企业官网建设流程全解析

去年年底，我从一个技术社区下载了一份号称“200条全覆盖”的 WorkBuddy 指令集，打包文档做得相当精致，分类列得整整齐齐。真拿上台面跑了两天，情况完全不是那么回事——大概有三分之一是空话，三分之一是同一个功能换了三种说法，剩下三分之一倒是能用，但对我日常任务来说属于低频场景。后面我又陆续试了几份类似的“大而全”清单，最后干脆自己动手整理了一份 WorkBuddy 指令集，实测筛选了整整一周，只留下30条。这篇就把筛选方法、留下的指令清单、以及哪些被淘汰的“热门款”一起摊开讲。

1. 筛指令的四个步骤，和“真能用”的判断标准

先说结论：大部分指令集的问题不是“错”，而是“没用”。错指令一跑就知道不对，顶多浪费几分钟；没用指令却会一直躺在你的配置里，每次调用都要占用上下文，还可能跟其他指令打架。所以我拿到任何一份指令集，都会做四轮筛选。

1.1 第一轮：通读剔除“看起来厉害”的虚词指令

第一轮就是通读。通读时我基本只看三件事：触发条件是否明确、执行动作是否具体、输出格式是否可验证。如果一条指令出现了“智能调度”“效能提升”“深度协同”这类词，而且读完之后我不知道它到底让 WorkBuddy 干什么，直接删。

这类指令有一个共同特征：它们不是在描述行为，而是在描述状态。比如“你是一个懂得深度思考的专家，请充分发挥你的能力，给出高质量回答”——这种话对模型没有任何约束力。因为它没有告诉 WorkBuddy 什么情况下触发、输出结构是什么、边界在哪里。真实的指令恰好相反，最好是“条件加动作”的样式：当遇到什么情况，就去做什么，最后给出什么。

第一轮筛下来，大部分“凑字型”和“修辞型”指令基本就都清掉了。

1.2 后三轮：单条实测、任务实测、留存观察

第二轮是单条实测。把每条指令单独丢进新开的会话里，不附带任何额外上下文，直接看 WorkBuddy 的反应。这一步能快速暴露两类问题：一是指令本身写得含糊，WorkBuddy 会反向提问；二是指令要求太高，比如“严格遵循每一步”，实际执行时它做不到。只要是单条跑不通的，我不会花时间调优，直接放弃。

第三轮是任务实测。把通过的指令放进真实场景里跑两三天，比如写周报、整理会议纪要、做文献综述、生成网站页面，观察它是不是真的稳定。单条实测跑通只能说明“不报错”，不能说明“好用”。我遇到过不少指令，单次触发很正常，但一旦任务稍微复杂一点，它就会跳过中间步骤。

第四轮是留存观察。我会在连续使用一周后回看使用记录，统计哪些指令真正被反复用到。有些指令本身没问题，但使用频率极低，这种情况我也会拿掉。因为 WorkBuddy 的上下文空间是有限的，每多一条低频指令，都会挤压真正高频指令的发挥空间。

1.3 我留下的判断标准

经过四轮筛选，最终我能接受的指令必须同时满足四条：

• 可复现：同样条件下执行，输出结构和质量基本一致。
• 不冲突：不会覆盖或干扰已配置的规则和其他指令。
• 有增量：它必须做到默认模式下做不到的事情，否则没有存在必要。
• 可维护：指令文本足够简洁，未来我改一个参数就能适配新场景。

下面是筛选矩阵，我每次评估指令时都会过一遍这张表。

2. 全局规则六条：先把 WorkBuddy 的底层运行模式固定住

我配置 WorkBuddy 的顺序很固定：先写全局规则，再添加具体指令。全局规则解决的是“这个助手长期以什么方式工作”的问题，它应该对几乎所有任务生效，而不是只对某一类任务生效。

2.1 为什么全局规则值得最先配置

很多人拿到 WorkBuddy 之后第一件事就是找各种技能和模板，反而忽略了最基础的运行规则。实际用下来，没有全局规则的时候，WorkBuddy 的输出风格会飘——同样一个“总结一下”，今天输出的是一段纯文本，明天可能变成列表，后天又变成表格。全局规则就是在底层把这台机器的默认参数固定住。后面每加一条新指令，都默认建立在这套参数之上，冲突概率会小很多。

2.2 六条规则逐条拆解

指令 01｜结果导向规则你的身份是工作助理。所有回复先给出明确结论，再给理由和操作步骤；如果结论存在不确定因素，先声明这些因素，再给出基于最常见情况的建议。

这条解决的是“绕圈子”问题。没有它之前，我让 WorkBuddy 分析问题时，它经常先讲背景、再讲原理、最后才落到结论，信息密度很低。加了这条之后，输出变成了“结论先行”的样式，不管是写邮件还是做方案，我都能在三秒内抓住重点。

指令 02｜三层结构规则涉及方案、总结、计划类任务时，按三层结构输出：第一层“目标”，第二层“方案中的关键选择”，第三层“需要用户确认的事项”。

三层结构的好处是强制 WorkBuddy 区分“目标、动作、待确认”三类信息。实际使用中，我发现它特别适合方案类任务：过去它会给一个很长的方案，我根本分不清哪些可以直接照做，哪些需要我决策。现在它会把待确认事项单独列出来，我只需要逐条回复就行。

指令 03｜缺信息问询规则当问题缺少关键信息时，先列出缺失的信息项，再基于最常见假设给出临时答案，并在答案开头注明“当前结论基于以下假设”。

这条是我最推荐的全局规则之一。AI 助手被问到自己不会的问题时，很容易直接编一个看似合理的答案。缺信息问询规则相当于给它加了一个“诚实开关”：它可以给推测性答案，但必须标明推测的前提。实际操作中，“基于以下假设”这句话让我的判断效率高了很多。

指令 04｜脱敏处理规则处理日志、配置文件、文档或用户数据前，先识别并替换手机号、邮箱、密钥、内网地址等敏感信息，脱敏后再继续执行。

这条的安全价值大于效率价值。我把 WorkBuddy 接入了一些本地文件操作场景之后，它经常会把配置文档里的服务地址、密钥片段贴进回复里。脱敏规则相当于给所有任务加了一层保险。你如果只把 WorkBuddy 当聊天工具用，这条可以暂时不开；但只要涉及日志和配置文件，强烈建议打开。

指令 05｜术语处理规则技术名词第一次出现时保留中英文对照；中文书面语优先，但代码、包名、命令、接口名等保持原始写法，不做翻译。

这条主要是为了减少“灾难性翻译”。我让 WorkBuddy 写技术说明时，它经常把“load balancer”翻译成“负载均衡器”倒还好，但把类名、方法名也强行意译，就非常影响使用。加了规则之后，术语处理稳定了很多，Review 成本明显下降。

指令 06｜执行确认规则当用户说“准备开始”或“开始执行”时，才执行可能修改文件系统、网络请求、外部服务的操作；其他时候只输出方案，不实际执行。

这条是我的“后悔药”。WorkBuddy 接入本地环境之后，它偶尔会在用户没确认的情况下尝试执行脚本。加上执行确认规则之后，所有外部副作用操作都多了一道确认闸门，误操作概率大幅下降。

2.3 怎么确认规则真的全局生效

配置完这六条之后，我建议你做一个验证动作：开一个全新的会话，发送一条没有任何上下文的普通任务，比如“帮我整理一个本周工作计划”。然后看输出开头是不是先给结论或目标，再看结尾有没有把“待确认事项”列出来。如果没有，说明全局规则没有被正确加载，问题一般出在两个地方：一是规则被写进了某个局部 skill 而不是全局配置；二是新会话没有触发全局加载。

3. 内容生产八条：写作、综述、网站生成这些硬任务怎么指挥

全局规则固定了运行方式，接下来就是具体场景的指令。内容生产是我使用 WorkBuddy 最重的场景，也是测试指令集时淘汰率最高的场景。下面这八条留下来，是因为它们都经历过至少三次真实任务验证。

3.1 长文与综述

指令 07｜长文四步走写长文时按四步执行：第一步输出大纲，第二步写出每段核心观点，第三步生成完整初稿，第四步自查信息密度并删减冗余。每一步完成后停下来等待确认，不连续执行。

这条是“防跑飞”指令。没有它的时候，我让 WorkBuddy 写 3000 字的方案，它经常一口气生成一大段，结构混乱。四步走把大任务拆成四次确认，每次我都能在大纲阶段就纠正方向，避免后面返工。实测下来，按这条指令写的文章，后期修改量减少了大概一半。

指令 08｜文献综述指令先让我提供文献列表或 PDF 路径；按年份和研究主题分组，分别标注每篇文献的核心结论、方法局限和引用价值；无法确认的信息用[待核]标记，不编造作者观点。

文献综述是最容易翻车的场景。我拿一份十几篇 PDF 的列表跑了三次，第一次它给我生成的内容看起来非常完整，但部分引用其实超出了文献原文的结论，属于模型脑补。加了这个指令之后，它会把不确定内容显式标记为[待核]，我只需要快速排查这些标记即可，工作量降了一大截。

3.2 会议纪要、周报、摘要改写

指令 09｜会议纪要指令根据发言记录，提取四类信息：已形成的决策、待处理事项、责任归属、截止时间。责任人不明确的标问号，不擅自推断。

会议纪要的核心不是记录完整，而是提取行动的链条。这条指令让 WorkBuddy 直接从记录里捞出“谁在什么时间之前做什么”，而不是复述每个人的发言。实际效果很直观——我开完会五分钟后就能拿到一张行动项表格。

指令 10｜周报四栏输出我提供本周事项，你按项目、进展、风险、下周计划四栏输出，每栏不超过三行；没有信息就写“无”，不编造进展。

周报这类任务，最大的问题不是 WorkBuddy 不会写，而是它太会“润色”。没加指令之前，它会把“暂无风险”写成“目前项目总体风险可控，团队协作顺畅”，信息量反而更低。四栏加“无”的限制，让周报回归了记录本质。

指令 11｜摘要重写指令将输入内容改写为指定风格的摘要：信息量不缩减，只替换表达；保留原文中的数字、名称、结论和限定词；输出后附一句改动说明。

当时我需求是把口语化记录改成正式文风。这条指令里最关键的限制是“保留数字、名称、结论和限定词”，否则模型很容易为了顺滑删除限定词，导致语义偏移。比如“大概率在周四完成”会被改成“周四完成”，差别极大。

指令 12｜标题十选指令基于这段内容生成10个标题，按信息量、搜索关键词、吸引力三个维度分别评分，并给出推荐顺序。

这条是在帮一个人做公众号时发现的。没有评分维度的标题生成，输出的十条基本都是同一个模板。加了三个维度后，模型会主动考虑搜索场景和文案场景的差异，推荐顺序也更有参考价值。

3.3 表格化输出与网站生成

指令 13｜表格化整理指令把以下内容整理为表格，列名分别为：事项、现状、责任人、下一步动作；无法填写的单元格写“无”，不允许用“待定”“N/A”以外的方式代替。

这个指令的核心是“违法单元格约束”。表格类输出最怕模糊，以前它会在责任人一栏写“项目组”，等于没写。约束单元格取值之后，输出质量立刻可控，我可以直接拿去发给协作方。

指令 14｜静态网站生成指令生成一个单页静态网站，要求 HTML、CSS、JS 分离，不引入构建框架；先输出目录结构，再逐个文件给完整代码；发布前检查外部资源链接可用性。

WorkBuddy 生成网站本身不稀奇，稀奇的是“生成能直接发布的网站”。这条指令强制它先给目录结构，再给文件代码，避免一次性生成一坨长文本，复制后还要自己拆文件。发布前检查外部资源链接这一句很关键，默认情况下它经常引入无法访问的 CDN 资源。

3.4 一个速查视角

内容生产场景的这八条，核心逻辑都可以用一句话概括：给 WorkBuddy 一个固定的处理框架，然后限制它自由发挥的边界。写长文限制结构，写综述限制信息来源，写周报限制信息量，写表格限制单元格取值。每一处限制，都在为你后面的整理工作省时间。

4. 跨对话记忆五条：让 WorkBuddy 记住你是谁

跨对话记忆是 WorkBuddy 这类工具最容易被高估、也最容易用错的功能。很多人以为“记忆”就是让工具记住你说过的每一句话，实际上记忆的价值不在于存了多少，而在于检索和更新是否顺畅。

4.1 记忆指令的核心不是“记”，是“怎么取”

同样一段偏好，放进记忆库之后，能不能在合适的时候被想起才是关键。我在测试阶段试过把大量信息堆进记忆，结果发现两个问题：一是占用上下文，二是在错误的时候被触发。比如我存过一条“邮件尽量当天回复”，结果它写周报时也把这个偏好带上。所以记忆指令的重心，应该放在触发器上。

4.2 五条记忆相关指令

指令 15｜记忆写入指令把以下内容写入长期记忆，并归入“偏好”标签：……。写入后回复确认，并说明在什么情况下应该使用这条记忆。

我实测下来，“说明在什么情况下使用”这句话能让记忆的命中率高很多。因为 WorkBuddy 需要的是一个触发上下文，而不只是一条静态规则。如果你直接写“我是产品经理”，它很难主动应用；但写成“在涉及产品决策时，默认按产品经理第一视角提供建议”，就会有效得多。

指令 16｜项目状态更新当前项目X的进度是……，关键技术决策是……，下一步计划是……。更新到记忆库，标记为“项目状态”，并覆盖旧版本。

项目状态必须用“覆盖”语义，否则记忆库里会积压多个过期版本。我发现如果不用“覆盖旧版本”这几个字，模型可能会把新老状态都保存下来，下一次引用时就会混乱。

指令 17｜标签化检索指令在记忆库中检索标签“项目X”，按时间倒序列出关键结论、变更点和未完成事项。

标签检索是跨对话记忆里性价比最高的操作。它不需要模型理解所有上下文，只需要按标签做倒序排列。实际操作中，我开始一个新项目会话时，总是先用这条指令把项目背景拉回来，效果比让模型“记住上次进度”稳定得多。

指令 18｜会话开场加载每次新会话开始时，先加载记忆库中标记为“全局”的规则，并在回复开头用一句话提示“已加载全局规则与项目X的状态”。

这个指令适合像我一样同时在交叠多个项目的人。它相当于给每次新会话做了一个“开场检查”，避免你对着一个失忆的助手从零解释背景。我测下来的提示语不用太长，一句话能让我确认状态已加载就够了。

指令 19｜冲突提示指令当我的新指令与已有记忆规则冲突时，先指出冲突点，并列出两个版本的差异，等待我决定以哪个为准，不静默覆盖。

这一条是后期加入的。当时我改了一条周报规则，结果项目状态里还留着旧规则，模型执行时自行选择了新规则，却没有告诉我。加了冲突提示之后，它会把差异点摆在桌面上，我一眼就能看到改动影响的范围。

4.3 三个最常见的记忆误区

误区一：记忆写得越细越好。实际上，越细的记忆越难命中，也越容易在其他任务中产生干扰。你只需要记住稳定的偏好和项目级结论，不需要记住某次任务的临时细节。

误区二：从不清理过期记忆。建议每隔两周用“标签化检索”过一遍记忆库，删掉不再使用的标签。我刚开始没清理，第三周就让模型出现了三次新旧版本冲突。

误区三：把个人偏好写成命令句。比如“你必须在邮件中使用敬语”。这种静态命令缺少触发场景，效果远不如“当撰写正式邮件时，使用敬语”。记忆指令的语法应该是“当……时，做……”。

5. 本地部署与运行维护七条：缓存、日志、配额、权限这些平时没人教

内容生产和记忆类指令解决的是“会不会干活”的问题，而我从开始把 WorkBuddy 接到本地环境之后，才意识到真正的坑都在运行维护上。这一小节可能是整份指令集里最不“炫技”的部分，但也是让我省心最多的部分。

5.1 部署前先做环境体检

指令 20｜环境体检指令检测当前机器的 CPU、内存、磁盘占用和网络延迟，输出一份适合运行 WorkBuddy 本地服务的体检报告，并给出最低配置建议。

这条是接到本地环境的第一条指令。WorkBuddy 在不同配置的机器上表现差异非常大，尤其内存和缓存盘IO，直接影响推理速度。跑一次体检，后面调参心里就有底了。体检报告不用理解每一行，只需要关注两个数字：可用内存和系统盘剩余空间。

5.2 缓存目录迁移和资源配比

指令 21｜缓存目录迁移指令将 WorkBuddy 缓存目录从系统盘迁移到指定路径（Windows 如 D:\WorkBuddyCache，Linux 如 /data/cache），迁移完成后保留原路径软链接，并验证读写正常。

系统缓存目录一直放在C盘会导致系统盘慢慢被填满。最稳的做法不是直接把目录拷过去，而是迁移后保留软链，这样 WorkBuddy 索引旧路径时依然能正常读写，同时实际文件已经落到D盘。热词里有人问“系统缓存目录能不能改到 D 盘”，可以明确回答：能改，而且推荐带软链接方案去改，不要用删目录的方式“省事”。

指令 22｜资源配比指令本地部署且内存受限时，按 7:3 分配推理缓存和工作内存；当内存占用超过总内存 85% 时，主动提醒我关闭部分扩展。

这条属于运维调优。我测试过多种配比，7:3 在我的机器上最稳，既保证推理缓存不频繁丢失，又给工作进程留了余量。85% 这个阈值是安全边际，因为一旦内存打满，整个服务会卡顿甚至假死。

5.3 日志诊断与定时维护

指令 23｜任务日志诊断指令读取最近一次失败任务的日志，按“错误类型—发生位置—修复动作—预防动作”四段输出诊断结果。

没有日志诊断指令之前，遇到任务失败我只能整个日志文件甩给 WorkBuddy，让它自由发挥。结果它经常只描述错误现象，不给修复步骤。四段式输出强制它把“修复”和“预防”都写完，每次排查时间能缩短一半以上。

指令 24｜定时维护指令每周日晚上检查缓存大小、旧日志和临时文件，清理超过30天的临时文件，并输出一份清理报告。

定时维护是“平时感觉不到、出事才知道重要”的活。我设了周日检查，三个月下来，缓存目录增速明显降下来了。这里有一个细节：清理范围只限定30天以上的临时文件，不要顺手清理模型缓存，否则下周第一次任务会慢到怀疑人生。

5.4 配额、权限和安全

指令 25｜配额预算指令在执行消耗类任务前，先估算预计消耗，列明本次调用和整月累计；超过月度预算时停止执行，并等待我确认。

WorkBuddy 接远程能力后，积分和配额消耗是个隐藏成本。我吃过一次亏：让模型批量处理一批文件时，它一次性开了很多消耗任务，配额一下就见了底。加了配额预算指令后，每轮消耗前都会先告诉我“这一批预计会用掉多少”，我就能控制批次大小了。

指令 26｜Skill 权限确认指令连接外部 Skill（数据库、网盘、代码仓库等）时，先列出该 Skill 可以读取的资源类型和可写入的资源范围，得到用户确认后再执行读写操作。

MCP 这类的 Skill 接入后，相当于把外部工具的手柄交到了 WorkBuddy 手里。权限确认指令主要用于一件事：防止它“顺手”写入了不该写的资源。实际使用中，“先列读写范围再执行”这句话带来的安全感，用过一次就回不去了。

6. 拾遗四条和避坑清单：为什么有些热门指令我一条都没留

最后要说的四条，是前面四类场景都覆盖不到、但在真实工作流里反复被用到的“低频高价值”指令。再往后，就是那些被很多人追捧、但我一条都没留的“热门款”。

6.1 最后的四条高频指令

指令 27｜速查指令输入“/cheat 关键词”，返回与该关键词关联的已配置指令列表，按最近30天使用频率排序。

这是我自己最常用的“元指令”。指令配置多了之后，最大的成本是记忆成本——我不记得自己写过什么。有了速查指令，新开会话后一条 /cheat 就能找回上下文，非常方便。

指令 28｜文档速览指令给定本地文档路径，提取核心结论、关键数据、操作步骤，输出不超过一页的速览，并按“结论—数据—步骤”三段排列。

这条在技术写作和资料整理中极其顺手。我读一份 40 页的调研报告时，用这条指令生成的速览基本能替代中间的浏览过程。注意：它和普通“总结一下”最大的区别在于，它限制输出“一页以内”，强制模型做信息压缩和取舍。

指令 29｜结构换转指令将当前内容转换为指定结构：Markdown 表格、JSON、YAML 或 HTML；转换后先自检一遍格式是否可解析，再输出。

默认情况下，让 WorkBuddy 输出 JSON 经常会混入注释或 Markdown 代码块，导致解析失败。“转换后自检”这句指令直接让模型在输出前多走一道校验逻辑，实际出错的概率降了非常多。

指令 30｜每日复盘指令晚上我把当天的工作记录发给你，你按“完成事项—卡点—可复用经验”三栏整理，并在第二天新会话开始时把复盘结论放在回复最上方。

每日复盘的难点在于“第二天的会话还记得”。我把这条和记忆类指令联动，实现了跨日复盘。三栏结构让复盘不止是流水账，会有意识地提取可复用的经验，坚持几周之后，对自己工作习惯的认识会清楚很多。

6.2 避坑清单：热门但不实用

我在筛选过程中淘汰了不少所谓“神指令”，下面这几类是最典型的。

第一类是超长“万能助理”指令，动辄几百字，把大量角色描述、行为准则、产出规范全部塞进一条指令里。这类指令最大的问题在于上下文占用过高，而且多条规则之间容易抵触。一旦某条任务触发后效果不对，你根本不知道是里面的哪条规则在作祟。

第二类是“模仿名人”指令，要求 WorkBuddy 模仿某个知名博主、作家的文风，但不给任何样本。实测结果是它输出了一套非常悬浮的“像”的东西，信息量反而更少了。如果你真想模仿风格，正确做法是提供至少三篇样本，并让其总结出可复用的句式特征和用词习惯。

第三类是“全自动执行”指令，让 WorkBuddy 在没有任何逐级确认的情况下，自主完成“读取文件到修改多个文件”的一整串操作。这种指令单看很爽，实际用起来风险极大。我保留的全局规则“执行确认规则”就是为了防这一类。

第四类，也是最需要警惕的一类，是网上那些自称“破甲”的指令，本质是想诱导模型突破自身的使用约束。这种指令不仅对长期使用没有任何好处，还会让工具进入不稳定状态，甚至触发安全策略导致功能受限。我的建议非常明确：不要配置、不要测试、不要传播。

6.3 一张对比表，记住经验

把这四条对应起来，你会发现“真能用”的指令和“好看”的指令，它们的差别始终在同一个维度：是否把抽象的愿望转化成了模型可以逐行执行的规则。

我个人在实际操作中的体会是，指令集整理不是一劳永逸的事，而是随着你的使用习惯一起进化的。那30条指令写成之后，我并没有固定在某一版本，而是每隔一两周就用筛法重新过一遍。有些指令可能因为全局规则的更新失去独立性，有些则被场景变化淘汰。你完全不需要照搬这30条，最好的做法是先从这里面挑出跟你日常工作最相关的十到十五条，跑两周，再按自己的筛法调整、删减、补充。真正好用的指令，是那种你平时几乎感觉不到它在工作，但一旦临时关掉，会发现整个工具又变回一个只会“漂亮地空谈”的聊天窗口——到那个时刻，你才算真正摸到这套工具的门道。