最近我在用 AI IDE 辅助开发自己的个人项目，过程中遇到一个很典型的问题：

我已经明确告诉 AI：

如果你修改了后端代码，判断是否需要重启；如果需要，就按照我指定的方式重启。

我甚至把这个规则写进了项目的长期记忆文件里，比如 AGENTS.md。

一开始项目比较简单的时候，这套方式看起来还能用。但随着项目越来越复杂，我发现 AI 经常会出现几种情况：

• 改完代码后不重启，直接告诉我“已经完成”
• 明明我告诉过它重启方式，它还是按照自己的思路执行命令
• 我让它用 MacBook 上的 launch 方式重启，它却自己去用 kill、npm run dev、mvn spring-boot:run 之类的方式
• 每次都要我再提醒一句：“你是不是忘了重启？”

这件事让我意识到一个问题：

不是我没有告诉 AI，而是我告诉 AI 的方式不够工程化。

---

一、我一开始的做法：把规则写进长期记忆文件

在 AI IDE 里，很多工具都会支持类似长期记忆文件的能力。

比如：

• AGENTS.md
• CLAUDE.md
• 项目规则文件
• 自定义 instructions
• skills / workflow 文件

它们的作用本质上都是：

在 AI 每次处理任务时，把一些项目规则、开发规范、运行方式提前放进上下文里。

所以我一开始的想法很简单：

既然 AI 经常忘记重启，那我就把规则写进 AGENTS.md。

类似这样：

如果修改了后端代码，需要判断是否需要重启后端。
如果需要重启，请使用 launch 的方式重启，不要使用普通命令重启。

这看起来很合理。

但实际效果并不稳定。

---

二、为什么 AI 明明“记住了”，但还是不执行？

后来我重新理解了一下 AI IDE 的工作方式，发现所谓“长期记忆”，并不是人类意义上的真的记住了。

它更像是：

每次你发起任务时，AI IDE 框架会把系统提示词、用户问题、项目规则、长期记忆文件、相关代码片段等内容，重新拼接成一个完整的 prompt，再发给大模型。

也就是说，AGENTS.md 这类文件不是写进了模型大脑里，而是作为上下文的一部分，被反复塞给模型看。

这带来一个问题：

被放进上下文，不等于一定会被模型注意到；被注意到，也不等于一定会转化成动作。

尤其是当项目变复杂后，AI 同时要处理很多信息：

• 当前用户需求
• 代码结构
• 历史对话
• 文件变更
• 运行命令
• 报错日志
• 项目规则
• 测试结果

这时候，如果规则写得太长、太模糊，或者动作本身需要 AI 自己判断，它就很容易漏掉。

比如这句话：

如果需要重启，就自动重启。

对人来说没问题，但对 AI 来说，中间有很多不确定性：

• 什么情况算“需要重启”？
• 修改哪些文件算后端变更？
• 用什么命令重启？
• 如果有多个启动方式，选哪个？
• 重启失败后怎么办？
• 是否需要健康检查？

只要这些没有被明确固化，AI 就可能自己发挥。

---

三、我对 AGENTS.md 和 Skill 的理解变化

一开始我以为，只要把所有规则都写进长期记忆文件，AI 就应该能稳定执行。

后来我发现，这种理解太粗了。

更合理的方式应该是把规则分层。

第一层：简短的大纲

这一层负责告诉 AI：

当前项目遇到某类任务时，应该走哪个固定入口。

比如：

后端代码或后端配置变更后，必须执行：

./scripts/local-release.sh

这句话越短越好，越明确越好。

不要在这里写一堆复杂解释。

因为这一层的目标不是教 AI 怎么重启，而是让它知道：

你不要自己想办法，只需要调用这个入口。

第二层：真正要做的事情

具体怎么构建、怎么重启、怎么检查服务是否启动成功，不应该每次都靠 AI 临场发挥。

这些事情应该固化成脚本。

比如：

./scripts/local-release.sh

里面再调用：

./scripts/restart-backend.sh
./scripts/health-check.sh

这样一来，AI 只需要记住一个简单动作：

后端变更后，执行 ./scripts/local-release.sh。

至于怎么重启、怎么健康检查，交给脚本完成。

---

四、我最后改成了脚本化发布流程

后面我把本地发布流程整理成了几个脚本。

大概结构类似这样：

scripts/
  local-release.sh
  restart-backend.sh
  health-check.sh

其中：

local-release.sh

作为唯一入口。

#!/usr/bin/env bash
set -euo pipefail

echo "Starting local release..."

./scripts/restart-backend.sh
./scripts/health-check.sh

echo "Local release completed."

restart-backend.sh

专门封装我的 MacBook 上的 launch 重启方式。

#!/usr/bin/env bash
set -euo pipefail

echo "Restarting backend by launch method..."

# 这里写真实的 launch 重启逻辑
# 例如 launchctl、launch 脚本、或者项目自己的启动方式

echo "Backend restarted."

health-check.sh

专门检查服务是否真的启动成功。

#!/usr/bin/env bash
set -euo pipefail

URL="${BACKEND_HEALTH_URL:-http://localhost:8080/actuator/health}"

echo "Checking backend health: $URL"

for i in {1..30}; do
  if curl -fsS "$URL" >/dev/null; then
    echo "Backend health check passed."
    exit 0
  fi

  echo "Waiting for backend... $i"
  sleep 2
done

echo "Backend health check failed."
exit 1

然后我在 AGENTS.md 里只保留最关键的规则：

## Local Release Rule

如果修改了后端代码、后端配置、接口、服务层、启动逻辑或依赖文件，必须执行：

./scripts/local-release.sh

不要自己发明重启命令。
不要直接使用 kill、pkill、npm run dev、mvn spring-boot:run、java -jar 等方式重启。
重启逻辑已经封装在 scripts/restart-backend.sh 里。

任务完成前必须说明：
- 是否修改了后端
- 是否需要本地发布
- 执行了哪个发布脚本
- 发布是否成功
- 健康检查是否通过

这样改完以后，效果明显稳定了很多。

---

五、为什么这样成功率会更高？

我自己的理解是，原因有三个。

1. 减少 AI 的判断空间

原来是：

你判断是否需要重启，然后选择正确方式重启。

现在是：

后端变更后，执行 ./scripts/local-release.sh。

前者需要 AI 判断很多事情。

后者只需要它判断一件事：

这次有没有改后端？

判断空间越小，成功率越高。

---

2. 把复杂动作交给确定性脚本

AI 最不稳定的地方是：

• 自己猜命令
• 自己组合流程
• 自己判断启动是否成功
• 自己临时处理异常

而脚本的优势是：

• 固定
• 可复用
• 可测试
• 可维护
• 不会每次自由发挥

所以后来我越来越觉得，AI 开发项目时，不应该让 AI 每次现场手搓流程。

更好的方式是：

AI 负责判断和调用
脚本负责执行
健康检查负责验收

---

3. 长期记忆文件应该写“入口”，不要写“教程”

这是我这次最大的收获。

一开始我很想把所有细节都写进 AGENTS.md，希望 AI 看完后什么都懂。

但项目复杂以后，这样反而会让规则变得很长，AI 不一定能抓住重点。

后来我发现，长期记忆文件更适合写：

• 项目固定规则
• 禁止事项
• 唯一入口
• 完成标准

不适合写太复杂的操作教程。

复杂流程应该沉淀到脚本、文档或者 Skill 里。

---

六、我现在对 AI IDE 记忆和 Skill 的理解

现在我对这类机制的理解是：

AGENTS.md 更像项目规则层

它适合写：

这个项目怎么启动
这个项目怎么测试
这个项目后端变更后怎么发布
哪些命令不能用
完成任务前必须检查什么

它应该短、硬、明确。

Skill 更像任务能力层

它适合写：

遇到某类任务时，应该按什么流程做
需要调用哪些脚本
失败时怎么排查
最后怎么汇报结果

也就是说，记忆和 Skill 最好不要写成一大坨内容。

更合理的是至少分成两层：

第一层：简短大纲，负责告诉 AI 什么时候用什么入口
第二层：具体动作，放到脚本、文档或 Skill 里

如果再细一点，Skill 甚至可以理解成多层：

技能名称和简介：负责让 AI 知道什么时候使用这个 Skill
SKILL.md：负责说明具体流程
scripts / references：负责执行和补充细节

这有点像软件里的懒加载：

先告诉 AI 有这个能力，需要时再展开具体内容。

---

七、这件事给我的启发

以前我以为，AI 开发项目就是：

我告诉它规则，它照着做。

现在我觉得，更准确的方式应该是：

我设计规则入口，让 AI 调用确定性的工程流程。

尤其是当项目越来越复杂后，不能只靠自然语言提醒 AI：

记得重启
记得测试
记得不要乱用命令
记得检查日志

这些提醒本质上都是软约束。

更可靠的方式是把它们变成：

固定脚本
固定入口
固定检查
固定完成标准

比如：

后端变更 → ./scripts/local-release.sh
接口变更 → ./scripts/api-test.sh
前端变更 → ./scripts/frontend-check.sh
数据库变更 → ./scripts/db-migration-check.sh

AI 不需要每次重新理解复杂流程，只需要根据任务类型调用对应脚本。

---

八、总结

这次问题看起来只是“AI 为什么不自动重启后端”。

但背后其实是 AI 工程化使用方式的问题。

我最后得到的结论是：

不要指望 AI 永远记住复杂流程，也不要让 AI 每次自由发挥执行命令。
更好的做法是：把复杂流程脚本化，把项目规则简化成固定入口，让 AI 负责判断和调用。

简单说就是：

AGENTS.md 写规则入口
Skill 写任务流程
Shell 脚本做确定执行
健康检查做结果验收

这样之后，AI 的成功率会明显高很多。

这也是我最近使用 AI IDE 开发个人项目时，一个比较有价值的体会。

AI 不是不能管理项目流程，但要给它足够清晰的工程边界。

不是一句“你记得重启”就够了。

更可靠的是：

你只要调用这个脚本，剩下的事情脚本会处理。