[Skills-04] 把反馈环焊进实现：Prototype、TDD、Debug 与 Review

这六个 engineering skill 共享同一个工程信念：Agent 的可靠性不主要来自“想得更久”，而来自更短、更可信的反馈环。原型回答设计问题，测试驱动行为实现，诊断先构造红色信号，审查则对照标准和目标检查最终 diff。

1. prototype：用一次性代码购买信息#

原型只回答一个问题。skill 先在两个分支中选择：

• Logic/state 问题：写一个可交互终端程序，把状态机推过难以纸上推理的案例；
• UI 问题：在同一路由提供多个明显不同的视觉方案，用 URL 参数和切换器比较。

原型规则刻意反生产化：一条命令可运行、默认内存状态、不写测试、不过度处理异常、不抽象。每次操作都展示完整相关状态，让用户能看到变化。

原型代码从第一天就标记为 throwaway。验证后的决定进入正式代码；原型本身可以保存在临时分支作为 primary source，并从 issue 留下 context pointer，但不混进主分支。

2. tdd：先约定 seam，再开始 red-green#

这个 TDD skill 并不追求“每个函数都有单测”。它先要求用户确认测试 seam：系统从哪里被调用，哪些行为最值得稳定验证。测试和生产调用者应跨越同一个 interface。

然后按纵向小循环推进：

一个 seam
  -> 一个从独立事实来源得到期望值的失败测试
  -> 最少实现使其变绿
  -> 根据新认识选择下一个行为切片

它反对三类测试：

• implementation-coupled：mock 内部协作者、测 private method，重构即碎；
• tautological：测试用与实现相同的算法重算期望值，因此永远无法反驳实现；
• horizontal slicing：先写完所有想象中的测试，再批量实现，失去逐轮学习。

这里把 refactor 推迟到 review，而不是塞在每轮 red-green 中。目的不是否定重构，而是让实现阶段保持单一、快速的行为反馈。

3. implement：一个小 orchestration skill#

implement 本身很短：基于 spec 或 tickets 工作，在预先约定的 seam 使用 tdd，完成后运行 code-review，再提交。

短是优点。测试方法和审查规则各有单一事实来源，implement 只负责编排：

读取 ticket/spec
  -> 确认范围和 seams
  -> TDD 实现纵向切片
  -> 双轴 code review
  -> 修复发现
  -> 验证并提交

多 ticket 项目应为每张 ticket 开新 context，避免上一项的实现细节占满下一项的推理空间。

4. diagnosing-bugs：先造一个会红的信号#

这个 skill 最强的判断是：Phase 1 才是 debugging 的核心。如果没有一个能在当前 bug 上稳定失败的 tight loop，读再多代码也容易陷入猜测。

反馈信号按成本从低到高寻找：失败测试、curl 脚本、CLI fixture、headless browser、trace replay、throwaway harness、fuzz loop、git bisect run、新旧版本 differential loop，最后才是需要人点击的结构化脚本。

对 flake，不要求立刻得到 100% 稳定复现，而是先提高发生率：循环 100 次、增加并发与压力、收窄时序窗口。1% 的 bug 难以诊断，50% 的 bug 已经可以做实验。

完整路径是：

1. 构造对该 bug 会 red 的 loop；
2. 复现并最小化输入；
3. 列出带概率和依据的假设，并向用户展示排序；
4. 在能区分假设的位置打断点或加定向 instrumentation；
5. 把最小复现转成 regression test，先看失败，再修复；
6. 重跑原始场景，删除带唯一前缀的 debug logs；
7. 做 post-mortem，判断是否因缺少良好 seam 而需要架构改进。

性能回归走另一条 instrumentation 分支：先基线测量、profile 或 query plan，再 bisect；随手打大量日志通常会污染测量。

5. code-review：Standards 与 Spec 两条轴分开看#

Review 的 fixed point 必须明确，通常使用 git diff <fixed-point>...HEAD 与 merge-base 比较。然后确定两类来源：

• Standards：仓库自己的 coding standards，加 Fowler code smell baseline；
• Spec：原始 issue、PRD 或 spec，检查是否忠实实现目标。

两条轴由不同 sub-agent 并行审查，避免“代码看起来漂亮”掩盖功能缺失，也避免规格符合度影响代码质量判断。输出按严重度、文件位置、理由和建议汇总。

内置 smell baseline 包括 mysterious name、duplicated code、feature envy、data clumps、primitive obsession、repeated switches、shotgun surgery、divergent change、speculative generality、message chains、middle man、refused bequest。它们是启发式，不是机械违规；项目明确标准优先。

6. resolving-merge-conflicts：按意图合并，不按文本二选一#

处理冲突时，先读 merge/rebase 状态、双方 commit、PR 和 issue，找到每一边改变的原始意图。对每个 hunk：

1. 能同时保留两边意图就合成；
2. 意图冲突时选择符合本次 merge 目标的一边，并记录取舍；
3. 不趁冲突解决发明新行为；
4. 完成后按项目顺序运行 typecheck、test、format；
5. stage 并继续 merge/rebase 直到真正结束。

它明确要求不以 --abort 逃避。重点不是保住两段文本，而是恢复一个同时解释两条历史线的有效程序。

7. 六个 skill 的统一视角#

Agent 写代码的速度很快，因而更需要把验证嵌进每一步。没有反馈环的速度，只会更快地产生不可确认的变化。

参考#

• prototype
• tdd
• implement
• diagnosing-bugs
• code-review
• resolving-merge-conflicts