不接受分期交付
AI 爱做「先上简版」的真实原因，以及为什么要打破这个模式
本页解决的问题
先给结论「不接受分期交付」要解决的关键问题是什么？
AI 爱做「先上简版」的真实原因，以及为什么要打破这个模式
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
实践中 AI 说「先做简版」往往与复杂度无关，它想快速给你一个能跑的东西来换取正反馈。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。打破这个模式后，AI 反而会更认真地分析完整方案。
点击播放，看「先做简版」的登录模块在 90 天里怎么变成永久技术债。上方两个数字会随时间线一起变化。
简版上线
用户名密码登录能跑了，AI 承诺「OAuth 后续再加」，你也觉得挺合理。
后续没有来
新需求源源不断，没人回头补 OAuth。会话、权限、支付、通知 4 个模块开始直接依赖简版接口。
成为永久技术债
想补全时发现依赖已经长死，9 个模块与简版耦合，重构成本高过重写。简版成了永久版。
AI 提出了分期方案，你的回应决定了 90 天后的结局。两个分支都可以试。
禁止的做法
禁止以任何理由简化实现：「先用临时方案」「后续再优化」「暂时 Mock」「简单处理一下」全部不接受。也禁止 AI 主动规划分期、MVP、阶段一二三。每次实现都必须是完整、正确、没有代码债的方案。
替代的做法
评估一个功能只需回答：完整做下来需要什么、有多复杂。确实太复杂时，明确列出「需要你先做哪些前置决策」，把选择权交还给人。已知有缺陷的方案，直接给正确版本，别先做一个将就的。
大型项目里这条规则可能显得激进：一个功能真需要 2000 行代码时，一次写完不现实。此时正确动作依然成立，让 AI 给出完整方案和真实工作量，由人决定是否拆分、怎么拆分。拆分是人的决策，降级是 AI 的自作主张，两者的区别就是这条规则的核心。
「后续再优化」的后续永远不会来。把选择权收回来：AI 负责给出完整方案和真实代价，拆不拆、怎么拆由人决定。
从「动机分析」把感觉变成判断
「实践中 AI 说「先做简版」往往与复杂度无关， 它想快速给你一个能跑的东西来换取正反馈 。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。打破这个模式后，AI 反而会更认真地分析完整方案」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「点击播放，看「先做简版」的登录模块在 90 天里怎么变成永久技术债。上方两个数字会随时间线一起变化」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「「后续再优化」的后续永远不会来。」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「动机分析」走到「交互演示一 · 技术债时间线播放器」
「动机分析」先把问题落在「实践中 AI 说「先做简版」往往与复杂度无关， 它想快速给你一个能跑的东西来换取正反馈 。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。打破这个模式后，AI 反而会更认真地分析完整方案」上；到了「交互演示一 · 技术债时间线播放器」，讨论继续推进到「点击播放，看「先做简版」的登录模块在 90 天里怎么变成永久技术债。上方两个数字会随时间线一起变化」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「动机分析」：实践中 AI 说「先做简版」往往与复杂度无关， 它想快速给你一个能跑的东西来换取正反馈 。「先用临时方案」「暂时 Mock」「简单处理一下」背后是同一个模式。打破这个模式后，AI 反而会更认真地分析完整方案
- 「交互演示一 · 技术债时间线播放器」：点击播放，看「先做简版」的登录模块在 90 天里怎么变成永久技术债。上方两个数字会随时间线一起变化
- 「最后的要点」：「按规则来：给我完整方案和工作量评估。确实太复杂就列出需要我先定的前置决策。」
最后的「最后的要点」把讨论落到「「按规则来：给我完整方案和工作量评估。确实太复杂就列出需要我先定的前置决策。」」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。