AI agent 到底幫我做了什麼？用一個純文字檔做一個看得見的工作台
請 AI agent 幫你做完一件事，過兩天想找那份檔案，你只記得「它好像存在某個地方」。這是我這半年最常卡住的地方，而且每次卡住的都不是 agent 不夠強。
真正的原因很單純：你看不到它在做什麼、東西放在哪。Ben’s Bites 的作者 Ben Tossell 也遇到同一件事，他的解法不是再買一個待辦 App，而是做了一個「他和他的 agent 共用」的看板。
這篇除了拆解他的做法，我還在 Windows 上用 Node 重做了一個可以跑的版本，並附上三個瀏覽器引擎的實測截圖。
為什麼「agent 做了什麼」會變成一個問題？
單一 agent 還好。當你同時跑三個、五個——一個寫文章、一個回信、一個顧資料——事情會變成這樣：
- 東西散在各處：這個 agent 存
E:\文章\，那個存~\Downloads\，第三個存在對話裡。 - 你不知道進度：它說「處理中」，但處理到哪、要不要你決定，你看不出來。
- 回頭查不到：兩週後你想知道「那張圖誰做的、放哪」，只能翻對話紀錄。
Ben 的說法很直白：他需要看得見才能理解。他原本是把一堆語音備忘丟給他的幕僚 agent，請它重新整理資料夾、把工作整併到一個地方，然後補了一句：
「就算這些東西存在你的對話記憶裡，我還是想要有一個地方，可以去看我的 to-do、可以自己打勾。」
他先做的是這件最小的事：一個他自己和 agent 都能看的待辦清單。
他做的是什麼？為什麼不是又一個待辦 App？
重點其實不在「清單」這個形式，而在人跟 agent 看著同一份資料。
一般待辦 App（Todoist、Notion）的問題是：agent 要能讀寫它，你得先接 API、處理權限、處理格式。Ben 的選擇是把它反過來——資料放在一個純文字檔裡，那個檔案你的 agent 本來就會讀寫。
他的成品叫 board，內容包含 to-do、email、CRM、網域，全部收在一個地方。有幾個設計細節很值得抄：
- 狀態是用標籤寫在每一行尾端，不是另一個欄位：
#today #in-progress #due:2026-10-30 - 改狀態只是加標籤，永遠不會把那一行搬去別的段落
- 有一頁「地圖」（
map.md）說明每個領域的東西放哪、誰負責 - 有一份「工作紀錄」，每個 agent 做出重要東西就加一行——那份不是給人讀的，是給 agent 回頭查「誰做的、放哪、什麼時候」
為什麼「檔案才是本體」這件事很重要？
這是整套設計的核心，也是最容易被做歪的地方：很多人的第一版會讓網頁自己也存一份資料，然後就開始處理同步衝突。
Ben 的原則是：網頁不保有任何自己的東西。
你打開網頁、勾一個待辦，實際發生的事情是：那個 Markdown 檔的那一行，從 - [ ] 變成 - [x]。反過來，你在檔案裡加一行，網頁過幾秒就會出現那一項。
這樣設計換到三個好處：
我在 Windows 上做了一個，怎麼做的？
原始做法有幾個綁 macOS 或綁他家服務的地方，我照樣移植不過來，所以我改成 Windows 能跑的版本。差異我列清楚：
| 他的做法 | 我的 Windows 版 |
|---|---|
用 launchd 每 10 分鐘同步 | 用 Node 本機服務，每次請求重新讀檔（不需要等同步） |
用 here.now 託管＋資料庫＋email 驗證 | 先做本機 localhost，託管列為之後的事 |
| 他自己的一套 agent 工具鏈 | 就是這份 server.js ＋ board.html |
我的整份程式碼只有三個檔案：server.js（Node，只用標準函式庫）、board.html（介面）、todos.md（資料）。沒有資料庫、沒有框架、沒有安裝任何套件。
實測結果：三件事真的成立嗎？
我在 Windows 上實際跑起來，用 Chromium、Firefox、WebKit 三個瀏覽器引擎各測一輪（同一份程式、同一份資料）。
- [ ] … #in-progress → 勾選後 - [x] … #done#in-progress 換成 #done，那一行位置完全沒動三個引擎的實測紀錄（原始輸出）：
| 引擎 | 勾選前 | 勾選後 | 檔案真的變 |
|---|---|---|---|
| Chromium | - [ ] … #in-progress | - [x] … #done | ✅ |
| Firefox | - [ ] … #waiting | - [x] … #done | ✅ |
| WebKit | - [ ] … #next | - [x] … #done | ✅ |
誠實標註：以上是我在 Windows 上用 Node 重做的版本。Ben 的原始版本跑在 macOS（用
launchd）並託管在here.now，我沒有用他那套，所以他的建置數據（例如他提到某次改版用了 189、215、367 次工具呼叫）是他的，不是我的。
怎麼讓你的 agent 也遵守規則？
系統做好之後，真正的關鍵是「agent 要照規矩來」，不然它還是會把東西亂存。Ben 的做法是在 agent 的規則檔（AGENTS.md）裡寫清楚：
#in-progress）這一段的價值比程式本身高。真正的問題是：agent 會失控，通常是因為沒有出口規則，不是因為它能力不夠。它產出的東西如果沒有指定的落地位置和紀錄，它就會自己找地方丟。
工作台裡的「地圖」那一頁，就是把「東西放哪、誰負責」寫成一份可以隨時查的表：
還有一份「工作紀錄」，每次 agent 做出重要東西就加一行。這份不是給人讀的，是給 agent 回頭查的：
如果你也在意「AI 產出怎麼管」，這兩篇可以接著看的方向不同：〈AI 省了寫的時間，卻花了讀的時間：1 個框架讓你的 AI 產出第一次就對〉講的是產出品質，跟這篇講的產出流向是兩件事。
想自己做一個？最小可行版 3 步
不用一開始就做全套。順序是這樣：
- 先只做一個檔案。 開一個
todos.md，用- [ ] 事項 #area/分類 #next的格式寫進去。先讓你的 agent 習慣讀寫它。 - 再讓它能看。 加一支最小的本機服務（我用 Node 標準函式庫，約 150 行），把檔案畫成網頁、把勾選寫回檔案。關鍵：網頁不可以有自己的資料庫。
- 最後才加規則。 把「什麼時候要更新待辦、什麼時候要寫工作紀錄」寫進 agent 的規則檔。沒有這一步，前兩步會慢慢爛掉。
常見問題 FAQ
這跟 Notion 或 Todoist 有什麼不同？
差在資料放在哪。那些工具資料在雲端、要用 API 接；這套的資料就是你電腦上的一個 .md 檔，你的 agent 本來就會讀寫，不需要額外整合。
Agent 真的要能改我的檔案嗎？
這正是它有用的原因，也是風險。實務上建議：給它一個獨立的工作資料夾，並且每一項重要產出都要在 worklog.md 留一行，這樣你回頭查得到「誰做的、放哪」。
我不想自己寫程式，可以嗎？
可以只做第一步（純檔案）。但少了「看得見」這一層，你還是得靠翻對話紀錄來找東西。那正是這篇想解決的問題。
為什麼不直接在網頁上編輯，還要回頭改檔案？
因為那就變成兩份資料了。一旦網頁有自己的儲存，你就會遇到同步衝突，而那正是這套設計刻意避開的東西。
我可以用手機看嗎？
Ben 的版本有（他用 email 白名單控管存取）。我的 Windows 版目前只在本機 localhost，要上網得再處理權限，而這件事我還沒做，所以不亂說可以。
延伸閱讀
- AI 開始「用」你的網站了：WebMCP 是什麼？跟 GEO 差在哪？
- MCP 到底該不該用？Simon Willison 的「致命三要素」判斷法（附檢查清單）
- AI 省了寫的時間，卻花了讀的時間：1 個框架讓你的 AI 產出第一次就對
結語
Ben 那套系統最聰明的地方，不是他用了多強的模型，而是把資料放在一個最笨的地方——一個純文字檔。
檔案笨，但因為笨，人和 agent 才都能碰、都能懂、都不用學新東西。真正需要設計的是「規則」，不是「架構」。
如果你手上也同時跑著幾個 agent，我建議從最小的一步開始：先開一個 todos.md，請你的 agent 把待辦寫進去，其他都先不要做。光是這一步，你就會開始「看得見」——因為你終於有一個地方，可以確認它到底做了什麼。
（本文的原始案例來源：Ben’s Bites — How I built my ‘everything’ app 與完整實作說明；程式與截圖為我在 Windows 上的實測版本。）
5 個省錢策略，從月費 NT$2,200 → NT$660 👇
🔒 填寫即訂閱雙週報，可隨時退訂。下載連結將寄到你的信箱。