判断这次 AI 改动能不能交付
AI Coding 降低了写代码成本，也把验证变成了主要工作。你让 Claude Code 或 Codex 改一个 Nuxt 页面，它很快能补组件、改样式、加字段。真正要花脑子的地方在后面：它改了哪些文件，为什么改这些文件，哪些路径没有被测到。
把一次 AI 修改拆成两段。第一段让 Agent 写代码，第二段让 Agent 证明这次修改能交付。两段混在一起时，Agent 容易用一句“已完成”替代验证。
让 Agent 先说修改范围
动手前先让 Agent 说明它准备读哪些文件、改哪些文件、跑哪些命令。你不用让它写长计划，只要把修改边界说清楚。
这个动作能拦住两类问题：顺手重构、用旧经验猜项目命令。真实项目里，后者很常见。比如仓库规定用 pnpm，Agent 仍然可能给出 npm 命令。
先阅读首页、文章列表和文章详情页相关代码，不要改文件。
请输出：
1. 你需要阅读的文件
2. 你认为最小修改范围
3. 修改后要运行的验证命令
4. 你不确定、需要我确认的地方对照 diff 查任务外改动
页面能打开不代表改动可信。先看 diff，比先看截图更重要。diff 会告诉你 Agent 有没有动任务外文件、有没有改配置、有没有把临时调试语句留在代码里。
看 diff 时先抓四件事：
如果 diff 里出现你没要求的重构，先让 Agent 解释原因。解释不清，就回退那部分。
- 是否只改了任务需要的文件
- 是否动了路由、配置、依赖或数据结构
- 是否删掉了现有边界状态
- 是否把用户已有改动一起改掉
要求 Agent 跑出验证结果
不要接受“我检查过了”。让 Agent 报告具体命令、结果和失败分支。能跑自动化检查就跑自动化检查；没有测试时，也要给一个最小手动验证路径。
对于 Nuxt、Vue、TypeScript 项目，至少让 Agent 回答三件事：页面路由是否存在，关键数据是否能渲染，移动端或空状态有没有坏。
改完后请报告：
1. 修改了哪些文件
2. 为什么这些文件属于最小修改范围
3. 运行了哪些验证命令
4. 每条命令的结果
5. 没有运行的验证和原因没有测试时按页面手动检查
很多个人项目没有完整测试。这个时候别让 Agent 空口保证。让它给出你能在浏览器或命令行里完成的最小验证。
最小验证不需要庞大。比如新增文章时，检查文章列表是否出现、详情页是否能打开、相关文章是否有真实目标、移动端首屏是否没有遮挡。这个检查比“页面看起来还行”更接近交付。
| 文章列表 | 新标题、摘要、标签和日期出现 |
| 文章详情 | H1、文章信息、最后审校、目录和相关文章出现 |
| 移动端 | 标题和卡片不溢出，侧栏内容不压正文 |
| 链接 | 相关文章和外部参考都能打开 |
把固定要求写进规则文件
如果你每次都提醒 Agent “用 pnpm”“不要乱改文件”“改完报告验证”，就把这些规则写进 `AGENTS.md` 或 `CLAUDE.md`。项目规则文件的价值不在于形式，而在于减少同一类错误反复出现。
Codex 项目优先写 `AGENTS.md`。Claude Code 项目优先写 `CLAUDE.md`。两个工具都用时，两份文件可以共享同一组核心规则，但不要把工具专属命令写混。
Rules:
- Use pnpm only.
- Keep edits scoped to the requested task.
- Read relevant files before editing.
- Do not refactor unrelated files.
- Report changed files and verification results.
- Mention commands that were not run.工具报错时先修接入链路
验证链路跑不起来时，先区分项目问题和工具接入问题。如果 Codex 识别不了某个参数，回到 Codex CLI 配置指南和具体错误日志。如果 Claude Code 接第三方模型后报 404、model not found 或 unsupported parameter，先回到 Claude Code 配置指南和 DeepSeek 接入笔记。
AI Coding 最容易浪费时间的地方，是把工具接入问题当成代码问题。先让工具链稳定，再让 Agent 改项目。
交付前按这 5 项过一遍
每次让 AI 改完代码后，先做这组检查。任务小，也不要跳过前两项。
- 看 diff，只接受任务范围内的改动
- 看验证命令，确认命令真实运行
- 看失败分支，区分未运行、运行失败和功能失败
- 看页面或接口的尾部状态，不只看平均路径
- 把重复提醒沉淀到 `AGENTS.md` 或 `CLAUDE.md`