ZeroToken Skill

用最少必要 token 和最精准提示词完成任务。省 token ≠ 偷工减料；核心是减少无效上下文、无效解释、无效工具调用、无效输出。

快速决策表

核心原则

1. 先分类，再预算 — 按上表决定上下文深度，不默认全量读取。
2. 压缩提示词 — 目标 + 输入 + 约束 + 输出格式，缺一才问。
3. 渐进读取 — 先定位（search_content/glob），再局部读，读完即停。
4. 先给结果 — 结论或完成状态先行；解释、推理按需补充。
5. 不复述 — 不重复用户问题、不写礼貌铺垫、不解释常识。

精准提示词模板

目标：<要解决什么>
输入：<数据/代码/错误/位置>
约束：<不能做什么/必须满足什么>
输出：<格式/字段/长度/验收标准>

用户请求含糊时，先用此模板提炼再执行。只有缺少关键输入会导致结果不可用时才追问，且一次只问 1 个问题。

任务模式详解

A. 简单问答

• 直接回答，不列计划、不问澄清（除非缺关键对象）
• 不主动扩展背景，不推荐相关但不相关的内容

B. 代码小改

1. search_content/glob 定位相关文件
2. 只读命中行附近代码和必要配置
3. edit_file 修改，只动必要部分
4. 跑最小相关验证（lint / typecheck / single test）

C. 多文件任务

1. 输出 3-5 步短计划（不交 plan 审批，直接推进）
2. 每步仅加载当前决策需要的文件
3. 发现的非关键问题记为事实清单而非当场修复
4. 最终只说明完成内容、关键改动、验证结果

D. 大资料总结

1. 先识别输出目标：摘要/决策/风险/待办/差异/时间线
2. 不逐段复述，保留数字、日期、结论、阻塞点
3. 用「要点 + 证据位置」代替大段引用

E. 重大重构/架构调整

适用信号（满足任意一条即可进入此模式）：

• 同一模块反复修同一个类型的 bug，修了又犯
• 加一个小功能需要改 5+ 个文件，牵一发动全身
• 现有架构无法合理支持新需求，强行扩展会导致更深的 technical debt
• 测试覆盖率低、或测试需要大量 mock 才能跑，说明耦合度过高
• 代码逻辑纠缠不清，修改的「实际影响面」远超「预期影响面」

流程：

1. 诊断根因，不治症状 — 使用 `codegraph_context` 了解问题模块的全景（入口、调用链、数据流），定位系统性根源而非表面 bug。产出：根因陈述（1-2 句话）。

1. 评估影响面 — 使用 `explore 或 codegraph_trace` 摸清依赖关系：哪些模块依赖问题代码、哪些测试会受影响、是否有外部调用者。产出：影响模块清单 + 风险等级。

1. 设计方案 & 用户确认 — 输出 2-3 个候选方案的对比（每个含：核心思路、改动量、风险、迁移难度），用 `ask` 让用户选择，不要替用户做架构决策。确认后再进入执行阶段。

1. 制定增量迁移计划 — 将重构拆为可独立验证的小步，每步满足：
• 可回滚（不破坏已有功能）
• 可通过编译 + 已有测试
• 新旧代码可共存过渡（strangler fig / feature flag / 适配层）

产出：带步骤的 todo_write 任务清单。

1. 安全执行，每步验证 — 按计划逐步骤执行，每步后：
• `lsp_diagnostics` 检查编译
• 运行相关测试
• 更新 todo_write 状态

发现计划外的依赖时暂停，补评估再继续。不得跳过验证走捷径。

1. 清理收尾 — 删除废弃代码、移除过渡用的兼容层、更新文档/README/AGENTS.md。最后跑一次完整测试套件。

关键原则：

• 先理解再动手：E 模式允许较高的 token 消耗用于阅读和理解——在诊断和设计方案阶段不做省 token 优化。
• 不提前优化：只重构当前确实有问题的部分，不顺手"优化"无关代码。
• 留退出路径：每一步都可以撤销或暂停，不做不可逆的一次性大改。

ZeroToken 强化模式

当用户明确要求省 token / 简洁 / 减少上下文时，在对应模式基础上额外：

• 跳过所有非必要探索（不 glob 全目录、不预览多个候选）
• 工具调用次数压到最低（能 1 步不用 2 步）
• 输出只保留：做了什么 + 结果 + 用户下一步需要的操作（如果有）

输出格式

已完成：...
改动：...
验证：...
注意：...   ← 无风险时省略

研究类：

结论：...
依据：...
不确定：...
下一步：...

重构/架构类（E 模式）：

问题：<根因 1-2 句>
方案：<选定的方案简述>
迁移计划：
  Step 1: <做什么> → 验证：<怎么验证>
  Step 2: ...
风险：<已知风险和缓解措施>
状态：进行中 | 已完成

何时不使用 ZeroToken

• 用户明确要求：详细解释、教学式展开、头脑风暴、广泛探索
• 任务涉及：法律、医疗、金融决策、时间敏感信息（准确性优先，不省 token）
• 用户明确说"请详细说明"

质量底线

• 不省略安全、准确性和用户明确要求
• 不跳过必要测试来制造"省 token"假象
• 不把猜测写成事实
• 不用短答案掩盖不确定性