AIOS 产品经理Skill（aios-pm）：把资深产品经理的完整方法论装进你的 AI 工作流
- 它是什么：aios-pm 是一个以「产品经理 Morgan」为角色设定的 AI 技能（技能 ID：9830），专注 PRD 撰写、史诗管理、优先级排序与路线图规划。
- 核心能力：内置
*create-prd、*create-brownfield-prd、*create-epic、*create-story、*gather-requirements、*research、*execute-epic等命令，覆盖从需求收集到史诗执行的完整链路。 - 方法论内置：MoSCoW、RICE 等优先级模型，业务案例、继续/停止决策、范围管理等产品决策工具都已写进角色职责。
- 工程化约束：技能采用「真理来源文件 + 宪法约束 + 声明依赖」的机制，明确要求不发明需求，比直接用聊天式大模型更可控。
- 适合谁用：独立开发者、小型创业团队、需要写 PRD 但不一定有专职产品经理的研发团队，以及想把产品流程标准化的组织。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是 AIOS产品经理Skill，英文名 aios-pm，技能 ID 为 9830。它在 AIOS 体系中扮演「产品经理 Morgan」这一角色：当你需要写 PRD、拆史诗、排优先级、做路线图或者准备业务案例时，激活它，AI 就会以产品经理的身份和命令体系与你协作。
它解决的问题非常具体：需求散落在聊天记录和会议纪要里、PRD 写得东一榔头西一棒子、优先级全靠拍脑袋、史诗和用户故事拆得不够细导致开发反复返工。aios-pm 把这些动作固化成可复用的命令和流程，让「产品工作」变成可重复执行的任务。
所谓「一键安装 AI 技能」，本质是把这套角色定义、命令系统与脚本一次性装进你的工作目录，之后每次只需激活即可复用，不必反复粘贴提示词。通用流程如下（具体安装命令、技能市场入口与版本信息以官方说明为准）：
- 确认安装前提：你的项目工作区中需要有 AIOS 的技能骨架（技能会引用
.aios-core/目录结构）；同时确认本机具备 Node.js 运行环境，因为激活流程中会用到node命令执行脚本。 - 通过技能市场或技能目录安装：在 AI 技能管理入口中搜索「aios-pm」或技能 ID「9830」，点击安装。安装命令与下载地址请以官方说明为准，不要使用来源不明的第三方脚本。
- 验证文件是否就位：安装后应能在项目中看到角色定义文件
.aios-core/development/agents/pm.md（备用路径.codex/agents/pm.md）。 - 验证是否生效：运行
node .aios-core/development/scripts/generate-greeting.js pm，如果终端输出产品经理 Morgan 的问候语，说明技能已正确加载并可以进入角色。 - 进入角色：确认问候语显示后，直接输入
*help查看全部可用命令，即可开始工作。
这种安装方式的价值在于：一次安装、长期复用，团队成员使用的是同一套「产品经理人格 + 同一套方法论」，产出文档的结构天然一致。
该技能的主要功能和特点
- 双路径 PRD 创建：
*create-prd面向从 0 到 1 的新项目，*create-brownfield-prd专门为现有项目编写 PRD——这是很多通用工具缺失的能力，改造类、迭代类需求同样有据可依。 - 史诗与用户故事管理：
*create-epic为现有项目创建史诗，*create-story拆分用户故事，把大目标逐层落到可执行的开发单元。 - 史诗执行支持：
*execute-epic可以按「基于波的并行开发」思路推进史诗计划，让多个任务成组并行落地。 - 需求收集：
*gather-requirements系统地收集并记录利益相关者的需求，避免关键信息只停留在口头。 - 优先级排序方法论：内置 MoSCoW、RICE 等主流排序框架，把「先做哪个」从主观判断变成可讨论的打分。
- 产品策略与规划：覆盖产品策略与愿景、路线图规划、业务案例开发、继续/停止决策、范围管理等偏上游的产品决策工作。
- 研究支持：
*research可生成深度研究提示，帮助你系统性地调研市场与竞品。 - 角色化与可治理：技能要求遵循
.aios-core/constitution.md（治理宪法），只从声明的依赖项执行工作流，并明确规定「不要在项目工件之外发明需求」。
与普通工具相比，它的差异不在于「能写文档」，而在于用一套角色协议约束住 AI 的输出边界：有真理来源、有命令系统、有非协商事项，产出更接近一位真实产品经理的工作方式，而不是一篇看起来漂亮的空泛文案。
如何使用该技能？
第一步：按激活协议加载角色。 技能定义了明确的激活流程：先加载 .aios-core/development/agents/pm.md 作为真理来源（备用 .codex/agents/pm.md），再采用该代理的角色和命令系统，然后通过 node .aios-core/development/scripts/generate-greeting.js pm 生成并显示问候语，最后保持在角色中，直到你要求切换或退出。
第二步：用 *help 摸清命令。 首次使用强烈建议先执行 *help，它会列出所有可用命令及其描述，这比自己猜命令更高效。
第三步：按场景选择命令。 常见调用方式如下：
| 命令 | 用途 | 典型输入示例 | 输出说明 |
|---|---|---|---|
*create-prd |
新项目 PRD | 「做一个面向中小团队的在线协作文档工具，目标用户是 5-20 人团队」 | 结构化的新产品 PRD |
*create-brownfield-prd |
现有项目 PRD | 「给已上线的会员系统增加积分兑换模块」 | 基于现状的增量 PRD |
*create-epic |
创建史诗 | 「把积分体系拆成若干史诗」 | 史诗清单与边界说明 |
*create-story |
创建用户故事 | 指定某个史诗，要求拆到可开发粒度 | 用户故事列表 |
*gather-requirements |
收集需求 | 粘贴访谈纪要、客户反馈 | 结构化需求记录 |
*research |
深度研究 | 「调研同类协作工具的定价策略」 | 研究提示词 |
*execute-epic |
执行史诗 | 指定史诗与并行波次安排 | 分波次的开发计划 |
第四步：补充上下文。 命令只是框架，信息由你提供。尽量给出目标用户、业务目标、约束条件（时间、人力、预算）、已有系统现状，AI 才能在你的项目工件范围内产出可用内容。
第五步：退出或切换角色。 需要回到普通对话模式时，明确说明切换或退出即可，技能会保持角色直到你提出要求。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| aios-pm（本技能） | 角色化的 AI 产品经理代理 | PRD（新项目/存量项目）、史诗与故事、需求收集、MoSCoW/RICE 排序、路线图、业务案例 | 需 AIOS 技能骨架与 Node.js 环境，安装入口以官方说明为准 | 团队需要标准化产品流程、需要存量项目 PRD | 优势：命令体系完整、方法论内置、有治理约束不易跑题；不足：依赖特定技能框架，脱离 AIOS 环境无法发挥 |
| 通用大模型对话 | 万能问答助手 | 自由写作、头脑风暴 | 无门槛，直接对话 | 快速起草一段文字 | 优势：零成本上手；不足：没有固定命令、每次都要重新交代背景，PRD 结构不稳定，容易写出空泛内容 |
| 文档工具的 PRD 模板 | 文档协作与模板库 | 固定格式模板、多人协作 | 需要注册与配置文档空间 | 已经有人写 PRD、只需统一格式 | 优势：协作体验成熟；不足：模板只是空壳，不会帮你思考优先级与拆解 |
| 通用 AI 编码代理的规划模式 | 面向编码任务的计划生成 | 任务拆解、执行计划 | 需配置编码代理环境 | 从需求直接进入编码 | 优势：与代码衔接紧密；不足：产品侧方法论较弱，PRD、业务案例、继续/停止决策等能力覆盖有限 |
从对比可以看出，aios-pm 的不可替代性主要在「产品经理专业方法论 + 角色稳定性」这两点上；如果你只是想让 AI 帮你写一段文字，通用对话就够了，但如果你要的是可交付、可评审的产品文档体系，角色化技能更合适。
该技能的典型应用场景与实际体验情况
场景一：独立开发者从 0 到 1 做新产品。 痛点是一个人既当产品又当开发，PRD 常常省略，导致做到一半反复改需求。使用方式是先 *gather-requirements 把想法和用户反馈整理成需求记录，再用 *create-prd 产出完整 PRD，最后 *create-epic、*create-story 拆成可开发的小块。实际体验是上手难度低，*help 一眼看清能做什么；效果上最大的改善是「想法被迫说清楚」，注意事项是要提供足够真实的用户信息，否则拆出来的故事会偏理想化。
场景二：存量系统改造。 老项目要加模块，最怕新功能和旧逻辑打架。*create-brownfield-prd 正好针对现有项目，配合对现状的描述可以产出增量式 PRD。体验上比通用大模型明显更聚焦，因为它默认你已经有既有系统；注意要主动说明旧系统的约束条件，AI 不会凭空知道你的历史包袱。
场景三：多线并行时的优先级争议。 团队里七八个需求同时抢资源，会上吵不出结果。用 MoSCoW、RICE 框架做一轮打分，把「我觉得重要」变成「分数摆在这里」。体验上排序过程本身就能暴露信息缺口；注意方法论只是工具，输入的业务数据不真实，结论依然不可靠。
场景四：史诗执行与并行推进。 大型史诗拆完后，用 *execute-epic 以「基于波的并行开发」方式安排推进节奏。体验上它给的是节奏建议而非硬性排期，仍需要团队结合实际人力调整；注意并行波次过多会带来集成风险。
该技能能为用户带来的价值
- 效率提升：把 PRD 撰写、故事拆分、需求记录这些重复劳动固化为命令，省去每次从零描述背景的时间，让「写 PRD」从半天缩短为一次对话。
- 门槛降低：没有专职产品经理的团队，也能借助内置的 MoSCoW、RICE、业务案例、继续/停止决策等方法论，做出有章法的产品判断。
- 质量可控：真理来源文件与治理宪法约束让输出更稳定；「不发明需求」的非协商事项，直接抑制了 AI 编造功能的常见问题，减少返工。
- 流程资产沉淀：PRD、史诗、用户故事都是写入项目的工件，随项目积累形成可追溯的产品档案，新成员接手时有据可查。
- 长期价值：团队共用同一套角色与命令，产品语言和方法论趋于一致，评审、交接、复盘的沟通成本持续下降。
常见问题 FAQ
Q1：怎么安装 aios-pm？装完怎么确认生效？
在 AI 技能管理入口搜索技能名「aios-pm」或技能 ID「9830」安装，具体命令与入口以官方说明为准。装完后确认 .aios-core/development/agents/pm.md（备用 .codex/agents/pm.md）存在，再运行 node .aios-core/development/scripts/generate-greeting.js pm，能看到产品经理问候语即为生效。
Q2：这个技能收费吗？ 技能本身的价格与授权方式取决于官方发布渠道，请以官方说明为准。它依赖的 Node.js 等基础运行环境是免费的。
Q3：只有产品经理适合用吗？开发者能用吗？ 不必是产品经理。独立开发者、技术负责人、创业者都可以用；开发同学用它的价值在于「先把需求写清楚再动手」，减少中途改需求。它要求你提供真实的业务上下文，纯技术问题不适合用它。
Q4：它会不会自己编造需求？
技能的非协商事项中明确写了「不要在项目工件之外发明需求」，并且要求只从声明的依赖项执行工作流、遵循 .aios-core/constitution.md。实际使用中仍需你把目标和约束讲清楚，否则它只能在有限信息范围内推理。
Q5：和直接用大模型写 PRD 相比，该怎么选？ 如果只是偶尔写一段产品描述，通用大模型更快；如果你需要成体系地做 PRD、史诗拆分、优先级排序并长期沉淀文档，角色化、有命令体系和治理约束的 aios-pm 更合适。