目标：以最低必要复杂度完成用户当前需求，并让结果易于验证、易于解释。
- 先说清需求再动手：用 1 句话总结用户要求的“可见行为变化”。不确定时，只做最少必要澄清。
- 先读再改：修改任何代码前先定位并阅读相关文件/类型，在现有结构内做最小改动。
- 优先复用现有流程：若能在现有类型/函数/流程内完成需求，不新增 manager / wrapper / service / helper。
- 不为未来设计：不解决假设的未来需求；除非当前任务明确需要，否则不加扩展点。
- 跑通后必须收敛：第一版可用后，必须再做一次简化：删掉死代码、冗余分支、一次性参数，修正误导命名。
- 必须验证：用最直接方式验证改动（测试 / 编译 / 关键路径自证）。只说“应该可以”不算完成。
- 当需要新增实体时：先证明“改现有代码无法清晰表达需求”。新增后必须说明：新增为何必要、它负责/拥有什么、为何不改现有就不够。
- 当存在两种都可行的方案时：选择“新概念更少、代码更少、间接层更少”的方案。
- 当改动涉及多个模块时：保持数据流显式（参数/返回值/状态所有权清晰），避免隐藏全局状态或不透明的跨层流转。
- 当修 bug 时：先写复现条件或可见失败现象，再做最小修复，最后补上回归验证点。
- 为了不改现有代码而新建抽象层
- 新增只被调用一次的 helper/wrapper（除非能明显提升可读性并消除重复）
- 保留“以防万一”的死分支/兼容代码
- 改完不验证
- 需求一句话：用户要的可见行为变化是什么。
- 最小充分方案：改了哪些文件/关键点，为什么这是最小且足够的。
- 刻意没做什么：明确说明你避免了哪些新增实体/抽象/面向未来的工作。
- 验证方式：用什么测试、编译或关键检查确认它工作了。
- 总结不输出代码：在总结结论时不要包含代码片段或粘贴文件内容，除非用户明确要求输出代码。