本文素材来自一个 Reddit 热帖。原帖作者问了个很诚实的问题："我一直在用 Claude Code，但感觉还是把它当聊天机器人在用。重度用户到底靠什么工作流？"下面是他收到的、也是最值得抄作业的三个回答。

先说结论：你和高手的差距，大概率不在提示词写得好不好，而在你有没有把 Claude Code 从"回答机器"改造成"带工具、能自查的执行体"。

说人话就是——它不能只"说"，得能"做"、能"查"、能"证伪自己"。

---

为什么"聊天框模式"会卡住你

聊天框模式长这样：你问 → 它答 → 你复制。

问题在哪？它给出的每一行代码，都没有经过任何真实环境的检验。它说"我写完了，一切正常"，你只能选择相信。可"说完成"和"真完成"之间，隔着一整个幻觉与埋雷的宇宙。

高手的做法是给 AI 装上眼睛和手脚，让它自己跑一遍、自己看结果。下面三个习惯，恰好是三层递进的"验证闭环"。

---

习惯一：给它一个能"跑起来"的 MCP 执行环境

痛点
Claude Code 默认就能读写文件、跑命令（只要你授权）。但真正让它"自查"的，是让它能触达你的真实系统——而不是在真空中生成代码。

最小可行做法
搭一个 MCP server，把三件事暴露给 Claude Code：

• 在 REPL 里执行一段代码，看真实输出；
• 查询本地数据库，确认数据真的写进去了；
• 读取本地服务的日志，确认没有偷偷报错。

为什么有效
当它能自己跑一下、亲眼看到结果，它就不会轻易说出"一切正常"——因为它刚看过。自我纠正的前提，是它有自己的眼睛。这跟写单元测试还不太一样，它更偏向探索期和调试期的即时反馈：改完马上跑，错了马上改。

一句话：别让它"嘴上说完成"，要让它"手上见真章"。

---

习惯二：让它能跑自动化测试套件

痛点
“打地鼠"你一定见过：你让它修一个 bug，它改完说"好了”，结果另外两个功能悄无声息地挂了。没有回归保护时，这几乎是必然。

最小可行做法
把测试命令（pytest / jest / go test 都行）接到 Claude Code 能调用的地方，要求它每改完一轮就跑一遍，把结果贴回来看。

为什么有效
测试给的是客观证据，不是 AI 那句"我感觉没问题"。它同时回答了两个问题：

1. 刚写的代码真的 work 吗？
2. 有没有顺手把别的地方搞挂？

第二个问题，才是资深工程师最在意的。测试套件相当于 AI 的"第三方审计"——比它自己的嘴可靠得多。

一句话：让 AI 用测试结果说话，而不是用自信说话。

---

习惯三：沉淀一个"基于你反馈"的代码审查技能

痛点
你有没有发现，自己总在重复纠正同一类问题：命名、架构分层、风格偏好……AI 不会自动记住这些，下次照样犯。

最小可行做法
让 Claude Code 回顾你的会话历史，统计你频繁纠正的那些点，据此生成一个"代码审查技能"（review skill）；之后每次提交前，让它按这个技能先自查一遍。并且定期（比如每两周）更新一次，把新冒出来的偏好补进去。

为什么有效
这一步是把"你的标准"从脑子里的隐性知识，变成 AI 可执行的显性规则。它越用越像你，你纠错的次数越来越少——这才是复利。

但要提醒一句：技能会过期，标准会变，"定期更新"不是可选项，是必选项。

一句话：别每次都从头教它，把你的标准固化成它能复用的能力。

---

你现在是哪种？

• □ 只用聊天框，复制答案就走
• □ 接了 MCP / 测试，但还没固化成习惯
• □ 有个人审查技能，而且定期维护

如果你还在第一格，别慌，今天这篇就是起点。这三个习惯不用一次到位，从"让它跑一下测试"开始，就已经甩开大多数纯聊天框用户了。

你还有什么"让 AI 自己查自己"的骚操作？ 评论区聊聊，我挑几个下期拆给你看。