原文： 面对大型项目且模块多而复杂的情况，有没有好的ai开发方案，如果只给出需求让大模型自己做计划，它可能压根不会参考项目中已有的模块代码，或者开发及查bug、codereview时大模型需要每次现去读取代码，可能存在读取的代码不准确，或读取代码导致上下文越来越大，后续开发更混乱。大家的企业项目开发过程中有没有落地的好流程、方案？
让AI梳理了一下：
对于大型企业项目（代码量大、模块多、业务复杂）的场景，AI开发到底应该如何落地？
目前使用大模型辅助开发时，经常会遇到几个比较明显的问题：
- 缺乏项目全局认知
- 如果只是把需求直接丢给大模型，让它自己拆解和制定开发计划，它往往只能基于需求本身进行推理。
- 很难主动理解项目现有架构、模块边界、设计规范以及历史实现方式。
- 结果就是容易重复造轮子，甚至给出与现有架构冲突的方案。
- 无法充分复用已有代码
- 项目里明明已经有类似功能或公共模块，但大模型未必能发现。
- 开发出来的新代码可能绕开现有能力，导致逻辑重复、维护成本增加。
- 上下文窗口限制
- 开发、排查 Bug、Code Review 时，大模型往往需要临时读取相关代码。
- 随着代码、日志、需求文档不断加入上下文，Token 消耗越来越大。
- 后续可能出现上下文污染、遗忘早期信息、分析结果前后不一致等问题。
- 代码理解准确性问题
- 即使使用代码检索（RAG）方案，大模型读取到的代码片段也可能不完整。
- 缺少调用链、依赖关系、运行时信息时，容易做出错误判断。
- 有时候分析 Bug 的结论看起来很合理，但实际上是建立在错误代码理解之上的。
- 开发过程缺乏持续记忆
- 今天分析了某个模块，明天继续开发时可能又要重新让模型学习一遍。
- 对项目约定、业务规则、架构原则缺少长期记忆和沉淀。
- 导致每次会话都在重复做项目认知工作。
- Code Review 效果不稳定
- AI能发现一些明显问题，但对于复杂业务逻辑、架构设计缺陷、历史兼容性问题，效果参差不齐。
- 很依赖它是否恰好获取到了足够的上下文。
11 个帖子 - 5 位参与者
来源: LinuxDo 最新话题查看原文