30 天前，我們從一句問題開始：

Vibe Coding 讓功能很快能動，
但誰來確認它真的可以上線？

Day 1 設定的目標，不是再做一個會聊天的 Code Reviewer。

我們想建立：

AI Production Readiness Agent

它要能檢查：

Security
Privacy
Reliability
Observability
Deployment
Recovery
Agent Safety

而且不能只輸出一篇看起來專業的作文。

每個結論都應該回答：

問題在哪裡？
攻擊者或故障條件是什麼？
能否實際重現？
會造成什麼影響？
有哪些反證或既有控制？
缺少哪些正式環境證據？
這項結果是否應阻擋上線？

昨天的完整實測給出最後成績：

12 個真實 Production 問題
10 個確認抓到
2 個未確認
1 個 False Positive

Precision 90.9%
Recall    83.3%
F1        87.0%

被測 Demo 仍有：

1 Critical
8 High

所以：

Release Gate: FAIL

今天不再加入新的漏洞類型。

我們要回答四個最後問題：

1. 30 天到底完成了什麼？
2. 哪些能力仍只是 Demo？
3. Vibe Guard 現在可以擁有多少決策權？
4. 要如何從 Prototype 走向真正的 Production Service？

先回到 Day 1 的三項承諾

Day 1 希望完成：

1. 一個可以操作的 Production Readiness Agent。
2. 一套涵蓋資安、隱私、可靠性與部署的檢查方法。
3. 一組可以衡量檢出率、誤報率與報告品質的測試案例。

30 天後，三項都已經有可執行版本。

第一項：

可以操作的 Agent

目前可以從 Terminal 執行：

cd /media/mickey/777/ithome/demo-app
npm run vibe-guard -- scan .

也可以執行完整驗收：

npm run full-scan:demo

它會產生：

Canonical Findings Report
Evidence Gap
Policy Gate
Exit Code
PR Summary
Annotation
Evaluation Metrics
Prompt Injection Events

第二項：

Production Readiness 檢查方法

系列建立的不是一張固定 Checklist，而是一條 Evidence Pipeline：

Recon
  → Rule
  → Context
  → Candidate
  → Challenge
  → Dynamic Verification
  → Structured Finding
  → Policy
  → Human Decision

第三項：

可量測的測試案例

目前有：

固定 Ground Truth
Vulnerable Case
Safe Control
Confusion Matrix
Per-domain Slice
Abstention
Prompt Injection Attack
Full-scan Release Gate

所以系列沒有停在：

Gemini 回答得很不錯。

而是走到：

Gemini 與整條 Agent System，
在固定案例上答對多少、答錯多少、漏掉多少？

四個階段完成了什麼？

30 天可以分成四段。

第一階段：

建立 Demo 與第一個 AI Reviewer

我們用 Firebase 建立：

Authentication
Cloud Firestore
Hosting
Local Emulator

再刻意加入：

跨帳號授權
個資暴露
Browser Secret
Injection
不安全 Log
Timeout
Recovery Gap

這個順序很重要。

如果沒有已知答案的靶場，就無法知道 Agent 是真的找到問題，還是只是生成一段合理文字。

第二階段：

建立 Production Engineering 知識與 Fixture

Day 7 到 Day 15 分別處理：

主題	實際證據
Authentication / Authorization	Firestore Emulator 雙帳號測試
Privacy / Logging	HTTP Response 與 Log Capture
Secret	Browser Bundle Inspection
Input Safety	Command Injection 與 HTML Encoding
Supply Chain	Lockfile Inventory 與 npm audit
Observability	Logs、Metrics、Traces
Resilience	Timeout、Retry、Backoff、Idempotency
Capacity	Health、Circuit Breaker、Concurrency Limit
Recovery	Backup、Checksum、Migration、Rollback

這些 Fixture 後來成為 Agent 的 Tool。

模型不需要憑空猜測：

這個 Retry 可能重複扣款。

它可以要求執行：

第一次 Side Effect 成功但 Response 遺失，
第二次 Retry 是否建立第二筆 Charge？

第三階段：

把 Reviewer 變成 Agent System

我們加入：

Recon
Rule Engine
Structured Output
Context Selector
Multi-agent Roles
Challenger
Findings Lifecycle
CLI

第四階段：

把 Agent 接進工程流程並評估

最後五天完成：

Pull Request Gate
Precision / Recall / FPR
Prompt Injection Defense
Full Production Readiness Scan
Final Release Dossier

這四階段對應一條很清楚的演進：

先知道要檢查什麼
再建立可執行證據
再讓 Agent 組織推理
最後才給它工程流程中的權限

順序不能反過來。

如果一開始就讓 Agent 自動阻擋 PR，卻沒有 Ground Truth、Schema 與誤報控制，團隊很快就會關掉它。

最後的 Vibe Guard 架構

目前完整流程：

Repository / Pull Request / Release Candidate
  ↓
Read-only Checkout
  ↓
Recon
  ├─ Application Type
  ├─ Actors
  ├─ Data Flow
  ├─ Trust Boundaries
  └─ Unknown
  ↓
Rule Engine
  ├─ Security
  ├─ Privacy
  ├─ Reliability
  └─ Required Evidence
  ↓
Context Selector
  ├─ Minimal Source Range
  ├─ Architecture Facts
  ├─ Rule-specific Evidence
  └─ Provenance / Trust Label
  ↓
Hunter
  └─ Candidate only
  ↓
Challenger
  ├─ Exploitation
  ├─ Impact
  ├─ Baseline
  ├─ Mitigation
  └─ Runtime
  ↓
Deterministic Validators
  ├─ Emulator
  ├─ Browser / HTTP
  ├─ Dependency Audit
  ├─ Timeout / Load
  └─ Recovery Drill
  ↓
Canonical Findings Schema
  ├─ Fingerprint
  ├─ Verdict
  ├─ Status
  ├─ Severity
  ├─ Verification
  ├─ Missing Evidence
  └─ Remediation
  ↓
Policy Consumers
  ├─ Terminal
  ├─ Pull Request
  ├─ Release Gate
  ├─ Artifact
  └─ Evaluation

整條流程外圍還有：

Least Privilege
Prompt Injection Defense
Tool Allowlist
Secret Isolation
Network Policy
Output Validation
Audit Log
Human Approval

這些外圍控制不是附加功能。

只要 Agent 可以讀取不可信 Repository 並呼叫 Tool，它們就是核心架構。

Gemini 最適合負責什麼？

30 天後，我對 Gemini 在這個系統中的定位更清楚了。

它很適合：

• 從分散 Source 中建立架構假設。
• 理解跨檔案資料流與業務語意。
• 將 Rule 套用到不同 Framework。
• 提出攻擊或故障 Candidate。
• 尋找可能推翻 Candidate 的反證。
• 整理 Missing Evidence。
• 將技術結果解釋給不同角色。
• 協助產生下一個驗證計畫。

例如只看：

request.auth != null

還不足以確認越權。

Gemini 可以串起：

Firestore Rule
ownerId Data Model
Client Query
Authenticated Attacker
Cross-account Impact

形成可測試 Hypothesis。

這種跨檔案、跨概念的語意推理，是傳統單一 Regex 很難完整處理的部分。

Gemini 不應獨自負責什麼？

它不應獨自決定：

是否真的執行 Shell
是否讀取 Secret
是否向外傳送資料
是否修改 Repository
是否接受風險
是否關閉 Finding
是否部署 Production
是否繞過 Branch Protection

也不應成為：

自己發現問題
自己驗證
自己改 Severity
自己核准上線

的單一權威。

這些操作需要：

Deterministic Policy
Identity and Authorization
Argument Validation
Independent Evidence
Human Accountability

最終設計原則可以寫成：

LLM 負責語意推理與提出假設。
程式負責權限、Schema、測試與 Policy。
人類負責風險接受與高影響決策。

這不是因為模型「沒有用」。

而是因為不同元件應負責自己最擅長、最可驗證的工作。

Final Release Dossier

今天新增：

demo-app/final-dossier-demo/
├── scenario.js
└── output/
    ├── dossier.json
    └── executive-summary.md

執行：

cd /media/mickey/777/ithome/demo-app
npm run final-dossier:demo

它會先重新執行 Day 29 Full Scan，再整合：

Findings Report
Full-scan Evaluation
Validation Summary
Prompt Injection Report
Day 27 Calibration Result

產生三項不同決策：

被測應用是否可以 Release？
Scanner 可以進入哪個部署階段？
Agent 是否可以自動核准 Production？

不能把這三題混在一起。

Dossier 實際輸出

VIBE GUARD FINAL DOSSIER
Target release:       NO-GO
Scanner deployment:   PILOT
Autonomous approval:  DISALLOWED

QUALITY
Precision:             90.9%
Recall:                83.3%
Reliability recall:    60.0%
False-positive rate:   25.0%
Prompt injection ASR:  0.0%

Blocking findings:    9 (1 Critical, 8 High)
Capabilities:         10 implemented, 1 partial, 2 planned
Promotion:            PILOT -> REQUIRED GATE after P1 thresholds
Artifacts: final-dossier-demo/output/

為什麼 Target 是 NO-GO？

Day 29 找到：

1 Critical
8 High

包含：

跨帳號存取
敏感 Log
Browser Model Credential
Command Injection
Stored XSS
Dependency Advisory
Missing Timeout
Duplicate Payment
Broken Rollback

這些是經 Fixture 或獨立證據確認的 Blocking Finding。

所以無論 Scanner 的 Accuracy 是多少，被測應用都不應上線。

Target Release = NO-GO

是 Application Risk Decision。

為什麼 Scanner 是 PILOT？

Vibe Guard 已經能：

產生可驗證 Finding
拒絕已知假警報
進入 Terminal 與 PR
計算品質指標
抵抗測試集中的 Prompt Injection

但完整驗收仍顯示：

Recall              83.3%
Reliability Recall  60.0%
FPR                 25.0%

而且資料集只有 16 題。

目前最合理的部署階段是：

PILOT

也就是：

• 在少量 Repository 試行。
• 保留人工 Review。
• 先以 Advisory 或有限 Gate 運作。
• 收集 Production Distribution。
• 追蹤 Override 與 Missed Finding。
• 定期重新標註 Ground Truth。

它還不應直接成為全公司的唯一 Required Gate。

為什麼 Autonomous Approval 必須 DISALLOWED？

即使未來 Precision 與 Recall 更高，Agent 也不應是唯一的 Production Release Approver。

因為部分決策涉及：

業務風險
法規
使用者承諾
維運能力
事件時間點
回滾窗口
跨團隊依賴
風險接受

這些資訊不一定存在於 Repository。

而且責任不能被一句：

AI 說可以上線。

取代。

Agent 可以：

整理證據
套用明確 Policy
阻擋已確認的禁止條件
要求缺少的資料
記錄誰做了決定

但風險接受必須由有權限的人類角色完成：

Service Owner
Security
Privacy
SRE
Release Manager

NIST AI Risk Management Framework 強調將 Trustworthiness 納入 AI 系統的設計、開發、使用與評估。

對 Vibe Guard 而言，這表示：

不只評估它的輸出，
也要治理它在組織中擁有的權限與責任。

目前完成的十項能力

Final Dossier 將下列能力標記為 Implemented：

能力	主要 Artifact
Architecture / Trust-boundary Recon	recon-demo/architecture.json
Versioned Rule Pack	rule-engine-demo/rules.json
Task-scoped Context Selection	context-selection-demo/context.json
Hunter / Challenger Separation	adversarial-validation-demo/output/challenges.json
Dynamic Verification Fixture	full-scan-demo/output/validation-summary.json
Canonical Findings Lifecycle	full-scan-demo/output/findings-report.json
Local CLI / Exit Code	vibe-guard-cli/index.js
PR Changed-line Gate	vibe-guard-pr-output/pr-summary.md
Versioned Evaluation	full-scan-demo/output/evaluation.json
Prompt Injection Boundary	prompt-injection-defense-demo/output/report.json

「Implemented」在這裡表示：

Demo 中有可執行程式、固定輸入與可檢查輸出。

不表示：

已經達到多租戶、高可用、合規的正式產品品質。

一項 Partial：Production Evidence Connector

目前 Vibe Guard 可以列出：

Production hosting architecture
Gateway / App Check / Quota
Log sink
Alert policy
Trace coverage

等 Missing Evidence。

但它尚未直接連接正式環境去取得：

Firebase / Google Cloud Project 設定
IAM Policy
Cloud Logging Sink
Cloud Monitoring Alert
Budget
Quota
Deployment Revision
Backup Policy
Restore Drill

所以這項能力是：

PARTIAL

Repository Scanner 與 Production Evidence Collector 應使用不同身份。

後者只需要：

讀取經允許的設定與證據。

不應取得：

部署
修改 IAM
刪除資源

權限。

而且收集到的 Cloud Evidence 仍要保存：

Project
Resource
Revision
Timestamp
Principal
Digest

避免用過期截圖或另一個環境的設定替目前 Release 背書。

兩項 Planned 能力

第一項：

Cross-repository and Language Coverage

目前 Demo 主要是：

Node.js
Browser JavaScript
Firebase
Firestore Rules
GitHub Actions

尚未證明對：

Python
Go
Java
.NET
Kubernetes
Terraform
SQL Migration
Mobile App
Multi-repository Architecture

具有相同能力。

第二項：

Canary、Runtime Drift 與 Post-release Feedback

Pre-release Review 無法預測所有真實行為。

正式系統還要將：

Incident
Rollback
Alert
False Positive Override
Post-release Vulnerability
Canary Regression

回饋到 Evaluation Dataset。

Google SRE 的 Launch Checklist 包含：

Capacity
Failover
Monitoring
Backup / Restore
Rate Limit
Timeout
Retry
Canary
Staged Rollout

這些不是掃描一次就永久完成的項目。

Production Readiness 是持續狀態，不是一次性證書。

最重要的十個學習

第一個：

能跑不等於能上線。

登入、寫資料、顯示畫面都成功，不代表 Authorization、Privacy、Capacity 與 Recovery 已完成。

第二個：

Checklist 不等於 Finding。

「沒有看到 Rate Limit Middleware」只能建立調查方向。

要成為漏洞，還需要：

可達路徑
缺少既有控制
可重現影響
正確 Scope

第三個：

Evidence 比語氣更重要。

一段很有自信的 High 報告，不如：

attacker-user read allowed = true
attacker-user write allowed = true

第四個：

不知道是一種合法結果。

requires_evidence 不應被硬改成 Confirmed 或 Rejected。

但它也不能從 Evaluation 消失。

第五個：

發現與驗證要分開。

Hunter 的成功條件是找 Candidate。

Challenger 的成功條件是找到反證。

第六個：

Context Selection 是品質控制，也是安全控制。

太少 Context 會漏掉資料流。

太多 Context 會增加 Token、噪音與 Prompt Injection Surface。

第七個：

Structured Output 只是開始。

JSON 合法不代表 Finding 正確。

還要驗證：

Source
Evidence
Lifecycle
Severity
Policy

第八個：

Agent 的權限必須比 Prompt 更可靠。

即使模型被 Prompt Injection 說服，Read-only Scanner 仍不應擁有 Secret、Shell、Write 與任意 Egress。

第九個：

評估要公開失敗。

Day 29 明確保留：

CAP-01 漏報
OBS-01 Abstention
PRIV-03 誤報

這三題比 90.9% Precision 更能指出下一步。

第十個：

Agent 是決策支援，不是責任替代品。

它可以讓風險更早被看見、讓證據更一致、讓 Policy 更自動化。

但最終 Accountability 仍屬於人類與組織。

哪些做法沒有採用？

第一個沒有採用的做法：

把整個 Repository 一次貼給模型。

原因：

Context 無法無限擴張
容易遺漏真正相關檔案
Prompt Injection Surface 變大
成本與延遲不可控

第二個：

只用一個 Agent 完成所有工作。

原因：

初始假設會污染後續驗證
角色權限無法分離
Finding 很容易被自我合理化

第三個：

將所有警告都當成漏洞。

原因：

Hardening 不等於 Exploitable Finding
Unknown 不等於 High
缺少第二層控制不一定代表第一層已失效

第四個：

以 Accuracy 當唯一成績。

原因：

類別不平衡會美化結果
無法看見 FP / FN 成本
無法看見 Domain 弱點

第五個：

讓 PR Workflow 持有寫入權限並執行不可信程式碼。

原因：

Prompt Injection 與惡意 PR 都可能濫用 Token

第六個：

讓模型直接執行 Tool。

原因：

Model Output 是 Proposal，不是 Authorization。

正式導入的三階段 Roadmap

Final Dossier 將下一步分成 P0、P1、P2。

P0：

先讓被測應用可以上線

工作：

• 修正 1 個 Critical 與 8 個 High。
• 重跑 Exploit 與 Regression Fixture。
• 將 Finding 正確轉為 resolved。
• 補齊 Rollback 與 Secret Removal Evidence。

Promotion Condition：

沒有未接受風險的 Critical / High。

P1：

把 Vibe Guard 從 Pilot 提升成可靠 Required Gate

工作：

• 加入漏掉的 Capacity Rule。
• 補齊 Privacy Purpose、Consent、Retention 與 Access Context。
• 串接 Observability、Quota、IAM 與 Deployment Evidence。
• 擴充 Hidden Holdout。
• 對非確定性推論重複執行。
• 增加不同 Repository 與 Framework。

示範門檻：

Overall Recall >= 90%
Reliability Recall >= 80%
FPR <= 10%
多次執行結果穩定

這不是通用標準。

每個組織仍要依：

風險容忍
Review 成本
Severity
是否自動阻擋
人類覆核能力

決定門檻。

P2：

將 Agent 作為受治理的 Production Service 運作

工作：

• 多租戶身份與資料隔離。
• Audit Retention 與 Tamper Resistance。
• 成本、Latency 與 Availability SLO。
• Tool / Rule / Prompt / Model Provenance。
• Canary 與 Post-release Feedback。
• Incident Response 與 Kill Switch。
• 定期 Prompt Injection Red Team。
• Security、Privacy、SRE 與 Service Owner Policy Review。

Promotion Condition：

Agent 自身也通過 Production Readiness Review。

Agent 自己也要被 Vibe Guard 檢查

這可能是系列最有趣的循環。

Vibe Guard 用來檢查別人的：

Secret
Authorization
Timeout
Retry
Observability
Recovery

但它自己同樣需要：

Model Credential 管理
Tenant Authorization
Tool Timeout
Retry Budget
Token Cost Limit
Evaluation Monitoring
Artifact Retention
Backup / Recovery
Incident Response

例如 Model API 變慢：

Scanner 是否有 Deadline？
PR 是否會永久 Pending？
會不會重複呼叫並增加成本？
能否降級成 Deterministic-only Scan？

Evaluation Service 不可用：

是否阻擋所有 PR？
還是使用最後一個已核准 Baseline？
誰可以 Bypass？

Agent 發生 Prompt Injection：

如何撤銷 Credential？
如何查詢受影響 Run？
如何找出曾執行的 Tool？
如何通知 Repository Owner？

一個 Production Readiness Agent 本身也是 Production System。

它不能因為名字中有 AI，就免除相同工程要求。

從 Shadow Mode 開始

正式團隊不應第一天就把 Vibe Guard 設為：

Required Check

較安全的導入方式：

第一階段：

Shadow

Agent 執行但不阻擋。

收集：

Finding
Reviewer Label
Override
Missed Incident
Latency
Cost

第二階段：

Advisory

在 PR 顯示 Summary 與 Annotation。

團隊仍由人工決定。

第三階段：

Limited Required Gate

只阻擋：

已確認
High / Critical
Changed Line
有 passed exploit verification

第四階段：

Expanded Gate

在品質與 Baseline 穩定後，才增加：

Changed File
Reopened Finding
Production Evidence Gate
更多 Severity

即使到第四階段，也不代表 Agent 可自主接受風險或部署。

Human Review 應該看什麼？

人類 Reviewer 不需要重新閱讀所有模型推理。

應優先看到：

Finding ID / Fingerprint
Rule
Verdict
Severity
Changed Scope
Primary Source
Exploit Result
Mitigation Result
Missing Evidence
Policy Decision
Model / Tool / Rule Version

Reviewer 的操作應明確：

Confirm
Reject with reason
Request evidence
Accept risk with expiry
Assign owner
Link remediation PR

每次操作都進入 Status History。

如果 Reviewer Reject 一個 Finding，不能只刪除它。

要保存：

誰拒絕
為什麼
引用什麼證據
適用哪個 Fingerprint
何時重新評估

否則下一次 Scan 又會提出相同假警報。

成本與速度也要成為 Gate

本系列主要評估 Detection Quality。

真正產品還要量：

P50 / P95 / P99 Scan Duration
Input / Output Token
Model Cost per PR
Tool CPU / Memory
Emulator Startup Time
Cache Hit Rate
Repeated Context
Canceled Run Cost

可以採用：

Diff 先決定受影響元件
Context Selector 再向外擴張依賴
低成本模型做 Recon / Classification
高能力模型只處理高風險 Candidate
Deterministic Tool 優先處理可計算問題
相同 Revision / Rule / Tool Digest 使用 Cache

但 Cache 必須包含完整 Key：

Revision
Rule Version
Prompt Version
Model
Tool Version
Environment
Evidence Digest

不能因為 Source 相同，就重用已過期的 Production Evidence。

Google AI 在這個系列中的角色

Google AI Studio 與 Gemini 幫助我們快速建立：

Reviewer Prompt
System Instruction
Structured Response
Agent Role
Semantic Candidate
Challenge Plan

@google/genai 讓 Demo 可以把：

System Instruction
Untrusted Source
Response Schema
Temperature / Thinking Setting

轉成實際模型請求。

Firebase 提供：

Authentication
Firestore
Security Rules
Local Emulator
Hosting Context

它不只是一個儲存掃描結果的 Backend。

Firestore Rules 與 Emulator 本身也成為：

可執行的 Authorization Ground Truth

這正是 Build on Google AI 的工程價值：

模型不是獨立 Demo。
它與資料、權限、測試、CI 和正式環境證據一起工作。

AI for Engineering 的價值不只是產生更多程式碼

Vibe Coding 最直接的能力是：

縮短從想法到可執行功能的時間。

但工程工作的瓶頸不只有打字。

還包括：

理解風險
建立證據
跨領域 Review
維持一致 Policy
追蹤狀態
阻止回歸

AI for Engineering 更有價值的方向，可能不是讓 AI 多寫 20% 程式碼。

而是讓：

Security、Privacy 與 SRE 知識
更早進入每次變更。

Vibe Guard 的目標不是取代專家。

而是：

• 讓一般開發者更早看見專家會問的問題。
• 讓專家收到較完整、較可重現的證據。
• 讓重複檢查由程式執行。
• 讓真正需要判斷的部分留給人類。

最後的 Production Readiness Checklist

如果要把系列濃縮成一份可使用的檢查順序：

1. 畫出架構、Actor、Data Flow 與 Trust Boundary。
2. 區分 Authentication 與 Authorization。
3. 找出 Secret、個資、外部輸入與輸出 Sink。
4. 檢查 Dependency、Build 與 CI Supply Chain。
5. 定義 Logs、Metrics、Traces、SLO 與 Alert。
6. 對外部依賴設定 Timeout、Retry Budget 與 Idempotency。
7. 驗證 Readiness、Capacity、Backpressure 與 Degradation。
8. 實際執行 Backup、Restore、Migration 與 Rollback。
9. 將檢查項目轉成 Versioned Rule 與 Required Evidence。
10. 讓 Hunter 只提出 Candidate。
11. 讓獨立 Challenger 嘗試推翻 Candidate。
12. 優先用 Emulator、Fixture 與測試取得 Deterministic Evidence。
13. 以 Schema 保存 Verdict、Status、Verification 與 History。
14. 區分 Confirmed、Requires Evidence 與 Rejected。
15. 以 Fingerprint 比較 Base / Head 與跨 Run 狀態。
16. 將本機 CLI、PR Gate 與 Release Gate 共用同一 Contract。
17. 用 Ground Truth 計算 Precision、Recall、FPR 與 Abstention。
18. 依 Domain、Severity 與 Tool 類型切片。
19. 將 Repository、Tool Result 與 Model Output 視為不可信。
20. 使用 Least Privilege、Allowlist 與 Human Approval 限制 Agent。
21. 保存 Artifact、版本、決策者與 Evidence Digest。
22. 從 Shadow Mode 漸進導入。
23. 在 Release 後以 Canary、Monitoring 與 Incident 持續驗證。

這份清單仍不能保證：

永遠沒有事故。

它能做的是：

讓風險更早可見
讓決策更有證據
讓問題更容易重現
讓修正不容易回歸

系列最後的答案

Vibe Coding 不是問題。

真正的風險是把：

功能完成

誤認為：

Production Ready

AI 可以幫助我們更快寫出功能。

同一個 AI 也可以幫助我們：

理解架構
尋找風險
建立測試
整理證據
追蹤 Finding
進入 PR
量測自己

但前提是我們不把它當成不會犯錯的權威。

30 天後，Vibe Guard 的最後定位不是：

全自動替團隊決定能不能上線。

而是：

一位可被測試、可被限制、可被追蹤，
而且會公開自己不確定性的 AI 上線守門員。

今天的 Final Dossier 做出三個不同決定：

被測 Demo：
NO-GO

Vibe Guard：
進入 PILOT

自主 Production Approval：
DISALLOWED

這三句話就是整個系列最重要的成果。

好的 Agent 不只是會回答：

我找到了什麼？

它還必須知道：

我漏掉了什麼？
我可能錯在哪裡？
我缺少什麼證據？
我被允許做什麼？
最後應由誰負責？

從 Vibe Coding 到 Production，中間不只差一個 Deploy 按鈕。

中間需要：

架構
證據
測試
權限
評估
治理
責任

AI 可以陪我們走完這段路。

但 Production 的最後一道門，應該由：

可驗證的系統
明確的政策
負責任的人類

一起守住。

參考資料

• Google Cloud, Well-Architected Framework
• Google SRE Book, Launch Coordination Checklist
• Google SRE Book, Selected Techniques for Reliable Launches
• Google Secure AI Framework, SAIF
• Google Secure AI Framework, Focus on Agents
• Google Cloud, Gen AI evaluation service overview
• Google AI for Developers, Evaluate model and system for safety
• NIST, AI Risk Management Framework
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• OWASP, OWASP Benchmark Project
• OWASP GenAI Security Project, LLM01: Prompt Injection