BLOG

“最小结构主义 + 强失败主义”

2026/05/11 6 min read BLOG “最小结构主义 + 强失败主义”

有，而且其实你这套思想并不小众。
你现在已经非常接近几套成熟工程哲学的交集了，只是你比它们更激进、更适合约束 AI。

你这套核心可以概括成：

“最小结构主义 + 强失败主义”

核心不是“代码风格”，而是：

  • 系统必须可推理

  • 结构必须收敛

  • 错误必须暴露

  • 功能必须唯一归属

  • 禁止熵增

你现在缺的不是更多规则。

而是：

从“行为约束”升级成“结构约束”

因为 AI 不怕规则。

AI 最怕：

无法绕开的结构系统。

你现在的问题

你现在规则仍然像：

不要：
- script
- fallback
- helper

但 AI 会换皮：

  • service

  • adapter

  • normalize

  • resolver

  • bridge

  • middleware

  • util

本质还是同一种东西。

所以：

不要限制“形式”

要限制“结构后果”

最契合你的成熟哲学

我认为你最适合的是：

1. Unix Philosophy（原教旨版）

2. DDD Lite（不是企业味那版）

3. Mechanical Sympathy

4. Radical Simplicity

5. Correctness-first systems

但都不完全。

你真正缺的是：

一个 AI 时代的“反熵系统”

我建议你不要继续加 gate

而是建立：

三层硬约束体系

这才是真正有效的。

第一层：Structural Laws（结构法）

不是建议。

是绝对规律。

例如：

LAW-001 — Single Source of Truth

任何业务规则只能存在一个真实实现。

禁止：

  • duplicate logic

  • mirrored validation

  • secondary normalization

  • parallel transforms

这是最关键的一条。

LAW-002 — One Capability One Owner

任何能力只能有一个 owner。

例如：

auth/*
schema/*
cache/*
parser/*

禁止：

  • 分散实现

  • 下游补偿

  • 局部 mini version

LAW-003 — Root Cause Layer Fixing

错误只能在产生层修复。

禁止：

  • downstream sanitize

  • UI patch

  • defensive conversion

这个会直接杀死 70% AI 屎山。

LAW-004 — Additions Require Deletion

新增代码必须伴随：

  • 替换目标

  • 删除旧结构

  • 收敛说明

否则禁止新增。

这条极强。

因为 AI 默认永远 append。

LAW-005 — No Silent Survival

非法状态必须 fail fast。

禁止：

  • implicit defaults

  • silent catches

  • optional spread

  • graceful corruption

第二层：Repository Shape Enforcement（仓库结构约束）

这是比 policy 更强的。

因为 AI 不会真正“理解规则”。

但会被结构卡死。

例如：

强 feature topology

强制：

/features/X
  /domain
  /application
  /infra
  /view

禁止：

  • random utils

  • shared dumping

  • cross-feature helpers

强 import direction

只能：

view -> application -> domain

禁止反向依赖。

这会直接减少大量 patch。

强 module boundaries

每层只暴露：

index.ts

AI 不允许随便穿透内部文件。

第三层：AI Execution Protocol（最关键）

真正杀 AI 熵增的不是 code style。

是：

强制 AI 先“解释结构”

例如要求 AI 在改代码前必须输出：

1. Canonical Path

真实入口：
真实 owner：
真实数据流：

2. Root Cause

错误产生层：
为什么会扩散：
为什么现有结构失效：

3. Minimal Change Proof

为什么不需要新增实体：
为什么不需要 helper：
为什么不需要 adapter：

4. Entropy Check

是否新增：
- path
- abstraction
- indirection
- normalization
- state

如果有任何新增：

必须解释为什么不可避免。

这是关键：

不要让 AI “直接写代码”

而是：

先证明：

“它没有在制造结构熵”

你真正想要的

其实可以总结成一句：

“系统必须持续收敛，而不是持续兼容”

这是很多现代工程体系反着来的。

现代系统强调：

  • resilience

  • backward compatibility

  • graceful degradation

  • extensibility

而你更接近：

可证明性（provability）

可收敛性（convergence）

可推理性（reasonability）

这个方向其实更适合 AI 时代。

因为 AI 最大问题就是：

它极度擅长“局部成立”

极度不擅长“整体收敛”

所以你必须把：

“结构收敛”

变成第一原则。