Hacker News 中文摘要

RSS订阅

与AI协作：一个具体实例 -- Working With AI: A concrete example

原文链接 | HN讨论 | 2026-06-30 11:42:48

文章摘要

作者对AI持矛盾态度，既承认其开发价值，也担忧智力钝化等风险。文章通过维护hyperscript解析器的具体案例，展示了AI的优缺点，并警示开发者若过度依赖AI可能陷入“魔法学徒困境”——无法理解并解决系统问题。

文章总结

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了关键细节，并删减了与核心主题关联不大的内容。

标题：htmx ~ 与AI协作：一个具体实例

作者Carson Gross对AI持矛盾态度。他认为AI是强大的开发工具，但也存在智力钝化、环境问题等风险。他曾在文章中警告过“魔法师的学徒”问题：开发者过度依赖AI，最终无法理解并解决自己系统里出现的问题。

本文通过作者在维护hyperscript项目时与AI的一次具体互动，展示了AI的优缺点，并特别说明了他是如何险些陷入“魔法师的学徒”困境的。

背景：hyperscript解析器

hyperscript是一种用于Web的替代性解释型脚本语言，完全用JavaScript编写。它的解析器设计很特别，作者故意打破了许多解析规则，例如将解析逻辑与解析元素放在一起、解析器可插拔且语法动态定义等。这种非常规方法在这个项目中效果不错。

Bug报告

用户报告了一个回归问题：在0.9.91版本中，表达式 fetch \{% url 'trade:getsymboldata' %}?symbol=${symbol}` as JSON无法正确解析。问题在于as JSON绑定得太紧，在传递给fetch` 之前就试图将字符串转换为JSON，而不是像预期那样先获取URL再将结果作为JSON处理。这是解析中典型的绑定冲突问题，在类似英语的xTalk语言中尤为突出。

调查原因

作者使用Claude（AI助手）来调查原因。Claude表现不错，很快找到了根源：在0.9.91版本中，作者重构了 go 和 fetch 命令，提取了一个公共方法 parseURLOrExpression()。但这一改动意外地让 fetch 命令后的语法包含了通用的“表达式”，而 as 关键字在表达式中是类型转换的意思（如 set x to "42" as Int），但它同时也是 fetch 命令的修饰符（如 fetch https://hyperscript.org as Text）。问题核心是，重构后解析器将 fetch 后的内容解析为表达式，导致 as 被表达式消耗掉，而不再是 fetch 的修饰符。在Claude的帮助下，作者几分钟就找到了原因。

修复问题

在寻找原因方面AI很有用，但在提出修复方案方面则弱得多。

  • 方案一：一个hack。AI建议先解析“类字符串”叶子，失败后再回退到完整表达式。作者认为这个方案太针对特定bug，不够通用（例如无法处理 fetch $url as JSON 的情况），因此拒绝了。

  • 方案二：更好但增加了不必要的复杂性。AI建议在解析器上添加一个 noConversions 标志，让 AsExpression 在解析URL时失效。作者意识到hyperscript解析器已经是上下文相关的，并且已经有了一个叫“follows”的机制，可以更优雅地实现这个目的，但AI没有发现这一点。

  • 方案三：接近但不够完美。作者向Claude指出了“follows”机制，Claude随即使用该技术修复了bug，在 parseURLOrExpression() 中正确地推入和弹出 as 作为follow token，解决了通用问题。

  • 最终方案：半人工修复。作者在审查时发现，方案三过于宽泛，因为 go 和 fetch 共享了 parseURLOrExpression() 方法，但只有 fetch 使用 as 作为修饰符。这个修复也阻止了 go 命令中合法使用 as 进行类型转换。因此，作者自己动手，将特殊处理范围缩小到 FetchCommand#parse() 方法中，只影响 fetch 命令，不影响 go。

测试

作者让Claude为各种情况生成了测试。Claude在这方面做得很好，创建了能清晰展示问题和验证修复的小型、聚焦的测试。

故事的寓意

这个普通的bug修复过程展示了AI的强项（调查问题、创建测试）和弱项（提出干净的解决方案）。如果作者不熟悉hyperscript解析器的架构，AI提出的方案很容易导致技术债务的累积。

这个故事表明，一个了解底层基础设施的人类与AI协作，比让AI单干能更有效地控制复杂性。作者没有像“魔法师的学徒”那样盲目接受AI的方案，而是像一个“魔法师”一样，要求一个更符合现有代码架构的正确解决方案。他理解问题，看到了正确的解法，并与AI合作实现它，最后用AI生成的测试来验证。

关于AI与年长开发者

作者作为一位50岁的开发者，认为AI直接解决了他两个相对弱点：记忆力和长时间工作的能力。AI帮助他快速理解事物，并能不知疲倦地生成更全面的测试。但他也担心，过度依赖AI可能会加速他整体智力的自然衰退，并对自己在这次经历中过于依赖Claude感到有些惭愧。

结论

作者记录这次互动，是为了捕捉AI辅助编程的优缺点。它展示了让一个称职的开发者与AI协作的价值，也揭示了盲目接受AI提出的第一或第二个解决方案的危险。希望这对读者形成自己的AI使用策略有所帮助。

评论总结

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

主要观点与论据：

  1. AI的优势与局限（评分：无）

    • 作者（recursivedoubts）认为AI在修复简单bug时表现良好，但存在不足。评论3（thorum）指出AI虽擅长生成测试，但若提前设计更全面的测试，可避免弱解决方案。评论6（jdlshore）强调AI擅长分析和模板化工作，但缺乏批判性思维和全局设计能力，这可能是LLM的固有局限。
    • 关键引用：评论3 "Creating tests is highlighted as something Claude did well, but it strikes me that all the weaker rejected solutions could have been avoided if it were really good at designing intelligent tests for itself."；评论6 "AI is good at analysis and boilerplate, but not good at the kind of critical thinking necessary for good designs."

  2. 对AI批评的反思（评分：无）

    • 评论7（smokefoot）认为许多对AI的批评同样适用于人类开发者，AI能更快、更便宜地完成“模仿式”编码，并强调自动化测试的重要性。
    • 关键引用：评论7 "Many developer criticism of AI coders could be easily directed at 95%+ of human developers. Much coding is monkey see, monkey do..."

  3. AI对智力影响的争议（评分：无）

    • 评论4（waffletower）反驳“AI导致智力迟钝”的观点，认为大脑具有可塑性，AI使用模式类似“用进废退”，而非永久性损害。
    • 关键引用：评论4 "I disagree with the trope -- (AI effects) 'the slow dulling of our intellects'... the brain is plastic."

  4. 对文章细节的质疑（评分：无）

    • 评论8（wiremine）批评文章未说明使用的Claude模型、工具和提示方法，认为缺乏细节影响分析价值。
    • 关键引用：评论8 "It's a good write up, but it's lacking some details, the most important one is: which Claude model was used?"

  5. 其他观点（评分：无）

    • 评论2（varun_ch）指出htmx新网站设计风格与作者（grugbrain.dev）倡导的简洁理念相悖，使用Tailwind CSS和Astro构建。评论5（nsonha）讽刺AI使htmx的“无需思考”理念变得多余。

平衡性总结： - 支持AI的观点：AI在分析、测试生成和快速编码方面有效，且批评AI的缺陷也常见于人类开发者。 - 反对/谨慎的观点：AI缺乏全局设计能力，可能导致技术债务；文章细节不足影响结论可靠性；AI可能削弱人类独立思考。