【谨慎运用】拒绝AI过度工程手册-后续章节
05/1847 浏览开发心得
第二章：早期预警——在 Claude 写代码之前识别过度工程
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Claude 在写代码之前通常先用自然语言描述方案。这段文字已经包含了过度工程的
早期信号。在 Claude 动手前识别并打断，比事后清理代价低 10 倍。
────────────────────────────────────────────────────────────────────────────────
2.1 高风险词汇表——出现时立即追问
────────────────────────────────────────────────────────────────────────────────
【抽象信号词】
接口 / 抽象类 / 基类 / 泛型约束 / 依赖注入 / 控制反转
→ 追问：「这个抽象在项目中有几个具体实现？如果只有一个，为什么需要抽象？」
【假设性需求信号词】
未来 / 以后 / 可能 / 扩展 / 灵活 / 通用 / 可复用 / 插件化
→ 追问：「你说的"以后可能"具体是什么场景？这个场景有多大概率真的发生？」
【模式信号词】
工厂模式 / 观察者模式 / 策略模式 / 装饰器模式 / 门面模式
→ 追问：「不用这个模式的话，代码会有什么具体问题？」
【过度健壮信号词】
容错 / 降级 / 熔断 / 重试机制 / 幂等 / 分布式事务
→ 追问：「我的场景需要这个级别的可靠性吗？宕机的代价是什么？」
【修复扩大信号词】（1.15 的早期预警）
根本原因 / 更彻底地修复 / 顺便处理 / 确保长期稳定
→ 追问：「你要做的哪些事是修复这个 BUG 必须的，哪些是额外改进？
把两个列表分开给我。」
────────────────────────────────────────────────────────────────────────────────
2.2 方案描述的结构性预警
────────────────────────────────────────────────────────────────────────────────
以下结构出现时，方案很可能已经过度复杂：
▸ 「我将创建以下组件：A、B、C、D、E……」
（超过 3 个新组件来完成一个小功能，几乎必然过度工程）
▸ 「首先我需要重构现有的 X，然后再实现……」
（你没要求重构，Claude 自行决定先重构再实现）
▸ 「这个实现分为以下几层：[展示层/业务层/数据层/基础层]」
（你要的可能只是一个函数）
▸ 「为了保持代码的清洁和可维护性，我将……」
（正当化语言后面往往跟着不必要的复杂度）
▸ 「这样修复更彻底，因为问题的根本原因在于……」
（可能是 1.15 范围蔓延的开始，追问「必须 vs 可选」）
────────────────────────────────────────────────────────────────────────────────
2.3 复杂度累积陷阱（最隐蔽的过度工程形式）
────────────────────────────────────────────────────────────────────────────────
单次过度工程很容易识别。但 Claude 在多轮对话中每次加入的复杂度往往都
"看起来合理"，问题在于累积效果。
典型场景：
第1轮：加了一个配置对象（「以后可能需要调整参数」）
第2轮：加了一个接口（「以后可能换实现」）
第3轮：加了一个工厂方法（「为了创建逻辑和业务逻辑分离」）
第4轮：加了一个依赖注入容器（「为了更好地管理依赖」）
每一步单独看都"合理"，最终你的 100 行程序变成了 500 行。
检测句式（多轮对话中定期使用）：
► 「我们在这个功能上总共写了多少行代码？
最初的需求有多复杂？这个比例合理吗？」
► 「列出这段代码里所有的间接层（接口、工厂、适配器、中间件），
每一层解决了什么问题。如果某层你说不清楚，它可能不应该存在。」
► 「如果我们从零重写这个功能，知道了现在所有的需求，
你会写出同样复杂的结构吗？如果不会，说明当前结构是历史积累的，
请提出简化方案。」
────────────────────────────────────────────────────────────────────────────────
2.4 打断方案描述的干预句式
────────────────────────────────────────────────────────────────────────────────
► 「等一下，你提到了 [X 个组件/抽象层]。
我的需求只需要一个函数，请用最少的结构重新描述方案。」
► 「你提到了"未来可能"，先暂停这个方向。
我们只解决现在确定的需求，假设性需求不纳入当前设计。」
► 「我注意到你计划先重构现有代码。我没有要求这样做。
请跳过重构，直接实现功能，哪怕实现方式不够"优雅"。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第三章：预防性约束——在任务开始时绑定 Claude 的行为
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
3.1 会话级行为契约（Session-Level Behavioral Contract）
────────────────────────────────────────────────────────────────────────────────
在会话开始时一次性声明约束，让 Claude 在整个会话中自动遵守，
而不是每次任务都重复。
【精简版（3 行，快速粘贴）】
┌─────────────────────────────────────────────────────────────────┐
│ 整个对话遵守：YAGNI（不为假设需求设计），最小改动（只改 │
│ 任务相关代码），建议分离（额外建议列在末尾不直接加进实现）。 │
│ 项目背景：[一句话描述] │
└─────────────────────────────────────────────────────────────────┘
【完整版（5 条，高精度控制）】
┌─────────────────────────────────────────────────────────────────┐
│ 在我们的整个对话中，请遵守以下工作原则： │
│ │
│ 1. YAGNI：只实现我明确要求的功能，不为假设的未来需求设计 │
│ 2. 最小改动：修改代码时，只改与任务直接相关的部分 │
│ 3. 建议分离：有额外建议时，在回复末尾的"可选项"中列出， │
│ 不要直接加进实现 │
│ 4. 先问后做：如果你认为需要比我要求更复杂的方案， │
│ 先告诉我理由，等我确认再实施 │
│ 5. 诚实不确定性：如果你不确定最佳实现方式，说出来， │
│ 不要用添加抽象层来规避不确定性 │
│ │
│ 项目背景：[描述项目规模和生命周期] │
└─────────────────────────────────────────────────────────────────┘
注意：行为契约需要在会话开始时声明。在中途声明效果会打折扣，
因为 Claude 的风格已经在前面的对话中被"校准"了。
────────────────────────────────────────────────────────────────────────────────
3.1.1 长会话的契约失效与重锚
────────────────────────────────────────────────────────────────────────────────
行为契约在长会话中会逐渐失效。Claude 技术上"记得"第 1 轮的声明，
但随着对话轮次增加，早期约束的权重会衰减，过度工程行为会重新出现。
【识别信号】：你在第 40 轮后发现 Claude 又开始加抽象层、顺便重构，
尽管你在会话开始时已经声明了约束。
【处理策略】
方案 A：主动重锚（会话继续时）
在同一会话中任意时刻重新粘贴模板 0（精简版），附加当前上下文：
┌────────────────────────────────────────────────────────────────┐
│ 重新确认约束：YAGNI，最小改动，建议分离。 │
│ 我们接下来要做的是：[任务描述]。请严格按约束实施。 │
└────────────────────────────────────────────────────────────────┘
方案 B：开新会话（切换到重大新任务时）
当当前任务与之前的对话主题差异很大时，开新会话比重锚更干净。
原因：长对话中积累的"风格校准"很难被单次重锚完全覆盖。
操作：开新会话 → 粘贴模板 0 或模板 1 → 带入必要的背景信息。
经验规则：同一个功能的迭代 → 重锚；切换到不同功能或模块 → 新会话。
────────────────────────────────────────────────────────────────────────────────
3.2 项目背景声明——帮 Claude 校准规模感
────────────────────────────────────────────────────────────────────────────────
Claude 无法感知你项目的规模。一句背景声明能显著减少规模错判。
► 「这是一个 [个人项目/内部工具/MVP]，不是生产级系统。
请按最简单可行的方案实现。」
► 「这是一次性脚本，运行后丢弃。不需要错误处理、日志、测试、文档。」
► 「这是 MVP，目标是快速验证假设。工程质量是次要的，允许技术债。」
────────────────────────────────────────────────────────────────────────────────
3.3 任务级约束——针对单个任务的精准限定
────────────────────────────────────────────────────────────────────────────────
实现新功能：
「实现 [功能]。约束：只实现我描述的功能 / 不修改现有代码结构 /
不引入新依赖 / 额外建议列在最后，不直接加进实现。」
修复 BUG：
「修复以下 BUG：[描述]。约束：只改导致 BUG 的那几行，
不做任何范围外的改动，包括"顺便的改进"。
修改前先列出具体行号，等我确认再改。」
重构：
「重构 [X]，目标是 [降低重复/提高可读性——选一个]。约束：
功能行为完全不变 / 不添加新功能 / 给我重构前后行数对比。」
代码审查：
「审查以下代码，只报告：会导致 BUG 的错误 / 有量化依据的性能问题 /
明确的安全漏洞。不需要：风格建议 / 重构机会 / 假设性扩展建议。」
架构设计：
「为 [描述] 设计架构。给两个方案：
方案 A（最简单，当前适用）/ 方案 B（当 [具体可测量条件] 满足时演进）。
明确说明现在选 A 的理由。」
行数限制（最直接的约束）：
「代码不超过 [N] 行。超出说明方案需要简化，不是我的需求变复杂了。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第四章：干预与简化——识别、打断、削减
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
4.1 实时干预句式（代码已生成，发现过度工程时）
────────────────────────────────────────────────────────────────────────────────
打断不必要的抽象（对应 1.1、1.2、1.10）：
► 「停一下。你创建了 [X 个类/接口]，但我的需求只需要一个函数。
请重写，不要抽象。」
► 「这个接口只有一个实现类。给我一个具体的（非假设性的）存在理由，
否则请去掉这个接口。」
打断不必要的错误处理（对应 1.3、1.11）：
► 「这个函数的输入由我控制，不是用户输入，不需要校验。请移除。」
► 「这里的 try/catch 捕获的是什么具体异常？说不出来就不应该存在。」
打断不请自来的重构（对应 1.5）：
► 「给我一个纯净的 diff：只包含必须改动的行，其余所有行完全不变。」
► 「你改了 [X 部分]，这不在我的需求里。这些修改有必要吗？没有就还原。」
打断修复过程中的范围蔓延（对应 1.15）：
► 「把你的改动分成两个列表：① 修复这个 BUG 绝对必须的 ② 你认为有益但不必须的。
我只接受第一个列表。」
► 「你说这是"根本原因"——如果我只修第一个列表里的内容，
BUG 还会出现吗？」
打断过度配置化（对应 1.4）：
► 「把 [X] 做成可配置需要什么理由？如果我永远不会改它，
硬编码更清晰。请用硬编码。」
────────────────────────────────────────────────────────────────────────────────
4.2 简化现有代码——让 Claude 做减法
────────────────────────────────────────────────────────────────────────────────
识别死代码：
► 「找出所有从未被调用的函数、从未被访问的变量、从未被走到的分支，
建议删除。」
► 「找出所有被注释掉的代码块，说明应该直接删除还是恢复，以及理由。」
拆解过度抽象：
► 「这个接口只有一个实现，把接口和实现合并，只删除不必要的层。」
► 「这个 [Manager/Handler/Provider] 只转发调用，
把逻辑内联到调用方，然后删除这个类。」
量化简化效果：
► 「简化前后的行数分别是多少？如果没有减少，说明方向不对。」
► 「读懂这段代码需要理解多少个独立概念？简化后能降到多少？」
────────────────────────────────────────────────────────────────────────────────
4.3 成本估算——让 Claude 量化复杂度的代价
────────────────────────────────────────────────────────────────────────────────
► 「如果这个功能在 6 个月后需要修改，你加入的这些抽象层需要额外
理解多少分钟才能看懂？如果是"不复杂设计"，这个时间是多少分钟？」
► 「如果我明天需要删除这个功能，你的方案需要改动多少个文件/函数/类？
最简单的方案需要改多少个？」
► 「6 个月后的我，看到这段代码，重新理解它需要多久？
如果是简单版本呢？」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第五章：应对 Claude 为复杂设计辩护
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
5.1 识别 Claude 的常见辩护话术
────────────────────────────────────────────────────────────────────────────────
话术 A：「这样更容易维护」
→ 反问：「维护什么场景？给我一个你预见到的、具体的维护操作。」
话术 B：「这是业界最佳实践」
→ 反问：「这个实践针对什么规模？我的项目符合那个规模吗？」
话术 C：「这样可以避免将来重构」
→ 反问：「将来重构的概率有多大？如果只有 20%，现在的额外投入值得吗？」
话术 D：「不这样做代码会很脆弱」
→ 反问：「脆弱意味着在哪种具体场景下出什么具体问题？
那个场景在我的项目里真实存在吗？」
话术 E：「这只增加了很少的复杂度」
→ 反问：「把本次对话里所有"只增加一点点"加在一起，总量是多少？
（参见第二章 2.3 复杂度累积陷阱）」
话术 F：「这样修复更彻底，根本原因是……」
→ 反问：「把"必须修"和"顺便修"分开列出来。我只接受必须修的。」
────────────────────────────────────────────────────────────────────────────────
5.2 打破辩护循环
────────────────────────────────────────────────────────────────────────────────
► 「我理解你的理由，我选择接受这个技术债。
请给我最简单的版本，不需要继续说服我。」
► 「把你的复杂方案和简单方案并排列出来：
简单方案会带来什么具体风险？复杂方案的成本是什么？
我来做权衡，你不需要替我决定。」
► 「我同意在大型项目中你的方案更好。但这不是大型项目。
请根据我的项目规模给建议。」
► 「直接给我代码。不需要继续讨论方案了。」
────────────────────────────────────────────────────────────────────────────────
5.3 最难的边界：当 Claude 的辩护是对的
────────────────────────────────────────────────────────────────────────────────
重要警告：本手册的目标是抵制不合理的复杂度，不是把所有复杂度都视为敌人。
有时候 Claude 坚持某个复杂设计是因为它真的是必要的。
【如何区分"Claude 正确坚持"和"Claude 错误辩护"】
Claude 可能是对的，如果：
✓ 它能举出你当前项目里的具体场景（不是"以后可能"）
✓ 你认同那个场景是真实存在的
✓ 去掉那个设计后，你能清晰描述会出什么具体问题
✓ 它指出了你还没意识到的约束（例如「这个字段在数据库层面必须唯一，
不是应用层校验能处理的」）
Claude 可能是在错误辩护，如果：
✗ 它用抽象的原则而非具体场景来支持自己（「SOLID 原则要求…」）
✗ 它的场景是假设性的（「如果以后…」）
✗ 你问"如果不这样做会怎样"时，它的回答变得模糊
✗ 它给出的是"可能会"而非"一定会"的后果
【当你不确定谁是对的时的操作】（全手册唯一需要记住的判断句）
► 「如果去掉这个 [接口/配置/抽象层]，
会在什么具体场景下出什么具体问题？」
- Claude 能清晰回答 → 认真考虑保留
- Claude 回答模糊 → 去掉它
────────────────────────────────────────────────────────────────────────────────
5.4 对话示例——完整辩护对抗流程
────────────────────────────────────────────────────────────────────────────────
场景：你要一个解析 CSV 的函数，Claude 给了支持 10 种格式的解析器框架。
你：「只需要一个函数，去掉框架。」
Claude 辩护：「CSV 有很多变体（不同分隔符、引号规则、编码），
这个框架可以统一处理，避免以后分别处理每种情况。」
你：「我的 CSV 格式是固定的：逗号分隔，UTF-8，有表头。
只有这一种格式。请给我处理这种格式的最简单函数。」
Claude 再次辩护：「但如果以后格式变了……」
你（终止辩护）：「如果格式变了，我到时候再处理。
现在只需要处理当前格式。请给我代码。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第六章：决策框架——复杂度是否合理的判断体系
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
6.1 质询三问——对每个设计决策的标准追问
────────────────────────────────────────────────────────────────────────────────
问题 1：「这个设计解决了什么具体的、现在已经存在的问题？」
✗ 假设性（"如果以后…"）→ 通常不需要
✓ 具体（"当 X 情况发生时会导致 Y 问题"）→ 可能合理
问题 2：「不这样做的最坏后果是什么？后果有多大概率发生？」
✗ 「可能不够灵活」→ 不需要
✓ 「一定会在 3 处重复相同逻辑，且三处会同步修改」→ 可能合理
问题 3：「现在加 vs 需要时再加，哪个总成本更低？」
大多数情况：等到需要时再加成本更低（届时需求更清晰，实现更准确）
例外：改动涉及不可逆的边界（如数据库 schema、公共 API 接口、加密算法）
────────────────────────────────────────────────────────────────────────────────
6.2 复杂度合理性判断流程图
────────────────────────────────────────────────────────────────────────────────
开始
│
▼
[这段逻辑重复出现了多少次？]
│ 1-2 次 ─────────────────────────────────→ 不抽象。两次重复是可接受的。
│ 3 次及以上
▼
[这三处重复会同步修改吗？]
│ 辅助判断：如果改了其中一处，另外几处会出 BUG 还是只是不一致？
│ → 会出 BUG 才算"同步修改"，只是"不一致"不算。
│
│ 不同步 ─────────────────────────────────→ 不抽象。它们只是形式相似。
│ 同步
▼
[抽象后的接口是否稳定？]
│ 辅助判断：接口的参数/返回值在未来 3 个月内是否已知不会变？
│ → 不确定的话等于是"为不稳定的接口过早抽象"，成本比收益高。
│
│ 不稳定 ─────────────────────────────────→ 等接口稳定再抽象。
│ 稳定
▼
[抽象后代码更容易还是更难理解？]
│ 辅助判断：删掉这一层，调用方的代码是变长了还是变短了？
│ → 如果调用方变短了，这层抽象在帮助理解；变长了则相反。
│
│ 更难 ──────────────────────────────────→ 不抽象。复杂度没有正回报。
│ 更容易
▼
✓ 这个抽象是合理的。
────────────────────────────────────────────────────────────────────────────────
6.3 复杂度合理的具体情形
────────────────────────────────────────────────────────────────────────────────
以下情形中，较高复杂度是合理的，不应盲目反对：
✓ Rule of Three 满足：同一逻辑第 3 次出现，三处会同步修改
✓ 已知的变化轴：明确知道这个逻辑会在某个维度上变化（不是"可能"）
✓ 信任边界处：用户输入、外部 API 的校验是必要的
✓ 不可逆操作：删除、支付、发送——需要完善的错误处理
✓ 已知的性能瓶颈：有 profiling 数据支撑，而非猜测
────────────────────────────────────────────────────────────────────────────────
6.4 Second System Effect（第二系统效应）
────────────────────────────────────────────────────────────────────────────────
Fred Brooks《人月神话》：「工程师在第二个项目中，倾向于把第一个项目里
所有'想加但没加'的东西全部塞进去，导致第二个系统往往是最失败的。」
Claude 的等价行为：
· 你在第一轮对话里要了一个简单的 CRUD
· Claude 给了一个简单实现，但在回复里提了很多"可以改进的方向"
· 第二轮你要加一个小功能，Claude 把那些"改进方向"全部塞进来
识别：「Claude 是否在利用这次任务，把上一轮没有实现的复杂度加进来？」
干预：
► 「这次任务只需要做 [X]，上一次讨论的其他改进方向不在本次范围内。
请只做 [X]。」
────────────────────────────────────────────────────────────────────────────────
6.5 对自己的简化判断进行压力测试
────────────────────────────────────────────────────────────────────────────────
本手册专注于对抗 Claude 的过度工程，但你自己的"简化偏好"也可能出错。
以下是你应该质疑自己的信号：
你可能错误地要求简化，如果：
✗ 你要删除的是 Claude 明确能描述出具体使用场景的错误处理
✗ 你要删除的校验处于信任边界处（用户直接提交的数据）
✗ 你的"简化"会导致代码在某个你承认存在的场景下静默出错
✗ 你对 Claude 说"以后再加"，但"以后"实际上是下周而非遥远未来
如何检查：
► 「如果我删除这段错误处理，在什么条件下程序会静默出错而不是抛出异常？
静默出错的危害是否比维护这段代码的成本更高？」
────────────────────────────────────────────────────────────────────────────────
6.6 演进触发条件——何时主动引入复杂度
────────────────────────────────────────────────────────────────────────────────
本手册反复强调"等到需要时再加"，但"需要时"需要有可量化的触发标准，
否则永远等不到，也永远不知道什么时候该演进。
（以下为参考起点，不是硬性规则——根据你的项目复杂度和个人习惯调整数字）
【从单文件到模块化】
触发条件：单文件超过 800 行，或者两个以上"不相关的功能"开始互相影响
动作：提取独立模块，不是"以后可能需要用到的工具类"
【从硬编码到配置化】
触发条件：同一个值在两个不同地方需要被修改，或者真实用户/场景需要不同值
动作：提取配置项，不是"看起来像是可配置的值就配置"
【从单一实现到接口抽象】
触发条件：Rule of Three 触发（第三次重复且三处同步修改），或
新需求要求同一"位置"支持两种不同行为
动作：提取接口，此时需求已清晰，抽象的形状是确定的
【从无错误处理到加错误处理】
触发条件：这个操作涉及外部系统（网络、磁盘、第三方 API），或
这个操作是不可逆的（删除、发送、支付）
动作：加错误处理；内部函数的错误处理等到真实出错时再加
【从单进程到分布式/微服务】
触发条件：你有 profiling 数据证明单进程已经是瓶颈，或
法律/合规要求强制服务隔离，或
不同组件需要独立部署周期（已有多个人在同时修改同一个服务）
动作：分拆；猜测未来需要分拆不是触发条件
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 第七章：让 Claude 做自我审查
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
这一章的句式是让 Claude 自己对自己的输出做批判性审查。
在你不确定"Claude 是否过度工程了"时使用。
► 【首选】「把你输出的所有内容分成三类：
A. 我明确要求的 B. 你认为有益但我没要求的 C. 防御性/预防性的设计
然后只保留 A，把 B 和 C 列出来让我决定是否需要。」
（这一条覆盖面最广，能一次暴露所有多余内容）
► 「在给我代码之前，先回答：你加入了任何我没有明确要求的东西吗？
如果有，逐一列出，并说明是否真的必要。」
► 「假设你是一个极度简洁主义的工程师，会如何批评你刚才的方案？
然后按那个批评重新修改。」
► 「对这段代码做 YAGNI 审查：哪些部分是为了"可能需要"
而非"现在确实需要"而加的？」
► 「如果这段代码明天就被废弃，你加入的哪些东西是纯粹的浪费？
把它们列出来。」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第八章：实用模板（可直接粘贴）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
────────────────────────────────────────────────────────────────────────────────
【模板 0】精简会话开场白（3 行，每次新会话粘贴一次）
────────────────────────────────────────────────────────────────────────────────
整个对话遵守：YAGNI（不为假设需求设计），最小改动（只改任务相关代码），
建议分离（额外建议列在末尾，不直接加进实现）。
项目背景：[一句话描述规模]
────────────────────────────────────────────────────────────────────────────────
【模板 1】完整会话级行为契约（高精度控制）
────────────────────────────────────────────────────────────────────────────────
在我们的整个对话中，请遵守以下原则：
1. 只实现我明确要求的内容，不为假设需求设计
2. 有额外建议时，列在回复末尾的「可选项」中，不直接加进实现
3. 修改代码时，只改与当前任务直接相关的部分（包括修复 BUG 时）
4. 如果你认为需要更复杂的方案，先问我，等确认后再实施
5. 如果你对实现方式不确定，说出来，不要用添加抽象层来规避不确定性
项目背景：[描述项目规模和生命周期]
---
────────────────────────────────────────────────────────────────────────────────
【模板 2】YAGNI + KISS 代码审查（针对已有代码）
────────────────────────────────────────────────────────────────────────────────
对以下代码做 YAGNI + KISS 审查，按优先级列出问题：
P0（应该删除）：
· 完全未被调用的函数/类/变量
· 注释掉的代码块
P1（建议简化）：
· 只有一个实现的接口/抽象类
· 为假设性未来需求存在的代码
· 对不可能发生情况的错误处理
· 只转发调用、没有独立逻辑的中间层
P2（可以考虑）：
· 可用原生 API 替换的第三方依赖
· 只重复代码内容的注释
对每个问题：说明简化方案，以及简化后会失去什么（如果有）。
代码：[粘贴代码]
────────────────────────────────────────────────────────────────────────────────
【模板 3】分级方案请求（防止 Claude 只给"最完整"方案）
────────────────────────────────────────────────────────────────────────────────
对于 [任务描述]，请给我分级方案：
Level 1（最小可用）
· 最少代码，完成核心功能
· 适合：原型、一次性脚本、MVP 早期
· 估计行数：___
Level 2（生产就绪）
· 基本错误处理、基本日志
· 适合：小团队内部工具、中期项目
· 估计行数：___
Level 3（可扩展）
· 扩展点、测试、文档
· 适合：长期维护、高流量、多依赖方
· 估计行数：___
根据我的项目背景（[描述]），推荐哪个 Level？
以及，选低于推荐 Level 的版本，具体会在什么情况下出什么问题？
────────────────────────────────────────────────────────────────────────────────
【模板 4】不确定性挖掘（当你怀疑 Claude 在用复杂度对冲不确定性时）
────────────────────────────────────────────────────────────────────────────────
在你给我代码之前，请回答：
1. 要确定最佳实现方式，你还需要知道哪些信息？
（如果没有缺口，直接说"信息已足够"；如果有，具体列出每条）
2. 你的方案中，哪些设计决策是为了"以防万一"而非"确实需要"？
3. 如果我们先把第 1 题的信息缺口补上，方案会变得更简单吗？
根据你的回答，我们先确定需求和约束，再写代码。
信息缺口应该通过提问来填补，而不是通过增加抽象层来规避。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
附录：全手册唯一需要记住的判断句
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 「如果去掉这个 [接口/配置/抽象层]， │
│ 会在什么具体场景下出什么具体问题？」 │
│ │
│ - Claude 能清晰回答 → 认真考虑保留 │
│ - Claude 回答模糊 → 去掉它 │
│ │
└─────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
核心理念
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【简单是一种能力，不是妥协】
复杂化很容易，简化需要判断力。要求 Claude 简化比要求 Claude 添加更难。
【YAGNI 是默认值，例外需要举证】
不是"为什么要简单"，而是"为什么要复杂"——复杂一方负有举证责任。
举证标准：具体的、现在已知的场景，而非假设性推断。
【规模匹配才是好设计（Gall's Law）】
适合大型项目的架构用在个人项目上是过度工程，不是高质量。
【Claude 的复杂度可能是它的不确定性，不是你的需求】
当你无法理解 Claude 为什么要这样设计时，追问它是否在用抽象层对冲不确定性。
（模板 4）
================================================================================
文档结束 v4.0 | 配套：AI编程调试提示词手册.txt