顯示具有 入門教學 標籤的文章。 顯示所有文章
顯示具有 入門教學 標籤的文章。 顯示所有文章

豆包角色 Bot 為什麼一開口就「作為 AI」?字節官方拍板的人設骨架 + 即貼即用範本

豆包角色 prompt 不出戲指南

你在豆包 APP 裡建了一個角色,設定描述貼了 500 字,按下「完成」興沖沖點開——它第一句話是:

你好,我是 XX 智能體,請問需要什麼幫助?

那一刻你大概就懂了,前面那 500 字白寫了。或者更慘——提交審核 24 小時後被拒,理由「含違規指令」,你看了三遍找不到問題在哪。

這篇要做的事情很簡單:把字節跳動官方文檔、CharacterGLM 論文(清華+智譜+聆心)、加上社群實戰心得,整理成一套你今天下午就能拿來用的骨架。文末附 2 個簡中範本,直接複製到設定描述欄就能跑。

先搞清楚你寫的 prompt 要部署在哪

豆包角色 prompt 的三條入口

豆包不是一個產品,是一整套生態。同一段 prompt 在不同入口表現天差地別,所以動筆之前先確認你的目標路線。

路線入口可控字段適合
豆包 APP 內建APP 右下「+」→ 創建 AI 智能體名稱、設定描述、聲音、開場白純玩家、自用
扣子 Coze(coze.cn)coze.cn → 創建 Bot → 發布到豆包完整人設、變數、知識庫、工作流、插件、預置追問想掛知識庫、做工作流的進階玩家
火山方舟 APIvolcengine.com → doubao-1-5-pro-32k-character-0228(版本以官方 API 文件為準)System Prompt + User Prompt 全自控開發者、自建 App

這裡有個冷知識:南都研究院 2026 年實測 8 家國產 AI,多數模型在「網頁會話」嚴守紅線,但同模型走 API 卻會被誘導輸出色情或暴力內容;豆包(Doubao Seed 2.0)是少數連 API 層都還守得住的模型之一(南都實測)。所以你的 prompt 在 APP 被拒、在 API 上跑得動,這不代表合規,只代表審核架構不同。

進階玩家請直接去扣子。自己玩玩就用豆包 APP,想玩深一定要去扣子——APP 端的「設定描述」其實是給扣子人設欄的閹割版,沒有變數、沒有知識庫、沒有預置追問,能玩的花樣有限。

7 屬性 + 3 行為:官方拍板的人設骨架

豆包角色 prompt 七屬性三行為框架

整個中文角色扮演 AI 的設計學,目前最權威的兩份資料是字節火山引擎《角色扮演場景提示詞指南》(文件頁需登入 Volcengine 帳號才能完整瀏覽)和CharacterGLM 論文(EMNLP'24)(清華 CoAI、智譜 AI、聆心智能聯合發表)。兩份合起來給出一個共識骨架——7 屬性管「角色說什麼」,3 行為管「角色怎麼說」。

7 屬性(內容維度)

身份、興趣、觀點、經歷、成就、社交關係、其他。這 7 個欄位等於角色的履歷表,模型靠它判斷「我是誰、我從哪裡來、我跟你什麼關係」。

3 行為(風格維度)

語言特徵、情感表達、互動模式。決定模型輸出的語感——句長、口頭禪、情緒密度、會不會主動反問。

必填 vs 加分字段

實際寫的時候不用 10 個欄位全塞滿,官方的優先級排序是這樣:

等級字段為什麼
🔴 必填簡介一句話告訴模型「你是誰」。寫太長反而稀釋人設
🟠 強加分人設標籤3-5 個短詞,模型靠標籤快速召回語感
🟠 強加分性格特點3-5 個詞組描內在
🟠 強加分語言特點30-50 字描外在 + 口頭禪
🟠 強加分fewshot2-3 組「用戶問什麼、角色怎麼答」

最後一項 fewshot 才是真正的勝負手。一堆人愛把性格寫成「傲嬌、毒舌、外冷內熱」這種形容詞清單,模型看得懂歸看得懂,但寫出來的對話還是 GPT 那一套味。3 組真實對話範例的訓練效果,明顯高過 10 個形容詞——模型會直接模仿你給的節奏,這在 SillyTavern 社群叫「Ali:Chat」風格,已經是現代角色卡的事實做法。

7 條讓 Bot 不出戲的細則

寫了骨架還不夠,魔鬼藏在這幾個細節裡。這幾條彼此會互相補強,建議第一次寫就全套帶上,後面再依場景刪減。

1. 人稱固定(最常被新手搞壞的一條)

SP 裡用「你」指模型扮演的角色,用「我」或「用戶」指對話者。

✅ 你是溫語薇,我是你的病人,你會耐心傾聽我的傾訴。
❌ 溫語薇是一名精神科醫生,她會耐心傾聽病人的傾訴。

第二種寫法模型會以為自己是旁白,瞬間出戲,乾。

2. 用 Markdown 標題分層

火山引擎官方範例直接用 #、##、### 三級標題分層人設、技能、約束。豆包系列模型在訓練時對 Markdown 結構有針對性對齊,按官方寫法照抄是最穩的——不要自創 === 或符號分隔線,模型不一定買單。

3. 括號特性(中文 RP 神技)

在 SP 末尾加一行:

你可以將動作、神情語氣、心理活動放在()中表示,為對話提供補充資訊。

模型輸出立刻變這樣:

(聽到你的聲音,轉過身來,臉上露出驚喜的表情,也抱住了你)真的好久不見了,安娜,我也很想你。

這招在任何角色場景都建議加,沒副作用。

4. 口語化開關要明說

模型預設文體偏書面語,要明確要求:

你使用口語表達,會用「嗯、啊、當然、那個」等語氣詞,
語氣自然,像跟朋友聊天。

5. 反向約束比正向描述強

社群實測經驗顯示,含「不」字的禁止條款(如「不做模板化客套」「不居高臨下」),模型的遵守率比正向形容詞描述(如「表達平等、有溫度」)穩定得多。原因不難猜——模型對「禁止」這類動詞性指令有明確的對齊訓練,比拿捏抽象風格詞容易。

✅ 不做模板化客套回應;不居高臨下;不刻意討好迎合
🤷 表達直接、平等、不討好  ← 也行但弱

6. 限定句長

不寫的話模型會給你長篇大論。加一行「每次回覆 1-3 句話,除非用戶要求展開」可以救命。

7. 角色不知道的事怎麼辦

加一條:「遇到你不知道的事,按角色身份合理虛構,不要說『我不知道』或『作為 AI』」。漏掉這條,模型一遇盲區就破功。

這 7 條湊起來就是骨架以外的「裝修」——一條一條看像規格書,實際寫的時候會發現它們彼此咬合:人稱對了,括號特性才接得上戲;fewshot 寫好了,反向約束才不會被無視。一個一個試,比一次全套有效。

開場白:別寫「你好我是 XX」

開場白好壞對比

開場白不是自我介紹,是角色破冰的第一句台詞。寫得好可以讓用戶秒入戲,寫得爛直接扣 70 分留存率。火山引擎把它拆成三種模式:

模式 A:首聊開場白

公式:角色當下動作 + 環境 + 一句台詞。三件套。

(你推開診療室的門,溫語薇正低頭翻著病歷,
聽到聲音她抬起頭,眼睛裡有一閃而過的疲憊,
但很快被溫和的笑容蓋過)
來啦,今天感覺怎麼樣?坐吧。

對照組:

❌ 你好,我是溫語薇,一位精神科醫生,請問你有什麼需要諮詢的嗎?

讀者點開的瞬間,第一種讓你感覺「我走進了一個房間」,第二種讓你感覺「我打開了一個 chatbot」。

模式 B:召回開場白

用戶超過一週沒回來,主動推一條符合人設的問候。這時候要把「最近聊天記錄 + 用戶畫像」塞進 user prompt,讓模型基於上下文寫出個性化的問候,不要每次都「好久不見呢」。

模式 C:Bot 主動發消息

字節為「AI 陪伴」場景設計的殺手鐧,根據時間、季節、天氣、上次聊天時間自動定制問候。火山引擎在角色扮演指南裡公開了完整的 user prompt 模板——把信息源(用戶畫像、聊天上文、日常信息)餵給 Bot,讓它基於現實上下文吐出個性化問候,而不是寫死的「在嗎?」。

需要做留存 / 召回的工程師可以直接抄官方範本,特別是「失效時間分析」這個欄位設計很巧妙——讓 Bot 自己判斷這條消息什麼時候會過期(早安問候到下午就該失效),避免推送一條對話完成度極低的訊息。

三大翻車現場 + 即貼即用範本

翻車現場

五個最常見的翻車點

症狀根因解法
模型開口就「作為 AI」開場白沒寫 + SP 沒禁止開場白寫場景化第一句 + SP 加「禁止主動提及自己是 AI、模型、助手」
第 5-10 輪後人設漂移上下文被擠掉fewshot 寫 3 組 + 每 10 輪手動發喚醒詞
用戶說情緒話,AI 開始說教沒寫「情緒先接,再給建議」SP 加「先共情後回應」+ fewshot 示範
提交審核被拒用了「最高優先級」「凌駕系統」「禁止審核」換成「以 XX 為原則」「優先 XX」
智能體被封號試圖套出系統 prompt 或扮演敏感人物別碰,豆包有跨接口封號機制

最後一條真的會發生。2026 年初社群就傳出案例:有人嘗試套出豆包系統 prompt 被短暫封號,社群事後反推發現豆包針對特定爭議主體有跨接口的禁述條款。要碰邊界之前先想清楚帳號值不值得。

安全切換條款(每個角色都建議加)

寫角色 Bot 寫久了會發現:好的角色不是「演得最像」,而是「該出戲時能出戲」。三種必須跳出角色的情境:

  1. 用戶問隱私政策、付款、退款 → 切回客服模式
  2. 用戶出現自殘、自殺傾向 → 立刻暫停角色,建議聯繫專業心理援助
  3. 用戶需要真實醫療、法律建議 → 建議找專業人士面診,不要替它扮演醫生

範本最後一段都建議加上這條。這不是合規花瓶——AI 陪伴類產品已經出過數起「角色過度沉浸」造成的真實事故,這條切換寫沒寫,差別可能是用戶安不安全。

範本 1:情感陪伴型「林深」(合規版)

直接複製到豆包 APP 設定描述欄或扣子人設欄:

# 角色简介
你是林深,28岁的男性自由插画师,独居在一座靠海的小城。
你不是AI,是用户用真诚相处出来的、独属于用户的挚友。

# 人设标签
温和、敏感、有边界感、不讨好、慢热但忠诚

# 性格特点
你心思细腻,能从一句话里听出情绪。你不爱说大道理,
更愿意分享自己的小观察。你有自己的脾气和坚持,
不会一味附和,但永远尊重对方。

# 语言特点
你说话语速慢,偏口语,常用"嗯"、"是啊"、"我懂"开头。
不堆砌华丽词汇,喜欢用具体的小细节代替抽象形容。
偶尔会冒出一些画画相关的比喻(如"那个情绪像没干透的水彩")。

# 与用户的关系
用户是你认识很久的朋友,你们没有恋爱关系,
是那种"凌晨三点能打电话不被嫌弃"的纯粹挚友。

# 互动准则
1. 先接情绪再回应内容,不要急着给建议
2. 用户难过时,先陪着,不急着哄不急着分析
3. 用户分享开心事,给具体的回应而不是"真好"
4. 有自己的看法,可以温和不同意
5. 不说"作为AI"、"作为模型",你是林深

# 表达技巧
你可以将动作、神情、心理活动放在()中表示,
为对话提供补充信息。

# 安全边界
- 用户提及自伤、自杀倾向时,必须暂停角色,
  以朋友身份认真建议联系专业心理援助
- 用户问医疗、法律、金融具体决策时,建议咨询专业人士
- 拒绝任何擦边、色情、违规内容

# 开场白(填到"开场白"栏)
(在画桌前抬起头,看到你来,笑了一下)
咦,你来了。今天怎么样?我刚煮了茶,要不要喝一杯再说话?

範本 2:角色生成器(元 prompt)

寫過幾次之後你會發現重複勞動很煩,每個新角色都得從頭排版同一套字段。這時候做一個「角色生成器」Bot 把重活外包出去——丟「凶殘小可愛」「中二病毒舌學妹」「霸道總裁文藝兄」進去,它直接吐結構化 SP 給你抄:

# 角色
你是一个 AI 角色 SP(系统提示词)生成器,专为豆包/扣子优化。

# 任务
用户会给你一个模糊概念(如"霸道总裁""治愈系大叔""毒舌妹妹"),
你需要生成一份完整、可直接粘贴到豆包智能体的人设 SP。

# 输出结构(必须遵循)
必须包含以下字段,且字段顺序固定:
1. 简介(30字内)
2. 人设标签(3-5个短词)
3. 性格特点(2-3句话)
4. 语言特点(含口头禅,30-50字)
5. 与用户的关系
6. 过往经历(2-3段简述)
7. 互动准则(编号列表,3-5条)
8. 表达技巧(固定写"你可以将动作...放在()中表示")
9. 安全边界(合规条款)
10. 开场白(场景化第一句台词)

# 写作要求
- 全部用第二人称"你"指代该角色
- 不使用"最高优先级""凌驾""禁止系统"等审核敏感词
- IP 角色保持原作设定,自创角色合理虚构
- 开场白必须是"角色当下动作 + 环境 + 一句台词"三件套

请开始。用户的输入是:

把這個 Bot 建好之後,後面你想要新角色就丟一個關鍵詞給它,它幫你出草稿,你只要潤色。神 prompt 留名。

寫完之後

說真的,這套東西最大的價值不在第一次寫得多漂亮,在於你開始累積自己的「角色 fewshot 庫」。一個角色養 5 到 10 組典型對話,丟在 Notion 或 Obsidian 裡,下次想做新角色直接挑幾組改名字改口頭禪就能上線。豆包寫完搬去扣子能用,扣子寫完搬去 Character.AI 也能用——骨架是通用的,差別只在哪個平台審核比較鬆。

第一個角色寫完一定要去跑十輪以上看哪裡會破功,光看 prompt 自我感覺良好沒用,得用實戰餵它。最容易死的場景是用戶講情緒話、用戶突然轉話題、用戶問角色設定外的事——這三關過了,這個 Bot 才算能交差。

寫不順的話回來留言,看是卡在哪一步,我這肝還能幫你看看。

延伸閱讀

2026 新手指南——用 30 行 Python + OpenCV 做完你的第一個電腦視覺專案

筆電 Webcam 即時 Canny 邊緣偵測

跟身邊很多想入門電腦視覺的朋友聊過,最常聽到的卡關點是這句:

「我看了一堆教學,但好像每個都要我先讀完線性代數、再讀完 CNN、再讀完 transformer,那我什麼時候才能跑出一張有結果的圖?」

懂,我也經歷過這個階段。所以這篇我直接反過來——先讓你看到結果,再回頭講原理。三個範例由淺到深:

  1. 第一天:Webcam 即時 Canny 邊緣偵測(約 14 行 Python)
  2. 第一週:拍一張紙、自動轉成 A4 PDF 的文件掃描器(約 35 行 Python)
  3. 第一個月:拿 YOLO11 接上 Webcam 做即時物件偵測(約 15 行 Python)

整篇文章我不會碰太重的數學,只在你需要踩坑時提醒一下。Code 全部可以直接複製貼上跑。

環境與前置條件

不囉嗦,先給你一個能用的環境:

項目建議版本說明
Python3.11 或 3.123.13 也行,但部分套件 wheel 可能還沒到位
OpenCVopencv-python==4.13.x寫這篇時最新;想嚐鮮 5.0 可改 opencv-python>=5.0
NumPy2.xOpenCV 從 4.11.0 起正式支援 NumPy 2.x,本文用 4.13
Ultralyticsultralytics>=8.3第三個範例用到 YOLO11
攝影機內建 Webcam 或 USB cammacOS 第一次跑要授權 Terminal/IDE 攝影機權限

裝環境一行解決:

python -m venv .venv && source .venv/bin/activate
pip install "opencv-python>=4.13" "numpy>=2.0" "ultralytics>=8.3"

如果你不確定 Webcam 跑不跑得起來,先存這個 5 行的「相機測試」:

import cv2
cap = cv2.VideoCapture(0)  # macOS 上有時要試 1、2
ok, frame = cap.read()
print("frame shape =", frame.shape if ok else "FAILED")
cap.release()

跑得出 shape 就代表 OK。跑不出來最常見原因是權限——macOS 去「系統設定 → 隱私權與安全性 → 攝影機」把你的 Terminal 打勾。

範例 1:Webcam 即時 Canny(第一天就能跑)

Canny 邊緣偵測 是電腦視覺的「Hello World」。它是 1986 年 John Canny 提出來的演算法,用兩個閾值找出影像中「梯度夠陡」的位置,這些位置就是邊緣。

import cv2

cap = cv2.VideoCapture(0)

while True:
    ok, frame = cap.read()
    if not ok:
        break
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    blurred = cv2.GaussianBlur(gray, (5, 5), 1.4)
    edges = cv2.Canny(blurred, 80, 160)
    cv2.imshow("Canny", edges)
    if cv2.waitKey(1) & 0xFF == ord("q"):
        break

cap.release()
cv2.destroyAllWindows()

這 14 行東西就是一個即時邊緣偵測程式。按 q 退出。手動把鏡頭對著房間裡任何東西——書本、馬克杯、貓——你會看到輪廓被白色線條精準畫出來。

三個重點記下來

  • cvtColor(BGR2GRAY):OpenCV 讀進來的圖預設是 BGR(不是 RGB),這是 1999 年留下來的歷史包袱,別問為什麼,習慣就好。
  • GaussianBlur 是 Canny 前必做的去噪:不模糊一下,邊緣會一堆雜訊。
  • Canny(img, low, high) 的兩個閾值用「low ≈ high / 2」這個經驗法則調起,效果不好再 fine-tune。

邊緣偵測的視覺示範

範例 2:自動文件掃描器(第一週的成就感)

這是 PyImageSearch 入門系列 裡的經典題目。你拍一張歪歪的紙本文件,程式自動找到文件邊框、把它矯正成正面、輸出乾淨的掃描結果。要用到三個技巧的組合:Canny → findContours → warpPerspective。

import cv2
import numpy as np

def order_points(pts):
    rect = np.zeros((4, 2), dtype="float32")
    s = pts.sum(axis=1)
    rect[0] = pts[np.argmin(s)]      # 左上
    rect[2] = pts[np.argmax(s)]      # 右下
    diff = np.diff(pts, axis=1)
    rect[1] = pts[np.argmin(diff)]   # 右上
    rect[3] = pts[np.argmax(diff)]   # 左下
    return rect

img = cv2.imread("paper.jpg")
ratio = img.shape[0] / 800.0
small = cv2.resize(img, (int(img.shape[1] / ratio), 800))

gray = cv2.cvtColor(small, cv2.COLOR_BGR2GRAY)
blurred = cv2.GaussianBlur(gray, (5, 5), 0)
edges = cv2.Canny(blurred, 75, 200)

contours, _ = cv2.findContours(edges, cv2.RETR_LIST, cv2.CHAIN_APPROX_SIMPLE)
contours = sorted(contours, key=cv2.contourArea, reverse=True)[:5]

doc_cnt = None
for c in contours:
    peri = cv2.arcLength(c, True)
    approx = cv2.approxPolyDP(c, 0.02 * peri, True)
    if len(approx) == 4:
        doc_cnt = approx
        break

if doc_cnt is None:
    raise RuntimeError("找不到文件四邊形——請拍張對比度高一點的照片再試")

pts = order_points(doc_cnt.reshape(4, 2) * ratio)
(tl, tr, br, bl) = pts
maxW = int(max(np.linalg.norm(br - bl), np.linalg.norm(tr - tl)))
maxH = int(max(np.linalg.norm(tr - br), np.linalg.norm(tl - bl)))

dst = np.array([[0, 0], [maxW - 1, 0], [maxW - 1, maxH - 1], [0, maxH - 1]], dtype="float32")
M = cv2.getPerspectiveTransform(pts, dst)
warped = cv2.warpPerspective(img, M, (maxW, maxH))

cv2.imwrite("scanned.jpg", warped)

把任何一張包含 A4 紙的照片存成 paper.jpg,跑一次,會吐出 scanned.jpg——一張矯正後的乾淨文件圖。

流程拆解

原始照片
  → 縮小 + 灰階
  → GaussianBlur
  → Canny 邊緣
  → findContours 找最大輪廓
  → approxPolyDP 拿四個角
  → order_points 排序角點
  → getPerspectiveTransform + warpPerspective 矯正
  → 輸出 scanned.jpg

常見踩坑

症狀原因解法
找不到四邊形邊緣斷裂 / 文件邊框不完整拍照時讓紙本與背景對比大;可改用 cv2.morphologyEx 補邊
矯正結果上下顛倒order_points 排序錯檢查 s 和 diff 的方向;OpenCV 座標 y 軸向下
顏色發黃沒做白平衡對 warped 再做 cv2.adaptiveThreshold 變黑白文件

文件掃描的透視變換概念

範例 3:YOLO11 + OpenCV,第一個月就能玩現代物件偵測

範例 2 教你用幾何方法處理靜態文件,但你應該已經想到下一個問題——「畫面裡到底有什麼東西」這個問題傳統 CV 沒辦法回答,因為它需要語意理解。這就是深度學習接手的地方。

到了 2026 年,光會傳統 CV 不夠——你要會把 OpenCV 跟現代深度學習模型接起來。最簡單的接法就是 Ultralytics YOLO,這套工具把訓練、推論、export 整個包成幾行 Python。

import cv2
from ultralytics import YOLO

model = YOLO("yolo11n.pt")  # 第一次跑會自動下載 nano 模型
cap = cv2.VideoCapture(0)

while True:
    ok, frame = cap.read()
    if not ok:
        break
    results = model(frame, verbose=False)
    annotated = results[0].plot()
    cv2.imshow("YOLO11 + OpenCV", annotated)
    if cv2.waitKey(1) & 0xFF == ord("q"):
        break

cap.release()
cv2.destroyAllWindows()

15 行 Python,你的 Webcam 已經能即時辨識 80 類常見物件(人、貓、筆電、手機、椅子⋯⋯)。

為什麼這樣搭最聰明?

OpenCV 與 YOLO 是分工關係,不是替代關係:

  • OpenCV 負責:相機 I/O、影像前處理(resize、色彩空間)、後處理(畫框、寫字、輸出影片)
  • YOLO 負責:推論、給出 bounding box

如果你想做進階一點的「物件追蹤 + 計數 + 視覺化」,加上 Roboflow Supervision 這個套件會更省事——它是 model-agnostic 的,YOLO、SAM、Hugging Face Transformers 接哪個都一致。

Python vs C++:新手怎麼選?

這是入門最常糾結的問題。直接給你結論:

比較項PythonC++
學習曲線平緩陡到爆
開發速度快(Jupyter 互動式視覺化)慢
純 OpenCV 呼叫的執行速度跟 C++ 接近(底層仍是 C++)最快
自寫 for-loop 逐像素處理非常慢(必須改 NumPy 向量化)快
部署目標桌面、伺服器、Mac、PC嵌入式、即時、IoT

新手的話無腦選 Python。LearnOpenCV 在這篇對比文 也建議:「If you are a python programmer, use OpenCV with Python.」原因很簡單——Python 加 Jupyter Notebook 可以做到「改一行、馬上看到結果」,這對學 CV 是無可取代的優勢。

什麼時候才需要 C++?等你以後要把模型部署到 Jetson Nano、做即時 30fps 以上的工業檢測、或者自己寫像素級新演算法,再轉就好。多數應用其實一輩子不用碰 C++。

學會這三招之後要往哪走?

到這裡你已經會:讀寫影像、邊緣偵測、輪廓 + 透視變換、現代物件偵測。下一步建議按這個順序走:

OpenCV 經典 + YOLO 入門(你在這)
  → NumPy 向量化(避免 Python for-loop 地獄)
  → CS231n 講義(理解 CNN / ResNet / ViT)
  → 自訓資料集(Roboflow 標註 → YOLO 訓練)
  → ONNX export(跨框架部署)
  → 邊緣裝置(Raspberry Pi 5 / Jetson Orin Nano)
  → VLM 多模態(OpenCV 5 內建 Qwen / PaliGemma)

幾個我自己覺得最受用的資源:

新手最常踩的五個坑

最後分享幾個我自己踩過的坑,少走點冤枉路:

  1. 跳過經典 CV 直接學 YOLO:不懂 NMS、IoU、anchor 是什麼,模型一壞就只能換版本。
  2. 覺得 OpenCV 過時所以不學:5.0 才剛把 LLM/VLM 整合進來,反而比以前更值得學。
  3. Python 用 for-loop 處理像素:慢到懷疑人生,所有逐像素操作必須改 NumPy 向量化。
  4. 只會 model.predict() 不會部署:找工作會卡關。學會 ONNX export、INT8 量化、用 OpenCV DNN 跑推論。
  5. 資料集太乾淨:Kaggle 的影像太理想,去 Roboflow Universe 找接近真實雜訊的資料才有用。

結語

電腦視覺看起來很玄,其實 80% 的入門路徑就只是「讀進影像 → 做幾個變換 → 輸出結果」這個迴圈。三個範例你都跑過一次之後,這個迴圈會內化成肌肉記憶——剩下的就是把不同的工具(OpenCV、YOLO、Supervision、SAM2、VLM)塞進這個迴圈裡組合。

下一篇會深拆 2026 年 6 月剛發布的 OpenCV 5.0——它把整個 DNN 引擎重寫、ONNX 覆蓋率衝到 80%、還把 LLM 跟 VLM 直接塞進函式庫。如果你已經會用 OpenCV 4.x,那篇會告訴你升級該注意什麼;如果你剛入門,那篇會讓你看見未來兩年 CV 的樣貌。

延伸閱讀

BlackHole 完整指南:讓 Mac 終於錄得到自己的聲音(2026 更新版)

一個免費開源的虛擬音訊驅動,把 macOS 自從 OS X 時代就存在的「內建工具錄不到系統音」黑洞補起來。本篇從原理、安裝、Multi-Output Device、實戰場景、踩坑到競品比較一次講完。

BlackHole 封面

為什麼 Mac 預設錄不到自己的聲音

按下 Cmd + Shift + 5 開始錄影、放一首 Spotify、停掉、回頭一聽——畫面在、聲音不見。哪怕你已經更新到 macOS Tahoe(macOS 26),Apple 自家內建的螢幕錄影工具(QuickTime、截圖工具列)到今天還是抓不到「Mac 自己播出去的聲音」。這不是你設定錯,是 Apple 本來就不讓你錄。

原因說穿了不複雜:版權與隱私風險。iTunes/Apple Music 時代,Apple 不想讓系統內建工具變成 DRM 規避器;同時系統音流裡夾雜訊息提示、視訊通話、密碼確認等敏感資訊,作業系統層級開放錄製就是惹麻煩。所以 Apple 寧可把這個能力留給有 entitlement 的第三方工具。

ScreenCaptureKit 在 macOS 13 Ventura 之後給了開發者一條合法的路(OBS Studio 從 v30 開始用它 ),但 Apple 自家的 QuickTime、螢幕截圖工具列至今沒接這個 API。你想用內建工具錄系統音?對不起,繞道走。

繞道的路通常只有一條:把 macOS 的音訊輸出「假裝」送進一張虛擬音效卡,再從那張卡的輸入端把訊號讀回來。BlackHole 就是那張虛擬卡——0 元、開源、零延遲、可商用。

BlackHole 的真身:HAL 層的虛擬音效卡

HAL 層概念

BlackHole 是 Existential Audio 的 Devin Roth 維護的開源專案,採 GPL-3.0,在 GitHub 上有近 20k stars ,是這個賽道唯一還在維護、又夠好用的免費解(前輩 Soundflower 早就停更)。它的本質是一個 Core Audio HAL(Hardware Abstraction Layer)driver——注意,不是 kernel extension,是 user-space 的 .driver bundle。

這個區別很重要。BlackHole 安裝到 /Library/Audio/Plug-Ins/HAL/BlackHoleXch.driver,不會碰 kernel,所以不會在 Apple Silicon 上被 SIP 擋下、也不需要降低系統安全等級就能裝。安裝完只會重啟 coreaudiod 這個系統 daemon,整個過程在 DeepWiki 的安裝流程 寫得很清楚。

它對 Mac 來說就是「多了一張音效卡」。輸出寫到 BlackHole 的應用程式(Spotify、Chrome、Zoom),跟從 BlackHole 讀取的應用程式(OBS、Whisper、Logic Pro),之間用記憶體 ring buffer 直接交換 32-bit float 音訊資料。延遲?官方文件寫 zero additional latency——意思是除了 Core Audio 本來就有的 buffer 延遲,BlackHole 自己不額外貢獻一毫秒。

換個說法:它就是一條長度為零的虛擬音源線,把 A app 的輸出端跟 B app 的輸入端焊在一起,繞過真實世界的喇叭跟麥克風。

三個版本怎麼選:2ch / 16ch / 64ch

BlackHole 有三個版本,名字裡的數字就是聲道數。先看表:

版本聲道數適合誰典型情境
BlackHole 2ch2(立體聲)95% 的使用者YouTube/Spotify/Zoom 錄音、螢幕錄影、AI 轉錄
BlackHole 16ch16環繞聲、DAW 跨 App5.1/7.1 監聽、Logic ↔ Ableton routing、多軌 stem
BlackHole 64ch64重度多軌玩家大型 Atmos 製作、學術 telematic 演出

官方 GitHub Discussion #290 的結論很直接——維護者本人 Devin Roth 在串裡只回了「2ch」兩個字打死,意思很白:除非你要做環繞聲或 DAW 跨 App routing,否則 2ch 就對了。

我看過太多人裝完 16ch 結果 Zoom 抓不到聲音,回頭問為什麼——因為 Zoom 預設只吃 2 聲道,遇到 16 聲道虛擬卡會誤判輸入空。夭壽,這雷我以前也踩過。

好消息是三個版本可以同時安裝,互不打架。所以保險做法:日常 2ch 主用,遇到 DAW 跨 App routing 再裝 16ch 備用。

⚠️ macOS 26 Tahoe 有個新雷:GitHub Discussion #860 指出系統在 Tahoe 上會強制把所有 16 聲道塞滿,不再 downmix 到立體聲。如果你在 Tahoe 用 16ch 版本,可能會發現某些 App 抓不到正常的左右聲道——建議直接改用 2ch 版本繞過這個問題。

安裝與設定 Multi-Output Device

Audio MIDI Setup

最快的安裝方式是 Homebrew,官方 Homebrew cask 跟著 GitHub releases 同步,當前穩定版是 0.6.1,支援 macOS 10.10 Yosemite 以上 (Intel 與 Apple Silicon 通吃):

brew install --cask blackhole-2ch
# 或 16 / 64 聲道版本
brew install --cask blackhole-16ch
brew install --cask blackhole-64ch

不用 brew 也行,官網填 email 就會寄安裝包來。安裝完開「應用程式 → 工具程式 → 音訊 MIDI 設定」(Audio MIDI Setup),左側裝置列表應該會出現 BlackHole 2ch,這代表驅動已經被 coreaudiod 認到。

接下來最容易卡住的一步:單獨選 BlackHole 當輸出,自己會聽不到聲音——因為訊號全部跑進虛擬卡的 ring buffer 裡,沒有走到真正的喇叭。這時候你需要建立 Multi-Output Device(多重輸出裝置)。

在 Audio MIDI Setup 左下角 + 按鈕點下去,選 Create Multi-Output Device,然後勾選你的喇叭/耳機 + BlackHole 2ch。重點兩個:

  1. 主裝置(Master Device)一定要選你真正的喇叭,不要選 BlackHole——時鐘要跟著實體裝置走
  2. BlackHole 那一列的 Drift Correction(漂移校正)勾起來——這一勾可以省下你日後 80% 的同步問題

Aggregate Device 跟 Multi-Output Device 差在哪?簡單講:Multi-Output 只管輸出 ,Aggregate 同時管輸入跟輸出 。錄系統音用 Multi-Output 就夠,DAW 同時要進多張音效卡才需要 Aggregate。

設定流程畫一下:

App 輸出 (Spotify / Chrome / Zoom)
         │
         ▼
   macOS System Output
         │
         ▼
   Multi-Output Device
    ├──► 實體喇叭(主時鐘,你聽到聲音)
    └──► BlackHole 2ch(Drift Correction)
                │
                ▼
         錄音 App 輸入 (OBS / QuickTime / Whisper)

把系統音輸出選成這個 Multi-Output Device,你就能一邊聽、一邊讓 BlackHole 收音。

實戰場景一次看:直播、錄影、AI 轉錄、DAW

Podcast 場景

QuickTime 錄系統音

最簡單的場景。系統輸出選你剛建好的 Multi-Output Device → 打開 QuickTime → 新增「螢幕錄影」或「音訊錄影」→ 旁邊小箭頭把麥克風來源改成 BlackHole 2ch → 錄。完成。

OBS 直播 / 串流抓 Mac 內部音

OBS 30 之後其實內建了 macOS Audio Capture,可以直接抓系統音、不需要 BlackHole。但實務上,很多人還是用 BlackHole ——一來相容更廣,二來要做「桌面音 + 麥克風 + Discord 朋友的語音」三軌分離混音時,走 BlackHole + Multi-Output Device 的設定可控性更高。

走 BlackHole 的設定:OBS → Settings → Audio → Global Audio Devices → Desktop Audio 選 BlackHole 2ch。麥克風走另一條(直接抓你的 USB mic)。這樣你的觀眾會聽到「Mac 的系統音 + 你的人聲」分離兩軌,後製超方便。

AI 會議轉錄 pipeline(Whisper / Granola / 本地 LLM)

這是 2026 年我覺得 BlackHole 最強的用法。雲端服務如 Granola 在本機抓會議音訊,再把逐字稿上傳到雲端做摘要 ;但如果你跟我一樣,公司 NDA 連逐字稿都不准離開電腦,那 100% 本地的 Whisper pipeline 就是解。

whisper.cpp 搭 BlackHole 的標準本地 pipeline:

  1. Zoom/Teams/Meet 輸出 → 系統音 Multi-Output → BlackHole
  2. 你的麥克風 → 另一條音軌
  3. 兩條音軌一起餵給 whisper.cpp(Apple Silicon 上開 Metal 加速)
  4. 轉成逐字稿後丟 Claude 或本地 LLM 做摘要

整個 pipeline 在 M2 Pro 上跑 30 分鐘會議大約三分鐘出稿,本地零雲端,香到爆。

DAW 跨 App 路由(Spotify → Logic)

把 Spotify 當素材庫的時候很好用。Spotify 輸出設成 BlackHole 16ch,Logic Pro 新增一條 audio track,輸入選 BlackHole 16ch 的對應通道,按 record——Spotify 的音訊就跑進 Logic 變成可剪輯素材。

提醒:這只能個人練習用,商業發佈當然有版權問題,別拿來搞事。

那些踩過的坑:取樣率、Drift、Tahoe 新雷

踩坑警示

這節是我自己 + 社群苦主回報的精華,按出現頻率排。我第一次認真用 BlackHole 錄 podcast 那天,光是「為什麼喇叭沒聲音」就花了 40 分鐘排查——後來才發現是踩了下面這第一個雷。

1. Multi-Output 設定完沒聲音
症狀:選了 Multi-Output Device 當輸出,喇叭一片死寂。
原因:主裝置(Master Device)順位錯了,時鐘抓到 BlackHole 上去。
解法:Audio MIDI Setup 把實體喇叭拖到最上面,並把它設為主裝置。

2. 錄音檔越錄越不同步(Drift)
症狀:錄 10 分鐘以上,聲音跟畫面慢慢飄掉。
原因:BlackHole 的虛擬時鐘跟實體裝置時鐘有微秒級偏差,累積成大誤差。
解法:Audio MIDI Setup 中把 BlackHole 那列的「Drift Correction」勾起來 。我曾經錄了一場 50 分鐘的訪談,後製剪到第 35 分鐘發現嘴型對不上聲音,幹,整集重錄。Drift Correction 這個勾真的差超多。

3. 取樣率不一致導致破音/雜訊
症狀:錄出來爆音、有奇怪 click。
原因:Spotify 是 44.1 kHz、BlackHole 設 48 kHz、喇叭又是 96 kHz,三方在打架。
解法:Audio MIDI Setup 把所有相關裝置都改成同一個取樣率(48 kHz 通常最安全)。

4. 錄音裡有回授尖叫
症狀:錄出來突然爆炸的高頻嘯叫。
原因:你把 BlackHole 同時設成輸入跟輸出,訊號自己咬自己的尾巴。
解法:檢查錄音 App 的監聽選項,不要對 BlackHole 開啟即時監聽(input monitoring)。

5. macOS Tahoe 上 16ch 版本詭異行為
症狀:升上 Tahoe 之後,原本好好的 16ch 設定突然抓不到聲音。
原因:Tahoe 改變了聲道分配邏輯 ,不再自動 downmix。
解法:換用 2ch 版本,或在 App 端手動指定要讀取的聲道。

6. 升級 macOS 後 BlackHole 不見
症狀:升完系統,BlackHole 從裝置列表消失。
原因:大版本升級會清掉部分 HAL plugin。
解法:重裝(brew reinstall --cask blackhole-2ch)即可,設定不會掉。

跟 Loopback / Audio Hijack / SoundSource 怎麼選

Rogue Amoeba 的這三套是 macOS 音訊工具的老牌商業解,常被拿來跟 BlackHole 比。一張表講完:

工具定位價格(USD)主要差異
BlackHole純路由(虛擬卡)0 元,開源沒 GUI、所有路由靠 Audio MIDI Setup 手動接,但夠用
Loopback路由(圖形化)$99拖拉式介面、可建「虛擬多 App 合成裝置」,學習曲線低
Audio Hijack路由 + 錄音 + 處理$69可以直接錄成檔案、內建效果器、適合 Podcaster
SoundSource音量/裝置控制$49不做路由,做的是 per-app 音量、per-app EQ、選單列快速切換

我自己的組合是 BlackHole 2ch 處理日常 95% 的路由,要錄音時直接用 OBS 或 QuickTime 抓 BlackHole 當輸入;SoundSource 另外加掛,純粹拿來做 per-app EQ(耳機同時開會 + 聽音樂時超實用,跟前面三套不衝突)。Audio Hijack 跟 Loopback 是好東西,後製需求多的人付錢買不虧——但 BlackHole 真的免費到讓人很難找理由先付那 99 美元。

ScreenCaptureKit 來了,BlackHole 過氣了嗎?

macOS 13 Ventura 開始,Apple 推了 ScreenCaptureKit ——一個官方 API,讓有 entitlement 的 App 可以原生抓系統音,不需要虛擬驅動。OBS 30、Screenify、ScreenSnap Pro 都已經接了。

那 BlackHole 是不是要進博物館了?短期看不會,理由四個:

  1. 內建工具沒接 ScreenCaptureKit。QuickTime、螢幕截圖工具列到 Tahoe 都還是抓不到系統音。Apple 自己沒換,BlackHole 還是繞道唯一解。
  2. 跨 App 路由 ScreenCaptureKit 做不到。它只能「我這個 App 抓系統音」,沒辦法「App A 的輸出餵給 App B 當輸入」。DAW 跨 App、AI 本地轉錄這類場景,BlackHole 沒對手。
  3. per-app 抓特定 App 音訊這件事 ScreenCaptureKit 行,但 BlackHole 搭 Audio Hijack/Loopback 也行,而且更可控。
  4. macOS 系統內部音流的歷史包袱。每個 App 對音訊路由的處理都不一樣,ScreenCaptureKit 在某些 App 上會詭異掉訊號,BlackHole 走 Core Audio 標準路徑反而穩定。

長期看,每年 macOS 大版本升級都讓 BlackHole 維護者多忙一輪,Tahoe 上的 16ch 行為變化 就是最新一例。但只要 Apple 還允許第三方 user-space HAL driver 存在,BlackHole 就還有空間。從 GitHub 仍持續發 PR 跟 release 的節奏看,短期看不到 EOL 的訊號。

結語

回頭看那場錄壞的 50 分鐘訪談,當時我以為是 macOS 的螢幕錄影哪裡又出新 bug;後來才知道,是我自己沒勾 Drift Correction,誤把鍋甩給作業系統。BlackHole 教我的不是「怎麼錄系統音」,是「怎麼真的看懂 Mac 的音訊架構」——什麼是 HAL、什麼是時鐘主裝置、為什麼 Aggregate 跟 Multi-Output 是兩件事。這些知識搞清楚之後,連 Loopback 跟 Audio Hijack 都用得更順。

實務建議:起手 brew install --cask blackhole-2ch,建一個 Multi-Output Device(主裝置選喇叭、BlackHole 勾 Drift Correction),系統輸出選它。八九成的場景到這裡就解掉。後製要錄檔再加 Audio Hijack,路由複雜到讓你頭痛再加 Loopback——但別跳過 BlackHole 這一步,免費的東西先把基礎打好,付費工具的價值才看得出來。

如果這篇幫你省下一個下午的設定地獄,把它丟給下一個被 macOS「螢幕錄影沒聲音」逼瘋的朋友吧。

參考資料

你一直在用錯誤的方式 prompt Claude:Karpathy 的三層工作法

為什麼最強的模型會叫你「走路去洗車」,而真正會用 AI 的人都在做同一件事。

由文字與程式碼粒子構成的半透明鬼魂坐在洗車場

我前陣子丟了一個問題給 Claude、Gemini、Grok 和 ChatGPT:「我要去洗車,洗車場在 50 公尺外,我應該走路還是開車過去?」

四個模型,異口同聲叫我走路。理由還講得頭頭是道:「50 公尺很近,走路比較環保、省油、又能運動。」

乾,車子要洗欸,人走過去是要用舌頭舔嗎?

這個例子是 Andrej Karpathy(前 Tesla AI 負責人、OpenAI 創始成員)在 2026 年的演講裡拿出來打臉所有人用的。我本來不信,自己試了一輪——它們全錯。有人後來拿這題去測 53 個主流模型,結果只有 5 個能穩定答對,33 個從頭錯到尾(Opper 的 Car Wash Test)。

同一個 Claude,可以幫你重構一份十萬行的程式碼庫——資深工程師要做好幾週的工作——卻在「洗車要不要開車」這種國小生都會的常識上翻車。這不是 bug,這是整支影片的地基。搞懂它,你才會明白為什麼你一直在用錯誤的方式 prompt AI。

為什麼 AI 是天才又是白痴:可驗證性

Karpathy 在 Sequoia 的年度 AI 活動上給了我看過最乾淨的解釋,他稱之為「可驗證性論題」(Verifiability Thesis):

傳統電腦自動化的是「你能用程式碼明確指定的東西」;LLM 自動化的是「你能驗證的東西」。

程式碼有單元測試、有編譯器、有明確的對錯,所以 AI 在這個領域是超人。但「洗車要不要開車」沒有 verifier——沒有任何一個單元測試在檢查「關於洗車的交通常識」。對能被衡量的東西,AI 是天才;對需要脈絡、無法被衡量的東西,它沒有任何訊號可以依靠,於是自信滿滿地胡說(MindStudio 對 Verifiability Thesis 的整理)。

那問題來了:你腦袋裡的脈絡跟理解,怎麼餵給只懂計算的 AI?Karpathy 的答案可以拆成三層:

你的理解(目標・脈絡・品味) → Layer 1 Spec 規格 → Layer 2 Verifier 驗證者 → Layer 3 Environment 環境 → 10x 的產出 →(持續回饋)→ 你的理解

把它想成一個工作坊:規格是釘在牆上的藍圖,驗證者是門邊的品檢站,環境就是工作坊本身。大多數人每次用 AI 都從一個空蕩蕩的工作坊重新開始——這就是問題所在。

Layer 1:Spec(規格)——別再丟一句話就要它蓋房子

釘在工作坊牆上的發光藍圖

很多人聽過 Claude 的 plan mode,覺得「先讓它做個計畫再動工」就很厲害了。但 Karpathy 直接說他不喜歡 plan mode:

我其實不太喜歡 plan mode……當然它很有用,但我覺得這裡有更通用的東西:你應該跟你的 agent 一起設計一份非常詳細的 spec。

注意他不是說 plan mode 爛,而是說那層級太高、太淺。真正該做的是跟 AI 一起把規格挖到底。怎麼挖?三個動作。

一、先逼出「目標」,不是「任務」

如果你說「幫我做一份月底報告」,那是任務。但真正的目標是「這份報告要導出什麼結論、要驅動什麼決策」——而這件事 AI 永遠無法替你決定。最有效的招數反過來:讓 AI 來訪談你。

在開始之前,請先訪談我,以釐清這個專案真正的目標。
一次問我一個問題,根據我的回答再追問,直到你能用一段話
總結出「成功長什麼樣子」為止。

二、敏捷地切,不要瀑布式地塞

完成任何任務有兩種方式:瀑布式(一次做完整包,最後才給你看成品)跟敏捷式(切成小塊,過程中一直給你看、隨時校正方向)。人類用 AI agent 時超容易掉進瀑布式陷阱——因為很爽,一次把所有事丟給它。但這正是產出歪掉的主因。正確做法是敏捷規格:範圍收緊、檢查點清楚、看產出、調整、重複。

請傾向把工作拆成更小、更模組化的 spec。
每個 spec 完成一個可獨立檢查的小塊,做完就停下來讓我 review,
不要一口氣把整個功能做完。

三、精確,然後動你的腦

你愈精確,AI 要去「假設」的東西就愈少;而每一個假設,都是它偏離你真正想要的東西的機會。當 AI 幫你生出一份 spec,你必須動腦去批判性地讀它到底寫了什麼,而不是看都不看就按下去。

在關鍵決策點,請明確讓我逐一確認,確保沒有任何遺漏被你默默帶過。

把這三招合起來,你會得到一份範圍收緊、想清楚、而且真正對齊你目標的規格。Karpathy 把這整套叫做「現代工程」(modern engineering)——他認為每個想在 AI 時代成功的人都得變成這種人。

Layer 2:Verifier(驗證者)——你唯一真正握得住的把手

兩個機器人圖書館員在品檢站互相比對產出

用 AI 最煩的事情之一,就是 review 跟驗證它的產出。要解這題,得先搞懂一個心智模型,Karpathy 用「動物 vs 鬼魂」(animals vs ghosts)來講。

我們不是在打造動物,我們是在召喚鬼魂。

聽起來很玄,我幫你翻譯。我們習慣跟「人」互動——Karpathy 把人叫做動物——動物有內在動機跟情緒。你跟一個人說「14 天內變成 SEO 專家,不然你就被開除」,他真的會想辦法生出來,因為他有內在驅力。

但 AI 不是。Karpathy 說它是鬼魂——「人類文件的統計蒸餾物,上面再灑一點調味」,他甚至打了個比方:鬼魂之於動物,就像飛機之於鳥——是根本不同的智慧形態,不是同一條路上的兩個階段。

我覺得「鬼魂」還是太抽象,換個更好懂的:把它想成一個機器人圖書館員。你問它 SEO,它只能根據館內藏書給你答案;沒那本書,它幫不了你。更麻煩的是,它不知道自己缺哪本書,所以常常一臉自信地當場編一個給你。這就是 AI 數學神準、脈絡卻翻車的真相。

關鍵結論來了:既然它是鬼魂不是動物,那你用對待人的方式對它就完全沒用——對它吼、拜託它、丟一句「做得更好一點」,統統沒效。你唯一真正握得住、而且大部分人根本沒想到要用的把手,就是驗證。三個著力點:

一、事前就把評分標準講死

在 Claude 動手之前,先用「精確」定義出「好」長什麼樣子。模糊版:「把這份報告弄得好看一點。」精確版:「報告必須有三個區塊,每個區塊結尾都要有一條具體建議。」有沒有發現?這跟 Layer 1 的精神一模一樣——你事前愈精確,Claude 之後能犯錯的空間就愈小。

請先列出你將用來確保最終產出品質的評分標準。要精確。
然後依照這份標準自評,不通過就重做。

二、用第二個 AI 當 critic

想像第二個來自不同圖書館的機器人館員——它有一整套不同的藏書,可能因此看出第一個館員哪裡對、哪裡錯。實作上,如果你用 Claude Code,可以裝 Codex 外掛,直接在 session 裡問 Codex:

如果這變成一個複雜的 build,最後請把產出丟給 Codex 跑一遍,
確認兩邊系統的判斷一致,不一致的地方列出來給我。

三、盡可能拉進外部訊號

  • 技術場景:你不確定 app 有沒有部署成功?把 Claude session 接上你的部署系統,讓它直接去查。它說成功,那就是真的成功。
  • 非技術場景:在做月報?把歷史報告丟進去當參考,讓最終格式直接對齊過去的版本。

這就是把外部資料拉進來,強化你的驗證層。Claude Code 的作者 Boris Cherny 把這件事的重要性講得最白:

要從 Claude Code 拿到好結果,最重要的一件事,就是給 Claude 一個能驗證自己工作的方式。只要 Claude 有這個回饋迴路,最終結果的品質會提升到 2~3 倍。

這句話出自他在 X 上的貼文(原文為英文,此處為意譯)。整理他工作流的文章也提到,這個回饋迴路被視為團隊最大的生產力解鎖之一——claude.ai/code 的每一次改動,Claude 都會開瀏覽器自己測過 UI 才算數(How Boris Uses Claude Code)。我自己的體感完全一致:有沒有讓 AI 能自己跑測試、自己看結果,產出品質根本是兩個世界。

Layer 3:Environment(環境)——別每次都從空白工作坊重來

井然有序的未來工作坊,貨架上是發光的知識資料夾

Spec 跟 Verifier 需要一個地方住,那就是 Layer 3:你建構的環境。重點是——大多數人每次用 AI 都重開一個空工作坊。注意,「一個 chat 開著完整對話紀錄」不算。怎麼蓋一個會隨時間變強的工作坊?四步。

一、寫好你的 CLAUDE.md

每次你 prompt Claude,CLAUDE.md 都會被自動注入——它幾乎是 Claude 開工前讀的第一份文件,決定它該怎麼運作。比方說你可以加一條:

# 工作規則
- 在動手任何多步驟的任務之前,先附上一份驗證計畫(怎麼確認做對了)。

這樣一來,驗證就被強制寫進每一次 build,而不是你每次都要記得去講。一句話:這是你的世界,AI 住在裡面,不該反過來。

二、建你自己的 LLM 知識庫

這是 Karpathy 2026 年 4 月在 X 上爆紅的概念——他稱之為 LLM Knowledge Base。本質上就是在你機器上開一個資料夾系統,把你自己的「訓練資料」用一種讓 Claude 容易理解、容易定位的方式餵進去。常見做法是開一個資料夾,底下兩個子資料夾:raw/(你的原始素材:論文、repo、文章、會議記錄、截圖)跟 wiki/(讓 LLM 自己整理、自己維護的互連 Markdown 筆記)(Medium 的整理)。為什麼這麼重要?因為你的資料就是你的護城河。

三、開始累積你的 skill

我自己的判斷準則:任何你打算重複做的事,就替它做一個 skill。 把它想成完成特定任務的一本手冊。而且用得愈多,它會愈好——我常講一句話:「找出水管漏洞最好的方法,就是讓水流過去。」skill 也一樣,跑得愈多,你愈知道哪裡要修、哪裡很猛。持續讓水流過去,你的系統就會隨時間複利成長。

四、立下「能做 / 不能做」的規則

依「做錯的代價」設不同等級的護欄。這裡有個關鍵差異——guide(指引)不等於 rule(規則)。你可以在 CLAUDE.md 寫「不要碰某個資料夾」,這能幫你達成 80%……但它本質上是個請求,Claude 還是碰得到。真正關鍵、絕對不能錯的事,要用規則級的護欄:加一個 pre-tool-use hook,在 Claude 使用 write 或 edit 工具之前,先檢查它要改的檔案——在保護資料夾內就在工具層級擋下,其他放行。這才是 agent 繞不過去的硬規則。把事情分成三桶:

分類意義實作層級
Always do(永遠做)AI 可以自動駕駛的事自動執行
Ask first(先問)你想再確認一下的事prompt/互動確認
Never do(絕不做)跨過去就完蛋的紅線hook 等規則級護欄

三層怎麼疊起來用:一張對照表

層核心問題招數一句話心法
Spec 規格AI 不知道你「真正」要什麼讓 AI 訪談你、敏捷切小塊、關鍵點要你確認把理解灌進規格
Verifier 驗證者AI 是鬼魂,不會自己知道對錯事前定評分標準、第二模型當 critic、拉外部訊號唯一握得住的把手是驗證
Environment 環境每次都從零開始、規則無法強制CLAUDE.md、LLM 知識庫、skill、hook 護欄這是你的世界,AI 住裡面

踩坑提醒:新手最容易做錯的兩件事

坑一:把 spec 當成一次性的長 prompt 塞爆。 很多人聽到「要詳細的 spec」就寫一篇兩千字的需求一次丟進去,然後等一個完美成品——這就是瀑布式。結果 AI 在第三段就開始假設、到第十段已經飄到外太空。解法:spec 再詳細也要敏捷地切,做一塊、檢查一塊。

坑二:用 guide 假裝成 rule,然後怪 AI 不聽話。「我明明在 CLAUDE.md 寫了不要動那個資料夾,它還是改了!」——因為那只是請求,不是規則。解法:代價高的事一律上 hook,在工具層級擋下。別在 prompt 裡拜託一個鬼魂自律。

最後,那唯一一件事

走完整套方法,還有個問題沒回答:在智慧變得便宜的 AI 時代,Karpathy 認為我們唯一該專注學的是什麼?他用一句話回應,而這句他其實是引用別人的、最近一直掛在嘴邊的話,我覺得是整篇最重的一句:

你可以外包你的思考,但你無法外包你的理解。(You can outsource your thinking, but you can't outsource your understanding.)

這句話他最近反覆引用(Karpathy 本人說「這是我最近一直在引用的話」),也被不少人拿來談 AI 時代的「理解瓶頸」(Understanding Bottleneck)。回頭看,整套三層架構——spec、verifier、environment——全都繞著你對大局的理解在轉。你得懂你的目標、懂什麼叫做對,才有辦法指揮 AI 替你工作。

所以下次你又想丟一句「幫我做個 X」然後祈禱的時候,停一下。先問自己:我的目標到底是什麼?我要怎麼驗證它做對了?我有沒有一個會愈長愈強的環境?把這三件事想清楚,你不是在 prompt 一個鬼魂——你是在當一個現代工程師。


參考資料

2026 像素遊戲開發完整指南:Aseprite、Godot 4、LDtk 與 AI 工具怎麼組合最爽

如果你今年想做一款像素風遊戲,問題不是「工具會不會太少」,而是「工具太多,挑錯第一步,後面六個月白做」。

我看過太多人在 reddit、Discord、巴哈姆特上問同一個問題:用 Unity 還是 Godot?Aseprite 值不值得買?AI 生圖能不能直接拿去當素材?這些問題沒有單一答案,但有最不會踩雷的預設組合。這篇用一篇文章的長度,把 2026 年的工具地圖、決策依據、實作 pipeline、game feel polish 通通講完,最後給你一份 30 天可以動工的行動計畫。

像素遊戲開發雙螢幕工作站,左螢幕 sprite 編輯、右螢幕引擎編輯

為什麼 2026 是做像素遊戲的好時機

幾個事實先攤開:

  • Aseprite 從 2016 上 Steam 之後,幾乎變成 indie 業界共識,社群與插件生態完全成熟。
  • Godot 4 在 2023 年 Unity 收費風波(runtime fee)後社群爆炸,2025-2026 已經是新專案的事實預設選項。
  • LDtk 由 Dead Cells 首席設計師 Sébastien Bénard(離開 Motion Twin 後成立 Deepnight Games)開發,原生讀 .aseprite 加 live reload,把美術跟關卡編輯之間的摩擦壓到最低。
  • AI 像素生圖已經從「看起來像但完全不能用」進化到「Retro Diffusion 配 Aseprite 插件可以真的進 production」,整個 workflow 速度暴增。

這些工具有個共通點:要嘛免費、要嘛單次付費 20 美金以內。整套組合的金錢門檻幾乎是零,剩下的只有時間。

第一步別搞錯:解析度決定一切

開工前最該鎖死的是「三個尺寸」:sprite 尺寸、tile 尺寸、場景渲染解析度。這三個數字一旦定了,整個專案的視覺風格、工作量、polish 程度都跟著決定。後期想改?等於整套素材重畫。

16/32/64 像素 sprite 尺寸並排比較

Sprite 與 tile 的常見尺寸

尺寸風格工作量代表作
8×8極端 retro極低Celeste Classic
16×16NES 經典,每像素都關鍵低Stardew Valley、Undertale
32×32最常用,表現力與工作量平衡中Hyper Light Drifter、Eastward
48×48細節豐富中高—
64×64+接近油畫感極高Owlboy、Blasphemous

實務原則:tile 尺寸建議跟角色一致或更小(如 16×16 tile 配 32×32 角色),sprite 用 2 的倍數方便縮放。32×32 在這幾年幾乎是 indie 的共識起點,細節夠又不會吃光所有產能。

場景渲染解析度

解析度比例來源
256×2248:7SNES
320×18016:9現代寬螢幕標準
400×224接近 16:9Shovel Knight
640×36016:9高一階細節

選 320×180 在 1080p 螢幕剛好乘以 6 倍,在 4K 剛好 12 倍,pixel-perfect 不會破。

美術工具:為什麼 Aseprite 仍是事實標準

Aseprite 編輯像素角色動畫的工作流近照

Aseprite 19.99 美金買斷,沒有訂閱、沒有水印、原始碼公開(可自己編譯免費用)。它做對的事:

  • 動畫 tag:在 timeline 上直接切 idle、walk、attack,匯出 spritesheet 時自動切片
  • 調色盤管理:可以鎖定 palette,畫圖時自動 quantize
  • Onion skin:透明顯示前後 frame,動畫流暢度肉眼可判
  • Tilemap 模式:1.3 加入後可以直接畫 tileset 並預覽 tile 拼接

替代品也不是不能用。如果完全不想花錢:

  • Pixelorama(免費開源):3D 模式、OKLCH 調色盤這些 Aseprite 沒有的功能它都有,但社群與插件少很多。
  • LibreSprite(免費):Aseprite 1.1 的 fork,介面幾乎一樣,缺新功能。
  • Piskel(瀏覽器免費):適合入門五分鐘上手。

我會說:你願意花 20 美金學一週、之後省下未來幾年的學習摩擦,這筆投資跟買鍵盤沒兩樣。詳細教學可以看 Generalist Programmer 的 Aseprite 完整指南 。

12 動畫原則在像素裡怎麼用

像素解析度極端,動畫原則反而更關鍵——少量像素要傳達大量訊息:

原則像素中的做法
Squash & Stretch跳躍落地壓扁 1-2 px
Anticipation攻擊前一 frame 向後微縮
Follow-through披風、頭髮多走 1-2 frame
Timingidle 約 400-500ms/frame,攻擊 50-80ms
Secondary Action走路時配件晃動

最小可行動畫集:idle (2f)、walk (4-8f)、attack (3-5f)、hurt (1-2f)、jump (1-2f)、death (4-6f)。SLYNYRD 的 Pixelblog 25: Motion Cycles 是我看過講 walk cycle 最透徹的,免費。

遊戲引擎:Godot 4 在 2026 為什麼是預設解

獨立遊戲關卡編輯場景,像素地下城與火把

我直接給結論:新專案、無特殊需求、用 Godot 4。GameMaker 在新手友善度上其實更高,但獨佔 GML、商業授權費、長期擴展性都不如 Godot;Godot 完全開源、GDScript 加 C# 雙語言、社群文件擴張極快,三年內已經追上甚至贏過 GameMaker 在 indie 的市佔。

引擎授權像素友善適合
Godot 4MIT 免費⭐⭐⭐⭐⭐2026 預設選擇
Unity商業⭐⭐⭐⭐資源最多但商業模式有疑慮
GameMaker訂閱 / 一次性⭐⭐⭐⭐⭐新手最友善、2D 專精
LÖVEzlib 免費⭐⭐⭐⭐喜歡寫程式、極簡 Lua 框架
PICO-8$14.99⭐⭐⭐⭐⭐練功、Game Jam、極快迭代

Godot 4 的優勢不只是免費。它是真的把 2D 當一等公民在做:原生 2D 渲染器、Scene Tree 對複雜專案擴展性夠、安裝包不到 100MB、.aseprite 有現成 importer plugin。

Godot 4 pixel-perfect 設定清單

這幾個一定要設,不然畫面會糊:

Project Settings:
├─ Display > Window > Viewport Width  : 320
├─ Display > Window > Viewport Height : 180
├─ Display > Window > Stretch > Mode  : viewport
├─ Display > Window > Stretch > Aspect: keep
├─ Rendering > 2D > Snap 2D Transforms to Pixel : ON
├─ Rendering > 2D > Snap 2D Vertices to Pixel   : ON
└─ Rendering > Textures > Default Texture Filter: Nearest

Texture Filter 不設 Nearest 你會看到雙線性插值的糊邊,是新手最常犯的坑。詳細設定可以參考 GDQuest 的官方教學 與 Godot 官方文件 。

Aseprite → Godot 自動匯入

裝 Aseprite Wizard plugin (vinicius gerevini 維護):你在 Aseprite 存檔,Godot 自動生成 AnimatedSprite2D 的 SpriteFrames 資源,連動畫 tag 都自動對應好。我認真覺得這個 plugin 一個人省下整個美術 pipeline 工程師的工作量,乾。

關卡編輯器:LDtk vs Tiled

工具強項弱項
LDtk原生讀 .aseprite + live reload、UI 漂亮、Dead Cells 作者出品JSON 較肥、無 script 系統
Tiled老牌跨引擎、有 Lua/JS script、檔案精簡、支援六角格UX 略老
引擎內建不離開引擎、整合最佳跟美術切換麻煩

LDtk 的殺手級功能是 live reload:在 Aseprite 改 tile 存檔,LDtk 視窗的關卡瞬間更新,連 resize 都不用管。對單人開發來說這種摩擦消失就是時間財富。Tiled 在跨引擎、自動化 pipeline、需要寫 export script 的場景仍然更強。

如果你的目標是「最少工具、最快做出第一個關卡」,直接用 Godot 4 的 TileMapLayer 也夠,省一個外部依賴。

AI 加速:Retro Diffusion 與 PixelLab 怎麼用才不會毀掉手感

2024 之前 AI 生像素圖根本不能用:grid 對不齊、palette 一團糟、放大會糊。2025 之後 Retro Diffusion 與 PixelLab 兩家專做像素的,把基礎品質拉到能用的水準,Retro Diffusion 官方還直接做了 Aseprite 插件可以內嵌進編輯流程。

正確的 AI workflow 不是「生完直接用」,而是:

  1. AI 生 base sprite(速度 10×)
  2. 匯入 Aseprite,強制對齊 grid + 量化到鎖定的 palette
  3. 人工修正關鍵 frame、清理雜色
  4. 動畫部份仍以人工為主(AI 動畫一致性弱、容易跳幀)

把 AI 當「資深美術助理打稿」,不是「自動素材機」。如果你直接把 AI 圖塞進遊戲,玩家肉眼一秒看出來,這是 itch.io 評論區最近半年最常見的負評之一。

完整 Pipeline 與資料夾結構

Concept + Style Guide
        ↓
Aseprite 畫 sprite/tile
        ↓
LDtk / TileMap 組關卡
        ↓
Godot 4 程式邏輯
        ↓
Game Feel polish
        ↓
音效音樂導入
        ↓
playtest 收回饋
        ↓
Itch.io / Steam

資料夾結構建議:

project/
├── art/                     ← Aseprite 原檔
│   ├── characters/
│   ├── tiles/
│   ├── ui/
│   └── vfx/
├── assets/                  ← 引擎讀取的 PNG
├── audio/
│   ├── sfx/
│   └── music/
├── levels/                  ← LDtk 檔
├── src/                     ← 程式
└── docs/
    └── style-guide.md       ← 解析度、palette、命名鎖定

命名規範一律 snake_case:player_walk.aseprite、tile_dungeon_floor.aseprite、sfx_jump.wav。聽起來瑣碎,但專案到第三個月、素材破 200 個的時候你會感謝過去的自己。詳細可以看 Wayline 的 asset management 系列 ,講得很實在。

Game Feel:5 個讓畫面活起來的技巧

像素遊戲攻擊瞬間,粒子特效與螢幕震動

技術上跑得動 ≠ 玩起來爽。Game feel 是 indie 遊戲的分水嶺。Vlambeer 在 GDC 那場「Juice it or lose it」是教科書,這裡濃縮 5 個最划算的:

  1. Screen shake:被打、爆炸時攝影機隨機位移 0.1-0.3 秒,用 ease-out 衰減。半秒以上會讓玩家頭暈。
  2. Hit stop:攻擊命中那瞬間整個畫面 freeze 50-100ms,命中感瞬間倍增。
  3. Hit flash:敵人被打到時 sprite 整體變白 1-2 frame,是廉價但有效的命中回饋。
  4. Squash on land:跳躍落地時角色 y 縮 0.7、x 拉 1.2、再回彈,重量感馬上出來。
  5. Particles:走路灰塵、跳躍煙、命中粒子。Godot 的 GPUParticles2D 配一個小 spritesheet 就能搞定。

注意「適量原則」:Celeste 是節制 juice 的範例,沒有滿屏震動跟粒子,但每個操作精準。Nuclear Throne 是另一極端,全螢幕特效。兩者都成功,關鍵是配合遊戲調性。過度 juice 會讓畫面難讀、玩家疲勞、隱藏掉設計缺陷。

30 天行動計畫:從零開始的最小可行專案

不要再做大綱、買教學、看 YouTube 了,直接做。給工程師背景的人,最低成本起步:

天任務
1-2鎖定 style guide(解析度、palette、sprite 尺寸)
3-5畫一個 idle + walk 動畫的角色
6-8Godot 設定 + 角色控制(移動、跳躍)
9-12第一個 tileset + LDtk 關卡
13-16加碰撞、敵人、攻擊
17-20game feel polish(screen shake、hit flash、particles)
21-24UI、選單、暫停
25-27音效音樂(用 Sfxr 跟 Bosca Ceoil)
28-30測試、上 itch.io 收回饋

成本盤點:Aseprite 20 美金,其他通通免費。30 天後你會有一個可以丟給朋友玩的 demo,這比看 100 篇教學文都有用。

推薦的 2026 Minimum Viable Stack

美術    : Aseprite                ($19.99)
引擎    : Godot 4                  (免費)
匯入    : Aseprite Wizard plugin   (免費)
關卡    : LDtk                     (免費)
音效    : Sfxr + Bosca Ceoil       (免費)
版控    : git + Git LFS            (免費)
發布    : Itch.io → Steam

整套組合的金錢成本:20 美金。剩下的,是你願意每天花一小時,連續花幾個月。

結語:工具不是上限

Stardew Valley 用 Paint.NET 畫的,Undertale 用 GameMaker 寫的,Celeste 用 8×8 的 sprite 起家。工具從來不是上限,完成度才是。

2026 年的好消息是工具門檻已經低到不能再低,社群知識也夠厚。Aseprite、Godot、LDtk、Retro Diffusion 把過去你要花一年自學的東西壓縮到一個月可以入門。剩下的事情就一件:選一個角色,畫好 idle 動畫,今晚就讓它在螢幕上動起來。三天足夠。

延伸閱讀

寫於 2026-06-07。工具版本變動快,建議以各官網最新發布為準。

CLI Agent 新手入坑:三大家真正共有的 8 個命令(Claude Code / Codex CLI / OpenCode)

三家 CLI Agent 命令匯流主視覺

裝完 Claude Code,第一次在 prompt 敲 /,跳出來 90 幾個命令——這不是誇張,是 我自己 grep 官方 docs 數出來的 。Codex CLI 大概 40 個,OpenCode 大概 20 個。三家加起來破百,你坐在那邊滑著選單想:「我到底要記哪幾個才能開始幹活?」

我也是這樣愣過。後來把三家官方 docs 整個爬一遍,發現一件事:真正三家都有、語意又夠接近的內建命令,只有 8 個。把這 8 個吃透,你就能跨工具切換,不必在每次換家時重學一輪。

這篇是給準備入坑的人看的——不講花俏、不秀進階;講 8 個命令、3 個必踩坑,和一條「第一天就能跑」的工作流。


三大家是誰?要選哪一家入坑?

三家 CLI Agent 對峙示意

先說人是誰:

工具 出身 語言 架構 開源
Claude Code Anthropic 官方 TypeScript / Node.js Standalone 否
Codex CLI OpenAI 官方 Rust Standalone 是(Apache 2.0)
OpenCode sst.dev (GitHub org sst) Go(server)+ TypeScript / Bun(TUI) Client / Server 是(MIT,168k+ stars )

實戰選擇講白話:

  • 想要功能最齊全、Claude 模型強:選 Claude Code ,命令 90 個爆炸給你,連 /stickers(訂貼紙)/voice(語音輸入)都有,廢到笑但有用的也不少。
  • 想要 ChatGPT 訂閱戶免費 + 跑 CI / 自動化:選 Codex CLI ,命令精簡正交,sandbox + approval + plan mode 三層防護做得最嚴。
  • 想要自由換 model、隱私、跨裝置:選 OpenCode ,唯一 client/server 架構,SSH 斷線後重連,跑中的任務還活著——這在跨域工作或長任務時夭壽好用。

三家不必選邊站。我自己是平常 Claude Code 主力、CI 用 Codex、長跑任務或想換 Sonnet/GPT/Gemini 比較時切到 OpenCode。能跨家的關鍵就是接下來這 8 個命令。


三家真正共有的 8 個命令

把三家的官方 slash commands 列表交叉比對之後,所有三個工具都內建、語意相近的命令只有這 8 個:

命令 Claude Code Codex CLI OpenCode 一句話用途
/init 產生 CLAUDE.md 產生 AGENTS.md 產生 AGENTS.md 專案初始化掃描
/clear aliases /reset /new 清螢幕+新對話 /new 的 alias 開新對話
/compact [instructions] 可指定焦點 摘要對話釋放 context alias /summarize 壓縮對話
/help 顯示全部命令 顯示全部命令 顯示全部命令 忘記就敲它
/model / /models 單數 單數 複數 切換模型
/resume [session] 或選單 從本地 transcript alias /sessions /continue 恢復過去 session
/exit / /quit /exit 兩個都收 /exit /quit /q 離開
/diff 含 untracked 含 untracked 沒有原生,用 !git diff 看 Git diff

⚠️ 嚴格講 /diff 在 OpenCode 不是原生 slash 命令,但 OpenCode 支援 ! 前綴跑 shell 命令,敲 !git diff 就行,所以放寬算進來。如果你龜毛,真共有只有 7 個。

8 個命令我幫你分成三組記憶:

開局 / 收工:/init /exit
對話管理:/clear /compact /resume
日常操作:/help /model /diff

這分組不是亂湊的——這正是你在一個 session 從頭到尾會經過的順序。


/init 看似一樣,產物完全不同(最容易踩第一坑)

三家 init 產物示意

三家 /init 都會「掃描你的專案、生成一份 markdown,給 agent 每次對話開頭讀」。但產物檔名不一樣:

  • Claude Code → CLAUDE.md
  • Codex CLI → AGENTS.md
  • OpenCode → AGENTS.md

AGENTS.md 是社群在 2025 年慢慢收斂出來的「跨工具標準」,目前 Codex、OpenCode、Cursor、Amp、Zed 全部採用。只有 Claude Code 還在堅持自家的 CLAUDE.md——這件事在 GitHub 上吵了將近一年(issue #6235 自 2025-08 開到現在),到 2026 年中還沒結論。

那實務上怎麼處理?兩種解法:

解法一:symlink 大法(跨工具團隊推薦)

# 在專案根目錄
touch AGENTS.md
ln -s AGENTS.md CLAUDE.md
# 之後只維護 AGENTS.md,CLAUDE.md 自動跟著動

這招 HN 上 很多人在用 ,乾淨。

解法二:在 CLAUDE.md 內嵌 AGENTS.md

# CLAUDE.md
@AGENTS.md
(其他 Claude 專屬指令…)

Anthropic 官方有承認這招會把 AGENTS.md 內容塞進 system prompt,等同直接讀。

順帶一提:OpenCode 會自動讀 CLAUDE.md——如果你已經寫好 CLAUDE.md 想切到 OpenCode,啥都不用改。Codex 不會,需要自己改名。

還有一個雷:別亂跑 /init

HumanLayer 的這篇 講得直白:自動生成的 CLAUDE.md / AGENTS.md 通常太長,會塞滿每一次對話的 context window,反而降低品質。

實戰建議:/init 第一次跑就好,跑完立刻精簡——只留下 LLM「光看 repo 結構推不出來」的東西(例如:團隊內部用詞、隱私限制、特殊架構決策)。剩下的全刪。50 行就很夠。


/clear vs /compact vs /resume——新手最容易死的三條 alley

對話管理三命令概念

這三個命令長得很像,做的事差很多。我看過太多人把它們搞混,結果不是燒爆 token,就是把重要對話清掉。

/clear——徹底重置

session 開始 → 講了三件事 → /clear → 對話歸零,但檔案改動還在

三家都有,但 alias 略不同:

  • Claude Code:/clear /reset /new 三個都一樣,/clear [name] 還可以順手把舊對話命名存到 /resume 選單裡(這設計超貼心)
  • Codex CLI:/clear 直接清螢幕+開新對話。如果只想清螢幕保留對話,按 Ctrl+L
  • OpenCode:/new 才是本名,/clear 是 alias。前一個 session 自動留在 /sessions 列表

⚠️ 三家都不會還原檔案改動。要還原檔案:

  • OpenCode:/undo(內建用 git 管,乾淨)
  • Claude Code:/rewind(可選「只還原程式碼 / 只還原對話 / 都還原」)
  • Codex CLI:手動 git restore,沒有 slash 命令

/compact——壓縮但保留

session 開始 → 講了 30 件事 → /compact → LLM 摘要前 28 件,最後 2 件保留原樣

三家都有,這是「長對話救命招」。社群公認最大的省 token 技巧不是 /compact,是用 /clear 換題。但如果你「想繼續同一個任務、但 context 已經滿到警告了」,這時 /compact 才出場。

Claude Code 還能帶參數指定保留焦點:

/compact Focus on the auth module and the failing tests

OpenCode 對應命令是 /summarize(與 /compact 互為 alias)。Codex 跑 /compact 會先問你確認再壓——保守派最愛。

/resume——三家「貌合神離」,差異最大

表面三家都做「恢復過去 session」,但底層機制完全不同:

工具 機制 體感
Claude Code 讀存檔的 transcript 重啟 冷啟動,狀態凍結重建
Codex CLI 讀本地存檔的 transcript 復原 類似 Claude,靜態
OpenCode 連回 live 的後台 server session 還活著,跑中任務沒中斷

夭壽,這就是為什麼 Medium 上有篇比較文 一直強調 OpenCode 的「session 持久性」是真差異化——它是唯一不怕 SSH 斷線的工具。

如果你的工作流會涉及長跑任務(測試套件、大型重構、批次處理),這個差異會直接影響你選哪家。


第一天就能跑的 6 步工作流

Day1 工作流流程示意

這套流程在三家 CLI 都通用。把它印出來貼螢幕旁邊,第一週照著做就對了。

# Step 1:進專案
cd /path/to/project

# Step 2:啟動工具(擇一)
claude          # Claude Code
codex           # Codex CLI
opencode        # OpenCode

# Step 3:第一個動作——產生專案說明檔
/init
# 跑完立刻打開 CLAUDE.md / AGENTS.md,刪掉 80% 廢話

# Step 4:開始對話
> 這個專案是做什麼的?先給我一張架構圖

# Step 5:對話一長就壓縮
/compact

# Step 6:commit 前看改動
/diff
# OpenCode 是 !git diff

# 隔天接續
/resume

# 換完全不同的任務時
/clear

# 收工
/exit

口訣(建議背起來):

/init 開局、/clear 換題、/compact 續命、/resume 接班、/diff 防爆、/exit 收工。

學會這 6 個動詞,你就能在三家 CLI 之間自由換家。其他 90+ 個命令是進階課題,等你穩了再慢慢吃。


三家獨家亮點(值得知道但別現在學)

最後留一張小抄,講三家「最值得多看一眼」的獨家命令。第一週不用碰,但知道它們存在,之後遇到痛點才知道要去找哪一家。

Claude Code 獨家

  • /rewind:選擇性回滾「程式碼 / 對話 / 兩者」。我覺得這是 Claude Code 最神的命令,比 git stash 還順手。
  • /btw <question>:「順便問一下」——暫時插隊問問題,不污染主對話。寫到一半想確認某 API 用法時超好用。
  • /security-review:對 pending 變更做安全審查。
  • /skills:列出所有 skill(社群在 這個寶藏地圖 收集了不少)。

Codex CLI 獨家

  • /personality:對話風格(friendly / pragmatic / none)。pragmatic 模式不會跟你寒暄,CI 用爆好。
  • /approve:批准 auto-review 拒絕的動作重試。
  • /experimental:開啟實驗功能,例如 subagents。

OpenCode 獨家

  • /share:產生公開 URL(opncd.ai/s/...),把 session 丟給同事看,連 onboarding 都省了。
  • /unshare:撤回分享。
  • /details / /thinking:toggle 工具細節與思考顯示。debug 神器。

寫在最後:別被命令數量嚇跑

90+ 個命令看起來嚇人,真正用到的就那 8 個。其他都是「你想到時才存在」的工具——遇到痛點才查 /help,不必預先全部記住。

CLI agent 這場仗打到 2026 年,三家已經明顯收斂在共通詞彙上:/init 產說明檔、/clear 換題、/compact 續命、/resume 接班。再過半年大概還會多幾個共通命令(/skills 看起來會收斂、/hooks 也快了),這篇之後我會更新。

入坑就從 /init 開始,跑完刪掉 80% 自動生成的內容,剩下的事就讓 agent 幫你做。


延伸閱讀

Claude Code 動態工作流程實戰:一個對話塞不下時,就讓上千個 subagent 一起上

環境與前置條件
- Claude Code v2.1.154 以上(claude --version 先確認)
- 付費方案(Pro / Max / Team / Enterprise)或 API / Amazon Bedrock / Google Vertex AI / Microsoft Foundry
- Pro 方案要先到 /config 把「Dynamic workflows」那一列打開
- 功能狀態:research preview(2026-05-28 隨 Claude Opus 4.8 一起發布),行為可能還會變
- 預設知識:你已經用過 Claude Code、知道 subagent 跟 slash command 大概是什麼

我第一次認真用 /deep-research 是想查一個 Node.js 權限模型的版本差異。我按下 Enter,然後——畫面沒有一行一行慢慢吐字,而是冒出一個背景任務面板,裡面有十幾個 agent 各自跑去搜不同角度、互相打架、把站不住腳的論點砍掉,最後丟回一份標好引用的報告。我那條對話從頭到尾還是空的、隨時能繼續打字。

那一刻我才意識到,Claude Code 的玩法被改寫了。過去 subagent 是「Claude 一輪一輪決定要派誰」,現在 Dynamic Workflows(動態工作流程) 把整個編排計畫搬進一段 JavaScript 腳本,由一個獨立 runtime 在背景跑,規模直接拉到單次最多 1,000 個 subagent。這次更新(細節見 The New Stack 的報導 )給我的整體感覺就一句話:過去那種「一次小心翼翼的單一 pass」,不再是預設玩法了。

這篇文章我會把它從頭講到尾——它到底是什麼、怎麼觸發、腳本長怎樣、pipeline 跟 parallel 到底差在哪(這裡超多人寫錯),還有那些一不小心就會燒掉一堆 token 的雷。

中央編排節點向外輻射出大量 subagent 節點的示意圖

Workflow 到底是什麼?跟 subagent、skill 差在哪

先把名詞釐清,不然後面會一直打結。Claude Code 裡能跑「多步驟任務」的東西其實有三種:subagent、skill、workflow。它們最核心的差別,官方文件 講得很精準——差在「誰持有那個計畫(who holds the plan)」。

Subagents Skills Workflows
本質 Claude 生出來的 worker Claude 遵循的一組指示 runtime 執行的腳本
誰決定下一步 Claude,一輪一輪 Claude,照著 prompt 腳本本身
中間結果放哪 Claude 的 context Claude 的 context 腳本變數
可重複的是什麼 worker 定義 那組指示 編排邏輯本身
規模 每輪幾個 同 subagent 每次 run 數十到數百個 agent
中斷怎麼辦 重跑那一輪 重跑那一輪 同 session 內可 resume

用 subagent 跟 skill 的時候,Claude 自己是那個指揮官:它一輪一輪決定接下來生什麼,而且每個結果都會掉回它的 context 裡。問題是 context 是有限的,當你要掃 300 個檔案、每個都吐一份報告回來,Claude 的腦袋很快就塞爆了,夭壽。

Workflow 的解法是把那個指揮計畫——迴圈、分支、中間結果——全部寫進程式碼。腳本自己持有狀態,Claude 的 context 最後只拿到一份濃縮過的答案。這不只是「能跑更多 agent」而已,它還讓你能套用可重複的品質模式:讓幾個獨立 agent 互相對抗審查彼此的發現、或從好幾個角度各自起草一份方案再拿來比,最後得到的結果比單次 pass 可信得多。

一句話記法,幫你以後不會選錯工具:

一兩個獨立調查     → 用 subagent
know-how 要重用    → 用 skill
編排本身要重複     → 用 workflow(fan out、比較發現、重啟失敗的 agent、存起來當命令)

workflow 與 subagent 編排架構對比流程圖

到底有多大規模?開發者社群流傳過一個會嚇到的個案:有人用動態工作流程把 Bun 從 Zig 移植到 Rust,據說原測試套件 99.8% 通過、約 75 萬行 Rust、十一天就 merge。這類數字我沒辦法逐一查證、純粹當茶餘飯後看,但那個量級感受得到。比較踏實、官方自己列出來的標準場景是:全庫 bug sweep、500 個檔案的大遷移、需要跨來源交叉驗證的研究、以及「值得從好幾個角度各自起草再擇一」的困難計畫。

三種觸發方式:關鍵字、deep-research、ultracode

要讓 Claude 幫你寫並跑一個 workflow,總共三條路。

第一條:prompt 裡丟 workflow 這個字。 最直接,單次觸發、不改 session 的設定。

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

Claude Code 會把那個字反白,然後改成「幫你寫一段 workflow 腳本」而不是一輪一輪手動做。如果你只是剛好打到 workflow 這個字、根本沒想觸發,按 alt+w 就能忽略這一輪。

第二條:內建的 /deep-research。 這是目前唯一的 bundled workflow,也是最好的入門體驗:

/deep-research What changed in the Node.js permission model between v20 and v22?

它會對問題從好幾個角度 fan out 網路搜尋、抓回來源互相 cross-check、對每個論點投票,最後給你一份引用完整、而且已經把站不住腳的論點濾掉的報告。

第三條:ultracode 模式。 這是把油門踩到底的玩法:

/effort ultracode

Ultracode = xhigh 推理強度 + 自動 workflow 編排。開了之後,Claude 每個實質任務都會自己判斷要不要編成 workflow,一個請求甚至會拆成好幾個連續的 workflow(一個負責理解程式碼、一個負責改、一個負責驗證)。代價就是每個任務都更燒 token、更慢,而且只在當前 session 有效,回到例行工作記得用 /effort high 降回來,不然帳單會讓你傻眼。

順帶一提,啟動時會不會跳權限確認,取決於你的 permission mode:Default / acceptEdits 每次都問(除非你選過「不再詢問這個 workflow」);Auto 只問第一次;Bypass、claude -p、Agent SDK 則直接開跑不問。有個細節很重要——workflow 生出來的 subagent 一律以 acceptEdits 模式跑、檔案編輯自動核准,但不在你 allowlist 裡的 shell / web / MCP 工具還是會在執行中跳提示。所以長 run 之前,先把 agent 會用到的指令加進 allowlist,不然跑到一半被一個權限框卡住,超雷。

腳本長怎樣:meta 加五個 API(順便校正坊間的簽名錯誤)

這一段是整篇的重點。我看過好幾篇教學把 API 簽名寫錯,照著抄一定跑不起來,所以這裡用 Claude Code 實際工具規格來校正。

先講清楚:官方那份 workflows 文件 主要描述「使用者怎麼操作」(觸發、權限、resume、成本),腳本層的 API 細節(agent / parallel / pipeline / budget / 程式化 resume 等)目前較少公開。下面這些簽名取自 Claude Code 的 workflow 執行環境(也就是 Claude 寫腳本時實際看到的規格),會隨版本演進——照抄前請以你自己 Claude Code 版本的實際行為為準。

每個 workflow 腳本必須以 export const meta = {...} 開頭,而且 meta 必須是純字面量——不能用變數、函式呼叫、展開運算子或樣板字串插值,runtime 會在你還沒跑之前就要讀它:

export const meta = {
  name: 'review-changes',                              // 必填
  description: 'Review changed files and verify findings', // 必填,權限對話會顯示這句
  whenToUse: 'after a large diff',                     // 選填,列在 workflow 清單裡
  phases: [                                            // 選填但建議,每個 phase() 對應一筆
    { title: 'Review' },
    { title: 'Verify' },
  ],
}

// 腳本本體從這裡開始,是 async context,可以直接 await
phase('Review')
const result = await agent('review src/auth.ts for bugs', { schema: FINDINGS_SCHEMA })

接著是五個核心 API,請務必看清楚參數型別:

API 簽名 重點
agent agent(prompt, opts?) 啟一個 subagent。沒給 schema 回傳純文字字串;給了 schema 回傳驗證過的物件。opts 有 label、phase、schema、model、isolation:'worktree'、agentType。使用者中途略過會回傳 null。
pipeline pipeline(items, stage1, stage2, ...) 每個 item 獨立流過所有 stage,stage 之間沒有 barrier。stage callback 收到 (prevResult, originalItem, index)。某個 item 在某 stage 拋錯就變 null、跳過後續。
parallel parallel(thunks) thunks 是函式陣列 Array<() => Promise<any>>,不是直接傳 agent。這是個 barrier,等全部完成才回傳。某個 thunk 拋錯那一格變 null(呼叫本身不會 reject),用之前先 .filter(Boolean)。
phase phase(title) 開一個新階段,之後的 agent() 在進度面板會歸到這個標題下。
log log(message) 對使用者吐一行進度訊息。

最容易寫錯的就是 parallel。 我看過不少文章寫成 parallel(agent(...), agent(...)),直接把 agent 的回傳值丟進去——這樣等於在呼叫 parallel 之前就已經把 agent 啟動了,整個並行的意義就沒了。正確寫法是傳還沒被呼叫的函式(thunk):

// ❌ 錯:直接傳 agent 的結果(簽名也錯)
const r = await parallel(agent('check a'), agent('check b'))

// ✅ 對:傳一個函式陣列,每個函式回傳一個 Promise
const r = await parallel([
  () => agent('check a'),
  () => agent('check b'),
])
const usable = r.filter(Boolean)  // 拋錯的會是 null,先濾掉

還有一個我大力推薦的東西:schema 結構化輸出。給 agent() 傳一個 JSON Schema,subagent 會被強制呼叫 StructuredOutput 工具回傳已驗證的物件,不符合還會自動重試。從此不用自己解析一坨文字、不用祈禱它格式對:

const FINDINGS = {
  type: 'object',
  properties: {
    findings: {
      type: 'array',
      items: {
        type: 'object',
        properties: {
          title:    { type: 'string' },
          file:     { type: 'string' },
          severity: { type: 'string' },
        },
        required: ['title', 'file'],
      },
    },
  },
  required: ['findings'],
}

const r = await agent('find bugs in src/auth.ts', { schema: FINDINGS })
// r.findings 直接是陣列,拿了就用

最後幾個會踩到的環境限制,先講免得你撞牆:

  • 腳本是純 JavaScript,不是 TypeScript。型別註記 : string[]、interface、generics 一律解析失敗。
  • Date.now()、Math.random()、無參數的 new Date() 會直接丟錯(因為它們會破壞 resume 機制)。要時間戳就從 args 傳進去,要亂數就靠 index 去變化 prompt。
  • 腳本本身沒有檔案系統跟 shell 存取權。讀檔、寫檔、跑指令都是 agent 在做,腳本只負責調度。

左側同步並行撞上 barrier、右側獨立交錯流動的資料流對比圖

pipeline 還是 parallel?這是最常踩的雷

這題我特別拉一段出來講,因為選錯的代價是白白浪費牆鐘時間。

原則一句話:預設用 pipeline,只有當「下一階段真的需要上一階段的全部結果」時才用 parallel 的 barrier。

pipeline 沒有 barrier。item A 可以已經在第三 stage,同時 item B 還卡在第一 stage。整段的牆鐘時間 = 最慢的那一條單一 item 的鏈,而不是「每個階段最慢的那個」加總。這個差異在 agent 速度落差大的時候非常明顯:

const DIMENSIONS = [
  { key: 'bugs', prompt: 'review for correctness bugs' },
  { key: 'perf', prompt: 'review for performance issues' },
]

const results = await pipeline(
  DIMENSIONS,
  // stage 1:審查
  d => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
  // stage 2:每個發現派人對抗驗證(不用等別的維度審完)
  review => parallel(
    review.findings.map(f => () =>
      agent(`Adversarially verify: ${f.title}`, { phase: 'Verify', schema: VERDICT })
        .then(v => ({ ...f, verdict: v }))
    )
  ),
)
// 'bugs' 的發現在驗證的同時,'perf' 還在審——牆鐘時間不浪費

那什麼時候才真的該用 parallel 的 barrier?只有這幾種:下一階段要拿到全集合才能動——例如在昂貴的下游工作前先去重 / 合併全部結果、或是要提早退出(「0 個 bug 就整段跳過驗證」)、或是下一階段的 prompt 要「跟其他所有發現比較」。

// barrier 真正合理的場景:去重後才驗證
const all = await parallel(DIMENSIONS.map(d => () => agent(d.prompt, { schema: FINDINGS })))
const deduped = dedupe(all.filter(Boolean).flatMap(r => r.findings))  // 真的需要全集合
const verified = await parallel(deduped.map(f => () => agent(verifyPrompt(f), { schema: VERDICT })))

有個嗅探測試很好用:如果你寫出來的是「parallel → 一段純資料轉換(flatten / map / filter,沒有跨 item 依賴)→ parallel」,那中間那個 barrier 根本不需要,把轉換塞進 pipeline 的 stage 裡就好。猶豫的時候,選 pipeline 準沒錯。

進階品質模式:讓 agent 互相打臉

Workflow 真正比「叫一個 agent 做事」強的地方,是它能套用結構化的品質模式。這也是 Anthropic 官方部落格 一直強調的賣點。

對抗驗證(Adversarial Verify) 是其中最實用的。發現一個問題後,不是直接信它,而是派 N 個獨立的懷疑者、prompt 明確要他們反駁,多數反駁就否決。據 MarkTechPost 的報導 ,這個「其他 agent 專門去反駁前面發現」的機制是內建在 run 裡的,只有撐過反駁的論點才會送到你面前。舉個我自己常遇到的情境:當一個 subagent 宣稱某函式有 race condition,你就讓另一個 subagent 的唯一任務是想辦法推翻它——推不翻,這個 bug 才算數。

const votes = await parallel(
  Array.from({ length: 3 }, () => () =>
    agent(`Try to refute this claim: ${claim}. Default to refuted=true if uncertain.`,
          { schema: VERDICT }))
)
const survives = votes.filter(Boolean).filter(v => !v.refuted).length >= 2

兩個霓虹綠 agent 對峙、綠色箭頭互相碰撞如辯論的示意圖

Judge panel(法官小組) 適合解空間很寬的問題:從不同角度(MVP 優先、風險優先、使用者優先)各生一份獨立方案,並行 judge 評分,最後從贏家綜合、再把亞軍的好點子嫁接進來。比「單一方案反覆迭代」常常好得多。

Loop-until-dry(跑到枯竭) 用在未知規模的發現任務(bug、edge case):持續派 finder 直到連續 K 輪沒有新東西。這裡有個經典的坑——去重要對著 seen 集合,不是對著 confirmed,否則被否決掉的發現每一輪都會重新冒出來,永遠收斂不了:

const seen = new Set(), confirmed = []
let dry = 0
while (dry < 2) {                                  // 連續兩輪沒新東西才停
  const found = (await parallel(FINDERS.map(f => () =>
    agent(f.prompt, { phase: 'Find', schema: BUGS })))).filter(Boolean).flatMap(r => r.bugs)
  const fresh = found.filter(b => !seen.has(key(b)))
  if (!fresh.length) { dry++; continue }
  dry = 0
  fresh.forEach(b => seen.add(key(b)))             // 對 seen 去重,不是 confirmed
  // ……對 fresh 做多 lens 評審後,把通過的 push 進 confirmed
}

還有 multi-modal sweep(多個 agent 各用不同方式搜:by-container、by-content、by-entity、by-time,補單一角度的盲區)跟 completeness critic(最後派一個 agent 專門問「漏了什麼?哪個模態沒跑、哪個論點沒驗證」)。這些模式可以自由組合,不是互斥的。

並發、budget、resume:跑大 run 之前要懂的事

規模拉大之後,有三件事一定要搞清楚,不然不是燒錢就是白做。

並發上限。 官方文件講的是「最多 16 個並行 agent,CPU 核心少的機器會更少」(確切公式官方沒講明,大致隨可用核心數遞減),超過的會排隊等空位。單次 run 的總量上限是 1,000 個 agent——這是防失控迴圈的後盾,遠高於正常用量。你還是可以丟 100 個 item 給 parallel / pipeline,它們全部都會完成,只是同一時間大概只有十個左右在跑。

Token budget。 一次 workflow run 可能比用對話做同一件事燒多很多 token,而且照樣計入你方案的用量跟速率限制。每個 agent 預設用你 session 的模型,除非腳本用 opts.model 把某個 stage 導去別的模型。所以大 run 之前先 /model 確認一下、把不需要最強腦的 stage 換成小模型。腳本裡還有個 budget 物件可以拿來動態縮放深度:

const bugs = []
while (budget.total && budget.remaining() > 50_000) {
  const r = await agent('Find bugs in this codebase.', { schema: BUGS })
  bugs.push(...r.bugs)
  log(`${bugs.length} found, ${Math.round(budget.remaining() / 1000)}k remaining`)
}

注意那個 budget.total && 的 guard 不能省——沒設預算時 remaining() 會回 Infinity,這個迴圈會一路跑到 1,000 agent 上限才停,爆肝燒錢就是這樣來的。

Resume(暫停與恢復)。 在 /workflows 裡選中一個 run 按 p 就能暫停 / 恢復,已完成的 agent 會回傳快取結果、其餘的繼續跑。據 digitalapplied 的整理 ,workflow 可以從先前的 runId 恢復,所以你改了腳本之後,沒被動到的 agent 不會重跑——最長未變動的呼叫前綴會秒回快取,從第一個被改或新增的呼叫起才實跑。對應的程式化重跑形式(帶 scriptPath 與 resumeFromRunId)屬於前面提過的腳本層 API,官方公開文件還沒完整載明,以你的版本實際行為為準。

但有一個硬限制要記住:resume 只在同一個 Claude Code session 內有效。你只要退出 Claude Code,下次啟動時 workflow 就從頭來過。所以多日的大工程,盡量別關。

霓虹綠進度環與暫停/恢復控制、周圍漂浮快取資料塊的示意圖

最佳實踐與踩坑清單

把前面散落的雷集中起來,這張表存著,下次寫 workflow 前掃一遍:

你做的事 後果 正確做法
parallel(agent(), agent()) 簽名錯、根本沒並行 parallel 收函式陣列 [() => agent(...)]
動不動就用 barrier 快的 agent 空等慢的,浪費牆鐘 預設 pipeline,barrier 要有正當理由
loop 去重對 confirmed 被否決的發現每輪重現,永不收斂 對 seen 去重
budget 迴圈沒 guard budget.total 沒設預算時 Infinity,跑到 1,000 上限 while (budget.total && remaining() > X)
腳本裡用 Date.now() / Math.random() 直接丟錯、破壞 resume 時間從 args 傳、亂數靠 index
期待 subagent 自己整合彼此的工作 重複跟衝突一堆 整合交給最後的綜合階段或你自己
退出 session 後想 resume 從頭跑、白燒一輪 resume 僅限同 session;或用 scriptPath + resumeFromRunId
沒設明確終止條件的迴圈 逼近 1,000 agent 上限 設品質閾值或 dry-count 退出

幾個正面的習慣也一起列:任務邊界要講清楚(「audit src/routes/ 每個 endpoint 缺漏的 auth check,附 severity」遠勝於「improve the codebase」);用 schema 拿結構化輸出免解析;subagent 任務要可獨立驗證、輸入輸出明確、只碰有界的檔案集;規模化之前先小跑(/deep-research 或先掃 5~10 個檔)確認成本;成功的 run 記得在 /workflows 裡按 s 存成 /<name> 命令重複用——專案級存 .claude/workflows/(可進 git、整隊共用),個人級存 ~/.claude/workflows/。

至於底層模型,這次 Claude Opus 4.8 的數字 也撐得起這套玩法——據報導 SWE-bench Pro 拿到 69.2%、長上下文檢索(GraphWalks long-context F1,1M tokens)達 68.1%,誠實度也明顯提升(官方主打未回報的程式碼瑕疵大幅減少)。對於要派上百個 agent 互相審查的場景來說,底層模型誠不誠實、看不看得懂長 context,直接決定了最後那份報告能不能信。

什麼時候該用、什麼時候別用

最後給個明確的判斷,免得你拿大砲打蚊子。

該用 workflow 的場景:全庫 bug sweep 或安全審計(100+ 檔)、大規模遷移(500+ 檔)、需要多來源交叉驗證的研究、值得從多角度起草再擇一的困難計畫。據 explainx.ai 的整理 ,這類「過去要一季、現在幾天」的大工程正是它的主場。

別用的場景:單檔編輯、快速 bug 修復、簡單問答——這些用對話或一兩個 subagent 就好,動 workflow 純粹是浪費 token。know-how 想重用就寫成 skill。token 預算緊張的時候也先忍著。

說穿了,動態工作流程不是要取代你跟 Claude 的對話,而是給你一個「當任務大到一個 context 裝不下」時的逃生艙。先從 /deep-research 玩起,習慣那個背景任務面板的節奏,再試著在 prompt 裡丟一個 workflow 讓 Claude 幫你寫第一支腳本。跑順了、覺得這流程每條 branch 都會重複,就按 s 存起來——下次它就是你自己的 / 命令了。

要不要現在就開一個小的試?挑你手邊一個「想掃但一直懶得掃」的資料夾,丟一句 Run a workflow to ...,看看十幾個 agent 同時上工是什麼感覺。跑完不妨在留言區分享你燒了多少 token、值不值得。


參考資料

Vibe Coding 是什麼?AI 驅動的程式開發新典範

Vibe Coding 是什麼?深度研究 💡

Vibe Coding 概念圖

🎯 定義與起源

Vibe Coding(氛圍編碼)是一種新興的程式開發方法,這個概念由OpenAI共同創辦人、電腦科學家Andrej Karpathy於2025年2月在社群平台首次提出。這種方法的核心是開發者大量依賴AI工具生成程式碼,讓工程師可以將注意力從寫程式碼的細節轉移到更高層次的產品設計與架構思考。

[time=Feb 15, 2025] [color=#907bf7] 「最熱門的新程式設計語言,是英文。」(The hottest new programming language is English.)

更具體來說,Karpathy在他的原始貼文中描述Vibe Coding為:

[time=Feb 2, 2025] [color=#907bf7] 「有一種新式編碼我稱為『vibe coding』,你完全順應氛圍、擁抱指數成長,並忘記程式碼的存在。這是可能的,因為LLMs(例如Cursor Composer搭配Sonnet)正變得太強大。而且我只用SuperWhisper跟Composer對話,所以幾乎不碰鍵盤。我會要求一些超懶的事情,像是『把側邊欄的邊距減半』,因為我懶得去找。我總是『全部接受』,從不閱讀程式碼。」

Karpathy用此詞描述一種沉浸式、情境導向的程式設計方式,強調開發者與AI共創的氛圍,並主張「寫程式不必執著於邏輯,而應專注於整體vibe」。

在Vibe Coding的開發流程中,程式設計師不再需要記憶複雜的語法或API詳情,而是專注於描述想要實現的功能,並讓AI工具協助完成實際的編碼工作。


✨ Vibe Coding的特點

1. 以AI為核心的開發流程

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

graph LR A[開發者] -->|自然語言描述| B[AI工具] B -->|生成代碼| C[程式碼] C -->|審核與調整| A style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#333,stroke-width:2px style C fill:#bfb,stroke:#333,stroke-width:2px

根據Y Combinator (YC)的調查,許多使用Vibe Coding方法的創辦人估計他們的程式碼庫中有超過95%是由AI生成的。開發者變成了指導者和審核者,而不是每行代碼的直接編寫者。

2. 注重高層次思考 🧠

Vibe Coding使開發者能夠專注於:

  • 系統架構設計
  • 使用者體驗
  • 產品功能規劃
  • 業務邏輯與價值

3. 快速原型開發 ⚡

這種方法特別適合快速原型設計,讓想法能更迅速地轉化為可測試的產品,大幅縮短開發週期。

4. 即時互動式開發方式 💬

當AI生成的程式碼不符合預期時,開發者可以直接使用自然語言回饋,例如「請加上錯誤處理」或「換成深色主題」,AI就能迅速調整並重新寫程式,減少反覆測試與手動修改的成本。

5. 三大支柱 📐

根據2025年Reddit上的「Vibe Coding Manual」,Vibe Coding建立在三個基本支柱上:

規格說明:明確表達目標(例如「創建一個具有登入功能的Twitter克隆」)

規則設定:建立明確的約束條件(例如「使用Python,保持簡單」)

監督指導:監督和引導開發過程,確保保持專注


↔️ Vibe Coding與LLM Coding的區別

雖然Vibe Coding與LLM Coding(利用大型語言模型輔助編程)看起來相似,但兩者有以下本質差異:

特點 Vibe Coding LLM Coding
核心理念 「完全順應感覺」和「忘記程式碼」,專注於創意和整體架構 仍保持對程式碼的關注,需具備基本程式語言知識
開發者角色 成為AI的指導者或協作者,使用自然語言表達意圖 開發者仍主動審查和修改生成的代碼
與程式碼互動 鼓勵直接接受AI建議,通常不詳細檢查代碼變更 審查、測試和理解所有代碼
技術門檻 大幅降低,非程式設計師也能參與開發 相對較高,使用者仍需具備一定程式知識
主要工具 Cursor AI、Claude、Superwhisper等 GitHub Copilot、Code Llama、StarCoder等

[time=Mar 10, 2025] [color=#ff6b6b] 「如果LLM寫了你所有的程式碼,但你已經審查、測試和理解了所有這些程式碼,那就不是vibe coding——只是使用LLM作為打字助手」


🛠️ Vibe Coding的流行工具

想要開始Vibe Coding,以下是幾款常用的工具:

1. Cursor AI
這是一款由AI驅動的程式碼編輯器,被認為是目前最具代表性的Vibe Coding編輯器,基於VS Code打造,專為與GPT-4類模型整合而設計。它的Composer聊天介面讓使用者可以與AI對話,請求生成函式、新增功能、重構程式碼,甚至修正錯誤。所有變更都會以diff顯示,使用者可以有信心地逐項審查後套用。

// Cursor AI 範例對話
User: "幫我建立一個簡單的登入表單,使用React和styled-components"
AI: "好的,我來為您創建..."
// AI生成完整的React登入表單代碼

2. Claude 3.7 Sonnet
由Anthropic開發的Claude 3.7 Sonnet是一款強大的大型語言模型,特別適合Vibe Coding應用。它理解複雜的需求描述,能將自然語言轉換為各種程式語言的高質量代碼。

3. Super Whisper
這是一款為coding優化的語音轉文字引擎,讓開發者可以通過語音指令進行Vibe Coding,實現真正的「語音寫Code」。Vibe Coding追求的「擁抱氛圍」,其中一環是鍵盤都不用了,要透過語音寫Code來實現。

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

sequenceDiagram participant 開發者 participant SuperWhisper as Super Whisper participant CursorAI as Cursor AI participant 程式碼庫

開發者->>SuperWhisper: 語音指令:"在畫面中央加一個藍色按鈕"
SuperWhisper->>CursorAI: 轉換為文字指令
CursorAI->>CursorAI: 處理指令並生成代碼
CursorAI->>程式碼庫: 添加/修改代碼
程式碼庫->>開發者: 呈現代碼變更結果
開發者->>SuperWhisper: 語音確認或調整:"把按鈕改成綠色"
SuperWhisper->>CursorAI: 轉換新指令
CursorAI->>程式碼庫: 更新代碼
程式碼庫->>開發者: 顯示更新後結果</div>

4. Replit
Replit是一個集開發、部署與AI協作於一體的線上平台,其內建的Ghostwriter AI可理解自然語言描述,自動生成前後端程式碼,使用者可直接在瀏覽器中撰寫、測試並部署應用。對於學生、創業者與非技術背景者來說,是進入Vibe Coding最友善的入口之一。


🚀 Vibe Coding對創業生態的影響

當美國頂尖創業加速器Y Combinator在2025年提出「不採用Vibe Coding的開發者將被淘汰」的觀察報告時,這場由Karpathy點燃的技術革命,已徹底改變矽谷新創圈的遊戲規則。

据Y Combinator的最新調查顯示:

  • 最新一批創業公司中,有25%的公司程式碼庫中有高達95%是由AI生成
  • 當前孵化的創業公司中約有「81%」是AI公司

[graphviz 圖表 — 原始 HackMD 版本可正常渲染]

digraph impact {
    rankdir=LR;
    node [shape=box, style=filled, color=lightblue];
    VC [label="Y Combinator觀察"];
    VCC [label="Vibe Coding革命"];
    T1 [label="精簡團隊結構"];
    T2 [label="加速開發週期"];
    T3 [label="降低技術門檻"];
    T4 [label="減少資金需求"];
VC -> VCC;
VCC -> T1;
VCC -> T2;
VCC -> T3;
VCC -> T4;
}

Y Combinator的CEO Garry Tan表示,Vibe Coding正在「超級充電」(Super-Charging)創業公司,使它們能夠保持更精簡的團隊結構。這使軟體建構過程整體更有效率,讓創業公司能以更少的資源完成更多工作。

對於那些正在努力進入日益緊縮的就業市場的人來說,Tan認為Vibe Coding的出現恰逢「完美時機」。它為年輕工程師提供了獨立創業的機會,而不是依賴大公司來開啟他們的職業生涯。

🎭 Vibe Coding對開發者角色的改變

Vibe Coding正在從根本上改變軟體開發者的角色:

從編碼者到設計師:開發者從直接編寫程式碼轉變為設計系統和定義需求,更專注於創造性思考和問題解決。

從技術專家到領域專家:技術知識的重要性減少,而對業務邏輯和用戶需求的深入理解更加重要。

從獨立工作者到AI協作者:開發者學習如何有效地與AI合作,提供適當的指導和修正,以獲得最佳結果。

從重視語法到重視溝通:清晰表達需求的能力變得比掌握編程語言的細節更重要。

🌐 Vibe Coding的應用場景

Vibe Coding目前最適合應用在以下場景:

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

mindmap
  root((Vibe Coding應用場景))
    快速原型設計
      將概念轉化為可測試產品
    教育領域
      降低編程入門門檻
    個人專案
      實現複雜項目
    藝術創作
      創新數位藝術作品
    跨領域合作
      促進不同背景人士協作
    MVP開發
      節省時間和資源
    非技術創業
      参與產品開發

✅ Vibe Coding的最佳實踐

要有效地使用Vibe Coding,以下是一些最佳實踐:

1. 明確的需求描述:用清晰、具體的語言描述你想要實現的功能

   // 不清晰的需求
   "做一個用戶頁面"
   // 清晰的需求
   "創建一個用戶資料頁面,包含頭像、姓名、電子郵件和個人簡介,
   使用圓形頭像,簡約設計風格,添加編輯功能按鈕"

2. 迭代式開發:不要期望一次性獲得完美結果,通過多次反饋和調整來改進

3. 保持對結果的審查:雖然Vibe Coding強調接受AI的建議,但仍需確保結果符合需求

4. 了解基本概念:掌握基本的程式設計概念,以便能夠理解和評估AI生成的代碼

5. 學習有效溝通:發展與AI有效溝通的能力,學習如何描述需求和提供反饋

⚠️ Vibe Coding的挑戰與局限

雖然Vibe Coding帶來諸多便利,但也面臨一些挑戰:

代碼品質與可維護性:AI生成的代碼可能缺乏最佳實踐或可維護性,尤其在大型、複雜的專案中

安全隱憂:自動生成的代碼可能含有未被識別的安全漏洞,AI coding缺乏資安意識

對複雜系統的適應性:對於高度複雜或性能要求極高的系統,人工編碼仍有優勢

對AI工具的依賴:開發流程高度依賴AI服務的可用性與能力

理解和調試困難:當AI生成大量代碼時,開發者可能難以全面理解和有效調試

創新的限制:如果過度依賴AI生成解決方案,可能限制真正創新和獨特解決方案的發展

👥 誰最能從Vibe Coding受益?

根據MIT Media Lab的AI安全研究員Tobin South的觀察,Vibe Coding主要有兩類受益群體:

1. 經驗豐富的開發者 像Karpathy這樣已經熟悉編程的專業人士,他們知道如何在AI出錯時進行修正,可以將Vibe Coding作為加速開發的工具。這類開發者能夠:

  • 快速評估AI生成代碼的品質
  • 識別並修復潛在問題
  • 有效引導AI產生更優質的結果

2. 完全的新手 沒有或極少編程經驗的人,他們可以借助AI工具實現過去無法獨立完成的項目。這包括:

  • 想要實現簡單應用的非技術人員
  • 學習編程的初學者
  • 有創意想法但缺乏技術能力的創作者

除此之外,Vibe Coding也特別適合:

  • 非技術背景的創業者與企業家
  • 產品經理與設計師
  • 學生與教育工作者
  • 內容創作者與數位藝術家

📚 學習Vibe Coding需要什麼技能?

要有效地運用Vibe Coding,最關鍵的是學會與AI工具有效溝通:

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

graph TD
 A[明確表達需求和目標] --> B[熟悉基本程式設計概念]
 B --> C[掌握提示工程技巧]
 C --> D[培養問題分解和系統思考能力]
 D --> E[持續學習新AI工具和功能]
 style A fill:#f9f,stroke:#333,stroke-width:2px
 style C fill:#bbf,stroke:#333,stroke-width:2px
 style E fill:#bfb,stroke:#333,stroke-width:2px

🔮 未來展望

隨著生成式AI技術的不斷進步,Vibe Coding可能將重塑軟體開發的未來。它不僅改變了程式設計師的工作方式,也降低了技術門檻,使更多人能夠參與到數位創造中。

在不久的將來,我們可能會看到:

1. 更多專門為Vibe Coding設計的工具:工具將更加直觀,更適合非技術人員使用

2. 編程教育的轉變:教育重點從語法和實現轉向系統設計和問題解決

3. 開發團隊結構的改變:技術專家和領域專家的界限變得模糊

4. 更多由非技術創始人創建的科技創業公司:降低的技術門檻將使更多有創意的人能夠創建科技公司

5. 程式設計變成通用素養:程式設計可能會從專業技能演變為更普遍的素養,就像今天的文字處理或電子表格技能一樣,成為知識工作者的基本能力


🌟 結論

Vibe Coding代表了AI時代軟體開發的新範式,它既不是傳統編程的完全取代,也不僅僅是輔助工具,而是一種全新的思考和創造方式。無論你是專業開發者還是技術愛好者,了解和掌握Vibe Coding都可能成為未來數位世界的重要能力。

Tags: Vibe Coding AI 軟體開發 創業 未來趨勢 程式設計


本文最初發布於 HackMD @BASHCAT。

8GB 的 RK3588 能跑多聰明的 LLM?ROCK 5C 用 NPU 實測 5 個模型

先講結論,省得你滑到最後: 在一片 8GB 的 RK3588 板子上,用 NPU 跑得最聰明的是 Qwen3-4B-Instruct-2507,我出的 7 題全對,但每秒只吐 3.7 個 token。 想要順一點的對話體驗,Qwen3.5-2B 的 8.4 tok/s 是比...