• 插图由AI生成

上一篇讲工具选择，最后落到一个问题：

如果任务不是一次性的，个人 Agent 工作台应该怎么设计？

这一篇接着往下走，先不讨论复杂企业系统，也不讨论代码仓库，而是从更日常的办公任务开始。

比如做一套汇报材料。

这篇不是要一次性把所有办公场景都设计完。

更现实的做法，是先选一个高频、边界清楚、有明确产出物的任务，把它做成一个可复用 skill。等这个 skill 跑通以后，再用同样方法慢慢覆盖会议纪要、调研报告、项目周报、方案文档、复盘材料等其他场景。

所以这篇文章的重点，不是“汇报材料怎么做得最漂亮”，而是借这个小案例说明：

这篇文章真正想回答的是：

日常办公工作台可以怎样从一个具体任务开始，逐步沉淀出自己的 skills。

传统做法通常是从 PowerPoint、WPS 或 Keynote 开始。

先找模板，再列大纲，再一页页写标题、正文、图表和备注。图片要自己找，版式要自己调，讲稿要另外写，最后再导出 PDF 或发给同事。

这种方式的优点是直观、可控，适合精修和正式交付。

但它的问题也很明显：结构、素材、讲稿、版本和交付物都靠人手工维护。做完一套材料以后，真正可复用的往往只是一个 PPT 文件，而不是一套可重复执行的制作流程。

后来很多人开始用普通 AI 辅助。

做法变成：打开聊天窗口，让 AI 帮忙写大纲、写几页文案、生成几张图，然后自己再复制到 PowerPoint 里手工拼。

这比纯手工快很多，但很快会遇到新问题：

01 大纲确认过一次，下次还要重新讲。

02 图片命名、讲稿命名、音频命名每次都靠临时约定。

03 哪些步骤需要人工确认，哪些步骤可以自动跑，没有固定规则。

04 生成 HTML、PDF、音频、素材目录时，每次都重新写命令。

05 做完一次以后，经验散落在聊天记录里，没有沉淀成可复用能力。

所以这里其实有三层：

传统 Office 做法：人在编辑器里完成页面。

普通 AI 辅助做法：AI 生成部分内容，人再手工搬运和拼装。

Agent 工作台做法：把材料生产流程、文件规范、工具脚本和模板一起组织起来。

这就是“用 AI 辅助做一份材料”和“搭一个 Agent 工作台”的差别。

用 AI 辅助，是把一个任务问完。

搭 Agent 工作台，是把一类任务变成可重复执行的工作流。

01日常办公工作台不只是文件夹

很多人理解工作台，会先想到一个资料目录。

资料目录当然重要，但还不够。

真正有用的日常办公 Agent 工作台，至少要包含四层东西：

workspace：资料、草稿、产出和归档放在哪里。

workflow：一类任务按什么步骤推进。

tools：哪些脚本、命令、模板可以被调用。

skills：哪些经验已经固化成可复用方法。

如果只有 workspace，没有 workflow，Agent 只能在文件堆里找材料。

如果只有 workflow，没有 tools，很多步骤还是要人手工处理。

如果只有 tools，没有 skills，Agent 不知道什么时候该用哪个脚本，也不知道哪些环节必须确认。

所以工作台的核心，不是“给 Agent 一个文件夹”，而是让它知道：

01 这类工作应该怎么开始。

02 资料应该放在哪里。

03 中间产物怎么命名。

04 哪些动作可以自动执行。

05 哪些节点必须等人确认。

06 交付物怎么验证。

07 做完以后经验怎么沉淀。

02一个具体案例：汇报材料制作 skill

这次可以用一个真实小案例来说明， office-skills 仓库里的一个通用 skill：

office-skills/skills/image-html-ppt-report

它解决的是一类很常见的办公任务：

用图片页和 HTML 播放器制作一套 PPT 风格汇报材料。

这类材料不一定要生成 .pptx。

更适合的方式是：

每页先生成一张稳定图片。

再用 index.html 做播放入口。

需要时补讲稿音频。

需要分发时导出 PDF。

最后形成一套目录：

report-folder/

├── index.html

├── report-assets.md

├── 01-title.md

├── 01-title.png

├── 01-title-script.md

├── 01-title-script-edge.mp3

├── 02-background.md

├── 02-background.png

├── 02-background-script.md

├── 02-background-script-edge.mp3

└── report.pdf

这里面有几个关键约定。

NN-topic.md 是每页图片的提示词或页面设计说明。

NN-topic.png 是最终图片页。

NN-topic-script.md 是纯讲稿正文，里面所有文字都会被送去 TTS 生成音频，所以不能写建议时长、语气说明、标题或制作备注。

NN-topic-script-edge.mp3 是讲稿音频。

index.html 是离线播放器。

report.pdf 是按页码把图片合并出来的 PDF。

这套约定看起来很简单，但它把一次临时制作，变成了一条可重复执行的流水线。

03和传统 Office / PowerPoint 的差别

这里需要先说清楚：这种工作台不是要否定 PowerPoint。

PowerPoint、Keynote、WPS 演示这类工具，仍然是非常成熟的人工编辑工具。它们适合人直接做版式、调动画、改细节、现场演示，也适合组织里已有固定模板和审稿流程的场景。

差别在于工作重心不同。

传统 PowerPoint：解决页面编辑。

普通 AI 辅助：解决局部内容生成。

Agent 工作台：解决材料生产流程。

Agent 工作台不是先打开一个空白 PPT 页面，而是先把整套材料当成一个项目来组织：目标、受众、大纲、提示词、图片、讲稿、音频、HTML、PDF 和素材目录。

所以更合理的关系是：Agent 工作台负责结构、生成、命名、批处理、导出、归档和复用；PowerPoint / WPS 负责人工精修、组织模板、复杂动画、正式审稿和现场编辑。它不是替代 Office，而是把 Office 之前和之后那些散乱的流程工程化。

04从任务到工作流

做汇报材料这件事，不能一上来就让 Agent 自动生成全部内容。

更合理的流程是：

主题/目标

-> 页码大纲

-> 每页提示词

-> 每页图片

-> 可选讲稿/音频

-> index.html

-> 可选 PDF

-> 素材目录

这里最重要的不是脚本，而是确认点。

工作台必须知道哪些地方不能直接自动跑。

所以这个 skill 里把流程分成了三种模式。

第一种是全流程确认模式。

适合正式汇报、对质量要求高的材料。

主题/目标 -> 人确认

页码大纲 -> 人确认

每页提示词 -> 人确认

每页图片 -> 人 review

讲稿 -> 人确认

音频 -> 人试听

HTML / PDF / 目录 -> 自动生成

第二种是确认大纲后自动生成模式。

适合内部初版、快速草稿。

主题/目标 -> 人确认

页码大纲 -> 人确认

提示词 / 图片 / 讲稿 / 音频 / HTML / PDF / 目录 -> 自动生成

第三种是已有素材装配模式。

适合用户已经有图片页和音频，只想生成播放器和 PDF。

扫描目录

-> 提示阻塞性缺口

-> 生成 index.html

-> 导出 report.pdf

-> 可选生成素材目录

这三个模式，其实就是日常办公工作台的关键设计。

不是所有任务都要人一步步确认，也不是所有任务都适合全自动。

工作台要做的是给不同风险等级的任务设置不同自动化程度。

05skills 不是提示词，而是工作方法

很多人会把 skill 理解成一段高级 prompt。

这不够。

真正有用的 skill，至少应该包含几类东西：

1. 任务边界：这个 skill 处理什么，不处理什么。

2. 工作模式：什么时候人确认，什么时候自动化。

3. 文件规范：输入、过程产物、最终产物怎么命名。

4. 工具脚本：可重复执行的操作不要每次重写。

5. 模板资产：固定格式的产出不要每次临时生成。

6. 验证规则：完成前检查哪些东西。

7. 使用说明：同事拿到以后怎么部署和适配。

image-html-ppt-report 这个 skill 里，就不是只有一个 SKILL.md。它还包含中文说明、跨工具部署说明、HTML 模板、workflow 文档和一组工具脚本。具体目录和用法可以直接看 office-skills 仓库。

这时 skill 就不只是“提示词”，而是一个小型办公能力包。

06工具脚本负责稳定动作

日常办公工作台里，Agent 适合做判断、组织、改写和调度。

但稳定动作最好交给脚本。

比如这个案例里，图片生成、音频生成、HTML 生成、PDF 导出和素材扫描都被整理成了脚本。

这些动作不应该每次都让 Agent 临时写代码。

临时写代码有两个问题：

第一，容易不一致。

今天叫 01-title.txt，明天叫 01-title.md；今天音频叫 -讲稿-edge.mp3，明天又叫 -script-edge.mp3。

第二，容易藏硬编码。

比如固定某个目录、固定某个模型、固定某个 base URL、固定只适配某次分享会。

整理成通用脚本以后，目录、模型、base URL、输出文件、是否跳过已有文件等参数，都应该通过命令行或环境变量传入，而不是写死在脚本里。

这就是工具脚本和临时脚本的区别。

临时脚本服务一次任务。

工具脚本服务一类任务。

07模板负责固定界面

这个案例里还有一个很重要的经验：index.html 模板要固化。

一开始的 HTML 是围绕 15 页分享会写的。

缩略图面板也容易写成固定 15 张。

但通用 skill 不能这样。

通用模板应该适配任意页数，不能把某次分享会的 15 页、固定缩略图数量或特定标题写死。模板里要把“这次分享会”的定制内容拿掉，留下通用播放器能力。

assets/index-template.html

这个模板可以被 build_index.py 填入报告标题、图片列表和音频列表，最后生成 index.html。

这也是工作台设计里很重要的一点：

能模板化的产出，不要每次重新设计。

08目录结构让 Agent 知道边界

一个日常办公工作台，可以从一个很朴素的目录结构开始。

比如：

office-workbench/

├── inbox/

├── projects/

├── outputs/

├── archive/

└── .codex/

└── skills/

└── image-html-ppt-report/

inbox/ 放临时输入资料。

projects/ 放正在处理的具体任务。

outputs/ 放最终交付物。

archive/ 放已完成材料。

.codex/skills/ 放这个工作台可复用的 skills。

如果是 OpenClaw，也可以是类似结构：

office-workbench/

├── agent-guides/

│ └── image-html-ppt-report/

├── reports/

├── materials/

├── outputs/

└── memory/

结构不必一开始就很复杂。

关键是要让 Agent 明确：

01 哪些目录是输入资料。

02 哪些目录允许写产物。

03 哪些目录是 skill 和模板，不能随便改。

04 哪些文件是最终交付物。

05 哪些内容应该归档。

否则 Agent 很容易把工作过程、临时文件和最终文件混在一起。

09memory 和 skill 要分工

搭工作台时，还要区分 memory 和 skill。

memory 适合存偏好和事实，比如默认语言、常用比例、是否总要保留素材目录。skill 适合存流程和工具，比如任务分几种模式、文件怎么命名、哪个脚本生成 HTML、完成前怎么检查。

这两者不能混。如果把流程都写进 memory，下一次 Agent 可能只记得一些模糊偏好，不知道具体怎么执行。如果把个人偏好都写进 skill，skill 又会变得过度绑定某个人，分享给同事时不好复用。

所以更合理的关系是：

skill：通用工作方法。

memory：个人或团队偏好。

workspace：当前任务材料。

session：这一次任务状态。

这也是 OpenClaw 这类工具里 tools、skills、session、memory 要分开的原因。

10权限边界要提前定

办公工作台看起来没有代码仓库那么危险，但也不能没有边界。

至少要提前定义几类边界：可以读哪些资料目录，可以在哪些目录生成文件，哪些脚本可以直接跑，哪些节点必须问人，是否允许覆盖已有文件。

在这个汇报材料案例里，可以这样设计：

可以自动执行：

01 扫描素材目录。

02 根据已有图片生成 index.html。

03 根据已有图片导出 PDF。

04 生成素材统计目录。

建议确认后执行：

01 批量生成图片。

02 批量生成音频。

03 覆盖已有 index.html 或 report.pdf。

必须人工确认：

01 页码大纲。

02 正式汇报材料的图片质量。

03 需要对外发布的讲稿和音频。

04 删除或覆盖原始资料。

边界判断

工作台不是越自动越好。它应该把自动化放在低风险、可验证的环节，把人放在目标、结构、质量和发布判断上。

11先覆盖一个场景，再慢慢扩展

如果要从零搭一个日常办公 Agent 工作台，不必一上来就覆盖所有办公场景。

更合理的方式，是先做一个最小版本：

1. 选一个高频任务。

2. 给这个任务建一个固定目录。

3. 固化文件命名规则。

4. 把重复动作写成脚本。

5. 把流程和确认点写成 skill。

6. 把最终产出模板化。

7. 用一两个真实任务跑通。

8. 再把经验整理成 README，分享给同事。

这个案例里的高频任务是“汇报材料制作”。

它不是日常办公工作台的全部，只是第一个可落地的样板。

等这个样板稳定以后，再逐步积累其他 skills，比如会议纪要、调研报告、项目周报、方案文档和复盘材料。每一类任务都可以按同样方式沉淀成一个 skill。

这些 skills 不需要一次性做完。

更好的节奏是：遇到一个高频任务，先用 AI 临时完成；第二次遇到时，整理文件结构和确认点；第三次遇到时，把重复动作写成脚本；再往后，就可以沉淀成 skill。

这些 skill 最好不要只留在某个临时项目目录里。

更适合的做法，是单独建一个仓库来管理。

比如我现在把这次的经验移到了一个公开的 office-skills 仓库里：

office-skills/

├── README.md

└── skills/

└── image-html-ppt-report/

├── SKILL.md

├── SKILL-CN.md

├── README.md

├── agents/

├── assets/

├── references/

└── scripts/

这个仓库不是某一次分享会的附件，而是一个长期积累办公 skills 的地方。根目录的 README.md 说明整个仓库的定位，skills/ 下面每个子目录是一类办公任务，image-html-ppt-report/ 是第一个样板。

这样做有几个好处：

01 skills 不再和某个具体项目绑死。

02 同事可以直接 clone 或复制某个 skill。

03 Codex、Claude Code、OpenClaw 都可以按自己的方式接入。

04 每个 skill 都可以单独迭代、测试和打包。

05 办公经验可以像代码一样版本化。

当这些 skills 慢慢多起来，个人工作台就不再只是一个聊天窗口，而是一个围绕自己真实工作场景逐步扩展的能力系统。

12小结

日常办公 Agent 工作台的关键，不是让 Agent 什么都能做。

而是把高频工作拆成可控流程：

workspace 管资料。

workflow 管步骤。

tools 管稳定动作。

skills 管可复用经验。

memory 管个人偏好。

session 管本次任务状态。

image-html-ppt-report 这个案例说明，一个小任务也可以被工程化：

从主题到大纲，从提示词到图片，从讲稿到音频，从 HTML 到 PDF，从一次经验到可分享 skill。

日常办公工作台的价值，不是把 AI 叫来临时帮忙，也不是一次性做完所有办公自动化，而是把自己反复遇到的一类类工作，逐步变成可复用、可验证、可交接的流程。

如果你对“软件开发工作台”更感兴趣，可以回顾前面那组Agent-First 软件外包项目工作模式，那里讲的是围绕软件项目组织上下文、任务状态、工具脚本和交付流程。

个人办公工作台这个方向，这里先讲到这个粒度。后面 OpenClaw 实战会转向另一个延展方向：低权限服务型 Agent。