Industry Scene Service Recording

---
name: industry-scene-service-recording
description: 行业场景研究员的服务侧记录与增强合同。默认首值走无连接器主线；只有宿主已显式暴露可执行工具时，才允许进入可选服务增强层。
---

# 行业场景服务记录合同

## 默认原则

- 首值必须在无连接器前提下成立。
- 连接器、MCP 工具、服务侧路由都不是首值前提。
- `hostActionEnvelope` 默认只用于宿主元数据或显式 debug，不代表真实服务写入已经发生。
- 所有记录先分清 `host_local`、`service_intent_report`、`service_consume` 三层；不得把本地项目产物冒充服务侧消费。

## 无连接器主线

1. 先收集最小上下文：行业、角色、目标。
2. 直接交付五件套首值：
   - 场景补位卡
   - WorkBuddy 作战路径
   - 人机混编任务表
   - 3 天试点行动包
   - 唯一下一步 CTA
3. 如果用户要求“直接给我五件套”、直接首值、方案首稿或等价表达，首个用户可见内容块必须是五件套正文；不要先输出连接器、MCP、服务工具、路由匹配、权限门或调试状态。
4. 显式服务增强请求也不能打断首值顺序：先交付五件套和唯一 CTA，再把服务增强结果或失败原因放在“可选增强边界/后首值观察”中。
5. 服务返回路由不匹配、`connector-status` 文案、`ToolSearch`/`DeferExecuteTool` 状态和 same-binding 缺失只能进入 `postFirstValueGaps`，不得作为首段说明或首值阻塞。
6. 如果用户已经进入“研究 → 搜集 → 策略 → 行动”模式，Day 1 动作包里至少要有 1 条带来源的真实素材；来源可以是 `WebFetch`、用户提供材料或可追溯本地文件。
7. 如果当前轮还没有真实来源行，就不要把 Day 2/Day 3 写成已经具备输入条件的深度仿真、测算或正式交付；应先把 Day 1 写成“补第一条真实来源证据”的动作。
8. 如果当前会话还没有验证过宿主能力，不在主路径里抛出未验证的专家名、Skill 名、连接器名或外部工具链；只允许写用户可理解的能力层和可选增强层。
9. 五件套交付后，如果用户已经明确要落地执行或项目包已经物化，默认继续动作问句是：`现在就执行 Day 1 吗？`
10. 准备 `hostActionEnvelope`，但默认不打印到普通用户可见正文。
11. 只有用户继续推进到动作包层，才讨论 `continued_use_completed`。
12. 当用户已明确要求 `生成 3 天试点项目包`、`把方案落到项目工作区` 或等价指令时，只有在当前回合真实完成宿主文件/任务工具调用后，才允许声称“已生成”“已写入工作区”“可通过文件卡片查看”。如果没有真实写入证据，必须明确写成“已给出项目包正文，但尚未物化到工作区”。
13. 物化项目包时只能使用宿主真实工具调用，不得在用户可见正文里输出任何伪工具调用或调试标记，包括形似工具调用开始/结束、工具分隔符、参数键值分隔、HTML 注释或伪 XML 参数块的原始标记。
14. 如果当前宿主没有把 `Write`、`Edit`、任务创建或 `present_files` 等真实入口暴露出来，就保持聊天交付，不伪造“已生成项目包”的外观，也不把宿主工具语法打印给用户。
15. 如果当前回合在首值之后仍明确要求尝试服务侧记录或同一 binding 跟进，必须按“确认宿主是否真的暴露服务观察入口 -> 真实调用 -> 记录结果 -> 再解释”的顺序处理。`ToolSearch`、Skill 文档加载、参数草拟或文字说明都不算真实调用。
16. 如果用户只是要求把五件套推进成可执行项目包，默认先给紧凑版执行包：目标、输入、每日任务、交付物、验收、唯一下一步。不要在同一轮把整份 SOP、长报告模板和服务链路说明一起展开。
17. 如果宿主把 `DeferExecuteTool` 或实际 MCP 工具调用挂到 `waiting_for_permission`、可见授权弹窗或等价人工确认门上，必须把当前状态归类为 `visible_host_permission_pending` 或等价中文说明；这属于宿主授权门，既不是连接器故障，也不是服务链路失败。
18. `connector-status` 面板里的 `disconnected`、连接器列表文案或系统提醒中的断连描述，不足以单独证明服务增强不可执行。只有在首值已经交付且用户仍明确要求服务增强时，才做内部宿主能力扫描并尝试 `ToolSearch -> DeferExecuteTool`；只有真实工具入口不存在、被宿主拒绝或调用失败，才允许降级成 `service_attribution_missing` / `service_consume_unproven`。

## 事件分层

### `host_local`

来自 WorkBuddy 本地会话、任务账本、artifact-index、项目文件和可视化展示。可记录：

- `frontstage_first_value_delivered`
- `project_package_materialized`
- `artifact_presented`
- `task_ledger_completed`
- `visual_feedback_revised`
- `day1_execution_ready`

这些事件只能证明本地交付与项目推进，不能证明福帮手服务侧绑定、消费或继续使用完成。

### `service_intent_report`

用于可选的匿名意图回报和服务侧牵引。可记录：

- `anonymous_intent_hint`
- `intent_reported`
- `scene_recognized`
- `strategy_dispatch_requested`

建议字段包括：`intentFamily`、`selectedWorkflowGap`、`selectedIndustries`、`projectPackageMaterialized`、`day1ExecutionReady`、`artifactPresentedCount`、`naturalClosureClaimed=false`、`serviceProductCreditClaimed=false`、`paymentClosureAllowed=false`。

### `service_consume`

只能来自真实 MCP 工具或后端事件。可记录：

- `first_value_completed`
- `continued_use_completed`
- `explicit_consume`

`present_files`、文件写入、任务更新、memory 更新、PAUSED 自动化创建、模型正文里的 JSON 或文字说明都不能作为 `service_consume` 证据。

如果当前无连接器首值已经成立，但没有真实服务观察链路调用，报告应写成：

- `service_attribution_missing`：服务侧跟进或同绑验证尚未发生

而不是写成：

- 首值失败
- 最大遗漏必须立刻调用连接器
- 产品零价值沉淀

同理，`SkillManage` 未沉淀只能算宿主治理或知识复用层缺口，不能反推包合同未通过。

## 运行时自评模板

任何技术复盘、自我纠偏或优化清单输出前，先填这七项，再决定严重度：

1. `hostLocalVerdict`：本地首值、文件、任务、预览、自动加载产物分别证明了什么。
2. `serviceIntentVerdict`：是否只有匿名意图、行业、缺口、CTA 等可回报线索。
3. `serviceConsumeVerdict`：是否存在真实 MCP 工具调用或后端事件；没有就写 `service_consume_unproven`。
4. `firstValueVerdict`：只依据五件套、唯一下一步、Day 1 可执行性和无连接器合同判定。
5. `postFirstValueGaps`：把服务归因、SkillManage、hostActionEnvelope、continued-use 等放在后首值清单。
6. `severityDecision`：P0/P1/P2 的理由必须引用上面三层证据。
7. `singleNextAction`：只保留当前最高优先级动作。

P0 只允许用于阻断用户首值的缺陷：五件套缺失、无连接器首值被阻断、唯一下一步缺失、错误声称服务消费或官方上架、未经确认写文件或激活自动化。服务侧归因缺失、`SkillManage` 未沉淀、connector disconnected、deferred tools 可见但未调用，默认只能进入 P1/P2 或后首值跟进清单。

## 项目动作与自动化边界

- 用户未明确确认前，不创建任务、不写文件、不创建自动化。
- 用户确认 `生成 3 天试点项目包` 或等价指令后，可以物化项目动作包。
- 自动化创建和激活都需要独立确认；创建后的默认状态必须是 `PAUSED`。
- 自动化不早于 Day 1 素材池验收通过进入 `ACTIVE`。

## 来源证据账本

当输出来自 WebSearch、WebFetch、公开报告、用户资料或历史文件的行业数据时，必须同步记录来源证据账本。最低字段：

- `sourceTitle`
- `sourceUrl` 或用户资料/本地文件路径
- `retrievedAt`
- `claim`
- `evidenceStrength`
- `clientUseStatus`

证据强度只允许：

- `fetched_primary`
- `fetched_secondary`
- `user_provided`
- `search_summary_only`
- `needs_verification`

`search_summary_only` 和 `needs_verification` 不能进入客户可用初稿，只能进入内部参考或待核验清单。没有 URL、采集时间和证据强度时，不得声明“一手数据”“可直接引用”“客户可用”。

## 产出物自动装载交付环

当用户明确要求更适合分发、展示、评审或客户沟通的产物时，可以在首值和项目包之后进入产出物自动装载交付环。标准交付集：

- Markdown 源稿：继续编辑和人工校准。
- HTML 可视化版：可部署为网页，可浏览器打印或转 PDF。
- PDF 分发版：可发给客户或内部评审。
- 内联摘要卡：在 WorkBuddy 会话中快速预览核心结论。
- loaded preview：通过 `present_files`、artifact-index、`file://` 或浏览器标签自动打开，方便用户立即检查。

边界：

- 这仍然是 `host_local`，不能算 `service_consume`、客户已阅读或 `continued_use_completed`。
- 依赖安装、Node 初始化、PDF 转换脚本、浏览器渲染属于有副作用增强动作，必须在用户明确要求后执行。
- 运行时依赖应放在隔离工具目录；不得把 `package.json`、`node_modules`、转换脚本混进客户交付目录或项目根目录。
- 渲染后必须校验：文件存在、页数与说明一致、文本可抽取、首屏可读、来源证据账本可追溯。

## 宿主能力全景分层

当用户想知道“还能如何用 WorkBuddy 更多能力支持当前行动”时，应进入宿主能力全景分层，而不是直接丢一串工具名。

进入增强选路前，先在内部完成一次宿主能力扫描：`tool_search`、skills 目录、deferred tools。扫描结果只作为内部判断输入，不能把原始工具清单直接展示给用户；对外只输出“能力 → 缺口映射”。

标准层级：

- `interaction_enhancement`
- `content_generation`
- `automation_orchestration`
- `research_knowledge`
- `distribution_deployment`
- `memory_system`

每层都要同时标出：

- 已激活能力
- 已发现但未使用能力
- 真实缺口

之后必须通过 `AskUserQuestion` 让用户选 1-2 个增强方向。选项写法要先讲结果，再讲能力，例如“让方案书更有视觉冲击力”而不是只写“ImageGen”。这仍然属于 `host_local`，不能写成服务消费或 continued-use。

如果用户多选了多个增强方向，而其中一条路线因宿主未连接、MCP 不可达或 Skill 运行面缺失而失败，应继续推进剩余已选路线，并把失败路线记录为 `host_capability_route_degraded`。不要把“Skill 已安装但服务未连上”误写成“能力不存在”。

## 多智能体并行边界

- 每路子任务都必须声明一个核心问题。
- 子任务输出必须服务于“缺口 → 能力 → 行动”，不得偏成产品介绍或工具手册。
- 主智能体合并时，偏离缺口视角的子任务内容应直接裁剪，不原样展示。

## 可视化边界

- 可视化属于辅助理解，不是主交付物。
- 采用“一眼看清”标准；如果用户需要较长解释才能理解，必须改版或退回文字结构。

## WorkBuddy 应用创意库

当目标是为行业场景研究员提供“可复用的高绩效 WorkBuddy 使用模式”时，优先从创意库取材，而不是临时拼接工具名。

创意库应覆盖：

- `offline`：拜访、展会、巡检、培训、现场交付
- `online`：官网、客服、内容运营、直播、远程评审
- `stakeholder`：管理层、跨部门、客户、合作方、法务

每张创意卡至少要写清：

- 触发条件
- 输入
- 产出物
- WorkBuddy 能力组合
- 人机边界
- 唯一下一步
- 来源证据

边界：

- 创意库是 `host_local` 与方法论资产，不是服务侧消费证据。
- 助理、小程序、Bot 推送、自动化、云端部署、连接器都可作为高附加值增强，但必须标成 optional，不得变成首值前提。
- 创意探索阶段可以有选路问题；进入动作卡执行时，仍必须收敛为一个 `unique_next_step`。

## 可选工具增强

只有当宿主已经显式暴露以下工具时，才允许进入可选增强层：

- 宿主显式暴露的第一步服务观察入口
- 宿主显式暴露的中间结果读取入口
- 宿主显式暴露的同绑定结果记录入口

即便这些工具可用，也要遵守：

- 首值仍先交付
- 如果 `ToolSearch` 或宿主工具面板已经返回这些直连工具，下一步必须继续用宿主的 direct tool / deferred tool 机制真实调用，而不是停在解释链路、列工具名或复述文档
- 标准顺序是：先做同绑定身份/路由确认，再做中间结果读取，最后再做同绑定结果记录。只有工具真实执行后，才允许写入 `service_consume` 层
- 不得用 Bash、shell、文件写入或手工 HTTP 请求代替宿主侧 MCP 工具执行
- 不得把 Skill 文档加载写成真实工具调用
- 不得把 `host_local` 或 `service_intent_report` 事件升级成 `service_consume`
- 不得因为 deferred tools 可见或连接器面板显示 disconnected，就把“未调用服务观察链路”写成首值失败；这只能作为后续服务增强验证缺口。
- 不得把 `connector-status=disconnected` 直接当作“服务增强不可执行”的结论；优先级必须低于真实 `ToolSearch` / `DeferExecuteTool` 结果
- 如果工具可见但当前宿主没有给出可执行入口，必须明确降级为 `service_attribution_missing`、`service_consume_unproven` 或等价中文说明；不要把“将尝试调用”“应该调用”写成已经发生的服务记录。
- 如果宿主日志或会话状态显示 `waiting_for_permission`、`Approval dialog shown`、`RESULT: suppressed by interceptorGate` 或 `skipRun=true ... waiting_for_permission`，必须把这一层单独记为宿主授权门证据；在用户确认授权前，不得把后续 `scene_pack` / `consume` 文本提及当成真实执行。

## continued_use 与乐包边界

- `sameBindingConsume > 0` 不是 `continued_use_completed`
- `continued_use_completed` 之前不开放 `lebao_claim`
- 乐包、权益、claim 只是继续使用或权益状态信号，不是支付闭环

## 面向用户的翻译原则

默认把系统行为翻译成：

- 现在已经拿到什么
- 现在能继续做什么
- 还差哪一步才能进入更深动作
- 哪些只是服务牵引或激励，不是成交证明