给 WorkBuddy 喂上下文的四种方式，样例是性价比最高的那个

很多人对 AI 输出不满意，第一反应是「指令写得不够细」，于是把要求写得越来越长。

但真正的问题往往不是要求不够细，是上下文不够。

官方在使用技巧里给了几种给上下文的方式，其中一条说得特别直接：

给它看例子：一个好的参考样本胜过十行抽象要求，样本是明确的锚点。

这篇把四种方式并列，说清楚各自适合什么。

本文依据 WorkBuddy 官方文档《高效使用技巧》与权限模式文档，核对日 2026-08-16。我们没有安装客户端，本文不含实测数据。

一、方式一：给文件（最基础，也最常被漏）

官方的三要素公式里，「有什么」这一项说的就是它——输入在哪。

对照官方给的正反示范就很清楚：

• ❌ 「帮我把上次的会议纪要整理一下」——没有输入；
• ✅ 「把 D:/会议纪要/0320产品评审.docx 里的会议纪要整理成…」——完整路径 + 完整文件名。

给文件时的三个要点：

• 完整路径，别用「桌面上那个」。官方 FAQ 里还有一条相关说明——移动端要求上传桌面文件时提示无法完成，官方建议改为在本机侧明确指定文件路径后再执行；
• 说明这份数据的关键部分：「表格里第 3 列是成交额，D 列有空值」——省掉它自己摸索；
• 把文件复制进任务目录。官方原话：处理重要文件之前，先建独立的任务文件夹，把需要的文件复制进去，而不是把原始目录直接交出去。

二、方式二：给样例（★ 性价比最高）

官方那句「一个好的参考样本胜过十行抽象要求」值得单独强调，因为它解决的是最难说清的那类要求——风格、格式、语气、结构。

对比一下：

❌ 写得专业一点，格式规范一些，语气正式但别太生硬
✅ 参照 2026Q2月报.docx 的结构和语气来写这一份

第一句里每个形容词都是主观的；第二句是客观的。

什么时候用：

情况	给样例的价值
公司有固定文档模板	极高——直接说「照这份的格式」
你上次做过一份满意的	极高
要求涉及风格、语气、排版	极高——这类最难用文字说清
纯数据统计类任务	中——格式给样例，口径还是要写清楚
全新的、你自己也没做过的	低——没样例可给

一条实用原则：只要你手上有一份满意的成品，就别再用形容词描述需求。

给样例的操作：把那份文件放进当前任务的工作空间，指令里点名文件名。

三、方式三：给身份

官方在使用技巧里的另一条：

给它一个身份：用「专家」预设角色（法律顾问、产品经理、数据分析师、营销文案等），相当于预设一层角色提示，让表达框架、关注重点和专业术语更快对齐。

这条对应的是官方的专家中心——官方对专家的描述是「每位专家都拥有独立的人设、方法论和工具链」。

什么时候值得用：

• 任务有明确的专业属性（法务条款、数据分析、营销文案）；
• 你希望它按某个岗位的思路组织内容，而不是通用写法。

成本提醒：官方在召唤专家团时明确提示——专家团可能会调用多位专家协同执行，积分消耗通常为单个专家的数倍。所以顺序应该是：直接对话 → 启用对应 Skill → 召唤单个专家 → 才是专家团。

还有个配套用法：官方技巧里另有一条切换角色视角——做完之后让它换个身份挑毛病，比如「用采购负责人的视角看这份方案，他最关心什么、会问什么问题」。开工前给身份，做完后换视角，是配套的两招。

四、方式四：给背景（用得最多，也最容易过量）

背景就是那些「你觉得理所当然、但它不知道」的信息：

• 受众：给谁看的（客户 / 老板 / 一线同事）；
• 场景：什么场合用（周会口头讲 / 发出去的正式文档）；
• 约束来源：为什么有这个要求（合规要求不能用极限词）；
• 历史：上次是怎么做的、为什么改。

官方在「不满意就调整」那一条里给的四个补充方向正是这类：受众、场景、格式、篇幅。

「受众」和「场景」是最常被漏、影响又最大的两个——同一份产品说明，给工程师看和给采购看，写法完全不同。你不说，它只能按最通用的方式写，结果两边都不太合适。

五、★ 给多了反而变差的情况

上下文不是越多越好。三种情况要收着给：

一、无关的文件。 把整个项目目录交出去，里面二十份文档只有三份相关——它得先判断哪些有用，判断错了结果就偏。只放相关的副本。

二、互相矛盾的样例。 给了三份风格完全不同的参考，它不知道该照哪份。给一份，或者明确说「主要参照 A，B 只看数据口径」。

三、堆积的对话历史。 这是最隐蔽的一种。官方对此有明确建议：

会话过长出现「前说后忘」「越聊越跑偏」时，不要硬撑——直接开新任务，把关键背景重新简洁说一遍。

很多人舍不得开新会话，觉得「上下文都在这儿」。但上下文太长本身就是跑偏的原因。

开新会话的技巧：把当前最接近的那一版当作样例带过去——绕了几轮之后，你对自己要什么的认识已经清楚多了，一次说全比继续打补丁快。

六、一个决策顺序

不知道该给什么的时候，按这个顺序：

1. 输入文件在哪？          → 必给，完整路径
2. 有没有满意的成品可参照？ → 有就给样例（性价比最高）
3. 这活有明确的专业属性吗？ → 有就给身份
4. 受众和场景是什么？       → 说清楚（最常被漏）
5. 还有别的背景吗？         → 只给相关的，别堆

第 2 步值得每次都问一遍——很多人手上有现成的好样例，却还在用形容词描述需求。

七、还有一个万能兜底

官方给的新手小贴士，不知道该给什么的时候直接问：

我想做 XX，你需要我提供哪些信息？

让它先梳理输入项，你照着补。 这比憋着写一段自以为完整的指令高效——你不知道你漏了什么，它知道它缺什么。

小结

• 输出不满意，问题往往不是「要求不够细」，是上下文不够。
• 四种方式：给文件（完整路径 + 说明关键部分 + 放副本）、给样例、给身份、给背景（受众/场景/约束来源/历史）。
• ★ 样例是性价比最高的——官方原话：一个好的参考样本胜过十行抽象要求。只要手上有满意的成品，就别再用形容词描述需求。
• 给身份对应官方的专家能力（人设 + 方法论 + 工具链）；配套用法是做完后切换角色视角挑毛病。成本上从便宜的档位开始试——专家团积分是单专家的数倍。
• 受众和场景是最常被漏、影响又最大的两项背景。
• ★ 三种情况给多了反而变差：无关文件、互相矛盾的样例、堆积的对话历史（官方：跑偏了不要硬撑，开新任务）。
• 决策顺序五步；不知道给什么就问「我想做 XX，你需要我提供哪些信息？」

功能与文档表述以官方为准，核对日 2026-08-16。