独立赚钱日记：通过本号记录独立赚钱的过程

独立赚钱日记 

目录

2025-10-30 序言

从今天起我将通过本号（微信公众号：独立挣钱）记录独立赚钱的过程。

这里“独立”强调的是不以公司职员/打工人的身份赚钱。

当前状态：

  1. 一些必须的准备工作和工具已经完成。比如家庭财务规划、科学上网方法、可以专心工作的场所、顺手的开发设备、免费或起步成本低廉的计算资源等等。这里不具体表述。

  2. 用 AI 生成的几个工具网页上线一段时间，正观察在没有外链情况下的搜索效果，之后会判断是否深入建设其中的某个工具。这项工作用闲暇时间处理，主要用来进行项目储备以及做实验。

  3. 用 AI 完成了一个特别简单的 APP。目的是熟悉 app store 和 google play 的应用上架操作。app store 前期准备已经搞定，就等待备案号出来后提交。google play 竟然被华为手机卡壳了，还没完成真实设备认证。感觉应该淘个装载原生 andorid 系统的手机。

  4. 确定了一个要全力开发的应用。这个应用比较有意思，我感觉非常值得试一下。借助 AI 完成了页面和交互设计，最基础的 API 定义也完成了，今天开始编码。

技术上不复杂，只是我没有对应技术栈的开发经验，进度比较慢。通过这个应用摸透对应技术栈也是计划的一部分。幸好有 AI 帮我解决了两个大难题：

  1. 完成产品原型从 0 到 1 的设计并且颇具美感。现阶段的我无法从 0 到 1 画出产品图，最多有个朦胧的概念。AI 把我脑中朦胧的概念呈现了出来，在AI 的基础上修正就要简单多了。

  2. 辅助技术选型决策。由于缺少相关技术栈的实战经验，在架构设计甚至 API 设计上有很多很多的疑问。AI 解答了我的疑问，印证了我的怀疑，并且给我灌输了很多很多的方案和其中缘由。受益匪浅！

如果没有 AI，我大概率不敢尝试独立赚钱。

2025-10-31 前期工作处理完成后，AI 会极度扩大产出效率

今天进行主力应用的 API 开发，进度比预先的要慢。

昨天把 API 设计文档敲定并且生成第一个接口的代码和测试用例后，本来以为今天可以用 AI 很快的完成其他 API 的编码工作。结果是今天才把昨天的接口彻底完成，然后初步完成了另外两个实现上非常相似的接口。

预期之外的时间主要耗费在代码的管理和 API 设计调整上。

昨天的接口初步完成后，我在和 gemini 讨论数据库表具体设计的时候，发现 gemini 给出的设计中多了一个 bucket name 字段。我有点奇怪为什么要有这个字段，不是一个 bucket 就可以了么？一追问就引发了更多问题。反正最后我认可了 gemini 的方案，我的应用场景中使用多个 bucket 确实更安全，后期更不容易出问题。

今天按照多 bucket 思路进行代码调整，又出现代码管理的工程问题。之前是单个 bucket，直接用默认 bucket 即可。现在是多个 bucket，显然不应该把 bucket name 写在各个地方。需要一个集中配置管理，又是一通交流+调整。

接着开发后续接口又发现 API 设计存在的隐患，和 gemini 交流后确定隐患存在，应该用更安全的方案。落实调整的时又产生新的疑问：js 项目中是否需要创建和表结构对应的结构化定义呢？和 gemini 交流后确认需要，又进行了一些调整。

归根到底是两个原因：

第一个是API 等技术方案设计不够熟练，没有做出一个不再需要调整的设计,而是在开发过程才发现存在的问题。相关的业务架构经验不足。

第二个是对 js 的项目没经验。如果是熟悉技术的栈，配置管理/Orm定义/错误处理等工程上的问题都是标准化操作。换到 js 技术栈，我只能先让 ai 生成的基本代码目录结构，然后摸索应该怎么管理，耗费了不少时间。

不过话又说回来了，也是因为我现在对工程质量要求高了，毕竟是自己要长期维护的项目代码，而且是从零开始，不能给自己挖屎坑。幸好朦朦胧胧的知道高质量的工程应该是什么样子的，能够产生疑问然后借助 AI 进一步明确。曾经在特别大的互联网公司待过，接触了一些代码，我只能说那简直是误人子弟。

明天进度应该会加快很多。

前期工作处理完成后，AI 会极度扩大产出效率，今天实现的最后一个接口实际耗费不到 10 分钟。

2025-11-01 主力应用开发开始进入关键部分

正如上个工作日预计的，今日 AI 编程的进度大大加速。代码生成之后，主要做了下风格的调整，比如把一些处理逻辑拆分到独立函数中，避免主流程函数代码过长不方便阅读和管理的问题等等。很快就进入关键部分：一个使用到 AI 能力的核心功能。

关键部分的实现比预想的要简单和快速，主要是因为 Google Firebase 服务实在是太给力了！异步流程中需要的消息队列可以说开箱即用，太方便了。和 AI 的对接也相当无缝，直接导入 sdk 调用即可。预计明天就能完成核心 API 的实现。

Cursor 以及之前用 Gemini-cli 生成的设计方案和项目代码，经常有不符合我的习惯和规范的地方。我做不到把自己的习惯全部列举出来一次性告知模型，只能在模型产出的基础上反复对话调教。这让我突然意识到，如果 Cursor 能通过我和它的对话历史，记住了我的很多小习惯，岂不是就能和我配合的越来越流畅，继而让我没有更换其它 AI 编程工具的意图？

不确定 Curosr 现在是否具有这个能力，而我又不想在以后的新项目或者换用其他 AI 编程工具的时候再来一轮反复调教过程，要怎么办？突然就想到了一个特别简单的点子：让 cursor 基于过往的对话生成一份规范文档。

AI 编程工具处于大发展阶段，我目前只用过出名较早的 Cursor、Gemini-ci、Copliot。这个领域中肯定有不少我还没有用过的功能特性，或许有更好的解决办法。但生成规范文档就能满足我当下的需求了。研究工具能力是磨刀，磨刀不误砍柴功的前提是没有忘记砍柴是主要任务。

2025-11-04 常规操作接口用 AI 一把过

最小化产品需要的服务端接口的和单元测试的编码基本完成。与 AI 交互以及异步流程相关的代码的单元测试延后补充，感觉这部分 AI 生成的代码有可能在实际部署时出现和真实环境不匹配的问题，没有必要现在就完成单元测试。

其它的一些常规操作接口几乎是用 AI 一把搞定。Cursor 的能力提升了不少。刚开始使用 Cursor 的时候，经常遇到“擅自修改”的问题。让 Cursor 修改或实现某个能力，它会莫名其妙地把不需要改动的地方也改了。最近的使用中没有遇到这个问题，也可能是因为我现在会看 AI 生成的每一行代码，下的指令更精确。

常规增删改查接口用 AI 实现的效率和准确性都非常高。不再需要噼里啪啦地敲类似代码。单元测试代码生成也非常惊艳，即使是非常熟悉的技术栈，实现同样覆盖率的单元测试代码，一个接口至少需要半小时甚至更多的时间。如果心情不好产生厌烦情绪，半天都写不了几行……

现在十几个常规接口和单元测试的编码一起生成只需要几分钟，花费一点时间查看 AI 的实现即可。AI 扎扎实实提高了程序员的工作效率，也将切实压缩程序员的岗位数量。我感觉可以压缩 20%～30% 的岗位，熟练的程序员不需要招初级程序员给自己打下手，AI 的代码质量和响应速度碾压只能按照他人设定的方案进行编码的程序员。

有了 AI，我可以把更大比例时间用于思考关键问题。

不过不是所有的公司都能够通过 AI 把总费用压缩到很低，或者让所有的事情突然流畅起来。不如先看看在编码之外的环节有没有做到位，看看对程序员的时间是利用居多还是浪费居多。仔细算算账或许会发现有效的编码费用占比微乎其微，折腾导致的浪费才是大头。

2025-11-05 身体不适，什么都没有做…

今天一整天什么都没做。上午外出处理家庭事务，中午回来后感到身体不适。唉，明天后天还有家里的事情要处理。这三天都要无进度，最多在脑海里琢磨下未来的计划。

更年轻的时候有大把可以自由支配的时间，既无压力也无负担。然而没有方向也没有 ai 辅助，东瞅西看没能利用业余时间做出什么产品。现在有方向又有 ai 助力，却进入上有老下有小的阶段，最近又赶上家里有一些事务。眼下这些事务赶紧过去吧！

自由的时间和方向哪个更重要？方向更重要。之前想学习一些展示端的技术，由于不知道自己想呈现出什么，每次都是浅尝辄止。确切知道自己想要什么更重要。

类似的表达方式还有：能提出问题更重要。不精确地讲，只要知道了问题就知道了答案。因为可以不停地追问为什么解决不了。提出一系列问题就好像把洋葱一层层剥掉，最终一定能找到一个可以解决或解释的内核。

ai 把人类的知识更高强度压缩之后，提出问题的能力更加重要了！

2025-11-14 回归正常节奏

上周四、周五、本周前四天都在带娃。和广场的上大爷大妈们凑堆的时候，内心非常惆怅，如果以后要一直这样带娃，天天和奶瓶纸尿裤为伴，每天陪着孩子在外面铲土，后半生都要结束的感觉……好在只是临时几天。

今日回归正常节奏，开始客户端的开发。web/ios/android，哪个优先？使用原生还是 flutter 之类的跨平台方案？在这两个问题上纠结了好一阵。最后决定还是暂时不用跨平台方案，做原生应用。主要理由如下：

  1. 应用目前比较简单，开发原生应用的代价不高，尤其是主要依赖 AI 开发
  2. 相比 flutter 之类的跨平台方案，我更需要先了解 ios/adnroid 的原生形态，不能在对原生形态一无所知的情况下就进入跨平台的坑

相关技术经验的缺失，严重拖累产出速度。没有什么好的办法，未做的功课就是要补上。

2025-11-17 ios客户端开发中

今天的进展只有一点点：用 AI 直接生成了第一版 ios 客户端，然后阅读了解生成的代码。后面要花不少时间细细调整。

代码量没有太多，即使将来增加更多功能，感觉也不需要太多代码。ios app 开发用的 switfUI 以及 android 开发中用的类似技术，大大降低了开发成本。感觉展示端的开发技术都在趋同，代码越来越精简，一个页面代码没有多少。

今天进度不多是因为在两个事情上浪费了时间。

上午办理社保相关手续花费了一小半的时间。

下午去退订衣柜，本来以为几分钟的事情，毕竟还在他家定好了全套的橱柜，无论怎么样也会做成我的一笔生意。没想到竟然遇到一个傻帽老板，一听要来退衣柜，整张脸都臭不可闻，全然忘了我还是他另一个单子的客户。浪费了大半个下午事情还悬而未决，然后又查询了一些资料，对橱柜的板材也开始越发没有信心了。

装修材料的选择真是没法深入追究，一深入进去看到的都是让人心里犯嘀咕的信息。特别是像橱柜衣柜这种需要定制的东西，使用的材料要么没有形成家喻户晓的品牌，要么很难验证真假，价格也都是稀里糊涂的。挂着大牌子的门店，细细一查大概率就是个授权/代理店，个人独资的小企业实在让人不放心。

如果那个傻帽老板痛痛快快的给处理，我大概也不会犯嘀咕了。这下倒好，反而查处了他就是个人独资的小企业，衣柜是铁定不要了，对橱柜也完全丧失信心。

装修赶紧完结吧，完结吧！时间太宝贵了！

2025-11-18 今日无进展，处理恶心事

今天没进展，上午处理事情，下午又用了一下午处理昨天遇到的傻帽老板的事情。下午处理的结果不估算完美，但是当前只能先这样，先忍一时把主动权拿回来，然后再说！

明天要专心、高效率的工作～

2025-11-19 只通过语言生成可用的 app 还是不太可行

今日主要是调整 cursor 生成的 ios app 代码，细节问题不少。

通过提示词直接生成需要连接后台的 app 目前还是不太可行，特别是有非常具体的预期的时候。新发布的 gemini3 pro 似乎也不能直接完成完整的 app。在 cursor 中指定 Gemini 3 pro，然后同样的提示词重新生成了一个 ios 代码，不如之前用 cursor auto 模式生成的。

网上传播的各种模型的很惊艳的编程效果，似乎是在没有特别具体的预期，完全让 ai 自由发挥时获得的。如果预期再具体一些，就会有好多需要反复调整的地方。

阅读代码并且不停调整的过程目前还是必须的。

AI 编程对我而言主要解决了两个问题：一）是代码从 0 到 1 的生成；二）编码方式从直接敲代码变成了写文字。

2025-11-20 可能误会 gemini3-pro

今天主要还是一边学习 cursor 生成的 swift 代码，一边调整。

耗费时间最多的是其中一个页面的布局。很简单一个页面，但是总感觉有不理想的地方。反反复复调整，从方式 A 调整到 方式 B 又重新调整回方式 A 等。中途一度焦虑进度太慢，想先跳过这个问题，但是心里总感觉别扭，非要在这里花费时间磨。最后好歹确定了一种感觉舒适一些的做法。

再次暴露了缺乏相关经验的弱点，如果以前做过类似的交互设计，就不需要在这里踟蹰好久。

用 cursor 生成的登录认证没有一次性通过，感觉 cursor 似乎在往更麻烦的方向走。心里犯嘀咕，如果用 gemini3-pro 效果会不会更好，之前在 cursor 中指定 gemini3-pro，会不会没有把它的能力发挥出来？最好用 google 自家的 gemini-cli 试下。

现在我正在用 gemini-cli 执行同样的任务。任务还没结束，但是通过中间过程，隐隐感觉 gemini-cli 在 gemini3 pro 模型的加持下，输出的 ios app 的完成度很有可能超过 cursor !昨天说在 cursor 指定 gemini3-pro 模型，生成的 ios app 不如 cursor 默认情况下生成的，可能误会了 gemini3-pro 了。

任务还在执行，明天补充具体结果。

google 推出 ide 还没有尝试，也要早点试一下，如果效果能超出 cursor 很多，后续就可以节省大量时间！网上有人说有些老的 Google 账号地区认证未通过，希望我不会遇到这个问题。对抗引发的隔离真是挺讨厌的。

2025-11-21 继续用 cursor

今天分别在 gemini-cli 和 antigravity 中使用 gemini 3 pro 从产品原型生成 ios app。

昨天预感 gemini-cli 会给出更好的效果，实际结果相比 cursor 没有明显的提升，甚至有不足。用 antigravity 生成的结果也不如 cursor 理想。

我现在有明确的产品原型，指示 ai 按照原型完成 app 开发。初始条件和预期结果都非常明确，正好能够对比各家的产出效果。目前用的几个，体感还是 cursor 更好。

一个 ai 编程工具的产出效果有显著突破时，我才会考虑换用。

我这种类型用户的黏性是很强的。

获得了先发优势的 cursor 只要保证水平不严重落后，用户就会非常稳定！

今天一边处理前几天建材问题的曝光和投诉，一边试用 gemini3 pro 的 gemini-cli。折腾了好一阵才发现 gemini3 压根没启用，需要到 setting 里设置才可以，引发的问题继而导致浪费了不少时间。不过把 gemini-cli 和 vertext ai 的对接跑通了，以后不受用量限制了。

主线任务推进了一点。前期总是慢的，因为有各种各样的环境、不熟悉的问题。把这些问题逐渐解决之后，后面就越来越快。我感觉下周会有快速的推进。装修遇到的糟心事也告一段落，不用分出精力了。

2025-11-26 旷工两天

前天、昨天旷工两天，今天才上岗。

进度和上周五预计的差不多，克服一个个小障碍后，进展越来越顺。主应用开发今天没啥可说的，就是常规地调试。

旷工的两天是处理房子装修的事情，选个全屋的插座就花费了很大功夫。赶紧折腾了两天，把心思都腾出来干正事。

同时处理态度恶劣的商家的事情，也就是网上发个帖，12345投诉。这个事情太屈辱了，屈辱到我都不好意思说，嫌丢人……

这个破事挺闹心，但让我隐隐看到这个行当中正在发生的一种经营方式。商家对我态度恶劣，除了个人性格问题之外，他们看人时意味深长的眼神分明是在告诉我他们正在小心提防某种东西。

一个网友的评论让我明白了他们在提防什么。这个行当主流的经营模式中中的利润的分配方式，让消费者额外花了很多钱。似乎可以做点事情，但仔细一想又有点困难，信任和保障太难了。

这门行当一定会被有口碑的大公司吃掉大部分市场。这里面还有没有个人可以起步的机会呢？放脑子里慢慢琢磨～～

2025-11-28 主要功能调通

昨天漏写日记。

昨天和今天继续调试，本以为会有波折的 AI 对接调试，很快就对接完成，没有出现消耗掉大量时间的障碍。感谢 Google 的基建～

主要操作链路已经调通，但是交互还有需要继续考虑的地方。APP 还需要在减少网络请求等各个方面进行优化。两眼摸黑的时刻成功度过，虽然还有优化、发布、收款、推广等一系列事情，但最大风险已经消除。

脑海中的点子就好比一粒种子，把点子落地的过程如同培育种子。我付出各种代价落地这个点子，最怕它不成熟、无法发芽。现在最大风险消除，剩下的就是专心成长，心里踏实多了～

日记有时候想写的内容较多，占用的时间比较长。有时候则是没有太多可写的，寥寥数语不值得的发。后续要不要只发关键节点？

2025-12-01 想清楚所处的阶段，答案就清晰了

今天开始继续调整 app 的 UI 和交互过程。平常使用各种 app 的时候没有啥特别感觉，直到自己要做一个 app 的时候，才发现每个页面都要经过深思熟虑。

有一些设计方式可以参考成熟 app 的做法，比如 profile、底部导航等。但是不能全部照抄，不同的 app 提供的服务不一样，展示和交互的侧重是不同的。有的把发布按钮放在底部导航正中心的位置，有的则放在屏幕右上角，不一样的位置背后是不一样的意图。

facebook/ig/youtube/x 底部导航栏,有的是只有 icon，有的是 icon 下方带有文字。我要做的这个 app 应该学习谁的做法？纠结了好一阵，才恍然大悟！

我要做的这个app 的核心动作是跳转到一个功能页面。不是拍摄发布，是 app 自身独有的一种动作。这种独有的动作是无法用一个 icon 就让用户明白的！所以我的这个 app 底部导航必须用 icon + text 的方式～

把 app 自身的功能、想要着重前调的事项等一条一条列出来，列的过程中各种元素的排布思路就逐渐清晰了。比如登录页是打开app的时候就弹出，还是某个时候触发。想清楚自己所处的阶段，答案就清晰了。

当然最难受的时候还会有。有几个元素都是需要的，但是展示空间有限，迟迟想不出协调的办法。这是最痛苦的时候，只能从其它 app 的交互设计中找灵感～

2025-12-02 调整UI和交互

如题

2025-12-03 继续调衡

UI 交互的调整简直是没有止境，不停地发现不理想的地方，不停地调整。之前用 gemini 生成了一个版本的原型，反复调整好多次以后感觉挺不错了。但是实际做成 app 一运行，发现还有各种各样的需要调整的地方。。

已经脑海汇总尝试、推翻、再推翻，折腾了好多个版本。 UI和交互设计师的工作不简单～～

2025-12-08 AI效果不好

每天写日志占用的时间有点多，后续改成记录重要节点。

过去几天一直在调整给 ai 的提示词，试了多种思路，在每种思路中都反复调整始终没有办法得到准确的结果。而且在我的场景下 gemini3 的结果不如 gemini2.5 ……

必须放弃做一个「准确」应用的想法了！

失去准确性，用户反复使用的概率应该会大大降低，没有持续壮大的可能。不得不在用户第一次接触的时候就触发付费，这就成了另一种玩法。

当初急于熟悉流程，对 ai 效果验证有点草率，没有进行更多试验以及更细致地观察。现有的模型服务达不到预期效果，我又没有时间和资源在这个细分场景中训练模型。无奈。

好在功夫不是全部白费，「熟悉整套流程」的初衷是能完成的，app 本身还有一定价值。接下来要用最小的投入把开发、推广完整流程跑通，尽可能获得正的收入。未来或许能遇到更好的模型，或者找到大力投入的依据。

上周五意识到这个主力 app 因为 ai 能力限制难成气候后，压力陡增。压力之中萌发了一个新的想法。对于这个新的想法要进行更仔细地调研、思索。熟悉流程已经不再是目标之一，少了这个执念以后更纯粹更聚焦。

参考

  1. 李佶澳的博客
编程基础  系统基础  关注跟踪 
Kubernetes  Prometheus  超级账本 


独立赚钱日记

  1. 独立赚钱日记：通过本号记录独立赚钱的过程

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接，合作请加微信lijiaocn或者发送邮件: [email protected]，备注网站合作

友情链接:  Some Online Tools Develop by Me  系统软件  程序语言  运营经验  水库文集  网络课程  微信网文