一个项目从 0 到 1 再到生产环境用 cc 来做将会是无数轮对话，n 轮对话后上下文就会膨胀，然后 cc 就会有些失忆和错乱。
求问用 cc 做一个完整项目的正确方式或顺序是什么？ 每次修改用 git 吗？然后在重启 cc ？ 有邪修偏方吗？
跪谢！
7 条回复 • 2026-01-25 23:58:41 +08:00
 |
1
hzlzh PRO 方法很多，我最近在开始在 X 分享一些小技巧。
首先一定要用 Git 阶段性保存，然后要开 Plan 模式，让 AI 产拆分了做，每次做完一个下点就要提交到 Git |
 |
2
zaitaoxiaoairen 1 月 21 日
我目前采用的是 openspec+vscode 的 cc 插件，小改动直接让 cc 改就是了，多的需求就 openspec
1.先讨论需求，产出 openspec 的规范文档，多轮对话，尽可能的清晰描述需求。 2.自己查看相关的文档内容看是否符合预期，条件允许可以让 cc 生成简单的 html 原型图验证是否符合预期 3.让 cc 自己查看输出不明确的和需要再次确认的问题并给出建议 4.生成最终的 openspec 文档 5.新开窗口让 cc 按照 openspec 文档开发，开发完成后自己 review 代码和测试 6.修复测试过程中的问题，条件允许可以让 codex review 代码 7.git 提交这次代码，后续有 bug 或者其他小问题直接新开对话让 cc 改，新需求重复 1-7 |
|
3
zaitaoxiaoairen 1 月 21 日
@zaitaoxiaoairen 多嘴一句，我用 opus2025-4-5-20251101 目前感觉做需求没啥问题
|
 |
5
raw0xff OP @zaitaoxiaoairen 大概明白您意思，是不是每次任务都做好文档，任务完成就 commit 。
|
 |
7
slackerman 1 月 25 日
核心是任务拆分，尽量减数多轮对话。
理解多轮对话的本质，每次对话都是一次独立的推理，多轮对话只是将前述对话上下文以各种形式打包到提示词中进行新的一次推理，所以上下文膨胀造成混乱的本质就是上下文窗口的有限性及注意力机制。 理解了这一点，就该明白，提示词中应该包含尽可能少且必要的信息，那么就应该尽量拆分任务，每次用清晰的信息做一件模型能力范围内的事。 由此应该尽量自己构建最干净必要的提示词进行一次推理而不是依赖多轮对话。因为多轮对话必然引入无效的上下文稀释模型注意力。 至于如何合理的拆分任务依赖与经验与能力就不展开了 |
Select Language