AI 與產品：2026 Q3 - mini flow

本篇是季度的 AI 使用紀錄最後一篇，AI 日新月異，場景與流程也持續迭代。前一版本經過一季後已有許多調整，因此本文僅代表 2026 年 9 月的做法，未來仍可能大幅變動。

目錄

1. AI 與產品：我的產品工作
2. AI 與產品：2026 Q1 - 產品流水線
3. AI 與產品：2026 Q2 - AI 怎麼加速探索未知？
4. （本篇）AI 與產品：2026 Q3 - mini flow

把執行加速到最快

mini flow 這個 Side Project 約於 6 月底啟動。當時我深感每天在 cmux 中大量的 remote、local session 之間團團轉。雖然 cmux 已經分成許多層，可以顯示最新對話與通知，但層層堆疊也遇到了新的瓶頸。

回顧我自己的工作型態，我會時常在三類任務間轉換：

1. 瑣碎的執行 e.g. 確認各種需求、開發 prototype、撈數據。

2. 討論與凝聚共識 e.g. 開會、與工程師討論。

3. 較深度的產品思考 e.g. 建立模型、思考策略、撰寫 PRD。

每一次「類型級」的工作切換，都是一次大的 context switch。舉個常見情境：開會回來後，看著 terminal 中好幾個 session，我得花很多時間才能掌握剛剛做到哪裡。剛好前一陣子在研究 Multica 是否能解決此問題。但對我而言，Multica 太複雜了。它適合小型產品團隊，我用不到其中許多功能，例如 Agents Profile、Usage，更不用說團隊管理。

於是，我決定直接開發一套符合自己需求的 Kanban 系統 mini flow。它需要：

1. 能讓我一目了然每項任務所屬的專案、目前狀態、產出物，以及引用自哪些需求，好讓我在 context switch 回來後，仍能快速掌握發生了什麼事。

2. 能記錄接下來可優先處理的任務，讓 Agent 在我不在時也能持續接單作業。

簡述系統架構，mini flow 透過 tmux 啟動訂閱制的 Claude Code 與 Codex、發出指令，並單向讀取 jsonl 對話紀錄；同時顯示遠端主機正在執行的任務，統整在同一個 Kanban 中。

功能上，mini flow 支援工作項目管理、輸入與資訊查看整合，並能統一 session 操作（以下圖片皆以 mock data 呈現）：

像記錄 Triage、彙整 todo，並以 unique ticket no. 追蹤 Agent 開發狀況。

或輸入與資訊查看整合，可快速預覽 AI 產出的 HTML、Markdown 等資料，也能在輸入框中帶入圖片、文字或待發送的內容。

這個過程意義非凡：mini flow 的第一個可用版本只花 1 天完成，此後幾乎每天都能迭代一版。每個功能都在幫自己加速，而加速又回饋到工作流上，形成了打造產品時最快樂的飛輪。

同時，我也在這個過程中發現自己工作流裡的新洞見。例如，最近我替 mini flow 加上聊天室模式。因為我發現在大量 ticket 中逐一回覆時，感覺就像在工作聊天室裡不斷切換聊天對象；如果還要逐一打開卡片，思路很容易被中斷，不如像連續回覆群組訊息一樣的互動模式。

上述的 mini flow 讓我每天可處理、可追蹤的 session 數量倍增。我從未感覺自己的執行速度這麼快，快到覺得多想一點都很浪費時間……

咦？

把思考放到最慢

這不是一個好跡象。前一篇文章提到，我認為流程中存在許多「不知道」正是我的弱勢。其中有些可以透過加速執行來處理。但經過兩個季度的嘗試，我發現：也許能以歸納法或實驗解決的問題，AI 都可以加速；但對於需要演繹法的問題，AI 對我的幫助不大。

首先，雖然我嘗試將思考拆細，透過提問增加阻力，但這無助於「理解」，只帶來更多「解決」。舉例來說，規劃一個產品功能時，我可以讓 AI 透過 Skill 問我十幾個問題，再用最短時間逐一回答。然而，十幾個問題之後，我仍不理解這個功能宏觀來看是什麼、背後的原因又是什麼。也許 AI 問過，我也回答過，但理解沒有因此發生。

終究我得承認，理解可以變得更容易、但無法加速，這兩件事有所不同卻時常混淆，連結起以前研究 好奇心時提到的關懷需要時間，也呼應前陣子讀過的文章 Understanding is the new bottleneck “You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward. If you’re lacking that fluency, your ability to participate in the project is meaningfully limited.” 如果沒有理解，解決再多問題也無法推動事情前進。

因此，我得預留一段 time block，連 Agent 都不能打斷，讓自己去理解。我會打開空白的 Whiteboard 或記事，將一卡車素材丟進去，花 2、3 小時整理思考。那麼，AI 在這裡能做什麼？它可以讓理解變得容易，例如，產生更多 Explorable Explanation，像是 Nicky Case 的分享，或像是前陣子火紅的 skill eli5 換個方式說明。還有嗎？

於是，我回顧上一季作法中的 Hypothesis List，因為那仍是從「如何更快完成思考」的角度出發。我把重心轉向 Bottom Up，從執行過程中抽取素材、創造好奇的起點驚訝。第一版採用 post hook 自動化，讓 Agent 在每個 session 結束時產生一篇摘要，並送到 Heptabase。

但這些大量紀錄對我而言都是雜訊，我也不會去讀。因此，我又再次改版，調整產出素材的顆粒度與切角，設計出更細緻的機制：每個 session 會自行產出 atom 資訊，包含 signals、decision 等片段 statement，並顯示在 mini flow 的每張 ticket 中。

接著，我開發 mini cluster 服務，為這些 atoms 建立 embedding，計算彼此的相似度並聚合。當聚合到一定程度後，才會將 packet 送到 Heptabase 保存。

Packet 送到 Heptabase 後，至少目前每篇 Packet 對我而言都是更有啟發性的素材。我會定期整理 Packet，發展對新問題的想法。執行時的靈光一閃，也能成為下一輪思考的素材。

這時，我再用 Heptabase 開啟 local service mini flow，一套快與慢的思考雙迴圈體驗就此成形。

小結

這個系列連續寫了 4 季，後續不再逐季更新，收斂出幾個希望長期保持的習慣：

• 持續理解 AI 的設定，以及預設會送進 context 的檔案內容。

• 個人服務的使用率與數據追蹤同樣重要。

• 定期 review AI 讀取的資料結構與工具設定，確保資料依 MECE 原則存放。

最後，想分享一件小事：

最近我把與 AI 的對話全部改成英文，並在 mini flow 中設計一套機制，讓我可以一邊對話、一邊練習英文。它會校正我的用法並提供改善建議；如果我接受，就會儲存到另一個新服務：mini language。

這在過去難以想像。Stephen Wolfram 曾分享他日常使用的 生產力工具，是他自己打造的。以前讀到這篇文章時，我只覺得：「畢竟那可是 Stephen Wolfram 啊？」他開發了研究所需的程式語言與生產力工具。再次感謝這個時代，AI 讓我們也得以領略持續打造與改善自身生態系的奧妙。

AI 成本紀錄

• Claude Code Max 5x：主力。

• Heptabase Premium：主力。

• ChatGPT Plus：Codex 加入中。

• Google One：個人用，主要用 Google Drive & 相簿，加減玩一下 Gemini。