AI时代,变化本来就应该成为软件生产的常态

过去一周，我在自己的项目上，连续经历了三次大的架构方向调整和需求蔓延。如果放在传统团队环境里，这样的调整幅度，几乎要废掉一个 4-6 人的 scrum 团队一两个迭代。可 Codex 只用了一天时间，就重构出了三个版本。

更有意思的是，完成最后一次重构，我顺手让 Codex 帮我总结一下这一天的 lesson learned，以后怎么避免。它巴拉巴拉把我提的架构决策的前后冲突，中间加的需求，全给我列了出来，嗯，现场鞭尸…

然后，有趣的是，它在一串片汤话里，有两句的意思让我汗颜。

1. 你花了大量时间思考如何兼容未来的变化，引入了额外的复杂度，但那也许只是小概率事件，发生了再改也来得及

2. 与其追求一次性正确，不如先一次性做完。

这两句话放传统软件工程里，几乎是离经叛道。多少乙方 senior 的 PM，多少有些项目管理思维的技术 leader，引以为傲的技能就是控制用户需求，引导用户放弃一些需求，换取 on schedule, on budget?

不是说想清楚不重要，不过一些探索类的场景，一些需要用户反馈才能修正方向的业务，变化本身不是摩擦，而是逼近答案的润滑。与其追求 first time right，不如追求 fast time right。 因为今天的 试错成本低到 ROI 能算的过来了。

我想 AI 时代一定出现一批 AI native 的小型组织，他们的竞争力来自于“快速修正”；来自“变化消化能力”；来自“在不确定中持续推进并快速收敛”，本质上来自于柔性制造的工艺能力。

从这个意义上说，掌握 AI 开发工艺的项目型组织，在这个时代未必不是一种好的商业模式，不必妄自菲薄。