TL;DR：AI 让生成文字的成本趋近于零，但读的人寻找重点、补背景、查事实的时间反而增加了——BetterUp Labs 与 Stanford 社交媒体实验室 2025 年 9 月的调查把这类低质量“AI 撑量”内容称为 workslop。问题不在“用了 AI”，而在内容没有目标、缺少上下文、无人为结论负责；Rick Manelius 的 AI;DR 框架建议发件人为内容附上核验信息。

AI 把写一封长邮件、做一份汇报的时间压缩到了几分钟。文字更多了，信息却不一定更多。发送者省下来的起草时间，可能变成接收者寻找重点、补背景、查事实和猜任务的时间。

让人厌烦的并不是某个标点，也不是“用了 AI”这件事本身。真正的问题是：一份内容没有清楚目标、没有必要上下文、没有核验，发件人也不愿为结论负责。AI 只是在极低成本下，把这种旧问题放大了。

🎬 视频版（B站） ｜ 🎧 音频版（6 分 34 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

AI;DR 是态度，不是检测器

TL;DR 的意思是“太长，没读”。AI;DR 则是“AI 写的，没读”。Manelius 的规则很直接：如果发送者不愿检查和编辑 AI 输出，他也不愿花时间阅读。

原文并不反对用 AI 找想法、列提纲或润色，也承认客服等场景适合高度自动化。它针对的是另一种行为：把一整面未经筛选的模型输出发给同事、读者或客户，让对方替自己找重点。

这是一条个人的阅读政策，不是判断内容质量的实验方法。它表达了真实的不满，却不能证明某段文字由 AI 生成，更不能据此认定作者偷懒。

《听懂 AI》第 012 期节目封面。判断内容质量，应看信息和责任，而不是猜文风。

别用破折号和三段式猜作者

HN 讨论里最有力的反驳之一，是“你怎么知道它是 AI 写的”。有人本来就写得正式，有人用 AI 只改语法，有人不是母语使用者。破折号、规整小标题和某些套话，都不是可靠证据。

编辑、翻译软件和职业写手存在了很多年。工具参与文字生产，没有天然的道德分界线。真正需要判断的是成品：它有没有明确目的，事实有没有来源，作者能不能解释结论，对方为什么需要读。

如果内容准确、简洁、适合场景，而且作者愿意负责，AI 参与了多少并不是首要问题。反过来，一篇完全由人手写的长文也可能空洞、含糊、浪费时间。

Workslop 调查测到了什么

BetterUp 把“外表完整、实际缺少有效内容的 AI 工作产物”称为 workslop。其公开页面称，BetterUp Labs 与 Stanford Social Media Lab 在 2025 年 9 月在线调查了 1,150 名美国全职办公室员工：40% 的受访者说过去一个月收到过 workslop；他们估计每次处理平均花费约 2 小时；研究方换算为每名员工每月 186 美元的成本，并进一步推算一家万人公司每年约 900 万美元。

这些数字适合说明问题值得关注，不能直接当作“AI 已经让每家公司损失这些钱”。它是一项在线自报调查，不是随机实验，也不是研究者进入企业逐项计时。受访者如何识别 AI、怎样回忆处理时间、哪些低质量工作原本就会发生，都会影响结果。

公开页面来自提供企业服务的 BetterUp，页面本身也推广其产品。引用这些结果时，需要保留样本、测量方式和商业背景，不能把估算写成普遍因果。

思考没有消失，只是换了人做

一份真正可用的工作材料至少要完成几件事：明确目的，选择相关信息，核对事实，结合项目背景，说明希望接收者做什么，并由一个人承担结论责任。

AI 可以帮助其中很多步骤，却不会自动替发送者完成判断。如果提示词只有一句含糊要求，模型仍能生成结构完整的长文。外表越像成品，发送者越容易误以为工作已经结束。

接收者随后要重新提炼结论、寻找任务、检查数字、补上下文。AI 节省的是发送者眼前的时间，增加的却是团队总阅读成本。文字生产效率提高，并不等于沟通效率提高。

披露“用了 AI”会不会先被嫌弃

Sue Lim 与 Ralf Schmälzle 的两项研究考察了 AI 来源披露如何影响电子烟预防信息的评价。第一项研究预先注册，结果显示来源标签会影响评价，但没有显著改变消息排序；第二项研究发现，参与者对 AI 的负面态度会调节评价，却没有调节最终选择。作者把整体结果概括为对 AI 生成消息的轻微负面偏好。

研究场景是短小的健康宣传信息。研究最初在 2023 年以预印本提交，现有 arXiv 页面已经关联 2024 年的期刊 DOI。它不能证明工作邮件只要标注 AI 就会被拒绝，也不能说明长篇文章的阅读行为。

这项研究更像一条提醒：读者会根据来源推断作者投入、意图和可信度。因此，披露不应只是贴一个“AI 生成”标签，还要让读者知道人做了哪些核验、哪些结论由谁负责。

发送前，把四件事留在人手里

图中是沟通责任框架，不是对 AI 使用比例的评分标准。

第一，先写目的。希望对方知道什么、决定什么、做什么，最好在开头一句话说清楚。

第二，亲自编辑。删除重复和“放在哪里都对”的句子，补上只有你知道的项目背景，把结论和请求提前。

第三，逐项核验。数字、引用、时间、承诺和外部链接都要能追溯；AI 帮你整理了资料，就把关键来源一起交出来。

第四，承担结论。对方追问时，你应该能不用再问 AI，就解释这份材料为什么成立、哪里仍不确定、下一步谁负责。

收到一大墙文字，怎样把责任送回去

直接回复“AI;DR”很痛快，也容易误伤认真写作的人。更有效的做法是不争论它是不是 AI 写的，而是问具体问题：

1. 请用一句话说明希望我做什么。
2. 这几个关键结论分别依据什么？
3. 哪些内容已经核验，哪些仍是假设？
4. 最终决定和后续解释由谁负责？

这些问题能迅速区分“借助 AI 后完成了判断”和“把模型输出直接转交”。即使文章完全由人写，也同样适用。

团队该管使用比例，还是管交付标准

规定“AI 只能写 30%”很难执行，也容易把讨论引向不可验证的文风猜测。更可操作的是定义交付标准：重要结论要有来源，决策材料要有明确请求，高风险内容要有人复核，发送者要能回答追问。

团队也可以约定适合高度自动化的场景，例如格式转换、初步分类和常见客服；对于战略判断、客户承诺、法律或安全内容，则提高核验和审批要求。标准跟风险走，不跟某个标点或写作风格走。

AI 能降低起草成本，但不能降低作者责任。真正有价值的不是“我生成了多少页”，而是“对方读完后能少猜一点、少查一点，并知道下一步该做什么”。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 012 期整理而成。本期并非基于单一论文：Rick Manelius 于 2026 年 8 月 17 日发表的《AI;DR (AI; Didn't Read)》是一篇个人评论；BetterUp Labs 与 Stanford Social Media Lab 的 workslop 页面给出一项 2025 年 9 月在线自报调查；Sue Lim 与 Ralf Schmälzle 的来源披露研究关注电子烟预防短消息，与工作邮件或长文不是同一场景；Hacker News 只作为社区讨论。本文会分别说明观点、调查和实验能支持到哪里。

1. Rick Manelius，2026-08-17：AI;DR (AI; Didn't Read)——本期的主要评论文章；表达个人阅读政策，不是 AI 文本检测研究。
2. Hacker News：AI;DR (AI; Didn't Read)——社区对阅读成本、AI 文风误判、编辑工具和作者责任的讨论；评论只代表参与者观点。
3. BetterUp Labs：Workslop: The Hidden Cost of AI-Generated Busywork——1,150 名美国全职办公室员工的在线自报调查摘要；页面同时带有 BetterUp 产品推广。
4. Sue Lim、Ralf Schmälzle，arXiv:2311.15544v2：The effect of source disclosure on evaluation of AI-generated messages: A two-part study——电子烟预防短消息的来源披露研究，不能直接外推到工作邮件或长文阅读。

资料说明：本文依据 2026 年 9 月 2 日可见资料整理。AI;DR 与 workslop 是用于讨论沟通现象的概念，不是判断某段文字是否由 AI 生成的技术标准。

TL;DR：低价 token 转售市场的折扣可以深至两三折，但便宜的部分往往对应被隐藏的风险：额度来源不明、请求经过中间商、后台模型可能与宣传不符、账号被封后无人退款。这一分析来自 Vectoral 的 Matt Lenhard 2026 年 8 月 10 日发布的《Who Are the Token Brokers?》——对每天批量调用模型的团队，折扣越深，越需要核验证据。
🎬 视频版（B站） ｜ 🎧 音频版（7 分 11 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

同一个模型、兼容同一套 API，一家按官方价收费，另一家便宜 40%，甚至只要两三折。对于每天批量跑分类、摘要、代码或 Agent 的团队，这不是小数目：模型费可能直接决定毛利率。

问题在于，调用价格只是交易中最容易看到的一项。额度能不能转让、请求经过谁、后台究竟调用了哪个模型、账号被封后谁退款，这些信息通常藏在代理接口背后。折扣越深，买家越需要证据，而不是更动听的解释。

先分清经纪人和中转站

Token broker 可以理解为“额度经纪人”。一些创业公司拿到云厂商或模型公司的推广额度，自己用不完、临近过期，于是尝试折价换成现金。经纪人负责寻找这些额度，再把用量卖给需要推理服务的团队。

Relay 是中转站。买家把 SDK 的接口地址改成中转站，中转站再从自己的账号、密钥或账号池里选一条通道，将请求发给上游。经纪人解决“货从哪里来、卖给谁”，中转站解决“请求怎样走”；两种角色经常由同一家公司承担，但不是同一个概念。

合法云市场、获授权的经销商和企业自建网关也会代理请求。是否经过代理不是判断好坏的标准。真正要问的是：运营主体是谁，上游是否授权，额度是否允许转让，数据如何处理，服务中断由谁承担。

《听懂 AI》第 011 期节目封面。节目讨论的是采购证据，不是把所有非官方渠道一概视为欺诈。

原文实际看到了什么

Lenhard 的文章提供了几类可直接核对的材料：创业者收到的推销信息；作者向经纪人发出的联络邮件；一位卖家声称每天可提供 10 万美元用量的聊天记录；交易站点上 30% 到 80% 的折扣；以及作者自己提交后仍处于审核状态的额度挂牌。

这些材料能证明“有人公开宣传并撮合这类交易”，不能自动证明所有挂牌都已成交、所有卖家都有所称额度，或每天 10 万美元的供应已经过稳定性验证。

原文说市场中可能有“数千万”额度正在被叫卖。作者后来在 HN 里澄清，指的是美元金额，不是数千万个 token；这个数字仍是他根据所见站点、论坛和卖家的粗略估计，不是审计后的成交额。

类似地，作者认为 40% 的统一折扣不像普通批量采购价，并猜测供应可能来自其他方式。前半句是行业判断，后半句是作者明确标注的猜测。文章没有因此查明某家服务的具体资金来源。

低价不是欺诈证据，但会增加举证责任

折扣可能有正当来源：供应商授权价、区域定价、企业包量合同、即将到期的合法权益，或卖家主动补贴获客。只看价格无法排除这些可能。

折扣也可能来自合同不允许转让的推广额度、订阅套利、账号池，甚至上游文章记录的免费额度滥用、拒付和盗刷。后一组说法的证据强弱并不相同，也不能套到每个中转站。

HN 上有人推测中转站会记录数据、偷换模型或使用来路不明的密钥，也有人质疑原文没有给出足够证据。这些评论适合提醒买家要查什么，不适合改写成“行业普遍如此”的事实。

实用的判断不是“便宜必然有鬼”，而是让卖家解释折扣，并用合同、授权和账单证明解释成立。价格越偏离公开价，所需证据就应越具体。

有额度，不等于有权转售

推广额度通常附带使用限制。AWS 现行 Promotional Credit 条款明确写明，不得出售、许可、出租或转让额度，额度原则上只能用于自己的 AWS 账户；Google Cloud Startups Program 的激励也规定不可转让、出售、购买或交换。两家都保留在滥用、欺诈或违反条款时撤销额度的权利。

这两份条款不能替其他供应商下结论，却说明一个关键区别：额度真实存在，不代表持有人有权把它变成代理服务卖给第三方。采购时要看具体计划、具体账户和具体合同，不能用“这是闲置额度”代替授权证明。

真正获授权的 reseller 通常能说明法律主体、上游关系、适用协议、账单和支持边界。只提供一个兼容接口、余额页面或聊天截图，无法证明转售权。

代理会看到请求，也可能改变响应

当 SDK 连接中转站时，HTTPS 保护的是“客户端到中转站”这一段。中转站必须解密请求，才能将提示词、代码、文件内容和工具定义转发给上游。它技术上可以记录这些内容，也可以改变请求和响应。

一份数据处理协议是有价值的合同材料，但不能单独证明服务没有留日志、没有更换分包商，或实际操作与页面承诺一致。买家还要核对数据经过的公司和地区、保留期限、删除机制、事件通知与审计方式。

模型真实性也一样。代理可以修改响应里的 model 字段，几道测试题只能发现明显异常，无法证明每次请求都到达指定模型。较可靠的做法是固定模型版本，保留客户端请求 ID，核对上游用量或账单，并用一组稳定评测监控质量、延迟和工具调用格式。OpenAI 官方 API 支持请求 ID，也提醒 API key 应作为秘密保存在服务端；把请求交给第三方代理后，会多出一层数据和密钥管理风险。

接入生产前的四道证据门

这是一份采购检查框架，不是对某个具体服务商的合规结论。

第一道门是额度授权：额度归谁，合同是否允许转让或代理使用，上游能否提供授权、账单或可审计的采购证明。

第二道门是数据处理：请求经过哪些公司和地区，提示词与回复保留多久，是否用于训练，怎样删除，分包商是谁，发生数据事件后多久通知。

第三道门是模型真实性：模型名称和版本怎样固定，能否核对请求 ID、用量与账单，抽测异常如何认定和赔付，版本变更是否提前通知。

第四道门是供应连续性：限流、可用性、退款、中断通知和预付款保护是否写进合同，账号或额度被撤销时有没有官方 API 或第二供应商兜底。

任何一关不能核验，都要把对应风险计入成本。涉及客户数据、未公开代码、生产密钥或高权限工具时，不通过就不该进入生产环境。

便宜多少，才值得换供应商

采购不能只比较每百万 token 的单价。更接近真实的成本还包括接入和评测时间、监控与审计、故障切换、预付款损失、数据事件，以及模型漂移导致的返工。

可以先拿非敏感、可重放的公开数据做小额试跑，设置日预算、并发上限和一键停用。测试至少覆盖目标模型、流式输出、错误码、工具调用、长上下文、峰值限流和退款流程。试跑期间不要传客户隐私、内部代码或可直接执行的高权限工具。

如果卖家拒绝提供主体、授权和数据路径，却要求长期预付，再大的折扣也很难覆盖风险。相反，能够给出授权、审计、SLA 和清晰补救条款的服务，即使不是官方直连，也可能是合理供应商。

一份可以带进采购会的清单

1. 谁签合同、谁开发票、谁承担退款和数据责任？
2. 额度属于谁，具体合同是否允许转让或代理使用？
3. 上游是哪家，能否提供授权、账单或可审计证明？
4. 请求经过哪些公司、地区和分包商，保留多久，怎样删除？
5. 模型名称、快照和能力怎样核验，变更怎样通知？
6. SLA、限流、余额、预付款和中断退款怎样写？
7. 能否从非敏感小流量开始，并随时停用？
8. 如果它明天消失，系统能否在一天内切回官方 API 或第二供应商？

这八个问题里，如果对方回避两三个，问题就不再是“能便宜多少”，而是“你究竟买到了什么”。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

内容边界：市场规模、异常折扣来源等为原文作者的粗略估计或明确标注的判断；Hacker News 评论只作为社区观点；AWS、Google Cloud 与 OpenAI 的官方条款和数据文档是编辑阶段补充，用于说明采购时应怎样核验，不代表对任何具体卖家的定性。

1. Matt Lenhard，Vectoral，2026-08-10：Who Are the Token Brokers?——本文主要原文；包含作者的联络、站点截图、挂牌和对市场规模的粗略估计。
2. Matt Lenhard，Vectoral，2026-06-28：An Inside Look at the Relay Market Powering Token Resellers and Fraud——中转站、账号池和网关软件的前文；其中不少市场描述来自论坛观察，不能外推到所有服务商。
3. Hacker News：The AI Credit Resale Economy——作者澄清“数千万”指美元金额，并讨论欺诈占比的不确定性；其他评论只代表参与者观点。
4. AWS：AWS Promotional Credit Terms & Conditions——编辑阶段补充；现行条款关于额度转让、撤销和违规使用的规定。
5. Google Cloud：Google Cloud Startups Program - Startup Terms——编辑阶段补充；项目激励不可转让、出售、购买或交换。
6. OpenAI：Data controls in the OpenAI platform——编辑阶段补充；官方 API 的数据保留和控制说明。
7. OpenAI：API Overview——编辑阶段补充；API key、请求 ID 和版本稳定性相关说明。

资料说明：本文依据 2026 年 9 月 2 日可见的公开资料整理。服务条款、折扣、卖家和中转站状态可能变化；实际采购应核对签约当天适用的合同与技术文档。

TL;DR：Anthropic 于 2026 年 8 月 14 日宣布，未来的 Claude 模型将在生成文本时加入统计水印——不是零宽字符或元数据，而是选词之间的统计关系。官方称无可感知的质量损失，批评者则指出密钥参与选词就意味着文字并非完全未变。本文梳理水印机制、争议双方与检测的边界。

2026 年 8 月 14 日，Anthropic 宣布未来的 Claude 模型会在生成文本时加入水印。它不是零宽字符，也不是粘在文件末尾的元数据。读者看到的依然是一段普通文字，真正留下痕迹的是一次次选词之间的统计关系。

争议也由此而来：Anthropic 说这种方法没有可感知的质量损失；批评者则认为，只要密钥参与了选词，就不能说文字完全没变。这两句话看似针锋相对，其实谈的是不同层面的“影响”。

🎬 视频版（B站） ｜ 🎧 音频版（7 分 44 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

它没有在文字里藏特殊字符

大语言模型每生成一个 token，都会先得到一组候选及其概率。遇到“天气又冷又……”这样的句子，“阴沉”和“灰蒙蒙”可能都合理；模型并不总是机械地选概率最高的那个，而会从候选分布中采样。

Anthropic 采用的是 SynthID-Text 的一种实现。它把前文上下文和一把秘密密钥放进伪随机过程，用得到的随机种子参与下一 token 的采样。单独看每次选择都正常，但在足够长的文本里，选词结果会与密钥形成可测量的相关性。

所以，水印不是一串可以搜索、复制或删除的标记。检测者需要掌握相应密钥，才能计算整段文字的统计分数。没有密钥的普通“AI 文本检测器”，做的是另一类事：它们通常根据文风、词频或训练出的分类器猜测来源，不能直接验证这枚水印。

“改变随机数”算不算改变写作

John Gruber 的批评抓住了一个直观问题：写作里的近义词并非真的等价。节奏、语气和画面感可能因为一个词而变化。既然密钥影响了抽样，最终句子当然可能和没有水印时不同。

Anthropic 与 SynthID-Text 论文强调的是另一层含义：非失真方案不把模型推向原本不合理的词，也不改变候选词在大量采样中的目标分布。它改变的是单次随机选择如何实现，而不是要求模型塞入某个固定词组。

这意味着两个判断可以同时成立：具体一次生成的词可能不同；但从统计分布和可测质量看，未必出现系统性下降。把“某句话可能变了”直接推成“整体文风一定变差”，证据并不够；反过来，把大规模评测中的“没有测出差异”说成“任何精修文本都绝对不受影响”，也超出了实验能证明的范围。

目前有哪些质量证据

SynthID-Text 论文报告了一项接近 2,000 万条 Gemini 回复的线上实验。带水印与不带水印两组的用户反馈没有出现统计显著差异。研究团队还做了标准基准与人工并排比较，同样没有观察到模型能力或文本质量下降。

这是一组重要的生产规模证据，但它测量的是用户反馈、基准和人工评分。它不能枚举所有文体，也不能保证某位作者特别在意的某个词永远不会变化。对于文学创作、品牌文案或法律措辞，最稳妥的态度仍是保留草稿、版本记录和人工复核，而不是用一句“无影响”替代具体审阅。

水印在哪里最强，在哪里最弱

水印需要可选择的空间。长篇解释、改写和翻译中，模型要做大量措辞决定，信号比较容易积累。短句、事实性段落、精确代码和只改标点语法的轻度校对，可替换的 token 少，信号可能弱到无法可靠检测。

这也是为什么“没检测到”不能直接等于“Claude 没参与”。文本太短、内容太确定、编辑量太小，都可能让检测器缺少证据。反过来，“检测到”也只说明 Claude 很可能参与过，无法区分整篇从头生成，还是对人类草稿做过大幅改写。

完整重写还可以移除水印。Anthropic 对这一点并不回避：轻度编辑通常不会立刻抹掉全部信号，但如果每个词都被替换，原有统计关系就会消失。它因此更像规模化内容生态里的来源线索，而不是不可破解的防伪钢印。

检测结果究竟能证明什么

检测依赖提供商的密钥与阈值。图中边界依据 Anthropic 技术说明和 SynthID-Text 论文整理。

用对应密钥检测时，结果回答的是：“这段文字在多大程度上符合 Claude 使用该水印时会产生的统计模式？”它不能识别具体用户、组织或对话，也不携带个人身份信息。

它同样不是通用 AI 鉴定。另一个模型即使也有水印，使用的密钥或方法也可能不同；开源模型可以根本不加水印。一个检测器也无法只凭 Claude 的水印判断其他模型是否参与过。

真正危险的不是检测器会给分数，而是机构把分数变成没有上下文的红灯。学校、平台或公司如果要据此采取行动，至少需要公开文本长度要求、阈值、误报与漏报的取舍、证据保存方式，以及当事人的申诉渠道。否则，一个概率工具很容易被误当成判决。

为什么选择全球上线

Anthropic 表示，这项改动是为了满足欧盟 AI Act 对合成内容透明度的要求。欧盟委员会围绕机器可读标记与检测制定了配套行为准则；签署行为准则本身是自愿的，但相关法律透明度义务并不因此变成可选项。

Anthropic 在 2026 年 7 月加入了这项准则，并称将水印在上线时全球应用，因为暂时没有稳定办法只按地区启用。旧模型则有过渡期，水印会在后续数月逐步加入。

这里还要区分文本水印和文件凭证。Claude 生成的部分图片、SVG 等文件会使用 C2PA 内容凭证，把经过签名的来源声明写入文件元数据；文字水印则作用于生成时的采样，两者不是同一种技术。

普通用户更该关心三件事

第一，别把水印当成藏在文章里的身份证。它只能提供来源概率，不能决定作者身份、版权归属或责任。

第二，重要稿件要保留过程证据。草稿、版本历史、引用来源和人工修改记录，通常比一次检测分数更能说明内容是怎样完成的。

第三，看到检测结论时先追问边界：检测的是哪家模型，是否持有官方密钥，文本有多长，阈值是多少，完整改写和混合创作怎么处理，误判后能否复核。

水印的技术问题，是怎样在随机采样里留下统计指纹；它真正带来的治理问题，则是谁能检测、检测能证明什么，以及误判以后谁负责。后面这三个问题，不应该跟水印一起藏起来。

收看本期节目

• 标题：Claude 以后写出的长文，为什么会藏着看不见的水印？
• 时长：7 分 44 秒
• 音频：在线播放或下载
• 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 010 期整理而成，核心资料包括 Anthropic 的技术说明、Google DeepMind 团队发表于 Nature 的 SynthID-Text 论文、欧盟委员会的透明度行为准则页面，以及 John Gruber 的评论文章。官方公告把水印描述为面向“未来 Claude 模型”的计划，并说明旧模型将在随后数月逐步加入；截至本文整理时，公开资料没有提供逐模型、逐入口的完整启用清单，因此不能把任意一段 Claude 输出都直接视为已带水印。

1. Anthropic，2026-08-14：How Claude's text watermarking works——未来模型、旧模型过渡、检测范围、改写影响、全球部署和检测 API 计划。
2. Sumanth Dathathri、Abigail See 等，Nature 634，2024：Scalable watermarking for identifying large language model outputs——SynthID-Text 方法、生产规模实验、检测机制与限制。
3. 欧盟委员会：Code of Practice on Transparency of AI-generated Content——AI 生成内容透明度行为准则及其适用背景。
4. John Gruber，2026-08-16：Anthropic's “Watermark” Text Adulteration in Claude Is a Perversion of Writing——从写作与选词角度提出的批评；这是评论观点，不是质量对照实验。
5. Hacker News：Anthropic text watermark discussion——社区对选词、检测权与可移除性的讨论；评论仅代表参与者观察。

资料说明：本文依据 2026 年 9 月 2 日可见的公开资料整理。水印部署状态、检测 API 和监管实施细节可能继续变化；判断具体文本时，应以提供商当时的模型说明与检测文档为准。

TL;DR：LittleLearner 实验把“模型是真会还是背过”变成了可控问题：研究者把预训练语料限制在小学（K–5）概念范围，再观察能否悟出范围之外的高阶知识。2026 年 8 月 13 日提交的论文显示，扩大模型、强化学习和上下文示范都能把能力推向边界之外，但结论限于最高 5B 参数模型与数学、事实问答，不能外推为所有模型的普遍定律。

大型语言模型读过的网页太多，我们很难判断一项能力究竟是后来学会的，还是预训练时已经见过，只是直到某个提示或任务出现才被调用出来。

LittleLearner 试图把这个问题变成可控实验。研究者先限制预训练语料中的概念范围，再观察扩大模型、强化学习和上下文示范能否把能力推到训练范围之外。

🎬 视频版（B站） ｜ 🎧 音频版（6 分 50 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

“只读到五年级”到底是什么意思

LittleLearner 不是让模型扮演十一岁儿童。研究者从 FineWeb-Edu 中构造了一个 88B-token 语料库 LittleCurriculum，用美国幼儿园到五年级课程标准作为概念、词汇和推理要求的代理边界。

他们从头训练了 0.6B、1.3B 和 5B 三种规模的 LittleLearner，并为每种规模准备匹配的 Unfiltered 对照。两组模型使用相同架构、token 数和训练方法，主要区别是预训练语料有没有经过 K–5 过滤。

项目页面把它称为“只知道五年级学生知道的内容”，但论文里的严谨含义是“预训练暴露经过课程范围过滤”。网页文本、模型学习方式和真实儿童教育都远比这句宣传语复杂。

研究者怎样建立知识边界

过滤过程分为多个阶段：

1. 按词汇习得年龄和词频做粗筛；
2. 用大模型标注数据训练年级分类器；
3. 依据课程标准判断概念是否属于 K–5；
4. 移除高阶数学符号和明显越界词组；
5. 采用偏向高精度的抽样策略，宁可删掉较难的小学材料，也尽量减少越界内容。

这类过滤不可能直接证明“零泄漏”。作者做了两项独立检查：在 WeeBit 外部年级语料中，过滤器保留了 6,000 篇高年级文本的 2.48%；人工复查后，只有 3 篇明确包含越界概念，相当于 0.05%。研究者还扫描了 126 个来自课程标准的高阶 n-gram，在保留语料中的匹配率为 0.09%。

这些结果支持“泄漏被限制得较低”，不能解释成所有高级概念都已被彻底清除。公开数据集仍然来自网页语料，存在抓取噪声、普通叙事和难以按年级归类的内容。

LittleLearner 不是儿童心智模型

真实儿童会通过视觉、动作、社交、提问和长期记忆不断获得新信息。LittleLearner 则在 88B token 文本上训练，采用与现代语言模型类似的架构和优化方式。

“K–5”在这里是一把控制预训练暴露的实验尺子，不是对儿童发展顺序的复制。模型可能会做好某些表面上更难的计算，却不会真实孩子熟悉的生活技能；遇到不知道的问题时，它也不一定会像孩子那样承认不知道。

项目页面还明确说明，这是学术研究产物，没有为儿童使用做安全对齐。它不应被当作儿童教育助手。

越过边界后，模型会怎样回答

LittleLearner 在范围外问题上并不总是输出随机乱码。论文展示了一个典型例子：面对“薛定谔的猫”，受限模型把它解释成一只“有两张脸的猫”。

论文作者认为，模型会把陌生概念投射到预训练中熟悉的模式，生成结构完整但事实错误的说明。它知道怎样组织一段像答案的文字，却缺少回答所需的概念背景。

这项观察提醒我们，流畅度不能证明知识真实存在。模型在知识边界外仍可能自信回答，因此“不知道何时不知道”也是需要单独评估的能力。

扩大模型能不能跨过边界

研究者比较了 0.6B、1.3B 和 5B 三种规模。模型变大后，K–5 范围内表现明显提高；在与小学算术结构仍有重叠的六、七年级问题上，也出现有限迁移。

到了八年级数学，三个规模的 LittleLearner 都接近性能地板。作者据此认为，在这组模型和任务中，扩大参数主要提高了训练暴露范围内的能力，没有显著扩展到更远的范围外内容。

这不等于“模型规模永远无法产生新能力”。作者在结论中提醒，5B 为了学术可行性而设，远小于前沿模型；某些上下文学习或涌现行为可能在这个规模上并不明显。

SFT 和 GRPO 能不能补上缺失知识

论文采用两阶段后训练：先做监督微调，再使用 GRPO 强化学习。LittleLearner 分别尝试 K–5 数据和不受年级限制的数据，Unfiltered 对照组也使用匹配训练。

在论文测试的预算中，后训练明显增强了 K–5 能力，范围外表现只得到有限改善。即使 LittleLearner 在 GRPO 阶段接触更高年级问题，仍没有追上拥有开放预训练语料的对照模型；两种 LittleLearner 后训练数据之间也没有观察到明显差异。

作者的结论是，跨过这道差距需要比当前 GRPO 设置更基础的变化。这里的限定词很重要：它只描述论文测试的算法、数据、任务和训练预算，不证明所有强化学习方法都无法引入新能力。

把示范写进提示词会怎样

研究者还给 5B LittleLearner 提供人工编写的自然语言解题示范。K–5 准确率从 34.0% 增加到 36.8%，Beyond-K–5 则从 6.0% 变为 5.9%。

示范会改变输出长度、格式和表达方式，却没有提升范围外推理。论文把这种现象解释为 elicitation：提示把已有能力更好地调用出来，并没有在测试过程中补上预训练时缺失的知识。

上下文学习的结论同样有边界。它只适用于论文测试的 few-shot 和 explanation 提示、5B 模型及 MathCAMPS 任务。

这篇论文能证明什么、不能证明什么

图中数值来自论文 v1。支持结论仅适用于论文测试的模型、数据、任务与训练预算。

论文支持的核心判断是：在这组受控实验里，参数扩展、SFT+GRPO 和上下文示范主要放大了预训练已经支持的能力，范围外迁移有限。

论文没有证明语言模型只能复述训练数据，也没有证明前沿模型、其他任务或未来学习算法会得到相同结果。过滤检查说明越界暴露较少，但不能排除所有泄漏。

Hacker News 上关于“模型为什么偶尔说出高阶术语”“它不像真实五年级儿童”的质疑，适合用来检查实验边界。单次在线对话不能推翻完整对照实验，也不能代替对数据集泄漏和任务设计的系统审计。

这间受控实验室接下来能研究什么

LittleLearner 提供了一个预训练暴露相对可追踪的实验环境。研究目标并不是让模型永远停在小学范围。

研究者可以逐步加入负数、代数或新的事实，观察模型学习速度、遗忘和干扰；也可以测试检索、外部记忆、自我探索、多 Agent 协作和新的奖励机制，区分新信息来自哪里。

普通网页规模模型的训练语料难以完整知道。当模型解出一道新题时，我们很难判断它是在组合旧知识、调用隐含记忆，还是获得了真正新的能力。受控语料不能直接回答这个大问题，却让研究者能够设计更清楚的实验。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 009 期整理而成。节目主要来源是 Fanfei Li、Jana Zeller、Manuel Prada-Corral 等作者于 2026 年 8 月 13 日提交的论文《LittleLearner: Language Models Under Pedagogically Controlled Knowledge Exposure》及项目页面。论文当前为 arXiv v1，研究的是最高 5B 参数模型、特定 K–5 过滤语料、数学与事实问答，以及有限的后训练和提示设置；本文不会把结果外推为所有语言模型的普遍定律。

1. Fanfei Li、Jana Zeller、Manuel Prada-Corral 等，2026-08-13：LittleLearner: Language Models Under Pedagogically Controlled Knowledge Exposure——arXiv v1 论文与实验范围。
2. LittleLearner 团队：项目页面——模型、主要发现、在线演示与资源入口。
3. LittleLearner 团队：LittleCurriculum 数据集——公开过滤语料和数据卡；网页数据仍需结合论文的过滤与泄漏检查理解。
4. arXiv：论文 HTML——实验方法、附录数值和作者限制说明。
5. Hacker News：What happens when an LLM never sees material beyond fifth grade?——社区对数据泄漏、儿童类比和在线模型表现的讨论；评论只代表参与者观察。

资料说明：本文讨论的是控制预训练暴露的研究方法，不提供教育、儿童发展或模型安全建议。LittleLearner 是研究产物，不是儿童心智模拟，也没有面向儿童使用做安全对齐。

能读懂大型代码库、调用工具、运行程序并根据错误继续调试的模型，离漏洞研究并不远。安全研究同样需要理解代码、构造输入、观察环境反馈，并把多个步骤连接起来。

GLM-5.3 的变化说明，编码能力经过面向长程任务的后训练后，可能迁移到漏洞发现与利用推理。这里需要先澄清：“涌现”不等于模型没人教就突然有了黑客人格。

本文由《听懂 AI》第 008 期整理而成。节目主要来源是 Z.ai 于 2026 年 8 月 14 日发布的《GLM-5.3：前沿编程能力与涌现的网络安全能力》。本文另外核对了 Z.ai 当前模型卡、Hugging Face 权重与许可证，以及安全披露账本。所有 benchmark 和真实项目漏洞数量都是 Z.ai 公布结果，不代表已经完成独立复现。Hacker News 评论只作为社区观察。

🎬 视频版（B站） ｜ 🎧 音频版（6 分 11 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

这里的“涌现”到底指什么

Z.ai 明确写道，GLM-5.3 与 GLM-5.2 使用相同的基础模型，性能提升来自后训练。团队把训练环境扩展到更长、更接近真实工作的任务，并从 2025 年 9 月开始与安全实验室建设漏洞发现数据、执行环境和专用 harness。

因此，网络安全不是完全没有训练目标的意外能力。官方所谓“超出预期”，更接近两层含义：

• 随着后训练规模扩大，安全能力增长速度高于预期；
• 提升没有停在代码审查，而是继续迁移到漏洞验证和利用推理。

团队主动训练了安全任务；超出原先预期的是模型在任务链上能走多远、增长有多快。

为什么编码能力会迁移到漏洞研究

编码 Agent 和安全研究 Agent 共享不少基础能力：

• 在多文件代码库中定位相关逻辑；
• 理解输入、状态和权限边界；
• 调用编译器、测试器、调试器与终端；
• 根据崩溃、日志和返回值修正假设；
• 在长任务中保存计划、证据和中间结果；
• 编写小段验证代码并检查是否达到目标。

普通编程任务常以“让系统按预期工作”为目标，漏洞研究则寻找“怎样让系统进入设计者没有预期的状态”。工具和推理过程高度重叠，区别主要在任务目标、授权范围与结果如何使用。

这也是网络安全能力具有双重用途的原因：同一套代码理解和验证能力，可以帮助维护者修复风险，也能降低攻击者批量试错的成本。

三个安全 benchmark 分别测什么

Z.ai 使用 CyberGym、ExploitBench 和 ExploitGym 覆盖攻击链的不同阶段。它们不能只按分数高低排成一张简单榜单。

图中数据来自 Z.ai 模型卡。三个评测的任务、单位、harness 和预算不同，不能互相换算。

CyberGym 从白盒源代码出发，要求模型触发程序故障并识别漏洞。Z.ai 报告 GLM-5.3 从 77.2% 提升到 84.5%。模型卡说明这是一组 1,507 个任务的单次 Pass@1 结果，使用 Claude Code harness、最大推理档位和受限网络环境。

ExploitBench 更深入，需要理解真实漏洞成因并覆盖相应利用能力。GLM-5.3 的平均覆盖分从 24.4 提升到 54.4，但仍低于模型卡中 Fable 5 的 78.0 和 GPT-5.6 Sol 的 76.5。该评测只有 41 个任务，并把三次修订得到的能力取并集。

ExploitGym 统计限定预算内完成的利用任务数量。GLM-5.3 在两小时和六小时预算下分别完成 105 与 130 项，GLM-5.2 为 29 与 39 项。预算还按不同模型的推理吞吐量换算，因此这些数字不能直接推广到任何真实网络环境。

为什么不能只截“84.5% 第一名”

CyberGym 的 84.5% 说明模型在该白盒任务集和指定工具条件下表现很强，不代表它在完整攻击链上领先所有模型。Z.ai 自己公布的另外两项结果已经显示，越深入漏洞利用阶段，GLM-5.3 与部分闭源前沿模型的差距越明显。

模型卡还给出了评测细节：任务运行在隔离容器中，网页工具关闭，部分域名被列入白名单，并使用特定版本的 Claude Code harness。换掉 harness、推理预算、工具、任务集或时间限制，结果都可能变化。

因此，benchmark 适合描述特定条件下的能力切片。它不能证明模型获得了真实系统授权，也不能代替对误报、越权行为和修复质量的评估。

2,436 个真实漏洞应该怎样解读

Z.ai 称其与多家安全团队开展红队测试和安全评估，经过初筛、去重后累计发现 2,436 个漏洞，覆盖 269 个项目，其中 1,097 个被归为中高危，最老的问题可追溯约 45 年。

这组数据比静态 benchmark 更接近实际代码，但仍然是厂商公布结果。当前公开材料没有提供完整样本、统一误报率、每个项目的投入时间，也无法让外部团队对全部 2,436 项逐一复现。大量问题还经历协调披露，公开程度受修复进度限制。

截至 2026 年 9 月 1 日，原 cvd.z.ai 披露账本已经停止展示具体漏洞详情，并指向 CNVD、CNNVD 和 NVDB 等官方平台。文章可以确认披露工作存在，不能把无法公开核对的条目写成已经独立验证的行业统计。

开放权重状态已经发生变化

节目发布时，Z.ai 表示会在安全评估和加固完成后约两周开放 GLM-5.3 权重。这个状态现在已经更新：截至 2026 年 9 月 1 日，GLM-5.3 和 BF16 版本都已出现在 Z.ai 的 Hugging Face 组织页面，模型卡提供本地部署说明。

权重使用自定义的 GLM-5.3 License。许可证允许使用、修改、分发和创建衍生作品，但包含合规要求，以及针对年收入超过 100 亿美元、经营“模型即服务”业务主体的安全审查条款。因此，称它为“开放权重”比笼统说“没有限制的开源模型”更准确。

权重公开也意味着外围 API 分类器和推理监控器不再是所有部署环境都能依赖的统一防线。模型内部安全对齐仍会随权重一起存在，但本地部署者可以改变提示、工具和外围控制。

攻击者和防守者谁更占便宜

没有一个自动成立的答案。

防守方可以用模型扩大代码审计覆盖面，更早发现冷门组件和长期遗留问题，并辅助复现、分级与修复。攻击方也可以批量扫描大量项目、并行尝试不同路径，把原本昂贵的人工研究变成可重复流程。

双方资源并不对称。一个开源项目可能只有少数维护者，还要支持多个旧版本；攻击者却可以同时扫描许多目标。把模型交给维护者，不会自动增加修复人力、升级窗口或用户安装补丁的速度。

发现之后的确认、修复、协调披露和部署速度，往往比模型生成报告的数量更能影响结果。

安全 Agent 还需要评估“守不守边界”

Hacker News 讨论里同时出现两类个人体验：有人认为 GLM-5.3 适合红队研究，也有人觉得它能力强但容易偏离原任务。这些只是社区个案，不是统一评测。

它们提醒我们分开测量两件事：

• 探索能力：能否找到漏洞路径、构造验证并持续推进；
• 控制能力：能否遵守授权范围、工具限制、停止条件和审批点。

一个模型在 ExploitBench 上取得高分，不能说明它适合直接连接生产网络。企业还需要测试误报率、越权尝试、计划偏离、敏感数据处理、日志完整性，以及发现问题后能否生成可审查的最小修复。

团队现在可以怎样使用这类能力

防御性使用可以从低风险环境开始：

1. 只在明确授权的代码库、镜像或测试环境中运行；
2. 默认只读，外部写入和真实利用必须经过人工批准；
3. 使用容器、虚拟机或专用沙箱隔离凭据和宿主文件；
4. 保存模型输入、工具调用、环境输出和最终证据；
5. 把结果交给人工复现和分级，不直接按模型报告发布漏洞；
6. 先联系维护者并遵循协调披露流程；
7. 同时跟踪发现数量、确认率、修复率和平均修复时间。

冷门代码“不太会被人看到”正在失去保护作用。团队更应该依赖依赖更新、最小权限、密钥隔离、可审计构建和及时补丁，而不是依赖漏洞长期无人发现。

GLM-5.3 显示，漏洞研究正在变得更容易规模化。防守团队的验收结果应当是风险在影响用户之前完成修复，而不是生成更多风险清单。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

1. Z.ai，2026-08-14：GLM-5.3：前沿编程能力与涌现的网络安全能力——官方中文发布文章、benchmark 与漏洞发现数据，均属于厂商公布结果。
2. Z.ai：GLM-5.3 Hugging Face 模型卡——当前权重、评测设置、本地部署和模型规格。
3. Z.ai：GLM-5.3 License——权重与代码的自定义许可条件。
4. Z.ai Security：漏洞公示迁移公告——当前披露账本状态及 CNVD、CNNVD、NVDB 查询入口。
5. Hacker News：GLM-5.3: Frontier coding with emergent cyber capabilities——社区对开放权重、harness、红队使用和边界控制的讨论；评论只代表参与者观察。

安全说明：本文只讨论公开的模型评测、治理与防御性工程做法，不提供漏洞利用步骤。任何安全测试都应在明确授权、隔离和可审计的环境中进行。

TL;DR：AI 已经能预测蛋白结构、筛选化合物、几秒内生成候选分子，但合成、细胞实验、动物研究和人体临床仍受生物学规律与监管要求约束——AI 加速的是研发前端搜索，而不是整条新药研发流程。这一判断来自 Andreas Bender 等人 2026 年 8 月 7 日发表于 Nature Reviews Drug Discovery 的观点文章。

AI 已经能预测蛋白结构、筛选化合物、生成候选分子，也能辅助预测活性和毒性。计算端的进步很快，但一款药物是否安全、有效，最后仍要由实验和人体数据回答。

候选分子可以在几秒或几小时内生成。合成、细胞实验、动物研究和人体临床却受生物学规律、实验条件、患者差异与监管要求约束。前端搜索加速，并不会让整条研发流程按同样比例缩短。

🎬 视频版（B站） ｜ 🎧 音频版（5 分 29 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

AI 在药物研发中已经能做什么

目前常见应用包括：

• 从疾病机制和多组学数据中寻找潜在靶点；
• 预测蛋白质结构和分子相互作用；
• 在化合物库中做虚拟筛选；
• 生成新的候选分子；
• 预测活性、选择性、药代动力学或毒性相关性质；
• 辅助实验设计、数据分析和文献整理。

AlphaFold 在 2021 年的 CASP14 评测中显著提高了蛋白结构预测准确度，是计算方法改变生命科学工具链的明确案例。但蛋白结构只是药物研发需要处理的一类信息。知道一个蛋白大致长什么样，不等于已经找到了能安全治疗患者的药。

候选分子与药物之间隔着什么

FDA 对药物研发流程的说明列出了候选物之后仍需回答的问题：它怎样被人体吸收、分布、代谢和排泄；合适剂量是多少；可能出现哪些毒性和药物相互作用；不同人群的反应是否不同。

临床前研究只能回答一部分安全问题，不能替代人体研究。进入临床后，研究者还要分阶段评估剂量、安全性、初步疗效、治疗获益和少见不良反应。临床试验使用明确的方案、入组标准、对照和统计方法，计算模型不能跳过这些证据要求。

AI 如果只把早期筛选从一个月缩短到一天，而合成、验证或临床仍是主要瓶颈，患者拿到药物的时间就不会同步缩短。

生命科学数据为什么特别依赖条件

同一个分子在不同实验方法、细胞系统、剂量、时间点和患者群体中，可能表现不同。训练数据中的“有效”，也许只表示它在某个测试中与靶点结合，并不自动包含能否进入细胞、到达正确组织、避免伤害其他器官等信息。

数据还可能来自不同实验室、设备和记录标准。模型在随机拆分的测试集上表现很好，可能只是因为训练集和测试集共享了相似化合物、实验条件或研究习惯。换到新时间、新项目或新实验室后，性能未必保持。

因此，模型分数需要和适用范围一起解释。脱离实验条件的单一“准确率”，很难代表真实研发决策的可靠性。

“有效分子”本身可能没有定义完整

原文把这种问题称为 underspecification，即任务看起来已经定义，实际仍遗漏了决定结果的条件。

例如，“预测一个有效分子”至少可能指：

• 能与目标蛋白结合；
• 在细胞中改变预期通路；
• 能到达需要作用的组织；
• 在有效剂量下没有不可接受的毒性；
• 对目标患者群体产生可测量的治疗获益。

这些目标不能互相替代。模型可能准确优化了容易取得的代理指标，却没有优化项目最后真正关心的结果。此时增加模型规模或生成更多分子，只会让不合适的目标被执行得更快。

benchmark 应该评价模型，还是评价决策

Nature Reviews 的观点文章认为，药物研发中的 benchmark 需要从模型验证转向决策价值。团队不应只问预测误差有没有下降，还要问：

• 原本会继续投入的坏候选，是否更早被淘汰；
• 原本会错过的好方向，是否被模型发现；
• 实验数量、时间和成本是否减少；
• 换到未来数据、外部实验室和新项目后，判断是否仍可靠；
• 候选进入下一阶段后的失败率是否改变。

一个模型可以在静态数据集上领先，却没有改变任何 go/no-go 决定。反过来，一个不够耀眼的工具如果能稳定减少无效实验，可能更有实际价值。

“技术推动”和“科学问题牵引”有什么区别

技术推动通常从新模型出发：先做出更大的生成器或预测器，再寻找可以使用它的任务。科学问题牵引则先定位研发流程中最昂贵、最慢或最容易出错的决定，再判断 AI 是否适合改善这个决定。

两种路径都可能产生研究价值，但资源分配方式不同。生成大量分子很适合展示模型能力；如果项目真正卡在靶点选择、实验不可比或临床入组上，继续扩大分子生成量不会解决瓶颈。

团队应该直接回答：“模型改变了哪一个决定，以及这个决定为什么值得改变？”

从模型结果到患者获益需要哪些证据

这是概念性流程图。图中卡片宽度和候选数量不代表行业统计比例，具体研发路径也会因药物类型与适应症而不同。

计算结果首先是待验证假设。候选能否合成、实验能否重复、生物学机制是否成立、毒性是否可接受、人体内是否产生治疗获益，都需要后续证据。每个阶段都可能推翻上一阶段看起来很有希望的结果。

AI 可以帮助选择下一项实验、预测失败风险或整理多源数据，但模型置信度不能作为临床疗效证据。

临床影响证据有限，不等于已经证明无效

2026 年的 Nature Reviews 文章认为，AI 药物研发已有大量方法、应用和 benchmark，但临床相关影响的证据仍然有限。这句话不能反过来解释成“AI 制药已经失败”。

较成熟的新方法出现的时间，可能还短于一款药从发现走到完整临床验证所需的周期。许多项目仍在研发途中，结果尚未成熟。现在既不能用早期跑分提前宣布行业革命，也不能因为上市药物不多就认定这些方法没有价值。

合理的做法是持续追踪中间决策是否改善，并等待足够长的临床结果。

怎样做更接近现实的验证

团队可以把模型验证分成几层：

1. 时间外推：用训练截止时间之后产生的数据测试；
2. 外部验证：换实验室、项目、设备或患者来源；
3. 前瞻验证：在结果尚未知时让模型参与真实决策；
4. 湿实验验证：用合成、细胞或动物实验检查预测；
5. 决策验证：记录模型是否改变候选淘汰、实验选择和资源投入；
6. 临床验证：跟踪人体安全性、疗效和最终患者获益。

不同层级回答的问题不同。静态测试集适合筛查模型错误，外部和前瞻研究才能逐步说明它是否适合真实流程，临床试验则负责回答对患者是否有效。

AI 制药的近期价值可能没那么戏剧化

Hacker News 讨论中，一些从业者把 AI 的日常价值描述为安装和使用专业工具、编写分析脚本、检查实验方案、整理数据，或更快得到一个可供实验的起始结构。这些是社区个人经验，不代表行业统计。

这种价值仍然重要。研究人员每天少花一些时间处理软件和数据，可以把更多精力放在实验设计和结果解释上。它不会立刻产生一款新药，也很难进入“AI 发现药物”的宣传标题，但可能是技术真正进入研发流程的第一步。

AI 制药是否成功，最后要看它能否让关键决策更准确，让实验更少浪费，并帮助更安全、更有效的药物更快到达患者。模型排行榜只覆盖早期计算环节。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 007 期整理而成。节目主要来源是 Andreas Bender、Morgan C. Thomas、Jack W. Scannell 等作者于 2026 年 8 月 7 日发表在 Nature Reviews Drug Discovery 的观点文章《Artificial intelligence in drug discovery — what it is, where we stand and the path forward》。本文补充 FDA 的药物研发流程资料和 AlphaFold 原始论文。Hacker News 讨论只作为社区观察，不作为临床效果证据。

1. Andreas Bender、Morgan C. Thomas、Jack W. Scannell 等，2026-08-07：Artificial intelligence in drug discovery — what it is, where we stand and the path forward——Nature Reviews Drug Discovery 观点文章，主张把评测重点从模型验证转向研发决策和临床转化。
2. U.S. FDA：Step 1: Discovery and Development——候选发现之后需要评估的药代、剂量、毒性和人群差异。
3. U.S. FDA：Step 3: Clinical Research——人体临床研究的目的、阶段和证据要求。
4. John Jumper 等，2021-07-15：Highly accurate protein structure prediction with AlphaFold——AlphaFold 在蛋白结构预测上的原始研究，不能单独代表完整药物研发周期。
5. Derek Lowe：So How is AI Drug Discovery Doing, Really?——Hacker News 条目实际提交的 Science 评论文章，属于对 Nature Reviews 观点文章的二次讨论。
6. Hacker News：AI in drug discovery — what it is, where we stand and the path forward——上述 Science 评论的社区讨论；评论只代表参与者观察。

资料说明：本文讨论研发评测与证据边界，不提供药物、疾病或临床决策建议。Nature Reviews 原文是一篇多作者观点文章，不是单项 AI 模型的临床试验；文中的流程图和评测建议是编辑阶段的概念性整理。

TL;DR：模型能力越强，授权给它的风险和不确定性也被放大——更强的模型意味着更难预测的行为、更高的单次成本和更深的信任依赖。一问一答讨论为什么“换更强的模型”不总是安全答案。

模型跑分提高，和它更适合一起工作，并不是同一件事。

一个编码 Agent 可以更快定位错误、完成更长的任务，也可能在需求有歧义时替人选定方向。它交付得更快了，人却不敢离开屏幕：每隔几分钟就要检查它是否扩大范围、改变计划，或把某个未写出的假设当成事实。

🎬 视频版（B站） ｜ 🎧 音频版（4 分 05 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

原文到底在抱怨什么

Mun Logadan 并没有说 Opus 5 能力倒退。相反，他认为它比 Opus 4.7、4.8 更有能力，benchmark 表现也很强。让他不舒服的是协作方式：

• 意图不清楚时，不太愿意停下来询问；
• 信息缺失时，会自行补充假设；
• 已有计划存在多种解释时，可能不经确认就重新理解或修改。

这会产生一种反直觉的体验：模型更能完成任务，人却需要更仔细地看守它。这里的证据只是个人观察。它能说明一种真实存在的使用问题，不能证明所有用户都会遇到，也不能据此给 Opus 5 的整体能力下结论。

官方叙事和个人体验为什么会冲突

Anthropic 在 2026 年 7 月 24 日发布 Opus 5 时，把它描述为更主动、更适合长时间多步骤工作的模型。官方公布了 Frontier-Bench、CursorBench、OSWorld 等结果，并列出大量早期客户反馈，其中一些特别称赞它会验证工作、发现隐患，或只在需要人类判断时把人拉回来。

这些材料证明了 Anthropic 想优化的方向，也提供了具体使用案例，但仍主要来自厂商评测和早期客户引述，并不是独立的用户体验研究。个人文章关注的又是另一种场景：任务文本没有写全，隐性业务约束很多，选错方向的代价高。

同一种“主动性”，在两类任务里可能得到相反评价：

• 任务自包含、结果可自动检查时，主动补步骤能节省时间；
• 任务依赖未写出的组织背景时，主动补假设可能扩大风险。

所以争议不一定是谁对谁错。双方测量的对象不同：一个更接近“模型能否完成”，另一个更接近“人是否放心让它完成”。

隐藏上下文才是现实工作的难点

“重构登录模块”看起来是一句完整需求，实际可能牵涉旧客户端兼容、审计要求、埋点协议、上线窗口和客户承诺。这些信息可能散落在代码、文档、工单和人的记忆里，不会自动进入提示词。

模型可以写出结构漂亮、测试全绿的新实现，却仍然删掉某个不能改变的旧行为。问题不一定是它不会写代码，而是它不知道自己缺少了哪些背景。

现实任务还经常没有唯一正确答案。两个方案都能运行，但预算、团队经验、发布节奏或维护责任会改变选择。Agent 如果继续执行，就相当于替项目负责人做了技术之外的取舍。

benchmark 的解释为什么只能当作线索

原文猜测，强调 benchmark 的训练环境可能鼓励模型在歧义面前大胆选择答案，因为一项设计良好的评测通常会提供足够信息，并保证存在可以评分的结果。模型如果反问任务设计者，反而无法得分。

这个解释有启发，但没有证据证明 Opus 5 的具体协作行为由某种 benchmark 或训练方式造成。官方发布材料也没有提供能支持这条因果链的数据。

现有证据只能说明，单独测任务成功率可能遗漏“何时需要人类输入”这项能力。真实工作既要看模型能不能解题，也要看它能否发现题面之外的关键决定。

多问问题也不是答案

让 Agent 每做一步都询问，同样会让自动化失去意义。更实用的做法是同时判断三个因素：

1. 歧义：目标是否有多种合理解释；
2. 后果：选错会影响多少用户、数据或外部系统；
3. 可恢复性：操作能否低成本撤回和验证。

这是文章中的编辑性框架，不是对 Opus 5 或其他模型的实验结果。

边界清楚、风险低、容易撤回的操作，可以直接完成并留下记录。信息不全但后果较轻时，可以声明假设，只做一个可回退的小步骤。动作虽然明确，但涉及发布、删除、付款或数据迁移时，应先取得审批。歧义和后果都很高时，Agent 应停止并请人决定方向。

问题是否有价值，要看它能不能改变方案或风险，而不是看数量。

注意力也应该计入生产力

Hacker News 讨论后来扩展到模型的固定写作句式、冗长注释和无关改动。有人认为这些问题严重消耗注意力，也有人觉得影响有限。这些都属于社区观察，不是统一实验结果。

但它们提醒了一个容易漏掉的成本：任务完成之后，人还要花多久才能信任结果。一个模型单次成功率更高，如果每次都要清理无关修改、核对隐藏假设和恢复越界操作，整体生产力未必同步提高。

团队可以记录这些指标：

• 人工持续盯守的时间；
• 审查和返工耗时；
• 偏离计划的次数；
• 越权或不可逆操作的次数；
• 出错后恢复到安全状态所需的时间；
• 因为信任不足而无法开放的工具和权限。

能力决定 Agent 能做多复杂的任务，协作成本决定团队愿意给它多大的行动范围。

怎样设计更合适的审批点

团队不必把所有背景写成一份无限增长的规则文件。固定约束适合写进项目说明，动态取舍则需要运行时判断：

1. 明确只读目录、允许的工具和必须审批的外部写入；
2. 要求 Agent 在高风险任务开始前复述目标、假设和不可改变的约束；
3. 把大任务拆成可检查、可撤回的阶段，每阶段提供真实读回证据；
4. 偏离已批准计划前，说明原因和影响并重新请求授权；
5. 对发布、删除、迁移、付款和凭据操作设置明确审批点；
6. 记录人类介入的位置，持续调整哪些步骤可以自动化。

规则文件能保护已经知道的边界，审批机制负责处理还没写进规则的新情况。两者缺一不可。

评测“知道何时问”可以怎么做

如果只给模型材料齐全、答案明确的任务，就很难观察它怎样处理现实中的不完整信息。更贴近协作的 Eval 可以故意留下关键歧义：

• 提供两个都能运行、但业务含义不同的方案；
• 隐去一个会改变设计的权限或兼容约束；
• 混合可撤回操作与不可逆操作；
• 在执行中途加入与原计划冲突的新证据。

评价时不应只数模型问了多少问题，还要看它是否发现真正会改变结果的歧义，是否区分可逆与不可逆操作，是否在偏离计划前请求授权，以及人类总共花了多少时间介入。

这套指标仍是一种编辑性建议，不是现成的行业标准。它至少把“感觉更累”转换成了可以记录和比较的协作成本。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 006 期整理而成。节目主要讨论 Mun Logadan 于 2026 年 8 月 14 日发布的个人文章《Why does Opus 5 feel worse to work with?》，并补充 Anthropic 的 Opus 5 发布说明和 Hacker News 社区讨论。原文描述的是作者及同事的使用感受，不是模型对照实验；关于训练和 benchmark 的解释也被作者明确标为推测。

1. Mun Logadan，2026-08-14：Why does Opus 5 feel worse to work with?——个人及同事的协作体验；关于训练与 benchmark 的解释由作者标为推测。
2. Anthropic，2026-07-24：Introducing Claude Opus 5——官方发布说明、厂商评测和早期客户案例，不应视为独立用户研究。
3. Hacker News：Why does Opus 5 feel worse to work with?——社区对自主性、写作风格、注释和审核成本的讨论；评论只代表参与者观察。

资料说明：本文没有证明 Opus 5 比旧模型更难协作，也没有把作者的训练猜测当作事实。关于审批矩阵、协作成本和 Eval 的部分，是基于原文问题做出的编辑性整理与实践建议。

比较 AI Agent 时，人们往往先问“用了哪个模型”。但模型只是其中一部分。它能访问哪些文件和工具、怎样管理上下文、何时请求批准、如何恢复失败、把运行记录保存在哪里，这些都由模型之外的 Harness 决定。

DeepSeek Harness 的 Developer Preview 把这层基础设施单独摆到台面上，并给出两个醒目的设计目标：所有能力都可以作为插件替换；每次运行都能从同一条事件流中追溯。

本文由《听懂 AI》第 005 期整理而成。主要来源是 DeepSeek Harness 官方站点、GitHub 仓库和架构文档。2026 年 8 月 26 日发布的 Cordis 预印本补充了可逆副作用和动态依赖的理论说明。项目截至 2026 年 8 月 28 日仍处于 Developer Preview，官方明确表示会出现破坏兼容性的变更。

🎬 视频版（B站） ｜ 🎧 音频版（5 分 04 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

Harness 到底负责什么

模型可以生成文本或工具调用意图，但它不能直接在操作系统里“自己做事”。Harness 负责把模型接进真实环境：

• 组装系统提示、历史消息和工具描述；
• 暴露文件、终端、搜索、网络等能力；
• 执行工具并把结果送回模型；
• 管理循环、子智能体、上下文压缩和停止条件；
• 应用权限、审批、沙箱和凭据策略；
• 保存会话、运行状态、错误和遥测信息。

同一个模型放进不同 Harness，能完成的任务、消耗的 token、失败方式和安全边界都可能不同。因此，评估 Agent 不能只看模型跑分，还要看它周围这套运行系统。

“所有东西都是插件”具体指什么

DeepSeek Harness 建在 Cordis 插件系统上。官方架构文档没有保留一个不可替换的特权核心：模型适配器、工具注册表、会话日志、智能体循环、沙箱、存储、调度和网页界面都通过插件提供。

这些插件把服务、带类型的事件和依赖关系挂到共享上下文中。开发者可以在配置里替换某个提供者，而不是修改 Harness 源码。例如，换掉模型适配器、把本地文件系统改成远程沙箱，或给某类会话使用不同的工具组合。

运行时并不是简单扫描一个插件目录。它按照 Profile、Bundle、用户补丁和命令行覆盖层组成一棵有顺序的插件树。官方提供 dsh --profile web --dump-config，让开发者查看机器最终实际启动的配置，而不是只看散落在多层文件中的声明。

可逆副作用能解决什么

插件卸载不只是删除一段代码。它可能已经注册监听器、打开连接、挂载服务或启动后台任务。Cordis 要求可撤销的注册在创建时同时登记清理函数，插件卸载时再按生命周期收回这些效果。

2026 年 8 月 26 日提交的 Cordis 论文把这种机制称为“时间可组合性”：组件产生的上下文变化带有逆操作，运行时负责保存并执行。论文还讨论“空间可组合性”，即组件根据声明的依赖动态激活和停用。

这个机制能清理框架知道并登记过的副作用，却不能倒转所有现实操作。插件如果已经删除外部文件、调用第三方 API 或泄露凭据，卸载函数无法让这些事情自动消失。生命周期清晰不等于风险消失。

“每次运行都可追溯”不是读心术

DeepSeek Harness 把会话视为只追加的 SessionEvent 事件流。用户输入、模型请求、模型返回、工具调用与结果、步骤开始结束等事实写入同一记录。下一轮模型历史由日志重新投影，恢复、分叉、搜索、重放、遥测和持久化也从这条事件流派生。

官方文档提出一条运行时约束：“模型可见”就必须能够从日志重建。也就是说，任何真正送进模型请求的内容都应留下对应事件，避免界面显示一套历史、模型实际收到另一套历史。

图中只展示架构关系。实际插件、事件和运行模式以当前配置及官方文档为准。

可追溯不等于能够读取供应商隐藏的内部推理。Harness 只能记录自己收到、创建或发送的内容；如果模型 API 没有返回完整 Chain of Thought，它不会凭空出现在会话日志里。日志透明的是执行链，而不是模型供应商没有暴露的内部状态。

四种模式对应不同的实验目标

官方当前提供四种运行模式：

• Standard：完整编码 Agent，包括文件、终端、搜索、技能、计划、目标和子智能体；
• Code：模型可以通过 Code Mode SDK 在一个 TypeScript 程序中组合多轮工具操作；
• Minimal：只保留持久 Bash 和文件编辑器，用于较小、容易比较的模型评测环境；
• Creator：在 Standard 能力上增加运行时检查、内存插件试验和 Profile 编写指导。

这些模式的意义不只是功能多少。Minimal 可以减少 Harness 自身对评测结果的干扰；Creator 则把插件开发和组合变成产品能力。团队也可以由基础 Bundle 开始，只为特定项目增加必要插件。

插件化和事件流带来的价值

对于研究者和 Agent 基础设施开发者，这种架构便于回答过去很难分开的实验问题：

• 同一个模型换不同工具集，结果差多少；
• 本地沙箱和远程沙箱怎样影响安全与性能；
• 换掉上下文压缩策略后，恢复和长会话表现是否变化；
• 某次失败究竟来自模型、工具、权限、上下文还是循环控制；
• 会话能否从相同事件边界稳定恢复或分叉。

插件边界让替换实验更容易，事件流则提供统一的观察依据。它们提供的是实验和组合能力，不是“换插件一定更好”的保证。

当前最重要的标签仍是 Developer Preview

截至 2026 年 8 月 28 日，官方仓库仍明确写着 Developer Preview，并警告会有破坏兼容性的变更。安全说明更加直接：项目尚未经过安全审计，不能视为安全或生产就绪的软件。

DeepSeek Harness 可以执行模型生成的代码和命令，加载第三方插件，并访问用户允许的网络、进程、凭据和文件。错误模型输出、缺陷、配置错误、恶意输入或不可信插件都可能修改或删除文件、泄露数据，甚至损害宿主机。

官方还强调，沙箱、审批和权限控制只能降低风险，不能保证完全隔离；系统无法保护已经被明确授权访问的资源。社区关于“插件疲劳”、版本冲突和供应链攻击面的担忧因此是合理的工程问题，但 HN 评论只是社区观察，不代表项目已经出现了这些事故。

现在怎样安全地试

如果只是想比较模型或研究 Harness，可以从隔离实验开始：

1. 使用一次性虚拟机、容器或专用环境；
2. 只挂载测试项目，不开放主目录和真实仓库；
3. 不注入生产凭据、SSH Key 或云端密钥；
4. 采用最小权限和人工审批，先从 Minimal 模式或较小插件集开始；
5. 阅读第三方插件源码、依赖和配置，再允许执行；
6. 给可访问文件做备份，并记录外部 API 的副作用；
7. 保存 --dump-config 结果和版本信息，方便重现实验；
8. 接受接口可能变化，不把当前 Profile 当成长期稳定契约。

DeepSeek Harness 把模型之外的运行系统摆到了开发者面前，让工具、会话、沙箱、循环和存储都可以观察和替换。它能否从实验台走向稳定生态，取决于接口治理、安全审计、插件质量和长期兼容性。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

1. DeepSeek：DeepSeek Harness Developer Preview——产品定位、运行模式和当前 Preview 状态。
2. DeepSeek AI：deepseek-harness GitHub 仓库——源码、安装、许可证与兼容性警告。
3. DeepSeek Harness Docs：Architecture Reference——插件树、事件流、Profile、Bundle 和运行时约束。
4. DeepSeek AI：Safety Notice——安全审计状态、沙箱限制与负责任使用要求。
5. Yifan Shi、Wei Zhang、Tianyi Cui 等，2026-08-26：A Programming Paradigm for Spatiotemporal Composability——Cordis 可逆效果与动态依赖的理论说明，当前为 v1 预印本。
6. Hacker News：DeepSeek Harness developer preview——社区对插件治理、兼容性和供应链风险的讨论；评论不代表已验证事实。

资料说明：本文描述的是 2026 年 8 月 28 日可见的 Developer Preview。仓库和 API 正在快速变化，后续版本可能调整名称、模式、接口和安全边界。

TL;DR：AI 编程工具压缩的是“写出代码”的时间，但理解设计、审查影响、验证行为和长期维护并没有同步变快——Florian Herrengt 在 2026 年 8 月 11 日的文章中，把这层被挤压的空间称为软件工程的“中间地带”。本文结合 GitHub、METR 与 DORA 的研究核对一个关键问题：写得更快，是否真的等于生产力更高。

AI 编程工具最直观的变化，是让“写出一批能运行的代码”变得更快。一个需求可以在几小时内长出页面、接口、数据表和测试，过去需要几天的实现工作被压缩到一个下午。

但软件交付并不在代码生成时结束。团队还要理解设计、审查影响、验证行为、迁移数据、处理故障，并在几个月后继续修改。生成速度提高后，这些工作反而更容易成为新的瓶颈。

🎬 视频版（B站） ｜ 🎧 音频版（5 分 09 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

原文所说的“中间地带”是什么

Herrengt 描述了一个常见场景：周一早上出现多个由 Agent 生成的巨大合并请求，功能看起来能运行，却没有人能清楚解释数据从哪里来、为什么增加某个抽象、失败后如何恢复。设计依据甚至只存在于一条来回改口的模型对话里。

他所谓的“工程师中间层消失”，不是一项职业分类研究，而是一个比喻：当实现和集成越来越容易，单纯把规格翻译成代码的价值可能下降；能够理解复杂系统、判断取舍并对结果负责的人会更重要。

原文中的“25,000 行合并请求”“一下午生成 20,000 行”等数字是叙事例子，不是行业平均值。文章对薪资分化和岗位减少的判断也是作者预测，不能当成已经发生的统计结论。

AI 到底让开发者快了多少

不同研究给出的答案并不一致，因为它们测量的任务完全不同。

GitHub 在一项受控实验中让 95 名专业开发者完成同一个 JavaScript HTTP 服务器任务。使用 GitHub Copilot 的一组平均用时 1 小时 11 分，未使用的一组平均用时 2 小时 41 分，前者快 55%。这是一个范围清楚、自动测试可以判断完成度的单项任务。

METR 在 2025 年研究了另一种情境：16 名熟悉大型开源项目的开发者完成自己仓库里的 246 个真实任务。允许使用当时的 AI 工具后，任务完成时间反而增加了 19%。参与者原本预计会快 24%，做完后仍主观认为自己快了 20%。

这项结果也不能推广到所有开发。它只代表 2025 年初的工具、这些开发者和成熟仓库。METR 在 2026 年公布的后续数据出现了可能的加速信号：原研究参与者子集估计快 18%，新招募开发者估计快 4%，但置信区间都包含没有提升的可能，而且不愿离开 AI 工具的开发者更容易退出实验，造成明显的选择偏差。研究团队因此决定调整实验设计。

三组结果放在一起，能得到一个更可靠的判断：AI 对明确、局部、容易验证的实现任务可能明显提速；在熟悉但复杂的长期项目中，上下文、验证和协作成本可能抵消一部分收益。不能用一个百分比概括全部软件工程。

瓶颈从敲代码移到理解变化

实现变快以后，团队要处理的变更数量和批次都可能增加。每个变更仍需要回答这些问题：

• 它是否符合真实业务约束；
• 新抽象是不是必要；
• 数据迁移失败时怎样回滚；
• 测试是否覆盖了没人想到的行为；
• 出现线上事故时，谁能解释和修复；
• 半年后还有没有人知道为什么这样设计。

图中流程是一般性的交付模型，不代表每个团队都使用相同阶段，也没有给出行业统一的速度比例。

DORA 的 2025 年研究把 AI 描述为组织能力的“放大器”：基础流程、平台和文化较强的团队更容易获得收益，原有弱点也可能被同步放大。DORA 在 2026 年的后续分析中还指出，生成阶段节省的时间经常转移到审计和验证；更高的 AI 使用与更高吞吐量、同时也与更高交付不稳定性相关。这里是关联关系，不等于 AI 单独造成了不稳定。

代码行数和 PR 数量为什么会骗人

一个人一天提交十个 PR，看起来像生产力提高了十倍。如果三个审查者接下来花两天理解、退回和重写，工作只是从生成者转移到了团队其他成员。

代码行数、PR 数量和“完成”的任务卡都属于局部产出指标。团队真正关心的是从需求到安全上线的完整周期，以及上线后的失败率、恢复时间、维护成本和知识是否有人掌握。

这并不意味着大改动永远错误，也不意味着技术债绝对不能欠。团队必须知道自己接受了什么风险、为什么此刻值得接受，以及准备怎样偿还。

“工程师两极分化”仍然只是预测

原文认为，AI 会扩大优秀工程师和较弱工程师之间的薪资差距。这是作者的判断，不是文章提供数据证明的结论。

现有证据只足以说明，AI 正在改变工程技能的相对价格。模板实现、样板代码和常规转换越来越便宜；需求澄清、系统建模、复杂度控制、测试设计、事故处理和技术取舍仍然需要大量上下文与责任承担。

初级工程师也不等于“只能写 CRUD”。原文自己举了相反例子：愿意追问、建立理解并检查假设的初级开发者，可能比已经放弃理解的资深开发者更可靠。风险不在职级，而在于是否把 AI 当作建立理解的工具，还是替代理解的借口。

怎样避免代码增长快过团队理解

团队可以从变更规模和知识所有权入手：

1. 要求 Agent 把任务拆成可独立审查的小改动；
2. 合并请求必须说明设计理由、替代方案和主要风险；
3. 用测试和 Eval 验证行为，不只验证代码能编译；
4. 数据库、权限和基础设施变更必须写回滚方案；
5. 生成代码的人要能不用聊天记录解释数据流和故障模式；
6. 同时衡量审查负荷、交付周期、变更失败率和恢复时间；
7. 把模型对话中的关键决定整理成团队可维护的文档。

使用 AI 并不等于放弃工程判断。真正需要警惕的是，代码已经进入生产，而团队仍不知道它为什么存在、会影响谁，以及出错后该怎么办。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 004 期整理而成。节目来源是 Florian Herrengt 于 2026 年 8 月 11 日发布的个人文章《AI is removing the middle class of software engineering》。原文以作者经历和判断为主，并不是就业市场或软件质量的统计研究；本文另外引入 GitHub、METR 和 DORA 的研究，核对“写得更快是否等于生产力更高”。

1. Florian Herrengt，2026-08-11：AI is removing the middle class of software engineering——个人经验与观点文章。
2. GitHub Research：Quantifying GitHub Copilot’s impact on developer productivity and happiness——95 名开发者完成固定 JavaScript 任务的受控实验。
3. METR，2025-07-10：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity——16 名成熟开源项目开发者、246 个真实任务的随机实验。
4. METR，2026-02-24：We are Changing our Developer Productivity Experiment Design——晚 2025 工具的后续信号、选择偏差和实验设计限制。
5. DORA，2025：State of AI-assisted Software Development——AI 使用与组织系统、吞吐量和稳定性的研究框架。

资料说明：原文关于“中间层”、薪资和就业结构的描述属于作者观点。本文补充的研究测量了不同任务和组织情境，结果不可直接互相替代，也不能用于预测单个岗位的未来。

TL;DR：2026 年 8 月 10 日提交的论文《Stealing Reasoning Traces from Proprietary LLM APIs》指出：大模型 API 返回的加密推理块可能被跨会话复用，研究者把它交给同厂商防护较弱的兼容模型处理，即可还原隐藏推理。论文归纳了四类风险，但测试限于 2026 年 7 月初的特定 API 与模型版本，结论不能直接外推到今天所有接口。

看到一段无法阅读的加密文本，人很容易把它当成“安全的乱码”。但在大模型 API 里，这类不透明数据可能保存着模型的隐藏推理、工具返回值，甚至用户输入过的敏感信息。

2026 年 8 月提交的论文《Stealing Reasoning Traces from Proprietary LLM APIs》提出了一个反直觉的风险：研究者没有暴力破解密钥，也没有直接攻破防护最严的前沿模型，而是利用加密推理块可以跨会话、跨用户和跨模型复用的特性，把它交给同一家服务商中防护较弱的兼容模型处理。

🎬 视频版（B站） ｜ 🎧 音频版（4 分 02 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

什么是“加密推理块”

推理模型在给出最终回答前，会生成较长的中间推理。服务商通常不把完整推理以明文返回，而是向客户端提供摘要，以及一段签名或加密后的不透明数据。客户端保存这段数据，并在下一轮请求时原样传回，让模型延续之前的推理状态。

论文把这种数据描述为经过认证加密的封装。它既能防止用户直接阅读，也能检测内容是否被篡改，同时让服务端不必长期保存每次会话的完整推理。

需要注意，论文作者也明确说，各服务商没有公开完整的密码学实现。因此，文章中的具体结构和密钥使用方式来自研究者的实验观察与推断，不是服务商公开的协议承诺。

问题不一定是“加密被破解”

论文发现的关键在于兼容范围过大。一个推理块可能被拿到另一段会话、另一个用户，甚至同一服务商的另一个模型中继续使用。

攻击者可以先从能力强、拒绝训练更严格的模型获得一个加密推理块，再把它送给较弱但兼容的模型。后者本来就需要合法解开并处理这类数据，研究者再诱导它把处理到的内容输出出来。

整个过程不需要知道加密密钥，也没有修改密文。真正失守的是“这段加密数据只能在原来的用户、会话和模型里使用”这一安全边界。

示意图只说明安全边界和防御方向，不包含论文中的具体攻击提示或供应商实现细节。

论文描述了四类风险

第一类是模型蒸馏。竞争者可能批量提取强模型的隐藏推理，用来训练或模仿另一个模型，绕过服务商隐藏思维过程的初衷。

第二类是敏感数据泄露。开发者公开 Agent 会话、评测轨迹或 API 日志时，常常只清理肉眼可见的文本，却保留看似无害的不透明推理块。秘密可能仍藏在里面。

第三类是拒答背后的危险内容。模型最终可能正确拒绝一个恶意请求，但隐藏推理已经处理过更具体的信息。如果推理块可以被恢复，安全的最终回答并不代表整个执行过程都没有泄露。

第四类是不可见提示注入。恶意指令可以隐藏在不透明数据中，人工审查日志时看不见，后续接手同一轨迹的 Agent 却可能读取并执行。论文把它作为概念验证和长时任务污染风险来讨论。

31 万个推理块里发现了什么

研究者从 GitHub 和 Hugging Face 收集了 6,708 条公开 Agent 轨迹，重建了 315,320 个推理块。完整论文给出的统计包括：

• 1,028 个推理块，也就是约 0.3%，包含至少一项隐私泄露；
• 328 条轨迹，也就是 6,708 条中的 4.9%，至少泄露过一项真实敏感信息；
• 在排除基准测试身份后的真实用户会话中，研究者去重得到 704 项隐私数据；
• 其中包括 62 个 API Key、33 个密码、24 个访问令牌、7 个私钥和 30 个个人邮箱；
• 64 项数据只出现在隐藏推理中，没有出现在可见聊天记录里。

论文摘要还用另一组分类口径概括为 367 项个人身份信息和 182 项凭据。不同数字对应不同分类、去重和数据范围，不能直接相加，也不能理解成同样数量的独立受害者。

研究样本来自公开轨迹，不是对整个互联网或所有生产系统的普查。论文也使用两阶段自动分类筛掉占位符和测试数据，但这仍是一项定向研究，不是完整的泄露率调查。

为什么“我已经清理日志”仍可能不够

论文给出的一个典型风险是会话清理：用户要求 Agent 删除仓库中的秘密，模型在隐藏推理中重新读取并复述这些值；最终可见回答只说“已经清理”，但不透明推理块仍可能保留原值。

因此，只搜索最终回答里的 API_KEY 或密码格式并不够。共享原始 API 记录前，还需要删除 signature、thinkingSignature、encrypted_content 等不透明推理字段。字段名称会随供应商和 SDK 改变，不能依赖一份永远不变的黑名单。

如果含有此类数据的会话已经进入公开 Git 仓库，删除最新文件也不代表历史提交消失。应当检查 Git 历史、缓存、制品和数据集副本，并轮换可能已经暴露的凭据。

论文有哪些限制，漏洞现在还存在吗

这篇论文是 2026 年 8 月 10 日提交的 v1 预印本。实验针对 2026 年 7 月初的 Anthropic、OpenAI 和 Google API 版本，服务商可以在不公告的情况下改变内部实现。

作者无法看到隐藏推理的真实明文，因此不能逐字证明每次提取都完全正确。他们主要用 API 报告的思考 token 数量与恢复文本的 token 数量做对照，并在 120 个 Codeforces 问题上观察到较强的一致性。这是提取可信度的证据，但不是完整的明文真值验证。

论文还说明，团队在发表前已向相关模型服务商、Microsoft 和 Hugging Face 负责任披露。作者报告说，各服务商确认收到报告，此后他们已经无法用相同方法继续发动攻击。这说明供应商可能采取了缓解措施，但不能据此推断所有历史数据已经安全，也不能证明所有相邻攻击面永久消失。

服务商和开发者分别能做什么

论文建议服务商使用多层防御：

1. 把完整推理留在服务端，客户端只拿随机句柄；
2. 在认证加密中绑定用户、会话、模型、前序提示和对话历史；
3. 在 API 网关阻止跨模型推理块；
4. 为异常重放提供签名或密钥撤销机制；
5. 训练模型拒绝输出隐藏推理，并监控异常提取模式。

更严格的上下文绑定会影响合法的会话压缩、历史编辑和模型切换，因此不是简单增加一个字段就能完成。即使绑定正确，只要某个模型必须解开并处理旧推理，模型级提示攻击仍可能成为风险，所以需要纵深防御。

开发者现在可以做这些事：

• 把不透明推理块当作敏感数据，而不是普通日志；
• 发布会话、轨迹或复现包前，删除完整推理字段；
• 不把未经验证的外部推理块传给 Agent；
• 检查已经公开的仓库与历史提交，必要时轮换凭据；
• 在日志策略里明确区分可见回答、工具结果和隐藏推理载荷。

密文不是废数据，也不是天然安全的秘密存储。看不懂一段内容，只说明人无法直接阅读，并不代表系统中的其他组件也无法处理它。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 003 期整理而成。事实来源是 Alexander Panfilov 等 8 位作者于 2026 年 8 月 10 日提交的 arXiv 预印本及作者项目页。论文测试的是 2026 年 7 月初可用的特定 API 和模型版本，不能直接代表今天所有接口仍然存在相同行为。

1. Alexander Panfilov、David Schmotz、Ilia Shumailov 等，2026-08-10：Stealing Reasoning Traces from Proprietary LLM APIs
2. arXiv：论文 HTML 全文——包含威胁模型、实验结果、限制、披露过程和缓解方案。
3. 论文作者：Stolen Thoughts 项目页——论文结果的交互式说明；示例中可能包含安全研究材料，阅读时不要复制其中的攻击提示或凭据样例。

资料说明：本文的技术结论和数字均来自论文 v1。论文作者报告的攻击状态、供应商范围和缓解结果具有时间性，后续版本或服务商更新可能改变结论。

TL;DR：NVIDIA 于 2026 年 8 月 11 日发布的 Nemotron 3.5 Lightning 与 NeMo Switchyard，瞄准的是 AI Agent 的模型路由问题：让规划等复杂步骤用强模型，工具调用、格式整理等步骤交给更小更便宜的模型。本文同时核对了评测边界、降本数字的前提，以及仓库仍标注 pre-alpha 的现实——它值得跟踪，但还不是能直接上生产的组件。

一个 AI Agent 真正运行起来以后，并不是每一步都需要最强模型。制定计划、处理复杂异常，可能值得调用能力最强的模型；执行工具、检查返回值、整理格式和重复查询，往往更在意速度和成本。

如果所有步骤都交给同一个昂贵模型，效果容易预测，账单和延迟却会迅速增加。反过来，如果只用便宜模型，复杂任务又可能失败。模型路由想解决的，就是如何在这两种选择之间分工。

🎬 视频版（B站） ｜ 🎧 音频版（5 分 53 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

Agent 不只需要一个模型

传统聊天产品通常把一次请求交给一个固定模型。Agent 的情况不同：它可能先规划，再调用工具，读取结果，修正计划，最后生成答案。一次任务里会出现很多性质不同的步骤。

NVIDIA 把这种架构称为“模型系统”：前沿推理模型负责规划和编排，小而快的模型承担代码检查、工具调用、安全告警监控和账单查询等高频工作。这个思路并不要求小模型取代大模型，而是让每种模型做自己更合适的事。

Nemotron 3.5 Lightning 小在哪里

Nemotron 3.5 Lightning 是一个 300 亿参数的混合专家模型（MoE），但每个 token 只激活约 30 亿参数。可以把它理解成一个拥有多个专家小组的组织：总知识容量仍然较大，每次任务只叫少数专家参与，因此单次计算量接近更小的稠密模型。

NVIDIA 的技术文章称，它针对长期运行 Agent 的高频执行层设计，并使用多 token 预测、推测解码和量化等手段提高吞吐量。官方公布的结果包括：

• 相比同级模型，输出速度最高可达 4 倍；
• 在 PinchBench 上达到 86% 准确率，完成 1 万个任务的时间比 Qwen3.6 35B 快 30%，同时保持接近的准确率；
• 提供 BF16 和 NVFP4 检查点，可用于本地和数据中心部署。

这些都是 NVIDIA 选择的测试条件和对照模型，适合用来理解产品定位，不能直接换算成任何业务的固定收益。真实效果仍取决于任务分布、推理框架、硬件、并发量和输出长度。

Switchyard 不只是一个“选模型”按钮

NeMo Switchyard 是一个用 Rust 编写的代理和路由库。它能在不同模型与供应商之间分配请求，也负责 OpenAI Chat、OpenAI Responses 和 Anthropic Messages 等接口格式之间的转换。

仓库目前提供多种路由方式：

• 用一个分类模型判断请求应该进入强模型还是弱模型；
• 根据工具结果、错误等会话信号分阶段路由；
• 先让弱模型回答，再由评审决定是否升级；
• 按固定比例随机分流，用于 A/B 测试；
• 编写自定义算法，把质量、延迟和成本偏好放进自己的规则。

这张图表示一般性的模型路由结构，不代表 Switchyard 会自动识别所有任务，也不表示三类模型一定同时存在。

路由器本身也会消耗资源。真实总成本不仅包括最终模型调用，还包括路由判断、额外分类模型、缓存补齐、失败重试和升级调用。若没有统一的质量门禁，所谓“节省成本”可能只是把错误推迟到后面。

那些漂亮的降本数字该怎么看

NVIDIA 公布的内部基准称，Switchyard 在保持前沿级准确率的同时，可把任务完成成本降到单独使用 Opus 4.8 的近三分之一。合作方数据中还有两组很醒目：

• LangChain 在 145 个多轮 Deep Agents 任务中，只把 7% 的调用交给前沿模型，成本降低 74%，但准确率下降了 6%；
• Ramp 报告称，在其 SWE-Bench 场景中，成本降低 58%，运行时间减少 33%，同时匹配前沿模型表现。

这些结果说明模型路由有潜力，但它们来自 NVIDIA 及合作方披露，并不是对所有任务的独立保证。尤其要注意 LangChain 的结果并非“质量完全不变”，而是用 6% 的准确率差异换取明显的成本下降。

评估路由器时，至少要同时看四项指标：正确率、端到端延迟、完整任务成本和失败后的恢复成本。只比较单个 token 价格，往往会漏掉路由判断和重试。

换模型会不会毁掉提示缓存

Hacker News 讨论中，争议最大的问题之一是提示缓存。批评者认为，同一会话不断切换模型，会让已经积累的 KV Cache 失效，抵消便宜模型省下的成本。

社区里也有人给出另一种解释：每个模型可以维护自己的缓存；重新切回某个模型时，只需要为它补上缺失的对话增量，而不是每次从头处理全部上下文。这样做仍然需要额外 prefill，而且缓存不能在结构不同的模型间直接共享，但较便宜模型承担更多生成工作后，整体仍可能节省费用。

这段讨论不能当作 Switchyard 的官方缓存承诺。它更像一个提醒：模型池大小、会话黏性、缓存策略和路由频率必须一起设计。模型选得越多，路由器越复杂，未必越划算。

新闻稿很积极，仓库却写着 pre-alpha

截至 2026 年 8 月 28 日，Switchyard 仓库仍把整个项目标为 pre-alpha，并提醒 API 和算法在 1.0 之前可能大幅变化。各组件的成熟度也不同：libsy 标为 Beta、可试验性集成；客户端和 runner 仍是 Alpha；switchyard-server 是演示服务器，明确不建议用于生产环境。

这与新闻稿中的“部署”“企业使用”并不完全矛盾：合作方可能使用的是内部集成、特定组件或受控试验，并不等于公开仓库中的演示服务器已经具备生产条件。对普通开发团队来说，更合理的起点是离线评测或旁路实验，而不是立刻替换线上网关。

真正动手前，先准备一张自己的路由表

如果要验证模型路由，可以从一个很小的模型池开始：一个擅长复杂规划的模型，一个便宜快速的执行模型，再加明确的升级条件。

建议先完成下面几件事：

1. 从真实日志中整理任务类型，不要凭想象分类；
2. 用同一批任务建立单模型基线，包括质量、延迟和总成本；
3. 为每种路由结果记录选中了谁、为什么选、是否升级以及最终是否成功；
4. 单独测量长会话下的缓存命中率和补齐成本；
5. 为路由错误准备回退方案，并把重试也计入成本。

好的路由器不会一味选择最便宜的模型。它应当使用可验证的规则，把昂贵能力留给确实需要它的步骤。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 002 期整理而成。节目讨论的主要来源是 NVIDIA 于 2026 年 8 月 11 日发布的 Nemotron 3.5 Lightning 与 NeMo Switchyard 资料，并加入了对项目成熟度、评测边界和 Hacker News 社区争议的核对。

1. Kari Briski，NVIDIA，2026-08-11：NVIDIA Nemotron 3.5 Lightning and NeMo Switchyard Deliver Faster, Smarter, More Efficient Agentic AI
2. Chris Alexiuk、Chintan Patel，NVIDIA Technical Blog，2026-08-11：NVIDIA Nemotron 3.5 Lightning Delivers Fast, Accurate Specialized Task Execution for Long-Running Agents
3. NVIDIA-NeMo：Switchyard GitHub 仓库——功能、路由策略、许可证与成熟度说明。
4. Hacker News：Nvidia Nemotron 3.5 Lightning and NeMo Switchyard——社区关于缓存、路由开销和产品成熟度的讨论；评论不代表已经验证的事实。

资料说明：性能和合作方数据主要来自 NVIDIA 官方材料，本文已保留测试主体、对照对象与准确率差异。关于缓存的内容来自社区讨论，只作为工程问题线索，不作为 Switchyard 的官方保证。

TL;DR：大语言模型并没有在脑中储存现成文章，它的核心机制是根据上下文反复预测下一个 token：这让它能流畅接话、解释概念，也解释了它为什么会在缺乏依据时，用同样笃定的口吻编造人名、论文和日期。理解这一点，就能理解它为什么“像人”，却并不可靠。

第一次和大语言模型聊天，很容易产生一种错觉：屏幕另一端像是坐着一个读过无数书、什么都能聊的人。它能续写邮件，能解释概念，也能顺着语气安慰你。可一旦追问一个冷门事实，它又可能用同样笃定的口吻编出不存在的人名、论文和日期。

这两种表现并不矛盾。要理解它，先放下“电子大脑”这个比喻，把它想成一位特别擅长接话、但不会自动查证的咖啡馆店员。

🎬 视频版（B站） ｜ 🎧 音频版（4 分 14 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇

一句话版本：它在反复预测下一个 token

假设你说：“今晚下雨，出门记得带……”

人很容易想到“伞”。语言模型做的事情与此有一点相似，但规模大得多：它先把输入切成一组 token，再结合前面的上下文，为下一个 token 计算概率。选出一个之后，它把这个 token 加回上下文，继续预测下一个，直到回答结束。

token 不一定等于一个完整汉字或单词。它只是模型处理文字时使用的基本单位；具体怎样切分，取决于模型采用的分词方法。

图中的候选词和概率只是工作原理示意，不是某个真实模型的测量结果。

2017 年的论文 Attention Is All You Need 提出了 Transformer 架构。它通过注意力机制处理序列中不同位置之间的关系，后来成为大语言模型的重要技术基础。2020 年的 Language Models are Few-Shot Learners 则展示了 GPT-3 这类自回归语言模型在扩大参数和训练数据规模后，可以仅凭文字指令或少量示例完成多种任务。

所以，“预测下一个 token”听起来很朴素，却不代表模型只能做简单的句子补全。模型从大量训练文本中学到语法、文体、概念之间的关联，以及常见的推理表达方式。当这些规律共同参与一次预测时，结果就可能表现为写作、问答、翻译或代码生成。

它不是在脑中翻找一篇现成文章

另一个常见误解是：模型先把互联网背下来，回答时再从某个数据库里找到对应段落。

训练确实可能让模型记住部分内容，尤其是重复出现或具有独特表达的文本。但通常情况下，训练材料中的语言规律会被编码进大量参数。生成回答时，模型根据参数和当前上下文计算后续内容，不是在资料库中逐条检索。

这里需要区分基础语言模型和完整的 AI 产品。一个产品可以在模型外部接入搜索引擎、知识库、计算器或其他工具。此时你看到的答案可能同时包含模型生成和外部检索结果，但检索能力不是“预测下一个 token”天然附带的事实核验机制。

它会用语言，但“理解”仍有争议

模型能正确处理“下雨”和“带伞”的关系，是否就说明它理解雨是什么？

这个问题没有一句公认的结论。Emily M. Bender 和 Alexander Koller 在 2020 年的论文 Climbing towards NLU 中强调，学习语言形式与获得由现实经验支撑的意义不是一回事。模型可以熟练处理词语之间的关系，却没有淋雨、撑伞或被冷风吹过的身体经验。

另一方面，只用“随机鹦鹉”也不足以描述今天模型表现出来的全部能力。它确实掌握了强大的语言模式处理能力，但不能据此直接推断它拥有人的意识、感受或理解方式。

为什么它会一本正经地编答案

模型的基本目标是生成在当前上下文中看起来合适的后续，而不是保证每句话都经过外部证据核对。如果问题含糊、训练材料不足，或者错误说法在语料中很常见，它仍可能生成连贯但不真实的答案。

2021 年的 TruthfulQA 用 817 个问题测试模型是否会复述人类常见的错误观念。在当时接受评测的模型中，最佳结果有 58% 的回答被判定为真实，而人类基线为 94%。这组数字不能代表今天任何具体产品的水平，但它说明了一个长期存在的问题：语言流畅度和事实真实性不是同一个指标。

因此，遇到下面这些内容，不要因为语气自信就直接采用：

• 具体日期、数字、论文名称和引用；
• 医疗、法律、财务等高风险建议；
• 冷门人物、机构和历史事件；
• 无法打开或无法在其他来源中找到的链接。

普通人怎样用得更稳妥

把语言模型当成一个反应很快、知识面很广、但偶尔会硬撑的助理，通常比把它当成权威更合适。

适合交给它的工作包括改写文字、整理材料、列出备选方案、模拟提问和解释概念。涉及重要事实时，可以要求它区分“已知事实”“推测”和“不确定项”，列出可核验的来源，再由人打开原始资料确认。

提问也不需要背诵所谓的“提示词咒语”。说明读者是谁、想解决什么问题、有哪些限制，再给一个例子，往往就能明显改善结果。与此同时，不要随手提交身份证号、病历、公司机密或未公开代码；能否输入某类数据，应以所在组织的制度和所用产品的数据政策为准。

使用时记住：它很会生成答案，但“很像答案”不等于“答案是真的”。

收看本期节目

视频版

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 001 期访谈整理而成。该期节目从科普主题出发，并非改写某一篇原文；文末补充了 Transformer、GPT-3、语言理解争议和真实性评测的原始论文。

1. Ashish Vaswani 等，2017：Attention Is All You Need——Transformer 架构原始论文。
2. Tom B. Brown 等，2020：Language Models are Few-Shot Learners——GPT-3 与少样本学习论文。
3. Emily M. Bender、Alexander Koller，2020：Climbing towards NLU: On Meaning, Form, and Understanding in the Age of Data——语言形式、意义与“理解”的讨论。
4. Stephanie Lin、Jacob Hilton、Owain Evans，2021：TruthfulQA: Measuring How Models Mimic Human Falsehoods——语言模型真实性评测。

资料说明：节目第 001 期原始 sources.json 只记录了“向不懂技术的人解释大语言模型”这一主题，没有外部 URL。以上论文由本文编辑阶段补充，用于说明相关技术背景和争议，不代表节目逐句改写这些论文。

最近看了 Matt Pocock 的一段视频：

视频只有 15 分钟，讲的却不是某个新模型或提示词技巧，而是一个更基础的问题：让 AI 参与一个已有代码库时，怎样避免每次都从头解释业务名词和历史决定？

Matt 之前的 /grill-me 会持续追问，把模糊的想法问到可以执行。它并没有失效；问题在于，单靠一轮轮问答，已经确认过的概念不会自动成为项目的一部分。下一次会话里，人仍可能要解释“独立视频”到底指什么、某个对象之间是一对一还是一对多、这个状态能否随意切换。

他现在在编码场景中改用 /grill-with-docs。它保留追问，但把共同语言和不容易看懂的决策写进仓库。这样，聊天记录不再是唯一的上下文。

单纯追问，为什么还不够

视频中的例子是一项新功能：在一个管理课程和视频的应用里加入 pitch。这里的 pitch 不是代码里的通用术语，而是视频的“包装”——标题、描述和对外呈现方式；团队会先想出多个 pitch，再选择其中一些制作成视频。

人一听就能根据上下文补全很多含义，AI 却没有这种默认背景。例如：

• standalone video 是不属于课程或课时的视频，还是“尚未关联 pitch 的视频”？
• 一个 pitch 能否对应多个视频？一个 pitch 是否可以暂时没有视频？
• 删除 pitch 时，是连带删除、禁止删除，还是归档？
• idle、scheduled、shipped 是强制流转的状态机，还是可以手动修改的标签？

这些不是措辞洁癖。它们会影响数据库关系、删除规则、变量名、文件名、界面分组和后来的人怎样理解代码。若定义只存在于某次聊天里，之后每一次让 AI 修改相关部分，都会重新产生猜测空间。

把“共同语言”写成 context.md

/grill-with-docs 借用了领域驱动设计（DDD）中的“通用语言”思路。它会先寻找 context.md，读取其中的术语和定义；在对话中发现概念不清、用词冲突或新规则时，再要求人确认并更新这份文件。

在视频里，context.md 至少承担三件事：

1. 说明这个代码库在解决什么问题；
2. 定义关键实体、状态和关系，例如课程、版本、独立视频与 pitch；
3. 为不熟悉项目的人和 AI 提供同一份可查阅的词汇表。

它不需要写成一份覆盖全部实现的百科全书。视频里的建议更接近 DDD 的 bounded context：一个大型 monorepo 可以有 context map 和多个上下文；如果一个仓库内大家说的是同一种业务语言，一份放在根目录的 context.md 就够用。

关键不在文件名，而在约束：产品、代码和与 AI 的对话尽量用同一个词。否则，文档里叫“已投递视频”，数据库表叫 standalone_videos，界面又叫“提案视频”，AI 很难判断它们到底是不是同一个东西。

共同语言需要在每次新需求中核对和更新；它不是一次写完就不再变化的说明书。

先核对词义，再讨论实现

/grill-with-docs 不会读完文档就直接生成代码。它会先把新需求同既有术语表对照，指出含义不清或冲突的地方，并通过具体场景把问题问出来。

视频的演示依次确认了：

• pitch 与独立视频是一对多关系；
• 有 pitch 的视频仍属于独立视频，pitch 是它的元数据，而不是另一类视频；
• pitch 允许暂时不关联任何视频；
• 状态目前可手动调整，自动流转以后再加；
• 由于作者更倾向归档而非删除，删除关系选择限制删除。

这些回答随后写回 context.md。作者也展示了一个很现实的细节：写入后产生了 pitched standalone video、unattached standalone video 之类别扭的名称。他没有假装第一版术语一定正确，而是提醒自己在“足够清楚”时停止讨论，后续需要时再重构。

这条边界很重要。共同语言的目的不是无限讨论命名，而是让接下来的实现少一点误解。

还有一类信息：为什么当时这样选

词汇表能定义“是什么”，却不总能解释“为什么”。视频把这类信息交给 ADR（Architecture Decision Record，架构决策记录）。

ADR 适合记录那些不看背景会觉得奇怪、又难以轻易撤回的选择：它面临过什么取舍、会带来什么后果。库选型这类容易替换的决定未必值得专门写 ADR；删除策略、数据关系或会影响多个模块的业务定义，通常更值得留下理由。

这也避免 AI 看到一个非直觉的实现时，自作主张把它“优化”掉。它能先读到决策背景，再判断当前需求是否真的要求改变它。

context.md 保存“是什么”，ADR 保存“为什么这样选”。

确认过的含义怎样留在项目里

Matt 的观察是：定义稳定后，AI 不必反复解释同一个概念，回复会更简洁；代码中的命名和规划文档也会更容易互相检索。这是他在工作流中的经验，而不是对所有模型和项目都成立的性能测试结果。

确认过的业务含义不必停在对话记录里。把它记录到仓库后，下一位开发者、下一次会话和后续生成的代码，都从同一份上下文开始。

从视频可以整理出一套小而可用的做法：

1. 新功能开始时，只列出会影响数据、界面或规则的核心名词；
2. 为每个名词写简短定义，并给一个能区分边界的例子；
3. 让 AI 先检查这些词与现有代码、文档是否冲突，再进入实现；
4. 把难以撤回的决定和取舍写成 ADR；
5. 当名称已经能支持当前工作时继续开发，别为了完美命名无限停留。

这里的重点不是复制某个斜杠命令。即使不用这两个 skill，团队也可以建立同样的习惯：把 AI 提出的关键歧义当作待确认的产品或技术问题；确认后更新共享文档，而不是只在聊天窗口里回答一次。

/grill-me 并没有被淘汰

视频最后给出了一条很清楚的使用边界：有代码库时，优先用 /grill-with-docs；没有代码库的开放式任务，则继续用 /grill-me。作者还举了非工程场景的例子：有人用后者整理为母亲写悼词时的回忆，价值就在于耐心追问，而不是建立术语表。

项目刚开始时，作者仍倾向 /grill-with-docs，因为这恰好是最需要建立共同语言的阶段。差别不在于有没有足够多的代码，而在于这次对话是否要留下能被后续工作复用的领域知识。

让 AI 写代码之前，把项目里的词说清楚，看起来比直接输入需求慢一点。但当这些词会进入表名、组件名、接口和用户界面时，早一点确认往往比之后在许多文件里改名更便宜。

两个账号应各自使用独立的本地状态目录；它们可以同时工作，但不共享认证和会话。

一个人同时有个人和工作两个 OpenAI 账号时，最容易踩的坑不是登录，而是登录之后。默认情况下，Codex CLI 把认证、配置、会话和本地状态都放在同一个目录。后一次登录会让下一次启动的 CLI 使用新的身份；MCP、插件和会话历史也混在一起。

我在 macOS 上用 codex-cli 0.145.0 核对过这个行为。Codex 的配置源码把 CODEX_HOME 定义为全部本地状态的根目录：默认是 ~/.codex，设置后会改用指定目录。源码中的说明 也说明日志和 SQLite 状态会随这个目录变化。

这意味着可以把“个人”和“工作”当成两套独立的 CLI 环境，而不是在同一套配置里反复登录、退出。

这不是原生的多账号切换

先把边界说清楚。Codex CLI 还没有类似 --account work 的正式账号选择器；官方仓库中相应的功能请求仍是开放状态。该请求 本身也把现状描述为：默认只有一个本地状态目录，多账号只能换目录、换认证文件或重新登录。

所以 CODEX_HOME 的作用不是把两个账号放进一个账号列表里。它做的是把两套状态彻底分开：

• 个人账号有自己的认证、配置、MCP、Skills、插件和会话记录；
• 工作账号也有自己的一套；
• 两个终端可以同时运行，各自读取自己的 SQLite 状态库；
• 已经启动的 Codex 不会在运行中切换身份。要换账号，必须从对应入口启动新的 CLI 进程。

这比手动替换 ~/.codex/auth.json 稳妥得多，也更容易查清一条会话究竟用了哪个身份。

建两个独立目录，再分别登录

下面示例用两个目录保存状态。目录名只表示用途，不会把账号名称传给 OpenAI：

mkdir -p "$HOME/.codex-profiles/personal" "$HOME/.codex-profiles/work"

# 首次使用个人环境时登录个人账号
CODEX_HOME="$HOME/.codex-profiles/personal" codex login

# 首次使用工作环境时登录工作账号
CODEX_HOME="$HOME/.codex-profiles/work" codex login

以后从相同的入口启动即可：

# 个人环境
CODEX_HOME="$HOME/.codex-profiles/personal" codex

# 工作环境
CODEX_HOME="$HOME/.codex-profiles/work" codex

登录完成后，分别检查状态：

CODEX_HOME="$HOME/.codex-profiles/personal" codex login status
CODEX_HOME="$HOME/.codex-profiles/work" codex login status

如果日常经常在两个环境间切换，可以给终端写两个别名或两个很短的启动脚本。关键不是别名的名字，而是每个入口固定指向一个目录。涉及外部操作，例如创建 PR、发消息或使用带权限的 MCP 工具时，先看当前终端来自哪个入口。

不要复制或软链接 auth.json

看上去最快的做法，是先在默认目录登录一次，再把 auth.json 复制到另一个目录。这个方法不可靠。

复制的认证文件可能在另一个副本刷新 refresh token 后失效；两个目录应分别登录。

Codex 使用的 OAuth refresh token 可能是一次性的：当一个副本刷新 token 后，另一个副本里的旧 token 会失效。官方仓库已有复现说明：复制认证文件后，第一次可能还能使用缓存的 access token，之后可能出现 401。问题 #15410 还明确指出，用软链接或复制文件来共享 ChatGPT 订阅认证都不是稳定方案。

每个目录各自执行一次 codex login。不要从另一套环境复制认证文件，也不要把认证文件纳入 Git、网盘同步或备份脚本。

配置隔离带来的实际影响

账号隔离不是只多两个 auth.json。新目录一开始没有你原来配置过的 MCP server、插件、Skills、偏好设置或历史会话。这既是代价，也是这个办法有用的原因。

我通常会把配置分成两类：

1. 与身份无关、也不含密钥的通用设置，可以用一个受版本控制的模板维护；
2. 包含公司地址、MCP OAuth 登录状态、访问令牌或本机路径的设置，只放在对应环境里。

这样做的好处是，工作账号不会意外加载个人的高权限工具，个人会话也不会写进公司的历史记录。代价是第一次使用时要分别安装或配置真正需要的工具。

要注意，本文只讨论从终端启动的 Codex CLI。桌面端、IDE 扩展和其他 GUI 进程未必会继承终端环境变量；不能因为 CLI 被隔离，就假定它们也已经切换到同一账号。它们应单独核对登录状态和凭据位置。

适合的使用场景和不适合的使用场景

这个办法适合把合法且明确授权的身份分开，例如个人订阅与公司账号、两个客户提供的独立账号，或需要避免配置互相污染的测试环境。

它不应用于自动探测额度、在账号受限后自动切到下一个账号，或把多个账号的额度当作一份可轮换的资源。OpenAI 的服务条款禁止规避速率限制、使用限制和保护措施；个人账号也不应与他人共享凭据。OpenAI Terms of Use

如果目标只是让日常开发时的个人、工作上下文互不干扰，两个目录、两次独立登录和两个固定启动入口已经够用。它没有魔法，也不会扩大任何一个账号的权限或额度；它只是把本来会混在一起的本地状态分开保存。

**来源与核验范围：**本文基于 codex-cli 0.145.0 在 macOS 上的本地检查，以及 OpenAI 公开的 Codex 配置源码、多账号需求讨论、认证文件复制问题 和 服务条款。Codex 的行为和条款可能更新；实际配置前请以本机 codex --help 与当前条款为准。

2015 年，我做过一款很小的 iOS App，中文名叫「闪印」。它只解决一件事：把旅行、采购或工作清单整理好，预览，然后打印到纸上。

旧版用 Objective-C 和 Storyboard 开发，后来陆续支持了 iPad、iPhone Xs Max 和 iCloud。它没有复杂的账号系统，也不试图成为项目管理工具。清单建好，纸张打出来，任务就完成了。

十一年后，我重新打开这个项目，决定用 SwiftUI 把它重写一遍。新版项目叫 PrintableCheckList-SwiftUI，代码已经开源。

这次重写不是给旧界面换一层 SwiftUI。我要保留原来的用途，也要回答一个新问题：如果 AI 能帮人省掉大量录入工作，一份「可打印清单」今天应该怎么做？

它现在能做什么

PrintableCheckList 仍然可以完全手动使用。你可以创建多份清单，一次粘贴多行内容，编辑、删除或拖动排序，再生成带方框的打印预览，通过 iOS 系统打印控制器输出。

AI 是可选的快捷入口。比如输入：

生成一份带孩子去北海道旅行 7 天的冬季行李清单，需要考虑滑雪和儿童常用药。

App 会返回清单标题和项目。结果不会立刻写入数据，而是先进入编辑页；你可以改标题、删掉不需要的内容、补上个人物品，确认以后再保存。AI 也能给现有清单补充遗漏项，不必每次从头生成。

整个过程可以概括为：

输入主题
  ↓
按需联网搜索
  ↓
模型返回结构化 JSON
  ↓
去重、限长、清理序号
  ↓
用户检查和修改
  ↓
保存到本地 → 预览 → 打印

这里最重要的一步不是「生成」，而是生成后的确认。模型负责减少输入，用户仍然决定最后打印什么。

清单不只是待办事项

接入 AI 时，我很快遇到一个看似简单的问题：用户说「全球票房前十名」时，他要的是十部电影，不是「查询票房」「核对排名」之类的十个任务。

因此，内置提示词会区分两类内容：

• 准备事项、操作步骤和计划，要生成简短、可执行的清单项；
• 排行榜、目录和资料列表，要直接返回条目本身，并保留顺序和用户指定的数量。

模型必须返回固定的 JSON 结构。App 还会清理 Markdown 围栏、编号和重复内容，限制标题与项目长度。补充已有清单时，已经存在的项目也会被过滤掉。

这些处理不显眼，却决定了 AI 生成的内容能不能真正进入一个普通 App，而不是停留在聊天窗口里。

给时效性问题增加联网查证

旅行行李清单通常不需要搜索，但「最新票房排行」「最近发布的产品」或「当前汇率」不同。只靠模型已有知识，很容易得到过期答案。

PrintableCheckList 提供三种搜索模式：

• 自动：识别排行、新闻、天气、价格等时效性主题，只在需要时搜索；
• 始终搜索：每次生成前都先查资料；
• 关闭：直接使用模型生成。

目前 GLM 通过 Web Search API 搜索，OpenAI 通过 Responses API 的 Web Search 搜索。搜索结果会先整理成一段带来源的材料，再交给清单生成器。结果页显示来源链接，但来源不会混进最终的清单项。

DeepSeek 和自定义 OpenAI 兼容服务仍可生成清单，只是不启用这条原生搜索路径。这样没有假设所有 /chat/completions 服务都支持同一种联网工具。

BYOK：API Key 留在用户设备上

新版采用 BYOK（Bring Your Own Key）模式。用户可以选择 GLM、OpenAI、DeepSeek，或填写自己的 OpenAI 兼容服务地址和模型名称。

API Key 存在 iOS Keychain，访问级别为 WhenUnlockedThisDeviceOnly。普通配置存入 UserDefaults，但不会包含 Key。生成请求和必要的搜索请求由设备直接发给用户选择的服务商，不经过开发者服务器。

没有配置 AI 也不影响手工创建、编辑、预览和打印。我坚持保留这条边界。AI 应该缩短输入时间，不应该变成打开清单 App 的通行证。

本地优先，也照顾旧用户的数据

每次编辑都会先保存到设备的 Application Support/PrintableCheckList/projects.json。没有网络时，清单的创建、修改和打印都能继续使用。

可选的 iCloud 路径使用 NSUbiquitousKeyValueStore，沿用旧版的 keyProjects。代码也保留了原来的 bundle identifier，并实现了 NSKeyedArchiver 迁移：旧 Objective-C 里的 Project 和 Item 会转换成新的 Codable Swift 模型；旧 ID 不是 UUID 时，则生成稳定的 UUID。

这部分比重新画界面麻烦得多，却是一次真正的 App 更新必须承担的责任。重写代码不应该等于让用户重新输入数据。

需要说明的是，未签名模拟器不能代替真实 iCloud 环境。仓库已经覆盖旧数据导入和同步逻辑测试，但签名真机上的 iCloud 端到端验证仍然是发布前检查项。

打印仍然是主角

虽然新版加入了 AI，项目名称里的 Printable 没有变。

预览页使用 SwiftUI 显示标题、项目和空白方框；真正打印时，App 生成一段经过 HTML 转义的排版内容，再交给 UIPrintInteractionController。iPad 上还单独处理了打印弹窗的锚点，避免 popover 因缺少来源视图而崩溃。

测试中还会把默认中文旅行清单交给打印格式化器，确认它能排在一张 A4 纸内。相比「按钮能点」，这更接近 PrintableCheckList 真正要完成的事情。

工程本身也换了一种维护方式

新版最低支持 iOS 17，使用 SwiftUI 和 Swift Concurrency。工程文件由 XcodeGen 根据 project.yml 生成，.xcodeproj 不进入版本库。生成、构建、测试、模拟器运行和归档分别有独立脚本，日常开发不必手动维护 Xcode 工程里的文件引用。

截至 2026 年 7 月 22 日，我在 iPhone 16 Pro / iOS 18.5 模拟器上执行了完整测试：42 个测试用例中，41 个通过，1 个 Keychain 用例因为无签名模拟器缺少 entitlement 而按预期跳过。覆盖范围包括：

• 清单的创建、编辑、排序、持久化和旧数据迁移；
• 打印内容转义与 A4 分页；
• AI 配置、Key 隔离、响应解析、去重和错误映射；
• GLM 与 OpenAI 的联网搜索请求和来源解析；
• 手工创建、AI 新建、AI 补充、取消、失败重试和设置页等 UI 流程。

本地运行

需要 macOS、Xcode、iOS 模拟器和 XcodeGen。克隆后运行：

git clone https://github.com/terryso/PrintableCheckList-SwiftUI.git
cd PrintableCheckList-SwiftUI
./Scripts/generate.sh
./Scripts/build.sh

执行完整测试：

./Scripts/test.sh

安装并启动模拟器版本：

./Scripts/run-simulator.sh

AI 配置不是运行项目的前提。你可以先把它当作一款普通的本地清单 App，之后再决定要不要填入自己的 API Key。

写在最后

软件重写很容易让人只关注新框架、新界面和新功能。但回到 PrintableCheckList，真正不能丢的只有两件事：旧数据还在，清单还能顺利打印。

SwiftUI 让界面和状态管理简单了很多，AI 让创建清单更快，联网搜索让时效性内容有了核对来源。不过这些能力最后都服务于一个很朴素的动作：拿起一张纸，照着清单去做事。

项目地址：github.com/terryso/PrintableCheckList-SwiftUI

如果你是 Swift 开发者，又想把自己 Mac 上的能力（本地文件、Shortcuts、Xcode 项目、Core Data 数据……）暴露给 Claude、ChatGPT 这类 AI 助手，那么 MCP Server 就是你要的东西。而目前主流的 MCP 教程几乎都是 Python 或 TypeScript，Swift 版本极少——这也让 “swift mcp server” 成为一个几乎无人竞争的关键词。

本文用一个能跑通的最小示例，带你从零构建一个 Swift MCP Server，并接入 Claude Desktop。

什么是 MCP Server？

Model Context Protocol (MCP) 是 Anthropic 在 2024 年底提出的开放协议，用来标准化 “LLM 应用 ↔ 外部工具/数据源” 之间的通信。你可以把它理解成 “AI 应用的 USB-C”：

• MCP Host：AI 应用（Claude Desktop、Cursor、Codex CLI……）
• MCP Client：Host 内部为每个连接建立的会话客户端
• MCP Server：你写的进程，向 Host 暴露 tools、resources、prompts

协议本体是基于 JSON-RPC 2.0 的双向消息，通过两种传输承载：

对本地 Mac 工具来说，stdio 是默认选择。

为什么用 Swift 写 MCP Server？

多数教程默认 Python/Node，但用 Swift 有几个独特优势：

1. 原生调用 macOS API：EventKit、Contacts、AppKit、Core Data、Shortcuts、ScreenCaptureKit……不需要 shell 桥。
2. 单文件可执行：swift build -c release 产出一个静态二进制，Claude Desktop 直接 spawn，无 Python 环境依赖。
3. 强类型 + async/await：JSON-RPC 消息用 Codable + enum 建模，工具 handler 天然并发安全。
4. 和 Xcode / SwiftUI 项目共享代码：同一份 Package 里既能被 App target 用，也能被 MCP server target 用。

架构总览

一个最小可用的 Swift MCP Server 包含四层：

┌─────────────────────────────┐
│  Claude Desktop (Host)      │
└──────────────┬──────────────┘
        stdio  │  JSON-RPC 2.0
┌──────────────▼──────────────┐
│  Transport  (stdin/stdout)  │  按行读、按行写
├─────────────────────────────┤
│  JSON-RPC Dispatcher        │  method → handler
├─────────────────────────────┤
│  MCP Protocol Layer         │  initialize / tools/list / tools/call
├─────────────────────────────┤
│  Your Tools                 │  echo / read_notes / run_shortcut ...
└─────────────────────────────┘

项目搭建

新建一个 Swift Package：

mkdir SwiftMCPDemo && cd SwiftMCPDemo
swift package init --type executable

编辑 Package.swift（macOS 13+，用到 AsyncStream 与 Foundation 的 JSON 编解码）：

// swift-tools-version:5.9
import PackageDescription

let package = Package(
    name: "SwiftMCPDemo",
    platforms: [.macOS(.v13)],
    targets: [
        .executableTarget(name: "SwiftMCPDemo", path: "Sources/SwiftMCPDemo")
    ]
)

第一步：JSON-RPC 消息建模

MCP 的每条消息都是 JSON-RPC 2.0。用 Codable 把请求 / 响应 / 错误建模一次，后面所有 handler 都复用：

import Foundation

struct RPCRequest: Decodable {
    let jsonrpc: String
    let id: JSONValue?      // 可能是 number / string / null（通知无 id）
    let method: String
    let params: JSONValue?
}

struct RPCResponse: Encodable {
    let jsonrpc = "2.0"
    let id: JSONValue?
    var result: JSONValue?
    var error: RPCError?
}

struct RPCError: Encodable {
    let code: Int
    let message: String
    var data: JSONValue?
}

/// 一个能表达任意 JSON 的枚举，避免到处写 [String: Any]
enum JSONValue: Codable {
    case null
    case bool(Bool)
    case int(Int)
    case double(Double)
    case string(String)
    case array([JSONValue])
    case object([String: JSONValue])

    init(from decoder: Decoder) throws {
        let c = try decoder.singleValueContainer()
        if c.decodeNil() { self = .null; return }
        if let v = try? c.decode(Bool.self) { self = .bool(v); return }
        if let v = try? c.decode(Int.self) { self = .int(v); return }
        if let v = try? c.decode(Double.self) { self = .double(v); return }
        if let v = try? c.decode(String.self) { self = .string(v); return }
        if let v = try? c.decode([JSONValue].self) { self = .array(v); return }
        if let v = try? c.decode([String: JSONValue].self) { self = .object(v); return }
        throw DecodingError.dataCorruptedError(in: c, debugDescription: "Unsupported JSON")
    }

    func encode(to encoder: Encoder) throws {
        var c = encoder.singleValueContainer()
        switch self {
        case .null: try c.encodeNil()
        case .bool(let v): try c.encode(v)
        case .int(let v): try c.encode(v)
        case .double(let v): try c.encode(v)
        case .string(let v): try c.encode(v)
        case .array(let v): try c.encode(v)
        case .object(let v): try c.encode(v)
        }
    }
}

第二步：stdio 传输层

MCP over stdio 用 换行分隔的 JSON（每条消息一行）。关键点：

• 所有日志必须写 stderr，不能污染 stdout；
• 读取用行缓冲，避免半条 JSON。

actor StdioTransport {
    private let stdin = FileHandle.standardInput
    private let stdout = FileHandle.standardOutput

    func readLines() -> AsyncStream<Data> {
        AsyncStream { continuation in
            Task.detached {
                var buffer = Data()
                while let chunk = try? self.stdin.read(upToCount: 4096), !chunk.isEmpty {
                    buffer.append(chunk)
                    while let nl = buffer.firstIndex(of: 0x0A) {
                        let line = buffer.subdata(in: 0..<nl)
                        buffer.removeSubrange(0...nl)
                        if !line.isEmpty { continuation.yield(line) }
                    }
                }
                continuation.finish()
            }
        }
    }

    func send(_ response: RPCResponse) throws {
        var data = try JSONEncoder().encode(response)
        data.append(0x0A) // '\n'
        try stdout.write(contentsOf: data)
    }
}

func log(_ msg: String) {
    FileHandle.standardError.write(Data("[mcp] \(msg)\n".utf8))
}

第三步：注册工具

定义一个 Tool 协议，让每个工具自描述 schema 并处理调用：

protocol Tool: Sendable {
    var name: String { get }
    var description: String { get }
    var inputSchema: JSONValue { get }   // JSON Schema
    func call(arguments: JSONValue) async throws -> JSONValue
}

struct EchoTool: Tool {
    let name = "echo"
    let description = "Echo the input text back to the caller."
    let inputSchema: JSONValue = .object([
        "type": .string("object"),
        "properties": .object([
            "text": .object([
                "type": .string("string"),
                "description": .string("Text to echo back.")
            ])
        ]),
        "required": .array([.string("text")])
    ])

    func call(arguments: JSONValue) async throws -> JSONValue {
        guard case .object(let obj) = arguments,
              case .string(let text) = obj["text"] ?? .null else {
            throw NSError(domain: "echo", code: 1,
                          userInfo: [NSLocalizedDescriptionKey: "missing `text`"])
        }
        // MCP tool 返回的是 content 数组
        return .object([
            "content": .array([
                .object([
                    "type": .string("text"),
                    "text": .string(text)
                ])
            ])
        ])
    }
}

第四步：Dispatcher 与 MCP 生命周期

MCP 一次会话至少要处理三个方法：initialize、tools/list、tools/call。

final class Server {
    let transport = StdioTransport()
    var tools: [String: any Tool] = [:]

    func register(_ tool: any Tool) { tools[tool.name] = tool }

    func run() async {
        for await line in await transport.readLines() {
            await handleLine(line)
        }
    }

    private func handleLine(_ data: Data) async {
        guard let req = try? JSONDecoder().decode(RPCRequest.self, from: data) else {
            log("bad json: \(String(data: data, encoding: .utf8) ?? "?")")
            return
        }

        var resp = RPCResponse(id: req.id)
        do {
            switch req.method {
            case "initialize":
                resp.result = .object([
                    "protocolVersion": .string("2025-06-18"),
                    "capabilities": .object([
                        "tools": .object([:])
                    ]),
                    "serverInfo": .object([
                        "name": .string("swift-mcp-demo"),
                        "version": .string("0.1.0")
                    ])
                ])

            case "tools/list":
                let list = tools.values.map { t in
                    JSONValue.object([
                        "name": .string(t.name),
                        "description": .string(t.description),
                        "inputSchema": t.inputSchema
                    ])
                }
                resp.result = .object(["tools": .array(list)])

            case "tools/call":
                guard case .object(let p) = req.params ?? .null,
                      case .string(let name) = p["name"] ?? .null,
                      let tool = tools[name] else {
                    throw NSError(domain: "mcp", code: -32601,
                                  userInfo: [NSLocalizedDescriptionKey: "tool not found"])
                }
                let args = p["arguments"] ?? .object([:])
                resp.result = try await tool.call(arguments: args)

            case "notifications/initialized":
                return   // 通知无需回复

            default:
                resp.error = RPCError(code: -32601, message: "method not found: \(req.method)")
            }
        } catch {
            resp.error = RPCError(code: -32000, message: "\(error)")
        }

        if req.id != nil {
            try? await transport.send(resp)
        }
    }
}

main.swift 里把它跑起来：

@main
struct App {
    static func main() async {
        let server = Server()
        server.register(EchoTool())
        log("swift-mcp-demo starting on stdio")
        await server.run()
    }
}

编译：

swift build -c release
# 产物路径
echo "$(pwd)/.build/release/SwiftMCPDemo"

接入 Claude Desktop

编辑 ~/Library/Application Support/Claude/claude_desktop_config.json：

{
  "mcpServers": {
    "swift-demo": {
      "command": "/绝对路径/SwiftMCPDemo/.build/release/SwiftMCPDemo"
    }
  }
}

重启 Claude Desktop。在对话框输入框左下角的 🔌 图标里应能看到 echo 工具。让 Claude 调用：

用 echo 工具回显 “Hello from Swift MCP”。

如果一切正常，Claude 会把返回内容展示回来。

常见坑

1. stdout 被日志污染：任何 print 都会破坏 JSON-RPC 帧。所有日志一律走 stderr。
2. 忘记 notifications/initialized：Host 发来的通知没有 id，如果你也回一个响应会让客户端报协议错。判断 req.id != nil 再发送。
3. schema 与 arguments 不一致：inputSchema 里声明的 required 字段必须真的能从 arguments 里拿到，否则 Host 会跳过工具或报错。
4. 权限提示卡住：如果工具触及通讯录、日历、屏幕录制等，第一次运行会弹系统授权；Claude Desktop 是无窗口 spawn，用户可能看不到——先在终端里手动跑一次触发授权。
5. remote / SSE 传输：Streamable HTTP 的 POST 必须带 Accept: application/json, text/event-stream，否则官方 SDK 直接 406。stdio 走不通再考虑升级到 HTTP。

常见问题（FAQ）

Q：Swift MCP Server 能跨平台跑吗？
可以。核心代码只依赖 Foundation，Linux 上的 Swift 5.9+ 也能编译；要触达 macOS 专属 API（EventKit 等）时才会被平台绑定。

Q：需不需要自己实现 JSON-RPC，社区有没有现成库？
有官方 Swift SDK（modelcontextprotocol/swift-sdk）。生产项目直接用它；本文手写是为了把协议讲透。

Q：MCP Server 支持流式返回吗？
支持。工具可以在长任务里通过 notifications/progress 推进度，但要小心：客户端普遍有 30~60 秒左右的调用超时，超长任务应拆成 “创建 job → 查询结果” 两个工具。

Q：怎样调试？
最简单的办法：用 mcp-inspector（npx @modelcontextprotocol/inspector /path/to/SwiftMCPDemo）在浏览器里逐条查看请求与响应。

Q：MCP 会不会被 CLI 工具替代？
围绕 CLI vs MCP 有过一场讨论，但对于强类型、需要 schema 的 macOS 原生能力，MCP 仍然是最合适的封装。

结论

Swift + MCP 是被严重低估的组合：一份 Swift Package 就能把 macOS 原生能力干净地暴露给任何符合 MCP 的 AI 客户端，无 Python、无网络、类型安全。这篇教程的完整代码可以直接复制运行；下一步建议：

• 把 EchoTool 换成 RunShortcutTool，用 Process 调 shortcuts run；
• 加一个 read_notes 工具走 AppleScript / EventKit；
• 打包成 .pkg 或 Homebrew tap，让别人一键装。

如果你在做类似方向的实验，欢迎订阅本站 RSS 或看看姊妹项目 Open Agent SDK (Swift)，那边把 “Agent Loop + MCP 集成” 完整跑通了。

如果你看过我之前那篇 Story Automator 上手实录，应该还记得我最后的结论：

白天手工跑，目前还是自己手工跑会更快。但睡前把一批 Story 交给它过夜跑，这个场景它真的挺合适。

那篇文章里我留了个没回答的问题——为什么它跑得比人手工还慢？ 我当时说"还没仔细分析它的实现原理"。

现在 BMAD 6.10 把这套东西重写了一遍，改名 BMAD Loop，也顺手把那个问题接上了。答案只有一句话，但它是理解整个设计的钥匙：

控制环里，不应该放 LLM。

先纠正一个最容易踩的误解

很多人第一次接触 BMAD Loop，会以为它是几个新 skill：bmad-loop-setup、bmad-loop-sweep、bmad-loop-resolve、bmad-dev-auto。

不是。这几个 skill 本身什么也不做。

真正驱动循环的，是一个用 uv 从 Git 装进来的 Python 工具——bmad-loop 包（仓库在 bmad-code-org/bmad-loop）。那几个 skill 只是编排器在循环的不同阶段会去调用的"基本操作"（官方文档里叫 primitive，说白了就是最基础的、可以单独派活的小单元）：

• bmad-dev-auto：开发——把意图变成经得起 review 的产物
• bmad-loop-sweep：巡检——清理延后工作台账
• bmad-loop-resolve：交互——和人一起消除歧义

换句话说，skill 是肌肉，Python 编排器才是中枢神经。 这一点想通了，后面所有设计都顺理成章。

灵魂信条：No LLM in the control loop

官方 README 的副标题一句话就给它定了性：

A deterministic ralph-loop orchestrator for the BMAD-METHOD implementation phase.

翻译过来：一个确定性的循环编排器。"确定性"（deterministic）这三个字是全文最重要的一组词。

它把整个开发循环切成两种完全不同的工作：

回过头看 Story Automator 为什么慢——它的控制环里塞满了"用提示词去问 LLM 现在该干嘛"的环节。每问一次都要花 token、等推理，还可能跑偏，跑偏了就再问一次。把调度交给 LLM，等于让一个容易走神、按字计费的新人在流水线上当调度员。

BMAD Loop 的做法是：调度员换成一段不会走神、不收钱的 Python 代码，LLM 只在每个工位上干它该干的创意活，干完就走。

这样做换来四个好处，是后续所有机制的出发点：

• 确定性：同样的 sprint 跑两次，调度路径一致
• 可调试：流程是代码，出问题能打断点、看日志，而不是"猜提示词哪里没说清"
• 可复现：每次运行的决策都有磁盘上的状态机记录
• 省钱：控制逻辑零 token 消耗

四个让它"敢放手"的关键机制

"控制环不放 LLM"说起来轻松，但它带来一个尖锐的问题：编排器怎么知道一个 LLM 会话干完了、干对了？ 旧做法是让编排器自己也是个 LLM，去"看"会话的输出——这正是 Story Automator 的包袱。

BMAD Loop 用四个机制绕开了这个包袱。

机制一：每个步骤都是全新上下文的一次性会话

Dev 和 review 是两个独立会话，review 会话绝不继承 dev 会话的上下文。

这一点反直觉，但极其关键。如果 review 会话带着 dev 写代码时的记忆，它天然会"护短"——人对自己刚写的代码容易先入为主、下不去狠手（心理学叫锚定效应，anchoring bias），LLM 也一样。把 review 放进一个对 dev 一无所知的全新会话里，它才会真的去挑刺，而不是附和。

类比：你不能让写代码的人和 code review 的人是同一个脑子。上下文隔离，就是给 review 配一双"没见过这份代码"的眼睛。

机制二：靠 hook 事件文件通信，绝不抓屏

编排器怎么知道会话结束了？答案是给 coding CLI（Claude Code / Codex / Gemini）注册 hook——Stop、SessionStart、SessionEnd、PreCompact。这些 hook 在关键节点往磁盘写结构化事件文件，编排器只管 watch 这些文件。

而每个 skill 在自动化模式下跑完，会写一个机器可读的 result.json，声明自己这一轮的产物和状态。

旧做法（Story Automator）：         BMAD Loop 的做法：
┌─────────────┐                    ┌─────────────┐
│  编排器(LLM) │                    │ 编排器(Python)│
│   去看屏幕   │ ←脆弱、贵、易错      │  watch 文件  │ ←稳、免费、结构化
└─────────────┘                    └─────────────┘
       ↑                                  ↑
   抓 pane / 读对话                  读 Stop hook 写的事件
                                   读 skill 写的 result.json

抓屏（pane-scraping）是上一个时代的痛：终端输出格式一变、模型多说了一句废话，编排器就懵了。换成"hook 写文件、编排器读文件"，接口就从自然语言降维成了结构化数据，鲁棒性立刻上一个台阶。

机制三：Trust nothing, verify everything

这是整个系统最硬核的地方。每个 LLM 会话结束后，编排器不信任会话自己说的"我搞定了"，而是去磁盘上独立校验：

• spec frontmatter（文件开头的元信息）状态：story 的规格文件状态字段是否真的变成了 done
• baseline-commit 匹配：会话声称改了哪些文件，和 git 里实际的 diff 对不对得上——这是一个便宜的"LLM 撒谎检测器"
• 非空 diff：到底有没有真的改东西
• sprint-status 同步：状态文件是否和实际进度一致
• 你的测试 / lint 命令：最后提交前，跑一遍你自己定义的测试和 lint

校验全过，才允许 commit。任何一项不过，要么重试，要么升级。

这条哲学值得单独记住：LLM 会幻觉，但 git 不会。 把"是否真的完成"这个判断，从"问 LLM"挪到"看磁盘证据"，整个系统就稳了。

机制四：deferred-work 台账 + sweep，终于有人读它了

循环里总会遇到"现在干不了"的活——某个 edge case 要等另一个 story 先落地、某个决策该人来拍板。这些不能硬干，也不能丢，于是写进一份台账：deferred-work.md。

有意思的是这份台账的身世。在更早的 BMAD 版本里，这是个有名的半成品——bmad-code-review 会往 deferred-work.md 里写延后项，但没有任何 skill 会回头读它（社区甚至专门提了 issue 报这个 bug）。写进去的债，永远没人还。

BMAD Loop 的 bmad-loop-sweep 终于补上了这一环。它做的事是只读巡检：把台账里每条 open 的项，对着真实代码库逐条验证（grep 症状、查 git log、读相关文件），然后分成五类：

"写进去的债，有人还了"——而且是带着证据还，不是凭台账里的旧状态拍脑袋。这条机制让循环可以长时间无人值守地跑下去而不至于债台高筑。

一张图看清整个循环

把上面四个机制拼起来，一个 story 在 BMAD Loop 里的完整生命周期是这样的：

整条链路的控制流是 Python，只有②③④这几个"创意工位"是 LLM 在一次性会话里干活。这就是"确定性编排器"的完整含义。

多模型编排：三个 CLI，按角色混搭

BMAD Loop 通过一个通用的 tmux 适配器驱动三种 coding CLI：claude（默认）、codex、gemini。而且可以按阶段混搭——配置在项目的 .bmad-loop/policy.toml 里：

[adapter]
name = "claude"          # 默认所有阶段都用 claude

[adapter.review]
name = "codex"           # 但 review 阶段换成 codex

为什么要混搭？因为不同模型擅长的事不一样。一个很实用的组合是：让一个模型写代码、让另一个模型做对抗式 review——两个不同家族的模型互相挑刺，比同一个模型自审要狠得多。这正好和"机制一：review 用全新上下文"叠加，双重消除偏置。

这已经不是"调一个模型"了，是模型编排。

什么时候它会停下来叫你：CRITICAL 升级

无人值守不等于无人干预。有一种情况编排器会主动暂停整个 run，等人——CRITICAL 升级。

触发条件通常是：dev 或 review 会话发现冻结的 spec（<frozen-after-approval> 块）自相矛盾，或者对某个关键场景保持沉默，没法安全地继续。这时候它不猜、不硬干，而是把 run 挂起，等你用：

bmad-loop resolve --story <story-key>

起一个交互式会话。这个会话里有人（你），所以它会问你问题、给出 2-4 个具体选项和推荐。你拍板之后，它去改 spec 本身——不是改代码——把歧义消掉，然后编排器重新驱动这个 story，对着一份修正过的、没有矛盾的 spec 重跑。

这个设计很克制，有几条硬规矩值得点赞：

• resolve 会话只改 spec 内容，不写一行功能代码、不跑测试、不提交
• 它不动 sprint-status.yaml，也不设 spec 的 status 字段——这些由编排器在恢复时确定性地产出
• 如果信息不够、或者正确的修复超出了 spec 编辑的范围（比如需要改 PRD/架构），它会直接说"我解决不了"，不写完成标记，run 继续挂着——这是安全的默认行为

一句话：遇到拿不准的，宁可停下来等你，也不编一个答案往下冲。 这是对"无人值守"最负责的理解。

怎么用：上手三步

前置条件就一条：你得有一个 BMAD v6 项目，而且 bmad-sprint-planning 已经跑过、生成了 sprint-status.yaml。换句话说，PRD / 架构 / epics&stories / sprint planning 这条链得先走完，Loop 才有故事可转。

装好之后（通过 bmad-loop-setup 这个 skill，它会从 Git 装 Python 工具 + 跑 bmad-loop init 注册 hook、铺 skill、写 policy.toml），核心命令其实很少：

bmad-loop init        # 装 bmad-loop-* skill + hook + policy.toml + gitignore
bmad-loop validate    # 预检：config / sprint-status / git / tmux / CLI / hook
bmad-loop run --dry-run   # 先打印计划，不真的拉起会话
bmad-loop run         # 开跑
bmad-loop tui         # 或者干脆全在可视化面板里操作

完整命令清单覆盖了 run / sweep / resume / resolve / decisions / status / attach / stop / clean 等，但日常 90% 的场景就是上面这几条。bmad-loop tui 那个仪表盘挺漂亮——run 选择器、sprint 树、deferred-work 台账、每个 story 的实时任务表、带颜色的日志流，一屏打尽。

一个必须知道的一次性设置坑：如果目标项目里 coding CLI 从来没跑过（比如 claude 没在这个目录启动过），你要先手动启动一次，接受 workspace-trust 和 hooks 审批对话框。编排器拉起的子会话没法替你点这些首次运行对话框，而一个挂着的对话框会被编排器误判成"会话超时"。

血统：从 Story Automator 到 BMAD Loop

把 BMAD Loop 放回时间线里，它的位置就很清楚了：

Story Automator          bmad-automator / bmad-auto          BMAD Loop
(2026 初, 我那篇          (中间的过渡形态,                  (6.10, 重写为
 实测的版本)               工具名 bmad-auto)                  确定性 Python 编排器)
      │                        │                                 │
      └──── 控制环里有 LLM ─────┴───── 重写 ────────► 控制环里没有 LLM ──┘
              (慢、贵、易跑偏)                         (确定、可调试、省钱)

README 里写得很坦诚："Inspired by the original bmad-automator (a separate, legacy project)"——它明确把上一代当成 legacy，自己是从头来的重写。

而它给自己定位是 "a deterministic ralph-loop orchestrator"。如果你关注过 autonomous dev 这个圈子，应该听说过 Ralph——那个让 Claude Code 自己跑开发循环的工具。BMAD Loop 借用了"ralph-loop"这个模式（无人值守、反复迭代的小循环），但把它确定性地实现在了 BMAD 的 story 体系上。所以它是"Ralph 的精神 + BMAD 的骨架 + Python 的中枢"。

适合谁，不适合谁

延续我测评 Story Automator 时的坦诚基调，给你一个不吹的判断。

适合用的场景：

• 你已经完整走完 BMAD 的规划链（PRD → 架构 → epics → sprint planning），手头有一串清晰、可独立实现的 story
• 你接受"睡前梭一把"这种异步交付模式——第二天起来看结果，而不是盯着它实时干
• 你的项目有可靠的测试和 lint（机制三最后那道闸靠它们），否则 verify 形同虚设
• 你想做多模型互相 review，又不想自己手动切来切去

不适合 / 要谨慎的场景：

• story 还很模糊、依赖关系没理清——这种跑进循环里大概率触发一堆 CRITICAL 升级，反而更累
• 没有测试的项目——编排器再聪明，最后那道 verify 闸门空转，等于裸奔
• 期待它"又快又好又自动"——确定性编排让它更稳、更省，但单 story 的绝对速度未必比一个熟手手工盯更快。它的价值在批量、异步、可恢复，不在单点提速

和上一代最大的区别，也是我现在最看好它的一点：因为控制环是确定性代码，它可调试、可复现、可信任。Story Automator 时代那个"为什么这么慢"的黑盒，这一次终于打开了——流程是 Python，你看得到每一步在干嘛、为什么这么决策。光这一点，就值得把它从"试验品"升级成"可以认真用起来的工具"。

写在最后

从 v6.8 的"锁定意图"（让 AI 先搞懂你要什么），到 6.10 的 BMAD Loop（让确定性的代码当调度员、LLM 只管写代码），BMAD 这两年的演进方向其实非常一致：

把不该让 LLM 干的活，一件一件从 LLM 手里拿回来。

意图理解该锁定的，用 SPEC 锁定；调度该确定的，用 Python 确定；该人拍板的，挂起 run 等人。LLM 越来越被收敛到它真正擅长的那块创意工作上。

这不是对 LLM 不信任，恰恰是对它的尊重——别让它干它不擅长、又会幻觉、还按字收费的活。

如果你也在用 BMAD 做项目，强烈建议拿一个 sprint 来认真试一次 BMAD Loop。哪怕只是为了让 deferred-work.md 那本"永远没人还的债账"终于有人管，也值。

参考来源：

• bmad-loop 官方仓库：bmad-code-org/bmad-loop
• BMAD Method 文档：docs.bmad-method.org
• 上一代实测：BMAD Story Automator 上手实录
• v6.8 上下文：BMad v6.8：AI开发正式进入"锁定意图"时代

原文：When AI builds itself — Anthropic Institute
作者：Marina Favaro, Jack Clark ｜ 发布于 2026 年 6 月

一句话总结

Anthropic 用自己内部的硬数据证明了：AI 正在加速 AI 的开发，而且加速度本身也在加快。从外部基准测试到内部工程效率，所有曲线都在上扬。递归自我改进——AI 完全自主地设计和开发自己的继任者——还没有实现，但可能来得比大多数机构准备好的时间更早。

进化的五个阶段

Anthropic 把这个过程分成了五个阶段：

这个阶段的划分不是理论推演，而是 Anthropic 内部真实发生的事情。注意最后那个 20XX?——连 Anthropic 自己都不确定时间点，但方向是明确的。

外部证据：基准测试的加速饱和

如果你只看公开数据，趋势同样惊人。

AI 能完成的任务时长每 4 个月翻一倍（之前是每 7 个月）。这是什么概念？

• 2024 年 3 月：Claude Opus 3 能完成人类约 4 分钟 的任务
• 2025 年 3 月：Claude Sonnet 3.7 搞定 1.5 小时 的任务
• 2026 年 3 月：Claude Opus 4.6 搞定 12 小时 的任务
• 如果趋势持续：2026 年内可能覆盖数天级别的任务，2027 年可能覆盖数周级别的任务

几个重要基准测试的状态：

• SWE-bench（真实世界的软件工程测试）：两年内从个位数跑到饱和。模型拿到真实的开源代码库和真实的 bug 报告，自己写修复代码并通过项目测试
• CORE-Bench（复现已有研究）：从 2024 年约 20% 的成功率，15 个月后饱和
• METR 长任务基准：Claude Mythos Preview 能连续工作至少 16 小时，已经触及 METR 能测量的上限

来自 Anthropic 内部的数据

公开基准测试能告诉你模型有多强，但看不到 AI 对 AI 开发本身的加速效应。Anthropic 这次公开了内部数据，这是这篇文章最有价值的部分。

80% 的代码由 Claude 编写

截至 2026 年 5 月，Anthropic 合并到代码库的代码中超过 80% 由 Claude 编写。Claude Code 在 2025 年 2 月发布之前，这个数字只有低个位数。

这张图有两个拐点：

1. 2025 年初：Claude 开始自己运行代码（而不是让人类复制粘贴），代码量开始上升
2. 2026 年：模型开始自主工作更长时间，曲线陡然加速

2026 年 Q2，典型工程师每天合并的代码量是 2024 年的 8 倍。注意，代码行数是不完美的度量——它度量的是数量而非质量。但方向是明确的。

一个更直观的数字：2026 年 3 月，130 名 Anthropic 研究人员的调查显示，中位数受访者估计使用 Mythos Preview 后产出约为不使用 AI 时的 4 倍。

代码质量已接近人类水平

代码质量有两个维度：能用 和 可维护。

在"能用"这个维度上，证据已经非常清楚。Anthropic 员工纠正、重定向或接管 Claude 的频率持续下降——包括最复杂、最开放的任务。

在开放性任务上，Claude 的成功率在 2026 年 5 月达到 76%，六个月内提升了 50 个百分点。

一个具体的例子：一次常规升级导致数万个训练任务崩溃。工程师把现场信息丢给 Claude，Claude 在大约两小时内隔离了一个冷门的调试 flag，可靠地复现了问题并确认了修复。这通常是两到三天的工作量。

在"可维护"这个维度上，差距在快速收窄。Anthropic 内部普遍认为：Claude 写的代码在 2025 年底还不如人类，目前已经基本持平，预计年内将超过人类水平。

一个有趣的发现：Anthropic 用 Claude 自动审查代码变更，回溯分析发现，如果一直用 Claude 审查，它能在大约三分之一的 bug 进入生产环境之前就发现它们。而写出那些代码的工程师，是世界上构建这类系统最顶尖的一批人。

实验优化：从超有用到超人类

Anthropic 每次发模型都跑一个固定测试：给 Claude 一段训练小型 AI 模型的代码，让它尽可能加速同时保持正确性。

• 2025 年 5 月，Claude Opus 4：约 3x 加速
• 2026 年 4 月，Claude Mythos Preview：约 52x 加速
• 对比：一个熟练的人类研究员需要 4–8 小时才能达到 4x

在明确目标下的实验执行这个环节，Claude 在不到一年内从"超有用"变成了"超人类"。

研究判断力：最后的差距

但实验执行和实验设计是两回事。Anthropic 做了一个实验来衡量这个差距：

他们找了 129 个真实的研究会话，这些会话都有一个共同特点——研究员在某个时刻走了一个弯路。他们把这个弯路之前的内容截断，问各个 Claude 模型"你下一步会怎么做"，然后用一个能看到完整会话结果的 Claude 来判断：AI 和人类谁的选择更好？

结果：

• 2025 年 11 月，Claude Opus 4.5：51% 的情况下比人类选择更好
• 2026 年 4 月，Claude Mythos Preview：64% 的情况下比人类选择更好

注意，这组数据本身就偏向 AI——因为他们刻意挑选了人类判断有改进空间的时刻。但作为一个衡量 AI 研究判断力随时间提升的指标，方向是清晰的。

这就是 AI 今天和"能自主设计自己继任者"之间的差距：方向设定——选择什么问题值得研究、什么结果值得信任、什么时候该放弃一条路。

三种未来场景

Anthropic 提出了三种可能的未来：

场景一：趋势停滞，但当前能力广泛扩散

指数曲线可能实际上是 S 曲线，我们可能正在接近拐点。"研究品味"可能是一种无法通过扩大训练来获得的能力。或者瓶颈可能在供应链——芯片产能、电网扩张、互联带宽。

即使模型能力冻结在今天的水平，变革仍然巨大。Project Glasswing 项目中，Mythos Preview 在最初几周就发现了全球最重要系统中超过一万个高危软件漏洞。一个 100 人的公司将能完成过去 1000 人的工作。

Anthropic 认为这个场景可能性最低——因为他们观察到每一个可衡量的能力指标都在同一条上升曲线上，还没有看到曲线变平的迹象。

场景二：AI 实验室持续获得复合效率增益

AI 开发被大幅自动化，但人类继续设定研究方向。100 人的公司能做 10,000 甚至 100,000 人组织的工作。

但这里有 Amdahl 定律的影子：加速一部分流程只会把瓶颈推到其他地方。Anthropic 已经遇到了这个问题——随着代码量暴增，人类的代码审查成了新的瓶颈。同样，新想法、新工具、新模拟的爆炸式增长远远超出了他们能追求的范围。

识别和修复瓶颈的能力，可能成为任何组织最重要的能力。

场景三：AI 系统实现完全的递归自我改进

AI 开始设计和精炼自身。进步的速度完全由算力可用性决定。人类角色大幅缩减，主要转向监督、验证和确认一个不断扩展的"虚拟实验室"。

这个场景最不确定的部分是对齐问题：

• 模型可能足够对齐且有足够的研究品味，发现并实施人类尚未达到的新方案
• 也可能够聪明到在不确定时主动暂停开发
• 但也可能——今天模型中罕见的不对齐行为在构建继任者时复合增长，变得越来越频繁却越来越不被理解，直到人类失去控制

Anthropic 的立场：我们需要暂停的选项

文章最后提出了一个明确的政策立场：

如果有可能有效地减缓这项技术的发展，给我们更多时间来处理其巨大影响，我们认为这可能是好事。但如果减速只是让最不谨慎的参与者在技术上赶上来，可能会让每个人都更不安全。

Anthropic 明确表示：如果其他前沿开发者也能以可验证的方式减速或暂停，他们愿意这样做。

但实现可信的暂停极其困难：

• 训练运行比导弹发射井更容易隐藏
• 训练的输入是通用资源（算力、电力）
• 悄悄违约的激励巨大——谁在别人暂停时继续，谁就能继承领先地位
• 暂停还需要定义触发条件、解除条件和裁决机制

Anthropic 承诺在未来几个月组织政策制定者、研究人员、公民社会和其他 AI 公司的对话，推动这些问题——特别是围绕完全递归自我改进和如何创建更好的协调选项。

我的思考

几点个人观察：

1. "8 倍代码量"是一个被低估的数字。 因为这不只是"写了更多代码"——它改变了工程师的角色定义。工程师从"写代码的人"变成了"审查和引导 AI 的人"。当审查速度跟不上生成速度时（Amdahl 定律），整个流程会再次重组。

2. 研究判断力的进步是最值得关注的指标。 代码编写和实验执行已经接近或超过人类水平，但"决定研究什么"这个最后的人类堡垒正在缩小——从 51% 到 64% 的胜率提升只用了五个月。如果这个趋势持续，"研究品味"可能也只是另一种 AI 能力——AI 会失败一段时间，然后突然变好。

3. 三种场景的分布比结论更重要。 Anthropic 明确说他们认为场景一最不可能。但他们没有押注场景二还是场景三——这本身就是一种信号。如果他们确信递归自我改进不会发生，他们会说"我们距离场景三还很远"。他们没有这么说。

4. 暂停的悖论。 Anthropic 愿意暂停的前提是"其他人也暂停"。但在一个没有全球协调机制的世界里，这几乎等同于"我们不暂停"。这不是批评——这是一个真实的囚徒困境。文章在这一点上非常诚实。

5. 最被低估的风险：不是 AI 变得强大，而是人类的协作基础设施被侵蚀。 文章引用了一位 Anthropic 员工的话让我印象深刻：

工作和生活曾经运行在人与人之间的小恩小惠的礼物经济上。"你能帮我跑一下这个脚本吗？"……每一个请求都创造了一点人情债、一点相互认知。Claude 更快，不产生人情债，但每一个这样的请求都是一次人类协作机会的丧失。

当 AI 让每个请求都能被即时满足时，人与人之间的协作纽带也在被悄无声息地削弱。这不是技术问题，而是社会结构问题。

原文核心数据速查

本文基于 Anthropic Institute 2026 年 6 月发布的 When AI builds itself 撰写，包含个人解读和分析。

仓库地址：github.com/terryso/hack-buffer
线上地址：blog.suchuanyi.dev

先说结论：这不是一个「深色主题」博客

很多人做「终端风」，就是在白色博客上换成深色背景加个等宽字体，完了。这个博客不是这样做的。

打开 blog.suchuanyi.dev，你看到的不是一个换了皮的 WordPress。你会看到一个在浏览器里运行的终端 IDE。每一个 UI 元素都有对应的终端隐喻，不是装饰，是交互逻辑本身。

顶部状态栏：你的 tmux pane

导航栏模仿的是 tmux 的 pane 标题行。左边是站点名 terry.so 前面带一个绿色圆点 ●，然后是当前路径：

● terry.so  ~/posts/open-source-terminal-blog  main*

~/ 后面跟着你当前所在的路径段，最后一截高亮显示——就像你在 tmux 里看到的 pane 标题一样。末尾的 main* 表示当前分支有未提交的改动（当然是假的，但感觉对了）。

右边是状态信息：GitHub Fork 链接、⌘K 命令面板入口，还有一个绿色脉冲圆点配 CONNECTED 字样——你的终端连上了远程服务器那种感觉。

整个导航栏是 sticky 的，磨砂玻璃效果（backdrop-blur），往下滚也不会消失。

底部状态栏：Vim 的 mode line

页面最底部固定了一行状态栏，完全模仿 Vim 的底部 mode 行：

[NORMAL]  index.md          g home  t tags  a about  ⌘K palette  UTF-8  14:32

• 左边是 NORMAL 模式标签（绿色高亮），像 Vim 的 -- INSERT --
• 旁边是当前文件名，比如 index.md 或 posts/open-source-terminal-blog.md
• 右边是快捷键提示和系统信息：编码（UTF-8）、当前时间（实时更新）

这不是静态装饰。时间每秒刷新，文件名跟随路由切换，NORMAL 标签一直告诉你「你不在输入模式」。

Vim 键位：全程不用鼠标

这是我最喜欢的部分。整个站点的导航可以用 Vim 键位操作：

在首页翻页的时候，h 和 l 的体验和 Vim 里左右移动光标一模一样。gg 跳回第一页，G 跳到最后一页——完全复刻 Vim 的行首行尾。

搜索框按 / 聚焦，这是 Vim 里搜索的键位。搜索结果出来之后可以 ESC 关掉。整套键盘流可以完全不用鼠标浏览整个博客。

命令面板：终端里的模糊搜索

⌘K 打开命令面板。外观是一个 $ 开头的终端输入框，底下列出可用命令：

$ type a command...
  :home
  :tags
  :about

输入几个字母自动过滤，Enter 执行第一个匹配项，ESC 关闭。和 VS Code 的命令面板一样好用，但长得像你的 shell。

首页：ls 你的文章列表

首页不是传统博客那种大图卡片布局。它更像是在终端里 ls -la 你的文章目录：

$ ls -la ~/articles | sed -n '1,10p'

上面这行是真的渲染在页面上的，作为 banner 的一部分。每个文章条目是一个网格行：

01  文章标题                                UPDATED: 2026-05-30
    文章描述文字...                          SIZE: 12KB
    #tag1  #tag2  #tag3                     READ: 8MIN

左边是序号（两位数，零填充），中间是标题 + 描述 + 标签，右边是文件元信息——就像 ls -la 的输出列。标签用 # 前缀，加了细边框，像终端里的 badge。

右上角显示当前页码和总数：PAGE 01/04 · TOTAL 37，用大写字母和零填充——信息密度拉满，但不会觉得乱。

文章页：YAML frontmatter 直接渲染

打开一篇文章，正文上方不是传统的「作者 + 日期」元信息块。你看到的是一段被渲染的 YAML frontmatter：

---
title:   "文章标题"
date:    2026-06-07
category:[开源, 博客]
tags:    [开源, TanStack Start, pgvector]
status:  published
---

绿色分隔线、等宽字体、键值对网格布局——就像你在终端里 cat 一个 Markdown 文件，frontmatter 原样输出。status: published 用绿色高亮，暗示这篇文章已经 merge 了。

这个设计不是偶然的。写博客的人天天和 frontmatter 打交道，把它直接展示出来，读者一眼就知道「这是一篇 Markdown 文件」，而不是一个 WordPress 页面。

搜索框：长得像 grep

首页的 AI 搜索框不是一个普通的输入框。它长这样：

$ grep -r  问点啥...例如 swift agent 集成  /

左边是绿色的 $ 提示符，紧跟着 grep -r，然后才是输入区域。右边有个 kbd 标签提示按 / 可以聚焦——还是 Vim 的搜索键。

搜索中的状态是 embedding query...，搜索结果标题行显示匹配数：// 3 matches，每条结果前面有相似度百分比。搜索失败的时候是 err: ...。

整个搜索体验就像你在终端里跑了一个命令，然后看着输出一行一行出来。

配色系统：oklch + 语义 token

终端风的灵魂不只是等宽字体，还有配色。

整个博客的颜色系统用 oklch 色彩空间定义，只有六个 token：

accent 是那个标志性的终端绿，用在链接、提示符、YAML 分隔线、闪烁光标、状态指示灯、快捷键高亮……所有需要「跳出来」的地方。统一、克制、不花哨。

组件层不写任何裸色值。所有颜色都走这六个 token。想换一套配色？改 styles.css 里六行代码，全站跟着变。

选中文字的高亮也是绿色的——::selection 用了 color-mix 把 accent 和透明度混合，选中效果像终端里高亮了一行输出。

闪烁光标：一直在线

页面标题末尾有一个闪烁的下划线 _，用 CSS step-end 动画实现，一秒闪烁一次——和终端里光标的节拍一模一样。

这个光标不是装饰。它在告诉读者「这个页面是活的，你可以输入」。首页标题「Agent 内核深潜」后面跟着 cursor-blink，搜索框打开的时候也是这种节奏。整个站点的交互节奏是统一的。

404 页面：cat: post not found

文章找不到的时候，你看到的不是一个大大的 404 插画。你看到的是：

$ cat: post not found
cd ~/

cd ~/ 是一个可点击的链接，带你回首页。就像你在终端里 cat 了一个不存在的文件，然后 cd 回到 home 目录。

文章内容的排版细节

正文用 sans-serif 字体（Inter），行高 1.75，但标题全部回到等宽字体。这是刻意的设计——结构信息用 mono，阅读内容用 sans。代码块背景比页面底色更深一层（oklch(0.13)），有细边框和圆角，代码高亮用 github-dark 主题。

引用块的左边是绿色竖线，背景有 6% 的绿色透明叠加。分隔线是虚线（dashed），不是实线——像终端里的注释行。

列表的 marker（disc / decimal）全部用 accent 绿色。链接有下划线但透明度 40%，hover 的时候变成实色——微妙但有反馈。

表格强制等宽字体，字号缩小到 0.875rem，表头有 surface 背景。整个表格看起来像终端里的 ps 或 top 输出。

顺便说一下 AI 功能

说了这么多终端风，AI 功能其实是锦上添花。但既然做了，也挺好用：

1. TL;DR —— 每篇文章自动生成三句话中文摘要（Gemini Flash）
2. 语义相关推荐 —— 文章底部自动推荐 3 篇最相关的旧文（pgvector 余弦相似度）
3. 自然语言搜索 —— 首页 grep 框输入自然语言，按语义返回结果

三个功能全部通过 Lovable AI Gateway 调用，项目里没有任何 API Key。同步管线用内容哈希做增量闸门，没变过的文章不重算、不花钱。一行脚本触发：./scripts/sync-posts.sh prod。

不想用 AI？VITE_ENABLE_AI=false 一行关掉，退化成纯静态博客。

技术栈一览

首屏 < 100KB，SSR 输出，每个路由都有 canonical / OG / JSON-LD。

Fork 指南

如果你想基于这个博客做自己的：

1. Fork 仓库 → github.com/terryso/hack-buffer/fork
2. 在 Lovable 导入 → 自动拿到 Supabase 项目和 AI Gateway
3. 替换 content/posts/ → 放你自己的 Markdown（frontmatter：title / date / description / tags）
4. 改品牌 → __root.tsx（站点信息）、about.tsx（自我介绍）、SiteShell.tsx（站名和导航）、styles.css（配色 token）
5. 改同步脚本 → scripts/sync-posts.sh 换成你的域名
6. 部署 + 同步 → Publish 之后跑 ./scripts/sync-posts.sh prod

终端风的 UI 和 Vim 键位不需要任何后端依赖。即使你完全不用 AI 功能，这套终端交互体验也是开箱即用的。

最后

这个博客最大的亮点不是 AI，不是 RAG，不是增量同步。是你打开它的那一刻，感觉像在终端里读文章。顶部路径栏、底部模式行、Vim 键位、grep 搜索框、YAML frontmatter 渲染、闪烁光标——整套 UI 都在说同一件事：这里属于程序员。

AI 是工具，终端是审美，开源是态度。

仓库在这里：github.com/terryso/hack-buffer

有问题开 Issue，或者直接在博客上按 / 搜——毕竟它自己就能搜。

/bmad-spec 提炼意图合约，
/bmad-ux 拆分视觉与行为脊柱，
/bmad-investigate 用工程化取证方式解决复杂问题。

完整更新日志: https://www.bmadcode.com/bmad-update-may-2026-web-bundles-prd-brief-platforms/