用這個工具，解決 Vibe Coding 當中的英語問題

說出來不怕大家笑話。

現在天天搞 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 的學習是有策略的，主要是兩方面：

1. 引入了一套科學的記憶算法，什么時候背新詞，什么時候復習，復習頻率，都由一套科學的卡片算法實現；
2. 在句子中學習，比直接死記硬背單詞更有用，所以 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）