別讓AI瞎猜了！這個配置讓返工從4次降到1次
整理版優先睇
OpenSpec：一份畀AI睇嘅項目說明書，令開發效率提升3倍
呢篇文章嘅作者係一位用Cursor寫Next.js項目嘅開發者。佢發現AI經常理解錯指令——明明叫用App Router，AI就寫Pages Router；明明規定用Prisma，AI就自己寫SQL。每次都要改3-4次先得，白白浪費時間解釋規範。為咗解決呢個問題，佢介紹咗OpenSpec呢個方法。
OpenSpec就係畀AI睇嘅項目說明書。你用標準格式寫低技術棧、目錄規則同核心規範，AI每次生成代碼前都會讀呢份文件，唔需要再靠估。作者喺3個真實項目測試過：未用OpenSpec時首次準確率大約62-71%，用咗之後升到87-93%，平均返工次數由3-4次降到1-2次，開發效率提升約3倍。結論係：如果項目超過20個文件、有明確規範、要維護超過一個月或者係團隊協作，強烈建議用OpenSpec，配置只需10分鐘，之後就長遠受益。
- OpenSpec係一份畀AI睇嘅項目說明書，用標準格式記錄技術棧、目錄規則同核心規範，寫一次AI每次都睇到。
- 使用OpenSpec後，首次代碼生成準確率由約65%提升到約89%，平均返工次數由3-4次降到1-2次，整體效率提升約3倍。
- OpenSpec針對三大痛點：理解偏差（AI靠估）、上下文丟失（對話太長失憶）、重複返工（團隊協作解釋成本高）。
- 上手只需三步：創建.openspec文件夾、寫project.md（技術棧+目錄+規則）、喺Cursor驗證，總共10分鐘搞掂。
- 適閤中大型項目（文件>20個）、有明確規範、團隊協作、維護超過1個月；一次性腳本或細項目唔需要用。
你係咪都遇過AI亂改代碼？
上週我畀Cursor幫手改一個Next.js項目嘅路由，明明話佢知「用App Router」，結果佢生成咗一堆Pages Router嘅代碼。改咗三次先啱。你係咪都遇過類似問題？
讓AI修改功能，結果理解偏咗，越改越亂
明明話要用某個規範，過咗十輪對話佢就唔記得；每次切換項目，都要重新解釋一遍項目結構。我踩過嘅坑你唔好再踩。今日同大家講下OpenSpec點樣解決呢啲問題。
OpenSpec = 畀AI睇嘅項目說明書
就係咁簡單。你用標準格式寫一份文檔，話畀AI知：呢個項目係做乜、用咗咩技術棧、有咩必須遵守嘅規則。AI讀咗呢份說明書，每次生成代碼時就能精準理解你嘅項目上下文。
寫一次，AI每次都明
用OpenSpec前後真實對比
未用OpenSpec之前，我有個電商後台項目，20幾個文件，用Next.js 14 + Prisma。每次叫Cursor寫代碼：叫佢加個API，佢習慣性寫成/pages/api，但我項目用緊/app/api；叫佢查數據庫，佢直接寫SQL，但我規定要用Prisma；叫佢加個組件，佢用咗any類型，但我要求嚴格TypeScript。結果：平均每個功能要改3-4次先用得，浪費大量時間解釋規範。
平均每個功能要改3-4次
呢度有一個最簡單嘅例子：假設你有個博客項目，最簡單嘅.openspec/project.md可以咁寫：
# 項目：個人博客
## 簡介
Next.js博客系統，支持文章發佈和評論
## 技術棧
- Next.js 14 （App Router）
- PostgreSQL + Prisma
- TypeScript
## 目錄
- /app：頁面和API路由
- /components：UI組件
- /lib：工具函數
## 關鍵規則
1. 組件必須TypeScript，不用any
2. API統一喺 /app/api 下
3. 數據庫操作只用Prisma就十幾行！AI讀咗之後即刻知道：用App Router，唔好寫Pages Router；TypeScript嚴格模式，唔好偷懶；數據庫走Prisma，唔好寫原生SQL。
首先生成嘅代碼直接係 /app/api/login/route.ts，用Prisma查詢，TypeScript類型完整
OpenSpec解決三大痛點
OpenSpec到底解決咗咩問題？主要有三個：
- 理解偏差：AI唔知項目背景，靠「估」寫代碼。OpenSpec將規則寫喺Spec裏，AI每次見到，唔再靠估。
- 上下文丟失：對話太長，AI「失憶」。OpenSpec嘅規則永久有效，AI永遠讀到，唔需要每次重新強調。
- 重複返工：團隊協作時，每個人都要畀AI解釋一遍。OpenSpec團隊共享一份，所有人嘅AI理解一致。
數據顯示，喺3個真實項目中測試，平均效率提升約3倍。而且配置OpenSpec只需要唔夠1個鐘，之後就係純賺。
配置OpenSpec只需要唔夠1個鐘
寫一次Spec，開發效率提升3倍
快速上手只需3步
唔使擔心複雜，OpenSpec上手超簡單：
- 1 第1步：喺項目根目錄創建.openspec文件夾（2分鐘）
- 2 第2步：寫一個project.md文件，填技術棧、目錄規則同核心規範（5分鐘）
- 3 第3步：喺Cursor中驗證生效（3分鐘）
總共10分鐘搞掂。具體點操作？下一篇手把手教你。
10分鐘配置，長遠受益
你在用AI編程時，最常遇到咩問題？評論區聊聊。關注我，下一篇更新實戰教程。
關注我，下一篇更新實戰教程
上星期我叫Cursor幫我改一個Next.js項目的路由，明明話咗「用App Router」，點知佢生成咗一堆Pages Router嘅代碼，改咗三次先啱。
你係咪都遇到過類似嘅問題？
叫AI改功能，點知佢理解錯咗，越改越亂 明明話咗要用某個規範，過咗十輪對話佢就唔記得咗 每次轉項目，都要重新同AI講一次項目結構
我跌過嘅坑你唔好再跌。今日講下OpenSpec係點樣解決呢啲問題。
一句講曬：OpenSpec係咩
OpenSpec = 俾AI睇嘅項目說明書
就係咁簡單。你用標準格式寫一份文檔，話俾AI知：
呢個項目係做咩㗎 用咗咩技術棧 有邊啲一定要遵守嘅規則
AI睇咗呢份說明書，每次生成代碼嘅時候就可以準確理解你個項目嘅上下文。
打個比喻：
建築工人睇施工圖紙→AI讀OpenSpec 廚師睇食譜→AI讀OpenSpec 你入新公司睇員工手冊→AI讀OpenSpec
寫一次，AI每次都明。
我用OpenSpec前後嘅真實對比
未用OpenSpec之前
我有個電商後台項目，成20幾個文件，用Next.js 14 + Prisma。
每次叫Cursor寫代碼：
叫佢加個API，佢習慣性寫成 /pages/api，但我個項目係用/app/api叫佢查數據庫，佢直接寫SQL，但我規定一定要用Prisma 叫佢加個組件，佢用咗 any類型，但我要求嚴格TypeScript
結果：平均每個功能要改3-4次先用得，浪費好多時間解釋規範。
用咗OpenSpec之後
我用咗唔夠1個鐘，寫咗一個.openspec/project.md文件：
# 項目：電商管理後台
## 技術棧
- Next.js 14 （App Router模式，不用Pages Router）
- TypeScript （禁止使用any類型）
- Prisma （所有數據庫操作必須用Prisma，不直接寫SQL）
## 目錄規則
- API路由：/app/api/*
- 組件：/components/*
- 業務邏輯：/lib/*
## 核心規範
1. 所有API必須放在 /app/api 下
2. 數據庫查詢只能用 Prisma Client
3. 組件必須用TypeScript，無any類型
...Cursor讀了這個Spec之後：第一次生成嘅代碼準確率由65%升到89% 平均返工次數由3-4次降到1-2次 整體開發效率提升大約3倍
呢個唔係誇張數字，係我記錄嘅真實數據。
30秒判斷：你應唔應該用OpenSpec？
對照呢幾個問題：
「你個項目文件超過20個？」 → 用！AI記唔曬咁多文件嘅關係
「你有明確嘅代碼規範？」 → 用！每次口頭話俾AI聽太攰
「你個項目要維護超過1個月？」 → 用！一次配置，長期受惠
「你係團隊開發？」 → 用！統一團隊成員嘅AI理解標準
「你就係寫一次性腳本？」 → 唔好用，冇必要
「你個項目得3-5個文件？」 → 暫時唔需要，AI一眼就明
符合2條或以上？強烈建議用OpenSpec！！
一個最簡單嘅例子
假設你有個博客項目，最簡單嘅.openspec/project.md可以咁寫：
# 項目：個人博客
## 簡介
Next.js博客系統，支持文章發佈和評論
## 技術棧
- Next.js 14 （App Router）
- PostgreSQL + Prisma
- TypeScript
## 目錄
- /app：頁面和API路由
- /components：UI組件
- /lib：工具函數
## 關鍵規則
1. 組件必須TypeScript，不用any
2. API統一在 /app/api 下
3. 數據庫操作只用Prisma就十多行!AI睇咗之後即刻知道：
用App Router，唔好用Pages Router TypeScript嚴格模式，唔好偷懶 數據庫用Prisma，唔好寫原生SQL
效果對比
冇用OpenSpec：
你：「幫我加個用戶登錄API」
AI：生成了/pages/api/login.ts，仲用直接SQL查詢
你：「唔啱，要用App Router同Prisma」
AI：改咗做/app/api/login/route.ts，但係仲直接寫SQL
你：「我話咗要用Prisma！」 AI：終於改啱咗……
用咗OpenSpec：
你：「幫我加個用戶登錄API」
AI：直接生成/app/api/login/route.ts，用Prisma查詢，TypeScript類型完整
你：「完美！」
慳咗起碼30分鐘同3輪返工。
OpenSpec到底解決咗咩問題？
問題1：理解偏差
場景：AI唔知項目背景，靠「估」寫代碼
你會遇到嘅情況：
你個項目用Next.js嘅App Router，AI習慣性寫成Pages Router 你規定用某個狀態管理庫，AI就用另一個 你有命名規範，AI完全唔跟
OpenSpec點樣解決： 將呢啲規則寫喺Spec度，AI每次都可以睇到，唔使再靠估。
問題2：上下文丟失
場景：對話太長，AI「失憶」
你會遇到嘅情況：
頭先明明講咗「業務邏輯放/lib文件夾」，過咗10輪對話AI就唔記得 叫AI跟某個規範，開頭仲記得，後面就唔理 每次新對話都要重新講一次規則
OpenSpec點樣解決： 規則寫喺Spec文件度，永久有效，AI永遠可以讀到。
問題3：重複返工
場景：團隊協作時，每個人都要同AI解釋一次
你會遇到嘅情況：
新同事加入，佢嘅AI助手唔知項目規範 轉去另一個AI工具，又要由頭講一次 每次Code Review發現AI生成嘅代碼唔符合團隊規範
OpenSpec點樣解決： 團隊共享一份Spec，所有人嘅AI都可以睇到，理解一致。
數據說話
我喺3個真實項目中測試OpenSpec：
平均效率提升大約3倍。
而且配置OpenSpec只需要唔夠1個鐘，之後就係純賺。
快速上手只需3步
唔使擔心複雜，OpenSpec上手超簡單：
第1步：喺項目根目錄創建.openspec文件夾（2分鐘） 第2步：寫一個project.md文件，填3個部分（5分鐘） 第3步：喺Cursor度驗證生效（3分鐘）
總共10分鐘搞掂。
具體點操作？下一篇手把手教你。
最後講幾句
OpenSpec嘅核心思路好簡單：俾AI一份「項目說明書」，叫佢先理解再開工。
適合：
中大型項目（文件>20個） 有明確規範嘅項目 團隊協作項目 持續維護超過1個月嘅項目
寫一次Spec，開發效率提升3倍。
但你可能仲有疑問：
OpenSpec具體點寫？ 點樣喺Cursor入面啟用？ 有冇現成模板？
下一篇，我會拆一個真實項目，數據同代碼都俾你睇。
你用AI編程嗰陣，最成日遇到咩問題？
留言區傾下，例如：
AI經常「失憶」，唔記得之前講過嘅規則 AI唔明項目架構，代碼擺錯位 每次都要重新解釋項目結構
關注我，下一篇更新實戰教學
睇完有收穫，㩒個「在看」等更多開發者睇到
#OpenSpec #AI編程 #Cursor #開發效率 #代碼規範
上週我讓Cursor幫我改一個Next.js項目的路由，明明告訴它「用App Router」，結果它給我生成了一堆Pages Router的代碼。改了三次才對。
你是不是也遇到過類似的問題？
讓AI修改功能，結果理解偏了，越改越亂 明明說了要用某個規範，過了十輪對話它就忘了 每次切換項目，都要重新給AI解釋一遍項目結構
我踩過的坑你別再踩。今天聊聊OpenSpec是怎麼解決這些問題的。
一句話說清楚：OpenSpec是什麼
OpenSpec = 給AI看的項目說明書
就這麼簡單。你用標準格式寫一份文檔，告訴AI：
這個項目是幹啥的 用了什麼技術棧 有哪些必須遵守的規則
AI讀了這份說明書，每次生成代碼時就能精準理解你的項目上下文。
類比一下：
建築工人看施工圖紙→AI讀OpenSpec 廚師看菜譜→AI讀OpenSpec 你入職新公司看員工手冊→AI讀OpenSpec
寫一次，AI每次都懂。
我用OpenSpec前後的真實對比
沒用OpenSpec之前
我有個電商後台項目，20多個文件，用的Next.js 14 + Prisma。
每次讓Cursor寫代碼：
讓它加個API，它習慣性寫成 /pages/api，但我項目用的是/app/api讓它查數據庫，它直接寫SQL，但我規定必須用Prisma 讓它加個組件，它用了 any類型，但我要求嚴格TypeScript
結果：平均每個功能要改3-4次才能用，浪費大量時間解釋規範。
用了OpenSpec之後
我花了不到1小時，寫了一個.openspec/project.md文件：
# 項目：電商管理後台
## 技術棧
- Next.js 14 （App Router模式，不用Pages Router）
- TypeScript （禁止使用any類型）
- Prisma （所有數據庫操作必須用Prisma，不直接寫SQL）
## 目錄規則
- API路由：/app/api/*
- 組件：/components/*
- 業務邏輯：/lib/*
## 核心規範
1. 所有API必須放在 /app/api 下
2. 數據庫查詢只能用 Prisma Client
3. 組件必須用TypeScript，無any類型
...Cursor讀了這個Spec之後：第一次生成的代碼準確率從 65%提升到89% 平均返工次數從3-4次降到1-2次 整體開發效率提升約3倍
這不是誇張數字，是我記錄的真實數據。
30秒判斷：你該不該用OpenSpec？
對照這幾個問題：
「你的項目文件超過20個？」 → 用！AI記不住這麼多文件的關係
「你有明確的代碼規範？」 → 用！每次口頭告訴AI太累了
「你的項目要維護1個月以上？」 → 用！一次配置，長期受益
「你是團隊開發？」 → 用！統一團隊成員的AI理解標準
「你就寫個一次性腳本？」 → 別用，沒必要
「你的項目就3-5個文件？」 → 暫時不需要，AI掃一眼就懂
符合2條及以上？強烈建議用OpenSpec！！
一個最簡單的例子
假設你有個博客項目，最簡單的.openspec/project.md可以這麼寫：
# 項目：個人博客
## 簡介
Next.js博客系統，支持文章發佈和評論
## 技術棧
- Next.js 14 （App Router）
- PostgreSQL + Prisma
- TypeScript
## 目錄
- /app：頁面和API路由
- /components：UI組件
- /lib：工具函數
## 關鍵規則
1. 組件必須TypeScript，不用any
2. API統一在 /app/api 下
3. 數據庫操作只用Prisma就十多行!AI讀了之後立刻知道：
用App Router，別寫Pages Router TypeScript嚴格模式，別偷懶 數據庫走Prisma，別寫原生SQL
效果對比
沒使用OpenSpec：
你：「幫我加個用戶登錄API」
AI：生成了/pages/api/login.ts，還用了直接SQL查詢
你：「不對，要用App Router和Prisma」
AI：改成/app/api/login/route.ts，但還是直接寫SQL
你：「我說了要用Prisma!」 AI：終於改對了...
用了OpenSpec：
你：「幫我加個用戶登錄API」
AI：直接生成/app/api/login/route.ts，用Prisma查詢，TypeScript類型完整
你：「完美!」
省了至少30分鐘和3輪返工。
OpenSpec到底解決了什麼問題？
問題1：理解偏差
場景：AI不知道項目背景，靠「猜測」寫代碼
你遇到的情況：
你的項目用Next.js的App Router，AI習慣性寫成Pages Router 你規定用某個狀態管理庫，AI卻用另一個 你有命名規範，AI完全不遵守
OpenSpec怎麼解決： 把這些規則寫在Spec裏，AI每次都能看到，不再靠猜。
問題2：上下文丟失
場景：對話太長，AI「失憶」
你遇到的情況：
前面明明說過「業務邏輯放/lib文件夾」，過了10輪對話AI就忘了 讓AI遵守某個規範，剛開始還記得，後面就不管了 每次新對話都要重新強調一遍規則
OpenSpec怎麼解決： 規則寫在Spec文件裏，永久有效，AI永遠能讀到。
問題3：重複返工
場景：團隊協作時，每個人都要給AI解釋一遍
你遇到的情況：
新同事加入，他的AI助手不知道項目規範 切換到另一個AI工具，又要從頭講一遍 每次Code Review發現AI生成的代碼不符合團隊規範
OpenSpec怎麼解決： 團隊共享一份Spec，所有人的AI都能看到，理解一致。
數據說話
我在3個真實項目中測試OpenSpec：
平均效率提升約3倍。
而且配置OpenSpec只需要不到1小時，之後就是純賺。
快速上手只需3步
別擔心複雜，OpenSpec上手超簡單：
第1步：在項目根目錄創建.openspec文件夾（2分鐘） 第2步：寫一個project.md文件，填3個部分（5分鐘） 第3步：在Cursor中驗證生效（3分鐘）
總共10分鐘搞定。
具體怎麼操作？下一篇手把手教你。
最後說幾句
OpenSpec的核心思路很簡單：給AI一份「項目說明書」，讓它先理解再動手。
適合：
中大型項目（文件>20個） 有明確規範的項目 團隊協作項目 持續維護超過1個月的項目
寫一次Spec，開發效率提升3倍。
但你可能還有疑問：
OpenSpec具體怎麼寫？ 如何在Cursor中啓用？ 有沒有現成模板？
下一篇，我會拆一個真實項目，數據和代碼都給你看。
你在用AI編程時，最常遇到什麼問題？
評論區聊聊，比如：
AI經常「失憶」，忘記之前說的規則 AI不懂項目架構，代碼放錯位置 每次都要重新解釋項目結構
關注我，下一篇更新實戰教程
看完有收穫，點個「在看」讓更多開發者看到
#OpenSpec #AI編程 #Cursor #開發效率 #代碼規範