One-Person Unicorn，一人獨角獸的時代來臨？

2024 年 4 月份 Sam Altman 提出 One-person unicorn 的時代來臨了，他強調的是在不久的將來，可能會有一些公司只有一位 CEO，其他的工作全部都由 AI 來完成。而且這樣的公司不見得就是傳統小規模的一人公司，而是有機會成為一家獨角獸公司。

經過這半年多對 AI 的學習之旅，自己天天用 AI 工具，並用 AI 工具來解決具體問題。也聽了許多公司如何使用 AI，並參與了一些公司的開發團隊使用 AI 做軟體開發的過程。

我想藉由這篇跟大家分享一些我對 AI 融入工作與生活的想法。

相信 AI 做得到

我相信現在還是很多人在探討 AI 「做得到什麼」與「做不到什麼」。而這種想法的背後，往往是為了找到不使用 AI 的理由。

例如透過 AI coding，可能因為 AI 很難參與複雜程式的開發，也不容易理解技術債，加上有太多 domain know-how 需要說明，也經常將程式碼改壞了。

所以得出結論是，AI 適合做全新程式開發，或者個人工具開發。這段話我也曾經說過，但我覺得我現在有些想法上的改變。

到底是我沒用對，還是 AI 真的做不到？
到底是我沒認真去找到與 AI 互動的方式，還是 AI 真的搞不懂？
到底是我把期待拉太高，沒有給 AI 定義好 R&R，還是 AI 太笨？

我後來發現，其實是我把期待一開始就拉太滿所導致，如果我一樣把 AI 當成一個 role，而不是一個不分角色，不分權責，不分年資的全能角色。

如果我把 AI 當成一個學科能力很強，且沒有參與過較大規模軟體開發工作的 senior engineer。同時他才剛進公司沒多久，在公司的年資很淺，對公司產品的理解有限。

當我對 AI 的角色設定是這樣，期待是這樣，那他不懂技術債，不懂 domain know-how 本就是理所當然的事。既然他本來就不懂，那身為協作者的我，就有義務要告訴他。

當我做出了這樣的調整，我發現 AI 很多事都做得到了。

AI 技術一定還有很多進步空間，但我建議大家好好擁抱 AI，相信 AI 做得到。

當你願意相信 AI 做得到，你就會繼續找方法去善用 AI，而不是選擇將 AI 束之高閣。唯有如此，你才能享受到 AI 時代的紅利，才不會被時代給淘汰了。

可只有相信是不夠的，以下我整理了幾個很重要的觀念與能力，是我建議大家可以多多練習與強化的。

盤點能力

在麥肯錫的問題解決方法中有個很重要的概念較 MECE(Mutually Exclusive, Collectively Exhaustive)，也就是互斥與窮舉。

如果你能將一件事情的可能性、元素、分支流程盡可能的窮舉出來，那對於跟真人或跟 AI 溝通都會大有幫助。可同時我們也要盡可能避免窮舉出來的選項彼此有重疊，因此我們還要考慮這些選項之間是否互斥。

關於 MECE 的細部說明我不多作介紹，但大家可以想像，當我需要跟一個人溝通時，我說：「我需要一個會員功能，會員有分一般會員跟管理者。」

這樣的敘述是否足夠清楚？不一定，但如果你能盡可能盤點所有的會員角色，並具體描述每個角色的權限範圍，那這個溝通必然會更有效。

這種能力不管是跟 AI 或真人溝通，其實都是很重要的。

善用 SMART 原則

所謂 SMART 原則其實是一種讓需求或情境具體化的方法，下表是我之前在談目標設定時使用的表格。

Specific：
明確的，你不可能跟 AI 說「有錯誤，請修正錯誤」或者「我想要新增一個數字欄位」這種含糊不清的需求。你得告訴他錯誤出現在哪，是什麼樣的操作程序所導致，正確的結果是什麼。你得將問題在哪，為什麼出錯，什麼樣才正確等清楚告知，不然他不會理解。

Measurable：
可衡量的，如果今天是個效能問題，你必須要告訴 AI 達成什麼樣的效能怎麼樣才算過關，乘載多少使用者才算滿足需求。如果是個費用問題，你得告訴他用最少的 token 完成任務，但怎麼樣算少呢？你可能得給一個具體數字，例如單次 prompt 不使用超過 20 個 token。

Attainable：
可達成的，你不能又要馬跑又要馬兒不吃草。承接上個案例，限制 AI 不能擴充機器，但要實現百倍的效能提升，很可能就是一種刁難，因為實務上或許這麼幹並不現實。

Relevant：
相關聯的，這是要確保你要 AI 完成的任務跟你想完成的目標是一致的。

Time-bound：
具時效性的，一週減 5 公斤跟一個月減 5 公斤，兩者會採取的行動是不一樣的，這就是時效對行動帶來的影響。與 AI 協作時，時效或許不是那麼重要，但在與人互動時，時效還是挺關鍵的。

脈絡關係

也就是 context，可能是前因後果，也可能是領先指標與落後指標的關係，還可能是相關性。AI 可能懂得常識，但有太多組織內的知識他是不能理解的。

像是公司為什麼對客訴零容忍，所以客服案件的優先級永遠高於業務，又或者是公司的北極星指標為何設定為客戶數而非營收金額。

進入到系統環節的話，如果沒有架構圖、部署圖，沒有人把元件與元件間的關係告訴 AI，那他當然不知道改了 A 很可能會導致 B、C、D 崩壞。你只讓他把 A 改對，A 是對了，但其他地方掛得一蹋糊塗。

過去在與真人協作時，我們是靠著流程制度卡關，然後口耳相傳來傳遞這些知識。但 AI 無法跟你口耳相傳，他也不會主動找你討論以取得更多資訊。這就很仰賴我們提供給他的資訊是否充足了。

定義與一致性

每間公司的行話與術語都略有差異，所以當我們進入到一家公司時總得適應一段時間，而這種適應 AI 也會需要。只是人類是透過文件、會議討論、教育訓練來獲得，而 AI 則是得透過文件定義、一致性的 prompt 用語來理解。

關於行話與術語的定義必須要夠明確，讓 AI 在讀到這些關鍵字的時候理解能一致，這才能避免產出錯誤的結果。請不要像與真人互動一般說話，因為 AI 能讀出弦外之音，也能搞懂你的 hidden agenda，但 AI 現在還辦不到。

就像我跟 AI 說「數據脈絡」，他肯定無法理解這是什麼概念，我必須要把定義告訴他。並在往後溝通時，如果提到與因果、相關性相關的議題時我就會用數據脈絡這個詞來表示。這樣雙方在溝通的用詞就會趨於一致。認知落差會小，溝通效率也會提高。

定義明確，用詞一致，這是有效溝通的基礎，也是軟體工程中很重要的一個環節。

全貌很重要

在從前，我們每個人都只扮演了組織中一顆小螺絲釘，所以我們往往只著眼於自己手邊的任務。但也因為我們對工作全貌的掌握度較低，所以我們在與 AI 互動時往往只能針對我們理解的範圍來溝通。最常見的問題就是 AI 會給我了一個「局部最佳化」的結果。

舉例來說，我是 AI Agent 團隊的工程師，我請 AI 幫我用 token 極小化的方式來處理請求，目的是降低使用 AI 的費用。但這種模式可能反而拖累了 backend service 的效能，導致 backend team 為了提升效能而提升了機器等級或改變了系統部署架構，產生了新的費用。

AI 團隊的費用降低了，但 backend 團隊的費用卻提高了。最終到底有沒有省到錢呢？不好說。這就是缺乏全貌時很容易產生的結果。

這種人與人之間因為分工而產生的問題，在我們面對 AI 時也會發生。如果你沒有給 AI 全貌，那他很可能會認認真真幫你解決一個不存在的問題。

流程自動化

人類的可貴之處在於我們會自己找事做，會自己去學習，自己去釐清各種資訊，我們會有許多自發性的行為。

但目前的 AI 通常是處於我們有對他下 prompt 他才做事，而這也是為什麼現在興起了 AI Agent 風潮的原因，因為我們需要將很多工作交由 AI 來完成，但又不希望每一次都需要人工介入，或者每一次都獲得不同的結果。我們希望能自動化。

我建議，如果請 AI 協助的事項不是一致性的，而是常態性的，那最好把流程梳理清楚，並讓這件事自動化處理。能自動化的東西，通常品質都會愈來愈穩定，因為你不會想每天介入這個工作，你會嘗試找出跟 AI 溝通的問題，並持續優化。

流程自動化，其實也是一種一致性。

把 AI 當成一個具體的人來對待，設定的背景如本文開頭所述。

把 AI 當成一個學科能力很強，且沒有參與過較大規模軟體開發工作的 senior engineer。同時他才剛進公司沒多久，在公司的年資很淺，對公司產品的理解有限。

調節好期待，認真的跟這位 AI 同事協作，提供他必要的資訊，讓他能順利完成他的工作。

友善對待他，不要霸凌他，不要不教而殺，你會發現自己進步了，AI 也幫助你更好的完成了工作。

如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。