Huzzah: 一种用于 AI 辅助编程的声明式伪代码方法

Huzzah 为 AI 编程引入了一种声明式范式

Huzzah 是一个实验性编辑器，旨在将 AI 辅助软件开发从长篇、命令式的聊天提示词转向持久、声明式的伪代码模型。开发者不再通过一系列瞬时的聊天消息来描述代码库的更改，而是使用伪代码在 .hz 文件中编写其意图，然后编辑器会利用这些内容自动生成并更新相应的源代码。

这种方法解决了当前 AI 编程智能体工作流中的三个主要摩擦点：

人类意图的丢失：在传统的智能体工作流中，提示词往往会被丢弃，导致无法留下关于为何进行特定更改的可靠记录。
命令式效率低下：基于聊天的指令描述的是更改（例如，“将循环改为接收一个输入”），而不是应用程序的期望状态，这导致了重复的指令和 Token 的浪费。
散文疲劳：为每一个技术更改编写详细的自然语言描述既繁琐又往往包含更多社交辞令而非实际的信息内容。

Huzzah 工作流：伪代码即源码

在 Huzzah 范式中，提示词不再是瞬时消息，而是一个持久的文件。工作流从对话转向了设计过程：

声明式定义：开发者创建一个 .hz file 并编写逻辑的伪代码表示。例如，不再是要求 AI “创建一个循环 100 次并打印 fizz/buzz 的函数”，开发者会编写一段简洁、结构化的伪代码块来定义逻辑。
自动生成：保存 .hz 文件后，Huzzah 会生成实际的可执行代码。
持久化迭代：若要修改行为，开发者只需更新伪代码文件。Huzzah 会捕获伪代码的 diff，并将其作为提示词来重新生成受影响的源代码。

这种方法允许伪代码既作为提示词接口，又作为永久的开发者文档，因为它以一种可读的、与语言无关的格式明确表达了人类的意图。

技术权衡与局限性

虽然 Huzzah 提供了一种更简洁的表达意图的方式，但也引入了几个技术挑战：

可扩展性：这种方法在大型、复杂代码库上的有效性尚未得到证实。
依赖管理：在伪代码中表达跨文件的依赖关系以及复杂的导入/导出比在标准编程语言中更困难。
工具链缺口：标准的语言服务器协议 (LSP) 功能（如自动补全和跳转到定义）在伪代码中无法原生使用，尽管作者指出它们有可能被生成。
领域专业知识：该方法要求用户具备足够的领域专业知识来编写结构化的伪代码；缺乏此类专业知识的用户可能会发现自然语言散文更容易。

社区观点与批评

软件工程师之间的讨论凸显了在“将 Huzzah 视为抽象化的必要演进”与“将其视为对现有实践的重新发明”之间的分歧。

支持该方法的论点

一些开发者认为一种“机器-人类混合语”正在出现——一种介于正式代码和模糊散文之间的中间地带。支持者认为，将意图持久化为一种持久的产物，使得 AI 编写的代码库更容易审计和维护。

"I’d feel much more confident to use a vibe-coded library where I can read the human-written intentions than one where I just see a lot of AI-written code."

反对该方法的论点

批评者认为 Huzzah 可能是在重新发明现有的软件工程学科。一些人指出，行为驱动开发 (BDD) 和 Gherkin 语法 是定义声明式行为的成熟方式，且这些行为也可以通过测试来执行。

其他批评者认为，这种方法本质上是一种“现在编译起来需要花钱的简洁语言”，因为它依赖于随机性的 LLM 来执行转译。此外，人们也担心这会进一步使程序员脱离解决硬逻辑错误所需的批判性思维。

"The problem is not writing English, it’s the rate of change... you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly."

其他建议

几位贡献者建议，与其使用伪代码来生成新代码，不如采用相反的方向——将庞大的现有代码库分解为简短的伪代码摘要——这对于管理遗留系统会更有价值。