EST修改

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！

2026-07-27 14:39:00

美国当地时间2026年7月23日上午，在费城举办的国际数学家大会上，官方正式公布2026年菲尔兹奖完整获奖名单，北大2007级本科校友王虹、邓煜双双上榜。这是自菲尔兹奖设立近九十年以来，首次有中国籍数学家拿下该奖项

然后网上各国各路反思怪就开始表演了，我也未能免俗，对其中有个议题感兴趣，数学强国，是否要允许养十年冷板凳的学科？

首先，这个「十年」冷板凳的说法有点误导的。Fields Medal 奖励给40岁以下的人，正是因为数学这玩意出成果可以当庭验证，不用等诺贝尔奖那种从理论刷新实验和工业需要几十年。

王虹：Kakeya 猜想（三维情形）开始于2024–2025年前后，与 Zahl 的工作集中攻克，2025年发表突破性证明（127页论文）。

邓煜：Boltzmann方程 到 流体方程（Hilbert第六问题方向）一系列，他这个周期的确比较长，但也是2024–2025年前后与合作者完成严格推导相关关键结果。

所以数学这玩意属于发大招的前摇很长。但是结果突破了就立马见效。

然后就回到这个议题，科学技术被「包养」10年，甚至可能不出成果，国家或者结构敢这么干吗？能这么干吗？会不会导致关系户吃空饷？有没有什么问题？

与其对这个问题辩经，不如看看历史上真实的「科研」是怎么进行的。

很多人包括我，对近现代科学史的定义，是从 哥白尼 开始，我觉得要不就从 第谷 开始，我让 A\帮我做了一个调查，有哪些 ≥第谷 档次的重要科学技术发明人

很快AI 给了这样一个表格：

AI给的几点补充说明:

• 早期(1600–1900)明显比后期"密度更高":因为现代科学建制尚未形成,单个人的贡献边界更清晰,也更容易和第谷这种"孤胆式"人物类比。20世纪后科学越来越工业化、团队化(比如人类基因组计划、大型对撞机、AlphaFold团队),个人英雄式的叙事变少了。
• 第谷本人的定位其实很微妙:他不是理论家,而是"数据基建"式人物——用极致的观测精度为后人铺路。如果按这个标准严格类比,像哈勃(观测确立宇宙膨胀)、萨顿·汤姆森测序团队/人类基因组计划这类"以海量精确数据推动范式转移"的人/团队,可能比爱因斯坦这种理论天才更贴近第谷的"角色",而不只是"级别"。

看过给出的列表，我问了第二个问题，TA们的funding是如何的？

AI说：

这个角度非常犀利——科学史书写往往聚焦"发现了什么",却选择性地忽略"靠什么活下来"。

AI发现几个有意思的规律：

1. "贵族/私产型"最省心:第谷(早期)、达尔文、拉瓦锡(早期)、麦克斯韦——但拉瓦锡的例子提醒你,私产型资助有政治风险,大革命一来照样人头落地。
2. "体制拖欠型"最折磨人:开普勒是典型代表——头衔光鲜、待遇纸面上不错,但皇室实际不给钱,他等于用占星术这份"副业"养活了现代天文学的诞生。
3. "教会/修道院型"稳定但可能换来彻底沉默:孟德尔衣食无忧,代价是被历史遗忘35年——这提醒我们"资助稳定"和"影响力"未必成正比。
4. "先穷后爆红"是个反复出现的剧本:爱因斯坦、居里夫人、卡里科都是先坐冷板凳,成名/成功后资助才如潮水涌来——这某种程度上说明资助体系本身经常是滞后的、事后追认的,而不是有远见地提前下注。
5. 国家战争机器是隐藏的大金主:图灵(二战)、弗莱托与钱恩的青霉素产业化(二战)都靠战时政府不计成本砸钱才落地,和平年代未必能拿到同等规模的支持。

然后我问了第三个问题：按照列表加入一个 资方 出发点 视角。本来是想拿这笔钱或者这个项目目的是干嘛的？

AI回答：

这个视角非常关键——你其实点出了科学史书写的一个系统性偏差:我们只看到"赌赢了"的案例,资方当初的真实动机往往和最终成果风马牛不相及,而"陪跑"的绝大多数投入早就被历史遗忘了。

AI总结的几个扎心的结论：

1. "完全对口"的案例极少:整个名单里,资方目的和最终科学价值高度一致的,大概只有詹纳(疫苗已验证后拨款)和青霉素产业化(军事紧急需求)——而且这两个都是"结果已经初步显现,资方才敢下注",不是提前押中的。
2. "跑题率"高到惊人:占星、税收、御医、公关、军事测绘、密码破译、电话降噪、文档管理系统……这些才是历史上真正的"招标书",科学突破几乎全是"顺手做的"或者"钻空子塞进去的"。
3. 你说得完全对——这份名单本身就是幸存者偏差的产物。第谷时代还有无数宫廷占星师拿着差不多的资助,一辈子没算出任何有价值的东西;孟德尔的修道院同期资助的可能还有几十个神职人员搞园艺,没人记得他们。我们能列出这张表,恰恰是因为"科学价值"是事后被追认的标签,而不是资方当初购买的商品。
4. 一个推论:如果按"资方本意是否达成"来打分,这些人在当时的语境下,很多其实是“项目失败”或“跑题挪用经费”——开普勒如果被鲁道夫二世按KPI考核占星准确率,大概率是不及格的;伯纳斯-李如果被CERN按"你的对撞机数据分析进度"考核,万维网这个"副业"说不定还会被叫停。

最后，图穷匕见：

现代科研基金委的"结果导向"评审(要求预设可衡量产出、里程碑、KPI),可能恰恰系统性地筛掉了历史上产生最大价值的那种"跑题式"研究。

我的暴论：

资方为了装逼去包养才是科学研究第一必要条件。🤣 🤣 🤣 🤣 🤣 🤣

科学家得有品味和敢做副业的决心，才有可能搞出来大新闻

穷逼就不要去幻想搞什么科研了。除非要么你能混成网红，要么你需要遇到一个贵人

2026-07-23 18:24:00

对齐前：

┌──────────────┐     ┌──────────────┐
│  用户请求     │────▶ │  网关服务     │
│  User Req    │     │  Gateway     │
└──────┬───────┘     └──────┬───────┘
       │                    │
       ▼                    ▼
┌──────────────┐     ┌──────────────┐
│  认证服务     │      │  业务逻辑     │
│  Auth Svc    │     │  BizLogic    │
└──────────────┘     └──────┬───────┘
                            │
                            ▼
                     ┌──────────────┐
                     │  数据存储😆   │
                     │  Database😂  │
                     └──────────────┘

对齐后：

┌──────────────┐     ┌──────────────┐
│  用户请求    │────▶│  网关服务    │
│  User Req    │     │  Gateway     │
└──────┬───────┘     └──────┬───────┘
       │                    │
       ▼                    ▼
┌──────────────┐     ┌──────────────┐
│  认证服务    │     │  业务逻辑    │
│  Auth Svc    │     │  BizLogic    │
└──────────────┘     └──────┬───────┘
                            │
                            ▼
                     ┌──────────────┐
                     │  数据存储😆  │
                     │  Database😂  │
                     └──────────────┘

AI 的解释：

Iosevka 的作者 be5invis 当年做这个字体时明确说过：因为他和很多朋友生活在中国、日本，所以他把这款字体做成严格的 1/2 em 宽，专门用来跟汉字对齐——面向亚洲用户，用这个就能保住完美对齐。也就是说 Iosevka 的西文字形宽度天生就是 0.5em，不需要任何 CSS 补偿或 size-adjust 魔法，配任何满格 1em 的 CJK 字体（Hiragino、PingFang、Source Han Sans 等）都是精确 2:1。而且它的构建系统是声明式的，用 TOML 配置文件驱动，可以精细控制粗细、宽度、每个字形的风格变体。

中英混合是搞定了，最后那个 数据存储 Database 带emoji错位了。

emoji 还有个zwj的问题：

农民 emoji 🧑‍🌾 其实是"人"+ 零宽连接符（ZWJ）+ "农作物"两个 emoji 码位拼成的

在 wcwidth 计算，会分别得到宽度 2、0、2，加起来变成 4 列宽导致错位

目前暂时无解

2026-07-18 19:32:00

跟AI发闹骚学到的

https://github.com/isaacs/github/issues/330

Allowing CORS for the endpoint you mentioned would mean that you could complete this step of the Web flow from a browser:
And this would mean that you're hard-coding your client_id and client_secret into a webpage (or JS file loaded into that webpage) for everyone to see. This would indeed cause security concerns since the client_secret should be kept secret. If someone got hold of your client_id and client_secret, they could impersonate you application, and for example -- wipe all the tokens for that application:

如果允许在浏览器通过 client_id, client_secret 交换得到 access_token，那么实际上你的账号等于公开裸奔，你所有的 github 资产等于公开被人控制。所以必须走一个服务端流程，然后再把 access_token 下发

呃，好像很有道理。

2026-07-12 17:53:00

去年搓了个 gitweets，一个 .html 实现了「微博」，拿git历史当feed流～发推

这个周末看着 coding plan 还剩 20% 要到期，没用完，怎么办呢？想来想去，挖大坑干不完，小修小改，就拿这个 gitweets 继续填坑了

首先是让AI把界面改成模仿微信 朋友圈，啪一下，很快啊，结果让人非常印象深刻，很逼真

https://f.est.im/est

现在的AI真厉害。让我去调CSS可能这辈子都搞不出来这个效果了。

后面是我的一些唠叨，不感兴趣的可以关闭页面，或者去上面那个围观一下。

想起来独乐乐不如众乐乐，要不，支持个评论功能？

项目的初衷是 static page，要实现互动肯定得用一些API了。

最能想到的思路，走传统的 github issue 什么的，和这个 gitweets 最大的出发点冲突了：一个 git repo 包含所有数据，随时搬家，不用导出。

而且麻烦的是，post 是绑定到 commit 上的。如果你用一个 JSON 之类的来存评论，势必也会新增一个 commit，这样会污染post时间线。

突然想起来一个古老的东西，git notes，这是连 ChatGPT 和 Claude 都没想到的邪路，不过它们很快确认这个办法甚好，可行。

git notes选型定下里，建立这个数据模型让我纠结了很久。围绕 github 开展流程，让我一度误入歧途

1. oauth 登录，不要任何scope
2. 用来存 github notes的repo邀请登录人加入项目
3. 浏览器通过该用户access token发起 notes append

最后想明白了，压根不应该走浏览器这一套。而是只能走后端代劳，用 Fine-Grained PAT 来和 github API 交互

其间还考虑 github 越来越拉垮，想避免 vendor lock-in，直接走git http协议。

首先想到的是 Cloudflare 那个牛逼的 zig 写的 100kb 的 wasm 可以 http 读写任意 git 仓库

git protocol engine is written in pure Zig (no libc), compiled to a ~100KB WASM binary. Support for both v1 and v2 of the git protocol. Support capabilities including ls-refs, shallow clones (deepen, deepen-since, deepen-relative), and incremental fetch with have/want negotiation.

仔细读了下文档，让AI一起调研，发现tmd这玩意仅限 Worker 内部使用，只能读写 CF 内部的 假 git，不支持读写外部任意 git http。

用 isomorphic-git 坑也挺多 。还是先走 github API 吧

这个 git notes 要走REST API 有查询放大 3+N 的问题，怕掉用次数爆掉，于是让AI走 GraphQL。我自己手动是搓不动 GraphQL，太难了。AI虽然是 flash 普通智商版本，也分分钟拼接好。一次成功。真猛 😭

于是 Vibe 出来了。

搓完了想起一个问题，如果有人刷评论怎么办？于是让AI搓了个 /.admin 管理页面。也是秒写好。太方便了。

明显欠缺的功能搓完之后，感觉又进入了贤者时间，索然无味了。

2026-07-11 11:53:00

AI在 coding 的时候我其实在玩别的。希望agent 每次干完活，macOS 弹个通知。

手上是 MimoCode，就让它自己写个。啪，很快写好了。结果还是折腾了好一会儿， 记录几个有意思的小坑。

首先是如果当前CLI是活动的，就不弹通知。

需要判断活动窗口。最初用 osascript

osascript -e 'tell application "System Events" to get name of first application process whose frontmost is true'

直接报错 Not authorized to send Apple events to System Events (-1743)。

于是换 lsappinfo，走 macOS Launch Services API，不需要任何额外授权：

lsappinfo info -only name $(lsappinfo front)
# → "LSDisplayName"="Terminal"

还能拿 PID：lsappinfo info -only pid $(lsappinfo front)。

然后如何判定活动窗口是不是 CLI？

写死个["iTerm2", "Terminal", "Alacritty", "kitty", ...] 列表

太笨了。当前hook是子进程，直接遍历 parent 进程树啊！找到终端模拟器的 PID，再跟前台 app 的 PID 比对。

但是在 tmux 里爬出来是这样的：

node → zsh → tmux → launchd(1) → init(0)

Terminal.app 的 PID 根本不在树上。因为 tmux server 启动后被 reparent 到了 launchd，跟 Terminal.app 断开了父子关系。

又想到一个办法，直接查 $TMUX_PANE 是否是当前 active pane：

tmux list-panes -F '#{pane_id} #{pane_active}' | awk '$2==1 {print $1}'

如果 $TMUX_PANE == active pane ID，说明用户就在看这个窗口，不需要通知。完全不需要知道前台是哪个 app。

非 tmux 场景才用进程树 + lsappinfo 的 PID 比对。

然后就是挑选具体哪些事件要弹通知了。

权限通知：permission.ask，但文档说 "not yet wired"。试了一下，确实没触发。尴尬。雷军！！！金凡！！！

最后的方案：注册 permission.ask 占位，如果哪天接入了就能精确捕获。目前靠 tool.execute.before 抢占并推断。工具跑完了说明权限已过或不需要。

还有个情况就是 Subagent 完成也给我哐哐弹。最初硬编码了 SUBAGENT_TYPES = ["general", "explore"]；后来发现 actor.preStop / actor.postStop 的 input 里有 mode: "subagent" | "peer"。于是就做了个计数器

最后通知到时候带上 Session 名字，折腾了一圈 直接 sqlite3 ~/.local/share/mimocode/mimocode.db "SELECT title FROM session WHERE id = '$SESSION_ID'"

完整代码放在

https://github.com/est/snippets/blob/master/mimocode-hooks/notify-done.ts

复制到 ~/.config/mimocode/hooks/ 就可以试试效果