urscos Tech - claude
type: channel
link: https://novel.urscos.com/category/claude/
items: 測試使用 SharpLensMcp:Roslyn 語意分析實戰與 CodeGraph 三層架構整合
items: CodeGraph 實戰心得：用「地圖導航＋精確搜索」提升 Claude Code 程式碼理解效率
items: Giving an AI Agent a Memory: Building a Self-Curating Knowledge Base for Game Development
items: Claude Code 摩擦點偵測實作：自動分析 Session 低效行為與改善建議
items: Claude Code 效率分析指標工具開發實作：Session 評分與效率報告生成
items: Workflow vs Agent 架構解析：Anthropic Building Effective Agents 重點整理
items: Claude Code Token 費用分析：費用計算、工具統計與 Web Dashboard 實作
items: 深入解析 Claude Code Session History：JSONL 格式、訊息結構與快取費用優化
items: 在大型遊戲專案中使用 Claude Code：分析 Session 並設計通用 Skills
items: Anthropic 改條款砍掉 96% AFK 額度：衝擊、競品動向與 Infra 因應策略

測試使用 SharpLensMcp:Roslyn 語意分析實戰與 CodeGraph 三層架構整合
type: item
date: 2026-08-21T02:28:00+00:00
description: 安裝 SharpLensMcp dotnet tool install -g SharpLensMcp D:\OlgCase\RS\XXXX>dotnet tool install -g SharpLensMcp 工具 'sharplensmcp' 已安裝。 安裝完成后啓動 sharplens sharplens D:\OlgCase\RS\XXXX>sharplens [10:33:08] [Information] SharpLens MCP server starting... 啓動 claude CLI 並嘗試使用 SharpLen 發現找不到對應的 SharpLens 工具 ❯ Use SharpLens to load the current C# solution. I don't have a SharpLens tool available in this session. It isn't among the connected MCP servers or built-in tools. What is connected for this repo: codegraph (mcp__codegraph__codegraph_explore) — a pre-built code-intelligence graph over the whole workspace, including all the C# under unity/. It returns verbatim symbol source + call paths + blast radius in one call. For "understand/locate/analyze C#" this covers what SharpLens/Roslyn-style loading would give you. UnityMCP (still connecting) — drives the Unity Editor. A couple of options: If you have a SharpLens MCP server you want to use, it needs to be added to your Claude Code MCP config (e.g. claude mcp add sharplens ... or in .mcp.json / settings). Once it reconnects I can drive it. Tell me how it's installed and I'll help wire it up. If the goal is just "load and analyze the current C# solution," I can do that now via codegraph — the index is already built for this repo (there's a .codegraph/ dir). Which do you want — set up the actual SharpLens server, or should I use codegraph to load/analyze the C# solution? And if the latter, what are you trying to find? 出現這個，應該還是要按照 mcp config 這邊發現必須手動加入設定到 mcp.json，如下： { "mcpServers": { "UnityMCP": { "type": "http", "url": "http://127.0.0.1:8088/mcp" }, "sharplens": { "type": "stdio", "command": "sharplens", "args": [], "env": { "DOTNET_SOLUTION_PATH": "d:\OlgCase\RS\HSLR_3\unity\unity.sln" } } } } 執行時發現錯誤 [Failed to parse] Project config (shared via .mcp.json)，必須將單反斜線 \改成雙反斜線 \： "DOTNET_SOLUTION_PATH": "d:\\OlgCase\\RS\\HSLR_3\\unity\\unity.sln" 將 SharpLens 改到 unity 項目啓動，再執行 reconnect 終於連上 SharpLens 連接上 SharpLen 後我們來測試看看，首先讓 claude…

CodeGraph 實戰心得：用「地圖導航＋精確搜索」提升 Claude Code 程式碼理解效率
type: item
date: 2026-07-08T06:52:00+00:00
description: 以下將 codegraph 納入實際項目運作查看使用效益 $ (py3.10) D:\OlgCase\RS\HXXR_3>codegraph init ┌ Initializing CodeGraph │ ◆ Initialized in D:\OlgCase\RS\HXXR_3 | | * Scanning files - 2,371 found | * Parsing code - done | * Resolving refs - done │ ◆ Indexed 2,371 files │ ● 69,568 nodes, 192,594 edges in 53.1s │ └ Done $ (py3.10) D:\OlgCase\RS\HXXR_3>codegraph status CodeGraph Status Project: D:\OlgCase\RS\HXXR_3 Index Statistics: Files: 2,371 Nodes: 69,568 Edges: 192,594 DB Size: 147.56 MB Backend: node:sqlite - built-in (full WAL) Journal: wal Nodes by Kind: method 25,000 field 16,000 import 8,000 enum_member 3,000 property 3,737 class 3,500 constant 2,515 file 2,365 namespace 1,581 struct 527 enum 421 variable 276 function 253 interface 207 Files by Language: csharp 2,285 python 42 xml 14 javascript 12 php 10 yaml 6 c 1 objc 1 [OK] Index is up to date 進入項目后提出需求給 cc cc先是透過llm分析出 keyword，然後查詢 codegraph 可用工具，再將關鍵詞輸入給codegraph "query": "UIAIDebugMenu AIDebugMenu aiwnd close hide AICondBlock refresh ai decision" 對話内容如下： 後續都是 Grep、Read ，如圖： codegraph 的實際使用流程并不是全面替代 grep、read，而是將項目 code roadmap 查找出來 先用 codegraph 做「地圖導航」 用戶提出需求 ↓ mcp__codegraph__codegraph_explore ← 只用一次 ↓ 目的：快速了解整個專案結構 "讓我先知道這個 codebase 長什麼樣" codegraph 的作用是給 Claude 一個高層次的程式碼地圖，知道哪些檔案、哪些 class、哪些 function 存在。 再來用 Grep + Read 做「精確搜索」 已知地圖後 ↓ Grep × 8 ← 搜尋具體關鍵字（如 "aiwnd", "CloseUI", 事件名稱） Read × 4 ← 讀取找到的具體檔案內容 後面因爲 Claude 已經知道方向了，就不需要再用 codegraph，改用更精準、更輕量的工具。 本質差異 工具 用途 比喻 codegraph 理解整體結構、依賴關係 看地圖 Grep 搜尋特定字串/pattern 用關鍵字查字典 Read 讀取完整檔案內容 打開具體頁面閱讀 沒有全部使用 codegraph 的原因大概也是如下： codegraph 執行成本 每次呼叫需要分析程式碼結構，在 CPU、IO 上比 grep 慢且耗資源。 必要性 第一次 codegraph 已給出足夠的「索引」，後續只需要針對性搜尋。 Claude 的工具選擇策略 不確定結構 → codegraph（掃描全局） 已知方向 → grep（精確定位） 找到目標 → read（深入閱讀） 如下是 Claude 的工作流程： codegraph（1次）→ 建立認知地圖 ↓ grep（8次）→ 精確定位關鍵程式碼 ↓ read（4次）→ 深入理解細節

Giving an AI Agent a Memory: Building a Self-Curating Knowledge Base for Game Development
type: item
date: 2026-06-29T19:46:00+00:00
description: Giving an AI Agent a Memory: A Self-Curating Knowledge Base for Game Development Why I stopped letting my AI assistant re-learn the whole codebase every morning — and built it a memory that curates itself. The problem I kept hitting On a fast-moving commercial Unity mobile-game project, the hardest part of plugging in an AI assistant wasn't the model — it was the context. Every session, the assistant started from zero: re-reading the codebase, re-deriving how a feature worked, often landing on a slightly different answer than yesterday. Meanwhile the actual knowledge was scattered across three places that quietly contradicted each other — daily commits, code-review notes, and ticket specs — and the game designers, who couldn't read C#, still needed to know "what does this feature touch, and is this request even feasible?" I didn't want a smarter prompt. I wanted the system to have a memory that stayed current on its own. The bet: three systems, one knowledge flywheel Instead of one monolith, I split the work across three cooperating systems: Game Source — the game client. It only produces material: a daily code review that emits pure "code does X + file:line" facts, with no opinions. Game Agent — the brain. It curates that raw material into a knowledge base, answers feasibility questions, and is deliberately kept outside the game repo so the whole mechanism is portable to the next project. Task — a self-built ticketing system. Requests the agent works out flow into it as tickets; completed tickets flow back into curation. That last loop matters: specs feed in, completed work feeds back, and the knowledge base gets stronger the longer the project runs. A flywheel, not a snapshot. The non-obvious trade-offs A few decisions went against my first instinct, and those are the ones worth writing down. I didn't use RAG. The reflexive move is to chunk everything, embed it, and retrieve by similarity. I tried that on a predecessor system and it was a poor fit for game-dev dat…

Claude Code 摩擦點偵測實作：自動分析 Session 低效行為與改善建議
type: item
date: 2026-06-19T01:34:00+00:00
description: Lab 2：摩擦點偵測器（Day 17-19） 要找出高摩擦 session，分類摩擦原因，輸出改善建議 2-1 摩擦偵測模組 新增 lib/friction.mjs： import { extractToolCalls } from './analytics.mjs'; const FRICTION_TYPES = { F1: { name: '工具執行失敗', severity: 'high' }, F2: { name: '重複修改同一檔案', severity: 'medium' }, F3: { name: 'Session 過長', severity: 'medium' }, F4: { name: 'Token 燃耗過高', severity: 'medium' }, F7: { name: '/compact 觸發', severity: 'low' }, }; /** * 偵測單一 session 的摩擦點 * @returns { type, severity, detail, recommendation }[] */ export function detectFrictions(messages) { const frictions = []; const turns = messages.filter(m => m.type === 'assistant').length; const toolCalls = extractToolCalls(messages); // F1：工具執行失敗 let toolErrors = 0; const errorMessages = []; for (const msg of messages) { if (msg.type !== 'user') continue; for (const c of msg.message?.content ?? []) { if (c.type === 'tool_result' && c.is_error) { toolErrors++; errorMessages.push(String(c.content ?? '').slice(0, 80)); } } } if (toolErrors > 0) { frictions.push({ type: 'F1', severity: toolErrors >= 5 ? 'high' : 'medium', detail: `${toolErrors} 次工具錯誤`, examples: errorMessages.slice(0, 3), recommendation: '在 CLAUDE.md 中補充路徑規範和常見錯誤處理方式', }); } // F2：重複修改同一檔案（3 次以上） const editCounts = {}; for (const call of toolCalls) { if (['Edit', 'Write', 'MultiEdit'].includes(call.name)) { const fp = call.input?.file_path ?? 'unknown'; editCounts[fp] = (editCounts[fp] ?? 0) + 1; } } const repeatedFiles = Object.entries(editCounts) .filter(([, n]) => n >= 3) .sort(([, a], [, b]) => b - a); if (repeatedFiles.length > 0) { frictions.push({ type: 'F2', severity: 'medium', detail: `${repeatedFiles.length} 個檔案被重複修改 3+ 次`, examples: repeatedFiles.slice(0, 3).map(([f, n]) => `${f} (${n}次)`), recommendation: '提問時一次說清楚所有需求，或使用 MultiEdit 批量修改', }); } // F3：Session 過長 if (turns > 50) { frictions.push({ type: 'F3', severity: 'medium', detail: `Session 長達 ${turns} 輪（建議上限 30 輪）`, examples: [], recommendation: '將大任務拆成多個獨立 session，每個 session 只處理一個子任務', }); } // F4：Token 燃耗過高 let totalTok…

Claude Code 效率分析指標工具開發實作：Session 評分與效率報告生成
type: item
date: 2026-06-15T05:36:00+00:00
description: 下面我們來開發使用 claude code 的效率指標圖表功能 效率指標計算器 目標：計算每個 session 的效率分數，找出你的高效與低效 session 新增效率指標模組 新增 lib/efficiency.mjs： import { extractToolCalls } from './analytics.mjs'; /** * 計算 session 效率指標 */ export function calcEfficiencyMetrics(messages) { const turns = messages.filter(m => m.type === 'assistant').length; const userMsgs = messages.filter(m => m.type === 'user').length; // 工具呼叫統計 const allToolCalls = extractToolCalls(messages); const toolCalls = allToolCalls.length; // 工具錯誤數 let toolErrors = 0; for (const msg of messages) { if (msg.type !== 'user') continue; for (const c of msg.message?.content ?? []) { if (c.type === 'tool_result' && c.is_error) toolErrors++; } } // 重複修改的檔案數 const editCounts = {}; for (const call of allToolCalls) { if (['Edit', 'Write', 'MultiEdit'].includes(call.name)) { const fp = call.input?.file_path ?? 'unknown'; editCounts[fp] = (editCounts[fp] ?? 0) + 1; } } const repeatedEdits = Object.values(editCounts).filter(n => n >= 3).length; // Token 統計 let totalTokens = 0; for (const msg of messages) { if (msg.type !== 'assistant') continue; const u = msg.message?.usage; if (u) totalTokens += (u.input_tokens ?? 0) + (u.output_tokens ?? 0); } const burnRate = turns > 0 ? totalTokens / turns : 0; const errorRate = toolCalls > 0 ? toolErrors / toolCalls : 0; // 效率分數 let score = 100; score -= Math.max(0, (turns - 15) * 2); score -= Math.max(0, (burnRate - 5000) / 1000); score -= errorRate * 200; score -= repeatedEdits * 10; score = Math.max(0, Math.min(100, score)); return { turns, user_msgs: userMsgs, tool_calls: toolCalls, tool_errors: toolErrors, error_rate: errorRate, repeated_edits: repeatedEdits, total_tokens: totalTokens, burn_rate: burnRate, efficiency_score: score, }; } /** * 將效率分數轉為等級 */ export function scoreGrade(score) { if (score >= 80) return { grade: 'A', label: '高效', emoji: '$' }; if (score >= 60) return { grade: 'B', label: '正常', emoji: 'O' }; if (score >= 40) return { grade: 'C', label: '偏低', emoji: '！' }; return { grade: 'D', label: '高摩…

Workflow vs Agent 架構解析：Anthropic Building Effective Agents 重點整理
type: item
date: 2026-06-13T09:18:00+00:00
description: 今天來看下這篇文章，第一次看的時候沒意識到重要性，後來看某個面試官在闡述 agent 工程師的區別時特地説到這篇文章才想起來 Anthropic building-effective-agents Anthropic 觀察了幾十個在生產環境落地的 LLM 系統，發現一個反直覺的規律：最成功的實作往往不是用最複雜的框架，而是用最簡單、可組合的模式。 他們把所有涉及 LLM 自主行動的系統統稱為 agentic system，但在這個概念下做了一個關鍵的架構區分—— Workflow 控制流由工程師寫死在程式碼中 LLM 是其中一個執行節點 行為可預測、可重複 適合任務邊界清晰的場景 Agent LLM 自己決定下一步怎麼做 工程師設計工具與邊界，不寫路徑 行為具有彈性、開放性 適合任務路徑不可預先知道的場景 核心差異不是「有沒有用 LLM」，而是控制流的所有權歸誰。Workflow 是工程師擁有控制流，Agent 是 LLM 擁有控制流。 Workflow 的五種標準模式 文章列出了五種在生產環境被反覆驗證的 workflow 模式，每一個都有清晰的適用場景： Prompt chaining 任務拆解成固定的串列步驟，前一步的輸出作為下一步的輸入。適合需要換精確度換延遲的場景。 Routing 先分類輸入，再導向不同的下游處理路徑。讓不同類型的任務各自優化，互不干擾。 Parallelization 同時跑多個 LLM call，結果再彙整。分為任務切分（sectioning）和多數決（voting）兩種形式。 Orchestrator-workers 一個 LLM 負責拆解任務、分配工作，多個 worker LLM 執行。子任務動態決定，不是預先寫死。 Evaluator-optimizer 一個 LLM 生成、另一個評估並給回饋，形成迴圈。適合輸出品質有明確評判標準的任務。 值得注意的是：orchestrator-workers 雖然看起來很像「agent」，但如果整個 orchestration 邏輯是由工程師寫死，LLM 只是按指令執行，它本質上仍是 workflow，只是更靈活的那種。 Agent 的本質：LLM 在環境回饋中自主循環 文章對 agent 的定義很精簡：LLM 在一個迴圈中，根據環境回饋（工具呼叫結果、程式執行結果）自主決策，直到任務完成或達到停止條件。 Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. Agent 的適用場景有兩個核心特徵：任務所需的步驟數量無法預先知道，以及正確路徑不能被硬編碼。 代價也很清楚：更高的延遲與成本、錯誤可能累積、需要更多測試與 guardrail。 我認為 workflow 和 agent 的區別，不只是技術架構的選擇，更是工程師思維方式的分水嶺。 Workflow 工程師的核心能力 Workflow 工程師的工作本質是系統設計與流程分解。他們需要把模糊的業務需求拆解成 LLM 可以處理的固定步驟，在每個節點插入適當的驗證與 gate，設計出可預測、可觀測、可維護的流程。這更接近傳統軟體工程的思維。 Agent 工程師的核心能力 Agent 工程師的工作核心則轉向工具介面設計（ACI）與信任邊界管理。你不再寫「做 A 然後做 B 然後做 C」，而是設計「給 LLM 什麼工具、工具的文件怎麼寫、失敗的時候怎麼恢復、在哪些節點需要人工確認」。 文章最犀利的觀察之一：他們在開發 SWE-bench agent 時，花在優化工具上的時間比花在優化 prompt 上的時間還要多。這個細節揭示了 agent 工程的重心所在——不是提示詞魔法，而是介面設計。 兩者都需要的判斷力 文章反覆強調的一個原則是：不要過度建構。很多時候，一個被良好優化的單一 LLM 呼叫就夠了。真正困難的判斷是——什麼時候從 workflow 升級到 agent？ 判斷標準很明確：如果任務的正確路徑可以被預先寫下來，用 workflow。如果連「需要哪些步驟」本身都是未知的，才需要 agent 的自主性。 三個核心原則 文章最後給出三條設計 agent 的指導方針，我認為這三條同樣適用於評估一個 agent 工程師的成熟度： 1、Simplicity：保持 agent 設計的簡潔。複雜性應該因需求增長，而非因工程師的偏好增長。 2、Transparency：明確展示 agent 的規劃步驟。可觀測性是信任的基礎，也是…

Claude Code Token 費用分析：費用計算、工具統計與 Web Dashboard 實作
type: item
date: 2026-06-09T11:53:00+00:00
description: 這個章節要説明關於 Claude Code Analytics 的部分内容 計算 token 費用、分析工具使用模式、建立 Web Dashboard 首先加入 Token 計算器 這邊要查詢所有 session，計算每個 session 的 token 用量與美金費用 新增費用計算模組 新增 lib/costs.mjs： const PRICING = { 'claude-opus-4': { in: 15, out: 75, cw: 18.75, cr: 1.50 }, 'claude-sonnet-4': { in: 3, out: 15, cw: 3.75, cr: 0.30 }, 'claude-haiku-4': { in: 0.80, out: 4, cw: 1.00, cr: 0.08 }, }; /** * 從 model ID 推斷定價方案 */ function getPricing(modelId) { const id = modelId?.toLowerCase() ?? ''; if (id.includes('opus')) return PRICING['claude-opus-4']; if (id.includes('haiku')) return PRICING['claude-haiku-4']; return PRICING['claude-sonnet-4']; } /** * 計算單條 assistant 訊息的費用 */ export function calcMessageCost(msg) { if (msg.type !== 'assistant') return 0; const usage = msg.message?.usage; if (!usage) return 0; const p = getPricing(msg.message?.model); const M = 1_000_000; return ( (usage.input_tokens ?? 0) / M * p.in + (usage.output_tokens ?? 0) / M * p.out + (usage.cache_creation_input_tokens ?? 0) / M * p.cw + (usage.cache_read_input_tokens ?? 0) / M * p.cr ); } /** * 計算整個 session 的 token 統計與費用 */ export function calcSessionStats(messages) { let input = 0, output = 0, cacheWrite = 0, cacheRead = 0, costUSD = 0; let models = new Set(); let toolCalls = 0, toolErrors = 0; for (const msg of messages) { if (msg.type !== 'assistant') continue; const usage = msg.message?.usage; if (usage) { input += usage.input_tokens ?? 0; output += usage.output_tokens ?? 0; cacheWrite += usage.cache_creation_input_tokens ?? 0; cacheRead += usage.cache_read_input_tokens ?? 0; costUSD += calcMessageCost(msg); } if (msg.message?.model) models.add(msg.message.model); for (const c of msg.message?.content ?? []) { if (c.type === 'tool_use') toolCalls++; } } // 計算 tool 錯誤數（在 user 的 tool_result 中） for (const msg of messages) { if (msg.type !== 'user') continue; for (const c of msg.message?.content ?? []) { if (c.type === 'tool_result' && c.is_error) toolErrors++; } } return { input_tokens: input, output_tokens: output, cache_write_to…

深入解析 Claude Code Session History：JSONL 格式、訊息結構與快取費用優化
type: item
date: 2026-06-07T09:33:00+00:00
description: session保存格式結構如下： json格式化如下： 為什麼選擇 JSONL？ Claude Code 沒有使用資料庫，而是選擇了最簡單的格式：每個 session 一個 .jsonl 檔案，每行一條 JSON 訊息。 比較面向 JSONL 格式 關聯式資料庫 讀取方式 任何文字編輯器、cat 需要 DB 驅動 追加速度 極快（append-only） 需要 transaction 查詢能力 低（需全掃） 高（SQL） 跨機器遷移 複製檔案即可 需要 dump/restore 故障恢復 行級別，單行壞掉不影響其他行 依賴 transaction log 版本控制 可用 git 追蹤 不適合 結論：AI 對話是只增不改、需要人類可讀、不需要複雜查詢的應用場景，所以JSONL 是最合適的選擇。 然後可以看到jsonl裏面的chat内容包含以下 session 啟動 ├── 寫入第一條 user 訊息 ├── 寫入 assistant 回覆 ├── 寫入 tool_result ├── 寫入下一條 user 訊息 ... └── session 結束（檔案不再修改） 這説明在 ~/.claude/projects/ 裡每一個 .jsonl 檔案都對應一個獨立的 session。如下： ~/.claude/ ├── projects/ │ └── -Users-jack-myproject/ ← 專案目錄（路徑編碼） │ ├── abc123.jsonl ← session 1 │ ├── def456.jsonl ← session 2 │ └── ghi789.jsonl ← session 3 └── settings.json 然後可以看到訊息結構如下： 頂層訊息結構 { "uuid": "3a7f-...", // 每條訊息的唯一 ID "parentUuid": "2b1e-...", // 父訊息 ID（形成對話樹） "sessionId": "abc-123", // 所在 session 的 ID "timestamp": "2025-06-15T10:30:00.000Z", "type": "user", // 訊息類型（見 §3） "isSidechain": false, // 是否為旁支對話 "cwd": "/Users/jack/myproject", "version": "1.0.35", "message": { ... }, // 核心內容（見下） "toolUseResult": { ... } // 工具執行結果 } User 訊息： { "message": { "role": "user", "content": "幫我分析這段程式碼" } } Assistant 訊息（含 token 統計）： { "message": { "role": "assistant", "id": "msg_01...", "model": "claude-opus-4-20250514", "content": [ ... ], "stop_reason": "tool_use", "usage": { "input_tokens": 5420, "output_tokens": 312, "cache_creation_input_tokens": 20238, "cache_read_input_tokens": 18500 } } } 然後訊息分爲以下幾類 type 觸發時機 包含的關鍵資訊 user 你送出任何訊息 你的文字、tool_result assistant Claude 回覆 文字、tool_use、usage summary 執行 /compact 後 msg.summary（摘要文字） system Session 初始化 系統提示詞 然後 Assistant message 的 usage 欄位 欄位 說明 費用倍數（相對 input） input_tokens 本次送出的 token 數 1× output_tokens Claude 生成的 token 數 5× (opus-4) cache_creation_input_tokens 首次建立 cache 的 token 1.25× cache_read_input_tokens 從 cache 讀取的 token 0.1× 這裏面關於 token 的重要信息 Claude Code 會自動快取你的 CLAUDE.md、專案檔案等長文件。當同一 session 中多次發送相似的上下文，後面的訊息可以從快取讀取，費用只有原來的 10%。 實際例子： 沒有快取：20,000 input tokens × $15/MTok = $…

在大型遊戲專案中使用 Claude Code：分析 Session 並設計通用 Skills
type: item
date: 2026-05-23T06:06:00+00:00
description: 本文以一個中型 Unity 單機遊戲專案為基礎，探討在程式碼總量逼近百萬 token 的情境下， 如何透過設計專案專屬的 Claude Code Skills，有效降低 token 消耗並提升查詢效率。 一、Session 數據初步觀察 從 token 總量與增長趨勢來看，本次 session 並無明顯異常。 然而，考慮到大型遊戲專案的程式碼總量可能突破百萬 token，核心問題在於： 當專案規模達到這個等級時，Claude Code 的 token 消耗是否會出現急劇增加的情況？ 然而，考慮到大型遊戲專案的程式碼總量可能突破百萬 token，核心問題在於： 當專案規模達到這個等級時，Claude Code 的 token 消耗是否會出現急劇增加的情況？ 回頭檢視 Loading Trace（CC 每次啟動時記錄的工具載入紀錄）後發現， 本次 session 中沒有任何 Skills 被觸發。另一個 session 也僅觸發了一個 Skill。 另外一個 session 也只有觸發一個 skill 這是因為目前的專案規模只屬於中型：無大型底層架構、無 Client/Server 架構（目前為單機遊戲）， 整體框架較小，尚未到需要 Skills 介入的門檻。 二、為什麼需要設計專案專屬 Skills？ 將專案截圖與目錄結構提供給 Claude Code 分析後，得到的關鍵洞察是： 我目前沒有設計對應skill，這個項目嚴格說算中型而已，所以我才提這個需求，以後應該會用上，你有辦法根據這個去設計 skill 嗎？需要修改對應項目設計嗎？（譬如script都放到Assets\\Scripts），然後這是另外的session，但都是同一個項目 這上面已經間接説明了，項目目錄規劃是能夠極大的優化 cc 的查詢效益，當然這是基於目前的 agent runtime 而言。 這是「用 200 行 markdown 救 8 次整檔 Read」的最高 ROI。長這樣（草稿）： --- name: unity-script-index description: | 在 D:\OlgCase\**** Unity 專案中定位 C# 腳本。 當使用者問「某某邏輯在哪 / 哪個檔處理 X / 我要改 Y 系統」時觸發。 返回目錄分區索引 + 一行用途，避免整檔 Read。 --- ## Assets\Scripts 目錄速查 - `Module/` — 遊戲核心系統。StageManager*（關卡）, SkinUnlockManager（外觀解鎖）... - `AI/` — AI 行為。AIUtils 是共用工具 - `UI/` / `NewUI/` — UI 控制（NewUI 較新） - `Data/` — 設定資料載入 - `Utils/` — 通用工具，含 GmCommand* GM 命令系統 - `EventCtrl/` — 事件 / 條件處理 - `Luban/def/` — Luban 生成的設定 schema（**勿手改**） ## 使用流程 1. 先 Grep 關鍵字（類別名 / 方法名）找精準位置 2. 再 Read with offset/limit，不要整檔 3. 如果關鍵字落在 Luban\def\，那是生成檔 — 真正的設定在 Resources\design\*.json 三、根據工單類型設計 Skill 觸發邏輯 實務上，工單通常分為兩類：修 Bug 與 新增需求。 兩者的資訊結構不同，對應的 Skill 觸發邏輯也應有所區別。 下列是發送給 cc 的内容 可行，不過我建議你參考下我在工單系統填寫的方式分析下 觸發邏輯是否需要修改：（下面有分 bug、需求兩種，我覺得你應該需要分析觸發區別） Case1. 【修bug】 在切換到我方角色時會瞬間卡頓，測試發現是計算威脅值太多了，如果敵方有40個entity，就要計算40次，單次都必須2~3ms，全部加起來就必須 50~60 ms Assets\Scripts\AI\AIUtils.cs line.596 AIUtils.GetMoveRangeChunkId 從這裏觸發 Assets\Scripts\Module\StageManager.cs line.1324 genFlowMap 這個執行的次數太多 Case2. 【新增需求類】 在 AICondition 的每一個 AICondBlock 都加入 Params5 參數，這是用來代表該 block 觸發後的冷卻效果，參數設定規則如下： colddown: -1,只會使用一次 colddown: 0 or 沒填, 正常使用(機率骰到 符合條件就會用) colddown: >0, 用一次後進入CD,CD歸0後才可以再度使用…

Anthropic 改條款砍掉 96% AFK 額度：衝擊、競品動向與 Infra 因應策略
type: item
date: 2026-05-19T22:15:00+00:00
description: Anthropic 上週宣布，6/15 起訂閱額度一分為二。 人類在場、有互動的 Human-in-the-loop 用途（像是 Claude Code 日常使用）繼續吃原本的額度 自動化工作流 Away From Keyboard（AFK）則改吃獨立的月度 credit——Pro 給 $20、Max 5x 給 $100、Max 20x 給 $200 這對 AFK 工作流和 harness engineering 來說是一記重拳，但同時也是重新審視自己 agent infra 的好時機。 社群估算，Max 20x 的重度用戶，每個月 AFK 跑下來消耗的算力大約等值 $5,000 API credit。現在切成 $200 credit。$5,000 變 $200，是 96% 的砍幅，不是 40%。 Anthropic 的真正算盤，並不是省成本。這個動作和 4 月封殺 OpenClaw 是同一條邏輯線——把「訂閱」重新定義為「人類在場、有互動」的場景，把 AFK 推到按量計費的 API。訂閱是給你坐在螢幕前用的，不是給機器人跑的。 對高階個人用戶：harness engineering 直接中槍 高階工程師已經炸鍋了。賣出第一門 Claude Code 付費課程的 Matt Pocock 公開說： I have never experienced such a frustrating lack of clarity over the basic terms of usage. 然後直接在 X 上把學員導流到 Codex。這不是情緒發洩，是他的課程商業模式受到直接衝擊——工具鏈綁死在一家供應商，對方一改條款，學員手上全是過期教材。 對在公司裡建立 harness engineering 的人來說，這更是一記重傷。 Harness 的核心價值，就是把 AI 變成「可被工程化調度的工作流」，具體來說包括： 批次跑任務 自動讀 issue 自動開 PR 多輪 code review 背景研究 多 agent 並行 CI/CD 裡自動修 bug 半夜自己跑測試、整理結果、回報狀態 這些全都是 AFK。Anthropic 這次等於是把 harness engineering 最重要的那條路切出來，丟進一個小得可憐的 credit pool。 競爭對手趁虛而入 對手當然不會放過這個空檔。 ChatGPT Pro 從 $200 直接砍到 $100；Codex 企業版提供兩個月免費試用，明確鎖定從 Anthropic 遷移的客戶，0 seat fee、30 天遷移窗口。Altman 甚至在公告底下回了一句「ok boomer」。 廣大網友一片歡呼——還好 GPT-4.1 夠猛，換過去反而有升級感。 老實說，我最近也覺得 Codex 出的 code 品質又快又好。 重新思考你的 Agent Infra 話說回來，別以為跳過去 Codex 就解決問題了。這件事更值得讓你想清楚一件事：你的 agent infra 夠健壯嗎？ 第一，vendor lock-in 就是風險。 供應商可以在週四傍晚改條款，你的自動化流程隔天就停一半。以前 vendor lock-in 的風險是理論，現在是帳單。如果你的核心業務壓在單一供應商的 API 上，這個週末應該花兩小時認真評估一下切換成本。 第二，個人開發者可以考慮 Claude + Codex 雙棲。 互動式寫程式留 Claude，AFK 自動化任務走 Codex 或 OpenAI API，費用結構比較適合批次跑。兩家都養著，哪家改條款你都有退路。別忘了，ChatGPT 以前也搞過不少讓人不爽的事⋯⋯ 第三，地端才是企業 harness engineering 的最終歸宿。 地端不只是資安問題，更是風險控管。現在 LLM 廠商太不穩定，把 infra 壓在雲端、跟著廠商反覆橫跳，只是暫時解法。有地端算力，才是真正的核心競爭力。 Qwen3 27B、Gemma 4 31B 這個量級的 dense 開源模型，在多數 coding 任務上已經堪用。這不是在省 token 費，而是你願意花多少代價，押在一份不知道哪天又會改的條款上。