2026年8月，作者对AI编程助手感到疲劳，厌倦用长文本描述代码变更，但也不想回到手动编码。他提出两个问题：AI聊天记录丢失了人类意图，且指令描述的是变更而非应用本身。

好的，这是根据您的要求，对原文进行的中文重述：

标题：Huzzah：一种与AI协作编程的新实验性方法

核心观点：

一位软件工程师在2026年经历了AI编程助手带来的初期兴奋后，陷入了疲惫。他厌倦了用冗长的自然语言向AI描述代码变更，但也不想回到完全手动编写代码的繁琐状态。他渴望对代码有更好的理解和控制，以确保输出高质量、可靠的软件。为此，他正在开发一个名为“Huzzah”的实验性编辑器，旨在解决当前AI编程模式（如编码代理）的三大问题：

1. 缺乏人类意图的可靠记录：提示词（prompts）通常被丢弃，代码是否由AI生成也无从追溯，失去了表达人类对机器期望的核心权威。
2. 指令效率低下：AI聊天中的指令是描述“变更”的步骤式命令，而非描述应用本身，导致指令在开发过程中被重复，消耗大量token。
3. 自然语言信息密度低：大部分自然语言用于社交而非传递信息，平均句子包含的真实信息很少，用这种方式与机器交流很繁琐。

Huzzah的解决方案：

Huzzah提出了一种替代范式。与编码代理使用“长格式、命令式、临时性”的提示词不同，Huzzah的提示词是“伪代码、声明式、持久化”的。

• 工作流程：用户创建一个.hz文件，在其中以伪代码形式描述程序逻辑。保存文件后，Huzzah会自动生成真实的代码。如需修改，只需更新伪代码文件，Huzzah会捕捉差异（diff）并将其作为提示词发送给大语言模型（LLM），从而重新生成受影响的源代码。

示例对比（以Fizz Buzz为例）：

• 编码代理方式：用户需要在聊天框中输入一段长文本描述（如“创建一个循环100次的函数，如果数字能被3整除，打印‘fizz’...”），修改时再发送另一段文本。
• Huzzah方式：用户直接在.hz文件中编写简洁的伪代码（如“loop 100 times; if divisible by 3: print fizz; ...”），保存即生成代码。修改时直接编辑伪代码文件。

其他优势：

• 编写伪代码更像是在设计代码结构，能更积极地调动思维。
• 可以自由控制伪代码的详细程度。
• 伪代码本身成为开发者文档，清晰表达了人类意图。
• 可以编写语言无关的伪代码，作为生成多种语言或环境代码的基础（例如复杂的CRDT算法）。

局限性：

• 在大型项目中可能存在扩展性问题。
• 更适合新项目而非现有代码库。
• 对于缺乏领域知识的用户，自然语言可能更易用。
• 某些跨文件依赖等复杂关系可能难以可靠表达。
• 无法直接获得LSP（语言服务器协议）等IDE特性（但理论上可以生成）。

当前状态：

Huzzah目前处于积极的实验性开发阶段，其源代码和设置说明已在GitHub上公开。

根据评论内容，总结如下：

主要观点与论据：

1. 伪代码作为持久化意图记录有价值，但非全新概念

   • 评论8（评分None）：“I think the idea of having a human-written persistent document describing the operation of the code is a great idea.”
   • 评论15（评分None）：“Every engineer I have ever mentored got a lesson on how to write a good commit message that included this. This is exactly that.”
   • 评论17（评分None）：“I think 'the pseudocode is persisted alongside the generated code' just reinvented jira/linear tickets and PR descriptions.”

2. 伪代码与编译器/规范驱动开发的相似性

   • 评论9（评分None）：“This is basically a compiler, but we’re moving up a layer of abstraction.”
   • 评论13（评分None）：“Isn't this just spec-driven development in a different language?”
   • 评论21（评分None）：“If the pseudocode is precise, what you want is a compiler. Otherwise the LLM is still making decisions for you.”

3. 对抽象层次与开发体验的讨论

   • 评论2（评分None）：“The challenge I see more broadly is we (as engineers now empowered by LLMs) are trying to find the right level of abstraction to operate in.”
   • 评论18（评分None）：“I think the reverse direction is more important: taking a massive complex problem/codebase and decomposing it to short pseudocode.”
   • 评论26（评分None）：“The problem is not writing English, it’s the rate of change. Programming is meditative... Agent-based development… there is no thinking, no meditation.”

4. 实用性与局限性

   • 评论4（评分None）：“Writing fizzbuzz requires that you understand algo + you credit card, while agent requires only your credit card.”
   • 评论7（评分None）：“What about multi-file / larger changes? How would you express files being connected, imports, and exports?”
   • 评论22（评分None）：“It's possible to be vague when you want to and specific when you need to. I'm not sure if that itself would work well in practice.”

5. 对创新性的质疑

   • 评论5（评分None）：“You seem to be conflating two things: how to prompt, and how to share sessions. You can already use pseudo-code today if you want to.”
   • 评论23（评分None）：“Invented New coding language that transpile to other coding languages and saying it novel approach.”
   • 评论11（评分None）：“I'm confused, it looks like you've just written a new terse language that now costs money to compile?”

平衡性总结：
评论整体认可“持久化意图记录”的价值，但多数认为该方案并非全新，而是对现有实践（如规范驱动开发、编译器、文档注释）的重新包装。部分评论关注抽象层次与开发体验的权衡，指出伪代码可能过于接近底层实现，而真正的挑战在于处理大规模代码库和变化速率。也有评论质疑其实际效用，认为直接使用现有工具（如系统提示、git notes）即可实现类似效果。