Matt 的 /improve-codebase-architecture skill：先出报告再决定改哪个模块
关注这个 skill 的可以看另外一个他的另外 /improve-codebase-architecture https://t.co/W814Gp1cNv 它在内部调用 /codebase-de...
推荐写代码的朋友试试这个 skill，它不直接改代码，先找出最烂的模块给你选，还自带 deletion test 防过度抽象，隔几天跑一次挺省心。
/improve-codebase-architecture 内部调用 /codebase-design 生成的规范词典，用 module、interface、depth、seam 等术语替代 component、service 这类含糊词。它会找出接口和内部实现一样复杂、藏不住复杂度的 shallow module，输出候选报告后停下让用户选择改哪一个，不直接重构。skill 还带 deletion test：拿掉模块后复杂度是否收进更小的接口，防止过度抽象。作者建议每隔几天跑一次，防止代码结构慢慢腐化。
关注这个 skill 的可以看另外一个他的另外 /improve-codebase-architecture https://t.co/W814Gp1cNv 它在内部调用 /codebase-de...
关注这个 skill 的可以看另外一个他的另外 /improve-codebase-architecture aihero.dev/skills-improve… 它在内部调用 /codebase-design 生成的规范词典，然后找出那些接口几乎和内部实现一样复杂 藏不住复杂度的浅模块（它称之为 shallow module） 出一份候选报告，然后停下来问你改哪一个 它不直接重构 同时它还有 deletion test 拿掉这个模块之后，复杂度是否收进一个更小的接口 防止修改以后过度抽象 他给出的适合场景是 隔几天跑一次 防止结构慢慢烂掉，我也慢慢按照这个建议在实践 我一直觉得 Matt 的 skills是软件工程设计非常好的实践，关注不仅仅是他的 skills，而是他的方法论和思考方式。 Viking @vikingmute matt 的这个 /codebase-design 最近对我帮助很大，尤其是让 AI 重构一些大模块的时候，它其实不修改任何代码，只是一套词典，把 module、interface、depth、seam、adapter、leverage、locality 每个词定义死。禁止用 component、service、API、boundary 这些含糊替代，规定好这套词典以后，边界会很清楚。 还有里面的四个 rules 真的是值得好好思考。 🔗 View Quoted Tweet 💬 1 🔄 2 ❤️ 8 👀 1394 📊 6 ⚡
