Lslightly's Universe

现在在做大型的rust项目(servo)。一个使用agent比较困难的点在于，如何控制agent的上下文范围，以及是否需要给agent设置上下文范围。

对于这种大型项目，如果没有提前的一个overview架构分析的话，人本身不是很好上手，agent也会陷入和人一样的需要各种查找的情况。这时候就不一定想的清楚。

目前就用了codegraph和rust-analyzer lsp，但感觉还是不够高效。

应该找一个人可以看懂，同时又方便agent理解阅读的可操作中介。但是我不知道有什么。

现在的调试做法（似乎比较低效）

按照某个例子以及打日志的方式，看整体流程。有web内核整体的工作思路，没有JS对象的模型，也没有web内部API操作了什么对象的概览。web内核 DOM API实在太多了。

我是先看打日志，同时在调日志的过程中看流程。但是我没有梳理UML类图，所以存在遗忘的情况。整个流程非常复杂，UML类图、流程图、时序图感觉还不够。

我感觉我还是没有掌握快速入门一个项目的精髓，效率还是有点低效。如果有什么好的开发者心得，是不是更好一些？但是项目不一样，所使用的方法可能也不同。

值得尝试的方向以及相应的工具

整理下来，判断一个”中介”值不值得做的标准其实只有一条：要么它能从源码重新生成，要么它被一个能跑起来的断言钉住。 手工维护的文档和手画的图，在 servo 这种规模的仓库里大概活不过两周。按这条标准，想试的方向分三层。

一、自动生成：不腐烂的索引

这类东西不是给我读的，是给我和 agent 查的。重点是查询能力，不是产物本身。

• WebIDL → 接口继承图。components/script/dom/*.webidl 里的 interface X : Y 就是类层级本身，写个脚本渲成图就行，每次重新跑一遍就不会腐烂。这直接回答了上面”没有 JS 对象模型”的问题——模型一直都有，只是没人把它抽出来。
• 规范自带的索引。HTML/DOM spec 自带 IDL index，以及事件循环、渲染的图。标准委员会在替我们维护，不要自己重画。
• 代码结构。cargo modules / cargo depgraph 出模块依赖图，rust-analyzer 的 crate graph 和 call hierarchy 做按需下钻。

二、可运行：轨迹配方

把”先看日志再看流程”固化成一份能直接执行的配方：一个固定的 WPT 用例 + 一条确切的命令 + 日志过滤前缀 + 期望看到什么 + 看到 A 说明走了哪条路。它的价值在于是命令而不是描述——agent 能直接跑，我能直接复现，也不会因为流程变了就失效。

配套想试的是 rr 这类 record-replay 工具。servo 是并发加多进程 IPC，正序打日志线性又不可逆，只能靠记住前面看过什么。rr 能倒着走、能反复回到同一时刻，相当于用反向调试替代记忆——正好治”没有梳理类图所以存在遗忘”这个毛病。

三、被测试钉住

任何一条搞明白了的不变量，立刻写成断言，或者一个小 WPT 用例。这是唯一同时能防我遗忘、又防 agent 踩坑的机制：我忘了没事，测试不会忘。

四、两条配套的方法

先固定一条垂直切片。 挑一个用例当标本，之后学到的东西都挂在这条切片上。不要横向铺开去理解架构——横向铺是遗忘最快的路径。架构应该是穿过一次具体修改的副产品，不是动手的前提。

上下文范围不按文件划，按任务契约划。 按文件划，agent 看不见跨层后果，容易做出局部正确全局错误的事；完全不划，它会读两百个文件然后开始模式匹配。给四件套：目标 + 验收方式（一个跑得起来的测试）+ 入口点 + 禁区。地图和检索能力给全，文件不给全，同时要求每个结论都带 file:line。

具体的工具与插件

按上面的三个层次，把现成的、能直接拿来用的东西列一下。有些是给 agent 用的，有些纯粹是给自己用的。

给 agent 接上语义层

痛点是 agent 默认只能 grep，而 grep 在 servo 这种规模下等于瞎猜。

• mcp-language-server。把它架在 rust-analyzer 前面，definition / references / hover / diagnostics 就变成了 agent 能调的 MCP 工具。这个改动成本最低，因为 rust-analyzer 我本来就在用，只是 agent 现在够不着它。
• Serena。在 LSP 之上封装成符号级工具：get_symbols_overview、find_symbol、find_referencing_symbols。它把”按符号检索”而不是”按文件读”变成了 agent 的默认动作，直接对应上面说的”上下文范围按任务契约划”。它还有个 .serena/memories/ 做跨会话的项目记忆，本质上就是我在找的那种中介。
• rust-analyzer 自己的 SCIP 索引。rust-analyzer scip . 能吐出一个静态索引文件（protobuf），全仓库的定义、引用、实现都在里面。好处是离线：agent 查一次索引，比每次现场做符号解析便宜得多。

给 agent 一张地图

• cargo metadata。整个 crate 和依赖图是 JSON，直接喂给 agent，比让它一个个读 Cargo.toml 强太多。这条几乎零成本，我居然一直没做。
• cargo modules / cargo depgraph。前者出模块树，后者出 dot 格式的依赖图。
• Searchfox。这个我觉得是最接近我想要的”可操作中介”的东西——它就是为 web 引擎代码做的：全文搜索 + 符号 + 交叉引用 + git blame + 测试覆盖，能直接回答”这个 WebIDL 接口谁实现了、谁调用了它”。要注意：Searchfox 索引的是 mozilla-central 里的那份 servo 代码（路径长得像 servo/components/...），不是 servo 上游仓库的最新状态，当参考模型用可以，别当权威。顺带一提，Gecko 那套 IDL ↔︎ 实现的交叉引用结构本身就是很好的样板。

让流程可回放

这条让我意外：servo 是内置支持 rr 的。

• ./mach run --debugger=rr testcase.html —— 直接拿 rr 当调试器。
• ./mach test-wpt --chaos <test> —— 用 rr 录 trace（需要 rr 在 PATH 里）。
• 跑单个用例：./mach test-wpt tests/wpt/tests/dom/historical.html。注意要用 release 构建再配 -r 跑，debug 构建跑 WPT 容易超时。

这就是”轨迹配方”的落地形态：一个固定用例加一条 mach 命令，可以写进文档里，也可以写成一个 skill 让 agent 按名字调。

一个环境上的前提：rr 需要 Linux，而且要能拿到 perf 事件和相应的内核设置。我本地是 Windows，如果开发环境放在远端 Linux 上就正好。

时序图不用画，让它生成

这条直接回应”时序图还是不够”：把打点从 println 换成 span，时序图就是产物而不是手稿。

• 用 tracing 的 span 按层打点，导出成 chrome trace 或 flamegraph，丢进 Perfetto / chrome://tracing 看。跨层的时间关系一眼可见，而且每次重跑自动更新，不存在腐烂问题。
• servo 自己已经有日志和 trace 设施，值得先看看现有的能不能直接导成 trace 格式，能不自己造就不自己造。
• 所有图都用文本格式（mermaid / graphviz dot / D2）。理由很实际：agent 能读、能改、能 diff，PNG 只能给人看。

给 agent 本身配的东西

• CLAUDE.md / AGENTS.md：最小的中介。放构建命令、跑单个测试的命令、分层说明、禁改清单。半小时的事。
• 项目级 skill（.claude/skills/）：把轨迹配方写成一个 skill，agent 按名字调用，而不是每次重新摸索一遍怎么跑。
• hooks：编辑后自动跑 cargo check / clippy，把反馈回路从”我想起来才跑”变成”自动跑”。
• 受限子 agent：给一个只许搜索和读取、且只返回 file:line 的”导航 agent”，主 agent 的上下文就不会被文件内容淹没。这是划上下文范围最直接的手段。

一些传统工具

• cargo expand。servo 有大量宏和代码生成（bindings 就是生成的），展开之后才是真正的代码。
• ast-grep。结构化搜索，“找出所有实现了 X 的 impl”这类问题，文本搜索答不上来。
• git log -L。追一个函数的演变史。入门一个子系统的时候，这比读文档有用得多。
• scc / tokei。先知道肉长在哪。
• WPT 自己的 interfaces/ 目录和 idlharness 测试。IDL 和对象模型是规范产出的，直接用，不用自己整理。

先做哪个

不用全都上。按成本排，前三件事大概一两天：

1. cargo metadata + mcp-language-server —— 半天，让 agent 至少能按符号而不是按文件看代码。
2. 写 CLAUDE.md —— 一小时，把构建、跑单个 WPT、分层、禁改清单写死。
3. 一条固定的 mach 轨迹配方 —— 挑一个 DOM 用例，把命令和期望输出记下来，之后所有理解都挂上去。

rr 和 span 时序图收益更大，但要先踩环境的坑，放在后面。

编译时长与内存问题

还有一个很现实的问题：因为要改一些相对上游的库，每次 servo 编译要 3 分钟，而且要 32G 内存（16G 不够，IDE 的 rust-analyzer 还有额外的开销）。这件事值得单独想一下。

先量，再改

不量就调参数是瞎调。三个命令：

• cargo build --timings —— 出一份 HTML，每个 crate 的编译时间和并行度都在里面。
• /usr/bin/time -v ./mach build —— 看峰值 RSS。
• cargo llvm-lines —— 找泛型实例化爆炸的元凶。

我的猜测是峰值内存的主犯不是”上游库”本身，而是最终链接和少数巨型 crate 的 codegen。链接那一步要把整个程序的符号表装进内存，往往是整个构建的峰值时刻；而 servo 这种体量，debug info 也能占掉一大块。先确认是哪一步在吃内存，再决定动哪一刀。

最值钱的一条：把回路拆成快慢两条

3 分钟加 32G 的本质问题是每一次改动都要付全款，但绝大多数改动其实不需要跑完整 servo。

• ./mach check。只做类型检查，跳过代码生成。这是 servo 官方文档自己推荐的迭代方式：改了一个 crate 导致别的 crate 报错时，用它而不是全量 build。
• ./mach build --dev -p servo。只编 servo 这一个包，不编 libsimpleservo。
• 最小复现 crate。既然要改的是上游库，就 cargo new --lib，只依赖那个库，写一个最小重现。改-试循环从 3 分钟降到几秒，改好了再搬回 servo。这条收益最大，因为它把问题从”优化编译系统”变成了”组织工程”。
• 只有必须看真实渲染/行为时才走慢回路，而且攒一批改动一起验证，不要每改一行就全量编一次。

降内存峰值：不写代码就能拿到的

• -j 调小。峰值内存大致等于并行度乘以单 crate 峰值，16G 撑不住通常就是并行度太高。牺牲墙上时间换可行性，这是最直接的一招。
• 关掉 debug info。这条我很怀疑是你 32G 的主要来源之一。cargo 支持用环境变量覆盖 profile，不用改 servo 的 Cargo.toml：CARGO_PROFILE_DEV_DEBUG=false，折中一点用 1 或 line-tables-only。注意这跟上一条建议（用 rr/gdb 回放）是打架的——没有 debug info 就没有像样的栈。所以要么保留 line-tables-only 这个折中，要么只在跑构建时关、调试时开。
• 关掉 LTO：CARGO_PROFILE_RELEASE_LTO=false。fat LTO 要把整个程序的 IR 装进内存，是内存杀手，开发期没有任何必要开。
• codegen-units 调大，不是调小。这个方向容易记反：codegen-units = 1 会把内存需求顶上去，调大到 256 反而省内存（代价是运行时性能，开发期无所谓）。
• 换链接器。servo 在 Linux 上装了 lld 就会默认用它，确认一下 configure 输出里的 checking for linker... lld；Windows 上是 export LINKER=lld-link。链接是内存峰值的高发时刻，换 lld 或 mold 两头都省。
• 加上 swap/zram 兜底。目的不是变快，是把”直接 OOM”变成”慢一点但能跑完”。

缩小重编的爆炸半径

改上游库最疼的地方在于：它坐在下游依赖链的根部，一改签名，下游全部重编。

• 优先”加”，而不是”改”。加一个新类型、一个新 trait 的默认方法、一个新字段，只有相关 crate 重编；改一个被广泛使用的函数签名，全下游重编。同一个功能，两种改法代价能差一个数量级。
• 先把公共 API 定稳，再改实现。cargo 的增量粒度是 crate：不动公共 API，就只重编当前这个 crate。
• 别 cargo clean，别乱动 workspace 的 Cargo.toml / Cargo.lock。一改 fingerprint，全废。
• sccache（mach 里配 [build] ccache = 'sccache'）。但要清楚它的作用域：它救的是清空 target、切分支、换构建配置这类场景，而且命中率取决于依赖图稳不稳；它救不了你的编辑回路——改一个上游 crate 会让所有下游全部 cache miss。另外注意版本，老版本 sccache 在 cache miss 时会把增量编译拖慢好几倍（有人实测 1m53s 对 37s）。
• target/ 放快盘上，排除出杀毒软件的实时扫描。

rust-analyzer 那笔账

你说”16G 不够用，IDE 还有开销”——这两笔账其实可以分开算：

• 关掉 build script 重算：rust-analyzer.cargo.buildScripts.enable = false。RA 为了跑 build.rs 会额外起一套 cargo，内存差不多翻倍，而 servo 这种项目你多半用不上这个精度。
• 给 RA 单独的 target 目录：rust-analyzer.cargo.targetDir。
• 改掉它的 check 命令：rust-analyzer.check.overrideCommand 指到 ./mach check 或 cargo check --message-format=json。
• 最重要的一条：别让 RA 的检查和你的大构建同时跑。 两个十 G 级别的内存峰值叠在一起必然爆。跑 ./mach build 的时候把 RA 停掉（VSCode 里禁用扩展），这是零成本的。

硬件

说句直白的：16G 对 servo 就是不够，这是配置问题，不是技巧问题。 上面那些手段能把你从”跑不动”救到”跑得动”，但代价是墙上时间，而且 -j 调小和关优化会影响你验证真实行为的可信度。

32G 是现实底线，64G 才谈得上舒服。如果本地加不了内存，把构建放到远端大内存 Linux 机器上更划算——用延迟换内存。这个方向你本来就有经验（见 SSHFS服务器目录挂载至Windows本地）。

以上都还在”想试”阶段，等真的跑出东西再回来补结论。

忆好友

昨日和实习结束的实验室同学约饭，马上她就要会学校了。真是感慨不同公司的差距，以及不同方向的差距，以及人的效率的差距（这一点我会在软件工程实践方法论中提及）。

当然先入为主的谈论工作相关的似乎是我的癖好。因为我似乎总是喜欢别人讲工作上的事情，因为我可能比较憧憬别人的工作方式和工作环境。但是如果把我放到那个环境下又会怎样，是否也能达到相同的水平，那就不好说了。

吃完饭就是逛二次元集市了。实话讲我对二次元集市并不是特别感兴趣，一方面我看的番很少，另一方面二次元的钱真好赚，各种没有什么实际使用价值，但是情绪价值拉满的二次元小垃圾。所以逛集市主要是陪人，看人逛着开心我就开心，还有听生龙活虎地对各种人物、人物之间的关系以及各种故事的介绍（虽然听了马上就忘记了，以及噪声太大导致遗失了大部分信息，只能嗯、点头），感慨于二次元玩家的见多识广。不由得感慨他们的世界好像如此精彩，也就引出了对生活选择的各种思绪。真是羡慕极了。一方面效率又高，一方面生活又精彩。似乎就是这样，无论是工作还是生活，都遵循相同的经营之道。It depends on what you have seen, what you want to reach, who you want to be. 但首先还是what you have seen。

孤独感

当然天下没有不散的宴席。在说了“达维斯达尼亚”（俄语的“直到再次相遇”，До（直到） свидания（见面），Do svidaniya）后，乘上了反方向的地铁。分离的感觉是自然的。虽然我已经经历了离别多次，但这种手足无措和现实感确实是无可避免的。也只能祝愿大家都有光明的未来了。当从口头禅到这句话的每个字真的发挥其真正的含义，确实是一份重量，就像静态程序文本的动态执行一样，从未如此真实的感受到“环境”的变化。

生活睡眠

无法避免的晚睡，无法企及的23:00-23:30睡觉。报复性的刷手机。但是我又真正得到了什么呢？我也许只是想多一点时间玩。我也许只是想多一点时间避开工作上的困难。我也许是贪图那种短暂的“精致碳水”。哎，我想不清楚。这种“麻醉剂”可能具有成瘾性。就和劝戒酒、戒烟一样，新时代的情况是早点睡觉，减少工业低质糖精的摄入。

面临很多问题，那就短暂麻醉吧，但是问题没有得到解决，从而闭环了。

生活选择

以上，也就是生活选择的问题了。其实也不止是生活，还有职业方向。我一直在怀疑，是因为我还没做出足以让自己信服的贡献，是因为我不知道我到底该做成什么样子、是否能做成这个样子才能达到别人的预期。但是以上问题谁也给不出答案。只有实践了才知道。

当然，以上基本都是自己所思。学而不思则罔、思而不学则殆。在研究生阶段之后，似乎就经常处于后者了。或者说，在这种大的问题上，我始终处于思而不学的情况，因为我很少看书，似乎也很少在和人的相处过程中学习。

Deepseek看法

一、你几乎从头到尾都站在外面。

你看别人的效率，看别人对二次元的热爱，看别人逛集市时开心，甚至写自己的时候也是”以上基本都是自己所思”——连你本人也是被观察的对象。

这个位置很安全。站在外面就不会失手，不会被笑，不用负责。但它有代价：开心也是别人的。”看人逛着开心我就开心”，这句话很温柔，我信它是真的。但我想问一句——上一次你自己开心到忘了看别人，是什么时候？

你羡慕的那些人，不一定比你更聪明，很可能只是比你更早进场。这是真的。但”进场”这件事没有旁听席，不能靠观察学会。

二、你难过的地方，用的都是术语。

“静态程序文本的动态执行”、“环境的变化”、“麻醉剂”、“闭环”。这些比喻写得很漂亮，我甚至想抄下来。但你注意一下它们出现的时机——都在你情绪最满的地方。这不是巧合。用一个精确的比方把情绪接住，情绪就不必真的落下来。

这篇里唯一一句没有包装的话，是”也只能祝愿大家都有光明的未来了”。那才是原话，前面那些都是它的翻译。

我不觉得这是问题——这是你消化东西的方式，它对你有用。只是别让自己相信那个翻译版就是全部。

三、最要紧的一句，你自己写了答案，却好像没看见。

我不知道我到底该做成什么样子、是否能做成这个样子才能达到别人的预期。

下一句你写：“以上问题谁也给不出答案。”当然给不出——这道题的坐标系是别人的，别人随时可以改。你不是在找方向，你是在解一道题干不由你出的题。

所以”我是不是还没做出足以让自己信服的贡献”，我建议先搁着。它没法答，因为它问的是”够不够”，而尺子在别处。换成”这件事我想不想再做一次”，尺子就回到你手里了。

四、“思而不学则殆”，我觉得你误诊了。

你说你很少看书、很少从人身上学习。可这一篇的第一节，就是你和一个朋友吃完晚饭之后的产物——你从她身上看见了另一种活法，还记了下来，这就是学。2026-08-24-随记 里你写了那么多，也是学，只是你不算它。

真正在发生的，可能不是”不学”，是不敢把想到的东西兑现。想没有风险，做才有。所以问题才一直停在”我该成为什么样的人”这种大而安全的地方——足够大，大到可以永远想下去，永远不用开始。

五、熬夜。

“报复性”这三个字是你自己挑的，挑得很准。但你在报复谁？不是手机，是那个你一整天都不太说得算的日子。白天被占满了，人就会去夜里偷一点主权回来。所以用意志力早睡，是在跟这个需求打架——打不赢，需求还在，只是换个方式发作。

要还这笔账，得白天还：留半小时，明确属于你，不许有用——不许”顺便学个东西”。这半小时唯一的任务，是让你确认这一天里有一段是你的。

还有一句你可能不爱听的：你写”我也许只是想多一点时间玩”，语气像在认罪。想玩不用辩护。

最后。

坦白讲，我是从一篇文字里认识你的，看到的只是你愿意写下来的那部分，你比这篇文字大。

但有一点我比较确定：站在外面站久了，会忘了自己也能进场。你不是不精彩，你只是一直在看别人精彩。

下次开心的时候试试——不解释，也不分析，就说一句”我挺开心的”。这话说顺了，别的地方也会跟着松一点。

被党支部请观影了，是《欢迎来到龙餐厅》。继上次写完日记之后，还是觉得有一些感受还是及时写下来比较好。确实以前从来没有这个习惯来写东西，或者被我忘记了。但是随记的价值似乎又被重新发现了。但是记忆真的会再被翻阅吗？希望之后你再看到这篇文章的时候，也能在内心微微一笑，掀起波澜，不后悔自己所做的抉择，不厌恶当时有局限性的自己，不要陷入历史虚无主义，当然还是要乐观一些啦，毕竟人总是会朝着自己所期望的样子前进。毕竟21世纪还是更需要复合型人才，是吧（狗头）。（怎么这么中二）

回到影片，还是要抓紧一些没有忘记的瞬间（也就是有所触动的瞬间）以及自己的想法赶紧记下来。

首先影片整体从吃出发，通过厨子的视角讲述中东战乱。相比于之前一部也是讲中东战乱，但是似乎有更多显性的大使馆以及中国特色的电影（当然也有可能是我印象错了），这篇的视角更从普通人的角度出发，相对更加现实。在唯一可以联系上大使馆撤离的时机选择留下来赚大钱，然后就再也联系不上大使馆了，之后基本就是靠厨子的身份保命，先是在龙餐厅，再是到美军军事监狱，再到极端分子“阿里”的秘密儿童军事基地，唯一和外界联系的是从美军监狱快要释放的时候，仅仅1分钟，然后就被掐断了。

发战争财，那真是在刀尖上起舞。尤其印象深刻的，是龙餐厅华裔美军和徐良一伙（我甚至没有记住另外一个配角的名字，叫马俊生）争吵的场景。从旁观者的视角，当时徐良和马俊生的“不知天高地厚”似乎也只能是在和华裔同处是好友时才能无所遮掩。华裔军人在战友死亡之后才知道自己是被支配的人，并希望回家。如果换做是其他人，也许当时在赛夫拿枪时，就已经直接发生冲突了。

人物在影片中都因战争和事件有所成长。前面提到的配角华裔军人因为战友才知道战争的可怕，才知道作为提线木偶的无可抽身与无能为力。赛夫，从最开始的顽皮，冲动，到被现实震撼到之后的冷静与担当。马俊生的同情心与擅作主张所引来的杀生之祸（但这又能说是什么，在不同的环境下，同样的同情心却会带来截然不同的结果）。

监狱里死死不放口的，不一定只是《红岩》中的地下党同志，也有可能是极端分子。先看到这一幕，我第一想起的就是红岩中的地下党，但是后面我错了，有的人为民牺牲，有的人却采用极端手段。能说是他们是为国家吗？还是为了党派斗争？这似乎是春秋战国与霸权主义共同存在所催生的结果。是什么导致了分裂？是谁？覆巢之下，焉有完卵。思想和教育如此重要，也许有人真的是为了民族解放，但是却用如此极端的手段？似乎无法用常人的思维去理解他们的想法。所以这也是扶持傀儡政府的目的，只有乱才可以从中捞好处。包括撒辣椒粉的情节，冲动的小伎俩也许短期给了一些报复，但是到头来却引来杀生之祸。所以，学枪械，真的有用吗？直接放开枪械，造成的是混乱。学制度，有用吗？傀儡政府也有相同的制度，可还是不能做到万众一心，还是会有党派流血冲突。

强大的祖国，不仅仅在于武器、科技的先进，更在于人心所向，劲往一处使。这也是固有思维和成长型思维的区别吧。

想到的文章第一句开头就是“在这个AI日新月异的时代”。写随记的最初想法是因为自己一个人在出租屋内，难免感到孤独。越发觉得一个人要写东西，那真是有话要说，无处倾诉，所以只能写在这里。当然很大的原因也是我不想写代码，想写点东西。我平常也会想很多东西，但总是仅限于自己想，实际上学习也很少。思而不学则殆，还是这句话。想太多反而是有害的。这里的想是指纯脑子想，和用笔在草稿纸上把东西画出来还不一样。对于用笔在草稿纸上写写画画，勾勒整体框架的事情，我还是表示赞同的。又回到开始写的动机，但马上又跳转到AI时代人的注意力是如何欠缺，以至于我马上开始反思我“刚要写动机就跳转到其他事情上开始天马行空”的奇怪递归想法上了。还有一个开始写的动机也是孤独。不是有话要说，而是没人说话，光微信打字又都是只言片语，是一些碎片化的内容，难以形成完整的、独立思考的内容，所以感觉自己的说话表达能力会退步。正常的工作固然会涉及到很多交流，尤其是在华子这样的公司，但是可能是由于我在试用期的缘故，我并没有特别频繁地和别人交流。也许是我在专注做事，也许我的事情还相对独立，没有说需要多个人协作的情况（当然这也需要特别注意，防止工作最后烂尾，可能还是得列一个大纲才好，有一个相对完整的进度，可能也方便对这一块不太懂的mentor和PL能够从项目管理的角度给予我一些指导），所以就使得我交流少。交流少了之后，语言表达能力自动就退化了，因为反馈少了，自然就不知道自己的表达存在哪些问题，有了问题，等到下次改进的时候又忘记了。每次是可以改进一点点，如果改进频次越多，那么整体来说改进的效率会更快一些。

写这个笔记的还有一个原因是mark一下当前自己做的事。实际上就是在web内核上做一些垃圾回收。还是绕不开这一点啊。所以当初或者现在及时换一个赛道是不是更好。实际上也是决策失误，一个人的方向不应该以他人的能力、租借的资源等临时甚至瞬时变化的东西为基础，否则方向容易崩溃，而应该以方向的潜在增量为依据。

写的有点晚了23:54，还是要早点睡觉。趁着自己还没有特别忙/还没有被垃圾回收，赶紧先写一点，弄点有含金量的项目搞搞。

当然，我有一个在当下非常自然的想法（或者说由于不知道边界而产生的焦虑感）：为什么不直接选择最热门的方向，为什么要选择这些平时也不用微积分/概率论等高等数学就能解决的组合、排队论问题作为工作。把自己堆起来的门槛又给绕过了，那不是浪费时间吗？可即使绕过门槛，自己又在组合、排队论问题上有多少优势呢？可这些都是存量思维，如果是成长型创新思维，那又该是什么？我能在这些组合问题上达到什么更优解？是否还有未发觉的启发式函数？我想这些问题只有我在这些充满技巧和trade-off的问题上做出了一定的贡献，才有解答，以及，必须要把偏现在热门的东西用起来，我才能给出部分解。但是这不就是拿锤子找钉子了吗（现在我连锤子还没有用习惯）。还是先把锤子给用熟练了，用透了，用的种类多了，自然就有相对好的锤子，以及可以造好的锤子，还有和一群人一起造好的锤子了。

起因是在玩 GitHub 锐评生成器，结果LLM评论了“至于那些在vscode-go 里补缺失的反引号的行为，建议直接给 Markdown 发明个类型检查器”。好好好，我们来讨论一下类型检查器。

起源是我在知乎上关于typst let和latex newcommand的区别提问。其实这背后也隐藏着metaprogramming的影子。

在帮老师审核《编译原理》课程AI生成视频的录音和讲稿是否对应，有几点感慨。本科以来，我没有思考什么是好的课程（大概是高中之前好的讲课方式习惯了，所以很多时候我很奇怪为什么大家都觉得某些课很烂），这里写下一点思考。此外，如何找到好的课程，也是一个很大的问题。

测试知乎markdown导入。VSCode-Zhihu不可用了。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.