项目管理与迭代
项目管理与迭代
项目管理保证产品按时、按质交付。AI 产品的项目节奏与确定性软件有明显差异——它管理的主要对象是不确定性：模型效果不确定、用户输入不确定、成本不确定。所以 AI 项目管理不是更严格的排期，而是一套在不确定性下持续校准价值与交付节奏的系统。
先厘清：项目、项目管理与软件工程
项目（Project）：为创造独特产品、服务或成果而进行的临时性工作——有明确的起止时间、目标与资源约束（PMBOK 定义）。它是跨行业的通用容器：建筑、活动、科研、软件开发都用项目管理来组织。
软件工程（Software Engineering）：系统化开发与维护软件的工程学科——需求工程、架构设计、测试、质量保证与过程管理（瀑布/敏捷等）。软件工程不是"项目的一种"，而是软件开发这门"手艺"；软件开发（工作）以项目形式组织，项目是工程实践的载体。
| 概念 | 本质 | 回答什么问题 | 跨行业 |
|---|---|---|---|
| 项目 | 组织工作的临时容器 | 怎么组织一群人按时按质交付 | 是 |
| 项目管理 | 管范围、时间、成本、干系人的方法论 | 交付过程如何受控 | 是 |
| 软件工程 | 软件领域的工程学科 | 怎么正确、可靠、可维护地造出软件 | 否 |
关系一句话：软件开发项目 = 项目管理 × 软件工程 × 领域知识。项目里的范围、时间、成本管理，软件工程不负责；软件工程里的架构、测试、质量实践，项目管理也覆盖不到。产品经理要懂的是两者的分工——项目管理管"按时按质"，软件工程管"造得对不对"；具体要懂到哪一层，见 能力模型中的软件工程素养。
项目类型与治理强度
不同项目类型的治理强度差异巨大——把 AI 项目一律按"互联网迭代"或一律按"交付项目"管，都会出事。先分类再定治理：
| 类型 | 典型例子 | 周期 | 文档强度 | 评审强度 | 发布频率 | 风险接受度 |
|---|---|---|---|---|---|---|
| 探索型 | 0→1 的 AI 功能验证 | 2~6 周 | 低（实验笔记 + 评测集） | 高频轻评审 | 周级 / 随时 | 高（允许试错） |
| 特性型 | 成熟产品加 AI 能力 | 1~3 月 | 中（PRD + 评测标准） | 评审门禁 | 双周 ~ 月级 | 中 |
| 平台型 | AI 平台 / API 服务 | 季度级 | 高（契约与兼容文档） | 架构评审 | 版本化发布 | 低（向后兼容） |
| 企业交付型 | 定制 AI 系统、合规项目 | 3~12 月 | 很高（合同、SLA、验收标准） | 阶段门禁 | 里程碑 | 很低 |
| 模型 / 基础设施型 | 训练、评测平台、推理优化 | 半年 ~ 年 | 高（研究日志 + 评测报告） | 科学评审 | 模型版本 | 中（实验分层） |
治理强度怎么定：风险越高、外部承诺越硬，文档与评审越重。探索型项目用"实验记录 + 周评审"就够，硬套阶段门禁会扼杀探索；企业交付型没有门禁，会赔上合同与合规。
双轨迭代
Continuous Discovery 与 Delivery 并行
Marty Cagan 在《启示录》里的核心主张：发现（discovery）与交付（delivery）是两条并行轨道，不是先规划后执行。发现轨道验证"该不该做"，交付轨道保证"做出来能用"：
| 轨道 | 干什么 | 节奏 | 产出 |
|---|---|---|---|
| 发现轨道 | 访谈、原型、假门测试、绿野仙踪 | 每周 2~3 次定性测试 | 已验证的想法 + 评测用例 |
| 交付轨道 | 把已验证的想法做成可发布功能 | 固定迭代（1~2 周） | 可发布的产品增量 |
合流点：每个迭代开始时，把发现轨道上"已验证"的想法排进交付 backlog；迭代结束时，交付轨道带回真实数据，重新喂给发现轨道。合流失败的症状：发现轨道自嗨（做了一堆没进 backlog 的原型），或交付轨道自嗨（做的功能没经过任何验证）。
发现轨道的常用方法（按成本从低到高）：客户访谈与门童测试（验证问题真伪）→ 假门 / 落地页测试（验证需求强度）→ 绿野仙踪（人工冒充 AI 验证价值假设，详见 产品设计与原型 的原型策略）→ 可行性原型（小样本跑通 RAG / Agent 链路，验证 AI 的可行性风险）。规则：发现轨道只产出"已验证的想法 + 评测用例"，不产出代码——代码留给交付轨道。
流程选型决策表
| 场景 | 选型 | 理由 |
|---|---|---|
| 需求高度不确定、想法多 | Kanban（拉式 + WIP 限制） | 不承诺固定范围，按价值拉取 |
| 跨职能承诺、固定节奏交付 | Scrum（2 周 sprint） | 节奏感强，评审点固定 |
| 创意型团队、大块功能 | Shape Up（6 周 + 2 周冷却） | 大块时间盒，避免无休止打磨 |
| 高风险、强合规（企业交付） | 阶段门禁（gate review） | 每个里程碑评审再放行 |
| 维护型 / 支持型工作 | Kanban | 无固定迭代，按优先级流动 |
规则：流程是工具不是信仰。AI 产品常见的选择是"Kanban 做发现、Scrum 做交付"混搭——比二选一更实用。
结果导向路线图
从愿景到承诺的层级
| 层级 | 内容 | 更新频率 | 谁定 |
|---|---|---|---|
| 愿景 | 2~10 年后想创造的未来 | 年 | 创始团队 / 高管 |
| 战略 | 一系列产品/市场契合的序列，一次聚焦一个 | 半年 ~ 年 | 产品负责人 |
| 目标（OKR） | 可衡量的业务结果 | 季度 | 产品团队 |
| 赌注 | 为验证某个假设投入的资源 | 迭代 | 产品团队 |
| 里程碑 | 可检查的中间节点 | 迭代 | 交付团队 |
| 高诚信承诺 | 先做发现、再承诺日期与结果的承诺 | 发现完成后 | 产品负责人 |
路线图不是承诺
《启示录》对"路线图"的批判值得反复读：想法一旦写进名为 roadmap 的文档，全公司就会把它当成承诺——而此刻既不知道能赚多少钱，也不知道成本是多少，商业论证的输入是"无法知道的东西"。替代方案是上面这组层级：愿景负责激励，战略负责聚焦，OKR 负责度量，赌注负责投入，承诺只在发现完成后给出。
OKR 写业务结果，不写输出
| 错误示范（输出） | 正确示范（业务结果） |
|---|---|
| 接入 GPT-5 模型 | 客服一次解决率从 62% 提到 75% |
| 上线 10 个 AI 功能 | 主动咨询的工单占比从 40% 降到 20% |
| 完成评测集建设 | 评测集对线上新问题的通过率 ≥ 85% 且保持 2 个月 |
判据：KR 里不出现"上线 / 接入 / 完成"这类动词，而是出现用户行为或业务指标的变化。AI 特有指标（延迟、token 成本、幻觉率）可以写，但必须挂在业务结果下，而不是自娱自乐。
AI 产品迭代的节奏
与传统开发相比，AI 产品的开发周期有"两快一慢"：
- 验证快：Prompt 调优、模型切换可以在小时级完成
- 上线快：Agent/API 集成比从零写功能快得多
- 评估慢：效果好坏难以自动化判定，回归测试成本高
"评估慢"决定了一切节奏设计：快的是写代码，慢的是证明它好。所以迭代节奏要围绕"评估"来排，而不是围绕"开发"来排。典型的一周节奏：
| 时间 | 动作 |
|---|---|
| 周一 | 跑评测集回归，更新错误模式清单 |
| 周二 ~ 周三 | 修复与开发（数据驱动的改动） |
| 周四 | 灰度发布 + 人工抽检 |
| 周五 | 迭代回顾 + 下一迭代评测集扩充 |
两个节奏信号：评估总是赶不上开发 → 砍开发量或扩评估人力，不要砍评估；连续两个迭代都没有真实用户数据回流 → 停下来说清楚为什么，再决定是否继续。
迭代流程建议
- 定义成功指标：每个迭代明确"好"的标准（准确率、任务完成率、用户留存）
- 建立评测集：把典型用户输入沉淀为评测集，每次改模型/提示词都跑一遍
- 小步快跑：Prompt 调整也要走"改 → 评测 → 上线 → 观察"闭环
- 灰度与回滚：模型输出不可控，必须能做用户级灰度与一键回滚
- 监控线上质量：用户反馈、错误率、幻觉投诉要有监控与复盘机制
迭代规划清单
排每个迭代时逐项过：
| 要素 | 检查问题 |
|---|---|
| 问题选择 | 这个迭代解决哪个已知问题 / 验证哪个假设？ |
| 验收标准 | 评测指标 + 人工抽检阈值写清楚了吗？ |
| 切分方法 | 按代理权切（v1 建议 → v2 执行），还是按用户旅程切？ |
| 容量 | 评测集扩充 + 人工抽检的工时算进容量了吗？ |
| 依赖 | 模型 / 数据 / 法务审批的依赖排了吗？ |
| 技术债 | 本迭代是否欠下新的债（如硬编码规则），记下来了吗？ |
| 发布窗口 | 灰度与回滚窗口是否避开业务高峰？ |
AI 功能迭代计划模板
以"客服工单助手 v2：建议解决方案"为例：
| 任务 | 负责人 | 验收标准 | 时间 |
|---|---|---|---|
| 评测集扩充 | 数据 / 评估 | 新增 20 条真实工单用例，覆盖新输入模式 | D1 ~ D3 |
| 检索与生成改造 | 工程 | 评测集通过率 ≥ 90%，延迟预算达标 | D3 ~ D6 |
| 人工抽检 | PM + 客服代表 | 抽检 50 条，错误率 < 5% | D6 ~ D7 |
| 灰度发布（10%） | 工程 | 转人工率、投诉率不恶化 | D8 |
| 监控与复盘 | 全员 | 出迭代回顾报告，更新错误模式表 | D9 ~ D10 |
模板要点：评测集建设与人工抽检是显式任务，不是"顺便做"——把它们写进计划表，才不会在排期紧张时被砍掉。
CC/CD：AI 产品的生命周期框架
把"两快一慢"与上面的迭代建议串进一个循环：开发（CD）= 划定能力范围（按代理权等级分版本）→ 搭建应用（埋日志、控制交接）→ 设计评测；上线后进入校准（CC）= 运行评测 → 分析错误模式 → 数据驱动修复，下一轮循环再划更高代理权的版本，形成飞轮。像带新同事：从小事开始、观察、建立信任、逐步扩权。
执行系统
节奏定了，还要有日常执行机制。AI 团队的执行系统至少包含六件套：
| 机制 | 频率 | 内容 | 产出 |
|---|---|---|---|
| 每日同步 | 每天 15 分钟 | 阻塞、进展、今日计划 | 阻塞清单 |
| 周会 | 每周 | 上周结果 vs 承诺，下周承诺 | 更新后的计划 |
| Demo | 每周 | 向干系人演示真实效果（不是 PPT） | 干系人反馈 |
| 风险评审 | 每迭代 | 逐条过风险登记册 | 更新的风险表 |
| 决策日志 | 随时 | 决策、理由、备选、owner | 可追溯的决策史 |
| 阻塞升级 | 随时 | 2 小时内无人接 → 升级 | 解决问题的路径 |
| 异步协作 | 随时 | 评测结果入共享文档、demo 录屏、异步评审 | 减少会议依赖，时区 / 排班友好 |
异步协作的约定：结论先行、留痕为王——每个决策都写进决策日志，每次评审都有文档或录屏，评测结果统一入表。AI 团队的评测与抽检工作天然适合异步（跑评测不用开会，看评测结果也不用开会），把会议留给真正需要同步讨论的阻塞与取舍。
DRI 与升级路径
每个高风险区域（模型效果、数据、成本、合规、发布）指定一个 DRI（Directly Responsible Individual，直接负责人）——不是"大家负责"，而是"出事找这个人"。
升级路径要写死：工程师 → 功能 DRI → 产品负责人 → 部门负责人。规则：
- 阻塞超过 2 小时且无解，升级一级（别在群里反复讨论）
- 升级时带上：阻塞什么、试过什么、需要什么决策
- DRI 的职责是决策，不是背锅——决策日志里记录每次升级的结论
范围与承诺管理
MVP 是实验，不是最小产品
《精益创业》的定义：MVP 不是最小的产品，而是最快通过一轮"构建-测量-学习"循环的最小努力版本——目标是验证假设，不是给用户一个功能全集。AI 产品尤其容易违反这条：为 AI 功能做全套产品级工程（评测、合规、全链路），却还没验证价值。正确的顺序是先用原型（绿野仙踪、假门测试）验证价值，再用最小产品验证增长（详见 《精益创业》笔记 与 《启示录》笔记）。
最小切片
- 按代理权切（推荐）：v1 只建议 → v2 需确认执行 → v3 自动执行（对齐 CC/CD 生命周期）
- 按用户旅程切：先做"提问 → 回答"闭环，再做"回答 → 执行"
- 按风险切：先做低风险动作，不可逆动作最后做
Must / Should / Could
| 级别 | 定义 | 判据 |
|---|---|---|
| Must | 没有它功能不成立 | 评测集核心用例无法通过 |
| Should | 重要但不阻塞发布 | 有明确用户价值，可后补 |
| Could | 锦上添花 | 没有它用户说不出来 |
| Won't | 明确不做 | 写进"不做清单"防蔓延 |
范围蔓延与砍功能
蔓延信号：需求讨论代替验收讨论（"顺便加个……"）、Demo 后追加需求、评测标准随实现结果改。
砍功能准则（按优先级）：
- 砍掉不影响核心指标的功能
- 砍掉只有一个人坚持的功能
- 砍掉无法评测的功能（AI 功能尤其：不能评测 = 无法验收 = 不该做）
延期谈判规则：砍范围优先于砍质量，砍质量优先于延期。延期信息越早暴露越好——在迭代第 3 天发现要延期，比第 9 天才说有用十倍。
风险与依赖
四类产品风险 + AI 特有风险
| 风险类型 | 问什么 | AI 场景例子 | 缓解手段 |
|---|---|---|---|
| 价值风险 | 用户愿意用吗 | 客服机器人没人愿意用 | 绿野仙踪、假门测试 |
| 可用性风险 | 用户会用吗 | 提示词交互太复杂 | 可用性测试、错误注入 |
| 可行性风险 | 做得出吗 | 幻觉率压不到可接受水平 | 生产 spike、评测集先行 |
| 商业可行性 | 赚得到钱吗 | token 成本吃掉毛利 | 成本测算、定价实验 |
| 模型风险 | 模型行为稳定吗 | 上游模型升级后行为漂移 | 基线评测、固定版本策略 |
| 数据风险 | 数据够吗、合法吗 | 训练 / 评测数据权限不清 | 数据审计、来源登记 |
| 成本风险 | 成本可控吗 | 上下文增长导致成本非线性上升 | 用量监控、预算护栏 |
| 安全风险 | 会被攻击 / 滥用吗 | Prompt 注入、越权工具调用 | 红队测试、权限最小化 |
| 合规风险 | 合法吗 | 数据出境、内容安全 | 法务前置评审 |
风险登记册模板
| 风险 | 概率 | 影响 | 缓解措施 | Owner | 触发条件 |
|---|---|---|---|---|---|
| 上游模型升级导致效果回退 | 中 | 高 | 固定模型版本 + 基线评测 | 工程 DRI | 评测集通过率下降 > 5% |
| 成本超支 | 中 | 高 | 用量监控 + 预算告警 | 数据 DRI | 单日成本超预算 20% |
| 合规审查未过 | 低 | 很高 | 法务前置评审 | PM | 新数据源接入时 |
每迭代过一遍登记册：概率与影响变了就更新，触发条件达到就执行缓解——登记册是活文档，不是评审 PPT。
依赖管理
AI 产品的依赖比传统软件更多且更难控制：模型 API（能力、限流、价格随时可能变）、数据源（权限、时效、质量）、算力（训练 / 评测跑批的排队）、法务审批（数据合规的周期不可压缩）。规则：外部依赖全部提前两个迭代排期，并在计划模板里显式列一行"依赖"——模型升级、数据接入这类依赖一旦卡住，整个迭代都会停摆，这是 AI 项目最常见的隐性延期源。
干系人与组织
角色分工
| 角色 | 在 AI 产品里的职责 |
|---|---|
| 产品经理 | 问题定义、评测标准、进度与承诺、干系人对齐 |
| 产品设计师 | 交互设计、失败路径、可用性验证 |
| 工程师 | 系统搭建、模型接入、评测自动化、灰度与回滚 |
| 数据 / 评测 | 评测集建设、错误模式分析、质量报告 |
| 法务 / 合规 | 数据合规、内容安全、文案声明审查 |
| 销售 / 解决方案 | 客户承诺管理、POC 与验收 |
| 客服 / 运营 | 转人工承接、用户反馈回流、错误模式一手观察 |
RACI 示例：AI 客服工单助手
| 活动 | PM | 设计 | 工程 | 数据 | 法务 |
|---|---|---|---|---|---|
| 定义评测标准 | A | C | C | R | I |
| 转人工流程设计 | C | A | R | I | C |
| 模型选型与评测 | C | I | R | R | I |
| 数据合规审查 | I | I | C | C | A |
| 发布决策 | A | C | R | C | I |
| 事故复盘 | A | I | R | C | I |
RACI 的关键是每个活动恰好一个 A；冲突升级路径：先在 PM 与对应 R 之间对齐，仍无法解决 → 共同上级决策，决策记录进决策日志。
AI 项目的坑
- Demo 与产品的差距：演示效果很好，上线后真实数据不行——尽早用真实数据测试
- 模型即服务的依赖：上游模型升级可能改变行为，要有基线评测和固定版本策略
- 评测集污染：评测集被优化得过多后失真，需要定期更新评测集
- 合规前置：数据合规、内容安全在 AI 产品里是开发前置条件，不是上线前补的
- 评测通过 ≠ 可以发布：评测集永远覆盖不全，发布还要过灰度、监控与人工抽检（见发布管理）
- 为 AI 而 AI：堆"AI 功能"却没有业务结果——立项时先写价值假设，用 OKR 的业务结果口径验收
- 把评测当一次性工程：评测集要随线上行为持续扩充，两个月不更新就失真
发布管理
发布管理的目标是：把"模型输出不可控"变成"发布过程可控"。对传统软件，发布是终点；对 AI 产品，发布只是进入校准循环的过渡（见 CC/CD 生命周期）——所以发布不是"放出去"，而是"放出去并盯住"。
评测作为发布门禁
把"评测作为发布门禁"写成可执行流程，而不是一句原则：
- 评测集回归：全量评测集通过率 ≥ 阈值（如 90%），失败用例全部归因
- 人工抽检：抽检 50~100 条真实输入，错误率 < 阈值（如 5%），抽检人不能是写代码的人
- 灰度层评测：1% → 10% → 50% → 100% 分阶梯放量，每级检查质量指标（转人工率、投诉率、赞踩比）不恶化
- 门禁记录：每次发布的通过 / 拒绝理由写入发布记录——被拒绝不是失败，是数据
灰度、监控与回滚
| 环节 | 做法 |
|---|---|
| 灰度 | 用户级 / 会话级 / 功能开关三种粒度；先从内部用户开始，再到 1% 外部用户 |
| 监控 | 业务指标（完成率、留存）+ 质量指标（错误率、幻觉投诉、转人工率）+ 成本指标（token 用量）三张表 |
| 回滚 | 提示词版本、模型版本、功能开关三层都可一键回滚；回滚预案在上线前写好 |
| 变更通知 | 影响用户行为的变更提前 3~5 天通知（改能力边界、改默认值必须通知） |
| 48 小时值守 | 上线后 48 小时专人盯监控，重大事故 15 分钟内响应，值守结束出值守报告 |
| 事故复盘 | 时间线 + 影响面 + 五 Whys（见下）+ 行动项，72 小时内完成，行动项有 owner 有期限 |
度量与复盘
输出、结果、学习分开
| 类型 | 定义 | 例子 | 用途 |
|---|---|---|---|
| 输出 | 交付了什么 | 上线 3 个 AI 功能 | 过程管理 |
| 结果 | 用户 / 业务发生了什么变化 | 工单解决率 62% → 75% | 价值判断 |
| 学习 | 验证了什么假设 | "客服愿意用 AI 建议"成立 / 不成立 | 认知积累 |
三个都要记，但只有结果与学习用来判断成败——输出指标好但结果不动的迭代，是浪费。
迭代回顾模板
| 问题 | 引导 |
|---|---|
| 做得好 | 什么值得保持？ |
| 做得差 | 什么浪费了时间 / 信任？ |
| 学到什么 | 验证了什么假设、推翻了什么假设？ |
| 下一步 | 一个行动项，有 owner 有期限 |
五 Whys 的正确用法
《精益创业》的规则：追到系统根因后按比例投资预防，而不是停在"谁干的"。正确示范：
事故：客服工单被 AI 自动回复了错误退款金额。 1 为什么？→ 检索命中了过期的退款政策。 2 为什么？→ 知识库有多个版本，检索没做时效过滤。 3 为什么？→ 知识库版本管理没有过期策略。 4 为什么？→ 评测集里没有"旧政策仍可命中"的用例。 5 为什么？→ 评测集建设没有覆盖知识库变更场景。 行动：给知识库加过期标记 + 评测集补用例。
"五个怪罪"的坑：如果五 Whys 的答案总是"某个人犯了错"，说明问错了——大多数错误由有缺陷的系统造成，而非糟糕的人。预防动作必须指向流程、评测、工具，而不是"下次注意"。
团队配置
一个典型的 AI 产品小组：
- 产品经理：需求、评估标准、进度
- 工程师：系统搭建、模型接入、评测自动化
- 数据/评估人员（可兼职）：评测集建设、质量分析
按组织形态展开的最小配置：
| 组织形态 | 最小配置 | 说明 |
|---|---|---|
| 初创团队 | PM（创始人兼任）+ 2~3 名全栈工程师 + 设计（外包 / 兼职） | 评测与客服由 PM 兼；先跑通闭环再补角色 |
| 大厂功能团队 | 1 PM + 1 设计 + 2~12 名工程师 + 数据 / 评测（可兼职）+ 法务（按需） | 《启示录》标准配置：同地办公、长期稳定、对结果赋权并问责 |
| 企业交付项目 | PM + 交付经理 + 工程 + 解决方案架构师 + 客服 / 运维 | 合同与验收驱动，法务全程参与 |
| 平台团队 | 平台 PM + 技术负责人 + 平台工程师 + 开发者关系 | 兼容性优先，评测与文档是产品本身 |
练习
- 为你的项目设计一个 20 条以内的种子评测集（覆盖典型输入、边界输入、对抗输入）
- 列出你的产品的 3 个核心监控指标
- 为你的产品填一张 5 行的风险登记册（含 owner 与触发条件）
来源说明
以下来源均于 2026-08-23 验证可达；页面可能随时更新。
经典著作与论文
- Marty Cagan, INSPIRED（《启示录》：发现 / 交付双轨、四类风险、路线图批判、高诚信承诺，2018）
- Eric Ries, The Lean Startup（《精益创业》：MVP 是实验、五 Whys、创新核算，2011）
- Teresa Torres, Continuous Discovery Habits（持续发现习惯，2021）
- Ryan Singer, Shape Up（2019）
- PMI, PMBOK Guide（项目管理知识体系，以第 7 版为准）
- Agile Manifesto（2001）、Scrum Guide（2020）
官方文档与博客
- Anthropic Building Effective Agents（Agent 系统的评测与护栏）
- OpenAI Agents Guide（Agent 开发实践）
仓库原创读书笔记与站内页
- 《启示录》精读笔记
- 《精益创业》精读笔记
- 《人人都是产品经理 2.0》精读笔记
- AI 产品开发生命周期（CC/CD）（迭代节奏的循环框架）
- 评估与评测（评测集与线上评估）
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用