腾讯客服团队亲测：学会这 4 步，让你的 AI 从“能用”到“好用”

不少 Buddy 在使用 AI 时都遇到过这些问题：

• 明明已经说清了背景和要求，生成的答案却总差点意思；

• 来回补充信息、调整提示词，它还是抓不住重点；

• 只想修改一处，其他原本没问题的内容也跟着变了；

• 面对相似的问题，AI 前后给出的结果甚至完全不同······

让 AI 生成一个答案并不难。真正难的是，让它理解我们到底要什么，并在一次次任务中稳定交付可靠的结果。

腾讯客服团队的 YOYO 也曾遇到过同样的问题。YOYO 是腾讯客服部的知识资产架构师，日常工作是把团队的知识与经验梳理、转化并沉淀为可复用资产，用 AI 帮助团队提效减负。过去，她所在的客服团队需要完成一项高度依赖人工经验的评估工作。一线提出诉求后，团队成员需要结合业务规则和过往经验作出判断，再给出相应方案。大量的关键判断掌握在少数人手中，不仅需要持续投入人力，也很难沉淀为统一、可复用的标准。

于是，他们尝试搭建了一个 AI 评估智能体。最初，智能体的评估准确率只有 50%，距离真正投入使用还有很大差距。经过五个月、101 次迭代后，评估准确率从 50% 提升到了 97%。

这一变化的实现，靠的并不是一条万能提示词，而是团队在实践中逐渐掌握的四个关键步骤——让 AI 从听懂需求开始，逐步成长为一位快速上岗且能够稳定完成工作的好帮手。

一、学会筛选：思考什么内容值得交给 AI

在个人和团队的日常工作中，大量经验分散在人的记忆、历史对话、零散文档里。要让 AI 真正参与工作，首先需要将这些经验提炼为可复用、能够直接交给 AI 执行的知识资产。

许多人的做法是把团队现有的规则、指南和历史经验一股脑塞进知识库。但问题是，这些经验当中可能既有真正影响判断的经验，也有在过去条件下形成、后来一直沿用的固定流程。如果未经筛选就将它们全部交给 AI，AI 可能只是更快地执行了一套本可简化甚至取消的流程。

因此，在沉淀经验之前，需要先做筛选，可以逐步回答以下问题：

• 这项工作真正要解决的问题是什么？

• 现有环节是否仍有存在的必要？

• 有没有更直接的解决方案？

• 哪些内容只是固定流程，哪些内容确实需要结合实际情况判断？

• 哪些经验会反复使用，值得沉淀为统一标准？

经过这一步，该优化的流程先优化，该取消的环节先取消。只有那些确实需要判断、又会被反复使用的经验，才进入后续的知识沉淀环节。

使用 AI，不是把原来的工作原封不动交给它，而是先重新确认需求，再决定 AI 应该介入哪些环节。因为 AI 可以把一件事做得更快，但它不会主动提醒你，这件事本来可以不做。

二、学会提问：让 AI 真正理解你的需求

确定要交给 AI 的任务后，下一个难点是：怎样把人的判断经验说明白？

很多人会选择直接告诉 AI：“帮我整理一份业务规则”或“帮我写一份操作指南”。AI 通常会迅速配合生成一份结构完整的文本，但这份文本未必真正包含业务判断所需要的信息，对于相关的领域几乎没有信息增量。

问题出在哪？知识沉淀最大的难点，不是不知道如何表达，而是有许多关键经验从一开始就没有被说出来：对于熟悉业务的人来说，一些判断早已成为下意识。面对具体问题时，他知道应该关注什么，也能察觉哪些情况需要例外处理；但当他尝试把这套经验写下来时，往往会自然省略自己认为“不言自明”的部分。可这些部分，你不说，AI 就永远不知道。让 AI 直接产出，只能根据有限信息进行补全，缺失的部分则容易被通用表述代替，看起来完整，但其实并不符合真实的需求。

因此，用 AI 沉淀知识，需要把顺序调转过来——不让 AI 直接开始写，而是先让它提问。

可以借鉴“苏格拉底式提问法¹”的思路，让 AI 扮演一个不了解业务、但会持续追问的采访者。告诉 AI：不需要急着给出答案，而是先围绕任务目标、判断条件、规则优先级、特殊情况等信息不断提问，将使用者原本没有说出口的信息逐步挖出来。

这种方式能解决一个常见的问题：越熟悉一项工作，越难还原自己尚未掌握它时的状态，越会不自觉地省略最需要的信息——“这种情况看着办”是什么情况？怎么看？“实在不行就上报”是什么情况才算实在不行？与其一个人面对空白文档反复回忆，不如让 AI 学会反问。许多原本依赖直觉完成的判断，也会在问答过程中逐渐变得明确。

当经验从“某个人知道怎么做”变成清楚的条件、边界和例外，它才真正具备被团队复用、被系统执行的基础。

具体怎么让 AI 进入“提问模式”？可以把下面这段话直接发给 WorkBuddy：

【提示词 1：苏格拉底式采访】

我是 [你的角色，如：客服]，正在做 [具体业务/项目]。

我想把 [某项判断经验，如：xxxx] 沉淀成 [新人/系统] 能照着独立执行的知识。

接下来请你用苏格拉底式提问来采访我，把这条经验挖清楚。规则：

1. 你只提问，我来答，不要替我下结论，也不要急着帮我总结

2. 每次只问一个问题，问完等我回答

3. 我的回答一旦含糊（比如“看情况”“一般来说”“有经验就知道”），你要顺着往下追问，直到把背后的具体条件问出来

4. 一直问到：换个完全不懂的人，照着也能做出同样判断为止

5. 你判断已经问清楚了，就停下来告诉我“可以整理了”，再把这条经验整理成一份结构化草稿：什么情况、判断依据、对应结论

现在开始，先问我第一个问题

三、学会管理：明确 AI 的操作权限

知识框架的搭建只是开始。随着业务变化，判据、阈值和输出话术需要更新，知识库会在一次次使用中持续变化，而真正容易被忽略的风险，往往发生在修改过程中。

需要注意的是，知识库不是一组彼此独立的文档，而是一张相互关联的规则网。修改其中一条规则，可能影响其他判断。AI 在执行修改时，也可能根据自己的理解“顺手优化”相关内容。而这些额外改动不一定会被明确标出。使用者能够看到要求修改的地方是否正确，却很难发现其他内容是否同时发生了变化，且知识库越大，这类问题越难排查。

因此，校验工作需要提前进行：不是等 AI 改完以后再检查，而是在修改发生之前，先明确 AI 有哪些操作权限。具体而言，需要建立三条规则。

1. 先列出清单，再执行修改

收到修改任务后，AI 不能立即写入，而要先列出完整的改动清单：

• 准备修改哪个文件、哪一部分；

• 对应的原文是什么；

• 计划修改成什么；

• 为什么需要修改。

使用者逐条检查并确认后，AI 才能开始执行。没有经过确认的改动，不进入知识库。

2. 只修改确认过的内容

改动范围一旦确认，清单之外的内容一律不动。即使 AI 在分析过程中发现了“似乎可以顺手优化”的内容，也不能擅自修改。

该改的内容没有改到，是执行问题；没有要求修改的内容被改动，则可能引入更难发现的新问题。

3. 遇到冲突先停止

如果修改规则 A 会影响规则 B，AI 不应该自行决定如何取舍，而要先停下来，向使用者说明：冲突发生在哪里、属于什么问题、可能影响哪些判断，再等待使用者决定。

AI 可以识别冲突、分析影响和提出方案，但最终选择仍然由人作出。否则，它就不再只是执行已经确认的决定，而是在替使用者作出新的业务判断。

可以把以下提示词复制到 WorkBuddy，明确修改规范：

【提示词 2：全局同步修改协议】

在着手修改任何文档（无论单个还是多个）之前，你必须严格遵循以下全局同步修改协议：

1. 全域预检（Global Pre-check）

在应用任何改动前，你必须先对所有涉及的目标文档进行扫描分析：

逻辑一致性：你计划修改的内容，是否与所有相关文档中的现有逻辑、既定规则或事实陈述存在冲突？

可读性影响：此次修改是否会导致单文档内部、或多文档之间的逻辑链条断裂、语义模糊或产生新的歧义？

2. 最小必要与聚焦原则

只纠误不改对：仅修正已被确认为错误、不准确或自相矛盾的内容。严禁对已正确无误的部分进行任何形式的“润色”、“优化”或风格统一（除非该风格本身导致了歧义）。

关联聚焦：修改范围必须严格限定于与当前修正目标具有直接逻辑关联的内容。不得触达无关章节或无关文档。

3. 跨文档冲突熔断机制

如果在预检中发现以下情况：执行当前修改会破坏其他文档（或本文档其他部分）的逻辑自洽性，你必须立即执行熔断程序：

停止修改：暂停当前的单点修改计划。

全景报告：向我明确汇报：

冲突点的具体位置（文件名+段落）；

冲突的性质（例如：定义不一致、数据矛盾、因果倒置）；

连锁反应评估（修改 A 会影响 B，进而导致 C 失效）。

你的解决方案：提出一个能一次性解决所有关联冲突的整体性调整方案。

等待授权：获得我的明确批准前，严禁写入任何内容。

4. 原子化提交

经授权后，你必须确保所有相关文档的修改在同一轮回复中完成，以确保逻辑的一致性不被后续的上下文遗忘所破坏。

还有一种情况需要单独处理：同一个问题已经修改了三四轮，却仍然没有解决，甚至越改越乱。这时，与其继续增加要求，不如先暂停修改，让 AI 回顾整条任务链路，找出卡点到底在哪里：是指令有歧义，还是任务本身存在冲突。

只有先找到反复失败的原因，后续修改才不会继续建立在错误的方向上。

遇到这种情况时，可以直接复制下面这段协议，每次让 WorkBuddy 更改知识库前发送：

【提示词 3：任务深度复盘协议】

启动“任务深度复盘协议”。请基于我们本次任务的全部对话历史，执行以下动作：

全链路梳理：按时间线完整还原任务执行的每一步，厘清最初的意图与最终的产出。

可行性重估：结合执行过程中的实际阻力，重新审视该任务目标在当前条件下的可行性（技术限制、逻辑矛盾、资源缺失等）。

根因分析（RCA）：

重点分析中途失败的具体节点。

区分“技术执行失误”与“任务逻辑设计缺陷”。

深挖导致失败的底层原因（例如：Prompt 歧义、上下文窗口限制、逻辑推理链断裂、或是我的指令本身存在悖论）。

流程诊断：指出我在任务推进过程中，哪些提问方式、干预手段或反馈机制是不合理的，导致了效率低下或方向偏离。

记忆固化与防错：将复盘得出的关键教训、禁忌点和优化策略，整理成结构化的“执行备忘录”。下次我启动同类任务时，请你主动调取这份记忆，并在第一步进行风险评估，确保同类错误不再发生。

四、学会归因：先找到错误源头，再优化提示词

完成知识沉淀后的下一步，是要让 AI 进入真实任务稳定执行，再根据真实的错误案例一步步校准。

五个月、101 次迭代，智能体的评估准确率从 50% 提升到 97%，YOYO 团队并没有反复润色整篇提示词，而是固定执行一套迭代闭环：建立基线 → 定位错误 → 最小修改 → 全量回归 → 留下记录。

准确率提升的关键在于，每一轮都解决一个能够被明确说明的问题。

例如，同样是判断错误，背后的原因可能完全不同。YOYO 团队将原因归纳为五类：

• 知识没有写清楚：关键条件缺失或表述仍然含糊，需要回到知识库补充；

• 规则顺序不清楚：多条规则同时命中，但没有说明哪一条优先，需要调整判断顺序；

• 输入信息不足：现有信息不足以支持结论，需要增加“信息不足”的退出条件；

• 输出没有遵守要求：判断本身正确，但格式、字数或话术不符合要求，需要收紧输出约束；

• 模型出现幻觉或不稳定：AI 添加了没有依据的信息，或在相似输入下给出不一致的判断。

这一步不能跳过。如果没有先判断问题发生在哪一层，就直接修改提示词，很容易把知识问题写成提示词补丁。提示词会越来越长，真正缺失的判断条件却仍然没有被补上。

可以直接复制下面这套指令，基于错误案例的实际情况，修改表述后发给 WorkBuddy：

【提示词 4：错误归因优化指令】

基于本轮的错误案例做归因。本回合只归因，禁止改动任何文件。

【错误案例】

输入：{{粘贴当时的输入}}

实际输出：{{粘贴错误的输出}}

期望输出：{{粘贴正确的结果}}

AI 给出的判断依据或可见分析过程（如有）：{{粘贴相关内容}}

执行顺序：

第一步：定位到具体哪一句

读取当前提示词与大模型的思考内容文件，指出是哪一句导致了这个结果，引用原句，不要只说小节名。

第二步：归因，只能取一类

A1 表述缺失：判断条件在知识库里有，但提示词用了没有定义的抽象词 （极端、严重、明显、较大、比较多等），模型无法对照执行

A2 知识缺失：这个判断条件在知识库里根本不存在

B 顺序不清：两条规则同时命中，但没说明谁优先

C 输入不足：现有输入信息支撑不了这个结论

D 输出违规：结论是对的，但格式、字数或措辞不符合要求

E 大模型思考存在幻觉

同时命中多类时，只取占比最大的一类。

归因为 A1 时有一条硬性要求：

必须同时引用知识库里对应的那条判断条件，证明它确实存在。

引用不出来，就说明这是 A2 而不是 A1，请改判。

第三步：判断该不该改提示词

以下情况直接说明并停止，不要为了完成任务而硬改：

- 归因为 A2：应该先补知识库条目，补完再回来走这个流程

- 案例输入本身自相矛盾，或缺少判断所需的关键信息

- 期望输出本身是错的（这种情况该改测试案例，不是改提示词）

- 这个判断超出提示词能解决的范围，应该改输入采集规范或任务边界

第四步：只有确认该改，才给出修改方案

方案里必须包含：改哪一句、改成什么、这一改如何让本案例走到正确结论。

四步做完就停，等我确认后再动手。

找到错误原因后，AI 通常会顺势提出一套解决方案。但这些建议不能直接全部写入。要让 AI 先把三件事说清楚：

• 要改什么：明确修改所涉及的文件、章节和具体语句，引用原文，并给出完整的修改版本。类似“优化判断条件”这样的概括性建议不能算作建议，因为并没有说明实际改动范围，也不足以支持使用者作出是否批准的判断。

• 为什么要改：每一项改动都要对应本轮归因中已经确认的具体问题，并说明二者之间的关系。如果某项建议无法对应明确错因，说明它不属于本轮修改范围，应当单独记录，不能与当前改动一并执行。否则，即使结果发生变化，也无法确认究竟是哪一项调整产生了作用。

• 改动之间是否存在冲突：AI 需要在执行前检查各项修改是否相互影响。例如，一条建议调整了判断顺序，另一条建议又增加了新规则，这可能形成矛盾。这类问题应该在改动生效前识别并说明，避免执行后再度返工。

随后，AI 需要将所有建议整理成清单，由使用者逐条确认。注意是“逐条确认”，而不是整体批准。整体批准只有接受或拒绝两个选项；逐条确认则可以保留必要改动，拒绝与本轮问题无关的调整。

可以直接把这段话发给 WorkBuddy：

【提示词 5：提示词优化与修改确认指令】

你已经找到问题的根源，现在不要开始修改。

先把修改方案按以下格式列出来，等我逐条确认后再动手。

第一部分：要改什么——逐条列出，一条一个编号

每条必须写清四项，缺任何一项这条视为无效：

1) 编号

2) 修改位置：文件名 + 小节名 + 原句（把原文引出来，不要只说“某处”）

3) 改为：修改后的完整内容，不要写“类似地调整”这种模糊描述

4) 预期效果：改完之后，原本出错的那个案例会怎么走到正确结论

第二部分：每一条为什么改——与第一部分逐条对应

对第一部分的每个编号，说明这条改动解决的是刚才归因出的哪一个具体问题。

要求一对一指明，不许用「整体优化判断逻辑」这类笼统说法。

如果某条改动你说不出对应的具体问题，说明它不在本轮范围内，

直接从清单里删掉，不要列出来让我判断。

第三部分：你自己先排查冲突——在交清单的同时完成

请预演一遍「所有改动都生效之后」的状态，逐项检查并回答：

1) 这些改动之间是否互相冲突

例如一条调整了判断顺序、另一条新增了条件，合起来是否产生矛盾

2) 是否影响到本轮之外的内容

逐条说明会牵连哪些其他规则，以及会影响哪些已通过的案例

3) 改完之后是否出现新的空隙

即某类情况原来有规则可依，改完之后没有任何规则能命中

排查结果单独成段写在清单后面，不要混在改动说明里。

发现冲突时不要自己改方案把矛盾抹平，原样列出来让我判断。

如果排查后认为某条不该改，直接说明，不要为了凑数留在清单里。

第四部分：等我逐条确认我会按编号回复「同意」或「否决」，也可能只同意其中几条。

- 我没有明确说同意的条目，一律不许改

- 我否决某条时，不要追问理由，也不要换个说法再提一次

- 确认完成后，你只执行我同意的那几条

一条硬性要求：清单之外的任何内容一律不许动，

包括你在修改过程中新发现的「顺手可以优化」的地方。

发现了就先告诉我，等下一轮再处理。

写在最后

我们常常把 AI 的使用效果归因于提示词的质量：答案不够准确，就继续补充要求；执行不够稳定，就尝试写出更长、更完整的指令。但一项真实工作往往包含大量隐性条件、规则边界和例外情况，很难通过一次输入全部说明。

因此，想更有效地使用 AI，不是要追求一次性写出一条完美指令，而是要建立一套可以持续运行的协作方法：先判断哪些任务真正适合交给 AI，再通过追问将隐性经验转化为明确的条件和规则；执行过程中限制修改范围、保留人工确认；出现错误后，则根据具体原因进行最小调整和完整验证。

无论是个人处理日常工作，还是团队沉淀业务知识，只要任务中包含可以复用的经验、需要反复作出的判断，以及能够被检验的结果，都可以沿着这条路径逐步优化。

当任务目标、判断依据、操作边界和反馈机制都足够清楚，AI 才不只是一个能够生成答案的工具，而会逐步成为一个更可靠、更有效的协作者。