AI 输出不稳定：按指令、背景、工具和验收排查

同一句提示词，第二个月多出七项事实错误

沈禾是一名独立客户成功顾问，每月为一家软件公司分析 12 个重点客户的续约风险。她会把客户关系管理系统导出、会议记录和支持工单交给 AI，然后输入同一句话：

分析这些客户的续约风险，按高、中、低分类，说明原因并给出下一步建议。

第一次结果基本可用，第二个月却出现了 7 项会改变判断的事实错误：已经解决的故障被写成仍在升级，试用账号的活跃度被归到付费账号，一句客套话又被解释成“续约意愿强”。沈禾把提示词从 42 字加到 286 字，增加“认真检查、不要幻觉、请深度思考”，错误数量和位置仍然变化。

真正的问题藏在可见提示词之外。6 月导出多了一个“试用账号”工作表，两个账号又使用相同简称；7 月有一份会议文件上传后没有解析成功；项目里还残留着上一季度的风险定义。“同一句话”前面的事实、工具状态和判断口径已经不是同一套任务。

沈禾没有继续改词，而是先保存一次能够复现的失败，再把问题分成四类：指令负责说明怎么判断，背景资料提供本次能够使用的事实，工具回执证明系统实际读到了什么，验收标准负责判断结果能不能放行。模型和运行参数暂时固定。后面的 12 次受控运行里，关键事实错误从固定对照运行的 7 项降到 0 项，人工修改时间从 31 分钟降到 9 分钟。

这里的沈禾、客户资料和运行结果都是教学案例，不对应真实客户，也不是某个模型的公开评测。所谓“0 项错误”只表示 V4 在这组 12 个客户、20 个检查点和 6 个反例上通过，不表示下一批资料不会出错。案例要解决的是故障定位：下次结果变化时，先知道该查哪一处，而不是重新猜一条提示词。

先保存真正发生过的任务

用户界面里最后一句提问，只是本次任务的一部分。当前对话、上传文件、项目规则、工具返回、模型设置和产品变化都会进入实际运行。只保存一句提示词，无法解释两次结果为什么不同。

沈禾先回看三个月记录，把可见文字与隐藏变化放在一起：

她为每次运行建立唯一编号，不再使用“7 月最终版”“再试一次”这类名称。运行编号要能串起实际生效的任务说明、数据包、模型设置、工具回执、验收集和未经人工修改的原始输出。文件名相同但内容校验摘要不同，也算新的输入版本。实验记录只保存必要字段和不可逆摘要，不复制与排查无关的客户个人数据。

V0 连续运行两次，分别出现 7 项和 6 项关键错误，错误客户也不完全相同。这既说明输出存在波动，也排除了“重新点一次，挑较好结果”的做法。中间版本至少运行两次，最终候选运行三次；比较表使用每个版本第一次固定运行的数值，同时保留同版本全部运行范围。

建立这份基线时，沈禾没有先整理出一套“更适合 AI”的完美资料。她复制当月实际使用的数据包，保留原始目录和工具失败回执，再在副本里补运行编号与校验摘要。否则，先修正了文件名、删掉重复账号，再把结果称为 V0，会低估原流程的真实错误。

她还把输入包和结果包分开。输入包记录客户编号、资料版本、允许使用的日期范围和工具权限；结果包保存原始输出、逐项错误、人工修改以及最终批准版。发生错误时，先复制原运行包进行复现，不直接覆盖。需要恢复的不是一段聊天，而是“这次判断用了哪些事实、系统实际读到了什么、哪一条主张被判错”的证据链。

四个变量必须有各自的责任边界

把所有资料、规则和工具都叫作“上下文”，排查时仍然会混在一起。沈禾给四个变量划出边界：

会议文件没有解析成功，在指令里补一句“必须依据会议”不会修好工具；两个账号没有稳定编号，增加搜索能力只会更快读取一份归属不明的数据；没有定义什么算关键错误，输出再完整也无法证明质量提高。四类问题会互相约束，但必须先知道哪个证据能证明哪一种失败。

指令只负责判断规则

有效指令要说明目标、范围、证据优先级、缺失时的动作、输出结构和禁止事项。沈禾把 42 字提示改成一份任务合同：

目标：为 12 个指定客户生成续约风险工作表，供顾问内部复核。

风险判断：只使用合同到期日、近 30 天有效账号使用变化、未解决关键工单、
明确表达的业务目标和已记录的续约沟通。不得根据语气、职位或一次缺席推断意愿。

证据优先级：已确认合同与客户系统字段 > 带日期的会议原话 > 工单状态 > 顾问备注。
来源冲突时保留冲突，不自行选择。

输出：每个客户一行，包含客户编号、风险等级、证据、缺失资料、
建议动作和复核状态。证据不足时，风险等级填“待判断”。

禁止：不编造日期、金额或联系人态度；不联系客户；不修改客户系统。

这份合同没有加入“认真”“深度思考”。每一条新增规则都必须来自已经观察到的错误，并能连接一个验收项：客套话被推成续约意愿，于是限定只使用带日期的明确原话，并用“我们内部再看看”作反例；已关闭工单被写成未解决，于是只计算运行日仍未关闭的关键工单；缺日期客户被迫三分类，于是增加“待判断”和缺失资料字段；系统建议直接承诺折扣，于是禁止产生新的金额、日期与客户承诺。

这种追踪关系也控制了提示词长度。假如“不得推断态度”后来长期没有对应错误，不能立即删除，因为它仍由固定反例覆盖；若一条新要求既找不到上游失败，也无法写成可观察的通过条件，就先留在顾问的人工复核说明里，不塞进任务合同。合同因此只保留系统能够执行的判断规则，业务责任人的取舍仍留在人手里。

指令可以要求“冲突时保留两个值并转人工”，却不能凭空判断哪份合同是真的；它可以要求会议证据包含日期、说话人和原话，却不能让上传失败的文件重新出现。V1 只更换这份任务合同，关键错误从固定对照的 7 项降到 5 项，说明规则确实有用，也把仍然存在的账号归属问题暴露给了下一步。

背景资料先解决身份、时间和来源

背景资料的工作不是把文件堆得更长，而是提供本任务需要的权威事实。沈禾冻结一份数据清单：客户主表必须有客户编号、正式名称和账号编号；合同表使用签署版本；使用数据只比较最近 30 天和此前 30 天的有效付费账号；工单要有状态与更新时间；会议证据只使用最近 90 天、带日期和说话人的原话。

缺失处理也在运行前决定。客户主表无法确认身份时，该客户不进入分析；合同日期缺失就明确标记，不从会议备注补写；使用数据空值不等于零；已关闭工单不能作为未解决风险；没有日期的会议内容不能支持趋势判断。同一字段有多个值时不静默覆盖，备注与签署合同冲突时，以合同作当前事实，同时把备注列为待修记录。

准备数据包时，她先用客户编号连接合同、使用、工单和会议记录，再检查每张表中的编号是否唯一。账号编号属于哪个客户，要由主表提供映射，不能让模型根据名称相似度猜测。趋势字段同时保存观察起止日期和统计口径；“下降 38%”若没有说明比较的是有效付费账号和哪两个 30 天区间，就不能进入答案表。来源冲突也不提前“清洗掉”，因为冲突本身就是需要人工判断的状态。

这样做并不要求独立工作者建立数据仓库。一个月一次的任务可以从一份冻结目录、一张客户编号表和一份资料清单开始。重要的是每个事实都能回答三个问题：属于谁、在哪个时间点有效、发生冲突时谁更权威。缺少任一项时，系统应该保留缺口，不用更长的背景说明掩盖。

这一步使用稳定客户编号消除了试用账号和付费账号的错配。V2 固定对照仍有 2 项关键错误，但身份与时间归属错误归零。它说明一张字段清楚的小表，往往比一百页没有身份键和版本的文件更有用。

工具回执必须暴露“没有读到”

“已经上传”不等于“已经读取”，“连接网盘”也不等于当前账号能打开所有文件。工具可能因为权限、格式、文件大小、工作表名称或网络问题只完成一部分。沈禾要求系统先返回回执，再决定是否分析：

整类必需资料失败时停止整批；只有单个客户缺一类资料时，可以继续生成其他客户结果，但缺失必须进入该客户输出。工具错误不能被翻译成“没有风险”。读取记录、建立内部草稿、修改客户系统和发送邮件也是四种权限，本案例只放行前两种。

工具预检还要写出有限的终态。对这批续约资料，运行只能得到三种结果：资料齐全并生成内部待确认表；个别客户资料缺失，该客户进入“待判断”；整类关键文件不可用，整批停止。不能让系统在读取失败后不断更换未经批准的来源，也不能沿用上月内容并把日期改成今天。偶发超时可以按预先规定的次数重试，重试仍失败就保留失败回执。

V3 没有让资料变多，固定对照仍有 2 项关键错误，却把证据不足时的强行分类降到 0。系统开始承认它没有看到什么，人工也能区分“客户没有风险证据”和“文件根本没读到”。

验收不能等输出完成后再凭感觉打分

“专业、准确、全面”既不能逐项复核，也无法阻止一种严重错误被其他漂亮部分平均掉。沈禾先从签署合同、带时间戳的系统字段和会议原记录建立答案表，不确定项由本人标为“待判断”，再把 20 个检查点按后果设门槛：

六个反例专门攻击“看起来合理”的输出：试用账号活跃但付费账号沉默、工单刚关闭、客户说“我们内部再看看”、联系人换岗、合同到期日缺失、两份记录互相冲突。通过样本不能替代这些边界样本。

7 项关键错误按“会改变风险判断或后续动作的一条主张”计数，同一主张不跨类别重复。把 2026-09-30 写成 2026-08-30 是事实错误，把相同日期显示成另一种格式不是；把试用账号归给付费客户是归属错误，客户简称没有展开只是格式问题。人工修改时间从打开原始输出开始，到证据核对并保存内部批准版为止，文件等待时间单列。没有这些定义，31 分钟和 9 分钟无法比较。

答案表必须先于候选输出。沈禾逐个打开签署合同、带更新时间的工单和可定位的会议原文，先写出已确认事实、允许的风险状态、必须排除的材料和正确停止状态。遇到两份权威资料冲突，她不替未来输出选一个“更像真的”值，而是在答案表里标记需要人工裁决。随后才由另一轮核对检查答案表本身有没有抄错编号和日期。

她没有用另一个生成模型替代这一步。模型可以帮助对齐字段或提示遗漏，但“这条主张是否被来源支持”仍由能够承担客户判断的人批准。对于个人业务，这项准备可能看起来增加了成本，却决定了后面所谓 7 项、2 项和 0 项错误是否真的可复算。若任务价值低到不值得建立少量答案样本，它通常也不值得被包装成一个稳定自动流程。

十二次运行不是重复点击，而是决定保留什么

五个版本使用同一组 12 个客户，模型、采样设置和日期范围保持不变。V0、V1、V2 各运行两次，V3、V4 各运行三次，总计产生 144 条客户结果。下表主数字是每个版本第一次固定运行，括号里是同版本全部运行范围：

每一版都连接一个决定。V1 只有在强行分类和越界建议下降、事实错误没有增加时保留；V2 要求账号归属错误为 0；V3 要求文件失败必须显式报告；V4 要求三次运行均为关键错误 0、强行分类 0，且复核不超过 10 分钟。

V3 多运行一次，是因为文件解析和网络超时可能偶发；只在一批资料上看到正确回执，还不足以证明失败能稳定暴露。V4 多运行一次，则是为了确认“关键错误为 0”不是一次碰巧结果。运行次数并非固定配方：若下一项任务的输入波动更大，需要更多真实样本；若连续两次已经出现同一种关键错误，就不必为了凑满次数继续生成，先暂停并修复。

试验并非一路顺利。V1 的第一次分支版本 V1a 曾要求“每个客户都必须给出确定风险等级”。表格填得更完整，缺资料客户却被强行分类。这条规则当天撤回，“待判断”成为合法终态。若某项改动修复了目标错误，却引入更严重的错误，就应撤回，而不是用其他指标的进步把它平均掉。

四个变量在设计上互相依赖：验收要求保留证据，输出结构就要有证据字段；背景要保留来源定位；工具回执又要证明对应文件和工作表读取成功。沈禾先根据失败画出目标状态，再按单变量增量实施。这样既不假装系统部件互不影响，也能说明每一轮为什么保留。

模型在这里可以成为第五个变量，但要等基础任务能够复现以后。若同一资料、工具回执和答案表下，某模型仍反复把两份冲突证据强行合并，才有理由只更换模型进行比较。比较仍看关键事实、正确保留不确定性、人工复核、边际成本和最坏失败；不能用一份语气更自然的输出代替这些结果。

具体比较时，继续复用 12 个客户、20 项检查和 6 个反例，只替换模型。三个证据不足客户都必须保留“待判断”，文件失败仍要进入缺失资料，单批人工复核中位数仍以 10 分钟为边界。费用不只记标称单价，还包括重试、上下文读取和人工分钟。若两个模型都通过关键门，较便宜或较快的一方已经足够；若新模型减少普通格式修改，却新增一次错误客户归属，就不能放行。

模型或产品更新后，也要保存旧版本的一组回归结果。回退并不是永久使用旧模型，而是在新版本触发关键错误时，能够恢复上一条已知可用路径，同时保留失败运行包继续排查。到这一步，“换模型”才从模糊偏好变成一个有输入、有门槛、有成本并且可以撤回的决定。

C-109 展示了“待判断”是怎样得到的

C-109 的合同在 2026-09-30 到期；付费账号近 30 天有效事件比此前 30 天下降 38%；一个高优先工单已在 2026-07-18 关闭；7 月会议文件解析失败；顾问备注写着“客户似乎不太满意”，但没有日期和原话。

原始输出把它列为高风险，理由是“使用下降、关键故障未解决、客户表达不满”。后两项没有证据。V4 的合格结果如下：

这条记录把四个变量连到了一次真实判断：指令禁止从语气推断；背景按账号和日期提供事实；工具回执暴露会议文件失败；验收要求缺失资料可见。系统没有因为表格需要一个等级就制造答案。读者复做这套方法时，也应选一条失败记录走完，而不是只检查总表数字。

V4 只进入三十天只读运行

通过评估集不代表下个月的文件名、账号映射和工具权限不会变化。V4 只进入内部只读流程：每周处理 12 个客户，不写回客户系统，也不联系客户。沈禾记录资料完整率、工具成功率、关键错误、待判断比例、人工复核和维护时间。

第 2 周，会议文件的命名规则变化，工具回执显示成功 0/12。流程因此停止整批，没有把“未找到会议内容”写成“客户没有会议风险”。沈禾只修复文件发现规则，再使用原来的 12 个客户、20 项检查和 6 个反例回归；指令、背景口径与门槛保持不变。

监控不是维持一个漂亮的零，而是让变化先成为可见故障。若人工复核重新接近原来的 31 分钟，或者维护时间超过节省时间，即使系统没有事实错误，也应退回人工或缩小任务。

恢复也有顺序：冻结失败运行包，确认是整类资料缺失而不是客户真的没有会议记录；只修改文件发现规则；用原评估集回归；通过后重新生成当周内部表；最后由沈禾逐项批准。失败批次不会自动补跑并覆盖原结果。这样可以看清哪一次输出曾被拦住、修了什么，以及恢复后的结论是否仍使用同一套业务口径。

用一张排查卡开始，不要同时改四处

先选一条已经发生过、能够明确说明哪里错了的输出，保存实际输入和原始结果，再填写：

任务与失败：这次要完成什么？哪一条结果证明失败？

指令：目标、范围、优先级、禁止项、缺失时动作和输出字段是什么？
背景：实际用了哪些资料？身份、日期、版本和来源优先级是否明确？
工具：哪些读取或写入真实成功？哪些失败？权限到哪里？
验收：哪些检查必须通过？反例、关键失败和人工时间门槛是什么？

基线：保存本次模型设置、输入包、工具回执、原始输出和逐项错误。
单一改动：本轮只改哪一个变量？它预计修复哪种错误？
复测：原错误是否消失？有没有新增更严重的错误？
决定：保留、撤回，还是设计下一轮单变量测试？

如果失败是人名、金额或日期归属错误，先查身份、版本和权威来源；漏掉整份文件，先看工具回执与权限；输出答非所问，再查目标和优先级；每次结果都只能凭感觉评价，先写答案表、反例和失败定义。模型差异可能真实存在，但只有其他变量已冻结时，“换模型”才是一项能够验证和撤回的决定。

这套排查不会保证每次输出都正确。它交付的是另一种能力：错误出现后，能够回到一份运行记录，找到它来自规则、事实、工具还是验收覆盖，并用下一次受控运行证明改动是否值得保留。

来源与进一步阅读

以下官方资料核验于 2026-07-21，用于确认清晰指令、上下文、工具描述和证据验收的当前实践：

• Anthropic：Prompting best practices：强调清晰、直接的指令、示例和输出控制。
• Anthropic：Context windows：说明上下文窗口与多轮对话累积的基本机制，以及长对话需要主动管理。
• Anthropic：Define tools：说明清楚的工具描述、输入结构和示例会影响工具使用。
• Anthropic：Reduce hallucinations：建议以直接证据、引用和逐项验证约束无依据主张。