首页 > 基础资料 博客日记
Kimi Code CLI 系统指令的摸索 以及 开发实战经验分享
2026-04-22 14:30:04基础资料围观1次
Kimi Code CLI 系统指令的摸索 以及 开发实战经验分享
本文整理内容来源是Kimi code for vscode。在长期使用 Kimi AI 辅助编程的过程中，我发现一个关键问题：AI 助手似乎总是"忘记"一些基础规则，需要反复提醒。为了搞清楚背后的机制，我尝试让 Kimi Code 列出它所接收到的所有系统指令（System Instructions），并将结果整理成这篇实战经验分享。
一、为什么我要关心系统指令？
如果你用过 Kimi Code CLI 这类 AI 编程助手，一定遇到过这种场景：
- 你明明说过"不要直接推送到 main 分支"，但 AI 在后续任务中又忘了
- 你设定过项目的代码规范，但 AI 在生成新文件时又忽略了
- 你反复强调要用中文回复，但某次长对话后 AI 突然切回了英文
这些问题的根源，在于系统指令的层级结构和上下文稀释机制。
我用过 Antigravity、Cursor、OpenCode 等AI编程工具，他们都有全局设定RULES的能力，即全局约束行为准则，但是在Kimi Cli中至今没能找到相似的设定，而是摸索出了系统指令这个概念。
大多数 AI 工具不会把系统指令直接展示给用户，它们像"后台程序"一样默默控制着 AI 的行为。理解这套机制，才能真正驾驭 AI，而不是被它反复试探耐心。
二、关键前提：AI 能"看到"自己的系统指令吗？
在我开始这次探索之前，需要先澄清一个事实：
AI 助手无法像读取文件一样直接"导出"完整的系统指令清单。
系统指令是平台在会话开始时注入给 AI 的底层行为约束，它们分布在上下文的各个位置，有些甚至以隐式方式存在。AI 只能根据它在交互中实际接收到的内容来回答，无法保证列出的就是"全部"。
也就是说，下面列出的内容是 AI 明确感知到的系统指令，而非平台源代码级别的完整定义。但这已经足够帮助我们理解其行为逻辑了。
三、系统指令完整梳理
根据 Kimi Code CLI 的反馈，我将其明确感知到的系统指令按主题分组整理如下。
3.1 Git 操作安全约束（最高优先级之一）
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 工作流。
3.2 Plan Mode（规划模式）
- 非平凡任务必须先进入 Plan Mode
- Plan Mode 下：先 explore → 再设计 → 写 plan 文件 → ExitPlanMode 等待用户批准
- Yolo mode 下：仅在用户明确要求规划或架构歧义时才进入 Plan Mode
- 计划必须写入 plans/ 目录的 .plan.md 文件
实战经验：
- Plan Mode 是 Kimi Code CLI 防止 AI "冲动改代码"的核心机制。
- 对于复杂重构，让 AI 写 plan 文件再执行，成功率远高于直接让它动手。
plans/目录下的.plan.md文件是持久化记录，不会被上下文压缩清除，这点非常重要。
3.3 工具使用规范
- 优先使用内置工具（ReadFile/WriteFile/StrReplaceFile/Shell）而非描述
- Shell 在 Windows 上运行 PowerShell
- Agent 工具可用于委托子任务
- AskUserQuestion 用于收集偏好、解决歧义、呈现选项
- 不要过度使用 AskUserQuestion
- 多个独立查询可并行 launch explore agents
实战经验：
- "优先使用工具而非描述"意味着 Kimi Code 被设计为行动优先。如果你问"这个 bug 怎么修"，它倾向于直接改代码而不是长篇解释。
AskUserQuestion是交互式工具，适合在 AI 不确定时用，但过度使用会打断心流。
3.4 用户消息处理策略
- 默认采取行动而非只回答
- 当请求可解释为问题或任务时，视为任务
- 使用与用户相同的语言回复
实战经验：
- 这条规则解释了为什么 Kimi Code 很少给你"教科书式"的解释——它被训练成先做事，再说事。
- "使用与用户相同的语言"是自动检测的，所以如果你用中文提问，它默认用中文回复。但如果上下文里英文内容太多，它可能会"漂移"，需要适时提醒。
3.5 AGENTS.md 相关规则
- AGENTS.md 可出现在项目任何层级
- 深层 AGENTS.md 优先于父目录
- 用户直接指令优先级最高
- 修改 AGENTS.md 中提到的内容时，必须同步更新 AGENTS.md
实战经验：
- 这是 Kimi Code CLI 的项目级自定义入口，
AGENTS.md是目前最可靠的项目规则定义方式。 - 层级覆盖逻辑很重要：子目录的
AGENTS.md可以覆盖父目录的规则，适合 monorepo 场景。
3.6 通用行为准则
- HELPFUL, CONCISE, ACCURATE
- 不要偏离任务目标
- 不要给用户超出需求的东西
- 避免幻觉，事实核查
- 保持简单，不要过度复杂化
四、容易混淆的概念：系统指令 vs 环境信息
在梳理过程中，我发现 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 失去了对项目状态的完整感知。
五、层级结构：系统指令、AGENTS.md、用户指令的优先级
理解这三者的关系，是解决"AI 老是忘记规则"问题的核心：
┌─────────────────────────┐
│ ① 用户直接说的话 │ ← 最高优先级
│ (每次对话的实时指令) │
├─────────────────────────┤
│ ② AGENTS.md │ ← 项目级覆盖
│ (项目任何层级，深层优先) │
├─────────────────────────┤
│ ③ 平台系统指令 │ ← 全局默认
│ (你无法直接编辑) │
└─────────────────────────┘
为什么 AI 会"忘记"你的规则？
答案：上下文稀释（Context Dilution）。
系统指令虽然优先级高，但 AI 的上下文窗口是有限的。当对话变得非常长时，平台会对历史消息进行压缩（compaction）。这个过程中：
- 系统指令通常被保留（它们在最前面）
- 但
AGENTS.md的内容、你之前强调的自定义规则、项目结构信息可能被压缩或摘要化 - 一旦这些项目级上下文丢失，AI 就会退回到"平台默认行为"
解决方案：
- 把最重要的规则写进
AGENTS.md（项目根目录），它在每次会话开始时会被加载 - 对于关键决策，在对话中明确引用
AGENTS.md中的规则 - 定期让 AI 重新读取
AGENTS.md来"刷新记忆"
六、当前 Kimi Code CLI 的局限与 Workaround
截止到目前的版本，Kimi Code CLI 在项目级规则持久化方面还比较基础：
- ❌ 没有专门的项目规则文件机制来自动加载项目级上下文
- ⚠️
AGENTS.md可以起到部分作用，但需要手动维护，没有自动挂载保证 - ⚠️ 用户偏好没有独立的持久化存储，主要靠
AGENTS.md模拟
Workaround：用 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 不是故意忘记规则，而是它的"记忆"机制和我们人类的直觉完全不同。
它的系统指令是分层、优先级驱动的，而不是"说过一次就永远记住"。
有效的 AI 协作需要建立三层"契约"：
- 平台层：了解系统指令的默认约束（如 Git 安全规则），顺势而为
- 项目层：通过
AGENTS.md建立项目专属规则，这是目前 Kimi Code 最可靠的自定义入口 - 对话层：在长对话中适时提醒关键约束，或让 AI 重新读取项目文件刷新上下文
希望这篇整理对你使用 Kimi Code CLI 有所帮助。如果你也做过类似的探索，或者有更好的 workaround，欢迎在评论区交流。
参考信息
- Kimi Code CLI 官方文档：moonshotai.github.io/kimi-cli
- MCP（Model Context Protocol）规范：modelcontextprotocol.io
- 本文整理自与 Kimi Code CLI 的直接对话，系统指令内容基于 AI 的自我陈述，非官方文档
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！
标签：
相关文章
最新发布
点击排行
本站推荐
