演思維寫Claude提示詞：從分鏡腳本到參數(shù)調(diào)優(yōu))
在實(shí)際使用 Claude 的過(guò)程中很多人會(huì)把寫提示詞當(dāng)成一道工程題先給任務(wù)再列約束最后規(guī)定輸出格式模型只要按“參數(shù)表”執(zhí)行就行。這種“提示詞工程師”式的寫法能解決一部分問(wèn)題但很快會(huì)遇到瓶頸——提示詞寫得很規(guī)范Claude 的輸出卻總是差一口氣要么缺少細(xì)節(jié)要么語(yǔ)氣不對(duì)要么把次要要求放在核心結(jié)果前面。換一個(gè)視角會(huì)更容易接近問(wèn)題的本質(zhì)提示詞不是在“配置”一個(gè)模型而是在“調(diào)度”一組能力。與其把自己當(dāng)成提需求的工程師不如把自己當(dāng)成導(dǎo)演。導(dǎo)演不負(fù)責(zé)寫劇本也不替演員逐字表演但決定鏡頭、節(jié)奏、情緒和取舍寫提示詞時(shí)如果能把 Claude 當(dāng)作一個(gè)能力很強(qiáng)、但需要明確“鏡頭指令”的演員團(tuán)隊(duì)輸出質(zhì)量往往會(huì)有明顯提升。下面按這個(gè)順序展開先解釋為什么導(dǎo)演思維比工程師思維更適合提示詞編寫再給出可復(fù)用的提示詞模板、Claude Code 場(chǎng)景下的實(shí)際用法最后整理一份常見報(bào)錯(cuò)與排查清單。1. 為什么寫提示詞更像導(dǎo)演工作而不是工程任務(wù)1.1 “提示詞工程師”這個(gè)稱呼帶來(lái)的三個(gè)誤區(qū)“提示詞工程師”這個(gè)詞本身容易讓人誤以為提示詞是一份可以精確計(jì)算、批量復(fù)制的技術(shù)文檔。實(shí)際接觸 Claude 之后會(huì)發(fā)現(xiàn)這個(gè)認(rèn)知有三個(gè)明顯誤區(qū)。第一個(gè)誤區(qū)是“提示詞越長(zhǎng)越嚴(yán)謹(jǐn)”。很多人認(rèn)為把約束寫全、寫細(xì)模型就不會(huì)跑偏。實(shí)際恰恰相反過(guò)長(zhǎng)的提示詞會(huì)稀釋關(guān)鍵指令。Claude 在長(zhǎng)上下文中會(huì)把靠后的補(bǔ)充說(shuō)明理解為次要內(nèi)容結(jié)果就是最核心的那條約束反而被忽略。長(zhǎng)度不等于質(zhì)量重點(diǎn)是信息密度和位置。第二個(gè)誤區(qū)是“提示詞可以公式化復(fù)制”。網(wǎng)上的模板很多但一套模板在不同任務(wù)、不同模型版本上的表現(xiàn)差異很大。同一個(gè)模板寫代碼周報(bào)有效寫產(chǎn)品文案可能完全跑調(diào)。模板只是骨架真正起作用的是對(duì)輸出場(chǎng)景的理解。第三個(gè)誤區(qū)是“單次生成決定質(zhì)量”。工程思維的默認(rèn)動(dòng)作是“生成、檢查、不好就重新生成”但導(dǎo)演不會(huì)因?yàn)橐粭l鏡頭不滿意就讓演員重演整場(chǎng)戲。高水平的提示詞使用一定是多輪對(duì)話中的持續(xù)校準(zhǔn)而不是一次性提交。1.2 導(dǎo)演思維的核心從最終畫面倒推導(dǎo)演拿到劇本后不會(huì)馬上開拍而是先在腦子里“看到”成片哪個(gè)鏡頭是近景哪段情緒要壓住哪句臺(tái)詞必須讓觀眾記住。寫提示詞也應(yīng)該這樣先想清楚最終交付物在讀者面前長(zhǎng)什么樣再倒推 Claude 需要什么輸入。舉一個(gè)真實(shí)例子。同樣是“寫一份項(xiàng)目周報(bào)”工程師式寫法是這樣的幫我寫一份項(xiàng)目周報(bào)內(nèi)容要有本周進(jìn)展、下周計(jì)劃、風(fēng)險(xiǎn)。導(dǎo)演式寫法會(huì)先描述“這份周報(bào)會(huì)在周五例會(huì)上被快速掃讀負(fù)責(zé)人只有 30 秒瀏覽時(shí)間”所以結(jié)構(gòu)要一眼能看到結(jié)論再倒推出提示詞場(chǎng)景你是一位熟悉 Web 后端項(xiàng)目的開發(fā)負(fù)責(zé)人正在為周五項(xiàng)目例會(huì)準(zhǔn)備周報(bào)。 動(dòng)作 1. 列出本周完成的 3 項(xiàng)關(guān)鍵功能每項(xiàng)用一句話說(shuō)明業(yè)務(wù)價(jià)值 2. 按優(yōu)先級(jí)排列下周計(jì)劃最多 3 條 3. 單獨(dú)列一塊“風(fēng)險(xiǎn)與求助”只寫明確阻礙項(xiàng)。 驗(yàn)收總字?jǐn)?shù)控制在 300 字以內(nèi)每條不超過(guò) 40 字不要出現(xiàn)“圓滿完成、積極推動(dòng)”這類空話。這兩種寫法最大的區(qū)別不是字?jǐn)?shù)而是“先看到結(jié)果再組織輸入”。導(dǎo)演式寫法把使用場(chǎng)景、信息優(yōu)先級(jí)、完成標(biāo)準(zhǔn)全部前置Claude 自然知道往哪個(gè)方向使勁。1.3 把 Claude 當(dāng)成“演員組”而不是“問(wèn)答器”Claude 是一個(gè)能力很綜合的模型但單次回答只能呈現(xiàn)一個(gè)“鏡頭”。把它當(dāng)成問(wèn)答器你會(huì)只關(guān)注它“答得對(duì)不對(duì)”把它當(dāng)成演員組你才會(huì)關(guān)心它“這場(chǎng)戲演得符不符合整體調(diào)性”。后一個(gè)視角更貼近真實(shí)協(xié)作。下面用一張表對(duì)比兩種寫法的差異維度工程師式寫法導(dǎo)演式寫法目標(biāo)描述輸出一份完整報(bào)告說(shuō)明報(bào)告給誰(shuí)看、在什么場(chǎng)景看約束方式羅列禁止事項(xiàng)給出取舍原則和判斷優(yōu)先級(jí)上下文組織一次性堆入全部資料分階段按需投喂風(fēng)格對(duì)齊生成后人工大量修改先給樣例讓模型對(duì)齊調(diào)性質(zhì)量校準(zhǔn)失敗就重新生成指出偏差局部重拍需要說(shuō)明的是工程師式寫法不是錯(cuò)誤它是導(dǎo)演式寫法的基礎(chǔ)。問(wèn)題在于很多人只停留在“把要求列清楚”這一步?jīng)]有繼續(xù)往前走。導(dǎo)演思維是在工程思維之上增加了一層“結(jié)果感”你清楚最終畫面長(zhǎng)什么樣清楚哪里可以妥協(xié)哪里必須堅(jiān)持。2. 導(dǎo)演思維的第一步用分鏡腳本替代籠統(tǒng)需求2.1 分鏡腳本的三個(gè)層次場(chǎng)景、動(dòng)作、驗(yàn)收拍電影前需要分鏡腳本寫提示詞同樣需要。一個(gè)有效的提示詞分鏡腳本至少包含三個(gè)層次。場(chǎng)景層次交代“誰(shuí)在什么背景下做這件事”。比如“你是一位熟悉訂單系統(tǒng)的后端開發(fā)正在評(píng)審?fù)碌姆猪?yè)查詢改動(dòng)”。場(chǎng)景越具體Claude 越容易調(diào)用匹配的知識(shí)和語(yǔ)氣。動(dòng)作層次交代“具體要做什么、做到什么程度”。動(dòng)作必須用編號(hào)列出每一條都是一個(gè)可執(zhí)行的指令而不是一句評(píng)價(jià)。驗(yàn)收層次交代“怎么判斷輸出合格”。驗(yàn)收標(biāo)準(zhǔn)必須是可檢查的條件比如條數(shù)、字?jǐn)?shù)、格式、禁止項(xiàng)?！緢?chǎng)景】 你是一位熟悉訂單系統(tǒng)的后端開發(fā)正在評(píng)審?fù)碌姆猪?yè)查詢改動(dòng)。 【動(dòng)作】 1. 閱讀 OrderController.java 和 OrderService.java 2. 找出分頁(yè)參數(shù)傳遞不一致的地方 3. 按嚴(yán)重程度排序輸出問(wèn)題列表。 【驗(yàn)收】 - 每個(gè)問(wèn)題包含文件、行號(hào)、原因、修改建議 - 最多輸出 5 個(gè)問(wèn)題 - 如果沒有問(wèn)題直接回復(fù)“未發(fā)現(xiàn)問(wèn)題”不要展開。這個(gè)提示詞里沒有一句“請(qǐng)認(rèn)真分析”這類空話但 Claude 的輸出會(huì)非常穩(wěn)定。因?yàn)閳?chǎng)景、動(dòng)作、驗(yàn)收三層邊界都劃清楚了。2.2 為什么要“驗(yàn)收標(biāo)準(zhǔn)”而不是“好聽的要求”很多人寫提示詞喜歡用模糊評(píng)價(jià)詞比如“寫得專業(yè)一點(diǎn)”“語(yǔ)言簡(jiǎn)練一些”“結(jié)構(gòu)清晰一點(diǎn)”。問(wèn)題在于這些詞無(wú)法被模型檢查。Claude 無(wú)法判斷什么叫“專業(yè)”但它能判斷“是否超過(guò) 5 條”“是否出現(xiàn)感嘆號(hào)”“是否包含文件行號(hào)”。寫法是否可檢查存在的問(wèn)題寫得專業(yè)一點(diǎn)否無(wú)法判斷輸出是否達(dá)標(biāo)每條不超過(guò) 5 條是可直接核對(duì)語(yǔ)言簡(jiǎn)練否主觀標(biāo)準(zhǔn)每次結(jié)果都不同不要出現(xiàn)感嘆號(hào)是可直接核對(duì)按優(yōu)先級(jí)排序否需要補(bǔ)充“優(yōu)先級(jí)”的定義嚴(yán)重問(wèn)題在前次要問(wèn)題在后是明確定義了排序規(guī)則把驗(yàn)收標(biāo)準(zhǔn)寫成交互雙方都能核對(duì)的條件是導(dǎo)演式提示詞最核心的練習(xí)。你越能準(zhǔn)確描述“合格長(zhǎng)什么樣”Claude 越不需要靠猜。2.3 常見分鏡錯(cuò)誤把“背景”寫成“劇本”分鏡腳本最常犯的錯(cuò)誤是背景寫了一堆動(dòng)作和驗(yàn)收卻只有一句話。比如有人會(huì)寫“我們是做電商的技術(shù)棧是 Java最近在重構(gòu)訂單模塊代碼很亂歷史包袱重這次的目的是提升可維護(hù)性”然后只補(bǔ)一句“請(qǐng)給出重構(gòu)方案”。這種寫法的結(jié)果是 Claude 輸出一份看似全面、實(shí)際沒有重點(diǎn)的方案因?yàn)榭刂戚敵龅暮诵男畔ⅰ獎(jiǎng)幼骱万?yàn)收——缺失了。正確做法是背景點(diǎn)到為止動(dòng)作和驗(yàn)收占主要篇幅。背景只負(fù)責(zé)讓 Claude 知道“現(xiàn)在站在哪”動(dòng)作和驗(yàn)收負(fù)責(zé)告訴它“接下來(lái)怎么走、走到哪里算完成”。3. 理解 Claude 的提示詞參數(shù)才能當(dāng)好導(dǎo)演3.1 核心參數(shù)速查導(dǎo)演思維不只體現(xiàn)在文字上也體現(xiàn)在對(duì)參數(shù)的掌控。Claude 的 API 和不同客戶端暴露的參數(shù)不完全一樣但有幾個(gè)參數(shù)幾乎每次都會(huì)用到。參數(shù)作用常見范圍使用提示system設(shè)定整體規(guī)則、角色和長(zhǎng)期約束不定放穩(wěn)定規(guī)則不放臨時(shí)任務(wù)temperature控制輸出隨機(jī)性0 到 1代碼和數(shù)據(jù)用 0 到 0.3創(chuàng)意寫作用 0.7 到 1.0max_tokens輸出長(zhǎng)度上限按任務(wù)評(píng)估太小會(huì)截?cái)嗵髸?huì)浪費(fèi)成本messages多輪對(duì)話上下文按會(huì)話用多輪校準(zhǔn)代替反復(fù)重新生成stop_sequences停止符按場(chǎng)景結(jié)構(gòu)化輸出時(shí)可限制結(jié)束位置temperature 是最容易理解錯(cuò)的參數(shù)。它不是“質(zhì)量旋鈕”而是“隨機(jī)性旋鈕”。生成代碼、SQL、數(shù)據(jù)分析結(jié)論時(shí)過(guò)高的 temperature 會(huì)讓輸出不穩(wěn)定同一個(gè)任務(wù)跑兩次結(jié)果差異很大而做頭腦風(fēng)暴、起標(biāo)題、寫創(chuàng)意文案時(shí)temperature 過(guò)低又會(huì)讓結(jié)果千篇一律。3.2 用 Python API 演示導(dǎo)演式調(diào)用下面這段代碼演示了如何在 Claude API 調(diào)用中組織導(dǎo)演指令。注意 system 里放長(zhǎng)期規(guī)則user 里放本場(chǎng)戲的具體任務(wù)。from anthropic import Anthropic client Anthropic(api_keyyour-api-key) response client.messages.create( modelclaude-sonnet-4-20250514, # 以實(shí)際可用模型為準(zhǔn) max_tokens1024, temperature0.3, system( 你是一位對(duì)外文檔編輯。你的任務(wù)是把工程師口語(yǔ)化描述改寫成結(jié)構(gòu)清晰的教程。 規(guī)則每個(gè)步驟必須包含操作和結(jié)果段落不超過(guò) 150 字 不要使用感嘆號(hào)不要出現(xiàn)非常簡(jiǎn)單、顯而易見這類評(píng)價(jià)詞。 ), messages[ { role: user, content: 我今天配置 Claude Code在終端輸入 claude 之后提示無(wú)法識(shí)別這個(gè)命令不知道什么原因。, } ], ) print(response.content[0].text)關(guān)鍵點(diǎn)在于system 里規(guī)定了“你是誰(shuí)、你長(zhǎng)期遵守什么規(guī)則”user 里只描述“這一場(chǎng)戲要處理什么”。這樣調(diào)用之后即使多個(gè)任務(wù)共用一個(gè) system也不會(huì)出現(xiàn)風(fēng)格漂移。3.3 system prompt 和 user prompt 的職責(zé)邊界很多初學(xué)者習(xí)慣把所有要求都塞進(jìn) system prompt覺得這樣“優(yōu)先級(jí)更高”。實(shí)際上 system prompt 和 user prompt 各有分工。system prompt 適合放世界觀、角色、語(yǔ)氣、紅線、長(zhǎng)期規(guī)則比如“你是一位技術(shù)文檔編輯不要使用感嘆號(hào)不要評(píng)價(jià)用戶代碼”。user prompt 適合放當(dāng)前任務(wù)、參考材料、臨時(shí)約束比如“請(qǐng)把下面這段口語(yǔ)描述改寫成教程”。如果每次任務(wù)都不同卻把任務(wù)細(xì)節(jié)寫死在 system 里會(huì)造成兩個(gè)問(wèn)題一是每次請(qǐng)求都會(huì)攜帶這段內(nèi)容浪費(fèi) token二是 system 內(nèi)容過(guò)雜會(huì)稀釋真正重要的規(guī)則。正確做法是把 80% 的穩(wěn)定性規(guī)則放進(jìn) system把 80% 的任務(wù)細(xì)節(jié)放進(jìn) user。4. Claude Code 場(chǎng)景下的導(dǎo)演式提示詞實(shí)踐4.1 Claude Code 是什么Claude Code 是 Anthropic 提供的命令行編程助手能夠在終端里讀取項(xiàng)目文件、執(zhí)行命令、生成和修改代碼。它適合的場(chǎng)景包括代碼重構(gòu)、補(bǔ)充單元測(cè)試、解釋老代碼、批量修改、執(zhí)行多步構(gòu)建任務(wù)。對(duì)于開發(fā)者來(lái)說(shuō)Claude Code 的價(jià)值是把“對(duì)話式 AI”放進(jìn)真實(shí)項(xiàng)目上下文而不是在一個(gè)空白對(duì)話框里猜代碼。4.2 安裝與啟動(dòng)安裝 Claude Code 前先確認(rèn)本機(jī)環(huán)境滿足基本要求。項(xiàng)目要求Node.js18 或更高版本以官方要求為準(zhǔn)npm隨 Node.js 一并安裝終端Windows PowerShell、macOS 終端或 Linux bash賬戶與鑒權(quán)按官方流程完成登錄或配置 API Key安裝命令node -v npm install -g anthropic-ai/claude-code claude --version在項(xiàng)目目錄中啟動(dòng)cd your-project claude每一步之后都要做檢查。node -v能正常輸出版本號(hào)說(shuō)明 Node 環(huán)境可用npm install沒有報(bào) ERESOLVE 或權(quán)限錯(cuò)誤說(shuō)明全局安裝成功claude --version能輸出版本號(hào)說(shuō)明命令已經(jīng)進(jìn)入 PATH。如果最后一步報(bào)錯(cuò)說(shuō)明問(wèn)題出在環(huán)境變量而不是安裝本身。4.3 安裝后 claude 命令無(wú)法識(shí)別的排查Windows 上最常見的一個(gè)報(bào)錯(cuò)是這樣claude : 無(wú)法將“claude”項(xiàng)識(shí)別為 cmdlet、函數(shù)、腳本文件或可運(yùn)行程序的名稱。請(qǐng)檢查名稱的拼寫如果包括路徑請(qǐng)確保路徑正確然后再試一次。這個(gè)報(bào)錯(cuò)的原因通常是三類Node.js 或 npm 沒有安裝成功npm 全局安裝目錄不在 PATH 中終端會(huì)話是安裝前打開的沒有刷新環(huán)境變量。先檢查 Node 和 npmnode -v npm -v再查看 npm 全局安裝目錄npm config get prefix在 Windows 上這個(gè)命令通常會(huì)返回C:\Users\當(dāng)前用戶\AppData\Roaming\npm。如果該目錄不在系統(tǒng) PATH 中claude命令就無(wú)法被識(shí)別。可以先在 PowerShell 中臨時(shí)追加路徑驗(yàn)證$env:Path ;$env:APPDATA\npm claude --version如果這樣能生效說(shuō)明確實(shí)是 PATH 問(wèn)題需要把%APPDATA%\npm加入用戶的 PATH 環(huán)境變量然后重新打開終端。macOS 和 Linux 上如果全局安裝目錄不在 PATH可以檢查npm config get prefix對(duì)應(yīng)的 bin 目錄通常需要追加到 shell 配置文件中。4.4 在 Claude Code 中寫導(dǎo)演式任務(wù)提示詞Claude Code 的特點(diǎn)是它能看到項(xiàng)目文件、能執(zhí)行命令所以提示詞里必須明確“改動(dòng)邊界”和“驗(yàn)證方式”否則它會(huì)自由發(fā)揮。下面是一個(gè)導(dǎo)演式任務(wù)提示詞示例當(dāng)前項(xiàng)目是 Spring Boot 3 的訂單服務(wù)測(cè)試框架為 JUnit 5。 任務(wù) 1. 閱讀 OrderService.java 和 OrderRepository.java 2. 找出訂單列表查詢未分頁(yè)的代碼路徑 3. 改用 Pageable 分頁(yè)并把改動(dòng)限制在這兩個(gè)文件內(nèi) 4. 修改后運(yùn)行 mvn test只執(zhí)行 OrderService 相關(guān)測(cè)試 5. 如果測(cè)試失敗先回滾改動(dòng)再說(shuō)明失敗原因和修復(fù)建議。 約束不要引入新依賴不要改動(dòng)數(shù)據(jù)庫(kù)表結(jié)構(gòu)。 驗(yàn)收最終輸出一份改動(dòng)摘要包含修改文件、改動(dòng)行數(shù)和驗(yàn)證結(jié)果。這個(gè)提示詞包含了場(chǎng)景、動(dòng)作、邊界、驗(yàn)收四層信息。特別重要的是“改動(dòng)限制在這兩個(gè)文件內(nèi)”和“測(cè)試失敗先回滾”這兩條。它們定義了演員不能越界的紅線也定義了出問(wèn)題時(shí)的處理方式這正是導(dǎo)演式調(diào)度在編程任務(wù)中的體現(xiàn)。4.5 多輪校準(zhǔn)局部重拍而不是全部重來(lái)Claude Code 在多輪任務(wù)中很容易“過(guò)度執(zhí)行”改了你沒讓改的文件或者擅自調(diào)整代碼風(fēng)格。這時(shí)候不要重新發(fā)一整段提示詞而是像導(dǎo)演叫停一樣給出局部指令“Controller 不用改只處理 Service 層”“把新增的方法拆成兩個(gè)小方法保持職責(zé)單一”“刪掉新增注釋用方法名表達(dá)意圖”“這一步做對(duì)了繼續(xù)下一步”這種校準(zhǔn)方式有兩個(gè)好處。一是節(jié)省 token不需要重新加載上下文二是保留前面已經(jīng)正確的輸出只修正偏差部分最終結(jié)果更穩(wěn)定。5. 輸出不符合預(yù)期時(shí)的排查鏈路5.1 五類常見問(wèn)題和處理方案提示詞效果不好時(shí)大多數(shù)問(wèn)題不是 Claude “變笨了”而是輸入和參數(shù)沒有對(duì)齊。下面這張表整理了幾類最常見的現(xiàn)象和處理方向。現(xiàn)象可能原因檢查方式處理建議輸出空泛缺失驗(yàn)收標(biāo)準(zhǔn)檢查 prompt 是否有可檢查條件補(bǔ)上數(shù)量、長(zhǎng)度、格式限制回答啰嗦沒有長(zhǎng)度和語(yǔ)氣約束檢查 system 是否說(shuō)明字?jǐn)?shù)要求增加段落和字?jǐn)?shù)上限漏掉關(guān)鍵約束約束條目太多數(shù)一下 prompt 里的要求總數(shù)精簡(jiǎn)到 5 條以內(nèi)關(guān)鍵約束前置格式總不對(duì)沒有給輸出樣例檢查是否有 few-shot 示例給出一條期望輸出的樣例結(jié)果不穩(wěn)定temperature 過(guò)高查看調(diào)用參數(shù)代碼和數(shù)據(jù)場(chǎng)景降到 0.3 以下排查順序很重要。先看輸入是否完整再看路徑和命名是否正確然后看依賴版本和參數(shù)配置最后才考慮模型本身。不要一遇到輸出不理想就懷疑模型能力大多數(shù)情況是提示詞結(jié)構(gòu)問(wèn)題。5.2 從日志和參數(shù)報(bào)錯(cuò)入手如果 Claude API 直接返回錯(cuò)誤排查順序應(yīng)該是請(qǐng)求是否成功發(fā)出API key 是否正確model 名稱是否為當(dāng)前版本支持max_tokens 是否過(guò)小參數(shù)類型是否合法。比如模型名稱不識(shí)別時(shí)會(huì)看到類似 “is not a model this version of claude code recognizes” 的報(bào)錯(cuò)。這種情況首先要確認(rèn)你使用的模型名是否符合當(dāng)前 Claude Code 版本支持的命名格式再檢查是否有拼寫錯(cuò)誤最后確認(rèn)版本是否過(guò)老或過(guò)新。不要第一時(shí)間懷疑是工具壞了。鑒權(quán)問(wèn)題可以查看環(huán)境變量是否配置echo $env:ANTHROPIC_API_KEY在 PowerShell 中使用$env:ANTHROPIC_API_KEY注意不要在共享日志或截圖里暴露完整密鑰。生產(chǎn)環(huán)境建議使用密鑰管理服務(wù)或本地環(huán)境變量不要硬編碼在代碼里。5.3 多輪對(duì)話跑偏的恢復(fù)順序多輪對(duì)話跑偏時(shí)很多人會(huì)繼續(xù)追加新要求這通常會(huì)讓局勢(shì)更亂。推薦按下面的順序恢復(fù)。第一步停止追問(wèn)不要疊加新任務(wù)。第二步明確指出偏差只說(shuō)“不要什么”比如“這一步不是我要的只要保留 Service 層的改動(dòng)”。第三步讓 Claude 先復(fù)述理解說(shuō)一句“先復(fù)述一下你準(zhǔn)備怎么改”確認(rèn)它接收到的指令沒有偏差。第四步再給局部指令而不是重發(fā)整段 prompt。這套恢復(fù)順序的本質(zhì)是分鏡重拍先確認(rèn)演員理解再局部調(diào)整而不是推翻整場(chǎng)戲。6. 可復(fù)用的導(dǎo)演式提示詞實(shí)踐清單6.1 寫提示詞前先回答 5 個(gè)問(wèn)題在動(dòng)手寫提示詞之前花兩分鐘回答下面五個(gè)問(wèn)題可以讓大部分提示詞質(zhì)量直接提升一個(gè)檔次。最終交付物給誰(shuí)看在什么場(chǎng)景下看輸出里必須出現(xiàn)哪些信息絕對(duì)不能出現(xiàn)哪些內(nèi)容怎么判斷合格數(shù)量、格式、長(zhǎng)度、約束條件分別是什么如果輸出跑偏第一句校準(zhǔn)指令是什么第 5 個(gè)問(wèn)題最容易被忽略但它決定了你在多輪對(duì)話里是掌控節(jié)奏的導(dǎo)演還是被輸出帶著走的乘客。提前想好校準(zhǔn)指令等于提前準(zhǔn)備了“叫停方案”。6.2 把提示詞當(dāng)成資產(chǎn)來(lái)管理提示詞不是一次性草稿而是可以持續(xù)復(fù)用的工程資產(chǎn)。建議按下面的方式管理。按場(chǎng)景分類沉淀模板庫(kù)。比如代碼評(píng)審、文檔改寫、周報(bào)生成、數(shù)據(jù)分析、SQL 編寫每類維護(hù)一份帶場(chǎng)景和驗(yàn)收標(biāo)準(zhǔn)的模板。用版本管理工具記錄提示詞變更改版后對(duì)比歷史輸出你很快會(huì)發(fā)現(xiàn)哪些規(guī)則真正提升了質(zhì)量。對(duì)生產(chǎn)環(huán)境使用的提示詞做回歸測(cè)試固定一組輸入記錄各版本的輸出差異避免“這次改好了下次改壞了”的情況。另外要注意 token 成本長(zhǎng)期不用的 system prompt 內(nèi)容不要一直掛在請(qǐng)求里該精簡(jiǎn)就精簡(jiǎn)。6.3 擴(kuò)展方向想繼續(xù)深入可以從三個(gè)方向走。第一用 Claude API 批量評(píng)測(cè)不同提示詞版本把“哪個(gè)提示詞更好”從主觀感受變成可量化的對(duì)比。第二把高質(zhì)量的提示詞沉淀為團(tuán)隊(duì)模板減少每個(gè)成員從頭摸索的成本。第三學(xué)習(xí)多智能體編排時(shí)保留導(dǎo)演思維每個(gè)智能體相當(dāng)于一個(gè)演員提示詞就是分鏡腳本難點(diǎn)同樣在于角色邊界、任務(wù)拆解和結(jié)果驗(yàn)收。寫提示詞這件事真正稀缺的不是公式而是“知道自己要什么畫面”。工程師思維能保證提示詞可執(zhí)行、可復(fù)現(xiàn)導(dǎo)演思維能保證輸出有重點(diǎn)、有取舍、有質(zhì)感。把兩份思維疊在一起才是 Claude 使用技巧里最值得練習(xí)的部分。下次打開對(duì)話窗口前先別急著列要求試著在腦子里把最終結(jié)果演一遍再動(dòng)手寫提示詞。 用導(dǎo)演思維寫Claude提示詞：從分鏡腳本到參數(shù)調(diào)優(yōu)
在實(shí)際使用 Claude 的過(guò)程中很多人會(huì)把寫提示詞當(dāng)成一道工程題先給任務(wù)再列約束最后規(guī)定輸出格式模型只要按“參數(shù)表”執(zhí)行就行。這種“提示詞工程師”式的寫法能解決一部分問(wèn)題但很快會(huì)遇到瓶頸——提示詞寫得很規(guī)范Claude 的輸出卻總是差一口氣要么缺少細(xì)節(jié)要么語(yǔ)氣不對(duì)要么把次要要求放在核心結(jié)果前面。換一個(gè)視角會(huì)更容易接近問(wèn)題的本質(zhì)提示詞不是在“配置”一個(gè)模型而是在“調(diào)度”一組能力。與其把自己當(dāng)成提需求的工程師不如把自己當(dāng)成導(dǎo)演。導(dǎo)演不負(fù)責(zé)寫劇本也不替演員逐字表演但決定鏡頭、節(jié)奏、情緒和取舍寫提示詞時(shí)如果能把 Claude 當(dāng)作一個(gè)能力很強(qiáng)、但需要明確“鏡頭指令”的演員團(tuán)隊(duì)輸出質(zhì)量往往會(huì)有明顯提升。下面按這個(gè)順序展開先解釋為什么導(dǎo)演思維比工程師思維更適合提示詞編寫再給出可復(fù)用的提示詞模板、Claude Code 場(chǎng)景下的實(shí)際用法最后整理一份常見報(bào)錯(cuò)與排查清單。1. 為什么寫提示詞更像導(dǎo)演工作而不是工程任務(wù)1.1 “提示詞工程師”這個(gè)稱呼帶來(lái)的三個(gè)誤區(qū)“提示詞工程師”這個(gè)詞本身容易讓人誤以為提示詞是一份可以精確計(jì)算、批量復(fù)制的技術(shù)文檔。實(shí)際接觸 Claude 之后會(huì)發(fā)現(xiàn)這個(gè)認(rèn)知有三個(gè)明顯誤區(qū)。第一個(gè)誤區(qū)是“提示詞越長(zhǎng)越嚴(yán)謹(jǐn)”。很多人認(rèn)為把約束寫全、寫細(xì)模型就不會(huì)跑偏。實(shí)際恰恰相反過(guò)長(zhǎng)的提示詞會(huì)稀釋關(guān)鍵指令。Claude 在長(zhǎng)上下文中會(huì)把靠后的補(bǔ)充說(shuō)明理解為次要內(nèi)容結(jié)果就是最核心的那條約束反而被忽略。長(zhǎng)度不等于質(zhì)量重點(diǎn)是信息密度和位置。第二個(gè)誤區(qū)是“提示詞可以公式化復(fù)制”。網(wǎng)上的模板很多但一套模板在不同任務(wù)、不同模型版本上的表現(xiàn)差異很大。同一個(gè)模板寫代碼周報(bào)有效寫產(chǎn)品文案可能完全跑調(diào)。模板只是骨架真正起作用的是對(duì)輸出場(chǎng)景的理解。第三個(gè)誤區(qū)是“單次生成決定質(zhì)量”。工程思維的默認(rèn)動(dòng)作是“生成、檢查、不好就重新生成”但導(dǎo)演不會(huì)因?yàn)橐粭l鏡頭不滿意就讓演員重演整場(chǎng)戲。高水平的提示詞使用一定是多輪對(duì)話中的持續(xù)校準(zhǔn)而不是一次性提交。1.2 導(dǎo)演思維的核心從最終畫面倒推導(dǎo)演拿到劇本后不會(huì)馬上開拍而是先在腦子里“看到”成片哪個(gè)鏡頭是近景哪段情緒要壓住哪句臺(tái)詞必須讓觀眾記住。寫提示詞也應(yīng)該這樣先想清楚最終交付物在讀者面前長(zhǎng)什么樣再倒推 Claude 需要什么輸入。舉一個(gè)真實(shí)例子。同樣是“寫一份項(xiàng)目周報(bào)”工程師式寫法是這樣的幫我寫一份項(xiàng)目周報(bào)內(nèi)容要有本周進(jìn)展、下周計(jì)劃、風(fēng)險(xiǎn)。導(dǎo)演式寫法會(huì)先描述“這份周報(bào)會(huì)在周五例會(huì)上被快速掃讀負(fù)責(zé)人只有 30 秒瀏覽時(shí)間”所以結(jié)構(gòu)要一眼能看到結(jié)論再倒推出提示詞場(chǎng)景你是一位熟悉 Web 后端項(xiàng)目的開發(fā)負(fù)責(zé)人正在為周五項(xiàng)目例會(huì)準(zhǔn)備周報(bào)。 動(dòng)作 1. 列出本周完成的 3 項(xiàng)關(guān)鍵功能每項(xiàng)用一句話說(shuō)明業(yè)務(wù)價(jià)值 2. 按優(yōu)先級(jí)排列下周計(jì)劃最多 3 條 3. 單獨(dú)列一塊“風(fēng)險(xiǎn)與求助”只寫明確阻礙項(xiàng)。 驗(yàn)收總字?jǐn)?shù)控制在 300 字以內(nèi)每條不超過(guò) 40 字不要出現(xiàn)“圓滿完成、積極推動(dòng)”這類空話。這兩種寫法最大的區(qū)別不是字?jǐn)?shù)而是“先看到結(jié)果再組織輸入”。導(dǎo)演式寫法把使用場(chǎng)景、信息優(yōu)先級(jí)、完成標(biāo)準(zhǔn)全部前置Claude 自然知道往哪個(gè)方向使勁。1.3 把 Claude 當(dāng)成“演員組”而不是“問(wèn)答器”Claude 是一個(gè)能力很綜合的模型但單次回答只能呈現(xiàn)一個(gè)“鏡頭”。把它當(dāng)成問(wèn)答器你會(huì)只關(guān)注它“答得對(duì)不對(duì)”把它當(dāng)成演員組你才會(huì)關(guān)心它“這場(chǎng)戲演得符不符合整體調(diào)性”。后一個(gè)視角更貼近真實(shí)協(xié)作。下面用一張表對(duì)比兩種寫法的差異維度工程師式寫法導(dǎo)演式寫法目標(biāo)描述輸出一份完整報(bào)告說(shuō)明報(bào)告給誰(shuí)看、在什么場(chǎng)景看約束方式羅列禁止事項(xiàng)給出取舍原則和判斷優(yōu)先級(jí)上下文組織一次性堆入全部資料分階段按需投喂風(fēng)格對(duì)齊生成后人工大量修改先給樣例讓模型對(duì)齊調(diào)性質(zhì)量校準(zhǔn)失敗就重新生成指出偏差局部重拍需要說(shuō)明的是工程師式寫法不是錯(cuò)誤它是導(dǎo)演式寫法的基礎(chǔ)。問(wèn)題在于很多人只停留在“把要求列清楚”這一步?jīng)]有繼續(xù)往前走。導(dǎo)演思維是在工程思維之上增加了一層“結(jié)果感”你清楚最終畫面長(zhǎng)什么樣清楚哪里可以妥協(xié)哪里必須堅(jiān)持。2. 導(dǎo)演思維的第一步用分鏡腳本替代籠統(tǒng)需求2.1 分鏡腳本的三個(gè)層次場(chǎng)景、動(dòng)作、驗(yàn)收拍電影前需要分鏡腳本寫提示詞同樣需要。一個(gè)有效的提示詞分鏡腳本至少包含三個(gè)層次。場(chǎng)景層次交代“誰(shuí)在什么背景下做這件事”。比如“你是一位熟悉訂單系統(tǒng)的后端開發(fā)正在評(píng)審?fù)碌姆猪?yè)查詢改動(dòng)”。場(chǎng)景越具體Claude 越容易調(diào)用匹配的知識(shí)和語(yǔ)氣。動(dòng)作層次交代“具體要做什么、做到什么程度”。動(dòng)作必須用編號(hào)列出每一條都是一個(gè)可執(zhí)行的指令而不是一句評(píng)價(jià)。驗(yàn)收層次交代“怎么判斷輸出合格”。驗(yàn)收標(biāo)準(zhǔn)必須是可檢查的條件比如條數(shù)、字?jǐn)?shù)、格式、禁止項(xiàng)?！緢?chǎng)景】 你是一位熟悉訂單系統(tǒng)的后端開發(fā)正在評(píng)審?fù)碌姆猪?yè)查詢改動(dòng)。 【動(dòng)作】 1. 閱讀 OrderController.java 和 OrderService.java 2. 找出分頁(yè)參數(shù)傳遞不一致的地方 3. 按嚴(yán)重程度排序輸出問(wèn)題列表。 【驗(yàn)收】 - 每個(gè)問(wèn)題包含文件、行號(hào)、原因、修改建議 - 最多輸出 5 個(gè)問(wèn)題 - 如果沒有問(wèn)題直接回復(fù)“未發(fā)現(xiàn)問(wèn)題”不要展開。這個(gè)提示詞里沒有一句“請(qǐng)認(rèn)真分析”這類空話但 Claude 的輸出會(huì)非常穩(wěn)定。因?yàn)閳?chǎng)景、動(dòng)作、驗(yàn)收三層邊界都劃清楚了。2.2 為什么要“驗(yàn)收標(biāo)準(zhǔn)”而不是“好聽的要求”很多人寫提示詞喜歡用模糊評(píng)價(jià)詞比如“寫得專業(yè)一點(diǎn)”“語(yǔ)言簡(jiǎn)練一些”“結(jié)構(gòu)清晰一點(diǎn)”。問(wèn)題在于這些詞無(wú)法被模型檢查。Claude 無(wú)法判斷什么叫“專業(yè)”但它能判斷“是否超過(guò) 5 條”“是否出現(xiàn)感嘆號(hào)”“是否包含文件行號(hào)”。寫法是否可檢查存在的問(wèn)題寫得專業(yè)一點(diǎn)否無(wú)法判斷輸出是否達(dá)標(biāo)每條不超過(guò) 5 條是可直接核對(duì)語(yǔ)言簡(jiǎn)練否主觀標(biāo)準(zhǔn)每次結(jié)果都不同不要出現(xiàn)感嘆號(hào)是可直接核對(duì)按優(yōu)先級(jí)排序否需要補(bǔ)充“優(yōu)先級(jí)”的定義嚴(yán)重問(wèn)題在前次要問(wèn)題在后是明確定義了排序規(guī)則把驗(yàn)收標(biāo)準(zhǔn)寫成交互雙方都能核對(duì)的條件是導(dǎo)演式提示詞最核心的練習(xí)。你越能準(zhǔn)確描述“合格長(zhǎng)什么樣”Claude 越不需要靠猜。2.3 常見分鏡錯(cuò)誤把“背景”寫成“劇本”分鏡腳本最常犯的錯(cuò)誤是背景寫了一堆動(dòng)作和驗(yàn)收卻只有一句話。比如有人會(huì)寫“我們是做電商的技術(shù)棧是 Java最近在重構(gòu)訂單模塊代碼很亂歷史包袱重這次的目的是提升可維護(hù)性”然后只補(bǔ)一句“請(qǐng)給出重構(gòu)方案”。這種寫法的結(jié)果是 Claude 輸出一份看似全面、實(shí)際沒有重點(diǎn)的方案因?yàn)榭刂戚敵龅暮诵男畔ⅰ獎(jiǎng)幼骱万?yàn)收——缺失了。正確做法是背景點(diǎn)到為止動(dòng)作和驗(yàn)收占主要篇幅。背景只負(fù)責(zé)讓 Claude 知道“現(xiàn)在站在哪”動(dòng)作和驗(yàn)收負(fù)責(zé)告訴它“接下來(lái)怎么走、走到哪里算完成”。3. 理解 Claude 的提示詞參數(shù)才能當(dāng)好導(dǎo)演3.1 核心參數(shù)速查導(dǎo)演思維不只體現(xiàn)在文字上也體現(xiàn)在對(duì)參數(shù)的掌控。Claude 的 API 和不同客戶端暴露的參數(shù)不完全一樣但有幾個(gè)參數(shù)幾乎每次都會(huì)用到。參數(shù)作用常見范圍使用提示system設(shè)定整體規(guī)則、角色和長(zhǎng)期約束不定放穩(wěn)定規(guī)則不放臨時(shí)任務(wù)temperature控制輸出隨機(jī)性0 到 1代碼和數(shù)據(jù)用 0 到 0.3創(chuàng)意寫作用 0.7 到 1.0max_tokens輸出長(zhǎng)度上限按任務(wù)評(píng)估太小會(huì)截?cái)嗵髸?huì)浪費(fèi)成本messages多輪對(duì)話上下文按會(huì)話用多輪校準(zhǔn)代替反復(fù)重新生成stop_sequences停止符按場(chǎng)景結(jié)構(gòu)化輸出時(shí)可限制結(jié)束位置temperature 是最容易理解錯(cuò)的參數(shù)。它不是“質(zhì)量旋鈕”而是“隨機(jī)性旋鈕”。生成代碼、SQL、數(shù)據(jù)分析結(jié)論時(shí)過(guò)高的 temperature 會(huì)讓輸出不穩(wěn)定同一個(gè)任務(wù)跑兩次結(jié)果差異很大而做頭腦風(fēng)暴、起標(biāo)題、寫創(chuàng)意文案時(shí)temperature 過(guò)低又會(huì)讓結(jié)果千篇一律。3.2 用 Python API 演示導(dǎo)演式調(diào)用下面這段代碼演示了如何在 Claude API 調(diào)用中組織導(dǎo)演指令。注意 system 里放長(zhǎng)期規(guī)則user 里放本場(chǎng)戲的具體任務(wù)。from anthropic import Anthropic client Anthropic(api_keyyour-api-key) response client.messages.create( modelclaude-sonnet-4-20250514, # 以實(shí)際可用模型為準(zhǔn) max_tokens1024, temperature0.3, system( 你是一位對(duì)外文檔編輯。你的任務(wù)是把工程師口語(yǔ)化描述改寫成結(jié)構(gòu)清晰的教程。 規(guī)則每個(gè)步驟必須包含操作和結(jié)果段落不超過(guò) 150 字 不要使用感嘆號(hào)不要出現(xiàn)非常簡(jiǎn)單、顯而易見這類評(píng)價(jià)詞。 ), messages[ { role: user, content: 我今天配置 Claude Code在終端輸入 claude 之后提示無(wú)法識(shí)別這個(gè)命令不知道什么原因。, } ], ) print(response.content[0].text)關(guān)鍵點(diǎn)在于system 里規(guī)定了“你是誰(shuí)、你長(zhǎng)期遵守什么規(guī)則”user 里只描述“這一場(chǎng)戲要處理什么”。這樣調(diào)用之后即使多個(gè)任務(wù)共用一個(gè) system也不會(huì)出現(xiàn)風(fēng)格漂移。3.3 system prompt 和 user prompt 的職責(zé)邊界很多初學(xué)者習(xí)慣把所有要求都塞進(jìn) system prompt覺得這樣“優(yōu)先級(jí)更高”。實(shí)際上 system prompt 和 user prompt 各有分工。system prompt 適合放世界觀、角色、語(yǔ)氣、紅線、長(zhǎng)期規(guī)則比如“你是一位技術(shù)文檔編輯不要使用感嘆號(hào)不要評(píng)價(jià)用戶代碼”。user prompt 適合放當(dāng)前任務(wù)、參考材料、臨時(shí)約束比如“請(qǐng)把下面這段口語(yǔ)描述改寫成教程”。如果每次任務(wù)都不同卻把任務(wù)細(xì)節(jié)寫死在 system 里會(huì)造成兩個(gè)問(wèn)題一是每次請(qǐng)求都會(huì)攜帶這段內(nèi)容浪費(fèi) token二是 system 內(nèi)容過(guò)雜會(huì)稀釋真正重要的規(guī)則。正確做法是把 80% 的穩(wěn)定性規(guī)則放進(jìn) system把 80% 的任務(wù)細(xì)節(jié)放進(jìn) user。4. Claude Code 場(chǎng)景下的導(dǎo)演式提示詞實(shí)踐4.1 Claude Code 是什么Claude Code 是 Anthropic 提供的命令行編程助手能夠在終端里讀取項(xiàng)目文件、執(zhí)行命令、生成和修改代碼。它適合的場(chǎng)景包括代碼重構(gòu)、補(bǔ)充單元測(cè)試、解釋老代碼、批量修改、執(zhí)行多步構(gòu)建任務(wù)。對(duì)于開發(fā)者來(lái)說(shuō)Claude Code 的價(jià)值是把“對(duì)話式 AI”放進(jìn)真實(shí)項(xiàng)目上下文而不是在一個(gè)空白對(duì)話框里猜代碼。4.2 安裝與啟動(dòng)安裝 Claude Code 前先確認(rèn)本機(jī)環(huán)境滿足基本要求。項(xiàng)目要求Node.js18 或更高版本以官方要求為準(zhǔn)npm隨 Node.js 一并安裝終端Windows PowerShell、macOS 終端或 Linux bash賬戶與鑒權(quán)按官方流程完成登錄或配置 API Key安裝命令node -v npm install -g anthropic-ai/claude-code claude --version在項(xiàng)目目錄中啟動(dòng)cd your-project claude每一步之后都要做檢查。node -v能正常輸出版本號(hào)說(shuō)明 Node 環(huán)境可用npm install沒有報(bào) ERESOLVE 或權(quán)限錯(cuò)誤說(shuō)明全局安裝成功claude --version能輸出版本號(hào)說(shuō)明命令已經(jīng)進(jìn)入 PATH。如果最后一步報(bào)錯(cuò)說(shuō)明問(wèn)題出在環(huán)境變量而不是安裝本身。4.3 安裝后 claude 命令無(wú)法識(shí)別的排查Windows 上最常見的一個(gè)報(bào)錯(cuò)是這樣claude : 無(wú)法將“claude”項(xiàng)識(shí)別為 cmdlet、函數(shù)、腳本文件或可運(yùn)行程序的名稱。請(qǐng)檢查名稱的拼寫如果包括路徑請(qǐng)確保路徑正確然后再試一次。這個(gè)報(bào)錯(cuò)的原因通常是三類Node.js 或 npm 沒有安裝成功npm 全局安裝目錄不在 PATH 中終端會(huì)話是安裝前打開的沒有刷新環(huán)境變量。先檢查 Node 和 npmnode -v npm -v再查看 npm 全局安裝目錄npm config get prefix在 Windows 上這個(gè)命令通常會(huì)返回C:\Users\當(dāng)前用戶\AppData\Roaming\npm。如果該目錄不在系統(tǒng) PATH 中claude命令就無(wú)法被識(shí)別。可以先在 PowerShell 中臨時(shí)追加路徑驗(yàn)證$env:Path ;$env:APPDATA\npm claude --version如果這樣能生效說(shuō)明確實(shí)是 PATH 問(wèn)題需要把%APPDATA%\npm加入用戶的 PATH 環(huán)境變量然后重新打開終端。macOS 和 Linux 上如果全局安裝目錄不在 PATH可以檢查npm config get prefix對(duì)應(yīng)的 bin 目錄通常需要追加到 shell 配置文件中。4.4 在 Claude Code 中寫導(dǎo)演式任務(wù)提示詞Claude Code 的特點(diǎn)是它能看到項(xiàng)目文件、能執(zhí)行命令所以提示詞里必須明確“改動(dòng)邊界”和“驗(yàn)證方式”否則它會(huì)自由發(fā)揮。下面是一個(gè)導(dǎo)演式任務(wù)提示詞示例當(dāng)前項(xiàng)目是 Spring Boot 3 的訂單服務(wù)測(cè)試框架為 JUnit 5。 任務(wù) 1. 閱讀 OrderService.java 和 OrderRepository.java 2. 找出訂單列表查詢未分頁(yè)的代碼路徑 3. 改用 Pageable 分頁(yè)并把改動(dòng)限制在這兩個(gè)文件內(nèi) 4. 修改后運(yùn)行 mvn test只執(zhí)行 OrderService 相關(guān)測(cè)試 5. 如果測(cè)試失敗先回滾改動(dòng)再說(shuō)明失敗原因和修復(fù)建議。 約束不要引入新依賴不要改動(dòng)數(shù)據(jù)庫(kù)表結(jié)構(gòu)。 驗(yàn)收最終輸出一份改動(dòng)摘要包含修改文件、改動(dòng)行數(shù)和驗(yàn)證結(jié)果。這個(gè)提示詞包含了場(chǎng)景、動(dòng)作、邊界、驗(yàn)收四層信息。特別重要的是“改動(dòng)限制在這兩個(gè)文件內(nèi)”和“測(cè)試失敗先回滾”這兩條。它們定義了演員不能越界的紅線也定義了出問(wèn)題時(shí)的處理方式這正是導(dǎo)演式調(diào)度在編程任務(wù)中的體現(xiàn)。4.5 多輪校準(zhǔn)局部重拍而不是全部重來(lái)Claude Code 在多輪任務(wù)中很容易“過(guò)度執(zhí)行”改了你沒讓改的文件或者擅自調(diào)整代碼風(fēng)格。這時(shí)候不要重新發(fā)一整段提示詞而是像導(dǎo)演叫停一樣給出局部指令“Controller 不用改只處理 Service 層”“把新增的方法拆成兩個(gè)小方法保持職責(zé)單一”“刪掉新增注釋用方法名表達(dá)意圖”“這一步做對(duì)了繼續(xù)下一步”這種校準(zhǔn)方式有兩個(gè)好處。一是節(jié)省 token不需要重新加載上下文二是保留前面已經(jīng)正確的輸出只修正偏差部分最終結(jié)果更穩(wěn)定。5. 輸出不符合預(yù)期時(shí)的排查鏈路5.1 五類常見問(wèn)題和處理方案提示詞效果不好時(shí)大多數(shù)問(wèn)題不是 Claude “變笨了”而是輸入和參數(shù)沒有對(duì)齊。下面這張表整理了幾類最常見的現(xiàn)象和處理方向。現(xiàn)象可能原因檢查方式處理建議輸出空泛缺失驗(yàn)收標(biāo)準(zhǔn)檢查 prompt 是否有可檢查條件補(bǔ)上數(shù)量、長(zhǎng)度、格式限制回答啰嗦沒有長(zhǎng)度和語(yǔ)氣約束檢查 system 是否說(shuō)明字?jǐn)?shù)要求增加段落和字?jǐn)?shù)上限漏掉關(guān)鍵約束約束條目太多數(shù)一下 prompt 里的要求總數(shù)精簡(jiǎn)到 5 條以內(nèi)關(guān)鍵約束前置格式總不對(duì)沒有給輸出樣例檢查是否有 few-shot 示例給出一條期望輸出的樣例結(jié)果不穩(wěn)定temperature 過(guò)高查看調(diào)用參數(shù)代碼和數(shù)據(jù)場(chǎng)景降到 0.3 以下排查順序很重要。先看輸入是否完整再看路徑和命名是否正確然后看依賴版本和參數(shù)配置最后才考慮模型本身。不要一遇到輸出不理想就懷疑模型能力大多數(shù)情況是提示詞結(jié)構(gòu)問(wèn)題。5.2 從日志和參數(shù)報(bào)錯(cuò)入手如果 Claude API 直接返回錯(cuò)誤排查順序應(yīng)該是請(qǐng)求是否成功發(fā)出API key 是否正確model 名稱是否為當(dāng)前版本支持max_tokens 是否過(guò)小參數(shù)類型是否合法。比如模型名稱不識(shí)別時(shí)會(huì)看到類似 “is not a model this version of claude code recognizes” 的報(bào)錯(cuò)。這種情況首先要確認(rèn)你使用的模型名是否符合當(dāng)前 Claude Code 版本支持的命名格式再檢查是否有拼寫錯(cuò)誤最后確認(rèn)版本是否過(guò)老或過(guò)新。不要第一時(shí)間懷疑是工具壞了。鑒權(quán)問(wèn)題可以查看環(huán)境變量是否配置echo $env:ANTHROPIC_API_KEY在 PowerShell 中使用$env:ANTHROPIC_API_KEY注意不要在共享日志或截圖里暴露完整密鑰。生產(chǎn)環(huán)境建議使用密鑰管理服務(wù)或本地環(huán)境變量不要硬編碼在代碼里。5.3 多輪對(duì)話跑偏的恢復(fù)順序多輪對(duì)話跑偏時(shí)很多人會(huì)繼續(xù)追加新要求這通常會(huì)讓局勢(shì)更亂。推薦按下面的順序恢復(fù)。第一步停止追問(wèn)不要疊加新任務(wù)。第二步明確指出偏差只說(shuō)“不要什么”比如“這一步不是我要的只要保留 Service 層的改動(dòng)”。第三步讓 Claude 先復(fù)述理解說(shuō)一句“先復(fù)述一下你準(zhǔn)備怎么改”確認(rèn)它接收到的指令沒有偏差。第四步再給局部指令而不是重發(fā)整段 prompt。這套恢復(fù)順序的本質(zhì)是分鏡重拍先確認(rèn)演員理解再局部調(diào)整而不是推翻整場(chǎng)戲。6. 可復(fù)用的導(dǎo)演式提示詞實(shí)踐清單6.1 寫提示詞前先回答 5 個(gè)問(wèn)題在動(dòng)手寫提示詞之前花兩分鐘回答下面五個(gè)問(wèn)題可以讓大部分提示詞質(zhì)量直接提升一個(gè)檔次。最終交付物給誰(shuí)看在什么場(chǎng)景下看輸出里必須出現(xiàn)哪些信息絕對(duì)不能出現(xiàn)哪些內(nèi)容怎么判斷合格數(shù)量、格式、長(zhǎng)度、約束條件分別是什么如果輸出跑偏第一句校準(zhǔn)指令是什么第 5 個(gè)問(wèn)題最容易被忽略但它決定了你在多輪對(duì)話里是掌控節(jié)奏的導(dǎo)演還是被輸出帶著走的乘客。提前想好校準(zhǔn)指令等于提前準(zhǔn)備了“叫停方案”。6.2 把提示詞當(dāng)成資產(chǎn)來(lái)管理提示詞不是一次性草稿而是可以持續(xù)復(fù)用的工程資產(chǎn)。建議按下面的方式管理。按場(chǎng)景分類沉淀模板庫(kù)。比如代碼評(píng)審、文檔改寫、周報(bào)生成、數(shù)據(jù)分析、SQL 編寫每類維護(hù)一份帶場(chǎng)景和驗(yàn)收標(biāo)準(zhǔn)的模板。用版本管理工具記錄提示詞變更改版后對(duì)比歷史輸出你很快會(huì)發(fā)現(xiàn)哪些規(guī)則真正提升了質(zhì)量。對(duì)生產(chǎn)環(huán)境使用的提示詞做回歸測(cè)試固定一組輸入記錄各版本的輸出差異避免“這次改好了下次改壞了”的情況。另外要注意 token 成本長(zhǎng)期不用的 system prompt 內(nèi)容不要一直掛在請(qǐng)求里該精簡(jiǎn)就精簡(jiǎn)。6.3 擴(kuò)展方向想繼續(xù)深入可以從三個(gè)方向走。第一用 Claude API 批量評(píng)測(cè)不同提示詞版本把“哪個(gè)提示詞更好”從主觀感受變成可量化的對(duì)比。第二把高質(zhì)量的提示詞沉淀為團(tuán)隊(duì)模板減少每個(gè)成員從頭摸索的成本。第三學(xué)習(xí)多智能體編排時(shí)保留導(dǎo)演思維每個(gè)智能體相當(dāng)于一個(gè)演員提示詞就是分鏡腳本難點(diǎn)同樣在于角色邊界、任務(wù)拆解和結(jié)果驗(yàn)收。寫提示詞這件事真正稀缺的不是公式而是“知道自己要什么畫面”。工程師思維能保證提示詞可執(zhí)行、可復(fù)現(xiàn)導(dǎo)演思維能保證輸出有重點(diǎn)、有取舍、有質(zhì)感。把兩份思維疊在一起才是 Claude 使用技巧里最值得練習(xí)的部分。下次打開對(duì)話窗口前先別急著列要求試著在腦子里把最終結(jié)果演一遍再動(dòng)手寫提示詞。