在 AI 輔助開發(fā)的浪潮中，我們習慣了用 AI 寫代碼，也開始嘗試用 AI 寫需求文檔（Spec）。但你是否發(fā)現(xiàn)，AI 寫出來的文檔往往有一種“精致的平庸感”？

• 看似專業(yè)：辭藻華麗，結構完整。
• 實則難用：充滿了“系統(tǒng)應具備高性能”、“用戶體驗流暢”這種無法驗收的廢話；或者過早地寫死了“使用 Redis 緩存”，限制了開發(fā)者的發(fā)揮。

通常，我們把這歸咎于模型不夠聰明。但經(jīng)過深度的 Prompt Engineering 實踐，我們發(fā)現(xiàn)問題的核心不在于模型，而在于流程——我們把 AI 當成了“作家”，卻忘了給它配一個“編輯”。

今天，我要揭秘一個名為 specify 的內部工具背后的核心邏輯。我們通過引入“需求單元測試（Unit Tests for Requirements）”的概念，讓 AI 學會了自我反思和自我糾錯。

核心理念：建立需求的“自動化驗收標準”

在軟件開發(fā)中，我們有單元測試來保證代碼的質量。那么，需求文檔的質量由誰來保證？

在我們設計的 checklist.prompt 中，定義了一個顛覆性的概念：Checklist 不是用來測試代碼的，而是用來測試“需求寫作”本身的。

請看這組對比：

前者是 QA 的工作，后者才是產(chǎn)品經(jīng)理（或 AI Agent）應該對自己產(chǎn)出物做的“單元測試”。

架構揭秘：內化的自我反思 (Internalized Self-Reflection)

普通的 Prompt 是線性的：輸入 -> AI 生成 -> 輸出。
而我們的 specify.prompt 是一個閉環(huán)系統(tǒng)。

它不僅僅是生成文檔，它將上述“需求單元測試”的邏輯內化為了一個強制性的步驟。AI 在向你吐出任何字符之前，必須在思維鏈（Chain of Thought）中先扮演一次“冷面質檢員”。

工作流解析

1. Drafting (起草)：
   AI 扮演“初級產(chǎn)品經(jīng)理”，根據(jù)你的自然語言描述（如“加個微信登錄”），結合行業(yè)標準，起草第一版 Spec。

2. Linting (靜態(tài)分析)：
   這是最精彩的一步。AI 切換角色，基于內置的 Checklist 規(guī)則，對剛才的“草稿”進行掃描。它不關心功能好不好用，它只關心文檔寫得對不對：

   • Implementation Leak Check：是否泄露了實現(xiàn)細節(jié)？（如出現(xiàn)了 React、Redis 等詞？Fail?。?/li>
   • Measurability Check：驗收標準是否可量化？（如出現(xiàn)了“很快”、“很好”？Fail?。?/li>
   • Ambiguity Check：是否有未定義的模糊地帶？

3. Refactoring (重構)：
   如果 Linting 失敗，AI 被禁止輸出結果。它必須在內部進行重寫，直到通過所有“單元測試”。

4. Final Output (交付)：
   只有當所有檢查項都打鉤后，你才會看到最終的那份文檔。

為什么這種“左右互搏”能帶來質的飛躍？

1. 根除“技術實現(xiàn)細節(jié)泄漏”

AI 模型看過太多代碼，所以它總想教你怎么寫代碼。通過在 Prompt 中硬性規(guī)定“Requirement Unit Test: No Implementation Details”，我們給 AI 裝上了一個過濾器。

• Before: "系統(tǒng)應使用 WebSocket 推送消息。" (技術細節(jié)，限制了方案)
• After: "系統(tǒng)應支持服務器端主動向客戶端發(fā)送實時通知。" (業(yè)務需求，方案開放)

2. 強制“模糊概念量化”

AI 喜歡寫片湯話。通過強制檢查“Measurability（可測量性）”，逼迫 AI 把形容詞變成數(shù)字。

• Before: "在大流量下保持穩(wěn)定。"
• After: "在 10,000 并發(fā)用戶下，95% 的請求響應時間需小于 500ms。"

3. 模擬人類專家的“元認知”

高手寫文檔，是邊寫邊改的。普通的 Prompt 試圖一步到位，這違反了創(chuàng)作規(guī)律。通過顯式定義這個 Validation Loop，我們賦予了 AI 自我糾錯（Self-Correction） 的能力。

實戰(zhàn)：把“需求測試”裝進你的 Prompt

你不需要復雜的 Agent 框架，只需要在你的 System Prompt 末尾加入這個“質量門禁（Quality Gate）”模塊：

## ?? 最終步驟：規(guī)格質量驗證 (Specification Quality Validation)

**CRITICAL**: 在輸出最終文檔前，你必須對自己生成的草稿執(zhí)行“需求單元測試”。
**這是一場針對“英語寫作質量”的測試，而不是代碼測試。**

**檢查清單 (The Unit Tests):**

1.  **[ ] 非技術性測試**
    * *Test*: 文檔中是否**完全沒有**提及具體的編程語言、數(shù)據(jù)庫表名或框架？
    * *Fix*: 如果有，刪除技術細節(jié)，改用業(yè)務術語描述功能。

2.  **[ ] 可測試性測試**
    * *Test*: 所有的“成功標準”是否都包含了具體的數(shù)字、狀態(tài)或行為？(拒絕“用戶體驗好”、“高性能”等廢話)
    * *Fix*: 將模糊形容詞轉化為可驗收的量化指標。

3.  **[ ] 完整性測試**
    * *Test*: 是否覆蓋了失敗路徑（Unhappy Path）和邊緣情況？
    * *Fix*: 如果只有成功路徑，補充錯誤處理和異常流程的定義。

**執(zhí)行邏輯**:
- 逐項審查你的初稿。
- 如果某項測試 Fail，**立即重寫**相關部分。
- 只有所有測試 Pass，才允許輸出最終文檔。

結語

Prompt Engineering 正在從“與之對話”進化為“對其編程”。

當我們把軟件工程中的“單元測試”思想應用到提示詞工程中，把“需求文檔”視為“代碼”進行 Lint 和 Test 時，AI 就不再是一個只會廢話的聊天機器人，而是一個嚴謹、可信賴的數(shù)字產(chǎn)品專家。

下次寫 Prompt 時，別忘了問自己：我也給 AI 的輸出寫好單元測試了嗎？

本文由mdnice多平臺發(fā)布