原文： 面对大型项目且模块多而复杂的情况，有没有好的ai开发方案，如果只给出需求让大模型自己做计划，它可能压根不会参考项目中已有的模块代码，或者开发及查bug、codereview时大模型需要每次现去读取代码，可能存在读取的代码不准确，或读取代码导致上下文越来越大，后续开发更混乱。大家的企业项目开发过程中有没有落地的好流程、方案？ 让AI梳理了一下： 对于大型企业项目（代码量大、模块多、业务复杂）的场景，AI开发到底应该如何落地？ 目前使用大模型辅助开发时，经常会遇到几个比较明显的问题： 缺乏项目全局认知 如果只是把需求直接丢给大模型，让它自己拆解和制定开发计划，它往往只能基于需求本身进行推理。 很难主动理解项目现有架构、模块边界、设计规范以及历史实现方式。 结果就是容易重复造轮子，甚至给出与现有架构冲突的方案。 无法充分复用已有代码 项目里明明已经有类似功能或公共模块，但大模型未必能发现。 开发出来的新代码可能绕开现有能力，导致逻辑重复、维护成本增加。 上下文窗口限制 开发、排查 Bug、Code Review 时，大模型往往需要临时读取相关代码。 随着代码、日志、需求文档不断加入上下文，Token 消耗越来越大。 后续可能出现上下文污染、遗忘早期信息、分析结果前后不一致等问题。 代码理解准确性问题 即使使用代码检索（RAG）方案，大模型读取到的代码片段也可能不完整。 缺少调用链、依赖关系、运行时信息时，容易做出错误判断。 有时候分析 Bug 的结论看起来很合理，但实际上是建立在错误代码理解之上的。 开发过程缺乏持续记忆 今天分析了某个模块，明天继续开发时可能又要重新让模型学习一遍。 对项目约定、业务规则、架构原则缺少长期记忆和沉淀。 导致每次会话都在重复做项目认知工作。 Code Review 效果不稳定 AI能发现一些明显问题，但对于复杂业务逻辑、架构设计缺陷、历史兼容性问题，效果参差不齐。 很依赖它是否恰好获取到了足够的上下文。 11 个帖子 - 5 位参与者 阅读完整话题
综合L站、公众号各位佬友 大v的评测，fable是真的很强，生产重构中大型项目完全不在话下了，所以AI再发展几年，程序员的角色会不会只是一个传话筒了，领导说改哪传给ai，客户哪里不满意，传给ai。。 10 个帖子 - 10 位参与者 阅读完整话题
如图，根据用户反馈问题定位 提出的修复方案让 Codex Review 核查后发回 结果显示找问题、定修复方案都差很多 第一次 Codex Review 发现很多问题，Claude 自己定位不精准 Claude 输出修订方案 V3 后，Codex Review 还发现问题，又修订 V4 模型信息： Claude Opus 4.7[1m] in Claude Code Desktop 上下文才 159K 2 个帖子 - 2 位参与者 阅读完整话题
codex中怎么将一个大型项目拆分需求，怎么架构，项目怎么进行？怎么去和codex沟通。codex完整大型项目的可行性，一个搞java的能用ai搞定go微服务吗，人麻了 2 个帖子 - 2 位参与者 阅读完整话题
想问一下各位佬友们，当前大型项目，尤其是全ai开发，怎么保证项目的稳定性，在测试和代码审核这部分怎么保证质量 3 个帖子 - 3 位参与者 阅读完整话题
目前手上维护百万行量级大型项目，日常主要用 Cursor 、Codex 做功能迭代与代码修改。 每次调用 AI 都需要重新读取完整项目代码，不仅效率偏低，还会造成大量 Token 无端消耗。 想请教各位大佬，有没有可行方法让 AI 记住项目整体架构、业务逻辑与现有功能结构，不用每次都全盘扫描完整源码，以此精简 Token 消耗、提升开发效率，望各路前辈不吝赐教！
目前手上维护百万行量级大型项目，日常主要用 Cursor 、Codex 做功能迭代与代码修改。 每次调用 AI 都需要重新读取完整项目代码，不仅效率偏低，还会造成大量 Token 无端消耗。 想请教各位大佬，有没有可行方法让 AI 记住项目整体架构、业务逻辑与现有功能结构，不用每次都全盘扫描完整源码，以此精简 Token 消耗、提升开发效率，望各路前辈不吝赐教！
用AI开发一个中大型项目的时候，还是会遇到上下文大小限制，模型要读取一个项目文件夹里的所有代码文件，有十几个目录，每个目录里也有十几个文件，上下文就不够用了，好像目前也没有太多上下文的模型。感觉AI在面对大项目的时候还是不行，只能搞搞小项目 6 个帖子 - 6 位参与者 阅读完整话题
1M的上下文处理大型项目还是比较爽的 10 个帖子 - 6 位参与者 阅读完整话题
最近读了翁家翌大佬一篇关于AI自己长期维护方法的博客，之前也用过coze(工作流编排)，codex，claude code等工具。 最近想做一个 单人维护的大型项目 （比如自动跑团的AI主持人），想和各位佬们讨论。 我遇到的问题 个人维护大型项目，在ai已经解决了大多数工程问题的情况下，最大的问题就是个人需要同时理解N个模块如何交互、修改后可能影响哪些地方，即“认知负载”。 对于项目本身的更新，个人常常容易陷入局部视角或缺乏相关技术经验，因此如果让项目能依据目前的结果自己更新也许能得到一个更全面的结果。 ai会写出大量屎山，过大的项目如果要求人工介入review难度太大。 目前架构思路 堡垒： 稳定，长期无需维护，提供基础支撑的核心模块，但搭建此类壁垒时需要用codex+superpower（纪律框架，例如TDD）做足够的pytest，之后就几乎不会再修改（或者修改时要人工review和监测之前pytest的输出）。最后这些堡垒会工作流中反复调用，并通过skill之类的封装，只预留少数接口。 通道： 业务流程编排层，用Coze类似的工作流引擎把堡垒模块串起来，节点只是调用之前每个堡垒的暴露的api，而流程逻辑则完全可视化，这样可以保证我只需要知道每个模块有什么用以及模块的少数接口，让“认知负载”降到最低 Heuristic System： 翁家翌大佬提出的核心设想，我的理解就是类比强化学习，有 策略（代码规则/状态机）、反馈（test/log/reward）、记忆（trails/回放）、更新机制（coding agent直接改代码） ，进而实现启发式的项目自我重塑。感觉其实很类似站里许多大佬提出的自动生成skill或memory的项目架构。 项目管理（如何在屎山上继续拉屎）上我基本0经验，所以目前想法就是对于通道上每个节点进行监督，失败或到达某一指标时要求人工介入；同时可能需要通过工作流编排保证一些区别很大的子项目拆分开来，防止一个子项目失效全部都失效。 翁家翌大佬的那篇博客我还在消化，理解可能有偏差。我目前还没想好哪些逻辑要放入堡垒中，哪些通过工作流式的编排实现，以及HL的反馈和记忆存哪些东西比较好（感觉我列的有点太多了）。希望佬们能给点建议。 6 个帖子 - 2 位参与者 阅读完整话题
姑且先不谈商家信誉，仅仅只考虑A社不断大量封号，kyc等行为，从事实的角度，中转对于中大型项目的性价比就很低，毕竟只要一切号，缓存直接重刷，一次半百的缓存创建，谁能负担的起，更不要提一次创建失败，还有更多次，直接几百元打水漂也有可能，所以我个人极不推荐使用Claude中转开发中大型项目，几千几千的教训给佬友们避一下雷 2 个帖子 - 2 位参与者 阅读完整话题
决定使用codex之前，问问各位大佬们! 36 个帖子 - 34 位参与者 阅读完整话题
一直都是找的中转站，咸鱼搞的。但是有个朋友在正真做大型项目都是买三个 gpt 的号轮着用，都还不够。所以我想直接买满血版，想知道要怎么操作，还有什么风险要注意的吗？