AI原生开发探索：企业内网环境下的软件研发实践分享

AI原生开发探索：企业内网环境下的软件研发实践分享

背景与思考

软件研发模式的发展变化

阶段	核心驱动力	研发特点	人员角色
传统软件工程	流程	阶段交付	执行流程
敏捷开发	迭代	快速反馈	业务协作
DevOps	自动化	持续交付	全生命周期负责
云原生	平台化	弹性、高可用	系统工程能力
AI原生开发	智能化	人与AI协同	AI增强型工程师

软件研发模式的发展，本质上是研发效率提升和复杂度管理方式的演讲。从最初依赖流程规范，到敏捷强调快速反馈，再到DevOps实现自动化交付、云原生实现平台化能力，如今AI正在进一步改变研发过程，使工程师从代码生成者逐渐转变为AI协同下的问题解决者。

当前研发过程中的痛点

1.需求理解成本高

场景：

研发人员接收到业务需求后需要：

• 阅读需求文档
• 理解业务背景
• 梳理功能边界
• 识别隐含需求
• 确认异常场景

痛点：

• 需求描述不完整
• 业务知识依赖个人经验
• 研发与业务之间存在理解偏差

2.技术方案设计效率不足

场景：

面对一个新功能，研发人员需要考虑：

• 系统架构设计
• 数据模型设计
• 接口设计
• 技术选型
• 风险评估

痛点：

• 方案设计耗时较长
• 优秀经验难沉淀
• 新成员学习成本高

3.编码开发存在大量重复工作

场景：

日常开发中存在大量重复性任务：

• CRUD代码生成
• DTO/VO转换
• SQL编写
• 单元测试编写
• 接口文档生成

痛点：

• 编码时间占比高
• 重复劳动影响效率
• 容易产生低级错误

4.代码质量保障压力增加

场景：

代码提交前需要进行：

• Code Review
• 代码规范检查
• 性能分析
• 安全检查

痛点：

人工Review存在：

• 时间有限
• 关注点不同
• 难以发现隐藏问题

5.技术资料查询与知识获取成本高

场景：

研发过程中经常需要：

• 查询官方文档
• 分析异常日志
• 学校新框架
• 理解历史代码

痛点：

• 信息获取耗时
• 知识分散
• 经验难复用

6.项目文档维护成本高

场景：

研发交付需要：

• 技术方案
• 接口文档
• 更新说明
• PR描述
• 发布说明

痛点：

开发人员通常：重代码实现，轻文档沉淀

导致：

• 文档滞后
• 信息不完整
• 后续维护困难

AI赋能研发的机会

面对这些研发过程中遇到的痛点，AI可以成为研发过程中的智能协作者。

从：研发人员独立完成所有工作转变为：研发人员+AI协作完成研发活动

公司AI转型实践：建设企业AI平台

建设背景

随着大模型技术快速发展，AI正在逐步融入软件研发全过程。

虽然通用大模型已经能够辅助完成部分研发工作，但企业内部实际应用过程中仍面临一些问题：

• 外部模型服务直接访问存在数据安全风险
• 不同模型接口、调用方式存在差异
• AI使用过程缺少统一管理和权限控制
• 无法统计AI使用情况和成本
• 企业知识、研发规范和工程经验难以沉淀

因此，公司需要建设企业级AI能力平台，为研发人员、业务系统以及智能Agent提供统一、安全、可管理的AI基础能力。

企业AI平台总体架构

企业AI平台不是单一的大模型调用入口，而是围绕AI能力接入、模型管理、知识增强、智能编排以及治理运营形成的一套完整能力体系。

整体架构包括：

1.AI能力调用入口

企业AI平台支持多种方式接入，包括：

业务应用入口

• Web应用
• 移动端应用
• OA、ERP、CRM等业务系统

研发智能入口

• IntelliJ IDEA插件
• VS Code插件
• Cursor等AI开发工具
• Codex CLI
• Claude Code

智能Agent入口

• 研发Agent
• 运维Agent
• 测试Agent
• 文档Agent

通过统一入口，使不同用户和应用能够以一致方式访问企业AI能力。

2.AI Gateway：统一AI访问与治理入口

在企业AI平台中，AI Gateway承担模型访问入口和请求治理能力。

它位于调用方与底层模型服务之间，用于屏蔽不同模式服务之间的差异。

整体流程：

AI调用方

(IDE插件 / 业务系统 / Agent)

        ↓

    AI Gateway

        ↓

模型服务

(GPT / Claude / DeepSeek / Qwen)

通过AI Gateway，调用方无需关注：

• 不同模型API协议
• 不同认证方式
• 不同模型部署位置
• 不同调用参数规范

AI Gateway主要提供：

1. 统一接入：提供统一API访问方式，使企业内部不同应用可以通过标准接口调用AI能力。

2. 访问控制：通过身份认证、权限管理和安全策略，控制不同人员和系统可使用的AI能力。

3. 调用治理：对AI调用过程进行：

   1. 日志记录
   2. 使用统计
   3. Token消耗分析
   4. 异常监控

   实现AI能力的可管理和可追踪。

3.AI能力服务层

在统一访问能力基础上，企业AI平台进一步提供面向业务和研发场景的AI能力。

主要包括：

Prompt管理

沉淀企业常用Prompt模版，例如：

• 需求分析Prompt
• 技术方案设计Prompt
• 代码Review Prompt
• 测试生成Prompt

使优秀的AI使用经验能够复用。

知识库与RAG能力

将企业内部知识转化为AI可利用的信息，包括：

• 技术文档
• 架构规范
• 项目资料
• 开发规范

通过知识增强，提高AI回答的准确性。

Agent能力

基于大模型构建面向具体任务的智能Agent。

例如

研发Agent:

需求分析

↓

技术方案生成

↓

代码辅助开发

↓

测试验证

运维Agent:

日志分析

↓

问题定位

↓

解决建议

4.模型与AI能力服务

企业AI平台支持多种模型来源：

云端通用大模型

例如：

• GPT系列
• Claude
• Gemini
• 通义千问等

特点：

• 能力成熟
• 持续更新
• API调用

企业私有模型

例如：

• DeepSeek
• Qwen
• Llama
• GLM

特点：

• 企业内部部署
• 数据可控
• 满足安全要求

AI增强能力模型

包括：

• Embedding模型
• Rerank模型
• OCR模型

用于知识检索、多模态处理等场景

5.企业治理与运营能力

为了保障AI能力长期稳定运行，企业AI平台需要具备治理能力，包括：

安全与合规

• 用户权限控制
• 数据安全检测
• 内容审核
• 操作审计

监控与运营

• 调用监控
• 性能分析
• 异常告警

成本管理

• Token统计
• 模型调用分析
• 使用成本评估

通过治理能力，使AI从个人工具转变为企业可管理的基础能力。

AI平台赋能AI原生开发

企业AI平台建设后，研发模式从：

研发人员独立完成研发工作

转变为：

研发人员

    +

企业AI能力

    +

工程规范

    ↓

AI增强型研发模式

研发人员可以通过IDE插件、CLI Agent等工具调用企业AI能力，将AI融入：

• 需求分析
• 技术设计
• 代码实现
• Code Review
• 测试验证
• 文档交付

最终形成以人为核心，AI辅助协作的软件研发模式。

建设价值

企业AI平台建设的核心价值包括：

1. 统一企业AI入口：降低不同团队接入和使用AI的成本
2. 保障AI使用安全：通过权限、审计和治理能力降低企业应用风险
3. 支持多模型灵活使用：根据业务场景选择合适模式
4. 沉淀企业AI资产：形成可复用的Prompt、知识库和Agent能力
5. 支撑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辅助敏捷开发实践

实践背景

在前面的AI原生开发理念中，设计了一套从需求分析、验收标准、任务上下文、技术方案、实施规划到代码提交的完整研发流程。

该流程适用于：

• 需求目标明确
• 功能范围相对稳定
• 需要输出规范性工程文档
• 对研发过程可追溯性要求较高的项目

例如：

• 新系统建设
• 中大型功能建设
• 跨团队协作项目
• 需要完整设计文档沉淀的研发任务

但是，在实际软件研发过程中，并非所有需求都符合上述模式。

特别是在敏捷开发场景下，经常存在：

• 需求初始描述不完整
• 业务人员在使用过程中不断提出调整意见
• 开发过程中发现新的业务规则
• 技术方案需要随着代码理解不断调整

因此，如果完全按照八阶段流程一次性完成，可能会导致：

• 前期分析成本较高
• 需求变化后大量返工
• 降低敏捷迭代速度

因此，在实际开发过程中，需要根据需求稳定性选择不同的AI协作方式。

AI原生开发模式的实际调整

1.明确需求场景：工程产物驱动模式

对于需求明确、变化较少的项目：

采用完整AI原生开发流程。

特点：

• 前期投入较多
• 工程产物完整
• 适合长期维护项目
• 便于团队协作和知识沉淀

流程：

需求澄清

 ↓

验收标准定义

 ↓

任务上下文装配

 ↓

技术方案设计

 ↓

实施任务拆解

 ↓

代码生成

 ↓

测试验证

 ↓

PR提交

2.敏捷开发场景：AI协同迭代模式

对于快速迭代、小范围功能开发：

采用更加灵活的协作方式。

核心思想：

不要求AI一次性理解完整需求，而是围绕最小功能点，通过人与AI持续交互逐步完善方案，并快速验证。

整体流程：

最小需求点

    ↓

AI分析理解

    ↓

生成实现方案

    ↓

人工确认

    ↓

代码修改

    ↓

立即验证

    ↓

问题反馈

    ↓

继续AI协作优化

敏捷开发中的AI协助实践流程

1.项目上下文准备

在开始具体开发前，首先通过项目级上下文约束AI行为。

主要包括：

• 项目技术栈
• 项目目录结构
• 编码规范
• 架构约束
• 测试命令
• 禁止修改范围

例如：

通过AGENTS.md描述：

项目技术栈：
Backend：
Spring Boot 3.4
JDK 17

Frontend:
Vue2
Vite

开发规范：
- Controller只负责接口处理
- Service负责业务逻辑
- 禁止直接修改公共组件
- 修改代码后必须执行测试
- 当用户说[生成提案]时，提案文件前用[## 原始描述]原封不动记录用户的原话及后续追加要求

作用：

让AI首先理解：

• 当前项目是什么
• 应该采用什么方式修改
• 哪些范围不可触碰

2.从最小需求点开始

敏捷开发中，不直接输入：

"帮我完成整个需求"

而是拆分为最小可交付功能点。

例如：

完整需求：

新增机构行政区域编码补全功能

拆分：

功能点1： 新增行政区域匹配服务

功能点2： 增加批量补全接口

功能点3： 增加任务执行状态查询

功能点4： 增加前端进度展示

每次围绕一个明确目标进行AI协作。

3.AI生成实现提案，通过多轮交互完善方案

这是实际AI辅助开发过程中最重要的环境。

与传统代码生成不同：

AI并不是直接根据需求生成代码，而是：

先分析现有代码和上下文，生成初步实现方案，并主动识别不确定项，通过研发人员补充信息逐步完善设计。

AI分析并生成初步实现提案

研发人员输入：

实现机构行政区域编码自动补全功能，请分析当前代码结构并提出实现方案。

AI首先分析：

涉及模块：

1. OrganizationService
2. AreaService
3. Task模块


建议方案：

1. 新增AreaMatchService
2. 扩展机构补全任务
3. 增加匹配规则处理


影响范围：

backend/service
backend/domain


验证方式：

增加匹配规则单元测试

AI主动识别不确定项

在方案分析过程中，如果上下文不足，AI不会自行假设，而是主动提出问题

例如：

当前存在以下待确认问题：

Q1：
行政区域匹配失败时是否需要保存失败记录？

Q2：
一个机构名称匹配多个行政区域时如何处理？

Q3：
补全任务是否允许重复执行？

Q4：
行政区域数据来源是否已经存在统一数据表？

Q5：
批量补全任务采用同步还是异步执行？

研发人员补充业务约束

研发人员根据实际业务回答：

例如：

Q1：
失败需要记录日志，不保存失败数据。

Q2：
优先匹配最小行政区域。

Q3：
允许重复执行，只处理未完成数据。

Q4：
使用统一行政区域表。

Q5：
采用异步任务执行。

AI基于补充信息完善方案

AI重新调整：

更新后的实现方案：

1. 新增AreaMatchService

职责：
- 行政区域名称匹配
- 简称匹配
- 编码返回


2. 增加异步补全任务

职责：
- 批量处理机构数据
- 更新补全状态


3. 增加任务日志

记录：
- 执行时间
- 成功数量
- 失败原因


4. 增加统计查询接口

人工确认最终方案

最终由研发人员确认：

业务方面：

• 是否符合真实业务流程
• 是否遗漏关键场景

技术方面：

• 是否符合当前系统架构
• 是否影响已有功能

范围方面：

• 是否存在过度设计
• 是否引入无必要改造

确认通过后基于该提案进入代码实现。

4.AI辅助代码实现

方案确认后进入编码阶段。

原则：

• 小范围修改
• 最小代码差异
• 避免无关重构

流程：

方案确认

 ↓

AI生成代码

 ↓

查看代码Diff

 ↓

人工检查

 ↓

执行测试

重点关注：

• AI是否正确理解方案
• 是否遵守项目规范
• 是否产生额外修改

5.功能完成后立即验证

敏捷开发强调快速反馈。

因此，每完成一个功能点：

立即执行验证：

• 编译检查
• 单元测试
• 接口测试
• 页面验证

流程：

代码修改完成

       ↓

启动服务

       ↓

功能验证

       ↓

发现问题

       ↓

AI辅助分析

       ↓

再次调整

6.AI辅助问题定位与优化

当功能验证失败：

不是重新开始开发，而是继续进入AI协作循环。

例如：

输入：

接口返回结果不符合预期。

日志如下：

xxx异常

请分析原因。

AI协助：

• 分析调用链
• 定位问题代码
• 判断原因
• 提供修复方案

然后：

问题定位

 ↓

修改代码

 ↓

重新验证

直到功能满足要求。

实践总结

通过实际开发过程可以发现：

AI原生开发并不是固定一套流程，而是一种新的研发协作方式。

不同场景采用不同模式：

场景	AI协作方式
大型项目、新系统建设	完整八阶段流程
规范要求高的功能开发	工程产物驱动
敏捷迭代、小需求开发	AI多轮交互协作
Bug排查和问题定位	AI辅助分析

真正有效的AI研发模式不是：

让AI直接写代码

而是

让AI参与理解、分析、设计和验证，通过人与AI持续协作完成软件交付

最终形成：

研发人员
    +
AI能力
    +
工程规范

=

AI增强型软件研发模式