常见任务实战

实战不是给 CC 一句“帮我做”，而是用 Plan Mode、权限模式、Skills 和验收模板把任务拆成可理解、可执行、可验收的小闭环。

修复前端 Bug

这一页是实战任务入口。每个模板都遵循同一个原则：先计划、再执行、再验收，不让 CC 从一句模糊需求开始自由发挥。

先选任务类型，不要所有问题都套一个模板：

任务	先看哪篇
页面错位、按钮溢出	修复前端 Bug
已会基础流程，想跑完整交付	完整前端 Bug 闭环案例
新增页面	新增一个简单页面
构建失败	排查构建失败
接口返回不对	修改接口逻辑
日志报错看不懂	根据日志排查问题
需要证明不再坏	补测试
改结构但不改行为	安全重构
依赖版本过旧	依赖升级
页面或接口变慢	性能优化
不确定该不该优化	性能优化前评估
多段日志混在一起	复杂报错日志分析
不确定依赖能不能升	依赖升级风险评估

/plan

请帮我修复一个前端 Bug。

现象：
【描述你看到的问题】

复现步骤：
1. 打开【页面路径】
2. 使用【浏览器/设备/宽度】
3. 执行【具体操作】
4. 看到【错误现象】

期望结果：
【修好后应该是什么样】

限制：
1. 先分析原因，不要马上修改。
2. 只修改和这个 Bug 直接相关的文件。
3. 不要重构无关代码。
4. 不要引入新依赖。
5. 修改后请优先用 /verify 或最小检查说明如何验证。

新增一个简单页面

/plan

请新增一个简单页面。

页面目标：
【页面用来做什么】

页面内容：
1. 标题：
2. 主要信息：
3. 需要的入口或导航：

范围限制：
1. 先阅读现有路由和页面结构。
2. 复用现有样式和组件。
3. 不要引入新依赖。
4. 如果需要改导航，请先说明原因。

请先给出计划，计划确认后再修改。

排查构建失败

/debug

构建失败了，请帮我排查。

错误信息：
【粘贴完整错误】

要求：
1. 先判断错误类型，不要立刻修改。
2. 找到最可能相关的文件。
3. 给出最小修复方案。
4. 只修复和这次构建失败直接相关的问题。
5. 修复后请重新执行必要检查并解释结果。

如果发现这是历史问题，请说明，不要顺手大改。

根据日志排查问题

/debug

请根据日志帮我排查问题，但先不要修改文件。

环境：
【本地 / 测试 / 生产 / CI】

复现步骤：
1.
2.
3.

日志：
【完整日志，敏感信息已脱敏】

要求：
1. 先分类问题。
2. 找出关键日志行。
3. 列出最可能原因和备选原因。
4. 只读定位相关文件。
5. 等我确认后再修改。

补 README 或使用说明

请帮我补充 README 或使用说明。

要求：
1. 先只读分析项目结构和已有脚本。
2. 不要编造不存在的命令。
3. 不要写没有依据的部署方式。
4. 输出面向新用户的简洁说明。
5. 修改后请说明哪些内容来自项目文件，哪些需要人工确认。

修改接口逻辑

/plan

请帮我修改一个接口逻辑。

接口：
【接口路径或方法名】

当前行为：
【现在怎么返回】

期望行为：
【希望怎么返回】

限制：
1. 先只读梳理调用链。
2. 不要修改数据库结构。
3. 不要改无关接口。
4. 不要顺手重构整个服务。
5. 给出正常和异常流程的验收方式。

补测试

/plan

请先分析当前项目测试方式，不要直接写测试。

请告诉我：
1. 使用什么测试框架。
2. 测试文件放在哪里。
3. 现有测试风格是什么。
4. 本次改动最应该补哪类测试。
5. 如果没有测试体系，最小验证方式是什么。

安全重构

/plan

请评估这次重构是否必要，不要修改文件。

重构目标：
【写清楚为什么要重构】

要求：
1. 保持外部行为不变。
2. 不新增功能。
3. 拆成小步。
4. 每一步都有验收方式。
5. 如果无法证明行为不变，请建议先不要重构。

依赖升级

/plan

请帮我做一次依赖升级，但先不要修改文件。

目标：
【修复安全漏洞 / 升级低风险依赖 / 升级某个依赖】

要求：
1. 先分析依赖管理器、关键依赖和版本风险。
2. 按低风险到高风险分批制定升级计划。
3. 每批说明影响范围、检查方式和回滚方案。
4. 不要一次性升级全部依赖。
5. 计划确认后只执行第一批。

性能优化

/plan

请帮我分析性能问题，但先不要修改文件。

现象：
【页面慢 / 接口慢 / 交互卡 / 构建慢】

要求：
1. 先定位可能瓶颈。
2. 建议如何记录优化前基线。
3. 给出低风险、小步优化计划。
4. 每一步都要有验证方式。
5. 不要做无法证明效果的大重构。

性能优化前评估

/plan

请先做性能优化前评估，不要修改文件。

要求：
1. 判断是否能确认这是性能问题。
2. 说明还缺哪些证据。
3. 给出最可能瓶颈排序。
4. 建议记录哪些基线指标。
5. 判断是否值得进入实际优化阶段。

复杂报错日志分析

/debug

请分析这组复杂日志，但不要直接给修复方案。

要求：
1. 拆分日志来源。
2. 按时间线整理事件链。
3. 找出第一处真实错误。
4. 区分根因候选、连锁错误和噪音。
5. 设计最小验证动作。

依赖升级风险评估

/plan

请做依赖升级前风险评估，不要修改文件。

要求：
1. 分析版本跨度和是否跨 major。
2. 判断破坏性变更。
3. 说明受影响代码区域。
4. 给出分批升级建议。
5. 给出回滚方案和是否建议现在升级。

提交前检查

请做提交前检查，但不要提交 Git。

要求：
1. 检查当前 Git 状态。
2. 列出本次修改文件。
3. 判断是否有无关文件变化。
4. 检查是否包含密钥或隐私信息。
5. 回顾 /verify 和 /code-review 是否完成。
6. 生成不夸大的提交信息。

实战原则

一个任务只解决一个问题。
陌生任务先用 Plan Mode。
方向明确后再切 acceptEdits 或保持逐步审批。
失败时先收窄，不扩大。
所有结果都要用 /verify、diff 审查或人工验收收尾。

实战任务分级

风险	例子	建议
低	文案、README、小样式	可以小步修改
中	新增页面、普通 Bug、补测试	先 Plan Mode
高	接口、权限、数据库、配置	只读分析和严格验收
极高	生产数据、支付、发布、回滚	必须人工确认

实战推进顺序

先用 /plan 确认范围。
批准最小方案。
修改后让 CC 解释 diff。
用 /verify 验收。
用 /code-review 查风险。
提交前检查 Git 状态和敏感信息。

任务失败时

当前任务没有顺利完成，请先收敛，不要扩大修改。

请输出：
1. 原始目标。
2. 已经完成的内容。
3. 失败在哪里。
4. 当前修改了哪些文件。
5. 最小修复或回退方案。
6. 是否建议重新进入 Plan Mode。

实战收尾模板

请为本次实战任务收尾。

请输出：
1. 原始目标。
2. 实际完成内容。
3. 修改文件。
4. 验收结果。
5. 剩余风险。
6. 是否建议进入提交前检查。

下一篇：修复前端 Bug 完整案例：前端 Bug 闭环