32 KiB

Raw Permalink Blame History

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，再由用户接受、修改、暂缓或拒绝。

确认写入项目记忆前，候选对象始终可继续接受、修改、暂缓或恢复处理；“接受”只是进入待写入集合，不等于写入项目真相层。真正锁定边界是用户明确执行“确认写入项目记忆”之后。

结构化提取后的默认顺序固定为：

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

参考链接：

15. 不可偏离项

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

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

32 KiB Raw Permalink Blame History Unescape Escape