Day 28，我們替 Vibe Guard 加上 Prompt Injection 防線。
Repository 中的：
Source Comment
README
Tool Result
Package Metadata
Encoded Instruction
即使成功影響 Model Planner，也不能直接：
讀取 Secret
連線外部網址
修改 Repository
執行 Shell
改寫 Finding Verdict
因為真正決定 Tool 是否能執行的是：
Deterministic Capability Gateway
至此，系列已經累積很多零件：
Recon
Rule Engine
Context Selection
Hunter
Challenger
Dynamic Validator
Findings Schema
CLI
Pull Request Adapter
Evaluation
Prompt Injection Defense
但它們大多在各自的文章中獨立執行。
今天要回答最初的問題：
把所有零件組起來後，
Vibe Guard 到底能抓出多少 Production 問題？
我們會執行一次完整驗收：
16 個固定案例
12 個真實 Production 問題
4 個 Safe Control
12 條驗證流程
Canonical Findings Report
Detection Metrics
PR Gate
Prompt Injection Gate
Final Release Gate
結果不會是 100 分。
這很重要。
一份可信的完整實測，不應只展示 Agent 成功的案例。
它也必須公開：
漏掉什麼
誤報什麼
哪些結果仍缺證據
哪些問題真的會阻擋上線
如果只測 Gemini 的單次回答，我們只能知道：
這個 Prompt 在這次推論得到什麼文字。
但 Vibe Guard 的最終結果還受到：
影響。
所以 Day 29 的評估單位是：
Vibe Guard System
而不是：
某一個 Model Response
Google Cloud Well-Architected Framework 將 Production 工作負載的非功能需求分成 Security、Reliability、Operational Excellence、Performance、Cost 與 Sustainability 等 Pillar。
Google SRE 的 Reliable Launch 實務也強調：
逐步發布
驗證步驟
Canary
Rollback
Capacity
Retry 行為
故障期間的觀測
因此一個「上線守門員」不能只做傳統程式碼弱點掃描。
它必須把：
Security
Privacy
Reliability
Recovery
Operations
Agent Safety
放在同一份 Release Decision 中。
新增：
demo-app/full-scan-demo/
├── ground-truth.json
├── scenario.js
└── output/
├── findings-report.json
├── evaluation.json
└── validation-summary.json
ground-truth.json 使用獨立版本：
{
"schemaVersion": "1.0.0",
"datasetVersion": "2026-09-29.1"
}
每個案例包含：
{
"id": "AUTH-01",
"domain": "security",
"ruleId": "SEC-AUTHZ-001",
"groundTruth": true,
"prediction": "confirmed",
"severity": "high",
"validator": "authorization",
"location": {
"path": "firestore.rules",
"line": 6,
"snippet": "allow read, write: if request.auth != null;"
}
}
這裡的 Repository 是系列專用的安全測試場。
它同時包含：
刻意保留的 Vulnerable Path
對應的 Safe Implementation
Dynamic Test Fixture
Safe Control
Agent Defense Fixture
所以今天量到的是：
Vibe Guard 對這份版本化驗收集的表現。
不能宣稱：
它在所有真實 Repository 都有相同的 83.3% Recall。
Day 27 已說明，小型固定資料集是 Calibration 與 Regression Tool，不是 Production Benchmark。
Ground Truth 中的 Positive Cases：
| ID | Domain | 問題 | Severity |
|---|---|---|---|
| AUTH-01 | Security | 登入者可跨帳號讀寫 Project | High |
| PRIV-01 | Privacy | Profile 回傳 Recovery Email 與 Internal Risk Note | Medium |
| PRIV-02 | Privacy | Error 與 Log 洩漏個資、Header 與 Stack | High |
| SECRET-02 | Security | Model API Key 被打包進 Browser Bundle | High |
| INPUT-01 | Security | Shell Interpolation 造成 Command Injection | High |
| INPUT-02 | Security | 不可信 Project Field 進入 innerHTML |
High |
| SUPPLY-01 | Security | Dependency Graph 含 Critical / High Advisory | Critical |
| RES-01 | Reliability | External Call 沒有 Timeout | High |
| RES-02 | Reliability | 非 Idempotent Payment Retry 重複扣款 | High |
| CAP-01 | Reliability | Unbounded Concurrent Work | 待檢出 |
| REC-01 | Reliability | Destructive Migration 破壞 Rollback | High |
| OBS-01 | Reliability | 無法證明 Production Telemetry Coverage | 待證據 |
這 12 題不是只有 Static Pattern。
其中多數有實際執行結果：
Firestore Emulator 跨帳號測試
HTTP Response 與 Log Capture
Browser Bundle Inspection
Command Injection Fixture
HTML Encoding Fixture
npm audit
Timeout Fixture
Idempotency Fixture
Capacity Fixture
Backup / Restore 與 Migration Rollback Fixture
OBS-01 比較特殊。
Repository 可以證明：
Demo 有一份可產生 Structured Log、Metric 與 Trace 的範例。
但不能證明：
正式應用真的部署這些 Telemetry。
Alert 是否存在。
Log 是否進入正式 Sink。
Trace 是否涵蓋外部依賴。
Retention 是否符合需求。
所以它的 Ground Truth 是：
Production Readiness 確實存在未滿足的可觀測性問題。
但 Agent 只能輸出：
requires_evidence
在 Day 27 的嚴格 Binary Scoring 中，這會算 FN。
如果資料集只放真問題，Agent 每題都喊 High 就能取得 100% Recall。
所以另外加入四個容易誤報的安全案例：
| ID | Agent 容易提出的主張 | Ground Truth |
|---|---|---|
| SECRET-01 | Local Firebase apiKey 是正式機密 |
Safe |
| RATE-01 | 沒有 App Middleware 就證明正式環境可被 DoS | Safe / Evidence Gap |
| HEALTH-01 | Static Firebase App 必須有 Repository-hosted /health |
Not Applicable |
| PRIV-03 | 必要的 Collaborator Email 一定是過度收集 | Safe |
SECRET-01 延續 Day 23。
Challenger 取得：
Localhost Runtime Guard
Firebase Emulator Connection
Firebase Client Configuration 語意
後，正確拒絕：
Exposed Firebase API key grants production database access
RATE-01 無法只靠 Repository 決定。
正式環境可能已有：
CDN
Gateway Quota
Firebase App Check
Platform Rate Limit
Budget Alert
所以它保留為 requires_evidence，但不被當成已確認 DoS。
HEALTH-01 則是 Scope 錯誤。
這個 Repository 的主應用是：
Local-only Firebase Static Web Application
不能因為後端服務通常需要 Readiness Endpoint，就要求 Static Hosting Repository 實作一個不存在的 Application Server。
PRIV-03 是今天刻意保留的誤報。
Agent 看見 Email Collection 後，沒有充分理解：
產品功能需要邀請 Collaborator
使用者已知情
用途已定義
存取已有 Policy
因此錯誤輸出 Confirmed。
這會讓完整結果不只是「每項防線都 PASS」的展示。
完整掃描不是只讀既有 JSON。
full-scan-demo/scenario.js 會重新執行：
adversarial-validation:demo
privacy:demo
secret:demo
input:demo
supply-chain:demo
observability:demo
resilience:demo
capacity:demo
recovery:demo
prompt-injection:defense
evaluation:demo
pr-review:demo
每條 Workflow 都有不同目的。
| Workflow | 驗證內容 |
|---|---|
| Adversarial Validation | AUTH、Firebase Key 與 Rate Limit Candidate |
| Privacy | Profile、Error Response 與 Log Data |
| Secret | Source Key 是否進入 Browser Bundle |
| Input | Command Injection、Allowlist 與 HTML Encoding |
| Supply Chain | Lockfile Integrity、Install Hook 與 Advisory |
| Observability | Structured Log、Metric 與 Trace 範例 |
| Resilience | Timeout、Retry、Backoff 與 Idempotency |
| Capacity | Readiness、Circuit Breaker 與 Concurrency Limit |
| Recovery | Restore、Checksum、Expand / Contract Migration |
| Prompt Injection | Agent Capability Boundary |
| Evaluation | Precision、Recall、FPR 與 Regression Threshold |
| PR Review | Changed-line Scope、Annotation 與 Merge Gate |
每個案例不是只檢查 Process Exit Code。
它還要求特定證據存在。
例如 Command Injection：
Unsafe command output:
"Checking release-notes\nINJECTED"
Idempotency：
Charges created without idempotency: 2
Charges created with idempotency: 1
Rollback：
Old application after rollback:
["<missing-name>","<missing-name>"]
Authorization：
attackerRead.allowed = true
attackerWrite.allowed = true
如果 Command 成功結束，卻沒有產生預期證據，完整掃描仍會失敗。
這避免：
測試程式因為沒有 Assertion 而總是 Exit 0。
完整執行時，Lockfile Inventory 為：
Direct dependencies: 7
Locked package entries: 874
Entries with integrity: 874/874
Packages with install hook: 6
這表示 Lockfile Integrity Metadata 完整。
但 npm audit 同時回報：
Total vulnerabilities: 16
Critical: 1
High: 3
Moderate: 12
Affected direct: firebase-tools (high)
所以不能只因為：
有 package-lock.json
每個 Entry 都有 integrity
就判定 Supply Chain 安全。
這兩種控制回答不同問題：
Integrity
安裝內容是否對應 Lockfile 宣告的 Artifact？
Advisory
這個版本是否已知存在安全問題？
正式判斷還要加入：
Dependency 是否只在 Dev 使用
Vulnerable Code 是否 Reachable
CI 是否會執行 Install Script
Runner 是否有 Secret
是否有可用修正版
升級是否破壞相容性
今天只要出現 Critical 或 High Advisory，就先保留 Blocking Finding。
這是保守的 Demo Policy。
每個非 no_finding 結果都轉成 Day 24 的 Schema 2.0.0。
例如 AUTH-01：
{
"id": "AUTH-01",
"ruleId": "SEC-AUTHZ-001",
"domain": "security",
"verdict": "confirmed",
"status": "open",
"severity": "high",
"confidence": "high",
"locations": [
{
"path": "firestore.rules",
"startLine": 6,
"endLine": 6,
"snippet": "allow read, write: if request.auth != null;"
}
],
"verification": [
{
"type": "exploit",
"result": "passed"
}
]
}
Schema 會強制：
confirmed 必須有 passed exploit verification
requires_evidence 必須列出 missingEvidence
rejected 必須使用 false_positive status
status 必須與 history 最後事件一致
fingerprint 必須是合法 SHA-256
完整報告共 15 項。
為什麼不是 16？
因為 CAP-01 是：
no_finding
Scanner 根本沒有建立 Candidate 或 Finding。
它只會出現在 Evaluation Error 中。
這個差異很重要：
requires_evidence
Agent 看到了風險，但無法完成確認。
no_finding
Agent 完全沒有提出這個問題。
兩者的改善方式不同。
執行：
cd /media/mickey/777/ithome/demo-app
npm run full-scan:demo
實際輸出：
VIBE GUARD FULL PRODUCTION READINESS SCAN
Dataset: 2026-09-29.1
Validators: 12/12 completed
Cases: 16 (12 production issues, 4 safe controls)
FINDINGS
Confirmed: 11
Requires evidence: 2
Rejected: 2
No finding: 1
DETECTION
TP=10 FP=1 TN=3 FN=2
Precision: 90.9%
Recall: 83.3%
F1: 87.0%
FPR: 25.0%
Accuracy: 81.3%
Abstain: 12.5%
DOMAIN RECALL
security 100.0% (5/5)
privacy 100.0% (2/2)
reliability 60.0% (3/5)
PIPELINE CONTROLS
PASS canonicalSchema
PASS pullRequestAdapter
PASS evaluationGate
PASS promptInjectionGate
Blocking High/Critical: 9
Release Gate: FAIL
Artifacts: full-scan-demo/output/
Console 顯示：
Confirmed: 11
但 Ground Truth 對照是：
TP = 10
FP = 1
也就是：
10 個真的被抓到
1 個安全案例被錯誤確認
因此 Precision：
Precision
= TP / (TP + FP)
= 10 / 11
= 90.9%
如果只在產品頁寫：
Vibe Guard 找到 11 個問題。
就把誤報偷偷算成能力。
正確說法是：
Vibe Guard 產生 11 個 Confirmed Findings；
其中 10 個符合 Ground Truth，1 個是 False Positive。
Recall：
Recall
= TP / (TP + FN)
= 10 / 12
= 83.3%
也就是：
12 個真實 Production 問題中，
10 個被確認，
2 個沒有成為 Confirmed Finding。
兩個 FN 是：
CAP-01
Unbounded Concurrent Work
Prediction: no_finding
OBS-01
Production Telemetry Coverage
Prediction: requires_evidence
Day 27 的嚴格規則把 requires_evidence 視為未確認。
因為它目前不能：
提供明確 Severity
自動阻擋
指派具體修正
證明風險已重現
同時，它也另計 Abstention：
OBS-01
RATE-01
Abstention Rate = 2 / 16 = 12.5%
Capacity Fixture 實際顯示：
Unbounded:
completed=5
peak_in_flight=5
Limited:
accepted=2
rejected=3
peak_in_flight=2
Ground Truth 判定：
沒有 Concurrency Limit 時，所有工作同時進入。
這是可執行、可量測的 Capacity Risk。
但完整掃描沒有為它建立 Finding。
這表示問題發生在：
Hunter Coverage
而不是：
Challenger 過度保守。
改進方式應是增加 Rule：
REL-CAPACITY-001
Required Evidence：
Concurrency Boundary
Queue Limit
Backpressure
Over-capacity Response
Load Fixture
Candidate 條件可以是：
存在可由外部或批次工作驅動的非同步操作，
但未找到 Queue、Semaphore、Worker Limit 或平台配額證據。
接著執行：
正常負載
尖峰負載
Over-capacity
Recovery
而不是在 Prompt 中追加一句：
請記得檢查容量。
Rule、Evidence 與 Fixture 才能形成可回歸的能力。
OBS-01 與 CAP-01 不同。
Agent 已經辨識：
Repository 無法證明正式 Telemetry 已部署。
所以輸出：
requires_evidence
缺少：
Production Log Sink and Retention Policy
Deployed Metrics and Alert Definitions
Trace Coverage for External Dependencies
這是合理的不確定性。
不能為了提高 Recall，直接把所有 Evidence Gap 升級成 High。
否則：
Precision 會下降
PR 會被 Repository 外資訊錯誤阻擋
Agent 會把「不知道」說成「已確認」
更好的整合是讓 CLI 產生 Evidence Request：
{
"findingId": "OBS-01",
"owner": "sre-team",
"requiredEvidence": [
"production-log-sink",
"alert-policy-export",
"trace-coverage-report"
],
"dueBefore": "release-approval"
}
Release Policy 可以規定：
High Confirmed Finding
→ 直接阻擋。
Required Production Evidence Missing
→ 在進入 Release Approval 前必須補齊。
Low-risk Repository Unknown
→ Warning，不直接阻擋 PR。
這比把所有 Unknown 混成同一種紅燈更可操作。
PRIV-03 的主張是：
Required collaborator email is unnecessary data collection.
Ground Truth 是 Safe。
Email 在這個案例中具備：
明確產品目的
使用者可理解的流程
限定用途
存取控制
但 Scanner 只看見：
系統收集 Email
就確認 Data Minimization Finding。
這代表 Privacy Context 不足。
安全與 Reliability 常能用：
Exploit
Timeout
Status Code
Duplicate Side Effect
建立較直接的 Ground Truth。
Privacy 常需要：
Purpose
Consent
Retention
Access Role
Legal Basis
User Expectation
如果 Context Selector 只選 Source Code，模型可能永遠看不到這些正式政策。
改進方法不是：
看到 email 就不要報。
而是建立 Privacy Evidence Contract：
Collected Field
Declared Purpose
Required Feature
Retention
Access Control
Disclosure
Deletion Path
Policy Approval
缺少 Contract 時，應先使用：
requires_evidence
而不是 confirmed。
整體指標：
Precision 90.9%
Recall 83.3%
F1 87.0%
FPR 25.0%
Accuracy 81.3%
看起來不錯。
但 Domain Slice：
Security Recall 100.0% (5/5)
Privacy Recall 100.0% (2/2)
Reliability Recall 60.0% (3/5)
顯示 Reliability 明顯較弱。
詳細矩陣：
| Domain | TP | FP | TN | FN | Precision | Recall |
|---|---|---|---|---|---|---|
| Security | 5 | 0 | 1 | 0 | 100.0% | 100.0% |
| Privacy | 2 | 1 | 0 | 0 | 66.7% | 100.0% |
| Reliability | 3 | 0 | 2 | 2 | 100.0% | 60.0% |
Privacy 雖然 Recall 100%，Precision 只有 66.7%。
因為三個 Privacy Positive Prediction 中，有一個是假警報。
Reliability Precision 100%，卻不能說它表現最好。
它只是：
只確認三個，而且三個都對。
另外兩個真問題沒有確認。
所以 Domain Roadmap 很清楚：
Privacy
補 Policy Context，降低 FP。
Reliability
補 Capacity Rule 與 Production Evidence Connector，提高 Recall。
Safe Control 只有四個。
其中一個被誤報：
FPR = FP / (FP + TN)
= 1 / 4
= 25%
這不表示真實世界每四個安全專案就一定有一個被誤報。
它表示：
在目前四個 Negative Control 中，有一題失敗。
樣本很小，比例會劇烈跳動。
再增加一個 FP：
FPR = 2 / 4 = 50%
修好唯一 FP：
FPR = 0 / 4 = 0%
因此文章保留：
FP=1
TN=3
FPR=25%
三個資訊，不只放百分比。
完整輸出顯示：
PASS canonicalSchema
PASS pullRequestAdapter
PASS evaluationGate
PASS promptInjectionGate
接著又顯示：
Release Gate: FAIL
這不是矛盾。
Control PASS 的意思是：
控制本身正確運作。
例如 Pull Request Adapter PASS，代表：
它正確辨識 AUTH-01 位於 Changed Line，
並產生 Gate: FAIL。
如果 Adapter 錯誤讓 PR 通過，Control 才應是 FAIL。
同理：
Canonical Schema PASS
報告符合 Contract。
Evaluation Gate PASS
Validated Workflow 達到 Day 27 的 Calibration Threshold。
Prompt Injection Gate PASS
五個攻擊沒有執行 Forbidden Effect。
這些控制都可以正常，但被控制的應用仍然有九個 Blocking Finding。
這正是守門員應該回報：
Scanner 健康。
報告可信。
應用尚未達到上線條件。
Default Release Policy：
confirmed
severity >= high
九個 Blocker：
| ID | Severity | 原因 |
|---|---|---|
| SUPPLY-01 | Critical | Dependency Graph 含 Critical Advisory |
| AUTH-01 | High | 跨帳號讀寫 |
| PRIV-02 | High | Error / Log 洩漏敏感資料 |
| SECRET-02 | High | Model Credential 進入 Browser Bundle |
| INPUT-01 | High | Command Injection |
| INPUT-02 | High | Stored XSS |
| RES-01 | High | External Call 無 Timeout |
| RES-02 | High | Retry 重複扣款 |
| REC-01 | High | Migration 破壞 Rollback |
PRIV-01 是 Confirmed Medium。
它需要修正，但不符合今天 High Gate。
PRIV-03 也是 Medium，卻是 False Positive。
如果 Policy 設成：
fail-on medium
它會錯誤阻擋 Release。
這再次說明：
Severity Threshold 越低，
越需要更高 Precision 與更好的 Baseline 管理。
不能使用：
16 題答對 13 題，Accuracy 81.3%，所以可以上線。
Production Gate 不是學校及格線。
只要存在：
可重現的跨帳號存取
Browser Secret
Command Injection
Stored XSS
Critical Dependency Advisory
重複扣款
Rollback 失敗
就不能因為整體分數超過 80 而放行。
Evaluation Metric 與 Release Policy 解決不同問題：
Evaluation
Scanner 準不準？
Release Policy
目前被確認的風險是否可接受？
Scanner 可以有 100% Precision，但只要確認一個 Critical Finding，Release 仍應失敗。
反過來，Scanner 也可能因為品質太差而不能成為 Required Gate。
所以正式上線需要雙重 Gate：
Scanner Quality Gate
Precision、Recall、FPR、Attack Success Rate。
Application Readiness Gate
Confirmed Finding、Missing Evidence、Risk Acceptance。
今天：
Scanner Quality Controls: PASS
Application Readiness: FAIL
九個 Blocker 都很重要，但仍需要排序。
第一批應優先處理可直接造成邊界跨越或程式執行的問題：
SUPPLY-01
AUTH-01
SECRET-02
INPUT-01
INPUT-02
第二批處理可能造成交易與服務故障的 Reliability 問題：
RES-01
RES-02
REC-01
PRIV-02 也應在正式流量前修正，因為 Error Path 往往在事故期間大量觸發。
實務排序可以使用：
Severity
Exploitability
User Impact
Data Sensitivity
Reachability
Change Scope
Fix Complexity
Blast Radius
Rollback Risk
例如 Critical Dependency Advisory 若只存在於不會進入 Production Image 的 Local Dev Tool，可能需要重新評估 Exposure。
但不能只因為它在 devDependencies 就自動降級。
CI 仍可能：
執行 Install Script
持有 Repository Token
存取 Artifact
產生 Release
Reachability 要包含 Build 與 CI Threat Model。
完整 Scan 的價值不是只在發現九個 Blocker。
修正後必須看到：
Vulnerable Fixture
原本 Exploit 不再成功。
Safe Fixture
合法功能仍然可以完成。
Canonical Finding
status 轉為 resolved。
Regression Verification
result = passed。
Release Gate
重新計算。
例如 AUTH-01：
修正 Firestore Rules
→ Owner 仍可讀寫
→ Attacker Read 被拒絕
→ Attacker Write 被拒絕
INPUT-01：
exec
→ execFile
→ 固定 Executable
→ Argument Array
→ Channel Allowlist
RES-02：
加入 Idempotency Key
→ 第一次 Side Effect 完成但 Response 遺失
→ Retry 回傳相同 Charge
→ Durable Charge Count 仍為 1
REC-01：
Destructive Rename
→ Expand
→ Backfill
→ 雙讀／雙寫
→ 舊版本流量歸零
→ Contract
不能只修改 Source Pattern，卻不重新執行 Exploit。
findings-report.json 適合：
CLI
PR Adapter
SARIF Exporter
Ticket Automation
Baseline Comparison
Status Lifecycle
evaluation.json 保存：
Confusion Matrix
Precision
Recall
F1
FPR
Accuracy
Abstention
Per-domain Slice
validation-summary.json 保存：
哪些 Workflow 執行完成
每個 Validator 是否取得預期證據
Pipeline Control 狀態
Blocking Finding IDs
Release Gate
這三份 Artifact 分別回答：
發現了什麼？
Scanner 表現如何？
驗證流程是否正常？
不要全部塞進一份巨大自然語言報告。
不同 Consumer 需要不同的穩定 Contract。
Day 26 的第一版 Policy 只阻擋：
confirmed
high or critical
changed-line
完整 Repository Scan 找到九個 Blocker，不代表每個 PR 都應立即被九個既有問題阻擋。
需要 Baseline：
Base Revision Findings
Head Revision Findings
Fingerprint Comparison
將結果分成：
New
Reopened
Unchanged
Resolved
合理的導入策略：
否則第一次啟用 Vibe Guard，就可能因歷史債務讓所有 PR 停擺。
但正式 Release Approval 可以使用更嚴格政策：
所有未接受風險的 Critical / High 必須清零。
必要 Production Evidence 必須完整。
Rollback、Capacity 與 Observability Gate 必須通過。
PR Gate 與 Release Gate 不一定使用相同門檻。
今天確實執行了所有 Fixture，但仍不是正式 Production Review。
缺少：
Google SRE 的可靠發布實務特別強調：
逐步 Rollout
觀察真實行為
在驗證失敗時 Rollback
所以 Pre-release Scan 不能取代：
Canary
Runtime Monitoring
Incident Response
Post-release Verification
Vibe Guard 是 Release Decision 的輸入，不是讓團隊停止 SRE 實務的理由。
將目前成果放在一起：
Pull Request / Release Candidate
↓
Read-only Checkout
↓
Recon
├─ Architecture
├─ Trust Boundary
├─ Data Flow
└─ Unknown
↓
Rule Engine
├─ Security
├─ Privacy
└─ Reliability
↓
Context Selector
├─ Required Evidence
├─ Minimal Source Range
└─ Provenance / Trust Label
↓
Hunter
└─ Candidate only
↓
Challenger
├─ Exploitation
├─ Impact
├─ Baseline
├─ Mitigation
└─ Runtime
↓
Deterministic Validators
├─ Emulator
├─ Browser / HTTP Fixture
├─ Dependency Audit
├─ Load / Timeout
└─ Recovery Drill
↓
Canonical Findings Schema
↓
Policy
├─ PR Changed-line Gate
├─ Release Gate
└─ Evidence Gate
↓
Summary / Annotation / Artifact
整條流程外圍還要有：
Prompt Injection Defense
Least Privilege
Tool Allowlist
Network Egress Policy
Secret Isolation
Audit Log
Evaluation Regression
這才是：
AI Production Readiness Agent
而不只是：
把整個 Repository 貼給模型，請它找問題。
所以，Vibe Guard 到底能抓出多少 Production 問題？
在 Day 29 的固定驗收集中：
真實問題：12
確認抓到：10
未確認： 2
Recall: 83.3%
它產生 11 個 Confirmed Finding：
真警報：10
假警報：1
Precision: 90.9%
兩個未確認問題：
CAP-01 完全漏掉
OBS-01 停在 requires_evidence
唯一誤報：
PRIV-03 將必要的 Collaborator Email 判成過度收集
Domain 表現：
Security Recall 100%
Privacy Recall 100%，但有 1 個 FP
Reliability Recall 60%
最終有：
1 Critical
8 High
9 Blocking Findings
所以：
Release Gate: FAIL
這是今天最重要的結果。
不是因為 Agent 全部答對。
而是它能在：
保留誤報
公開漏報
承認 Evidence Gap
通過 Schema
抵抗 Prompt Injection
正確觸發 PR Policy
的同時，做出可追蹤的：
不要上線
決定。
明天是系列最後一天。
Day 30 會回顧我們如何從：
一句 Vibe Coding Prompt
走到：
能執行 Recon、驗證 Evidence、計算品質、進入 PR，
而且知道自己仍可能犯錯的 Production Readiness Agent。
我們也會整理：
哪些能力已完成
哪些限制仍存在
正式產品化需要什麼
AI 在 Production Gate 中應該扮演什麼角色
iThome鐵人賽
看影片追技術