Agent Skills 工程化实践 04：从 ticket 到可审阅的 commit

实现不是“让模型改完文件”

在这套 Skills 里，implement 的职责很窄：接收已经确定的 spec 或 ticket，在约定的 seam 上完成一个 vertical slice，持续获得反馈，建立 review checkpoint，审阅后再形成最终 commit。

它不会重新 interview，也不会把多个 tickets 混在一个 session 里。这个限制看似保守，实际上是在保护 context：一个 session 只需要记住一条用户可验证的路径。

tdd 的核心是 red-green，而不是测试数量

tdd 把实现节奏收缩为：一个 seam、一个 failing test、一个 minimal implementation，然后重复。

好的 test 通过 public interface 验证 behavior，读起来像一条 specification。它不应该 mock 内部 collaborator，不应该测试 private method，也不应该按照实现本身重新计算 expected value。代码可以重写，测试仍然应该只关心用户能观察到的结果。

这也是为什么仓库强调 vertical slice：先写完所有 tests，再写完所有 implementation，会过早锁定一套 imagined behavior；一条条 tracer bullet 则允许每个 cycle 根据上一轮反馈调整。

seam 决定反馈是否可信

seam 是可以观察 behavior 的 public boundary。测试不是越靠近函数越好，而是要靠近真实调用路径，同时保持对 implementation 的独立性。

开始前最好先写下：哪些 module 的哪个 public interface 是这次工作真正要验证的 seam？如果 interface 形状本身不清楚，先用 codebase-design 的 module、interface、depth、adapter 和 locality 词汇把问题讲清楚，而不是随手创建一个浅薄的测试边界。

review checkpoint 为什么不能省

这个仓库把 committed diff 当作审阅边界。working tree 里的修改还可能被继续改写，无法稳定地回答“刚才审的到底是哪一版”。因此 implement 的收尾顺序是：

red → minimal green → 持续 typecheck/tests
  → review checkpoint commit
  → code-review <fixed-point>
  → 修复 findings
  → final commit

如果 review 发现问题，就在同一 fixed point 上重新跑。这样每一轮报告都对应明确的 diff，而不是一段会随时间漂移的本地状态。

code-review 的两个轴

code-review 不把“代码风格”和“需求正确性”揉成一个分数，而是并行检查两个轴：

• Standards：是否遵守 repo 的 documented standards，同时检查常见的设计 smell；
• Spec：是否真的实现了 originating issue 或 spec 的要求，是否有 scope creep。

一个 change 可能完全符合工程规范，却漏掉了用户需求；也可能功能都做对了，却引入了让 codebase 更难维护的结构。双轴报告保留了这两种失败的独立性。

一个轻量的交付门禁

在把 ticket 标记为完成前，可以检查：

1. failing test 是否真的对应用户 behavior，而不是附近的另一个 failure？
2. 本次 session 是否只完成一条 vertical slice？
3. typecheck、单文件测试和完整 suite 是否按节奏运行？
4. review 是否针对 committed diff，而不是未提交修改？
5. finding 是否能追溯到 standards 或 spec，而不是泛泛的偏好？

我的判断是，Agent 写代码的速度已经不是主要瓶颈；可验证的节奏才是。把 red-green、checkpoint 和 review 固定下来，交付就从“模型生成了一堆 diff”变成了“团队接受了一条有证据的 change”。

来源与版本

• 实现流程：implement
• 测试纪律：tdd
• 双轴审阅：code-review
• 参考分支：main · 核验 commit：022fcc3 · 核验日期：2026-08-12