用途：这是一条面向并发设计的原则性技能，用于判断多个并发执行体写入共享可变状态时应如何处理。触发条件是并发执行体可能写同一文件、分支、键或状态对象。
主要能力：
- 识别共享可变状态，例如双方都读写的文件、都推送的分支、既定义又消费的 API。
- 默认建议消除共享写目标：判断这些执行体是否需要同一个规范对象，还是仅在发布各自独立的事实；若是后者，让每个执行体拥有自己的文件、键、分支或状态目录，只在读取或汇报边界合并。
- 区分伪共享与真共享：两个工作者把各自的 lastX 字段写入同一个 state.json 仍属共享变更；而 indexer-state.json 与 metrics-state.json 分离则不构成共享。
- 仅当单一共享写目标确为必要不变量时，才从结构上串行化访问，手段包括锁文件、分阶段串行执行、单写者执行体或原子比较交换。
- 提醒把“我们需要一把锁”视为需要复核的设计信号，而非默认答案。
使用方式：在并发任务设计或评审阶段，先列出可能的共享可变状态，再按上述顺序判断能否消除共享；确认无法消除后，再选择一种结构性串行化机制。该资料未提供具体工具安装命令或代码示例。
适用场景：多智能体并行写入、并行分支推送、共享状态文件设计、并发 API 定义与消费等需要避免竞态条件的工程场景。
限制：资料未说明具体平台、实现语言、依赖或收费信息；也未给出可执行脚本与验证步骤，实际落地需结合具体工程环境判断。