@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/organization/ai-native-team.md

@@ -1,318 +0,0 @@
-# AI Native 团队文化手册
-
-> 本手册定义 AI Native 团队的文化原则、工作方式和协作规范。
-> 与 `knowledge/principles/constitution.md` 互补，宪法红线在此同样生效。
-
-## 核心理念
-
-AI Native 团队不是"使用 AI 的团队"，而是"以 AI 为核心设计工作流的团队"。
-
-### AI Native 四原则
-
-| 原则 | 描述 | 实践 |
-|------|------|------|
-| **AI 思维贯穿** | 每个角色都具备 AI 思维特质，不只是 AI 工程师 | 产品经理懂 AI 能力边界，工程师会用 AI 辅助编程 |
-| **数据驱动** | 决策有数据支撑，效果有评测验证 | 需求有用户数据，AI 功能有效果评测 |
-| **快速验证** | AI 功能先验证可行性再大规模开发 | MVP → 验证 → 迭代，不盲目铺量 |
-| **人机协作** | 明确 AI 与人各自擅长的领域 | AI 负责实现，人负责验收和决策 |
-
----
-
-## 工作模式
-
-### 1. Vibe Coding（ vibe 编程）
-
-> 核心理念：自然语言描述需求，AI 生成代码，人类验收。
-
-**传统模式 vs Vibe Coding**：
-
-| 维度 | 传统模式 | Vibe Coding |
-|------|---------|-------------|
-| 需求表达 | 写 PRD、User Story | 自然语言描述 + 示例 |
-| 代码实现 | 人类工程师编写 | AI 生成 |
-| 人类角色 | 实现者 + 审查者 | 验收者 + 架构师 |
-| 关注点 | 怎么实现 | 要什么效果 |
-
-**Vibe Coding 流程**：
-
-```
-1. 需求澄清
-   ↓
-2. 自然语言描述 + 示例
-   ↓
-3. AI 生成代码（可多轮迭代）
-   ↓
-4. 人类验收（功能 + 性能 + 安全）
-   ↓
-5. 通过 → 提交 | 不通过 → 反馈给 AI 修复
-```
-
-**适用场景**：
-- 功能明确、边界清晰的需求
-- 重复性 CRUD 页面
-- 测试用例生成
-- 文档生成
-
-**不适用场景**：
-- 架构决策
-- 安全敏感逻辑
-- 性能关键路径
-- 全新技术领域
-
-### 2. AI 结对编程
-
-> 核心理念：AI Agent 作为"第二开发者"，与人类工程师协同工作。
-
-**角色分工**：
-
-| 角色 | 职责 |
-|------|------|
-| **人类工程师** | 架构决策、Code Review、复杂问题解决 |
-| **AI 开发者** | 代码实现、测试生成、文档编写、Bug 修复 |
-
-**协作模式**：
-
-```
-人类工程师
-    │
-    ├──→ 需求描述
-    │         ↓
-    ←── AI 产出 ←── AI 开发者实现
-    │
-    ├──→ 反馈/修正
-    │         ↓
-    ←── 修订版 ←── AI 开发者修复
-    │
-    └──→ 最终验收
-```
-
-**关键原则**：
-- AI 产出必须经过人类审查
-- 复杂逻辑人类先行设计，AI 填充实现
-- 安全相关代码人类重点审查
-
-### 3. 多代理审查系统
-
-> 核心理念：并行启动多个专业审查 Agent，从不同角度审查代码。
-
-借鉴 Anthropic Claude Code 的实践：
-
-```
-┌─────────────────────────────────────┐
-│         Code Review Pipeline        │
-├─────────────────────────────────────┤
-│  并行启动多个审查 Agent：            │
-│  ├── 架构审查 Agent                 │
-│  ├── 安全审查 Agent                 │
-│  ├── 性能审查 Agent                 │
-│  ├── 可维护性审查 Agent              │
-│  └── 逻辑审查 Agent                 │
-├─────────────────────────────────────┤
-│  汇总审查结果                       │
-│  ├── 一致通过项                     │
-│  ├── 分歧项                         │
-│  └── 必须修复项                     │
-├─────────────────────────────────────┤
-│  人类最终确认                       │
-└─────────────────────────────────────┘
-```
-
-**审查维度**：
-
-| 维度 | 检查内容 |
-|------|---------|
-| 架构 | 模块划分、依赖关系、扩展性 |
-| 安全 | 注入漏洞、越权、敏感数据 |
-| 性能 | 复杂度、N+1、缓存策略 |
-| 可维护性 | 代码重复、命名、注释 |
-| 逻辑 | 业务逻辑正确性、边界条件 |
-
----
-
-## 角色转变
-
-### 从"实现者"到"验收者"
-
-| 传统角色 | AI Native 角色 |
-|---------|--------------|
-| 写代码 | 描述需求 + 验收代码 |
-| 解决 bug | 指导 AI 定位 + 验证修复 |
-| 写测试 | 审查 AI 生成的测试 |
-| 写文档 | 审核 AI 生成的文档 |
-
-### 各角色 AI Native 视角
-
-#### CEO / 创始人
-
-- 战略决策考虑 AI 能力边界
-- 识别 AI 带来的新机会
-- 评估 AI 投资回报率
-
-#### 产品经理
-
-- 理解 AI 能力边界，不过度承诺
-- 用自然语言表达需求
-- 设计 AI 可理解的验收标准
-
-#### 技术负责人
-
-- AI 架构思维，评估 AI 方案可行性
-- 设计人机协作流程
-- 建立 AI 效果评测体系
-
-#### 工程师
-
-- AI 集成思维，API 设计考虑 AI 调用
-- 掌握 AI 辅助编程工具
-- 审查 AI 生成的代码
-
-#### AI 工程师
-
-- 模型选型与 Prompt 工程
-- AI 效果优化
-- AI 与业务系统的集成
-
----
-
-## 决策流程
-
-### AI 参与决策的边界
-
-| 决策类型 | AI 角色 | 人类角色 |
-|---------|--------|---------|
-| 需求澄清 | 主导（11维扫描） | 确认 |
-| 技术方案 | 建议（多方案生成） | 选择 |
-| 代码实现 | 主导 | 验收 |
-| 安全决策 | 辅助（扫描） | 主导 |
-| 架构决策 | 建议 | 主导 |
-| 部署决策 | 风险评估 | 确认 |
-
-### 人机协作决策树
-
-```
-决策点
-  │
-  ├── 安全敏感？
-  │    ├── 是 → 人类主导，AI 辅助
-  │    └── 否 → 继续
-  │
-  ├── 可逆决策？
-  │    ├── 是 → AI 主导，人类抽检
-  │    └── 否 → 继续
-  │
-  └── 影响范围大？
-       ├── 是 → 人类确认
-       └── 否 → AI 自主
-```
-
----
-
-## 团队能力要求
-
-### 技能矩阵
-
-| 角色 | AI 基础技能 | AI 进阶技能 |
-|------|------------|------------|
-| 产品 | AI 需求表达、AI 效果评估 | AI 方案评估 |
-| 工程师 | AI 辅助编程、AI 代码审查 | AI 架构设计 |
-| AI 工程师 | Prompt 工程、模型调优 | AI 系统设计 |
-| 管理者 | AI 团队管理、AI 投资评估 | AI 战略规划 |
-
-### 培训体系
-
-1. **入门**：AI 辅助编程工具使用
-2. **进阶**：AI 代码审查与质量控制
-3. **专家**：AI 架构设计与团队赋能
-
----
-
-## 实践指南
-
-### 1. AI 需求表达
-
-好的需求描述：
-
-```
-"用户登录后展示订单列表，每个订单显示：
-- 订单号（订单号格式：ORD-YYYYMMDD-XXXX）
-- 下单时间（格式：YYYY-MM-DD HH:mm）
-- 订单金额
-- 订单状态（待支付/已支付/已完成/已取消）
-
-点击订单跳转到订单详情页。"
-
-→ AI 可直接生成完整功能
-```
-
-差的需求描述：
-
-```
-"做一个订单功能"
-
-→ AI 需要多次澄清，效率低
-```
-
-### 2. AI 代码验收清单
-
-- [ ] 功能完整性：需求中的每个点都有实现
-- [ ] 边界条件：空值、异常、超长都有处理
-- [ ] 性能合理：没有明显的性能问题
-- [ ] 安全合规：没有注入、越权等漏洞
-- [ ] 代码质量：命名清晰，逻辑可读
-
-### 3. AI 反馈技巧
-
-| 场景 | 反馈方式 |
-|------|---------|
-| 功能不对 | "期望行为是 X，实际是 Y" |
-| 风格不对 | "参考现有代码风格：..." |
-| 效率低 | "需要优化性能，参考：..." |
-| 边界漏了 | "还需要处理 X 情况" |
-
----
-
-## 与现有流程集成
-
-### 与 6 阶段流程的对应
-
-| 阶段 | AI 增强点 |
-|------|----------|
-| 需求分析 | AI 辅助需求澄清、竞品分析 |
-| 方案设计 | AI 辅助架构设计、API 推导 |
-| 编码实现 | Vibe Coding、AI 结对编程 |
-| 测试验证 | AI 测试生成、AI 异常检测 |
-| 部署交付 | AI 部署风险评估 |
-| 归档复盘 | AI 辅助 practice-log 分析 |
-
-### 与双层验证的集成
-
-- **Layer 1**：AI 辅助的自动化验证
-- **Layer 2**：多代理 AI 审查 + 人类确认
-
----
-
-## 反模式
-
-### 1. 盲目信任 AI
-
-- 表现：不审查 AI 产出，直接提交
-- 后果：安全漏洞、质量问题
-- 纠正：所有 AI 产出必须经过验收
-
-### 2. 过度依赖 AI
-
-- 表现：所有问题都交给 AI，不自己思考
-- 后果：失去技术判断力
-- 纠正：复杂问题人类先思考，AI 填充实现
-
-### 3. AI 能力过高估计
-
-- 表现：给 AI 无法完成的任务
-- 后果：产出质量差，返工多
-- 纠正：明确 AI 能力边界，选择合适场景
-
-### 4. AI 能力过低估计
-
-- 表现：能 AI 做的还人工做
-- 后果：效率低，浪费资源
-- 纠正：持续学习 AI 新能力，迭代工作流

package/knowledge/organization/team-metrics.md

@@ -1,228 +0,0 @@
-# 团队度量体系
-
-> 本文档定义 AI Native 团队的度量指标体系。
-> 与 `knowledge/organization/ai-native-team.md` 互补。
-
-## 概述
-
-AI Native 团队的度量体系需要同时衡量：
-1. **AI 能力**：AI 在团队中的参与度和效果
-2. **流程效率**：研发流程的效率和质量
-3. **产出质量**：最终交付物的质量
-
----
-
-## 一、AI 能力指标
-
-### 1.1 AI 参与度指标
-
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 代码占比** | AI 参与生成的代码占总代码量比例 | AI 生成行数 / 总代码行数 | > 40% |
-| **AI 审查覆盖率** | AI 审查覆盖的变更比例 | AI 审查次数 / 总变更次数 | 100% |
-| **AI 测试覆盖率** | AI 生成的测试占总测试比例 | AI 生成测试数 / 总测试数 | > 60% |
-
-### 1.2 AI 质量指标
-
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 首次通过率** | AI 生成的代码一次通过审查的比例 | 一次通过次数 / AI 生成提交次数 | > 70% |
-| **AI 修复效率** | AI 修复问题的平均次数 | 修复总次数 / 问题数 | < 2 次 |
-| **AI 误报率** | AI 审查中误报的比例 | 误报数 / 总报告数 | < 15% |
-
-### 1.3 AI 效率指标
-
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **AI 响应时间** | AI 从请求到响应的时间 | 平均响应时间 | < 30s |
-| **AI 并行度** | 同时运行的 AI 任务数 | 峰值并发数 | > 5 |
-| **AI 成本效率** | 每单位成本的 AI 产出 | 代码行数 / AI 成本 | 持续优化 |
-
----
-
-## 二、流程效率指标
-
-### 2.1 阶段效率指标
-
-| 阶段 | 指标 | 定义 | 目标 |
-|------|------|------|------|
-| 需求分析 | 需求澄清效率 | 需求到澄清完成的时间 | < 4h |
-| 方案设计 | 设计完成率 | 按计划完成设计的比例 | > 90% |
-| 编码实现 | 代码交付速度 | 每日提交行数 | 符合估算 |
-| 代码审查 | 审查响应时间 | 发起审查到首次响应 | < 4h |
-| 测试验证 | 测试通过率 | 首次提交测试通过率 | > 80% |
-| 交付部署 | 部署成功率 | 首次部署成功比例 | > 95% |
-
-### 2.2 迭代效率指标
-
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **周期时间** | 从需求到交付的总时间 | 交付时间 - 需求确认时间 | 持续缩短 |
-| **前置时间** | 需求确认到开始开发 | 开始时间 - 确认时间 | < 1 工作日 |
-| **批量大小** | 平均每次交付的需求数 | 交付需求数 / 交付次数 | 1-3 个 |
-| **在制品数量** | 同时进行的需求数 | 平均并行需求数 | < 5 个 |
-
-### 2.3 阻塞指标
-
-| 指标 | 定义 | 计算方式 | 目标 |
-|------|------|---------|------|
-| **阻塞率** | 被阻塞的阶段比例 | 阻塞次数 / 阶段总数 | < 10% |
-| **阻塞时长** | 平均阻塞时间 | 阻塞总时长 / 阻塞次数 | < 4h |
-| **升级率** | 需要人工介入的比例 | 升级次数 / 总任务数 | < 5% |
-
----
-
-## 三、质量指标
-
-### 3.1 代码质量指标
-
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **缺陷密度** | 每千行代码的缺陷数 | < 1 个/千行 |
-| **代码覆盖率** | 被测试覆盖的代码比例 | > 80% |
-| **技术债务比** | 技术债务与代码总量比 | < 5% |
-| **代码重复率** | 重复代码的比例 | < 3% |
-
-### 3.2 审查质量指标
-
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **审查通过率** | 首次提交通过审查的比例 | > 70% |
-| **审查意见数** | 平均每次审查的意见数 | 5-15 条 |
-| **审查时间** | 从提交到通过的平均时间 | < 1 工作日 |
-
-### 3.3 交付质量指标
-
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **线上缺陷率** | 线上发现的缺陷数 | < 2 个/版本 |
-| **回滚率** | 需要回滚的部署比例 | < 2% |
-| **P0 故障数** | 严重故障数量 | 0 |
-
----
-
-## 四、团队健康指标
-
-### 4.1 协作健康
-
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **任务完成率** | 按计划完成的任务比例 | > 90% |
-| **返工率** | 需要返工的任务比例 | < 10% |
-| **沟通成本** | 会议时间占比 | < 15% |
-
-### 4.2 成长健康
-
-| 指标 | 定义 | 目标 |
-|------|------|------|
-| **技能增长率** | 新技能掌握速度 | 持续提升 |
-| **知识分享数** | 团队分享次数 | 每周 > 2 次 |
-| **自动化程度** | 自动化任务占比 | 持续提升 |
-
----
-
-## 五、度量采集
-
-### 5.1 自动采集
-
-| 数据源 | 采集内容 | 频率 |
-|--------|---------|------|
-| Git | 提交、审查、合并数据 | 实时 |
-| CI/CD | 构建、测试、部署数据 | 实时 |
-| 项目管理 | 任务流转、阻塞数据 | 实时 |
-| 监控 | 线上质量数据 | 实时 |
-
-### 5.2 手动采集
-
-| 数据源 | 采集内容 | 频率 |
-|--------|---------|------|
-| 回顾会 | 团队反馈、改进建议 | 每周 |
-| 调查问卷 | 团队满意度 | 每月 |
-| 一对一 | 个人成长、挑战 | 每月 |
-
----
-
-## 六、度量看板
-
-### 6.1 核心看板
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    AI Native 团队度量看板                    │
-├─────────────────────────────────────────────────────────────┤
-│                                                             │
-│  AI 能力                    流程效率              质量       │
-│  ┌──────────┐            ┌──────────┐        ┌────────┐ │
-│  │AI代码占比 │            │周期时间   │        │缺陷密度│ │
-│  │   45%    │            │   5天    │        │ 0.8    │ │
-│  │   ↑5%    │            │   ↓1天   │        │  ↓0.2  │ │
-│  └──────────┘            └──────────┘        └────────┘ │
-│                                                             │
-│  ┌──────────┐            ┌──────────┐        ┌────────┐ │
-│  │AI首次通过 │            │审查响应   │        │覆盖率  │ │
-│  │   75%    │            │   3h     │        │  85%   │ │
-│  │   ↑10%   │            │   ↓1h    │        │  ↑5%   │ │
-│  └──────────┘            └──────────┘        └────────┘ │
-│                                                             │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 6.2 趋势分析
-
-| 指标 | 周环比 | 月环比 | 季度趋势 |
-|------|-------|-------|---------|
-| AI 代码占比 | +3% | +8% | ↑ |
-| 周期时间 | -0.5天 | -1天 | ↓ |
-| 缺陷密度 | -0.1 | -0.3 | ↓ |
-
----
-
-## 七、目标设定
-
-### 7.1 短期目标（1-3个月）
-
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 30% | 40% |
-| AI 首次通过率 | 60% | 70% |
-| 审查响应时间 | 6h | 4h |
-
-### 7.2 中期目标（3-6个月）
-
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 40% | 50% |
-| 周期时间 | 5天 | 3天 |
-| 缺陷密度 | 0.8 | 0.5 |
-
-### 7.3 长期目标（6-12个月）
-
-| 指标 | 当前值 | 目标值 |
-|------|-------|-------|
-| AI 代码占比 | 50% | 60% |
-| 自动化程度 | 70% | 90% |
-| 线上缺陷率 | 1.5 | < 1 |
-
----
-
-## 八、持续优化
-
-### 8.1 度量评审
-
-- **周度**：查看核心指标趋势
-- **月度**：分析目标达成情况
-- **季度**：调整目标和策略
-
-### 8.2 改进闭环
-
-```
-发现 → 分析 → 制定 → 执行 → 验证
-  ↑______________________________↓
-```
-
-### 8.3 注意事项
-
-1. **不追求完美指标**：指标是工具，不是目的
-2. **关注趋势**：比关注绝对值更重要的是趋势
-3. **避免过度度量**：度量有成本，聚焦关键指标
-4. **结合定性分析**：定量 + 定性 = 完整画像

package/knowledge/principles/constitution.md

@@ -1,134 +0,0 @@
-# 项目宪法 — 不可违反的红线清单
-
-> 宪法门禁（DP10）：自动检查，违反任何一条立即停止全流程。
->
-> **版本**: v2.0
-> **最后更新**: 2026-03-26
-> **基于**: 业界风险防范基本条例、核心原则
-
-## 安全红线
-
-1. **不可逆动作必须人工确认**
-   - 数据库迁移（DDL变更）
-   - 生产环境部署
-   - 外部API发送（邮件、短信、支付等）
-   - 数据删除（DELETE/TRUNCATE）
-   - 分支强制推送
-
-2. **敏感信息不可硬编码**
-   - 密钥、密码、Token不可出现在代码中
-   - 生产环境配置不可出现在代码仓库中
-   - 用户隐私数据不可出现在日志中
-
-3. **安全漏洞零容忍**
-   - SQL注入
-   - XSS（跨站脚本）
-   - CSRF（跨站请求伪造）
-   - 越权访问
-   - 未加密传输敏感数据
-
-## 流程红线
-
-4. **启动门禁不可跳过**
-   - 收到开发/建设类任务时，必须先执行启动协议（读pipeline→读宪法→确认范围）
-   - 禁止跳过需求分析直接写代码
-   - "全流程自动化"≠"跳过流程"，而是"按框架自动推进各阶段"
-
-5. **Layer 1不过不进Layer 2**
-   - 确定性验证（编译/测试/lint）失败时，禁止进入AI审查
-   - 测试红灯时，禁止声明代码完成
-
-6. **Layer 1必须真实执行**
-   - 禁止用"静态分析评估"替代真实执行来声称Layer 1通过
-   - 无法执行 → 标记为BLOCKED，不是PASSED
-   - BLOCKED → 先解决环境问题，或降级为experiment模式
-   - Layer 1结果必须附带真实执行日志
-
-7. **做审必须分离**
-   - 做类skill和审类skill必须由不同AI实例执行
-   - 审查必须通过Agent工具启动独立子进程，实现信息隔离
-   - 禁止同一上下文中切换角色冒充分离
-
-8. **回退上限3次**
-   - 同一问题修正循环超过3次必须升级人工
-   - 禁止无限循环修复
-
-9. **关键假设必须显式记录**
-   - 每个阶段的关键假设必须写入文件
-   - 阶段间传递时必须校验假设一致性
-   - 待确认假设超过3个必须升级人工
-
-## 决策红线
-
-10. **方向性决策必须人工确认**
-   - 需求方向和范围变更
-   - 架构重大变更（如单体→微服务）
-   - 安全敏感决策
-   - 新技术引入
-   - 自动模式下：标记为 REQUIRE_REVIEW + pendingConfirmations，不阻塞但不执行
-
-11. **知情猜测有上限**
-   - 最多3个NEEDS CLARIFICATION标记
-   - 其余做合理默认但不可隐藏假设
-
-## 执行模式红线
-
-> 自动模式（unattended）不降低安全标准，只改变确认方式。
-
-- **以下红线在自动模式下不可降级**（两种模式同等执行）：
-  - 安全红线（#1-#3）全部生效
-  - Layer 1 真实执行（#5-#6）全部生效
-  - 做审分离（#7）全部生效
-  - 数据完整性（#12）全部生效
-  - 部署可回滚（#13）全部生效
-  - 安全审计结论为"不安全" → 两种模式都阻止执行
-- **以下确认行为在自动模式下可降级为记录**：
-  - 不可逆动作确认（#1）→ 生成方案但不执行，记录 pendingConfirmations
-  - 阶段产出确认（#4 流程中的人工确认点）→ 使用 stage-gate Agent 替代
-  - 方向性决策确认（#10）→ 使用推荐值，标记 REQUIRE_REVIEW
-  - 待确认假设升级（#9）→ 记录但不阻塞，标记 HIGH_PRIORITY_REVIEW
-- **自动模式完成后，pendingConfirmations 中的所有项必须在下次交互中向用户展示**
-
-## 数据红线
-
-12. **数据完整性不可妥协**
-    - 禁止跳过数据校验
-    - 禁止未经验证的数据格式转换
-    - 禁止金额使用浮点数运算（必须使用 Money 类或 BigDecimal）
-    - 禁止 SELECT * 查询（必须指定列名）
-    - 禁止使用 ${} 进行 SQL 拼接（必须使用 #{} 参数化查询）
-
-## 运维红线
-
-13. **部署必须可回滚**
-    - 每次部署必须有回滚方案
-    - 回滚方案必须经过验证
-    - 禁止"只能前进不能后退"的部署
-
-14. **监控与日志规范**
-    - 关键业务节点必须打印日志（使用 LogUtil，带 TraceId）
-    - 禁止直接使用 logger 打印（无 TraceId，无法链路追踪）
-    - 禁止空 catch 块（异常必须记录日志并处理）
-    - 异步方法必须捕获异常（防止异常吞掉）
-    - 必须考虑三板斧：灰度、监控、应急
-
-15. **并发控制**
-    - 更新数据前必须加锁（一锁二判三更新原则）
-    - 禁止使用无界线程池（队列长度建议≤100）
-    - ThreadLocal 使用完毕后必须调用 remove() 清理
-
-## 停线条件
-
-以下任一条件成立 → 立即停止全流程，等待人工处理：
-- 检测到安全漏洞（上述第3条）
-- 检测到数据丢失风险
-- 同一问题修复3次仍未通过
-- 宪法门禁检查不通过
-- AI自我判断置信度极低（无法给出合理默认值）
-
-## 宪法修订规则
-
-- 本宪法的修改必须人工审批
-- AI不可自行修改或绕过宪法条款
-- 每季度review一次，确认条款仍然合理
-- 新增条款需说明来源（哪个事件/风险触发）