不接受分期交付
你要一个完整的认证系统，AI 说「先做一个简版的用户名密码登录，后续再加 OAuth」。后续永远不会来。这一节用两个演示，看清「先做简版」的完整生命周期，并练习正确的回应方式。
实践中 AI 说「先做简版」往往与复杂度无关，它想快速给你一个能跑的东西来换取正反馈。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。打破这个模式后，AI 反而会更认真地分析完整方案。
点击播放，看「先做简版」的登录模块在 90 天里怎么变成永久技术债。上方两个数字会随时间线一起变化。
简版上线
用户名密码登录能跑了，AI 承诺「OAuth 后续再加」，你也觉得挺合理。
后续没有来
新需求源源不断，没人回头补 OAuth。会话、权限、支付、通知 4 个模块开始直接依赖简版接口。
成为永久技术债
想补全时发现依赖已经长死，9 个模块与简版耦合，重构成本高过重写。简版成了永久版。
AI 提出了分期方案，你的回应决定了 90 天后的结局。两个分支都可以试。
禁止的做法
禁止以任何理由简化实现：「先用临时方案」「后续再优化」「暂时 Mock」「简单处理一下」全部不接受。也禁止 AI 主动规划分期、MVP、阶段一二三。每次实现都必须是完整、正确、没有代码债的方案。
替代的做法
评估一个功能只需回答：完整做下来需要什么、有多复杂。确实太复杂时，明确列出「需要你先做哪些前置决策」，把选择权交还给人。已知有缺陷的方案，直接给正确版本，别先做一个将就的。
大型项目里这条规则可能显得激进：一个功能真需要 2000 行代码时，一次写完不现实。此时正确动作依然成立，让 AI 给出完整方案和真实工作量，由人决定是否拆分、怎么拆分。拆分是人的决策，降级是 AI 的自作主张，两者的区别就是这条规则的核心。
「后续再优化」的后续永远不会来。把选择权收回来：AI 负责给出完整方案和真实代价，拆不拆、怎么拆由人决定。