不同的程序員在寫代碼時總有些獨特的習慣和小癖好。有人追求代碼的極致嚴謹和規范，有人熱衷于將邏輯壓縮得干凈利落，有人喜歡在注釋里加幾句自嘲或者冷笑話，也有人走上了更“文藝”的路線——在代碼中悄悄藏下一些只屬于自己的小彩蛋。

只是這些看似無害的“個性表達”，有時候也會踩到大公司的“雷點”。

John Calhoun 就是這樣一個例子。他早年因開發 Mac 平臺上的獨立游戲（如 Glider）而小有名氣，90 年代中期被蘋果招募入職。剛進公司那會兒，他還帶著點“獨立開發者”的隨性勁。有一天，他在系統的顏色選擇器資源的里，藏下了 T.S. Eliot 的一段詩句，作為彩蛋埋在代碼里。

沒想到，這個看似浪漫的小動作，差點讓他丟掉工作，也把他自己推上了“見高層、等處分”的邊緣。那是他第一次差點被蘋果解雇，成了他二十多年職場生涯里，始終記得的一課。

隨著他將自己這次《The First Time I Was Almost Fired From Apple》（我第一次差點被蘋果解雇）的經歷分享出來，也引發了巨大的討論：程序員在寫代碼時，到底能“玩”到什么程度？那些藏在代碼深處的“彩蛋”，到底是個性表達，還是一場風險操作？

接下來，我們不妨先看看發生在 John Calhoun 身上的真實經歷。

原文鏈接：https://www.engineersneedart.com/blog/almostfired/almostfired.html

作者 | John Calhoun 編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

1995 年 10 月，John Calhoun 被蘋果錄用。

那時正值蘋果最艱難的時期之一。他回憶道——當時的蘋果公司處于“在下水道邊緣打轉”的階段——外界媒體唱衰不斷，坊間也頻頻傳出“蘋果快要倒閉”的猜測。在這樣的背景下，蘋果依然在招聘新工程師，多少顯得有些反常。

但這家公司邏輯大概是：雖然公司搖搖欲墜，但還是得找個「圖形工程師」來繼續維護 QuickDraw GX 這個圖形技術。

說起來，這個技術是蘋果公司在 1990 年代初期推出的一項圖形系統技術，意圖作為原有 QuickDraw 圖形引擎的“下一代替代品”。不過，它最終并沒有成功推廣，被稱為蘋果歷史上“短命而先進”的技術之一，當然這些都是后話了。

彼時年僅 31 歲的 Calhoun，是一名為蘋果 Macintosh 設備寫游戲的獨立程序員。或許正因為這層背景，蘋果認為他是個合適的人選。

當慣了自由開發者，Calhoun 首次參加蘋果公司的面試時，感受到了前所未有的職業氛圍，好在他還是幸運地拿到了 offer，正式成為 Apple Computer, Inc. 的一名 QuickdrawGX 圖形工程師。

緊接著，他帶著女朋友、所有家當和兩只貓，從美國的堪薩斯搬到了蘋果公司所在的加州。對他來說，這不僅僅是一次搬家，更是一次徹底的生活轉軌。很快他意識到，自己在這份新工作中需要學習的不只是技術，還有真正意義上的“職場專業性”。

在蘋果公司初來乍到，他甚至一度懷疑自己是否勝任這份工作——蘋果的工程師們不僅聰明，還極富專業精神，而他則像個剛跳進深水區、手腳亂劃的新手。

不過，大約半年后，Calhoun 逐漸進入狀態，開始適應節奏，能夠踏實地推進自己的任務。但正如他自己所說的那樣，離“職場成熟人士”還差得遠，怎么看都還是個毛手毛腳的鄉下程序員，和所謂的“專業大公司范兒”格格不入。

他最初參與的 QuickdrawGX 項目在他入職不久后就宣告失敗，隨后他被調到另一個叫做 ColorSync 的團隊，并接手了一個新任務：將蘋果標準顏色選擇器（Color Picker）從老舊的 Motorola 68K 處理器遷移到更快的 PowerPC（PPC）平臺上。

顏色選擇器的遷移

蘋果的這個顏色選擇器其實是個模塊化設計，里面包括兩種配色器：一種是 HSL（色相、飽和度、亮度），另一種是 RGB（三原色）。

尤其是 HSL 那一塊，原來是用匯編語言寫的，能做到用戶一邊拉“亮度”滑塊，顏色輪一邊實時渲染，性能非常高效。簡單解釋一下，匯編是一種非常貼近硬件底層的編程語言，針對特定芯片寫的——而這段代碼就是為 Motorola 68K 芯片量身定做的。

所以，想在 PPC 上運行，就得把這些匯編代碼“清理”出去，換成別的寫法。

對剛加入蘋果不久的 John Calhoun 來說，這項任務毫無疑問是個“下馬威”。畢竟，他之前從未接觸過匯編語言。用他自己的比喻來說，這感覺就像拿到一本中文書，卻被要求翻譯成英文——前提是你根本不會中文。

盡管如此，Calhoun 還是咬牙啃下了這項任務。他用熟悉的 C 語言重寫了原有匯編邏輯，成功在 PPC 芯片上跑出了 HSL 色彩輪。

Calhoun 在博客中寫道：

要說把這個項目交給我，是因為大家都看好我，那也太天真了。其實就是沒人愿意干，剛來那小子正好就可以“安排”上了。是不是有點“甩鍋”的味道？也許吧，但這種事在公司里并不稀奇。

不過對此 Calhoun 也并不介意，反而從這些沒人爭的項目里，找到了一些屬于自己的成就感。

在接手顏色選擇器的過程中，他還遇到不少新概念，比如大量 callback 回調機制——起初完全看不懂。為了避免不小心破壞原有代碼的邏輯，他干脆決定自己從頭寫一個顏色選擇器。與其硬啃別人寫的代碼，不如親手造一遍輪子，這樣反而更容易理解整體流程。就像學中文最有效的方式，是直接去中國住一陣，通過“沉浸式”學習語言。

就其個人喜好而言，Calhoun 坦言，自己并不喜歡 HSL 模型，而更習慣使用 HSV（色相、飽和度、明度），這在做美術工作時對他來說更直觀。所以他把編寫一個 HSV 配色器也加進了自己的“待辦列表”中。

HSV 顏色選擇器

當他把自己的顏色選擇器寫出來、運行起來后，發現這事其實還挺好玩的。可能正因為有點上頭，Calhoun 又動手寫了一個新的配色器。

那時候，萬維網（www）剛開始火起來，于是他自然地想到：做一個 HTML 配色器應該挺有意義的。這個配色器基本還是基于 RGB，但數值是用十六進制表示的，比如 “ 這樣的格式，方便網頁設計師直接復制使用。

HTML 配色器

沒過多久，他又寫了一個“蠟筆配色器”。此時， Color Picker 項目已經基本完成， Calhoun 稱 ，自己 對它也算是摸透了。“后面這些配色器，純粹就是我玩得起勁，順手加的。”

Calhoun 寫的蠟筆配色器，有 60 支蠟筆可選。原始顏色和當前選擇顏色會以涂鴉形式展示，帶點隨機效果。第一排是棕色、冷暖灰色；第二排是飽和度很高的純色；后面幾排顏色越來越淡；最后一排全是中性色的灰。

為了規避法律風險，Calhoun 還特意查了蠟筆調色板的商標版權相關問題。得出的結論是，“Crayola”是注冊商標（美國著名的蠟筆制造商品牌），蠟筆尾部的波浪紋圖案也可能受保護，所以他干脆換了名字和設計，確保可以正常上線。

Calhoun 表示，他喜歡那個年代的蘋果公司，因為“工程師才是掌舵人”。他之所以寫 HSV 顏色選擇器，是因為覺得它對藝術創作者更友好；寫 HTML 顏色選擇器，是因為 Web 的發展讓它變得有用；而蠟筆選擇器，完全是出于一種本能的判斷——蘋果的產品應該讓“普通人”也能感受到樂趣與親近。HSL 和 RGB 是工程師的世界，而蠟筆，則是我們大多數人從小接觸顏色的方式。

令人驚喜的是，最終蘋果竟然把他寫的這些顏色選擇器軟件全部發布了。沒有市場部來提需求，也沒有設計部門審核功能是否“有商業價值”。但工程師們不僅是寫代碼的人，也是產品的用戶，他們憑直覺知道哪些東西是 Mac 用戶真正想要的。

至少對 Calhoun 而言，他只是把自己想要的工具，做出來了而已。

軟件中埋下“彩蛋”引發爭議

說到這兒，不得不提一件讓 John Calhoun 至今記憶猶新的插曲——關于他親手埋下的“彩蛋”。

在軟件世界中，所謂“彩蛋”（Easter egg）指的是那些被悄悄藏在程序里的小驚喜、小幽默。在 Mac 社區，發現或分享一個彩蛋是一件非常有趣、甚至帶點神秘感的事。而在蘋果內部，這種文化更是活躍。

Calhoun 當時剛加入公司，身邊正是那些曾參與彩蛋創作的老工程師，自然也萌生了一個念頭：自己也想在代碼里藏一個屬于自己的彩蛋。

這個念頭，最后幾乎讓他丟掉飯碗。

事后回想起來，他認為問題并不在于“做彩蛋”本身，而在于彩蛋的本質就是隱藏的、非公開的東西。那么，這類內容需要提前報備嗎？還是“先做了再說”，事后解釋求個原諒？他選擇了一個折中的做法——跟幾位同事打了聲招呼，征詢了一下意見。但顯然，這一步做得還不夠周全。

而這個讓他差點惹禍上身的彩蛋，其實就是幾行詩句，出自 T.S. 艾略特的名作《普魯弗洛克的情歌》：

“我們在海的密室中徘徊，

由海藻纏繞的海之少女圍繞身旁，

直到人聲將我們喚醒，我們便沉入海底。”

Calhoun 把這段詩句拆分成幾段，作為顏色選擇器中多個資源項的名稱使用。這些名稱就像網頁里圖片的文件名一樣，平時是不會直接呈現給用戶看的。但如果有人深入查看顏色選擇器的底層資源，就有可能偶然發現這些詩句。

而毫無疑問，后來確實有蘋果內部人員在操作系統構建流程中檢查字符串時，注意到了這段來自詩人 T.S. Eliot 的文字。

在 Calhoun 看來，這只是一個低調又克制的小彩蛋。他原以為這首詩已經進入公版領域，即便沒有，三行引用按理說也應屬“合理使用”。然而他忽視了一個關鍵事實：蘋果對版權問題一向極為敏感。畢竟公司歷史上曾多次因為知識產權問題惹上麻煩，而這一點他當時并沒有真正意識到。

更大的問題在于，他在“大公司企業文化”這門課上仍屬新手，不清楚在一家大型科技公司里做事的邊界與規范。結果，出于一份純粹的浪漫與無知，他差點在無意中把蘋果即將發布的操作系統推向法律風險的邊緣。

好在，萬幸，這個“彩蛋”字符串在系統真正制作發行版光盤之前被及時發現，避免了更嚴重的后果。

被叫去辦公室談話

John Calhoun 已經記不清事情發生時的所有細節了。當時可能是他的經理先得到了消息，然后把他叫進辦公室，告訴他闖了大禍。對于一位剛入職不久的員工來說，這無疑是一記重擊。而這位經理的憂慮顯然不止是 Calhoun 一人，他也很清楚，這種“任性操作”可能會連累整個團隊，甚至影響到他本人。

最終，經理告知他需要與蘋果的一位高層會面，這場會面將直接決定他是否還能繼續留在公司。

雖然記憶模糊，但 Calhoun 當時心里非常清楚：他真的惹了大麻煩，飯碗恐怕難保了。

他確實見到了蘋果負責操作系統項目的負責人——一個在蘋果早期就小有名氣的人物。據 Calhoun 回憶，這位高管常騎著一輛本田 Goldwing 摩托上下班，嘴里還叼著煙斗，是公司里少有的“老派角色”。

那次談話的情景，Calhoun 至今記得。他被嚴厲訓斥了一番，高管還告訴他，為了這段“詩意的彩蛋”，公司不得不銷毀一批刻了操作系統的光盤，這無疑是一筆不小的損失。

Calhoun 試圖解釋，自己原以為不會涉及版權問題，但對方顯然毫不買賬。在幾句無力的辯解之后，他索性認錯，接受了即將到來的任何處罰。

這位高管還問過他對接下來結果的看法。Calhoun 坦言，自己也意識到工作可能保不住了。但他也明確表態：如果公司愿意給他一個機會，他保證今后絕不會再做出類似的愚蠢舉動。

結果出乎意料——他留了下來。而且，這一干就是二十多年。不過這件事也成了他的“職場前車之鑒”，時不時用來告誡那些剛入職的新人：別太拿自己的“個性”當回事。從那天起，他在蘋果的每一步都變得格外謹慎，時刻考慮著總部會如何解讀他的行為，以及可能帶來的影響——無論這些影響是有意為之還是意料之外。

Calhoun 表示，回頭看，那一刻對他而言頗為羞恥。在蘋果這樣的大公司犯錯，就像在社交場合里出丑，立馬暴露出你成長環境的粗糙和不成熟。

這并不是他第一次在職場上體會“缺乏白領訓練”的代價。還有一次，是入職幾年后，經理問他為什么沒有參與公司提供的 401(k) 退休計劃。他一臉茫然：“那是什么？”后來才知道，原來入職第一天蘋果安排了整天的新人培訓，內容包括退休計劃的介紹和如何從工資中扣款設置。但 Calhoun 那天直接跳過了培訓，自顧自地跑到辦公室報到。

其他彩蛋

盡管一度面臨被解雇的風險，John Calhoun 最終還是留在了蘋果。他自己也說不清這是為什么。也許蘋果覺得沒必要這么做，或者覺得人非圣賢，允許給新人一次犯錯的機會，也有可能，是他的經理在關鍵時刻為他爭取了一把——這一切至今仍是謎。

事實上，Color Picker 中除了那段被質疑的詩句，還藏著其他幾個無傷大雅的彩蛋。比如在“蠟筆配色器”里，用戶可以看到蠟筆隨著時間推移而逐漸磨損甚至“斷裂”。雖然這一視覺效果不會影響功能，但充滿了童趣和細節感。每年圣誕節，所有蠟筆還會“自動重生”，仿佛剛換上了一整盒新的顏色。

另一個隱藏玩法，則是在特定操作下可以顯示一些“彩蛋色名”——實際上是項目組成員名字的字母重組（即字謎）。Calhoun 只記得其中一個彩蛋名叫“I Born Short”。

他猜測，在那次“藏詩事件”之后，這些無害的小彩蛋也被一并撤下了。是否真的如此，他不敢斷言，也許其他人會知道得更多。

不過后來的一些跡象表明，有些彩蛋其實還是悄悄被保留了下來。比如就有用戶發現，顏色選擇器里的蠟筆會隨著時間推移慢慢“磨損”，像真的被用過一樣。

程序員能否在代碼中留“彩蛋”？

回顧 John Calhoun 的經歷，一個本意純粹、風格浪漫的彩蛋，差點釀成職業生涯的重大危機。

而在 Hacker News 上，許多開發者也分享了對“代碼彩蛋”的看法。不少人認為，只要彩蛋無害、不影響功能，也不踩版權或合規的紅線，它反而是代碼世界里一絲幽默與人情味的體現。

有網友指出：

我覺得大眾（這里也包括不少軟件工程師）普遍高估了那種“一出大錯就被炒魷魚”的概率——就像電影里演的那樣。現實中，只要錯誤不是（1）出于惡意或蓄意，或者（2）明顯暴露出你完全不勝任這份工作，那么通常不會直接導致被解雇。大多數“重大失誤”，其實都出現在那些本意良好、技術扎實的工程師身上，只不過他們當時犯了一個真誠的錯誤而已。

從公司或管理層的角度，正確的做法不是立刻開除出錯的人，而是讓他們去修正問題（可能還需要別人的幫助）。而現實中，大多數公司確實也是這么做的。雖然也確實存在一些管理糟糕的公司會因此開人，但那應該是少數。

當然，也有人對此持更謹慎態度：

我從來不是彩蛋的忠實粉絲。從風險管理和質量保障（QA）的角度看：一個軟件項目本來就有很多可能出錯的地方，為什么還要特意加一個沒人要求的東西？哪怕它只有 1% 的幾率出問題，也未免太不值得了。因為一旦真的出故障，你還得寫事故復盤報告，到時候你要怎么解釋？

彩蛋，究竟是“多余的風險”，還是“程序員的浪漫”？可能每個團隊、每家公司都有不同答案。而對每一個工程師來說，也許真正重要的不是彩蛋本身，而是清楚它出現在哪里、為什么存在、又可能帶來什么后果。那么，你寫過“彩蛋”嗎？

——對話清華大學教授劉嘉 | 萬有引力

AI 產品爆發，但你的痛點解決了嗎？

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人

12 大專題分享，洞察趨勢、拆解路徑、對話未來。

立即掃碼領取大會PPT

搶占 AI 產品下一波紅利