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

零代码编程的实战心得：如何高效与AI协作完成项目开发。
核心内容：
1. 克服心理障碍，大胆向AI提问并理解系统逻辑
2. 约束AI过度修改的实用技巧与调试策略
3. 项目开发中的代码整理与归一化最佳实践

坦白说，这篇文章能提供的执行细节可能不算太丰富——毕竟，真正的开发过程往往反复且复杂，很难用三言两语完整呈现。不过，如果非要说点什么，倒是可以把过程中沉淀下来的几个习惯和交互思考，拿出来聊聊。

1. 第一步：先放下偶像包袱

这一点，其实是最容易被忽视的起点。虽然有过一些编程经验，但在前端交互和移动开发这块几乎是零基础，而且与技术前沿脱节了超过十年。所以，经常向AI抛出那种“一看就是菜鸟”的问题，而且问一遍不够，还要反复追问。

一个值得养成的习惯是：尽可能去理解系统层面的逻辑。但现实中，如果换作问身边人，绝大多数人会有心理包袱——不想让人觉得自己什么都不懂。就算鼓起勇气问了，没听懂对方的解释，也不好意思再追问下去。

换成AI，这种障碍反而消失了。不怕暴露无知，大胆提问，甚至可以理直气壮地连着问一堆特别基础的问题，然后让AI用最直白的方式重新解释一遍。

2. 如何挡住AI的“过度关怀”

碰到执行逻辑上的错误，往往最让人头疼。代码本身不报错，但运行结果和预期偏差巨大，调试过程就成了噩梦。偏偏这时候，AI极容易陷入“过度改动”的怪圈——为了掩盖表象问题，它可能大范围重构基础和结构代码，结果整个项目崩得一塌糊涂。

这里有几个实用策略值得记住：

2.1 勤快一点，把版本提交当饭吃

每一次正向进展，不论大小，第一时间git commit。一个正向进步，赶紧commit，把每一丝成果都夯实。

2.2 让AI先别说“改”，先说“问题”

先要求AI只描述问题以及它认为可行的解决方案，而不是直接动手改代码。很多时候，AI对问题的理解是错的，或者它提出的改动方案完全不能接受。

2.3 增加调试输出，把它当成“传话筒”

让AI先不要急着修复问题，而是增加调试信息输出。然后，把运行后的日志反馈给它，重复上一步的判断流程。调试过程中，人的经验和对业务逻辑的理解至关重要。虽然AI现在能给出不错的调试日志，甚至可以让部分业务实现自我迭代，但至少在游戏领域——尤其是游戏是否流畅、是否合理、难度是否恰到好处——目前还很难完全由AI来判断。毕竟，游戏最终是给人玩的。

2.4 确认AI找到问题后，务必强调“最小化改动”

这条经验至关重要。AI常见的“毛病”包括：过度修改、过度冗余，甚至用掩饰策略来解决问题，而不是真的修复问题。有些AI的方案，根本不是解决问题，而是用牺牲产品特性来回避问题——这让人着实无奈。建议养成一句话的习惯：最小化改动，只改某个部分，别碰其他地方。

3. 代码整理和归一化：别让它变成“烂尾楼”

自己心里要有数——哪些功能、哪些调用是可以复用的。初期的开发可能是一个功能一个功能独立完成，但到了后期，必须开始归纳、合并、统一逻辑。让AI合并相似逻辑，整理归一化的基础结构，这是硬要求。

如果用到像Cursor这样的工具，当全局通用结构、参数、定义被确立下来，并且需要反复向其强调时，可以设置成项目的rules，并且设为always。否则，AI后面会重新遗忘，然后继续制造“垃圾”。

归一化完成后，还需要让AI对代码进行“反思”。冗余的、废弃的代码尽量删除。否则，后续处理其他问题时，AI会频繁陷入这些无用代码中，浪费时间，甚至可能被误导。

曾经试过让AI尽量做清理，效果并不彻底，依然有不少“垃圾”存留。不指望完美清理，但这步一定要做。AI反复修改过的代码，会有大量废弃和冗余部分，如果不定期清理和逻辑拆分，未来的修改和调整会异常艰难。有人说冗余太多大不了重做——但有些复杂业务逻辑跑通已经很不容易，重做的代价也不低。

清理时也得小心。AI有时会粗枝大叶，直接把正在使用的调用逻辑给清掉。比较稳妥的做法是：先让它给出清理方案，再要求它反复检查相关代码。曾经有好几次，就差点清理掉正在使用中的代码。VS Code加Copilot在这种场景下还有一些劣势，因为它只局限于单个文件，对调用加载关系的检验不够充分。

4. 安全校验：放在最后一步

某个例子非常典型——当时追查Firebase远程前端数据调用的逻辑（靠“白痴式提问”让AI反复讲解），完成之后，对可分享的非敏感数据做了匿名化授权。结果，AI对这些准备视而不见，直接把登录远程数据库的key写到了前端。还好让它做了安全校验，自己发现了这个问题。不幸的是，没过多久它又犯了同样的错误。所以，每次发布前，必须进行代码安全校验和参数传递的安全审核。

但安全加固也要适度。AI会过度设计安全策略，而且代码本身也存在命名或定义冲突，导致正常功能被阻挡，让人无语。只能再次明确哪些安全策略是可行且必需的（轻度但覆盖完整的优先级更高），哪些是过度的。毕竟只是一个休闲游戏，用不着太复杂的安全防御策略。

有人提出，应该让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工具上，这笔账是算得过来的。

别总想着薅羊毛。如果真正看重AI带来的产出价值，这点成本节省，几乎不值一提。

大概就是这些。