规模化下的 Vibe Coding？工程体系的反击

生成式人工智能彻底改变了代码的生产方式。 短短几个月间，我们从仅能实现自动补全的工具，发展到能够编写、测试并部署整套应用程序的智能代理。 如今，市场中充斥着各种各样的方法，用于为这些智能代理构建框架，并使其产出高质量的代码。

然而，这种海量的工具选择也引发了一个鲜少被企业关注的问题：当您并非只打造一款应用，而是打造五十款应用时，会发生什么？

答案在于一个每个人都容易忽视的差异：一款软件即使“设计精良”，也可能并不符合“预期标准”。 结构化人工智能方法虽然能够达到“一流”的水平——也就是业界普遍认可的通用标准。 但一家企业的“一流”却属于“自身”：它基于特定情境，经过共识达成，且始终处于不断演进之中。 而这一点，正是人工智能所无法完全掌握的——在每一个项目中，它往往只是粗略地进行重新构想， 甚至失之于粗疏。

“行业前沿” ≠ “你的行业前沿”

让我们先澄清一个根本性的误解：不存在绝对的质量标准。

正如克里斯托夫·蒂博在《如何终结技术债务》一文中所提醒我们的那样：“‘质量’这一单一而普世的概念并不存在。 在雅典广场餐厅，你只需花费约380欧元就能享用一顿极佳的美食； 而在麦当劳，午餐价格不到8欧元，同样设有质量部门。 这两种标准截然不同——而且在各自的语境中都完全合理。 只要将它们的评判标准互换，就会出现两种荒谬的结果，而没有人会愿意为此买单。

所谓“行业前沿”，是指某一团队在明确或隐含的共识基础上，共同制定的一套实践规范——旨在在“自身”的语境下， 以“自身”的约束条件，打造出尽可能卓越的解决方案。 它既不具有普适性，也并非一成不变；它需要不断讨论、不断检验、不断更新。

然而，结构化人工智能方法本身也拥有自己的“行业前沿”：它是从互联网、各类库以及各种框架中积累的通用知识中提炼出的成果。 这种“行业前沿”固然价值连城，但它终究不是属于你的。 而挑战就在于：一款应用即便在通用标准下堪称完美，却可能完全偏离贵组织自身的规则与要求。

正因如此，我们区分了三种面向人工智能辅助开发的方法——这些方法并非依据其所使用的工具来划分，而是依据其所保障的“行业前沿”来区分。

氛围编码速度极快：你只需提出需求、反复迭代，并接受任何“看起来行得通”的方案。 这种方法非常适合用于原型开发、快速实验或探索阶段。 然而，代码的质量完全取决于你的输入提示和开发人员的技能水平。 既没有得到保证的“行业前沿”，也无法实现可重复性。

结构化人工智能辅助（其中，BMAD 是一个很好的例子）则更进一步。它通过设定模板、规则，并提供详尽的输入提示， 确保开发过程更加严谨规范。最终，你将获得一款结构良好、按照“标准流程”编写的应用程序。 这正是我们所说的情境确定性：对于这个项目，在这个特定的语境下，结果是可靠且可信赖的。

代理式工程则带来了系统性确定性。可靠性不再仅仅依赖于某一位开发者或某一条输入提示， 而是由一个平台来承担——这个平台让组织的“行业前沿”得以惠及每一位代理、 每一个项目、每一次开发工作。

区别不在于你是否使用人工智能，而在于你的方法究竟保障了怎样的“行业前沿”。灵感源自图3，摘自1。

结构化人工智能真正能做到什么——又不能做什么

公平地说，结构化人工智能确实迈出了重要的一步。它并非敌人，反而带来了氛围编码所无法提供的严谨性，帮助我们打造出高质量的应用程序。

然而，它也存在两个结构性的盲点。

第一个盲点：它强加了自己的构建链。它的模板、约定和步骤都是在组织之外精心设计的。 这些内容忽略了现有的流程——而这些流程恰恰是大型组织中确保客户期望的整体质量的关键所在。 这些流程当然需要不断更新，但绝非可以随意绕过。

第二个盲点：它所创造的确定性是局部的。 它对下一个项目毫无影响。下一个开发者、下一个代理、下一个项目都从零开始。 尽管可以遵循最佳实践，但未必完全契合组织自身的规则。 代码虽然制作精良，却未必与同一系统中的其他应用保持一致。

这时，很久以前就有人提到过的动态“杰里·温伯格”理念便派上了用场：

技术转移的第一定律：为了追求短期利益，往往会牺牲长期利益。 — 杰里·温伯格，《高质量软件管理》

结构化人工智能会优先考虑短期利益（即“这款”应用，快速且干净地交付），却以牺牲长期利益为代价——例如， 牺牲整个系统的整体一致性。对一个项目而言，这种做法看似无害； 但对五十个项目来说，却可能带来毁灭性的后果。

规模化带来的真正危险：重新发明“商品”

以下是混乱的精确机制。

当每个代理在不了解组织“行业前沿”的情况下自行构建应用时，他们会自己发明一套全新的体系。 更重要的是，他们会重新构建那些早已存在于其他地方的组件——却浑然不知。 身份验证、错误处理、可观测性、数据访问、用户界面组件：这些原本是现成的组件， 却被一个又一个项目重新构建、一遍又一遍地重构。

结果并不是N个优秀的应用，而是N个平庸的组件。 与其改进某个共享组件并持续提升其质量，不如将同样的需求分散成多个平庸且彼此迥异的版本。 没有任何一个应用能够真正走向规模化。

克里斯托夫·蒂博提出了一个比“技术债务”更精准的术语来描述这一现象：流程冲突。 一个解决方案并非“负债”；它依赖于那些从未被共同商定、却彼此矛盾的流程。 在人工智能出现之前，这种冲突很少发生，也几乎难以察觉：开发者们会在站会上遇到摩擦， 将其记录下来，冲突便会浮出水面并得到解决。

但在生成式人工智能的规模下，这种冲突的性质发生了改变，变得愈发严峻，原因有二：

• 它变得隐形。每个应用“看起来都很正常”，因为它们遵循的是通用的行业前沿标准。 没有人会感到任何摩擦。代理不会在任何环节遭遇障碍。 与组织的行业前沿标准之间的冲突，往往直到产品上线、发生事故、或者客户发现其中的不一致时才被察觉。

• 它会不断扩散。人工智能能够生成的应用数量庞大，使得原本零星的冲突逐渐演变成系统性的分歧。五十个项目意味着可能多达五十种相互不兼容的标准。

而账单总是会如期而至。因为信任是传递的。 最终用户信任一个品牌，而这个品牌会部署应用。 这些应用由代理来构建。一旦某一个环节出现故障，整个品牌的信任就会迅速瓦解。 高端品牌不可能容忍业余的用户体验；银行也不能容忍聊天机器人中出现安全漏洞； 电信运营商更不能让错误的语气在客户服务应用中悄然溜走。

每一个部署的应用，都在考验着品牌的声誉。信任的建立需要时间，而失去信任却只需一瞬间。

平台：让“行业前沿”变为可执行的现实

如果问题在于，代理们并非消费组织的“行业前沿”，而是自行重新发明它，那么解决方案其实非常简单：

一个代理式平台，就是将组织的“行业前沿”转化为可执行、可被人工智能消费的成果——并且以产品化的形式加以管理。

好消息是，这些原材料早已触手可及。安全策略、架构标准、设计系统、领域知识、 惯例规范——一切都在组织内部。问题不在于这些资源缺失——而在于它们并未被结构化， 以便代理们加以消费。它们散落在维基、人们的脑海中、PDF文件中、幻灯片中， 却无法被代理式系统所利用。

平台的作用，就是将这些组织内的宝贵资产转化为可消费的能力：对其进行整理、 工具化，并为其配备验证与防护机制。这些能力源自多位内容创作者——领域专家、 安全团队、品牌团队、架构师——并将它们开放给多位消费者——代理、项目、应用。

这正是桑吉特·保罗·乔达里在《平台思维：工作的未来》一文中所定义的平台的精髓： 一个连接生产者与消费者生态系统的系统，将可重复的操作商品化。 乔达里指出了一点至关重要：编写代码并不是一项可重复的操作——它更像是建造一条装配线这样一次性的基础设施活动。 真正可重复的是那些由代码自动化完成的操作。 平台正是将那些可重复的操作工业化，从而让整个生态系统能够专注于那些不可重复的事务。

实际上，平台提供了三大类系统性能力：

• 系统性情境（指令、领域知识、内存、示例）只需一次构建，并注入到每一个代理中。

• 系统性防护机制（安全、可靠性、品牌一致性、惯例规范）会自动执行，而非由开发者自行决定。

• 工具化能力（MCP服务器、CI/CD流水线、评估机制）则被共享并随时可用。

具体而言，业务目标、产品专属的防护机制等，都会在系统性基础之上层层叠加。但无论何时，这些基础始终存在，为每一个项目保驾护航。

工厂是必要的。但如果没有平台，每个项目都会重新发明情境、防护机制和工具化能力。灵感源自图6，摘自1。

在这个过程中，开发者的角色也随之转变。 他们不再单纯地编写代码：他们封装情境。 然而，这些情境并非完全来自他们自己——它们源自领域专家、安全团队、品牌团队、 架构师。每个人都在贡献自己的片段；开发者则负责将这些片段整合起来。 如果每个人都以自己的方式完成这样的封装，逐个项目地进行，那么你又回到了起点。 而这正是平台所实现的：一个框架，让每一种情境来源都被结构化、版本化，并自动注入到系统中。

惊喜在于价值，而非标准

当商品由平台来处理后，一个指导原则便应运而生。

你需要在所有涉及“商品”的环节中向左移动：尽早将质量、安全和标准推向项目上游， 嵌入平台之中，使它们成为理所当然的要素，而非需要重新构建的交付物。 标准不再是终点，而是起点——一个值得信赖的基准，而不是每次都需要重新追回的终点。

这样的做法具有双重好处。首先，由于商品被共享并商品化，它会不断进步：每一次使用都会让组件变得更加成熟， 而非散布出N个平庸的版本。其次——也是最重要的——人工智能的能量被聚焦在它创造价值的地方： 在业务上，在差异化上。

因为这才是关键所在：

应用不应以标准化的组件让客户感到意外。它应该以自身的商业价值，让他们大吃一惊。

标准本应是人们习以为常的，必须完美无瑕，却又隐形无迹。 而那些令人惊喜、令人满意、带来竞争优势的特质，恰恰来自于别人未曾做过的事情。 而平台正是为此而生：将平凡的事物商品化，让非凡的事物得以大规模实现。

共享的AI-ready能力，助力规模化构建可靠的应用。具体的模块与系统性能力相融合，共同打造出应用。

平台并非教条：它是一个受监管的产品

此时，一个严肃的质疑油然而生——而正是对这一质疑的回答，才真正支撑起我们的论点。

什么才算“商品”？并非一成不变的既定事实。 今天不同的东西，明天就可能成为标准。 从“共性”到“差异化”的界限不断变化。 如果一个平台将“行业前沿”固定下来，就有可能陷入僵化……甚至过时——而这正是蒂博在“绝对质量”这一标签下所指出的陷阱。

答案并不是放弃平台，而是要将其视为一个受监管的产品。 工程领导层——CTO、架构师、技术负责人——不断调整平台所视为“商品”的内容， 以及留给各个独立应用的部分。乔达里提醒我们：将平台开放给整个生态系统，意味着要接受一定程度的控制权丧失， 因此更要建立起制衡机制,以维护标准的稳定。

这样一来，“行业前沿”才能在蒂博所理解的“鲜活且经共识达成”的意义上得以延续， 而非被刻在石头上。平台并非那个颁布绝对质量标准的权威机构，而是那把工具， 让人类继续辩论、不断试验、不断更新的“行业前沿”得以落地、得以实现。

一种信念

氛围编码自有其用武之地。它适合探索、原型开发、学习。它并非敌人——它是起点。

结构化人工智能辅助——比如BMAD及其类似的方法——确实是向前迈出的重要一步。 它为个体的生产带来了严谨性。但我们需要清楚地认识到，它并不能做到以下事情： 在一家拥有数十个应用的大组织中，仅仅选择一种好的结构化人工智能方法是远远不够的。 每个项目仍然是孤岛，没有任何措施能够保证整个组织的统一性——或者达到组织标准下的质量。

挑战在于组织层面。关键在于确保代理们所构建的每一个应用，都能体现组织的“行业前沿”——包括安全、 可靠性、品牌一致性、价值——并且在规模化推进的过程中，绝不失去控制权。 要做到这一点，需要做出三个方面的转变：

• 停止认为，为代理构建框架的方法就足以应对规模化需求。“制作精良”的代码，并不等同于“符合标准”的代码。

• 将你的代理式平台视为一个受监管的产品,而非单纯的工具。只有这样，才能让“行业前沿”得以延续。

• 盘点并构建属于自己的“行业前沿”——安全、架构、设计系统、领域知识——使其能够被代理们有效利用、并加以消费。

开发者不再单纯地编写代码。他们将产生代码的情境进行封装。而要将这种封装工业化——让组织的“行业前沿”得以规模化落地、可被代理们有效利用——就需要一个平台。

最好的系统会将情境视为首屈一指的架构决策，像对待代码一样进行审查与版本管理。改编自图4，摘自1。

来源

克里斯托夫·蒂博——“告别‘技术债务’”, OCTO。

桑吉特·保罗·乔达里——“平台思维： 工作的未来”, Medium，2013年。

杰里·温伯格——《高质量软件管理》。

1. 阿迪·奥斯马尼、舒巴姆·萨布、索克拉底·卡塔基斯——“采用氛围编码的新SDLC：从临时提示到代理式工程”, Google，2026年5月。 ↩︎ ↩︎ ↩︎