技术方案评审
你将学到什么
- 评审会前的准备工作（5分钟扫描法）
- 5 类有效提问框架（目标对齐、用户感知、边界条件、可观测性、回退能力）
- AI 产品技术方案的 4 大特殊检查点
- 4 种常见对话场景的应对策略
- 与工程师建立长期信任的行为准则
为什么重要：评审会上沉默的 PM 和乱提意见的 PM 一样危险——前者被忽视，后者被排斥。掌握正确的提问方式，是 AI PM 的核心技能。
评审会前：准备工作
提前读文档（别等会上才看）
收到技术方案文档后，提前用"5分钟扫描法"（见读懂代码）过一遍：
- ✅ 圈出看不懂的词，会前问清楚（别在会上暴露）
- ✅ 标记与 PRD 有出入的地方，准备对齐
- ✅ 想好你关心的 2-3 个核心问题
经验法则
如果你在会前没有读完技术方案，会上 80% 的时间你都在"听天书"。提前 1 小时读完，会上才能有效参与。
准备你的视角
工程师关注可行性，PM 关注用户体验 + 业务目标。
会上你的核心任务是：
- ✅ 确认方案能达成产品目标
- ✅ 识别用户感知到的风险
- ✅ 确认上线策略和评估方案
常见误区
不要在评审会上质疑技术选型（"为什么不用 X 技术？"），除非你有充分的理由。工程师比你更了解技术约束。
你的价值在于：从产品视角发现工程师可能忽略的用户体验问题。
评审会上：提问框架
五类有效问题
类型 1：目标对齐
提问模板：
"这个方案能解决 [用户痛点 X] 吗？最弱的环节在哪里？"
示例：
"这个方案能保证用户在 3 秒内看到 AI 回答吗？如果模型响应慢，用户会看到什么？"
为什么有效：直接关联产品目标，帮助工程师理解优先级。
类型 2：用户感知
提问模板：
"从用户视角，最坏情况下的体验是什么？出现概率多大？"
示例：
"如果 API 超时，用户会看到空白页还是错误提示？这种情况的发生概率是多少？"
为什么有效：工程师容易关注"平均情况"，PM 需要关注"最坏情况"。
类型 3：边界条件
提问模板：
"[边界场景 X] 时，用户会看到什么？"
示例：
"如果用户输入 10,000 字的文本，系统会怎么处理？是截断、拒绝还是分段处理？"
为什么有效：边界条件是 Bug 的高发区，提前讨论可以避免上线后的紧急修复。
类型 4：可观测性
提问模板：
"上线后，我们怎么知道这个方案是否在正常工作？有哪些监控指标？"
示例：
"我们如何监控 AI 回答的质量？是否有自动化的质量检测？"
为什么有效：没有监控的功能，出问题时无法快速定位。
类型 5：回退能力
提问模板：
"如果上线后发现有问题，回滚的代价是什么？需要多久？"
示例：
"如果新 Prompt 效果不好，能立即切回旧版本吗？还是需要重新发版？"
为什么有效：降低上线风险，给团队留退路。
互动练习：识别问题类型
以下 3 个问题分别属于哪种类型？
- "如果用户连续点击 10 次生成按钮，会发生什么？"
- "我们如何知道用户对 AI 回答的满意度？"
- "这个方案能让用户在 5 秒内完成任务吗？"
查看答案
- 类型 3：边界条件 - 关注异常使用场景
- 类型 4：可观测性 - 关注如何监控和衡量
- 类型 1：目标对齐 - 关注是否达成产品目标
AI 产品技术方案的特殊检查点
1. Prompt 相关
| 检查项 | 为什么重要 | 追问示例 |
|---|---|---|
| Prompt 是否已经过测试？ | 未测试的 Prompt 上线风险极高 | "测试集有多大？覆盖了哪些场景？" |
| Prompt 版本如何管理？ | Prompt 变更可能影响所有用户 | "改 Prompt 算需要发版吗？能快速回滚吗？" |
| 不同模型版本的 Prompt 是否分开维护？ | 同一个 Prompt 在不同模型上效果差异大 | "如果切换模型，Prompt 需要重新调优吗？" |
| Prompt 中有没有写死的信息？ | 写死的日期、版本号会随时间失效 | "Prompt 里有没有'2024年'这种会过期的信息？" |
2. 模型选型
| 检查项 | 为什么重要 | 追问示例 |
|---|---|---|
| 为什么选这个模型？ | 确保选型有依据，而非拍脑袋 | "和其他选项的对比依据是什么？有测试数据吗？" |
| 模型供应商的 SLA 是多少？ | 影响产品可用性 | "历史可用性如何？有没有长时间故障的记录？" |
| 如果供应商涨价或停服，切换成本是多大？ | 避免被单一供应商绑定 | "切换到备选模型需要多久？成本差异多大？" |
| 是否考虑过本地部署作为备选？ | 降低对外部服务的依赖 | "本地部署的成本和性能如何？" |
3. 性能与成本
| 检查项 | 为什么重要 | 追问示例 |
|---|---|---|
| 预计 P50 / P99 延迟是多少？ | P99 延迟决定最坏情况下的用户体验 | "P99 延迟超过 10 秒的概率是多少？" |
| 高并发下的降级策略是什么？ | 避免流量高峰时服务崩溃 | "排队、限流还是切换小模型？" |
| 单用户月均成本估算是多少？ | 确保商业模式可持续 | "盈利模型是否 cover？有没有成本上限？" |
| Token 消耗监控怎么做？ | 防止成本失控 | "有没有异常告警？超过预算时如何处理？" |
4. 安全与合规
| 检查项 | 为什么重要 | 追问示例 |
|---|---|---|
| 用户输入是否会发送给第三方模型供应商？ | 隐私合规要求 | "用户知道吗？隐私政策里有说明吗？" |
| 模型供应商是否会用 API 数据训练模型？ | 合规敏感，尤其是企业客户 | "合同里有明确禁止条款吗？" |
| 有没有输入过滤？ | 防止提示词注入攻击 | "如何防止用户通过输入绕过系统限制？" |
| 输出有没有安全过滤？ | 防止有害内容、隐私信息泄露 | "如何检测和拦截敏感信息？" |
合规风险
如果你的产品面向企业客户或处理敏感数据，安全与合规检查点是必须讨论的，不能跳过。
常见对话场景
场景 1：工程师说"这个 AI 效果不好保证"
❌ 不好的回应：
"那你们想办法让它好"（推卸责任）
✅ 好的回应：
"我们先定义什么叫'够好'——我来提供测试集和评分标准，你们来跑 Baseline，一起决定是否达到上线门槛。"
为什么这样回应更好：
- 承担了 PM 的责任（定义"够好"）
- 提出了可执行的方案（测试集 + 评分标准）
- 强调协作（"一起决定"）
场景 2：工程师说"这个功能要 3 周"
❌ 不好的回应：
"能不能快点？" / "其他公司 1 周就做出来了"
✅ 好的回应：
"帮我理解一下 3 周的主要工作量在哪里？有没有可以拆成 MVP 版本先上的部分？"
为什么这样回应更好：
- 理解工作量（而非质疑）
- 提出建设性方案（MVP 拆分）
- 尊重工程师的专业判断
场景 3：工程师说"你的需求描述不清楚"
❌ 不好的回应：
"我写了那么多页了还不清楚？"
✅ 好的回应：
"帮我具体说哪里不清楚，我现在就补充。"（然后立刻更新 PRD，并在会上确认）
为什么这样回应更好：
- 立即行动（而非争辩）
- 当场解决（而非会后再说）
- 展示了对质量的重视
场景 4：评审会上出现分歧
不要在会上强行决策。 正确做法：
- 明确分歧点："我理解你们的顾虑是 X，我的诉求是 Y，对吗？"
- 拆解出决策依据："我们需要哪些数据才能决定？"
- 明确后续行动："谁在什么时间提供这个数据？下次会议再定。"
经验法则
如果评审会上出现分歧，80% 的情况是因为信息不对称。先对齐信息，再做决策。
与工程师建立长期信任
技术沟通是长期关系，不是单次博弈。
建立信任的行为
| 行为 | 为什么重要 |
|---|---|
| 承诺的 PRD 准时交付，且质量高 | 展示专业性和可靠性 |
| 会上提的问题基于真实用户反馈，而非个人感受 | 展示数据驱动的决策能力 |
| 工程师提出技术约束时，认真理解而不是立刻反驳 | 尊重专业判断 |
| 功能上线后，主动分享数据结果（不只在出问题时找他们） | 展示对结果的关注和责任感 |
破坏信任的行为
| 行为 | 为什么有害 |
|---|---|
| 需求频繁变更，且没有解释原因 | 让工程师觉得你不专业 |
| 在评审会上当众质疑工程师判断 | 破坏团队氛围 |
| 越过负责工程师直接找 leader 施压 | 破坏信任关系 |
| 只在出问题时沟通，平时不回消息 | 让工程师觉得你只关心自己的 KPI |
长期影响
一次破坏信任的行为，可能需要 10 次建立信任的行为才能弥补。在技术沟通中，信任是最宝贵的资产。
检查点
在继续之前，确保你能回答：
- [ ] 能说出评审会前的 3 个准备工作
- [ ] 能用 5 类提问框架提出有价值的问题
- [ ] 能列出 AI 产品技术方案的 4 大特殊检查点
- [ ] 能应对 4 种常见对话场景
- [ ] 能说出建立信任的 4 种行为和破坏信任的 4 种行为