我先来
推荐做法
- 引导 AI 出方案你来 review, review 通过了以后，先让 AI 先写测试用例，让测试用例失败，让 AI 自动修复测试用例，你来 review 修复方案和代码。
- 多用 plan 模式，确认没问题了才让 AI 生成代码，不要一把梭不停的让 AI 修改代码 ，改来改去可能越改越奇怪，最好是把计划做好，这样效率和准确率更高。
不推荐
- 你来出方案，让 AI 实现，你来测试，让 AI 修复代码。
第 1 条附言 3 天前
上下文并不是越大越好，有时候做完一个功能了，做另外一个不想干的功能，要及时 /clear , 避免上下文干扰。
24 条回复 2026-01-22 19:50:55 +08:00
 | 1 cheny233 5 天前 先 plan ，沟通好规划后，写文档，然后再让他按照文档来实现。 |
 | 2 Nexora OP @cheny233 嗯，我一直用在这方案，不过有一个麻烦点就是 2 台电脑无法共享工作进度，在公司用公司电脑开发，在家里用家里电脑开发，上下文会丢失，请问大佬有思路吗 |
 | 3 YingJieZ 5 天前  1 @hellojukay OpenSpec ，会将阶段性的 proposal 记录到文档里，变相实现上下文的 git 化保存。并且生成出来的 Specs 从结构和内容上都要比自己写 prompt 让 AI 生成的要好很多。 |
| 4 Nexora OP @YingJieZ 是说这个吗 https://github.com/Fission-AI/OpenSpec ， 这是一种思路，我看 Claude Code 其实是生成了 plan.md 文件，但是我不知道为什么它没有把文件放在 git 仓库里面，也许是有什么考量。 |
| 5 YingJieZ 5 天前 @hellojukay 对的，可以体验一下。在用 OpenSpec 之前我一直都是 docs/xxx.md 这种方式手动管理文档（上下文），后面发现随着项目开发深入，docs 多多少少都存在过时的问题。至于你说的 claude code 生成的 plan.md ，我理解 Anthropic 应该是不认为 plan 是值得长期维护的，所以放到了~/.claude/xxx/xxx 下，等于是一次性的上下文。所以可以对比着来看，OpenSpec 就是解决了 plan.md 没有跟着 project 维护的痛点，通过将 proposal/design/tasks/specs 等文档结构化存到 git 上来实现项目长期开发上下文的持久化。 |
 | 6 rcj6056 5 天前 我甚至都没用过 plan 模式 一直都是 agent ~ plan 模式是啥。。。 |
 | 7 kenshinhu 5 天前 现在发现 Vibe 过程中 “自洽” 很重要。当代码量大了，模型也会自己重新一个已经有方法来调用。必须要 review 生成的代码。 |
 | 8 xuelang 5 天前 这里代码量大的话，你可以不 review 没一行，但是得指导 AI 分模块，分组件，以及在哪可以复用等等。。。 |
 | 9 94 5 天前 前段时间听的一个分享，和 OP 你的方式差不多，但是他描述的会更细节一些。 [第 057 期：我总结了程序员靠 AI 做独立产品的可靠开发流程 - Robust: 程序员的 TALK PLACE]( https://www.xiaoyuzhoufm.com/episode/694ea7b1efa9eb089958c7bb) |
 | 10 brucedone 5 天前 @rcj6056 将你的需求，边界，想法，他所规划的整理成一个 md 文档，然后你确认是不是你想要的，确认后做为执行的依据，完全执行，plan 模式有个好处是通过和你沟通以及他的知识体系一次性汇总，省 token ，拆分大任务，推荐多用 plan |
 | 12 ZZITE 5 天前 大点的项目考虑到后期维护迭代，还是 SDD 好. 可以试试 OpenSpec 或者 spec-kit |
 | 13 livib 5 天前 先出 spec 多轮（多个 LLM ）验证确认一致性之后冻结协作契约再进入实施阶段。 规划（你或者你信任的 agent ）管理三类基本 agents： 契约 / 实现+测试 / 门禁 ，基本上得到符合预期的结果。 |
 | 14 shaojian0702 5 天前 PLAN MODE,讨论需求细节敲定了，让他把测试都写好，然后一把梭。不行就返工。 |
 | 15 pandasq 5 天前 |
 | 16 Miao18 5 天前 @rcj6056 https://code.visualstudio.com/docs/copilot/chat/chat-planning 相当于你先准备好详细设计（软工应该是这么称呼的吧）。然后再让 agent 实现。 在准备详细设计的时候，也能借助 AI 的帮助。 |
| 17 Miao18 5 天前 感谢分享。 先写测试确实是一个思路。 还有 plan 模式，可以通过不断的交互，让生成的 plan 非常详细，甚至可以详细到修改哪个代码文件。 |
 | 19 kasusa 3 天前 |
| 20 kasusa 3 天前 创建一个提醒事项的列表，随时想到随时记录。然后使用笔记软件/notion 整理需求点，并且删除一些明显多余的或者难以实现的功能。 然后一条一条实现。 |
 | 21 rrZ2C 3 天前 毫无技巧，只要把问题描述清楚 一个专业补丁工作者的日常 |
 | 22 derrick5788 3 天前 语义搜索 mcp 非常重要，可以防止上下文太长，重复造轮子 |
 | 23 Valid 3 天前 vibe coding 的终极实践应该是本地跑，或者就近计算 |
 | 24 ChristopherY 3 天前 我一般都是先自己描述需求，然后让 chatGPT 优化提示词结构，改成更好的、结构化的 LLM 指令遵循版本。然后再交给 Claude Code 去执行。再复杂一点的就先让 Claude Code 进入 Plan,确认 plan 没问题后，开始 coding.基本上没什么大问题。 |
Select Language