AI 写代码为什么越写越乱？可以试试这套逻辑推理框架
这不是一篇教你怎么写 prompt 的文章。
先说一个真实的场景
你用 AI 写后端接口，第一次它给你用了 studentName，第二次用了 display_name，第三次用了 name。
你让它写权限逻辑，它自己猜"学生大概可以被删除吧"，直接写进了代码。
你换一个 AI 会话继续，它完全不知道之前定了什么，又发明了一套新的目录结构。
代码库越大，这种漂移越严重，直到没人敢动。
问题不在于 AI 太笨。问题在于它不知道从哪里推导、该遵守什么规矩。
核心观点：通过理清开发逻辑来加速开发，而不是通过自动化来加速开发
AI 辅助开发有两条路：
- 自动化路线：让 AI 跑得更快
- 推导路线：先把赛道画清楚，让 AI 知道该往哪跑
如果开发逻辑本身是混乱的，AI 越快，产出的混乱就越多。
这就是 Derivation Kernel 想解决的问题——它不是代码生成工具，不提供 CLI，不是 Copilot 的替代品。它是一套让 AI 和人协作时能按清晰推导链工作的治理框架。
一个核心原则：先推导，后发明（Derive Before Invent）
问题在哪
你让 AI 写学生管理的后端接口，它会：
- 自己发明字段名（
studentNamevsdisplay_namevsname） - 自己决定 API 格式（有时套
{ data: ... }，有时不套） - 自己选目录结构（每次不一样）
- 自己猜业务规则（"学生大概可以被删除吧？"）
每一次"发明"都在制造漂移。代码库越大，漂移越严重。
解法
不让 AI 发明。让它从已经确认的上游真相中推导。
❌ AI 自己决定："学生的状态应该有 active、inactive、deleted"
✅ 先在领域真相中确认："学生状态只有 enrolled → suspended → graduated"，然后 AI 从这里推导出后端枚举、前端下拉选项、字典显示文本
区别在于：推导有明确的来源，出了问题可以追溯；发明没有来源，出了问题只能逐个文件排查。
五层推导链
代码世界需要关心五层，它们不是五个文件夹，而是看同一个系统的五个视角：
L3 领域逻辑层 （业务真相的源头）
↓
├── L4 后端架构层 （按域组织后端代码结构）
│ L3 + L4 = 后端域代码
│
├── L6 前端结构层 （按域装配前端组件结构）
│ L3 + L6 = 前端域级结构
│ ↓
│ L7 视觉语言层 （给域级结构加上视觉表达）
│ 域级结构 + L7 = 渲染成品
│
└── L5 桥接层 （按功能跨域组装页面，对齐前后端契约）
后端域代码 + 渲染成品 + 通用组件 → 功能页面
| Layer | 职责 | 稳定方式 |
|---|---|---|
| L3 领域逻辑 | 业务真相源头 | 四个视角穷尽业务域的最小知识集 |
| L4 后端架构 | 把真相组织成可维护的后端代码结构 | 选定架构策略，全项目一致执行 |
| L5 前后端契约 | 把后端能力投射成前端可消费的共享表面 | 共享规约 + 少量人工拍板 |
| L6 前端交互 | 把能力表面装配成页面、组件、交互流 | 组件治理规则（复用范围 × 复杂度） |
| L7 视觉语言 | 把交互结构变成最终的视觉表达 | 呈现哲学：重组展示方式，不重写真相 |
关键认知：
- L4 和 L6 是对称的——都从 L3 出发，都按域组织，分别停在后端域代码和前端域级结构
- L7 不是 L6 的下游推导——它是独立的呈现模板，域级结构 + L7 才是渲染成品
- L5 是唯一跨域的层——前后端都按域组织到域就停；L5 按功能组装页面，因为用户不按域思考
L3：为什么业务真相需要四个视角？
L3 是整条链的起点。它用四个视角穷尽"关于一个业务域，需要知道什么才能安全往下写代码"的最小集合：
| 真元 | 最简单的记法 | 缺失后果 |
|---|---|---|
| Schema | 主体是什么 | 字段名靠猜 |
| Service | 能做什么操作 | API 设计靠猜 |
| Policy | 谁能做什么 | 权限逻辑每人写一套 |
| Relationship | 实体之间怎么关联 | join 查询和级联行为靠猜 |
任何一个缺失，下游推导就会被迫"发明"，从而违反"先推导后发明"原则。
四个真元不意味着必须写四个文件。它们可以写在一个文件里（比如 domain-truth.md），关键是四个视角都被覆盖了。
L4-L7：每层靠什么稳定？
L4 后端架构层——靠"选定策略"稳定
选定一套架构策略，全项目一致执行。
| 稳定来源 | 举例 |
|---|---|
| 分层策略 | DDD-lite：domain → service → repository → transport |
| CRUD 工厂 | 统一的增删改查代码生成模式 |
| 错误工厂 | 统一的错误响应格式和错误码体系 |
| 查询工厂 | 统一的分页、筛选、排序模式 |
L4 的推导关系：L3 Schema → entity/migration；L3 Service → service 层方法；L3 Policy → guard/middleware；L3 Relationship → join 和 cascade 设计。
L6 前端结构层——靠"组件治理规则"稳定
L6 和 L4 对称——按域组织前端，L3 + L6 产出前端域级结构（知道有什么组件、承载什么数据，但还没有视觉表达）。
两个维度的治理矩阵：
- 复用范围：全局共享层（无业务语义）vs 领域共享层（模块内复用）
- 复杂度：原子组件 → 轻组合组件 → 领域组件
L6 只工作到域级，不涉及页面组装——页面组装是 L5 的职责。
L7 视觉语言层——靠"呈现哲学"稳定
L7 可以独立于 L6 定义，先定好设计体系再统一应用。
核心原则：为了更好的理解效率，可以重组展示方式；但只能重组呈现，不能重写真相。
几个稳定原则：
- 低基数直显，高复杂度嵌套（3 个选项直接展示，30 个选项用下拉框）
- 单轴过长时允许多轴展开（内容太多不要一直往下滚，可以分栏分区）
- 每一次点击/展开/滚动都应有明确收益
L5 桥接层——靠"共享规约 + 人工拍板"稳定
L5 是唯一跨域的层，也是决策密度最高的层。
前后端架构都按域组织，到域就停止。但页面是面向用户的，用户不按域思考。一个"个人详情页"，用户的身份可能来自身份域、权限域、组织域——如果按域划分页面，就会出现多个详情页，这不合理。
所以 L5 按功能（而非按域）组装页面，需要人工拍板的问题：
- 一个功能拆成几个页面？
- 每个页面从哪些域取组件？
- 哪些跨域信息同屏展示，哪些分步展示？
L5 的产出是页面能力矩阵：每个页面能做什么、对谁可见、暴露哪些操作、从哪些域取数据。
一个完整示例：身份域从 L3 到页面
L3 领域真相
实体：identity_account
字段：identity_id, login_principal（唯一）, display_name, lifecycle_status
状态机：pending_activation → active → suspended → deactivated
操作：activate_account, suspend_account, deactivate_account
权限：activate 只需 admin；suspend 需要 admin + 账户为 active 状态
关系：一个 identity_account 可以有多个 role_assignment
L4 后端推导（从 L3 推导，不是发明）
identity_account→ entity 文件 + migration + repositoryactivate/suspend/deactivate→ service 层的三个方法- Policy 规则 → guard middleware，检查角色和状态前置条件
- Relationship → repository 的 join 查询设计
L6 域级结构装配
从 L3 按域装配前端组件结构：
- 身份域组件：身份信息卡片、身份状态标签、身份操作按钮组
- 角色域组件：角色列表、角色分配表单
- 操作确认：suspend 和 deactivate 需要二次确认对话框
这些都是域级组件，还不涉及"放在哪个页面"。
L7 视觉表达
独立定义呈现规则：
- 状态标签色彩编码（active=绿，suspended=黄，deactivated=灰）
- 角色列表平铺展示（角色数量通常 < 5，不嵌套展开）
- 危险操作按钮用红色，放在操作组最后
L5 按功能组装页面
- 自服务页面：身份卡片 + 角色列表，用户可查看摘要、修改 display_name
- 管理页面：账户列表 + 筛选器 + 批量操作，管理员可执行 activate/suspend/deactivate
- 两个页面都跨了身份域和角色域——这就是为什么页面组装是 L5 的职责
从 L3 到最终页面，每一步都有明确的上游来源。没有任何一步需要 AI 自己"发明"。
为什么不让同一个 AI 全做了？
如果同一个 AI 既规划又执行：
- 它会跳过不确定的上游问题，直接写代码（因为写代码更容易产出）
- 它会在执行中悄悄扩大范围（"顺便把这个也做了吧"）
- 它会在遇到矛盾时自己消化（不汇报，自己编一个合理化的解释）
解法是角色分离：
| 角色 | 职责 | 不做什么 |
|---|---|---|
| Planner | 规划、确认上游真相、写任务书 | 不写代码 |
| Executor | 按任务书执行、在范围内实现 | 不扩大范围、不修改上游真相 |
Planner 写任务书时：描述"完成的样子"，不描述"怎么实现"。 Executor 比 Planner 更擅长找文件、选实现路径。
常见误解
"这是不是要每次写七份文档？"
不是。七层是七个视角，不是强迫你机械产生七个文件。重点是这些视角有没有被补齐、缺的是哪一层、下游是不是还在替上游补锅。
"这是不是 README 的升级版？"
不是。README 负责让陌生人快速理解仓库定位。这套框架负责让 AI 在推导过程中不需要猜测——两件完全不同的事。
"这不就是让 AI 自己推一切？"
恰恰相反。该由人拍板的层，要先拍板；已经拍板的内容，再交给 AI 往下推。不是让 AI 一路自由发挥到底。
总结
| 问题 | 本框架的回答 |
|---|---|
| AI 写代码为什么会乱？ | 因为它在"发明"而不是"推导"——缺乏上游真相 |
| 怎么让 AI 不乱？ | 给它清晰的推导结构：L3 域真相 → L4 后端 / L6 前端 + L7 视觉 → L5 按功能组装 |
| 业务真相需要定义什么？ | 四个视角：Schema、Service、Policy、Relationship |
| 下游层靠什么稳定？ | L4 靠选定策略，L6 靠组件治理规则，L7 靠呈现哲学，L5 靠人工拍板 |
| 怎么防止跨层漂移？ | 层之间有明确的桥接内容（字典、契约、格式规约等） |
| 这是自动化工具吗？ | 不是。这是让开发逻辑变清晰的治理框架 |
项目地址：GitHub - Derivation Kernel
如果你也在用 Claude / GPT 做工程化开发，欢迎来看看这套框架是否对你有用。有问题可以直接在评论区聊。
