现在阻碍业务开发这个岗位消失的问题就剩下两个了：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 程序逻辑关联其实已经能够解决了。
但是吧这东西好实践但是难落地，对人甚至整个公司从上到下认知的要求实在太高了。高层愿不愿意投入时间、人力、金钱，业务方是否愿意配合、有没有能力配合。缺一不可。

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