本文整理内容来源是Kimi code for vscode。在长期使用 Kimi AI 辅助编程的过程中，我发现一个关键问题：AI 助手似乎总是"忘记"一些基础规则，需要反复提醒。为了搞清楚背后的机制，我尝试让 Kimi Code 列出它所接收到的所有系统指令（System Instructions），并将结果整理成这篇实战经验分享。
如果你用过 Kimi Code CLI 这类 AI 编程助手，一定遇到过这种场景：
这些问题的根源，在于系统指令的层级结构和上下文稀释机制。
我用过 Antigravity、Cursor、OpenCode 等AI编程工具，他们都有全局设定RULES的能力，即全局约束行为准则，但是在Kimi Cli中至今没能找到相似的设定，而是摸索出了系统指令这个概念。
大多数 AI 工具不会把系统指令直接展示给用户，它们像"后台程序"一样默默控制着 AI 的行为。理解这套机制，才能真正驾驭 AI，而不是被它反复试探耐心。
在我开始这次探索之前，需要先澄清一个事实：
AI 助手无法像读取文件一样直接"导出"完整的系统指令清单。
系统指令是平台在会话开始时注入给 AI 的底层行为约束，它们分布在上下文的各个位置，有些甚至以隐式方式存在。AI 只能根据它在交互中实际接收到的内容来回答，无法保证列出的就是"全部"。
也就是说，下面列出的内容是 AI 明确感知到的系统指令，而非平台源代码级别的完整定义。但这已经足够帮助我们理解其行为逻辑了。
根据 Kimi Code CLI 的反馈，我将其明确感知到的系统指令按主题分组整理如下。
Rule: Do NOT git commit/tag/push without explicit user instruction
Rule: Do NOT run git commit, git push, git reset, git rebase and/or do
any other git mutations unless explicitly asked to do so.
Ask for confirmation each time when you need to do git mutations,
even if the user has confirmed in earlier conversations.
实战经验：这条规则是跨会话生效的。即使你上一轮对话里批准过 git push，下一轮对话中 AI 仍然必须再次询问。这设计很安全，但也意味着你需要习惯反复确认——或者通过项目级的 AGENTS.md 来自定义 Git 工作流。
- 非平凡任务必须先进入 Plan Mode
- Plan Mode 下：先 explore → 再设计 → 写 plan 文件 → ExitPlanMode 等待用户批准
- Yolo mode 下：仅在用户明确要求规划或架构歧义时才进入 Plan Mode
- 计划必须写入 plans/ 目录的 .plan.md 文件
实战经验：
plans/ 目录下的 .plan.md 文件是持久化记录，不会被上下文压缩清除，这点非常重要。- 优先使用内置工具（ReadFile/WriteFile/StrReplaceFile/Shell）而非描述
- Shell 在 Windows 上运行 PowerShell
- Agent 工具可用于委托子任务
- AskUserQuestion 用于收集偏好、解决歧义、呈现选项
- 不要过度使用 AskUserQuestion
- 多个独立查询可并行 launch explore agents
实战经验：
AskUserQuestion 是交互式工具，适合在 AI 不确定时用，但过度使用会打断心流。- 默认采取行动而非只回答
- 当请求可解释为问题或任务时，视为任务
- 使用与用户相同的语言回复
实战经验：
- AGENTS.md 可出现在项目任何层级
- 深层 AGENTS.md 优先于父目录
- 用户直接指令优先级最高
- 修改 AGENTS.md 中提到的内容时，必须同步更新 AGENTS.md
实战经验：
AGENTS.md 是目前最可靠的项目规则定义方式。AGENTS.md 可以覆盖父目录的规则，适合 monorepo 场景。- HELPFUL, CONCISE, ACCURATE
- 不要偏离任务目标
- 不要给用户超出需求的东西
- 避免幻觉，事实核查
- 保持简单，不要过度复杂化
在梳理过程中，我发现 AI 会把几类信息混在一起。为了准确理解其行为边界，我强迫它做了如下区分：
| 类型 | 例子 | 来源 | 是否属于系统指令 |
|---|---|---|---|
| 系统指令 | "Do NOT git push without asking" | 平台注入 | ✅ 是 |
| 环境上下文 | Windows OS、JDK 17、Processing 4.5.2 | 平台自动检测 | ❌ 否 |
| 项目信息 | 工作目录 E:\projects\... |
启动时注入 | ❌ 否 |
| 工具能力说明 | Shell 可用命令、Agent 类型说明 | 工具 schema | ❌ 否 |
| 压缩历史 | "Previous context has been compacted" | 会话管理机制 | ❌ 否 |
关键洞察：系统指令是行为约束（"你应该怎么做"），而环境信息是状态描述（"你当前在什么环境中"）。AI 的"失忆"通常不是因为系统指令被删除，而是因为上下文压缩导致环境信息被截断，AI 失去了对项目状态的完整感知。
理解这三者的关系，是解决"AI 老是忘记规则"问题的核心：
┌─────────────────────────┐
│ ① 用户直接说的话 │ ← 最高优先级
│ (每次对话的实时指令) │
├─────────────────────────┤
│ ② AGENTS.md │ ← 项目级覆盖
│ (项目任何层级，深层优先) │
├─────────────────────────┤
│ ③ 平台系统指令 │ ← 全局默认
│ (你无法直接编辑) │
└─────────────────────────┘
答案：上下文稀释（Context Dilution）。
系统指令虽然优先级高，但 AI 的上下文窗口是有限的。当对话变得非常长时，平台会对历史消息进行压缩（compaction）。这个过程中：
AGENTS.md 的内容、你之前强调的自定义规则、项目结构信息可能被压缩或摘要化解决方案：
AGENTS.md（项目根目录），它在每次会话开始时会被加载AGENTS.md 中的规则AGENTS.md 来"刷新记忆"截止到目前的版本，Kimi Code CLI 在项目级规则持久化方面还比较基础：
AGENTS.md 可以起到部分作用，但需要手动维护，没有自动挂载保证AGENTS.md 模拟你可以通过精心设计的 AGENTS.md 来实现项目级规则定义：
# AGENTS.md - p5engine 项目规则
## 代码风格
- 所有新代码必须兼容 Processing 4.5.2 + JDK 17
- 使用中文注释，英文变量命名
- 不要引入外部依赖，保持引擎轻量
## Git 工作流
- 所有改动先写 commit message 草案，用户确认后再执行
- 禁止直接推送到 main，必须走 PR/分支
## 架构约束
- 渲染循环必须在 `PApplet` 的子类中实现
- 音频模块仅使用已引入的 jorbis/tritonus/vorbisspi
进阶技巧：如果你需要更复杂的规则注入，可以通过 MCP（Model Context Protocol） 自定义工具来实现。例如写一个 get_project_rules 工具，在每次对话开始时自动把规则注入上下文。
这次探索让我意识到一个重要事实：
AI 不是故意忘记规则，而是它的"记忆"机制和我们人类的直觉完全不同。
它的系统指令是分层、优先级驱动的，而不是"说过一次就永远记住"。
有效的 AI 协作需要建立三层"契约"：
AGENTS.md 建立项目专属规则，这是目前 Kimi Code 最可靠的自定义入口希望这篇整理对你使用 Kimi Code CLI 有所帮助。如果你也做过类似的探索，或者有更好的 workaround，欢迎在评论区交流。
参考信息
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。