來源：Social Network（2010），IMDB

網路創業者最擔心的就是，擁有新穎的點子卻沒有可付諸執行的人力，所有夢想都只是空談。對網路創業者來說，找到對的人──優秀的程式設計師、軟體工程師，是團隊成功的關鍵性因素，同時也是一項艱難的挑戰。 為了要找到優秀的開發者，擁有許多資源的大公司會利用人資部門進行履歷的初步篩選，再請公司內部的開發者，對應徵者施以程式測驗和其他專業評估來挑出適當人選；但是，新創公司和小型企業並沒有那樣多的資源，甚至沒有幾位人力資源的專業人才。再甚者，很多新創公司創辦人並非資訊科技領域出身，不會寫程式、也看不懂程式碼 ，找到對的開發者更是難上加難。 然而，這並不是無法解決的問題，只要利用以下技巧就能找到「對的人」：

心態面

想清楚你「真正」的需求

專門開發 Android app 的 Torch Lab 執行長 Kevin Galligan 表示，如果你是完全的新手，你可花數個月學習程式語言──但不用擔心如何真正執行。為了避免限入無限研究的困境，應該先暫停一下，仔細清點你的需求。問自己兩個關鍵的問題開始： 1. 你需要你的網站可以做什麼？擁有一個網站並不一定意味著需要雇用一個開發者。你是簡單地公佈有關貴公司的信息，還是你的網站有「做」什麼事情？當你的網站需要和使用者開始互動的那一刻，至少和一位開發者聊聊。 2. 你試圖創造的是什麼？你的創業點子，是 Mobile 的產物，還是 Web 的產物，或兩者兼有之？如果答案為「非100％的網路」，你就需要找到擁有行動經驗的開發者。否則，你必須花費成本請 Web 開發者學習行動開發。

了解開發者的心理

吸引頂尖開發者的的最好方法，就是像他們一般思考。 Torch Lab 執行長 Kevin Galligan 表示，大多數的開發者，特別是最優秀的那些人，都愛上了寫程式這件事，他們最想做的事情就是整天解程式謎題。寫程式可以說是「科技宅」的藝術創作。許多國際企業都會特地舉辦駭客松（hackathons）大賽來招募人才，包括 Facebook 、 Yahoo! 、 Microsoft 、 Evernote 這些國際企業都在台灣舉辦過駭客松活動，可見程式馬拉松的確可以找到最頂尖開發人才。 如何有效和開發者面談？誠實說明你需求的人需具備什麼條件，但不要把談話變成條件交換 。清楚解釋你的想法的基本概念，並詢問他們從科技的角度切入是如何看待。 一旦他們在頭腦中建構出你的想法，他們將會更希望把想法實踐出來。

 一旦開發者在頭腦中建構出你的想法，他們將會更希望把想法實踐出來。  來源：Inception（2010）, IMDB

值得注意的小重點是，不要假定工程師的上一份工作就是其所有的技能，這是有些工程師深惡痛絕的事情。擁有16年經驗的軟體工程師 Matt Youell 說道，16年培養了我一系列的技巧，包括程式設計相關以及非相關的技能，我曾經幫軍方寫過程式、領導團隊、管理團隊。別單單根據我上一份工作或運用的科技，稱呼我為「 Rails 開發者」或 「.Net 工程師」。我喜歡解決軟體的問題，甚至硬體的問題。有時候我會在辦公室和人交談激發創意，請把我看作「人」，而非一個只會技術的人員 。

薪水要有誠意

招募夥伴時，很重要的是清楚說明公司的職位以及你所能提供的薪水。如果你擁有明顯的「成功優勢」請多加展現，例如風險投資資金、相關產業連結以及產品原型（prototype） —你很有可能就用個位數百分比的股權（註：這是你雇用第一個高科技職位的薪水數字）吸引到天賦異稟的開發者為你工作。假設你什麼都沒有，只有一個很棒的點子和燦爛的笑容，那在尋找的是一位創業夥伴，這也是一項很好的主意之一。此外，有誠意的薪資和絕對可以幫助你找到對的人（不要低於開發者的平均薪資）。但還是回到前述的重點：  熱愛程式設計的工程師更在意的是，他們實際上會作的工作，更甚於薪水。

執行面

刊登和撰寫徵才訊息

除了在各大人力銀行網站徵才，國內的話還可到 Inside Job Board 免費張貼徵才訊息。徵才訊息的撰寫也有一些技巧，和該避免的錯誤。 Matt Youell 以受雇者的經歷提供兩項建議： 1. 避免「技能過細」的敘述：

例如「徵求： Node.js V8 韓語終端優化工程師」

有時你需要一個非常具體的技能來解決「現況」的嚴重問題，這很常見也很自然，但不正常的是，各種職位總是在要求如此遽細靡遺的技巧。但有一天你公司需要的技術改變了呢？求職者會心想：我是不是當公司技術變革的時候我就會被解雇呢？如果其他專業人員被解雇了的話，我可以投入幫忙嗎？還是我只要管好我自己的事情就好？你應該雇用的是一個人，而非勞動的單位。過細的專業化分工會有反效果。 2. 避免「過於模糊」的敘述：

例如「徵求：Ruby on Rails 工程師」

這並不是一項工作描述也不是一個有效的職缺名稱。對實際工作的描述是零。求職者並不知道你想要解決的是哪種問題？是有許多程式專案同時進行嗎？還是只是對特定科技的修補？我過去的其他科技的經驗是否幫得上忙？若有雲端程式設計的背景是否有用處？需要對於數學和電腦科學領域有興趣嗎？ 我的工作內容是全天候將 Photoshop 檔案放上網站，還是這是份真正的程式設計工作？一開始過於模糊的職缺描述，讓有經驗的工程師滿頭疑惑，卻沒有動力去尋求答案。 不幸的是，不太可能單單從一份履歷就能分辨得出好的開發者。 Torch Lab 執行長 Kevin Galligan 表示：我曾經面試過擁有在大名牌公司中10年開發經驗的人，實際上擁有的知識卻寥寥無幾，讓我十分驚訝。即使是擁有人力資源部門的 Mutual Mobile （總員工325人， iOS 開發者60人），在招募 iOS 開發者時也遇到了困難，花光了所有資源；他們的 iOS 主任 Ron Lisle 表示：我們一開始使用電話審查，我們也發現許多人完全沒有程式設計的經驗，單單回答標準問題就蒙騙過關。

找到有經驗的開發者來幫你審查

程式撰寫是一項不要求執照以及同儕審查（peer review）的專業，這就是為什麼你需要有人來幫助你審核你的應徵者。這是必需的步驟，因為即使你作盡職調查，你仍然不可能知道你不熟悉的領域的一切。您可以選擇先至人力銀行網站，應徵一位經驗豐富的工程師作為「技術招募人員（Technical Recruiter）」，評估您需要哪些技能組合，意即需要求職者具有哪些技能，有什麼技術是能外包，而什麼需要自己做。 如果您願意花費更多時間，傳統的面對面人際網絡也是流傳悠久的招募方法。詢問具有科技專業的朋友願意幫你評估或是推薦人選。如果你的腦海中沒有浮現任何人，到本地的開發者社群去結識他們，或者加入共用工作空間、參加開發者聚會──你將能觀察出哪一位開發者最適合提供技術諮詢以及專業審查。

Codility 程式測驗網站。

程式測驗

由於程式技能較難辨識，請應徵者「實作」是必要的。面談前的程式測驗已經被企業廣為使用，若你有雇用技術招募人員或開發者的朋友，你可以請他們針對您的產品設計一系列的程式測驗，將破碎的程式碼、bug 放入程式，請求職者修復程式運行的問題，例如前述所提及的新創行動應用公司。若沒有專屬的程式測驗，也可利用現成的程式測驗產品（例如： Codility ） 作為審查工具。若要避免應徵者實際上對程式設計經驗不足，只是從網路上找到解答，現場程式測驗也是不錯的選擇，也提供優秀開發者表現的舞台。

面談的其他細節

除了清楚說明您的想法、需求、具體的工作內容，以及能夠提供的資源和福利，以下是您可在面對面交談時展現的態度。 1.  熱情：展現對每個專案都有同樣的熱情很重要，這樣可以顯示您正朝著創業成功的道路前進，嚴禁只是隨意找個人來填補職缺的態度。 2. 有趣：提供開發者有趣的願景，未來的工作將是解決有趣、有挑戰性的問題，或幫有名的人物解決問題。 3. 尊重：尊重程式設計師、開發者的專業，並展現您對開發者社群的了解，並建立真正的人際網絡，展現您招募一個高素質團隊的決心。 資料來源： 1. How to Recruit a Good Developer When You Don't Code 2. How to Recruit Superstar Developers (even if you are non-technical) 3. Want To Recruit Better Developers? Give Them Broken Code 4. The art of recruiting a software developer

圖片來源：Hartwig HKD

本文編譯自 Medium的〈The Future of Digital Products is in Storytelling〉 由專業設計師交流社區 hunie.co 的創始人 Damian Madray 所撰，他同時也是熱門資訊圖像化服務 Visual.ly 的產品設計負責人。

我是一名產品設計師。人們通常認為我們設計的產品都是有形的，例如蘋果賣電腦，電腦是他們的產品；又例如 Facebook 是一款將人與人聯繫起來的社群工具。但蘋果和 Facebook 都不是單單以這種方式在賣產品，它們賣的是「故事」。矽谷明星創投 Andreessen Horowitz 認為每個公司都需要自己的故事，而產品也同樣如此。我們不能將產品設計僅侷限於介面設計，好的介面設計已經比比皆是，不再是產品的制勝法寶。產品設計需要全新的思路，也就是──講故事。

這麼說來，其實我不是一名產品設計師，而更像是一個說書人——我必須要會講故事來讓我與眾不同，因為消費者希望我們賣給他的不僅僅是一款電子產品。講故事的重要性是我接下來要聊的，而在此之前，我想引用 Ryan Glasgow 在 Every Startup Needs a Story 文中的一段話來概括我的觀點：

...... 一種從投資人、員工到朋友、家人都能理解和接納的東西，一種難忘的、易於傳遞的、連科技白痴都能接受的東西。

我們來看雲端租房服務 AirBnB 和專業攝影社群網站 500px 這兩款產品。 AirBnB 沒有把自己簡單地定義為用戶之間提供住宿的工具，而是將這種服務看成一種體驗，一段可能會深深影響你一輩子的故事。它講述的故事的重點是：你不是為陌生人，而是為一個朋友提供住宿；你的小旅館不是在招待一名遊客，而是安置一位自遠方來的朋友。正是這樣一個迷人的故事讓 AirBnB 的服務覆蓋了 192 個國家，刊登超過 30 萬條短租房間資訊。 在 AirBnB 的介面設計中， 添加了「旅遊指南」等功能，允許你為你的潛在顧客建立一份城市遊覽指南。這就像是一位老友來拜訪我，我會告訴他：「嘿，XX 是喝飲料的好地方，而 XX 一帶最適合閒逛，週四你一定要去 XX，那裡有場很棒的演出！超讚的。」 在我看來，AirBnB 設計的不單純是產品，而是供用戶講述和分享故事。相似的產品還包括 Instagram、Lyft 和 American Girl 。 500px 很棒，但我會把它當 AirBnB 的反例來講述。 打開 500px 的主頁，我想購買幾張不錯的照片。我看中了一些，很喜歡並打算購買，照片售價 200 美金。跳出來的頁面要求我的信用卡資料和其它一些信息，冷冰冰的。照片固然很美，但憑什麼值 200 美金？添購藝術品本來就不是必需，你又憑什麼說服我買下你的照片呢？ 在我看來，500px 目前僅發揮一個線上圖片交易平台的作用而已，但挾著高品質內容的優勢，它顯然可以做的更好。同 AirBnB 一樣， 500px 需要講故事——鼓勵銷售照片的攝影師分享照片背後那段有意義的故事。就拿下面這張作品來說吧：

圖片來源：Herman Damar

假設攝影師在簡單的照片訊息（如相機型號，鏡頭等）之餘，還介紹了照片背後的故事：他和這些男孩交流了嗎？他們的個性如何？他們有年紀多大呢了？ 當然有人會說，攝影師已經用一種視覺的方式來講述了照片的故事，而文字的缺失會營造一種神秘感。這...... 的確有道理，但為什麼我還是不想買呢？ 我相信攝影師們也會同意如果給照片加上背景脈絡，那照片就不再是隨機的了，而是被賦予了意義。事實上，攝影師都熱愛自己的作品，因為他們深知作品背後的故事。我的想法是，與其要求攝影師添加一小段敘述或無關痛癢的內容，還不如鼓勵他們寫一段故事（story）。需要澄清的是，這樣做的目的不是為了讓攝影師花功夫斟酌字句，為了講故事而講故事，這樣做的目的是為了錦上添花，讓照片更加人性化。 設計並不總是視覺層面的。給照片加上一段故事，就能轉變用戶的想法——照片本身的內容也會改變。你購買的將不僅僅是一張照片，而是一段你能分享的故事。而這些故事讓 500px 超越了照片交易的基本功能，變成一個會講故事的產品。 如果你不同意我的觀點，來看看這段 Coco Chanel 的影片。沒有一擲千金做廣告，而是講述產品的歷史。看完之後， Chanel 的品牌形象更加讓我難忘。 American Girl 洋娃娃也是一款很出色的產品，一個傻乎乎的洋娃娃能賣 110 美金，不是因為它的產品，而是拜它所講述的故事所賜。 我們應該嘗試超越產品的範疇來設計產品。以後當有人問我什麼才是產品設計師，我會說：為電子產品設計故事的人。

當你在 Google Books 翻翻找找的時候，可能會被突然出現的一隻手所嚇到。 既是設計師又是藝術家的 Benjamin Shaykin 幾年前就發現了存在於 Google Books 裡，如幽靈一般的手，「掃描者的手按住書頁，遮擋了內容；文字與圖片都被處理過，變得模糊不清，難以辨認；掃描的時候，翻動書頁；在掃描差不多結束的時候，將地圖以及圖表折起來。」他為此專門製作了一本《Special Collection》，收集 Google Books 上這些奇怪的書頁。 而在 The Art of Google Books 上，同樣記錄了大量掃描書頁中的人類痕跡。這個部落格的主人 Krissy Wilson 是一名佛羅里達大學的學生，原本只是 Google Books 裡發現這些「幽靈手」，於是在電腦上用一個文件夾記錄，後來她被 Tumblr 在數據管理方面的潛力所吸引，於是保存在 Tumblr 上。後來因為被 Tumblr 推薦，The Art of Google Books 被越來越多人關注。她還教你如何在 Google 裡尋找被惡搞的書頁。 隨便翻看 Wilson 的部落客，可以發現更多「痕跡」。比如說故意把書頁燒掉一部分，在書頁上畫畫，簽名，故意將某部分的句子劃掉等等。而 Shaykin 第一次看到的，是一隻皮膚黝黑的手，然後套上洋紅色的指套，按在書頁上，把他嚇了一跳。 這些手屬於誰的？紐約藝術家 Andrew Norman Wilson 曾經在 Google 工作，他注意到，出現在 Google Books 裡的「幽靈手」是 Google 雇用的數據輸入工作者們的，但這些工作者被限制行動的自由。只有下午 2：15 分的時候，這些身著黃色工作服的工作人員才會離開公司大樓，Andrew 發現，他們看上去就好像「工廠裡的工人」。 他為此拍了一個影片，說明自己的發現，叫 Workers Leaving the Googleplex。而從 2007 年開始，他籌備名為 ScanOps 的公眾展覽，裡面就選用了 Google Books 裡被扭曲、出現人手的照片。他說，「這些手指以及經過軟體畸變的圖片，是藏在 Google 隨處介入信息的技術烏托邦願景背後的『純淨信息』。它們展示一場從本體論、倫理、審美觀點來看知識的討論，和事物與意義之間不可分割的爭辯。」

Photo Credit: Abhinay Omkar

本文編譯自體育社群平台 Bluefields 的 CEO Andrew Crump 刊於 Medium 的文章「1-Man-Startups」，Bluefields 為針對體育團隊與聯盟組織設計的平台與管理工具，提供使用者更便捷的方式管理組織、相互溝聽並調整賽事，曾參與美國 500 Startups 與歐洲 Seedcamp 的育成計劃。

多數的新創團隊長期致力於找出最有效率的團隊運作模式，以期在最適當的時機產出高品質的產品，並在工作與生活間達到最適平衡。Bluefields 的 CEO Andrew Crump 同樣在團隊中嘗試過各種方法以達成上述目的，接下來將分享 Andrew Crump 認為截至目前為止，最能強而有力地對新創團隊造成影響的方法。 時間拉回今年 10 月，由於獲選為 Seedcamp 育成計劃的新創團隊之一，CEO Andrew 踏上育成計劃的美國之旅，正搭乘前往舊金山的班機與幾位朋友以及新創團隊碰面。旅程中，Andrew 在參訪 AngelList 辦公室時聽見來自 Ash Fontana 對於「1-Man-Startups」的團隊架構概念分享，以及他們如何專注於 Leverage 與 Velocity，意即找到對的支點發揮槓桿作用與提升整體效率。這對當時正計劃對團隊組織架構進行變動的 Andrew 來說如獲至寶，隨即將「1-Man-Startups」的團隊架構帶進團隊，並獲得相當顯著的成效。「1-Man-Startups」的定義如下：

「1-Man-Startups」意即每位團隊成員都能把專案當作一個新創事業來對待。當團隊成員有了產品想法，他必須獨自進行設計、寫程式、行銷市場、支援顧客並回收來自企業內部與外部的意見回饋，最後進行新版本的開發。

Bluefields 採用「1-Man-Startups」的團隊架構之前，Andrew 認為他是團隊中唯一懷抱遠見、策略並懂得安排事情優先順序的人，「我想我有更好的知識與洞察力」他說道，於是整個團隊面對的挑戰就是確保整個團隊能準確執行 Andrew 提出的策略。

缺乏洞察的策略代表：許多微小的決定會經常被不適合的人決定。

上述的團隊架構存在的最大問題在於：無法有效管理時間，團隊必須時常校正策略執行方向以確保沒有偏離原定策略。事實上，由一人決定多數策略時，策略很有可能會缺乏更宏觀的洞察，而缺乏洞察的策略代表：許多微小的決定會常態性地被不適合的人決定，但錯誤的決定造成的後果卻會被管理階層的職權掩蓋。

過去 Bluefields 採用的團隊架構：

• 花費兩個禮拜的時間為某個專案進行衝刺。
• 團隊會向 CTO（Piers）與 CEO(Andrew) 回饋他們對產品的想法。
• CTO 與 CEO 負責制定商業模式與產品策略--當時的 CEO Andrew 還同時負責 UX 設計。
• CTO 認為產品技術規格比 UX 重要。
• 產品一旦完成，要花費近兩個禮拜的時間重複向各開發部門展示。

過去團隊架構遇到的問題：

• 每個專案衝刺的過程中都會因為一些無法預期的錯誤而進行修正。
• 儘管無法預期的錯誤不斷出現在各個專案中，但由於產品開發部門只遵從CTO 與 CEO 的指示開發產品，故當產品方向錯誤出現問題時，產品開發部門很難了解問題根源，最後問題只能交回給 CTO 與 CEO 解決。
• CTO 發現很難同時掌握產品開發與團隊規範。
• 在專案執行過程中，團隊間傳遞溝通的想法比原先預期的少。
• 儘管產品持續開發，但團隊整體運作不如預期的有效率。
• 顧客開發、行銷與產品開發這三件事與整個團隊無法有效連結。

過去 Bluefields 採用的團隊架構屬於有管理階層主導的組織架構，新創團隊最需要的是能快速成長、即時作決策並在需要時改變策略方向，然而在有管理階層主導的組織架構中，上述新創團隊的特點往往要耗費許多時間，無法及時完成。

無管理階層的「1-Man-Startups」團隊架構：

• 團隊成員為共同的企業目標專注於專案執行。
• 每個專案執行的不同階段都讓顧客開發、行銷業務與 UX 設計等各個部門共同參與。
• 任何對於專案的想法都公開在專案管理工具 Trello，鼓勵團隊成員交流分享。
• 沒有人是直接地為他人工作，成員間的工作自主負責。
• 任何成員都有變動產品設計的權利。
• 沒有 Deadlines
• 沒有制式的會議

「1-Man-Startups」團隊架構帶來的影響

• 整體團隊更有創意
• 問題更及時迅速地被專案團隊解決
• 減少浪費在冗長會議的時間
• 成員間的調度配置更加頻繁
• 整體團隊更加了解產品商業模式

上述的「1-Man-Startups」團隊架構需要專案團隊與多工的團隊成員才能有效率地團隊運作，提出此一概念的 Ash Fontana 來自 AngelList，而 AngelList 的每位成員都有過創業經驗。要準確執行此團隊架構，每個專案都需要顧客開發、業務、策略、設計與前後端的技術配合。這影響了新創團隊的成員組成，有過創業經驗、懂得寫程式又了解市場分析的成員更有助於新創團隊加速成長。

編者註：Medium 的出現，給了內容發布平台一條新的思路，可以說，它的整個運作機制，都頗具啟發性。在這篇文章裡，MG Siegler 從圖片和文字配合的角度，闡述了為何 Medium 是個很好的內容發布平台。

隨便打開一個科技部落格（甚至，任何一個部落格），你會發現它們連基本的「賣相」做的都不怎麼好，更別談會有什麼閱讀體驗了。 對此，作為讀者，我們從來的選擇都是默默忍受。為何？因為我們想看的「內容」在那裡。 在 Medium 正式推出 1.0 版本時，儘管關於它究竟解決的是什麼還有些爭議，大家對於「它已經是一款非常漂亮的產品」這一點看法倒是空前一致。作為一個書寫者，Medium 於我而言，它涵蓋了所有我在寫作時需要的工具，且整個界面一上來就是以「文字」為核心的。現在，這款產品也將文字和圖片，包裝在了一起。 這讓我想到，在我還是一個孩子的時候，一本雜誌我可以看上好幾個小時。細究原因，文字吸引我有時，圖像吸引我有時。最通常的情形是，我被這兩者的結合體所吸引。 不知何故，這種共生的關係，隨著內容被移到網頁端，已經不復存在。 當然，也有一些人​​正在嘗試著將這種關係​​帶回來，比如 Vox Media。與此同時，很多傳統的雜誌，也開始將內容灌入 iOS 和 Android 客戶端裡。但 Medium 算是我看到的，首款讓文字和圖片相得益彰的產品。 在我寫科技部落格的那幾年裡，不斷有人問我為何總喜歡在文章裡插入劇照，即便圖文關聯度很小。這樣做的原因很簡單：這些圖片會給讀者一種即刻的親暱感，這一點，他們自己可能也意識不到。 比如我寫的內容是 Google 提升了某一產品速度，拋開極度關心和一點都不感興趣的兩種極端讀者不談，搖擺不定、並不確定類似新聞是否值得關注的讀者，他們中只有一部分人會讀這樣的內容。為了拉來這批人，你必須得從某處創新——以標題吸引他們，或加張同主題相關且為他們熟知的劇照，迅速建立親暱感和連繫。 這只是其中一例，儘管有故意製造噱頭之嫌，但圖片的確能為文字加分，更具吸引力。你得承認，有時圖片比文字的力量要大上百倍。同樣，像我之前提到的雜誌閱讀經驗：當文字配上對的圖片時，其整體能量可能要放大千倍不止。 遺憾的是，現在我們最常看到的圖像都是廣告。這樣的設置，不僅不能加強閱讀體驗，更多時候都是適得其反。 一個很重要的問題是：我們所處的時代鮮有談及廣告的「美」，也沒法將廣告打造「廣告狂人」的層級。我們碰到的都是浮誇的橫幅和小方塊廣告，以及醜陋的連結。與雜誌不同，這些醜陋的廣告經常就懸停在內容的旁邊，有時候甚至會內嵌進去。 換句話說，文字和圖片在很多部落格文章中已經不存在共生關係，相反，大部分時候這兩者其實是相互敵對的。這些炫目圖片的目的是讓你停止閱讀，多看它們幾眼。這對於廣告人士而言，自然是好事兒，他們巴不得你去點擊廣告，然後從你正閱讀的文章中抽身出去，好好看看廣告。 有這種對抗存在，閱讀體驗怎麼能做的好！ 這也是為何我想為 Medium 鼓掌的原因，它將我們重新帶回那個文字和圖片彼此關聯，甚至密不​​可分的時代。我希望未來它還能提供更多的內容和工具，且不把圖片當成一個事後想起的、不得不加的角色。 為了讓我的文章更有說服力，一起來看看下面這些主頁：   混亂、圖片亂飛、廣告氾濫。鮮有圖片能為文字加分，大部分圖片都讓你的注意力從文字上挪開。 這也正是人們懷念 RSS，以及會選擇用 Pocket 和 Instapaper 的原因。 蘋果甚至覺得有必要在Safari 中內置一個閱讀器功能。想想看，這是多麼荒謬的事情——一個瀏覽器需要新增一項功能，目的是讓我們在網頁端的閱讀體驗更輕鬆一點。 最後，可以對比一下這篇文章在 TechCrunch 和 Medium 上的樣子。