EST的 RSS 预览

Mimocode/Opencode 的 Responses API 支持

2026-08-29 16:47:00

当前的 MiMoCodev0.1.13里，Responses API 有两套入口

Vercel SDK 的 responses() 方法 —— 触发条件是 provider id 为 openai / github-copilot / azure。
provider 为 gitlab 且每个模型加上 "useResponsesApi": true

就tmd很神奇。。一眼 vibe coding。我感觉世界上理解 Responses API 意义的人可能比例很少。。。

走 `gitlab`

{
  "$schema": "https://mimo.xiaomi.com/mimocode/config.json",
  "provider": {
    "gitlab": {
      "name": "GitLab",
      "models": {
        "gpt-5-codex": { "useResponsesApi": true }
      }
    }
  }
}

可以通过 GITLAB_INSTANCE_URL GITLAB_TOKEN 环境变量去变通，但是 token 来自 directAccessClient.getDirectAccessToken() 走的是 GitLab 的 token-exchange 协议（auth.openai.com 那套 OAuth exchange）

所以即使能把 instanceUrl 骗过去，token 交换这一步也会因为不是真 GitLab token 而失败——没有可配置的开源端点/key 入口，也没有绕过 token-exchange 的开关。

复用 `openai` 这个 provider id

支持自定义 options.baseURL + apiKey

{
  "$schema": "https://mimo.xiaomi.com/mimocode/config.json",
  "provider": {
    "openai": {
      "name": "My Responses Backend",
      "npm": "@ai-sdk/openai",
      "models": { "my-model": { "name": "my-model" } },
      "options": {
        "baseURL": "https://你的后端域名/v1",
        "apiKey": "你的key"
      }
    }
  }
}

provider id 必须是 openai/github-copilot/azure 之一

两个npm包的区别

@ai-sdk/openai-compatible 和 @ai-sdk/openai 都是来自 Vercel

	`@ai-sdk/openai-compatible`	`@ai-sdk/openai`
是什么	MiMoCode 自带/打包的通用 OpenAI 兼容适配器	Vercel 官方的 OpenAI 原生 provider
适用对象	任何"像 OpenAI"的第三方端点（OpenRouter、DeepSeek、本地 vLLM、各种网关）	OpenAI 自家 API，或任何支持 OpenAI Responses API 的后端（靠 `baseURL` 指过去）
在 MiMoCode 里的默认角色	自定义 provider 的默认 npm（你不写 `npm` 时，`up()` 函数默认填它）	绑定内置 `openai` provider id
协议能力	只有 Chat Completions（`languageModel()`）	Chat Completions + Responses API（`responses()` 方法）
路由差异	通用路径 `W()` 里固定走 `M.languageModel(id)` → chat	内置 `openai` loader 的 `getModel` 是 `return Z.responses(Q)` → 默认就走 Responses

npm: "@ai-sdk/openai-compatible" + 任意自定义 id** → 永远走 Chat Completions，拿不到 Responses API。这是最常用但偏偏不支持 responses 的那个。
npm: "@ai-sdk/openai" 本身有 responses() 方法，但只有当 provider id 叫 openai、github-copilot、azure，它们 loader 里也调 responses()）时，MiMoCode 才会用 Z.responses(Q)。自定义 id + @ai-sdk/openai 会掉回通用 languageModel() = chat。

实测模型支持

Opencode Go

model	completions	responses
deepseek-v4-flash	✅ 200	✅ 200
deepseek-v4-flash-vision-exp	✅ 200	✅ 200
deepseek-v4-pro	✅ 200	✅ 200
glm-5	✅ 200	❌ 500
glm-5.1	✅ 200	❌ 500
glm-5.2	✅ 200	❌ 500
glm-5.3	✅ 200	❌ 500
glm-5.3-flash	✅ 200	❌ 500
gpt-5.6-luna	❌ 500	✅ 200
grok-4.5	❌ 503	✅ 200
grok-4.6	❌ 401	✅ 200
hy3	✅ 200	❌ 500
hy3-preview	❌ 400	❌ 500
hy4-preview	✅ 200	❌ 500
kimi-k2.5	✅ 200	❌ 500
kimi-k2.6	✅ 200	❌ 500
kimi-k2.7-code	✅ 200	❌ 500
kimi-k3	✅ 200	❌ 401
longcat-2.0	✅ 200	❌ 500
mimo-v2-omni	❌ 400	❌ 500
mimo-v2-pro	❌ 400	❌ 500
mimo-v2.5	✅ 200	❌ 500
mimo-v2.5-pro	✅ 200	❌ 500
minimax-m2.5	✅ 200	❌ 401
minimax-m2.7	❌ 500	❌ 500
minimax-m3	✅ 200	❌ 401
muse-spark-1.2-contributor	❌ 500	✅ 200
qwen3.5-plus	✅ 200	❌ 401
qwen3.6-plus	✅ 200	❌ 401
qwen3.7-max	✅ 200	❌ 401
qwen3.7-plus	✅ 200	❌ 401
qwen3.8-flash	✅ 200	❌ 401
qwen3.8-max	✅ 200	❌ 401

Opencode Zen

model	completions	responses
big-pickle	⚠️ 429	❌ 500
hy3-free	✅ 200	❌ 500
laguna-s-2.1-free	✅ 200	❌ 500
ling-3.0-flash-fin-free	✅ 200	❌ 500
mimo-v2.5-free	⚠️ 429	❌ 500
muse-spark-1.2-contributor-free	❌ 500	✅ 200
nemotron-3-ultra-free	❌ 000	❌ 500

需要付费的 401 Insufficient balance 我就懒得测了。

git fetch 实现断点续传

2026-08-16 14:06:00

git fetch origin main --depth=1 一次只下一个 pack，包含所有缺失对象，国内这网络你懂的，断开就废了，然后从头下载，往往又出事；

老外不懂国内网络条件这么艰苦，只能自己让AI改造。结果：

https://github.com/est/snippets/tree/master/git-fr

步骤：

git fetch --filter=blob:none --depth=1 —— 只拉 commit+tree，这个速度很快，只有KB级别的传输
用 rev-list --objects --missing=print 算缺失集合，500 个 blob 一批回填
每轮重算缺失、只补缺的。

踩过的坑

git fetch origin <blobsha> 每次都会打印 fatal: bad object <sha> + error: ... did not send all necessary objects，但事后检查对象blob却真的下载了。后来发现因为cat-file 会拉数据,rev-list --missing=print 不会。
普通 git fetch origin <sha> 拿到的 pack 是薄包(thin pack)——服务器按客户端声明做 delta 压缩。如果本地声明的是 refs/remotes/origin/main(一个 commit),服务器据此假定我们拥有整棵树的全部 blob所以就啥都不给
git 原生 lazy fetch ，用 GIT_TRACE=1 git cat-file blob <missing> 抓到了 git 自己 lazy fetch 时实际执行的命令:

git -c fetch.negotiationAlgorithm=noop fetch origin --no-tags \
  --no-write-fetch-head --recurse-submodules=no --filter=blob:none --stdin

关键:
- fetch.negotiationAlgorithm=noop —— 不发 haves,服务器没法薄包化,只能发完整对象;
- --filter=blob:none —— 显式声明的 want 会绕过过滤器直接发送(partial clone 语义);
- --stdin —— want 列表从 stdin 读,天然支持批量。

还有很多放到 README.md 里了

安装

把 fr.sh 放到 PATH(如 ~/.local/bin/git-fr)，即可 git fr 使用。

或 git config --global alias.fr '!<绝对路径>/fr.sh'。

感觉，现在搞这些东西似乎意义不大了？反正大家都是让AI自己临时写一个脚本。。。🤣

有空让AI写个支持多线程并发 fetch 的。

继续搓英汉双解词典v3

2026-08-08 09:53:00

去年搓了个词典，本来懒得动了，但是看到opencode订阅还没用完，deepseek那么便宜，想着不用白不用，找了个最浪费token的方式，让AI再写一部词典

当年的AI我记得还是 gemini-2，其实很多东西不成熟。我也对AI脾气没摸准，很自然的就：“请输出 JSON”。今年学聪明了，直接上YAML。AI高呼你这想法真离经叛道但又极度合理。

甚至，block scalar（|）支持多行文本，不转义！

一个小技巧是，尽量避免嵌套的，什么 map套entries，每个 entry 再挂一个 senses 列表、每个 sense 再挂一个 examples 列表，别玩这一套。直接拍扁，层级尽可能少，整个 schema 里不允许出现一个方括号！

AI帮我写了个 validator，调教这一块还得是AI卷AI。不对劲的就返回错误让AI二次输出。但是基本都是1-pass通过。之前JSON翻车太多了。

跑了一圈还发现，短码对模型不友好。词性枚举最初写成 n/v/adj/adv，模型就开始输出 v.、V、vb、verb，改成全称 noun/verb/adjective 。我觉得这个跟 LLM 预训练 token 的分布高度相关，不要以为「缩写」对人和机器更友好！LLM是反过来的。

10年前第一版想的是薅Google Dictionary羊毛，去年第二版静态站中毒，想弄json，后来发现不对。20k的词汇量，对应20k个零碎小文件不可控。

这次第三版，回到传统RDBMS。一开始想一张 FTS5 全文索引表，让用户能模糊搜索、子串匹配，甚至搜中文释义——感觉这才配得上"AI 词典"的科技感。

然后又想了下，问了自己一个本该一开始就问的问题：用户到底是怎么用词典的？

输入一个完整的词，得到词条。前缀联想输入 "run" 提示 "running" 用一句 LIKE 'run%' 就够了，一共三张表

words：词头
senses：义项
surfaces：一切能解析到这个词的可供检索字符串：原形、变形、同义词、反义词、搭配

一个激进的决定，words 这个表甚至不保存词汇的归一化原始形式！直接作为 lemma 放到 surfaces 表里！

接下来，让AI写了个「递归」采集器，很简单，随便想几个单词，prompt就是让AI做词典；然后词典里的解释、例句再分词，再翻译。直到所有翻译和解释能自我包含，这样自动生成一部完整的词典。

让AI搓 BFS，起初几万词汇很舒服，很快发现，漂移进生僻词陷阱了：water 的释义带出了 odorless、colorless、tasteless，这些是英语词没错，所以又让AI给每个词标上分级，A1 A2 B1 B2 C1 C2 按顺序遍历。但我脑子抽了，没想到，这词在生成YAML之前，不知道自己的等级，AI提醒我，假设子词继承父词级别——够用就行。

后来想了下，反正AI闲着也是闲着，于是下载了一个权威 CEFR 词表，17 万词

https://github.com/Maximax67/Words-CEFR-Dataset/

这个词表的 level 是浮点，1.0=A1 … 6.0=C2，1.5 是 A1/A2 边界，天然可以先处理常用词后采集偏科的

甚至还提供了真实词频，the 出现了 928 亿次，还有 lemma 链接：ran→run、went→go、children→child，甚至还可以求出 clothes 没有链接，所以它是真词头。

跑起来之后，词典开始自己生长，敲入 caffeinate 睡了一觉。第二天起来一看，额度才用了 10% 不到。。Deepseek太耐烧了

顺便发现opencode关只在流式模式下返回内容，非流式直接返回空 body。挺浪费的说实话。

整理发现这个 CEFR 也tmd掺水，AI看了下挺多复数、连字符、西语、意大利语词汇混进去，后来干脆一刀切100w以上词频才纳入采集

哎，还得二次清洗

后续会把这个词典做出 on-demand 的：用户查一个词，命中缓存直接返回；没命中，当场调一次 AI 生成、校验、入库

最后，地址依然是：https://def.est.im/

清洗的时候AI又说怎么这么多人名地名乐队名，噪音可以跳过。

我想了下，其实对 language learner 还挺有用的。你输入一个名字，其实想知道这个名字的内涵，来源，是否得体，有坑的。

传统词典那些老学究那有时间给你折腾这那的。

一个地名儿，既然你查了，肯定是从某个书杂志地图册上碰到的，你是冲着大新闻、奇闻逸事来的。传统词典只告诉这是某国某地，有啥用？

其次AI又挑三拣四，说这西语词汇，扔了吧。老美现在西语人口那么多，流行文化我感觉都半边天了，用户查词汇碰到的概率很高。

过去纸质时代，让双语高手静下来编一部这样的词典，不容易

但是AI时代，有机会了。

我想就从这样的第一性原理，做一个完全服务语言学习者，感兴趣的词典。

不过 tokens 已经耗尽了，下次再说。

邮箱生态调研2026

2026-08-07 10:35:00

起初一个很简单的想法，把一个app/服务的私人数据，集中存数据库麻烦，不想维护担责，干脆放用户自己邮箱里，所谓"BYOS（自带存储）"。反正协议 SMTP/POP3/IMAP 很方便，然后调查了下很快发现，时代变了。

本来寄希望IMAP 这个协议，感觉能缝成一个读写API，

-APPEND 写（一封邮件 = 一个对象），FETCH 读，STORE 改 flag，COPY/MOVE 移动
- "目录 + KV"模型，flag（\Seen、\Flagged 等）即元数据位
- SEARCH查询主题、日期、自定义 header等
- 增量同步： UID + UIDVALIDITY，IDLE 可做准实时推送（仅单文件夹）

其实古董的 GMailFS / GMail Drive 之类把 Gmail 当虚拟磁盘的开源项目很多，各类邮件备份工具、笔记类应用的同步，都走过这条路

以前输入帐号密码这种简单方式，早被废了；甚至专用密码、动态密码都下掉了。主流邮箱（Gmail/Outlook/Yahoo）已全面转向 OAuth 2.0，就是它协议上是要走一个握手然后验证token的流程，用户门槛太高了。

让AI跑了一圈发现：

邮箱供应商对比：

供应商	开发者接入方式	开发者审核门槛	用户授权操作	用户麻烦程度
Gmail	OAuth 2.0（SASL XOAUTH2），scope `https://mail.google.com/`，需建 GCP 项目	最重：restricted scope，正式对外必须过 OAuth 验证 + 安全评估，每年复审；未过审只能 ≤100 测试用户或内部使用	跳转 Google 授权页点同意（OAuth）；或开 2FA 后生成 16 位应用专用密码粘贴	低（OAuth）~ 中（app password）
Outlook.com	OAuth 2.0（SASL XOAUTH2），scope `https://outlook.office.com/IMAP.AccessAsUser.All`，需注册 Microsoft Entra 应用	中等：Entra 注册免费即时；无强制审核；Publisher verification（去掉"未验证应用"警示）可选，需 EV 证书约 $100/年	必须先到网页设置手动打开 IMAP（默认关）；之后走 OAuth 自动授权，或应用密码	中（多一步开 IMAP）
Yahoo	OAuth 2.0（SASL OAUTHBEARER），需在 YDN 注册应用；或应用密码	低：无 Google 式受限 scope 审核	OAuth 授权页；或设置里生成应用密码	低（OAuth）~ 中（app password）
iCloud	官方支持三方应用 OAuth 授权，或应用专用密码	低-中	必须开 2FA，到 account.apple.com 生成应用专用密码（每应用一个，上限 25 个）	中
QQ 邮箱	无 OAuth，只有"授权码"	无（无审核无文档）	设置 → 账户 → 开启 IMAP/SMTP → 短信验证 → 生成 16 位授权码 → 粘贴进 App	中（2~3 分钟）
163 / 126	同上（客户端授权密码）	无	同上	中（2~3 分钟）

硬限制

供应商	IMAP 服务器	容量	单封大小	连接/会话限制	明文密码状态
Gmail	imap.gmail.com:993	15GB（与 Drive/相册共享）	25MB	15 并发连接；会话约 24h	已废除，需 OAuth 或 app password
Outlook.com	outlook.office365.com:993	15GB	约 35MB 量级	多客户端并发触发风控	已废除（2022-10 起强制 Modern Auth）
Yahoo	imap.mail.yahoo.com:993	1TB	25MB 附件	无公开数字	2024-05-15 起停用明文密码
iCloud	imap.mail.me.com:993	免费 5GB	约 20MB 量级	无公开数字	需应用专用密码
QQ 邮箱	imap.qq.com:993	约 16GB 级	普通附件约 50MB，大文件走中转站（有时效）	无公开文档，风控靠账号安全策略	无 OAuth，仅授权码
163 / 126	imap.163.com:993	免费容量较大（自动扩容）	普通附件约 50MB，大文件走"超大附件"（有时效）	无公开文档	无 OAuth，仅授权码

⚠️ 以上数字除标注官方来源者外均为常用量级，上线前需逐家实测；QQ/163 无官方公开 API/协议文档，以实操惯例为准。

操作路径

路径 A：OAuth 授权

Gmail / Outlook / Yahoo

用户操作：简单。点"继续用 Google/微软登录" → 同意 → 跳回，约 30 秒，体验最好，还能随时撤销。
开发者代价：Google 的 restricted scope 审核是真实的时间黑洞——提交安全评估、回答数据使用问卷、每年复审；没下来之前 App 无法对真实用户上线（只能测试名单）。微软无强制审核、Yahoo 无审核，相对顺。

路径 B：应用专用密码 / 授权码

用户要依次完成：开 2FA（Google/Apple 强制）→ 进设置页 → 生成 16 位码 → 回 App 粘贴。平均 5~15 分钟，而且这是客服工单的主要来源：没开 2FA、改了主密码（所有应用密码自动吊销）、粘贴带空格、公司/学校账号禁开……
Google 官方明说 app password "not recommended and unnecessary"，方向是逼大家走 OAuth。把产品押在 app password 上是逆政策而动，微软/Yahoo 已先后封死明文密码，这条路只会越来越窄。

结论：

算了。不要折腾。

附：参考来源

Gmail 应用专用密码与 2FA 要求：https://support.google.com/mail/answer/185833
Gmail 附件 25MB 限制：https://support.google.com/mail/answer/6584
Gmail IMAP 会话 / 连接限制、IMAP 常开（2025-01 起）：https://support.google.com/mail/answer/7126229 https://developers.google.com/gmail/imap/imap-smtp
Google OAuth 验证与受限 scope 年度复审：https://support.google.com/cloud/answer/9110914
Outlook.com 设置页（IMAP 默认关闭、强制 Modern Auth）：https://support.microsoft.com/en-us/outlook/pop-imap-and-smtp-settings-for-outlook-com
微软 IMAP OAuth 接入（scope、授权码 / 设备码流程）：https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
微软 basic auth 废除（Exchange Online，2022-10）：https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online
Yahoo 明文密码 IMAP 停用（2024-05-15）与 OAuth：https://help.yahoo.com/kb/SLN36636.html https://senders.yahooinc.com/developer/documentation/
Apple 应用专用密码（2FA 强制、25 个上限、改密吊销）：https://support.apple.com/en-us/102654

“畜牲”

2026-08-03 23:24:00

最近观察到娃学会了一些脱口而出的骂人的话，他骑车遇到看不惯的现象，就会骂一句 “牲口” ！

我也没太多去干预，毕竟比 “肏” 这类秽语要委婉那么一丢丢。

然后我最近也喜欢一边开 Vibe Coding 一边挂机 Rimworld 种田，

然后就发现一个事儿，我在牧场区域种的恶蘑菇，一种非食用植物，不会被动物吃掉；如果种玉米稻米土豆就会被偷吃，然后基地的粮食就少了一份。

所以突然就得到这么一个莫名其妙的理论：

动物并不会去主动破坏自己吃不了的东西

可能也有反例，狼、狮子会杀死竞争者的幼崽，黑猩猩会打架，一些鸟会破坏别的鸟的蛋；松鼠会偷走自己暂时吃不了的东西；海豚玩弄猎物；

通过这些例子，感觉破坏性和智力正相关，也就是利用预测能力和因果性去糟蹋东西。骂人是动物，仿佛动物低人一等，但是人心有的时候，甚至还不如“畜牲”

如果把这个限定缩小一点：

动物作恶的能力仅限身体。

人类里的坏逼，可能是唯一为了某个概念性的目标，会系统性破坏自己无法直接利用、甚至未来有价值东西的动物

智力让生物获得了创造未来的能力，也让它获得了毁灭未来的能力。

植物貌似也只会利用身体去占领局部环境，比如分泌毒素，遮挡阳光，向环境释放某种抑制剂。

但人类可以把攻击性扩大到远超生存需求的规模。为了荣誉、信仰、身份、复仇去糟蹋自己甚至不认识的人或者物。

这是一种非常特殊的“脱离现实反馈”的能力。

所以「畜牲」这个骂法有点讽刺——很多时候，骂别人「像动物」，其实是在指责对方缺少克制；但换个角度看，动物反而经常遵循一种很严格的生态逻辑：消耗资源、竞争、生存，不会为了纯粹抽象的理由把世界变得更糟。

btw 这个游戏真的有毒。好多年前尝试畜牧，结果直接生了一小崽，指数增长，然后过冬吃光了粮食，就纷纷饿死。然后来年就严格限制动物数量，定期宰杀，发现最简单的办法是砍掉雄性，留下1-2个传种，留下产奶产蛋的雌性。在感叹残酷的同时，结果无意中发现了回交。

据说宋朝马政废弛，就是因为儒生不忍心这么干，所以导致良马欠缺。

你说这个这个是人类的扭曲的道德还是动物的天性呢？

飞书并入豆包，文档是否减少？

2026-07-30 15:41:00

飞书并入豆包

7月30日，字节跳动发布内部邮件，宣布飞书产品团队与豆包产品团队将整合，成立新的豆包产品团队，由豆包负责人赵祺负责，飞书负责人谢欣向赵祺汇报。GTM（市场、销售、客户服务）体系方面，飞书GTM团队将与火山引擎团队整合，成立新的ToB GTM组织“创造力服务平台（Creativity Service Platform）”。整体负责字节 MaaS和SaaS等云服务的市场、销售和客户服务，由火山引擎负责人谭待负责，飞书销售负责人林婵、飞书战略及市场负责人史志隽向谭待汇报。重组之后，原有的飞书产品和服务保持不变，飞书还将和豆包在生产力场景进行更深度的产品协作。

然后刷到一个推

办公文档恰恰是 AI 要淘汰的信息交互协议。以前在两个信息孤岛传递信息，需要两边的对接人来进行消息组包和分解，来消除两边信息不对称的问题。
企业要推行 AI，那么两边各自准备一个智能体，他俩自己聊就行了。
没必要让智能体写一个报告或者 ppt，交给人类，再转交给另一个人类，再丢给智能体。
今后只会出现三个场景需要文档：
AI 写出来给 AI 看，作为阶段性消息压缩。
AI 写出来给人看，人写出来给 AI 看，作为人类和 AI 的两个信息孤岛的信息交互协议。

我想了下，不对啊。AGENTS.md、CLAUDE.md、.rules、MEMORY.md、DESIGN.md、SOUL.md vibe coding 发明出来多少妖魔鬼怪的文档环节

当然，有人说，你这码农自 high，非研发哪里需要这么多文档。但 vibe coding 暴露的问题不是码农特有的，而是大模型根本缺陷——没有连续性。

就算你用 A2A通信，打通 sub-agent又如何？同一个 agent 的今天和明天之间，隔着一堵完全遗忘的墙，比任何组织间的信息壁垒都彻底。

这一点已经被无数个 A\ 上的 blog 证明了。他们家甚至搞出来个逆天的 constitution 文档。为啥？两个 agent 的聊天记录是流水账，没法有意义地做版本对比。但一份 markdown spec 可以被 git diff、被 review、被回滚

当然，华丽排版的 Word、PPT 这种给人看的“表演”性质文档确实在这套流程里基本绝迹了。。。。吧？呃，不对。你汇报不做 ppt 能升值加薪吗？AI 能做 ppt，现在是卖点！

说到这里，我刚好遇到个工作里真实的事，有个说不清道不明的感受，不知道如何形容。

有个需求属于两、三个部门的业务数据流转

字段出了点差错，推送方和接受方都能做，管道方也能做，但是就推诿

这个时候，开个会，主持人出了个文档，突然事情就能进行下去了

本来我一直觉得，事在人为，人是做事的主体，但是这个情况里，人虽然有做事的「潜力」，但是种种原因，实际都懒得去做；反而一个文档被「讨论」出来之后，形成某种魔力，「驱动」人们去做事

然后我又想起，我在学生时代还有一个神奇的误解，小时候只知道美式三权分立，国会负责立“法”。具体立了什么法没太多概念直到贸易战，发现都是各种 act 。什么《民权 act》《清洁空气 act》《CHIPS Act》现在琢磨一下，有点类似戏剧里的 Act 1, Act 2，也有点“行动”的意思，这里的“法”其实和生活中“民法”有点微妙差异。它不是约束，而是推动。

AI看到这里，指出：

开会 + 出文档做的事情,恰好就是把私下的、各自心照不宣的认知,变成公开的、被见证过的认知。文档本身可能一个字新信息都没有,但"在场所有人一起看着这行字被写下来"这件事,把"我知道"升级成了"我们都知道,而且我们都知道我们都知道"。这就是谢林点(Schelling point)成立的条件——不是文档有魔力,是文档完成了一次"公证仪式",把博弈从"猜对方会不会先动"变成了"规则已经摆在这儿,不动才是异类"。

但是繁文缛节一多，这不就回到科层制，制度化（institutionalization）了吗？

我突然发现，spawn 一个 agent 是廉价的，那么理论上就如同 orchestrate 一个 subagent 集群写代码一样，需要形成很多 act 才能统一行动。

所以我得到一个阶段性结论：

将来办公文档恐怕不是变少，而是会海量的被agent生成出来。。。

继续下去，如果生成 act 的成本趋近于零，文档可靠性必然被稀释。就像货币超发会通胀——如果人人(agent)都能一句话甩出一份文档，那以谁的为准？

你别说，查一下claude code那几十万字的 system prompt。。。我甚至都怀疑里面冲突和矛盾有多少。。。

openai，A\ 这种 frontier 也是堆屎山，地球上有多少人还能做的更好呢？

也许，以后数据结构定义清晰，理解成本低，协议设计干练，RPC职权分明的数据驱动公司，和 “面条文档” AI驱动的公司，可能有天差地别的生产力悬殊对比。。。。

AI反驳说，真是世界没有唯一正确答案。不是一些 schema 套一点 enum 类型枚举就能穷尽的。

呃，业务建模当然存在各种问题，我想说的其实是，合理分工问题

现实当然是 messy的，往往没法写成一个固定 schema 的。就如同数学不可能背答案学好一样。

但是特定步骤和分工往往能解决一大片类似问题。

所谓部门结构决定代码架构，很多业务里的乱往往是部门墙导致的。过去部门调整往往伤筋动骨，顶层设计缺这少哪欠考虑

但是agent swarm呢？你的试错成本几乎为0 ，给agent赋予一个角色只需要一段 system prompt。

如果你懂业务，你可以几个小时构建一套完整流程，然后不停试错迭代。

这才是巨大的机遇。按照传统行业分工固定模式生产，想着AI 去充当裱糊匠，这个格局没打开。

想到这里，我突然回忆起这个炸裂的文章：

https://trinkle23897.github.io/learning-beyond-gradients/

EnvPool 的作者，他维护环境库时想找一种便宜、可复现的方式测试游戏环境是否跑得对，于是用 Codex(gpt-5.4)写纯规则策略，不训练任何神经网络。结果远超预期：一个打砖块游戏 Atari Breakout，策略从 387 -> 507 -> 839 -> 864，最后打到理论最高分；Breakout 从最开始简单的 “球在左边就往左” 发展出一套成熟完整的策略

作者说，专家系统、规则系统的失败，不是因为它表现不好，而是这玩意的维护成本十分高昂。人类手工维护 heuristic 很容易变成这样：

今天加一条规则修 case A。
明天发现 case B 被修坏了。
后天再加一个 if。
大后天没人敢删了。

那么有了 coding agent 之后呢？随着大模型能力提升，人类介入次数会逐渐变少，这个反馈循环就有机会在某些边界明确的系统里自动闭合，从而能够实现自动化用 HL 批量生产 HS：

环境反馈 / 测试失败 / 日志异常
coding agent 读 context
修改 policy / test / memory
重新运行
把结果写回 trials 和 summary
下一轮继续

我的takeaway可能更露骨：以前组织架构靠部门关系和体制运转

国会维护的 act 可能各种冲突、短视，矛盾，所以做事的主体，还得是人。

agent 时代不一样了。代码还是很乱，文档也很乱，但可能某种很牛的规则“醒过来”了

以后某个重要的岗位可能不是一个资深的员工，而是某个角落一段被反复验证过的核心代码

其实 quant 行业早就是这个形状了吧？

大多数人对AI 的态度，可能停留在提效上面。对于彻底掀翻桌子，固定岗位没了这种颠覆性的冲击可能没预料到，我这里的预测也有可能是错的。不过写到这，我突然发现，这篇blog核心观点就一句话：生产力的提升必然带来生产关系的变革。

刚好最近几天，肉眼可见这一轮AI 到顶了。美股科技股都在很大波动。

但是AI 对各行各业带来的冲击，我觉得刚开始。就看美国这一轮巨头会释放多少capex折损和二手设备流通，就像当年 dotcom bubble 带来廉价的fiber一样。

希望明年能用上 128G CAMM2 接口能跑 nvfp4 的本地推理AI！

EST修改