@chongyan/autospec 1.0.1

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

@@ -0,0 +1,318 @@
+# 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

@@ -0,0 +1,228 @@
+# 团队度量体系
+
+> 本文档定义 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

@@ -0,0 +1,134 @@
+# 项目宪法 — 不可违反的红线清单
+
+> 宪法门禁（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一次，确认条款仍然合理
+- 新增条款需说明来源（哪个事件/风险触发）