规范驱动开发何时值得用于AI代码治理

AI编程助手已逐渐成为开发基础设施，生成代码覆盖软件生命周期并进入生产环境，但安全漏洞、常见缺陷和行为偏离仍然存在，验证因此取代编码成为瓶颈。EU AI Act、ISO/IEC 42001和NIST AI风险管理框架都强调风险管理、记录保存及有效人工监督，仅称“人工审核”已不足以说明治理如何落地。

规范驱动开发把规范视为经过审查、批准和版本化的治理基线，而非提示词装饰。规范包括业务需求、HLD和LLD：以转账服务为例，要求资金守恒、操作原子化、幂等Key只能执行一次；更低层则明确余额不足时拒绝且不改状态，并将规则落实为可引用的不变量。研究基线覆盖核心资金操作、利息、限额、账单和账户生命周期，共20项不变量。

该流程设置五个控制点：先编写规范并形成草稿，再完成规范审查并留下审批人和时间戳；随后依据特定版本生成代码，记录模型与基线版本；接着检测并记录偏离，最后由人工核对、修改实现或更新设计，并保存变更人和理由。这样可形成从需求、生成到偏离处理的审计轨迹。按RACI划分，模型只对生成执行负责，最终责任始终属于人类。

研究围绕“人能否发现代码偏离基线”展开，指标包括缺陷召回率和归因能力。对象是一个受监管约束的多账户银行服务，包含开户、存取款、余额、转账、历史、每日取现限额、计息、对账单、总资产和销户等API；系统必须保证资金守恒、转账原子且幂等、限额有效并保留审计记录。研究生成了两套独立实现，分别采用Java和Python。

5名拥有3至10年经验的评审人员参与平衡交叉的2×2实验，分别在“基线”和“仅代码”条件下审查两套服务。他们不能运行代码、使用AI或联网查询，最终确认两套服务分别存在11个和10个真实偏离，结果通过源代码而非单一测试用例判定。初步结果显示，规范基线没有让评审发现更多缺陷，却显著改变了发现问题的依据：评审能够把偏离对应到具体要求或不变量，从而提升解释性、追溯性和问责能力。研究样本和任务数量有限，因此结论仍属方向性发现；是否采用这套方法，关键取决于业务风险、审计要求以及额外治理成本是否值得。