很多人听到AI Coding，第一反应是Cursor、Claude Code、Codex、Devin。
过去两年，AI编程工具以前所未有的速度改变着软件开发流程。从代码补全到自主编程，从辅助开发到仓库级重构，越来越多项目中的大部分代码已经能够由AI完成。
但一个问题也随之浮现：AI已经能写70%甚至90%的代码，为什么软件开发效率并没有同步提升70%甚至90%？
在7月2日举办的2026中国AI智能体大会上，杭州迅速智能CEO熊继斌带来了主题为《AI软件工厂——AI时代自动化软件开发的实践与思考》的分享。与行业聚焦Coding Agent能力提升不同，他将目光投向了软件工程更长的链条。
在他看来，从需求到代码之间最大的鸿沟，从来不是写代码本身，而是需求的结构化表达与多方对齐。
需求理解、业务建模、领域设计、任务拆解、协作编排、测试验证与持续迭代，依然占据着软件工程的大部分成本，而这些恰恰是今天大多数AI Coding工具尚未真正解决的问题。
因此，这场分享讨论的并不仅仅是如何生成代码，而是一个更大的命题：如何让AI从需求阶段开始介入，贯穿软件工程全生命周期，实现“你描述需求，AI产出整个系统”。
围绕这一目标，熊继斌分享了团队过去一年多在需求建模、多Agent协同与软件工厂方向的探索实践。在他看来，软件开发本质上是协作问题，而不是能力问题；真正的壁垒不在单点能力，而在系统化协作。正如熊继斌在演讲中所说：
单个Agent是作坊，把一组Agent协作成自动化工厂，才能形成壁垒。
当行业还在讨论如何打造更强的Coding Agent时，这场分享已将讨论推向更深一层——AI软件工厂对软件生产方式的重新定义。Agent从开发工具成长为软件工程体系的一部分，软件开发从“代码驱动”向“需求驱动”完整软件工程新范式的演进。
这个话题的起点是来自于一个非常朴素的观察。过去两年多我们见证了AI编程工具的爆发，从代码补全到Agent的自主编码，甚至从单个文件的修改到仓库级的重构，可能百分之七十八十甚至90%的代码都是AI写的。
但是如果我们把镜头拉得更远一些，在整个软件工程的生命周期，会发现这些工具解决的基本都是同一个环节的问题——写代码。
但是在写代码之前的需求澄清、业务建模、领域设计仍然高度的依赖人的经验和协作的。而写代码之后的环节就是集成测试、部署验证，乃至代码持续迭代也是同样的问题，需要人的经验协作。
于是我们问了自己一个问题——能不能让AI从需求阶段就介入，一直贯穿到最终的可运行系统？不是“AI帮你写代码”，而是“你描述需求，AI产出整个系统”。
这个问题的答案就是今天我给大家带来的两个系统，迅速智能推出的AI-Ready®需求建模器以及AI-ready®软件工厂，它们共同构成了一条从模糊的自然语言需求描述到可运行软件系统的全自动链路。
需求建模器负责“读懂需求”——把模糊的自然语言翻译成精确、无歧义、完备的结构化DDD领域模型；软件工厂负责“写出系统”——把DDD领域模型拆解成开发任务、多Agent并行编排，从而产出可运行的软件系统。
01
为什么需求建模是第一步？
解决需求到代码的鸿沟
为什么说需求建模是第一步呢？
在聊这个问题之前，先给大家分享一个我们遇到的真实的一个故事。我们的一个金融行业的客户要构建一套企业级的本体知识库，给了我们300多份项目PRD文档——有PDF扫描件、有Word文档、有Visio流程图，每一份的结构、术语、粒度都不一样。按传统做法，光是“理解需求”这一个环节，两三个高薪人力投入两个月是很正常的，而且大量时间消耗在沟通摩擦上。
传统需求分析的本质：人肉编译器，慢、贵、不可复现。
所以这个问题给我们的启发就是：从需求到代码之间的鸿沟，从来不是写代码本身的问题，而是需求的结构化表达与多方对齐问题。
所以需求建模器要做的就是用AI替代这层翻译。下面我会用一个更简单的场景——校园访客管理系统，来展开技术架构的说明。
需求建模器的设计实际上非常简洁，因为它的底层数据就是依靠领域社会驱动语言来做的。它只有三个核心的概念：
实体Entity，业务领域中有独立身份和生命周期的对象。比如“访客”“通行证”“审批记录”。
关系Relation，实体之间的语义连接。比如“访客申请通行证”“审批记录关联申请”。
事件Event，驱动状态变更业务的动作。比如“提交申请”“审批通过”“放弃并重提”。
这三个概念都是领域驱动设计的基石，而我们做的工作就是让AI从这些自然语言中自动识别并且提取他们。我们整个建模的过程是遵循了DDD的经典的三段式方法论。
第一阶段是事件风暴，让AI通读所有的输入文档，提取出来所有业务事件。我们用过去式去描述“已经发生的事实”，不预设任何的架构或者系统边界，我们只关心里面发生了什么事情。
第二阶段是四色建模，把这个领域的对象分成了4种颜色，包括时刻-时段、角色、一些描述以及参与方，逐步构建出实体关系和属性框架。
第三阶段是限界上下文，是根据耦合程度和因果关系自动识别相对独立的领域模块。比如说访客申请域、审批域、通行证域、门禁核验域等等。
这里跟大家说一个我们踩过的坑：我们一开始就让AI在事件风暴之后直接去做四色建模，但是出现一个问题——在事件不够完善的时候AI会倾向于去“脑补”这个缺失的实体，就导致后面的四色建模以及代码生成出现很多问题。
所以我们在中间加了一步工作，让AI先做“事件追溯”，检查事件之间的因果链是否完整。这个改动让我们的建模准确率提升了大约30%。边界划得好，下游才能做并行开发，准确率会更高。
到这里大家会问，我们整个Agent的生成过程大概是什么方式？我们到底是一个大Agent从头做到尾，还是多个小Agent去协作来完成呢？我们的答案是后者。
一个Agent去做全链链路建模会很容易陷入局部最优的问题，所以我们是六个子Agent协作，通过一个主Agent去协同。
SubAgent1：文档解析，负责PDF、Word、图片、纯文本等多模态输入的理解，转为统一结构化表示；
SubAgent2：事件识别，提取业务事件并建立时间线和因果链；
SubAgent3：实体建模，识别实体和属性、建立四色模型；
SubAgent4：聚合设计，将实体聚合成聚合根、定义业务规则和不变量；
SubAgent5：领域划分，识别限界上下文、定义接口和依赖；
SubAgent6：原型生成，基于业务场景自动生成可交互的产品原型界面。
所有的Agent共享一个上下文的总线，上游的Agent的输出会自动成为下游的一个输入。主Agent负责协调调度，决定哪些并行，哪些串行，以及在输出质量不达标的时候触发重新执行。
就像一个乐队，每个乐手相当于子Agent，都有自己的专长。而指挥去统一的协调，乐谱就是我们后面会讲到的Meta-Spec。
02
上下文管理：AI建模的“内存”
上下文管理是多Agent系统中最头疼的问题，我们将问题定义为“上下文断裂”。我们的方案有三个机制。
需求版本管理，指的不是说Git的代码版本管理，而是生成的第一个模型版本。当用户修改需求的时候，建模器不会从头重新建模，会对比版本的差异，只对受影响的局部进行重建，把变更的传播到下游。相当于一个设计师改了门的位置，他不会重把整个楼进行重画的图纸。
上下文预算，明确跟每个子Agent的分配一个注意力的配额，只关注自己任务的上下文。我们发现不是所有上下文给Agent它的效果就会好，只要这样反而会让这个无关的信息分散他的注意力，从而产生更多的幻觉。
-
Meta-Spec，就是我刚才讲到的我们六个Agent的协同和上下文的管理都依赖一个核心操作手册。
Meta-Spec是我们经过一年多摸索出来的一套建模规格语言，核心理念就是用结构化规范替代提示词工程。
传统的这个AI开发方式是写prompt，不断的调整措辞，但是prompt不可验证、不可追踪、不可复现。相同的prompt，如果模型升级，结果可能就改变了。
而我们有Meta-Spec之后，做法就不一样了。我们不告诉AI应该怎么做，而告诉它我们要产出什么。所以我们定义了一套严格的这种结构化的Schema——定义的事件事件应该有多少个字段、实体关系图是什么格式、限界上下文的接口包含哪些信息等等。
建模的质量不是感觉出来的，而是靠数据：输出的与Schema的匹配度，跨Agent和上下文一致性，包括建模产物的完整性指标分。
为什么会把DDD领域驱动设计为建模的方法论呢？因为DDD的核心主张就是先把业务领域本身建清楚，再谈技术实现。它天然的区分领域逻辑和技术细节。这正是我们需求到代码翻译最需要的边界。更重要的是DDD的产物是结构化、可枚举、可验证的，这让它特别适合AI自动建模。
领域事件、实体与值对象、聚合根、限界上下文，每一类都有明确的定义和约束，AI不是在自由发挥，而是在往一个确定的骨架里填充，这些产物和软件资产会一一对应。
正因为这种对应的关系，软件工厂才能把模型一步步地拆解成开发的任务。
一句话总结，我们用DDD不只是一种建模风格，它是连接业务语言和和代码结构的一座桥梁。
03
软件工厂：从DDD模型到
可运行代码的自动化
讲过需求建模，我们接着来看软件工厂，从模型到代码的自动化。有了结构化的DDD需求模型之后，下一个问题就显而易见了，怎么把它变成可以运行的代码？
传统的答案是交给开发团队去做。如果用需求建模器解决了AI读懂需求的这个问题，那么软件工厂解决的是“AI能够把系统写出来”的问题。
我们软件工厂第一道工序就是模型拆解。AI（这里用了DeepSeek-V4-Pro）读取需求建模器产出的DDD领域模型文件，是一组描述各种关系的上下文的JSON，通过头脑风暴确定最合适的这些技术架构，拆解成一份完整的多Agent实现工作流——按限界上下文划分的开发模块、每个模块的实现任务卡片（Issue）、任务之间的依赖关系、预估工时与优先级标签，以及一份Mermaid依赖拓扑图。
这里我提一个细节，我们用的项目管理工具是Planner，它是一个敏捷的跟踪平台。但它有一个原生的限制：一个卡片只能有一个父节点。而实际开发过程中一个模块经常会依赖多个前置的模块，比如说门禁核验既依赖通行证模块的数据格式，又依赖访客模块的身份验证逻辑。
我们的解决方案就是引入BLOCKERS机制：在卡片描述中嵌入形如BLOCKERS:I0,I2,B1的HTML注释标记。在任务编排引擎读取它的时候解析它，建立真正的多源阻塞关系；没有阻塞的任务不加标记，直接进入就绪队列。
软件工厂的核心是一个三引擎调度体系。
引擎一：任务定义层（Planner），是整个流水线的任务看板。把拆解后的所有的工作卡片通过直接写入PostgreSQL批量插入。每个工作卡片带有完整的实现清单，具体到文件路径、函数签名、验收标准、阻塞标签等等。
引擎二：编排调度层（Orchestrator），一个Elixir编写的调度引擎。它会每5秒钟轮询Planner，按优先级和阻塞关系选出可执行任务，创建工作空间副本、复制DDD模型与模板、生成相应的工作流文件，启动第三步的Coder Agent。
这里特别提到我们有一个比较优雅的设计maybe_unblock_downstream：一个工作卡片完成的时候，会编排调度层自动的去检查阻塞了哪些下游任务，如果条件都满足，自动从阻塞改为就绪。这样就会让这个多Agent的并行开发真正的成为可能。
引擎三：代码执行层（Coder），是OpenAI 的命令行Agent，通过AxonHub中转接入。我们把它设计为无状态原子执行单元，每次只完成一个工作卡片，完成就退出。状态通过Planer流转、上下文通过工作流传递。
我们已经完整跑通了刚才讲的校园访客系统。它分为了六个步骤，包括第一步输入访客管理的业务需求描述；第二步需求建模器自动生成完整的DDD模型；第三步将模型转化为20张任务卡，含Mermaid依赖拓扑图、44个标签、41条阻塞关系；第四步通过docker exec直接操作PostgreSQL、事务包裹批量写入Planner；第五步Orchestrator编排调度层从第一个可执行的Issue开始依次拉起Coder；第六步产出一个可以通过浏览器访问的完整可运行系统。
在这里最值得提到一点是模型的自动一致性检验。当AI开始分析DDD模型文件时，它会主动发现一些问题，比如状态枚举缺了“草稿”态导致暂存后无合法状态值、审批记录和通行证之间存在前向引用循环依赖等等。这些问题都是人工建模很难靠肉眼发现的问题，但在我们的自动化流水线里被提前到需求阶段就暴露出来。
在整个过程中，人工参与的环节实际上只有两个：初始需求的描述，以及最终结果的验收。中间过程都是自动化的。
04
全链路的最后一公里：
从跑通到工业级可用
刚刚讲到我们跑通了全链路，但发现这个离工业界可用还有一定的距离，所以团队还有正在推进的几个方向：
增量建模与DocMap。现实中的需求不是一次写完就再也不改的，企业级项目的需求文档经常是活的。
所以我们的目标是持续的建模。需求文档的任何变更，都能自动触发受影响局部的重新建模。DocMap是一套文档索引方法论：将几十甚至几百份文档构建成层级化索引网络，包括标题索引、段落chunk索引、业务规则提炼索引等等。对一份文档变更快速的定位到它影响了哪些实体、事件、领域边界，只对这些局部重建，而不是全量重新做。
DDD建模质量优化。我们在实战中发现对建模质量每提升10%，可能下游代码生成的一次通过率就能提升20%以上。
所以建模是整条链路的质量杠杆点。一是通过事件的追溯，在事件风暴和四色建模之间插入一个步骤，让AI检查事件因果链完整性，生成“事件断点报告”并提示补充，准确率提升约30%。第二个就是Skill重构：即使有Meta-Spec Schema约束，不同子Agent产物格式仍有漂移，所以我们逐个梳理每个子Agent的输入契约和输出规范，固化到Skill定义中。这样让重构后的跨Agent产物兼容性问题基本消失。
Canonical Business Story。传统用户故事“作为 XX 角色，我希望 XX 功能，以便 XX 价值”在AI工作流里缺乏结构化验收标准——AI不知道做到什么程度算完成。所以我们通过CBS增加了结构化的前置条件、后置条件、业务规则、异常路径、验收测试点，而且CBS的Schema是由输出要求反推设计的。这个“倒推设计”贯穿了整个Meta-Spec方法论。
05
Agent协作成自动化工厂
才能形成壁垒
当下的市场实际上讲了一个两个半的故事。当下的AI 市场实际上讲了两个半故事。第一个是算力的故事：芯片和算力中心作为“Token生产工具”，英伟达完整的验证了。第二个是模型的故事：优质大模型加优质算力，Anthropic和OpenAI都证明了这条线，包括智谱都能赚钱。第三个故事我们发现现在可能只讲了一半：应用层的故事。应用层现在的逻辑很朴素——减员增效，但这本质是零和博弈，我们认为这可能是一个过渡态，而不是终点。
把AI产业链拆开来看，最底层的是Token的生产，包括芯片、算力中心、电力，是‘资源层’；往上是模型层，造部件，解决了理解与生产的能力问题；再往上是Agent层，造机器，用模型驱动能自主完成任务的智能体。
Agent层的核心问题是机器能不能替代人，能替代人就能赚钱，但单个Agent的护城河很浅，真正的壁垒不在单点能力，而在系统化协作。所以刚才提到的我们的需求建模、软件工厂都是协作组建成协同体来完成开发流水线的。
单个Agent是作坊，把一组Agent协作成自动化工厂，才能形成壁垒。
06
AI软件工厂不是要替代开发者，
而是重新定义软件生产方式
回头看我们做的需求建模器和软件工厂，本质上是在讲应用层故事的一个下半段。相当于建了一个能自动交付软件的生产线，这不是减员增效的零和工具，而是重新定义软件生产方式的底层基础设施。这也是“需求驱动完整软件工程”’的核心命题。
它不是要替代开发者，而是要重新定义开发者的工作方式——从“写代码”变成“描述需求、验证结果、持续迭代”。开发者的创造力将被释放到更高层次的业务理解和系统设计上，而不是消耗在重复的模式匹配和样板代码中。
增量建模还需要打磨，软件工厂的后续版本还在迭代。但校园访客系统的全链路跑通已经证明这条路是通的。
我们认为Token经济的下半场，不是卖Token，而是卖生产线。
谢谢大家！
END
关注+星标，获取AI前沿进展与优质开源项目