网友总结的26条Claude Code的工程技巧。
Family A：结构化
1. 模块化组装：system prompt 拆成约 15 个独立函数，每个管一块，修改互不影响，静态部分可缓存。
2. XML 标签结构化：用 、、 划分区域，比 markdown 更精确。
3. Markdown 标题做导航锚点：每个 （井号） 回答一个问题，模型生成中途需要参考规则时可以快速定位。

Family B：行为控制
4. 大写关键词三档力度：普通偏好 → IMPORTANT → CRITICAL（附带后果说明）。
5. 正反例同时给：光有正例模型容易过度应用，明确的反例划出边界——PlanMode 什么时候用、什么时候不用。
6. 后果链描述：Don't do X because Y 远比 Don't do X 有效。git add -A → 包含 .env → 凭证被提交 → 安全漏洞。
7. 角色框架："高级安全工程师"和"AI 助手"激活的词汇量、风险评估和细节层级完全不同。

Family C：少样本示例
8. 多轮对话示例：一个完整的多轮示例比十个单轮示例更有效——教的是过程，不只是结果。Claude Code 里有一个完整示例，展示了并行启动 research worker、等待结果时给状态更新、汇总后再派发实现任务的完整流程。
9. 示例内加推理注释：在 标签里解释为什么这样做，模型学到的是决策标准，能泛化到新情况。

Family D：安全防护
10. 纵深防御分层：安全规则在 system prompt、工具描述、任务 prompt 多个层级重复出现。
11. prompt 注入检测委托：明确让模型监视工具输出中的注入尝试，发现后立即告警用户再继续。
12. 硬性排除清单：Claude Code 的安全审查有 17 条明确排除项，加上理由，告诉模型哪些不用报。

Family E：上下文管理
13. 缓存感知架构：system prompt 用显式边界分隔"静态前缀"（跨会话可缓存）和"动态后缀"（每次会话重算）。动态字段一改，整个缓存就作废了，所以要严格分开。
14. Token 预算控制：每个区块设上限——session memory 每 section 不超过 2000 token，总量不超过 12000 token。
15. 通过附件实现渐进式披露：频繁变更的数据，从工具描述里移到附件消息——agent 列表是 fleet 缓存 token 的 10.2%，每次 MCP 重连都会触发全量重缓存。
16. 内容去重和路径归一化：/tmp/user-abc123/ → $TMPDIR，所有用户共享同一条 prompt，缓存命中率大幅提升。

Family F：委托与分解
17. 子任务流水线：复杂任务拆成多阶段，每阶段用不同的 agent/prompt——安全审查分为研究、分析、评估、过滤四个阶段，每个阶段的提示策略不同。
18. 工具偏好层级：明确规定什么情况用什么工具，从最优先到 fallback 的顺序——Read > cat，Edit > sed，Glob > find，Bash 只用于无专用工具的场景。
19. 并行与串行的显式门控：没有依赖关系的工具调用并行执行，有依赖的串行。不加说明模型要么全串行（慢）要么全并行（错）。

Family G：自适应/条件
20. 功能开关控制 prompt 区块：feature flag 控制哪些 prompt 区块被包含，用不到的区块在编译时就消除，不占 token。
21. 用户类型分支：内部用户和外部用户拿到不同的指令——内部用户更直接、更少护栏；外部用户更多示例、更多限制。
22. 模型特定调优：代码里有大量 @[MODEL LAUNCH] 注释——"Capybara v8 注释过多，加这条直到模型修复"，"false claim 率 29-30%，加报告忠实性约束"。不同模型有不同的失效模式，需要专门补偿。

Family H：防漂移/接地
23. 永远不要委托理解：正确的委托要包含文件路径、行号、具体修改内容，证明委托者自己理解了问题。
24. 如实报告结果：47/50 测试通过就说 47/50，不要说"所有测试应该通过。
25. 日期锚定："Thursday" → "2026-03-05"。相对时间在未来读起来会失去意义。
26. 范围匹配：用户批准了一次 git push，不等于批准了所有 push。修 bug 不等于可以重构周围代码。权限不向外蔓延。如果再活一次你还愿意当现在的你吗？ 我认为愿意