1. 缺乏项目全局认知#

如果只是把需求直接丢给大模型，让它自己拆解和制定开发计划，它往往只能基于需求本身进行推理，很难主动理解项目现有架构、模块边界、设计规范以及历史实现方式。结果就是容易重复造轮子，甚至给出与现有架构冲突的方案。

2. 无法充分复用已有代码#

项目里明明已经有类似功能或公共模块，但大模型未必能发现。开发出来的新代码可能绕开现有能力，导致逻辑重复、维护成本增加。

3. 上下文窗口限制#

开发、排查 Bug、Code Review 时，大模型往往需要临时读取相关代码。随着代码、日志、需求文档不断加入上下文，Token 消耗越来越大，后续可能出现上下文污染、遗忘早期信息、分析结果前后不一致等问题。

4. 代码理解准确性问题#

即使使用代码检索（RAG）方案，大模型读取到的代码片段也可能不完整。缺少调用链、依赖关系、运行时信息时，容易做出错误判断。有时候分析 Bug 的结论看起来很合理，但实际上是建立在错误代码理解之上的。

5. 开发过程缺乏持续记忆#

今天分析了某个模块，明天继续开发时可能又要重新让模型学习一遍。对项目约定、业务规则、架构原则缺少长期记忆和沉淀，导致每次会话都在重复做项目认知工作。

6. Code Review 效果不稳定#

AI 能发现一些明显问题，但对于复杂业务逻辑、架构设计缺陷、历史兼容性问题，效果参差不齐，很依赖它是否恰好获取到了足够的上下文。

🏆 acrx10Zz（粪池蝶泳总冠军）— 高赞回复#

这种开发方式的交互入口是跟 AI 协同讨论的 RFC 文档 和 Plans 执行计划。

• RFC：和 AI 交互意见过程中产生的意见稿和决策意向
• ADR：一些敲定的决策规则会沉淀为架构决策记录
• Plans：具体的实施计划，包含这个迭代需要执行的技术细节和验收清单

这些就是和 AI 沟通中需要反复校对的内容。一旦计划敲定，开 Goal 执行，AI 需要向我提供 Report 报告和相关证据链。

总结： 输入 = 执行计划 Plans，输出 = AI 提供的包含验收清单和证据链的 Report。只对输入和输出的产物负责，中间执行过程由 AI 全权处理。

🏆 noshenxian（神仙）#

如果是在老的框架上改，让它参考，总是多做一些无用的东西出来。但新项目全 AI 开发的，我个人感受来说只能 AI 去改了，人已经改不动了。其实维护是个问题。

做法类似，效果有一些，但还是会不可控，很容易出现偏差。我的原因还是因为懒，后来我就开始死磕详细设计了。

🏆 cheviChan（不二之选）— 逐条心得#

分享下自己的心得，与各位佬一起学习进步：

1. 缺乏项目全局认知 & 无法充分复用已有代码 — 现在的 Agent 已经能很好解决这两个问题了，提示词限制好就行了，或在 claude.md、rules、agent.md 定好规范。注意不要用太差的模型，在 Cursor、Claude Code、Codex 这些 Agent 上，国内御三家也能基本完成任务。

2. 上下文窗口限制 — 还是得先拆分好需求。

3. 代码理解准确性问题 — 和 Agent 与模型有关，试过同样的问题被 Minimax 忽悠过，重要分析还是 GPT 比较稳。

4. 开发过程缺乏持续记忆 — 也在探索中。目前做法：如果某个工作做得很吃力但最终兜兜转完成了，就让它记下来，它会自己总结到项目文件中去。

5. Code Review 效果不稳定 — 设计大方向和重要节点还是人工 Review，其他就跑单测和后面交给测试人员了。

到实际开发过程中，感觉都不用省 Token 了，能完成任务就好。

🏆 coldwater#

推荐使用：

• github.com/mindfold-ai/Trellis
• github.com/coldwateryi/trellis-skills

已经在中小型项目验证过，效果可接受。

🏆 bigleo（楼主）#

主要是现去搜索，费时间又占用大量的上下文，还不一定理解得正确，Token 其实是小事。