TS 資訊科技與人才培育
資訊科技 管理 與人才培育
10/03/2026
[AI不會幫你做的事] 閱讀
9/30/2026
[AI不會幫你做的事] 壁掛浴室暖風機 電燈開關
前陣子家裡的暖風機電燈開關似乎壞了,按了很多次電燈也不亮,長按也沒用,但有時候又會突然好了。暖風機倒是可以正常使用。
網路上可以根據型號找到新的控制器,蝦皮賣1999台幣!不知道算貴還是便宜。
(2) WD40食品級:任何可能接觸到食品的機器,要除鏽防水,像是果菜機,食品加工機。
9/24/2026
ISO 27001認證的必要性?
我在某電商工作時,曾負責取得ISO 27001認證,今年又搞定目前公司的ISO 27001認證。要通過認證嚴格上來說不難,但是相當煩,耗時費力。
ISO27001有多少公司有?
首先,一開始會讓我有點意外的是,台灣大概只有不到兩千家的公司,持有ISO27001有效認證。但後來想想,ISO27001是資訊安全認證,因此,需要它的大都是軟體廠商,金融服務,電信服務。而台灣金融服務電信服務公司數量上其實不多,銀行就那幾十家,電信主要就三四家,加上周邊廠商,的確不會有那麼多公司,自然需要ISO27001數量也少。而軟體,電子交易,網路交易相較於其他國家,台灣算是相當的少,當然也就不需要ISO27001。絕大部分的電子製造業的品管認證,ISO9001 在台灣有超過兩萬張,數量自然比資訊安全來得多。
那麼,這樣的數量算多還是少?
這是列舉11個先進國家持有iso 27001認證的數量排序。看起來日本是最多。台灣感覺好像差日本一截。
| 排名 | 國家/地區 | ISO 27001 certificates |
|---|---|---|
| 1 | 🇯🇵 日本 | 6,644 |
| 2 | 🇬🇧 英國 | 4,455 |
| 3 | 🇺🇸 美國 | 4,260 |
| 4 | 🇩🇪 德國 | 2,444 |
| 5 | 🇦🇺 澳洲 | 2,217 |
| 6 | 🇹🇼 台灣 | 1,943 |
| 7 | 🇳🇱 荷蘭 | 1,568 |
| 8 | 🇰🇷 韓國 | 918 |
| 9 | 🇫🇷 法國 | 791 |
| 10 | 🇸🇬 新加坡 | 494 |
| 11 | 🇨🇭 瑞士 | 375 |
不過單就數量排序,顯然是不正確的。應該要按照公司數量,產業類別來排序。不過這樣做就搞得太複雜。這又不是學術論文。
弄的簡單的方法,以百萬人口數為單位,看看這些國家,每一百萬人有多少ISO27001證照。這種排序方法也沒什麼道理,只是可以盡量去除人口數量因素。
以 certificate / 百萬人口:
- 新加坡 — 113.7
- 荷蘭 — 87.1
- 台灣 — 83.0
- 澳洲 — 82.1
- 英國 — 64.4
- 日本 — 53.6
- 瑞士 — 41.6
- 德國 — 29.3
- 韓國 — 17.8
- 美國 — 12.5
- 法國 — 11.5
這樣一排下來。台灣反而是前段班,並且新加坡很明顯多餘所有其他國家。原因也很簡單,新加坡作為東南亞金融重鎮,許多公司的總部都在新加坡。我之前工作的電商總部也在新加坡,所以雖然我在台灣,處理ISO27001證照,但證照還是會歸在新加坡總部而非台灣分公司。
而台灣其實比例上竟然也很高,跟荷蘭澳洲差不多是屬於前段。ISO的總部雖然在日內瓦,但是瑞士法國(日內瓦是瑞士法國交界城市)比例倒是沒想像中的高。
ISO27001的必要性?
有些情況下認證有必要性。
例如,政府投標項目涉及政府的「核心資通系統開發、運維、代管」或「處理機密公務個資」,招標機關為了滿足自身的資安法遵,通常會在投標須知中規定:投標廠商(或共同投標成員)必須持有有效的 ISO 27001 驗證證書。
此外,大多數的情況是在「展現本公司的基本能力」。
從另一方面來說,當公司/組織被問跟資訊安全管理情況有關的問題。例如,投資者問「請問公司資訊安全有問題嗎?」或者客戶問「我的資料放在你家安全嗎?」等等此類問題,如果你沒辦法簡單回答這句話:「很安全,你看,我們有SOC2 以及ISO27001認證」那你就得用其他的方式回答。
我還真沒想到有什麼更好更簡單的方式可以回答這個問題啊。
9/19/2026
(仿生智慧 part-4) 跟果蠅玩坦克大戰

總之,這次的實驗,是模擬完整果蠅腦,來跟人類打坦克大戰。
這隻果蠅目前不太行。訓練模擬999場之後,牠對上一個「會走、會在瞄準時開火」的簡單電腦對手,勝率大概只有兩成多,比隨便亂按亂開火的隨機玩家高不了多少。真人應該很容易就贏果蠅。反過來想想也合理,如果人連果蠅都打不贏的話,那也太奇怪。
果蠅腦是哪裡來的
緊接著,另一組科學家(Shiu 等人)把這張接線圖變成一個可以「開機執行」的電腦模型:每個神經元都是一個簡單的電路:電位會慢慢下降,但是收到別人放電就往上加、超過門檻就自己放電、然後沿著接線圖把訊號傳給下游。他們證明這個模型可以重現果蠅的一些真實行為,例如舌頭碰到糖水會伸出口器等等。
我在前幾個小實驗裡,已經把這個模型用 NumPy 重新複製一次(當然是在AI協助下)跟原作者的版本比對過,反應幾乎一模一樣(相關係數 0.99)。所以我手上有一顆「隨時可以使用」的果蠅腦。
如何接到遊戲
遊戲是仿 Battle City 第一關的格局(只借用格子的排列,圖是自己畫的,應該沒有版權問題吧?):紅色的磚牆可以被子彈打穿、灰色的鋼板打不穿。兩台坦克,一台黃色的是你,一台綠色的、上面停著一隻卡通果蠅的是牠。規則刻意簡化:不用保護基地,就是互相打;每秒最多開一發;子彈跟坦克一樣快;被打中一發就結束。
那「果蠅開坦克」到底是什麼意思?整個過程0.25秒重複一次,分成三步驟:
第一:把遊戲畫面翻譯成果蠅的感官訊號,打進牠腦中對應的真實感覺神經元。
第二:讓整顆腦「跑」五十毫秒。十三萬八千個神經元同時漏電、充電、放電,訊號沿著兩百七十萬條真實突觸運作。在我的電腦上,這一步大約要零點一秒。
第三:讀出腦中一小群神經元的放電,決定坦克要做什麼:前進、左轉、右轉、掉頭、開火,還是不動。
所以嚴格說,「會學習」的地方是這751x6條連線的強度。果蠅腦本身當然是不會動的。
果蠅腦用什麼「感官」感知你
剛開始只想給牠眼睛:把坦克前方的畫面縮成三十二乘三十二的低解析度影像(果蠅複眼大概就這個解析度),投到牠視葉裡真實的視覺神經元上。然後我做了一個檢查:從牠腦中神經元的放電,能不能分辨「敵人在左邊還是右邊」、「我的砲口有沒有對準敵人」?
結果幾乎不能。只給眼睛,這顆腦對遊戲的理解接近瞎猜。這其實跟我前幾個專案的發現一致:坦克遊戲的畫面又暗又平,對一顆果蠅腦來說,沒什麼好看的。而且也跟實際上果蠅的人生是一樣的,果蠅主要並不靠眼睛處理環境的變化。
果蠅主要靠牠靠嗅覺器官、有觸角上的風感受器、有聽覺、有全身的觸覺、有味覺。這些感官在 FlyWire 的資料裡都有標好名字。把遊戲裡的資訊,一件一件「變成」成牠不同的感官刺激:
嗅覺:敵人在哪個方向。把牠兩千多個嗅覺受器神經元分成八組,對應八個方位;敵人在哪個方位,那組就放電,敵人越近放得越猛。對果蠅來說,敵人就是一顆越靠近、味道越濃的水果。
風感:果蠅觸角上有一群專門感受風和重力的神經元。敵人的砲彈飛過來時,離牠最近的那顆子彈的方位跟距離,就變成一陣風吹過去。
聽覺:果蠅的聽覺神經元分成兩組:一組在敵人開火那一瞬間響一下(聽到槍聲);另一組在「我的砲口正對著敵人、中間沒有鋼板」的時候持續響(表示可以打了)。
觸覺:撞牆。頭上的剛毛神經元分成前、左、右三組;哪個方向被牆或水擋住,那組就放電模擬撞到東西。
味覺:砲彈裝好了沒。糖的受器放電代表砲可以開,苦的受器放電代表還在裝彈。
每一個感官都直接打在 FlyWire 接線圖裡真實存在、有各自的神經元上,然後訊號自己沿著真實的接線在腦裡跑。加上這五個感官之後,之後再做一次同樣的檢查:從那751個下行神經元的放電,敵人方位分別率很高、是否有瞄準也能分辨、子彈有沒有飛過來也大多能感知。這顆腦似乎是知道遊戲裡在發生什麼了。
如何怎訓練牠
果蠅學東西靠多巴胺。在真實的果蠅腦裡,當一個氣味跟糖水(獎勵)或電擊(懲罰)同時出現,多巴胺神經元會放電,把「剛剛活躍的那些突觸」加強或減弱。神經科學把這叫「三因子學習規則」:突觸前放電、突觸後放電、再加上多巴胺,三個因子同時到,突觸才改變。
在第一個專案裡就用這套規則,教這顆腦分辨圖片是不是字母 A,效果很好。這次就把它搬到遊戲裡:
獎勵:牠的砲彈打中你,加一分(最大獎勵);牠被打中,扣一分(最大懲罰);牠在砲口對準你、中間沒鋼板的時候開火,小加零點一分,這是一點「引導」,鼓勵牠往正確方向開槍,就算沒打中。
多巴胺怎麼作用:每一步,六個動作單元跟七百五十一個腦神經元之間的突觸,都會留下一條「資格痕跡」。記錄「剛剛誰跟誰一起活躍」。牠選了某個動作之後,這條痕跡會偏向那個動作的單元,並且慢慢衰減(大約一秒多)。等獎勵或懲罰真的來了,多巴胺就沿著還沒消退的痕跡,把突觸加強或減弱。這樣,兩秒前開的那一槍打中了,還來得及獎勵。
訓練流程:牠先跟「站著不動的對手」練240場,再跟「亂走但不開火的對手」練360場,最後跟「會亂走、砲口對準時會開火的對手」練習399場,總共九百九十九場。每一百多場,我讓牠關掉探索、認真打一百場,記錄勝率。我的Mac M4 Pro同時開十二場訓練,整個訓練大約一個半小時。
訓練資料不是下載來的,就是這999場牠自己打出來的比賽。
以後可以怎麼變強
如果,不用果蠅腦,直接把「敵人在哪、有沒有瞄準、有沒有子彈飛過來」這些乾淨的數字餵給一個很小的普通神經網路,用一模一樣的獎勵去訓練,它在四百場之後就能打到七、八成勝率。所以遊戲跟獎勵的設計是可以學的,所以證明問題不是遊戲本身。如果,把果蠅腦那751個神經元的放電數,餵給一個用標準梯度下降訓練的線性模型。結果它也學不會,300場後勝率只有6%。這很有意思,代表問題不只是果蠅式的多巴胺學習規則不夠好,而是「從700多個雜訊很大的神經元放電數,在每場只有0.5次有用獎勵的情況下學會該做什麼」,本來就是很難的事。
如果,只給眼睛、不給其他感官的果蠅,訓練三百六十場,勝率一直在12%~16%之間 。說明其實其他感官是有用的。
目前,果蠅學到的不是「看到什麼就做什麼」,而是「整體上多開火、多掉頭」。不管砲口有沒有對準你、不管有沒有子彈飛過來,牠選各個動作的機率幾乎一模一樣。牠學到的是一種「習慣」,不是「反應」。但其實這和果蠅這個生物本身行為確實是一致的。
深究果蠅的腦部結構,那下行神經相對密集,因此,不管遊戲裡發生什麼,這幾百個神經元幾乎都在放電。多巴胺來的時候,加強的永遠是差不多同一批突觸,所以只能學到「整體多做某件事」,學不到「在什麼情況下做」。但老實說也跟這種極小型生物本身的情況一致。
如何玩?
整個系統我打包成一個 Docker 映像檔,裡面就包含這顆果蠅腦(接線圖加上訓練好的連線)。兩行指令就能在自己電腦上跑起來,打開瀏覽器,畫面是仿紅白機的坦克大戰:紅磚牆、鋼板、一台黃色坦克是你,一台綠色坦克上停著一隻卡通果蠅是牠。方向鍵移動、空白鍵開火。畫面右邊有幾個小視窗:你可以看到「果蠅眼中的世界」——牠前方那張三十二乘三十二的模糊影像;可以看到牠六個動作單元每一步各放了幾個電,哪一個贏了就亮黃色;還可以看到牠這一步的腦模擬花了幾毫秒。你看到的每一個動作,都是十三萬八千個神經元真的跑完五十毫秒之後,從幾百條下行神經的放電裡讀出來的,不是隨機數、也不是寫死的規則。
而且,每一場你跟牠打,牠都在用同一套多巴胺規則學。打中你,牠的多巴胺加強剛剛那一槍相關的突觸;被你打中,就減弱。每一場結束都會存一個新的訓練結果版本。
你作為人類,鐵定會贏牠。牠現在是一個會亂開槍、偶爾走位很怪的對手。但你會是在跟一顆真實果蠅腦對戰,而且你打的每一場,都成了牠的訓練資料。
要如何快速幫公司取得 ISO 27001 資訊安全管理 認證
所以,需不需要ISO 27001認證,其實端看公司客戶,如果是消費性客戶,那其實還好,沒這麼多人在意。但如果是企業客戶,牽涉到企業採購,企業的負責人當然會想知道最低程度的安全性控制。
目前,對於小企業來說,許多人會推薦Drata,一個月大概600美金,至少需要3個月,實際上恐怕要半年。一般而言,幫你搞定文件跟包auditor的agent收費差不多15000美金。所以至少16800美金,差不多五十多萬台幣!
相當貴啊
ISO 27001取得的意義
ISO 27001本身其實是設定「資訊安全標準」運作方式。他的邏輯是,你先設定好公司的各種policy,然後根據這些policy設定管理監督方式,然後auditor(稽核)取得管理監督方式的證據,然後auditor就會說「啊!你們很好,你們通過了ISO認證」在有企業客戶的情況,如果企業客戶問你「請問貴公司對於資訊安全的防護措施為何?我如何香相信貴公司對我資料儲存在公司有保障?」
有ISO認證的話,你就可以先簡單回答一句話「我們有ISO的認證」然後再開始吹噓細節「其實我們會先....然後再....然後又....」 對方如果不是資訊安全專業人士,大概只會聽到第一句話,你有ISO認證,就勉強相信你們大概不會亂搞
如何幫公司取得ISO
快速ISO取得的秘訣
9/18/2026
(仿生智慧 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%以上
========
市面上 同音錯別字查詢更正 解決方案的比較
做法一:果蠅腦
優點:- 極度輕量。整個引擎加索引可以壓在十幾 MB 以內,1000 筆商品的索引才 1.4 MB,理論上可以直接跑在手機、甚至瀏覽器裡,不需要任何伺服器。
- 快。查一次不到 1 毫秒。
- 完全免費、可離線。沒有任何 API 費用,資料不用送到外面,隱私有保障。
- 不需要訓練。搭好架構、資料丟進去就能用,改商品也只要重建索引(幾秒鐘)。
- 專門對付「同音/形近錯字」這種表層錯誤,非常對症下藥。
- 運作費用很低,以一個中型電商,一個月要600到1000台幣而已。
缺點:
- 它只懂「讀音和字形」,完全不懂「意思」。你打「魔法師的書」想找「哈利波特」,它幫不了你。
- 對「只打片段」(例如只打三四個字去搜一個長書名)比較弱。
做法二:Elasticsearch(業界最常見的搜尋引擎)優點:
- 成熟、穩定、功能齊全,全世界無數網站都在用,出問題有大量社群和文件可查。- 除了模糊比對,還能做各種篩選、排序、分頁、統計,是一整套完整的搜尋方案。
- 擴充性強,資料量從一千筆到一億筆都能撐。
缺點:
- 對「中文同音錯別字」其實不是天生擅長。它內建的模糊比對是看「字面差幾個字元」(編輯距離),但「利」跟「力」在電腦眼中是兩個完全不同的字,字面上差距很大。要讓它懂同音,你得自己額外做注音/拼音的處理,設定相當繁瑣。
- 它是一個需要獨立架設、吃記憶體的伺服器程式,不太會為了「更正錯別字」這一件小事去養一整套 Elasticsearch,有點殺雞用牛刀。一般來說這樣的elasticsearch還會做其他事情。
- 營運成本是那台elasticsearch,無論用什麼方案,都需要2000~5000台幣。
做法三:直接呼叫大型語言模型(LLM API,例如 Gemini 類的服務)
優點:- 最聰明、最全能。它不只懂同音錯字,還懂意思、懂上下文,甚至你打「那本魔法師小男孩的書」它都可能猜到是哈利波特。
- 幾乎不用自己開發,串個 API、寫幾句提示詞就能動。- 對各種千奇百怪的錯誤(同音、形近、語意、外文夾雜)都有很好的容忍度。
- 對於小型電商來說,成本可能反而更低,因為做查詢的人本來就不多,如果每天只有一兩次查詢,費用極端的低。
缺點:
- 如果使用者多,會發現它慢又貴。每查一次都要透過網路呼叫外部服務,通常至少要一秒以上,是果蠅腦的幾百倍到上千倍。理論上,查詢都要付費,量一大,帳單很可觀。
- 有可能有天生LLM「一本正經地亂講」的風險。雖然機率低,但是可能推薦一個根本不存在的商品。
- 很難「只回傳你商品庫裡真的有的東西」,還得額外做一層驗證。
======
以墊腳石為例,一個月要花多少錢?前面講優缺點還是有點抽象,我們乾脆用一個真實的例子把「營運成本」算出來。注意,這裡算的是「東西做好之後,每個月持續要付的錢」,不包含一開始的開發工。
先設定情境。墊腳石購物網(tcsb.com.tw)大約有十八萬個商品,假設一天約有三百筆成交。花錢的不是「購買次數」,而是「搜尋次數」。 會買的人,通常搜了好幾次、逛了好一陣子才下單;而且更多人是搜一搜、沒買就走了。以電商的經驗,搜尋量大概是成交量的幾十倍。我們保守,一個月大約六十萬次查詢。
方案一:果蠅腦
但要記得一個容易被忽略的成本:索引在查詢時必須放進記憶體(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 到 更多無上限
這不見得比方案二貴,但因為它是「按查詢次數計費」的查越多、付越多,而墊腳石一個月有六十萬次查詢。9/17/2026
(仿生智慧 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」,一個代表「這不是 A」。哪個放電放得比較多,就當作果蠅的答案。
一開始,這兩個神經元是隨便亂連的,答案當然也是亂猜。那牠是怎麼「學會」的?
訓練方法,大致源於真實大腦的獎勵機制,多巴胺。在神經科學裡,多巴胺就是大腦裡的那塊獎勵/懲罰。
具體來說,每看完一張圖、果蠅給出答案之後,我們就告訴牠對還是錯,並且據此微調相關神經連線的強度:答對就強化剛剛用到的連線,答錯就削弱它。這個過程一遍一遍重複,果蠅腦就會慢慢被訓練。
這裡又有一個,網路上很多人會分享,果蠅學習與記憶的中樞叫做「蕈狀體」(Mushroom Body),我們原本理所當然地想把學習放在那裡。但實驗做下去才發現:在我們這個視覺任務裡,蕈狀體幾乎完全沒有被activate,因為連到它的視覺神經細胞太少了,根本傳不進足夠的「形狀」資訊。這其實跟生物學是吻合的:果蠅的蕈狀體主要負責「氣味」的記憶,而視覺圖形的辨識,在真實果蠅身上是由大腦別的區域負責的。順道一提,接下來的另一個實驗就會用到氣味神經。
所以我們順勢把「學習的位置」,改到了視覺訊號真正豐富的地方。也就是眼睛後方、負責把視覺送進大腦中樞的那一批「投射神經元」。
結果?
講了這麼多,結果到底如何?以下是實際跑出來的結果:
在「簡單版」的測試裡(字母置中、字型單純、只有一點雜訊):
* 判斷 A 與非 A 的正確率高達 99.4%。 (5000張圖)
* 而且學得很快,資料只跑過一輪,正確率就已經接近滿分。
* 就算只給牠看 100 張圖來學習,正確率也有 96.7%。
在「困難版」的測試裡(六種字型、會旋轉、會縮放、位置會偏移、雜訊更多):
*正確率約 74%。雖然沒有簡單版那麼漂亮,但仍然明顯高於亂猜的 50%。
我們也做了幾個「對照實驗」來確認結果是真的,而不是碰運氣:如果用書上那種「答對給獎勵、答錯什麼都不做」的舊方法,果蠅根本學不起來,正確率停在 60% 動不了。這證明「答錯要給懲罰」這件事很關鍵。
另外,有一個結果很直得一提:如果我們把大腦裡的連線「隨機打亂」(保持每個神經元的連線數量不變,只是亂接),在簡單版測試裡正確率居然還有 98%。這說明在簡單任務上,真正運作的是前端那套「視覺投影」的機制,果蠅大腦「神經連結線路」本身,並沒有想像中那麼關鍵。到了困難版,真實大腦的接線才稍微展現出一點優勢(會得到74% )。老實說我後來想想也很合理,許多昆蟲的複眼直接就可以決定看到的東西是什麼,根本不用進到大腦思考。
(仿生智慧 part-1) 果蠅的頭腦 能做的事比想像中來得多
一隻果蠅的大概有16萬多個神經細胞,並且,這些細胞互相之間,總共有大概一億兩千百萬個神經連結。16萬細胞中,13萬大概在大腦,其他分布在身體不同地方。
而google的研究中心,把果蠅頭腦所有神經連結逐一數位化,並在2025年六月,發表了成年雄性果蠅完整中央神經系統圖譜MaleCNS v1。從發表以來,各種奇奇怪怪的應用都出現了,最引人注目的就是訓練果蠅玩遊戲,訓練果蠅投資數位產品之類的,這些種種作為,其實都是為了想要得達到利用生物天生有的頭腦架構,搞出更快更省電的人工智慧。
(1) 果蠅認字基本訓練:
(2) 果蠅同音錯別字更正:
(3) 果蠅 最瘋狂的事:
9/05/2026
電子書網路行銷 (寫書能賺錢嗎? - 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或者其他電子書網站,評論越多越容易被人購買。
當然訂閱也有分等級,最低9美金一個月的話,就是一次只能評論你的一本書,一本書還沒結束不能換下一本。當然訂閱越高,同時評論的書越多。
先說結果,這三項我都嘗試了,總投入的經費一萬二千台幣,完全失敗!一點用都沒有!
同音錯別字 在AI時代的處理方式
在2015~2022左右,電商網站,如果想要處理產品搜尋、同音字與錯別字時,Elasticsearch (ES) 是市場上最主流且最常見的解決方案。
他有很多搜尋引擎的優勢,Inverted Index與文字分析,內建完善的 Tokenizer 與 Filter 機制,能整合中文斷詞(如 IK Analyzer、Jieba),有拼音轉換插件(如 elasticsearch-analysis-pinyin),將同音字轉為拼音進行比對。
而且,模糊比對(Fuzzy Query):原生支援編輯距離演算法,可處理英文字母錯字或輸入長度的微小差異。(中文可能要有其他方式)
8/11/2026
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做的比較好,也不需要對員工解釋說:因為你上次專案做不好所以請你離開。
當裁員跟績效掛鈎的時候,所有事情都解釋不完,永遠不可能有滿意的結果。就連差強人意的被接受,都不可能。
對於還在的人呢?
說實在,工作壓力雖然會瞬間增高,但由於沒有交接,很多事情就算出問題,也應該在預測之內,只要公司能維持普通營運狀態一陣子,那些沒人做的事情,真正的重要性會浮現,浮現出來再做都還不遲。而沒有重要性的,自然也不用做下去。
如果我不是負責這樣的高技術部門,而是非技術部門,像是客服,裁員還會不會那麼順利就很難講。
沒有人會希望裁員,但是這並不是什麼嚴重的事情,只要補償金額合理,是個讓人好好休息的好機會。
8/08/2026
懇請不要用AI幫忙寫作?
最近紐約時報的一篇社論廣為流傳。而且流傳的比想像中還廣,很快的就在中文社群網站等地方出現link。
這篇社論的重點很簡單,作者希望大家不要用AI來做文字工作,因為AI會代替你思考,而文字工作(包含寫作,寫信,寫email等等)的本質是把你的思考,用文字形式傳遞給別人,讓其他人知道你怎麼想的。一但AI取代了人的思考,就是作弊。一但常常作弊就失去了思考。而且,長此以往,大家知道你是用AI寫的,就會請AI幫忙讀。
他懇切地說明了很多。當然都有道理。
我不是想討論他講的對的,還是不對。
但他文章裡有兩段話,看得我頗有感觸,請容許我用AI翻譯成中文:)
----以下引述原文----
普及的讀寫能力與民主崛起之間的關聯眾所皆知:歷史表明,具備自主閱讀與書寫能力的人,通常也擅長為自己做出選擇與發聲。然而,當這個過程開始倒退時,會發生什麼事?當人們失去耐心,無法吸收超過幾頁甚至幾句話的論點時?當他們因為缺乏日常練習,未能磨練出清晰思考的核心技能,從而失去了反駁這些論點的能力時?
我們已經在川普總統的社群媒體貼文,以及這些貼文對數千萬美國人產生的巨大影響力中,初嚐了這個世界的滋味。但那不過反映了十年前,在 AI 時代來臨前,這個國家的狀態。而如今,在我們閱讀、書寫與思考能力更加衰退的當下,我們又在這條路上往前走了多遠?
-------------------
他講的是很懇切,很有悲天憫人之心,在這個常常有反智現象的兩極社會裡,他不是第一個大聲疾呼的人,也不會是最後一個。雖然大體來說,綜觀人類歷史,對未來長久發展的推測還是樂觀的,但就某個時間區間,某個特定地區來說,人類也可能很慘很慘。
而個人的選擇,非常重要。因為每個個人的選擇,集合起來就變成大家的選擇(聽起來很廢話)就像工業革命之前,要出遠門,要就走路,有錢人頂多騎馬坐馬車牛車。那時候的人,基本上沒聽過,也不太會有膽固醇過高糖尿病等等。工業革命之後,生活上的方便,"整體"來說,還是增加人類的壽命。一個人可以選擇幾乎完全不運動,跑步健走爬山,不是交通工具,而是你對「健康」的選擇。
講的更殘酷一點,AI的便利性,的確會降低人的思考力,進而在很多情況下,降低某些「不做選擇」的人的智商知識力。這些人類只會聽從AI,拿取AI的便利性,而無法從中「選擇強化」自己的智商知識力,那就會跟工業革命之後,得膽固醇糖尿病的人一樣,這並不是交通工具的問題,是個人選擇的問題。
什麼樣選擇做法對自己比較好呢?你一定知道,但會不會做就很難講:)
對了,感謝善心人士。這篇懇請不要用AI寫作的社論的link是透過善心人士合法分享,所以不用訂閱登入也可以看到,順便說明一下,其實你免費登入也可以看。
8/07/2026
讓不同 AI 互相審稿:我用 opencode 打造的寫書流水線 (寫書能賺錢嗎 Part-2)
opencode是典型的AI coding工具,無論是「幫我改 bug」「幫我補一個功能」這類日常開發工作,都是典型的用法。但如果把它看成一個能讀檔案、寫程式、也能呼叫外部工具的 AI 助手,它其實可以拿去做很多事,包括寫書。
過去幾個月,我陸續用 opencode 完成了幾本英文自我成長書籍。它參與的不只是「生成文字」,還包括整理寫作企劃、安排不同模型互相審稿、寫處理內容的小工具,以及最後把 Markdown 轉成 EPUB 上架。這篇文章不打算討論「AI 能不能取代作者」,而是想記錄一件比較實際的事:在這整個流程裡,opencode 到底負責了什麼、哪些工作交給模型比較好、哪些反而應該交給固定的程式碼(當然這個所謂固定程式碼 也是AI生成 只是固定執行而已)。
以下的例子來自完成的5本書。對我來說這5本書最大的收穫,不是產出了5本書,而是讓一套流程慢慢變成可以重複使用的工具鏈。
整體流程大概長這樣
(1) 主題發想 ... 只有這個階段是純人類完成
人類(就是我)必須先想好書的主題跟概觀,模型主要負責生成和評論;程式負責批次執行、保存結果和驗證格式;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 上去。
回到「怎麼換模型」這件事本身,其實可以分兩個層次看。如果只是想換掉目前對話裡在用的模型,opencode 本身就有內建的方式:輸入 `/models` 就能挑選要用哪一家、哪一個模型;也可以在設定檔裡指定預設模型,或是替不同的 agent 分配不同的模型。例如負責規劃的 agent 用一個較快、較便宜的模型,負責寫程式或做深度分析的 agent 換成能力更強的模型。這些都是點一點設定就能做到的事,不需要另外寫程式,也是大多數人平常換模型的方式。
我並不是找到了一個很會寫文章的模型,而是我開始把寫書當成一件可以設計的事。模型可以幫忙產生內容,也可以扮演編輯、讀者或審稿人的角色;但流程怎麼拆、哪些結果要留底、哪些建議不能照單全收,終究還是要人來決定。封面文字、電子書結構這類要求精準的工作,交給傳統程式碼處理(當然傳統程式碼也是AI產生)反而更放心。從一本書到下一本書,速度變快的原因從來不是「讓 AI 自己多做一點」,而是把每一種工作交給適合的工具,並且可以根據犯過的錯修正。
AI 時代,有經驗的工程師反而更吃香
這陣子常看到新聞說,AI 讓工程師的工作變得岌岌可危,資工、資管相關科系的前景一片看衰。我自己倒是有不太一樣的體會:如果你本來就有軟體工程的底子,AI 普及之後,你能做到的事情反而變多了,不是變少。
單純打開 ChatGPT 網頁請它幫忙寫書,跟用 opencode 走一遍前面講的這整套流程,表面上都是「叫 AI 寫東西」,實際做起來完全是兩回事。在對話框裡,你每次只能一問一答,模型寫完一段,你得自己複製貼上、自己記得上一輪講到哪、自己去湊下一個 prompt;想要同時比較兩家模型的意見,就得開兩個分頁,自己把結果拼在一起看。這些事情不是做不到,只是每一步都要人親自動手,很難放大規模,也很難重複執行第二次。當然你也可以用openclaw,但他的設定繁瑣也得有工程背景的人才
而工程背景真正值錢的地方,是能把這些零散的步驟,寫成一套會自己讀檔案、自己呼叫好幾家 API、自己把結果存下來、下次還能接著跑的流程。企劃要不要重審一次、審稿意見要不要留底比對、電子書格式對不對,這些原本要靠人一步一步盯著做的事,都可以變成可以重複執行、也可以事後追查的工具。AI 本身很強,但強的模型加上散亂的操作方式,還是只能做出一次性的成果;懂得把 AI 放進一套系統裡的人,才能讓同樣的模型,一次又一次穩定地產出東西。
換句話說,這波 AI 浪潮真正淘汰的,可能不是「會寫程式的人」,而是「只會手動一步步操作、沒辦法把工作系統化的人」。對一個原本就習慣拆解問題、寫腳本、做自動化的工程師來說,AI 比較像是多了一批隨時待命、又便宜又能幹的隊友,而不是搶飯碗的對手。
8/06/2026
寫書能賺錢嗎? - Part-1
AI發展很快,許多事情已經在改變。
現在新聞網站上,常常看到標注「本文由AI產生」,也慢慢在電視台看到AI主播。更有甚者,利用AI來讀取資訊,已經佔了網頁資訊瀏覽的1/4以上,而且有很明顯的增加趨勢。
由AI產生內容,很快就要趕上人類產生內容了!那,寫書還能賺錢嗎?或者,使用AI會寫書來賺錢,反而更容易呢?
為了想試看看AI寫書能不能賺錢,我打算來做個實驗,實驗內容很簡單:
(1) 找到暢銷書能夠撰寫的類別
(2) 用AI寫書,至少5本
(3) 取得 ISBN 上架到amazon kindle
(4) 花一點錢行銷
(5) 放段時間 看看是否有收入
首先要決定類別,但在決定之前,我打算市場專注在英文市場。其實原因也很簡單,目前電子書市場還是以美國最大,如果加上英文系國家,那沒有任何語言可以比呀,即使是中文規模也無法跟英文比,特別是電子書。
其次,哪種類別的書最多?隨便走進一家台灣的書店,擺在最前面桌子,一入口就可以看到,通常是三大類「幫你賺錢」「鼓勵你幫助你的心靈」「最近很流行」。不需要專業知識,也不太需要成功故事的,大概只有「鼓勵你幫助你的心靈」這類。這類型的書範圍非常廣,從偏向諮商的「情緒勒索」「被討厭的勇氣」到各種狀況的建議,例如「每天只工作四小時」「絕不妥協的處世藝術」等等,範圍廣,而且理論上只需要給出自己的經驗,或許就可以贏得共鳴。
8/01/2026
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美金。或許他真的需要收入,心裡急了,就想趕快問問。
當然這樣同情也只是猜想,這件事情就成為自己一個經驗,或許在什麼時候會再看到也說不定。
[註]:名目所得的定義跟薪資不樣,絕大部分的國家名目所得都遠高於薪資,但名目所得是經濟學用來計算真實收入的方式。所以實際上的每日薪資會比名目所得低。
7/31/2026
執照 認證 頭銜
技術類型的工作者,工作久了,其實都有很多證書/執照/獎狀可以放在上面參考,多多少少對自己的職涯有點點幫助。
「執照」:根據各國法規應該有的工作類型執照,要從事該工作,當然一定得有。正常情況下,我們應該不可能去給一個沒有醫生執照的人看病做手術。而某些工作類型執照雖然沒有醫生執照這麼高門檻,像是職業小客車(計程車)執照,職業動力小船等等,考取不難,有執照也不見得是非常優良的司機,但沒執照去做該工作是不行的啊。
7/27/2026
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-INFmkdir -p ~/my-first-epub/EPUB/css
mkdir -p ~/my-first-epub/EPUB/images
mkdir -p ~/my-first-epub/EPUB/text
mimetype檔案是用來告知電子書閱讀器該如何處理此檔案。
關鍵在於,內容必須嚴格為 `application/epub+zip`,不可有任何結尾換行符號或空格,且zip打包成 zip 時絕對不能壓縮。
在shell裡面執行這個指令 確保沒有換行符號跟其他內容
<?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;
}
這步驟就是你隨便(AI)產生一個cover.jpg 放在這個目錄固定地方即可
所有實際書籍內容檔案,基本上就是 XHTML5 格式
<?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>
<?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>
第七步:建立導覽文件 (`EPUB/nav.xhtml`)
<?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>
<?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>
根據 EPUB 官方規範:
1. `mimetype` 必須是 ZIP 壓縮包中的第一個檔案,且必須不加壓縮(`-0`)且不含額外屬性(`-X`)。
2. 其餘所有檔案則透過遞迴方式壓縮加入。
1. 以不壓縮方式新增 mimetype 檔案
#zip -X0 my_first_book.epub mimetype
2. 以壓縮方式新增 META-INF 與 EPUB 資料夾
#zip -rDX9 my_first_book.epub META-INF EPUB
7/17/2026
現在年輕人比較辛苦?
每隔一段時間,總是會有各種文章,用各種數據,告訴大家「現在年輕人比較辛苦啊,房價很貴生活困難」
這些數據不能說不對,但是綜觀人類發展,從整體的角度來看,一定是「現在年輕人比以前年輕人日子過得好」。當然如果只挑一個特定的角度,例如房價/薪資收入,當然會覺得現在年輕人比以前辛苦,要工作更多年,才能買個更小的房子。
如果只挑一個片面角度,自然會很容易產生極端結果。例如,選西元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 縮短庶務時間,重視自主掌控權。 |














