记一个小程序的诞生与死亡

这一切都来自一个幼稚的想法

有一天，写读书笔记的时候突然冒出一个想法：能不能搞一个小程序大家一起写读书笔记，而且还要能多人同时编辑同一篇笔记。

重复造轮子

首先，现在的一些在线文档软件已经完全能够满足我的需求了。比如有道云笔记，石墨文档，wps在线文档。但我们人这个物种的一种劣根性就在于，“明知道是坑，还是要踩一踩”。一种莫名的虚荣心摄住了我。显然“来，书友。我们一起用我写的一个小程序写读书笔记吧”比“来，书友，我们一起用有道云笔记写读书笔记吧”要更有优越感。虽然，对于一个不会写代码的普通人，我预想了过程中可能遇到的困难很多。但主意已定，牛犊必须上路。

那么就开干吧

准备工作

工具：

1. AI写代码的工具
   1. 通义灵码
   2. cursor
2. 平台
   1. 微信公众平台
   2. 微信开发者工具
3. 学习资料
   1. 一本小程序开发的书籍
   2. 一套B站的学习视频

在AI编程工具的选择上，因为之前用通义灵码写过一个给女儿出口算题的应用。虽然灵码这一类的IDE插件在处理单个文件的代码编写工作已经游刃有余，但对于一个项目。如果还是用它的话，显然有点麻烦，所以我转向了另一个著名工具cursor（套壳VScode的一款带AI助手的集成开发环境）。cursor的强大之处在于能够完全将AI的建议应用到文件、文件夹的创建、删除、命令行的自动自行等，不像灵码需要自己手动做这些事。注册cursor的时候还有点曲折，开始用QQ邮箱，能收到邮件，但是看不到验证码。后来换了163的邮箱，一天都没收到验证码（第二天收到了），我以为必须要国外的邮箱，然而，我却没有。本来都准备放弃了，突然想到能不能搞个微软的outlook的邮箱试试。结果成了。

在平台选择上，我先思考了我到底想做一个哪个平台的应用？

电脑端？手机端？从便捷性上考虑，我选择了手机端。

app？或者web app？或者基于某个平台的mini program？

考虑到服务器，数据库，两方面的知识的薄弱，我最终选择了微信小程序。然后就是工具的下载，小程序账号注册的琐事。

然后是看书、看视频、小程序的开发文档学习,了解到微信小程序的技术栈主要是

• 前端:HTML\JavaScript\Css  虽然微信的叫法有点不一样  分别是JS/wxml/wxss

        js：负责页面的逻辑，wxml负责页面的元素，wxss负责页面的样式。之前对前端的技术看过一点，虽然写不出，可不是有AI吗。

• 后端：Node.js 这个就不太熟悉了。js的一个运行时，负责对前端传来的数据进行处理。比如操作数据库存取相关数据

开干

建立项目，这里有两种方法，一种是现在微信开发者工具创建项目，这会快速创建一个项目的框架

其中比较重要的是：

• pages  ： 所有页面的管理
• cloudfuctions：后端操作数据的云函数所在的文件夹
• 所有的json文件：配置文件，分为不同的级别
  • project级别，整个项目的配置
  • page级别，每一个页面的配置

另一种方式是直接在cursor让它帮我们创建一个目录结构

结果：

所以还是第一种方法更好。直接让cursor写的话，它会漏掉一些文件。虽然可以多次对话让他补齐，就是有点麻烦。

第一个版本

然后就是和AI的各种拉扯了。

我最初的思路是先写页面，让就在来考虑逻辑。
经过多轮对话，写出了下面的页面

这个过程中，主要是去找各种图标文件，然后代码让AI自己写，图标文件使用的是iconfont-阿里巴巴矢量图标库

富文本组件：第一个大坑

接下来是实现核心功能模块：富文本组件，用于笔记的创建编辑等，开始的想法是告诉AI使用一款第三方组件，AI推荐了一个npm包-vant。由于对node.js不太懂，这个过程中各种报错，正要是命令npm命令执行失败相关的。反复喂给AI错误提示还是不行，我猜npm应该和pip差不多。最后通过查资料，安装node.js终于解决。

Node.js — 在任何地方运行 JavaScript

然后开始各种编辑器按钮的规划。这个过程很费时间。

然后遇到各种bug，改不过来。

第一个版本失败。

第二个版本

一切从头开始，再好好地看了小程序开发文档，发现小程序有原生的编辑器组件editor。结合上次失败的经验，不再先做页面。直接开始和AI对话，要求使用editor组件开发富文本编辑器。结合自己使用笔记软件的经历，像尽量做到简洁，好用。

最后选择了以下功能。

本来考虑到作为写读书笔记的软件，引用的使用场景较多，但是多次尝试未果就放弃了。

书籍API：第二个大坑

因为是读书笔记，所以想要通过API获取书籍的一些数据，如书名、作者等，最开始像能使用微信读书最好了，结果微信没有开放API，然后就想考虑找个开源的书籍API吧，把需求告诉了AI，给我推荐了Open Library API。然后开始book页面开发工作。然后，如你所想，对这个api的陌生有一次成为了无法跨越的拦路虎。各种bug，获取不到数据。

接着我就想，先妥协吧，读书笔记。没书，先把笔记搞出来吧。

第三个版本

因为砍掉了书籍相关的功能，但是我发现让cursor创建文件，它很在行，但是要删除已有的一些功能的时候，总是会残留，然后自己手动删，结果又删错。所以又直接开始一个新的版本。

这次我考虑借鉴一些自己使用的笔记软件：小米笔记，锤子便签

简化页面布局，先将笔记的核心功能做出来

云函数：第三个大坑

要实现笔记的保存就必须先实现用户登陆，以及后台数据库。第一次使用云开发的时候。各种懵。

然后还犯了一个禁忌，我先让AI写了所有可能需要的云函数。而不是写一个，调试一个。

最后它写了十几个云函数。我完全不知道是干嘛的。所以期间，又重头再来了一次。

这期间一个朋友说要来一起开发，所以中途又去学了git相关的知识，搞半天弄到了gitee上的一个代码仓库上。后来辗转发现微信云后台有一个代码仓库。气哭！

bookinkHarmony: 多人在线合作编辑读书笔记微信小程序

不断改各种bug后，终于在改了6版后，提交了体验版。

最终效果

死亡来得太快

10块钱的广告费

开发完成，第一件事是想找人试用，于是跑到一个读书群打广告，一个群管理出来说我得发红包，好吧，发个10块钱的，找了10个体验者，然后体验者提了一些bug，继续修改。

改到1.1.0时，我准备让他上线了。

先是备案，然后提交审核。

然后就没有然后了

就是说你得注册一个公司，才能继续搞！好家伙。这就成了我无法跨越的困难了。

转念一想，也对。用户生成内容，保不齐谁发点奇怪言论，谁负责呢？个人开发者是负不起的！

总结

• 虽然死的快，起码还是完整体验了一个小程序的完整流程，不说学到什么，起码学会了：技术问题一直都不是问题
• AI编程：
  • 大模型真的没有记忆能力，所以你必须每次都给它提供完整的上下文，虽然cursor有@codebase，但实测它有时还是会抽风。比如目录中明明有noticefication-manager处理通知相关云函数。过程中它又给我搞出一个noticefication-operate。处理相同的逻辑。我删除一个，发现关联的又不对。再比如我让它在整个项目过程中维护一个development.md的开发文档。如果不每次对话都加上这句话那它很快就不给你干这活儿了。
  • 同样的问题换不同的问法可能有用
  • 解决其中一个困扰了我很久的bug的时候，我让它加了很多console.log语句来追踪某个对象的生命周期，然后发给它日志。终于才解决了，是一个对象加载次序造成的。
  • 也就是说，AI几乎不会犯语法错误，但逻辑错误不可避免。
    • 一方面可能是大模型对你的prompt的理解，和你想要的效果之间的分歧。
    • 另一方面也可能是你的prompt和你的思想之间的分歧。简单来说就是没想明白
  • 用AI生成代码so easy，但是debug很费时
  • 用一个Up主的话说就是：
    • 人的作用：产品经理、架构师、测试员
    • AI 的作用：程序员

总之，这就是从一个想法到实现的过程，是的，我们生活在一个AI时代，用凯文·凯利的话说：技术，带来的是一种可能性。