热点模块反复修改
频繁修改的模块应先通过近期提交和反复返工记录调查，而不是直接重写。识别热点背后的具体维护成本，再根据历史比较改进候选项。提案需要说明准备消除哪种持续负担，以及哪些证据支持现在进行调整。
Improve Codebase Architecture by Matt Pocock
使用 Matt Pocock 的 Improve Codebase Architecture，调查仓库中难以修改或测试的部分。先查看以实际摩擦为依据的模块改进候选与可视化报告，再选定一项深入讨论设计，明确取舍后决定是否实施重构。
选出值得实施的架构改进
指出维护热点、难以测试的边界或分散在多个文件的概念，要求候选方案具有历史和依赖依据。请求先进入设计讨论再选择迁移范围，避免从一个痛点直接扩大为整个仓库的重写。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: Improve Codebase Architecture https://github.com/mattpocock/skills/blob/main/skills/engineering/improve-codebase-architecture/SKILL.md 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 调查订单导入子系统的架构摩擦，尊重已有 ADR，先展示候选，等我选择后再考虑重构。 期望交付: 附代码证据与取舍的候选改进，等你选择后再实施。
关于 Improve Codebase Architecture
Improve Codebase Architecture 是 Matt Pocock 集合中供用户主动调用的架构调查入口。它围绕指定区域或近期频繁修改的热点，查找浅模块、边界泄漏和测试困难，并生成列明文件、前后结构与推荐强度的 HTML 报告。用户选定候选后才进入进一步讨论，流程不会一开始就重新设计所有接口。后续访谈结合 grilling、codebase-design 与 domain-modeling，并参考项目术语表和已有架构决策。它的作用是识别和讨论值得改进的地方，提出建议本身不证明新架构更优，也不等于获得全仓库重写授权。
Improve Codebase Architecture Skill的使用场景
反复返工、测试深入内部和理解概念时跨越大量文件，都可能揭示维护成本。架构改进需要将这些线索对应到真实依赖，再判断哪些边界值得改变，而不是单纯增加抽象。
真实行为难以测试
测试过度依赖私有细节，可能反映接口没有暴露足够有用的行为。将现有测试与它们真正需要验证的公共行为对照，提出更合适的边界或测试入口。先确认架构问题，再决定是否需要大范围调整测试。
理解概念需要跨越多文件
理解一个概念需要反复跨越大量文件时，可能已经产生真实的导航与维护成本。记录实际阅读路径，检查内聚性或分层调整能否减少负担，并将拟议边界与既有依赖比较，避免只是把复杂度移到另一个位置。
检验拟议模块边界是否合理
拆分建议可能减少一个文件的长度，却增加调用方耦合。决定采用前，将候选边界与真实依赖、公共行为和维护历史比较。设计讨论应说明哪里更容易理解、哪些成本只是转移到别处，在新边界有充分理由之前，不提前锁定实施范围。
如何评审架构改进
架构调整应先说明现有维护负担，而不是直接拿新设计替换旧代码。调查具体子系统和历史决定，审阅候选边界，再选一项进入设计讨论，明确迁移与验证范围。
确定调查范围
说明区域或痛点并提供领域资料；未指定时可结合近期变更确定范围。
审阅候选报告
核对涉及文件、摩擦、改进方向和结构比较，区分强建议与推测候选。
深入一项设计
选一项进入决策访谈，重构前明确接口、需保留行为和验证方式。
探索更多 Agent Skills
查看其他 Skill 指南，并在使用前核对原始来源。
Improve Codebase Architecture 常见问题
它会重构所有发现的问题吗？
不会。它先展示候选并询问要深入哪一项，实施是另一个有独立范围和检查的任务。
什么是模块深化机会？
指把实际复杂性放到更简单且有用的接口之后。价值应通过调用方、局部性或可测试性说明，而不是只增加抽象。
需要哪些配套 Skills？
当前原文引用 codebase-design、grilling 和 domain-modeling，应安装集合，使宿主 Agent 能找到这些引用。
报告包含什么？
包含相关文件、架构摩擦、可能改动、收益、可视化比较与推荐强度。原文将独立 HTML 文件保存到系统临时目录。
如何处理已有 ADR？
调查先读取相关决策。与之冲突的建议应指出冲突，并说明哪些实际摩擦值得重新讨论。
流程需要子代理吗？
原始探索流程使用子代理，接口备选也可能使用并行代理。缺少这些能力的宿主不能原样复现全部步骤。