日常开发中，代码主要由 AI Agent 编写。我负责提出需求、补充上下文、确认方案和检查结果。
实际使用 AI 开发时，我遇到过一些问题：Agent 对需求理解有偏差，Bug 还没定位根因就开始修改，代码能运行却有遗漏，甚至多次检查后仍出现新问题。
我希望把这些容易出问题的环节变成相对固定的工作步骤：分析问题时要有依据，修改代码时要有测试，完成任务时要拿出验证结果。为此，我使用五个 Skill，并把需要固定执行的规则写进 AGENTS.md。
每个环节都可以不用 skill，自己写提示词来让 AI 做同样的事，但我选择安装使用别人精心编写、反复验证过效果的 skill。
五个 Skill 的分工
| Skill | 主要作用 | 使用阶段 |
|---|---|---|
think | 分析方案、风险和取舍 | 开发前 |
hunt | 复现问题并定位根因 | Bug 修复前 |
tdd | 按测试驱动的循环实现代码 | 编写代码时 |
check | 检查变更、验证结果和潜在问题 | 代码修改后 |
code-review | 从项目规范和原始需求两个角度审查 | 按需追加审查 |
这些 Skill 分别约束不同环节。它们提供的是执行方法，实际结果仍要通过代码差异、测试输出和需求验收来确认。
开发流程
- 功能开发、修改：
think写或分析方案（按需） → 人工确认 → Agent 按tdd开发 →check→code-review（按需）。 - Bug 修复：
hunt定位根因 → Agent 按tdd修复 →check→code-review（按需）。
简单、明确的任务可以直接进入开发。复杂任务先确定方案和验收标准，避免 Agent 在实现过程中反复改变方向。think 和 code-review 都按需要使用；tdd 与 check 的调用规则写进了 AGENTS.md。
开始开发前
需求或方案不明确时，我主动让 Agent 调用 think，结合现有代码分析可选方案、风险和实施步骤。它会给出推荐方案，说明为什么这样选、放弃了什么，以及如何验证。我确认方向后再实施。明确的小任务可以跳过 think。
遇到 Bug 时，先调用 hunt，结合代码、日志和复现结果定位根因。Agent 会说明根因在哪里、哪些证据支持这个判断，以及怎样复现和验证。确认后再进入修复阶段，避免只针对表面症状反复修改。
编写和验证代码
我在 AGENTS.md 中要求：编写或修改代码前，必须先调用 tdd Skill。Agent 先提出需要测试的接口或行为边界，经我确认后，按 Red → Green → Refactor 的循环开发：写一个失败测试、实现最小代码使其通过，再整理代码。
确认测试边界会增加一次人工交互，尤其是小任务。我主要关注核心业务行为和容易出错的边界，避免为了覆盖每个实现细节而写大量脆弱的测试。不适合 TDD 的改动可以跳过，但 Agent 必须在最终回复中说明原因。
代码修改完成后，Agent 自动调用 check。它会结合改动范围和风险检查代码差异、测试结果及潜在问题。发现问题后，Agent 修复并重新验证，直到相关检查通过，或明确说明仍有哪些问题无法解决。
我遇到过多轮 check 和代码审查仍持续出现新问题的情况。此时需要留意每轮修复是否扩大了修改范围、测试是否覆盖原始问题，以及新问题是否暴露出方案上的缺陷。重复执行检查本身不能保证结果正确。
代码审查
对于改动较大、涉及核心业务或容易遗漏边界条件的任务，我通常会在 check 后调用 code-review。它会发起两个 SubAgent 从两个角度审查修改：
- Standards：代码是否符合项目规范，是否有明显的设计问题。
- Spec：实现是否满足原始需求，是否有遗漏或额外改动。
两个 Skill 都可能检查代码问题，但关注点和使用方式有区别：
check | code-review | |
|---|---|---|
| 关注点 | 变更是否合理，验证结果是否可靠，还有哪些风险 | 是否符合项目规范，是否完整满足需求 |
| 使用方式 | 每次代码修改后自动执行 | 根据改动规模和风险追加 |
| 主要依据 | 当前差异、测试与构建结果、项目上下文 | 指定的 Git 比较基点、项目规范和原始需求 |
交付结果
开发完成后，Agent 会说明修改了什么、执行了哪些测试或检查、结果如何，以及是否存在未解决的问题。
| 要确认的问题 | 希望看到的证据 |
|---|---|
| 修改范围是否符合预期？ | 变更文件和关键差异，是否包含无关修改 |
| 需求是否已经实现？ | 对照验收条件的结果、关键场景测试 |
| 修改有没有引入问题？ | 测试、构建和 check 的实际执行结果 |
| 还有什么不确定？ | 未执行的验证、已知风险和待处理事项 |
涉及复杂业务时，我会再对照原始需求逐项验收。无法执行的测试需要明确说明，不能只用“已完成”代替验证结果。
我目前的取舍
- 默认开 auto mode/full access：减少人工确认的次数，在开发前多花心思减少越界的可能。
- 不用 plan mode：think 已经覆盖 plan mode 的功能，并且能处理更复杂的情况，较轻量的任务也不会研究过深、过久。
- code-review：如果 Harness 自带也可以用自带的命令，比如 Codex、Claude 就有。
AGENTS.md
下面是我目前使用的三条固定规则：
- 提供多个解决方案时，按推荐程度降序排列并标记。
- 每次代码修改完成后自动执行
checkSkill；check发现问题并修复后，需要重新验证。 - 开始编写或修改代码前，必须先调用
tddSkill，遵循 Red → Green → Refactor 开发流程。Bug 排查应先定位根因，再进入 TDD 实施阶段。跳过时必须在最终回复中说明原因。
Skills
Agent Harness 和模型推荐
优先级从上往下
- Claude/Claude Code + Opus 5.5 High
- Codex + Sol Medium/High
- DSH/Pi + DeepSeek-Flash High/Max
- ZCode + GLM-5.3 Max
我在用的 Skill
npx skills add -y -g https://github.com/tw93/waza --agent universal claude-code
# <https://github.com/mattpocock/skills/tree/main/skills/engineering>
npx skills add -y -g https://github.com/mattpocock/skills --skill code-review --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill codebase-design --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill domain-modeling --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill grill-with-docs --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill improve-codebase-architecture --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill prototype --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill research --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill retro --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill tdd --agent universal claude-code
# <https://github.com/mattpocock/skills/tree/main/skills/productivity>
npx skills add -y -g https://github.com/mattpocock/skills --skill grill-me --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill grilling --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill handoff --agent universal claude-code
npx skills add -y -g https://github.com/mattpocock/skills --skill wait-what --agent universal claude-code
npx skills add -y -g https://github.com/JimLiu/baoyu-design --agent universal claude-code
npx skills add -y -g https://github.com/JimLiu/baoyu-skills --skill baoyu-image-gen --agent universal claude-code
npx skills add -y -g https://github.com/Dietrichgebert/ponytail --skill ponytail-review --agent universal claude-code
我的全局 AGENTS.md
## Preferences
- 用简体中文回复。
- Please remove all mannered prose.
- talk in ASD-STE100 Simplified Technical English.
## 通用规范
- 给多个方案时，按推荐程度降序排列，标出推荐项。
- 改对外行为、接口、配置或操作步骤后，更新受影响的文档。文档仍准确时不改。
- 审查后改的代码不 git add。不擅自提交、推送、部署。用户明确要求时除外。
- 代码修改完成后跑一次 check。修完审查问题只检查新增改动，重跑相关验证。不重复完整审查。
- 外科手术式改动：只做任务要求的事，匹配现有风格，不动没碰到的存量代码，不为单次使用或不可能的场景写代码和配置。
- 动手前查错误前提、逻辑跳跃、信息缺失、隐含假设。我判断不对时直接说，给出依据、风险和更合适的做法。区分事实、预测、主观观点。提醒我可能忽略的变量、成本和偏差。
- 没有可核实证据，不声称完成。无法验证时如实说明。禁止编造证据。
## 测试规范
- 写或改代码前调用 tdd Skill，走 Red → Green。Bug 先定位根因。跳过时在最终回复说明原因。
- 没法写测试的功能，给可重复执行的验证方案。
- 排查时只读，不改业务数据库。自动化测试只写已确认隔离的测试库。
- 审查时检查测试用例，排除同义反复测试（tautological tests）。
## 数据库规范
- 新字段加到表末尾。
- 判断数据是否存在时，先看软删除字段。
- 未要求处理存量数据时，只报告问题。处理方式和写库权限按当前任务授权。
- 排查数据问题，先确认环境是本地还是生产。