代码库里一直都有 slop

读 Lauren Tan（@poteto）今天的一条长帖：拿“AI 代码是垃圾”来拒绝 agent，站不住；真正的新手艺，是让 agent 写出平均更好的代码。

2026 年 10 月 11 日7 分钟读完原帖与评论来自 X

TL;DR

真正的 Good Code 一直很贵，绝大多数软件本来就是拿一些 bug 换速度，靠测试和线上监控兜底。agent 写不出 Good Code，但能把规模化的平均质量拉高——前提是验证跟得上。

01她在说什么

这条原帖发于 10 月 11 日下午 1:35（AEDT）。截至抓取时，有 2350 个赞、957 个收藏、165 条回复、47 条引用。开头一句就是结论：

codebases have always contained slop.

她的理由是，除了嵌入式这类“只有一次机会”的硬软件，代码很少需要完美。软件一直在变：用户口味在变，团队对问题的理解在变，功能来来去去。她也承认，2024 年前后她和很多老程序员一样，怀疑 agent 能不能写生产代码，担心“漂亮的代码库”被弄脏。

但她接着说，人写的 slop 一直很多。很多人口中的 slop，其实就是“不是我写的代码”。她甚至说 99% 的人（包括她自己）都不清楚 Good Code 长什么样，更写不出来。

02Good Code 为什么贵

她给 Good Code 下了一个很硬的定义，三条要同时满足：正确、没有 bug、跑起来快且省钱。长期以来，没有便宜的办法形式化地保证代码同时具备这三点，所以写“硬软件”格外贵——你必须一开始就做对。

大部分软件不需要做到这一步也能给用户带来价值。行业的做法是接受一些 bug 来换速度，用测试和可观测性（o11y）兜底，走增量迭代。她认为这是好事。

图 1质量越接近 Good Code，成本越陡；agent 不改变这条曲线的尽头，而是把大量“够用”的代码整体往上推。示意图，不是真实数据。

03agent 改变了什么

她的判断是：agent 让我们更快，而且只要你愿意，它能帮你写出更好的代码。不会是 Good Code（那仍然昂贵），但在规模上，平均会好很多。

结尾她把话说得很直：搞清楚怎么做到这一点，就是软件工程的新手艺，“现在这就是你的工作”。如果用不用 agent 产出差不多，说明你做错了什么；但现在开始学还不晚，就当是一棵全新的技能树。

04评论区怎么说

引用和回复里有赞同，也有不少有分量的反对。挑几条：

Programming is art the same way painting is art. Sometimes you need to draw a hyperrealistic portrait. And sometimes you just need to paint a wall white.

赞同@ChShersh 的引用：不是每段代码都要当艺术品。

yes, there was always slop. but it was owned by a human. that human was responsible for it. and tried to do better next time.

反驳一条引用：问题不在有没有 slop，而在谁为它负责。

Code quality is a continuum … I guess the concern is whether swes are able to determine what is appropriate where

补充@efexen 的回复。另一条引用说法类似：新技能是知道每个功能到底需要多少正确性。

Saying it’s fine to include slop might give the impression that sloppy engineering is ok, even though those are two different ideas.

担心@zbdel08 的回复：担心的是态度被带偏。

make it write the test first and watch it fail. A test that never failed proves nothing.

落地@boriskwemo 的回复：先让测试失败，再读 diff 看测试看不到的东西。

05怎么让“平均更好”成立

把赞同和反对放在一起看，分歧其实集中在一点：agent 写得多、写得快，谁来确认它是对的。“平均更好”不会自动发生，它要靠一套验证优先的流程撑起来：

写的人不验收自己的活。写代码的 agent 和审代码的必须分开。
合并前要有证据。CI 绿了、测试先红后绿、审核意见留在 PR 上，而不是一句“我检查过了”。
按风险分级。改规矩、改核心路径的，要更多人审；涂白墙的，自动检查就够了。

图 2验证优先：写的人只负责产出，证据由别人和机器给出，齐了才合并。示意图。

这其实就是 poteto 所说的新手艺的一部分：不是放手让 agent 乱写，也不是把它挡在门外，而是让每一次合并都有可检查的证据。Joye 这边的 PR 规矩——写的人不自审、两位审核、CI 先绿再合——就是同一件事的小规模版本。

06放到 Joye 这边看

Joye 现在的做法几乎就是这篇帖子的一个小样本。他的工作室 Joye & Co. 由四个 bot 分工，从 10 月 11 日起，所有代码都交给 Cursor cloud agent 写，bot 只写任务说明和审结果，Joye 自己只做最后一步：点合并。

让“平均更好”成立的，是团队共享仓库 co-context 里的一层仓库级 harness：

CI 自动检查 PR 标题前缀、只改自己的目录、共享文件必须写“为什么”，并用 gitleaks 扫密钥；
写的人不自审，至少另一个 bot 审过；改规矩的 PR 要两个不同的 bot 审过；
审过之后再推新提交，之前的审核自动作废。

当天就有一个现成的例子：一个 PR 在 rebase 之后悄悄丢了一处改动，第一位审核者（Pocket）没看出来，第二位（Tata）对照 CI 规则发现了。没有哪一环是完美的，但多一道独立的验证，slop 就进不了 main。这正是 poteto 说的新手艺：不追求每一行都是 Good Code，而是设计一个让错误大概率被拦下的流程。

留给 Joye 的一个开放问题：现在合并仍然靠他逐个点确认。等审核和 CI 足够可信，哪些 PR 可以放心让流程自己合，哪些必须留在人手里？