Machikoba no Techo

唯有寫得出來的人，才看得見危險。

九月。這裡夏天的風物詩之一——透抽的夜焚季節，正緩緩走向尾聲。一直在夜裡出船的人們，已經悄悄轉向我們稱為 budouika（葡萄魷）的目標。感謝各位長久以來的支持與愛護。

而九月還有另一件事：這是軟絲聚集的季節。水溫從盛夏的高點沉靜下來，餌魚一口氣活躍起來。魷魚也隨之改變，成群的小軟絲進到淺場——在黎明與黃昏那短暫的時段裡，防波堤上的竿子一支支彎了下去。這也許是一年當中最令人興奮的時候。對於想開始接觸木蝦路亞的人來說，這也是最容易入門的季節。

這個月，容我再談談工廠的另一面。上個月我寫到，即使由 AI 執筆，停下來確認仍是人的工作。這篇是它的續集。過去這一年，我在現場大量使用所謂的「vibe coding」，感受到它的威力，也感受到同樣大小的危險。而我遇上了一個我想不少人也正面對的問題：AI 產出的程式碼，可以當成黑盒子、不看裡面就搬進現場嗎？

■ 說一句「我想要這樣的東西」，它就動了

所謂 vibe coding，就是跳過詳細的規格書：用日常語言描述你想要什麼，讓 AI 去寫，然後收下一個能跑的東西。過去一年，我們就是這樣做出了好幾個現場用的小工具。或者該說，我們生成工具已經像呼吸一樣自然。

先說結論：這確實很強大。以前那些「想做，但沒時間去研究」而被擱置的事，如今在想到的當天就能跑起來。過去得先向外面的公司要報價才開始的工作，一個午休時間就成形了。對我們這樣的小工廠來說，沒有比這更值得歡迎的變化。

■ 「會動」和「正確」是兩回事

然而，這一年最可怕的地方，正是它真的會動。產出的東西通常都能跑。畫面乾淨，數字也出來了。正因為它會動，你從外面看不出它究竟是穩健還是危險。

某一處的四捨五入有著微妙的不同。當數值超出預期範圍時的未定義行為。錯誤被默默吞掉，一切彷彿沒發生過地繼續進行。這些，盯著一個正常運作的畫面是看不出來的。看得出來的，只有自己寫過那種程式、並且因此吃過苦頭的人。

到頭來，不把產出的程式碼從頭到尾追過一遍，就無法安心。原本想靠委派省下的時間，原封不動地以「閱讀」的形式回到自己身上。製作的門檻大幅下降了，察覺危險的門檻卻沒有。這種不對稱，是我這一年學到最清楚的一件事。換成我們的說法，就像站在一台四千萬日圓的綜合加工機前面說「它動了，所以沒問題」。那是絕對不被允許的。

■ 小工廠裡沒有理想的工件

那麼，這是個不能用的工具嗎？完全不是。在我們工作的某些環節，它比任何東西都合用。但要說明這一點，得先繞道談談小工廠的現實。

以我來說，我日常在做一件有點奇怪的事：用 vibe coding 生成 NC——也就是機械的語言。要寫輸出 NC 的程式，通常會自動選上 Python；多數情況下我會把它換成 Ruby。這是我的作風。

現代的 NC 工具機精度高得驚人。給它理想的材料、理想的形狀與理想的尺寸，它切出來的成品會讓人驚豔。但在我們的工廠裡，那些理想幾乎從來不成立。手邊有什麼，就得用什麼把事情做完。材料不均勻，形狀與大小每次都不同。「照圖面來」這個前提，根本不在我們眼前。

我把這稱為「有什麼就用什麼做完的精神」。這是小工廠的強項，也是我們的驕傲，但站在寫程式的人的立場，它實在很麻煩。因為尺寸每次都不一樣，你沒辦法寫一段把數字寫死的程序。不能寫成「把這個形狀切到這個尺寸」，而必須改寫成「量出眼前的東西，再從那個數值推導出切削」。換句話說，抽象度必須大幅提高。這正是在小工廠寫程式最難的地方。

■ 最適合「配合工件」與逆向工程

而這種配合實物的作法，和 vibe coding 像得出奇。沒有先寫好完美的規格；你對著眼前的東西一點一點逼近，切一下比一下，比一下再切一下。讓它先產出一個能跑的，指出哪裡不對，讓它修，再試一次。因為規格還沒定案就能先動手，它和「有什麼就用什麼」的現場非常合拍。

尤其，vibe coding 對最難的那一段——提高抽象度——是很好的補強。給它一份把數字寫死的版本，請它改成尺寸變動時依然能用，它就會挑出哪些應該變成變數。過去一個人要花上好幾天才找得到的「切入角度」，一下子就被清掉了。那正是我們這種「有什麼就用什麼」的現場一直欠缺的能力。

另一個合拍的用途是逆向工程：從外部去戳一個你並不了解的機制，把背後的邏輯重建出來。用來讀陌生的資料格式，或是很久以前某人寫下的長篇程式碼、弄清楚它到底在做什麼，它可靠得驚人。這本來就是我們原本不懂的領域，所以就算它錯了，代價也很小。只要抓到切入角度，剩下的人可以自己驗證。

更貼近我們的例子：工具機廠商自己輸出的 NC 程式。老實說，我不太喜歡那些程式。沒有縮排、註解幫不上忙、看不出它在做什麼。看不懂的程式，就是無法停下來檢查的程式。AI 補上了這個缺口。跟它說程式碼很難讀、請加上縮排與註解，它就照樣交回來。說抽象度太低、請拆成子程式，它就把程式碼分成一個個有意義的區塊。行為不變，只是整理成人看得懂的樣子——這也許是我們現在最常用的用途。

最讓我們頭痛的是，沒有任何地方寫著一個子程式會對哪些變數產生副作用。呼叫它，某些東西就變了。但變的是什麼，非得把整份讀完才知道。讓 AI 讀過，請它在開頭的註解裡列出內部被寫入的變數——它就把它們挑了出來。那是過去一個人要花上半天的工作。

舉一個具體的例子。我們常讓 AI 改寫線切割放電加工機的 NC 程式。方便到我差點流鼻血。在 NC 的世界裡，雖然大家都叫它「G-code」，但每家廠商都有自己的書寫習慣——實質上就是方言。這一款要這樣寫，那一款需要這道指令。對人來說，那是一邊比對手冊、一邊在現場學來的東西。

AI 從你交給它的程式風格裡把這件事讀了出來。它能察覺這段程式碼遵循的是誰的慣例，並用同樣的慣例寫下新增的部分。再把廠商的手冊餵給它，它甚至不用人交代，就開始使用那一款機型專屬的巨集。它讀出「這台機器有這道指令」，然後一臉平常地寫了下去。那些在工廠現場經年累月累積下來的默會知識，竟然能這樣被抽取出來——老實說，我背脊發涼。

但我們絕不會把這樣產出的程式直接送進機器。我們會除錯。它一定會上實機，一行一行單節執行，用眼睛確認變數的值與電極線的動作。這正是上個月寫過的 M01（選擇性停止）發揮作用的地方。不管成品看起來多漂亮，如果你沒有在實機上除錯的能力，就不能使用這個工具。或者該說，我認為不可以使用。把它當成產出正確答案的工具很危險；把它當成尋找切入角度的工具則非常強大。但確認那個角度，永遠是人這一側的事。

■ 應該當成黑盒子嗎？

話說回來，回到開頭的問題。AI 產出的程式碼，可以不看裡面就搬進現場嗎？老實說，我們會區分可以與不可以的情況。目前我們畫的那條線，是看它放在哪裡。錯了之後還能察覺、還能修正，失去的頂多是時間——這種地方，我們就不追完全部地使用它。而機器會動、尺寸會定下來、材料會被消耗——沒有第二次機會的地方，再怎麼繞遠路，人也要把它從頭讀到尾。

麻煩的是，黑盒子不只有 AI 寫的那一部分。今天的軟體是靠大量呼叫元件建起來的——那些由世界上某個人、在某個地方發布於 GitHub 之類平台的函式庫。最近 JavaScript 圈就發生了一起大事件。（其實後門幾乎天天都在出現。）一個大量軟體所依賴的函式庫被接管，裡面被埋進一個機制：它會在安裝時執行，並且把自己往下一個套件散播出去。數小時內似乎就有數百個套件遭到汙染。在那不久之前，還有在傳輸途中攔截、把付款對象調包的案例——也就是竄改處理金錢的那一段。

你向 AI 要「像這樣的東西」，它自然會挑選並納入方便的元件。它之所以快，有一部分正是因為那些元件不是它自己寫的。於是我們收下的，是一個雙層結構：在 AI 寫的那個盒子裡面，它又呼叫了別人的盒子。沒有一個職人會在不知道材料裡摻了什麼的情況下就下刀。我想軟體也是一樣的。

「能不能信任別人的盒子」這個問題並不新鮮。一九九〇年代中期，寫出郵件傳輸程式 qmail 的 D. J. Bernstein（十多年前我們自己也跑過這套），連 C 的標準函式庫都不信任——那是隨語言附帶、大家想都不想就在用的元件。他在設計筆記中表明，自己大致上放棄了標準函式庫，並把最容易出事的部分，例如字串處理與記憶體管理，換成他多年來自行開發的小元件。他沒有做到重寫作業系統的地步，但有一點他很徹底：把危險的部分放在自己的掌控之下。

貫穿 qmail 的，是盡可能減少你必須信任的東西這個想法。除了自己寫元件之外，他還把程式內部依角色切成小塊，讓即使是他自己寫的部分之間也彼此不信任。其中一塊被接管了，也走不到下一步。三十年前就有人把這件事想得這麼透徹。當然，我們沒辦法模仿他把所有函式庫都自己寫。但那個想法——以「不可信的東西一定會混進來」為前提去劃界線——直接就能套用到今天。

而可怕的是，盒子一旦太大，就沒有回頭路。把一個你連內部都不了解的東西整團吞下去，出事時你沒辦法把它切開拿掉。所以對策必須下在設計上：保持在隨時可以替換的形狀。這一塊可以換成別的東西；把這個元件拿掉，整體仍然跑得動。這樣做，出事的那一天，你就能只丟掉那一個盒子。

這需要的是物件導向意義下的設計能力。什麼東西算一個單位，什麼要對外公開，內部要藏起多少？界線畫在哪裡？過去被當成「寫得漂亮」的事，如今已經是「不把危險的東西帶進來」的現實需求。正因為內容是 AI 在寫，決定界線的能力才是必要的。

而且，這條線放著不管就會移動。順利了一陣子之後，人難免會想把盒子做得更大。更糟的是，察覺危險的能力，會和你自己動手寫的量成反比地鈍化。這個工具有一種性質：用得越多，越看不透它。所以這條線必須由人這一側重新畫，而不是交給工具。

■ 比起寫程式，更需要系統工程

回頭看這一年，我印象改變最大的就是這裡：今後真正不可或缺的，不是寫程式本身，而是系統工程。

決定什麼要做、什麼不要做。在交給機器的部分與由人判斷的部分之間劃線。在動手做之前，先準備好它壞掉時要怎麼回復。決定資料放在哪裡、由誰負責。不管它變得多聰明，這些 AI 都不會替你決定——因為要決定這些，得懂現場的工作。

隨著寫程式的時間減少，我們開始把時間花在設計、營運，以及判斷何時該停手上。諷刺的是，正因為「寫」的工夫消失了，「寫之前」那些工作的份量才變得清晰可見。

■ 在有田，全製程自社一貫

在小公司裡，做的人就是用的人，壞了也是同一個人修。所以「我們做得出來嗎？」遠不如「這在我們自己照顧得來的範圍內嗎？」來得重要。把規模控制在停掉的那天能靠自己的力量復原。這並不華麗，但我相信這就是「適合自己尺寸的 DX」。

這和做木蝦是完全一樣的故事。試作品成形的速度比以前快得多。但在海上確認的那一步，無論如何都縮短不了。最後決定好壞的，永遠是海。做得越快，我們就把越多時間放在確認上——這就是我們選擇的用法。

在日本佐賀縣有田町這個地方小鎮，我們從設計、模具切削到量產與販售，全製程都在自社內部持續製作木蝦。這就是八月一直讓我思索的事。世界上某處某人寫下的元件，在我們自己的工廠裡運轉；AI 讀著我們機器的方言。在這當中，什麼應該留在人的手上？答案連一半都還沒到，但我打算不停止思考。

■ 這個月的出海

九月我們有一連串新色與新品。Akazamurai Meteor Glow Orange 是一款在夜光與 UV 照射之間會改變表情的橘色，預定本月上市。針對岸拋 tip-run 的 JetChaser Purple Edition 也在本月。此外，JetChaser size 3.0 與 size 3.1 將開始一般販售，預定九月底出貨。

今年也是 EgiSharp 的「Akazamurai」色誕生的第十五年。上個月底，我們公開了紀念十五週年的顏色影像。它能連續十五年被人選擇，靠的不是我們自己的自信——那是使用它的人們給出的答案。

不管工具變得多聰明，最後做判斷的是人，決定好壞的是海。我們會把這件事放在心上，一步一步繼續做東西。這個月也感謝各位的支持。

2026年9月
KeyStone Corporation
Nobuhide Kanagawa，代表董事