独立赚钱日记：前期工作处理完成后，AI 会极度扩大产出效率

2025-10-31

今天进行主力应用的 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 分钟。

参考

李佶澳的博客

编程基础系统基础关注跟踪

Kubernetes Prometheus 超级账本

独立赚钱日记

独立赚钱日记：前期工作处理完成后，AI 会极度扩大产出效率

2025-10-31

参考

推荐阅读