迭代要快，别等完美
先出粗糙能跑的版本，再逐轮打磨。每轮提交一次，让迭代又快又有安全网。
新手 vibe coding 一个常见误区：想让 AI 第一次就写出能直接上线的完美版本——结果来来回回改 N 轮，每轮还都是推翻重来。真正顺手的做法是：先出一个粗糙能跑的版本，然后快速迭代打磨。
读完你能回答：
- 为什么「先实现再完美」更适合 vibe coding？
- 怎么让迭代又快又不翻车？
- 什么时候该停——不再打磨了？
先粗糙后打磨
- 粗糙版先行：任何功能，先让 AI 出一个能跑的粗糙版。能用、能看、能验证，就先立住
- 别在前期纠结细节：样式、边界、完美逻辑，等跑了再补
- 粗糙版是「见过的版本」：把你想要的东西先变得「看得见」，剩下的调整才有参照
先实现、后完美，是快速验证想法能不能成立的最短路径。
每次迭代小一点
- 一轮改一点：每一轮只确定一个「这一轮要变什么」，别贪多
- 改完就验证：这轮的改动对不对，跑一下、看一下 copilot-cost
- 对了就提交：把它变成新的安全点
小步迭代 + 每步提交，你永远有一个「上一个能工作的版本」可以回退，出问题不至于从头再来。
什么时候停
打磨没完没了，给一个停的标准：
- 功能满足验收标准了吗？→ 满足了就停
- 再改下去是在做「锦上添花」还是「修 bug」？→ 前者先停，安全、体验优先级另外排
- 用户真的会用到吗？→ 只打用户会碰的角落
记住「丑但能跑」优于「美了但没上线」。先稳住一个可用版本，比追求完美更重要。
迭代材料积累好了，下一步进入验收环节：审阅 AI 的产出，学会判断你要不要收这次结果。