pare

删除

优先考虑删除、直接状态、本地所有权、深层模块、原生能力和 YAGNI。拒绝转移复杂性。简化必须保持或提升可读性。

将大量分析、研究和专家工作委派给子 Agent，并返回简明的结论和证据链接，以保持主上下文精简。

将范围限定为所请求的系统／子系统或确切代码变更。使用下方的共享证据和简化标准，并根据范围选择系统清单或变更检查。保持只读：不要运行测试／构建，不要向提供方写入，也不要对候选项作出是否接受的判定。

不要在此只读简化结果中讨论缺陷判定／有状态一致性、实现和技术架构。

证据

明确软件系统／候选项、基线、说明和排除项。只检查区分实质性简化主张所需的当前使用方、实现／配置、历史记录、生成内容／框架的可达性，以及系统原生证据。搜索或工具缺失本身不能证明已删除；工具／指标输出是证据，而非简化判定。

当控制流／状态空间／嵌套／扇出／生命周期／复杂度／测试量实质影响调查时，请阅读复杂度与证明。当反复出现的可维护性／所有权模式具有实质影响时，请阅读可维护性模式。模式和指标只是信号，不是发现。

简化阶梯

对于每个实质性候选项，了解实际流程、使用方和契约。只有在保持所需行为的同时降低总体维护和理解负担时，才选择简化方案。保留当前形式也是有效结果。优先选择此阶梯中最靠前且合理的方案：

1. 删除 — 该机制无需存在，或现有元素没有必要的行为、契约、使用方或所有者。
2. 复用 — 当前实现／系统能力 → 标准库／框架／平台 → 已安装的依赖／工具。
3. 派生 — 消除存储／重复状态，同时保留时序／所有权／成本。
4. 本地化 — 将策略／状态放在真正的所有者／深层模块中。
5. 简化 — 尽量降低实现和调用方的总体语义与认知负担。保持符合惯例、易读的控制流；不要仅为减少行数而压缩代码，或将复杂性转移给调用方。

不要仅因文件／函数较大或分数较高就建议抽取／间接化。只有在考虑导航和调用方负担后，名称和边界确实能让某项连贯操作更易理解时，才抽取辅助函数。并非每个辅助函数都需要复用或独立的生命周期所有权。通用抽象仍需有当前存在的变化点或独立且真实的边界，才能证明其新增机制合理。

可读性约束

减少职责和推理负担，而非格式内容。删除有用的空白或换行、合并语句以及压缩表达式，都不能算作可接受的代码简化结果。不要把格式化器造成的变动或物理行数减少算作简化。

保留有帮助的名称、中间值、解释性注释、守卫子句和明确的生命周期步骤。在控制流、状态转换、错误处理和清理方面，增加行数可以让代码更易理解。对照原有形式和建议形式在这些路径上的表现；即使行为不变且测试通过，只要简化让它们更难理解，就应予以否决。说明哪些知识、状态、策略或间接层消失了，以及为什么剩余代码至少同样易读。

系统清单

当范围是现有系统或子系统时：

盘点互不重叠的源代码、入口点、构建、测试、工具、平台、运行时／配置和生成的子系统。将实现、依赖、配置和支持类构件分类为 retain | delete-safe | blocked。分别进行删除、表征、所有权、算法、重要时的复杂度以及证明审查。

删除安全性不能只看搜索结果是否为空：还要检查调用方、动态／框架／生成代码的可达性、配置／数据、构建、使用方、历史记录、契约和证明责任方。如果没有更全面的所有者，必须保留公共、安全／数据完整性、并发／恢复、适配器／运行时、交互／无障碍契约。

按持久契约价值而非数量／覆盖率审查测试。当有证据表明测试无法独立证伪重要契约、重新计算／镜像生产逻辑、验证的是模拟对象／编排而非行为、保护私有结构、测试项目并不拥有的框架／库行为、重复更强的证明、需要不成比例的脚手架，或仅因构建历史而留存时，可将其视为简化候选项。即使实现很小，如果测试独有地保护了重要且稳定的不变量，也不要建议删除。

按影响／风险／工作量／依赖关系排列重要的简化项，并说明实现切片；不要执行这些操作。即使更清晰的形式需要更多行，也应认可；如果替代方案会增加负担，则保留当前实现。当零散的调用方知识、转发层、重复策略或浅层接缝表明有深化机会时，应指出职责放置不当之处及调用方负担。根据需要使用 architect。

变更检查

当范围是代码变更时：

固定所提供的候选变更；否则，使用精确的当前变更边界。检查内聚性、耦合、复用、YAGNI、术语、无效／重复状态、所有权、深度、证明以及重要的语义复杂度。

还要检查：

• 变更范围偏移：被触及的子系统／文件／契约是否缺少简洁的请求行为或证明理由；
• 通过新增依赖、并行实现、兼容路径、推测性抽象或无关清理而扩大的范围；
• 主要为了便于测试而引入、但没有独立真实生产边界的生产架构；
• 能否通过消除／强化因果状态或责任方来移除的边界情况机制；以及
• 持久测试是否具备稳定接缝、独立判定依据、可证伪性，是否已有更强证明，以及维护负担。

仅将测试通过、覆盖率、代码行数减少或工具评分视为证据。若有证据支持安全移除，可将确实无用或冗余的代码列为清理建议；仅仅存在这些代码并非阻断性问题。根据需要使用 amose 和 architect。

如果某项有意的简化记录了上限／重新审视触发条件，且当前证据支持该简化，则应予以保留。对于没有可观察重新审视触发条件的重要有意限制，应视为可维护性问题，而非另行臆造债务系统的理由。

发现

使用 delete、native、yagni、state、owner、scope、test、shrink、proof 等标签，并报告：

<tag> <cost/consequence>. <proposed form and why it is simpler to maintain>. [location]
Risk: <material risk>
Proof: <evidence / future proof owner>
Confidence: <level>

提出建议前，重新检查身份、可达性、所有权、证明、迁移以及相关工作区状态。说明未来的验证／授权要求，但不要执行测试／构建，也不要进行变更。

返回范围／身份、按优先级排列的简化项或有理有据的保留结论、保留的契约、证明责任方、阻碍因素、实现切片、所需执行授权、未来验证以及剩余风险。