SSP 文件解析器（白話需求草稿 — 已歸檔）

狀態：Phase 1 brainstorming 已完成，spec 已細化為 api-spec.md 歸檔日期：2026-04-30 撰寫人：raymond

以下為原始白話需求，作為溯源參考。最新可執行 spec 請見 api-spec.md（SA） 與後續的 design.md（SD）。

Phase 1 brainstorm 修正了三點原始想法（不再採用）：

1. OSCAL JSON 匯出沿用既有邏輯 — 既有匯出邏輯不存在，v1 不做、留 v2
2. 系統元件 / 軟體元件 / 外部系統結構化抽取 — 範例 docx 該章節多半是敘述，無結構，v1 跳過
3. LLM 輔助解析 — v1 純規則 + 拖拉指派，LLM 留 v2 候選

詳見 api-spec.md §1.2。

客戶（資安顧問 / 受評公司）目前都用 Word 寫 SSP（System Security Plan）。 他們把寫好的 docx 上傳到 Guidant AI 後，希望系統能：

1. 自動把控制項段落抓出來，對應到指定的合規規範(NIST 800-171 / CMMC / ISO27001 )控制項目錄
2. 抽取每個控制項的「實作描述（control implementation statement）」，填到對應的 SSP control implementation 欄位
3. 遇到對應不到的段落（章節標題不規則、段落混排），顯示在「待人工確認清單」，讓使用者拖拉指定歸屬
4. 再多分析其他可用資訊 文件內可能會有系統元件, 軟體元件或是其他系統環境章節內的資訊, 是否可以在拆解出來, 放入SSP相關的物件內, 也在確認系統內有沒有對應的資料可以存放, 沒有的話可以討論是否新增

• 顧問拿到客戶寫好的 docx，丟進系統 → 期望看到自動對應結果
• 客戶自己寫 SSP，邊寫邊上傳更新 → 系統需要支援 重新解析 而不覆蓋使用者已手動編輯的部分

• 「上傳 → 自動解析 → 呈現解析結果 → 使用者只需確認 / 微調」
• 比起目前「人工逐條 copy-paste」，預期省 70% 時間
• 解析結果要能轉成 OSCAL JSON 匯出（後段流程沿用既有匯出邏輯）
• 自動辨識文件內 control, ao 的現況說明, 並可自動填入

• docx 章節標題格式各家寫法不一（有人用 "3.1.1 AC-1"、有人寫 "Access Control - AC-01"）→ 需要 fuzzy match
• 表格內的控制項描述抽取可能不準
• 同一個控制項在 docx 內可能被拆到多個段落，要能合併

• 客戶範本：reference/ASIA-CMMC-SSP-DRAFT-202604.docx（CMMC Asia draft，作為主要解析目標）
• 既有的 SSP control implementation 模型：jedi-oscal 內的infra.model的資料

1. 在合規資源庫, 新增/編輯 資源庫現況資料時, 可以允許匯入docx, 目前只有針對excel處理
2. 在專案規劃頁面, 規劃專案內容時, 可以允許匯入docx, 目前只有針對excel處理
3. 匯入後要有預覽以及即時編輯的UI
4. 再幫我想設計看看有沒有其他更好的方式

1. 幫我分析後, 列出要決策的項目, 我們逐項討論
2. 你可以先拿範例文件來分析, 這個規格可能隨時會再更新, 我們先出這一版
3. 如果有建議的docx的格式, 也可以討論, 目前還在定義這份範例文件