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

AI 写代码已经不难了。

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

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

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

目录

1. AI 写业务代码为什么总差一步

2. 一个 Skill 到底包含什么

3. 如何在大型代码库中找到改动点

4. 怎样把产品语言翻译成代码任务

5. 为什么验证必须成为流程的一部分

6. 红线与人工关卡如何控制风险

7. 94%代码生成率应该如何理解

8. 软件测试团队可以借鉴什么

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

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

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

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

• 产品需求和补充说明；

• Figma 设计稿；

• 接口字段和数据模型；

• 历史业务逻辑；

• 页面组件和点击事件；

• 日志、埋点与兼容处理；

• 构建系统和自动化测试。

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

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

上下文装不下

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

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

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

产品写的是：

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

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

TipsView WarningBanner showNotice didTapTipsView

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

AI容易跳过分析直接修改

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

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

• 漏掉需求点；

• 改错文件；

• 扩大修改范围；

• 发明项目中不存在的新写法。

完成状态缺少证据

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

• 代码没有编译；

• 页面没有运行；

• UI 与设计稿不一致；

• 点击路径根本走不通；

• 改动影响了其他功能。

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

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

二、一个Skill到底包含什么

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

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

它至少包含四部分：

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

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

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

例如：

• 没有完成需求拆解，不能开始改代码；

• 没有确认调用链，不能直接实现；

• 编译退出码不为 0，不能进入运行验证；

• UI 对齐未完成，不能标记通过；

• 没有人工确认，不能执行最终提交。

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

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

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

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

第一步：先消除需求歧义

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

• 邮件列表中的某个入口；

• 首页的邮件 Tab；

• 邮件详情页按钮；

• 推送消息中的跳转入口。

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

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

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

第一层是项目总览：

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

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

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

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

• 类名；

• 接口字段；

• 枚举；

• 方法名；

• 回调；

• 日志关键字。

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

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

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

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

第四步：追踪完整调用链

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

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

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

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

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

例如：

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

开发人员需要继续确认：

• 哪种状态下展示；

• 由哪个接口字段控制；

• 提示文案从哪里获取；

• 点击后跳转哪个页面；

• 是否影响 Tab 角标；

• 是否需要埋点；

• 对应哪张设计稿。

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

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

[ { "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 漏需求和越界修改的概率。但需要注意，这类规则只能降低风险，不能把复杂需求中的范围误判彻底降为零。([AI星球][1])

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

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

1. 编译验证

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

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

编译错误被分成两类。

AI可以尝试修复

• 语法错误；

• 类型不匹配；

• 缺少导入；

• 枚举分支遗漏；

• 标识符不存在。

这类问题允许 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星球][1])

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

• 尽早暴露错误；

• 控制错误范围；

• 保留执行证据；

• 支持失败回退；

• 把不可逆操作留给人确认。

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

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

开发过程中可能出现：

• 产品需求调整；

• 设计稿变化；

• 接口字段修改；

• 测试发现缺陷；

• 代码评审提出重构；

• 需求进入下一轮迭代。

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

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

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

• 当前做到哪一步；

• 哪些任务已经完成；

• 哪些方案被否决；

• 修改过哪些文件；

• 哪些边界不能突破；

• 后续还需要完成什么验证。

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

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

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

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

这种理解并不准确。

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

完整的软件交付还包括：

• 需求理解；

• 技术方案；

• 风险判断；

• 代码评审；

• 测试设计；

• 缺陷处理；

• 发布决策；

• 线上观测。

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

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

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

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

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

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

测试人员需要参与定义：

• 需求如何拆解；

• 每个阶段需要哪些质量产物；

• 什么条件下允许进入下一阶段；

• 哪些异常必须立即停止；

• 哪些操作必须人工确认；

• 什么证据才能证明任务完成。

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

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

未来需要逐步沉淀为：

• 业务风险库；

• 历史缺陷模式；

• 接口字段约束；

• 状态转换规则；

• 测试数据构造方法；

• 环境限制；

• 回归范围映射；

• 发布门禁标准。

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

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

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

每个工具都应该具备：

• 输入明确；

• 输出结构化；

• 执行可重复；

• 结果可验证；

• 失败原因清晰；

• 权限边界明确。

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

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

测试团队还需要关注：

• Agent 是否理解错需求；

• 是否修改了无关代码；

• 是否绕过阶段关卡；

• 是否使用不存在的接口；

• 是否遗漏异常路径；

• 是否出现自动化假通过；

• 是否在失败后继续执行高风险操作；

• 不同模型执行同一 Skill 的结果是否一致。

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

写在最后

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

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

• 项目知识库；

• 需求拆解规则；

• 自动化脚本；

• 代码规范；

• 质量红线；

• 验证证据；

• 人工决策节点；

• 跨会话技术文档。

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

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

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