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