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 输出格式的硬约束让结果可预期格式约束是自定义指令里最立竿见影的部分。我通常从四个维度去写维度写法示例作用结构必须包含“结论、依据、建议”三个小节保证逻辑完整长度每个小节不超过 150 字防止啰嗦标记关键数据用加粗风险项用引用块提升可读性禁止项不使用比喻不写客套话去除噪音这里有个细节长度约束要写“上限”而不是“下限”。写“不少于 200 字”会逼模型凑字数写“不超过 200 字”会逼它精简。实测下来上限约束的输出质量明显更高。另外如果你需要表格一定要在指令里给出表头示例。比如“对比类信息用表格呈现表头固定为方案名、适用场景、成本区间、风险点”。给了表头模型就不会自己发明列名后续你做数据提取会方便很多。3.3 容错策略让智能体学会说“不知道”这是最多人忽略、但最重要的一块。智能体最危险的行为不是答错而是自信地编造。自定义指令里必须明确写清楚信息不足时怎么办。我的容错规则通常包含三条信息不足时先问再答。如果用户问题缺少关键参数不要猜测直接列出需要补充的信息。不确定的内容必须标注。用“据我了解”“这一点需要你核实”这类前缀而不是直接陈述。超出范围时明确拒绝。不要硬答直接说“这个问题超出我的知识范围建议你咨询 XX”。这三条写进去之后输出的可信度会大幅提升。我做过对比加了容错规则的版本在事实性错误上的发生率明显下降因为模型不再被迫“必须给出答案”。3.4 语气与风格的软性控制语气这块我的建议是用场景描述代替形容词。不要写“语气要友好”而要写“像同事之间讨论方案那样直接、平等、不客套”。不要写“要专业”而要写“用行业术语但第一次出现时用一句话解释”。还有一个实用技巧给一个反面示例。比如“不要写成‘亲爱的用户感谢您的提问’这种客服腔”。模型对反面示例的敏感度很高给一个它就能避开一类。3.5 指令的版本管理别改完就忘自定义指令是需要迭代的。我建议每次修改都留一个版本记录写清楚改了什么、为什么改、改完效果如何。我自己的习惯是用一个简单的表格维护版本修改内容修改原因效果观察v1.0初始版本建立基础规则格式稳定但语气偏硬v1.1增加语气示例输出太像机器可读性提升v1.2补充容错条款出现编造情况事实错误减少这个习惯看起来麻烦但当你用了三个月、改了十几版之后没有记录你根本不知道哪条规则是有效的、哪条是多余的。4. 实操过程与核心环节实现4.1 从零开始搭建一套自定义指令下面是我实际使用的一套配置流程以“技术方案评审助手”为例你可以直接套用到自己的场景。第一步明确任务类型。先问自己这个智能体主要处理哪类任务是信息查询、内容生成、方案对比还是流程引导不同类型对规则的要求不一样。方案评审属于“分析判断类”重点是逻辑结构和判断标准。第二步写身份层。我写的是你是一名资深技术架构评审员有十年以上系统设计经验服务对象是正在做技术选型的研发团队。你的判断标准是可维护性优先于性能落地成本优先于技术先进性。第三步写硬约束。这部分用列表写每条独立成行每次评审必须给出明确结论不能模棱两可必须指出至少一个潜在风险不确定的信息必须标注“需核实”不使用“可能”“也许”等模糊词开头第四步写输出结构。我固定为四段结论一句话依据分点每点不超过两行风险分点标注严重程度建议可操作的具体动作第五步写容错规则。三条信息不足时列出需要补充的字段不猜测超出技术范围时直接说明并建议咨询方向遇到矛盾信息时指出矛盾点不强行统一第六步写语气偏好。一句话语气像技术评审会上的发言直接、有依据、不绕弯子不用客套话。这套配置写下来大概四百字左右不算长但覆盖了所有关键维度。实测跑了一个月输出结构一致率很高而且因为容错规则的存在很少出现编造情况。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而是先写指令框架把结构、边界、容错都想明白再动手。如果你刚开始用建议从一套最简单的四段式指令开始身份、结构、容错、语气。跑一周记录问题再迭代。不用追求一次写完美规则是长出来的不是设计出来的。