企业官网建设流程全解析

1. 从“superpowers”说起：一个让AI编程助手真正长出“超能力”的技能框架

第一次看到“superpowers”这个词，是在几个做AI辅助开发的群里。有人甩出一张截图，说自己的Claude Code突然会自己拆任务、自己写测试、自己跑验证，甚至能在改完代码后主动回滚有问题的提交。底下有人问“你装了什么插件”，答曰“superpowers”。当时我的第一反应是：又是一个包装得很花哨的提示词合集吧。直到我自己把它接进日常的Codex CLI和Claude Code工作流里跑了两周，才意识到这东西的定位其实比“提示词包”要硬核得多——它更像是一套给AI编程助手用的技能框架（agentic skills framework），把原本散落在各个对话里的“你应该先分析再动手”“你应该写测试”这类口头指令，固化成了可复用、可组合、可版本管理的技能单元。

说白了，superpowers解决的是一个很具体的痛点：AI编程助手很聪明，但它的聪明是“一次性”的。你这次教它先写测试再改代码，下次开个新会话它又忘了。你希望它遵循某种软件开发的节奏，但每次都得重新用自然语言描述一遍，描述得还不一定准。superpowers的思路是把这些“节奏”和“方法论”抽出来，做成一个个独立的技能模块，让AI在需要的时候自己去调用。这跟传统的“系统提示词”有本质区别——系统提示词是一大坨静态文本，而superpowers是按需加载、按场景触发的。

这套框架目前主要围绕Claude Code和Codex CLI这两个终端里的AI编程工具展开。如果你平时用VS Code配合Claude Code插件写代码，或者习惯在终端里敲codex命令让它帮你改bug，那superpowers能直接嵌进你现有的工作流，不需要你换工具。它适合的人也很明确：已经在用AI辅助编程、但觉得AI“不够听话”或者“每次都要重新调教”的开发者；以及想把自己团队内部的开发规范沉淀成AI可执行技能的技术负责人。至于完全没用过AI编程助手的新手，我建议先把Claude Code或Codex CLI跑通，再来看superpowers，否则会有点空中楼阁的感觉。

2. 核心设计思路拆解：为什么是“技能框架”而不是“提示词模板”

2.1 从“一次性对话”到“可复用技能”的范式转变

传统用AI编程助手的方式，基本是“对话驱动”：你打开Claude Code，输入一段需求，它给你代码，你觉得不对，再补一句“记得加错误处理”，它再改。整个过程里，你的开发方法论是隐式的，藏在你的每一次追问和纠正里。问题是，这种隐式知识没法沉淀。下次换个项目，或者隔了一周再回来，你又得从头教一遍。

superpowers做的事情，是把这些隐式知识显式化成技能文件。一个技能文件大概长这样：一个Markdown文档，里面写清楚这个技能叫什么、什么时候触发、执行步骤是什么、有哪些注意事项。比如有一个技能叫“test-driven-development”，它的触发条件可能是“当用户要求实现一个新功能时”，执行步骤就是“先写一个失败的测试，再写最小实现让测试通过，最后重构”。AI在接到任务时，会先扫描当前可用的技能列表，判断哪些技能适用，然后按照技能里定义的步骤去执行。

这个转变的关键在于：技能是可组合的。你可以有一个“代码审查”技能，一个“性能优化”技能，一个“数据库迁移”技能。当AI遇到一个复杂任务时，它可以同时加载多个技能，按照某种优先级顺序执行。这比你在一条对话里把所有要求都塞进去要清晰得多，也稳定得多。我实测下来，用技能框架约束后的AI，在遵循开发规范这件事上，一致性比纯对话方式高了不止一个档次。

2.2 为什么选择Claude Code和Codex CLI作为主要载体

superpowers目前主要适配Claude Code和Codex CLI，这个选择不是随意的。这两个工具的共同点是：它们都运行在终端里，都能直接执行命令、读写文件、调用外部工具。这意味着技能框架里的步骤可以真正“落地”——比如一个技能说“运行测试套件”，AI可以直接在终端里执行npm test，看到结果后再决定下一步。如果是在一个纯聊天的界面里，AI只能告诉你“你应该去运行测试”，然后你自己去跑，再把结果贴回来。这个来回的成本很高，而且容易断。

Claude Code和Codex CLI的另一个优势是它们都有项目级配置的概念。你可以在项目根目录放一个配置文件，告诉AI这个项目里有哪些技能可用、技能的优先级是什么。这样团队里每个人拉下代码后，AI的行为是一致的。我见过一些团队用共享的提示词文档来做类似的事，但提示词文档是给人看的，AI不一定每次都读；而技能框架是AI主动去加载的，可靠性高很多。

还有一个很实际的原因：这两个工具的命令行接口比较开放，允许你通过脚本或配置文件注入自定义行为。superpowers本质上就是一套约定好的目录结构和文件格式，AI在启动时会去扫描这个目录，把技能加载进上下文。这种“文件系统即配置”的方式，比搞一个复杂的插件系统要轻量得多，也更容易调试——技能不生效？直接去看文件是不是放对位置了。

2.3 技能框架与普通提示词工程的核心差异

很多人会把superpowers和“提示词工程”混为一谈，我觉得有必要把差异说清楚。普通提示词工程的核心是措辞优化：同样一个需求，换个说法，AI的输出质量可能就不一样。它关注的是“怎么说”。而superpowers关注的是“做什么”和“按什么顺序做”。它不关心你用什么样的语气跟AI说话，它关心的是AI在执行任务时，有没有遵循一套预定义的流程。

举个例子。假设你要让AI帮你重构一个函数。纯提示词的方式可能是：“请帮我重构这个函数，注意保持功能不变，提高可读性，顺便加上类型注解。”AI可能会做，也可能只做一部分。而用superpowers的方式，你会定义一个“重构”技能，里面写清楚：第一步，运行现有测试确保通过；第二步，分析函数的圈复杂度和重复代码；第三步，逐步提取子函数；第四步，每步之后重新运行测试；第五步，更新类型注解。AI加载这个技能后，会按步骤执行，每一步都有明确的完成标准。

这个差异带来的实际影响是：技能框架让AI的行为可审计。你可以去看技能文件里写了什么，知道AI为什么会那样做。而纯提示词的方式，AI的行为很大程度上是个黑盒，你只能通过反复试错来逼近你想要的结果。

3. 核心细节解析与实操要点：技能文件的结构与编写规范

3.1 一个技能文件应该包含哪些字段

superpowers的技能文件本质上是结构化的Markdown。根据我自己的使用和拆解，一个完整的技能文件通常包含以下几个部分：

• 技能名称：唯一标识符，通常用短横线连接的小写字母，比如test-driven-development。这个名字会被AI用来引用技能，所以不能有歧义。
• 触发条件：描述什么情况下这个技能应该被激活。可以写得很具体，比如“当用户要求添加新功能时”，也可以写得宽泛一些，比如“当涉及代码修改时”。触发条件写得好不好，直接决定了技能会不会在该用的时候被用上。
• 执行步骤：这是技能的核心，通常是一个有序列表，每一步都描述一个具体的动作。步骤要足够具体，让AI能直接执行，但又不能太死板，否则遇到边界情况就卡住了。
• 验证标准：怎么判断这个技能执行成功了？比如“所有测试通过”“代码覆盖率不低于80%”“没有新增的lint错误”。有了验证标准，AI在每一步之后可以自己检查是否达标。
• 注意事项：一些边界情况、常见错误、或者需要人工介入的场景。这部分往往是经验沉淀最多的地方。

我刚开始写技能文件的时候，容易把执行步骤写得太抽象，比如“优化代码结构”。AI看到这种步骤会懵，因为它不知道“优化”具体指什么。后来我改成“识别函数中重复出现的代码块，如果重复超过两次，提取为独立函数”，AI的执行就准确多了。所以写技能文件的一个核心原则是：能用动词+宾语+量化标准描述的，就不要用形容词。

3.2 技能之间的依赖与冲突处理

当你有多个技能时，它们之间可能会产生依赖或冲突。比如“快速原型”技能可能要求“先跑通再优化”，而“代码质量”技能要求“每次提交前必须通过lint”。如果两个技能同时被触发，AI该听谁的？

superpowers的处理方式是通过优先级和互斥标记。你可以在技能文件里声明这个技能的优先级（比如high/medium/low），以及它和哪些技能互斥。AI在加载技能时，会先解决冲突：如果两个技能互斥，就只加载优先级高的那个；如果两个技能有依赖关系，就按依赖顺序执行。

我自己的经验是，互斥标记比优先级更常用。比如我有一个“紧急修复”技能，专门用于线上出bug时快速打补丁，它的步骤里明确写了“跳过完整的测试套件，只运行相关测试”。这个技能就和“完整测试”技能互斥。如果不标记互斥，AI可能会同时加载两个，然后在“要不要跑全量测试”这件事上反复横跳，浪费很多时间。

还有一个坑是技能循环依赖。A技能依赖B技能，B技能又依赖A技能，AI就会陷入死循环。superpowers本身没有自动检测循环依赖的机制，需要你在写技能时自己注意。我的做法是画一张技能依赖图，确保没有环。如果确实需要互相调用，就把公共部分抽成第三个技能，让A和B都依赖它。

3.3 如何让技能“该触发时才触发”

技能触发时机的准确性，是这套框架好不好用的关键。触发条件写得太宽，AI会在不相关的任务上也加载技能，浪费上下文窗口；写得太窄，该用的时候又用不上。

我总结了几条实操经验。第一，触发条件里尽量包含具体的文件类型或操作类型。比如“当修改.test.js文件时”就比“当涉及测试时”要准确。第二，用否定条件排除不相关的场景。比如“当用户要求重构时，但如果重构范围小于10行代码则不触发”。第三，定期审查触发日志。Claude Code和Codex CLI都会记录AI加载了哪些技能，你可以定期看一遍，把误触发和漏触发的情况找出来，反过来优化触发条件。

还有一个技巧是给技能加一个“手动触发”的别名。有些技能你可能不想让它自动触发，但希望在想用的时候能快速调用。比如我有一个“性能剖析”技能，自动触发条件写得很窄（只在明确提到“性能”时触发），但我给它加了一个别名/perf，在Claude Code里直接输入/perf就能手动加载。这样既避免了误触发，又保留了灵活性。

4. 实操过程与核心环节实现：从零搭建一套可用的技能框架

4.1 环境准备：Claude Code与Codex CLI的安装与配置

在开始搭技能框架之前，得先把载体跑起来。Claude Code和Codex CLI的安装方式不太一样，我分别说一下我试过的流程。

Claude Code的安装，官方推荐的方式是通过npm全局安装。在终端里执行：

npm install -g @anthropic-ai/claude-code

装完之后，在项目目录下运行claude命令就能启动。第一次启动会引导你登录账号。如果你在Ubuntu上遇到权限问题，大概率是因为npm的全局目录没有写权限，可以用npm config set prefix改到一个用户目录下，或者直接用nvm管理Node版本，nvm装的Node默认就有全局写权限。

Codex CLI的安装稍微麻烦一点，因为它对Node版本有要求。我实测下来，Node 18和Node 20都能跑，但Node 16会报错。安装命令是：

npm install -g @openai/codex

如果你在国内网络环境下觉得npm安装很慢，可以换一个npm镜像源，比如npm config set registry https://registry.npmmirror.com。这个操作只影响npm的包下载，不涉及其他任何东西，纯粹是加速用的。

装完之后，在项目目录下运行codex就能启动。Codex CLI的配置文件和Claude Code不太一样，它默认会读当前目录下的.codex目录。你可以在里面放技能文件，也可以放模型配置。如果你想让Codex CLI调用本地的LM Studio模型，可以在.codex/config.json里指定baseURL为http://localhost:1234/v1，然后把模型名称填成LM Studio里加载的模型名。这个配置方式对Claude Code也类似，Claude Code支持通过环境变量ANTHROPIC_BASE_URL来切换API端点。

注意：如果你在VS Code里用Claude Code插件，插件的配置和终端里的配置是分开的。插件有独立的设置面板，需要在那里单独指定API端点或模型。我一开始只在终端里配好了，结果在VS Code里用插件时发现它还在用默认配置，排查了半天才发现是两套配置。

4.2 技能目录的初始化与文件组织

环境跑通之后，就可以开始搭技能目录了。superpowers的约定是在项目根目录下创建一个.skills目录（有些版本用的是.superpowers，具体看你的框架版本）。目录结构大概是这样的：

.skills/ test-driven-development/ SKILL.md code-review/ SKILL.md performance-profiling/ SKILL.md ...

每个技能一个子目录，子目录里放一个SKILL.md文件。这个文件就是技能的定义。AI在启动时会扫描.skills目录，把所有SKILL.md加载进上下文。如果你的技能比较多，可以在.skills目录下再分一层，比如按“开发流程”“代码质量”“部署运维”分类，但AI扫描的时候是递归的，所以分类只影响你自己的管理，不影响加载。

我建议在项目根目录再放一个.skills/config.json，用来配置全局的加载策略。比如：

{ "autoLoad": true, "maxSkills": 10, "priorityOrder": ["test-driven-development", "code-review", "performance-profiling"] }

autoLoad控制是否自动加载技能，maxSkills限制同时加载的技能数量（防止上下文爆炸），priorityOrder定义当技能冲突时的优先级顺序。这个配置文件不是必须的，但有了它，团队协作时行为会更一致。

4.3 编写第一个技能：以“测试驱动开发”为例

我拿“测试驱动开发”这个技能来演示怎么写。这个技能的目标是让AI在实现新功能时，遵循“先写测试，再写实现”的流程。文件内容大概是这样：

# 技能名称：test-driven-development ## 触发条件 - 用户要求实现一个新功能 - 用户要求修改现有功能的行为 - 不适用于：纯重构（不改变行为）、文档更新、配置修改 ## 执行步骤 1. 理解需求：用自己的话复述一遍用户的需求，确认没有歧义 2. 写测试：在对应的测试文件中添加一个测试用例，该用例在当前代码下应该失败 3. 运行测试：执行测试命令，确认新测试失败，且失败原因是功能未实现 4. 写实现：编写最小量的代码让测试通过 5. 再次运行测试：确认新测试通过，且没有破坏其他测试 6. 重构：在测试保护下，优化代码结构，每次重构后重新运行测试 ## 验证标准 - 新测试从失败变为通过 - 全量测试套件通过 - 没有跳过或注释掉任何测试 ## 注意事项 - 如果用户明确要求“先快速实现，测试后补”，则跳过此技能 - 如果项目没有测试框架，先建议用户搭建，不要强行写测试 - 测试用例要覆盖正常路径和至少一个边界情况

这个技能写完之后，放到.skills/test-driven-development/SKILL.md，重启Claude Code或Codex CLI，它就会在合适的场景下自动加载。我实测下来，AI在加载这个技能后，确实会先写测试再写实现，而且会在每一步之后运行测试。不过有一个细节需要注意：测试命令要写对。如果你的项目用的是npm test，但AI执行的是yarn test，就会报错。所以最好在技能文件里明确写出测试命令，或者在项目根目录放一个Makefile，让AI统一用make test。

4.4 技能加载与执行的现场记录

我拿一个实际任务来演示技能加载和执行的过程。任务是在一个Node.js项目里添加一个“计算两个日期之间工作日天数”的函数。启动Claude Code后，我输入需求。AI首先扫描.skills目录，发现test-driven-development技能的触发条件匹配（“实现一个新功能”），于是加载该技能。

然后它开始执行步骤1：复述需求。“你需要一个函数，接收两个日期，返回它们之间的工作日天数，排除周末。”我确认后，它进入步骤2：在test/date-utils.test.js里添加了一个测试用例：

test('计算两个日期之间的工作日天数', () => { const start = new Date('2024-01-01'); // 周一 const end = new Date('2024-01-07'); // 周日 expect(countWorkdays(start, end)).toBe(5); });

步骤3：运行npm test，测试失败，报错countWorkdays is not defined。步骤4：在src/date-utils.js里实现countWorkdays函数。步骤5：再次运行测试，通过。步骤6：它看了一下实现，觉得循环里可以提前计算总天数而不是逐天遍历，于是重构了一版，再次运行测试，仍然通过。

整个过程里，我只在步骤1之后确认了一次需求，其余步骤都是AI自动执行的。这个体验比我之前纯对话的方式要顺畅很多，因为我不需要反复提醒它“记得写测试”“记得跑测试”。

5. 常见问题与排查技巧实录

5.1 技能不生效的几种典型原因

技能不生效是最常见的问题。我踩过的坑大概有这么几类：

第一类是路径问题。.skills目录必须放在项目根目录下，也就是你运行claude或codex命令的那个目录。如果你在子目录里启动AI，它可能找不到技能目录。解决办法是在项目根目录启动，或者在配置里指定技能目录的绝对路径。

第二类是文件格式问题。SKILL.md必须是有明确章节结构的Markdown。如果章节标题写得不规范，比如用了## 触发条件而不是## 触发条件（看起来一样，但可能有多余空格或不可见字符），AI解析时可能会漏掉。我建议用纯文本编辑器写技能文件，避免富文本编辑器引入的隐藏格式。

第三类是触发条件太窄。比如你写“当用户要求添加新函数时”，但用户说的是“帮我加个方法”，AI可能就匹配不上。解决办法是在触发条件里多写几个同义词，或者用更宽泛的描述。

第四类是技能数量超限。如果你有几十个技能，AI的上下文窗口可能装不下，它会按优先级加载一部分，剩下的就忽略了。这时候要么精简技能，要么在配置里调大maxSkills，但调大之后要注意上下文长度是否够用。

5.2 技能冲突与优先级混乱的排查

技能冲突的表现是AI的行为前后矛盾。比如它先说要跑全量测试，跑了一半又说要跳过测试直接部署。这种情况通常是两个互斥的技能同时被加载了。

排查方法是看AI的加载日志。Claude Code和Codex CLI都会在启动时打印加载了哪些技能。如果看到两个互斥的技能同时出现，就去检查它们的互斥标记是不是写对了。互斥标记的写法是在技能文件里加一行：

## 互斥技能 - full-test-suite

这样当full-test-suite也被触发时，AI会根据优先级选择其中一个。如果优先级没定义，默认按字母顺序，这通常不是你想要的，所以最好显式定义优先级。

还有一个隐蔽的冲突是步骤顺序冲突。比如技能A说“先写文档再写代码”，技能B说“先写代码再写文档”。这两个技能不互斥，但同时加载时AI会不知道听谁的。解决办法是把这类技能合并成一个，或者定义一个“元技能”来协调它们的顺序。

5.3 性能与上下文占用的优化建议

技能框架的一个副作用是上下文占用增加。每个技能文件少则几百字，多则上千字，加载十几个技能就会吃掉不少上下文窗口。上下文窗口被占满后，AI的响应质量会下降，甚至开始遗忘之前的对话。

我的优化建议是：按需加载，而不是全量加载。superpowers支持在技能文件里写autoLoad: false，这样技能不会自动加载，只在手动调用时加载。我把一些不常用的技能都设成了手动加载，比如“数据库迁移”“性能剖析”“安全审计”。常用的技能，比如“测试驱动开发”“代码审查”，才设成自动加载。

另一个优化是精简技能文件。执行步骤不要写得太啰嗦，能用一句话说清楚的就不要用三句。注意事项只写真正重要的，不要把所有的边界情况都列上去。我一开始写技能文件时恨不得把所有经验都塞进去，结果一个技能文件两千多字，加载五个就满了。后来精简到每个技能三五百字，效果好很多。

还有一个技巧是用引用代替内联。如果多个技能共享一些公共步骤，可以把公共步骤抽成一个单独的“基础技能”，其他技能通过引用来使用。比如“运行测试”这个步骤在很多技能里都有，我就把它抽成了一个run-tests技能，其他技能里写“执行run-tests技能”。这样既减少了重复，又方便统一修改。

5.4 常见问题速查表

6. 技能框架的扩展玩法与团队协作实践

6.1 把团队规范沉淀成技能库

一个人用技能框架，收益是线性的；一个团队用，收益是指数级的。因为团队里每个人的开发习惯不一样，A喜欢先写测试，B喜欢先写实现，C喜欢边写边测。如果没有统一的约束，AI在帮不同人干活时，行为也是飘忽的。把团队规范写成技能文件，相当于给AI装了一套“团队操作系统”。

我们团队的做法是：在项目仓库里维护一个.skills目录，所有技能文件都提交到Git。新成员拉下代码后，AI的行为和老成员完全一致。技能文件的修改走正常的代码审查流程，谁想加一个新技能，或者改一个现有技能，都要提PR，由团队讨论后合并。这样技能库就成了团队知识的活文档，而不是某个人脑子里的隐性经验。

我们还给技能文件加了版本号。每个SKILL.md开头写一个version字段，比如version: 1.2。当技能有重大修改时，版本号递增。AI在加载技能时会记录版本号，这样如果某个任务的结果不符合预期，我们可以回溯到当时用的是哪个版本的技能。

6.2 技能与CI/CD流水线的结合

技能框架不仅能约束AI在本地开发时的行为，还能和CI/CD流水线结合。比如我们有一个“提交前检查”技能，里面定义了提交代码前必须执行的步骤：运行lint、运行单元测试、检查提交信息格式。这个技能在本地由AI执行，在CI流水线里则由脚本执行。两边用的是同一套逻辑，只是执行者不同。

具体做法是：把技能文件里的执行步骤抽成独立的脚本，比如scripts/pre-commit.sh，然后在技能文件里写“执行scripts/pre-commit.sh”。这样AI在本地调用的是这个脚本，CI流水线里也调用这个脚本。技能文件本身不包含具体命令，只包含对脚本的引用。这样做的好处是，修改检查逻辑时只需要改脚本，不需要改技能文件，两边自动保持一致。

我们还试过让AI在CI失败时自动分析日志。做法是写一个“CI失败分析”技能，触发条件是“当CI流水线失败时”，执行步骤是“拉取失败日志，定位失败步骤，分析可能原因，给出修复建议”。这个技能在本地由开发者手动触发，在CI环境里则由一个机器人账号触发，把分析结果发到团队频道。实测下来，对于一些常见的失败（比如依赖版本冲突、环境变量缺失），AI的分析准确率还不错，能省掉不少排查时间。

6.3 技能库的维护与迭代节奏

技能库不是写完就完了，它需要持续维护。我们的节奏是：每两周做一次技能库回顾，看看哪些技能被频繁触发、哪些从来没被触发过、哪些触发后AI的执行效果不好。频繁触发的技能，考虑优化步骤或增加边界处理；从来没被触发的技能，要么是触发条件写得太窄，要么是这个技能本身就不需要，可以考虑删除；执行效果不好的技能，就去看AI在哪一步卡住，针对性地改进步骤描述。

还有一个实践是给技能加“使用统计”。我们在技能文件里加了一个usageCount字段，每次AI加载这个技能时，会在一个本地日志里记一笔。两周下来，哪些技能是高频的、哪些是低频的，一目了然。这个统计不需要很精确，粗略的计数就足够指导决策了。

提示：技能库的迭代不要过于频繁。我一开始每周都改，结果AI的行为一直在变，反而不好调试。后来改成两周一次，每次改完之后观察几天，确认稳定了再进入下一个迭代周期。技能库的稳定性比“最新最好”更重要。

7. 一些踩过的坑和最后的经验分享

技能框架这东西，刚上手的时候容易贪多。我一开始写了二十多个技能，恨不得把所有的开发规范都塞进去。结果AI启动时要加载一大堆技能，上下文被占得满满的，响应变慢不说，还经常在几个技能之间反复横跳。后来砍到八个核心技能，只保留最常用的流程，效果反而好了很多。所以我的第一条经验是：技能不在多，在精。先把最核心的三五个流程固化下来，跑顺了再考虑扩展。

第二条经验是关于触发条件的。我早期写的触发条件太依赖关键词匹配，比如“当用户提到‘测试’时”。但用户不一定说“测试”，可能说“验证一下”“跑一下检查”。后来我改成基于操作类型来触发，比如“当AI准备修改.js文件时”，这样就不依赖用户的具体措辞了。操作类型的触发条件更稳定，也更符合技能框架“按场景加载”的设计初衷。

第三条经验是关于技能文件的写法。我踩过最大的坑是把技能文件写成了“教程”，里面塞了很多解释性的文字。AI不需要教程，它需要的是可执行的指令。后来我把技能文件里的解释性内容全部删掉，只保留触发条件、执行步骤、验证标准、注意事项这四个部分，每个部分都用最简洁的语言描述。改完之后，AI的执行准确率明显提升。

最后分享一个小技巧：给技能加一个“回滚”步骤。很多技能在执行过程中会修改代码或配置，如果执行到一半发现不对，没有回滚机制就会留下烂摊子。我在每个会修改文件的技能最后都加了一步“如果验证标准未达成，使用git checkout恢复修改前的状态”。这个步骤看起来简单，但能避免很多手动清理的麻烦。尤其是当AI在半夜自动跑任务时，有了回滚机制，第二天早上看到的就是干净的工作区，而不是一堆需要手动处理的冲突。