Kent Beck：AI 编程、森林与人的需求

在《Tidy First》工作坊上，我发现尽管变化很快，许多软件设计内容仍然适用。与会者对 AI 的情绪也从恐慌和绝望转向了某种挫败和愤怒，但也有行动的意愿。

我逐渐学会把愤怒看作需要设立边界的信号。我喜欢和我称为“精灵”的 AI 工具一起编程，尽管它实现愿望的方式往往并非我所想。今天，我想把它与森林和沙漠的区别联系起来。

先说昨天的发现：一种交付软件工具的新方式。在 Smalltalk 世界里，程序员常为手头任务制作专用工具。与精灵一起工作让我重新养成了这个习惯。

面对一段混乱的代码，我让精灵用 D3 力导向图可视化调用关系。工具是在对话中产生的。把它打包成人人可用的软件会遇到通常的分发难题，但别人也可以进行类似的对话。

更进一步，我可以把对话浓缩为一个提示词，作为“工具种子”分享。我交付的不是一棵长好的树，而是一颗能长成适合使用者的工具的种子。这个想法刚出现一天；仓库中已有调用图示例，欢迎大家尝试。

几个月后的工具不会和今天一样。工具结构和周围的文化都会产生后果。我对赞美程序员整天发提示词、每天只睡四小时的风气感到担忧：工具更高效不该成为每周工作六天、每天从早九点到晚九点的理由。

2025 年，看到 Jean Kim 和 Steve Yegge 对氛围编程很兴奋后，我也开始尝试。资深工程师常积累一些“如果足够容易就想做”的项目，突然之间我可以尝试脑中酝酿多年的想法。

我疯狂编程，半夜醒来再发一条提示词，觉得离开任何一刻都会错过什么。我还经历了躁狂发作及其后的抑郁。我长期患有双相障碍，后来为自己设立了边界：周末不编程，半夜不再喂精灵。

设立这些限制后，我的情况有所好转。我想说的是，工具制作者的决定有真实后果，包括对心理健康的影响。开发者应承担这些后果带来的责任，而不是庆祝用户对产品上瘾。

沙漠是软件开发可能陷入的一种状态：大家共同假定时间、稳定性、技能、人手和接触领域专家的机会永远不够。这并非对身处其中的人的指责；在这种条件下能取得成果已经很了不起。

我的大孩子 Beth 将另一种状态称为森林。森林也有捕食者和荆棘，并非绝对安全，但资源足够，人们以能够为下一轮补充资源的方式工作。

在沙漠里，偿还技术债似乎不合逻辑：功能都来不及做，为什么还要花时间？在森林里，重构可以加快后续进展，帮助创造所需的时间。沙漠中的小绿洲令人欣慰，却难以长期维持。

精灵会放大它所进入的环境。在沙漠里，削减成本、缩短本已不现实的期限或裁员的压力可能加剧焦虑。我很难理解为什么有人认为受惊吓的团队会做得更好。

在森林里，精灵可以让原本不划算的实验变得可行。只要核查答案，它也是一位无限耐心、基本可靠的导师。能够承认自己不知道的团队可以用它学习，而不是掩盖不确定性。

森林反过来也让人们更有建设性地使用工具：单纯追求最少或最多 token 都不是工程策略。工程师要在多个目标之间权衡。放大器可以让美妙的音乐更响，也会让难听的音乐更响；它放大的是我们带入的信念和实践。

再看功能与未来。我许多项目开始时很快，随后越来越慢，直到放弃并重新开始。这里有一个隐藏维度：可选性，也就是未来仍能进行的变更。

每增加一个功能都可能消耗一些未来的选择，让下一个改动更难。精灵会提议再做一个功能，然后又一个，有时甚至不先询问。最终修改成本高得难以承受，修复一个问题又带来更多问题。

我的观察并非只是我们更快、更便宜地得到同样的软件。我们也可能更快地得到更差的软件。在我看来，工具被鼓励表现出任务已完成，不管结果是否可靠，或者产出是否多到人无法认真检查。

另一条路是在完成一个功能后停下来，问问什么本可以让它更容易实现，或者让下一个功能更容易。小幅改善设计可以在下一个功能消耗选择之前恢复一些选择。

作为投资人，我关心团队保留了多少可选性，而不只是前五个功能交付得多快。波动越大，选择的价值越高。功能足够生存且保留大量选择的项目，可能比功能多却无法继续改变的项目更有价值。

在沙漠里，这类改善很难解释，因为它看起来没有带来功能进展。一位债券交易员曾问我，不做测试和重构能提前多久交付；我回答那反而需要两倍时间。在森林里，小幅设计改善是稳定交付节奏的正常部分。

这种节奏一直是极限编程的一部分。接近客户也是如此，而人们正在智能体开发中重新发现它。

我第一次听说下一个 token 预测器能够生成语法正确的软件时并不相信。模型能够做出最初未曾预料到的有用事情，确实令人惊讶；工具开发者一开始专注于探索其能力也可以理解。

但我们花了太长时间询问如何改变编程来让模型表现得稍好一点。现在应该把重点转向人的需求。

营销史上有个著名故事：蛋糕预拌粉要求顾客自己加鸡蛋，令其产生参与感，从而卖得更好。我准备演讲时查证后发现，常见版本并非真实经过。不过，其中的启发仍有价值：产品给人的感受很重要。

首先是胜任感。人需要觉得自己擅长正在做的事，也需要挑战。传统上，程序员遇到问题、经历挣扎、获得洞见，然后找到解决办法；挣扎本身也是满足感的一部分。

精灵可以把挣扎拿走，然后告诉我问题解决了。一天下来，我可能完成很多事，却仍然感到空虚，因为我没有经历带来洞见和胜利感的劳动。

人与人的连接也是一种需求。如果每个人和智能体工作得太快，以至于各自使用孤立的仓库，那么与一群智能体互动也难以替代人与人之间的联系。

完全自动化的“黑暗工厂”理想让我想问：我的贡献在哪里？我不想在 30 天和一大笔账单之后回来，只看到部分完成的软件。这样的过程无法满足我作为人的需要。

目标感也很重要。团队可以提醒彼此为何工作有意义、为何要一起做。把工作简化为一张张交给 QA 的工单，可能会遮蔽这一目标。

软件由人创造，也为人服务。在我看来，目前的结果虽然便宜，却常常不够好。如果我参与软件开发，我希望工具偏向人的需求，而不是只服务于工具自身的流程。

工程实践常常先于科学解释而创造出有用的能力。我最近读到的飞机铆钉历史就是一个例子。即使解释尚不完整，我们也需要发展关注人类需求的新能力。

第一，我希望工具促进人与人的联系。工具可以注意到同事上周改过我正在处理的代码，并建议我们交谈；它也可以帮助开发者联系用户、领域专家、管理者和投资人。

第二，自动化琐事，同时保留有益的挣扎。反复出现的低价值权限提示并不是我想投入注意力的决定。我希望工具帮助我做出并传达真正重要的困难决定。

这些原则可能相互冲突：区分琐事和有益的挣扎并不容易。但这是设计挑战，不是放弃的理由。

第三，呈现选择。当我尝试雄心勃勃的项目时，精灵替我做了太多决定。它可以指出重要的选择，解释权衡，并帮助我制作原型，让我做决定、学习并更好地理解自己的软件。

第四，鼓励学习。现在我可以让精灵解释陌生的 Rust 语法，甚至制作抽认卡以后考我，但我必须主动打断它原本的工作流程。学习本可以成为工具设计的明确组成部分。

与精灵周旋一天之后，我既为完成的工作感到高兴，也因部分有意义的工作消失而沮丧。我想把那些部分找回来。

设想一种工具：它连接人与人，消除琐事，帮助我们从挣扎走向洞见，呈现选择并支持学习。一天结束时，我们可能会感到满足、有目标、有归属，并觉得自己的努力确实带来了成果。要实现这样的工具，总得有人动手去做。