AI 写代码之后，我们还在编什么？

《代码整洁之道》里有一句话：

将需求明确到机器可以执行的细节程度，就是编程要做的事。

它出自 Robert C. Martin 在第一章写的 “There Will Be Code”。出版社于 2008 年发布的章节摘录保留了这段讨论：工具和语言会变化，需求中必须精确表达的部分仍然存在。

今天再读，很容易把它包装成“十八年前就预言了 AI 编程”。但它没有告诉我们模型能进步到哪一步，也没有给程序员的就业前景作保证。我觉得更值得讨论的是：当实现越来越容易，我们怎样知道，程序做出的决定符合自己的意图？

一个简单需求里藏着多少决定

假设我要一个小工具：“把博客文章同步发到小红书。”

找到发布入口，把标题和正文传过去，似乎就完成了。但“同步”至少留下了几种选择：全文照搬，还是保留观点、重新组织短文？代码块和链接怎么处理？博客改了错字，另一边是否跟着更新？博客已发出、小红书失败，再试一次时应该动哪一边？

两套程序都能跑，也可能都符合“同步发布”这四个字，实际用起来却完全不同。用户没说明的地方，不会因此从程序里消失，最终总要采用一种行为。

AI 能替我们作出许多合理选择。比如沿用现有按钮样式、为列表选一个常见排序，往往就能节省不少沟通。每个细节都追问，反而会让简单事情难以开始。

有些默认值却影响结果是否正确。一次发布超时，可能是没发出去，也可能只是成功消息没传回来。直接重试就可能多发一篇。这里需要查看发布记录，不能仅凭页面上的“失败”两个字决定下一步。

模型可以查记录、提出问题，也可以结合上下文处理这些情况。需要我们留意的是：它采用了哪些假设，哪些已经得到确认。一个完整的页面，可能同时包含用户明确要求的行为，以及模型自行补齐的选择。

精确性可以在使用中逐渐补齐

这不意味着让 AI 开始之前，必须先写一份覆盖所有情况的规格书。

很多问题要看到结果才会浮现。真正读一次文章，才知道摘要太长；实际点一次发布，才发现自己想先保存草稿。要求一开始就把这些全部想清楚，并不现实。

对上面的工具，我会先约定当前最重要的行为：博客保留全文，小红书使用适合阅读的版本；两边分别记录结果；一边失败时，保留已成功的内容，并明确指出哪边尚未完成。

然后做出能使用的流程，实际发一篇。碰到新的问题，再补充规则。暂时没有需要的定时发布、历史补发和复杂编辑同步，可以留到以后。

一句具体约定比“做好异常处理”更容易判断对错。例如：

博客已经发布成功，小红书发布失败时，保留博客那一份；再次尝试只处理小红书。

它既能指导实现，也能变成检查结果的例子。需求的精确程度可以随着对话、原型和实际使用提高，不必全部挤在开工前的文档里。

AI 也能帮助发现遗漏、比较方案。人需要参与多少，应当看选择的后果：留白不合适，随时可以调整；覆盖已有文章或重复发布，就值得提前说清。

“代码还在”不能证明“岗位不会变”

“系统需要精确的行为”和“每个细节必须由人亲自写”，是两个不同的判断。前一个成立，推不出后一个。

如果 AI 能完成实现、补充测试、定位错误，甚至参与需求讨论，人的工作当然会变化。至于会怎样影响岗位数量、分工和收入，需要观察现实，无法从一本旧书里得到保证。

把所有生成代码的活动都叫作编程，可以在定义上得到“编程仍然存在”的结论，却没有回答更实际的问题：人应该把时间花在哪里？

对我来说，值得练习的是看懂改动会怎样影响系统，发现需求里的矛盾，用具体例子判断结果，以及在出问题时找到原因。这些工作也会得到工具帮助，但理解它们，能让我更清楚什么时候可以放手，什么时候需要继续追问。

技术基础依然有用。知道数据存在哪里、请求在哪一步可能失败，才容易判断一次修改是否真的解决了问题。只看界面是否完整，往往看不出这些差别。

下一次让 AI 动手时，我想多做一件小事：给出一两个能判断成败的例子，然后尽快看结果。模型能自行处理的细节就交给它；实际影响使用的选择，在遇到时确认下来。

我从这段旧文字里读到的价值，也正在这里：程序会执行某种具体行为，而我们需要有办法判断，那是不是自己想要的行为。

---

原文出处：Robert C. Martin，《Clean Code: A Handbook of Agile Software Craftsmanship》，第一章 “Clean Code” 中的 “There Will Be Code” 小节。出版社章节摘录，2008 年 8 月 19 日。文中的双平台发布工具用于说明需求如何影响程序行为。