AI 协作开发流程：从需求拆分到人工验收

很多人把 AI 协作开发理解成：把需求告诉 AI，然后等它把代码写出来。

我自己做产品后发现，真正困难的地方从来不只是“让 AI 生成代码”。需求本身是否清楚、方案是否可行、结果能不能在真实环境运行、用户是否真的会用，这些问题不会因为用了 AI 自动消失。

AI 更像一个执行速度很快的协作者。它可以帮我查资料、整理思路、生成原型、实现局部功能、定位问题；但产品要做什么、什么不能做、结果是否合格，最后仍然需要人来判断。

这篇文章记录我现在更常用的一套 AI 协作开发流程：从一个模糊问题开始，走到可以实际运行、可以验收的功能为止。

先确认要解决的到底是什么问题

AI 最擅长处理被说清楚的问题。

如果一开始只说“帮我做一个更好用的功能”，得到的往往也是看起来很完整、实际却不一定能用的代码。因为“更好用”本身没有说明用户是谁、现在卡在哪里、功能应该怎么进入、失败后怎么办，以及什么结果算完成。

我做 UE Toolkit 时，很多功能都不是从“我想加一个按钮”开始，而是先看到真实使用中的重复操作。

例如，用户拿到一个资产包后，可能不知道它是插件、完整工程还是普通资源，也不想每次都手动整理目录再导入。这个问题拆开以后，才会变成更具体的任务：需要识别什么输入、展示什么信息、允许用户在哪一步确认、异常结构怎样提示。

在把任务交给 AI 前，我会尽量先回答几个问题：

• 这个功能为谁解决什么麻烦？
• 最小可用版本要完成哪一段流程？
• 哪些情况暂时不处理？
• 我怎样判断它真的完成了？

这一步不是为了把文档写得很厚，而是把模糊想法变成可以被讨论和验证的边界。

把大需求拆成可验证的小任务

一个功能通常同时包含界面、数据、异常处理和用户操作。如果一次把全部目标交给 AI，模型可能会给出很多实现，但很难知道问题究竟出在哪一层。

更可靠的做法是按链路拆开。

还是以资产处理为例，可以先确认输入识别是否正确，再看列表和状态是否符合预期，之后才处理导入、进度反馈和异常情况。每一步都留下一个可观察的结果：页面能否展示、文件能否被识别、提示是否正确、实际操作是否成功。

这样做有两个好处。

第一，AI 得到的是范围明确的任务，而不是一句很大的愿望。第二，出了问题时我能回到具体环节定位，而不是在一整套混在一起的改动里猜哪里错了。

任务拆分不意味着把每个小动作都写成死规则。它真正的作用是保留判断点：我知道当前在解决什么，也知道下一步为什么值得做。

先查资料和验证方案，再让 AI 大规模实现

AI 能快速生成看起来合理的方案，但“看起来合理”不是技术结论。

遇到版本兼容、系统配置、第三方接口或性能问题时，我会先找官方文档、已有实现和实际运行机制，再让 AI 根据明确的资料协助实现。这样能减少模型按习惯补全、却选错接口或错误理解约束的情况。

例如，在处理不同版本的 Unreal Engine 配置规则，以及蓝图资产导出时的依赖收集问题时，我先确认了配置文件和可用接口，再让 AI 协助把这些规则落实到插件和校验流程中。

我更愿意先做一个小原型，而不是直接把它接进整个产品。原型能验证方向：接口是否真的可用、用户操作是否顺畅、方案是否会引入新的麻烦。只有原型跑通，才值得继续扩大实现范围。

这也是我认为 AI 协作里很容易被忽略的一点：AI 可以加快实现速度，但不能替人承担方案选择的后果。

用上下文让 AI 理解“正在改什么”

AI 不会天然知道一个项目的历史、约束和已有问题。

如果只贴一段报错，让它“直接修”，它可能会得到一个局部能工作的答案，却破坏已有行为。更有效的方式是提供完成当前任务所需的最小上下文：目标模块负责什么、现象怎样出现、期望结果是什么、已经尝试过什么，以及哪些边界不能动。

对我来说，上下文不是把整个仓库一次性塞给 AI，而是让它先理解当前问题所在的链路。

例如，界面卡顿可能与数据读取、图片加载、列表渲染或线程回写有关。先确认现象发生在哪一层，再提供相关代码、日志或复现步骤，AI 才更容易提出能验证的改动。

上下文越清楚，AI 越能帮忙；但上下文越多也不一定越好。无关信息会让问题失焦，最后看起来改了很多，真正的原因却没有被解决。

AI 完成实现后，人工验收才是交付开始

我不会把“代码已经生成”当成功能完成。

AI 给出改动后，最重要的是把项目运行起来，按真实用户的操作去看结果。界面是否看得懂、拖入文件是否有反应、异常时有没有明确提示、配置应用后能否回退、不同环境下是否仍然符合预期，这些都只能在实际运行中确认。

验收时，我更关注可观察的结果，而不是代码看起来是否漂亮：

• 功能是否解决了最初的问题？
• 正常路径能否完成？
• 常见异常有没有合理反馈？
• 新改动有没有影响已有流程？
• 用户是否能理解下一步该做什么？

如果验收失败，我会把现象、复现步骤、报错和预期结果重新整理给 AI，再进入下一轮定位和修复。这个循环不一定快，但它能把“生成了一段代码”变成“交付了一个可以使用的功能”。

用户反馈会让流程从能跑变成可靠

自己测试时，最容易遗漏真实用户会遇到的边界情况。

UE Toolkit 在给别人使用后，用户反馈过文档入口不够直接、资产列表刷新不及时、配置应用后担心无法恢复等问题。这些问题未必复杂，却会直接影响一个工具是否让人放心使用。

AI 可以帮助我更快分析问题和实现改动，但用户反馈决定了我应该优先解决什么。每次反馈进来后，还是回到同一套流程：确认问题、拆分范围、查资料或做原型、实现、实机验收。

产品不是一次性写完的。真正的交付，是在用户开始使用以后继续发生的。

我现在对 AI 协作开发的理解

AI 协作开发不是把产品责任交给模型，而是把人的判断和模型的执行速度组合起来。

人负责：定义真实问题、确定优先级、选择方案、设定验收标准、判断风险和取舍。

AI 可以负责：资料整理、方案对比、原型生成、局部实现、问题定位和重复性工作。

只有这两部分连在一起，AI 才不只是“代码生成器”，而能成为产品开发过程中的协作者。

对我来说，这套流程最重要的价值不是让开发看起来更快，而是让我在面对一个模糊需求时，仍然能一步一步把它推进到可验证、可运行、可继续迭代的结果。