一个叫Daniel Vaughn的开发者最近在Hacker News上发了个帖子，介绍他做的实验性代码编辑器Huzzah。核心想法很简单：不用聊天窗口给AI下命令，改成写一份持久化的伪代码，保存文件时系统自动捕获改动的diff当prompt，重新生成对应的真实代码。这不是又一个“更好用的Copilot”，而是想换掉AI编程里最基础的一个假设——人类的意图到底应该以什么形式存在。
这个假设值得较真，因为2026年上半年编码智能体已经强到让不少工程师放下了手写代码，但很快撞上了同一堵墙：自然语言prompt说完就丢，代码里留不下人类到底想要什么的痕迹；每次改动都要用长句重新解释一遍上下文，费token又啰嗦。Huzzah的野心是把伪代码变成程序的第一等公民，而不是一次性用完就扔的提示词。
fizz buzz 之外，真正的架构是什么
Vaughn在原文里只演示了一个fizz buzz例子：写一段伪代码，保存后自动生成代码，改伪代码，diff被当成新prompt去重新生成。这个演示很讨巧，但它没讲清楚一件事——伪代码和生成代码之间，谁听谁的。
翻查项目仓库的PLAN.md会发现，Huzzah的真实设计是一套双文档模型：开发者写的Intent（伪代码意图）和智能体生成的Source（真实代码）分开存在，两者靠一条commit→reconcile（协调）→review→accept/reject的流程保持同步。换句话说，改了伪代码不是直接覆盖代码，而是先生成一个diff，人工审查通过才会真正合入。
这套流程比fizz buzz演示复杂得多，也更诚实——它承认AI生成的代码不能被无条件信任，需要一道人工闸门。项目本身是个跑在本地的SvelteKit应用，要求Node.js 22.19以上，模型接入走Pi支持的provider，目前完全是实验期的玩具，没有发行版。
声明式意图和缺失的沙箱，是同一枚硬币的两面
Huzzah的卖点是“伪代码更省心”，但它自己的文档里藏着一个原文完全没提的风险点：生成出来的JavaScript代码跑在Web Worker里，仓库文档明确写着这只是“实验性隔离”，不是真正能挡住恶意代码的沙箱。
这就有点拧巴。一边让开发者把意图写成伪代码、交给LLM去自动重生代码，强调的是“信任声明式意图”；另一边运行环境却连基本的安全边界都没搭起来。对愿意在玩具项目上试一试的人无所谓，但凡想往真实代码库里塞，这道题目前躲不开。
- 风险.Web Worker隔离不是沙箱，自动重生代码在真实项目里跑，安全边界目前是空的。
伪代码打不过的三件事，恰好是整条赛道的老大难
Vaughn自己在文中列了一串caveats：新代码库比老代码库更适合、缺乏领域经验时自然语言反而更好用、跨文件依赖难以在伪代码里可靠表达、LSP类的跳转定义和类型提示暂时没有、大规模场景是否可行完全没验证过。
这些不是谦虚的场面话，而是把这条路线的天花板指了出来。把它们排开看会发现一个规律：真正难的从来不是“怎么把意图写得更短”，而是“怎么让机器记住并复用跨越多个文件、多次改动的上下文”。这恰恰是AGENTS.md一类项目级说明文件、事件溯源式记忆层、多智能体编排各自在啃的同一块骨头，只是切入点不同——Huzzah选择的是可执行伪代码，别的方案选择的是自然语言说明或决策日志。
谁都在给AI编程加一层持久记忆，谁也没真正解决"记住之后怎么复用"
这里要提醒一句：网上有另一位同样研究Codex CLI和AGENTS.md方法论的作者，名字拼写是Daniel Vaughan（多了个a），和写Huzzah的Daniel Vaughn并非同一人，两套方案分属不同网站、不同仓库。检索时很容易把二者的方法论嫁接到一起，报道和转述都得留神这个同名陷阱。
接下来该看什么
- 结论.Huzzah值不值得关注，不取决于fizz buzz演示多讨巧，取决于reconcile阶段能不能扛住真实代码库的跨文件依赖。
Show HN发出后目前还没检索到被索引的评论区讨论，社区到底认不认这套范式，暂时没有一手证据。真正能验证这件事的，是GitHub上的star、fork和issue走势，以及有没有人真的把它塞进一个非玩具项目试跑——在那之前，它更像一份写得挺清楚的架构提案，而不是一个已经跑通的答案。