企业官网建设流程全解析

1. 先说清楚：我要沉淀的"专家"到底是什么

1.1 一个真实的痛点：我不是不会，是每次都从零开始

我做内容策划和方案交付有五六年了，最烦的从来不是"不会做"，而是每次都从零开始解释同一件事。同一个客户背景、同一套判断标准、同一批格式要求，我在不同的对话里重复描述过几十遍。每次开一个新窗口，工具对我是完全陌生的，它不知道我讨厌"赋能、闭环、抓手"这类空词，不知道我交付的方案必须在三页内讲清成本收益，不知道我整理会议纪要时习惯把"待确认事项"单独列一栏。

这种重复消耗非常隐蔽。单次看起来只有五六分钟，一天下来两三次，一年就是几百个小时。更麻烦的是判断标准会漂移：今天心情好写得松一点，明天赶时间写得紧一点，最后自己都不确定哪一版才是"我的水准"。

WorkBuddy 这类工具真正打动我的地方，不是它比通用对话工具更聪明，而是它允许我把这些东西固化下来。规则写一次，之后所有任务默认生效；资料放进去一次，之后能被反复检索；流程打包一次，之后一句话就能调度。所以标题里说的"把自己沉淀成一个专属专家"，说白了就是三件事：让工具认识我，让工具记住我的判断标准，让工具替我把重复的部分跑掉。

1.2 三层结构：规则层、知识层、技能层

我踩过的最大的一个坑，是一开始把所有东西都往"提示词"里塞。结果提示词写了两千多字，模型反而抓不住重点，输出越来越飘。后来我把整个体系拆成了三层，各管各的，才稳定下来。

这三层的分工逻辑很重要。规则层是长期不变的身份信息，比如我的行业、我的角色、我的输出风格。知识层是不断增长的资产，比如过往案例、行业数据、客户反馈。技能层是可复用的动作序列，比如"把一份会议录音整理成结构化纪要"、"把一份长文档压缩成三条结论"。

分层之后有个很直观的好处：调试的时候你知道该改哪一层。输出风格不对，改规则层；事实记错了，改知识层；步骤漏了，改技能层。如果全堆在一起，你只能整段重写，越写越长，最后自己都读不下去。

我的判断标准很简单：一个东西半年内不会变，放规则层；一周内会变，放知识层；每次都要重走一遍的动作，放技能层。

1.3 为什么不直接用通用对话工具

很多人会问，这些东西我开个对话框，每次粘贴一段背景说明不就行了？能行，但有两个问题绕不过去。

第一是上下文会被稀释。你把背景、资料、任务要求全塞进一次对话，模型要在这堆信息里找重点。资料一多，前面写的规则就容易被"淹没"，输出质量断崖式下滑。这不是模型不行，是注意力本来就是稀缺资源。

第二是资产无法积累。你在对话框里写的东西，关掉就没了。下次开新对话，还是从零开始。这就像租房子住——每个月都付租金，但房子永远不是你的。而搭一套规则+知识+技能的结构，相当于给自己装修了一套房，越住越顺手，东西越攒越多。

我自己的体感是：前两周花在搭建上的时间大概十几个小时，之后每天的重复劳动至少省掉四十分钟。第三周就回本了。这也是我愿意写这篇东西的原因——它不是那种"看起来很酷但用不上"的技巧，而是真的能算清账的投入。

2. 环境落地：WorkBuddy 工作台怎么改成自己的形状

2.1 安装与第一次配置：别急着用，先做三件事

安装本身没什么好说的，官网下载对应平台的版本，跟着向导走就行。Windows、macOS 都有，Linux 版本我用的 Ubuntu 也跑得起来，装完第一次启动会让你选工作目录和登录账号。

真正决定后面顺不顺手的是第一次配置。我建议你坐下之后别急着发第一条指令，先做完这三件事：

• 确定一个固定的工作根目录，比如~/workbuddy-workspace，所有项目子目录都挂在它下面。不要东一个西一个，散在桌面和下载文件夹里，后面接知识库会非常痛苦。
• 把常用资料做一次粗分类，哪怕是先建五个空文件夹：01-项目案例、02-行业资料、03-模板库、04-客户信息、05-临时草稿。分类标准不重要，重要的是先有个容器。
• 登录并确认模型来源。有的版本支持切换本地模型和云端模型，具体能选哪些取决于你装的版本和账号权限，以你界面里实际显示的为准。

这里有个小细节值得说：目录名一定要用英文或者拼音，别用中文加空格。我一开始用"客户资料 汇总"这种命名，后面写脚本批量处理的时候各种转义问题，改名字改了半小时。

还有一个容易被忽略的点：如果你打算接本地模型，先把机器的内存和显存摸清楚。量化后的小参数模型，8G 内存勉强能跑，但响应会慢；16G 以上体验会好很多。硬盘也要留出空间，模型文件动辄几个 G。这些信息在设置页面的模型管理里一般能看到当前占用，装之前先看一眼，省得装到一半发现跑不动。

2.2 自定义指令：写规则比写提示词重要

自定义指令是整个体系里性价比最高的一块。它的作用是对所有任务默认生效，不用你每次重复交代。我现在的全局指令大概是这样组织的，你可以直接抄结构，内容换成你自己的：

# 角色 我是一名内容与方案策划，主要交付对象是中小企业的市场负责人。 # 输出偏好 - 结论先行，第一段必须给出核心判断，不要铺垫。 - 段落短，单段不超过五行。 - 禁止使用空泛词汇：赋能、闭环、抓手、生态位、打法。 - 涉及数据必须标注来源或说明是估算，不允许编造精确数字。 # 工作习惯 - 给我方案时，永远同时给出一个更省成本的替代版本。 - 不确定的地方直接问我，不要自己猜一个答案往下写。 # 红线 - 不涉及任何法律法规解读、政策评价、社会争议话题。 - 不生成任何涉及他人隐私的具体信息。

写规则有几个经验，都是踩出来的。

规则条目要短，一条只讲一件事。我最早写过一条巨长的规则，把风格、格式、语气全塞在一句里，结果是模型每次只执行一半。拆成五六条短句之后，命中率明显上去了。

用否定句要谨慎。"不要啰嗦"这种表述很模糊，模型理解不了边界。改成"单段不超过五行"这种可量化的描述，效果立刻不一样。规则越具体，执行越稳定。

规则总数别超过二十条。超过之后边际收益急剧下降，而且互相之间容易打架。我现在的习惯是每个月月底翻一遍，把三个月都没触发过的规则删掉。规则库和衣柜一样，不清理就会越来越乱。

一个反直觉的发现：加了"不确定就问我"这条规则之后，输出速度变慢了，但返工率下降了一大截。慢一点比反复改要划算。

2.3 目录结构设计：给"专家"一个书桌

工作目录怎么设计，直接决定后面知识库能不能用。我现在的结构大概是这样：

workbuddy-workspace/ ├── 00-inbox/ # 临时丢进来的东西，每周清一次 ├── 01-cases/ # 过往项目，一个项目一个文件夹 ├── 02-knowledge/ # 行业资料、方法论笔记 ├── 03-templates/ # 各类模板，方案、周报、纪要 ├── 04-clients/ # 客户背景与历史沟通要点 ├── 05-output/ # 所有交付物，按年月归档 └── 06-skills/ # 自定义技能的定义文件

这个结构里最关键的是00-inbox和05-output两个。00-inbox是缓冲池，任何临时素材先扔进去，不立刻归类，避免因为"要想怎么归类"而拖延。05-output是成果池，所有对外交付的东西统一放这里，按2025-01这种年月命名，半年后回头看自己的产出曲线一目了然。

中间的01到04是资产区。这里有个原则：资产区只放"已经整理过"的东西。原始录音、聊天记录截图、没读过的 PDF，一律不进资产区。因为知识库检索的时候，垃圾素材会严重干扰结果质量。我吃过这个亏——把一堆半成品丢进去，结果每次检索都返回一堆没用的片段，反而把好的内容挤下去了。

清理节奏我定的是每周五下午半小时。Inbox 清空，Output 归档，顺手删掉三份最没用的素材。半小时听起来不多，但它保证了整个库不会腐烂。

3. Skill 体系：把重复劳动打包成可复用能力

3.1 什么该做成 Skill，什么不该

Skill 的本质是把一段固定的动作序列封装成一个可调用的单元。你可以理解为给工具装了一个"快捷键"，按一下就自动走完一整套流程。

但不是所有重复动作都值得做成 Skill。我用的判断标准叫"三次法则"：同一个动作如果我已经手动做过三次以上，且步骤基本固定，就值得封装。反之，如果每次的输入形态都不一样、中间需要大量人工判断，就先别急，硬做成 Skill 只会变成一个谁都不想用的摆设。

具体到我的场景，值得做的典型是这几类：

这个表的意思是：凡是能被写成"检查清单"的东西，都能做成 Skill；凡是要靠"感觉"的东西，都别做。比如"把一份长文档压成三条结论"就很适合，因为规则明确——三条、每条不超过三十字、必须包含一个动作动词。而"帮我写一封得体的道歉邮件"就不适合，因为得体与否取决于具体关系，封装之后反而会变得生硬。

3.2 我的第一批 Skill 清单与写法模板

我第一批做了六个 Skill，跑了大半年还在用的有四个。这里把定义模板放出来，你可以照这个结构写自己的：

# Skill 名称：长文压缩成三条结论 ## 触发条件 输入内容超过 2000 字，且明确要求"提炼"或"总结"。 ## 执行步骤 1. 通读全文，识别作者的核心主张，不要只抓每段的第一句话。 2. 找出支撑核心主张的关键证据或数据。 3. 生成三条结论，每条格式为：判断 + 一个支撑点。 4. 每条结论控制在 30 字以内，必须包含动词。 5. 输出后附一行"未覆盖的重要信息"，列出被舍弃的一到两点。 ## 输出示例 - 该方案应优先做渠道，因为现有流量成本已高于行业均值。 - 建议先小范围验证，因为同类尝试的失败率缺乏数据支撑。 未覆盖：财务测算部分、团队配置建议。 ## 边界 不适用于诗歌、小说等虚构类文本。

写这个模板的时候有几个细节很关键，也最容易漏。

"触发条件"必须写。不写的话，你会在不该用的时候条件反射地调用它，结果格式被硬套到完全不合适的任务上。我就干过把"压缩成三条结论"用在头脑风暴记录上，把一堆有价值的发散想法硬压成三条，白白浪费了一轮灵感。

"输出示例"必须给。这一步比任何文字描述都管用。给一个具体的样例，模型对齐格式的成功率会高非常多。示例不用写得完美，但结构要和目标输出一致。

"边界"必须写。这一条是最容易被忽略但最有用的。写明"什么时候不该用"，等于给未来节省了一次返工。

另外提一句，Skill 和插件不是一回事。插件更多是把外部能力接进来，Skill 是把你的内部流程固化下来。两者可以配合，但顺序是先有 Skill 再考虑插件——因为流程没理顺之前，接再多外部能力也只是把混乱放大了。

3.3 版本管理与迭代节奏

Skill 一定要做版本管理，否则改着改着就忘了当初为什么这么改。我的做法很简单，在每个 Skill 文件头部加两行：

版本：v3 最后修改：2025-03-11（原因：输出示例太抽象，替换为真实案例）

看起来笨，但真的有用。有一次我把一个 Skill 改坏了，靠这两行记录五分钟就回滚了。没有记录的话，你得凭记忆重建，那基本等于重写。

迭代节奏我定的是不主动改。只有出现下面三种情况之一才动手：

• 连续三次输出都不符合预期，说明规则本身有问题；
• 任务场景发生了结构性变化，比如客户从 To C 换成了 To B；
• 发现了更好的输出示例，值得替换进去。

除此之外一律不动。原因很实际：每次改动都要重新适应，频繁改会让你对工具的稳定性失去信任，最后干脆不用了。稳定比优化重要得多，尤其是前三个月。

4. 知识沉淀：把散落资料变成可检索的专家记忆

4.1 素材来源与清洗原则

知识层是最花时间但回报最持久的一层。我的素材来源主要四块：自己写的交付物、整理过的会议纪要、读过的行业材料、以及自己总结的方法论笔记。注意这四个来源有一个共同点——都已经被我加工过一遍了。这是我给自己定的硬规则：原始素材先进 Inbox 加工，加工完才进知识库。

为什么这么在意"加工过"这件事？因为检索的本质是匹配语义相似度。一堆没整理过的原始文本，里面充斥着口语、重复、中途放弃的句子，它们会跟真正有价值的内容抢位置。我做过一次对比：同一批资料，不加工直接入库存一份，加工后入库再存一份，同样的检索词，加工版返回的结果相关性明显更高。差距大到什么程度？不加工的那版，前五条结果里只有一条能用。

清洗的具体动作有三步：

• 去重：同一份资料在不同时间整理过两版，保留更完整的那版，另一版删掉。重复内容会在检索时重复占位。
• 加标题：每份资料必须有一个能被检索到的标题，不要用未命名文档3这种。标题本身就是最强的检索锚点。
• 标注时间：在文件里写清楚资料的形成时间。行业数据有保质期的，三年后还按老数据做判断是要出事的。

这三步每份资料大概多花两三分钟，但它是整个体系里最值钱的三分钟。

4.2 和笔记工具打通

我平时记笔记用 Obsidian，好处是文件都是本地 Markdown，天然适合作知识库的素材源。打通的方式有两种，看你的使用习惯。

一种是直接把笔记库目录挂进工作区的知识库。优点是省事，改完笔记立刻生效；缺点是笔记库里通常有大量私人内容，混进知识检索会干扰结果。我一开始就是这么干的，后来发现会议纪要检索经常返回我的个人日记片段，非常尴尬。

另一种是建一个单向同步目录。笔记库是主库，定期把里面适合共享的部分复制到02-knowledge。优点是干净、可控；缺点是要维护同步动作。我现在用的是这种，每周五清理目录时顺手同步一次，五分钟的事。

具体选哪种，我建议按一个标准判断：如果你的笔记库里有超过 30% 的内容是你不想让工作场景看到的，就选同步方案。如果没有，直接挂目录更省事。

提醒一句：同步的时候不要双向同步。我踩过这个坑——工作区里改了一版，笔记库里也改了一版，两边冲突，最后靠翻备份才找回来。单向，永远单向。

4.3 本地模型还是云端模型：怎么选

这是个经常被问的问题，我的答案取决于三件事：数据敏感度、机器配置、任务类型。

• 数据敏感度高（比如涉及未公开的客户信息），优先本地模型，宁可慢一点。
• 机器配置一般（内存 16G 以下），量力而行。本地模型跑不动硬跑，体验会差到让你放弃整个体系。
• 任务偏重推理和长文本理解，云端模型通常更稳；任务偏重格式转换和批量处理，本地模型够用，还省钱。

实际操作里我通常是混着用：日常的格式清洗、批量改名、简单摘要走本地；需要深度分析和长文档交叉引用的时候切云端。截图里能看到切换入口，操作本身一键的事。

关于本地模型还有两个细节值得说。第一，量化版本号要选对，同一模型不同量化等级的效果差距比想象中大，宁可多占点硬盘也别选太激进的压缩。第二，本地模型首次加载会慢，之后有缓存会快很多，别在第一次加载慢的时候就断定"本地模型不能用"，给它十分钟。

5. 跑通一次完整任务：从接需求到交付

5.1 任务拆解与指令编写

光有结构不够，得跑一遍才知道哪卡。我拿最近一个真实任务举例：给一家做企业服务的客户出一份竞品分析，最终要交付一份不超过十页的材料。

我的实际流程是这样的。第一步不是写指令，而是先想清楚交付形态。十页、给市场负责人看、要能直接进汇报材料——这三个约束决定了输出不能是那种长篇大论的分析，必须是结论密集、每页一个判断的结构。

想清楚之后才写指令。我的指令有个固定结构，四段：

目标：产出一份不超过十页的竞品分析，读者是客户的市场负责人。 输入：知识库中 02-knowledge/行业资料 下的五份材料，以及 01-cases 里两个同类项目。 约束：每页一个核心判断，判断后必须跟一个数据或事实支撑；不允许出现没有出处的时间。 输出：先给一页目录，我确认后再展开正文，不要一次性全写完。

最后那句"先给目录，确认后再展开"是我后来加的，非常重要。一开始我让工具一口气写完，结果方向错了，十页全废。加了这道关卡之后，返工成本从"重写十页"降到"改一行目录"。

这里的原则是：大任务一定要拆成可检查的中间节点。一次跑完看起来很爽，但出错的时候你只能全部推翻。中间加两三个确认点，总耗时反而更短。

5.2 中间产物管理与人工复核点

任务跑起来之后，中间产物的管理很容易被忽略。我的做法是每个任务建一个子目录，按阶段命名：

05-output/2025-03-竞品分析/ ├── 00-需求记录.md ├── 01-目录.md ├── 02-素材摘录.md ├── 03-初稿.md ├── 04-复核意见.md └── 05-终稿.md

这个结构最大的价值是让复核有据可依。你能看到目录改了几次、素材摘录是不是漏了什么、复核意见是不是都落实了。没有这个结构，你只能靠记忆，而记忆在第三天就不准了。

人工复核点我只设两个，设多了就变成给自己找活干。第一个在目录确认时，检查方向对不对；第二个在初稿完成时，检查事实有没有错。事实核查是绝对不能省的，尤其是数字、时间、名称这三类。工具在长文本里偶尔会把两个来源的数据混在一起，不查就会带着错误交付出去，那是事故级别的。

复核的时候我有个小技巧：不看正文，只看每段的主题句。因为主题句是骨架，如果骨架错了，细节再对也没用。骨架过了再通读细节，效率高很多。

5.3 成本、积分与速度的平衡

成本这块值得单独说。这类工具通常有配额或者积分机制，具体规则看你的版本和套餐，我这里只讲通用思路。

我的原则是把贵的算力用在刀刃上。具体分三类任务：

最容易浪费的是第一类。很多人拿最强的模型去干批量改名的活，一次几十条，配额哗哗掉。这类任务用最简单的处理方式就行，甚至写个正则都能搞定。

还有一个隐藏的成本是重试。同一个任务反复跑五次，成本是五倍。减少重试的关键不在模型，在输入质量——素材乱，怎么跑都跑不对。所以我把大量时间花在整理素材上，而不是花在调参数上。这个取舍我用了很久才想明白：上游的十分钟整理，能省掉下游的一小时重试。

速度上也有个反直觉的经验。给工具设置"先出目录再展开"之后，总耗时其实变长了，但返工少了，端到端的时间反而缩短。如果只看第一次输出的速度，你会觉得加确认点是在拖慢流程，拉长到整个任务周期看，结论正好相反。

6. 踩坑实录与排查速查表

6.1 我遇到过的六个典型问题

跑了几个月，问题攒了一堆，挑最典型的六个说。

第一个：规则写了但不生效。排查下来原因通常是规则写得太长太笼统，或者和另一条规则冲突。解决办法是把规则拆短，一条一件事，然后逐条测试——每次只开一条规则跑一次，看哪条没命中。听起来笨，但这是唯一靠谱的排查方式。

第二个：知识库检索返回不相关内容。百分之八十的情况是素材没清洗干净。先在 Inbox 里筛一遍，把半成品和有重复内容的文件清出去，再重建索引。我遇到过一次怎么调都不对，最后发现是同一个文件存了三份，删掉两份立刻正常。

第三个：网络连接异常。切云端模型时偶尔会连接不上，先看本地网络，再看是不是代理设置干扰。如果是公司网络环境有限制，切回本地模型通常能继续干活，别干等着。

第四个：响应特别慢。三个常见原因：素材一次塞太多、本地模型没加载完、后台有其他任务在跑。我的处理顺序是先看素材量，把单次输入控制在合理范围，长文分批处理。

第五个：本地模型输出质量波动大。量化等级、上下文长度、输入长度都可能影响。可以先固定输入长度做一次对比测试，定位到底是哪个变量在捣乱。如果机器配置确实有限，别硬撑，把重推理的任务切云端。

第六个：不同设备上规则不一致。这是在多台机器上使用时最容易出的问题。养成习惯：所有配置文件放在工作区目录里，换机器时整个目录搬过去，不要依赖工具自带的云同步——两边覆盖过一次就很难查清楚。

6.2 一份可以贴在显示器旁边的避坑清单

下面这些是我用血换来的，直接抄：

• 先想交付形态，再写指令。顺序反了，指令写得再漂亮也是白写。
• 大任务必须有中间确认点。一口气跑完看起来快，出错就是全废。
• 素材没洗完不入库。垃圾进，垃圾出，这条没有例外。
• 数字、时间、名称必须人工核查。这三类是错误的高发区，也是最难在事后发现的。
• 一次只改一个变量。同时改规则又改素材，出问题你根本不知道是哪边的事。
• 每周固定半小时清理。Inbox 清空、Output 归档、删三份最没用的素材。
• 规则库和 Skill 都要写版本记录。两行字的事，救过我好几次。
• 别追求一次到位。第一版一定是粗糙的，先用起来，用起来了才知道哪里该改。

我在实际使用中最深的一个体会是：这套东西的价值不在"用得多花哨"，而在"用得有多稳定"。我见过太多人一开始兴致勃勃搭了一堆规则和技能，两周后全弃了，原因通常是追求完美——规则改来改去，任务跑一半不满意就推倒重来，最后把自己耗没了。

真正跑得下去的做法恰恰相反：规则先写五条够用的，Skill 先做两个最刚需的，知识库先放二十份整理干净的材料。粗糙地跑起来，然后每周改一点点。三个月后回头看，你会发现整个体系已经和当初完全不一样了，而这个过程里你从来没有经历过那种"推倒重来"的挫败感。

最后分享一个我最近才开始用的小扩展：给每个 Skill 加一行"最近一次使用日期"。用不上的自然就沉淀下去了，用得多的会自动浮出来。这个动作几乎零成本，但它让整个体系的迭代方向变得非常清晰——你不需要靠感觉判断该优化什么，数据会告诉你。