Agent Skills 工程化实践 10：实现、测试、诊断、原型与研究是五种反馈回路

不同问题需要不同的“变红方式”

Agent 最危险的工作状态不是能力不足，而是没有可靠反馈：它修改文件、解释原因，却无法证明行为真的发生了变化。这五个 Skills 分别处理五种 feedback need：

• implement：已有 spec/tickets，如何完成并交付；
• tdd：行为可以通过稳定 public seam 被测试；
• diagnosing-bugs：根因未知，需要从 exact symptom 建立反馈；
• prototype：设计问题必须靠可运行 artifact 才能回答；
• research：外部事实必须回到 primary sources。

implement：编排一次有边界的交付

触发方式：User-invoked。 传入 spec 或 tickets：

/implement #128

它要求按既定 seams 使用 tdd，持续执行 typecheck 和相关测试，末尾运行完整 suite，再用 code-review 检查工作并提交到当前 branch。它是 orchestration skill，不负责重新发明 scope。

调用前最好满足三项条件：输入 artifact 足够明确；当前 branch 与允许修改范围已确认；测试 seam 已在 spec 阶段达成共识。否则 implement session 会把需求澄清、架构设计和代码生成塞进同一 context，review 时很难判断偏差从哪里开始。

上游 Skill：implement

tdd：通过 public interface 验证 behavior

触发方式：Model-invoked。 可以明确要求：

请用 tdd 实现购物车优惠规则，每次只推进一个 vertical slice，先展示 failing test。

它的循环是 red → green → refactor，但真正约束是测试质量：测试通过 public interface 验证 observable behavior，读起来像 specification，能在 implementation 完全重写后继续成立。

高层 seam 通常比 private helper 更有价值。Mock 只应该隔离真正的 external boundary；大量 mock 内部 collaborator 会让测试证明“代码按当前写法调用了自己”，而不是产品行为成立。每轮先确认 test 因正确原因失败，再写 minimal implementation，避免一口气预写一套 imagined behavior。

上游 Skill：tdd

diagnosing-bugs：先让 exact symptom 稳定变红

触发方式：Model-invoked。 用户说 diagnose、debug、broken、slow 等场景时应触发：

请用 diagnosing-bugs 定位结算接口偶发 2 秒超时；先建立可重复 feedback loop，不要直接修。

核心阶段是：feedback loop → reproduce → minimise → ranked hypotheses → instrumentation → fix + regression test。每个 hypothesis 必须 falsifiable，并写出 prediction；instrumentation 只服务于 prediction，结束后清理。

v1.2.3 特别补上了 secret redaction：展示命令、输出和 captured artifacts 前先把 credential 替换为 <REDACTED>，让 loop 从环境变量取 secret，只引用 artifact 中携带 signal 的行。调试便利不能成为泄露 auth headers 的理由。

不要使用的情况： 明确的 typo 或已有 failing test 的简单修复不需要完整 diagnosis ceremony。它为 hard bugs 和 performance regressions 设计，不是所有 bug 的强制前置。

上游 Skill：diagnosing-bugs

prototype：用 throwaway code 回答一个设计问题

触发方式：Model-invoked。 先明确问题属于哪一支：

请用 prototype 验证审批状态机在撤回、重开和并发审批下是否可理解。

• logic/state 问题：生成一个可分享的单文件 HTML，包含自由操作与 guided walkthrough；
• UI 问题：在同一路由提供多个差异足够大的方案，用 query param 与浮动切换栏比较。

prototype 的完成条件是得到 decision，不是接近 production。默认不做 persistence、不接真实 backend、不追求完整 design system。验证后的结论回到 spec、ADR 或真实实现；throwaway code 不应因为“已经能跑”就偷偷成为产品底座。

上游 Skill：prototype

research：把外部事实交给后台代理

触发方式：Model-invoked。 当问题需要官方 docs、源码、spec 或 first-party API：

请研究 Cloudflare Pages 当前对 Astro 构建的 Node 版本要求，只用官方来源，并把结论写入 repo 的 research note。

它要求启动 background agent，使主线程可以继续工作；研究代理把结论写入单个 cited Markdown。每个重要 claim 要追溯到拥有该事实的 primary source，而不是引用二手教程。

它的产物是 evidence，不是 decision。版本、限制和行为被核实后，仍要由产品或工程负责人决定采用什么方案。研究笔记应写明 baseline 与核验日期，避免把今天的 main、Latest Release 和 package version 混成一个“最新”。

上游 Skill：research

选择反馈回路，而不是选择最熟悉的工具

已有明确交付输入       → /implement
行为可被自动测试       → tdd
根因未知且症状可复现   → diagnosing-bugs
必须看见或操作才知道   → prototype
答案属于外部事实       → research

一次工作可能经过多个回路，但不要把它们同时启动。先判断当前最大的不确定性是什么，只建立能让它变红的最小系统；得到证据后，再进入下一 phase。

来源与版本

• 上游参考：README Why These Skills Exist
• Release 安全修复：v1.2.3
• 参考分支：main · 核验 commit：8b78b53 · 核验日期：2026-08-14