生活分享

Claude Code|如何把需求交代清楚

寫出目標、範圍、限制與驗收條件。好的任務提示詞會讓 Claude Code 知道你要完成什麼、可以改哪裡,以及用什麼方式確認成功。它不需要華麗的角色設定,最有價值的是清楚的邊界與可驗證成果。把「幫我把網站做好」改成「為待辦清單加入三種篩選,保留新增與刪除,附測試並實際操作驗證」,工作就有了明確的落點。

閱讀時間約 5 分鐘

如何把需求交代清楚:文件、螢幕與完成記號的幾何插圖
圖片:Mokaair (© Mokaair)
本篇目錄
  1. 描述想看到的改變
  2. 寫出範圍與限制
  3. 先規劃再實作
  4. 用驗收條件收尾
  5. 中途補充指示
  6. 練習改寫自己的需求

好的任務提示詞會讓 Claude Code 知道你要完成什麼、可以改哪裡,以及用什麼方式確認成功。它不需要華麗的角色設定,最有價值的是清楚的邊界與可驗證成果。把「幫我把網站做好」改成「為待辦清單加入三種篩選,保留新增與刪除,附測試並實際操作驗證」,工作就有了明確的落點。

這篇帶你把一個模糊需求改寫成可執行的小任務,再練習讀懂回報與補充指示。範例沿用待辦清單網站,沒有程式經驗也能先練習寫需求。真正開始修改前,請先完成,確保你知道原本的功能和測試結果。

描述想看到的改變

描述想看到的改變 → 寫出範圍與限制 → 先規劃再實作
描述想看到的改變 → 寫出範圍與限制 → 先規劃再實作 · 圖片:Mokaair (© Mokaair)
閱讀完整文字說明

如何把需求交代清楚,以流程和文件圖形呈現教學重點。

先寫使用者行為,再寫實作想法。例如「我按已完成,只看到打勾的待辦」是一個可觀察行為;「幫我改善架構」則還沒有說清楚成果。若你不知道技術方法,直接描述操作、輸入與預期畫面,讓 Claude 先探索專案再提出實作選擇。不要為了讓提示詞看起來專業,塞入自己還不確定的框架或函式名稱。

需求也要說明哪些情況算失敗。例如「切換篩選後,原本的待辦仍要保留;切回全部時能再看到」。這補上了容易漏掉的邊界:篩選只是顯示方式,不能真的刪掉不符合的資料。好的驗收條件通常來自你最怕被改壞的行為,而不是模糊地要求「不能有 Bug」。

寫出範圍與限制

範圍可以用功能、檔案區域或資料來界定。對新手,先描述功能最自然:「只做篩選,這次不加入帳號與遠端資料庫」。對熟悉專案的人,可以補充「預期主要改動 app.js、model.js 與測試;若需要改其他區域,先說明原因」。這是在提供判斷依據,不必把每一行實作都指定好。

提示詞部分需要交代的內容待辦清單範例
目標使用者會看到的改變可選全部、未完成、已完成
範圍本次要處理的功能只處理篩選
限制需要遵守的條件不增加套件,保留資料
驗收如何判斷成功測試通過,三種畫面正確
回報你需要的交付資訊改動摘要、測試結果、未驗證部分

如果資料夾已有其他人未完成的工作,應明確指出那些變更的用途與本次任務關係。不要要求 Claude 為了得到乾淨狀態而直接覆蓋不認識的檔案。當你自己也不清楚現況,可以先下只讀檢查任務,等它整理出事實後再決定實作範圍。

先規劃再實作

涉及多個檔案或你還不確定方法時,先請它整理現況、建議步驟與測試方式。規劃階段要產出能讓你評估的內容,例如資料要如何保存、哪個地方處理篩選、是否需要新依賴。只列「分析、開發、測試」三個大字,仍不足以讓你知道方案會怎麼影響專案。

Claude Code 對話框:先確認方案 · text
我想在待辦清單加入「全部、未完成、已完成」三種篩選。
請先閱讀現有程式與測試,提出最小改動方案。
限制:不增加第三方套件,不更動資料結構,篩選不能刪除原始項目。
請說明預計改哪些檔案、要補哪些測試,以及瀏覽器要怎麼驗證。
這一輪先不修改檔案。

看方案時,對照它是否回答你的需求,而不是只看文字長短。若它提出整個框架遷移,先要求縮小到目前功能;若它有兩個方案,請它說明選擇理由及具體差異。確認方案後,再明確要求照方案實作,避免一方面要求只分析,一方面又期待檔案已經被修改。

用驗收條件收尾

Claude Code 對話框:確認後實作 · text
請依剛才確認的方案實作。
驗收條件:
1. 三種篩選都能正確顯示。
2. 切回全部時,原始項目數量與內容不變。
3. 在篩選狀態勾選或刪除,仍以項目識別碼處理。
4. 原有測試與新增測試通過。
5. 開啟網頁實際操作;若環境無法操作,說明尚未驗證的步驟。
完成後回報修改摘要、檢查結果與剩餘事項。

驗收應該涵蓋正常操作和一兩個容易出錯的情境。比如一筆待辦完成後,從未完成清單消失是正確行為;它應該仍能在已完成清單找到。這類情境既能寫成測試,也能讓沒有程式背景的人在瀏覽器親自確認。測試是證據的一部分,不能拿一個與需求無關的通過結果代替整個功能驗證。

中途補充指示

另一種有用的寫法是明確指出資料來源的優先順序。例如「畫面上的文案以附圖為準,資料行為以現有測試為準;兩者衝突時先列出差異」。這能避免 Claude 為了模仿畫面而改掉原本資料規則,也讓你能在真正需要決定的地方提供答案。附件提供證據,任務文字則說明如何使用證據。

對較大的需求,可以先指定一個可獨立驗收的最小成果。例如先完成桌面與手機都能操作的三個篩選按鈕,再處理美化。每段工作都應有自己的完成條件,不能把所有檢查留到最後才發現資料處理方向錯了。拆分的依據是能否獨立判斷成功,而不是機械地限制一次只能改一個檔案。

發現方向偏離時,指出具體落差與期望修正。例如「目前切換篩選會重設輸入框,但我希望保留正在輸入的文字」。不要只說「做得不對」,也不要把新的需求藏在一大段抱怨中。若新的想法會擴大範圍,例如新增雲端同步,先把它另列,讓目前可完成的小功能收尾。

練習改寫自己的需求

拿一個你原本想說「幫我優化」的任務,依序補上使用者行為、保留條件、範圍和完成判準。再請另一個人只讀這份文字,說出他理解的成果;若兩人的理解不同,優先修正那一句。最後把任務交給 Claude,檢查回報是否逐項對應驗收,而不是只回覆「已完成」。這個方法也能用於、文件整理或接手舊專案,關鍵都在於讓輸入與成果可以對照。

回總目錄

  • 生活分享

    Claude Code|建立第一個 mod:在 Claude Code 行程內數工具呼叫

    寫一個三檔案的 mod,用驗證器與測試確認它掛上的事件。文件把 mod 定義成多了入口檔的 plugin:入口檔叫 hooks module,Claude Code 在事件發生時呼叫裡面的函式,函式可以觀察、改寫或接手事件。

  • 生活分享

    Claude Code|Git Worktree 平行工作

    隔離多個任務的檔案與分支。Git Worktree 讓同一儲存庫擁有多個工作目錄,各自使用分支與檔案。本篇會把待辦篩選與文件整理分開,確認兩個 session 不會直接改到彼此的檔案,再把其中一個成果整合回主分支。你也會知道何時可以安全清理工作目錄。

  • 生活分享

    Claude Code|雙 Worktree 實作與衝突整合

    隔離兩項功能,最後完成整合與回歸。兩個 Claude 工作階段同時編輯專案,最容易出現的問題是互相改到同一份檔案,或各自測試通過、整合後卻失敗。本篇用兩個 Worktree 分別處理篩選預設值與介面文字,故意製造一次小衝突,再完成整合、驗證與清理。你不需要先啟用 Agent Teams。

  • 生活分享

    Claude Code|比較流程品質、用量與執行時間

    以同一資料集比較兩種工作方法。比較兩種 Claude 工作方法時,不能只挑成功那一次,也不能只看第一個答案有多快。本篇用固定案例、原始紀錄和一致判準,比較品質、重試、等待與人工整合時間,最後寫出有樣本數與限制的報告,而不是保證某個方法一定省錢。

最新旅遊情報攻略

資料來源

生活分享