从单次提问到持续推进产品
很多人使用 ChatGPT 的方式还停留在：
帮我写个 PRD
帮我想几个功能
帮我写一段文案
帮我总结一下竞品这些请求都能节省时间。但如果每次都从一句话开始，产品背景、用户证据和已经做过的取舍就容易散落在不同对话里。今天生成的功能清单，可能与昨天确定的 MVP 范围冲突；PRD 写得完整，也不代表需求已经得到验证。
产品落地需要把一组相互关联的问题逐步收敛：
- 验证问题：这个问题是否真实？目标用户是谁？他们现在怎么解决？
- 选择方向：竞品解决得怎么样？我们的切入点在哪里？
- 确定范围：MVP 做什么、不做什么？怎样用较小投入验证关键假设？
- 交付上线：PRD 怎么写清楚？研发怎么拆？上线怎么验收？
- 观察结果：上线后看什么指标？哪些结果会让我们继续、调整或停止？
把 ChatGPT 当成工作台，就是围绕同一个产品持续提供材料、讨论取舍、修订产出，并把确认过的结论保存下来。后一次任务从前一次的结论继续，而不是重新生成一套看似合理的方案。
Projects 可以把相关聊天、文件、指令和来源组织在一起，为这种协作提供项目空间。具体搭建方法见 用 ChatGPT Projects 搭建产品项目工作台。功能说明参考 OpenAI 官方 Projects 文档。
按产品阶段安排协作
可以让 ChatGPT 在不同阶段采用不同的分析视角。角色名称用于明确任务重点，具体请求仍然要说明输入材料和需要作出的判断。
| 阶段 | 协作视角 | 需要提供的材料 | 产出与关键判断 |
|---|---|---|---|
| 机会发现 | 市场研究员 | 业务目标、市场资料、已有线索 | 机会地图、痛点评分及依据，判断哪些问题值得进一步调查 |
| 用户研究 | 访谈设计师 | 研究目标、招募条件、访谈记录 | 访谈提纲、问卷、基于证据的用户画像，区分用户原话与研究推断 |
| 竞品分析 | 产品战略顾问 | 竞品链接、截图、试用记录 | 竞品矩阵、差异化定位，标明资料日期与待核实项 |
| MVP 定义 | 产品负责人 | 用户证据、资源约束、核心假设 | MVP 范围、不做清单、验证方案，说明为什么保留或推迟某项需求 |
| PRD 写作 | 产品文档助手 | 已确认范围、业务规则 | PRD、用户故事、验收标准，补齐边界与异常流程 |
| 原型设计 | 交互顾问 | 核心流程、设计规范 | 页面结构、字段表、状态说明，检查空状态、错误与恢复路径 |
| 技术拆解 | 技术产品经理 | PRD、架构背景、技术约束 | API 清单、数据模型、任务拆分草案，交由研发评审可行性与估时 |
| 测试上线 | QA 负责人 | 验收标准、测试环境、发布方式 | 测试用例、上线检查表、回滚条件，交由团队执行并确认结果 |
| 运营复盘 | 数据分析师 | 业务数据、指标口径、用户反馈 | 数据看板方案、复盘报告、迭代计划，区分观察到的变化与原因假设 |
这张表不要求项目按固定顺序走完所有阶段。访谈可能推翻原来的定位，技术评审也可能迫使 MVP 缩小范围。每一轮协作都应说明：新增了什么证据，它改变了哪个判断。
用同一个例子串起证据、范围和验收
假设要做一个面向小团队的 AI 会议纪要工具。下面是说明工作方式的假设场景，不代表真实调研或实测结果。
一开始只有“大家整理纪要很麻烦”的想法。此时可以让 ChatGPT 帮忙设计访谈，重点追问最近一次会议后发生了什么、谁整理纪要、怎样分发、任务是否有人跟进。让它直接生成用户画像，容易把常见印象误当成研究结论。
拿到访谈记录后，再要求它把“用户原话、现有做法、问题影响、待验证假设”分别整理，并标出对应记录。假如材料显示，用户更困扰的是会后任务没有负责人，那么下一步需要验证的就是“明确负责人是否能改善任务跟进”，而不只是“能否生成更长的摘要”。
这会直接影响 MVP：先支持用户上传会议转写文本，生成带原文依据的行动项草稿，由用户确认任务、负责人和截止时间；实时录音、多平台会议接入和自动催办可以暂缓。每项取舍都要能回到当前要验证的问题。
写 PRD 时，再把“行动项提取”拆成可验收的行为，例如：
- 原文没有明确负责人时，标记为“待确认”，不自行补人名。
- 每条行动项保留对应原文，用户能检查是否提取准确。
- 用户可以修改、删除和确认行动项，再导出结果。
- 生成失败时保留输入内容，并提供重试或手动整理的路径。
上线后也要同时观察 AI 输出和业务结果。前者可以用人工标注样本检查行动项的遗漏、误提取和负责人匹配；后者可以观察用户是否确认并导出结果、整理耗时是否变化。指标需要事先说明分母、统计窗口和基线，不能仅凭“生成成功率高”就认定产品解决了问题。
每次对话形成一个可继续使用的结果
一次请求最好围绕一个明确目标，例如“判断访谈是否足以支持 MVP 立项”，而不是同时要求完成研究、PRD、原型和上线方案。
我们正在评估一个面向小团队的 AI 会议纪要工具。
当前阶段：用户研究结束，准备确定 MVP。
输入材料：已上传的访谈记录、项目背景和技术约束。
本次目标：判断现有证据支持先解决哪个问题。
约束：两名研发，四周内验证；暂不接入会议平台。
请输出：
1. 现有材料能支持的结论，并注明来源位置。
2. 尚未得到支持的假设，以及最低成本的验证办法。
3. 建议的 MVP 范围与不做清单，并说明取舍依据。
4. 需要我确认的关键决策。
不要编造用户原话、统计数据或技术可行性结论。讨论结束后，把确认过的结论更新到项目摘要和决策记录中，同时保留未解决的问题。模型提出的建议先作为候选方案，经确认后才成为后续任务的前提。这样能减少一个未经验证的猜测在多轮对话后变成“既定事实”的情况。
工具按任务选择，结果由人核验
文件上传适合处理访谈、PRD 和数据；网页搜索与 Deep research 适合查找和比较外部资料，研究报告仍需检查来源、日期及其是否支持结论。参考 OpenAI 官方使用指南与搜索及研究说明。
需要持续修改 PRD 时，可以使用当前界面提供的文档编辑能力；若有 Canvas，也可以用来集中修订正文。生成文件后应打开检查，再针对具体段落或表格提出修改。参考 OpenAI 官方文件协作说明。
需要使用外部工作资料时，再检查账户是否提供相应的应用连接或插件能力。这类能力也可能以 Connectors 等名称出现，具体名称以当前界面为准。连接能力及可用范围取决于账户、工作区和具体集成，不能因为安装了连接就默认所有资料都已读取。参考官方工具连接说明。
用户访谈、竞品事实、研发承诺和上线结果，都需要相应证据或负责人确认。上传资料前还应按团队规则处理隐私与授权，只提供任务需要的内容。产品经理要持续决定的是：当前最重要的不确定性是什么，需要什么证据，以及什么结果足以支持下一步投入。