Amp Artifacts 實戰：讓 agent 和團隊在同一份 thread 文件上共編，人的修改不再被蓋掉

你叫 coding agent 先出一份改動計畫，它回你一大段文字。你看完想改第三步、刪掉第五步、在表格裡補一欄，只能再打一段話描述「第三步改成……第五步不要……」，agent 再整段重寫一次。重寫完，你剛說的有一半漏了，另一半它順手改了你沒叫它動的地方。隊友想看這份計畫？你只能貼一個 thread 連結，叫他從四十則訊息裡自己挖。

這個「計畫活在聊天捲軸裡」的問題，Amp 在 2026 年 11 月 2 日的 changelog 給了一個正面解法：Artifacts。這篇從官方 changelog 和 Threads 文件把機制拆清楚，再整理成可以照做的用法。先講明：以下內容是讀文件整理出來的，不是我們長期實測的心得；文件沒寫清楚的地方會直接標出來。

一、它要解決什麼：長回覆不是好的協作介面

Amp 官方文件對 artifact 的定義很直接：

An artifact is a document attached to a thread that you, your teammates, and the agent edit together. Use one for what people will read: a plan, a report, notes from a call, or findings gathered from several threads.

關鍵在最後那句：給人讀的東西。聊天回覆適合「一來一回的對話」，但計畫、報告、會議筆記、跨 thread 的調查結論，這些是要被反覆讀、被修改、被轉給別人看的東西。把它們塞在對話流裡有三個老問題：

1. 改不動：你不能直接在 agent 的回覆上打勾、改表格，只能用自然語言描述修改，再賭 agent 理解對。
2. 會被覆寫：agent 每次「更新計畫」都是重新生成整段，你上一輪的修正很容易被吃掉。
3. 難轉交：隊友要看的是結論，不是整串 thread。

Artifacts 的設計就是把「要被讀的產出」從對話裡拉出來，變成一份 agent、你、隊友都能編輯的文件，而且它屬於某一個 thread，上下文不會斷。

二、運作原理：一份文件、多個編輯者、每次存檔一個 revision

把文件裡的描述拼起來，機制大概是這樣：

1. 文件屬於 thread。 每份 artifact 掛在單一 thread 底下，一個 thread 可以有很多份，用資料夾分組。在對話裡出現的 artifact 連結，點下去會在 Artifacts 分頁打開。刪掉 thread，底下的 artifact 一起刪。

2. agent 用 Markdown 讀寫。 文件寫明 agent 是透過一個叫 artifact 的工具，以 Markdown 讀寫 artifact，而且「每一個使用者可選的 agent mode 和每一個 Space」都有這個工具。也就是說你不用切特定模式才能用。內容支援標題、清單、checklist、表格、程式碼、圖片，還有 interactive views。

3. agent 會主動開。 changelog 的說法是「You don't have to ask for one」：當 agent 有東西要給你讀，例如計畫、報告、通話筆記，它會寫成 artifact 而不是一大段回覆，文件在 thread 旁邊打開。你也可以自己從 Views → Artifacts 打開，或直接叫 Amp 寫一份。

4. 你直接改，agent 先讀你的修改。 這是最實用的一點。changelog 原文：

Edit it like any document: tick off a checklist, fix a table, rewrite a paragraph. When the agent comes back to it, it reads your edits first and works them in instead of writing over them.

5. 衝突處理靠 revision。 文件寫：每次存檔產生一個新 revision。如果 agent 在工作期間有人存了更新的 revision，agent 的更新會被拒絕，它要把自己的改動合併進較新的版本，而不是蓋掉。這基本上是樂觀鎖（optimistic concurrency）的做法：寫入時檢查版本，過期就拒絕、重新合併。對共編來說，這比「最後寫入者贏」安全得多。

所以整個迴圈是：agent 寫初版 → 你或隊友直接編輯（產生新 revision）→ agent 回來時先讀最新版、把你的修改納入再續寫 → 若撞版就合併。人和 agent 第一次在同一份文件上是「對等編輯者」，不是「人下指令、agent 重寫」。

三、官方給的兩個例子

changelog 舉了兩個 Amp 團隊內部的 thread：

• Nicolay 的 thread：agent 翻了 60 個 Amp 的 thread，調查「Amp 在等長時間 shell 指令時有沒有浪費 model call」。產出的 artifact 裡有一張長條圖，數字從現行輪詢（polling）的 3.9k 降到改用 async watch 的 978，外加一份兩步驟的修正計畫。
• Beyang 的 thread：有使用者想在 Changes 面板看到 Markdown 渲染預覽。Beyang 讓 agent 做了兩個版本，各自在自己的 orb 裡跑，agent 再把兩版並排放進同一份 artifact，比較各自動到的檔案、檢查結果和成本。

注意數字的前提：3.9k 對 978 是 Amp 自己內部調查的結果，changelog 沒有說明單位的完整定義與量測條件，請當成「這種調查可以怎麼呈現」的示範，不要當成可以套到你環境的效能數據。

這兩個例子其實點出 artifact 最有價值的兩種用法：跨 thread 的調查彙整，和多方案並排比較。兩者的共同點是：結論要給別人看、要被拿來做決定。

四、分享與權限：先搞清楚誰看得到

文件寫的權限規則：

• 誰能編輯：能打開該 thread、且屬於該 workspace 的人；個人 thread 則是擁有者。

• Share → General Access 決定 artifact 連結誰能開：

  • Same Access as Thread（預設）：跟 thread 可見度一致，thread 之後改可見度也會跟著變。
  • Workspace Members：workspace 成員可讀，不能改。
  • Anyone with the Link：任何人免登入可開。

• thread 本身的可見度有 Private、Workspace、Group（僅 enterprise）、Unlisted。

• workspace 管理員可以透過稽核存取開啟 thread 或 artifact，這種方式開的 artifact 是唯讀。

• 管理員可以在 workspace 設定關掉公開連結（「Allow Public Artifact Uploads」或「Allow Users to Share Threads and Portals Outside the Workspace」），關掉後既有公開連結會失效。

還有兩個限制要記：每份 artifact 上限 2 MB；artifact 裡的圖片是存在 thread 裡的，透過 workspace 或公開連結進來的讀者會看到破圖。所以要對外分享的 artifact，圖表最好改用表格或程式碼區塊呈現，或另外附圖。匯出則有 Markdown、HTML，或列印成 PDF。

五、照著做：五個用法與 prompt

以下是根據文件機制整理的用法，prompt 可以直接改來用。

用法 1：計畫先落文件，再開工

不要讓計畫活在回覆裡。開場就指定：

先不要改程式。把這次重構的計畫寫成一份 artifact，結構：
1. 目標與不做的事
2. 影響的檔案（表格：檔案 / 改動 / 風險）
3. 步驟 checklist，每步可以單獨驗證
寫完停下來，等我改完 artifact 再開始做。

你在 artifact 裡刪步驟、改表格、補風險，改完回 thread 說「我改完了，照 artifact 做」。因為 agent 回來會先讀你的修改，你不用再把修改內容用文字複述一次。

用法 2：checklist 當進度條

叫 agent 每完成一步就在 artifact 打勾：

照 artifact 的 checklist 一步步做。每完成一步：
- 在 artifact 對應項目打勾
- 在該項底下補一行「怎麼驗證的」（跑了什麼指令、結果）
遇到計畫外的改動，先寫進 artifact 的「偏離計畫」區塊再動手。

這樣隊友打開 artifact 就知道做到哪，不用翻 thread。值得實測的點是：agent 打勾時會不會連帶改到你手寫的段落，文件說它會「works them in instead of writing over them」，但實際邊界要自己驗。

用法 3：多方案並排比較

學 Beyang 的例子，讓 agent 做兩版，再要一份決策文件：

用兩種做法實作這個功能（A：前端渲染、B：後端預先產生）。
做完後寫一份比較用的 artifact，一張表並排：
改動檔案數、測試結果、預估成本、主要風險、我建議哪個與理由。

決策的人只看這一份，不看兩條實作過程。

用法 4：跨 thread 調查彙整

學 Nicolay 的例子，把「翻很多資料得出結論」的工作交給 agent，產出給人讀：

調查最近跟 CI timeout 有關的 thread，整理成 artifact：
- 一段結論（三句內）
- 證據表格：thread / 現象 / 推測原因
- 修正計畫，分成兩步
不確定的推論標「待確認」。

用法 5：會議或通話筆記

文件明確列了「notes from a call」。貼逐字稿或重點進去，叫 agent 寫成 artifact，你和與會者直接在上面改、補 action item，之後的實作 thread 再引用這份。

六、什麼時候別用

• 一句話能答完的事：問個 API 用法、查個錯誤訊息，回覆就夠，開文件反而多一層。
• 要長期活在 repo 的文件：artifact 掛在 thread 上，thread 刪了它就沒了。架構決策記錄（ADR）、README、runbook 這類需要版控和 code review 的東西，還是應該進 repo。比較合理的分工是：artifact 是工作中的共編草稿，定案後匯出 Markdown 進 repo。
• 含圖要對外分享：前面提過，經連結進來的讀者會看到破圖。
• 權限敏感的內容：預設權限跟著 thread 走，thread 一改成 Unlisted，artifact 也跟著公開程度改變。分享前到 Share 確認一次 General Access。

七、對工程團隊的意義：不用 Amp 也能偷的做法

Artifacts 是 Amp 的功能，但它背後的工作模式其實可以搬到任何 coding agent 上。如果你用的是 Claude Code、Codex 或 Cursor，可以用一個專門的計畫檔模擬這個迴圈（這是我們的建議做法，不是這些工具的內建功能）：

1. 規定計畫寫進檔案：例如在專案指令檔（Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md）加一條：「非一句話能答的任務，先把計畫寫進 plans/<任務名>.md，等我確認再動手。」
2. 人直接改檔：你在編輯器改計畫，不用在對話裡描述修改。
3. 要求先讀再寫：在指令檔加「每次更新計畫檔前，先重新讀取檔案，保留我手動改過的段落，只修改你負責的部分」。
4. 用 git 當 revision：計畫檔改動前先 commit，agent 有沒有蓋掉你的修改，git diff 一眼看出來。

差別在於：Amp 把「revision 衝突就拒絕、改合併」做進工具裡，自己模擬時這層保護要靠 git 和紀律。這也剛好說明 Artifacts 真正的價值：不是「多一個文件編輯器」，而是把人的修改變成 agent 必須尊重的狀態，而不是可以被下一次生成蓋掉的對話紀錄。

如果你的團隊已經在用 Amp，最低成本的起手式是：下一個中型任務，開場就叫 agent 把計畫寫成 artifact，你直接在上面改，再看它回來時有沒有把你的修改接住。這一個實驗就能判斷要不要把它變成團隊習慣。

文件沒講清楚的地方

• Threads 文件裡「如何讓 agent 編輯你正在看的 artifact」那句的操作細節（文件提到 Ask Amp inside it），我們讀到的內容不完整，具體的 UI 操作請以 Amp 介面為準。
• 文件沒有提到 artifact 專屬的計費方式，也沒有 CLI 指令的說明。
• changelog 沒有作者署名；Nicolay 與 Beyang 是例子中的 thread 擁有者。

來源

• Amp Changelog〈Artifacts〉，2026-11-02，Amp 團隊：https://ampcode.com/news/artifacts
• Amp Docs〈Threads〉Artifacts 章節（權限、revision、2 MB 上限、匯出）：https://ampcode.com/docs/threads#artifacts
• Amp Docs，workspace thread 可見度控制：https://ampcode.com/docs/enterprise/workspace-thread-visibility-controls

整理：DataAgent · Coding Agent 實戰教學