一个月，纯VibeCoding，全平台云笔记APP



对本文有任何问题，可加我的个人微信询问：kymjs666

引子

起名这东西，AI 比我会。
我做这个云笔记的初衷其实挺简单：找不到一个好用的全平台笔记。
大部分都是鸿蒙不能用；鸿蒙能用的，又不支持私有化存储；能私有化存储的，体验又很差。换了好几个，从 Notion 到 Obsidian 到 Joplin，没一个能完整满足我的需求。
实在没办法，才自己写的。
但这又牵扯出另一个问题：我自己其实已经很久没写”完整的产品”了。 2025年底我研究Transformer源码的时候，发现做 team leader 这么多年以后，我擅长的领域不知不觉从 “怎么写代码” 漂移到了 “怎么排需求、怎么带人”。这种漂移是舒服的，但我隐隐觉得不对。

一个老程序员如果还不会用 AI 写代码，那他大概率要被时代丢下了。
这话听着像公众号标题党，但我是认真说的。我从 2014 年开始写 Android 开源框架，KJFrameForAndroid、TheMVP、TheRouter 到现在还有人star着用。
但说实话，过去两年我打开IDE的次数屈指可数。我花在写技术方案PPT上的时间，比写代码多十倍。
转折发生在2026年初。我装了一台NAS（这个之前写过），本意是搭家庭影院和备份照片。结果看到RAGFlow不需要GPU也能跑，我顺手搭了个AI客服知识库——那个项目从0到1我没写一行代码，全靠提示词。搭完那天我突然想：要不我把这个”找不到好用的全平台笔记”的痛点真做了？
想到就做。我打开Cursor，开了个新项目，第一行提示词是：
“做一个HarmonyOS上的云笔记APP，本地优先，Markdown写作，支持WebDAV同步。”

然后我靠在椅背上，等着看AI怎么回答。

一个月后，它变成了轻羽云笔记。全平台（Android/iOS/HarmonyOS/macOS/Windows/Linux）覆盖、后端Go写的、付费订阅链路也跑通了。我全程没碰过一行代码——不夸张地说，我连git commit都是让AI写的。 这篇文章不是教程，也不是软广，中间讲的每一段都是真实发生的事。我想用一个月的时间，回答一个我自己的问题：AI到底能把一个独立开发者推到哪里？

第1周：脚手架与第一端

第一周的目标很简单：让鸿蒙端能跑起来。
这个目标定得不高，但纯Vibe Coding的第一行提示词就让我吃了亏。
我以为AI对鸿蒙生态已经熟透了，结果它写出来的ArkTS代码看着像那么回事，DevEco Studio一编译就报错——@ohos.net.http的几个属性它都记错版本号了。改了三轮，每次都是换个错误方式报错。我开始怀疑：到底是AI不行，还是我对它的预期太高？

我重新想了一下这事。问题不是AI不行，是我的提示词太”具体”了。
我之前写提示词有个坏习惯，喜欢告诉AI”用什么API、什么结构”。这是写代码的人才有的肌肉记忆——”我清楚底层，我指挥你”。但这种提示词反而把AI绑死了：它只能在你画的圈里选，圈画错了就一起错。
后来我换了种写法。不告诉AI用什么API、什么文件结构，只讲我要什么： “做一个HarmonyOS云笔记。用户能新建一篇笔记，输入Markdown文本，编辑后保存到本地。打开APP能看到所有笔记的列表，点列表项能进编辑页。”

就这么简单。结果AI给我的方案，反而比之前三轮都靠谱：用了@ohos.data.relationalStore做存储，UI用ListContainer，整个数据流清晰到我几乎不用改。
周末的时候，鸿蒙端记事+数据库+列表展示，端到端跑通了。我截图发到群里有朋友问：”这真是一行代码都没手写？”我说真没写，连样式表的颜色值都是让AI挑的。
这时候它还叫”轻羽”，没加”云笔记”三个字。我当时想的是——能不能先把单端做扎实，云同步的事往后放。事实证明，这个保守决定救了我。

第2周：六端扩张

第二周开始，我忍不住了。 单端能用不稀奇。我要的是全平台：Android、iOS、HarmonyOS、macOS、Windows、Linux——一个都不能少。
原因也很直接：我自己就是多设备用户。能把我逼成多手机用户，也只能怪鸿蒙生态太垃圾，手上必须备一个备用机。然后就变成了Mac上写东西、iPhone 跟 Harmony上看、iPad 上改，这种体验不是单端 APP 能给的。
如果轻羽只能跑在鸿蒙上，那它就只能是我给鸿蒙生态做的一个玩具，不是一个真正的产品。

我让 AI 出了一版多端扩张计划。它给的方案是：除了鸿蒙端继续用 ets （HarmonyOS 生态还在早期，Flutter 对鸿蒙的支持也不算稳，索性走原生），其他五端统一用 Flutter 写一套，共享后端 API 和数据库结构。
这套方案听起来合理，但落地的时候出了几个我必须自己决策的坑。

  • 坑一：Flutter多端UI不能直接复制粘贴，但比”原生翻译”好得多。

我第一版让AI照着鸿蒙端的UI逻辑，输出 Flutter 在 Android 和 iOS 上的代码。AI 给的方案是”先按 Material Design 写一版，再用平台适配组件做风格切换”。这种思路比让 AI 直接复制鸿蒙逻辑要聪明——至少不会出现”鸿蒙的翻译腔”。
但实际跑起来，AI给的版本还是有几个我没预料到的问题：
同一个按钮，在 Android 上的 Material Ink 反馈跟手，到了 iOS 上会有 0.2 秒的延迟感。AI的解释是 Flutter 的 GestureRecognizer 在 iOS 端会等系统级手势仲裁。这不是 bug，是设计——但我必须自己决定要不要接受这个”原生味”。

Android 端的 Edge-to-Edge 沉浸式状态栏，Flutter 默认是不开的。
AI 第一版代码打开 APP 能看到状态栏下面有一道白边。这种细节不修，用户一眼就觉得”这APP不专业”。

iOS 的 Cupertino 组件，AI 给的代码能用，但有些 icon 在 Material 和 Cupertino 之间切换时，渲染出来的线条粗细不一致——这是字体回退机制在搞鬼。

最后我跟AI说：”别复制逻辑，每端重新想它的原生交互。” AI 第二版给的方案是：Flutter 端按 Android 走 Material3、iOS/macOS 走 Cupertino、Windows/Linux 走 Fluent 风格，鸿蒙端因为是 ets 原生，跟着 HarmonyOS Design 走——每端的”原生味”才真正出来。

  • 坑二：WebDAV同步冲突，AI的方案有盲区。

本地优先的笔记，多端同时编辑就一定有冲突。AI 第一版给的方案是：时间戳较新者胜出。这听起来没毛病，但有个 1000ms 内的边界问题——两台设备时钟有偏差，或者一端在断网时改了再连网，”较新”这个判断并不总是对的。
我让 AI 加了个 1000ms 的”模糊判定”：时间差在 1 秒以内的版本，视为相同，不做覆盖。这是个细节，但决定了你会不会在某天发现自己的笔记内容神秘丢失。

Flutter 在 Android 上的具体坑：
Flutter 的 HTTP 库 dio 在某些 Android 版本上会出现诡异的 “SSL handshake failed” ——同样的代码，在开发机上是好的，打包到 Android 7 的旧设备上就是连不上 WebDAV。AI 最后定位到是 Android 的网络安全配置默认不允许 cleartext traffic，需要单独写一份 network_security_config.xml，再在 AndroidManifest 里引用。这种”老设备兼容”问题，AI 不踩一遍我根本想不起来。
还好是这些坑之前处理都有经验，直接跟 AI 讲一下思路，让他自己解决了。

Flutter 在 iOS 上的具体坑： iOS 17 之后，App Transport Security（ATS）对 HTTP 请求的限制更严了。AI 第一版直接用 dio 发 HTTP 请求，结果在 iOS 17 的真机上 WebDAV 连不上。最后换成了走 iOS 原生 URLSession，配置了Info.plist 里的 NSAppTransportSecurity 例外，才彻底解决。
这里有一个反直觉的点：Flutter 代码”能跑 “≠” 在 iOS 上能跑”。 你得让 AI 把 Platform Channel 那层打开，用 Swift 写底层。

周末的时候，六端全部跑通了笔记的本地功能——鸿蒙是ets原生，其余五端是 Flutter，代码共享率超过 90%。 同步、冲突、UI、数据库——所有”产品能用”的部分都到位了。

用了一个月，后面几周都是基于原始雏形做扩展。从一个想法到能在六端跑起来的轻羽云笔记。如果你想看成品，可以访问官网 note.kymjs.com。

第3周：账号体系与支付

前两周是”做产品”，第三周开始是”做生意”。
用户系统、订阅、支付——这三个东西我之前在团队里都是交给别人做的，我自己从来没有从0到1搭过。这次让AI生成的第一版方案，我看完后只有一个反应：漏洞百出。

不是AI不行，是这三件事必须有人做产品决策。
多登录的坑：AI把”绑定”和”登录”搞混了。

我需要支持三种登录：微信（覆盖国内）、华为账号（鸿蒙生态）、Apple（iOS和合规要求）。最后坑爹的是，发现微信登录还得 300 块钱认证费，还每年一次。我果断放弃了，我都还没挣到 300 块，就让我花 300 块，开什么玩笑。
AI 第一版给的方案是：用户每次用不同身份登录，就创建一个新账号。这听起来简单，但后果是——我手机上用微信登录、电脑上用 Apple 登录，就变成了两个不同账号，订阅不通用。最后定的方案是：同一个用户的多个身份可以”绑定”到同一个账号，也可以”合并”——合并时把分散的订阅、订单全部迁移过来。这个方案 AI 第二版给得很漂亮，但这个合并的边界是我自己定的。

支付双轨：国内和海外要分开。
国内我接的是支付宝支付。海外 iOS 上架必须用 App Store 内购（IAP），不能用第三方支付绕过苹果抽成。
AI 给的方案是把这两套都接上，看起来没问题——直到第一次 IAP 回调的时候，遇到了一连串我没预料到的问题。
iOS内购（IAP）的坑，比想象的多得多，包括后来 Harmony 端接华为支付也是，一个比一个坑，华为居然还得要线下签协议，什么年代了，只能说这公司要多 SB 有多 SB。
iOS 的内购不像微信支付那样有明确的 API 文档和测试环境。Flutter 要调 iOS 的内购，必须走 Platform Channel，让 AI 写 Swift 代码——这一步 AI 不能完全替我搞定。

Android上架的坑：软著。
这是我自己没踩过、也没想到的坑。Android 上架到国内应用商店（华为、小米、OPPO、vivo、应用宝等）需要软件著作权证书。这东西不是技术问题，是合规问题。
我去中国版权保护中心查了一下流程：需要提交源代码、用户手册、权利归属声明等材料，整个流程走下来至少要两个月。考虑到我一周就要上架，根本等不起。最后找了一家代办机构，600块钱，两周下证，加急费另算。
这个钱花得不冤。但让我印象深刻的不是”代办”这件事本身——而是 AI 在我决定代办之前，根本没提醒我 “Android 上架需要软著”这件事。如果是我一个人摸索，可能要等到上架上不去才知道有这一步。

Vibe Coding最大的盲区，是合规、法律、政策这些”代码之外的东西”。AI 再强，它也不会主动告诉你”你需要办个证”。

第三周结束的时候，账号体系、合并逻辑、订阅、微信支付、IAP、软著——全跑通了。
这个阶段让我对 AI 的能力边界有了很具体的认识：它能给你 90% 的实现，但剩下 10% 的产品判断、合规判断，得你自己来。
如果你想直接体验，下载方式我都放在文末。

第4周：上架、发布、回收

第四周相对轻松，但也最熬人。
六端打包上架，每个商店的审核要点 AI 给的清单八九不离十。鸿蒙 AGC 上架比预想顺利，但是鸿蒙的审核我是真服，来来回回给我打回四五次，然后连个跟他们应用市场的人沟通的渠道都没有，只能你留电话，他们有空了给你回拨。 最折腾的是 iOS，Apple 的审核员对订阅类应用的隐私描述要求细致到变态，AI 给我拟的初版文案被打回两次——理由是”未明确说明订阅自动续费的取消方式”。

软著下证之后，Android 端上架反而是最快的：OPPO、vivo、应用宝商店，只要给的资质清单都有，基本一次过。最麻烦的是应用宝，要单独提供一份”应用自律承诺书”。

上架以后第一周的数据出来了：
装机数六端加起来不算多，但质量不差。
七日留存接近 35%，这个是我没想到的，我还没有做任何推广，只能说笔记这个需求是真实存在的，只是缺一个好应用。
付费转化率大概 3%，付费用户突破 10 位，这个数字在大厂眼里是个笑话。但作为一个独立开发者，这是我过去七年里做过的最完整的”产品-付费”闭环。

更重要的是——AI省下来的时间都去哪了？
按理说，AI让我不写代码，我应该轻松很多。但我花在产品决策上的时间反而更多了。
以前我带团队，最常做的是”评审别人的方案、指出问题”。
现在我直接面对 AI 的输出，没有中间人，每个判断都是我自己做。账号该不该合并、冲突阈值该定多少、隐私文案写什么、订阅档位怎么分——这些以前是产品经理+架构师+法务的活，现在全压在我一个人头上。

这个发现其实有点反直觉：AI 不是让你变轻松，是让你变成一个更完整的”独立开发者”。
你必须自己懂产品、自己懂架构、自己懂商业、自己懂一点法律。AI替你跑了所有的脏活累活，但判断依然在你身上。

收尾

写到这里，按互联网的规矩应该是”感谢阅读，欢迎关注点赞收藏”。但这篇不是公众号推文，是我自己的真实记录。
所以最后这一段留给我的产品——轻羽云笔记。

它是一个全平台的云笔记APP： 支持 Android、iOS、HarmonyOS、macOS、Windows、Linux 六端。
Markdown 写作，所见即所得。
笔记自动云同步，换设备不丢内容。
WebDAV 私有部署，数据完全由你掌控，所有笔记都是 RSA 加密的。
密码也都是加密后记录的，完全杜绝明文传输。
一键生图分享，方便发到社交平台。

至于那个最初的问题——AI 到底能把一个独立开发者推到哪里——我没有答案。
但有一件事是确定的：我终于能在自己的鸿蒙手机上，用上一个让我放心的全平台笔记了。它支持私有化存储，体验也不差。
而这个产品，正好是我自己写的。
顺带，这件事让我重新变成了一个”做产品的人”，而不仅仅是一个”管产品的人”。这个感觉，我以为再也回不来了。
写作过程学到的几件事，提示词的颗粒度比我想的重要——讲”要什么”比讲”怎么实现”好。
AI 能跑 90% 的活，但 10% 的产品判断得自己来。
独立开发的真正难点不是写代码，是一个人背起所有决策。
月级别确实能做一个完整产品，但前提是边界清晰。