Kent Beck：为人的需求构建 AI 编程工具

我最近重新看了自己的《Tidy First》工作坊材料。大约三分之一的内容在一年内过时了，但许多内容仍然适用。变化如此之快，自然会让人想问：哪些实践仍有助于我们设计软件？

两年前，我在这里谈到人们对 AI 和工作的焦虑。去年，情绪更接近恐慌和绝望。今年，在我参与的谈话中，我听到了挫折与愤怒，但也听到了行动的意愿。对我而言，愤怒可以是一个信号：该设定边界了。

我喜欢与我称为“精灵”的工具一起编程，尽管它也让我沮丧：它会实现你的愿望，却不一定是你原本想要的。今天我想把这种体验与此前提出的森林和沙漠之分结合起来——这是组织进行软件开发的两种方式。

在 Smalltalk 的世界里，程序员经常为眼前问题构建小工具。我现在又开始借助精灵这样做。最近，面对一段混乱的代码，我请它用 D3 力导向布局可视化调用图，并通过对话逐步完善结果。

我希望其他人也能使用这个工具，但打包和通用化软件会带来额外工作与假设。于是我把对话浓缩成一个提示词，让其他人根据自己的情境生成版本。我称之为“工具种子”：分发种子，而不是一棵已经长好的树。

当前工具会继续变化，但它们的设计已经产生影响。我对赞美程序员半夜醒来继续输入提示、睡眠极少的文化感到不安。工具的生产力不应以它占据一个人生活的程度来衡量。

2025 年开始尝试 AI 辅助编程时，我突然开始动手做多年来想做的项目。作为经验丰富的工程师，我积累了许多想法：如果搭建和实现更容易，这些想法就值得尝试。新工具减少了足够多的阻力，让实验变得诱人。

我也发现自己不停编程，甚至半夜醒来再发送一个提示。我患有双相情感障碍，经历了一次躁狂发作，随后陷入抑郁。后来我刻意在周末停止使用这些工具，也不再半夜输入提示；设定这些边界后，我感觉好多了。

因此，我希望工具构建者为设计选择的后果承担责任。心理健康影响不一定会在一次会话结束后消失。鼓励强迫性使用，并不是中立的设计决定。

在沙漠中，组织假定时间、稳定性、技能、人员和接触领域专家的机会永远不够。人们在这些限制下仍然能完成了不起的事情，但稀缺感影响每个决定。当所需功能的时间已经不够时，偿还技术债务似乎是不可能的。

在森林中，假设是资源会足够，尽管环境并非没有危险。团队的工作方式会为下一轮补充资源。重构可以加快未来的进展，从而帮助创造这项工作所需的时间。

组织中可能在更大的沙漠里拥有一片健康实践的绿洲，但维持它很困难。这一区分并不是对参与者的道德评判，而是描述不同的反馈循环和组织所强化的选择。

精灵是一台放大器。在稀缺心态下，团队可能进一步压缩本已不现实的时间表，或狭隘地关注减少 token 用量，加剧焦虑。同样的技术也可以放大健康实践：过去不经济的实验变得可行，人们可以探索不同方案或学习。

我把精灵当作一个永远有耐心的导师，尽管仍需核查它的答案。在沙漠里，不知道某件事可能让人不敢承认。在森林里，知识缺口可以成为调查的理由，而工具能够帮助这种探索。

单纯以最小化或最大化工具用量为目标都不明智。工程是权衡的空间。精灵会放大我们带入的信念和实践：如果之前演奏的是美妙音乐，它能放大音乐；如果之前是噪音，它也会放大噪音。

看待这种权衡的另一种方式是功能与未来选择。许多项目起初进展很快，随后越来越难修改。我有一系列重新开始的项目，因为每次尝试最终都慢到让我觉得重来更容易。

每增加一个功能，都可能通过让下一次修改更难而消耗一些未来选择。精灵往往立即提出下一个功能，有时甚至不问就自行添加。最终，即使强大的工具仍能快速生成修改，修复一个错误也可能引入更多错误。

我担心的不只是以更快、更便宜的方式得到相同的软件。根据我的经验，我们可能更快地得到更糟的软件。一个看起来完成了任务的工具，可能改善了系统，也可能产生了多到无人愿意审阅的输出。

另一条路是在完成一个功能后停下来，问问什么能让它更容易添加，什么能让下一个功能更容易。对结构的小幅改进可以补充选择余地。它们不是取代功能交付，而是与之交替进行。

作为投资人，我关心保留选择余地，尤其是在环境迅速变化时。功能很多但剩余选择很少的项目，可能不如功能足以生存、却保留更多适应路径的项目有价值。

在沙漠里，这些结构性改进很难证明其合理性，因为它们看起来不像直接的功能进展。我曾向一位客户解释测试和重构流程，对方问如果省掉这些能提前多久交付。我的回答是：那反而要花两倍时间。

在森林里，为未来增加选择是正常工作节奏的一部分。每次做一点，同时继续交付功能。极限编程长期强调这种节奏以及与客户紧密合作；agent 开发并没有让这些需求消失。

第一次听说大语言模型可以生成语法正确的软件时，我很怀疑。它们的实用性至今仍让人惊讶。早期工具构建者探索模型能做什么，是有道理的，因为我们当时并不知道。

但我认为，现在该改变重点了。太多注意力都放在如何让编程适应模型上。我希望工具围绕人的需求设计，而不是假定以更低成本产出更多代码就是全部目标。

我讲过一个著名的蛋糕粉故事：据说制造商让顾客自己加鸡蛋，好让烘焙感觉更像一项成就。核查历史后，我发现这个广为流传的版本并不准确；我找到的叙述强调的是糖霜和装饰的作用。

这个故事仍然引出一个关于体验的问题。人们需要在工作中感到胜任，也需要挑战。精灵出现之前，一个问题可能让人经历挣扎、获得洞见并找到解决方案；这些努力是理解事情经过所带来的满足感的一部分。

当我把挣扎完全外包时，即使完成了很多事情，也可能在一天结束时感到空虚。工具解决了问题，但我错过了让工作令人满意的努力和洞见。挑战与胜任是不同的需求，对我而言，当前工具都没有充分满足。

连接是另一种需求。如果每个人都独自面对自己的代码仓库和一群 agent，速度的代价可能是人与人之间的互动。更多 agent 不能替代人与人的连接。

“黑暗工厂”的理想——让 agent 完成一切，人很久之后再回来——并不吸引我。我希望在过程中有有意义的角色，而不只是得到一张账单和尚未完全完成或运行的软件。

目的感也很重要。团队可以提醒自己为什么构建某样东西，以及为什么要一起做。当工作被简化为沿流程传递的孤立工单时，人很难看出某项任务为何值得占用生命中有限的时间。

我从精灵那里看到的结果并不总是好到足以让我退出这一过程。我希望工具偏向人的需求：帮助人们生产有用的软件，同时保留目的感和贡献感。

设计这样的工具需要实验。我推荐一本关于工程师知识的书，其中包括为飞机开发可靠的平头铆钉所需的多年实践。工程师常常先发现什么有效，然后科学家才能充分解释原因。

一个原则是促进连接。工具可以注意到某位同事最近修改了同一区域，并建议双方交流。它也可以帮助开发者连接用户、领域专家、管理者和投资人，而不是让这些关系看起来像负担不起的奢侈品。

另一个原则是自动化琐事。反复出现的低价值提示，例如请求允许进行常规目录切换，会打断专注。但消除琐事与消除所有有益的挣扎不同；区分二者会很困难。

我不希望编程毫不费力。我希望工具指出重要决定，帮助我理解其中的权衡，并帮助我将决定传达给需要知道的人。如果精灵默默作出太多选择，我就失去了学习机会，也可能得到更差的结果。

学习应贯穿整个工作过程。现在我可以停下 agent，问它解释不熟悉的 Rust 语法，再要求它制作一张记忆卡并在之后测验。但我必须打断工具偏好的流程，学习才会发生。

想象一下，一天结束时，你使用的工具促进了人与人的连接，消除了琐事，支持你通过挣扎获得洞见，展示可参与的选择，并鼓励学习。我期待这样的工作带来更强的满足感、目的感和归属感。构建这类工具需要刻意努力，其激励也应超越单纯消耗更多 token。