人工智能

我本周发布了六篇文章。一篇关于 PostgreSQL，另一篇关于人工智能代理的，一篇关于上下文管理的教程，一篇自动化的教程，一篇调试案例分析，最后一篇是关于为评估 MVP（最小可行性产品）设计对抗性建议的。 这些并非有计划发布，而是每一篇都从一篇论文、一场演讲，或是一个某种程度上让我感到有趣的项目衍生出来的。可当我将它们汇聚到一起时，却发现了一个自己在写的时候没有注意到的“共同主线”。 这六篇文章说的是一回事。 不经意间发现的模式 最开始是在看 Bohan Zhang 关于 OpenAI 如何扩展 PostgreSQL 的文章得出的结论。这篇文的结尾非常震撼——8 亿用户，只用一个 primary，没有分片。PgBouncer（发布于 2007 年）。只读副本（90 年代的概念）。这世上最无趣的技术，却支撑了历史上应用最广泛的一个服务，至今依旧“仍在很好地运行”。 接着是 Michael Bolin 解析 coding agents（代码代理）构造的文章。不管是 Codex CLI，还是 Claude Code，剖开内部，你会发现它们其实是一个 带 LLM 的 while 循环。没有知识图谱，没有符号规划。有的只是一个循环、一些工具，还有模型决定该停止的时间点。它的“魔法”其实就是一个 while True。 之后是 OpenAI 的关于 上下文工程（Context Engineering） 的 Cookbook 文章。事实是，模型看到的内容比模型本身更重要。而这些技术并不新鲜：启动时注入上下文（相当于一个 README 文档），剪切历史记录（类似循环缓冲区），压缩旧的内容（通过总结）。这些方法早在 2000 年代的聊天系统中就已出现。 然后是那个 自动化教程，更是对此的有力印证：OpenAI 的 Codex Automations 是 cron + curl + 一个 LLM。完全字面意义上就是这样。Unix 系统中最老套的调度器接口，调用当今世界上最前沿的模型。这基础设施已经存在了 40 年，而这“脑袋”才开发了两年。 接着还有两个非基础设施主题的帖子。那个 Jane Street 的谜题 中，一个神经网络有 2500 层，但结果证明它只是一个 MD5。这解法靠的是传统的调试思维：观察数据形式、逐步缩小范围、叠加约束条件，直到剩下唯一可能的答案。工具可能是新的（SAT 解算器，ChatGPT），方法却是老的（有条不紊地假设排除法）。 最后一篇是关于 用对抗性建议评估 MVP 的文章：用 LLM 模拟 5 个专家去评估创意的可行性，这听起来很高科技，直到你发现它其实就是一种 战争推演方法。从 50 年代开始军队就在用了，产品团队也称之为 预死因分析（pre-mortems）。创新之处无非在于，现在只用 2 美元在云端即可串联这些分析，而用不到雇佣 5 万美元的顾问了。 ...

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——法律与监管 他的思维方式不是一个说“不行”的传统律师。他是一个把监管视为架构的法学家。他提出的“四种监管模型”（法律、社会规范、市场和代码/架构）能够分析如何设计一个系统，使监管成为非问题，而不是试图规避它。 ...

几周前，世界上最顶尖的量化交易公司之一 Jane Street 发布了一个关于 解释性机制 的谜题。他们手工设计了一个拥有大约2500层线性结构、使用整数权重的神经网络，并以一个简单的问题把它交给了公众：这个网络到底在计算什么功能？ 答案是：MD5。一个诞生于1992年的密码哈希算法，完全由矩阵运算和ReLU函数以神经网络的形式实现。 问题的精髓并不在答案，而是在最终赢家破解谜题时的过程。本质上，这个过程是一份调试复杂系统的教科书，它的应用远超机器学习领域。 实验背景 这个谜题并非一个典型的“黑盒”问题。参赛者可以获得模型的完整规范：所有的权重矩阵、偏置以及网络架构都公开了。不需要猜测模型的结构，而是需要理解模型 具体在做什么。 网络接受一个文本字符串作为输入，并返回0或1。官方给的例子是：“vegetable dog” 的输出是0。 拥有大约2500层线性结构、约200万个节点、却没有任何文档，这个问题的核心是：输入和输出之间到底是什么关系？ 解题路径：一个调试案例分析 最终赢家 Alex 的解题过程展现了资深工程师常用的调试逻辑。过程中的工具可能因领域不同而有所变化，但思维方式无疑是通用的。 阶段1：观察，而不是立刻动手 Alex 做的第一件事是可视化权重矩阵。他没有直接运行模型，也没有尝试训练它。他只是看了数据。 他的发现是：所有权重都是整数。没有小数，没有浮点数，而是清一色的整数。 这显然是一个重要的信号。使用梯度下降训练的神经网络通常会产生许多小数权重，而整数权重表明这是一个用特定目标手工设计的网络。这不是一个“学习”的模型，而是一个伪装成神经网络的程序。 这告诉我们调试中的第一个关键原则：在解释数据内容之前先观察数据的形状。比如，一个以每100毫秒精确间隔打出的时间戳日志肯定不是来自实际流量；一个JSON对象里的每个字段都精确包含3个元素，也不可能来自生产环境。数据的形状揭示了它的来源。 阶段2：缩小问题规模 Alex 尝试将神经网络转化为一个可满足性（SAT）问题。基本思路是：如果每个神经元都可以看作一个逻辑约束，或许一个SAT求解器能找到让网络输出为1的输入。 他的缩减过程是循序渐进的： 移除了80%的“恒等变换”神经元 合并了只有一个输入且权重为1的节点 压缩了具有相同输入向量的节点 通过这一系列优化，网络从200万个节点缩减到7.5万个节点，最终转化为20万个SAT变量。 但依然没解出来。问题的计算复杂度仍然过高，无法用暴力法解决。 这个阶段带来的重要教训是：正确地简化问题后仍无法解决，这本身也是重要的信息，而不是失败。如果在消除所有“附带复杂度”之后，问题仍然困难，那说明问题的难点是固有的。这一点揭示了它的本质，而在本例中，它的本质是这个函数可能不可逆——我们无法通过输出推断出输入。 阶段3：识别模式 Alex 注意到这个网络中存在一个显著的模式：有32个计算模块周期性地重复出现。32轮完全相同的结构，加上不可逆的性质。 于是他向 ChatGPT 提问：“有哪些密码算法使用32轮计算？” 答案是——MD5。 这是“灵光一闪”的瞬间。但注意，它并不是无来由的突发奇想，而是三个前期资料（整数权重 → 手工设计、不可逆 → 加密算法、32轮 → 特定密码协议）的合并推理，最终形成了一个可验证的假设。 这种模式——通过不断加入约束，直到可能性空间逐渐收敛，与资深工程师在生产环境中诊断问题的方法高度一致。资深工程师并不是提前知道答案，而是通过每一步观察逐步排除整个可能性类别，直到只剩下一种可能性为止。 阶段4：发现问题 接下来的步骤中，Alex 验证了自己的假设：他计算了几组输入的MD5值，并与网络输出进行对比。结果显示，网络输出与MD5哈希值完全一致，当输入长度不超过32字符时。 但是，当输入长度超过32字符时，网络的计算结果就出现了偏差。 这是因为网络中存在一个bug。设计者在处理输入长度编码时出现了错误——在前7层中发生了一个溢出错误，使得网络在处理长输入时与标准MD5的输出结果不同。 Alex 一层一层地追踪错误，直至找到确切的偏差点。 这是一个绝佳的案例：在边界条件下验证假设。如果你的心理模型认为“这个神经网络在计算MD5”，那么仅仅在理想情况下（短输入）验证它是不够的。必须在极端条件下（长输入、空输入、特殊字符）对其进行测试。而当它失败时，这些偏差往往正是定位问题的关键线索。 阶段5：成功破译 最终，确定这是一份具有已知bug的MD5函数后，Alex 提取出了倒数第二层中的目标哈希值偏置项。接着使用词典暴力破解法，找到了谜底——两个用空格分隔的英文单词。 这对调试的启示 Alex 的解题过程与机器学习本身关系不大，它本质上是一场关于调试的教科书式行动： 阶段 在谜题中的体现 在实际调试中的体现 观察形状 整数权重 → 手工设计 日志间隔均匀 → 合成数据 缩小问题规模 200万节点 → 7.5万节点 → SAT问题 完整堆栈轨迹 → 具体组件 累积约束 不可逆 + 32轮 → 加密算法 只在生产中失败 + 只发生在周一 → 定时任务 边界验证 短于32字符可行，长于32字符失败 → 溢出 ASCII正常，UTF-8失败 → 编码问题 利用错误找线索 溢出问题定位到具体层 堆栈追踪定位至具体行 结构完全一致，差异只是领域不同而已。 ...

“我有一个 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 状态码的页面。 ...

“你知道 Rust 最棒的一点是什么吗？它不会允许你编译粗制滥造的代码。你知道最糟糕的一点是什么吗？起初你写的所有代码都是粗制滥造的。” —— 蟹老板，大概是这样说的 比一个 AI 代理更好的是什么？是一个用 Rust 重写 的 AI 代理。 如果你上网超过五分钟，就会知道这个梗。不管是什么项目：文本编辑器、DNS 服务器、BMI 计算器，总会有人跳出来评论“你应该用 Rust 重写它”。这就是 Rewrite It In Rust —— 简称 RIIR，和地心引力一样不可避免的存在。 好吧，那我就来做一次真的。我将把一个有 8,300 行代码的 Python AI 代理移植到 Rust。但不是因为这个梗在召唤我（嗯…有一点是因为它）。我这么做，是因为我需要一个实验对象。 论点 最近几周，我一直在写关于静默失败、五种防止幻觉的方法、以及"一个 LLM 如何生成看似正确但实际上错误的代码"的文章。我甚至还给它起了个名字：对抗性开发。永远不要相信，总要验证。 很多理论，是时候实践了。 于是，我需要一个项目，满足三个特点：范围适中（而不是一个需求会不断变化的新应用）、明确的真相来源（现有可用的 Python 代码）、以及足够的复杂度，让 LLM 的幻觉能“藏起来”。一个纯粹的移植可以完全满足这三点。输入和期望输出已然存在。如果 Rust 版本的行为和 Python 的不完全一样，那肯定有问题。就是这么简单。 既然要做移植，那为什么不顺便真正学学 Rust 呢？借用检查器 (borrow checker)、所有权 (ownership)、生命周期 (lifetimes)… 我读了好几年资料，却几乎没有亲自实践过。如果是写一个真实项目而不是第 N 次看教程，一切或许会大不相同。 目标对象 它的名字叫 nanobot。这是一个基于 OpenClaw 开发的个人 AI 代理。它能将各种 LLM（如 Claude、GPT、DeepSeek）接入聊天渠道——Telegram、Discord、Slack、电子邮件——并赋予它们更多功能。比如读取和编辑文件、执行命令、网络搜索、通过 cron 编排任务，甚至在对话之间保存记忆。 它可以正常工作。而且已经运行了几个月。在 Python 上。 问题呢？它是单线程的。一次只能处理一条消息。如果你连续发送三条信息，它会像周六中午的超市购物队伍一样排队等待。它的内存消耗约为 50MB，而它实际上只是在不同的 API 之间传递 JSON。此外，它的错误处理方式令人羞愧：到处都是return f"Error: {str(e)}"。 ...

我妻子召唤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 同步。听起来很合理。但实际上： DATABASE MISMATCH DETECTED! This database belongs to a different repository: Database repo ID: d1f9ca0c Current repo ID: 01eac8ea ⚠️ CRITICAL: This mismatch can cause beads to incorrectly delete issues during sync! 每次启动会话都会看到这条消息。守护进程崩溃，同步崩溃，然后你就陷入了一种量子态：issues 存在于你的本地 SQLite 中但不在 git 里，或者反过来。你的 issues 同时存在又不存在。 ...

单一checkout的瓶颈 我正在开发一个macOS菜单栏应用。我有三个功能在待办清单中：一个消耗量的迷你图表、原生通知和一个桌面小组件。这三个功能都是独立的。我打算用Claude Code来完成这三个功能。 问题是：Claude Code在一个目录中工作。一个目录有一个分支。而git checkout就像一个单车道的环岛：一次只能通过一个。 如果我想同时推进这三个功能，我的传统选择是： Stash乒乓球：git stash，切换分支，工作，git stash pop，祈祷没有冲突。重复直到发疯或退休，看哪个先到。 克隆仓库三次：可以工作，但现在我有三个.git/副本，三个独立的历史记录，每个都要执行git fetch。浪费。 接受串行生活：一个功能接着一个功能。安全，可预测，但慢得像手动归并排序。 都不好。但有第四个选择，自2015年以来git就有了，但几乎没人使用。 Worktrees：你已经安装的解决方案 一个worktree是第二个工作目录，共享同一个.git仓库。没有副本，没有克隆，没有黑魔法。 比喻：你的仓库是一个图书馆。到目前为止你有一张桌子，只能打开一本书。worktree是放更多桌子。每张桌子都打开着不同的书，但都从同一个书架取书。 ~/code/miapp/ ← 桌子1 (main) .git/ ← 图书馆（只有一个） ~/code/miapp-sparkline/ ← 桌子2 (feature/sparkline) .git ← 文件，不是文件夹（指向图书馆的指针） ~/code/miapp-notificaciones/ ← 桌子3 (feature/notifications) .git ← 另一个指针 每个目录都是一个完整的checkout，包含所有文件。你可以在一个中编译，在另一个中运行测试，在第三个中让你的AI助手工作。同时进行。 创建只需一行命令 从你的主仓库： 1 2 git worktree add ../miapp-sparkline -b feature/sparkline git worktree add ../miapp-notificaciones -b feature/notifications 就这样。两个新目录，每个在自己的分支上，共享整个git数据库。不需要克隆，不需要配置远程，不需要复制历史记录。 它们共享什么，不共享什么 这很重要。worktrees共享整个仓库：提交、分支、标签、远程、钩子、配置。如果你在sparkline的worktree中做了一个提交，你可以立即从notifications的worktree中看到它，不需要fetch或任何操作，因为它们是同一个数据库。 它们不共享： 磁盘上的文件（每张桌子都有自己的工作副本） 暂存区（每个都有自己的git add） HEAD（每个指向自己的分支） 简单来说：“我正在处理什么"的状态对每个worktree是私有的。其他一切都是公共的。 ...

上周我分享了AI如何编造了一个完整的JSON结构，并用DTO、固件和测试对其进行包装。90个测试全部通过。全是假的。 那篇文章是诊断。这篇是治疗。 发现这个灾难后，我做了任何自尊心受挫的工程师都会做的事：连续数天疯狂研究，确保不再发生。我阅读论文、试用工具、分析应用API的真实数据，并为我的应用构建了一套防御系统。 我的发现令人惊讶。在我识别的5种应对措施中，只有3种真正有效。其他两种充其量是善意的表演。 思维模型：你与AI的对抗（字面意思） 在深入这些措施之前，你需要理解框架。我找到的最佳类比来自深度学习。 在GAN（生成对抗网络）中，有两个神经网络在竞争： 生成器产生内容（图像、文本等） 判别器试图检测内容是真实的还是虚假的 系统之所以改进，是因为两者相互推动。生成器学会更好地欺骗。判别器学会更好地检测。 当你与大语言模型编程时，你就处在一个无意的GAN中： **大语言模型是生成器。**它产生代码、DTO、测试、固件。 **你是判别器。**你必须检测什么是真实的，什么是编造的。 但存在一个残酷的不对称：生成器不知疲倦，而你会疲劳。大语言模型可以不费力地生成50个文件。你检查10个就累了，第11个文件就不看了。 这就像我在1Password一天要求Touch ID 47次中提到的授权疲劳。依赖人类永远保持警觉的安全就是纸板安全。 判别器应该监控什么 你不能（也不应该）检查每一行。你需要监控的是边界——你的代码接触外部世界的地方： 边界 关键问题 外部API DTO中的字段在真实API中存在吗？ 包 依赖项存在并且名称正确吗？ 数据库模式 表真的有这些列吗？ URL/端点 端点存在并返回我们期望的内容吗？ **原则：大语言模型对外部世界的所有声明在验证前都是可疑的。**它说得很自信并不是证据。Anthropic在自己的文档中承认了这一点： “Claude有时会生成包含虚假信息的响应…以自信、权威的方式呈现。” 一个说"我确定"的大语言模型和一个说"我认为"的大语言模型犯错的概率完全相同。 自动化判别器 最终目标是不再依赖你的纪律性，而是自动化验证： 之前： LLM生成 → 你审查（有时） → 合并 之后： LLM生成 → CI对真实数据验证 → 你审查差异 → 合并 接下来的5种措施是自动化判别器角色的方法。有些有效。有些不太行。 硬数据（给怀疑者） 在你认为"我不会遇到这种情况"之前，这里是真实研究的数字： **21.7%**的开源大语言模型推荐的包是编造的。在商业模型中下降到5.2%，仍然是每20个包中有一个。 GPT-4o对不常见API只能达到**38.58%**的有效调用率。不到40%。还不如抛硬币。 目前定位代码幻觉的最佳方法只能达到22-33%的精度。换句话说：我们能检测出四分之一。 一位研究人员上传了一个空包，包名是大语言模型经常幻觉的。3个月内3万次下载。他们称之为slopsquatting。 而且有正式的分类法。CodeHalu论文（AAAI 2025）定义了4类代码幻觉： 类别 定义 真实例子 映射 字段映射错误 混淆user_id和account_id 命名 编造的名称 response.quota.percentage实际是response.utilization 资源 不存在的资源 API中没有的active_flags字段 逻辑 看似合理但错误的逻辑 isPaid = !activeFlags.isEmpty但字段总是空的 我的案例是资源类型转化为逻辑类型。字段不存在，但依赖它的逻辑看起来完美。连贯的虚构小说。 ...

昨天我发现我的应用程序中有一半模块基于的是编造的数据。不是因为某个迷糊的初级开发者，而是我的AI。 最糟糕的不是它编造了内容。最糟糕的是所有代码都能编译，90个测试全部通过。 连贯的虚构 我正在构建BFClaude-9000，这是一个macOS菜单栏应用，用于监控Claude Max的配额。该功能的一部分需要通过调用claude.ai的API来区分Claude账户是付费还是免费。 我让Claude Code实现了检测功能。它实现了。它交付给我： 一个包含activeFlags: [String]字段的OrganizationInfo DTO 一个检查activeFlags是否非空的计算属性isPaid 一个将组织分类为付费和免费的枚举OrganizationSelection 带有验证所有功能正常工作的测试数据的测试 漂亮。简洁。结构良好。全是编造的。 active_flags字段在Claude的真实API中根本不存在。或者如果存在，也不像代码假设的那样工作。当我用付费账户登录时，应用告诉我我的账户是免费的。 纸牌屋模式 阴险的不是它撒谎说API有某个字段。而是它围绕这个谎言构建的完整系统： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 带有编造字段的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"]} """ // 测试通过 ✅ — 但这是在验证虚构对虚构 你看到了吗？这不是一个字段放错了位置。这是一个纸牌屋：DTO定义了一个虚假字段，逻辑依赖这个字段，测试验证逻辑使用同样虚假的测试数据正常工作。每个部分都在确认其他部分。一切都说得通。没有什么是真实的。 ...