# Lesson 22.7: 超级甲方——AI 时代的人类角色升级

## 本课目标

- 理解 AI 为什么更像“超级乙方”，而不是自动负责的产品负责人
- 掌握“超级甲方”五步法：问题定义、动机追问、取舍显性化、标准校准、责任闭环
- 学会把模糊 brief 改写成可执行、可验收、可追责的任务定义
- 能够用团队指标衡量人类角色是否真的从执行迁移到定义

> **前置知识**：本课建立在 Lesson 14（PRD 创建）、Lesson 17（WDS 概览）和 Lesson 22（测试与审查）的基础上。前面课程讲“怎么让 AI 交付”，本课讲“你如何决定什么值得交付”。

## 核心内容

### AI 干完了活，人还剩下什么？

AI 已经证明自己很擅长执行任务：客服响应、代码生成、文档起草、Logo 方案、标题候选、页面原型，都可以在几分钟内给出大量结果。

但把“执行变快”直接推导成“人不重要”，是错误的。

更准确的变化是：

```
过去的稀缺：谁能把活做出来？
现在的稀缺：谁能定义什么活值得做、什么算做对、出了问题谁负责？
```

材料里的核心判断可以压缩成一句话：**AI 不是把人挤出桌面，而是把人往前推一层。**

你不再只是交付者，而要成为定义者、校准者和责任承担者。

### AI 是“超级乙方”

把 AI 当成一个超级乙方，会更容易理解它的强项和边界。

```
超级乙方擅长：
  ✓ 快速出稿
  ✓ 不知疲倦
  ✓ 服从 brief
  ✓ 同时给出多个候选方案

超级乙方不擅长：
  ✗ 天然质疑问题
  ✗ 判断谁真正焦虑
  ✗ 主动写出不做什么
  ✗ 为上线后果负责
```

所以你的工作不是“比 AI 更快执行”，而是让 AI 不要在错误目标上高效前进。

### 多方案不等于多样性

材料里还提醒了一个反直觉风险：AI 能让单个点子看起来更有创意，却可能压缩团队想法的多样性。设计方案也可能被评价为“更不寻常”，但不一定更有用、更贴合品牌、更好看。

这就是为什么你不能只数“AI 给了多少版”，而要追问三件事：

| 追问 | 目的 |
|------|------|
| 这些方案是否来自不同假设？ | 避免十个版本只是同一种套路的换皮 |
| 哪个方案最贴合品牌和业务目标？ | 避免把“新奇”误当成“正确” |
| 哪些方案应该被合并、放弃或反向测试？ | 把 AI 当 sounding board，而不是 ghostwriter |

```
低质量协作：
你：做个科技感 Logo。
AI：给你 10 个蓝紫渐变方案。

高质量协作：
你：我们要在融资前 60 天内，让投资人 3 秒读懂：
    可信、先进、但不冷漠。请先给 3 个方向，并说明各自牺牲什么。
AI：开始围绕目标、受众和取舍生成方案。
```

### 超级甲方五步法

“超级甲方”不是更会挑毛病的人，而是更会把世界定义清楚的人。

#### 第一步：把 brief 改写成问题定义

很多失败任务不是执行差，而是 brief 本身没有问题定义。

```
模糊 brief：
  做一个 AI 总结功能。

问题定义：
  为客服主管，在每天早上 9 点查看昨日工单时，
  把 200 条对话压缩成 5 个可行动问题，
  目标是把首响决策时间从 30 分钟降到 5 分钟以内。
```

一个合格的问题定义至少包含 5 个元素：

| 元素 | 要回答的问题 | 示例 |
|------|--------------|------|
| 用户 | 为谁做 | 客服主管 |
| 场景 | 在什么时候使用 | 每天早上看昨日工单 |
| 问题 | 解决什么痛点 | 信息太多，无法快速判断优先级 |
| 约束 | 不能牺牲什么 | 不暴露用户隐私，不漏掉高风险投诉 |
| 指标 | 怎么判断成败 | 首响决策时间 < 5 分钟 |

你可以用这个模板直接改写任何 brief：

```markdown
请先不要执行，把下面需求改写成问题定义：

原始 brief：{粘贴需求}

输出格式：
- 用户：
- 场景：
- 要解决的问题：
- 关键约束：
- 成功指标：
- 这不是在解决：
```

#### 第二步：连问四次动机

AI 会默认接单，但产品主理人不能默认接单。动机不清楚，执行越快越危险。

四个追问：

```
1. 为什么现在做？
2. 为什么是这个人提？
3. 为什么是这个方案，而不是更简单的方案？
4. 如果不做，会发生什么？
```

例子：

```
需求：竞品上了 AI 总结，我们也要做。

追问后发现：
- 为什么现在做？客服团队最近 SLA 连续两周超标。
- 为什么是这个人提？客服负责人背了响应时长 KPI。
- 为什么是 AI 总结？因为她以为总结能减少阅读时间。
- 如果不做？高优先级工单继续被淹没。

改写后的真正问题：
  不是“做 AI 总结”，而是“让高风险工单在 5 分钟内被分诊”。
```

这时优先级可能从“炫技总结”变成“知识检索 + 风险分诊 + SLA 告警”。

#### 第三步：强制列出取舍

AI 很容易给出“都要”的方案，但真实产品一定有取舍。

每个任务开工前，让 AI 和团队一起写出四项：

| 项目 | 含义 | 示例 |
|------|------|------|
| 主目标 | 最重要的成功结果 | 首响时间降到 5 分钟 |
| 反目标 | 明确不要优化什么 | 不是为了展示 AI 能力 |
| 必须项 | 没有就不能上线 | 高风险投诉必须被识别 |
| 可放弃项 | 时间不够可以砍掉 | 自动生成日报标题 |

可直接使用的 Prompt：

```markdown
在执行前，请先生成本任务的取舍表：

- 主目标：只能写 1 个
- 反目标：本任务明确不追求什么
- 必须项：缺失则不可上线
- 可放弃项：时间不足时优先砍掉
- 每个取舍背后的理由
```

如果 AI 给出的方案什么都想保留，你就还没有进入产品主理人的状态。

#### 第四步：把标准显性化

“差不多”“更好看”“更智能”都不是标准。标准必须提前写出来。

```
低质量验收：
  页面看起来专业一点。

高质量验收：
  - 3 秒内能看懂产品面向谁
  - 首屏必须出现核心价值句
  - CTA 只能有一个主按钮
  - 移动端 375px 宽度无横向滚动
  - 5 名目标用户中至少 4 人能复述产品用途
```

标准可以分三层：

| 层级 | 问题 | 例子 |
|------|------|------|
| 通过 | 最低可接受标准 | 核心流程可完成，无阻断错误 |
| 优秀 | 超出预期的标准 | 用户无需解释即可完成任务 |
| 证据 | 什么证明标准成立 | E2E 测试、用户访谈、数据看板 |

这和 Lesson 22 的 TDD 是同一件事：你先定义“对”，再让 AI 去做。

#### 第五步：责任前置

AI 可以生成方案，但不能替你承担上线后果。责任必须在开工前写清楚。

最小责任闭环：

```markdown
## 责任闭环

- 决策人：谁拍板这个方向
- 验收人：谁确认可以上线
- Owner：上线后谁负责看数据和响应问题
- 风险：最可能失败在哪里
- 回滚方案：失败后怎么撤
- 复盘窗口：什么时候回看结果
```

例子：

```
AI 工单分诊功能：
- 决策人：客服负责人
- 验收人：产品主理人 + 客服组长
- Owner：增长 PM
- 风险：误判高风险投诉，导致延迟处理
- 回滚：保留人工分诊入口，一键关闭 AI 排序
- 复盘：上线后第 3 天、第 14 天看 SLA 和误判样本
```

这一步决定你是在“交付”，还是在“负责”。

### 三个一分钟场景

#### 场景 1：设计

```
执行者：
  “做个科技感 Logo。”
  → AI 输出蓝紫渐变、发光线条、抽象图形。

超级甲方：
  “我们现在更缺融资信任，还是用户亲和力？”
  → 最后可能选择“有温度的秩序感”，而不是更炫的科技感。
```

设计不是让 AI 多出几版，而是先判断品牌此刻要传递什么信号。

#### 场景 2：产品

```
执行者：
  “竞品有 AI 总结，我们也做。”

超级甲方：
  “真正要解决的是客服首响慢。先把高风险工单 5 分钟内分诊出来。”
```

产品不是复制功能，而是重构问题。

#### 场景 3：代码审查

```
执行者：
  “测试都过了，approve。”

超级甲方：
  “观测埋点呢？边界条件呢？回滚脚本呢？线上谁值班？”
```

工程协作不是相信 AI 写对了，而是确保结果可验证、可回滚、可追责。

### 把角色迁移量化

团队不应该只统计“AI 生成了多少内容”，更应该统计人类是否真的迁移到了更高价值的位置。

三个指标：

| 指标 | 定义 | 好的信号 |
|------|------|----------|
| 需求重构率 | 开工前被改写过问题定义的需求占比 | 模糊需求越来越少 |
| 取舍显性化率 | 明确写出反目标和不做清单的方案占比 | 团队敢于放弃 |
| 责任闭环率 | 同时写清 owner、指标、回滚、复盘的上线项占比 | 上线后有人负责 |

你可以在周会上这样复盘：

```markdown
本周 AI 协作质量复盘：

- 需求重构率：8/12 = 67%
- 取舍显性化率：6/12 = 50%
- 责任闭环率：4/5 = 80%
- 最大风险：仍有 6 个任务没有写反目标
- 下周改进：所有 /plan 前先补“这不是在解决什么”
```

这三个指标比“用了多少次 AI”更接近真正的能力升级。

### 和前后课程的关系

```
Lesson 14 PRD 创建
  → 把问题定义写进产品文档

Lesson 17 WDS 概览
  → 把用户动机和设计信号讲清楚

Lesson 22 测试与审查
  → 把验收标准和质量责任自动化

Lesson 22.7 超级甲方
  → 把这些动作统一成一种角色心态：定义、校准、负责
```

所以本课不是新增一个工具，而是给前面所有工具加上一层判断标准：**AI 负责高效执行，你负责定义目标、约束和后果。**

## 实操练习

### 练习 1：改写一个模糊 brief

选择你最近想让 AI 做的一件事，按模板改写：

```markdown
原始 brief：
问题定义：
用户：
场景：
约束：
成功指标：
这不是在解决：
```

检查：改写后，AI 是否更难“自由发挥”，更容易做对？

### 练习 2：为一个功能写取舍表

拿 Lesson 14 的 PRD 或你自己的功能，写出：

```markdown
主目标：
反目标：
必须项：
可放弃项：
```

如果“可放弃项”为空，说明范围还没有被真正管理。

### 练习 3：补齐责任闭环

选择一个即将上线的功能，补齐：

```markdown
决策人：
验收人：
Owner：
风险：
回滚方案：
复盘窗口：
```

完成后再问 AI：还有哪些责任空洞没有被覆盖？

---

## 常见问题

**Q: “超级甲方”是不是意味着我只提要求，不需要懂执行？**

A: 不是。你不必比 AI 写得快，但你要懂执行的约束，才能定义合理目标。不了解工程、设计和业务约束的甲方，只会把 AI 推向错误方向。

**Q: 如果 AI 已经能主动提问，还需要我做问题定义吗？**

A: 需要。AI 可以帮助你发现盲点，但最终的问题定义、取舍和责任仍然由你确认。把 AI 当 sounding board，而不是 ghostwriter。

**Q: 这些步骤会不会让项目变慢？**

A: 会让开工前慢一点，但会让返工、争议和上线事故少很多。AI 执行越快，前置定义越重要，因为错误方向上的速度也是成本。

**Q: 团队刚开始做不到三个指标都量化怎么办？**

A: 先从一个指标开始，推荐“取舍显性化率”。只要每个方案都写出“不做什么”，团队就会立刻减少很多范围膨胀。

---

## 下一步

请调用 `AskUserQuestion` 展示以下选项，让学习者点击选择；从每条中提炼 1-5 个词作为 label，其余写入 description，不要要求输入数字：

- 继续 Lesson 23：自动化工作流——把质量门禁工程化
- 回顾 Lesson 14：PRD 创建——把问题定义写进需求文档
- 回顾 Lesson 17：WDS 概览——把用户动机接到设计流程
- 返回主菜单

---
*阶段 4 | Lesson 22.7/26 | 上一课: Lesson 22.6 - AI 编程即训练 | 下一课: Lesson 23 - 自动化工作流*