近日，网易智企-CodeWave 技术负责人姜天意在 QCon 全球软件开发大会（北京站）「Coding Agent 驱动的研发新范式」专场，分享了以《从 Vibe Coding 到 Spec-Driven，CodeWave 智能化软件工厂的思考和实践》为主题的演讲。

 

 

围绕"当 Vibe Coding 的热潮退去，企业级软件开发究竟需要什么样的 AI 范式"这一核心问题，姜天意系统阐述了 CodeWave 团队如何将 SDD（Spec Driven Development）、马具工程（Harness Engineering）与可视化开发平台深度融合，构建面向企业级场景的智能化软件工厂。

快马失缰：AI Coding 狂飙背后的三重隐患

回看过去三年，AI Coding 领域的进化速度令人惊叹：2023 年 Copilot 开启编程辅助时代；2024 年 Cursor、Windsurf 重塑编辑器体验；2025 年 Claude Code、Codex 推出自主编程能力——我们正式进入"Vibe Coding 年"。

 

狂飙之下，三个核心问题越来越刺眼：

  • 代码质量不可控。AI 生成的代码表面可运行，但风格迥异、架构混乱。国外流行的技术栈（Next.js、Tailwind CSS）与国内企业技术栈差距大，拿来就用往往水土不服。

  • 代码难以维护。现在很多人用 AI 写的代码，只能用 AI 来维护。Debug 没有好的方式，只能不断地对话、再对话。改一个 Bug，引入三个新 Bug，这种事在 AI Coding 场景中发生的频率远比我们想象的要高。

  • 业务理解泛而不精。AI 缺乏对业务逻辑的深度理解，提示词微小的变化就可能导致生成结果的巨大偏移。你以为你说清楚了，AI 也表现得好像听懂了，但交付的东西总是差那么几个关键点。

 

这些问题并非新鲜事。早在 1978 年，算法大师 Dijkstra 就曾指出"自然语言编程是一件愚蠢的事情"。形式化符号之所以推动了文明进步，正是因为在书写的同时完成了思考和抽象。而自然语言的"自然性"，本质上是一种危险的舒适——它让我们能轻松说出那些荒谬性并不显而易见的话。AI 写代码可以很快，但速度掩盖了思考的缺失；对话越长，上下文越膨胀，AI 的服从性反而越成问题。

从纵马到驭马：SDD 与马具工程

既然纯自然语言驱动存在根本缺陷，有没有一种方式能在人与 AI 之间建立更可靠的沟通契约？这正是SDD试图回答的问题。与 Vibe Coding 的"Prompt → Code"路径不同，SDD 的路径是"Prompt → Requirements → Design → Tasks → Code"。先把需求标准化，再做技术设计，再拆解任务，最后才生成代码。这种方式通过技术架构约束保证代码质量可控。

 

但 SDD 也并非万能。实际测试中，由于自然语言的歧义，Spec 的标准很难统一，许多模型读不懂复杂的 Spec，编写 Spec 本身也有很高成本。更关键的是，当 Spec 规模膨胀，模型会将编码任务变成极其复杂的长程任务，需要保证其一直稳定运行，一个节点出错就可能导致后续全部崩塌。本质上是因为LLM的架构通常是为了“一次性对话”设计的，而软件开发是复杂的，有状态的，需精确追溯的工程问题。这引出了一个更深层的概念——马具工程。

 

 

从 2023 年的 Prompt Engineering，到 2025 年的 Context Engineering，再到 2026 年 Anthropic 和 OpenAI 提出的"构建舒适环境让大模型运行"，本质上都在回答同一个问题：大模型是一匹快马，如何驾驭它不跑偏？

 

马具工程包含三个要素——规范（通过 Spec、CLAUDE.md 等形式化文件约束行为）、控制（通过工程手段保证长程任务的稳定执行）、验证（通过 TDD、CI/CD 验证执行内容的准确性）。

 

 

理解了 SDD 的价值与局限、以及马具工程的必要性之后，一个自然的问题浮现出来：谁来承载这套体系？AI Coding 的问题在于开放性太强，生成的代码缺乏收敛能力，维护成本高。可视化开发平台天然有统一的 DSL、统一的应用生命周期管理和多人协作能力，但传统平台上手门槛高、灵活性不足。

 

网易智企-CodeWave 团队要走的路线是：在可控的语言底座上，用可视化开发做交付形态，用 Spec-Driven 驱动 AI 生成，三者合一。既用 SDD 解决 AI 生成的约束问题，又用平台能力解决资产沉淀、多人协作和全流程管理的企业级需求。

 

 

那么，这套融合后的产品具体长什么样？接下来进入 CodeWave 的产品全貌介绍。

CodeWave 可控的企业级 AI Coding 平台

CodeWave 可控的企业级 AI Coding 平台将 Spec-Driven 理念落地为一套完整的产品流程，覆盖从需求导入到应用搭建的全链路。整个平台围绕一个核心原则设计：人机协同，步进确认。具体开发流程分为四个阶段：

 

第一步：上传 PRD 文档，AI 自动"读懂"所有内容。上传 PRD 后，系统会自动将文档转为结构化格式，文档中的流程图、原型图等图片也会被智能识别，提取出布局、功能、交互逻辑等关键信息，为后续环节提供完整的需求输入。

 

第二步：规范需求拆解。系统会自动分析需求中的歧义和冲突，主动向你提问。用户只需要阅读问题、选择方案，就能完成需求确认。整个拆解由内置工作流驱动，不依赖个人提示词，确保输出质量标准化。

 

第三步：技术设计。点击开始后系统自主运行，自动完成架构设计、数据建模、组件匹配、UI 规范等工作，完成后提醒用户确认。

 

第四步：研发任务执行，云端自动运行。系统将生成完整研发任务，支持单项/批量执行且全部在云端运行。执行完成后，可以直接预览每个业务页面。后续如需调整，可返回 IDE 通过 AI 对话实现规范流程处理增量需求。

 

最后，项目中生成的所有资产会自动沉淀到资产中心，新项目可直接复用，越用越高效。以规范驱动智能开发，让 AI 产出稳定、可靠、可控——这就是 CodeWave 可控的企业级 AI Coding 平台。

 

CodeWave 产品演示

 

整个流程的设计哲学是步进式人机协同：AI 生成一步，人确认/干预一步，可视化预览、调整。通过马具工程保证输入、过程、结果的正确性，而不是把所有东西一股脑交给 AI 然后祈祷结果正确。

 

在 CodeWave 看来，Spec-Driven 的关键不在于如何生成代码，而在于 Spec 本身——什么样的 Spec 人能看懂、AI 也能看懂？这是一个古老而关键的问题：如何标准化地描述需求。

 

CodeWave 团队在调研了多种需求模式后，最终选择了EARS（Easy Approach to Requirements Syntax）。EARS 是一种轻量级结构化方法，旨在通过规范化的自然语言表达来改进需求编写。有一套通用结构：

"在 <可选的前提条件> 的情况下，当 <可选的触发条件> 时，<系统名称> 必须 <系统响应>。"

 

选择 EARS 的理由是：语法简单、可测试性强、非常适合需求工程场景，例如：

  • 消除模糊词。“最好能”“方便一点”模糊词，变成“应”“必须”。

  • 明确触发条件。"用户编辑内容时最好能自动保存"变成"当编辑框停止输入超过 5 秒时，系统应自动保存当前内容"。

  • 拆分复合需求。一句话混杂多个要求的情况，被拆分为多条独立描述。

  • 量化非功能需求。"不能太慢"被细化为"2 秒内响应"。

 

 

这些看似简单的转换，却是整个 SDD 链路的基石。如果连需求都无法跟人和 AI 达成共识，后续的技术设计、代码生成全部会出现偏移。有些实践，如用 OpenSpec 等工具随意生成 Spec 再快速实现的做法，只是“流程上SDD”，产出的往往是似是而非的东西。

 

以上流程描述的是从零开始构建新应用的场景，但在企业级实践中，更常见的痛点来自存量系统改动。业务逻辑散落在需求文档、设计文档、接口文档和多处 Wiki 中，依赖第三方包时需要频繁切换查阅文档，且文档更新不及时，经常出现"文档这么写但代码不是这么实现"的情况。

 

为此，CodeWave 提供了一条 Code2Spec 逆向路径：对老代码仓库进行源码解读，基于解读结果生成标准化 Spec，再导入平台进行重构开发。整个过程中，不仅将业务需求写入 Spec，还将 API 接口契约一并固化，确保新旧系统的接口兼容性。

 

 

产品层面的设计讲清楚了，接下来的问题是：这些看似流畅的步骤背后，到底需要解决哪些硬核的技术挑战？

NASL 底座上的马具工程实践

要理解 CodeWave 的技术方案，首先要理解平台基座。CodeWave 平台的核心是一门自研的领域特定语言——NASL（NetEase Application Specification Language）。平台上所有可视化的内容，包括页面、逻辑、数据定义、数据查询等等，本质上都是 NASL 的 DSL。

 

这意味着平台天然具备极强的约束性：技术栈统一、生成产物可控、AI 化改造也非常简单，将可视化交互改为 AI 交互输入即可。打个比方，如果说 AI Coding 是在一张白纸上画画，自由但容易乱，那 NASL 就像一本填色画册，边界清晰，AI 只需要在框内发挥，反而更不容易出错。

 

 

平台的 IDE 底座包含完整的基础设施：Language Server 提供静态补全和类型检查、Debugger 支持断点调试和变量监视、代码仓库和资产中心提供依赖管理、多环境和多租户管理覆盖应用全生命周期。AI 服务层则涵盖自然语言生成、代码补全、代码解读、D2C（设计稿转代码）等能力。

 

有了平台基座，还需要一个"执行引擎"来驱动整个 SDD 流程。为此，团队自研了代码智能体 wave-agent。关键数据：12 万行代码，72 个 Spec，没有任何一行人工编写的代码。它对标 Claude Code 实现了几乎完整的功能，还额外增加了 Constitution 自举机制、SpecKit 工作流、LSP 工具支持等增强能力。

🔗 wave-agent 项目已开源：https://github.com/netease-lcap/wave-agent

 

姜天意在演讲中说："在 AI 时代，只有真实感受到 SDD 的上限在哪里、哪些步骤必须人工介入，才能做出真正好用的产品。这些感受，是任何用户调研都给不了你的。"

 

平台基座提供了"AI 友好"的开发环境，但仅有环境还不够——如何让 AI 在这个环境中稳定、可控地完成大规模任务，才是真正的工程挑战。回到马具工程建设，姜天意认为要考虑三个重点：

 

  • 智能体架构：大型的任务如何持久化健康地跑，如何保证可干预；

  • 知识工程约束：开发过程的知识如何管理，约束如何制定；

  • AI 可信：如何验证模型的结果。

 

 

智能体架构选型时，CodeWave 在核心流程选择用 Workflow 保证稳定，每个 Skill 对应一个独立的 Sub Agent 保证上下文隔离。不追求"最聪明的 AI"，而追求"最可控的 AI"——在企业级场景里，可预期的 80 分远比偶尔 100 分、偶尔 30 分更有价值。

 

需求提交阶段，面对用户上传的上百页 PRD（扔给任何一个 Agent 上下文都会直接挤爆），CodeWave 首先会借助网易智企 CoreAgent 平台在知识库领域的多年积累，对文档中的表格、图片、内容等做准确的解析与处理，之后 CodeWave 分两步应对。

 

先用Sub Agent 并发提取功能模块大纲、模块间关联和术语表，再按模块逐个展开细节、建立索引映射。当需求文档里有图片时，CodeWave 提供多模态支持，系统会先判断图片类型：是流程图、原型图还是示意图，然后分别进入不同的处理路径，甚至能够支持 PRD 中的高保真界面设计直接生成页面。

 

技术设计阶段，如果前后端各自生成、缺乏统一契约，最终拼合时必然出现大量不匹配。为此，CodeWave 设计了一套完善的依赖关系处理，包括API Contract 层处理前端和后端的接口设计依赖，模块间的接口依赖等复杂场景。

 

设计定义完成后，进入代码生成阶段。面对企业级应用动辄数十个实体、上百个逻辑的生成规模，CodeWave 放弃了让 AI 自主规划执行的做法，转而通过任务管理器将所有生成工作拆解为原子任务，每个任务拥有独立上下文，可暂停、可重试、可人工干预，从瀑布式的一次性生成转为增量式的逐步构建，保证大规模复杂 AI Coding 任务的稳定性。

 

另一方面，对 NASL 大量私有知识，采用渐进式披露策略，"告诉模型知识在哪、让模型按需查取"，有效避免了将全部文档塞入上下文导致的信息过载，同时保证了模型在面对具体问题时能获取足够精确的知识。

 

在项目经验沉淀阶段，CodeWave 建立了 Compound 复合工程，让 AI 越跑越精准。通过引入 Plan → Work → Review → Compound 的循环，将解决的问题结构化记录，形成团队知识资产，让智能体成为一个自进化的开发伙伴。

 

最后，AI Agent 在运行时，会主动探索环境、执行系统命令、动态生成并运行代码，甚至可能删自己的代码、清空数据库。对此，CodeWave 参考 Claude Code，基于 Linux Bubblewrap 形成了一套轻量级沙箱方案，无需 root 权限、毫秒级启动、覆盖 PID/Mount/Net 等多维命名空间隔离，在安全性和性能之间找到了最佳平衡。

 

回顾整套技术方案，马具工程的三大要素在 CodeWave 中落地为：

 

  • 事前可约束：通过需求标准化预处理、模块依赖分析、知识工程注入等，保证输入需求、技术设计的准确性。

     

  • 事中可控制：采用Skill + Sub Agent + Workflow 混合架构，每个 Skill 对应独立 Sub Agent，主 Agent 只负责调度。同时利用上下文卸载技术，一切状态共享走文件，每个阶段输出的 Spec 都要写成文件，Sub Agent 失败可以从中间断点重试，用户可以在任意阶段介入修改，形成可追溯的完整链路。

     

  • 事后可验证：NASL 生成后必须过 Validate_nasl 检查，通过 Hooks 强制触发 NASL Checker，结果可验证才能进入下一环节。

 

 

技术方案解决了"怎么做"的问题，但要让产品持续进化，还需要一套客观的度量体系来回答"做得怎么样"。

Benchmark 驱动的产品设计与模型训练

"No Data, No BB"——没有 Benchmark，就无法知道产品的边界和模型的能力。CodeWave 围绕 SDD 全流程建立了完整的 Benchmark 体系，覆盖需求处理（需求标准化测试集、文档内图片识别测试集）、技术设计（外部依赖分析测试集、扩展组件召回测试集）、NASL 生成（页面设计测试集、AI 对话修改测试集）等各环节。Badcase 会持续回流到测试集中，保证产品质量随迭代稳定提升。

 

 

在提效度量上，团队设计了一套公式：

AI 功能平均提效率 E=(M - T) / M

 

其中 M 是纯手工开发时长，T 是使用 AI 功能后用户的实际耗时（包括 AI 生成时间和人工 Review/修改时间）。这个公式的价值在于——它不只衡量 AI 生成有多快，而是衡量"AI + 人"的组合效率比纯人工提升了多少，更贴近真实场景。

 

除了度量产品提效，Benchmark 体系同样驱动着底层模型的持续优化。为提升 NASL 代码生成效果，团队选择 Qwen2.5-Coder 作为基座模型进行微调：先从开源代码数据集中合成 10 万+ 条 NASL 指令，通过语言沙箱验证正确性；再使用 LoRA 方案进行监督微调（SFT），结合拒绝采样持续回流高质量数据；最后通过 DPO 偏好对齐，构造"正确代码 vs 错误代码"的三元组强化模型输出。经过多轮迭代，NASL 生成的 HumanEval 得分从早期的 54.58% 提升至 80.07%。

 

至此，CodeWave Benchmark 平台与产品迭代形成了完整闭环：Benchmark 识别模型能力边界，指导产品设计；线上 Badcase 回流到训练集和 Benchmark；产品 AI 功能升级（包括 Prompt、模型或工程方案调整）必须通过 Benchmark 评测才允许上线，确保 AI 能力不会退化。当大模型厂商突然更新模型时，团队也能第一时间进行回归测试。

三位一体的企业级开发答案：好马更需好马具

回到开头那个问题：AI Coding 狂飙下，相关问题如何解决。现在大家已经有了大体方向。Vibe Coding 解决了"从 0 到 1 快速生成"的问题，但企业级软件开发从来不只是生成代码——它需要需求澄清、架构设计、多人协作、持续维护和质量保障。这些问题，恰恰是可视化开发平台积累多年的优势所在。

 

 

如果用一个词概括 Spec-Driven 的本质，那就是降熵。原始需求是口口相传、白板涂画的混沌状态，熵值最高；经过 EARS 标准化，模糊性下降；加入交互稿和设计稿，视觉层的混乱度下降；通过代码约束和验证，输入输出变得可观测。Spec-Driven 并非什么高深理念，它只是通过形式化方式逐层降低混乱度的工程实践——而这恰恰是软件工程几十年来最朴素也最有效的智慧。

 

AI 不需要被限制，但需要被驾驭。毕竟，一匹好马配上好马具，才能跑得又快又远。Spec-Driven 提供了"想清楚再做"的方法论，马具工程提供了"做的过程中可控"的工程能力，而可视化平台提供了"做完之后可管理、可协作、可持续"的交付形态。CodeWave将其三者合一，才是面向企业级场景的完整答案。

 

如果你也在探索可控的企业级 AI Coding，欢迎扫码体验 CodeWave。

图片

 

AI 正在从「能用」走向「好用」，但技术落地从来不是单点突破，而是一场产业协同的远征。 如果你也在寻找 AI 与业务深度融合的真实路径，期待与千位企业决策者面对面碰撞，5月29日杭州，网易创新企业大会诚邀你现场见证、共创答案。

 

👇 扫码立即报名，锁定席位