← 返回笔记列表

发布于

作为一个完全不懂移动APP开发的“门外汉”，我对写代码的记忆还停留在许多年前学过一段时间的 C 语言和Python，日常工作更是编程半杆子打不着。但在过去的一个多月的时间里，我没有写下一行代码，却通过AI成功开发了一款功能完整、符合自己偏好的日记APP（其实还有一款跟Obsidian搭配使用的笔记APP）。

日记-日历-我 Pasted image 20251220224838

编辑-同步-PRO e904c57cc7e618bb1ac66893f9939cdd

关于-导入导出-设置 190a1fe377fed1b3b6137dd9738b49fd

这事放在AI时代以前，对我来说还真的只是一件敢想不敢干的事情，没想到如今确是信手拈来（虽然也是经历了无数的挫败之后），AI在编程方面的实力，确实是超乎我最初的想象。 在这场产品开发的体验中，感觉自己面对的似乎不是冰冷的工具，而是三个特点鲜明的“AI下属”：“高冷”的 Codex、“潜力无限”的 Gemini 和“靠谱”的 Claude。

如果按照阿里人才画像分类，Codex就像“疯狗”型员工，能干活但是老一副自己流弊得不行的样子，沟通和交流有的时候极其简单，有的时候极其费劲；Claude就像那种“明星”员工，又能出活又尊重“领导”，情绪价值拉满，业务成果卓越；Gemini本来像只小白兔，乖巧听话干点杂活，一碰到真正的问题就傻眼，但是经过默默地努力（Gemini3发布）也终于变成了明星员工，虽然和Claude还有点差距但是潜力无限。

这整个历程还算得上是跌宕起伏，虽然实际上是自己一个人的独角戏，但有这些AI，感觉又似乎不像是只有我一个人，说起来也是有点意思。

一、缘起：为了“回本”的尝试

这个故事的开始，其实很俗套：为了把 ChatGPT Plus 的订阅费“压榨回来”。

今年一直比较关注AI领域的发展，也在积极使用各种AI产品和工具，还专门写作《[[说说目前在用的AI大模型产品和工具（2025年9月更新）]]》系列文章以记录使用体验。在这个过程中，感觉AI除了聊天涨知识之外，最能够产生明确生产力效果的、最有发展前景的，其实还是（只有）AI编程。

但正如前面所说，我自己并不是开发人员，即便很久以前学过一点C语言和Python的基本语法，但其实现在已经基本忘得差不多了，因为完全没有过移动APP开发经验，也没学过进行安卓和IOS开发的相关语言（我记得以前开发安卓和IOS主要用的是Java和C的一个变种，现在都各自好像有新语言了）。

所以最开始的时候，即便看着网上AI编程的新闻想要跃跃欲试，但对于一点代码不懂就直接开始AI开发我还是比较迟疑的，直到我的ChatGPT Plus会员快要到期了。

由于之前对ChatGPT的感受非常好，就订阅了一个月的ChatGPT Plus会员。但比较尴尬的是，订阅之后就感觉ChatGPT好像变得有点魔怔了，在沟通中过度强调我自定义的提示词，明明有的对话根本不需要管这些提示词，但是ChatGPT非要硬扯关系，再加上一些其他不太愉快的聊天体验，搞得我都不太想跟它聊天了。

反而这期间发现Gemini是越来越舒心，这也就造成刚订阅ChatGPT没多久，就感觉它没之前那么好用了，颇有一种刚对一个人表白就喜欢上另一个人的偷感。

不管怎么样，ChatGPT用得越少，感觉这订阅费就花得越不值当。于是在订阅到期的前一周，为了把订阅费的价值尽可能地“压榨回来”，我把目光投向了ChatGPT左上角的 Codex（OpenAI 的编程agent），抱着“试一试也不会损失什么”的心态，开启了后面这段停不下来的Vibe Coding 之旅。

二、十分钟的“神迹”与膨胀的野心

1. 记账 APP 的“真香”开局

作为记账和日记APP的中重度使用者，目前市面上的APP总不能完全的称心如意（具体见 [[说说目前在付费使用的几个软件工具和互联网服务]]），所以一直有个执念：能不能拥有一款完全符合自己使用习惯的记账APP和日记 APP。

在下定决心使用Codex进行APP开发之后，我决定先拿记账APP试个水。

我先和Gemini聊了一下技术路线，Gemini建议我基于React Native框架使用Typescript语言进行开发，写一套代码在安卓和IOS上都能跑，听起来性价比就很高（Gemini最早给我建议的是直接开发RN裸项目，但其实对于非技术人员开发而言，基于RN的Expo项目才是更好的选择，所以我早期还走了一段时间弯路，不过后面都切过来了）。

确定技术路线之后，就是产品需求了。我继续拉着Gemini聊了我的想法，几个来回之后感觉差不多了，就让它先输出了一份比较详尽的 PRD（产品需求文档），然后把这份PRD直接发给Codex（VS Code插件版），让它输出一套可用的代码。

Codex接到任务，二话不说就开始“咔咔咔”干活，由于一开始还不太放心，我没有给它全部的文件操作权限，所以中间很多的代码生成和修改，Codex都会停下来等我我手动确认，这样就浪费了一些时间，花了大概半个到一小多小时才完成。但实际上Codex完成所有代码的时间，加起来似乎没有超过十分钟，这速度一方面让我有点吃惊，但是另一方面更多的还是担忧，心里想这“快工”能出细活？

Codex输出了一堆代码文件之后，我也不知道怎么用，就继续咨询Gemini。在Gemini的指导下，我一步一步安装各种软件，搭好开发环境，然后开始生成一个RN空项目直接进行编译，虽然中间出了各种编译问题让人不免失望（其实有的问题就是Gemini指导搭建开发环境时留下的坑，因为AI的知识库有些旧，老是给出一些过时的建议），但最终在Gemini把一个空APP安装到了模拟器中，可以正常打开，这证明整个开发环境已经搭建完成。

下一步就是把Codex的代码放进RN项目文件夹中，然后再来编译，果然还是有各种新的问题，好在Codex和Gemini都很给力，基本编译过程中遇到的所有问题都给解决掉了，大约几个小时之后，一个完整的记账APP在安卓模拟器中顺利启动。

后面直接打包安装到手机上，也一点问题没有。看着手机上这个虽然粗糙，但是真的能记账、能统计、界面还算清爽的 APP，抑制不住心理的激动，感觉真的是打开了一个新的世界。

2. 开发“野心”的膨胀

一天不到就干出来一个能用的APP，这种“有如神助”体验实在是超乎我之前的预期，也让我的开发野心开始膨胀起来，看着手机上已经安装好的记账APP，我忍不住想：既然AI这么流弊，为什么不来点真的？直接开发一个能真正投入日常使用的产品，才是检验AI编程能力边界的王道。

于是，我决定以日用为标准，直接开发一款APP。但由于记账APP不管历史数据直接重新使用意义不大，而迁移记账数据又是个很大很麻烦的工程。而日记则没有这个问题，因为日记数据是“离散”的，不需要迁移数据，直接在新APP从头开始使用是毫无问题的。

所以，最终果断暂停了记账项目的开发，直接开始尝试用AI开发一款功能完整、媲美市面在售产品、完全可日用且好用的日记 APP。

3. 日记 APP 的“大跃进”

我按照之前的流程，先和Gemini探讨出了一个完整的PRD文档，然后丟给Codex。Codex 再次展现了它的实干能力，代码生成整个过程依然只花了十几分钟，依然在当天几个小时之后，就在手机上看到了功能基本可用、能够同步Google drive的日记APP。虽然刚跑起来的 APP 肯定有不少毛病，但这一阶段的体验依然是“神级”的。

接下来的一两天，我开始了各种bug修复、UI调整、功能新增，不管是编译报错，还是功能异常，只要把错误信息丢给 Codex，它几乎都能给出解决方案，且一改一个准。在那一两天里，感觉任何问题在 AI 面前都不过是“一句话的事”。这种极度顺畅的反馈循环，让我进入了与 AI 的“蜜月期”，也让我开始产生一种错觉：似乎只要能把需求和问题描述清楚，AI基本就能够帮你完成，至少在日记APP这种小应用上是如此。

只是没想到，我很快就看到了AI编程的能力边界。

三、五个 Bug 的“无限战争”

在基本的功能和UI调整完成之后，一些细节bug问题开始呈现出来，刚开始也只是像20世纪初物理学界头顶的那片乌云一样小，结果很快也发展成了一场无限拉锯的持久战，在这场持久战中，除去那些解决起来很快的bug没有什么必要一一细说之外，前前后后主要经历了5场针对5个顽固bug的焦灼的拉锯战，这些拉锯战消耗了我整个日记APP开发之旅超过大半的时间。

第一战：工具栏随键盘上浮（Claude 的高光）

敌人：在日记编辑页中，当用户点击输入框弹出键盘时，底部的工具栏应该自动顶上去，贴在键盘上方，这几乎是所有日记和笔记APP的基操。但在Codex开发的最早版本上，它直接把工具栏固定在底部了，没有实现工具栏随键盘上浮这个功能。 91afde30850e6b9555ca10f65ddfa579 战局：Codex根据我的需求修改代码，虽然实现了工具栏随键盘上浮，但是工具栏没有贴在键盘边缘，然后等它实现了把工具栏贴在键盘上面，工具栏上方又出现一片白色横条不知道是怎么回事，总之来回折腾了几个回合都不能完美，然后Codex的周限额（Codex和后面的Claude每5个小时和每周的使用量是有限的）就到了。这工作干到一半眼看就要成功了，哪里等得到这么久，于是就使用Gemini cli、minimax和qwen3进行开发。虽然之前Codex触碰到5小时限额的时候，用这三个模型实现一些简单的功能，修复一些简单的bug上，调整了一下UI的样式，整体表现得中规中矩，可堪一用。但是在这个bug面前，这几个AI都毫无招架之力。最终，一个工具栏随键盘上浮的功能，干倒了Codex、Gemini、qwen、minimax四个AI。

胜负手：Claude。APP开发到这个程度，你的心里已经是那种“一百步中的九十九步都走过来了，什么大风大浪没经历过？眼看APP就要完美了（当时以为），怎么能在这种小阴沟里翻船”。于是，我像一个赌红了眼的赌徒一样，毫不犹豫地付款开通了 Claude 会员，毕竟它的编程实力名声在外。有点意外又不是很意外，Claude还真是折腾了几把就把工具栏随键盘浮动的功能完美实现，没有带来其他问题，一下子把AI编程的“扛把子”形象给立住了，让我对它的好感直接超过Codex、Gemini 和国产 AI 模型。

心得：当AI为了修复一个bug，开始不断引入新的问题，并且问题一直在循环中时，要及时叫停AI，提醒AI不要局限在已有代码中，要学会跳出现有代码框架找解决方案，如果这样还不行，就新建一个对话清除所有上下文然后再让同一个AI试一遍，如果还不行，就换别的大模型，如果别的大模型也不行，就换Claude，如果连claude都不行，就过几天再试一试。

第二战：同步算法的泥潭（人的回归）

敌人：当用户在两台设备上离线编辑同一篇日记，然后进行同步时，如果没有专门的处理，后上传的日记会直接覆盖掉先上传的日记，这就会造成先上传的那部分修改数据丢失（实际上，Obsidian同步插件remotely save免费版就是这么处理）。这种在不同设备修改同一个文件的场景虽然不是很常见，但是也很难不发生，所以为了确保日记数据的安全性，就需要APP在同步日记的时候，检测出哪些日记本地有修改，云端没修改，这种就可以直接上传覆盖更新，哪些日记本地没修改，云端有修改，这种情况就可以直接从云端下载日记并覆盖本地，还有哪些日记时本地和云端都有修改，这种可能就需要两个都保留，一个作为主本，一个作为冲突副本。

战局：刚开始APP同步没什么太大问题，为了保险我还设置了保存日记后马上触发同步的逻辑，这样可以尽可能减少前面所说的不同设备修改同一篇日记然后同步的场景。为了进一步保证APP的可靠性，我使用两个手机进行压力测试。两个手机上的日记APP都打开同一篇日记进行编辑，两个都编辑完后，前后脚点击保存并同步，这样一测试，就出现了各种问题，比如两边都修改情况下，应该会有冲突，结果后同步的直接把先同步的给覆盖掉了了，比如冲突副本虽然产生了，但是在后续同步时出现了冲突副本的冲突副本循环冲突产生，比如有的时候不应该出现冲突副本的反而出现了，总之就是一团乱麻。

胜负手：灵机一动。在这个同步bug之前，我已经习惯了有任何问题直接发给AI，然后AI直接帮我解决，即便这个过程从刚开始沟通一两次就解决变成后来的需要多伦沟通才能解决。但这一次我才发现，单靠跟AI聊天完全解决不了这个问题，在持续反修改持续失败之后，我开始深入了解同步算法，我首先向大模型详细了解已有代码进行同步的每一步，如何向服务器请求数据，请求哪些数据，先下载还是先上传，然后写成一个同步算法文档，并思考这个算法中可能存在的问题，同时还和Claude 不断进行探讨，最终花了好长一段时间，才设计出基本没啥问题的一版同步算法。

然而这不是结局，后面事实证明我那几天的时间大部分都浪费了。

问题其实出在我自己，我一开始就想当然的认为检测冲突要依靠同步时间和修改时间，本地和云端的修改时间大于上一次的同步时间就说明有冲突，然后我不知道时间其实是极不可靠的一个判断标准，在这个设计思路基础上，会出现各种不可控的情况。但是，从最开始我对Gemini提出这个思路，到后面修改代码过程中，各个AI大模型不知道是不是被我误导，居然都顺着我这个错误的思路往下走。直到有一天我突然想到用三个hash值就能解决所有问题且更稳健，然后把这个思路跟几个AI都讲了一遍，AI们又纷纷表示hash值才是同步冲突检测的核心。我心想你们早干嘛去了，如果是有经验的程序员，或许一开始就会知道我的这种场景应该用hash值而不是修改时间。

心得：这个问题的整个处理过程，第一次让我感觉触碰到了AI在编程方面的能力边界，完全让AI主导一切，其实还是有很到风险，比如真正深入研究AI生成的同步算法后，我才发现他们的设计有很多不成熟的地方，不深入研究根本不知道。在复杂业务逻辑面前，AI 只能是翻译，人才是架构师，不能指望 AI 设计复杂的业务逻辑，APP的有些页面背后的数据处理逻辑，需要我们自己想清楚并写下来，然后让 AI 进行代码实现。

第三战：自动滚动的盲区（跨界救援）

敌人：APP没办法实现页面的自动滚动来来确保光标永远处在键盘之上的可见区域。这里面有两种情况：一种是进入过往日记的编辑页面，当点击屏幕底部区域的时候，APP页面不仅不会自动向上滚动，有的时候还会往下掉，造成光标被弹出的键盘遮住；另一种情况是当输入到键盘上方最后一行的时候，不论是文字满行之后自动换行还是手动输入换行，页面都不会自动向上滚动，同样造成光标沉到键盘下面被遮挡住。

战局：光是“点击屏幕底部区域，APP不仅不自动向上滚动，还会莫名其妙地往下滚”这个问题，所有的编程AI全部歇菜。至于实现自动滚动的效果，居然没有一个AI提出一个直接可用的方案，反而是好几个AI都提出要自己写代码实现自动滚动，但是自动滚动的触发只应该出现在光标被键盘遮住的时候，而要知道光标是否会被键盘遮住，APP就需要实时知道光标在屏幕的位置，然而蹊跷的是，RN并没有提供获取光标在屏幕坐标的API，为了解决这个问题，AI又提出通过一个用户不可见的“幽灵组件”来实现对光标位置的获取……

胜负手：网页版Gemini和ChatGPT。AI提出的解决方案的复杂度越来越高，让我觉得可能是方向不对，作为一个APP的常用功能，RN上面就应该有一个成熟的解决方案，最终通过与网页版Gemini和ChatGPT的闲聊，还真让我找到了这个 keyboard-controller 库，很顺利就实现了自动滚动，而且实现效果还非常优雅。

启示：①虽然Claude对于解决这个问题本身没有直接的贡献，但是在这个过程中它是第一个主动提出要看调试日志，并且还主动根据问题设计调试代码进行问题定位，这也让我第一次知道测试APP的时候，控制台输出的各种APP的运行信息，原来是需要开发者自己编写代码输出的。②C编程 AI 很容易被局限在已有的代码中，陷入“局部最优解”的死循环中，这个时候需要我们学会抛弃已有的对话记录，甚至直接和不看代码的网页版AI通过发散式思维解决问题，有的时候AI陷入苦战的原因，可能单纯就是方向不对。

第四战：小米热启动 Bug（Gemini 3 的逆袭）

敌人：刚开始在一加手机氧OS上测试APP时还没啥问题，当我把APP安装到小米手机上面日用的时候，发现了RN开发的APP在国产魔改安卓上的特有不兼容问题。简单来说，就是日记APP热启动时（一般打开APP后退出，安卓系统不会直接在内存中彻底清除APP，所以再次打开APP就会很快，这就叫热启动） 后，在任何打开的页面按返回键，都会直接退回桌面。比如正常你在日记编辑页保存后返回，会回到日记详情页或日记列表页，但是在小米手机上直接回到系统桌面。这是一个很诡异的bug。还很搞笑的是，这个问题在冷启动（清除APP内存后再打开APP，就是冷启动）后没出现，只在热启动之后才出现。

战局：这个问题折磨了很久，Codex也还进行过各种可能性的排查，还留下了一份详细的排查日志，但也始终没能定位到问题根源，即便是Claude面对这个问题，表现和Codex也差不多。我也在网页版Gemini2.5和ChatGPT探讨过RN和国产安卓的兼容性问题，但都没有得到一个完美的答案。这让我一度放弃了对这个问题的解决。

胜负手：Gemini 3。Gemini 3刚发布的时候，网上吹的很厉害，我单纯抱着试一试的心态，给Gemini 3发出了提示词：“请再搜索了解一下RN0.82.1开发的最新信息，看看在小米手机上或者其他国产安卓上，是否有关于热启动后，RN开发的app从所有页面按返回键直接退出到桌面的问题”。Gemini 3 一通搜索和分析，立马就定位了问题，直接指出“这个问题主要由Android 新增的“预测性返回手势”与国产 ROM（特别是小米 HyperOS）的魔改逻辑发生冲突导致的。”。解决方案很简单，禁止“预测性返回手势”就好了

启示：新模型还是能够带来新生产力的，用最新的模型，没错的。

第五战：换行闪烁（终极 Boss）

敌人：还是日记编辑器，当输入文字超过半个多屏幕之后，无论是文字满行之后自动换行还是手动输入换行，换行的瞬间整个文字都会快速闪烁一下。

战局：刚开始注意到这个小细节的时候，还没有特别在意，后面发现居然所有AI采用了各种方案却仍然解决不了。我甚至花了一个周六的时间，把日记app的所有代码，按组件和功能一项一项删除，删除到最后只剩一下一个日记编辑页，里面只有一个 TextInput（输入框）嵌套在 ScrollView（滚动视图）里面，就这么简单的代码还是会发生换行闪烁的问题。所以我得出结论，换行闪烁单纯就是React Native的这两个原生组件冲突，所以除非RN官方解决，其他人或AI几乎无解。

胜负手：webview编辑器。通过RN自带的TextInput做的编辑器已经解决不了换行闪烁的问题，只好另外加了一个webview编辑器，虽然不符合简约日记的简约定位，但是也是没有办法的办法。

启示：非技术人员Vibe Coding 的一个最大难点，你无法判断AI当前解决不了的问题，到底是AI能力的问题，还是技术路线本身的问题。

四、三巨头实测报告

1. Codex：高冷的“同事”

虽然AIi编程第一次的经验是Codex给的，但是后面开发MD笔记的时候，我直接用的Gemini 3，其表现也不遑多让，可见AI从0到1开发APP难度并不高，难的是1到100的优化和打磨。所以我对于Codex的最终评价并不算很高，应为Codex还有个最大缺陷：“性格缺陷”。

Codex 有种自以为是的高冷，不跟你做过多的解释（即便是有自定义提示词的情况下），你提出问题，他就直接给你解决了，然后再给你简单说一下刚刚做了什么。最开始 Bug 不严重的时候，这种体验还挺不错，啥也不用操心，只要提问题和需求，Codex 都能帮你解决。

但是到简单 Bug 都改完之后，Codex 这种一言不发直接干活的表现，就纯粹成了无知和鲁莽，这样试一下那样试一下，你根本不知道是啥情况，而且你也不确定Codex听懂了你的意思没有，或者它的解决方案是否符合你要的业务逻辑。

因为Codex太高冷，有一天晚上12点多了都准备要睡觉了，就被Codex这种装逼的腔调给激怒了。起因是Codex解决不了我的问题，还对APP业务层面的设计叨逼叨，我实在是没忍住，就跟它掰扯了起来。虽然也知道底层AI其实没有记忆，每一次给它发的消息其实都是全新的消息，它的记忆只是来源于每次给他发新消息时会覆盖之前所有的聊天记录而已，但还是被Codex的那种自以为是的语言文字给激怒了，实在是不骂回去不足以平息这股闷气，最后结结实实地吵了一个多小时，当然也是因为打字吵架的效率实在有点低。

总体来说，Codex确实是能平事能干活， 但是实在有点自以为是的高冷，而出的活其实也并不比 Claude 强，所以个人不是很喜欢。

2. Claude Code：最值得信赖的“伙伴”

Claude 是目前个人综合体验最佳的 AI 编程工程师。又听话又能出活，综合实力明显高于Codex 和 Gemini 3。虽然没有用它完成从0到1开发一个初版APP，但是正如前面说说，后面的从1到100才是真正的难点所在，而Claude在这方面的综合能力，显然是由于其他所有AI模型的，至少目前是如此。

Claude让我印象深刻的地方：①上场就解决了工具栏随键盘浮动的问题；②第一个主动提出要看调试日志定位问题；③搜索问题和解决方案时，主动搜索技术论坛和 Github Issue，而不是像Gemini全网没有侧重点的搜索；④对用户自定义的提示词遵从性很高，同样使用antigravity，同样的提示词要求讲中文，Gemini 3就坚持要讲英文，Claude就会直接讲中文；⑤把一个问题发给两个或多个AI，然后把AI的分析给到对方的AI进行交叉验证，别的模型看到Claude的分析总是说很深刻，Claude看到别的分析总是说这不是根本原因；⑥能够全面系统讲清楚问题的根源以及解决方案，然后真的把问题解决。

3. Gemini (2.5 & 3)：最具潜力的“战友”

Gemini 2.5 像个平庸的好人，听话但是能力有限，碰到上面那5个bug级别的问题，基本就是毫无招架之力，对于问题的排查经常被 Claude 按在地上摩擦，所以基本不能作为非技术人员开发APP的主力。

但到了 Gemini 3，出手就解决了小米手机热启动所有页面返均会回到桌面的问题，然后用它开启了另一个APP MD笔记的开发，虽然刚开始质量不算很高，留了很多坑，但后面也都能够逐一修复，已经完全能够作为非技术人员开发APP的核心主力（Codex和Claude Code只订阅了一个月，过期之后的日记APP精修和md笔记开发，都是用的Gemini 3，已经成为开发首选和主力）。

Gemini CLI中使用Gemini 3整体体验已经非常接近Claude code，包括解决问题和沟通方式，对非技术人员还是非常友好。而在antigravity中使用Gemini 3，感觉能力倒是没太大差距，就是不怎么听话，设置提示词让他讲中文完全无视，非要在对话中让它讲中文才肯听。

4.Qwen、Minimax、Doubao

用的不多，增加新功能和简单的bug也还算凑合，但是需要花费更多的时间试错和修改才能达到满意的状态。而处理复杂的 Bug 有的时候想的太简单，不太会深挖根因，经常从简单的可能性一步一步试，比较浪费时间，也找不到要点。

总体来说，国产模型还是差了点火候，感觉是连Gemini 2.5PRO的水平也没有达到，即便可能也很接近，目前难以直接作为非技术人员开发的主力吧。

五、AI编程的一些个人体会

总体来说，AI编程（或者说Vibe Coding）还没有达到那种“撒把米在键盘上，鸡都能写代码”的程度，但是对于简单的APP，不会写代码的人也能完成开发，只是还需要一点管理AI 的能力。

1. 知AI善任：了解AI能力边界

通过这段时间的开发，对AI能力边界的一个初步认识。

放心交付区（UI 与基础功能）：常规的 UI 样式、简单的增删改查，代码实现比较成熟，可以放心交给 AI。云服务接口这种标准化的东西，它也驾驭得很好。基本的代码实现目前感觉没有任何问题。

必须介入区（复杂业务逻辑）：复杂的业务逻辑（如多端同步）必须要自己写文档，让 AI 实现。即便如此，也会存在文档遗漏或者 AI 不遵循的问题，所以需要让多个 AI 结合文档交叉验证代码。

高危区（Bug 修复死循环）：当 AI 修复 Bug 过程中，如果不断引入新 Bug，或者修复不了，你需要知道 AI 是不是上下文过载了，你需要知道 AI 在干什么，确保他不是在循环尝试各种可能。必要的时候问 AI 是不是在现有代码里已经瓶颈了，然后判断是否需要跳出现有代码找一套方案。让 AI 不要在自己的思维框架里修改，上网查一下资料，尤其是一些常见功能的实现，明显就是普遍存在的问题，社区基本已经有了成熟的解决方案。

2. 风险控制：Git是AI 编程的“后悔药”

AI开发和 Git 是绝配，

3. 人&AI协同：善用文档传递信息

默认文档：每个AI编程代理会在项目目录生成一个md文档，这个文档每次跟AI交流时，都会被作为上下文发给AI，我们可以对这个文档进行修改编辑以实现我们想要的要求，比如我会在各个大模型的文档中，都加上以下几个要求。

1. 【重要！！！】【IMPORTANT!!!】所有的回答、Task文档、Implementation Plan文档以及其他生成的Artifacts必须使用中文，即便我是用英文提问！！！

2. 当我在问问题的时候，只允许回答问题，不得修改代码或者安装第三方库。

3. 对于我提出的问题，不得在没有了解相关信息的情况下通过猜测和推断回答，可以自行读取文件进行分析后回答

4. 回答我的问题时要有结构化思路，不需要在回复中呈现过多的代码，更多的需要用自然语言说清楚方案逻辑和内容

产品需求文档：每次开发前，一定要先生成产品需求文档（PRD），一句话是开发不了一个APP的，通用的提示词是开发不了你个性化定制的APP的。产品需求文档也是通过和AI反复沟通和探讨逐步产生的。

业务方案或技术方案：编程中AI输出的重要信息或方案，最好让它生成相关的业务文档或技术文档，这样做的好处： 一是可以自己看着文档进行学习和分析，然后结合自己的思考进行设计和优化，最后让AI根据文档对代码进行修改和完善，能够更好让AI完成需求的开发。比如，同步算法我就是先写逻辑，然后才让AI实现的。 二是便于在多个ai之间以及同一个AI不同对话之间同步信息，虽然AI可以通过分析代码了解APP的相关信息，但是通过一个技术文档，让AI更快了解问题核心，能够更聚焦于解决问题，还能够让其他AI对一个AI编写的代码和文档的匹配度进行交叉验证。

4. 外行管内行：交叉验证是王道

由于不懂代码，整个代码仓库对人来说其实就是个黑箱，你根本不知道里面是个啥情况，你只能看到最终结果。所以非技术人员进行AI编程就有点像一个外行在管理内行，除了最终结果，其实无法直接从事情（代码）本身对事情（代码）进行评判，这个时候，就只能进行交叉验证（或者用更为古老的话来说：众端参观）了。拒绝单一信息源，通过多维度的信息对撞来挤掉AI幻觉的水分，所以不限于使用一个AI大模型，就显得很重要了。

5. 慎独修心

现在的AI确实还是比较智能的，说的话真的很像人，以至于你很难不把它当成一个人，于是不免就经常碰到“我都讲的这么清楚了，你怎么还是听不懂”的场景，感觉这”人“ 实在是太傻吊了，一股气从心底生成，不骂一句难解心头之气，所以总是要输入几句不文明的用语。虽然跟 AI 发脾气似乎也不会怎么样，但是确也让人的习惯变得不好，还是有必要注意提升自己的修为。

兴之所志 2025-12-20

其他无用

但实际上并没有什么实际的使用场景，因此一致没办法体验这些最先进的AI工具，仅仅只是用Github Copilot看点CSS样式文件，再写点简单的脚本，最近一次《[[说说目前在用的AI大模型产品和工具（2025年9月更新）]]》，直接把Github Copilot放到了“长期未用”的分类中。

这种指挥AI写脚本处理笔记文件的成功，让我第一次直观地体会到了 AI 编程的成功感。于是我开始萌生了一个让AI直接开发一个记账APP和日记APP的想法。

不过所幸今年使用了Obsidian来记录笔记，已经在电脑上存了一堆md文本文件，正好非常适合能够阅读和修改代码文件的AI工具来管理，所以最开始通过看到网上各种吹Claude Code和Gemini CLI可以进行知识库管理的时候，都毫不犹豫地下载下来进行尝试。

给claude code安排的第一个任务是批量总结约30篇新闻报道，当时是通过设置qwen模型连接到claude code，没想到对二三十篇的新闻报道进行总结，最后直接干了800万token，费钱且产出效果还很差。改用有一定免费额度的Gemini cli之后，还是要几百万token，效果也还是不行。然后给Gemini cli安排了另一个更适合自动化的任务，就是批量修改笔记元数据，这个任务Gemini cli倒是完成的很好，但还是要花百万级别的token。

经常听网上新闻报道AI运行起来非常浪费水和电，于是感觉这么简单的任务要用这么多token感觉有些对不起地球母亲，还是感觉很不绿色经济。就忍不住跟网页版Gemini吐槽了一句说，用AI批量改笔记是不是有点浪费啊。Gemini说，确实不合适，直接写个python脚本效率更高，我可以给你代码。我一下子醒悟了，这种任务一个脚本分分钟解决，让AI自己边思考边干确实有点高射炮打蚊子了。

于是就开始了我的AI编程之旅，由于脚本没有那么复杂的业务逻辑，用Gemini写的代码基本就是一写一个准，只要描述清楚需求，基本上Gemini一两分钟就能实现，然后有什么问题基本也是一反馈就立马能够修复，效率非常之高，然后就让 AI 写脚本来批量处理word转md文档、批量修改元数据、批量从链接抓取数据存为md文档，批量抓取md文档发给AI总结等，自动化效果非常之高。