60/30/5 讓 AI 產品先會改稿

這篇把 60/30/5 規則拆成可直接套用的 editing-first AI 產品模板。

我最近一直在看一種很煩的 AI demo。模型接上了、prompt 也寫了、畫面也做得很漂亮，結果一問就只會「我幫你完成」。聽起來很猛，實際上很空。因為真正做事的人，根本不是要一個替他把事情做完的機器；他要的是一個能先丟草稿、再讓他改、讓他砍、讓他接著往下做的工具。這差很多。

我就是被這個落差卡到，才去看 Forbes 上 Sourabh Pateriya 的文章。他不是在講什麼 AI 神話，而是拿音樂製作來拆工作流：哪些地方適合 AI 出主意，哪些地方適合 AI 當副手，哪些地方根本不該全交出去。這個角度很實用，因為它直接把「模型能做什麼」拉回「人到底願意讓出多少控制權」。

我看完只想說一句：很多 AI 產品不是太弱，是太急著結案。你還沒開始編輯，它就想收工；你還沒建立信任，它就想接管。這種產品在 demo 場合很會演，在日常工作裡通常很吵。下面我把這套 60/30/5 拆開，順手給你一個可以直接抄的版本。

別把「生成」當成「完成」

“60% use AI as an ideation tool... 30% use it as a co-producer... Only 5% delegate full production to AI.”

翻譯一下就是：大多數人不是想把整個工作丟給 AI，他們只是想先有個起點。真正有價值的，不是一次把成品吐出來，而是先幫人脫離空白頁。

這點我踩過很多次雷。以前我也看過不少工具，功能列表寫得像魔法：輸入一句話，輸出一篇文章、一段程式、一個設計稿。問題是，專業工作從來不是「有沒有初稿」而已，而是「這份初稿能不能被我快速改成我要的樣子」。如果不能，生成得再快都沒用。

所以 60/30/5 的第一個重點，不是比例本身多神，而是它把 AI 的角色分層了。60% 是發想，30% 是協作，5% 才是完全委派。這個分法很像現場製作：先有旋律、再疊樂器、最後才決定哪裡要交給機器跑。人還是主控，AI 只是把前面最卡的那段磨平。

實操上，我會建議你把產品預設成「草稿模式」而不是「成品模式」。不要一開始就問使用者要不要全自動，先問他要不要三個方向、五個版本、或一段可編輯的起手式。讓使用者先看見選項，再決定要不要往下推。

• 預設輸出 draft，不要預設 final。
• 先給 3-5 個方向，再讓人收斂。
• 把「改掉一小段」做成主要操作，不要只剩重生整份內容。

真正值錢的是判斷，不是吐字速度

“Producers are paid for taste, not output.”

也就是說，專業者拿錢不是因為他按得快，而是因為他知道什麼該留、什麼該刪、什麼看起來對其實很怪。這句話我很買單，因為它直接打臉一堆把 AI 產品做成「大量出字器」的人。

我自己看過太多團隊把「產量」當成價值。結果呢？模型是會生，使用者也真的收到一堆東西，但最後還是要人重寫、重排、重判斷。這時候 AI 沒有省時間，只是把時間從前面搬到後面，還順便增加了心理負擔。使用者不是在創作，是在收垃圾。

音樂製作之所以適合拿來講，就是因為它很誠實。你聽到一個 chord progression 不對，就是不對；你不用先寫一篇長文證明它不對。AI 產品也一樣。使用者真正買單的，不是模型能不能一次講完，而是他能不能很快看出問題、修掉問題、保留自己的判斷。

我之前做過一個內部知識工具，團隊很愛「一鍵生成摘要」。結果大家用兩週就膩了，因為摘要看起來像真的，但細節常常歪掉。後來我們改成「先生成，再標出可疑句，讓人逐段確認」，使用率反而上來。原因很簡單：人比較願意修 draft，不願意收一份假裝完成的答案。

實操寫法很直接：把 accept、reject、revise 做成一級功能。不要藏在右上角小按鈕。也不要只記錄最後結果，連使用者改了哪裡、為什麼改，都要留下來。那不是 log，那是產品學習資料。

• 每次生成都要可局部接受，不要只能全收。
• 把使用者修改過的區塊標出來，讓他知道自己掌控了什麼。
• 把常被推翻的段落當成產品弱點，而不是使用者不會用。

雙向工作流比一次性 prompt 更像真的合作

“The work is bidirectional. The AI is the junior collaborator, and the producer is still the artist.”

翻譯一下就是：好用的 AI 工具不是自動販賣機，而是那種會先交草稿、再聽你罵、再改一次的 junior teammate。它不能只會交作業，它要會接 feedback。

這句我很有感，因為很多產品團隊都太愛做「一槍斃命」的流程。使用者輸入一次，模型回一次，完了。聽起來很乾淨，實際上很不符合工作現場。真正的工作是來回修、局部改、保留上下文，然後持續往前推。

我在寫作工具上也遇過同樣問題。只要系統要求我一次給出完美 prompt，我很快就不想用了。不是我懶，是我根本不會在第一輪就知道自己要什麼。可是如果工具允許我先丟一個粗方向，再慢慢修成我想要的語氣、結構和長度，我就會留下來。因為那比較像工作，不像抽卡。

所以你在設計 AI 產品時，別只問「能不能生成」，要問「能不能接續前一輪」。保留狀態、保留修改痕跡、保留局部重生的能力。這些東西看起來不性感，但它們決定使用者願不願意第二次打開。

實操上，我會建議你把整個互動拆成三層：先定義意圖，再生成候選，再針對局部修正。每一層都要能回頭，不然使用者只會覺得自己在跟一個很會講話但完全不記得前文的人合作。

• 不要讓每次修改都重跑整份內容。
• 把上下文固定住，讓 AI 知道自己改的是哪一段。
• 讓使用者能把幾個版本拼在一起，而不是二選一。

使用者不是怕 AI，是怕自己變成校稿機器

“The people who chose music as a career did not do it so they could become editors of machine output.”

這句話很狠，但很準。翻成白話就是：人不是為了當機器輸出的審稿員才進這個行業的。大家想要的是更快、更順、更少卡住，不是把自己降級成機器的清潔工。

這也是為什麼很多所謂「全自動」產品會讓人反感。不是因為使用者討厭效率，而是因為那種效率很像把人從創作者變成監工。你要他一直盯著 AI 哪裡做錯，最後他只會覺得自己在替模型打工。

我自己最不爽的，就是那種把「少按幾下」包裝成「少做很多事」的產品。少按幾下不等於少負擔。只要最後還是要你逐段檢查、重寫、補洞，那就不是自動化，那只是把工作藏起來而已。

實操上，你要先守住使用者的身份感。產品最好能讓他保留風格、語氣、限制條件，甚至是個人偏好。讓他看得出這份成果是「我修出來的」，不是「AI 替我交出去的」。只要這個感覺在，接受度就會高很多。

如果你的產品是做內容、設計、程式、分析報告，這點更重要。因為這些工作本來就有作者性。你不能一邊跟人說「放心交給我」，一邊把他的判斷權拔掉。那樣產品再強，使用者也只會想逃。

先救火，再談創作，這才像真的工作

“They are using stem separation to rescue an old recording, AI-assisted mixing to balance a chaotic session or MIDI generation to break a writer’s block at 3 o’clock in the morning.”

也就是說，最有價值的 AI 使用情境，常常不是「從零創造一個神作」，而是「把快壞掉的東西救回來」。這句很務實，我反而最喜歡。因為真實工作本來就一堆救火場景。

你看這些例子：救老錄音、平衡混亂的 session、凌晨三點打破卡關。這些都不是華麗的場景，但都是會付錢的場景。因為它們直接省下時間、減少痛苦、保住進度。對使用者來說，這比任何炫技 demo 都有感。

我很建議產品團隊把這種「救援時刻」列出來。使用者在哪裡最容易卡住？哪裡最常需要重做？哪裡不是缺靈感，而是缺一個能幫忙收尾的工具？這些地方通常才是 AI 最有機會切進去的入口。

實操上，不要先從「我要幫你創造」開始，先從「我幫你把爛尾救回來」開始。因為救援場景比較容易建立信任。使用者一旦知道你能把半成品修好，他才會慢慢把更前面的環節交給你。

這也是我對 AI 產品最現實的建議：先做能讓人少崩潰的功能，再做能讓人更有靈感的功能。順序反了，通常只會得到一堆看起來很厲害、實際上沒人每天打開的工具。

60/30/5 其實是在提醒你別做錯層

“The bulk of the value lives in ideation. A meaningful middle lives in collaboration. A thin sliver lives in full delegation.”

翻譯一下就是：大部分價值在發想，中間一段在協作，真正全交出去的比例其實很薄。這不是音樂專屬，這是所有 AI 產品都該先承認的現實。

我覺得這套框架最有用的地方，不是它很漂亮，而是它逼你先問一個很難聽但很重要的問題：使用者到底願意把哪一段工作交給 AI？如果你不先回答這題，就很容易把產品做成「功能很多，但沒有一段是人真的想用到底的」。

很多團隊是反過來做的。先看模型能做什麼，再想辦法包成產品。這樣很容易做出 demo，卻做不出 daily tool。因為你沒先處理信任、控制、編輯權、回退機制，使用者當然不敢把它放進主流程。

實操上，你可以直接把功能分成三類：發想、協作、委派。然後檢查你的 roadmap。只要三類裡面有一類完全空白，或是全部都擠在「委派」，那通常就代表你在做展示，不是在做工作流。

我自己會用這個規則反問每一個 AI 功能：它是在幫人想，還是在幫人改，還是在幫人全包？如果答案講不清楚，功能多半也不會清楚。這種時候，砍掉比硬做更省事。

可抄的模板

# Editing-first AI 產品模板（60/30/5 版本）

## 產品原則
AI 先幫使用者發想與改稿，最後才碰完全交付。

## 設計規則
1. 預設輸出草稿，不預設成品。
2. 讓使用者可以局部接受、局部拒絕、局部重寫。
3. 每次生成都保留上下文與版本歷史。
4. 只重生選取區塊，不重跑整份內容。
5. 把使用者修改過的內容當成產品訊號。
6. 讓使用者保有風格、限制與最終決定權。

## 工作流
- Step 1：使用者先輸入目標、限制、語氣、不可碰的邊界。
- Step 2：AI 先產出 3 個方向或一份 rough draft。
- Step 3：使用者挑一個方向，並直接在原文上修改。
- Step 4：AI 只針對被標記的區塊重寫。
- Step 5：保留 diff、版本與最後輸出。

## 你該問的產品問題
- 使用者最常卡在哪一段？
- 哪些內容是 AI 最容易寫歪的？
- 哪些地方一定要人來定調？
- 使用者最常改掉哪一類句子或區塊？
- 什麼是最小但有用的 AI 動作？

## 功能清單
- [ ] 草稿模式
- [ ] 局部接受 / 拒絕
- [ ] 選取區塊重寫
- [ ] 版本歷史
- [ ] 可視化 diff
- [ ] 使用者註解 AI 錯誤
- [ ] 最終輸出由人確認

## Prompt 範本
你是我的 junior collaborator。先產出草稿，再給 3 個可選方向。不要假裝完成，不要自動定稿。每次修改只改我選的區塊，保留我的語氣、限制與上下文。

## 評估方式
不要只看生成速度。要看：
- 使用者最後保留了多少 AI 內容
- 使用者平均改了幾次才交付
- 哪些區塊最常被推翻
- 使用者是否願意第二次打開

## 反模式
- 一鍵生成整份成品
- 沒有編輯權的自動輸出
- 每次改動都重跑全文
- 看起來很聰明，但不能局部修
- 把使用者當旁觀者，而不是作者

這篇的原始來源是 Forbes Council 文章。我前面對 60/30/5 的拆解、產品化建議與模板整理，都是基於這篇文章再加上我自己的 AI 產品經驗；引文與核心框架歸 Sourabh Pateriya，模板與應用方式是我整理出來的可抄版本。