先搭好地基，再 AI Coding

先说结论

要先搭好 可持续迭代 的地基，再谈 AI Coding。
AI Coding、Vibe Coding 都依赖多轮演化；我们实践时主要用 Agent 把「写—跑—看—改」串起来。
地基不好，模型再强也只是多轮碰运气；地基好了，Agent 才能自动朝验收目标收敛。

环境至少要让下面这个循环能 自动、反复 发生：

能执行——改完能跑，输入输出清楚。
能观察——测试、日志、产物能说明成败。
能再改——同一套规则下进入下一轮。
能收敛——有设计文档、验收标准、测试设计，迭代是朝目标靠近，不是随机改。

定好标准与测试之后，应能交给 Agent：实现 → 观察 → 修改 → 再观察…… 往验收项靠。
可持续，指的就是这套循环能不靠人每次手动点「再试一次」而持续转下去。

会长期演化的项目，不是「设计一次、手写到底」。
顺序反了：人一直救火，Agent 没有稳定反馈，迭代断掉。
顺序对了：人定场子与标准，Agent 在场子里长跑。

所以启动项目时，优先问：这个环境支不支持可持续迭代？而不是先问：要用哪个最强模型？

墙钟可以很长——中间大段时间是模型/Agent 自己在循环里跑。
人真正参与的时间往往更短，但其中一大部分花在：环境搭建、验收标准、测试设计、边界与设计文档——不是替 Agent 敲完每一行业务代码。

人的杠杆在地基，不在手写完整实现。
这也是为什么「环境构建」看起来不炫，却常常吃掉一半甚至更多的人时。

举个简单例子：系统要从 Jenkins 取版本，再拉包、解压、做一些固定操作。
若「可测」绑死 真实、稳定的 Jenkins，环境就不在你控制里。外部一抖，观察失真，迭代中断。

强依赖不稳定的外部环境，就谈不上可持续迭代。
问题往往不在业务逻辑难，而在 观察链路依赖了你控不住的东西。

实操上，一般不追求 1:1 复刻 Jenkins 内部，而是：

用脚本做 黑盒替身——行为、接口「看起来够像」即可。
例如定时或随机产出发版信息，并暴露标准 API。
Agent 只对着接口实现与验收；不必去读模拟脚本内部怎么写。

人把契约和验收定清楚，模拟环境负责稳定地「像真环境一样响应」。
这样，观察和修改才能在本地闭环，循环才转得起来。

Agent 是执行循环的手段，不是地基本身。实践时大致是：

人先准备：设计文档、验收标准、测试设计、以及上一节的模拟环境。
再启动 Agent：按标准实现，少干预。
循环中：跑测、看日志/产物 → 改代码 → 再跑；卡住时人再介入。
收敛：逼近验收项；人确认达标，或必要时改标准。
可选：路径成熟后固化成普通脚本，降成本、增可控。

要点只有一句：循环能不能转，取决于地基；Agent 负责在地基上把循环跑起来。

角色	做什么
人	建可持续迭代的环境，定标准与测试，必要时模拟外部
Agent	在环境里自动实现、观察、修改，朝验收收敛

先搭好地基，再 AI Coding。
用 Agent 在可迭代的场子里长跑，而不是在沙滩上盖楼。