TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
VibeDoc 開源工具：把產品想法生成開發方案與 AI 編程提示詞
VibeDoc 是 MIT 授權的開源 AI 開發方案產生器，把產品想法生成固定五模組文件、Mermaid 圖與 AI 編程提示詞。本文從原始碼拆解它的防幻覺設計、品質分數的真相、資料流向與自架條件。
用 AI 摘要這篇文章：
把一個產品想法貼進 ChatGPT 或 Claude，請它寫一份開發方案，通常拿得到像樣的長文。麻煩出在第二次：換個對話、換個問法，出來的章節長得不一樣，參考連結常混著模型自己編的，甘特圖和架構圖則要看運氣。VibeDoc 這款 MIT 授權的開源工具，收的就是這段差距。它把「生成開發方案」固定成五個模組：產品概述、技術方案、開發計畫、部署方案、成長策略，配上 Mermaid 架構圖、流程圖、甘特圖，以及每個功能模組可以直接貼進 Claude、ChatGPT、Copilot、Cursor 使用的編程提示詞，最後讓你匯出成 Markdown、Word、PDF 或 HTML。範圍也先講清楚：它產出的是文件與提示詞，本身不寫程式碼，程式碼是提示詞丟給編程工具後的事。
AI 產出開發計畫文件之後，發布端還有另一種選擇：docmd能把 Markdown 文件變成帶 AI 檢索索引的靜態網站，兩者剛好接力。
專案 2025 年 9 月出現在 GitHub，目前版本 2.0.0，到 2026 年 8 月累積約 376 個 star、44 次 fork，最近一次程式更新停在 2025 年 11 月 21 日。它沒有付費牆；線上 demo 架在中國的模型社群平台 ModelScope（魔搭）創空間，本地自架只需要 Python 3.11 環境加一把免費申請的 API key。
跟直接問通用模型比起來，它多的是約束
先說清楚一個容易誤會的地方：VibeDoc 沒有自己的模型。原始碼裡的 config.py 把模型寫死為阿里雲的 Qwen2.5-72B-Instruct，經由 AI 推理 API 服務商 SiliconFlow 的介面呼叫，介面上沒有換模型的選單，想換就得改程式。所以它加固的是約束這一端：模型還是同一顆，換工具不會變聰明。
| 面向 | 直接問通用模型 | VibeDoc |
|---|---|---|
| 輸出結構 | 隨對話與問法變動 | 固定五模組加編程提示詞 |
| 圖表 | 要另外要求，格式看運氣 | 提示詞明定 Mermaid 圖種類與語法 |
| 假連結 | 常見，需自行檢查 | 黑名單加後處理自動清除 |
| 匯出 | 複製貼上 | Markdown、Word、PDF、HTML 一鍵 |
| 模型 | 自己挑 | 寫死 Qwen2.5-72B-Instruct |
| 費用 | 你已有的訂閱或 API 額度 | 工具免費，生成走 SiliconFlow 計費 |
這是能力存在面的差異。兩邊實際生成內容孰好孰壞，要真的跑過才說得準；可以確定的是，結構固定的輸出對要把文件交給別人看的人有實際意義。課堂專題的口試本、團隊內部的評估文件、給投資人或主管的提案底稿，都屬於「格式即禮貌」的場景，這時固定模板省下的來回調整，往往比模型本身的聰明程度更影響交付速度。反過來說，如果你的文件本來就沒有固定格式需求，直接對話的彈性用起來更省事。
還有一個時間成本的細節：config.py 把 API 逾時設成 300 秒，註解寫明是為了解決生成逾時問題，也就是說一次生成等到兩三分鐘屬於設計內的等待，不是當機。README 對速度的說法是 60 到 180 秒生成一份完整方案；這是作者的數字，實際時間取決於模型端負載與方案長度，缺少獨立量測可以對照，等太久時先看處理面板卡在哪一步。
原始碼裡的它：一次主呼叫，前後各有一串手腳
VibeDoc 常被歸類成 agent 應用，repo 的主題標籤也掛著 agent；不過把 app.py 這支 4,298 行的單檔主程式攤開看，主流程相當直白：輸入驗證、可選的想法優化、組系統提示詞、一次 requests.post 送向 SiliconFlow 的 chat completions 端點、然後進後處理。會有第二次模型呼叫的場合只有一個：按下優化創意描述按鈕時，prompt_optimizer 會先把一句話想法改寫成較完整的描述，附上修改建議，再進主流程。介面上那個逐步顯示「輸入驗證、AI 請求準備、內容生成、後處理」的處理過程面板，就是這條鏈的視覺化，每個步驟附耗時與明細，讓你看得到等待發生在哪一段。
生成完的方案可以直接在介面裡改。plan_editor 把輸出拆成可編輯的段落，逐節修改、留下編輯歷史與評論，改完再匯出；這對「AI 出初稿、人改第二稿」的用法比整包重新生成實際。匯出這端由 export_manager 負責，四種格式各有定位：Markdown 適合進版本控制與 GitHub 展示，Word 檔餵給商務流程，PDF 拿去做正式提案，HTML 放上網頁分享。
參考資料的進場方式藏在 config.py：兩個 MCP 服務（DeepWiki 負責解析技術文件站、Fetch 負責抓一般網頁）託管在 ModelScope 的端點上，你貼的參考網址會先經它們取回內容，再連同你的想法一起進提示詞，系統提示詞並要求生成結果明確引用這些參考。想多認識 MCP 在工具鏈裡的其他用法，可以看我們介紹過的 BrowserWing。
防幻覺才是它真正花力氣的地方
讀 app.py 第 907 行起的系統提示詞，會看到這個專案的主要工程投入花在哪裡。提示詞先注入今天的日期，要求甘特圖以真實日期規畫；接著列出一整段嚴禁事項：不得生成 github.com/username 這類佔位帳號連結、不得出現 example.com 或 xxx.com 等測試網域、沒有外部參考時必須整段省略參考來源，寧可寫「參考常見架構」也不要掛一排假文獻。Mermaid 圖同樣有逐條規格：節點文字怎麼包、禁用雙重引號、圖內不得出現標題語法，還附了架構圖、流程圖、甘特圖三份範本。
生成之後還有一串修補函數接力：fix_mermaid_syntax 修圖表語法、validate_and_clean_links 清掉漏網的假連結、fix_date_consistency 把過期日期換成當期、validate_and_fix_content 做整體結構檢查。黑名單列得相當具體，從 github.com/username 這種佔位帳號、medium.com/@username 加數字編號的格式、blog.csdn.net/username，到 example.com、xxx.com、test.com 等測試網域都指名道姓，後處理的連結檢查也用同一組特徵再掃一次。模型愛編參考連結是 LLM 生成文件的通病，一份交付文件裡只要混進兩三條看似可引用實則不存在的網址，可信度就整份賠掉；VibeDoc 用提示詞約束加事後清場兩層處理這個問題。把它理解成一個會自己打掃的模板引擎，比把它想成無所不知的產品經理更貼近實情。
README 的 85 分，量的是格式不是內容
README 的效能表宣稱生成成功率大於 95%、平均內容品質分 85/100。app.py 第 528 行起的 calculate_quality_score 函數說明了分數從哪裡來：內容超過 500 字得 15 分、超過 2,000 字再得 15 分；四個預期結構特徵（主標題、提示詞區塊、Mermaid 圖、甘特圖字樣）各得 6 分；日期落在近年且沒有更舊年份得 20 分；沒有假連結得 15 分；Mermaid 語法乾淨得 10 分。換句話說，一份內容全錯但格式齊全的方案，照樣能拿高分。這是結構計分器，量的是長得像不像預期，repo 裡沒有測試目錄，公開的第三方評測也少，使用時當參考就好。處理過程面板裡還有一個小細節：部分步驟的分數（準備階段 95 分、後處理 85 分）是寫死的常數，屬於顯示用途。
對這些行銷數字保持距離，跟理解它的價值並不衝突。VibeDoc 真正可檢驗的賣點是輸出紀律本身：章節固定、圖表語法被修過、連結被清過、日期對得上現在。這些是你拿到文件後三十秒內能自己核對的事，也是它跟裸對話拉開差距的地方。
你的想法會離開你的電腦
隱私邊界要單獨看。本地自架跑起來的只是介面與仲介程式；每一次生成，你的產品想法（以及優化後的版本）都會送到 SiliconFlow 的雲端 API，參考網址的內容則經 ModelScope 的 MCP 端點取回。程式裡沒有接本地推理模型的選項，接不了 Ollama 這類本機模型。repo 原始碼裡看不到遙測或廣告程式碼，這點乾淨；但「本地部署」四個字在這裡的意思是自己跑介面，推理與資料處理都在雲端。商業上敏感的想法、還沒公開的產品計畫，要不要送進第三方 API，這個判斷得自己先做。
想試的兩個入口
線上入口在 ModelScope 創空間的工作室 JasonRobert/Vibedocs；作者也在 B 站放了示範影片。想自架的人，條件是：clone 儲存庫、建 Python 3.11 環境、pip 安裝 requirements.txt、到 SiliconFlow 官網免費註冊並把 API key 寫進 .env，然後 python app.py，介面會起在本機 7860 埠。偏好容器的話，Dockerfile 與 docker-compose.yml 都在 repo 裡，DEPLOYMENT.md 另有部署細節與故障排除；.env.example 也提醒不要把真實金鑰提交進版本庫，對第一次自架 AI 工具的人算是友善的文件設計。
想先看看輸出的長相再決定，repo 附了一份完整範例 HandVoice_Development_Plan.md：輸入想法是「做一個 AR 手語翻譯 App」，輸出方案含產品概述、系統架構圖、技術選型（React Native、TensorFlow、MongoDB 等）、六個月的階段時程，以及每個功能模組的編程提示詞，章節、圖表、提示詞都攤在檔案裡，可以直接讀。判斷這種生成文件的價值，看範例永遠比看宣稱快。
九個月沒動的專案，該有的預期
活躍度是採用前要吞下的部分。最後一次 commit 在 2025 年 11 月 21 日，內容是把社群 QR code 圖檔換成 JPG 的文件更新；路線圖上 v2.1 的更多模型支援、團隊協作、版本管理，以及 v2.2 的行動版與多語言，全部停在計畫階段。issues 清單是空的，討論區也沒有開啟，遇到問題只能自己讀碼。不過文件面倒是齊全：使用者指南、部署指南、安全政策、給 AI 協作工具看的架構說明都在 repo 裡，對一個停更專案來說，棄坑前的整理算是做得完整。貢獻者名單上兩個帳號並列：作者（原帳號名 JasonRobertDestiny，現改名 calderbuild）54 次 commit，claude 帳號 55 次，一半提交來自 AI 工具，跟這個專案所在的 vibe coding 主題正好互相印證。同樣把注碼壓在 AI 編程工作流的還有我們介紹過的 Vibe Kanban，它的處境值得對照；把 vibe coding 拿去做文化創作的案例，可以看 vibary.art 的故事。
誰適合用它：需要把想法快速變成固定格式文件的人（專題口試、內部評估、提案底稿），以及想直接借用它的系統提示詞與後處理寫法的人，MIT 授權讓整支程式可以合法拆來改，那支一百多行、含黑名單與圖表規格的系統提示詞本身就是一份可以借來用的工程資產，就算不跑整個工具，把提示詞拆去自己的工作流也符合授權。誰該繞開：需要活躍維護與多模型支援的團隊、堅持本地推理的人，以及對資料出門有硬性顧慮的場景。個人開發者落在中間地帶，可以先問自己一個問題：你的瓶頸是沒有想法、還是沒有文件？前者 VibeDoc 幫不上忙，後者它把流程收斂成填想法、按生成、等輸出幾個動作。生成的提示詞若要長期累積管理，可以另外看看 YPrompt 的提示詞庫做法。
回到開頭的對比。VibeDoc 把「問模型要一份方案」變成結構固定、圖表齊全、可以直接匯出的文件，這個約束本身就把整份儲存庫變成可引用的資產。代價也寫在明處：模型鎖在 Qwen2.5-72B，推理在雲端，更新停在 2025 年 11 月。看 star 數決定跟不跟是倉促的判斷；回到自己的交付場景反而具體：文件要不要交給別人看、想法能不能出門，這兩個問題有答案，選擇就清楚了。
