还在把 AI 当聊天工具用?我现在才明白这件事-夜雨聆风

还在把 AI 当聊天工具用?我现在才明白这件事

适合谁看：你已经在用 AI 写代码、做项目，但经常遇到 AI “忘事”、状态不稳、每次都要重新解释同样的背景——你想让这件事变得更可靠、更系统。

你可能有过这样的经历：

昨天让 AI 按照你的风格写代码，今天打开新对话，它完全不记得了。解释了半天项目背景，AI 终于明白了，但接下来写了一百行错误方向的代码。想让它每次写完都跑一遍测试，但每次都要重新说。改了好几个文件之后，你发现它把你明确说不能动的东西给改了。

这不是你的问题，也不是 AI 变蠢了。

这是结构性缺失。 你把所有东西都堆在一次对话里，AI 没有稳定的记忆、没有固定的规则、没有分工。

这种”和 AI 随缘聊着写代码”的方式，有一个名字叫 Vibe Coding。

它能跑，但跑不稳。

这篇文章要聊的，是下一步：让 AI 在轨道上跑，而不是靠运气。

核心思路：五层结构

在深入每一层之前，先建立整体图像。

你的项目/├── CLAUDE.md                 ← AI 的"项目记忆"，每次启动自动读取└── .claude/    ├── commands/             ← 快捷指令，把重复的提示词变成 /一个词    ├── agents/               ← 专岗 AI，每个只干一件事    ├── skills/               ← 可复用的领域知识，像培训手册    ├── hooks/                ← 自动规则，特定事件触发，不用提醒    ├── rules/                ← CLAUDE.md 的补充，按主题拆分    └── settings.json         ← 权限、模型、行为的总开关

遇到什么问题，用什么工具：

场景	用什么
AI 总是忘记项目背景	CLAUDE.md
每天都要重复同样的提示词	Commands
任务很复杂，想让多个 AI 分工	Agents
某个领域有很多规范和易错点	Skills
某件事希望自动发生、不用每次提醒	Hooks
CLAUDE.md 太长需要拆分	Rules

第一层：CLAUDE.md — 项目记忆

解决什么问题

每次打开新对话，AI 就”失忆”了。

CLAUDE.md 是放在项目根目录的一个文本文件，Claude Code 启动时自动读取。你在里面写什么，AI 就记住什么。

怎么写

核心内容分三块：

第一块：交代背景

# 项目说明这是一个帮用户管理读书笔记的小工具。用户可以添加书、记笔记、打标签、导出为 PDF。技术用的是 Python + Flask，数据存在 SQLite 里。

第二块：操作手册

## 常用命令启动：python app.py测试：pytest tests/ -v格式化代码：black . && isort .

这一块最重要。衡量标准只有一个：任何人第一次拿到这个项目，只靠这个文件就能跑起来。 如果做到了，说明写到位了。

第三块：规矩

## 规矩- 不能修改 config/production.yaml- 提交代码前必须通过所有测试- 函数命名用下划线风格，不用驼峰- .env 文件不能提交到 Git

几个经验性建议

控制在 200 行以内

：不是技术限制，是实用经验——内容越多，重要规则越容易被稀释
写验证方式而不只是写规则

：”运行 pytest 验证通过”比”必须写测试”管用，因为 AI 可以自己检查
发现 AI 犯了新错误就更新它

：CLAUDE.md 不是写完就放着的，每次 AI 翻车都是更新它的机会

第二层：Commands — 你的快捷词库

解决什么问题

你每天可能重复问 AI 同样的问题：

“帮我看看这段代码有没有问题”
“帮我写这个功能，先列步骤再动手”
“帮我把这次改动整理成 commit”

Commands 让你把这些固定流程变成一个 /斜杠词，放进 .claude/commands/ 目录，提交到 Git，团队共享。

文件结构

.claude/└── commands/    ├── implement.md      → 输入 /implement 触发    ├── review.md         → 输入 /review 触发    └── commit.md         → 输入 /commit 触发

写一个你自己的 Command

新建 .claude/commands/implement.md：

---description: 实现一个新功能，包含代码和测试---实现以下功能：$ARGUMENTS在开始之前：1. 先分析现有代码结构，找到最合适的位置2. 给我一个实现步骤列表，等我确认3. 写实现代码4. 写对应的测试，运行确认通过

使用时直接输入：

/implement 用户登录功能，支持邮箱和密码

什么值得做成 Command？ 一个简单判断：你在 AI 对话里说过超过 3 次的同一段话，就值得做成 Command。

第三层：Agents — 专岗 AI

解决什么问题

你让同一个 AI 又写代码又检查代码，就像让同一个人当作者也当校对，很难客观。

Agents 让你可以给不同任务配不同的 AI，每个 Agent 有自己的角色定位、工具权限和隔离的上下文。

和 Command 的关键区别

	Commands	Agents
运行方式	在当前对话里执行	开一个全新的独立对话
上下文	和你共享	完全隔离
适合	流程指导、重复操作	需要专注的独立子任务

一个真实的 Agent 配置示例

---name:reviewerdescription:提交代码前，主动用这个agent做代码评审maxTurns:10tools:-Read-Grep-Glob---你是一名专注代码质量的评审员。你只读文件，不修改任何东西。评审时检查以下几点：1.有没有明显的bug或边界情况未处理2.有没有安全风险（比如直接把用户输入拼进SQL）3.代码是否清晰易懂，命名是否准确4.关键路径是否有测试覆盖输出格式：-🔴严重问题（必须改）-🟡建议（可以考虑改）-✅做得好的地方

注意 maxTurns: 10——限制最多执行步数，防止 Agent 失控跑偏。

第四层：Skills — 可复用的专业知识

解决什么问题

你做了很多项目，积累了很多”这么干才对”的经验。Skills 让你把这些经验打包成可复用的知识文件，注入到 Agent 或直接调用。

类比：给 AI 上一次培训课，上完课它就记住你项目的规范，不用每次从零讲。

Skills vs Agents

	Agents	Skills
是什么	会做事的 AI	教 AI 怎么做的知识
类比	员工	员工的培训手册
用法	委派任务	注入到 Agent 或直接加载

一个 Skill 示例

新建 .claude/skills/my-api-style/SKILL.md：

---name: my-api-styledescription: 设计 REST API 接口时使用这个技能---# 我的 API 设计规范## URL 命名- 用名词，不用动词：/users 而不是 /getUsers- 用复数：/articles 而不是 /article- 版本号在前：/v1/users## 返回格式（统一）{  "success": true,  "data": ...,  "message": "成功"}## 常见的坑- 删除接口返回 204，不要返回包含 data 的 200- 分页统一用 page 和 page_size 参数- 不要在 GET 请求里改数据- 列表接口必须有 total 字段

关键建议：Skill 里最有价值的内容是常见的坑——把 AI 默认做错的事专门写出来，效果远大于写”应该怎么做”。

第五层：Rules — 补充规则

解决什么问题

当 CLAUDE.md 开始变长，维护起来越来越困难，可以用 Rules 把规则按主题拆分出去。

使用方式

.claude/rules/├── code-style.md      ← 代码风格规范├── git-workflow.md    ← Git 提交规范└── security.md        ← 安全相关规则

Claude Code 会自动加载 .claude/rules/ 下的所有文件。

建议：前期不用主动做这一步，等 CLAUDE.md 超过 200 行、开始难以维护时再拆分。

进阶：Hooks — 自动执行的规则

Hooks 让你配置”事件触发器”——在特定时机自动执行脚本。比如：

每次 AI 写完代码，自动格式化
AI 要执行危险命令（rm、pip install 等），自动弹出确认
AI 完成任务时，播放提示音

一个立刻就能用的配置——在 settings.json 加入以下权限控制：

{"permissions":{"ask":["Bash(rm *)","Bash(rmdir *)","Bash(npm *)","Bash(pip *)","Bash(docker *)"]}}

加了这段，AI 每次想执行这些命令，都会先暂停来问你是否确认。

新手建议：先把前五层搞顺，再回来研究 Hooks。

从哪里开始

按这个顺序，每次只做一件事：

第 1 步（今天就能做）：创建 CLAUDE.md

cd 你的项目touch CLAUDE.md# 写上项目简介 + 启动命令 + 测试命令 + 3 条规矩

第 2 步：加 Commands

mkdir -p .claude/commands# 把你最常说的那句提示词写成命令文件

第 3 步：加 Agent

mkdir -p .claude/agents# 先做一个 reviewer，代码提交前让它帮你检查

第 4 步：加 Skills

mkdir -p .claude/skills/your-style# 把你的项目规范和常见坑写进去

第 5 步：拆分 Rules（CLAUDE.md 超过 200 行时）

mkdir -p .claude/rules# 按主题把规则从 CLAUDE.md 搬过来

精选技巧

以下技巧来自 Claude Code 的实际使用经验，直接可用。

跟 AI 沟通

让 AI 主动挑你的刺说”用这些改动质问我，通过你的测试之前不提交代码”——比你自己说”帮我检查”更有效，AI 会主动找问题。

不满意时，推倒重来说”了解了所有情况后，推倒重来，用最优雅的方案实现”——比”在这基础上修改”效果更好，AI 不会被旧的思路束缚。

小 bug 不用废话直接粘贴报错说”修复”，不要告诉它怎么修，让它自己判断。

关于计划

永远先做计划稍微复杂的任务，先让 AI 列步骤，你确认后再开始写代码。这是今天就能落地的最有效习惯。

让第二个 AI 来评审你的计划先让一个 Claude 写计划，再开一个新对话，让另一个 Claude 以”资深工程师”视角挑毛病——同一个模型换了上下文会发现完全不同的问题。

上下文管理

切新任务用 /clear换了一个新任务，用 /clear 清空对话，而不是在旧对话里继续堆东西。

反悔神器：Esc EscAI 改错了？连按两次 Esc，撤销到上一步。比在对话里说”帮我改回去”可靠得多。

上下文用到一半就压缩输入 /compact，不要等 AI 开始”忘事”才处理。用 /context 查看当前使用量。

Git 习惯

PR 永远只做一件事每个 PR 专注一个功能或修复，更容易审查，出问题也容易回滚。

频繁提交任务完成就提交，粒度越细，越容易追溯问题。

常见的错误做法

错误做法	后果	正确做法
第一天把所有最佳实践都堆进 CLAUDE.md	超过 500 行，AI 开始忽略	先写 50 行，遇到问题再补
创建很多 Agent 但不给明确分工	Agent 之间互相干扰	每个 Agent 只做一件事
Skills 写成通用的”应该怎么做”	AI 不当回事	重点写”坑”和”不这样做会出什么问题”
先做 Hooks 再做 CLAUDE.md	复杂度超过收益，半途而废	严格按顺序来
实现和验收交给同一个 AI	AI 自己写自己验，发现不了问题	用独立的 Agent 或独立对话做 QA

附录：目录结构速查

你的项目/├── CLAUDE.md                    ← 项目记忆（必做）└── .claude/    ├── settings.json            ← 权限配置    ├── commands/                ← 快捷指令    │   ├── implement.md    │   └── review.md    ├── agents/                  ← 专岗 AI    │   └── reviewer.md    ├── skills/                  ← 领域知识包    │   └── my-api-style/    │       └── SKILL.md    ├── hooks/                   ← 自动触发规则（进阶）    └── rules/                   ← 补充规则（CLAUDE.md 过长时拆分）

附录：常用命令速查

命令	作用
`claude`	在当前目录启动
`/clear`	清空对话，开始新任务
`/compact`	压缩上下文
`/model`	切换模型
`/config`	设置界面
`/context`	查看当前上下文使用量
`/rename [名字]`	给当前会话命名
`/resume`	恢复历史会话
`/doctor`	诊断安装问题
`Esc Esc` （连按两次）	撤销上一步操作

参考仓库：shanraisshan/claude-code-best-practice

整理于 2026 年 4 月