22 KiB

Raw Blame History

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 应做开放操作层，而不是封闭黑箱。

参考链接：

15. 不可偏离项

后续产品、原型和实现不得偏离以下判断：

PMFlow 是对话驱动的 AI 产品执行操作系统，不是传统项目管理工具加 AI。
聊天是操作语言，结构化对象和项目真相层才是产品内核。
首版体验 solo-first, team-ready，不要按重型 10-50 人团队 PM 工具设计。
团队版不是多人维护任务表，而是围绕 AI 维护的项目真相层进行异步审查和人机混编执行。
前台统一 AI，不暴露复杂 agent 选择器；后台按上下文自动编排专业 agent。
AI 生成正式对象必须有 ChangeSet、Approval、Evidence 或等价的可审计机制。
高风险动作必须可见、可确认、可回溯。
IDE / agent / Git / 测试 / 发布是外部执行主场，PMFlow 做上下文推送和结果回写。
模型推荐、成本、合规是主链决策卡片，不是首版独立巨型模块。
V1 只打穿创意到首次上线和反馈迭代主链，不做大而全平台。

22 KiB Raw Blame History Unescape Escape