让 AI 主动质疑自己的设计

AI Coding 里一个很重要的能力，不是让 AI 多写代码，而是让 AI 主动质疑自己的设计。

现在用 Codex、Claude、Cursor 这类工具写代码，最容易产生一种错觉：模型越强，工程质量就越高。

但实际用久了你会发现，AI 最大的问题之一往往不是“不会写”，而是“太会写”。它可以很快生成一套看起来完整、专业、抽象层次分明的方案，但这个方案未必适合当前项目。

尤其在真实业务里，很多问题本来只需要一个简单函数、一个明确分支、一个普通组件，AI 却很容易写出一套完整的：

TaskManagerFactory
TaskStrategyRegistry
TaskExecutionContext
TaskStateHandler

最后你回头一看，实际业务只有 3 个状态。

这不是工程化，这是复杂化。

AI 很容易把简单问题复杂化

程序员自己也会过度设计，AI 只是把这个倾向放大了。

因为 AI 训练语料里有大量“看起来很工程化”的代码：设计模式、架构分层、可扩展框架、通用抽象、策略模式、注册中心、生命周期管理器。于是它在面对一个普通需求时，很容易默认走向“更完整”的方案。

问题在于，完整不等于合适。

常见的过度设计包括：

• 为了未来可能的需求提前抽象
• 多封装一层 service、manager、handler
• 为了“优雅”引入复杂模式
• 把一次性逻辑做成通用框架
• 给小团队项目套大厂工程结构
• 为了理论最佳实践增加维护成本

这些东西单看都不一定错，但放到小团队、早期项目、业务还没稳定的场景里，就很容易变成负担。

[!WARNING] 过度设计最危险的地方是，它一开始看起来不像错误。它甚至显得很专业。真正的问题会在三个月后、半年后维护时出现。

关键词：避免过度设计

以后和 AI 协作时，一个非常值得长期复用的关键词是：

避免过度设计（overengineering）

这句话的作用不是让 AI 写得更少，而是让它重新检查：当前方案是不是超过了问题本身的复杂度。

AI 默认会倾向于“把方案做完整”。但真实工程里，更重要的是“刚好够用”。

尤其是两个人小团队，最怕的不是代码不够高级，而是项目太早染上“大厂病”：抽象很多、概念很多、文件很多，但真正的业务路径反而越来越难看懂。

Prompt 1：审视是否过度设计

这是最常用、也最推荐长期放在手边的一段 Prompt。

请审视当前方案是否存在过度设计（overengineering）。

重点检查：
1. 是否为了未来可能的需求做了过多抽象
2. 是否增加了不必要的层级/封装
3. 是否可以用更简单直接的实现
4. 是否存在“为了优雅而复杂”
5. 是否符合当前项目规模和团队情况

如果有，请给出更简单、更务实的方案。

这段 Prompt 的价值在于，它不是让 AI “继续优化”，而是让 AI 反过来质疑自己。

很多时候你会发现，AI 第二轮给出的方案会明显更朴素：少一个接口、少一个抽象类、少一个 registry，甚至直接承认原方案没有必要。

这才是有用的 AI 协作。

Prompt 2：像维护者一样思考

AI 很擅长完成当前任务，但它不一定天然关心半年后的维护体验。

所以你可以让它切换视角。

请从“半年后维护这个模块的人”的角度，重新审视当前实现。

重点关注：
- 可读性
- 复杂度
- 调试难度
- 是否容易理解
- 是否真的需要这么多抽象

请指出当前实现中未来维护成本最高的地方，并给出更容易维护的版本。

这个 Prompt 特别适合在 AI 已经写完一版代码之后使用。

因为第一版代码经常能跑，但不一定好维护。你让 AI 从“交付者”切换成“维护者”，它就会开始注意命名、调用链、状态流转、调试入口这些更实际的问题。

这一步很重要。

代码不是写完就结束。真正的成本发生在下一次需求变更、下一次线上 bug、下一次别人接手的时候。

Prompt 3：小团队长期维护原则

如果项目只有一两个人维护，很多所谓“最佳实践”都要重新评估。

不是说最佳实践错了，而是它们通常默认你有更多人、更长周期、更复杂组织和更稳定的边界。

小团队需要的是另一套优先级。

请按“小团队长期维护”的原则优化方案：

- 优先简单
- 优先可读
- 优先少抽象
- 优先少依赖
- 优先业务直观
- 不要为了理论最佳实践增加复杂度

请保留当前业务真正需要的部分，去掉不必要的工程化设计。

这段 Prompt 很适合小团队、个人项目、外包项目、早期产品。

它的核心不是“写得随便一点”，而是把复杂度花在真正有价值的地方。

少抽象不等于低质量。很多时候，少抽象反而更专业。

让 AI 给两个版本

还有一个非常实用的技巧：让 AI 同时给出简单版和扩展版。

请分别给出：
1. 最简单直接的实现
2. 更可扩展的实现

并说明：
- 两个方案分别适合什么场景
- 当前项目阶段更推荐哪个
- 如果选择简单方案，未来扩展时需要注意什么

这个方法很好用，因为它不会直接否定扩展性，而是把选择权拿回来。

AI 默认可能会给一个“工程化复杂方案”。但当你要求它同时给出两个版本，它往往会承认：当前阶段其实更适合简单实现。

这就是关键。

我们不是反对架构，不是反对设计模式，也不是反对扩展性。我们反对的是，在业务还没证明需要复杂度之前，就提前支付复杂度成本。

可以定一条团队 AI 原则

如果团队长期使用 AI 写代码，我建议定一条很简单的原则：

不要为了未来需求设计未来系统。
优先满足当前业务。

这句话听起来普通，但非常有用。

它可以压住 AI 的抽象欲，也可以压住程序员自己的抽象欲。

每次 AI 想引入新层级、新接口、新 manager、新 hook、新 service 时，都可以问一句：

这个抽象现在解决了真实问题，还是只是在服务一个未来想象？

如果答案是后者，就先别加。

AI 架构师思维

很多人理解 AI Coding，还停留在“怎么写 Prompt”“怎么让 AI 更快生成代码”。

但真正重要的能力，可能是另一件事：

控制 AI 的复杂度。

AI 可以让你更快写出代码，也可以让你更快堆出一座复杂系统。

所以你不能只做需求方，不能只说“帮我实现”。你还要学会当审查者，要求 AI 解释设计，质疑抽象，删除多余层级，把方案压回项目真实需要的大小。

这才是 AI 架构师思维。

不是让 AI 写更多，而是让 AI 在该停下来的地方停下来。

写在最后

好的 AI 协作，不是把所有事情都交给 AI。

而是你能控制它的方向、边界和复杂度。

当 AI 给出一个很“完整”的方案时，不要急着接受。先问它：

有没有过度设计？
有没有更简单的做法？
半年后维护这个模块的人会不会骂我？

如果这三个问题都过了，再继续往下写。

工程质量很多时候不是来自更多抽象，而是来自更少的、不必要的抽象。

把简单问题保持简单，是 AI Coding 里非常重要的能力。