Vibe Coding 都是在理论探讨，好像没看到像 reddit 大量的方法论讨论。我目前用了一周的 gitlab 方法论，希望得到一定的指导优化

[sampeng]

当上个月我开始接触 claude code ，立马就取消了 cursor 的包月。因为这就是我要的 AI 工具，有多少 token 就給多少 token ，理解不了不是工具问题，是模型问题。

经过一个月的使用和磨合，claude code 同样有其他工具和模型的问题。

• 认为做完了，其实只是写了一个注释
• 认为写了单元测试，但其实单元测试里面是空的，仅仅有占位
• 实现幻觉，重复实现
• 因为大模型的特点，实现功能在一次询问和第二次询问结果是不一样的。其实就是很碰运气得到想要的结果。可能某一次让我感到惊讶，其他的时候就是这是什么东西，连刚入门的程序员都不如。

一开始我尝试过 todo.md/task.md 的方式，这是一个不错的主意，但是也有问题，流程实现不是太稳定。无法"记得/记录"下来 task 和 todo 让我回顾。

因为我们使用 gitlab ，所以我重新开发了一个 mcp 去操作 gitlab 。

同时，我编写了标准流程的 prompt 。其实这一步我是拆开的，我并没完整的 prompt 实现 workflow 。而是有以下几个组成

• create-issues
• implementing-issues
• plan-issues
• review-issues

不过这几个 prompt 还有个插曲，我昨天用 claude 自己的 prompt 优化器优化了一下，狗屁不是，各种放飞自我，还是自己写的更符合心意。就注重一点：引导式，明确说为什么这么做。好的做法是什么，坏的做法是什么。确实有奇效。用坏的做法去 ban 掉奇奇怪怪的操作。一次不行，就换个说法或者追加边界。其实挺浪费 token 的。。。

如果没有 zen mcp 。整个工作流的有效性会大幅度下降。

zen 帮我发现了很多的上述问题

• hi ，你看，A function 已经在 B file 实现过了。
• 我觉得设计实现增加了 xx and xx 这两点是没意义和冗余的。
• 这个接口的设计应该定义清楚什么参数范围
• 单元测试 A 中的测试有严重问题，他在虚空测试，自己实现了一遍业务逻辑，并没测试实际的业务逻辑。

但这一切带来了什么？

• 稳定的实现，在开始设计的时候我就可以介入，因为都在 gitlab 上。如果我愿意，我直接手改可能更快一点。
• 有多个 ai 在不同的步骤进行协助检查，大幅度减少心智负担
• 海量的 token 浪费。因为很多步骤是重复的。但我觉得非常值得。
• 慢，非常的慢。远比一句:"hi,帮我給登陆加个保存密码"要慢 1000%。实际最后的体验是和我自己写代码没什么太大的效率区别。不过最近我在尝试调整 prompt 引入子代理，以及同时定义多个不冲突的需求，开不同的窗口同时开发。
• 可跟踪，真正的记忆下来。因为都在 gitlab 中，我只要稍微的调整一下 prompt 的逻辑，完全可以做到：分析这个需求改动了哪些文件和模块，查找 git commit 中提到的 issues id 。同时获取到这些 issues id 涉及的内容。其实人类在回忆半年前开发代码也是这样的流程。
• gitlab 上记录什么：
  • what：需求是什么，要达到什么样的目标这个需求才算完成
  • how: the implementation plan,整个需求要改动哪些文件，要如何修改，为什么要这么修改
  • process：实际实施修改了哪些文件，修改了哪些单元测试，结果如何。
  • fix：review 后提出的一些建议和想法，以及我发现问题时我会让他改完后再提交到 note 中。