摘要:当编码 Agent 让"写长文描述变更"成为日常,开发者 Daniel Vaughn 选择反叛:他构建的实验性编辑器 Huzzah 把提示词从"聊天对话"变成"持久化的伪代码文件",让人类意图可记录、可审计、可复现。本文拆解 Huzzah 的三条核心批评与实现机制,并把它放进"无 Vibes 编程 → Naeos 工程化 → 意图本位"的思潮脉络中,给出在现有工具下保留意图记录的具体建议。
从蜜月期到疲惫期
2026 年初,编码 Agent 突然好用到让人不再需要手写每一行代码。但 Daniel Vaughn 在博客里说,蜜月期总会结束,新鲜感消退后,他在 8 月感到"彻底疲惫"。他厌倦了用长篇英文描述每一个想要的改动,又不想退回纯手工编码的枯燥日子,更关键的是——他意识到自己需要重新获得对代码的洞察与控制,需要确认产出是高质量、可靠的软件,需要"作为专业人士对自己感到满意"。
这种情绪在 2026 年夏天的开发者社区里并不罕见:当"描述一下你想改什么"取代了"亲手写出解决方案",很多人开始隐隐不安。Vaughn 的选择不是戒断 AI,而是重新设计人机对话的形态。这个矛盾催生了 Huzzah:一个正在开发中的实验性编辑器,一种"用 AI 编码的新方式"。8 月 20 日晚它以 Show HN 形式登上 Hacker News 首页,截至本文核查时(8 月 21 日)获得 345 分、197 条评论,成为当日编码工具圈最受关注的观点输出之一。
痛点清单:对现行 Agent 模式的三条批评
Vaughn 对聊天式编码 Agent 的不满可以归结为三点,每一点都指向同一个问题:意图。
第一,没有可靠的人类意图记录。提示词被丢弃,代码可能是 AI 生成的,也可能不是——“我们失去了表达人类想要什么的中心权威”。当三个月后回看一段代码,你无法回答"这段代码当初为什么存在、它被要求做什么"。意图与实现之间的链条,在聊天界面里是断裂的。
第二,聊天是"描述变更",不是"描述应用"。AI 对话是命令式的、逐步的指令,描述的是"把循环改成 100 次""把函数改为接收参数"这类增量操作,而不是应用本身。同一意图会在整个开发周期里被反复用不同措辞表述,重复消耗 token——在 Vaughn 看来这是低效的。
第三,自然语言的信息密度太低。大量人类语言存在的目的是社交而非传递信息,平均一句话携带的真实信息量很低。用这种语言对机器说话,是笨重的。
于是他把两种范式的差异概括成三组对立:编码 Agent 的提示词是长文、命令式、一次性的;Huzzah 的提示词是伪代码、声明式、持久化的。
实验性方案:把提示词变成文件
Huzzah 的核心机制极其直白:你新建一个.hz文件,用伪代码写下你想要的程序,保存,Huzzah 自动生成真实代码。要修改?直接改文件,再保存——Huzzah 捕获这次编辑的 diff,把 diff 作为给 LLM 的提示词,重新生成受影响的源码。
对比一下 FizzBuzz 的两种写法。聊天式 Agent 的提示词是:
创建一个循环 100 次的函数。数字能被 3 整除就打印 "fizz", 能被 5 整除就打印 "buzz",能被两者整除(比如 15)就打印 "fizz buzz"。Huzzah 的fizz_buzz.hz则是:
fizz_buzz(n) loop n modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz"要改成接收参数n,聊天式要追加一条新消息;Huzzah 只需把loop 100改成loop n并保存,fizz_buzz()改为fizz_buzz(n)。作者还给了购物车、Todo 列表等例子,伪代码风格自由,可以极简也可以详细。
Vaughn 认为这套做法的收益不止于省 token。写伪代码像在设计代码的形状,比打字聊天更调动思考——你被迫先想清楚"这个程序由哪些操作构成",而不是让 AI 替你做架构决策;伪代码由人类写成,天然充当开发者文档,新人看.hz文件就能理解模块的意图;语言无关的伪代码还能作为多语言、多环境目标的共同底座——作者设想,像 CRDT 这样的复杂算法,可以先用一份伪代码表达,再针对不同语言环境分别生成实现。
技术上,Huzzah 基于 Node.js(要求 22.19 及以上),模型接入复用开源框架 Pi(earendil-works/pi)的 provider 配置,支持 Anthropic、OpenAI、Google、本地 Ollama 等;npm run dev后运行在http://localhost:5173。仓库 README 有一段重要的安全提示:规格与生成的源码会发送给所选模型厂商,被接受的 AI 生成的 JavaScript 会在本地 Web Worker 中运行——“这是实验性的隔离,不是恶意代码沙箱”。GitHub 实测该仓库(2026-08-21)108 星、3 fork,语言 Svelte,尚无 license,处于明确的实验阶段。
作者自己也列了 caveats:规模化的可行性未知;更适合新代码库而非既有大型代码库;缺乏领域知识时自然语言可能更容易;跨文件依赖难以可靠表达;LSP 类特性暂时缺失(但可能被生成)。
思潮对照:从"无 Vibes"到 Naeos 再到 Huzzah
Huzzah 不是孤立事件,它是 8 月编码 Agent 反思潮流的第三个坐标点。
第一站是"玄学批判"。8 月 16 日,学者 Peter Bloem 发表《AI coding without the vibes》,把当前主流用法称为 vibe coding——AI 写、人查,并断言"人脑根本做不到逐行审查 AI 产出",这种分工是不可持续的虚构。他主张 craft coding:人写代码,AI 当 reviewer 来查,即"doing 与 checking"两阶段由人机各负责一个。Bloem 用三个面包师做类比:Hanna 是纯手工手写派,Vivian 是只看销量不看工艺的 vibe 派,Cara 是既用机器又懂工艺的 craft 派。
第二站是"工程化"。8 月 20 日,开源项目 Naeos(NAEOS-foundation/naeos,Go 实现、Apache-2.0 许可)登上 HN,自我定位是"面向 AI 编码 Agent 的工程系统",试图为 Agent 的开发与运行提供工程化支撑——把 Agent 从单点工具变成可管理的平台。
第三站就是 Huzzah:意图本位。前两者分别回答"AI 该怎么用"与"Agent 该怎么建",Huzzah 则回到更上游的问题:"人类想要的到底是什么,如何把它记录下来?"它把答案从对话流里抽出来,固化成文件——提示词从此有生命周期,可以 diff、可以 review、可以成为文档。
HN 评论区对这种"伪代码即提示词"的看法两极。认同者认为它找到了正确的抽象层级(smicallef:“我们作为被 LLM 赋能的工程师,正在寻找合适的抽象层级来操作”),或呼应了半形式化规范语言的方向(apex_sloth 提到 Quint),“简洁伪代码 > 冗长散文”(florians)。质疑者更尖锐:esafak 指出伪代码本身不算创新,真正值得做的是会话管理;leobg 反问"为什么不直接在现有 harness 的系统提示词里加一句’给我伪代码我就展开实现’“;iloveoof 一针见血——“这基本是个编译器,只是抽象层上移了一层”;jxf 认为这是"换了个语言的 spec-driven development”;madrox 则调侃它"重新发明了 Jira/Linear ticket 和 PR 描述";quasarj 吐槽"你只是写了一个新的简洁语言,现在还要花钱编译";r0ze-at-hn 认为这本质是在重新发明"写好 commit message"和"写代码文档";user43928 干脆叫它"Micropilot——微管理";avaer 提出更激进的反向方向:与其从伪代码生成代码,不如把复杂代码库自动分解成可编辑的伪代码,再整体编译回去。还有评论者点出门槛问题:paretolaw 说写 FizzBuzz 的伪代码"需要你理解算法加一张信用卡",而 Agent 只需要信用卡——多数人会选后者。
实践建议:今天就能做的意图记录
即使不跟进 Huzzah 这类实验性工具,它的批评也给出了可立即执行的检查清单:
- 把"为什么"写进 commit 与 PR。聊天记录会丢,git 历史不会。commit message 和 PR 描述是现成的意图层,值得像写代码一样认真——这也是 Huzzah 质疑者 r0ze-at-hn 的提醒:好团队早就这么干了。
- 用文档文件承载规格。把关键模块的意图写成 spec 或
AGENTS.md/CLAUDE.md这类 Agent 可读的文档——8 月 20 日已有 Claude Code 支持 AGENTS.md 诉求的讨论,8 月 21 日 GitHub 官方又发布了 spec-kit 工具包推动 Spec-Driven Development,规格驱动正在被工具链正式接纳,不再只是个人习惯。 - 导出并归档关键会话。对重要决策,把 Agent 会话导出存档,与对应 commit 关联,别让意图只存在于聊天窗口里。
- 在现有工作流里"借"Huzzah 的思路:即使不用它的编辑器,你也可以对复杂模块先写一段伪代码注释再让 Agent 实现,把"意图草稿"留在源码里——低成本获得同样的可审计性。
- 什么时候值得试 Huzzah:新代码库、单人/小团队、领域专家、对可审计性有硬需求。它目前是 108 星的实验项目,README 也警告不要把 secrets 或私有源码贴进去——尝鲜可以,生产环境请等它长大。
总结
Huzzah 未必会成为主流编码范式,它的质疑者已经指出了不少硬伤:伪代码不新鲜、编译器隐喻、与既有 spec 工具重叠。但它的价值在于把"意图的可记录性"重新摆上桌面:当聊天式 Agent 把提示词当一次性消费品,一代开发者的工程判断力正在被悄悄稀释。从"无 Vibes"到 Naeos 再到 Huzzah,编码 Agent 的演进正在从"怎么用、怎么建"走向"意图从哪来、如何被尊重"。实验性的反叛未必赢,但它把问题定义清楚了——"意图层"很可能成为编码工具下一个真正的竞争点,这个方向的每一步,都值得所有重度使用编码 Agent 的人关注。
参考链接
- Huzzah 原文:https://www.danielvaughn.dev/posts/huzzah/
- Huzzah 源码:https://github.com/danielvaughn/hz
- HN 讨论帖:https://news.ycombinator.com/item?id=49378768
- AI coding without the vibes(Peter Bloem):https://peterbloem.nl/blog/craft-coding
- Naeos:https://github.com/NAEOS-foundation/naeos
- GitHub spec-kit:https://github.com/github/spec-kit
- Pi(模型接入框架):https://github.com/earendil-works/pi
弱网加速方案：实测首屏提速40%，彻底终结移动端接口超时与频繁断连)
