sliced-bread-depth

切片面包深度

将每个切片评为深模块：公开接口小而稳定，隐藏着大量实现。切片即使通过了所有边界检查，外壳本身也可能_就是_实现——一个 900 行的外壳只包着两个简单助手，虽然符合要求，却很浅。完整的原理请参阅 Sliced Bread 参考文档；本技能用于进行衡量。

范围

默认检查仓库中的每个切片。如果用户指定了切片，只衡量这些切片，但仍列出完整清单，以便了解比例的背景。纳入有文档说明的外壳例外情况（例如，作为切片接缝的单例）——对其进行分类，但不要将其本身标记为问题。

步骤 1 — 清点

找出每个切片的外壳——以该语言原生形式呈现的公开接缝：Go 中的导出标识符、Python 中的包 __init__ 接口、TypeScript 中的 index 模块，以及其他语言中的公共类接口。应用接口测试：使用者能否在顶层看到一组精简且一目了然的可用操作，而无需深入内部，也无需面对一个包含上百个符号的入口点？对外壳形态进行分类：

形态	特征
薄门面	重新导出、工厂、目录；自身几乎没有或完全没有逻辑
框架绑定	外壳必须继承框架基类（场景节点、视图、组件）
服务/模拟	外壳拥有热循环或长期运行的进程（step、tick、dispatch）

步骤 2 — 衡量

对每个切片使用代码计算（不要估算）：

• 外壳 LOC 和 切片总 LOC ——关键比率是实现占比：外壳 LOC ÷ 切片总 LOC。
• 内部模块数量和 LOC ——外壳所隐藏的深层实现。
• 公共接口 ——外壳上导出/非下划线函数、方法和事件/信号的大致数量。
• 生命周期组合 ——公共接口是否混合了不相关的生命周期（一次性设置与逐帧/逐请求操作，或 UI 接线）。

第 3 步——评估

当以下两项都成立时，建议拆解表层文件（提取内部实现——绝不增加第二个公共接口）：

• （a） 表层文件包含热路径实现；且
• （b） 深层为空或内容较少（实现占比主要集中在表层），或者公共接口混合了互不相关的生命周期。

校准标准，确保指标公平：

• 占比才是指标，绝对代码行数（LOC）不是。 对于纯工厂叶片切片，一个 250 行的表层文件占其全部内容也很健康；而一个 900 行的表层文件占所在切片 85% 的内容，就值得警惕。
• 框架绑定的表层文件可适当放宽凝聚性要求。 框架回调（生命周期、物理、渲染）必须位于子类中；提取目标应是由表层文件持有的普通辅助对象，而不是第二个公共接口。
• 内部文件多不等于发现问题。 一个包含三十个深层模块的宽泛表层文件存在的是 API 聚类问题——应对接口进行分组和收窄，而非深度问题。不要建议拆分切片。
• 尊重已记录的设计意图。 如果文档字符串或注释声明其接口设计有意如此，应引用相关内容并给出保留意见，而不是判定为问题。
• 双接口（实时单例 + 纯辅助门面）应采取“澄清而非拆分”的处理方式：建议说明各接口的职责，而不是另行设计第二个表层文件。
• 比较同类项。 两个实现相同模式、但深度相反的切片（一个委托其热循环，另一个将其内联）是置信度最高的问题——代码库中已经存在目标形态。

增长防护——评估深度时应排除的误报：

• 仅有一个使用方本身并不能证明抽象过早；应评估是否存在实际压力。两个使用方是常见依据，但不是硬性要求。
• 新概念若一直保留在单个文件中，就是正确的做法；不要标记。
• 为打破跨切片循环依赖而引入的分发器，即使只有一个事件和一个订阅者，也表明存在实际压力。
• 数值阈值只是参考信号，不应作为可判定的违规项；应评估实现占比、公共接口规模以及生命周期混用情况。
• 在唯一的隐私机制是文件位置的语言中，将内容标记为内部实现的子目录，表明这种可见性边界确有实际压力，即使其中只有一个文件。

判定结果

判定结果	含义
extract	两项启发式条件都成立；将内部实现从表层文件中剥离
narrow	存在深度；对公共接口进行分组并缩减
watch	体量增长明显，但仅涉及单一维度；待下一个功能落地后再评估
healthy	深度恰当；无需处理
intent	根据已记录的设计意图保持宽泛；引用依据并给出保留意见

输出

报告分为三个部分，仅供只读——此技能绝不修改代码：

1. 目录——一张表格，包含：切片、形态、表层文件 LOC、内部模块、实现占比、公共接口。
2. 评估——一张表格，列出每个切片的判定结果，按 extract → narrow → watch 排序；每项附上一行理由，并引用 file:line。
3. 投资回报率最高的 3 项提取——具体说明哪些内容应从表层文件移出、移至何处，以及代码库中可供参照的先例（如有）。优先选择已有先例支持的机械式改进，而不是推测性重构。

全部判定为 healthy 也是有效结果；绝不要凭空制造问题。