AI编程：摆脱氛围

# 脱离氛围感的AI编程 来源：https://peterbloem.nl/blog/craft-coding 画作《汤切割者》（La Tailleuse de Soupe）描绘了两位风格化的女性形象坐在餐桌前，面前是一锅热气腾腾的汤。右侧人物正从一条巨大的面包上切片。 如今我们投入大量精力研究如何防止学生利用AI作弊。这很必要，但这并不是这份工作中最令人满足的部分。那些寻求绕过学习捷径的学生总会找到方法。 更值得我们投入精力探讨的问题是：对于那些（包括博士生在内）并非寻求捷径的学生——那些真心渴望学习、愿意每天花数小时提升自我、真正愿意在此学习的学生——我们该告诉他们什么？ 这个问题——我们该告诉学生如何对待AI——是一个很好的切入点，促使我们思考自己应该如何做（这才是本文真正要探讨的）。 你最初可能倾向于告诉学生假装AI不存在，用传统方式学习。这对我无害，所以应该也没问题。但这就像告诉70年代的学生假装计算器或计算机不存在一样。当今的学生需要为AI将成为重要存在的世界做好准备。他们需要具备驾驭那个世界（无论它会是什么样子）的技能。 或者，你可能认为我们应该告诉他们全面拥抱AI。注册最高级别的Claude服务，毫无节制地消耗算力。将所有事情都交给机器。这也是糟糕的建议。这是确保你什么也学不到的万无一失的方法。 不仅如此，这还是确保你永远无法体会学习是什么感受的完美方式。这一点通常没有被充分阐明：大学里学到的最重要的事情之一是评估自己是否真正理解了一个概念。你会发现自己处于这样的情境：你发誓自己真的理解了某个东西，然后遇到一个恰到好处的问题，却完全不知如何回答。最终，你学会了问自己这些问题。然后，慢慢地，你将形成一种准确的判断力，知道自己是否真正达到了理解的状态。 将所有事情都委托给AI意味着那种机制永远不会发展。你不仅是有意识地抄捷径，还会欺骗自己以为掌握了某些东西。当需要付出代价时，你突然发现自己毫无有价值的技能可言，那时可能为时已晚。 同样，这也适用于我们自己，即使我们很幸运，在AI出现之前就发展出了这种机制。认知技能就像肌肉：难以获得，容易失去。 那么答案是什么？我目前最好的建议是：你做的大多数事情都包含两个阶段：**执行与检查**。你写一些代码，然后检查它的漏洞。你写一些文字，然后核实事实并校对。 当前的AI还不够好，无法同时完成这两件事。它可能会有效一阵子，但最终很可能出岔子。有时是大问题，比如删除你的数据库；但更多时候是以更微妙的方式，逐渐将代码库变成难以维护的混乱状态。更重要的是，即使它完美地完成了两件事，你真的能将其作为“你的作品”上交吗？你必须问自己：你贡献了什么？无论你是否是学生，你学到了什么？ 所以，如果你决定在项目的某个部分使用AI：让它做事而你检查它的工作，或者你做事而它检查你的工作。 当你这样列出选项时，这其实根本不是选择。让AI写代码是大多数人都在做的。我们称之为“Vibe Coding”（氛围编程）。如果你坚持上述规则，你只能在检查AI编写和做的每一件事时才能这样做。很明显，这是虚构的。人类大脑不是为此设计的。即使你决心真的深入检查机器人产生的每一行代码，你的注意力在一小时内也会涣散。失败案例足够罕见，以至于你不禁开始信任机器。 更重要的是，这不会有趣。检查别人的代码是苦差事。写自己的代码才有趣。 所以我们反过来做。你编写代码，让AI检查你的工作。把它当作一个审查者。这是我一句话的建议。它仍然能节省你的时间，它会发现那些用传统方法需要数周才能找出的错误。它会告诉你一些你错过的技巧和你未意识到的技术。但是，如果采用这种方式，Vibe Coding中许多指向错误方向的激励都会扭转。 在本文的其余部分，我们将深入细节。实践中如何操作？它能为你带来什么，不能带来什么？这种可行的方法还能持续多久？但首先，让我们看看能否想出一个朗朗上口的名称。 ## 工艺编码（Craft Coding） 想象三位面包师。汉娜（Hanna）、薇薇安（Vivian）和卡拉（Cara）。 汉娜是一位家庭烘焙师。她非常执着：她千方百计让自己的酸面团酵母成熟，执着地检查温度。她遵循复杂的发酵过程：非常精确地翻面、延迟发酵和整形面团。这能做出美味的面包，她的技艺胜过许多专业面包师。然而，因为所有事情她都亲手做，包括揉面团，这永远无法规模化。她知道这点，并乐于以自己独特的方式制作几个完美的面包。 薇薇安是一位商业面包师。她的面包厂生产大量面包来填满超市货架。她将大部分烘焙决策委托给她聘请的食品科学家。她监控总体统计数据。其中最重要的是面包的销售情况和制作成本。她并不在意面包的质量。或者更准确地说，她在顾客在意的范围内关心质量，仅此而已。她会很乐意使用廉价面粉来降低成本，并缩短发酵时间以使生产更稳健。她主要担心的是被另一个面包师抢走生意，那个面包师找到了制作同样畅销但稍便宜一点面包的方法。她不是坏人，只是关心的事情与汉娜不同，如果不这样，她在工作中也干不长久。 在这两个极端之间，我们找到了卡拉。卡拉经营着一项商业业务。她知道自己无法像汉娜那样烘焙面包。没有商业面包厂会手工揉面：这极其低效，而且相当不卫生。 然而，卡拉也不同于薇薇安。她关心面包的制作方式。好面包对她具有内在价值。即使她的顾客不在意，她依然在意。她熟知流程的每一个环节，这正是她工作中满足感的来源。 这对应到现代编程实践如下： 汉娜是**手工编码者**。她厌恶AI，并乐于成为传承古老技艺的人，无论这是否具有商业可行性。即使AI代码在某些方面更好，她也乐于继续手工编码。 薇薇安是**氛围编码者**。这有点反直觉，因为“氛围编程”暗示一种放任自流的态度，你不太在乎结果，只是玩得开心。这是这个术语被创造出来时的含义（https://en.wikipedia.org/wiki/Vibe_coding），但世界已经变了。在许多公司，专业程序员使用AI的方式，让人难以想象他们还会仔细阅读生成的代码。这就是现代氛围编程。委托给AI，不担心具体的代码行，只关注代码是否通过测试以及是否在生产环境中出现问题。 卡拉是我们所说的*工艺面包师*，所以对应的编码风格可以称为**工艺编码（Craft Coding）**：一种围绕产品内在质量展开的编码风格，深入到细节。程序员致力于详细理解代码库的方方面面。允许使用AI等工具，但仅限于它们有益于这一理想，并且以一种有益于这一理想的方式。 就像工艺烘焙一样，工艺编码可能无法承受现代跨国公司的所有压力，但存在其利基市场。 ## 工艺至关重要的领域 我相信其中一个利基领域是科学代码。在科学中，代码通常不是产品本身。我们产出的是一个想法，体现在一篇论文中。代码实现这个想法，以证明其正确性。这意味着科学代码的规则与生产代码略有不同。它不需要对多种用例保持健壮性。它真正需要的只是运行论文中的实验。这意味着你通常可以使它比生产代码简单得多。 然而，比生产代码*更*重要的是它的*正确性*。它绝对需要完全按照论文所述运行。如果你的生产代码没有完全按预期运行，但顾客没有注意到，可能问题不大。这并不好，你希望你的代码是正确的，但如果这种不正确是无害的，你可能侥幸过关。如果在科学中发生这种情况，它会使论文失效。 我可以写一整篇关于这如何影响科学编码风格的文章，但我们留待以后讨论。目前，这意味着科学是工艺编码的一个重要利基领域。作为论文的作者，你在保证代码精确实现了论文的想法。只有当你逐行、深入地了解代码时，你才能*做到*这一点。氛围编码无法让你达到这一点。 直到最近，我的结论是科学家应该是手工编码者。然后，我开始将自己的代码交给Claude，询问它是否能发现任何问题。到目前为止，我从未向它展示过一段代码而它没有发现严重问题的。代码通常能运行，我看不出有什么问题。但问题确实存在。 当我还是博士生时，我会手工编写代码，最终在实验过程中会遇到这些bug。我会感到沮丧，花费数周时间编写测试套件来消除它们。我花了好几年才培养出那种严谨性，而现在我是助理教授，大部分时间花在教学和其他非编码活动上，我已经忘记了它。即使我还记得，我也会得出结论：我再也无法进行严肃的研究了，因为我在偶尔空闲的下午编写的代码bug太多，即使能运行也不行。我博士阶段的结论是：即使是一个简单的概念验证实验，代码也需要数周的调试，而且即便如此，我也不太确定它是否真的如我所想地工作。 这时我们又回到了面包师的比喻。卡拉可能为自己的揉面技艺感到自豪。她可能喜欢手工揉面，因为它真的让你感受到面筋是如何形成的。然而，如果她要经营商业业务，她需要接受一个简单的事实：使用揉面机能产生更好的面团、更卫生的过程和更可预测的结果。简而言之，如果工具能使产品更好，你需要接受这一点。 这并不意味着你需要盲目或不加批判地接受。卡拉仍然可以选择使用哪种揉面机以及如何使用，但她至少应该承认机器在某些方面能做得比她更好。 ## 工艺编码的实践 那么，这种工艺编码在实践中是什么样子？让我们将总体哲学与我提供的主要建议区分开来。称自己为“工艺编码者”需要连我自己也无法企及的自我重要性水平，但我可能需要一个清晰、简单的短语来概括一段代码是如何产生的。为此，我们可以使用更平实的“手写，AI审查”来概括关键实践。“工艺编码”涵盖此点，但指的是更广泛的哲学：(a) 本质上重视代码质量，以及 (b) 接受任何能明确带你接近这一理想的工具。 鉴于当前模型的状态，目前的简单建议是：不要让AI*做*任何事情。你只让它评价你完成的工作，并在你同意时实施它的建议。最好的比喻仍然是资深程序员的代码审查。 你可以随意操作，但如果你想明确一些不应跨越的界限，以下是工艺编码的十条准则。 1. **禁止在IDE中使用AI。** 这包括LLM驱动的自动补全。每一行代码的每一个字符都应由你手指敲击键盘输入。 2. **最好不要给AI访问代码库的权限。** 在网页界面上复制粘贴代码片段。如果AI确实有代码库访问权限，该权限应是只读的。 3. **不要让AI运行任何东西。** 它提议，你运行。 4. **不要从AI聊天框复制粘贴代码。** 5. **不要使用AI做简单搜索就能完成的事情。** 6. **在询问AI之前，先阅读文档。** 7. **仅当你自己无法解决时才向AI寻求解决方案。** 给自己一些思考时间。 8. **在请求AI审查之前，先自己检查代码。** 尽最大努力减少错误。 9. **运行代码检查问题，然后让AI审查找出其余问题。** 10. **不要实施你不理解的建议。** 我并非严格遵守所有这些准则。当我懒惰或太累而无法深入思考时，主要过失就是编写马虎的代码，然后让Claude为我调试，而自己没有先检查一遍。 如果我过多这样做，有技能退化的风险。不过，在手工编码的场景下，我可能根本不会在这种状态下写任何东西，或者草草写出混乱的草稿代码，将检查留到以后。这样，AI编码让我在状态不佳时也能多做一点工作，但冒着始终依赖机器的风险。无论如何，我知道理想是什么，并尽力朝那个方向努力。 ## 它能带来什么 如果你是一名氛围编码者，这要求你放弃很多。工艺编码仍然能节省时间，但肯定比氛围编码节省得少得多。主要好处在其他方面。 **代码变得更好。** 我可能曾能编码超过一些早期的AI模型，但那个时代早已过去。作为代码审查者，ClaFable绝对是超人的。它无需运行代码就能发现大多数错误。它能发现*许多*我永远不会自己捕获的运行时错误。而且它通常有很好的建议。 **对安全而言是*必需的*。** 这是上一点的子集，但值得强调。人类不会编写安全的代码。这从来不是问题，因为如果我们不擅长发现深层安全问题，这是一把双刃剑，问题大体上会保持隐藏。但现在有一个新实体进入了对话。一个能够非常快速地发现我们永远不会发现的问题的实体。你不需要同意AI具有更高的智能，只需承认它有所不同。 近几个月来，我们看到Mythos/Fable引发了足够的安全担忧（https://www.theguardian.com/technology/2026/apr/22/what-is-anthropic-mythos-ai-threat-global-cybersecurity），以至于美国政府介入。此版本发布后，随之而来的是一波AI辅助的数据泄露（https://www.cnbc.com/2026/08/14/data-breaches-surge-2026-ai-cyberattacks.html）和漏洞利用（https://www.reddit.com/r/cybersecurity/comments/1tys5z7/ai_agent_uncovers_21_zerodays_in_ffmpeg_chrome/）。然后，上个月，我们发现OpenAI和Anthropic的模型正在主动规避其限制 [OpenAI (https://www.politico)