企业官网建设流程全解析

把 WorkBuddy 装进工作机的第一周，我差点把它卸载。第一次建好 Agent 让它帮我改脚本，它把我一个验证过的测试用例改崩了，然后非常礼貌地道歉。当时我心里只有一个念头：就这？

真正让我改观的，是第三周一次误打误撞的尝试——把一份我机械操作了两个月的手动报表丢给它定时跑。跑了三周没出错，每天早上到公司直接拿结果。从那天起我才意识到，这工具本来就不是给“改几个文件”用的，它是一套可以长在自己工作流里的自动化台子。三个月下来，我从“装上能用”走到了“敢把日常任务体系交到它手上”，中间攒了 30 个可以复用的实战技巧。这篇按我的使用阶段拆开讲：先解决装好能不能稳定跑，再谈 Skill 和自定义指令的调教，然后是自动化场景怎么做，最后是我觉得最重要的部分——怎么建立对 Agent 的信任边界，以及客服、科研这类具体岗位怎么落地。适合刚装好还在观望的朋友，也适合那种用了两星期觉得“也就那样”的人。

1. 安装只是开始：前三周最该做对的五件事

很多人装完 WorkBuddy 的第一天就开始建 Agent、写 Skill，然后过几天就放弃。我的建议恰恰相反：前两周先别追求“干大事”，把地基打好。这五个技巧是我踩坑踩出来的，顺序也有讲究，按顺序做完，后面会顺很多。

1.1 安装完成后的第一件事：把缓存挪出系统盘

技巧 1：装完先把系统缓存目录改到数据盘。

我最初用 WorkBuddy，跑了两个小时后 C 盘可用空间掉了好几个 G。这工具会在本地持续生成临时文件、索引、运行日志和模型相关缓存，默认路径往往在系统盘。如果你是那种 C 盘常年剩 30G 不到的机器，白屏、卡顿、组件加载失败都会接踵而来——不是软件坏了，是磁盘被撑爆了。

改法不复杂：在设置里找到缓存或存储路径相关选项，把它指到剩余空间比较大的盘，比如 D 盘或 E 盘新建一个 WBData 目录。有一点要提醒：路径尽量不要带中文。有些内部脚本对中文路径支持不完善，明明设置好了，跑起来却报找不到文件，排查半天才发现是路径编码问题。

改完缓存目录后再检查三件事：临时文件目录、日志输出目录、模型/索引目录。不同版本入口不完全一样，但思路一致——凡是本地会产生大量文件的地方，都不要留在系统盘。这是“能不能长期用下去”的分水岭。

1.2 白屏先别重装：按顺序做四步排查

技巧 2：遇到白屏，不要第一反应删了重装。

我印象很深的一次：某天早上打开工作台，界面一片白，转圈图标都不出现。第一反应是卸载重装，重启后问题依旧。后来静下心日志查了一遍，发现是缓存目录里残留了损坏的临时文件，导致界面初始化失败。

下面这张排查顺序是我三次白屏后总结的，比重装快很多：

1. 检查磁盘剩余空间，特别是缓存目录所在盘，低于 10G 先清磁盘。
2. 清理本地缓存：把缓存目录下的临时索引文件删掉，再重启软件。
3. 打开日志文件，看组件加载过程卡在哪一步，日志路径一般在缓存目录下，或者设置里直接可以看到。
4. 查安全软件的隔离区，看是否把 Agent 的某个组件当病毒隔离了。

这四步做完，绝大多数白屏都能定位。只有日志明确显示核心组件损坏，才需要走重装路线。核心原因在于：白屏大多是本地缓存和组件加载问题，重装既耗时，还不一定清得干净残留配置。

1.3 记忆和账号的真相：会话、长期记忆和换号迁移

技巧 3：给 Agent 固定一个独立工作目录，别让它在你个人文档里乱逛。

我的做法是建一个专用目录，比如 D:\WBWorkspace，所有任务默认在这个目录下读写。这样做的好处有三个：权限边界清楚、备份方便、日志好找。更现实的好处是，Agent 不会跑到你的桌面、下载目录里翻出一堆无关文件，也不会在关键时刻改错地方。

技巧 4：会话记录不等于长期记忆，核心规则一定要沉淀成自定义指令。

WorkBuddy 的会话上下文是临时的。你在某次对话里跟它说“以后生成的文件都放草稿目录”，当时它听懂了，第二天新开一个会话，它又忘了。我一开始以为是自己没调对，后来才理解：跨会话的稳定行为，得靠自定义指令、Skill 和配置去承载，聊天记录只是短期上下文。

技巧 5：换账号之前，先导出配置，再做迁移。

我换过一次账号，发现旧账号的会话记忆不会自动继承到新账号。当时我在旧账号里写过很长一段自定义指令，换号后全没了，心态差点崩掉。后来学乖了：换号前先把自定义指令、Skill 配置、缓存目录设置全部导出，新账号做好配置后再导入。如果你的核心工作流已经做成了可复用的 Skill，迁移成本会低很多——这也是为什么我一直强调，别把重要规则只放在聊天里。

2. Skill 贵精不贵多：把 Agent 调教成“你的”工作台

很多人对 WorkBuddy 的第一印象是“一堆 Skill 不知道装哪个”。我一开始也是，看到推荐的 Skill 就想装，装完又不知道什么时候用。这一章讲我怎么筛选 Skill、怎么写自定义指令，以及怎么让输出少一点“AI 味”。

2.1 Skill 的取舍标准：一个月用不到两次就删

技巧 6：装完不用的 Skill 等于负数。

我试过一口气装十几个 Skill，结果很糟糕：Agent 的上下文被撑得很长，响应变慢，遇到复杂指令还会把不同 Skill 的能力混在一起。一个月后我盘点了一下，真正高频使用的只有 8 个：文档解析、网页抓取、定时任务、数据清洗、PDF 处理、SSH 连接、代码审查、消息模板。其余全删了。

判断标准很简单：一个月内没启用过两次的 Skill，直接删。Skill 不是越多越好，它是给 Agent 加约束的。每个 Skill 都会参与指令组装和上下文计算，装得越多，Agent 越容易“什么都懂一点，什么都不精”。只留下与你日常工作强相关的，Agent 的行为会稳定一大截。

2.2 自定义指令三段式写法：角色、约束、输出

技巧 7：自定义指令用“角色-约束-输出”三段式，效果比长篇大论好得多。

我见过很多人写自定义指令，上来就是“你是一个很厉害的 AI，你要帮我处理文件……”这种话信息量很低。我用的是下面这种模板：

角色：你是一个谨慎的自动化运维助理。 约束： 1. 只允许读写 /input 和 /output 目录，其他路径一律不碰。 2. 任何删除操作必须先把目标移到回收站。 3. 结论必须附来源文件和行号。 输出： 先给结论，再给依据；如果涉及多条记录，用 Markdown 表格输出。

为什么三段式有效？角色决定口吻和专业边界——告诉它在什么场景下工作，它就不会用写散文的方式给你处理数据；约束决定行为边界——明确它不能碰什么，比“注意安全”这种空话管用一万倍；输出格式决定结果可用性——固定了格式，后续二次处理、存档、转发表都会非常省力。

技巧 8：负面约束比正面指令更管用。

“只允许操作 /input 和 /output 目录”比“请注意不要随便改动文件”有效得多。Agent 对“不要做XX”的遵循程度，往往比“要做XX”更高。写约束时，优先列出禁止清单：哪些目录不能碰、哪些命令不能执行、哪些操作必须经过确认。这条原则在后面 SSH 命令管理上尤其重要。

2.3 让输出“少一点 AI 味”的具体做法

技巧 9：固定输出格式，先结论后依据。

我所有的自定义指令里都写了同一句话：先给结论，再给依据。这样做最大的好处是，看完第一条就能知道下一步要不要看依据。如果是日常工作流里还要被程序二次处理的内容，固定输出格式更是刚需。

技巧 10：全局风格设置和单次任务指令分开写。

通用要求放进全局设置，比如“语气直接，不要寒暄，不要使用‘总之’‘综上所述’”。任务细节放进每次对话，比如“今天只要处理 2024 年的订单数据”。二者分开写，可以让单次任务的指令尽量短，减少上下文被无关信息污染的几率。指令太长会导致后端组装变慢，还会稀释关键信息的权重。

技巧 11：用禁用词表减少 AI 味。

如果你也嫌 Agent 写出来的内容一股模板味，直接把你反感的词列进指令里禁用掉。我的禁用词表包括：“总之”“综上所述”“需要注意的是”“尊敬的用户”“赋能”“抓手”这类词。同时我会指定口吻：像有十年经验的技术博主直接给结论，不要寒暄。

但这里有个度。有朋友跟我学，要求 Agent“每句话都要很像人，不准出现任何连接词”，结果输出逻辑变得很跳。AI 味不是靠删词彻底解决的，语气自然比堆砌“像人”更重要。

3. 把杂活交出去：四个高频自动化场景的完整思路

有了稳定的环境和可用的 Skill，下一步才是真正“用起来”。我挑四个高频场景讲：定时签到、PDF 批量处理、SSH 连接器、教学场景。它们覆盖了日常任务里最耗人工的那类活，而且上手门槛都不高。

3.1 定时签到类任务：先做幂等再做功能

技巧 12：定时任务先写幂等，再写功能。

“幂等”这个词听着玄乎，用大白话说就是：同一个任务，不管执行一次还是重复执行十次，结果都应该一致。最典型的例子是自动签到：如果某天任务重复触发了两次，系统里不应该出现两条签到记录。

实现幂等最简单的办法是加一个“已完成标记”。每天执行前先检查今天是否已经执行过，执行完了就写一个标记文件或数据库字段，第二天再判断一次。伪代码大概是这样的：

async def checkin_job(): if await already_done(today()): return try: await login() await do_checkin() await mark_done(today()) except Exception as e: await notify(f"签到失败: {e}") await retry_with_backoff(max_retries=3)

技巧 13：失败重试要带退避和通知，不要无限重试。

我见过一个同事的自动化任务，失败后设置每分钟重跑一次，结果一个下午跑了 80 多次全是失败，把日志塞满了，还没提醒任何人。后来改成：失败先等 30 秒重试，连续 3 次失败就停止并通知。通知是给自己的——一个真正敢放权的任务，必须让负责人知道它什么时候“搞不定”，而不是默默失败。

3.2 PDF 批量处理：能用文本提取就别上 OCR

技巧 14：批量处理 PDF 的核心顺序是：先抽取文本、再建索引、后按关键词归档。

我每个月要处理几十份 PDF：合同、报价单、技术文档混在一起。手动归档很痛苦。用 WorkBuddy 的处理流程是这样的：先把所有 PDF 的文本内容提取出来，生成“文件名-正文内容”的索引表；再按关键词规则归类，比如标题里带“合同”的进合同文件夹，带“报价”的进报价文件夹；最后生成一份归档摘要。

技巧 15：别默认开 OCR。

OCR 是 PDF 处理的最后手段，不是默认选项。很多 PDF 本身就是文本型的，直接就能提取文字，上 OCR 又慢又容易出错，还可能把标题里的字母识别成完全不同的字符。我一开始图省事，统一开了 OCR，结果归档准确率反而下降了。先检查 PDF 是不是文本型，再决定要不要 OCR，这一步能省一半时间。

批量处理前一定要先抽两三份文件试跑，确认索引格式符合预期，再全量跑。否则格式错了，几十份文件全部要重新处理。

3.3 SSH 连接器：密钥管理和命令白名单

技巧 16：SSH 连接器用密钥，密码别写进 Skill 文件。

把 SSH 连接做成 WorkBuddy 的一个技能，日常连服务器跑命令确实很方便。但连接信息里的密码千万不要以明文写进 Skill 文件。Skill 文件可能会被导出、同步、分享，密码一旦泄露就是事故。正确做法是使用 SSH 密钥，私钥放到独立文件并设置成只有当前用户可读，Skill 里只记录密钥路径。

技巧 17：SSH 命令做白名单，别让 Agent 自由发挥。

我会在 Skill 里明确列出允许执行的命令和禁止执行的命令：

允许执行： - uptime - df -h - tail -n 100 /var/log/app.log - systemctl status app 禁止执行： - rm -rf - 任何需要交互式输入的命令

为什么不直接让 Agent 完全自由？因为 Agent 再聪明也是概率模型，遇到模糊指令时可能猜一个不合理的操作。白名单的本质是给它的自由意志上一道保险。这一步做不做，直接决定你敢不敢让它在服务器上干活。

技巧 18：把重复的“连接-取数-回复”流程拆成模板。

比如每天早上要连服务器看磁盘水位、负载情况、是否有异常进程，然后生成一句话状态汇报。这种流程完全可以做成模板：固定命令、固定输出格式，Agent 只需要跑一遍并填数据。做模板时要连输出格式一起定好，这样每天的汇报文件可以直接归档，不用二次整理。

3.4 教学场景：把 WorkBuddy 变成课程助教

技巧 19：教学场景的应用，不需要写代码，基本靠对话就能跑起来。

我帮一个做培训的朋友把它用在课程准备上，效果意外地好。老师把讲义 PDF 交给 Agent，让它按章节生成练习题和问答卡；批改作业时，把错题信息粘贴进去，生成针对每个学生的个性化反馈。最花时间的是备课和反馈，这两件事恰好是 Agent 做得不算差、又能明显节省人工的活。

这个场景里有一个值得借鉴的思路：先找最重复、最不需要创造力的环节下手，比如错题归类、讲义转换、要点提取。教学的核心决策仍然留给老师，Agent 只做整理和生成。

4. 最容易被坑的四件事：安全审核、记忆迁移、缓存和日志

这一章是我三个月里真正“翻过车”的地方。安全审核没做就放权，差点把服务器配置文件搞乱；换账号没备份，自定义指令全丢；缓存目录改了日志没改，C 盘还是被占满。一个个说。

4.1 权限边界、前置审核与密钥管理

技巧 20：开工前定义权限边界，最小授权。

给 Agent 建立独立的工作账号或至少独立的工作目录。千万别上来就给整个磁盘的读写权限。最小授权的意思是：它只需要读哪些目录、写哪些目录、执行哪些命令，就只给这些。不授权的目录，对它来说等于不存在。这能挡住绝大多数误操作。

技巧 21：高风险操作加前置审核。

对于删除、覆盖、移动、发送消息这类不可逆或影响范围大的操作，我在指令里要求 Agent 先输出“将要执行的命令+影响范围+风险说明”，确认后才执行。WorkBuddy 如果本身有审核机制就直接用；没有的话，把这条规则写进自定义指令，形成固定流程。这比让它一口气执行到底再后悔要安全得多。

技巧 22：密钥和 Token 别进 Skill 文件。

这条再强调一次。Skill 文件是拿来传播和复用的，里面有 Token 等于把这个 Token 发给了所有会读文件的人。密钥走环境变量或专门的密钥管理器；日志里的 Token 要打码，禁止明文打印。我在一个测试项目里发现 Agent 把 API Key 打进了日志，幸好是测试环境，从那以后所有密钥相关操作都强制走外部存储。

4.2 换账号后记忆不继承？三步完成迁移

技巧 23：换账号的记忆迁移，靠的不是“记住”，而是“沉淀”。

我最初以为 WorkBuddy 的账号像网盘一样，登录后什么都在。实际并不是——跨账号迁移时，会话历史不会自动跟随。正确做法是三步：

1. 换号前，把自定义指令、Skill 配置、各 Skill 的说明文件全部导出。
2. 新账号登录后，先导入指令和 Skill 配置，再确认缓存目录设置。
3. 把核心工作流固化成可复用的 Skill 文件，以后换环境、换机器都能直接复用。

关键思路：不要依赖某个账号的“记忆”，要把规则沉淀成资产。账号是临时的，Skill 文件和配置是可以带走的。

4.3 缓存目录与日志路径：改了这里还得改那里

技巧 24：改完缓存目录，要复查日志输出路径。

我踩过一个很隐蔽的坑：把缓存目录从 C 盘换到了 D 盘，以为问题解决了。结果跑了一周发现 C 盘还是少了几个 G，最后定位发现是日志文件仍然写在旧路径。很多软件的日志路径是独立配置的，不会跟随缓存目录一起迁移。改了缓存目录，顺手把日志目录也迁走，才能真正解决磁盘占满问题。

技巧 25：白屏反复出现时，去安全软件的隔离区看看。

我自己遇到过一次“清缓存、重启、查日志三件套都做了，白屏还是复现”的情况，最后发现是杀毒软件把 WorkBuddy 的某个渲染组件文件隔离了。监控严格的杀软经常会把新装的 Agent 工具误判为可疑程序。白屏一直复现，别死磕软件本身，先看一眼隔离区，加信任名单，再重启一次。

5. 从“敢让它试试”到“敢把活儿交给它”：信任是怎么建立的

前面说了很多具体技巧，但真正让我下决心把日常工作托付给 WorkBuddy，靠的是一套放权方法。简单说：信任不是凭空产生的，是通过流程建立起来的。

5.1 四级放权法：只读、可写、可执行、全自动

技巧 26：按“只读-可写-可执行-全自动”四级逐步放权。

第一个月，我只让 Agent 做只读任务：总结文档、检索资料、分析日志。这类任务出问题的成本很低，哪怕结论不对，人看一眼就能改。第二个月，让它写文件，但所有文件进草稿目录，我检查完再移走。第三个月，才开始让它跑定时任务，而且每个任务都配了失败通知和回滚方案。

每一级都观察几天，确认没有问题，再升到下一级。这套节奏听起来保守，但恰恰是它让我三个月后能放心地把客服交接班摘要、日志巡检、报表生成全部交给自动化。跳过中间任何一级，都可能在某次意外里把信任清零。

技巧 27：给 Agent 建一份“操作白皮书”。

把你认可的操作规范写成文档，直接放进自定义指令的引用列表。比如：“涉及删除文件时，先移到回收站而不是直接删除；遇到不确定的情况，停止执行并说明原因；所有改动必须留下变更记录。”白皮书的好处是，它把“人觉得合理”的标准固化下来，Agent 每次执行时都有可依据的准则，不用靠猜。

5.2 客服负责人：把工单回复变成半自动流程

技巧 28：客服岗快速上手 WorkBuddy，第一步做自动语义分类，第二步自动回复低风险，第三步高风险转人工。

我是一个团队的管理者视角来试这个场景的。客服每天大量工作是在重复回答相似问题。用 WorkBuddy 搭的流程是：先把来单信息自动分类，比如“退款问题”“使用问题”“投诉”；再让 Agent 从知识库里匹配相关答案，生成回复草稿；低风险、命中正确答案的客户问题自动发送，高风险或情绪强烈的客户问题转人工。

这个流程的关键是“自动发送”的边界要定得很窄。我一开始只让 Agent 生成草稿，人工审核了两周，确认准确率稳定后才放开低风险问题的自动发送。客服负责人如果想快速上手，不要直接上全自动，先让它当“智能草稿器”。

技巧 29：交接班摘要可以做成自动化，晨会直接能用。

每天下午 17 点让 Agent 扫描当天未处理的会话，按客户等级整理成摘要：哪些是待回复的、哪些是即将超时的、哪些是高价值客户需要优先跟进。第二天晨会直接看这份摘要，省去人工翻聊天记录的时间。这个功能做起来不难，但对团队的效率提升非常直接。

5.3 科研场景：文献对比与代码排错

科研方向我同样试过。最常见的是文献处理：把一批 PDF 丢给 Agent，让它批量提取每篇的研究问题、方法、结论，生成对比表格。省下的时间非常可观。另一个是代码排错：把报错日志喂给 Agent，让它定位可疑代码并给出修改方案。但无论它给出的修改建议多自信，提交代码前必须人工 review——这跟信不信任无关，是流程要求。

技巧 30：每个自动化任务都装“校验-回滚-通知”三件套。

校验：任务执行后检查结果是否符合预期，比如生成的文件是否存在、行数是否正常；回滚：出问题时能恢复到任务执行前的状态，比如文件先备份再覆盖；通知：任务失败或者结果异常时，必须通知到人。这三件套是“敢把活儿交给它”的底线，缺任何一个，自动化就是定时炸弹。

6. 三个月沉淀的 30 条实战技巧速查表

前面已经逐个讲过原理，这里汇总成一张速查表。我按使用阶段排了序，方便刚接触的朋友照着一步步来，也方便用过一段时间的人快速检索某条经验。

最后再说一个小习惯。我每隔两周会把新踩的坑追加到自定义指令文件里，三个月下来，那个文件已经成了我的操作手册，反而比 WorkBuddy 默认的配置重要得多。这类工具的上限其实不在软件本身，而在使用者的调教程度。别指望装好就万物可干，给它明确的边界和规则，它就能回馈一条稳定的自动化流水线。