AI 做的 App,真垃圾..

我们用 AI 做 App，第一版往往挺顺。

加个页面，做个统计，聊几句就出来了。可功能多起来后，麻烦也跟着来了：只是想加一个“退款”，首页、分类统计和导出文件里的金额，都得重新检查。

既然AI能做，AI也能找问题。

今天分享一个专门帮大家找这类问题的 Skill：improve-codebase-architecture。我们先看看它这套流程能交出什么。

下面是我用一个小型记账App示例，按项目公开指引完成分析后生成的报告。先看左边现状，再看右边建议，代码为什么难改，比一大段术语直观得多。

这份报告只挑出一个值得优先讨论的问题：金额怎么算，散落在三个入口里。 至于要不要改、具体怎么改，留给下一步决定。

Skill会给项目做什么体检？

这个 Skill 来自 Matt Pocock 的开源集合 mattpocock/skills。

你给它一个现有项目，再告诉它接下来准备做什么。它会读代码，找出哪些结构可能让这次修改变复杂，整理成一份可以在浏览器里打开的 HTML 报告。

报告会列出相关文件、发现的问题、建议方向，以及修改前后的关系图。每个建议还有推荐程度，最后告诉你最值得先看哪一个。

如果没有指定范围，它会先查看近期提交记录，优先关注经常改动的地方。毕竟，一个半年都没人碰的角落，未必值得现在花时间折腾。

你先看报告、选方向，它再和你讨论。扫描阶段不会直接替你重构业务代码。

改一个功能，为什么牵动三个地方？

这次示例很小，没有完整 App 界面，只保留了三个统计入口：

现在三个地方都自己判断一次：这条记录是收入，还是支出？属于哪个月？金额要加到哪里？

原来的功能能工作。可准备加入退款时，你就得想：退款应该抵扣支出，还是算一笔收入？沿用原订单的分类吗？跨月退款怎么算？

这些规则如果分别塞进三个地方，下一次调整时，就得记住三个地方都要改。

这个 Skill 关心的，就是能不能让调用方少知道一点细节：页面继续负责展示，导出继续负责生成文件，金额规则集中处理。

不是文件越少越好，而是同一条规则，别让每个地方都维护一份。

如何快速上手：先告诉 AI，你准备改什么

打开要分析的代码项目，让支持 Skills 的 AI 助手（Agent：Codex、WorkBuddy、豆包工作等）准备这组指引：

项目提供的通用安装入口是：

npx skills"color:#6a9955">#c586c0">@latest add mattpocock/skills

按提示选择使用的 AI 助手和所需 Skill。不同Agent的安装入口以仓库说明为准。

准备好后，真正值得花心思的是任务描述。别只说“优化一下架构”，把你马上要做的事情告诉它：

它的核心流程不要求你另外订阅一个商业设计平台，但阅读代码、分析和生成报告会使用 AI 助手的额度。报告默认放在系统临时目录，想长期保留，记得另存到项目资料中。

这次实际看到了什么？

我先给示例放了两条记录：收入 1000 元，购物支出 200 元。运行后，首页显示结余 800 元，购物分类和导出文件中的支出都是 200 元。

再加入一条 50 元退款，三个入口的支出仍然都是 200 元。

这里要分清：没有出现“首页对了，导出错了”。三个入口目前都还不支持退款。 这条新记录是用来观察新增需求会影响哪里。

按这个例子的约定，退款冲减支出后，净支出应该是 150 元，结余应该是 850 元。现在需要做的是，把这项新规则放到合适的位置。

分析报告定位到 dashboard.py、categories.py 和 export_csv.py 中各自处理金额的代码，建议优先把共同规则集中起来。

这个建议有一个具体好处：以后新增部分退款或调整统计月份时，不必让三个入口各自理解一遍业务规则。测试也可以先围绕共同规则验证，再检查页面和导出是否正确使用结果。

报告也没有建议把整个小项目拆成微服务，或者先搭一套通用框架。对这个示例来说，最值得讨论的就是这一处。

但右边的结构图仍然只是建议，不能看到一张漂亮的“修改后”关系图，就以为重构已经完成。

选中一个建议后，还要问什么？

假如下一步决定沿着这个方向继续，仍然需要说清几件事：

这些问题没有讨论清楚，换成再整齐的目录结构，也可能把错误规则写得很整齐。

选中方案后，这个 Skill 会调用配套的追问流程，逐步明确约束。讨论中形成的新术语可以写入术语表；确实需要长期保留的重要取舍，也可以记录下来。

这次演示停在报告阶段。后面的业务确认、代码重构和修复后测试，并没有执行。

我的看法：先找值得改的地方

直接对 AI 说“把项目重构一下”，范围太大了。很容易改出一堆目录和抽象，最后还是回答不了：这次增加退款，到底轻松了多少？

这个 Skill 比较有用的地方，是把建议落到具体文件和具体改动上，再让你判断投入是否值得。对已经有代码、准备继续加功能的项目，这种报告有实际用处。

但报告里的推荐程度只是 AI 的判断。写着“强烈推荐”，也不代表必须照做。还要看这段代码以后会不会继续改、当前规则是否真的重复，以及调整会影响多少现有功能。

我的建议是：带着下一项需求去分析，每次先挑一个问题。 看懂它为什么值得改，再让 AI 动手，比一次性“全面优化”更容易掌握范围。

素材与演示说明：文中的记账app是为本篇专门构造，使用 Python 标准库实际运行；分析按项目公开指引完成，并据此生成报告及截图。

开源地址

https://github.com/mattpocock/skills

https://github.com/mattpocock/skills/tree/main/skills/engineering/improve-codebase-architecture

https://github.com/mattpocock/skills/blob/main/docs/engineering/improve-codebase-architecture.md