痛點之尺 · 拆解《演算法》

作者 山姆（謝冠生）・喵喵書評創辦人 ·發布 2026-07-18

分類：生產力

讀過近千本商業書，這篇不複述內容——只用《痛點》的 P.A.I.N. 之尺，挑這本書最該被戳的那一格，講一句你帶得走的判斷。拆一本書的四個步驟 →

加速自動化之前，先問這事該不該做

特斯拉前總裁喬恩・麥克尼爾，把馬斯克掛在嘴邊的那套「演算法」拆成了五個步驟：質疑每一個要求、刪掉能刪的、簡化、加速、自動化。這本書真正的重點，全押在它們的順序上——順序一顛倒，整套就壞了。

大多數人記得的，是最後兩步。誰不想要一條半夜還自己在跑的產線、一套睡覺時還在成交的系統。於是他們一頭栽進去加速、自動化，把一個環節磨得又快又順又漂亮。磨到某天才發現：那整條被磨到發亮的流程，打從一開始就不該存在。

馬斯克自己就栽過。他花了大把力氣去加速、去自動化弗里蒙特工廠裡的某些環節，回頭才想通，那些環節該先被刪掉。把一件不該做的事做到極致，只是把錯誤做得更有效率而已。這就是為什麼「質疑每一個要求」得排在第一步：它是踩剎車確認方向的那一下，方向對了，後面四步的油門才踩得有意義。

這套演算法不是麥克尼爾坐在辦公室想出來的。它是在特斯拉內華達與弗里蒙特工廠那幾波「生產地獄」裡，一次次撞牆撞出來的。麥克尼爾當時就在現場，這也是這本書比一般管理書更值得聽的地方：它記下的每一步，都對應一個真的讓馬斯克付過代價的錯。

第一步在問的，其實是《痛點》那句老話

把工廠語言換成創業語言，第一步「質疑每一個要求」問的，跟《痛點》那把尺對著你點子問的，是同一件事：這個東西，真的有人要嗎。

麥克尼爾記下一個很硬的做法：在特斯拉，每一個「要求」後面都得掛一個人名。不是「工程部說要」，是「某某某，在某年某月，說要」。因為掛了名，你才追得回去問他：這條規定今天還算數嗎，還是只是沒人敢動的慣性。一條沒有主人的要求，多半是沒人再驗過的假設。

創業者的產品裡，塞滿了這種沒有主人的要求。那個非加不可的功能、那個「客戶應該會想要」的服務、那頁精心設計的流程——問一句「這是誰、根據什麼、說一定要的」，一半答不出來。答不出來的，就是你正埋頭去簡化、去加速、去自動化的那個「不該存在」。

【打比方】這就像蓋房子前不先問「這塊地會不會淹水」，只顧著挑磁磚、選門把、把水電配到最省。等你把屋子蓋得美輪美奐、燈光自動化到用手機就能開，第一場大雨來，整棟泡在水裡。磁磚挑得再好，都救不了一塊本來就不該蓋的地。馬斯克的第一步，就是那句你最不想聽、卻最該先問的：這塊地，到底該不該蓋。

為什麼偏偏是第一步最常被跳過

因為前四步之外的每一步，都給人一種「我在前進」的爽感。刪一個功能、簡化一頁流程、把交期壓短、讓機器接手——每一下都看得見成果，都能發個進度截圖。只有第一步不給你成就感，它要你回頭質疑自己當初憑什麼做這件事。它像剎車，其他四步像油門。人本能地愛踩油門。

可《痛點》看過太多這樣的故事：一個團隊把兩年時間全花在把產品做快、做省、做到能自動出貨，上線那天才知道，這件事本來就不會有人買單。他們每一步都執行得無可挑剔，只漏了最上游那一步——沒有人停下來，質疑那個「要求」本身。

刪到會痛，才叫真的刪

順帶說第二步。麥克尼爾記下馬斯克刪東西的一條硬規矩：要刪到後來得把其中至少一成加回來——如果你不用把任何東西補回去，代表你根本沒刪夠。這句話狠在它的預設：它假定你一定會刪不夠，於是逼你刪到過頭，再往回收。

對創業者，這條規矩是一把篩子。你的功能清單、你的路線圖、你答應客戶的每一項服務，真按這把尺砍下去，砍到心疼、砍到怕砍過頭，才可能砍到那個沒人要的核心。多數人的做法剛好相反：一路加，捨不得減，把每一個「說不定有人會用」都留著，於是產品越長越腫，離那個真正的痛卻越來越遠。

把五步驟，收成一句話

你不用背下這五個字。你只要記得順序背後那句提醒：別急著刪減、加速、自動化，先蹲下來質疑那個需求本身——它到底是不是真的。

今晚就挑一件你正打算「做得更快更好」的事，別動手優化它。先問一句：如果這件事根本不做，會怎樣。答案要是「好像也沒差」，那你剛剛替自己省下的，就是麥克尼爾整本書想幫馬斯克省下的那筆——把力氣花在不該存在的東西上。這道題，比任何自動化都先該解。

發現引用或事實有誤？請寫信回報，我會依更正政策修正。