从“10 万行代码全是 bug”到“提交流程一次过”，作者用三周血泪史总结出一套 AI 编程防翻车三步法：先定位、再理解、后输出。只要让 AI 把上下文吃透，bug 率立降 80%。如果你也在用 Cursor 或 Claude Code，这篇文章就是避坑指南。

最近大部分精力都铺在“提示词管理助手”2.0版本开发上，带着我的好搭子claude code和cursor一起奋斗。

昨天晚上终于完成了上线前的测试环节，把它打包提交审核了，现在就等待谷歌那边过审就可以和大家见面啦~

这次迭代是我目前AI编程里耗时最多，难度最大的一次。

在“提示词管理助手”2.0版本的开发过程中，我总结了一下我干的最多的事情：写bug和改bug。

前两周的时间完全听AI的改架构，写了10万行代码全是bug，我本来满怀期待觉得AI说没问题，那应该我可以收获一个超级好用的版本。

结果啥都没收获还消耗了40刀的token。。。

只能从头再来了，我咬着牙给自己打气，你可以的，继续肝吧。

然后我继续迭代自己用claude code和cursor的编程方法，尽可能的降低bug发生的频率，一轮轮迭代过去了，终于见到了曙光。

打包提完审核的那一刻，感觉如释重负，终于还是做出来了，我还是可以和我的AI搭子们一起做很多事情的。

前两天跟大家分享了claude code 的整体编程思路，这次想更加聚焦的讲一个更关键的问题：

AI编程到底怎样能够少写bug，从而更高效的开发？

要真正解决AI编程bug率高的问题，我们要先搞清楚，它为什么写代码的过程中会出错。

以“提示词管理助手”为例，我就经历了bug从几乎没有到写啥蹦啥的全过程。

在早期几个版本用cursor开发的时候，bug可以说是非常少了。cursor开发都是一版过的，然后有一些细节我修修补补就好了。

随着功能的增加，代码量也随着增加，对应的bug率也增加了很多。

最明显的是在1.6.6版本后，我想优化一下飞书的授权问题，搞了俩小时除了让它更难用了，什么都没有改出来。。。

项目越大，代码量越多，AI越难准确的理解现有逻辑结构，bug也就会更频繁的出现。

归根到底其实还是上下文信息不够，导致AI不能正确的完成对应任务。

那其实只要能够想办法让AI在写代码前获得足够的上下文，这样bug也会降低很多很多。

于是我开始调整自己和 AI 协作的方式，在拿到一个需求后，我不会急着让它写代码，而是遵循这样一套流程：

1. 定位代码位置：先让AI把和这个需求相关的所有代码都找出来，明确说明这些代码文件都存放在哪。

2. 理解逻辑：搞清楚现有功能是如何运作的，新功能需要在什么位置介入。

3. 输出方案：开始写代码，搞定需求

前两步的重点是让AI看清楚现状，提供更多的上下文信息。

当AI具备了足够的上下文信息，再去写代码，成功率会很高，bug也会减少很多。

提示词管理2.0版本的开发进度中，我也采用了这个方法，对比之前的开发效率提升了太多了，要么那么多新功能和架构调整，我压根就搞不完。。。

那这个流程到底有多好用？我挑了两个我亲手踩过坑、后来靠它救回来的案例，带大家一起体验一下它的丝滑。

1.Cursor案例：版本号管理的bug修复

这是个小bug，主要是因为我在调架构的时候动的太多了，导致我的版本号管理文件好像被误删了，现有的版本管理逻辑和旧的对不上。

第一步：用 Cursor 快速定位文件

我需要cursor帮我修复这个问题，于是我先让它找对应的文件：

cursor自己查找了对应代码，告诉我现在的new是哪些文件来控制的，现在的逻辑是什么。

第二步：和 Cursor 一起梳理逻辑

然后继续和cursor讨论，得出一个功能开发的逻辑。

第三步：让 Cursor 生成修复方案

确认cursor都理解了，就让它开发就好了。

然后我测试了一下效果，改的没有任何问题。

2.claude code：提示词增删改查bug修复

这是个超级大的bug，我花了好几天时间在上边才把它改明白。

我之前写代码的时候过于让AI发挥，于是提示词增删改查它给我做了3套系统，导致我后续修改的时候，每次修改都只能叠加更多的bug。

第一步：让 Claude code 定位文件

于是我需要claude code帮我彻底解决这个问题，老样子还是让它先定位问题：

因为这个bug我改了一下午我实在没修复，这一次我就直接用“AI协作教练”提示词出的指令，让claude code先把这块的逻辑完整的读一遍。

然后claude code吭哧吭哧干了半天，给了我一个文档，基本上覆盖了这个场景下的所有逻辑。

第二步：和 claude code 一起梳理逻辑

然后我和它继续讨论，让它给到了我明细的流程图。

第三步：让 claude code 生成修复方案

基于流程图，让它梳理清楚当前bug的原因，然后做修复。

终于一次过了，太不容易了。

这两个案例一个小一个大，但是其本质都是一样的：帮AI看清现状，给与AI更多的上下文，从而让它写代码的时候变得更靠谱，降低代码率。

在写这篇稿子的时候发现，“提示词管理助手”2.0版本过审了，那我想在结尾跟大家聊一些我自己开发中的心路历程，聊聊我那些质疑过自己无数次的瞬间。

我开发一共花了3周，在前两周架构优化失败后，我脑子中其实有一个声音告诉我，这个产品你其实没必要做那么重，只要能用就行了。

新功能简单做一下，没有什么致命bug，前端样式和架构其实都不用调。只需要花一两天新版本就能推上去了，开发难度降低了很多。

从理性角度来讲这是正确的，但我想认真做好产品。

我可以接受花更多的时间，可以接受少写一点文章少一些流量，我想把这个产品做好，坚持迭代下去。

我在“提示词管理助手”开发完，去找小排老师和大铭老师得瑟的时候是这么说的：我的新版本开发完了，我感觉我的AI编程水平又往前迈了一大步。

如果我当时选择了偷懒，选择了不面对这一关，会错过很多美丽的风景的。

我想，还是要认真做好每一件事情，对得起自己，对得起用户，对得起良心。

这世界的力终究是反作用的，你给这个世界什么样的力，它会还回来的。

本文由人人都是产品经理作者【云舒】，微信公众号：【云舒的AI实践笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。