最近看了 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/

想深入了解, 可以阅读下面关于Hermes自进化的系列文章: 从 Memory、Skill 到 Background Review，完整拆解 Hermes 的自进化架构。

https://blog.suchuanyi.dev/posts/hermes-self-evolution-1-overview

如果你已经习惯通过 BAMD 写代码，接下来真正耗时间的，往往不是“写”，而是“协调”。

一个 Epic 里有 5 个、10 个、20 个 Story。每个 Story 都要经历创建规格、开发实现、自动化测试、代码审查、回顾总结。真正让人疲惫的，不是某一步本身，而是你要不断盯着流程、切换会话、处理失败、决定下一步。

Story Automator 想解决的，就是这层“人肉编排”。

昨晚我实际跑了一遍 /bmad-story-automator 的完整流程。下面就是这次使用过程的记录，以及一些当时截下来的图。

它解决的不是“写代码”，而是“盯流程”

先用一句话概括 Story Automator：

你告诉它要处理哪些 Story、用什么执行策略，它就自动完成「创建规格 → 开发实现 → 测试自动化 → 代码审查 → 回顾」这条流水线，只在真的需要人类决策时才打断你。

这和普通“单命令跑一个 Skill”不一样。它更像一个构建周期编排器：

初始化
  → 读取 Epic / Sprint 状态
  → 选择 Story 范围
  → 评估复杂度
  → 选择 Agent 策略
  → 执行 create / dev / automate / review / retro
  → 在失败或冲突时升级给人类

从设计上说，它是在自动化“协调工作”，而不是直接替代某一个具体开发步骤。

升级BMAD到最新版(v6.6)

如果你想体验 Story Automator，需要先把 BMAD 升到 6.6。安装时记得把 BMad Automator (Experimental) 这个模块勾上。

不然装完 BMAD，后面是用不起来的。

第一次运行：先补齐 Stop Hook，防止工作流半路被打断

第一次执行 /bmad-story-automator 时，它不会急着开跑，而是先做初始化检查。

从下面这张图可以看到，它先加载配置，然后尝试读取当前编排状态；如果发现状态目录还不存在，这是正常的首次运行场景。接着它会自动安装 Stop Hook 到 .claude/settings.json 中。

第一步：先选 Story，不是盲跑所有待办项

真正进入编排前，Story Automator 会先读取 Epic 和 sprint 状态，然后让你决定处理范围。

下面这张图展示了一个很典型的场景：Epic 5、6、7 中一部分 Story 已完成，一部分仍然待办。工具会把这些状态直接展示出来，然后询问你要处理哪些 Story。

第二步：复杂度不是拍脑袋，而是先打分再分配 Agent

这是我觉得 Story Automator 最有意思的部分之一。

它不是把所有 Story 一股脑丢给同一个 Agent，而是先生成一个Story 复杂度矩阵。截图里可以看到：

• Story 5.3 “Server 命令与 API 认证” → 4 分 / Medium
• Story 6.1 “通过 SDK AgentMCPServer 暴露 Axion” → 2 分 / Low
• Story 6.2 “axion mcp 命令与外部 Agent 集成验证” → 2 分 / Low
• Story 7.1 “基于 SDK Pause Protocol 的用户接管机制” → 2 分 / Low
• Story 7.2 “--fast 模式” → 5 分 / Medium

更关键的是，它不只给分，还给出原因：

• authorization / permissions
• 实时通信
• 验收标准数量高
• Story 文本较大

这意味着复杂度评估不是黑盒。你看到的不只是“结论”，而是“为什么它觉得这个 Story 更难”。这会直接影响后续的 Agent 选择策略。

换句话说，Story Automator 在做的事其实是：

先把 Story 变成“可调度对象”，再决定谁来执行。

第三步：你可以塞入自定义指令，但默认不强迫你多想

接下来它会问你有没有自定义指令。

比如：

• 每次修改后都运行测试
• 优先处理某个 Story
• 注意数据库迁移

这个设计我很喜欢，因为它在“全自动”和“可控”之间找到了一个不错的平衡：

• 如果你没有特殊要求，直接选 none
• 如果你有本轮迭代的偏好，可以临时注入

也就是说，它把“人类经验”当成一种可选输入，而不是每次都强迫你从头配置一大堆参数。

第四步：执行设置决定它跑得多激进

再往下，就是执行策略层面的配置。截图中可以看到两个核心问题：

1. 是否跳过 automate 步骤（测试自动化）
2. 最大并行会话数是多少

默认值是：

• 不跳过 automate
• 最多 1 个并行会话

对大多数真实项目来说，测试自动化是交付闭环里最不该轻易跳过的一环；而并行度默认设为 1，也避免了多个会话同时改动同一代码库时互相干扰。也就是说：

默认先追求“可控完成”，而不是“并行冲刺到极限”。

第五步：不同复杂度，自动映射到不同 Agent

有了复杂度矩阵之后，Story Automator 就能推荐 Agent 配置。

推荐配置如下：

• Low：create / dev / auto / review 都用 Claude
• Medium：create / dev / auto / review 都用 Codex，Claude 作为备选
• High：同样以 Codex 为主
• Retro：回顾阶段使用 Claude

从这个配置可以看出，它已经不是“调用一个模型”的层面了，而是在做模型编排。

而且它还提供了策略选项：

• Suggested：采用按复杂度分层的推荐配置
• Uniform：所有 Story 都使用同一个 Agent

不同团队可以这样用：

• 想稳一点，按推荐走
• 想保持行为一致，就统一 Agent

而从后面的配置摘要截图也能看出来，这次实际演示最后保存成了 all-claude。这恰好说明：推荐是推荐，不是强制。 你既可以让系统按复杂度智能分配，也可以为了稳定性或一致性，手动统一到同一类 Agent。

这一步让整个系统更像一个“调度器”，而不是一个简单的命令包装器。

第六步：配置会被显式保存，方便恢复和复盘

当你确认后，Story Automator 会把这次运行配置保存下来。截图里展示的是一个名为 all-claude 的配置摘要：

摘要里写了几件事：

• Epic 是哪个
• Story 范围是什么
• 自定义指令有没有
• create / dev / auto / review / retro 分别用什么 Agent
• 是否跳过自动化

这类“摘要页”看起来很普通，但它是编排器可恢复、可审计、可复盘的基础。

因为自动化一旦跨越多个 Story、多次会话、多个阶段，就一定会面对这些问题：

• 中途停了怎么办？
• 我这次到底选了什么配置？
• 为什么这批 Story 用的是这个 Agent 组合？

有了显式保存的配置，后续无论是恢复执行还是事后分析，都不会变成猜谜游戏。

实际体验结论

昨晚睡觉前，我直接把这 5 个 Story 交给 Story Automator 去跑。早上起来看结果，它总共跑了 5 个半小时。

坦白说，速度是比我自己手工盯着跑要慢的。按我平时的节奏，这 5 个 Story 如果自己来，估计 3 个小时内能收完。至于为什么会慢这么多, 具体原因还不太清楚, 还没有仔细的去分析它的实现原理，不过目前还只是试验版，能跑通比较重要。

目前比较适合：睡觉前梭一把。

另外一个我觉得做得不错的点，是每个 Epic 跑完之后，它会顺手做一次复盘，把有用的信息补到 project-context.md 里。

所以我现在对它的看法很简单：

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

如果你正在使用 BMAD 来开发项目，你一定要试一下 Story Automator，它可能是你将重复协调时间从小时级降到分钟级的工具。