零代码编程与AI沟通的一些纪要

那么我觉得有点不好意思的是，我并没有提供太多真正有价值的执行细节参照。毕竟执行过程还是比较复杂和反复的，所以也很难整理出完整的过程细节。

那么想想还是把我认为可能有用的一些执行中的习惯，交互认知分享一下。

1，不介意让自己当傻瓜。

这一点很重要，其实我说过我虽然有程序员经验，但不太擅长前端交互部分的设计，而且没有过移动开发的经验。更是和当下技术脱节了超过十年。

所以我会经常问AI非常菜鸟，非常白痴的问题，而且会反复问。

我有一个好习惯，就是我希望理解更多系统层面的逻辑，但是平时，如果问身边的人，第一，很多人都会有形象包袱，不想让别人觉得自己什么都不知道。第二，就算敢于提问，如果没听懂别人的解释，也不太好意思反复问。

但是面对AI就没这个心里障碍，不怕暴露自己的无知，大胆问，随便问，而且还可以很嚣张的连续问很白痴的问题，并让AI用最初级的方式讲解。

2，约束AI的过度发挥

一般，遇到所谓执行逻辑的错误是比较难以处理的，也就是代码不报错，执行结果和预期不一致，这种调试过程就比较复杂。

而这时候，AI很容易过度改动，甚至为了解决所谓的表象问题，大范围修改结构和基础代码，导致整个项目崩溃。

之前提过

 2.1 不断的git commit ，任何一个正向进步，赶紧commit。

那么2.2 让AI不要修改，先告知问题和解决方案，很多次你会发现它误解了你的问题，或者把问题扩大化，或者改动方案是无法容忍的。

2.3 继续让AI先不要试图解决问题，而是增加调试输出项，然后执行后把调试信息喂给它，重复2.2

调试是很需要你的经验，对业务逻辑的理解，AI现在可以给出很不错的调试日志，部分业务甚至可以做到自我测试迭代，但目前对于游戏而言，人的测试，我认为目前是不太容易取代的。毕竟游戏是给人玩的，只有人才能体会和判断到所谓游戏交互的是否顺畅，是否合理，以及难度是否恰到好处。

2.4 当确认AI应该是真的找到了问题时，强调，最小化改动。我发现这条太重要了。

过度修改，过度冗余，甚至是引入过度的掩饰策略而不是解决问题，都是AI常见的行为。

AI有些策略根本不是解决问题，而是掩饰问题，或者让你牺牲某些产品特性回避问题，特别操蛋。

我现在习惯说一句，最小化改动，只改动。。。部分，不要改动其他。

3，不断执行整理和清理的操作

你自己要心里有数，我旧文也提过，哪些功能，调用是可以复用的，刚开始开发可能是一个一个独立开发的，然后开始归纳，合并，统一逻辑，让AI合并相似逻辑，整理归一化的基础结构。

另外，针对cursor，当你拥有了一些全局通用的结构，参数，定义，并且需要频繁强调的，可以放在项目rules里，设置为always，否则它后续会忘掉这件事，然后继续制造垃圾。

归一化之后，让它反思代码，冗余的，废弃的代码尽量删除，否则以后遇到其它问题，它检查代码的时候会经常陷入这些废弃代码，浪费时间还会误入歧途。

我旧文提过，我做了逻辑归一后让它尽量做了清理，但后来发现并不彻底，依然有不少垃圾存余，不奢求完美清理吧，但尽量要做这件事。

有一个概念很重要，AI修改过多次的代码，会有大量废弃的冗余的部分，一定要不断让AI清理，逻辑拆分，后则后续的修改和调整将异常艰难，有人说代码冗余太多可以重做，不过有些复杂的业务逻辑跑通挺辛苦的，重做也不容易。

清理也要小心，它有时候也会粗枝大叶，直接把正在使用的一些调用逻辑直接清理了，不要让它直接清理，先给出清理方案，然后让AI再三检查相关代码。我发现好几次都是差点清理掉正在使用中的代码。

这个vscode + copilot有劣势，因为只局限在限定文件，可能对一些调用加载关系检验不充分。

4，安全校验

幸亏我追查了firebase远程前端数据调用的逻辑（用很白痴的方式反复问AI来理解），然后对可以分享的非敏感数据做了匿名化授权，结果AI对我做的准备视而不见，直接把登录远程数据库的key写到了前端，还好我让他做安全检验，自己发现了这个问题，不幸的是没多久它又犯了同样的错误。

所以每次发布前我都会让进行代码安全校验和参数传递的安全审核。

但安全加固其实也是适度就好，它会过度进行安全策略，而且代码本身也会存在一些命名或者定义冲突，以至于正常使用的功能被阻挡，就很无语，我只能再次界定，哪些安全策略（轻度且覆盖完整的）是可行的，哪些是过度的。毕竟我这个休闲游戏而已，不需要太复杂的安全防御策略。

有人说你应该让AI做全自动测试和迭代，特别是claude 4 opus有很强的自我测试迭代能力，我觉得也要看你的诉求场景，比如休闲游戏，这个必须玩家亲自体验，很多游戏中的体验感，难度设计才有真正的体会到，当然也必须承认测试成本挺高的，一些高难度的游戏关卡需要较多时间和运气才能执行完。

5，关于测试

那么仅从功能测试而言，一种合理的策略是降低难度参数来测试基本能力，比如测试游戏回放能力，把2048的入门难度定义到了128，这个就是为了测试方便。此外，测试挖阿挖的高难度通关回放，会把卡牌类型临时定义为3种（随便点都能过），等功能测试完毕后改为12种（非常非常难）。

难度设计的测试必须自己是专业玩家，比如数独就很典型，坦白说到现在数独难度依然不合理，极限难度过于简单了，暂时也没有时间继续调整。

AI过度修改是个很烦的话题，所以你哪怕只改很小的一个局部，但有时它会把很多功能和特性改的面目全非，所以可能很小一个修改就需要做全局的测试，这也是让我后来时间严重不足，测试严重不充分的原因，当然前面也提到了，要严格约束其修改范围。

还要重复一下，以上一切的背景是所谓 vibe coding，零代码编程，从头到尾没有自己做代码的设计，做代码的手工调整，结构也是AI设计的，但是我会通过对话做调整和优化，有人说你应该把代码结构做好再给AI，小问题应该手工修改，很多问题就不会出现，对不起，这不是我的初衷。

重复一遍，零基础开始做项目是值得鼓励的，但不要认为零基础是理所当然的，这只是起点，在前进的过程中，通过和AI的不断对话和交流，让自己变成有基础，懂技术。这里我的习惯是一个对话AI（chatgpt），一个编程AI(cursor)。

各种白痴问题我一般都是问chatgpt，但我注意到需要不断和cursor 核对相关内容，有几次几乎被chatgpt带到沟里去。我要做个Web分享能力，chatgpt一直要求我做完整的flutter build web，其实根本不需要，后来cursor建议我做一些简单的前端代码即可，可以直接flutter deploy only hosting发布上去。然后再拿这个说法问chatgpt，它又说是的，当然可以，这样更简单。。。

学习的时候也要不断核对。。。

6，要氪金

程序员也要氪金，氪金才能变得更强。

提醒一下各位老板，不要吝啬这个，一个程序员一个月在AI上花100-200美金我认为是很合理的，不要在这里抠门（20刀/月的 pro版本只是入门费用）。我认识的老板们会花的更多，很多都是自己玩的开心，不过如果对业务确实有帮助，给普通程序员花更多钱在AI上也是值得的。

不要总想着薅羊毛，如果你看中AI产出价值，这些羊毛的成本节省几乎不值一提。

大体这些。