Claude Code 不照审计报告做：6 个降为「建议」的原因 + 把报告变成 Tasks

你给了详细 audit report，Claude Code 我行我素——它把报告当 context 不当 contract。转成编号 Tasks、一次一条执行、终点 diff 对账。

发布于: 2026/05/17 更新于: 2026/06/15 作者: AI Productivity Guide Team 🌐 查看英文版本

你把一份 4 页的 audit report 贴进 prompt，说「按这个全改了」就走开。回来发现：Claude 改了 14 条里的 3 条、还编了 2 条不在 report 里的「改进」、动了你没让它动的目录结构、最高优先级那条根本没碰。你花一小时写的 report 现在成了考古文物。

最快修法： 别再把报告整块贴进去。存成 AUDIT.md，让 Claude 读完后用 TaskCreate 给每一条建一个 Task，再一条一条执行。Claude Code 原生的 Tasks 系统（v2.1.142 起为默认，取代了旧的 TodoWrite todo 列表）会按 ID 跟踪每一条、落盘持久化、随时能告诉你哪些还是 pending——这正是一团贴进去的文本缺的那份「问责机制」。

根因：Claude 把长 unstructured 输入当 context——做决策的背景信息——不当 contract——必须逐条执行的清单。没有显式绑定（「执行 AUDIT.md 第 N 条」），它读完报告、做自己的 plan，你的原清单就悄悄降级成「建议」。修法就是把清单变成一份结构化、可按编号寻址的产物，并把执行绑定到每一条。

你属于哪一类？

症状	最可能的原因	跳到
有些条目压根没做	报告太长，Claude 自摘要了	原因 1、Step 1 + 3
Claude 自己重排了优先级	prompt 没绑到编号	原因 2、Step 2
一个 bullet 只做了一半	一个 bullet 塞了多件事	原因 3、Step 1
Claude 选了你没选的方向	报告自相矛盾	原因 4、Step 4
已完成的又被动了、待办反被跳过	「现状」和「待办」混在一起	原因 5、Step 1
做的是通用修法不是真问题	条目引用了 Claude 打不开的 ticket/URL	原因 6、Step 6

常见原因

按命中率从高到低。

1. 报告太长，Claude 略读 + 自摘要

报告超过约 2 页，Claude 没法在工作注意力里把每一条都全保真地端着——它会对输入做摘要、按摘要工作。和 context window 被压缩（/compact）后的有损摘要是同一个问题，只是这次从第一轮就自己造成了。

如何判断： 让 Claude「列出报告里所有条目，编号」，对照原报告——缺的条目就是被摘掉的。

2. Prompt 说「用这份报告」没绑具体条目

「用这份报告」告诉它是什么，没告诉它怎么做每一条。Claude 自己出 plan、按自己的 heuristic 排序，也不会告诉你它偏离了你的清单。

如何判断： 回看 prompt——没写「先执行 1、再 2、再 3」，就是放任 Claude 自由挑。

3. 报告条目本身不清晰可分

「改进错误处理 + 加测试 + 更新文档」一个 bullet 三件事。Claude 做一件就当这个 bullet 完成了。

如何判断： bullet 里有「和」「与」或多个动词——每个连词都是个隐藏子项，Claude 可能跳过。

4. 报告里有自相矛盾

第 5 条「用 async/await」，第 11 条「转 Promise chain 给 IE 兼容」。Claude 静默挑了一个方向——矛盾本身就是 bug。

如何判断： 自己重读报告找矛盾——你找得到，Claude 也找得到，它会闷不吭声地选一个。

5. 报告混了「现状」和「待办」

报告有「current state」和「changes needed」两段。Claude 误读哪条是哪类、跳过它以为已经做了的、或者「修」已经正确的东西。

如何判断： 有些「done」项被又动了一遍，有些「todo」被跳了——这是结构性混淆。

6. 报告引用了 Claude 拿不到的领域知识

「按 Linear ticket BIL-42 的 spec 改进 billing 对账精度」——Claude 没有 Linear 访问权、查不到 BIL-42，于是按通用的「billing 改进」做了。凡是引用了 Claude 够不着的 context 的条目，都会被它用猜测填上。

如何判断： 条目引用了 URL / ticket ID / Slack thread / 私有 doc——Claude 把这些当成了 opaque 的黑盒。

最短修复路径

按收益从高到低。Step 1 一步就能搞定大多数「Claude 没听报告」。

Step 1：把报告变成一份编号 checklist 文件

存成 AUDIT.md，用严格的编号格式。别贴在 prompt 里——落盘的文件是 Claude 能逐字重读的东西，也是 Tasks 系统要去对照索引的东西。

# Audit 2026-06-15

每条独立可执行。Status 初始为 TODO。

## 1. 把密码比较从 `==` 换成 `crypto.timingSafeEqual`
- 文件：src/api/auth/login.ts:42
- 严重度：P0
- 接受标准：函数用常数时间比较；一条测试验证抗时序攻击。
- Status: TODO

## 2. 把密码重置 token TTL 从 24h 降到 1h
- 文件：src/api/auth/reset.ts:23（常量 TOKEN_TTL）
- 严重度：P1
- 接受标准：常量 = 3600；超过 1h 的现存 token 验证 fail。
- Status: TODO

[... 3-14 项类似]

「接受标准」是 Claude 把「完成」绑定到的目标——没有它，「完成」就是模糊的。

Step 2：每条建一个 Task，然后一次只执行一条

Claude Code 的 Tasks 系统（v2.1.16 引入，2026 年 1 月；v2.1.142 起成为默认的执行跟踪层，取代旧的 TodoWrite todo 列表）正是这里该用的原语。每一条变成一个可寻址的 Task，各自带 pending / in_progress / completed 状态，没有谁会从清单上悄悄掉队。

读 AUDIT.md。先别改任何东西。
用 TaskCreate 给每一条（1-14）建一个 Task，subject 用条目标题，description 放接受标准。
然后跑 TaskList，把 14 条全部回报给我，让我确认没有被合并或漏掉。
然后只执行 Task 1。接受标准通过后再把它标 completed。
停下，等我说「next」再开始 Task 2。

一次一条 = 不漏 + 不编。因为 Tasks 会持久化到磁盘上的 ~/.claude/tasks/（/compact 甚至关掉终端都还在），中途列表也是完整的——你可以在新 session 里接着做没做完的审计，直接问 TaskList 还有哪些 pending。

如果你在用 subagent 做编排，把 CLAUDE_CODE_TASK_LIST_ID 设成同一个值，这样每个 session 和 subagent 读写的是同一份 task 文件；否则每个 session 各持一份私有清单，互相看不到对方的进度。

Step 3：执行前先验证它真读懂了

读完报告后，在花一整个 session 去执行之前，先确认这次读取是完整的：

按编号 + 一行标题列出每一条。不要 paraphrase。
第 7 条 quote 不出来——你这次 read 不完整，重读 AUDIT.md。

这能在浪费一个 session 之前 catch 住「Claude 摘要了」。

Step 4：先解决矛盾再 delegate

在自己的报告里发现矛盾，就在 delegate 之前修掉，别让 Claude 闷头替你选：

第 5 和第 11 条矛盾。正确方向：到处用 async/await。
从 AUDIT.md（连同它的 Task）删掉第 11 条，或者重写它。不要自己挑方向。

Step 5：执行后和原清单 diff

跑 TaskList。每一条都：
1. 确认状态是 completed。
2. 把对应的实际 diff 贴出来。
3. 标出 diff 不满足 AUDIT.md 里接受标准的条目。

立刻能看出哪些是真完成、哪些只是声称完成。AUDIT.md 和 Task 列表之间的状态漂移，就是你的 bug 探测器。

Step 6：需要外部 context 的条目，先取来再做

如果第 8 条引用了「ticket BIL-42」：

你没有 Linear 权限。第 8 条开工前，让我把 BIL-42 的内容贴给你。
不要用你自己的解读来填空。

把外部 context 显式化，不要靠假设。

怎么确认修好了

跑 TaskList（或者问「列出所有 task 和状态」）。数量必须等于审计的条目数——14 条对应 14 个 task。数量更少，说明条目被合并了或压根没建。
每个 task 都是 completed，且每条的 diff 都对得上 AUDIT.md 里那行接受标准。
不存在任何无法映射回某个编号条目的改动。如果 Claude 动了审计范围外的文件，那就是「自己发明改进」的失败模式——回退、重新划范围。

对于不简单的审计，先在 plan 模式里跑一遍规划：按两下 Shift+Tab（或输入 /plan），让 Claude 在只读状态下把 Task 列表和执行顺序建好，你批准之后它才动第一个文件。

预防建议

给 agent 的报告 = 带显式接受标准的编号 checklist 文件，不是贴进去的 prose。
每条建一个 Task，按编号引用（「执行 Task 7」），不要「关于 X 的那部分」。
每个 session 步只一条；标 completed 前先按接受标准验证。
报告里的矛盾和歧义自己先解决——Claude 不能闷头选。
外部引用显式化（把 ticket 内容贴进去），不要靠 Claude 自取。
session 终点把 Task 列表和原 AUDIT.md diff 对账——状态漂移就是 bug 探测器。