判断类规则没有 100% 硬保证的机制。能做到最好的是:
① 写进 CLAUDE.md(权威、always-loaded)
② 记忆写得足够具体(点名反模式)
③ 我承诺一个自检动作:凡是给你选项或推荐,我必须显式标出哪个是"架构最正确"的,并让它作为推荐;绝不把"改动小/省事/风险低"列为推荐理由。

反模式（Anti-Pattern） 指的是：

表面上看起来是一个解决方案，但长期来看会带来更多问题、被业界证明是不好的做法。

它可以理解成：

模式（Pattern）= 经过实践验证的最佳实践

反模式（Anti-Pattern）= 经常有人采用，但最终证明是错误或低效的实践

---

一个简单例子

模式（Pattern）

数据库密码放到环境变量里：

DATABASE_PASSWORD=xxxx

应用启动时读取：

os.getenv("DATABASE_PASSWORD")

优点：

• 不提交到 Git
• 可以动态修改
• 适合 CI/CD
• 云原生兼容

这是最佳实践。

---

反模式（Anti-Pattern）

把密码直接写死：

password = "123456"

或者：

database:
  password: 123456

提交到 GitHub。

短期：

能跑。

长期：

• 密钥泄露
• 无法轮换
• 多环境管理困难
• 安全审计不过

于是大家总结：

Hardcoded Secret 是一种反模式。

---

软件工程里的经典反模式

1. God Object（上帝对象）

一个类负责所有事情。

UserManager

登录
注册
支付
订单
邮件
权限
统计
缓存

几万行代码。

修改任何地方都会影响整个系统。

这是经典反模式。

---

2. Spaghetti Code（意大利面条代码）

代码依赖关系混乱。

A调用B

B调用C

C调用A

D又调用A

E又调用B

最后没人敢改。

---

3. Copy-Paste Programming

复制代码解决问题。

save_user()

save_admin()

save_manager()

save_operator()

其实只有一点点区别。

以后修改逻辑要改十几个地方。

---

4. Big Ball of Mud（泥球架构）

系统没有明确边界。

所有模块互相依赖。

frontend

↓

gateway

↓

serviceA

↔ serviceB

↔ serviceC

↔ serviceD

↓

database

最终：

谁都能调用谁。

这是很多微服务项目后期会出现的问题。

---

5. Golden Hammer（金锤子）

手里只有锤子，看什么都像钉子。

例如：

公司引入了 Kubernetes。

然后：

• 博客也上 K8s
• 内部工具也上 K8s
• 定时任务也上 K8s
• 一个静态网站也上 K8s

虽然能做，但并不合适。

---

为什么叫“反模式”

这个词来自软件架构领域。

模式（Pattern）：

“这是大家反复验证过的好方案。”

反模式：

“这是很多人都这么做过，但最后发现踩坑无数，应该避免。”

反模式通常包含三个部分：

问题

↓

错误解决方案
（反模式）

↓

造成的问题

↓

推荐方案

例如：

需求：
多个服务共享数据库

↓

反模式：
所有服务直接操作同一个数据库

↓

后果：
耦合严重
无法独立部署
难以扩展

↓

推荐：
每个服务拥有自己的数据库
通过 API 通信

---

你截图里的含义

截图中说：

「不要把『改动小』『省事』『风险低』作为推荐理由。」

实际上是在避免一种常见反模式：

Status Quo Bias（现状偏见）

即：

现在这样也能跑

↓

改动太大

↓

那就继续保持现状

长期来看可能导致：

• 技术债不断累积
• 架构越来越难维护
• 错失真正合理的设计

所以作者要求：

给出建议时，必须明确说明：

哪个方案在架构上更正确（Architecturally Correct）

而不是：

哪个方案改动最少。

不过需要注意的是：

“最佳实践”和“反模式”并不是绝对的。

很多所谓反模式，在特定场景下可能是合理权衡。

例如：

• 单体应用不是反模式
• 共用数据库不一定是反模式
• 使用 YAML 配置密钥（开发环境）也不一定有问题

判断标准通常是：

这种做法是否会在当前规模和未来演进中持续制造问题。

如果答案是“会”，那它很可能就是一个反模式。