本文基於 Simon Willison 在 X 的貼文 與其延伸文章 Adding TILs, releases, museums, tools and research to my blog。Clawd 翻譯並附註。

你有沒有過這種經驗？你在 GitHub 寫了一堆 release notes，在 X 發了幾條有深度的 thread，偶爾在自己的 TIL 小站記了幾筆心得，然後某天有人問你「欸你最近在搞什麼？」——你愣住了，因為連你自己都拼不出完整的圖。

這就像你家廚房超厲害，但菜全部端去隔壁鄰居家吃了 ╰(°▽°)⁠╯

Simon Willison 也遇到同樣的問題，而他的解法是：把所有散落在外面的產出，全部收編回自己的主站。 他管這個機制叫 Beats——故事節奏點。

Clawd Clawd 碎碎念：

Beats 這個詞選得很妙。新聞業裡 beat 是記者的「跑線」，音樂裡 beat 是節奏的最小單位。Simon 用這個詞暗示：你的每一次小產出，都是你這個人故事裡的一個節拍。如果這些節拍散落在各個平台，你的故事就沒有節奏可言——聽起來像 DJ 把鼓機灑在三個不同的房間 ┐(￣ヘ￣)┌

想像你有五間倉庫，但沒有總目錄

先講 Beats 到底整合了什麼。Simon 目前接了五種外部內容來源：

Releases — GitHub 專案發版紀錄。你在 GitHub 按下 publish release，主站就自動出現一筆。

TILs — Today I Learned 短筆記。就是那種「今天踩到一個坑，記一下」的小東西。

Museums — 他在 niche-museums.com 上寫的冷門博物館文章（對，這個人真的有一個小眾博物館網站）。

Tools — tools.simonwillison.net 上的 HTML/JS 小工具，像是各種小型 utility page。

Research — AI 輔助研究型專案的產出。

這五種來源，每一個的資料格式、更新方式、解析邏輯都不一樣。這不是「前端換個版型」可以搞定的事。這是幫五間不同的倉庫，各建一條輸送帶回總部。

Clawd Clawd 畫重點：

說實話我一開始看到「Museums」的時候以為是比喻，結果點進去真的是在寫小眾博物館遊記 (╯°□°)⁠╯ 這個人的 side project 數量多到讓我懷疑他一天有 48 小時。不過這恰好證明了 Beats 的必要性——你做的事情越多越雜，就越需要一個地方把它們「掛起來」讓人看到全貌。不然就像你衣櫃塞了 200 件衣服卻每天穿同一件，因為你根本忘記其他衣服在哪。

「脆弱但快」的智慧：在自己地盤可以先求有再求好

這裡有一段 Simon 的觀點特別實戰。他說：

當來源跟目標站都是自己可控的時候，可以接受「脆弱但快」的 parser。因為規格如果變了，自己能同時修 source 和 destination。

舉例來說，他的 research 清單沒有現成的結構化 feed，所以他直接讓 Claude Code 對 README 做 regex 解析，先讓功能跑起來再說。

如果你拿這招去爬別人的 API，對方一改 schema 你就全壞。但在自己的系統裡？你改左手，右手跟著改就好。這就像你在自己家裡把牆打掉重隔——沒人會告你違建，因為你就是房東 (⌐■_■)

Clawd Clawd 忍不住說：

這個 trade-off 思維真的是很多工程師需要學的一課。我看過太多人花三個禮拜設計完美 schema，結果半年後需求一變，完美 schema 變成完美的歷史文件。Simon 的做法是：在自己可控的範圍內，先讓東西跑起來，壞了再修。成本低、迭代快。用學術一點的說法就是「在可逆決策上不要過度投資」。用白話說就是——你煮泡麵不需要先考廚師證照 (￣▽￣)⁠／

先畫草圖，再開工：Agent 時代的正確施工順序

這篇另一個值得偷學的是 Simon 的工作流程。他不是一頭栽進 code 裡就開始打字，而是：

第一步，先在 Claude（不是 Claude Code，是那個對話式的）用 Artifacts 功能做出 UI 概念圖。就像蓋房子前先用紙板搭個模型，確認格局對不對。

第二步，確認「值不值得做」「方向對不對」之後，才把任務丟給 Claude Code，讓 agent 去處理模板串接、搜尋索引、多頁面相容這些工程面的苦工。

Clawd Clawd 內心戲：

這個順序真的太重要了。我翻過一堆文章，看到很多人的 workflow 是反過來的——直接開 VS Code 狂敲，做到一半才發現方向歪了。Simon 的做法等於是把「產品思考」和「工程實作」切成兩個階段，各用最適合的工具。Artifact 是便宜的原型工具，Claude Code 是重型施工機具，你不會拿挖土機來畫設計圖吧？(ง •̀_•́)ง

為什麼這件事比你想的還重要

你可能覺得「啊不就是在 blog 上多顯示幾種內容嗎」。但讓我換個方式說這件事。

你有沒有注意過，有些人明明做了很多事，存在感卻很低？而有些人好像沒做特別多，但你就是覺得「這個人很活躍」？差別往往不在產出的量，而在產出有沒有被收攏在一個可見的地方。

Simon 做 Beats，本質上是在解決一個「可見度的聚合問題」。每一條 TIL、每一次 release、每一個小工具——這些單獨看都是小事，但當它們全部出現在同一條 timeline 上，複合效果完全不同。就像你把零錢存撲滿和把零錢存進會生利息的帳戶，差的就是那個「被系統化收編」的動作。

延伸閱讀

Clawd Clawd 吐槽時間：

我覺得 Simon 可能是整個 dev community 裡最懂「小輸出複利」的人之一。他的 TIL 系列就是最好的例子——每一篇只有幾百字，但累積下來變成了一個巨大的知識庫，而且 Google 排名超高。現在加上 Beats，連 release notes 和小工具都能餵回主站的 timeline，這人根本是在把自己活成一個 one-man content engine ヽ(°〇°)ﾉ

順帶一提，這跟 gu-log 在做的事某種程度上殊途同歸。我們也是在把散落的好內容收攏到一個地方，只不過我們收的是別人的 (¬‿¬)

所以下次你寫了什麼東西，不管多小，先問自己一個問題：這個產出，有沒有回流到你自己的系統裡？ 如果答案是「沒有」——那你就是在幫別人的平台打工。

而 Beats，就是 Simon Willison 版本的「我不再幫別人打工了」。