@sokeai/cli 1.0.75 → 1.0.77

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

@@ -1,1563 +0,0 @@
----
-name: ai-coach-director
-description: AI陪练主管技能。当用户输入业务资料、对话场景、提示词、需求描述、对话问题、评分问题、微调需求或平台同步需求时,自动分析意图、检查输入完整性、调度AI陪练专项技能,并执行资产调用与质量闸门。统一入口,覆盖创建陪练、微调陪练、技术排障、客户交付与平台同步。内置自主学习引擎。v2.20.8:Part 确认后前台不再展示后续后台步骤；Part1 默认封面固定为 lingshou_daogou.png。
-agent_created: true
----
-
-# AI陪练主管技能
-
-## 技能定位
-
-本技能是AI陪练技能体系的**统一调度入口**。它不直接替代专项技能,而是负责:
-
-1. 识别任务类型
-2. 检查输入是否足够
-3. 选择应读取的资产库
-4. 调度对应专项技能
-5. 设置质量闸门
-6. 防止技术问题被误当成提示词问题
-7. 平台同步时执行环境前置检测
-8. 端到端编排:创作 → 同步 → 交付
-9. 自主学习与自我进化:每次纠正、失败、漏拦都记录并推广为永久规则
-10. 当平台真实 API 与历史文档冲突时,以最新 CLI 实证、附件《比得_AI陪练CLI创建与更新场景使用指南 2.0》及 `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 +...` 等），不限于创建型流程
-13. **Part1 封面自动处理 + Part2 拆分同步后台自动执行（v2.14）**：用户在 Part1/Part2 只确认完整内容，不再确认中间执行细节。Part2 确认后，系统先生成完整 `part2-operations.json`，再后台拆分为角色级同步单元（角色1/角色2/角色3/OS），逐个保守写入并回读校验。只有失败时才向用户暴露异常。**若后台同步成功，必须自动继续输出 Part3，禁止停在“正在后台同步”中间态等待用户再次输入。**
-14. **Part3 已知回读问题默认直通（v2.20.3）**：若 Part3 `apply` 成功，但 `get-scenario` 仍未反映 `conversation_steps` 和/或 `opening_dialogue`，按已知平台回读口径异常处理，不再把用户确认 Web 后台可见作为前置闸门。应记录该异常到状态快照，默认继续进入 Part4；仅当 `preview/apply` 本身失败、或后续 Part4/Part5 需要依赖 Part3 字段且出现明确阻塞证据时，才中断排查。
-15. **Part1 封面主策略切换为平台图库择图（v2.20.3）**：Part1 确认后，封面优先从平台图片库/已有真实封面库中选择并写入，作为默认主路径；本地生成图片与上传降级为非主路径，仅在图库/封面库均不可用时才触发。前台仍不展示图片处理过程。
-16. **Part1 创建链路硬约束（v2.20.4）**：Part1 用户确认后，后台**必须立即生成 `part1-create.json` 或沿用 `step1-create.json` 作为创建请求文件，并立即执行 `soke-cli ai-training +create-scenario --request-file ...`**。创建成功后**必须拿到 `scenario_id`** 并写入状态快照。**没有 `scenario_id` 严禁进入 Part2。** 若前台已显示“已确认”但后台未创建成功，必须立即向用户报错并停止，不允许静默继续。
-17. **Part2-Part5 同步成功硬闸门（v2.20.6）**：Part2、Part3、Part4、Part5 在用户确认后，后台都**必须立即生成对应 JSON、执行平台同步、完成验收成功后**，才允许进入下一 Part。若前台已显示“已确认”，但后台未生成 JSON、未执行同步、同步失败、或验收失败，**必须立即向用户报错并停止**，禁止静默继续到后续 Part。**其中 Part2 与 Part3 允许存在“CLI `get-scenario` 回读口径落后于平台实际展示”的已知差异，验收以“preview/apply 成功 + 平台实际展示可见”优先。**
-18. **确认选项 = 后台执行触发器（新增硬约束）**：创建型任务中，所有“确认，同步到平台/同步角色/同步流程设置/同步评分/完成创建”都不是逻辑确认文案，而是**真实后台执行触发器**。用户一旦选择确认，系统必须立即执行：① 生成该 Part 对应 `.json` 文件；② 执行平台同步；③ 执行回读验收。三者缺一不可。**没有 `.json` = 没执行；没有同步成功 = 不得推进；没有验收通过 = 不得视为当前 Part 完成。**
-20. **统一输出参数与文件约定（v2.7）**：场景相关命令默认只解析 `BaseResponse.data`；排障时才追加 `--raw`。需要落盘时优先使用 `--output <file>` 保存返回 JSON。`+preview-scenario-update` / `+apply-scenario-update` 现统一支持两种输入方式：① `--request-file <scenario-update.json>` 传完整更新请求；② `--operations-file <operations.json>` 并搭配 `--base-updated-at`、`--reason`、`--idempotency-key`（仅 apply 必填）。**preview 不需要也不应要求 `--idempotency-key`**
-20. **soke-cli 多版本故障降级（v2.6）**：若默认 `soke-cli` 出现 Node wrapper `spawn Unknown system error -88`、Go 二进制 Exit 137、或 `config show` 因短 token / 空 token 触发 `slice bounds out of range [-4:]` panic，必须立即执行 `references/env-check.md` 的「soke-cli 多版本与配置修复」流程：按优先级探测 `which -a soke-cli`、`/Users/edy/soke-cli/soke-cli/soke-cli`、QClaw npm-global、nvm 安装路径；优先使用能正常 `config show` 和 `auth login` 的本地二进制完成登录；不要反复重试已知坏路径。若配置中 `UserToken` 为 `test_token_12345` 或长度不足 4、`CorpID` 为空，判定为未登录/未绑定，不得进入平台同步
-20. **跨平台适配（v2.4）**：本技能支持在 WorkBuddy、悟空(Wukong)、QClaw、Zework 四大平台运行。交互层按 `platform/adapters/` 加载对应平台的适配器（弹窗/纯文本/IM 对话），业务逻辑层（Part1-5 管线、质量闸门、资产调用）所有平台完全一致。当 soke-cli 在目标平台不可用时，降级为 `platform/api-fallback.md` 的 REST API 直接调用——JSON 结构和字段映射与 CLI 路径完全一致，仅传输方式不同
-
----
-
-## 调度技能清单
-
-### 创作管线(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` |
-| `adapters/` | **跨平台交互适配器**（WorkBuddy/悟空/QClaw/Zework） | `platform/adapters/README.md` |
-| `api-fallback` | **REST API 降级方案**（soke-cli 不可用时的 HTTP 直接调用） | `platform/api-fallback.md` |
-| `resource-finalizer` | **资源完善器**（封面/头像/语音回填） | `platform/resource-finalizer.md` |
-| `publish-gate` | **发布闸门**（结构+资源验收后才允许发布） | `platform/publish-gate.md` |
-
----
-
-## 标准任务类型
-
-### 1. 创建型
-
-从资料、需求、业务场景搭建新陪练。
-
-**典型表达**:帮我搭建AI陪练 / 创建陪练场景 / 根据资料生成提示词 / 做一个销售/面访/电话约访陪练
-
-> ⚠️ **创建型任务第一步强制执行**：识别为创建型任务后，**立即进入「创建型任务流程（严格顺序管线）」**，不得跳步、不得省略任何步骤。流程起点固定为 **Step 0 环境检测**，经 Step 1-4 后必须进入 **Step 5 Part1 创建同步（先于其他 Part 同步到平台）→ Part2 → Part3 → Part4 → Part5 分段同步**。此规则 **不管是什么平台（WorkBuddy / WebChat / CLI / 纯文本 / 群聊）都强制执行**，任何平台不得跳过 Step 0 或省略 Part1 优先创建同步。若当前运行环境不支持 soke-cli（如纯聊天平台），则引导用户在支持的终端执行环境检测和平台同步步骤。
-
-### 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`;单独发布已有场景时同样走此命令
-8. 在发布前必须先执行 `platform/resource-finalizer.md` 与 `platform/publish-gate.md`：封面、头像、语音任一缺失都禁止发布
-9. 场景列表、快照、恢复能力已纳入标准工具集：不确定 `scenario_id` 时先 `+list-scenarios`; 更新异常先 `+list-scenario-snapshots`, 必要时 `+restore-scenario-snapshot`
-
----
-
-## 资产调用规则
-
-默认资产库路径:`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-8 必须严格按顺序执行，每一步必须完成并通过闸门检查后才能进入下一步。**禁止跳步、禁止并行、禁止省略中间步骤**。如果某一步检测不通过，必须在当前步骤修复后再继续，不可将未解决的问题带入下一步。
-
-> ⚠️ **Part1 优先创建同步**：Step 5 内容生成时，**Part1 必须第一个生成并立即同步到平台创建场景**。Part1 创建成功后，再按 Part2 → Part3 → Part4 → Part5 顺序逐 Part 生成并同步。不得先生成全部 5 个 Part 再批量同步，也不得跳过 Part1 直接进入后续 Part。
-
-### 管线总览
-
-```
-Step 0: 平台就绪检测
-  ↓ ✅ 环境就绪
-Step 1: 材料接收与完整性检查
-  ↓ ✅ 材料齐全
-Step 2: 场景类型判定
-  ↓ ✅ 类型确认
-Step 3: 完整链路需求判定
-  ↓ ✅ 链路确认
-Step 4: 7 项必问清单确认
-  ↓ ✅ 全部可答
-Step 5: 内容生成（prompt-engineer 逐 Part 流水线）
-  ↓ ✅ 逐 Part 确认同步
-Step 6: 平台同步验证
-  ↓ ✅ 同步成功
-Step 7: 创建质量闸门（12 项全部通过）
-  ↓ ✅ 闸门通过
-Step 8: 资源完善与发布闸门
-  ↓ ✅ 资源完整、允许发布
-Step 9: 场景发布
-  ↓ ✅ 发布成功
-交付
-```
-
-> 每个箭头上方的 ✅ 是该步骤的强制闸门，未通过不得推进到下一步。
-
----
-
-### ⚙️ Step 0: 平台就绪检测（必做，不管什么平台都是第一步）
-
-创建型流程全程依赖 soke-cli 与平台交互。**必须在 Step 1 之前**完成环境检测。此步骤是创建型管线的**绝对起点**，不管用户在什么平台（WorkBuddy / 悟空 / QClaw / Zework / WebChat / 纯文本群聊 / CLI / API）发起请求，**都必须从 Step 0 开始执行**。
-
-> 📱 **跨平台适配（v2.4）**：Step 0 检测按当前运行平台自动选择执行策略——WorkBuddy 用 `dangerouslyDisableSandbox: true`，悟空/QClaw/Zework 直接执行 CLI（各自的沙箱机制不同），纯聊天平台可跳过 CLI 步骤直接检测 Token（从 `soke-cli config show` 或引导用户获取）。若 soke-cli 完全不可用，降级为 `platform/api-fallback.md` 的 REST API 模式——用 Token 验证 API 连通性代替 CLI 命令检测。交互方式按 `platform/adapters/` 加载对应平台适配器。
-
-> ⚠️ **沙箱绕过（全局规则）**：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。
->
-> ⚠️ **Part1 强制优先创建同步（不管什么平台）**：Part1 是创建型管线的第一个同步步骤，**必须先于 Part2-5 完成平台创建**。Part1 确认后立即调用 `soke-cli ai-training +create-scenario` 创建场景并拿到 `scenario_id`（若 soke-cli 不可用，降级为 `platform/api-fallback.md` 的 REST API POST），再逐个推进 Part2-5。若当前平台无法执行 soke-cli 也无法调用 API，在完成 Part1 内容生成和确认后，引导用户到支持的终端完成创建，**在此之前不得生成 Part2**。
->
-> ⚠️ **Part2 资源匹配双通道（不管什么平台）**：Part2 内容完整展示并由用户确认后，系统在后台执行头像和声音资源匹配，再生成写入 JSON。先检测 soke-cli 可用性 → CLI 可用走 `references/role-resource-matching.md`；CLI 不可用走 `platform/api-fallback.md`「资源匹配完整流程」的 REST API 路径。**禁止因 CLI 不可用直接跳过资源匹配**——Zework/悟空/QClaw 等平台若没有 soke-cli，必须降级到 REST API 完成 avatar/voice 匹配。资源匹配、写入、回读校验都不向用户二次确认。
->
-> 📺 **用户可见规则（v2.17 硬约束）**：Step 5 对话中**仅展示**各 Part 的标题（`## 🔨 PartN`）和确认交互（根据运行平台加载 `platform/adapters/` 对应适配器——WorkBuddy 用 `AskUserQuestion` / `render_ui`，悟空/QClaw/Zework 用结构化文本编号，但**所有平台的选项文案和分支路由完全一致**）。以下内容**全部在后台（内部推理 + 终端命令）中执行，严禁以任何形式写入对话窗口**：
-> - 内部思考与生成过程
-> - **任何 `.json` 文件名或路径**（`.json`、`step1-create.json`、`part2-operations.json`、`state-snapshot.json` 等全部禁止在对话中出现）
-> - JSON 文件创建命令与 Python 生成脚本
-> - CLI 命令及输出（`soke-cli`、`+preview-scenario-update`、`+apply-scenario-update`、`+get-scenario`、`+list-scenarios`、`+list-scenario-snapshots`、`+list-role-avatars`、`+list-role-voices`、`+create-scenario`、`+publish-scenario`、`python3` 脚本执行及其返回的 diff_summary、changed_fields、operation_count、snapshot_id 等全部禁止在对话中出现）
-> - 协议阶段 1 自检清单与结果
-> - 角色资源匹配过程（含头像/声音的 CLI 查询和写入）
-> - 工作流步骤编号（如"步骤 6：预览更新""步骤 8：发布场景"等工作流元信息）
-> - 任一同步操作的执行进度、成功/失败判断过程
-> - 环境检测命令（`node --version`、`which soke-cli`、`soke-cli config show`、`soke-cli auth login`）及其输出
->
-> **⛔ 仅允许在对话中展示的三种信息**：
-> 1. Part 完整内容（`## 🔨 PartN` + 纯文本内容展示）
-> 2. 确认弹窗交互（`AskUserQuestion` 或结构化文本编号）
-> 3. 最终摘要（Part5 完成后的一句场景信息 + 本地文件路径 + 封面缺口提示，不含任何 `.json` 文件名）
-
-> ⚠️ **确认后前台静默规则（v2.20.8）**：用户对任一 Part 回复“确认”后，后续 JSON 生成、preview、apply、回读、资源匹配、封面处理、状态快照写入等全部属于后台步骤，**前台不再展示任何“已确认”“正在同步”“继续处理中”“请稍候”等过渡消息**。后台成功则直接进入下一个 Part 展示；后台失败才允许前台报错。
-
-> ⚠️ **确认选项极简展示规则（v2.19）**：所有纯文本确认选项只展示「编号 + 选项文案」，禁止展示破折号说明、下一步解释、同步动作解释、长句说明。正确示例：`1. 确认，同步到平台（推荐）`；错误示例：`1. 确认，同步到平台（推荐）— 场景基础信息确认无误，立即创建场景到平台`。
-
-> ⚠️ **`.json` 前台零泄露规则（v2.19）**：任何 `.json` 文件名、路径、文件生成提示、脚本执行提示、CLI 参数中出现的文件名、同步中间文件、状态快照文件，均禁止出现在对话前台。即使是最终摘要，也只可说明「已完成同步/已发布」，不得出现 `step1-create.json`、`partX-update.json`、`operations.json`、`state-snapshot.json` 等字样。
-
-> ⚠️ **本地图片前台零展示规则（v2.20）**：创建型流程中本地生成的封面图、角色图、流程图等图片均属于后台资源处理，不得在对话前台展示、不得调用图片预览工具展示给用户、不得在最终摘要中主动输出本地图片路径。只有用户明确要求“给我看封面/预览图片/导出图片文件”时，才可展示或提供路径。封面是否正确由后台内部检查，不作为用户确认步骤。
-
-> ⚠️ **Part2-Part5 同等完整展示规则（v2.20）**：Part2、Part3、Part4、Part5 的内容展示必须与 Part1 同等严格：在对话框中逐字段完整展示，再给确认选项。禁止只展示摘要版、压缩版、标题版、部分字段版；禁止以“已同步/已生成/进入下一步”替代内容展示。隐藏字段仍按各 Part 隐藏规则不展示，但所有面向用户字段必须全文展示。
-
-
-
----
-
-#### ⛔ 每个 Part 的确认协议（最高优先级，不可绕过）
-
-> **统一协议：先完整展示，再提供确认。两个步骤不可颠倒、不可跳过、不可省略任何一步。**
->
-> 本协议适用于 Part1-Part5 全部五个部分，是 Step 5 的第一道强制闸门。
-
-##### 协议阶段 1：完整展示（必须在确认弹窗之前完成）
-
-每个 Part 生成后，**必须将该 Part 的全部完整内容直接在对话框中逐字段展示给用户**。展示格式为 `## 🔨 PartN：{标题}` 开头，接着逐节逐字段输出全部正文。
-
-**禁止使用弹窗组件（AskUserQuestion）替代内容展示**——弹窗组件仅用于协议阶段 2 的确认操作，**内容必须先在对话中以纯文本形式完整呈现**。
-
-各 Part 必须展示的内容清单（**展示内容严禁使用 Markdown 表格格式，必须用纯文本段落/列表呈现**）：
-
-
-**Part1 展示清单**：
-- 场景名称（完整原文）
-- 全部标签（逐条列出）
-- 场景描述全文（训练对象/业务情境/训练目标/边界条件——全部段落完整展示）
-- 考核关键点（逐条原文）
-- 场景语言
-
-**Part2 展示清单**：
-- **展示顺序固定**：先展示 AI角色整体设定 OS 全文，再逐个展示角色1、角色2、角色3...；禁止先展示角色资源匹配、写入、回读步骤。
-- AI角色整体设定 OS 全文（核心铁律/状态机/双层逻辑/行为模拟规范/知识库合规——全部章节完整原文）
-- 每个角色卡逐字段展示：名称/描述/沟通风格/MBTI/性格/标签/禁忌/知识水平
-- 每个角色的角色背景四段深度画像完整正文（我是谁/我的困扰/我的过往经历/我今天的心态——四段全部完整展示）
-- **隐藏字段**（不向用户展示）：`scenario_role_id`、来源类型、专项技能与触发器、`avatar`（平台头像资源）、`voice_id`（平台语音资源）——以上为平台元数据/内部配置
-
-**Part3 展示清单**：
-- 开场引导语完整原文
-- 每个环节完整展示：环节名/学员目标完整原文/AI任务完整原文（含环节进入条件+IF-THEN逻辑+环节退出条件）/最大轮次
-- **隐藏字段**（不向用户展示）：开场语类型——由 AI 根据开场内容智能判断（系统旁白式→2 学员先开口；AI直发式→1 AI先开口）
-
-> 🔴 **同等展示硬约束（v2.20）**：以下清单对 Part1-Part5 具有同等约束力。Part2、Part3、Part4、Part5 不得低于 Part1 的展示完整度。若任一 Part 只展示摘要、只展示维度名/环节名、只展示配置值、或省略应展示正文，视为协议阶段 1 失败，必须回退重新完整展示。
-
-**Part4 展示清单**：
-- 评分标准名称
-- 评分标准描述完整原文
-- 每个评分维度展示：名称/描述/权重/评分规则全文/评分点列表
-- **隐藏字段**（不向用户展示）：维度 `code`、`id`、`sort_order`、平台内部层级字段——以上为平台评分引擎内部字段
-
-> ⚠️ **Part4 展示修订（v2.20）**：评分规则和评分点必须作为面向用户内容完整展示，不再视为隐藏字段。不得只展示“名称/描述/权重”。
-
-**Part5 展示清单**：
-- 练习时间：默认关闭（不限时）
-- 最大练习次数：10 次
-- 通关分数：60 分
-- 通关难度：中（默认锁定，不可调整）
-- AI助答：开启
-- **隐藏字段**（不向用户展示）：`completion_rule`（写死 `all_steps`）——平台固定配置
-
-##### 协议阶段 1 自检（内部执行，不对用户展示）
-
-展示完成后，**必须内部自检后再弹窗**。逐项确认以下清单（**此清单仅在内部推理中执行，不得以文本/表格/Markdown 形式展示在对话窗口给用户看**）：
-
-```
-☐ Part 内容已全部在对话中以纯文本展示（非弹窗中展示）
-☐ 展示内容未使用 Markdown 表格格式（仅允许纯文本段落/列表）
-☐ 无"……""（略）""（同上）""详见材料""（下略）"等缩略标记
-☐ Part2 未展示 scenario_role_id、来源类型、专项技能与触发器、avatar、voice_id
-☐ Part2 每个角色的 background 四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）均已逐段完整展示，无缩略
-☐ Part4 未展示维度 code/id/sort_order 等平台内部字段，但已展示每个维度的评分规则全文和评分点列表
-☐ Part5 未展示 completion_rule；pass_difficulty 已展示为"中（默认锁定）"
-☐ 角色卡已展示全部面向用户字段，非仅名称
-☐ 场景描述/OS/背景/评分规则已展示全文，非仅标题或首句
-☐ 未先写入 JSON 再展示（必须先展示，后生成 JSON）
-☐ Part5 练习配置各字段值和说明已完整展示
-☐ Part3 开场语类型未展示给用户（内部根据开场内容智能判断）
-```
-
-> 🔴 **自检任一未通过 → 禁止弹窗 → 回退重新完整展示 → 再次内部自检 → 全部通过后方可进入协议阶段 2。**
->
-> ⚠️ **展示规则**：自检清单和自检结果**严禁写入对话窗口**。只在内部推理中执行判断，通过后直接进入协议阶段 2 弹窗。若未通过，回退重新展示时也只展示修正后的内容，不解释"之前某处缩略"。
-
-##### 协议阶段 2：用户确认（必须提供按钮弹窗选项）
-
-协议阶段 1 自检全部通过后，**必须使用 `AskUserQuestion` 工具提供确认弹窗或按当前平台适配器输出结构化文本编号确认**。纯文本编号确认只展示选项文案，不展示破折号说明。
-
-正确纯文本格式：
-```
-请选择：
-1. 确认，同步到平台（推荐）
-2. 内容需要微调
-
-回复数字编号即可。
-```
-
-错误纯文本格式：
-```
-请选择：
-1. 确认，同步到平台（推荐）— 场景基础信息确认无误，立即创建场景到 MentorAI 平台
-2. 内容需要微调 — 场景名称、标签、描述或考核关键点需要调整
-```
-
-选项映射如下：
-
-| 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 创建成功闸门（v2.20.4）**：Part1 的“同步到平台”不是逻辑确认，而是实际创建动作。必须满足以下四项后，才允许进入 Part2：
-> 1. 已生成创建请求文件（`part1-create.json` 或 `step1-create.json`）
-> 2. 已执行 `+create-scenario`
-> 3. CLI/API 返回成功
-> 4. 已提取到非空 `scenario_id`
->
-> 任一项未满足 → 立即报错并停在 Part1，禁止静默继续到 Part2。
-
----
-
-#### ⛔ Part1 确认硬约束（v2.18，一票否决）
-
-Part1 完整展示之后，**必须立即在对话中提供确认选项**，格式根据当前运行平台加载 `platform/adapters/` 对应适配器：
-- WorkBuddy → `AskUserQuestion` 弹窗（模板 1：确认同步到平台 / 内容需要微调）
-- 悟空/QClaw/Zework → 结构化文本编号确认（只展示 `1. 确认，同步到平台（推荐）` / `2. 内容需要微调`，禁止追加破折号说明）
-
-**以下行为视为执行错误，一票否决，必须打断回退**：
-- ❌ Part1 展示后直接进入 Part2 生成，未在对话中提供任何确认选项
-- ❌ Part1 展示后直接开始创建封面图或执行 `soke-cli ai-training +create-scenario`，未经用户确认
-- ❌ 展示"以上 Part1 内容如上""接下来进入 Part2"等跳过确认的过渡语句
-- ❌ 将 Part1 内容展示和确认选项合并在同一条消息中，用户直接看到 Part1 内容下方无确认选项即被跳过
-
-**合规执行流程**：
-```
-对话消息 1: 展示 Part1 全部内容（## 🔨 Part1 + 逐字段全文）
-对话消息 2: 提供极简确认选项（编号或弹窗，只含选项文案）→ 等待用户选择
-→ 用户选"确认"后方可进入封面生成和平台创建
-→ 用户选"微调"后回到内容层修改 Part1 并重新执行协议阶段 1+2
-```
-
-#### 流水线执行（Part1-Part5 完整顺序）
-
-```
-Part1 基础信息
-  协议阶段1: 在对话中完整展示 Part1 全部内容
-  协议阶段1自检: 内部逐项确认无缩略无截断
-  协议阶段2: AskUserQuestion 弹窗确认（模板 1）
-  → 确定封面来源 → 生成 part1-create.json 或 step1-create.json → 执行 create-scenario → 取得 scenario_id → 更新 state-snapshot
-  ↓
-Part2 AI角色设定
-  协议阶段1: 在对话中按固定顺序完整展示 Part2：先 OS 全文 → 再逐个角色展示全部面向用户字段（background 四段深度画像必须逐段完整展示）
-  协议阶段1自检: 内部逐项确认→特别是 background 四段是否完整逐段展示、scenario_role_id/来源类型/专项技能已隐藏
-  协议阶段2: AskUserQuestion 弹窗确认（模板 2）
-  → 后台自动执行（不向用户确认）：为每个角色匹配头像/声音资源 → 生成完整 part2-operations.json（avatar/voice_id 已写入真实值）→ 后台拆分为角色级同步单元 → 逐个角色 preview+apply+回读验证 → 最后写入 OS 并回读验证 → 更新 state-snapshot → 全部同步成功后立即自动输出 Part3
-
-> 🔴 **Part2 同步成功闸门（v2.20.6）**：Part2 只有在以下条件全部满足后，才允许进入 Part3：1. 已生成 `part2-operations.json` 与 `part2-update.json`；2. 已完成资源匹配并写入真实 `avatar`/`voice_id`；3. 已执行 preview/apply；4. 验收通过。**验收优先级**：a. `get-scenario` 回读正常且角色与 OS 验收通过；或 b. `get-scenario` 回读仍为 `ai_roles: []`、`ai_roles_overall_description: null`，但平台实际已展示 Part2 内容，则按已知平台回读差异记账通过。仅当 preview/apply 失败，或平台侧也未展示时，才立即报错并停在 Part2，禁止静默继续到 Part3。
-
-> ⚠️ **Part2 自动续流硬约束（v2.20.1）**：Part2 用户确认后，前台不得停留在“Part2 已确认，正在后台同步角色设定。”或同类中间态消息后等待用户再次输入“继续”。正确行为是：后台同步成功后，系统在同一轮任务中自动继续输出 Part3；只有出现失败、超时或必须人工介入的异常时，才允许中断并向用户暴露最小必要异常。
-  ↓
-Part3 流程设置
-  协议阶段1: 在对话中完整展示开场语+每个环节的学员目标/AI任务全文
-  协议阶段1自检: 内部逐项确认→特别是环节IF-THEN逻辑是否完整展示
-  协议阶段2: AskUserQuestion 弹窗确认（模板 3）
-  → 生成 part3-operations.json → preview+apply → 更新 state-snapshot
-  → ⚠️ apply 后验证：回读 `conversation_steps` 和 `opening_dialogue`；若未反映到 `get-scenario`，按已知平台回读问题记录并直接续流 Part4，不再以前台确认 Web 可见性作为阻断条件。详见 `sync-engine.md` Part3 验证规则。
-
-> 🔴 **Part3 同步成功闸门（v2.20.5）**：Part3 只有在以下条件全部满足后，才允许进入 Part4：1. 已生成 `part3-operations.json` 与 `part3-update.json`；2. 已执行 preview/apply；3. 若 CLI 回读正常，则回读字段验收通过；若 CLI 回读异常但 preview/apply 成功，则已按已知平台问题记录到状态快照。若 preview/apply 本身失败，或未生成 JSON，必须立即报错并停在 Part3，禁止静默继续到 Part4。
-  ↓
-Part4 评分标准
-  协议阶段1: 在对话中完整展示评分名称+描述+每个维度名称/描述/权重/评分规则全文/评分点列表
-  协议阶段1自检: 内部逐项确认→特别是一票否决是否嵌入各维度scoring_rule
-  协议阶段2: AskUserQuestion 弹窗确认（模板 4）
-  → 生成 part4-operations.json → preview+apply → apply后验收评分同步 → 更新 state-snapshot
-
-> 🔴 **Part4 同步成功闸门（v2.20.7）**：Part4 只有在以下条件全部满足后，才允许进入 Part5：1. 已生成 `part4-operations.json` 与 `part4-update.json`；2. 已执行 preview/apply；3. 验收通过。**验收优先级**：a. `get-scenario` 回读确认 `scoring_criteria_config.criteria_data.dimensions` 非空；或 b. `get-scenario` 回读仍为 `scoring_criteria_config: null`，但平台实际已展示评分标准，则按已知平台回读差异记账通过。仅当 preview/apply 失败，或平台侧也未展示评分标准时，才立即报错并停在 Part4，禁止静默继续到 Part5。
-  ↓
-Part5 教练设置
-  协议阶段1: 在对话中向用户展示：练习时间（关闭）/最大练习次数（10）/通关分数（60）/通关难度（中，默认锁定）/AI助答（开启）
-  协议阶段1自检: 内部逐项确认→所有值与固定模板一致、completion_rule 未泄露
-  协议阶段2: AskUserQuestion 弹窗确认（模板 5）
-  → 生成 part5-operations.json → preview+apply → apply后验收练习配置 → 完成摘要
-
-> 🔴 **Part5 同步成功闸门（v2.20.5）**：Part5 只有在以下条件全部满足后，才允许进入完成摘要/发布闸门：1. 已生成 `part5-operations.json` 与 `part5-update.json`；2. 已执行 preview/apply；3. `get-scenario` 验收确认练习配置字段已同步。任一项未满足 → 立即报错并停在 Part5，禁止静默结束或误报完成。
-```
-
-#### 各 Part 专项约束
-
-1. **保持既有 Part1-Part5 输出框架和章节顺序不变**
-2. **Part1 封面**：确认后优先在后台从平台图片库或已有真实封面库中选择一张匹配封面并写入；仅当图库/封面库都不可用时，才允许本地生成并上传。无论走哪条路径，**都必须拿到真实平台 URL 后**再创建场景，不得使用默认占位图，也不得只保留本地封面文件不上传
-3. **Part1 场景语言固定写死**：`scene_lang` 在创建请求中必须固定写成 `简体中文`，不得跟随材料语言、用户输入语言、场景语种或文件内容变化，前台展示中的“场景语言”与后台创建字段都必须一致
-3. **Part2 角色背景来源与完整性**：必须来自用户上传的业务材料，禁止 AI 凭空编造。若材料不足以支撑角色背景，标注"⚠️ 材料不足"并追问用户补充。`background` 字段直接复制四段深度画像全文，不压缩不修改。**⚠️ JSON 写入后、preview 前强制闸门**：生成 `part2-operations.json` 后，必须逐字比对每个角色的 `role_data.background` 与 Part2 展示中的「角色背景」文本是否完全一致（标点、措辞、空格均不可有差异），同时确认四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）全部完整。**任一项不通过 → 驳回修正，禁止直接 preview。** 这是最高频疏漏场景——背景文本在 JSON 生成阶段被截断/缩略/改写
-4. **Part2 头像/声音自动匹配 + 回读验收（CLI 过滤模式 v2.0）**：用户确认 Part2 完整内容后，后台**先从角色卡提取性别(gender)和年龄(age_group)**，映射为 CLI 的 `--gender` / `--age-group` 参数，再调用 `+list-role-avatars` / `+list-role-voices` 精准过滤查询（详见 `references/role-resource-matching.md`）。匹配失败时自动降级（去年龄→去性别→全量默认）。随后优先尝试整包 `replace_ai_roles` 写入；**仅当整包写入的 preview/apply 失败，或平台 Web 端也未展示内容时，才降级为角色级拆分同步单元。** 每次写入后执行验收：执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty`，对比以下全部项；若 CLI 回读为空但平台 Web 端已展示，则按已知回读差异记账通过，不得直接判失败。
-   - `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 验收规则（v2.11）**：角色首次 apply 时 `avatar`/`voice_id` 应为真实值。验收时确认 avatar 为非空 URL、voice_id 为非空 ID。若个别角色匹配失败保留空值，不阻断流程但需在摘要中标注。
-
-**⚠️ Part2 彻底解决方案：最小稳定结构 + 自动降级重试（新增）**
-
-当 Part2 回读出现以下任一异常时：
-- `role_data.name = "角色数据异常"`
-- `description = "角色数据格式异常，请检查数据"`
-- `background` / `communication_style` / `avatar` / `voice_id` 被平台回读为 `null`
-
-不得继续沿用当前整包结构硬重试，必须立即进入以下“彻底解决链路”：
-
-1. **第一层：字段级排雷**
-   - 将 `personality_type` 强制收敛为**单个 MBTI 值**，禁止写复合值（如 `ISTJ / ISFJ / ESTJ`）
-   - 检查 `source_type` 是否发生内外层重复写入；若有冲突，按已验证唯一层级保留，禁止双写博弈
-   - `customized_fields` 必须与实际保留字段逐项严格一致，禁止多报或漏报
-
-2. **第二层：最小稳定结构重试**
-   - 若第一层修正后仍异常，必须退化为**最小稳定角色结构**，首次仅保留以下字段：
-     - `name`
-     - `description`
-     - `communication_style`
-     - `background`
-     - `avatar`
-     - `voice_id`
-   - 以下字段默认从首次稳定写入中移除，待平台解析稳定后再逐步恢复：
-     - `knowledge_level`
-     - `taboos_objections`
-     - `tags`
-     - `personality`
-     - 非必要扩展型元字段
-
-3. **第三层：回读即准，不以 preview/apply 成功代替验收成功**
-   - `preview` 成功 ≠ Part2 成功
-   - `apply` 成功 ≠ Part2 成功
-   - 只有在 `get-scenario` 回读满足以下全部条件时，Part2 才算真正通过：
-     - `role_data.name` 不是“角色数据异常”
-     - `description` 正常
-     - `communication_style` 非空
-     - `background` 非空且四段完整
-     - `avatar` 为非空 URL
-     - `voice_id` 为非空 ID
-     - `ai_roles_overall_description` 非空
-
-4. **第四层：禁止带病续流**
-   - 只要回读仍出现“角色数据异常”，就必须停在 Part2
-   - 不得因为 preview/apply 成功就继续展示 Part3
-   - 不得口头说明“稍后再修”或“先继续后面 Part”
-
-5. **第五层：策略升级**
-   - 自此以后，Part2 默认策略不再是“高复杂字段整包写入”
-   - 默认策略改为：**最小稳定结构优先，稳定后再扩展字段**
-   - 只有在相同平台、相同结构已被实证稳定时，才允许恢复高复杂整包结构
-
-**⚠️ Part2 头像/语音强制前置（v2.15）**：avatar 和 voice_id 必须在生成 `part2-operations.json` 之前完成匹配并写入。流程：a. 按「OS → 角色1 → 角色2 → 角色3...」完整展示 Part2 内容并弹窗确认；b. 后台执行 `+list-role-avatars` 和 `+list-role-voices`；c. 按 `references/role-resource-matching.md` 为每个角色匹配资源；d. 将匹配结果写入 `role_data.avatar` 和 `role_data.voice_id`；e. 先生成完整 `part2-operations.json` 与 `part2-update.json` 并优先尝试整包同步；f. 仅在整包同步失败或平台 Web 端也未展示时，再降级为角色1、角色2、角色3、OS 的拆分保守写入。用户只确认完整 Part2 内容，不确认资源匹配、写入或回读步骤。
-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 生成后自动执行；无告警不输出，有告警才提示 ⚠️
-8.1 **Part2 默认生成策略升级（新增）**：首次同步角色时，默认优先生成“最小稳定结构”版本，不再默认把全部扩展字段一次性写入平台。高风险字段（如复合 `personality_type`、`knowledge_level`、`taboos_objections`、冗余 `source_type`）必须在平台解析稳定后再逐步恢复
-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` 不向用户展示
-20. **每个 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: 创建质量闸门（12 项）
-
-> ⚠️ **交付前必做**：完成全部生成和同步后，必须逐项通过以下 12 项闸门（定义详见「质量闸门 → 创建闸门」节）。任一未通过，返回对应步骤修复，修复后重新执行本闸门。
->
-> 📺 **以下闸门检查在内部推理中执行，严禁将逐项检查结果以任何形式（文本/表格/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 | 回退重新完整展示 |
-
-> 🚦 **闸门**：12 项全部 ✅ 后方可进入 Step 8。如有 ❌，必须回到对应步骤修复后重新跑本闸门，不得带缺陷交付。
-
----
-
-### Step 8: 发布闸门（资源兜底）
-
-> 在执行发布前，必须先补齐资源并通过发布闸门。
-
-1. 执行 `platform/resource-finalizer.md`
-   - 检查并补齐真实封面图
-   - 检查并补齐所有角色头像
-   - 检查并补齐所有角色语音
-2. 执行 `platform/publish-gate.md`
-   - 验证封面不是默认图
-   - 验证 avatar 全部非空 URL
-   - 验证 voice_id 全部非空 ID
-   - 验证无“角色数据异常”
-3. 任一失败 → 停止发布，输出缺口清单
-4. 全部通过 → 进入 Step 9
-
-### Step 9: 场景发布
-
-> 质量闸门全部通过后，执行场景发布，使其在 MentorAI 平台正式生效。
-
-#### 8.1 执行发布
-
-```bash
-soke-cli ai-training +publish-scenario \
-  --scenario-id <scenario_id> \
-  --version 1 \
-  --version-description "CLI发布" \
-  --pretty
-```
-
-> 若 soke-cli 不可用，降级为 `platform/api-fallback.md` 的 REST API POST 发布端点。
-
-参数说明：
-| 参数 | 说明 |
-|---|---|
-| `--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. **⚠️ Part3 `add_conversation_step` CLI 回读口径**：`add_conversation_step` apply 可能返回成功但 `get-scenario` 回读 `conversation_steps` 为空，`opening_dialogue` 也可能不同步反映——这是已知的 CLI/Web 回读口径差异，不代表数据未写入。验收时如 `preview/apply` 已成功，即记录为「平台回读异常待观察」，**默认直接进入 Part4**；不再要求用户先去 Web 后台确认。仅当 `preview/apply` 本身失败，或后续步骤出现明确依赖阻塞时，才回到 JSON/CLI 排查。严禁因 CLI 回读为空直接阻断流程。
-
----
-
-## 质量闸门
-
-> 💡 自主学习示例与推广案例详见 `references/self-improvement-examples.md`
->
-> 创建型任务交付前，须在「创建型任务流程 → Step 7」中逐项执行以下闸门检查。
-
-### 创建闸门(12 项)
-
-1. 材料完整
-2. 场景拆解合理
-3. 角色行为化
-4. 信息释放规则明确
-5. 每个阶段有明确的进入/退出条件
-6. 评分可识别（含一票否决嵌入各维度 scoring_rule）
-7. 练习配置匹配固定模板
-8. 有测试用例
-9. `整体设定` 节去空白字符 ≤ 3000,阶段专属规则已下沉到 `流程设置` 对应环节
-10. 每个 Part 内容已在对话中完整展示（无截断、缩略、省略号，逐字段原文可见）
-11. Part2-Part5 展示完整度不低于 Part1：Part2 OS+角色全字段、Part3 开场+所有环节全文、Part4 评分规则+评分点全文、Part5 固定配置全部展示
-12. 本地生成的封面/图片未在前台展示，未主动输出图片路径，除非用户明确要求预览或导出
-
-### 微调闸门(8 项)
-
-1. 有证据
-2. 已技术分流
-3. 已打标签
-4. 有修改决策
-5. 有标注改稿
-6. 有复测方案
-7. 有版本记录建议
-8. 微调后 `整体设定` 节去空白字符 ≤ 3000
-
----
-
-## 输出格式
-
-任务开始前先输出:
-
-```markdown
-## 🎯 意图识别
-- 任务类型:
-- 建议链路:
-- 当前管线步骤: [创建型任务需标注当前应执行的 Step N]
-- 必读资产:
-- 输入缺口:
-- 下一步:
-```
-
-> 创建型任务必须在上方标注当前管线进度（如"Step 1: 材料接收与完整性检查"），并与「创建型任务流程（严格顺序管线）」中的 Step 编号对应。
-
-### 创建/生成场景前台执行格式硬约束（新增）
-
-当任务类型 = **创建型** 且用户意图为“生成陪练场景 / 创建陪练场景 / 根据资料搭建场景”时，前台输出必须严格遵循以下顺序，**任何一项都不可省略、合并或重排**：
-
-1. **先输出 `## 🎯 意图识别`**
-   - 必须明确写出：任务类型、建议链路、当前管线步骤、必读资产、输入缺口、下一步
-   - 若是创建型任务，`当前管线步骤` 初始必须是 `Step 0: 平台就绪检测` 或当前真实步骤
-
-2. **再进入 Step 0 ~ Step 4 的前台汇报**
-   - Step 0：平台就绪检测结果
-   - Step 1：材料接收与完整性检查结果
-   - Step 2：场景类型判定结果
-   - Step 3：链路判定结果
-   - Step 4：7项必问清单结果
-   - 以上五步若有任一步未完成或未通过，**禁止输出 Part1**
-
-3. **只有 Step 0 ~ Step 4 全部通过后，才允许输出 `## 🔨 Part1`**
-   - 禁止一上来直接展示 Part1
-   - 禁止仅在内部完成 Step 0 ~ Step 4，却不在前台明确汇报当前已到哪个步骤
-   - **若 Step 4 结论为“7项全部可答，可进入 Part1”，则必须直接衔接输出 Part1；禁止停在结论句结束，禁止再插入解释、复述、流程说明或额外确认**
-
-4. **Part 展示与确认必须拆成两条前台消息**
-   - **默认理想模式**：消息A只展示完整 Part 内容；消息B只展示极简确认选项
-   - **平台兼容单消息模式（新增）**：若当前平台/会话引擎无法稳定连续发出两条独立 assistant 消息，则允许在**同一条消息内**按固定顺序输出：
-     1. `## 🔨 PartN` 完整内容
-     2. 空一行
-     3. `请选择：` + 对应确认选项
-   - 在单消息模式下，必须保证**先完整展示内容，后给确认选项**，不得把确认选项插入内容中间，不能只给确认不展示内容，也不能只展示内容不带确认
-   - **`## 🔨 Part1：基础信息` 输出完成之后，必须立刻给出“确认/修改”选项，不允许停住、不允许等用户自行猜测、不允许直接进入后台创建**
-   - **`## 🔨 Part2`、`## 🔨 Part3`、`## 🔨 Part4`、`## 🔨 Part5` 输出完成之后，同样必须立刻给出对应的确认/修改选项，不允许停住、不允许让用户猜下一步、不允许直接进入后台同步或直接展示下一 Part**
-   - **执行优先级**：若平台支持稳定双消息 → 用双消息；若平台不支持稳定双消息 → 自动降级为单消息兼容模式
-   - **禁止把 Part 内容和确认选项放在同一条消息中**
-   - **禁止在同一条消息里既展示 Part1 又顺带进入 Part2**
-
-5. **用户确认后，前台必须静默等待后台完成真实同步，再直接进入下一 Part**
-   - 禁止出现“已确认”“正在同步”“稍等”“继续处理中”等中间态提示
-   - 后台若失败，直接报错并停在当前 Part
-   - 后台若成功，直接输出下一 Part 内容
-
-6. **严禁“伪流程”**
-   - 所谓伪流程，指的是：口头声称“已按规则重置/已进入正式流程”，但实际仍在继续用未闭环的展示式回复推进任务
-   - 若没有完成当前 Part 的后台同步成功闸门，就不得声称“进入下一 Part”或“正式继续”
-
-### 创建型任务一票否决行为（新增）
-
-出现以下任一行为，视为**没有按照技能规则执行**：
-
-- ❌ 未先输出 `## 🎯 意图识别` 就直接展示 Part1
-- ❌ 未前台汇报 Step0~Step4 结果，就直接展示 Part1
-- ❌ Step4 已得出“7项全部可答，可进入 Part1”后，没有直接进入 Part1，而是继续解释、重复总结或空转结束
-- ❌ `## 🔨 Part1：基础信息` 展示完成后，没有在下一条消息立即提供“确认/修改”选项
-- ❌ `## 🔨 Part2`、`## 🔨 Part3`、`## 🔨 Part4` 或 `## 🔨 Part5` 展示完成后，没有在下一条消息立即提供对应确认/修改选项
-- ❌ 把“Part内容展示完成”当成可单独结束的消息，而没有自动继续发出下一条确认消息
-- ❌ 在不支持双消息的平台上，既没有双消息，也没有按单消息兼容模式补上确认步骤
-- ❌ Part 展示消息发出后，系统没有执行“自动续发确认消息”这一后置动作
-- ❌ 技能热更新后，没有立即回到当前断点按新规则执行，而是先解释“已优化/已修复/正确动作应为”
-- ❌ 把 Part 内容和确认选项放在同一条消息
-- ❌ 用户确认后未完成真实后台同步，就继续展示下一 Part
-- ❌ 用“我现在按规则重置”“我已正式进入流程”等措辞替代真实流程执行
-- ❌ 在创建型任务中，把“参考规则生成文案”误当成“按规则执行创建流水线”
-
-### 创建型任务防呆规则（新增）
-
-若当前任务 = 创建型，则系统必须遵守以下防呆约束：
-
-1. **不得在同一轮里跳过 Step 汇报直接输出 Part**
-   - 只要本轮前台还没有完整输出 Step0、Step1、Step2、Step3、Step4 的结果，就绝对禁止输出 `## 🔨 Part1`
-   - 即使内部已经完成判断，也不能省略前台 Step 汇报
-
-2. **Step4 通过后必须直接衔接 Part1**
-   - 若当前回复已输出“7项全部可答，可进入 Part1”，则该回复后续必须直接开始 `## 🔨 Part1`
-   - 若因长度或交互策略拆到下一条消息，则下一条消息必须以 `## 🔨 Part1` 开头，禁止插入任何过渡话术
-
-3. **禁止 Step 汇报后空转**
-   - 既然 Step4 已通过，就不能停在“可进入 Part1”这句话结束任务
-   - 必须立即衔接到 Part1（同条回复内直接继续，或下一条消息直接开始 Part1）
-
-4. **禁止 Part 前重复铺垫**
-   - 一旦 Step4 已通过，后续不得再重复“我现在开始正式进入流程”“下面重新按规则开始”“现在进入Part1”等口头铺垫
-   - 正确做法是：直接输出 `## 🔨 Part1`
-
-5. **Part1 展示后必须立即确认**
-   - `## 🔨 Part1：基础信息` 完整展示结束后，下一条前台消息只能是确认选项
-   - 允许的选项语义只有两类：`确认，同步到平台（推荐）` / `内容需要微调`
-   - 不允许缺少确认消息，不允许把用户留在“看完内容但不知道怎么操作”的状态
-
-6. **Part2-Part5 展示后也必须立即确认**
-   - `## 🔨 Part2` 完整展示结束后，下一条前台消息只能是：
-     - `1. 确认，同步角色（推荐）`
-     - `2. 调整角色设定`
-     - `3. 重设角色设定`
-   - `## 🔨 Part3` 完整展示结束后，下一条前台消息只能是：
-     - `1. 确认，同步流程设置（推荐）`
-     - `2. 调整流程设置`
-     - `3. 重设流程设置`
-   - `## 🔨 Part4` 完整展示结束后，下一条前台消息只能是：
-     - `1. 确认，同步评分（推荐）`
-     - `2. 调整评分标准`
-     - `3. 重设评分标准`
-   - `## 🔨 Part5` 完整展示结束后，下一条前台消息只能是：
-     - `1. 确认，完成创建（推荐）`
-     - `2. 调整教练设置`
-     - `3. 重设教练设置`
-   - 不允许省略确认步骤，不允许先解释后台动作，不允许直接进入下一 Part
-
-7. **技能热更新即时生效规则（新增）**
-   - 当用户在创建流程进行中提出“优化技能 / 补规则 / 修正执行规则”，且该规则影响当前所在断点时，更新技能后必须立即对当前断点生效
-   - 生效顺序固定为：
-     1. 更新技能文件
-     2. 识别当前流程断点（如 Part1 展示后、Part4 展示后、Part5 展示后）
-     3. **直接输出按新规则本应输出的那条前台消息**
-   - 禁止在技能更新后先输出“已优化”“已补规则”“现在正确动作是”等解释性过渡消息替代真实执行
-   - 若新规则要求“展示后下一条必须确认”，则技能更新后必须立刻补发该确认步骤，而不是先解释规则内容
-
-8. **确认步骤自动续发规则（新增）**
-   - 在支持双消息的平台中：当系统刚输出完任一 Part 的完整展示消息后，必须自动续发该 Part 的确认消息
-   - 这里的“下一条消息”不是“等待用户再说一句之后的下一条”，而是**系统自己紧接着发出的下一条前台消息**
-   - 若当前平台无法稳定做到这一点，则必须自动切换到**单消息兼容模式**，在同一条消息内补足确认区
-   - 如果系统既没有自动续发第二条消息，也没有在同一条消息中补足确认区，则视为本轮执行不合规
-
-9. **确认消息自动续发升级为执行级硬规则（新增）**
-   - 对创建型任务而言，“Part 展示后立即给出确认步骤”不是格式建议，而是**必须执行的后置动作**
-   - 在双消息平台：只要某条前台消息完成了 `## 🔨 PartN` 的完整展示，系统就必须立即执行一个后置动作：**再发送一条独立前台消息，内容只能是该 Part 的确认/修改选项**
-   - 在单消息兼容模式：只要 `## 🔨 PartN` 内容展示完成，系统就必须在**同一条消息末尾**追加确认区，且保持“内容在前、确认在后”的顺序
-   - 若该后置动作未执行成功，则判定为当前轮执行失败
-   - 执行失败时，系统不得继续任何后续流程，不得解释，不得进入下一 Part，唯一允许的补救动作是：**优先补发缺失的确认消息**
-   - 缺确认消息时，系统的最高优先级动作永远是“补发确认消息”，而不是解释原因、总结规则或继续流程
-
-10. **后台闭环执行级硬规则（新增）**
-   - 在创建型任务中，用户点击或回复任一确认选项后，系统必须立即进入后台闭环：
-     1. 生成该 Part 的 `.json` 文件
-     2. 执行平台同步
-     3. 执行回读验收
-   - 只有 1+2+3 全部完成，当前 Part 才算完成
-   - 若缺少任一环节：
-     - 没生成 `.json` → 视为当前 Part 未执行
-     - 没执行同步 → 视为当前 Part 未执行
-     - 同步失败或验收失败 → 视为当前 Part 未完成
-   - **禁止把“用户已确认”误当成“当前 Part 已完成”**
-   - **禁止前台已经进入下一 Part，但后台其实没有生成 `.json` 或没有完成同步**
-   - 出现上述情况时，必须立即报错并停在当前 Part
-
-### 创建型任务自检问句（新增，内部执行）
-
-在每次准备输出创建型任务前台内容前，必须先在内部逐条自问：
-
-- 我是否已经先输出了 `## 🎯 意图识别`？
-- 我是否已经明确前台汇报当前处于 Step0~Step4 的哪个步骤？
-- 如果我正要输出 Part1，Step0~Step4 是否已经全部完成并在前台说明？
-- 如果 Step4 已经通过，我是否会直接输出 Part1，而不是继续解释？
-- 如果我刚输出完 Part1，我的下一条消息是否一定会给出确认/修改选项？
-- 如果我刚输出完 Part2/Part3/Part4/Part5，我的下一条消息是否一定会给出对应的确认/修改选项？
-- 我是否错误地把“下一条消息”理解成“等用户再说话之后的下一条”，而不是系统自己立刻续发的下一条？
-- 我是否已经先判断当前平台是否支持稳定双消息；若不支持，是否已切换到单消息兼容模式？
-- 如果我刚发完 Part 展示消息，我是否已经真正执行了“自动续发确认消息”这个后置动作？
-- 如果我刚完成技能热更新，而新规则影响当前断点，我是否已经直接回到当前断点执行，而不是先解释？
-- 我这条消息是否错误地把“Part内容 + 确认选项”合并了？
-- 我是否在没有真实完成后台同步的情况下，试图口头推进到下一 Part？
-- 如果 Part2 回读出现“角色数据异常”，我是否已经立即切换到最小稳定结构 + 自动降级重试，而不是继续硬推原结构？
-
-任一回答为“否”或“是（存在违规）”，都必须中断当前输出并回到正确步骤。
-
-如果用户明确说"直接做/不用确认",可跳过确认,但**不能跳过输入质检和技术分流**；对创建型任务而言，**也不能跳过 Step0~Step4 的前台步骤汇报与当前管线定位**。
-
----
-
-# 自主学习与自我进化引擎
-
-> 核心思想:每一次诊断纠错、闸门漏拦、资产选错、子技能调度失败、用户纠正,都被自动记录并推广为永久规则。
-> 本引擎是独立 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 次同类纠正后,问一句"这是否可以作为永久规则?"