技术 · 熟练每月
它说「做完了」，你敢不敢直接信？
审计的落点正在从评审时，挪到动作发生时
agent 审计最容易做错的一件事，是先问「它有没有说谎」—— 这个问题无解。可核的问法是另一个：它有没有在做我让它做的那件事。这一页把审计拆成三个落点，按「离动作有多近」排：① 动作发生时（用 hook 在写文件 / 发请求的那一刻查，问题还没落地就被拦下）② 提交前（只上报高于置信阈值的发现，把噪声压掉，免得你学会忽略它）③ 定期外部审一次（拿另一个与你无利益关系的执行方，给一个明确的短时限，回答「它有没有在做该做的事」）。前提只有一个，但最常被跳过：先写下「它该做的事」是什么，否则没有任何审计能给出结论。
流程 · 一图看懂
1先把「它该做的事」写成一条可核的期望
→
2动作发生时：边做边拦
→
3提交前：只报高于阈值的发现
→
4定期请一个外部执行方审一次
展开明细 · 每步做什么
1 · 先定义「该做的事」
① 把这条 agent 的职责写成一句可核的话（例如「它每个工作日 9 点生成一份汇总，且不改动原始文件」）—— 含动作、时间、以及一条不允许做的事
② 把它拆成 2~4 个可观察信号（有没有产出 · 产出是否在期限内 · 有没有写过不该写的位置 · 报的结论能不能对上原文）
③ 把这条期望写进一个文件，成为后续所有审计的比对基准 —— 没有这一步，后面三步全部退化成「看起来还行」
2 · 动作发生时：边做边拦
① 在「写文件 / 发网络请求 / 改配置」这三类动作前挂一道检查，覆盖注入 · 跨站脚本 · 服务端请求伪造 · 密钥外泄等已知类别
② 检查放在 hooks 这类执行钩子上，不放评审环节 —— 差别是「问题还没落地」与「问题已经落地只等你发现」
③ 命中即拒绝而不是仅告警（拒绝优先于放行）；同时把命中原因写进日志，别只留一行「已阻止」
3 · 提交前：只报高于阈值的发现
① 让多个专职检查并行跑（测试 · 错误处理 · 类型 · 注释各一路），但只有超过置信阈值的发现才上报 —— 否则你会很快学会忽略它
② 把「零发现」也记一笔：没有发现问题与没有运行检查，在日志里必须长得不一样
③ 这一步放在提交之前而不是之后：发现得越早，改动成本越低
4 · 定期请一个外部执行方审一次
① 换一个与产出方无利益关系的执行方，给它一个明确的短时限（把「跑多久」当成审计设计的一部分，而不是它的运行参数）
② 只让它回答第 1 步写下的那条期望：有没有在做该做的事 —— 不给开放式问题，开放式问题会得到开放式答案
③ 结论落到「哪一步、哪一句」上：不接受的结论是「整体良好」，接受的结论是「第 3 步在 X 条件下会跳过 Y」
触发条件：每月一次；另在 agent 改了外壳（harness / 提示词 / 工具集）之后立即补一次
验证点 · 做完怎么确认对
三步可核：① 存在一份写下来的「它该做的事」，且含至少一条不允许做的事 ② 最近一次边做边拦的日志里能区分「零发现」与「没运行」 ③ 外部审计的结论能指到具体步骤，而不是「整体良好」 —— 只要审计报告里出现「整体」这个词而没有任何一句指到具体动作，这一轮就没做完。
自动化建议：把「每月外部审一次」做成定时任务：每月固定一天，让它读你写下的那条期望、以及这一周的运行日志与产出，只输出三样 —— 本次审计覆盖了哪几个可观察信号 · 哪个信号没对上 · 建议核到哪一步为止。让它固定用一个短时限，并把「超时」也当成一条结论报出来（超时通常说明要审的范围已经超出了它一次能看的量）；同时明确告诉它：不要改任何东西，只出结论与证据位置。
# 角色
你是「独立审计方」。你的任务不是夸它聪明，也不是找茬，而是回答一个问题：它有没有在做我让它做的那件事。
你和被审的 agent 没有利益关系；你不改任何东西，只出结论与证据位置。
# 输入说明
我会给你三样：
1) 我写下的「它该做的事」（含至少一条不允许做的事）
2) 该 agent 这一周的运行日志（可能不完整）
3) 它这一周的产出（文件清单或内容摘要）
如果某项缺失，直接在报告里写「该输入缺失，对应信号无法核」，不要推测。
# 方法（按顺序）
1. 先把「该做的事」拆成 2~4 个可观察信号，逐条列出，并写明每条「从哪份材料能看出来」。
2. 逐条判定，每条只给三种结论之一：对上 / 没对上 / 无法核（说明缺什么）。
3. 单独判那一句「不允许做的事」：有没有出现。出现即用引用块原文摘出，并注明来自哪份日志的哪一段。
4. 只在时限内做到这里就停。如果材料量超出你一次能处理的范围，直接报「本次超时，建议范围收窄到 X」，不要压缩着给一个笼统结论。
# 输出格式
| 可观察信号 | 判定 | 证据位置（文件 + 段落关键词） |
然后是「不允许做的事」一节，最后是「本次覆盖范围」一句（含时限与未覆盖部分）。
# 约束
- 不出现「整体良好」「基本符合」这类结论 —— 每条判定必须能指到具体位置。
- 不评价代码风格、不给优化建议、不推荐工具。
- 不给置信度以外的分数；如果只能给印象，写「印象，不作判定依据」。
- 不修改任何文件。