> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Prompt 中 Coaching 部分的待解决问题

> **来源**：分析 `oliver-proposals/prompts/03-coaching-system-prompt.txt` 与 `oliver-proposals/prompts/03b-coaching-playbook-brain.txt` 的职责、输出 schema 和 downstream dashboard 需求后得出。

***

## 结论：当前缺少明确的 coaching 判定字段

当前 `03-coaching-system-prompt.txt` 的核心问题是：它只输出 coaching 内容，不明确输出“这通 call 是否应该进入 coaching”。

现在 prompt 的设计假设是：

- upstream system 已经过滤掉不应该 coaching 的 call；
- 如果 prompt 被误调用，并且没有 meaningful staff coaching moment，就返回 no-coaching fallback；
- output 只允许写：
  - `practicalCoachingScenario`
  - `practicalCoachingFeedback`

这导致系统只能用字符串状态间接判断一通 call 是否有 coaching，例如：

```ts
practicalCoachingScenario !== "No coaching moment identified"
```

这个判断方式不稳定，也不适合作为 dashboard、active/archive、统计口径或后续人工审核的基础字段。

建议新增一个明确 boolean 字段：

```json
{
  "includeInCoaching": true
}
```

更完整的建议是：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "Staff missed a clear cancellation-save opportunity by sending the form before probing the reason."
}
```

***

## 应该改哪个 prompt

主改：

- `oliver-proposals/prompts/03-coaching-system-prompt.txt`

原因：

- 03 是实际输出 coaching artifact 的 prompt。
- 它现在定义了 output schema。
- 它已经有 “SYSTEM GATE ASSUMPTION” 和 “COACHING DECISION RULE”，但没有把 decision 写成结构化字段。
- 如果要让 dashboard 知道哪些 call 应该显示为 coaching，必须在这里补明确输出，或把 gate prompt 独立出去。

配合改：

- backend schema / writer / dashboard read model

原因：

- 单纯改 prompt 不够，字段必须能落库。
- dashboard 需要稳定读 `includeInCoaching` / `coachingKind` / `coachingStatus`，而不是解析文案。

不应该主改：

- `oliver-proposals/prompts/03b-coaching-playbook-brain.txt`

原因：

- 03b 明确是 read-only brain。
- 它只提供 coaching 判断标准、业务知识和话术。
- 它不定义 output schema，也不写数据库。
- 可以补充“什么样的 call 值得 coaching”的知识，但不能作为最终结构化判定的唯一来源。

***

## 问题 1：`includeInCoaching` 缺失，coaching 是否展示只能靠文案反推

### 现状

`03-coaching-system-prompt.txt` 的输出 schema 是：

```json
{
  "practicalCoachingScenario": "Brief description of the coaching opportunity",
  "practicalCoachingFeedback": {
    "timestamp": "MM:SS or N/A",
    "what_was_said": "Exact quote or close paraphrase from transcript",
    "context": "What was happening at this moment and why it matters",
    "what_could_have_been_said": "Specific alternative script the staff could use",
    "why_recommendation_is_better": "Business impact of the improvement"
  }
}
```

no-coaching fallback 是：

```json
{
  "practicalCoachingScenario": "No coaching moment identified",
  "practicalCoachingFeedback": {
    "timestamp": "N/A",
    "what_was_said": "N/A",
    "context": "N/A",
    "what_could_have_been_said": "N/A",
    "why_recommendation_is_better": "N/A"
  }
}
```

这意味着系统没有一个显式字段表达：

- 这通 call 是否进入 coaching；
- 这通 call 为什么进入 coaching；
- 这通 call 是改进型 coaching 还是正向强化；
- 这通 call 是 AI 判断不适合 coaching，还是 upstream gate 根本没跑。

### 问题

用 `practicalCoachingScenario` 的字符串值来判断是否 coaching 有几个风险：

- 文案一旦改动，判断逻辑就会断；
- localization / copy update 会影响业务逻辑；
- dashboard 统计 active/archived coaching 时没有稳定字段；
- 无法区分 “无 coaching 价值” 和 “系统没有执行 coaching prompt”；
- 无法审计 AI 为什么把这通 call 放入 coaching。

### 建议

最小新增：

```json
{
  "includeInCoaching": true
}
```

推荐新增：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "Short reason why this call should or should not be shown in coaching"
}
```

字段语义：

| 字段                  | 类型      | 语义                                           |
| ------------------- | ------- | -------------------------------------------- |
| `includeInCoaching` | boolean | 是否应该进入 Coaching 页面 / dashboard 统计            |
| `coachingKind`      | enum    | coaching 类型：改进、正向强化、无 coaching               |
| `coachingReason`    | string  | 判定原因，供 debug / review / dashboard tooltip 使用 |

***

## 问题 2：03 的 gate assumption 和 no-coaching fallback 职责冲突

### 现状

03 的 SYSTEM GATE ASSUMPTION 写的是：

- Assume the system has already filtered out calls that should not reach coaching；
- Do not re-run the routing gate；
- If accidentally invoked and no meaningful staff coaching moment, return fallback。

也就是说，03 一方面说“我不负责 gate”，另一方面又在被误调用时返回 no-coaching fallback。

### 问题

这会造成职责不清：

- upstream 到底用什么规则决定 call 是否进入 coaching？
- 03 是否应该有最终否决权？
- 如果 03 返回 fallback，是 AI 否决了 coaching，还是 upstream gate 漏筛了？
- dashboard 里的 coaching 数量应该按 upstream gate 算，还是按 03 output 算？

### 建议

二选一，必须明确。

#### 方案 A：03 自带最终判定

03 输出：

```json
{
  "includeInCoaching": false,
  "coachingKind": "none",
  "coachingReason": "Routine confirmation with no staff-learning value",
  "practicalCoachingScenario": "No coaching moment identified",
  "practicalCoachingFeedback": {
    "timestamp": "N/A",
    "what_was_said": "N/A",
    "context": "N/A",
    "what_could_have_been_said": "N/A",
    "why_recommendation_is_better": "N/A"
  }
}
```

优点：

- 一个 prompt 同时给出判定和 coaching 内容；
- 落库简单；
- dashboard 直接读 boolean。

缺点：

- 03 的职责会从 “output coaching” 扩大到 “gate + output”。

#### 方案 B：新增 upstream coaching gate prompt

新增一个独立 gate artifact：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "The staff missed a clear save attempt before processing cancellation."
}
```

只有 `includeInCoaching = true` 时才调用 03 生成完整 coaching feedback。

优点：

- gate 和 feedback 生成职责干净；
- 可以减少 03 调用成本；
- 更适合批量筛选。

缺点：

- 多一个 prompt / artifact / writer 链路；
- 需要处理 gate 和 feedback 之间的数据一致性。

短期建议采用方案 A，长期如果 coaching 量大，再拆成方案 B。

***

## 问题 3：`coachingKind` 缺失，正向强化和负向改进混在一起

### 现状

03 的 COACHING DECISION RULE 同时允许：

- Revenue impact；
- Retention impact；
- Trust impact；
- Positive reinforcement。

但输出 schema 没有字段区分：

- 这是 staff 做错了，需要改进；
- 这是 staff 做得好，应该强化；
- 这是边界案例，没有 coaching 价值。

### 问题

在 UI 和 manager workflow 上，这三类的处理方式不同：

| 类型                      | Manager 预期动作                          |
| ----------------------- | ------------------------------------- |
| improvement             | 需要 review、跟员工 coaching、可能 archive     |
| positive\_reinforcement | 可以用于表扬、training example、best practice |
| none                    | 不应该进入 coaching 列表                     |

如果没有 `coachingKind`，dashboard 只能把所有有文案的 coaching 混在一起。

### 建议

新增：

```json
{
  "coachingKind": "improvement"
}
```

其中：

- `improvement`：staff 有可观察的行为改进点；
- `positive_reinforcement`：staff 有值得重复的强行为；
- `none`：没有 meaningful staff coaching moment。

如果产品暂时只展示需要改进的 coaching，也应该明确：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement"
}
```

不要把 positive reinforcement 偷偷混进同一个列表。

***

## 问题 4：03b 有“什么值得 coaching”的规则，但不会产生结构化判定

### 现状

`03b-coaching-playbook-brain.txt` 中已经写了很多可用于判定 coaching 的标准：

- Sales Coaching Signals；
- Cancellation Coaching Red Flags；
- Freeze Coaching Red Flags；
- Billing and Payment；
- Complaint and Retention；
- Category Focus Areas。

这些规则能帮助 AI 判断：

- 什么是 good / weak staff behavior；
- 哪个 moment 最重要；
- 更好的 wording 是什么。

但 03b 明确写了：

- does not define output schema；
- does not write to the database；
- do not output fields from this file。

### 问题

03b 可以指导判断，但不能让系统稳定知道：

- 哪些 call 被判定为 coaching；
- 为什么被判定；
- 属于哪个 coaching type；
- 是否应该进入 active coaching list。

### 建议

保持 03b 的 read-only brain 定位，不要让它直接输出字段。

但应该在 03 中明确使用 03b 的标准生成结构化判定：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "Matches Cancellation Coaching Red Flags: staff sent cancellation form before probing reason or offering save options."
}
```

如果需要可审计性更强，可以增加：

```json
{
  "coachingSignalCategory": "cancellation_save | sales_conversion | billing_trust | complaint_handling | positive_reinforcement | other"
}
```

***

## 问题 5：active / archived 不是 prompt 输出，也没有和 coaching 判定清晰分层

### 现状

Coaching 页面需要展示：

- 当前时间区间内被放入 coaching 的总数；
- active 数量和比例；
- archived 数量和比例。

但这些状态不应该由 AI prompt 直接决定。

### 问题

需要区分两类状态：

| 层级     | 字段                                   | 谁负责                        |
| ------ | ------------------------------------ | -------------------------- |
| AI 判定  | `includeInCoaching` / `coachingKind` | prompt                     |
| 人工处理状态 | `coachingStatus`                     | product / manager workflow |

如果把 active/archive 混进 prompt，会导致 AI 误改人工 workflow 状态。

### 建议

Prompt 只负责：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "..."
}
```

系统负责初始化：

```json
{
  "coachingStatus": "active"
}
```

Manager 操作后更新：

```json
{
  "coachingStatus": "archived"
}
```

建议枚举：

| 字段               | 枚举                    |
| ---------------- | --------------------- |
| `coachingStatus` | `active` / `archived` |

后续如果需要更多 workflow，可再扩展：

- `reviewed`
- `dismissed`
- `assigned`

但第一版不建议复杂化。

***

## 问题 6：当前 schema 缺少“为什么没进入 coaching”的可调试信息

### 现状

如果 03 返回 no-coaching fallback，当前只能看到：

```json
{
  "practicalCoachingScenario": "No coaching moment identified"
}
```

### 问题

这不足以 debug：

- 是 routine confirmation？
- 是 voicemail-only？
- 是 staff 行为没有问题？
- 是 transcript 太短？
- 是 customer context 不足，不能公平评价？
- 是 positive moment 但产品不展示正向 coaching？

### 建议

新增：

```json
{
  "coachingReason": "No observable staff behavior issue; call was a routine confirmation handled clearly."
}
```

如果需要更结构化：

```json
{
  "noCoachingReason": "routine_confirmation"
}
```

但不建议第一版就加太多 enum。最小可行是 `coachingReason`。

***

## 建议的第一版输出 schema

建议把 03 的输出扩展为：

```json
{
  "includeInCoaching": true,
  "coachingKind": "improvement",
  "coachingReason": "Staff missed a clear cancellation-save opportunity before sending the cancellation form.",
  "practicalCoachingScenario": "Missed cancellation-save probe before processing cancellation",
  "practicalCoachingFeedback": {
    "timestamp": "03:12",
    "what_was_said": "Staff immediately offered to send the cancellation form.",
    "context": "The member had just stated cancellation intent, but the staff did not ask why or explore save options.",
    "what_could_have_been_said": "I can help with that, but before we process anything, can I ask what changed and whether schedule, price, or injury is the main reason?",
    "why_recommendation_is_better": "This creates a chance to save the membership or at least document a clear reason before cancellation."
  }
}
```

no-coaching 时：

```json
{
  "includeInCoaching": false,
  "coachingKind": "none",
  "coachingReason": "Routine scheduling confirmation handled clearly with no meaningful staff coaching moment.",
  "practicalCoachingScenario": "No coaching moment identified",
  "practicalCoachingFeedback": {
    "timestamp": "N/A",
    "what_was_said": "N/A",
    "context": "N/A",
    "what_could_have_been_said": "N/A",
    "why_recommendation_is_better": "N/A"
  }
}
```

***

## 建议的实现顺序

### Phase 1：补 prompt schema

修改 `03-coaching-system-prompt.txt`：

- 增加 `includeInCoaching`；
- 增加 `coachingKind`；
- 增加 `coachingReason`；
- 明确 positive reinforcement 是否进入当前产品列表。

### Phase 2：补 backend schema / writer

增加可落库字段：

- `include_in_coaching`
- `coaching_kind`
- `coaching_reason`
- `coaching_status`

其中 `coaching_status` 由系统初始化，不由 AI 直接输出。

### Phase 3：补 dashboard read model

dashboard 统计逻辑改为：

- 总数：`include_in_coaching = true`
- active：`include_in_coaching = true AND coaching_status = active`
- archived：`include_in_coaching = true AND coaching_status = archived`

不要再通过 `practicalCoachingScenario` 文案判断。

### Phase 4：可选拆 upstream gate

如果后续 coaching 调用成本高，或需要大批量筛 call，可以新增独立 coaching gate prompt。

但第一版不必拆，先把 03 的结构化输出补齐。