有没有人让遗留代码库对AI编程助手更易读？
快速总结：你是否曾经优化过一个遗留或使用Vibe编码的代码库，以改善基于AI的开发结果，并避免修复一个bug后又出现两个新bug？我想听听你的经历。
首先，提供一些背景信息。大约7个月前，我成为一家（现在）成立两年的初创公司的首位工程师。这个代码库最初是由我们的低级CTO构建的一个可爱的MVP，一个月前我们又聘请了一名开发人员，并正在进一步扩展我们的工程团队，为我晋升为员工工程师做好准备。
现在，正如你可能预料到的，代码库非常混乱，因为我们只是建立在第一个MVP的基础上，当然没有任何文档。我在我们的代码库中识别出的主要问题有：
- 重复的业务逻辑 → 没有单一的真相来源 / 分离关注点不佳。
- 僵尸表和列 → 积累的架构/结构性债务，大多数看起来是正确的，但实际上并非如此。
- 我们手动跟踪下游影响，因为一切都散落且重复，以最令人困惑的方式呈现 → 隐式依赖、隐式架构和高变更耦合。这里的一个变化也需要在其他地方进行更改（这主要可以通过代码库图索引器来修复）。
现在快速说一下，以免你感到无聊，我已经确定了在速度和可靠性之间的最佳解决方案，即对整个代码库进行适当的文档记录，并将其高效存储为我们的AI代理的“知识数据库”，以便它们至少了解已知的缺口、限制、决策、业务逻辑、需要更改的其他地方以及更改的原因和影响。
与这个确切问题最相关且最有趣的文章是Meta的这篇文章，我想以此作为我方法的起点。
我在这里请求的是一些类似的经验，其他初创公司的工程师是否经历过类似的过程，他们的做法、经验、结果以及任何我应该避免或注意的建议。
任何帮助都将不胜感激。
查看原文
Quick Summary: Did you ever optimize a legacy/vibe-coded codebase to improve AI driven development results and avoid fixing a bug for 2 more to appear? i want to hear what your experience was.<p>First, some context. ~7 months ago i was the first Engineering hire at a ( now ) 2 years old startup. The codebase started as a Lovable MVP built by our low level CTO, one month ago we hired a second dev and we are further expanding our engineering team and preparing the terrain for me to move to Staff.
Now as you probably expected, the codebase is a mess since we simply built on top of the first MVP, of course with zero documentation, the main problems i identified in our codebase:
- Duplicated business logic → no single source of truth / poor separation of concerns.
- Zombie tables and columns → accumulated schema/structural debt, most of them look right, they are not
- We manually track downstream effects since everything is scattered and duplicated in the most confusing way → implicit dependencies, implicit architecture and high change coupling. Changing a thing here also needs changing there and there ( this is mainly fixable by a codebase graph indexer )<p>Now quickly, so you dont get bored, ive identified as the sweet spot solution between speed and reliability to properly document the whole codebase and store that efficiently as a 'knowledge database' for our AI agents, so they are at least aware of the known gaps, constraints, decisions, business logic, where else to change something and the causes and effects of changes.<p>The closest and most interesting article that treats this exact issue is this one from Meta, which i want to start my approach from.<p>Now what im asking here is for some similar experiences, other startup engineers that had to go through a similar approach, what was their approach, experience, outcome and any tips on what should i avoid or be aware of.<p>Any help will be much appreciated