这是一条关于并发共享状态处理的设计原则，来源于技能条目 principle-separate-before-serializing-shared-state，主题为“先分离，再串行化共享状态”。
用途 当多个并发执行者（进程、智能体、任务、分支等）可能写入同一可变状态时，用于指导如何避免竞态条件。它要求先质疑共享本身是否必要，再考虑是否以及如何串行化访问。
主要能力
- 识别共享可变状态：例如双方都读写的文件、双方都推送的分支、双方既定义又消费的 API。
- 默认消除共享写目标：判断这些执行者是否需要同一个规范对象，还是只是在发布各自独立的事实；若属于后者，则给每个执行者分配其独占的文件、键、分支或状态目录，只在读取或汇报边界进行合并。
- 明确反例：两个执行者把各自的 lastX 字段写入同一个 state.json，仍属于共享变更；而 indexer-state.json 与 metrics-state.json 分离则不属于。
- 结构性串行化：仅当“只有一个共享写目标”确实是真实不变式时，才通过锁文件、顺序阶段、单写者执行者或原子比较交换等方式强制串行访问。
- 设计态度：把“我们需要一把锁”视为需要检查的设计气味，而不是默认答案。
使用方式 按文中给出的模式操作：先识别共享可变状态，再默认消除共享写目标，最后仅在必要时做结构性串行化。文中未提供具体的安装命令、代码示例或调用步骤。
适用场景 适用于并发执行者可能写入同一文件、分支、键或状态对象的工程与系统设计情境，包括多进程任务、多分支协作、共享状态文件写入等。
限制 说明与约定本身不构成并发控制；共享写入会导致间歇性、难以复现且调试成本高的竞态条件。串行化应作为最后手段，仅在共享写目标确为不变式时使用。其余具体实现细节、平台与工具支持情况，资料中暂未提供。