你的 Claude Code 配好了 CLAUDE.md装了几个 skill干活挺顺。然后你遇到了这些情况你换了个项目目录AI 忘了你所有的偏好又开始用你纠正过八百次的风格跟你说话。你上周和 AI 聊了一个方案讨论了三轮做了一半。今天开了个新 session它一脸茫然——”请问您想做什么”你在 CLAUDE.md 里明确写了”所有数据必须通过统一接口获取”。但你一转头AI 又import requests直接手写 URL 了。你开始怀疑是不是 CLAUDE.md 写得不够好是不是 skill 不够详细不是。“能用”和”高效”之间的差距不在于你教了 AI 多少规则而在于这些规则是靠”说”还是靠”执行”。一、四个阶段你在哪一个先用一张表定位自己阶段名称特征你在这里如果…1纯聊天直接对话每次重头开始没有 CLAUDE.md每次都要重新解释需求2文件化CLAUDE.md skillsAI 有了”说明书”配好了基础环境但总感觉”不够顺”3自动化hooks linter guards规则机械执行AI 偶尔还要手动纠正session 之间缺乏连续性4生态化memory plan dev-log manifest跨 session 连贯多项目同时推进长周期任务不再断片大多数教程——包括很多写得很好的入门文章——停在阶段 2。这篇文章讲阶段 3 和 4。二、阶段 1 和 2不展开阶段 1 是纯聊天和 ChatGPT 网页版没本质区别每次从零开始AI 不知道你是谁、项目是什么、你有什么偏好。阶段 2 是文件化CLAUDE.md 定义角色和规则skills 文件夹拆分专家能力用文档串联不同角色之间的工作流。这一步已经有很多优秀的教程了不展开。关键是——大多数人卡在阶段 2 的天花板上。CLAUDE.md 写得再详细skill 拆得再精细你依然会遇到开头说的那三个问题。因为问题的根源不在配置的”好不好”而在规则的”执行方式”。三、先说结果在讲方法之前先说结果你来判断值不值得继续读。我是产品经理不是程序员。几个月前开始用 Claude Code 做自己的项目。现在的状态一个人维护6 个应用项目 4 个基础库累计2000 自动化测试每天自动生成三个市场的数据分析日报从数据采集到报告产出全链路跑通任何一个项目开个新 session 就能直接继续上次的工作——不用花 10 分钟”回忆上次做到哪了”新增一个数据源或分析维度从需求到上线通常一个 session 内完成这不是因为我写代码厉害——我不会写代码。这是因为系统替我记住了该记的、执行了该执行的、拦住了该拦的。下面讲的就是这套系统的核心思路。四、核心洞察约束 文档 对话这是贯穿阶段 3 和阶段 4 的一条核心原则。我把它叫做”三层模型”约束层Constraints ← 机器执行不依赖 AI 理解 hooks / linter / preflight / guards 文档层Documents ← 文件系统持久化不依赖对话上下文 plan / spec / manifest / dev-log / memory 对话层Conversation ← AI 实时理解最灵活但最脆弱 CLAUDE.md / skills / 口头指令大多数人花大量精力在对话层——写更好的 CLAUDE.md写更详细的 skill 描述用更精确的措辞跟 AI 下指令。但对话层天然是最不可靠的一层。原因有三个第一上下文有限。Claude 的上下文窗口再大也有边界。聊到后面前面的指令可能已经被压缩了。你在 session 开头说的”记住用 TypeScript”到第 50 轮对话时它可能真的忘了。第二session 会断。你关掉终端明天重新开对话层的一切都消失了。CLAUDE.md 还在但你们之间关于”上次做到哪了”“选了哪个方案”“为什么放弃了方案 B”的所有讨论都没了。第三AI 会”选择性遗忘”。即使规则就在 CLAUDE.md 里AI 在复杂任务中也可能忽略它。不是它不听话是它的注意力在处理你的业务逻辑时确实可能没顾上那条规则。进阶的本质是把规则从对话层往上推。能写成文件的不靠说。能机械执行的不靠文件。打个比方对话层像口头约定文档层像书面合同约束层像自动执行的智能合约。你更信哪个如果你最近关注过 Harness Engineering 这个热词会发现这三层模型和它的核心框架高度吻合——Harness 里的 Guides前馈控制和 Sensors反馈控制对应的就是约束层的 hooks 和 linter而 Context Engineering 强调的”给 AI 正确的上下文”对应的就是文档层的 plan、manifest、memory。只不过 Harness Engineering 更多是在讲团队级的 Agent 治理而这篇文章讲的是一个人怎么用同样的思路把自己的 Claude Code 工作流从”能用”推到”高效”。五、阶段 3自动化——让规则自己执行这个阶段的核心手段是hooks。Claude Code 支持在特定事件比如 session 开始、session 结束时自动执行 shell 命令。这些命令是 harnessClaude Code 本身执行的不是 AI 执行的——它们不消耗 context不依赖 AI 的”理解”每次都会跑。SessionStart Hook环境体检 架构守卫我在.claude/settings.json里配了两个 SessionStart hook{ hooks: { SessionStart: [ { command: python3 scripts/preflight.py, timeout: 10 }, { command: python3 scripts/arch_lint.py, timeout: 10 } ] } }preflight.py检查三件事环境变量是否齐全、外部 API 是否可达、本地数据是否过期。任何一项有问题session 一开始就能看到告警不用等干了半天才发现。arch_lint.py扫描代码中的架构违规。比如我规定”所有 HTTP 请求必须通过统一的 API Client”如果 AI 在上一个 session 里直接import requests手写了 URL这个 session 开始时 linter 就会抓到。这两个脚本的具体实现我在系列的另一篇文章《别学歪了Harness 不是新概念》里有详细展开这里不重复。核心观点一句话写在 CLAUDE.md 里的规则是建议跑在 hook 里的 linter 是法律。Stop Hook下班自动存档这个更关键SessionStart 解决的是”开工时环境对不对”但还有一个同样重要的问题收工时状态怎么保存。痛点干了一天关掉终端明天开 session 什么都不记得了。得花 10 分钟跟 AI 解释”我们昨天做到哪了”。方案Stop hook 触发日志脚本自动记录 session 摘要。{ hooks: { Stop: [{ command: bash scripts/session-log.sh, timeout: 5 }] } }session-log.sh自动收集 git 信息生成结构化日志## 2026-04-15 Session #2 - **项目**: my-project - **时间**: 14:00 - 17:30 - **文件变更**: 8 files changed, 240/-60 lines - **Commits**: 3 (feat: user auth, fix: validation, refactor: middleware) - **Plan 进度**: Phase 1: 2/4 → 4/4 (已完成) - **明日继续**: Phase 2 权限管理模块明天开 session 时AI 可以直接读这个日志文件知道昨天做了什么、做到哪了、今天该从哪继续。关键点session 状态从”在脑子里”变成”在文件里”。不依赖你的记忆也不依赖 AI 的记忆。小结对话层 vs 约束层场景对话层做法约束层做法环境检查CLAUDE.md 写”请先确认环境变量”SessionStart hook 自动跑 preflight架构规则CLAUDE.md 写”请通过统一接口获取数据”Linter 自动扫描告警Session 状态“你还记得昨天做到哪了吗”Stop hook 自动存档下次直接读左边是建议右边是执行。你用久了就会发现但凡需要你提醒 AI 的事情最终都应该变成不需要提醒的事情。六、阶段 4生态化——让系统有记忆、有连续性阶段 3 解决的是”单个 session 内”的效率问题。阶段 4 解决的是”跨 session、跨项目”的连续性问题。6.1 Memory 分层——不是所有记忆都平等Memory 的完整框架我在《建立个人 AI 工作框架》里讲过了。这里只强调一个在实践中最容易被忽略的点memory 需要淘汰机制。我把记忆分成三层稳定层MEMORY.md月级 review、项目层memory/*.md周级带时间戳、流水层dev-log/日级只写不改。很多人只关注”怎么让 AI 记住更多”但真正用起来你会发现不删的 memory 是负债不是资产。三个月前记的”接口用 v2”现在已经升到 v3 了AI 还在用旧信息干活——这比什么都不记更危险。关键操作每月花 10 分钟 review 稳定层删掉过时的项目层超过两周未更新的自动标记为”可能过期”流水层只供查阅不供 AI 主动回忆。6.2 Plan 持久化——跨 session 的状态追踪痛点一个大任务分三天做。每天开 session你都要花好几分钟跟 AI 解释”我做到哪了、之前选了什么方案、为什么那样选”。有时候你自己也记不清了。方案把 plan 写成 markdown 文件用 checkbox 追踪状态用内嵌注释记录关键决策。# 用户认证模块开发计划 ## Phase 1: 基础架构 - [x] 创建数据模型 - [x] 实现注册接口 - [ ] 实现登录接口 **Decision:** 选了 JWT 而非 Session因为后续要支持移动端 - [ ] 密码加密与存储 ## Phase 2: 权限管理 - [ ] 角色与权限定义 - [ ] 鉴权中间件实现两个关键做法第一完成一步立刻打勾。- [ ]变成- [x]这个状态就持久化到文件里了。下个 session 的 AI 读文件就知道做到哪了不需要任何解释。第二非显而易见的决策立刻记录。为什么选了 JWT 而不是 Session当时讨论了什么这些对话会随着 session 结束而消失但 **Decision:**注释会留在文件里。三天后的你或者三天后的 AI看到这行注释就知道不用重新讨论这个问题了。可以再配一个简单脚本查进度$ python scripts/plan_status.py plans/auth-module.md Phase 1: 2/4 (50%) | Phase 2: 0/2 (0%) Decisions: 1 recorded关键点文件是跨 session 的唯一可靠载体。plan 不在对话里不在 memory 里在文件系统里。它不会因为上下文压缩而消失不会因为 session 切换而丢失。6.3 Manifest 依赖管理——多项目不翻车痛点当你的项目超过一两个开始有共享的基础库时问题就来了。你让 AI 改了基础库里某个函数的接口签名结果下游三个项目全炸了。AI 不知道有谁在用这个函数——这个信息不在任何一个 CLAUDE.md 里。方案每个项目/模块写一个manifest.yaml声明它提供什么接口、依赖谁、被谁消费。# shared-utils/manifest.yaml name: shared-utils version: 1.2.0 type: library interfaces: - name: format_date - name: parse_config - name: send_notification consumers: - web-app - api-server - background-worker有了这个声明变更流程就变成了想删send_notification先查 manifest ——background-worker在用不能直接删想改parse_config的参数先更新两边的 manifest确认兼容再改代码核心是双向声明A 的 manifest 说”我依赖 B”B 的 manifest 说”A 是我的消费者”。这样无论从哪边查都能看到完整的依赖关系。AI 可以在执行变更前自动检查 manifest判断影响范围。而不是凭上下文中的”记忆”来猜”这个函数好像没人用了”。6.4 Dev-log 指标——用数据驱动反思痛点每天都在忙但说不清产出了什么。感觉效率高但没有证据感觉哪里不对但说不出来。方案通过 hook 自动记录每个 session 的关键指标。| 指标 | 值 | |---|---| | Session 数 | 3 | | 文件变更 | 12 files, 380/-90 lines | | Commits | 5 | | Plan 完成率 | Phase 1: 75% → 100% | | Token 消耗 | ~120K |这些数字单独看意义不大但积累一两周之后你会开始发现模式哪类任务效率高有些任务用很少的 token 就能产出大量代码变更——说明需求明确、方案清晰哪类任务 token 烧得猛token 消耗大但产出少通常意味着需求不清AI 在反复试错Scope creep 什么时候发生plan 完成率连续几天不涨说明不断有新任务插入原计划被挤占指标不是用来”考核”的是用来发现问题的。当你能用数据回答”今天到底做了什么”的时候你对自己工作流的掌控力会上一个台阶。七、五条原则从几个月的实践中提炼出来的不是技巧是判断依据1. 约束 文档 对话。能机械执行的不靠说能写文件的不靠记。你的 CLAUDE.md 再完美也不如一个 linter 靠谱。这是本文最核心的一句话——如果你只记住一条记住这条。2. Memory 需要淘汰机制。不删的 memory 是负债不是资产。每月 review 一次删掉过时的条目把经过验证的临时记录提升为稳定规则。记忆越少越准确远好过记忆又多又旧。3. 文件是唯一可靠的跨 session 载体。Plan 状态、决策记录、session 摘要全部落盘到文件系统里。不信任对话上下文不信任 AI 的”记忆”不信任你自己的记忆。文件在状态就在。4. Skills 的复利来自框架化。单次 prompt 是消耗品——用一次就没了。一个带模板、带流程、带质量关卡的 skill用十次和用一百次的边际成本趋近于零。判断标准很简单某个流程你手动做了三次以上就该 skill 化。5. 先跑通再优化但跑通后必须提炼。不要过早抽象——第一次做的时候怎么快怎么来。但也不要永远手工——跑通了、验证有效了就花 15 分钟把它固化成 hook 或 skill。否则下次还是从零开始你的经验没有累积效应。八、回到开头还记得开头的三个场景吗换了项目目录AI 忘了偏好—— 全局 CLAUDE.md 分层 memory 系统跨项目提供一致的上下文。新 session 断片不知道做到哪了—— Plan 文件里有 checkbox 状态dev-log 里有昨天的 session 摘要打开就能继续。AI 无视 CLAUDE.md 里的规则—— Linter hook 在 session 开始时就已经扫描完了违规代码无处藏身。这三个问题的共同点是它们都不能靠”写更好的 prompt”来解决。它们需要的是系统层面的保障。如果你现在就想动手这三件事可以立刻做1. 加一个 SessionStart hook。哪怕只是echo session started先建立”session 开始时自动跑点什么”的习惯。等你习惯了再往里加 preflight 检查、linter 扫描。2. 把你最常重复跟 AI 说的那句话从对话搬到文件里。如果你每个 session 都要说一遍”用 TypeScript 不要用 JavaScript”那它就不应该只活在对话里——它应该在 CLAUDE.md 或 memory 文件中。3. 今天 session 结束时手动写 3 行日志。项目名、做了什么、明天继续什么。明天开 session 时让 AI 读这个文件。你会立刻感受到”有记录”和”没记录”的差别。