为持续推进的产品建立项目空间
推进同一个产品时，用户研究、MVP 取舍和 PRD 会反复使用相同背景。把这些任务放进一个 ChatGPT Project，可以集中管理相关聊天、文件和项目指令，减少重复交代背景的成本。工作方式见 产品经理要把 ChatGPT 当成工作台。
一次性的文案修改或概念查询，普通聊天就够了；需要多轮推进、形成多个产出，或者反复引用同一批材料时，再建立 Project。官方也按这种方式区分项目与独立聊天，见 Projects 文档。
本文讨论的是集中管理聊天、上传文件和来源的 ChatGPT Project。建立项目本身不等于授权它访问电脑文件夹，需要使用的资料应明确上传或连接。不同客户端可能还有本地项目入口，不应与这里的操作混用。
先建立最小可用的项目
在 ChatGPT 中找到 Projects 入口，新建一个项目，按“产品或业务对象 + 当前目标”命名，例如“会议纪要助手 · MVP 验证”。具体按钮位置以当前界面为准。
开始时只需要完成四件事：
- 添加一份简短的项目背景，交代用户、问题、目标和约束。
- 添加当前阶段最需要的证据，例如访谈记录或已有 PRD。
- 在项目设置中填写项目指令，约定协作方式。
- 从项目内新建聊天，用一个明确任务检查上下文是否足够。
可以先让 ChatGPT 概括项目目标、已确认结论和待验证问题，并列出引用的材料。若出现遗漏或冲突，检查材料是否已加入、是否能读取、是否存在多个版本，再开始后续工作。一次概括正确只能说明这次回答使用了相关材料，不能据此认为以后每次都会完整使用所有资料。
项目指令适用于项目内的聊天；跨聊天长期使用的资料应放入项目来源，只对当前任务有用的临时材料可以随请求附上。参考官方项目上下文说明。
Project 中放什么
资料围绕当前决策准备，不必一开始就上传全部历史文件。
| 材料 | 建议包含的内容 | 用途 |
|---|---|---|
| 项目背景 | 目标用户、问题、业务目标、当前阶段、成功标准 | 让建议围绕同一个目标展开 |
| 用户研究 | 访谈目标、招募条件、脱敏记录、用户反馈 | 区分用户事实、研究推断与待验证假设 |
| 竞品资料 | 链接、截图、试用记录、采集日期 | 比较同一场景下的能力与限制 |
| 产品方案 | 已有 PRD、用户流程、MVP 范围、不做清单 | 延续已确认的需求与取舍 |
| 技术与资源约束 | 架构背景、接口限制、团队、预算、时间 | 避免方案超出实际交付能力 |
| 业务数据 | 数据导出、字段解释、指标口径、统计时间 | 支持分析，并避免口径混用 |
| 设计与表达规范 | 设计规范、品牌文案、术语表 | 保持交互和文案一致 |
| 项目状态与决策 | 当前结论、决策日期、依据、负责人、未决问题 | 让后续任务从最新状态继续 |
每份材料最好带有日期、版本和状态，例如 PRD-v0.3-待评审.md。这里的文件名只是命名建议，不表示 Project 内必须建立对应目录。
同一份 PRD 有新版本时，明确哪份是当前有效版本；旧版需要保留时，标为历史参考。访谈原文与分析结论也应分开，避免后续把分析者的推断当成用户原话。对尚未读取的链接，不能仅凭网址推断内容；遇到无法访问的页面，应补充可读取的摘录或文件。
上传前按团队规则脱敏，移除姓名、联系方式、客户标识和凭据等与任务无关的信息。连接外部资料时，同样确认授权范围和共享对象。
Project 自定义指令
项目指令适合保存长期稳定的协作原则。经常变化的进度、范围和数据放在项目资料中，每次任务的具体要求写在当次消息里。
下面的模板可以按项目裁剪，不必让模型每次同时扮演所有角色。
你是我的 AI 产品共创助手。
根据当前任务，采用产品经理、用户研究专家、AI 产品架构师、
PRD 编辑、测试验收负责人或增长运营顾问的分析视角。
协作原则：
1. 所有建议围绕目标用户、使用场景、业务目标和现实约束展开，说明依据与取舍。
2. 区分材料中的事实、已经确认的决策、你的推断和待验证假设。
不编造用户原话、市场数据、来源或实验结果。
3. 引用资料时尽量给出文件名、章节或链接；无法读取时明确说明。
材料冲突时列出冲突点，优先参考明确标为当前有效的版本。
4. 信息不足且会改变关键结论时，先问最必要的问题。
不影响当前推进的缺口，可以在明确标注假设后继续。
5. PRD 中每项需求都要有可判断的验收标准，并覆盖关键边界与异常流程。
6. AI 功能需要说明评估样本、指标与通过标准，以及失败兜底和人工接管条件。
7. 如果范围过大，给出更小的 MVP、暂不做清单及其验证目标。
8. 提醒会影响方案选择的风险，同时给出应对办法；技术可行性与估时需研发确认。
9. 你的建议先作为候选方案，未经我确认，不写成已决定的事项。
默认输出风格：
- 中文
- 结论先行，再说明依据和必要过程
- 比较用表格，步骤用列表，因果与取舍用正文解释
- 给出具体的下一步，少说空话，不重复总结按目标拆分对话，并交代本次任务
同一个 Project 中，可以分别建立“访谈分析”“MVP 范围评审”“PRD 修订”“上线复盘”等聊天。一个聊天围绕一个主要结果，便于回查；涉及其他聊天的关键结论时，引用已经保存的项目摘要或决策记录。
不必每次粘贴全部历史。指出当前阶段、有效资料、本次目标和约束即可：
我们继续推进这个产品项目。
当前阶段：
[填写阶段]
本次参考材料：
[文件名 / 版本 / 相关章节；说明哪份是当前有效版本]
已有结论：
[简述已确认的关键结论，或指向项目状态摘要]
本次目标：
[本次只需要解决的主要问题]
约束条件：
[时间 / 团队 / 技术 / 预算 / 风险]
期望产出与完成标准：
[例如：MVP 范围表，含做与不做、取舍依据、待确认项；暂不写完整 PRD]
请简要复述会影响本次判断的目标与约束。
若存在阻碍判断的关键缺口，先提问；否则按以上要求继续。“确认上下文”应帮助发现缺口，不需要每次长篇复述项目背景。输出是否合格，也要按本次完成标准检查，而不是只看内容是否丰富。
对话结束后更新项目状态
讨论完成后，可以用下面的请求整理交接内容：
请整理本次讨论的项目状态更新草稿：
1. 已由我确认的决策，以及依据和影响范围。
2. 仍未确认的建议与待验证假设。
3. 待解决问题，以及下一步动作、负责人和所需材料。
4. 需要同步修改的文档与具体位置。
只记录对话中确实确认的事项；未指定负责人或日期时标为“待定”。
给出可复制的更新内容，不把这份草稿表述为已经写入项目资料。核对后，把这些内容补入项目状态摘要和决策记录；PRD、任务系统和测试清单也要同步更新。若当前工具支持直接修改，仍应检查实际修改结果；否则手动保存或重新上传有效版本。仅在聊天里说“请记住”，不能代替维护项目文档。
例如，已决定“MVP 暂不接入会议平台”，就应记录决策日期、原因，以及何时重新评估。后续讨论实时录音时，便能判断是条件发生变化，还是偏离了已有范围。
检查项目是否能支持持续协作
- 项目背景能说明目标用户、问题、成功标准和当前约束。
- 当前有效资料可以辨认，历史版本不会被误当成最新要求。
- 事实、假设、候选建议和已确认决策有明确区分。
- 新对话能根据项目摘要继续推进，关键结论能找到依据。
- PRD、决策记录和下一步任务已按确认结果更新。
- 敏感信息和外部连接的授权范围已检查。
Project 提供共享材料与指令的组织方式，不应把它当成完整、准确的自动记忆。关键任务仍要明确指出有效版本和必须遵守的决策；文件上传、研究和外部连接等功能的具体入口与可用范围，以账户和工作区实际提供的能力为准。相关说明见 OpenAI 官方使用指南。