省流（ TL;DR ）

• 核心問題：不是 AI 不会寫程式碼，而是需求、邊界、測試、文件沒準備好就讓它開寫，程式碼「看起來能用、後面難改」。
• 做法：用一串 Skill 把 AI 放進完整研發鏈路 —— 先收集上下文，再梳理性求、拷問邊界、出輕量方案，然後 TDD 實現、補測試、做 review 、本地走查、導出用例、更新文件。
• 流程特點：10 步有順序，但可在需求、方案、審查、走查、文件等環節回退修正，越早改成本越低。
• 人的角色：AI 負責整理和生成，取捨、驗收、能不能合仍要人判斷；目標是可控、可複用，不是一次性提速。

⏲️建議閱讀時間: 10min

轉生到 AI 研發時代，我不再迷信“許願式編程”，而是把 AI 放進需求、開發、測試和文檔這一整條研發鏈路裡。

一、為什麼 AI 的代碼總是難以維護？

很多人用 AI 寫代碼，第一步就是把需求丟進去，讓它直接生成。

剛開始確實很爽，速度快，效果也像那麼回事。但接到真實項目裡，問題就來了：寫法和項目不一致、權限漏了、邊界沒處理、異常場景沒考慮，測試也跟不上。

這些程式碼最麻煩的地方是「看起來能用，但後面難改」。因為它不是基於完整上下文寫出來的，而是基於一段暫時描述生成的。需求沒說清楚，AI 就只能猜；專案約束沒給足，AI 就按自己的習慣寫。

所以很多时候，不是 AI 寫程式碼不行，而是我們讓它太早開始寫程式碼了。需求、邊界、方案、測試點都沒準備好，就讓 AI 開始實現，最後生成得越快，返工也越快。

二、我的整體鏈路

1. 收集需求和專案上下文

2. 使用 /requirement skill 梳理需求

1. 使用 /grillwithdoc skill 拷問需求、邊界和風險

2. 輸出輕量技術實現說明

1. 使用 /TDD skill 實現核心邏輯

2. 使用 /testing skill 補齊單元測試/組件測試

1. 使用 /code review skill 做代碼審查

2. 本地運行，人工走查核心流程

1. 使用 /testcase skill 輸出 Excel ，用於導入 Transcend 專案管理平台

2. 使用 /feature-doc-maintainer 更新文件

這條鏈路不是只能從 1 走到 10 的直線流程。

主流程順序推進，但在需求拷問、技術方案、代碼審查、本地走查和文件更新階段，都可能回退到前面的步驟。發現問題就回到前面修正，越早改，成本越低。

第一步：先收集上下文，再讓 AI 工作

不要一上來就讓 AI 寫需求、寫方案或者寫代碼。因為在上下文不完整的情况下，AI 很容易給出看起來完整、但實際一坨的結果。

所以第一步是先把和需求相關的信息整理出來，比如原始需求、歷史文件、相似功能、接口說明、權限規則等。尤其是已經有的相似功能很重要，它能让 AI 參考項目裡真實的寫法，而不是重新發明一套方案。

上下文準備清楚了之後接下來就可以輕鬆的走下面的流程了，但是如果一開始信息有誤，那很可能会在錯誤的基礎上進行。

第二步：用 /requirement skill 梳理需求

上下文準備好之後，不要急着進入開發。先用 /requirement skill 把需求過一遍。

這一步主要是把零散的信息整理成結構化內容，比如功能目標是什麼、給誰用、核心流程怎麼走、涉及哪些字段和狀態、權限規則是什麼。

這裡要特別注意未確認問題或者是目前沒有想明白的地方，一定要先用 TODO 標記出來後面找人確認。 整理完畢，基本能產出一個可執行的需求文件，能夠明確整體方向了。後面我們還會用 grillwithdoc 來敲定細節

這裡產出時記得選 plan 模式

第三步：用 /grillwithdoc 技能 拷問需求

有了需求文件之後，不要馬上認定它就是對的。這個時候可以用 /grillwithdoc 技能 再拷問一遍。

🥚使用 plan 模式的话 有 對話框 可以一次一次確認

這一步主要是檢查需求有沒有說清楚，比如邊界在哪裡、哪些場景不做、異常情況怎麼處理、權限和數據範圍有沒有影響、按鈕控制是不是完整。很多問題在正常流程裡看不出來，只有換個角度追問，才會暴露出來。 這個 /grillwithdoc skill 很強，基本能把所有邊界和細節明確的很不清楚。

拷問完成之後就能夠得到一份寶貴的確認好細節的需求文檔了

第四步：輸出輕量技術實現說明

需求細節確認完之後，就可以開始看怎麼實現了。

這裡不建議一上來寫很重的技術方案，太長了沒人看，後面也不一定維護。我的做法是輸出一份輕量技術實現說明，把關鍵內容講清楚就行。

這一步的價值是讓後面的開發有一個明確方向。特別是多人協作或者需求比較複雜的時候，有一份輕量說明，後面寫代碼、補測試、做 review 都會順很多。

如果需求很簡單，或者已經很明確了，這一步也可以省略，後期少維護一個文檔👍

第五步：用 /TDD skill 實現核心邏輯

技術實現說明確定之後，就可以開始寫代碼了。

使用 /TDD skill 先處理核心邏輯。不要直接讓 AI 上來一顿寫，最好先讓它拆出核心行為，然後先寫測試，再實現代碼。

這樣做的好處是能限制 AI 的自由發揮。測試先寫出來，AI 後面的實現就要圍繞這些行為來做，不容易寫偏。

/TDD 技能 更適合用在建構核心邏輯、狀態轉流、工具函數、關鍵業務規則這些地方。如果是純頁面樣式或者很簡單的展示邏輯，就沒必要硬套 TDD 。該輕就輕，不要把流程搞複雜。

第六步：用 /Testing Vue Vitest 技能 补齊測試

TDD 做完之後，不代表測試就完成了。

TDD 更關注核心邏輯有沒有寫對，但頁面交互、組件行為、異常分支、權限顯隱這些，很可能還沒有覆蓋到。所以後面還要使用 /測試技能 再補一輪。

補測試的時候也要結合最終代碼看，不能只根據需求文檔生成。否則測試看起來很多，但可能測不到真正關鍵的地方。

/Testing Vue Vitest skill 這個也包含了頁面 UI 的 單元測試

第七步：用 /code review skill 做代碼審查

代碼和測試寫完之後。這個時候可以用 /code review skill 再過一遍。

/code review skill 也適合用來發現一些容易忽略的問題，比如重複邏輯、邊界處理不完整、測試沒覆蓋到關鍵場景等。

會按照優先級輸出一份質量報告

不過這裡還是要注意，AI review 只能作為提前檢查。最後這個代碼能不能合進去，還是要人自己判斷。

第八步：本地運行和人工走查

review 完之後，一定要本地跑一下。

尤其是前端功能，不能只看代碼和測試。頁面能不能打開、搜索分頁有沒有問題、新增編輯刪除是否正常、彈窗回顯對不對、錯誤提示是否合理、權限按鈕有沒有按預期顯示，這些都要實際走一遍。

這一步純體力活，就是人工驗收。AI 可以幫你寫代碼、補測試、做 review ，但它不能替你真實使用一遍功能。

如果本地走查發現問題，就回到前面的步驟修。不要因為流程已經走到第八步了，就硬往後推進。

第九步：用 /testcase skill 輸出測試用例 Excel

本地走查通過之後，就可以開始整理測試用例了。

這裡我會用 /testcase skill 輸出測試用例 Excel 。它不是只根據最開始的需求生成，而是結合需求文檔、技術實現說明、最終代碼改動、已有測試點和本地走查結果一起生成。

這樣出來的用例會更貼近真實功能，不容易寫出那種看起來很完整、但測不到重點的內容。

我們當前是把 Excel 導入 Transcend 專案管理平台。或者交付給測試，讓測試評估。

第十步：用 /feature-doc-maintainer 更新文件

最後一步是更新文件。

這裡的文件主要是倉庫內和功能強相關的文件，比如功能說明、權限規則、接口變化、操作流程、已知限制、測試說明等。不是為了補一篇很正式的文件，而是把最終實現沉澱下來。

很多次文件只停留在需求階段，後面代碼改了，文件沒跟上的。時間一長，下一次再改這個功能，又要重新理解一遍。

所以我會在鏈路最後用 /feature-doc-maintainer 做一次同步，把最終實現和關鍵說明補回去。這樣這次工作的結果，不僅停留在代碼裡，也能給後面的人（ AI ）繼續用。

三、人的判斷點

做正確的事，比正確地做事更重要。

這套鏈路雖然用了很多 Skill ，但核心判斷不能完全交給 AI 。

AI 可以幫我們整理信息、生成內容、補齊測試、做初步審查，但需求選擇、技術判斷、測試評估和最終驗收，還是要人來負責。

• 需求階段：需要判斷方向是否成立，哪些範圍要做，哪些先不做，哪些問題必須找產品或負責人確認。AI 可以把問題列出來，但不能替我們做選擇。

• 程式碼和測試階段：需要判斷程式碼是否符合專案現狀，改動成本是否可以接受，測試是否真的覆蓋了關鍵風險。程式碼能不能合進去、測試用例有沒有價值，最後還是要人來判斷。

所以這條鏈路不是讓 AI 替代人，而是讓人從重複整理、補充、檢查這些工作裡抽出來，把精力放在更重要的判斷和取捨上。AI 負責把材料準備好，人負責判斷這些東西是不是對的、能不能用。

四、這套鏈路帶來的變化

這套鏈路最大的變化，不是某一步突然快了多少，而是整個過程變得更穩了。

• 需求問題更早暴露

通過 /requirement skill 和 */grillwithdoc skill*，很多邊界、權限、異常場景可以在開發前先暴露出來，避免一邊寫代碼一邊補需求。

• AI 輸出更可控

每一步都有明確輸入和輸出，不是讓 AI 自由發揮。需求、方案、代碼、測試、文檔都能串起來，結果也更容易檢查。

• 返工更少

問題越早發現，修改成本越低。需求和方案階段能解決的問題，就不要拖到代碼寫完之後再改。

• 測試更有依據

測試不再是最後臨時補，而是基於需求、實現、代碼改動和本地走查結果生成，更貼近真實風險。

• 測試用例能進入協作流程

通過 /testcase skill 輸出 Excel ，可以導入 Transcend ，或者交給測試評估，不再只是本地文件。

• 文檔能同步更新

最後用 /feature-doc-maintainer 把最終實現、權限規則、接口變化、已知限制補回去，方便後續維護，也方便 AI 繼續理解上下文。

• 🧠人更專注判斷和取捨

人負責確認方向、篩選結果和最終驗收。

五、實踐中的注意點

1. 需求：先用 Plan 模式，不要直接執行

   需求階段盡量用 Plan 模式，讓 AI 先問問題、拆邊界、列 TODO 。

   這個階段不要急着生成代碼，重點是把方向、範圍、不做項先確認清楚。

2. 代碼：先用 Opus 4.7 計劃，再用 Composer 2.5 執行

   複雜需求可以先用 Opus 4.7 做方案和拆解，讓它把改動範圍、核心邏輯、風險點先列出來。

   確認方向沒問題後，再用 Composer 2.5 按計劃執行代碼修改。

   這樣比直接讓執行模型上來改代碼更穩，也更容易控制改動範圍。

1. 測試：先測核心路徑，再補邊界場景

   不要一開始就追求測試很全。

   先讓 AI 覆蓋核心流程，確認主路徑能跑通，再補權限、異常、空數據、搜索分頁、彈窗回顯這些邊界場景。

   測試用例也要人工篩一下，沒價值的不要硬留。

2. 文檔：最後再更新，基於最終實現寫

   文檔不要太早定稿。

   前面需求、代碼、測試都會調整，最好在本地走查和 review 之後，再用 /feature-doc-maintainer 更新。

   重點寫最終實現、權限規則、接口變化、已知限制，不要寫成很重的說明書。

六、總結

回到最開始的問題，為什麼要把這套實踐融入研發鏈路？

僅僅讓 AI 編寫程式碼，只能解決一小段效率問題。真正拖慢研發的，往往不是程式碼寫得慢，而是需求沒說清、邊界沒想全、測試補得晚、文件跟不上。問題不是沒做事，而是每一步都在補前一步的缺口。

這條鏈路的核心不是自動化，而是可控。每一步都有輸入、有輸出、有檢查點，也都允許人隨時介入確認。AI 能力越強，越需要這樣的鏈路來承接地。

最後要做到的不是讓 AI 替我們完成研發，而是讓 AI 穩定地參與研發。讓需求有依據，方案有約束，測試有反饋，文件有沉澱。這樣提效才不是一次性的，而是可以持續複用的。

七、本文用到的 Skill

這套鏈路裡主要用到了下面這些 Skill：

Skill	作用
requirement-analysis	整理需求，把零散信息整理成可執行的需求文件
grill-with-docs	詢問需求邊界、異常場景、權限和風險
tdd	用測試先行的方式實現核心邏輯
testing-vue-vitest	弥補 Vue 3 + Vitest 單元測試和組件測試
code-review	做代碼審查，提前發現質量和風險問題
diagnose	遇到複雜 bug 或性能問題時，按複現、假設、驗證、修復、回歸的流程定位問題
testcase-excel	生成測試用例 Excel ，方便導入測試管理平台
feature-doc-maintainer	根據最終實現更新功能文件

如果你也想把這些 Skill 放到自己的專案裡，可以參考我整理的 Git 倉庫：

Git 地址：https://github.com/535803710/ai-rd-skills

這些 Skill 不是固定答案，更像一套可以繼續調整的流程模板。真正落地時，建議根據自己團隊的項目結構、測試規範和文檔習慣做一輪改造。