说出来不怕大家笑话。
现在天天搞 AI，但实际上，我的英语水平其实不太好。
虽然咱们国内的大模型越来越强，最近高强度使用的 DeepSeek V4 Pro 非常令人惊喜，但咱们客观地说，想要用上更强的 AI，或者想要对 AI 的应用场景有更深刻的理解，还是得跟上老美那边。
就比如 Claude Code，虽然可以中文对话，但是系统提示语言这些都是英文；很多 AI 网站、国外信源，也都是英文，浏览器里的沉浸式翻译插件很好用，但是一些关键字词总得原文译文来回切换，才能理解到位。
我就琢磨，得把这些英语学会，学在脑子里，使用这些 AI 工具的时候，就省事儿多了，提高效率。
这么想是有原因的，主要是两个点：
- AI 工具使用中，所遇到的英文，是有限的。我大约看了一下，最常见的单词，总共也就是 300-500 词汇量，完全可以快速学会，不至于像托福雅思一样，洋洋洒洒几千词，光看数量就 abandon 了。
- 学会这些 AI 常见词，效率的提升是肉眼可见的。浏览器的网页有插件可以快速翻译，但是本地运行的 Claude Code、Codex 这些 Agent， 遇到不懂的单词，要么切出去单独查，要么装个截图翻译软件，都很打断心流，很麻烦，但是一旦把这三五百词学会，效率和心流的提升，立竿见影。
有限的词汇数量，为学 AI 单词这件事儿极大地降低了心理成本；明显的效率提升，为行动提供了强大的学习动力。
所以，说干就干，用 AI 打败 AI。
我开发了这个小程序——「VibeEnglish - 只学 AI 使用中的单词」。
后面也会讲一下这个小程序的产品设计与开发思路，我们借假修真，在实际案例中，思考与 AI Coding 的技巧。
第一，
VibeEnglish 提供了一个词库，这个词库，完全限制在 AI 工具场景，我自己亲手从 Claude Code、Codex、OpenRouter 等常见的 AI 工具里面，把遇到的单词整理出来，作为词库。
比如这一句：
Claude Code 在打开新项目的授权申请
我整理出来的，都是实实际际使用中遇到的单词，学了就一定能用上，不是那种为了多而全，对着字典搞一个大词库。
第二，
有限可穷尽，真的可以学完。目前这个词库只有 193 个单词、75 个句子，学完就学完了，而且学完就一定能把 Claude Code 这些国外的 AI 工具用起来。
以前我不爱背单词，很大一部分原因，是单词太多了，一眼看不到头儿，还没开始，耐心就磨没了。现在，VibeEnglish 把单词做成有限的词库，启动压力一下子小很多。
第三，
VibeEnglish 的学习是有策略的，主要是两方面：
- 引入了一套科学的记忆算法，什么时候背新词，什么时候复习，复习频率，都由一套科学的卡片算法实现；
- 在句子中学习，比直接死记硬背单词更有用，所以 VibeEnglish 提供了非常多的语境，直接学习 AI 工具中的句子，更容易用上，同时也更容易理解。
如果你也想集中突击一下 AI 场景中的英语，那么这个小程序，会是你在 AI 浪潮中的得力助手。
点击进入 VibeEnglish 小程序 - 只学 AI 场景里的词
AI 项目心得
最后简单分享一下，这个开发项目中的技巧心得。
这是我第一次「全链路无人工」的 VibeCoding 出一款完成度比较高的产品，几乎无监督地完成了整个项目的开发和设计。
我们把打造一个产品，拆解为以下阶段：
原始需求 - 正式 PRD - 交互设计-UI 设计稿 - 技术实现方案 - 进入开发 - 修复 Bug - 优化小细节 - 部署上线
在之前的 VibeCoding 项目中，这些关键阶段，或多或少都有几个环节是人工实现。
我画了一个表格，感受一下（表示 AI 完成的环节）：
产品项目
VibeEnglish
发票大王
醉准小程序
各种 Skills
BusinessModelCraft.com
AI 开发总结
本文项目，只提供了一个基础的原始需求，后续流程完全由 AI 完成
项目重点是多格式的解析和识别，在整体项目上，由人工进行了技术架构方向的梳理，实现清爽合理可复用的架构。
设计风格有特点，人工进行了 UI 设计
Skill 的制作需要很强的 SOP 约束，这些规则人工参与很深
商业模式画布网站是我第一款 AI Coding 产品，产品需求和交互人工完成，AI 完成 Web 页面的开发
原始需求
人工
人工
人工
人工
人工
正式 PRD
一起协作
一起协作
一起协作
一起协作
交互设计
人工
人工
人工
人工
UI 设计稿
人工
不涉及
技术实现方案
一起协作
一起协作
进入开发
修复 Bug
优化小细节
一起协作
部署上线
可左右滑动
我们一说 VibeCoding，总是觉得 Coding 的部分是主体，但实际上产品的创造，不仅仅是代码环节，更多在产品需求和设计阶段。
在过去的项目中，代码环节基本上都是 AI 完成，因为我完全不懂代码，稍微参与深一点的是「发票大王」的技术架构思路，是因为这个项目涉及到多源的格式解析，AI 给出的方案不够优雅，所以人工介入，其他项目的技术架构到代码开发，就全部由 AI 完成。
而代码之前的环节，比如产品的需求和交互，人工参与得很重。这一方面，是即使给 AI 加载了 UX 方面的 Skill，但 AI 也依然难以真正感受到用户体验的细节；另一方面，AI 的目标是完成需求，直线最短，但如果一味地走直线，就会少很多产品的巧思。
但这次 VibeEnglish 的开发不同，我只写了原始需求，描述我要一个学习 AI 场景英语单词的小工具，载体是微信小程序，设计风格采用 Claude 的设计系统。
然后，按照我的要求，AI 写出了完整的 PRD（产品需求文档）、Architecture（技术架构文档）、Design-spec（设计系统文档），可能是项目需求本身不复杂的原因，Claude 给到这三个文档的时候，我非常惊喜，一把过。
再往后的正式开发，这个项目就吃百家饭了，手头有啥模型就用啥模型。小米 MiMo 搞活动送了 7 亿 Token，我就顺势用了一阵子；DeepSeek V4 Pro 发布，我也用了 DeepSeek；部分疑难杂症，是 Claude 和 GPT 帮忙解决。
因为三个文档约束得足够好，所以实际写代码的时候，吃百家饭也没什么关系，我在每次开发完新功能，都会要求 AI 非常详细地写开发日志，记录问题出现的根因、解决方案、解法思路和论证过程，方便在切换各种工具的时候，延续上下文。
这是我的文档结构：
开发日志的格式，经过几轮调教，我总结成了一个模板，可以直接把开发日志的要求，写在项目的AGENTS.md，让 AI 遵守，模板分享出来：
1
## 文档规范
2
### 前置文档
3
开始任何实质性开发前，以下文档必须存在，缺失时应提示补充而非自行推断：
4
‑ `docs/PRD.md`：需求、验收标准、明确不做什么
5
‑ `docs/architecture.md`：技术选型、模块划分、数据流
6
‑ `docs/design-spec.md`：视觉与交互规范（无 UI 项目可省略）
7
8
### 开发日志
9
路径：`docs/dev-log/YYYY-MM-DD.md`，同一天多次 Session 追加到同一文件。
10
**触发时机**：完成一个功能模块后；当天工作结束时。
11
**详细程度**：日志面向未来的自己，应尽可能详细——宁可记多，不要遗漏。读者是「三个月后对这段代码完全陌生的自己」。
12
**必须记录**：
13
‑ **本次目标**：Session 开始前写，说清楚这次要做什么（不超过 3 条）
14
‑ **完成内容**：结果导向描述，说做了什么、达到了什么效果
15
‑ **关键决策**：有技术取舍时，记录采用方案和放弃方案及原因；显而易见的实现不需要记
16
‑ **Bug 记录**：现象 → 根因 → 修复方案，三项缺一不可
17
‑ **文件变更清单**：列出涉及的文件路径和变更类型
18
‑ **遗留事项**：未完成的任务和下次计划，保持上下文连续性
所以，如果用一句话，来总结 VibeEnglish 项目开发的经验，就是：
开发未动，文档先行。
模型有上下文，你不能指望模型把所有的细节都记住，即使是人脑，也是好记性不如烂笔头，对于大模型来说，更是如此。
互联网公司里，每一个产品需求，对于产品经理的需求文档要求都很高，需要写清楚所有的逻辑和细节，这正是大型组织为了解决产出确定性问题，而采用的方法。AI 时代，编码不再是难点，但能把需求给 AI 讲清楚，并且能把过程思考也记录下来，让 AI 随时调用，是更关键的问题。
文/亨亨（始终是产品经理）
微信：xiaozidaheng
微信公众号：产品变量（ID：hengpaper）
热门跟贴