AI-Native SDLC

AI-Native SDLC（AI原生軟件開發生命周期）是針對大語言模型（LLM）和Agent（智能體）時代對傳統軟件開發流程的一次重構與革新。

隨着工程智能體的普及，寫代碼（Build）的速度大幅提升，研發交付的瓶頸已全面轉移至下游的評審、攔截、安全與發布。本規範旨在將 AI 從單純的「輔助編碼工具」升級為「研發流程的自驅動核心」，人類工程師角色全面轉變為意圖定義者（Intent Definer）與最終紅線守門人（Gatekeeper）。

1. 傳統 SDLC vs AI-Native SDLC 核心對比

維度	傳統 SDLC	AI-Native SDLC
流轉介質	跨團隊會議、Jira 工單、口頭交付	具備版本控制的文檔鏈
編寫主體	人類手動編寫所有代碼與測試	AI 自動化生成，人類執行微調與審批
質量關卡	人工 Code Review、手動 QA 測試	自動化持續評測與硬攔截鈎子

2. 六階段製品驅動閉環 (The 6-Stage Loop)

AI-Native SDLC 廢除繁瑣的工單交接，轉而由一套相互耦合、可版本控制的文檔鏈驅動研發閉環：

• 1. 規劃階段 (Plan) -> 核心製品: intent.md
  • AI 職責: 動態追問人類，消除含糊語義，將原始想法提煉為結構化業務需求。
  • 人類職責: 提供核心商業意圖，劃定業務邊界。
• 2. 設計階段 (Design) -> 核心製品: spec.md
  • AI 職責: 讀取項目既有架構，自動生成符合規範的技術施工規格說明書。
  • 人類職責: 審計架構一致性，評估跨系統風險。
• 3. 構建階段 (Build) -> 核心製品: plan.md + 源碼變更
  • AI 職責: 強制進入計劃模式。在動筆修改任何代碼前，必須先輸出 plan.md，列出擬變動文件清單與本地驗證策略。
  • 人類職責: 審批或駁回 plan.md。未經人類授權，AI 禁止擅自修改任何系統文件。
• 4. 測試階段 (Test) -> 核心製品: 測試報告與覆蓋率指標
  • AI 職責: 自主編寫測試用例，在本地沙箱運行並自我修復斷言失敗。
  • 人類職責: 定義全局安全基線，抽查邊緣極端 case。
• 5. 部署階段 (Deploy) -> 核心製品: 附帶審計日誌的 Pull Request
  • AI 職責: 自動運行靜態漏洞掃描（SAST）、依賴項檢查、並自動準備發布描述。
  • 人類職責: 執行最終的合併（MFA 審批），堅守最後一關。
• 6. 維護階段 (Maintain) -> 核心製品: 沙箱診斷報告
  • AI 職責: 實時監控生產指標，故障發生時自動在隔離沙箱內跑診斷，反向生成新的 intent.md。
  • 人類職責: 審核故障歸因，將其固化為系統長期約束。

3. 倉庫治理架構：三層行為控制棧

為防止自主智能體在倉庫中出現盲目亂改文件或泄露機密，所有接入託管的項目必須實施以下三層強管制：

3.1 基礎層 (Base): CLAUDE.md 標準規範

此文件必須放置於項目根目錄下，定義 AI 在當前會話中的技術畫像。嚴禁 AI 在未經人類 Commit 覆蓋的情況下修改此文件。

# CLAUDE.md - 项目研发规范与上下文指南

## 1. 构建与测试指令 (Build & Test)
- 编译项目: npm run build 或 make compile
- 运行测试: pytest tests/unit/ 或 npm run test

## 2. 代码风格约束 (Code Style)
- 技术栈: TypeScript (ES2022), 必须开启 Strict Null Checks。
- 状态管理: 优先采用纯函数设计，副作用必须隔离在 services 层。

## 3. 历史伤疤日志 (Scar Tissue)
- FIX-001: 绝对不要在未处理 Token 局部过期上下文的情况下，批量重写 /api/v1/auth。
- FIX-002: 避免在数据库驱动中使用嵌套的 async 块，必须使用同步包装器。

3.2 規範層 (Specification): 領域技能集 (Skills)

針對高頻、高風險的細分領域任務，必須沉澱為非自由發揮的、程序化的任務描述：

• 數據庫 Schema 遷移規範: 規定 AI 生成 Migration 文件時必須包含 down（回滾）腳本。
• API 變更協議: 規定 AI 在修改對外接口時，必須先進行破壞性變更檢查（Breaking Change Detection）。

3.3 紅線層 (Hard Constraints): 系統級鈎子 (Hooks)

• 文件讀寫硬隔離: 通過 Git 鈎子（pre-commit）或系統權限，嚴禁 AI 在無人類二次認證（MFA）時讀取 .env、私鑰、或直接修改核心主幹配置。
• 命令執行白名單: 嚴格限制 AI 只能執行非破壞性的命令。任何觸發 rm -rf、drop table 等高危指令的行為將直接觸發會話強行終止。

4. 落地實施路線圖

企業流程演進應遵循「先受控、後提效、再閉環」原則，嚴禁一蹴而就：

1. 階段一：受控構建 (Weeks 1-4): 在所有核心倉庫強制推行 CLAUDE.md 模板，要求開發人員在與 Agent 配對編碼時，必須開啟「計劃模式（plan.md）」，卡住非受控的多文件胡亂修改。
2. 階段二：持續評測與規範固化 (Months 2-3): 引入 Evals（持續評測集）——針對 AI 生成的代碼或規格說明進行自動化質量打分，確保底層大模型升級時不會導致既有業務邏輯退化（Regression）。
3. 階段三：全閉環左移 (Months 4+): 徹底打通從產品意圖（intent.md）到架構設計（spec.md）的自動化轉換，並在生產環境異常時實現故障自診斷回流。

Boardline Spec7-en