用途：这是一条并发设计原则，适用于多个并发执行者（进程、智能体、任务）可能写入同一文件、分支、键或状态对象的场景。核心主张是先判断它们是否真的需要同一个可变对象；若不需要，就消除共享；若共享是真实不变量，再用结构化手段串行化访问。
主要能力与要点：
- 识别共享可变状态，例如双方都读写的文件、都推送的分支、既定义又消费的 API。
- 默认做法是消除共享写入目标：给每个执行者独立的文件、键、分支或状态目录，只在读取或汇报边界合并。资料指出，两个 worker 各自把 lastX 字段写进同一个 state.json 仍属于共享变更；而 indexer-state.json 与 metrics-state.json 分开则不算。
- 仅当单一共享写入目标确为真实不变量时，才结构化串行化，例如锁文件、顺序阶段、单写入者执行者或原子比较并交换。
- 强调指令和约定不是并发控制；把“我们需要一把锁”视为需要检查的设计气味，而非默认答案。
理由：对共享状态的并发写入会产生竞态条件，这类问题间歇出现、难以复现、调试成本高。
使用方式：在并发设计评审或实现前，先列出共享可变状态，再按上述默认路径消除共享；无法消除时选择一种结构化串行化机制。
限制：资料未提供具体代码示例、安装命令、平台支持、性能数据或收费信息，暂未提供。