Day 16｜地圖重貼（補）：十天之後，十二區能力的分數哪幾格動了、憑什麼動

2026 iThome 鐵人賽

DAY 7

AI Engineering

邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力系列第 11 篇

Day 16｜地圖重貼（補）：十天之後，十二區能力的分數哪幾格動了、憑什麼動

18th鐵人賽

中年一般人

2026-09-24 07:20:13

31 瀏覽

分享至

系列：「邊做邊補：用一個 AI 代理 mesh 專案，補齊 AI 工程師該有的能力」— 第 16 天
紀錄日期：2026-09-21
能力區：全部十二區（自評更新）｜類型：讀＋量

它是什麼

Day 01 說過：地圖在 Day 10、20、30 重貼。不是為了儀式，是因為自評這種東西只有在被逼著拿證據對照的時候才誠實。Day 10 已由另一份稿子重貼過一次；這一篇是同一天的第二份對照，保留它是因為兩份的分歧本身就是資料（見文末）。

規則不變：有＝能跑且有測試或證據；半＝有東西但沒量過或常壞；弱＝只有零件；無＝沒有。每一格要動，下面要能指到一個 commit、一個測試、或一份報告裡的數字。指不到就不動。

這十天專案裡發生了什麼（給分數當背景）

評估層：子任務採用率（D3）→ 存進 run log 活過關機（D4）→ 角色分類 v2、item 級 coverage、gap warning（D5、D6）。
方向：查了 55＋45 個開源專案，改成「開源堆疊＋薄核心」（D7）；借力帳從三節長到六節。
協定：MESH-CRYPTO-v1 十六輪 gate 後凍結（D8）；L4 receipt 鏈第一片落地、五輪 gate APPROVED（D9 之後）。
兩份設計文件：MESH-COMPOSITION、THREAT-CATALOG（draft-1）。
工具：mac-input-audit.sh（每晚唯讀稽核）、prompt-transit-check.py（三輪實測 prompt 傳輸中不可見）。

十二區：Day 01 vs Day 16（我這一份）

#	能力區	Day 01	Day 16	動的理由（指得到的證據）
1	Agent 基礎與範式	有	有	沒動。一顆 binary、三前端共用 daemon 仍成立
2	LLM 基礎與推理	半	半	沒動。provider 抽象在，配額半衰期還是沒量
3	上下文工程	半	半	沒動。合併 prompt 沒改；context 上限仍沒量
4	記憶與 RAG	半	半	沒動。THREAT-CATALOG §5.3 倒是新增了「記憶投毒」的對策設計，但沒寫程式
5	工具與協定	有	有＋	D9：Rust／TS 共用 CBOR 向量（T-CRYPTO-001）、`GET /rpc/mesh/receipts/:device_id`、Tauri `mesh_seal_receipt`；A2A／MCP／ACP 對照進借力帳。「＋」是我給自己的註記：這一區從「有」變成「有而且跨語言驗過 bytes」
6	Coding Agent	有，最強	有，最強	沒動。但發現無頭 claude 每次載入全部 MCP connector＋送 Datadog 遙測——工具強不等於工具乾淨，今天修了 worker 參數
7	框架：用輪子與造輪子	弱	半	D7 之後：Orca、Paperclip、open-orcha、Omarchy、herdr 各深讀一次，借法（黑盒／搬模組／抄設計）寫進借力帳，並有 MESH-COMPOSITION 說「哪四塊不借」。從「沒認真比較過」到「比較過、寫下判準」——但還沒真的接一個（S2／S3 spike 未跑），所以是半不是有
8	觀察與動作空間	弱	弱	沒動。語音、Computer Use 仍沒有
9	評估	弱	半	D3–D6：採用率、coverage、`unsupportedFinal`、gap warning 都有測試（`meshExecutor.test.ts` 38 條）；run log 有 `measured_coverage`。但仍沒有基準集、沒有統計顯著性——所以停在半
10	後訓練與 Agentic RL	無	無	沒動
11	持續進化：從軌跡學習	無	弱	D8：review-gate 的審查員錯誤帳開帳（BORROW-LEDGER §四、m5 報告每輪表）——這是「從軌跡學習」的最原始形式：記下誰在哪類問題上錯，下次調權重。只有帳、沒有回餵機制，所以是弱
12	多 Agent 協作	有	有	沒動級別，但內容變了：coordinator 現在記 `receipt_signed`；fan-out 的 attempt 有簽章 receipt 鏈。真正的多裝置驗簽（coordinator 拿 roster 公鑰驗）是下一片

變動：四格——第 5 區有→有＋、第 7 區弱→半、第 9 區弱→半、第 11 區無→弱。沒變：八格。

我差點想改、但證據不夠所以沒改的

第 12 區想標「有＋」：因為 receipt 鏈落地了。但 coordinator 還沒真的驗簽（只記錄有沒有簽），手機端的 receipt 也是這兩天才開始簽。等下一片。
第 4 區想標「半＋」：因為記憶投毒的對策設計寫了。但設計不是程式，一行都沒改。
第 2 區想降成「弱」：因為發現 Anthropic 的 IPv6 邊緣協商 TLS 1.2、IPv4 是 1.3——這是 provider 層的觀察。但這跟「LLM 基礎與推理」無關，是第 5 區的事，不該扯過來。

一個沒在 Day 01 地圖上的區

這十天做得最多的東西，在十二區裡沒有格子：安全。事件 tap 稽核、TCC 日誌、加密協定、威脅目錄、傳輸檢查——三本中文教材和六份英文對照裡，安全都是散在各章的一節，不是一個區。

我不打算改地圖（改地圖就沒辦法跟 Day 01 比了），但記在這裡：如果 Day 20 重貼時安全的工作量還是這麼大，就該承認地圖少了一區，而不是把它塞進第 5 區。

跟 Day 10 那一份的分歧

同一天、同一份證據，兩份重貼在兩格上不同：第 5 區我標「有＋」、Day 10 維持「有」（理由：單份驗證器不算整套加密）；第 11 區我標「弱」、Day 10 維持「無」（理由：有 review 紀錄但沒有回餵後改善的對照）。兩處都是 Day 10 比較嚴、比較對——我把「記了帳」當成了「學到了」。留這兩格的分歧，是為了下次重貼時看得到評分者也會漂。

今天真正學到的

第一，自評往上調比往下調容易，所以規則要嚴：每一格動都要指到 commit 或測試。今天四格動、八格沒動，三格想動但證據不夠——那三格才是這次重貼真正有用的地方。

第二，「半」是最誠實的等級。第 7、9 區從弱到半，都是「做了、有測試、但沒到能對外宣稱的程度」。教材裡沒有「半」，只有會不會；專案裡幾乎全是半。

第三，地圖本身會過時。十天前我以為十二區夠用，十天後最大的工作量落在地圖外。這不是地圖錯，是專案變了——而且變的方向（安全）正好是使用者最在意的。

明天

回到第 12 區｜做：coordinator 拿 roster 上的公鑰真的驗每份 receipt 的 device_sig，驗不過的 attempt 不算完成——這是把「有簽」變成「驗過」的那一步，也是第 12 區從有變有＋的證據。

參考

Day 01 的原始地圖與教材對照：三本中文書（bojieli/ai-agent-book、datawhalechina/hello-agents、WangRongsheng/awesome-LLM-resources）、英文對照（microsoft/ai-agents-for-beginners、huggingface/agents-course、humanlayer/12-factor-agents、mlabonne/llm-course、dair-ai/Prompt-Engineering-Guide、chiphuyen/aie-book）。
證據所在：docs/specs/demo-monday-mesh/reports/m5.md（9/16–9/21 各節）、app/src/lib/meshExecutor.test.ts、core/src/mesh_crypto/、docs/governance/BORROW-LEDGER.md。