设计与判断：不会过时的地基

一、那个问题不是修辞

2026 年春季学期，UCB CS61B 的最后几周，代课的是 Stella Kaval。她 2025 年本科毕业，做过这门课的助教，当时在 Meta 写代码。

课上她放了一段演示。屏幕上是命令行，她敲了几句，终端开始滚，最后弹出一个页面：一个邮箱输入框，一个密码框，一个按钮，间距和圆角都还算像样。整个过程十几秒。

然后她问：既然十几秒就有登录页了，为什么还需要你来规划？

教室里笑了一下。她没笑。

我后来想，这个笑是因为大家把它当成了修辞。可它不是。它问的是"那我还剩什么"，而且它带一个陷阱：如果答案是"AI 还不会做某件事"，这个答案就有保质期。今天不会的，明年大概率会了。

所以得换个问法。不问 AI 缺什么，问工程这件事里，哪一部分本来就不是"写"。

写只是最后一步。前面还有两段：决定要造什么，确认造出来的东西对不对。这两段不在"实现"的范围里，也就不会因为实现变便宜而消失。

手写代码的那些年，慢是常态。

一个类名想不清楚，敲到第三行就卡住，光标停在那里，逼你回去想这个名字到底该叫什么。一个边界条件没考虑到，写到 if 的时候就露出来了。这些卡顿很烦，但它们有用：机器不接受含糊，含糊的地方一定会被撞出来。

现在这层摩擦没了。你把想要的东西说个大概，材料就送来了。

采购本身没什么问题。有问题的是采购员的心态。手艺人有手感，一块砖拿在手里知道什么分量；采购员只看清单，清单上写漏了一项，他不会知道。而清单恰恰是最容易漏的。

非目标那一栏我一直觉得最难写。写着写着就想把可能性都留着，结果一条也没排除掉。等到模型照着这份文档做，它会把留着的可能性全做出来，一个不落。

含糊的代价没有消失。它只是从"编译不过"挪到了"看起来能用但其实不对"，而后者贵得多，因为它不会当场报错。

"做一个好看的登录页"，这不是需求，是愿望。

设计做的事很朴素：把愿望翻成能被检验的句子。谁能用，在什么场景下用，什么算成功，失败了怎么办。翻到这一步，话才落地。

那个演示里的页面就是个好例子。它确实能跑：输入框能输入，按钮能点，样式也不难看。可它不知道谁来用。没有手机号登录，没有找回密码，密码输错了只在控制台留一行红字。这些都写在"登录页"这三个字外面，但在真实需求里，它们比圆角和间距要紧得多。

这件事跟画架构图、套模板、走评审流程都没什么关系。一份文档哪怕只有半页，只要每句话都能被人指着问"凭什么"，它就是合格的；反过来，格式齐全、每句都正确、但一句都没法验证的文档，等于没写。

真正起作用的那一条，通常是"这次不做什么"。人的默认倾向和模型的默认倾向是一样的：多做一点。多出来的部分没人要求，也就没人验收，最后变成要维护的东西。写清楚这次不碰哪里，比写十行要做什么更能限制住范围。

还有一层作用容易被漏掉：设计文档同时是给模型的上下文。话说不清，它只能猜。猜出来的东西往往看着合理，但跟你要的那个东西没关系。

她还问了一个问题：代码是模型写的，测试也是模型写的，两边都过了，能不能上线？

这听着像个技术问题，其实是认识论问题。自己出题，自己答题，自己判卷，考了满分，能证明什么？只能证明这套卷子和脑子里的答案一致。至于脑子里的答案对不对，这套卷子问不出来。

模型写实现的时候，对需求有一份理解；写测试的时候，用的还是那一份。两边对得上，几乎是必然的。它们对得上的是同一个可能错的理解，而不是需求本身。

所以判断不能从生成过程里长出来。它得从别处来：真实用户怎么用，另一个人怎么看，上线之后出了什么事。这些都算外部信息，也是唯一能证伪的东西。

那些看起来冗余的工程规矩一直没被淘汰，原因也在这里。换个人做评审，测试写在使用之前，留一条端到端验证，本质上都是在造一个独立的信息源。以前这么做是因为人也会犯同样的错；现在这么做，是因为机器犯错的成本更低了。

如果设计与判断只是"AI 暂时还不会的事"，那它们迟早会被替代，说成地基就是自我安慰。所以得说清楚：它们的稀缺跟模型会不会做没关系，跟它们站在哪儿有关系。

最直接的一条是目标。模型能在给定约束下找解，但约束从哪来？要不要做这个功能，出问题的时候宁可少赚还是多赔，性能差一截能不能接受。这些算不出来，只能排。任何优化器都需要一个外部给的目标，目标本身没法由优化器产生。

再往下是责任。事故复盘的第一个问题永远是"谁决定的"。模型可以生成方案，但没法成为被追问的那个人。一个没人能解释清楚为什么这么改的系统，改不动，也长不大。

还有一条更现实：选项越多，选择越贵。生成变便宜之后，方案从一个变成一堆。选的成本没降，反而因为待选项变多而变高。这时候更快的生成帮不上忙，有用的是更清楚的判据。

关于目标那条，我偶尔会怀疑：如果模型足够强，能不能自己生成目标？我暂时想不出它为什么不能，但也想不出它为什么要。目标总得有个来源，而这个来源目前只有人。这一点我没想透。

有一种乐观很常见：等模型再强一点，这些麻烦就自然没了。

我觉得方向可能相反。模型越强，越会忠实地执行你含糊的意图。它不会替你纠偏，它会把偏差执行得更完整、更快、更像那么回事。以前含糊的代价是一个跑不起来的程序，现在含糊的代价是一个跑得很好但做错事的系统。

所以"提示词技巧"的收益会饱和，而"把目的想清楚"的收益不会。前者是在让表达更顺，后者是在让目的更明确。表达可以练，目的不行，它只能靠想。

回头看那个演示。它展示的是能力的上限，不是工程的上限。工程交的从来不止一个能跑的页面，还得有人要、出了事能查、过半年还改得动。演示里省掉的那部分，恰好是让它成为工程的部分。

设计与判断不会因为模型变强而过时。把它们当成还没被自动化掉的残留工序，是看错了位置：它们是自动化成立的前提。

写到这里我发现，我其实没有回答她那个问题。她问的是为什么还需要你规划，我给的理由都是规划很重要。这两件事并不完全一样，中间缺的那一步是：不规划会怎样。

大概会是这样：你会得到一个能跑的登录页，然后在某个下午，有人问你为什么这个页面不能改密码，你答不上来。

她讲完这一页就翻过去了。后面还有压缩，还有课程总结。