【2026 最新】Agentic Artifact Creation 是什麼？SlideOps 可追溯簡報教學

叫 AI「幫我做一份簡報」並不難，難的是兩週後程式碼改了，你能不能知道哪一頁已失真、為什麼失真，先把修補定位到受影響頁，再驗整份交付物。Agentic Artifact Creation 不看使用者最後收到幾個檔案，而看 AI 是否跨決策保留 artifact／process state，並讓至少一次中間觀察改變後續作品工作。

這篇專為第一次接觸這個名詞、但想把 AI 產物真正交付的讀者寫：先拆解論文框架，再用獨立開源專案 SlideOps 做一份五頁、可追溯、可由 agent-guided workflow 局部修補的程式碼簡報。完成後，你會有一條從引用、版本 stamp、JSON 檢查，到 MOVED／CHANGED 修補、渲染、PDF 與 CI 的完整路徑。

先說結論：SlideOps 不是論文的官方實作，也不等於完整的 Agentic Artifact Creation。它用來源與版本建立較窄的 provenance，check JSON 提供可由人或代理解讀的 observation／repair brief；只有這些觀察實際改變後續編輯、分支或停止決定時，整個 episode 才符合論文定義。

Agentic Artifact Creation 是什麼？

論文的正式定義有三個門檻：AI 必須實質建立或修改可交付成果；跨多個決策保留狀態；而且至少有一次中間觀察，真的改變後續製作。外部即使只看到一次請求與一次最終輸出，內部仍可能有符合定義的多步建構；判準不是對話輪數，而是觀察有沒有重新導向作品工作。

論文的三個功能角色是 Operational Representation、Construction Policy、Runtime Verification；Task Specification 提供任務條件，但不是第四個功能角色。論文把它們寫成一個有狀態的循環：任務是 T，目前作品狀態是 R；代理依任務、狀態與回饋選動作，產生下一版 R；驗證器再觀察結果並回傳新回饋。接受條件成立後，才把當下版本交付。用白話說就是：

1. 先表示狀態：知道作品目前有哪些頁、引用與版本。
2. 再觀察與判斷：不是只看「有沒有檔案」，而是判斷哪些準則通過、失敗原因在哪、下一步怎麼修。
3. 再決定下一步：讓觀察真正改變後續製作；需要修補時，可把證據定位到可編輯區塊，執行可行修改，再對受影響狀態重新驗證。

論文對 runtime feedback 的分類是 Criterion Status、Failure Diagnosis、Revision Guidance。本文為方便操作，把這三類合稱為「結構化回饋」；這是教學用縮寫，不是論文另立的正式術語。三種功能可以並存，粒度也可不同；需要局部修補時，最可行的回饋會把準則、及時證據、診斷、受影響狀態與可行修補或升級路徑連起來，而不只給一個總分。

論文與 SlideOps 的邊界要先畫清楚

這篇 arXiv v1 論文是廣泛調查型論文，不是 SlideOps 的產品實驗。它在 2026 年 8 月 28 日提交；依 v1 的 canonical survey corpus，作者統計截至 8 月 20 日可取得的 259 項工作，其中 230 個系統、29 個基準。論文的簡報段落歸納角色分工、參照資料與 rendered feedback、slide-level edits 等案例，但沒有測試本文下面的五頁 deck。這個口徑也不應和作者持續更新的 live catalog 混算。

SlideOps 則是 Gleb Lukicov 的獨立專案；其 v1.0.0 頁面標示為 8 月 28 日的 first public release，晚於 v1 corpus 的 8 月 20 日截止日。就公開時序而言，它是後發映射案例，不是該 survey 的證據；這是本文推論，不是論文主張。

用 SlideOps 實作 Agentic Artifact Creation：先安裝

截至 2026 年 9 月 1 日，GitHub 的最新 release 是 v1.1.1；本文把程式與文件固定在 66af7de，避免 main 後續變更讓操作與說明分離。以下命令來自該固定版本的官方安裝說明。Claude Code 可執行：

/plugin marketplace add glukicov/slideops
/plugin install slideops@slideops

支援 skills CLI 的代理可用一行安裝；這會依該工具當下解析到的版本安裝：

npx skills add glukicov/slideops

若要跟著本文重現，建議改在不含秘密、可丟棄的練習 repo 中固定版本，並先把安裝目的地限制在該 repo：

(
set -eu
git clone https://github.com/glukicov/slideops .tools/slideops
git -C .tools/slideops checkout 66af7de143647423bca60fff6e8b1251755947cb
test "$(git -C .tools/slideops rev-parse HEAD)" = 66af7de143647423bca60fff6e8b1251755947cb
.tools/slideops/install.sh --copy --dry-run --dest .agents/skills

mkdir -p .agents/skills
for skill in slideops slides-to-pdf; do
  target=".agents/skills/$skill"
  [ ! -e "$target" ] && [ ! -L "$target" ] || {
    echo "refusing to replace $target" >&2
    exit 1
  }
done
for skill in slideops slides-to-pdf; do
  cp -R ".tools/slideops/skills/$skill" ".agents/skills/$skill"
done
)

上面固定 commit 是為了固定本文使用的程式與文件。--dry-run 只預覽所選模式與目標，不會另列刪除步驟；真正執行這個版本的 install.sh 時，腳本會先對兩個目標執行 rm -rf，不論原項目是目錄、檔案或 symlink。所以上例只讓官方腳本 dry-run，實際安裝改從固定 checkout 複製，且任一目標已存在就中止，不覆寫既有內容；目的地也限制在練習 repo，而不是家目錄中的全域技能。

接著在要說明的程式碼 repository 內，先請代理讀專案，不要立刻做二十頁。若你還不熟悉代理如何保存工具、規則與驗證邊界，可以先看從 Agent 架構理解工具與記憶。

五頁 deck 的最小可行規格

1. 目的：這個 repo 解決什麼問題，誰需要看這份 deck。
2. 地圖：入口、主要模組與資料流；引用支撐圖的核心檔案。
3. 核心路徑：放一段真正的 request／job handler，說明關鍵行為。
4. 失敗與測試：用測試或設定檔說明錯誤路徑、重試或保護條件。
5. 結論與行動：整理限制、owner 與下一個決策，不為了湊頁數再塞程式碼。

把下面這段直接交給已安裝 SlideOps 的 coding agent。你已明確給出頁面結構，因此這次不需要再讓它猜題目；但仍要求它先回報實際找到的來源，再動 HTML：

請用 SlideOps 為這個練習 repo 建立
docs/slides/five-page.html，Ledger Light，共五頁：
1. 目的與受眾
2. 模組與資料流
3. 一條核心執行路徑
4. 失敗路徑與測試
5. 限制、owner 與下一步

只讀允許公開的檔案；不要讀 secrets、env、憑證或真實資料。
先列出每頁要用的來源，再建立 HTML。
第 2–4 頁的程式碼主張都要用 cite.py 產生引用，不手寫 hash。
完成後 stamp、輸出 artifacts/initial-check.json，並把五頁 render 到
artifacts/render-initial/。保留 HTML、JSON 與 PNG 中間產物。

「先定五頁結構、再填來源、最後看 render」是本文的教學設計，不是論文規定的唯一流程；它的好處是先建立可編輯單元，再讓回饋指向明確頁面。第 2 至 4 頁的具體主張要接到來源；第 1、5 頁若只是目的與決策摘要，不必硬塞逐行引用。

引用、stamp 與 check JSON：把來源變成可追溯狀態

先把 skill 路徑放進變數，再用 cite.py 讀真正的來源。第一輪請在沒有秘密的 fixture repo、且只對自己建立的 deck 練習；目前版本的路徑邊界問題會在限制段落說明。不要自己算 hash：

SLIDEOPS_SKILL="/absolute/path/to/slideops/skills/slideops"
python3 "$SLIDEOPS_SKILL/scripts/cite.py" app/main.py:40-58 --repo . --snippet

它會產生 data-src="path:start-end" 與 data-sha256。依官方 freshness 規格，hash 是來源行以換行字元連接後，SHA-256 的前 12 個十六進位字元；它指紋化的是原始碼，不是投影片上可能已裁短的片段。

<pre class="code small"
  data-src="app/main.py:40-58"
  data-sha256="a1b2c3d4e5f6">...escaped snippet...</pre>

deck 完成後再 stamp。cite.py --stamp 會在 <head> 寫入 commit、日期與 repo；目前 checker 只使用可解析的 commit 取回歷史來源、偵測 MOVED、產生 diff 與 commit entries，日期與 repo 僅保留在 report／build metadata，不會被驗證。

python3 "$SLIDEOPS_SKILL/scripts/cite.py" --stamp docs/slides/five-page.html --repo .
python3 "$SLIDEOPS_SKILL/scripts/check.py" docs/slides/five-page.html --repo . --json

JSON 是修補 brief，不是自動改稿指令。遇到漂移時，重點欄位會像下面這樣；內容是縮短的格式示意：

{
  "slide": "3",
  "label": "CORE PATH",
  "src": "app/main.py:40-58",
  "status": "CHANGED",
  "detail": "2 line(s) differ",
  "suggested_src": "app/main.py:40-58",
  "suggested_sha256": "<new-hash>",
  "diff": ["<unified diff>"],
  "commits": ["<short-sha> <commit subject>"],
  "current_source": ["<current source lines>"]
}

CURRENT 只表示目前引用範圍算出的 hash 前綴與 deck 記錄值相符；它不證明來源身分、整份檔案相同或簡報正確。MOVED、CHANGED、MISSING 是三種不同漂移；UNVERIFIED 在目前實作中主要表示缺 hash。官方文件也把無法解析的 build commit 列入 UNVERIFIED，但固定版本的程式會先丟棄該 commit，再依當前 hash 回報 CURRENT 或 CHANGED，兩者並不完全一致。這些狀態不能用同一個「全部重生」按鈕處理。

MOVED 與 CHANGED 怎麼做局部修補？

MOVED：當 build commit 可解析、舊 path 的 blob 存在且目前行 hash 不符時，checker 會在同一個目前檔案尋找與歷史區塊完全相同的第一個位置，找到後回報 MOVED 與新行號。它只是候選：先確認新位置的語意與唯一性，才能只更新 data-src 與建議 hash；否則按 CHANGED 處理。純 metadata 修正不必重做截圖，但投影片文字、節奏與版面也不應順手改掉。

CHANGED：若 build commit 與舊 blob 可解析，先看 unified diff 與最多 10 筆近期、觸及該 path 的 short-sha subject entries；不可解析時不會有 diff／move detection，應依 detail 與 current_source 判斷。變數改名可能只需重新引用；若分支被刪除、閾值改變或責任移到別的模組，就要先改論點，再換 snippet。定位並執行可行的小範圍修改，對應論文 §7.3 的 targeted repair；修改後讓舊證據失效、依相依關係重驗受影響頁面與 deck-level commitments，則是 §7.4 的另一項原則。先重渲染實際修改頁，但受影響範圍不能只由 HTML diff 決定。

MISSING 不等於可直接刪頁，應先用 git log --diff-filter=D -- path 找搬移或刪除脈絡，再請 owner 決定；UNVERIFIED 則重新 cite。接受證據綁定的是當前版本，修好後仍要重跑檢查，不能沿用上一次的綠燈。

做一次 MOVED／CHANGED 紅綠演練

1. 保存初版：把來源與 deck 一起 commit，確認 initial-check.json 的引用都是 CURRENT。
2. 製造 MOVED：只在被引用區塊上方加入 import 或註解，不改該區塊內容；commit 後重跑 checker，預期同檔案中的完全相同區塊會得到 MOVED 與新行號。
3. 修引用，不修故事：只套用 suggested_src 與 suggested_sha256，用 git diff 確認第 3 頁文案與第 4 頁人工備註沒有被碰到，再跑回 CURRENT。
4. 製造 CHANGED：真的改掉被引用區塊的一個行為，例如閾值或失敗分支；commit 後保存 changed.json，先讀 diff，再決定第 3 頁的 claim 與 snippet 是否都要改。
5. 局部修、廣義重驗：先只重渲染第 3 頁抓 overflow；修好後再 render 全五頁，檢查術語、頁序、導覽、跨頁敘事與 PDF。局部修補不代表交付驗收也只能看一頁。

python3 "$SLIDEOPS_SKILL/scripts/check.py" \
  docs/slides/five-page.html --repo . --json \
  > artifacts/moved-or-changed.json

git diff -- docs/slides/five-page.html

如何保護人工修改？

SlideOps 不會鎖住設計師改過的文案，也不是三方 merge 工具。可降低誤覆寫的操作邊界包括：把 deck 納入 Git；每次先保存乾淨 commit；只編輯 JSON 指到的頁；要求代理「repair, do not rebuild」；review HTML diff。凡可見內容、共享 CSS／JavaScript 或頁序有變，先看受影響頁，交付前再驗全 deck；只有純 metadata MOVED 可不重截圖。這些做法讓越界修改較容易被發現與回復，不能強制代理不重建，所以 diff review 不能省。若團隊還沒有明確的頁面責任與接受條件，可先用規格先行的收斂流程把「哪些內容可改、怎樣算通過」寫成可驗收規格。

Render、PDF 與 CI：讓完成條件可觀察

citation status 通過只代表目前引用範圍沒有被 checker 判為漂移，不能取代視覺 QA。依官方驗證流程，先用 headless Chrome 把每一頁渲染成圖片，再逐頁看文字裁切、導覽遮擋、表格或 code overflow、壞圖與頁碼。修改後先看受影響頁，交付前再看全 deck。

CHROME="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
DECK="docs/slides/five-page.html"
STAGE="$(mktemp -d "${TMPDIR:-/tmp}/slideops-render.XXXXXX")"

# 先看剛修過的第 3 頁
"$CHROME" --headless=new --disable-gpu --hide-scrollbars \
  --window-size=1280,720 --screenshot="$STAGE/slide-03.png" \
  "file://$PWD/$DECK#3"

# 交付前再渲染全 deck
N=$(grep -c '<section class="slide' "$DECK")
for i in $(seq 1 "$N"); do
  "$CHROME" --headless=new --disable-gpu --hide-scrollbars \
    --window-size=1280,720 \
    --screenshot="$STAGE/slide-$(printf '%02d' "$i").png" \
    "file://$PWD/$DECK#${i}"
done

Linux 請把 CHROME 換成實際的 Chrome／Chromium binary；截至固定版本，上游只列出 macOS 與 Linux 路徑，Windows 尚未由本文驗證。不要為了省事關閉 Chrome sandbox，但保留 sandbox 不等於切斷網路：敏感環境還要先審查 deck 的外連資源，或在禁止 outbound network 的隔離環境 render。逐張打開 PNG，刻意在第 3 頁放入過長文案時，先確認真的看得到 overflow，再縮短內容或調整留白，重新渲染到沒有裁切為止。想把架構差異也做成可驗證視覺，可參考架構 delta 圖的驗收方式。

PDF 是可選交付物。請安裝後的代理使用 companion slides-to-pdf skill，把五張 2× screenshot 組成一頁一張的 five-page.pdf；完成後再把 PDF render 回圖片，避免「頁數正確但圖片頁空白」。不過截至本文固定的 commit，官方 PDF 指令片段呼叫了未在前文定義的 $PDFPY，不能宣稱可直接照貼重現。驗證時直接呼叫剛建立的 venv Python：

PDF="docs/slides/five-page.pdf"
PDF_STAGE="$(mktemp -d "${TMPDIR:-/tmp}/slideops-pdf-check.XXXXXX")"
python3 -m venv "$PDF_STAGE/venv"
"$PDF_STAGE/venv/bin/pip" install --quiet pypdfium2 Pillow

"$PDF_STAGE/venv/bin/python" - "$PDF" "$PDF_STAGE" 5 <<'PY'
import sys
import pypdfium2 as pdfium

pdf_path, stage, expected = sys.argv[1], sys.argv[2], int(sys.argv[3])
pdf = pdfium.PdfDocument(pdf_path)
assert len(pdf) == expected, f"expected {expected} pages, got {len(pdf)}"
for index in range(len(pdf)):
    pdf[index].render(scale=1.5).to_pil().save(
        f"{stage}/check-{index + 1:02d}.png"
    )
print(f"rendered {len(pdf)} PDF pages for visual review")
PY

接著逐張查看 check-01.png 到 check-05.png。這段只修正回渲染驗證器的 Python 路徑；正式 CI 應把 pypdfium2 與 Pillow 版本寫進自己的 lockfile，不要假裝上游片段已經固定相依版本。

長期維護的 onboarding 或 architecture deck，適合先在 PR 加 advisory CI；快照型簡報則應保留當時狀態，不必自動追著主幹更新。把固定版本的 checker 複製進 repo，先用 report-only：

mkdir -p tools artifacts
cp "$SLIDEOPS_SKILL/scripts/check.py" tools/slideops-check.py
python3 tools/slideops-check.py docs/slides/ --repo . --suggest --exit-zero

--exit-zero 只把已完成檢查的 stale exit 1 改成 0；repo／deck 無法讀取或找不到 deck 仍回 2。只有 UNVERIFIED 時，即使沒有 --exit-zero，目前實作也會回 0。若要把 citation 狀態升級為 blocking，下面用 jq 同時檢查頂層計數、deck error 與 citation 狀態：

python3 tools/slideops-check.py docs/slides/ --repo . \
  --json --exit-zero > artifacts/slideops-drift.json &&
jq -e '
  (.checked > 0) and
  (.stale == 0) and
  (.unverified == 0) and
  ([.decks[] | select(.error != null)] | length == 0) and
  ([.decks[].citations[] | select(.status != "CURRENT")] | length == 0)
' artifacts/slideops-drift.json

這只是 citation status gate，額外需要 jq；checker 本身仍只用 Python standard library。它沒有證明 build commit 可解析，也不知道「預期要有幾條引用、哪些頁一定要有來源」。正式驗收要另外以 git cat-file -e "$BUILD_COMMIT^{commit}" 檢查 stamp 的 commit，並把引用清單、數量與逐頁覆蓋率和團隊審過的 manifest 比對。等團隊理解各狀態、建立修補責任與安全邊界後，再決定哪些 workflow 要 blocking。也可把它和另一種 drift CI對照：兩者都應把「偵測到變化」與「判定內容錯誤」分開。

Agentic Artifact Creation 在這個案例中的限制

• 綠燈不是語意真理：引用行相同，周邊文案、架構圖或結論仍可能錯。
• 看不到未引用的新世界：repo 新增一個模組，但舊引用都沒變，checker 不會主動知道 deck 少講了它。
• hash 不是安全簽章：12 位前綴適合偵測漂移，不等於防竄改或供應鏈驗證。
• 定位能力有範圍：MOVED 只代表同檔案找到第一個完全相同的歷史區塊候選，不證明其語意或唯一性；跨檔重構仍需人或代理追查。
• 修補需要判斷：JSON 提供證據，不會替你決定 claim 是否仍成立，也不會自動保護人工設計。

還有兩個目前版本的工程邊界。第一，固定版本的 check.py 與 cite.py 都直接把 citation／ref 路徑接到 repo 路徑後讀檔，沒有先拒絕絕對路徑、.. 或指向 repo 外的 symlink；cite.py --snippet 可直接印出該內容，而 hash 不符時 check.py --json 也可能把它放進 current_source。因此只應在不含秘密的 fixture repo，對自己建立且已審查的 deck／reference 執行這兩支腳本。第二，缺 hash 的 UNVERIFIED 不在目前 is_stale 集合內；即使沒有 --exit-zero，只有 UNVERIFIED 時程序也可能以 0 結束。

因此，SlideOps 最像是 provenance 與局部維護的「感測器加操作手冊」，checker 單獨不構成 Agentic Artifact Creation。論文的最低門檻仍是 AI 實質建構／修改、狀態跨決策持續，以及觀察重新導向後續工作；任務規格、接受條件、版本依賴與人類權限，是可按風險加入的更強控制，不是普遍必要條件。

常見問題 FAQ

1. Agentic Artifact Creation 就是叫 AI 生成簡報嗎？

不只是。至少還要跨決策保留作品狀態，並讓一次中間觀察實際改變後續製作。外部看起來只有一次請求與一次最終輸出，也可能在內部符合定義；判準是中間觀察有沒有重新導向作品工作，而不是對話輪數。

2. SlideOps 是論文作者做的官方實作嗎？

不是。兩者作者與專案來源不同；SlideOps 的公開發布也晚於論文語料截止日。本文只是把兩者在 provenance、feedback 與 targeted repair 上做方法對照。

3. Provenance 在 deck 裡具體是什麼？

是「這段內容從哪裡來、建於哪個版本」的可追溯資訊。SlideOps 用來源路徑與行號、內容 hash，以及 deck 的 build commit／日期／repo 表達。這是較窄的 source provenance；論文談的廣義 provenance 還可包含決策、核准與工具動作，兩者不能直接畫上等號。

4. 為什麼不能只記 data-src，不記 hash？

行號會因插入 import 或註解而改變；記錄 hash 可先偵測目前範圍是否仍相符。若不相符，checker 還要有可解析的 build commit 與舊 blob，才會在同檔尋找 MOVED 候選；是否真為搬移仍須確認語意與唯一性。缺 hash 時則回報 UNVERIFIED。

5. MOVED 和 CHANGED 最大差別是什麼？

MOVED 表示 checker 在同檔找到與歷史片段完全相同的第一個候選；先確認新位置的語意與唯一性，才只修 metadata。CHANGED 是來源內容不同，必須先重新判斷投影片主張，再決定改引用還是改整頁論述。

6. check 全部 CURRENT，就代表簡報完全正確嗎？

不代表。它只表示目前引用範圍的 hash 前綴與 deck 記錄值相符，沒有驗證來源身分、周邊解釋、視覺圖、未引用數字，也看不到新功能造成的內容缺口。

7. 代理更新時，能百分之百保留人工修改嗎？

不能靠 SlideOps 自動保證。可採用 Git 版本化、限定受影響頁、禁止整份重建、審 HTML diff，並只先重渲染實際修改的頁面；交付前仍做一次全 deck 驗收。

8. 每份 deck 都需要 PDF 和 blocking CI 嗎？

不需要。PDF 取決於交付情境；CI 適合會持續代表現況的 evergreen deck，且建議先 report-only。描述特定時點的 snapshot deck，反而應保留原貌。

重點整理

• Agentic Artifact Creation 的最低門檻是 AI 實質建構／修改、狀態跨決策持續、觀察改變後續工作；可行修補與重驗，是失敗或變更發生時的重要設計原則。
• SlideOps 用 data-src、data-sha256 與 build stamp，讓程式碼簡報具備可檢查的 provenance。
• MOVED 先驗證同檔候選的語意與唯一性，確認後才只修引用；CHANGED 先判斷 claim，再改 snippet 與必要文案。
• Git、最小 patch、diff review 與分層 render 能降低誤覆寫並協助回復人工修改，不是工具自動保證。
• check、視覺 QA、PDF render-back 與 CI 各自驗不同風險，不能用單一綠燈互相取代。