企业官网建设流程全解析

先把结论放在前面：WorkBuddy 这种 AI 工作台，真正拉开效率差距的不是模型本身，而是你会不会配置技能。我把它从“偶尔用一下的命令行助手”变成每天打开的第一件事，前后只花了两天，核心就是下面这 10 个技能。适合的人群不只是程序员，还包括日常要处理大量文档、做内容、管数据的运营和产品同学。文章不会讲太多理论，重点是把配置过程、注意事项、踩坑记录都摊开给你看。

1. 动手前的准备：三种落地姿势与基础配置

1.1 三种落地方式怎么选

先聊最实际的：WorkBuddy 装在哪。从社区里的问题分布来看，大家主要关心 Linux 版、Ubuntu、网页版和本地化部署。我的建议是：日常轻使用直接打开网页版，处理敏感资料用本地化部署，家里或办公室有常开机器就上 Linux 服务端。

网页版的优点是零安装，登录入口打开就能用，适合临时接需求、快速验证提示词。缺点也很明显：配置技能时，项目文件都在远端，浏览本地目录、连数据库这类操作会受到很多限制。本地化部署则相反，工作台跑在你自己的机器上，数据不出机器，适合公司内部文档处理、代码审查、批量操作本地文件。这里要特别说明一下，本地化部署并不等于本地跑大模型，WorkBuddy 本身是工作台，推理通常还是走模型 API，本地负责的是 skill 编排、文件读写、记忆存储和任务调度。

再说 Linux 版本。我实测下来 Ubuntu 22.04 和 Debian 12 都能顺利跑起来，安装包里已经带了主要依赖，基本不需要手动补环境。如果你跟我一样有常开的服务器，我强烈建议把 WorkBuddy 装在上面，因为后面讲的定时任务、自动日报这类技能，需要程序常驻。桌面版能做的事它都能做，还可以随时随地用网页访问。下面这张表可以帮你在三种方式里快速做决定：

1.2 第一次启动必做的三件事

第一件事，写全局规则。别急着试技能，先给 WorkBuddy 定几条规则，因为只有全局规则对所有任务生效时，后面每个技能才不用重复解释背景。我自己的全局规则大致长这样：

你是我的 AI 工作助理，称呼我“老板”。 默认使用中文回复，代码注释用中文。 输出 Markdown 格式，标题层级从 1 开始。 回答技术问题先给结论，再给理由和示例。 遇到不确定的信息，明确说“不确定”，不要编造。

这段规则放在全局配置文件里，之后的新对话都会自动生效。写的时候注意两点：一是规则不要太长，超过十条反而容易互相覆盖；二是尽量用“要什么”来描述，少用“不要什么”，因为指令越明确，模型越容易执行。

第二件事，规划缓存目录。WorkBuddy 默认把缓存、日志和临时文件放在系统盘，Windows 上通常是 C 盘，用久了容易爆。如果你也遇到“系统缓存目录能改到 D 盘吗”这个需求，答案是可以。在 Windows 上先停掉工作台，然后设置环境变量WORKBUDDY_CACHE_DIR=D:\WorkBuddy\Cache，把原缓存目录下的文件复制过去，再重启。Linux 上同样道理，改成/data/workbuddy/cache这种独立数据盘路径，配合定时清理脚本，能避免很多莫名其妙的卡顿。

第三件事，确认模型和计费策略。同样的任务，不同档位模型消耗的积分差好几倍。日常格式整理、邮件草稿这类低风险任务用轻量模型就行；代码审查、复杂数据分析再切高性能模型。这一步省下来的预算，比任何技能优化都直接。

2. 最值得长期使用的 10 个技能

2.1 全局规则进阶：一份配置规范所有项目

第一个技能和刚才的全局规则有点关系，但这里说的是更进阶的玩法：把全局规则拆成多个场景模块，接项目时按需加载。比如基础人设是所有任务都生效，代码规范只在处理代码时加载，内容风格只在写作时加载。

原理很简单：WorkBuddy 的规则注入是叠加的，全局规则作为底座，项目级规则覆盖项目内的默认行为。举个例子，你的全局规则里写“所有回答用中文”，但某个海外项目需要英文回复，只要在项目配置里加一条“本项目输出语言为英文”，优先级就会覆盖全局规则。这个机制特别适合在多个项目间切换的人。

实操时，我会在每个项目目录下放一个.workbuddy/rules.md，里面只写这个项目特有的约束，比如数据库命名规范、接口文档格式、文档存放路径。这样切项目的时候，WorkBuddy 读到不同目录下的规则，自动调整回答方式，体验真的很丝滑。注意项目规则别写得太细，能覆盖全局默认行为就够了，否则以后维护成本很高。

2.2 跨对话记忆：这个 skill 治好了我的健忘症

WorkBuddy 默认每次对话是独立的，关掉窗口就失忆。跨对话记忆 skill 的作用，是把每次对话的关键结论、待办事项、决策原因，自动追加到一个本地记忆文件里，下次新对话开始时读取。相当于 AI 有了一本随身笔记。

我通常把记忆文件按项目分目录存放，结构类似：

projects/ demo-web/ memory.md api-service/ memory.md

每个 memory.md 里记录几类内容：项目背景、当前进展、下一步待办、关键决策和原因、容易踩的坑。每次对话结束后，我会手动触发一遍“请把本次对话的关键结论写入记忆”，而不是依赖它自动总结。为什么？自动总结有时会把中间过程的试错记录也写进去，干扰后续判断，手动触发反而更干净。

真正提升效率的地方在第二天。早上打开新对话，我直接输入“读取项目记忆，继续推进昨天的进度”，它就自动恢复上下文，不用再花十分钟翻聊天记录。这里有个很重要的经验：记忆文件要放在独立目录，并定期备份，别和缓存目录混在一起。我试过不小心清理缓存时把记忆文件一并清掉的尴尬，从那之后就养成了随手备份的习惯。

2.3 MCP skill：让 WorkBuddy 直接操作外部系统

MCP 你可以理解成一种标准插头协议，把数据库、本地文件目录、内部系统 API 都变成 WorkBuddy 可以直接调用的工具。社区里很多人找 MCP skill 的配置方法，因为它确实是落地效率的关键。

我目前配置了三个 MCP：本地项目代码目录、某个内部管理系统的 API、还有一个测试数据库。配置方式是在工作台配置文件里声明 server 地址和能力列表，类似：

{ "mcpServers": { "local-files": { "command": "stdio", "args": ["--dir", "/data/projects"] }, "internal-api": { "command": "sse", "url": "http://127.0.0.1:9001/sse", "headers": { "Authorization": "Bearer ${TOKEN}" } } } }

配好之后，我可以说“查一下项目目录下最近修改的三个文件，总结改动内容”，它会自主调用目录工具去读文件，而不是靠我复制粘贴。实测下来，MCP 的最大收益是减少了“人翻译给 AI”的环节，信息损耗低了很多。

踩坑也很多。最常见的是 SSE 地址写错、本地服务没启动，排在前两位。还有 token 过期导致间歇性报错，排查的时候留意日志里的 401/403。配置完成后建议先做一次最小验证：让它调用一个无副作用的查询接口，确认链路通。

2.4 一句话生成网站并发布：从想法到上线半小时

这个技能是热词里很显眼的一个：WorkBuddy 怎么生成网站发布。我完整跑通过一次，包括生成落地页、本地预览、部署测试环境。对不常写前端的人来说，这个技能的价值不只是省时间，而是把“做网站”的门槛降到了会说话就行。

具体做法是，新建一个空目录，告诉 WorkBuddy 你的需求，比如：

“帮我生成一个产品落地页，产品名是 WorkFlow，目标用户是中小企业管理者。首页包含产品简介、核心功能三栏卡片、客户评价区、底部 CTA 和联系表单。样式走简洁商务风格，配色用深蓝和白色。生成后用本地预览模式打开。”

它会自动拆分任务：生成页面结构、写内容、套样式、启动本地预览。我确认预览没问题后，再让它“执行发布流程”，把构建产物推到托管平台。这里要提醒的是，发布前一定要先做两件事：检查页面里的链接是否用了相对路径，以及确认没有把密钥或接口地址写死在代码里。我见过真有人把第三方服务的 API key 一起提交上去，几分钟就被机器人扫走。

另外，如果你是做海外产品，域名和 CDN 的配置需要提前在托管平台准备好，WorkBuddy 只负责把静态文件推上去。静态站生成很快，但真正上线前的 DNS 解析、HTTPS 证书、缓存策略还是需要你亲自确认一遍。

2.5 批量文档格式化：救回被格式折磨的半天

做过内容迁移或者文档整理的人都懂，几十个文件标题层级不统一、代码块没标语言、表格参差不齐，手动改能改到怀疑人生。批量文档格式化这个技能，正好解决这一类“简单但重复”的事。

用法是给它一个目录和一份处理规则，它会逐个文件处理。我常用的指令模板：

“处理 /data/docs 目录下所有 .md 文件。规则：一级标题统一用 #；所有代码块标注语言；图片引用统一为相对路径；表格补全空单元格并统一对齐。先给我处理计划，确认后开始执行。”

我把它放在第一优先级，因为它必须严格执行格式规则，容错空间很小。关键技巧是让它先输出处理计划。AI 看了规则之后，会复述自己准备怎么做，你确认计划没跑偏再放行，能避免批量改完发现方向错了的悲剧。

另一个建议是输出到新目录，不要覆盖原文件。原文件是资产，改出问题还能回滚；直接覆盖的话，一旦规则理解偏差，损失是不可逆的。我通常让 WorkBuddy 输出到/data/docs_formatted，核对无问题后用 diff 工具或抽查几份确认无误，再整体替换。

2.6 代码审查与重构：把 AI 当第二双眼睛

说实话，AI 代码审查不能替代人工评审，但当第二双眼睛非常香。尤其在你连续改了十个小时代码，大脑已经麻木的时候，让 WorkBuddy 扫一眼提交前的改动，能抓住很多低级错误。

我习惯在工作目录里跑git diff，把未提交的改动发送给它，然后问：“请按严重程度分级审查以下改动，重点关注空值处理、资源释放、异常捕获和可能的安全风险，每一项给出文件行号和修改建议。”它返回的结果一般分三档：阻塞问题、建议优化、风格提醒。阻塞问题确实能抓到过空指针和未关闭的连接，这些都很容易被疲劳状态忽略。

用得多了有几点体会。第一，不要让 AI 直接修改生产分支代码，它提出的修改建议要逐个确认后再应用，因为大模型偶尔会脑补一些不存在的变量。第二，敏感项目的代码不要提交到云端推理，用本地部署更稳妥。第三，审查结果仅供参考，最终判断还得靠人，尤其是涉及业务语义的部分，AI 只知道代码内部的一致性，不知道业务对错。

2.7 多语言内容本地化：一套术语表管起所有语言

如果你的工作涉及产品出海、多语言文档、海外市场文案，这个技能一定值得落地。它本质上不是单纯的翻译，而是“格式保持 + 术语统一 + 语气一致”的本地化流程。

我先建一个术语表文件，规定哪些品牌词不翻译、哪些术语使用指定译法，比如：

Dashboard -> 仪表盘 Workflow -> 工作流 Deploy -> 发布

然后让 WorkBuddy 读取术语表，说明目标读者和使用场景，再开始翻译。输出的译文会严格保留 Markdown 标题、列表、表格结构，不会因为语言切换打乱排版。这一点对技术文档特别重要，很多翻译工具会把代码块搞坏，用 WorkBuddy 处理就稳得多。

经验是，第一次使用先做一小段试译，人工校正术语和语气后再批量执行。不要跳过这一步，否则错误术语会扩散到所有文档。另外涉及法律条款、营销承诺、价格数字的内容，机器翻译完必须有人工审校，这不是技术问题，是责任问题。

2.8 定时任务与自动日报：让工作台自己跑起来

定时任务技能适合那些每天都要重复的信息整理。比如每天早上拉取订单数据、汇总服务器状态、收集舆情文章，生成日报发到群里，手动做要四十分钟，配置成定时任务以后，睁眼时日报已经躺在那里。

WorkBuddy 在 Linux 上配合 cron 很顺。我先写好一个日报生成指令，存成独立 skill，然后在 crontab 里加一行：

30 8 * * * cd /data/workbuddy && workbuddy run skill:daily_report --output /data/reports/$(date +\%F).md

这里有个细节：cron 执行时的 PATH 往往和你终端不一样。我第一次跑的时候脚本报找不到命令，加了完整路径之后就正常了。另外建议定时任务写清楚输出路径，并把日志单独落盘，方便排查失败原因。

如果是在 Windows 桌面端，也可以用计划任务功能，效果类似。需要注意，定时任务会消耗积分和本地资源，不要为了偶尔用一两次的功能设置高频任务。给任务设置失败重试和异常退出通知，比把任务安排得非常密更可靠。

2.9 本地知识库问答：把资料库变成你的第二大脑

我工作的电脑里散落着几百份 Markdown 笔记、产品文档、会议记录，以前找资料全靠文件名记忆，现在我把它全交给 WorkBuddy 索引。这个技能和跨对话记忆的区别要分清：记忆 skill 记的是会话结论，知识库 skill 检索的是外部历史资料。

配置时只需要指定一个或几个目录，以及索引更新频率。之后我可以直接问“上个月的运营会议里关于拉新方案最后定了什么”，它会先检索相关文件，再基于检索结果回答，并标注信息来源，而不是凭空生成。

使用中有两点要注意。一是权限隔离，不要把所有机密资料都丢进同一个知识库，尤其当工作台服务被团队共享时，检索权限一定要做区分。二是指数更新时机，新文件刚写入时，如果没到更新频率就查不到，可以手动触发一次更新。这个小细节能避免很多“明明有这份文件却搜不到”的困惑。

2.10 缓存与日志整理：长期稳定运行的隐藏保障

最后一个技能不那么炫酷，但我愿意把它放进名单。本地部署或长时间高强度使用 WorkBuddy 的人，一定会遇到缓存目录疯涨、日志占据磁盘的局面。这个问题不比功能报错影响小，磁盘满了服务可能直接挂掉。

先解决缓存目录位置。Linux 下我一般设置环境变量WORKBUDDY_CACHE_DIR=/data/workbuddy/cache，把缓存挪到独立数据盘，和系统盘分开。Windows 下用setx WORKBUDDY_CACHE_DIR "D:\WorkBuddy\Cache"，设置后移动旧缓存并重启。迁移完成后，既能避免 C 盘被写满，也方便一次性清理。

日志方面，建议配置轮转策略，按大小或天数切割，不要无限增长。我自己的习惯是：每周末跑一遍整理指令，让它清理超过 7 天的临时文件，压缩 30 天前的日志，再把当前缓存占用情况输出成一张表。整个过程用时不到两分钟，但能让服务长期保持清爽。

3. 落地过程中我踩过的坑

3.1 技能不触发，先查这三件事

我遇到过明明配置了某个 skill，但调用时它完全没反应的情况。排查下来，最常见的三个原因是：全局规则写得太长，模型在上下文中丢掉了触发条件；技能没有设定清晰的触发词，靠自然语义识别不稳定；skill 文件格式不规范，被工作台静默忽略。

解决方法也不复杂：把每个技能的第一句写成固定的动作指令，例如“技能启动：批量格式化”，同时用一眼能看出的关键词作为开关。配置完后直接跑一条最小测试，比如让它输出“已启动”，确认生效再继续。

3.2 跨对话记忆突然失效，很可能是路径问题

记忆功能最怕的是文件找不到了。我遇到过一次，前一天还能回忆起项目进展，第二天打开却像失忆。后来发现是当时清理缓存时，把记忆目录当成临时目录一并清空了。所以记忆文件一定要放在独立、固定的目录，并且做好备份。

另外一个隐蔽问题：多个会话同时往同一份记忆文件里写，后写覆盖先写，导致部分记录丢失。给记忆文件按日期分块，或者每次写入时追加而不是覆写，可以避免这种相互覆盖。

3.3 MCP 连接失败，按清单快速定位

MCP 的问题通常比技能更直观，因为会直接报连接错误。但错误信息有时候很迷惑，我整理了一张排查清单：

按表格顺序过一遍，大部分问题十分钟内能解决。如果还是不行，就开工作台的调试模式看原始请求日志，信息量会大一倍。

3.4 积分消耗太快，降本其实很简单

经常有人问为什么积分用得这么快。我的观察是，大多数时候不是任务太多，而是用高性能模型处理了太多低价值动作。比如让一个大型模型去给一百个文件改标题格式，消耗必然爆炸。解决方案也很直白：全局默认使用轻量模型，复杂任务在指令里显式指定切换；限制每个任务的最大迭代轮数，避免 AI 在一个问题上反复试探；尽量精简每次对话携带的历史上下文，把无关的旧日志从记忆文件里清理出去。配一个每日用量提醒，超过阈值就发日志，心里始终有数。

4. WorkBuddy 和 CodeBuddy，到底该留哪个

4.1 两者的定位差异

很多人搞不清 WorkBuddy 和 CodeBuddy 的区别，其实从名字就看得出来：Buddy 是伙伴，CodeBuddy 的重心在代码场景，强调代码补全、仓库问答、提交信息生成；WorkBuddy 则把重心放在“工作任务”上，覆盖文档、网站、数据、自动化和内部系统对接。你可以理解为 CodeBuddy 是同桌的编程搭子，WorkBuddy 是管整个工作流的行政助理。

4.2 组合使用的实操思路

如果两个你都有，也完全可以组合使用。我的习惯是：写核心代码逻辑时用 CodeBuddy，因为它对项目结构和语言特性的支持更细；把代码交付后的说明文档、部署脚本、周报汇总、定时巡检这类杂活丢给 WorkBuddy。两者共用一套 prompt 原则，只是执行侧重点不同。

实测下来，双工具配合不会增加多少认知负担，反而能减少来回切换场景时的挫败感。

4.3 迁移与共存建议

从任意一款迁移到另一款，真正需要搬的是技能配置和规则文件。幸好这些大多是基于 Markdown 或 JSON 的文本配置，复制过去后按新格式微调即可。建议迁移前先完整备份旧配置，同时保留一份简版全局规则在新工具里测试，跑通一条核心工作流之后再开始大规模迁移。

如果你想先尝鲜，也别忘了旧工具里可能有很多积累下来的记忆和项目规则，这些都是比工具本身更值钱的资产。

5. 一点个人体会

这套配置我用了大半年，回想起来，最值钱的不是哪个单独技能，而是“全局规则 + 跨对话记忆 + 一批固定触发词”的组合。它让工作台真正记住了我的工作习惯，而不是每次从零开始教。顺便分享一个小技巧：每周抽半小时，把当周新增的 skill、记忆和规则过一遍，删掉不再用的，补上踩坑时发现的新约束。这个习惯听起来简单，却能一直保持配置的干净和高效。做完这些之后，我再也没回到那种“打开工具却不知道让它干嘛”的状态，效率翻倍不是夸张的说法。