Claude Code创建者建议：大改动别急着写代码，先对齐再动手

为什么Claude Code创建者反而劝你别急着写代码

在AI编程工具越来越强的今天，一个反直觉的建议来自Claude Code的创建者Boris本人：面对大改动，先别急着让AI写代码。

Claude Code是Anthropic推出的一款命令行AI编程助手，它可以直接在终端中运行，理解整个代码仓库的上下文，执行文件读写、运行命令等操作。与Copilot等补全式工具不同，Claude Code更接近一个「AI开发者同事」——你可以用自然语言跟它对话，让它完成跨文件的复杂任务。Boris Cherkasky作为其核心创建者，对产品的能力边界和最佳实践有第一手的认知。

这听起来有些矛盾。既然AI能自动生成代码，为什么不直接抛出需求让它一路写下去？Boris的答案很直接——仓库没摸清、方向没对齐时，写得越快返工可能越多。当你只丢一句「把这个功能做完」，AI可能沿着一个错误的方向一路写下去，等你发现问题时，已经堆积了大量需要推翻的代码。

这期视频拆解了Boris的官方演讲，核心只讲一件事：面对大改动，正确的AI编程协作方式是什么。这不仅仅是使用技巧，更是一种与AI协作的思维方式转变。

第一步：先用Claude Code提问，别急着改代码

Boris给新人的第一个建议是：第一次用Claude Code，先拿它问代码库，别急着改。

具体怎么问？比如：

• 这个功能的入口在哪里？
• 相关的测试在哪里？
• 这段逻辑为什么这么写？

这样提问有双重目的。表面上你在让它帮你定位文件、理清结构；更深一层，你其实是在试探它到底理解了多少——哪些地方它真的懂了，哪些地方还需要你自己盯着。

这一步至关重要。AI的输出质量高度依赖它对上下文的理解。AI模型处理信息依赖「上下文窗口」（Context Window），即模型单次能处理的token数量上限。即便现代模型的上下文窗口已扩展到数十万token，但对于大型代码仓库（动辄数十万行代码），模型仍然无法一次性「看到」所有内容，它需要有策略地检索和理解相关文件。如果它对代码库的认知本身就有偏差，那么后续生成的代码只会把偏差放大。先通过提问校准它的理解，本质上是帮助AI在有限的注意力资源内聚焦到最关键的上下文，等于给整个协作过程打好地基。

第二步：让AI先说方案，确认后再动手编码

假设你要加一个会动到多个文件的功能。这时候最忌讳的就是一句话丢过去让它自由发挥。

更稳的做法是先让它说清楚：准备改哪些文件？为什么这么改？ 拿到方案后，如果方向不对，你在方案阶段纠正，通常比等代码全部写完再返工要省事得多。

这个逻辑其实和软件工程中的「设计评审」一脉相承。设计评审（Design Review）是软件工程中一项成熟的质量保障实践，核心思想是：缺陷发现得越早，修复成本越低。据行业统计，需求阶段发现的问题修复成本约为编码阶段的1/10到1/100。在现代开发流程中，RFC（Request for Comments）文档和ADR（Architecture Decision Record）都是这一思想的延伸。在传统开发中，我们会在动手前先做技术方案评审，因为修改一份文档远比重构一堆代码成本低。AI编程协作同样适用这个原则——方案阶段的一次纠偏，可能省下后面几十次的代码返工。

第三步：写完就验证，用结果形成闭环

方案对齐以后，再进入真正的编码环节。而Boris强调的一个关键点是：写完要立刻验证。

• 写接口，就跑测试；
• 做页面，就看截图。

为什么必须验证？因为Claude Code看见结果，才知道下一遍该怎么改。在控制论和系统工程中，没有反馈信号的系统被称为「开环系统」，其输出无法自我修正。AI在没有测试结果或视觉反馈的情况下生成代码，就是典型的开环操作——它只能基于训练数据中的模式猜测正确答案，而无法根据实际运行情况进行调整。测试结果和页面截图是AI迭代的反馈信号，引入这些信号将开环变为闭环，显著提升了迭代的准确性。同时，你自己也能拿着这些结果去复核，判断功能是否真的达标。

这形成了一个完整的闭环：读仓库 → 出方案 → 写代码 → 跑验证 → 拿结果回炉。每一步都有明确的产出和检查点，而不是把整个任务当成一个黑盒。这本质上是将敏捷开发中的快速反馈循环应用到人机协作中，每个迭代周期越短，偏差被放大的空间就越小。

一段可复用的Claude Code提示词模板

把上面这套流程合成一段提示词，可以这样写：

先读仓库，告诉我功能入口、相关测试，还有可能要改的文件；先把方案给我看，我确认后再写；写完跑测试，把结果一起交回来。

这段提示词把「理解 → 方案 → 编码 → 验证」四个环节全部串联起来，让AI在一个受控的流程里工作，而不是自由狂奔。值得注意的是，这种结构化提示词的设计思路也适用于其他AI编程工具——无论是Cursor、Windsurf还是其他Agent，核心逻辑都是通过明确的阶段性指令来约束AI的行为边界。

什么时候该走完整流程，什么时候可以直接写

你可能没注意到，Boris并没有说每个任务都要走这一整套流程。判断标准在于任务的范围和方向的确定性。

• 小任务、改法明确：直接写更省事，不必层层确认；
• 范围大或方向不明：先看方案，确认它懂了什么、准备怎么改。

这是一个非常务实的态度。流程本身是工具而非教条，过度流程化反而会拖慢效率。关键是学会判断——什么时候该踩刹车，什么时候可以放手。一个简单的经验法则：如果你能在脑中清晰预见改动的影响范围（涉及哪些文件、哪些模块的行为会改变），那就可以直接写；如果你自己都不太确定「这一刀切下去会波及什么」，那就是该先看方案的时候。

结语：AI编程协作的核心是「先对齐再动手」

回顾Boris的整套建议，其内核可以浓缩成一句话：大改动先别催它写，先确认它懂了什么、准备怎么改，最后看它拿什么证明做完。

这背后反映的是一个更深层的认知转变——在AI编程时代，程序员的价值不再只是敲代码，而是扮演方向的把控者和结果的验收者。AI负责执行的速度与广度，人负责判断的方向与质量。这与历史上多次技术变革中的角色演进类似——从汇编到高级语言，程序员不再关心寄存器分配；从手写SQL到ORM，开发者不再手动优化每条查询。每次抽象层级的提升，都将从业者推向更高层次的决策角色。在AI编程协作中，判断力、架构思维和验收能力正在成为核心竞争力。

所以下次面对一个复杂需求时，不妨先问自己：我该在什么时候停下来先看方案？当范围一大、或者方向开始拿不准的时候，就是该踩刹车的时刻。

核心要点