企业官网建设流程全解析

我刚接触 WorkBuddy 的时候，正好是团队里所有人都在把 AI 当聊天框用的阶段：遇到问题复制粘贴一段提示词，拿回一段还不错的回答，然后再复制到文档里手工整理。效率确实比搜网页高一些，但总觉得别扭——AI 明明参与了工作，却始终是个“顾问”，不是“同事”。后来我把 WorkBuddy 从单纯对话升级成带技能、带流程、带交付标准的“虚拟工位”，才真正体会到原来 AI 可以像老同事一样，早上接需求、中午给草稿、下午按时交活，遇到不清楚的地方还会主动找你确认。这篇教程就和各位聊聊我自己的完整配置思路、踩过的坑、以及一套可以直接照做的落地方法，目标是把 WorkBuddy 从“聊天工具”变成真正的“干活同事”。

需要先说明一点：目前网上叫 WorkBuddy 的项目其实有好几个分支，有的是独立产品，有的是和 CodeBuddy 同体系的组件，也有一些是个人开发者放出来的社区版原型。这篇内容主要基于“内置技能、可配置工作流、可挂接本地知识库”这一类通用形态来写，核心方法论不挑具体版本。如果你手里的版本菜单对不上，按目录找同类入口即可，不必死磕按钮名称。

1. 先想清楚：你要的是聊天助手，还是干活同事

1.1 “同事型 AI”和“聊天型 AI”的本质区别

我见过太多人抱怨 AI 没用，仔细一看，其实是把 AI 用成了对话机器人。对话式 AI 的特点是“你问一句，它答一句”，上下文断断续续，输出内容五花八门，昨天能用今天不能用，换个说法结果就变。这不是模型变笨了，而是你没有给它一个稳定的“工作上下文”。

“同事型 AI”则完全不同。你给它的不是一个提示词，而是一整套岗位说明书：角色是什么、输入是什么、输出格式是什么、碰到什么情况要请示、什么情况要自主决定、以谁的标准为验收依据。说得直白一点，对话型 AI 像临时工，你推一把它动一步；同事型 AI 像正式员工，你只需要把任务目标讲清楚，它自带流程，知道第一步干什么、第二步干什么，甚至会告诉你“这里缺少材料，请提供”。

WorkBuddy 这类工具的核心价值，就是帮你把临时工转正。它提供了几个关键机制：可固化下来的角色设定、可重复执行的技能包、可编排组合的工作流，以及可以长期挂载的项目知识库。这几样东西组合起来，AI 就不只是“懂你说的表面意思”，而是真的懂“你这个岗位平时怎么干活”。

1.2 WorkBuddy 能覆盖哪些工作场景

从社区实践看，WorkBuddy 适合处理三类事情，我按我的使用频率排个序：

第一类是“知识密集型的写材料活”。比如项目周报、立项方案、需求评审意见、专利技术交底书初稿、调研报告。这类工作的共性是：有固定的输出模板，有相对稳定的参考素材，需要反复调整措辞，但核心劳动大多集中在“消化资料”和“组织语句”上。把资料扔进 WorkBuddy 的知识库，再挂一个“报告生成”技能，它能在几分钟内给出六十分的原稿，人只需要做最后二十多分钟的加工。

第二类是“规则密集型的重复活”。比如批量整理简历、统一格式的合同初审、字段核对、日报汇总。只要你能把筛选规则一条条写清楚，WorkBuddy 可以像流水线工人一样反复执行不抱怨，而且效率稳定。

第三类是“需要多步衔接的流程活”。比如“从需求描述到生成测试用例到输出测试报告”，中间每一步都有依赖关系，需要前一步的结果作为后一步的输入。如果用普通聊天框，你得一次次复制粘贴；用 WorkBuddy 的工作流，每个技能的输出会自动作为下一个技能的输入，中间不需要人肉搬运。

当然它也有短板。凡是需要线下环境判断、需要核对现场物理状态、需要和真实客户打电话确认的事情，现在的大模型同事依然搞不定。认清边界，才能把力使在刀刃上。

1.3 什么时候不值得上 WorkBuddy

有些朋友一听说能搭技能、接知识库，立刻想把所有事情都塞进去，结果折腾了两周，维护成本比手动干还高。根据我的经验，这三类情况不建议上：

• 任务量很小，一周用不到三次，花半天配置完全回不了本；
• 输出高度依赖个人风格，比如商务话语体系极强的高层汇报材料，模板化反而生硬；
• 输入资料格式每个月变一次，知识库和技能刚调好就要推倒重来。

我自己的原则是：同一类任务，只要每个月会重复做两三次以上，才值得做成技能；否则宁可直接在对话框中写提示词。做工具之前先算算时间账，这是不少新手很容易忽略的。

2. 环境准备与部署选型

2.1 三种部署方式怎么选

WorkBuddy 的部署方式，目前主流有三种：云服务直接体验、本地 Docker 部署、私有化服务器部署。我分别说说适用人群。

云服务版适合第一次接触的用户。不用管环境，注册账号配个模型 API Key 就能用，适合先验证“这套玩法适不适合我”。缺点是数据流经过第三方服务器，公司内部敏感资料要慎重。

本地 Docker 部署适合个人开发者和技术型用户。模型 API 仍然可以调用云端大模型，但 WorkBuddy 本体、技能文件、知识库索引都跑在自己电脑上，隐私性明显更好。缺点是需要基本的命令行操作能力。

私有化服务器部署适合团队使用。把 WorkBuddy 装在内部服务器上，成员通过局域网访问，知识库统一维护，技能统一发布，权限统一管理。这样整个团队才能用同一套“同事”标准。缺点是前期的网络、存储、备份、权限都要有人管。

我的建议是：个人先用云服务版跑通流程，觉得这个方法确实能提高效率，再折腾本地部署；团队使用直接上服务器方案，别让每个人都各自为战，否则技能版本对不上，你会疯掉的。

2.2 本地部署完整步骤（Docker 路线）

我自己踩过不少坑之后，整理了一套比较稳的本地部署流程，前提是电脑上已经装好了 Docker Desktop 和 Git。

第一步，拉取项目代码。在终端里执行：

git clone https://github.com/your-repo/workbuddy.git cd workbuddy

注意，不同社区版的项目目录结构差异极大，有的根目录下直接就是 docker-compose.yml，有的还需要进入 example 目录。我建议先执行ls -la看下目录情况，别急着跑命令。

第二步，检查配置文件。执行cp .env.example .env，然后用编辑器打开.env文件，至少要确认两个地方：

• MODEL_API_KEY：填你要使用的大模型 API Key；
• MODEL_BASE_URL：如果是 OpenAI 兼容接口，通常形如https://api.xxx.com/v1；
• WORKBUDDY_DATA_DIR：这个字段设置本机数据挂载目录，一定要设置在你不会清理系统垃圾时顺手干掉的位置。

第三步，启动服务：

docker compose up -d

首次启动会拉取镜像，耗时取决于网络情况。启动后用docker compose ps查看服务状态，看到STATUS: Up基本就算成功了。然后浏览器访问http://localhost:8080，顺利的话能看到 WorkBuddy 的初始化界面。

第四步，测试对话。在界面里随便发一句话，能正常回复，说明底层模型连接没有问题。这一步建议不要跳过，因为很多人把大量时间花在插件配置上，结果最后发现模型 Key 写错了，白白排查一晚上。

提示：如果使用国内模型厂商的 API，记得确认接口是否兼容 OpenAI 格式。多数厂商现在都兼容，但个别需要在 Base URL 后面加上特定路径，这个要以你用的模型服务商文档为准。

2.3 本地知识库与权限初始化

部署完成后，第一件事不是写技能，而是建知识库。我用的是默认的本地向量库模式，配置起来最省心。进入管理后台，找到“知识库”菜单，新建一个项目知识库，例如叫“产品部公共资料”，然后把团队常用的规范文档、历史模板、FAQ 导进去。支持 PDF、Word、Markdown、TXT，不需要预处理，系统会自动做切块和向量化。

这里有一个非常关键的细节：知识库文档要尽量用正式、结构化的版本，不要随便把聊天记录往里扔。向量检索的本事是“模糊查找”，不是“精准阅读”，材料质量直接决定 AI 引用质量。我自己就犯过错误，把一份带批注的混乱草稿扔进知识库，结果后来它引用出来的全是过时信息。

权限方面，如果是单人使用，默认管理员账号就够。团队使用时建议按角色分配：普通成员只能对话和上传附件，技能管理者才能修改工作流，管理员负责知识库整体维护。别贪图方便全都给管理员，人一多误操作的概率会急剧上升。

3. 用“技能”构建第一版同事角色

3.1 技能到底是什么

核心机制必须解释清楚。WorkBuddy 里的“技能”不是简单的一段提示词，而是一个结构化的作业指导书。它通常包含四个部分：触发条件、角色定义、执行步骤、输出规范。触发条件决定什么情况下激活这个技能；角色定义决定 AI 以什么身份说话；执行步骤决定 AI 按什么顺序干活；输出规范决定交付成果长什么样。

为什么强调结构化？因为大模型的风格展示能力很强，但纪律性很差。如果你只是告诉它“写份周报”，它可能会给你写出一篇声情并茂的散文；如果你给它一份周报技能，它就知道必须按“本周完成—数据指标—问题风险—下周计划—需要支持”五个板块输出，而且每周格式保持一致。这样你才能做到“看到 A 就知道 B”，减少逐次校对成本。

3.2 一个标准的技能包长什么样

社区版的技能通常以目录形式存在，目录下包含一个描述文件、一个提示词模板文件，以及可选的参考示例目录。下面是一个我实际在用的“项目周报生成”技能结构：

skill-weekly-report/ ├── skill.yaml ├── prompt.md └── examples/ ├── 周报示例一.md └── 周报示例二.md

skill.yaml是技能的元信息，内容大致如下：

name: weekly-report description: 根据本周工作事项和项目进展，生成结构化项目周报 version: 1.0.0 author: yourname triggers: - "写周报" - "生成周报" - "weekly report" input_params: - name: work_items required: true description: 本周工作事项列表 - name: project_status required: false description: 项目整体进展描述 output_schema: type: markdown sections: - 本周完成事项 - 核心数据指标 - 风险与问题 - 下周计划 - 需要协调支持

这里的重点是description和triggers。description写得越具体，AI 在多个技能并存时越能准确判断该用哪一个；triggers则负责在某些平台的技能触发场景下直接命中，比如你在群里@AI“请生成周报”，它就自动调用这个技能。很多人的技能失效，原因就是 description 写得太模糊，AI 匹配错了。

prompt.md是真正和大模型对话时使用的完整提示词。我在里面放了角色定义、执行要求、知识库引用规则和输出格式，内容类似这样：

你是一名有十年经验的项目管理助理，负责编写项目周报。 请严格按照以下步骤执行： 1. 阅读用户提供的工作事项列表； 2. 在知识库中检索与当前项目相关的历史周报模板与数据口径； 3. 将工作事项分类整理，提炼关键数据； 4. 按照输出 schema 生成周报； 5. 最后检查是否有遗漏事项，有则补充。 要求： - 所有数据必须来自用户输入或知识库，不得编造； - 风险描述要具体，避免“需关注”这种空话； - 下一周计划必须与本周遗留问题对应。

3.3 快速调试技能：先跑通再优化

新建技能后别急着做得完美，先用最小用例跑一遍。比如周报技能，就给它三个工作事项，看它能不能按格式输出。跑通后，再逐步加复杂输入，比如同时给它一份会议纪要、一个项目排期表，看它能不能正确解析。

调试过程中最容易出现的两类问题：一类是输出格式经常变，解决办法是在prompt.md末尾加一句“必须完全按照输出 schema 的章节顺序输出，不得增加或减少板块”；另一类是 AI 忽略知识库内容，解决办法是明确要求“先检索知识库，再开始生成内容，并在回答末尾注明引用来源”。

技能文件修改后，通常需要在 WorkBuddy 管理后台点击“重新加载技能”或重启服务才会生效。本地部署时我经常犯的错是改了 YAML 却忘记重启，导致一直用旧配置，白白浪费半小时。后来我养成了习惯：只要改过技能文件，第一件事就是重启服务，确认加载无误再进行测试。

4. 把任务交给 AI 的艺术：提示词与流程设计

4.1 工作流的基本元素

技能解决的是“一件事怎么做”，工作流解决的是“多个事怎么串起来”。我给 WorkBuddy 搭工作流时，基本只关注五个元素：

• 触发器：什么时候启动流程，比如“新任务创建后自动开始”；
• 节点：一个节点对应一个技能或一个判断动作；
• 变量：节点之间传递的数据，比如上一个节点的输出摘要作为下一个节点的输入；
• 条件分支：什么情况下走 A 路径，什么情况下走 B 路径；
• 结束条件：什么时候流程结束，输出什么最终产物。

打个比方，技能就像是生产线上的一个工位，工作流则是把多个工位按照工序串起来的流水线。每个工位只负责一件事，但连起来之后，整条产线就能自动完成一个复杂产品。

4.2 我常用的“交办→起草→评审→修改→验收”闭环

在真实工作中，领导不会让你甩一份资料直接出终稿，中间至少要经历两三轮修改。WorkBuddy 的工作流设计也应该模拟这个过程。我目前用得比较顺的是一个五段式闭环：

1. 交办阶段：用户输入任务主题、参考材料、期望格式；
2. 起草阶段：AI 调用对应技能，参照知识库输出第一版草稿；
3. 评审阶段：AI 换一个“挑剔评审员”的角色，对草稿进行打分，列出结构问题、数据缺失、逻辑漏洞；
4. 修改阶段：AI 结合评审意见自动修改草稿，输出修订稿；
5. 验收阶段：AI 对比用户要求的验收清单，逐项核对是否达标，给出最终交付物。

很多人的工作流到第二步就结束了，其实这是远远不够的。让 AI 自己审自己的初稿，听起来有点“自己判自己”的荒诞，但在实践里效果出奇地好。因为初稿生成时用的是一种思维模式，评审时切换到另一种思维模式，这模拟了人类“写完初稿放一晚上，第二天再看就能发现问题”的过程，只是 AI 把这段时间压缩到了几秒钟。

4.3 一套可以直接抄的提示词模板

下面这个是通用度极高的任务提示词模板，适用各种工作流节点。我建议你把工作流的每个节点提示词都按这个框架写：

【角色】 你是[具体岗位]，有[年限]年经验，擅长[核心能力]。 【任务目标】 本次任务需要完成[具体目标]，最终产出物为[交付形式]。 【输入信息】 - 任务主题：[描述] - 参考材料：见知识库“XXX”标签 - 约束条件：字数[XXX]，格式[XXX]，受众[XXX] 【执行要求】 1. 第一步：梳理相关信息，列出关键点； 2. 第二步：按照[XXX]标准输出初稿； 3. 第三步：自查以下检查项：[检查项列表]。 【输出格式】 严格按照[结构要求]输出，包含[固定板块1]、[固定板块2]。 【重要提醒】 禁止编造数据；如信息不足，请明确指出缺失项，不要猜测。

这套模板的精髓在于“给定岗位、给定目标、给定输入、给定标准、给定输出结构”，把模糊的人机对话变成清晰的内部交付单。

5. 实操全流程：从需求到交付，一个真实案例

5.1 场景描述：给技术方案做立项评估

理论知识说再多都不如完整走一个案例。我这里挑一个避开了所有敏感信息的通用场景：假设产品部提交了一份《智能排班系统技术方案》，我要用 WorkBuddy 快速产出一份部门评审意见，要求覆盖技术可行性、实施风险、资源需求、与现有系统兼容性四个方面，最终输出一份可以拿去开会讨论的评估报告。

这个过程我会拆成四个节点：资料解析、可行性初评、风险清单生成、报告整合。每个节点对应一个独立技能或者一次提示词调用。

5.2 实际操作步骤

我在 WorkBuddy 工作台里新建一个任务，命名为“智能排班系统评审意见生成”，然后在任务描述里把技术方案的链接或文档上传好。接着，我调用了四个技能节点，用工作流串起来。

第一个节点叫“方案解析器”。这个技能的 prompt 里明确要求：把技术方案中的核心架构、技术选型、模块划分、性能指标、部署方式逐项提取出来，并以结构化表格形式输出。这一步非常关键，因为后续所有评估都建立在这个结构化信息之上。方案原文可能是几十页 Word，信息密度低，不先做提取，大模型后面就很容易漏重点。

第二个节点是“技术可行性初评”。我将第一个节点的表格化输出作为输入，让它对照团队现有的技术栈和知识库里的历史项目案例，逐项判断每一项技术选型是否有落地经验、是否需要额外引入新组件、是否存在明显不成熟的风险点。这个节点我用的是“保守型评审员”角色设定，要求它宁可多标风险，也不要盲目乐观。

第三个节点是“风险清单生成”。它的输入也是第一个节点的结构化信息，但输出重点不同，它要把实施过程中可能遇到的风险按“高、中、低”三个等级排序，并且对每条风险给出具体的触发条件、可能影响、缓解措施候选。这里我特别要求：风险描述必须关联具体的技术点，不能写“可能存在技术风险”这种废话，而应该写“Redis 集群方案未说明分片策略，高并发场景下存在热点 key 风险”。

第四个节点是“报告整合器”。我把前三个节点的输出全部作为输入，按照部门评审意见模板生成最终文档。文档包括“总体评价—分项意见—风险清单—改进建议—评审结论”五个部分。最后，我让人工在这个基础上补一段团队内部讨论形成的补充意见，整个流程就算闭环了。

5.3 中间过程实测记录

整个流程跑完之后，我印象最深的是两点。

第一点，结构化中间产物的威力巨大。方案解析器输出的表格大概有二十多行，涵盖了技术栈、模块清单、性能预估等关键信息。我肉眼扫了一遍，发现它把方案中一个隐蔽的第三方依赖版本问题提取出来了。这个信息散落在原文第几十页的注释里，人工通读方案时很容易略过，但 AI 不会漏，因为它被明确要求逐项提取。

第二点，风险清单真正做到了“能开会讨论”的程度。对比我之前纯粹靠人肉眼读方案找风险，这次用 WorkBuddy 得到的风险清单不仅数量多，而且每条都带了解释和对应缓解建议。当然，它也会有一些过度标注的问题，比如把“团队需要培训”这种所有项目都会有的通用风险也列为中风险。这些冗余条目在人工评审时直接删掉即可，整体质量仍然远超从零开始写。

5.4 人机协作的分工原则

做完这个案例之后，我给自己定了一个分工原则：凡是“扫描、提取、比对、生成初稿”这类高重复、高消耗精力的工作，尽量交给 WorkBuddy；凡是“判断价值、拍板取舍、确认对外口径”这类需要行业经验和组织知识的工作，必须留在人手里。

有人可能会担心，AI 生成风险评估报告会不会不够专业？我的回答是：它本来就不是替代评审专家，它是替代你“通读几十页方案并在脑子里做初步筛选”的那两个小时。你仍然需要花半小时核验它列出的风险是否属实、权重是否合理，但这半小时换来的是两小时的通读时间节省，怎么看都划算。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

这一节列一下我实际使用过程中遇到的高频问题，以及对应的排查思路。每个问题背后都是我或身边同事踩过的坑，建议收藏：

6.2 一个非常隐蔽的 Agent 调用链问题

有一次我搭了一个多节点工作流，上游生成一份“方案摘要”，下游根据摘要生成“评审意见”。结果下游输出的内容明显偏离了原文，我一度以为是模型能力不行。排查了很久才发现，问题出在中间变量传递上——工作流配置里下游节点收到的不是摘要文本，而是上游的“输出文件链接地址”，模型拿到的是一串看不懂的路径字符串，自然就答非所问了。

后来我养成一个习惯：每搭好一个工作流，先跑一个最小用例，专门检查中间环节的输出内容长什么样。如果中间变量是一段没有语义的字符串或乱糟糟的 JSON，先修正变量映射，再去调提示词。这就像新入职的同事和你说“我去做了”，你真得看看他交回来的半成品是什么，不然等到最后才发现方向错了，就很尴尬。

6.3 关于幻觉，我的底线处理办法

大模型编造信息的问题永远无法根除，但可以大幅缓解。我的处理办法永远是这三步：第一，提示词里强制要求“信息缺失时明确说不知道”，从源头上减少编造；第二，知识库文档都标注版本号和适用范围，AI 引用时必须注明来源；第三，凡是输出内容会对外使用的，负责人必须人工复核关键事实和数据。可以坦白说，目前没有任何一个“无限制”的方案能保证模型永远不犯错，真想用 AI 提效，就得接受“人最终把关”的底线。

7. 给新手最后的几条实操建议

7.1 先解决“频率高、痛苦大”的任务

不要一上来就按照教科书搭一个庞大的工作流。我建议你先把日常工作中“每周至少做一次、每次至少花一小时、又烦又机械”的任务列个清单，挑排名第一的那个，用 WorkBuddy 做一个最小技能。跑通小流程之后再想扩大，而不是一上来就全自动。我的第一版技能是让 AI 每周整理竞品动态，大概只花了二十分钟配置，但后来每周稳定帮我省下一个多小时，这也是我继续深挖这套玩法的原动力。

7.2 写技能时，把自己当成“新同事的师傅”

判断你的提示词写得好不好，有一个很简单的标准：如果这段话发给一个完全没有背景知识的新同事，他能不能照着完成工作？如果能，你的提示词就是合格的；如果不能，那就说明你依赖了大量未言明的背景知识，这恰恰是 AI 不知道、也不会主动问的。所以，在技能文件里把上下文补齐：谁需要用、给谁看、格式是什么、什么不能碰、优先级是什么。

7.3 定期给“同事”做复盘的思路

很多人的技能写完之后就再也不管了，但真实业务在变，知识库在更新，如果技能不跟着升级，效果下滑是必然的。我建议每个月花点时间做一次技能复盘：把最近十次 AI 输出翻出来，看看哪几类反馈最多、哪几个环节总出问题，然后针对性修改技能文件或提示词。我上个月就发现周报技能生成的“风险与问题”板块总写得像套话，改了一下评判标准，让它用“假设你自己是部门领导，你最担心这周哪个事情推进不下去”这种视角来写，质量立刻上了一个台阶。

7.4 最后分享一个小技巧

如果你觉得一个技能在单次对话里效果很好，但放到工作流里就变笨，大部分情况下不是模型的问题，而是你在工作流节点里没有把上下文传够。一个简单到几乎不用动脑的修复方式是：在每个下游节点的 prompt 开头，先把上游输出总结成一段简短的文字再送进去。比如“根据以下内容进行下一步评审：……”，做一次手动压缩打包，能让模型回回神，专注在当前节点的子任务上。我在多个项目里用过这个笨办法，相当稳定，比单纯加参数、换模型都来得靠谱。

WorkBuddy 这类 AI Agent 工具发展的速度很快，今天你看到的能力边界，明年可能就完全不一样了。但不管底层模型怎么升级，“把 AI 当同事而不是聊天框”的思路不会过时。多给它一点结构，多给它一点流程，多给它一点反馈，它回报你的，就是稳定省出的时间和一份份能直接用的交付物。希望这篇指南能帮你少走点弯路，早点把这套“同事”也培养顺手。