- Cloara2026-08-18
如题，目前在筹备庞大的项目，这个项目有很多功能节点，预估至少能拆出8个子项目。我以前试过用trellis进行project的长期管理，但是当这个project超过3个子项且开发到项目中期后就有点失控了。求教各位佬是如何开发管理这些大型项目的呢？
主楼 - Cloara2026-08-18
上一个项目有两套前端，三套后端服务，自认为功能拆分还是较为清楚，有一个较为清楚的任务清单和明确的任务规范。但在开发到中期后明显感到5.6sol开发速度变慢，质量变低，bug增多。尝试重新梳理任务清单效果也不太好。感觉很无力。
- Nekopedia2026-08-18
用什么都不如让它自己规划管理。。
- ifconfog2026-08-18
首先，需要一个靠谱的记忆系统，这套记忆系统也是我从一个百万行代码的项目里，总结和精华出来的，说一不二
github.com
GitHub - grpcer/ownmem: Local, deterministic, git-native memory for coding...
Local, deterministic, git-native memory for coding agents — one set of Markdown files serves Claude Code, Codex, Gemini CLI, Cursor, and Grok CLI.
佬看看适不适用呗，可以顺便帮忙点个赞嘛 ^-^
- Pontus2026-08-18
【开源项目】基于 Codex CLI 为AI底座开发的 SpringBoot3.x+vue3.x+react19.x 的基础框架 - 资源荟萃 - LINUX DO
佬友可以借鉴一下
对于大型项目，主要有如下几点需要注意：
- AGENTS.md规约文档写好
- 服务模块级别的数据流文档和业务文档写好，最终汇聚到整个项目级别
- 某个复杂的业务，可以另外就近写文档
- 引入openspec，这个我认为很有必要，新增需求/比较严重的bug/比较大的需求变更都需要走openspec，小bug就别走了，浪费时间和token
- 需求先沟通->审查，认为没问题后再开始执行
- Cloara2026-08-18
感谢佬的记忆方案，我现在正在做项目龙骨，正好试试。
- Jeffry2026-08-18
与其靠模型自己记得去维护架构不腐化，可以用 spec-code 的链接机制来强制对齐设计+给模型提供精准的 rag，一份质量高的 spec 有奇效。有多神奇？我甚至觉得我可以扔掉 100w 行的代码库来让下一代更强的模型根据 spec 重写成一个更好的软件…
github.com
GitHub - shuxueshuxue/Spexcode: Spec-driven orchestration for your coding...
main
Spec-driven orchestration for your coding agents. Contribute to shuxueshuxue/Spexcode development by creating an account on GitHub.
- Cloara2026-08-18
感谢佬，项目的AGENTS.md有很大的参考价值。我写AGENTS.md有时候很纠结，不敢写多了，也不敢写少了，如何写一个长度适中的AGENTS.md感觉是一个老大难的问题。我也准备OpenSpec + Backlog.md干进来试试。
- Pontus2026-08-18
- Pontus2026-08-18