民生银行基于规格驱动开发（SDD）的 CodeAgent 私域研发探索与实践

近年来，大模型技术快速发展，人工智能在软件研发中的应用不断深化。从最初的代码补全工具，到能够理解需求、生成方案、编写代码以及辅助测试的智能化研发助手，人工智能正在逐步改变传统的软件开发方式。

起初，CodeAgent 工具在原型开发和技术验证场景中，通过自然语言描述需求即可生成代码的方式显著提升了研发效率。然而，银行业务系统通常具有规则复杂、系统耦合度高以及安全合规要求严谨等特点，在银行科技私域研发环境中，若仅依赖对话式人机结伴编程，仍然无法确保需求实现代码的准确生成，难以保证系统实现与企业工程规范的一致性，也难以满足银行研发体系对质量、稳定性和可控性的要求。

基于这一认识，民生银行科技团队于 2025 年启动了围绕规格驱动开发（Spec-driven development，简称 SDD）的探索。依托私有化部署的 Cloud IDE+民生 Code CLI 工具+阿里云通义千问，通过流程化 AI 编程的方式，基于企业级规格、领域级规格和项目级规格驱动生成符合企业私域规范和功能需求的代码，不断探索 CodeAgent 工具高效稳定应用的路径，使 AI 能力逐步融入企业研发体系。

在银行研发环境中，AI 赋能研发能够提升局部效率，但面向端到端的研发交付任务，仍面临多方面挑战。

一是 AI 对代码全局理解仍不足。银行系统复杂度高，不同项目的代码设计客观存在差异，单依靠长上下文能力进行工程理解，仍因诸多隐性知识缺失导致 AI 生成偏差。

二是难以稳定生成符合功能需求的代码。传统研发交付项目的 PRD（产品需求文档）、需求规格说明书等主要面向人类用户，焦点往往在于“用户需要什么”，可能普遍缺乏对“系统如何表现”方面的技术性转换，若直接作为 AI 的输入，很可能因 AI 对需求实现有理解偏差导致大量无效输出。

三是难以遵从私域规范和技术要求。传统对话式 AI 开发的输入通常具有临时性和碎片化特征，不同开发人员的描述方式差异较大，导致 AI 的生成内容对私域技术规范、工程实现要求、数据结构要求等遵从性不足。

四是质量验证机制需适应性变化。AI 生成高效但具有不确定性，如果缺乏规范化和自动化的代码测试校验和评估机制，难以保证 AI 长期高效稳定生产代码。

五是研发资产难以复用。AI 辅助开发过程中的关键信息往往停留在会话上下文中，难以形成可复用的组织资产。

参考目前的业界实践，从“意图驱动”走向“规格驱动”是可实现企业私域规范化研发的路径之一，目标在于基于标准流程和工程规范实现稳定应用。

2025 年 9 月 Github 提出 Spec-Driven development 的定义，认为 Spec（规格）是一份代码行为准则的契约，并成为工具和 AI 代理的代码生成、测试和验证代码所依赖的单一事实来源。随着 Spec Kit、OpenSpec 等工具出现，业界开展了诸多研究与实践。ThoughtWorks 杰出工程师 Birgitta 提出 SDD 工具实践有三种层次策略，一是规格优先（Spec-first，即编写规格用于 AI 辅助），二是规格锚定（Spec-anchored，即规格用完后保留用于功能演进与维护），三是规格为源（Spec-as-source，即规格代替源码作为主要源文件），成为业界实践的重要指导方法之一。

虽业界尚未对 Spec（规格）有通用的定义，结合业界与我行的实践，本文尝试提供在当前 SDD 概念下的一种关于 Spec（规格）的解释。本文认为，SDD 模式下的规格是一类具有明确性、可被验证、可演进、AI 可读的面向开发流程的技术性描述，也是人类与 AI 之间的共同技术契约语言。我们认为规格的核心内容包括：企业级规格、领域级规格以及项目级规格。区别于业界讨论的“规格与技术实现分离”观点，在企业私域研发环境中，开发规范往往涉及到实现细节（比如，编写单元测试所依赖的组件需要与领域内规定的标准版本保持一致），完全脱离技术实现要求可能导致 AI 生成无法高度遵从私域规范。

企业级规格，包含企业技术规范、公共技术知识、私域框架规范、组织研发安全等；

领域级规格，可从业务、技术两个视角出发，业务领域规格包含业务模型设计、产品知识等，技术领域规格包含工程实现知识与要求、公共接口方法、私域框架指引、消息中间件应用要求、测试代码编写要求、数据库配置要求、领域内研发安全约定、系统性能要求等；

项目级规格，包括需求规格（或功能规格）、接口与集成规格、数据结构规格、验收要求、实现约束、功能特定性能要求等。

SDD 是以上述规格作为重要的工程上下文驱动 AI 生成代码、验证代码的一种方法。使用 SDD 具有一定的应用门槛，也会带来一定应用开销。使用策略上，可采用轻量化的规格优先（Spec-first）方式切入，不断积累可复用的规格资产，减少后续迭代或同领域团队的应用开销，向规格锚定（Spec-anchored）逐步演进。

针对上述挑战，结合业界主流实践，民生银行科技团队依托阿里云联合创新实验室积极探索规格驱动开发的新型研发模式，以规格作为研发全过程的核心载体，将需求、设计、任务、实现和验证连接成完整链路，使人工智能能够在明确边界条件下参与研发活动。

民生银行通过规格开发深度实践，总结了指导性的规格开发流程框架。在整体框架上，规格驱动开发体系主要包括三个层次。

规格知识层。主要沉淀组织研发经验和工程规则，包括企业级规格、领域级规格、项目级规格内容，并通过知识库形式持续积累经验资产。

研发流程层。围绕需求分析、设计约束、任务拆解、代码实现和质量验证组织研发活动，使研发流程具有清晰的阶段划分。

智能能力层。通过多智能体协同与能力组件化方式，为研发流程提供自动化支持。

其中，在研发流程上，团队将规格驱动开发抽象为五个关键环节：

规格 → 计划 → 任务 → 实现 → 验证

• 规格用于明确需求，以及开发所遵循的各项要求；

• 计划用于形成研发实施路径；

• 任务用于拆解具体开发工作；

• 实现用于完成代码生成与系统构建；

• 验证用于确保实现结果符合规格验收要求。

1. 实践之初暴露的问题

为探索 SDD 在企业级私域规模化研发场景的潜力，我行面向具有以下典型私域研发特征的业务研发交付场景开展实践，一是基于我行私有技术开发框架，二是具有上下游系统关联，三是项目自有研发规范与约定。项目组围绕需求澄清、规格形成、开发实现和测试验证开展了实践探索。

我行在多个领域项目启动了 SDD 探索，行动之初并非一帆风顺。项目组遇到了以下棘手的问题，工具在试行过程中遭遇多次暂停与调整。

（1）敏捷、瀑布式项目既有材料与“规格”就绪数据存在距离

各项目的需求说明书、技术设计方案均是面向人的材料，距离 AI 可读可理解还存在一定差距，难以作为 AI 所需的高质量的规格信息。

（2）与 AI 规格互动给开发者带来了“额外”负担

开发者与 AI 交互，需要集中开展澄清需求、告知规范、形成规格、建立开发指南、设计约束与验收条件等一系列看似繁冗的工作，才能进入代码编写环节，与传统“可边想边写”的人类开发或 AI 辅助开发的模式有较大的差异。

（3）规格撰写存在个体差异，稳定输出受挑战

不同团队人员对“规格”的理解和撰写质量差异大，标准不一，导致规格形式化，难以准确指导 AI 流程化开发，生成质量难以控制。

2. 调整适应后的 SDD 实战

经过不断调整与适应，各项目组积极构建领域内规格内容标准，明确了核心内容要素，形成了规格模板，总结了企业级、领域级、项目级规格的显式分层注入方式，以及强化约束与验收条件的良好实践，并不断沉淀可复用的领域级规格研发资产。

在焕新出发的 SDD 实践中，私域研发作业在 AI 辅助下均展现出效率跃升的潜能，且切实落地 TDD（测试驱动开发），通过功能代码与单元测试的“左右互搏”不断自动改进代码质量。经研发交付项目实战，SDD 模式实现了从业务需求到高质量、规范化的私域代码的高效转换，一是代码生成直达一定质量基线，单元测试行覆盖率接近 70%，二是符合企业私域规范的代码开发完成度超 70%，三是长程任务执行过程中人类可脱离工具开展其他高价值工作。随着实践深入，开发者角色逐渐转向“守门员”，聚焦于代码审查、测试等质量管理工作。

规格驱动开发的关键，不在于单纯使用人工智能生成代码，而在于把规格从辅助材料提升为研发活动的牵引主线，使需求、设计、开发和验证始终围绕同一依据展开，减少理解偏差和返工调整。经过实战团队不断打磨，形成以下规格驱动开发范式。

1. 注入组织环境信息（企业级规格）

将企业级规范（如企业私域技术规范、公共技术知识、私域框架规范等）作为 AI 执行的组织环境信息，形成项目宪章。

2. 沉淀与利用团队可复用的知识（领域级规格）

以业务领域或技术领域为单位，做好领域级规格（如业务模型设计、工程代码实现基本要求、接口实现方法、私域框架使用约定与示范、数据库配置要求、消息中间件应用要求、测试代码编写要求等）沉淀，便于在同领域团队间重复利用。

3. 专注写好需求实现相关的各项规格（项目级规格）

面向项目或开发任务，针对需求所涉及的技术实现，为 AI 提供高质量的需求规格、接口与集成规格、数据结构规格等，以及相应的开发指南（方法与示例）。

4.强化约束和验收条件（项目级规格）

显式表达代码实现约束，明确“不能做什么”，比如不能使用某个方法、组件等，并且遵从 TDD 理念，AI 生成功能代码的同时生成单元测试，在测试的校验束缚下自动修改代码，实现直达验收条件的代码生成。

5.利用 Skills、MCP 探索延伸研发作业链

编写代码仅是研发活动中的一环，开发者应充分思考如何利用 Skills、MCP 等 AI 工具能力将编码前或后的其他环节尽可能融入 SDD 流程，比如代码改造分析、数据模型分析、门禁检查、代码评审等。

SDD 是当前 AI 代理编程的一种相对严谨和高阶的研发模式，能够通过流程化与规范化的输入使得 AI 在生成方面遵循企业规范且趋于稳定可控，但面向相对复杂的银行私域编程情景，仍然存在以下挑战。

一是存在场景局限性，且场景适配评估客观存在难度。SDD 并非适合于所有项目运用，经内部试点并结合业界实践得出，当前在探索类（如原型/研究、需求边做边迭代等）、创意类（如前端 UI 设计与优化）、算法类、金融专业逻辑类、性能优化类、微小改动类等开发场景不适用 SDD 方法。然而对上述范围之外的开发场景，模型能力、私域知识规范化储备、规格质量、存量工程质量等多方面因素均会影响 SDD 模式落地执行，比如对不同多年遗留系统的迭代开发进行 SDD 适配度评估，因代码架构陈旧度、研发知识匮乏度等情况异同，SDD 适配情况也会有差异。因此，面向私域各类系统、项目进行 SDD 适用度精准评估，客观存在一定的挑战。

二是过度规格化将困于规格与代码的偏离管理。SDD 研发模式下，规格被广泛视作“唯一真相源”，随着开发的推进，规格与代码的一致性保持将变成较大的负担，SDD 应用开销在后期将会不断增加。当前，我行主要采用“规格优先”而非“规格为源”的策略，同时探索“规格锚定”策略实践，聚焦于规格沉淀复用，而非严格要求以规格为知识源，也不盲目追求每一项功能更新与维护强制依赖规格，相反，支持开发者灵活混用 SDD 与 Copilot 或 Vibe Coding 工具互补完成代码开发。

三是长期迭代后的规格资产保鲜挑战。随着项目长周期迭代，积累的变更已成规模，变更分支的规格零散分布，规格知识资产保鲜问题也将凸显，过时规格加载到上下文中，生成准确性将面临挑战。因此，规格应视作一类研发资产，需探索规格的规范化管理机制与工具，以及增量规格合并、变更归档隔离等技术策略。我行将采用上下文工程管理工具对规格进行规范存储与版本管理。

SDD 研发模式天然带有约束和控制的特性，符合企业级私域规范化研发的纪律性要求，与驾驭工程（Harness Engineering）的约束控制思想有一定的相似性。我们计划在 SDD 实践中引入多智能体协同模式，将 AI 研发活动各环节进行约束探索，探索践行驾驭工程“边界约束”理念。比如，架构校验智能体负责架构方案匹配、接口与数据结构设计建议、技术边界校验以及非功能需求检查，增强测试智能体负责测试点提取、边界测试补全、集成/接口测试。

随着智能编程工具的自动化水平不断提高，当前主流的 AI 代码度量指标将难以满足对自动化水平更高的 AI 代理编程工具的效用评估需求。业界实践表明，无论是“先规划后生码”，还是“规范先行，AI 执行”，大部分机械式的编程劳动已交由 AI 编写“代劳”，在新工具形态下，AI 代码采纳率、AI 代码占比的参考价值将显著降低。

过去的 AI 过程性指标已难以适配如今 CodeAgent 观测需求，以质效结果为导向的 AI 度量指标将走上台阶。我们稳步开展 SDD 实践的同时，进一步探索 AI 工具效用评估向人类的研发效能评估方法靠近，重新启动 AI 效用度量相关工作，在指标设计、数据采集、统计算法等方面开展适应性调整。

随着大模型技术不断发展，软件研发方式正在发生深刻变化。对银行科技体系而言，AI 赋能研发的关键在于能否在规范、流程和治理框架内稳定且高效地运行。民生银行将深化阿里云联合创新，围绕规格驱动开发开展探索与实践，通过构建 AI 流程化研发闭环、引入约束与控制，使 AI 能力逐步融入企业私域研发流程。

未来，随着规格驱动开发体系不断完善和能力组件持续沉淀，人工智能、研发智能体将在银行科技研发中发挥更加重要的作用，为金融科技研发提供更加稳定、高效的技术支撑。