• 能把 5 個行政題目各做成 1 個 Opal mini-app，並能交付給同仁直接使用。
• 能用「PII Gate + 去識別化管線」把個資風險留在校內端處理。
• 能把自訂 GPT / Gem / Claude Skills 的核心 instructions 變成可管理的資產（assets），並建立版本治理。

• Opal 的輸入/輸出不會用於訓練生成式模型，但仍可能有人為檢視少量內容做除錯或理解用例。
• 行政資料常包含「直接識別」與「可再識別」資訊；後者最容易被忽略（小單位＋特定事件＋精準時間地點）。
• 應對策略：Opal 只處理去識別資料；需要回填真實資訊時，在校內端回填。

防線	你要做的事	行政實踐提示
第 1 層 選對方案	優先用具資料保護承諾的企業/教育版；釐清資料使用條款。	但不要把「條款」當成免死金牌；仍須第 3 層。
第 2 層 關閉/控管設定	混用個人帳號時，關閉活動紀錄/改進；避免把敏感內容留在聊天歷史。	這層容易因人而異，因此需要第 3 層「制度化」補強。
第 3 層 去識別化＋對照檔	本地端移除/替換個資，產出去識別版本；mapping 加密留校內。	Opal 只看代碼（S0001…）；需要回填真實值時，本地端回填。

• 標題就寫「去識別版」：讓使用者心理預期先對齊。
• 禁輸入：姓名、學號、身分證/居留證、電話、email、地址、出生年月日、銀行帳號。
• 高敏感：成績、獎懲、弱勢/財務、申訴/性平、心理/醫療資訊。
• 可再識別資訊：小單位＋特定事件＋精準時間地點（要改寫成抽象描述）。

建議固定代碼規則：學生 S0001、教師 T0001、承辦角色 A主管/B同仁、文件 DOC01。

• 格式範本：公文欄位、會議紀錄章節、需求書章節、證據鏈索引表欄位。
• 紅線清單：不可對外揭露資訊、不可輸出個資欄位、不得承諾超出範圍的條款。
• 語氣規範：缺件通知信、對外 Q&A、內部稽核寫作方式。
• 版本資訊：每份資產加版本號＋更新摘要＋生效日（讓同仁知道自己在用哪一版）。

• 在 prompt 中用 @ 插入工具，或用工具名稱明確要求「只查公開資料」。
• 行政常用的「安全句型」：要求多來源、附連結、禁止搜尋校內敏感內容。

請使用 [Search Web] 只查「公開資料」，蒐集 3 個彼此獨立的來源。
輸出時每點都要附上來源連結（URL），並標註你引用的關鍵句位置。
不要把任何校內內規、內部文件內容、或可識別資訊拿去搜尋。

提醒：工具呼叫會在 Console 留下痕跡；把 Console 當成稽核視窗。

• 每個 Generate 只做一件事：抽取／檢核／生成／品質檢查。
• 任何固定規格（格式/語氣/紅線）放到 Add Assets，不要塞在 prompt 裡。
• 長文件先做「去識別摘要」再送入，避免一次貼上大量敏感內容。
• 預設保留一個「人工覆核提醒」步驟，讓團隊知道模型最不確定哪裡。

• 輸入：需求摘要＋可公開片段（禁放報價與敏感條款）。
• 資產：需求書章節範本＋對外資訊紅線清單。
• Generate：草稿→Q&A→可驗收性檢查。
• 跳到第 5 題內容

• User Input：公文內容（去識別）、單位清單＋職掌關鍵字＋分派規則。
• Add Assets：公文欄位範本（收文/發文者/主旨/說明/期程/承辦建議/風險）。
• Generate：先判斷是否疑似含個資，通過才產出摘要與分派。
• Output：Webpage（閱讀）＋ Drive Sheet（一列一公文）。

下一頁提供可直接貼到 Opal 的「建置 Prompt」。

請建立一個 Opal mini-app，名稱為「公文摘要與分派建議（去識別版）」。

流程請包含 6 個步驟（steps）與 1 個資產（asset）：

[Step 1 | User Input | 公文內容輸入]
- 讓使用者提供「已去識別化」的公文文字（若 UI 支援檔案上傳/Drive 選檔，則允許上傳 PDF，並要求系統先把文字擷取後再處理）。
- 在輸入提示文字中明確提醒：不可包含姓名、學號、身分證號、電話、email、地址、出生年月日、個案描述可識別資訊。

[Step 2 | User Input | 分派規則與單位清單]
- 讓使用者貼上「單位清單＋每個單位的職掌關鍵字（最多 10 個）」與「分派規則」（例如：若涉及採購→總務；若涉及課程/學籍→教務；若涉及計畫/補助→研發；若涉及學生獎助→學務等）。
- 提示：這些規則屬於校內資訊，不要包含特定人的姓名。

[Step 3 | Add Assets | 公文欄位範本]
- 要求使用者上傳一份「公文欄位範本」文字檔或 Google 文件（範例欄位：收文日期、發文者、主旨、說明、期程、承辦建議、需回覆事項、可能風險）。
- 這份 asset 會當作輸出格式的約束。

[Step 4 | Generate | PII Gate（個資防線）]
- 目的：先掃描 Step 1 的內容是否疑似含個資或可識別描述。
- 若偵測到疑似個資，請直接輸出「拒絕處理」並列出需要移除的片段類型（不要回傳原文）。
- 若通過，輸出「OK」並給一個簡短提醒：仍需人工覆核。

[Step 5 | Generate | 摘要與分派建議]
- 依 asset 的欄位範本，生成：
  1) 150–250 字摘要（含期限/時程）
  2) 三項「需要承辦立即處理」的待辦
  3) 建議承辦單位（從 Step 2 的單位清單中選 1–2 個）
  4) 兩個風險提醒（例如：期限不明、權責不清、可能涉及對外回覆）
- 禁止輸出任何個資；如內容不足，標示「原文未提供」。

[Step 6 | Output | 匯出]
- 同時提供兩種輸出：
  A. Webpage（auto-layout）：給使用者快速閱讀
  B. 匯出到 Google Drive spreadsheet：一列代表一份公文，欄位依 asset 範本
- 若同一次只處理 1 份公文，仍以 1 列寫入試算表。

請確保每個 Generate step 的 prompt 會引用對應的 User Input 與 asset（使用 @ 參照），並在 Console 可追溯每一步輸入與輸出。

• User Input：申請資料（用代碼）＋規定條文（或文字擷取）。
• Add Assets：檢核表範本＋缺件通知信模板（承辦窗口用「單位」）。
• Generate：條款→檢核項目（8–15 條）→個案檢核（缺件/不確定/風險）。
• Output：Webpage（含通知草稿）＋ Sheet（每列一申請者代碼）。

下一頁：可直接貼上建置 Prompt。

請建立一個 Opal mini-app，名稱為「獎助學金初審檢核（去識別版）」。

流程包含 7 個步驟與 2 個資產：

[Step 1 | User Input | 申請資料（去識別）]
- 讓使用者貼上申請資料（可用表格文字或 JSON），並要求把姓名/學號改為代碼（例如 S0001）。
- 明確提醒：不得包含身分證/居留證號、地址、電話、email、銀行帳號、家庭財務細節。

[Step 2 | User Input | 獎助規定條文（可貼上）]
- 讓使用者貼上規定條文（或重點條款摘要）。
- 若 UI 支援檔案上傳，可上傳規定 PDF 後再擷取文字。

[Step 3 | Add Assets | 初審檢核表格式（範本）]
- 上傳一份檢核表格式範本（欄位至少包含：條款編號、檢核項目、符合/不符合/不確定、需要的佐證、缺件說明、需人工判斷原因）。

[Step 4 | Add Assets | 通知信模板（範本）]
- 上傳校內常用的缺件通知信格式（含稱謂、語氣、回覆期限、承辦窗口「單位」而非「個人」）。

[Step 5 | Generate | 規則拆解（轉成可檢核清單）]
- 把 Step 2 的規定條文拆成 8–15 條可操作的檢核項目，並對應到 Step 3 範本欄位輸出。

[Step 6 | Generate | 個案初審（缺件/風險/需人工判斷）]
- 逐條檢核 Step 1 的申請資料：
  1) 產出缺件清單（以「需要什麼證明」描述）
  2) 產出 3 個「需人工判斷」點（例如：條款灰色地帶、資料不完整）
  3) 產出一段給承辦的風險提醒（不要寫個資）
- 若資料不足，填「不確定」並說明原因。

[Step 7 | Output | 匯出]
- Webpage（auto-layout）：顯示「檢核結果摘要＋缺件清單＋需人工判斷清單」
- Google Drive spreadsheet：每一列代表一位申請者代碼（S0001），欄位包含：符合度概覽、缺件項目數、需人工判斷項目數、建議處理優先順序
- 同時在 Webpage 顯示「缺件通知信草稿」，草稿必須套用 Step 4 的語氣與格式，且不可包含個資。

請確保所有 Generate prompts 都使用 @ 參照前一步輸入與 assets，並在 Console 可追溯每一步輸入/輸出。

• User Input：逐字稿（人名改代碼）＋會議基本資料（會議名/日期/出席角色）。
• Add Assets：會議紀錄格式範本（章節固定）。
• Generate：先抽取 JSON/表格（決議/待辦/爭議/補資料），再生成會議紀錄。
• Output：Webpage（紀錄＋待辦）＋ Sheet（每列一個 Action Item）。

下一頁：可直接貼上建置 Prompt。

請建立一個 Opal mini-app，名稱為「會議紀錄與待辦追蹤（去識別版）」。

流程包含 6 個步驟與 2 個資產：

[Step 1 | User Input | 逐字稿（去識別）]
- 讓使用者貼上逐字稿文字。
- 明確提醒：把人名改為角色代碼（A主管、B同仁、學生X），不得包含可識別個案描述。

[Step 2 | User Input | 會議基本資料]
- 讓使用者提供：會議名稱、日期、出席角色（用代碼）、主持/紀錄者代碼、會議目的（1–2 句）。

[Step 3 | Add Assets | 會議紀錄格式範本]
- 上傳校內常用會議紀錄格式（至少包含：決議事項、討論重點、待辦事項、責任歸屬、期限、追蹤方式）。

[Step 4 | Generate | 先抽取再寫（結構化抽取）]
- 先把逐字稿抽取成結構化資料（JSON 或表格），欄位至少包含：
  1) 決議事項（含依據句：引用逐字稿的原句片段，但要把可識別資訊遮掉）
  2) 待辦事項（Action Items）：內容、負責角色代碼、期限（若未提到期限，標示「未提」）
  3) 爭議/未決事項（需要誰決策）
  4) 需要補資料清單

[Step 5 | Generate | 生成會議紀錄＋追蹤表]
- 依 Step 3 範本輸出完整會議紀錄（繁體中文、行政語氣、不要口語贅詞）。
- 另外產出一份「待辦追蹤表」：每列 1 個 Action Item（欄位：編號、內容、負責角色、期限、狀態預設為 Open、依據句位置）。

[Step 6 | Output | 匯出]
- Webpage（manual layout）：請用清楚區塊呈現「會議紀錄」與「待辦追蹤表」兩部分。
- Google Drive spreadsheet：寫入待辦追蹤表（每列 1 個 Action Item）。
- 額外要求：在 Webpage 最後加一段「人工覆核提醒」：列出本次模型最不確定的 3 個判斷點。

請確保使用 @ 參照 steps 與 assets，並可在 Console 看到每一步輸入/輸出與 tool calls（若有）。

• User Input：指標清單＋佐證資料摘要（以文件代碼 DOC01…描述）。
• Add Assets：證據鏈索引表範本＋版本與命名規則。
• Generate：指標—證據對應＋版本一致性檢查（避免新版指標引用舊版佐證）。
• Output：Webpage（索引＋風險提示）＋ Sheet（每列=指標×文件）。

下一頁：可直接貼上建置 Prompt。

請建立一個 Opal mini-app，名稱為「評鑑佐證證據鏈索引（去識別版）」。

流程包含 7 個步驟與 2 個資產：

[Step 1 | User Input | 指標清單]
- 讓使用者貼上評鑑指標清單（每條包含：指標代號、指標敘述、要提供的佐證類型）。

[Step 2 | User Input | 佐證資料摘要（去識別）]
- 讓使用者以「文件清單」方式提供佐證內容：
  每份文件用一段文字描述（文件代碼 DOC01、文件名稱、版本日期、摘要、關鍵段落文字）。
- 明確提醒：不要貼含個資的原文；若必要，先遮罩後再貼。

[Step 3 | Add Assets | 證據鏈索引表範本]
- 上傳索引表格式（欄位至少包含：指標代號、對應文件代碼、頁碼/段落位置、證據摘要、缺口、下一步補件）。

[Step 4 | Add Assets | 版本與命名規則（範本）]
- 上傳你們單位的檔案命名規則（例如：YYYYMMDD_主題_v1.2），以及版本更新原則。

[Step 5 | Generate | 指標—證據對應（建立索引）]
- 依 Step 3 範本，把 Step 1 的每個指標對應到 Step 2 的文件代碼。
- 每個指標至少要有 1 個證據；若沒有，標示缺口並寫出要補什麼。

[Step 6 | Generate | 版本風險提示與一致性檢查]
- 檢查 Step 2 的文件版本日期是否互相矛盾（例如新版指標卻引用舊版佐證）。
- 產出「版本風險提示」：列出 3–5 個最可能造成評鑑被追問的版本/證據鏈問題。

[Step 7 | Output | 匯出]
- Webpage（auto-layout）：顯示索引表＋版本風險提示
- Google Drive spreadsheet：匯出索引表（每列=一個指標對應一個文件）
- 額外要求：輸出最後加上「哪些內容必須人工回查原文」清單（只列文件代碼與位置，不貼原文）

請確保 prompts 使用 @ 參照 steps 與 assets，並在 Console 可追溯每一步輸入/輸出。

• User Input：需求摘要＋「可公開」片段（禁帳密/金鑰/完整拓樸/敏感條款）。
• Add Assets：需求書格式範本＋對外資訊紅線清單。
• Generate：需求書草稿→供應商 Q&A→可交付性/可驗收性檢查（補齊指標）。
• Output：Webpage（草稿＋Q&A＋檢查清單）＋ Sheet（Q&A 一列一題）。

下一頁：可直接貼上建置 Prompt。

請建立一個 Opal mini-app，名稱為「採購/委外需求書與問答（去識別版）」。

流程包含 8 個步驟與 2 個資產：

[Step 1 | User Input | 需求摘要（去識別）]
- 讓使用者描述需求背景、目的、範圍、交付項目、預計時程。
- 明確提醒：不得包含內部帳密、金鑰、完整網路拓樸、可用來攻擊的資安細節；不得包含特定人姓名與聯絡方式。

[Step 2 | User Input | 既有標案/合約的「可公開」片段]
- 讓使用者貼上過去文件中「可以對外公開」的片段（例如：交付物格式、服務等級指標），不要貼價格、廠商敏感條款。

[Step 3 | Add Assets | 需求書格式範本]
- 上傳你們單位常用需求書格式（章節：背景、目標、範圍、交付物、驗收方式、時程、投標須知、保密條款摘要等）。

[Step 4 | Add Assets | 對外資訊紅線清單]
- 上傳一份「不可對外揭露」清單（例如：內網 IP、系統弱點、未公開政策、個資欄位明細、資安設定等）。

[Step 5 | Generate | 需求書草稿（第一版）]
- 依 Step 3 範本產出需求書草稿。
- 強制遵守 Step 4 紅線：若使用者輸入疑似踩線，改寫成抽象描述，並標記「已抽象化」。

[Step 6 | Generate | 供應商問答（Q&A）]
- 先生成 10 個供應商最可能會問的問題（範圍/介面/驗收/時程/保固/罰則/資料處理）。
- 再針對每個問題生成「答覆原則」：避免承諾超出 Step 1 範圍；避免揭露紅線。

[Step 7 | Generate | 品質檢查（可交付性）]
- 以採購承辦角度檢查：需求是否可驗收、是否有可量化指標、是否有灰色地帶會引發追加費用。
- 產出 5 個你建議承辦在送件前補齊的項目。

[Step 8 | Output | 匯出]
- Webpage（manual layout）：上半部需求書、下半部 Q&A、最後品質檢查清單。
- Google Drive spreadsheet：輸出 Q&A（每列 1 題：問題、答覆原則、是否需法務/資安覆核）。

請確保所有 Generate prompts 都以 @ 參照 steps 與 assets，並可在 Console 追溯每一步輸入/輸出與 tool calls（若有）。

import re
import uuid
import pandas as pd

RE_TW_ID = re.compile(r"\b[A-Z][12]\d{8}\b")
RE_EMAIL = re.compile(r"\b[\w\.-]+@[\w\.-]+\.\w+\b")
RE_PHONE = re.compile(r"\b(?:\+?886[- ]?)?0?\d{1,2}[- ]?\d{6,8}\b")
RE_STUDENT_NO = re.compile(r"\b\d{8,10}\b")

PII_COLUMNS_HINT = {"姓名", "學號", "身分證", "電話", "email", "地址", "出生"}

def pseudo_id(prefix: str) -> str:
    return f"{prefix}{uuid.uuid4().hex[:8].upper()}"

def pseudonymize_value(v, mapping, prefix="P_"):
    if pd.isna(v) or str(v).strip() == "":
        return v
    raw = str(v).strip()
    if raw not in mapping:
        mapping[raw] = pseudo_id(prefix)
    return mapping[raw]

def redact_text(s, mapping):
    if pd.isna(s):
        return s
    t = str(s)
    t = RE_TW_ID.sub("[TW_ID]", t)
    t = RE_EMAIL.sub("[EMAIL]", t)
    t = RE_PHONE.sub("[PHONE]", t)

    def repl_student(m):
        return pseudonymize_value(m.group(0), mapping, prefix="SNO_")
    t = RE_STUDENT_NO.sub(repl_student, t)
    return t

def sanitize_table(input_path, out_sanitized, out_mapping):
    df = pd.read_excel(input_path) if input_path.endswith((".xlsx", ".xls")) else pd.read_csv(input_path)
    mapping = {}

    for col in df.columns:
        col_name = str(col)
        if any(h in col_name for h in PII_COLUMNS_HINT):
            df[col] = df[col].apply(lambda v: pseudonymize_value(v, mapping, prefix="PII_"))
        else:
            df[col] = df[col].apply(lambda v: redact_text(v, mapping))

    df.to_csv(out_sanitized, index=False, encoding="utf-8-sig")
    pd.DataFrame(mapping.items(), columns=["original_value", "pseudonym"]).to_csv(
        out_mapping, index=False, encoding="utf-8-sig"
    )

sanitize_table("input.xlsx", "sanitized.csv", "mapping.csv")

• 保存位置：校內受控環境（加密磁碟、限制下載、記錄存取）。
• 權限：只有需要回填的人可讀；承辦同仁日常只用代碼版本。
• 保存期限：對應行政流程（例如審查結案後 X 天刪除）；不要永久留存。
• 稽核：誰在何時用過 mapping、回填了哪份輸出、是否有二次輸出。
• 抽樣檢查：每批資料抽樣確認「仍可再識別」的描述已被抽象化。

治理對象	你要版本化的內容	最小可行規則
Opal mini-app	steps 結構、節點 prompts、Output 欄位、資產引用方式	v1.x 改欄位/流程；v1.x.y 修文字；每次改版寫更新摘要
Assets	格式範本、紅線清單、用語規範、檢核表	資產檔名含版本號＋生效日；資產內第一行寫版本資訊
Scripts（本地端）	去識別化程式、mapping 加密、稽核紀錄	先假資料測試；上線前必有權限/保存期限；變更需可回溯

• User Input：禁輸入清單是否明確？是否要求代碼化？
• Generate：是否有 PII Gate？是否先抽取再生成？是否列出不確定點？
• Assets：格式範本/紅線/語氣是否資產化？是否有版本號與更新摘要？
• Output：是否同時有 Webpage（閱讀）與 Sheet（追蹤）？欄位是否可回查？
• 本地端：是否有去識別化管線？mapping 是否加密、最小權限、到期刪除？
• 稽核：Console/Sheet 是否能回溯每次處理？是否有人工覆核紀錄？