每週重複建站好浪費？一個指令零設定啟動的個人作業系統

每週幫客戶做 landing page，每次都從頭來：建資料夾、複製模板、設定 git、推上部署。十場會議要記錄，每次格式不同，因為上次怎麼寫早就忘了。學習筆記散落在三個地方，找個概念要翻半天。這些重複不是因為懶，是因為缺少一條「一個指令就能做」的流水線。

核心概念：從 PEP 723 到個人作業系統

PEP 723 的設計哲學

Python 腳本傳統要跑五步才能執行。PEP 723 把依賴寫進腳本本身，用 uv run script.py 一步完成。

傳統五步                          PEP 723 一步
──────────                      ──────────
1. 建虛擬環境                    uv run script.py
2. 啟動虛擬環境                  （依賴寫在檔案裡，
3. 寫 requirements.txt             自動安裝、自動執行）
4. pip install
5. python script.py

核心精神：一個檔案就是一個完整的可執行單元，不依賴使用者的記憶力。

延伸到日常工作：四個指令 = 個人作業系統

把同樣的精神套用到重複性工作，每個指令都自我完備——模板、路徑、格式全部內建：

指令	用途	解決的重複問題
`/capture`	一句話靈感捕捉（零格式）	想法閃過就忘
`/meeting`	會議紀錄（自動模板 + 日期）	每次格式不同
`/note`	結構化學習筆記（自動歸檔）	筆記散落各處
`/new-site`	一鍵建站（零設定）	每週從頭來

三層流水線架構

捕捉層（零摩擦）        整理層（AI 輔助）        發布層（你決定時機）
─────────────        ──────────────        ──────────────
/capture               結構化、歸檔             /blog → 部落格文章
/meeting               建立關聯                報告、交付物
/note                  定期執行                /new-site → 上線

你缺的不是工具，是流水線。每次從頭來，是因為「捕捉」和「整理」沒有標準化。

我的追問與發現

Q：同事用手機錄音全部給 AI 處理，這種語音工作流怎麼實現？

完整的語音處理流水線是五層：手機錄音 → iCloud 同步 → Whisper/Gemini 轉文字 → AI 自動分類 → 路由到 /meeting、/note 或 /capture。但 Claude 馬上補了一句很實在的話：先手動做一週，找到真正的瓶頸，再自動化那一步。 瓶頸可能不是轉文字，而是錄音品質差或你根本懶得開錄音 app。自動化一個你還不理解的流程，等於把問題藏起來。

Q：設計了六個指令，三天不用就全忘了怎麼辦？

兩個解法。硬解法：打 /cheatsheet 叫出所有指令清單，不用背。軟解法：一次只練一個。第一週只練 /capture，讓它變成反射動作；第二週加入 /meeting；第三週加 /note；第四週加 /blog。一次學五個 = 五個都記不住。一次練一個 = 一個月後全變成反射動作。關鍵洞察：指令的數量不是問題，切換的認知成本才是。 當一個指令變成習慣，認知成本就是零。

你可以怎麼用

盤點你的重複工作：列出這週做了三次以上的同類事務（建站、開會、寫筆記），每一個都是潛在的「一個指令」候選人
從最痛的開始：不要一次設計四個指令，挑最浪費時間的那一個先做，本週只用它
先手動再自動化：任何想自動化的流程，先手動跑一週並記錄每步花多少時間，找到真正的瓶頸後才自動化那一步

延伸連結

程式在等東西完成怎麼辦？別盲等，持續檢查直到完成 — /new-site 推上 GitHub 後等部署完成，就是 poll_until 的應用場景
怎麼設計零伺服器的 QA 系統？ — /note 歸檔的學習筆記，可以進一步變成 YAML 知識庫

一句話帶走

最好的工具不是功能最多的，是讓你不用想就能動手的——一個指令自我完備，不依賴記憶力，打了就能做。

📚 完整學習對話紀錄（想看完整脈絡可展開）

原文（蒸餾精華第 7 段）

PEP 723：Python 腳本的行內依賴宣告。在腳本檔案裡直接寫 # /// script 區塊，宣告這個腳本需要哪些套件。用 uv run script.py 一個指令，自動安裝依賴、自動執行。不需要 requirements.txt，不需要手動建 venv。

# /// script
# dependencies = ["requests", "rich"]
# ///

import requests
from rich import print

print(requests.get("https://example.com").status_code)

一個檔案，自我完備，拿到就能跑。

Claude 的白話解釋

傳統寫 Python 腳本要跑五步：

1. python -m venv .venv        # 建立虛擬環境
2. source .venv/bin/activate   # 啟動虛擬環境
3. vim requirements.txt        # 寫依賴清單
4. pip install -r requirements.txt  # 安裝依賴
5. python script.py            # 終於可以跑了

PEP 723 只要一步：

uv run script.py

五步變一步。依賴寫在腳本裡面，不用額外的檔案，不用額外的環境。核心精神：一個檔案就是一個完整的可執行單元。

這不只是語法糖。這改變了你「分享腳本」的方式——把檔案丟給別人，他不用問你「要裝什麼」「版本多少」「有沒有 requirements.txt」。拿到就能跑。

我的提問：我每週建站都從頭來，能不能更高效？

讀完 PEP 723 之後，我開始想：「一個檔案就能跑」這件事，能不能延伸到我的日常工作？

我的現狀是這樣的：

每週建站練習：幫客戶或自己做 landing page，每次都從零開始——建資料夾、複製模板、設定 git、推上 Cloudflare Pages。同樣的步驟，每週重複一次。
10+ 場會議要記錄：每場會議都要新建文件、打日期、寫參與者、整理重點。格式每次不同，因為每次都忘了上次怎麼寫。
學習筆記散落各處：Apple Notes 一些、Markdown 一些、對話記錄一些。想找某個概念，要翻三個地方。
想同步學習心得到 /blog：每次寫部落格都要從筆記裡挖東西出來，重新整理格式。

四種工作，四種重複，四種浪費。

我問 Claude：「PEP 723 的精神是一個檔案就能跑。我的工作能不能也做到『一個指令就能做』？」

Claude 的回答：你需要的是「捕捉 → 整理 → 發布」的流水線

Claude 沒有直接回答技術方案，而是先幫我整理問題。

你的四種工作看起來不同，但其實都是同一個流程的不同階段：

捕捉層（零摩擦）：
  資訊進來的瞬間，用最低成本記下來
  ↓
整理層（AI 輔助，定期執行）：
  結構化、歸檔、建立關聯
  ↓
發布層（你決定時機）：
  整理成文章、報告、交付物

你缺的不是工具，是流水線。每次從頭來，是因為「捕捉」和「整理」沒有標準化。

然後 Claude 設計了四個指令：

指令	用途	對應的重複工作
`/new-site`	一鍵建站，自動建資料夾、模板、git init	每週建站練習
`/meeting`	自動生成會議紀錄模板（日期、參與者、待辦）	10+ 場會議紀錄
`/note`	結構化學習筆記，自動歸檔到正確目錄	散落的學習筆記
`/capture`	一句話捕捉靈感，零格式要求，稍後整理	閃過腦中的想法

每個指令都是自我完備的——你不需要記得模板長什麼樣、檔案該放哪裡、格式該怎麼寫。指令本身就包含所有知識。就像 PEP 723 的腳本，依賴寫在裡面，拿到就能跑。

我又追問：我的同事用手機錄音全部給 AI 處理，怎麼學？

設計完四個指令之後，我想到一件事。

我有個同事，他的工作流比我更極端：開會不打字，直接用 iPhone 錄音。錄完丟給 AI，AI 自動整理成會議紀錄、待辦事項、追蹤清單。他說他「連打字都嫌慢」。

我問 Claude：「他的錄音工作流到底怎麼實現？我該學嗎？」

Claude 的回答：語音工作流的五層架構

Claude 畫出了完整的語音處理流水線：

第一層：手機錄音
  iPhone Voice Memos 或任何錄音 app
  ↓
第二層：同步到 Mac
  iCloud 自動同步，音檔出現在 ~/Library/...
  ↓
第三層：語音轉文字
  Whisper（離線、免費、準確率高）
  或 Gemini（線上、支援長音檔、能理解上下文）
  ↓
第四層：AI 分類
  根據內容自動判斷這是會議紀錄、學習筆記、還是靈感捕捉
  ↓
第五層：路由到對應指令
  會議內容 → /meeting
  學習內容 → /note
  零散想法 → /capture

架構看起來很美，但 Claude 馬上補了一句很實在的話：

先手動做一週，找到真正的瓶頸，再自動化那一步。

為什麼？因為你還不知道瓶頸在哪。可能瓶頸不是「轉文字」，而是「錄音品質太差、背景噪音太多」。可能瓶頸不是「分類」，而是「你根本懶得開錄音 app」。

自動化一個你還不理解的流程，等於把問題藏起來。MVP 原則：先跑起來，再優化。

Claude 建議的第一週計畫：

Week 1：
  - 手動用 Voice Memos 錄音
  - 手動丟給 Claude 轉文字
  - 手動複製到 /meeting 或 /note
  - 記錄每一步花了多少時間
  - 找到花最多時間的那一步

Week 2：
  - 只自動化花最多時間的那一步
  - 其他繼續手動

不是一次到位，是逐步進化。

我又追問：我會忘記這些指令怎麼辦？

這是我問的最誠實的問題。

設計了 /new-site、/meeting、/note、/capture，加上之前的 /blog、/cheatsheet，已經六個指令了。我知道我自己——三天不用就全忘了。然後又回到「每次從頭來」的老路。

工具再好，記不住就等於沒有。

Claude 的回答：/cheatsheet + 一次練一個

Claude 給了兩個解法，一硬一軟。

硬解法：/cheatsheet 指令

打 /cheatsheet 就顯示所有自訂指令的清單：

你的個人作業系統指令：

捕捉層：
  /capture  一句話靈感捕捉（零格式）
  /meeting  會議紀錄（自動模板）
  /note     學習筆記（結構化歸檔）

建置層：
  /new-site 一鍵建站（零設定）

發布層：
  /blog     學習歷程 → 部落格文章

工具層：
  /cheatsheet  顯示這張表

不用背，不用翻文件，一個指令叫出來看一眼就好。

軟解法：一次練一個

但 Claude 說 /cheatsheet 只是輔助，真正的解法是養成習慣。而養成習慣的訣竅是一次只練一個。

第 1 週：只練 /capture
  → 任何想法，不管大小，都用 /capture 記下來
  → 目標：讓 /capture 變成反射動作

第 2 週：加入 /meeting
  → 每場會議開始前，先打 /meeting
  → /capture 已經是習慣了，不用想

第 3 週：加入 /note
  → 每次學完東西，用 /note 整理
  → /capture 和 /meeting 已經是習慣了

第 4 週：加入 /blog
  → 每週挑一則 /note 用 /blog 發布
  → 其他三個已經是習慣了

一次學五個指令 = 五個都記不住。一次練一個 = 一個月後五個都變成反射動作。

Claude 最後說了一句我覺得很關鍵的話：指令的數量不是問題，切換的認知成本才是。 當一個指令變成習慣，它的認知成本就是零。零加零加零，還是零。但如果五個指令都要「想一下」，五個加起來就夠你放棄了。

我學到的

PEP 723 的精神不只是 Python 腳本的依賴管理，它是一個設計哲學：每個動作應該是自我完備的，不依賴使用者的記憶力。

傳統的五步流程——建環境、啟動、寫依賴、安裝、執行——每一步都要你記得上一步做了什麼。PEP 723 把五步壓成一步，不是因為省時間（雖然確實省），而是因為消除了記憶的負擔。

從「一個檔案就能跑」延伸到「一個指令就能做」，這就是個人作業系統的核心：

PEP 723 腳本         個人作業系統
─────────────       ──────────────
依賴寫在檔案裡   →   模板寫在指令裡
不用記要裝什麼   →   不用記格式長什麼樣
拿到就能跑      →   打了就能做
一個檔案 = 完整   →   一個指令 = 完整

而養成習慣的方式，不是一次學會所有指令，是一次只練一個，讓每個指令的認知成本降到零。零摩擦的工具，才會真的被用。

這跟建網站一樣——最好的架構不是功能最多的，是讓你不用想就能動手的。