卡森·格罗斯 2026年6月29日 我通常对人工智能持中立态度。毫无疑问，过去一年里它已成为开发过程中的一项强大工具，但它也带来了许多危险，这不仅对我们个人（例如，逐渐削弱我们的智力）而且对我们整体（例如，环境问题、个人计算成本日益高昂等）都是如此。在《代码更便宜》中，我警告了“魔法师的学徒”问题，在这个问题中，开发者依赖于人工智能，以至于无法理解和正确解决他们所构建系统中出现的问题。本文中，我想通过与人工智能的具体互动来展示人工智能的一般优缺点，并特别阐述我所避免的“魔法师的学徒”问题。 超脚本解析器 作为背景信息，超脚本是一种针对网页的替代解释性脚本语言。具有讽刺意味的是，它完全用JavaScript编写。它是一种奇怪的软件：我在编写时故意打破了许多解析规则，以实验结果会如何。有些例子：解析逻辑与解析元素放置在一起，解析器是可插拔的，语法是动态定义的，支持多种属性访问语法。这并不是我会推荐给大多数编程语言的做法，但对于这个项目来说效果还不错。再一次证明，软件开发确实有多种解决方案。 一个错误报告 我们的故事开始于一个用户报告了在升级到0.9.91版本时出现的回归问题。以下表达式不再正确解析：fetch `{% url ' trade :get_symbol_data' %}?symbol=${symbol}` 尤其是，as JSON的绑定过于紧密，试图在将其传递给fetch之前将字符串文字转换为JSON，而不是按照用户的期望（以及之前的表现）获取给定的URL，并将结果视为JSON。这种绑定冲突是解析中的经典问题。由于超脚本是一种xTalk风格的语言，并且继承了英语的许多模糊性，因此这个问题变得更为严重。 调查原因 首先要调查为什么会发生这种回归。这是一个我通常会依赖人工智能提供帮助的领域。我使用Claude，它在找到根本原因方面表现得相当出色：在0.9.91版本中，我在重构go命令以重用/共享逻辑与fetch命令时过于激进。我提取了一个供这两个命令使用的公共方法：parseURLOrExpression()，但在此过程中，我不小心在fetch命令之后扩展了语法，使其包含一般表达式。as关键字在表达式中有一个含义：它是一个转换表达式，允许你在类型之间进行转换：set x to "42" as Int。但as关键字也是fetch命令的修饰符，指示它如何转换响应：fetch https://hyperscript.org as Text（也许这个事实让你有点恶心，好的）。问题的关键在于，我在重构过程中无意中让解析器在fetch关键字后解析一个表达式，现在将as关键字视为一个表达式，而不是允许它作为fetch的修饰符。在Claude的帮助下，我在几分钟内就找到了问题，比如果我得单独搞明白要快得多。 解决问题 尽管人工智能在找到问题原因方面非常有帮助，但在解决问题时却显得无力。我在此承认我有些懒，向人工智能请求解决方案，因此抱怨这些解决方案感觉有点懒惰，但我仍然认为这一系列事件是有启发性的，所以让我们仔细看看发生了什么。 提议的修复1：一个黑客 第一个建议是先解析所谓的“类字符串”叶子，然后回退到完全表达式：return this.parseElement("stringLike") || this.requireElement("expression"); 这个修复将解决用户提出的即时问题。然而，它非常特定于报告的错误，无法修复一般情况，例如如果有人使用变量作为fetch的目标：fetch $url as JSON。我拒绝了这个建议，因为：过于黑客，而且不够通用。（请注意，超脚本解析器中有很多自然生成的黑客，所以这可能是在给锅上黑锅。） 提议的修复2：更好但不必要的复杂性 第二个建议更有趣：在解析器上添加noConversions标志，将其设置在URL解析周围，当设置时，让AsExpression.parse中止：// AsExpression.parse() if (parser.noConversions) return; 这会让许多解析器工程师感到不安，因为它使超脚本解析器变得上下文敏感。好吧。超脚本解析器本身已经是上下文敏感的。当查看...