AI 原生系统开发规范 v1.0

AI-Native System Development Specification

当 AI 从"工具"演变为"协作者"再到"自主执行者"，我们需要一套全新的规范来定义：系统如何被构建、如何被理解、如何被演化、以及谁在什么边界内做什么。

〇、核心理念：三个根本性转变

本规范的适用范围：

• • 所有新建系统的架构设计
• • 存量系统的 AI 适配改造
• • 人机协作流程的治理
• • AI Agent 操作边界的定义

〇.一、与传统系统构建思路的根本性差异

这不是对传统方法的"升级"或"优化"——这是一次范式断裂。如果你仍然用传统的心智模型去理解以下规范，你会觉得它们是"过度设计"。但如果你接受了"AI 能力每六个月跃迁一次"这个前提，你会发现传统方法才是真正的"设计不足"。

速查总览：十二个差异一览表

一句话概括所有差异： 传统范式假设"人是执行者"，AI 原生范式假设"AI 是执行者"——当执行者换了，整个设计语言都要重写。

以下为各差异的详细展开，可按需阅读 ↓

差异一：需求的定义方式

传统思路:  产品经理 → 写 PRD/User Story → 开发拆任务 → 逐个实现  核心逻辑: "把人类的想法翻译成机器执行的步骤"AI 原生思路:  业务专家 → 声明意图+约束+验收标准 → AI 理解并生成实现 → 人类审核方向  核心逻辑: "把人类的目标声明给 AI，AI 负责找到最优路径"

核心断裂： 传统需求是"给人看的说明书"，AI 原生需求是"给 AI 看的合约"。前者追求"人类能理解"，后者追求"机器能执行、人类能验证"。

差异二：架构设计的时间观

传统思路:  "这个架构要支撑未来 3 年的业务增长"  ──设计一次，长期使用，变更是例外AI 原生思路:  "这个架构要能在一周内接入未来 6 个月内可能出现的任何 AI 能力"  ──持续演化是常态，不变才是例外

核心断裂： 传统架构追求"做对一次"，AI 原生架构追求"错了能快速换"。在指数变化的世界里，适应力比完美度更有价值。

差异三：代码的价值观

// ═══ 传统代码 ═══// 精心设计，期望长期使用publicclassDocumentProcessor {// 500 行精心优化的文档处理逻辑// 没有人想过这段代码有一天会"不需要存在"}// ═══ AI 原生代码 ═══/** * @ai-compensating * @reason 当前模型无法一次处理超过 200K token 的文档 * @evaporation-condition model.context_window >= 2_000_000 * @evaporation-impact 移除后文档处理延迟降低 60%，代码减少 500 行 */publicclassDocumentChunker {// 明确标注：这段代码的存在是因为 AI 还不够强// 它自带"死亡日期"}

核心断裂： 传统开发者为写出优雅的代码而自豪。AI 原生开发者为删掉不再需要的代码而自豪。系统变得更简单，意味着 AI 变得更强了。

差异四：测试与质量保障思路

# 传统质量保障流程代码 → 单元测试 → 集成测试 → 人工 Review → QA 测试 → 上线      │         │           │            │      └─────────┴───── 全部由人类驱动 ────┘# AI 原生质量保障流程意图 → AI 生成代码 ──→ Layer 1: 自动化验证（AI 生成的测试）                    ──→ Layer 2: AI 交叉审查（不同模型互审）                    ──→ Layer 3: 人类抽检（基于风险评分）                    ──→ 灰度部署 → 能力探针持续评估

核心断裂： 传统 QA 问"代码写得对不对"，AI 原生 QA 问"意图被满足了没有"。验证的单位从"代码行"变成了"业务意图"。

差异五：文档与知识管理

# 传统文档"部署注意事项：先部署 service-A，再部署 service-B，因为 B 依赖 A 的新接口。另外数据库要先跑迁移脚本。"→ 写在 Confluence 某个角落，三个月后没人找得到# AI 原生知识# deploy-guide.yamldeployment_order:  - service: service-A    reason: "service-B 依赖 A 的 /api/v2/users 接口"    pre_check: "GET service-A/api/v2/users 返回 200"  - service: database-migration    reason: "service-B v2.1 需要 users 表的 email_verified 字段"    script: "migrations/202604_add_email_verified.sql"    rollback: "migrations/202604_add_email_verified_rollback.sql"  - service: service-B    depends_on: [service-A, database-migration]→ AI 可以直接解析并执行部署，人类也能一目了然

核心断裂： 传统文档是"写给人看的故事"，AI 原生知识是"写给机器执行的合约"。如果你的知识只有人类能理解，那 AI 就是一个"有能力但不知情的操作者"——这比"无能力"更危险。

差异六：权限与安全模型

# 传统权限roles:developer:can: ["read_code", "write_code", "deploy_staging"]cannot: ["deploy_production", "modify_database"]# 问题：一旦给了 deploy_staging 权限，不管他今天状态好不好、代码质量怎样# AI 原生信任ai_agent:trust_score:85# 基于历史表现动态计算current_mode:AI_LED# 信任分 71-90 对应 AI_LED 模式allowed_operations:-scale_replicas:   { trust_required:L1, constraints:"2-50, 单次±10" }-update_config:    { trust_required:L2, forbidden:"*secret*" }-database_migration: { trust_required:L3, allowed:"add_column/add_index only" }-delete_user_data:   { trust_required:L4, ai_executable:false }trust_decay:"-5 per 30 days without validation"incident_penalty: { minor:-10, major:-30, critical:-60 }# 关键：权限是"挣来的"，会衰减，出事故会坠落

核心断裂： 传统权限是"静态名牌"——你是谁决定你能做什么。AI 原生权限是"动态信用"——你做得怎么样决定你能做什么。

差异七：错误处理与事故响应

# 传统事故响应23:00 告警 → 23:15 找到 oncall → 23:30 登录服务器 → 23:45 翻日志找线索 → 00:30 定位根因 → 01:00 手动修复 → 01:30 确认恢复耗时: ~2.5 小时，下次同样的问题可能同样花 2.5 小时# AI 原生事故响应  23:00 告警 → 23:00 AI 自动分析（匹配知识图谱已知模式）→ 23:02 已知问题？  ├─ 是: AI 自动执行修复（L1 级别）→ 23:05 恢复 → 通知 oncall 确认  └─ 否: AI 提供诊断报告 → 23:05 oncall 收到报告 → 23:15 人工决策 → 23:20 修复耗时: 5 分钟（已知）/ ~20 分钟（未知），且每次事故让系统变得更智能

核心断裂： 传统事故靠"人的经验"，经验在人脑中，人离职经验就消失。AI 原生事故靠"系统的知识"，知识在知识图谱中，越用越丰富。

差异八：团队结构与角色定义

# 传统 5 人团队┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│ 产品经理 │→ │ 后端 ×2  │→ │  前端    │→ │  测试    │→ │  运维    ││ 写需求   │  │ 写代码   │  │ 写页面   │  │ 找 Bug   │  │ 部署上线 │└──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘产出: 每两周 5-8 个功能点# AI 原生 2+AI 团队┌──────────────────┐  ┌──────────────────┐│  业务/产品架构师  │  │   技术架构师      ││  定义意图和边界   │  │  设计系统和安全策略 ││  审核业务正确性   │  │  审核架构决策      │└────────┬─────────┘  └────────┬─────────┘         │                     │         ▼                     ▼┌─────────────────────────────────────────┐│           AI Agent 集群                  ││  编码 │ 测试 │ 部署 │ 监控 │ 排障       │└─────────────────────────────────────────┘产出: 每天多次迭代, 10-15 个功能点

核心断裂： 传统团队围绕"技术分工"组织——谁会什么。AI 原生团队围绕"决策层级"组织——谁决定什么。编码不再是人类的"工作"，而是 AI 的"输出"，人类的工作变成了"定方向、划边界、验结果"。

差异九：技术债务的定义

# 传统技术债的生命周期引入妥协 → 说"以后重构" → 忘记了 → 越积越多 → 系统僵化 → 推倒重来                                      ↑                                   永远停在这里# AI 原生技术债的生命周期引入补偿层 → 标注蒸发条件 → 季度评审 → AI 能力达标？                                       ├─ 是 → 移除代码，系统简化                                       └─ 否 → 下季度再评估                                       ↑                                 有明确的"还债"机制

核心断裂： 传统技术债是"承认妥协但不知何时还"。AI 原生技术债是"承认妥协并标注了精确的还款条件"。

差异十：部署与运维模式

# 传统 CI/CD Pipeline（预定义、线性、确定性）pipeline:-stage:build-stage:unit_test-stage:integration_test-stage:deploy_staging-stage:manual_approval# ← 人工审批，可能等几小时-stage:deploy_production-stage:smoke_test# 问题：每次都走同样的路径，不管变更大小# AI 原生工作流（动态、自适应、风险感知）workflow:trigger:code_changesteps:-ai_analyze_change:output:risk_score,impact_scope,suggested_test_strategy-dynamic_testing:strategy:"based on risk_score"# 高风险多测，低风险快过-deployment_decision:ifrisk_score<0.3:auto_deploy_with_canaryifrisk_score<0.7:deploy_after_ai_reviewifrisk_score>=0.7:require_human_approval-post_deploy_monitoring:ai_watches:"5 minutes"auto_rollback_if:"error_rate > 1% or latency_p99 > 2x baseline"

核心断裂： 传统 DevOps 是"人设计流程，机器执行"。AI 原生 DevOps 是"人设计边界，AI 在边界内自主编排最优路径"。

差异十一：系统生命周期观

# 传统系统生命周期代码量  ▲  │          ╱─────────────╲  ← 稳定期（代码持续膨胀）  │        ╱                 ╲  │      ╱                     ╲  ← 衰退期（无人敢改）  │    ╱                           │  ╱  ← 成长期                     └──────────────────────────────→ 时间# AI 原生系统生命周期代码量  ▲  │  ╱╲  │ ╱  ╲     ╱╲  │╱    ╲   ╱  ╲     ← 每次 AI 能力跃迁，代码量下降（蒸发）  │      ╲ ╱    ╲ ╱╲  │       ╳      ╳  ╲──  ← 核心代码趋于稳定精简  └──────────────────────────────→ 时间         ↑        ↑      蒸发评审   蒸发评审

核心断裂： 传统系统越老越臃肿，最终不得不推倒重来。AI 原生系统越"老"越精简——因为 AI 能力的每一次跃迁，都意味着一批补偿层可以被蒸发。系统的演化方向是做减法，而不是做加法。

差异十二：成功的定义

一句话总结这十二个差异：

传统系统构建的核心假设是**"人是执行者，工具是辅助"**——所以我们优化人的效率、降低工具的使用门槛。

AI 原生系统构建的核心假设是**"AI 是执行者，人是决策者"**——所以我们优化 AI 的操作环境、强化人的判断力和边界设计能力。

当执行者换了，整个系统的设计语言都要重写。

一、意图声明层（Intent Declaration Layer）

1.1 设计哲学

传统开发从"需求文档"出发，经过拆解、设计、编码、测试的瀑布/敏捷流程。AI 原生开发从**"意图声明"**出发——你不再描述"怎么做"，而是声明"要达到什么状态"。

核心原则：声明式优于命令式，意图优于实现。

1.2 意图声明文件规范（.intent.yaml）

每个系统/模块必须拥有一个意图声明文件，作为系统的"灵魂文档"。

# system.intent.yaml — 系统意图声明apiVersion:intent/v1kind:SystemIntentmetadata:name:order-serviceowner:commerce-teamcreated:2026-04-19last_reviewed:2026-04-19# 【强制】每季度至少审查一次# ── 第一层：业务意图 ──intent:purpose:"处理用户的商品购买请求，确保交易的完整性和可追溯性"success_criteria:-"订单创建到支付确认的端到端延迟 < 3秒（P99）"-"订单数据零丢失，最终一致性窗口 < 30秒"-"支持 10,000 QPS 的峰值处理能力"business_constraints:-"必须符合支付行业 PCI-DSS 合规要求"-"用户个人信息必须加密存储"# ── 第二层：能力需求（而非技术方案）──capabilities_required:-name:persistent_storageintent:"可靠地持久化订单数据"consistency:eventual# 声明一致性需求，而非指定具体数据库durability:"RPO=0, RTO<5min"-name:async_messagingintent:"解耦订单创建与后续处理（库存扣减、通知等）"delivery_guarantee:at_least_onceordering:per_partition# 同一用户的订单保序-name:cache_layerintent:"加速商品信息和库存的读取"staleness_tolerance:"5s"# 可接受5秒的数据陈旧# ── 第三层：演化声明 ──evolution:current_phase:"human_led_ai_assisted"# 当前处于人类主导、AI辅助阶段next_phase:"ai_led_human_supervised"# 下一阶段目标transition_conditions:-"AI 代码审查准确率 > 98%"-"自动化测试覆盖率 > 90%"-"AI 生成代码的生产事故率 < 0.1%"# 明确哪些设计决策可能在未来过时assumptions_with_expiry:-assumption:"需要手动拆分长文本给 AI 处理"expiry_condition:"模型上下文窗口 > 2M tokens"impact:"可移除 TextChunkingService 整个模块"-assumption:"AI 生成的 SQL 需要人工审核"expiry_condition:"AI SQL 安全审计通过率 > 99.9%"impact:"可开放 AI 直接执行只读查询"

1.3 意图声明的层级结构

组织意图（Organization Intent）  └── 产品意图（Product Intent）        └── 系统意图（System Intent）              └── 模块意图（Module Intent）                    └── 接口意图（Interface Intent）

每一层都回答三个问题：

1. 1. 为什么存在？（Purpose）
2. 2. 什么算成功？（Success Criteria）
3. 3. 什么时候该被替换？（Evaporation Conditions）

1.4 需求表达规范

【废止】 传统的"作为XX用户，我希望XX，以便XX"的 User Story 格式。

【采用】 意图-约束-验证三元结构：

# feature.intent.yamlfeature:name:"智能退款处理"intent:|    当用户发起退款请求时，系统应该自动评估退款合理性，    对于明确合理的退款（如未发货订单）自动处理，    对于需要判断的退款升级到人工审核。constraints:-"自动退款金额单笔不超过 500 元"-"同一用户 24 小时内自动退款不超过 3 次"-"涉及已发货订单的退款必须人工介入"verification:automated:-"模拟 1000 笔退款场景，验证自动/人工分流准确率 > 99%"-"验证超限场景的拦截率 = 100%"human:-"业务方审核自动退款的规则是否符合退款政策"-"抽查 50 笔自动退款的合理性"ai_generation_hints:architecture_style:"event-driven"similar_patterns: ["支付风控模块", "订单状态机"]anti_patterns: ["不要用同步阻塞式调用", "不要硬编码退款规则"]

二、能力边界协议（Capability Boundary Protocol）

2.1 设计哲学

在 AI 能力持续增强的世界中，最危险的不是 AI 能力不足，而是边界模糊。每个系统、每个操作都需要一个清晰的、动态的、可机器读取的能力边界声明。

核心原则：明确的边界不是对 AI 的限制，而是 AI 安全自主运行的轨道。

2.2 操作边界声明规范（.boundary.yaml）

# order-service.boundary.yamlapiVersion:boundary/v1kind:OperationBoundarymetadata:service:order-serviceversion:"2.3.0"last_updated:2026-04-19reviewed_by: ["architect-wang", "sre-lead-li"]# ── 信任等级定义 ──trust_levels:L0_readonly:description:"只读访问，零变更风险"auto_approve:trueL1_reversible:description:"可逆变更，可快速回滚"auto_approve:truerequires: [rollback_plan, health_check]L2_significant:description:"重要变更，需确认后执行"auto_approve:falserequires: [impact_analysis, rollback_plan, canary_validation]approval: [tech_lead]L3_critical:description:"关键变更，需多方审批"auto_approve:falserequires: [impact_analysis, rollback_plan, full_regression, data_backup]approval: [tech_lead, sre_lead, business_owner]L4_forbidden:description:"禁止 AI 执行，仅人工操作"auto_approve:falseai_executable:false# ── 操作清单 ──operations:# === 基础设施操作 ===-name:scale_replicasdescription:"调整服务实例数量"trust_level:L1_reversibleconstraints:min_replicas:2max_replicas:50max_change_per_operation:10# 单次最多增减10个实例rollback:"kubectl scale --replicas={previous_count}"-name:update_configdescription:"更新运行时配置"trust_level:L2_significantconstraints:allowed_keys: ["thread_pool_size", "cache_ttl", "rate_limit"]forbidden_keys: ["db_connection_string", "encryption_key", "*secret*"]validation:"config diff + canary deployment for 10 minutes"-name:database_migrationdescription:"数据库 Schema 变更"trust_level:L3_criticalconstraints:allowed: ["add_column", "add_index", "create_table"]forbidden: ["drop_table", "drop_column", "modify_column_type"]pre_conditions:-"备份已完成且可恢复性已验证"-"变更脚本已在 staging 环境验证"-name:delete_user_datadescription:"删除用户数据"trust_level:L4_forbiddenreason:"涉及数据合规，必须由有权限的人工操作员执行"# ── 紧急情况覆盖规则 ──emergency_override:conditions:-"系统可用性 < 99% 持续超过 5 分钟"-"错误率 > 10% 持续超过 2 分钟"elevated_permissions:-operation:scale_replicastemporary_trust_level:L0_readonly# 紧急情况下自动扩容无需审批max_duration:"30m"-operation:rollback_deploymenttemporary_trust_level:L1_reversiblemax_duration:"15m"notification: ["oncall_engineer", "sre_lead"]audit:mandatory

2.3 能力探针规范（Capability Probe）

系统应该内置持续评估 AI 能力的探针机制，在检测到能力跃迁时自动或半自动调整操作边界：

# capability-probes.yamlapiVersion:probe/v1kind:CapabilityProbeSetprobes:-name:code_review_accuracydescription:"评估 AI 代码审查是否足够可靠以减少人工审查"schedule:"weekly"method:type:shadow_evaluationdetails:|        在 AI 代码审查与人工审查并行运行时：        1. 收集 AI 审查与人工审查的差异        2. 由高级工程师判定每个差异点的正确方        3. 计算 AI 的准确率、召回率current_threshold:accuracy:92%recall:88%graduation_threshold:accuracy:98%recall:95%graduation_action:-"将 code_review 操作从 L2_significant 降级为 L1_reversible"-"人工审查从全量改为抽查（20%）"-name:incident_diagnosis_qualitydescription:"评估 AI 是否能可靠地诊断生产事故"schedule:"monthly"method:type:retrospective_analysisdetails:|        对过去一个月的生产事故：        1. 让 AI 在不知道结果的情况下诊断        2. 对比 AI 诊断与实际根因        3. 评估诊断准确率和建议可行性current_threshold:root_cause_accuracy:75%graduation_threshold:root_cause_accuracy:95%graduation_action:-"开启 AI 自动诊断 + 建议修复方案的流程"-"L1 级别的常见问题允许 AI 自动修复"-name:context_window_capacitydescription:"检测模型能否处理完整代码库理解"schedule:"on_model_update"method:type:benchmarkdetails:|        1. 提交整个服务代码（不做切割）        2. 提出 10 个需要全局理解的问题        3. 评估回答的准确性和完整性current_threshold:full_codebase_understanding:70%graduation_threshold:full_codebase_understanding:95%graduation_action:-"移除 CodeChunkingService"-"启用单次全量代码审查模式"

2.4 边界演化原则

1. 1. 数据驱动放宽：边界放宽只能通过探针数据驱动，不能因主观判断放宽
2. 2. 随时可收紧：任何放宽的边界，必须有一键收紧的机制。放宽需要数据证明，收紧无需理由——安全优先
3. 3. 双重验证：边界变更需要技术验证（探针数据）+ 业务确认（风险评估）
4. 4. 透明审计：所有边界变更都记录到不可篡改的审计日志

三、可蒸发架构规范（Evaporable Architecture Standard）

3.1 设计哲学

在 AI 能力指数增长的世界中，今天为弥补"AI 还不够好"而引入的每一层架构，都应该被视为临时妥协而非永久资产。系统的持久价值在于其核心领域逻辑，而非围绕 AI 局限性构建的补偿层。

核心原则：每一个非核心模块都应该自带消亡条件。

3.2 代码注解规范

所有因 AI 能力限制而引入的代码，必须使用以下注解标记：

/** * @ai-compensating * @reason AI 当前无法可靠地直接输出符合业务规则的结构化 JSON * @evaporation-condition model.structured_output_reliability >= 99.5% * @evaporation-impact 移除此解析层后，响应延迟降低约 200ms * @added 2026-04-19 * @last-evaluated 2026-04-19 */publicclassAIOutputParser {// 解析和校验 AI 的非结构化输出}

# @ai-compensating# @reason AI 上下文窗口不足以处理完整文档# @evaporation-condition model.context_window >= 2_000_000# @evaporation-impact 移除后可简化整个文档处理 pipelineclassDocumentChunker:"""将长文档切割为 AI 可处理的片段"""pass

/** * @ai-compensating * @reason AI 生成的 SQL 存在注入风险，需要二次校验 * @evaporation-condition ai_sql_injection_detection_rate >= 99.99% * @evaporation-impact 移除后可实现 AI 直接查询数据库 */classSQLSanitizer {sanitize(aiGeneratedSQL: string): SafeSQL { ... }}

3.3 架构层级分类

系统中的每一层/模块必须被归类为以下类型之一：

┌─────────────────────────────────────────────┐│            Compensating Layer               │  ← 可蒸发：AI 能力补偿│  ┌───────────────────────────────────────┐   ││  │          Adaptive Layer               │   │  ← 可替换：连接与适配│  │  ┌───────────────────────────────┐    │   ││  │  │        Core Layer             │    │   │  ← 持久：业务领域本质│  │  │   (Domain Logic / Rules)      │    │   ││  │  └───────────────────────────────┘    │   ││  └───────────────────────────────────────┘   │└─────────────────────────────────────────────┘

关键规则：

• • Core 层禁止直接依赖任何 AI 能力假设
• • Compensating 层的代码量分级管控：> 30% 为红线（过度投资）；< 15% 为健康（成熟度 L3+）；< 10% 为优秀（成熟度 L4 目标）
• • 每个 Compensating 模块必须有对应的直通路径（bypass path），当 AI 能力达标时可直接旁路

3.4 蒸发评审流程

每季度必须执行一次"蒸发评审"（Evaporation Review）：

1. 1. 扫描所有 @ai-compensating 标注的代码
2. 2. 对每个标注评估当前 AI 能力是否已达到蒸发条件
3. 3. 已达标的 → 启用直通路径（bypass），将旧代码移入 archive/evaporated/ 目录备用，不物理删除
4. 4. 未达标但接近的 → 标记为"即将蒸发"，准备直通路径
5. 5. 远未达标的 → 保持，更新评估日期

注意： "蒸发"不等于"删除"。蒸发的代码通过配置开关旁路，并归档保留。这确保在 AI 能力回退时可以快速恢复（参见反模式八）。

蒸发评审报告模板：

## 蒸发评审报告 — 2026 Q2| 模块 | 蒸发条件 | 当前状态 | 行动 ||------|---------|---------|------|| AIOutputParser | 结构化输出 ≥ 99.5% | 当前 99.2% ✅ 接近 | 下季度移除，准备直通路径 || DocumentChunker | 上下文窗口 ≥ 2M | 当前 1M ⏳ 进行中 | 保持，关注模型更新 || SQLSanitizer | SQL 安全率 ≥ 99.99% | 当前 98.5% ❌ 未达 | 保持，继续评估 || ManualTaskRouter | Agent 自主规划 ≥ 95% | 当前 97% ✅ 达标 | 立即移除，本月完成 |**本季度蒸发收益：**- 移除代码：~2,400 行- 降低延迟：~350ms（端到端）- 简化依赖：移除 2 个中间件

四、知识工程规范（Knowledge Engineering Standard）

4.1 设计哲学

当 AI 成为系统的"操作者"和"维护者"之一，系统的知识体系必须从"面向人类阅读"转变为"面向人机双重消费"。

核心原则：如果一条知识只有人类能理解，那它就是 AI 的操作盲区。

4.2 架构决策记录（ADR）增强规范

每个重要的架构决策必须以增强版 ADR 格式记录：

# adr/ADR-042-eventual-consistency.yamlapiVersion:adr/v1kind:ArchitectureDecisionRecordmetadata:id:ADR-042title:"订单服务使用最终一致性而非强一致性"status:accepted# proposed | accepted | deprecated | supersededdate:2024-11-15authors: ["wang-xiaojie"]supersedes:nullsuperseded_by:null# ── 人类可读部分 ──context:|  2024年双十一期间，强一致性方案导致数据库锁等待超时，  峰值 QPS 仅能达到预期的 30%，直接影响了业务营收。decision:|  改用消息队列 + 补偿事务实现最终一致性模型。  选择 RocketMQ 作为消息中间件（团队熟悉度最高）。consequences:positive:-"吞吐量提升 10 倍"-"系统解耦，各模块可独立扩缩容"negative:-"需要处理约 0.01% 的不一致场景"-"问题排查链路变长"# ── AI 可读/可执行部分 ──ai_context:invariants:# 不可违反的不变量-"绝对不能将异步调用改为同步调用"-"补偿任务必须是幂等的"-"消息消费失败后必须进入死信队列，而非丢弃"operation_boundary:allowed:-action:"调整 RocketMQ 消费者并发数"constraint:"2 ≤ concurrency ≤ 64"-action:"调整消息重试次数"constraint:"3 ≤ retries ≤ 10"-action:"添加新的消息消费者"constraint:"必须实现幂等性接口"forbidden:-action:"修改事务模型"reason:"需要全面的业务影响评估"-action:"修改消息路由逻辑"reason:"可能导致消息丢失或重复"-action:"删除死信队列中的消息"reason:"死信消息是排查问题的重要依据"related_incidents:-id:INC-2024-1115summary:"双十一锁等待超时事故"lesson:"即使在低流量测试中强一致性看起来没问题，峰值压力下也会崩溃"-id:INC-2025-0312summary:"补偿任务非幂等导致重复扣款"lesson:"所有补偿操作必须带业务幂等键"# 决策的"保质期"——什么时候应该重新评估review_triggers:-"数据库技术发生代际更新（如支持分布式事务无锁方案）"-"消息中间件更换"-"业务一致性要求从'最终一致'提升为'强一致'"

4.3 系统知识图谱规范

每个系统必须维护一份机器可读的知识图谱：

# knowledge-graph/order-service.graph.yamlapiVersion:knowledge/v1kind:SystemKnowledgeGraphnodes:-id:order-servicetype:serviceintent:"处理用户下单请求"tech_stack: ["Java 21", "Spring Boot 3.x", "MySQL 8.0"]team:commerce-team-id:inventory-servicetype:serviceintent:"管理商品库存"tech_stack: ["Go 1.22", "Redis", "PostgreSQL"]team:supply-chain-team-id:payment-gatewaytype:external_dependencyintent:"处理支付交易"sla:"99.95% 可用性"degradation_impact:"用户无法完成支付，但可以创建待支付订单"edges:-from:order-serviceto:inventory-servicetype:async_dependencyprotocol:rocketmqtopic:"inventory-deduct"failure_handling:"重试 3 次后进入死信队列，人工处理"-from:order-serviceto:payment-gatewaytype:sync_dependencyprotocol:httpstimeout:5scircuit_breaker:truefallback:"返回'支付处理中'，异步轮询支付结果"# AI 排障指引troubleshooting_guide:symptoms:-symptom:"订单创建成功但库存未扣减"probable_causes:-cause:"RocketMQ 消息积压"check:"GET /internal/diag/mq-lag"fix_action:"增加消费者并发数"trust_level:L1_reversible-cause:"inventory-service 异常"check:"GET inventory-service/health"fix_action:"通知 supply-chain-team"trust_level:L0_readonly-symptom:"订单列表查询缓慢（>2s）"probable_causes:-cause:"MySQL 慢查询"check:"GET /internal/diag/slow-queries"fix_action:"分析并添加索引（需 L3 审批）"trust_level:L3_critical-cause:"Redis 缓存击穿"check:"GET /internal/diag/cache-hit-rate"fix_action:"调整 cache TTL 或开启热点key保护"trust_level:L2_significant

4.4 隐性知识显性化清单

以下类型的隐性知识必须被结构化记录：

五、人机协作治理模型（Human-AI Governance Model）

5.1 设计哲学

AI 不是"工具"也不是"人"，它是第三种协作实体。人机协作需要一种全新的治理模型：既不像管理工具那样刚性，也不像管理人类那样依赖信任——而是基于验证驱动的渐进式授权。

核心原则：AI 的权限不是被授予的，而是被验证出来的。

5.2 协作模式分级

# governance/collaboration-modes.yamlapiVersion:governance/v1kind:CollaborationModelmodes:# ── 模式一：AI 辅助，人类执行 ──-name:AI_ASSISTEDdescription:"AI 提供建议和草稿，人类做所有决策和执行"applicable_when:-"新领域/新系统，AI 缺乏上下文"-"涉及安全关键、资金关键操作"-"前期信任建立阶段"ai_responsibilities:-"代码生成草稿"-"技术方案建议"-"日志分析和告警解读"human_responsibilities:-"所有决策"-"所有生产环境操作"-"代码审查和修改"# ── 模式二：AI 主导，人类审核 ──-name:AI_LEDdescription:"AI 独立完成工作，人类审核关键节点"applicable_when:-"AI 在该领域的探针评分 > 95%"-"存在完善的自动化测试覆盖"-"有可靠的回滚机制"ai_responsibilities:-"独立完成编码和测试"-"自动化部署到 staging"-"性能和安全检测"human_responsibilities:-"审查架构设计决策"-"批准生产环境部署"-"处理探针未覆盖的异常场景"review_sampling_rate:20%# 人工抽检 20% 的 AI 输出# ── 模式三：AI 自主，人类监督 ──-name:AI_AUTONOMOUSdescription:"AI 全自主运行，人类只在异常时介入"applicable_when:-"AI 在该领域的探针评分 > 99%"-"该操作的风险等级 ≤ L1"-"已有 ≥ 3 个月的 AI_LED 模式无事故运行记录"ai_responsibilities:-"端到端的开发-测试-部署流程"-"自动扩缩容和性能优化"-"常见事故的自动诊断和修复"human_responsibilities:-"设定目标和约束"-"审查月度运行报告"-"处理 L2+ 级别的事件"circuit_breaker:trigger:"连续 3 次操作异常 或 影响用户数 > 1%"action:"自动降级到 AI_LED 模式，通知oncall"

5.3 AI 操作审计规范

所有 AI 操作必须产生审计记录，格式如下：

{"audit_version":"1.0","timestamp":"2026-04-19T18:30:00+08:00","agent_id":"deploy-agent-prod-01","model":"claude-4.6-opus","operation":{"type":"scale_replicas","target":"order-service","parameters":{"from_replicas":5,"to_replicas":15},"trust_level":"L1_reversible"},"context":{"trigger":"auto:cpu_usage_above_80_percent_for_5min","boundary_reference":"order-service.boundary.yaml#scale_replicas","intent_reference":"order-service.intent.yaml#success_criteria[2]"},"reasoning":{"observation":"order-service CPU usage at 85% for 7 minutes, QPS trending up","analysis":"Current 5 replicas handling 8000 QPS, projected peak 15000 QPS in 30min","decision":"Scale to 15 replicas to maintain headroom (10000 QPS target per criteria)","alternatives_considered":[{"option":"Scale to 10","rejected_reason":"Insufficient headroom for projected peak"},{"option":"Enable rate limiting","rejected_reason":"Would degrade user experience"}]},"verification":{"pre_check":"All health endpoints returning 200","post_check":"CPU usage dropped to 45%, P99 latency < 1s","rollback_available":true,"rollback_command":"kubectl scale deployment order-service --replicas=5"},"outcome":"success","human_notification":{"sent_to":["oncall-engineer"],"acknowledged":true,"acknowledged_at":"2026-04-19T18:35:00+08:00"}}

5.4 人工熔断机制

每个生产系统必须实现以下熔断能力：

# governance/circuit-breaker.yamlcircuit_breaker:# 一键停止所有 AI 操作global_kill_switch:endpoint:"POST /admin/ai/emergency-stop"effect:"立即停止所有 AI Agent 的写操作，切换到只读模式"authorization:"任何 oncall 工程师"notification:"全量通知 SRE 团队"# 按服务停止service_level:endpoint:"POST /admin/ai/pause/{service}"effect:"暂停指定服务的 AI 操作"# 自动触发条件auto_triggers:-condition:"AI 操作导致的错误率 > 5%（5分钟窗口）"action:pause_and_notify-condition:"AI 操作导致的 P99 延迟增长 > 200%"action:pause_and_notify-condition:"同一操作连续失败 3 次"action:block_operation_and_notify-condition:"AI 尝试执行 L4_forbidden 操作"action:alert_security_team

六、验证与信任体系（Verification & Trust Framework）

6.1 设计哲学

当 AI 的产出量级超越人类逐一审查的能力，"人工 Review 每一行代码"不再是可行策略。我们需要构建**"AI 检查 AI + 人类抽检 + 自动化验证"的三层验证体系**。

核心原则：信任不是默认值，而是通过验证积累的资产。

6.2 三层验证体系

┌──────────────────────────────────────────────────┐│              Layer 3: 人类抽检                     ││  ● 架构决策审查（100%）                             ││  ● 安全关键代码审查（100%）                          ││  ● 常规代码抽检（10-20%，基于风险评分）                │├──────────────────────────────────────────────────┤│              Layer 2: AI 交叉验证                   ││  ● 使用不同模型交叉审查 AI 生成的代码                  ││  ● 自动化安全扫描（SAST/DAST）                      ││  ● 业务逻辑一致性校验                                │├──────────────────────────────────────────────────┤│              Layer 1: 自动化验证                    ││  ● 单元测试 + 集成测试（覆盖率 > 90%）               ││  ● 契约测试（API 兼容性）                            ││  ● 性能基线回归测试                                  ││  ● 混沌工程测试                                     │└──────────────────────────────────────────────────┘

6.3 AI 信任评分模型

# trust/ai-trust-score.yamlapiVersion:trust/v1kind:TrustScoreModeldimensions:-name:accuracyweight:0.30description:"AI 输出的正确率"measurement:"AI 生成的代码通过所有测试的比率"-name:safetyweight:0.30description:"AI 操作的安全性"measurement:"AI 操作未触发安全事件的比率"-name:consistencyweight:0.20description:"AI 行为的一致性和可预测性"measurement:"相同输入产生等价输出的比率"-name:boundary_complianceweight:0.20description:"AI 遵守操作边界的合规度"measurement:"AI 操作在声明边界内的比率"trust_score_thresholds:-range:"0-70"mode:AI_ASSISTEDdescription:"AI 仅提供建议，人类执行一切"-range:"71-90"mode:AI_LEDdescription:"AI 主导执行，人类审核关键点（需探针 > 95%）"-range:"91-96"mode:AI_AUTONOMOUS_LIMITEDdescription:"AI 自主执行 L0-L1 操作（需探针 > 99%）"-range:"97-100"mode:AI_AUTONOMOUS_EXTENDEDdescription:"AI 自主执行 L0-L2 操作，人类监督"# 信任衰减规则trust_decay:no_data_decay:"每 30 天无新验证数据，信任分 -5"incident_penalty:minor:-10# 小事故：回滚即可恢复major:-30# 重大事故：影响用户critical:-60# 严重事故：数据丢失或安全事件recovery:rate:"+2 per week of clean operation"max_recovery:"不超过事故前水平，除非通过额外验证"

6.4 验证策略决策树

AI 生成了一份代码/变更        │        ▼   风险等级评估   ┌────┴────┐   │         │ 低风险    高风险   │         │   ▼         ▼Layer 1     Layer 1 + Layer 2自动验证    自动验证 + AI 交叉审查   │         │   ▼         ▼ 通过？     通过？ ┌─┴─┐    ┌──┴──┐ Y   N    Y     N │   │    │     │ │   ▼    ▼     ▼ │  修复  Layer 3  Layer 3 │       人工抽检  人工全审 ▼       (20%)   (100%)部署        │           ▼         部署/拒绝

七、系统演化协议（Evolution Protocol）

7.1 设计哲学

系统不是"一次性构建完成"的，而是"持续演化"的生命体。在 AI 能力指数增长的环境中，系统的演化速度必须跟上能力的增长速度——否则基础设施本身就成了 AI 能力的瓶颈。

核心原则：系统的价值不在于它今天能做什么，而在于它能以多快的速度适应明天的能力。

7.2 演化阶段模型

Phase 0: TRADITIONAL（传统模式）   ↓ 触发条件：AI 可辅助完成 > 30% 的编码工作Phase 1: AI_ASSISTED（AI 辅助）   ↓ 触发条件：AI 探针评分 > 95%，信任分 > 85，无重大事故 > 3个月Phase 2: AI_LED（AI 主导）   ↓ 触发条件：AI 探针评分 > 99%，信任分 > 96Phase 3: AI_AUTONOMOUS（AI 自主）   ↓ 触发条件：全维度探针 > 99%，信任分 > 96，持续 6 个月+Phase 4: AI_NATIVE（AI 原生）   └── 系统由 AI 持续优化和演化，人类设定目标和边界

7.3 演化日志规范

# evolution-log.yamlapiVersion:evolution/v1kind:EvolutionLogentries:-date:2026-04-19event:"code_review phase transition"from:AI_ASSISTEDto:AI_LEDevidence:-"AI 代码审查准确率连续 3 个月 > 98%"-"0 起因 AI 审查遗漏导致的生产事故"-"人工审查团队一致同意降低审查比例"changes:-"人工代码审查从 100% 降为 20% 抽检"-"AI 代码审查结果直接作为合入依据"reversibility:"可随时通过 CI 配置恢复全量人工审查"-date:2026-07-01event:"DocumentChunker evaporation"type:architecture_simplificationevidence:-"Claude 5.0 发布，上下文窗口达到 4M tokens"-"能力探针显示全量文档理解准确率 99.3%"changes:-"移除 DocumentChunker 模块（1,200 行代码）"-"文档处理延迟降低 40%"-"移除 Redis 中间缓存依赖"impact:"端到端性能提升，架构简化"

7.4 半年度系统健康审计

【强制】 每半年执行一次全面的系统演化健康审计：

## 半年度系统演化审计 — 2026 H1### 1. 能力追踪| AI 能力维度 | 半年前 | 现在 | 变化 | 系统适配状态 ||------------|--------|------|------|------------|| 上下文窗口 | 1M tokens | 4M tokens | +300% | ✅ 已移除文档切割 || 代码审查准确率 | 92% | 98.5% | +7% | ✅ 已切换到 AI_LED || 自主部署可靠性 | 85% | 93% | +8% | ⏳ 接近 AI_LED 阈值 || SQL 安全性 | 95% | 98.5% | +3.7% | ❌ 尚未达标，保持人工审核 |### 2. 蒸发统计- 本周期蒸发模块数：3- 蒸发代码行数：4,200- 蒸发带来的延迟降低：~600ms- 仍存在的 Compensating 层：5 个模块- 预计下期可蒸发：2 个模块### 3. 边界变更记录- L2→L1 降级操作：2 项- L3→L2 降级操作：0 项- 新增 L4 禁止操作：1 项（新增数据合规要求）### 4. 风险评估- 主要风险：AI 生成的测试代码存在 happy path 偏向- 缓解措施：引入变异测试（mutation testing）评估测试有效性- 下期关注：新模型可能改变 SQL 生成行为，需重新评估 SQL 边界### 5. 人才与组织适配- 团队 AI 工具使用率：85%（目标 90%）- AI 主导的代码行占比：65%（上期 45%）- 工程师角色转变进度：3/5 人已完成"AI 编排师"技能培训

八、接口与服务设计规范

8.1 AI-First API 设计原则

API 设计必须同时考虑人类和 AI 消费者：

# api-design-principles.yamlprinciples:-name:"语义化端点"description:"API 端点命名应传达业务意图，而不仅仅是 CRUD 操作"example:bad:"POST /api/orders/{id}/status"good:"POST /api/orders/{id}/confirm-payment"reason:"AI 可以从端点名理解操作意图，减少误用"-name:"自描述响应"description:"API 响应应包含足够的元数据，AI 可以据此决定下一步"example:|      // ❌ 缺少上下文      { "status": "error", "code": 429 }//✅自描述      {"status":"error","code":429,"intent":"rate_limited","retry_after_seconds":30,"current_rate":"150/min","limit":"100/min","suggestion":"Consider batching requests or implementing backoff"      }-name:"可发现性"description:"AI 可以通过 API 自身发现其能力"implementation:-"所有服务暴露 /.well-known/ai-capabilities 端点"-"返回该服务支持的操作、约束、权限要求"-name:"幂等性优先"description:"所有写操作默认支持幂等性"reason:"AI 重试操作时不会产生副作用"implementation:"所有 POST/PUT 请求必须接受 Idempotency-Key header"

8.2 AI 能力发现端点

每个服务必须暴露以下端点：

# /.well-known/ai-capabilitiesservice:order-serviceversion:"2.3.0"capabilities:-name:create_ordermethod:POSTpath:/api/orderstrust_level_required:L2_significantdescription:"创建新订单"parameters:required: ["user_id", "items", "payment_method"]optional: ["coupon_code", "delivery_note"]constraints:-"单笔订单金额不超过 50,000 元"-"同一用户每分钟最多创建 5 笔订单"side_effects:-"库存预扣减（异步，最终一致）"-"支付预授权"rollback_available:true-name:query_order_statusmethod:GETpath:/api/orders/{id}trust_level_required:L0_readonlydescription:"查询订单状态"caching:"结果缓存 5 秒"diagnostics:-name:healthpath:/internal/healthdescription:"服务健康状态"-name:slow_queriespath:/internal/diag/slow-queriesdescription:"最近 5 分钟的慢查询"trust_level_required:L0_readonly-name:connection_poolpath:/internal/diag/conn-pooldescription:"连接池使用情况"trust_level_required:L0_readonly

九、规范落地路线图

Phase 1：基础建设（第 1-2 个月）

• • 为所有核心系统编写 system.intent.yaml
• • 为关键操作定义 boundary.yaml
• • 梳理并结构化前 10 个最重要的 ADR
• • 统一日志/指标格式为 OpenTelemetry 标准
• • 实现全局 AI 熔断开关

Phase 2：知识工程（第 2-4 个月）

• • 标注所有 @ai-compensating 代码
• • 构建核心系统的知识图谱
• • 编写 AI 可理解的 Runbook
• • 暴露所有服务的 /.well-known/ai-capabilities 端点
• • 实施首轮蒸发评审

Phase 3：协作模式（第 4-6 个月）

• • 部署能力探针并收集基线数据
• • 在非关键系统试点 AI_LED 模式
• • 建立三层验证体系
• • 实现 AI 操作审计日志
• • 培训团队"AI 编排师"技能

Phase 4：持续演化（第 6 个月起）

• • 建立半年度系统演化审计机制
• • 根据探针数据动态调整操作边界
• • 在关键系统推广 AI_LED 模式
• • 评估并试点 AI_AUTONOMOUS 模式
• • 持续优化信任评分模型

十、反模式清单（Anti-Patterns）

规范告诉你"该怎么做"，反模式告诉你"千万别怎么做"。以下是 AI 原生系统建设中最常见、最危险的陷阱。

反模式速查表

❌ 反模式一："全交给 AI"

表现： 因为 AI 能力很强，就把所有决策和执行权一次性交给 AI，跳过信任建立过程。

后果： AI 在缺乏上下文的情况下做出看似合理但实际灾难性的决策（如自动删除了"看起来没用"的索引，导致查询性能崩溃）。

正确做法： 遵循渐进式信任模型，从 AI_ASSISTED → AI_LED → AI_AUTONOMOUS 逐步升级，每一步都需要探针数据支撑。

❌ Day 1: "AI 很强了，让它自己管理生产环境吧"✅ Day 1: AI 只读监控 → Month 1: AI 建议+人执行 → Month 3: AI 执行 L1+人审 → Month 6: 评估 L2

❌ 反模式二："精雕补偿层"

表现： 在明知是 AI 能力补偿的模块上投入大量精力做性能优化、设计模式改进。

后果： 三个月后 AI 能力达标，精心打磨的代码被整体删除。工程投入归零。

正确做法： 补偿层应遵循"刚好够用"原则，标注 @ai-compensating，投入最小化。

❌ 花两周优化 DocumentChunker 的切割算法，性能提升 30%✅ 用最简单的方式实现切割，标注蒸发条件，把省下的两周用在核心业务逻辑上

❌ 反模式三："无边界自由"

表现： 部署了 AI Agent 但没有定义操作边界（.boundary.yaml），AI 能访问和操作任何资源。

后果： AI 在"善意"的逻辑下执行了危险操作——比如为了"优化性能"修改了数据库索引策略，导致写入性能暴跌。

正确做法： 每个系统上线 AI 操作前，必须先定义 boundary.yaml，明确 L0-L4 操作清单。没有边界声明 = 禁止 AI 操作。

❌ 反模式四："文档补课式知识工程"

表现： 想一次性把所有隐性知识都结构化，启动了一个大型"知识梳理项目"。

后果： 项目持续三个月，产出了大量文档，但很快过时。团队疲惫且抵触。

正确做法： 知识工程应该是流式的，嵌入到日常工作中：

• • 每次事故后 → 更新 troubleshooting_guide
• • 每次架构决策时 → 写增强版 ADR
• • 每次代码审查时 → 补充 @do-not-modify 注解
• • 不搞运动式补课，而是渐进式积累

❌ 反模式五："AI 原生洁癖"

表现： 强制要求所有系统立刻按照 AI 原生规范改造，拒绝任何不符合新规范的代码合入。

后果： 团队抵触、开发速度骤降、业务需求积压。完美主义杀死了本应渐进的转型。

正确做法： 存量系统和新建系统采用不同策略：

• • 新建系统：完整遵循本规范
• • 存量系统：按优先级渐进改造（先加 .intent.yaml 和 .boundary.yaml，再逐步标注补偿层）
• • 过渡期：允许"混合态"存在，用成熟度模型追踪进度

❌ 反模式六："用 AI 验证 AI，无人兜底"

表现： 三层验证体系中完全取消了 Layer 3（人类抽检），认为 AI 交叉验证已经足够可靠。

后果： 两个 AI 模型犯了相同类型的系统性错误（如都忽略了某个边界条件），无人发现，直到生产事故。

正确做法： Layer 3 的人类抽检永远不能降为 0%。可以从 20% 降到 5%，但必须保留，尤其是在安全关键和资金关键路径上保持 100%。

❌ 反模式七："探针形式主义"

表现： 部署了能力探针，但从不根据探针结果采取行动。探针变成了摆设。

后果： AI 能力已经达标但系统仍在使用旧路径（浪费性能），或 AI 能力已经退化但系统仍在高信任模式运行（安全风险）。

正确做法： 探针必须与行动挂钩——达标触发升级评审，退化触发降级机制。探针不是"观察工具"，是"触发器"。

❌ 反模式八："忽视 AI 能力回退"

表现： 只考虑了 AI 能力越来越强的路径，没有准备 AI 服务降级、模型更换后能力下降的预案。

后果： 供应商调整 API 限制、模型版本更新后某些能力退化、或合规要求切换到国产模型——已蒸发的补偿层突然需要重新启用，但代码和知识都已丢失。

正确做法：

• • 蒸发的代码不要物理删除，而是移入 archive/evaporated/ 目录
• • 每个蒸发操作必须保留回退路径（配置开关，而非代码删除）
• • 在信任评分模型中设计衰减机制，长时间不验证 = 信任自动下降

❌ 反模式九："单一模型依赖"

表现： 所有 AI 操作都绑定在单一模型/供应商上，切换成本极高。

后果： 供应商涨价、服务中断、政策变化时，整个 AI 原生能力陷入瘫痪。

正确做法：

• • 意图声明和边界定义必须是模型无关的
• • Agent 编排层应支持多模型切换
• • 关键路径至少有两个模型可选
• • 定期用不同模型运行能力探针，评估替代方案

❌ 反模式十："只建不拆"

表现： 不断新增 AI 原生的规范文件（.intent.yaml、.boundary.yaml、ADR、知识图谱），但从不清理过时的规范。

后果： 规范文件互相矛盾、AI 读到了过时的知识做出错误决策。知识图谱的"噪声"比"信号"还多。

正确做法： 规范的生命周期管理和代码一样重要。每季度蒸发评审不仅评估补偿层代码，也评估所有规范文件的时效性。过时的规范必须标记为 deprecated 或归档。

十一、成熟度评估模型（Maturity Assessment Model）

在开始执行之前，先回答一个问题：我现在在哪里，该从哪里开始？

11.1 五级成熟度模型

Level 0         Level 1         Level 2         Level 3         Level 4TRADITIONAL     AWARE           STRUCTURED      ADAPTIVE        NATIVE传统模式         意识觉醒         结构化建设       自适应运行       AI 原生   │               │               │               │               │   ▼               ▼               ▼               ▼               ▼无 AI 参与     AI 作为工具     AI 有边界地     AI 自主运行     AI 与系统手动一切       辅助编码        参与开发运维    人类做决策者     深度融合

11.2 各级特征与评估标准

Level 0: TRADITIONAL（传统模式）

该做什么： 从 Day-1 最小行动清单开始 ↓

Level 1: AWARE（意识觉醒）

升级到 Level 2 的条件：

• • 80%+ 核心系统有 .intent.yaml
• • 50%+ 关键操作有 .boundary.yaml
• • 日志标准化率 > 70%

Level 2: STRUCTURED（结构化建设）

升级到 Level 3 的条件：

• • 能力探针部署并运行 > 3 个月
• • AI 代码审查准确率 > 95%
• • 至少完成一次蒸发评审
• • 三层验证体系建立

Level 3: ADAPTIVE（自适应运行）

升级到 Level 4 的条件：

• • AI 信任评分 > 96，持续 6 个月+
• • 全维度探针 > 99%
• • AI_LED 模式运行 > 6 个月无重大事故
• • 团队完成 AI 编排师技能转型

Level 4: NATIVE（AI 原生）

11.3 快速自评清单

回答以下 10 个问题，快速判断你的团队处于哪个级别：

你的级别 = 连续回答"是"的最高级别（中间断了就以断点前的级别为准）。

11.4 Day-1 最小行动清单

不知道从哪开始？从这里开始。一天之内可以完成。

不管你现在处于哪个级别，以下 5 件事情可以今天就做，零成本启动：

• • 1. 为最重要的 1 个系统写 system.intent.yaml
• • 只需要回答：它为什么存在？什么算成功？依赖什么？
• • 30 分钟可以完成一个初版
• • 2. 为该系统的 Top 3 危险操作写 .boundary.yaml
• • 列出：哪些操作 AI 绝对不能做（L4）？哪些可以自动做（L0-L1）？
• • 1 小时可以完成
• • 3. 在代码库中搜索并标注第一批 @ai-compensating 代码
• • 找那些你知道"如果 AI 更强就不需要"的代码，加上注解
• • 先标 5-10 处，不求全
• • 4. 把最近一次生产事故写成增强版 ADR
• • 包含 ai_context.invariants 和 ai_context.operation_boundary
• • 让 AI 也能"理解这次事故的教训"
• • 5. 统一团队的 AI 工具链
• • 确定编码用什么模型、审查用什么模型、建立基本使用规范
• • 开一个 30 分钟的团队会议即可

完成这 5 步，你就从 Level 0 进入了 Level 1。整个过程不超过半天。

十二、元规范：这份规范本身的生命周期

这份规范本身也遵循"可蒸发"原则。

# @ai-compensating# @reason 当前 AI 尚不能完全自主理解和遵守隐式的工程规范# @evaporation-condition AI 可以通过观察代码库自动推断并遵守工程规范# @evaporation-impact 规范从"显式文档"演化为"AI 内化的行为模式"

本规范的审查节奏：

• • 每季度：更新蒸发条件的评估结果
• • 每半年：评估规范本身是否需要结构性调整
• • 每次重大模型更新后：72 小时内评估对规范的影响

版本演化路径：

• • v1.0（当前）：人工编写和维护的显式规范
• • v2.0（预期）：AI 辅助维护，自动更新探针阈值和蒸发评估
• • v3.0（远期）：规范即代码——规范嵌入到系统运行时，自动执行

v1.0 — 2026年4月19日

以未来六个月的能力，定义今天的规范。以今天的规范，为未来六个月铺设安全的跑道。

附录：术语表