AI Agent 业务场景方案 PDF 生成器

输入企业名称 + 拜访对象 → 调研+设计 → 产出"贴合拜访人关注点"的客户版 PDF 方案 + 简要现场沟通谈参（含现场演示编排）

完整工作流

Step 0: 收集拜访对象信息（必做，且优先于一切）

启动任务时，必须先和使用者确认拜访对象，避免方案做得过于宽泛、与拜访人关注点错位。

如果使用者一开始没提供拜访对象，主动追问，至少收齐以下字段：

根据决策角色调整方案侧重（关键）：

裁剪原则：

• PDF 不要"大而全"。围绕拜访人的角色，Agent 数量从 4-6 个收敛到 3-4 个，把和拜访人关系最近的 2 个置顶。
• 优先级矩阵、价值汇总、行业对标等章节都要按拜访人视角调整措辞和指标。
• 在 Cover 副标题或第 1 章中，加入一句"本方案围绕 XXX（拜访人职位）关注的 XXX（议题）展开"，向客户传递"这是给您准备的"信号。

Step 1: 企业调研

使用 WebSearch 调研目标企业，重点收集：

1. 公司基础信息：成立时间、注册资本、员工规模、营收、融资阶段、核心产品、市场地位、资质荣誉
2. 业务主线：客户是谁、卖什么产品/服务、从获客到交付再到售后的关键流程、核心部门协同、经营瓶颈
3. 行业背景：市场规模、竞争格局、政策环境、关键趋势
4. 招聘画像（内部辅助，不写入PDF）：岗位名称、招聘数量、薪资范围、能力要求，只用于验证业务痛点和组织能力缺口，不作为方案主线
5. 行业对标案例：同行业 AI 赋能的实际案例，附可验证的新闻/政策链接
6. 拜访人对应条线的近期动作（关键）：如果拜访人是 CFO，重点搜该公司近年财务/上市/融资动作；如果是生产副总，重点搜近年扩产/智能制造投入；用于让方案"听起来你真的研究过他"

调研时将信息口头告知使用者，但不在 PDF 中写入公司画像细节。不要从招聘岗位倒推一堆岗位 Agent；招聘信息只是辅助证据，方案必须围绕客户真实业务主线 + 拜访人关注议题展开。

Step 2: 梳理业务主线

先写出一条可讲给客户听的业务主线，再设计 Agent。业务主线建议包含：

• 价值链条：市场/销售 → 方案/研发 → 采购/生产/交付 → 质量/售后 → 经营管理（按行业调整）
• 关键节点：3-5 个最影响收入、成本、交付或合规的业务节点
• 岗位映射：招聘岗位只作为"哪些节点人力紧张/专业门槛高"的旁证
• PC 办公触点：该节点是否存在文档、表格、会议、邮件、日程、浏览器、知识库、企业 IM、审批跟进等 PC/办公侧动作
• Agent 机会：只选择能在 WorkBuddy 当前能力边界内闭环或半闭环的节点
• 拜访人关注点叠加：在主线上标记"哪几个节点是拜访人最关心的"，作为后续 Agent 收敛依据

Step 3: 设计 Agent 场景（围绕拜访人收敛）

基于业务主线推导 3-4 个 Agent 场景（不再追求 4-6 个全景式覆盖），每个 Agent 含 3-4 个 Skill：

• Agent 粒度：按业务主线节点划分（如销售商机跟进、投标方案生成、交付项目管理、质量问题闭环），不要按招聘岗位命名
• 收敛规则：Agent 必须命中拜访人关注议题，至少 2 个 Agent 直接对应拜访人的本职 KPI；与拜访人无关的"其它部门 Agent"放进附录或删除
• Skill 粒度：Agent 内建能力模块，必须是可执行的办公动作（检索、整理、生成、校验、提醒、归档、汇总、跟进、会议纪要等）
• PSV 框架：每个 Agent 需明确 Pain（业务痛点）→ Solution（Skill组合）→ Value（量化收益），Value 的口径要换成拜访人能听懂的指标（CFO 听 ROI/成本，CIO 听集成成本/上手周期，业务听单据效率/响应时长）
• 可行性评估：每个 Skill 都要评估 WorkBuddy 适配度、数据可得性、人工确认点、集成依赖和首期建议
• 优先级：P0（最高）→ P1（高）→ P2（中），按业务紧迫度+技术可行性+ROI综合评估；P0 默认是"拜访人最关心的那 1-2 个"

Step 4: WorkBuddy 可行性边界

WorkBuddy 定位为全场景职场 AI 智能体桌面工作台：用户用自然语言描述任务，系统可自主规划步骤、调用本地文件/网页/文档/表格/连接器/Skill 等能力，交付可验收结果。设计方案时必须围绕 WorkBuddy 的真实强项展开，避免把它包装成生产设备控制系统或深度 ERP 替代品。

强制动作：开始 Step 3 之前以及 Step 7 编排现场演示之前，必须 WebFetch 一次 https://www.codebuddy.cn/docs/workbuddy/Overview，对齐 WorkBuddy 当前的能力清单（任务管理、专家 Expert、Skill / Skill Market、Cloud Agent、连接器如腾讯会议/腾讯文档、知识库、自动化、办公文档四件套等），避免推荐已下线/未上线的功能或编造能力名称。

优先选择这些高可行场景：

• 高可行：文档/PDF/PPT/表格生成与审阅、邮件解析与回复建议、会议纪要与待办、日程提醒、知识库检索/RAG问答、网页/系统查询、信息汇总、市场/竞品调研、报告生成、企业 IM 协同、审批/任务跟踪、人工确认后提交
• 中可行：需要调用企业系统 API 的查询类场景、低频写入类场景、需要结构化数据清洗的报表类场景、跨系统数据汇总与看板类场景；需明确接口、权限、字段、同步频率和人工复核点
• 低可行/不宜首期承诺：移动端重度操作、生产设备实时控制、复杂工业算法闭环、机器人/硬件控制、无 API 的深度 ERP 写入、强监管自动决策、无人审核的对外发送/下单/审批/付款

表达口径：

• 不是替换系统：WorkBuddy 更像"系统之外的办公协同层"，补足邮件、Excel、会议、文件、知识库、浏览器、IM 里的重复工作
• 不是替代人：关键动作保留人工确认，如报价发送、合规提交、客户回复、订单变更、付款审批
• 不是一次性大改造：首期用模拟数据或导出的 Excel/文档做 POC；跑通后再对接 ERP/MES/CRM/电商平台/API

客户版表达要务实：能做的讲清楚，不能首期做的写成"后续集成扩展"，避免承诺 WorkBuddy 当前不擅长的能力。

Step 5: 组装 JSON 数据

按 references/data_schema.md 中的 JSON 结构组装数据。关键规则：

• 主题选择：按行业选色（green=制造/能源, blue=金融/政务, red=互联网/电商, purple=科技/SaaS）
• 业务主线先行：PDF 中要出现业务主线或关键业务节点，让 Agent 设计有清晰叙事抓手
• 客户版语言：不写"招聘画像推导"，用"业务主线+行业洞察+业务痛点"表述
• 不暴露分析源：场景副标题描述业务节点痛点，而非招聘映射
• 拜访人锚定：Cover 副标题或第 1 章引言中加入"围绕 XXX（拜访人职位）关注的 XXX（议题）展开"
• 不写 Skill Demo 标记：未实现的 WorkBuddy Skill 功能不标注
• Skill 可行性：每个 Skill 建议填写 fit、feasibility、dependencies、human_in_loop 字段；PDF 会在 Skill 描述下方显示
• 行业对标附来源：每个 Agent 的对标案例需附可验证的新闻/政策 URL
• HTML 标签：文本中使用
（非
）换行，脚本自动修正但建议规范

Step 6: 生成 PDF

运行生成脚本：

python3 <skill_path>/scripts/generate_proposal_pdf.py <data.json> [output.pdf]

需使用已安装 reportlab 的 Python 环境（managed env 或系统 Python 3.9+）。脚本自动处理：

• 4 种配色主题（green/blue/red/purple）
• 跨平台中文字体自动检测（macOS/Linux/Windows）
• 
→
自动修正
• 优先级矩阵字段从 priority 自动推导
• reportlab 依赖检测（未安装时友好提示）

Step 7: 输出简要现场沟通谈参（含现场演示编排）

生成 PDF 后，必须在最终回复中额外输出一份简要谈参，用于客户现场沟通。谈参不写进 PDF，除非用户明确要求。

谈参必须回答："你觉得这个客户去现场沟通，我们沟通的方向是什么、要演示什么、怎么收口？"

建议结构：

1. 一句话沟通主线：贴合客户业务 + 拜访人关注点。例如：
• 外贸制造（CIO）：从"代工出海"到"品牌出海"，IT 不增成本不换系统，先在外贸协同、合规验厂、订单交付里加一层 AI
• 高端制造（生产副总）：不碰设备控制，先把报价、工艺知识、质量追溯这些办公链路跑顺
• 教育/医疗/政务（一把手）：围绕资料整理、知识问答、会议待办、报告生成、流程跟踪切入
2. 为什么这个方向对客户成立：用 2-3 个调研事实支撑，至少 1 条要直接关联拜访人本职 KPI
3. 现场三段式打法：
• 开场：用客户业务语言而非 AI 术语，说明"不换系统、不换人，在现有工作方式上加一层 AI"，并明确"今天专门围绕您（拜访人）关心的 XXX 来讲"
• 中段：讲 2 个 P0 场景，最好能演示一个客户日常动作（邮件询价、报价单、验厂文件检索、质量报告等）
• 收口：提出 4 周 POC，使用模拟数据或客户导出的文档/Excel，先跑通一个闭环

1. 现场演示编排（必出，且与方案绑定）

目标：让拜访人在 15-30 分钟内对 WorkBuddy 形成"这是真能干活的"实际体感，而非看 PPT 说概念。

设计原则：

• 必须和方案中的 Agent/Skill 直接挂钩：演示什么，方案就有什么；方案讲了什么，演示就能看到一段。形成"PPT 讲一段→桌面演一段"的闭环
• 必须有客户可感的场景载体：不要演"今天天气怎么样"，要演"帮我把这家供应商的最新报价整理成对比表"、"把这次评审会议纪要发给项目组"、"周一前给我一份本月质量异常清单"
• 覆盖 4 类核心能力（基于 WorkBuddy 现有能力，演示前必先 WebFetch 官方文档校准）：

| 能力 | 现场体感 | 与方案的挂钩点 |

|------|---------|----------------|

| 任务（Task） | 一句话发起多步骤任务、右侧实时看 AI 自主规划与执行、产出可验收文件 | 这就是方案里所有 Agent 的运行底座 |

| 专家（Expert） | 切换不同领域专家完成同一类任务，体感"换专家=换专业能力" | 对应方案里"销售专家/质量专家/财务专家"等岗位智能体 |

| Skill / Skill Market | 一键启用现成 Skill（如办公文档四件套、Web Search、本地 Whisper），或现场跑使用者自创的客户 Skill | 对应方案里 Agent 中的 3-4 个 Skill 单元 |

| 连接器：腾讯会议 | 一句话创建/查询/邀约会议，或演示"会议纪要→任务跟进"链路 | 对应方案里"会议纪要/项目跟进/客户回访"类 Skill |

• 可按拜访人加挂的能力（按现场时长和兴趣选用）：Cloud Agent（企业版）/ 自动化定时任务 / 知识库（腾讯文档/乐享/ima）/ Agent Browser / 数据分析可视化 / 微信助理接入

输出格式（必须给到使用者）：

编排表（按时长 20 分钟为基线，使用者可裁剪）：

| 时长 | 演示动作 | 客户日常场景载体 | 对应方案中的位置 | 拜访人体感关键词 |

|------|---------|------------------|-------------------|------------------|

| 0-2min | 任务起手：一句话发起 | "帮我整理本周的客户跟进情况" | 销售跟进 Agent / Step3 第 1 个 | "AI 真在干活，不是聊天" |

| 2-7min | Skill 调用：办公文档四件套 | "把刚才整理的内容生成一份周报 Word" | 周报/汇报类 Skill | "省下我每周 2 小时" |

| 7-12min | 专家切换 | 切到"销售专家"重新跑一遍同样的指令，对比输出差异 | 方案里的领域专家智能体 | "换专家=换专业大脑" |

| 12-17min | 腾讯会议联动 | "把这份周报发到项目组并约周五 10 点的评审会" | 会议/项目跟进 Skill | "AI 帮我打通了沟通这一步" |

| 17-20min | 收口与提问 | 引到 POC 4 周计划 | 方案最后一章 | "下一步怎么开始" |

每个动作都要写清"对应方案哪一页/哪个 Agent"，让客户在 PPT 上听到的，能在桌面上立刻看到一遍。

演示故事线（一句话串联）：示例—"今天围绕王总（CIO）关心的'IT 不增预算的前提下提效'，我先用一句话发任务、再生成周报文档、再换一个销售专家跑一遍、最后联动腾讯会议把人和事都串起来——这一套就是方案里销售跟进 Agent 的完整运行方式。"

风险与降级方案：

• 网络不稳定时的离线演示替代（本地 Skill / 已生成结果回放）
• 客户内网不允许装客户端时改为屏幕共享演示
• 涉及客户真实数据时改用脱敏样例

1. 建议主题名：给 3-5 个标题候选，区分"务实型/战略型/场景型/数字冲击型"，并明确首推（首推必须贴合拜访人角色）
2. 现场提问清单：给 5-8 个问题，用于快速确认痛点、数据可得性、决策链和 POC 范围
3. 边界提醒：明确 WorkBuddy 首期不承诺生产设备控制、深度 ERP 写入、无人审核对外发送；强调人工确认点

谈参要简短、可直接拿去对客户说。输出风格：结论先行、表格+编号、少空话，多业务抓手。

Step 8: 自动生成现场演示物料包（一场景一文件夹）

谈参里编排的每个演示动作，都需要一套真能在桌面打开就能演的物料。本步骤通过 Agent 工具启动 subagent 并行产出，避免主上下文被大段示例数据污染。

8.1 输出目录约定

所有演示物料统一输出到当前工作区下：

./demo-materials/<company-slug>-<YYYYMMDD>/
├── README.md                          # 总索引：场景列表、推荐演示顺序、风险与降级
├── 01-<scene-slug>/                   # 场景 1
│   ├── README.md                      # 本场景的演示脚本（5 段式）
│   ├── prompts.md                     # 现场可直接复制粘贴的提示词，按演示顺序编号
│   ├── data/                          # 演示需要用的样例数据（脱敏）
│   │   ├── *.xlsx / *.csv / *.docx / *.eml / *.txt / *.pdf …
│   │   └── data-manifest.md           # 每个文件的来源/字段/脱敏方式说明
│   ├── expected-output/               # 演示后期望产出的样例（用于客户预期对齐 + 兜底回放）
│   │   └── *.docx / *.xlsx / 截图.md …
│   └── fallback.md                    # 网络/权限受限时的降级演示动作
├── 02-<scene-slug>/
└── …

• ：客户公司英文 slug（小写连字符），如 cierr-group
• ：场景英文 slug，对应方案中 Agent 名，如 sales-followup、bid-response、quality-loop
• 每个场景对应谈参编排表中的 1 个演示动作或1 个 P0 Agent，不要把多个场景塞进同一个文件夹

8.2 启动 subagent 并行产出（关键）

不要在主对话里逐字编造演示数据。改用 Agent 工具，为每个场景启动一个 general-purpose subagent（场景间相互独立，应在同一条消息里并行发起多个 Agent 调用）。

每个 subagent 的 prompt 必须自包含，至少给到：

1. 客户上下文：公司名 / 行业 / 业务主线一句话
2. 拜访人信息：姓名职位 / 决策角色 / 关注议题
3. 本场景对应的方案 Agent / 用到的 Skill 列表
4. 本场景在编排表中的位置：第几段、时长、客户日常场景载体、体感关键词
5. 场景的输入数据要求：需要哪些脱敏样例文件（建议 3-5 个），字段、行数、风格
6. 输出目录的绝对路径：./demo-materials/-/-/
7. 强制约束：
• 数据必须脱敏，不得使用真实客户/员工/金额/电话/邮箱
• 公司名一律使用 "示例公司A/B/C"、人名使用 "张三/李四"、金额行业合理但虚构
• 提示词必须可在 WorkBuddy 主对话框直接粘贴运行，不依赖未提供的文件
• 每条提示词后注明"预期产出"和"演示话术"
• 严禁在演示数据里出现敏感关键词（身份证号、银行卡、内部 IP、内部代号）
8. 验收清单：data/ 下文件能打开、prompts.md 可顺序执行、expected-output/ 至少 1 个样例

并行规则：

• N 个场景 → 同一条消息里发 N 个 Agent 调用，subagent 各自独立工作
• 主 agent 等所有 subagent 返回后，统一生成总 README 索引
• 单个 subagent 失败不阻塞其它场景

8.3 每个场景 README.md 的 5 段式结构（subagent 必须按此输出）

# 场景：<场景中文名>（对应方案 Agent：<Agent 名>）

## 一、客户视角的一句话
"<用客户业务语言写一句，让拜访人立刻知道这段演示在解决他的什么问题>"

## 二、演示时长 & 节奏
- 时长：X 分钟
- 节奏：起手 → 主操作 → 加分动作 → 收口
- 与方案的挂钩：方案第 X 章 / Agent <Agent 名> / Skill <skill 列表>

## 三、所需数据
| 文件 | 用途 | 脱敏方式 |
| --- | --- | --- |
| data/xxx.xlsx | … | 公司名/人名/金额已脱敏 |
| … | | |

## 四、演示步骤（与 prompts.md 一一对应）
1. 起手：粘贴 prompts.md#1 → 等待右侧任务区出现 X → 话术：「<现场话术>」
2. 主操作：粘贴 prompts.md#2 → …
3. 加分动作（可选）：粘贴 prompts.md#3 …
4. 收口：粘贴 prompts.md#4 → 把产出落到 expected-output/ 对照
5. 引到方案：「这就是方案第 X 章里的 <Agent 名>，下一步如果做 4 周 POC，我们先用您们真实的 <数据类型> 跑一遍」

## 五、风险与降级（详见 fallback.md）
- 网络受限：用 expected-output/ 中的样例直接展示结果
- 数据敏感：当场不上传客户真实文件，只演示 demo-materials 里的样例
- 时间不够：跳过加分动作，直接到收口

8.4 prompts.md 规范

# 演示提示词（按顺序，可直接复制粘贴到 WorkBuddy 任务输入框）

## #1 起手
> <提示词原文>

预期产出：<一句话>
现场话术：「<现场对客户说的话>」

## #2 主操作
> <提示词原文>

预期产出：<一句话>
现场话术：「<现场对客户说的话>」

…

• 每条提示词独立成段，不要把多条合并
• 提示词中的文件名要与 data/ 下完全一致，使用相对路径
• 涉及切换"专家/Skill/连接器"的，提示词里写清切换动作（例如："请切换到《销售专家》后执行下面任务："）

8.5 主 agent 收尾动作

所有 subagent 完成后，主 agent 必须：

1. 在 demo-materials/-/README.md 生成总索引：场景清单、推荐演示顺序（与谈参编排表一致）、整套时长、降级方案汇总
2. 在最终回复中，告知使用者：
• 物料包绝对路径
• 推荐使用顺序
• 提醒"现场前自己跑一遍"，发现失败的提示词由使用者反馈以便迭代
3. 调用 deliver_attachments 把每个场景的 README.md 和 prompts.md 作为附件交付（场景多时，至少交付总 README.md 和首场景全套）

PDF 结构

依赖与平台

reportlab 库

脚本启动时自动检测 reportlab 是否已安装。未安装时会输出友好提示和安装命令后退出。

预装方式：

pip install reportlab

中文字体（跨平台自动检测）

脚本按 macOS → Linux → Windows 顺序搜索系统字体，无需手动配置：

Linux 安装中文字体：

# Debian/Ubuntu
sudo apt install fonts-noto-cjk fonts-noto-color-emoji
# RHEL/CentOS
sudo yum install google-noto-sans-cjk-fonts

未找到中文字体时脚本会列出搜索路径并给出安装建议后退出；未找到 Emoji 字体时仅输出警告，不影响 PDF 生成。

注意事项

• 拜访对象优先：没有拜访人信息坚决不进入 Step 1，Step 0 是硬性前置
• PDF 是给客户看的，语言要专业、正向，避免暴露内部分析方法
• 公司画像信息通过对话口头传达，不写入 PDF
• 招聘岗位是辅助证据，不是方案主线；不要输出"招聘岗位→Agent"的线性结构
• 先梳理客户业务主线，再从主线节点里挑选 WorkBuddy 可落地的 Agent 场景
• Agent 数量从过去的 4-6 个收敛到 3-4 个，宁可少而准，不要多而散
• 优先级矩阵用"业务紧迫度 + 拜访人 KPI 关联度"而非"招聘密度"
• 每个 Skill 都要给出可行性评估，尤其说明是否适配 PC 侧/日程办公侧工作流
• 每个Agent的Skill建议3-4个，少于4个时自动补"待规划"占位
• 现场演示编排是谈参的必出小节，且必须与方案中的 Agent/Skill 一一对应：方案里没的不要演，演了的方案里要有
• 演示推荐前必须 WebFetch https://www.codebuddy.cn/docs/workbuddy/Overview 校准最新能力清单，避免推荐已下线/未上线的功能
• 现场演示物料包必须用 subagent 并行产出，不要在主对话里编造大段示例数据；每个场景独立文件夹，结构按 Step 8.1 严格遵守
• 演示数据必须脱敏：公司名用"示例公司A/B/C"，人名用"张三/李四"，金额合理但虚构；严禁出现身份证号、银行卡、内部 IP、内部代号