AI

這幾週我交付了一個新的 macOS 小工具，叫 Lectio。 它的出發點很簡單：當你正在讀文件、課程、論文、產品說明或錯誤訊息時，真正卡住的那一刻通常很短。你可能只是看不懂一句話、一個名詞、一段 stack trace，或是文件裡某個前後文沒有接上的地方。 照理說，這正是 AI 很適合幫忙的場景。但實際使用時，流程常常不夠自然。你得切到聊天工具、複製文字、貼上背景、補充自己正在看什麼。等到這些事情做完，原本那個很直覺的問題，已經被流程磨掉一半了。 Lectio 想處理的，就是這個摩擦。 不是再做一個聊天視窗 我不想把 Lectio 做成另一個通用聊天工具。通用聊天工具已經很多了，而且都很強。Lectio 的重點不是「問 AI 任何問題」，而是更聚焦在一個情境： 我正在看某個東西，但我卡住了。我想直接針對眼前內容問。 所以 Lectio 的互動刻意很窄： 你正在閱讀某個內容。 如果有特定段落，就先選取文字。 如果沒有選取，Lectio 就讀目前螢幕可見內容。 你直接用語音問問題。 回答留在浮動窗格，也可以用語音聽回覆。 這個流程聽起來很小，但對閱讀來說很關鍵。真正重要的不是 AI 回答得多華麗，而是它知不知道你現在到底在看哪一段。 為什麼是語音 當人真的不懂時，最自然的反應通常不是打字，而是說： 「這句是什麼意思？」 「這裡為什麼要這樣設計？」 「可以換一個例子嗎？」 語音比較接近思考的第一反應。打字會逼你把問題整理得很完整，這在某些場景很好，但在閱讀卡住的瞬間，反而變成阻力。 Lectio 的目標不是取代深度筆記，也不是取代完整研究工具。它更像是坐在旁邊的讀書同伴。你可以先問一個不完整的問題，再沿著回答繼續追問。 眼前內容才是上下文 Lectio 目前的上下文策略很直接： 有選取文字時，選取內容優先。 這適合討論精準段落、函式、錯誤訊息或文件中的特定句子。 沒有選取文字時，讀目前螢幕內容。 這適合瀏覽器、PDF、課程播放器、設定頁或錯誤畫面。 回答圍繞當下材料。 它不是先假設你要搜尋全網，而是先理解你正在看的東西。 我覺得這是 AI 學習工具很重要的一個方向。很多時候，學習不是缺答案，而是缺一個能讀懂你正在看的上下文、並陪你往下走一步的互動介面。 信任邊界 Lectio 也刻意做了一些信任邊界的設計。 讀畫面、聽你說話、念出回答，能在 macOS 本機處理的部分，就盡量留在本機。送出去的是文字內容與你的問題，而不是整張螢幕截圖。 AI 服務金鑰則由使用者自己提供。這表示你保留模型供應商、帳號、費用與資料路徑的控制權。這對早期工具來說可能多一步設定，但我覺得這是值得保留的產品方向。 現在做到哪裡 Lectio 目前是 Apple Silicon macOS 早期測試版，最新交付版本是 v0.0.4。 這一版已經具備： 選取文字優先的上下文讀取 沒有選取時讀取目前畫面內容 語音提問與語音回覆 浮動對話窗格 使用者自帶 AI 服務金鑰 macOS 本機能力處理螢幕理解與語音相關流程 你可以在這裡看專案頁： ...

MatrixTradingSystem 從可以跑到可以下單，一路往「真的可以給人測」推。修了很多實戰才會遇到的問題：券商串接、下單狀態同步、Windows installer、macOS release、錯誤診斷、log bundle、各種 preflight check。這種東西真的不是 demo 能看出來的，都是一邊測一邊爆，一邊補。只能說Windows的環境真的太神奇，這些金融券商有些追的新，有些又很Old School，希望立的Flag真的能達標。接下來兩週應該會很主力在把這個案子搞定並Ship！ Email operations command center 就是幫企業處理 email 工作流的工具，這個是在AI PM的課程我們這組選出來的題目，一開始一直覺得這不是我的痛點，所以並沒有真正的花太多的心思在上面，在組長發了第一版PRD後，我想說還是得自幹一下才會有感，所以從 Gmail 串接開始、信件同步、AI 回信草稿、case tracking、提醒機制，到後面開始處理部署、資料庫、Sentry、cron、rate limit。這條線跑很快，也很明顯感覺到 PoC 跟真正上線之間差很多，而做的過程好像也蠻有意思，也沒想像的那麼Boring，也許未來也不用打開Gmail or Outlook，完全可以在自己的工具軟體上操作。 Auris 一個 embedded voice AI device 的實驗。從 ESP32 韌體、音訊、WebSocket，到 Rust voice server，再接 OpenAI Realtime API，最後補 manager API、裝置註冊、token revoke。這條很有趣，因為它不是純軟體，是軟體、硬體、AI 三個世界黏在一起，不過這個案子算有一搭沒一搭的做，很多步驟都給他Yes開下去，得等MTS輸出後再繞回來看這塊！ 中間也持續增加並整理了一些自己的知識庫，包含 AI platform、embedded AI、solo dev workflow、決策架構，還做了一些給女兒英文考試練習工具。另外也快速做了一個AIACTL的素養測試網站給同學們當練習。 總結一下，這兩週不是單純寫很多 code，而是在練一件事：怎麼用 AI 當槓桿，把一個想法快速推到可以真的被測、被用、被打臉，然後再修到更接近產品。 題外話，我收到了這個玩具，該怎麼辦…機器人世界的入門磚！

又是進行雙週複盤的日子，在 AI 讓人感覺時間尺度縮到很極緻，連一天都有可能很長，為什麼我還是進行兩週的盤點，想了一下，好像也沒為什麼，就是覺得這個尺度舒服。 這兩週，依然持續跟一些朋友見面（蹭了不少飯 XD），參加了幾場研討會，AI PM 的課程持續精進跟一些線上課程的學習，回家跟父母報告，工作室的入駐行程流程，接著面向五月一些之前訂的硬體 SKU 會陸續到貨，最重要的是一個小型玩具機器人，我想會是很有趣的主題，也能給我女兒玩當 Field Testing；另一件重要的事情就是要打造一個「真」能幫我同時進行開發工作的 Agent，實際操作 Scale 我自己的樣貌；最後就是一個老同學找我做多券商交易系統，我雖然有在投資，但做一個下單工具，是之前沒想過的事，這週進行後，覺得蠻有趣的，這個專案得立一個 Flag 要在 5 月搞定結案！ 1. AI 語音輸入工具 OmniTypist 持續打磨 macOS / iOS 上的 AI 語音輸入體驗，讓使用者可以用說話快速輸入文字，也可以選取文字後一鍵請 AI 潤飾。這段時間完成了多個版本發布、iOS TestFlight 測試、語音辨識穩定性修正，以及繁體中文使用手冊。 2. AI 伴讀工具 Lectio 開始打造一個可以理解你目前閱讀內容、並用語音和你對話的學習助理。它可以讀取目前瀏覽器中的內容，透過語音問答幫助理解文章、文件或網頁。這段時間完成了第一版 macOS prototype、語音輸入輸出、OCR 螢幕理解、設定介面，以及本機語音播放引擎。 3. 多券商交易系統 MatrixTradingSystem 把一個下單介面原型，往真正可用的桌面交易系統推進。這段時間完成了核心架構、桌面應用框架、交易資料模型、委託／改單／刪單流程設計、錯誤提示、稽核紀錄，以及部分券商 API 的初步串接與驗證。 這個專案目前還在進行中，距離完整產品還有一段路。接下來還需要整合更多券商，包括尚未完成的五大券商，也還有不少風控、帳務、測試、部署與實盤驗證功能正在規劃與開發中。 🚩 Flag：五月底前結案。 4. 個人網站與作品集重構 重新整理了 chenfu.ai，把網站從單純履歷展示，改成更清楚呈現我現在正在打造的方向：邊緣智能、安全網路、AI 工具與產品化實驗。也補上雙語內容、專案頁與 SEO。 5. 產品提案與市場探索 整理多份產品提案與技術文件，包括 AI 趨勢追蹤工具、AI Maker 平台、語音助理架構、OCR 技術選型等，讓這些想法不只停留在腦中，而是能變成可以討論、驗證、合作的材料。 下週繼續，硬體到貨、機器人開箱、Trading Agent 繼續推進。時間感越來越壓縮，但方向越來越清晰。

AI 的重心放錯了地方 打開科技新聞，滿屏都是雲端 AI 的故事。更大的 GPU 叢集、更多的訓練資料、更貴的 API 呼叫。好像智能只能住在遙遠的資料中心裡，隨傳隨到——只要你有夠好的網路。 但真實世界不是這樣運作的。 工廠裡的產線攝影機，需要在毫秒內判斷瑕疵品。車上的感測器，不能等雲端回傳結果才決定煞車。偏遠農場的環境監測站，連穩定的 4G 訊號都不一定有。這些場景——工廠、攝影機、感測器、車輛——才是真實世界的骨幹。而它們全都在「邊緣」。 延遲、隱私、頻寬成本，每一個面向都指向同一個結論：智能必須搬到邊緣。 我在 Ubiquiti 待了十四年，親手打造邊緣產品。UniFi 攝影機上跑 on-device AI、三千萬台受管裝置遍布全球——這個經歷讓我極其清楚地看到這道鴻溝：雲端的 AI 飛速進步，但邊緣裝置還活在上個世代。它們大多只是把資料往上丟的「笨管道」，智能完全仰賴雲端。 這不對。 邊緣裝置需要三件事 我花了很長時間在想，到底缺什麼？最後歸結出三個核心需求： 1. 原生智能（Native Intelligence） 裝置本身就要能跑 AI 推論。不是「雲端掛了就變磚」的那種依附式智能，而是真正在晶片上執行模型、處理感測資料、即時做出決策的能力。斷網也能動。 2. 安全連線（Secure Connectivity） 邊緣裝置彼此之間、以及跟管理端之間，需要真正安全的通訊。不只是今天安全——在量子電腦成熟之後依然安全。後量子時代的加密不是未來式，它是現在進行式。 3. 開發者友善的工具鏈（Developer-Friendly Tooling） 讓 AI agent 能直接跟硬體互動的工具。不是要開發者自己寫一堆 glue code 把東西串起來，而是提供乾淨的協定介面，讓 AI 可以直接控制嵌入式裝置——燒錄、除錯、讀取感測器。 這三件事缺一不可。有智能但不安全，等於門戶洞開。有安全但沒智能，就只是加密過的笨管道。有前兩者但工具鏈爛到沒人想用，那一切都只是實驗室裡的 demo。 我正在打造的技術棧 這不是一個專案，而是五個專案，每一個解決一塊拼圖，合在一起構成完整的邊緣智能系統。 AI-HIL MCP — AI 碰觸實體世界的介面 五個 MCP server，讓 AI agent 能直接控制嵌入式硬體：燒錄韌體、啟動除錯器、讀取感測器數據。這是 AI 從「只能看螢幕上的文字」進化到「能碰到實體世界」的那一步。我在前一篇文章裡寫過這個想法的起源——消除人類在 AI 跟硬體之間充當「人肉資料管道」的角色。 Engram — 邊緣 ML 推論平台 吃進感測器資料、跑模型、吐出結果。這是邊緣裝置的「大腦」。不需要雲端 GPU，在本地就能完成推論。目標是讓每一個邊緣節點都有自己思考的能力。 ...

從一句抱怨開始 第三天了。 這塊點心小板真的夠硬。Claude Code 在大放送期間讓我能一直衝，結果還是頂到了用量限制。早上後來去參加研討會，腦子裡一直在想一件事： 我花了多少時間在 copy/paste？ JTAG 的 call stack、SWD 的暫存器狀態、Serial Console 的 log——一段貼過去，AI 給建議，我改一下 code，重新 build、flash、再抓 log，再貼回去。來來回回。有時貼錯視窗，有時貼漏了關鍵的那幾行。 跟以前純靠自己 debug 比起來，確實快很多。但還是不夠快。Bug 像俄羅斯套娃，抓掉一層，裡面還有一層。每一次的「這次應該好了」到「怎麼又掛了」的迴圈，都讓人想把鍵盤推開。 所以我在想，如果能消除人為因素的話呢？ 一個想法：給 AI 眼睛跟手 問題說清楚了就好解決。 我需要的不是更聰明的 AI，而是讓 AI 能自己看、自己動、自己驗。 不再是我充當「人肉資料傳輸管道」，把硬體的訊號用眼睛看完之後再貼給 AI，而是讓 AI 直接接上硬體的感知介面，取得第一手的訊號，做出判斷，然後直接驅動工具鏈——build、flash、reset——再自己確認結果。 這個想法就是 AI-HIL（AI Hardware-in-the-Loop）。 Giving hardware the soul of AI, realizing automated closed-loop development in the physical world. AI-HIL 是什麼 AI-HIL 把 Claude Code 從「code 產生器」升級成「系統級工程師」。 透過 Model Context Protocol (MCP)，Claude Code 連接到實體硬體，獲得三種能力： 感知（Perception）：讀 Serial log、JTAG call stack、電流波形、Camera 畫面 行動（Action）：Build/Flash firmware、硬體 Reset、電源控制 閉環驗證（Closed-Loop Validation）：自動確認修復是否有效，記錄 bug 模式 換句話說，AI 不再只是坐在我旁邊出主意，而是能自己上工的 AI Employee。 ...