用了一段时间 WorkBuddy 之后，有个感受越来越明显——默认的 AI 对话能力只是个底层运行时，真正的生产力来自 Skills 层的能力扩展。这篇文章不是功能介绍，是基于实际使用场景做的一轮技术评估，重点关注每个 Skill 的适用边界、组合方式和潜在风险点。

---

1. agent-browser：给 AI 加一个受控的浏览器执行环境

从功能定位来看，agent-browser 解决的核心问题是：把 AI 的能力从"文本生成"扩展到"信息获取+动作执行"。

它的实现逻辑大致是：在沙箱或受控环境中启动一个浏览器实例，AI 可以驱动它打开 URL、执行搜索、提取 DOM 内容、截图，部分场景下还能辅助完成表单操作。

典型使用场景：

信息密集型的研究任务是它的强项。比如竞品监控、行业动态汇总这类工作，原本需要人工打开十几个页面再手动整理，现在可以把意图描述清楚，让它做信息搜集的第一遍过滤。一个可用的 Prompt 示例：

请访问以下三个网站，提取最近两周内关于大模型应用层产品的重要更新：
[网站A] [网站B] [网站C]
输出格式：时间 | 来源 | 核心内容 | 我方影响评估

需要清楚的边界限制：

agent-browser 不是全功能爬虫，也不是绕过平台限制的工具。碰到以下几类情况会失效或结果不可靠：

• 登录后才能访问的内容（OAuth、企业 SSO 等）
• 强反爬机制（Cloudflare 5秒盾、动态 Token 等）
• JavaScript 渲染依赖度极高的 SPA 页面（取决于浏览器实例的渲染能力）
• 需要验证码交互的操作

合理的用法是：把它定位为"公开信息的自动化预处理层"，不要指望它替代专业的数据采集系统。对于高价值、高精度要求的数据，它的输出应当作为草稿而非最终结果。

适合的角色： 产品经理（竞品分析）、研究员（快速情报）、运营（热点跟踪）、技术选型场景下的初步调研。

---

2. guizang-ppt-skill + pptx-generator：分层解决 PPT 的表现与交付问题

这两个 Skill 需要放在一起评估，因为它们解决的是 PPT 生产流程中的两个不同层次问题。

问题的本质：
AI 生成 PPT 面临的最大矛盾不是"内容质量"，而是"格式可交付性"。很多工具生成的是 HTML 展示页、Markdown 渲染或者截图，在正式场合不可用——你没办法把它插入公司模板，也没办法修改某一页的数据然后重新发送。

guizang-ppt-skill 的定位：
视觉表现层。它更擅长处理视觉设计逻辑——版面构图、字体层级、色彩搭配、信息密度控制。适合需要高视觉冲击力的场合：对外发布的产品介绍、演讲主视觉、展会材料。其风格偏现代国际化，如果你的受众对审美敏感，这个 Skill 生成的结果明显优于纯文本堆砌型的方案。

pptx-generator 的定位：
格式交付层。它的输出是标准 .pptx 文件，可以在 PowerPoint 或 WPS 中直接编辑。不追求极致视觉效果，但保证可修改性和兼容性。适合日常工作汇报：季度 OKR 回顾、项目状态更新、需求评审等场景。

推荐的三步工作流：

第一步：结构化大纲生成
→ 用 WorkBuddy 对话，基于原始材料（文档/数据/想法）生成逻辑清晰的大纲
  关键点：明确受众、汇报目标、信息层级

第二步：视觉设计（选用）
→ 如果需要高质量视觉，调用 guizang-ppt-skill
  给出风格偏好、品牌色、内容侧重

第三步：格式输出
→ 调用 pptx-generator 生成可编辑文件
  后续在 Office 内做最终调整

这个流程的优势在于：每一步都有明确的输入输出，不会出现"AI 一次性生成所有东西但哪都差一点"的情况。

---

3. PDF / DOCX / XLSX 文档处理套件：解决非结构化到结构化的转化问题

这三个方向合起来构成了职场文档处理的核心链路，本质上都在做同一件事：把非结构化或半结构化的信息提取出来，转换成可处理、可分析的结构。

PDF Skill 的核心价值：

PDF 是信息传递的终态格式，但经常需要从中提取内容反向加工。这类任务人工做效率极低，尤其是：

• 扫描版 PDF（需 OCR）+ 提取表格数据
• 多份合同或报告的关键条款对比
• 技术规范文档的结构化整理

一个有效的 Prompt 模式：

读取附件 PDF，完成以下任务：
1. 提取所有包含数字的表格，输出为 Markdown 表格格式
2. 找出所有"注意事项"/"风险提示"相关段落
3. 生成一份不超过 500 字的执行摘要，重点面向决策者

DOCX Skill 的核心价值：

适合把散乱信息整合成正式文档，或者把 AI 的输出结果标准化交付。会议纪要、技术方案、调研报告这类需要"格式标准、内容可信"的文档，用 DOCX Skill 输出比复制粘贴更可控。

XLSX Skill 的核心价值：

注意它的定位是"初步数据分析和格式化"，不是替代 Python/R 做专业统计分析。适合场景：销售数据的分组汇总、问卷数据的频率统计、多表的简单关联整理。

一个实际案例的工作流：

假设你需要整理一个季度的客户反馈报告：

1. 把多份 PDF 格式的客户反馈文件交给 PDF Skill 提取结构化信息
2. 用 XLSX Skill 做分类汇总和频率分析
3. 用 DOCX Skill 生成正式报告

这三步如果手工操作，通常需要半天。正确使用这套组合，可以把人工介入时间压缩到质量核查和最终润色阶段。

---

4. Find Skills：需求驱动的 Skill 检索，而不是随机发现

这个 Skill 的价值经常被低估，因为它看起来不"生产"什么东西。但从工程的角度看，找到正确的工具本身就是一项有成本的工作。

Skills 生态增长很快，能力重叠的 Skill 越来越多。在没有导航的情况下，用户面临的是选择困难——不知道该装哪个，装了以后发现不满足需求，再卸载再装，时间成本积累起来很可观。

Find Skills 的价值在于把"需求描述"映射到"能力匹配"。你不需要知道 Skill 的名字，只需要描述你要解决的问题：

我需要一个能把视频中的人声转成文字、同时区分不同说话人、
并输出带时间戳字幕的 Skill，请帮我搜索并对比前三个选项，
说明各自的限制条件和适合场景。

它还能做 Skill 对比分析，这对于功能相近的多个选项来说特别有用——你可以在安装之前就了解差异，而不是一个个试过去。

给工程师的建议： 在开始一个新的工作流设计之前，先用 Find Skills 做一轮能力地图扫描，确认现有 Skill 是否覆盖你的需求点，再决定是组合现有 Skill 还是需要自定义开发。

---

5. dingtalk-unified：把碎片化的企业通讯上下文整合到工作流

钉钉作为企业通讯基础设施，沉淀了大量的工作上下文——审批记录、日程、公告、文件、群消息。问题在于这些信息高度分散，人工汇总的成本很高，而且容易遗漏。

dingtalk-unified 的作用不是"替你回消息"，而是把钉钉里的信息做成 AI 可处理的上下文输入。

典型应用场景：

场景一：每日信息汇总

整理今天钉钉里所有@我的消息、待处理审批和日历提醒，
按紧急程度分级输出，标注每项需要我做什么决定。

场景二：日报/周报自动化

基于今天的钉钉工作记录（消息、任务、文件），
帮我生成一份日报初稿，格式：完成项 / 进行中 / 阻塞项 / 明日计划，
语气简练，不要废话。

场景三：会议纪要整合

提取本周会议群里的所有决策类消息，整理成决策记录表：
时间 | 决策内容 | 负责人 | 截止日期

权限和隐私是关键约束：

这个 Skill 能访问什么内容，完全取决于账号授权范围和企业IT 策略。在使用前需要明确：

• 该 Skill 请求了哪些权限范围
• 企业是否允许第三方应用接入钉钉数据
• 哪类消息属于不应外传的敏感信息

不要把含有客户信息、财务数据、人事敏感内容的消息直接作为输入传给任何 AI 工具，包括这个 Skill。

---

6. Agent Memory：把 AI 助手从无状态变成有上下文

从技术架构角度，大语言模型默认是无状态的——每次对话都从零开始。这在大量重复性工作场景下意味着极高的"提示工程"成本：你每次都要重新说明格式、风格、偏好、约束条件。

Agent Memory 解决的就是这个状态持久化问题。

值得持久化的典型信息类型：

1. 输出格式约定

   我写的所有技术文档，标题用 Markdown H2，正文不超过三级列表，
   代码块必须标注语言类型，结尾加"注意事项"章节。
   

2. 写作风格偏好

   面向工程师的文章：直接结论优先，不要铺垫，数字要具体，避免"非常/极其/完全"等程度副词。
   

3. 工作流模板

   每次做竞品分析，固定输出：产品定位 / 核心功能对比 / 差异化分析 / 我方机会点 / 风险评估。
   

4. 个人上下文

   我是后端工程师，主要技术栈是 Go 和 PostgreSQL，代码建议默认用这两个语言/数据库给例子。
   

需要注意的边界：

记忆系统不是越多越好。过度填充会导致上下文混乱——AI 在多个记忆条目之间产生冲突时，输出质量反而下降。建议按照"长期稳定、高频复用、无隐私风险"三个标准筛选要持久化的信息。

临时任务的偏好（“这次报告用蓝色风格”）、隐私数据（姓名、账号、密钥）、公司敏感信息，都不应该进入记忆系统。

---

7. Skill-vetter：Skills 安装前的安全评估环节

这个放在最后说，但从工程安全的角度，它应该是安装任何新 Skill 之前的标准流程的一部分。

Skills 的开放生态意味着代码质量和安全标准参差不齐。一个 Skill 在运行时可能会：

• 请求读取本地文件系统
• 发起网络请求（可能向第三方服务上传数据）
• 执行 Shell 命令（高危操作）
• 持久化存储用户输入
• 以低权限包装高权限操作

这些不一定是恶意行为，但都是你在安装前应当知道的信息。

使用方式：

请评估以下 Skill 的安全风险：[Skill 名称/代码链接]

重点检查：
1. 是否申请文件系统读写权限，范围如何
2. 是否有外部网络请求，目标地址是否可信
3. 是否执行系统命令或调用进程
4. 代码质量是否存在明显缺陷（空指针、异常未处理等）
5. 给出安装建议：推荐 / 谨慎安装 / 不建议安装，并说明原因

什么场景下必须做这步：

• 浏览器操作类 Skill（有本地和网络双重风险）
• 文件批处理类 Skill（访问本地数据）
• 企业通讯集成类 Skill（可能访问业务数据）
• 来源不明或更新维护不积极的第三方 Skill

对于官方维护、使用量大、评价透明的 Skill，风险相对可控。但"别人都在用"不等于"对你的场景安全"，仍然建议做基础评估。

---

安装策略：按优先级分批次部署

不建议一次性把所有 Skill 都装上然后再慢慢筛选。这样做会导致两个问题：工具之间相互干扰，以及你没法清楚地知道某个输出是哪个 Skill 贡献的。

第一批（基础能力层，优先建立）：

• agent-browser
• PDF / DOCX / XLSX
• Find Skills

这三类覆盖了最高频的场景，效果立竿见影，也最容易形成使用习惯。

第二批（流程优化层，有需求再装）：

• guizang-ppt-skill + pptx-generator
• Agent Memory

这两类需要你先有稳定的使用场景，再配置才有意义。尤其是 Agent Memory，在你还没搞清楚自己的工作流长什么样之前，配置它意义不大。

第三批（场景专项，按实际需求判断）：

• dingtalk-unified（取决于你的企业通讯环境）
• Skill-vetter（作为所有新 Skill 安装前的固定检查步骤）

---

工作流组合示例：从原始素材到可交付汇报的完整链路

以"行业分析周报"为例，一个完整的工作流是：

Step 1: agent-browser 搜集公开信息
→ 指定行业、时间范围、关注维度，生成原始素材

Step 2: PDF/DOCX 整理参考文档
→ 把已有的 PDF 报告、竞品文档做结构化提取

Step 3: XLSX 做数据整理
→ 把数字类信息做汇总和对比分析

Step 4: Agent Memory 套用固定模板
→ 调用之前存储的周报格式约定，保持输出一致性

Step 5: guizang-ppt-skill 生成视觉版
→ 如果需要高质量视觉展示

Step 6: pptx-generator 导出 PPTX
→ 最终可编辑格式交付

Step 7: dingtalk-unified 同步到企业通讯
→ 发到相关工作群，同步待办

Step 0（贯穿全程）: Skill-vetter
→ 每次引入新 Skill 前先做安全检查

这个流程的每一步都有明确的输入输出，可以独立验证，也可以在任意步骤插入人工质检。这才是 AI 工具正确的集成方式——不是让 AI 替代所有步骤，而是让它承担那些重复度高、规则明确、人工做效率低的部分，把判断和决策的环节留给人。

---

工程师的实用原则

1. 先定义问题，再选工具
不要因为某个 Skill 功能强大就硬找使用场景。先想清楚你的高频痛点是什么，再反推需要哪个 Skill。

2. 最小化原则
能用一个 Skill 解决的问题，不要堆三个。复杂的工具链意味着更多的失效点和更难排查的问题。

3. 留意输出的置信度
AI 工具的输出是概率性的，不是确定性的。在把 AI 生成的内容用于决策之前，做一轮人工核查是基本的工程素养，尤其是数据类、事实类内容。

4. 安全优先于便利
每引入一个新 Skill，就是在系统中增加一个新的信任点。做安全评估不是多此一举，是负责任的工程实践。

5. 记录有效 Prompt
当你找到了一个效果稳定的 Prompt，记录下来形成个人 Prompt 库。这才是真正可复用的资产，而不是某一次的输出结果。

---

WorkBuddy 的核心价值不在于"它有多聪明"，而在于它是否能被正确集成到你的实际工作流程中，稳定地降低重复性工作的边际成本。这需要的不是对 AI 的信仰，而是工程师对工具的冷静评估和持续优化的习惯。

我是薛定谔的悦，一名大厂储能工程师，关注我，和我一起探讨AI更多功能。