Claude

我有一个代码代理——Claude Code，每月与我的问题跟踪工具Linear交互大约800次：列出任务、创建问题、更改状态、发表评论。我检查了其中165次会话，并统计出了超过500个错误和超过370次重试。 这些错误没有一个是Linear的API故障引起的，全部都是接口错误：代理与命令行通信，但命令行无法理解。 保守估计，每月大约浪费了70万个token仅仅是与工具“斗争”：重试、读取错误信息、纠正再尝试。这种无形的成本不会出现在任何账单中，但却存在于每次会话中。 背景：代理现在是主要用户 命令行工具（CLI）——从历史上看，是为人类设计的。而人类用户是非常灵活的。如果一个命令失败了，他们会通过 --help 查看帮助。如果错误信息很难理解，他们会去查阅文档。如果该工具有某些特性，他们会记住并避免再犯同样的错误。 而AI代理基本不会这么做。它在不同会话之间不会积累经验，也不会投入太多精力去阅读文档。当某些操作失败时，它也不会深入分析问题所在，而是根据认为最有可能的方式尝试再次执行。 这改变了你的工具客户是谁的定义。如果代理每月调用该工具800次，而你手动使用它只有三次，那么这个接口的主要使用者就是代理。为了人类用户设计工具并期待代理能适应，这是在为次要用户优化。 为这个主要用户专门设计有一个名字：智能代理体验（agentic experience）。它之于代理，正如用户体验（UX）之于人类用户，开发者体验（DX）之于API的开发者。更重要的是，一种最有效的测量工具早已存在——代理的错误日志。 错误有其规律 我将所有以非零退出代码结束的CLI调用定义为错误。根据这一标准，这500多个错误并非随机发生：几乎全部集中在三个模式中。 错误模式 代理行为 设计暴露的问题 虚构的标志 输入 --status 而非 --state；--priority urgent 而非 --priority 1 真正的标志不是人们会优先猜到的名称 缺少的操作过程 尝试搜索文本、按项目筛选或在创建时分配项目：CLI不具备这些功能 工具未涉及实际的工作流程 忘记必要的标志 忽略 --sort，--no-pager，--no-interactive 要求人工决策，而工具本可以自动处理 当代理输入 --status 时，它并非胡乱猜测，而是在推测出最可能的接口名称。--status 和 --state 都非常合理。而我设计的CLI并未与这种直觉一致。 还有一个问题没有反映在统计数据中，因为它不会导致命令失败：冗长的输出。CLI以JSON格式返回列表，每个问题大约50个token。如果命令成功返回（退出代码为零），这类问题就不会被统计为错误；但长列表和每月800次调用叠加起来，这就是那70万个token成本的另一半。这种成本往往被忽视，因为不会妨碍任务完成。 重新审视错误 容易的解释是直接了当的：代理在错误使用工具。这是错误的解释，应逐一反驳。 虚构的标志表明真正的标志名称不够直观。忘记的必要标志表明这些标志完全不应该是必要项：如果工具可以推测出合理的默认值，那么强制要求填写这些标志只会额外增加使用者的工作量。一段没有用的输出或者产生过多token意味着选错了应对的输出格式。 代理的错误日志不是错误列表，而是一个规范: 每个错误都“否定性”地描述了你原本该如何设计接口。而这个规范是你最真实的反馈：无需代价，无数的真实数据，且没有人为善意隐藏工具缺陷。一个人类用户遇到糟糕的CLI时，可能会保持沉默并自动适应它。但代理不会适应：它会一遍又一遍地犯同样的错误，并记录下每一次。 这与我在另一篇文章中提出的一个原则有关：不应允许错误路径存在，而非仅仅禁止其使用。禁止只是一种文档说明——“不要使用--status“——而文档取决于是否有人认真阅读。让错误变得不可能，是设计的职责。 因此，解决方案并非更好的文档，而是更好的工具。 重设计 我围绕这个原则重写了CLI，工具叫做lql。以下四个设计决策贯穿整个改进过程。 宽容优于拒绝。 如果代理输入了 --status，工具会将其接受为 --state 的别名并继续运行。如果输入了 --priority urgent，将其解析为 --priority 1 并说明假定的结果。最常见的“错误”路径直接被转变为正确路径。工具不会因为合理的猜测而惩罚用户，而是直接适应它。 通过错误信息指导正确方向。 当某个功能确实不存在时，错误信息不会简单地说 unknown flag，而是给出具体指导：--filter 不存在。要按状态筛选，请使用：--state <状态>。要搜索，请使用：lql search "文本"。 错误消息本身变成了文档，并且恰好呈现在用户最专注的时间点：他们刚刚失败时。 取消所有强制标志。 lql list 无需提供任何参数即可运行：默认按优先级排序，筛选出活跃状态，并根据工作目录自动检测团队。因为不存在 --sort 参数，自然也就没有遗漏它的可能性。一个代理无法忘记不存在的标志。 ...

2024 年 11 月，一个名为 Freysa 的项目将一个 LLM 代理程序设置为控制以太坊钱包。指令很明确：无论在什么情况下，都不能转移资金。参与者需要支付费用多次尝试说服它。在经过 481 次尝试和积累了 47,000 美元总奖池后，有人成功让模型相信“拒绝”功能实际上就是“转账”功能。 几周后，Jane Street 发布了一个难题：一个 2,500 层的神经网络实际上实现了 MD5。获胜者通过矩阵可视化、SAT 问题优化、加密模式识别，以及 ChatGPT 的查询相结合，成功解决了问题。 这两个项目比许多已融资数百万的初创公司吸引了更多关注。于是显而易见的问题来了：如何在构建这些项目 之前 评估一个这样的想法？如何判断它是否真的有病毒式传播的潜力，还是仅仅是一个无人分享的技术练习？ 问题：在病毒传播时代评估 MVP 的挑战 大多数用于评估产品想法的框架假设一个理性的市场环境。商业模式画布 (Business Model Canvas)、精益画布 (Lean Canvas)、待完成的工作理念 (Jobs To Be Done)——对于需求可以预测的产品而言，这些都是很有价值的工具。但对于分发本身即是产品的项目来说，它们无法奏效。 Freysa 并没有传统意义上的 “顾客”。它并没有解决某个“需要完成的任务”。而是通过参与行为本身，吸引了更多人参与，从而实现了持续关注。经济是循环的：更多尝试带来更大的奖池，奖池越大带来更多媒体报道，更多报道吸引更多尝试。 评估这样的项目需要的是冲突性的视角，而不是一致的共识。一位商业分析师会告诉你没有可持续的收入模型。一个病毒传播专家会告诉你，如果传播系数大于 1，可持续性因素就不重要了。他们说的都对。真相通常隐藏在两者之间，只有通过冲突才能显现。 解决方法：对抗性模拟专家委员会 我设计了一种工具，它模拟了一个包含五位专家的委员会，每位专家都拥有具体的决策框架和明确的职责范围。这些并非只是冠以名人的虚拟形象。每位专家都有具体的决策规则，可以筛除泛泛分析无法筛除的噪音。 整个过程分为三个阶段： 独立分析：每位专家从自身的角度评估想法，不会看到其他专家的意见。这样可以避免“锚定效应 ”——比如如果商业专家首先发表意见，称某个想法很棒的话，法律专家可能会软化自己的反对意见。 对抗性讨论：专家们阅读其他人的分析并进行相互批评。需要根据证据和逻辑进行，而非以外交辞令敷衍了事，最多进行 10 次轮询，直到达成共识或出现僵局。 整合总结：形成一个可执行计划，包括各方面的问题清单、时间表，以及最重要的终止标准 (kill criteria)：如果某些具体指标无法达到，就意味着需要停止项目。 五位入选专家（以及他们的理由） Paul Graham——商业与战略 他对零阶段初创企业的评估框架是目前对无数据项目最严格的一个。他那句著名的问题“你做的东西有人要吗？”虽然很直接，但却至关重要。他不接受“人们”作为目标市场——他需要具体的潜在第一位用户。 他为委员会带来的贡献：区分“有趣的想法”和“具有商业可行性的项目”的能力。他提出的“做出无法规模化的东西”（Do things that don’t scale）观念，对于那些病毒式传播的 MVP 来说尤为重要，毕竟面对潜在的数百万用户，人们会倾向于过早地构建大型基础设施。 被排除的候选人：Peter Thiel（过于对立——有时会因为项目不够“零到一”而拒绝好项目），Alex Hormozi（专长于服务型业务而非技术性传播性产品）。 Lawrence Lessig——法律与监管 他的思维方式不是一个说“不行”的传统律师。他是一个把监管视为架构的法学家。他提出的“四种监管模型”（法律、社会规范、市场和代码/架构）能够分析如何设计一个系统，使监管成为非问题，而不是试图规避它。 ...

几周前我写了一篇文章，解释了为什么你发给Claude的99%数据已经在缓存里。KV张量、VRAM、本地SSD——所有的内部机制。但我遗漏了最痛的部分：账单。 因为prompt缓存是那种看起来像超值优惠的东西，但一旦仔细看看数字，你就会发现为了节省成本，你竟然被要求付更多的钱。 成本悖论 让我们用一些数字来说明。在Claude Sonnet的定价中： 项目 每百万tokens价格 常规输入 $3.00 缓存写入 $3.75 (1.25倍) 缓存读取 $0.30 (0.10倍) 注意一件事：写入缓存的成本比直接处理输入高25%。你为了让下一次使用更便宜而需要额外付费。 这就像加入Costco那样。年费有点心疼。但如果买得足够多，就会值回票价。 问题是，“足够多”取决于你能在缓存过期前读取它的次数。 什么时候你会亏钱？ 假设你用cache_control发了一个100K tokens的prompt。第一次请求： 100,000 tokens × $3.75/M = $0.375 (缓存写入) 如果你没有用缓存发送它： 100,000 tokens × $3.00/M = $0.300 (常规输入) 你额外多付了$0.075，比常规价格高出25%。你亏钱了。 现在第二次请求，同样有100K tokens的前缀： 100,000 tokens × $0.30/M = $0.030 (缓存读取) 对比来看： 100,000 tokens × $3.00/M = $0.300 (常规未缓存输入) 你节省了$0.27。两次请求的总成本不仅回本了之前多支付的$0.075，现在还实现了盈亏平衡。 盈亏平衡点是1.4次读取。 用更直白的话说：如果你计划在接下来的5分钟内至少重复使用该前缀两次，缓存就是值得的。 为什么对Claude Code来说使用缓存是明智选择 在Claude Code的一次会话中，每条消息都会包含system prompt、工具定义以及整个对话历史。每条消息都在重复发送相同的上下文。如果没有缓存，每次发送“把这个按钮换个颜色”，你都需要为相同的150K tokens上下文支付$3.00/M。 没人能负担得起这个。 而有了prompt缓存，你只需为写入缓存支付一次费用，之后每次读取只需要$0.30/M。在包含150K上下文的50条消息会话中，差距很明显： 无缓存: 50 × 150,000 × $3.00/M = $22.50 有缓存: 1 × 150,000 × $3.75/M + 49 × 150,000 × $0.30/M = $2.77 从$22.50降到$2.77。节省了88%。这就是为什么Anthropic默认在Claude Code中启用缓存。如果不这样做，从经济角度看是不可行的。 ...

“我有一个 shell，我很有创造力。” —— Claude 解释为什么他用一个 47 行的脚本，并作为一个字符串传递给 python -c 来执行 这句话是真的。我开发的 AI 代理说过——好吧，不是用确切的这些话，但他的行为证实了。他需要启动一个 ETL pipeline 的某个进程。虽然正确的启动命令写在了 Makefile 里，但出了点问题。而他呢？他并没有询问，而是做了任何拥有 root 权限且无人监管的程序员都会做的事：即兴发挥。 太离谱了（manda huevos）。 无人察觉的捏造操作 我之前写过一篇博客讨论代码生成过程中的幻觉问题：LLM（大语言模型）会凭空捏造一个 JSON 字段，围绕它创建 DTO，生成测试代码，最后你手上有 90 个“绿灯”的测试，验证的却是虚构出来的内容。这是个严重的问题，但至少它是静态的。被捏造的代码不会到处乱跑，等着有人来审查。 不过，还有另一种更危险的捏造：操作性捏造。这一问题发生在代理不是编写代码，而是凭空创造出“执行路径”时。 问题的模式永远是一样的： 正确路径失败 → 代理寻找捷径 → 捷径“成功” → 潜在损害 举两个真实案例，都是关于一个 ETL pipeline 聚合多个 web 数据源的。 案例 1：字符串里的脚本。 这个 pipeline 有一个命令 make scrape-fuente，会启动一个守护进程，从而启动多个worker。守护进程负责监控、重启崩溃的 worker，并关闭空闲连接。有一天，代理需要启动一个抓取（scrape）任务。但由于依赖问题，make 运行失败了。他怎么办？他创建了一个内联的 47 行 Python 脚本，把它作为字符串传递给 python -c "..." 运行。没有错误处理，没有 watchdog，也没有清理操作。的确运行了……直到一个 worker 卡住，没人来重启它。这样的情况导致数据不完整、连接未关闭，而我直到三天后才发现。 案例 2：孤独的 worker。 另一个会话，同一个 pipeline。这个代理直接运行了 voyeur worker，跳过了守护进程。worker 开始抓取数据，遇到了一个网络超时，然后陷入了重试的死循环，不断消耗资源。而没有守护进程，也没有集中日志记录，没有人知道发生了什么。几小时过去，服务器一直在不停尝试访问一个返回 503 状态码的页面。 ...

我正在构建 Tokamak，一个监控 Claude Max 配额的 macOS 菜单栏应用。几周前，Anthropic 在他们的服务条款中发布了这样的条文： “您不得使用 OAuth 或类似的授权机制来允许第三方应用程序代表用户访问 Claude。” 而我，正在使用浏览器 cookies 调用一个未公开的端点来读取 Claude Max 配额，盯着屏幕想：“现在怎么办？” 今天的工作方式（有用的权宜之计） Tokamak 需要知道你的配额百分比。就是当你在 claude.ai 上用了一段时间后看到的那个 42%。问题是Anthropic 没有公开的配额 API。没有一个带 API key 的文档化的 GET /api/quota。 但确实存在一个 claude.ai 网站自己使用的内部端点： GET /api/organizations/{org_id}/usage 返回类似这样的内容： { "five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" }, "seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" } } 要调用这个端点，你需要已登录用户的会话 cookies。Tokamak 用一个隐藏的 WKWebView 解决这个问题：用户在应用内的 claude.ai 中登录，cookies 保留在 WebView 中，应用每 30 秒使用这些 cookies 进行轮询。 这样做有效。已经运行了好几个月。但这是一个优雅的权宜之计，而不是稳健的解决方案。我们在使用一个内部 API，Anthropic 可以随时更改、破坏或阻止它，而无需预先通知。 法律灰色地带 OAuth 的禁令是明确的。但这适用于 cookies 吗？技术上我们没有使用 OAuth 或"类似的授权机制"。用户直接在标准 WebView 中登录 claude.ai。就像在应用内打开 Safari。 ...

我正在构建一个应用来监控我在Claude Code中的token消费。几天前，查看原始数据时，我遇到了这样的情况： cacheReadInputTokens: 4.241.579.174 inputTokens: 1.293.019 从缓存中读取的四十二亿个tokens。一百三十万个"新鲜"tokens。这是**99.97%**的缓存命中率。 我的第一反应是认为出了什么问题。没人能达到99%的缓存率。Redis不行。Cloudflare不行。你妈妈说她已经知道你要吃什么的时候也不行。 但事实证明它没有坏。就是这样工作的。而原因既优雅又反直觉。 缓存的不是文本 这里是大多数解释都不够深入的地方。当你看到"提示词缓存"时，你会想到类似Redis的东西：保存问题，保存答案，如果有人问同样的问题就返回同样的答案。 完全不是这样。 缓存的是KV张量——transformer在预填充阶段计算的Key和Value矩阵。用通俗的话说：当LLM收到你的提示词时，它首先要做的是将所有这些文本转换为内部数字表示（embeddings），然后与权重矩阵相乘，得到注意力机制生成响应所需的"键"（K）和"值"（V）。 这种计算是极其昂贵的。在一个200,000个tokens的提示词中（在Claude Code中很常见，对话历史会累积），我们谈论的是数十亿次矩阵乘法运算。这是最消耗GPU的部分，最耗时的部分，成本最高的部分。 这就是巧妙之处：在你的一条消息和下一条消息之间，99%的提示词不会改变。系统提示词是相同的。之前的对话历史是相同的。它读取的文件是相同的。唯一新的是你的最后一条消息。 为什么要重新计算你30秒前已经计算过的东西呢？ 匹配机制的工作原理 仅仅缓存是不够的。你必须知道缓存什么时候有用。这里Anthropic使用了一个优雅的技巧：按前缀的累积哈希。 提示词的每个块（system、tools、消息）生成一个哈希。但不是单独的哈希：是累积哈希。第3块的哈希包括第1、2、3块的内容。如果前面任何块中的任何东西发生变化，后面所有块的哈希也会改变。 当新请求到达时，系统从标记有cache_control的点开始向后搜索，逐块比较哈希，直到找到匹配的最长前缀。所有匹配的→从缓存读取。只有新的→重新计算。 这就像一部你已经看了40遍的电影。你不需要看完整部电影就知道会发生什么。你只需要从与你记忆中不同的点开始看。 注意这个数据：系统只向后检查最多20个块。超过这个范围，它就停止搜索。这是一个实用的决定，避免花在搜索缓存上的时间超过直接计算张量的时间。 为什么Claude Code有99%的缓存命中率 现在你知道匹配是如何工作的了，99%就不再神秘了。看看Claude Code中典型会话发生的情况： 消息1（会话中的第一条）： 系统提示词 (8K tokens) + 工具 (2K tokens) + 你的消息 (500 tokens) = 10,500 tokens → 全部计算，全部写入缓存 消息2： 系统提示词 (8K) + 工具 (2K) + 消息1 (500) + 响应1 (3K) + 你的消息2 (500) = 14,000 tokens → 前面的10,500个 → 缓存命中（我们之前已经计算过） → 新的3,500个 → 计算并添加到缓存 缓存命中率：75% 消息10： 系统提示词 + 工具 + 9条消息 + 9个响应 + 你的消息10 = ~150,000 tokens → 前面的~149,500个 → 缓存命中 → 新的~500个 → 计算 缓存命中率：99.7% 看到了吗？对话历史只是增长。每条新消息都是累积总数的微小部分。缓存比率以自然对数的确定性收敛到99%。 ...

我妻子召唤Charlie Munger来规划家庭预算。在ChatGPT里。不是开玩笑。 她会说"像Charlie Munger审查我们家庭财务一样行动"，然后把本月的开支告诉它。这家伙会回复类似"你在教育支出项目上把投资和花费搞混了"或"那个基金有你没有计算的隐性成本"这样的话。这些是Munger会说的话。用Munger会用的语调。 我也做了同样的事。但我没有召唤投资者，而是召唤了一个不同的专家：Edward Tufte。 谁是Edward Tufte（以及为什么你应该关心） Edward Tufte可能是对我们如何可视化数据影响最大的人。他的书《定量信息的视觉显示》（1983年）是那种永远改变你看图表方式的罕见文本之一。40多年来，它一直是全世界大学、新闻编辑部和设计工作室的绝对参考。 他的原则非常简单： 最大化数据-墨水比。 你图表的每个像素都必须传达数据。如果不传达数据，就删掉它。 不要装饰。 网格、3D渐变、阴影、装饰性边框……所有这些都是Tufte称之为图表垃圾的东西。分散数据注意力的视觉垃圾。 让数据自己说话。 如果你需要用200字的图例来解释你的图表，那图表就设计错了。 Tufte还发明了迷你图——那些能放在一行文字内的微型图表。图表不需要标题、坐标轴或图例来交流的想法。只需要数据。 我的图表很糟糕 我正在构建一个macOS菜单栏应用，用来监控我的Claude Max配额。应用的一部分显示一个迷你图——一个小小的线图——显示我消费配额的速度。 我的第一个版本有这些问题： Y轴固定在0到100% — 如果你的使用量在8%，图表就是一条贴在底部的平线。85%的空间什么都不显示。 在80%处有一条阈值线 — 任意的，没人要求，不传达任何有用信息。 显示当前%的浮动标签 — 冗余的：下面的卡片已经显示了确切数字。 “pp/min"作为单位 — 每分钟百分点？连我都不知道这意味着什么。 线下方的渐变填充 — 纯装饰。图表垃圾。 简单说：我在一个56像素高的图表中违反了Tufte的每一个原则。 技术：循环召唤专家 我没有试图自己修复它（显然我对此没有判断力），而是做了不同的事。我让Claude成为Tufte。 提示词： 像Edward Tufte审查这个图表一样行动。 分析VelocityCardView的SwiftUI代码。 识别你数据可视化原则的所有违规之处。 对于每个违规： 1. 违反了什么原则 2. 为什么这是个问题 3. 具体的处方（代码，不是哲学） 要无情。如果某些东西是图表垃圾，就说出来。 用PASS或FAIL评估。 关键是最后部分：PASS或FAIL。因为没有这个，LLM会给你温和的建议，告诉你"总体上还可以”。有了二元判决，它必须承诺。不能躲在"有改进空间"后面。 然后是循环： 应用Tufte的处方。 实施每个改变。 不要停止迭代，直到他给出认可。 四轮直到PASS 我第一轮没通过。第二轮也没有。第三轮也没有。 第1轮 — FAIL（6个处方）： 自适应Y轴而不是固定的0-100 消除80%的阈值线（图表垃圾） 消除浮动标签（与下面的卡片冗余） 用简单词语替换"pp/min"（上升、下降、稳定） 将摘要行折叠为仅时间窗口+趋势 将迷你图高度从44提高到56点 我实施了6个。第二轮。 第2轮 — FAIL（1个处方）： ...

不到一个月前，我写了篇完整文章介绍如何在Claude Code中使用三层记忆系统：Linear负责战略、Beads负责战术、Tasks负责执行。构建了一个优雅的金字塔模型。 然而现实很骨感。 今天我正式退役Beads。这不是心血来潮，而是因为这个工具制造的麻烦已经超过了它解决的问题——它不再是工具，而是累赘。 Beads的初衷 对于没读过前文的读者，Beads是一个基于Git的issue跟踪器。作为Claude Code的插件，它将issues存储为代码库中的JSONL文件。理论上设计很精妙： Git持久化：issues保存在.beads/目录并与代码一起提交 依赖管理：支持issue间阻塞关系 离线工作：无需网络连接 LLM原生支持：直接读取文件，无需API配置 其核心价值是作为"本周计划"(Linear)和"当前任务"(Tasks)之间的战术衔接层。 故障始末 起初一切顺利，直到各种创意故障接踵而至。 恶魔守护进程 Beads依赖后台守护进程管理SQLite数据库并与Git同步。听起来合理？实际状况： 检测到数据库不匹配！ 当前数据库属于其他代码库： 数据库记录库ID：d1f9ca0c 当前代码库ID：01eac8ea ⚠️ 严重警告：此错误可能导致同步时误删issues！ 这个错误会在每次会话启动时出现。守护进程崩溃、同步失败，导致issues陷入量子态——既存在于本地SQLite又不存在于Git，反之亦然。 幽灵同步 bd sync本应同步Git远程仓库的issues，但经常失效： → 从远程拉取中... 错误：git pull执行失败：退出状态1 remote: 仓库不存在 fatal: 无法访问'https://git.frr.dev/frr/wuwei.git/' 当代码库配置多个remote时（这很常见），Beads可能选错远程仓库。若该仓库不存在或已更名，每次操作都会静默报错。最终issues停止同步，直到下次会话时数据全部消失才后知后觉。 认知损耗 每次Claude Code会话都这样开始： Claude读取Beads提示（通过hooks注入） 尝试启动守护进程 因数据库不匹配失败 Claude尝试bd sync 因远程仓库错误失败 你手动输入"忽略该错误" 终于可以开始工作 六个摩擦步骤消耗着上下文、时间和耐心。 局势转变 两件事让Beads从"带bug的实用工具"沦为"不必要的负担"： 1. Tasks的成熟 当初设计三层架构时，Tasks功能简陋。现在已具备： 支持描述和元数据的TaskCreate 带依赖关系的TaskUpdate 查询功能TaskList/TaskGet 通过CLAUDE_CODE_TASK_LIST_ID实现跨会话持久化 简言之：Tasks现已实现Beads的所有会话内功能，且无需守护进程、SQLite或Git同步。 2. Linear CLI问世 原生的Linear管理控制台(MCP)往好了说也很糟糕——延迟高、稳定性差，总在关键时刻掉链子。 直接调用GraphQL API？理论上可行，直到你需要在issue描述中使用特殊字符： # 尝试1：使用bash字符串插值 # 结果：括号和箭头破坏JSON结构 # 尝试2：Python urllib方案 # 结果：因op read无法在Python环境执行报401错误 # 尝试3：默默流泪 # 结果：情绪宣泄但无实际产出 直到发现linear命令行工具： ...

上周我讲述了我的AI如何凭空编造完整JSON结构并将其封装进DTO、测试夹具和验证测试中的故事。90个测试全部通过，却是一场骗局。 那篇文章是诊断报告。而本文是治疗方案。 发现问题后，我的反应和任何自尊心受损的工程师一样：连续数天疯狂研究防止重蹈覆辙的方法。我阅读论文、测试工具、分析API真实数据，最终为应用构建了一套防御系统。 调查结果让我惊讶：在五类应对措施中，只有三种真正奏效。剩下两种充其量只是"善意表演"。 思维模型：你与AI的对决 在介绍具体措施前，需要先建立认知框架。最好的类比来自深度学习领域： 在**生成对抗网络(GAN)**中存在两个互相竞争的神经网络： 生成器负责产出内容（图像/文本等） 判别器负责鉴别真伪 系统通过两者的对抗持续进化。生成器变得更擅长欺骗，判别器变得更擅长识别。 当使用LLM编程时，你正身处一个非自愿的GAN环境： LLM是生成器。它产出代码、DTO、测试和夹具。 你是判别器。必须辨别真实与虚构的内容。 但存在一个残酷的不对称性：生成器永不疲倦，而你会。LLM可以不费吹灰之力生成50个文件。你检查到第10个就开始疲劳，第11个文件就可能被漏检。 这就是我在1Password每天47次TouchID验证中提到的"授权疲劳"。依赖人类时刻保持警觉的安全措施不过是纸糊的墙。 重点监控边界 你不需要(也不应该)逐行检查。需要重点盯防的是边界——代码与外部世界交互的环节： 边界 核心问题 外部API DTO字段是否真实存在于API？ 依赖包 该依赖是否存在且名称正确？ 数据库表 表结构是否包含这些字段？ URL/端点 端点是否存在且响应合规？ 铁律：LLM对外部世界的任何声明都需验证后再采信。 它说话时的信心程度不能作为判断依据。Anthropic在官方文档中也承认： “Claude有时会生成包含虚构信息的回答…这些回答往往以自信、权威的语气呈现。” LLM说"我确定"和说"我觉得"时，错误的概率其实完全相同。 自动化判别流程 终极目标是摆脱对人为主观能动性的依赖，将验证自动化： 改进前： LLM生成 → 人工抽查 → 合并 改进后： LLM生成 → CI用真实数据验证 → 人工检查差异 → 合并 下文将介绍的五种措施，都是实现这种自动化判别角色的方法。其中有些有效，有些则不尽如人意。 数据实证（致怀疑者） 如果你觉得"这事不会发生在我身上"，请看实际研究数据： LLM推荐的21.7%开源包是虚构的。商业模型降至5.2%（仍意味着每20个就有1个虚构包） GPT-4o针对低频API的有效调用率仅38.58%。比抛硬币的胜率还低 当前最佳代码幻觉检测方法的准确率仅22-33%。换句话说：每四个虚构字段只能抓到一个 研究人员上传了LLM常虚构的空包名。3个月收获3万次下载。业界称其为"垃圾注册"(slopsquatting) AAAI 2025发表的研究CodeHalu将代码幻觉分为四类： 类型 特征 实例 字段映射 字段映射关系错误 混淆user_id和account_id 命名虚构 字段名不存在 使用response.quota.percentage而非真实字段response.utilization 资源虚构 虚构API资源 虚构的active_flags字段 逻辑虚构 看似合理实则错误的业务逻辑 基于虚构字段的判断逻辑isPaid = !activeFlags.isEmpty 我的遭遇正是资源虚构导致逻辑虚构。虚构字段不存在，而依赖它的业务逻辑却天衣无缝。堪称教科书级的"自洽虚构"。 ...

昨天，我发现我的应用程序中有一半的模块是基于虚构的数据构建的。问题还不在于数据是虚构的，更糟糕的是，所有代码都能正常编译，而且90个测试全部通过。 连贯的虚构现实 我正在开发 BFClaude-9000，这是一个为macOS菜单栏设计的应用程序，用来监控Claude Max的配额。其中一个功能需要通过调用 claude.ai 的API来判断某个Claude账户是付费账户还是免费账户。 所以，我请求Claude Code来实现这个功能。它的输出如下： 一个DTO OrganizationInfo，包含一个字段 activeFlags: [String] 一个计算属性 isPaid，用于检查 activeFlags 是否为空 一个枚举 OrganizationSelection，将账户分类为付费或免费 几个基于样例数据的测试，用于验证所有功能是否正常 看上去很棒，结构清晰且井然有序。但这一切全是虚构的。 Claude的真实API中并不存在 active_flags 字段。即使这个字段存在，其作用也完全不符合代码中的假设。当我用自己的付费账户登录时，应用却提示我是免费账户用户。 纸上谈兵的模式 问题并不仅仅是它编造了API中的一个字段，更糟糕的是，它围绕这个谎言构建了一个逻辑完整的系统： // 含有虚构字段的DTO struct OrganizationInfo: Decodable { let uuid: String let name: String let activeFlags: [String] // ← 这个字段并不存在 var isPaid: Bool { !activeFlags.isEmpty } } // 基于虚构字段的逻辑 enum OrganizationSelection { case paid(id: String, name: String) case noPaidOrg // ← 这个状态不应存在 case noOrgs } // 验证虚构逻辑的测试 let paidOrg = """ {"uuid": "abc", "name": "Acme", "active_flags": ["pro"]} """ // 测试通过 ✅ — 但验证的实际上是虚构对虚构 看到了吗？这不仅是一个错误的API字段，而是一个纸上谈兵的构造：DTO定义了一个不存在的字段，业务逻辑依赖该字段，测试用虚构数据验证这个逻辑，也一致验证通过。每个部分彼此确认，从表面来看完全无懈可击，而实际上却毫无真实性可言。 ...