AI-Native SDLC

出自jwjp-Just Wiki Join Portal
跳至導覽 跳至搜尋

1. Executive Summary & Philosophical Shift

With the deployment of advanced software engineering agents, code generation speed has accelerated exponentially, shifting the delivery bottleneck downstream to evaluation, specification gating, and deployment reviews. This framework re-architects the software engineering lifecycle to safely operationalize autonomous agents within the repository.

1.1 Legacy SDLC vs AI-Native SDLC

Dimension Legacy SDLC AI-Native SDLC
Delivery Medium Cross-team meetings, Jira tickets, manual handoffs Version-controlled markdown artifact chains
Primary Author Human engineers writing all code and tests manually AI automated generation; humans perform review & tuning
Quality Gating Manual Code Review, sequential QA testing Automated continuous evaluation (Evals) & hard hooks

2. The 6-Stage Artifact-Driven Loop

AI-Native SDLC replaces traditional ticketing handoffs with a chain of continuous, version-controlled markdown documents:

  • 1. Plan -> Artifact: intent.md
    • AI Role: Interrogates requirements dynamically to structure ambiguous business goals.
    • Human Role: Defines the high-level business intent and scope boundaries.
  • 2. Design -> Artifact: spec.md
    • AI Role: Reads project architecture context to generate compliant technical specifications.
    • Human Role: Audits architectural alignment and resolves cross-system dependencies.
  • 3. Build -> Artifact: plan.md + Code Base
    • AI Role: Plan Mode Mandate. Generates target files to alter and local validation strategies before modifying code.
    • Human Role: Approves or Rejects plan.md. AI is blocked from file modifications without explicit human unlock.
  • 4. Test -> Artifact: Automated Test Logs
    • AI Role: Autonomously writes, executes, and fixes unit/integration tests in sandboxed runtimes.
    • Human Role: Audits edge cases and defines the absolute safety baseline.
  • 5. Deploy -> Artifact: Audited Pull Request
    • AI Role: Runs automated SAST security analysis, lints, and prepares environment deployment logs.
    • Human Role: Executes final manual merge (MFA verification) as the absolute gatekeeper.
  • 6. Maintain -> Artifact: Sandboxed Diagnostics
    • AI Role: Monitors production health and auto-generates isolated fault diagnosis reports.
    • Human Role: Feedback systemic constraints to Stage 1 to prevent future regression.

3. Repository Governance Architecture (The Control Stack)

To maintain systemic stability and prevent unauthorized file modifications or security leaks, all modern repositories must enforce a three-layer boundary structure.

3.1 Base Layer (Base): CLAUDE.md Specification

This root-level configuration dictates the runtime context for the agent. AI is strictly forbidden from altering this file without a manual human commit override. 

# CLAUDE.md - Engineering Standards for Agent Session

## 1. Build & Test Infrastructure
- Build Command: npm run build or make compile
- Test Execution: pytest tests/unit/ or npm run test

## 2. Code Style & Constraints
- Language Standard: TypeScript (ES2022), Strict Null Checks enabled.
- State Management: Functional purity preferred. Side effects must be isolated in service domains.

## 3. Scar Tissue (Anti-Patterns to Avoid)
- FIX-001: Do NOT batch write to /api/v1/auth without resolving local token validation contexts.
- FIX-002: Avoid nested async blocks in repository drivers; use explicit sequential wrappers.

3.2 Specification Layer (Specification): Domain Skills

Guidelines for high-frequency or high-risk tasks defined programmatically:

  • Database Schema Migrations: AI-generated migrations must include full down (rollback) scripts.
  • API Versioning Protocol: Enforces breaking change analysis prior to altering public interfaces.

3.3 Hard Constraints Layer (Hard Constraints): Hooks

  • File Level Isolation: Git hooks (pre-commit) must intercept agent access to .env, private keys, or master configurations without explicit human Multi-Factor Authentication (MFA).
  • Command Whitelisting: Execution targets are restricted to non-destructive development commands. Destructive targets (e.g., rm -rf, raw DB drops) trigger immediate process termination.

4. Operational Transition Roadmap

The evolution follows a strict phased approach: "Control, then Acceleration, then Full Autonomy."

  1. Phase 1: Regulated Build (Weeks 1-4): Enforce mandatory CLAUDE.md and plan.md interactive gates globally to eliminate unauthorized multi-file sweeping regressions.
  2. Phase 2: Continuous Evaluation (Months 2-3): Deploy Evals (Continuous Evaluation suites) to programmatically score agent output accuracy and prevent system regression during model upgrades.
  3. Phase 3: Upstream Shift-Left (Months 4+): Integrate the entire loop from product intent (intent.md) to autonomous technical specs and real-time production self-healing.

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

取自「https://wiki.jwjp.com/index.php?title=AI-Native_SDLC&oldid=117」