定义“Slop”：当生成速度超越判断力

Gabriel Martinez（Gabo）作为 G2I 的工程经理，愤怒地指出当前 AI 开发中泛滥的“Slop”（垃圾内容）现象。他明确界定，Slop 并非指 AI 生成的代码本身，而是指“当判断力被生成速度甩在身后时产生的后果”。这种输出看似完成，实则思考未竟；歧义通过猜测消除，权衡留给运气，所有权未被承担。真正的危险不在于机器做出了错误选择，而在于工程师从未意识到存在需要做出的选择。他们未曾触碰歧义、感受约束或发现会改变设计的边缘案例。软件是选择的记录，若工程师无法看见这些技术、产品或运营层面的选择，便无法拥有它们。此时，工程活动退化为单纯的代码合并，工程师沦为按按钮的“码农”，而非真正的系统构建者。

代码成本与理解成本的背离

尽管 AI 大幅降低了创建代码的成本，但理解软件程序的成本并未随之下降。Gabo 引用 Dystra 的观点强调：“如果我们能计算代码行数，我们不会将其视为生产的行，而是消耗的行。”AI 让团队更容易在文件、抽象层和复杂性上“挥霍”代码，但这笔账单最终由开发者承担。其后果表现为混乱、脆弱的流程以及无人愿碰的功能模块。正如那些臃肿的 B2B 软件，每个任务都需要培训，屏幕充满逃生出口，复杂性并非源于用户需求，而是团队不断堆砌的结果。好的软件具有实用性上的和谐，代码应反映领域形状。若系统本身已是“大泥球”，AI 不会将其拯救，只会更快、更大地构建这个泥球。任何一行代码都是负债，最佳代码往往是零代码。

原型幻觉与工程责任的缺失

当前趋势让任何人能在短时间内构建出可点击的原型，这扭曲了利益相关者的预期。他们看到提示词瞬间变为屏幕，便误以为最难的部分已经结束。然而，利益相关者往往忽视那些真正体现工程师价值的环节：处理非理想路径、整合新功能集、澄清需求以及确保用户体验不混乱。这些“最后一公里”的工作需要人类进行判断，包括阅读代码、测试行为、承担权衡以及决定是否将该功能纳入系统。为了遏制这种失控，必须建立问责制（Accountability）。仅仅知道有人将审查你的工作，就会迫使工程师在细节上更加专注和严谨。通过建立可见的问责指标，将工作产出与正负强化挂钩，才能确保团队对生产的内容负责，避免陷入由 AI 加速生成的混乱之中。

虚假的“免费”与激励错位

AI 代码生成并非零成本，其隐性代价由人类工程师承担。Gabriel Martinez 引用了一位资深开发者的观点：“你是在要求我为你维护它、记录它、测试它，并在未来 25 年里持续维护它。这绝不是免费的。” 这种观点揭示了外部利益相关者的压力与竞争“Slop Makers”（垃圾代码制造者）的焦虑，共同导致了团队产出的粗糙化。那些不注重细节、不细化规范的工程师往往产出更快，而严谨的开发者反而显得缓慢。这种环境引发了绩效焦虑（Performance Anxiety），迫使工程师在无法充分理解代码的情况下合并 PR。短期“快速上线”的压力压倒了长期代码健康（Code Health），导致团队陷入一种危险的激励循环：奖励机制若只关注 PR 数量而非价值创造，最终将带来灾难性的后果。真正的激励应围绕产生价值的优雅系统设计、清晰的测试与评估工具展开，而非单纯的代码行数或合并速度。

生成廉价 vs. 评估昂贵：新的瓶颈

AI 的核心影响是加速了字符和代码行的生产，但这并未真正提升团队效率。生成是廉价的，但评估（Review）是昂贵的。当 AI 产出的内容超过人类审查能力时，它没有加速团队，而是创造了瓶颈。Martinez 指出一个普遍现象：原本轻量级的需求（如几个用户旅程）被 AI 转化为冗长的文档或庞大的 PR，表面看似完成，实则将澄清问题的责任转嫁给了审查者。例如，一个模糊的任务可能变成数千行的代码 PR，没有任何人类能完全理解如此大规模变更中的所有关键细节。这种“完成感”是虚假的，因为真正的工作才刚刚开始——即审查者需要花费数小时去辨别其中是否有实质性的思考，还是仅仅用华丽的排版掩盖了模糊的逻辑。这种模式不仅没有解决问题，反而扩大了歧义，让其他利益相关者面对更大的工件去处理本应由执行者厘清的问题。

回归软件工程的“地面真理”

尽管 AI 带来了变革，但60 年的软件工程智慧并未被颠覆。Martinez 批评了当前对“代码行数”或“Token 消耗量”作为生产力指标的荒谬推崇，强调组合式代码、良好模式和扎实实践依然至关重要。有人质疑为何要关注 Agent 的代码规范，Martinez 认为，虽然 AI 抽象掉了底层实现细节（如同从机器码到高级语言的演进），但人类仍需理解系统如何 cohesive 地运作。因此，架构图和文档不再是事后的装饰，而是使系统可读性（Legible）的关键工具。通过服务边界、数据流和状态转换的图表，人类可以压缩审查表面，将实现细节推至“叶子”节点。声明式代码和分层架构模式使得人类能够专注于高层逻辑的审查，而非陷入实现的泥潭。目标不是代码生成本身，而是优化人类的认知层：保留人类的理解力、知识沉淀和最终审查权。

降低认知负荷与确立规范

认知开销（Cognitive Overhead）是工程师在做出有意义变更前必须支付的“税”，包括理解代码归属、遵循模式和确定正确实现。AI 若不加约束，会加剧这种开销：Agent 可能生成五种不同风格的合理模式，迫使审查者逆向工程其背后的意图。规范（Conventions）是解决这一问题的关键，因为明确的意图比晦涩的代码更容易被人类掌握。Martinez 强调，我们需要通过严格的编码约定、架构风格和约束条件来塑造 AI 的输出。这不仅是为了代码美观，更是为了降低人类审查的认知负担。在 Agent 能够生成海量实现细节的未来，人类的角色将从“编写者”转变为“架构师”和“审查者”。优化这一人类层，确保代码的可理解性和可维护性，是 AI 时代软件工程师的核心职责。

建立清晰的审查边界与“Done”定义

防止 AI 生成代码产生混乱（Slop）的核心策略在于建立文档化的标准流程、缩小可审查的代码范围以及明确的所有权边界。当代码变更的路径足够清晰时，低质量代码便无处藏身。这种对确定性的追求并非空谈，而是需要落实到具体的工程实践中。明确的“完成”定义（Definitions of Done）是确保产出物符合预期的关键，它要求团队在代码进入主分支前，必须经过严格的规划、审查和对抗性检查。

"Standards documented flows, small reviewable surfaces and clear ownership boundaries and definitions of done."

这一理念强调，审查面的缩小（Small reviewable surfaces）能显著降低认知负荷。如果每次 AI 生成的代码都涉及庞大的架构变更或模糊的责任归属，人类工程师将难以有效审查。因此，必须通过流程设计，确保 AI 的输出是小粒度、可追溯且责任明确的。这种结构化方法不仅适用于人类协作，也为后续引入 AI Agent 奠定了基础——只有当输入和输出的边界清晰时，自动化才能在不牺牲质量的前提下发挥作用。清晰的边界是抵御技术债务的第一道防线。

Rails 范式：通过约定减少决策面

在探讨如何降低工程复杂度时，Rails 框架及其“约定优于配置”（Convention over Configuration）的理念具有极高的参考价值。Gabriel Martinez 特别指出，Rails 的价值在于它激进地减少了决策面（Decision surface）。当框架通过约定消除了大量重复性选择时，开发者不再需要为同一概念寻找十种不同的结构方式，而是统一使用一种被广泛理解且有效的方式。

"Rails matters here because it shows what happens when a framework aggressively reduces decision surface."

这种认知开销的降低（Reduction of cognitive overhead）带来了显著的长期收益。作者分享了自己的职业经历：在两次使用 Rails 的四年间隔后，他重返项目时能够立即理解代码意图，无需重新解析架构。这是因为事实上的标准库（De facto libraries）和模式保持一致。这种一致性使得工程师能够在不同项目间横向移动，最小化上手成本（Minimal ramp up）。相比之下，JavaScript 等生态系统中存在多种竞争方案，导致 Agent 在开发时容易因选择过多而困惑。单一的正确做事方式对于 Agentic Development（智能体开发）至关重要，因为它消除了歧义，使自动化流程更加可靠。

ORC 的诞生：从对抗 Slop 到保留人类判断

基于上述对流程标准化和约定重要性的理解，团队构建了 ORC（Orchestration）系统。这并非因为相信“更多 Agent”能解决所有问题，也非认为工程判断可以被完全自动化。ORC 的诞生源于反复观察到的失败模式：AI 能够生成代码，但周围缺乏必要的纪律性——包括规划、审查、对抗性检查和上下文管理。团队发现，自己不得不重复执行人类流程来抵御低质量代码：分解工作、管理上下文、权衡选项，并确保输出以团队仍可推理的方式进入代码库。

"ORC is taking those lessons and baking them into the workflow."

因此，ORC 是一个保留人类责任并让 Agent 承担更多繁重工作的系统。它不是消除正确性责任的魔法盒子，而是将纪律内嵌到工作流中（Baking discipline into the workflow）。其目标不是发送更多生成的代码，而是确保在生成发生后，软件依然保持连贯性、可测试性、可维护性和所有权明确。未来的方向不是“氛围编码”（Vibe coding）得更快，而是带有判断力的编排（Orchestration with judgment）。正如演讲结尾所言：“不要变得随意”（Don't get sloppy），在享受 AI 效率的同时，必须坚守工程严谨性。

结论

生成廉价而评估昂贵，AI加速了代码生产却未降低理解成本。若缺乏纪律与规范，将导致技术债务激增、认知负荷过载及责任缺失。核心优势在于提升生成效率，短板在于人类审查瓶颈与质量失控风险。

解决方案并非依赖更多Agent，而是通过ORC系统将工程纪律内嵌工作流。依托Rails式约定减少决策面，明确审查边界与“完成”定义，缩小可审查范围。唯有保留人类判断力、所有权及最终审查权，在标准化约束下发挥AI作用，才能避免陷入Slop陷阱，确保软件系统的可维护性与长期健康。