D4. 資料處理邊界｜Bytecode 可編輯輸出研究

本頁所稱「Bytecode」泛指 .xlsx / .docx / .pptx 等二進位檔案格式（OOXML 容器）， 不是 Java / Python 那種編譯產物，也不是任何產品代號。

B3 案例庫目前的 case 都假設「.xlsx 進、.xlsx 出」，但真實需求未必限於 Excel—— 可能是「幫我生出一份可再編輯的 Word 提案書」、「輸出可再編輯的 PPT 簡報」、「交一份可再改數字的試算表」。 本頁不陷入單一檔案格式細節，而是從「產出物的可編輯性」這個更高層次的軸，盤點 Bytecode 的能力邊界—— 哪些格式能做到「真・可編輯」、哪些只能做到「看起來像但打開不能改」、哪些根本做不到。 結論用來決定 B3 案例庫該擴充哪些類別、E 類需要再開哪些技術研究、B4 IDE 規則需要定義哪些協議。

TL;DR

  • 「可編輯」本身是光譜，不是 yes/no。同樣是 .xlsx，有「資料可改、公式不保留」「資料可改、公式保留」「連樣版與圖表都保留」三檔，代價差很多。
  • .xlsx / .docx / .csv / .md 是純前端可編輯輸出的綠區； .pptx 是黃區（能生但圖表與動畫限制多）； .pdf 是紅區（本質不為編輯設計，只能當「最終交付物」）。
  • 保留「原樣式 + 新資料」的最務實路徑是模板預埋， 而不是從零組出一個視覺完美的檔案——後者成本指數級上升。
  • B3 應該保持「pure data transform」定位； 「生出漂亮 docx 提案書」「生出客製 pptx 簡報」屬 B 區另一類（文件生成），不該混進資料處理。

格式 × 可編輯光譜

這張表把每個檔案格式拆成「從生成到使用」的四道關卡——能不能在瀏覽器裡直接生出來、使用者拿到能不能再改、原本的字型版面有沒有被保留、公式與外部連結有沒有活著，最後一欄是適合的場景。 建議從右邊「適合場景」找到貼近自己需求的那一行，再橫向比對前四欄。 符號：✓ 可以、△ 有條件（通常需要先準備一份空白樣版檔， 也就是「模板預埋」——設計師把版型做好，系統只負責替換資料）、✗ 做不到、— 不適用。

格式純前端可生成可再編輯保留樣式保留公式 / 連結適合場景
.csv / .md✓✓——純資料、可版本控管
.xlsx（資料）✓✓✗✗B3 目前所有 case
.xlsx（樣版）△✓✓✓報表、發票、提案書
.xlsx（含圖表）✗✓✓✓需 SheetJS Pro 或模板
.docx（純文字）✓✓△—會議紀錄、摘要
.docx（樣版）✓✓✓—合約、提案書、信件
.pptx△✓△—報表簡報；複雜設計需模板
.pdf✓✗✓—最終交付，不可再編輯

為什麼同樣的副檔名要拆成多行

副檔名相同，能力可能差一個量級——這也是讀這張表最容易被誤判的地方。 把 .xlsx 與 .docx 拆開列出，是為了讓客戶情境對得上技術路徑：

  • .xlsx（資料）vs .xlsx（樣版）： 前者是「給我一份乾淨的試算表」，程式直接長出來； 後者是「給我一份印得出去的報表 / 發票」，必須先有設計師排好版的空白範本。 一句「幫我生 Excel」可能是其中任何一種，開發成本與前置工差一個量級。
  • .xlsx（樣版）vs .xlsx（含圖表）： 「保留版面樣式」與「保留可再生的圖表」是兩件事。 前者模板預埋能解，後者純前端免費套件做不到，要動用付費套件或伺服器端方案。 客戶說「我要好看的 Excel」時，要先問清楚是要排版漂亮、還是要圖表能再改。
  • .docx（純文字）vs .docx（樣版）： 前者是會議紀錄、摘要這種「內容為主、版面其次」，程式直接生即可； 後者是合約、提案書這種「版面就是價值」，必須走 docxtemplater + 設計師樣版。 維護負擔也不同——樣版改一次設計就要重做。

結論：接到「幫我生 Word / Excel / PPT」這類需求時，先問要的是「純資料」還是「有版面」， 再對照表中對應的那一行判斷可行性，避免把不同層次的題目混在一起估時程。

表格細節說明

  • .csv / .md「✓ 可再編輯」：任意文字編輯器即可改。
  • .xlsx（資料）「✗ 保留公式」：純 SheetJS 寫出時公式會被計算成值。
  • .xlsx（樣版）「△ 純前端可生成」：需要事先準備空白樣版，由設計師畫好版型、系統替換資料。
  • .xlsx（含圖表）「✗ 純前端可生成」：免費方案無解，需 SheetJS Pro 或模板綁 Named Range，詳見 E1。
  • .docx（純文字）「△ 保留樣式」：基本樣式（粗體、標題層級）可保留，複雜排版易失真。
  • .docx（樣版）「✓ 純前端可生成」：使用 docxtemplater（Word 範本填值套件）。
  • .pptx「△ 純前端可生成」：使用 pptxgenjs（PowerPoint 生成套件），複雜版型困難。

三個設計層次

把需求拆成三個逐級困難的層次，避免把不同層次的題目混在一起討論：

Layer 1 — 結構層可編輯（綠區）

使用者打開檔案能改資料、文字、儲存格內容。 這是 Bytecode 目前 B3 做到的，.xlsx、.csv、.md、純文字 .docx 都落在這層。 純前端、免費套件足夠，B3 案例庫可放心擴充。

Layer 2 — 樣式層可編輯（黃區）

除了改資料，還要保留字型、色彩、段落格式、合併儲存格、表格樣式。 最可行路徑是「模板預埋」——設計師先做好空白樣版（.xlsx / .docx），Bytecode 只替換標記欄位。 這是一個「介於 B3 資料處理與 B 區文件生成」的中間地帶， 建議獨立成 B6. 樣版文件生成（與 B3 並列），不要塞進 B3。

Layer 3 — 互動層可編輯（紅區）

要保留公式、圖表、樞紐表、資料驗證、交互連結、PPT 動畫等「活」的元素。 純前端免費方案幾乎無解，需要 SheetJS Pro、模板綁 Named Range、或改走伺服器端 OOXML library。 這層每個格式都有獨立的 E 類研究題（E1 已處理 Excel 圖表），不該倉促進 B 區。

十個核心問題（自問自答）

🎓 好學生

Q1. Bytecode 產出的檔案，使用者真的可以再編輯嗎？

A. 看層次。Layer 1（結構層）——完全可以；Layer 2（樣式層）——走模板就可以；Layer 3（互動層）——大多數情況下不能。 回答這個問題前，先釐清使用者要改的是「資料」「版型」還是「公式/圖表」。

Q2. 除了 .xlsx，Bytecode 能生出可編輯的 .docx / .pptx 嗎？

A. .docx 可以、.pptx 部分可以。.docx 有成熟的 docxtemplater 與 docx.js，樣版式文件（合約、提案書）純前端可做； .pptx 有 pptxgenjs，但只能產出「簡單版型」的簡報，公司級設計樣版幾乎必然失真。 要做到「可編輯簡報」建議 Layer 2 + 模板策略。

Q3. 為什麼 .pdf 不算「可編輯」？

A. PDF 的設計前提就是「固定版面、不可再改」。雖然有 PDF editor 工具，但打開後改動是破壞性的、體驗差、格式易爆。 PDF 定位是 最終交付物，如果使用者需要再編輯，交付時就應該用 .docx / .xlsx。

😏 酸民

Q4. 那 Bytecode 不就跟 mail merge 一樣？

A. 樣版層確實像，但資料層不是。Mail merge 只是「欄位替換」，Bytecode 在 Layer 1 還能做合併 / 拆分 / 清理 / 轉置等資料邏輯， 在 Layer 2 才接近 mail merge。重點是 Bytecode 把兩件事縫在一起：先把資料整乾淨，再塞進樣版。

Q5. 你說可以生「樣版 .xlsx」，那樣版誰做？AI 自己生？

A. 目前必須人工設計、AI 不畫樣版。AI 生成像樣的商業樣版（字型搭配、版式比例、品牌色）成本高且不穩定。 務實作法是：設計師做一次樣版 → AI 永遠只替換資料。 這決定了 B6 樣版文件生成的運作模型。

Q6. 「可編輯」跟「好編輯」是兩件事吧？

A. 對，這是光譜尾端的體驗問題。一份 .xlsx 技術上「可編輯」（打得開、存得回去），但若沒有命名範圍、沒有表格格式、公式散落， 使用者改起來很痛苦。Layer 2 的模板預埋就是為了「不只可編輯、還好編輯」。

Q7. 規模問題——生一份 500 頁的報告還可能純前端嗎？

A. 不建議。單頁數十 KB、500 頁就到十幾 MB，瀏覽器端產生與下載流程都會卡。 超過數十頁的批次文件生成應交給後端 pipeline，屬 B4 IDE 規則範疇。

🧪 問題學生

Q8. 能不能生「互相連動」的多檔？

A. 純前端做不到、模板可以。若 .xlsx A 的儲存格要連到 .xlsx B，OOXML 層級的 external link 純前端 library 幾乎都不支援。 真的需要「活連動」建議走模板預埋，或乾脆把兩份資料合進一份多 sheet 的檔案。

Q9. 可不可以「生出一份可編輯的網頁」？

A. 可以，但已經不是 Bytecode 的題目。產出靜態 HTML 或 Markdown 技術上瑣碎，真正的問題是「誰 host」「誰管 URL」「怎麼再改」。 這跳出 Bytecode 單次任務的語意，屬 B4 IDE 規則或另一個產品（Page Builder）。

Q10. Bytecode 串接成 pipeline 時，中間檔要是什麼格式？

A. 建議 .csv / .json 為主、.xlsx 為輔。.xlsx 當中間檔會累積樣式雜訊與效能負擔； pipeline 節點間用 .csv / .json，只在「交付給使用者」那一步才組合成 .xlsx / .docx。 這是 B4 pipeline 規則需要確立的約定。

B3 擴充建議

短期可擴充 B3（Layer 1 範疇）

  • 多 sheet 合併 / 拆分（輸入輸出都還是 .xlsx 結構操作）
  • N 檔合併（200 個分店總表）
  • 新增 E 類：資料轉置（寬↔長、pivot / unpivot）
  • 新增 F 類：資料計算（衍生欄位、groupby 統計）
  • 新增 G 類：資料比對（兩檔 diff）
  • 輸入格式擴充：.csv、.md 表格（仍屬 Layer 1）

另開新 B 區（Layer 2 範疇）

  • B6. 樣版文件生成——.xlsx 報表樣版、.docx 合約 / 提案、.pptx 簡報
  • 明確與 B3 的分工：B3 做資料、B6 做版面，B6 可消費 B3 的輸出

需要先做技術研究（E 類）

  • E5. 公式與圖表保留輸出（承接 E1，覆蓋所有 Layer 3 題目）
  • E6. 多格式輸入研究（PDF / 照片 / Google Sheet → 結構化資料）
  • E7. 樣版設計規範（B6 要能跑起來，需先定義樣版標記語法）
  • E8. 後端批次文件生成（> 數十頁、> 10 萬列）

屬於 B4 IDE 規則（不進 B 區）

  • 排程與狀態持久化（定時跑、寄出）
  • Pipeline 編排與中間檔規範
  • 互動確認協議（計畫/執行兩階段）
  • 外部副作用（寄 email、寫 DB、推播）

一句話定位

B3 處理資料邏輯（Layer 1）、B6 處理文件樣版（Layer 2）、 E 類研究互動格式（Layer 3）、B4 管流程編排。釐清這四條線，就不會再被「可不可以生出可編輯的 XX」這類問題打亂節奏。