开场个人观察

前面几篇文章里，我写了 AI 编程助手、AI Agent 工作流，以及普通开发者使用 AI 时需要守住的边界。写到 Codex 这一篇时，我更想把它写成一篇可以反复翻回来的实践笔记。

Codex 这类工具和普通聊天机器人不太一样。普通聊天机器人更像一个问答窗口，你问一句，它答一句；Codex 更像一个可以进入项目、阅读代码、修改文件、运行命令、解释结果的开发协作者。OpenAI 官方把 Codex 描述为用于软件开发的 coding agent，可以帮助写代码、理解陌生代码库、review 代码、调试问题和自动化开发任务。

但工具越强，越不能随便用。很多人第一次用 Codex，会把它当成“高级代码生成器”：给一句需求，期待它马上给出完美代码。这样当然偶尔能成功，但不稳定。真正稳定提升效率的方法，是把 Codex 放进一套清楚的工程流程里：准备上下文、明确任务、让它先计划、让它小步实现、跑测试、看 diff、复盘沉淀。

下面这 10 个技巧，是我理解里最适合普通开发者落地的用法。

技巧一：把需求写成一个小 issue，而不是一句口号

很多人对 Codex 的第一句提示是：“帮我优化一下代码。”这句话的问题不是太短，而是没有验收标准。什么叫优化？是性能变快、代码更短、结构更清楚，还是减少重复？如果没有边界，Codex 只能猜。

更好的写法，是把任务写成一个小 issue：

1
2
3
4
5

目标：给订单列表增加按状态筛选功能。
范围：只改订单列表页和相关查询参数，不调整全局路由。
验收：页面出现状态筛选框；选择状态后列表刷新；刷新页面后筛选条件保留。
验证：运行 npm test，并手动检查订单列表页。
限制：不要重构无关组件，不要修改接口返回结构。

这种写法看起来啰嗦，但它会显著降低返工。Codex 最怕的不是任务复杂，而是任务含糊。你越能把“想要什么”和“不要什么”说清楚，它越容易给出可 review 的结果。

我的经验是：凡是超过十分钟的开发任务，都值得先写成小 issue。即使最后不是交给 Codex 做，这个过程也能帮自己想清楚。

技巧二：为仓库准备 AGENTS.md，把长期规则沉淀下来

如果每次都在提示里重复“项目用 pnpm”“测试命令是 npm test”“不要改 public 目录”“提交前要跑 lint”，时间久了会很烦，而且容易漏。

Codex 支持通过 AGENTS.md 这类仓库说明文件获得项目规则。你可以把它理解成给 AI 看的 README：告诉它项目结构、常用命令、代码风格、测试方式、哪些目录不能动、遇到失败时如何处理。

一个简单的 AGENTS.md 可以这样写：

1
2
3
4
5
6
7

# 项目规则

- 文章源码在 source/_posts。
- 静态资源放在 source/images。
- public 是生成目录，非必要不要手写修改。
- 修改文章后需要运行生成命令，并检查 archives 页面。
- 保持 Markdown front matter 格式：title/date/tags。

这类规则越早沉淀，后面越省心。Codex 做得不稳定，很多时候不是模型能力问题，而是项目没有把“好结果长什么样”告诉它。

技巧三：先让 Codex 读代码和写计划，不要直接开改

面对一个真实项目，我不建议第一步就让 Codex 修改文件。更稳的方式是先让它做两件事：

第一，阅读相关代码并总结当前结构。

第二，给出准备修改的计划。

比如可以这样说：

1
2

先不要修改代码。请阅读和用户登录相关的文件，说明当前登录流程、
token 存储位置、错误处理方式，然后给出最小修改计划。

这一步的价值很大。它能让你提前发现 Codex 是否找对了入口、是否理解了业务、是否准备改错层级。如果计划已经偏了，就不要让它继续实现。

对复杂任务来说，“先计划再实现”比“直接生成代码”慢几分钟，但通常能省掉半小时返工。

技巧四：一个任务只做一个焦点，避免让 Codex 一次背太多锅

人类开发也一样，一个 PR 同时做登录、样式、数据库迁移、依赖升级，review 会非常痛苦。Codex 更是如此。

好的任务应该是可切分、可验证、可回滚的。比如：

不太好的任务：

1

帮我把后台系统整体优化一下，顺便修几个 bug，再加点测试。

更好的拆法：

1
2
3

任务1：修复用户列表分页参数丢失问题。
任务2：给用户列表补充分页相关测试。
任务3：整理用户列表组件里重复的状态判断。

每个任务都有一个焦点，Codex 就不容易迷路。你也更容易 review 它的输出。

技巧五：让 Codex 小步实现，并要求解释关键取舍

Codex 能一次性生成很多代码，但“大量生成”不等于“高效”。我更喜欢让它小步推进：

1
2
3
4
5

先完成最小可运行版本，不要做额外抽象。
完成后说明：
1. 改了哪些文件；
2. 为什么这样改；
3. 哪些地方可能需要后续优化。

这样做有两个好处。

第一，你能快速看到方向是否正确。

第二，Codex 会被迫解释自己的取舍，而不是只给结果。

当它解释“为什么这样改”时，你很容易看出它有没有理解项目。如果解释含糊，就继续追问；如果解释清楚，再进入下一步。

技巧六：把测试命令写进任务，而不是事后才想起来

Codex 的一个重要价值，是它可以帮你运行测试、构建、类型检查、格式检查等命令。但前提是它知道应该跑什么。

所以在任务里直接写：

1
2
3
4
5
6

完成后请运行：
- npm test
- npm run lint
- npm run build

如果某个命令失败，请说明失败原因、是否和本次改动有关，以及你如何处理。

如果项目没有自动化测试，也可以写手工验证标准：

1
2
3
4

没有单元测试。请生成后检查：
1. archives 页面出现 2026 年分组；
2. 新文章页面能打开；
3. 中文标题和标签显示正常。

这比“你看着办”可靠得多。Codex 可以帮你执行验证，但验证标准应该由人来定。

技巧七：把 Codex 用在阅读和定位上，不只是写代码

很多人低估了 Codex 的阅读能力。实际工作里，最耗时间的不一定是写代码，而是弄清楚代码在哪里、数据怎么流、为什么这个 bug 会出现。

有些特别适合交给 Codex 的阅读任务：

1

请梳理这个接口从路由到数据库查询的调用链。

1

请找出用户头像上传失败可能经过的所有错误处理分支。

1

请比较这两个组件的重复逻辑，说明是否值得抽公共组件。

这类任务风险低，收益高。即使最后不让 Codex 改代码，它也能帮你节省大量翻文件的时间。

我的习惯是：先让 Codex 当“代码导游”，再决定要不要让它当“代码作者”。

技巧八：用 /review 或明确 review 指令，让它站到审查者角度

写代码和审代码是两种不同心态。让 Codex 生成代码之后，最好再让它切换角色：

1
2
3
4
5
6

请以 code review 的角度检查刚才的改动，重点看：
1. 是否有无关文件改动；
2. 是否有未处理的异常路径；
3. 是否有兼容性风险；
4. 是否缺少测试；
5. 是否引入了过度抽象。

OpenAI 的 Codex 最佳实践也强调，不要只让 Codex 改代码，还要让它创建测试、运行检查、确认结果并 review 工作。这个思路非常重要：Codex 不应该只是“生产代码”，还应该帮助发现代码里的风险。

当然，AI review 不能代替人类 review。它更像第一道自动筛查，可以提前发现低级问题、遗漏分支和不一致风格。最终是否接受，仍然要人判断。

技巧九：权限要克制，默认从安全配置开始

效率和权限不是一回事。给 Codex 越多权限，它能做的事越多，但风险也越高。

比较稳的原则是：

第一，默认使用沙箱和审批。

第二，不把生产密钥、真实用户数据、内部敏感信息交给它。

第三，危险命令必须先说明目的，再由人确认。

第四，部署、删除、迁移、批量替换这类任务要格外谨慎。

官方最佳实践里也提到，如果刚开始使用 coding agent，应该从默认权限开始，保持 approval 和 sandboxing 收紧，等你理解工作流之后，再对可信仓库或特定流程放宽。

这点我很赞同。AI 工具最容易制造一种错觉：既然它能做，就让它全做。但工程里真正可靠的方式，是最小权限、可观察、可回滚。

技巧十：每次用完都复盘，把经验写回项目

Codex 用得好不好，不只取决于一次提示词，还取决于你有没有把经验沉淀下来。

每次任务结束后，可以复盘几个问题：

第一，哪些上下文给得有效？

第二，Codex 哪一步误解了？

第三，哪些测试命令必须写进下次任务？

第四，哪些规则应该放进 AGENTS.md？

第五，有没有可以沉淀成固定提示模板？

比如你发现 Codex 总是忘记运行某个检查，就把它写进 AGENTS.md。你发现某类任务总要提醒“不要修改生成目录”，也写进去。你发现某种 review checklist 很有效，就整理成 code_review.md，以后让 Codex 引用。

这就是复利。第一次用 Codex，可能只是省一点时间；第十次之后，如果规则、模板、测试、权限都沉淀好了，它省下的就不只是写代码时间，而是整个工程流程的沟通成本。

一个完整的使用模板

下面是我比较推荐的一段 Codex 任务模板，可以按项目改：

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

请完成以下任务：

目标：
- ...

范围：
- 允许修改：
- 不要修改：

上下文：
- 相关文件：
- 当前现象：
- 期望行为：

实现要求：
- 先阅读相关代码并给出计划。
- 计划确认后再修改。
- 保持改动最小，不做无关重构。

验证要求：
- 运行：
- 如果无法运行，请说明原因。
- 最后总结改动、验证结果和剩余风险。

这个模板看起来很普通，但它能解决大部分“AI 写偏了”的问题。因为它把目标、范围、上下文、实现、验证都拆开了。

总结

Codex 提高效率的关键，不是让开发者少思考，而是把重复、明确、可验证的工作交出去，让开发者把精力放在判断、设计和质量把关上。

我认为最值得记住的是这 10 点：

1. 把需求写成小 issue。
2. 用 AGENTS.md 沉淀项目规则。
3. 先让 Codex 读代码和写计划。
4. 一个任务只做一个焦点。
5. 小步实现，并解释关键取舍。
6. 把测试命令写进任务。
7. 让 Codex 帮你阅读和定位。
8. 用 review 指令检查风险。
9. 默认收紧权限和沙箱。
10. 每次用完都复盘沉淀。

用 Codex 最好的状态，不是“我完全不管，它自动完成”，而是“我把任务定义清楚，它帮我推进，我负责判断和验收”。这样才是真正稳定的软件工程效率提升。

参考资料

• OpenAI Codex
• OpenAI Codex best practices
• OpenAI Codex announcement

开场个人观察

AI 工具变强之后，最容易出现两种极端看法。一种是觉得它什么都能做，开发者很快就不重要了；另一种是觉得它经常出错，所以完全不值得用。

我的感受比较中间：AI 很有用，但它不是魔法。它能帮我们节省大量搜索、整理、样板代码和重复验证的时间，也会在上下文不足、需求模糊、边界复杂时犯错。关键不是用不用，而是知道在哪些边界内用。

对普通开发者来说，我认为最重要的是三条边界：成本边界、隐私边界、正确性边界。只要这三条边界想清楚，AI 就会从一个让人焦虑的新东西，变成一个可以稳定使用的工具。

核心观点

AI 的能力越强，越不能无脑使用。因为它不只是生成几句话，还可能参与代码修改、文档总结、日志分析、数据处理，甚至操作开发环境。

一个成熟的使用方式，不是问“AI 能不能做这件事”，而是问三个问题：

第一，这件事交给 AI 做，成本是否划算？

第二，交给 AI 的上下文里，有没有不该暴露的信息？

第三，AI 给出的结果，能不能被验证？

如果这三个问题都能回答清楚，就可以大胆用。如果回答不清楚，就应该缩小任务范围，或者干脆自己处理。

实践方法

先说成本边界。AI 的成本不只是钱，还包括时间和注意力。一个简单命令、一个熟悉 API、一个五分钟能写完的函数，如果反复和 AI 解释背景，可能反而更慢。比较适合交给 AI 的，是那些信息量大、重复性高、需要整理但风险可控的任务，比如读一批代码总结结构、补测试用例初稿、整理迁移步骤、生成文档草稿。

再说隐私边界。不要把密钥、生产数据库、用户隐私数据、公司内部敏感信息直接贴给 AI。即使工具声称有企业级保护，也应该遵守最小暴露原则。能脱敏就脱敏，能用样例数据就不用真实数据，能描述结构就不要贴完整内容。

最后是正确性边界。AI 的回答必须可验证。代码要能跑测试，SQL 要能解释执行计划，配置要能在测试环境验证，技术结论要能找到官方文档或源码依据。对于无法验证的内容，最多只能当成思路，不能当成结论。

我自己比较喜欢把 AI 任务分成三类。

第一类是低风险任务，可以直接让它做，比如整理 Markdown、解释报错、生成脚手架、翻译英文文档。

第二类是中风险任务，可以让它做初稿，但必须 review，比如修改业务代码、补单元测试、调整配置。

第三类是高风险任务，只能让它辅助分析，不能直接执行，比如生产数据修复、权限策略、支付金额计算、安全漏洞处理。

这样分层之后，使用 AI 会稳很多。不是每次都纠结“能不能信”，而是先判断任务风险，再决定让它参与到什么程度。

踩坑提醒

第一个坑是把“说得像真的”当成“真的”。AI 很擅长组织语言，所以它的错误也可能很顺。遇到版本号、API 行为、兼容性、法律合规、安全策略这些问题，最好看官方资料。

第二个坑是把完整代码库一次性丢给 AI。上下文越多不一定越好，关键是相关。给太多无关信息，既增加成本，也可能让它抓错重点。

第三个坑是用 AI 掩盖自己没想清楚的问题。如果需求本身模糊，AI 只能扩大这种模糊。比较好的做法是先让它帮你把需求拆清楚，再进入实现。

第四个坑是跳过复盘。每次 AI 帮你完成一个任务，都可以回头看一下：哪些提示有效，哪些地方它误解了，哪些验证步骤必不可少。用 AI 也需要积累经验。

总结

普通开发者使用 AI，不需要追每一个新模型，也不需要把所有工作都交出去。真正重要的是建立边界感。

成本边界提醒我们：不是所有问题都值得用 AI。

隐私边界提醒我们：不是所有上下文都可以交给 AI。

正确性边界提醒我们：不是所有回答都能直接相信。

把这三条边界守住，AI 就会是一个很好的放大器。它放大的不是偷懒，而是开发者已经具备的判断力、表达能力和工程习惯。

参考资料

• OpenAI Codex announcement
• OpenAI Agents docs
• GitHub Copilot cloud agent docs

开场个人观察

以前说到 AI 编程，大多数人想到的是代码补全：写一半函数，它帮你补完；写一个注释，它生成几行实现。这当然有用，但它更像是键盘旁边的加速器。

现在越来越多工具开始强调 Agent。Agent 和普通聊天助手最大的区别，是它不只是回答问题，而是可以围绕一个目标持续执行：读仓库、找文件、改代码、运行命令、生成 diff、创建分支，甚至提交 pull request。

这让我想到以前搭建 Hexo 博客的时候，很多事情都是一步一步手工来：写 Markdown、生成静态文件、检查页面、部署到 GitHub Pages。今天这些步骤仍然存在，只是其中一部分可以交给 AI Agent 帮忙跑。开发者要做的，不再只是“亲手敲完每一步”，而是设计一个可靠的工作流。

核心观点

AI Agent 时代的开发工作流，本质上是从“同步结对”走向“异步委派”。

同步结对很好理解：你坐在编辑器前，AI 在旁边补代码，你一边看一边改。这适合探索、小修小补、快速理解代码。

异步委派则更像给同事派任务：你把目标、背景、限制、验收标准说清楚，让 agent 自己在一个隔离环境里完成，然后你再 review 它的结果。OpenAI Codex 和 GitHub Copilot cloud agent 这类工具，都在往这个方向发展。

这并不意味着开发者可以完全放手。恰恰相反，工作流变复杂之后，人更需要把关。一个好的 agent 任务，应该像一个好的 issue：背景明确、范围可控、验收清楚、失败时容易回滚。

实践方法

我理解的 AI Agent 开发工作流，可以分成四步：任务委派、计划、实现、审查。

第一步是任务委派。不要只写一句“优化一下项目”。更好的写法是：“请阅读文章列表生成逻辑，新增 2026 年文章后确认归档页按年份展示；不要修改主题样式；完成后运行 hexo generate 并说明结果。”这样的任务有目标、有边界、有验证方式。

第二步是计划。Agent 动手之前，最好先让它说明会改哪些地方、为什么要改、如何验证。这个环节非常重要，因为很多错误不是发生在写代码时，而是发生在理解需求时。方向错了，代码越多越麻烦。

第三步是实现。实现时要鼓励 agent 小步提交思路，而不是一次性做大改。比如先新增文件，再运行生成，再检查输出。每一步都有反馈，问题就容易定位。

第四步是审查。审查不是简单看它说“已完成”，而是看实际 diff、命令输出和页面效果。尤其是自动生成内容、批量替换、依赖升级、部署脚本这类任务，一定要确认没有改到不该改的地方。

如果团队里使用 GitHub 工作流，还可以把 agent 的输出放到 PR 里处理。这样人类 review、CI、讨论记录都还在原来的工程体系里，不会因为用了 AI 就绕过质量门禁。

踩坑提醒

第一个坑是把 Agent 当成万能自动化。Agent 能执行任务，但它依赖上下文和工具权限。环境不完整、依赖装不上、测试命令缺失、文档过时，都会让它走偏。

第二个坑是权限给得太大。能读仓库、能改文件、能跑命令已经很强了，如果再加上网络、密钥、生产环境权限，就必须非常谨慎。Agent 适合在隔离环境里处理开发任务，不适合不经审查直接操作生产系统。

第三个坑是没有验收标准。人类开发者接到模糊需求会反问，Agent 往往会直接猜。猜出来的结果可能看上去很完整，但并不一定是你要的东西。

第四个坑是忽略团队习惯。一个项目原来怎么写测试、怎么发版、怎么做 code review，不应该因为引入 AI 就全部推翻。更好的方式是让 AI 进入现有流程，而不是让流程迁就 AI。

总结

AI Agent 带来的变化，不只是“写代码更快”，而是开发任务的组织方式变了。以前很多事情必须人一直盯着做，现在可以把一部分明确任务放到后台执行，人再回来审查结果。

但越是这样，越需要工程纪律。任务要小，边界要清楚，验证要真实，权限要克制，结果要 review。Agent 做的是执行和辅助判断，人做的是方向、责任和最后确认。

我觉得这会成为 2026 年之后开发者的一项基本能力：不是和 AI 比谁写代码快，而是学会把 AI 放进可靠的软件工程流程里。

参考资料

• OpenAI Codex announcement
• OpenAI Agents docs
• GitHub Copilot cloud agent docs

开场个人观察

从 2017 年之后，这个博客停了很久。中间几年技术变化很多，但真正让我觉得开发方式被改变的，不是某一个框架，也不是某一种语言，而是 AI 编程助手变得越来越像一个可以一起干活的同事。

刚开始用 AI 的时候，我更习惯把它当成搜索引擎的升级版：问一个概念，让它解释；贴一段报错，让它分析；想不起某个 API，就让它补一下示例代码。这个阶段确实有用，但用久了会发现，它只是让“查资料”变快了，并没有真正改变开发流程。

到了 2026 年，我对 AI 编程助手的理解变了。它不是简单替我写几行代码，而是参与到“理解需求、阅读代码、拆分任务、修改实现、运行验证、总结结果”的整个链路里。真正的差别不在于它能不能生成代码，而在于它能不能在一个真实项目里按上下文做事。

核心观点

我现在更愿意把 AI 编程助手看成一种协作工具，而不是答案机器。

答案机器的使用方式是：“我问一个问题，你给我一个答案。”这种方式适合查概念、写小片段、解释命令，但一旦进入真实项目，就很容易失真。因为真实项目里最重要的不是“这段代码理论上怎么写”，而是“在这个项目已有结构里应该怎么改”。

协作工具的使用方式则不一样。我们需要先让 AI 了解项目背景，再把任务拆成可验证的小步骤，然后让它读代码、提出方案、做修改、跑检查。最后人再 review 它的 diff，而不是直接相信它的结论。

这也是我认为 2026 年普通开发者最该掌握的能力：不是会不会问“帮我写一个函数”，而是会不会把问题描述成一个清楚、边界明确、可以验收的开发任务。

实践方法

第一步是给上下文。不要只说“帮我修一下这个 bug”，而是说清楚现象、期望、相关文件、怎么复现、什么不能改。如果项目里有测试命令，也应该直接告诉它。AI 最怕的是上下文不完整，它会用猜测填空，而猜测在工程里通常会变成 bug。

第二步是拆任务。比如要做一个功能，不要一上来就让 AI “完整实现”。更稳妥的方式是先让它读相关代码并说明当前结构，再让它给出改动计划。计划确认之后，再让它动手实现。这样做的好处是，中间每一步都能纠偏，不至于最后得到一大坨看起来很努力但方向不对的代码。

第三步是看 diff。AI 写代码再快，也不能跳过 review。尤其要看三类地方：有没有改到无关文件，有没有引入过度抽象，有没有把异常路径处理得过于乐观。很多时候 AI 的代码能跑通主流程，但边界条件会比较脆。

第四步是跑测试。没有测试的项目，至少也要跑构建、启动、本地页面检查，或者准备几个手工验证步骤。AI 的自信程度和代码正确率不是一回事。它说“应该可以”没有意义，命令输出和实际页面才有意义。

第五步是让它总结。每次完成一个任务后，我会让 AI 说明改了什么、为什么这样改、跑了哪些验证、还有什么风险。这个总结不是形式主义，它能帮助人快速进入 review 状态，也能暴露它有没有真的理解任务。

踩坑提醒

第一个坑是把 AI 生成的代码当成最终答案。它可以很快给出一个能看的版本，但工程质量还需要人来兜底。尤其是权限、金额、隐私、并发、删除数据这些地方，不能因为它写得顺手就直接合并。

第二个坑是一次性给太大的任务。任务越大，AI 越容易在中途丢失重点。一个比较好的经验是，把任务拆到“一个 PR 可以清楚 review”的大小。如果你自己都说不清验收标准，AI 更不可能稳定完成。

第三个坑是只追求速度。AI 最容易制造一种错觉：好像所有事情都能马上完成。但软件开发里，快只是其中一个指标。可维护、可验证、符合项目风格，很多时候比快更重要。

第四个坑是忽略成本。2026 年的 AI 工具已经越来越强，但强模型、长上下文、多轮对话、后台 agent 都是有成本的。日常开发中，简单问题可以用轻量方式解决，复杂问题再交给更强的模型或 agent。

总结

AI 编程助手真正改变的，不是让开发者不用写代码，而是让开发者可以把一部分明确、重复、可验证的工作委派出去。开发者的价值并没有消失，反而更集中在判断、设计、拆解、验证和取舍上。

如果把 AI 当成搜索框，它只是一个更快的问答工具；如果把它当成协作对象，就需要给它上下文、边界和验收标准。2026 年重新理解 AI 编程助手，我觉得关键就在这里：少一点神奇想象，多一点工程方法。

参考资料

• OpenAI Codex announcement
• OpenAI Agents docs
• GitHub Copilot cloud agent docs

开场个人观察

前面已经写过一篇比较完整的 Claude Code 常用指令整理，那篇更像一张命令地图；这篇我想写得更贴近日常项目使用：如果只记几个最常用的指令，应该先记哪些？每个指令到底在项目里怎么用？

Claude Code 的指令很多。官方命令页也提醒，输入 / 可以看到当前环境可用的命令，命令必须放在消息开头才会被识别；并且不是每个命令都会出现在每个人的环境里，平台、计划、版本和登录状态都会影响可见范围。所以我不建议一上来背完整命令表。

我的做法是先掌握一条主线：项目初始化用 /init 和 /memory，复杂任务用 /plan，长会话用 /context 和 /compact，验收用 /diff 和 /code-review，方向错了用 /rewind。这几个指令能覆盖大多数日常开发场景。

核心观点

Claude Code 指令的作用，不是让你少写自然语言，而是让会话进入正确模式。一个真实开发任务通常不是“问一句、答一句”，而是要经历理解项目、制定计划、修改文件、验证结果、审查风险几个阶段。

如果没有指令，你当然也可以用自然语言表达这些意图，比如“先不要改代码，先给计划”。但指令的好处是更稳定、更明确，也更适合形成习惯。

我会把最常用指令分成四类：

第一类是项目记忆：/init、/memory。

第二类是任务控制：/plan、/model、/effort。

第三类是上下文管理：/context、/compact、/clear。

第四类是验收和恢复：/diff、/code-review、/rewind。

不用一口气全记住。先把这四类放进开发流程里，用几次之后自然就熟了。

实践方法

1. /init：新项目第一步

/init 适合在第一次进入项目时使用。它通常会帮助生成项目级说明，比如 CLAUDE.md，让 Claude Code 了解项目结构、常用命令和开发约定。

我会这样用：

1

/init

生成之后不要直接结束。你应该手工检查里面的内容，把真实规则补进去：

1
2
3
4
5

- 安装依赖使用 npm install --no-package-lock。
- 文章源文件在 source/_posts。
- 图片放在 source/images。
- public 是生成目录，不要手动写业务内容。
- 修改文章后要生成静态站并检查 archives 页面。

/init 的价值不在生成那一刻，而在后面每次任务都能复用这些项目规则。

2. /memory：把重复提醒沉淀下来

如果你发现自己反复对 Claude Code 说同一句话，比如“不要升级依赖”“先看 diff”“生成后检查归档页”，就应该考虑用 /memory 管理项目记忆。

我会在一次任务结束后补一句：

1

/memory

然后把稳定规则整理进去。注意，记忆文件不适合放一次性需求。比如“今天新增一篇文章”不该写进去；“新增文章必须包含 title/date/tags”才适合写进去。

3. /plan：复杂任务先停一下

/plan 是我最常用的指令之一。只要任务会改多个文件、涉及配置、可能影响线上页面，我都会先让它计划。

示例：

1

/plan 把博客里最近几篇文章日期从 6 月 10 日改成 5 月份随机日期，再新增一篇 6 月 1 日文章。先列出要改的源文件、图片文件、生成和部署验证步骤。

好的计划应该包含四件事：会看哪些文件、会改哪些文件、怎么验证、风险在哪里。如果计划里出现“顺便升级 Hexo”这种越界动作，就要立刻纠正。

4. /model 和 /effort：控制成本和思考深度

不是所有任务都需要最高强度。改错别字、补一段说明、生成一张简单流程图，可以用较低成本；跨模块重构、排查线上问题、做安全审查，就值得提高推理强度。

你可以在任务前调整模型或思考深度：

1
2

/model
/effort

我的习惯是：普通写作和小修用默认设置；涉及发布、权限、数据变更、复杂回归时，再提高投入。这样不会为了小任务浪费太多资源。

5. /context：看看会话被什么占满了

长会话最怕的是上下文越来越乱。你已经换了三个任务，但对话里还塞着前一个任务的日志、diff、错误输出，Claude Code 就可能开始抓错重点。

这时可以用：

1

/context

它的作用是让你看清上下文占用。如果当前任务已经和前面的内容关系不大，就应该压缩或清空，而不是继续往上堆。

6. /compact：把长会话压成可继续的摘要

如果任务还没完，但上下文太长，我会用 /compact。关键是不要只输入一个裸命令，而是告诉它保留哪些东西：

1

/compact 请保留当前目标、已经修改的文件、尚未完成的验证、遇到的错误和下一步计划。

这样压缩后继续工作，方向更不容易丢。它适合长任务，不适合完全换题。如果你要做一个全新的任务，/clear 往往更合适。

7. /diff：验收前先看真实改动

/diff 是防止 AI 编程失控的核心指令。Claude Code 的总结可能写得很漂亮，但真正要 review 的是文件改动。

我一般会在实现后说：

1

/diff

然后重点看这几类问题：

是否改了无关文件；

是否误动配置、锁文件、部署脚本；

是否把临时路径、token、内部地址写进代码；

是否只改了正文但忘了生成资源；

是否删除了历史页面。

不要把 /diff 当成形式。它是开发者重新拿回控制权的地方。

8. /code-review：提交前再过一遍

/code-review 适合在提交前使用。官方命令说明里提到，它会检查 diff 中的正确性问题和可清理点。我的理解是，它像一次额外 review，但不能替代你自己看关键逻辑。

可以这样用：

1

/code-review

如果是高风险改动，可以补充要求：

1

/code-review 请重点看权限、数据删除、异常分支、测试缺口和是否改到无关文件。

对于博客项目，我会让它重点看 front matter、图片路径、生成页面、归档链接和中文编码。

9. /rewind：方向错了及时回退

很多人用 AI 工具时会有一个坏习惯：发现方向错了，还继续让它“修一下”。补丁叠补丁之后，diff 会越来越难看。

这时应该考虑：

1

/rewind

它的意义是回到一个更干净的检查点。特别是当 Claude Code 改了太多无关文件、误解了需求、或者尝试升级依赖导致项目乱掉时，及时回退比继续修补更稳。

10. /clear 和 /resume：切换任务与找回会话

如果当前任务已经结束，准备开始另一个独立任务，可以用：

1

/clear

它会开启更干净的上下文。之后如果需要找回旧会话，可以用：

1

/resume

我的习惯是：同一任务用 /compact 延续，不同任务用 /clear 切开。这样不容易把两个任务的上下文混在一起。

踩坑提醒

第一个坑，是把命令当成魔法。比如用了 /plan，不代表计划一定正确；用了 /code-review，不代表没有 bug。命令只是让流程更清楚，最终判断还在开发者手上。

第二个坑，是不看本机可用命令。Claude Code 文档明确说，不是每个命令都会在每个环境出现。最稳的方法是在自己的会话里输入 /，看当前真实可用列表。

第三个坑，是在长会话里不断换任务。AI 会尽量利用已有上下文，但旧上下文不一定对新任务有帮助。任务之间要么压缩，要么清空。

第四个坑，是把项目规则只写在聊天里。只在当前会话里说过的规则，很容易下一次就忘。长期规则应该进入 CLAUDE.md、memory、项目文档或 skill。

第五个坑，是跳过验证。无论用什么指令，最后都要落到测试、构建、页面检查、人工 review 上。没有验证的“完成”，只是文字上的完成。

总结

如果只记 Claude Code 的几个常用指令，我会按这个顺序记：/init、/memory、/plan、/context、/compact、/diff、/code-review、/rewind。

它们对应的不是孤立功能，而是一条项目开发主线：建立记忆，计划任务，管理上下文，检查改动，必要时回退。把这条主线用熟，比背完整命令表更有价值。

参考资料

• Claude Code commands reference
• Claude Code CLI reference
• Claude Code interactive mode