錯誤的流程配上夠強的人，也會穩定產出正確的結果——這正是它最危險的地方。

六個現場，排成一列

昨天結尾說，把這七天的洞攤開來看，會發現一個共同結構。今天不講新故事，就做這件事：把第二部的六個現場排成一列，等霧散開。

Day 08｜需求只有一句話
→ 資深工程師自己把該問的十件事問完、補完

Day 09｜介面沒有契約
→ 兩位老戰友用交情跟默契，一次對通

Day 10｜沒有 Acceptance Criteria
→ 他知道客戶驗收那天會點哪裡、皺哪種眉頭

Day 11｜沒有 ADR
→ 原作者剛好路過，一句話擋下重構地雷

Day 12｜變更沒有紀錄
→ PM 當場背出三個月的口頭變更時間軸

Day 13｜新人找不到資訊
→ 全辦公室的人腦，輪流充當索引

左邊那欄，是六個不同的工程缺口：Requirement、Interface Contract、Acceptance Criteria、ADR、Change Record，以及「資訊應該被設計成可取得」的基本責任。

右邊那欄，是六個看起來不同的解法。把左欄遮起來，只看右邊，會發現六個答案其實是同一個字：

人。

同一個結構，重複了六次：

流程缺一塊
   ↓
有人剛好補得上
   ↓
事情做成了
   ↓
組織記住的是「事情做成了」
   ↓
缺口原封不動，等下一次

當時團隊怎麼理解這件事

六個現場的當事團隊，說法各自不同，邏輯完全一致：

需求不用寫那麼細，我們資深的看得懂；介面文件太官僚，他們兩個對一下就好；驗收條件他心裡有數，寫出來也是形式；想知道當初為什麼這樣設計，問原作者最快；變更記在 PM 腦裡最即時，開單多慢；新人多問問人，順便熟悉團隊。

每句單獨看都有道理。更麻煩的是，每句都被結果驗證過：功能如期上線、聯調一次就通、驗收一次通過、地雷沒有爆、驗收會被救回來。六個現場，全部成功。

於是「成功」變成了證據——證明這些東西真的都不用寫。

這是第二部真正想指出的事：

專案成功，不等於流程有效。有時候只是有人強到讓所有缺口隱形。

正式命名：血脈壓制

Day 01 埋過一個暫稱，說之後會正式立論。就是今天。

這個詞借自小說跟遊戲：當雙方等級差距夠大，招式、屬性、規則通通不重要，高等級的一方站在那裡就贏了。放回專案現場，它的正式版本長這樣：

血脈壓制（大神壓制）：高能力團隊以隱性知識與個人判斷補足流程缺口，使錯誤的流程仍然穩定產出正確的結果，並讓組織據此得出「我們的流程沒有問題」的結論。

拆開來，對應幾個工程管理上的老詞——點到為止，各記一行就好：

Hero Culture
→ 組織依賴並獎勵救火的英雄，而不是修好會起火的流程

Tacit Knowledge
→ 完成工作必要的知識存在人腦，沒有外化成別人可取得的形式

Bus Factor
→ 少掉幾個人，專案就停擺；第二部六個現場的答案全是：一

契約 → 交情
→ 該由 Contract、AC、Record 承擔的協作，改由默契與記憶承擔

要強調一件事：這六個缺口，不是沒有解法才淪落至此。Requirement、Interface、Acceptance、Decision、Change，瀑布用它的重文件回答過，敏捷用輕 Artifact 回答過——Story 加上對話、契約加上測試、AC、輕量 ADR、有紀錄的重排。兩套方法都沒有一條規則叫做：

「這題可以不答，因為我們有資深的。」

大神腦袋裡疊了什麼

第二部每天都問一次「大神腦袋裡藏了什麼」。把六天的答案疊起來，會得到跟 Day 02 那個瀑布故事一樣的結論：他不是沒做這些 Artifact——他全做了。需求他澄清了、介面他對齊了、驗收標準他維護著、決策脈絡他記得、變更史他背得出來、新人的每個問題他都答得上。用記憶做、即時做、看起來免費地做。

組織以為自己很輕量。其實是把整套工程 Artifact，外包給幾顆特定的人腦。

而血脈壓制最危險的地方不是依賴本身，是它會自我強化：

大神越補，流程越沒有修的理由
   ↓
流程越不修，越依賴大神
   ↓
專案越成功，組織越相信「我們的流程很成熟」
   ↓
獎勵流向救火，而不是流向防火

最後一行不是推論，是現場實錄：Day 10 慶功時，PM 說「這次需求寫得不錯」——功勞記給了一份不存在的文件；Day 12 會後，大家稱讚的是 PM 的記憶力。連帳都記錯了，組織自然不會知道自己欠了什麼。

先說清楚：這一切不是大神的錯。他沒有做錯任何事，他做了所有對的事。要檢討的從來不是「為什麼有人這麼強」，而是——

為什麼這些事情，必須靠某個人剛好知道？

這次到底誰在吸收代價？

老規矩。這次一口氣結算六個現場：

Scope       □   答應的一項都沒少
Time        □   全部「如期」——帳面上
Cost        □   沒人追加預算，因為帳單還沒寄到
Quality     □   暫時無事；Day 09 那三天聯調是預告片
Risk        ■   六個現場的 Bus Factor 都是一
人          ■   六篇勾了六次，一次都沒漏   ← 第二部總結

前四格乾乾淨淨，正是血脈壓制的招牌景象：代價沒有消失，只是沒有記帳。Risk 那一格是唯一誠實的——它記著所有「剛好還在、剛好路過、剛好記得」，而剛好，總有一天會湊不齊。

如果沒有大神，應該留下什麼

直覺的答案是：「請大神把知道的全部寫下來。」不可能。隱性知識之所以隱性，是因為連本人都不覺得那是知識——他不覺得「知道客戶會皺哪種眉頭」需要寫下來，就像你不覺得呼吸需要寫進行事曆。要求一次寫完，只會得到一部誰都不看的百科全書。

比較誠實的第一步是盤點，不是搬家：先列出哪些事情此刻只活在一個人腦裡、他不在時會發生什麼，再決定哪幾件最該先落地、落成什麼形式。第二部留下的六個 Artifact——澄清清單、介面契約、AC、ADR、Change Record、Onboarding 缺口清單——就是「落地成什麼」那一欄的現成選項。

今日 Artifact｜大神依賴盤點表

找你的團隊，誠實填。每一件「只有某人知道」的事填一組，先填三組就好：

□ 這件事只有＿＿＿＿真正知道：＿＿＿＿＿＿
□ 他不在的話，會發生：＿＿＿＿＿＿
□ 應該落地成：＿＿＿＿
  （澄清清單／Contract／AC／ADR／Change Record／文件）

填不出來有兩種可能：你的團隊真的沒有這種事——或者，連「哪些事只有他知道」這件事，也只有他知道。

今日一句

我們以為流程成熟，其實只是人太強；強到讓錯的流程，一直給出對的結果。

第二部到此為止。六個現場有一個共同前提，安靜地躺在每個故事的背景裡：那個人，剛好都在。

所以第三部只需要問一個問題：

如果今天，沒有那個大神呢？

明天開始，講一個小專案的完整翻車過程。它的需求，只有一句話。