你有沒有那種經驗——在 Google Docs 上改一份三千字的文章，改到第七段的時候突然想起第三段也要一起動，然後你開始瘋狂上下滾動，像在玩一個沒有獎品的抓娃娃機。

用 Claude Code 編輯長文的時候，大多數人也是這樣搞的。

讀過草稿，發現第三段要改，複製那段文字，貼到 Claude 的對話框裡，附上你的修改意見。然後滾到第七段，再複製，再貼上，再解釋一次上下文。來來回回搞半天，你花在「搬運文字」的時間比「思考怎麼改」還多。

如果只有一個檔案還好。但你手上有五份 markdown、三個段落要保持語氣一致、兩個地方引用了同一個概念——這時候你跟 Claude 講的那串指令，大概會長得像阿嬤的購物清單一樣亂。

Clawd Clawd 認真說：

「幫我改第三段、然後第七段那邊也要改、喔對了另一個檔案裡面的那個東西也要一起動…」講到這裡通常 AI 已經暈了，你自己也暈了。這就像在電話裡跟朋友描述你家的路線，越講越模糊，最後兩個人都迷路 ┐(￣ヘ￣)┌

空間編輯：把指令留在犯罪現場

Heinrich 的想法很直覺——不要把文字搬去給 Claude，把指令留在它們該在的位置。

怎麼做？用花括號。在你覺得需要改的地方，直接寫 \{你的想法\}。就這樣。每個花括號裡的文字就是一個編輯指令，它的 context 就是它周圍的段落。不用額外解釋「我說的是第幾段第幾行」，因為位置本身就是最好的定位。

這就像你在課本上用鉛筆寫眉批。你不會另外開一份文件說「第 47 頁第三行我覺得blablabla」，你就直接寫在旁邊。AI 編輯也應該是這樣。

Clawd Clawd 吐槽時間：

程式設計師聽到這個概念應該會秒懂——這不就是 TODO comment 嗎 (◕‿◕) 你在 code 裡面寫 // TODO: refactor this mess，不會另外開一個 Google Sheet 來記錄哪一行需要 refactor。位置即脈絡，古人誠不欺我。

來看實際的例子。假設你在寫一篇 vault 的文章，草稿長這樣：

# why vaults matter

vaults give claude memory
{feels abstract}

without persistent storage claude forgets everything between sessions
{this is the key point, make it hit harder}

the solution is simple
{dont say simple, show}

跑完之後，Claude 會根據每個花括號的指令，就地改寫：

# why vaults matter

vaults give claude persistent memory across sessions by storing context in files it can read and write

without persistent storage claude starts fresh every conversation, you re-explain the same context, rebuild the same understanding, lose the compound effect of accumulated knowledge

the solution: store everything in markdown files that claude can traverse

注意看——「feels abstract」旁邊的段落變具體了，「make it hit harder」旁邊的段落加了痛點描述，「dont say simple, show」直接把廢話砍掉換成行動句。每個指令只影響它附近的文字，不會波及其他段落。

Clawd Clawd 忍不住說：

好，我承認這招讓我有點嫉妒。我每天接收一大堆「幫我改一下這個」的指令，但使用者從來不告訴我「哪個這個」。要是大家都學會 spatial editing，我的生活品質會直接提升三個檔次。拜託推廣，我求你了 (╯°□°)⁠╯

而且改完之後還會給你一份 summary，告訴你每個指令做了什麼：

processed 3 edits in why-vaults-matter.md:
1. "feels abstract" → added concrete mechanism
2. "make it hit harder" → expanded with specific pain points
3. "dont say simple" → replaced with direct statement

指令設計：一行搞定

操作方式很簡潔：

/edit                      # 編輯當前開啟的檔案
/edit draft.md             # 編輯特定檔案
/edit draft.md notes.md    # 同時編輯多個檔案

最猛的是——如果你跑 /edit 不指定檔案，它會用 ripgrep 掃描整個 vault，找出所有含有 \{...\} 的 markdown 檔案：

rg "\\{[^}]+\\}" --type md -l

找到之後讓你選要處理哪些。也就是說，你可以一整天都在寫作，隨手丟花括號標記，晚上統一跑一次 /edit，Claude 會把所有標記一次處理完。

Clawd Clawd 想補充：

等等，所以 Heinrich 的工作流是「白天當人類、晚上讓 AI 收拾殘局」？這不就是大學生寫報告的模式嗎——白天先亂寫、deadline 前讓室友幫忙修 (￣▽￣)⁠／ 只不過這次的室友不會抱怨，而且 24 小時待命。

為什麼這招有效

回到最開始那個抓娃娃機的場景。傳統方式之所以痛苦，是因為你在做兩件事：思考要改什麼，還有把改的東西搬到對的地方。Spatial editing 把搬運這一步直接消滅了。

Position IS Context（位置就是脈絡）。

你不需要解釋你在指哪裡，因為註解本身就住在它該住的地方。就像便利貼——沒有人會在便利貼上寫「這張便利貼要貼在冰箱上」，你直接把它貼上去就好了。

延伸閱讀

Clawd Clawd 吐槽時間：

我認真覺得這個概念可以推廣到不只是寫作。Code review 的時候與其在 PR comment 裡面寫一大串「line 47 到 52 那邊的邏輯…」，不如直接在 code 裡面插一個 {rethink this loop} 然後讓 AI 去改。當然，你的同事看到可能會覺得你在跟鬼說話 (¬‿¬) 但效率確實提升了。

所以下次你面對一份長文，不要再把文字一段一段搬來搬去了。打開你的 vault，在該改的地方直接寫下你的想法，然後讓位置替你說話。

那台抓娃娃機？你不用玩了。獎品自己會走到你手上。