AI 写代码已经不难了。补全方法、生成接口、修改页面、编写单元测试主流编程模型都能完成。真正难的是把 AI 放进一个拥有数千个文件、多人协作多年、需求材料分散的真实项目后它还能不能把一个需求完整交付。最近腾讯技术团队分享了一套移动端需求开发 Skill。它将需求收集、设计稿分析、任务拆解、代码定位、编码、编译、模拟器验证、技术沉淀和代码提交串成了一条完整流程。按照项目团队的统计口径AI 代码生成率达到了约 94%。但相比这个数字更值得关注的是它背后的工程方法AI 编程的上限不只取决于模型能力更取决于团队能否把研发经验变成规则、知识、工具和质量门禁。目录AI 写业务代码为什么总差一步一个 Skill 到底包含什么如何在大型代码库中找到改动点怎样把产品语言翻译成代码任务为什么验证必须成为流程的一部分红线与人工关卡如何控制风险94%代码生成率应该如何理解软件测试团队可以借鉴什么一、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 可以理解的结构化知识库。第一层是项目总览模块职责邮件列表邮件展示、同步、过滤和多选邮件详情正文渲染、附件预览和内容处理邮件撰写富文本编辑和附件上传数据模型数据解析、持久化和状态管理第二层继续记录模块中的主要文件文件职责MailListController管理列表展示和交互MailListViewModel管理数据加载和状态计算TipsView展示列表顶部提示信息AI 先看地图再进入源码能够显著减少无效搜索。第三步让搜索工具处理确定性工作确定模块后通过rg、grep等工具搜索类名接口字段枚举方法名回调日志关键字。模型负责扩展搜索思路和分析结果工具负责精确执行。这里需要修正一种常见说法不是简单地“把判断交给模型把数据交给脚本”而是把模糊语义理解交给模型把确定性搜索、计算、执行和校验交给工具。涉及业务边界、架构修改和发布风险的判断仍然需要人工参与。第四步追踪完整调用链找到候选文件后再确认数据和事件是如何流动的接口字段 ↓ 数据解析 ↓ 状态计算 ↓ ViewModel ↓ 页面组件 ↓ 用户交互只有确认完整链路后才能决定改动哪些文件以及哪些模块不能动。四、怎样把产品语言翻译成代码任务开发中最依赖经验的环节往往不是写代码而是把产品描述翻译成技术任务。例如邮件列表顶部增加一个提示条点击后进入管理页面。开发人员需要继续确认哪种状态下展示由哪个接口字段控制提示文案从哪里获取点击后跳转哪个页面是否影响 Tab 角标是否需要埋点对应哪张设计稿。Skill 会先把需求转换成结构化子任务。编号需求项类型数据来源设计节点M1列表顶部显示提示条新增 UI接口字段 ANode-101M2Tab 角标显示警告状态修改逻辑本地状态 BNode-102M3点击提示条进入管理页新增交互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 漏需求和越界修改的概率。但需要注意这类规则只能降低风险不能把复杂需求中的范围误判彻底降为零。([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 生成代码最终保留了多少首次编译通过率第一次生成后能否直接构建自动修复成功率常见错误能否在限定次数内修复人工介入次数每个需求需要多少次人工决策需求遗漏率是否存在未实现的需求点越界修改率是否修改了需求范围之外的代码回归缺陷率AI 改动是否引入历史功能问题验证假通过率自动化报告是否与真实结果一致只有把这些指标放在一起才能判断 AI 是否真正提高了工程效率。十、软件测试团队可以借鉴什么这类开发 Skill 并不会削弱测试的价值反而会推动测试更早进入研发流程。1. 从执行用例转向设计质量流程测试人员需要参与定义需求如何拆解每个阶段需要哪些质量产物什么条件下允许进入下一阶段哪些异常必须立即停止哪些操作必须人工确认什么证据才能证明任务完成。2. 把测试经验变成Agent可调用的知识很多测试经验仍然散落在个人经验、Excel、聊天记录、缺陷平台和自动化脚本中。未来需要逐步沉淀为业务风险库历史缺陷模式接口字段约束状态转换规则测试数据构造方法环境限制回归范围映射发布门禁标准。3. 把自动化脚本升级为标准工具未来的自动化测试不只是定时运行脚本还要将能力封装成 Agent 可以稳定调用的工具需求分析工具 测试点生成工具 测试数据构造工具 接口验证工具 UI执行工具 日志分析工具 视觉对比工具 变更影响分析工具 发布门禁工具每个工具都应该具备输入明确输出结构化执行可重复结果可验证失败原因清晰权限边界明确。4. 把Agent执行过程纳入测试范围当 AI 开始参与编码测试对象不再只有业务系统。测试团队还需要关注Agent 是否理解错需求是否修改了无关代码是否绕过阶段关卡是否使用不存在的接口是否遗漏异常路径是否出现自动化假通过是否在失败后继续执行高风险操作不同模型执行同一 Skill 的结果是否一致。未来的软件质量将同时包含产品结果质量和 Agent 执行过程质量。写在最后这个案例表面上是在讨论“如何让 AI 生成更多代码”本质上是在重新设计需求交付流程。它把原本存在于资深工程师脑中的经验逐步转化成项目知识库需求拆解规则自动化脚本代码规范质量红线验证证据人工决策节点跨会话技术文档。当这些能力没有建立起来时AI 只是一个速度更快的代码生成工具。当需求、知识、工具和质量门禁都被显式化后AI 才可能从“辅助写代码”进一步走向“参与需求交付”。对软件测试团队来说更值得研究的也不是 AI 能生成多少行代码而是如何把质量经验沉淀成一套 Agent 能理解、能执行、能验证同时不能随意绕过的工程机制。