2026-04-14 10:09
扫码打开虎嗅APP
本文来自微信公众号： caoz的梦呓 ，作者：caoz
先汇报一下，其实我的vibe coding一直有继续，最近没通报是因为希望后续产品有个稳定的发布版本，但是有点遗憾，第一是审核时间变得很长。（可以看出，用AI做App已经是潮流）第二是苹果市场悍然拒绝我的产品上架，说是山寨和重复产品，申诉未果，就只能放在testflight里，不过最近两周一直在外面浪，所以一些修复更新还没处理，所以今天暂时不宣传自己做了什么。主要是很多人会疑惑，AI技术越来越强，对小白越来越友好，那么我们还需要学习vibe coding么，那句话咋说来着，只要你学的不够快，你就发现可以不用学了。
如果我们把vibe coding，或者说AI编程简单理解为提示词工程，如何学习使用合理的提示词，可能真不用学了。
话说回来，有一件事我确实又忽视了，TK教主微博提到了大概这么个意思，学习AI的第一步没那么高深，先能做到正确表达。有时候我们以为是理所当然的基本能力，其实很多人不具备，清晰表达力是学会使用AI的第一步，没有这一步，再好的AI也无法给你真正的帮助。我发现我儿子就有这个问题，他天天有点头疼脑热就用AI搜索，然后每次都说自己得了特别要命的绝症，需要紧急治疗，其实就是他的表达极度夸张，缺乏严谨清晰的描述。
任何时候，沟通能力都是基本功，表达能力和理解力，否则再强大的工具你也利用不起来，在我的文章里，我会默认你有这个基础，这是所有后续建议的前提。
那么现在AI编程很强大了，我们好像真的可以零基础做项目了，是不是意味着任何人都可以轻松的做任何事情了？
也许未来可以，但我觉得时间还有几年。
也许你可以躺着等，等别人把能做的都做了，把能占的坑都占完了，然后你说，现在不用学也能做到了，问题是，这时候你做到了，还有什么价值呢。
就最近这一年，已经明显感觉到，苹果和谷歌的审核周期变长了，审核门槛提高了，背后真相不用猜也知道，都在疯狂发布产品，而且都是AI生成的。
所以，如果你现在选择从入门到放弃，我觉得也可以理解，但是如果你觉得还可以挣扎一下，还有一些想法值得去尝试实现，那么，结合我最近的经验教训，以及和其他人沟通的一些反馈，说一下我的建议。
1，记忆管理仍然有意义。
我其实几个月前在新加坡和某知名创业者就聊过这个话题，目前大模型的记忆管理并不完善，包括所谓持续记忆的chatgpt，实际沟通中也会经常忘记过去的信息。而且随信息量增加这个现象更明显。
编程也存在这个问题，你过往开发的目的，每次改动调整的目标和策略，是否有完整的记忆，实际上很多人开始会有产品文档，但是迭代的时候会丢信息，然后后续开发修复或者增加功能的时候，AI只看代码和当前需求，会错漏很多过往的问题，有时候就会形成很恶心的鬼打墙局面，改了一个新问题，老问题出现了，改了老问题，新问题又回来了。反复在重复问题中转圈。
所以编程的过程中也需要不断更新记忆文件，并且这个文件也不能太大，否则token消耗会爆掉，就需要主索引文档和不同的模块文档，这样才能平衡消耗和记忆保存，你们看到现在很多第三方工具都把解决记忆问题当作核心竞争力，比如爱马仕agent，比如那个好莱坞女影星的开源项目，我最近在星球也一直强调这个。
每次版本迭代和更新的时候，要求AI合理的记录记忆文件，并且记忆文件要合理的进行规划，去重冗余，并且不要用大而全的文件存储一切，方便后续快速对应阅读和处理。这样AI在后续处理的时候，能够做到尽量不伤害过往的成果，不重现过往的错误。
我知道这说起来好像挺平常的，其实我在开发过程中，最怕的就是这个，突然过往的成果被改坏了，或者过往修复过的bug又重现了，很多次，很多很多次。记忆管理，要让AI知道过往。
其实记忆管理也是可维护性的一部分，但不是全部。
有些人就会问，你都用AI编程了，代码你又不改，可维护性不是脱裤子放屁。
这里的可维护性，不是人来维护代码，而是AI维护代码。
AI维护代码，也需要可维护性。
AI修改的代码会越来越庞大，越来越多废弃的部分，此外，复用性不够，类似的功能很多重复编写，那么后续进行版本迭代的时候，它就可能出现各种问题，比如陷入大量冗余代码理解而浪费token，比如因为复用性不够只处理了一部分问题，导致整体展示和业务逻辑不统一，比如会去更新已经废弃的代码而不是正在使用的部分，比如理解代码的过程被废弃逻辑引入歧途，我坦白说，这些比如我都经历过，不是拍脑袋想的。
所以，每次版本更新，都需要让AI在它清醒的时候（刚做完更新，记忆还相对完整），清理掉冗余逻辑，删除废弃代码，提升复用性，类似结构代码归并处理。这样，后续AI自己做新的版本迭代的时候，才能节省token，提升处理效率，以及降低各种恶心事情的发生几率。
AI编程后，我发现有一件事的工作量不但不会少，反而增加了，就是测试。
因为以前很清楚自己修改了什么地方，测试也只着重跟进特定功能和操作流程即可。但是AI编程很多时候不知道它改了啥，特别是当指示约束不够好的时候，它会基于错误的理解去乱改，就很崩溃，有时候你以为它只改了一个小局部，但可能很多想不到的地方也被干扰的面目全非，特别是如果架构设计不清晰的一些vibe coding玩家，更容易遇到这种情况。
所以每次改动都要做各种测试，而且就算如此也经常遇到意想不到的地方出问题了。
所以当设计好需求后，其实是应该设计一个自动测试的测试范例和流程，好消息是，这个可以让AI来做，坏消息是，这个做完了也需要你测试是不是真的好使。
AI自动测试是个非常大的方向，现在应该有不少第三方的工具，不过我坦白，我还没用过，这是我的问题。如果你希望靠个人或小团队打造一个可持续稳定迭代的商业产品，这件事需要重视起来，因为你会发现，当你产品进入不断的反馈迭代优化流程时，这是你70%的工作量。
另外，再度强调，自动测试只能解决功能性测试，也就是功能是否符合设计预期。但不能解决一些所谓体验优化的测试，特别是小游戏这种，比如游戏难度是否合理，游戏卡顿，游戏用户操作的流畅度，交互反馈用户理解是否一致，数值平衡等等，这些仍然需要人来测试。甚至需要深度玩家才能测试出来。
就像我最近搞得AI围棋工具，我真的请了职业棋手参与测试，因为我的水平怎么下都是输，完全测试不了难度分级的效果。
大模型虽好，但是使用成本越发昂贵。
我这里说的本地模型，是指当你产品希望赋予某些AI能力，一种是基于API访问大模型，按照使用付费，另一种是直接嵌入本地模型，在客户端直接跑起来。
但目前，一般手机能力有限，能在手机上跑的本地模型通常能力不强，或者过于消耗资源而无法被手机市场接纳。
比如我本来打算用katago 28B本地版本直接做AI围棋终端，但是连产品提交都不行，只好降级为18B版本，就这样也无法展开参数跑，手机性能毕竟有限。
不过从长远看，第一，本地模型能力正在快速增长；第二，手机算力也在持续增长。所以未来可以乐观一点，基于本地模型的一些AI工具依然会大有可为。
还是前面的案例，即便是katago 18B模型，用低参数去跑，依然可以有准职业棋手的棋力，这是很恐怖的。以前alphago lee版本需要惊人的算力成本来维持其表现力，而现在稍微带高端一点显卡的单机都可以轻松碾压那个版本（katago28B都不需要最高参数，中等参数足够了，手机暂时还不行，但再过几年呢）
本地模型，开源模型，如何部署，如何结合到自己的网站，应用里，都是值得关注的方向，未来几年，在成本效率平衡的考量下，本地模型大有可为。
5，有想法尽量占坑吧。
苹果审核明显更严苛了，谷歌审核周期也逐渐拉长。
所谓占坑，就是某些领域你要尽早塞进你的产品，然后以后慢慢迭代，为什么这么说，苹果拒绝我的AI围棋产品，说是山寨和滥发，其实我能理解，就是现在做AI围棋的太多了，而且katago又是开源引擎，他们代码一审核，好家伙，好多产品都带着这个引擎，而且围棋么，你想想，还能有啥功能，还能长啥样，都是对弈，复盘，识谱这些对吧。这咋创新，几千年了对不对。
以前没那么多人做App，有些相似问题也不大，现在好家伙，几倍十几倍的增长，人家门槛自然水涨船高了。
如果你不早点占坑，以后你做出来的产品，可能上架门槛会更高，可能辛辛苦苦做出来，人家审核说一句，没创新，你就上不了市场。占坑以后才有机会慢慢迭代。
以上，是对不死心，还想继续在这个领域折腾的同学的建议。
最近我发现一个趋势，其实我自己也是，就是很多App或者小程序的开发者，就不是为了赚钱，不是为了做出多成功的产品，是什么呢，自己有需要，市场上也有产品，但是市场上的产品要么就订阅费，要么就弹广告，要么就只能联网才能使用。那现在AI编程那么容易，自己搞一个，就照着主流产品做，但是不收费不弹广告，自己用着舒服就好。我开发的几款产品，先不管别人怎么看，我是真的平时一直在玩，在用的。
想想也是，我要是手机市场的负责人，我也不喜欢这种开发者，这不搅局么。
