規格先於 agents 寫 code

主張：提示詞不是產品

AI coding agents 很流暢。流暢不是權威。

若只丟一句聊天請求——「加同步」、「讓搜尋更快」、「出桌面版」——agent 會用看似合理的工程填滿每個空隙。它會擴大 API 表面、多加一條「以防萬一」的儲存路徑，並把形容詞當成驗收條件。結果可能編譯過關、通過幾個 tests，卻仍是錯的產品：表面積太大、安全邊界錯了，或你根本無意維護的功能。

NT² Vault 是零知識、本機優先的保管箱。錯誤的範圍不只是白做工，更會威脅你之後無法用一句禮貌 follow-up 提示挽回的不變量。

因此主張狹窄且可操作：

Agents 實作版本化規格。人類擁有那些規格所承載的判斷。

規格是持久契約。聊天是可拋棄的鷹架。若決策只活在 session 逐字稿裡，下一個 agent——或明天的同一個 agent——會發明另一個產品。

本文是 一人如何與 AI agents 共同開發並營運 NT² Vault 之後的流程加深：不是完整生命週期，而是讓 agent 寫 code 對安全敏感產品夠安全的契約形狀。

約束：聊天會蒸發；agents 不會忘記創造力

三股壓力讓「跟 agent 說一聲就好」在保管箱工作上失敗。

Session memory 不是專案 memory。 昨天的對話同意 salt 留在裝置上、雲端驗證是簽名挑戰而非上傳密碼。今天的對話從空白開始。沒有書面切片，agent 會用訓練先驗重推意圖——假設伺服器很「好幫手」的通用 SaaS 模式。

模糊會朝便利膨脹。 「好幫手」的邊緣想要密碼重設、伺服器端搜尋，以及能打開保管箱的支援工具。Agents 在充滿這類功能的程式庫上受訓。若缺少 Non-Goals，agent 會朝錯誤方向「補完」產品。

大型主題不是可出貨單位。 「桌面與行動客戶端」、「共用」、「領域事件」是地圖。把 agent 指向地圖，會半做完每件事、卻什麼都沒驗收完整。你需要可勾選完成的可執行切片。

因此約束不是「多寫文件」，而是：讓 agent 工作的單位小到可驗證，且明確到範圍膨脹無處藏身。

設計：地圖、切片與三段契約

產品敘事與架構另作長壽 context。Agents 對照實作的是功能規格：一個可出貨切片，含目標、取向用的使用者故事，以及比周圍散文更重要的三個區塊。

沒有 Non-Goals 的 Scope 等於准許繼續做下去。沒有 Scope 的驗收條件是沒有課綱的考題。合在一起才是契約：唯有每個 checkbox 為真，且 diff 裡沒有 Scope 之外的東西，agent 才能宣稱完成。

傘狀地圖與子切片

有些能力在同一個產品主題下橫跨多個目標或機制：不同平台的可安裝客戶端、含多種傳遞模式的共用框架、含傳輸與投影的事件模型。把整個主題當成一張 agent 工單會失敗。

我們刻意拆分這些主題：

flowchart TB
  U[傘狀地圖<br/>共用目標與架構]
  U --> A[子切片 A<br/>可執行 Scope 與 AC]
  U --> B[子切片 B<br/>可執行 Scope 與 AC]

傘狀文件是地圖：共用目標、跨切拒絕、架構指標，以及子項索引。它不承載重複的驗收條件。子規格才是單一可出貨切片的可執行契約。實作釘住子規格。傘狀是 context——不是一 PR 做完整個主題的許可證。

不共享傘狀的獨立切片各自有規格。兩種模式都行。在同一份工作上混用——從地圖實作卻假裝子項可選——不行。

文件衝突時的優先順序

當產品敘事、架構筆記與功能切片方向不一致時，agents 需要不依賴魅力的優先清單：

1. 保管箱的硬性安全規則（主密碼永不離開裝置、金鑰不可匯出、salt 僅本機，以及憲章其餘條款）。
2. 當前功能切片——Scope、Non-Goals、Acceptance Criteria。
3. 領域架構與 UX——儲存與畫面如何運作，除非與 (1) 或 (2) 衝突。
4. 產品路線圖敘事——意圖與狀態；若意圖變了，更新切片，而非只依散文寫 code。

若實作暴露切片有錯，在同一變更集更新書面規格。聊天不是正式紀錄。

契約周圍的迴圈

規格化 → 規劃（唯讀）→ 實作 → 對照 checkbox 與自動化關卡驗證 → 人類依 Non-Goals review → 勾選條件並更新狀態後關閉。觸及密碼學、同步或超過少數模組的切片，最需要先規劃再編輯。新的一天或新的 agent thread 開始時重新附上書面切片不是儀式；那是約束創造力的方式。

取捨：起步較慢，較少意外產品

在 agent 第一次改檔之前寫好 Scope、Non-Goals 與 Acceptance Criteria 要花時間。把傘狀拆成子項要更多事前清晰度。人類必須核准模糊之處，而不能指望模型「懂了」。

我們放棄的是：

• 聊天速度的英雄主義——在安全表面上「直接實作」的多巴胺。
• 把傘狀當工單的便利——假裝桌面與行動是同一個「完成」的一句提示。
• 形容詞式驗收——「感覺很快」、「夠好用」、「夠精緻」。
• 沉默的架構漂移——只存在於已合併 PR 描述裡的決策。

我們得到的是：

• 可勾選的完成——reviewer 可走完 checkbox 清單，而不必重推意圖。
• 有界的 diff——Non-Goals 讓過度工程成為違約，而非品味辯論。
• 可交接——下一場 session，無論人類或 agent，讀同一份切片。
• 較安全的拒絕——當 agent 為了「復原」提議密碼託管時，Non-Goals 與安全憲章早已說不。

對一人產品加上 agent 吞吐量而言，昂貴的失敗模式不是「花一小時寫切片」，而是「出貨了三週錯誤的表面，現在必須拆掉一個密碼學假設」。

我們拒絕什麼

我們拒絕在沒有書面切片的情況下依模糊提示實作。 若 Scope 與 Acceptance Criteria 未經核准，寫 code 只是研究表演。

我們拒絕把傘狀地圖當成可執行工單。 地圖定位方向；子項出貨。兩層都複製 AC，條件就會漂移。

我們拒絕空的 Non-Goals。 「邊界以後再想」正是 agents 加上帳單、第二層加密，或把分頁架構打回全表載入 UI 的路徑。

我們拒絕沒有證據就勾選完成。 自動化關卡抓住型別與單元失敗；安全敏感流程仍需人類走一遍解鎖、錯誤密碼、匯出與鎖定。

我們拒絕只活在聊天裡的決策。 若產品意圖變了，儲存庫裡的切片也要變。下一個 agent 不繼承口耳相傳。

我們拒絕為了滿足 checkbox 而「方便地」違反保管箱安全規則。 修正規格或架構筆記。不要教 agent 憲章條款是可選的。

我們拒絕在 PR 中途擴大範圍卻不改寫契約。 新的胃口變成新切片或明確修訂——不是順手塞一個模組。

這些拒絕讓 agent 速度仍相容於雲端層盲目、解鎖材料永不變成伺服器神諭的保管箱。

能熬過下一場 session 的契約

對 NT² 而言，規格驅動開發不是官僚表演。它是讓 agents 快速前進、卻不發明天上 SaaS 閣樓所需的最小結構。

圍繞該結構的營運模型——權威表、核准關卡、安全否決、發布——見 一人如何與 AI agents 共同開發並營運 NT² Vault。本篇是該模型內的契約形狀：地圖對切片，以及 Scope／Non-Goals／Acceptance Criteria 作為「完成」唯一誠實的定義。

若你想要一座讓裝置繼續成為理解秘密之處的保管箱——試試 NT² Vault，或到 nt2.me 了解更多。