從壓縮到重建：AI 助理年代的人機協同知識工程
從壓縮到重建：AI 助理年代的人機協同知識工程

PCPILOT · 工程師思路系列 從壓縮到重建：AI 助理年代的人機協同知識工程 知識工程理論 · 母文定稿 · 2026-09-19 引言：你正在閱讀的東西，就是本文正在討論的東西 這篇文章不是只在談知識壓縮，它本身就是一次知識壓縮的實驗。 四篇獨立寫作的筆記，經過多輪 AI 協作、壓縮、發現結構損失、補回時間與脈絡，才形成現在你看到的母文。 原始討論 → 多模型加工 → 壓縮 → 發現損失 → 重建 → 新的知識模型 有句感想把 AI 助理的工作說得很準： 資訊的壓縮，以及解壓縮。 這條探索路徑，最後剛好形成了一個接近論文的論述結構： ✔第一層：為什麼不能只壓縮？——壓縮本身是判斷 ✔第二層：那應該保存什麼？——洞見生成容易、回收困難 ✔第三層：保存的東西應該怎麼表示？——需要可導航的拓撲與時間 ✔第四層：為什麼這種表示有價值？——知識傳遞是重建 第一章：為什麼不能只壓縮？ 一個有二十年現場經驗的工程師，看了一份新維修方案只說了一句話： 「這個方案有問題。」 六個字，背後其實壓縮了二十年的現場經驗。踩過的坑、失敗案例、對材質的直覺、對操作人員行為的長期觀察，全部被壓在那六個字裡面。AI 如果只看到文字，看到的就真的只有六個字。 AI 不只是要把外部資訊展開給人類看。更難的，是把人類自己腦中已經高度壓縮的經驗，重新解壓縮出來。 壓縮結果會實際產生取捨 在一次長時間多輪討論後，AI 把對話整理得非常漂亮，但把走過的幾條彎路整理掉了。那些彎路表面上跟主題無關，處理結果是省略。AI 的壓縮結果，會實際產生一個資訊取捨；而使用者未必有意識到這個取捨正在發生。 📌 Compression ≠ Selection Compression＝必然發生資訊取捨。 Selection＝有意識地決定哪些取捨不能接受。 AI 必然壓縮 →... » read more

0
Read
steven
從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題，順著脈絡把旁邊的問題也一起收掉。
從裸奔的 API Key 到全面打通的郵件架構 — 修一個問題，順著脈絡把旁邊的問題也一起收掉。

PCPILOT · 工程師思路系列 Pico-UTM 行銷日： 從裸奔的 API Key 到全面打通的郵件架構 修一個問題，順著脈絡把旁邊的問題也一起收掉。 那天的任務很單純：為 Pico-UTM 100 的銷售衝刺準備材料。這批設備有點特別——三年資安服務授權綁定的 700Mbps UTM，價格實在超值到連我自己都先買了一台，是難得一見的尾盤機會。 從早上開始，文件、網頁工具、診斷問卷一份接一份。其中最花工夫的是「企業網路風險自我診斷」工具：業主勾選公司有哪些網路設備，系統依風險模型即時產生報告，同步寄信給業主和業務端。 測試完成，信寄出去，報告顯示正常。完美。然後習慣性地按了 F12。 裸奔的發現 EmailJS 的 Public Key、Service ID、兩組 Template ID，全部白紙黑字在原始碼裡。 📌 什麼是 API Key 裸奔？ 網頁的所有程式碼，任何人都可以用瀏覽器「檢視原始碼」或開發者工具看到。如果服務的金鑰（API Key）直接寫在網頁裡，等同於把保險箱密碼貼在門口。拿到 EmailJS 的 Key，任何人都能冒用你的帳號大量寄信，直到額度用完或帳號被封。 做資安診斷工具的人，自己的工具先裸奔——這個畫面說不過去。當天就決定修掉。 路徑分歧：怎麼選解法 解法不只一條，每條都有代價。 方案 可行性 決定 自架後端伺服器 可行，Key 安全 ❌ 多管一台機器，排除 Resend 前端直打＋Domain 限制 Key 洩漏仍可發詐騙信 ❌ 法律風險，排除... » read more

0
Read
steven
從防火牆到 AI：資安設備真正累積的，從來不只是防護功能
從防火牆到 AI：資安設備真正累積的，從來不只是防護功能

從防火牆到 AI：資安設備真正累積的，從來不只是防護功能 工程師思路系列 · Mr. τ / 風雲網通系統  |  PCPiLOT 最近在研究 LionFilter 200。原本只是很單純的問題：一台標榜 10GbE、AI、防毒、IPS、惡意網站防護的中小企業 UTM，到底值不值得放進工廠環境？但一路研究下來，我反而想到一件更有意思的事情——我們今天看到的「AI 智能資安」，背後有一條走了二、三十年的路。而真正累積價值的，也許從來不是某一個防毒引擎，而是「資料」。 第一代：防火牆只需要知道「這個封包能不能過」 早期的防火牆，思考方式很單純：來源 IP、目的 IP、Port、Protocol——符合規則就放行，不符合就丟掉。這是一種「規則式」安全模型，工程師先定義什麼可以通過，設備負責執行。 後來攻擊越來越複雜，光看 IP、Port 已經不夠。於是開始加入 Anti-Virus、IDS、IPS、Web Filter、Application Control、Anti-Spam……慢慢形成今天所謂的 UTM。看起來像是把很多安全產品塞進同一台盒子裡，但真正的變化是：設備開始「看懂」網路流量。 第二代：從「封包」走向「行為」 再往後，資安設備開始不滿足於「這個封包有沒有病毒？」，而是開始問： ✔這個使用者在做什麼？ ✔這台電腦平常跟誰通訊？ ✔這個帳號最近是不是突然出現不一樣的行為？ 這就是網路行為分析、UEBA 等思維逐漸成熟的地方。舉例來說：某使用者平常上班時間使用 ERP、Office、Teams，但突然凌晨兩點從一台過去沒見過的裝置登入，開始大量讀取 NAS 資料，並把資料傳到從未連過的國外 IP——單看任何一件，不一定代表攻擊；把它們串起來，就開始有「故事」了。 真正有價值的資安系統，開始從「這個事件有沒有違反規則？」走向「這個行為，跟這個人平常的樣子有多不一樣？」 Palo Alto 這類產品，更早把問題往「行為情報」推 幾年前接觸 Palo Alto 的產品時，就已經看到這種思路。它不是單純把 Firewall、IPS、Application Control 一層一層疊上去，而是把使用者、裝置、App、URL、IP、流量與事件放進同一個上下文裡理解。於是設備看到的不再只是「某個 IP 連到某個 Port」，而是： 某個使用者，從某台裝置，在某個時間，以什麼方式，使用什麼應用程式，產生了什麼網路行為。 這個差別很大。因為「威脅」很多時候不是一個封包，而是一連串行為。 但行為模式從哪裡來？三層基準線... » read more

0
Read
steven
下一代 OS，不只是給人操作，也要讓 AI 理解
下一代 OS，不只是給人操作，也要讓 AI 理解

下一代 OS，不只是給人操作，也要讓 AI 理解 Mr. τ・風雲網通系統有限公司 二十幾年前，我剛入行的時候，「學會用電腦」這件事本身就是一個專業門檻。不是每個人都知道怎麼開磁碟機、怎麼打 IP、怎麼判讀錯誤代碼。 後來網路普及了，GUI 變得越來越友善，這道牆矮了一半。但對工程師來說，真正的工作仍然是那些 CLI、那些 config、那些藏在第三頁設定選單裡的參數。 現在，AI Agent 出現了。 我不是要說「AI 可以取代工程師」這種老套論述。我想說的是一件更底層的事：人類與複雜系統的互動介面，正在準備迎接第三次重構。 第一次：GUI 讓普通人也能操作機器 過去的作業系統，只有兩層溝通介面： 第一層：GUI 給人用的視覺介面。Windows 設定、NAS DSM、Router 管理介面。你看到的是「按鈕」，不需要知道背後是什麼指令。 第二層：API / CLI 給程式用的系統介面。PowerShell、Shell Script、REST API。工程師的地盤，自動化的入口。 但這兩層都有一個隱藏前提：操作者必須先知道「這個系統有什麼能力」。 你得知道功能在哪裡、工具叫什麼名字、參數怎麼填、錯誤怎麼判讀。這道「認知高牆」從來沒有消失，只是被 GUI 遮住了一部分。 第二次：API 讓程式也能操作機器 REST API 的普及，讓「自動化」成為可能。你不需要真的去點那個按鈕，只要呼叫對的 endpoint、帶對的參數，就能完成任務。 但這層也有門檻：你仍然需要先讀文件，先知道 endpoint 的名稱，先理解資料結構。程式不會「猜」，它只會「照做」。 API 解放了自動化的下限，但沒有解決「讓不熟悉系統的人也能快速上手」的問題。 第三次：AI Capability Layer — 讓 AI Agent 也能理解機器 AI... » read more

0
Read
steven
工程師思路系列・事出必有因: 當 SMART 亮紅燈，工程師看到的不只是壞掉的硬碟
工程師思路系列・事出必有因: 當 SMART 亮紅燈，工程師看到的不只是壞掉的硬碟

工程師思路系列・事出必有因 一顆硬碟的遺言 當 SMART 亮紅燈，工程師看到的不只是壞掉的硬碟 Mr. τ　|　風雲網通系統有限公司 · 2026 年 7 月 · 閱讀時間約 8 分鐘 接到電話的時候，已經是下午了。 對方是台中一家自動化機械設計公司的負責人，語氣有些急：「工程師說伺服器怪怪的，你可以過來看一下嗎？」 出門前，我把診斷隨身碟、備援硬碟、萬用電表、起子、網路線一件件放進工具箱。每次遇到這種電話，我都不知道今晚幾點回公司。路上順手買了一罐提神飲料。 到了現場，把診斷隨身碟插進前面板的 USB。沒有反應。換到後面板，才順利開機進入診斷環境。 大多數人看到的是：USB 壞了。 我看到的是：這台機器已經老化到開始出現第二層症狀了。 答案後來出來了——車程不計，現場停留時間：5 小時 13 分鐘。 SMART 亮了什麼燈 執行硬碟健康診斷後，畫面上出現了這一行： SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. 不是警告，是宣判。預計 24 小時內故障，請立即備份所有資料。 幾個關鍵數字： 22,984 重新分配磁區數（壞軌數，正常應為 0）... » read more

0
Read
steven
用 AI 協作把工程師的「工人智慧」，轉換成自動化工具
用 AI 協作把工程師的「工人智慧」，轉換成自動化工具

工程師思路系列 SpanExtract · HDD Rescue 削掉受傷的地方，剩下的還是好的 用 AI 協作把工程師的「工人智慧」，轉換成自動化工具 水果有些磕碰，削開果皮，果肉不好看。只要整體沒有腐壞，大多數人不會整顆丟掉——把瑕疵處切除，剩下的部分，仍然可以食用。 中古硬碟的道理，其實也是如此。 硬碟漲價的壓力，讓人重新看待手邊的舊硬體 最近 CPU、RAM、SSD、HDD 都在漲價。手邊累積多年的 3.5″ 與 2.5″ 硬碟，開始重新值得被認真評估。 真正壞到無法挽救的，早就拆下強力磁鐵，或是送去資源回收了。但有些硬碟的狀況並非「全死」——它們可能只是局部磁區異常、少數區域速度下降、或是邊緣扇區出現不穩定反應，整體仍有相當比例的可用容量。 問題在於：沒有一個有效的方法，把「堪用的部分」精確找出來。 以前靠工人智慧，現在想讓工人智慧變成程式 過去處理中古硬碟的流程，我一直用同一套手動方法： 1 使用 Victoria 進行全碟掃描，取得壞軌位置、延遲區域、讀取異常分布。 2 人眼綜觀掃描結果，加上磁區位置定位，以工程師的現場經驗，判斷哪些區域堪用、哪些區域必須隔離。 3 用硬碟分割工具手動建立多個分割區，分開管理堪用區與隔離區。 這套流程的核心，從來不是「掃描」。掃描只是收集資料。 真正困難的是「判斷」——而那個判斷，長期以來只存在於工程師的腦袋裡。 資深工程師看到同一份掃描報告，可以立刻判斷「這顆還能用」。但新人看到同樣的資料，不知道哪些錯誤嚴重、哪些可以接受、壞區位置代表什麼意義。 因為真正重要的知識，不在工具裡。而是在人的腦袋裡。 把判斷流程拆解，交給 AI 協助轉化成工具 這次我著手撰寫兩套工具軟體，目標就是把這整個人工流程自動化：偵測 → 掃描 → 瑕疵標記 → 分割建議 → 產出報告。 開發過程主要使用 OpenCode 推進實作。遇到架構卡關的問題，再轉給 Claude 協助審視，提出建議後交回 OpenCode 修正——這樣的協作分工，讓不同 AI... » read more

0
Read
steven
你一年花七千多元訂閱 AI，到底換來什麼？
你一年花七千多元訂閱 AI，到底換來什麼？

你一年花七千多元訂閱 AI，到底換來什麼？ 這個問題，最近很多人都在問。我自己也問過。 以前買軟體的時候，我們從來不會猶豫「值不值得」，因為那是「買東西」的思維。現在卻變成了「聘請一位數位助理」的思維，感覺完全不一樣。 第一幕：個人錢包的真實感受 幾乎每個用過電腦的人，都有一段共同記憶： ✔ 買新電腦時，Windows 是預裝的，感覺「免費」 ✔ 為了寫報告或做簡報，咬牙買正版 Office ✔ 想玩遊戲時，等特價，或者曾經接觸過非官方版本 ✔ 後來發現很多軟體可以免費下載，但總覺得功能不夠好 ✔ 再後來，開始付月費用 Adobe、Spotify、Notion、雲端硬碟…… 這些都是我們親身經歷的「付費心理轉變」。 現在，AI 成了下一個要付月費的項目。很多人卡住的原因不是錢，而是心態：我以前是買一套軟體，現在卻要持續付錢「訂閱智慧」？ 第二幕：軟體取得方式的根本改變 這正是關鍵轉折。 過去的軟體 現在的 AI 成品：開發者寫好，你付錢安裝，使用固定功能 生成工具：你給需求，它當場為你寫程式、做設計、整理資料、寫文案 賣固定產品 賣按需生產的能力 過去 GitHub、開源社群累積了大量軟體資產，但真正能修改、整合、打造新工具的人，仍然集中在少數技術族群。AI 的出現，讓「描述需求」第一次成為普遍使用者也能參與的開發入口。 從「買軟體」到「訂閱 AI 助理」，中間的心理距離，其實就是從擁有物品到擁有能力的轉變。 第三幕：科技消費模式的半世紀演進 把時間拉長來看，這不是孤立的現象，而是資訊革命一貫的模式。 每次重大技術突破，都會帶來新的「固定支出」，而這些支出最後都變成社會基礎建設： 📟 BB Call 時代：很多人覺得「有必要隨時被找到嗎？」 📱 行動電話時代：月租一千多？太貴了吧 🌐 寬頻網路時代：家裡一定要一直線上嗎？ ☁️ 雲端與串流時代：為什麼要每月付 Netflix 和 iCloud？ 🤖 AI... » read more

0
Read
steven
舊機重灌後的六項必做清單
舊機重灌後的六項必做清單

舊機重灌後的六項必做清單 工程師思路系列 ／ Mr. τ ／ 風雲網通系統 📋 這不是教學文，是現場 recovery checklist。拿到機器就照順序跑。 舊電腦重裝系統，很多人第一個念頭是「效能夠不夠用」。但實際跑現場的工程師知道：能不能「正常連線使用」才是第一關。 無論機器多老、系統多精簡，只要目標是「連線作業」，以下六件事要依序確認並處理完畢，才算真正就緒。 ① 上網 → ② 手動校時 → ③ 瀏覽器 → ④ 線上 AI → ⑤ 地端 AI → ⑥ NTP 自動校時 這台機器值得救嗎？快速判斷 在動手之前，先確認手邊的機器是否符合基本門檻。以下三個條件缺一不可： 條件 最低門檻 建議規格 CPU 年份 2011 年後 2013 年後 CPU 世代 Intel Core i 第 2 代（Sandy Bridge） Intel Core... » read more

0
Read
steven
AI 助理看不到現場：Linux 客製化的核心困境與破解展望
AI 助理看不到現場：Linux 客製化的核心困境與破解展望

工程師思路系列・事出必有因 AI 助理看不到現場：Linux 客製化的核心困境與破解展望 Mr. τ・風雲網通系統・2026 你不是不夠努力。你只是一個人，扛了不該一個人扛的事。 一、那些年，我們獨自面對的黑畫面 深夜。機器前。一整頁白字在黑色終端機畫面上靜靜燃燒。 你不確定是驅動問題、套件相依性衝突、還是這個發行版的版本差異。你查到的解法，是別人的環境、別人的套件版本、別人的硬體——不是你眼前這台機器的現場。改了一個，壞了另一個。再查，再改，再壞。 這不是技術能力的問題。這是資訊孤島的問題。 二、AI 助理出現了，但它看不到現場 AI 助理的出現，讓很多人以為問題解決了。但在 Linux 現場客製化這個場景，一道新的牆出現了——不是 AI 不夠聰明，而是 AI 根本看不到你的現場。 1 現場資訊出不來 錯誤畫面往往不只一頁。工程師能做的，只有舉起手機，對著滿屏白字拍照。拍到的是圖片，不是可以複製的文字——AI 讀圖還可能漏字或誤判關鍵訊息。 2 AI 回應進不去 手機 AI 給出的往往是成串甚至成段的指令。工程師必須把這些文字「人工搬運」回標的電腦的 terminal——一個字抄錯，全盤皆輸，一切重來。 3 資安顧慮讓選擇更少 新安裝的系統，環境未知、安全性未確認。為了不留下個人帳號足跡，不敢在標的電腦上登入 AI 助理，反而被迫改用最低效的手機模式求助。 4 語言障礙讓表達品質下降 沒有中文輸入法，使用者被迫用蹩腳英文慢吞吞描述問題。表達不完整、脈絡殘缺，AI 收到的是失真的現場描述，給出的答案自然也偏差。母語輸入不是舒適度問題，是 AI 協作品質的基礎條件。 沒人說出口的附帶代價：手機相簿裡莫名多了一堆黑底白字的終端機畫面，夾在生活照之間。忘記刪除就佔用空間，同步雲端則連備份都跟著污染。當下解決了不會去看，沒解決放棄了更不會去看——幾乎注定永遠躺在那裡。 四重障礙合起來，形成一個惡性循環：錯誤發生 → 資訊出不來（拍照）→ 語言殘缺地描述問題 → AI 回應進不去（手抄）→ 抄錯又出錯 → 再拍照…… 這不是使用者的問題。是工具的設計，還沒跟上現場的需求。... » read more

0
Read
steven
antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂
antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂

工程師思路系列 事出必有因 現場實錄 一個 Ctrl+Space，卡了一整晚 antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂 我有一台 Acer Aspire 4745G，第一代 i5，4GB RAM，說老不老，說新不新。 它的任務是跟我跑現場——去客戶公司做網路勘查，掃設備、抓封包、出報告。 為了讓這台老筆電跑得動勘查工具，我裝了 antiX 26——一個極度輕量的 Linux 發行版。 裝完之後一切都好，只剩一件事：打不了中文。 「這有什麼難的？」——我當時這樣想 在 Windows 上裝中文輸入法是五分鐘的事。Linux 嘛，查一下文件，跑幾行指令，應該也差不多吧。 結果我低估了這件事。 先裝 fcitx5，按照網路教學一步一步來，裝完重開機——Ctrl+Space，沒反應。 換 fcitx4，一樣。換 ibus，還是一樣。 三套輸入法框架，全部裝了又刪，刪了又裝，環境變數在系統裡留下一堆殘骸互相打架。 讓 Google Search AI 幫我試了四種不同版本，全都失敗。 「是不是 antiX 根本就不支援中文輸入？」 「還是我哪個步驟做錯了？」 「還是這台機器有什麼特殊問題？」 這種時候最消耗心力——不是累，是不知道問題出在哪裡，所以不知道從哪裡修。 換個工具，換個思路 後來我換了方法：不再自己亂試，而是讓 Claude Fable 5 協助我做系統性的診斷。 做法很直接——先寫一支診斷腳本，把系統狀態全部挖出來： 目前裝了哪些輸入法套件、環境變數是什麼值、Display... » read more

0
Read
steven
AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話
AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話

PCPILOT 知識中心 ── 產業觀察 AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話 從黃仁勳的水電工論,到外送與 Costco 的悖論,看懂自動化神話背後的人力本質 引言:沙漠中的金字塔 輝達執行長黃仁勳曾說過一句話,讓我反覆思考了好一陣子: AI 時代最搶手的,不是程式設計師,而是水電工;因隨著資料中心的快速增長,未來將需要數十萬名水電工和水管工。 第一次讀到這句話時,我腦中浮現的畫面,竟不是矽谷的伺服器機房,而是法老王金字塔的施工現場。 這個聯想其實一點也不荒謬。金字塔是古埃及人為永生信仰打造的終極硬體基礎設施,而今天的 AI 資料中心,則是現代人為「人工智慧」這個新神打造的終極硬體基礎設施。兩者的共同之處,在於人類把大量資源砸進一場「看不見的崇拜」——你看不到神,但看得到金字塔;你看不到 AI 的「智慧」本身,但看得到一座座吞噬電力與冷卻水的鋼鐵巨獸。 我們總以為 AI 時代是一個「去體力化、腦力至上」的時代,結果繞了一大圈才發現,真正稀缺的,反而是最古老的藍領技能。程式設計師寫完模型之後,要讓 AI 真正跑起來,靠的是電力、冷卻、管線、變電站、備援電源——這些最原始、最物理的東西。就像金字塔再怎麼神聖,最後還是得靠成千上萬人推石頭、拉繩子、抬木槓。只是石塊換成了伺服器機櫃,法老換成了黃仁勳,奴工換成了年薪可能比工程師還高的水電工。 核心對比:外送與 Costco 的悖論 這個「人力填補系統缺口」的觀察,讓我想起兩個生活中再尋常不過的例子。 案例一 外送經濟 年輕力壯的外送員,靠的是迅速響應的服務速率。這套系統把「時間」與「體力」拆解出來販售:付服務費,買的是別人的「執行速率」;選擇自取,則用自身體力與時間置換了溢價。 案例二 Costco 會員制 繳了會員費,再自己開車前往、自己揀貨、自己扛上車。零售業原本該承擔的物流成本,被悄悄轉嫁給消費者,而消費者卻心甘情願,甚至覺得划算。 外送悖論與 Costco 悖論,本質上是同一件事的兩種面貌:系統把效率包裝成自動化的神話,但底層始終靠人力填補設計留下的缺口。 範例 ── 外送服務 系統設計誘因:付費換取「時間壓縮」 人力參與形式:外送員成為即時物流節點 隱含的荒謬感:快速響應成為新階級象徵 範例 ── Costco 系統設計誘因:付費換取「低價與大份量」 人力參與形式:消費者自願成為運輸鏈一環 隱含的荒謬感:自己付錢、自己運貨、自己加油 範例 ── AI 工廠 系統設計誘因:投資換取「智慧與自動化」... » read more

0
Read
steven
我們不是花八小時修 bug，是花八小時才發現沒有 bug
我們不是花八小時修 bug，是花八小時才發現沒有 bug

PCPiLOT FIELD NOTES ✦ 數位工具開發實錄 我們不是花八小時修 bug，是花八小時才發現沒有 bug 一次 App 開發的真實除錯紀錄，以及它告訴我們關於 AI 協作、資訊可視化與決策品質的事 2026-06-25 ✦ Mr. τ／風雲網通系統 這篇文章不需要你懂程式。 它講的是一個管理者和決策者都熟悉的問題：當你的團隊花了很長時間解決一個問題，最後發現問題根本不在他們找的地方——那段時間，是怎麼浪費掉的？ 我最近第一次開發 Android 手機 App，親身經歷了這件事。過程很痛苦，但教訓很值得分享。 起點：一個真實的市場需求 台灣有超過五百萬慢性病患，他們每天面對一個沒有人幫他們解決的問題： 「站在超商貨架前，拿起一包零食，我能吃嗎？吃多少？今天已經吃太多了嗎？」 我開發的「好口福」App，就是要回答這個問題。使用者輸入身高體重和慢性病狀況，App 掃描食品標示後，給出一個簡單的顏色燈號： 🟢 安心買 🟡 注意量 🔴 地雷區 ⚫ 今日已爆 問題：一個小圖示消失了 App 的主要功能都做好了。最後一個待辦很小：在每個營養素旁邊加一個「ⓘ」圖示，讓使用者點擊後看到健康說明。 程式碼寫好了。系統檢查通過。部署完成。 但手機上，那個圖示完全不見了。 接下來的八小時 我和 AI 協作工具花了將近八小時排查這個問題。每一個假設都被否定： 假設一 程式碼沒有寫對 逐行核查後確認程式碼正確。❌ 不是這個。 假設二 手機作業系統的顯示 bug 查到真實存在的 bug 並修正，還是看不到。❌... » read more

0
Read
steven