workbuddy客户拜访指北

概述

AI Agent 业务场景方案 HTML 生成器（指引性框架）

输入企业名称 + 拜访对象 → 深度调研 → 动态梳理多业务主线 → 主线展开场景+匹配能力专家 → 二合一 HTML + 精简谈参

设计哲学（必读，先于一切）

本 skill 是指引性框架，不是 SOP。原则：给理念、给原则、给产出规范；不给死规则、不给死数量、不给死格式、不给参考样本。

• skill 规定：核心理念、判断原则、产出规范、必做项
• 运行时自主决策：主线数量、场景数量、能力映射粒度、专家组合、物料是否需要、调研深度、HTML 章节编排
• 不给参考样本：所有场景基于客户实际业务分析推导，不参考预设样本。每个客户的业务主线、痛点、数据资产、决策链都是独特的——参考样本会让方案趋同，失去针对性。运行时遇到 skill 没写的情况，回到第一性原理判断：这个决策对客户、对拜访人、对方案的说服力是否有利？ 有利就做，不利就调整。宁可少而准，不要多而散。

速查导航

按需查表，不必通读全文。

能力边界速览

把藏在细节里的限制集中放在前面，避免方案设计到一半才发现"这件事 WorkBuddy 做不了"。本节基于 WorkBuddy 官网产品定位（面向普通职场人的 AI 工作台）+ 华峰 AI 赛事 69 项目实战评估沉淀。

WorkBuddy 完整能力清单（9 项）

原生能力（7 项，高可行，可直接承诺）

扩展能力（2 项，需先明确接口/权限/字段/同步频率/人工复核点再承诺）

能力边界判定原则

核心判定原则（华峰实战沉淀）：

• 客户要"AI 给出建议/分析/报告/工具"→ WorkBuddy 可做
• 客户要"本地化部署"→ WorkBuddy 通过自定义模型接入客户本地模型，数据不出内网
• 客户要"对接内部系统"→ 优先用浏览器自动化跑系统（web-access 通用 / BrowserSkill 复用登录态操作已登录的内部系统），有 API 时用连接器

可行性分级（用于场景标注）

安全分级（用于承诺口径，华峰实战用到）

不能做（P3，低可行/不宜首期承诺）

完全不能做：

• 移动端重度操作（IM 通知是轻量级，重度移动端操作不在边界内）
• 生产设备实时控制（DCS 直接闭环、PLC 自动控制、SCADA 实时操控）
• 机器人/硬件控制（机械臂、AGV、IoT 设备控制）
• 无 API 且无 Web 界面的深度 ERP 事务写入

建议模式可做，但自动闭环不能做（关键区分）：

• 工业算法：可以给"建议值/建议策略"，不能自动执行到 DCS——如 PID 整定可算参数建议，但工程师确认后手动设置到 DCS
• 模型预测：可以做"预测+预警"，不能做自动决策——如客户风险评分可输出风险等级，但授信决策由人工确认
• 对外动作：可以做"草稿+人工确认"，不能无人审核直接发送——如邮件/下单/付款/审批必须有"人工确认后提交"环节

强监管场景不宜承诺：

• 金融交易自动决策、医疗诊断自动决策、法律决策自动闭环——客户版统一写成"后续集成扩展"

工业算法场景的特殊原则（华峰实战重要沉淀）

化工/制造业客户常提"AI 自动优化工艺参数""模型预测控制"等需求。处理原则：

1. 先判断客户要的是"建议"还是"自动执行"——建议模式 WorkBuddy 可做，自动闭环不能做
2. 建议模式的标准写法：WorkBuddy 编写 Python 做系统辨识/模型训练，输出带安全边界的参数建议报告，工程师确认后手动设置到 DCS
3. 自动闭环的标准写法（P3，不宜承诺）：自动调整 DCS 参数 模型预测控制 MPC 实时优化 RTO
4. 澄清问题必含：建议参数由谁确认后执行？——把"人工确认"写进场景设计

任何场景设计前先回查此表，确认方案没有把灰区/不能做的事写成"开箱即用"。

核心理念（必做，不可省略）

1. 拜访人优先（硬性前置）

启动任务时必须先确认拜访对象，没有拜访人信息不进入调研。至少收齐：姓名+职位、决策角色（拍板/技术评估/业务用户/引荐人）、关注议题、现场时长。

按拜访人角色调整方案侧重（详见 references/role_tailoring.md）：一把手听战略价值+ROI总账；CIO/CTO 听落地架构+集成边界；CFO 听量化收益+付费模式；业务一号位听本条线 P0 场景的端到端故事；执行层听业务执行层全场景赋能。

2. 企业深度调研

WebSearch + WebFetch 调研目标企业，重点收集：公司基础信息、业务主线（客户是谁→卖什么→从获客到交付到售后的关键流程→核心部门协同→经营瓶颈）、行业背景、招聘画像（仅作组织能力缺口旁证，不写入 HTML）、行业对标案例、拜访人对应条线的近期动作。

调研深度按企业复杂度自主决定，但必须支撑后续主线梳理——调研不够就梳理不出主线。

3. 多业务主线动态梳理（关键）

从调研结果动态梳理客户的业务主线，覆盖实际业务链。

• 主线数量不预设：可能 2 条，可能 5 条，按客户实际业务复杂度决定
• 每条主线标注：价值链节点、关键岗位、拜访人关注点（哪几个节点是拜访人最关心的）
• 不参考样本：每个客户的主线是独特的，要从调研推导——不要套用"制造业就是研发→采购→生产→质量→销售""生物制药就是研发+商业化"等通用模板。同样是制造业，某客户主线可能是"OEM 代工→客户对接→产能调度"，另一个客户主线可能是"研发设计→模具→注塑→组装→出货"

不要从预置主线库里硬套——每个客户的业务主线是独特的，要基于调研推导。

4. 主线 → 场景 → 能力 + 专家映射

每条主线选取高价值节点设计场景。

• 场景数量不预设：按实际业务链覆盖，宁可每条主线少而准
• 每个场景匹配：WorkBuddy 能力（见 [场景能力地图](#场景能力地图)）+ 专家/专家团（动态读 manifest.json）
• 能力映射粒度由运行时决定：简单节点可"1 能力 + 1 专家"，复杂节点可"多能力组合 + 专家团"，不强求统一
• PSV 框架：每个场景明确 Pain（业务痛点）→ Solution（能力+专家组合）→ Value（量化收益，口径贴合拜访人）
• 场景深度分层：见下方[场景深度分层](#场景深度分层)，每个场景标注深度层级

场景深度分层

场景不是越深越好——浅层场景快速见效，深层场景价值更高但需数据沉淀。运行时按客户业务链节点的实际需求选择深度，不强求所有场景都做深。

三层深度定义

L3 深层场景的核心特征（判定原则）

L3 不是"更复杂的 L2"，而是本质不同的场景类型。判定一个场景是否属于 L3，看是否同时满足：

1. 数据沉淀：场景运行过程会沉淀结构化数据/知识资产（不是用完即弃）
2. 历史参考：新任务可参考历史数据/案例/模式（如写新会议纪要时检索历史纪要；做生产/质量/采购决策时参考历史批次/记录数据）
3. 持续性：不是一次性任务，是周期性或触发式的持续运行（每月、每批次、每次新事件）
4. 辅助决策：输出的是决策建议/风险预警/策略推荐，而非单纯报告（人做最终决策，WorkBuddy 做分析+建议）

四个特征都满足才是 L3；只满足 1-2 个是 L2；都不满足是 L1。

L3 深层场景的设计原则

设计 L3 场景时，PSV 框架需扩展为 PSVD：

• Pain：业务痛点（不仅是"效率低"，而是"决策缺乏数据支撑""历史经验无法复用""风险事后发现"）
• Solution：能力+专家组合 + 数据沉淀路径 + 历史参考机制 + 决策建议输出格式
• Value：量化收益（不仅提效，还有决策质量提升、风险规避、经验复用红利）
• Decision Loop：决策闭环——WorkBuddy 输出建议 → 谁确认 → 怎么执行 → 执行结果如何反馈回数据资产（形成飞轮）

L3 深层场景的 Solution 必含四要素

Solution = 能力组合 + 数据沉淀路径 + 历史参考机制 + 决策建议输出

① 能力组合：通常涉及多项能力联动
   - 查东西（RAG 检索历史）+ 算东西（数据分析）+ 写东西（输出建议）+ 管东西（任务跟踪+人工确认）

② 数据沉淀路径：数据从哪来 → 沉淀到哪 → 如何结构化
   - 来源：会议纪要/生产记录/客诉记录/供应商数据/质量数据...
   - 沉淀：知识库 RAG / 多维表格 / 结构化数据库
   - 结构化：标签体系/分类体系/关系图谱

③ 历史参考机制：新任务如何调用历史数据
   - RAG 检索（语义相似）
   - 规则匹配（条件触发）
   - 时序对比（同比环比）

④ 决策建议输出格式：建议怎么呈现给决策者
   - 决策卡片（推荐方案+理由+风险+备选）
   - 风险预警清单（风险项+影响+建议动作）
   - 策略推荐（分层策略+预期效果）

L3 深层场景的现场演示包调整

L3 场景的现场演示包需额外说明：

• Part A 提示词：需说明"首次运行需先沉淀历史数据"（如"请先上传过去 6 个月的会议纪要"）
• Part B 演示脚本：演示时分两步——①展示历史数据资产；②演示新任务如何参考历史给出决策建议
• 预期 Q&A：客户常问"历史数据要多长时间？""建议准不准？"——准备好"冷启动期+精度提升曲线"的回答

场景深度与拜访人角色的关系

一把手拜访人必看 L3——L3 场景是方案的战略价值锚点，让一把手看到"WorkBuddy 不只是工具，是组织决策能力升级"。

场景深度与能力分布的关系

L3 场景通常涉及多项能力联动，在部门视角全景矩阵和管理视角总览中应高亮标注：

• 部门矩阵：L3 场景用特殊样式标注（如深色背景+★符号）
• 管理视角总览的组织影响地图：L3 场景是"能力补位方向"的主要贡献者
• 管理视角总览的落地路径：L3 场景通常在阶段二/三落地（POC 阶段先做 L1/L2 证明能力，再上 L3）

5. 每场景必出"现场演示包"（关键，替代原物料包）

每个场景必须告诉使用者"现场怎么演示这个场景"，包含两部分：

提示词设计原则（核心，必读）

提示词 = 任务核心信息 + 输入数据，不需要写行业知识和工作流程——这些已由专家内置。选对专家后，提示词应该非常精简。

对比示例（说明原理，不是场景样本）：

错误（提示词太长，把专家该做的事都写了）：

这是一封来自客户的询盘邮件，请：1）翻译并提取关键需求；2）基于行业常规报价逻辑
核算 FOB 港口报价（含原材料、加工、包装、利润空间）；3）生成标准化中英文报价单
（PI 形式发票），含产品描述、数量、单价、贸易术语 FOB、付款方式 T/T 30%定金+
70%尾款、交期 45 天。请给出报价依据说明。

正确（选对专家后，提示词精简）：

附件是一封客户询盘邮件，请翻译并提取关键需求，核算 FOB 报价并生成中英文 PI。

区别：报价逻辑、PI 格式、成本构成等行业知识由专家内置，提示词只需提供任务+输入。

提示词引用输入物料的闭环要求（关键）

提示词中提到的任何输入数据/文件，必须现场可用——否则无法演示。

检查清单（每个提示词必须过）：

1. 提示词引用了文件吗？ → 如引用，该文件必须已生成并放在 materials/ 目录，绝对路径写入提示词
2. 提示词引用了邮件/记录/数据吗？ → 如引用，必须：
   • 选项 A：生成脱敏文件放在 materials/ 目录，路径写入提示词
   • 选项 B：邮件内容直接嵌入提示词正文（短邮件适用）
3. 提示词是否可"复制即演示"？ → 使用者复制提示词到 WorkBuddy 后，不需要再手动找文件/找数据即可运行

反例：提示词写"这是一封来自德国客户的询盘邮件"但没给邮件内容、没给文件路径——使用者拿着提示词无法演示。

正确做法：要么把脱敏邮件内容嵌入提示词，要么生成 materials/01-询盘邮件.txt 并在提示词中写 /Users/marcus/.../materials/01-询盘邮件.txt。

Part A — 怎么用 WorkBuddy 跑这个场景

• 前置操作：请在专家列表中手动选择「XX 专家/专家团」+ 说明为什么选这个专家（这个专家内置了什么领域知识，所以提示词可以精简到什么程度）
• 提示词：可直接复制到 WorkBuddy 运行。精简版——只含任务核心信息+输入数据/物料路径，不含专家已内置的行业知识和工作流程
• 预期产出：一句话说明会得到什么
• 注意事项：是否需要输入文件（如需要，文件已生成且路径已写入提示词）

Part B — 怎么在客户面前演示这个场景

• 演示操作流：先选专家 → 粘贴提示词 → 预期看到什么 → 重点指向哪里讲解
• 预期 Q&A：客户可能问什么、怎么回答（2-4 个高频问题）
• 故障应对：现场跑不通怎么办、有没有 fallback（如展示预生成示例产出截图）
• 时间分配：这个场景演示多久收口

现场演示包是每场景必出的。格式轻量，不强求结构统一——但要让人看完能直接上手演示。

专家选择的正确写法（格式说明，非场景样本）：

• 前置操作：请在专家列表中手动选择「与任务匹配的专家/专家团」——该专家已内置 [领域知识/工作流程/输出规范]，提示词只需提供任务和输入
• 提示词正文：精简任务描述 + 输入数据/物料绝对路径（不含专家已内置的内容）
• 不要在提示词里写"请切换到《XX》后执行"——这在 WorkBuddy 中不生效

6. 二合一 HTML 输出（唯一交付物，非 PDF）

产出一份 HTML（注意：skill 名虽含 pdf，但实际产出 HTML 而非 PDF），含两种模式：

• 方案文档模式（默认）：长文+目录+章节，客户可翻阅/邮件转发/离线打开
• 演示模式：一屏一话题全屏播放，现场投屏讲
• 切换方式：URL 参数 ?mode=presentation 或键盘 P 切换

HTML 结构、配色、章节编排由运行时基于客户行业和内容自适应（参见 references/html_schema.md）。模板在 assets/html_template/。

7. 物料按需生成（不是每场景必出，但引用了就必须生成）

物料生成的判断原则

只有当场景核心动作是"处理某份文档/表格"时，才生成演示物料（word/excel/图片/视频/数据集等）：

• 需要物料的场景：整理报价单、分析销售数据、审阅合同、汇总报表、处理询盘邮件
• 不需要物料的场景：写周报、查竞品、生成方案、问答检索

物料闭环的强制要求（关键，解决"提示词引用物料但没生成"问题）

提示词中引用的任何输入物料，必须已生成且绝对路径已写入提示词——这是闭环要求，不是可选项。

检查规则：每个提示词发布前，过一遍检查清单——

1. 提示词是否引用了文件？→ 引用了就必须生成该文件
2. 提示词是否引用了数据/邮件/记录？→ 必须生成文件或嵌入正文
3. 使用者复制提示词到 WorkBuddy 后，能否直接运行？→ 不能则补齐物料

反例：提示词写"这是一封来自德国客户的询盘邮件"但没给邮件内容、没给文件路径——使用者拿着提示词无法演示，方案直接失效。

物料存储与路径规范

物料生成后放在 HTML 同级 materials/ 目录，绝对路径写入 HTML 提示词。使用者复制提示词到 WorkBuddy 即可调用——绝对路径确保 WorkBuddy 能正确定位文件，避免相对路径因工作目录不同而解析失败。

物料必须脱敏：公司名用"示例公司A/B/C"，人名用"张三/李四"，金额合理但虚构。严禁出现身份证号、银行卡、内部 IP、内部代号。

8. 精简谈参给使用者（不进 HTML）

运行时另输出一份精简谈参，只给使用者自己看，不进 HTML：

• 一句话沟通主线（贴合客户业务 + 拜访人关注点）
• 开场白 + 收口各一句
• 3-5 个现场提问清单（确认痛点、数据可得性、决策链、POC 范围）
• 边界提醒（WorkBuddy 能力边界）：首期不承诺生产设备实时控制（DCS 闭环/PLC 自动控制）、工业算法自动闭环（MPC/RTO）、无人审核的对外发送/下单/付款/审批；工业算法场景统一采用"建议+人工确认后执行"模式

不含演示编排——演示编排已进现场演示包。

9. 部门视角全景矩阵（必出，第二导航视角）

HTML 中必须包含一个"部门视角全景矩阵"章节，让不同部门的拜访人快速定位自己相关的场景：

• 行：客户涉及的部门（研发/生产/销售/财务/HR/法务/市场/IT 等，按客户实际部门梳理）
• 列：运行时根据实际场景涉及的能力动态生成（参考 [场景能力地图](#场景能力地图)，共 9 项能力——7 项原生+2 项扩展。只列出本方案场景实际用到的能力，不用到的不列。如场景涉及"编写代码构建工具""自定义模型接入"等也作为列出现）
• 单元格：该部门该能力下的场景名（可点击跳转到场景详解锚点）
• 每个场景需标注 department 字段，用于矩阵填充
• 矩阵让拜访人一眼看到"我部门有哪些场景可用"，是业务主线之外的第二导航视角

10. 管理视角总览（必出，第三导航视角）

HTML 中必须包含一个"管理视角总览"章节，让管理层拜访人（一把手/CIO/CTO/CFO/业务一号位）一眼看到整个方案对组织的整体意义，不用逐个翻场景。

管理层不关心"某个场景怎么用"，关心的是"这套方案对我组织意味着什么"。管理视角总览回答 6 个管理层核心问题：

① 整体覆盖度仪表盘

• 方案覆盖了 X 条业务主线、Y 个场景、Z 个部门、N 项能力
• 场景深度分布：L1 一次性任务 X 个 / L2 深度分析 Y 个 / L3 辅助分析决策 Z 个（让管理层看到方案的战略深度）
• 可行性分级分布：P0（原生支持）X 个 / P1（需扩展）Y 个 / P2（需澄清）Z 个
• 安全分级分布：安全·低 X 个 / 安全·中 Y 个 / 安全·高 Z 个
• 一句话结论：如"X 个场景中，Y% 可原生落地，Z% 需扩展覆盖；L3 深层场景 N 个支撑组织决策能力升级"

② ROI 总账（按拜访人角色裁剪口径）

• 汇总所有场景的量化价值：节省人天/年、平均提效百分比、降本金额、风险规避项数
• 按角色裁剪口径：一把手看战略价值+组织红利总账；CFO 看量化收益+付费模式；CIO 看集成成本+上手周期；业务一号位看本条线单据效率+响应时长
• 价值按业务主线分组汇总，让管理层看到"哪条主线收益最大"
• 量化口径必须保守——宁可少说不可夸大，标注"基于场景设计的预期值，POC 后校准"

③ 能力分布视图

• 9 项能力在本方案场景中的分布（哪些能力高频复用、哪些只用一次）
• 高频复用能力（≥3 场景）高亮，说明这是 WorkBuddy 对该客户的核心价值锚点
• 扩展能力（连接器/自定义模型）的使用分布，说明哪些场景需要扩展投入
• 让 CIO/CTO 看到"我需要为哪些扩展能力做准备"

④ 落地路径（三阶段路线图）

• 阶段一：POC 快速验证（2-4 周）——选 2-3 个 L1/L2 场景，证明 WorkBuddy 能力可用
• 阶段二：部门扩展+数据沉淀（1-2 月）——POC 场景推广到全部门，新增 3-5 个场景，启动 L3 场景的数据沉淀（如知识库搭建、历史数据结构化）
• 阶段三：全员规模化+决策赋能（3-6 月）——跨部门推广，建立 Skill 资产库，L3 深层场景上线（辅助决策能力形成飞轮）
• 每阶段标注：目标、场景范围、资源投入（License 数+人力）、里程碑、验收标准
• 让管理层看到"这不是一次性项目，是有节奏的推进——从单点提效到组织决策能力升级"

⑤ 风险与边界管控

• 首期不承诺事项（来自[能力边界速览](#能力边界速览)的不能做清单）：生产设备实时控制、工业算法自动闭环、无人审核对外发送等
• 人工确认环节清单：哪些场景的对外动作必须人工确认后提交（邮件/下单/付款/审批）
• 数据安全方案：敏感数据是否需自定义模型接入本地化部署、API Key 存储策略
• 变更管理建议：首期推广的组织保障（培训、Skill 管理、黑白名单）
• 让 CIO/CTO/CFO 看到"风险已被识别并有管控方案"

⑥ 组织影响地图

• 哪些岗位被赋能：按岗位列出（如采购员、PMC、研究院、研发、销售、QE 等）
• 能力补位方向：WorkBuddy 补了哪些组织能力缺口（如新员工上手、跨系统数据汇总、合规风控）
• 人才能力提升：员工从重复性工作解放后，精力转向什么高价值工作
• 让 HR/CHO 和一把手看到"这不只是工具，是组织能力升级"

管理视角的呈现形式

• 用仪表盘卡片+分布表+路线图时间轴呈现，不用长文
• 每个模块控制在 1 屏内，信息密度高但视觉清爽
• 在 HTML 导航中作为独立锚点（#management-view），位于部门矩阵之后、场景详解之前
• 演示模式下可作为独立一屏快速过

与其他视角的关系

• 业务主线视角：按业务流程导航（怎么创造价值）
• 部门视角全景矩阵：按部门导航（我部门有什么）
• 管理视角总览：按组织整体导航（对我意味着什么）

三个视角互补，管理层看管理视角总览定全局判断，需要细节时下钻到部门矩阵或场景详解。

场景能力地图

本地图是指引，不是封闭集合——如果客户场景需要清单外的 WorkBuddy 能力，运行时可自主补充，但要在 HTML 中说明。先梳理客户真实业务链，再从链上节点匹配能力，不要倒过来。 能力清单对应[能力边界速览](#能力边界速览)的 9 项能力。

场景深度与能力的关系：能力是"用什么做"，深度是"做到什么程度"。同一能力可支撑不同深度的场景——如"查东西"在 L1 是单次调研，在 L3 是基于知识库的持续监控+历史参考。深度定义见[场景深度分层](#场景深度分层)。

原生能力（7 项）

扩展能力（2 项，需先明确接口/权限/字段/同步频率/人工复核点再承诺）

先梳理客户真实业务链，再从链上节点匹配能力，不要倒过来。

专家/专家团匹配（动态读取，强制）

专家的核心价值：已内置领域知识

专家不是"能力增强器"，是"领域知识容器"——专家已内置行业知识、工作流程、输出格式规范、领域规则。选对专家后，提示词可以非常精简，只需提供任务目标+输入数据，不需要把行业知识和工作流程写进提示词。

专家匹配的核心判断：这个场景涉及的领域知识，哪个专家已经内置了？选对专家，提示词就能精简。

匹配流程（强制）

强制动作：读 ~/.workbuddy/app/cache/experts/manifest.json（WorkBuddy 默认专家池，当前 428 专家含 54 专家团），从中选取真实存在的专家/专家团。

1. 梳理场景领域知识需求：这个场景需要什么行业知识、工作流程、输出格式？（如"鞋类出口报价"需要：鞋类行业成本构成+FOB 报价逻辑+PI 格式规范+贸易术语规则）
2. 查 manifest 找专家：用 scripts/read_expert_pool.py 按关键词/分类/profession 检索，找 profession/tags 匹配场景领域知识的专家
3. 优先选专家团（expertType=team，多角色协作，内置知识面更广），其次选单专家（expertType=agent）
4. 验证专家内置能力：选完专家后，回查这个专家的 description/tags，确认它确实内置了场景需要的领域知识——选错专家会导致提示词不得不写很长，违背精简原则
5. 反推提示词精简度：选对专家后，提示词应能精简到"任务目标+输入数据"——如果发现提示词还是很长，说明专家选错了或专家内置知识不够，换专家或用专家团

匹配规则

• 名称必须用 manifest 中 displayName.zh 的中文全名，不得编造
• 匹配逻辑：场景领域知识需求 → 专家 profession/tags/description 匹配，运行时自主判断
• 禁止使用用户自发布的专家，只用默认专家池
• 专家选错的信号：提示词超过 3 行还在写行业知识/工作流程/输出格式——说明专家没内置这些，需要换专家

在 HTML 中的呈现

每个场景的现场演示包 Part A 必须说明：

1. 选了哪个专家/专家团（中文全名）
2. 这个专家内置了什么领域知识（让使用者理解为什么提示词可以精简）
3. 精简后的提示词（只含任务目标+输入数据/物料路径）

manifest 结构要点：experts 数组，每项含 id/displayName（中英字典）/profession（中英字典）/description（中英字典）/expertType（agent|team）/tags（中英字典数组）/categoryId。14 个分类见 manifest categories。

连接器映射（可选补充）

涉及外部系统调用时，读 references/connector_list.md（55 连接器离线清单）选取真实连接器，在 HTML 中标注连接器名称。常用映射：

• 会议协同→tmeet（腾讯会议）、企业 IM→wecom（企业微信）/dingtalk/feishu、在线文档→tencent-docs/kdocs、企业尽调→qcc-company/tyc-mcp、邮件→qq-mail、CRM→neo-crm、项目管理→tapd、问卷→tencent-survey、法律→pkulaw/tencent-esign

连接器是可选补充，不是必选——场景只在明确需要企业系统数据时才引入。

产出规范

二合一 HTML（详见 references/html_schema.md）

• 单文件，CSS+JS 内联，可离线打开
• 方案文档模式：封面 + 行业背景 + 业务主线全景（节点可点击跳转）+ 部门视角全景矩阵 + 管理视角总览 + 场景详解（含现场演示包）+ 能力总览 + 落地路径
• 演示模式：一屏一话题，键盘左右切换，ESC 退出
• 配色按行业自适应，可带 WorkBuddy 品牌（这是给客户看 WorkBuddy 能力的方案）

每场景"现场演示包"（必出，轻量）

必含：

• Part A：
  • 前置操作（请在专家列表中手动选择 XX 专家/专家团）+ 说明该专家内置了什么领域知识（让使用者理解提示词为何精简）
  • 提示词（精简版：任务目标+输入数据/物料绝对路径，不含专家已内置的行业知识/工作流程/输出格式）
  • 预期产出
  • 物料闭环确认（如提示词引用了物料，确认物料已生成且路径已写入）
• Part B：演示操作流 + 预期 Q&A + 故障应对 + 时间分配
• 注意事项（是否需要文件等）

不强求结构统一。但提示词必须可"复制即演示"——使用者复制后不需要再手动找文件/找数据即可运行。

精简谈参（不进 HTML）

必含：一句话主线 + 开场/收口 + 3-5 提问 + 边界提醒。

反模式速查

设计场景前先看这一节，避免常见错误。完整反模式说明（含"为什么不能这样做"）和常见问题解答见 references/antipatterns_faq.md。

更多反模式与 FAQ 见 references/antipatterns_faq.md。

参考资料

资产

注意事项

• 拜访人优先是硬性前置：没有拜访人信息不进入调研
• 能力边界先行：设计场景前先回查[能力边界速览](#能力边界速览)（10 项能力+可行性分级+安全分级+不能做事项），确认方案没有把灰区/不能做的事写成"开箱即用"
• 输入校验前置：每阶段先过 references/validation_and_fallback.md，校验失败不得继续往下走，不要"猜一个值填进去继续生成"
• 降级必告知：依赖缺失/网络异常时按 references/validation_and_fallback.md 处理，降级部分必须在产出中显式标注，不静默替换
• 不编造：专家名、连接器名、业务数据都不得因降级或信息不足而编造；调研不足宁可中止也不输出不可信方案
• 不参考样本：所有场景基于客户实际业务调研推导，不参考任何预设样本（如"生物制药靶点调研""制造业供应商准入"等模板）。每个客户的业务主线、痛点、数据资产、决策链都是独特的，参考样本会让方案趋同失去针对性
• 提示词精简原则：选对专家后，提示词只需"任务目标+输入数据"，不需要写行业知识/工作流程/输出格式——这些由专家内置。提示词超过 3 行还在写行业知识，说明专家选错了
• 物料闭环原则：提示词引用的任何输入物料（文件/邮件/数据），必须已生成且绝对路径已写入提示词，或内容嵌入正文。使用者复制提示词到 WorkBuddy 后必须能直接运行，不需要再手动找文件
• 专家/连接器名称必须真实存在：专家用 manifest 中 displayName.zh 全名，连接器用 connector_list.md 中 id
• 只用默认专家池，不用用户自发布专家
• 物料必须脱敏，严禁真实客户/员工/金额/电话/邮箱
• 工业算法场景必须区分建议模式 vs 自动闭环：建议模式（参数建议+人工确认后手动设置）可做，自动闭环（自动调整 DCS/MPC/RTO）不能做
• 对外动作必须有"人工确认后提交"环节：邮件/下单/付款/审批不能无人审核直接发送
• skill 是框架：运行时回到第一性原理，不要因为 skill 没写就不做、也不要因为 skill 写了就死守
• HTML 是给客户看的：语言专业正向，不暴露内部分析方法（如招聘画像推导），不写公司画像细节（口头传达）
• 业务主线先行：先梳理客户真实业务链，再从链上节点匹配 WorkBuddy 能力，不要倒过来
• 避免反模式：设计场景前先看 [反模式速查](#反模式速查)，避免常见错误