Files
Arcrun/system-dev/wiki/cards/decisions/Haiku能驅動是設計目標.md
T
uncle6me-web 558e80b4da chore(wiki): wiki-init 補骨架 + system-dev-template 安裝/更新腳本
wiki 已初始化過(push 檔活躍維護),本次補從沒建的 pull 層 + arcrun 化範本:
- cards/decisions/ 14 張決策原子卡(含 gloss/實體/typed-edge 三元組):
  從 decisions-summary 全量改寫 13 + 新增「薄殼規則晚於實作-MCP漂移是歷史債」1
- TAXONOMY 從 PKM 範本換成 arcrun 軸(子系統 零件架構/cypher/credential/recipe/kbdb/
  薄殼/部署/平台原則 + 形態 架構決策/踩坑/機制說明/禁令/案例經驗)
- principles 填 13 條跨全局原則(從 rules/ + mindset 蒸餾)
- INDEX 真實視圖(子系統角度 + 決策角度,指向 cards)
- system-dev/scripts/ + scripts/ install/update 安裝腳本(template 接入)

純基建/文檔,無業務 code(功能 code 見前一 commit)。
raw source(docs/)0 異動、wiki 卡際連結無斷鏈。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-27 17:53:37 +08:00

2.2 KiB
Raw Blame History

tags, gloss
tags gloss
平台原則
架構決策
arcrun 能用 Haiku 驅動才算設計達成。撞牆不是換模型,是信號要改介面。

Haiku 能驅動是設計目標

decisions/00-INDEX

來源system-dev/wiki/decisions-summary.mdHaiku 就能搞定是設計目標)、.claude/rules/06-mindset.md §1 最後更新2026-06-27

摘要

arcrun 的價值主張是「比直接開發容易 + 省 token + 省時間」。只有 Sonnet 能驅動時,「省」就不成立。Haiku 通過才是設計目標達成的證明;反之,Haiku 撞牆=介面缺陷信號,應改介面而非換模型。

重點

  • 設計思想:Haiku 作為基礎模型,若某操作需要 Sonnet 才行,代表介面太難、太多隱含上下文、需要手工智能補齊——這是架構欠債。
  • 測試邏輯
    • Haiku 通過 → 設計目標達成,介面夠清晰
    • Haiku 不通 → 升 Sonnet
      • Sonnet 通過 → 介面缺陷,要改介面白痴化
      • Sonnet 也不通 → 功能 bug,要改邏輯
  • 不要的做法:「Haiku 過不了就換 Sonnet」= 放棄設計目標、接受介面複雜度只有豪華模型才能應付。
  • 改進信號:Haiku 哪個步驟卡住(參數寫法?狀態機理解?錯誤訊息太模糊?),就是該改哪個介面。
  • 誠實限制mindset §7):Haiku 撞牆不要假綠(mock 迴應),要誠實標「需要 Sonnet」或「無法 resolve」,作為改進指標。

實體

  • HaikuClaude 3.5 Haiku)— 輕量級語言模型,arcrun 驅動的基準。
  • 設計達成design achievement)— 介面清晰度高到 Haiku 能自主操作,無需人工介入。
  • 介面缺陷interface defect)— Haiku 無法理解但 Sonnet 能理解的操作,表示介面隱含前置知識過多。
  • 功能 bugfunctional bug)— Sonnet 也無法做到的操作,表示後端邏輯確實有問題。

關聯

內文知識關係

  • 設計達成 >> 以 Haiku 通過 >> 衡量
  • Haiku 不通 >> 信號 >> 介面缺陷
  • 介面缺陷 >> 應該 >> 改介面
  • 功能 bug >> 應該 >> 改邏輯

卡片關係