在终端里与 AI 结对编程：/plan 和 /init 的协作体验
作为一名习惯在终端里完成大部分工作的开发者，最近几个月我一直在使用 Claude Code。有两个命令显著改变了我分析代码和规划功能的方式： /init 和 /plan。它们不是"让 AI 替你写代码"，而是让 AI 在你还未动手时，就帮你理清上下文和思路。
/init：让 AI 读懂你的项目
/init 是我进入一个新项目时最先运行的命令。它会扫描整个项目目录结构，分析依赖、构建脚本、代码风格和项目约定，最终生成一份 CLAUDE.md 文件，相当于一份为 AI 量身定制的"项目说明书"。
一个典型场景是：你克隆了一个有几百个文件的开源项目，完全不知道该从哪里读起。以前我会从 README 出发，翻 package.json，再跳进入口文件，一点点拼凑出项目骨架——这个过程轻松花掉一两个小时。现在 /init 在几十秒内就能完成同样的梳理工作，生成的文档涵盖项目概述、构建命令、测试运行方式、目录结构说明等。
更关键的是后续效果。/init 生成的上下文会被 AI 持续参考。当你后续在项目里写代码或提问时，AI 的回复不会凭空编造一套不存在的约定，而是贴合项目已有的技术栈和编码风格。这解决了 AI 编程工具最令人头疼的问题——写出与项目格格不入的代码。
/plan：把模糊想法变成可执行方案
如果 /init 回答的是"这个项目是什么"，那 /plan 回答的是"我该怎么改"。
在日常开发中，我经常拿到一个模糊的需求——比如"给用户模块加上权限控制"。以前我的习惯是在脑子里快速过一遍，然后直接动手。结果通常是写到一半发现漏了边界情况，改了 A 文件发现还要联动改 B 和 C，来来回回返工。这不是能力问题，而是"边想边做"天然的信息盲区。
/plan 的工作方式强制你在动手之前暂停思考。你描述需求后，AI 会主动阅读相关代码，理解现有架构，然后输出一份实现计划：涉及哪些文件、每个文件的改动点、有什么技术决策需要你确认。你可以跟它讨论其中任何一步，调整方案，直到你满意为止，然后再开始写代码。
这很像一次小规模的技术评审，区别是它发生在终端里，通常只需要几分钟。我观察到一个很有意思的现象：使用 /plan 后，我真正写代码的时间反而缩短了——因为在计划阶段预演过了，动手时几乎没有意外。
两个命令的组合拳
实际工作中，这两个命令通常是配合使用的。最近我做了一个数据看板功能的开发——
先用 /init 确保 AI 理解项目架构（React + ECharts + 自研数据处理层），然后用 /plan 规划组件拆分方式、数据流走向和性能优化点。
令我印象深刻的是在 /plan 阶段，AI 指出我设计中的一个盲区：我打算在前端直接对大数据集排序和聚合，但 AI 发现项目中已有一套带缓存机制的数据处理层，建议我将这些重操作下沉到数据层复用。这是我自己很可能踩到的坑，如果在编码阶段才发现，返工代价会大得多。
这恰恰体现了终端+AI 协作的核心价值：它不是你告诉 AI 写什么它就执行什么，而是在你动手之前帮你审视方案、发现盲区。
协作的边界感
使用一段时间后我最大的感受是：好的 AI 工具不是越"自动"越好，而是边界感恰当。/init 帮你建立上下文，/plan 帮你理清思路——但它们始终让你掌握决策权和方向盘。这种节奏让"先想清楚再动手"从一个需要刻意维持的习惯，变成了工作流里自然而然的环节。
终端里敲下 /init 和 /plan，本质上是在用一个极低的成本，换取一个更清晰的开发起点。对于一个追求效率的开发者来说，这也许是 AI 协作最踏实的打开方式。
