怎么优化重构 AI 生成的代码方便后面维护？

不要优化重构， 出了问题 AI 背锅

AI 生成的代码就是一次性的，别维护。这是不知道哪里看到的一个总结。

ai 最操的是欺骗性编程，有时候会忽略一点细节，所以还是需要审查代码

这是 AI 写的代码和你可以做的事

https://i.imgur.com/HUuMBP5.mp4

用架构风格和测试作为围栏，包括功能、性能、★场景测试，保证围栏正确下，反复自我迭代到最优解。AI 写的别看，越看越心累。

感觉没必要也不要去优化，这次大功夫让你改好了架构，下次继续用 AI 写需求，会不会又回去了，变得差不多呢

@baichi 让我加油！

不过你们如果人很多，最好定义一个 AI 提交的规范（测试怎么才算达标），尽量让每次提交都是正向质量代码

@HHA 其实我也是倾向于不看，但是这边之前用 Cursor 习惯了，习惯了自己得看一遍 AI 写的代码大概有什么功能等等，我感觉等以后模型变强了现在做的好多什么优化啊什么规范啊都不是问题。。。。
不过你说的规范指的是比如 claude.md 里面写的规范吗？

@NakanoAzure 那个有一点用，不过你这个场景，将你的思想转化为各类测试用例是核心

阶段性重构嘛，superpowers 出来的代码应该都有测试覆盖了吧，再测试不变的情况下原地重构结构就行了。先和 AI 讨论商量好做哪些架构上的改动，然后让他照着路线迁移就行。
然后不要过于频繁地去动结构。以前说方便维护，一个是要考虑人类去改代码，一个是要考虑测试覆盖率不高所以要减少盲点。现在你既不需要人类去改代码，又不会测试覆盖率不足，动结构几乎只要考虑(1)这样的结构是否更方便 AI 写代码和扩展，(2)这样的结构是否性能更好。

感觉只能定期人工 Review 了，因为就算你写在 AGENTS.md 里它还是写着写着就不遵循了，定期 Review 能在积重难返之前让 Agent 重回正轨。我一般就随机挑一个 feature 进去看它是怎么实现的，某种坏的模式一旦出现就很容易在整个代码库里传播，好消息是这也导致你有更大的概率抓住这种坏的模式（

另外 linter 和 formatter 都开起来，每笔提交之前都跑一遍测试，同样是为了防止积重难返。

现在阻碍业务开发这个岗位消失的问题就剩下两个了：1.大库旧代码更新维护以及程序逻辑关联 2.代码跟业务语义的关联
综合起来就是你要解决的问题，解决掉了绝大部分业务开发就可以转行了。
目前主流的思路有这么几个：
1.知识图谱
解决的是问题一，就是各种关联代码逻辑之间的关联关系。 我实际在生产项目上用过 code-review-graph 、gitnexus 等等 总体看下来效果差别不是特别大，只要不是微服务、大量 rpc 调用的项目准确度基本是可信的。rpc 目前市面的知识图谱试过一遍没有效果好的，如果有我没发现的欢迎指导。 但最大的问题是 ai 在调用关联关系的时候，图谱返回是全的，ai 处理会遗漏。当然这个问题很好解决，就不多赘述了。
2.LLM Wiki
其实期望上是解决代码到业务的关联。但其实本质上就是个文档自动化，不能直接解决代码到业务的关联问题。其他场景下倒是很好用，但是对团队里的人的习惯要求很高。毕竟读的是 diff 和注释+代码本身。维护起来没有想象中的那么方便
3.Business Rule Extraction （业务规则提取）
现在大体上两种思路，一个是确定性分析，但基本都是闭源产品，不知道怎么实现的。比如 Phase Change Software 反正广告吹的是能解决这个两个问题，真实怎么样不知道。 另一个是 ai 辅助识别，让 llm 去读代码，结合提交记录、注释然后生成伪代码+业务逻辑。这个反正我觉得很扯淡。
4.剩下的基本我判定为 ai 吹泡泡，为了吹牛逼而生的
比如软件数字孪生、在代码之上建一层语义抽象层（有点像 mcp ）等等，我觉得都很扯淡，至少目前看不到落地的可能逻辑

哦对了，还有一个思路，个人认为可以落地。但是如果没有 ai 之前落不了地，有 ai 也不行。
那就是 ddd
ddd 本身就是代码和业务之间的语义桥，提供了天然的模块边界。ai 可以非常方便的做各个聚合根对应什么业务概念。做代码跟语义的关联就会非常轻松。因为问题 1 程序逻辑关联其实已经能够解决了。
但是吧这东西好实践但是难落地，对人甚至整个公司从上到下认知的要求实在太高了。高层愿不愿意投入时间、人力、金钱，业务方是否愿意配合、有没有能力配合。缺一不可。


以上都是个人探索下来的拙见，欢迎交流

AI 生成的当然是 AI 维护了🤣