在二零零几年的时候，那个时候开发社区热衷于讨论设计模式、开发思想，思考如何把软件设计得像雕塑艺术品，而不仅仅是完成功能。

后来，风向变了，没有人再讨论这些陈旧的老东西了，大家喜欢讨论 A/B 测试，讨论微架构，讨论埋点。

又过了十年，到了 2026 年，其实在去年 2025 年就已经开始了，设计模式、开发思想又回来了，尤其是 SRP（单一职责原则），在使用 AI IDE 编程的时候，它首先被写进 rules 中。这些传统的思想、经验，现在不仅是程序员的财富，也是 AI 行动的圭臬。

我觉得，将相关 rules 完善，汇集成篇，都值得写一本书。在此之前，我先开源一个 agent-rules 大全，程序员同行随取随用：

https://github.com/rixingyike/agent-rules

为了展示这个仓库主要包含什么内容，我举两个小示例。其一，在 Anti 的 .agent/rules 目录下放置一个 single-responsibility-principle.md 文件，内容如下：

---
trigger: always_on
---

程序代码文件大致分为两种：一种是功能文件，这类文件，一个函数只干一件事，一个文件只负责一类事；另一种是路由编织文件，负责将很多甚至所有文件编组起来，从功能上讲，该类文件只负责了路由编织、导航，也符合单一职责原则。

在开发中，每个文件具体应该是路由文件或是功能文件，由模型自行判定

这个规则在当前工程项目下随时生效，约束 AI 进行合理的模块化架构。

其二，是 test-for-change.md 文件，内容如下：

---
trigger: always_on
---

在每次改变（新增、修改、删除）模块代码后，都要进行测试。测试的方法有许多种：
1，针对功能性函数编写单元测试，测试时运行单元测试；
2，针对脚本或启动程序的脚本，或程序，在终端里进行启动测试，看是否会发生错误；
3，每完成一次会话交互，就自动运行一次合适的测试，方式由模型决定。

测试代码编写规则：
1，绝对不允许修改工作代码，以便让测试代码通过；
2，如果为了测试准确，会产生 IO 副作用，可以将产生的副作用文件放在/tmp 目录下，测试并将生成的临时文件展示给开发者，以便开发者查验。

这个规则也是随时生效的，它通过让 AI 编写测试代码，保证项目在进行的过程中保持可测试性。AI 写代码，不仅写得快，还发跑得稳。不能因为开发了新功能，老功能频频出问题。而可测试性，就是保证稳定性的。

bye，就聊这么多，你对 rules 怎么看？你用 Anti 还是其他 AI IDE？现在 rules 已经成为业界事实标准，每个 AI IDE 都可以设置的。

2026/01/02 周五 10:15