KM Inside · 知識洞見 Context Engineering / 2026.10

Context 要給多少？

開發團隊的分層 Context 配置
Topic
Context Engineering
Model
範圍 6 層 × DIKW
Sources
研討會＋業界實踐
Date
2026.10.08
01 · The Question

到底要給 AI 多少文件？

−給太少
AI 只能猜
  • 不知道業務規則、術語、隱坑
  • 產出「看起來合理」但是錯的
✓剛好
最小的高信號集合
“the smallest possible set of high-signal tokens”
— Anthropic, Effective context engineering
+給太多
Context Rot
  • 輸入越長，表現越差
  • 規則互相矛盾時隨機挑一條
  • 成本與延遲一起上升
核心 問題不是「給多少」，而是什麼時候、由誰、給哪一層的知識。
KM Inside · Context Engineering 問題
02 · My Model · 範圍軸

Context 是漏斗：越往內越窄、越精準

01團隊知識庫過去累積的歷史文件 ｜ 探索、面對未知時使用
02專案業務知識需求收集階段產生 ｜ 不一定全進 Spec
03團隊協作知識角色之間交換 ｜ 各角色的特性知識
04角色工作 Context把 Spec 轉成「我能工作」的 context
05執行 ContextSource code・Code style / Rule・特定指示
06驗證 Context用來檢核產出結果
範圍
組織 → 單一任務
精準度
模糊 → 精準
壽命
長期 → 單次
回答的問題
誰擁有？何時用？
KM Inside · Context Engineering 分層模型
03 · Reference · 研討會分享

另一種切法：DIKW 知識建模四層

↓靠人沉澱
自上而下
↑引擎提煉
自下而上
L4約束偏好 · Wisdom
靠人沉澱，自上而下指導
L3業務領域 · Knowledge
引擎主導，自下而上提煉
L2術語流程 · Information
術語辨析、流程鏈路
L1代碼配置 · Data
代碼、配置等原始事實
四類高價值知識
複雜業務全景 代碼隱坑 術語辨析 跨倉鏈路
共同點
代碼本身
給不出可靠答案
KM Inside · Context Engineering DIKW 參考
04 · Insight

兩條軸：「範圍」× 「知識型態」

知識型態軸 → 範圍軸 ↓
Data程式碼・設定
Information術語・流程
Knowledge業務領域
Wisdom約束・偏好
01團隊知識庫
02專案業務知識
03團隊協作知識
04角色工作
05執行
06驗證
範圍軸 · 我的分層
誰擁有？什麼時候用？
型態軸 · DIKW
這是什麼知識？誰產生得出來？
交叉之後，每一格都有自己的載入方式
主要成分次要成分（示意）
KM Inside · Context Engineering 兩條軸
05 · Loading Strategy

交叉之後，載入方式自然浮現

Wisdom約束・偏好・禁忌
小而常駐
Always-on
  • 每層都要有，越內層越具體
  • CLAUDE.md・constitution・steering
  • 每檔建議 < 200 行
Knowledge / Information業務・術語・流程
建索引、按需載入
On-demand
  • 依「任務類型」路由，不依文件分類
  • 例：新增 API → 讀 A、B；改 DB → 讀 C
Data程式碼・設定
不預塞、即時檢索
Just-in-time
  • 讓 agent 自己 grep、讀檔
  • 只留檔案路徑等輕量指標
判準 只有程式碼本身給不出可靠答案的知識，才值得寫成文件；程式碼答得出來的，讓 agent 自己讀。
KM Inside · Context Engineering 載入策略
06 · Industry Practice

業界做法對照

我的分層
載入方式
業界對應
01團隊知識庫
搜尋／MCP 拉取
Codified Context cold memory：34 份規格按需載入｜騰訊 開發對話抽成經驗，MCP 檢索，每次平均注入 2.4 條
02專案業務知識
按需載入
阿里 後端知識庫「業務層」（術語、業務↔系統映射）｜Kiro product.md
03團隊協作知識
常駐，但要短
Claude Code 專案 CLAUDE.md｜Kiro tech.md・structure.md｜Spec Kit constitution｜阿里 架構層・基建層
04角色工作
轉換＝編譯器
BMAD SM agent 把切分後的 PRD／架構轉成 story 檔，dev agent 保持精簡｜Spec Kit plan → tasks｜Codified Context 19 個專責 agent
05執行
路徑帶入＋即時檢索
Claude Code 依路徑生效的 rules、子目錄 CLAUDE.md｜Kiro fileMatch 模式
06驗證
獨立 context
BMAD QA 開新對話審查｜Spec Kit converge｜Anthropic subagent 在乾淨 context 裡工作
KM Inside · Context Engineering 業界對照
Part 02 · 補強建議

讓分層真的運作起來

01五個屬性 02轉換產物 03隔離驗證 04回寫迴路
補強 01

每一層都要定義五個屬性

01
Owner
誰負責維護？
技術負責人 ＋ AI agent
02
產生方式
人寫，還是 AI 提煉？
人寫為主
03
存放處
放在哪裡？
repo 的 CLAUDE.md／AGENTS.md
04
載入方式
常駐、按需或檢索？
常駐
05
Token 預算
最多能佔多少？
< 200 行
範例以「03 團隊協作知識」為例（卡片下方灰底）
為什麼 少了這五個屬性，每一層最後都會想「全部塞進去」。
KM Inside · Context Engineering 補強 01
補強 02

Context 是往下「編譯」，不是往下傳遞

01知識庫
探索研究
02業務知識
需求收斂
Spec規格文件
角色拆解
04角色工作包
執行
05程式碼／PR
驗證
06驗證結果
關鍵：角色工作包
把相關的業務規則、API 契約、要動的檔案路徑直接抄進工作包
→ 執行層不必回頭翻上層文件
業界
BMAD story file ｜ Spec Kit plan → tasks
落地
規格文件已有必備欄位 → 再補一份「角色工作包」模板
KM Inside · Context Engineering 補強 02
補強 03

驗證 Context：先定義、要隔離

執行 Agent
Spec／AC程式碼 diff規則 推理過程試錯紀錄
交接內容
✓ Spec／AC
✓ diff
✓ 規則
✕ 推理過程
✕ 試錯紀錄
驗證 Agent
乾淨的 context
不被執行者說服
  • 01.事先定好AC 與測試案例在執行前就產出——例如讓 QA 依 Spec 先產出 test case
  • 02.隔離驗證者不接手執行者的推理與試錯，只拿 Spec／AC、diff 和規則，避免自己說服自己
  • 03.硬約束交給確定性機制用 hooks／CI 擋；CLAUDE.md 只是 context，不是強制設定
KM Inside · Context Engineering 補強 03
補強 04

補一條由下往上的回寫迴路

觸發來源
驗證失敗
Code Review 發現
線上事故
→
提煉與治理
Review→Dedup→Merge
抽出隱坑、術語、約束
未確認的先加標記
→
回寫目的地
03 團隊協作知識
01 團隊知識庫
下一輪任務自動受益
騰訊 QQ 瀏覽器
經驗抽取經 Review → Dedup → Merge，垃圾比例 ~90% → ~5%
阿里後端知識庫
評審、CR、事故回寫閉環；「未確認」標記的條目 agent 不當事實
建議 Owner
專責整理知識的 AI agent——對應 DIKW 的「自下而上提煉」
KM Inside · Context Engineering 補強 04
07 · Rules of Thumb

到底要給多少：六條經驗法則

01
常駐要小
CLAUDE.md 官方建議 < 200 行；入口檔只指路，不放正文
02
依任務路由
依任務類型決定讀哪些檔，不依文件分類全部載入
03
外拉內推
外層讓 agent 搜尋或用 MCP 拉；內層由系統主動帶入
04
子 agent 回摘要
回傳約 1–2k tokens 的摘要，不回原文
05
多不等於好
Context rot：輸入越長、表現越差；找最小的高信號集合
06
慢慢長出來
Context 無法寫單元測試；別整套照抄，實際用一陣子再調
KM Inside · Context Engineering 經驗法則
Summary
Context 是漏斗
不是倉庫
↓
往下編譯
每層轉換都有產物
⇣
按需載入
常駐小、其餘用拉的
⊘
隔離驗證
先定義、乾淨 context
↑
往上回寫
失敗與事故變成知識
KM Inside · Context Engineering 總結
References

參考來源

Anthropic · 2025.09Effective context engineering for AI agentsanthropic.com/engineering/effective-context-engineering-for-ai-agents
Böckeler · martinfowler.com · 2026.02Context Engineering for Coding Agentsmartinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html
Vasilopoulos · arXiv 2602.20478 · 2026.02Codified Context: Infrastructure for AI Agents in a Complex Codebasearxiv.org/abs/2602.20478
阿里技術分解一座冰山：後端系統「AI 知識庫體系」建設實踐53ai.com/news/zhishiguanli/2026072467892.html
騰訊技術工程AI Coding 的下一站，不是更會寫代碼，而是更懂團隊53ai.com/news/zhishiguanli/2026073006984.html
BMAD MethodBMAD Knowledge Base（story file、devLoadAlwaysFiles）github.com/bmad-code-org/BMAD-METHOD
KiroSteering 文件kiro.dev/docs/steering
GitHubSpec Kitgithub.com/github/spec-kit
Claude Code DocsHow Claude remembers your projectcode.claude.com/docs/en/memory
LangChain · 2025.07Context Engineering for Agentslangchain.com/blog/context-engineering-for-agents
Chroma ResearchContext Rottrychroma.com/research/context-rot
研討會分享知識建模・DIKW 四層（現場照片整理）原始出處未查到；內容與阿里後端知識庫實踐思路相近
KM Inside · Context Engineering 參考來源
準備匯出 PDF…