10 年老项目怎么搞 vibe coding？

[OrdinaryMan]

公司正在推团队 AI 编程，之前自己搞搞小项目从 0 到 1 用 opencode+openspec 挺好用的，但是对于公司的包含几十个微服务的老项目(单个微服务难以理解整个项目的复杂调用链路和跨微服务的业务)，再加上需要团队协作，这种场景下的 vibe coding 怎么搞？ v2 里大佬多，想听听各位的想法

我简单说说我的思路：

1. 对于单个微服务编程，内部使用 opencode+openspec ，迭代自己的新需求和 spec
2. 对于整个项目，基于 llm-wiki 的思路逐步基于服务，业务，规范，index 等角度建立项目级的 wiki 文档，独立整一个 git 仓库保存
3. 项目级的 wiki 需要基于所有微服务代码和人工整理的业务流程文档分模块生成并人工 review,每个微服务 spec 完结后也需要调用自定义 skill 手动收入 wiki 中

思路目前仅停留在想法阶段，还没有实施，想听听各位大佬的意见和实践经验

[mindddd]

我目前也遇到这个，我用 /understand 然后每个修改都 recap 一下，不过就是 token 会变多一点，但是下次上下文检索的时候就快很多并且减少 token 。

[OrdinaryMan]

@mindddd understand 和 recap 都是自定义的 command/skill 吗？

[harlen]

微服务的目标就是把业务逻辑隔离啊。
你的微服务，如果都需要理解其他服务的业务了，
直接把他当单体项目，一个主仓库，多个子仓库来当单体项目跑吧。

[mindddd]

@OrdinaryMan https://github.com/Egonex-AI/Understand-Anything

[Oilybear]

和人一样，你个人要管理多个微服务组成的大型项目的第一件事还是收集必要的信息建立全局链路。我觉得除了 llm-wiki 的部分如果有同事有对业务有一定了解可以参考。
llm -> 带来的是快和不确定
你要做的是减少不确定

[op351]

建 wiki 文档的思路是对的
但是可以考虑在每个子项目内建立对应的 code analysis summary ，而不是整个项目一个 wiki
在子项目内部开发时，确保每一次更新提交都更新对应的 code analysis summary 。
然后子项目开发时如果遇到外部调用的时候，让 agent 自己去读其他子项目的 code analysis summary ，然后他自然会去理解对应的业务逻辑，如果链式调用的话，也是一样的逻辑。
单独建一个 wiki 项目去做项目下所有子项目的文档维护的话，我觉得维护成本有点大。

[xiaomushen]

简单，放一个 workspace 里

[OrdinaryMan]

@harlen 你说的也有道理，但是一些抽离出来的公共业务服务和能力服务，比如订单中心，商品中心，任务中心这种是必要的啊

[OrdinaryMan]

@Oilybear 所以需要 AI 分析代码梳理业务，结合人工 review ，持续完善业务链路文档

[OrdinaryMan]

@op351 如果要让当前项目去读其他项目的 summary ，开发的 workspace 是否应该是整个项目？但是如果考虑在每个子项目内建立对应的 summary 的话，我觉得单个服务一个 workspace 更符合逻辑啊？