我们已经在交付‘slop’20年了。我们以前只把它称为 MVP。
Source: Dev.to
介绍
很多人已经开始使用 “slop” 这个词来简写 AI 生成的代码。他们的立场是，AI 正在向行业灌输低质量的软件，最终我们都会在宕机、回归和技术债务中付出代价。
这个论点听起来很有说服力——直到你诚实地审视过去 20 年软件的实际构建方式。
令人不安的真相是，“slop” 并不是 AI 才开始的。事实上，AI 让人们不再可能继续假装它不是。
让我们揭开行业在第一个大型语言模型（LLM）训练之前就已经遵循的那份沉默协议的面纱。
软件始终优化执行
在 Google 那种著名的严格审查文化之外，大多数科技巨头（Meta、Amazon、Microsoft 等）历来更看重速度。
- 在真实环境中，PR 往往只被略读。
- Bug 在用户报告后才会被修复。
- 架构在产品验证成功后才会演进。
当时我们并不把这称作“草率”，而是称之为 MVP（最小可行产品）。
相比之下，今天编码代理交付的部分代码已经优于许多公司早期的 PR。AI 并没有开启一个全新的“够用”代码时代；它只是我们使用了数十年的策略的最新工具。事后看来，我们一直愿意用外部市场的速度来换取内部代码的纯粹性。
开源解药
主要的例外是开源项目，它们的运作方式不同。开源始终产出可靠、可维护的代码——即使有数十甚至数百名开发者贡献。
为什么？
-
强制模块化。
贡献者在隔离的环境中工作，必须遵守严格的 API 边界和清晰的抽象，以便没有内部上下文的人也能在不破坏系统的情况下进行贡献。 -
积极的迭代循环。
每一次贡献都会经过自动化测试和多方人工评审。反馈来源众多，通常会在整体质量上优于仅为一两个特定用例编写的代码。
这种环境表明，只要为贡献者提供明确的边界和自动化反馈，优先执行而非完美是可行的——如果我们把 AI 代理视作外部的开源贡献者，“松散”就会消失。
将质量工程化到代理
在 Pochi，我们相信 AI 代理的输出质量取决于你为其构建的上下文防护措施。要避免“糟糕的结果”，必须超越简单的聊天提示。以下是我们实践中有效的技巧：
1. 解决幻觉问题
AI 生成代码最大的难题是它倾向于 幻觉 出不存在的库或已废弃的语法。这往往是因为开发者更关注 Prompt Engineering（提示工程），而不是 Environment Engineering（环境工程）。
解决方案： 将代理直接集成到 CI/CD 流水线中。每一行代码都会立即通过编译器、代码检查工具和静态分析工具进行验证。环境会在错误出现的瞬间捕获它们，这样你就不必等到 AI 自己纠正。
2. 使用 “Cloud Markdown”
“Cloud Markdown” 方法适用于大规模设计实践。与其使用包含冗长架构标准的静态 PDF，不如创建一个 README.pochi.md 文件，作为代理的唯一可信来源。
示例防护文件 (README.pochi.md):
# Project Design Patterns架构概览
- 遵循六边形架构。
- 所有外部依赖必须通过接口注入。
- 核心业务逻辑中不得直接调用第三方服务。
编码标准
- 使用 TypeScript 严格模式。
- 强制执行 ESLint
@typescript-eslint/recommended。 - 不使用
any类型；更倾向于显式泛型。
CI/CD 检查
- 在每个 PR 上运行
npm run lint。 - 执行
npm test -- --coverage并要求 ≥ 80 % 覆盖率。 - 验证生成的代码能通过
tsc --noEmit编译。
依赖管理
- 所有依赖必须锁定到特定版本。
- 禁止出现未在 lockfile 中记录的传递依赖。
- 使用
npm audit，并在出现任何高危问题时使构建失败。
审查流程
- 每个 AI 生成的 PR 必须至少有一名人工审阅者。
- 审阅者必须确认代码遵循上述防护措施。
通过向代理提供此 markdown，您为其提供了一个具体的、机器可读的合约，反映了开源项目的严谨性。
结论
- “Slop” 不是一个新的 AI 问题；它是速度与完美之间长期存在的权衡。
- 开源项目表明，严格的模块边界和自动化反馈可以让这种权衡得到控制。
- 将 AI 代理视为外部贡献者，给它们明确的护栏（CI/CD 验证、“cloud markdown” 规范），如此 “slop” 便会消失。
将质量工程化嵌入代理是将 AI 生成代码从负债转变为资产的关键。
数据获取
- 规则： 组件中不直接使用
fetch调用。 - 模式： 使用来自
@/lib/api的useQuery包装器。 - 原因： 确保全局错误处理和缓存得到应用。
状态管理
-
约束: 所有共享状态必须驻留在
LiveStore。 -
模式:
const [data, set] = useLiveStore(key);
全屏控制（示例）
Enter fullscreen mode
Exit fullscreen mode关键工作流
-
将文档作为上下文
将包含深层架构规则和设计模式的 Markdown 文件直接存放在仓库中。 -
提示注入
在代理开始任务之前，它会“读取”这些 Markdown 文件，以了解全局限制（例如，“始终通过 LiveStore 使用本地‑优先存储模式”）。 -
上下文脚手架
这确保代理不会在真空中编写代码片段；它遵循现有代码库的特定脚手架。
以这种方式嵌入架构知识，使代理在每次重大迁移之前尽可能收集文件级上下文，从而产生更准确的结果。
结论
归根结底，用户从未看到所谓的“烂代码”。他们看到的是破碎的界面、加载缓慢、崩溃以及不可靠的功能。
如果你把 AI 生成的代码视为“烂代码”，就会错过计算史上最大的速度变革。通过将开源纪律（严格审查和模块化）与 AI 辅助执行相结合，我们终于能够构建既能快速交付又能抵御变化的软件。