如果你最近一段时间开始认真用 Claude Code，大概率已经进入过一种很熟悉的状态：
有时候你会觉得它简直离谱。
你给它一个需求，它能：
- 自己看代码
- 自己找文件
- 自己跑命令
- 自己定位报错
- 自己写实现
- 甚至还能顺手把测试补上
那一刻你会产生一种特别强的幻觉：
“这不就是一个不知疲倦、还挺会干活的程序员吗？”
但再过几小时，你可能就会被它气得想关终端。
比如：
- 明明只是修一个 bug，它顺手把 lint 配置改松了
- 明明只是补一个接口，它多改了 8 个无关文件
- 明明昨天已经查过一轮，今天像重新投胎一样又问一遍
- 明明你开了两个会话想并行推进，最后
git diff像车祸现场 - 明明它说“已经修复”，结果一跑验证，build 直接红了
如果你也经历过这些场面，那恭喜你：你已经触摸到了 Claude Code 真正的使用门槛。
这本小册就是从这个门槛开始的。
因为我越来越确信一件事：
Claude Code 最大的问题，不是“它还不够聪明”，而是“它还没有被放进一个足够像样的工作环境里”。
换句话说，问题很多时候不是模型本身，而是模型外面那层工作流、规则、记忆、验证和协作机制没有搭好。
这一章，我们不谈配置，不谈 hooks，不谈 MCP，更不谈什么多智能体未来。
我们只做一件事：
先把问题看清楚。
因为如果你连 Claude Code 为什么会“时灵时不灵”都没看明白，后面所有技巧都会沦为打补丁。
一、Claude Code 真正让人上头的地方，不是它会写代码，而是它会“像人在工作”
先承认一个事实：Claude Code 之所以这么容易让开发者上头，不是因为它比 ChatGPT 多了几个按钮，而是因为它第一次让很多人感受到：
AI 不只是会说，它开始会“做”了。
你会看到它：
- 读
README - 查
package.json - 搜目录
- 跑
pytest - 看错误日志
- 修改文件
- 再回头继续推理
这套动作一连起来，就很容易让人脑子里自动补出一个画面：
电脑里好像真的住进去了一个“数字同事”。
这个画面非常有诱惑力，因为它和我们熟悉的人类工作方式很像。
但这个相似感也是最容易制造误判的地方。
因为你会下意识地认为：
既然它已经像人在工作，那真正决定上限的，应该就是“它够不够聪明”。
于是后面一旦出问题，最自然的归因就会变成：
- 模型不行
- 这轮提示词没写好
- 换个更强模型试试
- 加一句“认真思考”试试
这些归因不能说完全错，但经常只碰到了表层。
因为 Claude Code 最有意思的地方，不在于“模型突然变成程序员了”，而在于：
有人把模型外面那层工作环境搭到了一个足以让它看起来像在工作的程度。
这层工作环境是什么，我们后面会系统讲。
你现在先记住一句话就够了：
Claude Code 之所以像“会干活”，不只是因为模型强，更因为它被接上了工具、上下文和行动闭环。
而这也意味着，一旦外面这层环境不稳定，它就会立刻从“像个很能打的程序员”退化成“第一天上班的实习生”。
二、Claude Code 最常见的 5 种翻车方式
先别急着讲原理。
我们先把常见翻车模式摊开。
因为大多数开发者真正的困扰，不是“Claude Code 是什么”，而是：
“它为什么明明很强，但经常强得不稳定？”
我把这类问题大致归成 5 种。
1. 会动手，但不一定会收手
这是最常见的一类。
比如你让它：
“修一下这个登录页按钮点击无效的问题。”
理论上，这应该是个局部修复任务。
但它很可能会：
- 先扫一遍整个组件树
- 顺手整理几个文件结构
- 发现有重复样式
- 再顺手抽个 hooks
- 改着改着觉得 lint 很烦
- 最后把一个局部 bug 变成半个页面的无关重构
这个现象特别像一个能力很强、但还没学会节制的新同事：
- 看见什么都想顺手优化
- 什么都能讲出一点理由
- 但不太知道“这次到底应该只做什么”
这里最核心的问题不是它不会写代码，而是：
它没有清晰的任务边界。
2. 会查资料，但不会稳定记住自己查过什么
这类问题在长会话里特别明显。
比如第一轮它已经查清楚：
- 项目用的是
vitest - 某个接口在
apps/api/src/routes/user.ts - 当前构建失败是因为一个类型定义错位
结果两小时后，你再让它继续干，它可能会重新来一遍：
- 再读一次
package.json - 再搜一次测试框架
- 再查一次目录结构
你很容易觉得这是模型变笨了。
但更准确的说法是：
它没有被放进一个足够好的长期记忆和上下文管理系统里。
人类程序员也会忘，但人类会做这些事：
- 写 TODO
- 开 issue
- 记会议纪要
- 在 PR 里留交接说明
如果 Claude Code 没有类似机制，它当然会一遍遍重来。
3. 会并行，但不一定会协作
很多人第一次体验“多开几个 Claude Code 会话并行工作”时，会非常兴奋。
这事儿看起来太美了：
- 一个窗口查问题
- 一个窗口改后端
- 一个窗口改前端
- 另一个窗口跑测试
结果实际一跑，很快就开始出事：
- 两个会话同时改同一个文件
- 一个会话基于旧状态做了修改
- 另一个会话又把它覆盖了
- 最后你连哪个改动是谁做的都说不清
这种问题的本质并不是“Claude Code 不会并行”，而是：
并行不等于协作。
要让多个工作流并行，你需要：
- 任务边界
- 状态同步
- 工作区隔离
- 交接机制
如果这些没有，多开几个终端只是在扩大混乱。
4. 会回答“完成了”，但不一定真的通过了
这类问题应该每个开发者都遇到过。
Claude Code 很容易在某个阶段给你一句看上去很专业的话：
“问题已经修复，建议你验证一下。”
这句话表面上非常礼貌，实际上经常暗含一个非常危险的信息：
“我现在主观上觉得差不多了，但我没有把验证这件事做成强约束。”
如果系统里没有明确的验证闭环，它就很容易把：
- 我改了代码
- 我觉得逻辑通了
误当成：
- 真的构建通过了
- 类型检查通过了
- 测试通过了
- 回归没有问题
对开发者来说，这种错觉比“不会写”更危险。
因为它会让你产生一种虚假的完成感。
5. 会工作，但不一定知道什么叫“只做这次该做的事”
最后一种问题，很多人刚开始不会意识到，但用久了非常烦。
Claude Code 有时候不是不会做，而是 太容易被当前上下文带偏。
比如你今天本来是：
- 修一个 bug
但当前上下文里恰好有：
- 上一轮性能讨论
- 一段没清掉的调研结果
- 两个没完成的重构思路
- 一堆工具输出噪声
于是它可能会在修 bug 过程中突然：
- 开始担心性能
- 开始想起重构
- 开始回头处理旧任务
看起来像“自主思考能力很强”，实际上更像：
上下文里所有东西都在抢方向盘。
这时候，问题不在模型推理能力，而在：
上下文管理失控了。
三、为什么这些问题靠“更强模型”解决不了
讲到这里，很多人还是会忍不住问一句：
“那我是不是换更强模型就好了？”
我的答案是：有帮助，但解决不了根本问题。
你可以把这件事想象成这样：
给一个很聪明的人：
- 一堆没有整理的文档
- 一个混乱的任务列表
- 没有交接说明的长任务
- 没有边界的并行协作
- 没有固定顺序的验证流程
然后再告诉他：
“你再认真一点，你应该就能搞定。”
这件事听上去就不靠谱。
更强的大脑，当然能缓解一部分问题：
- 推理更强
- 理解更快
- 抽象更稳
但它解决不了这些根本矛盾：
1. 没有边界
更强的模型只会在错误方向上走得更快。
2. 没有记忆机制
更强的模型也一样会在新会话里丢状态。
3. 没有验证闭环
更强的模型也可能“自信地错”。
4. 没有工作区隔离
更强的模型也挡不住两个会话把同一个文件改炸。
5. 没有长期工作流
更强的模型不会自动替你发明一套工程流程。
所以我现在越来越不喜欢那种简单粗暴的建议：
“不稳定？换更强模型试试。”
因为这和你代码乱成一锅粥时，有人建议你：
“别重构了，换个更聪明的程序员。”
是一个逻辑。
聪明的人当然重要。
但如果工作环境一团糟，聪明人也会被拖垮。
这就是为什么我越来越确信：
Claude Code 的核心问题，很多时候不是“智力不够”，而是“工作环境没搭好”。
四、从这一步开始，你需要换一个视角看 Claude Code
如果你认同前面这些现象，那接下来就必须做一个认知转换。
以前很多人看 Claude Code，看的都是：
- prompt 怎么写
- 模型怎么选
- 有没有隐藏命令
- 哪些功能很酷
这些当然重要，但它们都还是“工具使用技巧”的视角。
而如果你真的想让 Claude Code 在真实项目里稳定工作，就得换成另一个视角：
我是不是在给它搭一套像样的工作环境？
这个工作环境至少要回答这些问题：
- 它该用哪些工具？
- 它什么情况下必须先计划？
- 什么规范要长期生效？
- 什么知识应该按需加载？
- 上下文什么时候该清、什么时候不能清？
- 长会话状态怎么恢复？
- 多个 agent 怎么分工？
- 多任务怎么不撞车？
- 验证怎么变成默认动作？
你会发现，一旦问题换成这样，整个世界都变了。
Claude Code 不再只是一个“会帮你写代码的 AI 工具”，而开始像一个真正可以被设计、被优化、被治理的工作系统。
而这个工作系统，在工程里有一个很关键的名字：
Harness。
你可以先把它简单理解成：
模型工作的环境。
模型负责推理。
Harness 负责让推理可以稳定落地。
所以从这一章往后，我们真正要搭的，不再只是：
- 一个更会聊天的 Claude Code
而是：
- 一套让 Claude Code 持续稳定干活的工作系统
五、本章交付：Claude Code 稳定性自检表
这一章最后，我给你一份非常实用的东西。
在正式进入配置和工作流之前，你可以先用这份清单判断：
你现在用的 Claude Code，到底更像“偶尔很强的工具”，还是“开始成型的工作系统”。
自检问题 1：复杂任务有没有固定的 planning 入口？
如果没有，那它大概率会：
- 写着写着跑偏
- 做太多无关修改
- 风险暴露太晚
自检问题 2：你的长期规则和按需知识有没有分层？
如果没有，那大概率会：
- 提示词越来越长
- 优先级越来越模糊
- 上下文越来越肥
自检问题 3：高频机械动作有没有自动化？
比如：
- 验证提醒
console.log检查- 格式化
- 长命令提示
- compact 前保存状态
如果没有，这些动作迟早会漏。
自检问题 4：长会话有没有恢复机制？
如果没有，那一旦：
- compact
- 中断
- 第二天续做
它就很容易像重新投胎。
自检问题 5：验证是不是默认动作？
如果“验证”只是你偶尔想起来才做，那你得到的不是工作系统，而是高配版碰运气。
自检问题 6：并行有没有工作区隔离？
如果你已经开始多开几个会话，却还没引入任何工作区隔离，那你离翻车只差一次手滑。
六、本章小结
这一章我们还没讲怎么配置，也没讲什么进阶技巧。
我们只做了一件更重要的事：
先把问题归因看清楚。
Claude Code 之所以让人又爱又恨，不是因为它一会儿聪明一会儿愚蠢，而是因为：
- 它的确很强
- 但一旦外面的工作环境没搭好，它就很容易把“高能力”变成“高波动”
所以从下一章开始，我们不再继续讨论“怎么更会用 Claude Code”，而是开始进入真正的主线：
Claude Code 不是问题的全部。 Prompt 也不是问题的全部。 真正决定它能不能稳定干活的，是它外面那层工作环境，也就是 Harness。
下一章，我们就正式把这件事讲透：
Agent、Prompt、Harness：你真正要理解的边界。
