IntentCAD一天連發5個版本：從工具到平臺的"自殺式"升級

一個做DXF文件對比的開源工具，在24小時內把自己"殺死"了5次。

2024年3月，cad-dxf-agent的GitHub倉庫突然靜默。不是 abandoned，是 metamorphosis。開發者把過去18個月積累的確定性比對引擎——那個能逐像素檢測工程圖紙差異的CLI工具——連根拔起，種進了一個叫IntentCAD的新骨架里。

同一天，5個EPIC（工程史詩）通過PR #73到#82集體落地。這不是版本迭代，是物種躍遷。

從"比對兩個文件"到"理解你想干什么"

舊工具的工作流很誠實：你丟進兩個DXF，它吐出差異報告。像一臺精密的天平，只回答"哪里不同"。

新架構的核心是intent router（意圖路由器），PR #74。用戶用自然語言描述需求——"找出這張圖紙里所有重復的標注模式"——系統不再硬編碼響應，而是走一套契約驅動的管道：

解析意圖 → 匹配能力契約 → 驗證前置條件 → 執行最高優先級匹配

代碼很直白。每個能力（capability）注冊時聲明三件事：處理什么意圖類型、需要什么會話狀態、產出什么結果。路由器本身不碰任何領域邏輯，新能力即插即用。

這不是聊天機器人套殼。是顯式階段（explicit stages）對隱式方法簽名的取代。

PR #75的提交信息很說明問題："Harden contracts against spec"。能力契約上線第一天就被加固——松散的類型提示變成嚴格schema，本該必填的可選字段被修正。契約剛誕生就需硬化，這恰恰證明顯式schema比隱式簽名更值得維護。

單用戶CLI的"器官移植"

比對引擎最初為單人命令行會話設計。平臺化需要三件器官：認證、授權、工作區隔離。

PR #80的UserManager類暴露了遷移的殘酷性。Google身份令牌驗證后，系統檢查白名單、upsert用戶記錄、隔離會話狀態。舊引擎的假設——"運行這段代碼的人就是操作者"——被徹底推翻。

更隱蔽的改動在PR #76：繪圖上下文（DrawingContext）現在攜帶用戶ID作用域。同一個比對算法，執行時看到的圖紙視圖可能完全不同。多租戶不是加個字段，是重新設計數據流經的每一條血管。

被低估的第五個EPIC

PR #78和#81處理了看似邊緣的場景：標記語言解析（markup interpretation）和區域問答（region Q&A）。

工程圖紙的標記不是裝飾。紅圈、引線、云線批注承載著審查者的意圖——"這里有問題"。舊工具把這些當像素差異處理，新系統嘗試理解"這個紅圈指向的公差標注是否與其他視圖沖突"。

區域問答更激進。用戶框選圖紙一角，問"這個裝配間隙的歷史變更記錄"。系統需要關聯幾何位置、版本歷史、變更工單——把靜態圖紙變成可查詢的知識庫。

這兩個能力沒出現在早期產品路線圖上。是intent router的架構彈性讓它們成為可能：新契約注冊，路由器自動識別，無需改動核心管道。

命名即戰略

從cad-dxf-agent到IntentCAD，刪除的是文件格式名，增加的是主語。

舊名字描述工具能處理什么文件。新名字描述用戶能表達什么意圖。這個重命名發生在PR #73，比五個EPIC早幾個小時——不是事后貼標簽，是預先框定架構方向。

開發者在一個commit message里坦承："Calling it 'cad-dxf-agent' was underselling it by a factor of five." 低估五倍。五個EPIC恰好對應五個被低估的能力維度：路由、契約硬化、多用戶、標記理解、區域查詢。

GitHub的contribution graph顯示，這一天有11個contributor提交記錄。對于一個小眾工程工具，這密度暗示著某種協作模式的轉變——從個人維護者的問題驅動，到平臺架構的能力驅動。

IntentCAD的README至今保留著一行小字："Formerly cad-dxf-agent"。不是懷舊，是考古層。下一個從這個地基上長出來的能力會是什么——當用戶開始用自然語言追問"為什么這個設計在2023年Q2被否決"時，系統需要嫁接多少新的數據源？