企业官网建设流程全解析

有人在社交平台上说，人类永远写不出比LLM更好的代码，接受这个事实，别再假装了。这句话里藏着太多没明说的“更好”。LLM被训练来生成看起来合理的内容，而不是正确的内容。你可以让它写出很优雅、很地道、很流畅的代码，同时却漏掉真正重要的约束：现有系统怎么运作、团队有哪些习惯、业务上有什么考虑、失败模式是什么、哪些功能还没实现。

资深工程师的工作不只是“写”代码，还包括知道什么时候不该写。识别真实的边界情况、判断抽象是否成熟、看出一个问题其实可以更简单地解决或者根本不值得解决，这些判断很难量化，也很难通过提示词获得，而且在一个生成出来的方案里往往并不明显。所以，LLM可以是个顺手的工具，但离真正的人类专家还差得远。

那条推文里最让我不舒服的词是“更好”。我们习惯把“更好”当成一个标量，好像只有一个数值能定义它。可当你追问“更好”是在哪个维度上衡量时，问题就来了：每分钟产出行数？正确性？可维护性？还是有勇气决定不构建这个东西？你会很快发现，衡量的维度不同，“更好”的意思就完全不一样。

最直观的指标是每分钟产出行数，简单、好测，而且给人一种在进步的感觉。但它衡量的只是打字速度，不代表产出的程序更好。一千行错误的代码比没有代码更糟；一千行一碰就碎的代码比那还糟。

于是我们转向正确性。代码之所以更好，是因为它正确：功能对、符合规格、能通过测试。这是进步，但还不够。真正的噩梦是LLM生成的代码在崩溃之前一直能跑，而你根本看不懂它为什么能跑。一段看起来合理的代码混进了生产环境，支付管道突然开始悄悄丢弃交易，因为模型自作主张给事务处理函数加了个装饰器，捕获异常、记日志、然后返回空。下游代码把空当成零美元的成功扣款，客户没付钱就拿到了商品。

Gramli在《To Retry or Not to Retry》里测试过类似情况。一个场景中，支付请求返回503并带有Retry-After头，但没有幂等键。八个模型里有六个遵循响应头建议重试，只有两个说不要重试。

HumanLayer的Dex在演讲《Harness Engineering Is Not Enough and Why Software Factories Fail》里解释了原因：很多编码基准只给模型通过或失败的奖励。测试过了就算赢，设计好坏没有任何惩罚。于是模型学会了加try/catch或者类型转换，因为这样能让测试通过。

我们可能得到一段本身能跑却无法修改的软件。这恰恰是我们最不想要的东西，这就是遗留代码，很糟糕。我们需要的是能够无痛修改。

所以下一个维度是可维护性。可维护的代码可读、简单，不会让人想砸办公室。它不会随着时间推移而崩坏，能适应新需求和变化而不被打破。

最后一个维度，也是最好的，是智慧。这种“更好”让我们能说“不，我们不该做那个”。它更好是因为它更少，但必要。代码是负债，应该保持在最低限度。这种“更好”最难实践，需要对压力说不，对预算说不，对自认为有好想法的利益相关者说不。它是一种少即是多的指标，但不构建东西所带来的复利会持续增长。

所以“更好”不是一件事，而是多个层次，并且随着经验增长而变化。我们从每分钟行数，走到正确性，走到可维护性，最后走到不构建。