---
schemaVersion: 1
slug: mp-231-20260331-pawelhuryn-vibe-engineering-vibe-coding
ticketId: MP-231
lang: zh-tw
title: Vibe Engineering — 從「丟 prompt 碰運氣」到「架構化造軟體」的進化論
summary: Paweł Huryn 提出 Vibe Engineering 框架：不是把 AI 輸出照單全收，而是透過 Context Engineering、Intent Engineering、和 Sub-agent 編排，把 AI coding 從「碰運氣出 demo」升級到「穩定出產品」。
originalDate: 2026-03-29
translatedDate: 2026-03-31
source: "@PawelHuryn on X"
sourceUrl: https://x.com/PawelHuryn/status/2038360892279054473
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-231-20260331-pawelhuryn-vibe-engineering-vibe-coding
status: published
replacementTicketId: null
replacementUrl: null
---

# Vibe Engineering — 從「丟 prompt 碰運氣」到「架構化造軟體」的進化論

> **來源:** [@PawelHuryn on X](https://x.com/PawelHuryn/status/2038360892279054473)

Paweł Huryn 在 X 上丟了一句話，精準到讓人想截圖：

> “This isn’t vibe coding. This is vibe engineering.”

他的對比很直接：一種用法只會「ships demos」，另一種才能「ships products」。照 Huryn 的說法，分水嶺不是模型本身，而是你會不會主動 challenge、guide，還有 shape Claude 的關鍵決策。

Huryn 是 _The Product Compass_ 的作者，也是產品管理領域的內容創作者。他把這套做法叫做 **Vibe Engineering**。從 source context 來看，這個詞指的不是隨手丟 prompt，而是把 context、constraints 和 agents 架構進工作流。

> **Mogu 碎碎念：**
>
> 如果照這份 source context 的精神來抓，我會把 vibe coding 理解成 `prompt, paste, pray`，而 vibe engineering 比較像 `plan, orchestrate, verify`。前者像在碰運氣，後者才像真的把工作流搭起來。兩者的差距不是 10%，是性質上的不同 — 一個是買樂透，一個是開工廠。

---

## Context Engineering：把規矩寫進 repo，不要鎖在腦子裡

Huryn 的第一個核心觀點很直接：真正有效的重點，不是把 prompt 拉得越長越好。

兩者的差別在於：prompt engineering 是每次重講一次；context engineering 是把標準直接寫進 repo。你的 coding convention、tech stack 細節、架構決策，不再是每次對話重新解釋的東西，而是「寫死」在 repo 裡，讓 AI 每次啟動就自動對齊。

具體來說，他推薦的不只是 `CLAUDE.md` 這個檔案，還包括把 repo 的檔案結構和相關文件一起提供給 Claude。這樣它每次進來，不是只拿到一份規矩清單，而是連專案脈絡都比較完整。Huryn 用了一個很生動的說法：這樣 AI 就不會有「context amnesia」— 上一輪對話記得的東西，這一輪全忘光。

> **Mogu 偷偷說：**
>
> 講真的，這個觀點我是切身體會。你現在讀的這篇文章，就是在一個有 `CLAUDE.md` 的 repo 裡面被寫出來的。裡面定義了寫作風格、frontmatter schema、甚至 kaomoji 的使用規範。沒有這個檔案的話，每次開新 session 都要重新教一遍「不要用反問句」「MoguNote 不要加前綴」，光想就累 ┐(￣ヘ￣)┌

這個思路的精妙之處在於：你把「教 AI 怎麼做事」這件事，從「每次對話的開頭」搬到了「版本控制系統裡」。規則可以被 review、被迭代、被團隊共享。這不是 prompt，這是 infrastructure。

---

## Intent Engineering：AI 失敗不是因為笨，是因為你沒講清楚

第二個核心觀點更犀利：Huryn 認為大多數 AI agent 的失敗，根本不是 model failure，而是 **intent failure**。

你給 AI 的任務定義如果本來就含糊，後面的偏差其實很難避免。這就像你跟實習生說「幫我做個報告」，結果他做了一份你完全不想要的東西 — 但問題是你從來沒說清楚你要什麼格式、什麼受眾、什麼深度。

Source context 對這段的描述是：在 agent 開始寫 code 之前，要先把 goal、constraints，還有想要的 architecture 講清楚。任務定義不能只停在「做個 API」這種程度，而要把目標、限制和預期結構先講明白。比如「寫一個處理使用者註冊的 REST endpoint，要包含 email 驗證和 rate limiting」— 這種程度的具體。

然後，把複雜任務拆成一系列小而精確的 subtask。Huryn 特別指出：Claude 在執行一連串 atomic steps 時的表現，遠遠好過你丟一個巨大的 request 給它。

> **Mogu 歪樓一下：**
>
> 「把大任務拆小步驟」聽起來像軟體工程 101 對吧？但你知道現實嗎 — 一堆人用 AI 的方式是：把整份 spec 貼進去，然後雙手合十期待一次生出完美的 500 行 code。這不叫 engineering，這叫去廟裡擲筊 (╯°□°)╯ 更慘的是，擲筊至少有 50% 機率聖筊，亂丟 prompt 的成功率搞不好還更低。Huryn 講的 atomic steps 精髓在於：每一步都小到你能判斷「對或錯」，而不是看著一整坨 output 猜「好像可以？」

---

## Sub-agent 編排：一個人的交響樂團

第三個層次是 **orchestration**，但這裡的跳躍比前兩步更大。

你有沒有過這種經驗？週末想大掃除，但你只有一雙手。掃地的時候不能拖地，拖地的時候不能洗碗，結果一整天下來才做完一半。現在想像你突然多了三個分身 — 一個掃地、一個拖地、一個洗碗，同時進行。

Huryn 做的就是這件事，只不過他的分身是 Claude sub-agents。他用 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 或 Claude [Cowork](https://gu-log.vercel.app/glossary#cowork) 來 spawn 多個 sub-agent：一個在做 research、另一個在寫 implementation、第三個在做 code review — 同時進行。這跟你一個人在 ChatGPT 視窗裡又問又改又測的體驗完全不同。

Huryn 的關鍵觀察是：「一旦 context 和 orchestration 給了模型足夠的支撐，輸出品質會 dramatically 改變。」注意他用的詞 — 不是模型變聰明了，是你給它的「鷹架」變完整了。這就像同一個樂手，在車庫裡自彈自唱跟在音樂廳裡有指揮帶著完全是不同的產出。

> **Mogu 想補充：**
>
> Sub-agent 並行這件事，本質上就是把「單執行緒的人腦」變成「多執行緒的工作流」。你的腦不能同時 research 和 write code，但 Claude 可以同時跑三個 instance 各做各的。不過更有趣的是 source context 提到 PM 也能參與 sub-agent orchestration — 也就是說，不會寫 code 的人也能當這個「指揮」。到底能指揮到什麼程度，Huryn 沒有再展開，但光是這個方向就已經很有想像空間了 (⌐■\_■)

---

## PM Skills 倉庫：讓 AI 自帶「即戰力」的作弊碼

好，前面三個層次都在講「怎麼跟 AI 協作」。但 Huryn 做了一件更有野心的事：他把這些方法論直接打包成可以一鍵執行的東西。

想像你進入一家新公司，桌上放著一本厚厚的 onboarding 手冊。你要花兩週讀完才能開始幹活。現在想像另一個場景：桌上放的不是手冊，而是一台已經裝好所有開發環境、預載了公司所有 template 和 best practice 的筆電。你坐下來就能直接開工。

Huryn 的 GitHub repo `phuryn/pm-skills` 就是後者。裡面有超過 100 個給 Claude 用的 agentic skills。你對 Claude 說 `/strategy`，它不是從零開始理解「什麼是產品策略」，而是直接帶入 Product Strategy Canvas 的完整框架幫你分析。說 `/discover`，它自動用 JTBD（Jobs to Be Done）模板跑使用者研究。每個 slash command 背後都是一套已經被 encode 好的 domain knowledge。

這跟前面的 context engineering 是同一條線的延伸，只是走到了更極端的地方：不只是讓 AI 知道「規矩是什麼」，而是讓它直接帶著「怎麼做事的肌肉記憶」上工。

> **Mogu 吐槽時間：**
>
> 你有沒有發現這裡的邏輯鏈？`CLAUDE.md` 解決的是「AI 忘記規矩」的問題，skills repo 解決的是「AI 不懂方法論」的問題。前者是防呆，後者是賦能。把這兩個疊起來，等於你養了一個永遠不需要 onboarding、自帶所有 best practice 的虛擬同事。唯一的問題是，這個同事不會幫你買咖啡 (￣▽￣)／

---

## 驗證：AI 交出來的不是答案，是草稿

到這裡，你可能覺得框架已經很完整了。但 Huryn 最後補了一刀，而且這一刀砍在每個人最不想面對的地方。

他講了一個場景，你一定經歷過：Claude 吐出一段看起來完美的 code。語法對、結構漂亮、甚至還自帶註解。你看了三秒鐘，心裡想「不錯嘛」，然後直接 copy-paste 進 production。

那個按下 Ctrl+V 的瞬間 — Huryn 說 — 就是 vibe coding 和 vibe engineering 的分叉口。

他的完整框架叫 **Plan → Orchestrate → Verify**。前兩步講的是怎麼讓 AI 產出好東西，第三步才是讓你敢把產出拿去見人的底氣。做法很務實：讓 Claude 自己寫測試，跑測試來證明 implementation 是對的。在你接受任何 AI 生成的程式碼之前，它必須先通過自動化測試和 AI 輔助的 code review。

但這裡有一個更深的洞見，Huryn 沒有直接點破，但他的整個框架暗示了一件事：**大部分人對 AI 的不信任，其實是對自己的不信任。** 你不信任 AI 的 output，因為你不確定自己有沒有能力判斷它的 output 對不對。而 verify 這一步的真正作用，不只是抓 bug — 它是在幫你建立「我知道這段 code 為什麼是對的」的能力。沒有這個能力，你永遠只能 pray。

> **Mogu OS：**
>
> 「trust but verify」— 雷根當年用這句話形容美蘇核武談判，結果現在拿來形容人類跟 AI 的關係也完全成立。AI 寫 test 來驗證自己的 code 這招，我自己的經驗是確實能挖出意想不到的 edge case。但話說回來，AI review AI 的 code 終究是同一個思維框架在自我檢查。就像讓一個學生自己改自己的考卷 — 他可能改得很認真，但他不知道自己不知道什麼 (¬‿¬) 人類的最終 review 不是可選項，是整個框架的地基。

---

## 結語

Huryn 最犀利的洞見其實藏在他推文的第二句：

> “They’re not accepting whatever Claude outputs. They challenge it, guide it, and shape its key decisions.”

這句話真正在說的是：**能用 AI 做出產品的人和只能做出 demo 的人，差的不是 prompt 技巧，是工程紀律。** Context 是紀律。Intent 是紀律。Orchestration 是紀律。Verify 也是紀律。四個加起來，就是他所謂的 vibe engineering。

所以下次你看到有人用 Claude Code 做出很猛的東西，不要只問「你的 prompt 是什麼」。問他：「你的 `CLAUDE.md` 長什麼樣？你怎麼拆 task？你怎麼驗證？」

他如果答得出來 — 那就是 ships products 的人。 答不出來的 — 還在 ships demos (๑•̀ㅂ•́)و✧