企业官网建设流程全解析

1. 为什么我决定给 workbuddy 立一套"家规"

用 workbuddy 超过三个月之后，我经历了一个很典型的心态转变。最开始那两周，我把它当成一个"更聪明的搜索框"——问一句答一句，答得不好就换个问法再问一遍。后来我开始让它帮我处理一些连续性的任务，比如整理项目文档、批量改写文案、按固定格式输出周报，问题就暴露出来了：同一个要求，今天它输出的是表格，明天变成了分点列表，后天又变成了一大段散文。更让人抓狂的是，有些我反复强调过的偏好——比如"不要用'赋能''闭环'这类词""代码注释统一用中文""输出 Markdown 时标题必须带编号"——它记不住，每次都要重新交代一遍。

这种体验本质上不是模型能力的问题，而是约束缺失的问题。大语言模型在默认状态下是一个"高熵"系统，它的输出空间极其宽广，你不给它划定边界，它就会在无数种合理表达里随机游走。这就像你请了一个能力很强但完全不了解你工作习惯的助理：他什么都能干，但每次干出来的东西都跟你想要的差那么一点点，而这一点点累积起来，就是大量的返工时间。

自定义指令（Custom Instructions）就是解决这个问题的核心手段。它的本质是：在每一次对话开始之前，系统自动把一段你预设好的规则文本注入到上下文里，作为模型的"系统级约束"。你不需要每次重复交代，模型在生成任何内容之前，都会先"读一遍"你的规矩。这个机制在业内通常被称为 system prompt 或者 custom instructions，不同平台的叫法不一样，但底层逻辑是一致的——用一段持久化的前置文本，把模型的输出分布往你期望的方向收窄。

我给 workbuddy 定的这套规矩，前后迭代了大概六七个版本，从最开始的三五条，到后来稳定在十几条，中间踩过不少坑：写过互相矛盾的规则导致模型行为混乱，写过太抽象的规则等于没写，也写过太细碎的规则把上下文预算吃光了。现在这套规则跑下来，效果是我基本不用再在对话里重复交代任何偏好，它输出的东西直接就能用，返工率从最初的差不多一半降到了现在的一成左右。

下面我把这套东西完整拆开讲，包括规则该怎么设计、每条规则背后的逻辑是什么、哪些写法是无效的、以及怎么根据你自己的场景去定制。不管你是刚接触 workbuddy 的新手，还是已经用了一段时间但总觉得"差口气"的老用户，这套思路都能直接拿去改改用。

2. 自定义指令到底改的是模型的哪一层行为

2.1 从"每次都说"到"说一次就够"的机制差异

要理解自定义指令的价值，得先搞清楚没有它的时候，你是怎么跟模型交互的。假设你想让 workbuddy 帮你写一段产品介绍，你可能会这样输入："帮我写一段产品介绍，要简洁一点，面向企业客户，不要用太夸张的词，输出成三段，每段不超过一百字。"这段话里其实包含了四类信息：任务本身（写产品介绍）、风格偏好（简洁、不夸张）、受众设定（企业客户）、格式约束（三段、每段百字以内）。

问题在于，下一次你让它写别的东西，这四类信息里的后三类你大概率还要再说一遍，因为模型不会自动记住。而自定义指令做的事情，就是把后三类——风格偏好、受众设定、格式约束——从"每次对话的临时输入"提升为"所有对话的持久前提"。任务本身每次都要变，但你的偏好和约束是相对稳定的，把它们固化下来，你每次只需要说"帮我写一段产品介绍"，剩下的模型自己会按规矩来。

这个机制在技术实现上，通常是把你的自定义指令拼接到系统消息（system message）里，位置在所有用户消息之前。模型在处理你的请求时，这段系统消息会作为最高优先级的上下文参与注意力计算。所以它不是一个"记忆"功能，而是一个"预设"功能——每次对话都是全新的，但每次对话都带着你的规矩开场。

2.2 为什么规则不是越多越好：上下文预算的现实约束

很多人第一次配自定义指令，恨不得把能想到的所有要求都写进去，结果发现效果反而变差了。这里有一个很实际的约束：上下文窗口是有限的，而且规则越多，单条规则的"注意力权重"就越低。

打个比方，你给助理交代三件事，他记得很清楚；你一口气交代三十件事，他可能每件都记得个大概，但每件都做不到位。模型也是类似的道理。当系统消息里有大量规则时，模型在生成每个 token 的时候，需要在众多约束之间做权衡，规则之间如果存在轻微冲突或者优先级不明确，输出就会变得摇摆不定。

我实测下来的经验是：核心规则控制在 8 到 15 条之间比较合适，每条规则尽量用一句话说清楚，总长度控制在 500 到 800 字。超过这个量级，边际收益急剧下降，而且会挤占你实际任务描述的上下文空间。如果你的需求确实很多，正确的做法不是全塞进自定义指令，而是把一部分做成"可复用的提示词模板"，需要的时候手动贴进去。

2.3 自定义指令和提示词模板的分工边界

这里要区分两个容易混淆的东西。自定义指令是"常驻背景"，提示词模板是"临时工具"。前者管的是那些你希望每次都生效的、跨任务的稳定偏好；后者管的是特定任务类型下的专门要求。

举个例子，"输出用 Markdown 格式，标题带编号"这种要求，几乎适用于我所有的任务，所以它应该进自定义指令。"写技术方案时，必须包含风险分析和回滚方案两个章节"这种要求，只适用于写技术方案这一个场景，它就不应该进自定义指令，而应该做成一个模板，需要的时候贴进去。

判断标准很简单：如果一条规则你希望它在 80% 以上的对话里都生效，就放进自定义指令；如果只在特定场景生效，就做成模板。把这两者混在一起，要么是自定义指令臃肿不堪，要么是模板里塞了一堆通用规则造成重复。

3. 我实际在用的规则清单与逐条拆解

3.1 输出格式类规则：让结果直接可用

这一类规则是我最早加进去、也是收益最明显的。核心思路是：让模型的输出格式固定下来，省去我手动调整排版的时间。

我实际用的几条是这样的：

• 默认使用 Markdown 格式输出，标题使用##和###层级，且必须带数字编号。
• 涉及步骤、要点、对比的内容，优先使用有序列表、无序列表或表格，不要写成大段连续文字。
• 代码块必须标注语言类型，非代码的配置示例用普通段落说明。
• 输出中不要使用 emoji 和颜文字。

为什么这几条有效？因为它们把"格式决策"从模型手里拿走了。没有这些规则的时候，模型会根据内容自己判断用什么格式，判断标准是不稳定的。有了规则之后，格式变成确定性的，我拿到输出基本不用再排版。

这里有个细节值得说："标题必须带编号"这条规则，我建议一定要加。因为模型默认输出的标题经常是不带编号的，而带编号的标题在长文档里导航起来方便太多。另外"不要用 emoji"这条也很关键，模型在默认状态下特别喜欢在标题和要点前面加各种符号，在正式文档里显得很不专业。

3.2 语言风格类规则：把"AI 味"压下去

这一类规则解决的是"读起来像不像人写的"问题。模型默认的输出风格有几个典型特征：爱用"通过……可以……""随着……的发展""为……提供支持"这类句式，爱在结尾加一段总结，爱用"总之""综上所述"收尾。这些特征在正式报告里可能还行，但在日常沟通和内容创作里就显得很假。

我的做法是直接列一个"禁用词表"和"禁用句式表"：

• 禁止使用"通过……可以……""随着……的发展""为……提供支持/保障""综上所述""总之"等模板化表达。
• 禁止在文末写归纳性总结段落，内容讲完即止。
• 语气直接、务实，像有经验的人在做分享，不要用教科书式的说教口吻。
• 复杂概念用生活化类比解释，避免堆砌术语。

这几条加进去之后，输出的"AI 味"明显下降。但要注意，禁用词表不能太长，列个七八个最高频的就够了，列太多反而会让模型在写作时畏首畏尾，句子变得别扭。我一开始列了二十多个禁用词，结果模型写出来的东西虽然没那些词了，但读起来磕磕绊绊的，后来精简到八个，效果好很多。

3.3 任务执行类规则：减少来回确认的次数

这一类规则管的是"模型怎么干活"，而不是"模型输出什么"。默认状态下，模型遇到不确定的地方喜欢反问，或者给出多个方案让你选，这在探索阶段是好事，但在执行阶段就很烦。

我的几条规则是：

• 信息足够时直接给出结果，不要反问确认；信息不足时，先按最合理的假设执行，并在结果开头用一句话说明假设。
• 涉及多个步骤的任务，先给出完整步骤清单，再逐步展开，不要边想边写。
• 如果任务存在明显更优的解法，直接采用并简要说明理由，不要罗列所有可能方案。

第一条规则特别有用。以前我让它改一段文案，它会问"你是想要更正式还是更活泼"，现在它会直接按我的风格偏好改一版，然后在开头说"按你偏好的简洁风格处理，如果方向不对告诉我"。这样我拿到的是可以直接看的结果，而不是一个需要我再回复一轮的问题。

第二条规则解决的是"思路混乱"的问题。模型在写长内容时，如果没有先列提纲，很容易写着写着跑偏。强制它先出步骤清单，相当于让它先做规划再执行，输出的结构性好很多。

3.4 领域知识类规则：把个人偏好固化下来

这一类是最个性化的，每个人都不一样。我因为经常处理技术文档和内容创作，所以加了几条领域相关的规则：

• 技术类内容中，涉及参数的必须给出具体数值和单位，涉及操作的必须说明操作意图。
• 中文内容中，中英文之间加空格，专业术语首次出现时给出中英文对照。
• 举例优先使用真实场景，不要用"某某公司""张三李四"这类虚构占位。

这几条规则的价值在于，它们把我平时需要反复纠正的细节一次性固化了。比如中英文加空格这件事，我以前每次都要手动改，现在模型直接按规则输出，省了很多事。

提示：领域知识类规则建议控制在 3 到 5 条，只放那些你最高频、最在意的偏好。放太多会让规则集变得臃肿，而且很多偏好其实用模板处理更合适。

4. 规则设计里最容易踩的四个坑

4.1 规则互相打架：模型行为摇摆的隐形原因

这是我踩过的第一个大坑。我一开始同时写了"输出要详细充分"和"输出要简洁精炼"两条规则，本意是希望模型根据情况自己判断，结果它的行为变得极其不稳定——同一个任务，有时候输出一大篇，有时候就几句话，完全没法预期。

后来我才想明白：规则之间不能有语义上的冲突，哪怕你觉得"模型应该能理解在不同场景下用不同规则"。模型在权衡冲突规则时，并没有你想象的那么智能，它更可能是随机偏向某一条，或者试图折中，结果两头不讨好。

解决办法是给规则加明确的适用条件。比如把上面两条改成："解释概念时充分展开，给出类比和例子；执行具体任务时直接给结果，不要铺垫。"这样两条规则各有各的适用场景，就不冲突了。

4.2 规则太抽象：等于没写

"输出要高质量""内容要有深度""表达要自然"——这类规则看起来很有道理，实际上完全无效。因为"高质量""有深度""自然"这些词，模型无法转化为具体的生成行为，它只能按自己的默认理解来，而那个默认理解跟你想要的可能完全不是一回事。

有效的规则必须是可操作的。什么叫可操作？就是模型读完这条规则，能明确知道"我应该在输出里做什么、不做什么"。比如"不要用 emoji"是可操作的，"输出要专业"是不可操作的；"标题带数字编号"是可操作的，"结构要清晰"是不可操作的。

我现在的习惯是，每写一条规则，都问自己一句：如果我是模型，我读完这条规则，知道具体该怎么改我的输出吗？如果答案是模糊的，这条规则就得重写。

4.3 规则太细碎：把上下文预算浪费在琐事上

跟太抽象相反，另一个极端是太细碎。我有一版规则里写了"逗号用中文全角""数字用阿拉伯数字""日期格式用 YYYY-MM-DD"这类非常具体的格式要求，加起来占了规则集的一半篇幅。结果是，模型在这些琐事上确实听话了，但在更重要的风格和结构上反而表现下降——因为上下文预算被琐事占用了。

规则集的篇幅应该花在"影响面大"的规则上。格式类的细节，如果真的很在意，用模板或者后期批量替换更划算。自定义指令的空间，应该留给那些"每次都要影响输出质量"的规则。

4.4 写完就不管：规则需要迭代

自定义指令不是写完就一劳永逸的。你的工作内容在变，你对输出的要求也在变，规则集需要定期回顾和调整。

我的做法是，每隔两三周回顾一次最近的对话记录，看看有没有反复出现的"我又要手动改"的情况。如果有，说明有一条规则缺失或者写得不够明确，就补上或者改掉。反过来，如果某条规则加了之后从来没起过作用，说明它要么是多余的，要么是写法有问题，可以考虑删掉。

这个迭代过程不需要很频繁，但一定要有。我现在的规则集跟第一版相比，内容已经换了七成以上，每一条都是被实际问题"逼"出来的。

5. 从零开始配置一套属于你的规则

5.1 先收集素材：从最近的返工记录里找线索

不要凭空想规则，那样想出来的规则往往不接地气。正确的起点是回顾你最近跟 workbuddy 的交互记录，找出那些让你不满意、需要返工的地方。

具体做法是，翻最近二三十条对话，把每次"它输出的东西我不能直接用，需要改"的原因记下来。比如：

• 格式不对，我要的是表格它给了列表。
• 语气太正式，我要的是口语化。
• 结尾又加了一段总结，我每次都删。
• 反问太多，我每次都要再回一轮。

把这些原因归类，你会发现它们高度集中在几个方面：格式、语气、结构、交互方式。每一类原因，就对应一条或几条规则。这样设计出来的规则，每一条都有明确的"解决什么问题"的背景，不会写成空话。

5.2 用"场景-行为-标准"三段式写规则

我总结了一个写规则的模板，叫"场景-行为-标准"三段式：

• 场景：这条规则在什么情况下生效。
• 行为：模型应该做什么，或者不做什么。
• 标准：做到什么程度算达标。

举个例子："在输出任何文档类内容时（场景），标题必须带数字编号，层级用 ## 和 ###（行为），编号格式为'1.''1.1'（标准）。"

这个模板的好处是，它强迫你把规则写具体。很多人写规则只写了"行为"，没写"场景"和"标准"，结果规则要么适用范围不清，要么达标标准模糊。三段式写下来，规则的可执行性会高很多。

5.3 分批上线，每次只加三到五条

不要一次性把规则集配满。我的建议是分批上线，每次加三到五条，用一周左右的时间观察效果。

这样做有两个好处。第一，如果新加的规则有问题，你能很快定位到是哪几条引起的，而不是在一大堆规则里排查。第二，分批上线能让你更清楚地感受到每条规则带来的变化，从而判断它是否值得保留。

我自己的规则集就是分四批加上去的：第一批是格式类，第二批是风格类，第三批是任务执行类，第四批是领域知识类。每批之间隔了大概一周，中间根据实际效果做了不少调整。

5.4 建立自己的"规则体检"清单

规则集稳定之后，建议建一个简单的体检清单，定期过一遍。我的清单是这样的：

这个清单我大概每个月过一遍，每次都能发现一两条可以优化的地方。规则集不是越复杂越好，而是越精准越好。

6. 几个真实场景下的规则效果对比

6.1 场景一：批量改写文案

没有规则的时候，我让它改写一段产品文案，它会输出一段改好的文字，然后在后面加一段"改写说明"，解释它做了哪些改动。这个说明我从来不看，每次都要手动删掉。

加了"不要输出改写说明，直接给结果"这条规则之后，输出干净了很多。但后来又发现新问题：它改写的时候会自作主张调整原文的结构，把一些我特意保留的短句合并成长句。于是又加了一条"改写时保持原文的段落结构和句子数量，只调整用词和语气"。

现在这个场景下，我基本是贴进去、拿结果、直接用，中间不需要任何手动处理。这就是规则的价值——把重复的判断变成一次性的配置。

6.2 场景二：整理会议纪要

会议纪要这个场景对格式要求特别高。我需要的是一份结构固定的文档：参会人、议题、结论、待办事项，每项待办要带负责人和截止时间。

最开始我每次都要在对话里把格式要求写一遍，后来把它固化成了规则："整理会议纪要时，固定输出四个部分：参会人员、讨论议题、达成结论、待办事项。待办事项用表格呈现，包含事项、负责人、截止时间三列。"

现在我只把会议记录贴进去，说一句"整理成纪要"，出来的就是我要的格式。这里的关键是把"输出结构"写死，模型不需要再自己设计结构，直接填内容就行。

6.3 场景三：技术方案评审

这个场景比较特殊，因为它需要模型"挑毛病"而不是"写东西"。默认状态下，你让它评审一个方案，它会先夸一遍，然后提几个不痛不痒的建议。

我加的规则是："评审技术方案时，直接列出问题和风险，不要写肯定性评价。每个问题要说明影响和修改建议。如果方案没有明显问题，直接说'未发现明显问题'，不要为了凑数编问题。"

这条规则的效果非常明显。现在它给出的评审意见都是实打实的问题，而且每条都带修改建议，我拿去跟团队讨论直接能用。这里体现的原则是：规则不仅要告诉模型"做什么"，还要告诉它"不要做什么"，尤其是那些模型默认会做但你不想要的行为。

7. 关于规则集维护的一些个人体会

规则集这个东西，本质上是你和模型之间的一份"协作契约"。它不需要很完美，但需要很诚实——每一条都应该是从实际问题里长出来的，而不是从"理论上应该这样"推出来的。

我现在这套规则跑了几个月，最大的感受是：好的规则集是"感觉不到它的存在"的。你不会在每次对话时想起"哦对了我设了这条规则"，而是拿到输出直接用，用完了也不会觉得哪里特别。它就像一副合适的眼镜，戴上之后你不会时刻意识到自己戴着眼镜，但摘下来就会发现哪哪都不对。

另外一个体会是，规则集要跟着你的工作走。我前段时间开始做一些偏创意的内容，发现原来的规则集太"工程化"了，输出的东西干巴巴的。于是单独加了一组"创意类任务"的规则，允许它用更活泼的表达、更多的比喻、更松的结构。这说明规则集不是一套打天下，而是可以按任务类型分组的——如果你的平台支持多套自定义指令，按场景分开配置会比揉在一起效果好得多。

最后说一个很实际的技巧：把你最满意的一次输出保存下来，作为"黄金样本"。当你觉得模型最近输出质量下降时，把黄金样本贴进去，让它对照着这个风格来。这比任何抽象的规则都管用，因为模型对具体例子的理解，永远比对你的文字描述的理解更准确。规则集负责划定边界，黄金样本负责锚定水准，两者配合起来，才是完整的"调教"方案。