观点

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

每当有大公司的基础设施相关文章发布时，Hacker News 上总会出现一堆评论，内容大多是这样的变体：“当然了，他们用Kubernetes撑起了47个微服务，还加了一套自主开发的分布式共识协议数据库。”然而，当真相是他们只是用单纯的PostgreSQL主库和一点使用规范支撑其业务时，评论区就会陷入一片尴尬的沉默。 这次，OpenAI就再次打了这样一个大脸。 超出所有人想象的数字 OpenAI基础设施工程师Bohan Zhang刚刚分享了他们如何用PostgreSQL支持ChatGPT的具体细节。令人惊讶的数据如下： 8亿用户 单一PostgreSQL主库（写入操作专用）部署在Azure上 ~50个只读副本 每秒百万次查询 p99延迟仅10-19毫秒 99.999%的可用性 一年内仅出现一次SEV-0事故 （而且还是因为ImageGen产品的病毒式传播，让一周之内新增了1亿用户） 再读一遍。一个。主库。支撑8亿用户。 “可是他们为什么不分片？” 不需要。背后的原因非常简单而务实。 给PostgreSQL分片需要改动数百个应用的端点。每一个默认假设所有数据都在同一个数据库查询——基本是所有查询——都需要重写，来判断每个数据属于哪个分片。 这么迁移需要付出的成本呢？是数月的工作量、新的bug层出不穷，再加上一个混乱的迁移过渡期——同时需要维护老旧和新系统。 于是他们采用了另一种方式：识别最占用写入负载的数据，然后将其移至Cosmos DB。而这样做的原因并不是因为Cosmos比PostgreSQL更好，而是因为这些特定的工作负载更适合文档数据库模型。而其他大部分业务逻辑依旧保留在PostgreSQL中。 用大白话说：他们没有让整个系统变复杂，而是精确识别出问题所在，并有针对性地解决它。精密手术刀式的调整，而不是拿电锯一通乱砍。 PgBouncer：将连接延迟从50毫秒降到5毫秒 他们遇到的第一大瓶颈是建立连接的延迟。PostgreSQL会为每个新连接创建一个独立进程。而随着来自成百上千个应用Pods的并发连接数增加，光是处理新连接的开销就已达到50毫秒——甚至还没开始执行查询呢。 他们的解决方案是：使用PgBouncer作为连接池。PgBouncer会维护一个已经建立好的连接池，复用这些连接。结果是连接延迟从50毫秒降至5毫秒，直接减少了90%的延迟。仅仅通过更换一项底层工具，问题就得到了解决。 值得提到的是，这根本不是什么新技术。PgBouncer已经有15年以上的历史，并一直被各种规模的企业用于生产环境中。然而，它再次证明，一款久经考验的不起眼的工具，解决了这个地球上使用最频繁应用之一的问题。 那个做了12个表联接的ORM 这个问题是我的最爱。我见过它出现在学生的项目、初创公司，甚至银行的系统里。到处都有。 他们的ORM生成了包含12个表联合查询(join)的SQL语句。罪魁祸首并不是哪个设计人员，而是因为数据模型过于复杂且关系交织，ORM顺着这些关系“不假思索”地将每个可能的相关表都加载了进来。 解决办法既不是换ORM，也不是手动改写所有的查询。他们选择了将一些逻辑转移到应用层。与其让PostgreSQL执行一个庞大的join操作，他们分拆成多个简单查询，然后用代码对数据进行整合。 这么做优雅吗？的确没那么优雅。速度快吗？快得多。因为PostgreSQL处理简单查询比处理含有交叉条件的12表联合查询高效得多。而且，部分结果还能进行缓存和复用。 -- 之前：ORM生成的SQL SELECT u.*, p.*, s.*, t.*, ... FROM users u JOIN profiles p ON ... JOIN settings s ON ... JOIN teams t ON ... JOIN ... -- 总计12个表 WHERE u.id = $1; -- 之后：语句被拆分，逻辑移到应用层 SELECT * FROM users WHERE id = $1; SELECT * FROM profiles WHERE user_id = $1; -- 可缓存、可并行、可调试 每一条单独的查询都很简单。查询解析器几微秒内就可以完成。并且一旦其中有一条失败或者变慢，你可以直接找到问题所在。 ...

几周前，世界上最顶尖的量化交易公司之一 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失败 → 编码问题 利用错误找线索 溢出问题定位到具体层 堆栈追踪定位至具体行 结构完全一致，差异只是领域不同而已。 ...

几周前我写了一篇文章，解释了为什么你发给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中启用缓存。如果不这样做，从经济角度看是不可行的。 ...

Claude Code 提供了一个名为 /simplify 的 slash command，可以自动审查你的代码。我用它检查了一个大幅变更——大约 8 个文件、500 行代码——结果让人有些意外。它确实发现了些我可能漏掉的点，但也带来了不少无用信息，让我浪费了不少时间。 所以我把它拆解了，然后又重新像拼图一样组装回来。 /simplify 是如何工作的 这是 Claude Code 内置的一项功能（无需额外安装）。它会并行运行三个代理，分别从三个不同的角度来审查代码变更： 代码复用（Code Reuse） —— 是否有可以替换新代码的现有工具？ 代码质量（Code Quality） —— 冗余状态、复制粘贴、不良抽象、stringly-typed code 等。 效率（Efficiency） —— 不必要的 I/O、未充分利用的并发、内存泄漏等。 这三个代理会各自给出发现的问题，之后系统尝试直接修复它们。 找到的亮点 代码复用代理发现我在测试代码的两处重复了一个完全相同的辅助函数：相同的名字、相同的代码内容，但分布在两个不同的文件中。我把它提取到一个共享模块里，干净利落。 效率代理指出了一个处理循环中不必要的磁盘操作：每次迭代都加载状态、修改后存储、读取数据、重新加载、再存储。写操作重复了两次，而实际上只需要一次。我没注意到这些隐患，但工具发现了。 还发现了一个内存缓冲区在错误路径中没有清除。如果在分配和释放之间发生错误，会产生内存泄漏。这种问题在主路径上已经被处理到了，但显然 copy-paste 草率遗漏了某些细节。 到这里为止，还算满意。三个发现，全都合法且可操作。但 /simplify 的问题并不在于它发现了什么，而是在于它发现了太多不重要的东西。 存在的缺陷 低级别的问题噪音过多。 它建议我删除一个 struct 的字段，因为 “它与一个计算属性是重复的”。这个字段占用 8 个字节，但被代码和测试中的十多处引用使用。做这个改动带来的代码修改工作量，远远超过了省下这几个字节的好处。 缺乏对项目上下文的理解。 它标记了一个并发模式为 HIGH 严重性，并且的确指出这是一个潜在风险。这一点没错，书面上看是合理的。但实际上，这个问题已经在项目的 CLAUDE.md 文档中记录了，工具链中专门配置了 lint 来应对，并且项目内还有一个相关的 issue 在处理。而 /simplify 并不知道这些，因为它只能基于代码变更的 diff 操作，缺乏项目整体的视角。 无法分辨“错误”和“可优化”。 上文提到的双磁盘操作的确效率低下，但并不是错误。而并发模式的问题就是真正的潜在炸弹。这两者的严重性却都被标记为 MEDIUM，优先级看上去一样，这种扁平的优先级划分很难起到实际帮助。 对外部数据强行推荐 enums。 它建议把某些 DTO 中的字段从字符串转换为枚举，但这些字段只是从外部 API 拉取后用于显示。把它们改成枚举需要自定义解码逻辑，却提供不了任何实际好处——如果对方 API 增加了新值，这样的枚举反倒会导致解析出错。枚举在这种情况下，不如保持字符串更稳妥。 ...

几个月来，我一直用自制的 cron 来执行 Claude Code 的任务。一个 Bash 脚本启动一个 headless 会话，给它一个 prompt，等待任务完成后关闭。它能运作，虽然运作得勉强，但能用。如果有需要，我把代码放在 GitHub 供大家参考。 而上周五，Anthropic 发布了 2.1.71 版本，引入了 /loop。一个原生的调度器，就直接内置在 Claude Code 会话中。 我的第一反应是：“我的项目凉了。” 试用之后的第二反应是：“嗯…还没死，但离死不远了。” /loop 的功能 语法相当简洁： /loop 5m check the deploy status 这个命令告诉 Claude Code：“每 5 分钟，执行这个 prompt 一次。” 不需要退出会话，也不需要 cron，也不用脚本。Claude 来解析时间间隔，安排任务，并在会话仍然开启且处于 *空闲* 状态时执行它。 你可以串联多个斜杠命令： /loop 20m /review-pr 1234 /loop 1h make test 2>&1 | tail -5 每个 loop 都有一个“安全网”：三天后它会自动到期。如果你曾经留下一个忘记关闭的 cron，你大概能理解这种设计有多贴心。 ## 我会如何使用它 试用一天后，我已经发现了三个明确的用途： **1. 在开发过程中监控测试。** 现在我正在 Tokamak 上实现一个重要功能（比如冷启动的五个优化阶段）。与其每次修改一点代码就运行 `make test`，不如直接这样做： /loop 10m make test 2>&1 | grep -E “passed|failed” ...

上周，我在用 Instruments 工具对一个 Swift 应用进行性能分析。没什么稀奇的：运行 xctrace record，再运行 xctrace export，然后把导出的 XML 拷贝到 Claude Code 的上下文，让它帮忙分析热点。 结果 Claude 跟我说："XML 文件太大，无法可靠地处理。" 33,553 行 XML，只为分析一个只有两个函数的程序。 真正的问题 xctrace export 是一个很棒的工具。它什么都给你：每一个采样点、每一个调用栈、每一帧的二进制信息、内存地址、UUID，简直面面俱到，精准无比，完美无缺。 但问题，也正是源于它的完美无缺。 对一个应用程序进行性能分析时，我并不需要所有的 3,044 个细节采样点。我不需要知道第 1,847 个采样点在 00:02.847.882 捕捉到了 libswiftCore.dylib 内存地址为 0x1027ec9a8 的内容。我只需要知道 heavyWork() 花掉了 70% 的时间，而 lightWork() 只用了 30%。 用大白话来说：我需要的是 10 行总结，而不是 33,000 行繁文缛节。 为什么 XML 格式是正确的选择（但噪音不可取） 在有人提出“2026 年了还用 XML 才是问题”之前——并不是这样。 XML 对于 xctrace 的功能来说，是非常理想的格式。试想一下： 层次结构：一个调用栈是一个框架的树状结构。一个采样点包含了一个调用栈，一个线程，一个进程。XML 自然而然地可以建模这些内容。 自描述性：每个元素都有名字、带类型的属性，并且结构可以被验证。你不用去猜 CSV 第七列的内容代表什么。 优雅的去重：xctrace 使用了 id 和 ref 系统，首次定义一个框架时是这样的：id="59" name="heavyWork()"，后续只需引用 ref="59"。可以看作是一种序列化的 flyweight pattern。 可以用标准工具解析：XPath、xmllint、xml.etree.ElementTree…… 不需要专属解析器。 xctrace 的 XML 格式并不是冗余。它是 Instruments 所需的结构化信息，用来重建交互式调用树、对比运行情况，以及按线程和进程进行筛选。它是专门为一个可以展开和折叠节点的 GUI 工具设计的。 ...

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

2026 年 2 月 25 日，Anthropic 宣布了针对 Claude Code 的 Remote Control 功能。构思是这样的：你在终端启动 Claude Code，然后拿着手机躺在沙发上，通过 claude.ai 继续你的会话。无需 SSH。无需 tmux。也不需要远程终端窗口。 听起来很酷，对吧？ 但实际上，当我在终端输入 /rc 激活后，它给了我一个 URL。我打开手机，登录进去… 然后 claude.ai 提示我 “this feature is not active in your organization”（此功能尚未在您的账户中启用）。2026 年 2 月，我订阅的是 Max 5x 账户，每月按时付款。但什么都没用。 于是，我决定做任何理性人都会做的事：反编译 API，弄清楚后台到底发生了什么。 什么是 Remote Control（官方说法） 本质上：它是一个连接本地 CLI 和 claude.ai 网页的桥梁。Claude Code 的 CLI 仍在你的机器上运行（可以访问你的代码、终端和文件），但你可以通过任何浏览器查看它、批准 tool calls，并发送消息。 Anthropic 将它作为一项 “research preview"（研究预览）推出，仅面向 Max 用户。官方的期望是，你可以启动一个长任务（/rc + 提示词），关上笔记本电脑，去健身房，然后通过手机查看任务进度。 然而，正如我们接下来要讨论的，现实要微妙得多。 我们发现的底层真相 当你运行 /rc 时，Claude Code 会在后台做很多事情。而且，这些行动会留下大量的痕迹——在 JSONL 文件中、在 debug logs 里、在 API 响应里。让我们逐一拆解。 ...