"用 AI" 和 "被 AI 放大" 是两件事。前者是把 AI 当工具——按需调用,用完关掉。后者是把 AI 当结构——它不在工作流的某个步骤里,它就是工作流本身。这个区别不是程度,是种类。这篇文章讲清楚两件事:第一,这个区别在哪;第二,为什么穿越这道分界的入口,目前只有 Claude Code。

一、"用 AI" 不等于 "AI-Native"

大多数人对"用 AI 工作"的理解,是把 AI 当成一个外置器官:平时不长在身上,需要的时候插上去用一下。打开一个网页 tab,提一个问题,得到一个答案,关掉。下次再开。

这种模式有个隐藏的代价——所有沉淀都断在你脑子里。你和 AI 上一次对话里学到的东西,下一次必须靠你自己回忆并重新喂给它。你三个月前精心调出来的那个 prompt,现在已经找不到了。你解决过的同一类问题,要解决第四遍。

这不是"用得不够熟",这是模式的天花板。在这个模式下,AI 的能力是常数,你的工作每次都从零开始。你的速度上限被你"复述上下文的速度"卡住。

AI-Native 是另一回事。它的前提假设是:AI 不应该被你召唤,它应该一直在那里——在你打开终端的瞬间就已经知道你是谁、你在做什么、上次卡在哪里、这周固化了哪些新能力。你不再是"使用 AI",你是在一个由 AI 主导路由、由文件系统持有记忆、由 Skill 沉淀能力的环境里工作。

两者的差,不在响应快慢,在积累:

注意最后一行。它才是真正的分水岭。

AI-augmented 的生产力是线性的——你用得多一点,产出多一点,但增长率不变。AI-Native 的生产力是复利的——每完成一个任务,都可能留下一个 Skill、一条 Memory、一个 Hook,这些东西反过来让下一个任务更快。三个月后,两条曲线之间的差距,会大到不像同一个工具。

二、入口是什么:被低估的概念

人们谈工具,常常谈功能、谈速度、谈集成度。这些都对,但都不是最深的那一层。最深的那一层是:入口决定了你的注意力预算分配给谁,以及你的工作沉淀流向哪里。

你每天大概有两到三个"注意力主屏"——那些你打开就忘记关、所有任务都顺手在那里发起的地方。对程序员,通常是终端 + 编辑器 + 浏览器。对运营,可能是 Notion + Slack + 邮箱。这些主屏共同的特点是:它们捕获了你的 Intent。你想做什么事,第一反应是打开它们其中之一。

谁捕获了 Intent,谁就决定了这件事用什么方式被做。如果你的入口是浏览器搜索框,你的工作就是"可以被搜索的问题的合集"。如果你的入口是 Notion 页面,你的工作就是"可以被组织成文档的事的合集"。如果你的入口是 AI 对话框,你的工作就是"可以被自然语言表达的意图的合集"。

最后一种范围最大,因为自然语言几乎可以表达任何意图。所以入口是 AI 对话的人,在 Intent 表达上没有形状约束。这是 AI-Native 真正的杠杆——不是"AI 给你做了多少事",而是"你不再被工具的形状限制你能做什么事"。

但这件事有个前置条件:这个 AI 入口必须能持有记忆、能扩展能力、能编排长任务。否则它只是一个更聪明的搜索框,你的 Intent 进去了,但出来的东西无法积累。

候选入口里,只有一个同时满足这些条件:

Claude Code 不是"最好的 AI 工具",这种比较没意义。它是目前唯一同时具备四件事的入口:AI 主导的意图路由、文件系统级的持久记忆、可无限扩展的能力体系(Skill / Hook / MCP / Subagent)、可编排长任务的执行模型。其他工具各有强项,但缺任何一个,这条路就走不通。

三、为什么是 Claude Code:文本即基底

这一节是这篇文章里最重要的一节。

Claude Code 之所以能成为 AI-Native 的入口,不是因为它"功能多"。它的关键属性,藏在一个看起来平淡无奇的事实里:它把工作的每一个组成部分都还原成了文本文件。

• • 你的能力是文本——Skill 是 ~/.claude/skills/*/SKILL.md
• • 你的记忆是文本——MEMORY.md 是索引,memory/*.md 是条目
• • 你的项目知识是文本——CLAUDE.md 在仓库里
• • 你的自动化是文本——Hooks 是 settings.json 里的几行
• • 你的对话历史是文本——transcript 可以被另一个 subagent 读

文本是最古老、最 AI 友好、最人类友好的介质。当一切都是文本,就一切都可以被 diff、可以被 git、可以被分享、可以被 AI 读懂、可以被 AI 改写。

这件事的深意远超工程便利。它意味着:

你的工作系统本身,是另一个 AI 可以理解和修改的对象。 你可以让 Claude 帮你写 Skill,让 Claude 评审你的 Memory,让 Claude 整理你的 CLAUDE.md。这是一种自指的能力——AI 不只是用你的工作,AI 还在帮你建造用 AI 工作的方式本身。这件事在网页 chatbot 里做不到,在 IDE 插件里做不到,只有当一切都是文本、都在文件系统里、都可以被 AI 读写,这件事才成立。

这就是为什么 Cursor 很强但不够——它的 AI 主要面向代码,不面向你的整套工作系统。这就是为什么网页 chatbot 不够——它的"记忆"是黑盒,你看不到、改不了、版本控制不了。只有当所有的层都暴露成普通文件,这个系统才真正属于你。

代价是:你必须接受"终端 + 文本文件"作为工作主屏。这对开发者门槛低(本来就在这),对非开发者门槛高,但门槛之后的世界,完全是另一种。

四、AI-Native 的五层结构

┌─────────────────────────────────────────────────┐│  L5 进化层   /review-skills, /loop, 周度评审       │   ← 体系自己迭代├─────────────────────────────────────────────────┤│  L4 记忆层   MEMORY.md + memory/*.md + CLAUDE.md  │   ← 跨会话的"我是谁"├─────────────────────────────────────────────────┤│  L3 执行层   Skills / Hooks / Subagents / MCP     │   ← 确定性的能力├─────────────────────────────────────────────────┤│  L2 意图层   自然语言 → Skill 命中 / Plan 启动     │   ← 路由├─────────────────────────────────────────────────┤│  L1 入口层   Claude Code(CLI/Desktop/Web/IDE)    │   ← 单一入口└─────────────────────────────────────────────────┘

这张图看起来像架构图,实际是一组断言:

• • 每一层都必须显式存在。隐式的层等于不存在——你以为你有 Memory,其实只在脑子里;你以为你有进化机制,其实从没复盘过。隐式即不存在,这是这个体系的零号公理。
• • 下三层是确定性的,上两层和 LLM 有关。Skill / Hook / Memory / 文件结构都是确定性的——同一个输入永远给同一个输出。LLM 只出现在 L2 的路由判断(选哪条 Skill)、L5 的评审建议(哪些该晋升)、以及任何 Skill 都没命中时的兜底 Planning。这个分层是有意为之:用确定性的壳包裹不确定性的核。
• • 构建顺序从下到上,请求顺序从上到下。先有入口,才能谈意图;先有意图,才能命中能力;能力的执行改写记忆;记忆的积累触发进化。任何一层缺失,上面的层都建不起来。很多人卡在 L4——以为装好 Claude Code 就是 AI-Native,但从来没建过 Memory 体系,于是永远停在第一天的状态。
• • 进化层是体系活下去的引擎,不是锦上添花。这一点单独讲。

五、工作模式:AI-Native 里一天是什么样的

理论讲完了,但真正影响生活的是日常。AI-Native 不是一组配置,是一组工作习惯——你说话的方式、分配注意力的方式、决定什么时候自己做、什么时候让 AI 做的方式,全部都和旧模式不一样。这一节把这些习惯一个一个说清楚。

5.1 意图表达:从"操作工具"到"声明目标"

旧模式下,你和工具交互的方式是指令式——打开这个、点这个、改这个、运行这个。你必须先把"想做什么"翻译成"工具能听懂的具体步骤",然后一步一步执行。

AI-Native 下,你的交互方式是声明式——你只表达目标和约束,让 AI 去拆步骤。

具体差别:

注意中间地带——既给意图也给约束:

"重构这个文件让它更好读。不要引入新依赖,不要改公开 API,保持现有命名风格。"

这种"目标 + 软约束"的表达,是 AI-Native 最重要的口语。学不会它的人,会一直把 Claude Code 当成一个昂贵的 grep。

声明式还有个更深的好处:它强迫你想清楚"自己到底想要什么"。指令式可以糊里糊涂地一步步试,声明式必须先清晰地表述目标。这一点对工作质量本身有提升——很多任务做得糟,是因为做的时候没想清楚要什么。

5.2 任务分流:四种路径,选对一种

不是所有任务都走 Plan,也不是所有任务都走自然语言。健康的体系里,任务按"已知度"和"时长"分四象限,每种走不同路径:

新手最常犯的错是把所有任务都走自然语言对话——简单的不写 Skill(每次重打 prompt),复杂的不进 Plan(直接让 AI 边想边做,失控)。这两种错误的代价都很大:前者把复利变线性,后者把成功率变赌博。

经验法则:手指开始打 prompt 前,先 0.5 秒判断"这是几号象限的任务"。这半秒的预判,省掉后面几分钟的弯路。

5.3 日内三段式

健康的 AI-Native 一天,大致这个节奏:

晨(3-5 分钟)·"被推到面前"

终端打开的瞬间,SessionStart hook 已经把以下东西摆好:

• • 昨天 background task 跑出的结果
• • cron 定时任务的产出(每日摘要、监控简报)
• • 待你审阅的 PR / Memory 草稿 / Skill 建议
• • 体系自检(有没有失败的 hook、有没有冲突的 Skill)

你不主动找信息,信息主动找你。省下来的"决定今天先做什么"的认知开销,比想象中大。这一段的设计原则是:让早晨的决策成本接近零。

午(主战场)·"流水线"

工作的核心时段。注意力分配大致是这样:

"审阅"占比最大——这是 AI-Native 和旧模式最大的体感差别。旧模式你 60% 时间在敲键盘,新模式你 60% 时间在点头或摇头。判断力从执行的间隙里被解放出来,直接成为主要动作。

晚(2-3 分钟)·"收口"

不让今天学到的东西流失。两件事:

1. 1. 一句话告诉 Claude 今天值得记的:记一下,飞书 MCP 在 attachment > 50MB 会静默截断
2. 2. 看一眼今天有没有该晋升为 Skill 的对话(周末跑一次完整 /review-skills)

加起来不超过 3 分钟。但没有这两步,前面 8 小时学到的东西大部分会蒸发。每天蒸发一点,一个月后你回到原点——还是那个 AI-augmented 用户,只是工具换了 logo。

5.4 并行的姿态:让 AI 异步陪你工作

旧模式下,你和 AI 是严格顺序的:你问 → 它答 → 你处理 → 你再问。一次只能做一件事,而且 AI 在你思考的时候是闲着的,你在 AI 跑的时候也是等着的。

AI-Native 提供三种并行原语,把 AI 变成一组异步工人:

• • Subagent:同一对话里同时派几个 subagent 做独立工作——一个 Explore 模块 A,一个 Explore 模块 B,一个查文档。十几秒后所有结果回到主对话,你做综合判断。
• • Background task:长任务直接丢到 background,你继续干别的。完成时系统通知。不需要 sleep,不需要轮询。
• • Worktree:多个分支同时推进且互相隔离。一个 worktree 在重构 A,另一个在加 B 功能,主对话在做 code review。三个上下文不污染对方。

掌握这三种原语之后,你不再是和 AI 一对一对话,你是在调度一支异步工人队伍。这是 AI-Native 真正"5 倍"的来源——不是 AI 比你快 5 倍,而是你同时让几个 AI 干活,且每一份都被你审阅过。

一个直观的画面:你在主对话里讨论方向,左边 worktree 里 background subagent 在跑测试,右边 worktree 在做无关的另一个功能。三件事并行推进。你的瓶颈不再是手速,是判断速度和审阅速度。

5.5 审阅:你的核心动作变了

承接上一节。在 AI-Native 里,你的核心身份从执行者变成审稿人。

旧模式:60% 时间敲键盘,30% 时间思考,10% 时间审阅。新模式:60% 时间审阅,30% 时间思考,10% 时间直接编辑。

你需要审的东西包括:

• • Plan(在 ExitPlanMode 之前)
• • diff(在 accept 之前)
• • Memory 草稿(在写进 memory/ 之前)
• • Skill 提议(/review-skills 报告里)
• • Subagent 的结果汇总

审阅是不可外包的部分——AI 可以执行、可以提议,但不能替你判断"这个方向对不对"。一旦你跳过审阅,失控只是时间问题。

学会审阅的关键,是快而不草。一个 plan 平均 1-2 分钟看完,一个 diff 30 秒到 2 分钟。比这快,你成了橡皮图章——审阅形同虚设,失控的风险照样存在。比这慢,你的吞吐量被自己拖垮——AI 再快也没用,瓶颈在你这里。

练这个能力,需要你刻意培养"在 1 分钟内识别 plan 风险点"的眼力。开始时一定会慢,会漏。这是 AI-Native 真正的学习曲线——不是学工具,是学怎么做审稿人。

5.6 从对话到资产:沉淀的暗流

每次自然语言对话,都是潜在的资产生产事件。健康的体系里,有几个触发词会让你立刻进入沉淀模式:

三次法则是这个暗流的节拍器:同一类任务做了三次还没 Skill,强制晋升。无论它看起来多简单。简单 Skill 写起来不浪费什么,但不写 Skill 的简单任务每次都浪费 30 秒重打 prompt——这种浪费在一个月里累加,就是几个小时的复利损失。

注意:成功的判断也要沉淀,不只是失败。如果你做了一个不寻常的决定而事后证明对了,这条经验和"避免失败"同等重要。Feedback memory 不是只记"踩过的坑",是记所有被验证过的判断——包括反直觉但正确的那些。

5.7 多入口的一致性

Claude Code 不只是 CLI——还有 Desktop app(Mac/Windows)、Web 客户端、IDE 扩展(VS Code / JetBrains)。这些客户端读同一份配置:

• • 你的 ~/.claude/skills/ 在哪都能命中
• • 你的 MEMORY.md 在哪都被加载
• • 你的 hooks 在哪都触发
• • 你在桌面端起的任务,在 CLI 能看进度

所以严格说,AI-Native 不要求你"只用终端"——它要求你只用一套 Claude Code 生态。你可以在桌面端审阅 PR、在 CLI 跑重构、在通勤路上用 web 客户端给 background task 发追问,这都是同一个体系在不同设备上的延伸。

"切换入口"这个动作不应该存在,存在的只有"切换设备"。前者意味着体系分裂成多个工具,后者只是一个体系在多个屏幕上的呈现。这两件事在体验上看着像,但在体系健康度上是地狱差距。

5.8 团队层面:从个人体系到团队体系

前面讲的都是个人 AI-Native。团队层面,有一组明确的分层约定:

项目级共享(进 git,所有协作者继承):

• • .claude/skills/ —— 团队公用 Skill(发版、code review、特定流程)
• • .claude/hooks/ —— 团队公用 Hook(commit 前检查、PR 模板)
• • CLAUDE.md —— 项目背景、术语、关注点

个人级保留(不进 git):

• • ~/.claude/skills/ —— 个人 Skill(/morning、/prep-1v1)
• • ~/.claude/memory/ —— 个人 Memory(偏好、私人踩坑)
• • ~/.claude/CLAUDE.md —— 全局个人偏好

这种分层带来一个新现象:Code review 不再只 review 代码,也 review Skills、Hooks、CLAUDE.md。新人入职第一天 git clone 之后,他不只继承代码——还继承团队过去半年沉淀的AI 工作方式。这是 AI-Native 在协作层面最强的复利,也是它和单兵作战工具的本质差别。

一条红线:不要把个人偏好强推到团队层。"我喜欢 vim 风格快捷键"是个人偏好,不是团队规范。混淆这两个层,团队规范会变成强加的个人风格,引发摩擦,最终团队 .claude/ 被人怨弃。

5.9 一个完整的工作片段示例

把上面所有东西串成一个 30 分钟的真实片段,大概是这样:

注意这 30 分钟里发生的事:

• • 2 次 Skill 命中(/triage-test-failures、/commit)
• • 1 次自然语言对话(自由问答)
• • 1 次 Plan(新问题,需要判断)
• • 2 个并行 subagent(独立子任务)
• • 多次审阅(报告、diff、memory 草稿)
• • 1 次沉淀(feedback memory)

旧模式做同一组事,大概要 60-90 分钟,而且学到的东西不会被结构化保留——下次遇到同类 cache bug,你还是从零调试。

六、AI 应该出现在哪里:三个,且只有三个

LLM 调用慢、贵、不确定。一个健康的体系不应该"无处不在地调 LLM",而应该精确知道在哪三个点上让 AI 介入,其他地方都不。

这三个点对应三种不可压缩的认知动作——这是这个三分法不是工程取舍,而是认知必然的原因:

1. 首次 Planning ←→ 决定方向

Intent 是新的,没有任何 Skill 能命中,没有 Memory 模板可以重放。这时候需要的不是执行,是判断:这件事到底应该怎么拆。这种判断必须基于对当前上下文的真实理解,不能靠模板。所以这里需要 LLM,而且必须留出审阅环节——AskUserQuestion 卡在分叉点,ExitPlanMode 前用户必须看过。Plan 不能静默执行,因为判断的所有权在你这里。

2. Self-healing ←→ 从失败中学习

任务失败、卡住、产出明显不对。Stop hook 检测到失败信号,提示是否沉淀一条 feedback memory。这里需要 LLM,因为分析"为什么失败"是个归纳动作——从这一次的具体情况,抽出可被未来引用的规律。规律必须带 Why——"飞书附件 >50MB 会超时"是事实,"因为 MCP 的 buffer 设了 50MB 上限"是 Why。没有 Why 的 feedback 在边界情况下会被错误应用,反而比没有更糟。

3. Template 评审 ←→ 修剪与策展

周度或月度触发。AI 扫描所有 Skill 的调用次数、Memory 的引用频率、transcript 里的重复模式,起草一份评审报告:哪些重复对话该晋升成 Skill、哪些 30 天 0 调用的 Skill 该淘汰、哪些 memory 在讲同一件事该归并。这里需要 LLM,因为它是个策展动作——从大量数据里识别"哪些值得保留"。但评审建议必须由人逐项确认,AI 可以提议,不能擅自动手。

这三个动作有一个共同点:它们都是认知的"边缘",不是认知的"内核"。内核——执行已知方案、查询已知信息、调用已知工具——必须是确定性的(用 Skill / Hook / 直接命令)。只有边缘——发现新方向、处理新失败、整理旧资产——才让 LLM 介入。

把这件事说反了的体系会怎样?会出现两种典型病态:

• • 过度 AI 化:每次读文件都让 AI 概括,每个简单命令都先问 AI 推荐用法,SessionStart hook 里就调 LLM。结果是钱、时间、不确定性三重浪费,而且热路径变慢,人会自然回到旧工具。
• • 不足 AI 化:遇到失败只是"小心一点",从来不沉淀;周度评审跳过;Skill 永远不写。结果是用了 AI 但没积累,六个月后还是 AI-augmented 模式。

健康的体系,LLM 调用频率应该是这样:

如果"首次 Planning"占了 80%,意味着 Skill 没沉淀。如果"Self-healing"几乎为零,意味着失败没被记录。

七、可靠性悖论:用确定性包裹不确定性

AI 是非确定性的——同一个 prompt 可能产生不同输出。工作要求可靠性——同一个任务必须有可预期的结果。这是个根本矛盾。

主流解决方案是"让 AI 更可靠"——更大的模型、更精的 prompt、更高的 temperature 控制。这条路有上限,而且本质上是和 AI 的概率本性对抗。

AI-Native 的解决方案不一样:不让 AI 更可靠,而是只让 AI 出现在"非确定性是优点的位置"。

判断方向应该是上下文相关的(不同任务该不同拆法),所以 Planning 适合 AI。归纳失败应该是情境敏感的(同样的报错在不同场景含义不同),所以 Self-healing 适合 AI。策展评审应该是有品味的(没有放之四海皆准的规则),所以评审适合 AI。

其他位置——查文件、跑测试、执行已知步骤——非确定性不是优点而是缺陷,所以让确定性工具做(Skill 里的 shell、直接的 grep、Hook 触发的脚本)。

这种分工不是为了优化成本(虽然顺带做到了),它是承认了一件事:可靠性不来自于消除不确定性,而来自于把不确定性关在该关的位置。

八、熵与评审:体系活下去的唯一办法

每个工作系统都在累积熵。新 Skill 会写,但旧 Skill 不会自己删。新 Memory 会加,但过时 Memory 不会自己淘汰。一年后,你的 ~/.claude/skills/ 里会有 50 个 Skill,其中 30 个你已经不用了,5 个甚至连功能都和现在的工作流冲突。

这种累积最终会反噬体系。Skill 太多,LLM 在 L2 路由层选错的概率上升。Memory 太多,索引膨胀,每次启动都要拉很多无关上下文。CLAUDE.md 里写满了三个项目前的注意事项,现在反而误导决策。

熵增是单向的,除非有反向机制。评审就是那个反向机制。它不是"锦上添花",它是热力学意义上的必须——没有它,系统必然衰减。

这就是为什么 /loop 7d /review-skills 不能跳过。这就是为什么"那些 30 天没调用的 Skill 该不该删"是必须每周问一次的问题。这就是为什么周度评审是三个介入点里频次最低、却是唯一一个跳过会致命的那个——Planning 失误,影响一次任务;Self-healing 失误,影响一类任务;评审失误,影响整个体系的健康度。

很多人在用 Claude Code 三个月后会感觉"它越来越笨"。这通常不是 Claude 的问题,是他们的体系开始被自己的旧资产压垮。

九、AI-Native 的真实代价

老实说,这条路有代价。

结构化的代价。AI-augmented 模式下,你想到什么就问什么,不需要规划。AI-Native 模式要求你接受"任务有路径、能力要沉淀、失败要复盘、资产要评审"。这种结构是力量的来源,但也是自由度的削减。如果你享受的是漫无目的探索的乐趣,这条路会让你别扭。

前期投入的代价。第一周写 CLAUDE.md,第二周写 Skill,第三周搭 Memory,第四周配评审。前四周你的产出未必比 AI-augmented 高——你大部分时间在搭基础设施。复利只在第二个月之后才开始显现。

工具单点的代价。把所有鸡蛋放在 Claude Code 一个篮子里,它崩了你就停摆,它涨价你就被动。这是真实风险。但反过来——多入口的代价是体系分裂,而体系分裂是没有上限的损失。两害相权,接受单点。

心智迁移的代价。你必须从"我有个问题要问 AI"切换到"我和我的体系一起工作"。前者是甲方思维,后者是合伙人思维。后者更累,但只有后者能走到 5 倍。

这些代价值得被诚实地说出来。任何不提代价的方法论都是营销,不是工程。

十、从零到 AI-Native 的 30 天

不要试图一步到位。

第 1 周 · 切入口

• • 装 Claude Code,所有任务尝试从这里发起
• • 不写任何 Skill,先用自然语言
• • 目标:习惯打开终端就是开始工作

第 2 周 · 第一批 Skill

• • 复盘第 1 周,挑 3 个你重复做了 ≥ 3 次的任务
• • 把它们写成 Skill(~/.claude/skills/)
• • 写一个项目级 CLAUDE.md
• • 目标:看到 Replay 的甜头

第 3 周 · Memory + Hook

• • 开始用 memory(feedback/project/reference 三类)
• • 装 1-2 个 hook(Stop hook 做 self-healing 提醒最有价值)
• • 目标:第一次感受到"它记得我"

第 4 周 · 评审循环

• • 设 /loop 7d /review-skills,或手动周末跑一次
• • 完整跑一次评审循环,晋升 / 淘汰 / 归并
• • 目标:体系开始自己迭代

到第 30 天,五层都立起来了。从这一刻开始,你的生产力曲线从线性进入复利。

十一、一句话

AI-Native 不是"用更多 AI",是把 AI 放在工作的入口、记忆的中枢、能力的内核、进化的引擎四个位置上。其他位置一个不多。

Claude Code 是目前唯一同时支撑这四件事的入口——不是因为它"功能最强",而是因为它把工作的每一层都还原成了文本,使得整套体系既属于你,又能被 AI 读懂和帮你迭代。

这条路有代价,有门槛,有几周的爬坡。但穿过去之后,你不再是"用 AI 的人",你是被 AI 持续放大的人。这两者中间隔着的,不是熟练度,是结构。