任務：建築師考題整理#
主要是針對建築師考古題的整理，為了做一些Project（未來會分享），必須將考題從PDF整理成JSON格式。
Background#
2025年9月28日其實就主要處理了一波112年到97年的題目。然後在2025年11月4日做了一次人工檢查，針對一些小錯誤進行確認。
2026年2月8日，因為Gemini免費試用api要到期了，被迫提早面對整理114年的題目。
Setup#
其實做的事情很簡單。把考古題PDF跟一個整理過的範例jJSON作為參考傳給LLM請他為我整理。
Prompt#
幫我完整把114年的問題與答案的md內容整理成json。 格式可以參考111年的。
附件檔案#
- 114年建築師法規試題
- 114年建築師法規更新答案
- 111年法規Dataset JSON
[
{
"id": "111-1801-Q01",
"year": 2022,
"subject": "營建法規與實務",
"question_type": "multiple_choice",
"question_text": "依建築師法之規定，下列何者非建築師開業執行業務的必要條件？",
"options": {
"A": "設立建築師事務所",
"B": "領得開業證書",
"C": "成立室內裝修公司",
"D": "加人該管直轄市、縣（市）建築師公會"
},
"answer": [
"C"
],
"explanation": null,
"source": "111180_1801_original.md",
"tags": [],
"answer_mode": "single"
},
{
"id": "111-1801-Q02",
"year": 2022,
"subject": "營建法規與實務",
"question_type": "multiple_choice",
"question_text": "依非都市土地使用管制規則規定，有關非都市土地之各種建築用地，其建蔽率及容積率，下列敘述何者正確？",
"options": {
"A": "丙種建築用地：建蔽率 $40 \\%$ ；容積率 $160 \\%$",
"B": "甲種建築用地、乙種建築用地：建蔽率 $60 \\%$ ；容積率 $240 \\%$",
"C": "交通用地、遊憩用地、殯葬用地：建蔽率 $40 \\%$ ；容積率 $140 \\%$",
"D": "特定目的事業用地：建蔽率 $60 \\%$ ；容積率 $160 \\%$"
},
"answer": [
"B"
],
"explanation": null,
"source": "111180_1801_original.md",
"tags": [],
"answer_mode": "single"
},
......
]
測試環境、對象#
在Macbook上運行，使用官方APP (Claude) 跟官方網頁（Gemini, GPT）
共測試四種
- Gemini 3 Pro
- GPT 5.2 Thinking
- Claude Sonnet 4.5 (Extended thinking)
- Claude Cowork (Claude Sonnet 4.5 Extended thinking)
結果#
Gemini 跟 GPT都沒問題！#
其實整體而言比去年9月好很多了，但經驗上我還是直接使用Gemini的版本去做後續校正。以下深入分析一下，首先講去年的狀況，再來討論今年的各家模型的差異，以及跟去年的比較。
回顧去年#
由於去年實作時並沒有做比較完整的紀錄，只有一些操作時的小筆記。在這裡根據筆記稍微還原當時的狀況。
當時Gemini 還在 2.5的版本。 GPT 5 , Claude 4，除此之外也測試直接在Cursor內整理。
基本上能有效做到任務的，只有Gemini 2.5 Pro (Official Web)、Gemini 2.5 Pro (Cursor) 以及Claude 4 Sonnet (Cursor)，其中Claude只有在 Cursor 環境下才能勉強成功，官方APP的Chat視窗題號會完全錯亂。
當時的筆記：
cursor auto (寫python) 徹底失敗
claude desktop 題號錯亂
chatgpt agent 局部數學公式latex有問題
chatgpt 5 大失敗
gemini最穩
cursor (gemini) 比 (claude) 快、便宜、但claude也很穩
當時Cursor內的Prompt
參考@112190_1801_original.md @112190_MOD1801_original.md 整理成@law_112_dataset.json 的格式以及邏輯，請你手動幫我把@57819m_original.md @037801100_original.md 轉成對應的json。請你直接生成不要透過其他任何方式去做轉換
（附註：當時甚至有些還先經過OCR的階段，先產生Md，再整理成JSON)）
後來11月時人工校正時，主要看到以下幾個常見的錯誤。
- 污染：當題目處於跨頁的地方時，常混入一些無關的字樣（考試卷頁碼等等），印象中，不只是先OCR過的版本會這樣。
- 全、半形：主要是%跟％，基於考試是台灣的，後來都使用全形的％
- 數字表示：當時在數字的前後，常會有空格（例如：總共 1000 元 ），當然可能是試卷本身的排版就是如此，但當時不知為何我腦子卡住會糾結這件事，就把所有的這種空格手動移除… 浪費時間
- 公式表示：類似於前一項，由LLM整理出來的json在表示這些公式，或有時甚至只是在文字內出現的數字、趴數時，也會用Latex之類的公式來表示。有好有壞，但當時把這些公式都手動移除了
- 錯別字：這部分最驚喜，在使用ctrl f 找同字的時候發現的。有些很有趣的錯別字，從來沒想過。
（例如：
内(錯誤) -內(正確)、奬（異體字） -獎、䨿-廠）這些根本一般閱讀不會發現。
今天#
首先，體感上Gemini處理最快。
接者回來看今天整理的過程。基本上就是先把claude, gemini, gpt 都跑過一遍後，請Cursor的Composer 1來檢查。
Prompt
@data/processed/114/law_114_dataset_claude.json @data/processed/114/law_114_dataset_gemini.json @data/processed/114/law_114_dataset_gpt.json 那幫我比較一下 這三個版本之間有沒有什麼差異？
結果是，claude出現一堆錯誤。包含題目與答案無法對應等等的，而GPT基本上與Gemini一致，至少Cursor沒有檢查出來問題（僅有縮排空格的差異）。
後續嘗試使用Cowork模式看看Claude能否扳回一城，結果是題目與答案之間的對應沒有問題了，但Claude在理解對於「更正答案」是如何處理的部分仍不穩。Cowork 版雖然有抓出第27題「多答案正確」的部分，並且在explanation欄位有解釋到B,D皆正確，answer mode 正確設置"Any"，但在正解選項中僅填入B。一般版本則是沒有這個問題，針對這個特殊的題目反而處理正確。
詳細檢查的狀況我附件在這裡
跟去年比較#
後續針對Gemini的版本我進行人工校正。流程基本上就是，核對pdf答案、錯別字Ctrl F搜尋、快速瀏覽各題（檢查是否有污染的狀況）。其中只遇到了％的半形與全形的問題而已（全使用半形），其他所有去年遇到的問題都沒發生，尤其是數字前後空格與公式表示這點，都直接與校正後的狀態一致（我沒有提供校正後的JSON給LLM）這點最讓人驚訝。總之，僅花了不到5分鐘就檢查完了，讓我省下許多時間，決定記錄下這一篇文章。
比較四組的處理過程#
這裡根據操作的過程 (Thinking Log 等等)進行分析與比較。首先Claude並沒有完整展示thinking的過程，主要簡化成摘要來講，Cowork簡化的更多，雖然UI上是有一個Process面板，但從對話框內其實是看不出來他哪裡去做了這些Checklpoint。
GPT的Thinking Log還是高水準，把許多細節保留，包含中間使用python跑了什麼。 Gemini的則是最差勁的，真的很白痴，看不出來他是否有正確讀取檔案，（也看不出來他是否有上網找答案）， 整個過程都被模糊的摘要簡化。
這裡我請GPT幫我整理了這四組各自的執行過程。GPT、Gemini、Claude、Claude Cowork
再請GPT 5.2 Thinking 對於這四組去做詳細的比較，整理成以下表格：
| 比較面向 | Claude | Cowork | GPT | Gemini |
|---|---|---|---|---|
| 流程呈現風格 | 時間順序＋分階段（約 1~16 步），偏流程管理/SOP | 精簡線性（約 10 步），偏「工作清單」 | 分 6 大階段＋細到約 20 步，偏「工程化詳規」 | 分 9 大模組＋約 26 步，偏「資料治理/QA 清單」 |
| 對任務理解/假設 | 清楚列三份檔案與目標：114 題目+答案 → JSON，格式對齊 111 | 同上，但更強調「先確認環境檔案清單」 | 補充背景與限制：題/答案分 PDF、共 80 題、先確認特殊規則 | 先界定資料來源可能含 OCR；先把題型/規則說清楚 |
| 參考範本（111 JSON）使用方式 | 先開啟 111 JSON，歸納欄位規格（含 answer_mode） | 直接列出欄位清單，對欄位存在感最強 | 強調「對齊 111 格式」但更著重後續如何實作解析/整合 | 先定義輸出 schema，再要求與 111 範例完全對齊（schema-first） |
| 題目抽取方法（Question PDF） | 描述會切 Q01~Q80，但工具/細節較少 | 只說解析 PDF 擷取內容，較像摘要 | 明確到可照做：pdfplumber 逐頁讀→合併→清理→切題→處理跨行 | 抽取與清理拆很細：題目/選項抽取＋OCR 清理＋特殊題修正 |
| 答案處理（Answer Key） | 建「題號→答案」對照表；辨識 Q27 給分規則→調整 answer_mode | 有提到讀答案，但對照表生成細節較少 | 解析答案頁格式→做 answers_map；遇 Q27 特例（符號/更正）→ any 模式＋說明 | 專章處理答案對照表，明確納入 Q27 any 模式 |
| ID/命名與輸出檔 | 明確 ID 規則（年份-科目代碼-Q題號）；輸出檔名；含交付/搬到輸出目錄 | 有輸出檔名與回報完成 | 連輸出參數都寫到（UTF-8/ensure_ascii/indent）＋可讀性檢查 | 較少檔案工程細節，重點放在「資料定稿」 |
| 品質控管/驗證 | 有題數/題號範圍概念，但 QA 條目較少 | 有「用 Python 做整合、驗證」但未細列驗證項 | 明確列驗證：80 題、每題 4 選項、JSON 可讀、特殊題標記 | 驗證最重：逐題檢查題/選項/答案、查缺漏/錯置，還提「對照原始 PDF」 |
| 例外/特殊題處理 | 聚焦 Q27，調整 answer_mode（描述偏「多答案給分」） | 幾乎沒提 Q27 的處理細節 | 把 Q27 定義成更正題，answer_mode=any，並保留說明文字 | 除 Q27 外還列出 Q34/Q35/Q47 等需修正案例（偏人工校正清單） |
| 一句話特色 | 專案 SOP：從接收→分析→轉換→輸出→交付，流程感強 | 最短最快：適合快速對齊共識，但可操作細節少 | 最工程化：可以直接照著寫 parser/流程 | 最偏資料品質治理：OCR 清理＋逐題 QA＋修正清單最完整 |
其實從以上表格看起來Gemini最可信，但坦白說，從他thinking log的顯示方式，我對他最不放心。不過好在是之前就是使用gemini 2.5為主要處理，以及這次任務不需要做到「上網搜尋」的步驟，因此還是選擇相信Gemini。
討論#
3個月前，基本上只有兩款模型能勉強協助完成這項無聊的Task，但今年基本上這三者都是可以做到，而且確實比去年省下許多人工校正的時間。
而針對今年主要進步的狀況，以及claude翻車的情形，以下根據個人經驗做出以下推斷。
- 今年各家模型（或後端）對於pdf的視覺辨識處理得更好了。過去可能單純是直接截取pdf內部資訊，而今天可能不僅僅如此，也包含直接截圖，用視覺能力進行Double Check詳情可見這篇還沒寫的文章。當然在本次任務中，從GPT的Thinking紀錄看起來是沒有使用到視覺能力，單純是資訊處理，而我也沒多去檢查他的Final輸出。Gemini的Thinking過程則依舊模糊表示，無法確認，但從描述中看似有經過第一階段的OCR後，再透過視覺去再次檢查了以下問題：
Q34：釐清選項模糊或錯置問題 Q35：確認題目與選項完整性 Q41：檢查資料一致性 Q46：補齊被截斷的題目或選項文字 Q47：完成缺漏的資料抽取 - Claude的視覺能力還是偏弱，從題目與答案對應出錯，可以判斷是在截取答案PDF(以表格呈現)的過程出了些問題。當然Cowork版本是有成功的，從執行過程紀錄來看，看起來是直接成功的，不是透過後續檢查找出問題去Loop處理的。只能說Claude Cowork在此任務上，調校的是比一般Chat狀態好。
- Claude廢話很多，明明範例中tags欄位都是空欄位，claude每一題都要塞入一個
- AI Agent 的執行過程可解釋性還是十分重要。
總結#
三個月的時間，一代模型的升級。我該繼續趕進度了！
