AI写代码越快，坑越多

今天分享下我总结的「4要素约束模板」—— 用AI写代码前，先把事情说清楚，速度才能真的快起来。先说3个最常见的坑下面这几个坑，我基本都踩过。一：上来就说”帮我修这个Bug”。发现问题了，直接把报错丢过去，或者一句”这个功能怎么不正常呀”，然后等它自己猜。猜对了皆大欢喜，猜错了再补充，来回几轮，不光问题没解决，人倒先烦了。二：只说想要什么，并没有说不要什么。直接说 ： “帮我加个用户登录功能。”， 然后 AI 一通操作，用户表、密码加密、token校验全写了。但实际上你可能只想要一个手机号验证码登录。等它写完你才发现不对，这就是需求本身很模糊的问题。三：没给 AI 划边界改一个Bug，搞不好把整个文件结构重构了。加一个小功能，把别的不相关模块的逻辑代码也改了。改完一跑，发现别的地方也整坏了。这 3 个坑有一个共同点：我们提前没说清楚。4 要素约束模板我现在改任何Bug、写任何功能，开工前都会先花几分钟，把 4 件事写下来。不用写正式文档，就是发给AI之前，先自己在脑子里过一遍——逼自己想清楚。① 问题的症状这个Bug是什么现象？用户看到了什么？报错信息是什么？越具体越好。比如不要说”这个接口筛选不了数据”，可以说”这个接口在有分页或超过500条记录后，筛选不了数据”。② 产生的条件什么时候触发？什么数据量？什么操作路径？把复现步骤写清楚。比如”在多维表格A里筛选日期字段，数据超过500条时，没有数据”③ 我们的约束哪些地方不能动？要遵循什么规范？用什么技术栈？哪些库不要碰？这条最关键。边界不划死，AI就会乱跑。我自己的原则是：“严格只改与这个功能相关的代码”这句话，每次都要写进去。④ 想要的效果修完后怎么验收？输入什么，输出什么，预期结果是什么？写出来，不是给AI看的，也是给自己确认——我到底想要什么。就这4件事，写下来没多少字。但只要你写清楚了，AI 的执行会稳很多。3分钟写清楚约束，比后面跟AI来回扯一小时省事得多。

真实案例：改睡眠系统的Bug今天客户反映之前的系统有个筛选问题，就用这个方法搞定的，说出来给大家参考。是个多维表格筛选的 Bug ——当时开发匆忙，加上项目不大，所以很多边界情况没考虑到， 现在数据量上来之后，用户就筛不出结果了。一开始，我直接和AI说：”api/stats/by-type和api/records这2个接口，我多维表格是有数据的，为什么现在筛选不了数据了”它改了一版，我跑了一下，不对。再改，再跑，还是不对。一来一回五六次，它每次改一个地方，顺手把别的代码也”优化”了。改到最后，整个模块的代码我快认不出来了，问题还没解决，新问题倒冒出来了。它分析了一会后， 倒是定位到问题了：当时没做分页，只取了前500条，现在数据超过这个量就出问题了。既然找到原因了，那就让它改吧，给我改了一版—在没有加上日期的情况下倒是能出数据了， 只不过它自作主张的用的内存筛选。我一看这不对呀，这数据全拿下来然后在内存里面筛选，这没意义呀，到时候数据量一大又拉垮了。又让它改完之后，这次使用的筛选条件的方式了，但是加上日期又不行了，
提要求让它处理日期，咔咔写完之后，我验证搜索不到。继续让它改，这次它说 ”我发现问题根源了“，又是一通操作之后，改完之后，好家伙，它告诉我因为日期不好处理，又给我回到内存筛选的状态了，敢情走了一圈，又回到原点了。那种感觉真的很糟——我感觉我不是在解决问题，而是在给 AI 收烂摊子。后来我意思到我以前的做法可能不对，不是 AI 的问题， 是我好多情况没说清楚。于是停下来，重新写了一段约束：

问题症状：多维表格超过500条记录后，用户筛选返回空。产生条件：使用api/stats/by-type和api/records这两个接口查询时，触发了内存筛选的边界。约束：

1. 必须用多维表格的筛选API，不要在内存中过滤。
2. 日期范围查询，起始时间加00:00:00，结束时间加23:59:59。
3. 改完自己先确认，不是用内存筛选。
4. 严格只改与这个功能相关的代码，不动其他模块。

想要的效果：筛选条件直接走多维表格API，500条以上也能正常筛出来。我的环境 ：
程序在虚拟环境 conda ，名字dev中，如果你要验证代码，要切到这个环境。

然后发给AI 执行， 它根据我的要求自己完成了代码的修复，并且还验证了代码，但是日期筛选它还是用的时间戳，于是我继续让它改

用编号，睡姿类型搜索没问题，但是加上日期后就有问题了。
1 你需要确认下多维表格的日期搜索到底是怎么搜索的，是不是用时间戳。
2 你可以看下现在这个编号去查询下多维表格的记录，看下它返回的时间戳是多少，或者返回的不是时间戳。
3 目前就是日期这里查询有点问题，主要处理这块，其它的模块不要动了

改完之后整个就通了，并且它还告诉我 ：多维表格日期使用时间戳方式查询是错误的。——这个细节，前面折腾了好几轮都没发现。改的代码也只动了该动的地方。关键差别在哪？不是 AI 突然变聪明了。而是在于我们先想清楚了自己要什么、不要什么。说白了，写约束的过程，其实是逼自己把问题想清楚的过程。很多时候你一边写，就会发现——哦，问题根源在这里，不在我以为的那个地方。意外好处：约束沉淀成资产还有一个没想到的收获。这些约束写下来，就变成了可复用的提示模板。下次遇到类似的Bug，骨架直接复制，改一下具体内容就能用。或者换了一个AI工具，把这些约束贴过去，照样管用。你之前跟 AI 反复磨合的理解，不会随着对话窗口关掉就消失——它变成了一份”个人经验库”，越用越值钱。这件事跟AI关系不大，跟人的习惯关系更大。最后想说用AI编程这一两年，我越来越觉得，说清楚这件事本身，本身就是一种核心能力。一个Bug，花3分钟把约束写清楚，可能少走两天弯路。
一个功能，花5分钟把需求和边界说清楚，可能少改三遍。
一个项目，花半小时把目标和限制列清楚，可能少返工一个月。前期看起来我们确实是”多花了时间”，其实是把后面要浪费的时间，提前到现在花完了。AI是放大器。你给它的输入越清晰，输出就越稳；你给它的输入越模糊，它给你挖的坑就越大。所以用AI写代码，技术只占一半，另一半是你怎么跟它说话。需求、边界、验收标准——说清楚这三件事，比学会多少新工具都管用。