⚡ CCAF 考前掃讀

按你的錯誤數據排序:🔴 還在錯 → 🟡 不穩 → 📖 誘答字典。每卡可 📋 複製回 Claude 討論。← 回模考

🔴 紅區——最近仍在錯的觀念

R1

Fixed pipeline vs Adaptive decomposition

流程可預測、階段固定(多面向 review、classify→extract→validate→load)→ fixed sequential pipeline,不需要 agent 自主性。root cause 未知的開放調查→ dynamic adaptive:形成假設 → 聚焦調查 → 由發現決定下一步。 cause unknown / could be X, Y, or Z → adaptive;same stages every time / never vary → fixed pipeline
R2

Grep 讀內文、Glob 配檔名

Grep = g/re/p(regular expression)→ 搜檔案內容:function 定義、呼叫點、error 字串、import。Glob = global 檔名萬用字元(**/*.test.ts)→ 只配路徑,永不看內文。探索順序:Grep 入口 → Read → 跟 import 再 Grep,別一次讀完。 找「寫在檔案裡的東西」= Grep;找「某類檔案在哪」= Glob
R3

Edit 失敗 → Read + Write,不是 retry

Edit = 精確字串比對(非 regex)+ 唯一錨點才動手。錨點不唯一(字串出現 N 次)是結構性失敗,retry 一萬次結果相同。標準 fallback = Read 整檔 + Write 修正後完整版。 "transient errors usually resolve" = 廢話型誘答——先判斷失敗是隨機的還是結構的
R4

標準系統用社群 server、專屬系統自建

Jira / GitHub / Postgres 這類標準工具→ 用現成的 established community MCP server。公司自有/專屬系統(proprietary)→ 社群不可能有現成的 → 自建 custom server。 鎖字 proprietary = 這半邊必自建;兩個都自建 = 重造輪子、兩個都用社群 = 不存在
R5

Enum 演化 → enum + "other" + detail

類別會持續出現新型 → 已知的留 enum(保結構化)、加 "other" + free-text detail 當未知的合法出口。「每次發現就擴 enum + redeploy」= 永遠慢一拍:新類型第一批必然被錯分、且錯分無聲。other 是緩衝區,常見了再轉正。同心法:source 可能沒有的欄位 → optional/nullable 防捏造keep arriving / new types emerge + 選項「每次改 schema redeploy」= 追不上現實的陷阱
R6

裁剪(filter/projection)≠ 壓縮(summarize)

回傳 40+ 欄只用 5 欄 → 進 context 做 deterministic 裁剪(PostToolUse 轉換 / result projection = SELECT 指定欄位),留下的原值無損。summarize = LLM 有損壓縮,precise data(金額/ID/日期)會走樣;/compact 時機太晚;大 context window = 塞得下 ≠ 讀得到returns 40+, uses five → 找「filter down / projection / before entering context」;precise 資料不能過 lossy 層
R7

死板對應表陷阱(6/13 真考錯)

評級/分類不一致 → 明確判準 + 具體範例(讓模型帶著判斷力看 context)。靜態 issue-type→severity 對應表 = rigid,丟失 context:同一 issue type 因 code path、exposure、criticality 不同該給不同 severity。官方原話:rigid approach oversimplifies。 選項出現 static mapping / lookup table / 一律對應 → 警惕;正解通常是 criteria + examples
R8

語意重疊要修兩邊(6/13 真考錯)

兩個工具名稱/描述語意重疊造成選錯 → 兩邊都處理:重命名含糊的那個 + 各給專屬描述,消除重疊本身。只擴充其中一個的描述 = partial fix——另一個的含糊名字照樣吸走流量。 兩個工具都含糊時,選「消除兩者間重疊」的選項,刪掉「只動一邊」的
R9

Process workaround 陷阱(6/13 真考錯)

系統的問題用技術解,不是改人的流程。「叫開發者把 PR 拆小」= 把負擔轉嫁到開發流程,review 系統的分析方法沒變好,且邏輯相關的變更本來就該一起審。正解:把 review 拆成聚焦多輪(per-file local pass + cross-file integration pass)對抗 attention dilution。 選項要求「使用者/開發者改行為」來遷就系統 = 轉嫁型,先刪

🟡 黃區——答對但不穩,一句話確認

Y1

MCP Resources = 給目錄,不是更快的手電筒

agent 大量 exploratory call 只為了「知道有什麼」→ server 曝露 resources(可瀏覽的唯讀資料目錄),盲搜直接消失。rate limit / cache = 讓浪費變快變便宜,浪費還在。
Y2

CI instance 要餵 project CLAUDE.md

CI 的 reviewer 是全新 instance,不知道你的內規。誤 flag 刻意慣例(deliberate, documented conventions)→ 載入 CLAUDE.md(準則/慣例/fixtures)。再大的 model 也推不出私有慣例——那是資訊不是智力。
Y3

明確 criteria > 態度指令

"be conservative" / "only high-confidence" = 官方點名無效的通用指令。有效的是可判定 yes/no 的具體條件:「untrusted input 流到 sensitive sink 且無 sanitization 才 flag」= 每個 finding 要有 concrete exploit path。單一類別 90% 誤報且短期修不了 → 暫時關掉該類保全體信任。
Y4

Few-shot 三原則

(1) targeted:4–6 個瞄準模糊案例,不是 10–15 個 clear case;(2) 附推理:寫明為何選 A 不選 B(worked examples > declarative rules);(3) 混排對比:flag/no-flag 交錯,分組會破壞 decision boundary。
Y5

Batch:結果無序、失敗靠 custom_id 單獨重送

batch 結果不保證順序("arrive in submission order" = 假前提);部分失敗是正常可恢復狀態 → 用 custom_id 對回、只重送失敗的。適用性:省 50%、最長 24hr、無 latency SLA → 只給非阻塞流程,merge gate 保持 real-time。
Y6

「成功但空」≠「取不到」

空結果兩種來源要在 response 結構區分:合法空(查成功沒 match / 空白表單)vs access failure(timeout / 憑證過期)。工具回 isError + errorCategory(transient/validation/business)+ isRetryable;否則 agent 對合法空狂 retry、對真失敗當「查無資料」寫進結論(silent swallow)。
Y7

Round-trips 多 → 先想原生 parallel tool use

Claude 原生支援同一 turn 吐多個 tool call。兩個工具總是分開兩輪叫 → prompt 一句引導 batch 即可。別選 composite tool(增 surface area)、speculative execution(over-engineering)、max_tokens(capacity 誤歸因)。「Claude 沒做 X」→ 先查是不是原生就會、只是沒被引導。
Y8

下游要程式 parse → --json-schema 強制

CI 裡要機器可讀輸出 → claude -p + --output-format json + --json-schema(沒填對送不出去的表單)。prompt 拜託「請輸出 JSON」= 軟性,偶爾還是亂。API 側同理:tool_use + JSON schema 強制。非互動卡住 = 少了 -p
Y9

三犯釘死句(R4 已避開,最後默背一次)

「個別已 9X%」= 能力足夠,只缺辨識 → few-shot,絕不選 preprocessing layer / separate model call。「12+ tool calls + redundant fetch + sequential」= 執行結構壞了 → 才用 decompose + parallel + shared context。signature 小用 prompt、signature 大用架構。

📖 誘答型字典——看到就扣分的選項長相

T1

假前提型

選項裡的機制陳述本身是假的:"results arrive in submission order"(batch 無序)、"batches cannot recover from partial failure"(custom_id 可以)、"Claude Code watches the filesystem"(沒這機制)、不存在的 flag(--batch、CLAUDE_HEADLESS)。背熟規格直接刪。
T2

聽起來合理的廢話型

"transient errors usually resolve"(結構性失敗不會自己好)、"read the document carefully"、"spend equal effort on every file"——指示不是機制。問自己:這句話有沒有改變任何確定性的東西?
T3

Capacity 誤歸因型

升 context window / max_tokens / 調 threshold 去解「注意力稀釋、行為、pattern 辨識」問題。塞得下 ≠ 讀得到(lost in the middle);空間不是行為的藥。
T4

無關升級型

題目明說 technically correct / accurate / 個別 9X% → 能力不是瓶頸,升 model tier 無效。缺的是 process(自評、criteria、context),不是智力。
T5

轉嫁型(問客戶/叫開發者)

agent 的問題丟給人:問客戶「這樣夠嗎」(降滿意度)、叫開發者拆 PR(process workaround)。系統的問題用技術解。
T6

Over-engineering 型

separate model call / preprocessing layer / speculative execution / 訓練 classifier / 第二個 model 過濾——prompt 層能解就不動架構。修補順序:prompt → description → hook → architecture(便宜到貴)。
T7

事後補救型 vs 事前 gate

compliance / 金流 / PII:nightly audit、事後掃描刪除、加 log 追溯 = 違規已發生。單次事故不可接受 → programmatic gate 事前擋(hook / prerequisite)。99% 靠 prompt 仍 = 非零失敗率。
T8

錯怪下游型

subagent 全部正常執行、報告仍缺角 → 問題在 coordinator 拆解太窄(被分配了什麼),不是下游 drift、不是 synthesis 刪內容、不是 model bias(無解歸因 = 陷阱)。

🔤 這幾天卡過的英文詞

V1

詞彙表

flag (v.)標記為問題、開 finding
deliberate刻意的(不是手滑);documented conventions = 有文件的團隊慣例
exploratory探索性的(為了摸清有什麼,不是拿特定答案)
expose開放/曝露出來給外部用
browsable directory可瀏覽的目錄(MCP resources)
filter down to過濾到只剩…
projection投影 = 只挑需要的欄位(SQL 的 SELECT 指定欄)
sink / sanitization敏感匯入點(SQL/eval/HTML,資料流終點)/消毒(跳脫、驗證)
exploit path具體攻擊路徑(theoretical = 只有想像,沒有路徑)
idempotent冪等:跑一次和 N 次結果相同(LLM 呼叫其實非冪等)
bookkeeping對帳、追蹤管理
transient ↔ structural暫時性(可 retry)↔ 結構性(retry 無效)
stale過期失效的(tool result / session)
provenance / attribution來源鏈/出處歸屬(claim-source mapping)
attention dilution注意力稀釋(大 PR 單輪 review 忽深忽淺)
of which其中(40+ fields, of which five…= 40 多個裡面只有 5 個…)
prerequisite前置條件(programmatic prerequisite = 程式化前置 gate)
least privilege最小權限(只給角色需要的 tool)
考完回 模考站|卡片複製後直接貼給 Claude 就能討論。祝順利 🎯