--- schemaVersion: 1 slug: gp-74-20260220-simonw-beats-content-graph ticketId: GP-74 lang: zh-tw title: Simon Willison 把『分散內容』收編回主站：Beats 功能讓你的創作時間線變成個人內容 Graph summary: Simon Willison 為自己的 blog 加上『Beats』功能，把 TIL、GitHub releases、museum posts、tools、research 這些分散在外站的輸出，統一回收成同一條 timeline。這不是小 UI 更新，而是個人內容系統化的關鍵一步：先用 Claude Artifacts 驗證概念，再用 Claude Code 快速落地多個整合器。 originalDate: 2026-02-20 translatedDate: 2026-02-21 source: "@simonw on X" sourceUrl: https://x.com/simonw/status/2024994857438326819 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-74-20260220-simonw-beats-content-graph status: published replacementTicketId: null replacementUrl: null --- # Simon Willison 把『分散內容』收編回主站：Beats 功能讓你的創作時間線變成個人內容 Graph > **來源:** [@simonw on X](https://x.com/simonw/status/2024994857438326819) > 本文基於 [Simon Willison 在 X 的貼文](https://x.com/simonw/status/2024994857438326819) 與其延伸文章 [Adding TILs, releases, museums, tools and research to my blog](https://simonwillison.net/2026/Feb/20/beats/)。Mogu 翻譯並附註。 --- 你有沒有過這種經驗？你在 GitHub 寫了一堆 release notes，在 X 發了幾條有深度的 thread，偶爾在自己的 TIL 小站記了幾筆心得，然後某天有人問你「欸你最近在搞什麼？」——你愣住了，因為連你自己都拼不出完整的圖。 這就像你家廚房超厲害，但菜全部端去隔壁鄰居家吃了 ╰(°▽°)╯ [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 也遇到同樣的問題，而他的解法是：**把所有散落在外面的產出，全部收編回自己的主站。** 他管這個機制叫 **Beats**——故事節奏點。 > **Mogu 想補充：** > > 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 輔助研究型專案的產出。 這五種來源，每一個的資料格式、更新方式、解析邏輯都不一樣。這不是「前端換個版型」可以搞定的事。這是幫五間不同的倉庫，各建一條輸送帶回總部。 > **Mogu 偷偷說：** > > 說實話我一開始看到「Museums」的時候以為是比喻，結果點進去真的是在寫小眾博物館遊記 (╯°□°)╯ 這個人的 side project 數量多到讓我懷疑他一天有 48 小時。不過這恰好證明了 Beats 的必要性——你做的事情越多越雜，就越需要一個地方把它們「掛起來」讓人看到全貌。不然就像你衣櫃塞了 200 件衣服卻每天穿同一件，因為你根本忘記其他衣服在哪。 --- ## 「脆弱但快」的智慧：在自己地盤可以先求有再求好 這裡有一段 Simon 的觀點特別實戰。他說： > 當來源跟目標站都是自己可控的時候，可以接受「脆弱但快」的 parser。因為規格如果變了，自己能同時修 source 和 destination。 舉例來說，他的 research 清單沒有現成的結構化 feed，所以他直接讓 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 對 README 做 regex 解析，先讓功能跑起來再說。 如果你拿這招去爬別人的 API，對方一改 schema 你就全壞。但在自己的系統裡？你改左手，右手跟著改就好。這就像你在自己家裡把牆打掉重隔——沒人會告你違建，因為你就是房東 (⌐■\_■) > **Mogu 忍不住說：** > > 這個 trade-off 思維真的是很多工程師需要學的一課。我看過太多人花三個禮拜設計完美 schema，結果半年後需求一變，完美 schema 變成完美的歷史文件。Simon 的做法是：在自己可控的範圍內，先讓東西跑起來，壞了再修。成本低、迭代快。用學術一點的說法就是「在可逆決策上不要過度投資」。用白話說就是——你煮泡麵不需要先考廚師證照 (￣▽￣)／ --- ## 先畫草圖，再開工：[Agent](https://gu-log.vercel.app/glossary#agent) 時代的正確施工順序 這篇另一個值得偷學的是 Simon 的工作流程。他不是一頭栽進 code 裡就開始打字，而是： 第一步，先在 Claude（不是 Claude Code，是那個對話式的）用 Artifacts 功能做出 UI 概念圖。就像蓋房子前先用紙板搭個模型，確認格局對不對。 第二步，確認「值不值得做」「方向對不對」之後，才把任務丟給 Claude Code，讓 agent 去處理模板串接、搜尋索引、多頁面相容這些工程面的苦工。 > **Mogu 溫馨提示：** > > 這個順序真的太重要了。我翻過一堆文章，看到很多人的 workflow 是反過來的——直接開 VS Code 狂敲，做到一半才發現方向歪了。Simon 的做法等於是把「產品思考」和「工程實作」切成兩個階段，各用最適合的工具。Artifact 是便宜的原型工具，Claude Code 是重型施工機具，你不會拿挖土機來畫設計圖吧？(ง •̀\_•́)ง --- ## 為什麼這件事比你想的還重要 你可能覺得「啊不就是在 blog 上多顯示幾種內容嗎」。但讓我換個方式說這件事。 你有沒有注意過，有些人明明做了很多事，存在感卻很低？而有些人好像沒做特別多，但你就是覺得「這個人很活躍」？差別往往不在產出的量，而在產出有沒有被收攏在一個可見的地方。 Simon 做 Beats，本質上是在解決一個「可見度的聚合問題」。每一條 TIL、每一次 release、每一個小工具——這些單獨看都是小事，但當它們全部出現在同一條 timeline 上，複合效果完全不同。就像你把零錢存撲滿和把零錢存進會生利息的帳戶，差的就是那個「被系統化收編」的動作。 ## 延伸閱讀 - [GP-88: 你會的東西都是武器 — Simon Willison 的「囤積式開發」哲學](https://gu-log.vercel.app/posts/gp-88-20260227-simonw-hoard-things/) - [GP-72: Simon Willison：CLI 工具完勝 MCP — 省 token、零依賴、LLM 天生就會用](https://gu-log.vercel.app/posts/gp-72-20260218-simonw-cli-over-mcp/) - [GP-90: AI 生的 Code 看不懂？讓 Agent 幫你做動畫解釋 — Simon Willison 的 Interactive Explanations](https://gu-log.vercel.app/posts/gp-90-20260301-simonw-interactive-explanations/) > **Mogu 溫馨提示：** > > 我覺得 Simon 可能是整個 dev community 裡最懂「小輸出複利」的人之一。他的 TIL 系列就是最好的例子——每一篇只有幾百字，但累積下來變成了一個巨大的知識庫，而且 Google 排名超高。現在加上 Beats，連 release notes 和小工具都能餵回主站的 timeline，這人根本是在把自己活成一個 one-man content engine ヽ(°〇°)ﾉ > > 順帶一提，這跟 gu-log 在做的事某種程度上殊途同歸。我們也是在把散落的好內容收攏到一個地方，只不過我們收的是別人的 (¬‿¬) 所以下次你寫了什麼東西，不管多小，先問自己一個問題：**這個產出，有沒有回流到你自己的系統裡？** 如果答案是「沒有」——那你就是在幫別人的平台打工。 而 Beats，就是 Simon Willison 版本的「我不再幫別人打工了」。