我用AI 编程做出万人付费的英语产品，你也可以

哈罗，大家好，我是涛哥，之前在一家上市公司做了五年后端开发，2025 年 9 月离职，开始全职用 AI 做自己的产品。

这一年，我做了一套英语学习和资料库平台。学习者可以在里面逐句精听、循环播放、录音跟读，内容博主可以制作自己的资料库，发布、售卖，再交付给学员。

图 1｜产品学习页实图：视频、逐句字幕、重点词汇和播放控制集中在同一个页面。

产品设计、开发、部署、维护，包括推广和客服，基本都是我一个人在做。

截至 2026 年 9 月复盘时，平台注册用户约 1.1 万，付费用户占比约 85%，已经接近万人付费的规模。这里的用户包括平台上各个博主服务的学习者，并非全都是我自己直接卖出去的客户。

如果你想体验试试，可以点击 第一期体验地址 。

这次我想把其中 AI 编程的部分展开讲一讲：一个后端程序员，怎么借助 AI 把前端、设计、后台、内容制作和上线交付都做出来？中间哪些步骤值得照着做，哪些地方又必须自己花时间？

早期我用过 Claude Code，后续大量开发和迭代用的是 Codex。这篇会结合我实际做过的项目来讲，方法可以迁移到你自己的工具和产品里。

一、先找到一个具体麻烦，再决定开发什么

我最早做的，其实是一个参加破局黑客松的英语口语网站。

当时想到这个方向，是因为我自己练过口语。用美剧片段跟读，一句话没听清，就得暂停、拖进度条；想跟着说两遍，视频又已经播到下一句。练不了多久，光操作播放器就很烦。

所以我给第一个版本定的核心目标很具体：让用户能控制每一句台词的播放和跟读间隔。

围绕这个目标，我用 AI 做了需求整理、原型、后端和前端。开发加上线花了三天，另外还花了一两天整理音频和文本素材，最后在黑客松拿了第四名。

图 2｜早期美剧口语网站的播放页面，已经有逐句播放和播放列表，后来才逐步发展成资料库平台。

我把开发过程写成公众号文章，来了不少读者。其中一个小红书博主找我，想让我帮他开发影子跟读资料库网站，还发来了一个竞品。

当时报价两三万元，他预算只有一两千，没谈成。

但我继续研究了他发来的店铺，看到那个商品上架几个月，已经卖了六千多份。我就在想，这类博主有内容、有销售渠道，但承担不起单独开发一个网站的成本。那我能不能把共同需要的能力做成平台，租给他们用？

我负责技术和制作工具，他们负责内容和销售。这样，同一套程序就能服务多个博主。

我把想法跟他说，他表示做出来愿意第一个付费。后面才有了现在这个产品。

这段经历对我影响很大。把用户的麻烦说具体，后面的需求文档才有依据。“做一个英语学习平台”太大了，换成“学员反复拖进度条”“博主不会把视频做成可交付的资料库”，开发要解决什么就清楚多了。

不过，竞品卖得好、一个人表示愿意买，都只是值得继续验证的信号。自己的产品有没有人买，还得做出来、卖出去才知道。

我也是分阶段验证的。2025 年 11 月开始集中开发，二十多天做出第一版，先卖自己制作的英语资料库。2026 年 1 月初租户系统上线，才逐步让其他博主入驻。今天看到的完整平台，是后面持续迭代出来的。

二、我的开发顺序：先把前一步的结果，变成后一步的输入

我做这套产品时，主要沿着这样一条线往下走：

竞品分析 → 需求文档 → 页面原型 → 数据库设计 → 后端接口 → 接口文档 → 前端实现 → 使用和修复 → 部署上线。

每一步都会留下文件。这样下一步开始时，AI 能读到前面已经确定的东西，我自己也能检查有没有跑偏。

1. 竞品分析，要记录操作过程

当时我用即时设计整理竞品页面，一边实际使用，一边记录页面的功能、交互，以及好用和不好用的地方。

比如学习页，记录到“有视频、有字幕”还不够。还要看：点击某一句字幕，视频会不会跳过去？当前播放句有没有高亮？控制按钮放在哪里？视频和字幕在手机上怎么排？

这些内容整理好，再交给 AI 讨论需求，就有了具体参照。

而且竞品只能帮我了解它公开的部分。像博主的后台管理、内容制作流程，我看不到，就需要根据自己的业务重新设计。

2. 需求文档，要把不同角色的事情分清楚

我的产品至少有三类使用场景：学习者来练口语，博主管理和交付资料库，内容制作者处理视频、字幕和词汇。同一个人可能兼任后两种角色，但页面承担的事情不同。

如果只告诉 AI“做一个资料库系统”，它很容易列出一长串功能。我会继续和它聊：哪些功能属于学习端，哪些属于后台，哪些在制作内容时才需要；哪些现在就做，哪些可以往后放。

AI 给出方案以后，我会检查里面哪些是多余的、哪些缺了，再让它修改。讨论完，再整理出一份完整的需求文档。

这一步我自己必须参与。因为 AI 可以补充选项，但这个版本到底服务谁、做到什么程度，最后还是我来决定。

3. 原型出来以后，回头检查需求

文字读起来没问题，不代表页面摆出来也合理。

我会让 AI 根据需求生成页面原型，先看区域划分、按钮位置、信息量和使用入口。原型阶段不必把真实业务都接好，但你得能看出来用户进来以后做什么。

比如学习页需要视频、字幕、重点词汇和控制区，电脑上放得下，手机上怎么处理？有一个后台配置项，但用户从哪里进入？这些问题看到页面后会更直观。

发现问题，就回去补需求，再调整原型。这个来回花的时间，能省掉后面不少代码返工。

4. 先设计数据，再开发接口

我的后端主要用 Go 和 Gin，前端用 Vue 3，数据库设计用 MySQL。我以前就有习惯使用的后端脚手架，所以会把脚手架说明和开发规范一起交给 AI。

技术栈对我来说主要是方便理解和维护。你有自己熟悉的，就先用熟悉的。

数据库设计时，我把需求和原型交给 AI，让它生成建表语句，也就是 DDL，再基于 DDL 画 ER 图，把表之间的关系展示出来。

资料库、剧集、字幕、词汇、租户、用户，这些对象之间怎么关联，得在这里想清楚。尤其做多租户平台，内容属于谁，谁有管理权限，学习者获得了哪些访问权益，都要能在数据和接口里表达出来。

如果你也做类似产品，可以拿一个具体场景检查设计：博主 A 发布的内容，博主 B 能不能改？学员兑换了某套资料库，能访问到哪些内容？让 AI 顺着这条操作路径解释涉及的表和权限，比只看一大段建表语句更容易发现问题。

5. 前端开发前，先把真实接口整理出来

后端开发完，我会让 AI 根据实际代码生成接口文档，包括请求地址、参数、响应结构和可以执行的 curl 示例，再通过请求检查接口结果。

前端开始开发时，我把需求、原型和接口文档一起给它，并明确要求按文档中的字段调用。

这件事看起来普通，但很实用。页面需要什么字段、后端实际返回什么，得对得上。否则页面生成得很快，一联调才发现两边理解的根本不是一回事。

后面接口发生变化，对应文档也要更新。旧文档继续喂给 AI，它会沿着旧信息往下写。

三、把提示词留在仓库里，让每次开发都有明确边界

我有一个习惯：开发中用到的重要提示词，会放进代码仓库的 docs 目录。

新功能、Bug 修复、重构、发布，可以分别用文件记录。复杂功能再单独建文档，把背景、相关文件、约束和验收标准写进去。

这样做了几个月以后，好处很明显。一个功能当时为什么这样做、后来改过什么，我不用再去长长的聊天记录里找。换一次会话，也能把相关文件交给 AI 接着做。

下面这份是根据我实际开发方式整理的任务模板，你可以替换成自己的项目内容：

任务：给现有学习页增加重点词汇搜索。

背景：词汇多时，用户逐条翻找不方便。
现状：已有词汇列表和词汇详情弹窗。
相关材料：需求文档、当前组件、词汇接口文档。

本次范围：搜索当前已加载的词汇列表。
约束：沿用现有组件风格和接口，不改播放逻辑。

请先阅读相关文件，说明实现方案和会修改的文件，
有信息缺失时明确列出，再按确定的方案实现。

验收：
输入关键词后能筛选词汇；
清空后恢复完整列表；
无结果时有明确状态；
筛选后仍能打开词汇详情；
手机上搜索框和列表正常显示。

完成后说明修改内容、自测结果和未验证的项目。

这个模板里最有用的，是把“做什么”和“怎样算完成”写清楚。

“优化词汇体验” 范围很大，“在现有词汇列表里加搜索，并且不影响原来的详情弹窗”，AI 就更容易在正确的位置修改。

我也会把大任务拆成能独立验证的小任务。比如一个复杂学习页，先做布局，再做主题切换，再迁移旧功能，再接真实数据。每完成一段，自己检查，通过以后提交一次 Git。

提交记录能留下一个明确节点。后面出了问题，至少知道上一个可用版本在哪里，也更容易看清这一次究竟改了什么。

一次任务结束后，把重要决定和未完成项写回文档，下一次只带相关上下文继续。所有细节都堆在一个越来越长的会话里，我自己也会越来越难判断当前进度。

四、产品能不能交付，靠的是把问题描述清楚以后反复验证

早期那个三天做完的口语网站，我花了整整一天打磨细节。

添加句子成功了，按钮没有变化，我不知道自己到底有没有添加；电脑上能用，手机打开布局很乱；随机播放每次都重新随机，结果老是重复同一句，练起来很不舒服。

这些问题都要自己用，才会发现。

后来做资料库学习页，也遇到过很具体的 Bug：双语模式下点击字幕，视频会跳转，当前句也会高亮；切到其他字幕模式，视频虽然播放了，高亮却没更新。

图 3｜后续版本中的字幕点击和单句循环入口。这张图展示需要验证的操作位置，并非当时 Bug 的现场截图。

你如果只说“字幕有 Bug，修一下”，AI 得先猜你遇到什么。把操作、现象和预期写清楚，它才有明确的问题可以查。

根据这次实际问题，可以整理成这样的修复任务：

位置：学习页 EpisodeLearn.vue 的动态字幕区域。

复现：
1. 在双语模式下点击另一句字幕，观察播放和高亮。
2. 切到其他字幕模式，再点击另一句。
3. 分别检查点击字幕区域和点击悬浮播放按钮。

实际结果：其他模式下能播放，但当前句高亮没有同步。
预期结果：不同字幕模式、不同点击入口都应同步更新
播放位置和当前句高亮。

请先检查播放状态与当前句状态的更新路径，定位原因。
修复后验证上述组合，并检查连续切句和原有播放控制。
请说明已验证的结果，以及仍需我在真实设备上检查的部分。

如果有报错，再补上日志；如果是显示问题，再加截图和设备信息。你给它的信息越接近真实现场，它越容易找到原因。

我自己反复做的就是这几个动作：用 → 发现问题 → 写清楚 → 交给 AI → 验证 → 再用。

AI 说修好了，我还得按原来的操作重新走一遍。有些问题改完当前入口没问题了，另一个入口可能又受影响，所以相关流程也要一起检查。

对收费产品，验收还要覆盖完整交付：内容制作完成后能不能发布，兑换码能不能让正确的用户进入，没有权限时会怎样，学员进去以后能不能顺畅完成一次练习。

只验证页面能打开，离这些事情都正常还有距离。

五、一次退款，让我把 AI 设计和工程实现分开做

产品上线以后，有个用户因为觉得竞品界面更好看，来找我退款。

当时我挺不舒服。我知道自己做了多少功能，但用户第一眼看到的就是页面。页面看着不够专业，他就会怀疑这个产品值不值得买。

于是我开始重做学习页。

图 4｜学习页改版前后对比：上方是旧版界面，下方是新版多主题界面在手机和平板上的效果。

这次我先用 GPT Image 2 做视觉方向探索，把自己和竞品的页面作为参考，比较不同风格；再把选中的方向整理成 HTML 原型，放进仓库。接着让 Codex 结合旧页面代码和这些素材，先写工程方案，再分阶段实现。

设计图能帮助我选方向，HTML 原型能帮助我看布局，真正接入产品时，还要处理原来的播放器、字幕、学习状态和权限。

当时我把这个改造分成了几个阶段：

1. 1. 用模拟数据搭好页面框架。
2. 2. 检查电脑、手机、iPad 横竖屏的布局。
3. 3. 加入主题切换，调整不同主题的视觉变量。
4. 4. 对照旧页面，把原来的学习功能迁移回来。
5. 5. 接入真实接口，再检查实际使用。
6. 6. 把默认主题、预览和相关权益接到租户后台。

这里有两个技术上的取舍，我觉得值得展开。

一个是把布局和主题分开。

视频怎么排、字幕怎么滚动、播放怎么控制，由页面框架负责。背景、文字、边框、当前句高亮这些颜色和样式，由主题变量负责。

比如组件使用“当前句背景色”这个变量，切主题时替换变量的值。这样八套主题可以共用一套业务组件，后面修改跟读功能，也不用在八份页面里各改一次。

另一个是专门列出旧功能迁移清单。

新版最初出现过跟读 Tab 有了、里面交互却没有和旧页面对齐的情况。双语切换也生成了新的操作方式，但老用户已经习惯原来的按钮。

所以我让 Codex 对照旧学习页逐项检查，把原来能做的事情迁回来。升级页面时，必须知道旧页面有哪些能力不能丢。

最费时间的还是多端体验。iPad 横屏时视频会不会挤压字幕，手机底部控制区会不会太高，重点词汇的数字会不会换行，都得实际打开看。

同一个页面，电脑截图好看，放到手机上可能根本没法好好学。这个环节我没办法只靠 AI 的完成报告来判断。

图 5｜同一个跟读功能在电脑和手机上的实际界面，录音、原音播放、录音回听都要分别检查。

六、一个人要服务这么多用户，也得把制作和交付工具做出来

做资料库，开发学习网站只是其中一部分。

一期内容要能让人逐句练习，还得处理视频、字幕、时间轴、翻译和重点词汇。句子开始时间错了，点字幕就跳不准；结束位置不对，单句循环可能把下句话带进来。

所以我后面也在做内容制作端，让这些动作能在一套工具里衔接起来：上传素材、编辑字幕、核对时间、生成和校对翻译、整理词汇、检查后发布。

AI 可以帮我写这些工具，也可以承担其中的翻译、词汇整理等工作。实际交付前，字幕、时间轴和内容质量仍然要检查。

我自己也用这套流程制作资料。哪一步一直在重复复制粘贴，哪一步经常出错，就继续让 AI 帮我做成脚本或工具，再把检查要求补进去。

图 6｜制作并发布后的资料库列表。每一期背后都有视频、字幕、时间轴和词汇的处理工作。

多租户模式也在这里发挥作用。我把共用的学习功能、内容管理和交付能力维护好，博主就能在这套系统里经营自己的资料库。软件开发可以复用，内容和销售则由不同的博主各自推进。

平台上的用户逐步增长，除了开发效率，也有这些博主持续制作内容、获客和服务学员的贡献。

所以看“85% 付费占比”时，也要结合这种交付方式理解。平台有博主先卖资料库、用户再通过兑换码来学习的路径，不能把这个比例直接理解成一个网站对陌生访客的付费转化率。

七、反馈越来越多以后，我再用 AI 把日常工作串起来

用户多起来以后，我一天会在好几个角色之间切换。刚处理完一个 Bug，又有人咨询；准备写文章，又有租户发来新需求。

聊天记录、需求、开发方案、文章素材散在不同地方，很容易漏。

我后来把这些内容整理进 Obsidian，再结合 WorkBuddy 和 Codex，做了一个自己的工作台。

在我这套分工里，Obsidian 里的文件保存业务资料和任务记录，WorkBuddy 承担定时整理、检查和提醒，Codex 做较复杂的开发、方案和内容任务。

图 7｜WorkBuddy 中配置的定时任务，包括每小时提醒、每日复盘和内容检查。

比如有租户通过微信提出增加粤语功能，我把这段反馈放进收件箱，系统识别为产品需求，整理成任务，再拆出可以开始的步骤。接下来由我判断优先级，进入开发、验证和交付。

图 8｜粤语需求进入任务系统后生成的执行提醒，已经拆出影响评估和下一步动作。图中姓名沿用原有脱敏处理。

工作台则把文件里的任务和进度展示出来，让我少翻几层目录。底层用 Python 服务解析 Markdown 文件，页面负责展示和提供入口，资料仍然保存在知识库里。

图 9｜个人工作台的“今日”页面，把任务、完成进度和复盘集中展示出来。

这里也要承认一个限制：我没有上报的进度，系统不会凭空知道。哪些需求值得做、结果能不能交付，仍然需要我判断。

你要借鉴这个方式，可以先选一个经常重复的流程。比如“用户反馈变开发任务”，先约定反馈放哪里、任务需要哪些信息、做完后怎么记录。跑顺以后，再考虑把更多事情接进来。

这套工作台是业务做起来以后，为了解决自己的忙乱逐步加上的，并不是开发第一个产品的前置条件。

八、重新来一次，我会坚持这几个动作

回头看，我能一个人把产品做到这个阶段，AI 编程确实帮我承担了大量工作。但我自己投入最多的精力，集中在需求判断、任务拆解、实际使用和质量把关上。

如果你也准备做自己的产品，我建议先把下面这条流程跑一遍：

1. 1. 找到一个具体用户，写清他现在在哪一步费劲，以及目前怎么解决。
2. 2. 和 AI 整理需求，做出能看懂、能讨论的原型，拿给目标用户确认。
3. 3. 把需求、数据和接口整理进项目，先实现一条可以完整走通的核心流程。
4. 4. 每次交给 AI 一个边界清楚、能够验收的任务，验证以后留下代码和文档记录。
5. 5. 让真实用户使用，再根据反馈修复、交付、继续迭代。

我有五年的后端经验，这个基础确实帮我更容易判断数据库、接口和部署的问题。没有这些经验的人，可以把第一个项目做小一点，在实际开发中逐步补齐，别拿别人的首版时间要求自己。

三天的比赛作品、二十多天的产品首版、后面持续维护的平台，是三个不同阶段。前面做得快，只是让我有机会更早接触用户，后面能不能留下来，还要继续做很多细活。

这一年我也多次因为忙开发而停更内容，获客还不够稳定，产品也仍有很多地方要改。

但有一件事已经很清楚了：我可以先把一个人的具体麻烦解决好，用 AI 把解决过程做成软件，再把软件交给更多人使用。用户指出哪里不好用，我就把问题带回下一轮开发。

下一次打开 AI 编程工具之前，先写清楚这一次让用户完成什么，以及你准备怎样检查。后面的开发，会有方向得多。