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

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

例如：

• 没有完成需求拆解，不能开始改代码；
• 没有确认调用链，不能直接实现；
• 编译退出码不为 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 能理解、能执行、能验证，同时不能随意绕过的工程机制。

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