AI 寫代碼之前，你漏掉的 8 件事，決定了項目是成還是廢
整理版優先睇
AI寫代碼前必做8件事：搭好環境，AI先係10倍效率放大器
呢篇文章係由一個叫竇竇嘅打工AI愛好者寫嘅。佢指出好多人以為用AI寫代碼就唔使跟軟件工程流程，但其實流程仲係好重要，只係目的變咗——以前係幫人有條理開發，而家係要幫AI Agent似人咁工作。結論係：你要為AI搭一個做得嘢嘅環境，環境搭錯咗，AI再聰明都係白做。
文章詳細講咗寫第一個Prompt之前一定要做嘅8件事，包括：先寫需求文檔（PRD）、手寫行為指南（claude.md）、配好Skills/Agents/MCP工具鏈、寫負面約束文件、建立進度同學習記錄、先寫測試再寫功能、從第一日做好Issue追蹤、同埋最後做壓力測試。呢8步係防止AI亂嚟同埋確保項目成功嘅關鍵。
作者強調，AI唔會革命軟件開發流程，只係換咗執行者。識得為AI搭建流程嘅人，可以將效率放大10倍；唔識搭嘅人，AI只會更快製造Bug。呢啲避坑能力先係AI時代真正值錢嘅能力。
- 結論：AI寫代碼前，必須先為AI搭建工作環境，流程依然重要，只係執行者由人變成AI。
- 方法：先寫PRD需求文檔，讓AI徹底理解要做咩，並通過Planner Agent反覆提問確認。
- 差異：手寫claude.md比自動生成更好，因為可以包含PRD連結、規則規範，避免冇用內容佔用上下文。
- 啟發：寫「唔好做咩」嘅負面約束比單純指令更重要，可以防止AI自作主張。
- 可行動點：建立Progress同Learnings文件，讓Agent持續記錄進度同錯誤，減少Token浪費同重複錯誤。
先搞清需求同行為指南
好多人一開波就對AI講「幫我寫個XXX應用」，結果出嚟嘅嘢同自己諗嘅完全唔同。唔係AI唔得，係你冇講清楚需求。正確做法係先寫PRD，創建一個Planner Agent，等佢反覆問你問題，直到徹底理解你要做咩。
PRD係成個項目嘅錨點，後面所有開發都圍繞佢展開。
Planner Agent會模擬產品經理嘅需求評審會，不斷追問細節。
- 第一步：用Planner Agent生成完整PRD，包含需求細節、實現計劃、關鍵設計決策。
- 第二步：手寫claude.md，指向PRD文檔，列出Agent必須遵守嘅規則同規範。
搭好工具鏈，再加負面約束
寫代碼之前要將所有工具連結好，包括MCP、Skills、Agents同路徑規則。另外，好多人忽略咗寫「唔好做咩」比寫「要做咩」更重要，因為AI傾向行動，會做你冇話唔做得嘅事。
MCP可以連接外部服務，例如Supabase、shadcn/ui、Playwright等。
Skills係可重複嘅工作流封裝，例如前端開發流程。
路徑規則可以定義具體模塊嘅開發規範，與全局claude.md互補。
- 1 第三步：提前配好Skills、Agents同MCP，確保Agent有工具可用。
- 2 第四步：寫負面約束文件，喺claude.md入面連結佢，防止Agent自作主張。
記錄進度、先測後寫、從頭追蹤
開發大型應用時，Agent好容易唔記得自己做過咩。所以要建立Progress同Learnings文件，等Agent持續更新。仲有，一定要先寫測試再寫功能，否則測試只會根據實現優化，而唔係根據需求。
Progress文件係Agent嘅施工進度表，Learnings文件係錯題本。
先寫測試可以確保測試以需求為錨點，唔係以實現為錨點。
Issue追蹤系統可以讓Agent自動記錄bug，多人協作時係救命稻草。
- 1 第五步：喺claude.md指示Agent持續更新Progress同Learnings文件。
- 2 第六步：從PRD推導測試用例，先寫測試再實現功能。
- 3 第七步：從第一日就接上Issue追蹤系統（GitHub或Notion MCP），讓Agent自動記錄bug同進度。
做足壓力測試，避免上線崩潰
AI生成嘅代碼天生唔會考慮併發場景，所以你必須主動話畀Agent預期嘅用戶規模同併發量，等佢編寫壓力測試用例。目標係就算出問題都可以優雅降級，唔係直接崩潰。
壓力測試工具可以揀K6或Artillery，根據技術棧決定。
優雅降級係目標，唔係直接崩潰。
- 1 第八步：話畀Agent預期用戶規模同併發量，編寫壓力測試用例。
- 2 用Claude嘅Plan Mode從多角度計劃生產環境方案。
- 總結：8步清單：1. 寫PRD；2. 手寫claude.md；3. 配好工具鏈；4. 寫負面約束；5. 建進度同學習文件；6. 先寫測試；7. 接Issue追蹤；8. 壓力測試。
- 記住：AI唔會革命流程，只係換咗執行者。為AI搭好環境，先可以發揮10倍效率。
好多人以為，有咗 AI 寫 code，軟件開發就變簡單咗。
錯。
AI 的確令一切快咗，出咗問題都更容易恢復。但軟件工程 60 年累積落嚟嘅流程，今日依然重要——只係原因變咗。
過去，呢啲流程係為咗令人有條理咁開發產品。而家，佢哋嘅作用變成咗令 AI Agent 好似人咁工作。
換句話講：你唔係喺度寫 code，你係喺度幫 AI 搭一個做到嘢嘅工作環境。環境搭錯咗，AI 再聰明都係喺度白忙。
今日呢篇文章，我將「動手寫第一行 prompt 之前」你一定要做嘅 8 件事，全部拆開嚟講清楚。
一、先寫需求文檔，唔係先寫 Prompt
呢個係最重要嘅一步，亦係再勁嘅模型都替代唔到嘅一步。
好多人一上嚟就對 AI 講「幫我寫個 XXX 應用」，然後發現做出嚟嘅嘢同自己諗嘅完全唔同。唔係 AI 唔得，係你冇將需求講清楚。
Claude Code 有個 Planning Mode，但佢偏技術角度，唔夠產品化。而家嘅模型已經夠強，規劃應該重產品、輕技術細節。
正確做法： 創建一個專門嘅 Planner Agent，叫佢按照 PRD（產品需求文檔）模板，不斷向你提問——直到佢完全理解你想做乜。
呢個過程好似產品經理嘅需求評審會。Agent 會不斷追問：用戶係邊個？核心場景係乜？MVP 包含邊啲功能？有冇遺漏？
問完之後，佢會生成一份完整嘅 PRD 文檔，包含：
所有需求細節 分階段嘅實現計劃 關鍵設計決策 應用所需嘅一切資訊
呢份文檔就係你整個項目嘅錨點。 之後所有嘅配置、開發、測試，都圍繞住佢嚟做。
二、手寫 CLAUDE.md，唔好用自動生成
claude.md 係 Claude Code 嘅「行為指南」——Agent 喺成個開發過程都會參考呢個檔案。
好多人用 claude init 命令自動生成，但呢個命令只係根據現有 codebase 推斷，佢唔知道你個項目真正需要啲乜。
正確做法：手寫。
呢個檔案應該包含：
指向 PRD 文檔嘅連結（咁樣 Agent 可以直接讀取需求，你唔使重複） 項目要跟從嘅規則同規範 編碼約定同風格要求 你希望 Agent 特別遵守嘅指令
唔應該包含：
項目結構描述（Agent 自己識讀目錄） AI 本來就知道嘅常識 只同某個具體功能相關嘅指令（呢啲應該放喺路徑規則入面）
記住：呢個檔案會被加載一次，永遠留喺上下文入面。所以唔好塞無關嘅內容，每一行都要值得佔用上下文窗口。
而且，佢唔係寫一次就搞掂嘅。隨住開發推進，你要持續喺裏面補充新嘅經驗同約定。
三、提早配好 Skills、Agents 同 MCP
喺動手寫 code 之前，將你嘅工具鏈全部接好。
MCP（Model Context Protocol）： 連接外部服務。例如：
用 Supabase 做後端？接上 Supabase MCP 用 shadcn/ui 做組件？接上對應嘅 MCP 用 Playwright 做測試？都要提早接好
Agents： 針對唔同任務創建專門嘅 Agent：
Planner Agent：負責需求規劃 Commit Agent：負責提交 code、運行預檢查、遵守 Conventional Commits Refactoring Agent：負責重構同性能優化 Verification Agent：使用 Playwright MCP 驗證 UI 同用戶流程
Skills： 將可重複嘅工作流程封裝成 Skill。例如前端開發係一個重複出現嘅流程，需要始終跟從統一嘅規範——呢個就適合做成 Skill。
簡單區分：
需要獨立上下文窗口嘅任務 → 用 Agent 可重複、需要參考文檔同指引嘅工作流程 → 用 Skill
另外，仲要設置路徑級規則（path-specific rules）。claude.md 管嘅係全局原則，而具體到某個模塊、某個目錄嘅開發規範，應該用路徑規則嚟定義。
四、寫「唔好做啲乜」比「要做啲乜」更重要
呢一點俾絕大多數人忽略咗。
AI Agent 天生傾向於行動。你同佢講「要做啲乜」，佢會做；但佢亦會做好多你冇講但佢覺得應該做的事。
正面指令留低嘅係一個「隱含嘅空白地帶」，Agent 會自作主張去填充佢。
所以你要明確咁同佢講：乜嘢唔做得。
創建一個負面約束檔案（例如放喺 docs/ 目錄下），喺 claude.md 裏面連結佢。內容包括你明確唔想要嘅嘢。
舉個最常見嘅例子：如果你唔想 AI 用佢默認嘅紫藍白配色方案，你一定要明確寫出嚟「唔好用紫色同藍色嘅默認配色」，而唔係淨係俾咗個設計稿就指望佢識領會。
負面約束 = 消除歧義 + 防止 Agent 喺唔應該實驗嘅地方亂搞。
五、等 Agent 自己記錄進度同教訓
當你開發一個有多個功能嘅大型應用時，Agent 好容易忘記自己做過啲乜、冇做過啲乜。
冇進度檔案，Agent 每次都要回頭讀 code、對照文檔，先至搞得清楚當前狀態。呢個又浪費時間，又浪費 Token。
你需要兩個檔案：
Progress 檔案： Agent 嘅「施工進度表」。佢一眼就知邊啲功能已完成、邊啲未開始。
Learnings 檔案： Agent 嘅「錯題本」。記錄遇到嘅錯誤、原因分析、解決方案。咁樣下次遇到類似問題，佢就唔會重蹈覆轍。
關鍵係：你要喺 claude.md 裏明確指示 Agent 喺開發過程中持續更新呢兩個檔案。否則佢唔會主動去寫。
呢兩個檔案係所有 AI 編碼框架嘅核心機制，無論你用邊個框架，底層邏輯都係一樣嘅。
六、先寫測試，再寫功能
呢個係好多人犯嘅經典錯誤：功能全部寫曬，最後先補測試。
點解咁樣唔得？因為如果 Agent 係喺功能實現之後先寫測試，佢只係知道「code 實際做咗啲乜」，而唔係「code 應該做啲乜」。
佢會為現有嘅實現優化測試，而唔係為需求規格優化測試。結果就係：
需求入面有但冇正確實現嘅功能，測試發現唔到 Agent 會偷懶，跳過本應覆蓋嘅邊界情況
正確做法：
叫 Agent 讀 PRD 從 PRD 反向推導功能應該點樣工作 基於推導結果先寫測試 然後再實現功能 最後用測試交叉驗證實現係咪符合需求
永遠唔好俾一句空泛嘅「測試一下呢個應用」俾 Agent。要令測試以需求為錨點，而唔係以實現為錨點。
七、從第一日就做好 Issue 追蹤
唔做追蹤，問題就會堆積。等到應用規模變大咗，你根本搞唔清楚邊個問題係幾時出現、咩原因導致。
對技術團隊： 用 GitHub。
結構化嘅 Git Commit Messages 可以令 Agent 追蹤每次提交做咗啲乜 出問題可以 revert commit 想做實驗性修改可以用 worktree 做隔離 配置 Agent 每次實現後自動提交，附帶詳細嘅提交信息
對非技術團隊成員： 接入 Trello 或 Notion 嘅 MCP。
叫 Agent 自動記錄 bug、追蹤進度、管理看板 在 claude.md裏面註明 Agent 應該用 Notion MCP 嚟追蹤問題
越早建立追蹤體系，項目越大時就越受益。 當多個人同時開發時，呢個就係你嘅救命稻草。
八、唔好唔記得生產環境嘅壓力測試
你嘅應用喺本地行得好完美，單用戶測試全部通過。然後一上線，多個用戶同時用——冧咗。
AI 生成嘅 code 天生唔會考慮併發場景。 你一定要主動話俾佢知。
點樣做：
話俾 Agent 知預期嘅用戶規模同併發量 叫佢基於呢啲資訊編寫壓力測試用例 用 Claude 嘅 Plan Mode 從多個角度規劃生產環境方案（呢度需要詳細嘅技術計劃） Agent 會從唔同視角提問，幫你發現潛在嘅生產問題
目標係令應用就算出問題都可以優雅降級，而唔係直接冧檔。
壓力測試工具可以揀 K6、Artillery 等，根據你嘅技術棧嚟定。
總結：清單一覽
喺你寫第一行 Prompt 之前，確保做完呢 8 件事：
AI 唔會革命軟件開發流程——佢只係換咗一個執行者。 流程依然重要，只係而家你要為 AI 而唔係為人嚟搭建呢個流程。
搭好環境嘅人，AI 係 10 倍效率放大器。冇搭好嘅人，AI 只係一個更快嘅 Bug 製造機。
識別到 code 裏面嘅坑、判斷到邊條路值得行、將技術變成可用嘅嘢—呢 啲先係 AI 時代真正值錢嘅能力。
每星期幫你篩一次 AI 工具同技術更新，只留值得花時間嘅。遇到部署問題
、選型糾結，直接問我。一杯奶茶錢，先體驗一次。
主理人介紹：竇竇，普通打工仔，亦係重度 AI 研究愛好者。日頭忙工作，夜晚忙搞工具、試方法、做內容
更鍾意分享我自己試過、踩過坑、最後覺得真係有用嘅嘢
關注我，一齊將複雜嘅 AI，變成普通人都用得着嘅日常。
很多人以為，有了 AI 寫代碼，軟件開發就變簡單了。
錯。
AI 確實讓一切更快了，出了問題也更容易恢復。但軟件工程 60 年積累下來的那些流程，今天依然重要——只是原因變了。
過去，這些流程是為了讓人有條理地開發產品。現在，它們的作用變成了讓 AI Agent 像人一樣工作。
換句話說：你不是在寫代碼，你是在給 AI 搭一個能幹活的工作環境。環境搭錯了，AI 再聰明也是在瞎忙。
今天這篇文章，我把"動手寫第一行 prompt 之前"你必須做的 8 件事，全部拆開講清楚。
一、先寫需求文檔，不是先寫 Prompt
這是最重要的一步，也是再強的模型都替代不了的一步。
很多人上來就對 AI 說"幫我寫個 XXX 應用"，然後發現做出來的東西跟自己想的完全不一樣。不是 AI 不行，是你沒把需求講清楚。
Claude Code 有個 Planning Mode，但它偏技術視角，不夠產品化。現在的模型已經足夠強了，規劃應該重產品、輕技術細節。
正確做法： 創建一個專門的 Planner Agent，讓它按照 PRD（產品需求文檔）模板，反覆向你提問——直到它徹底理解你要做什麼。
這個過程很像產品經理的需求評審會。Agent 會不斷追問：用戶是誰？核心場景是什麼？MVP 包含哪些功能？有沒有遺漏？
問完之後，它會生成一份完整的 PRD 文檔，包含：
所有需求細節 分階段的實現計劃 關鍵設計決策 應用所需的一切信息
這份文檔就是你整個項目的錨點。 後面所有的配置、開發、測試，都圍繞它展開。
二、手寫 CLAUDE.md，別用自動生成
claude.md 是 Claude Code 的"行為指南"——Agent 在整個開發過程中都會參考這個文件。
很多人用 claude init 命令自動生成，但這個命令只是根據現有代碼庫推斷，它不知道你的項目真正需要什麼。
正確做法：手寫。
這個文件應該包含：
指向 PRD 文檔的連結（這樣 Agent 可以直接讀取需求，你不用重複） 項目要遵循的規則和規範 編碼約定和風格要求 你希望 Agent 特別遵守的指令
不應該包含：
項目結構描述（Agent 自己能讀目錄） AI 本來就知道的常識 只跟某個具體功能相關的指令（這些應該放到路徑規則裏）
記住：這個文件會被加載一次，永遠留在上下文裏。所以不要塞無關的內容，每一行都要值得佔用上下文窗口。
而且，它不是寫一次就完事的。隨着開發推進，你要持續往裏面補充新的經驗和約定。
三、提前配好 Skills、Agents 和 MCP
在動手寫代碼之前，把你的工具鏈全部接好。
MCP（Model Context Protocol）： 連接外部服務。比如：
用 Supabase 做後端？接上 Supabase MCP 用 shadcn/ui 做組件？接上對應 MCP 用 Playwright 做測試？也要提前接好
Agents： 針對不同任務創建專門的 Agent：
Planner Agent：負責需求規劃 Commit Agent：負責提交代碼、運行預檢查、遵循 Conventional Commits Refactoring Agent：負責重構和性能優化 Verification Agent：使用 Playwright MCP 驗證 UI 和用戶流程
Skills： 把可重複的工作流封裝成 Skill。比如前端開發是一個反覆出現的流程，需要始終遵循統一的規範——這就適合做成 Skill。
簡單區分：
需要獨立上下文窗口的任務 → 用 Agent 可重複、需要參考文檔和指引的工作流 → 用 Skill
另外，還要設置路徑級規則（path-specific rules）。claude.md 管的是全局原則，而具體到某個模塊、某個目錄的開發規範，應該用路徑規則來定義。
四、寫"不要做什麼"比"要做什麼"更重要
這一點被絕大多數人忽略了。
AI Agent 天生傾向於行動。你告訴它"要做什麼"，它會做；但它也會做很多你沒說但它覺得應該做的事。
正面指令留下的是一個"隱含的空白地帶"，Agent 會自作主張去填充它。
所以你必須顯式地告訴它：什麼不能做。
創建一個負面約束文件（比如放在 docs/ 目錄下），在 claude.md 裏連結它。內容包括你明確不想要的東西。
舉個最常見的例子：如果你不想讓 AI 用它默認的紫藍白配色方案，你必須明確寫出來"不要用紫色和藍色的默認配色"，而不是僅僅給了一個設計稿就指望它能領會。
負面約束 = 消除歧義 + 防止 Agent 在不該實驗的地方瞎折騰。
五、讓 Agent 自己記錄進度和教訓
當你開發一個有多個功能的大型應用時，Agent 很容易忘記自己做過什麼、沒做什麼。
沒有進度文件，Agent 每次都要回頭讀代碼、對照文檔，才能搞清楚當前狀態。這既浪費時間，又浪費 Token。
你需要兩個文件：
Progress 文件： Agent 的"施工進度表"。它一眼就能知道哪些功能已完成、哪些還沒開始。
Learnings 文件： Agent 的"錯題本"。記錄遇到的錯誤、原因分析、解決方案。這樣下次遇到類似問題，它不會重蹈覆轍。
關鍵是：你要在 claude.md 裏明確指示 Agent 在開發過程中持續更新這兩個文件。否則它不會主動去寫。
這兩個文件是所有 AI 編碼框架的核心機制，無論你用哪個框架，底層邏輯都是一樣的。
六、先寫測試，再寫功能
這是很多人犯的經典錯誤：功能全寫完了，最後才補測試。
為什麼這樣不行？因為如果 Agent 是在功能實現之後才寫測試，它只知道"代碼實際做了什麼"，而不是"代碼應該做什麼"。
它會為已有的實現優化測試，而不是為需求規格優化測試。結果就是：
需求裏有但沒正確實現的功能，測試發現不了 Agent 會偷懶，跳過本該覆蓋的邊界情況
正確做法：
讓 Agent 讀 PRD 從 PRD 反向推導功能應該怎麼工作 基於推導結果先寫測試 然後再實現功能 最後用測試交叉驗證實現是否符合需求
永遠不要給 Agent 一句空泛的"測試一下這個應用"。要讓測試以需求為錨點，而不是以實現為錨點。
七、從第一天就做好 Issue 追蹤
不做追蹤，問題就會堆積。等到應用規模變大了，你根本搞不清楚哪個問題是什麼時候出現的、什麼原因導致的。
對技術團隊： 用 GitHub。
結構化的 Git Commit Messages 能讓 Agent 追蹤每次提交做了什麼 出問題可以 revert commit 想做實驗性修改可以用 worktree 做隔離 配置 Agent 每次實現後自動提交，附帶詳細的提交信息
對非技術團隊成員： 接入 Trello 或 Notion 的 MCP。
讓 Agent 自動記錄 bug、追蹤進度、管理看板 在 claude.md裏註明 Agent 應該用 Notion MCP 來追蹤問題
越早建立追蹤體系，項目越大時越受益。 當多個人同時開發時，這就是你的救命稻草。
八、別忘了生產環境的壓力測試
你的應用在本地跑得很完美，單用戶測試全部通過。然後一上線，多個用戶同時用——崩了。
AI 生成的代碼天生不會考慮併發場景。 你必須主動告訴它。
怎麼做：
告訴 Agent 預期的用戶規模和併發量 讓它基於這些信息編寫壓力測試用例 用 Claude 的 Plan Mode 從多個角度��劃生產環境方案（這裏需要詳細的技術計劃） Agent 會從不同視角提問，幫你發現潛在的生產問題
目標是讓應用即使出問題也能優雅降級，而不是直接崩潰。
壓力測試工具可以選 K6、Artillery 等，根據你的技術棧來定。
總結：清單一覽
在你寫第一行 Prompt 之前，確保做完這 8 件事：
AI 不會革命軟件開發流程——它只是換了一個執行者。 流程依然重要，只是現在你要為 AI 而不是為人來搭建這個流程。
搭好環境的人，AI 是 10 倍效率放大器。 沒搭好的人，AI 只是一個更快的 Bug 製造機。
能識別代碼裏的坑、能判斷哪條路值得走、能把技術變成可用的東西—這 些才是 AI 時代真正值錢的能力。
每週幫你篩一遍 AI 工具和技術更新，只留值得花時間的。遇到部署問題
、選型糾結，直接問我。一杯奶茶錢，先體驗一次。
主理人介紹：竇竇，普通打工人，也是重度 AI 研究愛好者白天忙工作，晚上忙折騰工具、試方法、做內容
更喜歡分享 我自己試過、踩過坑、最後覺得真有用的東西
關注我，一起把複雜的 AI，過成普通人也能用上的日常。