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

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

📊 Level ⭐⭐ | 11.8KB | entities/民生银行基于规格驱动开发sdd的-codeagent-私域研发探索与实践.md

背景与挑战¶

银行私域研发环境中，AI 赋能研发在面向端到端交付任务时面临多重挑战： AI 对代码全局理解仍不足。银行系统复杂度高，单依靠长上下文能力进行工程理解存在隐性知识缺失导致 AI 生成偏差。传统 PRD 及需求规格说明书主要面向人类用户，焦点在"用户需要什么"，缺乏对"系统如何表现"的技术性转换，直接作为 AI 输入会因理解偏差导致无效输出。传统对话式 AI 开发的输入具有临时性和碎片化特征，不同开发人员描述方式差异大，生成内容对私域技术规范、工程实现要求、数据结构要求等遵从性不足。缺乏规范化和自动化的代码测试校验和评估机制，难以保证 AI 长期高效稳定生产代码。 AI 辅助开发过程中关键信息停留在会话上下文中，难以形成可复用的组织资产。从"意图驱动"走向"规格驱动"是可实现企业私域规范化研发的路径之一。

关于 SDD 的认知¶

2025 年 9 月 GitHub 提出 Spec-Driven development 定义，认为 Spec 是一份代码行为准则的契约，成为工具和 AI 代理的代码生成、测试和验证所依赖的单一事实来源。 ThoughtWorks 杰出工程师 Birgitta 提出 SDD 工具实践三种层次策略：规格优先（Spec-first）、规格锚定（Spec-anchored）、规格为源（Spec-as-source）。 SDD 模式下的规格是一类具有明确性、可被验证、可演进、AI 可读的面向开发流程的技术性描述，是人类与 AI 之间的共同技术契约语言。规格核心内容包括企业级规格、领域级规格、项目级规格。企业级规格包含企业技术规范、公共技术知识、私域框架规范、组织研发安全等；领域级规格从业务、技术两个视角出发，业务领域规格包含业务模型设计、产品知识，技术领域规格包含工程实现知识、公共接口方法、私域框架指引、消息中间件应用要求、测试代码编写要求、数据库配置要求、领域内研发安全约定、系统性能要求等；项目级规格包括需求规格、接口与集成规格、数据结构规格、验收要求、实现约束、功能特定性能要求等。

开发实践¶

民生银行科技团队依托阿里云联合创新实验室探索规格驱动开发，将规格作为研发全过程的核心载体。规格驱动开发体系包括三个层次：规格知识层（沉淀组织研发经验和工程规则）、研发流程层（围绕需求分析、设计约束、任务拆解、代码实现和质量验证组织研发活动）、智能能力层（通过多智能体协同与能力组件化方式为研发流程提供自动化支持）。规格驱动开发抽象为五个关键环节：规格→计划→任务→实现→验证。实践之初暴露的问题：敏捷、瀑布式项目既有材料与"规格"就绪数据存在距离；与 AI 规格互动给开发者带来"额外"负担；规格撰写存在个体差异，稳定输出受挑战。调整适应后的 SDD 实战成果：代码生成直达一定质量基线，单元测试行覆盖率接近 70%；符合企业私域规范的代码开发完成度超 70%；长程任务执行过程中人类可脱离工具开展其他高价值工作。开发者角色逐渐转向"守门员"，聚焦于代码审查、测试等质量管理工作。

局限性思考¶

SDD 并非适合所有项目运用，当前在探索类（原型/研究、需求边做边迭代等）、创意类（前端 UI 设计与优化）、算法类、金融专业逻辑类、性能优化类、微小改动类等开发场景不适用 SDD 方法。过度规格化将困于规格与代码的偏离管理。民生银行采用"规格优先"而非"规格为源"的策略，探索"规格锚定"策略实践，支持开发者灵活混用 SDD 与 Copilot 或 Vibe Coding 工具互补完成代码开发。长期迭代后的规格资产保鲜挑战。规格应视作一类研发资产，需探索规格的规范化管理机制与工具，以及增量规格合并、变更归档隔离等技术策略。

行动进阶¶

计划在 SDD 实践中引入多智能体协同模式，将 AI 研发活动各环节进行约束探索，践行驾驭工程"边界约束"理念。架构校验智能体负责架构方案匹配、接口与数据结构设计建议、技术边界校验以及非功能需求检查；增强测试智能体负责测试点提取、边界测试补全、集成/接口测试。随着智能编程工具自动化水平不断提高，主流 AI 代码度量指标将难以满足 CodeAgent 工具的效用评估需求。以质效结果为导向的 AI 度量指标将走上台阶，探索 AI 工具效用评估向人类研发效能评估方法靠近。

深度分析¶

规格驱动开发的核心价值在于将需求、设计、开发和验证始终围绕同一依据展开，减少理解偏差和返工调整。银行系统的复杂性使得传统对话式 AI 辅助难以保证稳定输出，而 SDD 通过规格作为人类与 AI 之间的共同技术契约语言，构建了跨越这一鸿沟的桥梁。 SDD 的本质是一种约束驱动的方法论，与驾驭工程（Harness Engineering）的约束控制思想高度契合。在银行这类对安全合规有严格要求的私域研发环境中，SDD 通过企业级、领域级、项目级三层规格的显式注入，为 AI 生成的代码划定了清晰的边界，使得 AI 能力能够在明确边界条件下参与研发活动。这种约束性恰恰是银行科技体系所亟需的工程纪律。民生银行的实践表明，从"规格优先"切入逐步向"规格锚定"演进是更为务实的路径。完全追求"规格为源"在银行私域场景下存在较大应用开销，且规格与代码的一致性保持会成为较大负担。采用混用策略——SDD 与 Copilot 或 Vibe Coding 工具互补——更符合当前工程实际。 AI 度量指标需要从过程性指标（AI 代码采纳率、AI 代码占比）向质效结果导向指标演进，这一判断揭示了智能研发工具评估的根本性转变。当机械式编程劳动已交由 AI 代劳，衡量人类研发效能而非 AI 生成比例才是真正的价值锚点。

实践启示¶

规格资产具有显著的复用价值，应以业务领域或技术领域为单位持续沉淀领域级规格，便于同领域团队间重复利用，降低后续迭代的应用开销。规格撰写质量是 SDD 成败的关键，需要建立标准化的规格模板和核心内容要素，减少个体差异对稳定输出的影响。开发者角色正在从"代码编写者"向"守门员"转变，应聚焦于代码审查、测试等质量管理工作，在 AI 生成的基础上进行质量把控。规格应视作研发资产进行生命周期管理，采用上下文工程管理工具对规格进行规范存储与版本管理，探索增量规格合并、变更归档隔离等策略。 SDD 并非银行业的万能解，其适用性需要结合模型能力、私域知识规范化储备、规格质量、存量工程质量等多方面因素进行综合评估，不应盲目推广。多智能体协同模式是 SDD 进一步深化的方向，通过不同职责的智能体（架构校验、测试增强等）形成约束链条，是将驾驭工程理念落地的重要手段。 → 原文存档