作者民生银行信息科技部林冠峰、张新亮、雷双龙民生科技公司李宏乐近年来大模型技术快速发展人工智能在软件研发中的应用不断深化。从最初的代码补全工具到能够理解需求、生成方案、编写代码以及辅助测试的智能化研发助手人工智能正在逐步改变传统的软件开发方式。起初CodeAgent 工具在原型开发和技术验证场景中通过自然语言描述需求即可生成代码的方式显著提升了研发效率。然而银行业务系统通常具有规则复杂、系统耦合度高以及安全合规要求严谨等特点在银行科技私域研发环境中若仅依赖对话式人机结伴编程仍然无法确保需求实现代码的准确生成难以保证系统实现与企业工程规范的一致性也难以满足银行研发体系对质量、稳定性和可控性的要求。基于这一认识民生银行科技团队于 2025 年启动了围绕规格驱动开发Spec-driven development简称 SDD的探索。依托私有化部署的 Cloud IDE民生 Code CLI 工具阿里云通义千问通过流程化 AI 编程的方式基于企业级规格、领域级规格和项目级规格驱动生成符合企业私域规范和功能需求的代码不断探索 CodeAgent 工具高效稳定应用的路径使 AI 能力逐步融入企业研发体系。背景与挑战在银行研发环境中AI 赋能研发能够提升局部效率但面向端到端的研发交付任务仍面临多方面挑战。一是 AI 对 代码全局理解仍不足。银行系统复杂度高不同项目的代码设计客观存在差异单依靠长上下文能力进行工程理解仍因诸多隐性知识缺失导致 AI 生成偏差。二是难以稳定生成符合功能需求的代码。传统研发交付项目的 PRD产品需求文档、需求规格说明书等主要面向人类用户焦点往往在于“用户需要什么”可能普遍缺乏对“系统如何表现”方面的技术性转换若直接作为 AI 的输入很可能因 AI 对需求实现有理解偏差导致大量无效输出。三是难以遵从私域规范和技术要求。传统对话式 AI 开发的输入通常具有临时性和碎片化特征不同开发人员的描述方式差异较大导致 AI 的生成内容对私域技术规范、工程实现要求、数据结构要求等遵从性不足。四是质量验证机制需适应性变化。AI 生成高效但具有不确定性如果缺乏规范化和自动化的代码测试校验和评估机制难以保证 AI 长期高效稳定生产代码。五是研发资产难以复用。AI 辅助开发过程中的关键信息往往停留在会话上下文中难以形成可复用的组织资产。参考目前的业界实践从“意图驱动”走向“规格驱动”是可实现企业私域规范化研发的路径之一目标在于基于标准流程和工程规范实现稳定应用。关于 SDD 的认知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逐步演进。民生银行 SDD 开发实践针对上述挑战结合业界主流实践民生银行科技团队依托阿里云联合创新实验室积极探索规格驱动开发的新型研发模式以规格作为研发全过程的核心载体将需求、设计、任务、实现和验证连接成完整链路使人工智能能够在明确边界条件下参与研发活动。一SDD 开发流程框架民生银行通过规格开发深度实践总结了指导性的规格开发流程框架。在整体框架上规格驱动开发体系主要包括三个层次。规格知识层。主要沉淀组织研发经验和工程规则包括企业级规格、领域级规格、项目级规格内容并通过知识库形式持续积累经验资产。研发流程层。围绕需求分析、设计约束、任务拆解、代码实现和质量验证组织研发活动使研发流程具有清晰的阶段划分。智能能力层。通过多智能体协同与能力组件化方式为研发流程提供自动化支持。其中在研发流程上团队将规格驱动开发抽象为五个关键环节规格 → 计划 → 任务 → 实现 → 验证规格用于明确需求以及开发所遵循的各项要求计划用于形成研发实施路径任务用于拆解具体开发工作实现用于完成代码生成与系统构建验证用于确保实现结果符合规格验收要求。二SDD 研发交付实战1. 实践之初暴露的问题为探索 SDD 在企业级私域规模化研发场景的潜力我行面向具有以下典型私域研发特征的业务研发交付场景开展实践一是基于我行私有技术开发框架二是具有上下游系统关联三是项目自有研发规范与约定。项目组围绕需求澄清、规格形成、开发实现和测试验证开展了实践探索。我行在多个领域项目启动了 SDD 探索行动之初并非一帆风顺。项目组遇到了以下棘手的问题工具在试行过程中遭遇多次暂停与调整。1敏捷、瀑布式项目既有材料与“规格”就绪数据存在距离各项目的需求说明书、技术设计方案均是面向人的材料距离 AI 可读可理解还存在一定差距难以作为 AI 所需的高质量的规格信息。2与 AI 规格互动给开发者带来了“额外”负担开发者与 AI 交互需要集中开展澄清需求、告知规范、形成规格、建立开发指南、设计约束与验收条件等一系列看似繁冗的工作才能进入代码编写环节与传统“可边想边写”的人类开发或 AI 辅助开发的模式有较大的差异。3规格撰写存在个体差异稳定输出受挑战不同团队人员对“规格”的理解和撰写质量差异大标准不一导致规格形式化难以准确指导 AI 流程化开发生成质量难以控制。2. 调整适应后的 SDD 实战经过不断调整与适应各项目组积极构建领域内规格内容标准明确了核心内容要素形成了规格模板总结了企业级、领域级、项目级规格的显式分层注入方式以及强化约束与验收条件的良好实践并不断沉淀可复用的领域级规格研发资产。在焕新出发的 SDD 实践中私域研发作业在 AI 辅助下均展现出效率跃升的潜能且切实落地 TDD测试驱动开发通过功能代码与单元测试的“左右互搏”不断自动改进代码质量。经研发交付项目实战SDD 模式实现了从业务需求到高质量、规范化的私域代码的高效转换一是代码生成直达一定质量基线单元测试行覆盖率接近 70%二是符合企业私域规范的代码开发完成度超 70%三是长程任务执行过程中人类可脱离工具开展其他高价值工作。随着实践深入开发者角色逐渐转向“守门员”聚焦于代码审查、测试等质量管理工作。三SDD 开发范式沉淀规格驱动开发的关键不在于单纯使用人工智能生成代码而在于把规格从辅助材料提升为研发活动的牵引主线使需求、设计、开发和验证始终围绕同一依据展开减少理解偏差和返工调整。经过实战团队不断打磨形成以下规格驱动开发范式。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 能力逐步融入企业私域研发流程。未来随着规格驱动开发体系不断完善和能力组件持续沉淀人工智能、研发智能体将在银行科技研发中发挥更加重要的作用为金融科技研发提供更加稳定、高效的技术支撑。