Posts
关于 Vibe Coding 的一些经验分享
从一个错题本原型的开发经历，记录 Vibe Coding 从本地功能走向可用产品时遇到的工程与商业问题。
结论先行
最近两三周实践 Vibe Coding 后，我大致有了这样一个结论：当前的大语言模型正在大幅降低编程门槛。只要具备基本的电脑操作和软件使用能力，普通人也可以借助 AI 编写程序，实现自己想要的功能。
不过，这些功能通常只能在本地电脑上运行，或者只能作为一个“能用的工具”供自己直接使用。如果希望把程序部署到服务器上，作为一个持续为客户提供服务、不断迭代和优化的产品，就需要补充更多工程化思维。
进一步说，如果希望通过 AI 独立开发，以 OPC（One Person Company，单人公司）的方式实现商业盈利，那么除了技术实现，还必须考虑完整的商业模式、成本结构、用户需求和市场竞争。
下面以我最近尝试开发的一款错题本小程序为例，分享这段经历中的一些思考。
背景
我的本科专业是电子信息科学与技术，后来获得了工商管理硕士学位。本科毕业后，我曾通过培训机构学习了大约半年到一年的 Java 开发。那时候主流的开发方式还是经典 MVC 架构下的 SSH（Spring、Struts、Hibernate）。
虽然我在工作中没有独立编写代码并上线完整产品的经历，但一直从事 IT 行业，对数据库、中间件、前端和后端都有一定了解，也曾经带领产品、研发和运维团队，从零开始开发过一款产品。
因此，我并不是完全没有技术背景，但也清楚地知道，真正独立完成一款产品，和理解技术概念、管理研发团队，是两件不同的事情。
缘起：为什么开始做错题本
从日本回到成都后，我一直在思考下一阶段的发展方向。从年龄和现实情况来看，我才四十多岁，不可能现在就退休。无论从经济角度还是人生价值角度，我都需要继续工作，并尝试创造新的可能性。
在思考个人项目时，我一直想做一款错题本，帮助使用者积累自己的错题，并通过分析错题发现薄弱环节，逐步提升学习效果。
开始：从想法到原型
有了相对完整的时间后，我开始真正动手开发这个应用。最初的想法是开发一款独立 App。经过和 AI 讨论后，我决定先做成微信小程序，因为当时认为小程序的开发和发布应该会更轻量。
但真正开始实践后，我发现“小程序更轻量”只是表面现象。它的运行环境、接口限制和平台规则，会导致整体实现方式发生较大变化。很多在普通 Web 或 App 中比较直接的做法，在小程序里都需要重新设计。
第一个问题：图片识别与超时
我的基本需求是：
- 拍摄一道错题；
- AI 识别题目内容和解题过程；
- 分析错误的解题方法，判断薄弱点；
- 根据薄弱点生成针对性的错题本；
- 定期推送复习内容，帮助巩固知识。
问题首先出现在图片识别环节。
我最初使用 DeepSeek 进行图片识别。虽然模型具备 Vision 能力，但它并没有针对作业批改和错题分析场景进行专门优化。因此，识别速度和结果都不够稳定：有时很快，有时很慢，甚至会直接报错。
微信小程序默认的请求超时时间是 15 秒。一旦模型处理时间超过这个限制，小程序就会认为请求失败。
这时我遇到了第一个真正的工程化问题：不能让小程序一直等待模型返回结果，而应该把识别过程改成异步任务。
第二个问题：异步架构与云服务
AI 建议我使用异步方式处理图片识别：小程序先上传图片，后端创建识别任务并立即返回任务编号，后台服务异步调用 AI 模型，小程序再通过轮询或回调获取识别结果。
这意味着我需要使用 Serverless 函数或其他后台服务。
一开始，我把小程序后端部署到了微信托管云。但微信托管云并不具备我需要的全部服务能力，因此我又开通了腾讯云服务，用来托管异步识别服务。
好不容易完成了图片上传和异步识别，新的问题又出现了：微信托管云和腾讯云 VPC 之间没有直接打通。小程序只能通过公网访问腾讯云上的服务。要通过公网访问，就需要配置自己的域名和 HTTPS 证书。
域名和证书申请完成后，我发现仍然无法通过 HTTPS 正常访问。进一步排查后才发现，域名必须完成工信部备案。备案过程花了将近一周，而且无法加速，只能等待。同时，备案还要求域名绑定某个腾讯云服务。
最后，我购买了一台腾讯云 CVM，并花了不少精力把原本部署在微信托管云上的服务迁移到腾讯云。完成这些工作后，服务终于可以正常访问了。
第三个问题：模型选择与市场竞争
基础设施和网络问题解决后，我原本以为最核心的问题已经解决了。但实际测试后发现，图片识别效果依然不理想。
这一次，我通过调研发现，问题并不完全出在代码或部署方式上，而是出在模型本身。针对作业批改和错题分析场景，市场上已经有专门优化过的模型。这些模型在题目识别、手写内容理解和作业分析方面，效果明显更好，但需要额外付费。
与此同时，市场上已经存在相对成熟的错题本产品，功能也覆盖了我原本想实现的大部分需求。
综合考虑开发成本、模型调用成本、产品成熟度和市场竞争后，我最终决定停止继续开发自己的错题本小程序，转而使用市场上已经存在的成熟产品。
这并不意味着前面的开发完全没有价值。相反，这段经历让我更清楚地认识到：一个想法能不能做出来，和它是否值得独立做成产品，是两个不同的问题。
小结：需要补上的能力
回顾整个过程，我发现自己在多个方面都还有明显的提升空间：
- 架构设计：需要在项目早期更充分地考虑平台限制、网络边界和异步处理方式；
- 模型选型：不能只看模型是否具备某项能力，还要确认它是否针对具体业务场景进行了优化；
- 部署与运维：本地能运行，并不代表能够稳定地部署到生产环境；
- 成本控制：Token、云服务器、域名、证书和第三方模型服务都会形成持续成本；
- 市场调研：在投入大量开发时间之前，应先确认市场上是否已经存在成熟替代方案；
- 商业模式：如果目标是通过 OPC 方式实现盈利，技术实现只是基础，还需要验证用户需求、获客方式、定价和长期运营能力。
Vibe Coding 可以帮助一个人快速把想法变成原型，但从原型走向真正的产品，还需要工程、产品和商业层面的综合能力。
一点体会：工具要服务于习惯
在尝试 Codex、TUI 等工具之后，我最后还是回到了 VS Code。并不是因为这些新工具不好，而是因为 VS Code 的界面和工作方式更符合我最初学习开发时形成的习惯，也更容易让我保持稳定的工作节奏。
工具本身很重要，但更重要的是找到适合自己的工作方式。对于个人开发者来说，能够持续使用、持续思考和持续迭代，往往比追逐最新工具更加重要。