Chris Parsons 更新了他关于使用 AI 编程的指南。这是他的第三次更新，我喜欢的是他提供了大量关于如何使用 AI 的具体信息，细节足够丰富，我们可以从中学习。他的建议也与我见过的更佳建议相呼应，因此这篇文章很好地概述了使用 AI 进行软件开发的现状。
我在 2025 年 3 月撰写了这篇文章的上一版本，8 月更新过一次，此后我几乎所有关于 AI 工程的文章都链接了它。那篇文章的基本原则依然成立：保持改动小规模、建立防护栏、彻底记录文档，并确保每次变更在发布前都经过验证。有一点不得不随着工作量而调整。“已验证”过去意味着“你已审阅”。考虑到现代 AI 代理的处理能力，它现在必须意味着“通过测试、类型检查器、自动化关卡检查，或在你的判断至关重要时由你检查”。检查仍然会发生；只是不再总是在你的头脑中进行。
与 Simon Willison 一样，他明确区分了“氛围编程”（你不查看或关心代码）和“代理式工程”。他推荐使用 Claude Code 或 Codex CLI。他认为他偏好的工具提供的内在“驾驭机制”是其优势的关键部分。
他认为验证是需要关注的核心问题：
一个能在一下午生成五种方法并全部验证的团队，将胜过那种只生成一种方法并等待一周反馈的团队。游戏规则不再是“我们能多快构建”。而是“我们能多快判断这是否正确”。这改变了投资方向。构建更好的审查界面，而不是更好的提示词。在可能的情况下，让 AI 代理在向人类提问之前，先对照真实环境进行验证，从而消除反馈需求；在无法消除时，则让反馈即时发生。
程序员的关键角色在于训练 AI 正确编写软件，而熟练的代理式程序员能做的最重要的事情，就是将这项技能传授给其他开发者。
如果你是一位资深工程师，担心自己的工作正悄然变成审批代码差异：事实确实如此。出路在于训练 AI，让代码差异第一次就正确，让自己成为团队中塑造“驾驭机制”的人，并将这项工作变成你被考核的可见成果。这个角色的价值会不断累积，而审查工作永远不会。
❄ ❄ ❄ ❄ ❄
本月初，Birgitta Böckeler 撰写了一篇关于驾驭工程的精彩文章。（这不仅仅是我个人的看法，从它带来的惊人流量就能看出。）Birgitta 现在录制了一段与 Chris Ford 讨论驾驭工程的视频，非常值得一看。
在视频中，他们重点讨论了计算传感器在驾驭机制中的作用，例如静态分析和测试。
LLM 非常适合探索性和模糊规则，但一旦你有了真正客观的东西，将其转换为正式、明确、确定的格式，就能获得更高的保障。
Birgitta 进行了一些实验，探索添加传感器的好处，其中深入研究了静态分析。她发现这更有用，因为智能体可以真正处理每一个警告，而不会像人类那样偷懒。
❄ ❄ ❄ ❄ ❄
Adam Tornhill 思考了一个古老的问题：一个函数应该有多长？ 在智能体编程时代，这个问题依然具有现实意义。
AI 模型并不像人类那样“理解”代码。它们从 token 的模式中推断含义，并且严重依赖代码中明确表达的内容。
研究表明，命名起着关键作用。当有意义的标识符被替换为任意名称时，模型性能会显著下降。当前模型严重依赖字面特征——名称、结构和局部上下文——而非推断的语义。
和我一样，他认为答案不在于思考一个函数应该有多少行，而在于提供更好的结构。他有一个很好的例子，说明一个精心选择的函数如何定义有用的概念：一个函数封装了四行代码，返回一个新概念，从而进入程序的词汇表。
函数是代码库中结构的第一个单元。它们定义了逻辑如何分组、意图如何传达以及变更如何局部化。如果函数边界设置错误，那么建立在它们之上的一切都会变得更难理解和更难演化。
这符合我的观点：函数长度的关键在于意图与实现之间的分离：
如果你需要花精力去查看一段代码片段以弄清楚它在做什么，那么你应该将其提取为一个函数，并用那个“做什么”来命名该函数。这样，当你再次阅读时，函数的目的就会立刻跃入眼帘，而且大多数时候你无需关心函数如何实现其目的——即函数体。
❄ ❄ ❄ ❄ ❄
我信息流中的许多人推荐了 Nilay Patel 关于为什么人们讨厌 AI 的文章。他认为软件领域的许多人患有“软件脑”：
我想出的最简单定义是：当你将整个世界视为一系列可通过软件代码的结构化语言控制的数据库时，便是如此。如我所说，这是一种强大的看待事物的方式。我们生活的很大一部分都运行在数据库中，而许多重要公司的建立正是为了维护这些数据库并提供访问权限。
Zillow 是房屋数据库。Uber 是汽车和乘客数据库。YouTube 是视频数据库。The Verge 的网站是故事数据库。你可以一直列举下去。一旦你开始将世界视为一堆数据库，就很容易觉得只要能控制数据，就能控制一切。
软件大脑将人视为数据库，而奇怪的是，很多人并不喜欢这样。这就是为什么许多民调显示人们对人工智能运动抱有负面情绪。
即使花时间思考一下你的生活有多少被记录在数据库中，也会让人不快。没有人希望被持续监视，尤其不希望以让科技公司更强大的方式被监视。但将所有信息纳入数据库以便软件能够查看，正是人工智能行业的核心关注点。这就是为什么现在所有会议系统都内置了 AI 笔记工具。
Patel 提出了一个我也常做的类比——程序员与律师之间的相似性。起草合同的律师正在创建一份协议，规定合同各方应如何行事。正如 Patel 所言：
如果说软件大脑的核心在于认为用代码的结构化语言思考能让现实世界发生改变，那么律师大脑的核心则在于认为用法律条文和引证的结构化语言思考同样能推动事情发生。见鬼，它甚至能赋予你凌驾于社会之上的权力。
当然，区别在于法律是非确定性的。诉讼解决的是当人们对合同如何执行有不同看法时会发生什么。
❄ ❄ ❄ ❄ ❄
我最近与一家公司聊天，他们想用 AI 来理解内部数据。潜力巨大，但问题在于数据一团糟。人们把内容填进不合理的字段，对重要实体的分类也缺乏一致性。正如有人评论道：
内部数据最难的问题在于精确、一致的定义。
你可以想象我有多惊讶。（其实一点也不——在我与计算机打交道的几十年里，这始终是一个永恒的主题。）获得这种定义的困难，在很大程度上削弱了软件大脑的许多希望。
这与我们在编程时与LLM的关系产生了共鸣。精确且一致的定义，在我看来，对于与“精灵”进行有效沟通至关重要。这些定义需要在对话中不断生长，并随时间得到照料。概念建模将成为智能体编程及未来发展的关键技能。（至少我希望如此，因为这是编程中我非常享受的一部分。）
❄ ❄ ❄ ❄ ❄
帕特尔的文章引用了埃兹拉·克莱因关于旧金山新氛围的帖子。
你可能会认为硅谷那些腰缠万贯的AI人士如今正春风得意。但我发现他们明显缺乏安全感。他们认为AI时代已经到来，而赢家和输家将在一定程度上取决于采用速度。这个论点很简单：在AI助手和编码员大军之上工作的优势会随时间累积，现在开始这一过程，就能让你在未来远远领先于竞争对手。因此，他们正在相互竞争，将AI全面融入自己的生活和公司。但这不仅仅意味着使用AI，还意味着让自己变得对AI可读。
这种“可读性”正是帕特尔观察的核心。正因如此，我看到许多同事将他们所有的电子邮件、会议记录、幻灯片以及其他一切内容都倾倒进AI能够读取和处理的文件中。这恰好发挥了AI的优势——我们知道AI非常擅长查询非结构化信息。因此，我能以远比指望自己输入正确的搜索正则表达式更有效的方式，找出埋藏在笔记中的内容。
我在网络上大量使用Gemini正是出于这个目的，发现向它提问比向谷歌输入搜索词更容易。Gemini会记录我过去的请求，并利用这些信息来调整它对我所寻找内容的理解。正如克莱因所观察到的：
[AI]会不断回溯它已知或自认为已知的关于我的其他信息。根据我的经验，谄媚已让位于一种偶尔令人不安的专注；它不断在我当前的关切与过去的查询之间建立联系，就像一个急于证明自己一直在认真倾听的治疗师。
结果是一种既感到被看见，又感到被漫画化的奇异混合体。
和克莱因一样，我本人也是一名作家，同样面临着我在思考人工智能与写作时遇到的诱惑。或许我本不必绞尽脑汁撰写文章，而是让大语言模型生成一份总结我写作风格的AGENTS.md文件，每隔几天请它围绕某个主题创作一篇文章，我只需阅读、调整，然后发表这些博学的思考。但这对我毫无吸引力。我希望理解力能在我的大脑中生长，而非大语言模型转瞬即逝的会话中。通过写作向他人解释我的思考，正是我打磨思维的方式——正如克莱因所言，“将想法雕琢成可发表的作品”。若让AI代笔，无异于自废心智。