网友总结的30条Claude Code的工程技巧。
Family A：结构化（1-4条）
1. 模块化组装：system prompt 拆成约 15 个独立函数，每个管一块，修改互不影响，静态部分可缓存。
2. XML 标签结构化：用
3. Markdown 标题做导航锚点：每个 （井号） 回答一个问题——你是谁、接收什么、怎么处理、怎么输出、有什么限制。模型生成中途需要参考规则时可以快速定位。
4. 清单式指令优于段落：每条指令独立存在，不容易被跳过；子缩进把相关规则分组。
Family B：行为控制（5-9条）
5 大写关键词三档力度：普通偏好 → IMPORTANT → CRITICAL（附带后果说明）。原则：如果什么都是 CRITICAL，就什么都不是 CRITICAL。
6. 正反例同时给：光有正例模型容易过度应用，明确的反例划出边界——PlanMode 什么时候用、什么时候不用。
7. 后果链描述：Don't do X because Y 远比 Don't do X 有效。git add -A → 包含 .env → 凭证被提交 → 安全漏洞，模型会推理，不只是死记规则。
8. 角色框架："高级安全工程师"和"AI 助手"激活的词汇量、风险评估和细节层级完全不同。
9. 元认知脚手架：强制在
Family C：少样本示例（10-12条）
10. 多轮对话示例：一个完整的多轮示例比十个单轮示例更有效——教的是过程，不只是结果。Claude Code 里有一个完整示例，展示了并行启动 research worker、等待结果时给状态更新、汇总后再派发实现任务的完整流程。
11. 示例内加推理注释：在
12. 精确的输出模板：直接给一个填好的完整示例说"按这个结构来"，消除格式、深度、风格的所有歧义。
Family D：安全防护（13-16条）
13. 纵深防御分层：安全规则在 system prompt、工具描述、任务 prompt 多个层级重复出现。单条指令不可能 100% 可靠，冗余是设计。
14. prompt 注入检测委托：明确让模型监视工具输出中的注入尝试，发现后立即告警用户再继续。
15. 硬性排除清单：Claude Code 的安全审查有 17 条明确排除项（DoS、资源耗尽、速率限制……）加上理由，告诉模型哪些不用报。没有排除清单，什么都会被标出来。
16. 置信度阈值：低于 70% 置信度的发现不报告。把主观判断转成可量化的门槛，过滤掉投机性结论。
Family E：上下文管理（17-20条）
17. 缓存感知架构：system prompt 用显式边界分隔"静态前缀"（跨会话可缓存）和"动态后缀"（每次会话重算）。动态字段一改，整个缓存就作废了，所以要严格分开。
18. Token 预算控制：每个区块设上限——session memory 每 section 不超过 2000 token，总量不超过 12000 token，MEMORY.md 超过 200 行就截断。不设预算，模型会随机填满空间。
19. 通过附件实现渐进式披露：频繁变更的数据（如 agent 列表）从工具描述里移到附件消息——agent 列表是 fleet 缓存 token 的 10.2%，每次 MCP 重连都会触发全量重缓存。
20. 内容去重和路径归一化：/tmp/user-abc123/ → $TMPDIR，所有用户共享同一条 prompt，缓存命中率大幅提升。
Family F：委托与分解（21-23条）
21. 子任务流水线：复杂任务拆成多阶段，每阶段用不同的 agent/prompt——安全审查分为研究、分析、评估、过滤四个阶段，每个阶段的提示策略不同。
22. 工具偏好层级：明确规定什么情况用什么工具，从最优先到 fallback 的顺序——Read > cat，Edit > sed，Glob > find，Bash 只用于无专用工具的场景。
23. 并行与串行的显式门控：没有依赖关系的工具调用并行执行，有依赖的串行。不加说明模型要么全串行（慢）要么全并行（错）。
Family G：自适应/条件（24-26条）
24. 功能开关控制 prompt 区块：feature flag 控制哪些 prompt 区块被包含，用不到的区块在编译时就消除，不占 token。
25. 用户类型分支：内部用户和外部用户拿到不同的指令——内部用户更直接、更少护栏；外部用户更多示例、更多限制。
26. 模型特定调优：代码里有大量 @[MODEL LAUNCH] 注释——"Capybara v8 注释过多，加这条直到模型修复"，"false claim 率 29-30%，加报告忠实性约束"。不同模型有不同的失效模式，需要专门补偿。
Family H：防漂移/接地（27-30条）
27. 永远不要委托理解：禁止写"根据你的发现，修复这个 bug"——这把理解和执行都推给了下级 agent。正确的委托要包含文件路径、行号、具体修改内容，证明委托者自己理解了问题。
28. 如实报告结果：47/50 测试通过就说 47/50，不要说"所有测试应该通过"，也不要用"看起来完成了"来掩盖失败。模型有讨好倾向，这条指令专门对抗它。
29. 日期锚定："Thursday" → "2026-03-05"，"last quarter" → "Q1 2026 (Jan-Mar)"。相对时间在未来读起来会失去意义，保存记忆时必须转为绝对日期。
30. 范围匹配：用户批准了一次 git push，不等于批准了所有 push。修 bug 不等于可以重构周围代码。权限不向外蔓延，动作范围必须精确匹配请求范围。
原文：x.com/xenzee_ai/status/2039166944314884250
#HOW I AI# #程序员#
