一句话总结
别把长审计一股脑粘给编程 agent，然后祈祷它修对。先压成 1 页 brief（标题、范围、Top 3 findings、各严重度数量），抽出 3-5 个带 mini-spec 的具体 action item，把 brief 加 action items 一起喂进去，再逐个 PR 对照原 finding 核验。瓶颈从来不是 agent 的上下文窗口——就算是 Cursor 被截断后那约 10 万可用 token，也能吞下一份 42 页 PDF。瓶颈是：一墙 finding 给不了模型任何优先级信号，于是它挑最省事的那条改，最后回你一句“general improvements”。
为什么整份丢进去会翻车
长报告里大多是观察，不是命令。你把 18 条 finding 粘进一个 prompt，agent 没法知道哪三条要紧，于是它去优化“最便宜、看起来还行”的那次改动。结果是一个 PR 动了六个文件，修好了第 31 页一个无关紧要的 lint warning，却没碰第 4 页那个 N+1 查询。技术上它“处理了报告”，实际上你白白浪费了一轮 review。
这不是 token 不够的问题。截至 2026 年 6 月，大家真正在用的 agent 上下文都绰绰有余：
| Agent | 默认模型 | 上下文窗口 | 扣掉开销后可用 |
|---|---|---|---|
| Claude Code | Opus 4.7 / Sonnet 4.6 | 100 万 token（已 GA，无需 beta 标记） | 约 83 万（接近 83.5% 时压缩） |
| Codex CLI | GPT-5.5 | 40 万 token | 约 33-36 万 |
| Cursor（Agent） | Sonnet 4.6 / GPT-5.5 / Gemini 3.1 Pro | 标称 20 万 | 截断后约 7-12 万 |
| Aider | 自带模型 | 取决于模型 | 取决于模型 |
一份 20 页 PDF 大约 1 万到 1.5 万 token，所以一份 42 页审计在上面任何一个里都装得下。agent 能把整份读进去，它做不到的是给它分诊。分诊是你的活，而这套模式就是让你又快又稳地做完它。
这篇适合谁看
在真实项目里跑编程 agent（Claude Code、Codex、Cursor Agent、Aider）的开发者：审计后清理、依赖升级报告、无障碍审计、性能 review、安全 findings。当报告来自另一个工具——Lighthouse 跑出来的、LLM 审计的、人类顾问写的——而不是负责修的那个 agent 时，这套模式价值最大，因为那些 finding 还不在 agent 的工作记忆里。
如果报告本来就 1 页内、范围很紧，或者通篇叙事、没有 action item，那就跳过。后一种情况先把它改写成清单——松散的叙事在任何 agent 上都活不过第一轮。
这套模式，一步步走
1. 把报告压成 1 页 brief
不是重写，是 brief。它只包含四样东西：
- 审计标题和日期。
- 范围（审了什么）。
- 用大白话写的 Top 3 findings。
- 按严重度统计的 finding 总数（比如“3 个 critical、7 个 major、8 个 minor”）。
如果 1 页装不下，说明这次审计范围太大、没法一轮处理完——按区域拆开。
2. 抽出 3-5 个 action item
把 agent 真能下手的 finding 挑出来，其余的丢进 follow-up.md。5 个具体行动赢过 15 个含糊行动。你负责分诊，agent 负责执行。永远别把整张清单交给模型让它自己选——它会按省力程度选，而不是按影响程度。
3. 每个 action 写一份 mini-spec
mini-spec 是 agent 真正读的工作单元。每次都用同一种形状：
Action 1：把弃用的 request.json() 替换为 await request.json()
- 文件：src/api/*.ts
- 来源：报告 3.2 节
- 验收：现有测试全过、无 console warning验收那行是大家最爱省、却恰恰决定 PR 能不能审的一行。没有它，agent 就没有“完成”的定义，会早早宣布胜利。
4. 喂 brief 加 action items——不是全文
给 agent 那 1 页 brief 加几份 mini-spec。只有某个 action 确实需要周边上下文（被标记的代码块、一段 stack trace）时，再去引用全文。多数 item 单靠 mini-spec 就能跑。
在 Claude Code 上处理一份真的很大的报告时，把“读全文”这步交给 subagent，让原始 finding 留在它的上下文窗口里，你的主会话保持一个干净的工作集。盯着 /context 命令——它会按系统 prompt、工具、memory 文件、对话历史把占用拆开来，让你清楚看到报告什么时候开始挤占代码的空间。
5. 一个 action 一个原子 PR
让 agent 一个 action item 开一个 PR，或者一个 PR 里一项一个 commit。原子 PR 审得快、回滚干净。整份审计塞进一个超级大 PR，是这件事翻车的第二常见方式，仅次于直接丢报告。
6. 逐个 PR 对照原 finding 核验
闭环。先读原 finding，再读 PR：这个 action 解决的是那条 finding，还是旁边一个“接近的”？跑全套测试，不只跑动到的文件——性能和安全审计经常翻出“根本没测试”的 finding，那就让 agent 顺手提一个。
一个走完的例子：42 页性能审计
报告：“checkout 流程性能 review”，42 页，18 个 findings。
Brief：
性能审计，2026 年 5 月
范围：/checkout/*
严重度：2 个 critical、6 个 major、10 个 minor
Top 3：
1. CheckoutForm 不必要的 re-render（critical）
2. cart.ts 的 N+1 查询（critical）
3. OrderSummary 缺图片懒加载（major）Action items：只取 Top 3，每个 mini-spec 标清文件、验收、报告节号。结果：3 个小 PR，每个都能对着一条 finding 核验。剩余 15 个留在 follow-up.md，下个 sprint 处理。盯住命中率——如果你写了 spec 的 finding 里出 PR 的不到 70%，说明 brief 太激进，你漏掉了 agent 需要的上下文。
容易踩的坑
- 整份报告一把丢进 prompt。 agent 读完拿不到优先级信号，给你“general improvements”。
- 只有 finding 没有 action item。 finding 是观察，action item 是命令。送之前先翻译过来。
- 跳过严重度排序。 agent 挑最容易的，几乎不是最重要的那条。
- 让 agent 自己分诊。 你定修哪些，agent 定怎么修。
- 整审计一个超级大 PR。 审得慢、回滚也乱。
- mini-spec 没有验收标准。 没有“完成”的定义，agent 改到第一个看起来行的地方就停。
- 忘了 follow-up 文件。 今天没出 PR 的 finding，不在合并前落进
follow-up.md就蒸发了。
FAQ
- 报告是 PDF 或幻灯片怎么办？：四个 agent 都直接接受 PDF，而一份 20 页 PDF 也就约 1-1.5 万 token，大小根本不是问题。能转就还是转成纯文本或 Markdown——“压缩 + 抽取”这两步在你能 grep 的文本上好做得多。
- 做审计的那个 agent 该自己修吗？：可以。Claude Code 同一会话能审 + 修，很快。风险高的活就把“审”和“修”分开，让核验那步真正独立。
- 我能不能干脆靠 100 万 token 窗口，全粘进去？：能粘——窗口装得下。但上下文大不等于有优先级。brief 的存在就是给模型一个它从扁平清单里推不出来的分诊信号，顺带还是对审计本身的一道理性检查。
- 某条 finding 其实是错的怎么办？：行动前先核验 finding。brief 这步就是你的过滤器——把 Top 3 用大白话写出来，正是一条站不住脚的 finding 通常露馅的地方。
- brief 该多大？：1 页，硬上限。装不下就说明审计范围太宽、没法一轮处理；按区域拆开，每片各跑一遍这套模式。
相关阅读
想了解 Claude 在长会话里到底怎么管理上下文窗口，可参考 Anthropic 官方的 Claude Code 上下文文档。