AI原生开发流程设计-从需求分析到代码提交

AI原生开发流程设计-从需求分析到代码提交

前言

随着AI Coding Agent、代码生成工具和大模型能力快速发展，AI已经不再只是单点的编码辅助工具，而是可以参与需求澄清、技术设计、任务拆解、代码实现、测试生成、代码审查和文档沉淀等研发流程环节。

传统开发流程通常围绕"人如何编写代码"设计；AI原生开发流程则需要进一步回答：

• AI可以参与哪些研发活动，哪些决策必须由人完成？
• AI执行任务时需要哪些上下文，以及如何保证上下文准确、最小和安全？
• 如何防止AI误解需求、虚构接口、扩大修改范围或引入安全问题？
• 如何验证AI生成的代码，而不是仅判断代码"看起来合理"？
• 需求、设计、代码、测试和审批如何形成可追溯的证据链？

本篇随笔将"AI原生开发流程"定义为：
以结构化上下文为输入，以人机协作为执行方式，以自动化验证为质量基础，以人工决策为责任边界，并通过可追溯的工程产物连接需求、设计、代码和测试的软件研发流程。

其目标不是让AI取代研发工程师，而是让AI承担信息整理、方案生成、代码草拟和机械检查等工作，使工程师把更多精力投入需求判断、架构权衡、风险控制和最终决策。

为什么要重新设计开发流程

AI编码工具能够快速生成大量"看起来合理"的内容，但"看起来合理"不等于满足真实需求。AI生成的代码可能存在语义错误、安全问题、兼容性问题，也可能无法准确反映开发者意图，因此必须经过审查和测试。

这意味着，AI进入研发流程后，团队面临的核心问题已经从：

传统问题：如何更快地编写代码？->AI原生问题：如何更快地产生经过验证、可以解释并能够追溯的正确代码？

在传统流程中，工程师通常会在头脑中完成大量隐式工作，例如理解业务背景、识别代码约束、判断修改范围和评估风险。AI无法可靠地获得这些隐式信息，因此团队需要把关键知识转化为AI和人都可以理解的需求、上下文、规则、验收标准和验证证据。

因此，AI原生开发的重点不是单纯提高代码生成量，而是建立以下四项能力：

能力	需要解决的问题
上下文工程	让AI基于当前、可信、与任务相关的信息工作
任务分解	把大范围需求拆成目标单一、范围清晰、可独立验证的小任务
自动化验证	通过编译、测试、扫描和差异检查快速发现错误
人工责任闭环	由明确的人确认需求、架构、安全例外和最终合并

AI原生开发的五项基本原则

1.人类对最终结果负责

AI可以提出需求解释、设计建议和代码修改，但业务范围、架构决策、安全例外以及代码合并必须由明确的人类负责人确认。所有AI输出都应被视为待验证的工程草稿，而不是默认正确的事实。

涉及权限、支付、隐私、数据删除、生产配置变更时，不应允许AI在没有人工批准的情况下执行不可逆操作。

2.以工程产物驱动协作

需求、约束、设计、任务、测试结果和审查结论不能只存在于AI对话记录中。AI对话具有临时性，内容可能过时，也不适合作为正式的工程事实来源。真正的事实来源应当是版本库中的需求文档、设计记录、代码、测试和Pull Requst。

关键阶段应留下结构化产物，使后续参与者能够理解当时的目标、依据、决策和验证结果，而不是只保留一句"让AI帮我完成了"。

3.先定义验证方式，再生成代码

在让AI修改代码之前，应先明确：

• 什么行为代表需求已经实现？
• 哪些旧功能不能受到影响？
• 如何执行测试？
• 哪些安全检查必须通过？
• 出现问题时如何回滚？

没有验收标准和验证方式的代码生成，本质上只是扩大了试错范围。

4.最小上下文与最小权限

提供给AI的上下文并不是越多越好。无关或过时的文档可能干扰模型判断，敏感信息还可能带来数据泄漏风险。AI代理获得的执行权限也应保持最小化：

• 默认只读代码库，在确认计划后再开发有限写入权限
• 修改范围限制在当前任务相关目录
• 不提供生产环境凭据和未经脱敏的生产数据
• 不允许直接修改主分支
• 不允许跳过测试、审查或安全检查
• 高风险操作必须由人工确认

5.全流程可追溯

一次代码变更应该能够回答：

• 它对应哪个需求和验收标准？
• 为什么选择当前技术方案？
• 修改了哪些模块，是否超出原定范围？
• 执行了哪些测试和扫描？
• 谁审查并批准了变更？
• 最终构建产物来自哪个代码版本？

对于普通业务项目未必需要一次性建立完整的软件供应链证明，但应至少建立需求编号、提交记录、测试结果和构建版本之间的关联。

从需求分析到代码提交的标准流程

整体流程划分为八个阶段。它们在逻辑上按顺序推进，但在实际执行中允许回退：例如技术方案设计发现需求歧义，应返回需求阶段确认；代码阅读发现上下文不准确时，应先修正上下文再继续

阶段	核心问题	主要产物	进入下一阶段的判断
1.需求分析与澄清	为什么做、为谁做、做什么、不做什么？	需求说明、待确认问题	目标、范围和关键术语已确认
2.定义验收标准	怎样判断需求已经正确实现？	可验证的验收标准	正常、异常和边界行为可检查
3.装配任务上下文	AI完成任务需要知道什么，允许做什么？	最小任务上下文、修改边界	事实来源、代码范围和验证命令明确
4.技术方案设计	在现有约束下如何实现？	技术方案、风险与回滚设计	关键技术决策已确认
5.实施任务规划	按什么顺序把方案变成可审查的小改动	任务清单、依赖和执行顺序	每个任务可独立执行和验证
6.代码生成与迭代验证	如何以最小差异实现并快速获得反馈	代码差异、局部测试结果	相关编译、测试和检查通过
7.测试与质量验证	需求、回归和非功能风险是否得到系统验证？	测试证据、缺陷与风险记录	验证标准有证据，剩余风险有结论
8.审查、提交与PR	变更是否可以有团队接受并合并	审查记录、提交和PR说明	人工审批和自动化状态检查通过

阶段之间的分工：

• 需求定义"为什么和做什么"
• 验收标准定义"怎样算完成"
• 任务上下文定义"AI需要知道什么、能做什么"
• 技术方案定义"如何实现"
• 实施计划定义"按什么顺序执行"
• 测试证据证明"是否真的完成"

阶段一：需求分析与澄清

目标

把模糊的业务描述转换为边界明确、可以实现并能够验证的工程需求。

AI适合完成的工作

• 汇总需求背景、用户角色和使用场景
• 提取功能需求、非功能需求和业务规则
• 找出描述中的歧义、冲突和遗漏
• 生成待确认问题并初步识别影响范围
• 将自然语言需求整理成结构化文档

人工必须完成的判断

• 为什么要做这个需求，以及成功指标是什么
• 哪些内容属于本次范围，哪些明确不做
• 多个目标发生冲突时如何取舍
• 需求的优先级、法律合规和业务风险
• 关键业务规则的最终答案

示例：订单取消需求需要澄清什么

• 哪些状态的订单可以取消？
• 已支付订单如何退款？
• 取消后库存如何恢复？
• 是否允许部分取消？
• 谁拥有取消权限？
• 重复请求如何处理？
• 是否需要记录审计日志？

AI可以生成这些问题，但不能自行假设答案

阶段产物

建议输出requirement-brief.md(需求清单),至少包含：

• 背景与目标
• 用户及使用场景
• 功能范围
• 非功能需求
• 不在范围内的内容
• 业务规则
• 已知约束
• 待确认问题
• 风险与依赖

阶段门禁

• 目标和范围已经确认
• 关键术语不存在歧义
• 待确认问题已有结论或明确负责人
• 需求不存在由AI自行补充的事实
• 每项需求都能够对应至少一个验收条件

阶段二：定义验收标准

目标

把需求转换为可观察、可检查的系统行为。验收标准是连接需求、技术实现和测试证据的核心。

验收标准不等于技术方案

验收标准描述系统必须表现出的行为，不应过早限定具体实现

类型	示例	说明
错误表达	使用Redis实现接口限流	提前指定了实现方式，但没有说明用户可观察到的行为。
更好的表达	同一用户一分钟内最多提交十次请求；超过限制后返回明确错误，且不执行后续业务操作	定义了可验证的输入、边界和结果。

推荐结构

• 前置条件
• 输入或操作
• 预期结果
• 异常路径
• 边界条件
• 可执行或可检查的验证方式

可以采用BDD(Behavior-Driven-Development: 行为驱动开发)语法

Give：用户已经支付订单，订单尚未发货
When：用户提交取消申请
Then：系统创建退款任务，订单进入"退款处理中"状态
And：重复提交不会创建新的退款任务

AI的作用

AI可以帮助补充空值、异常输入、重复调用、并发操作、权限不足、外部服务失败、超时重试、数据一致性和向后兼容场景。但最终验收标准必须由需求负责人和研发负责人共同确认。

阶段产物

建议输出acceptance-criteria.md(验收标准),并给每条标准分配稳定编号，便于在设计、任务、测试和PR中引用。

阶段门禁

• 每项需求至少有一条可验证的验收标准
• 正常、异常和关键边界场景已覆盖
• 验收标准描述行为而不是未经确认的实现方式
• 验证方式可由测试、检查或人工评审执行

阶段三： 装配与校验任务上下文

目标

从项目规范、当前需求、验收标准和代码仓库中，筛选完成本次任务所需的最小可信信息，使AI明确：当前任务要解决什么问题、现有系统如何实现相关功能、应遵守哪些规范、可以修改哪些代码、哪些内容禁止修改，以及如何验证结果。

本阶段的重点不是重新编写一份包含全部项目信息的文档，而是从已有工程资料和代码中装配出适用于当前任务的上下文，并在AI阅读代码后校验这些信息是否准确。

需求和验收标准说明"要达到什么结果"，但不会自动告诉AI现有架构、可复用模式、兼容性约束、禁止修改范围和测试命令。任务上下文用于弥合“业务目标”与"现有代码库"之间的信息差。

上下文的三个层次

1.项目级上下文：长期维护的基础规则

项目级上下文适用于多个研发任务，由团队统一维护，不应在每个需求中重复复制。可以包括：

• 项目目标、核心业务术语和技术栈
• 仓库目录、核心模块及其职责
• 编码、异常处理、日志和监控规范
• 测试、构建、格式化和静态检测命令
• 安全要求、禁止修改的公共模块
• 常用组件、推荐实现模型和重要架构文档

这些内容可以保存在README.md、CONTRIBUTING.md、ARCHITHECTURE.md、AGENTS.md或AI工具的项目规则中

2.任务级上下文：本阶段重点装配的信息

任务级上下文针对当前需求筛选，至少应说明：

1. 当前需求和验收标准
2. 涉及的业务模块及调用链
3. 相关接口、数据模型和测试
4. 需要参考或复用的现有实现
5. 允许修改的文件或目录
6. 禁止修改的模块和无关范围
7. 必须遵守的兼容性、安全和数据约束
8. 必须执行的测试和检查命令
9. 已知风险、依赖和待确认问题

例如：修改一个订单查询接口时，通常需要订单领域模型、查询接口及其调用链、数据访问层、相关测试、现有分页和异常处理方式、本次需求与验收标准，以及允许修改的文件范围；通常不需要整个代码仓库、全部历史需求和所有数据库表结构。

3.执行级上下文：实施过程中动态形成的信息

执行级上下文是在AI阅读代码、设计方案和修改代码过程中逐步获得的信息，例如实际调用关系、可以复用既有实现、代码与文档的差异、测试失败原因、新发现的约束和未解决问题。

执行级上下文通常不必形成独立长期文档，可以记录在实施计划、AI工作会话、技术方案、测试证据或PR说明中。发现原有上下文不准确时，应先更新任务理解和计划，再继续生成代码。

上下文装配原则

原则	具体要求
最小相关	只提供完成当前任务所需的信息；避免无关代码、过时文档和完整数据集干扰判断
事实来源优先	优先引用当前代码、已确认需求、验收标准、接口定义、数据模型、架构决策和自动化测试
引用而非复制	记录文件路径、代码位置和文档章节，减少内容重复和多处维护
边界明确	明确允许修改、禁止修改和需要人工批准的范围；AI不得自行扩大任务
持续校验	AI阅读代码后重新检查相关文件、调用链、参考实现、文档一致性和测试命令
最小权限	上下文读取和工具权限均限制在完成当前任务所需的范围

引用而非复制的示例

相关领域模型：src/order/domain/order.py
异常处理规范：docs/development/error-handling.md
参考实现：src/customer/service/customer_query.py
验收标准：docs/requirements/ORDER-102/acceptance-criteria.md

边界明确的示例

允许修改：
- src/order/query/
- tests/order/query/

禁止修改：
- 公共分页组件
- 数据权限拦截器
- 数据库公共连接配置
- 与本次需求无关的接口

如果AI发现必须修改禁止范围内的文件，应停止修改并说明原因，由负责人决定是否扩大范围

AI在本阶段可以完成的工作

• 分析需求可能涉及的模块和调用链
• 查找相关接口、数据模型、测试和相似实现
• 汇总当前任务需要遵守的项目规范
• 生成任务上下文清单并识别缺失、冲突或过时信息
• 建议初步修改范围和验证命令
• 检查上下文中是否包含敏感信息

AI不能自行决定冲突文档中的最终业务规则，不能突破禁止修改范围，不能忽略安全和兼容性要求，也不能把未经确认的业务假设当作事实

安全边界

提供给AI的上下文中不得直接包含：

• 生产数据库密码、API密钥、私钥和证书
• 用户隐私数据和未经脱敏的生产日志
• 生产环境访问凭据
• 与当前任务无关的敏感配置或受限制商业数据

如果任务必须分析生产问题，应优先提供脱敏日志、最小化复现数据或经过授权的测试环境信息。

阶段产物

本阶段可以输出contenxt-package.md(上下文包)，也可以把任务上下文合到Issue、实施计划或AI任务描述中。大型、跨模块或高风险任务应形成正式任务上下文；小型任务不必单独建文档，但至少明确任务目标、相关代码、修改范围、实现约束和验证方式。

# 任务上下文

## 任务目标
说明本次任务需要实现的结果。

## 关联需求和验收标准
列出需求文档和验收标准的位置。

## 相关模块与代码
列出接口、模型、服务、数据访问层和测试文件。

## 参考实现
列出项目中应复用的相似实现。

## 实现约束与修改边界
说明编码、异常、事务、权限、兼容性和禁止修改范围。

## 验证方式
列出编译、静态检查和测试命令。

## 风险、依赖与待确认问题

阶段门禁

• 当前需求和验收标准已经关联
• 相关业务模块和代码范围已经初步识别
• 项目规范和参考实现已经明确
• 允许修改和禁止修改的范围已经说明
• 测试和验证命令已经确定
• 上下文中不存在明文敏感信息
• 关键文档与代码不存在未经说明的冲突
• 待确认问题已有负责人或处理方式

阶段四：技术方案设计

目标

在需求、验收标准和任务上下文明确后，确定满足当前约束的实现方式，并显示记录关键决策、风险和回滚策略。

任务上下文回答"现有系统是什么样、AI需要知道什么"；技术方案回答"在这些事实和约束下，本次具体如何实现"。

AI可以提供的帮助

• 分析可能受影响的模块和兼容性问题
• 提出多个候选方案并比较复杂度、收益和风险
• 生成接口、数据模型和异常流程草案
• 识别数据迁移、事务一致性和回滚需求
• 生成设计审查问题

人工必须确认的决策

• 业务和架构取舍
• 是否引入新依赖、公共抽象或数据结构变化
• 安全、隐私和兼容性风险是否可接受
• 灰度、迁移和回滚策略
• 是否存在更简单、范围更小的方案

技术方案至少应说明

• 当前问题与约束条件
• 候选方案及比较
• 选择的方案和放弃其他方案的原因
• 接口、数据模型和状态变化
• 事务、一致性、权限和安全控制
• 监控、日志、灰度和回滚
• 已知风险和验证策略

高影响或长期有效的架构决策，可以通过ADR(架构决策记录)保存背景、选项、结论和影响。

AI相关功能的额外要求

• 模型输入来自哪里，是否包含敏感数据
• 输出是否会直接触发操作，是否必须进行格式和权限校验
• 是否存在提示词注入、越权工具调用或数据泄漏风险
• 失败时是否有降级策略
• 如何评估准确性、安全行和回归效果
• 模型、提示词或知识库变更如何纳入版本管理和测试

阶段产物与门禁

建议输出solution-design.md(解决方案设计)。进入任务规划前，应确认影响范围、关键技术方案、接口和数据变化、安全与兼容性风险、测试策略和回滚方式均已明确。

阶段五：实施任务规划

目标

把已经确认的技术方案拆分为目标单一、范围明确、可以独立验证且容易审查的小任务。

技术方案说明系统将如何变化；实施计划说明这些变化按什么顺序落地、每一步允许修改什么、如何单独验证。

为什么需要拆分

一个同时包含数据库、服务端、前端和基础设施变更的任务，如果只交给AI一句"实现这个需求"，容易出现修改范围失控、遗漏异常路径、失败后难以定位和代码差异难以审查的问题。

任务拆分原则

• 目标单一
• 修改范围明确
• 能够独立编译或验证
• 失败后容易回滚
• 对应具体验收标准
• 产生较小、易审查的代码差异
• 依赖关系和执行顺序明确

任务拆分示例：订单取消功能的任务拆分

1. 增加订单状态转换规则
2. 增加取消领域服务
3. 增加退款任务接口
4. 增加幂等控制
5. 增加审计日志
6. 增加API接口
7. 增加单元测试和集成测试
8. 更新接口文档

单个任务的标准描述

任务目标：
关联需求与验收标准：
前置依赖：
允许修改的文件：
禁止修改的范围：
实现约束：
必须执行的测试：
预期输出：
完成条件：

阶段产物与门禁

建议输出implementation-plan.md(实施计划)。AI只有在每个任务的目标、范围、约束、依赖和验证方式明确后，才应进入代码修改阶段。

阶段六：代码生成与迭代验证

目标

以小步迭代的方式生成最小代码差异，并在每一步之后执行即时验证，尽早暴露错误理解和实现缺陷。

推荐循环

步骤	要求
1.阅读相关代码	先理解现有行为、调用链和可复用模式，不立即修改
2.复述当前理解	说明需求涉及哪些模块、可能的影响和缺少的信息
3.给出修改计划	列出拟修改文件、步骤和验证方式
4.生成最小差异	只完成当前子任务，避免无关重构和批量格式化
5.执行即时验证	运行编译、类型检查、格式检查、相关单元测试和差异检查
6.分析结果	说明失败原因、风险和下一步，必要时回退到上下文、设计或计划阶段

先读代码，不立即修改

要求AI先回答：当前代码如何工作、需求涉及哪些模块、有哪些既有模式可以复用、可能产生哪些兼容性影响、还有哪些信息不足。这样可以在生成代码之前暴露错误理解。

只生成最小修改

除非方案明确要求，否则AI不应执行大规模重构、全局格式化、批量重命名、更新无关依赖、修改无关配置或删除无法理解的代码。代码差异越小，审查和回滚成本越低。

每次修改都执行验证

• 编译或类型检查
• 代码格式检查和静态分析
• 与当前子任务相关的单元测试
• 必要的集成测试
• 依赖、安全和密钥扫描
• 代码差异检查

禁止AI静默处理失败

测试失败时，AI不能通过删除测试、降低断言强度、忽略错误或绕过检查来制造"通过"。它必须说明哪个测试失败、失败原因、应修改代码还是测试、为什么修改符合要求，以及是否影响原有行为。

停止条件

出现以下情况时，应暂停代码修改并请求人工判断：需求或上下文存在冲突、必须突破禁止修改范围、需要新增高风险依赖、测试环境无法证明关键行为、涉及生产数据或不可逆操作。

阶段产物

本阶段主要产生代码差异、执行日志和局部验证结果。它们可以暂存在开发环境和提交记录中，并在阶段七汇总为完整测试证据。

阶段七：测试与质量验证

目标

从需求、回归风险和非功能风险出发，对完整变更进行系统性验证，并形成可审查的证据。

阶段六的验证面向每次小改动，用于快速反馈；阶段七面向完整需求，用于确认验收标准、回归行为和非功能风险已经得到整体覆盖。

AI可以帮助生成测试，但由同一个AI同时生成实现和测试，并不能自动构成充分的独立验证。测试必须回到需求和风险本身，并由人审查关键用例和结果。

推荐的验证层次

1. 需求验证：逐条检查验收标准是否已经实现，避免只验证"代码能够运行"
2. 单元测试：覆盖正常路径、边界值、异常输入、状态变化和错误处理
3. 集成测试：验证数据库、消息队列、外部服务、事务边界、超时重试和幂等行为。
4. 回归测试：确认原有功能没有因为本次修改收到破环，特别关注公共组件和共享数据结构。
5. 非功能验证：根据需求和风险选择性能、并发、安全、可用性、兼容性和可观测性测试。
6. 静态与供应链检查：检查代码漏洞、密钥泄漏、高风险依赖、许可证风险、构建配置和依赖版本变化。

测试证据

建议生成test-evidence.md(测试证据)，记录测试环境、执行命令、结果、覆盖的验收标准、未执行测试及原因、已知缺陷和风险接受人。

证据字段	说明
验收标准编号	明确本项测试证明了哪些业务行为
测试环境与版本	记录代码版本、依赖、数据库或外部服务替身
执行命令与结果	保留可复现的命令、状态和关键输出
未执行项	说明缺失环境、时间限制或其他原因及补充措施
剩余风险	记录已知缺陷、影响范围和接受责任人

阶段门禁

• 验收标准都有对应验证证据
• 相关单元、集成和回归测试通过
• 必要的安全、依赖和静态检查通过
• 未执行的测试和剩余风险已明确说明
• 不存在通过削弱测试或绕过检查获得的虚假通过

阶段八：代码审查、提交与Pull Request

目标

由人和自动化检查共同确认需求理解、技术实现、代码质量、验证证据和上线条件，使变更成为团队可以接受、追溯和维护的工程成果。

AI第一轮审查适合关注

• 明显逻辑错误、空指针和边界问题
• 重复代码、异常处理遗留和测试缺失
• 文档、接口与代码不一致
• 潜在安全问题
• 与项目规范不一致的实现
• 修改范围与计划不一致

人类审查需要关注

• 需求和业务规则是否被正确理解
• 架构方向和修改范围是否合理
• 测试证据是否可信并覆盖主要风险
• 安全、数据和兼容性风险是否可接受
• 是否存在更简单的实现
• 是否具备部署、监控和回滚条件

人类审查者不能只阅读AI生成的变更摘要，还要检查真实代码差异和关键测试结果

Pull Request应包含什么

• 关联需求或Issue
• 修改目的和主要变更
• 不在本次范围内的内容
• 技术方案和关键决策
• 风险、数据库或配置变化
• 测试证据
• 部署和回滚步骤
• 是否使用AI辅助
• 需要审查者重点关注的内容

提交前检查

[ ] 代码差异只包含本次需求相关修改
[ ] 不包含密钥、账号或敏感数据
[ ] 编译、静态检查和必要扫描通过
[ ] 单元测试和必要的集成测试通过
[ ] 验收标准已经逐条验证
[ ] 文档、接口和配置已经同步更新
[ ] AI生成的代码和提交说明已经人工检查
[ ] 已说明风险、部署和回滚方式

提交信息即使由AI生成，也必须由开发者检查和编辑，确保准确说明修改目的和影响。

阶段产物与门禁

建议形成review-record.md(审查记录)和pr-descriptionn.md(PR描述)，也可以直接通过代码审查记录和PR模版承载。只有人工审查完成、自动化状态检查通过、PR信息完整、部署和回滚条件明确、最终负责人批准后才可以合并。

建议建立的八类工程产物

一套轻量级AI原生开发流程可以围绕以下八类信息运行。它们不一定都要成为独立文件，小型需求可以合并，但其中的关键信息不应省略。

产出的文件	主要内容	可合并位置
requirement-brief.md	需求背景、目标、范围、约束和待确认问题	Issue或需求单
acceptance-criteria.md	可验证行为、异常场景和边界条件	需求说明或测试用例
context-package.md	相关代码、项目规范、参考实现和AI操作边界	Issue、任务说明或实施计划
solution-design.md	技术方案、接口、数据、风险和回滚设计	设计评审记录或ADR
implementation-plan.md	任务拆分、依赖关系、修改范围和执行顺序	开发任务清单
test-evidence.md	测试命令、结果、覆盖范围和未解决问题	CI结果或PR说明
review-record	AI检查结果、人工意见和处理结论	代码审查记录
pr-description.md	变更摘要、风险、验证证据和发布说明	Pull Request模版

工程产物的管理原则

• 单一事实来源：同一规则尽量只在一个正式位置维护，其他文档使用引用
• 稳定编号：需求、验收标准、任务和测试证据之间使用稳定编号关联
• 随代码版本化：重要规范、设计和测试证据应与代码一同进入版本库
• 按风险裁剪：小型低风险任务可合并文档，高风险任务需要更完整的证据
• 避免形式主义：文档价值在于减少误解、限制范围和支持审查，而不在于文件数量

四个关键质量门禁

为了避免流程变成机械填表，可以在组织层面只设置四个关键门禁。阶段内的检查项用于准备材料，门禁用于决定是否允许进入下一类活动。

门禁	必须满足的条件	主要负责人
1.需求就绪	目标和范围明确；歧义已处理；验收标准可执行；风险和依赖已识别	需求负责人、研发负责人
2.设计就绪	任务上下文可信；影响范围明确；技术方案已确认；安全、数据、兼容性、测试和回滚方案已定义	研发负责人、架构或安全负责任人
3.代码就绪	修改范围符合计划；编译、测试和扫描通过；验收标准有证据；不存在未经说明的设计偏差	开发者、测试人员
4.合并就绪	人工审查完成；自动化状态检查通过；PR信息完整；部署和回滚条件明确；最终负责人批准	代码所有者、发布责任人

AI可以帮助检查材料是否完整、识别缺失和生成审查问题，但是是否允许进入下一阶段，应由项目定义的责任人决定。

如何评价AI原生开发流程

不建议把AI生成了多少行代码作为核心指标。代码生成量越大，并不代表交付价值越高，甚至可能意味着审查和返工成本增加。更合理的指标包括：

• 从需求确认到PR场景的周期
• 需求澄清阶段发现的问题数量
• PR平均修改范围和超范围修改比例
• 代码审查发现的问题
• 测试阶段发现的缺陷和上线后的逃逸缺陷
• 返工次数
• 验收标准覆盖率
• 自动化检查通过率
• AI生成内容被人工否决或重写的比例
• 从代码提交追溯到需求和测试的完整度

这些指标用于判断AI是在缩短反馈周期、降低缺陷和提高追溯性，还是仅仅提取生成了更多需要返工的内容。

落地建议

团队不需要一次性改造全部研发流程。更稳妥的做法是从低风险、边界清晰、已有自动化测试的项目开始，并根据实际问题逐步增加规范和工具

第一阶段：建立最小闭环

1. 每个需求都有结构化需求说明和验收标准
2. AI每次修改代码前必须输出理解和计划，修改后必须执行测试
3. 主分支必须经过人工审查和自动化状态检查

第二阶段：建立可复用的项目能力

1. 项目级AI上下文规范
2. 标准化设计和任务模版
3. PR模版和CODEOEWNERS
4. 安全扫描、依赖检查和测试证据归档
5. AI操作审计和权限控制

第三阶段：强化供应链与度量

1. 构建和发布来源追踪
2. 需求、提交、测试和发布之间自动关联
3. 流程质量指标和持续改进机制
4. 在验证和审计能力成熟后，谨慎扩大AI代理权限

AI权限的扩大必须建立在验证能力、回滚能力和审计能力已经完善的基础上，而不是建立在对模型能力的主观信任上。

结语

AI原生开发不是把传统研发流程中每一个人工步骤都替换成AI，而是重新设计人与AI之间的职责边界

要素	在流程中的作用
需求文档	为AI和团队提供明确目标与范围
验收标准	定义什么结果才算正确
任务上下文	约束AI的理解范围、事实来源和操作边界
技术方案	记录关键实现决策和风险
实施计划	把方案拆成小而可验证的修改
自动化测试	提供快速反馈和验证证据
人工审查	承担业务、架构、安全和最终合并责任
提交记录与PR	建立需求、代码、测试和审批的追溯链

真正成熟的AI原生开发流程，不以“AI能写多少代码”为标准，而以团队能否持续、稳定地交付经过验证的软件为标准。AI负责提高探索和执行速度，人类负责定义目标、判断正确性并承担最终责任。

参考资料

ISO/IEC/IEEE 29148:2018,Systems and software engineering — Life cycle processes — Requirements engineering

NIST AI 600-1,Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

NIST SP 800-218,Secure Software Development Framework，SSDF Version 1.1

ISO/IEC/IEEE 29119,Software and systems engineering — Software testing

GitHub Docs,Responsible use of GitHub Copilot Chat

GitHub Docs,Managing and standardizing pull requests

OWASP,Top 10 Risks and Mitigations for LLMs and Gen AI Apps 2025

SLSA Specification v1.2,Provenance。