EST修改

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/ 就可以试试效果

2026-07-09 23:01:00

自从自个儿琢磨出 locate cost 之后便开始关注这方面问题。最近看到两篇喷 harness 问题的

第一个是 Can Bölük https://blog.can.ac/2026/02/12/the-harness-problem/ 今年2月的时候发现：

Codex uses apply_patch: It takes a string as input, which is essentially an OpenAI-flavored diff, and instead of relying on a structured schema, the harness just expects this blob to follow a strict set of rules
Claude Code (and most others) use str_replace: find the exact old text, swap in the new text. Very simple to think about. But the model must reproduce every character perfectly, including whitespace and indentation.
Cursor trained a separate neural network: a fine-tuned 70B model whose entire job is to take a draft edit and merge it into the file correctly

如果你在 Codex 用别的模型

Grok 4’s patch failure rate in my benchmark was 50.7%, GLM-4.7’s was 46.2%.

Aider’s own benchmarks show that format choice alone swung GPT-4 Turbo from 26% to 59%, but GPT-3.5 scored only 19% with the same format because it couldn’t reliably produce valid diffs.

The Diff-XYZ benchmark from JetBrains confirmed it systematically: no single edit format dominates across models and use cases. EDIT-Bench found that only one model achieves over 60% pass@1 on realistic editing tasks.

懒得看原文的我直接说结论：大家都在争论哪个模型编程更强，但很多模型都知道要改什么，失败其实发生在具体改哪里。

他做了个实验，同样的 16 个模型，只换编辑这个 tool call，改成他自己发明的 hashline，给每行内容打一个短哈希做锚点，Grok Code Fast 1 从 6.7% 直接跳到 68.3%。

Can Bölük 这个老哥非常生猛，2021年有篇博客讲他在Intel CPU 发现一个指令可以序列化/反序列化打印所有 x86 指令集。微码立功了！

他这个 hashline 也很巧思，我也是最近才琢磨明白。你仔细想就会有个疑问，为啥不直接用 行号？

有个相关的问题一直困扰我。我经常让 Gemini 去搜我博客，我博客网址都是类似 stderr-XX 其中 XX 是数字，然后 Gemini 经常把别的文章内容给我总结批判一番。我得到的结论是 LLM 不识数。

后来在学 RAG embedding vs BM25 的时候突然顿悟了，tmd 这个基于 基于语义空间的相似度匹配 有利有弊。好处是比如你检索 汽车，它能联想到 车辆，无需 FTS 那里你自己要维护一套分词近义词表。坏处是行号 223 233 它觉得很「近似」直接搞混 😂

扯远了。

然后是前几天 Armin Ronacher 的 https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/

这老哥是 Flask/Werkzeug/Jinja2作者，现在主要在撸 Pi 这个agent（值得一题的是上面的老哥在撸 oh-my-pi 这个 fork）

他发现 Opus 4.8 和 Sonnet 5 在非 Claude Code 的 harness（比如他自己的 Pi 项目）里调用嵌套 edits[] 数组时会莫名其妙地塞进一堆乱七八糟的 <antml:function_calls> 这种内部控制字符。老的模型反而没这个毛病。他推测是 A\ 家训新模型强耦合了 Claude Code。逆向发现 Claude Code 客户端对格式错误极其宽容，有一整套别名映射、Unicode 修复、静默过滤多余字段的逻辑。结果就是模型在RL中适应了格式差不多就行，反正harness 会兜底。

看完这两篇我觉得印证了我前面 locate cost 一问的所有猜想。AI 指出，真正可能的机制更朴素：

RL 训练信号里，整段重写 往往比 精确定位再小改 更容易拿到奖励。重写不会因为空白符不匹配而报错。这跟第二篇里 Armin 讲的模型在宽容的 harness 里学会了偷懒，是同一个因果链条,不需要引入纹理/结构的形而上区分也能解释。

也就是说，LLM上课答题只给答案分，不给过程分，导致背题偷懒 🤣 这个方向在研究界是有名字的，叫 process supervision / process reward model，过程奖励模型。OpenAI 那篇《Let's Verify Step by Step》基本就是在数学推理场景做这件事。

但这条路有两个真实的代价，其一是 过程标注比结果标注贵得多；其二 如果训练时的 harness 比部署时的 harness 更宽容,学出来的好过程标准本身就是错的。

所以又回到一个老生常谈的话题。各大模型厂家都在推出自己的 CLI。观察「过程」比最终结果更值钱！

我让AI去 fact check了下。果然

Claude Code

数据使用文档里明确写着两条完全独立的通道:

1. consumer 账号里"Help improve Claude"那个 toggle 控制的是"conversation content"——如果你打开它,用于训练的数据 包括整个相关对话,连带任何内容、自定义样式或对话偏好。这是"代码/对话内容"这条线。
2. DISABLE_TELEMETRY 一条完全独立的遥测通道，文档原话是:Claude Code 会从用户的机器连接到 Anthropic，记录延迟、可靠性、使用模式这类运营指标。这类日志不包含任何代码或文件路径。关掉这条通道要单独操作，跟训练开关是两个开关、两套机制、两份文档。

Kiro(AWS)

设置页面里直接摆着两个并列开关

1. Content Collection For Service Improvement，关掉它就是不许训练
2. Usage Analytics And Performance Metrics 官方描述是"这是一个单独的、用于使用遥测的设置"。

也就是说厂商自己都承认这是两套独立治理的东西——只是大多数用户可能只会想起关第一个开关。

Codex(OpenAI)

官方文档列出了它 OTel 遥测会上报的事件类型，其中包括

• codex.tool_decision 工具调用是被批准还是拒绝,以及这个决定来自配置还是用户
• codex.tool_result 耗时、是否成功、外加一段输出片段
• codex.user_prompt 默认只记录长度、内容会被打码

听起来很克制,但 工具决策 + 输出片段 + 时长 这几项拼起来 就是前面说那种 过程信号，不是代码本身。精确刻画了模型在 harness 里怎么试错、被拒了多少次、跑了多久。这条 OTel 通道是靠单独的 config.toml 开关控制的，跟 ChatGPT 账号层面的训练数据开关是两件事。

Google Antigravity

方向比较模糊，它把训练相关的退出开关本身命名为 Enable Telemetry，把两件事的名字焊在一起。

Google Groups 的讨论帖里用户在问这个开关到底关不关得掉训练,官方也没给出干脆的回答。

所以接下去的推论就很简单。利用公开语料能训练出 2025年级别的sota llm。但是往后就看各家谁能拿到更多的轨迹数据了。无论靠CLI / app 装机量，还是买数据，偷数据，各显神通。其中装机量/DAU几乎正比于以后的智力天花板。所谓的 trillion tokens models 估计就是从各种日志里来的（而不是人类语料）

继续推演下去，有意思的一点是，可预见的将来，AI 的智力增长几乎全来自于coding

因为 coding 有个编译器师爷能把关，保证产出可验证！

别的什么 具身 世界模型，我觉得难了 😆

还有一个考虑的，装机量看 2C，各行业应用 2B 也很重要。比如design类的。这种“轨迹” 如何收集改进也很讲究。

但是design想了下又挺主观的。不过可以降低一些看上去很笨的地方。

甚至如果从公平的角度来说，AI厂家，除了按成本收费之外，还应该给高价值数据返钱才对。不是之前有报道说Anthropic 和 OpenAI 都签了七位数金额的 RL 环境和人类专家数据合同，预计投入还要再涨 3-5 倍。就是拿来训练“过程”的吧。

今晚娃又沉迷pad，我给他pad锁了 😆

为啥说起这个呢，我一直让娃坚持写「语音日记」

但是孩子长大了，他写得越来越不耐烦了，而且我苦恼作文没有批改，所以这个日记习惯实际上成了低水平重复。

其实把复制粘贴到deepseek，提示词 “以XX年级的标准点评改进下这篇” 就能搞定，奈何我家娃太懒。

所以我一直想给娃弄一个 作文训练 app。本来想不就是AI一问一答批改么。

但是想到 locate cost 突然觉得有点难。。。。。甚至比AI coding 还难。。

代码为什么定位相对容易。 哪怕 str_replace 因为空白符不匹配而报错,它要定位的目标本身是离散、有边界的——一行代码、一个函数,有语法(AST)天然把文档切成可寻址的单元。

或者 hashline，行号就每句话一个稳定锚点，把找位置从模糊的文本匹配变成精确的 ID 查找。这招完全可以照搬到「改病句」场景。做个 diff 也容易

但写作的问题，往往根本不是一个可以圈起来的line或者span，而是句子之间关系的性质。 “这段论证缺乏内在逻辑”，“这句话和上一句衔接生硬”，“全文的语气从第二段开始飘了”——这些反馈即便你精确指出“第3段第2句”,真正需要改的可能是第1句、连接词，或者整段重组。

代码的 bug 通常局限在一个可编辑单元里，作文的"bug"经常是分布式的、关系性的。定位到具体文字之后，改哪、怎么改这一步反而更模糊，比代码多绕一层

AI说，写作其实分两个层次

1. 可验证层
   语法错误、拼写、用词重复、被动语态滥用、句长方差、可读性指标（类似 Flesch-Kincaid 这类公式）、有没有明确主题句
   这些跟代码的 compiler/linter 是同一类东西,规则可判定
2. 不可验证层
   论证有没有说服力、有没有原创视角、语气是否统一、是否“有意思”？
   可以叫“品味”层。只有经验丰富的人的判断。而且专业阅卷老师之间对开放式作文打分的一致性本身就不高

怎么切入呢？

后者也有一些实践，比如借鉴 AP 阅卷没，用锚定范文（anchor papers）做少样本参照。而不是让模型凭空判断“这篇好不好”

也可以做高亮 + 提问式 而非直接改。比如第 2 段第 3 句话里，“非常开心”这个词能不能换一个更具体的？比如描述一下你当时的表情或动作？

甚至可以 示例驱动：AI 给出 改前 / 改后 小对比，只改 1-2 处；然后 多轮对话，孩子自己决定要改哪里，AI 只辅助，而不是 AI 主导大改。

要么就局部训练，针对常见作文类型（记事、写景、议论），开头、过渡、结尾分别训练

这样看来，写作文直接给娃一张无限大的白纸并不好。参考 Notion 的 Block 概念，强迫孩子在输入时就把“骨架”和“血肉”分开。比如，第一步只允许输入 3 个论点（形式）；第二步再针对每个论点去填充素材（质料）。通过产品机制，人为制造出“伪 AST（语法树）”。

或者阻断直接生成，只给“反向约束”。不输出完整的句子让孩子抄，扮演“刁钻的苏格拉底”。比如，当孩子写“今天我很开心”，AI 的反馈不应该是“你可以改成：今天我心花怒放”，而应该是抛出环境约束（Harness）：“你当时手里拿了什么东西？你的心跳有多快？”——逼迫孩子自己去完成“从潜能到现实”的推导。

当然，做好 diff 和版本控制是基础。记录孩子打磨一句话的过程。让孩子直观看到词汇的微调是如何让语义的边界越来越清晰的。

哎，这么一拆解又有点思路了，但比预计的感觉麻烦得多啊。不过语文教育有大问题啊。明明是工程上可以细化训练的（虽然很难，过去没AI需要大量人工精力）。上课根本不讲。全靠孩子天生悟性。以上种种，今年4月才喷过一篇《语文学习和考试》

作文从小学一上来就300 字 500字，其实真应该「刻意练习」的是语言 primitive。什么 铺垫、呼应、留白、对比、节奏、悬念、感官、动作、心理、对话等等，都上手了，然后再各种变化，组合。

学编程也是从少量 keywords ，赋值语句，条件，循环这样一步一步来的嘛。

过去没太好的语文教学条件，归根结底因为一个班上50个娃只有一个语文老师。

但是现在有LLM了。