摘要：AI 能否真正参与需求开发，取决于它是否理解需求、能否在既有流程中执行任务，以及能否接受人工评审和测试反馈。本文以 ONES 研发团队的 AI 员工实践为案例，拆解 AI 参与小需求开发的完整路径：从原始需求、PRD、技术方案、编码与测试，到工作项、工作流、Agent、Skills 和工作区如何共同支撑人机协作。

本文涉及的工具与能力：ONES AI 员工、AI Agent、AI 需求开发、工作项管理、工作流、PRD、技术方案、代码评审、测试方案、API 测试、UI 验证。

一、什么样的小需求适合优先交给 AI？

很多团队在讨论“AI 能不能开发需求”时，容易把问题理解为：模型能不能把自然语言转成代码。实际上，企业研发中更难的部分往往不在代码本身，而在于需求是否被准确理解、方案是否符合已有系统约束、测试是否覆盖真实业务，以及过程是否能被团队审核和追溯。

因此，AI 并不适合一开始就承接所有需求。更适合作为试点的，是传统人工研发周期约为 1—2 周、目标相对明确、可拆分为标准流程节点的小需求。

这类需求通常具有几个共同特征：

• 有较清晰的原始需求、业务背景或接口描述；
• 影响范围相对可控，不需要跨多个团队做长期协调；
• 可以拆成需求分析、方案设计、编码、测试等阶段；
• 能够从现有代码、日志、工作项和文档中获得必要上下文；
• 有明确的验收标准，且关键结果可以由产品、研发或测试人员复核。

例如，一个已有业务流程中的 OpenAPI 支持需求，原始描述可能并不长，但仍涉及业务规则、接口定义、权限判断、异常处理和页面或接口验证。这类需求不适合让 AI 直接“写完代码就上线”，却很适合让 AI 先做需求澄清、方案初稿、测试用例和部分编码工作，再由人完成关键判断。

反过来，业务边界模糊、涉及核心架构改造、依赖多个系统重构、需要长周期产品决策的复杂需求，仍应该以人工主导。AI 可以参与资料梳理、代码检索或子任务执行，但不能被当作独立的项目负责人。

所以，可以得出的结论是：AI 可以开发小需求，但不应独立完成整个需求。真正可持续的做法，是将需求开发拆解为一系列可理解、可评审、可验证的节点，让 AI 承担执行性工作，让人承担业务、技术和风险判断。

二、AI 如何完成从需求分析到测试验收？

小需求开发不应是一条“输入需求—输出代码”的黑盒链路。对企业而言，更可靠的流程是：先让 AI 证明它理解需求，再让它提出方案、执行编码和测试；每个关键阶段都设置人工反馈入口。

1. 从原始需求到 PRD：先确认 AI 是否理解“要做什么”

产品经理给出的原始需求，通常只描述目标和部分背景，未必包含完整的业务规则、边界条件和验收标准。人类研发人员会在沟通中追问、补充和澄清，AI 也需要经过这一层处理。

在 ONES 的小需求案例中，AI 拿到原始需求后，首先创建工作项跟进需求，并完成需求分析。它输出的不是代码，而是一份结构化 PRD，其中包含：

• 需求目标和业务背景；
• 详细的业务规则；
• Use Case 或典型使用场景；
• 涉及的关键术语、词条或对象；
• 尚待确认的信息与可能的边界条件。

这一阶段的重点不在文档写得多漂亮，而在于帮助团队识别“AI 理解的需求”是否与产品经理想表达的需求一致。

产品经理需要审核 PRD。如果 AI 将业务规则理解错了，或遗漏了重要场景，应在这里打回并补充反馈，而不是等到技术方案、代码甚至测试阶段才发现问题。因为需求理解出现偏差，后续每一步都会建立在错误前提上，返工成本会不断放大。

所以，PRD 评审不是对 AI 的额外限制，而是让需求开发更早暴露问题的机制。对 AI 来说，结构化 PRD 也提供了稳定的后续输入：技术方案、测试方案和代码修改都不再只依赖一句模糊的自然语言需求。

2. 从技术方案到测试方案：先定义“怎么做”和“怎样才算完成”

当 PRD 通过后，AI 才进入技术方案设计阶段。技术方案的作用，是将业务目标转化为可实现、可评审的技术路径。

在这一阶段，AI 可以按照团队的标准组织方案内容，例如涉及哪些模块、需要修改哪些接口、数据如何流转、哪些契约需要调整、是否存在兼容性风险。研发人员则重点判断几个问题：

• 方案是否符合既有架构和模块边界；
• 接口契约、数据结构和调用关系是否合理；
• 是否存在影响范围被低估的情况；
• 是否有更保守、更容易回滚的实现方式；
• 是否引入不必要的复杂度或技术债务。

AI 生成技术方案的价值，是降低方案初稿的准备成本；研发评审的价值，则是把团队积累的架构经验、工程规范和风险判断加入流程。二者不是替代关系。

技术方案通过后，AI 会继续生成测试方案和测试用例。案例中，测试用例采用较明确的三段式结构：前置条件、测试步骤、预期结果。这种写法有两个好处。

第一，它将“需求完成”的标准前置。团队不必等到代码写完后才讨论测试什么、如何判断通过。第二，它让 AI 的后续测试有具体依据：AI 不是泛泛地“跑一遍”，而是按已确认的场景逐项验证。

测试或研发人员需要审核测试方案是否覆盖主流程、异常流程和可能受影响的范围。若需求涉及接口、页面或权限变化，也要确认用例是否能反映真实用户的操作路径。

从流程设计上看，需求分析、技术方案和测试方案本质上是三次不同角度的校验：

• PRD 校验业务理解是否正确；
• 技术方案校验实现方式是否合理；
• 测试方案校验验收标准是否充分。

这三层确认完成后，AI 才具备更稳定地进入编码阶段的条件。

3. 从编码到测试：AI 执行，人工在关键节点把关

需求、技术方案和测试方案均通过后，AI 开始修改代码并提交相关变更。

这时，AI 的工作不只是调用模型生成片段，而是需要结合项目代码、已确认方案和当前任务上下文完成实际修改。代码提交后，研发人员仍要进行代码评审，确认实现是否符合方案、是否遵循既有代码结构、是否引入安全或稳定性风险。

代码评审通过后，AI 按此前确认的测试方案执行验证。测试过程可以涉及：

• 创建或更新测试环境；
• 更新待测代码；
• 执行静态检查、编译检查或基础验证；
• 调用 API 并判断接口返回结果；
• 在涉及界面改动时进行 UI 操作和页面验证；
• 保存截图、录屏、日志、运行数据等测试证据。

最后，研发或测试人员验收测试结果。这里尤其要关注测试不通过项：有些是真实缺陷，有些可能是 AI 操作路径错误、环境差异或界面识别偏差造成的误判。人工验收并不是重复做一遍 AI 已做的工作，而是对高风险和不确定结果进行最终判断。

整个小需求开发流程可以概括为：

原始需求 → AI 需求分析 → PRD 评审 → 技术方案 → 研发评审 → 测试方案 → 测试评审 → AI 编码 → 代码评审 → AI 测试 → 人工验收 → 发布

这条流程的核心不在于节点数量，而在于每一个节点都回答了一个关键问题：需求理解对不对？方案是否合理？代码是否符合约束？测试是否可信？只有这些问题逐步得到确认，AI 才可能稳定参与研发，而不是只在演示环境中表现良好。

三、ONES 如何让 AI 员工进入小需求开发流程？

对企业而言，AI Agent 落地的难点不只是模型和提示词。即使模型能够生成 PRD、方案或代码，如果它无法获取工作上下文、无法进入现有流程、无法留下执行记录，也很难成为团队真正可用的“AI 员工”。

在 ONES 的案例中，工作项、工作流、Agent、Skills 和工作区共同构成了 AI 参与小需求开发的基础。

1. 工作项：让 AI 获得连续的业务上下文

小需求开发通常涉及多种信息：原始需求、附件、历史评论、需求字段、代码关联、测试记录和评审意见。如果这些内容散落在不同工具或聊天窗口中，AI 每进入一个新阶段都可能缺少前文背景。

ONES 工作项可以承载这些过程产物。原始需求、AI 输出的 PRD、技术方案、测试方案、人工反馈和最终测试记录，都围绕同一个工作项沉淀。

这对人和 AI 都有价值。

对 AI 来说，它可以在当前节点读取需要的字段、附件和历史记录，并将结果写回相同位置，避免反复依赖人工复制上下文。对产品经理、研发和测试人员来说，他们可以在一个工作项中查看需求如何演变、哪一版方案被打回、AI 修改了什么、测试证据是什么。

因此，工作项不只是任务容器，更是人机协作中的上下文容器和审计载体。

2. 工作流：让 AI 和人工各自在合适的节点工作

AI 最容易出问题的情况之一，是接收一大段复杂输入后，试图一口气完成分析、设计、编码和测试。当前模型在面对过多信息和过宽目标时，容易忽略关键约束，也难以根据中间反馈调整方向。

ONES 工作流的价值，在于将一项小需求拆成多个节点。需求分析、技术方案、测试方案、编码和测试可以分别定义；AI 员工接管需要执行的节点，产品、研发和测试人员则在评审和验收节点介入。

这种设计使责任边界更清晰：

• 产品经理负责需求是否成立、业务规则是否完整；
• 研发人员负责技术方案、代码质量和风险控制；
• 测试人员负责测试覆盖和测试结果判断；
• AI 员工负责完成分析、方案初稿、编码和测试等执行性工作。

工作项进入某个节点后，AI 根据该节点的输入、目标和 Skills 开始执行；完成后再将结果和状态推进到下一步。下一步如果是人工任务，相关人员可以基于完整记录进行判断；如果是 AI 任务，AI 则接续已经沉淀的上下文继续工作。

这使 AI 不再是一个独立的聊天机器人，而成为工作流中的一个执行角色。

3. Agent、Skills 与工作区：让 AI 真正具备执行条件

要让 AI 从“会回答”走向“能干活”，还需要将能力、权限和运行环境组织起来。

在该案例中，Agent 的定义包括目标、提示词、输入字段和输出字段。输入输出字段的作用，是让 AI 在不同节点只读取必要信息，并以可控格式交付结果。例如，需求分析节点需要关注原始需求、附件和业务字段；测试节点则需要读取已确认的测试方案、代码状态和环境信息。

Skills 用于扩展 Agent 的实际能力。对于研发场景，技能可以覆盖代码理解、代码修改、UI 操作或其他工具调用。直播案例中，代码理解被视为基础能力：AI 需要先理解代码仓、模块职责和工程结构，才可能可靠地修改实现。

工作区则提供实际运行环境。一个企业通常存在多条业务线、多个产品和多个代码仓。工作区可以绑定不同代码仓，并管理与测试环境、外部系统对接相关的凭证。这样，AI 的执行范围和权限不再是模糊的，而是与具体业务和环境对应。

因此，ONES 在小需求开发中的作用，不是简单地“让 AI 写代码”，而是把以下要素连接起来：

工作项提供上下文 → 工作流划分节点与责任 → Agent 定义目标与输入输出 → Skills 提供执行能力 → 工作区提供代码仓和受控环境 → 人工在关键节点评审与验收

这套关系，才是 AI 员工能够进入真实研发流程的基础。

四、实际效果如何？AI 开发小需求有哪些边界？

在 ONES 小需求开发场景中，需求理解、技术方案和代码的一次性通过率分别为 70%、56% 和 44%，测试有效率为 40%。研发投入周期可由周级别缩短至一天以内。（数据来源见文末）

这些数字虽然不能说明AI 已经可以自动交付所有需求，但可以反映出几个重要事实。

第一，需求开发比缺陷修复更复杂。缺陷修复通常有明确的问题描述、日志或复现线索，而需求开发涉及新的业务规则、接口设计和潜在影响范围，AI 的第一版方案更容易需要人工修正。

第二，人工反馈并非失败信号，而是流程的一部分。需求理解 70%、技术方案 56%、代码 44% 的一次性通过率，说明不同阶段的难度不同。相比期待一次完成，更合理的做法是让 AI 先交付可评审的第一版，再根据产品、研发和测试反馈修正。

第三，测试自动化仍有明确边界。测试有效率为 40%，意味着 AI 可以帮助执行一部分验证工作、保存测试证据、缩小人工排查范围，但对 UI 操作、复杂业务路径和部分 API 场景仍可能发生误判。人工必须保留对异常项、边界条件和高风险变更的最终判断权。

第四，流程拆分比扩大输入更重要。与其把所有产品文档、代码、群消息和历史材料一次性交给 AI，不如为不同节点提供必要且相关的上下文：需求节点关注业务规则，技术节点关注契约与模块，测试节点关注用例和结果。目标更单一，输入更聚焦，AI 的输出才更稳定。

从管理视角看，AI 开发小需求的价值不在于减少所有研发角色，而在于改变角色的时间分配。产品经理可以更早发现需求理解偏差；研发人员将更多精力用于方案、代码和风险评审；测试人员把重点放在覆盖充分性和异常项判断上。AI 则承担了大量初稿、执行和记录工作。

五、常见问题FAQ

1. AI 可以独立完成小需求开发吗？

不建议这样理解。AI 可以参与需求分析、技术方案、测试方案、编码和测试执行，但 PRD、技术方案、代码和测试结果都应保留人工评审或验收节点。AI 的价值在于承担执行细节，而不是替代业务和技术责任。

2. 为什么要先让 AI 写 PRD，而不是直接编码？

直接编码会放大需求理解偏差。PRD 将业务规则、使用场景和边界条件显性化，产品经理可以在成本最低的阶段纠正问题。只有需求理解稳定，后续技术方案、代码和测试才有可靠基础。

3. 为什么测试通过后仍需要人工验收？

测试通过只表示 AI 按当前路径获得了预期结果，不代表所有业务场景都已覆盖。复杂系统中仍可能存在 UI 操作偏差、环境差异、接口遗漏和高风险变更，因此人工验收是保障交付质量的必要步骤。

4. 哪些团队适合先尝试这种模式？

有较规范的需求、代码评审和测试流程，并且能够为 AI 提供工作项上下文、代码仓和测试环境的团队，更适合先从低风险小需求开始试点。流程越清晰，AI 越容易发挥作用。

5. ONES 在这个过程中解决的是什么问题？

ONES 将工作项、工作流、Agent、Skills 和工作区连接起来，让 AI 能够在获得上下文和受控权限的前提下执行任务，并将过程结果留在团队可见、可评审、可追溯的研发流程中。

资料来源与写作说明
本文以 ONES 研发团队《AI 员工在 ONES 研发中的落地成果及工程实践》直播中的案例为观察对象，结合公开回放进行整理与分析。
文中涉及的流程、能力与数据均来自该案例，未经作者独立实测或审计，不构成对其他产品的实测排名，也不代表其他企业或项目的普遍效果。