小編精選 - 技術文章翻譯 · 07月13日

科技界的 Unboxable：證據保管庫

title: "科技界的無法裝箱者：證物櫃"
published: true
description:
tags: career, discuss, webdev, showdev
cover_image: https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/v5i8ilc5xibh1petp1er.png
published_at: 2026-07-09 16:35 +0200

十一件證物，上一回。我那段一直無法被塞進單一盒子裡的職涯——培訓講師、餐廳老闆、郵務人員、開發者、學校助理、又回到開發者——以及最後那個我沒有答案的問題：那到底是誰的問題，是我的，還是盒子的。

我現在還是沒有一個乾淨的答案。但我也沒有停下來等答案。那股不願意被歸類的念頭，從履歷轉移到程式碼上，又產生了八件新的證物。以下就是那些成果。

證物 12 — 圖譜

證物 11 的結尾時，我還站在教室裡，一週四天，幫一個不是我的孩子專注在也不是我的工作上。這不是隱喻，這就是實際的行程。

另外三天，我在寫程式。

某個時候，我試著用一般的 CV 向招募人員解釋這件事——就是那種線性版本，一份工作一行，按時間順序排得整整齊齊。看起來就像一個無法穩定工作的人。培訓講師、餐廳老闆、郵務人員、學校助理、開發者、又回到開發者，底下永遠都是開發者——但時間軸看不出「底下」是什麼。它只會顯示順序。

所以我不再寫時間軸，而是改做圖譜。把技能當成節點，把職務當成節點，把真正連接它們的關係當成邊——就像當初我質疑 CMS 或 ORM 的那股直覺，只是這次用在我自己的職涯上。結果發現，看起來雜亂無章的 CV，其實是渲染問題，不是內容問題。資料本身沒問題，是視覺化在說謊。

我還不知道圖譜會不會比十一個條列更能讓招募經理看懂，但我知道，它比較像真正的我。

學校助理這份工作只覆蓋了我生命中的一部分月份。圖譜才是我真正的樣子。我還在想辦法，讓這兩件事不要再互相矛盾。

（完整拆解——節點、邊、以及為什麼圖譜比時間軸更好——收錄在 Beyond the Linear CV。）

接下來，是同樣的直覺，只是這次面向的是程式碼，而不是職涯。

證物 13 — AJC Bridge

我想繼續在 WordPress 上寫作。不是因為它好，而是因為那是我已經熟悉的介面，幾乎沒有摩擦感。但我不想讓輸出內容只留在 WordPress 的主機上，承受 WordPress 的重量，卻要面對那些根本不在乎是哪個 CMS 產生頁面的讀者。

這不是遷移，是橋接。

所以我做了一個外掛。它掛在 WordPress 的發佈動作上，把內容推送到 Hugo、Astro 或 Jekyll——看目標網站跑哪個就送去哪個。一次撰寫，用我已經熟悉的工具，卻能把內容發佈到真正有讀者閱讀的地方。

有趣的不是程式碼。WordPress 發佈到靜態網站產生器，這其實早就是有十幾種半成品解法的老問題。真正有趣的是，我刻意抵抗那個最顯而易見的做法：直接把 WordPress 丟掉，然後稱之為進步。

問題不在 WordPress 本身。它只是我很熟悉的基礎設施，承載著我在意的內容，只是被一種不符合實際需求的代管模式拖慢了。人們常常會說的敵人——「WordPress 太肥了」、「直接用靜態網站就好」——其實從來不是我真正的限制。真正的限制，是那種認為熟悉不算數、認為「現代」工具就一定預設勝出的想法。

我把它拿去參加 GitHub Copilot CLI 挑戰。拿到前 7%、亞軍、400 多件中的前 25 名。不是因為點子多有原創性，而是因為大多數參賽作品都在解技術問題，只有這個作品保留了原本的工作流程，而不是把它整個丟掉。

和圖譜一樣，這也是把同一種直覺轉向我自己的發佈習慣，而不是職涯本身：不要先問要替換掉什麼流行的東西；先問真正壞掉的是什麼。

（完整說明：Actually Static: When WordPress Stops Being the Enemy。）

證物 14 — dev.to 沒有給你的記憶

dev.to 內建的統計只會告訴你瀏覽數、反應數、留言數——每篇文章、當下的資料。它不會告訴你三個月前發生了什麼，除非你自己截圖存下來。它不會告訴你哪篇文章一年後還在默默吸引讀者，或是哪個留言串最後發展成值得追蹤的內容。這個平台沒有記憶，它只有現在式。

我想知道自己的歷史。所以我先從小處開始——本機腳本、SQLite、排程抓取我的統計資料，然後就只是……把它們存起來。沒有比「不要把這些資料弄丟」更遠的計畫。

小規模一開始可行，直到不行為止。當我開始真的想查詢歷史資料——趨勢、比較、哪些文章的壽命比較長——筆電上的 SQLite 就不夠用了。於是我把它重做成一個真正的技術堆疊：FastAPI、搭配 pgvector 的 PostgreSQL，全都容器化，跑在我自己的 VPS 上。我先試了用 Superset 做儀表板。後來放棄了——對我實際需要看的東西來說，學習曲線付出的代價比產出還高。Streamlit 用更少的成本、更快完成了同樣的工作。我還大多數是搭著 GitHub Copilot CLI 一起完成的，把這個 agent 當成不是單純自動補全，而是像第二雙手一樣，幫我處理那些我已經知道怎麼規劃、但不想再打第二次的部分。

這一切都不是別人委託的。沒人要求我做一個 dev.to 分析平台。我會做，是因為一個設計上就會遺忘你歷史的平台，你就得自己比它更會記。

又是同一種直覺：不要把工具的失憶當成世界的現實。把它下面那層基礎做出來。也不要因為已經投資過某個工具，就一直留著它——Superset 也讓我學到這件事。

（從頭到尾的建置過程：From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI。）

證物 15 — 波蘭殭屍網路

dev.to 分析平台跑在 Cloud Run 上。有一個月，帳單突然暴增。不是一點點，而是大到我立刻注意到，讓我停下來，真的去看日誌，而不是假設這是我該高興的流量暴增。

不是流量，是殭屍網路；其中大部分追溯起來都來自波蘭，猛烈打那些根本不該被打得這麼頻繁的端點。沒什麼新奇的——沒有入侵，也沒有資料遺失——只是把噪音包裝成負載，默默讓我替它被掃描付費。

修法不是升級成更大的 instance，也不是在表面上硬加一個 rate limiter。真正的做法是回頭看實際暴露了什麼，關掉不需要公開的部分，並讓剩下的東西對攻擊者來說比對我來說更麻煩。帳單直接降了 96%。

最無聊、但也最重要的教訓：多數人以為要靠擴充解決的成本問題，其實都是還沒看出來的資安問題。很多所謂「過時」系統也是一樣，人們動不動就想重寫，但一半情況下，解法其實更小、也更接近，而不是一開始就想到的重寫。

到了現在，這個模式幾乎已經變成自動反應：先注意你以為正在發生的事，和實際發生的事之間的落差，然後在動其他東西之前先把那個落差補起來。

（完整日誌與數字：How I Cut My Cloud Run Bill by 96% by Stopping a Polish Botnet。）

證物 16 — WordPress 轉 Hugo，然後繼續往前

我曾經把 WordPress 遷移到 Hugo 的過程寫成一篇超快重建的文章：把 CMS 拿掉，保留內容，做出載入毫秒級而不是秒級的東西。那篇文章表現不錯。但它沒寫到的是，我發佈之後其實還繼續做了下去。

一個一次性的遷移腳本，處理一個網站還行。我一開始沒意識到那不只是腳本，而是一條流水線的起點，直到第二個部落格出現。到了第三個，模式已經很明顯了：不同的內容結構、不同的外掛怪癖、不同的東西需要映射，而不只是單純複製。所以那個腳本最後真的變成了一條流水線——內容擷取、圖片處理、重新導向對應，這些不會出現在「看，現在載入快很多」截圖裡的東西，才是實際工作。

一個專案真正有趣的版本，從來不是你發佈的那一版。真正有趣的是，在掌聲停止之後它還繼續被使用，安靜地變成基礎設施，因為不然的話，每次有人開口，你都得從頭解同一個問題。第一個修法只是 demo。真正的修法，是六個月後還在運作的那個。

（兩個遷移分別寫成兩篇：WordPress to Hugo；等這條流水線成熟後的 From WordPress to Astro: Three Days to Reclaim Control。兩篇文章都沒有寫到第二個與第三個客戶之後發生了什麼——這裡補上那一段。）

證物 17 — GCF Pro

在法國，培訓機構要受 Qualiopi 認證規範管理——這是一套合規框架，規定了他們如何管理資金、行政紀錄與稽核軌跡。大多數機構用的工具，其實都是為別的用途設計的：被硬拗的通用 CRM、靠習慣勉強撐著的試算表，或是專門賣給企業、但完全沒內建真正合規邏輯的昂貴軟體。

我把 GCF Pro 做成我一直看到培訓機構想要卻得不到的工具——自架主機、PHP、不要 ORM、不要比問題本身還重的 framework，並且以授權而不是訂閱的方式販售，因為這些機構不希望他們的合規資料，因為別人的 SaaS 訂價決策而被綁住。On-premise 不是我勉強接受的限制，而是在我真正理解「稽核軌跡」對那些證照成敗繫於此的人來說意味著什麼之後，才知道那其實是實際需求。

法國大約有 28,000 家通過 Qualiopi 認證的機構。這不是假設，而是篩選過後的名單。我目前還沒有證明，一份名單就是一個市場。

（產品網站在 gcfpro.fr。文件在 doc.gcfpro.fr。）

證物 18 — Prospection CRM，以及和我一起監看它的擴充功能

大量冷開發需要一個資料庫。我的一開始就是這樣——從公開的 Qualiopi 紀錄爬下來、補充資料、追蹤活動，並從設計上就符合 CNIL 規範，因為我寧可把這個限制直接做進系統裡，也不要之後再硬補。

資料庫本身不是重點。真正有趣的是，當我只是隨便瀏覽、並不是刻意在找潛在客戶時，會發生什麼事。我做了一個 Chrome 擴充功能：當我進到一個看起來像潛在客戶的網站時，只要點一下，它就會讀取目前頁面和法律聲明——公司名稱、SIRET、電話、負責人姓名——並排程掃描重點資訊：安全標頭、PHP 版本、效能，跟我大規模執行的診斷一模一樣，只是觸發條件只是我在看那個頁面。

它把「注意到某件事」和「開始行動」之間的落差壓到最小。不用複製貼上，不用切到表單，不用那種「我晚點再加進去」但最後永遠不會做的步驟。這個工具不等我決定自己現在是在工作。它假設我一直都有一點點在工作，然後自動讓開。

證物 19 — S&R CRM

有個客戶需要供暖與水管技師用的維護合約追蹤——哪棟建築有哪些設備、哪份合約涵蓋哪些設備、下一次保養何時到期。多數工具的直覺是把合約掛在客戶身上。這對這個產業是錯的：客戶會搬家，建築不會。鍋爐才不在乎今年房子是誰擁有的。

所以合約應該跟著建築走，而不是跟著住戶走。聽起來像是一個很小的建模決策。其實這是系統會不會在每次有人賣房時默默壞掉，和不會壞掉之間的差別。

原本替一個客戶做的修法，現在正變成一個獨立產品——行事曆那一側用 ScheduleX，介面用 Mazer，後端依舊是這裡所有東西都在用的 PHP 原生架構。還在轉型中。我還不知道「建築優先、住戶其次」這個模型，對這個產業以外的人來說是不是顯而易見，還是這整個產品的核心賣點。

結論

八件證物——一座橋、一層記憶、一道圖譜、更低的帳單、一條遷移流水線、一個合規工具、一個會和我一起思考的瀏覽器擴充功能、一個把世界建模正確而不是建模方便的 CRM。不同的問題，同一種反射，每一次都是先看真正壞掉的是什麼，再去相信「本來應該被替換掉的是什麼」那個故事。

把它們和前十一件排在一起，有件事就變得很明顯，只是我在經歷當下時完全沒察覺。那段在履歷上看起來零散的職涯——講師、餐廳、郵局、開發者、學校助理——以及那組在作品集上看起來零散的專案——一個 ERP、瀏覽器擴充功能、CV 視覺化、雲端帳單——其實是同一種形狀。兩者都不是我剛好做過的一串無關事情。它們都是當一個人不停問「這裡到底壞了什麼」而不是「標準答案是什麼」時會出現的結果；而且是在每一個經過他身邊、沒人雇他去維護的領域裡，一直重複這件事。

我知道怎麼做這件事。我一直沒想出來該怎麼用三個字，把它寫在名片上，給那種只有三十秒、而且在聽你說下去之前一定要先分類的人看。

所以這才是實際的問題——而且不是修辭：看完這份清單，你會願意為其中哪一項付錢嗎？如果會，你會怎麼稱呼它？我不是在討拍，我會問是因為我已經失去從外部看自己作品的能力，而第一批十一件證物和這後八件都沒教我怎麼看。但在第一個問題底下還有第二個問題，這才是我真正需要答案的：不只是「這些裡面哪個有價值」，而是像你站的角度看來，一個能做完這些事的人，看起來會是什麼樣子？這種人有名字嗎？因為從我這裡看起來，它只是同一個人一直在解眼前的問題而已，而我已經分不清楚，那到底是一份作品集，還是一種人格。

原文出處：https://dev.to/pascal_cescato_692b7a8a20/unboxable-in-tech-the-evidence-locker-20n4