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) 主題發想  ... 只有這個階段是純人類完成
(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找到




8/06/2026

寫書能賺錢嗎? - 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 這個作者頁上面的五本書就是這次的成果。截至目前為止,只是剛放上去而已,還沒有任何銷售量。為什麼需要一個筆名?因為研究顯示,不管哪一類型的英文書,作者最好還是有個「英語系國家名字」會比較好賣。

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



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美金。或許他真的需要收入,心裡急了,就想趕快問問。

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



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