workbuddy自定义指令设计指南：从Prompt到智能体规则的分层配置与容错策略

1. 为什么我要给 workbuddy 立规矩

workbuddy 这类智能体工具刚上手的时候，很多人第一反应是“这不就是个聊天框吗，问一句答一句”。我一开始也这么想，直到连续用了两周，发现同一个任务每次输出格式都不一样，今天给我列个表，明天给我写段散文，后天干脆把关键字段漏了。问题不在模型能力，而在于我从来没告诉它“我要什么形状的结果”。

自定义指令这个东西，本质上就是给智能体立一份“岗位说明书”。它不是简单的提示词堆砌，而是一套约束系统：告诉它你是谁、你在什么场景下工作、输出必须满足什么结构、遇到不确定的情况该怎么处理。我把它理解成给一个新员工写 SOP——你不写，他就按自己的理解干；你写清楚了，他比你还稳。

这篇文章适合三类人看：一是刚接触 workbuddy、还在“随便问问”阶段的新手；二是已经用过一段时间、但输出质量忽高忽低的中级用户；三是想把智能体接入实际工作流、需要稳定产出的团队使用者。我会从设计思路讲到具体配置，再到踩过的坑和排查方法，尽量把每一步背后的“为什么”说清楚，让你看完能直接抄作业，也能理解为什么这么抄。

核心关键词就几个：workbuddy、自定义指令、Prompt、智能体、规则。这几个词贯穿全文，你会在每个章节里看到它们怎么配合。

2. 自定义指令的整体设计思路拆解

2.1 先搞清楚：自定义指令到底管什么

很多人把自定义指令和单次 Prompt 混为一谈。单次 Prompt 是“这一句话你帮我干什么”，自定义指令是“你以后一直按这个规矩干活”。前者是临时任务，后者是长期契约。

workbuddy 的自定义指令通常包含几个层面：角色设定、任务边界、输出格式、容错策略、语气风格。这五块缺一不可。只写角色不写格式，输出会飘；只写格式不写容错，遇到边界情况它会瞎编；只写容错不写语气，读起来像机器翻译。

我自己的做法是把它当成一份“配置文档”来写，而不是一段“描述”。配置文档的特点是：可枚举、可验证、可迭代。每一条规则都要能回答“如果违反这条，我怎么发现”。比如“输出必须包含三个小节”，这就是可验证的；而“输出要专业一点”，这就是不可验证的，等于没写。

2.2 为什么规则要分层，而不是一锅炖

我见过不少人把自定义指令写成一大段话，几百字不分段。这种写法的问题在于：模型在解析时没有优先级，遇到冲突规则会随机选一个执行。比如你同时写了“尽量简洁”和“覆盖所有细节”，它到底听哪个？

分层的好处是建立优先级。我的分层逻辑是这样的：

• 第一层：身份与场景。你是谁，你在什么环境下工作，服务对象是谁。这一层决定语气和知识范围。
• 第二层：硬性约束。绝对不能做什么，必须包含什么。这一层是红线，优先级最高。
• 第三层：输出结构。用什么格式、分几段、每段多长、要不要表格。
• 第四层：软性偏好。语气、举例风格、详略程度。这一层可以在不违反前三层的前提下灵活调整。
• 第五层：异常处理。信息不足时怎么办、遇到不确定内容怎么标注、超出能力范围怎么回复。

这样分层之后，模型在生成时会有明确的优先级判断。实测下来，输出稳定性提升非常明显，同一类任务连续跑二十次，结构一致率能从原来的六成左右提到九成以上。

2.3 规则写多细才合适：一个平衡点

规则太粗，输出不可控；规则太细，模型没有发挥空间，遇到稍微变化的任务就卡死。我摸索出来的平衡点是：结构写死，内容留活。

举个例子。如果你做的是销售智能体，不要写“每次必须推荐三款产品”，而要写“每次推荐产品时，必须包含产品名、适用场景、核心优势三个字段，数量根据用户需求决定”。前者把数量写死了，用户只问一款的时候模型会硬凑三款；后者把字段写死了，数量留给模型判断。

再比如格式。你可以规定“必须用 Markdown 表格呈现对比信息”，但不要规定“表格必须有五列”。列数应该由内容决定，而不是由规则决定。这个度需要试几次才能找到，但原则是：规则管的是“不能少什么”，而不是“必须多什么”。

2.4 和平台自带能力的配合关系

workbuddy 本身有一些内置能力，比如上下文记忆、工具调用、多轮对话管理。自定义指令不是替代这些，而是给它们加约束。我见过有人试图用自定义指令去实现本该由工具调用完成的事情，结果就是规则越写越长，效果越来越差。

正确的做法是：能用平台能力解决的，不要写进指令。比如需要查实时数据，就用工具调用；需要记住用户偏好，就用记忆功能。自定义指令只负责“怎么表达”和“怎么判断”，不负责“怎么获取”。这个边界划清楚，指令能短一半，效果反而更好。

3. 核心细节解析与实操要点

3.1 角色设定的写法：具体比华丽重要

角色设定最容易犯的错是写得太虚。“你是一个专业的助手”——这句话等于没说。什么叫专业？哪个领域的专业？对谁专业？

我的写法是三层定位：领域 + 经验年限 + 服务对象。比如：

你是一名有八年经验的企业级软件售前顾问，服务对象是中小企业的技术负责人，他们关心的是落地成本和维护难度，不是技术先进性。

这句话里，“八年经验”给了模型一个知识深度锚点，“中小企业技术负责人”给了它一个受众画像，“关心落地成本”给了它一个判断标准。三句话下来，模型在回答时自动会往“务实、算账、讲维护”的方向走。

还有一个技巧：用否定句补充边界。比如“你不是一个只会说好话的销售，遇到明显不合适的方案要直接指出问题”。这种否定句能有效抑制模型的“讨好倾向”，让输出更可信。

3.2 输出格式的硬约束：让结果可预期

格式约束是自定义指令里最立竿见影的部分。我通常从四个维度去写：

这里有个细节：长度约束要写“上限”而不是“下限”。写“不少于 200 字”会逼模型凑字数，写“不超过 200 字”会逼它精简。实测下来，上限约束的输出质量明显更高。

另外，如果你需要表格，一定要在指令里给出表头示例。比如“对比类信息用表格呈现，表头固定为：方案名、适用场景、成本区间、风险点”。给了表头，模型就不会自己发明列名，后续你做数据提取会方便很多。

3.3 容错策略：让智能体学会说“不知道”

这是最多人忽略、但最重要的一块。智能体最危险的行为不是答错，而是自信地编造。自定义指令里必须明确写清楚：信息不足时怎么办。

我的容错规则通常包含三条：

1. 信息不足时，先问再答。如果用户问题缺少关键参数，不要猜测，直接列出需要补充的信息。
2. 不确定的内容必须标注。用“据我了解”“这一点需要你核实”这类前缀，而不是直接陈述。
3. 超出范围时明确拒绝。不要硬答，直接说“这个问题超出我的知识范围，建议你咨询 XX”。

这三条写进去之后，输出的可信度会大幅提升。我做过对比，加了容错规则的版本，在事实性错误上的发生率明显下降，因为模型不再被迫“必须给出答案”。

3.4 语气与风格的软性控制

语气这块，我的建议是用场景描述代替形容词。不要写“语气要友好”，而要写“像同事之间讨论方案那样，直接、平等、不客套”。不要写“要专业”，而要写“用行业术语，但第一次出现时用一句话解释”。

还有一个实用技巧：给一个反面示例。比如“不要写成‘亲爱的用户，感谢您的提问’这种客服腔”。模型对反面示例的敏感度很高，给一个它就能避开一类。

3.5 指令的版本管理：别改完就忘

自定义指令是需要迭代的。我建议每次修改都留一个版本记录，写清楚改了什么、为什么改、改完效果如何。我自己的习惯是用一个简单的表格维护：

这个习惯看起来麻烦，但当你用了三个月、改了十几版之后，没有记录你根本不知道哪条规则是有效的、哪条是多余的。

4. 实操过程与核心环节实现

4.1 从零开始搭建一套自定义指令

下面是我实际使用的一套配置流程，以“技术方案评审助手”为例，你可以直接套用到自己的场景。

第一步：明确任务类型。先问自己：这个智能体主要处理哪类任务？是信息查询、内容生成、方案对比，还是流程引导？不同类型对规则的要求不一样。方案评审属于“分析判断类”，重点是逻辑结构和判断标准。

第二步：写身份层。我写的是：

你是一名资深技术架构评审员，有十年以上系统设计经验，服务对象是正在做技术选型的研发团队。你的判断标准是：可维护性优先于性能，落地成本优先于技术先进性。

第三步：写硬约束。这部分用列表写，每条独立成行：

• 每次评审必须给出明确结论，不能模棱两可
• 必须指出至少一个潜在风险
• 不确定的信息必须标注“需核实”
• 不使用“可能”“也许”等模糊词开头

第四步：写输出结构。我固定为四段：

1. 结论（一句话）
2. 依据（分点，每点不超过两行）
3. 风险（分点，标注严重程度）
4. 建议（可操作的具体动作）

第五步：写容错规则。三条：

• 信息不足时，列出需要补充的字段，不猜测
• 超出技术范围时，直接说明并建议咨询方向
• 遇到矛盾信息时，指出矛盾点，不强行统一

第六步：写语气偏好。一句话：

语气像技术评审会上的发言，直接、有依据、不绕弯子，不用客套话。

这套配置写下来大概四百字左右，不算长，但覆盖了所有关键维度。实测跑了一个月，输出结构一致率很高，而且因为容错规则的存在，很少出现编造情况。

4.2 参数与规则的优先级设置

workbuddy 的自定义指令通常支持一定程度的优先级标记。如果没有显式优先级，就靠书写顺序来隐含。我的做法是：越靠前的规则优先级越高。

具体排列顺序是：硬约束 > 输出结构 > 容错规则 > 身份设定 > 语气偏好。为什么把硬约束放最前面？因为它是红线，任何时候都不能违反。身份设定放后面是因为它更多影响“风格”而不是“正确性”。

如果你用的平台支持权重参数，可以给硬约束设高权重，给语气设低权重。但大多数情况下，书写顺序就够了。关键是不要把语气规则写在硬约束前面，否则模型会优先满足语气而牺牲约束。

4.3 实测记录：一次完整的指令迭代

我拿一个实际案例来说明迭代过程。最初的需求是“帮我整理会议纪要”，第一版指令写得很简单：

你是一个会议纪要助手，把用户提供的内容整理成纪要。

结果输出很飘，有时候分点，有时候成段，有时候漏掉行动项。第二版我加了结构约束：

输出必须包含：会议主题、参会人、讨论要点、行动项四个部分。行动项必须包含负责人和时间节点。

这一版结构稳定了，但出现新问题：用户没提供负责人时，模型会编一个名字。第三版我加了容错：

如果行动项缺少负责人或时间节点，标注“待确认”，不要编造。

这一版之后，输出基本可用了。整个过程改了三次，每次都是发现一个具体问题、加一条具体规则。这就是我说的“可验证”原则——每条规则都是为了解决一个实际观察到的问题，而不是凭空想象。

4.4 和其他功能的配合配置

自定义指令不是孤立的。如果你同时用了 workbuddy 的记忆功能，要注意指令和记忆的边界。我的做法是：指令管规则，记忆管偏好。

比如“输出用表格”是规则，写进指令；“用户喜欢简洁风格”是偏好，交给记忆。这样指令保持稳定，记忆可以动态更新。如果两者冲突，以指令为准，因为指令是硬约束。

另外，如果你用了工具调用，要在指令里写清楚“什么时候调用工具”。比如“需要实时数据时调用搜索工具，不要凭记忆回答”。这句话能有效减少模型“假装知道”的情况。

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

5.1 指令写了但没生效，怎么排查

这是最常见的问题。排查顺序我总结成一张表：

我遇到最多的是“规则冲突”。比如同时写了“尽量详细”和“不超过 100 字”，模型就会随机选一个执行。解决办法是删掉软性描述，只留硬性约束。

5.2 输出格式不稳定的三种典型情况

第一种：表格变列表。原因通常是没有给表头示例。加上“表头固定为 XX”之后基本能解决。

第二种：分点变段落。原因是没有明确“必须用有序列表”。把“分点说明”改成“用 1. 2. 3. 的有序列表呈现”，稳定性会好很多。

第三种：长度忽长忽短。原因是只写了内容要求没写长度上限。加上“每点不超过两行”这类约束就能控制住。

5.3 遇到“invalid prompt”提示怎么处理

有时候保存指令会提示“invalid prompt: your prompt was flagged as potentially violating our usage p”这类信息。这通常是因为指令里包含了某些被平台判定为不合适的表述。排查方向：

• 检查是否有涉及具体个人信息的描述
• 检查是否有绝对化、指令性过强的表述
• 检查是否有平台明确禁止的内容类型

处理办法是换一种表达方式。比如把“你必须无条件执行”改成“请按照以下规则处理”，把具体人名改成角色描述。大多数情况下，调整措辞就能通过。

5.4 指令越写越长，效果反而变差

这是个典型误区。指令长度和效果不是正相关。我的经验是：超过八百字的指令，边际收益急剧下降。原因是模型在解析长指令时，注意力会分散，后面的规则可能覆盖前面的。

解决办法是做减法。把可以合并的规则合并，把可以由平台能力替代的删掉，把软性描述全部删除。我自己的指令从最初的一千多字精简到四百字左右，效果反而更好。

5.5 不同任务共用一套指令的取舍

有人想用一套指令搞定所有任务，这基本不现实。我的做法是按任务类型分几套基础指令，共用一套容错规则。

比如“分析类”“生成类”“查询类”各一套，但容错规则三条在所有指令里都一样。这样既保证了针对性，又减少了维护成本。如果你用的平台支持指令模板，可以把容错规则做成公共模块，每套指令引用它。

5.6 独家避坑技巧汇总

最后分享几个我踩过坑之后总结的技巧：

• 先写容错，再写功能。很多人反过来，结果功能写得很漂亮，一遇到边界就崩。
• 用反面示例代替正面描述。“不要写成客服腔”比“语气要自然”有效得多。
• 每次只改一条规则。一次改多条，出问题不知道是哪条导致的。
• 保留旧版本。新版本效果不好时能快速回滚。
• 定期清理无效规则。用了两周没触发过的规则，大概率是多余的。

6. 我个人的使用体会

这套自定义指令我用了大概三个月，最大的感受是：智能体的可靠性不取决于模型多强，而取决于你给它划的边界多清楚。同样的 workbuddy，别人用起来觉得“也就那样”，我用起来觉得“比我自己还靠谱”，差别就在这份规矩上。

还有一点体会是，写指令的过程其实是在梳理自己的需求。很多时候你觉得模型输出不好，其实是你自己没想清楚要什么。把规则写下来的过程，就是逼自己想清楚的过程。所以我现在每次开新任务，第一件事不是写 Prompt，而是先写指令框架，把结构、边界、容错都想明白，再动手。

如果你刚开始用，建议从一套最简单的四段式指令开始：身份、结构、容错、语气。跑一周，记录问题，再迭代。不用追求一次写完美，规则是长出来的，不是设计出来的。