Claude Code 的 SendFeedback 工具，让 AI 自己起草会话失败报告
草稿排队存在本地 ~/.claude/feedback/drafts/，须经用户批准才会送达 Anthropic
Anthropic 为 Claude Code 上线了一个名为 SendFeedback 的新内部工具，给这款 AI 编程工具处理质量反馈的方式带来了结构性转变：Claude Code 现在可以自己起草失败报告，排进队列等你审阅，之后才会有任何东西发往 Anthropic。这项功能把传统的报错工作流倒了过来。它不再等开发者察觉哪里出了问题、再手动写一份报告，而是让 Claude Code 实时目击会话失败并撰写草稿 —— 而开发者对「什么内容、是否提交」保有完全控制权。
实际使用上的变化不大。架构层面的含义则不然。这是第一次，运行你编程会话的那个模型主动参与记录自身的不足，把智能体观察到的失败数据交到 Anthropic 工程师手上，而不再完全依赖开发者主动发起的报告。Anthropic 的数据使用文档明确描述了这个工具：「有了 Claude 起草的反馈，Claude 也可以起草一份反馈报告并把它排在你的机器上供你审阅。在你选择发送草稿之前，Claude Code 不会发送任何东西；而一份已发送的草稿，走的是与其他 /feedback 报告相同的提交路径和留存策略。」
什么会触发草稿 —— 以及草稿里写了什么
按Anthropic 的文档所述，SendFeedback 在四种条件下启动：某个工具或命令反复失败而未能解决；Claude 在持续尝试后仍无法完成请求；用户告诉 Claude 它犯了错，或者 Claude 自行判定自己犯了错；又或者用户明确要求 Claude 提交一份报告。
只要出现其中任何一种情况，Claude 就会在内部调用 SendFeedback，生成一份结构化草稿。草稿包含标题、一个类别字段、报告正文本身，以及一个控制「当前会话的对话记录是否随提交一并发送」的开关。草稿会立即写入用户本地文件系统的 ~/.claude/feedback/drafts/。在这个阶段，没有任何东西发往 Anthropic。
草稿驻留在本地是刻意为之。Anthropic 把这套工作流设计成：用户可以在任何数据离开设备之前，读取、编辑，并批准或丢弃每一份报告。这与被动遥测系统有显著区别 —— 后者通常按可配置的策略自动传输。在 Claude Code 的实现里，提交在每一步都需要人的主动动作。
当生成草稿的那次会话仍然活跃时 —— 也就是对话历史在本地可得时 —— 记录开关默认为开，否则为关。用户在提交前可以朝任一方向覆盖这个设置。即便启用了记录共享，本地工作目录路径也只会存在草稿记录中供参考，而会从传输给 Anthropic 的内容里剥离掉。
队列系统：卡片、上限与配置
Claude Code 通过渲染在输入框上方的内嵌卡片界面呈现待处理的反馈草稿。每张卡片显示草稿标题，并提供三个键盘操作：按 1 打开完整草稿以供审阅和编辑；连按两次 2 会不经编辑立即发送；按 0 关掉卡片但不删除草稿。被关掉的草稿仍留在反馈队列中，可以通过不带参数的 /feedback 命令访问，该命令会打开跨所有会话的完整队列。
系统会做会话级节流：默认一次会话中最多出现三张反馈卡片。达到上限后，Claude Code 会改为在输入区底部显示一个数量指示，而不再弹出单独的卡片。当用户连续关掉两张卡片、又不选择关闭该功能时，Claude Code 在这次会话中就不再询问。
跨所有会话，草稿队列最多保存十份报告。当生成第十一份草稿时，Claude Code 会自动移除最旧的那条。单份草稿在三十天后过期，届时从本地文件系统删除。草稿一旦成功提交，就会立刻从本地设备移除。已提交的反馈记录遵循 Anthropic 的标准数据留存策略；根据数据使用文档，通过 /feedback 共享的记录留存五年。
对于希望手动撰写报告的团队，带文本参数的 /feedback 命令和 /bug 命令都会直接打开标准反馈窗口，完全绕过草稿队列。
自我报告的设计为什么关系到数据质量
常规的 AI 产品反馈循环，依赖一连串每一步都需要开发者动作的事件：察觉有什么不对、判断它值得上报、找到反馈入口，再写出一段条理清楚的失败描述。每一步都会流失一批用户，而能挺过这条管线的失败，不成比例地都是那些戏剧性的 —— 崩溃、任务彻底失败、明显错误的输出 —— 而不是那些细微的：安静的推理错误、长会话中的上下文退化，或者那些产出看似合理却不正确行为的工具使用边缘情况。
SendFeedback 的触发条件，专门瞄准那些 Claude 能观察到、而用户未必会自行上报的会话级失败模式。当 Claude Code 自行判定它没能完成某个请求时 —— 这是一次内部评估，用户未必看得到 —— 该工具会在会话上下文消失之前把那一刻记录下来。这捕获的是失败的技术签名：尝试了什么、发生了哪些工具调用、失败当刻模型处于什么状态。而一份在数小时或数天后由人撰写的报告，是凭记忆重建这份签名的，每一步都在丢失精度。
Anthropic Claude Code 团队的工程师 Thariq Shihipar 在一篇公开帖子中描述了这套工作流的意图：用户不必自己跑去 /feedback 写报告，而是可以让 Claude 起草一份，然后在发送前审阅。这个说法讲的是减少摩擦，但底下的机制是一条结构化的数据管线：智能体观察到的失败事件，被格式化成一致的报告，经用户批准，通过既定通道提交。
这项功能够不到的地方
SendFeedback 的可用性限制，与功能本身一样能说明问题。凡是本地草稿存储在架构上不可行、或者数据处理义务压过产品默认行为的部署场景，Anthropic 都把它排除在外。
云端托管的会话 —— 包括网页版 Claude Code —— 无法生成反馈草稿，因为其执行环境无法访问用户的本地文件系统。使用 -p 标志的非交互式会话和 Agent SDK 运行也因同样的结构性原因被排除：没有终端界面可供用户审阅并批准排队的卡片。
对云服务商的排除 —— Amazon Bedrock、AWS 上的 Claude Platform、谷歌云的 Agent Platform，以及 Microsoft Foundry —— 反映的则是另一重考量。在这些平台上，Anthropic 的文档指出，反馈会被写入 ~/.claude/feedback-bundles/ 下的本地归档，而不是传输给 Anthropic。一份包含 Bedrock 部署会话内容的反馈提交，会牵涉到用户与 AWS 签订的数据处理协议，而不只是与 Anthropic 的协议。把这些场景排除在 SendFeedback 管线之外，就避免了这层复杂性的产生。
最有分量的一项排除，针对的是启用了零数据留存（Zero Data Retention）的组织。ZDR 是一种企业配置，Anthropic 在其中承诺请求完成后不保留会话内容。若允许在 ZDR 场景下生成反馈草稿，就等于开出一条通道，让会话内容 —— 即便经过用户批准 —— 得以进入 Anthropic 的反馈管线，与那份留存承诺直接冲突。因此该功能对 ZDR 组织干脆不可用。
另有三个环境变量可以单独关闭该功能：设置 CLAUDE_CODE_SEND_FEEDBACK=0、DISABLE_FEEDBACK_COMMAND=1，或给 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 赋任何非空值，都会把 SendFeedback 从会话中移除。那些关闭了特性开关拉取、或通过 Anthropic 的托管设置在组织层面关闭了产品反馈的机构，同样被排除在外。
延伸阅读：Claude Code 实验悄悄重映射了 Fable 5 的思考强度档位，Anthropic 已确认
这项功能想帮着解决的那个更新日志难题
Claude Code 的发布节奏很激进 —— 版本追踪站点记录到 2026 年发布了数百个版本，通常每周多次。每次发布都打包了数十项改动，横跨安全补丁、行为调整、界面细化和基础设施改进。更新日志会覆盖这些条目，但它无法覆盖它自己并不知道的东西：会话内部那些 Claude Code 遇到了处理不了的情况、然后不留记录地略过去的时刻。
这项局限是结构性的，而且有据可查。今年早些时候，GPTS24 报道过一起事件：Anthropic 的一次 A/B 实验改变了 Fable 5 会话中思考强度档位被翻译成数值参数的方式 —— 这是一次没有出现在更新日志中的行为修改，直到一位开发者把原始 API 请求日志与预期值对照才被发现。Anthropic 事后承认了该实验，但这起事件说明了「更新日志覆盖的东西」与「会话期间实际发生变化的东西」之间的落差。
SendFeedback 并没有为未披露的实验填上那道缺口。它做到的，是为另一个方向建立了一套正式机制：那些 Claude 观察到、但目前会随会话结束而蒸发的失败。从 Anthropic 的角度看，一份由模型自己在失败当刻、在会话上下文完整时提交的反馈报告，所含的诊断信息远多于事后重建的那种。而对开发者来说，代价是花几秒钟审阅一份已经写好的草稿，而不是从零开始写一份。
这项功能也改变了这套系统在反馈循环中为谁服务。在此改动之前，只有那些动力足够强、愿意跑去 /feedback 的开发者，才会贡献关于会话失败的质量数据。有了 SendFeedback，每一次 Claude Code 遇到失败的会话都成了潜在的数据来源，筛选环节从「用户主动性」换成了「用户批准」。
与竞品工具的反馈机制相比如何
在其他主流 AI 编程 CLI 工具 —— 包括 OpenAI Codex CLI、Cursor、Gemini CLI 和 GitHub Copilot CLI —— 的现有文档中，没有出现可直接对应的「AI 发起的反馈起草」机制。
竞争者目前采用的做法遵循传统模型：一个独立的反馈命令或按钮，没有 AI 起草，也没有对机器可观察失败条件的结构化捕获。GitHub Copilot 的反馈路径走 GitHub 的 issue 追踪系统。Cursor 的应用内反馈机制由用户发起。Anthropic 看起来是第一家实现「AI 发起、人类批准」式反馈起草的主流 AI 编程 CLI 开发商 —— 不过这个说法基于文档审阅，而非对各产品内部能力的独立审计。
这个区别不只是使用体验上的便利。它反映的是对「智能体编程工作流中质量数据从哪儿来」的不同假设。如果假设是开发者会察觉并上报失败，那么现有模型够用。而如果假设是：一个每次会话要跑几十上百次工具调用的模型，会遇到开发者未必察觉、或可能归咎于自己代码而非智能体的边缘情况 —— 那么一套智能体层面的观察机制，就实质性地改变了质量反馈的图景。
与基于聊天的 AI 产品相比，Claude Code 每次会话跑的工具调用量高得反常。一次涉及多文件重构、反复跑测试、git 操作和网络查询的会话，可能包含数十次离散的工具调用，其中任何一次的失败在事后都很难被隔离出来。SendFeedback 工具的定位，正是在这些失败签名还能被观察到的时候把它们捕获下来。
这里的竞争差距可能会很快收窄。Codex CLI 和 Gemini CLI 在 2026 年都保持高频发布，而智能体编程工具的诊断面正在扩张，扩张的方式恰恰会从类似的自我报告机制中获益。竞争者会不会在接下来的发布周期里加上 AI 起草的反馈机制，部分取决于 Anthropic 的实现能否在缺陷修复周转或模型行为质量上展示出可衡量的改善。
对 Claude Code 的企业客户而言，这条反馈循环还有额外意义。大规模部署会产生个体开发者很少见到的失败模式：规模化下的边缘情况、会触发智能体异常行为的特定代码库结构，或者只在生产负载下才失败的工具调用序列。一套能在用户批准下系统性收集这些失败签名的机制，给了 Anthropic 一份人工上报在规模上无法复制的诊断数据集。
哪些仍是公司自述，以及开发者该核实什么
上文描述的行为细节来自 Anthropic 的文档，属于公司自述，而非经外部审计独立验证。Anthropic 陈述的数据处理方式 —— 草稿在提交前留在本地、工作目录路径不被传输、ZDR 组织被排除 —— 构成的是有文档记载的行为，而位于 code.claude.com/docs/en/data-usage 的数据使用页面是权威参考。
身处受监管环境、或对数据敏感度要求较高的开发者，应当在假定该功能未启用之前，先确认那些排除条件确实适用于自己的具体部署。最简单的验证方式是查看会话中 /feedback 命令是否可用：Anthropic 声明，对 ZDR 组织和上述被排除的云服务商，反馈命令和 SendFeedback 工具都不会出现。
对于想主动关闭该功能的团队，在环境中设置 CLAUDE_CODE_SEND_FEEDBACK=0 可以在任何会话开始之前就做到这一点。
这项功能的数据架构 —— 本地草稿、人工批准、排除 ZDR —— 代表着比典型遥测系统更保守的隐私姿态，但它也足够新，以至于它在边缘情况下的真实行为尚未被大规模公开记录。随着该功能积累使用量，文档所述行为与实际观察到的行为之间的任何缺口，都应该通过 Anthropic 建造它所要启用的那同一个机制浮现出来：一份由 Claude 起草、由你审阅的反馈报告。
接下来值得盯的里程碑是：Anthropic 会不会把 SendFeedback 机制从失败检测扩展到主动的质量信号 —— 为那些任务成功但路径异常绕远的会话、或者模型作了假设而被开发者中途纠正的会话起草报告。那样的扩展会把这项功能从失败追踪器变成一件持续的质量仪器，让 Anthropic 拿到关于「Claude Code 在没有任何评测能覆盖的真实世界编程任务长尾上表现如何」的更丰富信号。它也会要求一套比当前失败检测方案更细腻的触发模型，并且把隐私门槛抬高不少：一次需要三处纠正才成功的会话，和一次崩溃的会话，是性质完全不同的数据。Anthropic 如何处理这个取舍 —— 或者干脆把 SendFeedback 严格限定在可观察的失败上 —— 将决定这次新增在回头看时显得有多重要。