giboulz

我是一名 Scrum Master。十年前我曾是一名开发者。我有足够的背景与 LLM 讨论设计和权衡——但三个月前，我对我的个人项目做出了一个深思熟虑的赌注：我将永远不阅读代码。

规格定义测试。测试控制代码。代码是一个黑箱。

我并不是说这是每个人都应该做的。但这是我的赌注，它迫使一个系统诞生：当没有人阅读代码时，流程必须承载通常由阅读代码的人类提供的信任。我刚刚将该系统作为参考实现发布：backlog-as-data——完整的说明、翻译成英文的 Claude Code 技能，以及 CLI 源代码，原封不动地来自我的日常设置。

以下是简要版本。

待办清单是 git 数据，而不是文档

大多数代理任务管理工具将任务存储在专用位置——一个 tasks.json、一个数据库、一个 backlog/ 文件夹。我的赌注不同：待办清单就是我的规格文件的 YAML 前言。 每个工单一个文件，工单的状态是一个字段——永远不是文档中的位置。

---
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

前言以下的所有内容都是规格——由 LLM 在对话中挑战我表达的需求后编写。前言是数据——由一个小的 CLI 拥有，只能通过它进行修改。同一个文件，所以它们永远不会分离。

为什么这很重要：“移至 Done”不是一个操作。LLM（和人类）在状态变更意味着移动文本时会破坏文档。将状态设为字段，使每次转换都成为一行、幂等、可测试的修改。我查看的看板（我服务器上的一个小网页，带有指向每个规格的 GitHub 深度链接）和可读的 markdown 视图是生成的投影，由“请勿编辑”标记锁定，并由一致性测试覆盖。

成熟度：按工单决定模型、努力程度和审查深度——作为数据

承诺一个工单和决定思考它的难度是两个独立的行为。在任何代理运行之前，一个工单会通过一个三元组进行成熟度处理：

  • model — 哪个模型实现它（haiku → fable）
  • effort — 注入到提示中的推理深度
  • review — 审查门的剂量：none、light（1 个审查者）、deep（3 个）

一个简单的重命名获得 haiku / none / none。一个不可逆的数据迁移获得最强大的模型、最大推理和三个审查者。该决策与工单一起版本化，并在几个月后可审计（matured: <date>）。实现子代理运行完全成熟的模型——它的报告必须以 Model used: … 开头，以便事后验证该决策。

这是精益思维在代理预算中的应用：根据缺陷溜走的成本，按比例支付缺陷检测费用。

生命周期由钩子应用，而不是依靠任何人的记忆

todo → wip → merged → shipped 由附加到我的工作流命令的钩子设置——启动设置 wip，集成设置 merged（仅针对其 feat(TICKET-ID): 提交实际在分支上的工单），部署设置 shipped。没有人——人类或代理——手动移动生命周期的后半部分。钩子总是退出 0（生命周期自动化绝不能阻塞交付），并且以外科手术方式提交（一个共享的主检出有 10+ 个并行工作树，这教会了我 git add specs/ 会扫到邻近会话的工作——这是我从惨痛教训中学到的，并附上了日期）。

审查门：一无所知的审查者

这是我在这里没见过的部分。当实现子代理完成（在它自己的隔离 git 工作树中）时，编排器会生成新上下文审查者：他们获得工单 ID、规格路径、工作树、提交 SHA 和四个审查轴。仅此而已。 没有实现者做了什么的摘要，没有该看哪里的提示。污染审查者的上下文是确认偏误的主要途径。

我从事故中学会的三个细节：

  • 审查的证据由编排器产生，而不是由它审计的实体产生。 实现者不知道剂量，从未见过审查者提示，也不能证明任何关于审查的事情。SHA 是通过程序从 git 读取的（曾经有一个手抄的 SHA 只有 39 个字符），并且在审查前后检查 git status。
  • 发现只有两个出口：已修复，或带有理由的升级（规格错误 / 预存债务 / 修复破坏了绿色测试）。“不是大问题”不是一种处理方式。
  • 审查者只报告发现——没有赞扬。 一份说“其他一切都符合”的报告会制造虚假的信心。它曾经伴随一份报告，该报告宣布符合它未能发现缺陷的决策。

它有效吗？在发布前一天，我在已发布的仓库上运行了该门：一个新的审查者比较了我的英文翻译和法文原文，并提出了 3 个发现——包括一个错误翻译的计数器，如果跟随英文版本，可能会无声地破坏任何人的审查寄存器。该门在首次公开亮相时就收回了成本。

人类实际在做什么

我每个工单的三个接触点都是决策，而不是机械操作：同意需求（在对话中——LLM 挑战我，然后编写规格），说“成熟它并运行它”（带审查剂量），以及决定部署。介于两者之间的一切——CLI 调用、规格编写、代理编排、集成——都是代理的工作。我从不输入待办清单命令。CLI 是面向代理的：确定性来自于代理没有手动编辑路径，而不是我做簿记。

我不声称什么

  • 你应该停止阅读代码。这是我在我的个人项目上，根据我的风险状况做出的赌注。
  • 这是一个产品。它是从一个工作设置中提取的参考实现——阅读它，窃取想法，调整部分。README 有一个部分专门说明哪些部分移植得很好。
  • 该系统已经完成。它最大的开放问题是 README 中诚实地承认的：其中的每条规则都来自我习惯进行的意外回顾——该技能尚未触发自己的改进循环。

如果你每天都在运行编码代理，而你的待办清单仍然是一个每次代理“将某物移至 Done”都会被破坏的 markdown 待办列表——数据模型本身可能值得一读：github.com/giboulz/backlog-as-data。

很乐意在评论中回答任何问题——包括“从不阅读代码”的赌注是否已经让我吃苦头。