Manus 的 Vibe 模式，跟一般 AI 對話到底差在哪

來，趁空寫一篇！Manus新手使用的時候會發現Vibe方式跟其他AI平台不太一樣，怎麼點數消耗的那麼多！而且還沒做好？或是做到一半就斷掉？這是因為Manus不是聊天助理，你不能用聊天助理的方式來跟它溝通。同樣完成留言裡的網站，從規劃到完工我一步到位只花了1450點數，扣掉每天贈送的300點，實際消耗1150點，前後端、拉新裂變、未來訂閱制預備使用的金流都有，但類似的工具其他人卻可能花了8000點以上。

到底為什麼會這樣？？？先說明一下，圖片的內容我沒有全部寫在文章內，像是後端先行我就沒寫在文章內，反正看不懂就問 AI 囉！

精準指令的本質：讓 AI 聽得懂你的思考方式，而不是你的語言而已

在使用 Manus 時，很多人會犯一個原則性的錯誤，不是全天下男人都會犯的那一種，而是使用者會以為自己是在『對話』，但其實正確的溝通姿勢應該是『規格化』。

Manus 並不是一個聊天助理而已，它是一個可以自主規劃、調用工具並在沙盒中執行任務的Agent，換句話說，它不需要你去討好它的理解能力，而是需要你直接了當的提供足夠清晰的『任務結構』，讓它能少推理、多執行。

要做到這件事，你就得先掌握這個核心概念 #結構化提示 Structured Prompt Engineering。

結構化提示的目標是讓你的一句一句打上去、非結構化、模糊又自己改來改去修正的需求們，被轉譯成 Manus 能直接行動的五個關鍵元素：目標（Goal）、角色（Role）、步驟（Steps）、限制（Constraints）、格式（Format）。

很熟悉對吧？上下文工程也是在搞這件事，只是這件事在會用點數來換耐心的 Manus 會更加明顯。（ChatGPT有耐心，可以陪著你慢慢討論出正確的可裡姊的框架指令。

也就是說，這五個部分組合起來，就是你該知道的所有 AI 代理的母語。

為什麼 Manus 必須靠結構化提示運作

在傳統的 LLM 對話中，錯誤多半出現在『事實幻覺』，也就是模型編造了一個不存在的事實，唬爛久了連它自己都會相信，所以GPT會跟你爭論它說的才是對的。😅

但對於 Manus 這種具備規劃與執行能力的自主型代理來說，最致命的風險是『規劃幻覺 Planning Hallucination』，它會裝忙，看起來在很認真的計畫與執行，但整個計畫無法落地、缺乏邏輯銜接，或根本調不到對應的工具。

這就是為什麼 Manus 強調要 #先結構再思考：當你提供 Goal、Steps 與 Constraints 時，等於幫它建立了一個可以安全執行的框架。這個框架不只用來輔助理解，也是防止你浪費點數成本跟時間的保護。

結構化提示的五個核心要素（這我大概強調過八百次了）

1. Goal：明確定義 #最終成果，而非模糊方向

目標不是一個主題啊啊啊啊，目標是一個結果。你寫年度目標的時候，如果都把目標當作主題來寫，那這個主題就可以在下一年繼續沿用，因為這個目標不會變成結果XDDD

一個好的 Goal 句式，應該是在 Manus 執行完畢後，你能、可以、知道如何驗收的最終產物。

【錯誤示範】
① 幫我做一個專案管理網站
② 請幫我分析一下這份數據

【正確示範】
① 建立一個具備使用者認證與專案/任務管理功能的輕量級全端網站。
② 分析 `/home/ubuntu/sales_data.csv`，找出影響銷售額的前三大因素並以圖表呈現。

精準的目標 Goal 會讓 Manus 直接生成具體的任務規劃，而不需要浪費點數去猜你的真實意圖。

2. Role：指定 #以誰的邏輯執行

角色不只是職稱！不是職稱！不是職稱！角色真正在告知 AI 的是思維模式。

當你說『以資深全端工程師的角色來完成此任務』，你就是在告訴 Manus『請套用工程師的決策慣性與品質標準』。

不同的角色會改變 AI 回應或生成的行為策略。

數據科學家在意可重現性、前端設計師在意視覺層級、專案經理在意交付節奏。

Role 就是讓 AI 在你的世界觀中思考，避免出現切角錯位或邏輯跳躍的情況。

3. Steps：拆成 Manus 能 #原子執行 的計劃步驟

這個是提高 Manus 運作效率的關鍵，當然也節省點數的關鍵。

每個 Step 都應該是一個可以直接執行的最小單元，不需要manus在花點數去額外推理，也不需要跟你再三話嘮式確認，當然也不需要 AI 再思考要怎麼拆才好。

舉例來說：
① 使用 `webdev_init_project` 初始化專案（含資料庫與使用者認證）。
② 定義三個模型：User、Project、Task。
③ 撰寫使用者登入與註冊 API。
④ 建立前端頁面，串接登入與任務清單功能。

上面的每一步都是我前面說的可驗證、可執行的 #原子操作。

這樣 Manus 才能在每個執行階段，正確調用對應的工具（file、shell、webdev_init_project），而不是一直浪費點數、回頭重新解讀整個任務。

也就是說，如果你只說『幫我實作後端』、『幫我把 API 寫完』，
Manus 就會陷入模糊決策的困境，反覆的重構與試錯排錯，消耗大量運算成本的結果就是你的點數像破洞的口袋，一直在漏錢錢啊！

反正就是你的 Steps 要精準，每一步都要是『可直接成為一個 tool call』的單位。

像這樣叫精準：
．初始化專案（web-db-user）
．寫 models.py 的三個模型
．實作登入/註冊兩個 API
．實作 project CRUD API
．寫前端登入頁
．寫前端 project 列表頁
．暴露端口

像這樣叫不精準：
．幫我做後端
．幫我把 API 實作完
．幫我做前端

這種會讓 Manus 直接迷路，然後花很多很多點數之後還不見得找得到原路。

4. Constraints：把限制寫得 #像不可再被解釋的法律

限制的目的，是為了讓 AI 不需要再進行多餘的推理，推理，需要很多點數！

一個不夠精準的限制，會造成誤解、重寫、不必要的嘗試、確認本路徑失敗，然後重投再來過。點數就是這樣被耗光的，跟青春一樣！

以下是清楚與模糊的對照，看得懂就看吧，看不懂你就.......看留言的連結！

模糊限制 vs 精準限制
① 使用輕量級框架 vs 後端必須使用 Python/FastAPI
② 產生圖表 vs 使用 seaborn 或 matplotlib，並輸出為 PNG
③ 要能登入 vs 使用者密碼必須經過 hashing，並使用 JWT 作驗證
④ 有 API 文件 vs 輸出 Markdown 文件，列出所有路徑與參數範例

限制越具體，Manus 的推理成本就越低，點數的耗用就越少。

這也是整個『後端優先原則』與『小步快跑策略』的基礎。

後端優先是為了防止前後端交錯導致的狀態錯亂，網站做出來之後會需要滅蟲大隊；小步快跑是用來確保每一次修改都能獨立驗證，不會造成不可預期的副作用，例如系統崩潰掉。

5. Format：指定 #結果可驗收的交付形式

Format 是最容易被忽略，但卻也是最具控制力的部分。Format 直接決定了 Manus 的輸出格式、結構，還有媒介。

例如：
．最終產物為 Markdown 報告，包含三張圖與分析段落。
．生成一個可運行的 FastAPI 沙盒應用。
．以 JSON 格式輸出所有結果，鍵名為status、data、error。

這樣 Manus 才會直接在正確的媒介上輸出，而不是回傳一大段文字，然後你也看不懂，所以連整理都不知道從何下手。

Format 是讓機器輸出成可用成果，而不是參考回覆的關鍵。

三、從『對話』轉向『規格書』

理解這五個元素後，你會發現：所謂的精準指令並不是在寫漂亮的句式，而是在編寫一份可執行可驗證的工程規格書。

【一份理想的指令，應該像這樣】
目標：
修正 `/users/` 接口返回敏感數據的錯誤。

角色：
資深後端工程師。

步驟：

1. 修改 `/home/ubuntu/project/app/routes/users.py` 中的 `read_users` 函數，使其不再回傳 ORM 物件。
2. 重新執行測試以驗證修復結果。

限制：
必須使用 `file` 工具的 `edit` action 進行修改。

格式：
回傳修復結果與測試通過的日誌。

【Manus 接收到這樣的結構化提示後】
會直接生成精準的工具操作

{
"brief": "修正 /users/ 接口返回敏感數據的錯誤。",
"action": "edit",
"path": "/home/ubuntu/project/app/routes/users.py",
"edits": [
{
"find": "return users",
"replace": "return [UserSchema.from_orm(user) for user in users]"
}
]
}

這就是 #原子性修改 Atomic Edit 的用途。

一次只修改一個明確的目標，不要重構整段邏輯，也不讓 AI 進行額外思考。

這樣的操作有啥好處？精確、低成本、可追蹤，而且可以保持專案狀態一致性。

每一次的修改都可逆、可審查、可驗證，最關鍵的是：不會突然跟你說沙盒當機了。

四、讓 AI 成為你的工程師，而非你的翻譯器

我要再強調一下，#精準 不只是為了讓 AI 聽懂你的意圖，真正的用途是讓它不必再透過猜來釐清意圖。

所以當你用 Goal、Role、Steps、Constraints、Format 五項結構撰寫提示時，你其實是在完成一件更高層次的事：你讓 AI 以人類的『思考邏輯』來運作，而不是只流於語言表面而已。

模糊的指令讓 Manus 變成語言翻譯器；結構化的指令才會讓它變成工程執行者。

來結論一下，重點就是以下五個啦！

1. 明確性：任何可以量化的內容都不應該留白
2. 可執行性：每一段指令都要能對應到一個明確的最小行動
3. 原子性：修改永遠應該是最小單位的變更
4. 可追蹤性：所有輸出都應可驗證、可還原
5. 狀態一致性：每一步的小結果都應該維持環境穩定，不要影響其他部分

當你真正理解這五個原則，你才會發現 Manus 不再是一個『要教它怎麼理解我個人所列出的模糊指令』的 AI，而是一個 #你提供結構，#它就照規格執行 的專業代理。

然後，跟 緯育TibaMe 合作的Vibe Coding實戰，使用優惠碼『JOANVC』可以享有講師88折優惠喔！但課程內不會教Manus蛤～～～這一篇主要是因為剛好可以把Vibe Coding的觀念講清楚，所以直接用Manus為例，更完整的內容會在課程內說明啦！

報名連結在一樓！

本文原發表於 2025/11/24 的 Facebook 貼文，原文照登，僅調整網頁排版；文中提及的產品、價格與活動以當時為準。