#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，例如：

practicalCoachingScenario !== "No coaching moment identified"

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

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

{
  "includeInCoaching": true
}

更完整的建议是：

{
  "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 是：

{
  "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 是：

{
  "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。

#建议

最小新增：

{
  "includeInCoaching": true
}

推荐新增：

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

字段语义：

#问题 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 输出：

{
  "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：

{
  "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 上，这三类的处理方式不同：

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

#建议

新增：

{
  "coachingKind": "improvement"
}

其中：

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

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

{
  "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 的标准生成结构化判定：

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

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

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

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

#现状

Coaching 页面需要展示：

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

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

#问题

需要区分两类状态：

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

#建议

Prompt 只负责：

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

系统负责初始化：

{
  "coachingStatus": "active"
}

Manager 操作后更新：

{
  "coachingStatus": "archived"
}

建议枚举：

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

• reviewed
• dismissed
• assigned

但第一版不建议复杂化。

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

#现状

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

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

#问题

这不足以 debug：

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

#建议

新增：

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

如果需要更结构化：

{
  "noCoachingReason": "routine_confirmation"
}

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

#建议的第一版输出 schema

建议把 03 的输出扩展为：

{
  "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 时：

{
  "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 的结构化输出补齐。