2026-09-11 · Kim Kao(高宏榮) · Research Memo

JCConf Taiwan 2026 — 當 1+1 不再永遠等於 2:LLM 在領域模型中的能力與邊界

#meetup#jcconf-2026#ddd#ontology#oole#ai-coding#agentic-engineering#codegraph#context-engineering#harness-engineering
議程背景與研究焦點

- 大會場次:JCConf Taiwan 2026 | 402CD 廳 11:45 - 12:30
- 講者:Kim Kao(高宏榮)| AWS 解決方案架構師部門經理、台灣領域驅動設計社群(DDD Taiwan Community)共同發起人
- 核心提問:當機率推論的 LLM(具備幻覺與不確定性)介入高精確度、規則密集的企業領域模型(Domain Model)時,為什麼「1+1 不再永遠等於 2」?

[!note] 筆記定位與「講者原意 vs. 個人超譯」邊界聲明
- 講者原音核心:Kim Kao 現場演講著重於「概念流程(Conceptual Flow)、DDD 工作坊引導(Storytelling / Event Storming / Example Mapping)、不變量與領域模型邊界、SSOT、Wardley Mapping 策略定位與 Harness 治具心法」,帶領聽眾反思 LLM 在複雜企業系統中的推理極限。
- 個人超譯與落地延伸:筆記中關於「領域契約本體表的六大剛性欄位 Schema(Package, Class, Signature, Return Object)、ontology-table.yaml 格式、以及搭配 CodeGraph 的雙軌自動化驗收閉環」,屬於筆者聽講後為求具體落地所進行的「個人理解、超譯與工程化推導設計」,非講者現場展示的原始既定投影片規格。


Section

0. AI Coding 方法論演進脈絡

流程圖 · Diagram
flowchart LR
    V["Vibe Coding<br>直覺編程"] --> C["Context Engineering<br>上下文工程"]
    C --> S["Spec-Driven Development<br>規格驅動開發 SDD"]
    S --> H["Harness Engineering<br>工程治具與測試防禦"]
    H --> L["Loop Engineering<br>閉環工程與回饋迴路"]
    L --> O["Ontology-Grounded Loop<br>本體約束與閉環世界建模"]
術語溯源與客觀考證:什麼是 OOLE?

名詞來源:「Ontology-Oriented Loop Engineering(OOLE,面向本體的閉環工程)」一詞,源自中國 積墨 AI(Jimo Studio)2026 年 8 月 28 日 發布之技術部落格文章《從替人寫代碼到為智能體造世界:AI Coding 的範式躍遷》(*From Writing Code for Humans to Building Worlds for Agents*)。
業界定位:該名詞並非國際或業界普遍定型的主流標準術語(因此公開搜尋極少),而是該團隊將 DDD 領域建模、Palantir AIP 的 Ontology(物件/動作類型)、Spec 規約工程與 Loop Engineering(Agent 閉環自愈) 概念拼接融合後提出的「一家之言」。
主流等價概念:在主流技術社群中,更常被檢索與認可的同類概念為 Ontology-Grounded Software EngineeringSpec-Driven Development (SDD)Agentic Domain-Driven Design 以及 Semantic Layer for AI Agents


Section

1. 核心思想:從故事敘說到 Gherkin 規約的五階收斂鏈

1.1 會議現場的核心方法論全景

在 Kim Kao 的議程演講中,為了解決 LLM 介入業務系統時「機率推論破壞確定性規則」的核心矛盾,著重於以領域驅動設計(DDD)的引導工作坊與規約工程作為概念核心

下圖前半部(①~⑤)為演講所梳理之核心收斂鏈,後半部(⑥~⑦)則為進一步結合代碼圖譜之工程落地延伸:

流程圖 · Diagram
flowchart TD
    subgraph Speaker_Concept ["講者核心概念鏈 (DDD & Spec Workshops)"]
        A["① Domain Storytelling<br>【領域故事敘說】<br>角色、行動、工作物件"] -->|萃取概念與語義| B["② Ontology Modeling<br>【業務本體建模】<br>實體、狀態、關係、不變量"]
        B -->|動態時間軸展開| C["③ Event Storming<br>【事件風暴】<br>挖掘 Domain Events、Commands、Policies"]
        C -->|具體化規則邊界| D["④ Example Mapping<br>【實例對映】<br>規則、邊界案例、正反實例"]
        D -->|形式化契約| E["⑤ Gherkin Spec<br>【可執行規約】<br>Given - When - Then"]
    end

    subgraph Engineering_Extension ["工程落地超譯與延伸 (Dual-Graph & Execution)"]
        E -->|攜帶領域實體名詞| F["⑥ CodeGraph Grounding<br>【代碼拓撲錨定】<br>呼叫鏈、路由、影響半徑"]
        F -->|精確上下文約束| G["⑦ Agentic Execution<br>【Agent 實作與防禦】<br>測試驗證與持續閉環"]
    end

1.2 五階推進詳解:如何將「業務直覺」編譯為「Agent 憲法」

階段核心活動(Activity)核心產出(Artifact)對 AI Coding 的約束價值(Why it matters)
1. Domain Storytelling領域專家與架構師共同以圖形化說故事(Actor ➔ Work Object ➔ Activity)。領域情境圖、統一語言(Ubiquitous Language)初稿。防止名詞分裂:讓 AI 認識真實業務對象,不再把同一個概念在不同檔案亂取名字。
2. Ontology Modeling將名詞與動詞形式化為本體結構,定義類型邊界、依屬關係與全域不變量(Invariants)。業務實體定義、合法關係、靜態約束字典(ontology.yaml)。確立物理定律:定義什麼是「絕對不被允許的操作」(如已取消訂閱不可出帳)。
3. Event Storming沿時間軸捕捉「已經發生的業務事實(橘色便箋 Domain Events)」、觸發命令(藍色)與反應策略(紫色)。事件流(Event Stream)、狀態轉移圖、聚合根(Aggregates)邊界。杜絕狀態機穿透:明確告訴 Agent 狀態改變必然伴隨領域事件,不能直接 update DB。
4. Example Mapping透過四色便箋(黃故事、藍規則、綠實例、紅疑問)將抽象政策拆解為具體案例。規則清單、極端邊界實例(Edge Cases)、未解業務問題。消除模糊地帶:將「業務規則」轉化為「非黑即白的實例」,消除模型猜測空間。
5. Gherkin 規約化將綠色實例編譯為標準的 Given-When-Then 自然語言形式化契約。.feature 可執行測試規約、驗收測試腳本。黃金驗證治具:兼具「人類可讀」與「測試可自動執行」,成為 Agent 的不可撼動邊界。

1.3 傳統 AI Coding 的「業務語義斷裂」痛點

  • 名詞分裂(Semantic Drift):同一業務概念在不同模組、不同 Agent 輪次被隨意命名(如 User vs. Account vs. Customer)。
  • 規則黑盒(Hidden Invariants):Agent 可以產生表面語法完全正確的程式碼,但底層違反跨模組業務限制(例如:尚未完成 KYC 的帳戶直接觸發放款)。
  • 狀態機穿透:合法狀態轉移被跳過,甚至繞過 Audit Log 與事件廣播直接改動資料庫。

1.4 本體閉環工程(Ontology-Grounded Loop)的三層架構

借鑑積墨 AI(Jimo Studio)文章中所梳理的三層語義結構,將業務本體映射為可執行的軟體系統:

流程圖 · Diagram
flowchart TD
    L1["<b>1. Ontology Knowledge(描述性語義)</b><br>對象、狀態、關係、規則、權限、例外、不變條件"]
    L2["<b>2. Ontology-grounded Spec(規格橋樑 / Gherkin)</b><br>狀態轉移圖、API 契約、Given-When-Then 驗收測試、領域事件"]
    L3["<b>3. Ontological Twin(操作性語義與數位孿生)</b><br>可執行、可模擬、可斷言業務違規的操作世界"]

    L1 -->|"規格編譯<br>(Event Storming + Example Mapping)"| L2
    L2 -->|"代碼與世界生成<br>(CodeGraph + Harness)"| L3

1.5 概念辨析矩陣:Ontology vs. DDD vs. Knowledge Graph

構念核心定位關注焦點在 AI Coding 中的角色
DDD軟體設計與團隊協作Bounded Context、限界上下文、聚合根定義模組邊界與領域語言(Ubiquitous Language)
Knowledge Graph實例層的資料拓撲實體節點與事實關聯(Instance Facts)RAG 資料檢索、事實關係溯源
Ontology系統語義與不變約束類型定義、合法操作、狀態轉移、全域不變量約束 Coding Agent 行為的憲法與底層物理定律

1.6 核心工程載體:領域契約本體表(The Domain Contract Table)

聽講延伸與工程超譯實踐說明

演講概念基石:Kim Kao 現場演講著重於「以業務本體與工作坊作為概念流程,建立約束 LLM 邊界的單一事實來源(SSOT)」。
個人超譯推導:為了讓演講中的抽象概念能夠在現代工程專案中被自動化、可檢驗地執行,本小節為筆者基於該概念所進行的具體工程化超譯推導——將業務本體形式化為一張具備六大剛性欄位的「領域契約本體表」,藉由明確的代碼結構 Metadata 徹底消除 AI 的隨機性。

#### ① 本體表的核心 Schema 欄位推導

這張表將軟體架構的「實體骨架」與領域模型的「動態規則」凝練在一起,定義了六大剛性欄位:

欄位名稱(Column)定義與語義實例(Subscription Upgrade 範例)防止 AI 隨機性的機制
Package Name套件完整路徑與模組分層邊界com.company.billing.subscription.domain.model杜絕 Agent 到處亂建目錄或放錯模組邊界。
Class / Aggregate領域實體、聚合根或服務類別名稱Subscription杜絕名詞分裂(如一下寫 UserPlan 一下寫 Subscriber)。
Method / Operation領域操作動詞(對齊統一語言)upgradePlan杜絕隨機自創方法名(如 changePlansetTier)。
Parameters (Name & Type)嚴格的參數名稱與強型別定義(PlanId targetPlan, UserId operatorId)杜絕寬鬆型別(如直接傳 StringMap)及參數順序錯亂。
Return Object回傳值型別、領域事件或特定錯誤Result杜絕拋出不明黑箱 Exception 或直接回傳任意 Object。
Rules & Invariants該操作所必須守護的前置/後置條件Pre: status == ACTIVE, targetPlan.isAvailable == true明確列出邊界約束,消除模型的自行發揮空間。
Flow / State Transition狀態機轉移路徑與伴隨事件ACTIVE ➔ ACTIVE (with new plan);禁止 CANCELLED ➔ *杜絕跳過狀態檢查直接穿透修改資料庫。

#### ② 機器可讀格式定義(domain-ontology.yaml

這張本體表在專案中可以直接落實為可執行的元數據設定檔(或專用 DSL):

# docs/domain/ontology-table.yaml
domain: SubscriptionBilling
package: com.company.billing.subscription.domain.model

entities:
  - class: Subscription
    state_field: status
    states: [DRAFT, ACTIVE, SUSPENDED, CANCELLED]
    operations:
      - method: upgradePlan
        parameters:
          - name: targetPlan
            type: com.company.billing.plan.domain.PlanId
          - name: operatorId
            type: com.company.billing.iam.domain.UserId
        return: io.vavr.control.Either<SubscriptionError, SubscriptionUpgraded>
        preconditions:
          - "this.status == SubscriptionStatus.ACTIVE"
          - "targetPlan != this.currentPlan"
        postconditions:
          - "this.currentPlan == targetPlan"
          - "emits SubscriptionUpgraded(this.id, targetPlan, operatorId)"
        forbidden_transitions:
          - from: CANCELLED
            reason: "已取消的訂閱不可執行任何升級操作"

1.7 受控實作與確定性驗證閉環(Deterministic Execution & Dual Verification)

當有了「領域契約本體表」,AI Coding 的工作流程由「放任生成」轉變為「受控施工」,並具備客觀的自動化驗收依據:

流程圖 · Diagram
flowchart TD
    T["① Ontology 契約表<br>Package, Class, Signature, Rules"] -->|擷取對應行作為 Context| P["② Prompt Context Injection<br>給予 Agent 剛性約束邊界"]
    CG["③ CodeGraph 輔助拓撲<br>定位既有呼叫者、依賴項與測試"] --> P
    P --> AGENT["④ AI Coding Agent<br>在狹窄通道內施工實作代碼"]
    AGENT --> CODE["⑤ 產出實體代碼"]
    
    subgraph Dual_Verify ["雙軌客觀驗證閉環 Dual Verification"]
        direction TB
        CODE --> V1["★ 軌道一:靜態契約驗收 Static Compliance<br>AST / ArchUnit / 反射比對<br>驗證 Package, Class, 參數型別與回傳值是否 100% 吻合"]
        CODE --> V2["★ 軌道二:動態語義驗收 Dynamic Compliance<br>Gherkin 驗收測試 + Invariant 斷言<br>驗證狀態轉移與不變量是否被破壞"]
    end

    V1 -->|未吻合| FAIL["直接駁回修正"]
    V2 -->|未通過| FAIL
    FAIL --> AGENT
    V1 -->|通過| PASS["PR 交付"]
    V2 -->|通過| PASS
  1. Context 注入非隨機
  • 實作前,Prompt 不直接給模糊需求,而是精準注入本體表中該操作的完整定義行
  • CodeGraph 的輔助定位:Agent 拿著表中的 Subscription.upgradePlan 呼叫 codegraph explore,找出當前代碼庫中是誰在呼叫它、需要注入哪些 Repository 與 EventPublisher,省去檔案漫遊。
  1. 雙軌自動化驗收(Deterministic Verification)
  • 軌道一:靜態結構驗收(Static Compliance)
  • 撰寫輕量級的 ArchUnit 測試或 AST 檢查腳本,直接讀取 ontology-table.yaml,比對生成的 Java/Kotlin 代碼:
  • 是否在正確的 package
  • 類別名稱是否相符?
  • 方法參數型別與回傳型別是否 100% 嚴格一致?
  • 任何型別或命名偏差在編譯與靜態檢查階段直接報錯,不需要人工肉眼審查。
  • 軌道二:動態邏輯驗收(Dynamic Compliance)
  • 執行根據本體表中 preconditionsforbidden_transitions 生成的 Gherkin 測試,確認違反業務規則時必定正確拋出例外或回傳錯誤。

Section

2. 跨領域方法論整合矩陣:五大流派的交會與驗證

為了解決「LLM 的機率性 vs. 領域模型的確定性」,當前軟體架構界實際上正由五股方法論力量交會而成:

流程圖 · Diagram
flowchart TD
    subgraph Strategy ["1. 戰略治理層"]
        WM["Wardley Mapping<br>組件演進與邊界決策"]
    end

    subgraph Semantics ["2. 人機語義與規約層"]
        DDD["敏捷與 DDD 工藝流<br>Storytelling ➔ Event Storming ➔ Example Mapping"]
        ONTO["企業數位孿生流<br>Palantir AIP Ontology ➔ OOLE 操作世界"]
    end

    subgraph Code_Bridge ["3. 代碼實現與邊界防禦層"]
        TYPE["型別系統與內部品質流<br>Type-Driven ➔ Parse, don't validate"]
        TOPO["代碼拓撲與上下文工程流<br>CodeGraph ➔ LSP for Agent ➔ 影響半徑"]
    end

    Strategy --> Semantics
    Semantics --> Code_Bridge

2.1 五大流派深度剖析與對比

流派核心代表與思想核心機制對 AI Coding 的防禦作用潛在盲區或代價
① 敏捷與 DDD 工藝流Stefan Hofer、Alberto Brandolini、Matt Wynne、Dan North。Domain Storytelling ➔ Event Storming ➔ Example Mapping ➔ Gherkin BDD。消除語義模糊:將人類業務意圖編譯為無歧義的 Given-When-Then 活契約。需高強度的跨職能協同(人類工作坊開銷),缺乏底層代碼定位能力。
② 企業數位孿生流Palantir AIP、OOLE(面向本體閉環工程)。Object Types(名詞對象)、Link Types(關聯)、Action Types(動詞操作與安全控制面)。沙盒受控執行:AI 只能呼叫經授權與驗證的 Action Types,嚴禁直接竄改資料庫。本體模型若過於龐大易陷入過度設計,維護成本極高。
③ 型別系統與品質流Uberto Barbini(《Process Over Magic》)、Alexis King(Parse, don't validate)。利用語言的強型別(Java Records / Sealed Classes / Kotlin ADTs)建立領域代數型別。編譯期物理鐵律:Make impossible states unrepresentable(讓非法狀態無法在型別層表達)。只能防禦型別內的不變量,跨服務與分散式狀態轉移仍需上層規約。
④ 代碼拓撲工程流CodeGraph(Rust Kernel + SQLite)、Laurence Chen(Context Efficiency)。AST 預索引、符號呼叫圖(Call Graph)、框架路由與變更影響分析(Affected Tests)。精確定位與防翻檔:單次 MCP 呼叫取得手術式上下文,消除 Grep 猜測並算出影響半徑。只有語法拓撲事實,無法理解代碼背後的業務規則合法性。
⑤ 戰略演進治理流Simon Wardley(Wardley Mapping,Kim Kao 演講核心之一)。依演進階段區分:Genesis(創世紀)➔ Custom-Built(客製核心)➔ Product(產品)➔ Commodity(通用件)。防禦過度設計:指導團隊「何時該重兵投入本體防禦,何時該直接讓 AI 自由發揮」。屬於宏觀戰略規劃,無法直接指導微觀代碼實作。

2.2 戰略落地分工:如何用 Wardley Mapping 防止過度設計?

在 Kim Kao 的議程中,導入 Wardley Mapping 是防止團隊「陷入本體泥淖」的解毒劑:

演進階段Genesis(創世紀)Custom-Built(客製核心)Product / Rental(標準商用)Commodity / Utility(基礎設施)
業務定位探索性新業務核心競爭力領域模型標準商用產品 / 套件基礎通用設施 / 水電瓦斯
AI 策略Vibe Coding
快速驗證原型
★ 完整五階收斂鏈
DDD + Ontology-lite
+ CodeGraph + Harness
直接採用現成模組
(SaaS / 開源庫)
LLM 直接生成
或使用標準公用 API
  • 不應對所有程式碼一視同仁:對於通用基礎功能(如 JWT 認證、發送 Email、一般 CRUD),使用重度 Ontology 與工作坊是巨大的浪費。
  • 重兵集結於 Custom-Built:唯有承載企業核心業務規則(如金融風控、複雜計費、保險核保、大型 Mainframe 核心轉換),才必須徹底執行 Domain Storytelling ➔ Ontology ➔ Event Storming ➔ Example Mapping ➔ Gherkin ➔ CodeGraph 的全套防禦裝甲。

Section

3. 代碼結構層:CodeGraph 的定位與拓撲能力

3.1 什麼是 CodeGraph?

  • 工具定位:預先索引(Pre-indexed)之本機代碼知識圖譜(Code Knowledge Graph)。
  • 底層技術:Rust 原生 Kernel 解析 20+ 語言 AST,結合 SQLite FTS5,提供符號級呼叫圖(Call Graph)與依賴追蹤。
  • 核心價值:徹底取代 Agent 漫無目的的 grep / glob / read 檔案漫遊,以單次呼叫精準獲取「上下文、呼叫鏈、框架路由與影響半徑(Blast Radius)」。

3.2 語義與拓撲的邊界分工

流程圖 · Diagram
flowchart TD
    O["<b>Ontology(業務語義層)</b><br>定義「為什麼」與「能否做」:業務實體、權限規則、狀態轉移限制"]
    CG["<b>CodeGraph(代碼拓撲層)</b><br>掌握「在哪裡」與「怎麼做」:檔案路徑、符號位置、精確呼叫鏈"]

    O <-->|"映射與雙向約束"| CG
  • CodeGraph 的強項:毫秒級解析語法拓撲、跨語言呼叫橋接(如 Swift ↔ ObjC、RN Bridge)、框架路由反查。
  • CodeGraph 的局限:缺乏業務語義理解能力,無法主動判斷一段呼叫路徑是否破壞了領域不變量。

Section

4. 雙圖工程實踐:OOLE 結合 CodeGraph 的閉環流水線

流程圖 · Diagram
flowchart TD
    subgraph S1 ["階段一:頂層語義與規約 Top-Down"]
        O["Ontology-lite 規格定義"] --> S["Ontology-grounded Spec"]
        S -->|提供領域符號名詞| CG_IN["CodeGraph 符號定位"]
    end

    subgraph S2 ["階段二:精確拓撲檢索 Grounding"]
        CG_IN -->|codegraph_explore| CTX["Surgical Context 呼叫鏈與原始碼"]
    end

    subgraph S3 ["階段三:Agent 實作與防禦 Execution"]
        CTX --> AGENT["Coding Agent 實作代碼"]
        AGENT --> CODE["本地代碼庫變更"]
    end

    subgraph S4 ["階段四:驗證與影響分析 Verification"]
        CODE -->|檔案異動| SYNC["CodeGraph 自動增量同步"]
        CODE -->|執行測試| TEST{"業務約束與 Invariants 通過?"}
        SYNC -->|codegraph affected| IMPACT["評估變更影響半徑 Blast Radius"]
        TEST -->|失敗| AGENT
        TEST -->|通過| PASS["PR 交付"]
    end

4.1 端到端實例穿透:從 Gherkin 規約到 CodeGraph 拓撲落地

以訂閱升級(Subscription Upgrade)為例,展示規約與代碼圖譜如何協同引導 Agent:

#### ① 規約層產出:Gherkin 驗收契約(Executable Spec)

經過 Event Storming 與 Example Mapping 後,產出具備明確邊界的驗收規約:

# specs/features/subscription_upgrade.feature
Feature: 訂閱升級與領域事件廣播
  Scenario: 活躍訂閱者成功升級方案
    Given 客戶持有狀態為 "ACTIVE" 的訂閱 "sub-101"
    When 客戶請求升級為 "PRO_MONTHLY" 方案
    Then 訂閱方案應變更為 "PRO_MONTHLY"
    And 系統必須發布 "SubscriptionUpgraded" 領域事件

  Scenario: 已取消的訂閱禁止升級(違反業務不變量)
    Given 客戶持有狀態為 "CANCELLED" 的訂閱 "sub-202"
    When 客戶請求升級為 "PRO_MONTHLY" 方案
    Then 請求應被拒絕並拋出 "SubscriptionCancelledException"
    And 系統不得發布任何領域事件

#### ② 結構錨定層:CodeGraph 呼叫鏈檢索(Single Tool Call Grounding)

Agent 不需要使用 grep 全庫翻找,直接針對 Gherkin 內的實體名詞向 CodeGraph 發出探測:

# Agent 呼叫 CodeGraph MCP 工具
codegraph_explore "Subscription upgrade endpoint and domain state machine"

CodeGraph 一次性回傳完整拓撲與真實代碼區塊

  1. HTTP 入口SubscriptionController.java 中的 @PostMapping("/subscriptions/{id}/upgrade")
  2. 應用服務SubscriptionService.javaupgradePlan(...) 方法。
  3. 領域聚合根Subscription.java(包含狀態枚舉 SubscriptionStatus 與轉移限制)。
  4. 受影響測試SubscriptionUpgradeTest.java

#### ③ 實作與防禦閉環:不變量 Guardrail + 影響半徑

  1. Agent 寫入代碼:Agent 在實作時,受 Gherkin 與 Ontology 不變量雙重約束,嚴格在聚合根中加入防禦條件(如 if (this.status == CANCELLED) throw ...),而非直接在 Controller 覆寫資料庫。
  2. 變更影響評估:修改完成後,觸發:
   git diff --name-only | codegraph affected --stdin

立即獲知本次改動波及的下游消費者(如計費服務 BillingWorker、事件監聽器 AuditListener)以及必須重跑的測試檔案清單。


4.2 核心工作流收斂點

  1. Top-Down 精準定位:透過 Ontology 名詞快速查詢 CodeGraph,消除 Agent 瞎猜路徑的 Token 與時間開銷。
  2. Bottom-Up 逆向蒸餾:針對無文件的老舊系統(Legacy/Mainframe),透過 CodeGraph 呼叫鏈反向萃取業務實體與狀態圖。
  3. 變更影響半徑分析:改動 Ontology 規則時,透過 codegraph affected 快速定位所有受牽連的 API、事件處理器與測試檔案。

Section

5. 工程落地治具與目錄規範(Blueprint)

5.1 專案目錄結構提案

your-project/
├── .codegraph/                  # CodeGraph 原生資料庫與本機快取
├── docs/
│   └── domain/
│       ├── ontology.yaml        # 業務本體定義(實體、關係、狀態、不變量)
│       ├── glossary.md          # 統一領域詞彙(Ubiquitous Language)
│       └── state-machines/      # 狀態機與合法轉移規範
├── specs/                       # 基於本體編譯出的具體功能規格
└── src/                         # 實體業務代碼

5.2 Agent 指引規則與 MCP 工具鏈協同

  • [ ] 制定 Agent 行為守則:改動前必須同時查核 ontology.yamlcodegraph 拓撲。
  • [ ] 整合 CodeGraph MCP Server(codegraph_explore)。
  • [ ] 建立自動化稽核測試(Invariant Verification Tests)。

Section

6. 收斂研討室(Working Backlog & 待探討課題)

本筆記後續對話逐步收斂之關鍵清單

1. Ontology 的表達形式:YAML、DSL、還是直接採用 Type-level / Code-as-Ontology(例如 TypeScript / Java Records / Kotlin Sealed Interfaces)?
2. 雙圖同步問題:當程式碼重構後,Ontology 如何保證不與代碼拓撲脫節(Anti-drift)?
3. Context 預算管理:CodeGraph 的 explore 回傳完整程式碼,如何避免與龐大的業務規則在 Context Window 內打架?
4. 老系統逆向工程實戰:在 Mainframe COBOL 或老舊 Java 系統中,如何從 CodeGraph 拓撲一步步蒸餾出可靠的業務狀態機?