(仿生智慧 Part-3 ) 利用果蠅腦來做 同音錯別字查詢更正

這是第二個實驗，試圖讓果蠅腦來幫忙做「電商網站的同音錯別字查詢」。在電商網站，使用者不見得輸入完全正確的產品查詢名稱，例如使用者想要查的是「哈利波特」但很有可能打太快，輸入法選字的等等。會輸入「哈力波忑」，所以鐵定查不到產品，但現在大多數網站都有建立不同程度的同音字錯別字查詢，這裡我們想要果蠅大腦來解決此問題：

果蠅的嗅覺

果蠅靠嗅覺才能活著。牠必須在很吵雜、很混亂的環境裡分辨氣味：這東西是我可以吃的嗎？一顆水果開始腐爛了嗎？有掠食者靠近了嗎？空氣裡混著十幾上百種種味道，牠得瞬間判斷「這是不是我要的東西」。

科學家研究牠的腦子，發現果蠅處理氣味的方式非常聰明。牠腦中有一個區域，會把「進來的氣味訊號」做一個很特別的轉換：

首先，果蠅把訊號「攤開變大」。本來只有幾十種氣味感測器，訊號進來後會被投射到大約兩千個神經細胞上（這種細胞叫做「肯氏細胞」）。等於把一個很擁擠的訊息，攤開到一個很大的空間。

第二，只留下「最有反應的少數幾個」。這兩千個細胞不會全部亮起來，腦中有一個像「總開關」的抑制機制，會強制只讓其中大約百分之五的細胞放電，其他全部安靜。

這樣做的結果很奇妙：兩個「聞起來很像」的氣味，會讓幾乎同一批腦細胞亮起來；兩個完全不同的氣味，亮起來的細胞則幾乎不重疊。

換句話說，果蠅的嗅覺天生就是一台「相似度比對機」。相似的東西，牠給的判斷就相似。

2017 年，有科學家在《科學》（Science）期刊上指出：這根本就是一套大自然演化了幾億年的「相似搜尋演算法」，而且效率驚人。

把產品字串變成嗅覺訊號

既然果蠅能把「相似的氣味」對應到「相似的腦內反應」，我能不能把「讀音相似的中文字」餵進去，讓牠幫我把「哈利波特」跟「哈力波忑」對應到同一個地方？畢竟所謂氣味，在進到果蠅腦時就是電子訊號。果蠅不認識中文，牠只聞認懂「訊號」。所以我要先把每一個商品名稱，翻譯成一種果蠅能聞的「氣味」。做法是把名字拆成「讀音的成分」：


* 先用注音把每個字的讀音拆出來，例如「特」是 ㄊㄜˋ。
* 把聲母、韻母、聲調分開處理，這樣「特（ㄊㄜˋ）」跟「忑（ㄊㄜˋ）」因為讀音一模一樣，就會產生幾乎相同 「氣味」。
* 也可以還特別加一些「台灣人常見的混音」規則：像是 ㄓ/ㄗ、ㄔ/ㄘ、ㄕ/ㄙ 因為很多人打字時這些音本來就會搞混。

除了讀音，我還加了一條「長相」的線索。有些錯別字不是同音，而是「長得像」，例如「己」跟「已」、「未」跟「末」。在加了一份公開的漢字字型資料庫（Unicode 的 Unihan），把每個字的部首、筆畫數、倉頡碼也加進「氣味」裡。這樣長得像的字，氣味也會接近。

把這些成分全部混在一起，一個商品名稱就變成了一團獨特的「氣味」。接著，就把這團氣味送進前面說的那套「果蠅嗅覺」機制：攤開變大、只留最強的百分之幾，最後得到一串稀疏的「腦內指紋」。

每一個商品，都被轉成這樣一串指紋，事先存起來。等到使用者輸入查詢（哪怕打錯字），就把查詢也轉成指紋，看看哪些重疊越多，代表越接近

商品名稱在電腦裡當然就是一串二進位編碼（文字的位元）。但這串位元本身對神經元沒有意義，不能直接餵進去，中間一定要先做一次轉換。

第一步是把名稱轉成一個「特徵向量」。我的做法是用「雜湊」（hashing）把前面說的那些讀音、字形成分，各自對應到一個固定長度的向量上，這個專案裡是一個長度 4096 的浮點數陣列。注意它不是二進位的 0 與 1，而是一串有大有小的數值（例如某個位置是 0.7、某個位置是 0.0），代表「這個名稱在各個成分上的強度」。最後這個向量會做正規化（L2 normalization），讓長短不同的名稱可以公平比較。

如何送進果蠅腦？使成爲嗅覺訊號？

接下來「怎麼送進果蠅」，有兩種不一樣的方法：

在輕量版本裡，其實沒有真的模擬神經元放電。所謂「送進蘑菇體」，實際上是一次矩陣運算：把那個 4096 維的向量，乘上一個代表「投射神經元 vs 肯氏細胞」連接關係的稀疏矩陣，直接算出每個肯氏細胞的活躍值，再取數值最高的前百分之幾當作指紋。換句話說，那串數值是以「數字」的身分直接參與計算的，沒有轉成波形、也沒有轉成脈衝。這也是它能做到毫秒級的原因，它借用的是果蠅那套運算「結構」，而不是真的果蠅頭腦，如果是真的果蠅頭腦，那我們需要模擬讓神經放電。

在真實果蠅腦版本，會模擬神經元放電的，就必須把數值翻譯成神經元之間真正的溝通語言，而那個語言不是二進位、也不是連續波形，而是「放電頻率」，也就是每個神經元每秒放電幾次（單位是赫茲）。具體做法是把特徵向量分配到果蠅真正的 685 個嗅覺輸入神經元上，把每個神經元收到的強度換算成一個放電頻率（這個專案設在每秒約 5 到 200 次之間），數值越大就放得越頻繁。而且這裡用的是「卜瓦松放電」（Poisson spiking）你只設定「平均每秒幾次」，至於每一次實際在哪個瞬間放電則是隨機的，比較接近真實神經的行為。這種「用放電頻率來承載訊息」的方式，在神經科學裡稱為「頻率編碼」（rate coding）。

用果蠅大腦，怎麼幫上萬個商品建立索引？

既然可以模擬果蠅腦聞商品味道，那就把它認真跑一遍，將三萬多個商品建一份真正的「腦內指紋」目錄。這一步就是所謂的「建立索引」，做法其實跟你想像的一樣直白：一個一個商品，讓果蠅去。具體是這樣：

第一，拿出一個商品名稱，例如「哈利波特第一集」。把它照前面說的方式轉成「氣味」拆讀音、拆字形，變成一串特徵數值。

第二，讓果蠅大腦「聞」這個氣味。把這串氣味換算成放電頻率，強力地注入那六百多個嗅覺神經元，然後讓整顆十三萬神經元的大腦跑一段模擬。訊號會從鼻子一路流進去，激發、傳遞，最後在蘑菇體那五千多個肯氏細胞上，點亮其中特定的一小群。這「一小群被點亮的細胞」，就是「哈利波特第一集」這個商品在果蠅腦裡的專屬指紋。

第三，把這個指紋登記到一張「反向索引」表裡。這張表記的不是商品對應到"它點亮了哪些細胞"，而是反過來：每一個細胞有哪些商品會點亮它。舉例來說，如果第 3、17、42……號細胞被「哈利波特第一集」點亮了，我就在第 3 號細胞的名單上加一筆「哈利波特第一集」，第 17 號、第 42 號也各加一筆。就是反向索引。

第四，換下一個商品，重複第一到第三步。三萬多個商品，就讓果蠅腦逐一"聞"、逐一登記進表裡。

跑完之後，我們就得到一份完整的「腦內指紋目錄」：三萬多個商品，每個都有牠專屬的一小群肯氏細胞；而那張反向索引表，則記錄了每一個細胞背後掛著哪些商品。整份東西存成一個檔案，之後查詢時直接載進來用，不必每次重建。

這一步很花時間，因為每個商品都得讓整顆十三萬神經元的大腦實際跑一遍模擬，三萬多個商品用我的mac pro 32G要大約要跑二十分鐘。

用果蠅大腦，怎麼找到使用者要的商品？

索引建好之後，真正查詢的那一刻其實很簡單，跟建索引用的是同一顆腦、同一套流程。假設使用者打了錯字「哈力波特」：

第一，讓果蠅去聞「哈力波特」這個字串。跟處理商品時一模一樣：轉成氣味、強力注入嗅覺神經元、讓整顆大腦跑一遍，得到「哈力波特」這串查詢的專屬指紋：也就是它點亮了哪一小群肯氏細胞。因為「力」和「利」同音，這串指紋會跟「哈利波特」當初存下來的指紋高度重疊。


第二，拿這串指紋去反向索引表裡「對指紋」。看查詢點亮了哪些細胞，就翻開那些細胞的名單，把上面掛著的商品全部撈出來，投票累加。跟查詢共用越多細胞的商品，得票越高。因為有前面那張反向索引表，我不需要拿查詢去跟三萬多個商品逐一硬碰，只要碰到「有共用細胞」的少數商品就好，所以幾毫秒就能算完。

第三，算相似度分數、排名。把得票依照「細胞的稀有度」加權、再normalize成 0 到 1 的分數，由高到低排出來。分數越高，代表這個商品的指紋跟「哈力波特」的指紋越像。

第四，用分數決定要不要回給使用者。這裡我們設定了門檻，只有相似度分數超過大約 0.4 的商品，才夠格算「可能是你要找的」。以「哈力波特」來說，正牌的「哈利波特」系列會拿到明顯高於 0.4 的分數、穩穩排在最前面；而那些只是碰巧共用一兩個細胞、其實八竿子打不著的商品，分數遠低於 0.4，就被擋掉、不會拿去煩使用者。最後呈現出來的，就是幾個高分、確實跟「哈力波特」讀音相近的正確商品。

數位果蠅腦的一些基本數字

這個數位果蠅腦的實驗是從一個真實的購物網站（墊腳石）持續爬取商品名稱，本文的測試就是用當時已經抓到的約三萬兩千個真實商品名稱跑出來的。

整個「大腦」用到大約三萬兩千個模擬的肯氏細胞（每個名稱最後會點亮其中兩百多個，形成指紋）。

要建立建立整套索引（也就是把三萬多個商品都轉成指紋）大約花二十多分。

這裡要強調一件事：這個過程完全不需要「訓練」。 它不像時下的 AI 要吃大量資料、跑好幾天。果蠅的這套機制是「結構本身就是功能」。只要把架構搭好，資料一進去，指紋就自動生成了。

三萬多個商品的索引檔案大約 15 MB，還是小到可以輕鬆塞進一台普通主機。

查一次大約 2 到 7 毫秒（在三萬多個商品裡搜尋）。正確率並沒有極端高，大概都有95%以上

============================  

技術上來說，這個實驗，其實就是相似搜尋 / 局部敏感雜湊(LSH)的解決方案，其實 早在1990 年代就做得出來。

但沒有參考物的時候，我們得自己摸索：要把訊號展開幾倍？只保留多少比例的『最強反應』？要不要一個全域的抑制機制？

這些架構上的抉擇，並沒有標準答案，不同語言也會有很大差別，得靠實驗逐一嘗試。而大自然這隻經過幾億年天擇的果蠅，等於把這份『架構設計圖』先調好、示範給我們看：展開約四十倍、稀疏度壓在百分之五、用一顆抑制神經元管理全部等等。等於參考了一份被演化認證過的答案，省下的是摸索架構的時間。

========
市面上 同音錯別字查詢更正 解決方案的比較

做法一：果蠅腦

優點：
- 極度輕量。整個引擎加索引可以壓在十幾 MB 以內，1000 筆商品的索引才 1.4 MB，理論上可以直接跑在手機、甚至瀏覽器裡，不需要任何伺服器。
- 快。查一次不到 1 毫秒。
- 完全免費、可離線。沒有任何 API 費用，資料不用送到外面，隱私有保障。
- 不需要訓練。搭好架構、資料丟進去就能用，改商品也只要重建索引（幾秒鐘）。
- 專門對付「同音／形近錯字」這種表層錯誤，非常對症下藥。
- 運作費用很低，以一個中型電商，一個月要600到1000台幣而已。

缺點：
- 它只懂「讀音和字形」，完全不懂「意思」。你打「魔法師的書」想找「哈利波特」，它幫不了你。
- 對「只打片段」（例如只打三四個字去搜一個長書名）比較弱。

做法二：Elasticsearch（業界最常見的搜尋引擎）優點：

- 成熟、穩定、功能齊全，全世界無數網站都在用，出問題有大量社群和文件可查。
- 除了模糊比對，還能做各種篩選、排序、分頁、統計，是一整套完整的搜尋方案。
- 擴充性強，資料量從一千筆到一億筆都能撐。

缺點：
- 對「中文同音錯別字」其實不是天生擅長。它內建的模糊比對是看「字面差幾個字元」（編輯距離），但「利」跟「力」在電腦眼中是兩個完全不同的字，字面上差距很大。要讓它懂同音，你得自己額外做注音／拼音的處理，設定相當繁瑣。
- 它是一個需要獨立架設、吃記憶體的伺服器程式，不太會為了「更正錯別字」這一件小事去養一整套 Elasticsearch，有點殺雞用牛刀。一般來說這樣的elasticsearch還會做其他事情。
- 營運成本是那台elasticsearch，無論用什麼方案，都需要2000~5000台幣。

做法三：直接呼叫大型語言模型（LLM API，例如 Gemini 類的服務)

優點：
- 最聰明、最全能。它不只懂同音錯字，還懂意思、懂上下文，甚至你打「那本魔法師小男孩的書」它都可能猜到是哈利波特。
- 幾乎不用自己開發，串個 API、寫幾句提示詞就能動。- 對各種千奇百怪的錯誤（同音、形近、語意、外文夾雜）都有很好的容忍度。
- 對於小型電商來說，成本可能反而更低，因為做查詢的人本來就不多，如果每天只有一兩次查詢，費用極端的低。

缺點：
- 如果使用者多，會發現它慢又貴。每查一次都要透過網路呼叫外部服務，通常至少要一秒以上，是果蠅腦的幾百倍到上千倍。理論上，查詢都要付費，量一大，帳單很可觀。
- 有可能有天生LLM「一本正經地亂講」的風險。雖然機率低，但是可能推薦一個根本不存在的商品。
- 很難「只回傳你商品庫裡真的有的東西」，還得額外做一層驗證。



======

以墊腳石為例，一個月要花多少錢？前面講優缺點還是有點抽象，我們乾脆用一個真實的例子把「營運成本」算出來。注意，這裡算的是「東西做好之後，每個月持續要付的錢」，不包含一開始的開發工。


先設定情境。墊腳石購物網（tcsb.com.tw）大約有十八萬個商品，假設一天約有三百筆成交。花錢的不是「購買次數」，而是「搜尋次數」。 會買的人，通常搜了好幾次、逛了好一陣子才下單；而且更多人是搜一搜、沒買就走了。以電商的經驗，搜尋量大概是成交量的幾十倍。我們保守，一個月大約六十萬次查詢。

方案一：果蠅腦

每月營運成本估計極低（600台幣）這套東西很輕，可以直接跑在你原本就有的網站主機上。一次查詢 5 毫秒，一台最普通的主機一秒就能處理好幾百次查詢，六十萬次查詢對它的運算量來說是很小的。

但要記得一個容易被忽略的成本：索引在查詢時必須放進記憶體（RAM）。 你不會希望每次查詢都去硬碟讀一次 90 MB 的檔案，那太慢了；正確做法是把它整份載入記憶體常駐。而且實際放進記憶體後，為了查得快，它會展開成一個「反向索引」的結構，比原始檔案還大，以十八萬商品來說，實測大約會吃掉 350 到 400 MB 的記憶體，加上商品名稱字串和程式本身，保守估計要為它多留大約 0.5 到 1 GB 的 RAM。1G記憶體的成本每個月大概600台幣(GCP)

方案二：Elasticsearch，每月營運成本估計約新台幣 3,000 到 15,000 元

十八萬商品對 Elasticsearch 來說是小事，但它是一個需要「一直開著」的伺服器程式，比較吃記憶體。營運成本主要是那台（或那幾台）伺服器的租金。

- 自己租雲端主機架設：一台中小型主機（足夠跑十八萬商品）一個月大約 3,000 到 8,000 元；若要考慮穩定性做兩台備援，那就要兩倍。
- 用雲端業者的「代管 Elasticsearch」服務：入門方案通常一個月落在 5,000 到 15,000 元之間
- 它是「按時間」計費（開著就在花錢），不是「按查詢次數」計費，所以查詢多寡影響不大，而且就目前預估查詢量也不太會超過

每月營運成本估計：約 3,000 到 15,000 元，取決於要不要備援與是否用代管服務。

方案三：LLM API，每月營運成本估計約新台幣 6,300 到 更多無上限 

這不見得比方案二貴，但因為它是「按查詢次數計費」的查越多、付越多，而墊腳石一個月有六十萬次查詢。

假設每一次查詢用到500token，60萬次就是300個百萬token。每一個百萬token假設是0.7美元（按20%是輸出 80%是輸入，用gemini的價格) 那們，這樣的API就要花300*0.7*30=6300台幣起跳。

這個方案有可能在極端情況下會比elasticsearch多很多。但在某些時候也可能少很多。

(仿生智慧 part-2) 用一隻果蠅的大腦，來判斷這張圖片是不是"A"

 承接上篇，

本文要分享一個小實驗：把一隻果蠅的整顆大腦「搬」進一台筆記型電腦裡，讓牠透過兩隻眼睛「看」圖片，然後訓練他回答一個很簡單的問題「這張圖裡面有沒有大寫的英文字母 A」。結果是可以的：果蠅大腦學會了，而且在簡單的測試裡，正確率高達百分之九十九以上。

果蠅大腦是誰做出來的？

我們的大腦裡有幾百億個神經元，彼此用類似電線東西連在一起，形成一張超級複雜的網路。這張「神經元的接線圖」，科學家給它一個名字，叫做「連接體」（ Connectome）。

連接體就像是把大腦裡「哪個神經元接到哪個神經元」全部畫出來的地圖。有了這張地圖，我們才有機會了解大腦是怎麼運作的。

當然人類的大腦太大了，目前科技還做不到把每一條線都畫出來。所以科學家先從小動物下手，而果蠅（學名黑腹果蠅）就是最好的目標。牠的大腦只有大約十三萬個神經元，卻已經能夠飛行、學習、記憶、求偶、打架，麻雀雖小五臟俱全。反過來說，雖然他五臟俱全，但果蠅還真的夠小，小到可以直接切片分析。

這個把整顆果蠅大腦畫出來的計畫，叫做「FlyWire」。

這裡要特別澄清一個常見的誤會，很多人以為 FlyWire 是「Google 的專案」，我一開始查資料的時候也誤以為他是google的研究計劃，但其實它主要是由美國普林斯頓大學（Princeton University）的兩個實驗室主導的，背後有全世界上百位研究人員一起參與標註。Google 的研究團隊在其中扮演了很關鍵的角色，他們提供了強大的人工智慧影像技術，幫忙把電子顯微鏡拍下來的大腦切片，自動辨識、重建成一個一個的神經元。可以說，這是一個「學術界主導、Google 出力」的合作成果，成果在 2024 年登上了頂尖期刊《自然》（Nature）。

今年六月可以讓人隨便下載。全部都是公開資料，任何人都能下載。

如何下載？

最簡單的方法，是透過一個叫做「Codex」的網站（網址是 codex.flywire.ai）。這是普林斯頓大學做的線上工具，讓一般人也能瀏覽、查詢這顆果蠅大腦。你只需要用一個 Google 帳號登入（不用錢啊！），同意使用條款，就可以在網站上直接下載資料檔案，包括：

* 每個神經元的基本資料（它是哪一類細胞、在左腦還是右腦）
* 神經元之間的連線表（誰接到誰、接了幾條線、是興奮性還是抑制性）
*視覺神經的「欄位座標」（這是果蠅眼睛的地圖，這個專案會用到）

...等等還有很多相關資料。

這些檔案大多是壓縮過的表格檔，最大的一個也2G而已，一般家用網路幾分鐘就能下載完。

另外有其他的方式：是直接使用其他研究團隊已經整理好的版本。有一組哈佛的研究人員（Shiu 等人，2024 年同樣發表在自然期刊）把整顆果蠅大腦做成了一個可以直接拿來「跑模擬」的電腦模型，並且大方地放在網路上開源分享。我們這個實驗，程式碼很大部分，就在他們的基礎上完成。

怎麼讓一個靜態的果蠅腦動起來？

下載回來的果蠅大腦，本質上只是一張「連線圖」，它告訴你哪個神經元接到哪個神經元，但它本身不會動。


要讓它「動」起來，我們需要寫一個程式，去模擬每一個神經元的行為。真實的神經元是這樣運作的：它會慢慢累積來自其他神經元的訊號，像水杯慢慢裝水一樣；當累積到一定程度（水滿了），它就會「放電」一次，發出一個電脈衝，把訊號傳給下游的神經元，然後自己歸零、重新開始。

這種一顆一顆神經元、用「放電脈衝」互相溝通的模型，專業上叫做「脈衝神經網路」（英文縮寫 SNN）。它跟一般大家聽到的 AI（例如 ChatGPT 背後的技術）不太一樣，更接近真實大腦的運作方式。

我們用一台蘋果 M4 筆電，寫程式讓這十三萬多個神經元同時運作。一張圖片只需要大約 0.15 秒，速度相當快。

那怎麼知道我們的模擬「跑得對不對」？這一步很重要。我們拿前面提到的哈佛團隊那個已經驗證過的模型當作標準答案，做同一個實驗來比對。結果我們的模擬和他們的官方模型，神經元活躍程度的相關性高達 0.99（1.0 是完全一致），幾乎一模一樣。這代表我們的「電腦版果蠅大腦」是可信的。


（小插曲：在比對的過程中，我們一度發現自己的模擬比標準答案多冒出百分之二十的訊號。追查了很久，才發現原來真實模型有一個很細微的規則：神經元在「放電後的短暫休息期」內，是完全不理會外界訊號的。我們把這個細節補上之後，兩邊的結果就核對成功了）

如何讓果蠅腦「看」圖片

果蠅又不認識英文字母，我們怎麼讓牠「看」到一張寫著 A 的圖？

果蠅的眼睛是複眼，由大約七、八百個「小眼」排成一個六角形的蜂巢狀陣列。FlyWire 的資料裡剛好就有這些小眼的座標地圖（左右眼各一份）。


於是我們把一張 28×28 像素的小圖，投影到這個蜂巢狀的「螢幕」上：圖片哪裡亮，對應位置的視覺神經元就活躍一點；哪裡暗，就安靜一點。這張圖會同時送進左右兩隻眼睛。

一開始我很自然地想把訊號直接送進最前端的感光細胞，結果整個大腦幾乎沒反應，甚至越亮的畫面反應越弱。後來才理解：真實果蠅的感光細胞和最前端的神經元，用的是「抑制性」的訊號（有光的時候反而變安靜），而且它們不是用脈衝溝通的。所以我們改成把圖片訊號送進稍微後面一點、確定會「放電」的視覺神經元，訊號這才順利地一路傳進模擬的果蠅腦裡面。

這件事本身就很有啟發性：就算你手上有一張完整的大腦地圖，如果不了解每條線運作方式也沒用！不過當然，現在這類型的錯誤，在你自己有點知識的情況下，是可以讓AI幫忙找到潛在問題。

如何教果蠅腦分辨是不是Ａ

訊號進到大腦之後，我們要在末端放兩個「判斷用」的神經元：一個代表「這是 A」，一個代表「這不是 A」。哪個放電放得比較多，就當作果蠅的答案。


一開始，這兩個神經元是隨便亂連的，答案當然也是亂猜。那牠是怎麼「學會」的？

訓練方法，大致源於真實大腦的獎勵機制，多巴胺。在神經科學裡，多巴胺就是大腦裡的那塊獎勵/懲罰。

（但技術上來說，所謂的多巴胺，在這個專案的程式裡只是調整某些地方的權重+-而已)

具體來說，每看完一張圖、果蠅給出答案之後，我們就告訴牠對還是錯，並且據此微調相關神經連線的強度：答對就強化剛剛用到的連線，答錯就削弱它。這個過程一遍一遍重複，果蠅腦就會慢慢被訓練。

這裡又有一個，網路上很多人會分享，果蠅學習與記憶的中樞叫做「蕈狀體」（Mushroom Body），我們原本理所當然地想把學習放在那裡。但實驗做下去才發現：在我們這個視覺任務裡，蕈狀體幾乎完全沒有被activate，因為連到它的視覺神經細胞太少了，根本傳不進足夠的「形狀」資訊。這其實跟生物學是吻合的：果蠅的蕈狀體主要負責「氣味」的記憶，而視覺圖形的辨識，在真實果蠅身上是由大腦別的區域負責的。順道一提，接下來的另一個實驗就會用到氣味神經。

所以我們順勢把「學習的位置」，改到了視覺訊號真正豐富的地方。也就是眼睛後方、負責把視覺送進大腦中樞的那一批「投射神經元」。

結果？

講了這麼多，結果到底如何？以下是實際跑出來的結果：


在「簡單版」的測試裡（字母置中、字型單純、只有一點雜訊）：
* 判斷 A 與非 A 的正確率高達 99.4%。 (5000張圖)
* 而且學得很快，資料只跑過一輪，正確率就已經接近滿分。
* 就算只給牠看 100 張圖來學習，正確率也有 96.7%。


在「困難版」的測試裡（六種字型、會旋轉、會縮放、位置會偏移、雜訊更多）：

*正確率約 74%。雖然沒有簡單版那麼漂亮，但仍然明顯高於亂猜的 50%。



我們也做了幾個「對照實驗」來確認結果是真的，而不是碰運氣：如果用書上那種「答對給獎勵、答錯什麼都不做」的舊方法，果蠅根本學不起來，正確率停在 60% 動不了。這證明「答錯要給懲罰」這件事很關鍵。

另外，有一個結果很直得一提：如果我們把大腦裡的連線「隨機打亂」（保持每個神經元的連線數量不變，只是亂接），在簡單版測試裡正確率居然還有 98%。這說明在簡單任務上，真正運作的是前端那套「視覺投影」的機制，果蠅大腦「神經連結線路」本身，並沒有想像中那麼關鍵。到了困難版，真實大腦的接線才稍微展現出一點優勢（會得到74% ）。老實說我後來想想也很合理，許多昆蟲的複眼直接就可以決定看到的東西是什麼，根本不用進到大腦思考。

另外，這個實驗不是造出一個會識字的果蠅，他其實只是認定這個A圖樣。換成其他簡單圖樣結果應該也差不多。

實務上我把以訓練過的果蠅腦，打包成一個python script.

讓我以可以這樣執行它#python3 fly_check_a.py --image somepicture.png

有興趣也可以與我聯繫交流一下其他玩法：）

(仿生智慧 part-1) 果蠅的頭腦 能做的事比想像中來得多

 

一隻果蠅的大概有16萬多個神經細胞，並且，這些細胞互相之間，總共有大概一億兩千百萬個神經連結。16萬細胞中，13萬大概在大腦，其他分布在身體不同地方。

順道一提。人類光是大腦就有860億個神經細胞，而且連結數量實在太多，情況因人而異，但大約在100兆到1000兆之內。跟果蠅完全是不同等級。

而google的研究中心，把果蠅頭腦所有神經連結逐一數位化，並在2025年六月，發表了成年雄性果蠅完整中央神經系統圖譜MaleCNS v1。從發表以來，各種奇奇怪怪的應用都出現了，最引人注目的就是訓練果蠅玩遊戲，訓練果蠅投資數位產品之類的，這些種種作為，其實都是為了想要得達到利用生物天生有的頭腦架構，搞出更快更省電的人工智慧。

技術上來說，暫時還不是像「攻殼機動隊」一樣可以把生物的意識放在電腦裡面，但是，他確實可能是微小的第一步。

不過初期的應用還是跟現在人工智慧的應用差不多，但利用大自然已經訓練過上百萬上億年的神經網路，會遠比人類加上現存的AI的設計要好太多。

這隻果蠅的大腦數位化之後。可以被人類操作的是"SNN" ( Spiking Neural Network 的縮寫，中文稱為脈衝神經網路/突觸脈衝神經網路）。簡單的說就是大腦的運作可以靠電腦來模擬。

每個人都可以搞出自己的模擬細胞，模擬神經連結，特別是有AI之後，就算不會寫程式也可以做出來。但是，為什麼使用「果蠅大腦天然結構」優於「自己自創 SNN」？

果蠅大腦經過億萬年演化優化，果蠅在自然界中必須在極強的雜訊環境下（如風向干擾、氣味混合、水果微腐敗變質），精準在短時間識別出「這是不是同一種水果」「我可以吃嗎」。而這樣的SNN即是人類可以自己設計，可以花很多LLM的錢去模擬，做了幾萬種，可能都不如經過自然演化篩選過的果蠅大腦。

而SSN跟現在AI(LLM)比較起來，最大的優勢就是極端節省能源，耗電量極低。 

簡而言之，我打算做幾件事情。

(1) 果蠅認字基本訓練：

先download果蠅大腦ssn，然後，撰寫訓練程式。試圖做個簡單的測試。測試內容就是先產生幾百張圖，訓練果蠅大腦神經節，如果在視覺上看到A這個字就給予神經 多巴胺 獎勵。這樣幾百張圖之後，果蠅應該就學習到了A這個字。

測試也很簡單，給一些不同角度的"A"這個字的圖，看看果蠅神經反應如何。

(2) 果蠅同音錯別字更正：

利用果蠅大腦原本有的嗅覺機制，把中文字改成拼音字之後，對比之前訓練過的「嗅覺拼音」得到是不是同音錯別字，或者是最接近的字。講得很複雜，但簡單的說，就是先把「哈利波特」變成中文拼音「ㄏㄚㄌㄧㄅㄛㄊㄜ」 在讓果蠅記得這個字，但是果蠅不認得字啊，所以把它變成一種嗅覺電位刺激，讓他知道這個嗅覺。接下來如果有人輸入「哈力波忑」一樣換成拼音，再去果蠅大腦看看這個刺激有沒有反應，有的話是哪個反應，就得到「哈利波特」這個之前聞過的嗅覺。

當然，實際上嗅覺對於腦就是一種「數位刺激」，視覺也是聽覺也是，會使用嗅覺，是因為果蠅的嗅覺架構足夠處理10萬多種不同刺激，但是視覺解析度就很低了。請看這張果蠅視覺圖，他的複眼解析度實在不高。

(3) 果蠅 最瘋狂的事：

我還在想，希望前兩篇結果做好之後，第三件事情我也想到了:)

電子書網路行銷 (寫書能賺錢嗎？ - Part-3)

工程師最不會的就是行銷，但是電子書的出版量多的不得了，除非你已經是名作家，否則，在不行銷的情況下，只有你自己跟你朋友會買你的書啊！


要怎麼行銷？

當然先來問AI，先老實的說我只有400美金的預算。然後AI給了我一點建議：

首先：

便宜的外包管道，像是Fiverr/Upworks都有很多印度巴基斯坦人，專門做各種小型網路工作。很多介於灰色地帶，例如，真人大量的幫你的fb按讚加好友，幫你的youtube瘋狂增加點閱率。說是灰色地帶是因為，他可能是用半人工，半自動化方式進行。當然行銷不是只有灰色地帶行銷，許多fiverr/Upworks上的印度人巴基斯坦人，也有很多正常合理的方式。

行銷書籍在Fiverr上大多是會說，他們會到各個blog推薦書籍，撰寫推文等等。聽起來是有道理，為了預防萬一我選了一個在美國的，但其實他是不是美國人很難說，搞不好是個印度人，利用vpn創造美國的來源也說不定。總之我付了300元，他幫忙寫了非常多blog推薦信，但是最終成效是零。

其次：

Amazon Kindle本身的廣告功能：每日最多12美金，對用沒名氣的人根本沒啥用，雖然沒花什麼錢但也等於是拿錢丟到水裡。他會告訴你投放到哪些人登入amazon的時候，給你很好的reporting，但是，對於沒有任何名氣的人，根本沒用啊！不過好處是，如果沒有click，他不算錢！算是有點良心，不是曝光就收費，所以三天後其實只收了幾美金，但是我還是取消了。

第三：

booksprout.com 書評網站。老實說就他的運營邏輯來說，可能是最有用的。

當你付訂閱費之後，你會上傳電子書，並且要求你的書的人，到書的銷售頁面評論。銷售頁面不見得是amazon也有可能是吃的，這電子書必須要是可以被免費下載的。那為什麼會有人會幫不認識的書發表書評？因為可以第一時間，合法而且免費的看電子書，其次，如果你也是電子書作家，可以有默契的互相幫忙，我幫你評論，你自然就會幫我評論。而amazon或者其他電子書網站，評論越多越容易被人購買。

因此，就這邏輯來看，應該至少有點用。但是我忽略掉一件事情，如果你要在amazon發表評論，除了購買那本書的人之外，就只有kindle unlimited 訂閱戶可以評論，我是有參加kindle unlimited。

所謂kindle unlimited指的是每個月付出11美金，就可以無限制「借閱」所有kindle unlimited電子書來看，至於哪些書有參加kindle unlimited，是由作者（或者控制書的出版商）決定。我自己的五本書統統都有參加。借閱不用錢，因為每個月的月費，其中小小一的部分，就會付給這個電子書。當然因為借閱，所以在你的kindle上，他是需要「還書」的，但沒有期限，只有一次借閱數量的限制，一次可以借閱20本，超過你就得先還一本才能借下一本。

但當我要開始幫別人給書評，amazon又出現另一個限制，就是過去12個月需要再amazon消費49美金以上，但我是上個月才加入unlimited，換言之，至少要5個月才會滿49美金以上，除非我直接買點東西，讓我的消費超過49美金。所以我就暫時不給別人書評，當然，別人也不會給我書評。

換言之，其實這個網站宣稱的「會有人因為想看免費電子書來給你書評」基本上很難發生，大多是像我一樣完全沒名氣的作者來互相取暖。但我還取暖不了啊～

當然訂閱也有分等級，最低9美金一個月的話，就是一次只能評論你的一本書，一本書還沒結束不能換下一本。當然訂閱越高，同時評論的書越多。

先說結果，這三項我都嘗試了，總投入的經費一萬二千台幣，完全失敗！一點用都沒有！

其實主要的原因還是自己，對於一個在英語書刊知名度是零的人，單單靠這些方式是不夠的。行銷必須要有整體的規劃，而不是隨便撒點錢，就預期會隨便有點成果。隨便散點錢的成果，就是沒有任何成果。

同音錯別字 在AI時代的處理方式

在2015~2022左右，電商網站，如果想要處理產品搜尋、同音字與錯別字時，Elasticsearch (ES) 是市場上最主流且最常見的解決方案。

他有很多搜尋引擎的優勢，Inverted Index與文字分析，內建完善的 Tokenizer 與 Filter 機制，能整合中文斷詞（如 IK Analyzer、Jieba），有拼音轉換插件（如 elasticsearch-analysis-pinyin），將同音字轉為拼音進行比對。

而且，模糊比對（Fuzzy Query）：原生支援編輯距離演算法，可處理英文字母錯字或輸入長度的微小差異。(中文可能要有其他方式)

然而，AI 特別是LLM的出現，讓原本Elasticsearch能做的事情，很大一部分可以被取代，或者被改善。特別是中文，有新產品的出現，讓原本的斷詞，如果不用 Character N-gram去處理的話，會有很大的問題。舉例來說，「拉布布」是2024年才開始紅的，而且坦白說，我直到今天才知道他是什麼。如果辭典檔沒有這個詞，非常可能產生斷詞錯誤。此外，同音字，多個錯誤拼音字，夾雜不小心輸入的注音符號的詞，這些雖然都可以處理，但是都要額外花時間。

然而，LLM的出現可以讓這件事情變得簡單。

因為可以要求LLM （透過API/Prompt)來直理解輸入的詞彙。即時處理最近才出現在網路的詞（Gemini API可以做web search)，繁簡轉換可同時進行。

例如，一個典型的網路電商，要處理使用者輸入搜尋「哈利波特」非常簡單。

但是要處理「哈力波ㄊㄜ」這樣混著不同錯誤情況的，在elasticsearch不是做不到，而是所需要設定，花的心力，維護的成本是相當高的。

然而透過LLM檢視重建查詢字串，卻非常簡單，只有一個API加上不到300token的prompt。以Gemini來說，一百萬次的這樣查詢重建也不到400台幣，而且對於系統架構來說非常簡單，沒有各種維護的負擔。

當然，LLM在很多時候的成本是相當高的，也不是用來取代elasticsearch，但是查詢字串重構，是個非常容易實作，效果又很不錯的做法，對於中小型電商來說，成本也很低啊～

45%大裁員的第一手紀錄

這是經歷參與公司大裁員的第一手紀錄，經過了兩年多，大部分的事情應該都不是機密，但是還是不會揭露個別人物訊息。

---------

2024年過完農曆年，馬上收到CEO的信，所有一級主管，以及各國分公司總經理，以及部分二級主管，各自安排時間，在一週後的某日，抵達新加坡總部，信中沒寫原因，只有說要重要事情要討論，也強調為了不引發額外的遐想，希望大家對自己團隊說是主管訓練即可。

當時我負責部分工程部門，職稱是VP of Engineering，也是在緊急抵達名單之內。

這個公司是個規模大概一千多人的跨國電商。主要營運的地方是東南亞，加上台灣韓國澳洲，當時一共有10個國家分公司，總部是在新加坡。各國分公司規模大小不一，小規模的分公司可能有30個人，大的可能有60人。不過功能來區分的話，軟體工程部門是最大的部門，差不多兩百多個人，只分布在台灣越南新加坡三個國家。

在這個緊急通知範圍，大概有10位一級主管，10個分公司總經理，幾位VP，加上CEO跟法務人員，差不多將近30人。

台灣往新加坡的飛機，抵達新加坡差不多要4個小時。在飛機上我稍微想了一下，覺得應該就是為了大規模資遣。

為什麼呢？以下是當時的推測：

(1) 這不可能是為了講好消息，例如公司要上市了。講好消息不需要這麼神秘，也不需要"集合"一級主管。只要視訊會議就夠了

(2) 既然是為了壞消息，什麼樣的壞消息需要把公司重要人等在總部集合而非視訊會議？

- (2.1) 公司面臨很大的困難，不得已賣給別的公司：這其實不需要大家緊急集合

- (2.2) 公司有攸關生存的重大事件，例如資安事件，需要大家努力：這不需要緊急集合，公司的確曾有幾次這樣的生存危機，但是為了節省執行時間，應該要視訊會議搞定

- (2.3) 因某個原因要大裁員：這是我想過可能唯一需要大家到現場的，因為可以確保不會走漏消息。

所以在飛機上，我打算開始模擬如何大規模解散自己的部門。

即使我的推測不對（雖然對自己的推測還蠻有信心）花一點點在飛機上的時間模擬，並不會吃虧，只是少看了飛機上的電影而已。

為什麼需要先準備，因為這種事情，如果臨時才開始想怎麼做，到時候一定是被逼著做下意識地決定，而這種潛意識的決定，可能對公司，對團隊成員，對自己都不好。

反而是有所準備，理智的做出對三方面都好的決定最好。

首先，裁員規模一定是很大的。倘若打算裁員10%，根本不需要大張旗鼓，事實上20%也不需要，因為幾乎所有科技業電商每年的"自動更新率"（個人原因自願離職）多半在5%~15%之間，如果只打算裁員20%，其實只要正常離職的人口，加上部分裁員，完全夠了。所以我的猜測是至少裁員45%，而其中自動流失的是10%，所以一級主管至少裁掉自己部門現有人口35%，為了預防萬一，在模擬的時候，自己先訂了50%的目標。

到了總部，會議要求大家不要使用手機，我覺得我猜對了。果不其然，CEO開門見山的說，我們需要大規模的裁員。

原因當然很清楚。經過疫情之後，電商生意並沒有大幅好轉，而營業成本持續增加，公司雖然開始獲利，但獲利實在太少，如果不趁現在做一次性的降低成本，以後會更困難，公司距離到上市目標會遙遙無期。

並且也公布了"想要"達到的數字，45%。

會議中，CEO嚴肅的講了幾個原則：首先這件事情無法改變。其次：各主管要在一日之內，決定離開名單，第三：名單不是以績效決定，而是以公司未來價值決定。第四：名單需要保密到下週，公司會有一個統一時間決定。第五：一定要符合各國勞基法規定。第五：回國後，在公司統一公布前，絕不能洩漏。

最後，CEO說明，這件事是他獨一決定。他這樣說，大概是希望要怪罪就怪他一個人。

那場會議有個分公司總經理，聽到這個消息大為震驚，當場落淚。也有幾位一級主管看起來十分震驚，畢竟公司前不久才好不容易宣布轉虧為盈。

當場也有部分主管詢問，裁員的原則是什麼，怎麼樣決定。但其實CEO只能給概念性的答案。

其實也很簡單，各個主管才是真正了解自己部門在做什麼的人

當時我負責的主要部門有：Infra, QA, Tech-Support, info-sec(資安)，這些部門各有自己的主管，其中infra和 QA跨了三個國家。

在飛機上我自己模擬過之後，覺得以工程部門來說，最不好的方式就是均勻的裁掉。按照公司計劃，讓A團隊少45%，B團隊也少45%...這樣看似公平，其實會造成三輸的情況。

什麼樣的三輸：

公司最後會得到的是，規模縮小，事情不變，人心惶惶的同樣結構。

每個團隊留下來的人只會變得更忙，而且如果是這種裁員方式，留下來的必定是績效相對高的。也就是更有可能找到更好工作，能更快跳槽的人。這種情況下，會造成惡性循環。

最後是自己與個別成員，無論怎麼解釋，被裁員的一定會要我好好解釋「為什麼是我走」。我很願意解釋，但不會有人聽得進去。團隊成員並不是每個人都夠成熟的知道，責任不在"劊子手"而是在"決定者"。

最好的方式應該是按照結構。

當然每個VP，每個總經理所管轄的範圍不同，不是每個部門都可以按照結構來裁員。

總之，當時很快地送給CTO/CEO我的計劃。

我的概念很簡單，首先經過了疫情，我的團隊績效都已經提高很多，所以裁員和績效無關，而我希望裁員之後組織效率提高，團隊成員的互信與合作也要提高。

在這個預設條件下。首先橫跨三個國家的QA團隊，直接裁掉整個新加坡QA，單純只是因為新加坡的QA薪水實在太高。保留台灣與越南的所有QA。

其次，橫跨三個國家的infra團隊，其中越南只有一位，所以先不考慮，而決定裁掉整個台灣的infra團隊。而裁掉台灣infra的原因也很簡單，infra團隊過去是因為人才招募不易，所以同時在台灣跟新加坡都有，經過幾年的經營，台灣infra團隊其實比新加坡人還多，但就infra的本質，其實應該在總部才對。所以趁此機會，讓infra統一在總部。

最後，完整保留資安和Tech-Support。當時所謂資安團隊，也只是兩個人而已，而tech-support是在菲律賓，因為要24小時值班所以必須要有6個人。在公司有重大改變情況下，tech-support中長期都會有更多壓力，即便少一個人對整公司反而會更糟。

最後是我自己。我把自己也放在名單裡。

在這個規模的裁員情況下，作為主管，不能直接將自己變成例外。如果每個主管都這麼作，組織很快會頭重腳輕。我自己已經在公司做了6年多，順勢跟著一起離開，不但可以減少CEO的壓力：畢竟不裁任何一級主管也不太合理，理論上應該也要裁掉45%一級主管，但是能當上一級主管表示一定對公司有價值的地方，我要是CEO還真不知道怎麼裁比較好。

更重要的是，如果我自己也是要走的一員，我在溝通告知被離開的成員時，不但心理壓力會少非常多，溝通也容易得多。

總之名單，大概10分鐘就搞定，因為在飛機上已經有草稿。

最後跟CTO討論的時候，他發現我這種的裁法，會超過45%，所以他為求安定，希望在台灣留下幾個infra成員也好。即便我有解釋，這樣留下來的人，畢竟是非常值得留下來的，同時一定也是非常容易被挖角的。但他最後的決定還是希望多留點人，反正已經達到45%就好。

回到台灣，憋了大概近10天的時間。

要等一週的原因是各國勞基法個不相同，各國總經理必須先跟法務確認過才行。

終於到了公司全員視訊會議，公布的那日(D-Day)。

會議進行的是很簡單。CEO公布要大裁員，接下來說明大概流程，然後會議結束。流程很簡單。就是HR會逐一通知，告知你就是名單的一員，然後說明給予的補償，然後今天就可以離開，然後明天就不用來了，也不需要交接。

不過最後公布其實不是45%，原因也很簡單，首先有部分人在那10天就提辭呈。事實上在一個千人大公司裡面，10%離職率的話，每週有2~3人離職是非常正常的，而由於農曆過年剛過，又是特別容易有人離職的時候。其次，財務重新計算薪資結構，裁員一個新加坡人，跟裁員一個印尼人，看似都是一個人，但財務上差快5倍。也就是説重新計算大裁員後的結果，發現部分國家不需要裁那麼多。因此最後在投影片上並不是45%。

全公司結束後，由各國HR對內自己召開個別會議，對內說明部分流程差距。這主要原因是基於各國勞基法的不同，流程會有一點點差距，補償也有一點點差距。

當然我只知道台灣的流程以及特殊的地方。首先公司給的補償，一定超過勞基法，因此HR會提出一份自願離職合約，希望當場簽名走人。以技術人員角度來說，這個補償還不少，而且除了補償之外，原本勞基法有規定的假日如果還沒放完，也是會換成現金，還不需要花心力交接。

因此，正常情況下，簽那個合約是比較好的。

問題在於，如果不簽，或者想要明後天才簽可以嗎？

這其實之前模擬過，如果不簽，就不會使用這次資遣的補償，過幾天會改用「真的勞基法資遣」那個資遣費比這個自願離職會少很多。對於員工來說，最大的差別是，真的勞基法資遣，是可以"提告"的，而自願離職，當然不可能提告公司。

而這種情況，提告唯一能做的要求就是，這個資遣無理，要求返還為工作權。只是公司不怕提高，原因在於，公司雖然在這年，勉勉強強轉虧為盈，但那只是該年度，整個公司以資本額來說，還是虧錢的，以照法律解釋，虧損的公司，當然可以資遣員工。而根據過去台灣的案例，提告要求返回工作權利，幾乎都是真正的底層員工，勞動員工，工資大多低於4萬台幣。工資高的技術性員工，判決幾乎都輸。為什麼呢？因為勞基法保障的是喪失掉工作權，會造成生存問題的情況，並且保護資訊不對等，技術不對等的情況。如果是月薪高於勞保兩倍以上（也就是八萬），要求資遣不成立，幾乎不可能，至少我在過去判決書根本搜尋不到這個例子。

簡單的說，對於高技術的員工，這次給的大規模資遣補償相當不錯。

實際上逐一面談的時候，速度是很快，因為我也只講三句話：(1)你也是這次被離職的一員 (2)這個是公司提供的自願離職合約，上面有你可以拿到的錢，請看一下，如果同意今天要簽回 (3) 我自己也已經簽了

這三句話讓幾乎所有人都立刻簽了。因為看過上面的錢，再加上不用交接，其實能夠好好休息一陣子並不糟啊。

在同一天，一次搞定所有事情，這個策略其實是對的，是個三贏策略。

(1) 對被離開的人來說，不需要痛苦交接，不需要不必要的情緒反應。

(2) 對於公司來說，不需要延宕處理問題，在同一天有任何狀況也會一次性發生

(3) 對於主管來說，一次溝通完成，減少情緒消耗以及意外。

重要的是這次的大裁員的概念和立場是對的：「不是基於個人績效裁員」

不應該對員工說：選你是因為A做的比較好，也不需要對員工解釋說：因為你上次專案做不好所以請你離開。

當裁員跟績效掛鈎的時候，所有事情都解釋不完，永遠不可能有滿意的結果。就連差強人意的被接受，都不可能。

對於還在的人呢？

說實在，工作壓力雖然會瞬間增高，但由於沒有交接，很多事情就算出問題，也應該在預測之內，只要公司能維持普通營運狀態一陣子，那些沒人做的事情，真正的重要性會浮現，浮現出來再做都還不遲。而沒有重要性的，自然也不用做下去。

如果我不是負責這樣的高技術部門，而是非技術部門，像是客服，裁員還會不會那麼順利就很難講。

沒有人會希望裁員，但是這並不是什麼嚴重的事情，只要補償金額合理，是個讓人好好休息的好機會。

懇請不要用AI幫忙寫作？

最近紐約時報的一篇社論廣為流傳。而且流傳的比想像中還廣，很快的就在中文社群網站等地方出現link。

這篇社論的重點很簡單，作者希望大家不要用AI來做文字工作，因為AI會代替你思考，而文字工作（包含寫作，寫信，寫email等等）的本質是把你的思考，用文字形式傳遞給別人，讓其他人知道你怎麼想的。一但AI取代了人的思考，就是作弊。一但常常作弊就失去了思考。而且，長此以往，大家知道你是用AI寫的，就會請AI幫忙讀。

他懇切地說明了很多。當然都有道理。

我不是想討論他講的對的，還是不對。

但他文章裡有兩段話，看得我頗有感觸，請容許我用AI翻譯成中文:) 

----以下引述原文----

普及的讀寫能力與民主崛起之間的關聯眾所皆知：歷史表明，具備自主閱讀與書寫能力的人，通常也擅長為自己做出選擇與發聲。然而，當這個過程開始倒退時，會發生什麼事？當人們失去耐心，無法吸收超過幾頁甚至幾句話的論點時？當他們因為缺乏日常練習，未能磨練出清晰思考的核心技能，從而失去了反駁這些論點的能力時？

我們已經在川普總統的社群媒體貼文，以及這些貼文對數千萬美國人產生的巨大影響力中，初嚐了這個世界的滋味。但那不過反映了十年前,在 AI 時代來臨前,這個國家的狀態。而如今，在我們閱讀、書寫與思考能力更加衰退的當下，我們又在這條路上往前走了多遠？

-------------------

他講的是很懇切，很有悲天憫人之心，在這個常常有反智現象的兩極社會裡，他不是第一個大聲疾呼的人，也不會是最後一個。雖然大體來說，綜觀人類歷史，對未來長久發展的推測還是樂觀的，但就某個時間區間，某個特定地區來說，人類也可能很慘很慘。

而個人的選擇，非常重要。因為每個個人的選擇，集合起來就變成大家的選擇（聽起來很廢話）就像工業革命之前，要出遠門，要就走路，有錢人頂多騎馬坐馬車牛車。那時候的人，基本上沒聽過，也不太會有膽固醇過高糖尿病等等。工業革命之後，生活上的方便，"整體"來說，還是增加人類的壽命。一個人可以選擇幾乎完全不運動，跑步健走爬山，不是交通工具，而是你對「健康」的選擇。

講的更殘酷一點，AI的便利性，的確會降低人的思考力，進而在很多情況下，降低某些「不做選擇」的人的智商知識力。這些人類只會聽從AI，拿取AI的便利性，而無法從中「選擇強化」自己的智商知識力，那就會跟工業革命之後，得膽固醇糖尿病的人一樣，這並不是交通工具的問題，是個人選擇的問題。

什麼樣選擇做法對自己比較好呢？你一定知道，但會不會做就很難講:)

對了，感謝善心人士。這篇懇請不要用AI寫作的社論的link是透過善心人士合法分享，所以不用訂閱登入也可以看到，順便說明一下，其實你免費登入也可以看。

讓不同 AI 互相審稿:我用 opencode 打造的寫書流水線 (寫書能賺錢嗎 Part-2)

opencode是典型的AI coding工具，無論是「幫我改 bug」「幫我補一個功能」這類日常開發工作，都是典型的用法。但如果把它看成一個能讀檔案、寫程式、也能呼叫外部工具的 AI 助手，它其實可以拿去做很多事，包括寫書。

過去幾個月，我陸續用 opencode 完成了幾本英文自我成長書籍。它參與的不只是「生成文字」，還包括整理寫作企劃、安排不同模型互相審稿、寫處理內容的小工具，以及最後把 Markdown 轉成 EPUB 上架。這篇文章不打算討論「AI 能不能取代作者」，而是想記錄一件比較實際的事：在這整個流程裡，opencode 到底負責了什麼、哪些工作交給模型比較好、哪些反而應該交給固定的程式碼(當然這個所謂固定程式碼 也是AI生成 只是固定執行而已)。


以下的例子來自完成的5本書。對我來說這5本書最大的收穫，不是產出了5本書，而是讓一套流程慢慢變成可以重複使用的工具鏈。


整體流程大概長這樣

(1) 主題發想  ... 只有這個階段是純人類完成

(2) 寫作企劃與風險檢查  

(3) 逐章產生初稿 

(4) 多模型獨立審稿 

(5) 整合修改 

(6) 封面與電子書打包。

人類(就是我)必須先想好書的主題跟概觀，模型主要負責生成和評論；程式負責批次執行、保存結果和驗證格式；opencode 則是串起兩邊的那個角色，有時候它自己動手寫文章，有時候它去寫一支工具讓模型去跑，有時候它像編輯一樣讀完一堆審稿意見後，幫我整理重點。

先審企劃，再動筆

每本書一開始我會有個粗略的概念：想談什麼主題、寫給誰看、希望讀者讀完帶走什麼。我(人類)先把這粗糙的計劃撰寫成概念文件，然後讓opencode把這些想法整理成一份詳細的寫作企劃，它不只是章節目錄，更像是這本書的規格文件，哪些概念可以在書裡反覆使用、每一章大致要走什麼結構、遇到敏感主題時哪些話不能講得太武斷，都會先寫清楚。


最省時間的做法不是急著開始寫正文，而是先讓幾個模型讀企劃書挑毛病。opencode 會把企劃分別交給不同家的模型，請它們獨立找問題。像是某個主題定位太接近醫療建議、或是兩個章節其實在講同一件事。這類問題如果等寫完三萬字才發現，修改成本會高很多。軟體工程裡常把「越早發現問題越便宜」叫做 shift left，放到寫書上，就是先審閱企劃，再寫正文。到第三、第四本書的時候，企劃審查已經變成固定的第一關，先修骨架、再寫肉，通常比寫完之後大改划算得多。

逐章生成不是聊天，是一支可以重跑的程式

企劃定案後，opencode 不會只在對話框裡一章一章地跟模型聊，而是先幫我寫一支可以重複執行的小工具。每一章的主題、故事、要教的技巧和大概的字數，都會變成那一章的寫作指令；模型產生內容後，結果就存回書稿裡。這樣做的好處是流程不依賴某一次對話，如果中途斷掉，下次可以接著沒寫完的章節繼續，也留得下每次執行的紀錄。

到後面幾本書，每一章大概都會經過四個來回：第一個模型先寫初稿；第二個模型不急著改字句，而是用幾個預先設定好的讀者視角去讀它，例如只想快速找到方法、沒耐心的年輕讀者，或是特別反感說教口吻的主管；接著再由模型把這些反應整理成具體的修改任務；最後才重寫這一章。這些讀者視角當然不能取代真人試讀，但至少比每次臨時請模型「幫我看看讀者會怎麼想」要穩定一些。

這個過程都是在opencode的commandline(命令列)完成，所以如果有軟體工程背景，在使用AI上有很大的優勢。

許多新聞都提到資工資管資科的前景因為AI而變得晦暗不明，但我倒是覺得如果你是個能善用工具的人，有軟體工程背景在AI時代反而更能發揮。


這套流程裡最特別的地方：讓不同模型互相審稿

如果只看到「用 AI 生成文字」，這件事其實沒什麼特別。這個做法中，最能運用opencode先天優勢的是，我讓opencode角色更像是「多模型審稿流程的設計者和執行者」，而不是自己一個模型從頭寫到尾。


第一，不讓同一個模型同時寫稿又替自己打分。生成模型的任務是把內容寫出來，評論模型專門負責找問題、模擬讀者反應。這不代表換一個模型審查就一定比較客觀，但至少能減少「自己寫完、自己說沒問題」的情況。


第二，同一份稿子、同一個審稿指令，我會分別交給兩三家不同的模型，讓它們獨立作答，而且刻意不讓程式自動把幾份意見合併成一份「平均意見」。（實際做法等一下會說明）實作上就是一支小工具，把同一份稿子分別送給不同家的 API，並把每家的原始回覆各自保存下來。這些腳本背後的共同原則是：先分開保存各家的意見，再由人去比較它們，而不是一開始就把答案混在一起。真正的取捨，是我自己讀完幾份報告之後，判斷哪些是大家都同意的高信心問題、哪些只是單一模型的個人偏好，再決定要不要動手改稿。模型負責提出建議，工具負責整理和保存，最後裁決永遠是我自己做的。


第三，審稿腳本原則上只產生報告，不會直接改動書稿本身。真正要改稿，會是另一個明確標示用途的步驟去執行，而且會記得它是根據哪一輪審稿結果修的。這樣至少能把「模型提出問題」跟「有人採納建議」分成兩個獨立步驟，事後比較容易回頭檢查一段文字是怎麼被改掉的。


從第三本書開始，我還把幾個固定的讀者角色寫成檔案，之後每一輪審稿都用同一批角色去讀稿子。這有點像軟體測試裡固定的測試案例。每次改完稿，都可以用同一套視角再跑一次，確保前後兩輪的反應是可以互相比較的，而不是每次都臨時生一組隨機讀者出來。當然，這些角色終究是模擬出來的，不是真人讀者，它的價值主要在於讓不同版本之間能用同一套問題來比較。

審稿也不是把同一個指令重複跑七次那麼粗暴。第一輪先看結構、內容和語氣有沒有大問題；後面幾輪則只驗證前一輪修過的地方有沒有真的修好，不再重新檢討已經處理過的風格問題。等大問題都處理完，模型也就不再反覆挑戰整本書的風格，而是集中檢查指定的範圍。不然的話，模型永遠能再挑出一點新毛病，永遠改不完。有一本書甚至還多跑了一輪，專門請模型找出可以刪減的段落，再由我決定哪些建議值得採用。

封面和電子書，反而是刻意不讓 AI 立刻執行

第一次做封面的時候，我讓圖片生成模型直接畫「有文字」的完整封面，結果書名拼錯了字。圖片模型很會畫風格、畫氛圍，卻常常把文字畫成看起來很像字但其實是亂碼的東西。後來就改成分兩步做：圖片模型，只負責生成沒有文字的背景，書名和作者名另外用程式排版疊上去，保證每一個字都是對的。

電子書組裝也是同樣的道理。書稿最後會由一支純程式的小工具轉成 EPUB 需要的網頁和目錄結構，再打包成電子書檔案，整個過程完全不呼叫任何模型。EPUB 的檔案格式有規範，但沒那麼嚴格，就像網頁一樣，有點小錯誤乍看之下不會影響，但是任何一個小地方寫錯，就有可能不會通過kindle或讀墨上架平台檢閱，這種需要「絕對正確」的工作，讓程式處理反而比較安心。這幾次做下來，不能把所有事情都塞給模型。需要發想、需要判斷語氣、需要比較不同可能性的工作，模型很好用；但遇到格式、結構這類要求精準的事，還是讓程式來比較可靠。最後一關，程式還會先檢查電子書能不能正常解壓、內部連結是否完整，再把這些檢查結果整理成一份報告交給模型，讓它負責把已經算出來的事實講成人看得懂的話，而不是要它自己去猜檔案對不對。當然，強調一下其實「程式」也是AI寫的，這個程式會一直留著，之後的AI會去執行它，有必要的時候會修正他，但他始終是一個獨立完整的小程式。

opencode中如何讓多個LLM合作

這地方值得特別說明：你打開一個 opencode session、跟它聊天，不管切到 `/models` 選了哪一家，這個 session 本身在同一時間就是被一個模型驅動。它沒辦法自己一邊用 GPT、一邊用 Claude 回你話。所以「多模型互審」這件事，並不是靠我在對話裡不斷切換 opencode 用的模型做到的，而是靠另一層做法：把每一家的API 金鑰放進 `.env`，然後直接請 opencode 讀這個檔案、寫一支小工具去呼叫不同家的 API。

實際做的時候，我對 opencode 下的指令大概會長這樣：「讀一下 `.env`，裡面有 `OPENAI_API_KEY` 跟 `CLAUDE_API_KEY`，幫我寫一段程式，先用 OpenAI 審這份稿子，抓出結構跟語氣上的問題，然後把審稿結果連同原稿一起丟給 Claude，請它照著審稿意見重寫一遍。」opencode 當下自己是哪一個模型在跑不重要，重要的是它會照著指令，去讀金鑰、組出程式、呼叫兩家完全不同的 API，把整個「A 模型審、B 模型改」的來回跑完，再把結果放回書稿裡。從我的角度看，就是坐在同一個 session 裡打字，實際發生的事卻是好幾家 LLM 輪流上場。opencode 在這裡的角色比較像是一個知道去哪裡拿鑰匙、會自己開門的助理，而不是那個真的在審稿或重寫的人。

這個做法唯一要小心的地方，是 `.env` 裡放的是好幾家廠商的真實金鑰，絕對不能跟著程式碼一起進版控。實際操作上我會先確認專案的 `.gitignore` 裡有 `.env`，再讓 opencode 去讀取、使用它。這樣不管後續請它做多少事、寫多少支腳本，金鑰都只留在本機，不會不小心被 commit 上去。

這種做法，跟龍蝦openclaw操作不同agent感覺有點像，但是在控制權上有很大的不同。有機會再來特別說明一下:)

回到「怎麼換模型」這件事本身，其實可以分兩個層次看。如果只是想換掉目前對話裡在用的模型，opencode 本身就有內建的方式：輸入 `/models` 就能挑選要用哪一家、哪一個模型；也可以在設定檔裡指定預設模型，或是替不同的 agent 分配不同的模型。例如負責規劃的 agent 用一個較快、較便宜的模型，負責寫程式或做深度分析的 agent 換成能力更強的模型。這些都是點一點設定就能做到的事，不需要另外寫程式，也是大多數人平常換模型的方式。

我並不是找到了一個很會寫文章的模型，而是我開始把寫書當成一件可以設計的事。模型可以幫忙產生內容，也可以扮演編輯、讀者或審稿人的角色；但流程怎麼拆、哪些結果要留底、哪些建議不能照單全收，終究還是要人來決定。封面文字、電子書結構這類要求精準的工作，交給傳統程式碼處理(當然傳統程式碼也是AI產生)反而更放心。從一本書到下一本書，速度變快的原因從來不是「讓 AI 自己多做一點」，而是把每一種工作交給適合的工具，並且可以根據犯過的錯修正。




AI 時代，有經驗的工程師反而更吃香


這陣子常看到新聞說，AI 讓工程師的工作變得岌岌可危，資工、資管相關科系的前景一片看衰。我自己倒是有不太一樣的體會：如果你本來就有軟體工程的底子，AI 普及之後，你能做到的事情反而變多了，不是變少。

單純打開 ChatGPT 網頁請它幫忙寫書，跟用 opencode 走一遍前面講的這整套流程，表面上都是「叫 AI 寫東西」，實際做起來完全是兩回事。在對話框裡，你每次只能一問一答，模型寫完一段，你得自己複製貼上、自己記得上一輪講到哪、自己去湊下一個 prompt；想要同時比較兩家模型的意見，就得開兩個分頁，自己把結果拼在一起看。這些事情不是做不到，只是每一步都要人親自動手，很難放大規模，也很難重複執行第二次。當然你也可以用openclaw，但他的設定繁瑣也得有工程背景的人才

而工程背景真正值錢的地方，是能把這些零散的步驟，寫成一套會自己讀檔案、自己呼叫好幾家 API、自己把結果存下來、下次還能接著跑的流程。企劃要不要重審一次、審稿意見要不要留底比對、電子書格式對不對，這些原本要靠人一步一步盯著做的事，都可以變成可以重複執行、也可以事後追查的工具。AI 本身很強，但強的模型加上散亂的操作方式，還是只能做出一次性的成果；懂得把 AI 放進一套系統裡的人，才能讓同樣的模型，一次又一次穩定地產出東西。


換句話說，這波 AI 浪潮真正淘汰的，可能不是「會寫程式的人」，而是「只會手動一步步操作、沒辦法把工作系統化的人」。對一個原本就習慣拆解問題、寫腳本、做自動化的工程師來說，AI 比較像是多了一批隨時待命、又便宜又能幹的隊友，而不是搶飯碗的對手。

這五本英文書可以在amazon Kindle找到

寫書能賺錢嗎？ - Part-1

AI發展很快，許多事情已經在改變。

現在新聞網站上，常常看到標注「本文由AI產生」，也慢慢在電視台看到AI主播。更有甚者，利用AI來讀取資訊，已經佔了網頁資訊瀏覽的1/4以上，而且有很明顯的增加趨勢。

由AI產生內容，很快就要趕上人類產生內容了！那，寫書還能賺錢嗎？或者，使用AI會寫書來賺錢，反而更容易呢？

為了想試看看AI寫書能不能賺錢，我打算來做個實驗，實驗內容很簡單：

(1) 找到暢銷書能夠撰寫的類別
(2) 用AI寫書，至少5本
(3) 取得 ISBN 上架到amazon kindle
(4) 花一點錢行銷
(5) 放段時間 看看是否有收入

首先要決定類別，但在決定之前，我打算市場專注在英文市場。其實原因也很簡單，目前電子書市場還是以美國最大，如果加上英文系國家，那沒有任何語言可以比呀，即使是中文規模也無法跟英文比，特別是電子書。

其次，哪種類別的書最多？隨便走進一家台灣的書店，擺在最前面桌子，一入口就可以看到，通常是三大類「幫你賺錢」「鼓勵你幫助你的心靈」「最近很流行」。不需要專業知識，也不太需要成功故事的，大概只有「鼓勵你幫助你的心靈」這類。這類型的書範圍非常廣，從偏向諮商的「情緒勒索」「被討厭的勇氣」到各種狀況的建議，例如「每天只工作四小時」「絕不妥協的處世藝術」等等，範圍廣，而且理論上只需要給出自己的經驗，或許就可以贏得共鳴。

寫到這裡，覺得機會不是很大。首先 "花一點錢"行銷這個是很不確實的。幾乎所有的書，都需要比想像中更多的行銷。只是由於 (1) (2) (3)目前成本實在很低。所以倒是可以嘗試看看。

雖然AI寫書成本是不高，但還是有需要的技巧，我打算找個時機再寫當初是怎麼利用AI來寫書的。以結論來說，(1)(2)(3)都已經完成。

在Amazon Author T.S.Douglas 這個作者頁上面的五本書就是這次的成果。截至目前為止，只是剛放上去而已，還沒有任何銷售量。為什麼需要一個筆名？因為研究顯示，不管哪一類型的英文書，作者最好還是有個「英語系國家名字」會比較好賣。

接下來我會分享一下怎麼花點小錢行銷，以及最後的結果。雖然預期不會太好:)

Why you don't reply to me?

 在這個無國界的時代，數位外包是很常見的，簡單的像是logo名片pdf設計，複雜的像是app製作，都可以在fiverr, upwork, freelancer這類型外包網站找的便宜的方案。當然便宜表示品質跟成果非常不可靠，但也由於很便宜（可能比AI還便宜）所以通常素質不能要求太多。

有些小事情，我都會想要找便宜的跨國外包，會試著到fiverr,upwork找看看有沒有便宜的供應商。例如幫忙blog SEO之類的。

由於市場跟語言的關係，數位外包最大規模的供應商其實是印度和巴基斯坦。這兩個國家的人口夠多，而且由於過去都是英國的殖民地，稍微有教育水準的人，普遍都會某個程度的英文，再加上物價水準低到某個程度以下，在AI時代之前，是便宜外包最常看到的來源。當然有AI之後，網頁設計等等最底層簡單一頁式網站AI完成度搞不好更高，所以便宜外包能做的事情，似乎相對越來越少了。

跟不同文化的外包商溝通，常會有各種誤解。畢竟是便宜小規模的外包，應該不可能期待對方有超強的跨文化溝通能力。

不過有時候，遇到一些情況還是會先錯愕一下，自然會有點生氣，然後覺得好笑，變得有點同情，最後變成一種個人經驗。聽起來像是錯誤溝通的五個階段:)

前幾天有個例子，我想讓便宜外包商處理英文書的行銷，其中包含review。當我貼出需求之後，自然會有很多外包商來接洽。其中有一位說明了他的方案以及價格，我覺得價格頗貴，就直接說你的這不是我所需要。我倒是沒有提他的價格太貴，他自己可能發現價格比較貴，所以自動降價之後，還問我的預算。雖說降價是不錯，但是還是覺得太貴，而且不確定他的做法有沒有問題，我就說先不用好了。結果他一連寫了數封信，每一封信都很短，我猜想其實他是用手機在工作，這個在印度巴基斯坦的外包商相當常見，他們可能只有手機，只有接到案子之後，才會去一些公共的地方使用電腦來工作。當然我就懶得回信了，因為我還在跟其他外包商溝通。過了一天，他寫了一封只有一行的信："Why you don't reply to me?" 直譯的中文應該就是「你為什麼不回我」

一開始是錯愕了一下，怎麼會有這種信。

後來有點生氣，我又沒有欠你錢，也沒有跟你簽訂合約，也沒有口頭承諾任何事情，我何必要回信。本來還想回信說「I didn' own you a reply」

但自己覺得有點好笑，因為這樣的信，他真的會預期有可能接到我的生意嗎？還是他無法預期這樣的信件，很大的機會會讓他永遠錯失某客戶。

所以我突然之間同情了起來，也許他真的很需要這筆錢，在我們的生活裡30~50美金並不是很大的數目，但是巴基斯坦人均所得每日名目[註]所得不到5美金，印度差不多7美金，台灣差不多120美金。或許他真的需要收入，心裡急了，就想趕快問問。

當然這樣同情也只是猜想，這件事情就成為自己一個經驗，或許在什麼時候會再看到也說不定。

[註]：名目所得的定義跟薪資不樣，絕大部分的國家名目所得都遠高於薪資，但名目所得是經濟學用來計算真實收入的方式。所以實際上的每日薪資會比名目所得低。

執照 認證 頭銜

Linkedin有個區域專門放 licenses & certifications 。也就是執照跟證書，也可以放獎狀頭銜之類的東西。

技術類型的工作者，工作久了，其實都有很多證書/執照/獎狀可以放在上面參考，多多少少對自己的職涯有點點幫助。

「執照」：根據各國法規應該有的工作類型執照，要從事該工作，當然一定得有。正常情況下，我們應該不可能去給一個沒有醫生執照的人看病做手術。而某些工作類型執照雖然沒有醫生執照這麼高門檻，像是職業小客車（計程車）執照，職業動力小船等等，考取不難，有執照也不見得是非常優良的司機，但沒執照去做該工作是不行的啊。

「證照」：在還沒有AI之前:) 如果是剛畢業的資工資管資科學生，擁有幾個程式設計類型的認證，對於找工作是有點幫助。特定類型的工作，例如Oracle DBA沒有認證還不行。現在有AI之後，情況還是晦暗不明，可能還需要個幾年才知道，有AI輔助的情況下，個人的能力應該如何判定。非常多年前，還是屬於剛畢業的新鮮人，有朋友邀請一起去考SCJP（java programmer)執照，當時java 1.5剛剛出來，所以新版本1.5 SCJP考試特價49美金，當年原價應該都是200鎂，所以有特價對剛畢業的學生有莫大的吸引力。可惜現在SCJP應該也不很值錢。十幾年前剛開始流行Scrum的時候，Scrum認證也非常熱門，但花大錢考scrum認證更沒用，費用不高的話倒是可以考慮。

如果要去外商工作，有金色toeic證書(860+)也可以讓HR容易篩選出"這個人英文可能還不錯"。正常情況下，面試的時候還是會簡單再測試一下，免得你的英文能力是只會應對toeic考試。如果是機師空服員，某些外商儲備幹部，某些大公司國際採購，toeic是必要的最低門檻。

「獎狀頭銜」：絕大部分的情況，都是自己開心用的。當然有少數的獎在特定領域有極端的價值，例如你要是某運動的奧運金牌，當然對你在運動類型發展一定有用。

這個月，拿到了最近十幾年來最令人開心的，但也是最沒用的頭銜證書： 西洋棋競技場候選大師(ACM)，今年二月決定要進行的事情，當真的達成的時候，很開心啊，很久沒有這種經過努力，不是為了錢，也不是為了生活工作，而得到小確幸的感覺。 好像很多人在玩網路遊戲電動的時候，也能夠感受到這種幸福小確幸感受，當破關或者達到某種遊戲設定的成就的時候，會覺得腦中充滿幸福感。這種感覺可能因人而異，不知道為什麼網路遊戲電動在很久以前我就沒辦法從中感受到那種快樂感，當然，還是會很開心，覺得很有趣，但沒有某些人心裡能感受的那麼有趣。

雖然對於真正西洋棋高手來說，這個頭銜的含金量很低，大概是會下棋，願意學習，願意連續半年平均每天參加1.5場線上錦標賽，而且願意到FIDE(國際西洋棋協會)註冊通過KYC認證。大概就會拿得到的頭銜認證。但對一個中年才開始學西洋棋的我來說，還是有很大的情緒價值。這個ACM: Arena Candidate Master的中文確切翻譯應該是競技場候選大師，聽起來很饒舌。是屬於給初學者，但又想要繼續投入西洋棋的業餘愛好者，一種階段性的鼓勵。

從某個角度來說，西洋棋的「行銷設計」先天上比象棋圍棋好很多。

象棋/圍棋基本上業餘人士都是以級位段位來區分等級。例如一開始可能是16級後來隨著參加比賽，可以一路升級到1級。級位是數字越小越厲害，然後可以進行段位比賽，升級到初段，段位則是數字越大越厲害。所以，對於象棋圍棋業餘愛好者，有個人可能是3級，有個人可能是2段，這兩個人要是都沒有拿過比賽冠軍，他們都是沒有「頭銜」的業餘愛好者。那個3級/2段，就跟寶可夢的收集到寶貝數字意義差不多。直觀感受上，沒有比"候選大師" "國際大師" "特級大師"來的有情緒價值感。

西洋棋的棋力有更細緻的分數，通稱ELO分數，要取得分數要再正式的比賽至少比三場以上，而且其中一場必須要是「贏」或者「平手」，就會開始有分數。Elo分數（等級分）是用來衡量棋手實力高低的數字標準。贏了高分對手會增加很多分數，輸給低分對手則會扣很多分。初學者大多是在1000分以下，大師等級的人都在2200以上。 所以如果你是1230分 對上一個1800分，你大概心裡會清楚遇到某某高手，目前差距多少，如果贏了會讓你加很多分。但如果是象棋/圍棋，除了大行公開賽之外，同位階的人是在會一起比的，所以幾乎不會3段對上4級這種情況。而普通人又不可能也沒那個時間去參加大型公開賽，所以很難有機會再比賽上遇到等級稍高的人，讓自己體驗一下。

通常ELO到達某個分數之後，維持足夠數量的比賽都在某分數以上，就會拿到"頭銜"，這個頭銜是終身頭銜，也就是說之後年老力衰，elo下降了，頭銜仍然在。這和象棋圍棋不同，要有頭銜，就必須要拿到某比賽冠軍，對於沒很多時間的業餘人士難度太高，實在不利於推廣。

當然為了避免頭銜多到沒意義，頭銜本身也需要一定程度的努力，但不用到特別努力。這樣的拿捏程度我覺得西洋棋做得很不錯呀。

順道一提， ELO不是一個縮寫，是個人名。匈牙利裔美國物理學教授 阿帕德·埃洛（Arpad Elo）利用統計分配來改善當時(1950年代)的計分系統。這種計分系統，可以用在各種大型的比賽活動，例如目前業餘桌球也是使用這種系統，如果你是業餘桌球愛好者，參加台灣各種比賽，只要打過5場應該至少都有一些積分。

EPUB 電子書格式

EPUB是目前最廣泛使用的電子書格式，即便是有自己格式的kindle目前也支援epub。而且說實在，epub嚴格上來說，是個非常簡單的檔案組合格式，他基本上就是zip檔，再加上各種符合xhtml的文字檔案，再加上固定的目錄，全部zip變成一個檔案。實務上來說他甚至比大家更常用的.doc (word檔案）簡單很多很多。

如果你有mac要手搓epub檔案，相當簡單，就是用純文字編輯器，加上固定的目錄，加上zip指令，把所有相關的東西全部zip打包在一起就好了。

所有相關規範都是透明的，可以參考https://www.w3.org/publishing/epub3/ （或者叫你的AI agent去讀這個規範做出電子書:)

假設你要做一本電子書內容如下：

* 書名 "This is my first epub"
* 內容："Hello world, this is my first epub book. It is very easy to build."
* 有一個封面圖片、有個簡單的導覽目錄（Table of Contents）

第一步是要先準備好檔案目錄結構，最簡單的目錄結構如下圖：

具體的說 你先建立目錄my-first-epub 然後在這個目錄下面建立 兩個目錄：META-INF 以及 EPUB（這下面還有其他目錄），然後還有一個純文字檔案mimetype。

可以直接參考這些建立目錄的指令

mkdir -p ~/my-first-epub/META-INF
mkdir -p ~/my-first-epub/EPUB/css
mkdir -p ~/my-first-epub/EPUB/images
mkdir -p ~/my-first-epub/EPUB/text

第二步: mimetype檔案。

mimetype檔案是用來告知電子書閱讀器該如何處理此檔案。
關鍵在於，內容必須嚴格為 `application/epub+zip`，不可有任何結尾換行符號或空格，且zip打包成 zip 時絕對不能壓縮。
在shell裡面執行這個指令 確保沒有換行符號跟其他內容

echo -n "application/epub+zip" > mimetype

第三步:建立 `META-INF/container.xml`

使用文字編輯器或終端機指令建立 `META-INF/container.xml`：

<?xml version="1.0" encoding="UTF-8"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
  <rootfiles>
    <rootfile full-path="EPUB/package.opf" media-type="application/oebps-package+xml"/>
   </rootfiles>
</container>


第四步:建立 CSS 樣式表 (`EPUB/css/style.css`)

建立 CSS 檔案來設定標題、內文與封面圖片的樣式： 用文字編輯器 編輯EPUB/css/style.css 內容如下：(如果你對html有了解 哪這個跟html/css是一樣的）

body {
font-family: serif;
margin: 5%;
line-height: 1.6;
color: #222222;
}


h1 {
text-align: center;
color: #111111;
margin-top: 2em;
margin-bottom: 1em;
}

p {
text-indent: 1.5em;
margin-bottom: 1em;
}

.cover-container {
text-align: center;
margin-top: 10%;
}

.cover-image {
max-width: 100%;
height: auto;
}

第五步:新增封面圖片 (`EPUB/images/cover.jpg`)

這步驟就是你隨便(AI)產生一個cover.jpg 放在這個目錄固定地方即可

第六步:建立內容頁面 (XHTML)

所有實際書籍內容檔案，基本上就是 XHTML5 格式

 (1) 用文字編輯器編輯 EPUB/text/cover.xhtml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
     <meta charset="UTF-8"/>  
      <title>Cover</title>
      <link rel="stylesheet" type="text/css" href="../css/style.css"/>
  </head>
  <body>
    <div class="cover-container">
      <img class="cover-image" src="../images/cover.jpg" alt="Book Cover"/>
    </div>
  </body>
</html>

(2) 用文字編輯器編輯 EPUB/text/ch01.xhtml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8"/>
<title>This is my first epub</title>
<link rel="stylesheet" type="text/css" href="../css/style.css"/>
</head>
<body>

<h1>This is my first epub</h1>

<p>Hello world, this is my first epub book. It is very easy to build.</p>
</body>
</html>

其實到這裡你應該也非常容易理解，這些根本就都是網頁/html啊

第七步:建立導覽文件 (`EPUB/nav.xhtml`)

這是和普通網站略有不同的地方epub規定要有導覽文件 這個檔案是必要的 大部分的時候這檔案會涵蓋所有的章節目錄

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8"/>
<title>Table of Contents</title>
<link rel="stylesheet" type="text/css" href="css/style.css"/>
</head>
<body>
<nav epub:type="toc" id="toc">
<h1>Table of Contents</h1>
<ol>
<li><a href="text/cover.xhtml">Cover</a></li>
<li><a href="text/ch01.xhtml">This is my first epub</a></li>
</ol>
</nav>
</body>
</html>

第八步:建立封裝文件 (`EPUB/package.opf`) 這個檔案是用來指定如何封裝所有東西 更重要的是他可以指定閱讀順序！閱讀順序跟檔案內容順序是可以不一樣的

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" unique-identifier="pub-id">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier id="pub-id">urn:uuid:12345678-1234-5678-1234-567812345678</dc:identifier>
<dc:title>This is my first epub</dc:title>
<dc:language>en</dc:language>

<meta property="dcterms:modified">2026-07-27T00:00:00Z</meta>
</metadata>
<manifest>
<item id="nav" href="nav.xhtml" media-type="application/xhtml+xml" properties="nav"/>
<item id="cover-image" href="images/cover.jpg" media-type="image/jpeg" properties="cover-image"/>
<item id="cover-page" href="text/cover.xhtml" media-type="application/xhtml+xml"/>
<item id="ch01" href="text/ch01.xhtml" media-type="application/xhtml+xml"/>
<item id="style" href="css/style.css" media-type="text/css"/>
</manifest>
<spine>
<itemref idref="cover-page"/>
<itemref idref="ch01"/>
</spine>
</package>

第九步: 使用zip工具打包成 `.epub` 這裡的zip範例是用mac的zip 

根據 EPUB 官方規範：
1. `mimetype` 必須是 ZIP 壓縮包中的第一個檔案，且必須不加壓縮（`-0`）且不含額外屬性（`-X`）。
2. 其餘所有檔案則透過遞迴方式壓縮加入。

請在終端機中，於 `~/my-first-epub` 目錄下執行：

1. 以不壓縮方式新增 mimetype 檔案
#zip -X0 my_first_book.epub mimetype

2. 以壓縮方式新增 META-INF 與 EPUB 資料夾
#zip -rDX9 my_first_book.epub META-INF EPUB

現在年輕人比較辛苦？

每隔一段時間，總是會有各種文章，用各種數據，告訴大家「現在年輕人比較辛苦啊，房價很貴生活困難」

這些數據不能說不對，但是綜觀人類發展，從整體的角度來看，一定是「現在年輕人比以前年輕人日子過得好」。當然如果只挑一個特定的角度，例如房價/薪資收入，當然會覺得現在年輕人比以前辛苦，要工作更多年，才能買個更小的房子。

如果只挑一個片面角度，自然會很容易產生極端結果。例如，選西元1980跟西元1680這兩個時代在台灣的年輕人，他們的房地價所得比，1680年是低的很，基本上只要願意唐山過台灣的人，要設法取得數甲耕地根本等於不用錢啊（當然要承擔其他風險，像是渡海等等）

如果真的認真比對的話，必須要比的是「生活」的本身。那古代的生活之慘，是根本不用比的，你能想像活在沒有抽水馬桶的年代嗎？當然我們不用比較那麼遠，只要比較最近的三個世代就好：2026, 2006, 1986 每個時代差距20年，比較一下哪個世代的年輕人「生活整體」比較好？

既然要比較，就要科學性質比較，什麼叫做生活品質？根據國際衛生組織的定義是:「個人在其所生活的文化和價值體系中，對照其目標、期望、標準和所關心之事，對自身生命地位的主觀認知。」

而對比到的實際數字，就包含實質所得，房價比率，旅行容易度，資訊取得成本等等。

其中，旅行容易度跟資訊取得成本，看似跟"生活品質"沒啥關係，但實際上非常重要，因為可以越低成本的取得資訊，越低成本旅行，就越能拿到機會。而當你的機會越多，生活品質就會自然地提高！

簡單的說，房價確實問題，經濟確實困難，但是如果跟前兩個世代比較！這困難跟生活幸福程度哪個重要就因人而異。但無論如何，資訊越發達 選項越多！

衡量象限	1986 年（民國75年）	2006 年（民國95年）	2026 年（民國115年）
1. 年輕人實質所得 (25-35歲單人月/年所得中位數)	月薪約 1.2 萬 至 1.8 萬元 ・青年年所得約 18 萬至 22 萬元。 ・當時起薪低，但經濟成長率高達 11%，調薪幅度極快。	月薪約 3.1 萬 至 3.5 萬元 ・青年年所得約 40 萬元。 ・面臨全球化與科技業分流，實質薪資開始陷入停滯。	月薪約 4.3 萬 至 5.2 萬元 ・30歲以下年所得中位數約 55.9 萬元；30~34歲約 72.7 萬元。 ・基本工資已調升至 29,500 元，但通膨使購買力受壓縮。
2. 所得房價比 (以台北市/全台平均為準)	台北市：約 3 至 5 倍 ・台北市平均房價每坪僅 7.18 萬元。	台北市：約 8 至 9 倍 ・全台平均：4.97 倍。 ・	台北市：約 14.6 至 15.4 倍 ・全台平均：約 9.8 倍。
3. 旅行容易度 (免簽國數量 / 出國成本)	免簽國：近乎 0 國 ・當時出境仍有嚴格管制（1979 年剛開放觀光，至 1989 年才免除出境許可審查）。 ・機票極度昂貴 年輕人 出國人次 大約12萬人	免簽國：約 50 多國 ・出國觀光全面普及，廉價航空（LCC）開始萌芽。 ・亞洲線機票約 8,000~12,000 元，相當於年輕人 1/3 的月薪，出國旅遊成每年常態。 年輕人出國人次：大約175萬	免簽國：140 國以上 ・護照極為好用，各國通關程序數位化。 ・雖然疫情後機票價格大幅上漲，但透過廉航、自助旅行，去日韓旅遊僅需花費約 1/3 至 1/2 的月薪，旅行容易度達歷史新高。年輕人出國人次：大約360萬以上
4. 資訊取得程度 (獲取知識與外部資訊門檻)	低 ・網路尚未誕生，獲取海外資訊需依賴實體進口報章雜誌。 ・解嚴前夕，仍略有限制及圖書審查制度，資訊獲取極為被動、昂貴且受限。但已經比1960年代放寬很多	中高（PC 互聯網與搜尋時代） ・ADSL 寬頻與學術網路（BBS / PTT）普及。 ・年輕人習慣用 Yahoo、Google、維基百科查詢世界資訊，獲取成本相當低（僅需負擔月租費），但受限於電腦桌前。	無限（行動網路與 AI 時代） ・智慧型手機與 5G 普及率接近 100%。 ・除了各類社群平台（IG、Threads）即時串聯全球，2026 年生成式 AI（如 ChatGPT、Gemini）已成為年輕人的日常標配，資訊取得成本極低，資訊呈現爆炸狀態。

如果比較工作環境的話，永遠都是越後面的世代越好，不可能是以前比較好！

比較項目	1986 年（解嚴前夕）	2006 年（週休二日成熟期）	2026 年（多元彈性與 AI 時代）
工時制度	隔週週休一日（或無週休） ・每週法定工時 48 小時。 ・週六必須上半天班（半天課）。	隔週週休二日 ・每週法定工時 84 小時（雙週）。 ・多數外商與科技業已自行實施每週「週休二日」。	一例一休 / 週休二日 ・每週法定工時 40 小時。 ・法律強制規範例假與休息日。
典型工作時間	實質長工時、高加班 ・每天 8-10 小時，週六半天。 ・年輕人普遍「以廠為家」，加班是常態，勞基法剛起步（1984年實施）保障極低。	「責任制」與過勞時代 ・每天 9-12 小時。 ・科技業與辦公室白領盛行「責任制」（無加班費），年輕人面臨嚴重的「爆肝」與過勞死社會議題。	混合辦公與彈性工時 ・每天 8 小時（部分外商或科技業實施彈性上下班、每週數天遠端辦公）。 ・年輕人極度重視「工作與生活平衡」（WLB），排斥無薪加班。
主流工作型態	大部分的人是在 傳統製造業與實體辦公 ・製造業、成衣加工、傳統外貿。 ・工作高度依賴「打卡鐘」與「實體在場」，沒有任何遠端工作的可能。	辦公室白領、科技新貴、派遣興起 ・竹科半導體、金融業、網路泡沫後的電商與 IT 產業。 ・非典型勞動（合約工、派遣）比例開始大幅上升。	斜槓、零工、遠端、AI 協作 ・自由職業、網紅/自媒體、外送平台（UberEats/Foodpanda）等平台經濟盛行。 ・IT/AI 工具普及，年輕人普遍使用 IT/AI 縮短庶務時間，重視自主掌控權。

退職代行

日本有獨特的職場文化，而獨特的職場文化會產生獨特產業。退職代行就是其中之一。退職代行是指勞工因面臨巨大心理壓力、職場霸凌或雇主"可能"惡意留人，自己覺得無法親自向公司提出辭職時，付費委託第三方機構代為向雇主傳達辭職意願，並處理後續離職手續的服務。

日本的退職代行年處理件數已達十幾萬件，預估接近20萬件，主要集中在 20 至 29 歲的年輕世代（佔利用人數約 5 至 6 成），並以銷售零售、餐飲、護理及業務等高流動率、高人際壓力的行業最為普及。

代行公司還有分三種。

第一種是，私人企業（民間代辦公司）。理論上，僅能扮演「傳話筒」，無權與雇主進行任何權益協商。費用相對低，約 18,500 ~ 30,000 日圓。費用最便宜，市場競爭激烈，常有 24 小時 LINE 線上諮詢。適合完全沒有勞資糾紛、只想單純傳達「我要離職」並遞交辭呈的人。缺點也很明顯，他可能完全沒有交涉權，但大部分的私人企業會根據個案情況決定要不要律師參與，所以有可能變成第三種。照理說，依法不能替員工爭取有薪假（特休）折現、不能協商離職日期。若代辦人員越分際與公司談判，會觸犯日本《律師法》第 72 條的「非非弁活動（非法執業）」，可能導致離職程序無效。雖是如此，為什麼民間代辦還是很多？因為絕大部分的公司，也都不想過於糾纏這種情況，被通知說員工離職，很大的機率只會在嘴上抱怨抱怨，最後該讓人家走還是會依法完成手續。特別是工作內容是屬於銷售零售餐飲類別，這種嚴格上來說，根本沒什麼東西要交接，也不可能是簽署旋轉門條款，擁有公司特定的營業秘密之類的高級僱員，因此，其實只要有人幫忙講話，很多時候就夠了。

第二種是，聯名工會（合約工會）由代辦公司與外部工會合作，或由工會直接營運。利用日本法律賦予工會的「團體交涉權」來執行代辦。費用相對多一些，約 25,000 ~ 35,000 日圓。優點是費用稍微貴一點，但是合法擁有交涉權。可以代表員工與公司協商有薪假消化、調整離職日、發放退職金等細節。若雇主拒絕與工會協商，在法律上可能構成「不當勞動行為」。缺點是無法處理真正的法律訴訟。若公司因員工離職而威脅提告「損害賠償」，工會無權在法庭上擔任訴訟代理人。

第三種就是律師事務所（司法代理）由合格執業律師親自受理的正規法律諮詢與代理服務。費用是最貴的約 50,000 ~ 100,000 日圓（若需額外追討薪資或訴訟，會依比例抽取佣金）。優點也明顯，就是權限最完整、最安全。能處置所有棘手法律問題，包括：追討未給付加班費、職災賠償、應對公司威脅提告，或員工本身是公務員、派遣合約等複雜身份。律師出面通常具備極高的法律威懾力，雇主幾乎不敢刁難。缺點當然就是費用貴，而且行政流程可能比一般線上通訊軟體（LINE）為主的民間業者稍顯嚴謹與繁瑣，本來想要代行服務的人，就是不想跟別人溝通這些心理壓力大的事情，結果找了律師還是得跟律師溝通啊。

我在note.com上面看到對於這種現象截然不同的看法。而有這麼不同的看法也表示，這個退職代行真有其市場。有些是公司管理階層，特別是基層主管，退職代行對他們造成非常大的困擾。對他們的直覺感受就是：某個員工有一天突然人間蒸發，而那天他也收到一封非常正式的退職代行通知書，說不用再跟這位員工聯絡了，所有事情都跟本公司說吧。這些基層主管，會非常傷腦筋，或許有些人只是想知道原因，想知道怎麼交接，但現在只能硬著頭皮自行解決。有很多HR或者主管開始討論是不是要對這種情況有所準備，預設大家都有可能某一天隨時離開？

有些是受到職場壓力的人，無論是哪種類型的壓力，都讓人身心疲憊，甚至造成生理上的反應。但不是每個同事都很糟，一想到自己離職會造成大家困擾，壓力變更大，情況更糟。所以退職代行給了一條活路。的確是因為有市場，而產生的服務。

台灣大概是不會有這種服務。倒不是台灣人辭職比較沒有壓力，辭職恐怕都是有壓力的，但是台灣勞基法是規定可以「員工通知一下 就算離職 不管公司主管有沒有同意！」，而且所謂的通知，用口說，簡訊，電話，email都算，反正你跟公司說你不做了，就是不做了，公司依法必須要給你該有的東西。例如剩下的薪水不能拖欠，拖欠了你還可以提告。而由於勞健保是屬於政府法規，公司當然會自行幫你退保。

我後來想一想，台灣很多民法跟日本是非常接近的。難道台灣勞動基準法，會比日本更優於勞工？我覺得不太可能。所以我查了一下：日本《民法》第 627 條第 1 項規定： 當事人未約定雇用期間時，任何一方可隨時提出解約申請。自申請之日起，經過兩星期後，雇用關係即行終止。相對於台灣勞基法，其實差不多，台灣勞基法也有預告期，根據在公司工作的時間不同，最多也是30天而已，而且，即便你沒有30天前通知，只要你提出離職，不管主管把離職信撕掉還是拒絕，無論是台灣日本都是一樣，離職都已經完成了！剩下唯一個差別是，在台灣如果你沒有事先預告離職，公司因此有巨幅損失，是可以請求賠償，但在實務上公司很難提告賠償，因為絕大部分突然離職的員工根本不是做什麼重要的事情，而像是"公司要重新找人花時間成本"或者"找人要刊登廣告 廣告也要收費"這種屬於公司本來就應該處理，都不在法院的考慮範圍內。

所以其實法規是差不多的呀。真正的差別可能就真的是文化差異了。

六十億token其實很少呀

今天看到個一時之間令人訝異的新聞，是在商周上看到，內容很簡單，就是一位知名上市公司董事長說他們公司兩個月燒掉六十億token，他想要表達公司對AI的支持，並且他說"台灣不能再用人海戰術 要轉型成應用大國"

雖然我對他的想法大致是支持的，但那兩個月燒六十億token實在少得可憐。

我現在在一個小型AI公司工作，公司裡面只有7個工程師。我今天到其中一個我們使用的LLM的API key使用紀錄，光是7/2~7/3，就超過1億token。我們使用不只一個LLM(openai, claude, gemini都有用) 每個LLM大致上是均勻使用。也就是說，一個正常工作日，在我們這個小公司就要花到1.5億token，兩個月下來，最起碼66億token。但我們只是個七個人的小公司啊！這個上市公司，可是有八萬員工的公司，當然其中6萬多人是產線作業員，但白領以及工程師也有上萬人。如果他們真的把AI當作重要的程式設計，系統開發等工具，絕對不可能只有六十億token。
也有可能是董事長講錯，也有可能是記者記錯。但無論如何，沒有意識到這六十億token對於該公司是相當小，是個很奇怪的事情。我覺得更有可能的是，畢竟是硬體廠商，領導階層可能真的不解AI"應用"發展的現況，以至無法在心裡理解token數量的大致規模。

但我相信，他在腦海裡必能快速計算公司每個月可以生產多少AI伺服器，會有多少獲利，主要產線有哪些問題等等。

當然token隨便亂用也不是好事，可是以一個資深程式設計師來說，使用各種工具的情況下，一個月花到上億token真的很容易啊。