# PMFlow 产品蓝图真源 版本日期：2026-04-24 本文档是 PMFlow 当前产品方向的长期真源。后续原型、前端实现、后端对象模型、AI 编排与商业化叙事默认以本文档为准；只有当用户明确拍板调整产品战略时，才更新本文档。 ## 1. 最终定位 PMFlow 不是“聊天工具 + 项目管理工具”，也不是“Jira 加一个 AI 助手”。PMFlow 的最终定位是： **面向软件技术/半技术创作者与 1-10 人 AI 产品团队的，对话驱动的 AI 产品执行操作系统。** 它要解决的不是“怎么把任务排得更整齐”，而是： **把一个模糊创意持续压缩成可上线、可验证、可盈利的产品，并让人类、AI agent、IDE、Git、测试、发布和运营数据围绕同一份项目真相协同。** 外部表达可以更短： **AI 产品从创意到上线和变现的执行操作系统。** 首版体验必须 `solo-first, team-ready`： - `solo-first`：一个个人开发者、一人公司或小团队负责人，也能独立跑通创意到上线主链。 - `team-ready`：底层必须从第一天支持成员归属、角色审查、确认链、证据链和执行回写，避免后续团队版重做。 PMFlow 不追求成为重型企业 PM 系统，不按 10-50 人传统研发组织的管理后台去设计。首版核心用户是个人开发者、一人公司、副业创业者、半技术产品创作者和 1-10 人 AI 应用小团队。 ## 2. 产品边界 PMFlow 服务的项目类型是 AI 应用与传统软件 AI 转型项目。 覆盖范围： - 原生 AI 应用：AI 客服、AI 写作、RAG 知识库、Agent 工作流、多模态生成工具等。 - 垂直行业 AI 应用：教育、法律、财税、医疗辅助、运营自动化等。 - Agent 应用：工作流 agent、多 agent 协作、后台任务 agent、组织内助手。 - 传统软件 AI 转型：CRM、OA、ERP、工业软件、内部工具叠加 AI 能力。 不作为首版主目标： - 完全无 AI 能力的传统软件项目。 - 纯硬件产品。 - 只有想法、没有落地意愿的概念收集。 - 大企业 portfolio、复杂组织树、重审批采购、完整财务系统。 ## 3. 核心战略判断 ### 3.1 不做泛聊天，做项目型 AI 入口 聊天是操作语言，不是产品本体。用户可以从自然语言开始，但每次有效输入都要进入项目上下文、结构化对象、变更集、确认链或执行桥。 运行时和前端都禁止把 PMFlow 做成脱离业务对象的泛化聊天产品。 ### 3.2 不做传统项目管理，做结构化项目真相层 项目管理不是另一个模块，而是 AI 从对话、截图、文档、IDE、Git、测试和数据源中持续抽取、更新、回写后的“工作表面”。 用户看到的不是数据库表，而是可审查、可编辑、可追溯的项目对象： - 需求 - 决策 - 任务 - 风险 - 模型决策 - 测试结果 - 发布门禁 - 增长实验 - 收入信号 ### 3.3 不做全自动黑箱，做监督式自治 PMFlow 的 AI 应该能自动提取、拆解、同步、预警、生成执行上下文、触发外部工具和回写状态，但高风险动作必须可见、可确认、可审计。 产品原则是： **AI 自动推进标准流程，人类处理目标、判断、例外、确认和责任归属。** 禁止把“99% 自动驾驶”当成无条件产品原则。正确方向是监督式 agent 工作台。 ### 3.4 不替代 IDE，做执行桥 开发执行主要发生在 Cursor、VS Code、Codex、GitHub Copilot、GitHub PR、测试系统等外部工具里。PMFlow 不自建完整 IDE，不把开发者关进平台。 PMFlow 应负责： - 把需求、上下文、约束、验收标准、模型决策和风险推给开发工具。 - 支持同步副驾式开发和异步后台 agent 执行。 - 把提交、PR、测试、阻塞、执行日志和发布结果回写到项目真相层。 ### 3.5 不把模型推荐做成独立头牌，而作为主链决策对象 模型推荐、成本估算和合规提示是 AI 应用开发的关键能力，但它们必须嵌入需求、预算、执行和发布主链，形成 `Model Decision` 对象，而不是独立模型市场。 ## 4. 主交互模型 ### 4.1 单线程双视图 PMFlow 的核心不是“双模式切换”，而是一个统一 `Project Thread` 的两种投影： - `Conversation View`：对话视图。用户用自然语言提出想法、追问、判断、截图、上传材料、下达指令。 - `Work Graph View`：工作图谱视图。同一条线程被实时映射成结构化项目对象、阶段、状态、证据和待确认变更。 用户不是从“聊天”切到“项目管理”，而是在同一个项目线程里切换语言流与工作流。 ### 4.2 上下文副驾 原先的“AI 跟随”不作为模式名，升级为“上下文副驾”能力。它始终绑定四类上下文： - 当前对象：需求、任务、发布、测试、增长实验、收入信号等。 - 当前阶段：创意、验证、规划、开发、测试、发布、增长、变现。 - 当前意图：理解、修改、决策、执行、复盘。 - 当前风险：回答、草稿、正式更新、外部动作。 同一个统一 AI 在前台保持一致人格；后台根据上下文自动调度 Product Agent、PMO Agent、Dev Agent、QA Agent、Growth Agent、Ops Agent、Finance/Monetization Agent 等能力。前台不让用户先选多个 agent 标签页。 ### 4.3 Action Ladder 所有 AI 动作必须分级： - `Level 1: Answer`：只回答，不修改结构化数据。 - `Level 2: Draft`：生成草稿，进入待审区。 - `Level 3: Commit`：更新项目对象，必须显示 diff 和证据。 - `Level 4: Execute`：触发外部动作，如创建任务、推送 IDE、发起测试、生成发布动作。 高敏感动作必须走 `Draft -> Review -> Confirm -> Execute`： - 改需求范围。 - 大批量创建或重排任务。 - 委派开发到 IDE / agent。 - 触发发布。 - 修改定价、公开内容、营收目标。 - 删除、归档或覆盖正式对象。 ## 5. 核心产品表面 ### 5.1 Space / 空间 空间是所有项目、想法、草案和待继续事项的上层入口。它不等同于传统项目列表，而是用户当前所有创意、项目和 AI 推进状态的个人工作面。 默认承载： - 继续推进。 - 待我确认。 - AI 正在推进。 - 暂存想法。 - 草案箱。 - 新建项目入口。 ### 5.2 Project Launch / 新项目启动台 新项目启动台用于把一句创意、文档、截图或业务目标转成首个项目草案。它不是表单创建页，而是“意图输入 -> AI 结构化 -> 人类确认 -> 创建项目”的启动流。 首版可先用本地状态机和高保真原型验证体验，后续接真实后端对象。 ### 5.3 Command Center / 指挥台 项目创建后的主工作面。推荐结构： - 左侧：项目阶段轨道、项目入口、对象导航。 - 中间：当前工作画布或对话主线程。 - 右侧：上下文副驾。 - 底部或主输入区：全局自然语言输入。 指挥台必须支持从对话直接进入结构化提取、待确认、项目对象和执行桥。 ### 5.4 Structured Extraction / 本轮结构化提取 用户每次输入后，AI 不只回复文本，还要展示本轮提取结果： - 新增了哪些对象。 - 更新了哪些已有对象。 - 哪些字段来自明确证据。 - 哪些字段是 AI 推断。 - 哪些内容需要确认。 - 哪些内容证据不足。 这层解决“AI 到底理解成什么”的即时信任问题。 ### 5.5 Change Review / 待确认中心 这是 PMFlow 区别于聊天工具的关键页面。AI 的结构化写入先形成业务 diff，再由用户接受、修改、暂缓或拒绝。 待确认中心聚合： - AI 提议但未确认的对象。 - 高风险改动。 - 缺证据结论。 - 范围、成本、发布和合规风险。 - 需要不同角色异步审查的团队决策。 ### 5.6 Work Graph / 项目工作台 工作台按阶段组织项目对象： - 创意：Idea、Opportunity、Target User、Problem Statement、Solution Concept。 - 验证：Assumption、Evidence、Competitor Insight、Market Signal。 - 规划：Requirement、PRD、Milestone、Decision、Risk。 - 开发：Task、Build Spec、Execution Thread、Code Change / PR。 - 测试：Test Case、Test Run、Bug、Release Gate。 - 发布：Release、Rollback Plan、Observation Metric。 - 增长与变现：Growth Experiment、Channel、Conversion Signal、Revenue Signal。 工作台不是传统看板的替代品，而是结构化项目对象的主视图。对象可用列表、看板、时间线、关系图和表格等投影展示。 ### 5.7 Execution Bridge / 执行桥 执行桥连接 PMFlow 与 IDE / agent / Git / 测试系统。 首版重点： - 从 PMFlow 任务生成开发上下文包。 - 生成适合 Cursor / VS Code / Codex / GitHub agent 使用的开发 prompt。 - 把需求、约束、验收标准、模型决策和风险一起推送。 - 监听提交、PR、测试结果和执行日志。 - 自动回写任务状态、阻塞、测试结论和发布准备度。 执行桥必须同时支持： - 同步副驾：开发者在 IDE 里实时协作。 - 异步 agent：后台接任务、执行、开 PR、回写结果。 ### 5.8 Release & Growth / 发布与增长 发布不是终点，而是进入增长和变现验证的入口。 首版只做轻量闭环： - 发布准备度。 - 发布风险。 - 模型效果验证。 - 关键指标观察。 - 用户反馈聚类。 - 首批增长实验建议。 - 基础收入/转化信号。 不在首版做完整财务系统和完整合规平台。 ### 5.9 Project Memory / 项目记忆 Project Memory 是项目的机器可读真相层，也是后续 AI 行动的优先上下文来源。 它管理已确认事实： - 已确认目标。 - 已确认用户群。 - 已确认 MVP 范围。 - 已确认需求。 - 已确认技术约束。 - 已确认模型决策。 - 已确认优先级原则。 - 已确认商业模式。 - 已确认发布目标。 AI 后续行动优先引用 Project Memory，而不是无限依赖长聊天上下文。 ### 5.10 Team Layer / 团队层 团队版不是传统“多人一起维护任务表”，而是人机混编协作层。 团队协作的核心不是更多字段、更多权限、更多会议，而是： - 共享项目真相。 - 异步审查与拍板。 - 角色化收件箱。 - 团队动态流。 - Agent workforce 可见化。 ## 6. 团队协作原则 PMFlow 的团队方向是： **一个人如何像一个团队一样推进；一个小团队如何像一个更强的 AI 组织一样协作。** 团队版必须遵守三层协作模型。 ### 6.1 共享项目真相 所有成员围绕同一份项目真相层工作。团队成员默认看到： - 当前目标。 - 已确认需求。 - 待确认变更。 - 当前风险。 - 最新决策。 - 执行状态。 - 证据和来源。 先共享真相，再共享任务。 ### 6.2 异步审查与拍板 团队协作的关键不是同步开会，而是在同一份结构化变更集上分角色审查： - 产品负责人看价值、范围和优先级。 - 开发负责人看实现复杂度、架构风险和技术约束。 - QA 看回归范围和发布门禁。 - 运营/增长看上线节奏、渠道和指标影响。 - 创始人/负责人做最终取舍。 ### 6.3 人机混编执行 团队由人类成员、AI agent、外部工具执行器和异步任务线程共同组成。 平台要让团队看到： - 哪些 agent 正在工作。 - 用了哪些上下文。 - 产出了什么。 - 阻塞在哪里。 - 需要谁确认。 这比传统成员列表和任务看板更重要。 ### 6.4 Execution Capability Graph / 执行能力图谱 PMFlow 面向的是 AI 应用开发，不再把“人会哪种编程语言”作为任务分配中心。旧的用户、技能、负载三模块降级为底层信号；新的团队与个人能力模型是： **AI + 工具 + 人类判断责任 + 项目上下文 + 容量信号。** 任务推进先判断执行模式，而不是先找会 React / Python 的人： - `ai_direct`：AI 可直接生成执行包，适合低风险、边界清晰的动作。 - `ai_with_user_acceptance`：AI 执行，用户负责验收结果，适合非技术或半技术用户。 - `ai_with_technical_review`：AI 执行但必须有人类 reviewer 审查，适合权限、数据、安全、迁移、发布门禁等高风险改动。 - `needs_human_judgement`：范围、目标、商业取舍或验收标准不清时，先让人类补判断。 - `blocked`：缺 repo、插件、执行包、测试命令、回写证据或 reviewer 时显式阻塞，禁止冒充可执行。 后续团队空间只能扩展此模型，不能回到传统“用户管理 / 技能管理 / 团队负载”三件套作为主体验。技能标签可以继续作为参考词库，但不能成为 AI 分配任务的唯一或核心依据。 ### 6.5 Adaptive Human Capacity / 自适应人类容量 AI 应用时代不能继续把“工时负载”理解成固定工时槽或固定类型比例。PMFlow 的容量模型以人机混排为前提： - 时间是硬上限：人类一天仍有有限注意力、会议、休息和疲劳边界。 - 类型是弹性的：深度判断、审查、验收、协调共享同一个人类容量池，不再写死 35/25/20/20。 - 风险和疲劳决定边界：总时间未满不代表可以继续加高风险判断；加班只增加时间预算，不消除质量风险。 - 每日建议基线由当天真实任务池动态生成，依据人工触点、风险等级、截止时间、强绑定关系、成员角色、上下文熟悉度和工具准备度。 - 负责人可以手工调整今日有效容量、加班容量和任务类型偏向，但必须先看到模拟结果，调整必须有原因、审计和过期时间。 个人空间只展示“我的今日容量”：我今天有效容量多少、已计划人工触点多少、为什么还能/不能承接、AI 预处理可释放多少人工时间。Team Layer 展示“团队今日容量”：团队需求结构、成员容量卡、瓶颈、AI 预处理建议、负责人调整入口和调整记录。`/workloads` 只保留为高级容量明细，传统工时和旧负载比例仅作为历史成本参考。 后续团队空间只能扩展自适应容量模型，不能回退为传统工时表、固定工作类型槽或简单 workload ratio 分配。 ## 7. 底层对象模型 首版必须先定对象层，否则 UI 会漂。 ### 7.1 横切核心对象 - `Thread`：项目对话线程。 - `ProjectObject`：所有正式业务对象的统一抽象。 - `ChangeSet`：AI 每轮建议的结构化变更集。 - `Approval`：人工确认、修改、拒绝、暂缓记录。 - `Evidence`：对象与对话、截图、文档、PR、测试、数据源之间的证据关系。 - `ContextPacket`：当前页面/对象/阶段/意图/风险的上下文包。 - `ExecutionRun`：外部工具或 agent 执行事实。 - `AuditEvent`：关键动作审计。 ### 7.2 首版业务对象 首版对象不要过多，优先打通主链： - `Idea` - `Opportunity` - `Requirement` - `Decision` - `Task` - `ModelDecision` - `Risk` - `TestRun` - `Release` - `Metric` - `GrowthExperiment` - `RevenueSignal` ### 7.3 对象状态 正式对象必须区分状态： - `draft` - `proposed` - `confirmed` - `executing` - `blocked` - `done` - `archived` AI 生成不等于事实生效。只有经过确认、证据绑定或明确低风险规则允许的内容，才能成为项目真相。 ## 8. AI Agent 编排 前台只有一个统一 AI，不暴露一排 agent 让用户选择。后台按任务自动编排： - `Product Agent`：目标、需求、价值、范围、优先级。 - `PMO Agent`：里程碑、依赖、风险、状态推进。 - `Dev Agent`：开发上下文包、IDE prompt、PR 协作。 - `QA Agent`：测试策略、用例、回归、发布门禁。 - `Growth Agent`：数据解读、增长实验、转化优化。 - `Ops Agent`：运营内容、渠道节奏、自动化任务。 - `Finance/Monetization Agent`：定价、成本、收入信号、ROI。 前台只在必要时提示当前建议来自哪类专业能力，例如“当前由 QA Agent 检查发布风险”。 ## 9. AI 应用专属能力如何放置 ### 9.1 模型决策 模型智能评估与推荐作为 `ModelDecision` 对象嵌入需求宪章、任务拆解、预算估算、发布验证和复盘。 首版评估维度： - 能力匹配度。 - 成本适配度。 - 合规/可用性。 模型推荐不是独立大模块，不作为首屏主卖点。 ### 9.2 成本与 ROI 首版只做轻量： - 模型/API 成本估算。 - 实际调用成本回写。 - 发布后基础转化和收入信号。 - 单项目投入产出趋势。 不做完整财务系统、税务、现金流和多项目财务管理。 ### 9.3 合规风控 首版只做发布门禁和风险提醒： - 模型备案/来源风险。 - 数据敏感性。 - 内容安全风险。 - 知识产权风险。 - 对外发布风险。 不做完整合规平台，不把合规作为首版主功能墙。 ## 10. V1 范围 V1 只打穿一条主链： **创意输入 -> AI 结构化提取 -> 变更确认 -> 项目对象沉淀 -> 任务拆解 -> 推送 IDE / agent -> 开发与测试回写 -> 发布 -> 数据反馈 -> 下一轮迭代。** V1 必须包含： - 对话驱动的项目线程工作区。 - 本轮结构化提取。 - 待确认变更中心。 - Project Memory 真相层。 - Work Graph 项目工作台。 - Execution Bridge 执行桥。 - 轻量 ModelDecision / Cost / Release Check 卡片。 - 基础团队可见性：成员归属、角色、审查对象预留。 V1 不做： - 完整财务模块。 - 完整合规平台。 - 大而全协同体系。 - 大企业组织树。 - 多项目 portfolio。 - 投融资、孵化生态、应用市场。 - 复杂多 agent 前台角色系统。 ## 11. V1.5 与 V2 ### V1.5：Team-ready 补强 - 成员与角色归属。 - Team Feed 团队动态流。 - Decision Desk 决策台。 - Role Inbox 角色收件箱。 - 变更集多人异步审查。 - 任务/PR/测试的跨角色通知。 ### V2：Hybrid Human + Agent Team - Agent Workforce 面板。 - 多 agent 并行执行。 - 跨人/跨 agent 协同。 - 自动复盘与组织学习。 - 更完整的增长实验与收入闭环。 - 企业级权限、审计和私有化部署。 ## 12. 北极星指标 不要把首版北极星指标设成普通 DAU。更重要的是主链效率： - 从 idea 到首个可上线 MVP 的时间。 - 从需求确认到首个 PR 的时间。 - AI 提取变更被接受/修改/拒绝的比例。 - 状态和进度自动回写覆盖率。 - 发布门禁通过率。 - 上线后进入下一轮迭代的项目占比。 - 项目真相层对象有证据链接的比例。 ## 13. 用户体验硬原则 - 用户可见语言默认中文。 - 视觉默认浅色白底 + `#2463EB` 主色，参考 Linear 的克制层级、密度和节奏。 - 移动端不是桌面压缩版，必须有单手路径、底部安全区、抽屉/分段/底部 CTA。 - 项目创建前不展示正式应用底部导航；项目创建后移动端底部导航固定为 `空间 / 指挥台 / 待确认 / 动态 / 我的`。 - 项目内 `工作台 / 开发执行 / 发布增长 / 项目记忆` 不进入底部导航，通过项目内二级入口、分段切换或更多菜单进入。 - 不做泛后台风，不把 UI 画成表格管理系统。 - 不让用户先理解一堆 agent 名词。用户只看当前任务、对象、风险和下一步。 ## 14. 行业趋势依据 以下公开趋势作为方向依据，不作为逐字产品需求： - OpenAI 在 2026-02-02 发布 Codex app，强调它是管理多个 agent、并行工作、长任务协作的 command center；这支持 PMFlow 做“监督式 agent 工作台”，而不是单纯聊天框。 - OpenAI 在 2026-04-16 的 Codex 方向更新中继续强调自动继续长期任务、连接更多日常工具、记忆偏好和处理重复任务；这支持 PMFlow 的 Execution Bridge、Project Memory 和持续回写方向。 - GitHub 在 2025-02-06 推出 Copilot agent mode，并在 2025-06-13 区分 IDE 内同步 agent mode 与后台 coding agent；这支持 PMFlow 同时设计同步副驾和异步后台 agent。 - Atlassian Rovo 在 2025-07-09 强调 AI 要 built into workflow、chat that acts，并在 2025-08-26 强调基于组织知识的对话层、多步动作、记忆和个性化；这支持 PMFlow 的上下文副驾、项目真相层和动作确认。 - Microsoft 2025 Work Trend Index 提出 Frontier Firm 与 agent boss，说明未来团队协作会转向人类管理 AI agent、组织人机混编执行；这支持 PMFlow 的 Team Layer 和 Agent Workforce。 - MCP 已成为 AI 应用连接外部数据与工具的重要开放协议方向；PMFlow 应做开放操作层，而不是封闭黑箱。 参考链接： - https://openai.com/index/introducing-the-codex-app/ - https://openai.com/index/codex-for-almost-everything/ - https://github.blog/news-insights/product-news/github-copilot-the-agent-awakens/ - https://github.blog/developer-skills/github/less-todo-more-done-the-difference-between-coding-agent-and-agent-mode-in-github-copilot/ - https://www.atlassian.com/blog/artificial-intelligence/rovo-chat-july-2025-updates - https://www.atlassian.com/blog/artificial-intelligence/rovo-chat-august-2025-updates - https://www.microsoft.com/en-us/worklab/work-trend-index - https://modelcontextprotocol.io/docs/start/tutorial ## 15. 不可偏离项 后续产品、原型和实现不得偏离以下判断： - PMFlow 是对话驱动的 AI 产品执行操作系统，不是传统项目管理工具加 AI。 - 聊天是操作语言，结构化对象和项目真相层才是产品内核。 - 首版体验 `solo-first, team-ready`，不要按重型 10-50 人团队 PM 工具设计。 - 团队版不是多人维护任务表，而是围绕 AI 维护的项目真相层进行异步审查和人机混编执行。 - 前台统一 AI，不暴露复杂 agent 选择器；后台按上下文自动编排专业 agent。 - AI 生成正式对象必须有 ChangeSet、Approval、Evidence 或等价的可审计机制。 - 高风险动作必须可见、可确认、可回溯。 - IDE / agent / Git / 测试 / 发布是外部执行主场，PMFlow 做上下文推送和结果回写。 - 模型推荐、成本、合规是主链决策卡片，不是首版独立巨型模块。 - V1 只打穿创意到首次上线和反馈迭代主链，不做大而全平台。