行业知识 · v2.3.0 · 资料核对 2026-10-03

AI 产品经理与 AI 项目经理日常工作 SOP

在交互知识库中阅读下载 Markdown 原文

本文访谈与抽样数量是工作节奏样例；真实数量按任务风险、覆盖和统计把握度确定。每日关注严重错误/权限/成本异常，每周审阅任务轨迹与知识变化，每月对账质量/收益/费用，每季度复核法域、供应商、恢复与退役证据。方法见 行业基线。

目的：把“知道应该做什么”变成“每天真的会做”。本 SOP 同时覆盖 AI 产品经理与 AI 项目经理；同一人兼任时，也应把产品决策和项目控制分开记录。

1. 两个岗位每天分别在守什么

共同原则：不靠“感觉不错”推进；每个关键判断都尽量关联用户证据、评测证据、业务证据或交付证据。

2. 每日开工前的 15 分钟

按以下顺序检查，不要一上班就被聊天消息牵着走。

1. 查看线上告警、前一日核心指标和异常波动。
2. 查看高风险失败样本：安全、隐私、事实错误、错误执行、投诉。
3. 查看当天必须形成决定的事项，而不只是会议列表。
4. 查看项目关键路径、阻塞项和临近承诺日期。
5. 选出当天最重要的三个结果，写进工作日志。

建议的每日三问：

• 今天不完成什么，会直接影响用户、收入、安全或里程碑？
• 今天有哪些判断必须用样本或数据验证？
• 今天有哪些模糊责任需要明确到一个负责人和一个日期？

3. 一个标准工作日示例

这不是固定日历。关键在于每天都要留出不被会议切碎的深度工作时间，并持续接触真实用户与真实失败样本。

4. 每日指标巡检 SOP

4.1 先看护栏，再看增长

推荐顺序：

1. P0/P1 安全或合规事件。
2. 服务可用性、错误率与严重延迟。
3. 任务成功率及其置信区间。
4. 关键错误类型的发生率。
5. 用户采用、留存、完成漏斗。
6. 单次成功任务成本、毛利或预算消耗。
7. 用户主观满意度与投诉。

4.2 看到波动后的五步处理

1. 验证数据是否正确：埋点、口径、样本量、发布时间是否变化。
2. 定位影响范围：全部用户、某模型、某地区、某版本还是某类任务。
3. 判断严重度：用户伤害、不可逆动作、商业损失、合规风险。
4. 采取止血措施：降级、关闭功能、切回模型、限制权限或增加人工确认。
5. 建立后续行动：根因、负责人、完成时间、复发预防与验证方式。

5. 失败样本巡检 SOP

每天至少抽查一组真实任务；高风险产品应建立值班和强制抽检。

5.1 样本抽取结构

• 随机样本：防止只看到投诉。
• 低评分或重试样本：发现体验失败。
• 高价值任务：发现商业关键问题。
• 高风险任务：发现安全、隐私与误操作。
• 新版本/新模型样本：发现回归。
• 长尾与边界样本：发现覆盖不足。

5.2 每个失败样本记录

样本编号：
用户目标：
输入与上下文：
系统行为：
期望行为：
错误类型：
严重度：
是否可稳定复现：
可能根因：产品 / Prompt / 检索 / 工具 / 模型 / 数据 / 权限 / UI / 其他
临时处置：
长期修复：
负责人和日期：
是否加入回归评测集：是 / 否

5.3 错误处理纪律

• 不用一个精彩案例代表总体质量。
• 不只修 Prompt；先判断是否是输入、检索、工具、模型或交互问题。
• 用户已经造成严重损失的错误，优先级高于发生频率低所带来的“统计安慰”。
• 每个修复过的重要错误都应进入回归集，防止下个版本重新出现。

6. 站会 SOP

站会控制在 15–20 分钟。每人只回答：

1. 昨天交付了什么可验证结果？
2. 今天承诺交付什么？
3. 当前阻塞是什么，需要谁在何时提供什么？
4. 是否出现新的风险、范围变化或质量异常？

不在站会上做长讨论。需要讨论的议题会后拉必要人员，形成结论后回写决策日志。

7. 用户接触 SOP

7.1 每周最低接触量

按产品阶段调整，但不能长期为零：

• 探索期：每周 5–8 个访谈或现场观察。
• 验证期：每周 3–5 个任务测试，并跟踪未采用者。
• 上线期：每周抽查客服、一线销售、运营和用户反馈。
• 规模期：定量行为数据与定性研究并行，持续覆盖不同用户分层。

7.2 访谈不问“你想要什么 AI 功能”

重点问：

• 最近一次完成这个任务是什么时候？
• 从开始到结束做了哪些步骤？
• 哪一步最慢、最贵、最容易错？
• 现在使用什么替代方案，为什么还在用？
• 错误发生时有什么后果，谁承担后果？
• 哪些信息不能交给系统？哪些动作必须人工确认？
• 什么结果会让你愿意持续使用或付费？

8. PRD 与方案推进 SOP

任何 AI 需求进入研发前，至少明确：

• 用户与任务，而不是宽泛的“做一个 AI 助手”。
• 当前基线：人工、规则、搜索、旧模型或竞品的表现。
• 输入、输出、上下文、数据来源与权限。
• 质量标准、业务指标、护栏指标与成本上限。
• 不处理的场景和失败时的降级路径。
• 人工确认点、可撤销性和审计要求。
• 离线评测集、线上实验和验收方案。
• 依赖、风险、灰度、回滚和运营责任。

未明确上述内容时，不以“先开发看看”代替产品判断；可以安排时间盒原型或 Spike，但要明确要消除哪项不确定性。

9. 实验评审 SOP

实验前

• 写清假设和最小有意义提升，不在看到结果后改目标。
• 明确实验单位、分流方式、周期、样本量与排除条件。
• 同时设置主指标、诊断指标和护栏指标。
• 确认不同模型版本、提示词和配置可以追溯。

实验中

• 不因短期波动频繁停止实验。
• 监控安全事件、严重错误和数据质量。
• 记录并控制同期发布、节假日、流量结构变化等干扰。

实验后

• 同时看统计显著性、实际效应和用户分层。
• 分析失败样本，不用均值隐藏高风险尾部。
• 形成采用、继续实验、回滚或停止的明确决定。
• 把结论和可复用知识写入实验档案。

10. 会议操作系统

会前

• 说明会议类型：同步、评审、决策、问题解决或复盘。
• 给出预读材料、要做的决定、决策人和准备要求。
• 没有明确目标的会议优先取消或异步处理。

会中

• 先复述事实与约束，再讨论方案。
• 区分“事实、假设、偏好、风险”。
• 对关键争议明确需要什么证据才能消除。
• 在结束前确认决定、负责人、截止日期和复查条件。

会后

在当天更新：

决定：
决策人：
依据：
被否决方案及原因：
风险与保护措施：
负责人：
截止日期：
何时/在什么条件下复查：

11. 决策日志 SOP

需要记录的决定包括：模型切换、架构选择、重要范围变更、质量阈值、上线/回滚、预算调整、风险接受和例外审批。

一条合格的决策记录应允许三个月后的新人回答：

• 当时要解决什么问题？
• 有哪些方案？
• 为什么选这个？
• 基于哪些当时已知的事实和假设？
• 什么信号出现时要推翻这个决定？

12. 项目风险与依赖巡检 SOP

每日看板

风险条目

风险事件：如果……可能导致……
概率：低 / 中 / 高
影响：低 / 中 / 高 / 灾难性
触发信号：
预防措施：
应急方案：
风险责任人：
复查日期：
当前状态：开放 / 观察 / 已发生 / 关闭

升级条件

• 关键路径无可行替代且即将影响承诺。
• 高风险数据、模型、安全或合规问题没有明确责任人。
• 范围增加但资源、时间或质量目标未调整。
• 关键依赖连续两个检查周期无进展。
• 团队在同一问题上反复讨论但决策权不明确。

升级时带上事实、影响、已尝试动作、可选方案和希望对方做出的决定。

13. 需求与优先级管理 SOP

需求进入池前

至少回答：谁在什么场景遇到什么问题、当前如何解决、证据是什么、解决后有什么价值、为何现在做。

排序时

综合考虑：

• 用户价值与受影响任务频率。
• 商业价值与战略一致性。
• 风险降低和合规必要性。
• 证据强度与成功可能性。
• 工程、数据、运营和组织成本。
• 学习价值与可逆性。
• 对关键路径和其他项目的影响。

每周清理

• 合并重复项。
• 删除没有负责人或没有证据的僵尸需求。
• 把“想法”与“已承诺交付”分开。
• 明确每个进行中事项的退出条件。

14. 线上事故前 30 分钟 SOP

1. 确认指挥人和记录人。
2. 判断影响范围、严重度与是否仍在扩大。
3. 优先止血：关闭高风险动作、降级、回滚、限流或切换备用方案。
4. 保存必要日志、版本、输入输出与时间线，避免破坏证据。
5. 通知必要的技术、安全、法务、客服和业务负责人。
6. 设置下一次同步时间；不要让多人各自猜测状态。
7. 对外沟通只发布确认事实，不承诺尚未验证的恢复时间。

事故稳定后再做完整根因分析。不要在止血阶段争论归责。

15. 周节奏

周一：校准

• 复核本周结果目标和关键路径。
• 确认实验、发布、访谈和评审安排。
• 检查上周未关闭的高风险问题。
• 明确本周必须做出的三项关键决定。

周中：证据与纠偏

• 看用户研究和失败样本是否改变原假设。
• 检查迭代是否在追指标而忽略真实任务。
• 对延期风险做范围、资源或时间的显式取舍。

周五：闭环

• 本周交付了什么结果，不只列活动。
• 哪些指标变化可归因，哪些仍只是相关。
• 新增了哪些错误模式和回归样本。
• 哪些决策需要被记录或复查。
• 下周最大的风险和首要任务是什么。

16. 月度与季度节奏

每月

• 复盘 North Star、采用、留存、质量、安全、延迟、成本和收入。
• 更新错误分类、评测集和高风险场景覆盖。
• 复查模型、数据、供应商、算力和人工运营成本。
• 清理产品债、技术债、评测债、数据债和合规债。
• 复核关键风险、例外审批和整改状态。

每季度

• 检查 ICP、核心任务和战略假设是否仍成立。
• 重排产品组合：加码、保持、试验、停止。
• 复查 Build / Buy / Partner 选择。
• 更新能力地图、人员缺口与合作方式。
• 进行灾备、回滚、安全或人工接管演练。
• 确定下一季度最重要的学习目标，而不仅是功能列表。

17. 一人兼任两个岗位时

为避免“既做决定又证明自己进度正常”，至少分开维护：

重大上线建议设置独立技术、业务或风险审批人，避免单人闭环造成盲点。

18. 新人前 30 天行动表

第 1 周：理解系统

• 完成产品体验与核心用户任务地图。
• 认识所有关键角色及决策权。
• 阅读近三个月指标、事故、用户反馈和决策记录。
• 跟随一次用户或一线团队真实工作过程。

第 2 周：理解证据

• 手工审查 50–100 个代表性样本。
• 复核核心指标口径与评测集结构。
• 画出数据、模型、检索、工具和权限链路。
• 列出十个最大未知数与验证方式。

第 3 周：承担一个闭环

• 选择一个边界清晰的问题。
• 定义基线、目标、护栏和验收。
• 推进一次原型、实验或小范围迭代。
• 完成从决策到复盘的完整记录。

第 4 周：提出改进

• 给出用户、质量、成本、风险和项目管理五方面诊断。
• 明确三项近期改进和一项中期能力建设。
• 与负责人校准优先级和成功标准。

19. 每日收工检查清单

• [ ] 今天是否看过真实用户行为或真实失败样本？
• [ ] 今天最重要的决定是否留下依据？
• [ ] 每个关键行动是否有唯一负责人和日期？
• [ ] 新风险是否进入台账，而不是只留在聊天记录里？
• [ ] 项目范围、时间、资源、质量之间的取舍是否显式？
• [ ] 明天第一件最重要的事是否清楚？
• [ ] 是否有应该停止、取消或异步化的工作？

20. 相关模板

可直接使用：模板工具箱，并结合项目检查清单与决策速查表。