🔧 阿川の電商水電行
朱利安·德安吉利斯本週發表了一篇文章，幾天內瀏覽量就超過了19.4萬次。文章的論點是：人工智慧編碼代理失敗並非因為模型本身有缺陷，而是因為指令含糊不清。
他稱之為規範驅動開發。它包含四個步驟：明確需求、規劃技術實現方案、將需求分解為任務、逐一實現任務。每個步驟都能減少歧義。當開發人員開始編寫程式碼時，他們已經掌握了所需的一切——功能的作用、邊界情況以及測試需要驗證的內容。
這篇文章說得沒錯。問題在於，這種工作流程需要嚴格的紀律，而大多數會議都缺乏這種紀律。在截止日期的壓力下，編寫規範的步驟就被忽略了，你又回到了直接提示的模式。
所以我發展了一項可以幫你寫規格的技能。
沉默決策問題
朱利安的例子讓我印象深刻：
“增加一項功能，用於從後台管理專案。”
代理程式讀取程式碼庫，選擇模式，然後編寫功能。起初看起來一切正常。但當你再次點擊「新增專案」時，它卻插入了相同的項兩次。所有你認為理所當然的假設，其實都沒有出現在提示訊息中。
哪個後台系統－內部後台還是面向賣家的後台？操作是否應具有冪等性？僅限管理員還是所有使用者？使用哪個儲存層？採用哪種錯誤處理策略？
每一個決定都是無聲的。智能體進行猜測。有些猜測是正確的，有些是錯誤的。而你只有在功能上線執行，出現意想不到的異常情況時，才能知道哪些猜測是正確的。
規範的功能在於讓智能體在猜測之前就能看到這些決策。但是，每次會話之前，都要為每個功能從頭開始編寫規範——這種繁瑣的操作會扼殺這種習慣。
首先生成，並內聯標記假設。
規範工具的標準方法是問答式：工具在產生任何內容之前會提出一些澄清性問題。使用者角色是什麼？身份驗證模型是什麼？出錯時該如何處理？
問答環節的問題在於，你必須知道自己不知道什麼。如果你確切知道該問什麼問題，那你離完成規範就差一步之遙了。
spec-writer 採用不同的方法。它會立即產生完整的規範，並標記出所有你未明確指定的、它自己做出的決定：
Given an authenticated user requesting an export
When the export contains more than 1,000 rows [ASSUMPTION: async for large exports]
Then the export is generated asynchronously and the user is notified by email最後，將所有假設匯總成一個優先列表：
## Assumptions to review
1. Async generation for exports over 1,000 rows — Impact: HIGH
Correct this if: your order volumes are low and synchronous is fine
2. Date range filter is required — Impact: MEDIUM
Correct this if: the first version should export all orders with no filtering修改草稿比直接回答問題快得多。 [ASSUMPTION: ...]標籤可以準確地告訴你代理人可能猜錯的地方——甚至在它做出猜測之前。這才是它的價值所在，不是規範本身，而是那些清晰可見的假設。
一個真實的例子
我在我正在開發的一個專案上執行了它——Foundation（我的知識共享專案）的命令列介面捕獲功能。 Foundation 目前透過瀏覽器擴充功能擷取 Claude.ai 的瀏覽器會話。 Claude Code 會話保存在~/.claude/projects/目錄下，30 天後消失。我也需要捕獲這些會話。
提示：
/spec-writer Add CLI capture for Claude Code sessions stored in ~/.claude/projects/以下是部分回傳結果：
依規格說明：
Given a developer with Claude Code sessions in ~/.claude/projects/
When they run the Foundation CLI capture command
Then a list of uncaptured sessions is displayed, sorted by most recent first
Given a session already in Foundation
When the developer runs capture again
Then that session does not appear in the review list
Given a malformed .jsonl file
When the capture command processes it
Then an error is logged for that file and processing continues on remaining sessions根據計劃：
CLI capture runs locally — it needs to read the local filesystem, which
Cloudflare Workers cannot do. [ASSUMPTION: CLI capture is a local Node.js
or Bun script that calls the Foundation API to insert sessions, rather
than a Worker itself]那個假設讓我停了下來。我沒有考慮到架構上的分離——Foundation 執行在 Cloudflare Workers 上，而 Cloudflare Workers 無法讀取本機檔案系統。這項技能在我編寫一行程式碼之前就讓我意識到了這一點。
假設總結：
1. CLI capture is a local script calling the Foundation API, not a Worker
Impact: HIGH
Correct this if: you want a purely serverless approach
2. Manual curation before capture, not automatic bulk import
Impact: HIGH
Correct this if: you want automatic background capture
3. Session ID from .jsonl filename is the deduplication key
Impact: MEDIUM
Correct this if: session IDs are stored differently in your schema
4. No sensitive data scrubbing in v1
Impact: MEDIUM
Correct this if: your sessions contain credentials or keys四個假設，其中兩個影響巨大。架構方面的假設我會在實作過程中遇到。敏感資料方面的假設，直到有人抱怨，我才意識到。
這才是價值所在，不是規格本身，而是其中顯而易見的假設。
它如何融入軟體定義設計（SDD）
spec-writer 能讓你立即進入 Spec-First 階段，無需任何繁瑣的步驟。只需一條命令，即可獲得完整輸出，修正假設，然後交給代理商。
Julián 也描述了兩個更高層次的實作方式。 「規範錨定式」：規範存在於程式碼倉庫中，並隨程式碼一同演進。 「規範即原始碼」：規格是主要工件，程式碼會重新產生以與之相符。如果您想要採用“規範錨定式”，請將輸出儲存到程式碼倉庫中的specs/feature-name.md 。這項技能會產生值得保留的內容。
這套方法論是朱利安的。這項技能是消除摩擦的關鍵。
安裝
mkdir -p ~/.claude/skills
git clone https://github.com/dannwaneri/spec-writer.git ~/.claude/skills/spec-writer然後：
/spec-writer [your feature description]適用於 Claude Code、Cursor、Gemini CLI 以及任何支援 Agent Skills 標準的代理商。同一個 SKILL.md 檔案在所有平台上都適用。
程式碼倉庫位於github.com/dannwaneri/spec-writer。 README檔案中包含完整的輸出格式和一個可運作的範例。
代理程式在執行方面越來越出色。瓶頸始終在於規格——需要足夠精確地了解要建立的內容，以便代理程式無需猜測。規範編寫器並沒有消除這項要求，而是加快了滿足該要求的速度。
規範並非輸出結果，假設才是。
基於規範驅動開發（Spec Driven Development）方法論－由GitHub Spec Kit和OpenSpec等工具實作－建構而成。 Julián Deangelis 在 MercadoLibre 上發表的 SDD 的文章是直接的靈感來源。
其他技能：語音人聲化器－檢查你的文字是否符合你自己的聲音，而不是通用的人工智慧模式。
原文出處：https://dev.to/dannwaneri/i-built-a-skill-that-writes-your-specs-for-you-1o2n
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
