giboulz

我是一名 Scrum Master，十年前曾是開發者。我擁有足夠的背景能與 LLM 討論設計與取捨——但三個月前，我對自己的獨立專案做了一個刻意的賭注：我永遠不會閱讀程式碼。

規格定義測試。測試控制程式碼。程式碼就是一個黑箱。

我並不是說這是每個人該做的事。但這是我的賭注，而它迫使一個系統誕生：當沒有人閱讀程式碼時，流程就必須承擔原本由閱讀程式碼的人類所提供的信任。我剛把這個系統以參考實作的形式發布：backlog-as-data——完整的說明、翻譯成英文的 Claude Code skills，以及 CLI 原始碼，原封不動地來自我日常的設定。

以下是簡短版本。

待辦清單是 git 資料，而非文件

大多數代理任務管理工具會把任務存放在專屬位置——例如 tasks.json、資料庫，或 backlog/ 資料夾。我的賭注不同：待辦清單就是規格檔案的 YAML frontmatter。 每張票據一個檔案，而票據的狀態是一個欄位——永遠不是文件中的位置。 

---
id: PARSE-07
title: Tolerate CRLF in decklist import
type: ticket
status: todo
priority: should
exec:
  model: sonnet
  effort: think
  review: light
  matured: 2026-07-22
---

# PARSE-07 — Tolerate CRLF in decklist import

The spec body: design, contracts, test cases. The ticket file IS the spec.

Enter fullscreen mode Exit fullscreen mode

frontmatter 下方的所有內容就是規格——由 LLM 在它挑戰過我對話中表達的需求後撰寫。frontmatter 是資料——由小型 CLI 擁有，只能透過它進行變更。同一份檔案，所以它們永遠不會分離。

為什麼這很重要：「移到 Done」不是一項操作。LLM（與人類）在狀態變更意味著搬移文字時，會破壞文件。讓狀態成為一個欄位，使得每一次轉換都變成單行、冪等、可測試的變更。我所查看的看板（我伺服器上的一個小型網頁，附有指向各個規格的 GitHub 深度連結）以及可讀的 markdown 檢視，都是產生的投影，由「請勿編輯」哨兵鎖定，並由一致性測試覆蓋。

成熟化：以資料形式為每張票據決定模型、努力程度與審查深度

認領一張票據，以及決定要多努力思考它，是兩件分開的事。在任何代理人執行前，一張票據會以一個三元組進行成熟化：

  • model — 由哪個模型實作它（haiku → fable）
  • effort — 注入提示中的推理深度
  • review — 審查閘道的用量：none、light（1 位審查者）、deep（3 位）

一次微不足道的重新命名會得到 haiku / none / none。一次不可逆的資料遷移則會使用最強大的模型、最大推理量，以及三位審查者。這個決定會隨票據一起版本化，並可在數月後稽核（matured: <date>）。而實作者子代理人會精確地執行已成熟化的模型——它的報告必須以 Model used: … 開頭，以便事後驗證決定。

這是精實思考應用在代理預算上：根據缺陷溜掉的成本，按比例支付缺陷偵測的費用。

生命週期由 hooks 應用，而非任何人的記憶

todo → wip → merged → shipped 是由附加到我工作流程指令的 hooks 所設定——launch 設定 wip，integration 設定 merged（僅限於其 feat(TICKET-ID): commit 確實在分支上 的票據），deploy 設定 shipped。沒有人——人類或代理人——能手動移動生命週期的後半段。這些 hooks 永遠以 0 結束（生命週期自動化絕不能阻擋交付），並以精確方式 commit（一個有 10 個以上平行 worktree 的共享 main 檢出，曾教訓我 git add specs/ 會掃到鄰近 session 的工作——這是慘痛的經驗，有日期可循）。

審查閘道：一無所知的審查者

這是我在其他地方沒看過的部分。當實作者子代理人完成（在它自己獨立的 git worktree 中）後，orchestrator 會產生全新情境的審查者：它們只拿到票據 ID、規格路徑、worktree、commit SHA，以及四個審查軸。沒有其他任何東西。 沒有實作者做了什麼的摘要，也沒有提示該看哪裡。污染審查者的情境是確認偏誤的主要來源。

三個經歷事件才學到的細節：

  • 審查的證據是由 orchestrator 產生，而非被它稽核的實體。 實作者不知道用量，從未看到審查者提示，也無法證明任何關於審查的事。SHA 是以程式方式從 git 讀取（曾有一次手抄的 SHA 少了一個字元，共 39 個字元），且 git status 會在審查前後檢查。
  • 發現只有兩種出口：已修正，或附帶理由升級（規格錯誤／既有債務／修正會破壞綠色測試）。「不是什麼大問題」不是一種處置。
  • 審查者只回報發現——沒有讚美。 一份寫著「其他一切都符合」的報告會製造虛假的信心。它曾伴隨一份宣告「符合」的報告，而那份報告恰恰漏掉了一個缺陷。

這有用嗎？在發布前一天，我對已發布的儲存庫本身執行了這個閘道：一位全新審查者比較了我的英文翻譯與法文原文，並提出了 3 項發現——其中包括一個翻譯錯誤的計數器，如果使用英文版本，任何人的審查紀錄都會被靜默破壞。這個閘道在首次公開亮相時就收回了成本。

人類實際上做了什麼

我每張票據的三個接觸點都是決策，而非操作：同意需求（在對話中——LLM 會挑戰我，然後撰寫規格）、說「成熟化並執行它」（附帶審查用量），以及決定部署。其間的一切——CLI 呼叫、規格撰寫、代理人編排、整合——都是代理人的工作。我從不輸入任何待辦清單指令。CLI 是面向代理人的：確定性來自代理人沒有手動編輯途徑，而不是我做簿記。

我不主張什麼

  • 你應該停止閱讀程式碼。這是我的賭注，在我的獨立專案上，用我的風險配置。
  • 這是一個產品。這是從一個運作中的設定中提取出來的參考實作——閱讀它、竊取想法、調整片段。README 有一節說明哪些部分移植性良好。
  • 這個系統已經完成。它最大的未解問題在 README 中誠實地寫著：其中的每一條規則都來自我習慣進行的專案事後檢討——這項技能尚未觸發它自己的改進迴路。

如果你每天都在執行程式設計代理，而你的待辦清單仍然是一份每次代理人「移到 Done」就會被破壞的 markdown 待辦清單——那麼光是資料模型就值得一讀：github.com/giboulz/backlog-as-data。

很樂意在評論區回答任何問題——包括「從未閱讀程式碼」的賭注是否已經燒到我。