摘要
在前三篇复盘中，我们探讨了工具选型、老项目改造路径以及人机协作边界。然而，随着 AI 在团队内的普及，一个新的瓶颈逐渐浮现：AI 的"幻觉"与"发散" 。它经常写出不符合团队规范的代码，或者在重构时破坏隐式的业务规则。本篇作为系列复盘的第四篇，将聚焦于 上下文工程（Context Engineering） 与 约束管理（Constraint Management） 。我们将论证，AI 辅助研发的高级阶段，本质上是将人类工程师的经验、判断与底线，转化为 AI 可执行的"法律"。文章将通过三个硬核的代码案例------基于 CLAUDE.md 的静态规则约束、基于 Git Worktree 的动态上下文隔离、以及基于 Skills 的团队知识沉淀，展示如何从"放任式 AI 开发"迈向"工程化 AI 协作"。
第一章：失控的隐患------为什么 AI 需要"紧箍咒"？
在 AI 辅助研发的早期，我们享受着"自然语言编程"的快感。但随着项目复杂度上升，这种快感迅速演变为噩梦。
1.1 "放任式"开发的代价
当我们对 AI 说"帮我优化这段 Java 代码"时，如果缺乏上下文，AI 通常会基于训练数据中的"通用最佳实践"进行重构：
-
引入废弃依赖 ：在 JDK 8 的老项目中引入 JDK 11 的
var语法。 -
破坏隐式规则：将原本为了兼容旧客户端而保留的"丑陋代码"优化掉，导致线上故障。
-
风格漂移：今天生成的代码遵循 Google 风格，明天又变成了 Spring 官方风格。
正如我们在内部黑板报中总结的：**"只靠让 AI 自己发挥，大概率会跑偏。"** 大模型是概率机器，它缺乏对项目特定历史、业务特定规则以及团队特定习惯的感知。
1.2 约束的本质：可执行边界
所谓"约束"，本质上是一种翻译机制。它的目标是将人类模糊的、经验性的判断（例如"这里要快"、"那里要稳"、"这块逻辑很核心别乱动"），转化为 AI 能够精确理解和遵守的可执行指令。
在软件工程史上，我们用"代码规范"来约束人类程序员；在 AI 时代，我们需要建立一套全新的**SDD（Software Development by Description，描述式软件开发）**体系。这不仅是提示词（Prompt）的艺术，更是工程管理的变革。
第二章：双轨制约束------静态规则与动态指令
要让 AI 稳定地产出，我们需要建立两层防御体系：长期共识（静态约束） 与单次任务（动态约束）。
2.1 静态约束：项目的"基本法"
静态约束是长期不变的，它定义了项目的基因。AI 必须在每一次生成代码前，将这些规则加载到上下文中。
-
载体 ：
CLAUDE.md、AGENTS.md、.cursorrules等。 -
内容：项目的目录结构规范、技术栈版本锁定、命名规范、架构禁忌（如"严禁在 Service 层直接操作 Request"）。
-
作用 ：确保 AI 写出的代码风格统一、符合架构预期。
2.2 动态约束：任务的"作战指令"
动态约束是针对当前具体任务的上下文。它告诉 AI "这次你要干什么"以及"做到什么程度算完"。
-
载体：Spec（规格说明书）、Plan（执行计划）、Task（任务清单）。
-
内容：具体的业务需求描述、高层设计文档、影响范围评估、验收标准（Acceptance Criteria）。
-
作用 ：确保 AI 的执行精准对焦、不跑题。
核心原则 ：静态约束管"长期共识"，动态约束管"这次怎么做"。在 IDE 中，建议将静态约束文件始终 Pin 在聊天窗口，而动态约束则通过 @ 符号或文件引用动态注入。
第三章：实战案例一------CLAUDE.md 的工业级写法
很多团队在编写 CLAUDE.md 时容易犯一个错误：试图把整个项目的代码都塞进去 。这会导致 AI 产生"注意力稀释"。正确的做法是做索引，不做百科全书。
3.1 反例：糟糕的 CLAUDE.md
bash
# 不要这样写！
## 项目规范
这里是几千字的开发手册复制粘贴...
这里是某个复杂的工具类代码...
这里是数据库表结构...问题：文件过长，AI 难以检索重点，且占用了宝贵的上下文窗口（Context Window）。
3.2 正例：工业级 CLAUDE.md
以下是一个针对遗留 Spring MVC 项目的实战配置。它简洁、有力，直击痛点。
文件路径： .claude/CLAUDE.md
bash
# CLAUDE.md - 项目专属指令集 (Legacy Project v1.0)
## 🏛️ 1. 项目背景与硬性红线 (Static Constraints)
*本项目是基于 JDK 8 的 Spring MVC 遗留系统，严禁引入任何高版本语法或新框架。*
- **语法限制**：绝对禁止使用 Java 8 之后的语法（如 `Optional`, `LocalDateTime`, `var`, Lambda 表达式）。
- **JSON 处理**：全项目强制使用 `Fastjson`，严禁使用 `Jackson` 或 `Gson`。
- **日志规范**：必须使用 `SLF4J`，严禁使用 `System.out.println`。
- **SQL 限制**：严禁在循环内执行 SQL 查询（绝对禁止 N+1 问题）。
- **事务规范**：所有写操作必须使用 `@Transactional(readOnly = false, rollbackFor = Exception.class)`。
## ⚖️ 2. 代码审查动态约束 (Dynamic Constraints)
*当你接收到一个修改需求时，必须按以下步骤执行：*
1. **影响范围评估**：首先列出本次修改会涉及哪些核心文件（Entity, Service, Controller）。
2. **依赖检查**：检查是否无意中引入了 `pom.xml` 中没有的新依赖。
3. **防御性检查**：检查是否修改了无关的公共工具类。
4. **输出标准**：在给出最终代码前，必须先输出一段"变更摘要（Change Summary）"，说明你遵守了上述哪些红线规则。效果验证：
当你在 Cursor 或 Claude Code 中输入提示词："帮我给 UserService.java 增加一个缓存逻辑"时，AI 会先读取上述规则。
-
无约束时 ：AI 可能会顺手用
ConcurrentHashMap写了一个本地缓存，并使用了 JDK 11 才有的var关键字。 -
有约束时：AI 会输出如下结果：
Change Summary 遵守 CLAUDE.md 约束报告：
-
未引入新依赖，继续使用项目原有的
Guava包实现本地缓存。 -
代码完全兼容 JDK 8，未使用
var等新语法。 -
已按要求在
updateUser方法上追加@Transactional注解以保证数据一致性。
Code Diff: （此处输出具体的代码修改）
-
第四章：实战案例二------上下文隔离的工程化（Git Worktree）
黑板报中提到"探索区 vs 生产区"。在物理层面上，如果让 AI 在同一个目录下边查资料边写代码，它的上下文会被无限拉长，最终变成一个只会复读的机器。高阶玩家的做法是利用 Git Worktree 打造完美的 AI 辅助编程工作流。
4.1 痛点：分支切换的烦恼
传统的 git checkout -b feature/new-idea 会导致 IDE 重新加载索引，打断思路。而且，如果 AI 在探索区写出了"脏代码"，很容易误提交到主干。
4.2 解决方案：多 Agent 并行隔离
假设我们正在重构一个电商系统，需要同时处理"支付模块重构"、"库存扣减优化"和"订单状态机改造"三个互不干扰的任务。
Step 1：创建独立的 Worktree（物理隔离）
不要在同一个目录下用 git stash 来回切换，而是为每个任务开辟一个独立的文件夹，但它们共享底层的 Git 历史。
bash
# 在电商项目根目录下执行
# 为任务 A 开辟一个独立的 worktree
git worktree add ../ecom-payment -b agent/payment-refactor
# 为任务 B 开辟一个独立的 worktree
git worktree add ../ecom-inventory -b agent/inventory-opt
# 为任务 C 开辟一个独立的 worktree
git worktree add ../ecom-order -b agent/order-stateStep 2：启动独立的 AI Agent
现在，你有三个完全隔离的文件夹。你可以分别进入这三个目录，启动三个独立的 Claude Code 或 Cursor 实例。
bash
# 终端 1：专职处理支付
cd ../ecom-payment
claude
# AI 的上下文仅限于 payment 模块，不会被 inventory 的代码干扰
# 终端 2：专职处理库存
cd ../ecom-inventory
cursor .
# AI 在这里可以自由实验各种锁机制，不用担心搞崩主分支Step 3：审查与合并
当三个 Agent 都完成了各自的探索，并输出了符合规范的代码后，你再回到主项目进行人工 Code Review，确认无误后合并。
核心价值：
这样做的好处是：探索区的脏代码（实验性代码、未确认的假设）永远不会污染生产区的干净主干。 即使 AI 在某个 Worktree 里把代码改崩了，也只需删除该目录，不会影响主分支的稳定性。
第五章：实战案例三------Skills 沉淀与复用（把经验变成资产）
Skills 不仅仅是提示词，它是**"可复用流程 / 知识 / 工具"的封装**。对于团队来说，Skills 是防止 AI 水平忽高忽低、把高级工程师的经验固化为团队资产的最佳手段。
5.1 痛点：重复造轮子
每次新增一个 REST API，高级工程师都要在心里默念一遍流程："先写接口、再写应用层、再写领域层、最后写测试"。而初级工程师或 AI 往往会直接把逻辑堆在 Controller 里。
5.2 解决方案：封装"REST API 开发 Skill"
与其每次都跟 AI 唠叨，不如把这个过程封装成一个标准的 Skill 文件。
目录结构：
bash
your-project/
└── .claude/
└── skills/
└── rest-api/
└── SKILL.md.claude/skills/rest-api/SKILL.md 内容：
bash
# Skill: REST-API-Generator (v1.0)
## 目标
标准化生成后端 RESTful API，杜绝"屎山"代码。
## 触发条件
当用户要求"新增一个 XXX 接口"或"生成 OrderController"时使用。
## 工作流程 (Must Follow)
1. **接口定义**：在 `xxx-api` 模块的 `Api.java` 中使用 Swagger 注解定义 URL、Method 和入参出参。
2. **应用层编排**：在 `xxx-app` 模块编写 Application Service，负责编排 Domain 层，严禁包含 SQL 或 HTTP 调用。
3. **领域层实现**：在 `xxx-domain` 模块实现核心业务逻辑和 Entity。
4. **防腐层**：如果涉及外部 RPC 调用，必须在 `infra` 层编写 Adapter。
5. **单元测试**：必须提供 JUnit 测试代码，覆盖正常流程和参数校验异常流程。
## 输出要求
- 必须输出完整的 Java 文件路径。
- 禁止直接修改 Controller 层的已有逻辑，只允许新增。
实战演示：
当你对 AI 说："帮我新增一个'取消订单'的接口"。
-
无 Skill 时 ：AI 可能会直接在你的
OrderController里加一堆 if-else，甚至直接在 Controller 里调用 JDBC。 -
有 Skill 时：AI 会严格按照 Skill 定义的流程执行：
-
它会拒绝直接在 Controller 里改代码，并提示违反了"单一职责原则"。
-
它会依次生成四个层级的代码文件：
-
api/OrderCancelApi.java(定义接口) -
app/OrderCancelAppService.java(编排逻辑) -
domain/Order.java(修改状态) -
infra/OrderRepository.java(持久化)
-
-
最后附带一段单元测试代码。
-
团队价值：
新人入职后，不需要背诵《开发手册》。只要调用 rest-api Skill，AI 就能辅助他写出符合架构规范的代码。Skill 成为了团队知识的载体。
第六章：避坑指南与最佳实践
基于上述实践，我们总结了三条核心原则：
-
文件即法律 ：
CLAUDE.md不是建议，而是 AI 必须遵守的法律。定期 Review 和更新这个文件。 -
物理隔离优于逻辑隔离 ：不要让 AI 在同一个窗口里处理完全不相干的任务。
Git Worktree是你最好的朋友。 -
渐进式披露：不要一次性把所有规则扔给 AI。先给目标，遇到困难再注入具体的 Skills。
结语
AI 辅助研发的高级阶段，不是让 AI 变得更"聪明"，而是让人类工程师变得更"工程化"。我们通过 CLAUDE.md 建立静态约束，通过 Git Worktree 实现动态隔离，通过 Skills 沉淀团队智慧。
我们正在经历一场从"人肉写代码"到"人指挥 AI 写代码"的范式转移。在这个过程中，"理解"是前提，"约束"是保障，"验证"是闭环。只有建立了这套严密的工程体系，我们才能放心地让 AI 在广阔的业务空间中驰骋，而不必担心它闯下大祸。
在下一篇（也是本系列的最后一篇）中，我们将跳出单点工具的使用，探讨如何通过度量指标与流程优化 ，构建企业级的 AI 研发效能体系。我们将回答一个核心问题：如何量化 AI 到底为研发团队省了多少钱？提效了多少倍？
免责声明：本文涉及的代码案例与工程化实践基于通用开发规范与常见 AI 编程工具（如 Cursor、Claude Code）的特性编写。实际落地时需结合具体技术栈（如 JDK 版本、框架差异）及团队内部规范进行适配与调整。Git Worktree 的使用需注意磁盘空间管理，建议定期执行 git worktree prune 清理无效目录。
本文相关文章序列：
AI辅助研发深度复盘（1/5）：老项目改造的核心逻辑与人机分工最优路径-CSDN博客
AI 辅助研发内部复盘（2/5）：老项目改造的工程化实践-CSDN博客