主题
04.5 性能压榨 Checklist
30 条可勾选的调优动作，按"收益/成本"排序。这是前四章的行动总纲。
读完你能做什么：拿着这张表逐条落地，把前面所有章节的原理变成肌肉记忆。
使用说明
- 每条标注 收益 和 成本（🔴高 🟡中 🟢低）
- 优先做"高收益、低成本"的（表格已按此排序）
- 每条链接到原理章节
第一梯队：立刻做（高收益，低成本）
| # | 动作 | 收益 | 成本 | 原理 |
|---|---|---|---|---|
| 1 | 把最关键的约束放在提示词最后一行 | 🔴 | 🟢 | 04.2 |
| 2 | 长文档放前面，问题放后面 | 🔴 | 🟢 | 03.2 |
| 3 | 给"我不知道"一个明确出口 | 🔴 | 🟢 | 04.3 |
| 4 | 用 XML 标签分块，不写散文式提示词 | 🔴 | 🟢 | 02.2 |
| 5 | 把形容词约束改成可验证的具体标准 | 🔴 | 🟢 | 02.1 |
| 6 | 切换到不相关任务时用 /clear | 🔴 | 🟢 | 03.4 |
| 7 | 看到第一次偏离就立刻纠正 | 🔴 | 🟢 | 04.2 |
| 8 | 涉及"最新/当前"的问题，强制先搜索 | 🔴 | 🟢 | 04.3 |
| 9 | 一个提示词只放一个主任务 | 🟡 | 🟢 | 02.7 |
| 10 | 负向指令都配一个正向替代 | 🟡 | 🟢 | 02.1 |
第二梯队：值得投入（高收益，中成本）
| # | 动作 | 收益 | 成本 | 原理 |
|---|---|---|---|---|
| 11 | 长文档用"先摘录原文再作答"的两步法 | 🔴 | 🟡 | 03.3 |
| 12 | 关键结论用独立子代理交叉验证 | 🔴 | 🟡 | 02.6 |
| 13 | 建 CLAUDE.md（<200 行）固化项目规则 | 🔴 | 🟡 | 05.6 |
| 14 | 代码校验用 hook 自动化（类型检查/测试） | 🔴 | 🟡 | 06.5 |
| 15 | 长任务用外部 PROGRESS.md 存状态 | 🔴 | 🟡 | 03.4 |
| 16 | 给可验证的"完成标准"，不说"修好它" | 🔴 | 🟡 | 04.1 |
| 17 | 复杂决策用"生成多候选 → 评分 → 择优"链 | 🟡 | 🟡 | 02.6 |
| 18 | 精心设计 2-5 个示例（含边界+拒绝案例） | 🟡 | 🟡 | 02.3 |
| 19 | API 调用强制查证，不凭记忆 | 🔴 | 🟡 | 04.3 |
| 20 | 混合模型：Haiku 扫描 + Opus 决策 | 🟡 | 🟡 | 03.5 |
第三梯队：精细优化（中收益，视情况）
| # | 动作 | 收益 | 成本 | 原理 |
|---|---|---|---|---|
| 21 | 关键约束在开头和末尾各写一次 | 🟡 | 🟢 | 04.2 |
| 22 | 每条陈述标注 [观察]/[推断]/[通识]/[未知] | 🟡 | 🟡 | 04.3 |
| 23 | 工具输出加管道过滤，不全量读入 | 🟡 | 🟢 | 03.1 |
| 24 | 简单任务降 effort 或降模型 | 🟡 | 🟢 | 01.5 |
| 25 | 大仓库用"先索引后精读"三阶段 | 🟡 | 🟡 | 03.2 |
| 26 | 明确任务复杂度上界，抑制过度思考 | 🟡 | 🟢 | 02.5 |
| 27 | 用 /context 定期检查上下文占用 | 🟡 | 🟢 | 03.1 |
| 28 | 长思考后在末尾重申输出格式 | 🟡 | 🟢 | 02.5 |
| 29 | 用 hook/权限做硬约束，不靠提示词 | 🔴 | 🟡 | 06.5 |
| 30 | 走错方向用 /rewind 而非让它改回来 | 🟡 | 🟢 | 03.4 |
按症状索引
不知道从哪条开始？先定位你的症状：
症状：输出不准/有幻觉
→ 优先做 #3、#8、#11、#14、#19、#22
核心逻辑：强制引用 + 强制验证 + 给不知道的出口。
症状：不遵守指令/格式漂移
→ 优先做 #1、#4、#7、#21、#28
核心逻辑：位置 + 结构 + 早纠正。
症状：长会话越来越笨
→ 优先做 #6、#15、#27、#30
核心逻辑：管理上下文，不要让它无限膨胀。
症状：又慢又贵
→ 优先做 #6、#20、#23、#24
核心逻辑：砍上下文长度 > 换便宜模型。
症状：Agent 跑偏/做危险操作
→ 优先做 #16、#29
核心逻辑：可验证的完成标准 + 硬性拦截。
三个"元技巧"
超越单条技巧的心法：
元技巧 1：先诊断，后用药
效果不好时，不要立刻加说明。按这个顺序查：
text
上下文被污染了吗？ → 清理
关键约束在中段吗？ → 移到末尾
约束可验证吗？ → 改具体
任务太多吗？ → 拆分
（以上都 OK 才加说明）见 04.2 第六节。
元技巧 2：概率的归提示词，确定的归机制
text
「倾向性」需求（风格、偏好、一般规则）→ 提示词 / CLAUDE.md
「必须保证」需求（安全、格式、流程门禁）→ hook / 权限 / schema 校验不要用提示词去做需要 100% 保证的事。
元技巧 3：让程序当裁判
任何能被程序判定对错的东西（语法、类型、测试、schema），都交给程序判，不要靠人肉核对或指望我自觉。这是把"概率正确"升级为"确定正确"的唯一途径。
打印版速记
text
位置：关键的放首尾，长文档在前，问题在后
结构：XML 分块，一次一个任务
具体：可验证的标准，不用形容词
出口：给"不知道"留路
验证：引用 + 执行 + 程序校验
上下文：该清就清，用外部文件存状态
纠正：第一次偏离就动手
机制：必须保证的用 hook，不用提示词延伸阅读
- 02.7 反模式清单 —— 反面对照
- 04.1 我的底层运作机制 —— 所有技巧的根源
- 12.4 提示词模板库 —— 现成模板