与 AI 协作：一个具体的例子
文章摘要
htmx 作者 Carson Gross 在这篇文章里通过一个具体的 bug 修复案例，剖析了 AI 在编程中”强在哪里、弱在哪里”。他的核心论点是：AI 擅长调查性（investigative）和生成性（generative）的任务，但不擅长设计出优雅的解决方案；关键在于要有懂行的人来引导 AI 走向架构上合理的答案，而不是不加批判地全盘接受它给出的初版建议。
具体的例子是 hyperscript（一种解释型脚本语言）解析器里的一个 bug：fetch 命令中的 as JSON 修饰符绑定得太紧（binding too tightly）。Claude 很快定位到了根因——一次过于激进的重构错误地扩展了语法。然而 Claude 给出的初版修复要么过于狭隘（只针对上报的那个 bug，无法覆盖一般情况），要么引入了不必要的复杂度（连带禁掉了 go 命令中完全合法的 as 转换表达式）。
真正优雅的解法来自 Gross 本人：他意识到解析器基础设施中既有的 “follows” 机制可以更漂亮地解决这个问题，于是把这个特例精确地收窄到仅作用于 fetch 命令，不影响其他功能。他由此总结出几点体会：AI 能有效辅助调查和生成测试，但判断”什么才是架构上合适的方案”仍离不开人类专家；当开发者在不理解代码库的情况下接受次优建议时，技术债就会累积；对年长的开发者而言，AI 能缓解记忆力和精力的衰退，但也带来智力退化（intellectual atrophy）的风险——这就是”魔法师学徒”式的隐忧：一旦开发者把批判性判断力拱手让给自动化系统，问题就来了。
HN 评论精华
讨论以对作者的赞赏开场（hugeBirb、AloysB 都表示喜欢这种”罕见的具体案例”），随后深入到”AI 为何不擅长设计”的成因辩论。
- jdlshore 的看法与作者高度一致：AI 擅长分析和样板代码，但缺乏做出好设计所需的批判性思维——它”太快跳向解决方案”，不会退一步从全局考虑各部分如何拼成一个连贯整体；他认为这与 LLM 没有”世界模型（world model）”有关。oulipo2 补充说 LLM 擅长”代码补绘（code inpainting）”：给定清晰的结构和目标，它能填好样板，但因其训练本质是一种”求平均”，缺乏推理、抽象和提出新颖设计的能力。
- 但也有人反驳”世界模型”这类解释。Zababa 直言这类说法往往是空洞的，更朴素的答案是”软件架构比代码/数学更难验证，所以对它做 RL 更难、写好的评测基准也更难”。stymaar 则提出社会学偏见的角度：造 LLM 的人熟悉写代码但不是软件工程师，所以他们把 RL 策略设计成”让模型学会写代码”，而非”学会设计可维护的软件”。
- 关于缓解手段，rapind 描述了真实体感：与 LLM 协作就是不断在它的上下文之外（自动化地）加护栏——静态类型、快速编译、消除 null、lint 等等，先让它快速逼近解，再”在问题周边搭好它的笼子”。rst 建议善用 plan mode 并仔细审查计划；epolanski 分享用 superpowers 的头脑风暴 skill、再让另一个 LLM（如 codex）做对抗性评审，能显著提升设计质量。
- 关于”AI 是否会让人变笨”，出现了分歧。waffletower 不认同”AI 会缓慢钝化我们的智力”这一论调，以自己隔十年重拾旧技术栈的经历说明遗忘的东西能很快找回；ekidd 用 Anki 的间隔记忆数学补充了”重新记起比从零学快得多”的量化依据；但 luisln 反问：”我在所有副业项目里都只告诉它’我想要这个按钮做某件事’，你是说这对我的大脑有好处？”
- wiremine 批评文章缺少关键细节（用的哪个 Claude 模型、什么提示方式），作者 recursivedoubts 回应是通过 IntelliJ 的 Claude 插件用 Opus 4.x，提示过程也很平常，没什么特别。smokefoot 则唱反调，认为作者承认这门语言和解析器设计本就”古怪”，连他自己偏爱的解法也不过是既有 hack 的延伸，他本可以更开放地看待 AI 的建议——很多对 AI 编码者的批评其实同样适用于 95% 的人类开发者。