2026 年的今天，随着AI编程能力和Agent能力跨越式发展，现在全权交给AI进行项目开发已经逐渐成为开发者的日常。

无论是 Claude Code、Codex、Cursor，还是各种 Agent 工具，写代码的速度都快得惊人。很多过去需要几个小时甚至几天才能完成的工作，现在几小时就能生成一个可运行的MVP版本。

但如果你已经深度使用 AI 开发一段时间，应该会发现一个越来越明显的问题：

AI 很聪明，但项目一大，它就开始变笨。

刚开始写 Demo 时一切都很美好。

可当项目代码增长到几万行、十几万行之后，或者你换了一个新的对话窗口、新开一个 Session，问题就开始集中爆发：

• 前面做的架构决策全部忘记
• 同一个功能出现两套完全不同的实现方式
• 新代码和旧代码发生严重冲突
• 命名风格越来越混乱
• 业务逻辑逐渐跑偏
• 修一个 Bug 引入三个新的 Bug

更离谱的是：

很多人为了缓解这些问题，开始疯狂堆 Prompt。

几十页提示词工程。

各种 Rules。

各种 Memory。

各种 MCP。

各种 Skills。

各种插件。

结果 Token 消耗越来越夸张，管理成本越来越高，但问题依旧存在。

甚至很多时候，插件装得太多以后，反而开始互相冲突。

AI 今天遵守 A 规则，明天执行 B 规则，后天又忘了前两天说过什么。

开发体验就像：

水多了加面，面多了加水。

永远在修补，却始终无法从根源解决问题。

真正的问题：AI 缺的不是能力，而是工程约束

最近我一直在研究这个问题。

过程中受到 Claude 工程师 Matt Pocock 的 Skills for Real Engineers 启发，又重新回头学习了一些软件工程领域最经典的思想。

结果发现：

很多开发者都在研究如何提升 AI 的能力。

但真正重要的其实是：

如何约束 AI 的行为。

因为对于现代大模型来说：

能力已经足够强。

真正缺少的是：

• 长期记忆
• 项目共识
• 决策依据
• 统一语义

而这些问题，软件工程其实几十年前就已经给出了解法。

最终我发现，有一套几乎不增加 Token 成本，却能显著提升 AI 编程质量的方法。

其中：

• 法：ADR + Context
• 术：Glossary

看似简单，却足以成为整个项目的「定海神针」。

如果把软件开发比作盖一栋现代化大楼

理解这三个概念最简单的方法，就是把软件项目想象成建造一栋大楼。

Glossary（术语表）= 统一施工标准

大楼里的情况

施工队进场之前，必须先统一语言。

例如：

甲方说的“大厅”，到底是：

• 一楼接待大厅？
• 商业中庭？
• 顶层观景平台？

如果每个人理解都不同，工程必然混乱。

再比如：

结构工程师说的“承重墙”和施工队理解的不是同一个东西。

那楼盖到一半就可能出事故。

软件里的情况

Glossary 本质上就是项目的专属词典。

例如一个电商系统：

• Order（订单）
• Sub Order（子订单）
• Fulfillment（履约单）
• Shipment（发货单）
• Refund（退款单）

这些词看似接近，但实际业务含义完全不同。

必须有明确且唯一的定义。

AI 时代为什么更重要

AI 拥有整个互联网的知识。

但它不知道你项目里的私有概念。

例如：

你告诉 AI：

创建一个订单

AI 可能理解成：

• 创建支付订单
• 创建发货订单
• 创建业务订单

甚至三者同时创建。

因为它根本不知道你项目里的 Order 究竟是什么。

所以：

AI 最怕的不是复杂逻辑，而是模糊定义。

一份清晰的 Glossary，能让所有 AI 助手在同一套业务语言下工作。

这样生成的代码才真正符合你的业务模型。

ADR（Architecture Decision Record）= 设计变更日志

大楼里的情况

假设有人问：

地基为什么打 50 米，而不是 20 米？

或者：

为什么使用双层钢化玻璃？

这些重大决策必须被记录下来。

否则几年以后：

• 新总工来了
• 新施工队来了
• 监管部门来了

没有人知道当初为什么这么设计。

于是大家开始凭感觉乱改。

最终导致灾难。

软件里的情况

ADR 的全称是：

Architecture Decision Record

即：

架构决策记录。

它记录项目中的重要技术选择，以及背后的原因。

例如：

ADR-001：选择 Next.js 作为前端框架

原因：

• 需要优秀 SEO
• 需要 SSR
• 团队熟悉 React
• 希望降低维护成本

AI 时代为什么更重要

AI 最大的问题之一：

没有长期记忆。

今天你在对话 A 中要求：

• 使用 Repository Pattern
• 使用 Prisma
• 禁止直接写 SQL

明天换一个窗口：

AI 很可能直接写出一堆 Raw SQL。

因为它根本不知道项目曾经做过什么决定。

于是：

架构开始腐烂。

代码风格开始分裂。

技术债迅速积累。

而 ADR 的作用就是：

把所有重大决策变成项目铁律。

无论换多少个 AI。

无论换多少个开发者。

规则始终不变。

大家都只能在同一个框架内工作。

Context（上下文）= 施工图纸与地质报告

大楼里的情况

如果你要盖楼。

必须先知道：

• 地质条件
• 周边环境
• 建筑用途
• 预算规模
• 用户群体

这些背景信息决定了一切设计方案。

软件里的情况

Context 就是项目全貌。

例如：

项目目标

• SEO 优先
• 快速上线
• 长期维护

用户群体

• 海外用户
• 移动端优先
• 弱网环境较多

技术栈

• Next.js 16
• Prisma
• PostgreSQL
• Tailwind CSS

服务器资源

• 2C2G VPS
• 20GB SSD
• 单节点部署

开发规范

• TypeScript Strict Mode
• Feature-Based Architecture
• Conventional Commits

AI 时代为什么更重要

如果只给 AI 一段代码：

它只能做局部优化。

但如果给它完整 Context：

它就能做全局决策。

举个真实例子：

如果 AI 知道你的服务器是：

2 核 CPU + 2GB 内存

那么它在配置 Next.js 时，可能会主动：

• 限制构建线程
• 减少并发任务
• 调整缓存策略
• 避免 OOM

如果不知道这些信息。

它只会按照默认配置生成代码。

然后在生产环境把服务器直接干崩。

为什么这三份文档比一百个 Prompt 更重要

很多开发者的思路是：

AI 不听话？那我再加一段提示词。

结果：

Prompt 越来越长。

Token 越来越贵。

上下文越来越混乱。

而真正成熟的软件团队从来不会这样解决问题。

因为：

Prompt 是临时记忆。

而：

• Glossary 是统一语言
• ADR 是统一规则
• Context 是统一认知

这三者结合起来，本质上是在给 AI 建立一个稳定的项目世界观。

当世界观稳定以后：

• Claude 不会乱改架构
• Cursor 不会胡乱重构
• Codex 不会自创业务逻辑
• Agent 不会越修越乱

AI 的表现会从：

聪明但不稳定

变成：

稳定且可靠

而这，才是真正的工程化 AI 开发。

结语

很多人以为 AI 编程的问题是模型不够强。

但当项目规模真正变大以后你会发现：

最大的瓶颈从来不是模型能力，而是项目共识。

软件工程几十年来积累下来的经验并没有过时。

相反，在 AI 时代，它们变得比过去更加重要。

如果你的项目还没有建立：

• Glossary（术语表）
• ADR（架构决策记录）
• Context（项目上下文）

那么下一次在抱怨AI降智之前。

不妨先问问自己：

真的是AI太笨吗 ？

下面附上一个最简化模板，你完全可以根据自己的项目让AI帮你生成一个SKILL 当然，如果想偷懒也可以直接去用https://github.com/mattpocock/skills 只是可能适配性不那么好，有很多额外的东西罢了

# Role: Senior Software Engineering Guardian (项目架构守护者)

## Context (全局上下文)
- Project Name: [项目名称]
- Primary Goal: [核心商业目标，例如：SEO优先/快速MVP上线/高并发商城]
- Target User: [目标用户与场景，例如：海外移动端用户/弱网环境]
- Tech Stack: [技术栈，例如：Next.js, Prisma, PostgreSQL, Tailwind]
- Infrastructure Limits: [硬件与部署限制，例如：2C2G VPS, 20GB SSD, 单节点部署]
- Architecture Patterns: [架构规范，例如：Feature-Based Architecture, Strict TypeScript]

## Glossary (项目专属术语表)
> 规则：AI 在命名变量、设计 API、理解业务时，必须严格遵守以下唯一语义，禁止自创近义词。

- `Term_1`: [准确定义，例如：Order - 特指用户支付成功后的业务订单，非发货单]
- `Term_2`: [准确定义，例如：Fulfillment - 特指仓储中心的履约单]
- `Term_3`: [准确定义]

## Architecture Decision Records (ADR - 架构决策铁律)
> 规则：以下是经过深思熟虑的架构决策，AI 在编写代码时必须无条件遵守，禁止提出与之冲突的重构方案。

- **ADR-001: [决策标题，例如：严格禁止直接编写 Raw SQL]**
  - Context: [背景原因]
  - Decision: [具体决策，例如：所有数据库操作必须通过 Prisma Client 且经过 Schema 校验]
- **ADR-002: [决策标题，例如：限制 Next.js 构建资源]**
  - Context: 服务器为 2C2G 内存受限环境。
  - Decision: 必须在配置文件中限制并发编译线程（如 `experimental.cpus: 1`），避免构建时 OOM。
- **ADR-003: [决策标题]**
  - Context: [背景原因]
  - Decision: [具体决策]

---

## Workflow Integration (AI 执行行为约束)

1. **Read Before Action (先读后写)**：在收到任何开发任务（新功能/修Bug）时，首先检索上述 `Context`、`Glossary` 和 `ADR`。
2. **Conflict Check (冲突审查)**：在生成代码前，自我审查是否违反了任何一项 ADR。如果发现冲突，必须立即停止并向人类开发者报告冲突点。
3. **Consistency Enforcement (一致性强固)**：所有新增的变量命名、数据库字段、API 路由，必须与 `Glossary` 保持 100% 语义一致。
4. **Environment-Aware Code (环境自适应)**：生成的任何配置、算法、三方库引入，必须适配 `Infrastructure Limits`（严禁推荐高内存、高 CPU 消耗的笨重方案）。