7 天可上線 · 內部 MVP 決策報告

澳洲留學公司 GS AI 小工具:最終整合方案

基於兩份 HTML 報告與 10 份成功 AI 回覆整合。本報告把高層可讀的工作流放在外層,將完整 prompt、模型回覆、錯誤路由與技術細節放入預設折疊區,方便工程師展開核對。

7 天完成可用內部工具,不追求完整平台
2 套最快 Google Sheet 方案 + 推薦 Streamlit 方案
10 份DeepSeek / Gemini / Grok / MiniMax / Claude 成功回覆已整合
人工審核AI 產出草稿,人員挑選、核對、調整後使用

一眼看懂:公司要做的不是大型 AI 平台,而是「標準化 GS 生產線」

目前 GPT-5.5 / Claude Opus 4.6+ 在官方 web 介面已被驗證能產出 99% 可用 GS。真正問題不是模型能力,而是同事不會穩定整理資料、寫 prompt、判斷風險。因此 7 天 MVP 的核心,是把你現在成功的人工流程固定成工具。

員工操作
貼上學生 Google Drive link,填可選撰寫方向,按「生成草稿」。
AI 處理
讀取客戶文件、檢查 Form 500 與證件/課程/財務資料一致性,套公司 GS 知識包與官方要求,多模型撰寫。
人工把關
輸出多個 AI 版本的 Word 草稿,員工比較、挑選、核對、調整後才用於簽證材料。

未來標準工作流

1. 顧問放資料按固定 Drive folder 結構放 Form500、護照、財務、課程、照片與備註。
2. 員工貼連結在工具輸入 Google Drive link,可選填「想強調的方向」。
3. 系統讀文件抽取 DOCX/PDF/Google Docs 文字;掃描件先標 OCR needed。
4. AI 分析建立學生 facts、檢查 Form500 與證件/課程/資金一致性,列缺失與風險。
5. 多模型撰寫Claude / Gemini / DeepSeek / GPT 等輸出同一 schema,再統一轉 Word。
6. 人工挑選員工比較多份 Word,核對 evidence checklist,調整後定稿。

兩套 7 天內可落地方案

方案 A:Google Sheet + Apps Script + Python Worker

最快試用

適合:公司想最快讓 2-5 位內部人員開始用,不想先做正式 web app。

  • Google Sheet 作為操作面板:Drive link、顧問方向、狀態、輸出連結。
  • Apps Script 負責按鈕與權限,呼叫 Python worker。
  • Python worker 負責下載文件、抽文字、組 prompt、呼叫模型、生成 Word。
  • 輸出 Word 存回指定 Drive folder。
優點:員工零學習成本,3-7 天能跑;缺點:長期維護與錯誤追蹤較弱,不適合快速擴大多人使用。

方案 B:Streamlit + Python + Google Drive API

推薦 MVP

適合:希望 7 天內做出一套像產品的小工具,後續可升級成正式內部系統。

  • Streamlit 做單頁內部 UI:貼 link、填方向、選模型、查看進度、下載 Word。
  • Python 原生處理 PDF/DOCX/OCR fallback、token 截斷與 Word 排版。
  • 可保存 log、prompt version、模型輸出、review checklist。
  • 可部署在公司電腦、Cloud Run、VPS 或內部伺服器。
優點:7 天仍可完成,但比 Sheet 方案更穩、更像工具;缺點:需要簡單部署與權限配置。

方案比較

項目方案 A:Sheet + Worker方案 B:Streamlit App建議
上線速度最快,3-7 天可用約 5-7 天可用若只有展示/試用,選 A;若要日常用,選 B
使用者體驗像填表,簡單但不漂亮像內部小工具,可顯示進度與錯誤B 更適合少數授權人員長期使用
文件處理核心仍要靠 Python workerPython 原生處理,較穩B
權限與審計Google 權限好用,但 log 較散可做使用者、prompt、模型、輸出版本 logB
未來升級容易重寫可升級 FastAPI / Next.js / RAGB

7 天 MVP 架構圖(推薦方案 B)

Streamlit UIDrive link、方向、模型選擇、生成狀態。
Drive Reader讀 folder、下載文件、檢查標準結構。
ParserPDF/DOCX/Docs/Sheets 抽文字;圖片列附件或 OCR。
Prompt Builder固定 Knowledge Pack + Student Evidence Pack + 顧問方向。
Model Runner並行呼叫多模型,要求 JSON/Markdown schema。
Word Renderer統一排版,輸出多份 GS Word 與 checklist。

固定 Drive folder 結構

Student_Name_or_ID/
  01_Form500/
  02_Passport_ID/
  03_Course_COE_Offer/
  04_Education_Employment/
  05_Finance/
  06_Family_Ties/
  07_Photos_Portfolio/
  08_Consultant_Notes/
  09_Other/

7 天開發進度拆分

1定規格

鎖定 folder 結構、Word 模板、Knowledge Pack v1、prompt schema、模型清單。

2Drive 接入

完成 folder link 解析、檔案列舉、權限錯誤、缺資料 warning。

3文件抽取

完成 PDF/DOCX/Google Docs/Sheets 文字抽取與 token 截斷規則。

4Prompt + 模型

組 Student Evidence Pack,串 Claude/Gemini/DeepSeek/GPT 可用 API。

5Word 輸出

使用 python-docx 統一渲染多模型 Word,含 150-word answers、long version、checklist。

6測試修正

用 3-5 個歷史案例測試,修 prompt、修截斷、修排版、修錯誤訊息。

7內部上線

部署、權限、操作手冊、審核 SOP、版本記錄,給少數授權人員使用。

輸出的 Word 應該長什麼樣

章節目的誰看
Cover Page學生、課程、provider、生成模型、生成時間、Draft 標記內部
Case Summary3-5 點總結本案主線與撰寫策略顧問/審核人
Risk Notes列缺失資料、Form500 與證件/課程/資金不一致、簽證風險審核人
ImmiAccount GS Answers每題英文 <=150 words,附 word count可複製到申請表
Long Version GS完整敘事稿,供內部理解與必要時附件參考內部/必要時使用
Evidence Checklist每個重要主張對應來源文件審核人
Photo / Portfolio Appendix插入或列出作品/生活照片來源顧問/審核人
Human Review Checklist要求人工勾選:事實、字數、法規、語氣、文件齊備最終把關人

7 天 MVP 必須做的風險控制

防止 AI 亂寫

  • 所有 factual claim 必須附 evidence_ref。
  • 找不到來源時標記 [NEEDS_CONFIRMATION]。
  • 顧問方向與文件矛盾時列 warning,不盲從。
  • temperature 設低,輸出 schema 固定。

防止不合規提交

  • Word 封面標 Draft / Human Review Required。
  • 每題自動 word count,超過 150 words 標紅或重寫。
  • 固定法規來源,不讓模型自行編 URL。
  • 人工 review checklist 必填。

防止資料遺漏

  • 缺 Form500、護照、course offer/CoE、finance 時標高風險。
  • 掃描 PDF 抽不到文字時列 OCR needed。
  • 所有未讀取圖片列入附件清單。
  • 處理前顯示文件 inventory。

防止隱私事故

  • API key 放 server env,不放前端。
  • 只允許授權人員使用。
  • 每案隔離 temp directory,處理後清理。
  • 記錄 user、time、folder、model、prompt version、output version。

推薦 Prompt 模板框架

展開查看工程師可直接實作的 Prompt Schema
System Prompt:
You are an Australian Student Visa Genuine Student drafting assistant for an education agency.
You must follow the official GS requirement: English answers, maximum 150 words per ImmiAccount answer, evidence-supported claims, no fabrication, no migration-intent framing.
You must output structured JSON/Markdown only. Do not create unsupported facts.

Knowledge Pack:
- Home Affairs GS requirement snapshot with version date.
- Direction No. 106 summary and closer scrutiny factors.
- Company GS writing rules.
- De-identified successful examples summarized as situation/risk/strategy/answer.
- Common risk handling rules.

Student Evidence Pack:
- Extracted facts grouped by personal details, education, employment, family, finance, course/provider, immigration history, photos/portfolio.
- Each fact includes source_file, page_or_section, confidence.
- Missing documents and unreadable files are listed.

Consultant Direction:
- Optional user instruction.
- If it conflicts with evidence, flag the conflict instead of following blindly.

Output Schema:
- case_summary: bullet list
- risk_flags: list of issues and severity
- missing_information: list
- form500_consistency_check: list of checked fields and mismatches
- gs_answers: array; each item contains question, answer, word_count, evidence_refs
- long_version: full internal GS draft
- supporting_evidence_checklist: array of claims mapped to source files
- photo_appendix_notes: list of useful photos or portfolio files
- self_check: word_count_ok, evidence_ok, unsupported_claims, regulation_ok, human_review_required

Forbidden:
- Do not invent awards, jobs, income, family ties, career plans, travel history, visa history, or documents.
- Do not cite laws or URLs not supplied in the Knowledge Pack.
- Do not imply the main purpose is migration or permanent residence.
- Do not ignore missing evidence.

成本與商業判斷

外包每份約 AUD 100-200。7 天 MVP 後,每案主要成本會變成模型 API、可選 OCR、少量運算與人工審核。依兩輪模型回覆估算,若每案跑 2-4 個模型,直接 API 成本多數情況可能落在 USD 2-20;即使加上人工審核時間,仍能顯著低於外包,且可保留公司內部知識與版本紀錄。

真正省下來的不是只有外包費。更重要的是:輸入流程統一、prompt 不再靠個人能力、輸出格式一致、風險能被系統提醒、案例知識能逐步沉澱。

最終建議

若公司有一位能寫 Python 的工程師,我建議直接做「方案 B:Streamlit + Python + Google Drive API」。7 天內足夠做出可用小工具,且後續能升級。若公司完全沒有部署條件,先做「方案 A:Google Sheet + Apps Script + Python worker」作為過渡。

第一版不要承諾「AI 自動完成可提交簽證材料」。產品命名與 UI 應寫成「GS Draft Generator / AI Draft Assistant」。AI 產出的是草稿,多模型版本供人工挑選與調整;最後仍由授權員工核對 Form500、證件、資金、課程資料、字數和官方要求後定稿。

來源與依據

技術附錄:各模型 Prompt 與 AI 原文回覆

以下預設折疊,給工程師或管理層需要追溯時展開。內容直接來自 MCP job JSON,未做摘要替代。

第一輪:長期架構與風險分析:完整 Prompt 與 AI 回覆
Round 1 - DeepSeek V4 Pro deepseek-v4-pro · 0.00665115 USD

Prompt

你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。

【背景】
我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。

公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。

【預計資料夾/知識來源】
1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。
2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。
3. 成功案例 GS 文件夾:已成功學生 GS。
4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。
目標是讓 AI 能持續參考、持續進步。

【本地範例資料概況】
本地資料夾:C:\Users\F\AiFolder\Projects\SC_AI\GS撰寫技巧補充文件夾
包含:
- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。
- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。
範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。

【官方資料依據,請納入分析】
1. Australian Department of Home Affairs - Genuine Student requirement
來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement
重點:
- GS requirement applies to student visa applications lodged on or after 23 March 2024; before that date assessed under GTE.
- Applicants must be genuine applicants for entry and stay as a student and show understanding that studying in Australia is the primary reason.
- Online form asks: current circumstances including family/community/employment/economic ties; why this course/provider and understanding of course/living in Australia; how the course benefits the applicant; other relevant information; extra question for prior student visa / applying in Australia from non-student visa.
- Home Affairs prefers responses in the application form rather than separate GS statement.
- 150 words per response, all in English.
- Supporting documents in ImmiAccount matter; more weight is given to statements supported by evidence.
- Assessment considers circumstances, immigration history, compliance with visa conditions, course/provider/living knowledge, value of course to future, salary/employment benefit, and other relevant matters.

2. Home Affairs Document Checklist Tool
來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool
重點:
- GS answers must be English and max 150 words per question.
- Supporting documents may include qualifications, transcripts, proof of employment, CV/resume with education/employment history.
- In line with Ministerial Direction 106, factors include circumstances in home country, potential circumstances in Australia, value of course to future, immigration history, other relevant matter; if minor, intentions of parent/legal guardian/spouse.

3. Ministerial Direction No. 106 - Assessing the genuine entry and stay requirements for Student visa and Student Guardian visa applications
來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf
重點:
- Commences 23 March 2024 and applies to Subclass 500 Student visa applications on or after that date.
- Genuine student criterion refers to clause 500.212 of Schedule 2 to the Regulations.
- Decision makers should not use listed factors as a mechanical checklist; they assess circumstances as a whole.
- Further scrutiny may apply where there is migration fraud risk, concerning immigration history, intended course unrelated to previous studies/employment, inconsistencies, applicant holds/held certain visas including student visa/visitor/485 etc.
- Factors include home country circumstances, reasons for not studying similar course locally, family/community/employment ties, economic circumstances, military/civil unrest, knowledge of course/provider/living in Australia, level of research, whether visa is used to maintain residence, value of course to future, consistency with past education/employment, expected remuneration, immigration history, and for minors the intentions of parent/legal guardian/spouse.

【我想問你】
1. 這樣的工具方向合理嗎?哪些部分合理,哪些部分有風險?
2. 如果把所有成功案例、失敗案例、法令資料、客戶資料都給模型,會不會導致 token 越來越大、反而失去焦點?應如何避免?
3. 你會如何設計更好的方案?請具體到架構,例如 Google Drive 文件接入、OCR/文件解析、結構化抽取、RAG、案例檢索、prompt pipeline、多模型生成、評分/審核、Word 輸出、人類審核、版本保存。
4. 成功案例與失敗案例應如何被 AI 使用?是直接塞 prompt、做 vector DB、做分類/標籤、做 rubric、還是 fine-tuning?請比較。
5. 最新移民局公告/法令資料應如何自動更新與引用?如何避免過期法規、幻覺引用、錯誤法規?
6. 因為客戶資料包含護照、身份、財務、家庭等敏感資料,請分析資料安全、權限、審計、供應商 API、資料出境/保留/刪除、隱私合規風險。
7. 多模型策略:Claude/OpenAI/DeepSeek/Gemini/Grok/Minimax 等同時生成是否值得?是否應該每個模型生成完整 GS,還是分工,例如抽取、風險審核、撰寫、評分?
8. 目前澳洲 GS 官方是每題 150 words 且偏好填入表格,而公司卻想輸出完整 GS Word。如何設計輸出格式最務實?是否應包含 150-word ImmiAccount answers + evidence-backed internal long note + supporting document checklist?
9. 請提出 MVP 版本、V1 版本、V2 版本的落地路線圖與大概成本/時間/風險。
10. 請給出你建議的最終架構與流程,並列出關鍵資料表/資料模型、prompt 模板策略、評分 rubric、人類審核 checklist。

請把回答寫得完整,不要短答。請直接給結論、架構、風險、建議與可執行步驟。

AI Reply

【DEEPSEEK-V4-PRO · deepseek-v4-pro】
以下將以「建構企業內部 GS 撰寫輔助系統」為目標,完整、具體地回答十個問題。內容將以繁體中文呈現,並經常引用您提供的官方依據與範例。

---

## 1. 工具方向合理嗎?哪些合理?哪些有風險?

**合理處:**
- 用 AI 輔助撰寫 GS 的方向是對的。目前 Claude Opus、ChatGPT 等模型只要拿到結構化客戶資料與優質範例,確實能寫出流暢、邏輯連貫、符合簽證官關注點的英文答案。比起全人工從零撰寫,效率可提升 5-10 倍,成本可從 100-200 澳幣/案降至個位數美金/案。
- 指定「Google Drive 學生文件夾 + 撰寫方向」作為起點,貼近留學顧問現有工作流,導入阻力低。
- 多模型同時生成再讓人挑選,能降低單一模型偏誤(如某模型習慣過度承諾、語氣不自然),也增加「可提交版本」的命中率。

**風險:**
1. **合規風險**:Home Affairs 明確表示「prefers responses in the application form rather than separate GS statement」,目前系統若只生成一份 Word 文件,可能產生員工直接上傳 Word 而非填入 ImmiAccount 表格的偏差,反而引起簽證官對真實性的質疑。  
2. **品質風險**:150 字的嚴格限制(Ministerial Direction 106 配套的線上表格)如果沒被寫進 prompt,模型容易寫出冗長段落,甚至無法被 ImmiAccount 接受。  
3. **幻覺風險**:法令、課程名稱、學校資訊若由模型憑記憶生成,極可能出錯,導致簽證被拒。  
4. **隱私風險**:護照、財務、家庭資料透過公用 API 傳輸至境外,若不處理將違反澳洲 Privacy Act 1988 乃至客戶國的個資法。  
5. **維護風險**:法令、成功案例若只靠手動丟入,會隨時間失效,且人工維護成本高,最終員工不信任系統而棄用。

**結論:方向正確,但要補上「強制內嵌的合規輸出格式」「嚴格引用/證據驅動」「資料不落地或脫敏的隱私設計」「自動更新知識庫」才算成熟工具。**

---

## 2. Token 爆炸與失焦風險及其解法

若把「所有成功/失敗案例、法令PDF、客戶資料」一次塞進 prompt,勢必導致:
- Context 過大,推理成本急升(Claude Opus 200K token 一次可超過數美元)。
- 模型注意力分散,遺漏關鍵細節(如客戶的拒簽歷史、資金缺口)。
- 失敗案例可能「汙染」輸出,模型無意學習拒簽理由中的不良敘事。

**解法:檢索增強生成(RAG)+ 結構化「案例卡」+ 動態組裝 prompt**
- 客戶資料先經過「結構化抽取」模組,產出 JSON(個人背景、教育、財務、家庭、簽證史等),不再把原始證件 PDF 直接塞 prompt。
- GS 撰寫技巧、法令條文、成功案例精華改為存入向量資料庫(如 Pinecone、Qdrant、Pgvector)。根據客戶的「國家、課程類型、資金來源、過去拒簽與否」等特徵,只檢索最相關的 Top-K 段落(例如 3 個相似背景的成功故事、2 條適用法規)。
- 案例做成「Card」:200~400 字的“成功要點摘要”+完整文件連結,而非整份 PDF 餵入。
- Prompt 設嚴格的 token 預算:System prompt 固定(含格式要求、評分 rubric),檢索到的參考資料限 3-4K tokens,客戶結構化資料限 2K tokens,總 prompt 控制在 8-12K tokens,確保模型聚焦。

如此可避免無差別灌資料,維持高度相關性,也讓每次生成成本可控。

---

## 3. 更好的方案設計(具體架構)

以下為完整 pipeline,從輸入到輸出、審核一氣呵成:

**階段 0:資料接入與預處理**
- Google Drive API 監聽「學生文件夾」:自動列出所有文件(證件掃描、Form 500、照片等)。
- OCR/文件解析層:針對掃描件用 Azure Document Intelligence / Amazon Textract 提取文字、表格;docx/pdf 直接解析。若照片有文字(如獎狀),亦 OCR 並以多模態模型(GPT-4V/Gemini)描述。
- 結構化抽取模組(用 GPT-4o mini 或自家微調模型):從各文件中抽出標準化 JSON——《學生基本資訊》、《教育史》、《工作史》、《家庭成員與財務》、《簽證史》、《旅行史》、《課程選擇與動機備註》(來自 Form 500 或顧問筆記)。

**階段 1:知識庫與檢索**
- 知識來源:
  - 法令庫:定時爬取 immi.homeaffairs.gov.au 指定頁面 + Ministerial Direction 106 PDF,切成段落,以 embedding 儲存,並記錄「生效日期與版本」。
  - 成功案例庫:每份成功 GS 轉成結構化案例卡(客戶畫像、GS問答亮點、證據清單),以 embedding + 標籤(國籍、課程等級、資金來源、有無配偶、有無拒簽史等)存入向量庫。
  - 失敗案例庫:同樣結構化,特別抽取「拒簽理由段落」與「對應的 GS 弱點」,標註風險類別(如資金不足、學習動機不強、移民傾向)。
  - GS 撰寫技巧庫:由資深顧問維護的模式段落、修辭建議、常見陷阱。
- 檢索:根據「當前客戶 JSON」與「撰寫方向」進行多模態檢索(關鍵字 + 向量),得到 Top-N 相關參考素材,並附上來源 metadata。

**階段 2:多模型生成與評分**
- Prompt Pipeline:將檢索結果、客戶 JSON、官方要求(150 words per answer, English only, evidence-backed)組裝成最終 prompt,同時送入 Claude、OpenAI、DeepSeek、Gemini(或更多)。每個模型獨立生成「完整 GS 答案集」。
- 內建雙層審核:
  1. **自動評分模型**(如用 GPT-4 校訂 + 規則引擎):對每份生成答案,針對「字數合規」「證據引用」「邏輯一致性」「風險因子(如移民傾向暗示)」打分,輸出評分報告。
  2. **規則檢查器**:程式檢查必含關鍵字、引用的文件是否存在、日期是否一致等。
- 將多個版本及其評分並列展示給顧問,並高亮各版的風險點。

**階段 3:輸出與人類審核**
- 員工選定最優版本,或在線上編輯器中微調。
- 最終輸出包含:
  - 可直接填入 ImmiAccount 的 150 字純文字(已分段對應各問題)。
  - 內部用「證據備註版」:每個答案旁邊標示所引用的客戶文件段落、支持法條、相似案例。
  - 支持文件檢查清單:根據 GS 答案中提到的證據,自動生成應上傳的文件列表及符合性勾稽。
- 版本保存:每次生成、每次人工修改都記錄為版本,並可追溯是哪個模型、哪個 prompt 版本、哪些參數。

---

## 4. 成功/失敗案例應如何被 AI 使用?各方法比較

| 方法 | 優點 | 缺點 | 建議用途 |
|------|------|------|----------|
| **直接塞 prompt(Few-shot)** | 快速,不需額外架構;模型能模仿語氣與結構 | 量多時 token 爆,失敗案例可能誤導;無法精確匹配當下客戶背景 | 僅用於初期 prototype,提供 2-3 個「完美範例」作為格式與語氣參考 |
| **Vector DB + RAG** | 可動態檢索最相關的成功/失敗片段,保持 prompt 精簡;可擴展 | 需優質的 chunking 策略與 embedding;失敗案例需小心標記避免汙染 | **主要方法**:將每個案例切成「問題-亮點-證據」區塊,失敗案例只檢索「拒簽原因與對應改進」作為風險提示 |
| **分類/標籤 + 結構化案例卡** | 人工或 LLM 預標籤後,檢索準確率高;方便產出統計洞察 | 需前期標註成本;標籤體系需持續維護 | **必要搭配**:用標籤過濾後再做語義檢索,避免檢索到完全不相關案例 |
| **Rubric 評分矩陣** | 將質量標準化,可用來評分生成結果,也可反哺 prompt(告訴模型好答案的維度) | 無法提供具體文字素材 | **作為生成時的自我評價標準與自動打分依據**,不是素材來源 |
| **Fine-tuning** | 可內化公司寫作風格與簽證官偏好,生成品質穩定;無需每次檢索 | 成本高,需大量(數百)去識別化的成功案例;法令變更時需重新訓練;敏感資料風險 | **V2 考慮**:在累積足夠脫敏案例後,微調開源模型(如 Llama)作為「公司專屬撰寫引擎」,但仍需 RAG 提供最新法規 |

**最佳組合(按優先級)**:
1. 將案例轉為結構化卡片 + 向量庫,RAG 檢索。
2. 在 prompt 內附上 Rubric,讓模型自我對標。
3. 僅在優化特定客戶群時嘗試少數 few-shot(背景極相似的 2 個成功案例摘要)。
4. Fine-tuning 當作長期計畫,待資料量與合規審查通過後執行。

**失敗案例的特別處理**:
- 不直接當作正面素材,而是建立「風險雷達」:失敗案例庫中抽出「拒簽理由 → GS 應該避免的敘述」,檢索時若當前客戶呈現相似輪廓(如大齡、倒讀、無足夠資金證明),則在 prompt 中加入「風險提醒:請確保強調XXX,避免出現YYY」,幫助模型避坑。

---

## 5. 最新移民局公告/法令如何自動更新與引用,避免過期與幻覺

**自動更新機制:**
- 用 Crawler (如 Scrapy/Playwright) 每 24 小時監測指定 URL(GS requirement 頁、Document Checklist Tool、Ministerial Direction PDF 發布頁)的變更。若偵測到變更,自動下載並比對新舊版本,產生 diff。
- 將新法令段落進行 embedding,並以版本號與生效日期標記存入向量庫。
- 系統保留「法規生效日期」欄位。生成時,prompt 自動帶入「當前日期」,要求模型僅引用「已生效且未廢止」的條文,並提供引用段落 ID。輸出的引用會在後臺對齊法條版本,若法規已過期,系統在審核階段就標紅警示。

**避免幻覺引用:**
- 所有法令引用必須來自於檢索出的真實段落。prompt 明確指示:「You must only cite regulations provided in the context below. If a claim requires legal support but no relevant clause is found, do not invent one; instead note that supporting regulation is pending verification.」
- 在生成後,規則引擎掃描輸出文字,若發現形如「According to Ministerial Direction XXX」但上下文無對應引用,立刻標記為潛在幻覺,強制顧問確認。
- 建立一個受信任的「法條白名單 JSON」,裡面存放常用條文摘錄,模型只能引用這些白名單內的條文。當白名單更新時,自動通知管理者。

**實務操作建議:**
- 在 MVP 階段先由資深顧問每週手動確認一次法令更新(可拉入 Notion/SharePoint),直接更新知識庫文本。
- V1 才加入自動爬蟲與版本控制。

---

## 6. 資料安全、權限、審計、API、隱私合規風險

客戶資料包含護照、身份證字號、財務證明、家庭成員資訊,屬極度敏感個資。一次性全送入境外 API 會引發以下風險:

**風險分析:**
- 資料出境:OpenAI、Anthropic、Google 等 API 伺服器多位於美國或全球節點,部分非澳洲境內,可能違反澳洲 Privacy Act(尤其 APP 8 跨境傳輸)以及客戶本國法規(如中國個人信息保護法)。
- 資料保留:許多 LLM API 條款中,可能記錄請求用於濫用監控(Anthropic API 目前預設不保留,但需確認合約;OpenAI API 自 2023 年 3 月起不再使用 API 數據訓練,但保留 30 天監控)。若未採用企業版合約,仍有合規缺口。
- 供應商風險:使用多家 API 增加攻擊面,也增加合約審查複雜度。

**解法 – 分層資料處理與合規架構:**
1. **資料脫敏/假名化層(必要)**:在資料進入 LLM prompt 之前,透過本地服務將姓名、護照號、地址、電話、銀行帳號等進行假名化(替換為「Student A」「Passport XXXX123」),並保留映射表在內部安全資料庫。模型從頭到尾拿不到真實識別資訊。
2. **私有環境部署**:敏感核心推理最好使用自架的開源模型(如 Llama 3.1 70B、DeepSeek-V2 等)於澳洲境內雲端(AWS Sydney region)或公司內部伺服器,完全避免資料出境。外部 API 僅用於非敏感任務:如結構化抽取(可先脫敏)、校訂文法、公共法令查詢等。
3. **API 企業合約**:若仍需使用 OpenAI/Anthropic,務必簽署企業級 Data Processing Agreement (DPA),確保 zero data retention,並明定資料處理地點(可要求指定區域節點,例如 Azure OpenAI 澳洲區域)。開通審計日誌。
4. **權限與審計**:
   - 登入系統強制 SSO + MFA,角色區分:顧問(可建案、生成 GS)、審核主管(可批准最終版本)、管理員(可維護知識庫、查看所有審計日誌)。
   - 所有 prompt、回覆、操作(查看、匯出、修改)均記錄於不可竄改的審計表。
   - 客戶資料原始檔(Google Drive)僅允許系統以唯讀服務帳號存取,且不對外暴露。
5. **資料保留與刪除**:在系統中設定自動生命週期:案件提交後 90 天,自動從系統永久刪除客戶個人資料及生成紀錄(或依照法規要求保留簽證顧問記錄,但脫離 AI 平台)。需設計資料清除腳本並經合規確認。

---

## 7. 多模型策略:同時生成完整 GS 還是分工?

**建議採用「平行生成 + 競爭評分」為主,部分分工為輔。**
原因:GS 答案整體性強,每個問題之間互相關聯(如家庭背景與資金、未來規劃與課程),拆開給不同模型寫容易風格割裂、邏輯矛盾。平行生成能保留各模型的「整體人格」,再由評分模型找出最優。

**具體策略:**
- **主要生成**:Claude Sonnet/Opus, OpenAI GPT-4o, Gemini 1.5 Pro, DeepSeek V2 等均收到同樣的完整 prompt,獨立生成整套 GS 答案(每題 150 words)。
- **評判模型**:另一個較便宜且可靠的模型(如 GPT-4o mini 或 Claude Haiku)扮演評審,根據 rubric 對各版本打分並比較,輸出排名與各版優缺點摘要。
- **專才分工(輔助)**:
  - 結構化抽取:用 DeepSeek 或開源模型做,成本低且在固定 JSON 輸出上表現佳。
  - 風險審核:用一個專門 prompt 加載失敗案例知識庫,掃描所有候選 GS,獨立輸出風險評估(移民傾向分數、證據薄弱點),供顧問參考。
  - 語言潤飾:若選定版本後,用 Gemini 等擅長英語的模型進行最終文法與語氣優化(在不改變原意的條件下)。

**是否每個模型都跑?**
- MVP 階段選 2-3 家(如 GPT-4o + Claude Sonnet + DeepSeek)作為對照組即可,避免成本暴增。
- V1 後可根據過往「員工最終採用率」數據,淘汰表現差的模型,加入更強的新模型。

---

## 8. 輸出格式最務實的設計

Home Affairs 官方的偏好與實際狀況:
- 答案必須在線上表格用英文填寫,每題 150 words。
- 支持證據透過 ImmiAccount 上傳,簽證官會對照答案與證據。
- 單獨的「GS Statement」文件不再推薦,但內部仍可作為撰寫草稿與證據對照。

**最佳輸出組合(三位一體):**

1. **ImmiAccount Ready Answers(純文字表格)**
   - 直接生成一份 Markdown 表格或純文字區塊,每個區塊標明對應的線上問題(Current circumstances / Why this course / Value to future / Other info),文字精煉在 140-150 words,已經是最終版本。
   - 顧問可直接複製貼上,零轉換成本。

2. **Evidence-backed Internal Long Note(內部長版備註)**
   - 同一份答案旁附上「證據備註」:例如「資金 AUD 84,964 來源自父親定期存款證明(見證件文件包 p.12)」,這份長版 Note 不提交給移民局,僅供內部審核和存檔。可用折疊方式展示,方便查證。

3. **Supporting Document Checklist(證據上傳清單)**
   - 系統自動從 GS 答案與客戶資料對比,列出應上傳的文件列表:如 COE、資金證明、學歷證書、工作證明、家庭關係證明等,並標註已上傳/缺失狀態。
   - 這份清單可作為內部審核用,也可給學生作為補件通知。

**格式實現:**
- Word 輸出可包含上述三部分,並用分頁區隔,第一頁「Submission Answers 」(簡單清楚),第二頁「Internal Review Notes 」(含證據引用),第三頁「Checklist」。顧問核可後,只取第一頁內容填入 ImmiAccount。

這樣既吻合移民局要求,又保留內部品管所需的一切細節,且不增加員工額外文書工作。

---

## 9. MVP、V1、V2 路線圖與成本/時間/風險

### MVP(1-2 個月)
**目標:驗證 AI 生成 GS 的可用性,取代部分外包**
- 功能:員工手動上傳結構化客戶 JSON(或由一個簡單 Form 填寫)+選擇撰寫方向,後端固定 prompt 調用 Claude 和 GPT-4o 兩個模型,生成兩版 GS 答案(限 150 字)並排顯示,人工複製。
- 知識庫:靜態的「GS撰寫技巧補充文件夾」手動轉為文本嵌入 prompt。
- 不接 Google Drive、不做 OCR、不做多模型評分、不做自動更新法規。
- 安全:資料脫敏規則簡單(正則替換姓名、護照號),使用 API 企業方案並簽 DPA。
- **成本**:開發 1 位全棧工程師 + 0.5 位顧問(理需求)2 個月,約 AUD 30-50K;API 費用每月 <500 澳幣。
- **風險**:品質仰賴人工 JSON 輸入,易出錯;法規未自動更新有過時風險;僅靠兩模型,多樣性不足。

### V1(+3-4 個月)
**目標:端到端半自動化,建立品質門檻**
- 加入:Google Drive 接入 + OCR + 結構化抽取模組;自動生成客戶 JSON。
- 知識庫 RAG:成功/失敗案例向量化;法令頁面手動更新版本化管理。
- 多模型平行生成(4 個模型)+自動評分+風險審核模組(紅黃綠燈標示移民傾向、證據缺失)。
- 輸出三位一體格式;Word 自動匯出。
- 角色權限與基礎審計日誌。
- **成本**:團隊 2-3 人(1 BE, 1 FE, 1 ML engineer)4 個月,雲基礎設施(向量庫、OCR)每月 AUD 1-2K,API 費每月 ~2K。總計約 AUD 100-150K。
- **風險**:OCR 對非英文文件可能錯誤,需人工校正;模型幻覺仍需嚴格 rule 過濾;敏感資料假名化與合規合法性需法務簽署。

### V2(+6 個月以上)
**目標:高度自動化、專屬微調、智能維護與合規聯防**
- 基於累積的脫敏案例 fine-tune 開源 LLM(如 Llama 3),成為公司風格專屬引擎,降低外部 API 依賴與成本。
- 法令自動爬蟲 & 即時更新;失敗案例庫自動聚類產生「拒簽趨勢報告」。
- 智能策略推薦:輸入客戶背景後,系統自動推薦「最佳撰寫策略」(如強調家庭約束力、或強調課程對薪資跳升的影響)。
- 與公司 CRM 整合,自動產出學生的 GS 完成度儀表板、批量處理。
- 全面合規與災難恢復:多地域備份、資料自動過期刪除、滲透測試。
- **成本**:專職 4-5 人團隊,長期投入 200-400K+。風險在於模型持續微調的維護與法規變動追趕,需專責 RA 人員。

---

## 10. 建議的最終架構、資料模型、Prompt 模板、評分 Rubric、人類審核 Checklist

### 最終架構流程(圖像化概念)
```
[Google Drive 文件夾] 
    → (1) File Ingest Service → OCR/Document Parser 
    → (2) Entity Extraction LLM → Customer_JSON
    ↓
(3) RAG Retriever: [法規庫|成功案例庫|失敗案例庫|撰寫技巧庫] → Context_Blob
    ↓
(4) Prompt Composer → (5) Multi-Model Generator (Claude, GPT, DS, Gemini)
    ↓
(6) Output Formatter → (7) Auto-Grader + Risk Scanner → Candidate_Versions
    ↓
(8) Reviewer UI (顧問選版/微調) → (9) Final Exporter (ImmiAccount Answers + Long Note + Checklist)
    ↓
(10) Audit Logger & Version Control
```

### 關鍵資料表 / 資料模型
- `customers`:customer_id, google_drive_folder_id, extracted_json (JSONB), created_at, status
- `customer_documents`:doc_id, customer_id, file_type, ocr_text, parsed_content, source_path
- `knowledge_law`:law_id, title, content_chunk, embedding, effective_date, expiry_date, source_url
- `knowledge_cases`:case_id, type(success/failure), client_profile_tags (JSON), highlights_text, risks_text, embedding, created_at
- `generation_jobs`:job_id, customer_id, prompt_version, models_used, output_versions (JSON), grader_scores (JSON), selected_version, reviewer_id, created_at
- `audit_logs`:log_id, user_id, action, target_type, target_id, details, ip, timestamp

### Prompt 模板策略(核心結構)

**System Prompt(常駐)**
```
You are an Australian migration documentation assistant specializing in GS requirements for Subclass 500. You must produce answers in English, max 150 words per question. Use only information from the provided Customer Profile and Reference Materials. Never invent regulations or personal details. For each answer, internally note the supporting evidence and cite the document source if available. Tone: professional, factual, personal.
```

**User Prompt 組裝模板**
```
[Customer Profile JSON]
{extracted_json}

[Relevant Success Strategies]
{retrieved_success_strategies}

[Relevant Risk Warnings from past refusals]
{retrieved_risk_warnings}

[Applicable Law Excerpts]
{retrieved_law_excerpts}

[Specific Advisor Notes]
{advisor_direction}

Task: Generate genuine student answers for the following ImmiAccount questions:
1. Current circumstances (family, community, employment, economic ties)
2. Why this course and provider / understanding of living & studying in Australia
3. How the course benefits your future
4. Any other relevant information
{optional: previous visa history question}

Output Format:
Question 1: <answer 150 words>
...
```

### 評分 Rubric(Auto-Grader 用)
每個維度 1-5 分,總分加權:
1. **字數合規**:是否在 130-150 words(超過 150 直接扣分)
2. **證據對齊**:答案中的主張是否有對應的客戶證據或法規支持
3. **邏輯一致性**:各題之間是否有矛盾(如資金來源在前後不一致)
4. **風險規避**:是否有不當暗示(如想移民、對課程一無所知、資金不足仍勉強解釋)
5. **語氣真實性**:是否像真實學生口吻,而非模板框架
6. **符合官方要求**:是否清楚表明以學習為主因,並有回國/職涯規劃

### 人類審核 Checklist
- [ ] 每題字數均在 150 words 以下,可順利填入 ImmiAccount
- [ ] 所有關鍵主張(資金、課程名稱、學校名稱、職涯規劃)均可從客戶文件找到直接證據
- [ ] 家庭約束力、經濟狀況與課後規劃彼此吻合,沒有移民傾向暗示
- [ ] 客戶若有拒簽史或複雜簽證史,GS 答案有合理解釋且無矛盾
- [ ] 語氣一致,無明顯 AI 模板感(例:過度使用複雜詞彙、缺乏個人細節)
- [ ] 支持文件清單上的每個項目確實存在於文件包中,且已上傳或預備上傳
- [ ] 未引用過期或錯誤的法規條文(對照知識庫版本)
- [ ] 敏感資訊已在最終提交版本中正確還原真實姓名(從假名映射)且無遺漏
- [ ] 版本紀錄已保存,主管簽核

---

**總結**:方向可行,但必須將「合規輸出格式、證據驅動、資料安全、法令即時更新」嵌入系統核心,配以務實的分層架構(脫敏→RAG→多模型→評分→人審),才能在降低成本同時,做出比人工更可靠、可追溯的 GS 簽證材料。
📊 Token:输入 1650 / 输出 6820(reasoning 640) | 费用:$0.006651 | 耗时:230899ms | finish_reason:stop | 续写:0
Round 1 - Gemini Pro gemini-2.5-pro · 0.02514375 USD

Prompt

你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。

【背景】
我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。

公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。

【預計資料夾/知識來源】
1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。
2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。
3. 成功案例 GS 文件夾:已成功學生 GS。
4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。
目標是讓 AI 能持續參考、持續進步。

【本地範例資料概況】
本地資料夾:C:\Users\F\AiFolder\Projects\SC_AI\GS撰寫技巧補充文件夾
包含:
- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。
- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。
範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。

【官方資料依據,請納入分析】
1. Australian Department of Home Affairs - Genuine Student requirement
來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement
重點:
- GS requirement applies to student visa applications lodged on or after 23 March 2024; before that date assessed under GTE.
- Applicants must be genuine applicants for entry and stay as a student and show understanding that studying in Australia is the primary reason.
- Online form asks: current circumstances including family/community/employment/economic ties; why this course/provider and understanding of course/living in Australia; how the course benefits the applicant; other relevant information; extra question for prior student visa / applying in Australia from non-student visa.
- Home Affairs prefers responses in the application form rather than separate GS statement.
- 150 words per response, all in English.
- Supporting documents in ImmiAccount matter; more weight is given to statements supported by evidence.
- Assessment considers circumstances, immigration history, compliance with visa conditions, course/provider/living knowledge, value of course to future, salary/employment benefit, and other relevant matters.

2. Home Affairs Document Checklist Tool
來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool
重點:
- GS answers must be English and max 150 words per question.
- Supporting documents may include qualifications, transcripts, proof of employment, CV/resume with education/employment history.
- In line with Ministerial Direction 106, factors include circumstances in home country, potential circumstances in Australia, value of course to future, immigration history, other relevant matter; if minor, intentions of parent/legal guardian/spouse.

3. Ministerial Direction No. 106 - Assessing the genuine entry and stay requirements for Student visa and Student Guardian visa applications
來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf
重點:
- Commences 23 March 2024 and applies to Subclass 500 Student visa applications on or after that date.
- Genuine student criterion refers to clause 500.212 of Schedule 2 to the Regulations.
- Decision makers should not use listed factors as a mechanical checklist; they assess circumstances as a whole.
- Further scrutiny may apply where there is migration fraud risk, concerning immigration history, intended course unrelated to previous studies/employment, inconsistencies, applicant holds/held certain visas including student visa/visitor/485 etc.
- Factors include home country circumstances, reasons for not studying similar course locally, family/community/employment ties, economic circumstances, military/civil unrest, knowledge of course/provider/living in Australia, level of research, whether visa is used to maintain residence, value of course to future, consistency with past education/employment, expected remuneration, immigration history, and for minors the intentions of parent/legal guardian/spouse.

【我想問你】
1. 這樣的工具方向合理嗎?哪些部分合理,哪些部分有風險?
2. 如果把所有成功案例、失敗案例、法令資料、客戶資料都給模型,會不會導致 token 越來越大、反而失去焦點?應如何避免?
3. 你會如何設計更好的方案?請具體到架構,例如 Google Drive 文件接入、OCR/文件解析、結構化抽取、RAG、案例檢索、prompt pipeline、多模型生成、評分/審核、Word 輸出、人類審核、版本保存。
4. 成功案例與失敗案例應如何被 AI 使用?是直接塞 prompt、做 vector DB、做分類/標籤、做 rubric、還是 fine-tuning?請比較。
5. 最新移民局公告/法令資料應如何自動更新與引用?如何避免過期法規、幻覺引用、錯誤法規?
6. 因為客戶資料包含護照、身份、財務、家庭等敏感資料,請分析資料安全、權限、審計、供應商 API、資料出境/保留/刪除、隱私合規風險。
7. 多模型策略:Claude/OpenAI/DeepSeek/Gemini/Grok/Minimax 等同時生成是否值得?是否應該每個模型生成完整 GS,還是分工,例如抽取、風險審核、撰寫、評分?
8. 目前澳洲 GS 官方是每題 150 words 且偏好填入表格,而公司卻想輸出完整 GS Word。如何設計輸出格式最務實?是否應包含 150-word ImmiAccount answers + evidence-backed internal long note + supporting document checklist?
9. 請提出 MVP 版本、V1 版本、V2 版本的落地路線圖與大概成本/時間/風險。
10. 請給出你建議的最終架構與流程,並列出關鍵資料表/資料模型、prompt 模板策略、評分 rubric、人類審核 checklist。

請把回答寫得完整,不要短答。請直接給結論、架構、風險、建議與可執行步驟。

AI Reply

【GEMINI-PRO · gemini-2.5-pro】
好的,收到您的需求。這是一個非常典型且極具價值的企業級 AI 應用場景。身為資深 AI 產品架構師與 RAG/LLM 系統顧問,我將以可落地的企業內部工具設計為核心,為您提供一份完整、具體的分析與規劃。

---

### **總體評估與結論**

您的方向非常正確且具備高度可行性。將重複性高、依賴專家知識、且有大量參考案例的工作,透過 RAG 結合多模型生成來自動化,是 LLM 在企業落地的最佳實踐之一。這不僅能大幅降低單件成本(從 AUD 100-200 降至幾塊錢的 API call 成本),更能標準化產出品質、提升效率,並將專家的時間釋放出來,專注於最棘手的案件審核與策略制定。

以下我將逐一回答您的問題。

---

### **1. 工具方向的合理性與風險分析**

#### **合理之處:**
1.  **高價值目標:** GS 撰寫是簽證申請的核心環節,直接影響成功率。自動化此流程能帶來顯著的商業價值。
2.  **數據基礎良好:** 您已擁有成功/失敗案例、客戶資料、撰寫技巧等結構化與非結構化的知識資產,這是建構高效 RAG 系統的完美起點。
3.  **技術成熟度:** 目前的 LLM(尤其是 Claude 3.5 Sonnet/Opus, GPT-4o)在長文理解、遵循指令、專業寫作方面表現出色,足以應對 GS 撰寫的複雜性。
4.  **多模型策略:** 採用多模型並行生成,再由人工挑選,是一種聰明的「集成學習」(Ensemble Learning) 策略。它能有效規避單一模型的短板與偶然的失誤,最大化產出品質。

#### **主要風險:**
1.  **資料安全與隱私(最高風險):** 客戶資料極度敏感,包含護照、財務等 PII (Personally Identifiable Information)。API 傳輸、資料庫儲存、權限控管、供應商的資料政策都必須符合澳洲《隱私法》(Privacy Act 1988),這是系統成敗的關鍵紅線。
2.  **事實幻覺 (Hallucination):** AI 可能會「創造」不存在的事實,例如編造一個不符合學生背景的職涯規劃,或引用過時的法規。這需要嚴謹的 RAG 與人類審核機制來把關。
3.  **過度依賴與品質下降:** 員工可能因工具太好用而變得疏於審查,導致細微但致命的錯誤被忽略。長遠來看,若沒有持續的專家反饋,系統的知識庫可能會逐漸僵化。
4.  **維護成本:** RAG 系統並非一勞永逸。知識庫需要持續更新,模型需要迭代,prompt 需要優化。這需要投入持續的技術與人力資源。

---

### **2. 如何避免 Token 越來越大、失去焦點?**

您的擔憂非常到位。直接將所有資料塞入 Prompt 是不可行的,不僅會超過 context window 限制,成本高昂,且會因資訊過多而干擾模型的專注力。

**正確的解決方案是:檢索增強生成 (Retrieval-Augmented Generation, RAG)。**

RAG 的核心思想是「開卷考試」,而不是讓模型「背下所有書」。流程如下:
1.  **離線建立索引 (Indexing):** 將您所有的知識文件(成功/失敗案例、法規、技巧)進行預處理:
    *   **分塊 (Chunking):** 將長文件切成有意義的小段落(例如,按 GS 問題分段、按法規條款分段)。
    *   **向量化 (Embedding):** 使用 embedding model (如 OpenAI's `text-embedding-3-large`) 將每個文本塊轉換為數學向量。
    *   **存入向量資料庫 (Vector Database):** 將文本塊與其向量存儲在 Pinecone, Weaviate, ChromaDB 等專業資料庫中。同時儲存重要的**元數據 (Metadata)**,如:`case_id`, `outcome: success/fail`, `rejection_reason`, `student_profile_tags: [IT_to_cookery, high_risk_country]`, `source_document`, `date_updated`。
2.  **線上即時檢索 (Retrieval):** 當一個新學生的案件進來時:
    *   **分析學生概況:** 從學生的結構化資料(如 Form 500)中提取關鍵詞和語義,如「中國學生」、「IT 背景轉讀廚藝」、「資金來源為父母贈與」。
    *   **生成查詢:** 將學生概況轉化為對向量資料庫的查詢。
    *   **混合搜索:** 執行向量語義搜索(找到意義最相近的案例)+ 關鍵詞過濾(利用元數據,例如 `outcome: success` AND `student_profile_tags: IT_to_cookery`)。
    *   **獲取上下文:** 系統只檢索出最相關的 3-5 個成功案例片段、1-2 個相關的失敗案例警示、以及最新的相關法規。
3.  **增強生成 (Augmented Generation):**
    *   將**少量、高相關性**的檢索結果,連同學生的個人資料,一起注入到一個精心設計的 Prompt 模板中。
    *   將這個 context-rich 的 prompt 發送給 LLM 進行生成。

**結論:** RAG 確保了每次調用 LLM 時,提供的上下文都是針對當前學生「量身定做」的,完美解決了 Token 爆炸和失焦的問題。

---

### **3. 系統架構設計方案**

這是一個企業級的 RAG 系統,以下是具體架構:

  *(這是一個概念圖,請想像一下)*

**流程與組件:**

1.  **數據接入層 (Data Ingestion):**
    *   **觸發器:** 使用 Google Drive API Webhook 或定時輪詢,監控指定的「待處理」文件夾。當新學生文件夾被創建(或標記為 ready)時,觸發流程。
    *   **文件解析器 (File Parser):**
        *   **OCR 服務:** 對於 `.pdf`, `.jpg`, `.png` 掃描件(如護照、成績單),調用 Google Cloud Vision API 或 AWS Textract 進行光學字符識別,轉換為文本。
        *   **文檔解析器:** 對於 `.docx`, `.txt` 文件,直接提取文本。
2.  **數據預處理與結構化 (Preprocessing & Structuring):**
    *   **實體抽取 (Entity Extraction):** 使用一個小而快的 LLM(如 GPT-4o 或 Claude 3.5 Sonnet)或傳統 NLP 模型,從解析出的文本中抽取關鍵信息(姓名、生日、學校、課程、資金數額等),並將其結構化為一個 `StudentProfile.json` 對象。這比讓主生成模型自己從一堆文本裡找信息更可靠。
3.  **知識庫與 RAG 核心 (Knowledge Base & RAG Core):**
    *   **向量資料庫 (Vector DB):** 如前述,存放所有案例與法規的向量。推薦使用帶有元數據過濾功能的雲端服務,如 Pinecone 或 Weaviate。
    *   **檢索器 (Retriever):** 接收 `StudentProfile.json`,生成查詢,從 Vector DB 中執行混合搜索,返回最相關的上下文片段。
4.  **多模型生成層 (Multi-Model Generation):**
    *   **Prompt Pipeline Orchestrator:**
        *   載入預設的 Master Prompt Template。
        *   將 `StudentProfile.json` 和檢索器返回的上下文(相關案例、法規)填入模板。
        *   並行(asynchronously)向多個 LLM API (OpenAI, Anthropic, Google, DeepSeek) 發送請求。
5.  **輸出與審核層 (Output & Review):**
    *   **結果整合器 (Result Aggregator):** 收集所有模型的生成結果。
    *   **評分與標記 (Scoring & Flagging):** 可設計一個評分模型(或用強大的 LLM 如 GPT-4o 做評估),根據預設的 Rubric(見第 10 點)對各版本進行初步評分,並標記出潛在風險(如語氣不當、事實不一致)。
    *   **輸出生成器 (Output Generator):** 將多個版本格式化,生成一個包含並排比較、評分、批註的 Word 文件 (`.docx`)。
    *   **人工審核界面 (Human-in-the-Loop UI):** 一個簡單的 Web 界面,讓員工可以查看、比較、編輯、選擇最終版本,並點擊「批准」。
6.  **反饋與閉環 (Feedback Loop):**
    *   **版本控制:** 保存所有生成版本、最終批准版本以及簽證結果(成功/失敗)。
    *   **知識庫更新:** 批准的成功案例,經過 PII 脫敏處理後,自動進入知識庫的索引更新流程。失敗案例連同拒簽信(需人工標註拒簽原因)也一併加入,成為未來檢索的寶貴資料。

---

### **4. 成功與失敗案例的使用方式比較**

| 方法 | 優點 | 缺點 | 適用場景 | 結論 |
| :--- | :--- | :--- | :--- | :--- |
| **直接塞 Prompt** | 簡單,無需額外架構 | Token 限制、成本高、無法擴展、信息噪音大 | 快速原型驗證,不適用於生產系統 | **不推薦** |
| **Vector DB (RAG)** | **可擴展、成本效益高、內容可更新、具備可解釋性(知道引用了哪些案例)** | 需要建立和維護索引,檢索質量依賴於分塊和 embedding 策略 | **核心推薦方案。** 最適合這種基於大量知識的生成任務 | **最佳選擇** |
| **分類/標籤** | 增強檢索精度 | 需要人工或 AI 進行標註,工作量大 | 作為 Vector DB 元數據的一部分,實現精準過濾 | **強烈推薦**,與 RAG 結合使用 |
| **Fine-tuning** | 能讓模型學會特定的寫作**風格、語氣和格式** | 成本極高、需要上千個高質量樣本、容易「忘記」通用知識、無法動態增加新知識 | 當你想讓模型模仿你公司獨特的、難以用 prompt 描述的「腔調」時 | **不建議作為首選**。RAG 解決知識問題,Prompt 解決風格問題。Fine-tuning 是最後的、高成本的優化手段。 |

**最佳實踐:** 使用 **RAG 結合元數據標籤**。為每個案例打上詳細標籤,例如:
*   `student_origin: China`
*   `education_gap: 2_years`
*   `course_change: business_to_IT`
*   `financial_source: self_funded`
*   `outcome: success`
*   `rejection_reason: lack_of_financial_proof` (來自拒簽信)

這樣,RAG 系統就能進行極其精準的檢索,比如:「為一位有 2 年空窗期、從商科轉 IT 的中國學生,查找成功的 GS 案例,並參考因資金證明不足而失敗的案例以規避風險。」

---

### **5. 最新移民局公告/法令資料的自動更新與引用策略**

1.  **自動監控與抓取:**
    *   建立一個定時任務(如每日執行的 Python 腳本),使用 `BeautifulSoup` 或 `Scrapy` 框架,監控以下關鍵頁面:
        *   Genuine Student requirement 頁面
        *   Ministerial Directions 列表頁面
        *   移民局新聞/公告頁面
    *   計算頁面內容的哈希值 (hash),一旦哈希值變化,就意味著頁面有更新。
2.  **內容處理與驗證:**
    *   觸發更新後,抓取新內容,並與舊版本進行比對(`diff`),高亮顯示變更部分。
    *   將變更內容發送到一個專門的 Slack/Teams 頻道,並 **@ 指定的法規專家/資深顧問進行人工審核**。這一步絕對不能省略,AI 無法完全理解法規變更的深層含義。
3.  **打標與索引:**
    *   專家確認後,為新法規內容打上元數據標籤,如 `effective_date: 2024-03-23`, `document_type: ministerial_direction`, `version: 106`。
    *   將新內容分塊、向量化,並加入到 Vector DB 中。同時,將舊的、過時的法規標記為 `is_archived: true`,在檢索時過濾掉它們。
4.  **避免幻覺引用:**
    *   **在 Prompt 中強制要求引用來源:** 指示 LLM 在生成內容時,如果引用了某個法規或案例,必須在內部註釋中標明來源 `[Source: Ministerial Direction 106, Section 2.1]`。
    *   **事實校驗層 (Fact-checking Layer):** 在生成後,可以額外調用一次 LLM,讓它檢查生成內容中的法規陳述是否與檢索到的原文上下文一致。

---

### **6. 資料安全與隱私合規風險分析**

這是本項目最高優先級的事項。
1.  **供應商選擇與配置:**
    *   **API 提供商:** 必須選擇提供 **"Zero Data Retention"** 政策的企業級 API,如 OpenAI (透過 API)、Microsoft Azure OpenAI Service、Anthropic。這意味著他們不會使用你的客戶數據進行模型訓練。**絕對禁止使用消費者版的 ChatGPT Web 界面。**
    *   **雲端平台:** 優先選擇在澳洲有數據中心的雲服務商(AWS, Google Cloud, Azure),並在配置中指定數據存儲在澳洲境內。
2.  **數據處理流程中的安全措施:**
    *   **數據脫敏 (PII Anonymization):** 在將成功/失敗案例存入通用知識庫(Vector DB)之前,必須進行嚴格的 PII 脫敏處理。用腳本替換掉姓名、生日、護照號、地址、具體金額等,代之以 `[APPLICANT_NAME]`, `[DATE_OF_BIRTH]`, `[PASSPORT_NUMBER]` 等佔位符。
    *   **權限控制 (Access Control):** 實施「最小權限原則」。員工只能通過公司賬號登錄系統,且只能訪問被分配給自己的學生案件。嚴格禁止數據的隨意下載。
    *   **加密:** 所有數據在傳輸過程中(TLS 1.2+)和靜態存儲時(AES-256)都必須加密。
    *   **審計日誌 (Audit Trail):** 記錄每一次數據訪問、每一次 GS 生成、每一次修改和批准的操作。日誌應包含操作人、時間、操作對象(學生 ID)、IP 地址。
3.  **合規性:**
    *   **資料保留與刪除:** 制定明確的數據保留政策。簽證流程結束後,應在規定期限內(例如 7 年)安全歸檔,過期後應徹底刪除。需提供可供客戶請求刪除其個人資料的機制。
    *   **隱私政策:** 更新公司的隱私政策,告知客戶其資料可能會被用於內部 AI 系統以提升服務質量的目的,並確保獲得客戶的同意 (consent)。

---

### **7. 多模型策略的價值與分工**

同時生成是值得的,但可以更進一步。

*   **策略一:並行生成 (Ensemble) - 適用於 V1**
    *   **做法:** 將同一個 final prompt 發給 Claude, OpenAI, Gemini, DeepSeek。
    *   **優點:** 簡單直接。不同模型有不同的「個性」——Claude 擅長連貫的長篇敘事,GPT-4o 邏輯嚴謹,Gemini 可能會有創新的角度。這提供了一個風格和內容的「自助餐」,讓顧問選擇最接近完美的一份來修改。
    *   **成本:** 成本是單一模型的 N 倍,但考慮到 GS 的高價值,這點 API 費用是值得的。

*   **策略二:任務分工 (Agentic Workflow) - 適用於 V2**
    *   **做法:** 將流程拆解,不同環節使用最適合的模型。
        *   **數據抽取:** GPT-4o 或 Claude 3.5 Sonnet (速度快,結構化輸出能力強)。
        *   **風險識別:** Claude 3 Opus (強大的推理能力),根據失敗案例庫,識別學生檔案中的潛在風險點並輸出警告。
        *   **草稿撰寫 (長文):** Claude 3 Opus (寫作質量高)。
        *   **精煉摘要 (150-word answers):** GPT-4o (遵循指令和字數限制能力強)。
        *   **最終評審:** GPT-4o 作為 "AI 審稿人",檢查一致性、語法和合規性。
    *   **優點:** 充分利用各模型優勢,可能得到更高質量的綜合輸出,且總體成本可能更低。
    *   **缺點:** 架構複雜度大增,需要工作流編排引擎 (Orchestration Engine)。

**建議:** 從**並行生成**開始,在 V2 版本再考慮引入**任務分工**。

---

### **8. 輸出格式的務實設計**

您的觀察很敏銳。官方要求簡潔,但內部需要詳盡的論述來支撐。因此,輸出格式應該是一個**為內部顧問服務、同時兼容外部提交需求**的綜合性文件。

**建議的 Word (`.docx`) 輸出結構:**

*   **第一部分:提交材料 (For Submission)**
    *   **GS 問題回答區:**
        *   清晰列出移民局表格上的每一個 GS 問題。
        *   下方是 AI 生成的、嚴格遵守 **150 詞限制**的英文回答。這部分可以直接複製粘貼到 ImmiAccount。
*   **第二部分:內部工作底稿 (Internal Use Only)**
    *   **詳細論述 (Detailed Narrative):**
        *   這是完整的、不受字數限制的 GS Statement。它將學生的背景、動機、課程關聯性、未來規劃等所有細節串聯成一個有說服力的故事。150 詞的回答是從這部分精煉而來的。
    *   **證據鏈分析 (Evidence Linkage):**
        *   AI 分析每一條論點,並指出它由哪些支撐文件證明。
        *   例如:
            *   `Claim: Applicant has sufficient funds (AUD 84,964).` -> `Supporting Document: [Bank_Statement_2024.pdf], [Parents_Financial_Support_Letter.pdf]`
            *   `Claim: Strong ties to home country.` -> `Supporting Document: [Family_Hukou_Book.pdf], [Parents_Employment_Certificate.pdf], [Property_Ownership_Deed.pdf]`
*   **第三部分:行動清單 (Action Checklist)**
    *   **推薦補充文件列表:** 根據分析,AI 建議還需要客戶補充哪些文件來增強說服力。
    *   **風險提示:** 列出此案件的潛在風險點(例如,較長的學習空白期、課程轉換跨度大)以及應對策略建議。

這種格式既高效(可直接複製)又專業(提供詳盡的背景和策略),極大賦能了顧問。

---

### **9. 落地路線圖 (Roadmap)**

| 版本 | 預計時間 | 預計成本 (粗估) | 核心功能 | 主要風險 |
| :--- | :--- | :--- | :--- | :--- |
| **MVP (最小可行產品)** | 1-2 個月 | 開發:1-2人月<br>API:低 | - 手動上傳學生資料(單個文件夾)<br>- 後端腳本處理,無 UI<br>- RAG 基於 20 個精選成功案例<br>- 調用單一模型 (e.g., GPT-4o) 生成<br>- 輸出為單一 `.txt` 文件 | 生成質量不穩定,流程不順暢,無法處理多樣化案例 |
| **V1 (內部可用版)** | 3-6 個月 | 開發:3-5人月<br>API/雲服務:$500-$1k/月 | - Google Drive API 接入<br>- OCR 處理掃描件<br>- 結構化數據抽取<br>- 擴充 RAG 知識庫 (100+ 案例)<br>- **多模型並行生成**<br>- 生成**結構化的 Word 文件** (如 Q8 所述)<br>- 簡單的 Web 審核界面 | 資料安全措施需到位,UI/UX 需要打磨,成本控制 |
| **V2 (成熟平台版)** | 6-12 個月 | 開發:6-10人月<br>API/雲服務:$1k-$3k+/月 | - 完整的**反饋閉環**,自動更新知識庫<br>- 法規**自動監控**與審核工作流<br>- **PII 自動脫敏**<br>- 儀表板與分析功能 (成功率、模型表現等)<br>- **高級 RAG 策略** (元數據過濾、混合搜索)<br>- 完善的權限與審計系統 | 技術複雜度高,長期維護成本,需要專職團隊 |

---

### **10. 最終架構、資料模型、Prompt 與 Checklist**

#### **最終架構圖 (概念)**
`[Google Drive] -> [Ingestion Service (OCR/Parser)] -> [Structured Data (JSON)] -> [RAG Retriever] -> [Prompt Orchestrator] -> [Multi-LLM APIs] -> [Output Aggregator] -> [Review UI] -> [Final DOCX] -> [Feedback Loop to Vector DB]`

#### **關鍵資料模型 (Data Models)**
*   **StudentProfile (JSON):**
    ```json
    {
      "student_id": "S12345",
      "personal_info": { "name": "...", "dob": "...", "nationality": "..." },
      "education_history": [ { "degree": "...", "school": "...", "year": "..." } ],
      "employment_history": [ { "role": "...", "company": "...", "duration": "..." } ],
      "chosen_course": { "name": "...", "provider": "Navitas", "level": "..." },
      "financial_summary": { "total_funds": 84964, "source": "parental_support" },
      "family_ties": { "in_home_country": [...], "in_australia": [...] },
      "raw_documents": { "form_500_text": "...", "cv_text": "..." }
    }
    ```
*   **KnowledgeChunk (in Vector DB):**
    *   **Content:** "段落文本..."
    *   **Vector:** `[0.123, 0.456, ...]`
    *   **Metadata:**
        ```json
        {
          "doc_id": "case_chuhan_wu",
          "doc_type": "success_case",
          "source_file": "Chuhan WU-GS.pdf",
          "tags": ["english_course", "career_change_cosmetics"],
          "outcome": "success",
          "date_added": "2024-05-20"
        }
        ```

#### **Prompt 模板策略 (Master Prompt Template)**

這是一個簡化版,實際會更複雜:
```text
# ROLE:
You are an expert Australian migration consultant specializing in Student Visa Subclass 500 applications. Your goal is to write a compelling and evidence-based Genuine Student (GS) statement. You must adhere strictly to the information provided and Australian migration law.

# CONTEXT:
## Student Profile (JSON):
{{student_profile_json}}

## Relevant Successful Case Excerpts (for style and structure):
{{retrieved_success_cases}}

## Relevant Failure Case Warnings (to avoid pitfalls):
{{retrieved_failure_cases}}

## Applicable Regulations (for legal basis):
{{retrieved_regulations}}

# TASK:
Based on all the provided context, write the Genuine Student statement for the applicant. The output MUST be a JSON object with two main keys: "immi_account_answers" and "internal_narrative".

## INSTRUCTIONS for "immi_account_answers":
1.  Address the following official GS questions.
2.  Each answer MUST be in English and strictly under 150 words.
3.  The tone should be formal, direct, and factual.
4.  The questions are:
    *   Q1: Give details of the applicant's current circumstances...
    *   Q2: Explain why the applicant wishes to study this course in Australia...
    *   ... (and so on)

## INSTRUCTIONS for "internal_narrative":
1.  Write a comprehensive, detailed narrative that connects all aspects of the student's profile into a cohesive story.
2.  This narrative is the foundation for the 150-word answers.
3.  Structure the narrative by the GS themes: circumstances, course choice, future value, etc.
4.  Integrate evidence from the student's documents seamlessly.

# OUTPUT FORMAT (Strictly JSON):
{
  "immi_account_answers": {
    "q1_current_circumstances": "...",
    "q2_course_choice": "...",
    "q3_course_value": "..."
  },
  "internal_narrative": "..."
}
```

#### **評分 Rubric (for AI/Human Assessor)**
*   **Clarity & Cohesion (1-5):** 論述是否清晰,邏輯是否連貫?
*   **Persuasiveness (1-5):** 理由是否充分,是否能打動簽證官?
*   **Evidence-based (1-5):** 每個論點是否都有對應的文件證據支撐?
*   **Compliance (Pass/Fail):** 是否符合 GS 要求,字數限制是否遵守?
*   **Risk Mitigation (1-5):** 是否有效回應了檔案中的潛在弱點?

#### **人類審核 Checklist (for Consultant)**
1.  **事實核對:** 所有姓名、日期、金額、學校名稱是否與原始文件 100% 一致?
2.  **一致性檢查:** 不同問題的回答之間是否存在矛盾?
3.  **語氣與情感:** 語氣是否真誠、積極,符合一個真實學生的口吻?
4.  **“澳洲中心”思想:** 是否過分強調移民傾向,還是清晰地表明學習是主要目的?
5.  **文件鏈完整性:** AI 建議的支撐文件列表是否完整?是否需要補充?
6.  **最終潤色:** 進行最後的語法、拼寫和風格潤色,使其更具個人色彩。

希望這份詳盡的規劃能為貴公司的 AI 工具建設提供一個堅實的藍圖。這是一個極具潛力的項目,祝您成功。
📊 Token:输入 2387 / 输出 2216 | 费用:$0.025144 | 耗时:93900ms | finish_reason:stop | 续写:0
Round 1 - Grok grok-4.3 · 0.0054175 USD

Prompt

你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。

【背景】
我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。

公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。

【預計資料夾/知識來源】
1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。
2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。
3. 成功案例 GS 文件夾:已成功學生 GS。
4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。
目標是讓 AI 能持續參考、持續進步。

【本地範例資料概況】
本地資料夾:C:\Users\F\AiFolder\Projects\SC_AI\GS撰寫技巧補充文件夾
包含:
- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。
- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。
範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。

【官方資料依據,請納入分析】
1. Australian Department of Home Affairs - Genuine Student requirement
來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement
重點:GS applies on/after 23 Mar 2024; GTE before then;online form asks current circumstances, course/provider reason and understanding, benefit, other information, extra question for prior student visa/applying in Australia from non-student visa;Home Affairs prefers form responses rather than separate GS statement;150 words per response;English only;supporting docs matter and evidence-supported statements get more weight。
2. Home Affairs Document Checklist Tool
來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool
重點:GS answers max 150 words per question;supporting docs can include qualifications/transcripts/employment/CV;Direction 106 factors: home country circumstances, potential circumstances in Australia, value of course, immigration history, other relevant matters, minor's parent/legal guardian/spouse intentions。
3. Ministerial Direction No. 106
來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf
重點:commences 23 Mar 2024;applies to Subclass 500;decision makers should not use factors as a mechanical checklist;further scrutiny for fraud risk, concerning immigration history, unrelated course, inconsistencies, prior/held visas;factors include home country circumstances, reasons not studying locally, ties, economic circumstances, knowledge of course/provider/living, research, value to future, consistency with past education/employment, remuneration, immigration history, minor intentions。

【問題】
請分析:工具方向是否合理;token 是否會越來越大並失焦;更好的架構;成功/失敗案例如何用;法令資料自動更新與引用;資料安全與供應商風險;多模型策略;官方 150-word GS 與 Word 完整稿的輸出取捨;MVP/V1/V2 路線圖;最終架構、資料模型、prompt 策略、評分 rubric、人類審核 checklist。

請完整回答,不要短答。

AI Reply

【GROK · grok-4.3】
**內部 GS 自動化工具架構建議(企業落地版)**

以下分析完全從「可實際落地、控制成本與風險」的角度出發,針對你描述的澳洲留學公司內部工具需求進行完整設計。

### 1. 工具方向是否合理

**合理,但需大幅調整輸出目標。**

目前官方明確偏好「線上表格直接填寫」(每題 ≤150 字),而非獨立長篇 GS Statement。因此工具的核心輸出應是:
- **主要輸出**:線上表格 5–6 題的精準 150 字以內回答(可直接複製貼上)
- **次要輸出**:一份結構化 Word(供員工內部參考或少數仍需上傳的情況)

若仍以「生成完整 Word」為主要目標,會產生兩大問題:(1)容易被移民官視為模板化;(2)token 消耗與失焦風險極高。

### 2. Token 膨脹與失焦風險(核心問題)

若直接把整個學生資料夾 + 所有成功/失敗案例塞進單一 prompt,很快就會遇到以下問題:
- Context window 被大量無關文件佔據
- 模型開始「平均化」寫作風格,失去個案針對性
- 成本快速上升

**解決方案**:採用**分層 RAG + Agent 架構**,而非單一長 prompt。

### 3. 推薦架構(企業內部實用版)

**核心設計原則**:資料永不直接全量塞 prompt,只傳「經過篩選與摘要後的相關片段」。

**建議技術架構**:
- **向量資料庫**:Pinecone / Weaviate / PGVector(建議用支援 metadata filtering 的)
- **文件處理層**:所有上傳文件先做結構化解析 + metadata 標註
- **Agent 流程**(用 LangGraph 或 AutoGen 實作):
  1. **Document Intelligence Agent**:讀取學生資料夾,提取結構化資訊(教育背景、家庭、資金、課程等)
  2. **Evidence Mapping Agent**:將每項事實對應到 Direction 106 的 factor
  3. **Retrieval Agent**:依據 factor 精準檢索相關成功/失敗案例與法規
  4. **Generation Agent**:分段生成(每段獨立生成後再組裝)
  5. **Consistency & Risk Agent**:檢查前後矛盾、移民風險點

### 4. 成功/失敗案例的使用方式

不要把案例當「範本」直接學習,而要當「對照組」使用:

- **成功案例**:標註「此做法被接受的原因」(metadata 記錄)
- **失敗案例**:標註「被拒原因 + 拒簽信關鍵字」(例如 course 不相關、資金來源不清、回國意願薄弱)
- 檢索時加入 **Negative Example Retrieval**:讓模型同時看到「什麼寫法會被拒」

建議在 metadata 中加入欄位:
`case_outcome: accepted | refused`
`risk_factors: ["course unrelated", "weak home ties", "funds source unclear"]`
`key_success_factors: ["strong career linkage", "clear home country economic tie"]`

### 5. 法令資料自動更新與引用

建立一個獨立的「Regulation Knowledge Base」:
- 每週自動抓取 Home Affairs 公告、Direction 更新
- 對每份文件做版本控制與生效日期標註
- 生成時強制要求模型引用具體 Direction 106 條款(如 "Direction 106, paragraph 9(b)")

### 6. 資料安全與供應商風險

- **高風險做法**:直接把學生護照、成績單、銀行流水丟給 OpenAI/Claude API
- **建議做法**:
  - 先在本地做 PII 遮罩或結構化抽取,只傳「已脫敏後的結構化 JSON」
  - 關鍵模型改用 Azure OpenAI(企業合約)或本地部署的模型(DeepSeek / Qwen / Llama 405B)
  - 所有輸入輸出記錄做版本控制與審計日誌

### 7. 多模型策略

建議採 **Model Routing** 而非全部模型都跑一次:

| 任務階段           | 推薦模型          | 理由                     |
|--------------------|-------------------|--------------------------|
| 文件解析與結構化   | Claude 3.5 / GPT-4o | 長文件理解能力強         |
| 風險分析與矛盾檢查 | Claude 3.5        | 嚴謹度較高               |
| 最終生成(表格回答)| GPT-4o / DeepSeek | 性價比與輸出穩定性       |
| 創意/說服力優化    | Claude 3.5        | 寫作質量較佳             |

### 8. 150 字表格回答 vs Word 完整稿

**V1 版本強烈建議以「表格回答」為主輸出**,Word 作為輔助。

表格回答的 prompt 需加入強制約束:
- 每題嚴格控制在 140–148 字
- 每句必須有文件佐證
- 禁止使用模板句型

### 9. MVP / V1 / V2 路線圖

**MVP(2–3 週)**:
- 單一模型(Claude 3.5)
- 手動上傳結構化 Excel/JSON
- 只生成 5 題表格回答
- 人工比對功能

**V1(2–3 個月)**:
- 接入 Google Drive 連結自動讀取
- 建立向量資料庫 + 基本 RAG
- 支援成功/失敗案例檢索
- 加入簡單一致性檢查

**V2(4–6 個月)**:
- 多 Agent 架構
- 自動抓取法規更新
- 風險評分系統
- 版本管理與 A/B 測試功能

### 10. 最終建議:Prompt 策略 + 評分 Rubric + 人類審核 Checklist

**Prompt 核心結構**(建議每段都使用):
```
Role + Task + Direction 106 相關 factor + Evidence Mapping + Output Constraint + Self-critique
```

**GS 回答評分 Rubric**(建議做成內部評分表):
1. Direction 106 因素覆蓋完整度(25%)
2. 每項主張是否有文件佐證(25%)
3. 與學生真實背景一致性(20%)
4. 移民風險點規避程度(15%)
5. 語言自然度與非模板化(15%)

**人類審核 Checklist**(建議做成 Notion 或內部表單):
- [ ] 所有主張都有對應文件
- [ ] 無明顯自相矛盾
- [ ] 課程與未來規劃連結合理
- [ ] 回國因素足夠具體
- [ ] 資金來源說明清晰
- [ ] 每題字數符合要求

需要我再針對「表格回答」的單題 Prompt 模板、或資料夾的 metadata schema 做更細部的設計嗎?
📊 Token:输入 1168 / 输出 1583(reasoning 488) | 费用:$0.005417 | 耗时:38130ms | finish_reason:stop | 续写:0
Round 1 - MiniMax M2.7 highspeed MiniMax-M2.7-highspeed · 0.0204516 USD

Prompt

請用繁體中文完整分析:澳洲留學公司想做內部 AI 工具,讀取 Google Drive 學生文件夾、Form500、證件、照片、成功/失敗 GS 案例、拒簽信、最新 Home Affairs/Direction 106 法規資料,調用多模型生成澳洲 Student visa Subclass 500 的 Genuine Student (GS) 內容。官方重點:GS 取代 GTE,適用 2024-03-23 起申請;ImmiAccount 表格每題 150 words、英文;官方偏好表格回答而非單獨 GS statement;證據支持的陳述權重更高;Direction 106 看整體情況、home country circumstances、potential circumstances in Australia、course value、immigration history、minor parent/legal guardian intentions、unrelated course/inconsistency/visa history 會觸發 scrutiny。請回答:方向是否合理、token/RAG 如何避免失焦、Google Drive/OCR/結構化抽取/RAG/多模型生成/審核/Word輸出/版本保存架構、成功失敗案例如何用、法規如何自動更新與引用、資料安全與 API 供應商風險、多模型是否值得、輸出是否應改成 150-word answers + internal long note + evidence checklist、MVP/V1/V2 路線圖、資料模型、prompt 策略、評分 rubric、人類審核 checklist。

AI Reply

【MINIMAX-M2.7-HIGHSPEED · MiniMax-M2.7-highspeed】
# 澳洲留學公司內部 AI 工具  
**目標:自動生成 Subclass 500 「真正學生」(Genuine Student, GS) 回覆內容**  
> 以下內容全部以**繁體中文**呈現,架構、資料模型、Prompt 策略、評估標準與人類審核清單均已完整說明。  

---

## 1️⃣ 方向是否合理?

| 評估維度 | 結論 | 說明 |
|----------|------|------|
| **官方要求匹配** | ✅ 合理 | GS 取代 GTE (2024‑03‑23) 後,ImmiAccount 中每題限 150 words,且官方偏好**表格回覆**(非獨立 GS Statement)。本工具正是針對此格式與內容需求設計。 |
| **證據導向** | ✅ 合理 | Direction 106 強調「證據支持的陳述」權重較高,工具可自動對照文件庫(護照、學歷、資金證明等)產出 Evidence Checklist。 |
| **自動化風險** | ⚠️ 需控制 | AI 生成內容屬「輔助」而非「移民建議」;需人類審核與最終把關,避免錯誤資訊外流。 |
| **多模型/ RAG** | ✅ 值得探索(中期) | 初期 MVP 可用單一強模型(GPT‑4o),之後加入 RAG 與多模型分工,可提升事實依據與合規性。 |
| **法規自動更新** | ✅ 可行 | 透過每日爬蟲 + 版本化儲存,可把最新 Direction 106、Policy‑Manual 等注入 RAG,保持內容最新。 |

**結論**:方向與官方需求高度契合,技術上可行,但必須在 **安全、合規與人類審核** 上設置嚴格閘門。

---

## 2️⃣ Token / RAG 如何避免失焦(Off‑Topic)

### 2.1 Token 預算分配(每題 150 words ≈ 225 tokens)

| 組成 | 建議 Token 上限 | 說明 |
|------|----------------|------|
| System Prompt (背景、指令) | 600 | 包含 Direction 106 重點、輸出格式要求、證據清單樣式。 |
| User Prompt (學生資料 + 查詢) | 400 | 姓名、護照、課程、財務、家庭等關鍵欄位。 |
| Retrieved Context (RAG) | 500–800 | Top‑3~5 法規段落 / 成功案例段落,確保高度相關。 |
| Answer Output (150 words) | 250 | 英語答案本體(直接寫入 ImmiAccount)。 |
| Internal Note + Checklist | 300 | 內部備註與證據對照表。 |
| **合計** | **≈ 2 k** | 大多數模型單次回話上限(8 k–32 k)均足夠。 |

### 2.2 失焦防範策略

| 技術/方法 | 目的 | 具體做法 |
|-----------|------|----------|
| **Query Decomposition** | 把大問題拆成子問題,只取最相關片段。 | 使用「GS Question → Sub‑Q1, Sub‑Q2」指令;每子問題僅檢索對應法規/案例。 |
| **Hybrid Search** | 關鍵字 + 語意向量,兼顧精確與語意相關。 | Elasticsearch/Weaviate 同時支援 BM25 + cosine similarity。 |
| **Metadata Filtering** | 只取「當前年度」+「Subclass 500」+「GS」的法規。 | 在向量 DB 中加入 `year`, `visa_subclass`, `topic` 標籤。 |
| **Re‑Ranking** | 把檢索結果再排序,最相關的放在最前。 | 使用 `cross‑encoder`(如 `ms-marco‑ELECTRA`)做二次排序。 |
| **Prompt Engineering** | 明確定義「只回答」與「禁止」的範圍。 | System Prompt 加上「Answer ONLY the question; do NOT add extraneous info.」 |
| **Safety / Consistency Check Model** | 小型模型(如 `gpt-4o-mini`)先行檢查是否符合 Direction 106 關鍵要素。 | 若檢測到「unrelated course」等敏感詞,自動加入內部 note 要求人類加強審核。 |
| **Chunk‑Level Summarization** | 將長段落濃縮為 1‑2 行要點,防止上下文溢出。 | 在 RAG 前置作業使用 `gpt-4o` 產生 `TL;DR` 段落。 |

---

## 3️⃣ 系統架構總覽(文字版)

```
┌──────────────────────────────────────────────────────────────────┐
│                        Google Drive (Student Folder)            │
│   ├── 學生個人資料夾 (Passport, Photo, ID)                      │
│   ├── Form500 (PDF/圖片)                                         │
│   ├── 案例資料夾 (成功/失敗 GS 案例)                              │
│   └── 法規資料夾 (Home Affairs PDFs, Direction 106)              │
└─────────────────────┬────────────────────────────────────────────┘
                      │ (Google Drive API + Cloud Function 觸發)
                      ▼
          ┌───────────────────────┐
          │   Cloud Function      │  // 檔案新增/修改事件
          │   (Event‑Driven)       │
          └──────┬────────────────┘
                 │ ① OCR / Layout Extraction
          ┌─────▼──────────────────┐
          │   Document AI (Vision) │  // 文字、表格、簽名
          │   (Azure Read / GCP)   │
          └─────┬──────────────────┘
                 │ ② Structured Extraction (LayoutLM / GPT‑4o)
          ┌─────▼──────────────────┐
          │   Structured JSON      │  // 學生欄位、回答、證據清單
          │   (StudentSchema)       │
          └─────┬──────────────────┘
                 │ ③ Versioning (Git‑like) → DB (PostgreSQL / Firestore)
          ┌─────▼──────────────────┐
          │   RAG Vector Store     │  // 法規、成功/失敗案例向量
          │   (Weaviate / Pinecone)│
          └─────┬──────────────────┘
                 │ ④ Multi‑Model Generation
          ┌─────▼──────────────────────┐
          │   LLM Orchestrator         │
          │  ├─ Main Model (GPT‑4o)    │  // 150‑word answer
          │  ├─ Safety Model (Mini)    │  // Direction 106 合規檢查
          │  └─ Citation Model (Legal) │  // 自動產出法規引用
          └─────┬──────────────────────┘
                 │ ⑤ Output Assembly
          ┌─────▼──────────────────────┐
          │   Word Template (docx)     │  // 150‑word Answer + Internal Note
          │   + Evidence Checklist     │  // + 法規引用列表
          └─────┬──────────────────────┘
                 │ ⑥ Human Review UI (React / Angular)
          ┌─────▼──────────────────────┐
          │   Reviewer (顧問)           │  // 最終審核、修改、提交
          └─────┬──────────────────────┘
                 │ ⑦ Final Submission (ImmiAccount Upload)
          ┌─────▼──────────────────────┐
          │   Audit Log / Versioning   │  // 版本快照、回滾、統計
          └──────────────────────────────────────────────────────────┘
```

### 3.1 各元件職責

| 元件 | 技術棧 | 關鍵功能 |
|------|--------|----------|
| **Google Drive Watch** | Google Drive API v3 + Cloud Pub/Sub | 即時偵測學生資料夾變動,觸發後端流程。 |
| **OCR** | Azure AI Document Intelligence / GCP Vision | 擷取 PDF、圖片中的文字、表格、簽名。 |
| **結構化抽取** | LayoutLM v3 / GPT‑4o (Vision) | 將護照、學歷、財務證明等轉換為 JSON(`StudentSchema`)。 |
| **版本控制** | PostgreSQL + JSONB / Firestore | 每一次文件更新自動建立新版本;支援 Diff、Rollback。 |
| **向量檢索** | Weaviate (self‑hosted) / Pinecone (托管) | 法規、成功/失敗案例、案例庫的語意向量。 |
| **主生成模型** | OpenAI `gpt-4o`(或其他同等模型) | 產生 150‑word 英文答案、Internal Note、Evidence Checklist。 |
| **安全/合規模型** | `gpt-4o-mini`(低成本) | 檢查答案是否觸發 Direction 106 敏感點(如 unrelated course)。 |
| **引用模型** | `gpt-4o` + 法規段落摘要 | 自動在答案末端列出「依據:Direction 106 第 X 條」等。 |
| **Word 輸出** | `python-docx` / `docx-templates` | 產生 `.docx` 檔,內含答案、內部備註、證據清單、法規引用。 |
| **人類審核 UI** | React + Ant Design / Angular Material | 檢視、編輯、批准、提交;支援 Comment、Version Diff。 |
| **日誌/監控** | Cloud Logging + Prometheus + Grafana | 記錄每次 API 呼叫、成功/失敗率、Token 使用量。 |

---

## 4️⃣ 成功 / 失敗案例如何使用?

| 案例類型 | 用途 | 使用方式 |
|----------|------|----------|
| **成功案例** | 提供「最佳實踐」與「高分要素」 | 1️⃣ 向量化後作為 RAG 正例;<br>2️⃣ 在 Prompt 中加入「參考以下成功範例:」 + 3 個精選段落;<br>3️⃣ 自動產出「成功要素檢查表」供內部顧問比對。 |
| **失敗案例** | 警示「常見拒簽」與「觸發點」 | 1️⃣ 同樣向量化,但以「負面提示」形式注入 Prompt(例如「避免以下情況:」)<br>2️⃣ 自動生成「失敗因素警示」置於 Internal Note。 |
| **案例標註** | 確保資訊可被過濾 | 每個案例附加 metadata:`outcome (approved/refused)`, `year`, `visa_subclass`, `key_issue (e.g., finance, course‑relevance)`. |

> **實務技巧**:每季重新人工抽取 20–30 個案例(需脫敏)寫入 `CaseStudy` 表,以提升 RAG 的語意覆蓋度。

---

## 5️⃣ 法規如何自動更新與引用?

| 步驟 | 技術 | 說明 |
|------|------|------|
| **① 爬蟲** | `scrapy` / `playwright` + Cloud Scheduler(每日) | 抓取 `homeaffairs.gov.au` / `legislation.gov.au` 最新 PDF、HTML。 |
| **② 解析** | `pdfplumber`(PDF)+ `BeautifulSoup`(HTML) | 取得文字、表格、目錄結構。 |
| **③ 版本化** | PostgreSQL `RegulationSnapshot` 表(`id`, `title`, `url`, `version_date`, `content_hash`) | 每次抓取比對 hash,若變更則寫入新紀錄。 |
| **④ 向量化** | `text-embedding-3-large`(或同等) | 對每段落(≤500 tokens)生成向量寫入 Weaviate;附帶 `regulation_id`、`article_no`、`year` 等 metadata。 |
| **⑤ 引用生成** | `gpt-4o` + Prompt:「以下內容出現在法規第 X 條,引用格式為『Direction 106, Section X (Year)』」 | 在答案末端自動加入「References」列表。 |
| **⑥ 回滾** | 當新版本失效或被撤回時,自動標記 `is_current=False`;RAG 檢索時只取 `is_current=True`。 |  |

> **建議**:每季由合規團隊(Compliance Officer)手動審查法規解析結果,確保自動抽取的段落沒有遺漏或錯誤。

---

## 6️⃣ 資料安全與 API 供應商風險

| 風險 | 緩解措施 |
|------|----------|
| **傳輸安全** | 所有 API 呼叫使用 TLS 1.3;內部服務間使用 mTLS。 |
| **靜態加密** | 學生資料(護照掃描、照片)在 Google Drive 使用 AES‑256 加密;存放於 DB 時使用 PostgreSQL 的 `pgcrypto` 加密敏感欄位。 |
| **存取控制** | RBAC(角色型存取):顧問只讀取本人負責的學生資料;管理員擁有全部;AI 服務帳號僅具「讀取+寫入」最小權限。 |
| **資料留存** | 學生文件在生成完成後 90 天自動刪除(符合澳洲 Privacy Act),除非學生另行同意延長。 |
| **API 供應商鎖定** | 採用 **Adapter Pattern** 包裝 LLM 呼叫(`LLMAdapter`),支援快速切換 `OpenAI → Azure OpenAI → Anthropic`;所有 Prompt 以變數注入,工廠模式實例化。 |
| **合約與資料處理** | 與供應商簽署 **DPA(Data Processing Agreement)**,明確禁止將資料用於模型訓練;索取 SOC 2 Type II 報告。 |
| **回退機制** | 若主要模型逾時/失敗,自動切換至備用模型;同時寫入 `FallbackLog` 以供審計。 |
| **審計日誌** | 所有操作(OCR、生成、版本變更)寫入 Immutable Audit Log(Cloud Audit Logs + Cloud Storage Object versioning)。 |

---

## 7️⃣ 多模型是否值得?

| 考量 | 短期(MVP) | 中期(V1) | 長期(V2) |
|------|------------|-----------|-----------|
| **模型數量** | 1 主模型(GPT‑4o) | 1 主模型 + 1 安全模型(Mini) | 主模型 + 安全模型 + 引用模型 + 潛在 Fine‑tuned Domain Model |
| **成本** | $0.01/1k tokens(假設) | + $0.001/1k tokens(安全模型) | + $0.005/1k tokens(引用) |
| **提升** | 快速產出、可控制 | 降低不合規風險、提升引用準確度 | 自動化程度最高,顧問負擔降至 30% |
| **風險** | 單點失敗、可能遺漏法規細節 | 需维护多模型部署與版本同步 | 需持續監控模型表現與合規性 |
| **建議** | **MVP** 採用單模型,降低技術與維運負擔;先驗證流程可行性。 | **V1** 加入安全模型與基礎引用;此時已具備完整 RAG。 | **V2** 再引進領域微調模型(如經過澳洲移民法語料微調的 Llama‑3)或其他大型語言模型,以提升特定條款的解讀。 |

> **實務結論**:多模型在 **合規與錯誤率** 上有明顯收益,但前期投入(調試、監控、成本)不小。建議採 **漸進式** 部署(MVP → V1 → V2)。

---

## 8️⃣ 輸出格式建議

### 8.1 三層輸出結構

| 層次 | 用途 | 格式 |
|------|------|------|
| **1️⃣ 150‑Word Answer** | 直接寫入 ImmiAccount 表格 | 英文,每題 150 words (±5%),段落式。 |
| **2️⃣ Internal Long Note** | 顧問快速理解背後邏輯、額外說明 | 中文,含「要點摘要」「潛在風險提示」「建議補充的證據」等。 |
| **3️⃣ Evidence Checklist** | 確保文件齊備、符合 Direction 106 | 表格(`Evidence Item`, `Present?`, `File Path`, `Note`)。 |

### 8.2 Prompt 範例(System Prompt)

```
你是澳洲移民局 Subclass 500 真正的學生 (GS) 生成助理。  
你的任務是根據以下資訊產生 **英文 150‑Word** 回答(ImmiAccount 表格),以及**中文內部備註**與**證據清單**。  

**Direction 106 核心要素**(請務必符合):
- 申請人的總體情況(包括在祖國的狀況)
- 潛在在澳洲的情況
- 課程價值與申請人過去、現在或未來之關聯
- 先前的移民史、簽證記錄
- 若為未成年父母/法定監護人,需提供其意向聲明
- 若申請人參加與其學術背景或職業目標無關的課程,需額外說明

**輸出格式(JSON)**:
{
  "answer_150w": "...(英文,最多 150 words)...",
  "internal_note": "...(中文,建議 200–400 字)...",
  "evidence_checklist": [
    {"item": "護照影本", "present": true, "file": "student/passport.pdf", "note": ""},
    {"item": "資金證明 (Bank Statement)", "present": false, "file": "", "note": "需提供近 3 個月的存款證明"},
    ...
  ],
  "regulation_citations": [
    {"citation": "Direction 106, Section 4.1 (2024)", "relevant_text": "..."},
    ...
  ]
}
```

> **注意**:在 `internal_note` 中必須標註「此內容僅供內部參考,非移民建議」。

---

## 9️⃣ MVP / V1 / V2 路線圖

| 階段 | 時間 | 主要交付 | 關鍵技術 | 驗收標準 |
|------|------|----------|----------|----------|
| **MVP** | 4–6 週 | • Google Drive 觸發 OCR + 基本 JSON 提取<br>• 單一 LLM(GPT‑4o)生成 150‑Word 答案<br>• 手動下載 Word 檔 | Drive API, Azure Read, `gpt-4o` | ① 成功生成 10 個測試案例答案(≥90% 符合長度)<br>② 顧問手動審核後無重大錯誤 |
| **V1** | 8–12 週 | • RAG(法規 + 成功/失敗案例)<br>• 多模型安全檢查(Mini)<br>• 自動法規引用<br>• Word 自動產出(docx)<br>• 版本控制 + 回滾 | Weaviate, `gpt-4o-mini`, `python-docx`, PostgreSQL | ① RAG 召回率 > 85%(以人工比對)<br>② 安全模型檢測到至少 80% 的 Direction 106 觸發點<br>③ 顧問平均審核時間降至 ≤10 分鐘/案件 |
| **V2** | 6–9 個月 | • 法規自動爬蟲 + 版本化<br>• Domain‑Fine‑tuned Model(澳洲移民法)<br>• 前端 UI(React)完整審核工作流<br>• 統計儀表板(通過率、案例分析)<br>• 多語言支援(越南語、印地語等) | Cloud Scheduler, `Fine‑tuned LLaMA‑3‑8B`, React + Ant Design, Grafana | ① 法規更新延遲 ≤ 24 小時<br>② 端到端(檔案上傳 → 生成 → 提交)≤ 30 分鐘<br>③ 人類審核錯誤率 < 2%<br>④ 顧問 NPS > 8 |
| **持續改進** | 季度 | • 案例庫更新(每年 30 案例)<br>• Prompt 演進(基於失敗案例)<br>• 合規培訓 | 回饋迴圈、MLOps | • 每季錯誤率下降 ≥ 10% |

---

## 🔟 資料模型(Entity‑Relationship Overview)

```sql
-- 1. 學生 (Student)
CREATE TABLE student (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    full_name   TEXT NOT NULL,
    passport_no TEXT,            -- 加密儲存
    nationality TEXT,
    dob         DATE,
    created_at  TIMESTAMPTZ DEFAULT now()
);

-- 2. 申請 (Application)
CREATE TABLE application (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    student_id   UUID REFERENCES student(id),
    visa_subclass TEXT DEFAULT '500',
    gs_year      INT,                 -- 申請年度
    status       TEXT,                -- draft, pending_review, approved, refused
    created_at   TIMESTAMPTZ DEFAULT now()
);

-- 3. 文件 (Document)
CREATE TABLE document (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    application_id UUID REFERENCES application(id),
    doc_type     TEXT,                -- passport, photo, financial, academic, etc.
    gcs_path     TEXT,                -- Google Cloud Storage path (encrypted)
    ocr_text     TEXT,                -- raw OCR output
    extracted    JSONB,               -- 結構化欄位(StudentSchema)
    version      INT DEFAULT 1,
    uploaded_at  TIMESTAMPTZ DEFAULT now()
);

-- 4. GS 答案 (GSAnswer)
CREATE TABLE gs_answer (
    id                UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    application_id    UUID REFERENCES application(id),
    question_id       TEXT,                -- ImmiAccount question code
    answer_150w       TEXT,
    internal_note     TEXT,
    evidence_checklist JSONB,
    regulation_citations JSONB,
    model_version     TEXT,                -- 'gpt-4o' / 'gpt-4o-mini' etc.
    token_used        INT,
    created_at        TIMESTAMPTZ DEFAULT now()
);

-- 5. 版本 (Version) – Git‑like
CREATE TABLE version (
    id               UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    entity_type      TEXT,                -- 'gs_answer', 'document', 'regulation'
    entity_id        UUID,
    version_no       INT,
    diff             TEXT,                -- JSON diff
    changed_by       TEXT,                -- user id or 'system'
    changed_at       TIMESTAMPTZ DEFAULT now()
);

-- 6. 法規快照 (RegulationSnapshot)
CREATE TABLE regulation_snapshot (
    id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    title         TEXT,
    url           TEXT,
    version_date  DATE,
    content_hash  TEXT,
    is_current    BOOLEAN DEFAULT true,
    raw_content   TEXT,
    created_at    TIMESTAMPTZ DEFAULT now()
);

-- 7. 案例研究 (CaseStudy)
CREATE TABLE case_study (
    id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    outcome       TEXT,                -- approved, refused
    year          INT,
    visa_subclass TEXT,
    key_issue     TEXT,                -- finance, course‑relevance, etc.
    summary       TEXT,
    embedding     vector(1536),        -- 假設使用 1536‑dim 向量(text‑embedding‑3‑large)
    created_at    TIMESTAMPTZ DEFAULT now()
);

-- 8. 審核日誌 (AuditLog)
CREATE TABLE audit_log (
    id            BIGSERIAL PRIMARY KEY,
    user_id       TEXT,
    action        TEXT,
    entity_type   TEXT,
    entity_id     UUID,
    detail        JSONB,
    performed_at  TIMESTAMPTZ DEFAULT now()
);
```

> **說明**:所有涉及 **護照號碼、資金證明** 等敏感個資,必須使用 `pgcrypto` 加密;向量欄位使用 `pgvector`(PostgreSQL 擴展)或外部向量 DB。

---

## 1️⃣1️⃣ Prompt 策略(高層設計)

| 階段 | Prompt 類型 | 關鍵要素 |
|------|-------------|----------|
| **System** | 角色 + 法規背景 + 輸出格式 | 「你是澳洲移民局 Subclass 500 GS 助理,……」 + Direction 106 要點 + JSON schema |
| **User** | 學生資料 + 檢索到的法規/案例 | 插入 `{{student_json}}` + `{{retrieved_context}}` |
| **Few‑Shot** | 2–3 個成功/失敗案例(脫敏) | 讓模型學會「如何引用證據」與「避免觸發敏感點」 |
| **Post‑Processing** | 安全模型檢查 | Prompt:「若以下答案中出現『unrelated course』或『insufficient fund』等關鍵字,請在 internal_note 中標註『⚠️ 高風險』」 |
| **Citation** | 自動引用法規 | Prompt:「根據以下法規段落,產出標準引用格式」 |
| **Versioning** | 每次生成後自動寫入 `gs_answer` 表 | 觸發時傳入 `model_version`, `token_used` 等 Metadata |

### 1️⃣1️⃣1️⃣ Prompt 範本(完整版)

```
SYSTEM:
你是一名專門處理澳洲學生簽證(Subclass 500)真正學生(GS)申請的 AI 助理。  
**Direction 106 核心考量**(請在答案中體現):
1. 申請人的總體情況(包括在祖國的情況)  
2. 潛在在澳洲的情況(居住、學習、生活)  
3. 所選課程對申請人的價值(與過去、現在或未來學習/工作的關聯)  
4. 申請人、先前或同行的監護人/父母的移民史與意向  
5. 申請人是否有與其背景/目標無關的課程、簽證歷史或不一致之處(這些情形需額外說明)  

**輸出格式(JSON)**:
{
  "answer_150w": "...(英文,最多 150 個單詞)...",
  "internal_note": "...(中文,200‑400 字,包含要點、潛在風險、建議)...",
  "evidence_checklist": [
    {"item":"護照影本","present":true,"file":"...","note":""},
    ...
  ],
  "regulation_citations": [
    {"citation":"Direction 106, Section 4.1 (2024)","relevant_text":"..."},
    ...
  ]
}
**注意**: 所有輸出僅供內部使用,非移民建議。請遵守澳洲 Privacy Act 與資料保密原則。

USER:
### 學生基本資訊
{{student_json}}

### 已檢索的法規段落(相關片段):
{{retrieved_regulation}}

### 已檢索的成功/失敗案例摘要:
{{retrieved_cases}}

### 當前問題(ImmiAccount 題號):
{{question_id}} - {{question_text}}
```

---

## 1️⃣2️⃣ 評分 Rubric(自動 + 人類共同)

| 維度 | 權重 | 評估指標 | 評分方式 |
|------|------|----------|----------|
| **長度合規** | 10% | 150 words ±5%(130‑160) | 正則表達式計數 |
| **內容相關性** | 25% | 是否回答了問題核心;是否涵蓋 Direction 106 要點 | 關鍵字覆蓋率(自動)+ 人類審核(主觀) |
| **證據支持度** | 25% | 每個聲稱是否有對應的 Evidence Checklist 項目;文件路徑是否存在 | 自動比對 `evidence_checklist.present` 與實際文件 |
| **法規引用準確性** | 15% | 引用格式是否符合「Direction 106, Section X (Year)」;段落是否與內容相關 | 正則校驗 + 人類抽查 |
| **語言質量** | 10% | 英文語法正確、正式、符合移民局風格 | `language-check` / `grammarly-api` + 人類 |
| **安全合規** | 15% | 是否觸發 Direction 106 高風險關鍵字;是否含有不當內容 | 安全模型(Mini)分類(0/1)+ 人類審核 |

> **總分 = Σ(權重 × 分項分數)**;合格分數 ≥ 80%。若低於 80%,系統自動生成「需要修改」的提示,送到人類顧問審核。

---

## 1️⃣3️⃣ 人類審核 Checklist(顧問必檢項目)

| 序號 | 檢查項目 | 備註 |
|------|----------|------|
| 1 | **完整性** – 所有 ImmiAccount 問題均已產生答案。 | 確認 `question_id` 完整、未漏題。 |
| 2 | **長度** – 每個答案在 130‑160 個英文單詞之間。 | 超出範圍需手動縮減或補充。 |
| 3 | **事實正確性** – 學生姓名、護照號碼、出生日期、課程名稱等關鍵資訊無誤。 | 可對照 OCR 提取結果。 |
| 4 | **證據清單匹配** – 每項聲稱均已有對應的證據項目,且文件已上傳至 Drive。 | 若缺失,列入「需補件」清單。 |
| 5 | **法規引用** – 引用段落是否與內容相關、格式正確。 | 必要時自行加上「依據」說明。 |
| 6 | **Direction 106 觸發點** – 是否有「unrelated course」或「不一致」敘述,需額外說明。 | 若有,檢查 internal_note 是否已標註「⚠️ 高風險」並提供建議。 |
| 7 | **語氣與風格** – 是否使用正式、移民局可接受的英語。 | 避免口語化或誇張描述。 |
| 8 | **資料保密** – 輸出文件中是否有護照號碼等敏感資訊未加密或外泄。 | 確認 `.docx` 檔案不含明文護照號。 |
| 9 | **版本一致性** – 本次生成的答案是否基於最新的文件版本(文件 version ≥ answer version)。 | 若文件更新,必須重新生成。 |
|10 | **最終批准** – 顧問在系統內點選「Approved」,方可導出 Word 並上傳至 ImmiAccount。 | 確保所有「待補件」狀態已關閉。 |

> **建議**:每次審核結束後,系統自動把審核結果寫入 `audit_log`,便於日後統計與合規稽查。

---

## 1️⃣4️⃣ 結語與建議

1. **MVP 先聚焦**:先讓顧問能 **快速產出 150‑Word 答案**、**Word 檔下載**、**基本版本控制**,再逐步加入 RAG、多模型安全檢查與法規自動更新。  
2. **資料安全先行**:所有護照掃描、財務證明必須加密、角色隔離,並簽署 DPA,防止資料外泄與模型訓練爭議。  
3. **法規更新作為血液**:每 24 小時自動爬取一次最新 Direction 106、政策手冊,確保答案永遠基於最新法律。  
4. **多模型分層**:主模型產出內容 → 安全模型檢查合規 → 引用模型自動生成法規引用,三者協同可大幅降低人為疏漏。  
5. **人類把關不可缺**:最終提交前必須由持牌移民代理(Migration Agent)或資深顧問審核,系統產出僅作為 **助理** 而非 **替代**。  
6. **持續反饋**:每季收集「失敗案例」與「顧問反饋」,用於微調 Prompt 與更新案例庫,形成閉環學習。  

---

**祝貴公司 AI 助理研發順利,若需要更詳細的技術實作細節(如程式碼範例、具體 API 調用、部署腳本),隨時告訴我!**
📊 Token:输入 326 / 输出 8440(reasoning 1270) | 费用:$0.020452 | 耗时:145961ms | finish_reason:stop | 续写:0
Round 1 - Claude Sonnet 4.6 route claude-sonnet-4-6 · 0.459675 USD

Prompt

你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。

【背景】
我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。

公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。

【預計資料夾/知識來源】
1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。
2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。
3. 成功案例 GS 文件夾:已成功學生 GS。
4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。
目標是讓 AI 能持續參考、持續進步。

【本地範例資料概況】
本地資料夾:C:\Users\F\AiFolder\Projects\SC_AI\GS撰寫技巧補充文件夾
包含:
- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。
- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。
範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。

【官方資料依據,請納入分析】
1. Australian Department of Home Affairs - Genuine Student requirement
來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement
重點:GS applies on/after 23 Mar 2024; GTE before then;online form asks current circumstances, course/provider reason and understanding, benefit, other information, extra question for prior student visa/applying in Australia from non-student visa;Home Affairs prefers form responses rather than separate GS statement;150 words per response;English only;supporting docs matter and evidence-supported statements get more weight。
2. Home Affairs Document Checklist Tool
來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool
重點:GS answers max 150 words per question;supporting docs can include qualifications/transcripts/employment/CV;Direction 106 factors: home country circumstances, potential circumstances in Australia, value of course, immigration history, other relevant matters, minor's parent/legal guardian/spouse intentions。
3. Ministerial Direction No. 106
來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf
重點:commences 23 Mar 2024;applies to Subclass 500;decision makers should not use factors as a mechanical checklist;further scrutiny for fraud risk, concerning immigration history, unrelated course, inconsistencies, prior/held visas;factors include home country circumstances, reasons not studying locally, ties, economic circumstances, knowledge of course/provider/living, research, value to future, consistency with past education/employment, remuneration, immigration history, minor intentions。

【問題】
請分析:工具方向是否合理;token 是否會越來越大並失焦;更好的架構;成功/失敗案例如何用;法令資料自動更新與引用;資料安全與供應商風險;多模型策略;官方 150-word GS 與 Word 完整稿的輸出取捨;MVP/V1/V2 路線圖;最終架構、資料模型、prompt 策略、評分 rubric、人類審核 checklist。

請完整回答,不要短答。

AI Reply

【CLAUDE · claude-sonnet-4-6】
# 澳洲 GS 簽證 AI 撰寫工具:完整企業架構設計

---

## 目錄

1. 工具方向合理性評估
2. Token 膨脹與失焦問題分析
3. 整體系統架構設計
4. 資料模型與知識庫設計
5. Prompt 策略設計
6. 成功/失敗案例的用法
7. 法令資料自動更新與引用
8. 資料安全與供應商風險
9. 多模型策略
10. 官方 150-word 與 Word 完整稿的輸出取捨
11. 評分 Rubric 設計
12. 人類審核 Checklist
13. MVP / V1 / V2 路線圖
14. 最終架構總覽

---

## 1. 工具方向合理性評估

### 1.1 方向正確,但有幾個核心風險需要在架構層面解決

你的方向本質上是:**文件理解 → 知識注入 → 多模型生成 → 人工篩選**,這是目前 LLM 應用中最成熟、風險最可控的落地模式之一。以下逐點評估:

| 面向 | 評估 | 說明 |
|------|------|------|
| 商業合理性 | ✅ 強 | 每份 100-200 AUD,若日處理量 5-20 份,月節省 1.5 萬至 12 萬 AUD |
| 技術可行性 | ✅ 可行 | Google Drive API + LLM API 均有成熟方案 |
| 品質上限 | ⚠️ 需設計 | LLM 單獨生成不夠,必須有結構化 Prompt + 知識庫注入 + 評分機制 |
| 合規風險 | ⚠️ 中等 | 移民局政策每季可能更新,若知識庫過期,品質會斷崖式下降 |
| 資料隱私 | ⚠️ 高風險 | 學生護照/銀行流水等敏感文件送出至第三方 API,需要架構隔離 |
| 人工角色 | ✅ 保留正確 | 最終由員工核對選版本,這是正確的「Human-in-the-loop」設計 |

### 1.2 目前做法(Claude/ChatGPT web 版)的隱患

你說 web 版生成品質已經不錯,這是因為你(或員工)在 web 上做了大量隱性的「prompt 工程」——每次對話的上下文、補充說明、反覆修改都是人工投入。**這個過程無法複製、無法標準化、無法稽核**。

內部工具要解決的核心問題是:

> 把熟練員工腦中「什麼是好 GS」的知識,**外化為系統設計**,讓任何員工都能輸出接近資深員工水準的 GS 初稿。

---

## 2. Token 膨脹與失焦問題分析

### 2.1 為什麼 Token 會膨脹

在你的場景中,Context Window 有四個來源:

```
System Prompt(政策知識 + 撰寫技巧 + 範例)
+ 學生資料(Form 500 + 掃描件 OCR + 員工備註)
+ 歷史成功/失敗案例(Few-shot)
+ 生成指令
= 總 Token 數
```

以你的範例資料估算:
- Form 500 範本:36,102 字元 ≈ **9,000 tokens**
- 成功 GS 範本 Chuhan WU:24,361 字元 ≈ **6,000 tokens**
- System Prompt(政策 + 技巧):估計 **3,000-5,000 tokens**
- 學生實際資料(OCR):**5,000-15,000 tokens**(視文件數量)

**合計:23,000 - 35,000 tokens**,Claude Opus 4.5/4.6 有 200K context,GPT-4o/5 有 128K,DeepSeek 有 64K。

**短期看,Token 不是瓶頸,但品質失焦才是**。

### 2.2 失焦的真實原因

Token 多本身不是問題,問題是:

1. **重要資訊被稀釋**:把整份 Form 500(36K 字元)全部塞進去,但 GS 只需要其中 30% 的欄位。
2. **模型注意力分散**:LLM 在超長 context 中對「中段資訊」的注意力顯著下降(Lost in the Middle 問題)。
3. **範例品質不齊**:如果成功案例資料夾中有結構不佳的 GS,模型會學到壞習慣。
4. **指令與資料混雜**:沒有清晰的結構分離,模型不知道哪些是「資料」、哪些是「指令」。

### 2.3 解決方案:分層注入架構

不要把所有東西都塞進一個大 Prompt,而是:

```
Layer 1: System Prompt(固定,精煉,≤ 3,000 tokens)
         - 角色定義
         - GS 評分標準(Direction 106 因素)
         - 150-word 官方格式要求
         - 輸出格式規範

Layer 2: Dynamic Knowledge Injection(動態,RAG 召回,≤ 5,000 tokens)
         - 最相關的成功/失敗案例片段(非全文)
         - 最新法令變更摘要
         - 針對本學生特徵的撰寫技巧

Layer 3: Student Data Packet(結構化,壓縮後,≤ 8,000 tokens)
         - 從 Form 500 提取的結構化 JSON
         - OCR 文件的關鍵資訊摘要
         - 員工補充備註

Layer 4: Task Instruction(任務指令,≤ 1,000 tokens)
         - 具體生成任務
         - 特殊注意事項
         - 輸出格式要求
```

**總計控制在 17,000-20,000 tokens 以內**,避免浪費且保持焦點。

---

## 3. 整體系統架構設計

### 3.1 系統架構圖(文字版)

```
┌─────────────────────────────────────────────────────────────┐
│                    前端員工介面 (Web App)                      │
│  [Google Drive 連結輸入] [撰寫方向備註] [啟動生成按鈕]          │
│  [多版本對比檢視] [選定版本] [匯出 Word]                        │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│                   Orchestration Engine                        │
│  (核心調度層 - Python FastAPI / Next.js API Routes)           │
│                                                               │
│  1. Google Drive 資料擷取模組                                  │
│  2. 文件解析 & OCR 模組                                        │
│  3. 學生資料結構化模組 (Student Data Extractor)                │
│  4. RAG 知識檢索模組                                           │
│  5. Prompt 組裝模組                                            │
│  6. 多模型並行調用模組                                          │
│  7. 輸出評分模組                                               │
│  8. Word 生成模組                                              │
└──────┬──────────┬──────────┬──────────┬──────────┬──────────┘
       │          │          │          │          │
       ▼          ▼          ▼          ▼          ▼
  ┌─────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌──────────┐
  │ Claude  │ │ OpenAI │ │DeepSeek│ │ Gemini │ │ (備用)   │
  │ Opus 4+ │ │GPT-5/4o│ │  V3   │ │1.5 Pro │ │ Llama 3  │
  └─────────┘ └────────┘ └────────┘ └────────┘ └──────────┘
       │          │          │          │          │
       └──────────┴──────────┴──────────┴──────────┘
                           │
                    ┌──────▼───────┐
                    │  結果彙整層   │
                    │ 評分 + 對比  │
                    └──────────────┘

┌─────────────────────────────────────────────────────────────┐
│                      知識庫層                                  │
│                                                               │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐   │
│  │  Vector DB   │  │ Relational DB│  │   File Storage   │   │
│  │ (Embeddings) │  │(PostgreSQL)  │  │(加密, 澳洲節點)   │   │
│  │              │  │              │  │                  │   │
│  │ - GS 段落    │  │ - 學生檔案   │  │ - 原始 PDF/DOCX  │   │
│  │ - 法令條文   │  │ - 案例記錄   │  │ - 簽證結果記錄   │   │
│  │ - 案例摘要   │  │ - 生成歷史   │  │ - OCR 快取       │   │
│  └──────────────┘  └──────────────┘  └──────────────────┘   │
└─────────────────────────────────────────────────────────────┘
```

### 3.2 核心模組詳細說明

#### 模組一:Google Drive 資料擷取模組

```python
# 偽代碼示意
class GoogleDriveIngester:
    def __init__(self, credentials_path):
        self.service = build('drive', 'v3', credentials=creds)
    
    def ingest_student_folder(self, folder_url: str) -> StudentRawData:
        folder_id = self.extract_folder_id(folder_url)
        files = self.list_files_recursive(folder_id)
        
        result = StudentRawData()
        for file in files:
            if file.type == 'application/pdf':
                result.pdfs.append(self.download_and_cache(file))
            elif file.type == 'docx':
                result.forms.append(self.download_and_parse(file))
            elif file.type in IMAGE_TYPES:
                result.images.append(self.download_image(file))
        
        return result
```

**重要設計決策**:
- 文件下載後立即加密儲存在本地/私有雲,**不長期保存原始檔案在內存中**
- 每份文件設定 TTL(建議 90 天後自動刪除)
- 每次讀取記錄 audit log

#### 模組二:學生資料結構化模組(Student Data Extractor)

這是整個系統最關鍵的模組。用一個輕量模型(GPT-4o mini 或 Claude Haiku)專門負責從 Form 500 和各種文件中提取結構化資訊:

```json
{
  "student_profile": {
    "personal": {
      "name": "Chuhan WU",
      "nationality": "Chinese",
      "age": 22,
      "current_location": "China",
      "english_level": "Intermediate"
    },
    "education": {
      "highest_qualification": "High School Certificate",
      "institution": "XXX High School, Beijing",
      "graduation_year": 2023,
      "gpa_or_equivalent": "良好",
      "relevant_subjects": ["Art", "English", "Business"]
    },
    "employment": {
      "current_status": "Unemployed",
      "work_history": [
        {
          "role": "Beauty Consultant Intern",
          "employer": "XXX Company",
          "duration": "3 months",
          "relevance_to_course": "High"
        }
      ]
    },
    "financial": {
      "total_funds": 84964,
      "currency": "AUD",
      "fund_sources": ["Parents savings", "Bank account"],
      "fund_documents": ["Bank statement 3 months", "Parent income proof"]
    },
    "family": {
      "parents_in_china": true,
      "siblings_in_australia": true,
      "sibling_detail": "Elder sister studying/working in Melbourne",
      "family_ties_strength": "Strong"
    },
    "intended_course": {
      "course_name": "General English",
      "provider": "Navitas English",
      "location": "Melbourne",
      "duration": "24 weeks",
      "cricos_code": "XXXXXX",
      "course_cost_aud": 8400
    },
    "career_plan": {
      "target_industry": "Beauty and Image Design",
      "short_term": "Improve English, gain Australian qualification",
      "long_term": "Return to China, establish beauty business",
      "return_intention_strength": "Strong"
    }
  },
  "gs_risk_flags": {
    "prior_visa_refusal": false,
    "unrelated_course_to_background": false,
    "weak_home_country_ties": false,
    "insufficient_funds": false,
    "inconsistent_statements": false
  },
  "employee_notes": "需強調家族在中國的生意背景,強化回國動機"
}
```

**這個 JSON 是整個系統的「單一事實來源」(Single Source of Truth)**。後續所有模型都從這個 JSON 生成 GS,而不是從原始文件直接讀取。

---

## 4. 資料模型與知識庫設計

### 4.1 知識庫的四個集合

#### 集合 A:政策法令庫(Policy Knowledge Base)

```
policy_documents/
├── direction_106/
│   ├── direction_106_full.pdf          # 原文
│   ├── direction_106_summary.md        # AI 生成摘要
│   ├── direction_106_factors_json.json # 結構化因素列表
│   └── direction_106_changelog.md      # 版本變更記錄
├── gs_requirement/
│   ├── gs_official_page_snapshot.md   # 官方頁面快照
│   ├── gs_150_word_guide.md           # 150字指引
│   └── last_updated: 2025-07-15
├── announcements/
│   └── [日期]_[標題].md               # 自動抓取的公告
└── document_checklist/
    └── evidentiary_tool_snapshot.md
```

**向量化策略**:
- 每個段落獨立向量化(chunk size: 300-500 tokens,overlap: 50 tokens)
- Metadata 包含:來源、日期、政策版本號、重要性權重
- 定期重新向量化(當有更新時)

#### 集合 B:成功案例庫(Success Cases)

```sql
CREATE TABLE gs_cases (
    id UUID PRIMARY KEY,
    student_id UUID REFERENCES students(id),
    case_type ENUM('success', 'failure'),
    visa_result VARCHAR(50),        -- 'granted', 'refused', 'pending'
    refusal_reason TEXT,            -- 若失敗,拒簽原因
    gs_full_text TEXT,              -- 完整 GS 文本
    gs_word_150_q1 TEXT,            -- 官方表格各題答案
    gs_word_150_q2 TEXT,
    gs_word_150_q3 TEXT,
    gs_word_150_q4 TEXT,
    gs_word_150_q5 TEXT,
    nationality VARCHAR(50),
    course_type VARCHAR(100),
    course_level VARCHAR(50),
    provider VARCHAR(100),
    fund_amount_aud DECIMAL,
    has_prior_visa BOOLEAN,
    submission_date DATE,
    decision_date DATE,
    quality_score INTEGER,          -- 人工評分 1-10
    notes TEXT,
    created_at TIMESTAMP,
    indexed_at TIMESTAMP            -- 向量化時間
);
```

**成功案例的向量化策略**(重要):

不要向量化整份 GS,而是**按問題分段向量化**:

```python
def vectorize_gs_case(case: GSCase) -> List[EmbeddingRecord]:
    records = []
    
    # 每個問題段落獨立向量化
    for question_num in range(1, 6):
        segment = case.get_question_segment(question_num)
        
        # 加入 metadata 豐富上下文
        enriched_text = f"""
        [案例類型: {case.case_type}]
        [國籍: {case.nationality}]
        [課程: {case.course_type}]
        [資金: AUD {case.fund_amount_aud}]
        [問題 {question_num}]:
        {segment}
        """
        
        records.append(EmbeddingRecord(
            text=enriched_text,
            embedding=embed(enriched_text),
            metadata={
                'case_id': case.id,
                'case_type': case.case_type,
                'question_num': question_num,
                'nationality': case.nationality,
                'course_type': case.course_type,
                'quality_score': case.quality_score
            }
        ))
    
    return records
```

#### 集合 C:撰寫技巧庫(Writing Techniques)

這是員工手動補充的知識,格式如下:

```markdown
# 技巧條目範例

## 技巧 ID: WRT-045
## 類型: 資金說明
## 適用場景: 父母提供資金,父母在中國
## 重要性: 高
## 最後更新: 2025-07-10

### 核心技巧
說明資金來源時,必須同時說明:
1. 資金的具體來源(儲蓄/生意收入/房產/投資)
2. 資金的穩定性(多年積累還是近期集中)
3. 父母支持的動機(為何願意投資子女教育)

### 反面教材(失敗案例 ID: FAIL-012 相關)
移民局在拒簽信中提到:「申請人僅聲稱父母提供資金,但未說明資金來源的合法性與可持續性」

### 推薦表述框架
"My parents have been running [業務類型] in [城市] for [年數] years. 
Their accumulated savings of AUD [金額] represent [年數] years of careful 
financial planning specifically to support my educational development..."

### Direction 106 對應因素
- Economic circumstances of the applicant
- Home country circumstances
```

### 4.2 知識庫的 RAG 查詢策略

```python
class GSKnowledgeRetriever:
    
    def retrieve_for_student(
        self, 
        student_json: dict, 
        question_num: int
    ) -> RetrievalResult:
        
        # 建立查詢向量(結合學生特徵 + 問題語境)
        query = self._build_query(student_json, question_num)
        
        # 多路召回
        results = []
        
        # 1. 相似成功案例(權重最高)
        similar_cases = self.vector_db.search(
            query=query,
            collection='success_cases',
            filters={
                'case_type': 'success',
                'nationality': student_json['student_profile']['personal']['nationality'],
                'course_type': student_json['student_profile']['intended_course']['course_name'],
                'quality_score': {'gte': 8}
            },
            top_k=3
        )
        
        # 2. 相似失敗案例(用於反面學習)
        failure_cases = self.vector_db.search(
            query=query,
            collection='failure_cases',
            filters={'case_type': 'failure'},
            top_k=2
        )
        
        # 3. 相關法令條文
        policy_refs = self.vector_db.search(
            query=query,
            collection='policy_documents',
            top_k=3
        )
        
        # 4. 相關撰寫技巧
        writing_tips = self.vector_db.search(
            query=query,
            collection='writing_techniques',
            top_k=3
        )
        
        return RetrievalResult(
            success_examples=similar_cases,
            failure_warnings=failure_cases,
            policy_references=policy_refs,
            writing_tips=writing_tips
        )
    
    def _build_query(self, student_json: dict, question_num: int) -> str:
        profile = student_json['student_profile']
        
        question_contexts = {
            1: f"current circumstances home country ties {profile['personal']['nationality']} student",
            2: f"course provider reason understanding {profile['intended_course']['course_name']} {profile['intended_course']['provider']}",
            3: f"benefit value course future career {profile['career_plan']['target_industry']}",
            4: f"immigration history other information supporting documents",
            5: f"prior student visa in Australia circumstances"
        }
        
        return question_contexts.get(question_num, "genuine student requirement")
```

---

## 5. Prompt 策略設計

### 5.1 三層 Prompt 架構

#### 第一層:Master System Prompt(固定不變)

```
你是一位澳洲移民法領域的 Genuine Student (GS) Statement 專業撰稿人,
擁有超過 10 年的簽證申請材料撰寫經驗,深度熟悉 Ministerial Direction No. 106 
及 Department of Home Affairs 的 GS requirement 政策。

【你的核心任務】
根據提供的學生資料,撰寫一份完整的 Genuine Student Supporting Statement,
包含兩個部分:
A) 官方表格版本:每題不超過 150 英文單詞,直接填入 ImmiAccount 表格
B) 完整 Word 版本:每題詳細展開,包含 Summary + Detailed Version + 佐證說明

【Direction 106 評分維度——你必須在每題中覆蓋相關維度】
Factor 1: Home country circumstances (家鄉聯繫、家庭關係、不回去的代價)
Factor 2: Circumstances in Australia (在澳情況、支持網絡)
Factor 3: Value of course (課程對職涯的實際價值,而非泛泛而談)
Factor 4: Immigration history (簽證記錄、合規情況)
Factor 5: Other relevant matters (任何加分因素)

【硬性規則——絕對不可違反】
1. 所有 GS 內容必須以英文撰寫
2. 官方表格版本每題嚴格不超過 150 words
3. 不得虛構任何事實、不得捏造文件或金額
4. 若學生資料有缺口,用 [MISSING: 請員工補充XXX] 標記,不得假設
5. 必須引用具體數字、日期、地點,避免空泛表述
6. 不得使用移民局已知的「模板語言」(如 "I am a genuine student who...")

【品質標準】
- 每個聲明都必須可由文件佐證
- 敘述邏輯必須一致(前後不矛盾)
- 展示對課程/院校的真實了解(具體細節,不是官網抄寫)
- 回國動機必須具體且可信(職涯路徑清晰)
- 資金說明必須完整(來源、金額、可持續性)
```

#### 第二層:動態知識注入 Prompt(RAG 召回結果)

```python
def build_knowledge_injection_prompt(retrieval_result: RetrievalResult) -> str:
    prompt = """
【參考成功案例——學習這些表述方式和結構】

"""
    for i, case in enumerate(retrieval_result.success_examples, 1):
        prompt += f"""
成功案例 {i}(相似度: {case.similarity:.2f},品質分: {case.quality_score}/10):
國籍: {case.nationality} | 課程: {case.course_type}
---
{case.text}
---
"""

    prompt += """
【失敗警告——以下是曾導致拒簽的表述模式,必須避免】

"""
    for warning in retrieval_result.failure_warnings:
        prompt += f"""
⚠️ 拒簽風險(來自拒簽案例 {warning.case_id}):
問題描述: {warning.refusal_reason}
錯誤表述: {warning.problematic_text}
---
"""

    prompt += """
【最新法令更新——本次生成必須符合以下最新政策要求】

"""
    for policy in retrieval_result.policy_references:
        prompt += f"""
政策參考({policy.source},更新於 {policy.last_updated}):
{policy.text}
---
"""

    prompt += """
【撰寫技巧補充】

"""
    for tip in retrieval_result.writing_tips:
        prompt += f"""
技巧 {tip.id}({tip.category}):
{tip.content}
---
"""
    
    return prompt
```

#### 第三層:學生資料 + 任務指令 Prompt

```python
def build_task_prompt(
    student_json: dict, 
    employee_notes: str,
    output_type: str  # 'form_150' or 'full_word' or 'both'
) -> str:
    
    return f"""
【學生完整資料包】

{json.dumps(student_json, ensure_ascii=False, indent=2)}

【員工補充說明與撰寫方向】
{employee_notes}

【風險標記】
{format_risk_flags(student_json['gs_risk_flags'])}

【生成任務】
請根據以上資料,按以下結構生成 GS Statement:

═══════════════════════════════════════
 GS 官方表格答案(每題嚴格 ≤ 150 words)
═══════════════════════════════════════

**Question 1: Current circumstances**
(Describe your current circumstances including your ties to your home country)
[150-word answer here]
Word count: [X]/150

**Question 2: Course and provider**  
(Explain why you chose this course and provider, and your understanding of what the course involves)
[150-word answer here]
Word count: [X]/150

**Question 3: Benefit**
(Explain how completing this course will benefit you)
[150-word answer here]
Word count: [X]/150

**Question 4: Other information**
(Is there any other information you would like to provide in support of your application?)
[150-word answer here]
Word count: [X]/150

[僅當學生有舊簽證記錄時生成]
**Question 5: Prior student visa / in Australia circumstances**
[150-word answer here]
Word count: [X]/150

═══════════════════════════════════════
 GS 完整支持材料(Word 版本)
═══════════════════════════════════════

**GENUINE STUDENT STATEMENT**
Applicant: {student_json['student_profile']['personal']['name']}
Date: [今日日期]
Course: {student_json['student_profile']['intended_course']['course_name']} at {student_json['student_profile']['intended_course']['provider']}

---

**PART 1: CURRENT CIRCUMSTANCES AND HOME COUNTRY TIES**

[Summary - 3 sentences]
[Detailed Version - 3-5 paragraphs]
[Supporting Documents Referenced: List specific documents]

---

**PART 2: REASONS FOR CHOOSING THIS COURSE AND PROVIDER**

[Summary - 3 sentences]
[Detailed Version - 3-5 paragraphs]
[Supporting Documents Referenced: List specific documents]

---

**PART 3: BENEFIT AND VALUE OF THE COURSE**

[Summary - 3 sentences]
[Detailed Version - 3-5 paragraphs]
[Supporting Documents Referenced: List specific documents]

---

**PART 4: FINANCIAL CAPACITY**

[Summary - 3 sentences]
[Detailed Version - 2-3 paragraphs]
[Supporting Documents Referenced: List specific documents]

---

**PART 5: FUTURE PLANS AND INTENTION TO COMPLY**

[Summary - 3 sentences]
[Detailed Version - 3-5 paragraphs]

---

**SUPPORTING DOCUMENTS CHECKLIST**
[列出學生應準備的所有佐證文件,勾選已有/缺失]

---

**INTERNAL NOTES FOR EMPLOYEE REVIEW**
[標記任何需要員工確認的資訊缺口或潛在風險點]
"""
```

### 5.2 模型特定 Prompt 調整

不同模型對同樣的 Prompt 有不同的「偏好」:

| 模型 | Prompt 調整策略 |
|------|----------------|
| Claude Opus 4.6 | 強調「仔細思考每個聲明的可信度」,加入 `<thinking>` 標籤要求推理過程;善於處理長文件 |
| GPT-4o / GPT-5 | 加入 JSON schema 要求結構化輸出,再轉換為 Word 格式;善於遵循格式規範 |
| DeepSeek V3 | 適合用來生成「更具中文思維邏輯」的表述,特別適合中國學生背景敘事 |
| Gemini 1.5 Pro | 善於多文件同時分析,可以讓它直接讀取 Google Drive 文件(通過 Gemini Files API) |

---

## 6. 成功/失敗案例如何用

### 6.1 成功案例的三種用法

**用法一:Few-shot 示範**
直接放入 Prompt 作為「參考範例」,但要特別注意:
- 只放與當前學生特徵最相似的案例(同國籍、同課程類型、相似資金水平)
- 截取最相關的段落,而非整份 GS
- 加入「從這個案例中學習以下表述方式」的明確指令

**用法二:RAG 相關片段召回**
按問題維度召回最相關的段落:
```
Query: "Chinese student, English course, beauty industry career plan, strong family ties"
→ 召回:與此特徵最匹配的成功案例中「職涯規劃」和「家庭聯繫」段落
```

**用法三:品質基準**
在評分模組中,用成功案例的 embedding 作為「品質向量」,計算生成內容與成功案例的語義相似度,作為評分指標之一。

### 6.2 失敗案例的三種用法

**用法一:反面禁忌清單**
從拒簽信中提取移民局常見的「拒絕理由」,轉化為 System Prompt 中的「禁止事項」:

```markdown
【基於真實拒簽案例的禁忌表述】

❌ 禁止:"I plan to return to China after my studies" 
   (無具體理由,移民局視為空洞聲明)
   
✅ 應改為:具體說明回國後的工作機會、家庭責任、商業計劃

❌ 禁止:只陳述資金金額,不說明來源
   (移民局要求資金來源的合法性與可持續性說明)
   
✅ 應改為:具體說明資金來源(如父母 XX 年的生意收入),並提及佐證文件

❌ 禁止:對課程的描述與院校官網完全相同
   (顯示未真正研究課程,只是複製貼上)
   
✅ 應改為:加入個人視角和具體選擇理由
```

**用法二:風險預警**
當學生 JSON 中出現類似失敗案例的特徵時,系統自動觸發警告:

```python
def check_risk_similarity(student_json: dict) -> List[RiskWarning]:
    warnings = []
    
    # 比對失敗案例的特徵向量
    student_vector = embed(str(student_json))
    similar_failures = vector_db.search(
        query=student_vector,
        collection='failure_cases',
        top_k=3,
        threshold=0.75
    )
    
    for failure in similar_failures:
        warnings.append(RiskWarning(
            risk_level='HIGH',
            description=f"此學生特徵與失敗案例 {failure.case_id} 相似度 {failure.similarity:.0%}",
            failure_reason=failure.refusal_reason,
            mitigation=failure.mitigation_strategy
        ))
    
    return warnings
```

**用法三:對比強化**
在 Prompt 中加入:「以下是一個因 [原因] 被拒簽的案例段落,請確保你的版本避免類似問題:[失敗段落]」

### 6.3 案例庫的持續學習機制

```python
class CaseLearningPipeline:
    """每當新案例結果出來,自動更新知識庫"""
    
    def process_new_result(
        self, 
        case_id: str, 
        result: str,  # 'granted' or 'refused'
        refusal_letter: Optional[str] = None
    ):
        case = db.get_case(case_id)
        case.visa_result = result
        
        if result == 'refused' and refusal_letter:
            # 用 LLM 分析拒簽原因
            analysis = self.analyze_refusal_letter(refusal_letter, case.gs_full_text)
            
            # 提取關鍵弱點
            weaknesses = analysis.identified_weaknesses
            
            # 更新失敗案例庫
            db.add_failure_case(
                case_id=case_id,
                refusal_reasons=weaknesses,
                problematic_segments=analysis.problematic_segments
            )
            
            # 更新禁忌表述清單
            self.update_prohibition_list(weaknesses)
            
            # 重新向量化
            self.reindex_case(case_id, collection='failure_cases')
        
        elif result == 'granted':
            # 提升成功案例的品質分數(有真實佐證)
            case.quality_score = min(case.quality_score + 2, 10)
            db.update_case(case)
            self.reindex_case(case_id, collection='success_cases')
```

---

## 7. 法令資料自動更新與引用

### 7.1 監控目標與頻率

| 監控目標 | URL / 來源 | 更新頻率 | 重要性 |
|---------|-----------|---------|-------|
| GS Requirement 官方頁面 | immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement | 每日比對 | 🔴 極高 |
| Direction 106 PDF | immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf | 每日 MD5 比對 | 🔴 極高 |
| Department of Home Affairs News | homeaffairs.gov.au/news-media/pages/news-listing.aspx | 每日 | 🟡 中 |
| Migration legislation | legislation.gov.au | 每週 | 🟡 中 |
| DIBP / ImmiAccount 公告 | 每日 | 🔴 極高 |

### 7.2 自動更新架構

```python
class PolicyMonitor:
    """每日執行的政策監控服務"""
    
    async def daily_check(self):
        for source in MONITORED_SOURCES:
            current_hash = await self.fetch_and_hash(source.url)
            
            if current_hash != source.last_known_hash:
                # 內容有變化
                new_content = await self.fetch_full_content(source.url)
                old_content = self.get_cached_content(source.id)
                
                # 用 LLM 分析差異
                diff_analysis = await self.analyze_change(
                    old_content=old_content,
                    new_content=new_content,
                    source_name=source.name
                )
                
                if diff_analysis.is_significant:
                    # 重要更新:發送警報給管理員
                    await self.send_alert(
                        subject=f"⚠️ 重要政策更新:{source.name}",
                        body=diff_analysis.summary,
                        changes=diff_analysis.key_changes,
                        action_required=diff_analysis.impact_on_gs_writing
                    )
                    
                    # 更新知識庫
                    await self.update_policy_kb(
                        source_id=source.id,
                        new_content=new_content,
                        effective_date=diff_analysis.effective_date
                    )
                    
                    # 標記需要人工確認
                    await self.flag_for_human_review(diff_analysis)
                    
                    # 暫停 GS 生成服務,直到人工確認
                    if diff_analysis.risk_level == 'HIGH':
                        await self.pause_generation_service()
                
                # 更新 hash
                source.last_known_hash = current_hash
                source.last_checked = datetime.now()
    
    async def analyze_change(self, old_content, new_content, source_name) -> DiffAnalysis:
        prompt = f"""
        以下是澳洲移民局 {source_name} 的頁面更新。
        
        舊內容:
        {old_content[:3000]}
        
        新內容:
        {new_content[:3000]}
        
        請分析:
        1. 有哪些重要變化?
        2. 這些變化對 Genuine Student Statement 撰寫有何影響?
        3. 是否有任何舊的撰寫建議需要作廢?
        4. 是否有新的要求需要納入?
        5. 風險評級(HIGH/MEDIUM/LOW)
        
        以 JSON 格式回答。
        """
        
        response = await claude_client.messages.create(
            model="claude-opus-4-5",
            messages=[{"role": "user", "content": prompt}]
        )
        
        return DiffAnalysis.parse(response.content)
```

### 7.3 版本管理與引用追蹤

每份 GS 生成時,系統記錄所用的政策版本:

```json
{
  "generation_metadata": {
    "generated_at": "2025-07-15T10:30:00Z",
    "models_used": ["claude-opus-4-5", "gpt-4o", "deepseek-v3"],
    "policy_versions": {
      "direction_106": "v1.0 (2024-03-23)",
      "gs_requirement_page": "snapshot_20250715",
      "document_checklist": "snapshot_20250710"
    },
    "knowledge_base_versions": {
      "success_cases_count": 47,
      "failure_cases_count": 12,
      "last_kb_update": "2025-07-14"
    },
    "employee_id": "EMP_005",
    "student_id": "STU_20250715_001"
  }
}
```

這樣,如果日後出現問題,可以追溯到當時的知識庫狀態,進行責任審計。

---

## 8. 資料安全與供應商風險

### 8.1 威脅模型分析

學生資料包含:護照掃描件、銀行流水、居住地址、家庭成員資訊。這是極度敏感的個人資料(澳洲 Privacy Act 1988,中國個資保護法均適用)。

| 威脅 | 風險等級 | 緩解方案 |
|------|---------|---------|
| API 供應商資料訓練 | 🔴 高 | 使用企業 API(明確無訓練條款),或本地部署 |
| API 傳輸截攔 | 🟡 中 | 全程 HTTPS,敏感欄位傳輸前遮蔽 |
| 員工誤操作洩漏 | 🟡 中 | 最小權限原則,audit log,MFA |
| 雲端存儲洩漏 | 🟡 中 | 加密存儲,澳洲或中國節點,定期刪除 |
| Google Drive 共享設置錯誤 | 🔴 高 | 讀取後立即本地緩存,不長期依賴 Drive 共享 |

### 8.2 資料安全架構設計

#### 敏感資料遮蔽(Redaction before API call)

**核心原則**:護照號碼、銀行帳號等識別性資訊,在送出 API 之前進行遮蔽:

```python
class DataRedactor:
    """在送出 LLM API 前遮蔽敏感識別資訊"""
    
    REDACTION_RULES = [
        # 護照號碼(中國護照格式:E + 8位數字)
        (r'[EGP][0-9]{8}', '[PASSPORT_NO_REDACTED]'),
        # 銀行帳號
        (r'\b[0-9]{10,20}\b', '[ACCOUNT_NO_REDACTED]'),
        # 信用卡號
        (r'\b(?:\d[ -]?){13,16}\b', '[CARD_NO_REDACTED]'),
        # 手機號碼
        (r'(?:\+86)?1[3-9]\d{9}', '[PHONE_REDACTED]'),
    ]
    
    def redact_for_llm(self, text: str) -> tuple[str, dict]:
        """
        Returns: (redacted_text, restoration_map)
        restoration_map 用於在最終 Word 中還原真實資訊
        """
        restoration_map = {}
        redacted = text
        
        for pattern, placeholder in self.REDACTION_RULES:
            matches = re.findall(pattern, redacted)
            for i, match in enumerate(set(matches)):
                unique_key = f"{placeholder}_{i}"
                restoration_map[unique_key] = match
                redacted = redacted.replace(match, unique_key)
        
        return redacted, restoration_map
    
    def restore_in_output(self, output: str, restoration_map: dict) -> str:
        """在最終輸出中還原真實資訊"""
        restored = output
        for key, value in restoration_map.items():
            restored = restored.replace(key, value)
        return restored
```

注意:GS Statement 本身不應該包含護照號碼或銀行帳號,這些資訊只出現在支持文件中,不會進入 GS 文本。但 Form 500 包含這些欄位,讀取時需要遮蔽後再送 LLM。

#### API 供應商選擇的安全考量

```
優先順序(安全性維度):

1. 本地部署 Llama 3 / DeepSeek 本地版
   → 最安全,但品質可能略遜
   → 適合:敏感文件摘要、Student Data Extraction 步驟

2. Azure OpenAI / AWS Bedrock(企業契約)
   → 明確的資料不訓練條款
   → 適合:主要生成步驟

3. Anthropic Claude API(Enterprise tier)
   → 有明確的隱私政策,Enterprise 版不訓練
   → 適合:主要生成步驟

4. OpenAI API(付費,無 data training opt-out 問題)
   → API 版本不用於訓練(需確認最新條款)
   
5. DeepSeek API(中國公司)
   → 涉及中國學生資料時有額外的合規考量
   → 建議:僅作為對比用,不作主力
   → 或使用 Together.ai / Groq 上托管的 DeepSeek,規避資料主權問題

⚠️ 絕對避免:使用 web 介面(ChatGPT.com, Claude.ai)處理真實學生資料
```

#### 資料生命週期管理

```python
DATA_RETENTION_POLICY = {
    'raw_documents': {
        'retention_days': 90,
        'encryption': 'AES-256',
        'storage': 'AU_REGION_ONLY',
        'deletion': 'SECURE_WIPE'
    },
    'extracted_json': {
        'retention_days': 365,  # 案例學習需要
        'encryption': 'AES-256',
        'pii_fields_masked': True
    },
    'generated_gs': {
        'retention_days': 730,  # 保留2年用於案例學習
        'encryption': 'AES-256'
    },
    'llm_api_logs': {
        'retention_days': 30,
        'note': '不記錄學生原始資料,只記錄調用 metadata'
    }
}
```

### 8.3 供應商風險管理

**模型供應商多元化策略(不依賴單一供應商)**:

```
Claude(主力)+ GPT(備用主力)+ Gemini(Google 生態協同)+ DeepSeek(成本優化)

風險場景:
- Claude API 突然漲價/停服 → GPT 立即接管
- OpenAI 政策變更不允許移民相關用途 → Claude + Gemini 接管
- 中美科技衝突影響 API 可用性 → 本地 Llama 3 作為最後防線
```

---

## 9. 多模型策略

### 9.1 為什麼需要多模型

不是為了多而多,而是每個模型有真實的差異化優勢:

| 模型 | 在 GS 場景中的優勢 | 劣勢 |
|------|------------------|------|
| Claude Opus 4.6 | 長文件理解最強、細節一致性高、善於複雜邏輯推理、遵循指令準確 | 速度較慢、成本最高 |
| GPT-4o / GPT-5 | 格式遵循準確、結構清晰、英文表達地道 | 對新政策的「幻覺」風險較高 |
| DeepSeek V3 | 成本極低(GPT-4o 的 1/30)、中文背景理解強 | 英文表達稍遜、較少訓練在移民場景 |
| Gemini 1.5 Pro | 原生 Google Drive 整合、多模態(可直接看圖片文件)、上下文超長(1M token) | 在法律/移民專業場景表現不如 Claude |

### 9.2 多模型調用策略

**策略一:全並行生成(推薦用於 MVP 後)**
```
同時調用 Claude + GPT + DeepSeek
→ 3個獨立版本 → 員工選最佳 → 或 AI 評分後推薦
優點:多樣性高,員工有選擇餘地
缺點:成本是單模型的 3 倍,時間取決於最慢的模型
```

**策略二:串聯精煉(推薦用於 MVP)**
```
Step 1: GPT-4o mini / Gemini Flash(快速、便宜)→ 生成初稿
Step 2: Claude Opus 4.6(最強)→ 審查初稿,提出改進,生成最終版
Step 3: DeepSeek(便宜)→ 檢查邏輯一致性和遺漏點

優點:成本控制好,質量有保障
缺點:串聯時間長(可能 3-5 分鐘)
```

**策略三:混合策略(推薦 V1)**
```
快速通道:DeepSeek + Claude Haiku → 5分鐘,低成本,日常批量用
精品通道:Claude Opus + GPT-4o 全並行 → 15分鐘,高成本,VIP 學生或複雜案例用
```

### 9.3 模型調用的成本估算

```
每份 GS 的 Token 消耗(估算):
- Input tokens: ~20,000 tokens
- Output tokens: ~5,000 tokens(官方版 + 完整版)

各模型成本:
Claude Opus 4.5: $15/M input + $75/M output
  → 20K × $15 + 5K × $75 = $0.675/份

GPT-4o: $2.5/M input + $10/M output  
  → 20K × $2.5 + 5K × $10 = $0.10/份

DeepSeek V3: $0.27/M input + $1.1/M output
  → 20K × $0.27 + 5K × $1.1 = $0.011/份(!!超便宜)

Gemini 1.5 Pro: $3.5/M input + $10.5/M output
  → 20K × $3.5 + 5K × $10.5 = $0.123/份

三模型並行(Claude + GPT + DeepSeek)總成本:
$0.675 + $0.10 + $0.011 ≈ $0.786/份

對比人力外包:$100-200 AUD
AI 成本:< $1 AUD

ROI: 即使加上開發和維護成本,一年節省超過 95%
```

---

## 10. 官方 150-word 與 Word 完整稿的輸出取捨

### 10.1 移民局的立場

根據官方資料:
> "Home Affairs prefers form responses rather than separate GS statement"
> "150 words per response"
> "evidence-supported statements get more weight"

這意味著:**移民局官員會先看 150-word form response,而不是附加的 Word 文件**。150-word 版本是「主戰場」。

### 10.2 但完整 Word 稿仍然重要

原因:
1. **Word 稿是「拓展材料」(Supporting Documents)的一部分**,Direction 106 明確指出 supporting docs 有加分效果
2. **150 words 不夠充分表達複雜情況**(如有特殊背景、有舊簽證記錄等)
3. **員工審核和修改的工作底稿**:Word 稿包含完整邏輯,員工從中提煉 150-word 版本
4. **複雜案例的風險緩解**:對於有拒簽風險的學生,詳細的支持材料可以彌補表格的字數限制

### 10.3 最佳實踐:兩套並行但主次分明

```
輸出優先順序:

【核心】150-word Form Answers(5題)
→ 這是移民官直接審核的材料
→ 必須精煉、有力、符合 GS 評分因素
→ 每個 word 都要有重量

【輔助】Complete Supporting Statement(Word 文件)
→ 給想深入了解的移民官提供背景
→ 包含更多細節、佐證文件引用
→ 結構清晰,便於快速掃讀

【附件】Supporting Documents Checklist
→ 明確列出哪些文件支持哪些聲明
→ 幫助移民官快速找到佐證
```

### 10.4 150-word 版本的特殊撰寫技巧

```
150 words 的分配策略(以 Q1 為例):

句子 1-2(約 30 words):核心聲明(最強的 home country tie)
句子 3-4(約 40 words):具體佐證(家庭/財務/職涯具體細節)
句子 5-6(約 40 words):回國動機(具體且可信的理由)
句子 7(約 20 words):文件佐證引用(明確指向哪些附件)
最後 1 句(約 20 words):總結性聲明(正面、有力)

❌ 避免:
- 開頭用 "I am a genuine student" → 移民局看了無數次,毫無說服力
- 泛泛而談的未來計劃 → "I will use my skills in the future"
- 過多的感謝語和客套話 → 浪費字數

✅ 應該:
- 第一句就上最有力的事實 → "My parents operate a 15-year-old beauty salon chain in Beijing, employing 23 staff members..."
- 每個形容詞都配具體數字 → 不說 "strong financial support",說 "AUD 84,964 in savings"
- 引用具體文件 → "as evidenced in the attached bank statements (Jan-Mar 2025)"
```

---

## 11. 評分 Rubric 設計

### 11.1 自動評分系統

每份生成的 GS 在送給員工前,先由系統自動評分:

```python
class GSAutoScorer:
    
    def score_gs(self, generated_gs: str, student_json: dict) -> GSScore:
        
        scores = {}
        
        # === 維度 1:Direction 106 覆蓋度(30分)===
        d106_factors = [
            "home country circumstances",
            "ties to home country", 
            "reasons not studying locally",
            "economic circumstances",
            "value of course",
            "knowledge of course and provider",
            "immigration history",
            "future plans consistency"
        ]
        
        d106_score = self._check_factor_coverage(generated_gs, d106_factors)
        scores['direction_106_coverage'] = d106_score * 30
        
        # === 維度 2:具體性與可信度(25分)===
        specificity_indicators = {
            'has_specific_numbers': self._check_has_numbers(generated_gs),
            'has_specific_dates': self._check_has_dates(generated_gs),
            'has_document_references': self._check_has_doc_refs(generated_gs),
            'has_specific_location': self._check_has_locations(generated_gs),
            'avoids_generic_phrases': self._check_no_cliches(generated_gs)
        }
        specificity_score = sum(specificity_indicators.values()) / len(specificity_indicators)
        scores['specificity'] = specificity_score * 25
        
        # === 維度 3:一致性(20分)===
        # 檢查 GS 中的陳述是否與學生 JSON 一致
        consistency_checks = {
            'financial_amount_consistent': self._verify_financial_consistency(
                generated_gs, student_json
            ),
            'dates_consistent': self._verify_date_consistency(
                generated_gs, student_json
            ),
            'family_info_consistent': self._verify_family_info(
                generated_gs, student_json
            ),
            'course_info_accurate': self._verify_course_info(
                generated_gs, student_json
            )
        }
        consistency_score = sum(consistency_checks.values()) / len(consistency_checks)
        scores['consistency'] = consistency_score * 20
        
        # === 維度 4:150-word 合規(15分)===
        word_count_compliance = self._check_150_word_compliance(generated_gs)
        scores['word_count_compliance'] = word_count_compliance * 15
        
        # === 維度 5:風險標記(10分,扣分項)===
        risk_deductions = self._check_risk_phrases(generated_gs)
        scores['risk_penalty'] = -risk_deductions * 10
        
        total_score = sum(scores.values())
        
        return GSScore(
            total=total_score,
            breakdown=scores,
            auto_flags=self._generate_flags(scores, generated_gs),
            recommendation='approve' if total_score >= 75 else 'review' if total_score >= 55 else 'regenerate'
        )
    
    def _check_no_cliches(self, text:

```python
    def _check_no_cliches(self, text: str) -> float:
        """檢查是否使用了移民局已知的套話"""
        
        CLICHE_PHRASES = [
            "i am a genuine student",
            "i genuinely intend to study",
            "i will comply with all visa conditions",
            "i look forward to returning to my home country",
            "australia is a great place to study",
            "i have always dreamed of studying abroad",
            "i promise to abide by",
            "i sincerely hope",
            "i would like to take this opportunity",
            "needless to say",
            "as a genuine applicant"
        ]
        
        text_lower = text.lower()
        cliche_count = sum(1 for phrase in CLICHE_PHRASES if phrase in text_lower)
        
        # 0個套話 = 滿分,每多1個扣 0.15
        score = max(0.0, 1.0 - (cliche_count * 0.15))
        return score
    
    def _check_150_word_compliance(self, text: str) -> float:
        """檢查每題是否符合 150 word 限制"""
        
        # 提取各題答案
        questions = self._extract_question_answers(text)
        
        if not questions:
            return 0.5  # 無法解析時給中等分
        
        compliance_scores = []
        for q_num, answer in questions.items():
            word_count = len(answer.split())
            
            if word_count <= 150:
                compliance_scores.append(1.0)
            elif word_count <= 165:
                compliance_scores.append(0.7)  # 輕微超標
            elif word_count <= 180:
                compliance_scores.append(0.3)  # 明顯超標
            else:
                compliance_scores.append(0.0)  # 嚴重超標
        
        return sum(compliance_scores) / len(compliance_scores)
    
    def _check_risk_phrases(self, text: str) -> float:
        """檢查是否出現高風險表述"""
        
        HIGH_RISK_PATTERNS = [
            # 暗示移民意圖
            (r'(?i)(plan to (stay|remain|settle) in australia permanently)', 0.5),
            (r'(?i)(hope to get (pr|permanent residency|permanent resident))', 0.5),
            # 矛盾表述
            (r'(?i)(both study and work)', 0.2),
            # 無法核實的誇大
            (r'(?i)(world.class|world.renowned|best in the world)', 0.1),
            # 直接抄官網
            (r'(?i)(navitas english offers a range of)', 0.3),
        ]
        
        total_risk = 0.0
        for pattern, weight in HIGH_RISK_PATTERNS:
            if re.search(pattern, text):
                total_risk += weight
        
        return min(1.0, total_risk)
    
    def _generate_flags(self, scores: dict, text: str) -> List[AutoFlag]:
        """根據評分結果生成具體的員工提示"""
        
        flags = []
        
        if scores.get('direction_106_coverage', 100) < 18:
            flags.append(AutoFlag(
                level='WARNING',
                category='Direction 106',
                message='部分 Direction 106 評分因素未被充分覆蓋,建議員工補充以下面向:' + 
                        self._identify_missing_factors(text)
            ))
        
        if scores.get('specificity', 100) < 15:
            flags.append(AutoFlag(
                level='WARNING',
                category='Specificity',
                message='內容過於泛泛,缺乏具體數字/日期/文件引用,建議員工補充具體細節'
            ))
        
        if scores.get('consistency', 100) < 14:
            flags.append(AutoFlag(
                level='ERROR',
                category='Consistency',
                message='⚠️ 發現陳述與學生資料不一致,請員工務必核查後再提交'
            ))
        
        if scores.get('risk_penalty', 0) < -5:
            flags.append(AutoFlag(
                level='ERROR',
                category='Risk',
                message='⚠️ 發現高風險表述,可能引發移民官疑慮,建議重新生成或手動修改'
            ))
        
        return flags
```

### 11.2 員工評分介面設計

除了自動評分,員工在審核時按以下維度手動評分(1-5分),手動評分結果會回饋進案例庫:

```
【員工手動評分表】

生成版本:Claude Opus 4.6 版 / GPT-4o 版 / DeepSeek 版
生成時間:2025-07-15 10:32

評分維度(每項 1-5 分):

□ 1. 回國動機可信度
  1=完全不信 2=勉強 3=基本可信 4=較有說服力 5=非常有說服力
  備註:_______________

□ 2. 資金說明完整性
  1=嚴重缺失 2=部分缺失 3=基本完整 4=完整 5=非常詳盡且有力
  備註:_______________

□ 3. 課程選擇邏輯
  1=無說服力 2=牽強 3=合理 4=充分 5=非常有說服力
  備註:_______________

□ 4. 家庭/社會聯繫描述
  1=幾乎沒有 2=薄弱 3=一般 4=具體 5=非常具體且有力
  備註:_______________

□ 5. 英文表達流暢度
  1=很差 2=勉強 3=一般 4=良好 5=優秀
  備註:_______________

□ 6. 與學生實際情況吻合度
  1=大量不符 2=部分不符 3=基本吻合 4=吻合 5=完全吻合
  備註:_______________

□ 7. 整體提交信心
  1=肯定不提交 2=需大改 3=需小改 4=微調即可 5=可直接提交

最終決定:
○ 選用此版本(直接提交 / 微調後提交)
○ 放棄此版本
○ 合併多版本(說明合併哪些段落)

員工備註:
_________________________________________________
```

### 11.3 跨模型對比評分矩陣

員工在看完三個版本後,系統提供對比矩陣:

```
╔═══════════════════════════════════════════════════════════════╗
║                    GS 版本對比矩陣                              ║
║  學生:Chuhan WU  |  課程:Navitas General English              ║
╠═══════════════════╦══════════╦══════════╦══════════╦══════════╣
║ 評分維度           ║ Claude   ║  GPT-4o  ║ DeepSeek ║ 系統推薦  ║
╠═══════════════════╬══════════╬══════════╬══════════╬══════════╣
║ D106 覆蓋度        ║   27/30  ║   24/30  ║   21/30  ║  Claude  ║
║ 具體性             ║   22/25  ║   23/25  ║   18/25  ║  GPT-4o  ║
║ 一致性             ║   19/20  ║   18/20  ║   17/20  ║  Claude  ║
║ 150字合規          ║   15/15  ║   15/15  ║   12/15  ║  兩者均可 ║
║ 風險扣分           ║    0/10  ║   -2/10  ║    0/10  ║  Claude  ║
╠═══════════════════╬══════════╬══════════╬══════════╬══════════╣
║ 自動總分           ║   83/100 ║   78/100 ║   68/100 ║          ║
║ 自動評級           ║  ✅ 推薦 ║  ✅ 可用 ║  ⚠️ 審核 ║          ║
╠═══════════════════╬══════════╬══════════╬══════════╬══════════╣
║ 員工手動評分        ║   待填   ║   待填   ║   待填   ║          ║
║ 最終選定           ║    ○     ║    ○     ║    ○     ║          ║
╚═══════════════════╩══════════╩══════════╩══════════╩══════════╝

⚠️ 系統自動標記:
[WARNING] GPT-4o 版本 Q3 中使用了 "world-renowned provider",建議修改
[INFO] Claude 版本 Q1 未提及學生父親的具體職業,可補充加強
[INFO] DeepSeek 版本 Q2 對課程內容的描述與官網高度相似,建議員工改寫
```

---

## 12. 人類審核 Checklist

### 12.1 員工提交前強制核查清單

這個清單設計為系統強制流程——員工必須勾選完才能解鎖「匯出 Word」按鈕:

```
╔══════════════════════════════════════════════════════════════╗
║           GS 提交前強制核查清單(員工必須逐項確認)              ║
╠══════════════════════════════════════════════════════════════╣
║ SECTION A:事實核查(每項必須對照學生原始文件確認)              ║
╠══════════════════════════════════════════════════════════════╣
║ □ A1. 學生姓名拼寫與護照一致                                   ║
║ □ A2. 出生日期與護照一致                                       ║
║ □ A3. 課程名稱、院校名稱、地點完全正確                          ║
║ □ A4. 課程費用金額正確(對照 COE 或課程報價)                   ║
║ □ A5. 資金金額與銀行流水/存款證明一致                          ║
║ □ A6. 資金來源描述與學生提供的說明一致                         ║
║ □ A7. 學歷資料(學校名稱、畢業年份)與原件一致                  ║
║ □ A8. 家庭成員資訊(在澳/在中國)與 Form 500 一致              ║
║ □ A9. 工作經歷(如有)與勞動合同/在職證明一致                  ║
║ □ A10. 如有舊簽證記錄,GS 中的說明與事實完全一致               ║
╠══════════════════════════════════════════════════════════════╣
║ SECTION B:官方規範核查                                        ║
╠══════════════════════════════════════════════════════════════╣
║ □ B1. 所有 GS 內容為英文(無中文混入)                         ║
║ □ B2. 每題答案已確認 ≤ 150 words(逐題字數核查)               ║
║       Q1: ___ words  Q2: ___ words  Q3: ___ words             ║
║       Q4: ___ words  Q5: ___ words(如適用)                   ║
║ □ B3. 150-word 版本的語氣為第一人稱(I/My)                    ║
║ □ B4. Word 完整版結構完整(Summary + Detailed + Doc List)     ║
║ □ B5. 所有引用的支持文件確認學生已提供或正在準備                ║
╠══════════════════════════════════════════════════════════════╣
║ SECTION C:Direction 106 因素覆蓋確認                          ║
╠══════════════════════════════════════════════════════════════╣
║ □ C1. 家鄉聯繫(家庭、財產、工作)已清晰說明                   ║
║ □ C2. 回國動機具體且可信(非套話)                             ║
║ □ C3. 課程選擇理由已說明(為何是這個課程、這個院校、這個城市)  ║
║ □ C4. 課程對未來職涯的價值已具體說明(職涯路徑清晰)           ║
║ □ C5. 資金能力已充分說明(金額+來源+可持續性)                 ║
║ □ C6. 若有移民歷史,已在 Q5 正面、誠實地回應                   ║
╠══════════════════════════════════════════════════════════════╣
║ SECTION D:風險排查                                            ║
╠══════════════════════════════════════════════════════════════╣
║ □ D1. 無任何可被理解為「移民意圖」的表述                        ║
║ □ D2. 無法律上不允許的承諾或保證                               ║
║ □ D3. 無無法由文件佐證的聲明                                   ║
║ □ D4. 學生本人已閱讀並確認 GS 內容屬實(獲得學生書面確認)      ║
║ □ D5. 若自動評分有 ERROR 標記,已逐條處理或有理由說明           ║
╠══════════════════════════════════════════════════════════════╣
║ SECTION E:最終確認                                            ║
╠══════════════════════════════════════════════════════════════╣
║ □ E1. 選定的版本已記錄(Claude / GPT / DeepSeek / 混合)       ║
║ □ E2. 員工手動評分已完成並提交(用於系統學習)                  ║
║ □ E3. 如有特殊情況,已在系統備註欄記錄                         ║
║                                                                ║
║ 員工簽名確認:____________  日期:____________                 ║
╚══════════════════════════════════════════════════════════════╝
```

### 12.2 資深員工二次審核觸發條件

以下任何一個條件觸發,系統自動要求資深員工或主管進行二次審核:

```python
SENIOR_REVIEW_TRIGGERS = [
    # 技術觸發
    ('auto_score_below_60', '自動評分低於 60 分'),
    ('consistency_error_detected', '系統偵測到資料不一致'),
    ('risk_flag_detected', '偵測到高風險表述'),
    
    # 學生特徵觸發
    ('prior_visa_refusal', '學生曾有簽證拒簽記錄'),
    ('prior_student_visa', '學生曾持有澳洲學生簽證'),
    ('applying_from_australia', '學生在澳洲境內申請'),
    ('course_unrelated_to_background', '課程與學業背景明顯不相關'),
    ('high_risk_nationality', '高拒簽率國籍組合'),
    ('large_fund_amount', '資金金額超過 AUD 150,000(需額外核查來源)'),
    ('minor_applicant', '申請人為未成年人'),
    
    # 業務觸發
    ('vip_student', 'VIP 學生帳戶'),
    ('first_time_employee', '員工首次使用系統(前10份需監督)'),
    ('unusual_course_duration', '課程長度異常(超過 24 個月或少於 4 週)'),
]
```

---

## 13. MVP / V1 / V2 路線圖

### 13.1 MVP(第 0-4 週):核心閉環,快速驗證

**目標**:證明「AI 生成 GS 品質可達到或超過人力外包」,完成第一個真實案例的端到端閉環。

**技術範圍**:

```
✅ 納入 MVP:
- Google Drive 資料夾讀取(PDF + DOCX)
- 基礎 OCR(PyMuPDF + python-docx)
- Student Data Extractor(用 GPT-4o mini 提取結構化 JSON)
- 單一模型生成(Claude Opus 優先)
- 固定 System Prompt(手動精煉,不用 RAG)
- 少量固定 Few-shot(2-3 個手動精選的成功案例,硬編碼在 Prompt 中)
- 基礎 Web UI(Next.js 或 Streamlit 快速搭建)
- Word 文件輸出(python-docx)
- 基礎安全(HTTPS + 員工登錄 + Audit log)

❌ MVP 先不做:
- 多模型並行
- RAG 向量庫(先用 hardcoded few-shot)
- 自動評分系統
- 法令自動監控
- 失敗案例分析
- 複雜的 UI
```

**MVP 驗收標準**:
```
1. 員工可在 10 分鐘內完成一份學生 GS 的輸入和生成
2. 生成的 150-word 版本每題字數不超過 150 words(自動驗證)
3. 至少 3 位員工盲測評分,AI 版本平均分達到目前外包版本的 85% 以上
4. 第一批 5 個真實學生案例全部成功提交(員工確認可提交品質)
```

**MVP 技術棧(刻意精簡)**:
```
後端:Python FastAPI
前端:Next.js(或 Streamlit 更快)
資料庫:PostgreSQL(單一 DB,不用向量庫)
文件處理:PyMuPDF + python-docx
LLM:Claude API(先單一模型)
部署:單台 VPS 或 Railway.app(快速)
檔案存儲:本地加密存儲(MVP 先不用 S3)
```

**MVP 估計工時**:
```
Week 1: Google Drive 讀取 + OCR + Student Data Extractor(2人・5天)
Week 2: Prompt 設計 + Claude API 整合 + Word 輸出(2人・5天)
Week 3: 基礎 Web UI + 員工登錄 + Audit log(1人・5天)
Week 4: 內部測試 + Prompt 精煉 + 真實案例驗收(全員・5天)
總計:約 4 週,2-3 名開發人員
```

---

### 13.2 V1(第 5-12 週):多模型 + 知識庫 + 評分系統

**目標**:建立可持續學習的知識庫,引入多模型對比,讓系統品質持續提升。

**新增功能**:

```
Week 5-6:知識庫建設
  ✅ 向量庫整合(Qdrant 或 Pinecone)
  ✅ 歷史成功案例向量化(從 MVP 積累的案例 + 歷史案例遷移)
  ✅ 失敗案例 + 拒簽信結構化入庫
  ✅ RAG 查詢模組(替換 hardcoded few-shot)
  ✅ 政策文件向量化(Direction 106 + GS Requirement 官方頁面)

Week 7-8:多模型並行
  ✅ GPT-4o 整合
  ✅ DeepSeek V3 整合
  ✅ 並行調用 + 結果彙整
  ✅ 多版本對比 UI(並排顯示 + 差異高亮)
  ✅ 版本選擇與合併功能

Week 9-10:自動評分系統
  ✅ Auto Scorer(Direction 106 覆蓋度 + 具體性 + 一致性)
  ✅ 員工手動評分表(回饋給案例庫)
  ✅ 對比矩陣 UI
  ✅ 強制 Checklist(解鎖匯出按鈕)

Week 11-12:法令監控 + 安全強化
  ✅ 政策頁面每日 hash 比對
  ✅ 資料 Redaction 模組
  ✅ 資料生命週期管理(TTL + 安全刪除)
  ✅ 資深員工二次審核觸發機制
  ✅ 完整 Audit Trail
```

**V1 驗收標準**:
```
1. 三模型並行生成,員工選用最佳版本,整體滿意度 ≥ 90%
2. 自動評分與員工評分相關性 ≥ 0.75(Pearson correlation)
3. 案例庫達到 ≥ 30 個成功案例(向量化完成)
4. 法令監控系統成功偵測至少一次政策更新(可模擬測試)
5. 資料安全審計通過(無 PII 洩漏至 LLM API)
```

---

### 13.3 V2(第 13-20 週):智能化 + 自動化 + 品質飛輪

**目標**:從「輔助工具」進化為「學習型系統」,品質隨案例積累持續提升,並向其他簽證類型延伸。

**新增功能**:

```
Week 13-14:簽證結果回饋閉環
  ✅ 簽證結果記錄模組(員工更新結果:批准/拒簽)
  ✅ 拒簽信自動解析(提取拒絕原因 + 對應 GS 弱點)
  ✅ 自動更新禁忌表述清單
  ✅ 案例品質分數動態更新
  ✅ 周報:本週成功率 / 失敗率 / 最常見問題

Week 15-16:智能建議功能
  ✅ 學生風險預評估(提交 Google Drive 連結後,
     先輸出「風險報告」再生成 GS)
  ✅ 缺失文件自動偵測(「您的資料缺少銀行流水,建議補充後再生成」)
  ✅ 個性化撰寫建議(「根據此學生特徵,建議重點強調 X,弱化 Y」)

Week 17-18:Prompt 自動優化
  ✅ A/B 測試框架(同一學生,不同 Prompt 版本,追蹤最終結果)
  ✅ 基於成功率的 Prompt 版本管理
  ✅ 自動識別「哪種描述框架對中國學生最有效」

Week 19-20:擴展與整合
  ✅ Gemini + Google Drive 原生整合
     (讓 Gemini 直接讀取 Drive 文件,無需下載)
  ✅ 本地 LLM 選項(Ollama + Llama 3,用於敏感文件處理步驟)
  ✅ API 版本(供前台 CRM 系統調用)
  ✅ 初步支援其他簽證類型框架(如工作假期、技術移民 EOI)
```

**V2 驗收標準**:
```
1. 系統追蹤的案例簽證批准率 ≥ 公司歷史平均批准率
2. 拒簽後,系統能自動識別拒絕原因並對應到 GS 弱點(準確率 ≥ 70%)
3. 員工平均每份 GS 處理時間(含審核)≤ 20 分鐘
4. 案例庫達到 ≥ 100 個有簽證結果的案例
5. 系統正常運行率 ≥ 99.5%(每月最多 3.6 小時停機)
```

---

## 14. 最終架構總覽

### 14.1 完整系統架構(生產級)

```
┌─────────────────────────────────────────────────────────────────────┐
│                         員工前端(Next.js)                            │
│                                                                       │
│  [案例儀表板] [新建 GS 任務] [知識庫管理] [案例結果更新] [系統設定]      │
│                                                                       │
│  新建 GS 任務流程:                                                    │
│  ① 貼入 Google Drive 連結                                             │
│  ② 系統自動偵測文件並顯示「文件清單 + 缺失項目警告」                     │
│  ③ 員工填入撰寫方向備註                                                │
│  ④ 系統顯示「風險預評估報告」(可選擇繼續或先補齊文件)                  │
│  ⑤ 點擊「生成 GS」→ 3 個版本並行生成(進度條顯示)                     │
│  ⑥ 三版本對比矩陣 + 自動評分 + 差異高亮                                │
│  ⑦ 員工選版本 + 填寫手動評分 + 完成 Checklist                          │
│  ⑧ 解鎖「匯出 Word」→ 下載最終文件                                     │
│  ⑨ 記錄案例(日後更新簽證結果)                                         │
└─────────────────────────┬───────────────────────────────────────────┘
                           │ HTTPS
┌─────────────────────────▼───────────────────────────────────────────┐
│                    API Gateway(FastAPI)                              │
│                                                                       │
│  路由:                                                               │
│  POST /api/tasks/create          → 建立新任務                         │
│  POST /api/tasks/{id}/ingest     → 觸發文件擷取                       │
│  GET  /api/tasks/{id}/risk       → 風險評估報告                       │
│  POST /api/tasks/{id}/generate   → 觸發多模型生成                     │
│  GET  /api/tasks/{id}/results    → 取得生成結果 + 評分                │
│  POST /api/tasks/{id}/finalize   → 員工選版本 + 評分回饋               │
│  GET  /api/tasks/{id}/export     → 匯出 Word                         │
│  POST /api/cases/{id}/outcome    → 更新簽證結果                       │
│  POST /api/kb/add                → 手動新增知識庫條目                  │
│  GET  /api/policy/status         → 政策監控狀態                       │
│                                                                       │
│  中間件:                                                              │
│  - JWT 認證 + 角色權限(employee / senior / admin)                    │
│  - Rate Limiting(防止意外大量調用 API 產生費用)                       │
│  - 請求 / 回應日誌(不記錄學生原始資料)                                │
└──────┬──────────────┬──────────────┬────────────────────────────────┘
       │              │              │
       ▼              ▼              ▼
┌─────────────┐ ┌───────────┐ ┌────────────────────────────────────┐
│  文件處理層  │ │ 生成引擎   │ │          知識庫層                   │
│             │ │           │ │                                    │
│ Google      │ │ Prompt    │ │ PostgreSQL                         │
│ Drive API   │ │ Builder   │ │ - students                         │
│     ↓       │ │     ↓     │ │ - gs_tasks                         │
│ File        │ │ Claude    │ │ - gs_cases                         │
│ Downloader  │ │ API       │ │ - gs_results                       │
│     ↓       │ │     ↓     │ │ - policy_versions                  │
│ OCR         │ │ OpenAI    │ │ - employee_actions                 │
│ (PyMuPDF)   │ │ API       │ │                                    │
│     ↓       │ │     ↓     │ │ Qdrant (Vector DB)                 │
│ Data        │ │ DeepSeek  │ │ - success_cases_embeddings         │
│ Extractor   │ │ API       │ │ - failure_cases_embeddings         │
│ (→ JSON)    │ │     ↓     │ │ - policy_embeddings                │
│     ↓       │ │ Gemini    │ │ - writing_tips_embeddings          │
│ Redactor    │ │ API       │ │                                    │
│             │ │     ↓     │ │ File Storage (加密)                │
│             │ │ Result    │ │ - 原始文件(TTL 90天)              │
│             │ │ Aggregator│ │ - 生成結果(TTL 730天)             │
└─────────────┘ └───────────┘ └────────────────────────────────────┘
       │              │              │
       └──────────────┴──────────────┘
                      │
┌─────────────────────▼───────────────────────────────────────────────┐
│                   背景服務(Celery + Redis)                            │
│                                                                       │
│  定時任務:                                                            │
│  - 每日 02:00: PolicyMonitor.daily_check()(政策頁面監控)             │
│  - 每日 03:00: DataLifecycleManager.cleanup_expired()(清除過期文件)  │
│  - 每週日: KnowledgeBase.reindex_all()(重新向量化知識庫)             │
│  - 每月: PerformanceReport.generate()(生成系統效能報告)              │
│                                                                       │
│  非同步任務:                                                          │
│  - 多模型並行生成(避免 HTTP timeout)                                  │
│  - 大文件 OCR 處理                                                     │
│  - 案例結果更新後的 KB 重新索引                                         │
└─────────────────────────────────────────────────────────────────────┘
```

### 14.2 資料流程圖(一份 GS 的完整生命週期)

```
員工輸入 Google Drive 連結
        ↓
[文件擷取] Google Drive API 下載所有文件
        ↓
[OCR & 解析] PDF → 文字,DOCX → 文字,圖片 → 略過(僅記錄有照片)
        ↓
[資料提取] GPT-4o mini 將非結構化文件轉為 Student JSON
        ↓
[資料遮蔽] Redactor 遮蔽護照號/銀行帳號等識別符
        ↓
[風險評估] 比對失敗案例特徵向量 → 輸出風險報告
        ↓
[員工確認] 員工查看風險報告,填入撰寫方向備註
        ↓
[RAG 召回] 根據學生特徵召回:
          - 3個相似成功案例段落
          - 2個相似失敗案例警告
          - 相關法令條文
          - 相關撰寫技巧
        ↓
[Prompt 組裝] System Prompt + RAG 結果 + Student JSON + Task Instruction
        ↓
[並行生成] Claude | GPT-4o | DeepSeek 同時生成(Celery 非同步)
        ↓
[自動評分] Auto Scorer 對三個版本評分
        ↓
[還原遮蔽] Redactor.restore() 還原真實資訊到生成結果
        ↓
[員工審核] 查看三版本對比矩陣,完成手動評分和 Checklist
        ↓
[選定版本] 員工選定最佳版本(或合併)
        ↓
[Word 生成] python-docx 生成格式化 Word 文件(含院校 Logo 等格式)
        ↓
[記錄入庫] 任務記錄、員工評分、選用版本記錄進 PostgreSQL
        ↓
[向量化] 新案例加入知識庫(暫標記為 pending,待簽證結果出來後升級)
        ↓
員工下載 Word 文件,提交至 ImmiAccount

        ↓(數週後)
        
[結果更新] 員工在系統記錄簽證結果(批准/拒簽)
        ↓
[知識庫更新] 
  若批准 → 案例升級為 success,quality_score +2,重新向量化
  若拒簽 → 解析拒簽信,提取弱點,加入 failure_cases,更新禁忌清單
        ↓
[品質飛輪] 下一份 GS 的 RAG 召回會更準確
```

### 14.3 技術棧總結

```
層次         技術選型                    理由

前端         Next.js 14 (App Router)    React 生態,部署簡單,TypeScript 支援
後端         Python FastAPI             LLM SDK 生態最好,非同步支援好
任務佇列     Celery + Redis             多模型並行生成的標準方案
主資料庫     PostgreSQL 16              穩定可靠,JSON 欄位支援好
向量資料庫   Qdrant (self-hosted)       開源,自部署(資料不出境),效能好
文件處理     PyMuPDF + python-docx      成熟的 PDF/DOCX 處理庫
OCR          PyMuPDF 內建 + 可選 Azure DI 複雜掃描件可升級至 Azure Document Intelligence
Word 生成    python-docx                程式化生成 Word,支援格式控制
LLM SDK      anthropic + openai + httpx 各供應商官方 SDK
Embedding    text-embedding-3-large     或 Cohere embed-v3
加密         cryptography (AES-256)     文件落地加密
部署         Docker Compose → K8s        從簡單到可擴展
監控         Sentry + Grafana           錯誤追蹤 + 效能監控
```

### 14.4 最後的關鍵建議

在結束前,有幾點架構層面的強烈建議:

**第一:Student JSON 是神聖的**

整個系統的品質上限由 Student Data Extractor 的準確性決定。如果 JSON 提取錯誤(例如資金金額抓錯),後面所有模型都會生成錯誤的 GS。建議:

```
對 Student JSON 的所有金融數字欄位,
增加一個「人工確認步驟」——在生成 GS 之前,
先把 JSON 的關鍵欄位以清單形式展示給員工確認:

「系統解讀的學生資料如下,請確認無誤後再生成:
- 資金總額:AUD 84,964
- 資金來源:父母儲蓄 + 銀行存款
- 課程:Navitas General English, Melbourne, 24 weeks
...
[確認正確,開始生成] [有誤,手動修正]」
```

**第二:不要在 MVP 階段就做 RAG,先用 Hardcoded Few-shot**

RAG 的好處在案例庫達到 30-50 個以上才真正體現。在 MVP 階段,用 2-3 個手動精選的成功案例硬編碼在 Prompt 裡,效果往往比品質參差的 RAG 更穩定。等 V1 案例庫建立後,再切換為 RAG。

**第三:150-word 版本是核心 KPI,Word 完整版是加分項**

所有的 Prompt 設計、評分 Rubric、員工 Checklist,都應以「150-word 版本的品質」為最優先指標。Word 完整版是重要的補充材料,但移民官首先審核的是表格答案。

**第四:每份 GS 的生成成本要顯示給員工**

在介面上顯示本次生成的 API 成本(如:Claude $0.68 + GPT $0.10 + DeepSeek $0.01 = $0.79 USD)。這有兩個好處:一是讓員工有成本意識,不會無謂地反覆生成;二是讓管理層清晰看到 ROI。

**第五:政策更新時,立即暫停服務**

Direction 106 如果有重大更新,繼續使用舊 Prompt 生成的 GS 可能反而有害。在政策監控系統偵測到重大更新後,應自動觸發「安全停機」——暫停新 GS 任務,直到管理員確認新政策並更新 System Prompt 後才恢復。這是整個系統中最重要的合規保護機制。

---

*本架構文件版本:v1.0 | 適用政策:Direction No. 106(2024-03-23 起) | 建議每季審查*
📊 Token:输入 19065 / 输出 26832 | 费用:$0.459675 | 耗时:390078ms | finish_reason:stop | 续写:1
第二輪:最快 MVP 上線方案:完整 Prompt 與 AI 回覆
Round 2 - DeepSeek V4 Pro deepseek-v4-pro · 0.00904017 USD

Prompt

你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。

【背景】
我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。

【目前重要現實】
我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。

真正痛點不是模型不會寫,而是:
1. 其他公司同事無法穩定有效使用最新模型。
2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。
3. 公司希望把流程統一化,交給少數有權限人員。
4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。
5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。

【上一輪多模型與 Codex 綜合結論】
完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。

【但這一輪我要你回答的問題是:最快能上線方案】
請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:

1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?
2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?
3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?
4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?
5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?
6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。
7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。
8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。
9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。
10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。
11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。
12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。
13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。
14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。
15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?

請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。

AI Reply

【DEEPSEEK-V4-PRO · deepseek-v4-pro】
好的,以下是針對你各項問題,以「最快能上線」為核心的具體實務方案。完全繞開重架構,只做能讓少數人在 7-10 個工作天內穩定產出 99% 可用 GS 的工具。

---

## 1. 最快上線方案(1-2 週,少數人可用)

做一個 **「Streamlit 內部工具」**,流程極簡:

員工貼入學生 Google Drive 資料夾的「公開分享連結」,可選填一句顧問方向→點擊「產生 GS」→ 系統下載所有檔案、抽出文字、組裝世界級 prompt → 同時打給 **GPT-4o** 和 **Claude 3.5 Sonnet**(用 API)→ 拿到兩份 Markdown → 分別轉成 Word → 畫面出現兩個下載鍵,員工比較、選一份人工審核送出。

背後的所有「知識」都寫死在 **System Prompt(固定知識包)** 中,不做 RAG、不做向量資料庫、不做知識庫動態檢索。完全是把你現在「在網頁版能點出 99 分 GS」的流程,用程式自動把檔案餵進去、把答案吐成 Word。

---

## 2. 不做 RAG/向量庫/微調的可行性與風險控制

### 可行性:完全可行
你已經實證過:在乾淨的 session、丟進規範+範例+所有學生文件,模型就能產出高品質 GS。  
現在只是把「人工貼檔案內容」換成程式下載+抽文字,本質沒變。這就代表 **知識不是靠外部檢索,而是靠 prompt 內的固定知識包**。

### 風險怎麼控
| 風險 | 控制方式 |
|---|---|
| 文件太長超過 context window | 每份文件給一個 token 上限,優先保留關鍵文件(Form500、CoE、護照、財力摘要),課程手冊等非必要者只取前 1500 字或直接省略,並在 prompt 中標注「以下文件因長度未完整納入」 |
| 學生資料外洩給模型供應商 | 使用官方 API(OpenAI / Anthropic)並 **關閉訓練使用**(API 預設就不會拿來訓練,但仍需在帳號設定中確認),可視為與你現在貼上網頁版同級風險 |
| 模型幻覺、編造經歷 | 透過「引用來源強制+自檢區塊+低溫度」與最終人工審核三道防線處理(詳見第 8 點) |
| 沒做 OCR 照片/掃描件資訊遺漏 | 系統會列出「未成功抽出文字」的檔案清單,要求人員手動補入關鍵欄位(如護照號碼、存款金額)後才能進下一步 |

---

## 3. 固定知識包應包含什麼?Token 會太大嗎?如何控制

直接把下面這些寫死在 System Prompt:
1. **Direction No. 106 重點摘要**(約 700 tokens)
2. **ImmiAccount GS 六大題目原文+每題 150 字限制+官方評分偏好**(約 400 tokens)
3. **公司內部 GS 高級寫作技巧**(如何把證據自然融入、如何寫回國計畫、如何處理空窗期、轉領域解釋等)(約 500 tokens)
4. **2-3 份已脫敏、極高品質的真實 GS 範例**(每份摘要到約 400 tokens,合計 1200 tokens)
5. **輸出結構與格式要求**(含自檢清單、引用來源格式)(約 300 tokens)

總計約 **3000-3500 tokens**,加上學生文件文字平均約 4000-8000 tokens(只放關鍵文件),總輸入通常落在 **8k-12k tokens**,以 GPT-4o 128k 或 Claude 200k 來說極度安全,成本也極低。

若要再壓,可以把範例只放 2 份或把技巧濃縮,但現階段不用,維持品質。

---

## 4. Google Drive 開放連結最簡單接入方式

### 最快做法
- **技術**:Google Drive API + Service Account
- 員工拿到學生的「知道連結的人可檢視」資料夾網址,直接貼進 Streamlit
- 系統用 Service Account 模擬「任何人」下載(若權限不夠,要求學生把該 SA 的 email 加入共用對象)
- 不自己做 OAuth 流程,完全省事

### 檔案結構:建議先半強制,再容錯
**最穩:規定命名規則**  
讓學生/顧問將檔案分類放進子資料夾,名稱固定:
```
/01_Form500
/02_Passport
/03_Finance
/04_Course
/05_Photos
/06_Other
```
沒有子資料夾也沒關係:系統可以根據檔名關鍵字自動分類,例如:
- 含 `passport` → 護照
- 含 `form500` / `application` → Form 500
- 含 `coe` / `ecoe` / `confirmation` → CoE
- 含 `bank` / `financial` / `sponsor` → 財務
- 其餘歸 `other`

**容錯機制**:在畫面中顯示「系統辨識出的檔案分類清單」,讓人員看一眼、勾掉不對的,再點「確認後產生」。這一步就夠了,不必做成全自動。

---

## 5. 文件解析的最快 MVP 策略(分兩期)

| 階段 | 範圍 | 工具 |
|---|---|---|
| **第 1 週 MVP** | 只處理「原生文字檔」:PDF 有文字層、DOCX、TXT | `pdfplumber`(或 `PyMuPDF`)+ `python-docx` |
| **第 2 週起強化** | 圖片型 PDF(掃描件)、JPG/PNG 照片 | 先用 Google Cloud Vision 或 Azure Document Intelligence 做 OCR,僅針對「被標記為掃描件且關鍵文件」才調用 |

第一週面對掃描件:系統偵測不到文字時,就顯示「可能為掃描件,請人工輸入以下關鍵資訊:護照全名、護照號碼、生日…」,並把這些人工補入的欄位直接併入後續 prompt 的「學生事實」。不為少數案例卡住上線時間。

---

## 6. 「完整 GS Word」模板設計(兼顧官方 150 字與內部需求)

**Word 架構如下(由模型一次生成全內容,分段明確)**

| 區塊 | 內容 | 備註 |
|---|---|---|
| **Cover Page** | 學生姓名、課程、CoE ID、生成日期、使用模型、`DRAFT – NOT FOR SUBMISSION` 浮水印 | 一眼防誤送 |
| **1. Case Summary** | 基本背景、學校、課程、動機一句總結、最高風險點點出 | 讓審核者 60 秒內理解全貌 |
| **2. Official GS Answers (150 words each)** | 針對每一題寫出 **嚴格≤150 字** 的答案,並在段落中自然嵌入證據引用(如“As shown in my father’s bank statement of $XX…”) | 這是你日後貼進 ImmiAccount 的主體 |
| **3. Detailed Explanations (Internal)** | 每題的長版說明,補充更多背景、邏輯、法規適用,無字數限制 | 給審核顧問深度理解與修改依據 |
| **4. Risk Assessment Notes** | 基於 Direction 106 的 risk factors,點出此案弱點與可行解方(如轉領域、空窗期、沒放財力證明等) | 內部決策用,不對外 |
| **5. Evidence Checklist** | 已提供檔案清單、對應證據強度、建議補件清單 | 一目瞭然 |
| **6. Appendix: Key Source Excerpts** | 貼上關鍵文件的原文片段(如 CoE、財力、過往簽證頁) | 供人員快速核對事實 |
| **7. Photo Appendix** | 若照片有文字(如身分證、戶籍)且被抽出,放截圖;否則留空或附上照片檔名清單 | MVP 先放檔名清單即可 |

**格式**:模型輸出一份完整 Markdown,後端用 `pandoc` 或 python-docx 模板直接套入,轉成一份 Word。所有粗體、標題、項目符號都能保留。

---

## 7. 多模型生成最快具體做法

一個原則:**每個模型產出一份 Word,不混成一份**。

具體做法:
1. 同時(用 `asyncio`)呼叫兩個 API:
   - `openai.ChatCompletion.create`(model=`gpt-4o`)
   - `anthropic.Messages.create`(model=`claude-3-5-sonnet-20241022`)
2. 兩個 request 的 `messages` 相同(同一份 system prompt + 同一份學生事實 user message)
3. 兩者都要求輸出 **Markdown**(不是 JSON),並遵循同一個章節模板
4. 收到後端回傳的字串
5. 用 `pandoc` 將兩份 Markdown 分別轉為 `.docx`(或直接用 `docx` library 生成)
6. Streamlit 介面顯示「GPT-4o 生成完成」「Claude 生成完成」,各附一個下載按鈕

這樣員工只要比較兩份 Word,選一份最順眼的再人工微調即可。

---

## 8. 不做完整 RAG 的防幻覺與防法規過期機制

| 防線 | 方法 |
|---|---|
| **Prompt 強制來源引用** | 要求模型「每個事實句末標註來源檔案簡稱,如 (CoE, p.1);若無來源,請寫 (Not in documents)」 |
| **自我檢查區塊** | 輸出要求包含一段「Self-Check Report」,逐條檢查人事時地物是否有文件對應,並對信心不足處標記 `[UNCERTAIN]` |
| **低溫度** | 設 temperature=0.2,大幅降低創造力 |
| **硬規則忽略非文件內容** | System prompt 明定:**"You are forbidden from using any knowledge outside the documents provided below. If you are uncertain, state it clearly."** |
| **法規時間戳** | 在固定知識包第一句寫:「Current as of 2024-03-23, Direction No. 106」,提醒模型與審核者 |
| **重要提示放入 Word** | 封面頁加警語:「此文件由 AI 生成,請務必核對所有宣稱與證據文件一致。法規請以 Home Affairs 官網為準。」 |
| **終極防線** | 所有文件產出後,由有經驗的簽證顧問人工核對,這是目前法律上唯一真正有效的防線;工具只是消除 90% 的機械式寫作工作 |

---

## 9. 最簡單可維護的操作介面比較與推薦

| 方案 | 結論 |
|---|---|
| **Streamlit** | ✅ **最推薦**。一個 `.py` 就能做出網頁 UI,內建檔案下載、按鈕、進度條,支援 `asyncio` 調 API,部署只需 `streamlit run`,可放內部 VM 或 Streamlit Cloud |
| Google Sheet + Apps Script | ❌ Apps Script 有 6 分鐘執行限制,無法處理多個 API 呼叫與檔案下載轉換,不適合 |
| n8n/Zapier/Make | ❌ 適合排程自動化,但人員互動差,要比較兩個模型、輸入方向、預覽檔案清單都不好做 |
| Next.js 小工具 | 可以做,但需要前後端分離,開發速度遠慢於 Streamlit |
| CLI / 桌面工具 | 對非技術員工極不友善,直接淘汰 |

**結論**:Streamlit 一個頁面,後端全 Python,前後端一體,單人可一天完成基礎原型。

---

## 10. 最快 MVP 完整工作流(使用者 + 系統 + 輸出 + 審核)

**使用者步驟**
1. 打開內部 Streamlit 網頁(可設簡易密碼)
2. 貼上學生 Google Drive 資料夾分享連結
3. (可選)輸入顧問指導方向,例如“學生轉領域,需強調如何從金融轉 IT”
4. 點「Analyze Files」
5. 系統顯示偵測到的檔案清單與類型,員工確認無誤
6. 點「Generate GS Answers」
7. 等待約 30-60 秒,畫面出現兩顆下載鈕(GPT-4o / Claude)
8. 下載兩份 Word,打開比較,選一份加工
9. 最終顧問簽核後,人工貼入 ImmiAccount

**系統步驟 (自動)**
- 取得 Google Drive 權限,遞迴下載所有檔案到暫存記憶體
- 依檔名分類,用 pdfplumber + python-docx 抽文字
- 將文字組裝成標準化 User Prompt(含每份文件名、分類、內容摘要)
- 組合 System Prompt(固定知識包)
- 同時呼叫 OpenAI 與 Anthropic API(timeout 60s)
- 取得兩份 Markdown
- 用 pandoc 轉 `.docx`(或 python-docx 模板)
- 回應前端兩個下載連結

**輸出物**
- 每位學生每次產生兩份 Word(可再加日期戳記、模型名稱)
- 系統可選擇另存一份純文字紀錄檔供日後改善 prompt

**審核步驟**
- 員工打開 Word,逐區確認
- 重點查:官方答案是否超過 150 字、是否有文件佐證、是否編造經歷
- 修改後另存定稿,再貼入 ImmiAccount
- 無需系統內建繁瑣審計,MVP 階段信任人工

---

## 11. 1-2 週落地計畫(每日工作清單)

假設一人開發(熟 Python + Streamlit + API)

| 日期 | 工作內容 | 交付物 |
|---|---|---|
| **Day 1** | 申請 Google Service Account、測試 Drive API 下載;建 Streamlit 骨架,能輸入網址並列出檔案名稱 | 可列出檔案清單的網頁原型 |
| **Day 2** | 加入 pdfplumber + python-docx 文字抽取;顯示抽取字數、成功/失敗檔案 | 抽完文字的除錯頁面 |
| **Day 3** | 設計固定知識包 prompt 與 user prompt 模板;呼叫第一個模型(例如 GPT-4o)取得 Markdown | 第一個端到端生成結果(純文字) |
| **Day 4** | 串接第二個模型(Claude);實作 Markdown 轉 Word(pandoc);基本錯誤處理 | 兩份可下載的 Word(草案) |
| **Day 5** | UI 完整化:進度條、兩顆下載鈕、檔案確認介面、顧問方向輸入、錯誤提醒 | 內部可試用版 |
| **Day 6** | 內部用 3-5 個真實案子測試,調整 prompt、分類邏輯、token 截斷規則 | 穩定產出與人工產出品質接近的版本 |
| **Day 7** | 加入掃描件偵測與手動補資訊表單;封面頁警語 + DRAFT 浮水印;簡易密碼保護 | 具基本安全防護的 beta 版 |
| **Day 8-9** | 根據使用者回饋調整 prompt(特別是 150 字限制與引用格式);補文件類型例外處理 | V1.0 正式上線 |
| **Day 10-12** | 教育訓練、撰寫使用手冊、討論下一階段(OCR、RAG、評分儀表板) | 收尾與規劃 v2 |

**先不要做的功能**:
- 自動判斷簽證風險分數
- OCR 全面掃描件處理
- 資料庫儲存學生檔案(先只用檔案系統與暫存)
- 學生端介面
- 全自動提交 ImmiAccount(極度危險)

---

## 12. 成本估算(每案 + 工程 + 維護)

### 單一案件 API 成本
- 假設平均輸入 10,000 tokens(含知識包 3,000 + 學生文件 7,000)
- 輸出約 2,500 tokens(整份 GS 含長版)

| 模型 | 輸入價格 (USD/1M tokens) | 輸出價格 | 本案成本 |
|---|---|---|---|
| GPT-4o | $5.00 | $15.00 | $0.05 + $0.0375 ≈ **$0.0875** |
| Claude 3.5 Sonnet | $3.00 | $15.00 | $0.03 + $0.0375 ≈ **$0.0675** |
| **兩模型合計** | | | **≈ US$0.155 → 約 AUD 0.24** |

對比 **外包 AUD 100-200**,成本差異極大。就算你單案多跑幾次實驗,成本仍可忽略。

### 工程成本
- 1 人 × 2 週約 AUD 4,500-5,000(含 overhead)
- 一次性建置

### 維護成本
- 伺服器:可放公司內部 PC 或雲端最小 VM,月費約 AUD 50-100
- 固定知識包每月更新一次(1-2 小時)
- API key 管理、模型版更,極低

單案邊際成本接近零,投資約兩週內回收。

---

## 13. 最容易踩雷的 20 個問題與對策(簡潔版)

| # | 問題 | 對策 |
|---|---|---|
| 1 | 學生個資外洩給 OpenAI/Anthropic | 使用 API 並關閉訓練;隱私風險與你貼上網頁版相同 |
| 2 | Google Drive 權限不足無法下載 | 提示使用者確認共用設定,或直接上傳 ZIP 作為備援 |
| 3 | 檔案命名混亂導致錯誤分類 | 清單預覽供人工確認,並可拖曳修正 |
| 4 | 圖片/掃描件文字遺漏 | 標記「無文字」並要求手動輸入關鍵資訊 |
| 5 | 財力文件只放截圖 | 同上,手動輸入金額與持有人 |
| 6 | 模型輸出超過 150 字 | Prompt 強調限制,後端用正則截斷並加警語 |
| 7 | 模型編造不存在的工作經歷 | 要求「未提供則寫 not indicated」,並自檢 |
| 8 | 引用文件頁碼錯誤 | 不要求頁碼,只求檔案名,降低難度 |
| 9 | Word 排版跑版 | 使用 pandoc 標準範本,或直接用 docx 模板填空 |
| 10 | 知識包過期 | 每月人工更新日期與法條,並在 prompt 中標版本 |
| 11 | 員工直接提交未審版 | Word 封面大字「DRAFT」及每頁浮水印 |
| 12 | 模型引用不相關法條 | System prompt 禁止引用非 Direction 106 之內容 |
| 13 | 多模型結果同質性太高 | 沒關係,讓人工選較佳者,不失為一種驗證 |
| 14 | 非英文文件無法處理 | 先標記,要求人工翻譯後再生成 |
| 15 | 超長文件塞爆 prompt | 對每份文件設定字數上限,非關鍵者最多 1,500 tokens |
| 16 | 同一學生多次生成版本混亂 | 檔案名加入 timestamp,如 `GS_GPT4o_20250321.docx` |
| 17 | 介面無權限控管 | Streamlit 加上簡易密碼或內部 IP 白名單 |
| 18 | 照片中的臉部生物特徵隱私 | 照片不送入 API,僅檔名記錄;若有 OCR 需求只送必要區塊 |
| 19 | 顧問方向太多干擾模型 | 限制方向輸入最多 300 字,並放在 prompt 最末 |
| 20 | 系統不記錄生成內容,遇問題無法回溯 | MVP 可選擇將 prompt + 輸出存成純文字 log,備查 |

---

## 14. 推薦 Prompt 模板框架(可直接使用)

### System Prompt(此段固定,不隨學生變化)
```
[Knowledge Pack - GS Assistant v1.0, current as of 2024-03-23]
You are a senior Australian migration agent specialised in Genuine Student assessments under Direction No. 106. Your task is to draft GS answers for ImmiAccount (Student visa Subclass 500).

Key GS assessment factors (Direction 106):
- Home country circumstances (family, community, assets, career prospects)
- Potential circumstances in Australia (ties, incentives to stay)
- Value of course to future (career/remuneration improvement)
- Immigration history (visa compliance, refusals)
- Knowledge of course, provider, living arrangements
- Any inconsistencies, unrelated course history, or visa history gaps

Official GS questions (ImmiAccount):
1. [Question text 1]
2. [Question text 2]
...
6. [Question text 6]

Requirements:
- Each answer ≤ 150 English words, supported by documentary evidence
- Use first-person voice as the applicant
- Preferred format: short, direct, evidence-rich

Company writing techniques:
- Weave evidence naturally (e.g., "My parents own a property at..., as evidenced by the title deed.")
- Show strong home-country pull factors
- Explain course choice with career progression logic

Examples of high-quality GS answers (sanitised):
[Example 1 – Answer set]
[Example 2 – Answer set]

Output structure:
1. Case Summary
2. Official GS Answers
3. Detailed Explanations (internal use)
4. Risk Notes
5. Evidence Checklist
6. Appendix of key source excerpts

Crucial rules:
- Only use facts from the provided documents. If a fact is missing, write "Not indicated in documents provided" and do not invent it.
- Include a Self-Check Report section where you verify each factual claim against a document.
- Temperature effect: be factual and conservative.
```

### User Prompt(由系統自動拼裝)
```
[Student Case Files]
Folder: ...
Detected files:
- form500.pdf (Category: Form500)
- passport.pdf (Category: Passport)
- coe_sydney.pdf (Category: CoE)
- bank_statement.pdf (Category: Finance)
...

Below are the extracted texts from each document.
--- Document: form500.pdf ---
[完整文字]
--- Document: passport.pdf ---
[完整文字]
...

[Consultant Direction]
{使用者輸入,或留空}

Please generate the complete GS pack as per the specified structure. Start with "Case Summary".
```

---

## 15. 最終推薦:顧問角度,第一版做哪一種方案

**推薦方案:Streamlit 內部工具 + 雙模型 API + 固定知識包 + Markdown 轉 Word,1.5 週上線。**

理由:
- 你已經證明**人工貼進網頁版能產出 99% 可用 GS**,所以瓶頸根本不在「AI 能力不夠」或「缺少 RAG」,瓶頸在於「非核心人員無法穩定複製高品質輸出」
- 這個 MVP 把「專業顧問的 prompt engineering 技巧+公司高品質範例+官方要求」封裝成一個一鍵按鈕,讓一個初級員工能做到原本要資深顧問貼檔、調 prompt、人工轉存 Word 的整套流程
- 成本低到幾乎是外部代寫的 1/400,回收期不到兩週
- 完全不做過度工程,把 RAG、OCR、自動評分等留在 v2,當你發現「模型不知道最新改的法規」再來做 RAG;當你大量碰到掃描件時才加上 OCR
- 這個架構未來可以直接長成正式平台(抽換 prompt 為 API 呼叫、接入內部向量庫等),不會變成一個死胡同

如果我是外部顧問,我會建議這樣做:**這不是一個「簡陋版」,而是精準打擊你當前瓶頸的「最瘦 MVP」,上線後立刻開始幫公司省下每案 AUD 150-200 的外包成本,且因人工終審把關,法律風險與現狀相同。**
📊 Token:输入 1360 / 输出 9711(reasoning 4150) | 费用:$0.009040 | 耗时:313163ms | finish_reason:stop | 续写:0
Round 2 - Gemini Pro gemini-2.5-pro · 0.1133925 USD

Prompt

你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。

【背景】
我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。

【目前重要現實】
我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。

真正痛點不是模型不會寫,而是:
1. 其他公司同事無法穩定有效使用最新模型。
2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。
3. 公司希望把流程統一化,交給少數有權限人員。
4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。
5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。

【上一輪多模型與 Codex 綜合結論】
完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。

【但這一輪我要你回答的問題是:最快能上線方案】
請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:

1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?
2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?
3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?
4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?
5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?
6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。
7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。
8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。
9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。
10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。
11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。
12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。
13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。
14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。
15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?

請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。

AI Reply

【GEMINI-PRO · gemini-2.5-pro】
好的,收到。身為資深 AI 產品架構師與 MVP 顧問,我完全理解你的需求:**速度優先,完美其次**。基於「Web 界面手動操作已證明可行」的核心前提,我們來設計一個最精簡、最快能上線的內部工具。

這份方案將完全圍繞「如何用最低工程成本,將你手動操作的流程,變成一個可靠的內部自動化腳本」。

---

### **總體 MVP 策略:Google 生態系內的「無伺服器自動化腳本」**

我們的核心是利用你公司已經在用的 Google Workspace (G Suite),以 Google Sheets 為操作介面,Google Apps Script 為黏合劑,串接 Google Drive API、LLM API、Google Docs API。這幾乎不需要架設伺服器,部署極快,權限控管也相對單純。

---

### **1. 1-2 週內上線的最快方案**

**方案:Google Sheet + Google Apps Script**

*   **操作介面 (Frontend):** 一個 Google Sheet。員工只需要在這個 Sheet 的特定欄位貼上學生 Google Drive Folder 的 URL,並在旁邊的欄位寫下顧問的特定指示。
*   **核心邏輯 (Backend):** Google Apps Script。這是一個基於 JavaScript 的雲端腳本平台,內建於 Google Workspace。它可以:
    *   被 Google Sheet 中的一個按鈕或自訂選單觸發。
    *   直接調用 Google Drive API 來讀取文件。
    *   直接調用外部 API (如 OpenAI, Anthropic)。
    *   直接調用 Google Docs API 來生成文件。
*   **為什麼這是最快的?**
    *   **零基礎設施:** 無需伺服器、無需部署、無需管理環境。
    *   **原生整合:** 與 Google Drive/Docs/Sheets 無縫接軌,權限驗證最簡單。
    *   **學習曲線低:** 對於會 JavaScript 的工程師來說,Apps Script 非常容易上手。
    *   **使用者零門檻:** 公司同事都會用 Google Sheet。

### **2. Drive link -> Prompt 包 -> API -> Word 的可行性與風險**

**絕對可行。這就是 MVP 的核心。**

*   **流程:**
    1.  **輸入:** 員工在 Sheet 中提供 Drive Folder URL。
    2.  **觸發:** 點擊「生成 GS 草稿」按鈕。
    3.  **Apps Script 執行:**
        *   遍歷指定 Drive Folder 內的文件。
        *   根據文件類型(DOCX, PDF, JPG)抽取文字。
        *   將抽取的文字與「固定知識包」和顧問指示組合成一個巨大的 prompt。
        *   並行(或串行)呼叫 OpenAI API 和 Anthropic API。
        *   接收 API 回傳的 Markdown 或 JSON。
        *   使用 Google Docs API 將 Markdown/JSON 內容填入一個預設的 Google Doc 範本中。
        *   將生成好的 Google Doc 連結回填到 Google Sheet 中。

*   **風險與控制:**
    *   **風險 1:垃圾進,垃圾出 (GIGO)。** 學生文件亂七八糟。
        *   **控制:** 強制規定 Google Drive Folder 的標準結構。如果結構不對,腳本直接報錯退出,要求員工先手動整理。
    *   **風險 2:Token 數超限或成本失控。** 學生給了 500 頁的銀行流水。
        *   **控制:** 在文件解析階段設定硬性上限,例如「只讀取前 50 頁 PDF」或「總文字量不超過 50,000 token」。並在 Sheet 上顯示預估 token 數與費用。
    *   **風險 3:API Key 洩漏。**
        *   **控制:** 將 API Key 儲存在 Apps Script 的 `PropertiesService` 中,不要寫死在程式碼裡。這是 Google 推薦的安全做法。
    *   **風險 4:處理時間過長。**
        *   **控制:** Google Apps Script 有 6 分鐘的執行上限(標準帳戶)。如果處理複雜,需要告知使用者耐心等待,或考慮拆分流程。但對於一般案例,6 分鐘足夠。

### **3. 最快版的「固定知識包」策略**

**是的,直接用「固定知識包」塞進 prompt 是最快的 MVP 做法。**

*   **內容:**
    1.  **公司 GS 技巧與最佳實踐 (Know-how):** 約 1000-2000 words。
    2.  **優秀 GS 範例 (Examples):** 3-5 個匿名化的、結構清晰的範例,每個約 500 words。
    3.  **官方規範 (Regulations):** Home Affairs GS 要求、Direction No. 106 的核心要點摘要。不要貼全文,要摘要。約 1000 words。
*   **Token 估算:**
    *   知識包:約 4000-5000 words,約等於 6000-8000 tokens。
    *   學生資料:假設 10-20 頁文件,約 10000-20000 tokens。
    *   總計:約在 16k - 28k tokens。
*   **是否可接受:** **完全可接受。** GPT-4o、Claude 3 Sonnet/Opus 都有 128k-200k 的 context window。這點 token 量對它們來說綽綽有餘,甚至還能放更多學生資料。
*   **如何控制大小:**
    *   **摘要化:** 所有法規、技巧都必須是精煉的摘要,用 bullet points 表示。
    *   **範例篩選:** 只放最多樣化、最經典的範例,而不是所有範例。
    *   **硬上限:** 知識包本身可以存在一個 Google Doc 裡,腳本每次去讀取。如果超過 token 上限,就在腳本裡報錯,提醒維護者去精簡。

### **4. Google Drive 接入與容錯**

*   **最簡單接入:** 使用 Google Apps Script 的 `DriveApp` 服務。只需要幾行程式碼就能根據 URL 找到 Folder 並遍歷裡面的檔案。
    ```javascript
    // Example in Apps Script
    function processStudentFolder(folderUrl) {
      const folder = DriveApp.getFolderById(folderUrl.match(/[-\w]{25,}/));
      const files = folder.getFiles();
      // ... loop through files
    }
    ```
*   **固定結構:** **強烈建議 MVP 階段強制使用固定結構。**
    ```
    /Student_Name_GS_Case/
    ├── /01_Application_Form/ (放 Form500 PDF)
    ├── /02_ID_and_Photos/ (放 Passport, ID, 照片)
    ├── /03_Financial_Docs/ (放銀行證明、收入證明)
    ├── /04_Course_and_COE/ (放 CoE, Offer Letter)
    ├── /05_Academic_and_Work/ (放成績單、工作證明)
    └── /06_Previous_Visas/ (放過往簽證記錄)
    ```
*   **容錯機制:**
    *   **結構檢查:** 腳本第一步就是檢查 `01` 到 `06` 這些資料夾是否存在。如果缺少任一關鍵資料夾(例如 `01` 和 `04`),直接在 Google Sheet 中回報「錯誤:缺少關鍵資料夾,請檢查」,然後停止執行。
    *   **不要猜測:** MVP 不要花時間做複雜的 AI 來猜測文件是什麼。規則驅動最快最穩。

### **5. 文件解析 MVP 策略**

分階段進行,速度第一。

*   **Phase 1 (Week 1): 文字優先**
    *   **DOCX:** 使用 Apps Script 的原生能力或開源庫解析。
    *   **PDF (可選取文字的):** Apps Script 可以直接讀取 PDF 內的文字 (`getAs('text/plain')`)。品質不完美但堪用。
    *   **圖片/掃描件:** **直接跳過。** 在 Sheet 上回報「警告:發現 X 個圖片文件,內容未被讀取」。要求員工手動將圖片中的關鍵資訊(如護照號碼、存款金額)複製到一個 `summary.txt` 文件中,放在根目錄下。
*   **Phase 2 (Week 2, if time permits): 簡易 OCR**
    *   **Google Drive Built-in OCR:** Google Drive 本身就有 OCR 功能。上傳圖片時選擇轉換為 Google Doc,文字就會被提取出來。可以讓員工先手動操作,或用 Apps Script 呼叫 API 實現自動轉換。這是成本最低、整合最快的 OCR 方案。
    *   **先不用 Cloud Vision/Azure:** 這些是更強大的工具,但需要額外的 API 設置和費用管理,留在下一版。

### **6. MVP 的 Word (Google Doc) 模板設計**

輸出物不只是答案,更是顧問的工作台。使用 Google Docs API 將內容填入預設模板。

**Google Doc 模板結構:**

*   **封面頁 (Cover Page)**
    *   學生姓名、申請號碼、申請課程、目標學校
    *   生成日期、使用的模型 (e.g., GPT-4o, Claude 3 Opus)
    *   **!!免責聲明:此文件為 AI 生成草稿,僅供內部參考,必須由專業顧問審核修改後方可使用!!**

*   **第一部分:案件摘要與風險評估 (Case Summary & Risk Assessment)**
    *   **AI 生成的摘要:** 一段話總結學生背景、資金、課程關聯性。
    *   **AI 識別的潛在風險點 (AI-Identified Potential Risks):**
        *   `[ ] 學習斷層 (Study Gap): 2.5 年`
        *   `[ ] 資金來源:近期大筆存入`
        *   `[ ] 課程轉換:從商科轉 IT,關聯性需加強解釋`
        *   `[ ] 移民歷史:曾有旅遊簽拒簽記錄`
        *   *(這個部分是巨大價值點,幫助顧問快速聚焦)*

*   **第二部分:GS Form Answers (每題 150 Words)**
    *   **Question 1: Details of their current circumstances...**
        *   **AI Generated Answer (148 words):** [生成的答案]
    *   **Question 2: Explain why you wish to study this course...**
        *   **AI Generated Answer (149 words):** [生成的答案]
    *   ... (依此類推)

*   **第三部分:長篇版陳述 (Long Version for Reference)**
    *   AI 生成的未經刪減的詳細版本,顧問可以在這裡找到更多素材來修改 150-word 版本。

*   **第四部分:證據清單核對 (Evidence Checklist)**
    *   AI 根據讀取到的文件,自動勾選它「看到」的證據。
        *   `[X] 護照掃描件`
        *   `[X] COE 文件`
        *   `[ ] 雅思成績單 (未找到或無法識別)`
        *   `[X] 銀行存款證明 (金額 AUD 85,000)`

*   **第五部分:附件 (Appendix)**
    *   如果讀取到照片,可以把學生的照片縮圖放在這裡,以供參考。

### **7. 多模型生成方案**

**方案:JSON/Markdown -> 統一渲染**

1.  **LLM 只負責生成結構化內容**:要求所有模型輸出 **Markdown** 或 **JSON** 格式的內容,而不是直接生成 Word 排版。這讓輸出更穩定、可預測。
    *   例如,Prompt 要求模型返回一個 JSON 物件:
        ```json
        {
          "case_summary": "...",
          "risk_factors": ["Study gap of 2.5 years", "Recent large deposit"],
          "gs_answers": {
            "q1": "...",
            "q2": "..."
          },
          "long_version": "...",
          "evidence_found": ["Passport", "COE"]
        }
        ```
2.  **Apps Script 統一處理**:你的 Apps Script 收到這個 JSON 後,負責解析它。
3.  **Google Docs API 渲染**:腳本打開你的 Google Doc 模板,然後像填空一樣,把 JSON 裡的值填入對應的位置(書籤、佔位符等)。
4.  **生成多個文件**:為每個模型(GPT-4o, Claude 3 Opus)都重複一次這個渲染過程,生成 `[學生姓名]_GS_Draft_GPT4o.docx` 和 `[學生姓名]_GS_Draft_Opus.docx`。

**優點:** 關注點分離。LLM 專注於內容,程式碼專注於排版。修改 Word 模板時,完全不需要改 prompt。

### **8. MVP 的 Guardrails (無 RAG)**

1.  **強力 Prompt 約束:**
    *   **角色扮演:** 「你是一位經驗豐富的澳洲移民顧問...」
    *   **資料來源限定:** 「你**只能**根據下方提供的『學生資料』來回答。嚴禁編造任何學生不存在的經歷、成績或家庭背景。」
    *   **未知處理:** 「如果學生資料中缺少某項關鍵資訊(例如雅思成績),你必須在『風險評估』部分明確指出『資訊缺失:未找到雅思成績單』,而不是假設一個分數。」
    *   **引用檢查:** 「在『長篇版陳述』中,當你引用一個具體事實(如存款金額),請在旁邊用括號註明來源文件名 (e.g., ...存款為 AUD 85,000 (source: bank_statement_2024.pdf))。」
    *   **禁止外部知識:** 「不要引用任何你模型訓練數據中的舊法規或外部網頁。所有法規判斷必須基於我提供的『固定知識包』。」
2.  **輸出結構化:** 要求 JSON 輸出。如果 LLM 無法生成合法的 JSON,表示它可能「失控」了,腳本可以捕獲這個錯誤並回報。
3.  **風險標籤化:** 在 prompt 中明確要求 AI 輸出一個 `risk_factors` 列表。這強迫它去思考問題,而不是只生成完美的答案。
4.  **關鍵詞檢查:** 腳本在收到 LLM 回應後,可以做簡單的字串檢查,比如是否包含 "As an AI language model..."、"I cannot..." 等樣板廢話,如果有的話,可以要求重試或標記出來。
5.  **人類審核是最終防線:** 在 Word 模板最上方用紅色粗體字標明「**AI 草稿,必須人工審核**」。

### **9. 內部人員操作介面推薦**

**首選:Google Sheet + Apps Script**

*   **優點:**
    *   **最快實現 (1-2 天可搞定介面)。**
    *   **零部署、零維護成本。**
    *   公司員工熟悉,**無學習成本**。
    *   權限管理與公司 G Suite 帳號體系掛鉤,天然安全。
    *   處理紀錄直接保存在 Sheet 上,一目了然。
*   **次選:Streamlit**
    *   **優點:** 介面更美觀,互動性更好。
    *   **缺點:** 需要一個地方部署(即使是免費的 Streamlit Cloud),需要處理使用者登入/權限問題,比 Apps Script 慢。
*   **不推薦:** Next.js (太重)、n8n/Zapier/Make (增加了第三方依賴和成本,不如 Apps Script 原生)、CLI (非技術人員無法使用)。

**結論:對於「最快落地」,Google Sheet 是無可爭議的冠軍。**

### **10. 最快 MVP 具體工作流**

1.  **顧問 (使用者):**
    *   步驟 1:將學生的所有文件按照**固定結構**整理到一個 Google Drive Folder 中。
    *   步驟 2:打開「GS 生成工具」Google Sheet。
    *   步驟 3:在新的一行中,填入學生姓名,並將該 Folder 的 URL 貼到「Drive Folder URL」欄。
    *   步驟 4:(可選) 在「顧問特別指示」欄輸入額外要求,如「請特別強調他畢業於名校的優勢」。
    *   步驟 5:從自訂選單中選擇 `GS Tools > Generate Drafts for Selected Row`。
2.  **系統 (Apps Script):**
    *   步驟 1:讀取被觸發行的 Folder URL 和指示。
    *   步驟 2:驗證 Folder URL,並檢查內部是否符合「固定結構」。不符合則在 Sheet 中回報錯誤並終止。
    *   步驟 3:遍歷 Folder,讀取所有文字型文件 (DOCX, PDF),匯總成一個 `student_data.txt` 字串。
    *   步驟 4:讀取儲存在另一個 Google Doc 中的「固定知識包」。
    *   步驟 5:組合最終的 Prompt = `System Prompt` + `Knowledge Pack` + `Student Data` + `Consultant Direction`。
    *   步驟 6:同時向 OpenAI API 和 Anthropic API 發送請求。
    *   步驟 7:等待 API 回傳 JSON 結果。
    *   步驟 8:複製一份 Google Doc 模板。
    *   步驟 9:解析 JSON,將內容填入新的 Google Doc。
    *   步驟 10:為每個模型生成一份 Doc。
    *   步驟 11:將兩份 Doc 的 URL 連結回填到 Google Sheet 的「GPT-4o 輸出」和「Claude Opus 輸出」欄位,並更新狀態為「完成」。
3.  **顧問 (審核):**
    *   步驟 1:看到 Sheet 狀態變為「完成」,點擊連結打開兩份 Google Doc。
    *   步驟 2:首先查看「案件摘要與風險評估」部分,快速掌握重點。
    *   步驟 3:比較兩份文件的優劣,選擇一份作為基礎。
    *   步驟 4:基於該草稿進行專業修改、事實核對、潤飾語氣。
    *   步驟 5:定稿後,從中複製 150-word 的答案到 ImmiAccount 申請表中。

### **11. 1-2 週落地計劃**

*   **Week 1: 核心引擎搭建**
    *   **Day 1-2: 準備與設計**
        *   [ ] 確定並撰寫「固定知識包」v1.0,存為 Google Doc。
        *   [ ] 設計並創建 Google Doc 輸出模板 v1.0。
        *   [ ] 設計 Google Sheet 操作介面,確定欄位。
        *   [ ] 申請 OpenAI 和 Anthropic API Key,設置好預算提醒。
    *   **Day 3-5: 核心腳本開發 (Apps Script)**
        *   [ ] 實現 Google Drive 文件讀取與結構檢查功能。
        *   [ ] 實現文字檔、DOCX、PDF 的文字抽取。
        *   [ ] 搭建 Prompt 組合邏輯。
        *   [ ] 完成單一模型 (如 OpenAI) 的 API 呼叫與回應處理。
    *   **Day 6-7: 輸出與測試**
        *   [ ] 實現 Google Docs API 的內容填充功能。
        *   [ ] 將整個流程串起來,用 2-3 個真實案例進行端到端測試。

*   **Week 2: 完善與上線**
    *   **Day 8-9: 多模型與 UI 優化**
        *   [ ] 加入第二個模型 (Anthropic) 的 API 呼叫。
        *   [ ] 完善 Google Sheet 的介面,加入自訂選單、狀態回報、錯誤提示。
    *   **Day 10-11: 內部測試與培訓**
        *   [ ] 交給 1-2 位核心顧問進行小範圍試用,收集反饋。
        *   [ ] 撰寫一份簡單的操作手冊(不超過一頁)。
    *   **Day 12-14: 修正與上線**
        *   [ ] 根據反饋修正 Bug 和優化 prompt。
        *   [ ] 正式宣布工具上線,僅供指定人員使用。

*   **MVP 階段絕不要做的功能:**
    *   **不要做** 複雜的 OCR 與手寫識別。
    *   **不要做** Vector DB 或 RAG。
    *   **不要做** 獨立的 Web UI。
    *   **不要做** 複雜的使用者權限管理系統(依賴 Sheet 的共享設定即可)。
    *   **不要做** 自動版本控制(讓顧問手動另存為即可)。

### **12. 成本估算**

*   **工程成本:**
    *   如果找到熟悉 Google Apps Script 和 API 串接的開發者/顧問,預計 **20-40 小時** 的工作量。按市場行情,約 AUD 2,000 - 5,000 的一次性開發成本。
*   **Token 成本 (每案):**
    *   假設總 token (in+out) 約 30k。
    *   **GPT-4o:** ~$0.005/1k (in) + ~$0.015/1k (out) -> 均價算 $0.007/1k。30k token ≈ **AUD 0.32**。
    *   **Claude 3 Opus:** ~$0.015/1k (in) + ~$0.075/1k (out) -> 均價算 $0.025/1k。30k token ≈ **AUD 1.13**。
    *   **Claude 3 Sonnet (推薦,性價比高):** ~$0.003/1k (in) + ~$0.015/1k (out) -> 均價算 $0.006/1k。30k token ≈ **AUD 0.27**。
    *   **總計每案成本:** 使用 GPT-4o + Claude 3 Opus,約 **AUD 1.5**。如果換成 Sonnet,成本不到 **AUD 1.0**。
*   **維護成本:**
    *   極低。主要是 prompt 的微調和 API 模型的更新。每月可能只需 1-2 小時。
*   **與外包比較:**
    *   外包:**AUD 100 - 200** / 案。
    *   內部工具:**< AUD 2.0** / 案。
    *   **ROI 極高。** 處理 20-30 個案例就能回收開發成本。核心優勢是**速度**(從幾小時變幾分鐘)和**品質標準化**。

### **13. 最容易踩的 20 個雷與對策**

1.  **隱私/學生資料外洩:**
    *   **雷:** API 供應商記錄 prompt。
    *   **策:** 與 OpenAI/Anthropic 簽訂 Business Agreement,啟用零數據保留 (Zero Data Retention) 政策。
2.  **Google Drive 權限混亂:**
    *   **雷:** 腳本權限過高,或員工分享了錯誤的連結。
    *   **策:** 腳本只在被觸發時由觸發者身分運行,它只能讀取該使用者有權限讀取的文件。明確培訓員工分享 folder 的正確方式。
3.  **Prompt 洩漏:**
    *   **雷:** 公司核心的 prompt 模板被洩漏。
    *   **策:** Prompt 儲存在 Google Doc 中,僅限特定人員訪問。Apps Script 程式碼也只有開發者能看到。
4.  **學生資料遺漏:**
    *   **雷:** AI 沒讀到關鍵文件。
    *   **策:** 強制文件結構 + 輸出 Evidence Checklist,讓顧問一目了然 AI 讀了什麼、沒讀到什麼。
5.  **照片/掃描件識別失敗:**
    *   **雷:** OCR 效果差,或 MVP 根本沒做 OCR。
    *   **策:** MVP 階段明確放棄處理這類文件,要求人工輔助(填寫 summary.txt)。管理好使用者預期。
6.  **Word/Doc 排版混亂:**
    *   **雷:** LLM 直接輸出帶格式的內容,非常不穩定。
    *   **策:** 讓 LLM 只輸出 JSON/Markdown,由程式碼負責渲染到 Google Doc 模板,100% 控制排版。
7.  **員工直接提交未審核版本:**
    *   **雷:** 新員工過於相信 AI,直接複製貼上。
    *   **策:** 在輸出文件的最頂部用巨大紅色字體標註「AI 草稿,嚴禁直接提交」,並在崗位培訓中反覆強調審核流程。
8.  **模型幻覺/編造事實:**
    *   **雷:** AI 編造了學生的實習經歷。
    *   **策:** 強力 Prompt 約束 + 要求 AI 標註信息來源文件名 + 顧問人工事實核對。
9.  **法規過期:**
    *   **雷:** 知識包裡的 Direction 106 摘要過時了。
    *   **策:** 指定專人(例如資深顧問)每季度審核並更新「固定知識包」Google Doc。
10. **Google Apps Script 執行超時:**
    *   **雷:** 學生文件太多,腳本跑了 6 分鐘被強制終止。
    *   **策:** 在 Sheet 上提示使用者,如果文件過多,請先手動精簡。或將流程拆分:一個按鈕讀文件,另一個按鈕生成。
11. **API 費用超支:**
    *   **雷:** 迴圈 bug 導致不斷請求 API。
    *   **策:** 在 OpenAI/Anthropic 後台設定嚴格的每日/每月預算硬上限。
12. **處理多國語言文件:**
    *   **雷:** 中文成績單無法識別。
    *   **策:** 依賴 LLM 的多語言能力。在 prompt 中告知「學生文件可能包含中文,請正確理解」。
13. **不同顧問風格不一:**
    *   **雷:** AI 生成的語氣不符合某位金牌顧問的風格。
    *   **策:** 在 Sheet 上增加「寫作風格」欄,允許顧問輸入「專業嚴謹」或「熱情洋溢」,並將此詞彙加入 prompt。
14. **Folder 命名不規範:**
    *   **雷:** 員工手滑,`01_Application` 寫成了 `1_Application`。
    *   **策:** 腳本做嚴格的資料夾名稱匹配,找不到就報錯。提供一個「標準空資料夾模板」供員工複製。
15. **API 供應商服務中斷:**
    *   **雷:** OpenAI 當機。
    *   **策:** 腳本中做好 try-catch 錯誤處理,在 Sheet 中回報「OpenAI API 暫時無法訪問,請稍後再試」。
16. **輸出品質不穩定:**
    *   **雷:** 同樣的輸入,兩次生成結果差異很大。
    *   **策:** 設定模型的 `temperature` 參數為較低值(如 0.2-0.5)以獲得更穩定的輸出。
17. **忽略顧問的特別指示:**
    *   **雷:** AI 沒看到或忽略了顧問的額外要求。
    *   **策:** 在 prompt 結構中,將 `Consultant Direction` 放在非常靠後、接近任務指令的位置,並用特殊符號包裹,例如 `### 最重要的指示 ###`。
18. **處理重複/矛盾信息:**
    *   **雷:** 學生給了兩份不同日期的存款證明。
    *   **策:** 在 prompt 中指示 AI:「如果發現資訊矛盾,請使用最新的文件,並在風險評估中註明發現了矛盾資訊。」
19. **Google API Rate Limit:**
    *   **雷:** 短時間內處理太多案例,觸發 Google Drive API 的速率限制。
    *   **策:** 在 Apps Script 中加入 `Utilities.sleep(1000)`,在每次迴圈之間增加延遲。
20. **工具過於成功,需求爆炸:**
    *   **雷:** 工具太好用,大家都要加新功能,導致 MVP 範圍不斷擴大。
    *   **策:** 嚴格管理需求池。明確告知使用者這是 MVP,所有新功能排入 v1.1 的 backlog,先讓核心流程穩定運行一個月。

### **14. Prompt 模板框架推薦**

```
# [SYSTEM PROMPT] - 角色與總體指令
You are an expert Australian migration consultant specializing in Student Visa (Subclass 500) applications. Your task is to draft the Genuine Student (GS) answers based on the provided documents. You must adhere strictly to the GS requirements and Direction No. 106. Your tone should be professional, confident, and persuasive. You MUST only use the information provided in the student's documents and our internal knowledge base. DO NOT invent any facts.

# [KNOWLEDGE PACK] - 固定的內部知識與規範
{{KNOWLEDGE_PACK_CONTENT}}
---
Here are our best practice examples:
...
Here are the key points from Direction 106:
...
---

# [STUDENT FACTS] - 從 Google Drive 抽取的學生資料
Here is the complete set of information extracted from the student's documents.
File: 01_Application_Form/form500.pdf
Content:
...
File: 03_Financial_Docs/bank_statement.pdf
Content:
...
---

# [CONSULTANT'S DIRECTION] - 顧問的特別指示
Please pay close attention to the following specific instructions for this case:
"{{CONSULTANT_DIRECTION_INPUT}}"
---

# [TASK & OUTPUT SCHEMA] - 具體任務與輸出格式
Based on ALL the information above, generate a JSON object with the following structure. Do not include any text outside of the JSON object.

{
  "case_summary": "A concise summary of the applicant's profile, proposed study, and financial situation.",
  "risk_factors": [
    "A list of potential GS risk factors identified from the documents, such as study gaps, financial issues, or weak course relevance. If no risks are found, return an empty list.",
    "If any critical information is missing (e.g., IELTS score), list it here as 'Missing Information: ...'"
  ],
  "gs_answers": {
    "q1_current_circumstances": "Draft a response to the GS question about the applicant's current circumstances. Max 150 words.",
    "q2_course_choice": "Draft a response explaining the choice of course and provider. Max 150 words.",
    "q3_course_value": "Draft a response explaining the value of the course to the applicant's future. Max 150 words.",
    "q4_australia_ties": "(If applicable for certain profiles) Draft a response about ties to Australia. Max 150 words.",
    "q5_other_matters": "Draft a response for any other relevant matters. Max 150 words."
  },
  "long_version": "A detailed, comprehensive statement covering all GS aspects, without the 150-word limit. Use this section to elaborate on the points made in the short answers. When citing a fact, add (source: filename.pdf).",
  "evidence_checklist": {
    "passport": true, // boolean: true if found, false if not
    "coe": true,
    "financial_evidence": "AUD 85,000", // string: state amount if found, or 'Not Found'
    "ielts_score": "Not Found", // string: state score if found, or 'Not Found'
    "academic_transcripts": true,
    "work_experience_letters": false
  }
}

# [FINAL CHECK] - 自我檢查指令
Before outputting the JSON, double-check your work:
1. Did you invent any information not present in the [STUDENT FACTS]? If so, remove it.
2. Are all short answers under 150 words?
3. Is the evidence_checklist an accurate reflection of the provided files?
4. Have you addressed the [CONSULTANT'S DIRECTION]?
```

### **15. 最終推薦**

**我的最終推薦是:立即採用「Google Sheet + Apps Script」方案。**

**理由如下:**

1.  **完美契合「最快上線」的核心要求:** 這是所有方案中,開發時間最短、部署最快、對現有工作流侵入性最小的選擇。它能讓你在一到兩週內就看到實際產出。
2.  **成本效益最高:** 開發成本是一次性的少量投入,而運行成本幾乎可以忽略不計,相比每案 AUD 100-200 的外包費用,ROI 立竿見影。
3.  **風險可控:** 整個流程建立在你們公司可控的 Google Workspace 生態內,權限和資料安全有基本保障。MVP 的設計(如人工審核、固定結構)已經內建了關鍵的風險控制機制。
4.  **解決了真正的痛點:** 這個方案直接解決了「同事不會用、流程不統一」的核心問題。它將複雜的 prompt 工程和資料整理工作標準化、自動化,讓顧問能專注於最終的審核與決策,而不是繁瑣的前置作業。

這個 MVP 不是一個完美的 AI 系統,而是一個強大的**「流程增強器」**。它將你已經驗證成功的手動工作流,變成了一個穩定、高效、可規模化的內部工具,能立刻為你的公司帶來降本增效的價值。先跑起來,再根據實際使用反饋,迭代優化。
📊 Token:输入 2250 / 输出 11058 | 费用:$0.113392 | 耗时:104803ms | finish_reason:stop | 续写:0
Round 2 - Grok grok-4.3 · 0.00646625 USD

Prompt

你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。

【背景】
我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。

【目前重要現實】
我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。

真正痛點不是模型不會寫,而是:
1. 其他公司同事無法穩定有效使用最新模型。
2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。
3. 公司希望把流程統一化,交給少數有權限人員。
4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。
5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。

【上一輪多模型與 Codex 綜合結論】
完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。

【但這一輪我要你回答的問題是:最快能上線方案】
請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:

1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?
2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?
3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?
4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?
5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?
6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。
7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。
8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。
9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。
10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。
11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。
12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。
13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。
14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。
15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?

請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。

AI Reply

【GROK · grok-4.3】
**最快 MVP 方案(目標:10-14 天內公司 3-5 人可穩定使用)**

以下直接回答你列的 15 個問題,全部以「最快落地、可立即執行」為優先,不談長期架構。

### 1. 1-2 週內上線建議做法
用 **Google Apps Script + Google Sheet + Drive** 做最小介面,搭配 OpenAI + Anthropic API。  
不建新網站、不做 RAG、不做向量資料庫。  
核心流程:員工在 Sheet 貼 Drive 連結 → 按「生成」→ 系統下載文件、抽文字、組 prompt → 呼叫兩個模型 → 輸出 Word。

### 2. 是否可先不做 RAG?
**可以,而且應該先不做**。  
目前 web 介面已能做到 99% 可用,代表模型本身知識與 few-shot 能力已足夠。MVP 只做「固定知識包 + 學生資料抽取」,token 控制在 12k 以內即可。風險透過「self-check + 人工必審」控制。

### 3. 固定知識包策略
建立一個 **GS_Knowledge_Pack.txt**(約 4500-5500 tokens),內容包含:
- Direction 106 重點摘要
- 官方 GS 每題 150 字偏好寫法
- 公司 8-10 個高品質 GS 範例(每題拆開)
- 常見風險對應寫法(gap year、轉領域、低分、移民歷史等)

每次生成只放一次知識包 + 學生資料,token 可控。超過 6500 tokens 就開始精簡範例。

### 4. Google Drive 接入與資料夾結構
**強制固定結構**(最快容錯方式):
```
學生姓名_StudentID/
  01_Form500/
  02_Passport/
  03_Finance/
  04_Course/
  05_Other/
```
員工只需貼「主資料夾連結」。  
Apps Script 用 `getFolders()` 檢查結構,不符合就直接回傳錯誤訊息給員工。初期不做複雜容錯,先要求員工照結構放。

### 5. 文件解析最快策略
**第一版只抽文字**:
- PDF/DOCX:用 `pdfplumber`(Python)或 Apps Script 的 `getBlob()` + `getDataAsString()`
- 掃描件/照片:**第一版完全跳過 OCR**,直接在 prompt 寫「若為掃描件請標註無法讀取,請員工手動補充」
- 第二週再補 Google Vision OCR(只針對 02_Passport 與成績單)。

### 6. Word 模板結構(最快版)
建議輸出以下結構(用 python-docx):
1. Cover(學生姓名、日期、模型版本)
2. Case Summary(一行風險等級 + 3 點重點)
3. Risk Notes(模型自動標註的潛在風險)
4. **GS Answers**(官方 150 字版本,6-7 題)
5. Internal Long Version(給顧問看的完整版)
6. Evidence Checklist(自動列出已使用文件)
7. Photo Appendix(只放照片縮圖,不放全文)

### 7. 多模型生成做法
**推薦做法**:
- 每個模型各自生成完整 Markdown
- 再用同一支 python-docx 腳本轉成相同格式的 Word
- 檔名自動標註模型名稱(`GS_學生姓名_GPT4o.docx` / `GS_學生姓名_Claude.docx`)

這樣員工可以直接打開兩個 Word 比較。

### 8. 避免幻覺的 Guardrails(MVP 版)
在 system prompt 加入以下強制指令:
- 所有數字、日期、學校名稱、課程名稱必須來自提供的文件
- 若文件未提供,必須寫「[文件未提供]」
- 禁止自己編造工作經歷、家庭背景、動機
- 每題結尾必須列出「引用文件:XX」

### 9. 操作介面推薦
**最快選擇:Google Sheet + Apps Script**(推薦)
- 優點:公司已在用 Google,1 天就能做出表單
- 缺點:介面較陽春,但 10 天內可上線

其他選項比較:
- Streamlit:需部署,較慢
- n8n/Zapier:prompt 太複雜時容易卡
- Next.js:最慢,兩週內不建議

### 10. 最快 MVP 工作流
員工步驟:
1. 把學生資料夾整理成固定結構
2. 在 Sheet 貼主資料夾連結 + 簡單方向(可留空)
3. 按「生成」

系統步驟:
1. 下載所有可讀文件並抽文字
2. 組 prompt(知識包 + 學生資料 + 禁止事項)
3. 同時呼叫 GPT-4o + Claude 3.5 Sonnet
4. 生成兩個 Word 放回指定 Drive 資料夾
5. Sheet 顯示「待審核」狀態

審核步驟:員工打開兩個 Word,確認後手動提交。

### 11. 1-2 週落地計劃
- **Day 1-3**:固定知識包 + prompt 模板完成
- **Day 4-6**:Apps Script 基礎流程(下載、抽文字、呼叫 API)
- **Day 7-9**:Word 輸出 + 多模型並行
- **Day 10-12**:風險 guardrails + 人工審核流程
- **Day 13-14**:測試 5 個真實案例 + 微調

**最小功能清單**:固定資料夾、文字抽取、雙模型生成、基本 Word 輸出、風險標註。  
**先不要做**:OCR、向量資料庫、版本控制、權限系統、自動上傳 ImmiAccount。

### 12. 成本估算(每案)
- Token 成本:約 AUD 0.8-1.5(雙模型)
- 工程成本:一人 10-12 天(外包或內部)
- 維護成本:每月 2-3 小時
- 與外包 AUD 100-200 相比,內部做完後每案成本可降到 AUD 2 以內。

### 13. 最容易踩雷的 20 個問題(重點挑 8 個)
- 員工直接提交未審核版本 → 強制在 Sheet 設「已審核」勾選才能下載
- Google Drive 權限洩漏 → 用 Service Account,只給特定資料夾權限
- 照片/掃描件無法讀取 → 第一版直接跳過,由員工手動補
- 模型編造經歷 → prompt 寫死「未提供文件不得撰寫」
- Word 排版跑掉 → 用固定 python-docx 模板
- 模型供應商保存資料 → 開啟「Zero Data Retention」或用 Azure OpenAI
- 學生資料夾結構錯誤 → Apps Script 直接報錯
- prompt 洩漏公司範例 → 知識包放私有 repo,不放在前端

### 14. Prompt 模板框架(簡化版)
```
System: 你是資深澳洲學生簽證顧問,嚴格遵守 Direction 106。
Knowledge Pack: [固定 4500 tokens]
Student Facts: [從文件抽取的結構化文字]
Consultant Direction: [員工輸入或留空]
Output Schema: 必須輸出以下 JSON 結構...
禁止事項: 1. 不得編造... 2. 所有事實必須標註來源
Self-check: 生成後檢查是否違反以上規則
```

### 15. 最終推薦
**第一版直接做 Google Sheet + Apps Script + 固定知識包 + 雙模型 API + python-docx 輸出**。

理由:這是目前「最接近你們現有手動流程」的自動化版本,10-14 天內真的能跑起來。等穩定使用 1-2 個月、累積 30-50 個案例後,再決定是否要加 RAG 或做正式介面。不要一開始就想做完整平台,會拖到兩個月以上。

需要我直接給你 Apps Script 基礎程式碼框架與 prompt 完整版本嗎?
📊 Token:输入 1493 / 输出 1840(reasoning 253) | 费用:$0.006466 | 耗时:30520ms | finish_reason:stop | 续写:0
Round 2 - MiniMax M2.7 highspeed MiniMax-M2.7-highspeed · 0.0391506 USD

Prompt

你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。

【背景】
我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。

【目前重要現實】
我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。

真正痛點不是模型不會寫,而是:
1. 其他公司同事無法穩定有效使用最新模型。
2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。
3. 公司希望把流程統一化,交給少數有權限人員。
4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。
5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。

【上一輪多模型與 Codex 綜合結論】
完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。

【但這一輪我要你回答的問題是:最快能上線方案】
請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:

1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?
2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?
3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?
4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?
5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?
6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。
7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。
8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。
9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。
10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。
11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。
12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。
13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。
14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。
15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?

請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。

AI Reply

【MINIMAX-M2.7-HIGHSPEED · MiniMax-M2.7-highspeed】
# GS 文書生成系統 — 最快 MVP 方案

## 核心前提

你們的現況判斷完全正確:**生成品質已經夠用,痛點在流程標準化與人員操作門檻**。以下方案完全基於這個前提設計,目標是 1-2 週讓內部少數人穩定使用。

---

## 1. 1-2 週上線方案

**策略:極簡工具鏈 + 人工介入點**

```
工具棧選擇(按部署速度排序):
┌─────────────────────────────────────────────────────────┐
│  方案 A(最快,3-5 天可上線)                            │
│  Google Sheet + Apps Script + n8n 免費版                │
│  適合:內部 2-3 人使用,流程可控                         │
├─────────────────────────────────────────────────────────┤
│  方案 B(稍慢,7-10 天)                                 │
│  Streamlit 單頁應用 + Google Drive API + 多模型 API    │
│  適合:多人使用,需要更好 UX                            │
└─────────────────────────────────────────────────────────┘
```

**方案 A 具體架構**:
```
Google Sheet(操作介面)
    ↓
Apps Script(觸發工作流)
    ↓
n8n(檔案下載 + 模型呼叫 + Word 生成)
    ↓
Google Drive(輸出 Word)
```

**為什麼不用 Zapier**:價格高、靈活性低、不支援自定義程式碼。

**為什麼用 n8n**:免費(self-hosted)、視覺化流程、支援自定義 JS/Python、Webhook 觸發穩定、社群活躍。

---

## 2. 不做 RAG 完全可行

**結論:完全可行,風險可控**

| 方案 | 優點 | 缺點 | 適用場景 |
|------|------|------|----------|
| 無 RAG(固定知識包) | 部署快、穩定、無 token 浪費 | 法規更新需手動更新包 | **MVP 首選** |
| 輕量 RAG(向量搜尋) | 動態檢索相關案例 | 需維護向量資料庫、額外複雜度 | 案子量 > 50/月後考慮 |
| 完整 RAG | 最智能 | 2-3 個月才能上線 | 完全不考慮 |

**為什麼固定知識包足夠**:
1. GS 要求相對穩定,Home Affairs 每年只更新 1-2 次
2. Direction 106 是綜合評估框架,邏輯不常變
3. 150-word 答案長度短,不需要大量 context
4. 你們已有「99% 可用」的 prompt,代表知識封裝已經完成

**風險控制**:
- 每季度更新一次知識包(設行事曆提醒)
- 知識包版本號寫入輸出文件抬頭
- 保留「最後更新日期」於 system prompt 內

---

## 3. 固定知識包設計

**內容組成**(建議總長度控制):

```
┌─────────────────────────────────────────────────────────┐
│  知識包結構                                              │
├─────────────────────────────────────────────────────────┤
│  Part A: GS 要求摘要 (~500 tokens)                      │
│  - 官方定義、官方指引 URL                               │
│  - 2024-03-23 後 GS vs GTE 差異                         │
├─────────────────────────────────────────────────────────┤
│  Part B: Direction 106 評估因素摘要 (~800 tokens)        │
│  - 5 大評估維度                                         │
│  - 每維度關鍵問題點                                     │
├─────────────────────────────────────────────────────────┤
│  Part C: 高品質 GS 範例 2-3 篇 (~3000 tokens)           │
│  - 不同背景學生(倒讀、轉專科、年紀大)                 │
│  - 附分数分析                                           │
├─────────────────────────────────────────────────────────┤
│  Part D: GS 寫作技巧清單 (~1000 tokens)                 │
│  - 官方偏好措辭                                         │
│  - 常見失敗模式                                         │
│  - Evidence 支持原則                                    │
├─────────────────────────────────────────────────────────┤
│  Part E: 風險點檢核清單 (~500 tokens)                   │
│  - 高風險信號(倒讀、資金疑慮、移民傾向)              │
│  - 如何正面論述                                         │
├─────────────────────────────────────────────────────────┤
│  總計:~5800 tokens(加上 student data 約 15,000-25,000)│
│  Claude 200K / GPT-4o 128K 上下文完全足夠               │
└─────────────────────────────────────────────────────────┘
```

**知識包更新機制**:
- 放在 Google Doc(公司內部共同編輯)
- 每次更新記事本版本號 + 日期
- Apps Script 讀取時快取 1 小時(避免每次呼叫都讀取)

---

## 4. Google Drive 接入方案

**強制固定資料夾結構**:

```
根目錄:GS_個案_{學生姓氏}_{遞交月份}
│
├── 00_管理文件/
│   ├── 顧問備註.txt          ← 必填,寫入希望強調的重點
│   └── 案件狀態.txt
│
├── 01_Form500/
│   └── Form500_填寫版.pdf   ← 必填,護照姓名、課程代碼
│
├── 02_護照/
│   ├── 護照正面.jpg
│   └── 護照資料頁.pdf
│
├── 03_財務證明/
│   ├── 存款證明.pdf
│   └── 財力說明.txt
│
├── 04_課程資料/
│   ├── Offer_letter.pdf
│   ├── CoE.pdf
│   └── 課程介紹.pdf
│
├── 05_照片/
│   └── 護照規格照片.jpg      ← 可選
│
└── 06_其他支持文件/
    ├── 語言成績.pdf
    ├── 學歷證書.pdf
    └── 其他.txt
```

**容忍非固定結構的設計**:

```python
# 檔案識別邏輯(Python)
def identify_file(filename, content_hint=""):
    filename_lower = filename.lower()
    
    # 精確匹配
    if "form500" in filename_lower:
        return "form500"
    if "coe" in filename_lower or "enrollment" in filename_lower:
        return "coe"
    if "offer" in filename_lower:
        return "offer_letter"
    if "passport" in filename_lower:
        return "passport"
    if "finance" in filename_lower or "bank" in filename_lower:
        return "finance"
    
    # 副檔名推斷
    if filename_lower.endswith(".pdf"):
        # 假設其餘 PDF 為「其他支持文件」
        return "supporting_doc"
    
    return "unknown"
```

**上傳前檢核清單**(在 Google Sheet 建立勾選表):
- [ ] 顧問備註.txt 已上傳
- [ ] Form500 已上傳
- [ ] 護照已上傳
- [ ] 財務證明已上傳
- [ ] Offer/CoE 已上傳

---

## 5. 文件解析 MVP 策略

**分兩階段執行**:

### Phase 1(現在做):純文字提取

```python
# 最快實作方式
import requests
from io import BytesIO

def download_and_extract_drive_file(file_id):
    """使用 Google Drive API 下載並提取文字"""
    
    # Step 1: 下載
    url = f"https://www.googleapis.com/drive/v3/files/{file_id}?alt=media"
    headers = {"Authorization": f"Bearer {access_token}"}
    response = requests.get(url, headers=headers)
    
    # Step 2: 根據類型提取
    if file_id.endswith('.pdf'):
        # 使用 PyMuPDF(pip install pymupdf)
        import fitz
        doc = fitz.open(stream=response.content, filetype="pdf")
        text = "\n".join([page.get_text() for page in doc])
        
    elif file_id.endswith(('.docx', '.doc')):
        # 使用 python-docx
        from docx import Document
        doc = Document(BytesIO(response.content))
        text = "\n".join([p.text for p in doc.paragraphs])
    
    elif file_id.endswith(('.jpg', '.jpeg', '.png')):
        # Phase 2 才處理,先標記「需 OCR」
        return {"text": "", "needs_ocr": True, "file_id": file_id}
    
    return {"text": text, "needs_ocr": False}
```

### Phase 2(1 個月後加):OCR 處理

**推薦順序**:
1. **Google Drive 內建 OCR**(最簡單)
   - 把圖片上傳到 Google Drive → 右鍵「開啟方式」→ Google Docs → 自動 OCR
   - 缺點:需手動操作

2. **Cloudflare Workers + Tesseract**(成本最低)
   - 前端直接呼叫,圖片不上傳到 OpenAI/Anthropic
   - 成本:免費配額內

3. **Google Cloud Vision API**(較貴但準確)
   - $1.5/1000 頁

**MVP 建議**:Phase 1 先上線,圖片/掃描件顯示「待 OCR — 請人工確認護照號碼、出生日期」標記,由顧問手動校對 key facts。

---

## 6. Word 輸出模板結構

**設計原則**:
- 顧問快速審核:重點訊息放前面
- 學生隱私:只放必要資訊
- 官方格式對照:每題 150-word 版本最接近 ImmiAccount 格式

```
┌─────────────────────────────────────────────────────────┐
│                                                         │
│  GS 文書生成報告                                         │
│  生成日期:2024-XX-XX | 知識包版本:v2024.Q3            │
│  學生代碼:STU-XXXXX | 負責顧問:XXX                    │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第一部分:個案摘要                                      │
│  ─────────────────────────────────────────────────      │
│  學生姓名:[從護照自動提取]                             │
│  申請課程:[從 Offer 自動提取]                          │
│  課程開始:YYYY/MM/DD                                   │
│  預計完成:YYYY/MM/DD                                   │
│  風險評估:⬛ 低 / ⬛ 中 / ⬛ 高                         │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第二部分:關鍵事實提取(供顧問確認)                   │
│  ─────────────────────────────────────────────────      │
│  ■ 護照                                          [✓/✗]  │
│  ■ Form500                                    [✓/✗]    │
│  ■ Offer Letter                               [✓/✗]    │
│  ■ CoE                                        [✓/✗]    │
│  ■ 財務證明                                    [✓/✗]    │
│  ■ [其他]                                     [✓/✗]    │
│                                                         │
│  ⚠️ 標記:「需人工確認」的事實(護照號碼、金額等)      │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第三部分:風險分析                                      │
│  ─────────────────────────────────────────────────      │
│  [系統根據 Direction 106 自動識別的潛在風險點]          │
│                                                         │
│  風險 1:倒讀/專科背景                                  │
│  → 論述方向:職業發展需求、課程銜接合理性               │
│                                                         │
│  風險 2:[根據學生情況自動生成]                         │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第四部分:GS 答案(150-word 版本)                    │
│  ─────────────────────────────────────────────────      │
│                                                         │
│  【官方格式】                                           │
│                                                         │
│  Q1: 你的學習動機是什麼?                               │
│  ┌────────────────────────────────────────────────┐     │
│  │ [150-word 答案,正確計數顯示]                  │     │
│  │ Word count: 147                                │     │
│  └────────────────────────────────────────────────┘     │
│                                                         │
│  Q2: 為什麼選擇這個課程和這個學校?                     │
│  ┌────────────────────────────────────────────────┐     │
│  │ [150-word 答案]                                │     │
│  └────────────────────────────────────────────────┘     │
│                                                         │
│  Q3: 你的課程如何幫助你未來的職業規劃?                 │
│  ...                                                    │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第五部分:長版敘述(顧問參考用)                       │
│  ─────────────────────────────────────────────────      │
│  [完整論述,無 150-word 限制]                           │
│  [供內部會議或特殊情況使用]                             │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第六部分:證據清單                                     │
│  ─────────────────────────────────────────────────      │
│  根據 GS 要求,建議準備以下證據:                       │
│                                                         │
│  □ 護照                                                │
│  □ Form500                                             │
│  □ CoE                                                 │
│  □ 財務證明(銀行存款證明 + 資金說明信)               │
│  □ 語言成績證明                                        │
│  □ 學歷證書 + 成績單                                   │
│  □ 履歷表                                              │
│  □ 僱主在職證明(如適用)                              │
│  □ [其他根據個案需要]                                  │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第七部分:多模型版本比較                               │
│  ─────────────────────────────────────────────────      │
│  [GPT-4o 版本 vs Claude Sonnet 版本對照]               │
│  [顧問可選擇或合併使用]                                 │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  第八部分:顧問備註                                     │
│  ─────────────────────────────────────────────────      │
│  [空白區域,顧問手動填寫修改意見]                       │
│                                                         │
│  修改方向:___________________________________          │
│  特別強調:___________________________________          │
│  最終版本:□ GPT  版  □ Claude 版  □ 合併版            │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

**Word 生成工具**:python-docx 庫

```python
from docx import Document
from docx.shared import Pt, RGBColor
from docx.enum.text import WD_ALIGN_PARAGRAPH

def generate_gs_word(answers, student_info, risk_analysis):
    doc = Document()
    
    # 標題
    title = doc.add_heading('GS 文書生成報告', 0)
    title.alignment = WD_ALIGN_PARAGRAPH.CENTER
    
    # 元數據
    doc.add_paragraph(f"生成日期:{answers['generated_date']}")
    doc.add_paragraph(f"知識包版本:{answers['knowledge_version']}")
    
    # 各題答案
    for q_num, answer in answers['questions'].items():
        doc.add_heading(f'Q{q_num}: {answer["question"]}', level=1)
        p = doc.add_paragraph()
        run = p.add_run(answer['text'])
        run.font.size = Pt(11)
        p.add_run(f'\nWord count: {answer["word_count"]}')
    
    doc.save('gs_report.docx')
```

---

## 7. 多模型生成策略

**推薦流程**:

```
┌─────────────────────────────────────────────────────────┐
│  方案:各模型輸出 Markdown → 統一轉 Word                │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Step 1: 準備 Prompt(single prompt,多模型共用)       │
│          ↓                                              │
│  Step 2: 同時呼叫 GPT-4o + Claude Sonnet               │
│          ↓              ↓                              │
│  Step 3: 各模型輸出 Markdown                            │
│          ↓              ↓                              │
│  Step 4: 系統解析 Markdown → 結構化 JSON                │
│          ↓              ↓                              │
│  Step 5: 同一 Word 模板,填入兩版內容                   │
│          ↓                                              │
│  Step 6: 顧問比較,選擇或合併                           │
│                                                         │
└─────────────────────────────────────────────────────────┘
```

**為什麼不用各模型直接生成 Word**:
1. 模型输出版式不一致,後處理成本高
2. Markdown 結構化輸出更穩定
3. 統一模板確保格式一致性

**具體 Prompt 設計**(讓模型輸出 Markdown):

```markdown
## 任務
你是一個專業的澳洲學生簽證 GS 文書顧問。請根據以下資訊生成 GS 答案。

## 輸出格式
請嚴格按照以下 Markdown 格式輸出,不要偏離:

```markdown
# GS 答案
## 個案摘要
[3-5 句話總結學生背景]

## 風險分析
### 已識別風險
- 風險 1:[描述]
- 風險 2:[描述]

### 論述策略
[如何正面回應風險]

## Q1: [問題原文]
### 答案(目標 150 words)
[答案正文]

### Word Count: [數字]

## Q2: [問題原文]
...

## 使用的支持證據
- [證據 1]
- [證據 2]
```

## 禁止事項
- 不要編造學生未提供的資訊
- 不要使用假設性表述(「假設學生...」)
- 不要引用未提供的法規條文
- 不要使用模糊表述(「可能」、「或許」)

## 事實確認要求
在生成答案前,請先列出你使用的「學生事實」:
- [事實 1] - 來源:[文件名]
- [事實 2] - 來源:[文件名]
```

**並行呼叫代碼**:

```python
import asyncio
import openai
from anthropic import Anthropic

async def generate_parallel(student_data, knowledge_pack):
    # 構造共同 prompt
    prompt = build_prompt(student_data, knowledge_pack)
    
    # 並行呼叫
    tasks = [
        call_gpt(prompt),
        call_claude(prompt)
    ]
    
    gpt_result, claude_result = await asyncio.gather(*tasks)
    
    # 解析 Markdown → JSON
    gpt_answers = parse_markdown_to_json(gpt_result)
    claude_answers = parse_markdown_to_json(claude_result)
    
    return {
        "gpt": gpt_answers,
        "claude": claude_answers
    }

async def call_gpt(prompt):
    client = OpenAI()
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": prompt}
        ],
        temperature=0.3  # 降低隨機性
    )
    return response.choices[0].message.content

async def call_claude(prompt):
    client = Anthropic()
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=2000,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": prompt}]
    )
    return response.content[0].text
```

---

## 8. 無 RAG 下的 Guardrails 設計

**四層防護機制**:

### Layer 1: Prompt 層約束

```python
SYSTEM_PROMPT = """
## 核心原則
你是一個澳洲學生簽證 GS 文書專家,必須嚴格遵守以下規則:

### 事實基礎原則
1. 只使用「學生事實」區塊中明確提供的信息
2. 所有論述必須基於提供的證據
3. 發現資訊不足時,明確標記「【需要補充】」

### 禁止行為
- ❌ 編造學生經歷、家庭背景、財務狀況
- ❌ 虛構學校名稱、課程名稱、日期
- ❌ 引用未在「學生事實」中的法規條文
- ❌ 使用「可能」、「或許」、「假設」等不確定表述
- ❌ 透露你對學生的「猜測」

### 答案品質標準
- 每個答案必須有具體的「為什麼」(不是空泛理由)
- 必須提及課程的具體價值(不是「好處很多」)
- 未來規劃必須與課程內容邏輯相關

### 法規遵循
- 只引用 Home Affairs 官網資訊
- Direction 106 原則必須體現在風險分析中
- 答案長度嚴格控制在 150 words(+-5 words)
"""

# 在 User Prompt 中加入事實確認要求
USER_PROMPT = """
## 學生事實(請使用以下資訊,不要自行發明)

護照姓名:{passport_name}
出生日期:{dob}
國籍:{nationality}
當前學歷:{current_education}
當前/最近職業:{current_occupation}
申請課程:{course_name}
學校:{institution_name}
課程開始:{course_start_date}
選擇課程原因:{course_selection_reason}  【如未提供,標記「需要補充」】
未來規劃:{future_plan}  【如未提供,標記「需要補充」】
財務來源:{financial_source}  【如未提供,標記「需要補充」】
"""
```

### Layer 2: 事實清單強制輸出

```python
# Prompt 中要求模型先列出使用的資訊
FACT_CHECK_SECTION = """
## 事實確認(請在生成答案前填寫)

請先確認以下資訊來源的可用性:

| 資訊項目 | 是否提供 | 來源文件 |
|---------|---------|---------|
| 護照姓名 | □ 是 □ 否 | 護照文件 |
| 出生日期 | □ 是 □ 否 | 護照文件 |
| 申請課程 | □ 是 □ 否 | Offer Letter |
| 課程開始日 | □ 是 □ 否 | CoE |
| 財務證明 | □ 是 □ 否 | 財務文件 |
| 語言成績 | □ 是 □ 否 | 成績單 |
| 學歷背景 | □ 是 □ 否 | 學歷證書 |
| 選擇理由 | □ 是 □ 否 | [需要學生提供或標記缺失] |
| 未來規劃 | □ 是 □ 否 | [需要學生提供或標記缺失] |

【缺失資訊將如何處理】:除非顾问特别指示,否则不生成包含缺失資訊的答案,而是输出「【請补充:XXX】」標記。
"""
```

### Layer 3: 後處理校驗

```python
def validate_output(generated_text, student_facts):
    """生成後自動校驗"""
    
    warnings = []
    
    # 檢查 1:是否有編造嫌疑的表述
    suspicious_phrases = ["可能", "或许", "假设", "大概", "應該是"]
    for phrase in suspicious_phrases:
        if phrase in generated_text:
            warnings.append(f"⚠️ 發現不確定表述:「{phrase}」")
    
    # 檢查 2:學生事實中的關鍵資訊是否出現在答案中
    key_facts = [student_facts.get("course_name"), 
                 student_facts.get("institution_name")]
    for fact in key_facts:
        if fact and fact not in generated_text:
            warnings.append(f"⚠️ 關鍵資訊「{fact}」未出現在答案中")
    
    # 檢查 3:Word count 範圍
    word_count = len(generated_text.split())
    if word_count < 145 or word_count > 155:
        warnings.append(f"⚠️ 字數 {word_count} 超出 150±5 範圍")
    
    # 檢查 4:是否包含「需要補充」標記
    if "【需要補充】" in generated_text:
        warnings.append("🔴 答案中包含未提供的資訊,請人工確認")
    
    return {
        "passed": len(warnings) == 0,
        "warnings": warnings
    }
```

### Layer 4: 人類審核節點

```
【系統設計不能跳過的步驟】

┌────────────────────────────────────────┐
│  ⚠️ 顧問審核是必經步驟,無法自動化 ⚠️   │
├────────────────────────────────────────┤
│  系統輸出後,必須完成以下檢核表:       │
│                                        │
│  □ 確認學生姓名正確                     │
│  □ 確認課程名稱/學校名稱正確            │
│  □ 確認日期無誤                        │
│  □ 確認無編造資訊                      │
│  □ 確認答案邏輯符合學生實際情況        │
│  □ 確認無「假設」/「可能」等不當表述    │
│                                        │
│  才能點選「批准輸出」按鈕              │
└────────────────────────────────────────┘
```

---

## 9. 操作介面推薦

**比較表**:

| 方案 | 部署時間 | 學習曲線 | 維護成本 | 適合人數 | 缺點 |
|------|---------|---------|---------|---------|------|
| **Google Sheet + Apps Script** | 2-3 天 | 低 | 低 | 1-5 人 | 功能有限,複雜邏輯困難 |
| **n8n 免費版** | 3-5 天 | 中 | 中 | 3-10 人 | 需自架伺服器 |
| **Streamlit** | 5-7 天 | 中 | 中 | 5-20 人 | 需 Python 環境 |
| **Make (Integromat)** | 1-2 天 | 低 | 高 | 1-3 人 | 每月訂閱費用高 |
| **CLI 工具** | 1 天 | 高 | 低 | 1-2 人 | 不友善 |

**MVP 首選:Google Sheet + Apps Script + n8n**

**架構示意**:

```
┌─────────────────────────────────────────────────────────────────┐
│                     Google Sheet 操作介面                       │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │ 案件列表    │  │ 輸入 Drive  │  │ 執行按鈕                │  │
│  │(連動狀態)│  │ 連結        │  │ [生成 GS]               │  │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘  │
└────────────────────────────┬────────────────────────────────────┘
                             │ Apps Script 觸發
                             ▼
┌─────────────────────────────────────────────────────────────────┐
│                         n8n Workflow                             │
│  ┌───────────┐   ┌───────────┐   ┌───────────┐   ┌───────────┐ │
│  │ Drive 下載│ → │ 檔案解析  │ → │ Prompt 組│ → │ 多模型   │ │
│  │           │   │           │   │ 裝        │   │ 生成      │ │
│  └───────────┘   └───────────┘   └───────────┘   └───────────┘ │
│                                                          │      │
│                                                          ▼      │
│                                           ┌─────────────────────┤
│                                           │ Markdown → Word     │
│                                           └─────────────────────┘
└─────────────────────────────────────────────────────────────────┘
                             │
                             ▼
                    Google Drive 輸出資料夾
```

**Google Sheet Apps Script 範例**:

```javascript
function generateGS() {
  // 1. 讀取當前列的 Drive 連結
  const sheet = SpreadsheetApp.getActiveSheet();
  const row = sheet.getActiveRange().getRow();
  const driveLink = sheet.getRange(row, 3).getValue(); // C 欄
  
  // 2. 呼叫 n8n Webhook
  const payload = {
    "action": "generate_gs",
    "drive_folder": driveLink,
    "case_id": sheet.getRange(row, 1).getValue(),
    "student_name": sheet.getRange(row, 2).getValue(),
    "consultant_notes": sheet.getRange(row, 4).getValue()
  };
  
  const options = {
    'method': 'post',
    'contentType': 'application/json',
    'payload': JSON.stringify(payload)
  };
  
  const response = UrlFetchApp.fetch('https://your-n8n-instance/webhook/gs-generate', options);
  const result = JSON.parse(response.getContentText());
  
  // 3. 更新狀態
  sheet.getRange(row, 5).setValue('生成中...');
  sheet.getRange(row, 6).setValue(result['output_url']);
  
  // 4. 通知
  SpreadsheetApp.getUi().alert('GS 生成完成!\n輸出位置:' + result['output_url']);
}
```

**n8n Workflow 快速部署**(可用現成 Template):

1. 建立 n8n 免費帳號(n8n.io)或 self-host
2. 使用以下流程節點:
   - **Webhook**(接收 Apps Script 請求)
   - **HTTP Request**(下載 Google Drive 檔案)
   - **Code**(解析檔案)
   - **HTTP Request**(呼叫 OpenAI API)
   - **HTTP Request**(呼叫 Anthropic API)
   - **Code**(Markdown → Word)
   - **Google Drive**(上傳輸出)

---

## 10. 最快 MVP 工作流

### 完整流程圖

```
╔═══════════════════════════════════════════════════════════════╗
║                    GS 生成完整工作流                           ║
╠═══════════════════════════════════════════════════════════════╣
║                                                               ║
║  【顧問操作】                                                  ║
║  ┌─────────────────────────────────────────────────────────┐  ║
║  │ 1. 在 Google Sheet 新增一列                              │  ║
║  │ 2. 填入:案件 ID、學生姓名、Google Drive 資料夾連結      │  ║
║  │ 3. 在「顧問備註」欄寫下希望強調的重點(如有)             │  ║
║  │ 4. 點選「生成 GS」按鈕                                   │  ║
║  └─────────────────────────────────────────────────────────┘  ║
║                            │                                  ║
║                            ▼                                  ║
║  【系統自動執行】                                              ║
║  ┌─────────────────────────────────────────────────────────┐  ║
║  │ 5. n8n 接收請求                                          │  ║
║  │ 6. 下載 Drive 資料夾內所有檔案                           │  ║
║  │ 7. 解析 PDF/DOCX/TXT,提取文字                          │  ║
║  │ 8. 識別學生關鍵事實(姓名、課程、學校、日期)             │  ║
║  │ 9. 組裝 Prompt(知識包 + 學生事實 + 顧問備註)           │  ║
║  │ 10. 並行呼叫 GPT-4o 和 Claude Sonnet                    │  ║
║  │ 11. 解析 Markdown 輸出                                  │  ║
║  │ 12. 執行自動校驗(字數、風險表述)                       │  ║
║  │ 13. 生成 Word 文件(含兩版答案供比較)                   │  ║
║  │ 14. 上傳 Word 到 Drive 指定輸出資料夾                    │  ║
║  │ 15. 更新 Sheet 狀態為「待審核」                          │  ║
║  │ 16. 發送 email/Slack 通知顧問                           │  ║
║  └─────────────────────────────────────────────────────────┘  ║
║                            │                                  ║
║                            ▼                                  ║
║  【顧問審核】                                                  ║
║  ┌─────────────────────────────────────────────────────────┐  ║
║  │ 17. 顧問開啟 Word,閱讀「個案摘要」                       │  ║
║  │ 18. 檢查「關鍵事實提取」是否正確                         │  ║
║  │ 19. 閱讀「風險分析」是否合理                            │  ║
║  │ 20. 比較 GPT 和 Claude 兩版答案,選擇或合併              │  ║
║  │ 21. 在「顧問備註」欄填寫修改意見                        │  ║
║  │ 22. 點選「批准」或「重新生成」                           │  ║
║  └─────────────────────────────────────────────────────────┘  ║
║                            │                                  ║
║                            ▼                                  ║
║  【最終輸出】                                                  ║
║  ┌─────────────────────────────────────────────────────────┐  ║
║  │ 23. 批准後,Word 複製到學生專用資料夾                    │  ║
║  │ 24. 顧問複製答案到 ImmiAccount GS 表格                   │  ║
║  │ 25. Sheet 狀態更新為「已完成」                          │  ║
║  └─────────────────────────────────────────────────────────┘  ║
║                                                               ║
╚═══════════════════════════════════════════════════════════════╝
```

### 各步驟時間估算

| 步驟 | 顧問操作 | 系統自動 | 總時間 |
|------|---------|---------|-------|
| 輸入資料 + 觸發 | 2 分鐘 | - | 2 分鐘 |
| 檔案下載解析 | - | 30 秒 | 30 秒 |
| Prompt 生成 | - | 5 秒 | 5 秒 |
| 模型生成 | - | 30 秒 | 30 秒 |
| Word 產出 | - | 10 秒 | 10 秒 |
| **系統總計** | - | **~1.5 分鐘** | - |
| **顧問審核** | **10-15 分鐘** | - | 10-15 分鐘 |

**單案總時間:~15 分鐘(顧問操作 12 分 + 系統 1.5 分)**

---

## 11. 1-2 週落地計劃

### 兩週衝刺排程

```
┌────────────────────────────────────────────────────────────────┐
│                      第 1 週:核心功能                         │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  Day 1-2:基礎設施                                             │
│  ├─ 申請 OpenAI API key                                       │
│  ├─ 申請 Anthropic API key                                    │
│  ├─ 申請 Google Cloud 專案 + 啟用 Drive API                   │
│  ├─ 部署 n8n(local 或 n8n.io 免費版)                       │
│  ├─ 建立測試用 Google Sheet                                   │
│  └─ 確認網路可以訪問 API                                      │
│                                                                │
│  Day 3-4:檔案處理                                             │
│  ├─ 撰寫 Google Drive 下載腳本(Python/n8n)                  │
│  ├─ 實作 PDF 文字提取(PyMuPDF)                              │
│  ├─ 實作 DOCX 文字提取(python-docx)                         │
│  ├─ 建立「顧問備註.txt」解析邏輯                             │
│  └─ 測試:下載實際學生資料夾,確認可提取文字                  │
│                                                                │
│  Day 5-6:Prompt + 單模型生成                                 │
│  ├─ 撰寫 System Prompt(知識包整合)                         │
│  ├─ 撰寫 User Prompt Template                                 │
│  ├─ 實作 GPT-4o API 呼叫                                      │
│  ├─ 實作 Markdown 解析                                        │
│  ├─ 實作自動 Word Count 校驗                                  │
│  └─ 測試:使用 1-2 個真實學生案例,檢視輸出品質               │
│                                                                │
│  Day 7:Debug + 顧問人工審核流程                               │
│  ├─ 收集測試反饋,修復問題                                    │
│  ├─ 設計「顧問審核檢核表」                                   │
│  └─ 確認輸出 Word 格式正確                                    │
│                                                                │
├────────────────────────────────────────────────────────────────┤
│                      第 2 週:完整流程 + UI                    │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  Day 8-9:多模型整合 + Word 模板                               │
│  ├─ 加入 Claude Sonnnet 呼叫                                 │
│  ├─ 實作「兩版答案並列」Word 模板                            │
│  ├─ 實作「個案摘要」自動生成                                 │
│  ├─ 實作「風險分析」區塊                                     │
│  └─ 實作「證據清單」建議                                     │
│                                                                │
│  Day 10-11:Apps Script + 通知                                 │
│  ├─ 撰寫 Google Sheet 按鈕腳本                               │
│  ├─ 串接 n8n Webhook                                          │
│  ├─ 實作狀態更新邏輯                                         │
│  ├─ 實作完成通知(email/Slack)                              │
│  └─ 測試完整流程:Sheet → n8n → Word → Sheet 回饋             │
│                                                                │
│  Day 12-13:知識包最終化 + 培訓                                │
│  ├─ 整理 GS 範例 2-3 篇(高品質)                            │
│  ├─ 整理 Direction 106 摘要                                  │
│  ├─ 撰寫「使用者手冊」(5 頁以內)                          │
│  ├─ 內部培訓:2-3 位顧問熟悉流程                             │
│  └─ 用 3-5 個真實歷史案例做壓力測試                         │
│                                                                │
│  Day 14:上線 + 監控設定                                       │
│  ├─ 建立「案件資料夾模板」(固定結構)                      │
│  ├─ 設定 API用量監控(避免超支)                            │
│  ├─ 建立問題回報機制                                         │
│  └─ 宣布 MVP 上線                                            │
│                                                                │
└────────────────────────────────────────────────────────────────┘
```

### 最小功能清單(MVP 必須)

```
【必須有】
✅ Google Drive 資料夾下載
✅ PDF/DOCX 文字提取
✅ 顧問備註解析
✅ GPT-4o 生成(至少一個模型)
✅ 150-word 答案生成
✅ Word 輸出(含基本排版)
✅ 顧問審核檢核表
✅ 狀態追蹤(待處理/生成中/待審核/已完成)

【可以不做】
❌ Claude 第二模型(先只用 GPT,節省 50% API 成本)
❌ OCR 圖片解析(手動 key-in)
❌ 自動風險評分(顧問主觀判斷)
❌ 版本管理系統(靠 Google Drive 版本歷史)
❌ 多使用者權限管理(先信任內部人員)
❌ 即時同步(每天處理即可)
❌ 完整 RAG
❌ Fine-tuning
❌ 專屬網站/域名
```

---

## 12. 成本估算

### 單案 API 成本

| 模型 | 輸入 tokens(估算) | 輸出 tokens | 單案成本 |
|------|-------------------|-------------|---------|
| GPT-4o | 20,000 | 2,000 | ~$0.08 |
| Claude Sonnet | 20,000 | 2,000 | ~$0.11 |
| **兩模型合計** | - | - | **~$0.19/案** |

### 月度成本估算

```
場景:每月 30 個案件

API 成本:
- GPT-4o: 30 × $0.08 = $2.40 AUD
- Claude: 30 × $0.11 = $3.30 AUD
- 緩衝 20%: $5.50 × 1.2 = ~$7 AUD/月

基礎設施成本:
- n8n self-hosted: $0(用閒置電腦或 $10/月 VPS)
- Google Cloud Drive API: $0(免費配額內)
- 網域/主機: $0(初期用 ngrok 或直接 IP)

人力成本:
- 一次性開發:假設 10 天工程師(internal 或 external)
- Internal: 機會成本(假設 $150/hr × 80hr = $12,000)
- External: ~$3,000-5,000 AUD

每月維護:
- 知識包更新:2-4 小時/月
- 問題修復:1-2 小時/月
- 總計:~$200-400/月(internal 成本攤提)

總計:
- 第一個月:$7 + $10 + $3,000-5,000 = $3,017-5,017 AUD
- 後續每月:$7 + $10 + $200-400 = $217-417 AUD/月
```

### vs 外包比較

```
外包 GS 代寫:AUD 100-200/案

損益平衡點:
- 如果每月案件 < 10 個:外包更便宜
- 如果每月案件 10-20 個:自建更划算(省下時間價值)
- 如果每月案件 > 20 個:自建明顯更省錢

其他考量:
✅ 自建:速度更快(15 分鐘 vs 1-3 天)
✅ 自建:可重複迭代、知識累積
✅ 自建:輸出品質更可控
✅ 自建:公司 Know-how 不外流
```

---

## 13. 20 個最容易踩雷的問題與對策

### 隱私與資料安全

```
┌────────────────────────────────────────────────────────────────┐
│  1. API 供應商保存資料                                         │
│     問題:OpenAI/Anthropic 可能用 API 輸入訓練模型              │
│     對策:                                                      │
│     ✅ 啟用 OpenAI API「不使用資料訓練」設定                    │
│     ✅ 啟用 Anthropic API「不訓練」設定                         │
│     ✅ 查看隱私政策,確認澳洲資料不上傳美國                      │
│     ✅ 敏感欄位(護照號碼)在 prompt 中遮罩前 4 碼              │
│                                                                │
│  2. Google Drive 權限泄露                                      │
│     問題:顧問不小心把案件資料夾設成公開                         │
│     對策:                                                      │
│     ✅ 建立「GS_Generator」專用服務帳號                         │
│     ✅ 所有案件資料夾只分享給該服務帳號                         │
│     ✅ Apps Script 綁定該服務帳號                               │
│     ✅ 顧問本地電腦不存護照掃描檔                               │
│                                                                │
│  3. Prompt 泄漏                                                │
│     問題:顧問把含學生個資的 prompt 截圖分享                     │
│     對策:                                                      │
│     ✅ 在培訓中強調「禁止截圖含學生資訊的 prompt」               │
│     ✅ 系統在 prompt 末尾加入浮水印:「僅供內部使用」            │
│     ✅ 設定 Slack/Email 關鍵字警示(護照號碼)                  │
│                                                                │
│  4. 輸出文件外流                                                │
│     問題:生成的 Word 未加密就發給學生                           │
│     對策:                                                      │
│     ✅ Word 設定密碼保護(python-docx 可設定)                  │
│     ✅ 發送前檢查是否含完整護照號碼                             │
│     ✅ 使用公司加密 email 或 WeTransfer                        │
└────────────────────────────────────────────────────────────────┘
```

### 資料處理問題

```
┌────────────────────────────────────────────────────────────────┐
│  5. 學生資料遺漏                                               │
│     問題:顧問只上傳部分文件,系統不知道缺哪些                   │
│     對策:                                                      │
│     ✅ 建立「必填文件」檢核清單,缺失則不生成                   │
│     ✅ 系統輸出「缺失文件」警告清單                            │
│     ✅ 在 Sheet 中用顏色標記缺失欄位                           │
│     ✅ 顧問必須點選「我已確認文件完整」才能生成                │
│                                                                │
│  6. 照片/護照掃描件 OCR 失敗                                    │
│     問題:系統無法從圖片讀取護照號碼、姓名                      │
│     對策:                                                      │
│     ✅ Phase 1:圖片不上 OCR,顯示「需人工 key-in」            │
│     ✅ Phase 2:使用 Google Drive OCR 串接                     │
│     ✅ 強制要求上傳 PDF 而非圖片(JPG 品質參差不齊)           │
│     ✅ 提供「手動輸入關鍵資訊」欄位                            │
│                                                                │
│  7. 檔案命名混亂                                               │
│     問題:顧問上傳「new version final FINAL.pdf」               │
│     對策:                                                      │
│     ✅ 建立「案件資料夾模板」,說明命名規則                     │
│     ✅ 系統根據副檔名和上傳時間判斷檔案類型                     │
│     ✅ 對無法識別的檔案顯示「⚠️ 未知檔案,請確認」             │
│                                                                │
│  8. 文件解析編碼錯誤                                           │
│     問題:PDF 解析出亂碼(尤其是中文或掃描件)                  │
│     對策:                                                      │
│     ✅ 解析後顯示「前 100 字預覽」,供顧問確認                 │
│     ✅ 發現亂碼時自動標記「需人工確認」                        │
│     ✅ 使用 PyMuPDF 而非 pdfminer(對中文支援更好)            │
└────────────────────────────────────────────────────────────────┘
```

### 生成品質問題

```
┌────────────────────────────────────────────────────────────────┐
│  9. 模型編造學生經歷                                           │
│     問題:模型「合理推測」學生背景而非基於事實                 │
│     對策:                                                      │
│     ✅ System prompt 明確禁止「假設」/「可能」表述              │
│     ✅ 要求模型先列出「使用的學生事實」再生成答案              │
│     ✅ 顧問審核時檢查「是否提到文件未提供的內容」              │
│     ✅ 後處理校驗:比對答案與學生事實清單                      │
│                                                                │
│  10. 法規引用過期                                              │
│     問題:模型引用 2022 年的移民法規                           │
│     對策:                                                      │
│     ✅ System prompt 明確寫「你的知識截止到 [日期],          │
│        請只引用 Home Affairs 官網資訊」                        │
│     ✅ 知識包每次更新時,prompt 版本號 + 日期                   │
│     ✅ 禁止模型「猜測」法規內容,只允許引用事實                │
│                                                                │
│  11. 引用幻覺(Hallucination)                                  │
│     問題:模型說「根據 2024 年移民法 Section 50...」           │
│     對策:                                                      │
│     ✅ Prompt 要求「只引用你確定的資訊,不確定時說不知道」      │
│     ✅ 禁止使用「根據法律...」「法規規定...」等表述            │
│     ✅ 使用「根據 GS 要求...」「Direction 106 提到...」       │
│                                                                │
│  12. 150-word 限制飄移                                         │
│     問題:有時生成 180 words,有時 120 words                   │
│     對策:                                                      │
│     ✅ Prompt 明確要求「exactly 150 words, tolerance ±5」      │
│     ✅ 後處理自動計數,超出範圍顯示警告                        │
│     ✅ 提供「壓縮版」和「擴展版」供顧問微調                    │
│                                                                │
│  13. 多模型輸出不一致                                          │
│     問題:GPT 和 Claude 對同一學生生成差異大的答案             │
│     對策:                                                      │
│     ✅ 兩版都提供給顧問,由顧問選擇                            │
│     ✅ 差異過大時標記「⚠️ 建議人工確認」                      │
│     ✅ 記錄哪些類型的案子模型一致性高/低                      │
└────────────────────────────────────────────────────────────────┘
```

### 流程與協作問題

```
┌────────────────────────────────────────────────────────────────┐
│  14. 員工跳過審核直接提交                                       │
│     問題:顧問太忙,直接把系統輸出貼到 ImmiAccount             │
│     對策:                                                      │
│     ✅ 系統設計「必須點選批准按鈕」才能複製答案                │
│     ✅ 批准前必須完成檢核表(勾選)                           │
│     ✅ Sheet 狀態「待審核」→ 顧問 key-in 密碼才能變更        │
│     ✅ 每週抽查 2-3 份輸出,確認審核品質                      │
│                                                                │
│  15. 同一案子重複生成                                          │
│     問題:顧問忘記已生成,再次點選按鈕                         │
│     對策:                                                      │
│     ✅ 系統偵測「今日是否已生成過」,提示覆蓋風險              │
│     ✅ 新生成建立新版本檔案(v1, v2...)                      │
│     ✅ 顧問可選擇「更新」或「新建版本」                       │
│                                                                │
│  16. 流程卡在某步驟不知道原因                                   │
│     問題:n8n workflow 失敗,顧問不知道要重試                 │
│     對策:                                                      │
│     ✅ n8n 設定「失敗時自動重試 3 次」                        │
│     ✅ 失敗時發送 alert 給指定人員                            │
│     ✅ Sheet 顯示「生成失敗,請聯繫 IT」+ 錯誤代碼            │
│                                                                │
│  17. 知識包版本混亂                                            │
│     問題:不同人修改知識包,產生衝突                           │
│     對策:                                                      │
│     ✅ 指定 1 人為「知識包管理員」                            │
│     ✅ 知識包存放在公司 Google Doc,開啟修訂記錄               │
│     ✅ 每次修改填寫「修改原因 + 日期」                        │
│     ✅ 輸出 Word 抬頭顯示「知識包版本:v2024.Q3.1」          │
└────────────────────────────────────────────────────────────────┘
```

### 技術與成本問題

```
┌────────────────────────────────────────────────────────────────┐
│  18. API Rate Limit                                            │
│     問題:同時多人使用,API 限流                              │
│     對策:                                                      │
│     ✅ 系統加入佇列機制,一次只處理 1 個案子                  │
│     ✅ 設定「排隊中,預計 N 分鐘 後處理」提示                  │
│     ✅ API key 使用「每分鐘限制」而非「每天限制」              │
│                                                                │
│  19. Token 成本超支                                            │
│     問題:一個月下來 API 費用暴增                              │
│     對策:                                                      │
│     ✅ 設定預算上限,超過時發送 alert                          │
│     ✅ 每天查看用量(OpenAI/Anthropic dashboard)             │
│     ✅ 考慮「只用 GPT-4o,暫停 Claude」節省 50%              │
│     ✅ Phase 1 限制每案最多 3 次生成                          │
│                                                                │
│  20. Word 排版走樣                                             │
│     問題:在不同 Word 版本打開格式不同                         │
│     對策:                                                      │
│     ✅ 使用標準字體(Arial, Times New Roman)                  │
│     ✅ 避免複雜表格合併                                        │
│     ✅ 生成後用「另存成 PDF」測試確認                         │
│     ✅ 提供「最小相依性」版本(純文字 + 簡單格式)             │
└────────────────────────────────────────────────────────────────┘
```

---

## 14. Prompt 模板框架

### 完整版 Prompt(可直接使用)

```markdown
# ========== SYSTEM PROMPT ==========
# GS 文書生成系統 v2024.Q3.1
# 最後更新:2024-09-01

你是一個專業的澳洲學生簽證 GS(Genuine Student)文書顧問。
你的任務是根據提供的學生事實資料,生成符合移民局要求的 GS 答案。

## 核心原則

1. **只使用提供的資訊**:答案中的每一個具體事實都必須來自「學生事實」區塊
2. **不編造、不假設**:如果某項資訊未提供,明確標記「【需要補充:XXX】」
3. **正面論述**:即使學生有潛在風險,也要正面、合理地解釋
4. **具體明確**:避免空泛表述,用具體細節說明

## 法規遵循

- 適用於 2024-03-23 起遞交的 Student visa Subclass 500 申請
- 必須符合 Home Affairs 官方的 GS 要求
- 體現 Direction 106 的評估原則(home country circumstances、Australia circumstances、course value、immigration history)
- 答案長度:每題 150 words(允許範圍 145-155 words)

## 禁止事項

❌ 使用「可能」「或許」「假設」「大概」「應該是」等不確定表述
❌ 引用學生事實中未提供的法規條文
❌ 透露你對學生的猜測或臆斷
❌ 使用「很多好处」「非常好」「非常重要」等空泛表述
❌ 生成包含學生未提供資訊的答案

## 答案品質標準

✅ 每個答案必須回答「為什麼」(不只是「是什麼」)
✅ 必須提及課程的具體價值點(不是泛泛而談)
✅ 未來規劃必須與課程內容邏輯相關
✅ 使用主動語態,直接陳述
✅ 適當使用連接詞(therefore, specifically, particularly)

## 你的知識範圍

- 你的訓練資料截止到 2024-06
- 對於 GS 具體要求,請以「學生事實」中提供的 Home Affairs 官網資訊為準
- 不要引用你「記憶中」的移民法條文

---

# ========== KNOWLEDGE PACK ==========
# 知識包內容(每季更新一次)

## A. GS 官方要求摘要

根據 Home Affairs 官網:

**什麼是 Genuine Student (GS)?**
GS 要求申請人:
1. 是真實來澳洲學習的學生
2. 課程符合其教育背景和未來職業目標
3. 有合理的留學計畫
4. 理解在澳洲生活的責任

**GS 問題類型**:
1. 學習動機
2. 選擇特定課程和學校的原因
3. 課程對未來職業的幫助
4. 過去的學習/工作經驗與課程的關聯(如適用)

**官方偏好**:
- 直接在 ImmiAccount 表格中回答(不另附長篇 statement)
- 每題最多 150 words
- 使用第一人稱「I」
- 具體、清晰的陳述

## B. Direction 106 評估因素摘要

**Home Country Circumstances**(家鄉情況):
- 經濟狀況與就業機會
- 教育機會
- 個人情況(家庭、資產)

**Potential Circumstances in Australia**(在澳洲的情況):
- 課程價值與職業發展
- 與家鄉的連結
- 適應能力

**Course Value**(課程價值):
- 課程與過去教育和未來目標的關聯
- 學校聲譽
- 課程對申請人的具體價值

**Immigration History**(移民歷史):
- 之前的簽證申請
- 簽證遵守紀錄

**Other Relevant Matter**(其他相關事項):
- 申請人對課程和學校的理解程度
- 申請真實性跡象

## C. 高品質 GS 範例

### 範例 1:應屆畢業生,直接升學
```
I am applying to study [課程名稱] at [學校名稱] because this program 
directly aligns with my bachelor's degree in [科系]. 

Specifically, the advanced modules in [具體模組名稱] will provide 
expertise I cannot obtain locally. Australia is my preferred destination 
because [學校特色,如 industry connections/地理位置].

My career goal is to work as [職業名稱] in [產業/地區]. This qualification 
will significantly enhance my employment prospects, as the industry 
reports indicate strong demand for graduates with this specialized knowledge.

I am financially prepared, with [資金來源說明] supporting my tuition and 
living expenses. My family has [簡要說明與家鄉的連結], and I plan to 
return after completing my studies.
```

### 範例 2:有工作經驗,職業轉型
```
With [數字] years of experience in [當前產業], I have identified 
a clear need to transition into [目標產業/職業].

Studying [課程名稱] at [學校名稱] will provide me with [具體技能/資格] 
that is essential for this career change. What particularly attracts me 
to this program is [學校/課程的獨特之處].

In my current role, I [簡要描述工作內容]. However, I have observed that 
[觀察到的產業趨勢/機會], which requires [需要的資格]. This qualification 
will enable me to [具體目標].

My employer [公司名稱] has agreed to [相關支持,如有], and I maintain 
strong ties to [家鄉的連結].
```

## D. GS 寫作技巧清單

### 官方偏好的表述
- "This program will provide me with..."
- "Specifically, I will gain..."
- "My career objective is to..."
- "This qualification will enable me to..."

### 應該避免的表述
- "It is a very good course"(太空泛)
- "I might work in..."(不確定)
- "The school is famous"(主觀)
- "Many benefits"(空泛)

### 如何正面處理潛在風險

**風險:年紀較大**
→ 強調成熟的學習動機、相關工作經驗、清楚的職業目標

**風險:倒讀(申請低於當前學歷的課程)**
→ 強調職業轉型需求、特定技能習得、產業認證需求

**風險:空檔期(多年未就學)**
→ 強調工作經驗累積、自我探索過程、明確的新目標

**風險:財務狀況複雜**
→ 強調具體的資金來源(家人支持/自儲蓄/獎學金)、來源合法性

**風險:有親屬在澳洲**
→ 強調獨立的學習動機、明確的畢業後計畫、與家鄉的連結

## E. 風險點檢核清單

在生成答案前,請評估是否存在以下風險,並在答案中正面處理:

- [ ] 申請人年齡 > 30 歲
- [ ] 倒讀(申請較低AQF level)
- [ ] 空檔期 > 2 年
- [ ] 頻繁更換課程/學校
- [ ] 有澳洲親屬
- [ ] 資金來源不明確
- [ ] 英語成績邊緣
- [ ] 學術背景與申請課程無明顯關聯

---

# ========== STUDENT FACTS ==========
# 以下資訊來自學生提供的文件,請只使用這些資訊

護照姓名:{passport_name}
護照號碼:{passport_number_masked}【只顯示前 4 碼 + 後 4 碼】
出生日期:{dob}
國籍:{nationality}
當前學歷:{current_education}
當前/最近職業:{current_occupation}
工作年資:{years_of_experience}

申請學校:{institution_name}
學校地點:{institution_location}
申請課程:{course_name}
課程等級:{course_level}(如 Bachelor/Master/Diploma)
課程開始日:{course_start_date}
預計完成日:{course_end_date}
課程時長:{course_duration}
課程特色:{course_highlights}【如未提供,填「未提供」】

選擇課程原因:{course_selection_reason}【未提供則標記「需要補充」】
未來職業目標:{future_career_goal}【未提供則標記「需要補充」】
回國計畫:{return_plan}【未提供則標記「需要補充」】

財務證明金額:{financial_amount} {currency}
資金來源:{financial_source}
資金來源關係:{funds_relationship}(如父母/自籌/獎學金)

語言成績:{language_score}(如 NA 或未提供)
學術背景:{academic_background}

顧問特別指示:{consultant_notes}【顧問希望強調的重點】

---

# ========== USER PROMPT ==========

請根據上述「學生事實」生成 GS 答案。

## 任務

1. 先確認「學生事實」中每項資訊的來源可用性
2. 識別任何潛在風險點
3. 生成針對每個 GS 問題的答案
4. 確保答案正面、合理、具體

## 輸出格式

請嚴格按照以下 Markdown 格式輸出:

```markdown
# GS 答案生成報告

## 資訊確認
| 項目 | 是否提供 | 來源 |
|------|---------|------|
| 護照姓名 | ✓/✗ | [文件名] |
| 申請課程 | ✓/✗ | [文件名] |
| ... | ... | ... |

## 風險識別
- [ ] 風險 1:描述
- [ ] 風險 2:描述

## 風險論述策略
針對上述風險,答案中將:
- [具體處理方式]

## Q1: 你的學習動機是什麼? / What is your purpose for studying in Australia?
### 答案(目標 150 words)
[答案正文]

### Word Count: [數字]

## Q2: 為什麼選擇這個課程和這個學校? / Why have you chosen this specific course and education provider?
### 答案(目標 150 words)
[答案正文]

### Word Count: [數字]

## Q3: 這個課程如何幫助你實現職業目標? / How will this course help you achieve your career goals?
### 答案(目標 150 words)
[答案正文]

### Word Count: [數字]

## Q4: [如有其他問題]
...

## 使用的支持事實
- [事實 1] - 來源:[文件名]
- [事實 2] - 來源:[文件名]
```

## 特殊處理要求

{consultant_notes}

如果「學生事實」中標記「需要補充」的項目,請:
1. 在答案中明確標記「【需要補充:該項目】」
2. 不要自行編造該資訊
3. 在「使用的支持事實」中說明「該項目未提供」

## 最後確認

生成答案後,請自我檢查:
- [ ] 所有具體資訊都來自「學生事實」區塊?
- [ ] 沒有使用「可能」「或許」「假設」等詞?
- [ ] 每個答案都回答了「為什麼」?
- [ ] Word count 在 145-155 範圍內?
- [ ] 未來規劃與課程邏輯相關?

---

# ========== GUARDRAILS ==========
# 額外約束條件

## 事實核查
在生成過程中,如果發現:
- 護照姓名與課程名稱可能拼寫不符 → 標記「⚠️ 姓名可能有誤」
- 課程開始日期早於 CoE 日期 → 標記「⚠️ 日期邏輯問題」
- 資金金額明顯不足以支付學費+生活費 → 標記「⚠️ 財務缺口」

## 輸出控制
- 溫度參數(temperature):0.3(降低創造性,提高穩定性)
- 最大輸出 tokens:2500(預留緩衝)
- 停止序列:不使用

## 錯誤處理
如果模型無法完成任務,輸出:
```
【生成失敗】
原因:[具體原因]
建議:[顧問應該做的動作】
```
```

---

## 15. 最終推薦

### 如果我是顧問,會建議的方案

**第一版:Google Sheet + Apps Script + n8n(方案 A)**

**理由**:

| 評估維度 | 評分(1-5) | 說明 |
|---------|-----------|------|
| 部署速度 | ⭐⭐⭐⭐⭐ | 3-5 天可上線 |
| 學習曲線 | ⭐⭐⭐⭐ | 顧問 2 小時可學會 |
| 初期成本 | ⭐⭐⭐⭐⭐ | < $5,000(含外部協助) |
| 可維護性 | ⭐⭐⭐ | 需要 1 位懂 JS/Python 的人 |
| 擴展性 | ⭐⭐⭐ | 案子多了可升級到 Streamlit |
| 風險控制 | ⭐⭐⭐⭐ | Guardrails 足够 MVP 用 |

**這個方案適合你們的核心原因**:

1. **你們的瓶頸不是技術,是流程**:已經驗證 GPT/Claude 可以生成 99% 可用的 GS,不需要再優化模型。

2. **內部人員操作能力有限**:顧問不是工程師,需要最簡單的介面。Google Sheet 是所有人都會的工具。

3. **資金和時間都有限**:1-2 週上線比完美架構更重要。先用、先賺錢、先迭代。

4. **案件量還沒到需要完整 RAG**:就算每月 30 案,固定知識包 + 每次重載完全足夠。

**Phase 2 升級時機**(建議 3-6 個月後):

```
案件量 > 50/月
    OR
顧問抱怨「還要複製貼上太麻煩」
    OR
需要處理 OCR 圖片
    OR
想要更好的版本管理

→ 升級到 Streamlit + 增強 RAG
```

**絕對不建議的方案**:

- ❌ 一開始就做完整 RAG + Fine-tuning(浪費 3-6 個月)
- ❌ 買現成移民文書 SaaS(不適合你們的客製化需求)
- ❌ 完全外包(Know-how 不累積、風險高)
- ❌ 等「完美方案」再開始(永遠等不到)

### 總結

你們的判斷完全正確:**痛點是流程,不是模型能力**。

最快 MVP = Google Sheet(輸入)+ n8n(處理)+ 固定知識包(context)+ 多模型 API(生成)+ Word(輸出)+ 顧問審核(品質把關)。

1-2 週可以上線,先跑起來,3-6 個月後根據實際使用反饋再決定是否升級。

---

需要我幫你把這個方案的任何部分展開成更詳細的技術文件或代碼嗎?
📊 Token:输入 1371 / 输出 15970(reasoning 1247) | 费用:$0.039151 | 耗时:267818ms | finish_reason:stop | 续写:0
Round 2 - Claude Sonnet 4.6 route claude-sonnet-4-6 · 0.462306 USD

Prompt

你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。

【背景】
我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。

【目前重要現實】
我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。

真正痛點不是模型不會寫,而是:
1. 其他公司同事無法穩定有效使用最新模型。
2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。
3. 公司希望把流程統一化,交給少數有權限人員。
4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。
5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。

【上一輪多模型與 Codex 綜合結論】
完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。

【但這一輪我要你回答的問題是:最快能上線方案】
請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:

1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?
2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?
3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?
4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?
5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?
6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。
7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。
8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。
9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。
10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。
11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。
12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。
13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。
14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。
15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?

請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。

AI Reply

【CLAUDE · claude-sonnet-4-6】
# 澳洲留學公司 GS 材料生成系統:最快 MVP 完整方案

---

## 總覽:我的核心推薦

**第一版做什麼:** Google Drive Link → Python 腳本抽文字 → 固定知識包 + 學生資料打包 prompt → 呼叫 Claude API + GPT-4o API 各生成一份 → 輸出 Word → 人工審核後交付

**時間:** 10 個工作天內可用
**技術棧:** Python + Streamlit(操作界面)+ Google Drive API + python-docx + Anthropic/OpenAI API
**不做的東西:** RAG、vector DB、fine-tune、OCR複雜流程、自動遞交、自動審核

---

## 第一題:1-2 週內上線,建議怎麼做?

### 核心原則
你已驗證「99% 可用」,所以第一版的目標是:**把你個人已驗證的人工操作流程,打包成可重複執行的半自動工具**。

不要追求自動化一切,只追求:
- 輸入標準化(減少同事整理資料的錯誤)
- Prompt 鎖定(防止同事自己亂改 prompt)
- 輸出規格化(統一 Word 格式)
- 多模型並行(節省比較時間)

### 具體做法分三層

```
Layer 1 - 輸入層(Day 1-3)
  └── Streamlit 表單:輸入 Drive link + 顧問備注
  └── Python 自動下載並解析文件

Layer 2 - 生成層(Day 4-7)
  └── 固定知識包 + 學生資料 → 組裝 prompt
  └── 並行呼叫 Claude API + GPT-4o API

Layer 3 - 輸出層(Day 8-10)
  └── 各模型輸出轉 Word(統一模板)
  └── 人工審核介面(對比兩份)
  └── 最終版本存檔
```

---

## 第二題:先不做 RAG/vector DB,只做 prompt 包 → API 生成 → Word 輸出,可行嗎?

### 結論:完全可行,這就是推薦方案

**可行理由:**
- Claude Opus / GPT-4o context window 分別達 200k / 128k tokens
- 固定知識包(GS規範 + 10個範例 + Direction 106摘要)約 15,000-25,000 tokens
- 學生全部文件抽取文字約 5,000-15,000 tokens
- 總計 20,000-40,000 tokens,遠低於上限,cost 可控

**風險與控制:**

| 風險 | 控制方法 |
|------|----------|
| 知識包過時(法規更新) | 建立「知識包版本號」機制,每月由專人更新一次 |
| 單次 prompt 太長導致模型失焦 | 知識包控制在 20k tokens 以內,學生資料另做結構化摘要 |
| 沒有 RAG 無法查具體案例 | 知識包內放 5-8 個高品質匿名化真實案例,覆蓋主要 risk pattern |
| Token 成本累積 | 每案估算後見第十二題 |

**不需要 RAG 的理由:**
GS 的「知識庫」其實很小——Direction 106 內容固定、GS factors 固定、官方標準固定。這不是需要查詢大量動態知識的任務,直接塞進 system prompt 完全夠用。

---

## 第三題:固定知識包方案,token 可接受嗎?如何控制大小?

### 知識包組成與大小估算

```
固定知識包(每次都帶入,約 18,000-22,000 tokens)
├── GS 官方標準摘要(精煉版)         ~1,500 tokens
├── Direction No. 106 關鍵摘要        ~2,000 tokens
├── 7個 GS assessment factors 逐一說明 ~3,000 tokens
├── 150-word 寫作技巧與禁止事項       ~1,000 tokens
├── 公司內部 GS 優秀範例 x 6          ~8,000 tokens
│   (每個案例包含 student profile + 3個 GS answers)
├── 常見 risk patterns 與處理方式      ~2,000 tokens
└── Output schema(JSON格式定義)      ~1,500 tokens
```

### Token 控制原則

**原則一:範例要精不要多**
6個案例覆蓋主要 risk 類型:
- 案例1:典型年輕學生,無財務風險,課程升級合理
- 案例2:轉課程 / inconsistent study history
- 案例3:有家庭牽絆(強 home country ties)
- 案例4:財務資金來源需說明
- 案例5:工作經歷與課程關聯性
- 案例6:再次申請 / previous visa refusal

**原則二:Direction 106 只要摘要不要全文**
```markdown
### Direction 106 GS Assessment Factors(摘要版)

Factor 1: Home Country Circumstances
- 評估:家庭狀況、經濟狀況、就業歷史、是否有強烈回國動機
- 正面信號:有家庭/財產/工作在澳洲以外、有明確回國計劃

Factor 2: Potential Circumstances in Australia  
- 評估:在澳洲是否有可能超時打工、有無非法居留誘因
- 正面信號:清晰學業計劃、展示對學習的專注

...(以下類似格式)
```

**原則三:output schema 用 JSON 定義好格式**
讓模型輸出結構化 JSON,而不是自由格式文字,後端再轉 Word。

---

## 第四題:Google Drive 開放連結怎麼接入最簡單?

### 強烈推薦:要求固定 Folder 結構

```
Student_YYYY_MM_DD_姓名/
├── 01_form500/          → Form 500 填寫版 PDF 或截圖
├── 02_passport/         → 護照首頁
├── 03_finance/          → 銀行對帳單、資金來源說明
├── 04_course/           → CoE、課程資料、入學條件
├── 05_academic/         → 成績單、學歷證明
├── 06_employment/       → 工作證明、推薦信
├── 07_photos/           → 照片(生活、家庭)
└── 08_other/            → 其他補充材料
```

**為什麼要固定結構:**
1. 程式碼簡單 10 倍(不需要猜文件類型)
2. 員工上傳時有引導,減少遺漏
3. 系統可以按 folder 決定解析優先級與處理策略
4. 後期加功能容易

**接入代碼最簡版本:**

```python
from googleapiclient.discovery import build
from google.oauth2 import service_account

def get_folder_files(folder_url_or_id: str) -> dict:
    """
    輸入 Drive folder URL 或 ID
    返回 {folder_name: [file_list]} 結構
    """
    # 從 URL 提取 folder ID
    folder_id = extract_folder_id(folder_url_or_id)
    
    service = build('drive', 'v3', credentials=get_credentials())
    
    # 列出所有子資料夾
    subfolders = service.files().list(
        q=f"'{folder_id}' in parents and mimeType='application/vnd.google-apps.folder'",
        fields="files(id, name)"
    ).execute()
    
    result = {}
    for folder in subfolders.get('files', []):
        # 列出每個子資料夾的文件
        files = service.files().list(
            q=f"'{folder['id']}' in parents",
            fields="files(id, name, mimeType)"
        ).execute()
        result[folder['name']] = files.get('files', [])
    
    return result

def extract_folder_id(url: str) -> str:
    """支援多種 Drive URL 格式"""
    import re
    patterns = [
        r'folders/([a-zA-Z0-9_-]+)',
        r'id=([a-zA-Z0-9_-]+)',
    ]
    for pattern in patterns:
        match = re.search(pattern, url)
        if match:
            return match.group(1)
    # 如果本身就是 ID
    return url
```

**容錯機制(如果不是固定結構):**

```python
FOLDER_MAPPING = {
    # folder名稱關鍵字 → 類型
    'form': 'form500',
    '500': 'form500', 
    'passport': 'passport',
    '護照': 'passport',
    'finance': 'finance',
    '財': 'finance',
    'bank': 'finance',
    'course': 'course',
    '課程': 'course',
    'coe': 'course',
    'photo': 'photos',
    '照片': 'photos',
}

def classify_folder(folder_name: str) -> str:
    folder_lower = folder_name.lower()
    for keyword, category in FOLDER_MAPPING.items():
        if keyword in folder_lower:
            return category
    return 'other'  # 無法分類的放 other
```

**認證方式選擇:**

| 方式 | 設定難度 | 推薦度 |
|------|----------|--------|
| Service Account(推薦) | 中等,一次性設定 | ⭐⭐⭐⭐⭐ |
| OAuth 2.0 用戶授權 | 每個員工要個別授權 | ⭐⭐ |
| Public link 直接下載 | 最簡單,但要開放分享 | ⭐⭐⭐ |

**最快方案:Public Link 直接下載**
讓員工把 folder 設為「知道連結的人可以查看」,系統直接用 requests 下載,無需 OAuth:

```python
import requests
import re

def download_from_drive(file_id: str, output_path: str):
    url = f"https://drive.google.com/uc?export=download&id={file_id}"
    response = requests.get(url, stream=True)
    
    # 處理 Google 的「大文件確認」頁面
    if 'text/html' in response.headers.get('content-type', ''):
        # 提取確認 token
        token = re.search(r'confirm=([0-9A-Za-z_]+)', response.text)
        if token:
            url = f"{url}&confirm={token.group(1)}"
            response = requests.get(url, stream=True)
    
    with open(output_path, 'wb') as f:
        for chunk in response.iter_content(32768):
            f.write(chunk)
```

---

## 第五題:文件解析最快 MVP 策略

### 分層策略(按實作難度排序)

**第一層(Day 1 就能做,優先):**

```python
# DOCX 解析
from docx import Document

def parse_docx(file_path: str) -> str:
    doc = Document(file_path)
    return '\n'.join([para.text for para in doc.paragraphs if para.text.strip()])

# PDF 解析(文字版)
import pdfplumber

def parse_pdf(file_path: str) -> str:
    with pdfplumber.open(file_path) as pdf:
        text = ''
        for page in pdf.pages:
            page_text = page.extract_text()
            if page_text:
                text += page_text + '\n'
    return text

# 自動根據副檔名選擇解析器
def parse_document(file_path: str) -> str:
    ext = file_path.lower().split('.')[-1]
    parsers = {
        'pdf': parse_pdf,
        'docx': parse_docx,
        'doc': parse_docx,  # 需要 antiword 或 libreoffice
        'txt': lambda p: open(p, 'r', encoding='utf-8', errors='ignore').read(),
    }
    parser = parsers.get(ext)
    if parser:
        return parser(file_path)
    return f"[無法解析的文件類型: {ext}]"
```

**第二層(掃描件/圖片,Week 2 做):**

最快方案是用 **Google Drive 內建 OCR**(不需要額外費用):

```python
def download_with_ocr(file_id: str, service) -> str:
    """
    利用 Google Drive API 的 OCR 功能
    將掃描 PDF 或圖片轉成 Google Docs 再抽文字
    """
    # 上傳到 Drive 並要求 OCR
    file_metadata = {
        'name': 'temp_ocr',
        'mimeType': 'application/vnd.google-apps.document'  # 轉成 Google Doc
    }
    media = MediaFileUpload(local_path, mimetype='image/jpeg')
    
    uploaded = service.files().create(
        body=file_metadata,
        media_body=media,
        ocrLanguage='zh-TW,en',  # 支援中英文
    ).execute()
    
    # 下載轉換後的文字
    text_content = service.files().export(
        fileId=uploaded['id'],
        mimeType='text/plain'
    ).execute()
    
    # 清理暫存文件
    service.files().delete(fileId=uploaded['id']).execute()
    
    return text_content.decode('utf-8')
```

**第三層(高準確度需求,Month 2):**
- Azure Document Intelligence(Form Recognizer)→ 結構化表單抽取
- 適合 Form 500 等有固定欄位的表格

### 解析品質處理

```python
def clean_extracted_text(text: str, source_type: str) -> str:
    """清理抽取的文字"""
    lines = text.split('\n')
    cleaned = []
    
    for line in lines:
        line = line.strip()
        # 跳過空行(但保留段落間隔)
        if not line:
            if cleaned and cleaned[-1] != '':
                cleaned.append('')
            continue
        # 跳過純符號行(常見於 PDF 表格邊框)
        if all(c in '─│┌┐└┘├┤┬┴┼-=_*#' for c in line):
            continue
        cleaned.append(line)
    
    return '\n'.join(cleaned)

def summarize_if_too_long(text: str, max_tokens: int = 3000) -> str:
    """
    如果單個文件太長(例如銀行流水),
    先用便宜模型做摘要再放進主 prompt
    """
    # 粗略估算:1 token ≈ 4 chars(英文)/ 2 chars(中文)
    estimated_tokens = len(text) / 3
    
    if estimated_tokens > max_tokens:
        # 呼叫 GPT-4o-mini 做便宜摘要
        return call_summarizer(text, max_tokens)
    return text
```

---

## 第六題:Word 模板設計

### 推薦 Word 輸出結構

```
GS_Report_學生姓名_日期.docx
│
├── 【封面頁】
│   ├── 公司 Logo
│   ├── 學生全名 + 申請日期
│   ├── 課程:Provider + Course Name
│   ├── 生成日期 + 版本號
│   └── ⚠️ DRAFT - FOR INTERNAL REVIEW ONLY
│
├── 【Section 1:Case Summary & Risk Assessment】(內部用,不提交)
│   ├── 學生背景快速摘要(5-8 bullet points)
│   ├── 主要 Risk Flags(紅色標記)
│   ├── 建議強調的 positive factors
│   └── Direction 106 各 factor 評分(低/中/高 concern)
│
├── 【Section 2:GS Answers(官方提交版)】
│   ├── Q1: Why do you want to study in Australia?
│   │   └── 150-word answer(英文,可直接複製入 ImmiAccount)
│   ├── Q2: Why have you chosen this course and provider?
│   │   └── 150-word answer
│   ├── Q3: How does this course relate to your future?
│   │   └── 150-word answer
│   ├── Q4: What are your ties to your home country?
│   │   └── 150-word answer
│   └── Q5: Additional information(如適用)
│       └── 150-word answer
│
├── 【Section 3:Extended Context Notes】(給顧問參考,不提交)
│   ├── 每題的延伸版本(500+ words,解釋為什麼這樣寫)
│   ├── 每個 claim 對應的 evidence 文件
│   └── 如果 VO 追問,建議如何回應
│
├── 【Section 4:Evidence Checklist】
│   ├── ✅/❌ 已提供的文件清單
│   ├── ⚠️ 建議補充的文件
│   └── 每份文件的 relevance 說明
│
└── 【Section 5:Model Comparison】(如生成多個版本)
    ├── Claude 版本 vs GPT-4o 版本 差異對比
    └── 顧問選擇欄位
```

### python-docx 實作核心

```python
from docx import Document
from docx.shared import Inches, Pt, RGBColor
from docx.enum.text import WD_ALIGN_PARAGRAPH
from docx.oxml.ns import qn
import json
from datetime import datetime

def create_gs_word(student_data: dict, gs_answers: dict, risk_assessment: dict) -> Document:
    doc = Document()
    
    # ===== 設定樣式 =====
    # 標題樣式
    title_style = doc.styles['Heading 1']
    title_style.font.color.rgb = RGBColor(0x1F, 0x49, 0x7D)  # 深藍色
    
    # ===== 封面頁 =====
    doc.add_heading('GENUINE STUDENT ASSESSMENT REPORT', 0)
    doc.add_paragraph(f"Student: {student_data['full_name']}")
    doc.add_paragraph(f"Course: {student_data['course_name']} @ {student_data['provider']}")
    doc.add_paragraph(f"Generated: {datetime.now().strftime('%Y-%m-%d %H:%M')}")
    
    # 加警告框
    warning_para = doc.add_paragraph()
    warning_run = warning_para.add_run('⚠️ DRAFT - FOR INTERNAL REVIEW ONLY - DO NOT SUBMIT WITHOUT REVIEW')
    warning_run.font.color.rgb = RGBColor(0xFF, 0x00, 0x00)
    warning_run.bold = True
    doc.add_page_break()
    
    # ===== Section 1: Risk Assessment =====
    doc.add_heading('SECTION 1: CASE SUMMARY & RISK ASSESSMENT', 1)
    
    # Risk flags(紅色)
    doc.add_heading('Risk Flags:', 2)
    for flag in risk_assessment.get('risk_flags', []):
        para = doc.add_paragraph(style='List Bullet')
        run = para.add_run(f"⚠️ {flag}")
        run.font.color.rgb = RGBColor(0xFF, 0x44, 0x00)
    
    # Positive factors(綠色)
    doc.add_heading('Positive Factors:', 2)
    for factor in risk_assessment.get('positive_factors', []):
        para = doc.add_paragraph(style='List Bullet')
        run = para.add_run(f"✅ {factor}")
        run.font.color.rgb = RGBColor(0x00, 0x80, 0x00)
    
    doc.add_page_break()
    
    # ===== Section 2: GS Answers =====
    doc.add_heading('SECTION 2: GS ANSWERS (FOR IMMI ACCOUNT SUBMISSION)', 1)
    
    questions = [
        ('Q1', 'Why do you want to study in Australia?'),
        ('Q2', 'Why have you chosen this course and provider?'),
        ('Q3', 'How does this course relate to your current or future employment?'),
        ('Q4', 'What are your ties to your home country?'),
    ]
    
    for q_key, q_text in questions:
        doc.add_heading(f'{q_key}: {q_text}', 2)
        
        answer = gs_answers.get(q_key, {})
        answer_text = answer.get('answer_150', '')
        word_count = len(answer_text.split())
        
        # 字數顯示(超過 150 顯示紅色警告)
        count_para = doc.add_paragraph()
        count_run = count_para.add_run(f'[Word Count: {word_count}/150]')
        if word_count > 150:
            count_run.font.color.rgb = RGBColor(0xFF, 0x00, 0x00)
            count_run.bold = True
        else:
            count_run.font.color.rgb = RGBColor(0x00, 0x80, 0x00)
        
        # 答案本文(帶底色)
        ans_para = doc.add_paragraph(answer_text)
        # 加淡藍色底色(需要操作 XML)
        shade_paragraph(ans_para, color='E8F4FD')
        
        doc.add_paragraph()  # 空行
    
    doc.add_page_break()
    
    # ===== Section 3: Extended Notes =====
    doc.add_heading('SECTION 3: EXTENDED CONTEXT NOTES (INTERNAL ONLY)', 1)
    
    for q_key, q_text in questions:
        doc.add_heading(f'{q_key} - Extended Version', 2)
        answer = gs_answers.get(q_key, {})
        doc.add_paragraph(answer.get('extended_notes', 'N/A'))
        
        # Evidence links
        evidence = answer.get('evidence_support', [])
        if evidence:
            doc.add_heading('Supporting Evidence:', 3)
            for ev in evidence:
                doc.add_paragraph(f"• {ev}", style='List Bullet')
    
    doc.add_page_break()
    
    # ===== Section 4: Evidence Checklist =====
    doc.add_heading('SECTION 4: EVIDENCE CHECKLIST', 1)
    
    checklist = risk_assessment.get('evidence_checklist', {})
    for item, status in checklist.items():
        para = doc.add_paragraph(style='List Bullet')
        icon = '✅' if status == 'provided' else ('⚠️' if status == 'recommended' else '❌')
        run = para.add_run(f"{icon} {item}")
        if status == 'missing':
            run.font.color.rgb = RGBColor(0xFF, 0x00, 0x00)
    
    return doc

def shade_paragraph(paragraph, color: str):
    """給段落加底色(需直接操作 XML)"""
    from docx.oxml import OxmlElement
    pPr = paragraph._p.get_or_add_pPr()
    shd = OxmlElement('w:shd')
    shd.set(qn('w:val'), 'clear')
    shd.set(qn('w:color'), 'auto')
    shd.set(qn('w:fill'), color)
    pPr.append(shd)

def save_document(doc: Document, output_path: str):
    doc.save(output_path)
    return output_path
```

---

## 第七題:多模型生成方案

### 推薦:各模型輸出 JSON,統一轉 Word

**原因:**
- 每個模型各自生成 Word 會造成排版不一致(很難比較)
- 統一 JSON schema → 一個 Word 模板 → 兩個版本用同樣格式呈現
- JSON 也方便後期加功能(評分、diff 比較)

### JSON Output Schema

```json
{
  "meta": {
    "model": "claude-opus-4-6",
    "generated_at": "2025-01-15T10:30:00Z",
    "student_id": "STU_001",
    "version": "1.0"
  },
  "case_summary": {
    "student_profile": "25歲台灣籍學生,目前在台北從事會計工作3年...",
    "course_rationale": "申請墨爾本大學 Master of Business Analytics...",
    "key_narrative": "從傳統會計轉型到數據分析的職涯升級故事"
  },
  "risk_assessment": {
    "risk_flags": [
      "財務資金來源需進一步說明(父母贈與需提供親屬關係證明)",
      "課程與現有工作有一定關聯性但需加強論述"
    ],
    "positive_factors": [
      "有穩定工作歷史,在台資產清楚",
      "課程直接升級現有職業技能",
      "無澳洲簽證違規歷史"
    ],
    "direction_106_assessment": {
      "home_country_ties": "HIGH - 強",
      "course_value": "HIGH - 強",
      "immigration_history": "CLEAR - 清",
      "financial_capacity": "MEDIUM - 需說明"
    },
    "evidence_checklist": {
      "護照": "provided",
      "Form 500": "provided",
      "CoE": "provided",
      "銀行對帳單(3個月)": "provided",
      "資金來源說明信": "recommended",
      "在職證明": "provided",
      "學歷證明": "provided",
      "父母資金贈與說明": "missing"
    }
  },
  "gs_answers": {
    "Q1": {
      "question": "Why do you want to study in Australia?",
      "answer_150": "Australia's world-class education system and its position as a leader in business analytics make it the ideal destination for my studies. I have specifically chosen this country due to Melbourne's thriving data-driven business ecosystem, where I can engage with industry leaders and gain practical exposure beyond classroom learning. Australia's structured visa framework and post-study work opportunities also allow me to apply my skills in an international context before returning to Taiwan, where I plan to leverage this expertise in the rapidly growing fintech sector. My employer has confirmed they value internationally-qualified candidates, making this investment directly aligned with my career trajectory. I have thoroughly researched living costs, studied English preparation materials, and connected with alumni from my target program to ensure I am fully prepared for this transition.",
      "word_count": 128,
      "key_claims": [
        "墨爾本商業分析生態系統",
        "課程與職涯目標直接連結",
        "回國工作計劃明確",
        "充分了解澳洲生活"
      ],
      "evidence_support": [
        "CoE 確認課程內容",
        "在職證明顯示現職與課程相關",
        "雇主支持信(如有)"
      ],
      "extended_notes": "這個答案強調了三個 Direction 106 關鍵點:(1) Australia 選擇的合理性而非單純移民動機,(2) 明確的職業升級目的,(3) 預先展示對澳洲生活的了解。建議顧問確認學生確實有了解墨爾本生活成本,在面談時能夠具體說明。"
    },
    "Q2": {
      "question": "Why have you chosen this course and provider?",
      "answer_150": "...",
      "word_count": 145,
      "key_claims": [],
      "evidence_support": [],
      "extended_notes": "..."
    },
    "Q3": {
      "question": "How does this course relate to your current or future employment?",
      "answer_150": "...",
      "word_count": 138,
      "key_claims": [],
      "evidence_support": [],
      "extended_notes": "..."
    },
    "Q4": {
      "question": "What are your ties to your home country?",
      "answer_150": "...",
      "word_count": 142,
      "key_claims": [],
      "evidence_support": [],
      "extended_notes": "..."
    }
  },
  "self_check": {
    "all_under_150_words": true,
    "no_fabricated_facts": true,
    "claims_supported_by_evidence": true,
    "no_immigration_intent_language": true,
    "issues_found": [],
    "confidence_score": 0.92
  }
}
```

### 並行呼叫實作

```python
import asyncio
import anthropic
from openai import AsyncOpenAI
import json

async def generate_gs_claude(prompt_package: dict) -> dict:
    client = anthropic.AsyncAnthropic(api_key=ANTHROPIC_API_KEY)
    
    message = await client.messages.create(
        model="claude-opus-4-5",
        max_tokens=8096,
        system=prompt_package['system_prompt'],
        messages=[
            {
                "role": "user", 
                "content": prompt_package['user_prompt']
            }
        ]
    )
    
    # 抽取 JSON(處理模型可能加入多餘文字的情況)
    response_text = message.content[0].text
    return extract_json_from_response(response_text)

async def generate_gs_gpt4o(prompt_package: dict) -> dict:
    client = AsyncOpenAI(api_key=OPENAI_API_KEY)
    
    response = await client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": prompt_package['system_prompt']},
            {"role": "user", "content": prompt_package['user_prompt']}
        ],
        response_format={"type": "json_object"},  # GPT-4o 支援強制 JSON 輸出
        max_tokens=8096
    )
    
    return json.loads(response.choices[0].message.content)

async def generate_all_models(prompt_package: dict) -> dict:
    """並行呼叫所有模型"""
    tasks = [
        generate_gs_claude(prompt_package),
        generate_gs_gpt4o(prompt_package),
    ]
    
    results = await asyncio.gather(*tasks, return_exceptions=True)
    
    return {
        'claude': results[0] if not isinstance(results[0], Exception) else {'error': str(results[0])},
        'gpt4o': results[1] if not isinstance(results[1], Exception) else {'error': str(results[1])},
    }

def extract_json_from_response(text: str) -> dict:
    """從模型回應中抽取 JSON(處理模型加入說明文字的情況)"""
    import re
    
    # 方法1:嘗試直接解析
    try:
        return json.loads(text)
    except:
        pass
    
    # 方法2:找 ```json ... ``` 區塊
    json_block = re.search(r'```json\s*(.*?)\s*```', text, re.DOTALL)
    if json_block:
        try:
            return json.loads(json_block.group(1))
        except:
            pass
    
    # 方法3:找第一個 { 到最後一個 }
    start = text.find('{')
    end = text.rfind('}')
    if start != -1 and end != -1:
        try:
            return json.loads(text[start:end+1])
        except:
            pass
    
    return {'error': 'JSON extraction failed', 'raw_response': text}
```

---

## 第八題:不做完整 RAG 的情況下,如何避免幻覺?

### 核心原則:讓模型只能用學生資料,不能自由發揮

**Guardrail 1:Evidence-Anchored 生成規則**

在 system prompt 中明確寫:

```
CRITICAL RULES:
1. Every factual claim about the student MUST be directly sourced from the provided documents.
2. If a document does not clearly state something, you MUST NOT infer or assume it.
3. If important information is missing (e.g., no bank statement provided), flag it in risk_assessment instead of making up details.
4. DO NOT mention any specific laws, visa regulations, or statistics unless they are explicitly provided in the Knowledge Pack below.
5. DO NOT use phrases like "according to studies" or "research shows" - only use information from the provided documents.
6. When in doubt, write a placeholder like "[EVIDENCE NEEDED: please confirm X with student]" rather than fabricating.
```

**Guardrail 2:Pre-Generation Evidence Map**

讓模型在生成 GS answers 之前,先輸出一份「evidence map」:

```
STEP 1 - Before writing GS answers, output an evidence_map:
{
  "evidence_map": {
    "student_name": {"value": "陳大明", "source": "passport p.1"},
    "course_start": {"value": "2025-07-01", "source": "CoE document"},
    "current_job": {"value": "Senior Accountant at ABC Corp", "source": "employment letter"},
    "financial_source": {"value": "personal savings + parental support", "source": "bank statements"},
    "home_ties": {"value": "parents in Taipei, owns apartment", "source": "student declaration"},
    ...
  },
  "missing_evidence": [
    "No document confirms student's property ownership",
    "Bank statement only shows 1 month, 3 months recommended"
  ]
}

STEP 2 - Only use values from evidence_map when writing GS answers.
STEP 3 - Write GS answers.
```

**Guardrail 3:Self-Check 強制欄位**

```python
def validate_gs_output(gs_json: dict) -> list:
    """驗證輸出品質"""
    issues = []
    
    # 1. 字數檢查
    for q_key in ['Q1', 'Q2', 'Q3', 'Q4']:
        answer = gs_json.get('gs_answers', {}).get(q_key, {})
        word_count = len(answer.get('answer_150', '').split())
        if word_count > 155:  # 給5字容差
            issues.append(f"{q_key} exceeds 150 words ({word_count} words)")
        if word_count < 50:
            issues.append(f"{q_key} is too short ({word_count} words) - may be incomplete")
    
    # 2. 禁用語句檢查(暗示移民意圖)
    forbidden_phrases = [
        'permanent resident', 'PR', 'settle in australia',
        'immigrate', 'never return', 'stay permanently'
    ]
    for q_key in ['Q1', 'Q2', 'Q3', 'Q4']:
        answer_text = gs_json.get('gs_answers', {}).get(q_key, {}).get('answer_150', '').lower()
        for phrase in forbidden_phrases:
            if phrase in answer_text:
                issues.append(f"⚠️ CRITICAL: {q_key} contains forbidden phrase: '{phrase}'")
    
    # 3. 檢查是否有 EVIDENCE NEEDED 佔位符(提醒顧問補充)
    placeholders = []
    for q_key in ['Q1', 'Q2', 'Q3', 'Q4']:
        answer_text = gs_json.get('gs_answers', {}).get(q_key, {}).get('answer_150', '')
        if '[EVIDENCE NEEDED' in answer_text:
            placeholders.append(q_key)
    if placeholders:
        issues.append(f"⚠️ REVIEW NEEDED: {', '.join(placeholders)} contain evidence placeholders")
    
    # 4. 法規引用檢查
    import re
    regulation_pattern = r'section \d+|schedule \d+|act \d{4}|regulation \d+'
    for q_key in ['Q1', 'Q2', 'Q3', 'Q4']:
        answer_text = gs_json.get('gs_answers', {}).get(q_key, {}).get('answer_150', '').lower()
        if re.search(regulation_pattern, answer_text):
            issues.append(f"⚠️ {q_key} references specific regulations - verify accuracy")
    
    return issues
```

**Guardrail 4:知識包版本控制**

```python
KNOWLEDGE_PACK_META = {
    "version": "2025-01-15",
    "gs_effective_date": "2024-03-23",
    "direction_106_version": "Current as of 2024",
    "last_reviewed_by": "Migration Agent XYZ",
    "next_review_due": "2025-04-01",
    "disclaimer": "This knowledge pack is current as of the version date. Always verify against current Home Affairs guidelines before submission."
}
```

**Guardrail 5:Critical Risk 自動警告**

```python
HIGH_RISK_PATTERNS = {
    "multiple_visa_refusals": lambda data: data.get('visa_refusals', 0) > 1,
    "course_downgrade": lambda data: data.get('course_level_change') == 'downgrade',
    "gap_in_study": lambda data: data.get('study_gap_years', 0) > 3,
    "no_english_evidence": lambda data: not data.get('english_test_provided'),
    "insufficient_funds": lambda data: data.get('funds_coverage_months', 99) < 12,
}

def check_high_risk(student_data: dict) -> list:
    warnings = []
    for risk_name, check_fn in HIGH_RISK_PATTERNS.items():
        try:
            if check_fn(student_data):
                warnings.append({
                    "risk": risk_name,
                    "level": "HIGH",
                    "action": "Requires manual review before submission"
                })
        except:
            pass
    return warnings
```

---

## 第九題:操作介面方案比較與推薦

### 方案比較

| 方案 | 開發時間 | 維護難度 | 非技術員工易用性 | 部署 | 推薦度 |
|------|----------|----------|-----------------|------|--------|
| **Streamlit** | 2-3天 | 低 | ⭐⭐⭐⭐ | Cloud Run / Railway | ⭐⭐⭐⭐⭐ |
| Google Sheet + Apps Script | 1-2天 | 中 | ⭐⭐⭐⭐⭐ | 零部署 | ⭐⭐⭐⭐ |
| n8n / Make | 1天 | 低 | ⭐⭐⭐ | 需自架或付費 | ⭐⭐⭐ |
| Next.js 小工具 | 1-2週 | 高 | ⭐⭐⭐⭐ | Vercel | ⭐⭐ |
| CLI 腳本 | 1天 | 低 | ⭐ | 本地執行 | ⭐⭐(初期測試用) |

### 最終推薦:Streamlit(第一版)

**理由:**
1. Python 一個檔案就能起服務,不需要前後端分離
2. 非技術員工只需要瀏覽器操作
3. 10 分鐘可以部署到 Railway/Render(免費層夠用)
4. 與後端 Python 邏輯共用同一語言,無縫整合

### Streamlit 界面設計

```python
import streamlit as st
import asyncio
import os
from pathlib import Path

st.set_page_config(
    page_title="GS Generator - Internal Tool",
    page_icon="🇦🇺",
    layout="wide"
)

# ===== 側邊欄:系統設定 =====
with st.sidebar:
    st.title("⚙️ 系統設定")
    st.info(f"知識包版本: 2025-01-15")
    st.warning("⚠️ 所有輸出均需人工審核後方可提交")
    
    # 模型選擇
    models_to_use = st.multiselect(
        "選擇生成模型",
        ["Claude Opus 4", "GPT-4o", "Gemini 1.5 Pro"],
        default=["Claude Opus 4", "GPT-4o"]
    )

# ===== 主界面 =====
st.title("🎓 GS Answer Generator")
st.caption("澳洲學生簽證 Genuine Student 材料生成工具 | 內部專用")

# 步驟 1:學生資料
col1, col2 = st.columns(2)

with col1:
    st.subheader("Step 1: 基本資料")
    student_name = st.text_input("學生全名(英文)", placeholder="CHEN Da-Ming")
    nationality = st.selectbox("國籍", ["Taiwan", "China", "Vietnam", "India", "Other"])
    
with col2:
    st.subheader("Step 2: 課程資料")
    provider = st.text_input("學校名稱", placeholder="University of Melbourne")
    course_name = st.text_input("課程名稱", placeholder="Master of Business Analytics")
    course_level = st.selectbox("課程等級", ["Doctoral", "Masters", "Bachelor", "Diploma", "Certificate", "ELICOS"])

# 步驟 2:Drive 連結
st.subheader("Step 3: 上傳文件")
drive_link = st.text_input(
    "Google Drive Folder 連結",
    placeholder="https://drive.google.com/drive/folders/...",
    help="請確保資料夾已設為「知道連結的人可以查看」"
)

# 步驟 3:顧問備注
st.subheader("Step 4: 顧問備注(可選)")
consultant_notes = st.text_area(
    "特別需要強調的內容或注意事項",
    placeholder="""例如:
- 學生有輕微的工作間隔需要解釋
- 強調課程與現職的升級關係
- 不要提及學生有海外工作經驗(尚未核實)""",
    height=120
)

risk_focus = st.multiselect(
    "已知風險點(系統會特別處理)",
    [
        "資金來源需說明",
        "課程與學歷不直接相關", 
        "有過往簽證拒簽",
        "課程等級下降",
        "長時間學習空窗",
        "在澳已有親屬",
        "無法清晰說明回國原因"
    ]
)

# 步驟 4:生成按鈕
st.divider()

if st.button("🚀 開始生成 GS Materials", type="primary", use_container_width=True):
    
    # 驗證必填欄位
    if not drive_link:
        st.error("❌ 請填入 Google Drive 連結")
        st.stop()
    if not student_name:
        st.error("❌ 請填入學生姓名")
        st.stop()
    
    # 開始處理
    with st.status("正在處理...", expanded=True) as status:
        
        st.write("📂 正在下載 Drive 文件...")
        # documents = download_and_parse_drive(drive_link)
        # 模擬進度(實際替換為真實函數)
        import time
        time.sleep(1)
        st.write("✅ 文件下載完成,共解析 8 份文件")
        
        st.write("📋 正在組裝 Prompt...")
        time.sleep(0.5)
        st.write("✅ Prompt 已準備,預估 token: ~35,000")
        
        st.write("🤖 正在呼叫 AI 模型(並行生成)...")
        time.sleep(2)
        st.write("✅ Claude Opus 4 生成完成")
        time.sleep(1)
        st.write("✅ GPT-4o 生成完成")
        
        st.write("📄 正在生成 Word 文件...")
        time.sleep(1)
        
        status.update(label="✅ 生成完成!", state="complete")
    
    # 顯示結果
    st.success("🎉 GS Materials 生成完成!")
    
    # 警告和問題
    issues = ["Q3 word count: 152/150 words (slightly over)", "Missing: parent financial support letter"]
    if issues:
        st.warning("⚠️ 請注意以下問題:")
        for issue in issues:
            st.markdown(f"- {issue}")
    
    # 下載區
    col1, col2, col3 = st.columns(3)
    with col1:
        st.download_button(
            label="📥 下載 Claude 版本",
            data=open("output_claude.docx", "rb") if os.path.exists("output_claude.docx") else b"",
            file_name=f"GS_{student_name}_Claude_{datetime.now().strftime('%Y%m%d')}.docx",
            mime="application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        )
    with col2:
        st.download_button(
            label="📥 下載 GPT-4o 版本",
            data=b"",
            file_name=f"GS_{student_name}_GPT4o_{datetime.now().strftime('%Y%m%d')}.docx",
            mime="application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        )
    with col3:
        st.download_button(
            label="📥 下載對比報告",
            data=b"",
            file_name=f"GS_{student_name}_Comparison_{datetime.now().strftime('%Y%m%d')}.docx",
            mime="application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        )
    
    # 內部審核勾選
    st.divider()
    st.subheader("✍️ 審核確認")
    reviewed = st.checkbox("✅ 我已審核所有 GS answers,確認內容準確且基於學生提供的文件")
    approved = st.checkbox("✅ 我確認字數符合 150 words 要求")
    no_fabrication = st.checkbox("✅ 我確認沒有捏造或推測學生未提供的資訊")
    
    if reviewed and approved and no_fabrication:
        st.success("✅ 審核完成,可以提交客戶使用")
        # 記錄到 log
```

---

## 第十題:最快 MVP 完整工作流

### 使用者視角工作流

```
【員工操作步驟】

Step 1(2分鐘)
  └── 開啟 Streamlit 工具
  └── 輸入學生基本資料(姓名、國籍、課程)
  └── 貼入 Google Drive folder 連結
  └── 選填:顧問備注、已知風險點

Step 2(自動,3-8分鐘)
  └── 系統自動:下載文件 → 解析文字 → 組裝 prompt → 呼叫 API
  └── 員工等待,看進度條

Step 3(15-30分鐘,人工)
  └── 下載兩份 Word(Claude 版 + GPT-4o 版)
  └── 比較兩份,選擇更好的底稿
  └── 在 Word 中修改(調整措辭、補充細節、確認字數)
  └── 確認 evidence checklist(提醒學生補充缺少文件)

Step 4(審核,由資深顧問)
  └── 資深顧問審核最終版本
  └── 確認 risk flags 已被妥善處理
  └── 勾選 Streamlit 審核確認框(留下記錄)

Step 5(交付)
  └── 發送給學生確認事實準確性
  └── 學生確認後,複製到 ImmiAccount
```

### 系統視角工作流

```
System Flow Detail:

1. INPUT COLLECTION
   ├── 解析 Drive folder URL → 提取 folder ID
   ├── 列出所有子資料夾和文件
   └── 下載每個文件到臨時目錄(temp/{session_id}/)

2. DOCUMENT PARSING
   ├── PDF → pdfplumber 抽文字
   ├── DOCX → python-docx 抽文字
   ├── Images/Scanned → 標記為 [IMAGE FILE - OCR PENDING](MVP版先跳過)
   ├── 每份文件:clean text → 如超過3000 tokens 先摘要
   └── 輸出:structured_docs = {folder_type: cleaned_text}

3. STUDENT PROFILE EXTRACTION(Pre-Generation Step)
   ├── 先呼叫一次 GPT-4o-mini(便宜)
   ├── 任務:從所有文件中提取 student facts JSON
   └── 輸出:student_facts = {name, dob, nationality, education_history, 
                              work_history, course_details, financial_summary,
                              visa_history, home_ties, ...}

4. PROMPT ASSEMBLY
   ├── system_prompt = KNOWLEDGE_PACK + GS_RULES + OUTPUT_SCHEMA
   ├── user_prompt = STUDENT_FACTS_JSON + RAW_DOCS_SUMMARY + CONSULTANT_NOTES
   └── 估算 token 數,如超過 80k 則壓縮 raw docs

5. PARALLEL API CALLS
   ├── asyncio.gather([claude_call, gpt4o_call])
   └── 各自返回 GS JSON

6. VALIDATION
   ├── validate_gs_output(claude_json)
   ├── validate_gs_output(gpt4o_json)
   └── 標記 issues

7. WORD GENERATION
   ├── create_gs_word(student_data, claude_json) → claude.docx
   ├── create_gs_word(student_data, gpt4o_json) → gpt4o.docx
   └── 可選:create_comparison_doc() → comparison.docx

8. LOGGING & CLEANUP
   ├── 記錄到 log file(時間、學生ID、模型版本、issue清單)
   ├── 清除臨時文件(temp/{session_id}/)
   └── 保存輸出 Word 到 output/{session_id}/(7天後自動清除)
```

### 輸出物清單

```
每案輸出:
├── GS_姓名_Claude_日期.docx      → 主要審核版本
├── GS_姓名_GPT4o_日期.docx       → 對比版本
├── GS_姓名_StudentFacts_日期.json → 結構化學生資料(內部存檔)
└── GS_姓名_GenerationLog_日期.txt → 生成記錄(issues、token用量)
```

---

## 第十一題:1-2 週落地計劃

### Day-by-Day 計劃

```
Week 1:核心功能

Day 1(週一)- 環境與架構
  ✅ 建立 GitHub repo(私有)
  ✅ 設定 Python 虛擬環境(poetry 或 venv)
  ✅ 申請/確認 API keys:OpenAI, Anthropic, Google Drive API
  ✅ 建立基礎目錄結構
  ✅ 撰寫固定知識包(直接從現有最佳 prompt 整理)
  預計時間:6-8小時

Day 2(週二)- 文件下載與解析
  ✅ Google Drive API 接入(Service Account)
  ✅ 文件下載函數(支援 PDF/DOCX/JPEG/PNG)
  ✅ PDF/DOCX 文字抽取
  ✅ 文字清理與長度壓縮(pdfplumber + python-docx)
  ✅ 本地測試:用一個真實學生案例測試解析
  預計時間:6-8小時

Day 3(週三)- Student Facts 抽取 + Prompt 組裝
  ✅ Student facts extraction prompt(呼叫 GPT-4o-mini)
  ✅ Prompt assembly 函數(knowledge pack + student data)
  ✅ Token 計算與壓縮邏輯
  ✅ 測試:完整 prompt 輸出,人工確認品質
  預計時間:6-8小時

Day 4(週四)- API 呼叫 + JSON 輸出
  ✅ Claude API 呼叫(含錯誤處理)
  ✅ GPT-4o API 呼叫(含 JSON mode)
  ✅ asyncio 並行呼叫
  ✅ JSON 抽取與驗證函數
  ✅ 端到端測試:Drive link → JSON output
  預計時間:6-8小時

Day 5(週五)- Word 輸出
  ✅ Word 模板函數(python-docx)
  ✅ 封面、Risk Section、GS Answers、Evidence Checklist
  ✅ 字數標記(超過 150 紅色顯示)
  ✅ DRAFT watermark
  ✅ 測試:產出可用的 Word 文件
  預計時間:8小時

Week 2:界面、部署、測試

Day 6(週一)- Streamlit 界面
  ✅ 基礎表單(學生資料、Drive link、顧問備注)
  ✅ 進度條顯示
  ✅ 文件下載按鈕
  ✅ 審核確認 checkbox + 記錄
  預計時間:6小時

Day 7(週二)- 部署與安全
  ✅ 部署到 Railway.app 或 Render.com
  ✅ 設定環境變數(API keys 不在代碼中)
  ✅ 基礎密碼保護(Streamlit secrets 或 simple auth)
  ✅ HTTPS 確認
  預計時間:4小時

Day 8(週三)- 內部測試
  ✅ 找 3-5 個真實學生案例測試
  ✅ 記錄問題清單
  ✅ 修復主要 bugs
  ✅ 優化 prompt(根據測試結果調整知識包)
  預計時間:全天

Day 9(週四)- 修復 + 文件
  ✅ 修復 Day 8 發現的問題
  ✅ 撰寫員工使用說明(1頁 PDF)
  ✅ 撰寫顧問審核 checklist
  預計時間:6小時

Day 10(週五)- 上線
  ✅ 內部員工培訓(30分鐘)
  ✅ 正式開放使用
  ✅ 建立反饋收集機制(簡單 Google Form)
  預計時間:半天
```

### 最小功能清單(Must Have)

```
✅ Google Drive folder link 接入
✅ PDF/DOCX 文字解析
✅ 固定知識包(在代碼/設定檔中,可更新)
✅ Claude + GPT-4o 並行生成
✅ JSON → Word 轉換
✅ 字數驗證
✅ Risk flags 顯示
✅ DRAFT 水印
✅ 基礎密碼保護
✅ 生成記錄 log
```

### 先不做的功能(Nice to Have,Month 2+)

```
❌ OCR(掃描件先人工處理)
❌ RAG/vector DB
❌ 自動評分比較
❌ 版本歷史管理
❌ 多用戶權限系統
❌ 自動更新知識包
❌ 案例管理資料庫
❌ 與 ImmiAccount 直接整合
❌ 郵件自動發送
❌ 客戶端口(只給內部員工)
```

---

## 第十二題:成本估算

### 每案 Token 估算

```
每案 Token 用量:

System Prompt(知識包):      ~20,000 tokens
Student Facts 抽取(input):  ~15,000 tokens  
Student Facts 抽取(output): ~1,000 tokens
Main Generation(input):     ~40,000 tokens(每個模型)
Main Generation(output):    ~5,000 tokens(每個模型)

總計(Claude + GPT-4o 各一次):
  Input tokens:  ~75,000 tokens
  Output tokens: ~12,000 tokens
```

### 成本計算(2025年1月價格)

```
GPT-4o:
  Input:  $2.50 / 1M tokens → 75,000 × $2.50 / 1,000,000 = $0.188 USD
  Output: $10.00 / 1M tokens → 12,000 × $10.00 / 1,000,000 = $0.120 USD
  GPT-4o 小計:~$0.31 USD

Claude Opus 4:
  Input:  $15.00 / 1M tokens → 75,000 × $15.00 / 1,000,000 = $1.125 USD
  Output: $75.00 / 1M tokens → 12,000 × $75.00 / 1,000,000 = $0.900 USD  
  Claude 小計:~$2.03 USD

Student Facts 抽取(GPT-4o-mini):
  Input:  $0.15 / 1M → ~$0.002 USD
  Output: $0.60 / 1M → ~$0.001 USD
  小計:~$0.003 USD

每案 API 總成本:~$2.35 USD(約 AUD 3.65)

如果只用 GPT-4o(不用 Claude Opus):
  每案約 $0.31 USD(AUD 0.48)
  品質下降約 10-15%,但快且便宜
```

### 與外包比較

```
┌─────────────────┬──────────────┬──────────────┬───────────────┐
│ 方案            │ 每案成本     │ 時間         │ 品質可控性    │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ 外包(目前)    │ AUD 100-200  │ 2-5 天       │ 參差不齊      │
│ 本工具(含審核)│ AUD 4-10     │ 1-2 小時     │ 統一標準      │
│  API 成本       │ AUD 3.65     │              │               │
│  員工時間(審核) │ AUD 5-10     │ 30-60分鐘    │               │
├─────────────────┼──────────────┼──────────────┼───────────────┤
│ 節省            │ ~AUD 95-195  │ 80-90% 節省  │ 更高          │
└─────────────────┴──────────────┴──────────────┴───────────────┘
```

### 工程與維護成本

```
開發成本(一次性):
  如果自己做:2週 × 工程師成本
  如果外包開發:AUD 3,000-8,000(Upwork 澳洲/台灣工程師)
  
月度維護成本:
  API 費用(100案/月):AUD 365/月
  Render/Railway 托管:AUD 7-25/月
  知識包更新(每月1-2小時):內部人員時間
  
回本計算(以每月 50 案為基準):
  節省:50 × AUD 150 = AUD 7,500/月
  成本:AUD 200/月(API + 托管 + 維護)
  回本時間:如自建 1 個月,如外包約 1-2 個月
```

---

## 第十三題:20 個最容易踩雷的問題與對策

### 隱私與安全類(最重要)

```
雷 01:學生護照、財務資料透過第三方 API 傳輸
風險:違反澳洲隱私法(Privacy Act 1988)、GDPR(如有歐洲學生)
對策:
  ├── 在服務條款中明確說明 AI 處理(讓學生簽署同意)
  ├── 檢查 Anthropic/OpenAI 的 data processing 政策
  │   └── OpenAI API: 不用於訓練模型(預設),但確認 Enterprise 條款
  │   └── Anthropic: 確認 data retention policy
  ├── 文件下載後即時處理,處理後立即刪除(不長期儲存在伺服器)
  └── 考慮在傳輸前去除敏感識別資訊(如護照號碼只傳名字+出生日期)

雷 02:Google Drive 開放連結被不相關人員訪問
風險:學生個人資料外洩
對策:
  ├── 要求學生使用「限制」分享,並授權公司 service account email
  ├── 或使用「知道連結的人」但設定過期時間(Google Drive 可設)
  └── 系統下載後即時撤銷建議提醒員工通知學生取消分享
```

```
雷 03:Prompt 洩露(員工看到完整 system prompt)
風險:公司 know-how 外洩、競爭對手複製
對策:
  ├── 知識包存在後端環境變數或加密配置文件,不在前端顯示
  ├── Streamlit 界面只顯示輸入和輸出,不顯示 prompt 詳情
  └── 員工帳號只有操作權限,不能查看系統設定

雷 04:API Key 洩露
風險:帳單暴增、服務被濫用
對策:
  ├── 永遠不要把 API key 放在代碼中,用環境變數
  ├── 設定 API 使用限額(OpenAI 和 Anthropic 都支援)
  ├── 定期輪換 API key(每季度)
  └── 啟用 API key 使用通知(異常用量立即告警)
```

### 資料正確性類

```
雷 05:學生資料遺漏(關鍵文件沒上傳到 Drive)
風險:GS 答案缺乏關鍵 evidence,被 VO 質疑
對策:
  ├── Mandatory document checklist(系統自動檢查文件夾是否有對應資料)
  ├── 在 Word 輸出中清楚標示 [DOCUMENT MISSING: 請補充 X]
  └── 員工審核 checklist 明確要求確認每個 evidence claim 都有文件支持

雷 06:掃描件/圖片無法讀取,系統靜默忽略
風險:重要資訊(如財務文件)是掃描件,系統跳過導致 GS 缺失關鍵內容
對策:
  

```
雷 06:掃描件/圖片無法讀取,系統靜默忽略
風險:重要資訊(如財務文件)是掃描件,系統跳過導致 GS 缺失關鍵內容
對策:
  ├── 解析後主動顯示「無法讀取文件清單」給員工確認
  ├── 對圖片類型文件(jpg/png/scanned pdf)顯示明確警告
  ├── Word 輸出中列出 [IMAGE FILE - CONTENT NOT PARSED: 02_passport/scan.jpg]
  └── 員工須人工確認每個無法解析的文件是否影響 GS 內容

雷 07:模型編造學生未提供的事實
風險:GS 答案包含學生實際上無法在面談中確認的資訊,導致移民局不信任
對策:
  ├── System prompt 明確禁止推測(見第八題 Guardrail 1)
  ├── Evidence map 先生成再寫 GS(見第八題 Guardrail 2)
  ├── 員工審核時必須逐句對照原始文件確認每個 claim
  └── Word 中每個 key claim 旁邊標注 [Source: document name]

雷 08:答案超過 150 words 但員工沒發現
風險:ImmiAccount 可能截斷或 VO 認為不遵守格式要求
對策:
  ├── 系統自動計算每題字數,超過 150 在 Word 中顯示紅色警告
  ├── Streamlit 界面顯示每題字數 badge
  ├── Validation 函數拒絕輸出超過 155 words 的答案(要求模型重新壓縮)
  └── 員工審核 checklist 第一項即為字數確認

雷 09:不同學生資料混入同一次生成(Session 污染)
風險:A 學生的財務資訊出現在 B 學生的 GS 答案中
對策:
  ├── 每次生成使用獨立 session ID,臨時文件存在 temp/{session_id}/ 目錄
  ├── 生成完成後立即清理臨時目錄
  ├── 不使用任何全域變數儲存學生資料
  └── 多進程時確認沒有共享狀態
```

### 法規與品質類

```
雷 10:知識包法規資訊過期
風險:GS 答案基於舊版 Direction No. 106 或已廢止的政策要點
對策:
  ├── 知識包頂部明顯標注版本日期和下次審查日期
  ├── 每月指定一人負責核對 Home Affairs 官網更新
  ├── 系統在每次生成時顯示「知識包版本:YYYY-MM-DD,請確認是否最新」
  └── 建立知識包更新 SOP:誰更新、怎麼測試、怎麼發布

雷 11:答案隱含永久居留意圖
風險:VO 認定學生是 genuine temporary entrant 失敗
對策:
  ├── Forbidden phrases 列表(見第八題 Guardrail 2)自動偵測
  ├── 知識包中明確說明:答案要展示臨時居留意圖,要有明確回國計劃
  ├── 每個 Q4(home country ties)答案必須包含至少兩個具體的回國動機
  └── 員工審核 checklist 包含「是否有明確回國計劃論述」

雷 12:課程合理性論述薄弱
風險:VO 認為課程選擇與學生背景不一致(Direction 106 course value factor)
對策:
  ├── 系統抽取學生學歷+工作歷史後,自動評估「課程連結強度」
  ├── 如果連結較弱,在 risk flags 中標注並提示顧問補充說明
  └── 知識包中包含各種「課程升級/轉換」的合理論述範例
```

### 操作與流程類

```
雷 13:員工直接提交未審核的 AI 生成版本
風險:錯誤資訊進入正式申請,損害學生案件
對策:
  ├── Word 文件首頁有不可移除的 DRAFT 水印(需手動更改)
  ├── Streamlit 的審核確認 checkbox 是強制步驟(不勾無法下載最終版)
  ├── 建立雙重審核制度:初級員工生成 → 資深顧問審核 → 才能交付
  └── 所有生成記錄附時間戳,審核簽名記入 log

雷 14:員工上傳錯誤 Drive 連結或沒有訪問權限
風險:系統無法下載文件,生成空洞或錯誤的 GS
對策:
  ├── 系統在開始生成前先測試 Drive 連結可訪問性
  ├── 顯示「已找到 X 個文件,共 Y 個資料夾」讓員工確認後再繼續
  ├── 如果 0 個文件被找到,拒絕繼續生成並顯示明確錯誤訊息
  └── 提供 Drive 連結格式說明與截圖教學

雷 15:同一案件多次生成,版本混亂
風險:員工不知道哪個版本是最新的,提交了舊版本
對策:
  ├── 輸出檔名包含日期時間(精確到分鐘)
  ├── 每次生成在 log 中記錄,Streamlit 可查最近5次生成記錄
  ├── 最終提交版本要求員工在系統中標注「已確認提交版本」
  └── 建議公司統一命名規範:GS_姓名_v1_審核人_日期.docx

雷 16:PDF 是加密的或有複製保護
風險:pdfplumber 無法抽取文字,靜默失敗
對策:
  ├── 解析前檢測 PDF 是否加密(pikepdf 可偵測)
  ├── 如加密,顯示警告並要求員工提供未加密版本
  └── 部分 PDF 即使沒密碼也有複製保護,需使用 PyMuPDF 嘗試備用解析

雷 17:API 呼叫超時或失敗,員工不知道結果
風險:生成中途失敗,員工以為成功或反覆重試造成重複計費
對策:
  ├── 所有 API 呼叫設定明確 timeout(建議 120 秒)
  ├── 失敗時顯示清楚錯誤訊息(不是 500 error,而是「Claude 生成失敗,GPT-4o 已成功,請使用 GPT-4o 版本」)
  ├── 實作簡單重試邏輯(最多 2 次,指數退避)
  └── 如兩個模型都失敗,保存已解析的學生資料 JSON,允許員工重試生成步驟而不需重新下載文件

雷 18:Word 在不同版本 Office 顯示排版錯亂
風險:員工用 Mac 的 Word 或 Google Docs 開啟,格式跑掉
對策:
  ├── python-docx 盡量使用標準樣式,避免複雜 XML 操作
  ├── 測試時在 Windows Word、Mac Word、Google Docs 各確認一次
  ├── 如果排版很重要,考慮同時輸出 PDF 版本
  └── 提供一個「簡潔版」Word(只有純文字 GS answers),排版需求最低

雷 19:顧問備注與學生實際情況衝突
風險:顧問要求「不要提工作空窗期」,但 VO 會看到工作歷史中的空窗,導致 inconsistency
對策:
  ├── System prompt 中說明:顧問備注是方向指引,但不能要求隱瞞或扭曲事實
  ├── 如果顧問備注與文件資料有明顯衝突,系統在 risk flags 中標注
  ├── 知識包中說明:GS 的一致性(consistency)是 Direction 106 的重要考量
  └── 員工培訓強調:AI 工具不能用於捏造或隱瞞資訊,只能用於合法的最佳呈現

雷 20:系統成為員工依賴的黑箱,審核流於形式
風險:員工習慣直接用 AI 輸出,不再認真審核,品質下滑不被發現
對策:
  ├── 建立月度品質抽查機制(資深顧問隨機抽查 10% 已提交案件)
  ├── 記錄每案從生成到提交的修改次數(如果修改率接近零,是警示信號)
  ├── 員工培訓強調:AI 生成是草稿,你的簽名代表你的專業判斷
  └── 定期(每季)讓員工不用工具手寫一份 GS,維持基本能力
```

---

## 第十四題:完整 Prompt 模板框架

### System Prompt(知識包包含在內)

```
你是一位專業的澳洲學生簽證(Subclass 500)Genuine Student(GS)材料撰寫專家。
你服務的是持牌移民代理公司,你的輸出將由人工審核後才提交。

═══════════════════════════════════════════════
【KNOWLEDGE PACK v2025-01-15】
═══════════════════════════════════════════════

## A. GS 法規基礎

GS(Genuine Student)requirement 自 2024-03-23 起取代 GTE。
適用簽證:Student visa Subclass 500
官方要求:ImmiAccount 內以英文作答,每題最多 150 words。
法規依據:Migration Act 1958 s.65 + Direction No. 106

## B. Direction No. 106 七大評估因素

評估官(VO)會整體評估以下因素,你的答案必須主動回應這些因素:

**Factor 1: Home Country Circumstances**
VO 關注:學生在原籍國的家庭、財務、社會連結是否提供回國動機。
正面信號:父母/伴侶在原籍國、擁有財產、有工作職位保留、有社會義務。
負面信號:在原籍國沒有任何連結、全家都在澳洲。

**Factor 2: Potential Circumstances in Australia**
VO 關注:學生在澳洲的潛在居留誘因(親屬、PR 通道、工作機會)。
處理策略:不要否認這些因素,而是展示學習目的和臨時居留意圖更強。

**Factor 3: Value of the Course**
VO 關注:課程是否對學生的職業/學術發展有真實意義。
正面信號:課程直接升級現有技能、雇主要求、產業需求明確。
負面信號:課程等級比已有學歷低(需特別解釋)、與工作完全無關。

**Factor 4: Immigration History**
VO 關注:過去的簽證記錄是否符合申請目的。
正面信號:乾淨的簽證記錄、如實說明過去歷史。
負面信號:曾超期居留、曾被拒簽(需在 GS 中解釋,不要迴避)。

**Factor 5: Course and Provider Knowledge**
VO 關注:學生是否真的了解要讀的課程和學校。
正面信號:能說出課程具體內容、為什麼選這個 provider、了解學費和生活成本。
負面信號:答案空泛,任何學生都可以套用。

**Factor 6: Living Knowledge**
VO 關注:學生是否做過充分準備,了解澳洲生活。
正面信號:了解居住安排、交通、生活費用、澳洲文化。

**Factor 7: Inconsistency / Unrelated Course / Visa History**
VO 關注:申請材料是否有前後矛盾之處。
處理策略:主動解釋任何可能看起來矛盾的地方,不要讓 VO 自己猜測。

## C. 150-Word Answer 寫作技巧

**結構建議(每題):**
- 句1-2:開門見山,直接回答問題核心
- 句3-5:提供具體證據/事實支持(用數字、職稱、課程名稱等具體資訊)
- 句6-7:連結到 Direction 106 相關 factor
- 句8-9:展示準備充分、回國計劃或臨時居留意圖
- 句10(如有空間):加強最重要的 positive factor

**禁止事項:**
❌ 不能說:will settle in Australia / plan to stay permanently / hope to get PR
❌ 不能有空泛的讚美:Australia is the best country...
❌ 不能直接複製範例,必須個人化
❌ 不能用第三人稱,必須用第一人稱 "I"
❌ 不能引用具體法條或簽證規定(容易出錯且 VO 不需要)
❌ 不能捏造或推測學生未提供的事實

**正面寫法:**
✅ 使用具體數字:3 years of experience / AUD 45,000 tuition / 12 months savings
✅ 連結證據:My employer has confirmed... / As shown in my CoE...
✅ 展示研究:I have researched accommodation in Melbourne averaging...
✅ 明確回國計劃:Upon completing my studies, I intend to return to [country] where...

## D. 公司優秀 GS 範例

### 範例 1:台灣會計師申請 Master of Business Analytics

**Student Profile:** 28歲,台灣籍,CPA,3年會計事務所經驗,申請 UoM MBAn
**Risk Level:** 低(乾淨簽證記錄,明確職業升級路徑,強家庭連結)

Q1 Why do you want to study in Australia?
---
Australia's leadership in data-driven finance makes it uniquely suited for my professional development. Melbourne specifically hosts the Asia-Pacific headquarters of four firms where I aim to work upon returning to Taiwan, providing networking opportunities unavailable elsewhere. I have researched the University of Melbourne's MBAn program extensively, confirming its curriculum directly addresses the skills gap I identified in my current accounting practice, where data analytics capabilities increasingly determine promotion prospects. I understand living costs in Melbourne average AUD 2,000-2,500 monthly and have secured accommodation through the university's housing portal. My parents remain in Taipei, where I also maintain my CPA registration, ensuring I have compelling personal and professional reasons to return after completing my 18-month program.
[Word count: 120]

Q4 What are your ties to your home country?
---
My ties to Taiwan are substantial and multi-layered. My parents, both in their late 50s, reside in our family home in Taipei, and as their only child, I have cultural and familial obligations to return and support them as they age. I currently hold an active CPA licence with the Financial Supervisory Commission of Taiwan, which requires ongoing Taiwanese residency to maintain its full commercial value. My employer, ABC Accounting Firm, has confirmed in writing that my position will be preserved during my studies and that they are sponsoring part of my tuition, contingent on my return. I also co-own a residential property in New Taipei City with my parents. These personal, professional, and financial anchors make Taiwan the clear centre of my life plans after graduation.
[Word count: 130]

---

### 範例 2:越南學生轉換課程方向(需解釋 inconsistency)

**Student Profile:** 24歲,越南籍,護理學士,申請 Diploma of Business
**Risk Level:** 中(課程方向轉換需解釋,財務部分依賴父母)

Q3 How does this course relate to your current or future employment?
---
While my bachelor's degree is in nursing, my career focus has shifted toward healthcare administration, a field that demands strong business management skills. During three years working at Hanoi's Bach Mai Hospital, I observed that clinical departments with business-trained administrators consistently secured better resource allocation and improved patient outcomes. I have been informally managing my ward's supply procurement, a responsibility that highlighted my lack of formal business training. The Diploma of Business at RMIT Vietnam's partner institution will equip me with financial management, operations, and strategic planning skills directly applicable to hospital administration roles. Upon returning to Vietnam, I have a confirmed position offer as Administrative Coordinator at my current hospital, a role created specifically for candidates with both healthcare experience and business qualifications. This course is therefore a deliberate and evidence-based career transition.
[Word count: 143]

---

### 範例 3:中國學生有過往旅遊簽證(主動說明歷史)

### 範例 4:印度學生財務資金來自父母(解釋資金來源)

### 範例 5:有澳洲親屬但展示臨時居留意圖

### 範例 6:課程等級比學歷低(ELICOS/Diploma after Degree)

[範例 3-6 結構與範例 1-2 相同,此處省略以控制 token]

## E. 常見風險處理策略

| 風險類型 | 處理策略 |
|---------|---------|
| 資金來自父母 | 說明父母職業和資產,強調這是家庭投資而非貸款,並說明有能力償還 |
| 課程等級下降 | 說明此課程是「補充性」的,填補特定技能空缺,而非重讀低端課程 |
| 在澳有親屬 | 承認這一點,但強調獨立的學習計劃和原籍國更強的連結 |
| 過往拒簽 | 主動說明原因,展示此次申請已解決當時的問題 |
| 無工作經驗 | 強調學術連貫性和課程對職涯啟動的價值 |

═══════════════════════════════════════════════
【OUTPUT REQUIREMENTS】
═══════════════════════════════════════════════

你必須以有效的 JSON 格式輸出,完全符合以下 schema,不要輸出任何 JSON 以外的文字。
[Output schema 見第七題 JSON 定義]
```

### Student Facts Prompt(第一步:資料抽取)

```
以下是學生提供的所有文件原文。

請仔細閱讀所有文件,然後輸出一份結構化的 student_facts JSON。

規則:
1. 只輸出文件中明確記載的資訊,不要推測
2. 如果某個欄位在文件中找不到,填入 null 並在 missing_info 中列出
3. 對於財務數字,記錄原始貨幣和金額

=== 文件內容開始 ===

[01_form500]
{form500_text}

[02_passport]
{passport_text}

[03_finance]
{finance_text}

[04_course]
{course_text}

[05_academic]
{academic_text}

[06_employment]
{employment_text}

[07_other]
{other_text}

=== 文件內容結束 ===

請輸出以下 JSON 格式:
{
  "student_facts": {
    "full_name": null,
    "date_of_birth": null,
    "nationality": null,
    "passport_number": null,
    "current_location": null,
    "education_history": [
      {"institution": null, "degree": null, "field": null, "year_completed": null, "gpa": null}
    ],
    "work_history": [
      {"employer": null, "title": null, "start_date": null, "end_date": null, "is_current": false}
    ],
    "course_applied": {
      "provider": null,
      "course_name": null,
      "level": null,
      "start_date": null,
      "duration": null,
      "tuition_total": null,
      "coe_number": null
    },
    "financial_summary": {
      "total_funds_available": null,
      "currency": null,
      "sources": [],
      "months_of_bank_statements": null
    },
    "visa_history": {
      "previous_australia_visas": [],
      "refusals": [],
      "current_visa": null
    },
    "home_country_ties": {
      "family_in_home_country": null,
      "property_ownership": null,
      "job_offer_on_return": null,
      "other_ties": []
    },
    "australia_connections": {
      "family_in_australia": null,
      "previous_australia_study": null,
      "other_connections": []
    },
    "english_proficiency": {
      "test_type": null,
      "score": null,
      "test_date": null
    }
  },
  "missing_info": [],
  "potential_risk_flags": [],
  "document_quality_notes": []
}
```

### Main GS Generation Prompt(第二步:生成 GS)

```
以下是已驗證的學生資料(已從原始文件中結構化抽取):

=== STUDENT FACTS ===
{student_facts_json}

=== CONSULTANT NOTES ===
{consultant_notes}

=== IDENTIFIED RISK AREAS ===
{risk_flags}

=== TASK ===

基於以上學生資料和 Knowledge Pack 中的規範與範例,生成完整的 GS materials。

執行步驟:

STEP 1 - 建立 evidence_map
列出每一個你計劃在 GS answers 中使用的事實,標注其來源文件。
標出任何你無法從文件中確認的資訊,使用 [EVIDENCE NEEDED: description]。

STEP 2 - 評估 Direction 106 各 Factor
對每個 factor 評分(STRONG / ADEQUATE / WEAK / CONCERN),說明理由。

STEP 3 - 撰寫 4 個 GS Answers
每題嚴格控制在 150 words 以內。
每個 claim 必須對應 evidence_map 中的來源。
語氣:專業、第一人稱、具體、真誠。

STEP 4 - Self-Check
逐一確認:字數、無禁用語句、無推測事實、無法規引用錯誤。

輸出格式:嚴格遵守 Knowledge Pack 中定義的 JSON schema,不輸出任何其他文字。
```

### Forbidden Phrases 清單(embedded in system prompt)

```python
FORBIDDEN_PHRASES = [
    # 永久居留相關
    "permanent resident", "permanent residency", "get PR", "obtain PR",
    "settle in australia", "settle permanently", "stay permanently",
    "never return", "immigrate", "immigration goal",
    
    # 過於政治化或不相關
    "australia is the best", "australia is the greatest",
    "dream of living in australia",
    
    # 虛假承諾
    "i guarantee", "i promise to return",
    "i will definitely", "i assure you",
    
    # 空洞讚美
    "world-class in every way",
    "unparalleled opportunities",
    
    # 法規錯誤引用
    "under section", "as per migration act",
    "according to visa regulation",
    "schedule 8",
]
```

### Self-Check Schema(要求模型自我驗證)

```json
{
  "self_check": {
    "q1_word_count": 128,
    "q2_word_count": 143,
    "q3_word_count": 137,
    "q4_word_count": 149,
    "all_under_150": true,
    "forbidden_phrases_found": [],
    "claims_without_evidence": [],
    "regulation_references_found": [],
    "fabricated_facts_risk": "LOW",
    "home_country_ties_addressed": true,
    "return_intention_stated": true,
    "course_rationale_specific": true,
    "inconsistencies_noted": [],
    "overall_confidence": 0.91,
    "reviewer_attention_items": [
      "Q2 mentions employer support letter - please confirm document exists in Drive",
      "Financial amount stated as AUD 45,000 - please verify against bank statement"
    ]
  }
}
```

---

## 第十五題:最終推薦方案

### 如果我是顧問,我的建議

**第一版就做這一個方案:**

> **Streamlit + Python 後端 + Google Drive API + Claude/GPT-4o API + python-docx Word 輸出**
> 全部在一個 Python monorepo,部署在 Railway.app,10 個工作天上線。

---

**為什麼這樣選,而不是其他方案:**

**為什麼不選 Google Sheet + Apps Script:**
Apps Script 呼叫外部 API 有嚴格的執行時間限制(6分鐘),而文件下載 + 解析 + 雙模型生成總時間很容易超過這個限制。一旦超時就要做複雜的非同步設計,反而更難維護。Streamlit 沒有這個限制。

**為什麼不選 n8n/Make:**
這類無代碼工具擅長簡單線性流程,但你的需求涉及文件解析、token 計算、JSON 驗證、Word 生成等需要 Python 邏輯的步驟,用 n8n 做會非常勉強,而且當流程複雜到一定程度後,視覺化流程圖反而比代碼更難維護。

**為什麼不選 Next.js:**
開發時間至少翻倍(需要前後端分離、API routes、部署配置),但對使用者體驗的提升在 MVP 階段不值得。Streamlit 的界面已經完全夠用,等到需求穩定、使用量上升後再遷移到 Next.js 是更理性的選擇。

**為什麼不做 RAG:**
你的知識庫(Direction 106 + GS 規範 + 公司範例)非常穩定且體積小,完全可以直接放進 system prompt。RAG 的價值在於需要動態查詢大量外部知識,這個場景不符合。把時間花在 RAG 上是浪費,直接做固定知識包是正確的。

---

**三個關鍵成功因素:**

**第一:知識包品質決定一切**
工具本身只是把你已驗證的人工操作自動化。你在 web 界面手動用最佳 prompt 做出 99% 可用的 GS,就是因為你有好的 context。第一週最重要的工作不是寫代碼,而是把你腦子裡的最佳 prompt 完整文字化,整理成可複用的知識包。這份工作比所有技術開發都重要。

**第二:人工審核不能省**
這個系統的定位是「幫顧問把初稿從 0 做到 80 分」,而不是「替代顧問判斷」。你的資深顧問的審核不是形式,是保護公司和學生的最後防線。在工具設計上要讓審核「容易做」而不是「容易跳過」——Word 中清楚標注每個 claim 的來源、evidence checklist 要明確、DRAFT 水印要顯眼。

**第三:先用,再完善**
第一版上線後一定有各種問題,學生文件有各種奇怪格式,prompt 對某些 edge case 效果不好,員工有各種操作問題。這些問題只有在真實使用中才會出現。10 天上線一個 80 分的版本,然後在真實使用中快速迭代,遠比花 2 個月做一個「完美」但從未被真實業務驗證的系統更有價值。

---

**建議的第一個月里程碑:**

```
Week 1-2:上線(見第十一題計劃)
Week 3:  收集真實使用反饋,修復前 5 個最大問題
Week 4:  優化 prompt(根據 VO 偏好調整),加入掃描件 OCR 支援
Month 2: 根據使用量決定是否需要加功能(案例管理、版本歷史等)
Month 3: 評估是否需要遷移到更正式的架構
```

**最後一句話:**

你已經驗證了核心價值——模型會寫,品質夠用。現在唯一的問題是把這個已驗證的價值打包成可重複交付的工具。不要在這個階段追求完美架構,追求的是:**讓更多人能穩定地做到你已經能做到的事情**。10 天,上線,用起來,再說。
📊 Token:输入 22167 / 输出 26387 | 费用:$0.462306 | 耗时:400547ms | finish_reason:stop | 续写:1
模型路由失敗 / 卡住紀錄
Round 1 - Grok first alias failed error
{
  "job_id": "20260513-164249-grok-4.3--8155ff5f",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T16:42:49.198Z",
  "model": "grok(4.3)",
  "prompt": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。\n\n【背景】\n我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。\n\n公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。\n\n【預計資料夾/知識來源】\n1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。\n2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。\n3. 成功案例 GS 文件夾:已成功學生 GS。\n4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。\n目標是讓 AI 能持續參考、持續進步。\n\n【本地範例資料概況】\n本地資料夾:C:\\Users\\F\\AiFolder\\Projects\\SC_AI\\GS撰寫技巧補充文件夾\n包含:\n- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。\n- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。\n範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。\n\n【官方資料依據,請納入分析】\n1. Australian Department of Home Affairs - Genuine Student requirement\n來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement\n重點:\n- GS requirement applies to student visa applications lodged on or after 23 March 2024; before that date assessed under GTE.\n- Applicants must be genuine applicants for entry and stay as a student and show understanding that studying in Australia is the primary reason.\n- Online form asks: current circumstances including family/community/employment/economic ties; why this course/provider and understanding of course/living in Australia; how the course benefits the applicant; other relevant information; extra question for prior student visa / applying in Australia from non-student visa.\n- Home Affairs prefers responses in the application form rather than separate GS statement.\n- 150 words per response, all in English.\n- Supporting documents in ImmiAccount matter; more weight is given to statements supported by evidence.\n- Assessment considers circumstances, immigration history, compliance with visa conditions, course/provider/living knowledge, value of course to future, salary/employment benefit, and other relevant matters.\n\n2. Home Affairs Document Checklist Tool\n來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool\n重點:\n- GS answers must be English and max 150 words per question.\n- Supporting documents may include qualifications, transcripts, proof of employment, CV/resume with education/employment history.\n- In line with Ministerial Direction 106, factors include circumstances in home country, potential circumstances in Australia, value of course to future, immigration history, other relevant matter; if minor, intentions of parent/legal guardian/spouse.\n\n3. Ministerial Direction No. 106 - Assessing the genuine entry and stay requirements for Student visa and Student Guardian visa applications\n來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf\n重點:\n- Commences 23 March 2024 and applies to Subclass 500 Student visa applications on or after that date.\n- Genuine student criterion refers to clause 500.212 of Schedule 2 to the Regulations.\n- Decision makers should not use listed factors as a mechanical checklist; they assess circumstances as a whole.\n- Further scrutiny may apply where there is migration fraud risk, concerning immigration history, intended course unrelated to previous studies/employment, inconsistencies, applicant holds/held certain visas including student visa/visitor/485 etc.\n- Factors include home country circumstances, reasons for not studying similar course locally, family/community/employment ties, economic circumstances, military/civil unrest, knowledge of course/provider/living in Australia, level of research, whether visa is used to maintain residence, value of course to future, consistency with past education/employment, expected remuneration, immigration history, and for minors the intentions of parent/legal guardian/spouse.\n\n【我想問你】\n1. 這樣的工具方向合理嗎?哪些部分合理,哪些部分有風險?\n2. 如果把所有成功案例、失敗案例、法令資料、客戶資料都給模型,會不會導致 token 越來越大、反而失去焦點?應如何避免?\n3. 你會如何設計更好的方案?請具體到架構,例如 Google Drive 文件接入、OCR/文件解析、結構化抽取、RAG、案例檢索、prompt pipeline、多模型生成、評分/審核、Word 輸出、人類審核、版本保存。\n4. 成功案例與失敗案例應如何被 AI 使用?是直接塞 prompt、做 vector DB、做分類/標籤、做 rubric、還是 fine-tuning?請比較。\n5. 最新移民局公告/法令資料應如何自動更新與引用?如何避免過期法規、幻覺引用、錯誤法規?\n6. 因為客戶資料包含護照、身份、財務、家庭等敏感資料,請分析資料安全、權限、審計、供應商 API、資料出境/保留/刪除、隱私合規風險。\n7. 多模型策略:Claude/OpenAI/DeepSeek/Gemini/Grok/Minimax 等同時生成是否值得?是否應該每個模型生成完整 GS,還是分工,例如抽取、風險審核、撰寫、評分?\n8. 目前澳洲 GS 官方是每題 150 words 且偏好填入表格,而公司卻想輸出完整 GS Word。如何設計輸出格式最務實?是否應包含 150-word ImmiAccount answers + evidence-backed internal long note + supporting document checklist?\n9. 請提出 MVP 版本、V1 版本、V2 版本的落地路線圖與大概成本/時間/風險。\n10. 請給出你建議的最終架構與流程,並列出關鍵資料表/資料模型、prompt 模板策略、評分 rubric、人類審核 checklist。\n\n請把回答寫得完整,不要短答。請直接給結論、架構、風險、建議與可執行步驟。",
  "prompt_preview": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。 【背景】 我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。 公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最",
  "ref_image": null,
  "max_tokens": 16000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T16:42:49.250Z",
  "completed_at": "2026-05-13T16:42:49.249Z",
  "duration_ms": 19,
  "error": "[grok(4.3)→grok(4.3)] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 grok(4.3) 无可用渠道 (request id: 2026051400424920425660088821540)\",\"type\":\"one_api_error\"}}"
}
Round 1 - MiniMax first alias failed error
{
  "job_id": "20260513-164249-minimax-M2.7--d3d76a15",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T16:42:49.251Z",
  "model": "minimax(M2.7)",
  "prompt": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。\n\n【背景】\n我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。\n\n公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。\n\n【預計資料夾/知識來源】\n1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。\n2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。\n3. 成功案例 GS 文件夾:已成功學生 GS。\n4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。\n目標是讓 AI 能持續參考、持續進步。\n\n【本地範例資料概況】\n本地資料夾:C:\\Users\\F\\AiFolder\\Projects\\SC_AI\\GS撰寫技巧補充文件夾\n包含:\n- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。\n- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。\n範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。\n\n【官方資料依據,請納入分析】\n1. Australian Department of Home Affairs - Genuine Student requirement\n來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement\n重點:\n- GS requirement applies to student visa applications lodged on or after 23 March 2024; before that date assessed under GTE.\n- Applicants must be genuine applicants for entry and stay as a student and show understanding that studying in Australia is the primary reason.\n- Online form asks: current circumstances including family/community/employment/economic ties; why this course/provider and understanding of course/living in Australia; how the course benefits the applicant; other relevant information; extra question for prior student visa / applying in Australia from non-student visa.\n- Home Affairs prefers responses in the application form rather than separate GS statement.\n- 150 words per response, all in English.\n- Supporting documents in ImmiAccount matter; more weight is given to statements supported by evidence.\n- Assessment considers circumstances, immigration history, compliance with visa conditions, course/provider/living knowledge, value of course to future, salary/employment benefit, and other relevant matters.\n\n2. Home Affairs Document Checklist Tool\n來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool\n重點:\n- GS answers must be English and max 150 words per question.\n- Supporting documents may include qualifications, transcripts, proof of employment, CV/resume with education/employment history.\n- In line with Ministerial Direction 106, factors include circumstances in home country, potential circumstances in Australia, value of course to future, immigration history, other relevant matter; if minor, intentions of parent/legal guardian/spouse.\n\n3. Ministerial Direction No. 106 - Assessing the genuine entry and stay requirements for Student visa and Student Guardian visa applications\n來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf\n重點:\n- Commences 23 March 2024 and applies to Subclass 500 Student visa applications on or after that date.\n- Genuine student criterion refers to clause 500.212 of Schedule 2 to the Regulations.\n- Decision makers should not use listed factors as a mechanical checklist; they assess circumstances as a whole.\n- Further scrutiny may apply where there is migration fraud risk, concerning immigration history, intended course unrelated to previous studies/employment, inconsistencies, applicant holds/held certain visas including student visa/visitor/485 etc.\n- Factors include home country circumstances, reasons for not studying similar course locally, family/community/employment ties, economic circumstances, military/civil unrest, knowledge of course/provider/living in Australia, level of research, whether visa is used to maintain residence, value of course to future, consistency with past education/employment, expected remuneration, immigration history, and for minors the intentions of parent/legal guardian/spouse.\n\n【我想問你】\n1. 這樣的工具方向合理嗎?哪些部分合理,哪些部分有風險?\n2. 如果把所有成功案例、失敗案例、法令資料、客戶資料都給模型,會不會導致 token 越來越大、反而失去焦點?應如何避免?\n3. 你會如何設計更好的方案?請具體到架構,例如 Google Drive 文件接入、OCR/文件解析、結構化抽取、RAG、案例檢索、prompt pipeline、多模型生成、評分/審核、Word 輸出、人類審核、版本保存。\n4. 成功案例與失敗案例應如何被 AI 使用?是直接塞 prompt、做 vector DB、做分類/標籤、做 rubric、還是 fine-tuning?請比較。\n5. 最新移民局公告/法令資料應如何自動更新與引用?如何避免過期法規、幻覺引用、錯誤法規?\n6. 因為客戶資料包含護照、身份、財務、家庭等敏感資料,請分析資料安全、權限、審計、供應商 API、資料出境/保留/刪除、隱私合規風險。\n7. 多模型策略:Claude/OpenAI/DeepSeek/Gemini/Grok/Minimax 等同時生成是否值得?是否應該每個模型生成完整 GS,還是分工,例如抽取、風險審核、撰寫、評分?\n8. 目前澳洲 GS 官方是每題 150 words 且偏好填入表格,而公司卻想輸出完整 GS Word。如何設計輸出格式最務實?是否應包含 150-word ImmiAccount answers + evidence-backed internal long note + supporting document checklist?\n9. 請提出 MVP 版本、V1 版本、V2 版本的落地路線圖與大概成本/時間/風險。\n10. 請給出你建議的最終架構與流程,並列出關鍵資料表/資料模型、prompt 模板策略、評分 rubric、人類審核 checklist。\n\n請把回答寫得完整,不要短答。請直接給結論、架構、風險、建議與可執行步驟。",
  "prompt_preview": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。 【背景】 我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。 公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最",
  "ref_image": null,
  "max_tokens": 16000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T16:42:49.266Z",
  "completed_at": "2026-05-13T16:42:49.266Z",
  "duration_ms": 12,
  "error": "[minimax(M2.7)→minimax(M2.7)] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 minimax(M2.7) 无可用渠道 (request id: 2026051400424925572820028500805)\",\"type\":\"one_api_error\"}}"
}
Round 1 - Claude first alias failed error
{
  "job_id": "20260513-164249-claude-sonnet--72bcbf7a",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T16:42:49.259Z",
  "model": "claude(sonnet)",
  "prompt": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。\n\n【背景】\n我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。\n\n公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。\n\n【預計資料夾/知識來源】\n1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。\n2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。\n3. 成功案例 GS 文件夾:已成功學生 GS。\n4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。\n目標是讓 AI 能持續參考、持續進步。\n\n【本地範例資料概況】\n本地資料夾:C:\\Users\\F\\AiFolder\\Projects\\SC_AI\\GS撰寫技巧補充文件夾\n包含:\n- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。\n- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。\n範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。\n\n【官方資料依據,請納入分析】\n1. Australian Department of Home Affairs - Genuine Student requirement\n來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement\n重點:\n- GS requirement applies to student visa applications lodged on or after 23 March 2024; before that date assessed under GTE.\n- Applicants must be genuine applicants for entry and stay as a student and show understanding that studying in Australia is the primary reason.\n- Online form asks: current circumstances including family/community/employment/economic ties; why this course/provider and understanding of course/living in Australia; how the course benefits the applicant; other relevant information; extra question for prior student visa / applying in Australia from non-student visa.\n- Home Affairs prefers responses in the application form rather than separate GS statement.\n- 150 words per response, all in English.\n- Supporting documents in ImmiAccount matter; more weight is given to statements supported by evidence.\n- Assessment considers circumstances, immigration history, compliance with visa conditions, course/provider/living knowledge, value of course to future, salary/employment benefit, and other relevant matters.\n\n2. Home Affairs Document Checklist Tool\n來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool\n重點:\n- GS answers must be English and max 150 words per question.\n- Supporting documents may include qualifications, transcripts, proof of employment, CV/resume with education/employment history.\n- In line with Ministerial Direction 106, factors include circumstances in home country, potential circumstances in Australia, value of course to future, immigration history, other relevant matter; if minor, intentions of parent/legal guardian/spouse.\n\n3. Ministerial Direction No. 106 - Assessing the genuine entry and stay requirements for Student visa and Student Guardian visa applications\n來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf\n重點:\n- Commences 23 March 2024 and applies to Subclass 500 Student visa applications on or after that date.\n- Genuine student criterion refers to clause 500.212 of Schedule 2 to the Regulations.\n- Decision makers should not use listed factors as a mechanical checklist; they assess circumstances as a whole.\n- Further scrutiny may apply where there is migration fraud risk, concerning immigration history, intended course unrelated to previous studies/employment, inconsistencies, applicant holds/held certain visas including student visa/visitor/485 etc.\n- Factors include home country circumstances, reasons for not studying similar course locally, family/community/employment ties, economic circumstances, military/civil unrest, knowledge of course/provider/living in Australia, level of research, whether visa is used to maintain residence, value of course to future, consistency with past education/employment, expected remuneration, immigration history, and for minors the intentions of parent/legal guardian/spouse.\n\n【我想問你】\n1. 這樣的工具方向合理嗎?哪些部分合理,哪些部分有風險?\n2. 如果把所有成功案例、失敗案例、法令資料、客戶資料都給模型,會不會導致 token 越來越大、反而失去焦點?應如何避免?\n3. 你會如何設計更好的方案?請具體到架構,例如 Google Drive 文件接入、OCR/文件解析、結構化抽取、RAG、案例檢索、prompt pipeline、多模型生成、評分/審核、Word 輸出、人類審核、版本保存。\n4. 成功案例與失敗案例應如何被 AI 使用?是直接塞 prompt、做 vector DB、做分類/標籤、做 rubric、還是 fine-tuning?請比較。\n5. 最新移民局公告/法令資料應如何自動更新與引用?如何避免過期法規、幻覺引用、錯誤法規?\n6. 因為客戶資料包含護照、身份、財務、家庭等敏感資料,請分析資料安全、權限、審計、供應商 API、資料出境/保留/刪除、隱私合規風險。\n7. 多模型策略:Claude/OpenAI/DeepSeek/Gemini/Grok/Minimax 等同時生成是否值得?是否應該每個模型生成完整 GS,還是分工,例如抽取、風險審核、撰寫、評分?\n8. 目前澳洲 GS 官方是每題 150 words 且偏好填入表格,而公司卻想輸出完整 GS Word。如何設計輸出格式最務實?是否應包含 150-word ImmiAccount answers + evidence-backed internal long note + supporting document checklist?\n9. 請提出 MVP 版本、V1 版本、V2 版本的落地路線圖與大概成本/時間/風險。\n10. 請給出你建議的最終架構與流程,並列出關鍵資料表/資料模型、prompt 模板策略、評分 rubric、人類審核 checklist。\n\n請把回答寫得完整,不要短答。請直接給結論、架構、風險、建議與可執行步驟。",
  "prompt_preview": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。 【背景】 我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。 公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最",
  "ref_image": null,
  "max_tokens": 16000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T16:42:49.277Z",
  "completed_at": "2026-05-13T16:42:49.277Z",
  "duration_ms": 14,
  "error": "[claude(sonnet)→claude(sonnet)] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 claude(sonnet) 无可用渠道 (request id: 2026051400424926852240014562251)\",\"type\":\"one_api_error\"}}"
}
Round 1 - MiniMax generic retry pending at previous report time success
{
  "job_id": "20260513-164410-minimax-e9997ea3",
  "type": "ask_model",
  "status": "success",
  "created_at": "2026-05-13T16:44:10.033Z",
  "model": "minimax",
  "prompt": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。\n\n【背景】\n我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。\n\n公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最適合的一份作為簽證材料。\n\n【預計資料夾/知識來源】\n1. GS撰寫技巧補充文件夾:優秀成功 GS 範例、最新法令資料、移民局公告自動抓取、人力補充的新文件材料。\n2. 客戶資料:學生所有證件掃描件、Form 500 個人信息表格、照片等。\n3. 成功案例 GS 文件夾:已成功學生 GS。\n4. 失敗案例 GS 文件夾與拒簽信:失敗 GS 與拒簽信。\n目標是讓 AI 能持續參考、持續進步。\n\n【本地範例資料概況】\n本地資料夾:C:\\Users\\F\\AiFolder\\Projects\\SC_AI\\GS撰寫技巧補充文件夾\n包含:\n- Chuhan WU-GS.pdf,12 頁,約 24,361 字元,成功案例 GS 範本。\n- 範本-Chuhan WU-Form 500 Part A+B_2025 Sep.docx,約 36,102 字元,Form 500 個人信息表格範本。\n範例 GS 的做法:按 GS 問題分段,每段先有 Summary,再有 Detailed version;整合學生教育背景、家庭關係、資金證明、赴澳原因、課程選擇、學後規劃、照片/獎項/工作生活照片等。案例包含 Navitas English General English 課程、家庭在中國與澳洲的支持、約 AUD 84,964 資金、未來美妝/形象設計職涯方向等。\n\n【官方資料依據,請納入分析】\n1. Australian Department of Home Affairs - Genuine Student requirement\n來源:https://immi.homeaffairs.gov.au/visas/getting-a-visa/visa-listing/student-500/genuine-student-requirement\n重點:GS applies on/after 23 Mar 2024; GTE before then;online form asks current circumstances, course/provider reason and understanding, benefit, other information, extra question for prior student visa/applying in Australia from non-student visa;Home Affairs prefers form responses rather than separate GS statement;150 words per response;English only;supporting docs matter and evidence-supported statements get more weight。\n2. Home Affairs Document Checklist Tool\n來源:https://immi.homeaffairs.gov.au/visas/web-evidentiary-tool\n重點:GS answers max 150 words per question;supporting docs can include qualifications/transcripts/employment/CV;Direction 106 factors: home country circumstances, potential circumstances in Australia, value of course, immigration history, other relevant matters, minor's parent/legal guardian/spouse intentions。\n3. Ministerial Direction No. 106\n來源:https://immi.homeaffairs.gov.au/Visa-subsite/files/direction-no-106.pdf\n重點:commences 23 Mar 2024;applies to Subclass 500;decision makers should not use factors as a mechanical checklist;further scrutiny for fraud risk, concerning immigration history, unrelated course, inconsistencies, prior/held visas;factors include home country circumstances, reasons not studying locally, ties, economic circumstances, knowledge of course/provider/living, research, value to future, consistency with past education/employment, remuneration, immigration history, minor intentions。\n\n【問題】\n請分析:工具方向是否合理;token 是否會越來越大並失焦;更好的架構;成功/失敗案例如何用;法令資料自動更新與引用;資料安全與供應商風險;多模型策略;官方 150-word GS 與 Word 完整稿的輸出取捨;MVP/V1/V2 路線圖;最終架構、資料模型、prompt 策略、評分 rubric、人類審核 checklist。\n\n請完整回答,不要短答。",
  "prompt_preview": "你是一位資深 AI 產品架構師、RAG/LLM 系統工程顧問,並熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement 文件準備流程。請用繁體中文回答,內容要具體、可落地、偏企業內部工具設計,不要只講泛泛概念。 【背景】 我的公司是澳洲留學公司。學生簽證目前已從 GTE 轉為 GS (Genuine Student) requirement。公司目前製作一份 GS 的外包價格很高,約 100-200 澳幣,通常由有留學/申請經驗、會研究澳洲移民局最新政策與案例的人員撰寫。但我用 Claude Opus 4.6 與 ChatGPT 5.4 web 版本,在提供要求與參考材料後,生成的 GS 品質已經很不錯,甚至可能超過人力外包。 公司想做一個內部工具:有權限的員工輸入 Google Drive 學生文件夾連結,並指定學生的撰寫方向/注意事項;系統讀取學生資料後,分別調用 Claude/OpenAI/DeepSeek/Gemini 等最新大模型,由各模型分析並撰寫完整學生 GS Word;最後員工核對各版本,選擇最",
  "ref_image": null,
  "max_tokens": 16000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T17:00:58.906Z",
  "completed_at": "2026-05-13T17:00:58.905Z",
  "duration_ms": 1008866,
  "model_id": "MiniMax-M2.7",
  "response_preview": "# GS 智能生成系統完整架構分析\n\n## 一、工具方向合理性評估\n\n### 1.1 核心價值主張\n\n你的工具方向**高度合理**,但需滿足特定前提條件:\n\n```\n┌─────────────────────────────────────────────────────────┐\n│  合理性評估維度                                          │\n├─────────────────────────────────────────────────────────┤\n│  ✓ GS 標準化程度高:官方明確定義 5 大問題領域           │\n│  ✓ 150 words/問題限制:明確邊界,可量化目標             │\n│  ✓ Direction 106:12 項評估因素,邏輯可程式化           │\n│  ✓ 市場替代成本高:外包 100-200 AUD/份                   │\n│  ✓ 知識累積需求強:案例庫持續增值                        │\n│                                                         │\n│  ⚠ 前提:移民政策變動需即時同步                         │\n│  ⚠ 前提:最終責任歸屬需明確(AI 輔助 vs AI 生成)       │\n│  ⚠ 前提:隱私合規需認真對待                             │\n└─────────────────────────────────────────────────────────┘\n```\n\n### 1.2 GS vs GTE 的系統化差異\n\n| 維度 | GTE | GS (2024年後) | 對系統設計的影響 |\n|------|-----|---------------|------------------|\n| 問題結構 | 自由敘述 | 5大問題領域 | ✓ 可模板化 |\n| 字數限制 | 無明確限制 | 150 words/問題 | ✓ 可量化校驗 |\n| 評估標準 | 個案判斷 | Direction 106 12因素 | ✓ 邏輯可歸類 |\n| 官方傾向 | 偏好獨立文件",
  "reasoning_preview": "這是一個非常詳細的請求,用戶是一間澳洲留學公司,想要開發一個內部工具來自動生成學生簽證(Subclass 500)的Genuine Student (GS)文件。\n\n讓我系統性地分析這個需求:\n\n1. **工具方向是否合理** - 需要評估\n2. **Token是否會越來越大並失焦** - 架構問題\n3. **更好的架構** - 系統設計\n4. **成功/失敗案例如何用** - RAG策略\n5. **法令資料自動更新與引用** - 持續學習\n6. **資料安全與供應商風險** - 安全架構\n7. **多模型策略** - 模型選擇\n8. **官方150-word GS與Word完整稿的輸出取捨** - 輸出格式\n9. **MVP/V1/V2路線圖** - 開發規劃\n10. **最終架構、資料模型、prompt策略、評分rubric、人類審核checklist** - 完整設計\n\n讓我逐一分析:\n\n## 1. 工具方向是否合理\n\n合理性分析:\n- 市場需求真實存在,外包成本100-200澳幣\n- GS與GTE不同,GS更結構化,有明確的問題框架(5個問題領域)\n- 官方明確說明150 words per response,這是可標準化的基礎\n- Direction 106提供了明確的評估因素,這是可程式化的邏輯\n- 優點:一致性、可擴展、成本降低、知識累積\n- 風險:移民政策變動、審核責任歸屬、學生資料隱私\n  \n## 2. Token爆炸與失焦問題\n\n這確實是個問題。學生文件可能很多(PDF、圖片、Word),如果一次全部塞入context,token會快速膨脹且容易被無關內容分散注意力。需要採用階段式處理:首先提取關鍵信息(姓名、年齡、教育背景),然後根據Direction 106因素進行針對性分析,最後才生成GS回應。\n\n## 3. 更好的架構\n\n需要建立多層次的系統。學生資料先通過OCR和結構化提取轉換成JSON格式,GS範例和失敗案例作為RAG系統的知識庫,而法令更新則由LLM自動監控。每個回應都經過模型生成和多版本比較,最後由人類專家審核把關。\n\n## 4. 成功/失敗案例應用\n\n成功案例應該按國籍、教育層級、專業方向、資金來源等維度組織。失敗案例需要特別標註具體的拒簽理由和移民局的反饋。這些案例構成系統的學習基礎,幫助避免重複犯錯。\n\n## 5. 法令更新",
  "finish_reason": "stop",
  "finish_reasons": [
    "length",
    "stop"
  ],
  "continuation_count": 1,
  "continuation_exhausted": false,
  "usage": {
    "prompt_tokens": 17240,
    "completion_tokens": 25415,
    "total_tokens": 42655,
    "total_characters": 0,
    "prompt_tokens_details": {
      "cached_tokens": 0
    },
    "completion_tokens_details": {
      "reasoning_tokens": 193
    }
  },
  "cost_usd": 0.03567,
  "log_file": "C:\\Users\\F\\AiFolder\\_runtime\\logs\\codex\\2026-05-14.json"
}
Round 1 - Claude Opus diagnostic retry pending at previous report time success
{
  "job_id": "20260513-164928-claude-opus-a64a18eb",
  "type": "ask_model",
  "status": "success",
  "created_at": "2026-05-13T16:49:28.950Z",
  "model": "claude-opus",
  "prompt": "請用繁體中文完整分析:澳洲留學公司想做內部 AI 工具,讀取 Google Drive 學生文件夾、Form500、證件、照片、成功/失敗 GS 案例、拒簽信、最新 Home Affairs/Direction 106 法規資料,調用多模型生成澳洲 Student visa Subclass 500 的 Genuine Student (GS) 內容。官方重點:GS 取代 GTE,適用 2024-03-23 起申請;ImmiAccount 表格每題 150 words、英文;官方偏好表格回答而非單獨 GS statement;證據支持的陳述權重更高;Direction 106 看整體情況、home country circumstances、potential circumstances in Australia、course value、immigration history、minor parent/legal guardian intentions、unrelated course/inconsistency/visa history 會觸發 scrutiny。請回答:方向是否合理、token/RAG 如何避免失焦、Google Drive/OCR/結構化抽取/RAG/多模型生成/審核/Word輸出/版本保存架構、成功失敗案例如何用、法規如何自動更新與引用、資料安全與 API 供應商風險、多模型是否值得、輸出是否應改成 150-word answers + internal long note + evidence checklist、MVP/V1/V2 路線圖、資料模型、prompt 策略、評分 rubric、人類審核 checklist。",
  "prompt_preview": "請用繁體中文完整分析:澳洲留學公司想做內部 AI 工具,讀取 Google Drive 學生文件夾、Form500、證件、照片、成功/失敗 GS 案例、拒簽信、最新 Home Affairs/Direction 106 法規資料,調用多模型生成澳洲 Student visa Subclass 500 的 Genuine Student (GS) 內容。官方重點:GS 取代 GTE,適用 2024-03-23 起申請;ImmiAccount 表格每題 150 words、英文;官方偏好表格回答而非單獨 GS statement;證據支持的陳述權重更高;Direction 106 看整體情況、home country circumstances、potential circumstances in Australia、course value、immigration history、minor parent/legal guardian intentions、unrelated course/inconsistency/visa history 會觸發 scrutiny。請回答:方向是否合",
  "ref_image": null,
  "max_tokens": 12000,
  "max_continuations": 3,
  "updated_at": "2026-05-13T17:01:58.442Z",
  "completed_at": "2026-05-13T17:01:58.441Z",
  "duration_ms": 749483,
  "model_id": "claude-opus-4-6",
  "response_preview": "# 澳洲留學公司內部 AI 工具:完整架構與策略分析\n\n## 一、方向合理性評估\n\n### 1.1 方向判定:合理且具高價值,但需精準校準\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    方向合理性總評                              │\n├──────────────┬──────────────────────────────────────────────┤\n│ 商業價值      │ ★★★★★  每個 GS 案件節省 2-4 小時人工撰寫時間    │\n│ 技術可行性    │ ★★★★☆  成熟技術棧,但整合複雜度高               │\n│ 法規契合度    │ ★★★★★  GS 框架高度結構化,適合 AI 輔助          │\n│ 風險可控性    │ ★★★☆☆  需嚴格人類審核 + 資料安全措施             │\n│ 競爭護城河    │ ★★★★☆  案例庫 + 法規知識庫形成獨特優勢           │\n└──────────────┴──────────────────────────────────────────────┘\n```\n\n### 1.2 為什麼方向合理\n\n**GS 框架天然適合 AI 處理的原因:**\n\n| 特性 | GTE(舊制) | GS(新制 2024-03-23 起) | AI 適配性 |\n|------|------------|------------------------|----------|\n| 評估框架 | 模糊的「真實臨時入境者」 | 結構化的 Direction 106 多因素 | GS 更結構化 → AI 更易處理 |\n| 回答格式 | 自由格式長文 statement | ImmiAccount 表格每題 150 words | 受限格式 → prompt 更精準 |\n| 證據權重 | 主觀陳述為主 | 「Evidence-backed statements carry more weight」 | AI 可自動匹配證據 |\n| 評估方式 | 整體印象 | 明確的 scrutiny triggers + ho",
  "reasoning_preview": null,
  "finish_reason": "length",
  "finish_reasons": [
    "length",
    "length",
    "length",
    "length"
  ],
  "continuation_count": 3,
  "continuation_exhausted": true,
  "usage": {
    "prompt_tokens": 73941,
    "completion_tokens": 48000,
    "total_tokens": 121941
  },
  "cost_usd": 4.709115,
  "log_file": "C:\\Users\\F\\AiFolder\\_runtime\\logs\\codex\\2026-05-14.json"
}
Round 2 - OpenAI o3 route failed error
{
  "job_id": "20260513-172152-openai-o3-89c8f84f",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T17:21:52.106Z",
  "model": "openai-o3",
  "prompt": "你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。\n\n【背景】\n我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。\n\n【目前重要現實】\n我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。也就是說,生成品質本身已經接近可用。\n\n真正痛點不是模型不會寫,而是:\n1. 其他公司同事無法穩定有效使用最新模型。\n2. 同事不會寫有效 prompt、不會整理資料、不知道該先分析什麼風險。\n3. 公司希望把流程統一化,交給少數有權限人員。\n4. 工作人員最好只需要貼上學生 Google Drive 開放鏈接,再簡單輸入顧問/學生希望撰寫方向(甚至不輸入),系統就能看完所有文件 + 公司預設 GS 技巧/範例/規範,然後輸出各個大模型的完整 GS Word(帶基本排版),讓員工比較並選一份。\n5. 目的:最快落地,先降本增效,不追求一開始就做完整企業級 RAG 平台。\n\n【上一輪多模型與 Codex 綜合結論】\n完整長期方向是:文件抽取 -> evidence map -> 法規/案例 RAG -> 150-word GS answers -> internal long note -> checklist -> 人類審核。不要把全部文件與案例直接塞 prompt,避免 token 膨脹、失焦、資料污染。正式長期架構要有 Google Drive 文件接入、OCR/文件解析、結構化抽取、案例/法規 RAG、prompt pipeline、多模型生成、評分審核、Word 輸出、版本保存、權限、審計、供應商隱私控管。\n\n【但這一輪我要你回答的問題是:最快能上線方案】\n請不要給太重的企業級架構。請基於「目前 web 界面人工操作已經可產生 99% 可用 GS」這個現實,設計一個最快 MVP:\n\n1. 如果目標是 1-2 週內上線,公司內部少數人可用,你建議怎麼做?\n2. 是否可以先不做完整 RAG/vector DB/fine-tune,只做「Drive link -> 文件下載/整理 -> 一鍵生成模型 prompt 包 -> 多模型 API 生成 -> Word 輸出」?可行嗎?風險如何控制?\n3. 最快版是否應該使用「固定知識包」:公司 GS 範例、GS 技巧、Home Affairs GS 要求、Direction 106 摘要,直接作為每次生成的 system/context?這樣 token 會不會可接受?如何控制大小?\n4. Google Drive 開放鏈接如何接入最簡單?是否先要求每個學生 folder 結構固定,例如 /01_form500 /02_passport /03_finance /04_course /05_photos /06_other?如果不是固定結構,怎麼容錯?\n5. 文件解析最快 MVP 用什麼策略?DOCX/PDF 直接抽文字,圖片/掃描件先不用 OCR 還是用 Google Drive OCR/Cloud Vision/Azure Document Intelligence?如何分階段?\n6. 目前公司想要「完整 GS Word」,但官方偏好 150-word form answers。最快 MVP 的 Word 應該怎麼設計?請提出 Word 模板結構:例如 cover page、case summary、risk notes、每題 150-word answer、long version、evidence checklist、photo appendix。\n7. 多模型生成最快方案:每個模型都生成完整 GS Word?還是各模型只生成 markdown/json,最後由系統統一轉 Word?請給具體做法。\n8. 在不做完整 RAG 的情況下,如何避免模型亂寫、法規過期、引用幻覺、編造學生經歷?請設計簡單但有效的 guardrails。\n9. 公司內部人員的操作介面最簡單可以怎麼做?例如 Google Sheet + Apps Script、Streamlit、Next.js 小工具、n8n/Zapier/Make、內部 CLI/桌面工具。請比較並推薦最快能用且可維護的選項。\n10. 請給出最快 MVP 的具體工作流,包括使用者步驟、系統步驟、輸出物、審核步驟。\n11. 請給出 1-2 週落地計劃,每天/每階段要做什麼,最小功能清單,哪些功能先不要做。\n12. 請估算每案成本、token 成本、工程成本、維護成本,並與外包 AUD 100-200 比較。\n13. 請列出最容易踩雷的 20 個問題與對策,尤其是隱私、Google Drive 權限、prompt 泄漏、學生資料遺漏、照片/掃描件識別、Word 排版、模型供應商保存資料、員工直接提交未審核版本。\n14. 請給出推薦的 prompt 模板框架:system prompt、knowledge pack、student facts prompt、consultant direction、output schema、禁止事項、self-check。\n15. 請給出最終推薦:如果你是顧問,會建議我們第一版做哪一種方案?為什麼?\n\n請直接、具體、可執行。不要只說要 RAG、要安全、要審核;請把最快可上的務實方案講清楚。",
  "prompt_preview": "你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。 【背景】 我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/",
  "ref_image": null,
  "max_tokens": 18000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T17:21:52.120Z",
  "completed_at": "2026-05-13T17:21:52.120Z",
  "duration_ms": 5,
  "error": "[openai-o3→o3] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 o3 无可用渠道 (request id: 2026051401215210919840018833724)\",\"type\":\"one_api_error\"}}"
}
Round 2 - OpenAI gpt-4o route failed error
{
  "job_id": "20260513-172306-openai-cdc9f1ee",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T17:23:06.051Z",
  "model": "openai",
  "prompt": "你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。\n\n【背景】\n我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/living knowledge、inconsistency/unrelated course/visa history 等因素。\n\n【目前重要現實】\n我已經測試過:使用 GPT-5.5 與 Claude Opus 4.6+ 的普通會員官方 web 界面,只要開一個新 project/window,添加幾個優秀 GS 範例與移民局 GS 要求規範,然後把學生資料、Form500、證件、照片、課程資料等丟進去,再給一個好 prompt,就能做出 99% 可用的 GS。真正痛點不是模型不會寫,而是公司同事無法穩定有效使用最新模型、不會寫有效 prompt、不會整理資料。公司希望工作人員只貼 Google Drive 開放鏈接,簡單輸入撰寫方向,系統就能看完文件與公司預設 GS 技巧,輸出各模型完整 GS Word。\n\n【問題】\n請基於「最快 1-2 週可上線」回答:是否可先不做 RAG/vector DB/fine-tune,只做 Drive link -> 文件下載/整理 -> prompt 包 -> 多模型 API 生成 -> Word 輸出;固定 knowledge pack 如何設計與控制 token;Google Drive folder 結構與容錯;文件解析/OCR 最快策略;Word 模板;多模型應輸出 markdown/json 還是 Word;guardrails;內部 UI 用 Google Sheet+Apps Script、Streamlit、Next.js、n8n/Make 哪個最快;完整工作流;1-2 週計劃;每案成本;20 個踩雷點與對策;prompt 模板框架;最終推薦。請直接、具體、可執行。",
  "prompt_preview": "你是一位資深 AI 產品架構師、內部工具 MVP 顧問、LLM workflow 工程師,也熟悉澳洲 Student visa Subclass 500 的 Genuine Student (GS) requirement。請用繁體中文回答,內容要非常具體、偏「最快能上線」而不是完美長期架構。 【背景】 我們是一間澳洲留學公司。公司目前要為學生簽證準備 GS(Genuine Student)相關材料。根據澳洲 Home Affairs,目前 GTE 已被 GS 取代,GS 適用於 2024-03-23 起遞交的 Student visa 申請;ImmiAccount 內 GS answers 官方要求英文、每題最多 150 words,官方偏好在申請表中回答而不是另附長篇 statement;證據支持的陳述權重更高;Direction No. 106 要整體評估 home country circumstances、potential circumstances in Australia、course value、immigration history、course/provider/",
  "ref_image": null,
  "max_tokens": 18000,
  "max_continuations": 4,
  "updated_at": "2026-05-13T17:23:06.065Z",
  "completed_at": "2026-05-13T17:23:06.065Z",
  "duration_ms": 5,
  "error": "[openai→gpt-4o] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 gpt-4o 无可用渠道 (request id: 202605140123065416530051720056)\",\"type\":\"one_api_error\"}}"
}
Round 2 - OpenAI gpt-4.1 route failed error
{
  "job_id": "20260513-172424-openai-4.1-8670d307",
  "type": "ask_model",
  "status": "error",
  "created_at": "2026-05-13T17:24:24.455Z",
  "model": "openai-4.1",
  "prompt": "請用繁體中文,從最快 MVP 角度分析:澳洲留學公司已用 GPT/Claude 官方 web 界面證明只要固定 GS 範例、移民局 GS 規範、學生 Drive 文件與好 prompt,就能產出 99% 可用 GS。現在要在 1-2 週內做內部工具,讓員工貼 Google Drive folder link + 可選撰寫方向,系統讀文件、套固定 knowledge pack、調多模型、輸出完整 GS Word 與 150-word ImmiAccount answers。請具體回答:最簡方案、是否不用 RAG/vector DB、固定 knowledge pack token 控制、Drive folder 結構、文件解析/OCR 分階段、Word 模板、多模型輸出 markdown/json 再轉 Word、guardrails、防幻覺/防編造、UI 選 Google Sheet+Apps Script/Streamlit/Next.js/n8n、1-2 週實施計劃、成本、20 個踩雷點、prompt 模板與最終推薦。",
  "prompt_preview": "請用繁體中文,從最快 MVP 角度分析:澳洲留學公司已用 GPT/Claude 官方 web 界面證明只要固定 GS 範例、移民局 GS 規範、學生 Drive 文件與好 prompt,就能產出 99% 可用 GS。現在要在 1-2 週內做內部工具,讓員工貼 Google Drive folder link + 可選撰寫方向,系統讀文件、套固定 knowledge pack、調多模型、輸出完整 GS Word 與 150-word ImmiAccount answers。請具體回答:最簡方案、是否不用 RAG/vector DB、固定 knowledge pack token 控制、Drive folder 結構、文件解析/OCR 分階段、Word 模板、多模型輸出 markdown/json 再轉 Word、guardrails、防幻覺/防編造、UI 選 Google Sheet+Apps Script/Streamlit/Next.js/n8n、1-2 週實施計劃、成本、20 個踩雷點、prompt 模板與最終推薦。",
  "ref_image": null,
  "max_tokens": 14000,
  "max_continuations": 3,
  "updated_at": "2026-05-13T17:24:24.469Z",
  "completed_at": "2026-05-13T17:24:24.469Z",
  "duration_ms": 5,
  "error": "[openai-4.1→gpt-4.1] API 错误 503:{\"error\":{\"message\":\"当前分组 default 下对于模型 gpt-4.1 无可用渠道 (request id: 2026051401242445796280003963059)\",\"type\":\"one_api_error\"}}"
}