只写伪代码,保存时同步成真源码

上周我改自己视频 pipeline 里的一个小逻辑：重试次数从 3 提到 5，而且只对超时生效。

在对话框里，我打了三行完整的中文才把这件事说清楚。写完盯着屏幕愣了两秒——这段话的长度，是我自己动手改那行代码的好几倍。

累的不是 agent 不行，是每一个改动都得先翻译成一段人类完整句子。⚡

01有人把这层"翻译"直接换成了代码

8 月 20 日，一个实验性编辑器 Huzzah 出现在 Hacker News（帖子 49378768，379 points、209 条评论）。据作者自述：今年 1 月起他几乎只用 coding agent 写码，几个月下来精疲力尽。

他还给了个判断——代码库过了某个复杂度，agent 就开始把自己绕晕。这是他的观察，没有基准也没有数字。

做法是：你按自己顺手的方式写伪代码，保存时编辑器同步成真源码；伪代码不删，跟生成的代码一起存着，等于把 prompt 变成一份"意图记录"。编辑器还建 source map，伪代码的每一行能追到它生成的那几行真码。

据作者自述，这东西目前只是 proof of concept，就是个网页应用，落到文件系统、变成桌面程序都还只是方向。

第一条，spec-driven development。他试过，结论是不行 🧩。规格是一堵墙的文字没人愿意读，更要命的是它和代码很快脱节，工程师索性让 LLM 去更新规格——现在规格既是长篇大论、又是机器写的，谁也不知道还反不反映真实意图。

第二条，双向：从代码反向抽规格、生成摘要。他说这方向眼下项目一堆，他在自己上班的公司也试过几种想法，没有一次跑通。他的判断是，最后你总得有个人手写出来的东西。

第三条，做 IDE 插件。放弃。理由很实在：语法高亮本身就极难（据作者自述，能跑起来他自己都意外），再加 source map，插件里也许能做，但眼下自己控整个环境省事得多。他说不排斥这条路。

三个方案形状一样：在人和代码之间加一层中间物。差别只在这层东西由谁维护、维护的钱谁出。

规格交给 LLM 维护，成本最低，代价是漂移不可见——你不知道它哪天悄悄改了口径。

反向抽取看着最省人力，验证成本却比写还高：你得读完抽出来的东西，才敢确认它没抽错。

伪代码由人手写，写的成本没省，省的是验证——source map 把"读一整篇规格"降成了"逐行点过去对"。

我的公众号自动化里也有这么一层中间物：一堆 prompt 模板加规则文件。有一阵我图省事，让模型自己去更新规则文件。

一个月后翻开，我已经分不清哪条规则是我定的、哪条是它自己加的。后来改回死规矩：规则只许手写，模型只有读的权限。这跟他那句"总得有人手写的东西"撞上了。

往内行一点说，这其实是可溯源问题。做检索增强那类系统，评估好不好用，一半功夫花在"这句话到底是哪来的"。source map 做的是同一件事，只是对象从文档换成了代码行。✍️

对一个人干活的开发者来说，取舍就在这儿：你愿意为"还看得懂自己的系统"付多少钱。全交给 agent 最快，代价是几个月后读不动自己的代码库；留一层人手写的东西慢一点，但系统还是你的。

我是 James。原帖在 Hacker News 49378768，作者 @danielvaughn。这个编辑器我不急着装，但他走完三条死路留下的那句结论，我抄进了自己的规则文件。

◆ ◇ ◆

AI 西海岸来信 · 周五见