从 VS Code 到命令行：一个 AI Native 开发者的 Claude Code 工作流进化
上篇文章我分享了从 AIGC 到 AI Agent 的进化——Claude Code 作为 VS Code 插件，能直接读写文件、运行命令，真正实现了"有手有脚"的自主开发。
但我用了一段时间后发现一个问题：VS Code 插件虽然方便，但我的工作流被绑定在编辑器里了。
有时候我只是想在终端里快速做个小实验——新建一个目录、写几行代码看看效果。为了用 AI Agent，我还得先打开 VS Code、加载项目、等插件初始化……这个"启动成本"看起来不大，但次数多了，我总觉得哪里不对。
直到我装上了 Claude Code 的命令行工具，才意识到：插件和 CLI，本质上是两种不同的工作范式。
一、从插件到 CLI：更深的集成
Claude Code 最早是以 VS Code 插件的形式出现的。在编辑器里唤出对话面板，Agent 可以直接修改你光标所在的代码。对于"在已有项目中改代码"这个场景来说，这确实是最自然的交互方式。
但 CLI 工具是另一个维度的东西。安装很简单：
npm config set registry https://registry.npmmirror.com/
npm install -g @anthropic-ai/claude-code
全局安装之后，在任何目录下输入 claude，就可以直接启动一个 AI Agent 会话。不需要打开编辑器，不需要加载项目，不需要等待。
这带来的变化是微妙的——你可以在项目初期（甚至还没有项目目录的时候）就启动 AI 对话。比如我想做一个个人网站 jima，直接在终端里：
mkdir jima && cd jima
claude
然后就进入了和 AI Agent 的对话。它问我是否信任这个文件夹，我确认之后，它就开始读目录结构、生成代码、安装依赖。整个过程不离开终端。
对比一下三层进化：
| 阶段 | 工具 | 交互方式 | 启动成本 |
|---|---|---|---|
| AIGC | ChatGPT/豆包 | 网页对话，复制粘贴 | 低，但来回搬运 |
| AI Agent | VS Code 插件 | 编辑器内对话 | 中，需加载 IDE |
| AI Agent | CLI 工具 | 终端直接对话 | 低，即开即用 |
从插件到 CLI，不是功能的增减，而是集成深度的跃迁——它让 AI Agent 变成了终端这个开发者最核心工作台的一部分，而不是附着在某个 IDE 上的额外工具。
二、信任与权限：AI Agent 的安全哲学
第一次启动 claude 命令时，会遇到一个有趣的步骤——它问我："Do you trust this folder?"
如果你选择"是"，Claude Code 就能读写这个目录下的文件、在目录内运行命令。如果你选择"否"，它只能读取代码帮你分析，不能修改任何东西。
这个设计让我停下来想了想。
它背后的逻辑是这样的：一个能够自主读写文件、运行命令的 Agent，本质上就是一个远程程序员。你给它访问权限，就像给一个程序员办公室的门禁卡——它需要看到代码才能工作，需要写文件才能交付，需要跑命令才能验证。
但权限是有边界的。你给的门禁卡只能开这个办公室的门，不能开财务室的门。Claude Code 的信任模型也是一样——你授权的只是当前目录，而不是整个系统。
这就是 Anthropic 反复强调的 最小权限 + 安全边界 原则。
听起来很技术，但翻译成人话就是：给 Agent 足够完成工作的权限，但绝不多给一分。 这不是对 AI 的不信任，而是对安全的基本尊重——就像你不会把服务器 root 密码随便给一个实习生一样。
这其实呼应了我 v003 里写的一个感悟：给 Agent 清晰的边界，它反而能更好地完成任务。 当 Claude Code 知道自己的工作范围就是当前目录，它就不会跑偏到无关的系统配置上去，专注度反而更高。
三、/plan 模式：先规划再执行
用了几天 CLI 之后，我遇到了第二个让我眼前一亮的设计：/plan 模式。
之前我用 AI Agent 的工作流是这样的：写一个 prompt → 交给 Agent 执行 → 看结果 → 不满意再改 prompt → 再执行。这个流程的问题是——prompt 的质量直接决定了结果的质量，但 prompt 本身是"一次性"的。 你写完之后就交给 AI 了，中间没有"对齐"的环节。
/plan 模式改变了这个流程：
输入想法 → /plan → AI 提问 → 你回答 → 生成计划 → 确认 → AI 执行
举个例子，我想用 Claude Code 做一个新项目，但我对这个领域不太熟悉。直接写 prompt 的话，我不知道应该包含哪些关键信息，也不知道什么样的技术选型是合理的。
在 /plan 模式下，Claude Code 会反过来问我问题：
- "这个项目的核心目标是什么？"
- "目标用户是谁？"
- "有什么技术限制或偏好吗？"
- "你期待的交付标准是什么？"
我回答完之后，它会生成一份完整的实施计划——包括技术选型、文件结构、开发步骤。我确认之后，它才开始动手写代码。
这个模式最妙的地方在于：它把"写 prompt"这件抽象的事，变成了一场结构化的对话。 AI 不再是"等我喂 prompt 的工具"，而是"主动帮我理清需求的协作者"。
对我来说，/plan 模式至少有两个价值：
第一，降低领域知识门槛。 当我要做一个不熟悉的项目时，AI 通过提问帮我补齐知识盲区。它知道这个领域的最佳实践，知道哪些技术栈适合我的需求，而我不需要事先都了解。
第二，把"思考"和"执行"分开了。 在做任何事之前，先对齐目标和方案，再动手。这本来是工程开发的常识，但和 AI 合作时我们常常跳过了这一步——因为我们觉得"AI 随时可以改"。
但事实是：思考越充分，执行的迭代次数越少。 /plan 模式强迫你先思考再行动，而这正好是我 v002 里说的"代码向后，业务向前"的另一种表达。
四、Vibe Coding 的再思考
说到这里，我想回头聊聊 Vibe Coding。
在 v001 里，我提到了这个词——"氛围编程"，意思是让 AI 接管编码的细节，开发者只需要沉浸在创造性的氛围中。听起来很美好，对吧？
但经过这段时间的实践，我对 Vibe Coding 有了新的理解：不要直接把任务丢给 LLM。
这不是说 Vibe Coding 不对，而是说我们需要区分"什么可以 vibe"和"什么不能 vibe"。
LLM 擅长的事情是：执行精准、详细、边界明确的任务。 比如"写一个函数，输入是 X，输出是 Y，用 TypeScript，加注释"。这类任务越精确，AI 的执行质量越高。
LLM 不擅长的事情是：替你思考。 如果你说"帮我做一个好用的工具"，它生成的代码大概率是平庸的——因为你没有告诉它什么是"好用"，没有给它评估的标准，没有给它边界约束。
所以 Vibe Coding 的正确姿势不是"让 AI 替你想"，而是**"你想清楚之后，让 AI 替你做"**。
这又回到了 v002 的核心观点——领域知识仍然是护城河。 你越了解你要做的事情，你的 prompt 就越精准，AI 的输出就越好。而 /plan 模式之所以有效，正是因为它帮你补上了"想清楚"这个环节。
在 v003 里我分享了六要素 prompt 框架，本质也是在做同一件事：把任务结构化，让 AI 接管执行，让开发者守住定义和决策。 无论是 /plan 还是六要素，方法论的内核是一致的。
五、用 CLAUDE.md 管理项目
最后一个想分享的实践，是关于项目文档的。
Claude Code 有一个内置命令 /init，会在项目根目录生成一个 CLAUDE.md 文件。这个文件是给 AI 看的项目说明书——包含项目概述、关键文件、架构说明、开发规范等。
当 AI Agent 进入一个新项目时，它首先会读取 CLAUDE.md，快速了解项目上下文，而不是从头开始扫描所有文件。这就好像你接手一个项目时，先看 README 而不是直接读源码——效率天差地别。
但 /init 还有一个隐藏用处：用于已有项目的维护。
举个例子，我最近在学 #JavaScript30 挑战，其中一个项目是鼓点模拟器——9 个按键对应 9 种鼓声，用原生 JS 实现。这是一个"别人写的项目"，我想让 AI 帮我理解和修改它。
我先在这个项目目录下运行了 claude，然后用 /init 让 AI 分析整个项目。AI 自动识别出了：
- 项目结构：index-FINISHED.html（完整版）、index-START.html（模板）、style.css、sounds/ 目录
- 架构模式：9 个
.keydiv 通过data-key与KeyboardEvent.keyCode关联，9 个隐藏的<audio>元素播放对应声音 - 关键机制：按键时添加
.playing类触发 CSS 动画，transitionend 事件移除动画类 - 完整的按键映射表（A-L 键分别对应 clap、hihat、kick……）
所有这些信息，都被写进了 CLAUDE.md。下次我打开这个项目时，AI 已经知道它的全部架构。我不需要再解释一遍。
这看起来是个小事情，但我认为意义不小——它解决了 AI 开发中的"上下文丢失"问题。
你和一个 AI 对话时，它可以记住整个会话的上下文。但下次你回来时，一切都 reset 了。CLAUDE.md 就像是项目的"长期记忆"——AI 离开后，它的理解被留在了文件里，下次进来可以直接读取。
对个人开发者来说，这意味着你的项目不再是"一次性的对话产物"，而是可以被 AI 持续维护、迭代的东西。
结语：工作流的持续进化
回顾这四篇文章，我发现自己走了一条很清晰的路径：
- v001，我在聊 OPC（一人公司）的概念框架——知道了 AI 可以做什么，一个人借助 AI 可以身兼七个角色。
- v002，我在聊 Prompt 设计和 LLM 原理——知道了怎么给 AI 写精确的指令，理解了 y = fθ(x) 的本质。
- v003，我在聊 AI Agent 的实战——知道了怎么用 Claude Code 做完整的项目，从 Prompt 到落地页一步到位。
- v004，也就是今天，我在聊工作流的进化——知道了怎么让 AI Agent 真正融入日常开发，从插件到 CLI，从直接执行到
/plan规划，从新建项目到用 CLAUDE.md 维护已有项目。
每一步，我的抽象层级都在提升，我和 AI 的协作方式都在进化。
有一种很强烈的感觉是：AI Native 不是一种状态，而是一个过程。 不是"用了 AI 工具"就完了，而是在每一次实践中不断优化你与 AI 协作的方式——发现新的模式、建立新的习惯、抛弃旧的流程。
Be AI Native，是一步步走出来的。
下篇见。
