Confidence check

实施前置信度检查

在动手写代码前花 100-200 tokens 做检查，可避免走错方向浪费 5,000-50,000 tokens。

---

自动触发规则

触发检查的场景

识别到以下复杂任务时 自动触发：

任务类型	触发关键词
新功能开发	实现、开发、添加、创建功能、implement、add feature
Bug 修复	修复、解决、fix、bug、错误、问题
代码重构	重构、优化、refactor、改进
架构变更	架构、设计、迁移、migrate

跳过检查的场景

以下情况 不触发检查：

• 单行修改、变量重命名
• 纯文档变更（README、注释）
• 代码阅读/解释请求
• 代码审查类请求（「看看有没有问题」「review 一下」「检查代码质量」「有没有 bug」）——注意区分：有具体报错信息或复现步骤的才是 Bug 修复，纯粹让你「看看」的是代码阅读请求。跳过时回复：「我会直接阅读代码。如果有具体报错信息或复现步骤，告诉我可以触发 Bug 修复检查。」
• 用户明确说"跳过检查"（需先提醒风险）

---

检查流程

步骤 0：确认任务对象存在

在识别任务类型之前，先确认请求中是否包含具体的操作对象（文件名、函数名、模块名、组件名、错误信息等）。

如果请求没有指定任何具体对象（例如「优化一下」「改改这个」「让它更快」），停止，不得开始检查，直接回复：

请告诉我你想操作的具体文件或功能，我才能进行有针对性的检查。例如：「优化 UserService.ts 中的 getUserList 方法」。

等待用户补充信息后，再从步骤 1 开始。

步骤 1：识别任务类型

分析用户请求，判断属于以下哪种类型：

• 新功能开发
• Bug 修复
• 代码重构

步骤 2：执行对应检查项

根据任务类型，执行对应的检查项。每项检查需要 实际执行（使用工具搜索）+ 上下文分析。

新功能开发检查项

检查项	权重	执行方式
重复实现检查	40%	使用 grep/glob 搜索代码库，查找是否已有类似实现
架构合规检查	30%	检查 CLAUDE.md/AGENTS.md、审查现有代码模式
官方文档验证	30%	搜索官方文档，确认 API 用法和最佳实践

Bug 修复检查项

检查项	权重	执行方式
根因分析	40%	审查错误日志、堆栈跟踪，定位问题根源
官方文档验证	30%	搜索相关 API/库的文档和已知问题
OSS 参考方案	30%	搜索 GitHub Issues、Stack Overflow 查找解决方案

代码重构检查项

检查项	权重	执行方式
架构合规检查	50%	确认重构方向符合项目架构规范
重复实现检查	30%	确认没有重复造轮子
OSS 最佳实践	20%	参考开源项目的类似实现

步骤 3：计算综合评分

每项检查评分为 0-100%，根据权重计算综合得分。

步骤 4：做出决策

综合评分	决策	行为
≥80%	✅ 继续实施	直接开始编码
70-79%	⚠️ 需要澄清	提出问题，等待用户确认
<70%	❌ 暂停	说明风险，请求补充信息

---

输出格式

检查完成后，输出以下格式的报告：

📋 实施前置信度检查

任务类型：[新功能 / Bug修复 / 重构]

检查结果：
   [✅/❌] 重复实现检查 - [具体发现说明]
   [✅/❌] 架构合规检查 - [具体发现说明]
   [✅/❌] 官方文档验证 - [具体发现说明]
   [✅/❌] OSS 参考方案 - [具体发现说明]
   [✅/❌] 根因分析 - [具体发现说明]（仅 Bug 修复）

综合评分：XX%
决策：[✅ 继续实施 / ⚠️ 需要澄清 / ❌ 暂停并补充信息]

建议：
- [可操作的具体建议 1]
- [可操作的具体建议 2]

---

跳过检查的处理

如果用户要求跳过检查（如"跳过检查"、"直接开始"、"不用检查"），先输出以下风险提醒：

⚠️ 跳过前置检查可能带来的风险：

• 40% 的"简单"任务存在重复实现
• 30% 的返工由架构假设错误导致
• 5 分钟检查可节省 3 小时调试时间

你已经完成了哪些检查？确认继续吗？

等待用户确认后，再开始实施。

---

常见风险信号

用户想法	实际风险
"这个太简单了，不用检查"	40% 的"简单"任务会写出重复代码
"我已经知道架构了"	30% 的返工由错误假设导致
"官方文档太耗时间"	5 分钟阅读可节省 3 小时调试