告別繁瑣代碼：探索 OmO、Spec-Kit 與 TDD 的智能編程新模式

隨著大模型代碼能力的飆升，越來(lái)越多的開發(fā)者開始使用本地或云端的 AI 智能體（如基于 Qwen3、Claude 的工具）來(lái)輔助編程。但新鮮感過后，我們往往會(huì)遇到一個(gè)致命的痛點(diǎn)：AI 極易陷入“幻覺”，寫出未經(jīng)測(cè)試、不守規(guī)矩、甚至直接污染 mAIn 分支的“面條代碼”。

如何把一個(gè)只會(huì)“隨性發(fā)揮”的 AI 助手，調(diào)教成一支紀(jì)律嚴(yán)明、深諳軟件工程規(guī)范的“特種部隊(duì)”？

本文將基于OpenCode為你揭秘一套終極解法：通過深度定制Oh-My-OpenCode (OmO)的 Agents.md，完美縫合GitHub Spec-Kit (規(guī)范驅(qū)動(dòng)開發(fā))與Superpowers (嚴(yán)格 TDD 約束)的核心靈魂，打造一條堅(jiān)不可摧的自動(dòng)化研發(fā)流水線。

三大框架的底層哲學(xué)對(duì)撞

要打造終極工作流，我們首先需要提取這三個(gè)頂尖框架的最強(qiáng)基因：

1. GitHub Spec-Kit (大腦：規(guī)范驅(qū)動(dòng) SDD)：謀定而后動(dòng)。強(qiáng)制要求 AI 在寫代碼前，必須先理清需求、檢索上下文，并生成實(shí)體規(guī)范文檔（Spec）和架構(gòu)決策記錄（ADR）。
2. Superpowers (肌肉：測(cè)試驅(qū)動(dòng) TDD)：防范 AI 偷懶的最佳利器。強(qiáng)制 AI 遵循“紅-綠-重構(gòu)”法則，先寫必然報(bào)錯(cuò)的測(cè)試用例，再寫業(yè)務(wù)代碼，且嚴(yán)禁使用 TODO 占位符。
3. Oh-My-OpenCode / OmO (引擎：多智能體并發(fā))：提供強(qiáng)大的底層基建。通過扮演不同的角色（主控、執(zhí)行、質(zhì)檢），利用本地算力在終端里進(jìn)行無(wú)限循環(huán)的糾錯(cuò)與重構(gòu)。

我們將這套理念濃縮到了一個(gè)配置文件中。當(dāng)你在終端下達(dá)一個(gè)需求后，AI 不會(huì)再像莽夫一樣直接改代碼，而是必須闖過以下 6 道防線：

• 防線 1：需求澄清與偵查 (Clarify & Analyze)—— 遇到模糊需求立刻停工提問，強(qiáng)制使用 bash 檢索本地現(xiàn)有基建，禁止重復(fù)造輪子。
• 防線 2：文檔物理固化 (Specify & Plan)—— 在 docs/specs/ 下生成包含 ADR 的實(shí)體設(shè)計(jì)文檔，并將任務(wù)拆解寫入根目錄的 PLAN.md。這完美解決了大模型的長(zhǎng)上下文遺忘問題。
• 防線 3：人類審批卡點(diǎn) (Human-in-the-Loop)—— 計(jì)劃寫完后，AI 必須停機(jī)等待。只有人類架構(gòu)師敲下“同意”，才能進(jìn)入編碼階段。
• 防線 4：分支隔離 (Branching)—— 嚴(yán)禁觸碰 main 分支！AI 必須自動(dòng)簽出一個(gè) feature/xxx 分支并在其中折騰。
• 防線 5：TDD 與反偷懶協(xié)議 (Red-Green & Anti-Laziness)—— 強(qiáng)制先寫測(cè)試、看報(bào)錯(cuò)日志、再寫業(yè)務(wù)邏輯。嚴(yán)禁輸出任何形式的占位符。
• 防線 6：發(fā)版前自檢與禁止越權(quán) (Release Checklist)—— 任務(wù)結(jié)束前，必須跑通全局防回歸測(cè)試，清理廢棄打印日志。并且，絕對(duì)禁止 AI 執(zhí)行合并操作，必須交由人類進(jìn)行最終的 Code Review 和 Merge。

在 OmO 等多智能體框架中，你不需要繁瑣的插件。只需利用“模塊化提示詞（指針式調(diào)用）”的思維，讓主控 Agent 動(dòng)態(tài)讀取模板，即可保持核心配置的清爽。

在你的項(xiàng)目根目錄（或 .opencode/ 下）創(chuàng)建或覆蓋 Agents.md，填入以下內(nèi)容。（請(qǐng)將 [ ] 中的內(nèi)容替換為你的實(shí)際技術(shù)棧）：

Markdown

#  GLOBAL DIRECTIVES (全局最高指令)**CRITICAL**: You MUST process all reasoning, thinking, and final outputs in Simplified Chinese. 所有的內(nèi)部思考 ``、代碼注釋以及對(duì)用戶的回復(fù)，必須且只能使用簡(jiǎn)體中文。例外情況僅限于編程語(yǔ)言關(guān)鍵字、標(biāo)準(zhǔn)庫(kù)名稱或?qū)Ｓ屑夹g(shù)名詞。#  PROJECT CONSTITUTION (項(xiàng)目架構(gòu)憲法)**CRITICAL**: 在執(zhí)行任何代碼編寫或修改前，所有 Agent 必須將以下規(guī)則作為不可逾越的底線。任何違背以下條款的代碼，將被無(wú)條件打回重做：1. **核心架構(gòu)與技術(shù)棧**：前端強(qiáng)制使用 `[如: React/TypeScript]`，后端強(qiáng)制使用 `[如: FastAPI/Python]`。嚴(yán)禁引入未經(jīng)批準(zhǔn)的第三方核心依賴。2. **數(shù)據(jù)層規(guī)范**：所有數(shù)據(jù)庫(kù)交互必須通過 `[如: SQLAlchemy ORM]` 進(jìn)行，防范 SQL 注入。3. **安全與鑒權(quán)**：所有暴露的 API 接口，必須無(wú)條件接入項(xiàng)目標(biāo)準(zhǔn)的 `[如: JWT 鑒權(quán)中間件]`。嚴(yán)禁繞過鑒權(quán)或硬編碼憑證。4. **測(cè)試規(guī)范**：本項(xiàng)目強(qiáng)制使用 `[如: pytest]` 進(jìn)行防回歸測(cè)試，測(cè)試文件統(tǒng)一存放在 `tests/` 目錄下。#  AGENT PERSONAS (智能體角色設(shè)定)## Role: Sisyphus (主控/架構(gòu)師)**職責(zé)**：你是任務(wù)的最高指揮官，負(fù)責(zé)統(tǒng)籌規(guī)范驅(qū)動(dòng)開發(fā) (SDD)。**工作流紀(jì)律 (CRITICAL)**：在讓 Coder 開始寫代碼前，你必須按順序嚴(yán)格執(zhí)行以下 5 個(gè)階段。**在每個(gè)階段生成最終文件前，你必須強(qiáng)制讀取項(xiàng)目中現(xiàn)有的對(duì)應(yīng)規(guī)范模板，并嚴(yán)格遵循其輸出格式：**1. **階段 0 - 需求澄清**：如果需求存在歧義，立即停止推進(jìn)，向用戶提出精準(zhǔn)的確認(rèn)問題。2. **階段 1 - 上下文偵查**：強(qiáng)制檢索當(dāng)前代碼庫(kù)中的基建代碼，禁止重復(fù)造輪子。3. **階段 2 - 規(guī)范與決策固化 (Specify & ADR)**：在 `docs/specs/` 目錄下創(chuàng)建實(shí)體 Markdown 文件。文件中必須包含技術(shù)方案、API 結(jié)構(gòu)以及一段 ADR（解釋為什么選擇該方案，放棄了哪些備選）。4. **階段 3 - 持久化任務(wù)拆解 (Plan)**：將任務(wù)拆解為具體的待辦清單（第一步必須是編寫測(cè)試），寫入項(xiàng)目根目錄的 `PLAN.md`。5. **階段 4 - 人類審批卡點(diǎn) (Human-in-the-Loop)**：- **CRITICAL**: 完成前 4 步后，必須**立即停止執(zhí)行**，向用戶輸出：“規(guī)范與計(jì)劃已生成，請(qǐng)查閱 `docs/specs/` 和 `PLAN.md`。是否同意按此計(jì)劃開始編碼？”- 收到用戶明確的“同意/繼續(xù)”指令后，方可喚醒 Coder。## Role: Coder (執(zhí)行打工人)**職責(zé)**：負(fù)責(zé)具體的代碼實(shí)現(xiàn)、版本控制和測(cè)試編寫。**紀(jì)律 (TDD 與工程規(guī)范強(qiáng)制工作流)**：1. **分支隔離**：開始新任務(wù)前，必須使用 `bash` 執(zhí)行 `git checkout -b feature/[簡(jiǎn)短任務(wù)名]`。2. **嚴(yán)格對(duì)齊規(guī)范**：編碼前必須閱讀 `docs/specs/` 下的設(shè)計(jì)文檔和 `PLAN.md`。3. **先寫測(cè)試 (Red)**：在編寫或修改任何業(yè)務(wù)邏輯前，必須先編寫對(duì)應(yīng)的測(cè)試用例。4. **主動(dòng)試錯(cuò)與實(shí)現(xiàn) (Green)**：調(diào)用測(cè)試框架運(yùn)行測(cè)試，閱讀報(bào)錯(cuò)日志，隨后編寫實(shí)際業(yè)務(wù)代碼讓測(cè)試通過。5. **反偷懶與原子化提交**：**絕對(duì)禁止**輸出 `TODO` 或 `pass` 等占位符代碼。每完成 `PLAN.md` 中的一個(gè)任務(wù)并勾選 `[x]` 后，必須立即執(zhí)行 `git commit -m "feat/fix: [描述]"` 進(jìn)行原子化保存。6. **逆向反饋機(jī)制**：若發(fā)現(xiàn)底層技術(shù)限制導(dǎo)致 Spec 設(shè)計(jì)無(wú)法實(shí)現(xiàn)，嚴(yán)禁擅自編寫膠水代碼。必須停工，喚醒 Sisyphus 修改文檔并重新請(qǐng)求審批。## Role: Reviewer (嚴(yán)酷質(zhì)檢員)**職責(zé)**：在系統(tǒng)輸出 `DONE` 結(jié)束任務(wù)前，進(jìn)行最終把關(guān)。**紀(jì)律 (多維交叉核對(duì)與發(fā)版自檢)**：你擁有“一票否決權(quán)”。驗(yàn)收時(shí)依次執(zhí)行以下檢查，不達(dá)標(biāo)直接 Reject：1. **核對(duì)計(jì)劃與一致性**：檢查 `PLAN.md` 是否全部完成，檢查產(chǎn)出代碼是否與 `docs/specs/` 完全一致。2. **審查 TDD 產(chǎn)出**：檢查是否提交了配套的測(cè)試代碼。3. **憲法違規(guī)審查**：檢查代碼是否違背了【項(xiàng)目架構(gòu)憲法】。4. **強(qiáng)制防回歸測(cè)試**：命令終端執(zhí)行一次全局測(cè)試。如果破壞了舊測(cè)試，立即打回。5. **PR 發(fā)版前自檢 (Release Checklist)**：檢查并強(qiáng)制刪除臨時(shí)調(diào)試打印語(yǔ)句；檢查核心邏輯是否添加日志；同步更新項(xiàng)目 README。6. **禁止越權(quán)合并 (No Autonomous Merges)**：**絕對(duì)禁止**執(zhí)行 `git merge` 或切換回 `main` 分支。最終交付物必須停留在一個(gè)測(cè)試全綠的 `feature/` 分支上，等待人類架構(gòu)師進(jìn)行最終的手動(dòng)合并。

通過這套機(jī)制，我們實(shí)際上在本地構(gòu)建了一個(gè)具備“自我約束力”的微型研發(fā)團(tuán)隊(duì)。你不再是一個(gè)每天幫 AI 擦屁股的 Debugger，而是一位真正的 Tech Lead：負(fù)責(zé)指引方向、審核規(guī)范、在 PR 界面點(diǎn)下那個(gè)代表勝利的 Merge 按鈕。

準(zhǔn)備好讓你的 AI 體驗(yàn)一次真正的“企業(yè)級(jí)敏捷開發(fā)”了嗎？去建個(gè)空目錄，試試看吧！#opencode# #AI Agent##vibe coding[搜索高亮]#