10 个关键问题 Q&A
- 什么是 Anti-slop 软件工厂？
一套面向 AI 智能体协作的代码交付体系，核心目标是阻止 AI 持续产出粗糙劣质代码，保障大规模跨职能团队稳定交付。 - 为什么说仓库才是软件工厂，Agent 不是？
Agent 只是执行代码编写的工具；仓库内置 CI、Lint、类型、测试等硬性约束，这套基础设施才是保障代码质量的工厂本体。 - Slop（劣质代码）最大危害是什么？
劣质代码会不断累积，形成指数级恶化；仓库越乱，AI 产出代码质量越差，评审变慢、交付持续降速。 - Co-location 代码就近组织的作用？
减少 AI 检索文件的开销，避免上下文被大量文件检索信息污染；一个功能组件、工具、测试放在同一目录，也方便评审范围把控。 - 作者为什么禁用 lib、utils 文件夹？
通用工具文件夹会造成文件分散，AI 需要遍历大量目录检索代码，消耗大量上下文，更容易写出错误实现。 - 为什么优先 Lint 规则，而不是给 Agent 写技能指令？
AI 容易无视文本指令，技能提示词容易随模型迭代而过时；Lint 可以立刻检测违规并给出修复方案，形成闭环约束。 - 作者对代码复用的独特观点？
业务场景代码允许复制重复，不用强行抽象共享组件；按钮、设计令牌这类全局基础组件必须统一，并由 Lint 强制管控。 - Bugbot 在整套体系里放在什么位置？
后置使用，不能替代 Lint 与单元 / E2E 测试；适合处理无法用静态规则检测的复杂缺陷，缺点是误报率高、闭环慢。 - 为什么 CI 速度至关重要？
市场等非开发人员不会搭建本地环境，全程依赖预览部署；CI 构建与检查就是他们完整开发反馈链路，慢 CI 会直接阻断工作流。 - Zen 云端智能体的核心价值？
可多渠道触发，通过 Composio 安全对接日志、工单、用户会话等外部系统，补齐业务上下文，自动完成大量 PR 合并。
最近我发布了一则视频，分享了一套实战方案：搭建一套软件工厂，让大型团队（工程师、产品、市场人员都可以使用各自的个人 AI 智能体）持续向生产环境交付可靠代码，收到了很多关注。因此我写了这篇博客版，方便不爱看视频的朋友阅读。
我是 Sarah，在 Composio.dev 负责产品工程。今年 2 月，我从零搭建了 dashboard.composio.dev 项目。当时 Claude Code 刚爆火，我专门面向 AI 智能体设计了这个代码仓库。 如今这个项目已有近 50 名贡献者，横跨工程、市场、产品岗位。我可以很确定地说：绝大多数代码变更都能一次提交通过，代码评审也变得非常轻松。
劣质代码会不断累积恶化（Slop Compounds）
大家听过不少 “软件工厂” 的定义。很多人会联想到 AI 智能体集群、看板。 现在很多软件工厂面临一个核心问题：劣质代码会指数级累积放大。 如果云端智能体在一个本身就充斥劣质代码的仓库里工作，相当于让它基于烂代码做方案、按烂方案实现，最后再自查自己产出的烂代码。 大规模反复使用云端智能体时，劣质问题会呈指数级恶化。
在我看来，这算不上合格的软件工厂。代码变更的评审周期越来越长，团队交付速度持续下降。
AI 智能体 ≠ 软件工厂
我的理解是：优秀的软件工厂，核心不在于智能体、执行框架、技能集。真正的工厂就是你的代码仓库本身。 仓库内置整套机制：CI 流水线、Lint 校验规则等等。目标是：任何人都可以接入自己的个人 AI 智能体，不管它用什么框架、什么大模型；仓库要做到让智能体几乎不可能写出坏代码。
这是一个很高的目标，下面是我落地的 7 项核心实践：
1. 代码就近组织（Co-location）
这一点最容易被忽视，我很少看到有人讨论。 AI 智能体写代码前，会遍历、检索仓库理解项目结构。文件越分散，智能体检索工作量越大，上下文窗口越容易被无效信息占满。如果一个功能的所有代码都放在同一个文件夹里，智能体一定能找到它。 Next.js App Router 的模式对我们帮助巨大：一个路由模块拥有自己的组件、工具函数、测试代码，所有相关内容和业务代码放在一起。就近组织还有一个巨大好处：评审 PR 时，可以一眼看清这次修改影响的范围。 我非常认同这个原则，直接在项目里禁用了 lib和 utils通用工具文件夹。
2. 端到端类型安全
类型定义要贯穿全链路。 我很推崇 tRPC 和 OpenAPI。一旦数据结构（schema）发生变更，编译器会直接告诉智能体，哪些地方需要同步修改。
3. 允许代码重复（Duplication is OK）
这是我最有争议的观点，也是代码就近组织得以落地的基础：允许代码重复。 Tailwind CSS 已经证明了这件事：我们不再编写大量复用样式类，而是直接在代码里写样式，完全可行。现在代码生成的成本也极低。同一个工具函数，生成两份完全没问题。 比如确认弹窗这类组件，没必要强行封装成全局共享组件。直接复制，按场景单独处理交互体验即可。
当然有例外：全局基础组件（按钮、设计令牌等）需要统一复用，并且要用 Lint 规则强制约束。
4. Lint 规则优先，而不是技能指令（Skills）
为什么不靠技能指令？ 技能指令只是一段文字说明，但 AI 智能体经常无视指令。你要预设：写在技能里的任何规则，迟早会被某个智能体打破。 而且技能指令很容易过时。模型持续迭代，旧模型踩的坑，新模型不一定会踩。我们仓库里写过的所有技能指令，最后都会变成技术债，或者占用智能体上下文的负担。
你会发现我一直在强调 Lint 规则：主题规范是 Lint 规则、全局组件规范是 Lint 规则、禁止 lib 文件夹也是 Lint 规则。 技能只能告诉智能体 “有这条规则”；Lint 规则能立刻指出智能体哪里违规，并且给出修复方案。这个闭环，不仅作用于你的智能体，团队所有人的智能体都会受到约束。
我们的后台项目现在有 38 条自定义 Lint 规则。每当智能体写出错误代码，我们就新增一条 Lint 规则堵住这类问题。 也不需要全部自己手写。React Doctor 项目可以自动检查 React 最佳实践；还有一批防劣质代码项目，可以识别 AI 智能体高频写出的反模式，我很看好。
我对 Lint 规则执行得非常严格：项目里直接禁用 useState、useEffect。智能体如果非要使用，必须写注释说明理由，证明无法使用仓库已有的 TanStack Query、react-hook-form、nuqs 等封装钩子。
5. 端到端测试
很多人会想到让 AI 智能体自我校验，但我优先选择全局生效的方案：端到端测试。 我们在试用 Meticulous.ai：录制预发布环境的真实操作会话，反复回放，对比页面视觉差异。 同时使用 MCPJam/inspector，针对 MCP 服务器做 MCP 协议测试。
6. Bugbot（缺陷机器人）
完成上面这些之后，再考虑 Bugbot。 很多团队过度依赖 Bugbot。它误报率高，修复闭环的速度远慢于 Lint 规则。它适合处理那些无法用确定性规则检测的复杂缺陷。 Cursor 的 Bugbot 思路我很喜欢：把团队最佳实践录入 Bugbot，相当于在每一条 PR 上强制运行一个子智能体做复审。
7. 极速 CI 流水线
最后一点，同样容易被忽略：保持 CI 足够快。 我们不会给每一位市场人员配置本地开发环境。他们全程使用预览部署环境，构建与自动化检查就是他们完整的开发闭环。 迁移到 Blacksmith.sh 之后，效率提升巨大：部分检查耗时缩短 50%，有些甚至减少 70% 以上。
8. 云端智能体（放在最后）
只有仓库基础设施全部就绪，才轮到搭建云端智能体。 我们自研了内部智能体 Zen。可以通过 Slack 消息、Linear 工单、Datadog 告警、定时任务触发。从 2 月至今，Zen 已经在所有仓库合并了 1300 多条 PR；仅 9 月就合并 245 条。
这类云端智能体的核心价值，是通过 Composio 获取各类业务上下文：读取 Datadog 日志、PostHog 用户会话、Linear 工单，调试能力很强。依托 Composio 托管鉴权，智能体可以安全访问这些外部系统。你只需要给出模糊的需求，它就能检索各类业务信息，快速对齐上下文。
这，就是软件工厂
希望我的这些实战经验能给你启发，你也可以在自己的软件工厂里尝试落地。 文中提到的所有工具都没有赞助，是我们真实在用且验证有效的方案。大家有问题可以在评论区提问。
关键术语注释
- Slop
原文核心词，指 AI 产出的敷衍、粗糙、低质量代码 / 内容，译作「劣质代码」；anti-slop = 防劣质代码 - Software factory
软件工厂，指由 AI 智能体参与、标准化、自动化的软件交付体系 - Co-location
代码就近组织，功能相关文件同目录存放 - Lint rules
代码静态校验规则 - Skills
给 AI 智能体的文本指令 / 技能提示 - End-to-End tests(E2E)
端到端测试 - Bugbot
缺陷检查机器人 - CI
持续集成流水线 - PR
Pull Request，代码合并请求 - MCP
Model Context Protocol，模型上下文协议 - Preview deployment
预览环境部署