# AI 原生電子書生產：多 IDE 編排作為方法論工程基礎設施 —— 設計科學研究

> Languages: [English (source)](2026_AI_NATIVE_EBOOK_PRODUCTION_preprint.md) ｜ 繁體中文（本檔）

---

**作者：** Lu, Yeh-Hsing（盧業興；專業上亦使用 Morris Lu）
**單位：** Tiger AI（獨立研究）
**ORCID：** [0009-0006-5373-0586](https://orcid.org/0009-0006-5373-0586)
**聯絡：** <yesinlu@gmail.com>
**版本：** 1.0 中文 companion 版（reader-facing；正式學術引用請使用英文 canonical 版）
**日期：** 2026-05-18
**授權：** Creative Commons Attribution 4.0 International (CC BY 4.0)（本 preprint 文字）；配套 toolkit 軟體採 Apache 2.0
**論文 DOI（concept，永遠最新版）：** [10.5281/zenodo.20261850](https://doi.org/10.5281/zenodo.20261850)
**論文 DOI（本版本 v2 = v1.1）：** [10.5281/zenodo.20264772](https://doi.org/10.5281/zenodo.20264772)
**論文 DOI（前版本 v1.0）：** [10.5281/zenodo.20261851](https://doi.org/10.5281/zenodo.20261851)
**配套軟體 DOI（toolkit, concept）：** [10.5281/zenodo.20261680](https://doi.org/10.5281/zenodo.20261680)
**配套軟體 DOI（toolkit v3.0.1）：** [10.5281/zenodo.20261681](https://doi.org/10.5281/zenodo.20261681)
**Repository：** <https://github.com/MorrisLu-Taipei/GenAI-Consulting-Methodology-Toolkit>
**GitHub release：** [v3.0.1](https://github.com/MorrisLu-Taipei/GenAI-Consulting-Methodology-Toolkit/releases/tag/v3.0.1)（commit `5361c7b`）
**可重現性 manifest：** `09_Research_Paper/REPRODUCIBILITY.md`
**Release manifest（凍結版）：** `09_Research_Paper/RELEASE_MANIFEST_v1.0.0.md`
**建議引用格式：** Lu, Y.-H. (2026). *AI-Native eBook Production: Multi-IDE Orchestration as Methodology Engineering Infrastructure — A Design Science Investigation*（Version 1.0）[Preprint]. Zenodo. <https://doi.org/10.5281/zenodo.20261850>

> **狀態說明。** 本 preprint 已於 2026-05-17 以獨立學術 artifact 身份 deposit 到 Zenodo（paper concept DOI [10.5281/zenodo.20261850](https://doi.org/10.5281/zenodo.20261850)；paper version DOI [10.5281/zenodo.20261851](https://doi.org/10.5281/zenodo.20261851)）。它透過 Zenodo「Is supplement to」關係，cross-link 到配套軟體 deposit《GenAI Consulting Methodology Toolkit》（concept DOI [10.5281/zenodo.20261680](https://doi.org/10.5281/zenodo.20261680)；v3.0.1 DOI [10.5281/zenodo.20261681](https://doi.org/10.5281/zenodo.20261681)）。GitHub 軟體 release tag `v3.0.1` 對應 paper release candidate v1.0。本版本為 release candidate —— **尚未經同儕審查** —— 對外提供以供社群回饋、複製嘗試、勘誤（透過 repository Issues）。peer-reviewed 版本為下一步（見 §9.5 預註冊驗證研究、§10.5 經驗研究議程）。

> **譯註與定位說明。** 本中文版為英文原稿之 **reader-facing companion 版**，定位為「讓中文讀者快速理解論文主張」。**正式學術引用、Zenodo / SSRN / arXiv deposit、peer review 投稿，一律以英文 canonical 版（同目錄 `2026_AI_NATIVE_EBOOK_PRODUCTION_preprint.md`）為準**。技術術語（DSR、LLM、AI IDE、workflow 名稱、commit hash、檔案路徑）刻意保留原文，便於跨語對照與檢索；其他敘述與 section heading 翻譯為中文。如中英文出現歧義，以英文原稿為準。本中文版的更新可能落後英文版，最新主張請以英文版為主。

---

## 摘要

傳統電子書與專業知識型書籍的生產，多半延續印刷書與 PDF 的線性出版邏輯：作者以長週期撰稿，產出靜態文本，讀者則以被動閱讀為主要消費方式。本文以設計科學研究方法探討一種新範式——**AI 原生電子書生產（AI-Native eBook production）**：電子書不再只是排版後的文本容器，而是由多 IDE 協作環境（Claude Code、Cursor、Antigravity、Codex）、Git 版本控制、持久識別符（DOI）、宣告式 workflow 與讀者—IDE 互動共同構成的可查詢、可審查、可重現知識製品。我們以 *GenAI Consulting Methodology Toolkit*（Apache 2.0；n = 354 份 markdown 文件；7 種語言；橫跨三個 IDE 家族的 22 個專門化 AI-IDE workflow）作為此範式的實作案例，因為顧問方法論、成熟度模型與流程參考架構代表一類高結構、需跨文件一致性、且讀者必須轉譯到自身組織脈絡的專業電子書內容。該製品展現四項傳統單一工具寫作無法達成的特性：(1) 跨語言強制執行的同步多語一致性；(2) 多引擎對抗式審查（例如 `/devil-pair-debate`、`/red-team-review`）；(3) 讀者可查詢的執行能力——生產該製品的同一 IDE 可被讀者用 `/socratic-challenge`、`/deep-synthesize` 等 workflow 反向詢問；(4) 透過 Git 歷史加宣告式 workflow 檔案達成的可加密重現衍生鏈。我們依 Hevner 設計科學七大準則進行評估，並與傳統方法論發展循環（McKinsey 7-Step、Rosemann BPM 發展）量化對比。我們討論此範式對電子書生產、方法論工程、HCI 中「IDE 即媒介」命題、以及 LLM 時代「active」學術出版未來的意涵。

**關鍵字：** 設計科學研究；AI IDE；AI 原生電子書；電子書生產；專業知識製品；多代理協作；可執行文件；可重現製品；literate programming；顧問框架

---

## 1. 緒論

### 1.1 動機

專業電子書與知識型書籍——例如顧問方法論、成熟度模型、流程參考架構、技術手冊與學術型工具書——長期延續印刷出版的線性生產邏輯。作者或小型專家團隊以月或年為單位撰稿、審查、排版與發布，最後產出 PDF、EPUB、期刊論文或專書等靜態文件；讀者則以根本上被動的方式消費：閱讀，然後嘗試應用。

此工藝模式衍生三項結構性低效：

1. **循環延遲（Cycle latency）。** 專業書籍常落後其主題領域 3 至 7 年。當一份經同儕審查的 AI 成熟度框架或實務工具書終於問世，AI 主題本身可能早已經歷兩次典範轉移。
2. **單作者偏見（Single-author bias）。** 即使優秀的知識型書籍也繼承其主要作者或小型團隊的盲點。對抗式審查只在編輯、同儕審查或出版前讀者階段發生，往往在偏見被烘焙進章節結構之後才發生。
3. **讀者被動性（Reader passivity）。** 以靜態 PDF 或 EPUB 形式消費的專業書籍，需要大量人類翻譯勞動才能應用到特定組織或情境。書本本身無法回答關於自己的問題，也無法追蹤某一讀者假設對後續章節、工具或流程的影響。

與此同時，一種新的生產環境已經出現：**AI 整合開發環境（AI IDEs）**，例如 Claude Code [Anthropic 2025]、Cursor [Anysphere 2026]、Google Antigravity [Google 2025]、OpenAI Codex CLI [OpenAI 2025]。這些工具將大型語言模型（LLM）推理與檔案系統、版本控制、shell 指令原語融合，使其不再僅是程式編輯器，而成為通用的**認知基礎設施（cognitive infrastructure）**。

### 1.2 研究問題

本文探討 AI IDE 在刻意編排下，是否能作為新類別電子書的生產與互動環境——我們將這類製品稱為 **AI 原生電子書（AI-Native eBook）**。方法論工程是本文選取的 demanding case：它高度結構化、跨檔依賴強、需要可追溯來源，也要求讀者把內容轉譯到自身組織脈絡。具體而言：

- **RQ1。** 多 IDE 編排在電子書生產中啟用了哪些單一工具寫作無法達成的特性？
- **RQ2。** 讀者—IDE 互動如何改變專業電子書的消費方式？需要哪些設計支援？
- **RQ3。** 哪些設計原則應規範 AI 原生電子書工程？這些原則與已確立的方法論發展指南如何比較？

### 1.3 貢獻

本文做出四項貢獻：

1. **範式描述：** AI 原生電子書生產的範式，並與先前類別（AI 輔助寫作、literate programming、可執行文件）區隔。
2. **實作製品：** *GenAI Consulting Methodology Toolkit*，已準備好以 Apache 2.0 授權與待發布的 Zenodo DOI 釋出，既是一份可用的方法論，也是 AI 原生電子書範式的 demanding-case 示範。
3. **設計科學評估：** 依 Hevner 等人 [2004] 的七大準則對製品進行評估，並以傳統方法論發展循環作為專業知識型書籍生產的對照案例。
4. **可重用基礎設施：** 22 個 AI-IDE workflow 規格、三個 IDE 設定目錄、與一份 `CITATION.cff` provenance 檔，其他研究者可 fork 並改編。

本文其餘安排如下：第 2 節將本工作定位於相關文獻；第 3 節描述實作製品；第 4 至 8 節闡述 AI 原生電子書生產的五項區辨特性；第 9 節呈現設計科學評估；第 10 節討論意涵。

---

## 2. 相關工作

### 2.1 專業知識製品、方法論工程與設計科學研究

方法論的系統性建構已透過**設計科學研究（DSR）** 範式予以形式化 [Hevner et al. 2004; Peffers et al. 2007]。Hevner 的七大準則——問題相關性、設計即製品、設計評估、研究貢獻、研究嚴謹度、設計即搜尋過程、研究傳播——提供 IT 製品（包含方法論）作為學術貢獻接受評估的標準視角。

在 DSR 範疇內，方法論發展是一類被認可的製品 [March & Smith 1995]。其下知名子類別包含**成熟度模型發展**，de Bruin 與 Rosemann [2005] 以及 Becker 等人 [2009] 為其闡明程序標準。本文借用這一脈絡作為 demanding case 的評估視角，而非將研究對象限縮為方法論本身：我們關心的是，當一本專業電子書承載高結構、可審查、需應用轉譯的知識內容時，AI IDE 編排能否改變其生產與消費方式。本工作因此以 DSR 為主要評估視角（第 9 節），同時提出一項**二階（second-order）** 設計科學貢獻：研究中的製品不僅是一份方法論內容，也是一個關於如何在 LLM 時代生產可查詢專業電子書的實例。

### 2.2 Literate Programming 與可執行文件

Knuth [1984] 的 **literate programming** 引入了「程式與其文件應共存於單一製品中、程式可從文件衍生」的觀念。Jupyter notebooks [Kluyver et al. 2016] 將此推廣至計算科學，讓散文、程式碼、輸出可交織。

近期 **observable notebooks** [Bostock 2017] 與**反應式文件（reactive documents）**[Victor 2011, 2014] 進一步推進：文件本身可互動，讀者操作參數並觀察重新計算的輸出。AI 原生電子書沿第三個軸線延展此軌跡：不只是**互動**文件，而是**可查詢（queryable）**文件——讀者的問題由製作該文件的同一 AI 基礎設施回答。

### 2.3 AI 輔助寫作

近年的文獻探討 LLM 輔助學術與專業寫作 [Mirowski et al. 2023; Lee et al. 2022; Long et al. 2024]。主流框架是**增強（augmentation）**：單一人類作者搭配單一 AI 助手，研究問題聚焦於創作控制、署名歸屬、AI 共同作者的感知。

我們主張此框架已不足。當電子書生產從聊天介面移到**具有檔案系統存取權的 AI IDE** 之後，相關分析單位不再是「人—AI 二元組」，而是**多 IDE 編排（multi-IDE orchestration）**——多個專門化 AI 引擎各自貢獻獨特能力，透過檔案系統與版本控制原語協調。據我們所知，這種編排模式尚未在專業電子書與高結構知識製品生產脈絡中被系統性研究。

### 2.4 IDE 即媒介

Engelbart [1962] 關於**增強人類心智（augmenting human intellect）**的論文預示，計算介面不只是加速既有任務，而是**重構**人類認知工作。Victor [2014] 關於**思考的媒介（media for thought）**的工作主張，程式設計環境本身塑造可被便宜地思考的思想。

AI IDE 是此命題在前所未有規模上的全新實例化。我們延伸 Engelbart 與 Victor 的框架，主張 AI IDE 不只是**思考程式碼**的媒介，也是**思考任何可以版本化純文字表達的事物**的媒介——包含方法論、書籍、合約、課綱。

### 2.5 落差

我們未能找到直接探討以下組合的先前工作：

- 將**多個專門化 AI IDE 以刻意編排方式**作為專業電子書生產環境的使用方式；
- 將**主動的、讀者可查詢的專業電子書**以持久識別符發布為學術製品；
- 使此類製品在形式學術意義上可重現的**衍生鏈（provenance chain）**（Git + workflow 檔案 + DOI）。

本文填補此落差。

---

## 3. 製品：GenAI Consulting Methodology Toolkit

### 3.1 範疇

實作製品為 **GenAI Consulting Methodology Toolkit**（以下簡稱 *Toolkit*），以 Apache License 2.0 發布。下列數值屬性**凍結於 commit `7da82d7`（2026-05-18）**，可依 `09_Research_Paper/REPRODUCIBILITY.md` 中的指令獨立驗證：

| 屬性 | 數值 | 驗證 |
| --- | --- | --- |
| Markdown 文件總數 | 354 | REPRODUCIBILITY.md §3.1 |
| 實質源文件數（排除翻譯姊妹檔） | 120 | REPRODUCIBILITY.md §3.2 |
| 翻譯姊妹檔總數（7 語言） | 234（EN/DE/FR/ES/JA/KR/TH 分別 78/31/31/31/31/31/1） | REPRODUCIBILITY.md §3.2 |
| 專門化 AI-IDE workflow 數 | 22（Claude Code 10、Codex 10、Antigravity 2） | REPRODUCIBILITY.md §3.3 |
| 八階段方法論的階段數 | 8 | 定性—見 EIGHT_STAGE_FLOW_STORY.md |
| 成熟度模型的層級數 | 5（L1 Chat → L5 Agent Team） | 定性 |
| 業界案例研究（Benchmark-grade 格式） | 7 | REPRODUCIBILITY.md §3.4 |
| Git commit 數 | 94 | `git rev-list --count HEAD` |
| 具實質涵蓋的源語言 | 7（繁體中文、English、Deutsch、Français、Español、日本語、Korean；部分泰文） | REPRODUCIBILITY.md §3.5 |
| Repository URL | <https://github.com/MorrisLu-Taipei/GenAI-Consulting-Methodology-Toolkit> | — |
| 授權 | Apache License 2.0（附 NOTICE 署名要求） | `cat LICENSE` |

### 3.2 方法論實質內容（簡述）

Toolkit 的實質方法論——不在本文範圍內，但完整記錄於 repository——包含：

- **八階段閉環顧問流程**（Stage 1 As-Is -> Stage 2 Reference Model -> Stage 3 Best Practice/Ideal Practice -> Stage 4 Gap Analysis -> Stage 5 Problem Definition -> Stage 6 Phased Goals -> Stage 7 To-Be Design -> Stage 8 Implementation），以季度性的 Stage 2 雷達回環作為可證偽機制；
- **Tiger AI L1-L5 GenAI 採用成熟度模型**，組織於兩條正交軸上（規模軸 L1-L3、AI 自主軸 L4-L5），依 Tool 2.5 成熟度模型資格計分卡自評通過 10 條件中的 9 條；
- **四層企業 AI Reference Model**（L1 Governance / L2 Business / L3 Information / L4 Technical），由「抽象 × 揮發性」軸線推導而出；
- **三階段契約模型**（Phase A Diagnostic / Phase B Strategy / Phase C Implementation），具有明確的 Gate A/B/C 退出點；
- **工具箱範本庫**（40 題訪談題庫、計分量規、Stage Gate 條件、Risk Register、Audit Log 規範、AI Ethics 檢核表）。

L1-L5 成熟度模型將作為獨立的學術貢獻於另一篇論文中呈現 [Lu, in preparation]。本文聚焦於建構整個 Toolkit 所用的**生產範式**。

### 3.3 此製品在本文中為何有趣

就本文目的而言，Toolkit 的實質方法論被視為**代表性負載（representative payload）**。新穎貢獻在於回答以下問題：*既然需要生產出此規模的製品（354 份文件，7 種語言，8 階段方法論，5 級成熟度模型，7 個案例研究），使用了何種生產環境？該環境提供了哪些傳統環境無法提供的特性？*

第 4 至 8 節從五個維度回答此問題。

---

## 4. 多 IDE 生產架構

Toolkit 透過刻意編排**三個專門化 AI IDE 家族**進行生產，各自貢獻獨特能力。編排方式編碼於三個 repository 目錄中：

```text
Repository root/
├── .claude/         (Claude Code -- 1M context、跨檔綜合)
│   ├── README.md
│   └── workflows/   (10 個專門化 workflow)
├── .codex/          (OpenAI Codex CLI -- 工程嚴謹度、稽核)
│   └── workflows/   (10 個專門化 workflow)
└── .antigravity/    (Google Antigravity -- 多代理並行)
    └── workflows/   (2 個專門化 workflow)
```

### 4.0 背景詞彙：AI IDE、Git、GitHub

本節為非工程背景的讀者（管理、資訊系統、HCI、教育、顧問方法論等領域）澄清三個本文反覆出現、且支撐整體論點的關鍵構念。已熟悉者可略過本節。

**AI IDE。** 本文所稱的 AI IDE，並非僅指傳統的程式碼編輯器，也不是單純的 chatbot。它是一種將大型語言模型與 repository、檔案系統、版本控制、shell 指令、任務規格結合的工作環境。換言之，AI IDE 不只是回答問題，而是能在受控範圍內讀取多個檔案、比較版本、執行檢查、依照 workflow 修改文件，並將結果回寫到 repository。這使 AI IDE 成為一種「認知工作台」：作者可用它綜合大量文件、追蹤跨檔一致性、執行對抗式審查；讀者則可用它查詢方法論、測試情境、追蹤某一設計變更的下游影響。本文討論的 Claude Code、Codex CLI、Antigravity、Cursor，皆屬於這類把 LLM 推理嵌入 versioned text workspace 的工具。其重要性不在於它們是特定品牌，而在於它們把方法論文件從靜態文本轉化為可被代理讀取、檢查、重組與詢問的版本化製品。本文後續所說的「AI IDE」，皆指此構念 —— AI 嵌入的版本化工作環境 —— 並非任一單一產品。

**Git。** Git 是一種分散式版本控制系統，其版本歷史**不依賴任何特定代管平台**：它把對一組檔案的每一次變動，記錄為帶時間戳、有作者署名、以內容定址的「commit」單位；一連串 commit 構成一條不可變、可重播的歷史，紀錄檔案如何走到當前狀態。Branch（分支）與 tag（標籤）為這條歷史中的特定節點命名（一個「release」通常是一個命名 tag，例如 `v1.0.0`）。即使僅在作者本機運作，Git 也能形成可檢查、可重播的問責記錄；它在電子書生命週期中扮演的角色因此是**作者問責（authorial accountability）**，在 commit 那一刻就已成立，無論作品是否曾被公開分享。對於傳統文件而言，「這份文件」這個說法是模糊的，指的是讀者剛好打開的那個檔案；但對於 Git 版本化的製品而言，「commit `7da82d7` 時刻的文件」是一個精確、可被外部驗證的指涉：每一段文字、每一張表格、每一份 workflow 規格，皆可追溯到特定時刻與特定作者決策。這正是本文 §1、§8 「完整 provenance」主張能在實務上成立的基礎。

**GitHub。** GitHub 是 Git repository 最常見的**公開**代管服務。它是一個 Git 版本化製品「從私人作者工作，轉化為公開可存取、且公開**可共演化（evolvable）**之學術物件」的關鍵層。在電子書生命週期中，GitHub 扮演三個獨立角色：

1. **散布（distribution）。** 任何具網路存取的人都可以在任一過去 commit（包含任一 tagged release）clone 該製品，無需作者授權或協調。
2. **共演化介面（collaborative evolution surface）。** GitHub 對本文論點而言最關鍵的貢獻是：**它讓讀者可以從 consumer 變成 contributor**。透過 Issues、pull requests、discussions，讀者不只能標示勘誤，更能**提出實質的新內容** —— 例如新增一個業界案例、一個新的 workflow 規格、一個額外的語言翻譯、或修正後的計分量規。透過 pull request 機制，讀者的貢獻可被審查並合併進 canonical 製品，貢獻者的作者身份保留在 Git 歷史中。這把方法論從「一對多廣播」轉化為「多對多的**活製品（living artifact）**」。我們刻意作有邊界的主張：**對顧問方法論與成熟度模型這類製品而言**，這種「版本化、可引用、可被讀者貢獻並共演化」的出版形態，在傳統出版形式（書、PDF、期刊論文）中幾乎沒有直接對應物 —— 書無法接受讀者投稿章節、靜態 PDF 無法收納讀者勘誤、期刊論文無法承載讀者後續的實證案例。但 GitHub 上的 Git 版本化方法論三者皆可。（我們知道 wiki、open-source textbooks、Jupyter Book、GitBook 在鄰近領域已實現類似效果；此處的新意在於將此出版模式應用於「方法論／成熟度模型」這一類目，在該類目中此模式仍屬罕見。）
3. **DOI 橋（DOI bridge）。** GitHub 的 release 事件觸發 Zenodo 的 webhook，數分鐘內鑄造出持久 DOI（見 §8.2、§10.3），讓一個 GitHub release 成為可被學術引用、永久封存的學術製品。

若無這條「Git + GitHub + Zenodo」鏈，本電子書的生命週期在原理上仍可運作，但會失去其大部分的可重現性、公開貢獻管道與可引用性。我們在 §8.2（provenance chain）與 §10.3（學術出版）進一步闡述：將這三者視為**生命週期中三個不同層次**、而非同一件事的三種包裝，其**理論意涵**為何。本文後續所有提到「the repository」、「某個 commit」、「v1.0.0 release」、「workflow 檔案」之處，皆以標準 Git / GitHub 意義理解。

### 4.1 依認知任務的專門化分工

不同生產任務適合不同 IDE 引擎。Toolkit 的設計讓每個引擎處理其最擅長的認知任務：

| 認知任務 | 偏好的 IDE | 原因 | 代表性 workflow |
| --- | --- | --- | --- |
| 跨檔深度綜合 | Claude Code（Opus 4.7，1M-token context）| 支援全庫級上下文載入與長距離概念追蹤 | `/deep-synthesize` |
| 對抗式辯論 | Claude Code（多代理 spawn）| 可生成角色分化的專門化 sub-agent | `/devil-pair-debate` |
| 長時程反事實壓測 | Claude Code | 在假設體制變動下持續推理 | `/thought-experiment` |
| 工程一致性稽核 | Codex CLI | 在本製品中表現為較偏結構檢查與規則遵循 | `/consistency-review` |
| Provenance / traceability 生成 | Codex CLI | 機械式擷取，低創造性容忍 | `/generate-traceability` |
| 多代理並行報告草擬 | Antigravity | 原生並行代理派發 | `/generate-report` |
| 診斷訪談模擬 | Antigravity、Claude Code | 多角色並行角色扮演 | `/diagnose`、`/simulate-engagement` |

完整列舉見附錄 A。

### 4.2 為何不使用單一 IDE

自然的反問是：用單一 IDE 生產 Toolkit 是否更簡單？本研究的回答不是「多工具必然優越」，而是：在本次 artifact construction 中，單一 IDE 難以同時最佳化三種彼此張力很高的任務：全庫級綜合、對抗式審查、與工程一致性稽核。因此，多 IDE 編排不是裝飾性的工具堆疊，而是一種 **task specialization design**。驅使此設計選擇的三項生產挑戰為：

1. **Context window 異質。** 在本次生產過程中，較短 context 的工具較適合局部稽核與修改；全庫級綜合則主要依賴 Claude Code 的長 context（`/deep-synthesize`、`/cross-stage-trace`）。我們不對其他 IDE 的能力作普遍主張；僅指出在本研究的工具集與工作流中，長 context 引擎承擔了跨檔綜合的主要負荷。
2. **對抗分離需要視角差異。** 單一 LLM session 內的「自我辯論」容易受到相同上下文、相同模型偏好與相同前文 framing 的影響。為 `/devil-pair-debate` spawn 全新 Claude sub-agent，或以 Claude 作為提案者、Codex 作為 `/red-team-review` 稽核者，並不等同於人類 peer review，但可產生比單一 session 自我審查更高的視角分離。
3. **綜合與稽核偏好的方向不同。** 長 context 綜合引擎在本研究中適合維持敘事連貫與跨檔概念整合；但同一能力也可能將局部不一致「敘事化」或平滑處理。Codex 因較偏向結構檢查與規則遵循，被用作 **structural auditor**：`/consistency-review` 多次標示出 primary synthesis pass 已略過的命名、依賴、階段邏輯與格式違規。

### 4.3 編排作為宣告式規格

關鍵的方法論行動是：**編排本身即為版本化製品**。`.claude/workflows/`、`.codex/workflows/`、`.antigravity/workflows/` 目錄包含 markdown 規格，任何使用者可閱讀、fork、修改、呼叫。這使生產環境具可重現性：擁有相同 IDE 帳號的第三方可對相同的 repository 狀態重播 workflow，並觀察到類似的輸出。

我們主張，這是 AI 原生電子書生產區別於 ad-hoc AI 輔助寫作的關鍵特性：**製作該製品的程序本身，也是製品的一部分**，並因此可被版本化、檢查與引用。

---

## 5. 讀者作為查詢者的互動模型

### 5.1 超越被動閱讀

傳統專業電子書消費遵循線性模式：讀者（顧問、主管、研究生或專業實務者）打開文件、循序閱讀、嘗試心理上將其翻譯到自己的脈絡。翻譯勞動巨大且大半隱形；這正是許多優秀知識型書籍雖內容扎實、卻難以落地的原因。

Toolkit 作為方法論電子書案例，顛覆此模式。生產該電子書內容的同一個 Claude Code、Cursor 或 Codex 環境，可被讀者用來**詢問**內容。10 個 Claude Code workflow 中有一個子集專為讀者使用而設計：

- **`/socratic-challenge`**——方法論向讀者提出探問式問題，迫使讀者用方法論的詞彙說出自己組織的真實狀況；
- **`/theory-bridge`**——讀者描述具體情境，workflow 將其對應到方法論引用的七大學術支柱；
- **`/scenario-planning`**——給定讀者的限制條件，workflow 產出三條對比路線圖加上明確 trade-off；
- **`/cross-stage-trace`**——讀者在某一階段提出一個改動，workflow 追蹤其在 stages 4 至 8 的下游影響。

### 5.2 上手機制

實務問題隨之而來：讀者的 AI IDE 如何**理解**這本專業電子書到足以支援這些 workflow？答案是 repository 附帶兩份專為 AI 攝取設計的上手檔：

- **`AGENTS.md`**——200 行規格，向任何 AI 代理簡述方法論的結構、關鍵檔案、詞彙、紀律邊界。是任何 AI 工具的共同主要進入點。
- **`CLAUDE.md`** / **`CODEX.md`** / **`ANTIGRAVITY.md`**——針對三大 IDE 家族的專屬擴充。例如 `ANTIGRAVITY.md` 賦予 AI「平行多代理 (parallel multi-agent)」的任務派發意識，而 `CLAUDE.md` 則闡明其作為「具跨檔綜合能力的戰略推理夥伴」的角色，並分別啟動各自的 workflow 庫。

這些檔案讓全新的 LLM session 在短時間內從通用助手轉變為「內容識讀的對話夥伴」。經驗上這是質性差異：在 repository 根目錄打開 IDE session 並自動攝取對應的環境設定檔後，第一輪即可回答相當深度的電子書內容問題；同一模型若無 repository context，則傾向產出較泛化的 AI 顧問建議。

換言之，reader-as-querier 並非「把文件丟給任意 chatbot」；它依賴 repository 內建的 orientation files、workflow specifications、與版本化語境，將一般 LLM session 約束成內容識讀的查詢代理。reader-as-querier 能力因此不是任一模型本身的固有屬性，而是「模型 **加上** repository 附帶的 orientation infrastructure」所共同產生的屬性。

### 5.3 對作者—讀者關係的意涵

古典作者—讀者關係不對稱：作者廣播，讀者接收。AI 原生電子書引入第三方——讀者的 AI IDE——雙向中介此關係。讀者仍無法直接詢問作者本人，但可以詢問一個由作者公開素材塑造、以電子書內容為基礎的 AI。

這引發關於作者意圖、知識製品在讀者群中的漂移、以及「內容可轉移性（transferability）」如何適當評估等有趣問題。我們於第 10 節回到這些問題。

---

## 6. 多語言一致性作為湧現特性

### 6.1 一致性挑戰

Toolkit 以七種語言發布。多語方法論的天真做法——以 A 語言寫，然後翻譯至 B 到 G 語言——累積兩項複合問題：

1. **漂移（Drift）。** 源語言的更新無法一致地傳播至譯本。
2. **不對稱權威（Asymmetric authority）。** 譯本語言的讀者遇到的術語與範例往往以源文化校準，且通常不可見。

Toolkit 的生產透過我們所稱的**同步多語一致性（simultaneous multilingual coherence）** 同時處理兩個問題：源更新與譯本更新被視為單一協調的 commit；跨語一致性由**自動化掃描強制執行**。例如，專案記憶系統紀錄如下紀律規則：

> *真實姓名移除：* `新竹` -> `City X`、`Hsinchu` -> `City X`、`Sinju`（同一地名的韓文音譯）-> `City X`。必須在同一 commit 中跨 7 種語言檔案套用。

Commit `1dcc569`（46 個檔案修改，2026-05-17）即為此紀律的示範：一個語意變動（為避免法律風險而移除台灣真實地名與機構名）在單一 atomic commit 中傳播到 `CLIENT_JOURNEY_STORY` 的全部 7 種語言、`MANUFACTURING_CONSULTING_STORY`（zh）、加上 14 個相關檔案。（註：本篇 preprint 論文自身的雙語版本，亦是透過此多 IDE 機制維持同步更新，作為此紀律的後設展示。）

### 6.2 為何單作者生產難以達成

單一人類作者難以在涉及 354 份檔案、數十萬字的文件量上同時維持 7 種語言的流暢度與一致性。即使一支專業譯者團隊，也難以在多 IDE 生產所支援的時間軸上保證跨語言的語意變動 atomic 傳播（前述 commit 完成於約 45 分鐘的單一操作者 session 內）。

我們將此性質描繪為**湧現特性（emergent property）**：同步多語一致性不是生產環境中任一單一代理具備的功能，而是「LLM 流暢生成 + Git atomic commits + `/consistency-review` 式掃描 workflow」三者組合的結果。在本製品的生產脈絡中，單一人類或單一 AI 引擎都難以單獨維持此性質；整體生產環境則可以。

### 6.3 實證稽核

完整的跨語言涵蓋稽核（透過 `09_Research_Paper/REPRODUCIBILITY.md` §3.2 的單行 Python 腳本生成）顯示，在 120 份實質源文件（即非 IDE-meta 檔案）中：

- 31 份（26%）在五種非源目標語言（DE/FR/ES/JA/KR；通常 EN 也存在）皆完整；
- 48 份（40%）有部分姊妹檔涵蓋（DE/FR/ES/JA/KR 中的 1 至 4 種，加上多數有 EN）；
- 41 份（34%）尚無翻譯姊妹檔（低優先內部任務日誌、輔助檔案、近期新增等待首輪翻譯的文件）。

對於這個規模的單作者專案，所述的生產範式是使此類多語一致性變得可操作的關鍵條件。

---

## 7. 對抗式品質保證

### 7.1 單次審查問題

慣例方法論審查為單次、人類進行：作者寫，同儕審查者讀一次，回應意見，製品出版。此模式留下三種未被涵蓋的失敗模式：

- **價值觀盲點（Value-system blind spots）**——審查者與作者間共享的盲點（同領域的每個人都共享相同文化預設）；
- **內部不一致（Internal inconsistencies）**——跨檔案數量超出任何單一審查者閱讀範圍的不一致；
- **反事實脆弱性（Counterfactual fragility）**——方法論在可信情境下運作，但在體制變動（如監管改變）下崩潰。

### 7.2 用 workflow 編碼的對抗式審查

Toolkit 透過對應的 workflow 處理上述每一項：

- **`/devil-pair-debate`**——Claude-A 為方法論主張辯護；Claude-B 從 Foucauldian 或 Bourdieusian 批判理論立場反駁；Claude-C 法官綜合。輸出暴露的不是 bug，而是**價值觀偏見**。例如針對 Tiger AI L1-L5 模型本身執行此 workflow，浮現出「AI 自主性是值得追求的軌跡」這個文化偶然性主張——目前已明確記於方法論的討論中。
- **`/consistency-review`**（Codex）——掃描整個 repository 的跨檔不一致（術語漂移、數值主張矛盾、損壞的交叉引用）。例如此 workflow 標示出角色職稱（具體為 `IT 副理`）與角色責任所暗示的階級不一致（解決方案：commit `1dcc569` 將該角色升級為 `IT 協理`，橫跨 17 個檔案）。
- **`/thought-experiment`**——執行反事實壓測：「若 EU AI Act 將 L4 部署刑罪化，方法論是否仍能運作？若 LLM 成本下降 1000 倍，什麼變得過時？」這些產出明確的**脆弱性地圖（fragility maps）**，補足慣例審查較少系統化處理的反事實面向。
- **`/red-team-review`**（Codex 對 Claude 輸出）——使用不同 IDE 引擎稽核主要作者引擎的輸出。功能上類似於在多輪間切換同儕審查者，但具備確定性的跨引擎獨立性，而非審查者池的政治。
- **`/diagnose`**（Antigravity）——多代理並行角色扮演。此 workflow 在同一時間實例化多個具有利益衝突的利害關係人（例如：成本控管的 CFO、重視效能的 CTO、要求合規的法務），讓他們對方法論的特定階段（如 To-Be Design）進行同時施壓與質詢。這種平行對抗（parallel adversarial role-play）暴露出方法論在跨部門利益協調時的盲點。

### 7.3 意涵：知識製品硬度 vs. 審查者池規模

傳統同儕審查的硬度隨審查者數量、領域知識與注意力分配而變化，也可能受共享盲點影響。AI 原生對抗式審查則依 workflow 設計工作量（一次性）與運算成本（變動）擴展，特別適合暴露跨檔一致性、命名漂移、依賴鏈斷裂等結構盲點。兩者不互相取代；應串聯執行。但 AI 原生層改變了專業電子書品質的**地板（floor）**：通過 `/devil-pair-debate` 與 `/red-team-review` 的主張，至少已通過一層可重播、可審計的機械化對抗檢查。

---

## 8. 可重現性與 Provenance

### 8.1 「AI Slop」問題

對 LLM 生成內容的常見批評是**不可證偽的 provenance**：讀者無法判斷哪些主張來自人類推理、哪些來自 LLM 補完、哪些既非前者也非後者（即幻覺）。此批評對專業電子書尤為尖銳；在方法論這類 demanding case 中更是如此，因為其權威性源自理論血緣與經驗基礎。

### 8.2 Toolkit 的 Provenance Chain

Toolkit 透過四層 provenance chain 處理此問題：

1. **Git 歷史**——每次改動皆有時間戳並可歸屬於 commit。截至撰文時的 94 個 commit 編碼了製品的完整衍生歷史。
2. **AI 署名紀律**——具實質 AI 協助的 commit 帶有 `Co-Authored-By:` trailer（例如 `Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>`）。混合署名的 commit 對這份混合性誠實。
3. **Workflow 檔案作為衍生程序**——`.claude/workflows/`、`.codex/workflows/`、`.antigravity/workflows/` 目錄歸檔所用的精確 prompt 與程序。第三方可重播。
4. **持久識別符**——待發布的 Zenodo DOI（concept DOI + 每個 release 的 version DOI）將在 `v1.0.0` tag 發布後，為學術引用提供不可變的 handle。

#### 8.2.1 Git、GitHub、Zenodo 作為三個不同的生命週期層

上述四個機制並非「讓製品可被取用」這同一件事的重複包裝。我們主張它們對應 AI 原生學術製品生命週期中**三個不同的層**，各自提供其他層無法提供的屬性：

- **Git** 提供**作者問責（authorial accountability）**：一份關於「誰在何時決定了什麼」的版本化記錄，不論是否曾被分享。此層在 commit 那一刻建立。
- **GitHub** 提供**公開參與與共演化（public participation and co-evolution）**：一個讓讀者透過 Issues、pull requests、discussions 從 consumer 轉化為 contributor 的介面（見 §4.0）。此層在 push 那一刻建立。
- **Zenodo** 提供**學術固定與可引用性（scholarly fixity and citability）**：一份不可變、具持久識別符、適合學術引用的快照。此層在 DOI 鑄造那一刻建立。

三者疊加後，電子書不再只是被發布的文件，而成為**可被追溯、討論、修正、擴充、重新發布的版本化學術製品**。我們把這個**疊加（stacking）** —— 而非任一單一層 —— 當作值得命名的貢獻。§10.3 將回到此疊加對學術出版整體的意涵。

此處需要補上一個常被混淆的觀念：**DOI、授權宣告、著作權註冊是三件不同的事**。GitHub release 有 tag、commit hash 與 URL，但它本身不是出版系統，沒有提供等同於學術出版識別號的機制；DOI 則讓某一份固定版本的電子書或 release 取得可解析、可引用、可長期維護的**出版識別號（publication identifier）**。換言之，DOI 回答「這份被引用的出版版本是哪一個」。授權宣告則回答「讀者可以如何使用、改作、散布這份作品」，例如 front matter 中的授權文字、repository 內的 `LICENSE` / `NOTICE`、Zenodo metadata 中的 license 欄位，以及 `CITATION.cff` 中的引用資訊。著作權註冊或登記則是第三層：它不是產生 DOI，也不是授權他人使用，而是在特定法域中建立權利主張的官方紀錄，並可能影響後續執法、訴訟或損害賠償主張。這一層具有明顯法域差異：例如美國著作權自作品固定時即自動存在，但 Copyright Office registration 可建立公開紀錄，且對美國作品提起侵權訴訟通常需要先完成註冊或取得拒絕註冊；台灣則採著作完成即受保護，著作權註冊制度已廢止，不以登記作為取得保護的前提 [U.S. Copyright Office n.d.; Taiwan Intellectual Property Office 2020]。換言之，DOI 提供**出版身份與引用固定性**，授權宣告提供**使用邊界**，著作權註冊在有此制度的法域提供**權利紀錄與執法支援**；三者疊加後，AI 原生電子書才同時具備可引用性、可合法再利用性與較清楚的權利證據鏈。

#### 8.2.2 出版循環：從疊加層到時序迴圈 / The Publishing Cycle

§8.2.1 的三層觀是**空間性**：Git、GitHub、Zenodo 各自提供完成品的一項屬性。但實際運作中，AI 原生電子書並非「一次穿越三層後就停止」，而是**循環式地反覆穿越**，每一輪產生一個新的 version DOI，concept DOI 則自動指向最新版本。我們把這個時序維度命名為**出版循環（Publishing Cycle）**：

```text
┌─────────────────────────────────────────────────────────┐
│  Phase 1 — 撰寫（Git）                                  │
│   Commit-by-commit；Co-Authored-By trailers 紀錄 AI     │
│   協助；建立本地作者問責。                              │
│                                                         │
│            │ push                                       │
│            ▼                                            │
│  Phase 2 — 公開（GitHub）                               │
│   讀者看到最新版；Issues / PRs / discussions 啟動；     │
│   讀者→貢獻者的轉化成為可能。                           │
│                                                         │
│            │ 累積有意義改動                             │
│            ▼                                            │
│  Phase 3 — 累積期                                       │
│   多個編輯堆積；reviewer 回饋進來；工作停在自然斷點，   │
│   等待下一輪版本切割。                                  │
│                                                         │
│            │ 切新版本                                   │
│            ▼                                            │
│  Phase 4 — 凍結（Zenodo）                               │
│   鑄造新的 version DOI；concept DOI 自動指向最新；      │
│   舊的 version DOI 永久保留可引用。                     │
│                                                         │
│            │ 讀者引用、審查、回饋                       │
│            ▼                                            │
│  Phase 5 — 接收                                         │
│   讀者引用某個特定 version DOI；回饋透過 Issues / PRs / │
│   個人聯絡流回。                                        │
│                                                         │
│            │ 回饋變成下一輪 Phase 1 輸入                │
│            ▼                                            │
│  Phase 6 — 回到 Phase 1                                 │
└─────────────────────────────────────────────────────────┘
```

此循環具有熟悉的形狀：它本質上是 Shewhart–Deming PDCA 循環 [Deming 1986] 套用至學術出版的特化版本，四個古典階段對應到六個 phase 如下：

| PDCA 階段 | 出版循環中對應的 phase |
| --- | --- |
| **Plan** | Phase 3（累積期；決定下一版要包含什麼） |
| **Do** | Phase 1（撰寫；commit 具體改動） |
| **Check** | Phase 2 + Phase 5（公開與接收） |
| **Act** | Phase 4（凍結為可引用版本）+ 回饋將循環導入下一輪 Plan |

此處的新意**不在於**電子書可以再版（書籍本來就可以再版），而在於這個循環是**端到端機械化**的，每一個 phase 都有自己的技術載體：Git 承載 Phase 1，GitHub 承載 Phase 2 與 Phase 5，Zenodo 承載 Phase 4。Phase 3（累積期）是唯一沒有原生技術載體的 phase；它是「何時切下一版」的作者層級決策。即使這個決策也被累積的 Git history 支撐 —— 作者可隨時檢視「自上次 DOI 鑄造以來變動了什麼」。

一個值得明說的後果：**在這個循環中，GitHub `main` 分支與 Zenodo deposit 之間被刻意允許出現漂移（drift）**。兩次 Zenodo deposit 之間，GitHub `main` 在設計上就是「活的」版本；而每一個已鑄造的 Zenodo version DOI 永遠是「凍結的」引用點。這正如同 arXiv 版本（`v1`、`v2`、`v3`）與期刊 preprint 軌跡累積修訂、舊版本仍可被引用一樣。漂移不是 bug；正是漂移讓製品**同時具備「當前性」（GitHub）與「歷史可參考性」（Zenodo）**。

**Dogfooding 觀察 / Dogfooding observation。** 本論文自身的生產即清楚地循此循環。**v1.0**（concept DOI [10.5281/zenodo.20261850](https://doi.org/10.5281/zenodo.20261850)；version DOI [10.5281/zenodo.20261851](https://doi.org/10.5281/zenodo.20261851)）僅 deposit markdown 原始檔。**v1.1**（version DOI [10.5281/zenodo.20264772](https://doi.org/10.5281/zenodo.20264772)）加入由同一 Git 歷史衍生而出的 PDF 渲染版本。**本次修訂**回應了 Phase-5 讀者觀察 —— 指出原 abstract 將論文框定為「方法論的發展」而標題卻框定為「電子書生產」；該回饋流回 Phase 1，產生重新框定的 abstract 與本 §8.2.2，明確命名了 v1.0 與 v1.1 已隱含遵循的循環。我們將此事件視為「該循環在實務中可操作」的輕量、單案例證據，而非規範性的模型主張。

### 8.3 引用紀律

Toolkit 在**內容層級**進一步強制引用紀律。所有理論主張在 `00_Overview/ACADEMIC_THEORETICAL_FOUNDATIONS.md` 中追溯至具體外部來源（Rosemann BPM Maturity、CMMI、APQC PCF、SCOR、TOGAF、Dragon1 EA 等）。源自 Toolkit 自身設計選擇的內部主張則被標示為內部主張，並依 Tool 2.5 的十條件計分卡自評。

此紀律處理我們認為對 AI 輔助專業電子書生產最深層的反對：AI 增強的作者可能傾向生成「聽起來合理的理論」，而非始終回到可檢查來源。Toolkit 的紀律——編碼於 `AGENTS.md` 並由 `/evidence-audit`（Codex）強制——讓此類生成可見且可被切除。

### 8.4 形式意義上的可重現性

具備以下三項條件的讀者：

- 公開 repository 的存取權；
- Claude Code / Codex / Antigravity（或相容 AI IDE）的帳號；
- 已發布的 workflow 檔案；

原則上可從相當早期的 commit 起重新衍生電子書內容，觀察相同的 workflow 是否產出收斂或發散的輸出。在前 LLM 時代的專業知識製品（如 1990 年代的 CMMI 發展）並不具備這種**可重現性**——因為生產環境本身未被發布。

---

## 9. 評估

### 9.1 Hevner 設計科學七大準則

我們依 Hevner 等人 [2004] 的標準準則評估 AI 原生電子書範式。

| # | 準則 | 自評 | 證據 |
| --- | --- | --- | --- |
| 1 | 設計即製品 | [x] | 實作 Toolkit 為可行、完整製品（Apache 2.0、354 個檔案、待發布 Zenodo DOI）。|
| 2 | 問題相關性 | [x] | 專業電子書生產危機（循環延遲、單作者偏見、讀者被動性）已記錄，並在方法論 demanding case 中具結構性內在。|
| 3 | 設計評估 | [!] 部分達成 | 對自有十條件計分卡自評（9/10）。對比傳統方法論循環的評估作為專業知識型書籍生產的 demanding-case 比較（§9.2）。經驗讀者採用研究延至後續工作。|
| 4 | 研究貢獻 | [x] | 範式描述、實作製品、評估框架、可重用基礎設施——四項獨立貢獻。|
| 5 | 研究嚴謹度 | [x] | 理論視角（DSR）、評估標準（Hevner）、比較方法（循環時間與涵蓋度指標）皆明確。|
| 6 | 設計即搜尋過程 | [x] | 94 個 Git commit 記錄設計空間的反覆搜尋。|
| 7 | 研究傳播 | [x] | 兩種受眾：實務工作者（整個 repository、多語言）與學術界（本 preprint、待發布的 Zenodo DOI）。|

唯一的部分通過（準則 3）是誠實的：經驗讀者採用研究目前不在範疇內。我們於第 10 節描繪經驗研究議程。

### 9.2 比較循環分析

我們將 AI 原生電子書生產與三個參考點比較。這三者不是「所有書籍」的代表，而是高結構專業知識型書籍的 demanding-case 代表：McKinsey 7-Step 問題解決方法論的發展（如 [Rasiel 1999] 所載）；Rosemann 的 BPM Maturity Model 發展 [Rosemann & de Bruin 2005; de Bruin & Rosemann 2007]；以及一個代表性的 GenAI 成熟度框架（Gartner AI Maturity Model，最新公開索引版本為 2024）。

| 維度 | McKinsey 7-Step（標準）[a] | Rosemann BPM-MM（學術）[b] | Gartner AI-MM（業界）[c] | Toolkit（AI 原生）[d] |
| --- | --- | --- | --- | --- |
| 首次公開發布到 v1.0 | ~ 5 年 | ~ 3 年（PhD 週期）| 每次改版 ~ 18 個月 | **~ 6 個月** |
| v1.0 時源語言數 | 1 | 1 | 1（EN），部分後續本地化 | **7 同步** |
| v1.0 時實質文件數 | ~ 30（書）| ~ 6（論文 + 補充材料）| ~ 5（研究筆記）| **120** |
| 專門化 workflow 數 | 0 | 0 | 0 | **22** |
| 生產 provenance | 回憶錄／訪談 | 致謝段落 | 編輯團隊名單 | **完整 Git + workflow 檔案 + DOI** |
| 讀者可查詢性 | 無（靜態文字）| 無 | 無 | **22 個讀者可呼叫的 workflow** |
| 授權 | 專有 | 學術／Elsevier | 專有（付費牆）| **Apache 2.0（開放）** |

**比較表的腳註：**

**[a] McKinsey 7-Step。** 數值估計來自 Rasiel [1999] 的記載，該書記錄該方法自 1990 年代初期累積到正式出版。循環時間估計指 McKinsey 內部發展 7-step 公式的時間；文件數指 Rasiel 該書（~ 200 頁）作為主要公開製品。實質上更豐富的衍生書籍（如 Friga 2009）在首次釋出後才出現。

**[b] Rosemann BPM Maturity Model。** 數值估計來自 de Bruin 博士論文循環 [de Bruin & Rosemann 2005, 2007; de Bruin 2009]。循環時間估計對應產出標準模型的博士工作；文件數計入 v1.0 時期的公開論文（ECIS 2005、BPTrends 2005、Delphi 論文 2007），不包含後續衍生工作。

**[c] Gartner AI Maturity Model。** 數值估計來自 Gartner 已發布的研究筆記改版節奏（2019、2021、2023、2024 為實質改版；間隔年份僅有小幅更新）。循環時間估計指改版節奏，非首次發布。文件數指每次改版的研究筆記包。

**[d] Toolkit（本論文）。** 所有數字凍結於 commit `7da82d7`（2026-05-18），可依 `09_Research_Paper/REPRODUCIBILITY.md` 中的指令重現。

非 Toolkit 欄位的數值仍為來自公開來源的近似值；歡迎修正，將透過 repository Issues 接受勘誤。**定性**模式則穩固：AI 原生生產產出比比較者多一個數量級的文件、同時支援多語、且具備比較者結構上欠缺的 provenance 與讀者可查詢性。我們指出此比較是**生產範式**之間的比較，而非方法論本身實質優劣的比較。

### 9.3 限制

我們列舉三項誠實的限制：

- **幻覺風險。** 儘管有引用紀律與 `/evidence-audit`，殘存的幻覺主張可能仍存在。歡迎讀者透過 repository Issues 標示。
- **IDE 存取不對稱。** 無 Claude Code、Cursor 或同類工具的讀者無法完整運用「讀者作為查詢者」的模式。這以經濟資源層級化存取，這是我們共同的擔憂。
- **永續性。** Toolkit 的生產速率取決於對當代 LLM 的持續可負擔存取。明顯的價格上漲或能力下降將改變計算。
- **資料隱私與智財權。** 將讀者特定的情境（如 `/socratic-challenge`）輸入至依賴公有雲 API 的 IDE 中，可能引發企業機密外洩的疑慮。此範式在企業級部署時，將高度依賴 Zero-data-retention 協議或地端 Local LLM 的成熟。

### 9.4 本論文不主張之事

我們明確指出本論文**不**做的三項主張：

- **不主張「已經同儕審查」。** 在 Zenodo 發布只授予持久識別符，非同儕審查。本 preprint 是為社群回饋而提供的；經同儕審查的版本是下一步。
- **不主張「已透過經驗案例研究驗證」。** Toolkit 的實質方法論（L1-L5、八階段流程）已被謹慎**建構**，但尚未透過縱貫式客戶交付經**驗證**。此驗證是另一條研究線目前正在規格設計階段的明確主題（見 repository 中 `90_References/PILOT_STUDY_PROTOCOL.md`）。
- **不主張「AI 為作者」。** 生產環境是 AI 原生，但作者責任——以及對錯誤的問責——由人類作者承擔。共同作者 trailer 承認 AI 對特定 commit 的貢獻，並不轉移作者身份。

### 9.5 計畫驗證實驗（預註冊）

為了讓本文從「立場與製品」貢獻向研究級評估推進，我們**預註冊（pre-register）** 一項小樣本讀者採用研究，將於 v1.0.0 發布後進行。下列協議現在即提供，讓審稿者在結果出現前評估方法適切性；最終結果將於 v2.0 修訂中呈現。

**假設。**

- **H1（時間）：** 使用讀者作為查詢者 workflow（`/socratic-challenge`、`/theory-bridge`、`/deep-synthesize`）回答方法論理解問題的讀者，每題所需時間將少於使用相同方法論靜態 PDF 形式的讀者。
- **H2（正確性）：** 讀者作為查詢者的答案在正確性上將相對 PDF 閱讀答案非劣（non-inferior），正確性以與方法論作者預先撰寫的評分量規一致性衡量。
- **H3（應用準備度）：** 讀者作為查詢者的參與者在 10 分鐘的後問卷應用草稿任務中，將產出比 PDF 參與者更具體、更組織專屬的應用草稿。

**設計。** 受試者內交叉（within-subject crossover），n = 6 位參與者（兩種背景各 3 位：有經驗的管理顧問；對顧問框架不熟悉的資深 IT 專業人員）。每位參與者完成兩個 session，間隔 ≥ 7 日，順序對抗平衡：Session A 使用 AI-IDE 讀者作為查詢者模型；Session B 使用相同內容的 PDF 渲染版本。每個 session 呈現相同 8 題理解題（每 session 內容隨機不同）與相同的 10 分鐘應用草稿任務。

**測量。**

- 每題作答時間（連續，自動記錄）；
- 答案正確性（5 點量規，由獨立評分者盲分）；
- 應用草稿涵蓋度（引用的方法論元素計數；品質由同一盲評分者 1-5 評分）；
- 自陳認知負荷（NASA-TLX 簡式）；
- 自陳偏好（實驗後 Likert）。

**統計計畫。** 受試者內差異採配對 t 檢定（或 Wilcoxon 符號秩檢定，若分布非常態）；三組假設家族採 Bonferroni 校正。樣本（n = 6）以調查研究標準而言為小，但對於我們使用的受試者內交叉設計為足夠；我們報告效果量與 p 值並列，並將研究視為探索性而非確認性。

**預註冊。** 完整協議、量規、問卷文字、應用草稿題目、統計計畫將於招募第一位參與者前 deposit 至 OSF（Open Science Framework）登錄，並以 Zenodo 連結的 DOI 標示。連結將於本 preprint v1.1 修訂時附於本節。

**計畫研究的限制。** 受試者內交叉設計控制了參與者間變異但引入順序效應；對抗平衡僅部分處理此問題。樣本為作者專業網路便利招募，限制了可推廣性。AI-IDE 熟悉度為一干擾變項，我們透過簡短前 session 訓練控制，但無法完全消除。

**為何在執行研究前就預註冊。** 在結果出現前預註冊承諾分析計畫，避免事後 fishing。本 preprint 的審稿者應將 §9.5 視為**可證偽承諾（falsification commitment）**：若研究執行後假設未獲支持，v2.0 修訂必須誠實報告 null 或反向發現。

---

## 10. 討論與意涵

### 10.1 對專業電子書生產與方法論工程

專業電子書生產的傳統成本結構一直是進入門檻，特別是當書籍承載方法論、成熟度模型或流程架構這類高結構內容時。Toolkit 顯示：單一個人若有紀律地使用 AI IDE，可在數月內產出過去通常需要機構團隊與較長週期才能完成的成果。意涵不是「所有專業電子書都將變成單作者」——恰恰相反，**評估**負擔仍然巨大。但**建構**階段的進入門檻已顯著下降。

這可能對顧問業結構產生二階效應。方法論歷史上是大型事務所的準專有資產（Bain Way、McKinsey 7-Step）。AI 原生開源方法論在 Apache 2.0 授權下、附 DOI 可引用 provenance，以根本不同的基礎競爭。是否會導致方法論的**commons** 模式（類比於開源軟體）是我們在此無法解決的經驗問題；但生產的前提條件現在已具備。

### 10.2 對 HCI 與 IDE 設計

Toolkit 為「**IDE 即媒介**」命題提供了一個新規模的案例。Cursor、Claude Code、Antigravity、Codex 並非專為電子書生產或方法論工程設計，但其通用設計足以支撐此類版本化文字製品的生產。這暗示 AI IDE 設計者三個方向：

1. **First-class 的 workflow 規格。** `.claude/workflows/`、`.codex/workflows/` 目錄慣例正成為 *de facto* 規範。形式標準化（`.ide-workflows/` 目錄？YAML schema？）將有助於可攜性。
2. **跨 IDE handoff 原語。** 目前作者在 Claude Code 與 Codex 之間手動切換。一個「在另一個 IDE 引擎 spawn 此任務並回傳結果」的原語將收緊編排。
3. **Provenance 作為內建功能。** Co-Authored-By 的 Git trailer 是可行的過渡解，但並非專為 AI provenance 設計。一個行級 AI 署名標準（類比於 `git blame`）將使 provenance 故事成熟。

### 10.3 對學術出版

Zenodo + GitHub release 模式提供「不適合傳統期刊論文形式」的製品一條立即可用的正式學術出版路徑。路徑如下：

1. Apache 2.0 授權 + `NOTICE` 署名要求；
2. GitHub-Zenodo 整合自動鑄造每個 release 的 DOI；
3. `CITATION.cff` 用於機器可讀引用元資料；
4. 在 SSRN 發布 preprint 以在社會科學與管理文獻中被發現；
5. 衍生論文投稿會議／期刊。

這一路徑同時處理三件傳統出版常被綁在一起、但在開放知識製品中應被拆開的事：**出版識別**、**權利宣告**與**權利登記／註冊**。GitHub 提供開發與版本協作所需的 tag、commit 與 release record；DOI 讓讀者、審稿者與引用資料庫能把某一個 release 當作「出版版本」穩定引用；`LICENSE`、`NOTICE`、front matter 與 Zenodo license metadata 則宣告著作權保留與再利用條件；若作者所在法域提供且需要著作權註冊，則可另行向主管機關註冊該版本或作品，以建立官方權利紀錄。本文採取的原則是：每一個可被引用的 release 都應同時有版本 DOI、清楚授權、機器可讀引用資訊、人類可讀的版權／授權說明，並在適用法域中保留可銜接著作權註冊或權利證明的 metadata。

此 stack 不取代同儕審查，但消除「**等待**同儕審查」的成本，讓引用證據與讀者參與可以提早累積。

更重要的是，如 §8.2.1 所闡述，此 stack 應被理解為**生命週期中三個不同的層**，而非同一概念的三種包裝：Git 提供作者問責、GitHub 提供公開參與與共演化、Zenodo 提供學術固定與可引用性。這裡的出版創新不在於任一單一機制（三者皆早於本論文存在），而在於它們作為一條**整合管線（stacked composition）**被組合起來，用於專業知識型電子書與高結構知識製品的出版。我們主張，此組合本身值得被命名、值得在電子書與學術製品出版工具集中佔有可被辯護的位置 —— 與期刊論文、學術專書並列，而非取代。

### 10.4 對「AI Slop」擔憂

LLM 增強內容生產的批評者常援引「AI slop」——流暢、聽起來合理、實質無錨定的內容。我們共享此擔憂。我們主張適當回應不是揚棄 AI 生產，而是強制執行 provenance 紀律：Git 歷史、workflow 檔案歸檔、引用要求、對抗式審查、DOI 持久性。「AI slop」與「AI 原生學術」的差別正是紀律本身。Toolkit 的生產作為此紀律實務樣貌的一個示範被提供。

### 10.5 經驗研究議程

我們以本論文未回答、希望在後續工作處理的三個經驗問題作結：

- **讀者採用研究。** 讀者作為查詢者模型是否可衡量地減少專業電子書內容消費與組織應用之間的翻譯勞動？
- **跨作者複製。** 若不同作者、具不同盲點，在相同領域（GenAI 採用）產出競爭的 AI 原生電子書，製品在涵蓋度、內部一致性、讀者採用上將如何比較？
- **縱貫式知識製品演化。** 24 個月內，當 LLM 能力與 IDE 功能演進時，製品如何改變？workflow 檔案手法是否優雅地老化，或變得過時？

---

## 11. 結論

AI 原生電子書生產——以 GenAI Consulting Methodology Toolkit 為 demanding case——代表專業知識型電子書如何被建構、出版、消費的有意義轉變。四項區辨特性——多 IDE 編排、讀者作為查詢者互動、同步多語一致性、完整 provenance——共同將高結構電子書的生產成本結構改變了一個數量級，同時改善（而非減弱）製品的可稽核性。

此範式並非無限制，且若干問題——特別圍繞經驗讀者採用與跨作者複製——仍未解決。我們邀請研究社群與此製品互動、以 Apache 2.0 授權 fork、並將此範式延伸到新的專業電子書與知識製品領域。

Repository、本 preprint、workflow 規格、`CITATION.cff` 檔案皆開放可用。引用資訊位於 front matter。

---

## 致謝

作者感謝 Queensland University of Technology 的 Prof. Michael Rosemann 對 Business Process Management 學派的長期智識影響——Toolkit 的成熟度模型方法即源自此血緣。方法論為作者個人責任；所有錯誤、遺漏、向 AI 領域的延伸應用均不代表 Prof. Rosemann 或 QUT 的觀點。

我們致謝生產 Toolkit 與本論文所使用的 AI 引擎：Anthropic Claude（Opus 4.6、4.7）、OpenAI Codex CLI、Google Antigravity。AI 對特定 commit 的貢獻已透過 Git 歷史中的 `Co-Authored-By:` trailer 記錄。

---

## 參考文獻

> 本中文版保留英文書目資訊；學術引用應使用英文原始書目以利國際對照。
>
> **引用稽核（v1.0）。** 下列所有參考文獻在 v1.0 發布前皆已對外部來源獨立重新驗證。稽核過程修正：APQC (2024) → (2022/2024) 以準確反映發布／現行版本狀態；Bostock (2017) 從「Observable: A new way to think with code」修正為「A Better Way to Code」（Medium）；Long et al. (2024) 從 CHI 2024 修正為 DIS 2024 並補 DOI；Victor (2014)「Seeing Spaces」venue 主張因二手來源不一致而軟化；Claude Code、Cursor、Google Antigravity、OpenAI Codex CLI 的產品引用明確補上。**產品文件與廠商部落格僅用以證明工具的存在與能力，不作為本論文研究主張的學術證據。** Lu (in preparation) 為作者本人尚未發表之作品，依設計無法被外部驗證。其他條目的勘誤歡迎透過 repository Issues 提出。

### A. 學術文獻（同儕審查論文、博士論文、技術報告）

Becker, J., Knackstedt, R., & Pöppelbuß, J. (2009). Developing maturity models for IT management. *Business & Information Systems Engineering*, 1(3), 213-222. DOI: 10.1007/s12599-009-0044-5

de Bruin, T. (2009). *Business process management: Theory on progression and maturity* [Doctoral dissertation, Queensland University of Technology].

de Bruin, T., & Rosemann, M. (2005). Towards a Business Process Management Maturity Model. In *Proceedings of the 13th European Conference on Information Systems (ECIS 2005)*.

de Bruin, T., & Rosemann, M. (2007). Using the Delphi technique to identify BPM capability areas. In *Proceedings of the 18th Australasian Conference on Information Systems*.

Engelbart, D. C. (1962). *Augmenting Human Intellect: A Conceptual Framework*. Stanford Research Institute, Summary Report AFOSR-3223.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. *MIS Quarterly*, 28(1), 75-105. DOI: 10.2307/25148625

Kluyver, T., Ragan-Kelley, B., Pérez, F., et al. (2016). Jupyter Notebooks -- a publishing format for reproducible computational workflows. In *Positioning and Power in Academic Publishing: Players, Agents and Agendas*, IOS Press, 87-90. DOI: 10.3233/978-1-61499-649-1-87

Knuth, D. E. (1984). Literate programming. *The Computer Journal*, 27(2), 97-111. DOI: 10.1093/comjnl/27.2.97

Lee, M., Liang, P., & Yang, Q. (2022). CoAuthor: Designing a human-AI collaborative writing dataset for exploring language model capabilities. In *Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems*. DOI: 10.1145/3491102.3502030

Long, T., Gero, K. I., & Chilton, L. B. (2024). Not Just Novelty: A Longitudinal Study on Utility and Customization of an AI Workflow. In *Proceedings of the 2024 ACM Designing Interactive Systems Conference (DIS '24)*. DOI: 10.1145/3643834.3661587

March, S. T., & Smith, G. F. (1995). Design and natural science research on information technology. *Decision Support Systems*, 15(4), 251-266. DOI: 10.1016/0167-9236(94)00041-2

Mirowski, P., Mathewson, K. W., Pittman, J., & Evans, R. (2023). Co-writing screenplays and theatre scripts with language models. In *Proceedings of CHI 2023*. DOI: 10.1145/3544548.3581225

Paulk, M. C., Curtis, B., Chrissis, M. B., & Weber, C. V. (1993). *Capability Maturity Model for Software, Version 1.1*. Carnegie Mellon University, Software Engineering Institute (CMU/SEI-93-TR-024).

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. *Journal of Management Information Systems*, 24(3), 45-77. DOI: 10.2753/MIS0742-1222240302

### B. 書、專業方法與業界出版（非同儕審查但可信來源）

APQC. (2022). *Process Classification Framework, Version 7.3*. APQC. Current as of 2024.

Bostock, M. (2017). *A Better Way to Code*. Medium, April 28, 2017.（後來成為 d3.express 與 Observable。）

Friga, P. N. (2009). *The McKinsey Engagement: A Powerful Toolkit for More Efficient and Effective Team Problem Solving*. McGraw-Hill.

Rasiel, E. M. (1999). *The McKinsey Way*. McGraw-Hill.

Rosemann, M., & de Bruin, T. (2005). Application of a Holistic Model for Determining BPM Maturity. *BPTrends*, February 2005.

Victor, B. (2011). Explorable Explanations. *Personal essay*, <http://worrydream.com/ExplorableExplanations/>.

Victor, B., & Hellman, D. (2014). *Seeing Spaces*. Talk / dynamic poster.（Dynamicland 存檔；二手來源對原始 venue 說法不一，此處不作單一 venue 主張。）

### C. 產品文件與廠商／業界研究筆記（非學術證據）

Anthropic. (2025). *Claude Code documentation*. Anthropic. <https://docs.anthropic.com/en/docs/claude-code/overview> （Accessed 2026-05-18）

Anysphere. (2026). *Cursor: The AI code editor*. Anysphere. <https://cursor.com/> （Accessed 2026-05-18）

Gartner. (2024). *Gartner AI Maturity Model*. Gartner research note, 2024-11-20. <https://www.gartner.com/en/documents/5937907> （Accessed 2026-05-18；完整 revision history 為付費內容；本來源所衍生之主張刻意保持 approximate、不主張可獨立重現）

Google. (2025). *Start building with Gemini 3*. Google Blog, 2025-11-18.（介紹 Google Antigravity 作為 agentic development platform。）<https://blog.google/technology/developers/gemini-3-developers/> （Accessed 2026-05-18）

OpenAI. (2025). *OpenAI Codex CLI: Getting started*. OpenAI Help Center. <https://help.openai.com/en/articles/11096431-openai-codex-cli-getting-started> （Accessed 2026-05-18）

Taiwan Intellectual Property Office. (2020). *Must copyrights be registered to receive protection?* Ministry of Economic Affairs, R.O.C. <https://www1.tipo.gov.tw/en/cp-313-183443-48c3c-2.html> （Accessed 2026-05-19）

U.S. Copyright Office. (n.d.). *Copyright in General: Frequently Asked Questions*. <https://www.copyright.gov/help/faq/faq-general.html> （Accessed 2026-05-19）

U.S. Copyright Office. (n.d.). *What is Copyright?* <https://www.copyright.gov/what-is-copyright/> （Accessed 2026-05-19）

### D. 作者本人尚未發表之作品

Lu, M. (in preparation). *L1-L5: A Generative AI Adoption Maturity Model for Enterprises.*

### E. 引用狀態表（供審稿透明度）

下表將上方各條引用依「證據類型」分類，讓審稿者一眼區分學術證據與輔助文件。**C 區產品文件**僅用以證明工具存在與能力，**不作為**本論文研究主張的學術證據。

| 引用 | 類型 |
| --- | --- |
| Hevner et al. (2004) | 同儕審查期刊論文 |
| Peffers et al. (2007) | 同儕審查期刊論文 |
| March & Smith (1995) | 同儕審查期刊論文 |
| Becker et al. (2009) | 同儕審查期刊論文 |
| Knuth (1984) | 同儕審查期刊論文 |
| de Bruin & Rosemann (2005) | 同儕審查會議論文 |
| de Bruin & Rosemann (2007) | 同儕審查會議論文 |
| Lee et al. (2022) | 同儕審查會議論文 |
| Mirowski et al. (2023) | 同儕審查會議論文 |
| Long et al. (2024) | 同儕審查會議論文 |
| Kluyver et al. (2016) | 同儕審查書章 |
| Paulk et al. (1993) | 技術報告（CMU/SEI）|
| Engelbart (1962) | 技術報告（SRI）|
| de Bruin (2009) | 博士論文 |
| Rasiel (1999) | 專書 |
| Friga (2009) | 專書 |
| Rosemann & de Bruin (2005) | 業界／實務出版物（BPTrends）|
| APQC (2022) | 業界／標準機構出版物 |
| Bostock (2017) | 個人散文（Medium）|
| Victor (2011) | 個人散文 |
| Victor & Hellman (2014) | 演講／動態海報 |
| Gartner (2024) | 業界研究筆記（付費；僅引用作脈絡）|
| Anthropic (2025) | 廠商文件 |
| Anysphere (2026) | 廠商文件 |
| Google (2025) | 廠商公告／部落格貼文 |
| OpenAI (2025) | 廠商文件 |
| Taiwan Intellectual Property Office (2020) | 政府著作權 FAQ |
| U.S. Copyright Office (n.d.) | 政府著作權 FAQ |
| Lu (in preparation) | 作者本人尚未發表之作品 |

---

## 附錄 A —— Workflow 列表

Toolkit 的生產環境編碼 22 個專門化 workflow，橫跨三個 IDE 家族。每個 workflow 為一份對應 IDE 可閱讀與執行的 markdown 規格。

### A.1 Claude Code workflows（`.claude/workflows/`）

| Workflow | 用途 | 生產用途 |
| --- | --- | --- |
| `/deep-synthesize` | 多檔深度綜合（1M context）| 跨階段一致性草擬 |
| `/theory-bridge` | 映射客戶情境與 7 大學術支柱 | 新讀者上手 |
| `/scenario-planning` | 3 條對比路線圖加 tradeoff | 情境庫生成 |
| `/socratic-challenge` | 探問式問題磨利讀者思考 | 讀者對話模式 |
| `/cross-stage-trace` | 單一變動的下游影響 | 變動傳播分析 |
| `/simulate-engagement` | 完整 6 週顧問案模擬 | 銷售 demo、訓練素材 |
| `/parallel-perspectives` | 6 個利害關係人並行視角 | 利害關係人地圖生成 |
| `/thought-experiment` | 反事實壓測 | 脆弱性地圖生成 |
| `/devil-pair-debate` | 兩個 Claude 對辯，第三方裁判 | 價值觀偏見浮現 |
| `/methodology-fork` | 客戶特化方法論分叉 | 客製部署 scaffold |

### A.2 Codex workflows（`.codex/workflows/`）

| Workflow | 用途 | 生產用途 |
| --- | --- | --- |
| `/academic-upgrade` | 將實務散文轉為學術 register | 本 preprint |
| `/bump-version` | 跨檔案的版本協調升版 | Release 管理 |
| `/consistency-review` | 跨檔一致性稽核 | Pre-commit gate |
| `/diagnose` | 子區域工程診斷 | 品質分類 |
| `/evidence-audit` | 驗證每個主張都有引用 | 幻覺防護 |
| `/generate-report` | 機械式報告組裝 | 交付物生成 |
| `/generate-traceability` | 建立追溯矩陣 | Provenance 支援 |
| `/harvest-insights` | 從原始筆記精煉洞察 | 筆記轉發表 pipeline |
| `/methodology-test` | 將方法論套用到合成情境 | 自我驗證 |
| `/red-team-review` | 對作者輸出進行對抗式審查 | QA gate |

### A.3 Antigravity workflows（`.antigravity/workflows/`）

| Workflow | 用途 | 生產用途 |
| --- | --- | --- |
| `/diagnose` | 多代理診斷 | 並行角色扮演訪談 |
| `/generate-report` | 多代理報告草擬 | 並行交付物生產 |

---

## 附錄 B —— 可重現性 Manifest

從任一較早 commit 重新衍生 Toolkit 的實質子集：

1. Clone repository：`git clone https://github.com/MorrisLu-Taipei/GenAI-Consulting-Methodology-Toolkit.git`
2. Checkout 指定 commit：`git checkout <commit-hash>`
3. 在 Claude Code（或相容 AI IDE）中打開 repository。
4. 呼叫 workflow，例如：`/deep-synthesize "Re-derive Stage 4 Gap Analysis from Stage 2 and Stage 3"`。
5. 將 workflow 輸出與該 commit 對應的實際 Stage 4 文件比較。

對於實質結構內容預期會收斂；對於風格選擇與精確字句預期會發散。

---

*本 preprint v1.0 中文版結束。作者歡迎來信、勘誤、複製嘗試，聯絡方式見上方 email 與 repository。*
