本文作者分享了使用 Claude Code 作为 AI 编程助手的体验。作者认为 Claude Code 在提供充足 token 方面表现出色，但同时也指出了其在代码实现、单元测试、幻觉生成以及结果不稳定性等方面存在的问题。为解决这些挑战，作者构建了一个基于 GitLab 的工作流，包含创建、实现、规划和评审 issues 等环节，并强调了引导式 prompt 的重要性。作者还提到了使用 zen mcp 工具来发现和解决 AI 辅助开发中的常见问题，例如冗余实现、接口定义不清和单元测试不准确等。尽管 AI 编程助手在效率上仍有提升空间，但作者认为其在稳定实现、多 AI 协作、可追溯性以及减少心智负担方面带来了显著价值，并计划通过引入子代理和并行开发等方式进一步优化。

📝 AI 编程助手 Claude Code 提供了充足的 token，但仍存在实现不完整、单元测试空缺、生成幻觉和结果不稳定的问题，这表明大模型在理解和稳定输出方面仍需优化。

💡 作者通过构建基于 GitLab 的工作流，将需求拆解为 create-issues, implementing-issues, plan-issues, review-issues 四个环节，并强调了引导式 prompt 的重要性，通过明确“为什么这么做”、“好的做法”和“坏的做法”来规避 AI 的不当输出，显著提升了 AI 辅助开发的有效性。

🛠️ zen mcp 工具在整个工作流中扮演了关键角色，能够帮助发现 AI 实现中的问题，如重复实现、接口定义不清、单元测试虚假等，从而提升代码的稳定性和质量。

📈 尽管 AI 编程助手整体开发速度可能不如手动编码，但其带来的稳定实现、多 AI 协同检查、可追溯性以及心智负担的减轻，使得作者认为其价值远超 token 的浪费，并计划通过调整 prompt 和引入子代理等方式进一步提升效率。

📂 GitLab 作为信息记录平台，详细记录了需求的“what”（需求与目标）、“how”（实现计划与修改原因）、“process”（实际修改与测试结果）以及“fix”（评审建议与问题修正），实现了真正的“记忆”功能，使得代码开发过程透明且可追溯，与人类回顾历史代码的流程类似。

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

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

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

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

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

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

create-issuesimplementing-issuesplan-issuesreview-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 中。