665 lines
32 KiB
Markdown
665 lines
32 KiB
Markdown
# PMFlow 产品蓝图真源
|
||
|
||
版本日期：2026-05-07
|
||
|
||
本文档是 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` 对象，而不是独立模型市场。
|
||
|
||
### 3.6 PMFlow AI 采用“双脑结构”
|
||
|
||
PMFlow 最核心的 AI 价值不来自“多个页面各放一个聊天框”，而来自一个统一 PMFlow AI 在两个工作面上的分工协同：
|
||
|
||
- `Space AI`：空间级 AI Operating Partner。负责跨项目注意力、优先级、机会、风险、想法孵化、待确认聚合和入口路由。
|
||
- `Project Copilot`：项目级上下文操作副驾。负责单个项目内的项目真相解释、结构化变更生成、证据/风险审查、执行上下文交接和回写闭环。
|
||
|
||
两者是同一个 PMFlow AI 的两个工作面，不是两个割裂人格，也不是两个互相抢职责的聊天助手。
|
||
|
||
核心分工：
|
||
|
||
| 问题 | Space AI 主责 | Project Copilot 主责 |
|
||
| --- | --- | --- |
|
||
| 我今天应该先做什么 | 跨项目排序、容量与注意力建议 | 只回答当前项目下一步 |
|
||
| 现在有哪些项目/想法/待确认 | 聚合展示与路由 | 不做跨项目经营判断 |
|
||
| 一个新想法值不值得推进 | 收进 idea seed，判断成熟度和缺口 | 只有明确绑定当前项目时才进入项目变更 |
|
||
| 这个项目现在卡在哪 | 给空间级摘要并跳转 | 基于 Project Memory / ChangeSet / Execution 状态解释 |
|
||
| 用户输入需求、反馈或材料 | 判断归属并路由到项目 | 生成候选 ChangeSet、Evidence 与审查建议 |
|
||
| AI 正在做什么 | 展示跨项目 AI 进行中与异常 | 展示当前项目 AI 动作、证据和门禁 |
|
||
| 外部趋势/竞品/新技术是否相关 | 判断是否值得进入某项目研究 | 结合当前项目目标做影响分析，必要时形成候选变更 |
|
||
|
||
产品原则：
|
||
|
||
- 空间 AI 管“有限注意力投向哪里”，项目 AI 副驾管“这个项目的下一步怎么可靠推进”。
|
||
- 聊天只是输入方式，正式输出必须尽量落到 idea、draft、ChangeSet、Evidence、Task、ExecutionPackage、ReleaseSignal 等业务对象。
|
||
- Space 与 Project 之间的所有注意力回流必须带客户安全对象锚点，至少包含 `objectRef / objectType / objectId / surface / projectId / href`，避免空间建议只能打开页面而不能回到具体项目对象。
|
||
- Space AI 不直接写 Project Memory、不执行 ChangeSet commit、不发起 Execution Bridge 写回。
|
||
- Project Copilot 不做跨项目 portfolio 决策、不直接改 provider/model/prompt 路由、不绕过确认链。
|
||
- AI 可以提出候选、解释依据、准备执行上下文；高风险写入、执行、发布、删除、权限和外部动作必须可审查、可确认、可追溯。
|
||
|
||
## 4. 主交互模型
|
||
|
||
### 4.1 单线程双视图
|
||
|
||
PMFlow 的核心不是“双模式切换”，而是一个统一 `Project Thread` 的两种投影：
|
||
|
||
- `Conversation View`：对话视图。用户用自然语言提出想法、追问、判断、截图、上传材料、下达指令。
|
||
- `Work Graph View`：工作图谱视图。同一条线程被实时映射成结构化项目对象、阶段、状态、证据和待确认变更。
|
||
|
||
用户不是从“聊天”切到“项目管理”，而是在同一个项目线程里切换语言流与工作流。
|
||
|
||
### 4.2 上下文副驾
|
||
|
||
原先的“AI 跟随”不作为模式名，升级为“上下文副驾”能力。上下文副驾只存在于正式业务 surface 内，始终绑定四类上下文：
|
||
|
||
- 当前对象：需求、任务、发布、测试、增长实验、收入信号等。
|
||
- 当前阶段：创意、验证、规划、开发、测试、发布、增长、变现。
|
||
- 当前意图：理解、修改、决策、执行、复盘。
|
||
- 当前风险：回答、草稿、正式更新、外部动作。
|
||
|
||
同一个统一 PMFlow AI 在前台保持一致人格；后台根据上下文自动调度 Product Agent、PMO Agent、Dev Agent、QA Agent、Growth Agent、Ops Agent、Finance/Monetization Agent 等能力。前台不让用户先选多个 agent 标签页。
|
||
|
||
项目级 AI 副驾不是普通聊天框，也不是页面右侧的静态建议卡。它在 PMFlow 中的产品定位是“绑定项目真相层的上下文操作副驾”：把当前 `ProjectTruthState`、ChangeSet、Evidence、ExecutionContext、Reviewer Routing 与 Release Signals 投影成一个可理解、可审查、可行动的上下文包。
|
||
|
||
标准能力由五部分组成：
|
||
|
||
- `Context Packet Viewer`：解释当前对象、阶段、待确认数量、证据数量、高风险项和可执行任务。
|
||
- `Decision/Risk Guard`：说明 AI 当前判断、阻塞原因、证据缺口和高风险门禁。
|
||
- `Action Ladder Controller`：把用户可点动作映射到 `Answer / Draft / Commit / Execute`，并在高风险动作上强制进入审查确认。
|
||
- `Evidence-aware Answer`：回答必须引用当前项目证据或明确说明证据不足，禁止用模板句冒充结论。
|
||
- `Draft/Review/Execute Orchestrator`：可发起草稿、进入待确认、准备执行上下文包、检查发布门禁，但不能绕过 Project Memory commit、reviewer gate 或 Execution Bridge。
|
||
|
||
项目级副驾在不同 surface 上显示不同重点：`command_center` 负责解释当前轮次和待确认入口；`structured_extraction` 负责证据缺口与抽取质量；`change_review` 负责风险、证据和写入门禁；`project_memory` 负责已确认事实和上下文包；`work_graph` 负责正式对象关系与下一任务；`execution_bridge` 负责执行准备、交接包和回写；`team_layer` 负责审查责任和协作阻塞；`release_growth` 负责发布门禁、反馈信号和下一轮 draft。
|
||
|
||
前台结构固定为：当前上下文、AI 判断、下一步动作、证据与缺口、用户输入。页面可以提供 surface adapter，但不得各自实现另一套静态副驾或展示后台 provider、模型、trace、prompt、内部 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 是空间页的核心工作面，不是页面角落的聊天插件。它的产品定位是“跨项目注意力路由器 + 个人 Chief of Staff + 想法孵化器 + 风险雷达”。
|
||
|
||
空间默认承载：
|
||
|
||
- 继续推进。
|
||
- 待我确认。
|
||
- AI 正在推进。
|
||
- 暂存想法。
|
||
- 草案箱。
|
||
- 新建项目入口。
|
||
|
||
空间 AI 默认能力：
|
||
|
||
- `Today Brief`：根据项目、待确认、AI 进行中、风险、草案和容量给出今日优先级。
|
||
- `Attention Queue`：把待确认、项目风险、停滞项目、可推进想法和 AI 异常组织成可处理队列。
|
||
- `Idea Incubation`：承接 pre-project idea seed，输出目标用户、问题假设、价值假设、缺失信息、准备度和推荐下一步。
|
||
- `Cross-project Routing`：把用户输入路由到新想法、Project Launch、已有项目、待确认中心或项目级副驾。
|
||
- `AI Work Monitor`：解释哪些 AI 正在处理、哪些失败/降级、哪些需要人工补信息。
|
||
- `Operating Memory`：沉淀用户跨项目偏好、常见拒绝原因、推进节奏和容量边界，但只作为可审计产品记忆，不用隐式聊天历史冒充事实。
|
||
|
||
空间 AI 的输出优先形态不是长回答，而是可行动的空间对象：
|
||
|
||
- 今日优先事项。
|
||
- 待确认入口。
|
||
- 项目健康/阻塞摘要。
|
||
- 暂存想法及成熟度。
|
||
- 草案推进建议。
|
||
- AI 进行中状态。
|
||
- 推荐跳转和下一步动作。
|
||
|
||
空间 AI 的限制：
|
||
|
||
- 不直接写 Project Memory。
|
||
- 不直接提交 ChangeSet。
|
||
- 不直接派发 Execution Bridge handoff。
|
||
- 不从前端 surface hint 覆盖后端权威项目/想法事实。
|
||
- 不把系统诊断、provider、prompt、trace、数据库字段暴露给客户用户。
|
||
|
||
### 5.2 Project Launch / 新项目启动台
|
||
|
||
新项目启动台用于把一句创意、文档、截图或业务目标转成首个项目草案。它不是表单创建页，而是“意图输入 -> AI 结构化 -> 人类确认 -> 创建项目”的启动流。
|
||
|
||
首版可先用本地状态机和高保真原型验证体验，后续接真实后端对象。
|
||
|
||
### 5.3 Command Center / 指挥台
|
||
|
||
项目创建后的主工作面。推荐结构：
|
||
|
||
- 左侧：项目阶段轨道、项目入口、对象导航。
|
||
- 中间：当前工作画布或对话主线程。
|
||
- 右侧：上下文副驾。
|
||
- 底部或主输入区：全局自然语言输入。
|
||
|
||
指挥台必须支持从对话直接进入结构化提取、待确认、项目对象和执行桥。
|
||
|
||
### 5.4 Structured Extraction / 本轮结构化提取
|
||
|
||
用户每次输入后，AI 不只回复文本，还要展示本轮提取结果：
|
||
|
||
- 新增了哪些对象。
|
||
- 更新了哪些已有对象。
|
||
- 哪些字段来自明确证据。
|
||
- 哪些字段是 AI 推断。
|
||
- 哪些内容需要确认。
|
||
- 哪些内容证据不足。
|
||
|
||
这层解决“AI 到底理解成什么”的即时信任问题。
|
||
|
||
本轮结构化提取不是独立工作流终点，而是结构化读取检查层：
|
||
|
||
- 从指挥台进入时，主任务是核对 AI 本轮理解，并继续补充或进入待确认。
|
||
- 从待确认中心进入时，主任务是核对候选对象的完整读取、证据与字段来源，处理完成后应返回待确认队列继续拍板。
|
||
- 已写入项目记忆后的结构化结果只作为来源快照，修改必须通过新的变更确认链路发起。
|
||
|
||
### 5.5 Change Review / 待确认中心
|
||
|
||
这是 PMFlow 区别于聊天工具的关键页面。AI 的结构化写入先形成业务 diff，再由用户接受、修改、暂缓或拒绝。
|
||
|
||
确认写入项目记忆前，候选对象始终可继续接受、修改、暂缓或恢复处理；“接受”只是进入待写入集合，不等于写入项目真相层。真正锁定边界是用户明确执行“确认写入项目记忆”之后。
|
||
|
||
结构化提取后的默认顺序固定为：
|
||
|
||
```text
|
||
Structured Extraction
|
||
-> ChangeSet 生成
|
||
-> Change Review 初审 / 分流
|
||
-> 必要时 Team Layer 角色审查
|
||
-> Change Review 形成 accepted / edited / deferred / rejected 审查结果
|
||
-> 确认写入 Project Memory
|
||
-> Work Graph 生成正式任务与执行候选
|
||
-> Execution Capability Graph 判断执行模式
|
||
-> Execution Bridge 发起执行交接
|
||
```
|
||
|
||
因此，团队层审查不是 Project Memory 写入后的复盘，也不是另一个待确认中心。团队层只负责把高风险、跨角色、缺证据或需要专业判断的 ChangeSet 路由给合适 reviewer，并展示审查状态、阻塞原因和跳转入口；正式接受、修改、暂缓、拒绝和写入项目记忆仍回到 Change Review 完成。
|
||
|
||
低风险、证据充分、单人项目内的普通变更可以由负责人在 Change Review 直接处理并写入记忆；高风险或团队项目中的关键变更必须先满足角色审查，再允许确认写入项目记忆。禁止先写入 Project Memory 再要求团队补审。
|
||
|
||
待确认中心聚合：
|
||
|
||
- 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、测试结果和执行日志。
|
||
- 自动回写任务状态、阻塞、测试结论和发布准备度。
|
||
|
||
代码仓库连接是 Execution Bridge 的项目级资产，不是 GitHub 专属配置。首版云端标准连接优先使用 GitHub App：PMFlow 平台方在 GitHub 创建并配置一次 App ID、私钥、安装地址和 webhook secret，终端用户只是在 GitHub 安装该 App 并选择自己的仓库，代码仍落在用户自己的仓库里。Gitea / GitLab / 自托管 Git 作为 `Code Provider` 适配接入。Gitea 公网实例可通过 OAuth / Token 接入，内网实例应通过 Local Bridge 或私有部署连接器接入。无论使用哪种 Provider，PMFlow 都只能在用户明确选择项目仓库和任务代码落点后生成真实执行包；未确认仓库时只能生成执行草案，不得声称已推送到代码环境。
|
||
|
||
执行桥必须同时支持：
|
||
|
||
- 同步副驾：开发者在 IDE 里实时协作。
|
||
- 异步 agent：后台接任务、执行、开 PR、回写结果。
|
||
|
||
进入开发执行的边界必须晚于 Project Memory commit。AI 提取出的 Task 或执行建议在 ChangeSet 阶段只是候选对象，不能直接派给人或 agent 执行。只有当相关需求、决策、约束、风险和任务通过 Change Review 写入 Project Memory，并在 Work Graph 中成为正式任务后，才进入执行准备态。
|
||
|
||
执行准备态先由 Execution Capability Graph 判断执行模式，再在 Execution Bridge 完成具体交接：
|
||
|
||
- `ai_direct`：低风险、边界清晰、测试与回写路径明确，可由 AI / agent 执行，但仍必须生成可审计执行包。
|
||
- `ai_with_user_acceptance`：AI 执行，用户负责验收结果。
|
||
- `ai_with_technical_review`：AI 执行但必须绑定技术 reviewer，适合权限、数据、安全、迁移、发布门禁等高风险改动。
|
||
- `needs_human_judgement`：目标、范围、验收标准或商业取舍不清，先回到 Change Review / 指挥台补判断。
|
||
- `blocked`：缺 repo、插件、测试命令、执行包、reviewer、权限或回写证据时显式阻塞。
|
||
|
||
人员或 agent 跟进分两层：审查责任在 Change Review / Team Layer 阶段确定，决定谁对变更质量拍板；执行责任在 Project Memory commit 后、Execution Bridge handoff 前确定，决定谁或哪个 agent 领取正式任务。执行建议可以提前展示，但不得在候选变更尚未写入项目记忆时生效。
|
||
|
||
### 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 检查发布风险”。
|
||
|
||
统一 AI 在产品上必须遵守“双脑结构”：
|
||
|
||
- 空间级入口优先执行 `attention / idea_incubation / routing / monitor / cross_project_summary`。
|
||
- 项目级入口优先执行 `project_truth_explain / structured_change / evidence_review / execution_handoff / writeback_guard`。
|
||
- 后台 agent 只能作为能力编排，不得变成前台多人格标签页，也不得绕过 Space AI 与 Project Copilot 的职责边界。
|
||
|
||
## 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 只打穿创意到首次上线和反馈迭代主链，不做大而全平台。
|