当产品经理在业务不熟、资料不全的情况下接手B端项目二期时，如何与AI协作破局？本文通过真实项目复盘，揭示从业务梳理到文档沉淀的全过程。在AI快速生成方案的表象之下，真正的价值在于产品经理如何识别系统闭环、判断需求边界，以及将AI产出转化为团队共识的深度思考。
最近我介入了一个 B 端业务系统的二期项目，负责推进其中两个核心模块。
刚接手时，我站在一个挺典型的“半空中”的位置：项目一期已经做完，二期还有内容要继续推进，但我并不清楚一期到底完成到了什么程度；哪些规则已经确认，哪些只是过程记录；哪些内容可以复用，哪些还需要重新梳理。
更现实的是，我之前没有接触过这个业务领域。虽然做了多年产品经理，但换到一个陌生行业，很多术语、流程、系统关系都需要重新理解。
当时我手里的材料也很有限：一份客户调研内容，以及一个竞品系统账号。没有现成 PRD，也没有已经整理好的项目资料。
所以这次做需求，对我来说不只是一次业务梳理，也是一场和 AI 的协作实验。
做完整个模块后，我回头看，发现真正值得复盘的不是“AI 帮我写了多少文档”，而是：在业务不熟、资料不全的情况下，产品经理到底可以怎样和 AI 一起，把一个模糊的问题逐步做清楚。
刚开始时，我并没有能力把需求一次性说清楚。
所以我做的第一件事，不是让 AI 直接给我一份方案，而是先把自己的处境告诉它。
我告诉 AI：我现在要介入一个XXX项目，项目已经完成一期，还有二期未完成。我主要负责其中XXX模块。现在我对这个系统业务不了解，手里有一份客户调研内容，也有一个竞品系统可以参考。如果我要完成需求产出给开发，应该怎么入手？希望AI能帮我一起提效。
这一步看起来很简单，但后来我发现很关键。
AI 协作不是一定要从“资料完整、目标清晰”才开始。很多真实项目恰恰相反：资料不完整、业务不熟、交接不系统，但事情已经要往前推进了。
这个时候，人的作用不是把答案喂给 AI，而是把处境讲清楚：
这些信息说清楚后，AI 先帮我梳理了一个初步的 PRD 大纲。
但看着这份大纲，我反而有点犯难：结构是完整的，内容看起来也都对，可我对业务还不熟，知道这些“正确”背后可能还有很多没暴露的问题。
于是我没有继续让 AI 往下写，而是让它回过头来对照客户调研和竞品，帮我找差异：哪些是客户提到但竞品没有的，哪些是竞品有但调研里没有的，哪些两边存在冲突。
这些差异让我有了判断抓手。哪些可以先采纳，哪些需要线下沟通确认，哪些还不能直接下结论，都开始变得具体。后续的竞品差异确认清单、访谈问题清单和工作台，也是在这个过程中逐步沉淀出来的。
等需求文档逐渐成型、准备继续做页面原型前，我又反过来问 AI：这份文档看起来完整，但能不能真的交给开发做？
于是检查重点从“业务是否合理”转向“交付是否清楚”：字段、状态、按钮、附件、通知、异常规则是否定义到位，开发是否能据此评估和实现。后面形成的开发评审确认清单，本质上是在进入原型和更细规则前，先降低开发理解和评估的不确定性。
当信息逐步补齐后，我开始让 AI 生成页面原型和规则说明。第一眼看上去，产出确实挺完整。
模块有了，页面有了，字段有了，流程也有了。
但真正有价值的部分，是我开始看着这些内容不断发现“不对劲”。
比如：
这个字段在新建页填了，后续在哪里查看？
这个按钮点完之后，流程走到哪里？
这个状态只是展示，还是可以筛选？
附件是采购上传的，还是供应商上传的？
供应商能不能看到采购附件？
保存和确认报价到底有什么区别？
报价截止后，采购怎么知道可以进入报价对比？
这些问题如果面对密集的文档，其实很难问出来。因为没有具体对象，就很难判断哪里不合理。
AI 第一稿的价值就在这里：它快速生成了一个可以讨论的版本。
这个版本不一定正确，但它让问题变得具体了。
很多产品判断不是凭空产生的，而是在看到页面、字段、按钮、状态之后才出现的。你只有看到了一个具体设计，才会开始追问：这里为什么这样？后面接到哪里？用户真的能理解吗？数据有没有闭环？
所以现在我不会期待 AI 第一稿就是最终答案。
我更愿意把它当成一个“可被质疑的草稿”。AI 先把模糊的东西变成可见的结构，人再围绕这个结构持续校准。
这次协作中，我反复做的一件事，就是指出那些看起来不顺、不清楚、不闭环的地方。
有时候问题很小，比如一个按钮文案容易让人误解。
有时候是一个字段，比如“报价次数”到底从哪里来。
有时候是一个状态，比如是否应该增加“待比价/授标”筛选。
有时候是一个链路，比如采购上传的附件，供应商是否可见，后续详情页是否能追溯。
这些问题表面上是页面细节，背后其实都是产品逻辑。
一个字段有没有闭环，决定了数据是否可追溯。
一个按钮有没有明确去向，决定了操作是否可理解。
一个状态有没有筛选入口，决定了用户能不能找到待办。
一个附件有没有流转说明，决定了采购和供应商之间的信息是否对齐。
这种“不对劲”并不是单纯的审美判断，也不是为了挑毛病。
它背后其实是一种系统感：看到一个字段，会自然想到它后续在哪里展示；看到一个按钮，会想到谁能点、什么时候能点、点完后进入什么状态；看到一个状态，会想到它是否能筛选、是否能驱动流程、是否影响权限和通知。
所以指出的问题看起来很细，但背后其实是在检查系统是否能跑通。
AI 很擅长根据问题给方案。只要我指出某个地方不闭环，它往往能很快给出几种处理方式，并说明哪种更轻、哪种更完整、哪种更适合当前阶段。
但前提是，人要先发现问题。
AI 很容易展开。
你让它补规则，它可以补很多；让它想异常，它可以列一长串；让它设计一个功能，它也可能自然地往完整系统能力上走。
但项目不是越完整越好。尤其是二期项目，真正难的是判断：本期到底做到什么程度。
比如有一个内部沟通纪要功能，如果让 AI 完整展开，可以做新增、查看、编辑、删除、权限控制、通知、历史版本等一整套能力。
但回到当前项目，我最后选择的是更轻量的闭环：允许新增和查看，本人短时间内可编辑，不做删除，不通知供应商，只作为内部留痕。
这不是 AI 自动决定的，而是人根据项目阶段、开发成本和业务必要性做出的取舍。
所以我觉得，AI 协作里产品经理不能只做“提需求的人”，还要做“收边界的人”。
AI 负责把可能性展开，人负责判断哪些要做，哪些先不做，哪些只是开发评审时再确认。
收束不是简单地砍功能，而是明确本期边界。真正重要的是，关键链路有没有闭环，本期规则有没有讲清楚，开发拿到后是否知道怎么评估和实现。
这次复盘时我发现，影响 AI 协作效果的，不只是模型能力，也不只是提示词写得好不好。
当然，模型能力本身会影响协作体验。复杂业务需求不是简单问答，它要求 AI 能读长文档、理解上下文、承接多轮追问、保持前后一致，还要能把讨论沉淀成结构化文档。
所以在复杂任务上，能力更强的 AI 工具确实会降低很多协作摩擦。比如使用 Codex、Claude Code 这类工具时，我能明显感觉到它们在上下文承接、多轮协作和结构化输出上更顺畅。
但强模型不是全部。
更关键的是，人能不能和 AI 形成有效的来回：能不能把项目处境讲清楚，能不能在 AI 给出的内容里看出哪里还没接上，能不能顺着一个小问题继续追问，也能不能在 AI 展开很多方案后判断哪些适合本期。
这些能力听起来并不新鲜，但真正做到并不容易。
它来自产品经理在一个个真实项目里慢慢形成的工作敏感度。当 AI 把产出速度拉快之后，人需要更早、更具体地进入判断。否则 AI 可能会生成很多看起来完整的内容，但未必真的能落地。
所以，AI 协作不是让产品经理少思考，而是让产品经理更早进入判断。
与AI协作的过程中，沉淀出了很多东西：PRD、开发规格说明、页面原型、字段流转、状态定义、操作闭环、验收用例、系统衔接评审清单。
但这些文档不是一开始规划出来的，而是在一次次追问中长出来的。
回头看，这些文档的价值不只是“写清楚需求”，而是把对话中的判断沉淀成了团队可以复用的共同理解。
最后，简单总结一下这次协作中沉淀下来的几条原则：
但这里有一个容易被忽略的前提：模型能力决定了协作的下限，人的系统感决定了协作的上限。
工具可以越来越好，但能不能看出“不对劲”、能不能收住边界、能不能在 AI 展开的无数可能性中做出适合当下的取舍——这些依然是人的功课。
AI 提高了产出的速度，但产品经理决定了产出的质量和边界。
后记：
写完这篇文章，我又追问了自己几个问题：我现在的敏感度，很大程度上来自过去“逐个元素定义规则”的笨功夫。但如果未来的产品经理从一开始就只用 AI 生成完整的文档，这种敏感度还怎么培养？
更进一步——如果 AI 越来越强，强到能自己发现并补上那些“不对劲”，那产品经理的价值还剩下什么？
这些问题我没有答案。但我觉得，它们是值得持续思考的。
本文由 @爱因思索 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。