Claude Code标准作业流程：六个判断节点决策框架 ​

效率的瓶颈不在于它能不能做，在于你做不做对了判断——在正确的时机，用正确的方式给它正确的任务。

为什么这些判断题这么难 ​

根本原因是：Claude Code的能力边界不是一条清晰的线，是一个模糊的区间。

同样的需求，描述方式不同、上下文不同、当前会话状态不同，结果可能差很多。你没有办法靠"背答案"来应对，你需要一套判断逻辑。

六个判断节点，每个一个决策规则。

判断节点一：这个需求适不适合直接给它做？ ​

判断标准：你能不能用一段话说清楚"做完是什么样的"？

测试方法：动手之前花60秒在脑子里过一遍——如果它做完了，我怎么验证它做对了？我能写出来三条验收标准吗？

能写出来三条 → 需求清楚，可以直接给它做

写不出来 → 你自己还没想清楚，给它做最后一定来回改

踩坑案例：说"帮我做一个数据看板"，它做完了我说"不对，我想要的不是这样"——但自己也说不清楚"正确的样子"是什么。来回改了四次，花了三小时做完本来两小时能搞定的东西。

判断节点二：直接写代码还是先让它提问？ ​

判断标准：这个需求有没有你没想到的边界条件？

简单规则：涉及以下任何一项，先让它问你——

其他情况，直接给它做。

触发提问的标准Prompt：

我要实现 [一句话描述]。在开始之前，先问我你需要知道的问题，不要自己假设，问完等我回答。

判断节点三：它给的方案要不要直接用？ ​

判断标准：这个方案出了问题，修复成本有多高？

修复成本高的标准Prompt：

在实现之前，解释一下这个方案：
1）为什么这样设计而不是 [你想到的另一种方式]
2）这个方案有什么潜在的风险或局限性
3）如果三个月后需求变化，这个方案容不容易改

关键洞察：让它解释方案，不只是验证方案是否正确，更重要的是逼它把"隐性假设"说出来。它在设计方案时做了很多假设，通常不会主动说。让它解释，这些假设就会浮出来。

判断节点四：开新会话还是继续当前对话？ ​

判断标准：当前任务和上一个任务有没有代码层面的直接依赖？

强制开新会话的信号：

开新会话标准操作：

claude  # 启动新会话

第一句话：

[粘贴CLAUDE.md里的项目约定]

当前任务：[任务名称]
上下文：[上一个任务完成了什么，这个任务依赖什么]

判断节点五：做完要不要验收，怎么验收？ ​

判断标准：按任务规模分三档。

大任务验收Prompt：

你刚才完成了 [模块名]。帮我做一次自我验收：

1. 列出这个模块应该覆盖的所有场景（正常流程 + 边界情况）
2. 对每个场景，说明你的实现是否覆盖了
3. 有没有你没有实现但应该实现的部分？
4. 有没有你做了假设但没有确认的地方？

让它自己做验收清单，比你自己想要全面。

判断节点六：卡住或给错了怎么处理？ ​

判断标准：错误是方向错了，还是细节错了？

判断方法：把报错给它看，加一句：

这个错误是可以通过修改代码修复的，还是说我们的方案本身有根本性的问题？
先告诉我是哪种情况，再决定怎么处理。

让它先做诊断，你根据诊断结果决定是修还是推翻重来。

踩坑环节 ​

坑一：把"方向错了"当"细节错了"来修，越修越乱 ​

做Stripe Subscription状态同步，方案有问题，在当前对话里来回修了七八轮，每修一次感觉好一点但又有新问题冒出来。

最后花了两小时，发现根本原因是它对Stripe的事件处理顺序有一个错误假设。推翻重来，开新会话，新方案半小时搞定。

解决方案：同一个问题来回修超过三轮，停下来，先让它诊断是细节问题还是方向问题，再决定继续修还是推翻重来。

坑二：小任务没验收直接提交，bug在大任务里才暴露 ​

小任务做完看一眼感觉没问题就commit，不跑测试。某次做大任务时用到了之前小任务的函数，报了一个很奇怪的错误。排查四十分钟，发现是那个小任务里有一个边界情况没处理。

解决方案：哪怕是小任务，也至少跑一个边界情况。最快的办法是问它"这段代码最容易出问题的边界情况是什么"，然后手动测那一个。一分钟，省掉可能的四十分钟。

总结 ​

六个判断节点，每个都有明确的规则，不靠感觉，靠标准。

这六个判断节点里，你目前做得最差的是哪个？

关键词：Claude Code, 标准作业流程, 判断节点, 决策框架, 验收, 新会话