AI 写代码已经不难了。

补全方法、生成接口、修改页面、编写单元测试，主流编程模型都能完成。真正难的是把 AI 放进一个拥有数千个文件、多人协作多年、需求材料分散的真实项目后，它还能不能把一个需求完整交付。

最近，腾讯技术团队分享了一套移动端需求开发 Skill。它将需求收集、设计稿分析、任务拆解、代码定位、编码、编译、模拟器验证、技术沉淀和代码提交串成了一条完整流程。

按照项目团队的统计口径，AI 代码生成率达到了约 94%。但相比这个数字，更值得关注的是它背后的工程方法：**AI 编程的上限，不只取决于模型能力，更取决于团队能否把研发经验变成规则、知识、工具和质量门禁。** 

## 目录

1. AI 写业务代码为什么总差一步
2. 一个 Skill 到底包含什么
3. 如何在大型代码库中找到改动点
4. 怎样把产品语言翻译成代码任务
5. 为什么验证必须成为流程的一部分
6. 红线与人工关卡如何控制风险
7. 94%代码生成率应该如何理解
8. 软件测试团队可以借鉴什么

---

## 一、AI写业务代码为什么总差一步

在演示项目中，AI 编程通常很顺利。

用户给出一个清晰任务，模型生成代码，运行后就能看到结果。但企业项目中的需求，很少能用一句话描述完整。

一个看似简单的页面改动，背后可能涉及：

* 产品需求和补充说明；
* Figma 设计稿；
* 接口字段和数据模型；
* 历史业务逻辑；
* 页面组件和点击事件；
* 日志、埋点与兼容处理；
* 构建系统和自动化测试。

AI 面对的不是“写一个方法”，而是“在现有工程约束下完成一次需求交付”。

这时，几个问题会集中出现。

### 上下文装不下

项目可能包含几千甚至上万个文件，一个功能又可能跨越数据层、业务层和 UI 层。

把整个代码库一次性塞给模型，不仅成本高，也容易让模型被大量无关代码干扰。

### 产品语言和代码语言不一致

产品写的是：

> 邮件列表顶部增加一个红色提示条。

代码中可能根本没有“红色提示条”这个词，而是：

```text
TipsView
WarningBanner
showNotice
didTapTipsView
```

直接搜索需求原文，往往得不到有效结果。

### AI容易跳过分析直接修改

用户说一句“按照需求改一下”，AI 可能还没有确认需求边界，就开始修改代码。

结果通常不是不会写，而是：

* 漏掉需求点；
* 改错文件；
* 扩大修改范围；
* 发明项目中不存在的新写法。

### 完成状态缺少证据

AI 很容易输出“已经完成”，但实际情况可能是：

* 代码没有编译；
* 页面没有运行；
* UI 与设计稿不一致；
* 点击路径根本走不通；
* 改动影响了其他功能。

因此，企业需要解决的不是“怎样让 AI 多写代码”，而是：

> 怎样让 AI 按照项目已有的工程规范完成需求，并用可检查的结果证明自己做完了。

---

## 二、一个Skill到底包含什么

很多人提到 Skill，会把它理解成一份更长、更复杂的提示词。

但在这个案例中，Skill 更像是一套面向 Agent 的工程作业系统。

它至少包含四部分：

```text
流程编排
+ 项目知识
+ 自动化工具
+ 质量规则
```

需求开发被拆成多个有先后顺序的阶段：

| 阶段   | 主要任务          | 关键产物   |
| ---- | ------------- | ------ |
| 物料收集 | 获取需求、设计稿和接口文档 | 本地需求材料 |
| 需求拆解 | 明确需求点及依赖关系    | 子任务清单  |
| 代码定位 | 找到文件、方法和调用链   | 改动位置说明 |
| 编码实现 | 按项目模式修改代码     | 源码差异   |
| 编译验证 | 执行真实构建        | 编译报告   |
| 运行验证 | 安装、操作、截图和检查日志 | 验证证据   |
| 知识沉淀 | 记录边界、决策和演进过程  | 技术说明文档 |
| 提交收尾 | 生成提交信息并等待确认   | 代码提交   |

```mermaid
flowchart LR
    A[需求与设计稿] --> B[结构化拆解]
    B --> C[代码定位]
    C --> D[编码实现]
    D --> E[编译验证]
    E --> F[运行时验证]
    F --> G[知识沉淀]
    G --> H[人工确认与提交]

    E -- 失败 --> D
    F -- 功能问题 --> D
    F -- 验证路径问题 --> F
```

真正重要的不是分成了几个阶段，而是每个阶段都有明确的进入条件和退出标准。

例如：

* 没有完成需求拆解，不能开始改代码；
* 没有确认调用链，不能直接实现；
* 编译退出码不为 0，不能进入运行验证；
* UI 对齐未完成，不能标记通过；
* 没有人工确认，不能执行最终提交。

这使 AI 从“自由回答问题”，变成了“按照工程流程执行任务”。

---

## 三、如何在大型代码库中找到改动点

处理大型代码库时，单纯增加上下文并不是最稳妥的方法。

更有效的思路是不断缩小范围。

### 第一步：先消除需求歧义

用户说“修改邮件入口”，可能指：

* 邮件列表中的某个入口；
* 首页的邮件 Tab；
* 邮件详情页按钮；
* 推送消息中的跳转入口。

AI 首先要结合需求材料确认目标，而不是立即搜索或修改代码。

### 第二步：通过项目地图定位模块

项目需要提前建立一份 AI 可以理解的结构化知识库。

第一层是项目总览：

c

第二层继续记录模块中的主要文件：

| 文件                 | 职责          |
| ------------------ | ----------- |
| MailListController | 管理列表展示和交互   |
| MailListViewModel  | 管理数据加载和状态计算 |
| TipsView           | 展示列表顶部提示信息  |

AI 先看地图，再进入源码，能够显著减少无效搜索。

### 第三步：让搜索工具处理确定性工作

确定模块后，通过 `rg`、`grep` 等工具搜索：

* 类名；
* 接口字段；
* 枚举；
* 方法名；
* 回调；
* 日志关键字。

模型负责扩展搜索思路和分析结果，工具负责精确执行。

这里需要修正一种常见说法：

> 不是简单地“把判断交给模型，把数据交给脚本”，而是把模糊语义理解交给模型，把确定性搜索、计算、执行和校验交给工具。

涉及业务边界、架构修改和发布风险的判断，仍然需要人工参与。

### 第四步：追踪完整调用链

找到候选文件后，再确认数据和事件是如何流动的：

```text
接口字段
  ↓
数据解析
  ↓
状态计算
  ↓
ViewModel
  ↓
页面组件
  ↓
用户交互
```

只有确认完整链路后，才能决定改动哪些文件，以及哪些模块不能动。

---

## 四、怎样把产品语言翻译成代码任务

开发中最依赖经验的环节，往往不是写代码，而是把产品描述翻译成技术任务。

例如：

> 邮件列表顶部增加一个提示条，点击后进入管理页面。

开发人员需要继续确认：

* 哪种状态下展示；
* 由哪个接口字段控制；
* 提示文案从哪里获取；
* 点击后跳转哪个页面；
* 是否影响 Tab 角标；
* 是否需要埋点；
* 对应哪张设计稿。

Skill 会先把需求转换成结构化子任务。

| 编号 | 需求项          | 类型    | 数据来源   | 设计节点     |
| -- | ------------ | ----- | ------ | -------- |
| M1 | 列表顶部显示提示条    | 新增 UI | 接口字段 A | Node-101 |
| M2 | Tab 角标显示警告状态 | 修改逻辑  | 本地状态 B | Node-102 |
| M3 | 点击提示条进入管理页   | 新增交互  | PRD 原文 | Node-103 |

同时生成机器可读的任务台账：

```json
[
  {
    "id": "M1",
    "title": "列表顶部显示提示条",
    "type": "新增UI",
    "data_source": "接口字段A",
    "depends_on": []
  },
  {
    "id": "M2",
    "title": "Tab角标显示警告状态",
    "type": "修改逻辑",
    "data_source": "本地状态B",
    "depends_on": ["M1"]
  }
]
```

这份结构化清单既能指导开发，也能直接成为测试分析的输入。

测试人员可以据此扩展：

* 字段正常返回；
* 字段缺失或异常；
* 多个状态同时出现；
* 页面首次加载与刷新；
* 点击跳转及返回；
* 新旧版本兼容；
* 日志和埋点是否正确。

需求拆解一旦结构化，开发任务、测试点和回归范围就可以围绕同一份数据展开。

---

## 五、联想用于搜索，证据用于决策

AI 需要联想能力，否则很难跨越产品语言和代码命名之间的差异。

产品说“红色提示条”，代码中可能出现：

```text
tips
banner
warning
notice
alert
```

在搜索阶段，AI 可以根据业务语义、项目命名习惯和知识库扩展候选关键词。

但在实现阶段，任何修改都必须有明确依据：

* PRD 原文；
* 设计稿标注；
* 接口协议；
* 用户确认；
* 已评审的技术方案。

产品只要求修改一个入口，AI 不能因为“保持一致性”，自行修改其他相似入口。

这条原则可以概括为：

> 联想用于寻找代码，证据用于决定改什么。

原文通过关键词表、设计稿归属检查和交互依据清单，降低了 AI 漏需求和越界修改的概率。但需要注意，这类规则只能降低风险，不能把复杂需求中的范围误判彻底降为零。([AI星球][1])

---

## 六、为什么验证必须成为流程的一部分

这套实践最值得测试人员关注的地方，是它没有把验证放在代码生成之后，而是直接嵌入 Skill。

## 1. 编译验证

代码修改完成后必须执行真实构建。

判断标准不是 AI 认为代码正确，而是编译退出码为 0。

编译错误被分成两类。

### AI可以尝试修复

* 语法错误；
* 类型不匹配；
* 缺少导入；
* 枚举分支遗漏；
* 标识符不存在。

这类问题允许 AI 自动修复，但必须限制重试次数，防止错误范围不断扩大。

### 必须人工介入

* 构建配置异常；
* 第三方依赖问题；
* 链接失败；
* 错误超出本次改动范围；
* 涉及公共组件或架构调整。

此时 Agent 应停止执行并报告，而不是继续试错。

## 2. 运行时验证

编译通过只能证明代码能够构建，不能证明功能正确。

Skill 会根据需求、设计稿和 `git diff`，生成一条具体验证路径：

```markdown
1. 启动应用
2. 进入目标模块
3. 打开指定页面
4. 构造目标业务状态
5. 检查提示条是否出现
6. 核对提示文案
7. 点击提示条
8. 检查目标页面
9. 核对运行日志
```

每一步都要形成可检查的证据：

* 页面截图；
* 运行日志；
* 接口返回；
* 自动化执行结果；
* 状态字段。

## 3. 视觉对齐

涉及 UI 的需求，还要检查：

* 字体；
* 颜色；
* 控件尺寸；
* 间距；
* 对齐方式；
* 深色模式；
* 不同设备尺寸。

只要存在未确认的关键差异，任务就不能标记为通过。

## 4. 失败分类

运行验证失败后，不能一律重新执行。

需要先判断失败属于哪一类：

| 类型      | 示例              | 处理方式   |
| ------- | --------------- | ------ |
| 代码问题    | 页面未展示、字段错误、发生崩溃 | 返回实现阶段 |
| 验证路径问题  | 被登录页拦截、账号无数据    | 修改验证方案 |
| 脚本或时序问题 | 页面未加载完成、点击坐标错误  | 有限次数重试 |

失败分类可以防止 Agent 在错误路径上反复尝试。

不过，自动编译、模拟器操作和截图比对只能作为开发阶段的自验证，不能等同于完整测试。复杂业务场景、跨端兼容、异常链路、性能、安全和真实用户环境，仍然需要专业测试体系覆盖。

---

## 七、红线与人工关卡如何控制风险

仅在提示词中写“不要越界”“确保编译通过”，属于软约束。

更稳定的方法，是把高风险行为变成不可绕过的规则。

例如：

* 未完成需求拆解，禁止修改源码；
* 未读取现有实现，禁止创建新的设计模式；
* UI 改动禁止硬编码字体和颜色；
* 编译连续失败达到上限，必须停止；
* 运行验证未通过，不能进入提交阶段；
* 没有人工确认，不能执行代码提交。

触发规则后，Agent 必须停止并输出结构化报告：

```text
触发规则：编译连续失败

当前情况：
第三次编译仍然存在链接错误。
错误位于公共依赖模块，不属于本次需求改动范围。

处理建议：
停止自动修复，由开发人员检查构建配置和依赖版本。
```

原文还提出了一个很有价值的细节：长时间命令不能只根据终端输出判断是否成功，而要通过退出码、文件、日志或 Git 状态形成确定性证据。例如，以编译报告、截图、运行日志和最新 commit hash 作为任务完成依据。([AI星球][1])

这类机制解决的不是“让 AI 永远不出错”，而是：

* 尽早暴露错误；
* 控制错误范围；
* 保留执行证据；
* 支持失败回退；
* 把不可逆操作留给人确认。

---

## 八、跨会话接力不能只靠聊天记录

真实需求很少在一次会话中结束。

开发过程中可能出现：

* 产品需求调整；
* 设计稿变化；
* 接口字段修改；
* 测试发现缺陷；
* 代码评审提出重构；
* 需求进入下一轮迭代。

如果信息只存在聊天记录中，重新开启会话后，历史决策很容易丢失。

这套实践将关键过程沉淀为三类文件：

| 文件     | 作用                 |
| ------ | ------------------ |
| 技术说明文档 | 记录功能边界、模块、调用链和设计决策 |
| 子任务台账  | 记录需求状态、依赖关系和关联提交   |
| 执行时间线  | 记录人工修正、验证结果和提交事件   |

新的 Agent 会话进入项目后，先读取这些文件，就能快速恢复：

* 当前做到哪一步；
* 哪些任务已经完成；
* 哪些方案被否决；
* 修改过哪些文件；
* 哪些边界不能突破；
* 后续还需要完成什么验证。

这种持久化知识不依赖某个模型，即使更换 AI 工具，对开发人员和新员工也同样有价值。

---

## 九、94%代码生成率应该如何理解

“AI 代码生成率达到 94%”很容易被理解为：

> AI 已经完成了94%的研发工作。

这种理解并不准确。

代码生成比例不等于需求交付比例，也不等于效率提升比例，更不能直接说明代码质量。

完整的软件交付还包括：

* 需求理解；
* 技术方案；
* 风险判断；
* 代码评审；
* 测试设计；
* 缺陷处理；
* 发布决策；
* 线上观测。

原文也说明，相关效率数据主要来自项目半年实践中的经验统计，并非严格控制变量的 Benchmark。例如，需求拆解从一两个小时缩短到数分钟、代码定位从几十分钟缩短到数分钟，都更适合作为项目经验参考，而不是行业通用结论。([AI星球][1])

因此，团队真正应该关注的指标不只是代码生成率，还包括：

| 指标      | 说明              |
| ------- | --------------- |
| 生成代码采纳率 | AI 生成代码最终保留了多少  |
| 首次编译通过率 | 第一次生成后能否直接构建    |
| 自动修复成功率 | 常见错误能否在限定次数内修复  |
| 人工介入次数  | 每个需求需要多少次人工决策   |
| 需求遗漏率   | 是否存在未实现的需求点     |
| 越界修改率   | 是否修改了需求范围之外的代码  |
| 回归缺陷率   | AI 改动是否引入历史功能问题 |
| 验证假通过率  | 自动化报告是否与真实结果一致  |

只有把这些指标放在一起，才能判断 AI 是否真正提高了工程效率。

---

## 十、软件测试团队可以借鉴什么

这类开发 Skill 并不会削弱测试的价值，反而会推动测试更早进入研发流程。

### 1. 从执行用例转向设计质量流程

测试人员需要参与定义：

* 需求如何拆解；
* 每个阶段需要哪些质量产物；
* 什么条件下允许进入下一阶段；
* 哪些异常必须立即停止；
* 哪些操作必须人工确认；
* 什么证据才能证明任务完成。

### 2. 把测试经验变成Agent可调用的知识

很多测试经验仍然散落在个人经验、Excel、聊天记录、缺陷平台和自动化脚本中。

未来需要逐步沉淀为：

* 业务风险库；
* 历史缺陷模式；
* 接口字段约束；
* 状态转换规则；
* 测试数据构造方法；
* 环境限制；
* 回归范围映射；
* 发布门禁标准。

### 3. 把自动化脚本升级为标准工具

未来的自动化测试不只是定时运行脚本，还要将能力封装成 Agent 可以稳定调用的工具：

```text
需求分析工具
测试点生成工具
测试数据构造工具
接口验证工具
UI执行工具
日志分析工具
视觉对比工具
变更影响分析工具
发布门禁工具
```

每个工具都应该具备：

* 输入明确；
* 输出结构化；
* 执行可重复；
* 结果可验证；
* 失败原因清晰；
* 权限边界明确。

### 4. 把Agent执行过程纳入测试范围

当 AI 开始参与编码，测试对象不再只有业务系统。

测试团队还需要关注：

* Agent 是否理解错需求；
* 是否修改了无关代码；
* 是否绕过阶段关卡；
* 是否使用不存在的接口；
* 是否遗漏异常路径；
* 是否出现自动化假通过；
* 是否在失败后继续执行高风险操作；
* 不同模型执行同一 Skill 的结果是否一致。

未来的软件质量，将同时包含产品结果质量和 Agent 执行过程质量。

---

## 写在最后

这个案例表面上是在讨论“如何让 AI 生成更多代码”，本质上是在重新设计需求交付流程。

它把原本存在于资深工程师脑中的经验，逐步转化成：

* 项目知识库；
* 需求拆解规则；
* 自动化脚本；
* 代码规范；
* 质量红线；
* 验证证据；
* 人工决策节点；
* 跨会话技术文档。

当这些能力没有建立起来时，AI 只是一个速度更快的代码生成工具。

当需求、知识、工具和质量门禁都被显式化后，AI 才可能从“辅助写代码”进一步走向“参与需求交付”。

对软件测试团队来说，更值得研究的也不是 AI 能生成多少行代码，而是如何把质量经验沉淀成一套 Agent 能理解、能执行、能验证，同时不能随意绕过的工程机制。

---

 /**本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。**/ 


补全方法、生成接口、修改页面、编写单元测试，主流编程模型都能完成。真正难的是把 AI 放进一个拥有数千个文件、多人协作多年、需求材料分散的真实项目后，它还能不能把一个需求完整交付。

从代码生成到需求交付：一个开发 Skill 的工程化实践

人工智能

开发工具

后端

腾讯技术团队分享AI编程实践，在大型项目中实现94%代码生成率。通过结构化流程将需求拆解、代码定位、验证等环节串联，确保AI按工程规范交付。关键是将研发经验转化为规则、知识和质量门禁，使AI从代码生成工具升级为需求交付参与者。测试团队可借鉴其质量流程设计思路，将测试经验转化为AI可执行的质量机制。

代码生成工具

AI代码生成

日志分析

软件测试

单元测试

代码解释

AI编程

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从代码生成到需求交付：一个开发 Skill 的工程化实践-腾讯云开发者社区-腾讯云

从代码生成到需求交付：一个开发 Skill 的工程化实践

从代码生成到需求交付：一个开发 Skill 的工程化实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐