AI真正的进化不是帮你写代码更快，而是能把你积累的整套工作方法完整迁移给另一个人。
前几天发生了一件事，让我重新理解了AI写代码这件事的边界在哪里。
一个朋友要启动一个新项目，领域跟我完全不同。她问我能不能帮她搭一套项目工作流，从质量评估、信息搜索策略、到输出模板、数据追踪，整个闭环。
我花了大概三个月，在自己的项目里一点点打磨出了这样一套体系。二十多个文件，涵盖质量评分算法、搜索框架、角色定义、输出模板、记忆系统、反馈循环。每个文件都是在实际使用中反复迭代出来的。踩过坑才知道哪个阈值该调，试过错才知道哪些来源可信。
我当时的第一反应是，这东西没法直接给她。领域不一样，角色不一样，评判标准不一样。得从头搭。
这其实是一个被低估的老问题。
每个人在工作中都会形成自己的方法论，什么该检查、什么标准算合格、遇到问题先查哪里、哪些来源可信、哪些坑绝对不能踩。这些东西大部分不在任何文档里，它在你的习惯里，在你的判断里，在你试错的经验里。
你想把这些传给另一个人，传统做法是什么？手把手带，花几周甚至几个月。或者写一份长长的SOP，但对方拿到手还是得从头消化，遇到新情况照样抓瞎。而且一旦换了领域，SOP里大半内容不适用，又得重新写。
这就是为什么公司花大量预算做培训和交接，因为一个人积累的工作方法，想完整地搬给另一个人，一直是一件极其费力的事。不是因为方法不好，而是因为方法和具体领域绑得太死，没法抽象出来复用。
然后我换了个思路。我问 Claude Code 能不能分析一下我这套体系，哪些是通用的框架，哪些是跟我的领域绑定的？通用的搬过去，领域特定的替换成她的信息。
它真的做到了。
大多数人理解的"AI写代码"
先说说大多数人在用的AI编程工具是什么样的。
打开VS Code，装一个AI插件，Copilot也好，Cline也好，它做的事情本质上是你写代码，它帮你补全；你选中一段代码，它帮你优化；你问它一个问题，它在聊天框里回答你。
这已经很好用了。补全准确率越来越高，能读懂上下文，能理解你的意图。对于日常编程，效率提升是实实在在的。
但它的工作范围始终是：你打开的那个文件，或者你打开的那个项目文件夹。
它帮你写好一个函数，帮你修好一个bug，帮你重构一段代码。一次一个任务，一次一个文件。你是主导者，它是助手。
这就是大多数人对AI写代码的全部想象。
那天真正发生了什么
回到我朋友那件事。
我在 Claude Code 的终端里，给了它两个路径，我的项目和她的项目。然后让它分析我这套工作流的结构，分出通用框架和领域特定内容，把通用的迁移过去，领域特定的用她的信息替换。
接下来发生的事情让我意识到，这不是写代码能描述的。
它先派出一个分析 agent，花了几分钟把我项目里的二十多个文件全部读完。然后给出了一份清单，哪些文件是100%通用的可以直接搬（质量评估框架、反馈循环机制、去重逻辑、日志记录系统），哪些需要保留框架但替换内容（角色定义、评分字典、搜索模板、来源数据库），哪些是领域专属需要从头写的（示例文件、记忆档案）。
然后它同时启动了四个并行 agent，分头创建不同批次的文件。每个 agent 独立工作，一个写项目说明和记忆系统，一个写角色定义和质量标准，一个写搜索和来源体系，一个写Python评分脚本和示例。
几分钟后，二十多个文件全部就位。目录结构完整，每个文件的内容都已经根据她的领域、身份、风格做了定制化替换。评分算法里的关键词字典、搜索策略里的权威来源、角色定义里的正面词和禁忌词，全部换成了她的领域的内容。
CLI版能做什么不一样的事
这件事之后，我仔细想了想，CLI版的 Claude Code 到底跟 VS Code 里的AI插件有什么本质区别。不是功能多少的问题，是工作方式根本不同。
第一，它在文件系统层面工作，不是在编辑器层面。
VS Code 插件的工作单位是你当前打开的文件。CLI 的工作单位是你整台电脑上的任何目录，它可以同时读一个项目的文件，在另一个项目里创建新文件，这意味着它可以做跨项目的操作，而插件做不到。
第二，它有 Skill 架构，技能是可以积累和迁移的。
在我的项目里，工作流程、质量标准、评分算法这些东西不是散落在代码里的零碎逻辑，而是一个结构化的 Skill 目录。有入口文件定义操作模式，有参考文档定义具体规范，有脚本实现算法逻辑。这个结构本身就是为迁移设计的，换一套参考文档和字典，同一个框架就能服务完全不同的领域。
第三，它有持久记忆，跨会话保留。
每次任务完成后，系统会自动把这次的主题、输出、质量评分、使用的来源记录到日志里。下一次启动时，它会检查是不是做过类似的任务，会参考之前哪些方案效果好。这不是聊天记录，是结构化的记忆数据。插件关掉窗口，一切归零。CLI 的记忆写在文件系统里，永远在那。
第四，它可以编排多个 agent 并行工作。
那天迁移的时候，四个 agent 同时工作，各管各的文件。当任务可以拆分成独立子任务时，并行执行的效率是线性执行的好几倍。VS Code 插件没有这个能力，它一次只能处理一个对话。
第五，它有 Hooks 机制，自动化的质量把关。
我的项目里配置了 hook，每次我输入一段话，它会自动优化成结构化的提示词；每次编辑文件，它会自动运行格式检查。这些自动化流程是在后台静默运行的，不需要我记住要做什么。插件没有这个层面的自动化能力。
这件事让我想到什么
说到底，VS Code 里的AI插件和 Claude Code CLI 的区别，不是哪个更聪明的问题。用的可能是同一个模型，同样的推理能力。
区别在于它能调度的资源不同。
插件能调度的资源是当前编辑器里的文件内容 + 一个对话框。CLI 能调度的资源是整个文件系统 + 多个并行 agent + 持久记忆 + 自动化 hook + 结构化技能体系。
AI 能把你积累的整套工作方法完整迁移给另一个人。这件事只有当 AI 拥有文件系统级的操控能力、可迁移的技能架构和持久记忆时，才能真正做到。
而这些，目前只有 CLI 版的 Claude Code 能给你。