本文素材来自一个 Reddit 热帖。原帖作者问了个很诚实的问题："我一直在用 Claude Code，但感觉还是把它当聊天机器人在用。重度用户到底靠什么工作流？"下面是他收到的、也是最值得抄作业的三个回答。
先说结论：你和高手的差距，大概率不在提示词写得好不好，而在你有没有把 Claude Code 从"回答机器"改造成"带工具、能自查的执行体"。
说人话就是------它不能只"说"，得能"做"、能"查"、能"证伪自己"。
为什么"聊天框模式"会卡住你
聊天框模式长这样：你问 → 它答 → 你复制。
问题在哪？它给出的每一行代码，都没有经过任何真实环境的检验。它说"我写完了，一切正常"，你只能选择相信。可"说完成"和"真完成"之间，隔着一整个幻觉与埋雷的宇宙。
高手的做法是给 AI 装上眼睛和手脚，让它自己跑一遍、自己看结果。下面三个习惯，恰好是三层递进的"验证闭环"。
习惯一：给它一个能"跑起来"的 MCP 执行环境
痛点 Claude Code 默认就能读写文件、跑命令（只要你授权）。但真正让它"自查"的，是让它能触达你的真实系统------而不是在真空中生成代码。
最小可行做法 搭一个 MCP server，把三件事暴露给 Claude Code：
- 在 REPL 里执行一段代码，看真实输出；
- 查询本地数据库，确认数据真的写进去了；
- 读取本地服务的日志，确认没有偷偷报错。
为什么有效 当它能自己跑一下、亲眼看到结果，它就不会轻易说出"一切正常"------因为它刚看过。自我纠正的前提，是它有自己的眼睛。这跟写单元测试还不太一样，它更偏向探索期和调试期的即时反馈：改完马上跑，错了马上改。
一句话：别让它"嘴上说完成"，要让它"手上见真章"。
习惯二：让它能跑自动化测试套件
痛点 "打地鼠"你一定见过：你让它修一个 bug，它改完说"好了"，结果另外两个功能悄无声息地挂了。没有回归保护时，这几乎是必然。
最小可行做法 把测试命令（pytest / jest / go test 都行）接到 Claude Code 能调用的地方，要求它每改完一轮就跑一遍，把结果贴回来看。
为什么有效 测试给的是客观证据，不是 AI 那句"我感觉没问题"。它同时回答了两个问题：
- 刚写的代码真的 work 吗？
- 有没有顺手把别的地方搞挂？
第二个问题，才是资深工程师最在意的。测试套件相当于 AI 的"第三方审计"------比它自己的嘴可靠得多。
一句话：让 AI 用测试结果说话，而不是用自信说话。
习惯三：沉淀一个"基于你反馈"的代码审查技能
痛点 你有没有发现，自己总在重复纠正同一类问题：命名、架构分层、风格偏好......AI 不会自动记住这些，下次照样犯。
最小可行做法 让 Claude Code 回顾你的会话历史，统计你频繁纠正 的那些点，据此生成一个"代码审查技能"（review skill）；之后每次提交前，让它按这个技能先自查一遍。并且定期（比如每两周）更新一次，把新冒出来的偏好补进去。
为什么有效 这一步是把"你的标准"从脑子里的隐性知识，变成 AI 可执行的显性规则。它越用越像你，你纠错的次数越来越少------这才是复利。
但要提醒一句：技能会过期，标准会变，"定期更新"不是可选项，是必选项。
一句话：别每次都从头教它，把你的标准固化成它能复用的能力。
你现在是哪种？
- □ 只用聊天框，复制答案就走
- □ 接了 MCP / 测试，但还没固化成习惯
- □ 有个人审查技能，而且定期维护
如果你还在第一格，别慌，今天这篇就是起点。这三个习惯不用一次到位，从"让它跑一下测试"开始，就已经甩开大多数纯聊天框用户了。
你还有什么"让 AI 自己查自己"的骚操作？ 评论区聊聊，我挑几个下期拆给你看。