AI时代的开发范式：ABS

观点

目前关于 AI 编程，大致有几种不同的观点：

不相信 AI，只把 AI 当作代码生成器使用。生成一些片段代码后复制到项目中，开发流程依然和过去完全一样。
100% 相信 AI，采用纯 Vibe Coding 模式。完全不看生成后的代码，只不断补充网上搜集来的最佳实践和更细致的验证条件。只要验证条件通过，再加上足够多的最佳实践约束，就能够得到可用的项目。
半相信 AI。把写代码的工作完全交给 AI，但不相信 AI 能做好设计或者测试。因此自己通过 Ask 模式参与设计，或者让 AI 搭建测试脚手架，再由自己完成测试工作。

那么，究竟哪一种才是正确的方向？

迷思

在这个时代，随着 Loop Engineering 的出现，源代码似乎已经不再属于程序员。UI 界面似乎不再属于设计师，测试脚本似乎不再属于测试人员，甚至连需求文档也开始不再完全属于产品经理。

但与此同时，完全没有人类参与的情况下，又很难真正做出一个可用的产品。那么留给人类的工作究竟还剩下什么？人脑与模型之间真正的 Gap 又在哪里？

新的范式

从电路板到集成电路

我大学学的其实不是计算机，而是电子工程。最早的电路设计是在电路板上手动焊接各种元器件，包括三极管等具备一定逻辑能力的器件。后来随着集成电路的诞生，这些底层逻辑逐渐被封装起来。工程师只需要编写 HDL 代码，就能自动生成复杂的电路结构。

没有人再关心某个晶体管究竟是如何连接到另一个晶体管的，我们的思维开始向更高层次迁移。关注的不再是元器件之间的连接方式，而是更抽象、更高层级的问题。

从代码到 ABS

ABS是什么

ABS，全称 Agent Behavior Specification。

你在项目中看到的 AGENTS.md、CLAUDE.md、MEMORY.md 等文件，本质上都是用于规范 Agent 行为的文件。它们都属于 ABS。

如何实践

工程师的工作不应该是一行一行地写代码，也不应该是一行一行地审查代码。当然，也不是完全不关心 Agent 的实现过程，只看最终结果。工程师依然需要保留对细节的掌控能力，你仍然会在项目初期或者某个特定阶段深入审查代码。

但这件事的性质已经发生了变化。过去审查代码是为了交付产品，现在审查代码则是为了校准 Agent。你看完之后，不再第一时间去修改代码、文档或者配置，而是去思考：为什么 Agent 会这样做？它缺少了什么规则？哪些经验应该被沉淀下来？

随后，让 Agent 自己去完成修改，而你负责总结规律，并将其写入 ABS。例如：

可以改进的地方写入最佳实践，例如 BEST_PRACTICES.md。
不应该再犯的错误写入禁令，例如 NEVER.md。
项目架构的调整写入架构定义，例如 ARCHITECTURE.md。
其他长期有效的规则继续沉淀到对应的 ABS 文件中。

因此，在 AI 时代，工程师最重要的产出不再是代码本身，而是 ABS 文件。ABS 才是新时代的源代码，而代码只是 ABS 的编译结果。

单文件 vs 多文件

ABS 文件到底是一个 CLAUDE.md 或 AGENTS.md 就够了，还是应该拆分成 ARCHITECTURE.md、STACK.md、NEVER.md 等多个文件？社区已经出现了很多不同的规则文件组织方式，那么哪一种更好？

当我们把 ABS 视为新时代的源代码之后，这个问题其实很好回答。

第一，哪种颗粒度更好？答案是多文件。原因和传统软件工程完全一样：职责划分更清晰、更适合多人协作、更容易维护、更容易定位问题，同时也能够减少代码冲突。

第二，哪种命名规范更好？是叫 STACK.md 还是 ARCHITECTURE.md？其实并不重要。就像今天的软件开发一样，重要的不是文件名本身，而是你是否完成了合理的职责划分。你需要知道哪些内容属于架构层，哪些内容属于最佳实践层，哪些内容属于禁止事项层。至于具体文件叫什么名字，并不是关键，关键是这种组织思想。

工作场景

那么，AI 时代的工程师究竟应该如何工作呢？下面这个例子或许能帮助你感受未来的软件开发方式。

Tom 早上 9 点来到公司，泡了一杯咖啡，准备开始一天的工作。

编排面板

他打开 Agentic Development Workflow 面板（这个名字已经长到不需要解释它是干什么的了）。

首先查看各个 Agent 的工作状态。哪些 Agent 被 Block 住了？哪些 Agent 昨晚又提交了多少个 PR？哪些 Agent 的效率明显下降？这些信息会成为他一天工作的起点。

编辑 ABS

随后他发现一个 Agent 被卡住了，需要 Human-in-the-Loop 的支持。于是他帮助 Agent 解决了问题，并把解决方案写进 NEVER.md，防止其他 Agent 将来遇到类似问题。

处理完所有被卡住的 Agent 后，他开始查看昨天的监控数据。这时他发现某个 Agent 为一个非常简单的需求编写了几百行单元测试，这让他觉得有些异常。于是他仔细阅读这些测试代码，结果发现 Agent 编写了大量 Mock，对实现细节进行了过度依赖，形成了一套非常脆弱的测试体系。

于是他让 Agent 重新编写测试。这一次，更偏向芝加哥学派，而不是伦敦学派。随后，他把这条经验补充到了 BEST_PRACTICES.md 中。

Agent行为监控

接着，系统面板弹出一个通知。某个 Agent 已经连续 10 轮无人值守地产出代码。根据他预先设置的阈值，现在应该切换到人工辅助模式。

在这种模式下，Agent 不再自动提交和审核代码，而是每一步都需要人类参与确认。通过审查最近的工作记录，他发现这个 Agent 已经开始出现轻微的架构漂移。于是他怀疑其他 Agent 可能也存在类似问题，随后抽查了其他几个 Agent 的工作成果，并相应更新了 ARCHITECTURE.md、BEST_PRACTICES.md 等文件。

核心问题攻坚

下午，老板交给他一个非常困难的任务。这个任务涉及大规模架构调整，模型暂时还无法独立完成。

于是他将 Agent 切换到人工辅助模式。接下来几个小时里，他和 Agent 一起完成了架构设计、方案验证以及实现工作。与此同时，那些 Bug 修复、UI 微调、配置更新等相对标准化的任务，依然由无人值守的 Agent 自动完成。

就这样，一天的工作结束了。

Tom 关掉电脑，下班回家。

而他的 Agent 们，则继续工作。