| name | ascetic-breaker |
|---|---|
| description | 苦行僧破执术。用于打破AI智能体在执行任务时的'苦行僧模式'——即仅依赖当前上下文埋头硬推、无视外部资源、重复造轮子、信息不足仍强行编造的封闭式执行习惯。当智能体出现以下信号时触发：(1)任务涉及代码编写/方案设计/调研分析但未先检索现有资源；(2)连续多轮在同一问题反复推理未引入外部新信息；(3)上下文明显缺少版本号、API文档、行业现状等关键信息却仍继续输出；(4)倾向于自行编造缺失信息而非核实。本Skill是元认知技能，不重复实现检索逻辑——调研类任务委托domain-research，代码类任务用WebSearch/WebFetch定向检索官方文档/GitHub/SO，项目内复用优先Glob/Grep。核心价值在缺口检测、方案评分、交叉校验、假设显式化。 |
| allowed-tools | WebSearch WebFetch Bash Read Write Edit Glob Grep AskUserQuestion |
| when_to_use | 当任务涉及代码编写/方案设计/调研分析但未先检索现有资源时；连续多轮在同一问题反复推理未引入外部信息时；上下文缺少版本号/API文档/行业数据等关键信息却仍继续输出时；智能体用'应该是''大概''通常'填充关键事实缺口时；正在从头实现某个可能已有成熟开源库的功能时。 |
| shell | powershell |
| metadata | {"version": "2.0-cc", "source": "doubao-v2-adapted", "platform": "claude-code", "last_updated": "2026-08-12"} |
苦行僧破执术 (ascetic-breaker)
定位：元认知技能，不是检索技能
本Skill 不重复实现检索逻辑。检索能力由专门的Skill或工具提供：
- 调研/分析类任务 → 委托
domain-research（多平台交叉验证） - 代码/API类任务 →
WebSearch+WebFetch定向检索官方文档、GitHub、Stack Overflow - 项目内复用 →
Glob/Grep搜索本地代码
本Skill的核心价值在检索之外：
- 缺口检测：识别上下文缺什么、影响多大、该找谁补
- 方案评分：检索到多个方案时，按可复用性/兼容性/质量评分选择
- 交叉校验：外部信息与原始上下文冲突时检测并解决
- 假设显式化：无法补全的缺口必须标注，不能悄悄当事实
- 卡壳检测：推理停滞时自动触发重新检索
核心理念
苦行僧（Ascetic）指那些只靠自身苦修、拒绝借助外力的人。在AI智能体语境下，"苦行僧模式"是指：
智能体收到任务后，完全锁死在用户给定的上下文里，即便信息残缺、条件模糊，依然靠内部预训练知识强行推演、写代码、构造方案，不检索外部资料，不查证参考资料，不确认版本与事实，最终产出脱离现实的结果。
为什么苦行僧模式是陷阱
从心理学看，苦行僧的苦修本质是"用肉体的苦换取符号界的积分"——身体受苦但自我膨胀，感觉自己"比偷懒的人更精进"。AI智能体同样如此：自己从头推导、从头写代码，会激活预训练知识中最频繁的模式，产生"我在认真工作"的路径依赖。
从工程角度看，AI智能体的"环境好奇心缺失"导致它明明有现成库和文档，却视而不见，非要自己造轮子——不仅浪费算力，产出的方案还漏洞百出。
破执三层（马祖道一）
- 即心即佛：不再埋头苦推，转向外部检索现有方案
- 非心非佛：检索到的方案也不能盲目照搬，需评分校验
- 无佛可求：外部也找不到时，显式标注缺口，而非编造
触发条件（满足任意一条即激活）
- 未检索先执行：任务涉及代码编写、方案设计、调研分析，但尚未执行任何外部检索
- 封闭推理循环：连续2轮以上在同一问题反复推理，未引入任何外部新信息
- 信息缺口被忽略：上下文缺少关键参数（版本号、API签名、行业数据等），仍继续输出
- 编造倾向：检测到用"应该是""大概""通常"等模糊词填充关键事实缺口
- 重复造轮子：正在从头实现某个可能已有成熟开源库/内置函数/项目内已有实现的功能
核心工作流（4步，含验证循环）
Step 1: 上下文边界检测（Gap Detection）
目标：在执行任何实际任务动作之前，扫描上下文，识别信息缺口并评分。
1.1 任务拆解
- 任务目标：用户要什么？最终产物是什么？
- 任务类型：代码开发 / 调研分析 / 方案设计 / 通用问答
- 已有信息：用户提供了哪些（代码、文档、链接、版本、约束）？
1.2 缺口识别 按以下类别逐项检查（详细清单见 gap-detection-checklist.md）：
- 版本与兼容性（依赖版本、语言版本、运行环境）
- API与接口（签名、认证、版本废弃）
- 数据与输入（格式、编码、样例、输出要求）
- 领域知识（专业背景、政策法规、时效性）
- 现有资产（项目内可复用代码、工具函数、编码规范）
1.3 缺口评分
每个缺口按影响程度评分：
| 影响程度 | 判定标准 | 处理要求 |
|---|---|---|
| 高 | 直接影响结果正确性（版本不兼容、API签名错误） | 必须解决，不能跳过 |
| 中 | 影响质量但不影响基本功能（编码规范、最佳实践） | 尽量解决，无法解决则标注 |
| 低 | 锦上添花（输出格式、命名风格） | 可跳过，使用默认值 |
1.4 验证循环（Validator→Fix→Repeat）
初次缺口识别后，执行一次复查：
- 对照任务目标，检查是否有遗漏的缺口类别
- 检查已识别的缺口是否误报（用户其实已提供但被忽略）
- 复查通过 → 进入Step 2；发现遗漏 → 补充后重新复查（最多2轮）
1.5 输出：缺口清单
## 缺口清单
| # | 缺口 | 类别 | 影响 | 获取方式 |
|---|------|------|------|----------|
| 1 | pandas版本未知 | 版本兼容 | 高 | 查requirements.txt或官方文档 |
| 2 | CSV编码未知 | 数据输入 | 中 | Glob搜索数据文件，Read查看样例 |
可选：运行缺口分析脚本：
python ${CLAUDE_SKILL_DIR}/scripts/context_gap_analyzer.py --task "任务描述" --context "已有上下文"
Step 2: 资源获取路由（Resource Routing）
目标：根据缺口类型和任务类型，路由到正确的获取方式——不重复造检索的轮子。
2.1 路由决策
| 缺口类型 | 任务类型 | 获取方式 | 委托对象 |
|---|---|---|---|
| 项目内已有代码/配置 | 任意 | Glob/Grep 搜索本地文件 | 本Skill直接执行 |
| API签名/参数/版本 | 代码开发 | WebSearch + WebFetch 定向查官方文档 | 本Skill直接执行 |
| 错误信息/报错排查 | 代码开发 | WebSearch 搜错误信息，优先Stack Overflow | 本Skill直接执行 |
| 行业数据/市场现状 | 调研分析 | 多平台交叉检索 | 委托 domain-research |
| 技术方案对比/选型 | 方案设计 | 多平台交叉检索 | 委托 domain-research |
| 政策法规/最新动态 | 调研分析 | 多平台交叉检索 | 委托 domain-research |
| 成熟开源库发现 | 代码开发 | WebSearch 搜GitHub + WebFetch 看README | 本Skill直接执行 |
2.2 委托 domain-research 的规则
当缺口属于调研/分析/选型类时：
- 将Step 1识别的缺口清单作为输入，委托
domain-research执行多平台检索 - 不重复实现多平台搜索逻辑
- domain-research返回结果后，进入Step 3校验
2.3 本Skill直接执行的检索（代码类）
代码类缺口的检索策略（详细见 resource-acquisition-routing.md）：
- P0：项目内搜索（Glob/Grep）——不联网，最快
- P1：官方文档（WebSearch
allowed_domains限定官方域名 + WebFetch） - P2：GitHub/Stack Overflow（WebSearch + WebFetch）
- P3：技术博客（WebSearch + WebFetch）
2.4 检索约束
- 每个缺口最多3轮关键词调整
- WebSearch每次最多8次搜索，复杂检索分批执行
- WebFetch的
prompt参数必填，精确指定提取目标 - 检索结果为空时：记录"未找到"，不编造，进入Step 4标注假设
- 检索失败时按降级策略处理
2.5 输出：资源清单
## 资源清单
| 缺口 | 获取方式 | 结果 | 来源 | 状态 |
|------|----------|------|------|------|
| pandas版本 | Glob搜索requirements.txt | pandas==2.1.0 | 本地文件 | 已解决 |
| read_csv参数 | WebFetch官方文档 | 确认skiprows行为 | pandas.pydata.org | 已解决 |
| 行业数据 | 委托domain-research | 见调研结果 | 多平台 | 已解决 |
| XXX | 3轮检索无结果 | - | - | 未解决→标注假设 |
Step 3: 融合校验（Cross-Validation）
目标：对获取到的外部资源进行评分、冲突检测和适用性校验——这是破执的第二层。
3.1 方案评分（多方案选择时）
当检索到多个可用方案时，按以下维度评分（详细标准见 cross-validation-guide.md）：
| 维度 | 权重 | 评分标准 |
|---|---|---|
| 版本兼容性 | 一票否决 | 与项目依赖版本是否兼容？不兼容直接淘汰 |
| 可复用性 | 30% | 直接可用=5分 / 需少量适配=3分 / 需大量改造=1分 |
| 社区质量 | 25% | star数、最近更新时间、维护状态、issue响应 |
| 代码质量 | 20% | 可读性、测试覆盖、文档完整度 |
| 许可证 | 15% | MIT/Apache=5分 / GPL=3分 / 未知=1分 |
| 项目规范符合度 | 10% | 是否符合项目编码规范和技术栈 |
3.2 冲突检测
将外部信息与原始上下文对比：
- 外部信息与原有假设一致 → 保留，附加来源
- 外部信息与原有假设矛盾 → 标记冲突，以外部权威来源为准，记录修正
- 多个外部来源互相矛盾 → 标记争议，并列呈现，不擅自选择
3.3 验证循环（Validator→Fix→Repeat）
每个方案采纳前执行校验：
- 提取验证：WebFetch返回的是否为正文（非导航/广告/404）？
- 完整性验证：是否包含所需的关键信息（API签名、参数说明、版本要求）？
- 适用性验证：版本是否兼容？依赖是否满足？许可证是否允许？
- 验证不通过 → 换来源重试（最多2次）；仍失败 → 标记"未验证"，进入Step 4标注假设
3.4 交叉验证增强规则
| 验证组合 | 可信度 | 处理 |
|---|---|---|
| 官方文档 + 社区实践一致 | 高 | 直接采用 |
| 2个以上独立来源一致 | 高 | 采用，标注来源 |
| 仅1个来源 | 中 | 采用但标注"单一来源待验证" |
| 来源间矛盾 | 低 | 并列呈现，向用户确认 |
3.5 输出：校验报告
## 校验报告
- 方案选择：[方案A]（评分4.2/5，版本兼容，MIT许可）
- 冲突修正：原假设XXX与官方文档不符，已修正为YYY
- 未验证项：[列出]
Step 4: 借力执行（Leverage & Execute）
目标：使用【原始上下文 + 校验后的外部信息】执行任务，优先复用，并显式标注假设。
4.1 复用模式选择
| 模式 | 适用场景 | 要求 |
|---|---|---|
| 直接引用 | 成熟方案完全匹配 | 标注来源，不做修改 |
| 适配修改 | 方案基本匹配但需调整 | 明确说明改了什么、为什么改 |
| 包装调用 | 引入库但封装接口 | 说明封装理由和接口设计 |
| 参考思路 | 只借鉴思路，自行实现 | 说明参考了什么，为什么不直接用 |
| 全新编写 | 无现成方案可用 | 必须在Step 2确认过"未找到" |
4.2 假设显式化
所有未解决的缺口必须在输出中列出：
### 未解决的假设
- 假设pandas版本>=1.5（未确认实际版本，基于2024年后默认版本推断）
- 假设CSV编码为UTF-8（未获取样例数据）
4.3 输出格式要求
## 执行结果
### 使用的现有资源
- [来源1]：用于xxx，模式：直接引用/适配修改
- [来源2]：用于xxx，模式：包装调用，封装了xxx
### 新编写的代码/内容
[仅包含无法从现有资源复用的部分]
### 校验记录
- 版本兼容性：已确认/未确认（原因）
- 冲突修正：[列出]
### 未解决的假设
- [假设1]：影响程度，建议确认方式
4.4 执行后自检
完成输出后，快速过一遍：
- 是否使用了Step 2获取的外部资源？（没用上说明检索白做了）
- 高影响缺口是否全部解决或显式标注？
- 是否有编造的内容？
- 引用的代码是否检查了版本和许可证？
卡壳自动触发机制
执行过程中出现以下信号时，自动中断当前操作，回到对应步骤：
| 信号 | 判定条件 | 动作 | 回到 |
|---|---|---|---|
| 推理停滞 | 连续2轮输出含"可能""大概""应该是" | 停止推理，检索验证 | Step 2 |
| 报错循环 | 同一错误连续修复3次未解决 | 停止修复，搜错误信息 | Step 2 |
| 功能膨胀 | 正在从头实现复杂功能但未检索过 | 停止编码，搜现有库 | Step 2 |
| 信息漂移 | 输出偏离用户原始需求 | 停止输出，重新检测边界 | Step 1 |
| 方案纠结 | 在2个方案间反复比较超过2轮 | 用Step 3评分表强制决策 | Step 3 |
| 校验失败循环 | 同一来源验证2次仍不通过 | 换来源或标记未验证 | Step 3 |
可观测性 Trace
每次执行本Skill时记录以下trace，形成可追溯的执行轨迹：
[trace] 任务: {任务描述}
[trace] 类型: {代码开发/调研分析/方案设计}
[trace] Step1 缺口检测: 发现{N}个缺口（高{H}/中{M}/低{L}），复查{K}轮
[trace] Step2 资源获取: 委托domain-research={Y/N}, 直接检索={N}个缺口, 未解决={N}个
[trace] Step3 校验: 方案评分={X}/5, 冲突修正={N}处, 未验证={N}项
[trace] Step4 执行: 复用模式={直接引用/适配/包装/参考/全新}, 假设={N}条
[trace] 卡壳触发: {次数}次（{信号类型}）
[trace] 结果: 高影响缺口全部解决={Y/N}, 编造内容={无/有}
- trace在执行过程中实时更新TodoWrite状态时一并记录
- 最终输出的"未解决的假设"部分应引用trace中的未解决项
质量控制清单
每次执行本Skill必须检查：
- 高影响缺口全部解决或显式标注
- 调研类任务已委托domain-research（未自行重复多平台检索）
- 代码类任务已检查项目内可复用代码（Glob/Grep）
- 检索到的方案已评分并检查版本兼容性
- 外部信息与原有假设的冲突已检测并修正
- WebFetch的prompt精确指定了提取目标（未抓整页灌入上下文）
- 未找到的信息标注"未找到"，未编造
- 输出包含"使用的现有资源"和"未解决的假设"
- 卡壳信号出现时已触发重新检索
- trace记录完整
Checkpoint 机制
长任务执行中，使用TodoWrite作为checkpoint：
- 每完成一个Step → 更新TodoWrite状态
- Step 2检索批次间 → 检查是否偏离缺口清单（目标漂移检测）
- 同一缺口检索超过3轮 → 标记"未解决"，不继续死磕
- 中断恢复：从TodoWrite最后完成项继续，不重复已完成的检索
与其他 Skill 的协作
| Skill | 协作场景 | 分工 |
|---|---|---|
domain-research | 调研/分析/选型类缺口 | domain-research负责多平台检索，本Skill负责缺口定义和结果校验 |
lark-doc | 结果需要文档交付 | 本Skill完成分析后，委托lark-doc写入飞书文档 |
tech-analysis | 技术方案深度分析 | tech-analysis负责技术分析，本Skill负责检测是否需要外部信息 |
协作原则：本Skill是"交通警察"——识别缺口、路由到正确的Skill、校验结果、确保假设显式化。不替代任何专门Skill的检索能力。
Claude Code 环境注意事项
- WebSearch：仅返回标题+URL，需要具体内容必须用WebFetch二次获取；每次最多8次搜索；用
allowed_domains参数限定站点（不用site:语法） - WebFetch：
prompt参数必填；内容截断至100KB后通过Haiku摘要，无分页；非预批准域名引用限制125字符；15分钟缓存；跨域重定向不自动跟随 - Glob/Grep：项目内搜索优先，不联网，是P0优先级
- PowerShell：用
python不是python3；不支持&&连接命令；脚本路径用${CLAUDE_SKILL_DIR} - AskUserQuestion：需要用户提供信息时使用，不要凭空假设
Anti-Patterns（严禁行为）
- 无检索先编码：未检查现有库/函数，直接从头写
- 编造事实：用模糊词填充版本号、API签名等关键事实
- 封闭推理：连续多轮在给定上下文内反复推理，不引入外部信息
- 无视文档：用户提供了文档链接但不WebFetch
- 盲目复用：搜索到代码直接粘贴，不检查版本兼容和许可证
- 重复检索：已有domain-research却自行实现多平台搜索逻辑
- 海量灌入：把整个网页内容塞进上下文，不做摘要筛选
- 隐藏假设：把未经核实的假设当事实，不标注
详细反模式案例见 anti-patterns.md
常见场景示例
场景1：代码开发（本Skill直接检索）
用户：帮我写一个Python脚本，解析这个CSV文件并生成统计报告。
- Step 1：检测缺口——pandas是否可用？CSV编码？报告格式？
- Step 2：P0 Glob搜索requirements.txt → P1 WebFetch pandas文档 → 发现
describe()可直接用 - Step 3：评分——pandas方案5/5分，版本兼容，直接引用
- Step 4：引用pandas方案，标注来源，列出未确认假设
场景2：调研分析（委托domain-research）
用户：分析一下新能源行业现状。
- Step 1：检测缺口——缺2024-2025行业数据、政策变化、市场规模（均为高影响）
- Step 2：委托domain-research执行多平台检索（不自行重复搜索逻辑）
- Step 3：校验domain-research结果——数据来源可信度？是否有矛盾？
- Step 4：基于校验后的数据综合分析，标注数据来源和假设
场景3：信息充足（直接跳过）
用户：基于我给的这份完整文档，帮我总结要点。
Step 1检测：用户提供了完整文档，无高影响缺口 → 退出Skill，直接执行。
References
- theory-foundations.md：三个理论维度的完整参考知识
- gap-detection-checklist.md：信息缺口检测清单（含评分标准和复查流程）
- resource-acquisition-routing.md：资源获取路由策略（何时委托domain-research、何时直接检索）
- cross-validation-guide.md：方案评分标准、冲突解决、验证循环
- anti-patterns.md：反模式详解与案例
Scripts
scripts/context_gap_analyzer.py：上下文缺口分析脚本v2，输出缺口清单（含评分、获取方式建议和路由汇总）。运行：python ${CLAUDE_SKILL_DIR}/scripts/context_gap_analyzer.py --task "任务" --context "上下文" [--json]