企业官网建设流程全解析

Cursor Team Kit 合并冲突解决实战：从冲突检测到可构建状态的标准化非交互式流程

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

导读

在多人协作的 Git 仓库中，合并冲突（merge conflict）是无法回避的日常场景，而冲突解决质量直接决定后续 CI、代码评审与发布流程能否顺利推进。Cursor Team Kit 插件的fix-merge-conflicts技能定义了一套非交互式、以"最小改动 + 正确性优先 + 可构建状态"为核心目标的标准化解冲突流程：从冲突检测、逐文件裁决，到 lockfile 重新生成、编译/测试验证，再到暂存与决策总结，全程不需要人工反复打开编辑器手工拉扯冲突标记。读完本文，你将掌握该技能在 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中定义的完整工作流，并能将其与同插件中的check-compiler-errors、fix-ci、run-smoke-tests、verify-this等技能串联成一条"冲突修复 → 本地验证 → CI 转绿"的可靠链路。

一、技能定位：什么时候该触发 fix-merge-conflicts

按照 Cursor 插件规范，每个技能通过一个带 YAML frontmatter 的SKILL.md文件声明，其中name是技能标识，description说明其适用场景。fix-merge-conflicts的声明如下：

--- name: fix-merge-conflicts description: Resolve merge conflicts non-interactively, validate build and tests, and finalize conflict resolution ---

description中两个关键词定义了该技能的适用范围：

• non-interactively（非交互式）：面向 Agent 自动执行，不依赖人工反复在编辑器中点选"接受当前/接受传入/双方合并"；
• validate build and tests（验证构建与测试）：冲突解决不以"没有冲突标记"为终点，而以"项目能编译、测试能通过"为完成标准。

其显式触发条件（Trigger）为：

Branch has unresolved merge conflicts and needs a reliable path to a buildable state. （分支存在未解决的合并冲突，且需要一条通往可构建状态的可靠路径。）

也就是说，当git status中出现both modified等冲突状态、代码中出现<<<<<<</=======/>>>>>>>冲突标记，而团队又希望快速、可靠地恢复到可编译状态时，就该启用该技能，而不是放任冲突堆积或靠"赌一把"式的手工拼接。

二、核心工作流：六步走完冲突修复

技能定义的工作流共六步，每一步都对应明确的落地动作。下面结合 Git 通用实践与 Cursor Team Kit 配套技能逐条展开。

步骤 1：从 git status 与冲突标记中检测所有冲突文件

冲突解决的第一步不是"猜"，而是穷举。需要同时使用两类信号：

• git status/git diff --name-only --diff-filter=U列出处于 unmerged 状态的文件清单；
• 在检出文件后通过正则搜索冲突标记，例如grep -rn '^<<<<<<< ' --include='*.ts' --include='*.tsx' .，确认哪些文件仍残留<<<<<<<、=======、>>>>>>>。

之所以要"双通道"检测，是因为存在两种典型漏网场景：其一，某些合并策略（如git merge -X theirs）会自动裁决，但仍可能留下逻辑层面的不一致；其二，冲突标记可能残留在被 git 判定为"已合并"但实际上内容拼接错误的文件中。只有同时核对 status 与标记，才能保证所有冲突文件都被纳入处理范围。

步骤 2：对每个冲突执行最小化、正确性优先的编辑

技能对编辑动作给出两条硬性约束：

• minimal（最小化）：只改冲突区域本身，不顺手重构、不格式化无关代码、不调整相邻函数；
• correctness-first（正确性优先）：裁决的标准是"这段代码合起来是否语义正确"，而不是"哪边改动多就保留哪边"。

这与 Cursor Team Kit 中 make-pr-easy-to-review/SKILL.md 的立场一脉相承——绝不把有意义的行为变更隐藏在"清理"之中。冲突解决阶段如果夹带无关改动，评审者将无法判断哪些差异是合并裁决引入的，哪些是顺手为之，评审噪音与回归风险都会成倍放大。

步骤 3：默认保留双方，否则选择"能编译且公共行为稳定"的一方

这是整个技能中最核心的裁决原则，原文为：

Prefer preserving both sides when safe. Otherwise, choose the variant that compiles and keeps public behavior stable.

解读为三层决策树：

1. 安全时保留双方：当两个分支修改的是不同位置、不同职责的代码（例如一个改了 A 函数的实现，另一个新增了 B 函数并调用 A），合并二者通常安全。典型做法是把两个 hunk 都保留并按语义拼接，必要时补上调用衔接；
2. 必须二选一时，以"能编译"为底线：选择当前分支与传入分支中语法完整、类型可推导、依赖引用成立的一方；
3. "公共行为稳定"是最终标尺：对于导出函数、公开 API、配置结构、数据库迁移这类对外契约，优先选择与既有调用方兼容的一方，避免合并引入隐性破坏。这正是插件中 rules/typescript-exhaustive-switch.mdc 等团队规则在合并场景的自然延伸——公共类型处理不完整，编译期就会暴露问题。

步骤 4：用包管理器工具重新生成 lockfile，而非手工编辑

当冲突发生在package-lock.json、pnpm-lock.yaml、yarn.lock、Cargo.lock、go.sum等依赖锁定文件时，技能给出了一条不可妥协的铁律：

Regenerate lockfiles with package manager tools instead of hand-editing.

原因在于 lockfile 的内部结构包含依赖树哈希、解析路径与版本指纹，手工拼接冲突 hunk 极易产生"文件格式合法但解析结果错误"的伪成功状态，后续任何一次npm ci都会失败。正确做法是在package.json（或其等价清单）完成裁决后，直接调用对应工具重新生成锁定文件，例如：

# npm 项目：按 package.json 重新解析并更新锁定文件 npm install # pnpm / yarn pnpm install yarn install # Rust 项目（Cargo.lock） cargo update # Go 项目（go.sum 通常随 go mod tidy 重新生成） go mod tidy

这条原则与 run-smoke-tests/SKILL.md 中"构建前置条件就绪后再运行测试"的次序要求相互呼应：lockfile 不干净，后续所有编译与测试命令都会建立在不稳定的依赖图上。

步骤 5：运行编译、lint 与相关测试

冲突裁决完成后必须进入验证环节，技能明确要求同时覆盖三类检查：compile（编译）、lint（静态检查）、relevant tests（相关测试）。

• 编译/类型检查：可复用同插件的 check-compiler-errors/SKILL.md 定义的工作流——运行仓库的编译与类型检查命令、按文件与错误类型归类、先修置信度最高的问题、反复运行直到干净或明确受阻；
• lint：保证合并后的代码风格与插件内 rules/no-inline-imports.mdc 这类团队约定保持一致；
• 相关测试：优先运行与被冲突文件存在调用关系的测试集。若项目存在 Playwright 冒烟测试，可参考 run-smoke-tests/SKILL.md 中的示例命令执行：

# 运行完整冒烟测试套件 npm run smoketest # 针对单个测试文件快速迭代 npm run smoketest -- path/to/test.spec.ts

步骤 6：暂存已解决文件并总结关键决策

验证通过后，用git add暂存所有已解决的冲突文件，然后必须输出一份人类与评审系统都能读懂的决策摘要。这一步常被忽视，但它决定了后续评审（对应 review-and-ship/SKILL.md 的"intent fit"检查）与问题回溯（对应 verify-this/SKILL.md 的证据链要求）能否高效进行。

三、Guardrails：冲突解决期间的四条红线

技能定义了四条护栏，违反任何一条都会让"可靠路径"重新变得不可靠：

1. 改动保持最小且可读（Keep changes minimal and readable）：与步骤 2 一致，冲突期间任何重构都是噪音；
2. 任何文件不得残留冲突标记（Do not leave conflict markers in any file）：这是可构建状态的硬前提，也是提交前必须用正则复查的兜底检查；
3. 解决冲突期间避免大规模重构（Avoid broad refactors while resolving conflicts）：重构应回到独立分支、独立 PR 中进行，可参照 new-branch-and-pr/SKILL.md 的"分支范围聚焦单一变更集"原则；
4. 冲突解决过程中不 push、不打 tag（Do not push or tag during conflict resolution）：把"推送到远端"延后到本地验证完全通过之后，避免把半成品状态广播给协作方。

这四条护栏与同插件 fix-ci/SKILL.md 的护栏互为镜像：fix-ci要求"一次只修一个可操作的失败、优先最小低风险改动"，fix-merge-conflicts则把同样的纪律前置到合并裁决环节。

四、输出规范：一次冲突解决必须交付的三样东西

技能规定的输出（Output）固定为三部分，这也是任务完成的验收清单：

第三项"Build/test outcome"尤其重要——它把冲突解决的终点从"没有冲突标记"提升到"可构建、可测试"的事实层面，为后续 review-and-ship/SKILL.md 中的"行为是否按预期工作"验证提供了可直接引用的证据，也为 verify-this/SKILL.md 的"VERIFIED / NOT VERIFIED"式结论提供了 artifact 基础。

五、在 Cursor Team Kit 中的闭环用法

fix-merge-conflicts不是孤立技能，它在插件生态中的典型协作链路如下：

git merge/pull 出现冲突 │ ▼ fix-merge-conflicts （检测 → 裁决 → 重生成 lockfile → 编译/lint/测试 → 暂存 + 摘要） │ ├──► check-compiler-errors （编译/类型错误逐文件归类与修复） ├──► run-smoke-tests （端到端冒烟验证） │ ▼ 本地验证通过 │ ▼ review-and-ship （评审、提交、打开/更新 PR） │ ▼ fix-ci / loop-on-ci （CI 失败时的快速迭代转绿路径）

安装该插件后即可直接使用这套流程，Cursor Team Kit 的设计目标正是"开箱即用、无需第三方服务集成"，安装命令参考 cursor-team-kit/README.md：

/add-plugin cursor-team-kit

六、常见冲突类型与裁决速查

结合步骤 2、3 的裁决原则，可以沉淀出四类高频冲突的处理速查：

无论哪种类型，都必须牢记：每一条裁决都要可回溯。这正是"Notable resolution choices"输出项存在的意义——它让冲突解决从"一次性行为"变成"可审计记录"。

七、验证清单：如何确认一次冲突解决真正完成

在收尾前，用以下清单做最终自检，全部满足才视为完成：

1. git status中已无 unmerged 状态文件；
2. 全仓库正则搜索无<<<<<<</=======/>>>>>>>冲突标记残留；
3. lockfile 由包管理器工具重新生成，未手工拼接；
4. 编译/类型检查通过（或已明确记录受阻项）；
5. lint 通过，未引入与团队规则（如 no-inline-imports.mdc、typescript-exhaustive-switch.mdc）冲突的写法；
6. 相关测试运行并通过，结果已记录；
7. 已暂存所有解决文件，并输出 Files resolved / Notable resolution choices / Build/test outcome 三件套；
8. 未 push、未打 tag，等待本地验证结论稳定后再进入下一环节。

这套清单把 cursor-team-kit/skills/fix-merge-conflicts/SKILL.md 中约三十行的精炼定义，落成了一条任何人（或任何 Agent）都可以照章执行的工程化流程。冲突解决从此不再是"碰运气的手工活"，而是有检测、有裁决、有验证、有记录的可重复过程——这正是 Cursor Team Kit 将日常工程纪律沉淀为插件技能的核心价值所在。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins