提交前先分类：互相影响的放一起，独立的分开

一个开发者在一条消息中把数据库列从 user_name 改名为 display_name，然后单独发一条让 Claude 更新 API 序列化器。两个改动都做完后，应用崩了——ORM 模型仍然引用 user_name，而序列化器期望 display_name。ORM 模型掉进了两条消息之间的缝隙。

这是互相影响的改动被当作独立的提交了。列改名、ORM 模型更新和序列化器改动都连接着同一个数据结构。它们应该是一条消息。

规则

互相影响的问题 — 修一个会影响另一个的改动 — 放进一条消息。Claude 原子性地处理它们，一次看到改动的所有方面。

独立的问题 — 没有共享代码、数据结构或接口的改动 — 放在分开的顺序消息中。每个得到聚焦关注，开发者在继续前审查。

什么让问题互相影响

问题在共享以下内容时互相影响：

• 函数或接口 — 重命名函数需要更新所有调用方
• 数据结构 — 给模型加字段影响每个读写该模型的文件
• 文件 — 改动同一文件的两个变更可能冲突或重叠
• 契约 — 改 API 响应格式影响处理器和所有消费者

一个跨 8 个文件的函数重命名和一个影响 5 个文件的新字段添加，如果有 3 个文件重叠就互相影响。应该一起提交。

styles/button.css 的 CSS 修复和 api/users.ts 的 API 校验修复没有共享内容。它们是独立的。

数据

一个团队在一个 sprint 中比较了提交 20 个问题的两种策略：

分类分组用了更多消息但后续修复减少了 77%。包含返工在内的总时间更低，尽管消息数更多。

提升不是来自更多消息。把 20 个问题随机拆成 12 条消息不会达到 8%。提升专门来自把互相影响的放一起、独立的分开。

分类步骤

提交给 Claude 之前，对每个问题分类：

1. 对每对问题问：修一个会影响另一个吗？
2. 把互相影响的分组为单条消息批次
3. 独立的问题作为单独的顺序消息处理

对于一个有 15 个问题的积压：4 个 auth 模块问题（互相影响）、3 个校验层问题（互相影响）、8 个不相关问题（独立）：

• 消息 1：全部 4 个 auth 问题一起
• 消息 2：全部 3 个校验问题一起
• 消息 3-10：每个独立问题单独一条，之间有审查

常见错误

把互相影响的改动拆到多条消息。 DB 列改名的例子。还有：一条消息改函数签名，另一条更新调用方。Claude 的第二条消息聚焦于它的具体任务而不会重访第一条消息的文件。

把所有东西塞进一条消息。 混合 5 个不相关问题稀释了 Claude 的注意力。独立问题在 Claude 能一次专注一个时得到更好的处理。

按严重度或复杂度排序而不是按交互性。 一个关键的独立修复和一个轻微的互相影响修复有不同的分组需求。严重度决定优先顺序；交互性决定分组。两者都重要，各自独立。

在一条消息中用标记。 [问题 1] 和 [问题 2] 标签在一条消息中仍然要求 Claude 在不相关问题之间切换上下文。分开的消息提供真正的聚焦分离。

一句话总结： 互相影响的问题放一条消息保原子一致性；独立的问题放分开的消息保聚焦关注——提交前先分类，后续修复从 35% 降到 8%。