当产品经理在业务不熟、资料不全的情况下接手B端项目二期时，如何与AI协作破局？本文通过真实项目复盘，揭示从业务梳理到文档沉淀的全过程。在AI快速生成方案的表象之下，真正的价值在于产品经理如何识别系统闭环、判断需求边界，以及将AI产出转化为团队共识的深度思考。

最近我介入了一个 B 端业务系统的二期项目，负责推进其中两个核心模块。

刚接手时，我站在一个挺典型的“半空中”的位置：项目一期已经做完，二期还有内容要继续推进，但我并不清楚一期到底完成到了什么程度；哪些规则已经确认，哪些只是过程记录；哪些内容可以复用，哪些还需要重新梳理。

更现实的是，我之前没有接触过这个业务领域。虽然做了多年产品经理，但换到一个陌生行业，很多术语、流程、系统关系都需要重新理解。

当时我手里的材料也很有限：一份客户调研内容，以及一个竞品系统账号。没有现成 PRD，也没有已经整理好的项目资料。

所以这次做需求，对我来说不只是一次业务梳理，也是一场和 AI 的协作实验。

做完整个模块后，我回头看，发现真正值得复盘的不是“AI 帮我写了多少文档”，而是：在业务不熟、资料不全的情况下，产品经理到底可以怎样和 AI 一起，把一个模糊的问题逐步做清楚。

01一开始不是把需求说清楚，而是把“已知和未知”说清楚

刚开始时，我并没有能力把需求一次性说清楚。

所以我做的第一件事，不是让 AI 直接给我一份方案，而是先把自己的处境告诉它。

我告诉 AI：我现在要介入一个XXX项目，项目已经完成一期，还有二期未完成。我主要负责其中XXX模块。现在我对这个系统业务不了解，手里有一份客户调研内容，也有一个竞品系统可以参考。如果我要完成需求产出给开发，应该怎么入手？希望AI能帮我一起提效。

这一步看起来很简单，但后来我发现很关键。

AI 协作不是一定要从“资料完整、目标清晰”才开始。很多真实项目恰恰相反：资料不完整、业务不熟、交接不系统，但事情已经要往前推进了。

这个时候，人的作用不是把答案喂给 AI，而是把处境讲清楚：

• 我知道什么；
• 我不知道什么；
• 我手里有什么；
• 我要产出什么；
• 哪些材料后续还可以继续提供。

这些信息说清楚后，AI 先帮我梳理了一个初步的 PRD 大纲。

但看着这份大纲，我反而有点犯难：结构是完整的，内容看起来也都对，可我对业务还不熟，知道这些“正确”背后可能还有很多没暴露的问题。

于是我没有继续让 AI 往下写，而是让它回过头来对照客户调研和竞品，帮我找差异：哪些是客户提到但竞品没有的，哪些是竞品有但调研里没有的，哪些两边存在冲突。

这些差异让我有了判断抓手。哪些可以先采纳，哪些需要线下沟通确认，哪些还不能直接下结论，都开始变得具体。后续的竞品差异确认清单、访谈问题清单和工作台，也是在这个过程中逐步沉淀出来的。

02 第一稿不是答案，而是一个可以被质疑的对象

等需求文档逐渐成型、准备继续做页面原型前，我又反过来问 AI：这份文档看起来完整，但能不能真的交给开发做？

于是检查重点从“业务是否合理”转向“交付是否清楚”：字段、状态、按钮、附件、通知、异常规则是否定义到位，开发是否能据此评估和实现。后面形成的开发评审确认清单，本质上是在进入原型和更细规则前，先降低开发理解和评估的不确定性。

当信息逐步补齐后，我开始让 AI 生成页面原型和规则说明。第一眼看上去，产出确实挺完整。

模块有了，页面有了，字段有了，流程也有了。

但真正有价值的部分，是我开始看着这些内容不断发现“不对劲”。

比如：

这个字段在新建页填了，后续在哪里查看？

这个按钮点完之后，流程走到哪里？

这个状态只是展示，还是可以筛选？

附件是采购上传的，还是供应商上传的？

供应商能不能看到采购附件？

保存和确认报价到底有什么区别？

报价截止后，采购怎么知道可以进入报价对比？

这些问题如果面对密集的文档，其实很难问出来。因为没有具体对象，就很难判断哪里不合理。

AI 第一稿的价值就在这里：它快速生成了一个可以讨论的版本。

这个版本不一定正确，但它让问题变得具体了。

很多产品判断不是凭空产生的，而是在看到页面、字段、按钮、状态之后才出现的。你只有看到了一个具体设计，才会开始追问：这里为什么这样？后面接到哪里？用户真的能理解吗？数据有没有闭环？

所以现在我不会期待 AI 第一稿就是最终答案。

我更愿意把它当成一个“可被质疑的草稿”。AI 先把模糊的东西变成可见的结构，人再围绕这个结构持续校准。

03“这看着不对劲”背后，是一种系统感

这次协作中，我反复做的一件事，就是指出那些看起来不顺、不清楚、不闭环的地方。

有时候问题很小，比如一个按钮文案容易让人误解。

有时候是一个字段，比如“报价次数”到底从哪里来。

有时候是一个状态，比如是否应该增加“待比价/授标”筛选。

有时候是一个链路，比如采购上传的附件，供应商是否可见，后续详情页是否能追溯。

这些问题表面上是页面细节，背后其实都是产品逻辑。

一个字段有没有闭环，决定了数据是否可追溯。

一个按钮有没有明确去向，决定了操作是否可理解。

一个状态有没有筛选入口，决定了用户能不能找到待办。

一个附件有没有流转说明，决定了采购和供应商之间的信息是否对齐。

这种“不对劲”并不是单纯的审美判断，也不是为了挑毛病。

它背后其实是一种系统感：看到一个字段，会自然想到它后续在哪里展示；看到一个按钮，会想到谁能点、什么时候能点、点完后进入什么状态；看到一个状态，会想到它是否能筛选、是否能驱动流程、是否影响权限和通知。

所以指出的问题看起来很细，但背后其实是在检查系统是否能跑通。

AI 很擅长根据问题给方案。只要我指出某个地方不闭环，它往往能很快给出几种处理方式，并说明哪种更轻、哪种更完整、哪种更适合当前阶段。

但前提是，人要先发现问题。

04 AI 负责展开，人负责收束

AI 很容易展开。

你让它补规则，它可以补很多；让它想异常，它可以列一长串；让它设计一个功能，它也可能自然地往完整系统能力上走。

但项目不是越完整越好。尤其是二期项目，真正难的是判断：本期到底做到什么程度。

比如有一个内部沟通纪要功能，如果让 AI 完整展开，可以做新增、查看、编辑、删除、权限控制、通知、历史版本等一整套能力。

但回到当前项目，我最后选择的是更轻量的闭环：允许新增和查看，本人短时间内可编辑，不做删除，不通知供应商，只作为内部留痕。

这不是 AI 自动决定的，而是人根据项目阶段、开发成本和业务必要性做出的取舍。

所以我觉得，AI 协作里产品经理不能只做“提需求的人”，还要做“收边界的人”。

AI 负责把可能性展开，人负责判断哪些要做，哪些先不做，哪些只是开发评审时再确认。

收束不是简单地砍功能，而是明确本期边界。真正重要的是，关键链路有没有闭环，本期规则有没有讲清楚，开发拿到后是否知道怎么评估和实现。

05 同样用 AI，为什么结果会不一样

这次复盘时我发现，影响 AI 协作效果的，不只是模型能力，也不只是提示词写得好不好。

当然，模型能力本身会影响协作体验。复杂业务需求不是简单问答，它要求 AI 能读长文档、理解上下文、承接多轮追问、保持前后一致，还要能把讨论沉淀成结构化文档。

所以在复杂任务上，能力更强的 AI 工具确实会降低很多协作摩擦。比如使用 Codex、Claude Code 这类工具时，我能明显感觉到它们在上下文承接、多轮协作和结构化输出上更顺畅。

但强模型不是全部。

更关键的是，人能不能和 AI 形成有效的来回：能不能把项目处境讲清楚，能不能在 AI 给出的内容里看出哪里还没接上，能不能顺着一个小问题继续追问，也能不能在 AI 展开很多方案后判断哪些适合本期。

这些能力听起来并不新鲜，但真正做到并不容易。

它来自产品经理在一个个真实项目里慢慢形成的工作敏感度。当 AI 把产出速度拉快之后，人需要更早、更具体地进入判断。否则 AI 可能会生成很多看起来完整的内容，但未必真的能落地。

所以，AI 协作不是让产品经理少思考，而是让产品经理更早进入判断。

06 最后交付的不是文档，而是共同理解

与AI协作的过程中，沉淀出了很多东西：PRD、开发规格说明、页面原型、字段流转、状态定义、操作闭环、验收用例、系统衔接评审清单。

但这些文档不是一开始规划出来的，而是在一次次追问中长出来的。

• 发现字段没闭环，就补字段流转。
• 发现状态不清楚，就补状态定义。
• 发现页面跳转缺失，就补操作入口。
• 发现开发拿文档还不能直接做，就补系统衔接评审清单。

回头看，这些文档的价值不只是“写清楚需求”，而是把对话中的判断沉淀成了团队可以复用的共同理解。

最后，简单总结一下这次协作中沉淀下来的几条原则：

• 先讲清“已知和未知”，而不是直接要答案；
• 让 AI 产出“可被质疑的草稿”，而不是第一稿就正确；
• 人负责发现“不对劲”，AI 负责展开方案；
• 人负责收束边界，判断哪些做、哪些不做。

但这里有一个容易被忽略的前提：模型能力决定了协作的下限，人的系统感决定了协作的上限。

工具可以越来越好，但能不能看出“不对劲”、能不能收住边界、能不能在 AI 展开的无数可能性中做出适合当下的取舍——这些依然是人的功课。

AI 提高了产出的速度，但产品经理决定了产出的质量和边界。

后记：

写完这篇文章，我又追问了自己几个问题：我现在的敏感度，很大程度上来自过去“逐个元素定义规则”的笨功夫。但如果未来的产品经理从一开始就只用 AI 生成完整的文档，这种敏感度还怎么培养？

更进一步——如果 AI 越来越强，强到能自己发现并补上那些“不对劲”，那产品经理的价值还剩下什么？

这些问题我没有答案。但我觉得，它们是值得持续思考的。