企业官网建设流程全解析

开头

作为一个每天要和十几份周报、月度总结打交道的后端开发，我过去对"AI 编程助手"一直抱着一种"能写代码但做不了完整事情"的刻板印象。直到最近用 WorkBuddy 把团队周报汇总这项重复劳动彻底自动化，我才发现这类工具的价值根本不在"帮你写几行函数"，而在于把一条完整的工作流固化下来，让 AI 从"问答机器"变成"生产线"。我花了一下午搭好工作台、写了一个 skill，现在每周五下午 5 分钟就能出一份质量稳定的部门周报，还能顺手生成 Excel 给领导看。这篇文章就是把完整的思路、操作过程和踩过的坑都摊开来讲。

如果你是开发、运维、产品经理，或者任何每周都要处理重复性文档汇总的人，这篇实战复盘可以直接照着抄。不需要你懂机器学习，也不需要你写过复杂的脚本，我会从场景选择、skill 设计、工作台搭建到实际问题排查一步步拆开说，顺便把很多人问过的"换账号记忆丢失""怎么降低 AI 味""缓存目录能不能改"这些细节一起解决掉。

1. 为什么选中"周报汇总"作为 WorkBuddy 的第一个任务

很多人拿到 WorkBuddy 之后的第一反应是去写代码，这恰恰容易翻车。因为代码生成类任务对上下文要求极高，一个项目几百个文件，AI 很难从头接管；而纯问答又体现不出"工作台 + skill"的威力。我在选场景时卡了一个硬标准：高频、结构化、有明确产出物。

1.1 场景选择的三条判断标准

我挑中周报汇总并不是随手抓的，而是过了三条判断标准：

• 频率足够高：每周都要做，意味着自动化节省的时间能持续累积，不是一次性交付。
• 输入有规律但又不死板：周报里有"本周进展""下周计划""风险点"，但每个人措辞差很多，纯正则脚本根本扛不住。
• 输出必须可验证：汇总结果对错一眼能看出来，出错不会酿成事故，适合拿来做 AI 工具的试验田。

我自己试过用 Python 脚本写一个解析器，写了三版，每版都因为同事换了个说法就崩。后来想明白了：这种"格式半结构化、语义变化多"的任务，恰恰是传统脚本的噩梦，却是大语言模型最擅长的地方。

1.2 为什么单次对话不够，要落到 skill 上

一开始我也直接在 WorkBuddy 对话框里说"帮我汇总一下这些周报"，效果时好时坏。今天好用明天就拉胯，原因很简单：单次对话没有固定的流程约束，AI 每次都在自由发挥。而 skill 相当于把一段最优实践固化成了模板——包含角色设定、处理步骤、输入输出规范，每次调用都按同一套流程执行。

打个比方：你去餐厅跟厨师说"随便炒个菜"，他可能发挥稳定也可能翻车；但如果你给他一份标准菜谱，规定好食材比例、火候、出锅时间，那不管谁来掌勺，出品都不会差太多。skill 就是那张标准菜谱，WorkBuddy 会是那个按菜谱执行的厨师。

1.3 最终整体方案：工作台 + 单个 skill

我的最优解是做成了一个"工作台"。这个工作台里维护着周报原文件目录、一份 skill 定义文件、一个输出目录。每周五把同事的周报丢进输入目录，运行 skill，WorkBuddy 会自动完成读取文件、语义解析、要点归纳、格式整理、生成 Markdown 和 Excel 这一整套动作。

我不需要再写代码，也不需要每次都重新解释背景。工作台保存了项目上下文，skill 保存了流程模板，两者一组合，一个完整的自动化任务就闭环了。这个架构我认为可以复用到很多场景——报销单据汇总、客服工单分类、会议纪要整理，本质都是"半结构化输入 + 语义理解 + 固定格式输出"。

2. 先搞懂 WorkBuddy 的 skill 和工作台，再谈实操

2.1 skill 到底是个什么东西

在深入实操之前，我建议你先从概念上把 skill 和工作台分开。Skill 是一份可执行的流程说明书，它告诉 WorkBuddy 三件事：你的身份是什么、你按什么步骤干活、你输出什么格式。

一个标准的 skill 文件通常包含：

• name：技能名称，比如 weekly_report_summarizer
• description：一句话说清这个技能干什么、在什么条件下触发
• workflow：具体步骤列表，比如先扫描目录、再逐文件解析、然后提炼重点、最后生成报告
• output_format：输出的结构，比如 Markdown 标题层级、Excel 列名
• constraints：一些硬性规则，比如"不要臆造原文没有的数据""保留人名和项目名"

我在第一次用的时候踩了坑，把 skill 写成了一个超长系统提示词，塞了很多废话。后来发现 WorkBuddy 会对 skill 里的步骤做结构化解析，描述越具体、步骤越清晰，执行就越稳定。与其写"仔细分析每份周报"，不如写"对每个文件执行：提取本周进展字段 → 提取风险字段 → 判断是否有阻塞项"。

2.2 工作台：让 AI 记住项目背景的地方

工作台这个概念特别像我印象里 IDE 里的"工作区"，但它多了两层东西：持久化的项目记忆和文件目录绑定。

WorkBuddy 的工作台可以关联你本地的一个文件夹，所有 skill、输入文件、生成结果都在这个目录里管理。这个设计天然规避了一个大问题：对话式 AI 每次聊天都是新的，但只要工作台的上下文被保存，下次打开还能延续之前的记忆。

我自己的目录结构是这样的：

workbuddy-workspace/ ├── weekly-report/ │ ├── input/ # 每周把同事周报丢进来 │ ├── output/ # 生成的汇总结果 │ ├── templates/ # 输出模板 │ └── skill/ │ └── weekly_summary.md └── README.md

这种结构的好处是：一个工作台就是一个自包含的项目，换机器、换账号、甚至分享给同事，只要拷贝整个目录就能接着用。这就是为什么我特别推荐你用工作台而不是直接在对话框里临时操作——对话框里的会话是即时的，工作台里的项目是可延续的。

2.3 和 Cursor、CodeBuddy 这类工具有什么区别

总有人拿 WorkBuddy 和 Cursor、CodeBuddy 对比。我的体感是，Cursor 更偏"结对编程"，核心场景是你写代码它补全，你们共享一个编辑器；CodeBuddy 的侧重点也偏向代码生成和调试。WorkBuddy 的差异点在于它是一个"任务工作台"，skill 机制让它可以承担端到端的业务任务，而不是只停留在代码层面。

换句话说，Cursor 是"帮我写这段代码"，WorkBuddy 是"从领任务到交结果全包了"。我拿周报汇总这个例子给用 Cursor 的朋友看，他说他在 Cursor 里也能做到，但要自己维护一个 agent 循环，远不如 skill 直白。这件事没有绝对优劣，选哪款要看你的核心场景是写大型工程还是执行重复任务流。

3. 完整实操：从安装配置到跑通第一个任务

3.1 环境准备与安装

WorkBuddy 的安装本身不复杂，覆盖 Windows、macOS 和 Linux，直接去官网下载对应平台安装包就行。我更想提的是三件容易被忽略的事：

• 登录账号：安装后第一步登录账号，后续 skill 同步和 reward 关联都需要它。
• 指定工作目录：安装时或首次启动时，WorkBuddy 会询问工作目录，这里建议不要用默认的用户根目录，专门建一个工作区文件夹。
• 系统缓存目录：很多人问"怎么更改系统缓存目录"，其实在设置里能找到缓存路径配置。为什么建议改？我默认装在 C 盘，跑了两周缓存涨到了好几个 G，里面有模型临时文件和历史会话索引，时间长了肯定拖慢速度。我把缓存目录改到 D 盘专门分区的目录之后，不光空间问题解决了，重启后加载速度也明显快了不少。

Linux 环境下需要注意一个点：如果是在服务器上无图形界面运行，要注意进程对工作目录的读写权限。我一开始直接用 sudo 启动，导致生成的文件全部是 root 属主，后来同事根本没法在这个目录里改文件。正确做法是调整目录属主，让当前用户有权限，再启动程序。

3.2 搭建工作台的初始化步骤

安装完成后，我强烈建议花 10 分钟把工作台搭好，后面所有操作都围绕它进行。具体步骤如下：

1. 新建项目，命名 weekly-report-auto。
2. 把本地的 direction weekly-report 关联为该项目的根目录。
3. 在项目内的 skill 子目录下新建文件 weekly_summary.md。
4. 准备一份"参考输出"样例放在 templates/ 目录下，方便 AI 对齐格式。

这里我额外说明一下第 4 步：给 AI 一份你人工做过的标准输出，比在 skill 里写一百句格式要求都管用。我实际测试过，没有样例输出时，生成的 Markdown 虽然内容都全，但标题层级风格每次都不一样；放了一份精心整理过的样例后，输出格式立即稳定了很多。这其实就是 few-shot 的力量，不用惊讶，这个技巧在 WorkBuddy 里同样适用。

3.3 编写第一个 skill：周报汇总器

这个 skill 的核心任务是扫描 input 目录下所有的 Markdown 文件，理解每份周报的内容，剔除客套话，提炼出每个人真正干完的事、下一步计划、存在的风险，最后汇总成一份部门周报，并生成对应的 Excel。

我的 skill 文件最初是这样写的：

--- name: weekly_report_summarizer description: 汇总团队周报并输出部门周报 Markdown 和 Excel --- ## 输入 - 位置：../input/*.md - 格式：每份文件是一位同事的周报 ## 处理步骤 1. 扫描输入目录，列出所有 .md 文件 2. 逐个读取文件，提取三个字段： - 本周完成事项 - 下周计划 - 风险与阻塞 3. 对每个字段进行压缩去重，保留关键信息 4. 生成合并后的部门周报，包含人员维度和小结 5. 将人员维度数据写入 Excel，列：姓名、完成事项、下周计划、风险 ## 输出 - 写回 ../output/部门周报_本周.md - 写回 ../output/明细数据_本周.xlsx ## 约束 - 必须保留原周报中出现的具体项目名称和人员姓名 - 不要臆造原文没有的数据 - 语气用简洁书面语，不使用"我们团队""大家"这类空泛表达

注意我在文档头部用了 YAML 格式的 frontmatter 来写 name 和 description，这是 WorkBuddy 识别技能的一种方式，具体格式在你的客户端版本上可能略有差异，但思路是一样的：把 skill 写成人能看懂、AI 能拆解的步骤式说明。

3.4 执行任务与第一轮调试

skill 写完保存后，回到 WorkBuddy 对话框里运行。第一次执行，我心里也没底，结果果然出问题了：它把"本周跟进项目 A"这种描述识别成了"本周完成了项目 A"，语义颗粒度太粗了。

排查后发现问题出在 skill 里只说了"提取字段"，没有限定归纳粒度。我在处理步骤里补了一条："区分'推进中'与'已完成'，判断依据是原文中的动词和时态，如无法确认则归类为'推进中'。" 加上这条约束后，输出准确率明显提升。

这里有个关键心得：skill 不是一次性写好的，它是一个持续迭代的产物。第一版能用只是开始，后面你需要根据每次翻车的情况不断补充细节。我建议你执行完每次任务后，都反问一句"这次哪里跑偏了"，然后把它写进 skill 的约束里，几次迭代之后，skill 会越用越顺。

3.5 降低 AI 味：输出模板的精细控制

我的周报是要发给部门领导看的，如果里面全是一眼 AI 生成的套话，我宁可不用。在调教输出风格时，我在 skill 里加了一段否决式约束："禁止使用'总的来说''综上所述''与此同时'等过渡词，禁止使用'赋能''抓手''闭环'等空泛词汇，句子尽量短，主动语态"。

效果立竿见影。我再分享一个更有效的小技巧：在 skill 的约束区放一段"反面示例"——把你厌恶的 AI 体句子原样列出来，并明确标注"禁止出现此类表达"。反面示例往往比正面要求更能帮助模型理解边界，这也是我试了很多次才发现的。

4. 常见问题排查与避坑实录

4.1 换账号后如何获得原来账号的记忆

我的经验是：WorkBuddy 的记忆绑定在账号 + 工作台目录两个维度上。账号的云背书同步了一部分配置和技能，但真正完整的项目记忆在工作台目录里。所以换账号后如果你的记忆丢失了，九成是因为新账号登录后 WorkBuddy 默认打开了新工作区，而不是原来那个目录。

解决方法是：换账号前先确认你的工作区目录是本地那个工作台文件夹，换完账号后重新打开这个项目。如果 WorkBuddy 登录逻辑会重置本地路径，你只需手动"打开项目"，选择原来的目录路径即可。这再次说明为什么我建议所有重要操作都放在工作台里，而不是依赖单个聊天会话——聊天记录是脆弱的，目录文件才是持久化的可靠载体。

4.2 Linux 环境下动作奇怪：权限与编码

我在 Linux 服务器上遇到了两个具体问题：

• 生成的 Excel 中文字符乱码。排查后发现是系统 locale 没设置好，Python 环境默认以 ASCII 处理输入文件。解决办法是在启动服务的环境变量里加上LANG=zh_CN.UTF-8。
• WorkBuddy 访问 input 目录时权限不足。原因是目录属于 root，我当前用户无写权限。处理方式是把整个工作台目录的宿主改成当前用户：

sudo chown -R current_user:current_user /path/to/workbuddy-workspace

这个问题容易踩，因为很多 Linux 用户习惯于在服务器上以 root 身份装服务，结果程序能跑但文件权限混乱。

4.3 缓存目录膨胀太快的处理方案

刚才说过，我默认配置下缓存增长速度很快。如果你也发现磁盘占用异常，可以定期清理缓存目录，或者直接在设置里把缓存路径指向更大容量的磁盘分区。清理后第一次启动会较慢，因为要重建索引，这是正常的。

另外，如果团队有多人共用同一台机器，每个人登录后再切换账号，可能因为共享同一个缓存目录产生数据串扰。稳妥的方法是分账号建不同的工作台目录，并为每个目录单独设置缓存子路径，避免相互影响。

4.4 问答速查表

这里整理一份我在使用中遇到的常见问题速查表，方便你直接对照：

5. 复盘：这个方案还能推广到什么场景

跑通周报汇总这件事后，我开始把同一套思路移植到别的任务上，目前试过的两个方向效果都不错，这里一并分享。

第一个是会议纪要结构化。以前开完会要手动整理待办项，现在我把原始会议记录丢进工作台，skill 自动提取决议、负责人、截止时间，输出一份带责任矩阵的纪要，比自己整理快了不知道多少倍。

第二个是投诉工单分类统计。我在另一个工作台里建了一个技能，把客服导出的投诉文本按问题类型归类，统计各类别占比，输出日报。这个场景比周报更复杂，需要技能对业务名词有一定理解，但在 skill 里补充了几条业务词表之后，准确率已经能用了。

我强烈建议你也挑一个痛点场景试试，但有一个合理化建议：第一次落地不要选复杂任务，要从"单次人工 30 到 60 分钟、规则清晰、出错可容忍"的任务开始。这样既不会因为学习成本太高半途而废，又能快速看到效果。

我在实际使用中的体会是：WorkBuddy 这类工具的价值不在于某个单点功能有多惊艳，而在于它把"提示词"这种虚无缥缈的东西变成了可维护、可复用、可传播的工程资产。skill 一次编写、反复使用，工作台把项目上下文稳固下来，这才是真正能落地到日常工作的用法。如果你正准备把某个重复任务交给它，建议就从搭建你的第一个工作台开始，先跑通一个最小闭环，再逐步往里面加细节。这个过程你会踩不少坑，但回头看绝对值得。