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

AI 写代码这件事，现在已经不算什么新鲜事了。

代码补全、接口生成、页面修改、单元测试编写——这些活儿，主流编程模型基本都能干得不错。但真正的难点在于：当AI被扔进一个拥有上千个文件、多人协作多年、需求文档散落在各个角落的真实项目里，它还能不能把一个需求从头到尾完整交付？

最近，腾讯技术团队分享了一套面向移动端需求开发的 Skill。这套方案把需求收集、设计稿分析、任务拆解、代码定位、编码实现、编译验证、模拟器操作、技术沉淀，直到最后的代码提交，全都串成了一条完整的作业流水线。

按照项目团队的统计口径，AI 的代码生成率达到了大约 94%。不过，相比于这个数字，更值得深挖的其实是它背后那套工程方法：AI 编程的上限，绝不仅仅取决于模型的能力，更关键的是，团队有没有本事把研发经验沉淀成规则、知识、工具和质量门禁。

目录

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

一、AI 写业务代码，为什么总是差那么一步

在演示项目里，AI 编程通常表现得非常顺畅。

用户给一个清晰明确的任务，模型生成代码，运行一下，结果就出来了。但企业项目里的需求，很少能用一句话说清楚。

一个看似简单的页面改动，背后可能牵扯到：

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

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

这时候，几个核心问题就会集中暴露出来。

先说上下文这个老大难问题

一个项目可能包含几千甚至上万个文件，而一个功能需求又可能横跨数据层、业务层和 UI 层。把整个代码库一股脑全塞给模型，不仅成本高得离谱，还容易让模型被大量无关代码干扰判断。

产品语言和代码语言之间，隔着一条鸿沟

产品经理写的是：“在列表顶部加一个红色提示条”。

而代码里，可能根本找不到“红色提示条”这个词，取而代之的是：

TipsViewWarningBannerShowNoticeDidTapTipsView

直接拿需求原文去搜索，往往什么都搜不到。

AI 容易跳过分析，直接上手修改

用户说一句“按需求改一下”，AI 可能还没搞清楚需求边界在哪里，就开始噼里啪啦改代码了。结果通常不是不会写，而是：

• 漏掉了需求点；
• 改错了文件；
• 扩大了修改范围；
• 发明了项目里根本不存在的写法。

完成状态，缺少证据链

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

• 代码根本编译不过；
• 页面压根跑不起来；
• UI 跟设计稿对不上；
• 点击路径走不通；
• 改动影响到了其他功能。

所以说，企业真正需要解决的问题，不是“怎样让 AI 多写几行代码”，而是：

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

很多人一提到 Skill，就以为它是一份更长、更复杂的提示词。

但在这次案例中，Skill 更像是一套面向 Agent 的工程作业系统。它至少包含四个部分：

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

整个需求开发流程被拆解成多个有先后顺序的阶段。这里直接看一张表，比较清晰：

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

flowchart LRA[需求与设计稿] --> B[结构化拆解]B --> C[代码定位]C --> D[编码实现]D --> E[编译验证]E --> F[运行时验证]F --> G[知识沉淀]G --> H[人工确认与提交]E -- 失败 --> DF -- 功能问题 --> DF -- 验证路径问题 --> F

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

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

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

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

处理大型代码库时，单纯地增加上下文，并不是最稳妥的办法。更有效的思路，是不断缩小搜索范围。

第一步：先消除需求歧义

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

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

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

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

项目需要提前建好一份 AI 能理解的结构化知识库。第一层是项目总览，第二层继续记录模块中的主要文件：

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

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

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

确定模块后，通过 rg、grep 这类工具搜索：类名、接口字段、枚举、方法名、回调、日志关键字。模型负责扩展搜索思路和分析结果，工具负责精确执行。这里需要修正一个常见说法：涉及业务边界、架构修改和发布风险的判断，仍然需要人工参与。

第四步：追踪完整调用链

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

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

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

四、怎样把产品语言翻译成可执行的代码任务

开发中最依赖经验的环节，往往不是写代码，而是把产品描述翻译成技术任务。举个例子，产品说“在列表顶部加一个提示条”，开发人员需要继续确认：

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

Skill 会先把需求转换成一张结构化的子任务表：

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

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

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

这份结构化清单，既能指导开发，也能直接成为测试分析的输入。测试人员可以据此扩展测试点，比如：字段正常返回、字段缺失或异常、多个状态同时出现、页面首次加载与刷新、点击跳转及返回、新旧版本兼容、日志和埋点是否正确。需求拆解一旦结构化，开发任务、测试点和回归范围就可以围绕同一份数据展开。

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

AI 需要联想能力，否则很难跨越产品语言和代码命名之间的差异。产品说“红色提示条”，代码中可能出现：tips、banner、warning、notice、alert。在搜索阶段，AI 可以根据业务语义、项目命名习惯和知识库来扩展候选关键词。

但在实现阶段，任何修改都必须有明确依据：PRD 原文、设计稿标注、接口协议、用户确认、已评审的技术方案。产品只要求修改一个入口，AI 不能因为“保持一致性”，就自行去修改其他相似入口。这条原则可以概括为：联想用于搜索，证据用于决策。

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

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

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

1. 编译验证

代码修改完成后，必须执行一次真实的构建。判断标准不是 AI 认为代码正确，而是编译退出码是否为 0。编译错误被分成两类：

语法错误、类型不匹配、缺少导入、枚举分支遗漏、标识符不存在。这类问题允许 AI 自动修复，但必须限制重试次数，防止错误范围不断扩大。

构建配置异常、第三方依赖问题、链接失败、错误超出本次改动范围、涉及公共组件或架构调整。此时 Agent 应停止执行并报告，而不是继续试错。

2. 运行时验证

编译通过只能证明代码能够构建，不能证明功能正确。Skill 会根据需求、设计稿和 git diff，生成一条具体的验证路径，比如：

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

每一步都要形成可检查的证据：页面截图、运行日志、接口返回、自动化执行结果、状态字段。

3. 视觉对齐

涉及 UI 的需求，还要检查：字体、颜色、控件尺寸、间距、对齐方式、深色模式、不同设备尺寸。只要存在未确认的关键差异，任务就不能标记为通过。

4. 失败分类

运行验证失败后，不能一律重新执行。需要先判断失败属于哪一类：

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

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

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

仅在提示词里写“不要越界”“确保编译通过”，属于软约束，不太靠谱。更稳定的方法，是把高风险行为变成不可绕过的规则。例如：

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

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

触发规则：编译连续失败。当前情况：第三次编译仍然存在链接错误。错误位于公共依赖模块，不属于本次需求改动范围。处理建议：停止自动修复，由开发人员检查构建配置和依赖版本。

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

这类机制解决的不是“让 AI 永远不出错”，而是：尽早暴露错误、控制错误范围、保留执行证据、支持失败回退、把不可逆操作留给人确认。

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

真实需求很少在一次会话中就能结束。开发过程中可能出现：产品需求调整、设计稿变化、接口字段修改、测试发现缺陷、代码评审提出重构、需求进入下一轮迭代。如果信息只存在于聊天记录里，重新开启会话后，历史决策很容易丢失。

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

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

新的 Agent 会话进入项目后，先读取这些文件，就能快速恢复：当前做到哪一步、哪些任务已经完成、哪些方案被否决、修改过哪些文件、哪些边界不能突破、后续还需要完成什么验证。这种持久化知识不依赖某个模型，即使更换 AI 工具，对开发人员和新员工也同样有价值。

九、94% 的代码生成率，到底该怎么理解

“AI 代码生成率达到 94%”很容易被理解为：100 行代码里，有 94 行是 AI 写的。这种理解并不准确。代码生成比例不等于需求交付比例，也不等于效率提升比例，更不能直接说明代码质量。

完整的软件交付还包括：需求理解、技术方案、风险判断、代码评审、测试设计、缺陷处理、发布决策、线上观测。原文也说明了，相关效率数据主要来自项目半年实践中的经验统计，并非严格控制变量的 Benchmark。例如，需求拆解从一两个小时缩短到数分钟、代码定位从几十分钟缩短到数分钟，这些更适合作为项目经验参考，而不是行业通用结论。

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

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

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

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

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

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

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

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

很多测试经验仍然散落在个人经验、Excel 表格、聊天记录、缺陷平台和自动化脚本里。未来需要逐步沉淀为：业务风险库、历史缺陷模式、接口字段约束、状态转换规则、测试数据构造方法、环境限制、回归范围映射、发布门禁标准。

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

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

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

每个工具都应该具备：输入明确、输出结构化、执行可重复、结果可验证、失败原因清晰、权限边界明确。

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

当 AI 开始参与编码，测试对象就不再只有业务系统了。测试团队还需要关注：Agent 是否理解错需求、是否修改了无关代码、是否绕过阶段关卡、是否使用不存在的接口、是否遗漏异常路径、是否出现自动化假通过、是否在失败后继续执行高风险操作、不同模型执行同一 Skill 的结果是否一致。

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

写在最后

这个案例，表面上是在讨论“如何让 AI 生成更多代码”，本质上，是在重新设计需求交付的流程。它把原本存在于资深工程师脑中的经验，逐步转化成：项目知识库、需求拆解规则、自动化脚本、代码规范、质量红线、验证证据、人工决策节点、跨会话技术文档。

当这些能力没有建立起来时，AI 只是一个速度更快的代码生成工具。只有当需求、知识、工具和质量门禁都被显式化后，AI 才可能从“辅助写代码”进一步走向“参与需求交付”。

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