@sokeai/cli 1.0.66 → 1.0.67

package/skills/ai-coach-director/SKILL.md

@@ -0,0 +1,1229 @@
+---
+name: ai-coach-director
+description: AI陪练主管技能。当用户输入业务资料、对话场景、提示词、需求描述、对话问题、评分问题、微调需求或平台同步需求时,自动分析意图、检查输入完整性、调度AI陪练专项技能,并执行资产调用与质量闸门。统一入口,覆盖创建陪练、微调陪练、技术排障、客户交付与平台同步。内置自主学习引擎。v2.2:soke-cli沙箱绕过(dangerouslyDisableSandbox)、头像/声音合并单次patch写入+强制验证+重试机制、自查清单/内部步骤编号对用户不可见。
+agent_created: true
+---
+
+# AI陪练主管技能
+
+## 技能定位
+
+本技能是AI陪练技能体系的**统一调度入口**。它不直接替代专项技能,而是负责:
+
+1. 识别任务类型
+2. 检查输入是否足够
+3. 选择应读取的资产库
+4. 调度对应专项技能
+5. 设置质量闸门
+6. 防止技术问题被误当成提示词问题
+7. 平台同步时执行环境前置检测
+8. 端到端编排:创作 → 同步 → 交付
+9. 自主学习与自我进化:每次纠正、失败、漏拦都记录并推广为永久规则
+10. 当平台真实 API 与历史文档冲突时,以最新 CLI 实证和 `references/platform-api-pitfalls.md` 为准
+11. 场景命令模板统一以 `references/verified-cli-cheatsheet.md` 为抄写基准,避免误写成顶层 `soke-cli +...`
+12. **所有 soke-cli 命令必须绕过沙箱执行**：soke-cli 是 Go 编译的二进制文件，在 WorkBuddy Bash 工具的沙箱中会被限制（表现为 `permission denied`、`operation not permitted`、静默无输出等）。调用 Bash 工具执行任何 soke-cli 命令时，**必须设置 `dangerouslyDisableSandbox: true`**。此规则适用于全部 soke-cli 子命令（`config show`、`auth login`、`ai-training +...` 等），不限于创建型流程
+
+---
+
+## 调度技能清单
+
+### 创作管线(coaching/)
+
+| 技能 | 功能 | 路径 |
+|------|------|------|
+| `role-profiler` | 可选增强模块:复杂资料 → 按需画像(MBTI+冰山理论+行为模式) | `coaching/role-profiler/role-profiler.md` |
+| `prompt-engineer` | 编排器:工作流 + Part1 + 一致性校验(Part2-5 框架拆分至 `parts/`,Part2 已按真实平台规则升级) | `coaching/prompt-engineer/prompt-engineer.md` |
+| `prompt-optimizer` | 现有提示词/对话问题 → 四段式诊断报告 | `coaching/prompt-optimizer/prompt-optimizer.md` |
+
+### 平台同步(platform/)
+
+| 技能 | 功能 | 路径 |
+|------|------|------|
+| `soke-ai-training` | 知识包/提示词 → MentorAI 平台同步 | `platform/soke-ai-training/soke-ai-training.md` |
+| `sync-engine` | JSON 生成规则、字段映射表、CLI 命令模板 | `platform/sync-engine.md` |
+| `interaction` | 弹窗交互规则（优先 render_ui 弹窗，兜底结构化文本） | `platform/interaction.md` |
+
+---
+
+## 标准任务类型
+
+### 1. 创建型
+
+从资料、需求、业务场景搭建新陪练。
+
+**典型表达**:帮我搭建AI陪练 / 创建陪练场景 / 根据资料生成提示词 / 做一个销售/面访/电话约访陪练
+
+### 2. 微调型
+
+已有提示词、对话记录或反馈,需要优化。
+
+**典型表达**:优化提示词 / AI不像客户 / 对话不对劲 / 评分不准 / 提前结束 / 信息泄露
+
+### 3. 技术排障型
+
+涉及 ASR、TTS、权限、跳转、按钮、录音、部署、数据同步等。
+
+### 4. 客户交付/复盘型
+
+涉及培训包、看板、数据指标、项目复盘、客户验收。(纯流程型,不调度子技能)
+
+**流程**:
+1. 确认交付对象(学员/管理者/客户)和交付形式(培训包/看板/报告)
+2. 收集对话数据和评分结果
+3. 按交付对象生成对应物料:
+   - 学员侧:个人能力报告 + 薄弱项 + 练习建议
+   - 管理者侧:团队看板 + 数据指标 + 趋势分析
+   - 客户侧:项目复盘 + ROI 摘要 + 下一步建议
+4. 交付前跑数据完整性检查(指标口径一致、数据无污染)
+
+### 5. 平台同步型
+
+把知识包/提示词同步到 MentorAI 平台。
+
+**典型表达**:同步到平台 / 上传知识包 / 绑定场景 / 编译知识计划 / 发布场景
+
+**流程**:
+1. **环境前置检测**:`read references/env-check.md`,按顺序检查 Node.js → soke-cli 安装 → 登录状态 → 企业绑定
+2. 全部通过 → 优先按 `platform/sync-engine.md` 的 Partwise 同步流执行(Step1 create → Part2 → Part3 → Part4 → Part5)
+3. 同步前先参考 `references/platform-api-pitfalls.md` 的已验证差异,避免沿用过时 payload / operation type
+4. 需要复制或核对命令时,统一参考 `references/verified-cli-cheatsheet.md`
+5. 仅当知识库超长或用户明确要求知识包同步时,才追加调度 `platform/soke-ai-training/soke-ai-training.md`
+6. 任一步未通过 → 按 `references/env-check.md` 修复流程引导,不进入同步
+7. 创建型流程在 Step 8 自动执行 `+publish-scenario`;单独发布已有场景时同样走此命令
+
+---
+
+## 资产调用规则
+
+默认资产库路径:`references/cases/`(本技能内置)
+
+### 创建型任务必读
+
+- `AI陪练客户材料清单与访谈题库.md`
+- `AI陪练场景分类库.md`
+- `AI陪练提示词模块库.md`
+- `AI陪练评分标准组件库.md`
+- `AI陪练测试用例库.md`
+
+### 微调型任务必读
+
+- `AI陪练微调问题库.md`
+- `AI陪练Bad Case样本库.md`
+- `AI陪练技术边界与排障库.md`
+
+### 微调按需选读
+
+- 角色不像:`AI客户角色模板库.md`
+- 评分不准:`AI陪练评分标准组件库.md`
+- 信息泄露:`AI陪练提示词模块库.md`
+- 数据问题:`AI陪练数据指标与看板口径库.md`
+- 指令执行偏差(P标签):`AI陪练提示词模块库.md`
+- 对话自然度偏差(N标签):`AI客户角色模板库.md`
+
+---
+
+## 创建型任务流程（严格顺序管线）
+
+> ⚠️ **强制串行执行**：以下 Step 0-7 必须严格按顺序执行，每一步必须完成并通过闸门检查后才能进入下一步。**禁止跳步、禁止并行、禁止省略中间步骤**。如果某一步检测不通过，必须在当前步骤修复后再继续，不可将未解决的问题带入下一步。
+
+### 管线总览
+
+```
+Step 0: 平台就绪检测
+  ↓ ✅ 环境就绪
+Step 1: 材料接收与完整性检查
+  ↓ ✅ 材料齐全
+Step 2: 场景类型判定
+  ↓ ✅ 类型确认
+Step 3: 完整链路需求判定
+  ↓ ✅ 链路确认
+Step 4: 7 项必问清单确认
+  ↓ ✅ 全部可答
+Step 5: 内容生成（prompt-engineer 逐 Part 流水线）
+  ↓ ✅ 逐 Part 确认同步
+Step 6: 平台同步验证
+  ↓ ✅ 同步成功
+Step 7: 创建质量闸门（10 项全部通过）
+  ↓ ✅ 闸门通过
+Step 8: 场景发布
+  ↓ ✅ 发布成功
+交付
+```
+
+> 每个箭头上方的 ✅ 是该步骤的强制闸门，未通过不得推进到下一步。
+
+---
+
+### ⚙️ Step 0: 平台就绪检测（必做，先于内容生成）
+
+创建型流程全程依赖 soke-cli 与平台交互。**必须在 Step 1 之前**完成环境检测。
+
+> ⚠️ **沙箱绕过（全局规则）**：soke-cli 是 Go 编译的二进制文件，在 WorkBuddy Bash 沙箱中执行会被限制（`permission denied` / 静默失败）。**所有 soke-cli 命令调用 Bash 工具时必须设置 `dangerouslyDisableSandbox: true`**，包括环境检测中的 `which soke-cli`、`soke-cli --version`、`soke-cli config show`、`soke-cli auth login` 以及后续全部 `soke-cli ai-training +...` 命令。
+
+```
+read references/env-check.md
+按顺序执行 4 步检测：
+  1. node --version → 确认 >= 14
+  2. which soke-cli → 确认已安装
+  3. soke-cli config show → 确认含 user_token
+  4. soke-cli config show → 确认 implementation_corp_id / corpid 至少一个非空
+
+全部通过 → 记录企业 ID，进入 Step 1
+```
+
+**各步失败时的处理：**
+
+| 步骤 | 失败表现 | 自动修复动作 |
+|------|---------|------------|
+| 1 | Node.js 未安装或 < 14 | ❌ 无法自动修复，提示用户安装 Node.js >= 14 |
+| 2 | `soke-cli` 未安装 | ❌ 无法自动修复，按 env-check.md 步骤 2 引导安装 |
+| 3 | `user_token` 为空或过期 | ✅ **自动执行 `soke-cli auth login`**，浏览器会自动打开授权页。若浏览器未打开，提示用户复制终端输出的链接手动完成授权。登录后重新检测 |
+| 4 | `implementation_corp_id` 和 `corpid` 均为空 | ✅ 登录成功后自动读取；若仍为空，执行 `soke-cli auth login --force` 刷新企业绑定信息。仍为空则提示用户在授客AI平台完成企业绑定 |
+
+> ⚠️ **步骤 3 关键规则**：`soke-cli config show` 无 `user_token` 时，**必须立即执行 `soke-cli auth login`**，不可跳过、不可只告知用户。`soke-cli auth login` 会自动调用系统默认浏览器打开授客AI开放平台授权页面，用户在浏览器中完成授权即可。授权成功后返回终端，Token 自动保存。
+
+> 🚦 **闸门**：环境检测失败时，不生成任何提示词、不创建任何 JSON 文件、不进入 Step 1。修复成功后必须从 Step 0 重新完整检测。
+
+---
+
+### Step 1: 材料接收与完整性检查
+
+> ⚠️ **禁止跳过**：上传资料后必须先完成材料完整性检查。不允许"边做边补材料"或"先生成一版再补信息"。
+
+#### 1.1 确认材料已接收
+
+用户上传的业务资料必须至少包含以下一类：
+- 真实话术、录音、SOP 或培训资料
+- 产品资料、合规文件
+- 销冠话术、优秀案例
+- 明确的业务场景描述与训练目标
+
+#### 1.2 逐项检查材料完整性
+
+对每份材料进行检查：
+- 内容是否可读、清晰
+- 是否包含具体业务场景信息（而非仅有宏观方向）
+- 是否包含对话/话术素材（而非仅有流程框架）
+- 是否足以支撑后续角色设定和知识库构建
+
+#### 1.3 输出检查结果
+
+```
+✅ 材料齐全，通过 → 进入 Step 2
+⚠️ 材料不足 → 输出材料缺口清单 + 补充访谈问题 → 等待用户补充 → 重新执行 Step 1
+```
+
+> 🚦 **闸门**：材料不足时，先输出材料缺口和访谈问题，**不进入 Step 2（场景类型判定）**，更不进入 prompt-engineer。用户补充材料后，从 Step 1 重新开始。
+
+---
+
+### Step 2: 场景类型判定
+
+> ⚠️ **禁止跳过**：必须基于 Step 1 确认的完整材料，通过场景分类资产库判定场景类型。不允许未经判定就直接生成内容。
+
+#### 2.1 读取场景分类资产
+
+```
+read references/cases/AI陪练场景分类库.md
+```
+
+#### 2.2 结合材料判定场景类型
+
+综合材料中的行业、业务环节、训练目标等信息，从分类库中匹配最合适的类型。
+
+输出格式：
+
+```markdown
+## 场景类型判定
+
+- **行业**：[行业]
+- **业务环节**：[环节，如 电话约访 / 面访 / 展会 / 客服 等]
+- **场景类型**：[类型名称，如 金融电话约访型 / B2B销售型 / 餐饮服务型]
+- **匹配标杆案例**：[references/cases/create/ 中的对应案例路径]
+- **判定依据**：[简述为什么匹配该类型]
+```
+
+> 🚦 **闸门**：场景类型判定结果必须输出给用户确认。不确定时列出最可能的 2 个备选类型让用户选择。确认后进入 Step 3。**类型未确认前，不得生成任何内容**。
+
+---
+
+### Step 3: 完整链路需求判定
+
+> ⚠️ **禁止跳过**：基于场景类型和材料复杂度，判定执行标准链路还是完整链路。不允许模糊处理。
+
+#### 判定规则
+
+| 条件 | 链路选择 | 执行说明 |
+|------|---------|---------|
+| 材料简洁、角色明确、场景单一 | **标准链路** | 直走 `prompt-engineer`（知识库、角色生成、剧本设计已内嵌于各 Part 模块） |
+| 资料复杂、需提炼多类典型客户 | **完整链路** | `role-profiler → prompt-engineer`（先按需画像提取典型角色，再生成内容） |
+| 用户明确要求"按需画像 / MBTI 侧写" | **完整链路** | `role-profiler → prompt-engineer` |
+
+输出链路判定结果，确认后进入 Step 4。
+
+> 🚦 **闸门**：链路判定必须明确。标准链路不得无故调用 role-profiler；完整链路不得跳过 role-profiler。
+
+---
+
+### Step 4: 7 项必问清单确认
+
+> ⚠️ **禁止跳过**：在进入内容生成前，必须逐项确认以下 7 个问题均有明确答案。任一无法回答，不得进入 Step 5。
+
+逐项输出确认：
+
+```markdown
+## 7 项必问清单
+
+| # | 检查项 | 状态 | 答案 / 材料来源 |
+|---|--------|------|----------------|
+| 1 | 训练对象是谁？（角色、职级、经验水平） | ✅ / ⚠️ | [从材料中提取的答案，或标注"待补充"] |
+| 2 | 业务场景是什么？（行业、环节、上下文） | ✅ / ⚠️ | ... |
+| 3 | 成功对话标准是什么？（怎样的对话算"练好了"） | ✅ / ⚠️ | ... |
+| 4 | AI 角色是谁？（模拟的客户/对话者画像） | ✅ / ⚠️ | ... |
+| 5 | 有没有真实话术、录音、SOP 或培训资料？ | ✅ / ⚠️ | ... |
+| 6 | 有没有评分标准或验收口径？ | ✅ / ⚠️ | ... |
+| 7 | 有没有禁用话术或红线？ | ✅ / ⚠️ | ... |
+```
+
+> 🚦 **闸门**：任一问题答案为 ⚠️（无法从材料中明确获知），先追问用户补充，**不进入 Step 5**。全部 ✅ 后方可推进。
+
+---
+
+### Step 5: 内容生成（prompt-engineer 逐 Part 流水线）
+
+> ⚠️ **强制顺序**：必须按 Part1 → Part2 → Part3 → Part4 → Part5 严格串行执行。**禁止跳 Part、禁止并行生成、禁止一次性批量输出多个 Part**。每个 Part 必须完成「**生成 → 完整展示 → 用户确认 → 同步**」四步闭环后才能进入下一 Part。
+>
+> 📺 **用户可见规则**：Step 5 对话中**仅展示**各 Part 的标题（`## 🔨 PartN`）和确认弹窗（`AskUserQuestion`）。以下内容**全部在内部推理中执行，严禁写入对话窗口**：
+> - 内部思考与生成过程
+> - JSON 文件创建命令
+> - CLI 预览/应用命令及输出（含 `+preview-scenario-update` / `+apply-scenario-update` 及其返回的 diff_summary、changed_fields、operation_count 等）
+> - CLI 查询命令及输出（含 `+get-scenario` / `+list-scenarios` / `+list-scenario-snapshots` / `+list-role-avatars` / `+list-role-voices` 及其返回数据）
+> - 协议阶段 1 自检清单与结果
+> - 角色资源匹配过程（含头像/声音的 CLI 查询和写入）
+> - 工作流步骤编号（如"步骤 6：预览更新""步骤 8：发布场景"等工作流元信息）
+
+---
+
+#### ⛔ 每个 Part 的确认协议（最高优先级，不可绕过）
+
+> **统一协议：先完整展示，再提供确认。两个步骤不可颠倒、不可跳过、不可省略任何一步。**
+>
+> 本协议适用于 Part1-Part5 全部五个部分，是 Step 5 的第一道强制闸门。
+
+##### 协议阶段 1：完整展示（必须在确认弹窗之前完成）
+
+每个 Part 生成后，**必须将该 Part 的全部完整内容直接在对话框中逐字段展示给用户**。展示格式为 `## 🔨 PartN：{标题}` 开头，接着逐节逐字段输出全部正文。
+
+**禁止使用弹窗组件（AskUserQuestion）替代内容展示**——弹窗组件仅用于协议阶段 2 的确认操作，**内容必须先在对话中以纯文本形式完整呈现**。
+
+各 Part 必须展示的内容清单（**展示内容严禁使用 Markdown 表格格式，必须用纯文本段落/列表呈现**）：
+
+**Part1 展示清单**：
+- 场景名称（完整原文）
+- 全部标签（逐条列出）
+- 场景描述全文（训练对象/业务情境/训练目标/边界条件——全部段落完整展示）
+- 考核关键点（逐条原文）
+- 场景语言
+
+**Part2 展示清单**：
+- AI角色整体设定 OS 全文（核心铁律/状态机/双层逻辑/行为模拟规范/知识库合规——全部章节完整原文）
+- 每个角色卡逐字段展示：名称/描述/沟通风格/MBTI/性格/标签/禁忌/知识水平
+- 角色背景四段深度画像完整正文（我是谁/我的困扰/我的过往经历/我今天的心态——四段全部完整展示）
+- **隐藏字段**（不向用户展示）：`scenario_role_id`、来源类型、专项技能与触发器、`avatar`（平台头像资源）、`voice_id`（平台语音资源）——以上为平台元数据/内部配置
+
+**Part3 展示清单**：
+- 开场引导语完整原文
+- 每个环节完整展示：环节名/学员目标完整原文/AI任务完整原文（含环节进入条件+IF-THEN逻辑+环节退出条件）/最大轮次
+- **隐藏字段**（不向用户展示）：开场语类型——由 AI 根据开场内容智能判断（系统旁白式→2 学员先开口；AI直发式→1 AI先开口）
+
+**Part4 展示清单**：
+- 评分标准名称
+- 评分标准描述完整原文
+- 每个评分维度展示：名称/描述/权重
+- **隐藏字段**（不向用户展示）：维度 `code`、`scoring_rule` 分档标准全文、`criteria` 评分点列表、`sort_order` 排序号——以上为平台评分引擎内部字段
+
+**Part5 展示清单**：
+- 练习时间：默认关闭（不限时）
+- 最大练习次数：10 次
+- 通关分数：60 分
+- 通关难度：中（默认锁定，不可调整）
+- AI助答：开启
+- **隐藏字段**（不向用户展示）：`completion_rule`（写死 `all_steps`）——平台固定配置
+
+##### 协议阶段 1 自检（内部执行，不对用户展示）
+
+展示完成后，**必须内部自检后再弹窗**。逐项确认以下清单（**此清单仅在内部推理中执行，不得以文本/表格/Markdown 形式展示在对话窗口给用户看**）：
+
+```
+☐ Part 内容已全部在对话中以纯文本展示（非弹窗中展示）
+☐ 展示内容未使用 Markdown 表格格式（仅允许纯文本段落/列表）
+☐ 无"……""（略）""（同上）""详见材料""（下略）"等缩略标记
+☐ Part2 未展示 scenario_role_id、来源类型、专项技能与触发器、avatar、voice_id
+☐ Part2 每个角色的 background 四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）均已逐段完整展示，无缩略
+☐ Part4 未展示维度 code、scoring_rule 分档全文、criteria 列表、sort_order
+☐ Part5 未展示 completion_rule；pass_difficulty 已展示为"中（默认锁定）"
+☐ 角色卡已展示全部面向用户字段，非仅名称
+☐ 场景描述/OS/背景/评分规则已展示全文，非仅标题或首句
+☐ 未先写入 JSON 再展示（必须先展示，后生成 JSON）
+☐ Part5 练习配置各字段值和说明已完整展示
+☐ Part3 开场语类型未展示给用户（内部根据开场内容智能判断）
+```
+
+> 🔴 **自检任一未通过 → 禁止弹窗 → 回退重新完整展示 → 再次内部自检 → 全部通过后方可进入协议阶段 2。**
+>
+> ⚠️ **展示规则**：自检清单和自检结果**严禁写入对话窗口**。只在内部推理中执行判断，通过后直接进入协议阶段 2 弹窗。若未通过，回退重新展示时也只展示修正后的内容，不解释"之前某处缩略"。
+
+##### 协议阶段 2：用户确认（必须提供按钮弹窗选项）
+
+协议阶段 1 自检全部通过后，**必须使用 `AskUserQuestion` 工具提供确认弹窗**，选项映射如下：
+
+| Part | 弹窗标题 | 选项 1（推荐） | 选项 2 | 选项 3 |
+|------|---------|--------------|--------|--------|
+| Part1 | 场景确认 | 确认，同步到平台（推荐） | 内容需要微调 | — |
+| Part2 | 角色确认 | 确认，同步角色（推荐） | 调整角色设定 | 重设角色设定 |
+| Part3 | 流程设置确认 | 确认，同步流程设置（推荐） | 调整流程设置 | 重设流程设置 |
+| Part4 | 评分确认 | 确认，同步评分（推荐） | 调整评分标准 | 重设评分标准 |
+| Part5 | 教练设置确认 | 确认，完成创建（推荐） | 调整教练设置 | 重设教练设置 |
+
+**选项分支路由：**
+- 用户选选项 1（推荐）→ 生成 JSON → preview + apply → 更新 state-snapshot → 进入下一 Part
+- 用户选选项 2（微调）→ 局部修改后，重新执行本 Part 的协议阶段 1+2
+- 用户选选项 3（重设）→ 回到内容层重新生成该 Part，重新执行协议阶段 1+2
+
+> ⚠️ **Part1 确认后强制同步到平台**：模板 1 不提供"取消"或"跳过同步"选项。Part1 确认即意味着场景必须创建到平台。
+
+---
+
+#### 流水线执行（Part1-Part5 完整顺序）
+
+```
+Part1 基础信息
+  协议阶段1: 在对话中完整展示 Part1 全部内容
+  协议阶段1自检: 内部逐项确认无缩略无截断
+  协议阶段2: AskUserQuestion 弹窗确认（模板 1）
+  → 生成封面图 → 上传封面 → 生成 step1-create.json → 创建场景 → 更新 state-snapshot
+  ↓
+Part2 AI角色设定
+  协议阶段1: 在对话中完整展示 Part2 OS全文+角色卡全部面向用户字段（background 四段深度画像必须逐段完整展示）
+  协议阶段1自检: 内部逐项确认→特别是 background 四段是否完整逐段展示、scenario_role_id/来源类型/专项技能已隐藏
+  协议阶段2: AskUserQuestion 弹窗确认（模板 2）
+  → 生成 part2-operations.json → ⚠️ background 逐字比对闸门（JSON vs 展示文本）→ preview+apply → ⚠️ apply 后逐字段验收（name/description/communication_style/background/personality/tags/knowledge/taboos 逐字段对比 + ai_roles_overall_description 前100字符一致性 + background 四维完整性）→ 验收通过后方可进入匹配头像/声音 → 提取角色性别年龄 → CLI 精准过滤并行查询头像+声音 → ⚠️ 单次 patch_ai_role 合并写入 avatar+voice_id → ⚠️ get-scenario 强制验证 avatar+voice_id 均非空 → 验证失败则重新读取 updated_at 后重试一次 → 仍失败则标注「⚠️ 资源匹配未完成」但继续 Part3（不阻断） → 更新 state-snapshot
+  ↓
+Part3 流程设置
+  协议阶段1: 在对话中完整展示开场语+每个环节的学员目标/AI任务全文
+  协议阶段1自检: 内部逐项确认→特别是环节IF-THEN逻辑是否完整展示
+  协议阶段2: AskUserQuestion 弹窗确认（模板 3）
+  → 生成 part3-operations.json → preview+apply → 更新 state-snapshot
+  ↓
+Part4 评分标准
+  协议阶段1: 在对话中完整展示评分名称+描述+每个维度scoring_rule/criteria全文
+  协议阶段1自检: 内部逐项确认→特别是一票否决是否嵌入各维度scoring_rule
+  协议阶段2: AskUserQuestion 弹窗确认（模板 4）
+  → 生成 part4-operations.json → preview+apply → apply后验收评分同步 → 更新 state-snapshot
+  ↓
+Part5 教练设置
+  协议阶段1: 在对话中向用户展示：练习时间（关闭）/最大练习次数（10）/通关分数（60）/通关难度（中，默认锁定）/AI助答（开启）
+  协议阶段1自检: 内部逐项确认→所有值与固定模板一致、completion_rule 未泄露
+  协议阶段2: AskUserQuestion 弹窗确认（模板 5）
+  → 生成 part5-operations.json → preview+apply → apply后验收练习配置 → 完成摘要
+```
+
+#### 各 Part 专项约束
+
+1. **保持既有 Part1-Part5 输出框架和章节顺序不变**
+2. **Part1 封面**：确认后先生成封面图（场景名称+标签+行业为 prompt），上传后获得 CDN URL 再创建场景，不得使用默认占位图
+3. **Part2 角色背景来源与完整性**：必须来自用户上传的业务材料，禁止 AI 凭空编造。若材料不足以支撑角色背景，标注"⚠️ 材料不足"并追问用户补充。`background` 字段直接复制四段深度画像全文，不压缩不修改。**⚠️ JSON 写入后、preview 前强制闸门**：生成 `part2-operations.json` 后，必须逐字比对每个角色的 `role_data.background` 与 Part2 展示中的「角色背景」文本是否完全一致（标点、措辞、空格均不可有差异），同时确认四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）全部完整。**任一项不通过 → 驳回修正，禁止直接 preview。** 这是最高频疏漏场景——背景文本在 JSON 生成阶段被截断/缩略/改写
+4. **Part2 头像/声音自动匹配 + apply 后逐字段验收（CLI 过滤模式 v2.0）**：角色 apply 后，**先从角色卡提取性别(gender)和年龄(age_group)**，映射为 CLI 的 `--gender` / `--age-group` 参数，再调用 `+list-role-avatars` / `+list-role-voices` 精准过滤查询（详见 `references/role-resource-matching.md`）。匹配失败时自动降级（去年龄→去性别→全量默认）。**apply 后立即逐字段验收**：执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty`，对比以下全部项，**任一不一致 → 判定同步失败，禁止进入 Part3**：
+   - `ai_roles` 数组长度 = JSON 角色数
+   - 每个角色逐字段（name/description/communication_style/background/personality_type/personality/tags/knowledge_level/taboos_objections）与 JSON 逐字一致
+   - `ai_roles_overall_description` 非空且前 100 字符与 OS 原文一致（确保 OS 完整写入非丢失）
+   - `role_data.name` ≠ `"角色数据异常"`（出现此值 → 检查外壳字段是否误放入 `role_data` 内部）
+   - `background` 四段完整（我是谁/我的困扰/我的过往经历/我今天的心态）
+   - **同步失败处理**：回退检查 JSON 结构（data.roles vs data.ai_roles、外壳字段层级、字段类型），修正后重新 preview+apply+验收，不得带缺陷进入 Part3
+   - **⚠️ avatar/voice_id 验收规则变更**：角色首次 apply 时 `avatar`/`voice_id` 留空（`""`），此阶段验收不检查 avatar/voice_id 是否为非空。验收通过后，进入下方「头像/声音资源回填」流程完成写入并二次验证。
+
+**⚠️ 头像/声音资源回填（apply 验收通过后强制执行）**：
+
+   角色逐字段验收通过后，立即执行资源匹配并**合并为单次 patch_ai_role 写入**：
+
+   a. 提取角色性别(gender) + 年龄(age_group) → CLI 过滤参数
+   b. **并行查询**：`+list-role-avatars` + `+list-role-voices`（同时发起，节省往返时间）
+   c. **合并写入**：将 avatar URL + voice_id 写入**同一个** `patch_ai_role` 操作，`customized_fields` 写 `["avatar", "voice_id"]`
+      - 禁止分两次 patch_ai_role：分开调用会导致第二次 patch 的 `updated_at` 变化后第一次写入的 avatar/voice_id 被后续 get 验证误判为丢失
+   d. **强制验证**：patch apply 后立即执行 `soke-cli ai-training +get-scenario --pretty`，确认每个角色的 `avatar` 非空 URL、`voice_id` 非空 ID
+   e. **重试机制**：任一角色 avatar/voice_id 为空 → 重新读取场景 `updated_at`，重新生成 patch，重试 1 次
+   f. **降级处理**：重试后仍失败 → 标注「⚠️ {角色名} 资源匹配未完成」，**不阻断 Part3**，但必须在最终交付摘要中提醒用户手动补充
+5. **⚠️ Part2 JSON 关键结构规则**：
+   - `replace_ai_roles` 数据键用 `data.roles`（非 `data.ai_roles`）
+   - `role_data.avatar` 写头像资源 **URL**（来自 `+list-role-avatars` 的 `url` 字段），严禁用 `id`
+   - `role_data.voice_id` 写声音资源 **ID**（来自 `+list-role-voices` 的 `id` 字段）
+   - 每个角色必须提供 `scenario_role_id` 便于后续 `patch_ai_role` 定位
+   - **⚠️ 外壳字段在外层**：`customization_level`、`is_custom_role`、`customized_fields`、`source_type`、`created_at`、`updated_at` 放在与 `role_data` 和 `scenario_role_id` 同级的外层，**不可写入 `role_data` 内部**——写入内部触发"角色数据异常"
+   - **⚠️ generate → checklist → preview**：生成 `part2-operations.json` 后，**必须先对照 `platform/sync-engine.md`「Part2 replace_ai_roles 自查清单」逐项核对 14 项**，全部通过后方可 preview。最常见的写入失败根因是 `data.roles` 错写成 `data.ai_roles`（占比 80%+）
+6. 平台同步优先按 `platform/sync-engine.md` 的 Partwise 流程；执行前参考 `references/platform-api-pitfalls.md`；复制命令统一参考 `references/verified-cli-cheatsheet.md`
+7. 仅在知识库超长或用户明确要求知识包时，才追加调度 `platform/soke-ai-training/soke-ai-training.md`
+8. prompt-engineer 内部一致性扫描在每个 Part 生成后自动执行；无告警不输出，有告警才提示 ⚠️
+9. **Part3 开场语类型智能判断**：`opening_dialogue_type` 不固定值，由 AI 根据开场引导语内容自动判断——系统旁白叙事式→2（学员先开口），AI角色直发式→1（AI先开口）。此字段不向用户展示
+10. **Part4 apply 后强制验收**：立即执行 `soke-cli ai-training +get-scenario --pretty` 验证 `scoring_criteria_config.criteria_data.dimensions` 非空。**生成 part4-operations.json 后，必须先对照 `platform/sync-engine.md`「Part4 replace_scoring_criteria_config 自查清单」逐项核对 13 项**，全部通过后方可 preview。#1 最高频错误：漏掉 `config` 包裹层，`criteria_data` 直接放 `data` 下
+11. **⚠️ Part4 禁止金牌话术**：`scoring_rule` 和 `criteria` 中禁止出现引号包裹的示例对话（如"太好了谢谢姐！"），评分规则仅描述行为标准和得分条件
+12. **⚠️ Part4 一票否决嵌入维度**：不再使用全局 `one_vote_veto` 字段。每个维度的一票否决写在 `scoring_rule` 末尾（格式"以下行为触犯即该维度0分且总分不合格：…"）
+13. **⚠️ Part5 练习配置固定模板**：`min_practice_duration`=0, `max_practice_duration`=0, `max_practice_attempts`=10, `passing_score`=60, `pass_difficulty`=2（中，默认锁定不可调整）, `completion_rule`="all_steps"（写死，不展示）, `ai_assistance_enabled`=true。所有场景统一，不提供"调整"选项。不含收尾话术/SOP摘要/考核关键点摘要——这些已在 Part1 或 Part3 中同步。`completion_rule` 不向用户展示
+14. **每个 Part JSON 生成后必须先对照 `platform/sync-engine.md` 对应自查清单逐项核对，全部通过后方可 preview**：
+   - Part1 → `step1-create.json 自查清单`（7 项）：最高频错误 `key_points` 写成数组
+   - Part2 → `replace_ai_roles 自查清单`（14 项）：最高频错误 `data.roles` 误写为 `data.ai_roles`
+   - Part3 → `Part3 operations 自查清单`（8 项）：最高频错误 `opening_dialogue_type` 写成字符串
+   - Part4 → `replace_scoring_criteria_config 自查清单`（13 项）：最高频错误漏 `config` 包裹层
+   - Part5 → `Part5 operations 自查清单`（9 项）：最高频错误混入非练习配置字段
+
+> 🚦 **闸门**：每个 Part 必须完整走完「协议阶段 1 展示 → 自检 → 协议阶段 2 确认」三步骤。任一步未完成或未通过，不得进入下一 Part。Part5 确认后进入 Step 6。
+
+---
+
+### Step 6: 平台同步验证
+
+> 内容生成完成后，确认所有 Part 已成功同步到 MentorAI 平台，且 JSON 内容与平台存储一致。
+
+1. 读取 `state-snapshot.json`，验证所有 Part 的 `applied` 状态均为 `true`
+2. 执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty` 获取最终平台状态
+3. **逐字段验证 JSON 内容已同步**：对照各 Part 的 JSON 文件与平台返回结果，逐字段比对：
+   - `key_points`、`description`、`name`、`tags` → 与 `step1-create.json` 一致
+   - **Part2 关键验收**：`ai_roles` 非空、`ai_roles[].role_data.name` ≠ `"角色数据异常"`、`ai_roles[].role_data.avatar` 非空 URL、`ai_roles[].role_data.voice_id` 非空 ID。若 name 为"角色数据异常"，回退检查 part2-operations.json 中外壳字段是否误放 `role_data` 内
+   - `scoring_criteria_config.criteria_data.dimensions` → 维度数量、名称、权重与 `part4-operations.json` 一致
+   - `passing_score`、`pass_difficulty`、`max_practice_attempts` 等练习配置 → 与 `part5-operations.json` 一致
+4. 记录最终的 `scenario_id` 和平台 URL
+
+> 🚦 **闸门**：所有 Part 必须 `applied: true`，平台状态验证通过，且关键字段内容与 JSON 一致，方可进入 Step 7。
+
+---
+
+### Step 7: 创建质量闸门（10 项）
+
+> ⚠️ **交付前必做**：完成全部生成和同步后，必须逐项通过以下 10 项闸门（定义详见「质量闸门 → 创建闸门」节）。任一未通过，返回对应步骤修复，修复后重新执行本闸门。
+>
+> 📺 **以下闸门检查在内部推理中执行，严禁将逐项检查结果以任何形式（文本/表格/Markdown/代码块）输出到对话窗口。** 闸门全部通过后，仅在对话中输出一行摘要「✅ 质量闸门全部通过」。如有 ❌ 项，只在对话中告知用户"需返回 Step N 修复 X 问题"，不列出逐项明细。
+
+内部检查清单（不在对话窗展示）：
+
+| # | 检查项 | 状态 | 来源步骤 | 不通过时的处理 |
+|---|--------|------|---------|---------------|
+| 1 | 材料完整 | ✅ / ❌ | Step 1 | 返回 Step 1 补材料 |
+| 2 | 场景拆解合理 | ✅ / ❌ | Step 2 | 返回 Step 2 重新判定 |
+| 3 | 角色行为化 | ✅ / ❌ | Part2 | 返回 Step 5 Part2 调整 |
+| 4 | 信息释放规则明确 | ✅ / ❌ | Part2 | 返回 Step 5 Part2 调整 |
+| 5 | 每阶段有明确的进入/退出条件 | ✅ / ❌ | Part3 | 返回 Step 5 Part3 调整 |
+| 6 | 评分可识别（含一票否决嵌入维度） | ✅ / ❌ | Part4 | 返回 Step 5 Part4 调整 |
+| 7 | 练习配置匹配固定模板 | ✅ / ❌ | Part5 | 返回 Step 5 Part5 修正为固定值 |
+| 8 | 有测试用例 | ✅ / ❌ | - | 补充测试用例 |
+| 9 | 整体设定节去空白字符 ≤ 3000 | ✅ / ❌ | Part2 | 返回 Step 5 Part2 压缩 |
+| 10 | 每个 Part 内容已在对话中完整展示 | ✅ / ❌ | Step 5 | 回退重新完整展示 |
+
+> 🚦 **闸门**：10 项全部 ✅ 后方可进入 Step 8。如有 ❌，必须回到对应步骤修复后重新跑本闸门，不得带缺陷交付。
+
+---
+
+### Step 8: 场景发布
+
+> 质量闸门全部通过后，执行场景发布，使其在 MentorAI 平台正式生效。
+
+#### 8.1 执行发布
+
+```bash
+soke-cli ai-training +publish-scenario \
+  --scenario-id <scenario_id> \
+  --version 1 \
+  --version-description "CLI发布" \
+  --pretty
+```
+
+参数说明：
+| 参数 | 说明 |
+|---|---|
+| `--scenario-id` | 必填，AI 陪练场景 ID |
+| `--version` | 发布版本号，默认 1 |
+| `--version-description` | 发布版本说明，默认 `CLI发布` |
+
+#### 8.2 发布后验收
+
+执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty`，确认场景状态为已发布。
+
+> 🚦 **闸门**：发布成功后方可交付。若发布返回 409/422，使用 `--raw` 查看完整错误，排查原因后重试。
+
+---
+
+## 微调型任务流程
+
+1. 收集微调输入包
+2. 🚨 **确认分析对象**:在陪练对话中,"AI"和"学员"是两个不同角色。诊断前必须先声明"本次分析对象是 AI(客户角色)还是学员"。AI模拟客户让学员练习的场景中,诊断对象为 AI(客户角色),分析其角色一致性、对话自然度、问题随机性等;学员的应对不当不应混入 AI 诊断标签
+3. 判断是否为技术/产品问题
+4. 使用 F/I/O/L/E/S/R/K/T/D 标签诊断(见「微调诊断标签」节)
+5. 匹配资产库
+6. 调度 `prompt-optimizer`
+7. 输出标注版改稿、复测方案和版本记录建议
+
+### 微调输入包
+
+必须尽量收集:
+
+- 当前提示词
+- 原始对话记录
+- 用户反馈原话
+- 期望表现
+- 场景类型
+- 当前评分结果
+- 音频/转写文本,如涉及语音
+- 设备/账号/操作路径,如涉及技术
+
+### 缺失规则
+
+| 缺失项 | 处理方式 |
+|--------|---------|
+| 无原始对话 | 只能做结构审查,不断言具体行为偏差 |
+| 无当前提示词 | 只能给优化方向,不输出最终修改版 |
+| 只有"感觉不像" | 追问具体对话片段或期望表现 |
+
+---
+
+## 平台同步前置
+
+**创建型和平台同步型**任务在调用平台接口前,都必须先执行环境检测。
+
+创建型流程在内容生成之前完成检测(见「创建型任务流程（严格顺序管线）→ Step 0」)。
+
+平台同步型(任务类型 5)单独触发时,同样执行:
+
+> ⚠️ 与创建型流程相同，所有 soke-cli 命令必须设置 `dangerouslyDisableSandbox: true` 绕过沙箱。
+
+```
+read references/env-check.md
+按顺序执行 4 步检测:
+  1. node --version → 确认 >= 14
+  2. which soke-cli → 确认已安装
+  3. soke-cli config show → 确认含 user_token
+  4. soke-cli config show → 确认 implementation_corp_id / corpid 至少一个非空
+
+全部通过 → 优先执行 platform/sync-engine.md 的 Partwise 同步流(Step1 create → Part2 → Part3 → Part4 → Part5)
+需要复制或核对命令时 → 统一参考 references/verified-cli-cheatsheet.md
+任一步失败 → 按 references/env-check.md 修复流程引导,不进入同步
+```
+
+检测到 corpid 后记录,后续 CLI 命令创建的场景自动归属该企业。
+
+---
+
+## 技术问题分流
+
+凡涉及以下问题,优先按技术/产品问题处理,**不要直接交给 prompt-optimizer 改提示词**:
+
+- ASR识别错误
+- 语音尾字丢失
+- TTS声音不符合角色
+- 播报没结束就跳评分页
+- 授权不同步
+- 部门同步失败
+- 按钮报错
+- iOS录音权限未释放
+- 评分等待无提示
+
+---
+
+## 微调诊断标签
+
+| 标签 | 含义 | 判定要点 |
+|------|------|---------|
+| **F** | 格式违规 | 括号动作、Markdown语法、后台痕迹外显 |
+| **I** | 信息释放违规 | 开场透露全部症状/底线/背景 |
+| **O** | 角色OOC | 太热情/太攻击/说出不该说的术语 |
+| **P** | 指令执行度违规 | AI实际行为与提示词行为指令不一致 |
+| **N** | 对话自然度违规 | 模板化、万能回应、句式单一、过渡生硬 |
+| **L** | 逻辑违规 | 信任值异常、价格防线过早松动 |
+| **E** | 结束违规 | 提前结束、成交后继续追问 |
+| **S** | 场景规则违规 | 违反药房/合规/B2B场景规则 |
+| **R** | 评分规则问题 | 评分项抽象、目标错位、无法识别间接达成 |
+| **K** | 知识/合规问题 | 产品知识错误、禁用话术未触发 |
+| **T** | 技术/体验问题 | ASR/TTS/权限/跳转 |
+| **D** | 数据/看板问题 | 指标口径错误、数据污染 |
+
+**没有标签,不进入修改建议。**
+
+### 诊断分析顺序(必须严格按此顺序)
+
+```
+T排障 → O拟真 → P指令执行 → N自然度 → I信息释放/K知识 → E结束/S场景 → L逻辑/F格式 → R评分
+```
+
+- **P 在第 3 位**:先确认角色没崩(O),再查指令执行度(P),避免角色OOC导致P误判
+- **N 在第 4 位**:先确认行为指令合规(P),再查表达是否自然(N)。模板化"好的""了解了"等万能回应属于 N 违规而非 O 或 F 问题
+
+---
+
+## prompt-engineer 调用硬约束
+
+> 此节规则在「创建型任务流程 → Step 5: 内容生成」中被强制引用。调度 prompt-engineer 时必须同时满足以下约束和 Step 5 的流水线顺序要求。
+
+### Part 确认协议（引用 Step 5 统一协议）
+
+每个 Part 的确认必须严格遵循 **「创建型任务流程 → Step 5 → 每个 Part 的确认协议」** 定义的两阶段协议：
+- **协议阶段 1**：先在对话框中逐字段完整展示该 Part 的全部内容 → 执行自检清单
+- **协议阶段 2**：自检通过后，用 `AskUserQuestion` 提供确认弹窗选项
+
+**详细展示清单、自检项、弹窗选项路由均以 Step 5 主协议为准，此处不重复。**
+
+### 内容生成硬约束
+
+用户明确要求：搭建提示词/陪练内容时，`prompt-engineer` 输出框架不要变。
+
+1. 保持既有 Part1-Part5 输出框架和章节顺序
+2. 不重排整体框架
+3. 不把非标准模块插入角色设定、流程设置或其他既有模块内部
+4. Part4 评分标准仅输出评分维度、权重、评分规则、评分点，一票否决嵌入各维度 scoring_rule，不包含知识库内容
+5. **⚠️ Part4 scoring_rule 禁止嵌入示例话术**：评分规则中禁止出现引号包裹的示例对话，这些属于金牌话术库，不写入平台
+6. **⚠️ Part4 无全局 one_vote_veto**：一票否决条件已嵌入各维度 `scoring_rule`，不再使用全局 `one_vote_veto` 字段
+7. **⚠️ Part2 角色资源匹配走 CLI 过滤模式**：头像/声音匹配必须先提取角色性别(gender)和年龄(age_group)，映射为 CLI 的 `--gender` / `--age-group` 参数，再精准过滤查询。禁止拉取全量库后做文本匹配。匹配失败时自动降级（去年龄→去性别→全量默认）。详见 `references/role-resource-matching.md`
+8. **⚠️ Part2 avatar 用 URL 非 ID**：`role_data.avatar` 写入 `+list-role-avatars` 返回的 `url` 字段，严禁用 `id`
+9. **⚠️ Part2 replace_ai_roles 用 data.roles**：数据键是 `data.roles`（非 `data.ai_roles`），必须带 `scenario_role_id`
+10. **⚠️ Part2 外壳字段在外层**：`customization_level`、`is_custom_role`、`customized_fields`、`source_type`、`created_at`、`updated_at` 必须与 `role_data`、`scenario_role_id` 同级（外层），**严禁**写入 `role_data` 内部。写入内部会触发平台回读 `name: "角色数据异常"`，全部字段 null。判断规则：描述"角色有什么属性"→ `role_data` 内；描述"这个数据是什么类型/何时创建"→ 外层。详见 `references/platform-api-pitfalls.md` §4.1
+11. **⚠️ Part2 background 必填不可漏**：`role_data.background` 必须包含四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态），**严禁留空或 null**。这是最常见疏漏——replace_ai_roles 中写了其他字段但忘记 background。apply 后验收时检查 `ai_roles[].role_data.background` 非空
+12. **⚠️ Part5 练习配置已写死**：Part5 operations 使用固定模板（时长关闭、最大次数 10、通关分数 60、通关难度 中=2 默认锁定、完成规则 all_steps、AI助答开启）。所有场景统一，不含收尾话术、SOP 流程摘要、考核关键点摘要——这些已在 Part1/Part3 中同步。`completion_rule` 不向用户展示；`pass_difficulty`=2（中）向用户展示但不可调整
+13. **⚠️ `add_conversation_step` 数据不持久化**：平台 CLI v1.0.66 存在已知 bug——`add_conversation_step` apply 返回 snapshot_id 但数据不保存，`get-scenario` 始终返回空 steps。创建型流程的对话步骤需在 MentorAI Web 管理后台手动补充。`replace_conversation_steps` 同样不可用（422 校验拒绝）。仅 `create-scenario --request-file` 中 `conversation_steps` 全量创建时可写入，但会同时忽略 `ai_roles` 和 `scoring_criteria_config` 等复杂字段。详见 `references/platform-api-pitfalls.md`
+
+---
+
+## 质量闸门
+
+> 💡 自主学习示例与推广案例详见 `references/self-improvement-examples.md`
+>
+> 创建型任务交付前，须在「创建型任务流程 → Step 7」中逐项执行以下闸门检查。
+
+### 创建闸门(10 项)
+
+1. 材料完整
+2. 场景拆解合理
+3. 角色行为化
+4. 信息释放规则明确
+5. 每个阶段有明确的进入/退出条件
+6. 评分可识别（含一票否决嵌入各维度 scoring_rule）
+7. 练习配置匹配固定模板
+8. 有测试用例
+9. `整体设定` 节去空白字符 ≤ 3000,阶段专属规则已下沉到 `流程设置` 对应环节
+10. 每个 Part 内容已在对话中完整展示（无截断、缩略、省略号，逐字段原文可见）
+
+### 微调闸门(8 项)
+
+1. 有证据
+2. 已技术分流
+3. 已打标签
+4. 有修改决策
+5. 有标注改稿
+6. 有复测方案
+7. 有版本记录建议
+8. 微调后 `整体设定` 节去空白字符 ≤ 3000
+
+---
+
+## 输出格式
+
+任务开始前先输出:
+
+```markdown
+## 🎯 意图识别
+- 任务类型:
+- 建议链路:
+- 当前管线步骤: [创建型任务需标注当前应执行的 Step N]
+- 必读资产:
+- 输入缺口:
+- 下一步:
+```
+
+> 创建型任务必须在上方标注当前管线进度（如"Step 1: 材料接收与完整性检查"），并与「创建型任务流程（严格顺序管线）」中的 Step 编号对应。
+
+如果用户明确说"直接做/不用确认",可跳过确认,但**不能跳过输入质检和技术分流**。
+
+---
+
+# 自主学习与自我进化引擎
+
+> 核心思想:每一次诊断纠错、闸门漏拦、资产选错、子技能调度失败、用户纠正,都被自动记录并推广为永久规则。
+> 本引擎是独立 self-improving-agent 思想与 AI 陪练领域的深度整合,在泛用框架之上注入了 12 个 AI 陪练专属 Area、诊断分流触发规则和陪练推广目标表。
+
+## 引擎架构
+
+```
+用户纠正 / 命令失败 / 闸门漏拦 / 新需求
+  ↓ 自动捕获
+├─ 修正/洞察/缺口/最佳实践 → .learnings/LEARNINGS.md
+├─ 命令失败/集成异常        → .learnings/ERRORS.md
+├─ 用户请求的新能力          → .learnings/FEATURE_REQUESTS.md
+  ↓ 自我反思(每次完成任务后)
+├─ 结果是否达到预期?
+├─ 哪里可以更好?
+├─ 这是反复出现的模式吗?
+  ↓ 模式检测(同类 ≥ 3 次 + 跨 ≥ 2 任务 + 30 天内)
+↓ 自动推广
+├─ 行为改进 → 本 SKILL.md(诊断标签/闸门/资产规则/调度流程)
+├─ 工具坑点 → TOOLS.md
+├─ 调度规则 → AGENTS.md
+├─ 长期记忆 → MEMORY.md
+└─ 高价值 → 提取为独立 skill
+```
+
+## 学习存储分层
+
+| 层级 | 位置 | 容量限制 | 加载策略 |
+|------|------|---------|---------|
+| **HOT** | `.learnings/` 中 Priority=critical/high 且 Status=pending 的条目 | 无限制 | 任务开始时扫描 |
+| **WARM** | `.learnings/` 中 Priority=medium 或已 resolved 的条目 | 无限制 | 按 Area 匹配时加载 |
+| **COLD** | 已 promoted / wont_fix / 90 天以上未触发的条目 | 无限 | 显式查询时加载 |
+
+### 分层规则
+
+- Pattern 触发 3 次/7 天内 → 提升 Priority 至 high
+- Pattern 30 天未触发 → 降 Priority 至 low
+- Pattern 90 天未触发 → 归档为 COLD(不改动,仅标记)
+- **绝不删除**已确认的学习条目
+
+## 学习文件初始化
+
+首次使用时,确保 `.learnings/` 目录及文件存在:
+
+```bash
+mkdir -p .learnings
+[ -f .learnings/LEARNINGS.md ] || printf "# AI 陪练 - 学习日志\n\n修正、洞察、知识缺口、最佳实践。\n\n**类别**: correction | insight | knowledge_gap | best_practice\n\n---\n" > .learnings/LEARNINGS.md
+[ -f .learnings/ERRORS.md ] || printf "# AI 陪练 - 错误日志\n\n命令失败与集成异常。\n\n---\n" > .learnings/ERRORS.md
+[ -f .learnings/FEATURE_REQUESTS.md ] || printf "# AI 陪练 - 功能请求\n\n用户请求的新能力。\n\n---\n" > .learnings/FEATURE_REQUESTS.md
+```
+
+不覆盖已有文件。**绝不记录**密钥、token、完整对话抄本或敏感环境变量。
+
+---
+
+## AI 陪练专属 Area 标签
+
+| Area | 范围 |
+|------|------|
+| `coaching/prompt` | 提示词创建、优化、微调 |
+| `coaching/role` | 角色生成、拟真度(按需画像为增强能力) |
+| `coaching/script` | 交互剧本、流程设置 |
+| `coaching/knowledge` | 知识库构建、内容提取 |
+| `coaching/scoring` | 评分标准、评分逻辑 |
+| `diagnosis` | 诊断标签(F/I/O/P/N/L/E/S/R/K/T/D)的判定与排序 |
+| `quality-gate` | 创建闸门、微调闸门 |
+| `asset` | 资产库调用、匹配规则 |
+| `platform/sync` | 平台同步、环境检测、平台创建 |
+| `delivery` | 客户交付、培训包、看板 |
+| `cfg` | 配置、路径、环境变量 |
+
+---
+
+## 学习信号检测
+
+### 自动触发记录的场景
+
+| 场景 | 写入位置 | 类别 |
+|------|---------|------|
+| 用户纠正诊断标签归属 | LEARNINGS.md | `correction` |
+| 诊断顺序导致误判(如先P后O) | LEARNINGS.md | `correction` |
+| 闸门漏拦导致交付问题 | LEARNINGS.md | `correction` |
+| 资产选错导致分析偏差 | LEARNINGS.md | `correction` |
+| 子技能输出异常 | ERRORS.md | - |
+| 平台同步环境检测失败 | ERRORS.md | - |
+| 命令返回非零/超时/权限拒绝 | ERRORS.md | - |
+| "能不能也支持XX场景" | FEATURE_REQUESTS.md | - |
+| "为什么不能XX" | FEATURE_REQUESTS.md | - |
+| 发现新的诊断模式或标签 | LEARNINGS.md | `insight` |
+| 用户传授新的陪练业务规则 | LEARNINGS.md | `knowledge_gap` |
+| 找到比现有方法更好的流程 | LEARNINGS.md | `best_practice` |
+
+### 识别人工纠正的关键词
+
+- "不对"、"不是这样"、"应该是"、"实际上"、"你搞错了"
+- "这不是X标签,是Y标签"
+- "先查X再查Y"
+- "这个资产不对,应该用XX"
+- "闸门没拦住,少检查了XX"
+- "别"、"停止"、"以后不要"
+- "我更喜欢"、"我一向都是"
+
+### 识别偏好信号的关键词(直接记录到 SKILL.md 对应节)
+
+- "我喜欢你这样" → 强化当前行为
+- "每次都帮我做X" → 写入对应流程
+- "不要做Y" → 写入对应约束
+- "我的风格是" → 写入输出格式
+
+### 识别新需求的关键词
+
+- "能不能也"、"可以支持吗"、"为什么不"、"有没有办法"、"我想"
+
+### 以下情况不记录
+
+- 一次性指令("查一下这个文件")
+- 上下文相关("在这个场景里")
+- 假设性问题("如果怎么做会怎样")
+- 用户没有反馈时的沉默推断
+
+---
+
+## 日志格式
+
+### 学习条目(LEARNINGS.md)
+
+```markdown
+## [LRN-YYYYMMDD-XXX] category
+
+**Logged**: ISO-8601 timestamp
+**Priority**: low | medium | high | critical
+**Status**: pending
+**Area**: coaching/prompt | diagnosis | quality-gate | asset | ...
+
+### Summary
+一句话描述学到了什么
+
+### Details
+完整上下文:发生了什么、错在哪、正确的是什么
+
+### Suggested Action
+具体的修复或改进措施
+
+### Metadata
+- Source: conversation | error | user_feedback | self_reflection
+- Related Files: 涉及的文件路径
+- Tags: 标签
+- See Also: LRN-xxxxxxxxx-xxx(如与已有条目关联)
+- Pattern-Key: 可选,用于跨任务模式追踪
+- Recurrence-Count: 1
+- First-Seen: YYYY-MM-DD
+- Last-Seen: YYYY-MM-DD
+
+---
+```
+
+### 错误条目(ERRORS.md)
+
+```markdown
+## [ERR-YYYYMMDD-XXX] skill_or_command
+
+**Logged**: ISO-8601 timestamp
+**Priority**: high
+**Status**: pending
+**Area**: ...
+
+### Summary
+简要描述失败原因
+
+### Error
+\`\`\`
+实际错误消息
+\`\`\`
+
+### Context
+- 执行的命令/操作
+- 输入参数
+- 环境信息(如有)
+
+### Suggested Fix
+可识别的修复方案
+
+### Metadata
+- Reproducible: yes | no | unknown
+- Related Files: 路径
+- See Also: ERR-xxxxxxxxx-xxx(如反复出现)
+
+---
+```
+
+### 功能请求(FEATURE_REQUESTS.md)
+
+```markdown
+## [FEAT-YYYYMMDD-XXX] capability_name
+
+**Logged**: ISO-8601 timestamp
+**Priority**: medium
+**Status**: pending
+**Area**: ...
+
+### Requested Capability
+用户想要什么能力
+
+### User Context
+为什么需要、解决什么问题
+
+### Complexity Estimate
+simple | medium | complex
+
+### Suggested Implementation
+可能的实现方式
+
+### Metadata
+- Frequency: first_time | recurring
+- Related Features: 关联现有功能
+
+---
+```
+
+### ID 生成规则
+
+格式:`TYPE-YYYYMMDD-XXX`
+- TYPE: `LRN`(学习)、`ERR`(错误)、`FEAT`(功能请求)
+- 日期: 当前日期
+- 序号: 三位数 `001`、`002`...
+
+示例:`LRN-20260708-001`、`ERR-20260708-001`、`FEAT-20260708-001`
+
+---
+
+## 自我反思机制
+
+每完成一个完整任务后,主动执行三问反思:
+
+### 反思模板
+
+```
+CONTEXT: [任务类型] - [场景名称]
+REFLECTION: [我注意到什么]
+LESSON: [下次应该怎么做不同]
+```
+
+### 示例
+
+```
+CONTEXT: 微调型任务 - XX保险公司电话约访
+REFLECTION: 先P后O诊断,结果O误判导致P误报。用户指正后调整顺序才找到真正问题
+LESSON: 诊断顺序硬约束:必须先O再P,跳过必错
+```
+
+### 何时反思
+
+- 完成多步骤任务后
+- 收到反馈后(正面或负面)
+- 修复错误后
+- 发现自己的输出可以更好时
+
+反思条目同样遵循推广规则:成功应用 3 次 → 提升 Priority → 满足推广条件后写入本 SKILL.md。
+
+---
+
+## 冲突解决
+
+当学习条目相互矛盾时:
+
+1. **最具体的优先**:项目级 > Area级 > 全局
+2. **最新的优先**(同级时):尊重演化
+3. **模糊不清时** → 追问用户确认
+
+**示例**:
+- 全局规则:"微调时必须跑全部资产库"
+- 项目级规则:"药店场景微调时跳过客户角色模板库(因为药店角色已定型)"
+- → 执行时采用项目级规则
+
+---
+
+## 条目生命周期
+
+### 状态流转
+
+```
+pending → resolved | promoted | promoted_to_skill | wont_fix
+```
+
+### 解决后
+
+1. 改 `**Status**: pending` → `**Status**: resolved`
+2. 追加 Resolution 块:
+
+```markdown
+### Resolution
+- **Resolved**: ISO-8601
+- **Notes**: 简述做了什么
+```
+
+### 推广后
+
+1. 改 `**Status**: pending` → `**Status**: promoted`
+2. 加 `**Promoted**: SKILL.md | AGENTS.md | TOOLS.md | MEMORY.md`
+
+---
+
+## 模式检测与自动推广
+
+### 写入前先查重
+
+```bash
+grep -rn "关键词" .learnings/
+```
+
+- 已有类似条目 → 加 `See Also` 链接,bump 优先级,递增 `Recurrence-Count`
+- 没有 → 新建
+
+### 自动推广条件(满足全部 3 条)
+
+- `Recurrence-Count ≥ 3`
+- 跨至少 2 个不同任务
+- 30 天内出现
+
+### 推广目标
+
+| 学习类型 | 推广到 | 示例 |
+|---------|--------|------|
+| 诊断标签判定修正 | 本 SKILL.md「微调诊断标签」节 | "模板化万能回应归N不归O" |
+| 闸门漏拦 | 本 SKILL.md「质量闸门」节 | "新增第11项:每阶段退出条件" |
+| 资产选错规则 | 本 SKILL.md「资产调用规则」节 | "评分不准时同步查Bad Case库" |
+| 调度顺序优化 | AGENTS.md | "微调前必须先查err-detected" |
+| 工具/命令坑点 | TOOLS.md | "soke-cli login 需要先 node>=14" |
+| 行为模式改进 | SOUL.md | "诊断报告不含未经标签的猜测" |
+| 业务经验 | MEMORY.md | "XX客户偏好电话约访场景" |
+| 高复发价值 | 提取为独立 skill | LRN → skills/coaching-fix-name/ |
+
+### 推广时保持简洁
+
+推广到系统文件时,只写短规则,不写长篇事件描述:
+
+```
+❌ 坏:"2026年7月8日,在处理XX保险公司的陪练微调时,用户指出...经过排查发现..."
+✅ 好:"诊断顺序硬约束:必须先O再P再N,禁止跳过。"
+```
+
+---
+
+## 常见陷阱与应对
+
+| 陷阱 | 为什么危险 | 正确做法 |
+|------|-----------|---------|
+| **从沉默中学习** | 创造虚假规则 | 等待显式纠正或重复证据 |
+| **推广太快** | 污染 HOT 记忆 | 新教训保持 tentative,等待重复 |
+| **把一次性指令当规则** | 过度泛化 | 只有重复 ≥ 3 次且跨任务的才推广 |
+| **压缩时删除** | 丢失信任和历史 | 合并、汇总、或降级,不删除 |
+| **把技术问题当提示词问题** | 无效修改、故障不修复 | 严格走技术分流流程 |
+| **先P后O诊断** | 角色OOC导致P误判 | 强制 T→O→P→N 顺序 |
+| **忽略沉默中的偏好** | 用户懒得说但你该记住 | 偏好信号("我喜欢")→ 立即记录 |
+
+---
+
+## 学习推广示例
+
+### 案例 1:标签判定修正
+
+```
+用户:"这不是N(自然度违规),这是O(角色OOC)"
+→ [LRN-20260708-001] correction,Area: diagnosis
+→ 复发 3 次后推广
+→ 本 SKILL.md「诊断分析顺序」节写入新规则
+```
+
+### 案例 2:闸门漏拦
+
+```
+交付后用户发现结束条件不清晰
+→ [LRN-20260708-002] correction,Area: quality-gate
+→ 推广到「创建闸门」新增:"每个阶段有明确的退出条件"
+```
+
+### 案例 3:资产选错
+
+```
+微调"评分不准"时只查了评分组件库,漏了Bad Case库
+→ [LRN-20260708-003] correction,Area: asset
+→ 推广到「资产调用规则」微调按需选读:
+   "评分不准:必读评分组件库 + 同步查 Bad Case 中同类问题"
+```
+
+---
+
+## 周期性审查
+
+### 何时审查
+
+- 每次大任务开始前
+- 每次交付完成后
+- 每周主动检查一次
+
+### 快速状态
+
+```bash
+# 待处理数量
+grep -ch 'Status\*\*: pending' .learnings/*.md
+
+# 高优先级条目
+grep -B5 'Priority\*\*: high' .learnings/*.md | grep '^## \['
+```
+
+### 审查动作
+
+- 待处理 → 解决 → resolved
+- 满足推广条件 → promoted
+- 关联相关条目 → 加 See Also
+- 反复出现的问题 → 升级为独立 issue
+
+---
+
+## 技能自动提取
+
+### 提取条件(满足任一)
+
+- 有 2+ 个 See Also 关联(反复出现)
+- 状态 resolved 且有可工作修复
+- 需要实际排查才能发现(非显而易见)
+- 跨项目适用
+- 用户明确说"记下来"、"下次别忘了"
+
+### 提取流程
+
+1. 确认候选 learning 满足条件
+2. 使用 `assets/SKILL-TEMPLATE.md` 模板,创建 `skills/<skill-name>/SKILL.md`
+3. 更新原 learning:`**Status**: promoted_to_skill`、加 `Skill-Path`
+4. 在新 session 验证 skill 可独立使用
+
+---
+
+## 与主流程的集成点
+
+### 意图识别阶段
+
+- 检查 `.learnings/` 中是否有与当前任务 Area 匹配的 Priority=high/critical 且 Status=pending 的条目
+- 如有,在「意图识别」输出中追加:`⚠️ 历史学习提醒:XX(LRN-XXX)`
+
+### 诊断阶段
+
+- 每次打完诊断标签后,自动扫描用户反馈中的纠正关键词
+- 如检测到纠正 → 立即修正当前行为 → 异步写入 LEARNINGS.md,任务结束后推广
+
+### 交付阶段
+
+- 交付前跑闸门清单
+- 如闸门漏拦 → 写 LEARNINGS.md,标注 quality-gate Area
+
+### 任务收尾阶段
+
+每个完整任务结束时:
+
+- 执行自我反思(三问)
+- 输出简洁的学习摘要(新条目数量 + 关键洞察)
+- 如有反思 → 写入 LEARNINGS.md
+
+---
+
+## 辅助脚本与模板
+
+| 文件 | 用途 |
+|------|------|
+| `scripts/activator.sh` | 每轮对话后提醒评估学习(可选启用) |
+| `scripts/error-detector.sh` | 命令执行失败时自动检测并提示记录 |
+| `scripts/extract-skill.sh` | 从 learning 提取为新 skill |
+| `assets/LEARNINGS-TEMPLATE.md` | 学习条目记录模板 |
+| `assets/ERRORS-TEMPLATE.md` | 错误条目记录模板 |
+| `assets/FEATURE_REQUESTS-TEMPLATE.md` | 功能请求记录模板 |
+| `assets/SKILL-TEMPLATE.md` | 新技能创建模板 |
+
+---
+
+## 最佳实践
+
+1. **立刻记录** - 上下文在问题刚发生时最新鲜
+2. **具体明确** - 后续的自己需要快速理解
+3. **包含复现步骤** - 特别是错误
+4. **链接相关文件** - 方便修复
+5. **给出具体修复建议** - 不只是"调查一下"
+6. **积极推广** - 拿不准时,推广到本 SKILL.md 比漏掉好
+7. **定期审查** - 过时的 learning 没有价值
+8. **屏蔽敏感信息** - 不记录密钥、token、完整对话抄本
+9. **从纠正中学习,不从沉默中学习** - 没有显式纠正 = 没有教训
+10. **推广前先确认** - 3 次同类纠正后,问一句"这是否可以作为永久规则?"