一句话

非交互地解掉合并冲突，以正确性优先做最小修改，跑通编译和测试后总结关键取舍。

何时用

• 适合：分支有未解决冲突，需要一条可靠路径回到可构建状态。
• 不适合：还没产生冲突的预防性 rebase；想顺手做重构（明确禁止）。

怎么用

把这个分支和 main 的冲突解掉，解完跑编译和测试

1. 从 git status 和冲突标记找全冲突文件。
2. 逐个做最小、正确性优先的解决；能两边都保留就都保留，否则选能编译且公开行为稳定的版本。
3. lockfile 用包管理器重新生成，不手改。
4. 跑编译、lint 和相关测试，stage 已解决文件并总结关键决定。

产出

• 已解决的文件清单、值得说明的取舍、构建和测试结果。

要点与坑

• 硬规则：任何文件不留冲突标记；解冲突期间不做大范围重构、不 push、不打 tag。
• 拿不准哪边对时，标准是能编译且公开行为不变。

关联

• 同类：ctk-fix-ci · 上游：ctk-loop-on-ci
• 所属：00-ctk-概览 · 工作流：W7-交付与运维循环