这个动作你一天大概要重复多少次？让 AI 写了一段代码，看着不太对，又说不上来哪不对，于是复制粘贴开个新对话，重新贴一遍项目上下文，补一句"帮我看看这里是不是有问题"，然后再花十分钟辨别它的回复里哪些是真话、哪些是它为了显得有用而硬挤出来的建议。我上个月统计了一下，一天七八次是有的。
这事儿的根源其实特别简单：AI 生成代码的速度太快了，快到它自己都懒得跟你确认"我到底有没有看懂你的意思"。你问它这段逻辑有没有问题，它默认的回应方式是直接甩给你一段"优化后的版本"——哪怕你只是想让它看看边界条件是不是漏了一个。结果就是，代码越写越多，理解越来越薄。你被它带着走，它替你做了判断，你只剩下复制粘贴的手速。
前几天 arXiv 上刚挂了一篇论文——《Practical Implementation Report on Introducing Spec-Driven Development Using AI Agents in Software Development PBL》，讲的是在一门本科三年级的项目式学习课程里引入 AI 智能体辅助开发的实践。八月的预印本，软件工程方向，CSEE&T 2026 录用。论文本身写的是教学场景，但我读完之后发现它顺手戳破了一件事，就是大多数 AI 辅助开发的痛点和教室里学生遇到的一模一样：AI 智能体的使用确实提高了实现吞吐量，但也倾向于让学生（以及我们这些"非学生"）在没完全理解代码的情况下继续往前推。论文里那句"教师定期核查学生的代码理解"——说实话，翻译成日常工作流，就是我们自己得给自己当那个定期核查的老师。
论文提出了一套规格驱动开发的流程，分四个阶段：调研、规划、实现、审查。这套东西在课堂里大概是有用的，但我不想把整套搬进自己的工作流，太重了。我只想偷走"审查"那一步里最核心的动作。
我的改法是在 CLAUDE.md 里加了一条规则。
对，就是那个 Claude Code 启动时自动读的 CLAUDE.md。以前我只往里面放项目技术栈、目录结构、注意事项这类东西，现在多加了一条：
## 代码理解核查
让我改代码之前，先复述一遍这段代码的实际行为，然后再说建议。直接甩优化版本之前，先告诉我你理解了什么。
就这一行。
⚡这一下的效果是：从那之后，AI 不能再靠"给个新版本"糊弄过去了。它必须先解释一遍它看到的代码——实际逻辑、数据流、边界情况。而我只需要听它复述，就能立刻发现它是不是真的懂了，还是在拿一段表面光滑的代码敷衍我。上周有一次它复述出来的逻辑跟我的意图差了十万八千里，要不是这条规则逼它先开口，我可能就稀里糊涂把它的"优化版本"合进去了——然后花一下午排查一个我根本不理解的 bug。
以前让 AI 改代码，默认就是"给出优化版本"，你拿到之后得自己逆向工程它到底动了什么。现在它先复述，你确认它理解对了，再让它动手改。省掉的是最贵的那个环节：读 AI 生成的代码然后试图搞懂它为什么这么写。这个改法纯属论文里那句"代码理解"的直译——那天读到那句话我就想，与其事后核查理解，不如让 AI 在动手之前把理解说出来，提前把这个弯掰过来。
三分钟配置，这周用下来大概省出了小半个下午。当然这招也不是万能的，如果只是写个 CRUD 接口或者那种一眼望到头的样板代码，让它先复述反而是浪费时间——那种场景直接 Tab 到底就完事了。但只要是牵扯到状态流转、边界条件、或者那种你自己也要想一想的逻辑，这条规则就是我的第一道安检。
论文里还有一个观察我记得很清楚：AI 的使用模式在不同开发阶段和不同团队之间差异很大。翻译一下就是，有人拿 AI 当加速器，有人拿它当拐杖。区别就在于你有没有让它先复述一遍。说到底 AI 替我们写代码这件事本身没问题，问题在于它写完之后，我们是不是真的看懂了它写的什么。让 AI 先开口的那一下，就是省掉"事后才发现没看懂"的那个瞬间。
这配置粘贴进去，下一回就生效。你有更顺手的写法，教教我——尤其如果你找到了让 AI 在长会话里别"假装听懂"的办法，那才是这个问题的终极解法。