智解家考題解析審查 Agent Instruction

這份文件是一份可以交給其他 agent 執行的工作指令，用來審查智解家選擇題考古題資料庫中的 AI 生成解析。

它整理自已完成的一輪 114 年完整驗證流程。該輪共審查 300 題，結果為：

狀態	題數	說明
`ok`	222	通過嚴格 citation gate，可視為本輪機器審查通過
`has_issue`	14	已確認原解析有實質錯誤，應進入修正 queue
`needs_human_review`	64	未取得足夠官方佐證或涉及精細實務判斷，需人工二審

本流程的核心不是讓 agent 自信地回答，而是讓 agent 在證據不足時保守停下來。

一句話目標

針對每一題，檢查 AI 生成的法律解析是否有實質錯誤；只有當所有重要法律主張都能被官方一級資料支持時，才標記為 ok。

審查範圍

只審查 AI 生成內容：

key_point
concept
reason
option_analysis

不要重新審查題幹、選項與官方答案。題幹、選項與正答視為 source data。

explanation 是 redundant rendered field，原則上不送給 reviewer 做完整重審。它只做 deterministic consistency check：

是否忠實合併 key_point、concept、reason、option_analysis。
是否多出新的法律主張。
是否產生與四個 primary fields 矛盾的內容。

若沒有 extra claim 或 contradiction，就不要花 reviewer tokens 重看 explanation。

判斷標準

審查標準是考試年度當時適用的法律與實務見解。若只能取得現行法，必須記錄是否檢查過考試時法是否有重大差異。

這不是文風潤稿。不要因為語氣不優雅、教學語感不佳、或可以補更多 nuance 就判錯。只有實質法律風險才算 issue。

實質錯誤包含：

法條、項、款、字號、釋字、裁判字號錯誤。
引用來源不能支持該主張。
把現行法誤用到考試時法已不同的題目。
正答理由錯誤。
選項分析把正確選項說成錯，或把錯誤選項說成對。
使用沒有官方支持的幻覺式法理或實務見解。
key_point、concept、reason、option_analysis 彼此矛盾。

狀態定義

狀態	使用條件
`ok`	沒有實質法律錯誤，且所有重要法律主張都有一級官方資料或已接受的一級快取來源支持
`has_issue`	找到實質錯誤，且能說明錯誤原因與建議修正方向
`needs_human_review`	自動流程無法達到高信心，例如來源衝突、官方來源不可得、只找到二級資料、學說有爭議、reviewer 信心不足

重要規則：有 unresolved warning 時，不得標記為 ok。應標記為 needs_human_review。

證據分級

Tier 1：可支持 `ok`

一級資料包含：

law.moj.gov.tw：全國法規資料庫。
mojlaw.moj.gov.tw：法務部主管法規或函釋資料。
cons.judicial.gov.tw：司法院解釋與憲法法庭裁判。
www.judicial.gov.tw：司法院官方資料、公告與 hosted documents。
data.judicial.gov.tw 或官方法院/open-data endpoint：裁判資料。
moex.gov.tw 或考選部官方資料：試題、答案或考試相關資料。

Tier 2：只能做 discovery

二級資料可用來找線索，但不能單獨支持 ok：

補習班、法律部落格、律師事務所文章。
商業法律資料庫或整理型網站。
學校講義、考生筆記、非官方 mirror。

若重要主張只有 Tier 2 支持，狀態必須是 needs_human_review。

Tier 3：不可作為審查證據

社群貼文、論壇、匿名筆記。
搜尋摘要。
AI 產生答案。
沒有來源可追溯的整理。

必須覆蓋的 claim

每一題要把重要主張拆成 claim，並給穩定 claim_id：

claim_id 範例	說明
`answer_rationale`	為什麼官方正答是對的
`option_A`、`option_B`	各選項關鍵正誤理由
`statutory_basis`	重要法條依據
`practice_basis`	實務見解、判決、釋字、裁判依據
`law_time_basis`	考試時法與現行法是否有差異

ok 要求每個 material claim 都有支持，或被明確標記為不需要 authority 的非法律主張。

Agent Team 角色

1. Orchestrator

負責整體流程，不做法律判斷的最後憑空決定。

責任：

匯出 source data。
建立 source manifest 和 hash。
切 batch。
分派 worker。
驗證 JSON、schema、line count、question_id。
執行 strict gate。
只有 Orchestrator 可以 promote 到 accepted.jsonl 或寫入 local SQLite。

2. Source Resolver

負責找官方來源與建立 source cache。

責任：

法條優先對應官方法規 URL。
釋字、憲法法庭裁判對應官方頁。
判決優先找官方法院或 open-data 來源。
只保留短 excerpt、來源摘要、hash，不塞整頁 HTML 給 reviewer。
找不到一級資料時清楚標記 unresolved。

3. Primary Legal Reviewer

負責審查單題的四個 AI 欄位。

責任：

檢查 key_point、concept、reason、option_analysis。
拆 claim。
初步判斷 ok、has_issue、needs_human_review。
找到錯誤時寫出錯誤內容與修正方向。
不做風格改寫。

4. Citation Verifier

負責確認 citation 是否真的支持 claim。

責任：

檢查法條、裁判、釋字、函釋號碼是否正確。
確認來源文字是否支持 reviewer 的 claim。
若 citation 無法支持 claim，必須降級。
若只有 Tier 2 支持，不能讓題目成為 ok。

5. Consistency Checker

盡量 deterministic。

責任：

檢查 explanation 是否只是四個 primary fields 的合併。
檢查 option_analysis 是否和 correct_answer 矛盾。
檢查 JSON shape、status consistency、source hash、citation shape。

6. Adjudicator

只處理 escalation，不要每題都叫它。

觸發條件：

Reviewer 與 Citation Verifier 不一致。
有 Tier 2 evidence trace。
官方來源不可得或 ambiguous。
考試時法與現行法可能不同。
Reviewer 標記 needs_human_review。
QA 發現 ok 可能是 false ok。

7. QA Auditor

負責抽查品質。

建議抽查：

100% has_issue。
100% needs_human_review。
100% 有 Tier 2 trace 的題目。
第一批每科至少抽 20% 的 ok。
流程穩定後，每 batch 抽 5% 到 10% 的 ok。

Token-efficient Workflow

已驗證的省 token 原則如下：

Reviewer input 不送完整 explanation，只送四個 primary fields。
explanation 先做 deterministic consistency precheck。
Source Resolver 建立 shared source cache，同一法條或裁判不要讓每個 worker 重新抓。
送 source excerpts，不送整頁 HTML、PDF 或搜尋結果全文。
Citation Verifier 只看 claim/citation/source excerpt，不重看整題。
低風險題先單 reviewer；只有高風險題才進 second reviewer 或 adjudicator。
先跑 representative sample，再放大 batch。

在 114 年完整 run 中，slim input 相較 full input 約降低 22.8% 到 25.0% 字元量。完整 300 題 run 的邊際 token 約為每題 20,315，低於 35k/question gate。這個數字不是法律正確性的證明，但證明此 input 瘦身方式可以在 strict gate、citation hygiene、local ledger 都保留的前提下降低成本。

Batch Workflow

Step 1：匯出 source data

輸出：

source/questions.jsonl
source/questions.json
source/source_manifest.json

manifest 必須包含：

row count
selection SQL 或資料選取條件
exported timestamp
question IDs
source checksum

Step 2：建立 local review ledger

使用 local SQLite 或等價 ledger。不要直接更新 production DB。

基本原則：

source DB 是 read-only source。
absence of review row = 尚未審查。
所有 review 結果先存在 local ledger。
最後再由人決定哪些 correction 要回寫產品資料。

Step 3：先跑代表性 sample

放大前必須先跑 sample：

至少 30 題。
至少 3 個科目。
包含 statute-only、實務見解、法律倫理、國際法或其他高風險題型。

Go/no-go gate：

平均 marginal tokens < 35k/question。
ok 題沒有 unresolved warning。
Tier 2 trace 沒有被 promote 成 ok。
Source cache 開始產生 reuse。
QA 沒抓到 false ok。

Step 4：Production batch

建議：

穩定後每 batch 50 到 100 題。
高風險科目或年份可降為 20 到 30 題。
每個 batch 都要有 input.jsonl、manifest.json、attempts/<id>/output.jsonl、accepted.jsonl、validation_report.json。

worker 只能寫自己的 attempts/<id>/output.jsonl。只有 Orchestrator 可以寫 accepted.jsonl。

Step 5：Strict Gate

以下情況不得 promote 為 ok：

有 material claim 只有 Tier 2 或 Tier 3 evidence。
官方來源不可得。
citation verifier 認為 source 不支持 claim。
citation 沒有 claim_id。
explanation 有未檢查的 extra legal claim。
現行法與考試時法可能不同但沒有 note。
reviewer 與 verifier 不一致。
output 有 unresolved warning。

Step 6：SQLite consolidation

Orchestrator promotion 後才寫 local SQLite。

必查 invariant：

input row count = output row count。
question_id 全部 match。
source checksum 有記錄。
JSON parse 和 schema validation 都通過。
每個 ok 至少有一筆 citation check。
每個 ok 沒有 warning。
每個 ok 的 material claims 都有 Tier 1 support。
SQLite summary 和 accepted JSONL 一致。

Step 7：Viewer / Report

產出 reviewer 可以用的檢視介面或報告，至少包含：

題幹、選項、正答。
原始四個 AI 欄位。
review status。
issues。
warnings。
claim checks。
citation checks。
source snapshot reference。

Stop Conditions

遇到下列情況要停下來，不要硬跑：

Production batch strict warning rate > 20%。
cache warm-up 後平均 marginal tokens 仍 > 35k/question。
QA sample 發現 false ok。
超過 5% 官方 source URL 失敗。
prompt、schema 或 source tier rule 需要改。

改 prompt 或 schema 時，必須 bump protocol version。

可直接給 Worker 的 Prompt

以下 prompt 可貼給 Primary Legal Reviewer。Orchestrator 應先填好每題 source snapshot、source excerpts 和 batch metadata。

你正在審查一題智解家司法官/律師考試選擇題解析。請遵守 lawsome-review-protocol-v0.1。

任務：
只審查以下 AI 生成欄位：
- key_point
- concept
- reason
- option_analysis

不要為了文風改寫。除非 consistency checker 指出 explanation 有額外法律主張或矛盾，否則不要獨立審查 explanation。

法律標準：
使用考試年度當時適用的法律與控制性實務見解。若使用現行官方法，必須記錄是否檢查過考試時法是否有重大差異。

證據規則：
ok 需要每個 material legal claim 都有 Tier 1 官方來源支持。

Tier 1 包含：
- law.moj.gov.tw
- mojlaw.moj.gov.tw
- cons.judicial.gov.tw
- www.judicial.gov.tw
- data.judicial.gov.tw
- moex.gov.tw

Tier 2 只能當 discovery clue。若 material claim 只有 Tier 2 支持，status 必須是 needs_human_review。

請逐一完成：
1. 找出本題所有 material claims。
2. 為每個 material claim 指派穩定 claim_id。
3. 檢查每個 claim 是否正確。
4. 為每個 claim 附 citation check。
5. 確認 citation 是否為官方來源、是否真的支持 claim。
6. 若發現實質錯誤，寫出錯誤原因與建議修正。
7. 若證據不足或不確定，標記 needs_human_review，不要硬標 ok。

狀態只能三選一：
- ok：沒有實質法律錯誤，且所有 material claims 有 Tier 1 支持。
- has_issue：找到實質錯誤，且能寫出錯誤原因與修正方向。
- needs_human_review：來源未解、只有 Tier 2、學說或實務有爭議、或信心不足。

輸出限制：
- 只輸出 JSON object。
- 不輸出 markdown。
- 不引用長篇來源文字。
- 不得用 Tier 2 作為 ok 的最終支持。
- 不確定時選 needs_human_review。

輸出 JSON shape：
{
  "question_id": "...",
  "status": "ok | has_issue | needs_human_review",
  "confidence": "high | medium | low",
  "field_reviews": {
    "key_point": {"status": "ok | has_issue | needs_human_review", "note": "..."},
    "concept": {"status": "ok | has_issue | needs_human_review", "note": "..."},
    "reason": {"status": "ok | has_issue | needs_human_review", "note": "..."},
    "option_analysis": {"status": "ok | has_issue | needs_human_review", "note": "..."}
  },
  "claim_checks": [
    {
      "claim_id": "answer_rationale",
      "field": "reason",
      "claim": "...",
      "result": "supported | unsupported | unclear",
      "note": "..."
    }
  ],
  "citation_checks": [
    {
      "claim_id": "answer_rationale",
      "source_tier": 1,
      "source_type": "statute | judgment | interpretation | official_summary | other",
      "title": "...",
      "source_url": "...",
      "official_source": true,
      "supports_claim": true,
      "verified": true,
      "article_or_case_no": "...",
      "effective_date_note": "...",
      "note": "..."
    }
  ],
  "issues": [],
  "warnings": [],
  "explanation_consistency": {
    "status": "pass | extra_claims | contradiction | not_checked",
    "note": "..."
  },
  "source_snapshot_ref": "...",
  "protocol_version": "lawsome-review-protocol-v0.1",
  "reviewer": "...",
  "reviewed_at": "..."
}

Orchestrator Validation Prompt

可在每個 batch 結束後交給 Orchestrator 或 validator agent 使用：

你是 Lawsome review Orchestrator。請只驗證 batch output，不做新的法律判斷。

請檢查：
1. output 行數是否等於 input 行數。
2. 每行 JSON 是否 parse 成功。
3. question_id 是否全部存在於 manifest。
4. source_snapshot_ref 是否 match source manifest。
5. status 是否只使用 ok、has_issue、needs_human_review。
6. ok rows 是否 issues 為空。
7. ok rows 是否 warnings 為空。
8. ok rows 是否至少有一筆 citation_check。
9. ok rows 的 citation_checks 是否全部 source_tier = 1、official_source = true、verified = true、supports_claim = true。
10. material claim 是否都有 claim_id 和對應 citation。
11. explanation_consistency 是否 pass，或其問題已使狀態降為 needs_human_review/has_issue。

若任何 ok row 有 unresolved warning 或 Tier 2-only support，不得 promote，必須退回 worker 或降為 needs_human_review。

輸出：
- accepted_count
- rejected_count
- status_counts
- strict_gate_counts
- validation_errors
- rows_to_return_to_worker
- rows_to_downgrade

Agent-loop Review Gates

每次放大前，用三個只讀 reviewer lane 檢查 instruction 和結果：

Lane A：品質與證據 reviewer

問題：

這份流程是否可能把 citation 不完整的題目誤標為 ok？
has_issue 是否需要 proposed correction？
needs_human_review 是否被誤解成錯誤？
是否有 Tier 2 source 被 promotion gate 放過？

接受條件：

所有 unresolved warning 都不得成為 ok。
所有 ok 都有 verified Tier 1 citation。
has_issue 必須有錯誤原因與修正方向。

Lane B：Token 成本 reviewer

問題：

reviewer input 是否仍含 redundant explanation？
source cache 是否跨 batch reuse？
citation verifier 是否只看 claim/citation/excerpt？
是否有 worker 重複抓整頁或整批資料？

接受條件：

slim input 降低約 20% 以上字元量。
cache warm-up 後 marginal tokens 低於 35k/question。
hard cases 可超標，但需記錄比例與原因。

Lane C：可執行性 reviewer

問題：

其他 agent 是否知道要產出哪些檔案？
失敗時是否知道要停、退回、降級或人工複核？
Orchestrator 和 worker 權限是否清楚？
是否避免直接更新 production DB？

接受條件：

每 batch 有 manifest、attempt output、accepted output、validation report。
worker 不能寫 accepted output 或 SQLite。
Orchestrator promotion 有可重跑驗證。

Decision Ledger Template

每次 loop 後用下列表格記錄採納與否：

建議	來源	決策	理由	後續
例如：不要把 Tier 2 source 作為 ok 支持	品質 reviewer	adopted	會造成 false ok	strict gate 阻擋
例如：不要送 explanation 給 reviewer	Token reviewer	adopted	已驗證可降 22.8% 到 25.0% 字元量	consistency precheck
例如：所有題都雙 reviewer	可執行性 reviewer	modified	成本過高，改為 high-risk 才 second reviewer	escalation rule

本稿 Agent-loop 驗證結果

本 instruction 發布前，用三個只讀 reviewer lane 檢查過：

Reviewer lane	檢查重點	結果	採納或修正
品質與證據 reviewer	是否可能把 citation 不完整的題目誤標為 `ok`	通過	保留 fail-closed、unresolved warning 不得 `ok`、Tier 2 不得支持 `ok`
Token 成本 reviewer	是否保留已驗證的降耗方式	通過	明確要求不送 redundant `explanation`、使用 source cache、citation verifier 只看 claim/citation/excerpt
可執行性 reviewer	其他 agent 是否知道 artifact、權限與停止條件	通過	明確規定 worker 只能寫 attempt output，Orchestrator 才能 promote `accepted.jsonl` 與寫 local ledger
Workspace / public-safety check	是否含私有 access、憑證、內部 URL 或本機路徑	通過	本公開版只保留流程與驗證數字，不包含資料庫 access 或秘密

已驗證依據

這份 instruction 參考了已完成的 114 年完整 run：

範圍：114 年 300 題。
結果：222 ok、14 has_issue、64 needs_human_review。
所有 ok：無 unresolved warning、無 bad citation、至少一筆 verified Tier 1 citation。
citation rows：902。
ok citation rows：752 筆 Tier 1 official verified supporting citations。
token：總 token 56,251,964；cached input 50,157,568；邊際 token 約 20,315/question。
slim input：相較 full input 降低約 22.8% 到 25.0% 字元量。

注意：這些數字證明流程與 gate 可以運作，並證明 slim input 在本輪沒有破壞 strict gate 與 citation hygiene。它不是法律上「所有 ok 永遠正確」的保證。因此仍需要 QA sample 與 human review queue。

給執行 agent 的最後提醒

你的任務不是把所有題都變成 ok。你的任務是把資料分成三類：

有足夠官方證據支持，可以通過。
已確認有錯，應修正。
證據不足或判斷風險高，需要人看。

第三類不是失敗，而是品質控制。

智解家考題解析審查 Agent Instruction

智解家考題解析審查 Agent Instruction

一句話目標

審查範圍

判斷標準

狀態定義

證據分級

Tier 1：可支持 ok

Tier 2：只能做 discovery

Tier 3：不可作為審查證據

必須覆蓋的 claim

Agent Team 角色

1. Orchestrator

2. Source Resolver

3. Primary Legal Reviewer

4. Citation Verifier

5. Consistency Checker

6. Adjudicator

7. QA Auditor

Token-efficient Workflow

Batch Workflow

Step 1：匯出 source data

Step 2：建立 local review ledger

Step 3：先跑代表性 sample

Step 4：Production batch

Step 5：Strict Gate

Step 6：SQLite consolidation

Step 7：Viewer / Report

Stop Conditions

可直接給 Worker 的 Prompt

Orchestrator Validation Prompt

Agent-loop Review Gates

Lane A：品質與證據 reviewer

Lane B：Token 成本 reviewer

Lane C：可執行性 reviewer

Decision Ledger Template

本稿 Agent-loop 驗證結果

已驗證依據

給執行 agent 的最後提醒

Tier 1：可支持 `ok`