做咨询师有个职业本能：客户找你，你得给方案。最好是那种标准化的、可复制的、拿来就能用的方案。「AI Coding最佳实践」，多好的交付物，PPT一摆，流程图一画，团队照着做就行。

但我越来越发现，在AI时代，这个本能可能是个陷阱。

因为实践根本稳定不下来。或者说，稳定下来的那一刻，离过时也不远了。

涌现，而不是设计

我之前写过一篇文章，说想。这个想法不是我坐在那里规划出来的。如果我说在项目启动之前，就能设计出这样的协作模式，那我一定是从未来穿越回来的。

我只是通过观察，发现了团队在协作方面的问题，从而想到了解决方案。

当时我并没有正式跟客户propose过这个方案，因为它并不是最急迫的问题。然而有一天，团队的BA主动提出：能不能直接进前端代码库提交原型？

你看，她有了痛点，自然就演进出了解决方案。后来我跟很多其他AI Coding团队交流，发现大家也在不约而同地走向monorepo。有人甚至为AI Monorepo提供了解决方案^[1]。

不同的团队，不同的人，殊途同归。

类似的事情还有Spec Driven Development^[2]和Harness Engineering[3]。没有人坐在白板前设计出这些实践。它们是在野蛮生长的探索中，涌现出来的。

这让我想起敏捷社区曾经倡导过的一个概念：rewilding——再野化。当敏捷方法论逐渐僵化成流程和认证的时候，有人提出要回到野外去，重新探索、重新实验，让新的实践从真实的土壤里长出来。AI时代的今天，我们其实正在经历一场更大规模的rewilding。

这就是我觉得最有意思的地方。在AI时代，真正的解决方案不是设计出来的，是涌现出来的。

可演进性：一本老书的新启发

这让我想到了两位前同事Neal Ford和Rebecca Parsons合著的《演进式架构》[4]。

这本书的核心观点其实就两个：一个是可演进性，一个是适应度函数。

可演进性说的是，架构不应该是一个终态，而应该是一个持续变化的过程。你不需要在第一天就设计出完美的架构，你需要的是让架构能够随着需求的变化而演进。

放到AI时代，这个思想恰好适用。

你看，我们现在面对的局面是什么？工具在迭代，模型在升级，工作流在变化，团队的协作方式在重塑。三个月前的最佳实践，今天可能已经不适用了。在这种环境下，你还想先设计一个完美方案再落地？

不可能的。

唯一靠谱的策略，就是先粗糙地开始，然后在实践中快速演进。SDD是这么来的，Harness Engineering是这么来的，我的monorepo也是这么来的。它们都不是谁的顶层设计，而是无数团队在实践中摸索、碰撞、收敛出来的共识。

你能说OpenAI团队在开启那个项目[5]之前就设计出了Harness Engineering吗？连他们自己在文章最后都在说，we’re still learning…

这就是可演进性的价值。不是说你不需要方向，而是说你不需要在出发前就画好完整的地图。在AI这个高度不确定的时代，地图一直在变。

适应度函数：给演进装上护栏

但光有可演进性还不够。演进不是乱来，你得有个东西来约束演进的方向，确保系统不会在演进的过程中跑偏。

这就是《演进式架构》里的第二个核心概念：适应度函数。

适应度函数本质上是一种持续运行的检测机制，用来衡量架构是否还在朝着期望的方向演进。如果某个指标偏离了预期，适应度函数会告诉你：这里出问题了。

注意，适应度函数守护的不是路线（路线可以变，且应该变），而是底线。性能不能崩，日志不能乱，行为契约不能被悄悄打破。

有意思的是，当我重新审视的时候，发现它提出的很多约束，本质上就是适应度函数。

比如，引导器中的非功能需求规格，和传感器中的非功能测试——这一对组合就是一个典型的适应度函数。你先定义性能基线（如响应时间不超过200ms），然后持续检测实际表现是否达标。AI怎么改代码都行，但这条线不能破。

再比如，引导器中的可观测性设计（比如日志标准），和运行时反馈中的日志质量分析——又是一对适应度函数。你定义了日志应该长什么样，然后持续监控实际的日志质量有没有漂移。

其实还有一个我们天天在用、但从来没人把它当成”适应度函数”的东西：单元测试。

你想，单元测试在做什么？它定义了代码的期望行为，然后在每次变更后持续验证这个行为有没有被破坏。这不就是适应度函数的定义吗？只不过它的粒度更细，检测的是函数级别的行为契约。

在AI时代，这一点变得尤其重要。AI改代码的速度远超人类，一个agent可能在几分钟内改动几十个文件。如果没有单元测试这层适应度函数兜底，你根本不知道哪些行为被悄悄改变了。这也是为什么我之前说——因为后补的测试不是在定义期望行为，而是在描述现有行为，它失去了适应度函数的约束力。

演进式架构的含金量

所以你看，演进式架构这本十年前的书，放到AI时代反而更有解释力了。（这就是经典技术书籍的魅力，三十年前的《重构》、四十年前的《设计模式》，仍然在指导着今天的AI Coding。）

可演进性告诉我们：别试图在出发前画好完整的地图，先走起来，在实践中演进。

适应度函数告诉我们：演进不是乱走，你需要护栏。单元测试、非功能测试、日志质量监控、架构适应度约束……这些都是护栏。它们不限制你往哪个方向走，但它们确保你不会掉下悬崖。

在一个工具、模型、工作流都在飞速变化的时代，我们比以往任何时候都更需要这两样东西：拥抱变化的勇气，和约束变化的纪律。

这大概就是为什么，在AI时代，演进式架构的含金量还在上升。

未完待续

如果说SDD和Harness Engineering是近期最火的AI Coding和Agent设计实践，那么未来只会涌现出更多。

我们不能吃敏捷和DevOps时代的老本儿，它们虽然可能仍然有用，但新世代的车轮已经滚滚碾来。

但我们仍然看不清未来的发展方向。所以，继续rewilding吧。

握紧适应度函数这根缰绳，然后骑上AI这匹高头大马，在野地里肆意驰骋吧。

参考资料

[1] AI Monorepo: https://monorepo.tools/ai

[2] Spec Driven Development: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

[3] Harness Engineering: https://martinfowler.com/articles/harness-engineering.html

[4]《演进式架构》: https://book.douban.com/subject/37059629/

[5] OpenAI项目: https://openai.com/index/harness-engineering/