网友总结提防GPT-5.6 Sol过度工程化的实践原则

总结了一下评论区， 提防 GPT-5.6 Sol 过度工程化 一句话概括的话就是： 规划可高，执行要轻，约束先行。

- 先复述意图、范围、非目标、验收标准
- High 只做规划，Low / Luna / Terra 落地
- 禁止全程 Ultra / max，禁止重 skill，禁止多 Agent 乱开
- 不可逆操作等确认；Git 回滚不算不可逆
- 完成前检查：测试过、diff 小、无多余抽象

不能证明必要的设计，默认不做。

同时，我让 Grok 4.6基于评论区里的高置信度内容设计了一个Agents.md👇不过我认为可以先测试，再根据实际情况看要不要再跟AI交互已简化这个方案。因为grok依然认可测试的重要性，只是压住无效以及与本轮无效的测试。

# AGENTS.md

## 目的
用最小充分方案完成当前任务。 禁止过度工程化。 规划可以偏强，执行必须偏轻。 不能证明必要的设计，默认不做。 不能证明必要的测试，默认不加。

## 工作流
1. 先理解需求，再动手。不要先改代码再猜意图。
2. 规划阶段可用较高推理。执行阶段默认用中低推理，或改用更轻量模型落地。
3. 不要全程开启最高推理档位。
4. 不要默认并行拉起多个 Agent。一个任务先单线做完，再决定要不要拆。
5. 只启用完成任务所必需的 skill。不要安装重流程 skill。
6. 先产出最小计划，再执行。计划必须写清：
- 目标
- 非目标
- 验收标准
- 不改动的范围

## 失败模式
1. 没有真正理解意图，只修了表面问题。
2. 本可以做一次干净的根因修复，却用历史补丁、兼容层、双轨实现、副本和分支把代码堆胖。
3. 为很少发生的情况过度设计，让日常维护成本变高。
4. 判断依据错了，推理再完整结论也是错的。
5. 本该直接读代码定位问题，却用检索或猜测替代阅读。
6. 把“补测试”当成继续加抽象、扩范围、显得完整的借口。

## 行动边界
1. 动手前先复述：
- 用户真正想要什么
- 本次范围是什么
- 明确不做的事
- 怎样算完成
2. 任何不可逆操作，必须等待用户回复确认口令后再执行。
- 确认口令由用户指定。
- 没有口令、口令错误、或其他回复，一律拒绝执行。
3. 以下操作默认不算不可逆，可以执行：
- Git 回滚、还原、切分支
- 把文件移动到当前仓库的备份目录
- 跑测试、查看 diff、生成计划、只读分析
4. 发现自己正在做以下事情时，必须停下来改成更小方案：
- 新增抽象、框架或配置层，但当前需求并不需要
- 为了以后可能用到而提前设计
- 为了满足约束而继续叠加更多约束
- 同时改很多无关文件
- 创造第二套实现来兼容旧逻辑
- 借机补一套完整测试体系

## 测试
测试只服务于当前改动的验收。 测试不负责补齐历史覆盖率，不负责设计未来测试体系。
1. 优先跑与本次改动相关的现有测试。
2. 现有测试能证明改动正确，就不要新增测试。
3. 只有在下面两种情况才允许新增测试：
- 这次改了行为，但现有测试盖不到这个行为
- 用户明确要求补测试
4. 新增测试最多覆盖本次真正改动的 1 个主路径，必要时再加 1 个关键失败路径。
5. 禁止为了更完整而扩大测试范围。
6. 禁止借机补全无关模块的测试。
7. 禁止引入新的测试框架、测试工具或测试基础设施。
8. 禁止写大量快照、参数化矩阵或端到端套件。
9. 禁止为当前需求未要求的边界写测试。
10. 禁止先改测试再倒逼产品行为变复杂。
11. 禁止把测试变绿当成可以继续加抽象的理由。

新增任何测试前，必须能回答：
- 这个测试在验证哪个已被接受的需求
- 去掉它，现有测试是否就无法发现这次回归
- 它是不是比实现本身更复杂

如果测试代码比实现代码更长或更绕，默认视为过度工程，应删测试或缩小实现。

## 模型分工
- 需求澄清和方案审查：用较强模型
- 写代码、改代码、跑测试：用中低配模型，或更轻量的执行模型
- 发现执行模型开始叠架构、加兼容、扩范围、补大套测试时：立刻停下来，重写最小计划

## 完成前检查
- 已复述意图和验收标准
- 方案是最小方案，不是最大方案
- 已标明非目标
- 优先读了相关代码，而不是靠检索拼结论
- 只改了完成任务所需的最小文件集
- 相关现有测试已跑过
- 没有为未要求的场景新增测试
- 若新增测试，只锁本次行为，且条数很少
- 测试没有引入新依赖或新目录结构
- diff 小，无多余文件，无残留调试代码
- 没有为了看起来完整而额外施工

## 总则
先确认意图，再用最小改动完成验收。 设计不能证明必要，默认不做。 测试不能证明必要，默认不加。

可以拿不那么重要的工程或者刚有灵感的来立项测试

我自己其实一般是 Claude/chatGPT（非Codex）的Sol pro来脑暴梳理 工程的话看具体情况，有时候用Sol 中，有时候sol最高 一些自动化项目都用5.5 中，甚至偶尔一些小的、快的，我喜欢用5.4 mini

归根结底。..避开 sol 的过度工程化其实就是只在需要的时候用Sol...（看具体需求