开发者用 AI：编程智能体、费用与安全的任务交接

怎么做

1. 1交给它之前，先写好或指明检查方式：失败的测试，或者命令及其预期输出。
2. 2用本页的提示词给它布置任务，写明哪些文件可以改，哪些不可以。
3. 3让它自己运行检查，并贴出最终输出。
4. 4像审查同事的 pull request 一样审查 diff；检查通过只是审查的开始，而不是结束。

内置功能

• ChatGPT · Codex
• Claude · Claude Code

可复制的提示词

任务：[改动内容]。
完成的标准：[测试或命令] 通过，并输出 [预期输出]。结束前运行它，并把结果贴出来。
你可以修改：[路径]。不要修改：[路径]、依赖项或测试。
如果你没法让它通过，就停下来说明原因，而不是绕过这项检查。

容易出错的地方

• 智能体有时会通过削弱测试来让它通过。禁止修改测试，并在 diff 里留意这种情况。
• 一项检查覆盖不了的任务，也就大到不适合一次交出去。把它拆开。

怎么做

1. 1选离你的代码最近的那个：Codex Cloud、GitHub 上的 Copilot cloud agent，或 Claude Code on the web。
2. 2确保它的环境能安装你的依赖项并运行你的测试；否则智能体只能靠猜。
3. 3像上面那项任务一样，发送小而独立的任务，每项都配有自己的检查。
4. 4先让自动审查工具读一遍每个 pull request，然后你自己再审查。

内置功能

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

可复制的提示词

在这个代码库中：[任务]。
背景：[代码中的位置、相关 issue]。
完成的标准：[测试或命令] 在你的环境中通过；把它的输出写进 pull request 的描述里。
pull request 的改动控制在 [n] 行以内。如果需要更多改动，就停下来，提出拆分方案。

容易出错的地方

• 需要机密信息或你没有配置的服务的测试，会被跳过或失败。缺了它们，即使全部通过也说明不了什么。
• 几个智能体同时处理相关代码，产生的 pull request 会相互冲突。让并行任务各管不同的区域。

怎么做

1. 1把构建、测试和 lint 命令写进智能体在每次会话开始时读取的指令文件；每个智能体的文档都写明了这个文件叫什么。
2. 2在 Claude Code 中添加 hook，在每次编辑后运行格式化工具和测试，这样智能体就能看到失败并加以修复。
3. 3让机器人审查每个 pull request：在 Codex 中开启“Automatic review”，或请求 Copilot 担任审查者。
4. 4智能体同一个错误犯了两次，就把它变成一个测试，或指令文件里的一条规则。

内置功能

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

可复制的提示词

阅读这个代码库，为编程智能体写一份指令文件：
1. 安装、构建、测试、lint 和格式化的确切命令。
2. 项目结构，不超过 10 行。
3. 新人在这里容易弄错的约定，每条附一个例子。
4. 智能体在这里绝对不能做的事，比如修改迁移文件或编辑自动生成的文件。
只列出你成功运行过的命令；其余的标注为“未验证”。

容易出错的地方

• 指令文件里的命令如果已经不能用了，会让智能体学会忽略这个文件。配置有变化时，重新运行一遍这些命令。
• 审查机器人也会自信地犯错。把它们的评论当作建议。

怎么做

1. 1列出你最常粘贴到对话里的内容，比如 issue、错误日志、文档或数据库结构。先连接这些。
2. 2为每一项添加官方 MCP 服务器，并使用只能读取的令牌。在 Gemini CLI 中，一个扩展可以把 MCP 服务器及其配置打包在一起。
3. 3给它一个需要用到这些连接的任务，检查它调用的是不是正确的那个。
4. 4每隔几周，删掉你不再使用的服务器。

内置功能

• Gemini CLI · Extensions

可复制的提示词

在修改任何东西之前：读取问题跟踪系统中的 issue [编号]，在日志中找到错误，并查阅 [库] 的文档。
说明每一项分别告诉了你什么，以及你认为哪个文件出了问题。
不要向任何已连接的工具写入内容。

容易出错的地方

• 网页、issue 或文档里可能包含专门用来操纵智能体的文字。不要给会读取外部内容的工具写入权限。
• 写在配置文件里的令牌会泄露。使用客户端的机密存储或环境变量，绝不要放进代码库。

怎么做

1. 1先看看你已经在为什么付费：ChatGPT 的方案包含 Codex，Claude 的付费方案包含 Claude Code。
2. 2在智能体显示 token 用量的地方，记下几次典型会话的用量。
3. 3在我们的 API 价格页面上为这些用量算出费用，再与订阅对比。
4. 4自动化和 CI 使用设了支出上限的 API 密钥，以免一个死循环刷出一大笔账单。

内置功能

• ChatGPT · Codex
• Claude · Claude Code

可复制的提示词

这是我 [n] 次典型会话的用量：[输入和输出 token 数]。我每周大约工作 [天数] 天。
按以下价格估算我每月按 token 计费的费用：[从 API 价格页面粘贴]。
把它和每月 [价格] 的订阅对比。写出计算过程，方便我核对。

容易出错的地方

• 订阅也有用量限制。任务进行到一半撞上限制会浪费时间；不只要看价格，还要看限制。
• 对账单影响最大的是模型。按你实际使用的模型来对比。

怎么做

1. 1在代码库中运行 /init：它会分析代码库并写出一份初始的 CLAUDE.md；如果已经有了，它会提出改进建议。
2. 2团队规则（比如构建和测试命令、编码规范）放在 ./CLAUDE.md 中并提交。你自己的偏好放在 ~/.claude/CLAUDE.md（对所有项目生效），或 CLAUDE.local.md（只对当前项目生效）。
3. 3较长的文档不要粘贴进去，而是引用它们：@path/to/file 会在启动时导入另一个文件。
4. 4Claude 每次在同一件事上错了两次，就加上那一行本可以避免这个错误的说明。

可复制的提示词

阅读这个代码库并改进 CLAUDE.md。控制在 60 行以内：
1. 构建、测试和 lint 的确切命令。
2. 用几行说明项目结构。
3. 新人在这里容易弄错的约定。
4. 绝对不能编辑的文件和文件夹。
删掉所有已经不再属实的内容。你没有运行过的命令标注为“未验证”。

容易出错的地方

• CLAUDE.md 里的所有内容每次会话都会加载，并占用上下文。把细节移到它导入的文件里。
• 已经不再属实的指令比没有还糟。配置有变化时，重新检查这些命令。

官方文档原文： Claude Code docs: How Claude remembers your project

怎么做

1. 1按 Shift+Tab，直到状态栏显示“plan mode on”，或者在提示词开头加上 /plan。
2. 2描述要做的改动，以及哪些东西不能变。Claude 仍然可能运行命令来探索代码，但在制定计划期间不会编辑文件。
3. 3像读设计说明一样读这份计划：文件找错了、漏了某种情况、改动太大。要求修改，直到计划正确，然后批准。
4. 4开始下一项无关的任务之前，用 /clear 重新开始。

可复制的提示词

/plan 修改 [什么]，以便 [目标]。约束：[哪些不能变]。
列出你会改动的文件、改动的顺序、证明每一步正确的测试，以及你不确定的地方。在我批准之前，不要编辑任何东西。

容易出错的地方

• 计划改动的文件比你预想的多，就是一个警告信号。批准之前问清原因。
• 计划模式仍然会运行命令来探索。它并不能让一个陌生的代码库变得可以放心运行。

官方文档原文： Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

怎么做

1. 1打开 /permissions，查看每条规则以及它来自哪个设置文件。
2. 2把团队规则放在 .claude/settings.json 中并提交。个人规则放在 ~/.claude/settings.json 或 .claude/settings.local.json 中。
3. 3规则的检查顺序是先 deny，再 ask，最后 allow，所以一条 deny 规则优先于任何 allow 规则。
4. 4用 Shift+Tab 切换模式：acceptEdits 会自动批准工作目录中的文件编辑。bypassPermissions 会关闭提示和安全检查；文档说只应在没有互联网访问的隔离容器或虚拟机中使用它。

可复制的提示词

看看你在这次会话中运行过的命令。为 .claude/settings.json 提出权限规则：允许我们每天都用的只读命令和测试命令，拒绝任何读取机密信息或删除项目以外内容的操作，其余的都保留为询问。每条规则用一行解释。

容易出错的地方

• 一条能匹配任何命令的 allow 规则，等于完全没有提示。只允许确切的命令。
• .claude/settings.json 中的规则一旦提交，就对整个团队生效。像审查代码一样审查它们。

官方文档原文： Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

怎么做

1. 1在无关的任务之间，/clear 会以空的上下文开始一段新的对话。
2. 2在长任务中，带上重点执行 /compact（例如“/compact 保留计划和失败的测试”），它会总结之前的内容。
3. 3把大范围搜索交给子智能体：每个子智能体都在自己的上下文窗口中运行，所以只有它的答案会回到你的会话中。
4. 4Claude Code 在接近上限时也会自动压缩；在合适的时机自己压缩，保留的是你选择的内容。

内置功能

• Claude Code · Subagents

可复制的提示词

/compact 保留：目标、计划、目前为止改动过的文件，以及仍然失败的测试。丢掉探索过程。

容易出错的地方

• /clear 会忘掉这段对话。凡是你之后还会用到的内容，都要先写进 CLAUDE.md。
• 你能拿回来的只有子智能体的答案。要求它给出文件路径和行号，而不只是结论。

官方文档原文： Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

怎么做

1. 1用 claude --worktree <name>（或 -w）启动每次会话。它会在 .claude/worktrees/<name>/ 下创建一个 git worktree，分支为 worktree-<name>。
2. 2按文档的建议，把 .claude/worktrees/ 加入 .gitignore。
3. 3每次会话只给一项任务，并配上它自己的检查，这样你可以逐一审查。
4. 4像对待其他 pull request 一样审查并合并每个分支。

可复制的提示词

你正在分支 worktree-[名称] 上的一个 worktree 中工作。任务：[一项改动]。完成的标准：[测试或命令] 通过。只在这个分支上提交；不要合并或变基其他分支。

容易出错的地方

• 每个 worktree 都是独立的文件夹，所以依赖项和构建输出不共享。在每个 worktree 中分别安装。
• 无论用不用 worktree，两项改动同一批文件的任务，在合并时仍然会冲突。

官方文档原文： Claude Code docs: Run parallel sessions with worktrees

怎么做

1. 1在空的输入框中按两次 Esc，或输入 /rewind（/checkpoint 和 /undo 也可以）。
2. 2选择出错之前的那个时间点，恢复对话、代码，或两者都恢复。
3. 3了解它的限制：被 rm、mv 或 cp 等 shell 命令改动的文件不会恢复，在 Claude Code 之外或在另一次会话中做的编辑也不会恢复。
4. 4在有风险的步骤之前先提交。检查点用于在会话内快速恢复，不能代替 git。

可复制的提示词

开始之前，先提交当前状态，提交信息写“[任务] 之前的检查点”。然后 [任务]。执行任何删除或移动文件的命令之前，先问我。

容易出错的地方

• Rewind 找不回被命令删除的文件。只有 git 可以。
• 在此期间你手动做的编辑也不会被记录。回退之前先把它们提交。

官方文档原文： Claude Code docs: Checkpointing · Claude Code docs: Commands

怎么做

1. 1claude -p "..." 以非交互方式运行。--output-format json 或 stream-json 会给出脚本可以解析的输出。
2. 2成功时退出码为 0，失败时为非零值，因此 CI 可以据此决定后续步骤。
3. 3在 CI 中加上 --bare，让运行不依赖本地配置。
4. 4对于 pull request，/install-github-app 会设置 Claude Code GitHub Actions（仅限 github.com 上的代码库）；之后在 pull request 或 issue 的评论中提及 @claude 即可。

可复制的提示词

claude -p "阅读与 main 之间的 diff。列出所有新增依赖、涉及身份验证或修改数据库迁移的改动，以 JSON 格式输出：{\"files\": [], \"reason\": \"\"}。如果没有，就返回空列表。" --output-format json

容易出错的地方

• 脚本以你给它的权限运行。只给 CI 它所需的最小权限。
• /install-github-app 只适用于 github.com 上的代码库。

官方文档原文： Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

怎么做

1. 1在 CLI 中运行 /init，在当前文件夹中写出一份初始的 AGENTS.md。
2. 2个人指导写在 ~/.codex/AGENTS.md 中，项目规则放在代码库里。子文件夹可以有自己的文件；离 Codex 工作位置越近的文件越优先。
3. 3文件要保持简短：它们的总大小有上限，默认是 32 KiB。
4. 4添加一个“## Code Review Rules”部分：Codex 在 GitHub 上的审查会遵循它。

可复制的提示词

阅读这个代码库并写出 AGENTS.md：
1. 安装、构建、测试和 lint 的确切命令。
2. 用几行说明项目结构。
3. 新人在这里容易弄错的约定。
4. 一个“## Code Review Rules”部分，写明审查者必须始终标出的问题。
只列出你成功运行过的命令；其余的标注为“未验证”。

容易出错的地方

• 文件太长会适得其反：总大小默认上限为 32 KiB。
• 子文件夹里的文件如果和根目录的文件相矛盾却不加说明，会让人和 Codex 一样困惑。写明它覆盖了哪些内容。

官方文档原文： Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

怎么做

1. 1在 CLI 中，/permissions 用于切换模式，/status 会显示当前生效的审批策略和可写文件夹。
2. 2“Ask for approval”是推荐的默认模式，它在工作区内编辑文件、运行命令，越出工作区之前会暂停。
3. 3“Approve for me”保留同样的沙盒，但把审批请求交给自动审查，而不是交给你。
4. 4“Full access”会去掉文件系统和网络限制。文档对此附有警告；只在可以随时丢弃的环境中使用它。

可复制的提示词

开始之前，运行 /status，告诉我审批策略和可写文件夹。然后 [任务]。任何需要联网或在这个代码库之外写入的命令，执行之前先问我。

容易出错的地方

• 使用“Approve for me”时，没有人会逐条阅读请求。只在错误操作很容易撤销的场合使用。
• “Full access”作用于整台机器，而不只是这个代码库。

官方文档原文： Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

怎么做

1. 1codex exec "..." 以非交互方式运行，默认使用只读沙盒。
2. 2需要编辑文件时加上 --sandbox workspace-write；--full-auto 已被弃用。
3. 3--json 会输出 JSON Lines 格式的事件流，供需要了解每一步的脚本使用。
4. 4在 GitHub Actions 中，openai/codex-action@v1 会替你运行 codex exec。

可复制的提示词

codex exec "阅读自标签 [v1.2.0] 以来的改动。撰写发布说明，按新增、变更和修复分组：每项改动一行，用用户能看懂的话来写，不要写提交哈希。"

容易出错的地方

• 较早的指南仍在使用 --full-auto。它已被弃用；请使用 --sandbox workspace-write。
• 只需读取的任务就应保持只读，在 CI 中也一样。

官方文档原文： Codex docs: Non-interactive mode · Codex docs: GitHub Action

怎么做

1. 1CLI 中的 /review 会审查你的工作树。codex review 不通过聊天完成同样的事，可以针对某个基准分支、某个提交或未提交的改动。
2. 2在 GitHub 上，在 pull request 中评论 @codex review。
3. 3在 Codex 设置的“Personal preferences”下开启自动审查；之后就不需要评论了。
4. 4把团队的规则写在 AGENTS.md 的“## Code Review Rules”部分中。

内置功能

• Codex · Codex code review

可复制的提示词

## Code Review Rules
- 标出任何涉及身份验证或权限的改动。
- 标出无法回滚的数据库迁移。
- 标出新增的依赖项，并说明是否必要。
- 忽略格式问题；lint 工具会处理。

容易出错的地方

• GitHub 上的审查只标出 P0 和 P1 问题。没有评论并不代表设计是对的。
• 审查是第二意见，不是测试运行。测试还是要保留。

官方文档原文： Codex docs: CLI commands · Codex docs: GitHub integration

怎么做

1. 1创建一个环境，包含任务所需的代码库、依赖项、工具和访问设置。新环境会记录一个安装脚本和一个启动 skill。
2. 2为每个环境分别设置互联网访问：仅限包管理器、指定的域名，或全部放开。
3. 3可以从 ChatGPT 启动任务；较长的工作可以从 IDE 扩展启动；也可以在终端用 codex cloud exec 启动；--attempts 1-4 会要求尝试多次，以便对比。
4. 4Code Review 以及 GitHub 和 Linear 集成仍然运行在旧版 Codex Cloud（Legacy）上，OpenAI 计划将其停用。

内置功能

• Codex · Codex Cloud

可复制的提示词

codex cloud exec --attempts 3 "任务：[改动]。背景：[文件]。完成的标准是 [测试] 在这个环境中通过。diff 控制在 [n] 行以内。"

容易出错的地方

• 不受限制的互联网访问会让任务能访问任何网站，包括专门写来操纵它的网页。只允许任务所需的访问。
• 如果缺少安装脚本，测试可能根本没有运行。确认任务真的运行了测试。

官方文档原文： Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

怎么做

1. 1在 ~/.codex/config.toml 中设置默认模型和推理强度（model 和 model_reasoning_effort）。CLI 和 IDE 扩展共用这个文件。
2. 2把 profile 写成单独的文件 ~/.codex/<name>.config.toml，并用 --profile <name> 启动。
3. 3用 codex mcp add <name> -- <command> 添加 MCP 服务器；每个服务器都会成为一个 [mcp_servers.<name>] 表，/mcp 会列出当前启用的服务器。
4. 4/status 显示当前生效的设置，codex resume --last 会接着这个文件夹中最近的一次会话继续。

可复制的提示词

阅读 ~/.codex/config.toml 和这个项目的 .codex/config.toml。告诉我当前生效的模型、推理强度、沙盒和 MCP 服务器，每项分别来自哪个文件，以及任何相互冲突的地方。

容易出错的地方

• 项目设置只在受信任的项目中加载。如果某项设置似乎被忽略了，先检查这一点。
• profile 现在是单独的文件。把 [profiles.name] 写在 config.toml 里的指南已经过时了。

官方文档原文： Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands