起因

用 Claude Code 和 Codex 这类 AI CLI 工具，如果只是"打开就聊"，那跟用网页版 ChatGPT 没区别。真正的威力在于三个进阶用法：

1. 定义角色和规则——让 AI 知道它是谁、该遵守什么规范
2. 开多个 subagent 并行干活——一个任务拆成几块，同时跑
3. 全自动运行——给个清晰的目标，AI 自己干到完成为止

这篇文章把这四件事一次讲清楚。

需求

• 给 Claude Code 定义项目级规则（CLAUDE.md）
• 给 Codex 定义项目级规则（AGENTS.md）
• 创建多个 subagent，各自负责不同任务，并行执行
• 开启全自动模式，AI 无需人工干预运行到目标达成
• 全自动模式下，目标描述必须清晰，规则边界必须明确

定义角色和规则

Claude Code：CLAUDE.md

CLAUDE.md 是 Claude Code 的项目级（或用户级）配置文件，放在项目根目录或 ~/.claude/ 下。Claude 启动时自动读取，作为系统提示的一部分。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 项目规则

## 技术栈
- 后端：Go 1.22 + Gin
- 前端：React 18 + TypeScript
- 数据库：PostgreSQL

## 代码规范
- 函数必须有注释
- 错误必须显式处理，不允许 panic
- 提交信息格式：type(scope): description

## 常用命令
- 构建：make build
- 测试：make test
- 本地运行：make dev

## 绝对不允许
- 修改 .env 文件
- 执行 git push --force
- 删除 migrations 目录

这个文件的核心价值是：你不需要每次会话都重复告诉 AI 这些规则。写得越具体，AI 的行为越可预测。

Codex：AGENTS.md

AGENTS.md 是 Codex 的等价物，放在项目根目录（对当前项目生效）或 ~/.codex/ 下（全局生效）。语法和内容跟 CLAUDE.md 几乎一样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Project Instructions

## Build & Test
- Run tests: npm test
- Type check: npm run typecheck

## Code Style
- Use TypeScript strict mode
- All functions must have JSDoc
- Commit messages in English

## Directory Structure
- src/     core source code
- scripts/ build scripts

两个工具的规则文件机制几乎相同：都是自动加载、都是 Markdown 格式、都可以项目级和用户级分开。区别只是文件名不同——CLAUDE.md vs AGENTS.md。

规则文件写什么

好的规则文件不是写给 AI 看的散文，而是可执行的约束清单。核心三类内容：

其中"硬性禁止"最重要——这部分对应后面要讲的规则边界，也是全自动模式下 AI 不会越界的保障。

多 Subagent 并行

什么是 Subagent

Subagent 是 Claude Code 的一个机制：你可以定义多个专门的"子代理"，每个有自己的角色描述、可用工具、模型选择。主 agent 通过 Task tool 把任务委派给它们。

关键特性：

• 上下文隔离：每个 subagent 有自己独立的上下文窗口，不会污染主对话
• 工具白名单：可以给每个 subagent 限定能用什么工具（比如只读不给写）
• 并行执行：多个 subagent 可以同时跑，结果汇总回主对话

创建 Subagent

在 .claude/agents/（项目级）或 ~/.claude/agents/（用户级）目录下创建 Markdown 文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

---
name: code-reviewer
description: 代码审查，检查质量和安全问题
tools: Read, Glob, Grep
model: sonnet
---

你是一名严格的代码审查员。审查代码时重点关注：
- 安全漏洞（SQL 注入、XSS、硬编码密钥）
- 性能问题（N+1 查询、不必要的循环）
- 可读性（命名、注释、函数长度）
输出格式：问题列表，每条包含严重级别和具体修改建议。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

---
name: test-writer
description: 为指定模块编写单元测试
tools: Read, Glob, Grep, Edit, Bash
model: sonnet
---

你是一名测试工程师。根据提供的模块路径：
- 阅读源码，理解功能
- 用项目现有的测试框架编写测试
- 运行测试确认通过
- 输出：测试文件路径 + 覆盖的功能点

并行调用示例

主 agent 在对话中自然调用 subagent。比如一次大重构，可以拆成：

1
2
3
4
5
6

主 agent: "把 auth 模块重构成 JWT 认证，同时保持 API 兼容"

→ 委派给 code-reviewer："审查当前 auth 模块的实现，列出所有需要改动的点"
→ 委派给 test-writer："为 auth 模块现有功能补充测试基线"
→ 两个 subagent 并行执行，结果汇总
→ 主 agent 根据结果实施重构

Subagent 的权限控制

每个 subagent 可以通过 frontmatter 精确控制权限：

1
2
3
4
5

---
name: safe-researcher
description: 只读研究，不修改任何文件
tools: Read, Grep, Glob, Bash   # 只允许这些工具
---

或者反过来，用 disallowedTools 禁止特定工具，继承其余：

1
2
3
4
5

---
name: no-writes
description: 除了写文件，其他都能干
disallowedTools: Write, Edit
---

这种设计让最小权限原则很容易落地：一个只负责搜索的 agent，就不该有写文件的权限。

全自动运行

Claude Code 的 Auto Mode

Auto Mode 是 Claude Code 的一种权限模式：用一个分类器模型在命令执行前自动审查，安全操作直接放行，高风险操作才拦截提示。大致能自动批准 90% 以上的常规操作。

开启方式（三选一）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 命令行启动时指定
claude --permission-mode auto

# 会话中切换
Shift + Tab

# 写入配置（默认开启）
# ~/.claude/settings.json
{
  "permissions": {
    "defaultMode": "auto"
  }
}

Auto Mode 的拦截规则：

分类器会拦截的操作包括：可能泄数据的操作、降低系统安全性的操作、跨信任边界的操作（比如访问非当前项目的目录）等。

边界（Boundary）规则：

在 Auto Mode 下，你可以用 permissions.ask 和 permissions.deny 精确定义哪些操作始终提示、哪些操作永远禁止：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "permissions": {
    "defaultMode": "auto",
    "ask": [
      "Bash(git push:*)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(.env)",
      "Bash(curl * | sh)"
    ]
  }
}

• ask：分类器也无法自动批准，始终弹窗确认
• deny：直接阻止，不可覆盖

Claude Code 的 /goal 模式

/goal 模式解决的是另一个问题：不是单条命令的权限，而是整个任务的完成度。

用法：在会话中输入 /goal <条件>，Claude 会持续工作，每轮结束后由一个小型评估器模型检查条件是否达成，没达成就继续干，直到评估器判定通过。

1

/goal npm test 退出码为 0 且 npm run build 成功

工作流程：

1. 你把目标和完成条件告诉 Claude
2. Claude 执行一轮操作
3. 评估器模型检查条件：达成 → 结束；未达成 → 把原因反馈给 Claude，继续下一轮
4. 重复直到目标达成

好的 goal 条件 vs 坏的 goal 条件：

关键原则：评估器只能看到对话记录，所以条件必须是"主模型能在对话里证明的事"——命令输出、测试日志、编译结果，这些都可以；“生产环境没有脏数据"这种评估器看不到的东西就不行。

Auto Mode + /goal 组合

两者解决不同维度的问题，组合使用效果最佳：

• Auto Mode：减少单轮内的权限确认弹窗
• /goal：保证多轮任务持续运行直到完成

一个典型的全自动工作流：

1
2
3
4
5

1. 启动 claude --permission-mode auto
2. 定义好 CLAUDE.md 规则边界
3. /goal 给出清晰的可验证目标
4. Claude 全自动执行：写代码 → 跑测试 → 看结果 → 修 bug → 再跑测试
5. 评估器判定条件达成，自动结束

Codex 的全自动

Codex 没有 /goal 的等价物，但可以通过配置文件 + 命令行参数实现接近的效果：

1
2
3

# ~/.codex/config.toml
approval_policy = "on-failure"
sandbox_mode = "workspace-write"

on-failure 意味着：沙箱内操作直接放行，只有沙箱拒绝（越界操作）时才弹窗。配合 workspace-write（限制只能写工作区），就是 Codex 的"全自动"模式：

1

codex --full-auto

等价于 --sandbox workspace-write --approval on-failure。

关键实践：目标要清晰，边界要明确

无论 Claude Code 还是 Codex，全自动模式下有两个铁律：

铁律一：目标必须可验证

不要写"帮我优化代码”，要写"npm run build 无警告且所有测试通过"。

不要写"修复登录功能"，要写"curl -X POST localhost:8080/api/login -d '{"user":"test","pass":"test"}' 返回 200 和 JWT token"。

目标越具体，AI 的自主循环越不容易跑偏。

铁律二：边界必须明确

全自动模式下，AI 有很高的自主权，所以必须提前用规则文件和权限配置把"绝不能碰的线"画清楚：

在 CLAUDE.md / AGENTS.md 里写"不要修改 .env"是一种约束，但写在 permissions.deny 里才是硬边界——前者是建议，后者是强制执行。

总结

核心思路一致：用 Markdown 文件定义"你是谁、你该遵守什么"，用权限配置定义"你绝不能做什么"，然后给 AI 一个可验证的目标，让它自己跑到完成。

参考链接

• Claude Code 官方文档：创建自定义 Subagents
• Claude Code Auto Mode 配置文档
• Claude Code Goal 模式指南
• Claude Code Agent Teams