用途：Seam Ripper 用于系统化剖析代码库内部架构，暴露接口、边界和契约中的问题，并给出应当如何修改的建议。资料强调现有模式只是过去决策的证据，不代表正确；组件如何连接比文档宣称更能揭示系统真实结构；向后兼容不是约束，正确架构才是目标；每个抽象、间接层和接口都需证明自身存在的必要。
主要能力：按四个阶段执行。阶段一绘制地形：列出所有模块/包/命名空间，追踪导入/依赖图，编目公开接口（导出的函数、类、类型、常量），查找跨边界共享类型、DTO、schema 等数据契约，定位集成点，并输出依赖图，标注模块间依赖原因、循环依赖、各模块扇入/扇出数。阶段二逐缝审问：检查接口清晰度（能否仅凭公开接口理解模块职责、是否存在 util/helper 导出、是否暴露实现细节）、依赖方向（是否符合概念层级、是否应反转）、耦合评估（接口变更会破坏多少模块、是数据耦合还是行为耦合、能否改为事件/消息）、抽象完整性（是否泄漏实现细节、调用方是否做了模块内该做的事、是否存在多种方式做同一件事）、契约稳定性（历史变更频率、是否有版本化接口或弃用警告、测试是否 mock 该接口）。阶段三识别系统性失败模式：上帝模块、霰弹式修改、特性依恋、不当亲密、中间人、平行层级、投机泛化、死抽象。阶段四提出重构：针对每个显著问题给出指控（具体说明错在哪、为何重要）、正确架构（清晰边界与职责、符合概念层级的依赖方向、暴露意图而非实现的接口）、转型步骤（什么移动到哪里、什么拆分或合并、什么接口改变、出现哪些新抽象）、证据（量化耦合降低，如 N 个导入减为 M 个）。输出采用固定格式：Seam Analysis 标题、依赖图、关键发现（含位置、严重程度、模式、证据、指控、重构、转型）、推荐架构、转型序列。
适用场景：用于架构审查、技术债评估、重构规划，以及判断模块边界和依赖关系是否合理。
限制：资料将其定位为分析技能，不包含安装命令、运行环境或价格信息；其原则明确拒绝“保留坏架构的渐进改进”、接受“能跑就行”、用适配器/门面掩盖问题、仅因广泛使用就保留接口。资料未提供具体平台、版本或性能数据。