产品项目初始化 Prompt：让 Agent 参与从市场分析到版本复盘的全流程
很多团队已经在用 Agent 写代码，但 Agent 往往只参与“实现”这一段：产品经理在文档里描述需求，设计师在另一个工具里画原型，研发在代码仓库里开发，测试和复盘又散落在聊天记录、表格和会议纪要中。
这样做的问题不是 Agent 不够强，而是它没有一个能够持续读取和更新的项目上下文。每次新任务开始，Agent 都要重新猜测产品背景、需求状态、版本范围和验收标准；项目越大，重复沟通越多，历史决策越容易失真。
本文整理自奔跑的大毛腿（@run_maotui）在 X 发布的《产品项目初始化 Prompt：让 Agent 参与产品全流程》。原文把一套初始化 Prompt 设计成产品项目脚手架：初始化完成后，市场分析、需求调研、需求分析、原型、PRD、评审、研发、测试、验收和版本复盘都可以在同一个项目上下文中持续进行。
本文不是把原文整段复制到博客，而是把它拆成一套可以直接落地的目录设计、规则设计和 Agent 协作方法。对于使用 GPT88、Codex、Claude Code 或其他 Coding Agent 的团队，这套结构也可以作为项目初始化的起点。
一、先看核心结论
这套方法最重要的不是某一句 Prompt，而是建立一个稳定的项目工作空间：
原始输入
→ 产品事实与规划
→ 候选需求池
→ 单需求工作包
→ 版本承诺
→ 开发与验收
→ 上线验证与复盘
Agent 在其中扮演的是持续协作成员，而不是一次性的问答机器人。它可以帮助整理材料、分析问题、生成 PRD、拆解任务、编写代码、执行测试、归档证据和总结复盘，但每一个阶段都应该有清晰的输入、输出、负责人和门槛。
最值得保留的四条原则是：
- 原始材料先登记，再用于分析，不要把截图或聊天记录直接当成正式需求。
- 每类信息只保留一个事实源，其他文档通过引用连接，避免多处复制后互相漂移。
- 需求状态由需求池统一维护，不在 PRD、版本计划和聊天记录里各写一份状态。
- Agent 可以提出方案和执行任务，但不能未经确认把草稿标记为已批准，也不能凭空宣称已经上线。
二、为什么要先初始化项目空间
1. 把项目记忆从聊天窗口移到仓库
聊天窗口适合讨论，不适合作为长期事实源。随着项目推进，重要信息会分散在：
- 用户访谈、销售反馈和市场材料；
- 产品背景、术语、平台限制和技术基线；
- 候选需求、优先级和负责人；
- 单个需求的 PRD、原型、接口和验收标准；
- 版本范围、里程碑和发布记录；
- 测试结果、线上指标和复盘结论。
如果这些内容没有固定位置，Agent 即使能够搜索，也很难知道哪一份是最新的、哪一份只是草稿、哪一份已经被否决。
2. 让 Agent 参与完整链路
一个产品需求通常不是“写一个页面”这么简单，而是经历一连串判断：
发现问题 → 判断是否值得解决 → 定义需求 → 设计方案 → 评审取舍
→ 研发实现 → 测试验收 → 发布观察 → 复盘是否达成目标
如果目录结构只服务于研发，Agent 就只能看到代码和 issue，看不到问题来源、业务目标与验收证据。初始化 Prompt 的作用，是先把这些信息划分出来，使 Agent 在后续任务中能够沿着项目流程工作。
3. 目录编号是一种低成本导航
使用 00、01、02 这样的编号前缀，不是为了追求形式，而是为了让文件系统排序本身就呈现工作流顺序。新人、产品经理和 Agent 都可以从根目录按顺序理解项目，而不需要先熟悉一套复杂的知识库导航。
三、推荐的项目目录结构
在空项目根目录下建立以下目录：
00-rules/ # 规则、模板和阶段门槛
01-inputs/ # 讨论、文档、截图和外部材料
02-product/ # 稳定产品事实、术语和平台基线
03-planning/ # 问题空间、模块地图和决策记录
04-requirement-pool/ # 候选需求登记和状态跟踪
05-requirements/ # 每个正式需求的独立工作包
06-versions/ # 版本目标、范围和里程碑
07-reviews/ # 评审、验收、上线验证和复盘
90-assets/ # 演示、原型截图和共享交付物
99-archive/ # 已关闭或过期的材料
各目录的职责应尽量互不重叠：
| 目录 | 放什么 | 不放什么 |
|---|---|---|
00-rules | 命名、状态、工作流、模板和硬性边界 | 某个具体需求的临时结论 |
01-inputs | 未加工的原始输入和来源登记 | 未经确认的输入直接变成正式需求 |
02-product | 稳定事实、术语、用户和平台背景 | 单个版本的执行计划 |
03-planning | 问题空间、模块地图、架构和决策 | 每条候选需求的详细验收记录 |
04-requirement-pool | 所有候选需求及当前状态 | 需求的完整 PRD 和代码实现 |
05-requirements | 单个需求的定义、方案、开发和验证 | 与该需求无关的项目级规划 |
06-versions | 版本范围、里程碑、发布目标 | 需求池的全量复制 |
07-reviews | 评审、验收、上线数据、复盘 | 未验证的“已上线”结论 |
90-assets | 跨需求共享的原型、演示和图片 | 只属于某个需求的私有中间文件 |
99-archive | 关闭、过期或替换后的材料 | 仍在执行中的正式事实 |
四、先写四份核心规则
不要一开始就为每个目录写几十页说明。先写四份能约束 Agent 行为的规则文件。
1. naming-and-structure.md
这份文件定义目录职责、文件命名和需求目录命名。建议使用稳定、可搜索的英文 kebab-case：
Markdown 文件：problem-space.md、decision-log.md
日期材料：2026-09-18-customer-interview.md
需求目录：req-0001-route-management
版本目录：v1.2
命名规则不需要复杂，但要能让人和 Agent 从文件名判断内容类别、日期和归属。
2. source-of-truth.md
唯一事实源规则解决的是“同一信息应该改哪里”：
每类信息只有一个维护位置，其他地方只引用，不复制完整内容。
例如，需求当前状态只在 04-requirement-pool/requirement-pool.md 维护；版本承诺只在 06-versions/<version>/scope.md 维护；验收证据只在对应需求或 07-reviews/ 中维护。
这条规则能减少一种很常见的 Agent 错误：它在旧 PRD 里看到“进行中”，在版本计划里看到“已完成”，然后自行猜测哪个是真的。
3. status-and-gates.md
需求状态建议先定义完整流程：
candidate → collecting → analyzing → defined → reviewing
→ approved → developing → validating → released → closed
小团队可以从精简版本开始：
candidate → analyzing → defined → approved → released → closed
状态本身不是流程，状态之间的门槛才是。至少要明确：
approved之前必须完成什么信息；- 需求发生实质变化后是否回到
reviewing； released需要哪些真实上线证据；- 谁可以批准、谁可以关闭；
- Agent 是否只能建议状态变化，还是可以执行某些低风险状态更新。
4. product-workflow.md
把整个产品工作流写成一条可执行路径：
原始输入 → 产品认知与规划 → 需求池 → 单需求定义
→ 原型与 PRD → 版本承诺 → 开发验收 → 上线验证 → 复盘
配套纪律应写得直接：
- 原始输入先登记再使用；
- 产品判断引用来源，并标注“已观察”“推断”“待确认”或“未覆盖”；
- 一个需求应该能够独立定义、评审、开发和验收；
- 形成正式结论前，Agent 不得把草稿默认为团队共识；
- 版本发布必须能够回溯到验收记录和上线证据。
五、入口文件怎么设计
README.md：给人和 Agent 的项目地图
根目录 README.md 只需要回答三个问题：项目是什么、当前处于什么阶段、下一步应该去哪里。
# [产品名称] 产品工作空间
本仓库用于长期管理产品认知、需求、版本、验收和复盘。
## 当前阶段
- 已建立产品工作流和目录规则。
- 尚未启动正式版本。
## 常用入口
| 要做的事 | 入口 |
| --- | --- |
| 查看项目规则和工作流 | [AGENTS.md](AGENTS.md)、[00-rules/](00-rules/README.md) |
| 登记讨论和外部材料 | [01-inputs/](01-inputs/README.md) |
| 查看产品背景和术语 | [02-product/](02-product/README.md) |
| 查看问题空间和决策 | [03-planning/](03-planning/README.md) |
| 查看或登记候选需求 | [04-requirement-pool/](04-requirement-pool/README.md) |
| 推进正式需求 | [05-requirements/](05-requirements/README.md) |
| 启动和跟踪版本 | [06-versions/](06-versions/README.md) |
| 保存评审、验收和复盘 | [07-reviews/](07-reviews/README.md) |
这里的“当前阶段”要随着真实项目推进更新，不能永远保留初始化时的默认文字。
AGENTS.md：只保留索引和硬边界
如果项目使用 Claude Code、Codex 或其他支持项目规则文件的 Agent，可以在根目录放一个 AGENTS.md。它不应该复制所有产品知识，而应该成为规则入口：
# [产品名称] 项目协作规则
## 规则入口
详细规则在 `00-rules/` 维护；本文件只保留索引和硬性边界。
| 规则 | 唯一维护位置 |
| --- | --- |
| 目录职责、命名 | `00-rules/naming-and-structure.md` |
| 产品工作流 | `00-rules/product-workflow.md` |
| 需求状态和阶段门槛 | `00-rules/status-and-gates.md` |
| 信息归属和引用 | `00-rules/source-of-truth.md` |
## 通用执行要求
- 先登记输入，再形成方案。
- 需求应能独立定义、评审、开发和验收。
- 产品判断必须引用来源，并标记结论等级。
- Markdown 是持续维护的内容事实源；Word、PDF 是确认内容后的交付产物。
## 硬性边界
- 未经确认，不得把草稿标记为已批准。
- 未经真实验证，不得把需求标记为已发布。
- 密钥、Token、密码不进入代码、文档或 Git 历史。
把详细规则放在 00-rules/，可以减少每次任务加载的上下文，也更容易单独更新某条规则。
六、原始输入为什么要单独登记
01-inputs/ 不等于需求池
用户访谈、销售反馈、会议纪要、截图、竞品链接和外部文章都属于输入。它们可能很有价值，但不一定已经完成需求分析，也不一定代表团队正式决定。
建议在 01-inputs/source-register.md 建立来源登记表：
# 输入来源登记
| 来源 ID | 日期 | 材料 | 类型 | 提供方 | 项目内位置 | 适用范围 | 当前处理状态 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SRC-0001 | 2026-09-18 | 客户访谈 | 访谈 | 客户成功团队 | ... | 路由管理 | 待分析 |
登记表的价值在于让后续结论可以回溯到来源，而不是只剩下一句“用户需要这个功能”。同一材料出现新版本时，应新增记录，不要静默覆盖旧版本。
原始材料至少标记四种状态
未处理 → 已整理 → 已用于分析 → 已归档
也可以补充 待确认、存在冲突 和 已过期。这些标签能帮助 Agent 判断材料是否可以直接作为事实使用。
七、需求池是整个系统的状态中心
04-requirement-pool/requirement-pool.md 只维护候选需求的登记和状态，不承载每个需求的全部细节：
# 需求池
| 需求 ID | 需求名称 | 来源 | 所属模块 | 状态 | 优先级 | 负责人 | 目标版本 | 前置依赖 | 工作包 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| REQ-0001 | 路由失败可解释提示 | SRC-0001 | API 网关 | analyzing | P1 | @owner | v1.2 | 错误码规范 | 05-requirements/req-0001-route-errors/ |
字段规则建议固定下来：
- 来源使用
SRC-XXXX，能够回溯原始输入； - 状态只在需求池维护；
- 优先级使用
P0/P1/P2/P3，并记录判断依据； - 目标版本表示当前计划，不等于已经承诺；
- 版本承诺以
06-versions/<version>/scope.md为准； - 工作包链接到
05-requirements/下的唯一目录。
需求池解决的是“项目里有哪些候选问题、当前推进到哪一步”，而单个需求目录解决的是“这个需求具体怎么定义和交付”。两者不要互相替代。
八、单个需求应该是一个独立工作包
建议每个正式需求建立独立目录，例如：
05-requirements/req-0001-route-errors/
├── README.md
├── context.md # 问题背景、来源和目标
├── requirements.md # 需求定义与非目标
├── prototype.md # 原型或交互说明
├── prd.md # 评审后的产品需求文档
├── technical-plan.md # 技术方案和依赖
├── test-plan.md # 测试范围和验收用例
├── implementation-log.md # 开发过程记录
└── release-evidence.md # 上线与结果证据
不是每个项目都必须使用完全相同的文件名，但一个需求应当能独立回答：
- 为什么要做，问题来自哪里？
- 成功标准是什么，哪些事情明确不做？
- 方案是什么，依赖和风险是什么？
- 如何开发、测试和验收？
- 上线后如何证明它真的生效？
当 Agent 被要求“继续这个需求”时，它只需要读取该工作包、规则入口和必要的产品背景，而不用把整个仓库全部加载进上下文。
九、版本目录负责承诺，不复制需求详情
版本目录可以这样组织：
06-versions/v1.2/
├── README.md
├── goals.md
├── scope.md
├── milestones.md
├── dependencies.md
└── release-checklist.md
scope.md 负责说明本版本承诺交付什么、明确不交付什么、依赖哪些需求和风险。它应该引用需求 ID，而不是复制整个 PRD：
## 本版本范围
- REQ-0001：路由错误提示
- REQ-0004：用量异常告警
## 明确不包含
- 多区域自动故障转移
- 计费账单重构
这样需求的细节仍由需求工作包维护，版本只表达当前的交付承诺。需求发生变化时，Agent 可以检查哪些版本范围受到影响，而不需要同步修改多份重复文本。
十、评审、验收、发布和复盘要形成证据链
07-reviews/ 不只是会议纪要目录。它应当保存可以支撑状态变化的证据：
需求评审 → 技术评审 → 开发验收 → 发布检查 → 上线观察 → 版本复盘
每个阶段都可以要求不同的输出：
| 阶段 | Agent 可以做什么 | 最终需要谁确认 |
|---|---|---|
| 需求评审 | 整理问题、指出冲突、生成待决问题 | 产品负责人和相关业务方 |
| 技术评审 | 梳理依赖、接口、迁移和风险 | 技术负责人 |
| 开发验收 | 运行测试、对照验收标准、汇总失败项 | 需求负责人和 QA |
| 发布检查 | 核对版本范围、回滚方案、监控和权限 | 发布负责人 |
| 上线观察 | 汇总日志、指标和用户反馈 | 产品与技术负责人 |
| 复盘 | 生成目标与实际结果对照 | 版本负责人 |
released 不能仅凭“代码合并”或“部署命令成功”得出。至少需要真实环境中的访问、功能、指标或用户反馈证据，具体证据标准应按项目风险定义。
十一、给 Agent 的初始化 Prompt 应该说什么
初始化 Prompt 的重点不是让 Agent 立刻生成所有文件，而是让它建立规则、确认边界，并在后续任务中按流程工作。可以使用下面这份精简版作为起点：
你现在负责初始化一个长期维护的产品项目工作空间。
目标：让 Agent 能够参与市场分析、需求调研、需求分析、原型、PRD、评审、研发、测试、验收、上线验证和版本复盘。
请按以下顺序执行：
1. 检查当前项目目录和已有文件，不覆盖既有用户内容。
2. 创建 00-rules、01-inputs、02-product、03-planning、
04-requirement-pool、05-requirements、06-versions、
07-reviews、90-assets、99-archive。
3. 在 00-rules 中创建目录职责、唯一事实源、需求状态门槛和产品工作流规则。
4. 创建根目录 README.md、AGENTS.md，以及各目录的 README.md。
5. 创建输入来源登记表和需求池模板。
6. 为所有规则写清楚：来源引用、草稿与批准的区别、发布证据、
密钥和 Token 不得进入文档或 Git。
7. 初始化完成后，输出已创建文件、当前阶段、待确认事项和下一步建议。
执行边界：
- 不要把历史材料直接标记为正式需求。
- 不要未经确认修改业务结论、需求状态或版本承诺。
- 不要删除或覆盖已有文件。
- 不要写入真实 API Key、Token、密码或 Cookie。
- 所有产品判断都要区分已观察、推断、待确认和未覆盖。
这份 Prompt 更像项目引导程序，而不是一次性内容生成任务。初始化完成后，后续任务应该引用项目规则和对应工作包，而不是每次重新粘贴一整套说明。
十二、在 GPT88、Codex 或 Claude Code 中如何使用
第一步：选择一个真实项目根目录
不要在临时聊天目录里初始化。选择实际会长期维护的代码仓库或产品工作区，并先检查当前分支、未提交文件和已有规则。
第二步：先让 Agent 只做初始化
第一轮只创建目录、规则、入口和模板，不要同时让它分析市场、写 PRD 或修改代码。这样更容易审查生成的结构是否符合团队习惯。
第三步：人工确认规则再开始导入输入
重点检查：
- 哪些目录是事实源；
- 哪些状态变化需要人工确认；
released的证据标准是什么；- 需求、版本、评审是否互相复制；
- 团队是否真的会维护这些文件。
第四步：按工作流导入材料
可以把会议纪要、访谈记录、竞品链接和截图放入 01-inputs/，让 Agent 先登记来源，再生成分析结果。分析结果应引用来源 ID，而不是把结论伪装成一手事实。
第五步：从候选需求开始推进
让 Agent 根据输入整理候选需求，写入需求池，给出问题描述、影响范围、优先级建议和待确认项。只有负责人确认后，才进入 defined 或 approved。
第六步：将正式需求拆成独立工作包
当某条需求获得批准，再创建 05-requirements/req-xxxx-name/。这样每个工作包能够拥有自己的 PRD、技术方案、测试计划和发布证据，减少多个需求互相污染。
十三、哪些内容适合交给 Agent，哪些不能交给 Agent 自动决定
| 工作 | Agent 适合做 | 需要人工把关 |
|---|---|---|
| 材料整理 | 提取主题、去重、建立来源索引 | 是否遗漏关键上下文 |
| 市场分析 | 汇总公开信息、比较方案、指出证据差距 | 商业判断与数据可信度 |
| 需求分析 | 拆解问题、整理用户故事、识别冲突 | 最终优先级和范围承诺 |
| PRD | 生成结构、补齐验收标准和边界 | 产品目标、非目标和取舍 |
| 技术方案 | 查代码、梳理依赖、提出实现路径 | 架构决策和生产风险 |
| 测试验收 | 执行测试、汇总结果、定位失败 | 发布准入和业务验收 |
| 复盘 | 汇总指标、对照目标、生成问题清单 | 结论、责任和后续承诺 |
原则很简单：Agent 可以加速分析和执行，但正式事实、业务承诺、权限变化、发布状态和高风险决策都要有明确负责人。
十四、最容易失败的地方
1. 目录建得很完整，但没人维护
目录不是成果，持续更新才是。建议先从四份规则、一个来源登记表和一个需求池开始，等真实工作流运行后再增加文件。
2. 把所有内容都复制到 README
README 是导航，不是第二个知识库。复制越多，事实源越容易漂移。保持短小，用链接指向唯一维护位置。
3. 把草稿当结论
Agent 生成的市场判断、用户需求和 PRD 都应该带状态。没有负责人确认的内容，只能标记为草稿、推断或待确认。
4. 用“已部署”代替“已验证”
部署命令成功并不等于用户可以访问，也不等于功能符合验收标准。发布记录中应区分构建成功、部署成功、路由可达、功能通过和业务指标达标。
5. 把全项目一次性塞进上下文
项目初始化的目的不是让 Agent 每次读取所有文件，而是建立按需读取的导航。先读取规则入口，再读取当前需求工作包和必要的产品事实，最后才扩展到相关版本或历史复盘。
6. 让 Agent 自动改状态但没有审计
状态变化会影响排期、责任和发布决策。可以允许 Agent 建议状态变化，但执行更新前要记录原因、来源和证据；高风险状态如 approved、released 和 closed 应保留人工确认。
十五、如何把这套方法接到 GPT88 工作流
GPT88 更适合作为统一模型入口和 Agent 工具链的一部分，而不是替代项目事实源。实际接入时可以按角色配置不同模型：
- 低成本模型：做目录扫描、格式检查、来源索引和初步摘要；
- 推理模型：做需求冲突分析、技术方案比较和测试失败归因；
- 强模型或人工评审：处理版本取舍、复杂产品决策和发布风险。
模型 ID、价格、上下文、可用协议和配额会变化，项目规则里不要写死某个长期不变的模型承诺。API Key 应通过环境变量或部署平台密钥管理注入，不要写进 AGENTS.md、Prompt、日志、截图或 Git。
一个常见的任务提示可以这样写：
请处理 REQ-0001 路由错误提示。
先读取：
- AGENTS.md
- 00-rules/source-of-truth.md
- 00-rules/status-and-gates.md
- 05-requirements/req-0001-route-errors/
请先输出：
1. 当前需求状态和依据；
2. 已知事实、推断、待确认事项；
3. 本次任务范围和不包含内容；
4. 需要执行的验证；
未经确认，不要修改需求状态、版本承诺或发布证据。
这类提示词比“把这个需求做完”更可靠，因为它把读取范围、输出结构和权限边界说清楚，同时把项目长期规则留在仓库中维护。
十六、初始化后的验收清单
- 项目根目录有 README.md，能够指向主要工作区。
- 根目录有 AGENTS.md 或等价的 Agent 协作入口。
-
00-rules/至少包含命名、唯一事实源、状态门槛和产品工作流规则。 -
01-inputs/有来源登记表，外部材料不会直接变成正式需求。 -
04-requirement-pool/有统一的需求状态和优先级字段。 - 每条正式需求都有独立工作包和验收入口。
- 版本范围引用需求 ID，不复制整份 PRD。
- 发布状态需要真实验证证据。
- 规则中明确禁止写入密钥、Token、密码和 Cookie。
- Agent 知道哪些事情可以执行，哪些事情必须请求确认。
- 团队实际使用过一轮，目录没有成为无人维护的空壳。
结语
产品项目初始化 Prompt 的价值，在于把 Agent 从“临时帮忙写一段代码”提升为“能够在项目上下文中持续协作的成员”。实现这一点不依赖一份超长系统提示词，而依赖稳定的目录、清晰的事实源、可追踪的状态和明确的阶段门槛。
最实用的落地顺序是：先建规则，再登记输入；先维护需求池，再创建单需求工作包；先定义验收，再承诺版本；上线之后保留证据，最后回到复盘。这样，Agent 的每一次分析和执行都能回到项目事实，而不是从零开始猜测。
来源与延伸阅读
- 原文：奔跑的大毛腿（@run_maotui）在 X 发布的《产品项目初始化 Prompt：让 Agent 参与产品全流程》，收录时间为 2026 年 9 月 17 日。
- 相关实践：GPT-6 Astra 时代如何重写 Skills、AGENTS.md 与提示词。
- 文中目录、状态和模板是整理后的可执行版本，实际项目应根据团队审批、合规和发布流程调整。
সম্পর্কিত গাইড
GPT-6 Astra 时代如何重写 Skills、AGENTS.md 与提示词