项目管理智能体（PM Agent）PRD v1.0（SaaS｜企业微信/飞书打通｜100–1000人互联网企业）

  • 文档类型：产品需求文档（PRD）
  • 产品形态：Web 管理台 + IM（企业微信/飞书）对话式智能体 + 开放 API
  • 目标客户：100–1000 人互联网行业小微/中型企业（产品/研发/测试/设计/运营多角色协作）
  • 核心价值：把“管理动作”从人转移给智能体，把“项目状态”从填表转移为自动生成，把“交付产物”从散落转移为可追溯资产

0. 一句话定义

PM Agent 是“以对话为主界面、以交付物为主对象、以工作图谱为底座”的项目管理系统：让项目管理从“人追人、表追表”变成“智能体驱动的闭环交付”。

1. 背景与机会

1.1 目标企业典型现状（100–1000人互联网团队）

  • 组织结构多为：产品线/项目组并行，跨团队共享研发与测试资源
  • 工具现状常见组合：
    • 任务：飞书/企业微信消息 + 表格/看板工具
    • 需求：PRD 文档散落（飞书文档/腾讯文档/语雀/Confluence/Notion）
    • 节点：里程碑靠口头与群公告，缺少一致口径
    • 输出：上线清单、测试报告、验收材料、复盘文档分散在各系统

1.2 核心痛点（按你给的四类问题映射）

  1. 项目管理难
  • 状态靠手填；多项目并行时“真相”不可见
  • 风险靠经验；预警滞后且缺少可操作建议
  • 资源冲突无法提前暴露（开发/测试/设计被多项目抢占）
  1. 需求管理难
  • 需求来源多渠道、重复、口径不一致
  • PRD→任务拆解依赖“资深 PM/TL”，标准难复制
  • 需求变更没有影响分析：影响哪些里程碑/交付物/版本
  1. 节点管理难
  • 里程碑/关键节点（评审、联调、提测、灰度、发布）缺少统一标准
  • 节点责任人不清晰，卡点没有升级链路
  • 节点完成标准（DoD）不一致，导致“名义完成、实际没交付”
  1. 输出管理难
  • 输出物无法对齐：PRD、设计稿、接口文档、测试报告、发布说明、验收记录
  • 输出物与任务/版本未绑定，复盘与审计成本高
  • 管理层缺少“交付物视角”的项目健康度

1.3 机会窗口：AI从“辅助写作”升级为“可执行智能体”

现有工具普遍停留在：

  • 生成摘要/润色文案（Copilot）
  • 轻量问答（Chat） 缺少：
  • 能把对话内容转成结构化工作项并持续跟进
  • 能把节点/交付物闭环化，并自动生成管理输出
  • 能在企业微信/飞书里完成 80% 的项目操作

2. 产品目标与成功指标

2.1 产品目标（目标 = 让管理动作自动化）

  • 让“需求→计划→执行→交付→复盘”闭环的关键动作可由智能体自动完成或半自动完成
  • 让“项目真相”来自系统事件与集成数据，而不是人工汇报
  • 让“交付物”成为第一等公民：可追溯、可验收、可复用

2.2 北极星指标（NSM）

  • 按时交付率提升：按时完成的里程碑/节点占比（Node On-time Rate）
  • 管理工时下降：PM/负责人用于收集状态、追进度、写周报的时间减少比例
  • 交付物完整率：每个版本/项目要求交付物的完成度与合规性（Deliverable Completeness）

2.3 关键过程指标（示例）

  • 需求转化效率：需求进入→完成评审→进入迭代的平均耗时
  • 迭代健康度：燃尽偏差、阻塞天数、返工率
  • 风险响应：风险识别→明确owner→给出动作→关闭的平均耗时
  • 报告自动化：周报/月报自动生成覆盖率与人工修改幅度

3. 产品定位与核心原则

3.1 定位

  • 面向互联网团队的“AI 驱动项目管理系统”（不是在既有系统上加一个聊天框）
  • 主战场：企业微信/飞书（对话即操作、卡片即状态）
  • 主对象：交付物与节点（不是“任务列表”）

3.2 核心原则

  1. 对话优先（Chat-first）：项目管理动作尽量在 IM 发生
  2. 交付物优先（Output-first）：用“交付物清单”串起需求、任务、节点
  3. 工作图谱优先（Work-Graph-first）：用关系网络而不是孤立表格来表达真实依赖
  4. 默认自动化（Autopilot by default）：能自动就不要求人工填
  5. 组织可复制（Templateable）：项目方法论、节点标准、DoD、报表模板可复用与版本化

4. 竞品分析（详细）

目标：用 Jira/Confluence/TAPD 等“行业 SOTA”定义基准能力，用国内研发管理工具定义本土化集成与定价，再用 ClickUp/Notion 观察“全能协作平台”的趋势。

4.1 行业基准（SOTA 能力清单）

以 Jira + Confluence 模式为代表的基准能力包括：

  • 工作项体系：Epic/Story/Task/Bug，支持自定义工作流、字段、权限、看板与路线图
  • 自动化规则：基于事件触发与条件的自动流转
  • 知识库（Confluence）：页面树、模板、宏、与项目工作项互链
  • 报表：燃尽、累计流图、版本发布、跨项目路线图
  • 生态：API/插件市场（Marketplace）与外部系统集成

4.2 竞品对比总览（核心差异点）

产品 定位/强项 弱项/缺口（针对100–1000人互联网团队） 价格/门槛（公开信息）
Jira（Atlassian） 工作流与权限极强；敏捷研发事实标准 配置与治理成本高；“写周报/追节点/管输出”仍靠人；IM 内闭环弱 采用分档渐进计费模型，官方示例给出 Jira Cloud Standard 在不同席位段的单价计算方式（如 1–100席 $8.60/席/月）。 oai_citation:0‡Atlassian
Confluence（Atlassian） 知识库与模板体系强；与 Jira 深度互链 知识沉淀依赖习惯；输出物与节点闭环仍需流程设计 Standard $5.42/用户/月，Premium $10.44/用户/月；自动化额度 Free/Standard/Premium 不同。 oai_citation:1‡Atlassian
TAPD（腾讯） 本土敏捷研发平台；腾讯生态/企业微信友好 更偏研发管理平台，跨部门输出物与管理报告仍偏“系统操作” 腾讯云购买页显示：企业版账户 799/账号/年，卓越版账户 499/账号/年。 oai_citation:2‡Tencent Cloud
PingCode 国内研发全流程；模块化（项目/知识/测试/效能） AI 更像“加成”，不是主操作系统；输出物闭环仍需人为定义 免费版 25人以下免费；项目管理商业版标价 499（人/年），知识管理 399（人/年）。 oai_citation:3‡PingCode
ONES 研发管理套件；工作流/效能/项目集齐全 复杂度与治理成本仍偏高；“对话式执行”不足 官方定价页：团队版 50人及以下免费；企业版 10人起售（按需订阅）。 oai_citation:4‡ONES
Worktile 通用项目协作；里程碑/甘特图/模板较成熟 研发需求/缺陷/版本链路偏弱；需求到交付物追溯要靠配置 免费版限10人；专业版 ￥499人/年；旗舰版 ￥799人/年。 oai_citation:5‡Worktile
ClickUp 全能协作（任务/文档/白板/AI）；视图丰富 研发语义与追溯体系不如 Jira/TAPD；本土 IM 与合规需补强 Unlimited $7/用户/月（按年付），Business $12/用户/月（按年付）；另有 Brain AI 定价。 oai_citation:6‡ClickUp
Notion 文档/数据库一体；轻量需求与知识管理强 复杂项目执行与权限/流程不足；节点与输出闭环需要强自建 定价页显示：Plus $10/席/月，Business $20/席/月。 oai_citation:7‡Notion
Teambition（阿里） 项目协作+甘特；钉钉/阿里生态适配 研发链路与追溯深度一般；对话式执行不足 帮助文档信息显示企业版按名额与时间收费，价格提到 399元/人/年。 oai_citation:8‡Teambition Support
禅道（ZenTao） 开源+本土化；适合私有化与可控 SaaS 体验与生态弱于头部；AI 与 IM 内操作弱 官方页面展示开源版/企业版/旗舰版/IPD版等版本体系。 oai_citation:9‡禅道项目管理软件

4.3 竞品“空白区”（100–1000人互联网企业最缺）

  1. 对话即项目执行：多数工具仍要求打开系统、点页面、填字段
  2. 节点+交付物闭环：多数工具把“里程碑”当时间点，而不是“带验收标准的交付门”
  3. 管理输出自动化：周报/月报/项目集汇总仍高度依赖人工
  4. 跨工具真相聚合：代码、CI、测试、文档、群讨论分散，系统无法自动形成项目事实
  5. 低治理成本：Jira/ONES/PingCode 类工具强，但“强治理”本身成本高

5. 差异化策略（必须可落地）

5.1 差异化主张

“项目管理智能体 = 默认接管项目经理的机械劳动，把管理输入变成自然语言，把管理输出变成自动生成。”

5.2 三个差异化支柱

A. 对话式执行（Chat-native Execution）

  • 企业微信/飞书是主界面：
    • @PM Agent 创建需求：XX → 自动生成需求卡片、补全信息、发起评审
    • @PM Agent 本周版本状态 → 自动拉取关键事实生成周报
    • @PM Agent 把这个群讨论转成任务 → 自动抽取、去重、分派、设定DDL
  • 卡片/消息是“可执行 UI”（审批/确认/驳回/补充信息一键完成）

B. 节点与交付物为第一等公民（Node & Deliverable-first）

  • 节点不是“日期”，而是：
    • owner、验收标准（DoD）、必需交付物清单、依赖、风险、升级链路
  • 交付物不是“附件”，而是：
    • 有模板、有版本、有审阅、有签核、有追溯链路（关联需求/任务/版本）

C. 工作图谱（Work Graph）+ 自动汇报（Auto Reporting）

  • 系统底层构建“工作图谱”：
    • 需求 ↔ 任务 ↔ 缺陷 ↔ 节点 ↔ 交付物 ↔ 代码提交 ↔ 发布版本
  • 报表不靠填：
    • 基于图谱事实自动生成：项目健康度、风险雷达、资源冲突、交付物完整率

6. 产品范围（范围边界清晰）

6.1 必做（MVP 必须闭环）

  • 需求管理：多渠道收集→评审→拆解→进入迭代/看板
  • 项目执行：看板/迭代/依赖/阻塞/提醒
  • 节点管理：里程碑模板 + DoD + 升级机制
  • 输出管理：交付物清单 + 模板 + 版本 + 审阅/签核
  • IM 集成：企业微信/飞书（至少一种先落地）对话创建/更新/汇报
  • 报告自动生成：周报、里程碑状态、风险清单

6.2 可选增强（Beta/GA）

  • 资源管理：容量规划、跨项目冲突检测、关键路径与预测
  • DevOps 集成：GitHub/GitLab/Jenkins 等（自动关联提交/PR/构建/发布）
  • 知识库：内置轻量 Wiki 或对接 Confluence/飞书文档
  • 自动化规则引擎：可视化规则 + AI 生成规则
  • 审计与合规：审计日志、数据留存策略、SSO/SCIM（中型企业需要）

7. 信息架构（IA）与导航

mindmap
  root((PM Agent))
    工作台
      我的待办
      今日节点
      风险雷达
      需要我确认
    需求
      需求池
      评审
      变更影响
    项目
      看板
      迭代
      时间线
      里程碑/节点
      交付物
      文档
    项目集
      路线图
      资源负载
      跨项目风险
    报表
      周报自动生成
      项目健康度
      交付物完整率
    管理
      成员与权限
      工作流与字段
      集成与API
      自动化规则
      审计与安全

8. 核心概念模型（工作图谱）

8.1 核心对象（Entity）

  • 组织（Org）
  • 空间/工作区（Workspace）
  • 项目（Project）
  • 工作项（Work Item）
    • 类型：需求（Requirement）、史诗（Epic）、用户故事（Story）、任务（Task）、缺陷（Bug）、风险（Risk）、节点（Node）、交付物（Deliverable）
  • 版本（Release）
  • 迭代（Sprint）
  • 文档（Doc）
  • 评论/讨论（Comment/Thread）
  • 关系（Link）
    • 依赖、阻塞、关联、重复、父子、与交付物绑定等

8.2 关键关系（Graph Links）

  • 需求 → Epic/Story（拆解）
  • Story/Task → Node（节点约束：必须在哪个节点前完成）
  • Node → Deliverable（节点验收依赖交付物）
  • Deliverable → Doc/附件/链接（承载）
  • Work Item ↔ Code/PR/Build（外部事实）
  • Release ↔ Node/Work Item/Deliverable（版本闭环）

9. 关键业务流程（端到端闭环）

9.1 需求→交付闭环（主流程）

flowchart TD
  A[多渠道输入: IM/表单/导入] --> B[需求池: 去重/分类/补全]
  B --> C[评审: 决策/优先级/范围]
  C --> D[智能拆解: Epic/Story/Task + 验收标准]
  D --> E[计划: 迭代/里程碑/依赖/负责人]
  E --> F[执行: 看板/阻塞/提醒/自动更新]
  F --> G[节点验收: DoD + 交付物清单]
  G --> H[版本发布: Release Notes 自动生成]
  H --> I[复盘: 指标回溯 + 经验沉淀]

9.2 节点（里程碑）闭环（节点 = 交付门）

flowchart LR
  N[节点模板: 例如"提测"] --> S[节点实例: 项目A-提测]
  S --> C1[验收标准DoD]
  S --> D1[必需交付物清单]
  S --> R1[升级机制/超期策略]
  D1 -->|未齐全| Block[节点不可关闭]
  D1 -->|齐全+签核| Close[节点关闭并触发下一节点]

10. 功能需求（详细）

10.1 工作台（个人/角色视角）

目标：把“管理输入”压缩为少量确认动作

  • 我的待办：来自任务、节点、审批、@提及、风险处置
  • 今日节点：今天到期/未来 7 天的关键节点
  • 风险雷达：按严重度排序；显示建议动作与责任人
  • 需要我确认：AI 生成的拆解/周报/变更影响，待一键确认/修改

验收标准

  • 角色切换后，工作台内容与权限一致
  • 任何一个“需要我确认”可在 IM 内完成确认与回写

10.2 需求管理（Requirement OS）

10.2.1 需求池（Intake）

  • 输入方式：
    • IM：@PM Agent + 自然语言
    • Web：需求表单（可嵌入企业微信/飞书）
    • 导入：CSV/Excel/第三方系统导入
  • AI 处理：
    • 去重/聚类（相似需求合并候选）
    • 自动补全（用户、场景、收益、风险、依赖）
    • 自动生成“需求卡”与“待澄清问题列表”（但不以问句形式打扰用户：转为待确认项）

10.2.2 评审（Review）

  • 评审会议模式：
    • IM 评审：卡片投票/确认（通过/拒绝/延期/需补充）
    • 会议纪要自动生成（决策、行动项、owner、DDL）
  • 评审输出：
    • 优先级（P0/P1/… 或 WSJF）
    • 目标版本/里程碑建议
    • 需求范围（In/Out）
    • 验收标准草案（AC）

10.2.3 需求变更与影响分析（Change Impact）

  • 变更类型：
    • 范围变更、优先级变更、节点日期变更、依赖变更
  • 影响分析输出（自动）：
    • 影响的节点列表（延迟/冲突）
    • 影响的交付物清单（需要补充/重审）
    • 影响的工作项（需要重排/重估）
    • 风险提示与建议动作（如加人、降范围、拆版本）

验收标准

  • 任意需求变更触发影响分析并生成“待确认变更包”，确认后自动回写相关对象

10.3 项目执行（Scrum/Kanban/混合）

10.3.1 项目模板

  • Scrum：迭代、故事点、燃尽、回顾
  • Kanban：WIP 限制、累计流、吞吐
  • 混合：迭代 + 看板并存（常见于互联网中型团队）

10.3.2 看板（Board）

  • 列 = 状态；支持自定义工作流
  • 卡片字段最小集：
    • 标题、类型、优先级、负责人、截止时间、节点约束、阻塞原因、关联交付物
  • AI 自动更新：
    • 从 IM“我做完了/卡住了/需要XX”识别状态变化候选
    • 从代码/PR/构建结果联动状态（若接入 DevOps）

10.3.3 迭代（Sprint）

  • 容量管理：
    • 个人/团队容量（人天、故事点）
    • 自动检测超载并给出拆分建议
  • 迭代仪式：
    • 日报：自动生成 standup 摘要（昨日/今日/阻塞）
    • 周报：自动生成迭代进展与风险
    • 回顾：自动聚合问题与数据（延期原因、返工点）

验收标准

  • 迭代内工作项状态变化可追溯（来源：手动、AI 建议确认、集成事件）
  • 看板与时间线与节点状态一致

10.4 节点管理（Node Management｜本PRD核心差异）

10.4.1 节点模板库（组织级）

  • 常用模板：
    • 需求评审完成
    • 方案评审完成（技术/设计）
    • 联调完成
    • 提测
    • 测试完成
    • 灰度发布
    • 全量发布
    • 验收/结项
  • 模板包含：
    • DoD（Definition of Done）
    • 必需交付物清单（如：接口文档、测试报告、发布说明）
    • 节点 owner 角色（PM/研发TL/测试TL）
    • 升级链路（超期自动升级到谁）
    • 风险规则（触发条件与提示文案）

10.4.2 节点实例（项目级）

  • 节点健康度（自动计算）：
    • 进度：剩余天数 vs 完成度
    • 风险：阻塞项数量、严重度
    • 输出：交付物完整率
  • 节点关闭机制：
    • 必需交付物齐全 + 关键人签核（可选）→ 允许关闭
    • 未满足 DoD → 系统禁止关闭并给出差距清单

10.4.3 升级机制（Escalation）

  • 超期规则：
    • T-2 天提醒 owner
    • T 天提醒项目负责人
    • T+1 自动升级到项目集负责人/部门负责人
  • 升级内容（自动生成）：
    • 当前节点差距清单
    • 影响范围（影响的后续节点/版本）
    • 三种可选策略（降范围/拆版本/加资源）与建议

验收标准

  • 节点关闭必须基于交付物与DoD，而非纯手动
  • 升级机制在 IM 内可直接一键确认行动项并回写

10.5 输出管理（Deliverable Management｜本PRD核心差异）

10.5.1 交付物类型（组织级）

  • PRD / MRD
  • 技术方案 / 架构图
  • API 文档
  • 测试计划 / 测试报告
  • 埋点方案 / 指标验收报告
  • 发布说明（Release Notes）
  • 验收记录 / 复盘报告

10.5.2 交付物实例（项目/版本级）

  • 元数据：
    • 类型、所属项目/版本、owner、状态（草稿/评审中/已批准/冻结/归档）
    • 关联节点（必须在哪个节点前完成）
    • 关联工作项（哪些需求/任务/缺陷支撑它）
  • 版本化：
    • v0.1/v0.2…，支持差异对比与回滚
  • 审阅/签核：
    • IM 卡片发起审阅：一键通过/驳回/评论
    • 驳回自动生成“修订任务”并绑定回交付物

10.5.3 输出包（Output Package｜用于管理层汇报/交付）

  • “版本输出包”自动汇总：
    • 本版本的交付物链接集合
    • 关键节点完成证明
    • 风险与遗留项
    • 发布说明与回滚预案（如接入 DevOps 可自动生成）

验收标准

  • 任意版本输出包可一键生成并在 IM 内分享
  • 输出包内所有交付物均可追溯到对应节点与需求

10.6 报表与管理输出（Auto Reporting）

10.6.1 周报（自动）

  • 项目周报模板（可组织配置）：
    • 本周完成（按需求/任务/缺陷/交付物）
    • 节点状态（绿/黄/红 + 差距）
    • 风险清单（含建议动作与owner）
    • 下周计划（由迭代与节点自动推导）
  • 生成方式：
    • 每周固定时间自动生成草稿 → 负责人在 IM 内一键确认/微调

10.6.2 项目集视角（Portfolio）

  • 路线图（Roadmap）：跨项目里程碑对齐
  • 资源负载：按角色/团队统计未来 2–6 周负载
  • 风险热力图：按影响面与严重度聚合

验收标准

  • 周报生成不依赖人工填写字段，来源为系统事实与集成事件
  • 管理层看板的口径一致（可追溯数据来源）

10.7 知识与文档（内置或对接）

  • 内置轻量 Wiki：
    • 页面树、模板、与工作项互链
  • 对接模式：
    • Confluence/飞书文档/腾讯文档：作为交付物承载，系统保留元数据与追溯

10.8 自动化规则（Rules）

  • 规则结构：触发器（事件）+ 条件 + 动作
  • 典型内置规则：
    • “任务阻塞超过48小时 → 自动生成风险并@负责人”
    • “节点T-2天 → 自动提醒并生成差距清单”
    • “交付物被驳回 → 自动生成修订任务并回填节点”

11. 智能体系统设计（AI 不是功能点，是运行机制）

11.1 智能体矩阵（多智能体协作）

  • PM Agent（主智能体）：项目推进、节点、周报、升级
  • Requirement Agent：需求补全、去重、拆解、影响分析
  • Schedule Agent：计划与预测、关键路径、资源冲突
  • Risk Agent：风险识别、风险分级、建议动作、闭环跟踪
  • Delivery Agent：交付物模板生成、审阅流转、输出包生成
  • Integration Agent：对接企业微信/飞书与DevOps、同步异常处理
  • Knowledge Agent：知识沉淀、复盘提炼、可复用模板提取

11.2 智能体的“可执行工具”（Tooling）

必须具备可控的工具调用（函数调用/工作流），而不是只聊天：

  • CRUD：创建/更新/查询/关联工作项、节点、交付物
  • 规则引擎：生成规则草案、模拟影响
  • 图谱查询：依赖链、影响面、追溯链
  • 集成读取：PR/构建/发布状态、文档链接、IM 消息上下文
  • 输出生成：周报、风险通报、变更包、输出包

11.3 人在回路（Human-in-the-loop）策略（关键）

  • L0：纯自动（低风险动作，如生成草稿、提醒）
  • L1：需确认（创建任务、变更节点日期、升级风险级别）
  • L2：需审批（关闭关键节点、冻结交付物版本、发布输出包）

11.4 权限与数据隔离（避免“AI越权”）

  • AI 访问遵循用户权限与对象权限
  • 输出时自动脱敏：
    • 跨部门/跨项目汇报只输出允许字段
  • 所有 AI 关键动作可审计：谁触发、基于哪些事实、做了什么变更

12. 企业微信/飞书集成方案（对话=操作）

12.1 核心交互形态

  • @ 提及：@PM Agent …
  • 交互卡片：
    • 需求卡、任务卡、节点卡、交付物卡、周报卡、风险卡、变更包卡
  • 快捷指令（可配置别名）：
    • “创建需求 / 拆解 / 拉周报 / 查节点 / 升级风险 / 生成输出包”

12.2 IM 内典型闭环示例（文本化）

示例：节点差距确认

  • PM Agent 在群里发“提测节点差距卡”
    • 缺口：测试计划未批准、接口文档未更新、阻塞Bug 2个
    • 按钮：生成行动项 / 调整节点日期 / 升级风险
  • 点击 生成行动项：
    • 自动创建 3 个任务，分配 owner 与 ddl
    • 回写到节点差距清单

13. 权限模型（100–1000人必须做严谨）

13.1 角色

  • 组织 Owner
  • 组织 Admin
  • 项目 Owner / PM
  • 成员（研发/测试/设计/运营）
  • 访客（外部合作方）

13.2 权限维度

  • 空间级：是否可见哪些项目
  • 项目级：可读/可写/可管理
  • 对象级：交付物、节点、风险的可见范围
  • 字段级：成本、人事、合同等敏感字段（可选）

14. 非功能需求（SaaS必须可用可控）

  • 性能：关键列表/看板加载 < 2s（P95）
  • 稳定性：核心 API 99.9% SLA（阶段目标）
  • 安全：
    • 多租户隔离
    • 传输与存储加密
    • 审计日志
  • 合规（按客户等级逐步）：数据留存、导出、权限审计、SSO

15. 数据模型（最小可用版）

15.1 WorkItem（工作项）

  • id, type, title, description
  • status, priority, assignee, watchers
  • due_date, estimate, remaining
  • links[]（依赖/阻塞/关联/父子）
  • node_id（约束节点）
  • deliverable_ids[]
  • external_refs（PR/commit/build 等）

15.2 Node（节点）

  • id, template_id, name
  • owner, due_date, status
  • dod_checklist[]
  • required_deliverables[]
  • health_score（自动）
  • escalation_policy

15.3 Deliverable（交付物）

  • id, type, title
  • owner, status, version
  • content_ref（文档链接/附件）
  • review_flow（审阅记录）
  • bound_nodes[]
  • bound_workitems[]

16. 交互原型草图（文本线框）

16.1 Web：项目主页（Project Overview）

┌──────────────────────────────────────────────────────────┐
│ 项目：Phoenix v2.3        健康度：🟡       负责人：Alice    │
├──────────────────────────────────────────────────────────┤
│ 关键节点（未来14天）                                        │
│ [提测 01/25  完成度 70%  差距 3] [灰度 02/01  完成度 20%]     │
├──────────────────────────────────────────────────────────┤
│ 交付物（版本输出包）                                        │
│ PRD v1(已批)  API文档(待更)  测试报告(草稿)  发布说明(待生成)  │
├──────────────────────────────────────────────────────────┤
│ 风险雷达（Top 5）                                           │
│ R1: 联调阻塞(高) owner:Bob  建议:拆分接口+临时Mock             │
├──────────────────────────────────────────────────────────┤
│ 执行区：看板 / 迭代 / 时间线 / 依赖图 / 报表                   │
└──────────────────────────────────────────────────────────┘

16.2 IM：周报卡（示意）

[项目周报｜Phoenix v2.3｜自动生成草稿]
- 本周完成：Story 12 / Bug 31 / 交付物 2
- 节点状态：
  - 提测：🟡（差距：测试计划未批、阻塞Bug 2）
- 风险：
  - R1 联调阻塞（高）→ 建议动作已生成（3项）
[按钮：一键确认发布] [按钮：要求补充] [按钮：升级风险]

17. 计费与套餐（面向100–1000人的现实打法）

目标：避免“按功能拆得过碎”，同时把 AI 价值与交付闭环绑定到可计费单元。

17.1 套餐建议（示例）

  • Standard（100–300人）：项目/需求/节点/交付物 + IM 操作 + 基础报表 + 基础 AI（草稿+建议）
  • Pro（300–1000人）：项目集/资源冲突/高级报表 + 高级 AI（自动周报、影响分析、输出包）+ 审计日志
  • Enterprise（私有化/强合规）：SSO/SCIM、数据域隔离、专属模型策略、专属支持

17.2 计费维度（建议）

  • Seat（协作人数）+ AI 动作包（高价值动作：拆解、影响分析、输出包生成、自动周报）
  • 外部协作方（Guest）不计费或低价（降低协作摩擦）

18. MVP 里程碑（不讨论日期，只给交付边界）

18.1 MVP（最短闭环）

  • IM：创建需求/任务、节点差距卡、周报草稿卡、确认回写
  • Web：项目看板、节点列表、交付物列表、版本输出包生成
  • AI：需求补全、拆解建议、周报生成、节点差距与风险建议
  • 基础权限：项目级读写、交付物审阅

18.2 Beta（可规模化）

  • 项目集视角、跨项目风险聚合
  • 自动化规则引擎（可视化+AI生成）
  • DevOps 基础集成（PR/构建状态回写）
  • 更完整审计与导出

19. 风险与对策（产品级）

  1. AI幻觉导致错误动作
  • 对策：关键动作 L1/L2 必须确认；输出必须附“依据事实列表”（可点击查看来源对象）
  1. 越权与信息泄露
  • 对策：严格权限裁剪；跨项目默认脱敏；所有AI访问与生成可审计
  1. 组织不愿改变习惯
  • 对策：不强迫迁移；先从“周报自动化+节点差距”切入；IM内操作降低学习成本
  1. 集成碎片化
  • 对策：先做企业微信/飞书一种深度闭环；DevOps 用最小集成（PR/构建/发布）起步

20. 附录：可复用模板（示例）

20.1 节点模板（提测）

  • DoD：
    • 测试计划已批准
    • 测试环境可用且联调通过
    • P0/P1 阻塞缺陷清零或有批准豁免
  • 必需交付物：
    • 测试计划
    • 接口文档（冻结版）
    • 提测清单（版本输出包的一部分）
  • 升级机制：
    • T-2 提醒 owner
    • T 当天提醒负责人
    • T+1 升级到项目集负责人

20.2 交付物模板（Release Notes）

  • 本次版本目标
  • 功能变更列表（按需求/模块）
  • 风险与限制
  • 回滚预案
  • 验收人/时间戳

参考公开信息（用于竞品对齐）