Update from Sync Service

2026-06-22.md

@@ -0,0 +1,5 @@
+
+ 
+
+- [ ] ⏫ 无人机测流项目预算
+- [ ] 🔼 

AI工程/3DGS在VR眼镜上的显示方案研究.md

@@ -0,0 +1,273 @@
+# 3DGS 数据在 VR 眼镜上的显示方案研究
+
+> 研究日期：2026-06-07
+> 关键词：3DGS, 3D Gaussian Splatting, SuperSplat, VR, WebXR, Meta Quest
+
+---
+
+## 一、3DGS (3D Gaussian Splatting) 技术概述
+
+### 什么是 3DGS？
+
+3D Gaussian Splatting 是 2023 年 SIGGRAPH 发表的革命性 3D 场景表示技术（论文作者：Kerbl, Kopanas 等），用**数百万个半透明的椭圆高斯球**来重建 3D 场景，而非传统的多边形网格。
+
+**核心优势：**
+- 📸 **照片级真实感**：从照片/视频直接生成，效果逼真
+- ⚡ **实时渲染**：优化后可达交互帧率
+- 🌟 **体积表示**：自然处理半透明材质、精细细节、复杂光照
+- 💰 **低成本**：比传统 3D 建模便宜且快速
+
+### 数据格式
+
+| 格式 | 说明 | 大小 |
+|------|------|------|
+| **PLY** | 标准二进制 3DGS 格式（未压缩） | 大（数百MB~数GB） |
+| **SOG** | PlayCanvas 压缩格式（ZIP + WebP） | PLY 的 1/15~1/20 |
+| **SPZ** | SuperSplat 项目格式 | 压缩后更小 |
+
+---
+
+## 二、SuperSplat 工具
+
+### 基本信息
+
+- **开发者**：PlayCanvas
+- **GitHub**：https://github.com/playcanvas/supersplat（⭐9k+）
+- **在线版**：https://superspl.at/editor
+- **许可证**：MIT（免费开源）
+- **技术栈**：纯 Web（TypeScript + PlayCanvas Engine），浏览器直接运行
+
+### 核心功能
+
+1. **检查（Inspect）**：加载 .ply / .splat 文件，查看高斯球分布
+2. **编辑（Edit）**：选中/删除/移动高斯球，清理噪点
+3. **优化（Optimize）**：压缩、裁剪、降采样，减小文件体积
+4. **发布（Publish）**：导出优化后的文件，或直接发布到 SuperSplat 平台
+
+### ⚠️ SuperSplat 本身不支持 VR
+
+SuperSplat 是一个**编辑器**，运行在桌面浏览器的 2D 界面中。它**不直接支持 VR 模式**。
+
+要在 VR 中查看 3DGS 数据，需要使用以下方案之一。
+
+---
+
+## 三、3DGS 在 VR 上显示的技术方案
+
+### 方案对比
+
+| 方案                     | 平台              | 渲染技术                 | VR 支持    | 难度   | 适用场景             |
+| ---------------------- | --------------- | -------------------- | -------- | ---- | ---------------- |
+| **PlayCanvas + WebXR** | Web 浏览器         | WebGL/WebGPU         | ✅ WebXR  | ⭐⭐   | 最简单，跨平台          |
+| **RSR**                | Windows 原生      | Direct3D 12 + OpenXR | ✅ OpenXR | ⭐    | 最佳性能，PC VR       |
+| **Unity VR Viewer**    | Windows (Unity) | CUDA + OpenXR        | ✅ OpenXR | ⭐⭐⭐  | 开发者，需 NVIDIA GPU |
+| **A-Frame + GS**       | Web 浏览器         | WebGL                | ✅ WebXR  | ⭐⭐   | 快速原型             |
+| **VRSplat**            | Linux/CUDA      | CUDA + OpenGL        | ✅ 研究     | ⭐⭐⭐⭐ | 学术研究             |
+
+### 方案 1：PlayCanvas + WebXR（推荐入门）
+
+**原理**：PlayCanvas Engine 原生支持 Gaussian Splatting 渲染 + WebXR API。
+
+**流程**：
+1. 用 SuperSplat 编辑/优化 3DGS 数据
+2. 导出 PLY 或 SOG 文件
+3. 在 PlayCanvas 项目中加载并启动 WebXR VR 会话
+
+**优势**：
+- 浏览器直接运行，无需安装
+- Meta Quest 浏览器原生支持 WebXR
+- Apple Vision Pro Safari 也支持
+
+**代码示例**（PlayCanvas）：
+```javascript
+// 检查 VR 支持并启动
+button.element.on('click', () => {
+  if (app.xr.supported && app.xr.isAvailable(pc.XRTYPE_VR)) {
+    app.xr.start(entity.camera, pc.XRTYPE_VR, pc.XRSPACE_LOCALFLOOR);
+  }
+});
+```
+
+**局限**：
+- 浏览器性能有限，大场景可能卡顿
+- 移动端 VR（Quest 独立模式）渲染能力受限
+
+### 方案 2：RSR — Rapid Splat Renderer（推荐高性能）
+
+- **GitHub**：https://github.com/warpgatelabs/RSR（⭐44）
+- **技术**：Direct3D 12 + OpenXR
+- **平台**：Windows only
+
+**特点**：
+- 原生 D3D12 渲染，性能最强
+- 支持 PLY 和 SOG 格式
+- 支持完整球谐函数（SH up to order 3）
+- 可选 NVIDIA DLSS 超分辨率（RTX GPU）
+- **免费个人/非商业使用**
+
+**使用方式**：
+```
+RSR.exe                     # 启动文件浏览器
+RSR.exe <path-to-scene>     # 直接打开场景
+```
+按 V 或 F11 切换 VR 模式，支持 OpenXR（SteamVR / Oculus / 其他 OpenXR 运行时）。
+
+**VR 控制方式**：
+- 左摇杆：移动
+- 右摇杆：转向/上下
+- 左/右手柄 Grip：拖拽/缩放场景
+- A 键：重置视角
+
+**系统要求**：
+- Windows 10/11 x64
+- DirectX 12 GPU
+- OpenXR 兼容 VR 头显
+- NVIDIA RTX GPU（可选，用于 DLSS）
+
+### 方案 3：Unity + CUDA VR Viewer
+
+- **GitHub**：https://github.com/clarte53/GaussianSplattingVRViewerUnity（⭐373）
+- **技术**：Unity + CUDA 原生插件 + OpenXR
+
+**特点**：
+- 使用原始 CUDA 光栅化器，渲染质量最高
+- 支持同时加载多个模型
+- 支持深度混合（高斯球与 3D 场景混合）
+- 支持多相机渲染
+
+**性能参考**（bicycle 场景，RTX 3060 Ti）：
+- 桌面 OpenGL (FOV 60°): 12ms (80 FPS)
+- Unity DirectX11 (FOV 60°): 15ms (67 FPS)
+- **Unity OpenXR (双眼, FOV 90°): 38ms (26 FPS)**
+
+**注意**：VR 模式需要渲染双眼 + 更大 FOV，性能开销约 2.5-3x
+
+**硬件要求**：
+- CUDA GPU（Compute Capability 7.0+，即 RTX 2060 以上）
+- 推荐 RTX 4070+
+- 16GB RAM
+
+### 方案 4：VRSplat（学术方案）
+
+- **GitHub**：https://github.com/Cekavis/VRSplat（⭐57）
+- **论文**："VRSplat: Fast and Robust Gaussian Splatting for Virtual Reality"
+- 专门优化 VR 渲染的学术方案，解决了 VR 中的高斯球渲染痛点
+
+---
+
+## 四、VR 眼镜选型
+
+### 根据 3DGS 渲染需求分类
+
+3DGS 渲染对 GPU 要求极高（百万级高斯球实时排序+渲染），需要区分两种使用模式：
+
+**A. PC VR 模式（推荐）**：VR 眼镜连接 PC，由 PC GPU 负责渲染
+**B. 独立 VR 模式**：VR 眼镜自带芯片渲染，性能受限
+
+### 推荐设备
+
+#### 🥇 方案 A：PC VR（最佳体验）
+
+| 设备 | 价格（人民币） | 分辨率 | FOV | 连接方式 | 推荐理由 |
+|------|---------------|--------|-----|---------|---------|
+| **Meta Quest 3** | ¥3,500-4,000 | 2064×2208/眼 | 110° | WiFi串流/USB-C | 性价比之王，WebXR+PC串流都支持 |
+| **Meta Quest 3S** | ¥2,200-2,800 | 1832×1920/眼 | 96° | WiFi串流/USB-C | 预算有限首选，3 的降配版 |
+| **Pico 4 Ultra** | ¥3,500-4,000 | 2160×2160/眼 | 105° | WiFi串流/USB-C | 国行首选，售后好，国内生态完善 |
+| **Pico 4** | ¥1,800-2,500 | 2160×2160/眼 | 105° | WiFi串流/USB-C | 性价比之选 |
+| **Valve Index** | ¥6,000+ | 1440×1600/眼 | 130° | DP直连 | FOV最大，刷新率144Hz |
+| **HTC Vive Pro 2** | ¥7,000+ | 2448×2448/眼 | 120° | DP直连 | 分辨率最高，专业级 |
+| **Bigscreen Beyond 2** | ¥7,000+ | 2560×2560/眼 | 110° | DP直连 | 超轻(仅127g)，Micro OLED，极致画质 |
+
+**PC VR 的关键**：GPU 决定体验，建议：
+- **最低**：RTX 3060 Ti（VR 模式约 26 FPS，可接受但不算流畅）
+- **推荐**：RTX 4070 Super 以上（流畅体验 60+ FPS）
+- **理想**：RTX 4080/4090（大场景也能流畅）
+
+#### 🥈 方案 B：独立 VR（便捷但性能受限）
+
+| 设备 | 价格 | 芯片 | 分辨率 | 3DGS 能力 | 备注 |
+|------|------|------|--------|-----------|------|
+| **Meta Quest 3** | ¥3,500 | Snapdragon XR2 Gen 2 | 2064×2208/眼 | ⚠️ 仅小场景 | 浏览器 WebXR 运行 PlayCanvas |
+| **Meta Quest 3S** | ¥2,200 | Snapdragon XR2 Gen 2 | 1832×1920/眼 | ⚠️ 仅小场景 | 同上 |
+| **Apple Vision Pro** | ¥25,000+ | M2 + R1 | 3660×3200/眼 | ✅ 较好 | Safari WebXR，芯片性能强 |
+| **Pico 4 Ultra** | ¥3,500 | Snapdragon XR2 Gen 2 | 2160×2160/眼 | ⚠️ 仅小场景 | 国行，浏览器支持 WebXR |
+
+**独立模式的限制**：
+- 移动端 GPU 性能仅为 PC 的 1/10~1/5
+- 3DGS 场景必须大幅压缩（减少高斯球数量到数十万级）
+- 只能通过 WebXR 浏览器方案（PlayCanvas）
+- 大场景基本无法流畅运行
+
+#### 🥉 方案 C：混合模式（Quest 串流 PC）
+
+这是**性价比最优方案**：
+1. 购买 Meta Quest 3 / Pico 4 Ultra
+2. 独立使用时通过浏览器 WebXR 查看小场景
+3. 连接 PC 时通过 Steam Link / Air Link / Virtual Desktop 使用 RSR 等原生方案
+
+**一台设备，两种模式，兼顾便携和性能。**
+
+### 最终推荐
+
+| 需求 | 推荐设备 | 理由 |
+|------|---------|------|
+| 💰 **预算优先** | Meta Quest 3S + PC | ¥2,200 起步，PC 串流体验完整 |
+| ⚖️ **性价比最优** | **Meta Quest 3 + PC（RTX 4070+）** | ¥3,500，独立+PC双模式 |
+| 🇨🇳 **国内首选** | **Pico 4 Ultra + PC** | 国行保修，国内售后完善 |
+| 🎯 **专业级** | Bigscreen Beyond 2 + PC（RTX 4090） | Micro OLED 极致画质 |
+| 🍎 **苹果生态** | Apple Vision Pro | 25K+，M2 芯片性能强，但贵 |
+
+---
+
+## 五、完整工作流
+
+```
+拍照/录像 → 训练3DGS模型 → SuperSplat编辑优化 → VR显示
+   ↓              ↓                ↓                ↓
+ 手机/相机    gaussian-splatting   superspl.at/editor  ↓
+ Polycam     gsplat/nerfstudio   裁剪/压缩/清理      ↓
+ Luma AI                            ↓                ↓
+                                导出 PLY/SOG          ↓
+                                           ┌─────────┴──────────┐
+                                           ↓                    ↓
+                                    WebXR方案              原生方案
+                                  (PlayCanvas)          (RSR/Unity)
+                                           ↓                    ↓
+                                    Quest浏览器           PC + OpenXR
+                                    (独立模式)            (PC VR模式)
+```
+
+---
+
+## 六、关键参考链接
+
+### 工具
+- SuperSplat Editor: https://superspl.at/editor
+- PlayCanvas Engine: https://playcanvas.com
+- RSR (Rapid Splat Renderer): https://github.com/warpgatelabs/RSR
+- Unity VR Viewer: https://github.com/clarte53/GaussianSplattingVRViewerUnity
+- VRSplat: https://github.com/Cekavis/VRSplat
+- Splatapult (C++ OpenGL): https://github.com/hyperlogic/splatapult
+
+### 3DGS 训练
+- 原始实现: https://github.com/graphdeco-inria/gaussian-splatting
+- gsplat (CUDA 加速): https://github.com/nerfstudio-project/gsplat
+- Nerfstudio: https://github.com/nerfstudio-project/nerfstudio
+
+### 数据来源
+- Polycam (拍照生成3DGS): https://poly.cam/gaussian-splatting/
+- Luma AI: https://lumalabs.ai
+
+### 文档
+- PlayCanvas Gaussian Splatting: https://developer.playcanvas.com/user-manual/gaussian-splatting/
+- PlayCanvas XR: https://developer.playcanvas.com/user-manual/xr/
+- SuperSplat User Guide: https://developer.playcanvas.com/user-manual/gaussian-splatting/editing/supersplat/
+
+---
+
+## 七、总结建议
+
+1. **如果你有 PC（RTX 4070+）**：买 Meta Quest 3 或 Pico 4 Ultra，用 RSR 渲染，体验最佳
+2. **如果只有笔记本**：Quest 3S 最低预算入门，通过 Steam Link 连笔记本
+3. **如果要给客户展示**：SuperSplat 编辑优化 → PlayCanvas WebXR 发布 → 发链接即可在 Quest 浏览器打开
+4. **3DGS 数据必须优化**：原始 PLY 文件太大，用 SuperSplat 裁剪+压缩后再用于 VR

AI工程/AI上下文体系_团队级AICoding.md

@@ -0,0 +1,114 @@
+# AI上下文体系 - 团队级AI Coding简明手册
+
+> 来源：幻灯片分享，2026-06-20 归档
+
+## 核心理念
+
+使用完整的文档来描述上下文和约束体系，**区分过程方案和事实方案，减少维护成本**。
+
+---
+
+## 文档分层结构
+
+| 目录 | 用途 | 维护者 | 性质 |
+|------|------|--------|------|
+| `docs/standards` | 标准规格（API、命名、安全规范） | Tech Lead | 事实方案 |
+| `docs/features` | 需求规格 | 产品/BA | 事实方案 |
+| `docs/plans` | 计划规格（每轮任务实现方案） | AI/开发 | **过程方案** |
+| `docs/designs` | 设计规格（DB、表等 Source of Truth） | AI/开发 | 事实方案 |
+| `docs/others` | 架构决策、Release、测试用例 | — | 按需 |
+| `AGENTS.md` | 宪法级约束 | — | 事实方案 |
+
+---
+
+## 过程方案 vs 事实方案
+
+### 过程方案（Plans）
+
+**定义**：每次 Plan/Go 循环产生的**执行计划**，记录"我们打算怎么做"。
+
+**特点**：
+- 临时的、一次性的
+- 每次创建**新文件**（如 `plan-2026-06-20-feature-x.md`）
+- 细微修改**不再更新**旧文件，直接创建新版本
+- 作为执行记录，不是长期参考
+
+**示例**：
+```
+docs/plans/
+├── plan-2026-06-01-user-auth.md
+├── plan-2026-06-05-user-auth-v2.md
+└── plan-2026-06-10-payment-flow.md
+```
+
+**为什么这样设计**：
+- 避免反复修改同一文件导致的 Git 冲突
+- 保留历史决策轨迹，方便复盘
+- AI 每次执行完可以"丢弃"，不污染长期文档
+
+---
+
+### 事实方案（Designs / Standards / Features）
+
+**定义**：反映系统**当前真实状态**的文档，是 Source of Truth。
+
+**特点**：
+- 长期有效的、稳定的
+- 每次变更以**最终态更新**（覆盖式修改）
+- 作为下一次 Plan 的**起点和依据**
+- 必须与实际代码/系统保持一致
+
+**示例**：
+```
+docs/designs/
+├── database-schema.md        # 当前数据库表结构
+├── api-endpoints.md          # 当前 API 定义
+└── architecture.md           # 当前架构图
+
+docs/standards/
+├── coding-style.md           # 编码规范
+└── security-guidelines.md    # 安全规范
+```
+
+**为什么这样设计**：
+- AI 每次 Plan 时读取这些文档，获得"当前真相"
+- 避免 AI 基于过时的信息做决策
+- 减少维护成本：只维护一份最终态
+
+---
+
+## Plan/Go 模式的规格流转
+
+```
+起点 Features
+    ↓
+Standards（约束）
+    ↓
+TDD 驱动测试 + 代码
+    ↓
+事实方案 Designs（更新最终态）
+    ↓
+过程方案 Plans（执行记录）
+    ↓
+回到起点 Features（验收）
+```
+
+**流转规则**：
+- **追加**：创建新文件，细微修改不再更新 → 过程方案
+- **变更**：以最终态更新，作为下一次 Plan 的事实依据 → 事实方案
+
+---
+
+## 实践建议
+
+1. **AGENTS.md 作为宪法**：定义 AI 的行为边界和基本原则
+2. **区分"打算做"和"已做完"**：Plans 是意图，Designs 是事实
+3. **减少维护成本**：过程方案不维护，事实方案必须维护
+4. **AI 友好**：每次 Plan 前读取事实方案，执行后更新事实方案
+
+---
+
+## 参考
+
+- 幻灯片：如何让AI听话-构建AI上下文体系
+- 归档日期：2026-06-20

AI工程/AI辅助硬件设计开发最佳实践.md

@@ -0,0 +1,588 @@
+# AI辅助硬件设计开发最佳实践
+
+> 研究日期：2026-06-11
+> 状态：深度研究版
+
+---
+
+## 目录
+
+1. [概述](#概述)
+2. [AI辅助硬件设计全景图](#ai辅助硬件设计全景图)
+3. [AI辅助设计评审详解](#ai辅助设计评审详解)
+4. [LLM辅助芯片设计](#llm辅助芯片设计)
+5. [Agentic EDA趋势](#agentic-eda趋势)
+6. [国内外工具对比](#国内外工具对比)
+7. [最佳实践建议](#最佳实践建议)
+8. [风险与局限](#风险与局限)
+9. [参考资料](#参考资料)
+
+---
+
+## 概述
+
+### 什么是AI辅助硬件设计？
+
+AI辅助硬件设计是指将人工智能技术（特别是大语言模型LLM和强化学习RL）应用于电子硬件设计全流程，包括：
+
+- **原理图设计**：元器件选型、电路拓扑生成、原理图绘制
+- **PCB设计**：布局、布线、层叠设计
+- **设计评审**：DRC/ERC检查、信号完整性分析、EMC评估、DFM分析
+- **仿真验证**：热仿真、信号完整性仿真、电源完整性仿真
+- **芯片设计**：RTL生成、验证用例生成、物理设计优化
+
+### 发展时间线
+
+| 时间 | 里程碑 |
+|------|--------|
+| 2020 | Synopsys推出DSO.ai，首次将强化学习引入芯片物理设计 |
+| 2021 | Cadence推出Cerebrus AI引擎 |
+| 2023 | Quilter.ai成立，专注AI PCB设计 |
+| 2024 | Flux.ai获B轮融资，用户突破100万 |
+| 2025 | 华秋发布国内首款AI EDA工具 |
+| 2025 | 嘉立创接入大模型，实现自然语言选型+AI建库 |
+| 2025 | Quilter获2500万美元B轮融资 |
+| 2026 | Agentic EDA概念兴起，从L2辅助迈向L3自主 |
+
+---
+
+## AI辅助硬件设计全景图
+
+### 板级设计工具
+
+#### Quilter.ai ⭐⭐⭐⭐⭐
+- **官网**：https://www.quilter.ai
+- **核心技术**：物理驱动的强化学习 + 大模型
+- **主要能力**：
+  - 从原理图自动生成PCB布局布线
+  - 自动优化信号完整性、电源完整性
+  - 自动DRC/DFM检查
+  - 设计时间从数周缩短到数小时
+- **融资历程**：
+  - 2024年：2700万美元B轮
+  - 2025年4月：2500万美元B+轮
+- **适用场景**：消费电子、IoT、工业控制
+- **局限**：复杂高速板仍需人工干预
+
+#### Flux.ai ⭐⭐⭐⭐
+- **官网**：https://www.flux.ai
+- **核心技术**：云端协作 + AI辅助布局
+- **主要能力**：
+  - 实时多人协作编辑
+  - AI辅助元件放置和走线建议
+  - 实时DRC检查
+  - 内置元器件数据库（100万+器件）
+- **用户规模**：100万+注册用户
+- **定价**：免费版 + 付费Pro版
+- **适用场景**：教育、快速原型、小团队
+
+#### 华秋AI EDA ⭐⭐⭐
+- **官网**：https://www.huqiu.com
+- **定位**：国内首款深度融合大模型的AI EDA工具
+- **主要能力**：
+  - 自然语言描述→电路原理图
+  - AI元器件推荐
+  - 智能布局建议
+  - 与华秋PCB打样深度集成
+- **特色**：开源+AI，与嘉立创生态打通
+- **局限**：与国际顶尖工具有2-3年差距
+
+#### 嘉立创EDA ⭐⭐⭐⭐
+- **官网**：https://www.lceda.com
+- **2026年新能力**：
+  - 自然语言选型：输入功能描述，推荐合适元器件
+  - AI智能建库：导入器件手册自动创建符号+封装
+  - 原理图辅助设计：基于大模型的电路建议
+  - 集成ERC/DRC/DFM验证工具
+- **企业版特色**：
+  - 团队协作
+  - 问题前置到设计阶段
+  - 与LCSC元器件商城深度集成
+- **用户规模**：全球最大EDA用户群之一
+
+### 芯片级EDA工具
+
+#### Synopsys DSO.ai ⭐⭐⭐⭐⭐
+- **定位**：AI驱动的芯片物理设计自动化
+- **核心技术**：强化学习
+- **主要能力**：
+  - 自动探索布局布线设计空间
+  - 优化PPA（性能、功耗、面积）
+  - 时序收敛优化
+  - 自动识别关键路径
+- **效果**：设计周期缩短30-50%，PPA优化提升10-20%
+- **用户**：Intel、NVIDIA、Qualcomm等头部芯片公司
+
+#### Cadence Cerebrus ⭐⭐⭐⭐⭐
+- **定位**：AI辅助的全流程芯片设计
+- **主要能力**：
+  - 智能布局规划
+  - 自动时钟树综合优化
+  - 布线资源智能分配
+  - 设计空间探索
+- **集成**：与Cadence全流程工具深度集成
+- **效果**：工程效率提升2-3倍
+
+#### 华大九天 ⭐⭐⭐
+- **定位**：国产全流程EDA工具
+- **AI能力**：正在逐步引入AI辅助
+- **主要工具**：
+  - 模拟电路设计
+  - 平板显示设计
+  - 晶圆制造工具
+- **差距**：AI能力与国际顶尖仍有差距
+
+---
+
+## AI辅助设计评审详解
+
+### 传统评审 vs AI评审
+
+| 维度 | 传统评审 | AI评审 |
+|------|----------|--------|
+| **DRC** | 基于规则的静态检查 | 规则+AI预测潜在问题 |
+| **信号完整性** | 手动仿真验证 | AI预测+自动优化建议 |
+| **EMC/EMI** | 经验+后期测试 | AI预判+设计阶段优化 |
+| **DFM** | 人工对照检查表 | AI自动分析+建议 |
+| **热分析** | 后仿真 | AI预测+布局优化 |
+| **评审时间** | 数天到数周 | 数小时 |
+| **可追溯性** | 人工记录 | 自动生成评审报告 |
+
+### DRC（设计规则检查）
+
+#### 传统DRC
+- 基于制造厂商提供的规则文件
+- 检查线宽、线距、孔径等几何参数
+- 只能发现明确的违规，无法预测潜在问题
+
+#### AI增强DRC
+- **预测性检查**：基于历史数据预测可能的制造问题
+- **上下文感知**：理解设计意图，区分关键/非关键违规
+- **自动修复建议**：不仅报告问题，还给出修复方案
+- **持续学习**：从制造反馈中学习，更新检查规则
+
+**代表工具**：
+- Quilter.ai：自动DRC + 修复建议
+- 嘉立创EDA：集成DRC + DFM分析
+- Cadence Cerebrus：智能DRC优先级排序
+
+### 信号完整性（SI）评审
+
+#### AI在SI领域的应用
+
+1. **串扰预测**
+   - 传统：需要完整3D电磁仿真，耗时数小时
+   - AI：基于几何特征快速预测串扰水平，秒级响应
+
+2. **反射分析**
+   - 传统：需要S参数仿真
+   - AI：基于走线拓扑自动识别阻抗不连续点
+
+3. **衰减预测**
+   - 传统：需要传输线仿真
+   - AI：根据走线长度、介质、频率预测衰减
+
+4. **自动优化建议**
+   - 调整走线间距
+   - 建议参考平面层叠
+   - 推荐端接方案
+
+**代表工具**：
+- Quilter.ai：内置SI预测引擎
+- Cadence Sigrity + AI：信号完整性仿真+AI优化
+- Ansys SIwave + ML：机器学习加速仿真
+
+### EMC/EMI评审
+
+#### AI辅助EMC评审
+
+1. **辐射热点预测**
+   - 基于电流回路分析预测辐射源
+   - 识别高速信号回流路径不连续
+
+2. **自动屏蔽建议**
+   - 推荐屏蔽罩位置
+   - 建议滤波电容放置
+
+3. **接地策略优化**
+   - 分析接地方案
+   - 建议分割/统一地平面策略
+
+4. **预合规检查**
+   - 预测EMC测试结果
+   - 提前识别可能的不合规项
+
+**现状**：
+- EMC领域的AI应用相对滞后
+- 主要因为EMC问题复杂，变量多
+- 目前更多是辅助分析，还无法完全自动化
+
+### DFM（可制造性分析）
+
+#### AI在DFM领域的应用
+
+1. **焊接缺陷预测**
+   - 基于焊盘设计预测虚焊/桥接风险
+   - 自动建议焊盘优化
+
+2. **元件摆放优化**
+   - 考虑贴片机限制
+   - 优化元件方向便于自动贴片
+
+3. **钻孔优化**
+   - 减少钻头更换次数
+   - 优化钻孔顺序
+
+4. **成本预估**
+   - 基于设计特征预估制造成本
+   - 建议降本方案
+
+**代表工具**：
+- 嘉立创EDA：集成DFM检查
+- Quilter.ai：DFM自动优化
+- Valor（Mentor）：DFM分析+AI建议
+
+### 热分析
+
+#### AI辅助热设计
+
+1. **热点预测**
+   - 基于功率分布预测PCB温度场
+   - 识别过热区域
+
+2. **散热方案建议**
+   - 推荐散热过孔布局
+   - 建议铜皮面积
+   - 推荐散热器规格
+
+3. **布局优化**
+   - 热源分散布局建议
+   - 敏感器件远离热源
+
+**现状**：
+- 热分析的AI应用还在早期
+- 主要依靠传统CFD仿真
+- AI可用于快速估算和布局建议
+
+---
+
+## LLM辅助芯片设计
+
+### RTL代码生成
+
+#### 当前能力
+
+| 工具/模型 | 能力 | 成熟度 |
+|-----------|------|--------|
+| GPT-4/Qwen | 简单模块生成 | 中 |
+| ChipNeMo（NVIDIA） | 芯片领域专用LLM | 中高 |
+| RTLCoder | 开源RTL代码生成 | 中 |
+| 内部微调模型 | 企业专用RTL生成 | 高 |
+
+#### 应用场景
+
+1. **模块模板生成**
+   - 输入：接口描述 + 功能需求
+   - 输出：Verilog/VHDL模块框架
+
+2. **验证环境生成**
+   - 自动生成testbench
+   - 生成覆盖率驱动的测试用例
+
+3. **代码补全**
+   - IDE集成的RTL代码补全
+   - 基于上下文的智能建议
+
+4. **文档生成**
+   - 从RTL生成设计文档
+   - 自动生成注释
+
+#### 局限性
+
+- **复杂逻辑**：超过500行的复杂模块仍需人工
+- **时序约束**：LLM难以理解时序要求
+- **验证完备性**：生成的验证用例无法保证覆盖所有边界
+- **安全关键**：汽车/航空芯片需要人工严格验证
+
+### 验证用例生成
+
+#### AI在验证领域的应用
+
+1. **Testbench生成**
+   - 基于DUT接口自动生成框架
+   - 生成激励/监测组件
+
+2. **覆盖率驱动测试**
+   - 分析覆盖率空洞
+   - 自动生成针对性的测试用例
+
+3. **断言生成**
+   - 从规范文档提取要求
+   - 自动生成SVA断言
+
+4. **回归测试优化**
+   - 智能选择最小回归测试集
+   - 优化仿真资源分配
+
+**代表工具**：
+- Synopsys Verdi + AI：调试辅助
+- Cadence JedAI：验证优化
+- 自研微调模型：企业专用
+
+---
+
+## Agentic EDA趋势
+
+### EDA自动化等级
+
+参考自动驾驶分级概念：
+
+| 等级 | 名称 | 描述 | 代表 |
+|------|------|------|------|
+| L0 | 纯手工 | 完全人工操作 | 传统EDA |
+| L1 | 辅助 | 单点AI辅助（如自动布线） | Altium自动布线 |
+| L2 | 部分自动 | 多步骤AI辅助，人做决策 | 当前主流AI EDA |
+| L3 | 有条件自主 | AI自主完成，人审核确认 | Agentic EDA（兴起中） |
+| L4 | 高度自主 | AI完成绝大部分工作 | 实验阶段 |
+| L5 | 完全自主 | 端到端全自动 | 尚未实现 |
+
+### Agentic EDA的特征
+
+1. **自主规划**
+   - 理解设计意图后自主制定设计方案
+   - 多步骤任务的自主分解和执行
+
+2. **工具调用**
+   - 自主调用EDA工具链
+   - 根据中间结果调整策略
+
+3. **迭代优化**
+   - 自动检测问题并修复
+   - 多轮迭代直到满足要求
+
+4. **人机协作**
+   - 关键决策点请求人工确认
+   - 异常情况自动上报
+
+### 2025-2026关键转折
+
+- **技术成熟度**：LLM能力达到理解复杂设计规范的水平
+- **工具集成**：EDA厂商纷纷推出AI Agent接口
+- **用户接受度**：工程师开始习惯与AI协作
+- **商业模式**：按设计任务收费的新模式出现
+
+---
+
+## 国内外工具对比
+
+### 板级EDA对比
+
+| 工具 | 国家 | AI能力 | 生态集成 | 价格 | 推荐度 |
+|------|------|--------|----------|------|--------|
+| Quilter.ai | 美国 | ⭐⭐⭐⭐⭐ | 中 | 高 | 高速/复杂板 |
+| Flux.ai | 美国 | ⭐⭐⭐⭐ | 高 | 中 | 教育/小团队 |
+| 华秋AI EDA | 中国 | ⭐⭐⭐ | 高 | 低 | 国产替代 |
+| 嘉立创EDA | 中国 | ⭐⭐⭐⭐ | 很高 | 低 | 性价比首选 |
+| Altium | 澳大利亚 | ⭐⭐ | 高 | 很高 | 传统强项 |
+| KiCad | 开源 | ⭐ | 中 | 免费 | 开源爱好者 |
+
+### 芯片级EDA对比
+
+| 工具 | 国家 | AI能力 | 主要优势 |
+|------|------|--------|----------|
+| Synopsys DSO.ai | 美国 | ⭐⭐⭐⭐⭐ | 物理设计优化 |
+| Cadence Cerebrus | 美国 | ⭐⭐⭐⭐⭐ | 全流程集成 |
+| 华大九天 | 中国 | ⭐⭐ | 国产替代 |
+| 中国电科SUNV-EDA | 中国 | ⭐⭐ | 军工应用 |
+| Mentor（Siemens） | 德国/美国 | ⭐⭐⭐ | 验证强项 |
+
+### 差距分析
+
+**国产EDA与国际顶尖的差距**：
+- **时间差距**：约2-3年
+- **核心差距**：
+  - AI算法积累不足
+  - 大规模设计数据缺乏
+  - 先进制程支持有限
+- **追赶优势**：
+  - 政策支持力度大
+  - 本土市场需求旺盛
+  - 开源生态发展迅速
+
+---
+
+## 最佳实践建议
+
+### 选型建议
+
+#### 按项目类型
+
+| 项目类型 | 推荐工具 | 理由 |
+|----------|----------|------|
+| 简单IoT设备 | 嘉立创EDA + Quilter | 快速+低成本 |
+| 消费电子 | Flux.ai / Quilter | 协作+质量 |
+| 高速数字板 | Quilter.ai | SI/PI优化 |
+| 汽车电子 | Cadence/Altium + AI辅助 | 可靠性优先 |
+| 芯片设计 | Synopsys/Cadence | 业界标准 |
+
+#### 按团队规模
+
+| 团队规模 | 推荐方案 |
+|----------|----------|
+| 个人/学生 | KiCad + AI辅助工具 |
+| 3-5人小团队 | Flux.ai / 嘉立创EDA |
+| 10-50人团队 | Quilter.ai + 嘉立创 |
+| 大型企业 | Cadence/Synopsys + 自研AI |
+
+### 工作流建议
+
+#### AI辅助设计评审最佳实践
+
+1. **设计前**
+   - 明确设计约束（成本、性能、可靠性）
+   - 选择合适的AI工具
+   - 准备设计规范文档
+
+2. **设计中**
+   - 利用AI进行方案探索
+   - 实时运行DRC检查
+   - AI预测SI/PI问题
+
+3. **评审阶段**
+   - AI自动评审 + 人工审核
+   - 重点关注AI标记的问题
+   - 生成评审报告
+
+4. **迭代优化**
+   - 根据AI建议优化设计
+   - 重新运行评审验证
+   - 记录经验反馈给AI
+
+#### 人工评审重点
+
+AI评审不能完全替代人工，以下方面需要人工重点关注：
+
+1. **设计意图**：AI可能误解设计需求
+2. **安全余量**：关键参数的安全裕度
+3. **可靠性**：长期工作条件下的可靠性
+4. **成本优化**：综合成本的权衡决策
+5. **供应链**：元器件的可获得性和生命周期
+
+### Prompt工程
+
+#### 高效使用AI辅助设计的Prompt技巧
+
+1. **明确上下文**
+   ```
+   我需要设计一个STM32F4的最小系统板，工作温度-20~70°C，
+   供电3.3V，需要引出UART/SPI/I2C接口...
+   ```
+
+2. **分步骤提问**
+   ```
+   第1步：请推荐合适的电源方案
+   第2步：基于此方案，设计电源电路
+   第3步：检查此电路的EMC风险
+   ```
+
+3. **提供约束**
+   ```
+   成本<50元，PCB面积<50x50mm，4层板，
+   需要过CE认证...
+   ```
+
+4. **要求解释**
+   ```
+   请解释为什么推荐这个方案，有什么优缺点？
+   与备选方案相比如何？
+   ```
+
+---
+
+## 风险与局限
+
+### 当前局限
+
+1. **可解释性差**
+   - AI给出的建议难以追溯依据
+   - 难以满足安全认证的审计要求
+
+2. **训练数据偏差**
+   - AI可能继承历史设计的缺陷
+   - 对新工艺/新材料缺乏经验
+
+3. **安全关键领域受限**
+   - 汽车（ISO 26262）要求完整验证链
+   - 航空（DO-254）需要可追溯设计过程
+   - 医疗（IEC 62304）需要严格文档
+
+4. **知识产权风险**
+   - AI生成的设计是否侵权？
+   - 训练数据中的专利问题
+
+### 缓解策略
+
+1. **人机协作**
+   - AI作为助手，人做最终决策
+   - 关键节点人工审核
+
+2. **渐进采用**
+   - 从简单项目开始
+   - 逐步扩大AI应用范围
+
+3. **建立规范**
+   - 制定AI辅助设计规范
+   - 明确人工审核清单
+
+4. **持续学习**
+   - 积累AI使用经验
+   - 建立企业内部最佳实践
+
+---
+
+## 参考资料
+
+### 工具官网
+- Quilter.ai: https://www.quilter.ai
+- Flux.ai: https://www.flux.ai
+- 华秋EDA: https://www.huqiu.com
+- 嘉立创EDA: https://www.lceda.com
+- Synopsys: https://www.synopsys.com
+- Cadence: https://www.cadence.com
+
+### 技术文章（微信公众号）
+- "华秋电子发布国内首款AI EDA工具!开启硬件设计Agent时代" - 愉悦资本
+- "AI开始'造硬件'了:自然语言生成电路,大模型重写电子设计" - 天天AI研习社
+- "Agentic EDA 黎明:从 AI 辅助到 AI 自主的芯片设计革命" - 麒芯说AI
+- "让大模型真正懂电路:硬件 AI 大模型全流程工程化开发指南" - 万星智库
+- "vibe PCB来了?关注这家AI公司" - 橙子随记
+- "让设计更快,让研发更稳!嘉立创EDA企业级解决方案正式发布" - 嘉立创科技
+
+### 行业报告
+- "别吹了!现在的AI硬件设计工具,90%都是玩具" - AI硬件未来眼
+- "AI越火,PCB越吃香!2026年最值得入局的硬核高薪赛道" - Layout日记
+
+---
+
+## 附录：术语表
+
+| 术语 | 全称 | 含义 |
+|------|------|------|
+| EDA | Electronic Design Automation | 电子设计自动化 |
+| DRC | Design Rule Check | 设计规则检查 |
+| ERC | Electrical Rule Check | 电气规则检查 |
+| DFM | Design for Manufacturing | 可制造性设计 |
+| SI | Signal Integrity | 信号完整性 |
+| PI | Power Integrity | 电源完整性 |
+| EMC | Electromagnetic Compatibility | 电磁兼容性 |
+| EMI | Electromagnetic Interference | 电磁干扰 |
+| RTL | Register Transfer Level | 寄存器传输级 |
+| PPA | Power, Performance, Area | 功耗、性能、面积 |
+| LLM | Large Language Model | 大语言模型 |
+| RL | Reinforcement Learning | 强化学习 |
+| DUT | Device Under Test | 被测设备 |
+| SVA | SystemVerilog Assertions | SystemVerilog断言 |
+
+---
+
+*本文档持续更新，最后修改：2026-06-11*

AI工程/GSD_Core_上下文工程框架.md

@@ -0,0 +1,173 @@
+# GSD Core - AI 编码上下文工程与规范驱动开发框架
+
+> **GitHub**: https://github.com/open-gsd/gsd-core
+> **npm**: `@opengsd/gsd-core`
+> **License**: MIT
+> **Slogan**: Git. Ship. Done.
+> **研究日期**: 2026-06-07
+
+---
+
+## 一句话总结
+
+GSD Core 是一套**上下文工程（Context Engineering）+ 规范驱动开发**框架，通过**全新上下文子代理（fresh-context subagent）** 架构解决 AI 编码中「上下文腐化」问题，让 Claude Code、Cursor、Codex 等 AI 编程工具在大型项目中保持高质量输出。
+
+## 解决的核心问题：上下文腐化（Context Rot）
+
+AI 编码会话随着对话轮次增加，上下文窗口逐渐被填满。模型不会报错，但输出质量**静默下降**：
+- 开始 contradicts 早期决策
+- 代码风格偏离初始约定
+- 计划忽略早期明确的需求
+- 臆造之前正确记忆的文件名/函数签名
+
+这不是 bug，是 Transformer 注意力机制在长序列上的**固有特性**——信噪比随窗口填充而劣化。
+
+## 核心方案：全新上下文子代理
+
+**核心洞察**：编码会话中大部分工作（研究、规划、编写、验证）不需要在主上下文中进行。
+
+架构设计：
+- **主会话（编排器）**：不碰源文件，只负责派发代理、收集结果、更新状态。上下文缓慢增长。
+- **子代理**：每个子代理以**干净 200k token 上下文**启动，只接收当前任务所需上下文，完成后终止。
+
+```
+主会话（轻量编排器）
+  ├── Researcher Agent (200k fresh context)
+  ├── Planner Agent (200k fresh context)  
+  ├── Plan-Checker Agent (200k fresh context)
+  ├── Executor Agent × N (200k fresh context, 并行)
+  └── Verifier Agent (200k fresh context)
+```
+
+## 5阶段循环（Phase Loop）
+
+每个里程碑通过重复的 5 步循环推进：
+
+```
+Discuss → [UI Design] → Plan → Execute → Verify → Ship
+```
+
+### 1. Discuss（讨论）
+- 在规划前捕获实现决策（用什么库、错误处理策略、边界情况）
+- 输出 `CONTEXT.md`（结构化决策记录）
+- 几分钟对话避免几小时返工
+
+### 2. UI Design（可选）
+- 视觉相关阶段可选 `/gsd-ui-phase`
+- 输出 `UI-SPEC.md`（布局、交互、视觉行为的设计契约）
+
+### 3. Plan（规划）
+- 3个全新上下文子代理依次运行：
+  - **Researcher** → 调研生态，输出 `RESEARCH.md`
+  - **Planner** → 读研究+CONTEXT，输出 `PLAN.md`
+  - **Plan-Checker** → 验证计划完整、一致、在范围内
+- 计划按依赖波次排列，支持并行执行
+
+### 4. Execute（执行）
+- 每个 Executor 以 200k 干净上下文启动
+- 只加载：项目摘要 + 阶段上下文 + 研究 + 具体 PLAN.md
+- 原子提交，每 commit 对应一个计划任务
+- 按波次并行，前波完成后启动后波
+
+### 5. Verify（验证）
+- 不只是测试，检查：
+  - 需求覆盖率（REQ-ID 是否都处理了）
+  - 决策覆盖率（CONTEXT.md 的决策是否落地了）
+  - 整体阶段目标对齐
+- 输出 `VERIFICATION.md` + 修复计划（如有偏差）
+
+### 6. Ship（交付）
+- 创建 PR，归档阶段产物
+- 更新 `STATE.md` 标记阶段完成
+- 开始下一个阶段循环
+
+## 关键文件结构
+
+```
+.planning/
+├── STATE.md           # 项目当前状态（里程碑/阶段/进度）——系统脊梁
+├── phases/
+│   ├── CONTEXT.md     # 讨论阶段的实现决策
+│   ├── RESEARCH.md    # 调研发现
+│   ├── PLAN.md        # 具体执行计划（按波次）
+│   ├── UI-SPEC.md     # UI 设计契约（可选）
+│   └── VERIFICATION.md # 验证报告
+ROADMAP.md             # 项目路线图
+```
+
+## 支持平台
+
+Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf 等。
+
+## 快速开始
+
+```bash
+npx @opengsd/gsd-core@latest
+# 选择运行时和安装方式
+/gsd-new-project
+```
+
+也提供轻量模式：
+- `/gsd-quick` — 不需要完整阶段循环的快速任务
+- `/gsd-fast` — 更轻量的即时操作
+
+## 三大支柱
+
+1. **Fresh-context subagents** — 每个子代理干净启动，结构性地解决上下文腐化
+2. **Spec-driven development** — 执行前产出结构化产物（CONTEXT/RESEARCH/PLAN/VERIFICATION），代理精确执行
+3. **Meta-prompting** — 代理定义本身是精心工程化的 prompt，编码了领域知识
+
+## 与 Trellis 对比
+
+| 维度 | GSD Core | Trellis |
+|------|----------|---------|
+| **核心理念** | 上下文工程 + 子代理架构 | 规范持久化 + 记忆 |
+| **解决痛点** | 上下文腐化（质量随窗口填充下降） | AI 每次从零开始（无记忆） |
+| **架构** | 主会话编排 + fresh-context subagents | 4阶段循环（Plan→Implement→Verify→Finish） |
+| **记忆机制** | 文件系统（.planning/ 目录） | .trellis/workspace/ journal |
+| **平台支持** | 10+ 平台 | 14+ 平台 |
+| **License** | MIT | AGPL-3.0 |
+| **适用规模** | 中大型复杂项目（上下文腐化严重时收益最大） | 个人/团队通用 |
+| **轻量模式** | /gsd-quick, /gsd-fast | 无 |
+| **验证深度** | 需求+决策+目标三重验证 | lint+type-check+测试 |
+
+## 评价
+
+### ✅ 优点
+- **深刻理解了 AI 编码的根本问题**（上下文腐化是 Transformer 固有特性，不是 workaround 能解决的）
+- fresh-context subagent 是**结构性解决方案**，不是权宜之计
+- 5阶段循环设计严谨，每步都有明确存在的理由
+- 验证环节不仅是测试，而是需求+决策+目标三重覆盖
+- MIT 许可证友好
+- 诚实承认 trade-off（简单任务不需要用完整循环）
+
+### ⚠️ 注意
+- 对简单任务有**流程开销**（官方也承认）
+- 子代理启动延迟比单会话编辑慢
+- 需要一定学习曲线理解阶段循环概念
+- 最适合**中大型复杂项目**，小项目用 /gsd-quick 即可
+
+### 📊 项目成熟度
+- 完整文档体系（教程/指南/参考/概念）
+- CI/CD 测试覆盖
+- 活跃的社区（Discord + 多语言 README）
+- 多平台支持
+- 有 CLI 工具和完整命令体系
+
+## 核心洞察（值得记住）
+
+> "The model is not forgetting — it never 'remembered' in the human sense. It is weighting relevance across a finite window, and as that window fills with accumulated noise, signal-to-noise degrades."
+
+> "An executor that runs with 180k tokens of accumulated session history is a degraded executor. An executor that starts clean and reads only what its plan requires is an executor operating at full capacity."
+
+## 相关链接
+
+- [GitHub](https://github.com/open-gsd/gsd-core)
+- [npm](https://www.npmjs.com/package/@opengsd/gsd-core)
+- [Discord](https://discord.gg/mYgfVNfA2r)
+- [上下文工程详解](https://github.com/open-gsd/gsd-core/blob/next/docs/explanation/context-engineering.md)
+- [阶段循环详解](https://github.com/open-gsd/gsd-core/blob/next/docs/explanation/the-phase-loop.md)
+
+---
+
+*研究归档：2026-06-07 | 路径：/obsidian/AI工程/GSD_Core_上下文工程框架.md*

AI工程/HyperFrames_HTML视频引擎研究.md

@@ -0,0 +1,318 @@
+# HyperFrames — HTML 视频引擎完全研究
+
+> 研究日期：2026-06-01
+> 官网：https://www.hyperframes.net/zh
+> GitHub：https://github.com/heygen-com/hyperframes
+> 文档：https://hyperframes.mintlify.app/introduction
+> 开发商：HeyGen
+> 许可证：MIT（开源引擎）
+
+---
+
+## 一句话概括
+
+**用 HTML 写视频。** HyperFrames 是 HeyGen 出品的开源 HTML-to-video 框架，将 HTML composition 直接渲染成 MP4，专为 AI Agent 驱动的视频生产设计。
+
+---
+
+## 核心理念
+
+- 视频的「源代码」就是 HTML 文件
+- 用 `data-start`、`data-duration`、`data-track-index` 等 data attribute 定义时间线
+- 动画用熟悉的 GSAP、Lottie、CSS 等任何可 seek 到指定帧的运行时
+- **确定性渲染**：同一输入 → 完全相同的输出帧，可 CI 化、可回归测试
+- 不需要 React，不需要时间线编辑器，不需要专有格式
+
+---
+
+## 架构与包
+
+| 包 | 作用 |
+|---|---|
+| `@hyperframes/core` | 类型定义、HTML 解析、composition lint |
+| `@hyperframes/engine` | seek 驱动的帧捕获引擎（headless Chrome） |
+| `@hyperframes/producer` | 捕获 + FFmpeg 编码的完整流水线 |
+| `@hyperframes/studio` | 可视化编辑器 UI |
+| `hyperframes (CLI)` | 命令行工具，默认非交互，适合 Agent 自动化 |
+
+### 渲染管线
+
+```
+HTML Composition → headless Chrome 逐帧捕获 (beginFrame API) → FFmpeg 编码 → MP4/MOV/WebM
+```
+
+渲染模式：
+- **Local Mode**：本地 Puppeteer + 系统 FFmpeg，开发迭代快
+- **Docker Mode**：确定性输出，固定 Chrome 版本 + 字体集，适合 CI/CD
+
+---
+
+## Composition 模型
+
+### 项目结构
+
+```
+project/
+├── index.html          # 根 composition（视频入口）
+├── compositions/       # 子 composition（可复用片段）
+│   ├── intro-anim.html
+│   ├── caption-overlay.html
+│   └── outro-title.html
+├── assets/             # 媒体素材
+│   ├── video.mp4
+│   ├── music.mp3
+│   └── logo.png
+└── meta.json           # 项目元数据
+```
+
+### 最小示例
+
+```html
+<div id="root" data-composition-id="demo"
+     data-start="0" data-width="1920" data-height="1080">
+
+  <h1 id="title" class="clip"
+      data-start="1" data-duration="4" data-track-index="1"
+      style="font-size: 72px; color: white;">
+    Welcome to Hyperframes
+  </h1>
+
+  <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
+  <script>
+    const tl = gsap.timeline({ paused: true });
+    tl.from("#title", { opacity: 0, y: -50, duration: 1 }, 0);
+    window.__timelines = window.__timelines || {};
+    window.__timelines["demo"] = tl;
+  </script>
+</div>
+```
+
+### 三条核心规则
+
+1. **根元素**必须有 `data-composition-id`、`data-width`、`data-height`
+2. **定时元素**需要 `data-start`、`data-duration`、`data-track-index` 和 `class="clip"`
+3. **GSAP timeline** 必须用 `{ paused: true }` 创建，注册到 `window.__timelines`
+
+### 嵌套 Composition
+
+- **外部文件**：用 `data-composition-src` 引用，内容包在 `<template>` 里
+- **内联**：直接在父 composition 里定义
+- 框架自动管理子 composition 的时间线嵌套
+
+### 变量系统
+
+- 在 `<html>` 上用 `data-composition-variables` 声明变量（id + type + default）
+- 在实例上用 `data-variable-values` 传值
+- 在脚本里用 `window.__hyperframes.getVariables()` 读取
+- 同一个子 composition 可以多次嵌入，每次不同参数
+
+---
+
+## GSAP 动画
+
+HyperFrames 使用 GSAP 作为主要动画运行时。
+
+### 关键要点
+
+- Timeline 必须 `{ paused: true }`，框架控制播放
+- 通过 position 参数（第3个参数）做绝对时间定位
+- 只能做视觉属性动画，**不能**控制媒体播放
+- 支持的方法：`to()`、`from()`、`fromTo()`、`set()`
+- **Timeline 时长 = Composition 时长**（最长的动画决定总时长）
+
+### 常见陷阱
+
+- ❌ 在脚本里 play/pause/seek 媒体元素
+- ❌ 创建非 paused 的 timeline
+- ❌ 直接在 `<video>` 元素上动画 width/height（用 div 包装）
+- ❌ 手动嵌套子 timeline
+
+---
+
+## 渲染配置
+
+### 输出选项
+
+| 参数 | 可选值 | 默认 |
+|---|---|---|
+| `--format` | mp4, mov, webm, png-sequence | mp4 |
+| `--fps` | 24, 30, 60 | 30 |
+| `--quality` | draft, standard, high | standard |
+| `--workers` | 1-8 或 auto | auto |
+| `--gpu` | NVENC, VideoToolbox, AMF, VAAPI, QSV | off |
+| `--docker` | 确定性渲染 | off |
+| `--hdr` / `--sdr` | HDR 输出控制 | off |
+
+### 环境要求
+
+- **Node.js 22+**
+- **FFmpeg 7.x**
+- Chrome（bundled）
+- Docker（可选，生产渲染推荐）
+
+---
+
+## Agent 集成
+
+这是 HyperFrames 的最大亮点。
+
+### 为什么对 Agent 友好
+
+1. LLM 天生擅长生成 HTML — 不需要学新 DSL
+2. CLI 完全非交互，参数驱动，纯文本输出
+3. 可以从文档、网页、GitHub 仓库等现成内容起步
+4. 支持 Claude Code、Cursor、Gemini CLI、Codex 等 AI 编码 Agent
+
+### Skills 安装
+
+```bash
+npx skills add heygen-com/hyperframes
+```
+
+安装后在 Claude Code 中注册为 slash commands：
+- `/hyperframes` — composition 创作
+- `/hyperframes-cli` — init, lint, preview, render
+- `/hyperframes-media` — TTS、转录、背景移除
+- `/tailwind` — Tailwind v4 样式
+- `/gsap` — GSAP 时间线动画
+- 以及 `/animejs`、`/css-animations`、`/lottie`、`/three`、`/waapi`
+
+### 示例提示词
+
+```
+Using /hyperframes, create a 10-second product intro with a fade-in title over a dark background.
+
+Summarize the attached PDF into a 45-second pitch video using /hyperframes.
+
+Turn this CSV into an animated bar chart race using /hyperframes.
+
+Make a 9:16 TikTok-style hook video about [topic] using /hyperframes.
+```
+
+---
+
+## 使用场景
+
+| 场景 | 描述 |
+|---|---|
+| **文档转视频** | onboarding、release note、帮助中心 → 解释型视频 |
+| **网站转视频** | 产品页、发布文案 → demo、功能讲解 |
+| **仓库转视频** | GitHub README、架构说明 → devrel walkthrough |
+| **数据转视频** | CSV、看板、指标 → 动态图表叙事 |
+| **产品 demo** | 从提示词或 HTML 生成产品演示视频 |
+| **社交媒体内容** | YouTube、TikTok、短视频 |
+
+---
+
+## Catalog 组件库
+
+50+ 开箱即用的 blocks 和 components：
+- 字幕样式（caption-clip-wipe 等）
+- 社交 overlay
+- Shader 转场
+- 数据可视化图表
+- 电影化特效
+
+安装方式：`npx hyperframes add <component-name>`
+
+---
+
+## 定价
+
+### 开源引擎
+- **免费**，本地渲染不限量
+- Docker 渲染也不收费（用自己的基础设施）
+
+### 托管 Studio（hyperframes.net）
+
+| 套餐 | 价格 | 积分/月 | 备注 |
+|---|---|---|---|
+| 入门版 | $29/月（年付 $87） | 500 | 基础功能 |
+| 标准版 | $99/月（年付 $297） | 2,000 | 优先队列 |
+| 高级版 | $199/月（年付 $597） | 8,000 | 最快速度 |
+| 试用 | 免费 | 30 积分 | 新用户 |
+
+积分消耗：4秒视频 = 40积分，15秒视频 = 150积分
+
+免费浏览器工具（视频转换、缩略图、GIF、图片压缩）不扣积分。
+
+---
+
+## Frame Adapters
+
+HyperFrames 通过 Frame Adapter 模式支持多种动画运行时：
+- **GSAP** — 主要推荐
+- **Lottie** — 通过 `window.__hfLottie` 注册
+- **CSS Animations** — 原生支持
+- **Three.js** — 3D 场景
+- **WAAPI** — Web Animations API
+- **Anime.js** — 轻量动画库
+
+只要运行时能 seek 到某一帧，就能通过适配器接入渲染链路。
+
+---
+
+## 竞品对比思考
+
+| 维度 | HyperFrames | Remotion | After Effects |
+|---|---|---|---|
+| 视频定义方式 | HTML + data attributes | React + JS | 时间线 GUI |
+| Agent 适配 | ⭐⭐⭐ 原生设计 | ⭐⭐ 需 React | ⭐ 无法自动化 |
+| 确定性渲染 | ✅ | ✅ | ❌ |
+| 学习曲线 | 低（会 HTML 就行） | 中（需 React） | 高 |
+| 动画运行时 | GSAP/Lottie/CSS/任意 | CSS/React 状态 | 内置 |
+| 渲染依赖 | Chrome + FFmpeg | Chrome + FFmpeg | Adobe |
+| 开源 | ✅ MIT | ✅ MIT | ❌ |
+
+---
+
+## 评价
+
+**优点：**
+- 概念非常清晰 — HTML 即视频，零新 DSL 学习成本
+- Agent 友好设计是杀手级特性，开箱即用的 skills 系统
+- 确定性渲染让视频也能 CI/CD
+- HeyGen 背书，项目活跃
+- 50+ Catalog 组件开箱即用
+
+**局限：**
+- 适合结构化、信息展示类视频，不适合复杂真人特效
+- 托管 Studio 定价偏贵（相比自建）
+- 依赖 Chrome 逐帧捕获，渲染速度不如原生视频引擎
+- 生态还比较新，社区资源有限
+
+**适用人群：**
+- 需要批量生成视频的开发者团队
+- 想用 AI Agent 自动化视频生产的人
+- DevRel、产品营销团队
+- 数据可视化视频制作者
+
+---
+
+## 快速上手
+
+```bash
+# 1. 初始化项目
+npx hyperframes init my-video
+cd my-video
+
+# 2. 浏览器预览
+npx hyperframes preview
+
+# 3. 渲染 MP4
+npx hyperframes render --output output.mp4
+
+# 4. 环境检查
+npx hyperframes doctor
+```
+
+---
+
+## 相关链接
+
+- 官网：https://www.hyperframes.net/zh
+- GitHub：https://github.com/heygen-com/hyperframes
+- 文档：https://hyperframes.mintlify.app/introduction
+- Catalog：https://hyperframes.mintlify.app/catalog
+- 定价：https://www.hyperframes.net/zh/pricing
+- 使命：https://www.hyperframes.net/zh/mission

AI工程/JetLinks物联网平台深度研究.md

@@ -0,0 +1,160 @@
+# JetLinks 物联网平台深度研究
+
+> 研究日期：2026-06-12
+> 来源：GitHub 官方仓库 + 官网
+
+## 基本信息
+
+| 项目 | 内容 |
+|---|---|
+| **GitHub** | https://github.com/jetlinks/jetlinks-community |
+| **Stars** | 6.5k ⭐ |
+| **Forks** | 1.9k |
+| **当前版本** | 2.3（社区版）/ 2.11（分支） |
+| **公司** | 重庆，深圳设研发中心 |
+| **许可证** | Apache 2.0 |
+| **官网** | https://www.jetlinks.cn |
+| **文档** | 语雀托管 |
+
+## 技术架构
+
+### 核心技术栈
+
+- **Java 8+**, Spring Boot 2.7.x
+- **Spring WebFlux** — 全响应式 Web（非传统 Servlet）
+- **R2DBC** — 响应式关系型数据库驱动
+- **Reactor** — 响应式编程框架
+- **Netty + Vert.x** — 高性能网络编程
+- **PostgreSQL** — 业务数据存储
+- **ElasticSearch / TDengine** — 时序数据存储
+
+### 模块结构
+
+```
+jetlinks-community
+├── jetlinks-components/          # 核心组件层
+│   ├── network-component         # 网络：MQTT/TCP/UDP/CoAP/HTTP
+│   ├── protocol-component        # 协议适配
+│   ├── gateway-component         # 消息网关/设备接入
+│   ├── rule-engine-component     # 规则引擎
+│   ├── things-component          # 物模型
+│   ├── elasticsearch-component   # ES 时序存储
+│   ├── tdengine-component        # TDengine 集成
+│   └── notify-component          # 通知（短信/邮件）
+├── jetlinks-manager/             # 业务管理层
+│   ├── authentication-manager    # 用户/权限
+│   ├── device-manager            # 设备管理
+│   ├── network-manager           # 网络组件管理
+│   ├── rule-engine-manager       # 规则引擎管理
+│   ├── visualization-manager     # 数据可视化
+│   └── notify-manager            # 通知管理
+└── simulator/                    # 设备模拟器
+```
+
+## 核心能力
+
+### 协议支持
+
+| 协议 | 支持 | 水利适用 |
+|---|---|---|
+| MQTT | ✅ | ⭐⭐⭐⭐⭐ |
+| TCP | ✅ | ⭐⭐⭐⭐ |
+| UDP | ✅ | ⭐⭐⭐ |
+| CoAP | ✅ | ⭐⭐⭐ |
+| HTTP | ✅ | ⭐⭐⭐ |
+| TLS/DTLS | ✅ | ⭐⭐⭐⭐ |
+| Modbus | ⚠️ 需自研 | 需扩展 |
+| SL651水文规约 | ❌ 无 | **核心缺口** |
+
+### 物模型管理
+
+- 产品(Product) → 物模型(ThingModel)
+  - 属性(Properties): 水位、流量、水温、电量
+  - 功能(Functions): 开闸、关闸、重启
+  - 事件(Events): 超水位告警、断电告警
+- 设备(Device) → 绑定产品 → 继承物模型
+- 支持设备影子（离线缓存指令）
+
+### 规则引擎
+
+- 支持多种规则模型（阈值告警、场景联动、自定义）
+- **ReactorQL**：用 SQL 描述流式数据处理
+- 告警 → 通知（短信/邮件/Webhook）
+- 联动：水位超限 → 自动开闸
+
+### 数据存储方案
+
+- **PostgreSQL**：设备信息、用户权限、配置等业务数据
+- **ElasticSearch**：属性时序数据、设备日志
+- **TDengine**（可选）：高性能时序写入
+
+## 部署
+
+### Docker 一键部署
+```bash
+cd docker/run-all
+docker-compose up -d
+# 访问 http://localhost:9000
+```
+
+### 依赖组件
+- PostgreSQL
+- ElasticSearch（或 TDengine）
+- Redis
+- MQTT Broker（内置）
+
+### 硬件要求
+- 最低：2C4G（开发/测试）
+- 生产：4C8G 起步，数据量大建议 8C16G
+
+## 社区版 vs 企业版
+
+| 功能 | 社区版 | 企业版 |
+|---|---|---|
+| 设备接入+管理 | ✅ | ✅ |
+| 物模型 | ✅ | ✅ |
+| 协议适配 | ✅ | ✅ |
+| 规则引擎 | ✅ | ✅ 更强 |
+| 数据可视化 | ✅ 基础 | ✅ 高级大屏 |
+| 多租户 | ⚠️ 基础 | ✅ 完整 |
+| AI 视觉 | ❌ | ✅ |
+| 边缘网关 | ❌ | ✅ |
+| 源码 | ✅ 全开放 | 需购买 |
+
+## 水利场景评估
+
+### 优势
+1. Java 生态，水利行业 Java 开发者多
+2. 响应式架构，高并发性能好
+3. 协议扩展灵活，SL651 可自研接入
+4. 中文文档完善（语雀 + QQ 群）
+5. 模块化设计，按需裁剪
+6. 国产项目，等保合规
+
+### 注意事项
+1. **SL651 需自研**：无现成实现
+2. **响应式学习曲线**：WebFlux + Reactor 有门槛
+3. **社区版文档滞后**
+4. **GIS 能力弱**：需自己集成地图
+5. **前端 Vue 版本较旧**
+
+### 落地路径建议
+1. Docker 部署社区版，跑通 MQTT demo
+2. 开发 SL651 协议包
+3. 对接 TDengine 做时序存储
+4. 前端集成 GIS 地图（天地图/高德）
+5. 开发水利业务大屏
+
+预估：2-3 人团队，MVP 约 2-3 个月
+
+## 竞品对比
+
+| 维度 | JetLinks | ThingsBoard | 自研+TDengine |
+|---|---|---|---|
+| 语言 | Java | Java | 自选 |
+| 学习成本 | 中 | 中 | 高 |
+| 中文文档 | ⭐⭐⭐⭐⭐ | ⭐⭐ | 自己写 |
+| 协议扩展 | 好 | 好 | 完全自由 |
+| 二次开发 | 友好 | 一般 | 完全自由 |
+| 部署复杂度 | 中 | 中 | 高 |
+| 社区规模 | 中（国内） | 大（全球） | 无 |

AI工程/New_API_研究报告.md

@@ -0,0 +1,311 @@
+# New API 研究报告
+
+**研究日期**: 2026-06-09  
+**项目**: QuantumNous/new-api  
+**Stars**: 37,729 ⭐  
+**语言**: Go  
+**最新版本**: v1.0.0-rc.10 (2026-05-26)  
+**官网**: https://www.newapi.ai  
+**文档**: https://docs.newapi.pro  
+
+---
+
+## 📋 项目概述
+
+**New API** 是下一代 LLM 网关和 AI 资产管理系统，是 One API 的增强版本。它将多个 AI 模型提供商统一转换为 OpenAI/Claude/Gemini 兼容格式，提供集中化的模型管理平台。
+
+### 核心定位
+- **AI API 网关**: 聚合多个 AI 提供商，统一接口
+- **企业级管理**: 组织级鉴权、用量统计、成本核算
+- **私有化部署**: 支持 Docker 一键部署
+- **格式转换**: OpenAI ⇄ Claude ⇄ Gemini 互相转换
+
+---
+
+## 🚀 核心功能
+
+### 1. 多协议支持
+- ⚡ **OpenAI Responses API** (最新格式)
+- ⚡ **OpenAI Realtime API** (包括 Azure)
+- ⚡ **Claude Messages API**
+- ⚡ **Google Gemini API**
+- 🔄 **Rerank Models** (Cohere, Jina)
+
+### 2. 智能路由
+- ⚖️ 渠道加权随机
+- 🔄 失败自动重试
+- 🚦 用户级模型限流
+- 💾 缓存命中统计 (OpenAI/Azure/DeepSeek/Claude/Qwen)
+
+### 3. 格式转换
+- OpenAI Compatible ⇄ Claude Messages
+- OpenAI Compatible → Google Gemini
+- Google Gemini → OpenAI Compatible (仅文本)
+- 🔄 思考内容转换 (thinking-to-content)
+
+### 4. 推理努力控制
+**OpenAI 系列**:
+- o3-mini-high/medium/low
+- gpt-5-high/medium/low
+
+**Claude 系列**:
+- claude-3-7-sonnet-thinking
+
+**Gemini 系列**:
+- gemini-2.5-flash-thinking/nothinking
+- gemini-2.5-pro-thinking
+- 支持 -low/-medium/-high 后缀
+
+### 5. 计费与配额
+- ✅ 内部充值和配额分配 (EPay, Stripe)
+- ✅ 按请求/用量/缓存命中率成本核算
+- ✅ 灵活计费策略
+- ✅ 企业客户管理
+
+### 6. 权限管理
+- 🔑 Token 分组
+- 🔒 模型限制
+- 👥 用户管理
+- 🔐 多种登录方式 (Discord/LinuxDO/Telegram/OIDC)
+
+---
+
+## 📡 支持的渠道类型 (50+)
+
+| 渠道类型 | 编号 | 默认 BASE_URL |
+|---------|------|---------------|
+| OpenAI | 1 | https://api.openai.com |
+| Azure | 3 | - |
+| Anthropic | 14 | https://api.anthropic.com |
+| **阿里云 (Ali)** | **17** | **https://dashscope.aliyuncs.com** |
+| 百度文心 | 15/46 | https://aip.baidubce.com |
+| 智谱 | 16/26 | https://open.bigmodel.cn |
+| Gemini | 24 | https://generativelanguage.googleapis.com |
+| Moonshot | 25 | https://api.moonshot.cn |
+| DeepSeek | 43 | - |
+| 火山引擎 | 45 | - |
+| OpenRouter | 20 | https://openrouter.ai/api |
+| Cohere | 34 | https://api.cohere.ai |
+| MiniMax | 35 | https://api.minimax.chat |
+| Mistral | 42 | - |
+| xAI | 48 | - |
+| 更多... | - | - |
+
+---
+
+## 🔗 阿里云百炼对接
+
+### 百炼 OpenAI 兼容接口
+
+阿里云百炼的千问模型支持 OpenAI 兼容接口，只需调整 API Key、BASE_URL 和模型名称。
+
+### 配置信息
+
+**BASE_URL (SDK)**:
+- 北京: `https://dashscope.aliyuncs.com/compatible-mode/v1`
+- 弗吉尼亚: `https://dashscope-us.aliyuncs.com/compatible-mode/v1`
+- 新加坡: `https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1`
+
+**HTTP Endpoint**:
+- 北京: `POST https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions`
+
+### 支持的千问模型
+
+**商业版**:
+- **千问 Max**: qwen3.7-max, qwen3-max, qwen-max
+- **千问 Plus**: qwen3.6-plus, qwen3.5-plus, qwen-plus
+- **千问 Flash**: qwen3.6-flash, qwen3.5-flash, qwen-flash
+- **千问 Coder**: qwen3-coder-plus, qwen3-coder-flash
+- **QwQ**: qwq-plus
+
+**开源版**:
+- qwen3.6-35b-a3b, qwen3.5-397b-a17b, qwen3.5-122b-a10b
+- qwen3-235b-a22b, qwen3-32b, qwen3-30b-a3b, qwen3-14b, qwen3-8b
+
+### New API 对接百炼步骤
+
+1. **部署 New API**
+   ```bash
+   docker run -d --name new-api -p 3000:3000 \
+     -e TZ=Asia/Shanghai \
+     -v ./data:/data \
+     calciumion/new-api:latest
+   ```
+
+2. **添加阿里云渠道**
+   - 进入管理后台 → 渠道管理 → 添加渠道
+   - 选择 **阿里云 (Ali)** 类型 (Channel Type: 17)
+   - 填写 **百炼 API Key**
+   - BASE_URL 默认已填: `https://dashscope.aliyuncs.com`
+   - 选择要启用的模型
+
+3. **创建 Token**
+   - 令牌管理 → 创建令牌
+   - 生成 API Key 供下游应用使用
+
+4. **下游应用调用**
+   ```python
+   from openai import OpenAI
+   
+   client = OpenAI(
+       api_key=***  # New API 生成的 Token
+       base_url="http://localhost:3000/v1",  # New API 地址
+   )
+   ```
+
+### 渠道额外设置
+```json
+{
+    "force_format": true,        // 强制格式化为 OpenAI 格式
+    "thinking_to_content": true, // 将思考内容转为 <think> 标签
+    "proxy": "socks5://xxx"      // 网络代理
+}
+```
+
+---
+
+## 🐳 部署方式
+
+### Docker Compose（推荐）
+
+```yaml
+version: '3.4'
+services:
+  new-api:
+    image: calciumion/new-api:latest
+    container_name: new-api
+    restart: always
+    ports:
+      - "3000:3000"
+    volumes:
+      - ./data:/data
+      - ./logs:/app/logs
+    environment:
+      - SQL_DSN=postgresql://root:123456@postgres:5432/new-api
+      - REDIS_CONN_STRING=redis://:123456@redis:6379
+      - TZ=Asia/Shanghai
+    depends_on:
+      - redis
+      - postgres
+
+  redis:
+    image: redis:latest
+    restart: always
+    command: ["redis-server", "--requirepass", "123456"]
+
+  postgres:
+    image: postgres:15
+    restart: always
+    environment:
+      POSTGRES_USER: root
+      POSTGRES_PASSWORD: 123456
+      POSTGRES_DB: new-api
+    volumes:
+      - pg_data:/var/lib/postgresql/data
+```
+
+### Docker 单容器（SQLite）
+
+```bash
+docker run --name new-api -d --restart always \
+  -p 3000:3000 \
+  -e TZ=Asia/Shanghai \
+  -v ./data:/data \
+  calciumion/new-api:latest
+```
+
+部署后访问: `http://localhost:3000`
+
+---
+
+## 📊 支持的接口
+
+- Chat Interface (Chat Completions)
+- Response Interface (Responses)
+- Image Interface (Image)
+- Audio Interface (Audio)
+- Video Interface (Video)
+- Embedding Interface (Embeddings)
+- Rerank Interface (Rerank)
+- Realtime Conversation (Realtime)
+- Claude Chat
+- Google Gemini Chat
+
+---
+
+## 🌍 多语言支持
+
+- 简体中文
+- 繁体中文
+- English
+- Français
+- 日本語
+
+---
+
+## 🎨 UI 特性
+
+- 现代化界面设计
+- 数据看板（可视化控制台和统计分析）
+- 主题定制（支持 Anthropic/Simple Large 预设）
+- 响应式设计（移动端友好）
+- 暗色模式
+
+---
+
+## 🔐 认证方式
+
+- Discord 授权登录
+- LinuxDO 授权登录
+- Telegram 授权登录
+- OIDC 统一认证
+
+---
+
+## 💡 使用场景
+
+### 个人开发者
+- 统一管理多个 AI 提供商的 API Key
+- 跨平台模型切换
+- 用量追踪
+
+### 企业用户
+- 组织级鉴权和权限管理
+- 成本核算和计费系统
+- 多租户管理
+- 用量统计和分析
+
+### API 转售
+- 支持多租户
+- 配额管理
+- 计费系统 (EPay, Stripe)
+- 缓存优化降低成本
+
+---
+
+## 🔗 相关资源
+
+- **官方文档**: https://docs.newapi.pro
+- **GitHub**: https://github.com/QuantumNous/new-api
+- **Docker Hub**: https://hub.docker.com/r/calciumion/new-api
+- **One API (原版)**: https://github.com/songquanpeng/one-api
+- **百炼文档**: https://help.aliyun.com/zh/model-studio/
+- **Key 工具**: https://github.com/Calcium-Ion/new-api-key-tool
+
+---
+
+## 📝 总结
+
+**New API** 是一个功能强大的 AI API 网关，适合：
+
+1. **个人开发者**: 统一管理多个 AI 提供商的 API Key
+2. **企业用户**: 组织级鉴权、成本核算、用量统计
+3. **API 转售**: 支持多租户、配额管理、计费系统
+
+**百炼对接优势**:
+- 原生支持阿里云渠道 (Channel Type 17)
+- 百炼提供 OpenAI 兼容接口，迁移成本低
+- 千问模型性价比高，适合各种场景
+- 支持缓存统计，可降低成本
+
+**推荐部署方式**: Docker Compose，包含 PostgreSQL + Redis，适合生产环境。

AI工程/R3与LingBot-Map_流式3D重建技术对比.md

@@ -0,0 +1,336 @@
+# R³ 与 LingBot-Map：流式3D重建技术深度对比
+
+> 研究日期：2026-06-12
+> 来源：GitHub README + arXiv 论文摘要
+
+---
+
+## 一、R³：3D Reconstruction via Relative Regression
+
+### 基本信息
+
+| 项目 | 信息 |
+|------|------|
+| 论文 | [arXiv:2605.26519](https://arxiv.org/abs/2605.26519) |
+| GitHub | [KevinXu02/R3](https://github.com/KevinXu02/R3) ⭐ 188 |
+| 作者 | Congrong Xu (西湖大学/密歇根大学), Huachen Gao, Xingyu Chen, Yuliang Xiu, Jun Gao (NVIDIA), Anpei Chen |
+| 参数量 | **372M** |
+| 发布时间 | 2026-05-26 |
+| 许可 | 未明确（仅开放推理代码） |
+| 项目主页 | https://kevinxu02.github.io/r3-site/ |
+
+### 核心问题
+
+传统前馈几何基础模型（如 DUSt3R、MASt3R）依赖**全局坐标系假设**：
+- 网络必须在单一全局帧中回归所有相机位姿
+- 长时间流式重建时，平移量随时间无界增长
+- 必须维护任意时间原点，导致长上下文/流式场景性能下降
+
+### 解决方案：相对回归（Relative Regression）
+
+**核心思想**：不直接预测全局坐标，而是预测**置信度加权的成对相对位姿约束**，再在后处理中组装全局轨迹。
+
+#### 架构设计
+
+```
+输入视频流 → Depth Anything 3 骨干 → 轻量级成对位姿 MLP → 置信度加权相对位姿 → 全局轨迹组装
+```
+
+**两个关键创新**：
+
+1. **轻量级成对位姿 MLP**
+   - 基于 Depth Anything 3 (DA3) 骨干网络
+   - 无循环状态（no recurrent state）
+   - 无 TTT 模块（Test-Time Training）
+   - 无额外 Transformer
+   - 仅通过简单 MLP 预测相邻帧间的相对位姿
+
+2. **单一学习置信度（Single Learned Confidence）**
+   - 每条边（edge）一个置信度值
+   - 解耦为旋转置信度 + 平移置信度
+   - 三重作用：
+     - **训练时**：加权损失函数
+     - **推理时**：指导位姿聚合（pose aggregation）
+     - **运行时**：管理关键帧库（keyframe-bank management）
+
+#### 推理模式
+
+| 模式 | 适用场景 | 说明 |
+|------|---------|------|
+| `test` | 快速测试 | 保留所有 KV 缓存，跳过回退/度量缩放 |
+| `local` | 室内/小覆盖场景 | 默认检查点 r3，短片段局部一致性强 |
+| `long` | 户外/长轨迹 | 使用 r3_long 检查点 |
+| `strided` | 时间稀疏视频 | 跳帧处理 |
+
+#### 检查点
+
+| 名称 | 训练视图数 | 适用场景 | 特点 |
+|------|-----------|---------|------|
+| `r3` | 4–32 | 室内/小覆盖场景 | 论文报告结果，短片段局部一致性强 |
+| `r3_long` | 32–100 | 户外/长轨迹 | 用于 `--mode long` 和 `--mode strided` |
+
+### 性能指标
+
+- **参数量**：372M（约 1B 级模型的 1/3）
+- **推理速度**：20+ FPS
+- **长序列能力**：数千帧（有界内存预算）
+- **精度**：匹配或超越 SOTA 流式方法（位姿估计 + 密集重建）
+
+### 技术栈依赖
+
+- **Depth Anything 3**（字节跳动）：深度估计骨干
+- **CUT3R**：3D 重建基础
+- **STream3R**：流式 3D 重建
+
+### 开源状态
+
+- ✅ 推理代码
+- ✅ 检查点（HuggingFace）
+- ❌ 评估代码（TODO）
+- ❌ 训练代码（TODO）
+
+---
+
+## 二、LingBot-Map：Geometric Context Transformer
+
+### 基本信息
+
+| 项目 | 信息 |
+|------|------|
+| 论文 | [arXiv:2604.14141](https://arxiv.org/abs/2604.14141) |
+| GitHub | [Robbyant/lingbot-map](https://github.com/Robbyant/lingbot-map) ⭐ 7166 |
+| 团队 | **蚂蚁灵波科技（Robbyant）** — 蚂蚁集团具身智能研究团队 |
+| 作者 | Lin-Zhuo Chen, Jian Gao, Yihang Chen, Ka Leong Cheng, Yipengjing Sun, Liangxiao Hu, Nan Xue, Xing Zhu, Yujun Shen, Yao Yao, Yinghao Xu |
+| 参数量 | **1B+**（基于模型体积 ~350MB+ 和描述推断） |
+| 发布时间 | 2026-04-15 |
+| 许可 | **Apache 2.0**（完整开源） |
+| 项目主页 | https://technology.robbyant.com/lingbot-map |
+
+### 核心定位
+
+受 **SLAM（Simultaneous Localization and Mapping）** 原理启发的**前馈 3D 基础模型**，专为流式 3D 重建设计。
+
+### 架构设计：几何上下文 Transformer（GCT）
+
+**核心创新**：在单一注意力机制中统一三大功能，解决流式重建的三大挑战：
+
+```
+┌─────────────────────────────────────────────────────────┐
+│              Geometric Context Transformer              │
+├─────────────────────────────────────────────────────────┤
+│  ┌─────────────────┐  ┌──────────────────┐  ┌────────┐ │
+│  │ Anchor Context  │  │ Pose-Reference   │  │Traject-│ │
+│  │  (锚点上下文)    │  │    Window        │  │ ory    │ │
+│  │                 │  │ (位姿参考窗口)    │  │Memory  │ │
+│  │ • 坐标定位       │  │ • 密集几何线索    │  │        │ │
+│  │ • 全局参考系     │  │ • 局部精细信息    │  │• 漂移  │ │
+│  │                 │  │                  │  │  校正  │ │
+│  └─────────────────┘  └──────────────────┘  └────────┘ │
+└─────────────────────────────────────────────────────────┘
+```
+
+#### 三大组件详解
+
+| 组件 | 功能 | 解决的问题 | 技术实现 |
+|------|------|-----------|---------|
+| **Anchor Context**<br>（锚点上下文） | 坐标定位 | 为重建提供全局参考系，避免坐标系漂移 | 在注意力机制中引入锚点 token，作为空间参考基准 |
+| **Pose-Reference Window**<br>（位姿参考窗口） | 密集几何线索 | 提供精细的局部几何信息，支持高精度重建 | 滑动窗口机制，维护局部帧间几何一致性 |
+| **Trajectory Memory**<br>（轨迹记忆） | 长程漂移校正 | 防止长时间累积误差导致的全局不一致 | 显式记忆模块，存储历史轨迹信息用于回环检测 |
+
+#### 推理优化
+
+- **分页 KV 缓存注意力**（Paged KV Cache Attention）
+  - 基于 **FlashInfer** 实现
+  - 支持高效流式推理
+  - 内存占用可控
+
+- **关键帧策略**（Keyframe Interval）
+  - 每 N 帧保留一个关键帧到 KV 缓存
+  - 非关键帧仍产生预测但不存储
+  - 解决超过 320 帧后性能下降问题（训练时 RoPE 在 320 视图上训练）
+
+- **窗口化推理**（Windowed Inference）
+  - 适用于 >3000 帧的长序列
+  - 滑动窗口 + 重叠关键帧
+  - 每个窗口重置 KV 缓存
+
+### 检查点
+
+| 名称 | 说明 | 适用场景 |
+|------|------|---------|
+| `lingbot-map-long` | 长序列优化版 | 长序列 + 大场景（**推荐**） |
+| `lingbot-map` | 均衡版 | 短长序列均衡 |
+| `lingbot-map-stage1` | Stage-1 训练权重 | 支持双向推理（c2w） |
+
+### 性能指标
+
+- **参数量**：1B+
+- **推理速度**：~20 FPS（518×378 分辨率）
+- **长序列能力**：**10,000+ 帧**（实测 25,000 帧 / 13 分钟室内漫游）
+- **精度**：多个 benchmark 达到 SOTA（超越流式和迭代优化方法）
+
+### 技术栈依赖
+
+- **VGGT**（Meta）：视觉几何基础模型
+- **DINOv2**（Meta）：视觉特征提取
+- **FlashInfer**：分页 KV 缓存注意力加速
+- **NVIDIA Kaolin**：批量渲染管线（可选）
+
+### 开源状态
+
+- ✅ 完整代码（Apache 2.0）
+- ✅ 检查点（HuggingFace + ModelScope）
+- ✅ 评估脚本（KITTI、Oxford Spires 等）
+- ✅ Demo 脚本（交互式 + 离线渲染）
+- ✅ 长视频示例（25,000 帧室内漫游）
+
+---
+
+## 三、深度对比分析
+
+### 3.1 架构对比
+
+| 维度 | R³ | LingBot-Map |
+|------|-----|-------------|
+| **核心思想** | 相对回归（避免全局坐标） | 几何上下文 Transformer（统一三大功能） |
+| **骨干网络** | Depth Anything 3 | VGGT + DINOv2 |
+| **位姿预测** | 成对相对位姿 MLP | 注意力机制直接预测 |
+| **长序列处理** | 置信度引导的关键帧管理 | 轨迹记忆 + 窗口化推理 |
+| **复杂度** | 轻量（无额外 Transformer） | 重（GCT 架构） |
+
+### 3.2 性能对比
+
+| 指标 | R³ | LingBot-Map |
+|------|-----|-------------|
+| 参数量 | **372M**（轻量） | 1B+（重） |
+| 推理速度 | 20+ FPS | ~20 FPS |
+| 长序列上限 | 数千帧 | **10,000+ 帧** |
+| 内存控制 | 有界内存预算 | 分页 KV 缓存 + 关键帧策略 |
+| 漂移控制 | 置信度加权聚合 | 显式轨迹记忆 |
+
+### 3.3 工程成熟度对比
+
+| 维度 | R³ | LingBot-Map |
+|------|-----|-------------|
+| 代码开放 | 仅推理 | **完整开源** |
+| 训练代码 | ❌ 未开放 | ✅ 未明确（但完整可用） |
+| 评估脚本 | ❌ TODO | ✅ 完整（多数据集） |
+| 文档完善度 | 基础 | **详尽**（含长视频示例、渲染管线） |
+| 社区热度 | 188 stars | **7166 stars** |
+| 许可证 | 未明确 | **Apache 2.0** |
+
+### 3.4 适用场景对比
+
+| 场景 | R³ | LingBot-Map |
+|------|-----|-------------|
+| **手机/消费级设备实时重建** | ✅ 首选 | ⚠️ 可能过重 |
+| **短中长度视频（几百帧）** | ✅ 适合 | ✅ 适合 |
+| **长视频建图（数千帧）** | ⚠️ 有上限 | ✅ 首选 |
+| **机器人导航** | ⚠️ 无漂移校正 | ✅ 首选（轨迹记忆） |
+| **自动驾驶** | ⚠️ 无长期稳定性 | ✅ 首选 |
+| **快速原型验证** | ✅ 即插即用 | ⚠️ 配置复杂 |
+| **学术研究/复现** | ⚠️ 训练代码缺失 | ✅ 完整 |
+
+### 3.5 技术选型决策树
+
+```
+需要 3D 重建？
+├─ 视频长度 < 1000 帧？
+│  ├─ 是 → 需要轻量部署？
+│  │       ├─ 是 → R³
+│  │       └─ 否 → LingBot-Map（精度更高）
+│  └─ 否 → 视频长度 > 3000 帧？
+│          ├─ 是 → LingBot-Map（万帧级稳定性）
+│          └─ 否 → 需要长期空间记忆？
+│                  ├─ 是（机器人/自动驾驶） → LingBot-Map
+│                  └─ 否 → R³（快速部署）
+```
+
+---
+
+## 四、技术背景：Feed-forward 3D Foundation Model 赛道
+
+### 4.1 技术演进
+
+```
+传统 NeRF/3DGS          →    Feed-forward 模型
+（每场景优化，慢）            （一次前向，快）
+     ↓                            ↓
+per-scene optimization      depth + pose + pointcloud
+需要 COLMAP 等 SfM          无需 SfM，端到端
+分钟级/场景                  秒级/场景
+```
+
+### 4.2 上游技术谱系
+
+**R³ 谱系**：
+```
+Depth Anything 3 (字节) → CUT3R → STream3R → R³
+```
+
+**LingBot-Map 谱系**：
+```
+DINOv2 (Meta) → VGGT (Meta) → LingBot-Map
+```
+
+### 4.3 相关竞品
+
+| 项目 | 机构 | 特点 |
+|------|------|------|
+| DUSt3R | Naver | 早期前馈 3D 重建 |
+| MASt3R | Naver | DUSt3R 改进版 |
+| CUT3R | - | 流式 3D 重建 |
+| STream3R | - | 流式 3D 重建 |
+| **R³** | 西湖大学/密歇根 | 相对回归，轻量 |
+| **LingBot-Map** | 蚂蚁灵波 | GCT，万帧级 |
+
+---
+
+## 五、总结与建议
+
+### 5.1 核心差异一句话
+
+- **R³**：用"相对回归"绕过全局坐标问题，轻量但功能有限
+- **LingBot-Map**：用"几何上下文 Transformer"统一解决三大问题，重但完整
+
+### 5.2 技术成熟度
+
+- **R³**：学术原型阶段，训练代码未开放，复现困难
+- **LingBot-Map**：工程成熟阶段，完整开源，可直接用于生产
+
+### 5.3 选型建议
+
+| 你的需求 | 推荐方案 |
+|---------|---------|
+| 手机 App 实时 3D 扫描 | R³ |
+| 快速验证 3D 重建 idea | R³ |
+| 机器人 SLAM 替代方案 | LingBot-Map |
+| 长视频建图（>3000 帧） | LingBot-Map |
+| 学术研究/论文复现 | LingBot-Map（完整代码） |
+| 生产环境部署 | LingBot-Map（Apache 2.0） |
+
+### 5.4 未来展望
+
+- **R³**：等待训练代码开放，可能成为轻量级 3D 重建标准
+- **LingBot-Map**：蚂蚁灵波科技持续投入，可能成为具身智能空间感知标准组件
+
+---
+
+## 六、参考链接
+
+### R³
+- 论文：https://arxiv.org/abs/2605.26519
+- 代码：https://github.com/KevinXu02/R3
+- 检查点：https://huggingface.co/KevinXu02/R3
+- 项目主页：https://kevinxu02.github.io/r3-site/
+
+### LingBot-Map
+- 论文：https://arxiv.org/abs/2604.14141
+- 代码：https://github.com/Robbyant/lingbot-map
+- 检查点：https://huggingface.co/robbyant/lingbot-map
+- 项目主页：https://technology.robbyant.com/lingbot-map
+- Demo 数据集：https://huggingface.co/datasets/robbyant/lingbot-map-demo
+
+---
+
+*来源：GitHub README + arXiv 摘要 + 项目主页，2026-06-12*

AI工程/Trellis_AI编码工程化框架.md

@@ -0,0 +1,150 @@
+# Trellis - AI 编码工程化框架
+
+> **GitHub**: https://github.com/mindfold-ai/Trellis
+> **官网/文档**: https://docs.trytrellis.app/zh
+> **npm**: `@mindfoldhq/trellis`
+> **License**: AGPL-3.0
+> **开发商**: Mindfold (mindfold-ai)
+> **研究日期**: 2026-06-06
+
+---
+
+## 一句话总结
+
+Trellis 是一个**开箱即用的 AI 编码工程化框架**，核心解决的问题是：**AI 编码 Agent 每次会话从零开始，记不住项目规范和团队标准**。它将规范、任务、记忆沉淀进代码仓库，让任何 Coding Agent 都按你的工程标准执行。
+
+## 核心痛点
+
+AI 编码工具（Cursor、Claude Code、Codex 等）虽然能快速生成代码，但存在以下问题：
+1. **无记忆** — 每次新会话从零开始理解项目
+2. **无规范持久化** — `CLAUDE.md`、`.cursorrules` 等文件容易膨胀变臃肿
+3. **无任务结构化** — PRD、实现上下文、审查记录散落各处
+4. **无跨平台统一** — 每个工具都要单独配置工作流
+
+## 核心能力
+
+| 能力 | 说明 |
+|------|------|
+| **自动注入规范** | 规范写在 `.trellis/spec/`，Trellis 按当前任务自动注入相关上下文 |
+| **任务驱动工作流** | PRD、实现上下文、审查上下文统一在 `.trellis/tasks/` 管理 |
+| **项目记忆** | `.trellis/workspace/` 中的 journal 保留上次会话脉络 |
+| **团队共享标准** | Spec 随仓库版本化，个人规则可成为团队基础设施 |
+| **多平台复用** | 一套结构覆盖 **14 个 AI Coding 平台** |
+
+## 工作原理（4阶段循环）
+
+```
+Plan → Implement → Verify → Finish → (循环)
+```
+
+### 1. Plan（规划）
+- `trellis-brainstorm` 逐题梳理需求 → 写入 `prd.md`
+- 资料调研派发给 `trellis-research` 子代理
+- 产出：精选 Spec + 研究文件，由 `implement.jsonl` / `check.jsonl` 编排
+
+### 2. Implement（实现）
+- `trellis-implement` 子代理依据 PRD 编写代码
+- 上下文按 `implement.jsonl` 自动注入
+- **不会执行 git commit**
+
+### 3. Verify（验证）
+- `trellis-check` 子代理基于 diff 对照 Spec 逐项核查
+- 运行 lint、type-check、测试
+- 自动修复能力范围内的问题
+
+### 4. Finish（收尾）
+- 最终检查
+- `trellis-update-spec` 将新增认知沉淀回 `.trellis/spec/`
+- 归档任务，更新 journal
+
+## 目录结构
+
+```
+.trellis/
+├── spec/           # 项目规范（自动注入到 Agent 上下文）
+├── tasks/          # 任务 PRD、实现/审查上下文、状态
+├── workspace/      # 工作日志（journal），会话间记忆
+└── ...             # 各平台适配文件（自动生成）
+```
+
+## 支持平台（14个）
+
+仓库中包含以下平台的配置目录：
+- `.claude/` — Claude Code
+- `.cursor/` — Cursor
+- `.codex/` — OpenAI Codex
+- `.opencode/` — OpenCode
+- `.pi/` — Pi
+- `.agents/` — 通用 Agent Skills
+- `.husky/` — Git Hooks 集成
+- 其他更多...
+
+## 快速开始
+
+```bash
+# 安装
+npm install -g @mindfoldhq/trellis@latest
+
+# 在项目中初始化
+trellis init -u your-name
+
+# 指定平台初始化
+trellis init --cursor --opencode --codex -u your-name
+```
+
+**前置要求**：Node.js >= 18, Python >= 3.9
+
+## 使用流程
+
+1. 用自然语言描述需求
+2. AI 逐题头脑风暴 → 澄清 PRD
+3. AI 自主调用 `trellis-implement` 编码 + 自动校验
+4. 完成时输入 `/trellis:finish-work`，归档任务、更新记忆
+
+## 与 CLAUDE.md / AGENTS.md / .cursorrules 的区别
+
+这些文件是有用的入口，但容易膨胀。Trellis 在此之上补充了：
+- **作用域明确的 Spec**（不是一个大文件）
+- **按任务划分的 PRD**
+- **工作流关卡**（Plan→Implement→Verify→Finish）
+- **工作区记忆**（跨会话）
+- **多平台自动适配文件**
+
+## 适用场景
+
+- **个人开发者**：记忆机制 + 可复用工作流，不用每次重复说明
+- **团队**：标准统一、任务边界清晰、上下文可审查、跨平台可移植
+- **多工具用户**：同一套 Trellis 结构在 Cursor/Claude Code/Codex 间复用
+
+## 评价
+
+### ✅ 优点
+- 解决了 AI 编码的核心痛点（记忆 + 规范持久化）
+- 多平台支持是一大亮点，不用为每个工具单独配置
+- 4阶段循环（Plan→Implement→Verify→Finish）是成熟的工程化思路
+- 规范随仓库版本化，团队协作友好
+- 开源 AGPL-3.0，可自托管
+
+### ⚠️ 注意
+- AGPL-3.0 许可证，商业使用需注意传染性
+- 需要团队统一采用，否则收益有限
+- 增加 `.trellis/` 目录到仓库，有一定侵入性
+
+### 📊 项目热度
+- GitHub Stars：持续增长中
+- 有微信群 + 飞书群，国内社区活跃
+- npm 周下载量可见
+
+## 相关链接
+
+- [官方文档](https://docs.trytrellis.app/zh)
+- [快速开始](https://docs.trytrellis.app/zh/start/install-and-first-task)
+- [支持平台](https://docs.trytrellis.app/zh/advanced/multi-platform)
+- [真实场景](https://docs.trytrellis.app/zh/start/real-world-scenarios)
+- [Spec 模板](https://docs.trytrellis.app/zh/templates/specs-index)
+- [Discord](https://discord.com/invite/tWcCZ3aRHc)
+- [DeepWiki](https://deepwiki.com/mindfold-ai/Trellis)
+
+---
+
+*研究归档：2026-06-06 | 路径：/obsidian/AI工程/Trellis_AI编码工程化框架.md*

AI工程/团队级AI_Coding简明手册_逐页研究/00_概述与前言.md

@@ -0,0 +1,522 @@
+# 团队级 AI Coding 简明手册 - 逐页详细研究
+
+> 原文：系统设计研讨会分享 PPT v0.2（2026年6月18日）
+> 研究日期：2026-06-20
+> 研究目标：逐页深入分析，补充背景知识、工具推荐、实践建议
+
+---
+
+## 第1页：封面
+
+### 原文内容
+- 标题：团队级 AI Coding 简明手册 v0.2
+- 日期：2026年6月18日
+- 来源：系统设计研讨会分享
+- 版权声明：版权归分享人所有
+
+### 研究要点
+- 这是 v0.2 版本，说明经过了迭代完善
+- "团队级"强调这不是个人技巧，而是组织层面的工程实践
+- "简明手册"定位：实用导向，非学术理论
+
+---
+
+## 第2页：AI 编程思想发展过程
+
+### 原文内容
+AI 编程经历5个阶段演进：
+
+| 阶段 | 特征 | 自动化程度 |
+|------|------|------------|
+| **原始阶段** | 基于本能，手动复制代码或通过问答交互 | 半自动，有人值守 |
+| **Rule 约束** | 经验规则显化，如 RIPER-5 定义工作模式 | 半自动，持续对话 |
+| **规格驱动** | 需求结构化表达，如 OpenSpec 框架 | 过渡阶段 |
+| **Loop Engineering** | 可反馈闭环，AI 根据验收规则自动循环 | 接近全自动 |
+| **Harness 驾驭工程** | 纳入工程治理体系，提供约束+外部接口 | 全自动，Plan 后无人值守 |
+
+### 深入解读
+
+**1. 原始阶段**
+- **现状**：大多数开发者仍在这个阶段
+- **典型场景**：复制 ChatGPT 生成的代码到 IDE，手动调整
+- **问题**：上下文断裂，每次对话都要重新解释背景
+- **工具**：ChatGPT 网页版、早期 Copilot
+
+**2. Rule 约束阶段**
+- **RIPER-5 模式**（Research-Investigate-Plan-Execute-Review）：
+  - 由 AI 编程社区提出的结构化工作流
+  - 将复杂任务分解为5个明确阶段
+  - 每个阶段有不同的提示词策略
+- **其他 Rule 框架**：
+  - Cursor Rules：在 `.cursor/rules` 定义项目规范
+  - Claude Code 的 `CLAUDE.md`：项目级指令
+  - OpenCode 的 `.opencode/config.json`
+
+**3. 规格驱动阶段**
+- **OpenSpec 框架**：
+  - 将需求写成结构化的 Spec 文件
+  - AI 读取 Spec 生成代码，文件进文件出
+  - Spec 可以作为版本控制的产物
+- **优势**：需求可追溯，AI 行为可预测
+
+**4. Loop Engineering**
+- **核心理念**：AI 不是执行一次就结束，而是进入循环
+- **循环机制**：
+  - 定义验收标准（测试用例）
+  - AI 执行 → 运行测试 → 失败则修复 → 再次运行
+  - 直到所有测试通过才退出循环
+- **代表工具**：Claude Code 的 `/loop` 命令
+
+**5. Harness 驾驭工程**
+- **概念来源**：OpenAI、Anthropic 等公司提出的工程理念
+- **Harness（驾驭工具）**：
+  - 为 AI 提供约束体系（Rules、Specs）
+  - 为 AI 提供外部接口（MCP、Skills、CLI）
+  - 让 AI 在受控环境中自主工作
+- **关键特征**：
+  - Plan 阶段人机协作
+  - 执行阶段无人值守
+  - 可审计、可回溯
+
+### 实践建议
+- **评估你所在团队的位置**：大多数团队在阶段1-2之间
+- **渐进式升级**：不要跳级，先建立 Rule，再引入 Spec
+- **关键指标**：AI 代码采纳率、人均代码产出、缺陷率
+
+### 相关资源
+- [Harness Engineering - OpenAI](https://openai.com/index/harness-engineering/)
+- [Harness Engineering - Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
+- [Anthropic: Harness Design for Long-running Apps](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+
+---
+
+## 第3页：四大核心问题
+
+### 原文内容
+团队级 AI Coding 面临4个核心问题：
+
+1. **需求衔接**：如何用 AI 整理需求？
+2. **开发实现**：如何获得高质量的代码？
+3. **测试验收**：如何根据规格自动化测试？
+4. **Agent as Code**：如何组织协作文件，构建 AI 友好环境？
+
+### 深入解读
+
+**问题1：需求衔接**
+- **痛点**：AI 无法理解模糊需求，需要结构化输入
+- **关键问题**：
+  - 格式：Markdown vs YAML vs JSON
+  - 组织：按功能模块 vs 按用户故事
+  - 原型图传递：Figma 链接 vs HTML 原型
+  - 模版设计：新建需求 vs 变更需求
+- **解决方案**：使用 `docs/features/` 目录管理需求规格
+
+**问题2：开发实现**
+- **痛点**：AI 生成的代码质量不稳定，缺乏上下文
+- **关键问题**：
+  - 上下文管理：如何让 AI 理解项目结构
+  - 外部工具：如何调用数据库、API、文件系统
+  - 代码一致性：如何保证风格统一
+  - 多任务并发：如何同时开发多个功能
+  - 调试能力：如何让 AI 自主排查问题
+- **解决方案**：
+  - AGENTS.md 定义项目约束
+  - MCP 协议接入外部工具
+  - 打样工程提供代码模版
+
+**问题3：测试验收**
+- **痛点**：AI 生成的代码缺乏测试，难以验证
+- **关键问题**：
+  - 测试策略：单元测试 vs 集成测试 vs E2E 测试
+  - 浏览器操作：如何让 AI 操作浏览器进行 E2E 测试
+  - 测试用例管理：如何组织、版本控制
+- **解决方案**：
+  - TDD 驱动：先写测试再写代码
+  - Playwright MCP：AI 操作浏览器
+  - 测试用例生成：Browser Use 探索 → Playwright 固化
+
+**问题4：Agent as Code**
+- **痛点**：AI 协作文件散乱，缺乏组织
+- **关键问题**：
+  - 文件结构：如何组织 docs、skills、mcp 等目录
+  - 工具支持：如何让 Claude、Cursor、OpenCode 都识别
+  - 版本控制：如何将 AI 配置纳入 Git 管理
+- **解决方案**：
+  - AGENTS.md 作为宪法级文件
+  - 软链接到各工具的配置文件
+  - 统一目录结构：`docs/`, `skills/`, `mcp/`
+
+### 实践建议
+- **优先级排序**：先解决问题4（Agent as Code），建立基础
+- **逐步引入**：需求衔接 → 开发实现 → 测试验收
+- **度量指标**：AI 代码采纳率、测试覆盖率、缺陷逃逸率
+
+---
+
+## 第4页：AI 赋能软件开发实现地图
+
+### 原文内容
+完整的软件开发生命周期中，人与 AI 的分工：
+
+```
+需求分析 → 需求文档/原型图 → 技术方案 → 代码框架+打样
+   ↓              ↓              ↓              ↓
+  人+AI          人+AI          人+AI          人+AI
+   ↓              ↓              ↓              ↓
+AI代码编写 → 单元/API测试 → E2E测试 → Code Review → 提测部署
+   ↓              ↓            ↓           ↓           ↓
+  机             机+人         机+人        机+人        机+人
+```
+
+**核心 Loop**：研发自测阶段（AI 自治运行）
+**全流程超级 Loop**：从需求到部署（人机协作）
+
+### 深入解读
+
+**阶段1：需求分析（人+AI）**
+- **人的角色**：用户访谈、竞品分析、业务理解
+- **AI 的角色**：整理访谈记录、生成用户故事、绘制流程图
+- **工具推荐**：
+  - ChatGPT/Claude：整理访谈笔记
+  - Miro AI：自动生成流程图
+  - Whimsical AI：生成用户旅程图
+
+**阶段2：需求文档+原型图（人+AI）**
+- **人的角色**：定义业务规则、审核原型
+- **AI 的角色**：生成需求文档草稿、生成 HTML 原型
+- **工具推荐**：
+  - Cursor/Claude Code：生成 Markdown 需求文档
+  - v0.dev：生成 React 原型
+  - Galileo AI：生成 UI 设计稿
+
+**阶段3：技术方案（人+AI）**
+- **人的角色**：架构决策、技术选型
+- **AI 的角色**：生成技术规格文档、绘制架构图
+- **工具推荐**：
+  - PlantUML + AI：生成领域模型、时序图
+  - Claude Code：生成 API 设计文档
+
+**阶段4：代码框架+打样（人+AI）**
+- **人的角色**：定义目录结构、编写核心接口
+- **AI 的角色**：生成 CRUD 代码、填充模版
+- **工具推荐**：
+  - Claude Code + 打样工程：生成符合项目规范的代码
+  - Cursor Composer：批量生成代码
+
+**阶段5：AI 代码编写（机）**
+- **AI 的角色**：根据 Spec 自动生成代码
+- **人的角色**：审核关键逻辑
+- **工具推荐**：
+  - Claude Code Loop 模式：自动循环直到测试通过
+  - OpenCode：根据 OpenSpec 生成代码
+
+**阶段6：单元/API 测试（机+人）**
+- **AI 的角色**：生成测试代码、运行测试
+- **人的角色**：审核测试用例、补充边界条件
+- **工具推荐**：
+  - Jest + AI：生成单元测试
+  - Karate：生成 API 测试
+
+**阶段7：E2E 测试（机+人）**
+- **AI 的角色**：操作浏览器、生成测试脚本
+- **人的角色**：定义关键路径、审核测试
+- **工具推荐**：
+  - Playwright MCP：AI 操作浏览器
+  - Browser Use：探索式测试生成
+
+**阶段8：Code Review（机+人）**
+- **AI 的角色**：自动审查代码、发现问题
+- **人的角色**：审核 AI 的审查结果
+- **工具推荐**：
+  - GitHub Copilot Code Review
+  - Claude Code：PR Review
+  - CodeRabbit：AI 代码审查
+
+**阶段9：提测部署（机+人）**
+- **AI 的角色**：生成部署脚本、执行部署
+- **人的角色**：审核部署配置、处理异常
+- **工具推荐**：
+  - GitHub Actions + AI：自动生成 CI/CD
+  - Vercel/Netlify：一键部署
+
+### 实践建议
+- **从核心 Loop 开始**：先在研发自测阶段引入 AI
+- **逐步扩展到超级 Loop**：覆盖需求、测试、部署
+- **关键指标**：AI 参与率、自动化程度、交付周期
+
+---
+
+## 第5页：AI 赋能软件开发工具体系
+
+### 原文内容
+展示了各阶段使用的工具和产出物：
+
+| 阶段 | 工具 | 产出 |
+|------|------|------|
+| 原型图 | Stitch/Figma/HTML | Design.md |
+| 需求规格 | AI IDE + 模版 | Markdown |
+| 技术规格 | AI IDE + 模版 | Markdown |
+| 代码编写 | AI IDE + 规范 | TS/Java |
+| 测试规格 | AI IDE + 模版 | Markdown |
+| E2E 测试 | Playwright MCP | TS 代码 |
+| Bug 修复 | AI IDE + 模版 | 代码修复 |
+| 部署 | AI IDE + Yaml | 环境部署 |
+
+### 深入解读
+
+**工具链核心：AI IDE**
+- **定义**：集成 AI 能力的开发环境
+- **代表工具**：
+  - **Cursor**：基于 VS Code，AI 优先设计
+  - **Claude Code**：命令行 AI 编程工具
+  - **OpenCode**：开源的 AI 编程终端
+  - **Kiro**：AWS 推出的 AI IDE
+  - **Trae**：字节跳动推出的 AI IDE
+
+**模版体系**
+- **需求规格模版**：定义需求文档结构
+- **技术规格模版**：定义技术设计文档结构
+- **测试规格模版**：定义测试用例结构
+- **代码模版**：定义代码风格、目录结构
+
+**关键工具详解**
+
+1. **Design.md**
+   - 作用：约束 AI 生成的前端风格
+   - 内容：颜色、字体、间距、组件库
+   - 来源：从设计稿提炼或从现有代码反推
+
+2. **Playwright MCP**
+   - 作用：让 AI 操作浏览器
+   - 场景：E2E 测试、UI 调试
+   - 优势：标准化接口，支持 Accessibility Tree
+
+3. **MCP（Model Context Protocol）**
+   - 作用：AI 与外部系统通信的标准协议
+   - 场景：数据库、API、文件系统接入
+   - 优势：标准化、双向通信、即插即用
+
+### 实践建议
+- **建立模版库**：将常用的文档结构模版化
+- **统一工具链**：团队使用相同的 AI IDE
+- **维护 Design.md**：确保 AI 生成的 UI 风格一致
+
+---
+
+## 第6页：分隔页（01 需求衔接）
+
+### 原文内容
+章节分隔页，标志进入"需求衔接"部分
+
+### 研究要点
+- 这是第4个核心问题的展开
+- 需求衔接是整个开发流程的起点
+- 良好的需求衔接能大幅提升 AI 代码质量
+
+---
+
+## 第7页：需求规格编写
+
+### 原文内容
+**AI 能理解的需求格式**：Markdown/Excel 表格
+
+**关键要素**：
+1. **模块切分**（增量/存量）
+2. **字段清单**
+3. **原型链接**
+4. **业务规则**
+
+**编写原则**：
+- 先写业务背景，再切模块
+- 一个模块 = 一个文档
+- 分解为增量需求和存量需求：
+  - **增量需求**：全新功能，需新建模块
+  - **存量修改**：对已有功能做变更
+- Tips：增量建模块，存量标改动
+
+**字段清单示例**：
+```markdown
+| 字段名    | 类型    | 必填 | 默认值 | 描述         |
+|-----------|---------|------|--------|--------------|
+| username  | string  | 是   | —      | 登录用户名   |
+| email     | string  | 是   | —      | 电子邮箱     |
+| role      | enum    | 否   | user   | 用户角色     |
+| status    | boolean | 否   | true   | 是否启用     |
+```
+
+**字段定义要求**：
+- 定义完整字段
+- 标注校验规则
+- 标注 UI 展示
+- 标注数据来源
+
+**原型图传递**：
+- Figma：选中 Frame → Share → Copy link
+- Stitch：选中设计稿 → 获取分享链接
+- HTML 版本：用 HTML/CSS 做可交互原型，提交到代码仓库
+
+**业务规则示例**：
+```markdown
+R1 用户名唯一不可重复
+R2 邮箱格式正则校验
+R3 密码 ≥ 8 位含大小写
+R4 删除需二次确认
+R5 超时自动登出
+R6 管理员不可降级
+```
+
+**编写原则**：
+- 条目化 + 正交分解
+- 每条规则独立可测
+
+**重要 Tip**：BA 也应该工作在代码仓库中，让 AI 基于当前系统事实构建新需求
+
+### 深入解读
+
+**为什么用 Markdown？**
+- **版本控制友好**：可以纳入 Git 管理
+- **AI 友好**：LLM 对 Markdown 理解能力强
+- **可读性好**：人和 AI 都能轻松阅读
+- **工具支持**：所有 AI IDE 都支持
+
+**为什么区分增量/存量？**
+- **增量需求**：AI 从零生成，需要完整上下文
+- **存量修改**：AI 需要理解现有代码，才能安全修改
+- **影响 AI 策略**：增量可以用生成式 AI，存量需要理解现有代码
+
+**字段清单的价值**
+- **明确数据模型**：AI 可以根据字段生成数据库表、API 接口
+- **减少歧义**：类型、必填、默认值都明确定义
+- **自动生成代码**：可以根据字段清单生成前端表单、后端 DTO
+
+**业务规则条目化**
+- **独立可测**：每条规则可以单独写测试用例
+- **正交分解**：规则之间不重叠、不冲突
+- **可追溯**：每条规则可以追溯到代码实现
+
+**BA 在代码仓库中工作**
+- **优势**：
+  - BA 可以看到现有需求、代码结构
+  - AI 可以基于现有需求生成新需求
+  - 需求变更可以追溯历史
+- **实践**：
+  - BA 使用 Git 管理需求文档
+  - 需求变更通过 PR 审核
+  - AI 参与需求文档的生成和审核
+
+### 实践建议
+- **建立需求模版**：统一需求文档结构
+- **使用字段清单**：明确数据模型
+- **业务规则条目化**：方便测试和追溯
+- **BA 使用 Git**：将需求管理纳入版本控制
+
+### 工具推荐
+- **需求管理**：Git + Markdown
+- **原型设计**：Figma、Stitch、HTML
+- **字段清单**：Excel、Markdown 表格
+- **业务规则**：Markdown 列表
+
+---
+
+## 第8页：原型图设计
+
+### 原文内容
+**原型图设计的3种方式**：
+
+**1. AI 设计软件输出**
+- 在设计工具中完成原型，通过 URL 链接嵌入需求文档
+- 标注映射：在需求中注明对应模块和页面
+- **Figma**：选中 Frame → Share → Copy link
+- **Stitch**：选中设计稿 → 获取分享链接
+
+**2. HTML + CSS 输出**
+- 用 HTML/CSS 做可交互原型，提交到代码仓库
+- **优势**：
+  - 真实代码：直接使用项目组件库拼装
+  - 可交互：点击、跳转、表单输入均可演示
+  - 版本管理：随代码仓库一起管理和 Review
+
+**3. Design.md 生成统一的视觉风格**
+- **Design.md**：用 Markdown 约束 AI 生成的前端风格，确保输出与项目组件库一致
+- **两种产生方式**：
+  - 从设计稿提炼规则
+  - 从现有代码反推样式
+
+**Design.md 示例**：
+```markdown
+# Design System
+
+## Colors
+- primary: #1a1a1a
+- background: #ffffff
+- text: #333333
+
+## Typography
+- font: -apple-system, sans-serif
+- h1: 1.5rem / 700
+- body: 0.875rem / 400
+
+## Spacing
+- unit: 8px (base)
+```
+
+**参考资源**：https://getdesign.md
+
+### 深入解读
+
+**为什么需要原型图？**
+- **减少歧义**：文字描述容易产生误解，原型图直观展示
+- **AI 理解**：AI 可以通过原型图理解 UI 结构
+- **用户确认**：用户可以提前看到效果，减少返工
+
+**Figma vs Stitch vs HTML**
+
+| 维度 | Figma | Stitch | HTML |
+|------|-------|--------|------|
+| **学习成本** | 中 | 低 | 高 |
+| **AI 友好度** | 中 | 高 | 极高 |
+| **版本控制** | 差 | 中 | 极好 |
+| **交互能力** | 中 | 中 | 极强 |
+| **协作能力** | 极强 | 强 | 中 |
+
+**Figma**
+- **优势**：设计师常用，生态丰富
+- **劣势**：AI 无法直接读取 Figma 文件，需要通过链接
+- **适用场景**：专业设计师参与的项目
+
+**Stitch**
+- **优势**：AI 友好，可以直接生成设计稿
+- **劣势**：生态较小
+- **适用场景**：AI 优先的项目
+
+**HTML**
+- **优势**：AI 可以直接生成，版本控制友好
+- **劣势**：需要前端开发能力
+- **适用场景**：技术团队主导的项目
+
+**Design.md 的价值**
+- **统一风格**：确保 AI 生成的 UI 风格一致
+- **可维护**：Markdown 格式，易于修改和版本控制
+- **可复用**：可以在多个项目中复用
+
+**Design.md 的内容**
+- **Colors**：主色、背景色、文字色
+- **Typography**：字体、字号、字重
+- **Spacing**：间距、边距
+- **Components**：按钮、表单、卡片等组件样式
+- **Layout**：布局规则
+
+### 实践建议
+- **选择适合的原型工具**：根据团队能力选择 Figma/Stitch/HTML
+- **维护 Design.md**：确保 AI 生成的 UI 风格一致
+- **原型与代码同步**：原型变更时同步更新代码
+- **使用 getdesign.md**：参考现成的 Design.md 模版
+
+### 工具推荐
+- **设计工具**：Figma、Stitch
+- **原型工具**：HTML/CSS、v0.dev
+- **Design.md 生成**：从设计稿提炼、从代码反推
+
+---
+
+（由于篇幅较长，我将继续为剩余页面创建详细研究文档。需要我继续吗？）

AI工程/团队级AI_Coding简明手册_逐页研究/00_索引.md

@@ -0,0 +1,354 @@
+# 团队级 AI Coding 简明手册 v0.2 - 逐页研究索引
+
+> 原文：系统设计研讨会分享 PPT（2026年6月18日）
+> 研究日期：2026-06-20
+> 研究范围：第1-30页（全文）
+> 归档位置：/obsidian/AI工程/团队级AI_Coding简明手册_逐页研究/
+
+---
+
+## 文档结构
+
+### 00_概述与前言.md
+**覆盖页码**：第1-8页
+
+**核心内容**：
+- 第1页：封面信息
+- 第2页：AI 编程思想发展过程（5个阶段）
+- 第3页：四大核心问题概述
+- 第4页：AI 赋能软件开发实现地图
+- 第5页：AI 赋能软件开发工具体系
+- 第6页：分隔页（01 需求衔接）
+- 第7页：需求规格编写
+- 第8页：原型图设计
+
+**关键概念**：
+- AI 编程5阶段：原始 → Rule约束 → 规格驱动 → Loop工程 → Harness驾驭
+- 4个核心问题：需求衔接、开发实现、测试验收、Agent as Code
+- 需求规格：Markdown格式、字段清单、业务规则条目化
+- 原型图：Figma/Stitch/HTML + Design.md
+
+---
+
+### 01_开发实现_第9-15页.md
+**覆盖页码**：第9-15页
+
+**核心内容**：
+- 第9页：分隔页（02 开发实现）
+- 第10页：如何让 AI 听话 - 规则、规格、技能
+- 第11页：构建 AI 上下文体系
+- 第12页：如何让 AI 调用外部工具
+- 第13页：用什么 AI 编程工具
+- 第14页：用什么 SDD 框架比较好
+- 第15页：一个新星：Superpower
+
+**关键概念**：
+- 三要素：Rules（规则）、Specification（规格）、Skill（技能）
+- 上下文体系：AGENTS.md + docs/（standards/features/plans/designs/others）
+- 过程方案 vs 事实方案：Plans（追加新文件）vs Designs（覆盖更新）
+- 外部工具：MCP、Skills、CLI
+- AI 工具：Claude Code、Cursor、Kiro、Trae、OpenCode、Codex CLI
+- SDD 框架：BMAD、Spec Kit、OpenSpec、Kiro
+
+---
+
+### 02_开发实现续_第16-19页.md
+**覆盖页码**：第16-19页
+
+**核心内容**：
+- 第16页：技术规格如何编写
+- 第17页：打样工程：如何让 AI 抄作业
+- 第18页：如何多任务同步开发
+- 第19页：完整的核心 Loop 过程（研发自测）
+
+**关键概念**：
+- 技术规格 DSL：领域模型（PlantUML）、数据库（SQL DDL）、API（OpenAPI）、时序图、专题设计
+- 打样工程：提供代码模版，让 AI "抄作业"
+- 三层架构：Controller → Service → Repository
+- Git Worktree：多任务并行开发
+- 核心 Loop：Plan → TDD → 验证
+
+---
+
+### 03_测试验收_第20-25页.md
+**覆盖页码**：第20-25页
+
+**核心内容**：
+- 第20页：分隔页（03 测试验收）
+- 第21页：AI 辅助下的测试策略
+- 第22页：AI 如何操作浏览器
+- 第23页：如何用测试用例生成 E2E 测试
+- 第24页：Playwright E2E 示例
+- 第25页：超级 Loop（E2E Loop）
+
+**关键概念**：
+- 测试策略：Lint → Code Review → 单元测试 → API 测试 → E2E 测试
+- AI 操作浏览器：Playwright MCP、Chrome DevTools MCP、Browser Use、Computer Use
+- E2E 测试生成：Browser Use 探索 → Playwright 固化 → 截图视觉兜底
+- Playwright 最佳实践：稳定选择器、API 登录、测试数据管理
+- 超级 Loop：在核心 Loop 基础上增加 E2E 测试验证
+
+---
+
+### 04_Agent_as_Code_第26-30页.md
+**覆盖页码**：第26-30页
+
+**核心内容**：
+- 第26页：分隔页（04 Agent as Code）
+- 第27页：AI 工程文件管理
+- 第28页：分隔页（附录&参考资料）
+- 第29页：关于 AI 编程实践的心得
+- 第30页：参考资料
+
+**关键概念**：
+- Agent as Code：将 AI 协作文件以代码方式管理
+- AGENTS.md 作为宪法级配置
+- 软链接实现多工具共享配置
+- Skills 目录：可复用的 AI 能力单元
+- MCP 配置：让 AI 访问外部工具
+- 实践心得：放弃"开箱即用"，"少量取用，大量实践"
+
+---
+
+## 核心框架总结
+
+### 团队级 AI Coding 的4个核心问题
+
+| 问题 | 核心挑战 | 解决方案 |
+|------|---------|---------|
+| **需求衔接** | 如何编写 AI 能理解的需求？ | Markdown 格式、字段清单、业务规则条目化、原型图传递 |
+| **开发实现** | 如何让 AI 生成高质量代码？ | 规则/规格/技能、上下文体系、MCP/Skills/CLI、SDD 框架、打样工程、核心 Loop |
+| **测试验收** | 如何自动化测试 AI 生成的代码？ | 分层测试、AI 操作浏览器、E2E 测试生成、超级 Loop |
+| **Agent as Code** | 如何组织 AI 协作文件？ | AGENTS.md、文档体系、Skills 库、MCP 配置、软链接 |
+
+### AI 编程5阶段演进
+
+```
+原始阶段 → Rule 约束 → 规格驱动 → Loop Engineering → Harness 驾驭工程
+   ↓           ↓           ↓            ↓                  ↓
+手动复制   RIPER-5    OpenSpec     自动循环           工程治理
+半自动     持续对话   文件进出     测试驱动           无人值守
+```
+
+### 文档分层体系
+
+```
+AGENTS.md          ← 宪法（所有 AI 工具读取）
+docs/
+├── standards/     ← 标准规格（架构/命名/API/安全规范）
+├── features/      ← 需求规格（产品/BA维护）
+├── designs/       ← 设计规格（事实方案，Source of Truth）
+├── plans/         ← 计划规格（过程方案，追加不修改）
+└── others/        ← 架构决策、Release、测试用例等
+skills/            ← AI 技能（可复用能力单元）
+mcp/               ← MCP 配置（外部工具接入）
+```
+
+### 核心 Loop 流程
+
+```
+Plan 阶段（人机协作）
+    ↓
+装载需求规格 → 创建 Plan → 确认 Plan
+    ↓
+执行阶段（AI 自治）
+    ↓
+编写 API 测试 → 编写实现 → 运行测试
+    ↓                              ↓
+    ↓ 失败                        ↓ 成功
+    ↓                              ↓
+修复重试 ←──────────────────── 退出循环
+```
+
+### 测试策略金字塔
+
+```
+        E2E 测试（Playwright）
+       /                      \
+      /    API 测试（Karate）    \
+     /                          \
+    /    单元测试（JUnit/Jest）    \
+   /                              \
+  /    Code Review（AI + 人工）     \
+ /                                  \
+/    Lint 代码扫描（ESLint/SonarQube）\
+/____________________________________\
+```
+
+---
+
+## 关键工具清单
+
+### AI 编程工具
+- **Claude Code**：Anthropic 出品，强大的推理能力
+- **Cursor**：基于 VS Code，AI 优先设计
+- **Kiro**：AWS 出品，深度集成 AWS 服务
+- **Trae**：字节跳动出品，中文支持好
+- **OpenCode**：开源，支持多种 AI 模型
+- **Codex CLI**：OpenAI 出品，基于 GPT-4
+
+### SDD 框架
+- **BMAD**：企业级，强治理，多 Agent 编排
+- **Spec Kit**：工程化，Git 集成，适合新项目
+- **OpenSpec**：轻量级，灵活，适合存量项目
+- **Kiro**：IDE 原生，可执行 Spec，自动验证
+
+### 测试工具
+- **Playwright**：最流行的 E2E 测试框架
+- **Browser Use**：AI 操作浏览器，Token 消耗低
+- **Karate**：BDD 风格的 API 测试框架
+- **RestAssured**：Java API 测试库
+- **SonarQube**：代码质量分析工具
+- **ESLint**：JavaScript 代码检查工具
+
+### 文档工具
+- **PlantUML**：文本化的 UML 图
+- **OpenAPI**：API 规范定义
+- **Markdown**：通用文档格式
+- **Mermaid**：Markdown 中的图表
+
+### 协作工具
+- **Git**：版本控制
+- **GitHub/GitLab**：代码托管和协作
+- **Git Worktree**：多工作区并行开发
+
+---
+
+## 最佳实践清单
+
+### 需求阶段
+- [ ] 使用 Markdown 编写需求规格
+- [ ] 区分增量需求和存量需求
+- [ ] 使用字段清单定义数据模型
+- [ ] 业务规则条目化，每条规则独立可测
+- [ ] 通过原型图传递 UI 设计（Figma/Stitch/HTML）
+- [ ] 维护 Design.md 约束前端风格
+
+### 开发阶段
+- [ ] 建立 AGENTS.md 作为宪法级配置
+- [ ] 区分过程方案（Plans）和事实方案（Designs）
+- [ ] 使用 DSL 编写技术规格（PlantUML/SQL/OpenAPI）
+- [ ] 建立打样工程，提供代码模版
+- [ ] 使用 TDD 驱动开发
+- [ ] 使用 Git Worktree 并行开发
+- [ ] Plan 阶段充分沟通，关闭所有开放性问题
+
+### 测试阶段
+- [ ] 分层测试：单元测试 → API 测试 → E2E 测试
+- [ ] 先用 Browser Use 探索，再固化到 Playwright
+- [ ] 使用稳定的选择器（data-testid、角色、标签）
+- [ ] 关键页面截图验证（视觉回归测试）
+- [ ] 所有测试集成到 CI/CD 流程
+
+### 协作阶段
+- [ ] 使用 AGENTS.md 作为统一入口
+- [ ] 使用软链接让多个工具共享配置
+- [ ] 所有配置纳入 Git 管理
+- [ ] 建立 Skills 库，沉淀常用 AI 能力
+- [ ] 配置 MCP 让 AI 访问外部工具
+
+---
+
+## 学习路径
+
+### 入门（1-2周）
+1. 理解 AI 编程的5个发展阶段
+2. 建立 AGENTS.md
+3. 使用一个 AI 工具（如 Claude Code）
+4. 实践核心 Loop（Plan → TDD → 验证）
+
+### 进阶（1-2月）
+1. 学习 SDD 框架（BMAD/SpecKit/OpenSpec/Kiro）
+2. 使用 DSL 编写技术规格
+3. 建立打样工程
+4. 实践分层测试
+5. 使用 Playwright 进行 E2E 测试
+
+### 高级（持续）
+1. 构建完整的 Harness 体系
+2. 开发自定义 Skills
+3. 配置 MCP 访问外部工具
+4. 优化 AI 工作流
+5. 分享实践经验
+
+---
+
+## 关键洞察
+
+1. **AI 编程不是银弹**：需要工程化的方法来驾驭
+2. **上下文是关键**：AI 需要清晰的上下文才能生成高质量代码
+3. **测试是保障**：自动化测试是 AI 生成代码质量的保障
+4. **实践出真知**：没有放之四海而皆准的方案，需要根据项目特点定制
+5. **持续演进**：AI 能力在快速提升，方法也需要持续演进
+6. **区分过程和事实**：Plans 是过程记录（追加不修改），Designs 是事实描述（覆盖更新）
+7. **少量取用，大量实践**：不要一开始就引入所有概念，先实践核心，再逐步扩展
+
+---
+
+## 术语表
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| AI 编程 | AI Coding | 使用 AI 辅助或自动化进行软件开发 |
+| Harness | Harness | 为 AI 提供约束和工具的工程实践 |
+| SDD | Spec-Driven Development | 以规格文档为核心的开发方法 |
+| MCP | Model Context Protocol | AI 与外部系统通信的标准协议 |
+| AGENTS.md | AGENTS.md | AI 协作的宪法级配置文件 |
+| Plan | Plan | AI 执行任务的规划文档 |
+| Spec | Specification | 结构化的需求描述 |
+| Rule | Rule | 约束 AI 行为的规则 |
+| Skill | Skill | 可复用的 AI 能力单元 |
+| Loop | Loop | AI 自治运行的开发循环 |
+| TDD | Test-Driven Development | 测试驱动开发 |
+| E2E | End-to-End | 端到端测试 |
+| DSL | Domain Specific Language | 领域特定语言 |
+| Worktree | Git Worktree | Git 的多工作区功能 |
+| Browser Use | Browser Use | AI 操作浏览器的框架 |
+| Playwright | Playwright | 浏览器自动化测试框架 |
+| BMAD | Business Model Architecture Design | 企业级 SDD 框架 |
+| OpenSpec | OpenSpec | 轻量级 SDD 框架 |
+| Kiro | Kiro | AWS 推出的 AI IDE 和 SDD 框架 |
+
+---
+
+## 参考资料
+
+1. [Harness Engineering - OpenAI](https://openai.com/index/harness-engineering/)
+2. [Harness Engineering - Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
+3. [Anthropic: Harness Design for Long-running Apps](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+4. [从 Rule、Spec 到 Harness：AI Coding 的渐进式建设路径](https://mp.weixin.qq.com/s/UCh2bPzMZjNBMBCCJysuNw)
+5. [让 AI 乖乖听话的几个 Rules](https://mp.weixin.qq.com/s/FXNzk_y2Z2h8BVe62uEn_A)
+6. [Understanding SDD: Kiro, spec-kit, and Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+7. [harness-engineering-in-ai-coding](https://github.com/2361485765/harness-engineering-in-ai-coding)
+8. [attractor-guided-engineering-template](https://github.com/entropy-cloud/attractor-guided-engineering-template)
+9. [OpenAI: Tools Computer Use](https://developers.openai.com/api/docs/guides/tools-computer-use)
+
+---
+
+## 文档信息
+
+- **原文**：团队级 AI Coding 简明手册 v0.2
+- **作者**：系统设计研讨会分享人
+- **日期**：2026年6月18日
+- **研究日期**：2026-06-20
+- **研究范围**：第1-30页（全文）
+- **归档位置**：/obsidian/AI工程/团队级AI_Coding简明手册_逐页研究/
+- **文件列表**：
+  - 00_概述与前言.md（第1-8页）
+  - 01_开发实现_第9-15页.md（第9-15页）
+  - 02_开发实现续_第16-19页.md（第16-19页）
+  - 03_测试验收_第20-25页.md（第20-25页）
+  - 04_Agent_as_Code_第26-30页.md（第26-30页）
+  - 00_索引.md（本文档）
+
+---
+
+**研究完成** ✅
+
+所有30页内容已详细研究并归档，包含：
+- 原文内容提取
+- 深入解读和背景知识
+- 实践建议和工具推荐
+- 代码示例和配置示例
+- 最佳实践清单
+- 学习路径指南

AI工程/团队级AI_Coding简明手册_逐页研究/01_开发实现_第9-15页.md

@@ -0,0 +1,315 @@
+# 第9-15页：开发实现篇
+
+> 章节：02 开发实现
+> 核心问题：如何让 AI 听话？如何构建 AI 上下文体系？如何调用外部工具？
+
+---
+
+## 第9页：分隔页（02 开发实现）
+
+### 原文内容
+章节分隔页，标志进入"开发实现"部分
+
+### 研究要点
+- 这是4个核心问题中的第2个
+- 开发实现是整个流程中最关键的环节
+- 核心目标：让 AI 生成高质量、符合规范的代码
+
+---
+
+## 第10页：如何让 AI 听话 - 规则、规格、技能
+
+### 原文内容
+**三要素模型**：
+
+| 要素 | 定义 | 示例 |
+|------|------|------|
+| **规则 Rules** | 约束 AI 行为的边界，定义能做什么、不能做什么 | "请做一个登录注册页面，需要能实现邮箱验证" |
+| **规格 Specification** | 把模糊的需求收敛为结构化的内容，甚至通过 DSL 描述 | 用户故事 + 验收标准 |
+| **技能 Skill** | 通过打包提示词、脚本、模版，进一步精确拓展 AI 的能力 | 提示词 + 规格文档 |
+
+**规则示例（Java 代码风格）**：
+```markdown
+# Java 代码风格 Rules
+1. 使用 Java 17 语法，不使用已废弃 API
+2. 类名使用大驼峰（PascalCase），方法名和变量名使用小驼峰（camelCase）
+3. 常量使用全大写下划线分隔（UPPER_SNAKE_CASE）
+4. 单行代码不超过 120 字符，超过则换行
+5. 大括号采用 Egyptian 风格（左括号不换行）
+6. 禁止使用 @Autowired 字段注入，改用构造器注入
+```
+
+**规格示例（用户故事 + 验收标准）**：
+```markdown
+作为一个新用户或现有用户，我想要一个同时支持注册和登录的页面，
+并且在注册时能通过邮箱完成身份验证，以便安全地创建账户并登录系统。
+
+验收标准（AC）：
+1. 用户可以输入邮箱、密码等必要信息进行注册。注册提交后，
+   系统向用户邮箱发送验证链接（或验证码）。用户点击链接
+  （或输入验证码）后，账户状态变为"已验证"。
+2. 已验证用户可使用邮箱和密码登录系统。未验证邮箱的用户
+   尝试登录时，系统提示"请先完成邮箱验证"。
+3. 邮箱格式不正确或已被注册时，系统给出明确提示。验证链
+   接过期或无效时，支持重新发送验证邮件。
+```
+
+### 深入解读
+
+**规则 Rules 的本质**
+- 作用：约束 AI 的行为边界
+- 载体：
+  - Cursor：`.cursor/rules/` 目录
+  - Claude Code：`CLAUDE.md` 文件
+  - OpenCode：`.opencode/config.json`
+  - 通用：`AGENTS.md` 文件
+
+**规则的分类**：
+1. 代码风格规则：命名规范、格式规范
+2. 架构规则：分层架构、依赖方向
+3. 安全规则：敏感数据处理、权限控制
+4. 性能规则：数据库查询优化、缓存策略
+
+**规格 Specification 的价值**
+- 消除歧义：将模糊需求转化为明确定义
+- 可验证性：验收标准可以直接转化为测试用例
+- 可追溯性：需求变更有历史记录
+
+**规格的格式**：
+1. 用户故事格式：As a... I want... So that...
+2. Given-When-Then 格式：行为驱动开发（BDD）
+3. 表格格式：字段清单、业务规则
+4. DSL 格式：领域特定语言
+
+**技能 Skill 的概念**
+- 定义：打包的可复用能力单元
+- 组成：提示词模版、脚本工具、文档模版、配置文件
+- 复用性：可以在多个项目中使用
+
+### 实践建议
+- 建立规则库：将常用的规则沉淀下来
+- 使用规格模版：统一需求文档格式
+- 开发技能包：将常用的能力封装成技能
+
+---
+
+## 第11页：构建 AI 上下文体系
+
+### 原文内容
+**核心理念**：使用完整的文档来描述上下文和约束体系，区分过程方案和事实方案，减少维护成本。
+
+**文档分层结构**：
+```
+AGENTS.md          ← 宪法
+docs/
+├── standards/     ← 标准规格（架构/命名/API/安全规范）
+├── features/      ← 需求规格（产品/BA维护）
+├── plans/         ← 计划规格（过程方案）
+├── designs/       ← 设计规格（事实方案，Source of Truth）
+└── others/        ← 架构决策、Release、测试用例等
+```
+
+**规格流转**：
+- 追加（Plans）：每次创建新文件，细微修改不再更新
+- 变更（Designs）：每次以最终态更新，作为下一次 Plan 的事实依据
+
+### 深入解读
+
+**AGENTS.md 的内容**：
+```markdown
+# 项目基本信息
+- 项目名称：示例项目
+- 技术栈：Java 17, Spring Boot 3.x, MySQL 8.0
+- 代码规范：阿里巴巴 Java 开发手册
+
+# AI 行为规则
+1. 生成代码必须符合代码规范
+2. 数据库表必须包含 created_at, updated_at 字段
+3. API 接口必须使用 RESTful 风格
+4. 敏感数据必须加密存储
+```
+
+**过程方案 vs 事实方案详细对比**
+
+| 维度 | 过程方案（Plans） | 事实方案（Designs） |
+|------|------------------|-------------------|
+| 目的 | 记录实现过程 | 记录当前状态 |
+| 更新方式 | 追加新文件 | 覆盖更新 |
+| 生命周期 | 短期（任务完成后归档） | 长期（持续维护） |
+| 维护成本 | 低（不修改旧文件） | 高（必须保持最新） |
+| 使用场景 | 任务执行、问题排查 | 新功能开发、架构决策 |
+| 示例 | plan-2026-06-20-feature-x.md | database-schema.md |
+
+**Plans 最佳实践**：
+- 命名规范：`plan-YYYY-MM-DD-feature-name.md`
+- 内容结构：目标、方案、任务列表、状态、问题记录
+- 归档策略：任务完成后移动到 `archive/` 目录
+
+**Designs 最佳实践**：
+- 命名规范：使用功能名称，如 `database-schema.md`
+- 内容结构：概述、详细设计、变更历史
+- 更新策略：每次变更必须更新文档，保持最新
+
+---
+
+## 第12页：如何让 AI 调用外部工具？
+
+### 原文内容
+**三种方式**：
+
+**1. MCP（Model Context Protocol）**
+- AI 与外部系统通信的标准协议
+- 标准化接口、双向通信、即插即用
+```json
+{
+  "mcpServers": {
+    "database": {
+      "command": "node",
+      "args": ["mcp-server-sqlite"]
+    }
+  }
+}
+```
+
+**2. Skills**
+- 将开源工具用脚本封装成 AI 可直接调用的能力单元
+- 脚本封装、触发词驱动、可复用
+```markdown
+# Commit & Push Skill
+## 触发词: commit, push
+## 执行
+git add -A
+git commit -m "{message}"
+git push
+## 规则
+- 提交前检查 lint
+- 信息遵循 conventional commit
+```
+
+**3. Commands（CLI）**
+- 通过 CLI 命令让 AI 直接调用外部工具
+- 即时执行、管道组合、权限可控
+```bash
+# AI 通过 CLI 调用工具
+> 部署到生产环境
+npm run build
+npx vercel --prod
+```
+
+### 深入解读
+
+**MCP 详解**
+- Anthropic 提出的开放标准协议
+- Client-Server 架构
+- 常用 MCP Server：
+  - 数据库：mcp-server-sqlite、mcp-server-postgres
+  - 文件系统：mcp-server-filesystem
+  - Web 搜索：mcp-server-brave-search
+  - GitHub：mcp-server-github
+  - 浏览器：mcp-server-playwright
+
+**Skills 详解**
+- 可复用的能力单元
+- 组成：触发词、执行逻辑、参数、规则
+- 开发流程：需求分析 → 脚本开发 → 触发词定义 → 测试验证 → 文档编写
+
+**CLI 安全考虑**：
+- 白名单机制：只允许执行特定的命令
+- 沙箱环境：在隔离环境中执行
+- 审计日志：记录所有执行的命令
+
+---
+
+## 第13页：用什么 AI 编程工具？
+
+### 原文内容
+**三类工具**：
+
+**1. 命令行类**（AI 优先，人辅助）
+- Claude Code、Codex CLI、OpenCode
+
+**2. AI IDE**（人掌控感更强）
+- Cursor、Kiro、Trae
+
+**3. 增强插件**（预制辅助工具集）
+- Superpower、oh-my-opencode、oh-my-codex
+
+### 工具对比表
+
+| 工具 | 类型 | 价格 | AI 模型 | 适用场景 |
+|------|------|------|---------|---------|
+| Claude Code | CLI | 按 Token | Claude | 复杂逻辑 |
+| Codex CLI | CLI | 按 Token | GPT-4 | 快速原型 |
+| OpenCode | CLI | 免费 | 多模型 | 预算有限 |
+| Cursor | IDE | $20/月 | 多模型 | 日常开发 |
+| Kiro | IDE | 免费+付费 | Claude | AWS 项目 |
+| Trae | IDE | 免费+付费 | 豆包 | 中文项目 |
+
+### 各工具详解
+
+**Claude Code**
+- 强大的推理能力，支持长上下文
+- 内置 MCP 支持，Loop 模式
+- 适合复杂逻辑开发、架构设计
+
+**Cursor**
+- 基于 VS Code，AI 优先设计
+- 强大的代码补全，Composer 模式
+- 适合日常开发
+
+**Kiro（AWS）**
+- 深度集成 AWS 服务
+- 支持 Spec 驱动开发
+- 自动化测试生成
+
+**Trae（字节跳动）**
+- 集成豆包大模型
+- 中文支持好
+- 适合中文项目
+
+---
+
+## 第14页：用什么 SDD 框架比较好？
+
+### 原文内容
+**SDD（Spec-Driven Development）框架对比**
+
+Spec = 单一事实来源（SSoT），甚至可以直接生成代码
+
+| 维度        | BMAD                     | Spec Kit               | OpenSpec          | Kiro               |
+| --------- | ------------------------ | ---------------------- | ----------------- | ------------------ |
+| 方法定位      | 企业级 SDD 操作系统             | 工程化 Spec 工作流           | 轻量 Spec 层         | IDE 原生 SDD         |
+| 核心理念      | Spec = 治理体系 + 多 Agent 编排 | Spec = 开发入口 + Git 生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
+| Spec 生命周期 | 全生命周期                    | 与分支绑定（短生命周期）           | 长期存在（持续演化）        | 持续驱动               |
+| Spec 粒度   | 大（系统/模块级）                | 中（Feature级）            | 小（变更/Patch级）      | 中（Feature+行为）      |
+| 可执行能力     | 通过流程驱动                   | 驱动开发流程                 | 类 Prompt          | 可生成代码+测试并自动校验      |
+| 流程控制      | 强（阶段+审批+Agent）           | 中（Plan→Spec→Tasks）     | 弱（自由演化）           | 强（闭环）              |
+| 自动验证      | 无                        | 无                      | 弱                 | 强（内建）              |
+| 与代码关系     | 间接                       | 半耦合                    | 弱耦合               | 强耦合                |
+| 适用场景      | 大型系统/多团队                 | 新项目（0→1）               | 存量项目/快速迭代         | 小团队/高自动化           |
+| 失控风险      | 低                        | 中                      | 高                 | 中                  |
+
+### 框架选择指南
+
+| 团队规模 | 项目类型  | 推荐框架     |
+| ---- | ----- | -------- |
+| 大型团队 | 企业级项目 | BMAD     |
+| 中型团队 | 新项目   | Spec Kit |
+| 小型团队 | 存量项目  | OpenSpec |
+| 个人开发 | 快速迭代  | Kiro     |
+
+---
+
+## 第15页：一个新星：Superpower
+
+### 原文内容
+- 提供了一些内置的 skills
+- 方便开箱即用
+- 缺点是不太方便精细调整
+
+### 深入解读
+- 为 AI 编程工具提供增强功能的插件集合
+- 内置 Skills：预制的常用能力
+- 优势：快速上手、功能丰富、社区支持
+- 劣势：不够灵活、黑盒、依赖性强
+- 适合快速原型和学习，不适合深度定制

AI工程/团队级AI_Coding简明手册_逐页研究/02_开发实现续_第16-19页.md

@@ -0,0 +1,692 @@
+# 第16-19页：开发实现续篇（技术规格 + 打样 + 多任务 + 核心Loop）
+
+> 章节：02 开发实现（续）
+> 核心问题：技术规格如何编写？如何让 AI 抄作业？如何多任务同步开发？核心 Loop 如何运转？
+
+---
+
+## 第16页：技术规格如何编写？
+
+### 原文内容
+**技术规格的5个模块**（DSL 驱动）：
+
+| 模块 | 表达标准 | 格式 | 产出内容 | 约束/规范 |
+|------|---------|------|---------|----------|
+| **领域模型** | PlantUML/Smart Domain | .puml | 实体、属性、关系（ER/类图） | 必须表达实体关系；字段需与数据库一致；标注聚合关系 |
+| **数据库** | SQL DDL/DBML/Flyway 脚本 | .sql | 表结构、索引、约束 | 必须可执行；包含索引和外键；字段与领域模型一致 |
+| **API** | OpenAPI 3.x | .yaml/.json | 接口定义、请求/响应结构 | 必须定义 schema；禁止只写接口说明；字段与模型一致 |
+| **时序图** | PlantUML | .puml | 调用流程、系统交互 | 必须反映真实调用链；建议包含异常分支（alt） |
+| **专题设计** | Markdown | .md | 架构策略（权限/事务/缓存等） | 只写"策略与规则"，不重复 API/DDL；强调设计决策 |
+
+### 深入解读
+
+**为什么用 DSL？**
+- **可执行**：DDL 可以直接运行，OpenAPI 可以生成代码
+- **AI 友好**：LLM 对 DSL 的理解比自然语言更精确
+- **一致性保证**：DSL 有语法规则，不容易产生歧义
+
+**领域模型详解**
+
+**PlantUML 示例**：
+```plantuml
+@startuml
+entity User {
+  * id : Long <<PK>>
+  --
+  * username : String(50)
+  * email : String(100)
+  * role_id : Long <<FK>>
+}
+
+entity Role {
+  * id : Long <<PK>>
+  --
+  * name : String(20)
+}
+
+User }o--|| Role : "拥有"
+note right of User : 聚合根
+@enduml
+```
+
+**约束要求**：
+- 必须表达实体关系（1:1, 1:N, M:N）
+- 字段需与数据库一致（类型、长度、默认值）
+- 标注聚合关系（哪些是聚合根）
+
+**数据库设计详解**
+
+**SQL DDL 示例**：
+```sql
+-- Flyway migration: V1__create_users_table.sql
+CREATE TABLE users (
+    id BIGINT PRIMARY KEY AUTO_INCREMENT,
+    username VARCHAR(50) NOT NULL UNIQUE,
+    email VARCHAR(100) NOT NULL UNIQUE,
+    password VARCHAR(255) NOT NULL,
+    role_id BIGINT NOT NULL,
+    status TINYINT(1) DEFAULT 1,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+    INDEX idx_username (username),
+    INDEX idx_email (email),
+    CONSTRAINT fk_user_role FOREIGN KEY (role_id) REFERENCES roles(id)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+**必须可执行**：
+- DDL 必须可以直接在数据库中运行
+- 使用 Flyway/Liquibase 管理版本
+- 包含索引（查询性能）和外键（数据完整性）
+
+**API 设计详解**
+
+**OpenAPI 3.x 示例**：
+```yaml
+openapi: 3.0.3
+info:
+  title: User API
+  version: 1.0.0
+paths:
+  /api/v1/users:
+    post:
+      summary: 创建用户
+      tags: [User]
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateUserRequest'
+      responses:
+        '201':
+          description: 创建成功
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '400':
+          description: 参数错误
+components:
+  schemas:
+    CreateUserRequest:
+      type: object
+      required: [username, email, password]
+      properties:
+        username:
+          type: string
+          minLength: 3
+          maxLength: 50
+          description: 登录用户名，唯一
+        email:
+          type: string
+          format: email
+          description: 电子邮箱，唯一
+        password:
+          type: string
+          minLength: 8
+          description: 密码，≥8位含大小写
+    UserResponse:
+      type: object
+      properties:
+        id:
+          type: integer
+          format: int64
+        username:
+          type: string
+        email:
+          type: string
+        role:
+          type: string
+          enum: [admin, user]
+        status:
+          type: boolean
+```
+
+**约束要求**：
+- 必须定义 schema（请求和响应的结构）
+- 禁止只写接口说明（"返回用户列表"这种描述不够）
+- 字段与领域模型一致（类型、名称、约束）
+
+**时序图详解**
+
+**PlantUML 时序图示例**：
+```plantuml
+@startuml
+actor User
+participant "UserController" as C
+participant "UserService" as S
+participant "UserRepository" as R
+database "MySQL" as DB
+
+User -> C: POST /api/v1/users
+C -> C: 参数校验
+C -> S: createUser(CreateUserRequest)
+S -> S: 业务规则校验
+S -> R: save(User)
+R -> DB: INSERT INTO users ...
+DB --> R: 返回结果
+R --> S: 返回 User
+S --> C: 返回 UserResponse
+C --> User: 201 Created
+
+alt 用户名已存在
+  S --> C: throw DuplicateException
+  C --> User: 409 Conflict
+end
+@enduml
+```
+
+**约束要求**：
+- 必须反映真实调用链
+- 建议包含异常分支（alt）
+- 标注关键步骤（参数校验、业务规则校验）
+
+**专题设计详解**
+
+**专题设计示例**：
+```markdown
+# 权限设计方案
+
+## 策略
+- 使用 RBAC（基于角色的访问控制）
+- 权限注解：@RequirePermission("user:create")
+- 默认拒绝所有未授权的请求
+
+## 规则
+1. 管理员角色拥有所有权限
+2. 普通用户只能操作自己的数据
+3. 敏感操作需要二次确认
+
+## 设计决策
+- 选择 RBAC 而非 ABAC：业务场景简单，角色固定
+- 权限存储在 Redis：减少数据库查询
+- 权限变更实时生效：通过 Redis Pub/Sub 通知
+```
+
+**约束要求**：
+- 只写"策略与规则"
+- 不重复 API/DDL（避免信息冗余）
+- 强调设计决策（为什么选择这个方案）
+
+### 实践建议
+- 使用 DSL：统一技术规格的表示方式
+- 保持一致性：领域模型、数据库、API 要一致
+- AI 辅助生成：让 AI 根据规格生成代码
+- 版本控制：技术规格纳入 Git 管理
+
+---
+
+## 第17页：打样工程：如何让 AI 抄作业？
+
+### 原文内容
+**参考代码**：https://github.com/domain-driven-design/ddd-microservices
+
+**原则**：
+1. 约定大于配置
+2. 编排逻辑和原子能力分离
+3. 操作者和被操作对象分离
+
+**常见 CQRUD 操作的工序**：
+
+**1. 简单 CRUD**：
+```
+Controller + Command → AppService → Repository → Response 对象
+```
+
+**2. 复杂或有复用逻辑的 CRUD**：
+```
+Controller + Command → AppService → DomainService → Repository → Response 对象
+```
+
+**3. 复杂的查询操作**：
+```
+Controller + Query 对象 → AppService → QueryPO（或复用 PO）→ Response 对象
+```
+
+### 深入解读
+
+**什么是打样工程？**
+- 定义：提供代码模版和示例，让 AI 参考生成代码
+- 目的：保证代码风格统一、质量稳定
+- 核心理念：让 AI "抄作业"，而不是自由发挥
+
+**为什么需要打样工程？**
+- AI 生成的代码质量不稳定
+- 不同 AI 工具生成的代码风格不同
+- AI 可能不知道项目的最佳实践
+
+**打样工程的优势**：
+1. 提高代码质量：基于模版生成，质量有保障
+2. 统一代码风格：所有代码遵循相同的风格
+3. 减少 Review 成本：代码符合规范，Review 更快
+4. 知识沉淀：最佳实践沉淀在模版中
+
+**三层架构详解**
+
+**Controller 层**：
+- 职责：接收请求、参数校验、调用 Service
+- 输入：Command/Query 对象
+- 输出：Response 对象
+- 不包含业务逻辑
+
+**Service 层**：
+- 职责：编排业务逻辑、调用 DomainService/Repository
+- AppService：应用服务，编排逻辑
+- DomainService：领域服务，复杂业务逻辑
+- Repository：数据访问
+
+**Repository 层**：
+- 职责：数据持久化
+- 输入：实体对象
+- 输出：实体对象或 PO（Persistent Object）
+
+**工序详解**
+
+**简单 CRUD（无复用逻辑）**：
+```java
+// Controller
+@PostMapping("/users")
+public Response<UserResponse> createUser(@Valid @RequestBody CreateUserCommand cmd) {
+    return Response.success(userAppService.create(cmd));
+}
+
+// AppService
+public UserResponse create(CreateUserCommand cmd) {
+    User user = userRepository.save(User.from(cmd));
+    return UserResponse.from(user);
+}
+
+// Repository
+public User save(User user) {
+    userMapper.insert(user);
+    return user;
+}
+```
+
+**复杂 CRUD（有复用逻辑）**：
+```java
+// AppService - 编排逻辑
+public UserResponse create(CreateUserCommand cmd) {
+    // 1. 校验用户名唯一
+    domainService.checkUsernameUnique(cmd.getUsername());
+    // 2. 加密密码
+    String encryptedPassword = domainService.encryptPassword(cmd.getPassword());
+    // 3. 保存用户
+    User user = User.from(cmd, encryptedPassword);
+    userRepository.save(user);
+    // 4. 发送欢迎邮件
+    domainService.sendWelcomeEmail(user);
+    return UserResponse.from(user);
+}
+
+// DomainService - 原子能力
+public void checkUsernameUnique(String username) {
+    if (userRepository.existsByUsername(username)) {
+        throw new BusinessException("用户名已存在");
+    }
+}
+```
+
+**复杂查询**：
+```java
+// Controller
+@GetMapping("/users")
+public Response<Page<UserResponse>> listUsers(@Valid UserQuery query) {
+    return Response.success(userAppService.list(query));
+}
+
+// AppService
+public Page<UserResponse> list(UserQuery query) {
+    Page<UserPO> page = userRepository.findByQuery(query);
+    return page.map(UserResponse::from);
+}
+
+// Repository
+public Page<UserPO> findByQuery(UserQuery query) {
+    // 构建查询条件
+    // 执行分页查询
+    // 返回分页结果
+}
+```
+
+### 实践建议
+- 建立打样工程：提供标准的代码模版
+- 分层清晰：Controller、Service、Repository 职责明确
+- 工序标准化：简单 CRUD、复杂 CRUD、复杂查询各有标准
+- AI 参考打样：让 AI 根据打样工程生成代码
+
+---
+
+## 第18页：如何多任务同步开发？
+
+### 原文内容
+使用 git 的 Worktree 功能同时把一个仓库的多个分支映射到不同文件夹。Claude Code、Codex、Cursor 等已经自动支持使用 subagent 创建 Worktree，加速开发。
+
+```bash
+# 基于已有分支创建
+git worktree add ../feature-login feature/login
+
+# 创建新分支 + 工作区（最常用）
+git worktree add -b feature-payment ../feature-payment
+
+# 查看所有 worktree
+git worktree list
+
+# 删除工作区
+git worktree remove ../feature-login
+```
+
+### 深入解读
+
+**什么是 Git Worktree？**
+- 定义：Git 的一个功能，允许你从同一个仓库检出多个工作目录
+- 每个工作目录都是一个独立的分支
+- 共享同一个 .git 目录（节省磁盘空间）
+
+**为什么需要 Worktree？**
+- AI 编程时，经常需要同时开发多个功能
+- 传统方式：切换分支，容易丢失上下文
+- Worktree：每个功能在独立的目录，互不干扰
+
+**Worktree 的优势**：
+1. 并行开发：多个 AI 实例可以同时工作在不同分支
+2. 上下文隔离：每个功能的上下文独立，不会混淆
+3. 快速切换：不需要 `git checkout`，直接切换目录
+4. 节省空间：共享 .git 目录
+
+**使用场景**
+
+**场景1：多 AI 实例并行开发**
+```bash
+# 主工作区：开发功能 A
+cd /project/feature-a
+claude-code # 启动 Claude Code
+
+# 新开终端：开发功能 B
+cd /project/feature-b
+claude-code # 启动另一个 Claude Code 实例
+
+# 再开终端：开发功能 C
+cd /project/feature-c
+claude-code # 启动第三个 Claude Code 实例
+```
+
+**场景2：AI + 人工并行开发**
+```bash
+# AI 在 feature-a 开发
+cd /project/feature-a
+claude-code
+
+# 人工在 main 分支修复紧急 bug
+cd /project/main
+# 手动修复 bug
+```
+
+**场景3：Code Review 时继续开发**
+```bash
+# 主工作区：feature-a 提交 PR，等待 review
+# 新开工作区：继续开发 feature-b
+git worktree add -b feature-b ../feature-b
+cd ../feature-b
+claude-code
+```
+
+**Worktree 管理**
+
+**列出所有工作区**：
+```bash
+git worktree list
+# 输出：
+# /project/main              abc1234 [main]
+# /project/feature-a         def5678 [feature-a]
+# /project/feature-b         ghi9012 [feature-b]
+```
+
+**清理工作区**：
+```bash
+# 删除工作区（会自动删除目录）
+git worktree remove ../feature-a
+
+# 强制删除（即使有未提交的更改）
+git worktree remove --force ../feature-a
+
+# 清理已删除的工作区记录
+git worktree prune
+```
+
+**AI 工具自动支持**：
+- Claude Code：自动创建 Worktree 进行并行开发
+- Codex CLI：支持在独立工作区运行
+- Cursor：可以在多个窗口打开不同 Worktree
+
+### 实践建议
+- 使用 Worktree 并行开发：提高开发效率
+- 命名规范：工作区目录名与分支名一致
+- 及时清理：完成的功能及时删除 Worktree
+- AI 工具支持：利用 AI 工具的自动 Worktree 功能
+
+---
+
+## 第19页：完整的核心 Loop 过程（研发自测）
+
+### 原文内容
+**核心理念**：通过 TDD/浏览器调试（前端），AI 自治运行
+
+**Loop 流程图**：
+```
+开始进入循环
+    ↓
+[Chat] 进入 Plan 模式
+    ↓
+装载需求规格，给出指令进行 Plan
+    ↓
+[Chat] 符合要求，退出 Plan 模式，开始执行？
+    ↓ 是
+[模型] 读取 Plan
+    ↓
+创建 API 测试，实现代码
+    ↓
+[模型] 运行测试/浏览器调试，是否成功？
+    ↓ 否
+重复多次 / 白天持续很久 / 夜间
+    ↓ 是
+[模型] 退出循环
+    ↓
+（给予 ByPass 权限）
+```
+
+**核心思想**：
+1. Plan 阶段尽可能锁定上下文到 Plan 中，关闭所有的开放性问题
+2. Plan 中记录实现状态，让任务可以分批完成或者重试
+3. 需要给出确定性的验收方式：例如通过所有的 API 测试，让 AI 能建立自我修复标准
+
+**Loop 规则（API 为例，放到 AGENTS.md 作为开发流程要求）**：
+1. **Plan 等待确认**：在 docs/plans 下根据模版创建 Plan
+2. **编写 API 测试**：根据 Plan 实现 API 测试，运行成功并断言失败
+3. **编写实现**：编写单元测试 + 实现代码，通过编译
+4. **运行 API 测试**：运行测试，并修复失败的测试和其他错误
+
+### 深入解读
+
+**什么是核心 Loop？**
+- 定义：AI 自治运行的开发循环
+- 目标：通过 TDD 驱动，AI 自动实现需求并修复问题
+- 特点：Plan 阶段人机协作，执行阶段 AI 自治
+
+**Loop 的三个阶段**
+
+**阶段1：Plan（规划）**
+- 输入：需求规格、技术规格
+- 输出：实现方案、任务列表
+- 关键：关闭所有开放性问题
+- 人工介入：确认 Plan 是否合理
+
+**阶段2：执行（Implementation）**
+- 输入：Plan
+- 输出：API 测试、实现代码
+- 关键：按照 Plan 逐步实现
+- AI 自治：无需人工介入
+
+**阶段3：验证（Verification）**
+- 输入：API 测试、实现代码
+- 输出：测试结果、修复建议
+- 关键：所有测试通过
+- AI 自治：自动运行测试，自动修复
+
+**Plan 模版示例**：
+```markdown
+# Plan: 实现用户注册功能
+
+## 目标
+实现用户注册 API，支持邮箱验证
+
+## 任务列表
+- [ ] 1. 创建数据库表 users
+- [ ] 2. 实现 POST /api/v1/users API
+- [ ] 3. 实现邮箱验证逻辑
+- [ ] 4. 编写单元测试
+- [ ] 5. 编写 API 测试
+
+## 实现方案
+1. 使用 Flyway 创建 users 表
+2. Controller 接收 CreateUserCommand
+3. AppService 调用 UserRepository 保存
+4. 发送验证邮件（使用 JavaMail）
+
+## 验收标准
+- 所有单元测试通过
+- 所有 API 测试通过
+- 代码符合阿里巴巴 Java 开发手册
+
+## 状态
+- 开始时间：2026-06-20 10:00
+- 预计完成：2026-06-20 12:00
+- 实际完成：待更新
+```
+
+**TDD 驱动详解**
+
+**步骤1：编写 API 测试**
+```java
+@Test
+public void testCreateUser() {
+    CreateUserRequest request = new CreateUserRequest();
+    request.setUsername("testuser");
+    request.setEmail("test@example.com");
+    request.setPassword("Password123");
+    
+    Response<UserResponse> response = userClient.create(request);
+    
+    assertEquals(201, response.getCode());
+    assertNotNull(response.getData().getId());
+    assertEquals("testuser", response.getData().getUsername());
+}
+
+@Test
+public void testCreateUser_DuplicateUsername() {
+    // 先创建一个用户
+    CreateUserRequest request1 = new CreateUserRequest();
+    request1.setUsername("testuser");
+    request1.setEmail("test1@example.com");
+    request1.setPassword("Password123");
+    userClient.create(request1);
+    
+    // 再创建一个同名用户
+    CreateUserRequest request2 = new CreateUserRequest();
+    request2.setUsername("testuser");
+    request2.setEmail("test2@example.com");
+    request2.setPassword("Password123");
+    
+    Response<UserResponse> response = userClient.create(request2);
+    
+    assertEquals(409, response.getCode());
+    assertEquals("用户名已存在", response.getMessage());
+}
+```
+
+**步骤2：运行测试（断言失败）**
+```bash
+mvn test -Dtest=UserApiTest
+# 预期：测试失败（因为没有实现）
+```
+
+**步骤3：编写实现代码**
+```java
+// Controller
+@PostMapping("/users")
+public Response<UserResponse> createUser(@Valid @RequestBody CreateUserRequest request) {
+    return Response.success(userAppService.create(request));
+}
+
+// AppService
+public UserResponse create(CreateUserRequest request) {
+    // 校验用户名唯一
+    if (userRepository.existsByUsername(request.getUsername())) {
+        throw new BusinessException(409, "用户名已存在");
+    }
+    // 加密密码
+    String encryptedPassword = passwordEncoder.encode(request.getPassword());
+    // 保存用户
+    User user = User.from(request, encryptedPassword);
+    userRepository.save(user);
+    // 发送验证邮件
+    emailService.sendVerificationEmail(user);
+    return UserResponse.from(user);
+}
+```
+
+**步骤4：运行测试（通过）**
+```bash
+mvn test -Dtest=UserApiTest
+# 预期：所有测试通过
+```
+
+**ByPass 权限**
+- 定义：AI 在某些情况下可以跳过某些步骤
+- 场景：
+  - 测试环境不可用
+  - 第三方服务不可用
+  - 紧急修复
+- 控制：在 AGENTS.md 中定义 ByPass 规则
+
+**Loop 的退出条件**
+1. 所有 API 测试通过
+2. 所有单元测试通过
+3. 代码符合规范（Lint 通过）
+4. 没有编译错误
+
+### 实践建议
+- Plan 阶段充分沟通：关闭所有开放性问题
+- TDD 驱动：先写测试再写代码
+- AI 自治运行：执行阶段无需人工介入
+- 记录实现状态：方便复盘和优化
+- ByPass 权限控制：紧急情况可以跳过某些步骤
+
+---
+
+## 本章小结
+
+**开发实现的核心要点**：
+1. 让 AI 听话：规则、规格、技能三要素
+2. 构建上下文体系：区分过程方案和事实方案
+3. 调用外部工具：MCP、Skills、CLI
+4. 选择合适的工具：命令行类、AI IDE、增强插件
+5. SDD 框架：BMAD、Spec Kit、OpenSpec、Kiro
+6. 技术规格 DSL 驱动：领域模型、数据库、API、时序图、专题设计
+7. 打样工程：让 AI 抄作业
+8. 多任务同步开发：Git Worktree
+9. 核心 Loop：Plan → TDD → 验证
+
+**关键工具**：
+- Claude Code、Cursor、Kiro
+- MCP Server、Skills
+- PlantUML、OpenAPI
+- Git Worktree
+
+**最佳实践**：
+- AGENTS.md 作为宪法
+- 区分 Plans（过程）和 Designs（事实）
+- 使用 DSL 编写技术规格
+- 建立打样工程
+- TDD 驱动开发

AI工程/团队级AI_Coding简明手册_逐页研究/04_Agent_as_Code_第26-30页.md

@@ -0,0 +1,491 @@
+# 第26-30页：Agent as Code + 附录
+
+> 章节：04 Agent as Code + 附录
+> 核心问题：如何组织 AI 工程文件？如何让多个 AI 工具协同？
+
+---
+
+## 第26页：分隔页（04 Agent as Code）
+
+### 原文内容
+章节分隔页，标志进入"Agent as Code"部分
+
+### 研究要点
+- 这是4个核心问题中的第4个
+- Agent as Code 是整个体系的基础设施
+- 核心目标：让 AI 协作文件可版本化、可复用、可共享
+
+---
+
+## 第27页：AI 工程文件管理
+
+### 原文内容
+**核心思路**：使用 AGENTS.md 构建引用关系，让 Claude/OpenCode 等工具支持相关 Harness 文件
+
+**目录结构**：
+```
+AGENTS.md          ← 宪法
+docs/
+├── standards/     ← 标准规格
+├── features/      ← 需求规格
+├── plans/         ← 计划规格
+├── designs/       ← 设计规格
+└── others/        ← 其他
+skills/            ← AI 技能
+mcp/               ← MCP 配置
+```
+
+**工具配置**：
+- `.claude/` - Claude Code 配置
+- `.opencode/` - OpenCode 配置
+- `.cursor/` - Cursor 配置
+
+**实现方式**：通过软链接（symlink）让各工具读取同一份 AGENTS.md
+
+### 深入解读
+
+**什么是 Agent as Code？**
+- 定义：将 AI 协作的所有文件以代码的方式管理
+- 目标：可版本化、可复用、可共享
+- 核心理念：AI 的行为由代码（配置文件）决定
+
+**为什么需要 Agent as Code？**
+- AI 工具配置分散：每个工具有自己的配置文件
+- 难以复用：不同项目需要重复配置
+- 难以协作：团队成员无法共享 AI 配置
+- 难以追溯：AI 行为变更没有历史记录
+
+**AGENTS.md 的作用**
+- **宪法级约束**：定义 AI 的基本行为规则
+- **统一入口**：所有 AI 工具都从这个文件开始
+- **引用枢纽**：通过引用关系组织其他文件
+
+**AGENTS.md 示例**：
+```markdown
+# 项目信息
+- 项目名称：电商平台
+- 技术栈：Java 17, Spring Boot 3.x, React 18
+- 代码规范：阿里巴巴 Java 开发手册
+
+# AI 行为规则
+1. 生成代码必须符合代码规范
+2. 数据库表必须包含 created_at, updated_at 字段
+3. API 接口必须使用 RESTful 风格
+4. 敏感数据必须加密存储
+
+# 目录结构
+- src/main/java/com/example/project/controller
+- src/main/java/com/example/project/service
+- src/main/java/com/example/project/repository
+
+# 引用文件
+- 代码规范：./docs/standards/coding-style.md
+- API 规范：./docs/standards/api-style.md
+- 数据库规范：./docs/standards/db-style.md
+```
+
+**软链接实现**
+
+**Linux/Mac**：
+```bash
+# 创建软链接
+ln -s ../AGENTS.md .claude/AGENTS.md
+ln -s ../AGENTS.md .opencode/AGENTS.md
+ln -s ../AGENTS.md .cursor/AGENTS.md
+```
+
+**Windows**：
+```cmd
+# 创建软链接（需要管理员权限）
+mklink .claude\AGENTS.md ..\AGENTS.md
+mklink .opencode\AGENTS.md ..\AGENTS.md
+mklink .cursor\AGENTS.md ..\AGENTS.md
+```
+
+**Git 管理**：
+```bash
+# 添加到 Git
+git add AGENTS.md
+git add .claude/AGENTS.md
+git add .opencode/AGENTS.md
+git add .cursor/AGENTS.md
+
+# 提交
+git commit -m "feat: add AGENTS.md for AI collaboration"
+```
+
+**Skills 目录**
+- 定义：可复用的 AI 能力单元
+- 组成：提示词、脚本、文档
+- 示例：
+```
+skills/
+├── commit-push/
+│   ├── SKILL.md
+│   └── commit.sh
+├── deploy/
+│   ├── SKILL.md
+│   └── deploy.sh
+└── test/
+    ├── SKILL.md
+    └── test.sh
+```
+
+**MCP 配置**
+- 定义：Model Context Protocol 配置
+- 作用：让 AI 访问外部工具
+- 示例：
+```json
+{
+  "mcpServers": {
+    "database": {
+      "command": "node",
+      "args": ["mcp-server-sqlite"]
+    },
+    "filesystem": {
+      "command": "node",
+      "args": ["mcp-server-filesystem", "/path/to/dir"]
+    }
+  }
+}
+```
+
+### 实践建议
+- **使用 AGENTS.md 作为统一入口**：所有 AI 工具从这个文件开始
+- **使用软链接**：让多个工具共享同一份配置
+- **纳入 Git 管理**：配置可版本化、可追溯
+- **建立 Skills 库**：沉淀常用的 AI 能力
+- **使用 MCP**：让 AI 访问外部工具
+
+---
+
+## 第28页：分隔页（附录&参考资料）
+
+### 原文内容
+章节分隔页，标志进入"附录&参考资料"部分
+
+### 研究要点
+- 提供进一步学习的资源
+- 包含实践心得和参考资料
+
+---
+
+## 第29页：关于 AI 编程实践的心得
+
+### 原文内容
+**两条核心心得**：
+
+1. **放弃"开箱即用"的框架**
+   - 每个项目需要构建自己 Harness 工具和文档
+   - 没有放之四海而皆准的解决方案
+   - 需要根据项目特点定制
+
+2. **"少量取用，大量实践"是更好的策略**
+   - 不要一开始就引入所有概念
+   - 先实践核心概念，再逐步扩展
+   - 实践出真知
+
+### 深入解读
+
+**为什么没有"开箱即用"的框架？**
+
+**原因1：项目差异大**
+- 技术栈不同：Java vs Python vs JavaScript
+- 团队规模不同：个人 vs 小团队 vs 大团队
+- 业务复杂度不同：简单 CRUD vs 复杂业务逻辑
+- 合规要求不同：内部项目 vs 金融项目 vs 医疗项目
+
+**原因2：AI 能力在快速演进**
+- 模型能力不断提升
+- 工具生态快速变化
+- 最佳实践还在形成中
+- 昨天的最佳实践可能今天已过时
+
+**原因3：团队文化差异**
+- 有的团队喜欢严格规范
+- 有的团队喜欢灵活自由
+- 有的团队重视文档
+- 有的团队重视代码
+
+**如何构建自己的 Harness？**
+
+**步骤1：从 AGENTS.md 开始**
+- 定义项目基本信息
+- 定义 AI 行为规则
+- 定义目录结构
+
+**步骤2：建立文档体系**
+- docs/standards/ - 标准规范
+- docs/features/ - 需求规格
+- docs/designs/ - 设计规格
+- docs/plans/ - 计划规格
+
+**步骤3：开发常用 Skills**
+- commit-push - 提交和推送代码
+- deploy - 部署到环境
+- test - 运行测试
+
+**步骤4：配置 MCP**
+- 数据库访问
+- 文件系统访问
+- 外部 API 访问
+
+**"少量取用，大量实践"的具体做法**
+
+**第一阶段：基础配置（1-2周）**
+- 建立 AGENTS.md
+- 建立基本文档结构
+- 配置一个 AI 工具（如 Claude Code）
+
+**第二阶段：核心实践（2-4周）**
+- 使用 AI 生成代码
+- 使用 AI 进行 Code Review
+- 使用 AI 编写测试
+
+**第三阶段：扩展应用（1-2月）**
+- 引入更多 AI 工具
+- 开发更多 Skills
+- 配置更多 MCP
+
+**第四阶段：持续优化（持续）**
+- 根据实践反馈优化配置
+- 沉淀最佳实践
+- 分享给团队
+
+### 实践建议
+- **不要追求完美**：先跑起来，再优化
+- **小步快跑**：每次只引入一个新概念
+- **记录实践**：记录什么有效，什么无效
+- **分享经验**：与团队分享实践经验
+- **持续学习**：关注 AI 编程领域的最新进展
+
+---
+
+## 第30页：参考资料
+
+### 原文内容
+**参考资料列表**：
+
+1. [Harness Engineering - OpenAI](https://openai.com/index/harness-engineering/)
+2. [Harness Engineering - Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
+3. [Anthropic: Harness Design for Long-running Apps](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+4. [从 Rule、Spec 到 Harness：AI Coding 的渐进式建设路径](https://mp.weixin.qq.com/s/UCh2bPzMZjNBMBCCJysuNw)
+5. [让 AI 乖乖听话的几个 Rules](https://mp.weixin.qq.com/s/FXNzk_y2Z2h8BVe62uEn_A)
+6. [Understanding SDD: Kiro, spec-kit, and Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+7. [harness-engineering-in-ai-coding](https://github.com/2361485765/harness-engineering-in-ai-coding)
+8. [attractor-guided-engineering-template](https://github.com/entropy-cloud/attractor-guided-engineering-template)
+9. [OpenAI: Tools Computer Use](https://developers.openai.com/api/docs/guides/tools-computer-use)
+
+### 深入解读
+
+**资料分类**
+
+**Harness Engineering 理论**：
+1. OpenAI 的文章：介绍 Harness Engineering 的概念和实践
+2. Martin Fowler 的文章：从软件工程角度阐述 Harness
+3. Anthropic 的文章：针对长时间运行应用的 Harness 设计
+
+**AI Coding 实践**：
+4. 微信公众号文章：从 Rule 到 Spec 到 Harness 的渐进式路径
+5. 微信公众号文章：让 AI 听话的 Rules 实践
+
+**SDD 框架**：
+6. Martin Fowler 的文章：对比 Kiro、spec-kit、Tessl 三个 SDD 框架
+
+**开源项目**：
+7. harness-engineering-in-ai-coding：Harness Engineering 实践项目
+8. attractor-guided-engineering-template：引导式工程模版
+
+**官方文档**：
+9. OpenAI 官方文档：Computer Use 工具使用指南
+
+**推荐阅读顺序**
+
+**入门阶段**：
+1. 先读第4、5篇微信公众号文章（中文，易理解）
+2. 再读 OpenAI 的 Harness Engineering 文章
+
+**进阶阶段**：
+3. 读 Martin Fowler 的 Harness Engineering 文章
+4. 读 Anthropic 的 Harness Design 文章
+5. 读 SDD 框架对比文章
+
+**实践阶段**：
+6. 参考开源项目实践
+7. 阅读官方文档
+
+**关键概念解释**
+
+**Harness Engineering**：
+- 定义：为 AI 提供约束和工具的工程实践
+- 目标：让 AI 在受控环境中高效工作
+- 核心：约束体系 + 工具体系
+
+**SDD（Spec-Driven Development）**：
+- 定义：以规格文档为核心的开发方法
+- 核心理念：Spec 是单一事实来源
+- 代表框架：Kiro、spec-kit、OpenSpec、BMAD
+
+**Rule/Spec/Harness 演进**：
+- Rule：约束 AI 行为的规则
+- Spec：结构化的需求描述
+- Harness：完整的约束和工具体系
+
+### 实践建议
+- **循序渐进**：按照推荐阅读顺序学习
+- **理论结合实践**：读完理论后动手实践
+- **关注官方文档**：获取最新信息
+- **参与社区**：关注开源项目和社区讨论
+
+---
+
+## 全文总结
+
+### 核心框架
+
+**团队级 AI Coding 的4个核心问题**：
+1. **需求衔接**：如何编写 AI 能理解的需求？
+2. **开发实现**：如何让 AI 生成高质量代码？
+3. **测试验收**：如何自动化测试 AI 生成的代码？
+4. **Agent as Code**：如何组织 AI 协作文件？
+
+**解决方案概览**：
+
+**需求衔接**：
+- 使用 Markdown 编写需求规格
+- 区分增量需求和存量需求
+- 使用字段清单和业务规则
+- 通过原型图传递 UI 设计
+
+**开发实现**：
+- 规则、规格、技能三要素
+- 构建 AI 上下文体系（AGENTS.md + docs/）
+- 区分过程方案（Plans）和事实方案（Designs）
+- 使用 MCP/Skills/CLI 调用外部工具
+- 选择合适的 AI 编程工具
+- 使用 SDD 框架（BMAD/SpecKit/OpenSpec/Kiro）
+- 使用 DSL 编写技术规格
+- 建立打样工程
+- 使用 Git Worktree 并行开发
+- 核心 Loop：Plan → TDD → 验证
+
+**测试验收**：
+- 分层测试：Lint → Code Review → 单元测试 → API 测试 → E2E 测试
+- AI 操作浏览器：Playwright MCP、Chrome DevTools MCP、Browser Use、Computer Use
+- 生成 E2E 测试：Browser Use 探索 → Playwright 固化 → 截图视觉兜底
+- 超级 Loop：在核心 Loop 基础上增加 E2E 测试验证
+
+**Agent as Code**：
+- 使用 AGENTS.md 作为统一入口
+- 建立文档体系（standards/features/plans/designs）
+- 开发 Skills 库
+- 配置 MCP
+- 使用软链接让多个工具共享配置
+
+### 关键工具
+
+**AI 编程工具**：
+- Claude Code、Cursor、Kiro、Trae、OpenCode、Codex CLI
+
+**SDD 框架**：
+- BMAD、Spec Kit、OpenSpec、Kiro
+
+**测试工具**：
+- Playwright、Browser Use、Karate、RestAssured
+
+**文档工具**：
+- PlantUML、OpenAPI、Markdown
+
+**协作工具**：
+- Git、GitHub、GitLab
+
+### 最佳实践
+
+**需求阶段**：
+- 使用 Markdown 编写需求
+- 区分增量和存量需求
+- 使用字段清单
+- 通过原型图传递 UI
+
+**开发阶段**：
+- 建立 AGENTS.md
+- 区分 Plans 和 Designs
+- 使用 DSL 编写技术规格
+- 建立打样工程
+- TDD 驱动开发
+
+**测试阶段**：
+- 分层测试
+- 先用 Browser Use 探索，再固化到 Playwright
+- 使用稳定的选择器
+- 关键页面截图验证
+
+**协作阶段**：
+- 使用 AGENTS.md 作为统一入口
+- 使用软链接共享配置
+- 纳入 Git 管理
+- 建立 Skills 库
+
+### 学习路径
+
+**入门（1-2周）**：
+1. 理解 AI 编程的5个发展阶段
+2. 建立 AGENTS.md
+3. 使用一个 AI 工具（如 Claude Code）
+4. 实践核心 Loop
+
+**进阶（1-2月）**：
+1. 学习 SDD 框架
+2. 使用 DSL 编写技术规格
+3. 建立打样工程
+4. 实践分层测试
+5. 使用 Playwright 进行 E2E 测试
+
+**高级（持续）**：
+1. 构建完整的 Harness 体系
+2. 开发自定义 Skills
+3. 配置 MCP 访问外部工具
+4. 优化 AI 工作流
+5. 分享实践经验
+
+### 关键洞察
+
+1. **AI 编程不是银弹**：需要工程化的方法来驾驭
+2. **上下文是关键**：AI 需要清晰的上下文才能生成高质量代码
+3. **测试是保障**：自动化测试是 AI 生成代码质量的保障
+4. **实践出真知**：没有放之四海而皆准的方案，需要根据项目特点定制
+5. **持续演进**：AI 能力在快速提升，方法也需要持续演进
+
+---
+
+## 附录：术语表
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| AI 编程 | AI Coding | 使用 AI 辅助或自动化进行软件开发 |
+| Harness | Harness | 为 AI 提供约束和工具的工程实践 |
+| SDD | Spec-Driven Development | 以规格文档为核心的开发方法 |
+| MCP | Model Context Protocol | AI 与外部系统通信的标准协议 |
+| AGENTS.md | AGENTS.md | AI 协作的宪法级配置文件 |
+| Plan | Plan | AI 执行任务的规划文档 |
+| Spec | Specification | 结构化的需求描述 |
+| Rule | Rule | 约束 AI 行为的规则 |
+| Skill | Skill | 可复用的 AI 能力单元 |
+| Loop | Loop | AI 自治运行的开发循环 |
+| TDD | Test-Driven Development | 测试驱动开发 |
+| E2E | End-to-End | 端到端测试 |
+| DSL | Domain Specific Language | 领域特定语言 |
+| Worktree | Git Worktree | Git 的多工作区功能 |
+| Browser Use | Browser Use | AI 操作浏览器的框架 |
+| Playwright | Playwright | 浏览器自动化测试框架 |
+| BMAD | Business Model Architecture Design | 企业级 SDD 框架 |
+| OpenSpec | OpenSpec | 轻量级 SDD 框架 |
+| Kiro | Kiro | AWS 推出的 AI IDE 和 SDD 框架 |
+
+---
+
+**文档信息**：
+- 原文：团队级 AI Coding 简明手册 v0.2
+- 研究日期：2026-06-20
+- 研究范围：第1-30页（全文）
+- 归档位置：/obsidian/AI工程/团队级AI_Coding简明手册_逐页研究/

AI工程/团队级AI_Coding简明手册v0.2.md

@@ -0,0 +1,323 @@
+# 团队级 AI Coding 简明手册 v0.2
+
+> 来源：系统设计研讨会分享 PPT（2026.06.18），版权归分享人所有
+> 归档日期：2026-06-20
+
+---
+
+## 一、AI 编程思想发展过程
+
+| 阶段 | 特征 | 模式 |
+|------|------|------|
+| **原始阶段** | 基于本能的 AI 编程，手动复制代码或通过问答交互 | 半自动，有人值守 |
+| **Rule 约束** | 经验规则显化（如 RIPER-5），通过持续对话输入需求 | 半自动 |
+| **规格驱动** | 需求结构化表达，基于规格流转（如 OpenSpec），文件进文件出 | 全自动过渡 |
+| **Loop Engineering** | 可反馈闭环：AI 根据验收规则自动循环 + 测试套件 | 全自动 |
+| **Harness 驾驭工程** | 纳入工程治理体系，提供约束体系 + 外部接口 | 全自动，Plan 后无人值守 |
+
+> 每一次思想的变更是对前者的重新表述而非推翻
+
+---
+
+## 二、AI 赋能软件开发实现地图
+
+```
+需求分析 → 需求文档/原型图 → 技术方案设计 → 代码框架+打样工程
+    ↓            ↓                ↓                ↓
+  人+AI        人+AI             人+AI            人+AI
+    ↓            ↓                ↓                ↓
+AI代码编写 → 单元测试/调试 → E2E测试 → Code Review → 提测部署
+    ↓            ↓              ↓           ↓           ↓
+  机           机+人           机+人        机+人        机+人
+```
+
+**核心 Loop**：研发自测阶段，AI 自治运行
+**全流程超级 Loop**：从需求到部署的完整闭环
+
+---
+
+## 三、四大核心问题
+
+### 01 需求衔接
+- 如何编写 AI 能理解的需求？
+- 使用什么格式？如何组织需求规格？
+- 如何传递原型图？需求模版长什么样？
+
+### 02 开发实现
+- 如何让 AI 理解上下文且按要求执行？
+- 如何调用外部工具？生成一致的代码？
+- 如何多任务同步开发？
+
+### 03 测试验收
+- AI 编程需要什么测试策略？
+- 如何让 AI 操作浏览器？
+- 如何管理测试用例？
+
+### 04 Agent as Code
+- 如何把和 AI 协作的文件在代码仓库中合理组织？
+- 构建 AI 更友好的环境
+
+---
+
+## 四、需求规格编写
+
+### 关键要素
+- **模块切分**（增量/存量）
+- **字段清单**
+- **原型链接**
+- **业务规则**
+
+### 编写原则
+1. 先写业务背景，再切模块。**一个模块 = 一个文档**
+2. 分解为增量需求和存量需求：
+   - **增量需求** — 全新功能，需新建模块
+   - **存量修改** — 对已有功能做变更
+3. 字段定义需完整：类型、必填、默认值、描述、校验规则、UI展示、数据来源
+4. 业务规则条目化 + 正交分解，每条规则独立可测
+
+> **Tips**: BA 也应该工作在代码仓库中，让 AI 基于当前系统事实构建新需求
+
+### 原型图设计
+- **设计工具输出**：Figma/Stitch URL 嵌入需求文档
+- **HTML+CSS 输出**：可交互原型提交到代码仓库
+- **Design.md**：约束 AI 生成的前端风格，确保与项目组件库一致
+
+---
+
+## 五、开发实现
+
+### 让 AI 听话的三要素
+
+| 要素 | 说明 | 示例 |
+|------|------|------|
+| **规则 Rules** | 约束 AI 行为边界 | Java 代码风格、命名规范 |
+| **规格 Specification** | 结构化需求，甚至用 DSL 描述 | 用户故事 + 验收标准 |
+| **技能 Skill** | 打包提示词/脚本/模版扩展能力 | Commit & Push Skill |
+
+### 构建 AI 上下文体系（详见下方重点章节）
+
+### 让 AI 调用外部工具的三种方式
+1. **CLI Commands** — 最直接，AI 生成命令并执行
+2. **MCP** — 标准协议，统一接入数据库/API/文件系统
+3. **Skills** — 脚本封装，触发词驱动
+
+### AI 编程工具选择
+- **命令行类**：Claude Code、Codex CLI、OpenCode
+- **AI IDE**：Cursor、Kiro、Trae
+- **增强插件**：Superpower、oh-my-opencode、oh-my-codex
+
+### SDD 框架对比
+
+| 维度 | BMAD | Spec Kit | OpenSpec | Kiro |
+|------|------|----------|----------|------|
+| 定位 | 企业级 SDD 操作系统 | 工程化 Spec 工作流 | 轻量 Spec 层 | IDE 原生 SDD |
+| Spec 粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+
+### 技术规格编写（DSL 驱动）
+
+| 模块 | 标准 | 格式 | 约束 |
+|------|------|------|------|
+| 领域模型 | PlantUML/Smart Domain | .puml | 必须表达实体关系 |
+| 数据库 | SQL DDL/DBML | .sql | 必须可执行 |
+| API | OpenAPI 3.x | .yaml/.json | 必须定义 schema |
+| 时序图 | PlantUML | .puml | 必须反映真实调用链 |
+| 专题设计 | Markdown | .md | 只写策略与规则 |
+
+### 打样工程：让 AI 抄作业
+- 原则：约定大于配置、编排逻辑和原子能力分离、操作者和被操作对象分离
+- 简单 CRUD：Controller + Command → AppService → Repository → Response
+- 复杂 CRUD：Controller + Command → AppService → DomainService → Repository → Response
+- 复杂查询：Controller + Query → AppService → QueryPO → Response
+
+### 多任务同步开发
+使用 `git worktree` 同时把多个分支映射到不同文件夹：
+```bash
+git worktree add -b feature-payment ../feature-payment
+```
+
+---
+
+## 六、⭐ 过程方案 vs 事实方案（重点）
+
+### 核心理念
+
+> 使用完整的文档来描述上下文和约束体系，**区分过程方案和事实方案，减少维护成本**。
+
+### 文档分层体系
+
+```
+AGENTS.md          ← 宪法级约束
+docs/
+├── standards/     ← 标准规格（架构/命名/API/安全规范）
+├── features/      ← 需求规格（产品/BA维护）
+├── designs/       ← 设计规格（DB/表等 Source of Truth）  ⬅ 事实方案
+├── plans/         ← 计划规格（每轮任务实现方案）          ⬅ 过程方案
+└── others/        ← 架构决策、Release、测试用例等
+```
+
+### 过程方案（Plans）
+
+**定义**：每一轮任务的实现方案、Tasking、工作状态。
+
+**特征**：
+- **临时性**：每次创建新文件，用完即弃
+- **不维护**：细微修改不再更新旧文件
+- **可追溯**：保留历史决策轨迹，方便复盘
+- **增量追加**：`追加: 每次创建一个新的文件`
+
+**示例**：
+```
+docs/plans/
+├── plan-2026-06-01-user-auth.md      # 第1轮
+├── plan-2026-06-05-user-auth-v2.md   # 第2轮迭代
+├── plan-2026-06-10-payment-flow.md   # 新任务
+└── plan-2026-06-15-order-module.md   # 新任务
+```
+
+**为什么这样设计**：
+1. 避免反复修改同一文件导致的 Git 冲突
+2. 保留完整决策轨迹，AI 和人都能回溯
+3. AI 执行完可以"丢弃"，不污染长期文档
+4. 降低维护成本——过程方案不需要维护
+
+**在 Plan/Go 模式中的角色**：
+- Plan 阶段产出 → 锁定上下文到 Plan 中
+- 记录实现状态，让任务可以分批完成或重试
+- 关闭所有开放性问题后再进入执行
+
+### 事实方案（Designs / Standards / Features）
+
+**定义**：反映系统**当前真实状态**的文档，是 Source of Truth。
+
+**特征**：
+- **长期有效**：稳定的、持续维护的
+- **最终态更新**：`变更: 每次以最终态更新`
+- **事实依据**：作为下一次 Plan 的起点
+- **必须一致**：与实际代码/系统保持同步
+
+**示例**：
+```
+docs/designs/
+├── database-schema.md      # 当前数据库表结构（最终态）
+├── api-endpoints.md        # 当前 API 定义（最终态）
+└── architecture.md         # 当前架构图（最终态）
+
+docs/standards/
+├── coding-style.md         # 编码规范
+└── security-guidelines.md  # 安全规范
+
+docs/features/
+├── user-management.md      # 用户管理需求（当前版本）
+└── order-system.md         # 订单系统需求（当前版本）
+```
+
+**为什么这样设计**：
+1. AI 每次 Plan 前读取这些文档，获得"当前真相"
+2. 避免 AI 基于过时信息做决策
+3. 只维护一份最终态，减少维护成本
+4. 是团队共识的载体
+
+### 规格流转图
+
+```
+起点 Features（需求规格）
+    ↓
+Standards（约束规范）
+    ↓
+TDD 驱动 → 测试 + 代码
+    ↓
+事实方案 Designs（更新最终态）  ← 变更：覆盖更新
+    ↓
+过程方案 Plans（执行记录）      ← 追加：新建文件
+    ↓
+回到起点 Features（验收）
+```
+
+### 实践建议
+
+1. **AGENTS.md 作为宪法**：定义 AI 行为边界和基本原则
+2. **区分"打算做"和"已做完"**：Plans 是意图，Designs 是事实
+3. **Plan 阶段尽可能锁定上下文**：关闭所有开放性问题
+4. **Plan 中记录实现状态**：让任务可以分批完成或重试
+5. **给出确定性验收方式**：如通过所有 API 测试，让 AI 建立自我修复标准
+
+---
+
+## 七、测试验收
+
+### AI 辅助测试策略
+
+| 测试类型 | 工具 | 负责人 |
+|----------|------|--------|
+| Lint 代码扫描 | TS Lint/SonarQube | 程序 |
+| Code Review | Copilot/Claude Code/CodeRabbit | 开发者 + AI |
+| 单元测试 | JUnit/pytest/Jest | 开发者 + AI |
+| API 测试 | Karate/RestAssured | QA + 后端 + AI |
+| E2E 测试 | Playwright | QA + 自动化 + AI |
+
+### AI 操作浏览器方案对比
+
+| 方案 | 原理 | 速度 | Token 消耗 | 跨应用 |
+|------|------|------|-----------|--------|
+| OpenWright (Playwright MCP) | Accessibility Tree | 快 ~0.9s | 高 | 仅浏览器 |
+| Chrome DevTools MCP | CDP 协议 | 中 ~1.2s | 中 | 仅浏览器 |
+| Browser Use | DOM + 截图双模 | 中 ~1.5s | 极低 | 仅浏览器 |
+| Computer Use | 视觉识别+坐标 | 慢 0.8-2s | 高 | 全桌面 |
+
+### E2E 测试生成策略
+1. **Browser Use 探索**：AI 自主遍历页面，记录操作轨迹（消耗 Token）
+2. **Playwright 固化**：转为测试脚本加入 CI（零 Token 可重复运行）
+3. **截图视觉兜底**：覆盖布局偏移、动效、Canvas 等场景
+
+### 核心 Loop（研发自测）
+```
+Plan 模式装载需求规格 → Plan 确认 → 编写 API 测试 → 编写实现
+    → 运行测试 → 通过？→ 退出循环
+                 ↓ 否
+              修复重试
+```
+
+### 超级 Loop（E2E Loop）
+在核心 Loop 基础上增加：
+- 编写测试用例（docs/test-cases）
+- 浏览器调试（Playwright 确认视觉效果）
+- 编写 E2E 测试覆盖本轮需求
+
+---
+
+## 八、Agent as Code
+
+### AI 工程文件管理
+```
+AGENTS.md          ← 宪法，构建引用关系
+docs/
+├── .ai/           ← AI 配置
+├── standards/     ← 标准规格
+├── features/      ← 需求规格
+├── designs/       ← 设计规格
+├── plans/         ← 计划规格
+├── skills/        ← AI 技能
+└── mcp/           ← MCP 配置
+
+.claude / .opencode / .cursor  → 软链到 AGENTS.md
+```
+
+---
+
+## 九、实践心得
+
+> - 放弃"开箱即用"的框架，每个项目需要构建自己的 Harness 工具和文档
+> - "少量取用，大量实践"是更好的策略
+
+---
+
+## 参考资料
+
+- [Harness Engineering - OpenAI](https://openai.com/index/harness-engineering/)
+- [Harness Engineering - Martin Fowler](https://martinfowler.com/articles/harness-engineering.html)
+- [Harness Design for Long-running Apps - Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps)
+- [从 Rule、Spec 到 Harness 的渐进式建设路径](https://mp.weixin.qq.com/s/UCh2bPzMZjNBMBCCJysuNw)
+- [Understanding SDD: Kiro, spec-kit, and Tessl](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
+- [harness-engineering-in-ai-coding](https://github.com/2361485765/harness-engineering-in-ai-coding)

AI工程/概念/AGENTS.md.md

@@ -0,0 +1,174 @@
+# AGENTS.md
+
+> 相关：[[Agent_as_Code]]、[[上下文体系]]、[[Harness工程]]
+
+## 定义
+
+**AGENTS.md**是AI协作的宪法级配置文件，定义AI的基本行为规则，所有AI工具都从这个文件开始。
+
+**核心思想**：AGENTS.md是AI的"宪法"，约束AI的行为边界。
+
+## 核心特征
+
+### 1. 宪法级
+- 最高优先级
+- 所有AI工具都读取
+- 定义基本行为规则
+
+### 2. 统一入口
+- AI从这个文件开始
+- 引用其他文档
+- 形成完整的上下文
+
+### 3. 可版本化
+- 纳入Git管理
+- 变更有历史记录
+- 可回滚
+
+## 内容结构
+
+### 基本信息
+```markdown
+# 项目信息
+- 项目名称：电商平台
+- 技术栈：Java 17, Spring Boot 3.x, React 18
+- 代码规范：阿里巴巴Java开发手册
+```
+
+### AI行为规则
+```markdown
+# AI行为规则
+1. 生成代码必须符合代码规范
+2. 数据库表必须包含created_at, updated_at字段
+3. API接口必须使用RESTful风格
+4. 敏感数据必须加密存储
+```
+
+### 目录结构
+```markdown
+# 目录结构
+- src/main/java/com/example/project/controller
+- src/main/java/com/example/project/service
+- src/main/java/com/example/project/repository
+```
+
+### 引用文件
+```markdown
+# 引用文件
+- 代码规范：./docs/standards/coding-style.md
+- API规范：./docs/standards/api-style.md
+- 数据库规范：./docs/standards/db-style.md
+```
+
+## 完整示例
+
+```markdown
+# 项目信息
+- 项目名称：电商平台
+- 技术栈：Java 17, Spring Boot 3.x, React 18
+- 代码规范：阿里巴巴Java开发手册
+
+# AI行为规则
+1. 生成代码必须符合代码规范
+2. 数据库表必须包含created_at, updated_at字段
+3. API接口必须使用RESTful风格
+4. 敏感数据必须加密存储
+5. 所有方法必须有注释
+6. 所有API必须有单元测试
+
+# 目录结构
+- src/main/java/com/example/project/controller
+- src/main/java/com/example/project/service
+- src/main/java/com/example/project/repository
+- src/main/java/com/example/project/domain
+- src/main/java/com/example/project/infrastructure
+
+# 引用文件
+- 代码规范：./docs/standards/coding-style.md
+- API规范：./docs/standards/api-style.md
+- 数据库规范：./docs/standards/db-style.md
+- 安全规范：./docs/standards/security.md
+
+# 开发流程
+1. Plan阶段：创建Plan文档，等待确认
+2. 执行阶段：按照Plan实现代码
+3. 验证阶段：运行测试，确保通过
+
+# 测试要求
+- 单元测试覆盖率 > 80%
+- 所有API必须有集成测试
+- 关键流程必须有E2E测试
+```
+
+## 配置位置
+
+### 项目根目录
+```
+项目根目录/
+├── AGENTS.md              # 宪法级配置
+├── .claude/
+│   └── AGENTS.md -> ../AGENTS.md  # 软链接
+├── .opencode/
+│   └── AGENTS.md -> ../AGENTS.md  # 软链接
+└── .cursor/
+    └── AGENTS.md -> ../AGENTS.md  # 软链接
+```
+
+### 软链接实现
+```bash
+# Linux/Mac
+ln -s ../AGENTS.md .claude/AGENTS.md
+ln -s ../AGENTS.md .opencode/AGENTS.md
+ln -s ../AGENTS.md .cursor/AGENTS.md
+
+# Windows
+mklink .claude\AGENTS.md ..\AGENTS.md
+mklink .opencode\AGENTS.md ..\AGENTS.md
+mklink .cursor\AGENTS.md ..\AGENTS.md
+```
+
+## Git管理
+
+```bash
+# 添加到Git
+git add AGENTS.md
+git add .claude/AGENTS.md
+git add .opencode/AGENTS.md
+git add .cursor/AGENTS.md
+
+# 提交
+git commit -m "feat: add AGENTS.md for AI collaboration"
+```
+
+## 适用场景
+
+- **团队协作**：多个开发者共享AI配置
+- **多项目**：在多个项目间复用配置
+- **持续迭代**：配置需要持续演进
+- **知识沉淀**：最佳实践需要沉淀
+
+## 优势
+
+- **统一入口**：所有AI工具从这个文件开始
+- **一致性**：所有AI工具行为一致
+- **可追溯**：配置变更有历史记录
+- **易维护**：修改一处，多处生效
+
+## 挑战
+
+- **初始成本**：需要建立完整的配置
+- **维护成本**：需要持续维护配置
+- **学习曲线**：团队需要理解配置
+
+## 最佳实践
+
+1. **从核心规则开始**：先定义最重要的规则
+2. **逐步扩展**：根据实践逐步添加配置
+3. **定期Review**：定期审查和优化配置
+4. **团队共享**：将配置纳入团队知识管理
+
+## 相关概念
+
+- [[Agent_as_Code]]：AGENTS.md是Agent as Code的核心文件
+- [[上下文体系]]：AGENTS.md是上下文体系的宪法级文件
+- [[Harness工程]]：AGENTS.md是Harness的组成部分

AI工程/概念/AI编程演进阶段.md

@@ -0,0 +1,67 @@
+# AI 编程演进阶段
+
+> 相关：[[团队级AI_Coding简明手册v0.2]]、[[Harness工程]]、[[Rule约束]]、[[规格驱动开发]]、[[Loop工程]]
+
+## 概述
+
+AI 编程从简单的手动复制粘贴，逐步演进到工程化的自动化开发体系。
+
+## 5 个阶段
+
+### 阶段1：原始阶段（本能驱动）
+- **特征**：手动从浏览器中复制 AI 的代码，通过问答和 AI IDE 交互
+- **方式**：人工复制粘贴，逐行审查
+- **效率**：低，依赖人工
+- **适用**：个人学习、简单脚本
+
+### 阶段2：Rule 约束（经验规则显化）
+- **特征**：定义 AI 在不同工作模式下的处理方式，如 RIPER-5
+- **方式**：通过 Rules 文件约束 AI 行为
+- **效率**：中等，需要持续对话输入需求
+- **适用**：个人项目、小团队
+
+### 阶段3：规格驱动（需求结构化表达）
+- **特征**：基于规格流转的开发方式，如 OpenSpec 框架
+- **方式**：文件进、文件出，结构化需求文档
+- **效率**：较高，AI 可理解完整上下文
+- **适用**：中型项目、团队协作
+
+### 阶段4：Loop 工程（闭环自动化）
+- **特征**：让 AI 能根据验收规则自动循环，构建测试套件
+- **方式**：TDD 驱动，AI 自治运行，自动修复
+- **效率**：高，半自动有人值守
+- **适用**：复杂项目、持续集成
+
+### 阶段5：Harness 驾驭工程（工程治理）
+- **特征**：把 AI 纳入工程治理体系，提供约束体系和外部接口
+- **方式**：完整的 Harness 体系，全自动 Plan 后无人值守
+- **效率**：最高，全自动无人值守
+- **适用**：企业级项目、大规模团队
+
+## 演进路径
+
+```
+原始 → Rule → 规格驱动 → Loop → Harness
+手动    规则    文档       自动    治理
+低效    中效    高效       自动    全自动
+```
+
+## 关键转变
+
+1. **从人工到自动**：减少人工干预
+2. **从对话到文档**：从口头需求到结构化规格
+3. **从单次到循环**：从一次性生成到持续迭代
+4. **从自由到约束**：从无约束到工程化治理
+
+## 实践建议
+
+- **小团队**：从 Rule 约束开始，逐步引入规格驱动
+- **中型团队**：采用规格驱动 + Loop 工程
+- **大型团队**：构建完整的 Harness 体系
+
+## 相关概念
+
+- [[Harness工程]]
+- [[核心Loop]]
+- [[规格驱动开发]]
+- [[Agent_as_Code]]

AI工程/概念/Agent_as_Code.md

@@ -0,0 +1,131 @@
+# Agent as Code
+
+> 相关：[[Harness工程]]、[[AGENTS.md]]、[[上下文体系]]、[[Skills]]
+
+## 定义
+
+**Agent as Code**是将AI协作的所有文件以代码的方式管理的理念，实现可版本化、可复用、可共享。
+
+**核心思想**：AI的行为由代码（配置文件）决定，而不是由人的临时提示决定。
+
+## 核心特征
+
+### 1. 可版本化
+- 所有配置纳入Git管理
+- 变更有历史记录
+- 可回滚到历史版本
+
+### 2. 可复用
+- 配置可在项目间复用
+- Skills可在团队间共享
+- 最佳实践可沉淀
+
+### 3. 可共享
+- 团队成员共享AI配置
+- 新成员快速上手
+- 统一团队AI行为
+
+## 核心文件
+
+### AGENTS.md（宪法级）
+```markdown
+# 项目信息
+- 项目名称：XXX
+- 技术栈：Java 17, Spring Boot 3.x
+
+# AI行为规则
+1. 代码必须符合规范
+2. 数据库表必须包含时间戳字段
+3. API必须使用RESTful风格
+```
+
+### Skills目录
+```
+skills/
+├── commit-push/
+│   ├── SKILL.md
+│   └── commit.sh
+├── deploy/
+│   ├── SKILL.md
+│   └── deploy.sh
+```
+
+### MCP配置
+```json
+{
+  "mcpServers": {
+    "database": {
+      "command": "node",
+      "args": ["mcp-server-sqlite"]
+    }
+  }
+}
+```
+
+## 实现方式
+
+### 软链接共享配置
+```bash
+# 让多个AI工具共享AGENTS.md
+ln -s ../AGENTS.md .claude/AGENTS.md
+ln -s ../AGENTS.md .opencode/AGENTS.md
+ln -s ../AGENTS.md .cursor/AGENTS.md
+```
+
+### Git管理
+```bash
+git add AGENTS.md
+git add .claude/AGENTS.md
+git commit -m "feat: add AGENTS.md for AI collaboration"
+```
+
+## 目录结构
+
+```
+项目根目录/
+├── AGENTS.md              # 宪法级配置
+├── docs/
+│   ├── standards/         # 标准规范
+│   ├── features/          # 需求规格
+│   ├── designs/           # 设计规格
+│   └── plans/             # 计划规格
+├── skills/                # AI技能
+├── mcp/                   # MCP配置
+├── .claude/               # Claude Code配置
+├── .opencode/             # OpenCode配置
+└── .cursor/               # Cursor配置
+```
+
+## 适用场景
+
+- **团队协作**：多个开发者共享AI配置
+- **多项目**：在多个项目间复用配置
+- **持续迭代**：配置需要持续演进
+- **知识沉淀**：最佳实践需要沉淀
+
+## 优势
+
+- **一致性**：所有AI工具行为一致
+- **可追溯**：配置变更有历史记录
+- **可复用**：Skills和配置可复用
+- **易维护**：修改一处，多处生效
+
+## 挑战
+
+- **初始成本**：需要建立完整的文档体系
+- **维护成本**：需要持续维护配置
+- **学习曲线**：团队需要理解Agent as Code理念
+
+## 最佳实践
+
+1. **从AGENTS.md开始**：先定义最基本的规则
+2. **逐步扩展**：根据实践逐步添加配置
+3. **定期Review**：定期审查和优化配置
+4. **团队共享**：将配置纳入团队知识管理
+
+## 相关概念
+
+- [[Harness工程]]：Agent as Code是Harness的技术实现
+- [[AGENTS.md]]：Agent as Code的核心文件
+- [[上下文体系]]：Agent as Code的文档组织
+- [[Skills]]：Agent as Code的能力单元

AI工程/概念/BMAD.md

@@ -0,0 +1,74 @@
+# BMAD
+
+> 相关：[[规格驱动开发]]、[[Spec_Kit]]、[[OpenSpec]]、[[Kiro]]
+
+## 定义
+
+**BMAD**（Business Model Architecture Design）是企业级SDD框架，提供强治理和多Agent编排能力。
+
+**核心思想**：Spec = 治理体系 + 多Agent编排，适合大型系统和多团队协作。
+
+## 核心特征
+
+### 1. 企业级定位
+- 强治理体系
+- 多Agent编排
+- 全生命周期管理
+
+### 2. 大粒度Spec
+- 系统级/模块级规格
+- 完整的架构设计
+- 详细的实现方案
+
+### 3. 强流程控制
+- 阶段+审批+Agent
+- 严格的变更控制
+- 完整的审计轨迹
+
+## 与其他SDD框架对比
+
+| 维度 | BMAD | [[Spec_Kit]] | [[OpenSpec]] | [[Kiro]] |
+|------|------|--------------|--------------|----------|
+| 方法定位 | 企业级SDD操作系统 | 工程化Spec工作流 | 轻量Spec层 | IDE原生SDD |
+| 核心理念 | Spec = 治理体系 + 多Agent编排 | Spec = 开发入口 + Git生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
+| Spec生命周期 | 全生命周期 | 与分支绑定（短生命周期） | 长期存在（持续演化） | 持续驱动 |
+| Spec粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 可执行能力 | 通过流程驱动 | 驱动开发流程 | 类Prompt | 可生成代码+测试并自动校验 |
+| 流程控制 | 强（阶段+审批+Agent） | 中（Plan→Spec→Tasks） | 弱（自由演化） | 强（闭环） |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 与代码关系 | 间接 | 半耦合 | 弱耦合 | 强耦合 |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+| 失控风险 | 低 | 中 | 高 | 中 |
+
+## 适用场景
+
+- **大型系统**：需要完整的架构设计
+- **多团队协作**：需要强治理体系
+- **企业级项目**：需要严格的变更控制
+- **合规要求高**：需要完整的审计轨迹
+
+## 优势
+
+- **强治理**：完整的治理体系
+- **多Agent编排**：支持多个AI Agent协同
+- **全生命周期**：覆盖从需求到交付的全流程
+- **失控风险低**：严格的流程控制
+
+## 挑战
+
+- **学习曲线陡峭**：需要理解完整的框架
+- **初始成本高**：需要建立完整的治理体系
+- **灵活性低**：流程严格，不够灵活
+- **维护成本高**：需要持续维护治理体系
+
+## 最佳实践
+
+1. **适合大型团队**：小型团队不建议使用
+2. **逐步引入**：不要一开始就引入所有概念
+3. **培训团队**：团队成员需要充分培训
+4. **持续优化**：根据实践持续优化流程
+
+## 相关概念
+
+- [[规格驱动开发]]：BMAD是SDD框架之一
+- [[Spec_Kit]]、[[OpenSpec]]、[[Kiro]]：其他SDD框架

AI工程/概念/Browser_Use.md

@@ -0,0 +1,144 @@
+# Browser Use
+
+> 相关：[[测试策略金字塔]]、[[Playwright]]、[[Computer_Use]]、[[MCP]]
+
+## 定义
+
+**Browser Use**是一个Python框架，让AI可以自主操作浏览器，支持DOM和截图双模式。
+
+**核心思想**：AI自主决策循环，支持DOM和截图双模，Token消耗极低。
+
+## 核心特征
+
+### 1. Python框架
+- 基于Playwright
+- AI自主决策循环
+- 易于集成到Python项目
+
+### 2. 双模式支持
+- DOM模式：结构化DOM快照
+- 截图模式：视觉理解
+- 可以混合使用
+
+### 3. 极低Token消耗
+- CLI模式~75 tok/步
+- 比其他方案低很多
+- 成本敏感项目首选
+
+## 原理
+
+```
+AI决策
+  ↓
+Browser Use框架
+  ↓
+Playwright操作浏览器
+  ↓
+获取DOM/截图
+  ↓
+AI分析结果
+  ↓
+下一步操作
+```
+
+## 与其他方案对比
+
+| 维度 | Browser Use | Playwright MCP | Chrome DevTools MCP | Computer Use |
+|------|-------------|----------------|---------------------|--------------|
+| 原理 | Python框架 + Playwright，AI自主决策循环 | 通过Playwright访问浏览器Accessibility Tree | 通过Chrome DevTools Protocol直接与浏览器引擎通信 | AI截取屏幕截图 → 视觉识别元素 → 输出坐标/按键操作 |
+| 抽象层 | DOM + 截图 视觉 + 结构化混合 | Accessibility Tree 结构化DOM快照 | CDP Protocol DevTools协议原生 | 截图 + 坐标 OS级视觉理解 |
+| 速度 | 中 ~1.5s/步 | 快 ~0.9s/步 | 中 ~1.2s/步 | 慢 0.8-2s/步 |
+| Token消耗 | 极低 CLI模式 ~75 tok/步 | 高 截图+结构全传 | 中 按需取数据 | 高 截图编码开销大 |
+| JS重页面 | 中 — 视觉兜底 | 中 — DOM可读 | 中 — CDP可取 | 高 — 视觉理解 |
+| 跨应用操作 | 仅浏览器 | 仅浏览器 | 仅浏览器 | 全桌面 |
+
+## 使用示例
+
+### 基本使用
+```python
+from browser_use import Agent
+
+agent = Agent(
+    task="Go to Reddit, search for 'r/LocalLLaMA' and click on the first post",
+    llm=llm
+)
+
+result = await agent.run()
+print(result)
+```
+
+### 原始指令
+```python
+agent = Agent(
+    task="""
+    1. 打开 /login 页面
+    2. 输入用户名 test@example.com
+    3. 输入密码 123456
+    4. 点击登录按钮
+    5. 验证跳转到 /dashboard
+    6. 验证页面显示 "Welcome"
+    """,
+    llm=llm
+)
+```
+
+### AI探索后生成的Playwright脚本雏形
+```typescript
+test('login flow', async ({ page }) => {
+  await page.goto('/login');
+  await page.fill('[name="email"]', 'test@example.com');
+  await page.fill('[name="password"]', '123456');
+  await page.click('button[type="submit"]');
+  await expect(page).toHaveURL('/dashboard');
+  await expect(page.locator('text=Welcome')).toBeVisible();
+});
+```
+
+## E2E测试生成三步法
+
+### Step 1: Browser Use探索
+- AI自主遍历页面，记录操作轨迹、选择器、页面状态
+- 输出Playwright脚本雏形
+- 消耗Token
+
+### Step 2: Playwright E2E固化
+- 将探索结果转为Playwright测试脚本
+- 加入CI，零Token可重复运行
+
+### Step 3: 截图视觉兜底
+- Playwright覆盖不到的视觉场景（布局、动效、图表）
+- 重回截图判断
+
+## 适用场景
+
+- **Token成本敏感**：极低Token消耗
+- **复杂网页自动化**：需要视觉理解
+- **E2E测试探索**：快速生成测试脚本雏形
+- **网页数据抓取**：自动化数据提取
+
+## 优势
+
+- **Token消耗极低**：CLI模式~75 tok/步
+- **AI自主决策**：无需手动编写脚本
+- **支持视觉理解**：可以处理复杂视觉场景
+- **易于集成**：Python框架，易于集成到项目
+
+## 挑战
+
+- **仅限浏览器**：不能操作其他应用
+- **依赖Python**：需要Python生态
+- **学习成本**：需要了解框架使用
+
+## 最佳实践
+
+1. **Token成本敏感首选**：极低Token消耗
+2. **先用Browser Use探索**：快速生成测试脚本雏形
+3. **人工审查后固化**：优化选择器，加入CI/CD
+4. **关键页面截图验证**：视觉回归测试
+
+## 相关概念
+
+- [[测试策略金字塔]]：Browser Use是E2E测试的工具
+- [[Playwright]]：Browser Use基于Playwright
+- [[Computer_Use]]：Browser Use和Computer Use的对比
+- [[MCP]]：Browser Use和MCP的对比

AI工程/概念/Claude_Code.md

@@ -0,0 +1,73 @@
+# Claude Code
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[Cursor]]、[[Kiro]]、[[Trae]]
+
+## 定义
+
+**Claude Code**是Anthropic推出的AI编程工具，基于Claude模型，提供强大的推理能力和长上下文支持。
+
+**核心思想**：强大的推理能力，支持长上下文，内置MCP支持，Loop模式。
+
+## 核心特征
+
+### 1. 强大的推理能力
+- 基于Claude模型
+- 强大的逻辑推理
+- 适合复杂逻辑
+
+### 2. 长上下文支持
+- 支持超长上下文
+- 可以理解完整项目
+- 适合大型项目
+
+### 3. 内置MCP支持
+- 原生支持MCP协议
+- 可以访问外部工具
+- 即插即用
+
+### 4. Loop模式
+- 支持自治运行
+- 自动修复问题
+- 持续迭代
+
+## 与其他AI工具对比
+
+| 工具 | 类型 | 价格 | AI模型 | 适用场景 |
+|------|------|------|--------|---------|
+| Claude Code | CLI | 按Token | Claude | 复杂逻辑 |
+| [[Cursor]] | IDE | $20/月 | 多模型 | 日常开发 |
+| [[Kiro]] | IDE | 免费+付费 | Claude | AWS项目 |
+| [[Trae]] | IDE | 免费+付费 | 豆包 | 中文项目 |
+
+## 适用场景
+
+- **复杂逻辑**：需要强大的推理能力
+- **大型项目**：需要长上下文支持
+- **架构设计**：需要理解完整架构
+- **问题排查**：需要深入分析问题
+
+## 优势
+
+- **推理能力强**：适合复杂逻辑
+- **长上下文**：可以理解完整项目
+- **MCP支持**：可以访问外部工具
+- **Loop模式**：支持自治运行
+
+## 挑战
+
+- **按Token计费**：成本可能较高
+- **CLI界面**：不如IDE直观
+- **学习曲线**：需要了解CLI使用
+
+## 最佳实践
+
+1. **复杂逻辑首选**：推理能力最强
+2. **长上下文利用**：充分利用长上下文能力
+3. **MCP配置**：配置必要的MCP Server
+4. **Loop模式**：充分利用Loop模式
+
+## 相关概念
+
+- [[Harness工程]]：Claude Code是Harness的工具之一
+- [[Agent_as_Code]]：Claude Code支持Agent as Code
+- [[Cursor]]、[[Kiro]]、[[Trae]]：其他AI编程工具

AI工程/概念/Computer_Use.md

@@ -0,0 +1,120 @@
+# Computer Use
+
+> 相关：[[测试策略金字塔]]、[[Browser_Use]]、[[Playwright]]、[[MCP]]
+
+## 定义
+
+**Computer Use**是Anthropic推出的OS级视觉操作方案，让AI可以操作任何桌面应用。
+
+**核心思想**：AI截取屏幕截图 → 视觉识别元素 → 输出坐标/按键操作 → 沙箱执行。
+
+## 核心特征
+
+### 1. OS级通用
+- 可以操作任何应用
+- 不限于浏览器
+- 桌面级操作
+
+### 2. 视觉理解
+- 基于截图识别元素
+- 输出坐标和按键
+- 强大的视觉理解能力
+
+### 3. 沙箱执行
+- 在沙箱环境中执行
+- 安全性高
+- 可控制
+
+## 原理
+
+```
+AI截取屏幕截图
+  ↓
+视觉识别元素
+  ↓
+输出坐标/按键操作
+  ↓
+沙箱执行
+  ↓
+返回结果
+```
+
+## 与其他方案对比
+
+| 维度 | Computer Use | Playwright MCP | Chrome DevTools MCP | Browser Use |
+|------|--------------|----------------|---------------------|-------------|
+| 原理 | AI截取屏幕截图 → 视觉识别元素 → 输出坐标/按键操作 | 通过Playwright访问浏览器Accessibility Tree | 通过Chrome DevTools Protocol直接与浏览器引擎通信 | Python框架 + Playwright，AI自主决策循环 |
+| 抽象层 | 截图 + 坐标 OS级视觉理解 | Accessibility Tree 结构化DOM快照 | CDP Protocol DevTools协议原生 | DOM + 截图 视觉 + 结构化混合 |
+| 速度 | 慢 0.8-2s/步 | 快 ~0.9s/步 | 中 ~1.2s/步 | 中 ~1.5s/步 |
+| Token消耗 | 高 截图编码开销大 | 高 截图+结构全传 | 中 按需取数据 | 极低 CLI模式 ~75 tok/步 |
+| JS重页面 | 高 — 视觉理解 | 中 — DOM可读 | 中 — CDP可取 | 中 — 视觉兜底 |
+| 跨应用操作 | 全桌面 | 仅浏览器 | 仅浏览器 | 仅浏览器 |
+
+## 使用示例
+
+### 基本使用
+```python
+from anthropic import Anthropic
+
+client = Anthropic()
+
+response = client.messages.create(
+    model="claude-3-5-sonnet-20241022",
+    max_tokens=1024,
+    tools=[{
+        "type": "computer_20241022",
+        "name": "computer",
+        "display_width_px": 1024,
+        "display_height_px": 768,
+    }],
+    messages=[{
+        "role": "user",
+        "content": "Open Chrome and go to google.com"
+    }]
+)
+```
+
+## 适用场景
+
+- **桌面应用自动化**：操作任何桌面应用
+- **需要跨应用操作**：多个应用协同
+- **复杂视觉场景**：需要视觉理解
+- **无法使用API的场景**：没有API的应用
+
+## 优势
+
+- **可以操作任何应用**：不限于浏览器
+- **可以处理复杂的视觉场景**：视觉理解能力强
+- **OS级通用**：桌面级操作
+
+## 挑战
+
+- **速度慢**：0.8-2s/步
+- **Token消耗高**：截图编码开销大
+- **依赖视觉识别准确性**：可能误识别
+- **成本高**：Token消耗大
+
+## 最佳实践
+
+1. **需要跨应用选Computer Use**：OS级通用
+2. **复杂视觉场景选Computer Use**：视觉理解能力强
+3. **成本敏感不选Computer Use**：Token消耗高
+4. **速度要求高不选Computer Use**：速度慢
+
+## 方案选择指南
+
+| 场景 | 推荐方案 | 理由 |
+|------|---------|------|
+| E2E测试 | Playwright MCP | 速度快，结构化信息丰富 |
+| 性能分析 | Chrome DevTools MCP | 可以监控网络和性能 |
+| 网页自动化 | Browser Use | Token消耗低，AI自主决策 |
+| 桌面应用 | Computer Use | 可以操作任何应用 |
+| Token成本敏感 | Browser Use | 极低Token消耗 |
+| 复杂视觉场景 | Computer Use | 视觉理解能力强 |
+
+## 相关概念
+
+- [[测试策略金字塔]]：Computer Use是测试的工具
+- [[Browser_Use]]：Computer Use和Browser Use的对比
+- [[Playwright]]：Computer Use和Playwright的对比
+- [[MCP]]：Computer Use和MCP的对比

AI工程/概念/Cursor.md

@@ -0,0 +1,73 @@
+# Cursor
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[Claude_Code]]、[[Kiro]]、[[Trae]]
+
+## 定义
+
+**Cursor**是基于VS Code的AI IDE，提供AI优先的开发体验。
+
+**核心思想**：基于VS Code，AI优先设计，强大的代码补全，Composer模式。
+
+## 核心特征
+
+### 1. 基于VS Code
+- 熟悉的IDE界面
+- 丰富的插件生态
+- 易于上手
+
+### 2. AI优先设计
+- AI深度集成
+- 智能代码补全
+- 上下文感知
+
+### 3. Composer模式
+- 多文件编辑
+- 智能重构
+- 批量修改
+
+### 4. 多模型支持
+- 支持多种AI模型
+- 可以切换模型
+- 灵活选择
+
+## 与其他AI工具对比
+
+| 工具 | 类型 | 价格 | AI模型 | 适用场景 |
+|------|------|------|--------|---------|
+| [[Claude_Code]] | CLI | 按Token | Claude | 复杂逻辑 |
+| Cursor | IDE | $20/月 | 多模型 | 日常开发 |
+| [[Kiro]] | IDE | 免费+付费 | Claude | AWS项目 |
+| [[Trae]] | IDE | 免费+付费 | 豆包 | 中文项目 |
+
+## 适用场景
+
+- **日常开发**：最常用的开发工具
+- **代码补全**：需要智能代码补全
+- **多文件编辑**：需要批量修改
+- **团队协作**：需要熟悉的IDE环境
+
+## 优势
+
+- **熟悉界面**：基于VS Code，易于上手
+- **AI集成**：AI深度集成
+- **代码补全**：强大的代码补全
+- **多模型**：支持多种AI模型
+
+## 挑战
+
+- **付费**：需要$20/月
+- **资源消耗**：可能消耗较多资源
+- **依赖网络**：需要网络连接
+
+## 最佳实践
+
+1. **日常开发首选**：最适合作为日常开发工具
+2. **代码补全利用**：充分利用智能代码补全
+3. **Composer模式**：充分利用多文件编辑能力
+4. **模型选择**：根据需求选择合适的模型
+
+## 相关概念
+
+- [[Harness工程]]：Cursor是Harness的工具之一
+- [[Agent_as_Code]]：Cursor支持Agent as Code
+- [[Claude_Code]]、[[Kiro]]、[[Trae]]：其他AI编程工具

AI工程/概念/Git_Worktree.md

@@ -0,0 +1,125 @@
+# Git Worktree
+
+> 相关：[[Harness工程]]、[[核心Loop]]、[[超级Loop]]
+
+## 定义
+
+**Git Worktree**是Git的一个功能，允许从同一个仓库检出多个工作目录，每个工作目录都是一个独立的分支。
+
+**核心思想**：共享同一个.git目录，节省磁盘空间，实现多任务并行开发。
+
+## 核心特征
+
+### 1. 多工作区
+- 一个仓库，多个工作目录
+- 每个工作目录是一个独立分支
+- 共享同一个.git目录
+
+### 2. 并行开发
+- 多个AI实例可以同时工作
+- 互不干扰
+- 快速切换
+
+### 3. 节省空间
+- 共享.git目录
+- 不需要克隆多个仓库
+- 节省磁盘空间
+
+## 基本命令
+
+### 创建Worktree
+```bash
+# 基于已有分支创建
+git worktree add ../feature-login feature/login
+
+# 创建新分支 + 工作区（最常用）
+git worktree add -b feature-payment ../feature-payment
+
+# 查看所有worktree
+git worktree list
+
+# 删除工作区
+git worktree remove ../feature-login
+```
+
+### 管理Worktree
+```bash
+# 列出所有工作区
+git worktree list
+# 输出：
+# /project/main              abc1234 [main]
+# /project/feature-a         def5678 [feature-a]
+# /project/feature-b         ghi9012 [feature-b]
+
+# 删除工作区
+git worktree remove ../feature-a
+
+# 强制删除（即使有未提交的更改）
+git worktree remove --force ../feature-a
+
+# 清理已删除的工作区记录
+git worktree prune
+```
+
+## 使用场景
+
+### 场景1：多AI实例并行开发
+```bash
+# 主工作区：开发功能A
+cd /project/feature-a
+claude-code # 启动Claude Code
+
+# 新开终端：开发功能B
+cd /project/feature-b
+claude-code # 启动另一个Claude Code实例
+
+# 再开终端：开发功能C
+cd /project/feature-c
+claude-code # 启动第三个Claude Code实例
+```
+
+### 场景2：AI + 人工并行开发
+```bash
+# AI在feature-a开发
+cd /project/feature-a
+claude-code
+
+# 人工在main分支修复紧急bug
+cd /project/main
+# 手动修复bug
+```
+
+### 场景3：Code Review时继续开发
+```bash
+# 主工作区：feature-a提交PR，等待review
+# 新开工作区：继续开发feature-b
+git worktree add -b feature-b ../feature-b
+cd ../feature-b
+claude-code
+```
+
+## 优势
+
+1. **并行开发**：多个AI实例可以同时工作在不同分支
+2. **上下文隔离**：每个功能的上下文独立，不会混淆
+3. **快速切换**：不需要`git checkout`，直接切换目录
+4. **节省空间**：共享.git目录
+
+## 挑战
+
+- **分支管理**：需要管理多个分支
+- **冲突处理**：可能需要处理分支冲突
+- **学习成本**：需要了解Git Worktree概念
+
+## 最佳实践
+
+1. **命名规范**：工作区目录名与分支名一致
+2. **及时清理**：完成的功能及时删除Worktree
+3. **AI工具支持**：利用AI工具的自动Worktree功能
+4. **定期Prune**：定期清理无效的工作区记录
+
+## 相关概念
+
+- [[Harness工程]]：Git Worktree是Harness的组成部分
+- [[核心Loop]]：Git Worktree支持并行执行多个Loop
+- [[超级Loop]]：Git Worktree支持并行执行多个超级Loop

AI工程/概念/Harness工程.md

@@ -0,0 +1,114 @@
+# Harness工程（驾驭工程）
+
+> 相关：[[AI编程演进阶段]]、[[Agent_as_Code]]、[[核心Loop]]、[[上下文体系]]
+
+## 定义
+
+**Harness工程**是AI编程的第5阶段，将AI纳入工程治理体系，为其提供约束体系和外部接口，实现全自动无人值守的开发。
+
+**核心思想**：不是让AI更聪明，而是让AI在受控环境中工作。
+
+## 核心特征
+
+### 1. 约束体系
+- **规则约束**：Rules定义AI能做什么、不能做什么
+- **规格约束**：Spec定义需求和设计的边界
+- **测试约束**：自动化测试验证AI输出质量
+
+### 2. 外部接口
+- **MCP**：让AI访问数据库、文件系统等外部工具
+- **Skills**：可复用的能力单元
+- **CLI**：命令行工具集成
+
+### 3. 自动化流程
+- **Plan阶段**：人机协作，锁定需求
+- **执行阶段**：AI自治，无需人工介入
+- **验证阶段**：自动化测试，自动修复
+
+## 关键原则
+
+### 约束大于提示
+- 不要依赖AI的"聪明"
+- 通过约束体系保证质量
+- 规则 > 提示词
+
+### 文档即代码
+- AGENTS.md作为宪法
+- 规格文档可版本化
+- 所有配置纳入Git
+
+### 持续验证
+- TDD驱动开发
+- 自动化测试覆盖
+- 持续集成持续交付
+
+## 组成部分
+
+```
+Harness = 约束体系 + 工具体系 + 验证体系
+
+约束体系：
+  - Rules（规则）
+  - Specs（规格）
+  - Standards（标准）
+
+工具体系：
+  - MCP（外部工具）
+  - Skills（能力单元）
+  - CLI（命令行）
+
+验证体系：
+  - 单元测试
+  - API测试
+  - E2E测试
+  - Code Review
+```
+
+## 适用场景
+
+- **企业级项目**：需要严格的质量控制
+- **多团队协作**：需要统一的开发规范
+- **长期维护**：需要持续的代码质量保证
+- **合规要求**：金融、医疗等需要审计的场景
+
+## 实践要点
+
+### 1. 建立文档体系
+```
+AGENTS.md          ← 宪法
+docs/
+├── standards/     ← 标准规格
+├── features/      ← 需求规格
+├── designs/       ← 设计规格（事实方案）
+└── plans/         ← 计划规格（过程方案）
+```
+
+### 2. 配置工具链
+- 选择合适的AI工具（Claude Code/Cursor/Kiro）
+- 配置MCP访问外部工具
+- 开发Skills封装常用能力
+
+### 3. 建立验证流程
+- 定义测试策略
+- 配置CI/CD流程
+- 建立Code Review规范
+
+## 优势
+
+- **质量可控**：通过约束体系保证代码质量
+- **可追溯**：所有配置和变更有历史记录
+- **可复用**：Skills和配置可在项目间复用
+- **可扩展**：易于引入新的工具和流程
+
+## 挑战
+
+- **学习曲线**：需要理解完整的工程体系
+- **维护成本**：需要持续维护文档和配置
+- **工具依赖**：依赖多个AI工具和协议
+
+## 相关概念
+
+- [[Agent_as_Code]]：Harness的技术实现方式
+- [[核心Loop]]：Harness中的开发循环
+- [[上下文体系]]：Harness的文档组织
+- [[AI编程演进阶段]]：Harness是第5阶段

AI工程/概念/Kiro.md

@@ -0,0 +1,73 @@
+# Kiro
+
+> 相关：[[规格驱动开发]]、[[BMAD]]、[[Spec_Kit]]、[[OpenSpec]]
+
+## 定义
+
+**Kiro**是AWS推出的AI IDE和SDD框架，提供IDE原生的SDD能力。
+
+**核心思想**：Spec = 可执行源（代码与测试），可以生成代码+测试并自动校验。
+
+## 核心特征
+
+### 1. IDE原生
+- 深度集成IDE
+- 原生SDD支持
+- 无缝开发体验
+
+### 2. 可执行Spec
+- Spec可以直接生成代码
+- Spec可以直接生成测试
+- 自动校验
+
+### 3. 强流程控制
+- 闭环流程
+- 自动验证
+- 高度自动化
+
+## 与其他SDD框架对比
+
+| 维度 | [[BMAD]] | [[Spec_Kit]] | [[OpenSpec]] | Kiro |
+|------|----------|--------------|--------------|----------|
+| 方法定位 | 企业级SDD操作系统 | 工程化Spec工作流 | 轻量Spec层 | IDE原生SDD |
+| 核心理念 | Spec = 治理体系 + 多Agent编排 | Spec = 开发入口 + Git生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
+| Spec生命周期 | 全生命周期 | 与分支绑定（短生命周期） | 长期存在（持续演化） | 持续驱动 |
+| Spec粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 可执行能力 | 通过流程驱动 | 驱动开发流程 | 类Prompt | 可生成代码+测试并自动校验 |
+| 流程控制 | 强（阶段+审批+Agent） | 中（Plan→Spec→Tasks） | 弱（自由演化） | 强（闭环） |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 与代码关系 | 间接 | 半耦合 | 弱耦合 | 强耦合 |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+| 失控风险 | 低 | 中 | 高 | 中 |
+
+## 适用场景
+
+- **小团队**：不需要强治理
+- **高自动化需求**：需要自动验证
+- **AWS项目**：深度集成AWS服务
+- **新项目**：从零开始的项目
+
+## 优势
+
+- **IDE原生**：无缝开发体验
+- **可执行Spec**：Spec可以直接生成代码和测试
+- **自动验证**：内建自动验证
+- **高度自动化**：减少人工干预
+
+## 挑战
+
+- **IDE绑定**：依赖特定IDE
+- **学习成本**：需要了解Kiro的工作流
+- **灵活性低**：不如OpenSpec灵活
+
+## 最佳实践
+
+1. **适合小团队**：小型团队最适合
+2. **高自动化**：充分利用自动验证能力
+3. **AWS集成**：充分利用AWS集成能力
+4. **持续学习**：持续学习Kiro的最佳实践
+
+## 相关概念
+
+- [[规格驱动开发]]：Kiro是SDD框架之一
+- [[BMAD]]、[[Spec_Kit]]、[[OpenSpec]]：其他SDD框架

AI工程/概念/Loop工程.md

@@ -0,0 +1,98 @@
+# Loop工程
+
+> 相关：[[核心Loop]]、[[超级Loop]]、[[Harness工程]]、[[测试策略金字塔]]
+
+## 定义
+
+**Loop工程**是AI编程的第4阶段，通过构建测试套件和验收规则，让AI能够根据验收规则自动循环，实现半自动有人值守的开发。
+
+**核心思想**：让AI能根据验收规则自动循环，构建测试套件，定义输出结果。
+
+## 核心特征
+
+### 1. 自动循环
+- AI根据验收规则自动运行
+- 失败时自动修复并重试
+- 直到满足退出条件
+
+### 2. 测试驱动
+- TDD驱动开发
+- 先写测试再写代码
+- 测试作为验收标准
+
+### 3. 有人值守
+- Plan阶段需要人工确认
+- 执行阶段AI自治
+- 异常时需要人工介入
+
+## Loop类型
+
+### [[核心Loop]]
+- 范围：API测试
+- 验证：后端逻辑
+- 复杂度：中等
+- 适用：后端开发
+
+### [[超级Loop]]
+- 范围：API测试 + E2E测试
+- 验证：前后端联动
+- 复杂度：高
+- 适用：全栈开发
+
+## Loop流程
+
+```
+Plan阶段（人机协作）
+    ↓
+装载需求规格 → 创建Plan → 确认Plan
+    ↓
+执行阶段（AI自治）
+    ↓
+编写测试 → 编写实现 → 运行测试
+    ↓                              ↓
+    ↓ 失败                        ↓ 成功
+    ↓                              ↓
+修复重试 ←──────────────────── 退出循环
+```
+
+## 退出条件
+
+1. 所有测试通过
+2. 代码符合规范（Lint通过）
+3. 没有编译错误
+4. 满足验收标准
+
+## 适用场景
+
+- **复杂项目**：需要自动化开发流程
+- **持续集成**：需要持续交付
+- **团队协作**：需要统一的开发流程
+- **质量保证**：需要严格的测试覆盖
+
+## 优势
+
+- **自动化**：减少人工干预
+- **质量保证**：TDD驱动，代码质量有保障
+- **可追溯**：Plan记录了实现过程
+- **持续迭代**：可以快速修复问题
+
+## 挑战
+
+- **Plan质量**：Plan阶段需要充分沟通
+- **测试覆盖**：需要编写全面的测试
+- **运行时间**：Loop可能需要较长时间
+- **调试复杂**：失败时需要调试
+
+## 最佳实践
+
+1. **Plan阶段充分沟通**：关闭所有开放性问题
+2. **TDD驱动**：先写测试再写代码
+3. **记录状态**：方便复盘和优化
+4. **逐步扩展**：从核心Loop开始，逐步引入超级Loop
+
+## 相关概念
+
+- [[核心Loop]]：Loop工程的具体实现
+- [[超级Loop]]：Loop工程的扩展实现
+- [[Harness工程]]：Loop工程是Harness的组成部分
+- [[测试策略金字塔]]：Loop工程使用的测试策略

AI工程/概念/MCP.md

@@ -0,0 +1,157 @@
+# MCP（Model Context Protocol）
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[Skills]]
+
+## 定义
+
+**MCP**（Model Context Protocol）是AI与外部系统通信的标准协议，由Anthropic提出。
+
+**核心思想**：标准化接口、双向通信、即插即用，让AI可以访问外部工具。
+
+## 核心特征
+
+### 1. 标准化接口
+- 统一的协议规范
+- 跨工具兼容
+- 易于扩展
+
+### 2. 双向通信
+- AI可以调用外部工具
+- 外部工具可以返回结果
+- 支持流式通信
+
+### 3. 即插即用
+- 配置即可使用
+- 无需修改AI代码
+- 支持热插拔
+
+## 架构
+
+### Client-Server架构
+```
+AI工具（Client）
+    ↓
+MCP协议
+    ↓
+MCP Server（外部工具）
+    ↓
+数据库/文件系统/API等
+```
+
+### 常用MCP Server
+
+| 类型 | Server | 用途 |
+|------|--------|------|
+| 数据库 | mcp-server-sqlite | SQLite数据库访问 |
+| 数据库 | mcp-server-postgres | PostgreSQL数据库访问 |
+| 文件系统 | mcp-server-filesystem | 文件系统访问 |
+| Web搜索 | mcp-server-brave-search | Brave搜索 |
+| GitHub | mcp-server-github | GitHub API访问 |
+| 浏览器 | mcp-server-playwright | 浏览器自动化 |
+
+## 配置示例
+
+### Claude Code配置
+```json
+{
+  "mcpServers": {
+    "database": {
+      "command": "node",
+      "args": ["mcp-server-sqlite"]
+    },
+    "filesystem": {
+      "command": "node",
+      "args": ["mcp-server-filesystem", "/path/to/dir"]
+    },
+    "brave-search": {
+      "command": "node",
+      "args": ["mcp-server-brave-search"],
+      "env": {
+        "BRAVE_API_KEY": "your-api-key"
+      }
+    }
+  }
+}
+```
+
+### 配置文件位置
+- Claude Code：`.claude/mcp.json`
+- Cursor：`.cursor/mcp.json`
+- OpenCode：`.opencode/mcp.json`
+
+## 使用场景
+
+### 1. 数据库访问
+```json
+{
+  "mcpServers": {
+    "database": {
+      "command": "node",
+      "args": ["mcp-server-postgres"],
+      "env": {
+        "DATABASE_URL": "postgresql://user:pass@localhost:5432/db"
+      }
+    }
+  }
+}
+```
+
+### 2. 文件系统访问
+```json
+{
+  "mcpServers": {
+    "filesystem": {
+      "command": "node",
+      "args": ["mcp-server-filesystem", "/path/to/project"]
+    }
+  }
+}
+```
+
+### 3. Web搜索
+```json
+{
+  "mcpServers": {
+    "brave-search": {
+      "command": "node",
+      "args": ["mcp-server-brave-search"],
+      "env": {
+        "BRAVE_API_KEY": "your-api-key"
+      }
+    }
+  }
+}
+```
+
+## 适用场景
+
+- **数据库访问**：让AI直接查询数据库
+- **文件系统访问**：让AI读写文件
+- **API调用**：让AI调用外部API
+- **浏览器自动化**：让AI操作浏览器
+
+## 优势
+
+- **标准化**：统一的协议规范
+- **易用性**：配置即可使用
+- **可扩展**：支持自定义Server
+- **跨工具**：多个AI工具可以共用
+
+## 挑战
+
+- **安全性**：需要控制AI的访问权限
+- **性能**：可能影响AI响应速度
+- **维护成本**：需要维护MCP Server
+
+## 最佳实践
+
+1. **最小权限**：只开放必要的MCP Server
+2. **环境隔离**：不同环境使用不同的MCP配置
+3. **监控日志**：记录AI的MCP调用
+4. **定期审查**：定期审查MCP配置
+
+## 相关概念
+
+- [[Harness工程]]：MCP是Harness的组成部分
+- [[Agent_as_Code]]：MCP是Agent as Code的组成部分
+- [[Skills]]：MCP和Skills都是AI的能力扩展方式

AI工程/概念/OpenSpec.md

@@ -0,0 +1,73 @@
+# OpenSpec
+
+> 相关：[[规格驱动开发]]、[[BMAD]]、[[Spec_Kit]]、[[Kiro]]
+
+## 定义
+
+**OpenSpec**是轻量级SDD框架，提供灵活的Spec层。
+
+**核心思想**：Spec = 变更单元（持续演化），适合存量项目和快速迭代。
+
+## 核心特征
+
+### 1. 轻量级定位
+- 灵活自由
+- 最小化约束
+- 快速迭代
+
+### 2. 小粒度Spec
+- 变更/Patch级规格
+- 长期存在
+- 持续演化
+
+### 3. 弱流程控制
+- 自由演化
+- 最小化流程
+- 适合快速迭代
+
+## 与其他SDD框架对比
+
+| 维度 | [[BMAD]] | [[Spec_Kit]] | OpenSpec | [[Kiro]] |
+|------|----------|--------------|----------|----------|
+| 方法定位 | 企业级SDD操作系统 | 工程化Spec工作流 | 轻量Spec层 | IDE原生SDD |
+| 核心理念 | Spec = 治理体系 + 多Agent编排 | Spec = 开发入口 + Git生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
+| Spec生命周期 | 全生命周期 | 与分支绑定（短生命周期） | 长期存在（持续演化） | 持续驱动 |
+| Spec粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 可执行能力 | 通过流程驱动 | 驱动开发流程 | 类Prompt | 可生成代码+测试并自动校验 |
+| 流程控制 | 强（阶段+审批+Agent） | 中（Plan→Spec→Tasks） | 弱（自由演化） | 强（闭环） |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 与代码关系 | 间接 | 半耦合 | 弱耦合 | 强耦合 |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+| 失控风险 | 低 | 中 | 高 | 中 |
+
+## 适用场景
+
+- **存量项目**：已有代码库的项目
+- **快速迭代**：需要快速响应变化
+- **小型团队**：不需要强治理
+- **灵活需求**：需要最大的灵活性
+
+## 优势
+
+- **轻量灵活**：最小化约束
+- **快速迭代**：适合快速变化
+- **易于上手**：学习曲线平缓
+- **适合存量项目**：不需要重构
+
+## 挑战
+
+- **失控风险高**：缺乏流程控制
+- **不适合大型项目**：缺乏治理能力
+- **不适合新项目**：不如Spec Kit结构化
+
+## 最佳实践
+
+1. **适合存量项目**：已有代码库的项目最适合
+2. **快速迭代**：充分利用灵活性
+3. **适度约束**：虽然灵活，但需要适度约束
+4. **持续演化**：Spec持续演化，保持最新
+
+## 相关概念
+
+- [[规格驱动开发]]：OpenSpec是SDD框架之一
+- [[BMAD]]、[[Spec_Kit]]、[[Kiro]]：其他SDD框架

AI工程/概念/Playwright.md

@@ -0,0 +1,192 @@
+# Playwright
+
+> 相关：[[测试策略金字塔]]、[[Browser_Use]]、[[MCP]]
+
+## 定义
+
+**Playwright**是最流行的浏览器自动化测试框架，支持Chromium、Firefox、WebKit。
+
+**核心思想**：提供稳定、快速的浏览器自动化能力，支持多浏览器、多平台。
+
+## 核心特征
+
+### 1. 多浏览器支持
+- Chromium（Chrome、Edge）
+- Firefox
+- WebKit（Safari）
+- 一套API，多浏览器运行
+
+### 2. 自动化能力
+- 自动等待元素可操作
+- 自动重试断言
+- 网络拦截
+- 截图和视频录制
+
+### 3. 稳定性
+- 使用稳定的选择器
+- 自动处理动态内容
+- 支持并行测试
+
+## 基本使用
+
+### 安装
+```bash
+npm init playwright@latest
+```
+
+### 基本测试
+```typescript
+import { test, expect } from '@playwright/test';
+
+test('basic test', async ({ page }) => {
+  await page.goto('https://playwright.dev/');
+  await page.getByText('Get Started').click();
+  await expect(page).toHaveTitle(/Getting started/);
+});
+```
+
+### 登录测试
+```typescript
+test('login success', async ({ page }) => {
+  await page.goto('https://example.com/login');
+  await page.getByPlaceholder('Email').fill('test@example.com');
+  await page.getByPlaceholder('Password').fill('123456');
+  await page.getByRole('button', { name: 'Login' }).click();
+  await expect(page).toHaveURL(/dashboard/);
+  await expect(page.getByText('Welcome')).toBeVisible();
+});
+```
+
+### API登录（更稳定）
+```typescript
+test('login via API + set session', async ({ page, request }) => {
+  const response = await request.post('https://example.com/api/login', {
+    data: {
+      email: 'test@example.com',
+      password: '123456'
+    }
+  });
+  
+  expect(response.ok()).toBeTruthy();
+  
+  const cookies = await response.headers()['set-cookie'];
+  
+  await page.context().addCookies([{
+    name: 'session',
+    value: cookies,
+    domain: 'example.com',
+    path: '/'
+  }]);
+  
+  await page.goto('https://example.com/dashboard');
+  await expect(page.getByText('Welcome')).toBeVisible();
+});
+```
+
+## 选择器最佳实践
+
+### 推荐的选择器（从优到差）
+```typescript
+// 1. 使用data-testid（最稳定）
+await page.getByTestId('submit-button').click();
+
+// 2. 使用角色和名称（推荐）
+await page.getByRole('button', { name: 'Login' }).click();
+
+// 3. 使用标签文本（推荐）
+await page.getByLabel('Email').fill('test@example.com');
+
+// 4. 使用占位符（可用）
+await page.getByPlaceholder('Enter your email').fill('test@example.com');
+
+// 5. 使用文本（可用）
+await page.getByText('Welcome').toBeVisible();
+
+// 6. 使用CSS选择器（不推荐，容易变）
+await page.locator('.btn-primary').click();
+
+// 7. 使用XPath（不推荐，容易变）
+await page.locator('//button[@type="submit"]').click();
+```
+
+## 等待策略
+
+### 自动等待
+```typescript
+// Playwright自动等待元素可见、可操作
+await page.getByRole('button', { name: 'Login' }).click();
+```
+
+### 显式等待
+```typescript
+// 等待URL变化
+await expect(page).toHaveURL(/dashboard/);
+
+// 等待元素可见
+await expect(page.getByText('Welcome')).toBeVisible();
+
+// 等待元素隐藏
+await expect(page.getByText('Loading')).toBeHidden();
+
+// 等待网络请求完成
+await page.waitForLoadState('networkidle');
+```
+
+## 配置
+
+### playwright.config.ts
+```typescript
+import { defineConfig } from '@playwright/test';
+
+export default defineConfig({
+  testDir: './tests',
+  fullyParallel: true,
+  forbidOnly: !!process.env.CI,
+  retries: process.env.CI ? 2 : 0,
+  workers: process.env.CI ? 1 : undefined,
+  reporter: 'html',
+  use: {
+    baseURL: 'http://localhost:3000',
+    trace: 'on-first-retry',
+  },
+  projects: [
+    { name: 'chromium', use: { browserName: 'chromium' } },
+    { name: 'firefox', use: { browserName: 'firefox' } },
+    { name: 'webkit', use: { browserName: 'webkit' } },
+  ],
+});
+```
+
+## 适用场景
+
+- **E2E测试**：最流行的E2E测试框架
+- **浏览器自动化**：自动化浏览器操作
+- **视觉回归测试**：截图对比
+- **性能测试**：页面加载性能
+
+## 优势
+
+- **多浏览器支持**：一套API，多浏览器运行
+- **稳定性**：自动等待、自动重试
+- **速度快**：比Selenium快
+- **生态成熟**：社区活跃，文档完善
+
+## 挑战
+
+- **学习成本**：需要了解框架API
+- **维护成本**：需要维护测试脚本
+- **运行时间**：完整的E2E测试运行时间长
+
+## 最佳实践
+
+1. **优先使用稳定的选择器**：data-testid、角色、标签
+2. **使用API登录**：提高测试速度
+3. **测试数据管理**：使用Fixture或API准备数据
+4. **并行测试**：提高测试效率
+5. **CI/CD集成**：每次提交自动运行测试
+
+## 相关概念
+
+- [[测试策略金字塔]]：Playwright是E2E测试的工具
+- [[Browser_Use]]：Playwright和Browser Use的对比
+- [[MCP]]：Playwright MCP是MCP的一种实现

AI工程/概念/Rule约束.md

@@ -0,0 +1,133 @@
+# Rule约束
+
+> 相关：[[AI编程演进阶段]]、[[Harness工程]]、[[规格驱动开发]]
+
+## 定义
+
+**Rule约束**是AI编程的第2阶段，通过规则文件约束AI在不同工作模式下的处理方式。
+
+**核心思想**：用明确的规则告诉AI能做什么、不能做什么，而不是依赖AI的"聪明"。
+
+## 核心特征
+
+### 1. 规则显化
+- 将隐式的经验转化为显式的规则
+- 规则以文件形式存在
+- 规则可版本化、可共享
+
+### 2. 工作模式
+- 定义AI在不同模式下的行为
+- 如：Research模式、Plan模式、Code模式
+- 每种模式有不同的约束
+
+### 3. 持续对话
+- 需要通过对话输入需求
+- AI根据规则约束生成代码
+- 人工需要持续监督
+
+## 典型框架
+
+### RIPER-5
+- **R**esearch：研究阶段，分析需求
+- **I**mplement：实现阶段，编写代码
+- **P**lan：规划阶段，制定计划
+- **E**valuate：评估阶段，验证结果
+- **R**eview：审查阶段，Code Review
+
+### 规则示例
+```markdown
+# Java代码风格Rules
+
+1. 使用Java 17语法，不使用已废弃API
+2. 类名使用大驼峰，方法名使用小驼峰
+3. 常量使用全大写下划线分隔
+4. 单行代码不超过120字符
+5. 禁止使用@Autowired字段注入
+6. 数据库表必须包含created_at和updated_at字段
+```
+
+## 规则分类
+
+### 1. 代码风格规则
+- 命名规范
+- 格式规范
+- 注释规范
+
+### 2. 架构规则
+- 分层架构约束
+- 依赖方向约束
+- 模块划分规则
+
+### 3. 安全规则
+- 敏感数据处理
+- 权限控制
+- 加密要求
+
+### 4. 性能规则
+- 数据库查询优化
+- 缓存策略
+- 并发控制
+
+## 载体
+
+### .cursor/rules/
+```
+.cursor/
+└── rules/
+    ├── java-style.md
+    ├── api-style.md
+    └── security.md
+```
+
+### CLAUDE.md
+```markdown
+# 项目规则
+
+## 代码规范
+- 使用阿里巴巴Java开发手册
+- 所有方法必须有注释
+
+## 数据库规范
+- 表名使用下划线命名
+- 必须包含时间戳字段
+```
+
+### AGENTS.md
+```markdown
+# AI行为规则
+
+1. 生成代码必须符合代码规范
+2. 敏感数据必须加密存储
+3. API必须使用RESTful风格
+```
+
+## 适用场景
+
+- **个人项目**：约束AI生成符合个人习惯的代码
+- **小团队**：统一团队代码风格
+- **学习阶段**：通过规则学习最佳实践
+
+## 优势
+
+- **简单直接**：规则清晰，易于理解
+- **快速上手**：不需要复杂的工具链
+- **灵活调整**：规则可以随时修改
+
+## 局限
+
+- **需要持续对话**：每次都需要输入需求
+- **无法自动化**：依赖人工监督
+- **规则冲突**：复杂场景规则可能冲突
+
+## 最佳实践
+
+1. **从核心规则开始**：先定义最重要的规则
+2. **逐步完善**：根据实践逐步添加规则
+3. **定期Review**：定期审查和优化规则
+4. **规则分层**：区分强制规则和推荐规则
+
+## 相关概念
+
+- [[AI编程演进阶段]]：Rule是第2阶段
+- [[Harness工程]]：Rule是Harness的组成部分
+- [[规格驱动开发]]：Rule的进阶是Spec

AI工程/概念/Skills.md

@@ -0,0 +1,155 @@
+# Skills
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[MCP]]
+
+## 定义
+
+**Skills**是可复用的AI能力单元，通过打包提示词、脚本、模版，进一步精确拓展AI的能力。
+
+**核心思想**：将常用的能力封装成可复用的单元，提高AI的工作效率。
+
+## 核心特征
+
+### 1. 可复用
+- 可以在多个项目中使用
+- 可以在团队间共享
+- 可以版本化管理
+
+### 2. 触发词驱动
+- 通过触发词调用
+- 自动识别使用场景
+- 无需手动配置
+
+### 3. 封装完整
+- 包含提示词
+- 包含脚本工具
+- 包含文档模版
+
+## 组成
+
+### 1. SKILL.md
+- 技能描述
+- 使用说明
+- 触发词定义
+
+### 2. 脚本文件
+- 可执行的脚本
+- 自动化工具
+- 配置文件
+
+### 3. 文档模版
+- 输出格式模版
+- 配置文件模版
+- 报告模版
+
+## 示例
+
+### Commit & Push Skill
+```markdown
+# Commit & Push Skill
+
+## 触发词
+commit, push, 提交
+
+## 执行
+git add -A
+git commit -m "{message}"
+git push
+
+## 规则
+- 提交前检查lint
+- 信息遵循conventional commit
+- 推送前确认分支
+```
+
+### Deploy Skill
+```markdown
+# Deploy Skill
+
+## 触发词
+deploy, 部署, 发布
+
+## 执行
+npm run build
+npx vercel --prod
+
+## 规则
+- 构建前运行测试
+- 部署前确认环境
+- 部署后验证功能
+```
+
+### Test Skill
+```markdown
+# Test Skill
+
+## 触发词
+test, 测试, 运行测试
+
+## 执行
+mvn test
+
+## 规则
+- 运行所有测试
+- 生成测试报告
+- 失败时提供修复建议
+```
+
+## 目录结构
+
+```
+skills/
+├── commit-push/
+│   ├── SKILL.md
+│   └── commit.sh
+├── deploy/
+│   ├── SKILL.md
+│   └── deploy.sh
+├── test/
+│   ├── SKILL.md
+│   └── test.sh
+└── code-review/
+    ├── SKILL.md
+    └── review.sh
+```
+
+## 开发流程
+
+1. **需求分析**：确定技能的功能和触发词
+2. **脚本开发**：编写可执行的脚本
+3. **触发词定义**：定义触发词和使用场景
+4. **测试验证**：测试技能的功能
+5. **文档编写**：编写SKILL.md文档
+
+## 适用场景
+
+- **常用操作**：提交代码、部署、测试等
+- **复杂流程**：需要多个步骤的操作
+- **团队协作**：需要统一的操作规范
+- **知识沉淀**：最佳实践需要沉淀
+
+## 优势
+
+- **可复用**：可以在多个项目中使用
+- **易共享**：可以在团队间共享
+- **易维护**：可以版本化管理
+- **易扩展**：可以快速添加新技能
+
+## 挑战
+
+- **初始成本**：需要开发Skills
+- **维护成本**：需要持续维护Skills
+- **学习成本**：团队需要学习Skills
+
+## 最佳实践
+
+1. **从常用操作开始**：先封装最常用的操作
+2. **保持简单**：每个Skill只做一件事
+3. **文档清晰**：SKILL.md要清晰易懂
+4. **定期Review**：定期审查和优化Skills
+
+## 相关概念
+
+- [[Harness工程]]：Skills是Harness的组成部分
+- [[Agent_as_Code]]：Skills是Agent as Code的组成部分
+- [[MCP]]：MCP和Skills都是AI的能力扩展方式

AI工程/概念/Spec_Kit.md

@@ -0,0 +1,73 @@
+# Spec Kit
+
+> 相关：[[规格驱动开发]]、[[BMAD]]、[[OpenSpec]]、[[Kiro]]
+
+## 定义
+
+**Spec Kit**是工程化SDD框架，提供Git集成的Spec工作流。
+
+**核心思想**：Spec = 开发入口 + Git生命周期，适合新项目（0→1）。
+
+## 核心特征
+
+### 1. 工程化定位
+- Git集成
+- 工程化工作流
+- 与开发流程紧密结合
+
+### 2. 中粒度Spec
+- Feature级规格
+- 与Git分支绑定
+- 短生命周期
+
+### 3. 中等流程控制
+- Plan→Spec→Tasks
+- 灵活但有序
+- 适合敏捷开发
+
+## 与其他SDD框架对比
+
+| 维度 | [[BMAD]] | Spec Kit | [[OpenSpec]] | [[Kiro]] |
+|------|----------|----------|--------------|----------|
+| 方法定位 | 企业级SDD操作系统 | 工程化Spec工作流 | 轻量Spec层 | IDE原生SDD |
+| 核心理念 | Spec = 治理体系 + 多Agent编排 | Spec = 开发入口 + Git生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
+| Spec生命周期 | 全生命周期 | 与分支绑定（短生命周期） | 长期存在（持续演化） | 持续驱动 |
+| Spec粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 可执行能力 | 通过流程驱动 | 驱动开发流程 | 类Prompt | 可生成代码+测试并自动校验 |
+| 流程控制 | 强（阶段+审批+Agent） | 中（Plan→Spec→Tasks） | 弱（自由演化） | 强（闭环） |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 与代码关系 | 间接 | 半耦合 | 弱耦合 | 强耦合 |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+| 失控风险 | 低 | 中 | 高 | 中 |
+
+## 适用场景
+
+- **新项目（0→1）**：从零开始的项目
+- **中型团队**：需要工程化工作流
+- **敏捷开发**：需要灵活但有序的流程
+- **Git重度用户**：深度集成Git
+
+## 优势
+
+- **Git集成**：与Git深度集成
+- **工程化**：完整的工程化工作流
+- **灵活性**：比BMAD更灵活
+- **易于上手**：学习曲线相对平缓
+
+## 挑战
+
+- **失控风险中等**：需要一定的流程控制
+- **不适合大型项目**：大粒度不如BMAD
+- **不适合存量项目**：不如OpenSpec灵活
+
+## 最佳实践
+
+1. **适合新项目**：从零开始的项目最适合
+2. **Git工作流**：充分利用Git的分支和PR
+3. **团队协作**：团队成员需要理解工作流
+4. **持续迭代**：根据实践持续优化流程
+
+## 相关概念
+
+- [[规格驱动开发]]：Spec Kit是SDD框架之一
+- [[BMAD]]、[[OpenSpec]]、[[Kiro]]：其他SDD框架

AI工程/概念/Trae.md

@@ -0,0 +1,68 @@
+# Trae
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[Claude_Code]]、[[Cursor]]、[[Kiro]]
+
+## 定义
+
+**Trae**是字节跳动推出的AI IDE，集成豆包大模型，中文支持好。
+
+**核心思想**：集成豆包大模型，中文支持好，适合中文项目。
+
+## 核心特征
+
+### 1. 豆包大模型
+- 字节跳动自研模型
+- 中文理解能力强
+- 适合中文项目
+
+### 2. 中文支持好
+- 中文文档完善
+- 中文社区活跃
+- 中文优化
+
+### 3. IDE集成
+- 完整的IDE功能
+- AI深度集成
+- 易于使用
+
+## 与其他AI工具对比
+
+| 工具 | 类型 | 价格 | AI模型 | 适用场景 |
+|------|------|------|--------|---------|
+| [[Claude_Code]] | CLI | 按Token | Claude | 复杂逻辑 |
+| [[Cursor]] | IDE | $20/月 | 多模型 | 日常开发 |
+| [[Kiro]] | IDE | 免费+付费 | Claude | AWS项目 |
+| Trae | IDE | 免费+付费 | 豆包 | 中文项目 |
+
+## 适用场景
+
+- **中文项目**：中文理解和生成能力强
+- **国内团队**：国内团队使用更方便
+- **豆包生态**：使用豆包生态的项目
+- **成本敏感**：有免费版本
+
+## 优势
+
+- **中文支持好**：中文理解和生成能力强
+- **国内团队**：国内团队使用更方便
+- **成本较低**：有免费版本
+- **豆包生态**：与豆包生态集成
+
+## 挑战
+
+- **国际项目**：不如Claude Code适合国际项目
+- **复杂逻辑**：推理能力不如Claude Code
+- **生态成熟度**：生态不如Cursor成熟
+
+## 最佳实践
+
+1. **中文项目首选**：中文项目最适合
+2. **国内团队**：国内团队使用更方便
+3. **豆包生态**：充分利用豆包生态
+4. **成本优化**：使用免费版本降低成本
+
+## 相关概念
+
+- [[Harness工程]]：Trae是Harness的工具之一
+- [[Agent_as_Code]]：Trae支持Agent as Code
+- [[Claude_Code]]、[[Cursor]]、[[Kiro]]：其他AI编程工具

AI工程/概念/_概念索引.md

@@ -0,0 +1,162 @@
+# AI工程概念索引
+
+> 本索引收录团队级 AI Coding 相关的所有核心概念
+
+## 基础概念
+
+### [[AI编程演进阶段]]
+AI 编程从手动复制到全自动的5个发展阶段
+
+### [[Harness工程]]
+为 AI 提供约束体系和外部接口的工程实践
+
+### [[Agent_as_Code]]
+将 AI 协作文件以代码方式管理的理念
+
+---
+
+## 开发方法论
+
+### [[Rule约束]]
+通过规则文件约束 AI 行为的方法
+
+### [[规格驱动开发]]
+以规格文档为核心的开发方法（SDD）
+
+### [[Loop工程]]
+AI 自治运行的开发循环
+
+### [[核心Loop]]
+Plan → TDD → 验证的开发循环
+
+### [[超级Loop]]
+核心Loop + E2E测试验证的扩展循环
+
+---
+
+## 技术概念
+
+### [[过程方案vs事实方案]]
+Plans（追加不维护）vs Designs（覆盖更新）
+
+### [[上下文体系]]
+AI 协作的文档组织结构
+
+### [[打样工程]]
+提供代码模版让 AI 参考生成代码
+
+### [[技术规格DSL]]
+领域模型、数据库、API、时序图的标准化表达
+
+---
+
+## 工具与协议
+
+### [[MCP]]
+Model Context Protocol，AI 与外部系统通信的标准协议
+
+### [[Skills]]
+可复用的 AI 能力单元
+
+### [[AGENTS.md]]
+AI 协作的宪法级配置文件
+
+### [[Git_Worktree]]
+Git 多工作区并行开发功能
+
+---
+
+## AI工具
+
+### [[Claude_Code]]
+Anthropic 出品的 AI 编程工具
+
+### [[Cursor]]
+基于 VS Code 的 AI IDE
+
+### [[Kiro]]
+AWS 推出的 AI IDE 和 SDD 框架
+
+### [[Trae]]
+字节跳动推出的 AI IDE
+
+---
+
+## SDD框架
+
+### [[BMAD]]
+企业级 SDD 框架，强治理
+
+### [[Spec_Kit]]
+工程化 SDD 框架，Git 集成
+
+### [[OpenSpec]]
+轻量级 SDD 框架，灵活
+
+---
+
+## 测试相关
+
+### [[测试策略金字塔]]
+Lint → Code Review → 单元测试 → API测试 → E2E测试
+
+### [[Browser_Use]]
+AI 操作浏览器的框架
+
+### [[Playwright]]
+浏览器自动化测试框架
+
+### [[Computer_Use]]
+Anthropic 的 OS 级视觉操作方案
+
+---
+
+## 统计
+
+- 总概念数：28个
+- 分类：7大类
+- 创建日期：2026-06-20
+- 最后更新：2026-06-20
+
+## 概念清单
+
+### 基础概念
+- [[AI编程演进阶段]]
+- [[Harness工程]]
+- [[Agent_as_Code]]
+
+### 开发方法论
+- [[Rule约束]]
+- [[规格驱动开发]]
+- [[Loop工程]]
+- [[核心Loop]]
+- [[超级Loop]]
+
+### 技术概念
+- [[过程方案vs事实方案]]
+- [[上下文体系]]
+- [[打样工程]]
+- [[技术规格DSL]]
+
+### 工具与协议
+- [[MCP]]
+- [[Skills]]
+- [[AGENTS.md]]
+- [[Git_Worktree]]
+
+### AI工具
+- [[Claude_Code]]
+- [[Cursor]]
+- [[Kiro]]
+- [[Trae]]
+
+### SDD框架
+- [[BMAD]]
+- [[Spec_Kit]]
+- [[OpenSpec]]
+
+### 测试相关
+- [[测试策略金字塔]]
+- [[Browser_Use]]
+- [[Playwright]]
+- [[Computer_Use]]

AI工程/概念/上下文体系.md

@@ -0,0 +1,141 @@
+# 上下文体系
+
+> 相关：[[Harness工程]]、[[Agent_as_Code]]、[[AGENTS.md]]、[[过程方案vs事实方案]]
+
+## 定义
+
+**上下文体系**是AI协作的文档组织结构，通过分层文档为AI提供完整的上下文信息，让AI能够理解和遵循项目规范。
+
+**核心思想**：使用完整的文档来描述上下文和约束体系，区分过程方案和事实方案，减少维护成本。
+
+## 核心特征
+
+### 1. 分层结构
+- 宪法级：AGENTS.md
+- 标准层：standards/
+- 需求层：features/
+- 设计层：designs/
+- 计划层：plans/
+
+### 2. 引用关系
+- 上层文档引用下层文档
+- 形成清晰的依赖关系
+- AI可以理解完整上下文
+
+### 3. 双轨管理
+- 过程方案：Plans（追加不修改）
+- 事实方案：Designs（覆盖更新）
+
+## 文档分层结构
+
+```
+AGENTS.md          ← 宪法（所有AI工具读取）
+docs/
+├── standards/     ← 标准规格（架构/命名/API/安全规范）
+├── features/      ← 需求规格（产品/BA维护）
+├── designs/       ← 设计规格（事实方案，Source of Truth）
+├── plans/         ← 计划规格（过程方案，追加不修改）
+└── others/        ← 架构决策、Release、测试用例等
+skills/            ← AI技能（可复用能力单元）
+mcp/               ← MCP配置（外部工具接入）
+```
+
+## 各层职责
+
+### AGENTS.md（宪法级）
+- 定义项目基本信息
+- 定义AI行为规则
+- 定义目录结构
+- 所有AI工具都从这个文件开始
+
+### standards/（标准层）
+- 代码风格规范
+- API设计规范
+- 数据库设计规范
+- 安全规范
+
+### features/（需求层）
+- 产品需求文档
+- 用户故事
+- 验收标准
+- 由产品/BA维护
+
+### designs/（设计层）
+- 数据库设计
+- API设计
+- 架构设计
+- 事实方案，必须保持最新
+
+### plans/（计划层）
+- 任务计划
+- 实现方案
+- 过程方案，追加不修改
+
+### skills/（技能层）
+- 可复用的AI能力单元
+- 包含提示词、脚本、文档
+
+### mcp/（工具层）
+- MCP配置
+- 外部工具接入
+
+## 构建引用关系
+
+### 示例：AGENTS.md
+```markdown
+# 项目信息
+- 项目名称：电商平台
+- 技术栈：Java 17, Spring Boot 3.x
+
+# 引用文件
+- 代码规范：./docs/standards/coding-style.md
+- API规范：./docs/standards/api-style.md
+- 数据库规范：./docs/standards/db-style.md
+```
+
+### 示例：Plan引用Design
+```markdown
+# Plan: 实现用户注册功能
+
+## 参考设计
+- 数据库设计：../designs/database-schema.md
+- API设计：../designs/api-design.md
+
+## 实现方案
+根据设计文档实现...
+```
+
+## 适用场景
+
+- **团队协作**：多人协作需要统一的上下文
+- **复杂项目**：复杂项目需要完整的文档体系
+- **长期维护**：长期项目需要持续的上下文管理
+- **知识传承**：新成员需要快速理解项目
+
+## 优势
+
+- **完整上下文**：AI可以理解完整的项目背景
+- **易于维护**：分层结构，职责清晰
+- **可追溯**：文档变更有历史记录
+- **可复用**：标准和设计可以在项目间复用
+
+## 挑战
+
+- **初始成本**：需要建立完整的文档体系
+- **维护成本**：需要持续维护文档
+- **学习曲线**：团队需要理解文档体系
+
+## 最佳实践
+
+1. **从AGENTS.md开始**：先定义最基本的规则
+2. **逐步扩展**：根据实践逐步添加文档
+3. **明确职责**：每层文档有明确的职责
+4. **定期Review**：定期审查和优化文档
+5. **保持最新**：事实方案必须保持最新
+
+## 相关概念
+
+- [[Harness工程]]：上下文体系是Harness的组成部分
+- [[Agent_as_Code]]：上下文体系是Agent as Code的文档组织
+- [[AGENTS.md]]：上下文体系的宪法级文件
+- [[过程方案vs事实方案]]：上下文体系的双轨管理方式

AI工程/概念/打样工程.md

@@ -0,0 +1,153 @@
+# 打样工程
+
+> 相关：[[Harness工程]]、[[上下文体系]]、[[技术规格DSL]]
+
+## 定义
+
+**打样工程**是提供代码模版和示例，让AI参考生成代码的工程实践。
+
+**核心思想**：让AI"抄作业"，而不是自由发挥，保证代码风格统一、质量稳定。
+
+## 核心原则
+
+1. **约定大于配置**：通过模版约定代码风格
+2. **编排逻辑和原子能力分离**：Controller、Service、Repository职责明确
+3. **操作者和被操作对象分离**：分层清晰
+
+## 常见工序
+
+### 1. 简单CRUD（无复用逻辑）
+```
+Controller + Command → AppService → Repository → Response对象
+```
+
+**示例**：
+```java
+// Controller
+@PostMapping("/users")
+public Response<UserResponse> createUser(@Valid @RequestBody CreateUserCommand cmd) {
+    return Response.success(userAppService.create(cmd));
+}
+
+// AppService
+public UserResponse create(CreateUserCommand cmd) {
+    User user = userRepository.save(User.from(cmd));
+    return UserResponse.from(user);
+}
+
+// Repository
+public User save(User user) {
+    userMapper.insert(user);
+    return user;
+}
+```
+
+### 2. 复杂CRUD（有复用逻辑）
+```
+Controller + Command → AppService → DomainService → Repository → Response对象
+```
+
+**示例**：
+```java
+// AppService - 编排逻辑
+public UserResponse create(CreateUserCommand cmd) {
+    // 1. 校验用户名唯一
+    domainService.checkUsernameUnique(cmd.getUsername());
+    // 2. 加密密码
+    String encryptedPassword = domainService.encryptPassword(cmd.getPassword());
+    // 3. 保存用户
+    User user = User.from(cmd, encryptedPassword);
+    userRepository.save(user);
+    // 4. 发送欢迎邮件
+    domainService.sendWelcomeEmail(user);
+    return UserResponse.from(user);
+}
+
+// DomainService - 原子能力
+public void checkUsernameUnique(String username) {
+    if (userRepository.existsByUsername(username)) {
+        throw new BusinessException("用户名已存在");
+    }
+}
+```
+
+### 3. 复杂查询
+```
+Controller + Query对象 → AppService → QueryPO（或复用PO）→ Response对象
+```
+
+**示例**：
+```java
+// Controller
+@GetMapping("/users")
+public Response<Page<UserResponse>> listUsers(@Valid UserQuery query) {
+    return Response.success(userAppService.list(query));
+}
+
+// AppService
+public Page<UserResponse> list(UserQuery query) {
+    Page<UserPO> page = userRepository.findByQuery(query);
+    return page.map(UserResponse::from);
+}
+
+// Repository
+public Page<UserPO> findByQuery(UserQuery query) {
+    // 构建查询条件
+    // 执行分页查询
+    // 返回分页结果
+}
+```
+
+## 三层架构
+
+### Controller层
+- **职责**：接收请求、参数校验、调用Service
+- **输入**：Command/Query对象
+- **输出**：Response对象
+- **不包含业务逻辑**
+
+### Service层
+- **AppService**：应用服务，编排逻辑
+- **DomainService**：领域服务，复杂业务逻辑
+- **职责**：编排业务逻辑、调用DomainService/Repository
+
+### Repository层
+- **职责**：数据持久化
+- **输入**：实体对象
+- **输出**：实体对象或PO
+
+## 参考代码
+
+- **DDD微服务示例**：https://github.com/domain-driven-design/ddd-microservices
+
+## 为什么需要打样工程
+
+- **AI生成代码质量不稳定**：需要模版约束
+- **不同AI工具风格不同**：需要统一风格
+- **AI不知道最佳实践**：需要沉淀最佳实践
+
+## 优势
+
+1. **提高代码质量**：基于模版生成，质量有保障
+2. **统一代码风格**：所有代码遵循相同的风格
+3. **减少Review成本**：代码符合规范，Review更快
+4. **知识沉淀**：最佳实践沉淀在模版中
+
+## 挑战
+
+- **初始成本**：需要建立打样工程
+- **维护成本**：需要持续维护模版
+- **灵活性**：模版可能限制创新
+
+## 最佳实践
+
+1. **建立打样工程**：提供标准的代码模版
+2. **分层清晰**：Controller、Service、Repository职责明确
+3. **工序标准化**：简单CRUD、复杂CRUD、复杂查询各有标准
+4. **AI参考打样**：让AI根据打样工程生成代码
+
+## 相关概念
+
+- [[Harness工程]]：打样工程是Harness的组成部分
+- [[上下文体系]]：打样工程是上下文体系的组成部分
+- [[技术规格DSL]]：打样工程使用技术规格DSL

AI工程/概念/技术规格DSL.md

@@ -0,0 +1,220 @@
+# 技术规格DSL
+
+> 相关：[[规格驱动开发]]、[[Harness工程]]、[[上下文体系]]
+
+## 定义
+
+**技术规格DSL**（Domain Specific Language）是使用领域特定语言编写技术规格的方法，包括领域模型、数据库、API、时序图等。
+
+**核心思想**：使用DSL驱动技术规格，保证一致性和可执行性。
+
+## 5个模块
+
+| 模块 | 表达标准 | 格式 | 产出内容 | 约束/规范 |
+|------|---------|------|---------|----------|
+| **领域模型** | PlantUML/Smart Domain | .puml | 实体、属性、关系 | 必须表达实体关系；字段需与数据库一致 |
+| **数据库** | SQL DDL/DBML/Flyway | .sql | 表结构、索引、约束 | 必须可执行；包含索引和外键 |
+| **API** | OpenAPI 3.x | .yaml/.json | 接口定义、请求/响应 | 必须定义schema；字段与模型一致 |
+| **时序图** | PlantUML | .puml | 调用流程、系统交互 | 必须反映真实调用链；包含异常分支 |
+| **专题设计** | Markdown | .md | 架构策略 | 只写策略与规则；强调设计决策 |
+
+## 领域模型
+
+### PlantUML示例
+```plantuml
+@startuml
+entity User {
+  * id : Long <<PK>>
+  --
+  * username : String(50)
+  * email : String(100)
+  * role_id : Long <<FK>>
+}
+
+entity Role {
+  * id : Long <<PK>>
+  --
+  * name : String(20)
+}
+
+User }o--|| Role : "拥有"
+note right of User : 聚合根
+@enduml
+```
+
+### 约束要求
+- 必须表达实体关系（1:1, 1:N, M:N）
+- 字段需与数据库一致
+- 标注聚合关系
+
+## 数据库设计
+
+### SQL DDL示例
+```sql
+-- Flyway migration: V1__create_users_table.sql
+CREATE TABLE users (
+    id BIGINT PRIMARY KEY AUTO_INCREMENT,
+    username VARCHAR(50) NOT NULL UNIQUE,
+    email VARCHAR(100) NOT NULL UNIQUE,
+    password VARCHAR(255) NOT NULL,
+    role_id BIGINT NOT NULL,
+    status TINYINT(1) DEFAULT 1,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+    INDEX idx_username (username),
+    INDEX idx_email (email),
+    CONSTRAINT fk_user_role FOREIGN KEY (role_id) REFERENCES roles(id)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+### 约束要求
+- 必须可执行
+- 使用Flyway/Liquibase管理版本
+- 包含索引和外键
+
+## API设计
+
+### OpenAPI 3.x示例
+```yaml
+openapi: 3.0.3
+info:
+  title: User API
+  version: 1.0.0
+paths:
+  /api/v1/users:
+    post:
+      summary: 创建用户
+      tags: [User]
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateUserRequest'
+      responses:
+        '201':
+          description: 创建成功
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+components:
+  schemas:
+    CreateUserRequest:
+      type: object
+      required: [username, email, password]
+      properties:
+        username:
+          type: string
+          minLength: 3
+          maxLength: 50
+        email:
+          type: string
+          format: email
+        password:
+          type: string
+          minLength: 8
+```
+
+### 约束要求
+- 必须定义schema
+- 禁止只写接口说明
+- 字段与领域模型一致
+
+## 时序图
+
+### PlantUML时序图示例
+```plantuml
+@startuml
+actor User
+participant "UserController" as C
+participant "UserService" as S
+participant "UserRepository" as R
+database "MySQL" as DB
+
+User -> C: POST /api/v1/users
+C -> C: 参数校验
+C -> S: createUser(CreateUserRequest)
+S -> S: 业务规则校验
+S -> R: save(User)
+R -> DB: INSERT INTO users ...
+DB --> R: 返回结果
+R --> S: 返回 User
+S --> C: 返回 UserResponse
+C --> User: 201 Created
+
+alt 用户名已存在
+  S --> C: throw DuplicateException
+  C --> User: 409 Conflict
+end
+@enduml
+```
+
+### 约束要求
+- 必须反映真实调用链
+- 建议包含异常分支（alt）
+- 标注关键步骤
+
+## 专题设计
+
+### 示例
+```markdown
+# 权限设计方案
+
+## 策略
+- 使用RBAC（基于角色的访问控制）
+- 权限注解：@RequirePermission("user:create")
+- 默认拒绝所有未授权的请求
+
+## 规则
+1. 管理员角色拥有所有权限
+2. 普通用户只能操作自己的数据
+3. 敏感操作需要二次确认
+
+## 设计决策
+- 选择RBAC而非ABAC：业务场景简单，角色固定
+- 权限存储在Redis：减少数据库查询
+```
+
+### 约束要求
+- 只写"策略与规则"
+- 不重复API/DDL
+- 强调设计决策
+
+## 为什么用DSL
+
+- **可执行**：DDL可以直接运行，OpenAPI可以生成代码
+- **AI友好**：LLM对DSL的理解比自然语言更精确
+- **一致性保证**：DSL有语法规则，不容易产生歧义
+
+## 适用场景
+
+- **复杂项目**：需要完整的技术规格
+- **团队协作**：需要统一的技术规范
+- **AI辅助开发**：需要精确的技术规格
+
+## 优势
+
+- **一致性**：领域模型、数据库、API保持一致
+- **可执行**：部分DSL可以直接执行
+- **AI友好**：AI可以精确理解DSL
+- **可维护**：DSL可以版本化
+
+## 挑战
+
+- **学习成本**：需要学习多种DSL
+- **维护成本**：需要保持DSL的一致性
+- **工具支持**：需要相应的工具支持
+
+## 最佳实践
+
+1. **使用DSL**：统一技术规格的表示方式
+2. **保持一致性**：领域模型、数据库、API要一致
+3. **AI辅助生成**：让AI根据规格生成代码
+4. **版本控制**：技术规格纳入Git管理
+
+## 相关概念
+
+- [[规格驱动开发]]：技术规格DSL是SDD的组成部分
+- [[Harness工程]]：技术规格DSL是Harness的组成部分
+- [[上下文体系]]：技术规格DSL是上下文体系的组成部分

AI工程/概念/核心Loop.md

@@ -0,0 +1,177 @@
+# 核心Loop
+
+> 相关：[[Loop工程]]、[[超级Loop]]、[[Harness工程]]、[[测试策略金字塔]]
+
+## 定义
+
+**核心Loop**是AI编程中AI自治运行的开发循环，通过Plan → TDD → 验证的流程，实现半自动有人值守的开发。
+
+**核心思想**：Plan阶段人机协作，执行阶段AI自治。
+
+## 核心流程
+
+```
+开始进入循环
+    ↓
+[Chat] 进入Plan模式
+    ↓
+装载需求规格，给出指令进行Plan
+    ↓
+[Chat] 符合要求，退出Plan模式，开始执行？
+    ↓ 是
+[模型] 读取Plan
+    ↓
+创建API测试，实现代码
+    ↓
+[模型] 运行测试/浏览器调试，是否成功？
+    ↓ 否 → 重复多次/白天持续很久/夜间
+    ↓ 是
+[模型] 退出循环
+    ↓
+（给予ByPass权限）
+```
+
+## 三个阶段
+
+### 阶段1：Plan（规划）
+- **输入**：需求规格、技术规格
+- **输出**：实现方案、任务列表
+- **关键**：关闭所有开放性问题
+- **人工介入**：确认Plan是否合理
+
+**Plan模版**：
+```markdown
+# Plan: 实现用户注册功能
+
+## 目标
+实现用户注册API，支持邮箱验证
+
+## 任务列表
+- [ ] 1. 创建数据库表users
+- [ ] 2. 实现POST /api/v1/users API
+- [ ] 3. 实现邮箱验证逻辑
+- [ ] 4. 编写单元测试
+- [ ] 5. 编写API测试
+
+## 实现方案
+1. 使用Flyway创建users表
+2. Controller接收CreateUserCommand
+3. AppService调用UserRepository保存
+4. 发送验证邮件
+
+## 验收标准
+- 所有单元测试通过
+- 所有API测试通过
+- 代码符合阿里巴巴Java开发手册
+
+## 状态
+- 开始时间：2026-06-20 10:00
+- 预计完成：2026-06-20 12:00
+```
+
+### 阶段2：执行（Implementation）
+- **输入**：Plan
+- **输出**：API测试、实现代码
+- **关键**：按照Plan逐步实现
+- **AI自治**：无需人工介入
+
+**步骤**：
+1. 编写API测试
+2. 运行测试（断言失败）
+3. 编写实现代码
+4. 运行测试（通过）
+
+### 阶段3：验证（Verification）
+- **输入**：API测试、实现代码
+- **输出**：测试结果、修复建议
+- **关键**：所有测试通过
+- **AI自治**：自动运行测试，自动修复
+
+## Loop规则
+
+### 1. Plan等待确认
+在docs/plans下根据模版创建Plan，等待人工确认。
+
+### 2. 编写API测试
+根据Plan实现API测试，运行成功并断言失败。
+
+```java
+@Test
+void testCreateUser() {
+    CreateUserRequest request = new CreateUserRequest();
+    request.setUsername("testuser");
+    request.setEmail("test@example.com");
+    request.setPassword("Password123");
+    
+    Response<UserResponse> response = userClient.create(request);
+    
+    assertEquals(201, response.getCode());
+    assertNotNull(response.getData().getId());
+}
+```
+
+### 3. 编写实现
+编写单元测试 + 实现代码，通过编译。
+
+```java
+@PostMapping("/users")
+public Response<UserResponse> createUser(@RequestBody CreateUserRequest request) {
+    return Response.success(userAppService.create(request));
+}
+```
+
+### 4. 运行API测试
+运行测试，并修复失败的测试和其他错误。
+
+```bash
+mvn test -Dtest=UserApiTest
+```
+
+## 退出条件
+
+1. 所有API测试通过
+2. 所有单元测试通过
+3. 代码符合规范（Lint通过）
+4. 没有编译错误
+
+## ByPass权限
+
+AI在某些情况下可以跳过某些步骤：
+- 测试环境不可用
+- 第三方服务不可用
+- 紧急修复
+
+在AGENTS.md中定义ByPass规则。
+
+## 适用场景
+
+- **后端开发**：API开发、业务逻辑实现
+- **中等复杂度**：需要TDD驱动的开发
+- **团队协作**：需要统一开发流程
+
+## 优势
+
+- **质量可控**：TDD驱动，代码质量有保障
+- **可追溯**：Plan记录了实现过程
+- **AI自治**：执行阶段无需人工介入
+- **持续迭代**：可以快速修复问题
+
+## 挑战
+
+- **Plan质量**：Plan阶段需要充分沟通
+- **测试覆盖**：需要编写全面的测试
+- **运行时间**：Loop可能需要较长时间
+
+## 最佳实践
+
+1. **Plan阶段充分沟通**：关闭所有开放性问题
+2. **TDD驱动**：先写测试再写代码
+3. **记录状态**：方便复盘和优化
+4. **ByPass控制**：紧急情况可以跳过步骤
+
+## 相关概念
+
+- [[Loop工程]]：核心Loop是Loop工程的具体实现
+- [[超级Loop]]：核心Loop的扩展，增加E2E测试
+- [[Harness工程]]：核心Loop是Harness的组成部分
+- [[测试策略金字塔]]：核心Loop使用的测试策略

AI工程/概念/测试策略金字塔.md

@@ -0,0 +1,99 @@
+# 测试策略金字塔
+
+> 相关：[[核心Loop]]、[[超级Loop]]、[[Playwright]]、[[Browser_Use]]
+
+## 定义
+
+**测试策略金字塔**是AI辅助下的分层测试策略，从代码扫描到端到端测试，层层递进。
+
+**核心思想**：分层测试，每层有不同的测试对象和工具。
+
+## 测试层级
+
+| 测试类型 | 测试对象 | 工具（含AI） | 负责人 |
+|---------|---------|--------------|-------------------|
+| **Lint代码扫描** | 代码风格、代码逻辑和片段 | TS Lint/SonarQube | 程序 |
+| **Code Review** | 代码逻辑、架构设计、规范 | GitHub Copilot、Claude Code、CodeRabbit、GitHub PR | 开发者 + AI Review Agent |
+| **单元测试** | 函数/类行为、边界条件、异常处理 | JUnit、pytest、Jest + AI生成测试代码 | 开发者 + Test Generation Agent |
+| **API测试** | 接口契约、输入输出、鉴权、错误码、业务规则 | Karate（主）、RestAssured（补充） + AI生成测试用例 | QA + 后端开发 + API Test Agent |
+| **E2E测试** | 用户关键路径、跨系统流程、前后端联动 | Playwright + AI生成脚本/自愈 | QA + 自动化测试工程师 + E2E Agent |
+
+## AI的作用
+
+### Lint代码扫描
+- 自动修复格式问题
+- 检测潜在的bug
+- 提供修复建议
+
+### Code Review
+- 速度快：几分钟内完成审查
+- 覆盖广：可以检查多个维度（安全、性能、规范）
+- 一致性：不会遗漏
+
+### 单元测试
+- 快速生成大量测试用例
+- 覆盖边界条件
+- 生成Mock数据
+
+### API测试
+- 根据OpenAPI规范生成测试用例
+- 生成测试数据
+- 自动生成断言
+
+### E2E测试
+- 生成测试脚本
+- 自愈（selector修复）
+- 步骤补全
+
+## 测试金字塔演变
+
+### 传统测试金字塔
+```
+        E2E测试（少量）
+       /               \
+      /   集成测试       \
+     /   （中等数量）     \
+    /                     \
+   /     单元测试          \
+  /     （大量）           \
+ /_________________________\
+```
+
+### AI时代的测试策略
+- **AI生成大量单元测试**：覆盖边界条件
+- **AI生成API测试**：基于OpenAPI规范
+- **AI操作浏览器做E2E测试**：模拟真实用户
+- **人工专注于Code Review**：审查AI的审查结果
+
+## 适用场景
+
+- **所有项目**：都需要分层测试
+- **复杂项目**：需要完整的测试金字塔
+- **AI辅助开发**：充分利用AI生成测试
+
+## 优势
+
+- **全面覆盖**：从代码到端到端，全面覆盖
+- **自动化**：充分利用AI生成测试
+- **质量保障**：多层测试保证代码质量
+- **效率提升**：AI生成测试提高效率
+
+## 挑战
+
+- **维护成本**：需要维护多层测试
+- **运行时间**：完整的测试金字塔运行时间长
+- **学习成本**：需要了解多种测试工具和策略
+
+## 最佳实践
+
+1. **分层测试**：单元测试→API测试→E2E测试
+2. **AI生成测试**：利用AI快速生成大量测试用例
+3. **人工审查**：AI生成的测试需要人工审查
+4. **持续集成**：所有测试集成到CI/CD流程
+
+## 相关概念
+
+- [[核心Loop]]：核心Loop使用测试策略金字塔
+- [[超级Loop]]：超级Loop扩展了测试策略金字塔
+- [[Playwright]]：E2E测试使用的工具
+- [[Browser_Use]]：E2E测试使用的工具

AI工程/概念/规格驱动开发.md

@@ -0,0 +1,150 @@
+# 规格驱动开发（SDD）
+
+> 相关：[[AI编程演进阶段]]、[[Harness工程]]、[[Rule约束]]、[[BMAD]]、[[Spec_Kit]]、[[OpenSpec]]、[[Kiro]]
+
+## 定义
+
+**规格驱动开发**（Spec-Driven Development，SDD）是AI编程的第3阶段，以规格文档为核心的开发方法。
+
+**核心思想**：Spec是单一事实来源（SSoT），所有开发活动围绕Spec展开。
+
+## 核心特征
+
+### 1. 规格中心化
+- Spec是唯一的真相来源
+- 所有代码从Spec生成
+- Spec变更驱动代码变更
+
+### 2. 结构化表达
+- 需求以结构化形式表达
+- 使用Markdown、YAML等格式
+- 可机器解析和验证
+
+### 3. 文件驱动
+- 文件进，文件出
+- 规格文件可版本化
+- 规格文件可复用
+
+## SDD框架对比
+
+| 维度 | [[BMAD]] | [[Spec_Kit]] | [[OpenSpec]] | [[Kiro]] |
+|------|----------|--------------|--------------|----------|
+| 定位 | 企业级SDD操作系统 | 工程化Spec工作流 | 轻量Spec层 | IDE原生SDD |
+| 理念 | Spec=治理体系+多Agent编排 | Spec=开发入口+Git生命周期 | Spec=变更单元（持续演化） | Spec=可执行源 |
+| 生命周期 | 全生命周期 | 与分支绑定（短） | 长期存在（持续） | 持续驱动 |
+| 粒度 | 大（系统/模块级） | 中（Feature级） | 小（变更/Patch级） | 中（Feature+行为） |
+| 可执行 | 流程驱动 | 驱动开发流程 | 类Prompt | 可生成代码+测试 |
+| 自动验证 | 无 | 无 | 弱 | 强（内建） |
+| 适用场景 | 大型系统/多团队 | 新项目（0→1） | 存量项目/快速迭代 | 小团队/高自动化 |
+
+## 规格类型
+
+### 1. 需求规格（Feature Spec）
+```markdown
+# 用户注册功能
+
+## 用户故事
+作为一个新用户，我想要注册账号，以便使用系统功能。
+
+## 验收标准
+1. 用户可以输入邮箱和密码
+2. 系统发送验证邮件
+3. 用户点击链接完成验证
+4. 验证成功后可以登录
+
+## 字段定义
+- email: string, required, unique
+- password: string, required, min:8
+- verified: boolean, default:false
+```
+
+### 2. 设计规格（Design Spec）
+```markdown
+# 数据库设计
+
+## users表
+- id: bigint, primary key
+- email: varchar(100), unique
+- password: varchar(255)
+- verified: tinyint(1), default:0
+- created_at: timestamp
+- updated_at: timestamp
+```
+
+### 3. API规格（API Spec）
+```yaml
+openapi: 3.0.3
+paths:
+  /api/v1/users:
+    post:
+      summary: 创建用户
+      requestBody:
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateUserRequest'
+```
+
+## 规格流转
+
+### 过程方案（Plans）
+- 每次创建新文件
+- 记录实现过程
+- 不修改旧文件
+- 保留决策轨迹
+
+### 事实方案（Designs）
+- 覆盖更新最终态
+- 作为下次Plan的起点
+- 必须保持最新
+- Source of Truth
+
+## 适用场景
+
+### BMAD
+- 企业级项目
+- 多团队协作
+- 强治理需求
+- 合规要求高
+
+### Spec Kit
+- 新项目（0→1）
+- 需要Git集成
+- 中等复杂度
+
+### OpenSpec
+- 存量项目
+- 快速迭代
+- 轻量级需求
+
+### Kiro
+- 小团队
+- 高自动化需求
+- AWS项目
+
+## 优势
+
+- **单一真相来源**：避免信息不一致
+- **可追溯**：Spec变更有历史记录
+- **可验证**：Spec可以生成测试
+- **可复用**：Spec可以在项目间复用
+
+## 挑战
+
+- **初始成本**：需要建立完整的Spec体系
+- **维护成本**：Spec需要持续更新
+- **学习曲线**：团队需要理解SDD理念
+
+## 最佳实践
+
+1. **从核心Spec开始**：先定义最重要的规格
+2. **逐步扩展**：根据实践逐步添加规格
+3. **定期Review**：定期审查和优化规格
+4. **自动化验证**：尽可能自动化Spec验证
+
+## 相关概念
+
+- [[AI编程演进阶段]]：SDD是第3阶段
+- [[Harness工程]]：SDD是Harness的组成部分
+- [[过程方案vs事实方案]]：SDD的规格管理方式
+- [[BMAD]]、[[Spec_Kit]]、[[OpenSpec]]、[[Kiro]]：SDD框架

AI工程/概念/超级Loop.md

@@ -0,0 +1,223 @@
+# 超级Loop（E2E Loop）
+
+> 相关：[[核心Loop]]、[[Loop工程]]、[[测试策略金字塔]]、[[Playwright]]、[[Browser_Use]]
+
+## 定义
+
+**超级Loop**是在[[核心Loop]]基础上增加E2E测试验证的扩展循环，确保前后端联动的正确性。
+
+**核心思想**：通过E2E测试纳入更大的Loop范围，验证完整的用户流程。
+
+## 核心流程
+
+```
+开始进入循环
+    ↓
+[Chat] 进入Plan模式
+    ↓
+装载需求规格/界面原型，给出指令进行Plan
+    ↓
+[Chat] 符合要求，退出Plan模式，开始执行？
+    ↓ 是
+[模型] 读取Plan，按照Loop规则进行实现
+    ↓
+[模型] 满足Loop准出要求？
+    ↓ 否 → 重复多次/白天持续很久/夜间
+    ↓ 是
+[模型] 退出循环
+    ↓
+（给予ByPass权限）
+```
+
+## 7个步骤
+
+### 1. Plan等待确认
+在docs/plans下根据模版创建Plan。
+
+```markdown
+# Plan: 实现用户注册功能（含前端）
+
+## 目标
+实现用户注册功能，包括后端API和前端页面
+
+## 任务列表
+- [ ] 1. 实现POST /api/v1/users API
+- [ ] 2. 实现注册页面 /register
+- [ ] 3. 实现表单验证
+- [ ] 4. 实现注册成功跳转
+- [ ] 5. 编写API测试
+- [ ] 6. 编写E2E测试
+
+## 验收标准
+- 所有API测试通过
+- 所有E2E测试通过
+- 前端页面视觉效果符合设计稿
+```
+
+### 2. 编写测试用例
+在docs/test-cases下编写E2E测试用例。
+
+```markdown
+# docs/test-cases/register.md
+
+## 测试用例
+
+### TC-001: 成功注册
+1. 访问 /register 页面
+2. 输入用户名 testuser
+3. 输入邮箱 test@example.com
+4. 输入密码 Password123
+5. 确认密码 Password123
+6. 点击注册按钮
+7. 验证跳转到 /login
+8. 验证提示"注册成功"
+
+### TC-002: 用户名已存在
+1. 访问 /register 页面
+2. 输入已存在的用户名 existinguser
+3. 点击注册按钮
+4. 验证提示"用户名已存在"
+```
+
+### 3. 编写API测试
+根据Plan实现API测试，运行成功并断言失败。
+
+```java
+@Test
+void testRegister() {
+    CreateUserRequest request = new CreateUserRequest();
+    request.setUsername("testuser");
+    request.setEmail("test@example.com");
+    request.setPassword("Password123");
+    
+    Response<UserResponse> response = userClient.create(request);
+    
+    assertEquals(201, response.getCode());
+    assertNotNull(response.getData().getId());
+}
+```
+
+### 4. 编写实现
+编写后端和前端实现代码。
+
+**后端实现**：
+```java
+@PostMapping("/users")
+public Response<UserResponse> createUser(@RequestBody CreateUserRequest request) {
+    return Response.success(userAppService.create(request));
+}
+```
+
+**前端实现**：
+```tsx
+function RegisterPage() {
+  const [form] = Form.useForm();
+  
+  const handleSubmit = async (values) => {
+    await axios.post('/api/v1/users', values);
+    message.success('注册成功');
+    navigate('/login');
+  };
+  
+  return (
+    <Form form={form} onFinish={handleSubmit}>
+      <Form.Item name="username" rules={[{ required: true }]}>
+        <Input placeholder="用户名" />
+      </Form.Item>
+      <Button type="primary" htmlType="submit">注册</Button>
+    </Form>
+  );
+}
+```
+
+### 5. 运行API测试
+运行测试，并修复失败的测试和其他错误。
+
+```bash
+mvn test -Dtest=UserApiTest
+```
+
+### 6. 浏览器调试
+使用[[Playwright]]调试前端，确认视觉效果和交互功能。
+
+```typescript
+test('注册页面视觉效果', async ({ page }) => {
+  await page.goto('/register');
+  
+  // 截图验证视觉效果
+  const screenshot = await page.screenshot();
+  // 调用AI视觉模型验证
+  
+  // 验证表单验证
+  await page.fill('[name="email"]', 'invalid-email');
+  await page.click('button[type="submit"]');
+  await expect(page.getByText('请输入有效的邮箱')).toBeVisible();
+});
+```
+
+### 7. 编写E2E测试
+编写[[Playwright]] E2E测试，覆盖本轮需求的测试场景。
+
+```typescript
+test('完整的注册流程', async ({ page }) => {
+  await page.goto('/register');
+  
+  await page.getByLabel('用户名').fill('testuser');
+  await page.getByLabel('邮箱').fill('test@example.com');
+  await page.getByLabel('密码').fill('Password123');
+  await page.getByLabel('确认密码').fill('Password123');
+  
+  await page.getByRole('button', { name: '注册' }).click();
+  
+  await expect(page).toHaveURL(/\/login/);
+  await expect(page.getByText('注册成功')).toBeVisible();
+});
+```
+
+## 超级Loop vs 核心Loop
+
+| 维度 | [[核心Loop]] | 超级Loop |
+|------|-------------|----------|
+| 测试范围 | API测试 | API测试 + E2E测试 |
+| 验证层次 | 后端逻辑 | 前后端联动 |
+| 复杂度 | 中等 | 高 |
+| 运行时间 | 几分钟 | 几十分钟到几小时 |
+| Token消耗 | 中等 | 高 |
+| 适用场景 | 后端开发 | 全栈开发 |
+
+## 适用场景
+
+- **全栈开发**：需要同时开发前后端
+- **复杂交互**：需要验证前后端联动
+- **用户体验**：需要验证视觉效果
+- **完整流程**：需要验证完整的用户流程
+
+## 优势
+
+- **全面验证**：验证前后端联动的正确性
+- **用户体验**：验证视觉效果和交互
+- **完整流程**：验证完整的用户流程
+- **质量保障**：E2E测试保证质量
+
+## 挑战
+
+- **成本高**：运行时间长，Token消耗大
+- **维护成本**：E2E测试需要持续维护
+- **调试复杂**：需要调试前后端
+- **环境依赖**：依赖完整的环境
+
+## 最佳实践
+
+1. **先写测试用例**：明确验收标准
+2. **API测试先通过**：确保后端逻辑正确
+3. **浏览器调试**：验证前端视觉效果
+4. **E2E测试覆盖**：确保前后端联动正确
+5. **成本控制**：仅在必要时使用
+
+## 相关概念
+
+- [[核心Loop]]：超级Loop基于核心Loop
+- [[Loop工程]]：超级Loop是Loop工程的扩展
+- [[测试策略金字塔]]：超级Loop使用的测试策略
+- [[Playwright]]：超级Loop使用的E2E测试工具
+- [[Browser_Use]]：超级Loop可能使用的浏览器自动化工具

AI工程/概念/过程方案vs事实方案.md

@@ -0,0 +1,170 @@
+# 过程方案vs事实方案
+
+> 相关：[[规格驱动开发]]、[[上下文体系]]、[[Harness工程]]
+
+## 定义
+
+**过程方案**和**事实方案**是[[规格驱动开发]]中两种不同的规格管理方式。
+
+- **过程方案（Plans）**：记录实现过程，每次新建文件，用完即弃
+- **事实方案（Designs）**：记录系统真相，覆盖更新，长期维护
+
+## 核心区别
+
+| 维度 | 过程方案（Plans） | 事实方案（Designs） |
+|------|------------------|-------------------|
+| 目的 | 记录实现过程 | 记录当前状态 |
+| 更新方式 | 追加新文件 | 覆盖更新 |
+| 生命周期 | 短期（任务完成后归档） | 长期（持续维护） |
+| 维护成本 | 低（不修改旧文件） | 高（必须保持最新） |
+| 使用场景 | 任务执行、问题排查 | 新功能开发、架构决策 |
+| 示例 | plan-2026-06-20-feature-x.md | database-schema.md |
+
+## 过程方案（Plans）
+
+### 特征
+- 每次任务创建新文件
+- 文件命名包含日期：`plan-YYYY-MM-DD-feature-name.md`
+- 任务完成后移动到`archive/`目录
+- 不修改旧文件，保留决策轨迹
+
+### 内容结构
+```markdown
+# Plan: 实现用户注册功能
+
+## 目标
+实现用户注册API，支持邮箱验证
+
+## 任务列表
+- [ ] 1. 创建数据库表users
+- [ ] 2. 实现POST /api/v1/users API
+- [ ] 3. 实现邮箱验证逻辑
+
+## 实现方案
+1. 使用Flyway创建users表
+2. Controller接收CreateUserCommand
+3. AppService调用UserRepository保存
+
+## 状态
+- 开始时间：2026-06-20 10:00
+- 预计完成：2026-06-20 12:00
+- 实际完成：2026-06-20 11:30
+
+## 问题记录
+- 10:30 发现数据库连接池配置问题
+- 11:00 邮箱服务超时，增加重试机制
+```
+
+### 最佳实践
+- **命名规范**：`plan-YYYY-MM-DD-feature-name.md`
+- **内容结构**：目标、方案、任务列表、状态、问题记录
+- **归档策略**：任务完成后移动到`archive/`目录
+
+## 事实方案（Designs）
+
+### 特征
+- 每次覆盖更新
+- 文件命名使用功能名称：`database-schema.md`
+- 必须保持最新状态
+- 作为下次Plan的事实依据
+
+### 内容结构
+```markdown
+# 数据库设计
+
+## 概述
+系统数据库设计，包含用户、角色、权限等表。
+
+## users表
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| id | bigint | 主键 |
+| username | varchar(50) | 用户名，唯一 |
+| email | varchar(100) | 邮箱，唯一 |
+| password | varchar(255) | 密码，加密存储 |
+| status | tinyint(1) | 状态：0-禁用，1-启用 |
+| created_at | timestamp | 创建时间 |
+| updated_at | timestamp | 更新时间 |
+
+## roles表
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| id | bigint | 主键 |
+| name | varchar(20) | 角色名称 |
+
+## 变更历史
+- 2026-06-20：添加users表
+- 2026-06-21：添加roles表
+- 2026-06-22：添加user_roles关联表
+```
+
+### 最佳实践
+- **命名规范**：使用功能名称，如`database-schema.md`
+- **内容结构**：概述、详细设计、变更历史
+- **更新策略**：每次变更必须更新文档，保持最新
+
+## 目录结构
+
+```
+docs/
+├── standards/     # 标准规格（事实方案）
+├── features/      # 需求规格（事实方案）
+├── designs/       # 设计规格（事实方案）
+├── plans/         # 计划规格（过程方案）
+│   ├── archive/   # 归档的计划
+│   └── plan-2026-06-20-feature-x.md
+└── others/        # 架构决策、Release、测试用例等
+```
+
+## 使用策略
+
+### 何时使用过程方案
+- 任务执行过程记录
+- 问题排查记录
+- 决策轨迹记录
+- 临时方案记录
+
+### 何时使用事实方案
+- 数据库设计
+- API设计
+- 架构设计
+- 标准规范
+- 需求规格
+
+## 优势与局限
+
+### 过程方案
+**优势**：
+- 维护成本低
+- 保留决策轨迹
+- 易于追溯历史
+
+**局限**：
+- 文件数量多
+- 需要定期归档
+- 不反映当前状态
+
+### 事实方案
+**优势**：
+- 反映当前状态
+- 单一真相来源
+- 易于理解
+
+**局限**：
+- 维护成本高
+- 需要持续更新
+- 丢失历史信息
+
+## 最佳实践
+
+1. **明确区分**：清楚区分哪些是过程方案，哪些是事实方案
+2. **定期归档**：过程方案定期归档到`archive/`目录
+3. **保持最新**：事实方案必须保持最新状态
+4. **变更历史**：事实方案记录变更历史
+5. **关联引用**：Plans引用Designs，确保一致性
+
+## 相关概念
+
+- [[规格驱动开发]]：过程方案和事实方案是SDD的规格管理方式
+- [[上下文体系]]：过程方案和事实方案是上下文体系的组成部分
+- [[Harness工程]]：过程方案和事实方案是Harness的文档管理方式

Clippings/Introducing 3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles 1.md

@@ -0,0 +1,70 @@
+---
+title: "Introducing 3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles"
+source: "https://cesium.com/blog/2026/04/27/3d-gaussian-splats-lod/"
+author:
+  - "[[Shehzan Mohammed]]"
+published: 2026-04-27
+created: 2026-05-11
+description: "3D Gaussian splats are now available in the Cesium and 3D Tiles ecosystems, including CesiumJS, Cesium for Unreal, and Cesium ion."
+tags:
+  - "clippings"
+---
+3D Gaussian splats are now available in the Cesium and 3D Tiles ecosystems, including CesiumJS, Cesium for Unreal, and Cesium ion. This integration enables developers to stream and visualize high-fidelity, photorealistic 3D content that captures the real world with unprecedented detail. By leveraging 3D Tiles as a spatial index and glTF as the payload, massive 3D Gaussian splat datasets can now be streamed with level of detail (LOD), ensuring high performance from city-scale environments down to sub-centimeter details.
+
+3D Gaussian splatting is an efficient radiance field reconstruction method that converts 2D images into a sparse cloud of volumetric 3D Gaussians. Unlike traditional photogrammetry, which often struggles to represent thin or complex structures, 3D Gaussian splats excel at preserving visual fidelity for cables, power lines, vegetation, and reflective surfaces by creating a point cloud of soft, rounded shapes of the subject, with each point defined by properties including position, orientation, color, and opacity. This technique uses spherical harmonics to support view-dependent lighting, allowing for realistic specular reflections and anisotropy that traditional reality meshes cannot easily replicate.
+
+<iframe src="https://player.vimeo.com/video/1186727561?app_id=122963" width="426" height="240" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" title="3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles"></iframe>
+
+3D Gaussian splatting provides significant advantages for industries requiring high-fidelity reality capture and photorealistic digital twins, including infrastructure monitoring, telecom tower maintenance, and electrical utility and substation inspections—plus the built environment, such as in real estate, where traditional mesh and point cloud methods often have limits. Beyond industrial applications, we see 3D Gaussian splats being adopted in media and entertainment to capture challenging visual details like reflections, semitransparent materials, and fire. 3D Gaussian splats are expected to play a key role in long-term asset monitoring and situational awareness, enabling users to track changes in the natural and built environment over the entire life cycle.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelNBsBOoF08xOq4_3DGS_UE_Crane.jpg?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=4000)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This crane is depicted with Cesium for Unreal.
+
+![3D Gaussian splat of a crane.](https://images.prismic.io/cesium/aelNnMBOoF08xOq8_Portable_crane.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2549)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOUMBOoF08xOq__Partially_destroyed_msft_building1.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2552)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOTcBOoF08xOq-_Partially_destroyed_msft_building2.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2547)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOusBOoF08xOrH_Power_Station_LODs_latest.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2548)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOt8BOoF08xOrG_Cell_Tower_LODs_latest.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2547)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+## Standardizing 3D Gaussian splats in glTF with SPZ compression
+
+To ensure 3D Gaussian splats are interoperable across platforms, we have collaborated with Khronos, Open Geospatial Consortium (OGC), Esri, and Niantic Spatial to integrate this new graphics primitive into the glTF 3D asset standard. This effort centers on two new extensions: [KHR\_gaussian\_splatting](https://github.com/KhronosGroup/glTF/tree/4ecfc3bd8c439a1c3feab04218212e6b9b222253/extensions/2.0/Khronos/KHR_gaussian_splatting) and [KHR\_gaussian\_splatting\_compression\_spz](https://github.com/KhronosGroup/glTF/pull/2531). The base glTF extension defines how splats are stored as point primitives, which allows for a graceful fallback to sparse point clouds in renderers that do not yet support rendering 3D Gaussian splats.
+
+A major challenge for 3D Gaussian splats has been their massive file size, which can hinder efficient streaming. To solve this, we adopted the SPZ compression format, an open source solution provided by Niantic Spatial. SPZ uses advanced quantization techniques and gzip to compress splat data by up to 90% compared to standard PLY files while maintaining visual fidelity. This format is particularly effective at handling spherical harmonic data for specular lighting. Furthermore, the recent SPZ 2.0.0 release introduced improved rotational accuracy for linear geospatial features—such as antennas and power lines—by encoding rotations as normalized quaternions.
+
+3D Gaussian splats will be added to 3D Tiles as part of the proposed 3D Tiles 2.0 OGC community standard.
+
+## Creating 3D Gaussian splats using Cesium ion
+
+With the integration of iTwin Capture technology into Cesium ion, the platform provides an end-to-end pipeline for reality modeling, including the creation of 3D Gaussian splats with LOD. Users can upload source photos directly to Cesium ion, which will automatically reconstruct a 3D Tileset as a mesh, point cloud, or 3D Gaussian splats.
+
+To accommodate different development needs, these workflows are accessible through both the Cesium ion web interface and via REST APIs, enabling everything from manual one-off uploads to fully automated, high-scale production pipelines. Once tiled, these splats are georeferenced, allowing them to be instantly combined with global datasets like Cesium World Terrain or Google Photorealistic 3D Tiles for full geospatial context.
+
+![3D Gaussian splatting tileset of Microsoft Redmond Campus, as viewed in CesiumJS. Captured in partnership with Bentley Systems. This tileset uses 20,169 photos (427.7 gigapixels, DJI FC6310 camera) and covers an area of about 3.7 sq km, with mean ground sampling distance 3 cm. The reconstruction is 110 million splats.](https://images.prismic.io/cesium/aelPlMBOoF08xOrQ_Parially_finished_and_construction_zone_4.png?auto=compress%2Cformat&w=2555)
+
+3D Gaussian splat tileset of Microsoft Redmond Campus, as viewed in CesiumJS. Captured in partnership with Bentley Systems. This tileset uses 20,169 photos (427.7 gigapixels, DJI FC6310 camera) and covers an area of about 3.7 sq km, with mean ground sampling distance 3 cm. The reconstruction is 110 million splats.
+
+## Streaming to CesiumJS, Cesium for Unreal, and more
+
+CesiumJS now supports 3D Gaussian splat tilesets. The implementation uses specialized shaders for volumetric rendering and high-performance sorting using WebAssembly for increased performance. Developers using [CesiumJS](https://cesium.com/platform/cesiumjs/) can build high-fidelity digital twin applications leveraging 3D Gaussian splat tilesets in conjunction with previously supported data types.
+
+For developers building immersive experiences with game engines, [Cesium for Unreal](https://cesium.com/platform/cesium-for-unreal/) now supports 3D Gaussian splat tilesets, as well. This enables the integration of massive 3D Gaussian splat dataset rendering into the Unreal Engine ecosystem with the ability to stream 3D Gaussian splats with LOD directly from Cesium ion. In addition to Cesium for Unreal, we plan to add support to Cesium for Unity and other runtime engines based on community feedback. By standardizing splat delivery through 3D Tiles and glTF extensions, we’re ensuring that these assets remain interoperable across platforms as the field of neural rendering evolves.
+
+## Getting started with 3D Gaussian splats
+
+Upload your own photos to Cesium ion by [signing up for a free community account](https://ion.cesium.com/signup). You can try out live examples in the Cesium Sandcastle or start building your own reality models today.

Clippings/Introducing 3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles.md

@@ -0,0 +1,70 @@
+---
+title: "Introducing 3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles"
+source: "https://cesium.com/blog/2026/04/27/3d-gaussian-splats-lod/"
+author:
+  - "[[Shehzan Mohammed]]"
+published: 2026-04-27
+created: 2026-05-11
+description: "3D Gaussian splats are now available in the Cesium and 3D Tiles ecosystems, including CesiumJS, Cesium for Unreal, and Cesium ion."
+tags:
+  - "clippings"
+---
+3D Gaussian splats are now available in the Cesium and 3D Tiles ecosystems, including CesiumJS, Cesium for Unreal, and Cesium ion. This integration enables developers to stream and visualize high-fidelity, photorealistic 3D content that captures the real world with unprecedented detail. By leveraging 3D Tiles as a spatial index and glTF as the payload, massive 3D Gaussian splat datasets can now be streamed with level of detail (LOD), ensuring high performance from city-scale environments down to sub-centimeter details.
+
+3D Gaussian splatting is an efficient radiance field reconstruction method that converts 2D images into a sparse cloud of volumetric 3D Gaussians. Unlike traditional photogrammetry, which often struggles to represent thin or complex structures, 3D Gaussian splats excel at preserving visual fidelity for cables, power lines, vegetation, and reflective surfaces by creating a point cloud of soft, rounded shapes of the subject, with each point defined by properties including position, orientation, color, and opacity. This technique uses spherical harmonics to support view-dependent lighting, allowing for realistic specular reflections and anisotropy that traditional reality meshes cannot easily replicate.
+
+<iframe src="https://player.vimeo.com/video/1186727561?app_id=122963" width="426" height="240" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share" title="3D Gaussian Splats with Hierarchical Level of Detail Using 3D Tiles"></iframe>
+
+3D Gaussian splatting provides significant advantages for industries requiring high-fidelity reality capture and photorealistic digital twins, including infrastructure monitoring, telecom tower maintenance, and electrical utility and substation inspections—plus the built environment, such as in real estate, where traditional mesh and point cloud methods often have limits. Beyond industrial applications, we see 3D Gaussian splats being adopted in media and entertainment to capture challenging visual details like reflections, semitransparent materials, and fire. 3D Gaussian splats are expected to play a key role in long-term asset monitoring and situational awareness, enabling users to track changes in the natural and built environment over the entire life cycle.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelNBsBOoF08xOq4_3DGS_UE_Crane.jpg?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=4000)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This crane is depicted with Cesium for Unreal.
+
+![3D Gaussian splat of a crane.](https://images.prismic.io/cesium/aelNnMBOoF08xOq8_Portable_crane.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2549)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOUMBOoF08xOq__Partially_destroyed_msft_building1.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2552)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOTcBOoF08xOq-_Partially_destroyed_msft_building2.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2547)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOusBOoF08xOrH_Power_Station_LODs_latest.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2548)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+![3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers.](https://images.prismic.io/cesium/aelOt8BOoF08xOrG_Cell_Tower_LODs_latest.png?auto=compress%2Cformat&fit=crop&ar=16%3A9&crop=faces%2Ccenter&w=2547)
+
+3D Gaussian splats enable high-fidelity accurate visualizations of thin-and-long assets like cranes, building materials, power stations, and cell towers. This scene is depicted in CesiumJS.
+
+## Standardizing 3D Gaussian splats in glTF with SPZ compression
+
+To ensure 3D Gaussian splats are interoperable across platforms, we have collaborated with Khronos, Open Geospatial Consortium (OGC), Esri, and Niantic Spatial to integrate this new graphics primitive into the glTF 3D asset standard. This effort centers on two new extensions: [KHR\_gaussian\_splatting](https://github.com/KhronosGroup/glTF/tree/4ecfc3bd8c439a1c3feab04218212e6b9b222253/extensions/2.0/Khronos/KHR_gaussian_splatting) and [KHR\_gaussian\_splatting\_compression\_spz](https://github.com/KhronosGroup/glTF/pull/2531). The base glTF extension defines how splats are stored as point primitives, which allows for a graceful fallback to sparse point clouds in renderers that do not yet support rendering 3D Gaussian splats.
+
+A major challenge for 3D Gaussian splats has been their massive file size, which can hinder efficient streaming. To solve this, we adopted the SPZ compression format, an open source solution provided by Niantic Spatial. SPZ uses advanced quantization techniques and gzip to compress splat data by up to 90% compared to standard PLY files while maintaining visual fidelity. This format is particularly effective at handling spherical harmonic data for specular lighting. Furthermore, the recent SPZ 2.0.0 release introduced improved rotational accuracy for linear geospatial features—such as antennas and power lines—by encoding rotations as normalized quaternions.
+
+3D Gaussian splats will be added to 3D Tiles as part of the proposed 3D Tiles 2.0 OGC community standard.
+
+## Creating 3D Gaussian splats using Cesium ion
+
+With the integration of iTwin Capture technology into Cesium ion, the platform provides an end-to-end pipeline for reality modeling, including the creation of 3D Gaussian splats with LOD. Users can upload source photos directly to Cesium ion, which will automatically reconstruct a 3D Tileset as a mesh, point cloud, or 3D Gaussian splats.
+
+To accommodate different development needs, these workflows are accessible through both the Cesium ion web interface and via REST APIs, enabling everything from manual one-off uploads to fully automated, high-scale production pipelines. Once tiled, these splats are georeferenced, allowing them to be instantly combined with global datasets like Cesium World Terrain or Google Photorealistic 3D Tiles for full geospatial context.
+
+![3D Gaussian splatting tileset of Microsoft Redmond Campus, as viewed in CesiumJS. Captured in partnership with Bentley Systems. This tileset uses 20,169 photos (427.7 gigapixels, DJI FC6310 camera) and covers an area of about 3.7 sq km, with mean ground sampling distance 3 cm. The reconstruction is 110 million splats.](https://images.prismic.io/cesium/aelPlMBOoF08xOrQ_Parially_finished_and_construction_zone_4.png?auto=compress%2Cformat&w=2555)
+
+3D Gaussian splat tileset of Microsoft Redmond Campus, as viewed in CesiumJS. Captured in partnership with Bentley Systems. This tileset uses 20,169 photos (427.7 gigapixels, DJI FC6310 camera) and covers an area of about 3.7 sq km, with mean ground sampling distance 3 cm. The reconstruction is 110 million splats.
+
+## Streaming to CesiumJS, Cesium for Unreal, and more
+
+CesiumJS now supports 3D Gaussian splat tilesets. The implementation uses specialized shaders for volumetric rendering and high-performance sorting using WebAssembly for increased performance. Developers using [CesiumJS](https://cesium.com/platform/cesiumjs/) can build high-fidelity digital twin applications leveraging 3D Gaussian splat tilesets in conjunction with previously supported data types.
+
+For developers building immersive experiences with game engines, [Cesium for Unreal](https://cesium.com/platform/cesium-for-unreal/) now supports 3D Gaussian splat tilesets, as well. This enables the integration of massive 3D Gaussian splat dataset rendering into the Unreal Engine ecosystem with the ability to stream 3D Gaussian splats with LOD directly from Cesium ion. In addition to Cesium for Unreal, we plan to add support to Cesium for Unity and other runtime engines based on community feedback. By standardizing splat delivery through 3D Tiles and glTF extensions, we’re ensuring that these assets remain interoperable across platforms as the field of neural rendering evolves.
+
+## Getting started with 3D Gaussian splats
+
+Upload your own photos to Cesium ion by [signing up for a free community account](https://ion.cesium.com/signup). You can try out live examples in the Cesium Sandcastle or start building your own reality models today.

Docker/Docker安装redis.md

@@ -1,128 +0,0 @@
-# Docker 安装 Redis
-
-## 1. 下载 Redis 镜像
-
-```bash
-docker pull redis:latest
-
-# 或者指定版本
-docker pull redis:7-alpine
-```
-
-## 2. 创建本地目录
-
-```bash
-# 创建配置和数据目录
-mkdir -p redis/conf redis/data
-```
-
-## 3. 创建 Redis 配置文件
-
-```bash
-cat > redis/conf/redis.conf << 'EOF'
-# 基本配置
-bind 0.0.0.0
-protected-mode no
-port 6379
-
-# 持久化
-appendonly yes
-appendfilename "appendonly.aof"
-
-# 内存管理
-maxmemory 256mb
-maxmemory-policy allkeys-lru
-
-# 日志
-loglevel notice
-EOF
-```
-
-## 4. 启动 Redis 容器
-
-```bash
-docker run -d \
-  --name redis \
-  -p 6379:6379 \
-  -v $PWD/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-  -v $PWD/redis/data:/data \
-  redis:latest \
-  redis-server /usr/local/etc/redis/redis.conf
-```
-
-### 参数说明
-
-| 参数 | 说明 |
-|------|------|
-| `-d` | 后台运行 |
-| `--name redis` | 容器名称 |
-| `-p 6379:6379` | 端口映射 |
-| `-v .../redis.conf:...` | 配置文件挂载 |
-| `-v .../data:/data` | 数据目录挂载 |
-| `redis-server ...` | 使用指定配置文件启动 |
-
-## 5. 连接测试
-
-```bash
-# 使用 redis-cli 连接
-docker exec -it redis redis-cli
-
-# 或者直接用 redis-cli（如果主机已安装）
-redis-cli
-
-# 测试
-> PING
-PONG
-
-> SET test "hello"
-OK
-
-> GET test
-"hello"
-```
-
-## 6. 常用运维命令
-
-```bash
-# 查看容器状态
-docker ps | grep redis
-
-# 查看日志
-docker logs -f redis
-
-# 进入容器
-docker exec -it redis sh
-
-# 停止/启动
-docker stop redis
-docker start redis
-```
-
-## 7. 无配置文件快速启动
-
-如果不需要自定义配置：
-
-```bash
-docker run -d \
-  --name redis \
-  -p 6379:6379 \
-  -v redis-data:/data \
-  redis:latest \
-  redis-server --appendonly yes
-```
-
-## 8. 数据备份
-
-Redis 数据存储在 `/data` 目录（已挂载到本地）：
-
-```bash
-# 备份
-tar -czvf redis-backup-$(date +%Y%m%d).tar.gz redis/data/
-
-# 恢复
-tar -xzvf redis-backup-xxxxxxxx.tar.gz
-```
-
----
-
-> 参考：[Redis Docker 官方文档](https://hub.docker.com/_/redis)

Docker/docker镜像清理.md

@@ -1,62 +0,0 @@
-# Docker 镜像清理
-
-## 清理无用镜像
-
-### 方法一：prune 命令（推荐）
-
-```bash
-# 清理悬空镜像（无 tag 的镜像）
-docker image prune -f
-
-# 清理所有未使用镜像
-docker image prune -a -f
-```
-
-### 方法二：批量清理
-
-```bash
-# 批量删除所有无用镜像，不会影响正在使用的镜像
-docker images | awk 'NR!=1{print $1":"$2}' | xargs docker rmi
-```
-
-### 方法三：system prune（全面清理）
-
-```bash
-# 清理所有未使用的容器、网络、镜像
-docker system prune -f
-
-# 清理所有未使用的镜像，不仅仅是悬空镜像
-docker system prune -a -f
-
-# 清理卷（注意：会删除数据）
-docker system prune --volumes -f
-```
-
-## 清理前后对比
-
-```bash
-# 查看清理前
-docker images -a
-
-# 清理
-docker system prune -f
-
-# 查看清理后
-docker images -a
-```
-
-## 定时清理（可选）
-
-创建 cron 任务定期清理：
-
-```bash
-# 编辑 crontab
-crontab -e
-
-# 每周日凌晨 3 点清理
-0 3 * * 0 /usr/bin/docker system prune -f
-```
-
----
-
-> 参考：[Docker 官方文档](https://docs.docker.com/config/pruning/)

HomePage/MeNav导航站.md

@@ -0,0 +1,95 @@
+# MeNav 个人导航站生成器
+
+> 一个轻量的个人导航网站，轻量级、高度可定制，完全静态部署
+
+- **⭐ GitHub**: rbetree/menav (256 stars)
+- **许可证**: AGPL-3.0
+- **技术栈**: HTML5 + CSS3 + JavaScript + Handlebars
+
+---
+
+## 核心特点
+
+- 🚀 **静态一键部署** — 无数据库，无后端，纯静态页面
+- 📂 **书签导入** — 从浏览器书签一键导入
+- 🎨 **多层级嵌套** — 支持 2-4 层级的分类结构
+- 🌙 **双主题** — 明亮/黑暗主题切换
+- 🔗 **GitHub Pages** — 一键 Fork 部署
+- 🔖 **自动同步** — 配合 MarksVault 浏览器扩展，支持书签自动同步
+
+---
+
+## 快速开始
+
+### 1. 克隆仓库
+
+```bash
+git clone https://github.com/rbetree/menav.git
+cd menav
+```
+
+### 2. 安装依赖
+
+```bash
+npm install
+```
+
+### 3. 配置
+
+编辑 `config/` 下的配置文件，定义你的网站分类和链接。
+
+### 4. 本地预览
+
+```bash
+npm run dev
+```
+
+### 5. 构建
+
+```bash
+npm run build
+```
+
+构建产物在 `dist/` 目录。
+
+---
+
+## 部署到 GitHub Pages
+
+1. Fork [menav](https://github.com/rbetree/menav) 仓库
+2. 在仓库 Settings → Pages 中启用 GitHub Pages
+3. 选择 `gh-pages` 分支
+4. 访问 `https://yourusername.github.io/menav/`
+
+---
+
+## 书签导入
+
+支持从浏览器书签导入，生成导航站点：
+
+1. 导出浏览器书签为 HTML
+2. 使用 MeNav 的书签导入功能
+3. 自动生成分类结构
+
+---
+
+## 项目结构
+
+```
+menav/
+├── src/          # 生成器、书签处理、前端脚本
+├── templates/    # Handlebars 模板
+├── config/       # 模块化配置
+├── assets/       # 静态资源
+├── bookmarks/    # 书签导入相关
+└── dist/         # 构建产物
+```
+
+---
+
+## 适用场景
+
+- 个人导航主页
+- 书签管理
+- 团队内部链接导航
+- 实验室/项目资源汇总

wiki/AI工程/AIAgent浏览器与数据采集工具调研.md

@@ -0,0 +1,97 @@
+# AI Agent 浏览器与数据采集工具调研
+
+> 来源: https://mp.weixin.qq.com/s/opVr-6roUTCD5BSBcx4Zag
+> 研究日期: 2026-05-05
+
+## 文章概要
+
+独立开发者 @GoSailGlobal 调研了市面上 18 款主流 AI Agent 浏览器和数据采集工具，按功能与技术路线分为**五大派系**。
+
+## 五大派系分类
+
+| 派系 | 定位 | 代表工具 |
+|------|------|----------|
+| **王者派** | 高星标、成熟稳定 | browser-use, MediaCrawler, Scrapling, playwright-mcp |
+| **Rust 主权派** | 速度 + 本地控制 | agent-browser, obscura, AutoCLI |
+| **MCP 协议派** | IDE 深度集成 | mcp-chrome, browser-tools-mcp, firecrawl-mcp |
+| **CLI Hub 派** | 网站转 CLI，复用登录态 | OpenCLI, AutoCLI, feedgrab |
+| **极简备胎** | 零安装、临时使用 | r.jina.ai |
+
+## 核心选型建议
+
+| 场景 | 推荐工具 |
+|------|----------|
+| 临时抓取单 URL 转 Markdown | r.jina.ai |
+| 完整自动化任务 | browser-use |
+| 复用 Chrome 已登录状态 | mcp-chrome / AutoCLI |
+| 国内社媒爬取 | MediaCrawler + feedgrab |
+| 多平台社媒采集 | agent-reach + MediaCrawler + feedgrab |
+| IDE 内嵌 | playwright-mcp |
+| 追求极致速度 | agent-browser（Rust） |
+
+## 重点工具详解
+
+### 王者派（高成熟度首选）
+
+| 工具 | 说明 |
+|------|------|
+| **browser-use** | AI Agent 浏览器自动化框架，支持多种 LLM，处理表单/购物/研究 |
+| **MediaCrawler** | 国内自媒体爬虫之王，支持小红书/抖音/快手/B站/微博/知乎 |
+| **Scrapling** | 自适应网页抓取，擅长反反爬（Cloudflare 等） |
+| **playwright-mcp** | Microsoft 出品，MCP 协议浏览器自动化，适合 IDE 内 Agent |
+| **agent-reach** | 多平台采集器（Twitter/Reddit/YouTube/GitHub/B 站/小红书），CLI 驱动 |
+| **OpenCLI** | 将网站/工具转为 CLI，复用登录态，近期关注暴涨 |
+
+### Rust 主权派（速度与控制优先）
+
+| 工具 | 说明 |
+|------|------|
+| **agent-browser** | Vercel 出品，Rust 实现，高效 headless browser |
+| **obscura** | 专为 AI 设计的 Rust headless 浏览器 |
+| **AutoCLI** | 复用 Chrome 登录态，支持 55+ 站点，单文件二进制 |
+
+### MCP 协议派（IDE 深度集成）
+
+| 工具 | 说明 |
+|------|------|
+| **mcp-chrome** | 10.7K ⭐，直接操作已登录的 Chrome |
+| **browser-tools-mcp** | 7.1K ⭐，看 console |
+| **firecrawl-mcp** | 6.2K ⭐，来自 firecrawl 官方 |
+| **dev-browser** | 6K ⭐，Claude Skill |
+| **browserbase/skills** | 2K ⭐，带网页浏览工具的 Claude Agent SDK |
+
+### CLI Hub + 极简备胎
+
+| 工具 | 说明 |
+|------|------|
+| **OpenCLI** | 18.7K ⭐，关注数暴涨 |
+| **AutoCLI** | 2.5K ⭐，速度极快，内存安全 |
+| **feedgrab** | 337 ⭐，中文友好，多平台内容抓取 |
+| **jina** | r.jina.ai/URL，零安装转 Markdown |
+
+## 工具优点共性
+
+- ✅ 大多开源免费
+- ✅ 支持登录态复用，绕过部分反爬
+- ✅ 转向 Markdown/结构化输出，适合 LLM 处理
+- ✅ MCP/CLI 趋势明显，提升 Agent 集成度
+
+## 潜在挑战
+
+- ⚠️ 反爬与合规风险
+- ⚠️ 网站 UI 频繁变化，需定期维护
+- ⚠️ 本地运行需处理代理/环境问题
+- ⚠️ 复杂任务可能需付费云浏览器
+
+## 选型框架
+
+1. **明确需求**：临时阅读 → r.jina.ai；国内社媒 → MediaCrawler；复杂交互 → browser-use
+2. **优先本地/开源**：控制成本与隐私
+3. **组合使用**：agent-reach 多平台采集 + browser-use 自动化 + r.jina.ai 后备
+
+## 与我们的关联
+
+- **OpenClaw 浏览器工具**：已有 playwright 集成，可考虑引入 MCP 协议支持
+- **MediaCrawler**：可用于社交媒体数据采集（需合规）
+- **r.jina.ai**：可作为网页内容提取的备用方案
+- **AutoCLI/OpenCLI**：适合 CLI 驱动的数据采集工作流

wiki/AI工程/ClaudeCode对话导出Obsidian.md

@@ -0,0 +1,266 @@
+---
+created: 2026-05-04
+type: guide
+tags: [Claude Code, Obsidian, 数据导出, 对话存档, SQLite]
+---
+
+# Claude Code 对话导出到 Obsidian 完整方案
+
+> 将所有 Claude Code 对话会话存档到 Obsidian 知识库
+> 归档时间：2026-05-04
+
+---
+
+## 📌 原理
+
+Claude Code 的对话数据存储在本地 SQLite 数据库中：
+
+**数据库路径**：
+- macOS/Linux：`~/.claude/CLAUDE.md` 同级目录下的 `~/.claude/conversations.db`
+- 实际数据库文件：`~/.claude/*.db` 或 `~/.claude/PROJECT_ID/*.db`
+
+**数据库结构**（典型）：
+- `conversations` 表：会话元数据（ID、标题、创建时间等）
+- `messages` 表：对话消息（角色、内容、时间戳）
+- `attachments` 表：附件/文件引用
+
+---
+
+## 🔧 方案一：Python 脚本导出（推荐）
+
+### 1. 导出脚本
+
+```python
+#!/usr/bin/env python3
+"""
+claude_to_obsidian.py
+将 Claude Code 所有对话导出为 Obsidian Markdown 笔记
+"""
+
+import sqlite3
+import os
+import json
+from datetime import datetime
+from pathlib import Path
+
+# 配置
+CLAUDE_DB_PATH = os.path.expanduser("~/.claude/conversations.db")
+OBSIDIAN_PATH = "/obsidian/ClaudeCode对话/"  # 你的 Obsidian vault 路径
+
+def export_all():
+    if not os.path.exists(CLAUDE_DB_PATH):
+        print(f"❌ 数据库不存在: {CLAUDE_DB_PATH}")
+        print("请确认 Claude Code 已安装并运行过")
+        return
+    
+    os.makedirs(OBSIDIAN_PATH, exist_ok=True)
+    
+    conn = sqlite3.connect(CLAUDE_DB_PATH)
+    conn.row_factory = sqlite3.Row
+    cursor = conn.cursor()
+    
+    # 获取所有会话
+    cursor.execute("""
+        SELECT c.id, c.title, c.created_at, c.updated_at,
+               COUNT(m.id) as msg_count
+        FROM conversations c
+        LEFT JOIN messages m ON c.id = m.conversation_id
+        GROUP BY c.id
+        ORDER BY c.updated_at DESC
+    """)
+    
+    conversations = cursor.fetchall()
+    print(f"📊 找到 {len(conversations)} 个会话")
+    
+    exported = 0
+    for conv in conversations:
+        title = conv['title'] or f"untitled-{conv['id'][:8]}"
+        # 文件名安全处理
+        safe_title = "".join(c for c in title if c not in r'\/:*?"<>|')
+        safe_title = safe_title[:80]  # 限制长度
+        filename = f"{safe_title}.md"
+        filepath = os.path.join(OBSIDIAN_PATH, filename)
+        
+        # 获取该会话的所有消息
+        cursor.execute("""
+            SELECT role, content, created_at
+            FROM messages
+            WHERE conversation_id = ?
+            ORDER BY created_at ASC
+        """, (conv['id'],))
+        
+        messages = cursor.fetchall()
+        
+        # 生成 Markdown
+        md = generate_markdown(conv, messages)
+        
+        with open(filepath, 'w', encoding='utf-8') as f:
+            f.write(md)
+        
+        exported += 1
+        print(f"  ✅ {title} ({len(messages)} 条消息)")
+    
+    print(f"\n🎉 完成！导出 {exported} 个会话到 {OBSIDIAN_PATH}")
+    conn.close()
+
+def generate_markdown(conv, messages):
+    created = datetime.fromtimestamp(conv['created_at']).strftime('%Y-%m-%d %H:%M:%S') if conv['created_at'] else 'unknown'
+    updated = datetime.fromtimestamp(conv['updated_at']).strftime('%Y-%m-%d %H:%M:%S') if conv['updated_at'] else 'unknown'
+    
+    md = f"""---
+created: {created}
+updated: {updated}
+tags: [claude-code, 对话]
+conversation_id: {conv['id']}
+message_count: {len(messages)}
+---
+
+# {conv['title'] or 'Untitled'}
+
+> 创建时间：{created}
+> 更新时间：{updated}
+
+---
+
+## 对话记录
+
+"""
+    
+    for msg in messages:
+        role = msg['role']  # 'user' or 'assistant'
+        content = msg['content'] or ''
+        ts = datetime.fromtimestamp(msg['created_at']).strftime('%H:%M:%S') if msg['created_at'] else ''
+        
+        if role == 'user':
+            md += f"\n### 👤 用户 `{ts}`\n\n"
+        else:
+            md += f"\n### 🤖 Claude `{ts}`\n\n"
+        
+        # 处理内容（可能是 JSON 字符串）
+        md += sanitize_content(content)
+        md += "\n\n---\n"
+    
+    return md
+
+def sanitize_content(content):
+    """清理内容，移除可能的工具调用元数据"""
+    try:
+        # 尝试解析 JSON
+        data = json.loads(content)
+        if isinstance(data, dict):
+            # 提取文本内容
+            if 'content' in data:
+                return data['content']
+            if 'text' in data:
+                return data['text']
+            return json.dumps(data, indent=2, ensure_ascii=False)
+    except (json.JSONDecodeError, TypeError):
+        pass
+    
+    return str(content)
+
+if __name__ == "__main__":
+    export_all()
+```
+
+### 2. 使用
+
+```bash
+# 安装依赖（通常不需要）
+pip install sqlite3  # Python 内置
+
+# 运行导出
+python3 claude_to_obsidian.py
+```
+
+---
+
+## 🔧 方案二：直接查看数据库结构
+
+```bash
+# 查看数据库表
+sqlite3 ~/.claude/conversations.db ".tables"
+
+# 查看表结构
+sqlite3 ~/.claude/conversations.db ".schema conversations"
+sqlite3 ~/.claude/conversations.db ".schema messages"
+
+# 查看会话数量
+sqlite3 ~/.claude/conversations.db "SELECT COUNT(*) FROM conversations;"
+
+# 导出单个会话为 JSON
+sqlite3 -json ~/.claude/conversations.db \
+  "SELECT m.* FROM messages m JOIN conversations c ON m.conversation_id = c.id WHERE c.title LIKE '%关键词%';"
+```
+
+---
+
+## 🔧 方案三：按项目/目录组织
+
+Claude Code 为每个项目创建独立的数据库：
+
+```bash
+# 查找所有项目数据库
+find ~/.claude -name "*.db" -type f
+
+# 输出示例：
+# ~/.claude/projects/project-uuid-1/conversations.db
+# ~/.claude/projects/project-uuid-2/conversations.db
+```
+
+**按项目导出脚本**：
+
+```python
+import os
+import glob
+
+def export_by_project():
+    db_files = glob.glob(os.path.expanduser("~/.claude/**/conversations.db"), recursive=True)
+    
+    for db_path in db_files:
+        # 从路径提取项目名
+        project_name = db_path.split(os.sep)[-2]  # 倒数第二级是项目 UUID
+        project_dir = os.path.join(OBSIDIAN_PATH, project_name)
+        os.makedirs(project_dir, exist_ok=True)
+        
+        print(f"📁 处理项目: {project_name}")
+        # ... 使用上面的导出逻辑
+```
+
+---
+
+## 📂 Obsidian 目录结构建议
+
+```
+/obsidian/ClaudeCode对话/
+├── _templates/
+│   └── Claude对话模板.md      # Obsidian 模板
+├── 2026-05-04/
+│   ├── 修复API鉴权Bug.md
+│   ├── 编写单元测试.md
+│   └── 重构数据库模块.md
+└── INDEX.md                   # 索引笔记（按日期/项目分类）
+```
+
+---
+
+## ⚠️ 注意事项
+
+1. **隐私安全**：对话可能包含敏感信息（API Key、代码等），导出后注意权限控制
+2. **大文件**：长对话可能生成大文件，Obsidian 打开会慢
+3. **编码问题**：确保以 UTF-8 编码写入
+4. **增量导出**：记录上次导出的时间戳，只导出新对话
+5. **工具调用**：Claude Code 的工具调用（文件读写、Shell 执行）元数据可能需要特殊处理
+
+---
+
+## 🔄 自动同步方案
+
+```bash
+# 加入 cron，每天凌晨自动导出
+0 2 * * * cd /path/to/scripts && python3 claude_to_obsidian.py >> /tmp/claude_export.log 2>&1
+```
+
+---
+
+*研究归档，2026-05-04 | Claude Code 对话导出到 Obsidian 完整指南*

wiki/AI工程/ClaudeCode开发全流程存档方案.md

@@ -0,0 +1,465 @@
+---
+created: 2026-05-04
+type: workflow
+tags: [Claude Code, Git, Obsidian, 开发流程, 存档, 自动化]
+---
+
+# Claude Code 开发全流程存档方案
+
+> 每步提交 Git + 全程存档 Obsidian，打造可追溯的 AI 开发工作流
+> 归档时间：2026-05-04
+
+---
+
+## 📌 目标
+
+1. Claude Code **每完成一个开发步骤**，自动提交 Git
+2. 整个开发过程（对话 + 代码变更 + 决策）**实时存档到 Obsidian**
+3. 形成**可回溯、可搜索、可复盘**的 AI 开发知识库
+
+---
+
+## 🏗️ 整体架构
+
+```
+Claude Code (开发)
+    │
+    ├── 1. 每步完成后 → git commit (自动)
+    │       │
+    │       └── commit message 包含步骤描述
+    │
+    ├── 2. 对话记录 → 导出 Markdown → Obsidian (自动)
+    │       │
+    │       └── 按项目/日期归档
+    │
+    ├── 3. 代码变更 → git diff → 存档笔记 (自动)
+    │       │
+    │       └── 记录"改了什么 + 为什么改"
+    │
+    └── 4. 开发日志 → 每日汇总笔记 → Obsidian (自动)
+            │
+            └── 包含决策、踩坑、复盘
+```
+
+---
+
+## 🔧 工具清单
+
+| 工具 | 用途 | 必选 |
+|------|------|------|
+| **Git** | 代码版本控制 | ✅ |
+| **Claude Code** | AI 编码助手 | ✅ |
+| **Obsidian** | 知识库管理 | ✅ |
+| **obs（obsidian-headless CLI）** | 命令行写 Obsidian 笔记 | ✅ |
+| **pre-commit** | Git 钩子，自动触发存档 | ⚠️ 可选 |
+| **git-changelog** | 生成变更日志 | ⚠️ 可选 |
+| **Claude Code 的 `--output-format json`** | 结构化对话输出 | ✅ |
+
+---
+
+## 📋 实施方案
+
+### 方案一：Claude Code + Git 自动提交（推荐）
+
+#### 1. Claude Code 配置
+
+在项目的 `CLAUDE.md` 中写入指令：
+
+```markdown
+# CLAUDE.md - 项目级 Claude Code 指令
+
+## 开发流程要求
+
+每次完成代码修改后，必须执行以下操作：
+
+1. **git add + commit**：
+   ```bash
+   git add -A
+   git commit -m "[AI-Step] {简短描述}"
+   ```
+
+2. **记录开发日志**：
+   - 用 `obs` 命令写入 Obsidian 开发日志
+   - 格式：`obs obs今天日记 {内容}`
+
+3. **commit message 规范**：
+   - `[AI-Step]` - 普通开发步骤
+   - `[AI-Fix]` - Bug 修复
+   - `[AI-Feature]` - 新功能
+   - `[AI-Refactor]` - 重构
+   - `[AI-Test]` - 测试相关
+
+## 示例
+
+用户：帮我修复这个登录 Bug
+Claude：
+1. 分析问题...
+2. 修改 auth.js...
+3. git add -A && git commit -m "[AI-Fix] 修复登录 token 过期问题"
+4. 记录到开发日志...
+```
+
+#### 2. Git Hook 自动存档
+
+在项目 `.git/hooks/post-commit` 中添加：
+
+```bash
+#!/bin/bash
+# post-commit 钩子：每次 commit 后自动存档到 Obsidian
+
+COMMIT_MSG=$(git log -1 --pretty=%B)
+COMMIT_HASH=$(git log -1 --pretty=%h)
+COMMIT_DATE=$(git log -1 --pretty=%ci)
+CHANGED_FILES=$(git diff-tree --no-commit-id --name-only -r HEAD)
+
+# 获取变更统计
+STATS=$(git diff --stat HEAD~1 HEAD 2>/dev/null || echo "Initial commit")
+
+# 写入 Obsidian 开发日志
+TODAY=$(date +%Y-%m-%d)
+LOG_DIR="/obsidian/开发日志/${TODAY}"
+mkdir -p "$LOG_DIR"
+
+# 追加到今日开发日志
+cat >> "$LOG_DIR/开发日志.md" << EOF
+
+### $(date +%H:%M) - ${COMMIT_MSG}
+
+- **Commit**: \`${COMMIT_HASH}\`
+- **时间**: ${COMMIT_DATE}
+- **变更文件**:
+$(echo "$CHANGED_FILES" | sed 's/^/  - /')
+- **变更统计**:
+\`\`\`
+${STATS}
+\`\`\`
+
+---
+EOF
+
+echo "✅ 已存档到 Obsidian: $LOG_DIR/开发日志.md"
+```
+
+#### 3. 启用 Git Hook
+
+```bash
+cd /path/to/your/project
+chmod +x .git/hooks/post-commit
+```
+
+---
+
+### 方案二：完整对话导出 + 存档
+
+#### 1. Claude Code 对话导出
+
+```bash
+# 方式 A：使用 Claude Code 内置导出
+claude export --output json > /tmp/claude-session.json
+
+# 方式 B：直接从数据库导出
+python3 << 'PYEOF'
+import sqlite3
+import json
+import os
+from datetime import datetime
+
+DB_PATH = os.path.expanduser("~/.claude/conversations.db")
+OBSIDIAN_PATH = "/obsidian/ClaudeCode开发日志/"
+
+conn = sqlite3.connect(DB_PATH)
+conn.row_factory = sqlite3.Row
+
+# 获取最新会话
+cursor = conn.cursor()
+cursor.execute("""
+    SELECT * FROM conversations ORDER BY updated_at DESC LIMIT 1
+""")
+conv = cursor.fetchone()
+
+# 获取消息
+cursor.execute("""
+    SELECT * FROM messages WHERE conversation_id = ? ORDER BY created_at ASC
+""", (conv['id'],))
+messages = cursor.fetchall()
+
+# 生成 Markdown
+today = datetime.now().strftime('%Y-%m-%d')
+filename = f"{today}-{conv['title'] or 'session'}.md"
+filepath = os.path.join(OBSIDIAN_PATH, filename)
+
+os.makedirs(OBSIDIAN_PATH, exist_ok=True)
+
+with open(filepath, 'w', encoding='utf-8') as f:
+    f.write(f"# {conv['title']}\n\n")
+    f.write(f"> 日期：{today}\n\n")
+    f.write("---\n\n")
+    
+    for msg in messages:
+        role = "🤖 Claude" if msg['role'] == 'assistant' else "👤 我"
+        f.write(f"### {role}\n\n")
+        f.write(f"{msg['content']}\n\n")
+        f.write("---\n\n")
+
+print(f"✅ 已导出: {filepath}")
+conn.close()
+PYEOF
+```
+
+#### 2. 用 obs 命令直接写入
+
+```bash
+# 每次开发步骤完成后
+obs obs今天日记 "完成了用户模块开发，git commit: [AI-Feature] 添加用户注册接口"
+
+# 或者创建专题笔记
+obs obs创建笔记 "用户模块开发记录" "
+## 用户需求
+- 支持手机号注册
+- 支持邮箱验证
+- 密码加密存储
+
+## 实现过程
+1. 设计数据库 schema
+2. 编写 API 接口
+3. 添加单元测试
+4. 修复 CORS 问题
+
+## 关键决策
+- 选择 bcrypt 而非 md5 加密
+- 使用 JWT 而非 session
+
+## 踩坑
+- Redis 连接池未关闭导致内存泄漏
+- CORS 配置遗漏
+"
+```
+
+---
+
+### 方案三：Obsidian 插件配合
+
+#### 必装插件
+
+| 插件 | 作用 |
+|------|------|
+| **Templater** | 自动填充开发日志模板 |
+| **Dataview** | 按标签/日期查询开发记录 |
+| **Git** | Obsidian  vault 自动同步 Git |
+| **Calendar** | 日历视图查看每日开发记录 |
+| **QuickAdd** | 快速创建开发笔记 |
+
+#### Templater 模板：开发日志
+
+```markdown
+<%*
+const today = tp.date.now("YYYY-MM-DD");
+const project = await tp.system.prompt("项目名称");
+const task = await tp.system.prompt("本次任务");
+%>
+
+# 开发日志 - <%= today %>
+
+## 项目：<%= project %>
+
+### 任务：<%= task %>
+
+**开始时间**：<% tp.date.now("HH:mm") %>
+**结束时间**：
+
+---
+
+## 开发过程
+
+### 步骤 1：
+
+**Git Commit**：`[AI-Step] `
+
+**变更内容**：
+
+**遇到问题**：
+
+**解决方案**：
+
+---
+
+## 复盘总结
+
+### 做得好的：
+
+### 需要改进的：
+
+### 下次注意：
+
+---
+
+## Git 变更记录
+
+```bash
+git log --oneline --since="<%= today %> 00:00" --until="<%= today %> 23:59"
+```
+
+---
+
+*<% tp.date.now("YYYY-MM-DD HH:mm:ss") %> 记录*
+```
+
+#### Dataview 查询：按项目查看开发记录
+
+```dataview
+TABLE 项目, 任务, file.ctime as "创建时间"
+FROM "开发日志"
+WHERE 项目 != null
+SORT file.ctime DESC
+```
+
+---
+
+## 🔄 完整工作流示例
+
+```
+用户：帮我开发一个用户管理模块
+    ↓
+Claude Code：
+1. 分析需求，创建文件
+2. git add -A && git commit -m "[AI-Step] 初始化用户模块"
+    ↓
+post-commit 钩子触发：
+→ 写入 Obsidian 开发日志
+→ 记录变更文件列表
+    ↓
+Claude Code：
+3. 编写 API 接口
+4. git add -A && git commit -m "[AI-Feature] 添加用户注册/登录 API"
+    ↓
+post-commit 钩子触发：
+→ 追加到 Obsidian 开发日志
+→ 记录 diff 统计
+    ↓
+... 循环直到完成
+
+最终：Obsidian 中有完整的开发过程记录
+      Git 中有每步的代码变更
+```
+
+---
+
+## 📂 Obsidian 目录结构
+
+```
+/obsidian/开发日志/
+├── 2026-05-04/
+│   ├── 开发日志.md              # 当日汇总
+│   ├── 用户模块开发记录.md       # 专题笔记
+│   └── 数据库设计记录.md
+├── 2026-05-05/
+│   └── ...
+└── _templates/
+    └── 开发日志模板.md
+
+/obsidian/ClaudeCode对话/
+├── 2026-05-04-用户模块开发.md
+├── 2026-05-04-Bug修复记录.md
+└── ...
+```
+
+---
+
+## ⚡ 一键初始化脚本
+
+```bash
+#!/bin/bash
+# setup-dev-workflow.sh - 一键配置开发存档工作流
+
+PROJECT_DIR=$1
+if [ -z "$PROJECT_DIR" ]; then
+    echo "用法: ./setup-dev-workflow.sh /path/to/project"
+    exit 1
+fi
+
+cd "$PROJECT_DIR"
+
+# 1. 创建 CLAUDE.md
+cat > CLAUDE.md << 'EOF'
+# 开发流程要求
+- 每完成一个步骤，执行 git add -A && git commit -m "[AI-Step] 描述"
+- 用 obs 命令记录开发日志
+- commit 前缀：[AI-Step] [AI-Fix] [AI-Feature] [AI-Refactor] [AI-Test]
+EOF
+
+# 2. 创建 Git Hook
+mkdir -p .git/hooks
+cat > .git/hooks/post-commit << 'HOOK'
+#!/bin/bash
+COMMIT_MSG=$(git log -1 --pretty=%B)
+COMMIT_HASH=$(git log -1 --pretty=%h)
+CHANGED=$(git diff-tree --no-commit-id --name-only -r HEAD)
+TODAY=$(date +%Y-%m-%d)
+LOG="/obsidian/开发日志/${TODAY}"
+mkdir -p "$LOG"
+echo "### $(date +%H:%M) | \`${COMMIT_HASH}\` | ${COMMIT_MSG}" >> "$LOG/开发日志.md"
+echo "  文件: $(echo $CHANGED | tr '\n' ', ')" >> "$LOG/开发日志.md"
+echo "---" >> "$LOG/开发日志.md"
+HOOK
+chmod +x .git/hooks/post-commit
+
+# 3. 创建 Obsidian 目录
+mkdir -p /obsidian/开发日志/_templates
+mkdir -p /obsidian/ClaudeCode对话
+
+echo "✅ 开发存档工作流已配置！"
+echo "   - CLAUDE.md: $PROJECT_DIR/CLAUDE.md"
+echo "   - Git Hook: $PROJECT_DIR/.git/hooks/post-commit"
+echo "   - Obsidian: /obsidian/开发日志/"
+```
+
+---
+
+## 💡 进阶技巧
+
+### 1. 生成开发报告
+
+```bash
+# 查看某天所有 commit
+git log --oneline --since="2026-05-04" --until="2026-05-05"
+
+# 统计代码变更量
+git log --since="2026-05-04" --pretty=format: --stat | tail -1
+
+# 生成变更日志
+git log --oneline --graph --all > /obsidian/开发日志/变更日志.md
+```
+
+### 2. 自动关联 Git 与 Obsidian
+
+在 Obsidian 笔记中嵌入 Git commit：
+
+```markdown
+## 代码变更
+
+- `[commit:abc1234](https://github.com/user/repo/commit/abc1234)` - 修复登录问题
+- `[commit:def5678](https://github.com/user/repo/commit/def5678)` - 添加单元测试
+```
+
+### 3. 复盘笔记模板
+
+```markdown
+# 项目复盘 - {{项目名}}
+
+## 时间线
+- 开始：{{日期}}
+- 结束：{{日期}}
+- 总 commit 数：`git log --oneline | wc -l`
+
+## 关键决策
+
+## 踩坑记录
+
+## 经验教训
+
+## 可复用代码/模式
+```
+
+---
+
+*研究归档，2026-05-04 | Claude Code 开发全流程存档方案*

wiki/AI工程/ClaudeCode软件开发最佳实践.md

@@ -0,0 +1,101 @@
+# CLAUDE.md — 软件开发最佳实践
+
+> 本文件指导 Claude Code 在此项目中的行为。
+> 创建日期：2026-05-04
+
+## 核心原则
+
+- **先理解，再动手** — 修改前先阅读相关文件，理解上下文
+- **最小改动** — 只改必要的，不要动无关代码
+- **保持风格一致** — 遵循项目现有代码风格
+- **原子化提交** — 每次提交只做一件事
+
+## 开发流程
+
+### 每次修改后必须执行
+
+```bash
+git add -A && git commit -m "[AI] 简短描述做了什么"
+```
+
+提交信息格式：`[AI] 动词+名词`，例如：
+- `[AI] 添加用户登录接口`
+- `[AI] 修复分页参数越界`
+- `[AI] 重构订单计算逻辑`
+
+### 开发步骤
+
+1. **需求确认** — 不清楚时先问，不要假设
+2. **方案设计** — 大改动先写方案（`docs/` 目录下）
+3. **小步实现** — 分步实现，每步可编译、可测试
+4. **自动提交** — 每步完成后自动 git commit
+5. **自检** — 运行 lint/test，确认无报错
+
+## 代码规范
+
+### 通用
+- 变量/函数名用英文，语义清晰
+- 函数不超过 50 行，超过考虑拆分
+- 禁止魔法数字，用常量代替
+- 错误处理必须覆盖，不要吞异常
+
+### TypeScript / JavaScript
+- 优先 `const`，需要改再用 `let`，不用 `var`
+- 使用 async/await，不用回调地狱
+- 接口定义在前，实现在后
+- 使用 ESLint + Prettier，提交前自动格式化
+
+### Python
+- 遵循 PEP 8
+- 类型注解必须（`def func(x: int) -> str:`）
+- 使用 pyproject.toml 管理依赖
+
+### Node.js
+- 错误优先回调或 Promise，统一用 async/await
+- 环境变量用 `.env`，不硬编码
+- 日志用结构化格式（JSON）
+
+## 测试
+
+- 新功能必须写测试
+- 修改后运行相关测试确认通过
+- 测试命名：`describe('xxx', () => { it('should xxx', () => {}) })`
+- 覆盖率不低于 80%
+
+## Git 规范
+
+- **分支命名**：`feat/xxx`、`fix/xxx`、`refactor/xxx`
+- **提交前检查**：
+  ```bash
+  git diff --staged --name-only  # 确认变更范围
+  ```
+- **不要 force push** 除非明确要求
+- **冲突处理**：保留双方代码 + 注释说明，让用户决定
+
+## 文档
+
+- 公共 API 必须有 JSDoc / docstring
+- 复杂逻辑写注释解释 **为什么**，不是 **做了什么**
+- 重大变更更新 `CHANGELOG.md`
+- README 保持更新
+
+## 安全
+
+- **绝不提交密钥、Token、密码**
+- 敏感信息用环境变量或密钥管理工具
+- SQL 参数化，防注入
+- 用户输入必须校验和转义
+
+## 性能
+
+- 数据库查询用索引，避免 N+1
+- 大列表操作考虑分页或流式
+- 缓存热点数据，设置合理过期时间
+- 不要阻塞主线程
+
+## 与 Claude Code 交互
+
+- 完成任务后简洁汇报：做了什么 + 关键变更 + 需要关注的点
+- 遇到不确定的事情直接说，不要编造答案
+- 大文件修改前确认用户意图
+- 遇到编译/测试失败主动排查原因

wiki/AI工程/DBCheck数据库巡检工具研究.md

@@ -0,0 +1,149 @@
+# DBCheck — 开源跨平台数据库巡检工具研究
+
+> 来源: https://mp.weixin.qq.com/s/tR4FpYFnfi6vFmPgoNSUuA
+> 研究日期: 2026-05-05
+
+## 项目概览
+
+- **名称**: DBCheck
+- **GitHub**: https://github.com/fiyo/DBCheck.git
+- **官网**: https://dbcheck.top
+- **许可证**: MIT
+- **定位**: 开源跨平台数据库巡检工具，一键生成专业巡检报告
+
+## 支持的数据库
+
+| 数据库 | 连接资源 | 缓存性能 | 查询效率 | 日志 | 安全 | 集群 |
+|--------|----------|----------|----------|------|------|------|
+| MySQL | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| PostgreSQL | ✅ | ✅ | ✅ | ✅ | ✅ | — |
+| SQL Server | ✅ | ✅ | ✅ | ✅ | ✅ | — |
+| 达梦 DM8 | ✅ | ✅ | ✅ | ✅ | ✅ | — |
+| TiDB | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Oracle | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+## 解决的三大痛点
+
+| 痛点 | 说明 | DBCheck 方案 |
+|------|------|-------------|
+| **重复劳动** | 50 套库 × 20 分钟 = 16 小时 | 一键自动，3 分钟出报告 |
+| **标准不一** | 不同 DBA 巡检质量差异大 | 内置 130+ 标准化规则 |
+| **历史缺失** | 无法判断趋势 | 自动保存快照，趋势折线图 |
+
+## 系统架构
+
+```
+用户交互层
+├── CLI 模式（自动化脚本/CI/CD）
+├── Web UI 模式（Flask + 原生 JS）
+└── 编程接口（Python 模块 import）
+
+核心调度层
+├── checkdb() 总入口
+├── APScheduler 定时调度
+└── SSH 隧道支持
+
+数据库适配层
+├── main_mysql.py
+├── main_pg.py
+├── main_sqlserver.py
+├── main_dm.py（达梦）
+└── main_tidb.py
+
+分析引擎层
+├── analyzer.py（130+ 规则引擎）
+├── slow_query_analyzer.py（慢查询分析）
+└── AI 诊断模块（Ollama 本地）
+
+输出层
+├── Word 报告（python-docx）
+└── Web UI 可视化报告
+```
+
+## 核心功能
+
+### 1. AI 智能诊断
+
+- **本地部署 Ollama**，数据零出站，满足等保合规
+- 建议包含：问题描述 + 可执行 SQL + 操作影响 + 优先级标注
+- **安全约束**：硬编码仅允许 localhost，无法被配置绕过
+
+### 2. 130+ 条标准化检查规则
+
+覆盖维度：
+- 连接资源（连接数使用率、连接堆积）
+- 缓存性能（Buffer Pool 命中率）
+- 查询效率（全表扫描、慢查询）
+- 日志与告警（错误日志、归档日志空间）
+- 安全审计（弱密码、权限过剩）
+- 复制/集群（主从延迟、Region 均衡）
+
+### 3. 历史趋势分析
+
+- 每次巡检快照自动存入 `history.json`（SQLite 版本规划中）
+- Web UI 折线图展示关键指标历史变化
+- 支持任意时间段对比
+
+### 4. 慢查询深度分析
+
+- 解析慢查询日志，提取 Top 20 慢 SQL
+- 执行 EXPLAIN 模拟，识别全表扫描、索引缺失
+- 自动生成建议创建的索引 SQL
+
+### 5. RAG 知识库（进阶功能）
+
+- 支持格式：PDF、Markdown、TXT、HTML
+- 检索增强生成，让 AI 建议更精准
+
+### 6. 定时巡检 + 多渠道告警
+
+- 基于 APScheduler，支持标准 Cron 表达式
+- 企业微信/钉钉/邮件通知
+
+## 快速上手
+
+```bash
+# 方式一：源码运行
+git clone https://github.com/fiyo/DBCheck.git
+cd DBCheck
+pip install -r requirements.txt
+python web_ui.py
+# 访问 http://localhost:5000
+
+# 方式二：下载可执行文件
+# Windows: DBCheck.exe
+# Linux: DBCheck-Linux-x64
+# macOS: DBCheck-macOS-x64
+```
+
+## 技术栈
+
+| 组件 | 技术 |
+|------|------|
+| 后端 | Python + Flask |
+| 报告生成 | python-docx |
+| 定时任务 | APScheduler |
+| AI 诊断 | Ollama（本地 LLM） |
+| 前端 | 原生 JS（无重型框架） |
+| 数据持久化 | history.json → 规划 SQLite |
+
+## 开源理念
+
+- MIT 许可证，商用/修改/分发自由
+- 所有检查 SQL、AI Prompt、报告逻辑全部开源可审计
+- 功能路线图由社区投票决定
+- 参与方式：Star / Issue / PR
+
+## 项目评价
+
+**优点**：
+- ✅ 解决真实痛点，实用性强
+- ✅ 多数据库支持，国产达梦也在列
+- ✅ AI 诊断本地部署，安全合规
+- ✅ 架构清晰，模块化设计
+- ✅ 零重型前端依赖，部署极简
+
+**可改进**：
+- 🔧 历史数据目前用 JSON，建议尽早切 SQLite
+- 🔧 Web UI 较简单，可考虑 Vue3/Element Plus 升级
+- 🔧 可增加更多数据库（MongoDB、Redis 等）

wiki/AI工程/GaussForge高斯格式转换库.md

@@ -0,0 +1,210 @@
+# GaussForge — 高性能 3DGS 格式转换库
+
+> 来源: https://github.com/3dgscloud/GaussForge
+> 在线查看: https://www.3dgsviewers.com/
+> 研究日期: 2026-05-06
+> 协议: Apache-2.0
+
+## 项目概览
+
+- **名称**: GaussForge
+- **作者**: 3dgscloud
+- **定位**: 高性能 3D Gaussian Splatting 格式转换库
+- **核心特点**: 无损转换、多格式支持、C++17 编写
+- **Python**: `pip install gaussforge`
+- **npm**: `npm install @gaussforge/wasm`
+
+## 解决的核心问题
+
+3D 高斯泼溅领域存在**多种互不兼容的格式**：
+- PLY（标准格式，文件大）
+- SPZ（Niantic 压缩格式）
+- SPLAT / KSPLAT（Web 渲染格式）
+- SOG（PlayCanvas 超压缩格式）
+- compressed.ply（压缩 PLY）
+
+GaussForge 提供**无损转换**，统一这些格式。
+
+## 支持的格式
+
+| 格式 | 扩展名 | 读 | 写 | 说明 |
+|------|--------|----|----|------|
+| **PLY** | .ply | ✅ | ✅ | 标准 PLY 格式 |
+| **SPZ** | .spz | ✅ | ✅ | Niantic 压缩格式 |
+| **Compressed PLY** | .compressed.ply | ✅ | ✅ | 压缩 PLY |
+| **SPLAT** | .splat | ✅ | ✅ | Splat 格式 |
+| **KSPLAT** | .ksplat | ✅ | ✅ | K-Splat 格式 |
+| **SOG** | .sog | ✅ | ✅ | PlayCanvas SOG 格式 |
+
+## 核心技术架构
+
+### 统一中间表示（IR）
+
+```
+任意格式 → GaussianCloudIR → 任意格式
+```
+
+所有格式转换都通过统一的中间表示 `GaussianCloudIR`：
+
+| 数据字段 | 说明 |
+|----------|------|
+| **Positions** | 3D 坐标数组 |
+| **Scales** | 对数尺度值 |
+| **Rotations** | 四元数表示的旋转 |
+| **Alphas** | 预 sigmoid 不透明度 |
+| **Colors** | 球谐函数 0 阶（DC）系数 |
+| **SH Coefficients** | 高阶球谐系数 |
+| **Metadata** | 坐标系、单位、颜色空间 |
+
+### 数据验证机制
+
+- 数组大小一致性检查
+- 数据范围合理性验证
+- 格式规范合规性检查
+
+## 三种使用方式
+
+### 1. CLI 命令行工具
+
+```bash
+# PLY 转 SPZ
+./gfconvert input.ply output.spz
+
+# 压缩 PLY 转标准 PLY
+./gfconvert input.compressed.ply output.ply
+
+# 手动指定格式
+./gfconvert input.dat output.dat --in-format ply --out-format spz
+```
+
+### 2. Python SDK
+
+```bash
+pip install gaussforge
+```
+
+```python
+import gaussforge
+
+gf = gaussforge.GaussForge()
+
+# 读取 PLY
+with open("model.ply", "rb") as f:
+    data = f.read()
+
+result = gf.read(data, "ply")
+print(f"Loaded {result['data']['numPoints']} points")
+
+# 格式转换
+converted = gf.convert(data, "ply", "splat")
+with open("output.splat", "wb") as f:
+    f.write(converted["data"])
+```
+
+### 3. WebAssembly（浏览器/Node.js）
+
+```bash
+npm install @gaussforge/wasm
+```
+
+```typescript
+import { createGaussForge } from '@gaussforge/wasm';
+
+const gaussForge = await createGaussForge();
+const converted = await gaussForge.convert(fileData, 'ply', 'spz');
+```
+
+## 技术栈
+
+| 层级 | 技术 |
+|------|------|
+| **核心** | C++17 |
+| **构建** | CMake 3.26+ |
+| **编译器** | GCC 7+ / Clang 5+ / MSVC 2017+ |
+| **Python 绑定** | nanobind |
+| **WASM 绑定** | Emscripten + TypeScript |
+| **依赖** | spz (Niantic) / libwebp / nlohmann_json / zlib |
+
+## 项目结构
+
+```
+GaussForge/
+├── include/gf/
+│   ├── core/        # 核心数据结构（IR、元数据、验证）
+│   └── io/          # I/O 接口和格式实现
+├── src/
+│   ├── core/        # 核心实现
+│   ├── io/          # I/O 实现
+│   ├── cli/         # 命令行工具
+│   └── wasm/        # WebAssembly 绑定
+├── python/          # Python 包（nanobind 绑定）
+├── wasm/            # WASM 包（npm）
+└── cmakes/          # CMake 配置
+```
+
+## 与 SuperSplat 的关系
+
+| 维度 | SuperSplat | GaussForge |
+|------|------------|------------|
+| **定位** | 可视化编辑器 | 格式转换库 |
+| **运行方式** | 浏览器 | CLI / Python / WASM |
+| **功能** | 编辑/优化/发布 | 格式转换/验证 |
+| **语言** | TypeScript | C++17 |
+| **互补性** | 编辑前需要转换格式 | 转换后可用 SuperSplat 编辑 |
+
+**工作流**：`原始数据 → GaussForge 转换 → SuperSplat 编辑 → 发布`
+
+## 在线工具
+
+**3DGS Viewer**: https://www.3dgsviewers.com/
+- 集成 GaussForge 的在线 3DGS 查看器
+- 支持上传 PLY/SPZ/SPLAT/KSPLAT/SOG 格式
+- 可直接在浏览器中查看和导出所有格式
+- 无需安装
+
+## 应用场景
+
+### 1. 3DGS 开发/研究
+- 不同工具输出不同格式，需要统一转换
+- 训练输出 PLY → 转 SPZ/SOG 用于生产
+
+### 2. Web 应用
+- WASM 版本支持浏览器端格式转换
+- 用户上传任意格式，自动转换后渲染
+
+### 3. 自动化管线
+- Python SDK 集成到 CI/CD 流程
+- 批量转换和验证
+
+### 4. 跨平台协作
+- 不同团队使用不同格式
+- GaussForge 作为"翻译层"
+
+## 如何添加新格式
+
+1. 在 `include/gf/io/` 创建新的 reader/writer 头文件
+2. 在 `src/io/` 实现对应读写逻辑
+3. 在 `src/io/registry.cpp` 注册新格式
+
+## 项目评价
+
+**优点**：
+- ✅ 6 种主流格式全覆盖
+- ✅ 无损转换（统一 IR）
+- ✅ 三种使用方式（CLI / Python / WASM）
+- ✅ C++17 高性能实现
+- ✅ 数据验证机制
+- ✅ 零多余依赖
+- ✅ Apache-2.0 开源协议
+
+**局限**：
+- 🔧 纯转换工具，不包含编辑功能
+- 🔧 不涉及 3DGS 训练/生成
+- 🔧 需要配合其他工具使用（编辑器/渲染器）
+
+## 相关链接
+
+- GitHub: https://github.com/3dgscloud/GaussForge
+- 在线查看器: https://www.3dgsviewers.com/
+- Python PyPI: https://pypi.org/project/gaussforge/
+- npm WASM: https://www.npmjs.com/package/@gaussforge/wasm

wiki/AI工程/Lua脚本语言研究.md

@@ -0,0 +1,343 @@
+---
+created: 2026-05-03
+type: language
+tags: [Lua, 脚本语言, 嵌入式, 游戏开发, 配置文件]
+---
+
+# Lua 脚本语言研究
+
+> 轻量级、可嵌入的脚本语言，游戏和嵌入式领域的常青树
+> 归档时间：2026-05-03
+
+---
+
+## 📌 简介
+
+**Lua**（葡萄牙语"月亮"）由巴西 PUC-Rio 大学于 1993 年开发，设计目标是**嵌入到应用程序中**，为其提供灵活的扩展能力。
+
+- 官网：https://www.lua.org
+- 当前版本：Lua 5.4（2020）
+- 许可：MIT License
+- 大小：核心解释器仅 ~300KB
+
+---
+
+## ⭐ 核心特性
+
+| 特性 | 说明 |
+|------|------|
+| **轻量级** | 核心极小，内存占用低 |
+| **可嵌入** | C/C++ API 完善，嵌入成本极低 |
+| **高性能** | JIT 版本 LuaJIT 性能接近 C |
+| **极简设计** | 只有 8 种数据类型，语法精简 |
+| **Table 万能** | 数组、字典、对象、模块全用 table |
+| **协程支持** | 原生协程（coroutine），适合异步/游戏逻辑 |
+
+---
+
+## 🔤 基本语法速览
+
+### 变量与类型
+
+```lua
+-- 8 种类型
+local num = 42          -- number
+local str = "hello"     -- string
+local bool = true       -- boolean
+local nil_val = nil     -- nil
+local tbl = {a=1, b=2}  -- table
+local func = print      -- function
+local thr = coroutine.create(function() end)  -- thread
+local usr = newproxy()  -- userdata
+
+-- 只有 nil 和 false 为假，0 和 "" 都是真！
+```
+
+### Table（核心数据结构）
+
+```lua
+-- 数组
+local arr = {10, 20, 30}
+print(arr[1])  -- Lua 索引从 1 开始！
+
+-- 字典
+local dict = {name = "Lua", version = 5.4}
+print(dict.name)
+
+-- 混合
+local mixed = {
+    x = 1, y = 2,
+    "first", "second"
+}
+
+-- 嵌套（模拟对象）
+local obj = {
+    name = "Player",
+    hp = 100,
+    attack = function(self, target)
+        target.hp = target.hp - 10
+    end
+}
+```
+
+### 控制流
+
+```lua
+-- if
+if score >= 90 then
+    print("A")
+elseif score >= 60 then
+    print("B")
+else
+    print("C")
+end
+
+-- while / repeat
+while i < 10 do
+    i = i + 1
+end
+
+repeat
+    line = io.read()
+until line ~= ""
+
+-- for
+for i = 1, 10 do print(i) end          -- 数值 for
+for i = 10, 1, -1 do print(i) end      -- 递减
+for k, v in pairs(tbl) do print(k, v) end  -- 泛型 for
+```
+
+### 函数
+
+```lua
+-- 基本定义
+function add(a, b)
+    return a + b
+end
+
+-- 匿名函数 / 闭包
+local make_counter = function()
+    local count = 0
+    return function()
+        count = count + 1
+        return count
+    end
+end
+
+-- 多返回值
+function divmod(a, b)
+    return math.floor(a / b), a % b
+end
+local q, r = divmod(17, 5)  -- q=3, r=2
+
+-- 可变参数
+function sum(...)
+    local total = 0
+    for _, v in ipairs({...}) do
+        total = total + v
+    end
+    return total
+end
+```
+
+### 模块
+
+```lua
+-- mylib.lua
+local M = {}
+M.VERSION = "1.0"
+
+function M.greet(name)
+    return "Hello, " .. name
+end
+
+return M
+
+-- 使用
+local mylib = require("mylib")
+print(mylib.greet("World"))
+```
+
+---
+
+## 🔌 嵌入 C/C++
+
+### 最小嵌入示例
+
+```c
+#include <lua.h>
+#include <lauxlib.h>
+#include <lualib.h>
+
+int main() {
+    lua_State *L = luaL_newstate();
+    luaL_openlibs(L);
+    
+    // 执行 Lua 脚本
+    luaL_dostring(L, "print('Hello from Lua!')");
+    
+    // 调用 Lua 函数
+    luaL_dostring(L, "function add(a,b) return a+b end");
+    lua_getglobal(L, "add");
+    lua_pushnumber(L, 3);
+    lua_pushnumber(L, 4);
+    lua_pcall(L, 2, 1, 0);
+    int result = lua_tonumber(L, -1);
+    printf("3 + 4 = %d\n", result);
+    
+    lua_close(L);
+    return 0;
+}
+```
+
+### C 函数暴露给 Lua
+
+```c
+static int l_cwrap(lua_State *L) {
+    double x = luaL_checknumber(L, 1);
+    lua_pushnumber(L, x * x);
+    return 1;  // 返回值数量
+}
+
+// 注册
+lua_pushcfunction(L, l_cwrap);
+lua_setglobal(L, "cwrap");
+
+// Lua 侧使用：print(cwrap(5))  → 25
+```
+
+---
+
+## 🎮 主要应用场景
+
+### 游戏脚本（最大应用领域）
+
+| 游戏/引擎 | 用途 |
+|-----------|------|
+| **World of Warcraft** | UI 插件系统 |
+| **Roblox** | 游戏逻辑（Luau 方言） |
+| **Unity** | 通过 xLua/ToLua 热更新 |
+| **Cocos2d-x** | 脚本层 |
+| **Garry's Mod** | 模组脚本 |
+| **Redis** | 服务器端脚本（EVAL） |
+
+### 配置系统
+
+```lua
+-- config.lua
+return {
+    server = {
+        host = "0.0.0.0",
+        port = 8080,
+        workers = 4
+    },
+    database = {
+        url = "mysql://localhost/mydb",
+        pool_size = 10
+    }
+}
+```
+
+### Nginx/OpenResty
+
+```lua
+-- access_by_lua_block
+access_by_lua_block {
+    local redis = require "resty.redis"
+    local red = redis:new()
+    red:connect("127.0.0.1", 6379)
+    local ok, err = red:auth("password")
+    -- ... 限流/鉴权逻辑
+}
+```
+
+### Redis 脚本
+
+```lua
+-- 原子操作：检查 + 设置
+local key = KEYS[1]
+local val = redis.call('GET', key)
+if val then
+    return tonumber(val) + 1
+else
+    redis.call('SET', key, 1)
+    return 1
+end
+```
+
+---
+
+## ⚡ LuaJIT
+
+**LuaJIT** 是 Lua 的 JIT 编译器，由 Mike Pall 开发：
+
+- 性能：纯 Lua 代码可达 C 的 50%-80%
+- FFI：直接调用 C 库，无需 C 包装层
+- 广泛应用于：OpenResty、Torch、FFmpeg 滤镜等
+
+```lua
+-- LuaJIT FFI 示例
+local ffi = require("ffi")
+ffi.cdef[[
+    int printf(const char *fmt, ...);
+]]
+ffi.C.printf("Hello %s!\n", "World")
+```
+
+---
+
+## 🆚 Lua vs Python/JavaScript
+
+| 维度 | Lua | Python | JavaScript |
+|------|-----|--------|-----------|
+| **嵌入性** | ⭐⭐⭐⭐⭐ 专为嵌入设计 | ⭐⭐ 可嵌入但重 | ⭐⭐⭐ V8 可嵌入 |
+| **体积** | ~300KB | ~30MB | ~5MB (V8) |
+| **索引** | 从 1 开始 | 从 0 开始 | 从 0 开始 |
+| **面向对象** | 基于 prototype | 基于 class | 基于 prototype |
+| **生态** | 小而精 | 大而全 | 大而全 |
+| **适合场景** | 嵌入/脚本/配置 | 通用/数据/AI | Web/全栈 |
+
+---
+
+## 💡 优缺点
+
+### 优势
+- ✅ 嵌入成本极低，C API 设计优雅
+- ✅ 语法精简，学习曲线平缓
+- ✅ 协程原生支持，游戏逻辑编写方便
+- ✅ Table 一统天下，数据结构灵活
+- ✅ LuaJIT 性能出色
+
+### 劣势
+- ❌ 标准库极小（没有正则、网络、文件系统）
+- ❌ 索引从 1 开始，C 程序员易混淆
+- ❌ 错误信息有时不够友好
+- ❌ 缺乏包管理（luarocks 生态较小）
+- ❌ 无内置调试器
+
+---
+
+## 🔧 工具链
+
+| 工具 | 用途 |
+|------|------|
+| **lua** | 官方解释器 |
+| **luajit** | JIT 编译器 |
+| **luarocks** | 包管理器 |
+| **stylua** | 代码格式化工具 |
+| **teal** | Lua 类型系统 |
+| **selene** | Lint 工具 |
+| **xLua/ToLua** | Unity 热更新框架 |
+
+---
+
+## 📚 学习资源
+
+- 官方手册：https://www.lua.org/manual/5.4/
+- 《Programming in Lua》（PiL）：官方教程
+- Lua 5.3/5.4 中文版
+- 实战：Redis EVAL、OpenResty、WoW 插件
+
+---
+
+*研究归档，2026-05-03 | Lua 语言核心技术梳理*

wiki/AI工程/OpenDesign_Kami设计系统.md

@@ -0,0 +1,165 @@
+---
+created: 2026-05-03
+type: project
+tags: [AI设计, Open Design, Kami, Claude Design, 开源, 设计系统]
+source: https://mp.weixin.qq.com/s/MpjANCg5eO4TSxNUDrpRpQ
+author: jackao（恶人笔记）
+---
+
+# Open Design + Kami 设计系统
+
+> Claude Design 的开源替代品，集成 Kami 设计系统，实现杂志级 AI 设计
+> 归档时间：2026-05-03
+
+---
+
+## 📌 概述
+
+**Open Design** 是 Anthropic Claude Design 的**本地优先、完全开源替代品**，是一个 **Agent 驱动的设计生成平台**。
+
+最新更新：正式集成 **Kami 设计系统**，让生成内容拥有"专业杂志/书籍"的纸质质感。
+
+---
+
+## 🔧 Open Design 核心能力
+
+### 支持 11+ 种 Coding Agent
+
+| Agent                              | 推荐度       |
+| ---------------------------------- | --------- |
+| Claude Code                        | ⭐⭐⭐⭐⭐（最强） |
+| Codex / Cursor / Hermes / Kimi CLI | ⭐⭐⭐⭐      |
+| BYOK 代理（任意 OpenAI 兼容模型）            | ⭐⭐⭐       |
+
+### 支持内容
+
+- Web / 移动 / 桌面原型
+- Pitch Deck（演示文稿）
+- 简历 / 作品集 / 信函
+- 杂志海报
+- 短视频与 HyperFrames
+
+### 设计系统库
+
+- **72 个品牌级 DESIGN.md**：Linear、Stripe、Vercel、Apple、Notion、小红书、Tesla 等
+- **31 个可组合 Skill**：magazine-poster、guizang-ppt 等
+
+### 独特机制
+
+| 机制 | 作用 |
+|------|------|
+| 沙盒预览 | 实时 iframe 预览生成效果 |
+| 实时 Todo 流 | 追踪 Agent 生成进度 |
+| 强制问题表单 | 确保明确设计意图 |
+| 五维自评 | Agent 自我质量评估 |
+| 反 Slop 黑名单 | 禁止紫色渐变、emoji 滥用、Inter 做标题等 |
+
+### 导出格式
+
+HTML / PDF / PPTX / ZIP / Markdown，一键专业输出。
+
+---
+
+## 🎨 Kami 设计系统
+
+### 基本信息
+
+- **作者**：@HiTw93（Tw93）
+- **理念**：Good content deserves good paper
+- **定位**：严格约束的**印刷品设计系统**，非传统 UI 组件库
+
+### 视觉规范
+
+| 属性 | 值 | 说明 |
+|------|-----|------|
+| 背景色 | `#f5f4ed` | 温暖羊皮纸色，非纯白 |
+| 强调色 | `#1B365D` | 墨蓝，唯一强调色 |
+| 英文字体 | Charter | 经典衬线体 |
+| 中文字体 | 仓耳金楷（TsangerJinKai02） | 个人免费，商用需授权 |
+| 日文字体 | YuMincho | - |
+
+### 排版哲学
+
+- 极简阴影：仅 whisper / ring 两种
+- 紧凑标题行高：1.1-1.3
+- 舒适正文行高：1.5-1.55
+- **绝对禁止"AI 味"装饰**
+
+### 支持文档类型
+
+One-Pager / Long Doc / Letter / Portfolio / Resume / Slides（含 WeasyPrint 优化模板）
+
+Open Design 集成后额外提供 `kami-deck.html` 模板，专为横版杂志风 Pitch Deck 优化。
+
+---
+
+## 🚀 上手指南
+
+### 环境准备
+
+- Node.js ≈ 24（推荐 nvm/fnm 管理）
+- pnpm 10.33.x（`corepack enable` 后自动）
+- 至少一个 Agent CLI
+
+### 一键安装
+
+```bash
+git clone https://github.com/nexu-io/open-design.git
+cd open-design
+pnpm install
+pnpm tools-dev run web
+```
+
+首次运行会自动创建 `.od/` 文件夹（SQLite 数据库 + 项目工作区）。
+
+### 日常生成流程
+
+1. 选择 **Skill**（magazine-poster / guizang-ppt 等）
+2. 选择 **Design System** → 搜索选中 **Kami**
+3. 输入自然语言 Prompt
+4. 填写 **Discovery Form**（必须：表面、受众、语气、品牌背景、规模、约束）
+5. 选择视觉方向（或直接用 Kami 预设）
+6. Agent 实时输出 → 沙盒预览
+7. 满意后一键导出
+
+### Kami 独立使用（不走 Open Design）
+
+```bash
+npx skills add tw93/kami -a claude-code -g -y
+```
+
+然后在 Claude Code 里直接说"用 Kami 风格做一份作品集"即可。
+
+---
+
+## 📊 评价
+
+### 优势
+
+- ✅ 质量领先：Kami 约束 + 反 Slop 流程 = 稳定专业印刷品水准
+- ✅ 本地优先 + 开源：数据不上传、完全可审计
+- ✅ 生态成型：72 设计系统 + 31 Skill，覆盖 95% 日常需求
+- ✅ 成本可控：用开源模型就能跑，导出无水印
+
+### 不足
+
+- ⚠️ 上手门槛中等：Node + pnpm + Agent CLI 配置（15-30 分钟）
+- ⚠️ 依赖底层模型能力：弱模型容易"翻车"
+- ⚠️ 中文字体商用需注意仓耳金楷授权
+- ⚠️ 复杂长文档仍需人工二审
+
+### 建议
+
+- **每天用 AI 写东西/做演示/发作品集** → 值得装
+- **偶尔用一次或零技术背景** → 等桌面版或教程
+
+---
+
+## 🔗 相关链接
+
+- Open Design：https://github.com/nexu-io/open-design
+- Kami：https://github.com/tw93/kami
+
+---
+
+*研究归档，2026-05-03 | 基于"恶人笔记"公众号文章整理*

wiki/AI工程/SkillHub科大讯飞智能体技能注册中心.md

@@ -0,0 +1,125 @@
+# SkillHub — 科大讯飞开源智能体技能注册中心
+
+> 来源: https://mp.weixin.qq.com/s/989DJSRSihmEs6JSbLGnkw
+> 研究日期: 2026-05-05
+> 协议: Apache-2.0
+
+## 项目概览
+
+- **名称**: SkillHub
+- **GitHub**: https://github.com/iflytek/skillhub
+- **作者**: 科大讯飞（iFlytek）
+- **定位**: 企业级开源智能体技能注册中心
+- **口号**: 在组织内发布、发现和管理可复用的技能包
+
+## 解决的核心问题
+
+| 痛点       | SkillHub 方案          |
+| -------- | -------------------- |
+| **版本混乱** | 语义化版本控制，自动 latest 跟踪 |
+| **权限失控** | 企业级 RBAC + 审核机制      |
+| **发现困难** | 全文搜索 + 评分/下载量筛选      |
+| **分发低效** | CLI 一键安装，类似 npm 体验   |
+|          |                      |
+
+## 核心功能
+
+| 功能           | 说明                                |
+| ------------ | --------------------------------- |
+| **Skill 发布** | 一键上传技能包，自动版本管理/元数据提取              |
+| **自托管私有化**   | 部署在自有基础设施，数据不出防火墙                 |
+| **团队命名空间**   | 按团队/全局组织技能，独立成员/角色管理              |
+| **审核与治理**    | 团队管理员审核，平台管理员控制推广，审计日志            |
+| **发现与搜索**    | 全文搜索，支持按命名空间/下载量/评分/时间筛选          |
+| **社交功能**     | 收藏、评分、下载量跟踪                       |
+| **账户合并**     | 多个 OAuth 身份 + API 令牌整合到单账户        |
+| **CLI 优先**   | 原生 REST API + ClawHub 风格注册中心客户端兼容 |
+
+## 技术栈
+
+| 层级 | 技术 | 说明 |
+|------|------|------|
+| **前端** | React 19 + TypeScript + Vite + shadcn/ui | SPA，支持 i18next 国际化 |
+| **后端** | Java 21 + Spring Boot 3.2 + Spring Security | 模块化 REST API |
+| **数据库** | PostgreSQL 16 + Flyway | 主数据存储 + 全文搜索 |
+| **缓存** | Redis 7 | 会话管理 + 分布式锁 + 限流 |
+| **对象存储** | 本地文件系统 / S3 / MinIO | 技能包文件存储 |
+| **安全** | Spring Security OAuth2 + RBAC + API 令牌 | 认证授权 |
+| **扫描器** | Python 服务 | 上传技能包多引擎安全分析 |
+| **部署** | Docker Compose + Kubernetes | 容器编排 |
+
+## 项目结构
+
+```
+skillhub/
+├── server/
+│   ├── skillhub-app/        # 入口点、控制器
+│   ├── skillhub-domain/     # 核心实体、领域服务
+│   ├── skillhub-auth/       # OAuth2、RBAC、API 令牌
+│   ├── skillhub-search/     # 搜索 SPI + PostgreSQL 全文检索
+│   ├── skillhub-storage/    # 对象存储 SPI
+│   ├── skillhub-infra/      # JPA 仓库、事件
+│   └── skillhub-notification/ # 邮件与告警
+├── web/                     # React 19 前端
+│   └── src/
+│       ├── pages/           # 路由级页面
+│       ├── features/        # 业务功能模块
+│       ├── shared/          # 可复用组件
+│       └── api/             # OpenAPI 生成类型
+├── scanner/                 # Python 安全扫描器
+├── deploy/                  # Kubernetes 清单
+├── monitoring/              # Prometheus / Grafana
+└── docker-compose.yml       # 开发依赖
+```
+
+## 快速启动
+
+```bash
+git clone https://github.com/iflytek/skillhub.git
+cd skillhub
+make dev-all   # 启动完整开发栈
+# 或分别启动
+make dev-backend  # 仅后端
+make dev-web      # 仅前端
+```
+
+**前置要求**: Java 21+ / Node.js 20+ / Docker
+
+## 架构亮点
+
+### 治理模型
+
+```
+开发者 → 发布技能到命名空间 → 团队管理员审核 → 推广到全局
+```
+
+- 每个命名空间独立管理（Owner/Admin/Member 角色）
+- 所有治理操作记录审计日志
+- 可见性规则确保用户只能看到有权访问的技能
+
+### 安全设计
+
+- **API 令牌**: 基于前缀的安全哈希，作用域控制
+- **CSRF 防护**: 前端请求保护
+- **多引擎扫描**: 上传技能包自动安全分析
+- **数据主权**: 完全自托管，专有技能保留在防火墙后
+
+## 与 OpenClaw/ClawHub 的关系
+
+- SkillHub 兼容 **ClawHub 风格注册中心客户端**
+- 可作为 OpenClaw 技能的**企业级私有注册中心**
+- 提供与公共注册中心相同的体验，但完全可控
+
+## 项目评价
+
+**优点**：
+- ✅ 科大讯飞出品，企业级品质
+- ✅ 完整治理模型（审核/权限/审计）
+- ✅ 技术栈现代（React 19 / Java 21 / PG 16）
+- ✅ 自托管，数据完全可控
+- ✅ Apache-2.0 协议，商用友好
+
+**适用场景**：
+- 企业内部 Agent 技能共享平台
+- 团队私有技能注册中心
+- 需要权限控制的技能分发场景

wiki/AI工程/SuperSplat高斯泼溅编辑器.md

@@ -0,0 +1,133 @@
+# SuperSplat — PlayCanvas 3D 高斯泼溅编辑器
+
+> 来源: https://github.com/playcanvas/supersplat
+> 在线体验: https://superspl.at/editor
+> 研究日期: 2026-05-06
+> 协议: MIT（推测，PlayCanvas 通常 MIT）
+
+## 项目概览
+
+- **名称**: SuperSplat
+- **作者**: PlayCanvas
+- **定位**: 免费开源的 3D Gaussian Splat（高斯泼溅）编辑器
+- **运行方式**: 纯浏览器运行，无需下载安装
+- **官网**: https://superspl.at/editor
+- **用户指南**: https://developer.playcanvas.com/user-manual/gaussian-splatting/editing/supersplat/
+
+## 什么是 3D Gaussian Splatting？
+
+3D 高斯泼溅是一种**从照片重建 3D 场景**的技术：
+- 通过多张照片扫描真实环境
+- 生成"云"状的高斯体（oriented blobs）
+- 能实现**照片级真实感**的 3D 场景渲染
+- 但原始 splat 没有三角面、碰撞体、导航网格、光照
+
+## SuperSplat 核心功能
+
+| 功能 | 说明 |
+|------|------|
+| **检查/浏览** | 在浏览器中查看 3D 高斯场景 |
+| **编辑** | 裁剪、删除、优化高斯体 |
+| **优化** | 压缩、减少高斯体数量 |
+| **发布** | 分享和发布编辑后的 splat |
+| **Walk Mode** | 第一人称视角漫步场景 |
+| **Streamed LOD** | 流式加载不同细节层级 |
+| **Studio 模式** | 添加标注、电影级后期效果 |
+| **社交功能** | 用户主页、收藏、下载 |
+
+## 技术栈
+
+| 层级 | 技术 |
+|------|------|
+| **运行环境** | 浏览器（WebGL/WebGPU） |
+| **开发环境** | Node.js 18+ |
+| **构建工具** | npm |
+| **国际化** | i18next，支持多语言 |
+| **本地开发** | `npm run develop` → http://localhost:3000 |
+
+## 快速启动
+
+```bash
+git clone https://github.com/playcanvas/supersplat.git
+cd supersplat
+npm install
+npm run develop
+# 浏览器打开 http://localhost:3000
+```
+
+## PlayCanvas 高斯生态工具链
+
+| 工具 | 类型 | 用途 |
+|------|------|------|
+| **SuperSplat** | 在线编辑器 | 可视化编辑 3DGS |
+| **SplatTransform** | CLI 工具 | 命令行转换/优化 splat |
+| **SOG 格式** | 压缩格式 | "高斯泼溅的 WebP"，超压缩 |
+| **PlayCanvas Engine** | 游戏引擎 | 在浏览器中运行 3DGS 游戏 |
+
+## SOG 格式（Spatially Ordered Gaussians）
+
+- PlayCanvas 开源的 3DGS 压缩格式
+- 被称为"高斯泼溅的 WebP"
+- 比 SOGS 格式更进一步的压缩
+- 支持高效流式加载
+
+## 应用场景
+
+### 1. 房地产/建筑可视化
+- 扫描真实建筑，生成照片级 3D 场景
+- 客户可以"走进"未建成的房子
+
+### 2. 电商产品展示
+- 用照片扫描产品，360° 展示
+- 比传统 3D 建模成本低
+
+### 3. 游戏/VR
+- 快速创建真实感游戏场景
+- 结合 PlayCanvas 引擎，可在浏览器运行 FPS 游戏
+
+### 4. 文化遗产保护
+- 扫描历史建筑/遗址
+- 永久保存数字副本
+
+### 5. 影视/虚拟制作
+- 快速创建虚拟场景
+- 替代传统绿幕拍摄
+
+## 最新进展（2026）
+
+| 日期      | 更新                                     |
+| ------- | -------------------------------------- |
+| 2026-04 | Walk Mode + Streamed LOD + Easy Upload |
+| 2026-04 | 可下载 Splats + 许可证 + 社交链接                |
+| 2026-04 | 将高斯场景变成可玩游戏（FPS demo）                  |
+| 2026-03 | SuperSplat Studio 发布                   |
+| 2026-02 | Studio 支持标注 + 电影后期效果                   |
+| 2025-09 | SOG 压缩格式开源                             |
+| 2025-07 | SplatTransform CLI 工具发布                |
+
+## 项目评价
+
+**优点**：
+- ✅ 纯浏览器运行，零安装
+- ✅ PlayCanvas 大厂支持，持续迭代
+- ✅ 完整工具链（编辑器 + CLI + 压缩格式 + 引擎）
+- ✅ 开源，可自托管
+- ✅ 活跃的社区和文档
+
+**局限**：
+- 🔧 浏览器性能限制，超大场景可能卡顿
+- 🔧 编辑功能相比桌面专业工具仍有差距
+- 🔧 原始 splat 缺少碰撞体等游戏元素（需手动添加）
+
+## 与 AI 的结合
+
+- **Voxelo.ai**: AI 驱动的 3DGS 产品可视化
+- 未来趋势：AI 自动生成 splat + SuperSplat 编辑优化
+
+## 相关链接
+
+- GitHub: https://github.com/playcanvas/supersplat
+- 在线编辑器: https://superspl.at/editor
+- 用户指南: https://developer.playcanvas.com/user-manual/gaussian-splatting/editing/supersplat/
+- 博客: https://blog.playcanvas.com
+- Discord: https://discord.gg/RSaMRzg

wiki/AI工程/WeWrite公众号AI写作Skill研究.md

@@ -0,0 +1,142 @@
+# WeWrite — 公众号文章全流程 AI Skill
+
+> 来源: https://github.com/oaker-io/wewrite
+> 研究日期: 2026-05-04
+
+## 项目定位
+
+**一句话搞定公众号文章**：从热点抓取 → 选题 → 写作 → SEO → 视觉 AI → 排版 → 微信草稿箱推送
+
+兼容 **Claude Code** 和 **OpenClaw** 的 skill 格式。
+
+## 核心能力
+
+| 能力 | 实现 |
+|------|------|
+| 热点抓取 | 微博 + 头条 + 百度实时热搜（`fetch_hotspots.py`） |
+| SEO 评分 | 百度 + 360 搜索量化评分（`seo_keywords.py`） |
+| 选题生成 | 10 选题 × 3 维度评分 + 历史去重 |
+| 素材采集 | WebSearch 真实数据/引述/案例（不编造） |
+| 框架生成 | 7 套写作骨架（痛点/故事/清单/对比/热点解读/纯观点/复盘） |
+| 内容增强 | 按框架类型自动匹配策略 |
+| 文章写作 | 真实信息锚定 + 风格注入 + 编辑锚点 |
+| SEO 优化 | 标题策略/摘要/关键词/标签 |
+| AI 配图 | 封面 3 创意 + 内文 3-6 配图（9 provider 自动 fallback） |
+| 排版发布 | 16+ 主题 + 微信兼容修复 + 暗黑模式 |
+| 效果复盘 | 微信数据分析 API 回填 |
+| 风格飞轮 | 学习用户修改，越用越像用户 |
+| 范文风格库 | SICO 式 few-shot，从已发布文章提取风格指纹 |
+
+## 5 套写作人格（Writing Persona）
+
+| 人格 | 适合 | 风格 |
+|------|------|------|
+| midnight-friend | 个人号/自媒体 | 极度口语化、高自我怀疑、第一人称 |
+| warm-editor | 生活/文化/情感 | 温暖叙事、故事嵌套数据 |
+| industry-observer | 行业媒体/分析 | 中性分析、数据先行、稳中带刺 |
+| sharp-journalist | 新闻/评论 | 犀利简洁、数据驱动、强观点 |
+| cold-analyst | 财经/投研 | 冷静克制、逻辑链条、风险意识强 |
+
+## 16+ 排版主题
+
+| 类别 | 主题 |
+|------|------|
+| 通用 | professional-clean（默认）、minimal、newspaper |
+| 科技 | tech-modern、bytedance、github |
+| 文艺 | warm-editorial、sspai、ink、elegant-rose |
+| 商务 | bold-navy、minimal-gold、bold-green |
+| 风格 | bauhaus、focus-red、midnight |
+
+全部支持微信暗黑模式。
+
+## 微信自动修复
+
+| 问题 | 自动修复 |
+|------|----------|
+| 外链被屏蔽 | 转上标编号脚注 + 文末参考链接 |
+| 中英混排无间距 | CJK-Latin 自动加空格 |
+| 加粗标点渲染异常 | 标点移到 `</strong>` 外 |
+| 原生列表不稳定 | `<ul>/<ol>` 转样式化 `<section>` |
+| 暗黑模式颜色反转 | 注入 `data-darkmode-*` 属性 |
+| `<style>` 被剥离 | 所有 CSS 内联注入 |
+
+## 安装
+
+### OpenClaw
+```bash
+git clone --depth 1 https://github.com/oaker-io/wewrite.git ~/.openclaw/skills/wewrite
+cd ~/.openclaw/skills/wewrite && pip install -r requirements.txt
+cp config.example.yaml config.yaml
+```
+
+### Claude Code
+```bash
+git clone --depth 1 https://github.com/oaker-io/wewrite.git ~/.claude/skills/wewrite
+cd ~/.claude/skills/wewrite && pip install -r requirements.txt
+```
+
+## 配置
+
+```yaml
+# config.yaml
+# 微信公众号 appid/secret（推送需要）
+# 图片 API key（生图需要）
+# 不配也能用——自动降级为本地 HTML + 输出图片提示词
+```
+
+## 使用方式
+
+```
+你：写一篇公众号文章
+你：写一篇关于 AI Agent 的公众号文章
+你：交互模式，写一篇关于效率工具的推文
+你：帮我润色一下刚才那篇
+你：学习我的修改 → 飞轮学习
+你：看看有什么主题 → 主题画廊
+你：换成 sspai 主题 → 切换主题
+你：检查一下 → 生成报告 + 质量自检
+你：导入范文 → 建立风格库
+```
+
+## 目录结构
+
+```
+wewrite/
+├── SKILL.md              # 主管道（Step 1-8）
+├── config.example.yaml   # API 配置模板
+├── style.example.yaml    # 风格配置模板
+├── scripts/              # 数据采集 + 诊断 + 构建
+│   ├── fetch_hotspots.py # 多平台热点抓取
+│   ├── seo_keywords.py   # SEO 关键词分析
+│   ├── humanness_score.py # 文章质量打分（11项检测）
+│   ├── extract_exemplar.py # 范文风格提取
+│   ├── learn_theme.py    # 从公众号文章 URL 提取排版主题
+│   └── fetch_article.py  # 从公众号 URL 提取正文为 Markdown
+├── toolkit/              # Markdown → 微信工具链
+│   ├── cli.py            # CLI（preview / publish / gallery）
+│   ├── converter.py      # Markdown → 内联样式 HTML
+│   ├── publisher.py      # 微信草稿箱 API + 小绿书图片帖
+│   ├── image_gen.py      # AI 图片生成（9 provider）
+│   └── themes/           # 16+ 排版主题
+├── personas/             # 5 套写作人格预设
+├── references/           # Agent 按需加载的参考文档
+└── output/               # 生成的文章
+```
+
+## 与 OpenClaw 的关系
+
+- 兼容 OpenClaw skill 格式，有专门的 `dist/openclaw/` 构建
+- 可安装到 `~/.openclaw/skills/wewrite`
+- 需要配置微信公众号 appid/secret（我们已有：`wxdbcccdac8e7c97be`）
+- 图片 API 可用百炼 qwen-image-2.0
+
+## 核心设计理念
+
+**不是"骗过 AI 检测"，而是写出值得读的文章**：
+1. 内容增强 — 按框架类型自动执行不同策略
+2. 素材采集 — 真实数据锚定，不编造
+3. 编辑锚点 — 在 2-3 个关键位置标记"在这里加一句你自己的话"
+4. 学习飞轮 — 每次编辑后学习，下次更接近用户风格
+5. 范文风格库 — 导入已发布文章，写作时注入风格指纹
+
+## MIT 许可证

wiki/AI工程/everything-claude-code研究.md

@@ -0,0 +1,118 @@
+# everything-claude-code (ECC) 研究
+
+> 来源: https://github.com/affaan-m/everything-claude-code
+> 研究日期: 2026-05-04
+
+## 项目概览
+
+- **140K+ stars, 21K+ forks, 170+ contributors**
+- Anthropic Hackathon 获奖项目
+- 当前版本: **v2.0.0-rc.1**
+- 定位: **AI Agent Harness 性能优化系统**（不只是配置文件）
+
+## 核心能力
+
+| 能力 | 说明 |
+|------|------|
+| Token 优化 | 模型选择、系统提示瘦身、后台进程管理 |
+| 记忆持久化 | Hooks 自动跨会话保存/加载上下文 |
+| 持续学习 | 自动从会话中提取模式生成可复用技能 |
+| 验证循环 | Checkpoint vs 持续评估、grader 类型、pass@k 指标 |
+| 并行化 | Git worktrees、级联方法、实例扩展 |
+| 子代理编排 | 上下文问题管理、迭代检索模式 |
+
+## 支持的 Agent Harness
+
+Claude Code, Codex, Cursor, OpenCode, Gemini 等
+
+## 规模
+
+- **48 个 agents**（覆盖 10+ 编程语言）
+- **182 个 skills**
+- **68 个 legacy command shims**
+- **12 种语言生态**（TypeScript, Python, Go, Java, PHP, Perl, Kotlin/Android/KMP, C++, Rust 等）
+
+## 安装方式
+
+### 1. Claude Code 插件（推荐）
+```bash
+/plugin marketplace add https://github.com/affaan-m/everything-claude-code
+/plugin install everything-claude-code@everything-claude-code
+```
+
+### 2. 手动安装
+```bash
+# 最小配置（不含 hooks）
+./install.sh --profile minimal --target claude
+
+# 核心配置（不含 hooks）
+./install.sh --profile core --without baseline:hooks --target claude
+
+# 完整版
+./install.sh --profile full
+```
+
+### 3. npm
+```bash
+npx ecc-install --profile minimal --target claude
+```
+
+### 4. 咨询工具
+```bash
+npx ecc consult "security reviews" --target claude
+```
+
+## 关键架构
+
+### 三个公共标识（不可互换）
+- GitHub 源码: `affaan-m/everything-claude-code`
+- Claude 插件: `everything-claude-code@everything-claude-code`
+- npm 包: `ecc-universal`
+
+### Hook 运行时控制
+```bash
+ECC_HOOK_PROFILE=minimal|standard|strict
+ECC_DISABLED_HOOKS=...
+```
+
+### 新增 Harness 命令
+- `/harness-audit` — 审计评分
+- `/loop-start` — 启动循环
+- `/loop-status` — 循环状态
+- `/quality-gate` — 质量门禁
+- `/model-route` — 模型路由
+
+## ECC 2.0 特性（alpha）
+
+- Rust 控制平面原型 (`ecc2/`)
+- 新增命令: dashboard, start, sessions, status, stop, resume, daemon
+- Dashboard GUI (Tkinter)
+- SQLite 状态存储 + 查询 CLI
+- Session adapters 结构化记录
+- Skill evolution 自改进基础
+
+## 安全
+
+- **AgentShield 集成**: `/security-scan` 技能
+- 1282 个测试，102 条规则
+- GitHub Marketplace: `github.com/marketplace/ecc-tools`
+
+## 与 OpenClaw 的关联
+
+ECC 的很多理念与 OpenClaw 的 AGENTS.md / SOUL.md / 技能系统类似：
+- **Skills 系统** → OpenClaw 的 skills/ 目录
+- **Instincts** → 类似 SOUL.md 的个性定义
+- **Hooks** → 类似 OpenClaw 的 cron/heartbeat 机制
+- **Agents** → 类似 OpenClaw 的 sub-agent 编排
+
+## 注意事项
+
+⚠️ **不要叠加安装方式** — 最常见错误：先 `/plugin install`，再跑 `./install.sh --profile full`，会导致重复技能/运行时。
+
+⚠️ **插件无法自动分发 rules** — 安装插件后仍需手动复制规则文件夹。
+
+## 相关项目
+
+- **NanoClaw v2** — 模型路由、技能热加载、会话分支/搜索/导出/压缩/指标
+- **AgentShield** — 安全扫描工具
+- **ECC Tools** — GitHub App（免费/专业/企业版）

wiki/AI工程/元模型驱动AI技术方案写作.md

@@ -0,0 +1,178 @@
+---
+created: 2026-05-03
+type: methodology
+tags: [AI写作, 元模型, 技术方案, 投标, 约束驱动, RAG, 文档生成]
+source: https://mp.weixin.qq.com/s/Po42W8VuLy1KvwbDzCdXdA
+author: 人月聊IT
+---
+
+# 元模型驱动的 AI 技术方案写作
+
+> 结构约束优先于内容生成，来源追溯优先于流畅表达
+> 归档时间：2026-05-03
+
+---
+
+## 📌 传统 AI 辅助写作的三大困境
+
+| 问题 | 表现 | 根源 |
+|------|------|------|
+| **知识点孤立** | RAG 检索局部片段，忽略文档内部的隐性约束网络 | 片段间约束关系丢失 |
+| **需求无映射** | AI 不知道哪段对应哪个评分点 | 没有需求→内容映射机制 |
+| **缺乏约束** | AI"合理推断"编造数据、虚构案例 | 无结构化约束框架 |
+
+**核心结论**：AI 写作缺乏结构化的约束框架，导致结果不可控。
+
+---
+
+## 🏗️ 文档元模型三层架构
+
+### Layer 1：原子要素层（最小可复用单元）
+
+**判定标准**：独立性 + 可复用性 + 参数化可能性
+
+**7 类原子要素**：
+
+| 类别 | 名称 | 示例 |
+|------|------|------|
+| A | 背景叙述类 | 政策背景、行业痛点 |
+| B | 技术能力类 | 产品功能、能力清单 |
+| C | 架构方案类 | 架构图说明、部署方案 |
+| D | 实施方法类 | 实施流程、风险策略 |
+| E | 资源配置类 | 硬件测算、软件清单 |
+| F | 案例数据类 | 客户案例、实施成果 |
+| G | 合规声明类 | 技术偏离、服务承诺 |
+
+每个要素包含：唯一 ID、内容摘要、知识库来源、参数化变量、可复用性评分（1-5 分）。
+
+**示例**：`B-004`：API 网关认证插件能力描述
+- 来源：历史建议书 → 4.2 API 网关引擎
+- 复用性：5 分
+- 参数化：`{{AUTH_METHODS}}`
+
+### Layer 2：组合块层（章节填充模板）
+
+多个原子要素按逻辑组合成章节模板，每个组合块包含：
+- 适用章节
+- 要素组合逻辑
+- 写作要点
+- 外部约束映射（对应哪些评分点）
+
+**示例**：Block-04 实施方法论模块 = D-001~D-006 六个步骤要素
+
+### Layer 3：框架层（文档骨架 + 约束图谱）
+
+**章节骨架属性**：
+- 必要性分级：★★★（必须）/ ★★（建议）/ ★（可选）
+- 核心定位、输入依赖、输出约束、关联组合块
+
+**约束图谱**（核心价值）：
+
+| 约束 ID | 类型 | 规则 |
+|---------|------|------|
+| C-HR-01 | [H] 硬约束 | 组织架构每个岗位必须有具名人员 |
+| C-TP-01 | [H] | 实施计划工期 ≤ 招标文件周期 |
+| C-RF-01 | [H] | 功能方案 100% 覆盖需求分析列举的功能 |
+| C-AF-01 | [H] | 产品架构组件必须在功能方案中有展开 |
+| C-HW-01 | [H] | 硬件配置存储容量 ≥ 资源测算需求量 |
+
+约束分级：硬约束[H] / 软约束[S] / 建议约束[R]
+
+---
+
+## 📋 七阶段工作流
+
+### 阶段一：输入解析
+
+**输出四张表**：
+1. 评分点提取表（评分 ID + 描述 + 分值 + 满分条件）
+2. SOW 建设内容提取表（交付范围 + 优先级）
+3. 项目变量提取表（`{{变量名}}` 格式）
+4. 隐含约束识别表
+
+同时输出**知识库覆盖度报告**。
+
+### 阶段二：元模型提取
+
+从知识库萃取三层元模型，标注覆盖缺口：
+- ⬜ 部分覆盖 → 改写适配
+- ❌ 未覆盖 → 标注缺口，**禁止虚构内容填充**
+
+### 阶段三：知识点关联建模
+
+**六类关联关系**：
+
+| 类型 | 约束强度 | 说明 |
+|------|---------|------|
+| →必须 | 最强 | B 必须基于 A，A 不存在则 B 无效 |
+| →引用 | 强 | B 引用 A 的数据，不一致则矛盾 |
+| →覆盖 | 强 | A 必须完整覆盖 B 的所有条目 |
+| →支撑 | 中 | A 为 B 提供论据背书 |
+
+### 阶段四：文档生成准备
+
+### 阶段五：需求映射与追溯
+
+**双向追溯矩阵**：
+- **正向追溯**（需求→内容）：给定评分点 → 找到响应章节
+- **反向追溯**（内容→需求）：给定章节 → 找到响应的评分点
+
+**追溯完整性验证**（四指标）：
+- 需求覆盖率 = **100%**
+- 高分需求响应质量分
+- 章节利用率 ≥ **70%**
+- SOW 必须项完全覆盖率 = **100%**
+
+### 阶段六：一致性约束建模
+
+通用约束（7 条）+ 项目专属约束 → **约束验证清单**
+
+### 阶段七：文档生成与验证
+
+**执行顺序**：
+1. 生成前准备：确认变量赋值、缺口处理方案
+2. **逐章生成**：标注组合块 ID + 原子要素 ID + 评分点编号
+3. **约束验证（QP-01）**：硬约束通过率必须 **100%**
+4. **最终质检（QP-03）**：追溯完整性 + 变量替换 + 章节编号
+5. **归档（QP-04）**：新要素入库，专属约束入库候选
+
+---
+
+## 🛠️ 配套工具三件套
+
+| 工具 | 格式 | 作用 |
+|------|------|------|
+| 元模型建模规范 | Markdown | 方法论主文件 |
+| 提示词手册 | Markdown | System Prompt + UP-00~UP-05 + QP-01~QP-04 |
+| 约束验证规则库 | 内嵌于规范 | 7 条通用硬约束 + 项目专属模板 |
+
+---
+
+## 📊 实际验证（iPaaS 项目样本）
+
+- **57 个**原子要素
+- **6 个**标准组合块
+- 覆盖全部 **65 分**评分点的双向追溯矩阵
+- **12 条**约束验证规则
+
+---
+
+## 💡 核心价值
+
+| 维度 | 解决方式 |
+|------|---------|
+| **内容层面** | 三层结构拆解到最小可复用粒度，每段内容都有出处 |
+| **需求层面** | 双向追溯矩阵机械验证，确定性而非主观感觉 |
+| **质量层面** | 约束图谱显式化隐性规则，硬约束 100% 通过才输出 |
+| **知识积累** | 归档机制让知识库持续生长，越用越丰富 |
+
+---
+
+## ⚠️ 适用边界
+
+- ✅ **最适合**：结构标准化、知识库充分的文档（投标响应文件等）
+- ⚠️ **价值有限**：大量创新论述、结构不固定的内容（研究报告、创意提案）
+
+---
+
+*研究归档，2026-05-03 | 基于"人月聊IT"公众号文章整理*

wiki/Areas/AI编程工具/Hermes Agent接入Obsidian内容生产线.md

@@ -0,0 +1,185 @@
+---
+created: 2026-05-02
+type: source
+tags: [Hermes Agent, Obsidian, 知识库, 内容生产, AI工作流, Agent Skill, 选题管理]
+source: "https://mp.weixin.qq.com/s/ZJZGwdWUlj8-L2Lsp1Zyog"
+author: 超级猛
+---
+
+# Hermes Agent 接入 Obsidian — 知识库内容生产线
+
+> 来源：微信公众号 **超级猛**
+> 链接：<https://mp.weixin.qq.com/s/ZJZGwdWUlj8-L2Lsp1Zyog>
+> 归档时间：2026-05-02
+
+---
+
+## 📌 核心理念
+
+> **知识库最大的浪费不是"不够大"，而是"存了不用"**
+
+核心链路：
+```
+资料进来 → 判断价值 → 拆成选题 → 生成草稿 → 发布归档
+```
+
+> 一篇收藏没进过选题池，等于死了。
+> 一个灵感没变成过大纲，只是心理安慰。
+
+---
+
+## 📂 目录设计（给 Agent 认路）
+
+```
+📁 01-Sources      ← 外部资料入库
+📁 02-Accounts
+    └─ 账号名
+       ├─ Topics    ← 选题池
+       ├─ Drafts    ← 草稿区
+       └─ Published ← 发布归档
+📁 03-Frameworks   ← 内容框架、写作规范、账号定位
+```
+
+**关键认知**：目录不是给人看的，是给 Agent 认路的。
+
+最小流转链路：
+```
+Source Note → Topic Note → Draft Note → Published Note
+```
+
+---
+
+## 🔧 五步实操
+
+### Step 1：入库判断（让 Agent 当编辑）
+
+**提示词**：
+```
+判断这篇内容是否值得收入 Obsidian 内容中台。如果值得，生成 Source Note，包含：
+- 核心摘要
+- 关键观点
+- 适合哪个账号
+- 可延展成哪些选题
+- 建议放入的目录和文件名
+```
+
+**价值**：不是简单的摘要，而是先过一遍"编辑台"——判断值不值得继续加工。低质量资料直接过滤掉。
+
+### Step 2：拆选题（钉死"写什么"）
+
+**提示词**：
+```
+基于这篇 Source Note，为账号拆 3 个选题。每个选题包含：
+- 一句话定义
+- 目标读者
+- 用户痛点
+- 核心承诺
+- 标题候选（3 个）
+- 简短提纲
+判断哪个最适合近期发布。
+```
+
+**选题四标准**：
+1. 有明确的用户痛点
+2. 有真实案例可引用
+3. 能讲成可复现的工作流
+4. 能给出可操作的方法
+
+### Step 3：生成草稿（但别直接定稿）
+
+**提示词**：
+```
+基于这个 Topic Note，写一版长文草稿。要求：
+- 从使用场景和判断出发，不要写成工具说明书
+- 结构清楚，但别像模板
+- 每节都有具体做法
+- 少用空泛形容词，多写真实问题和取舍
+- 结尾给出下一步行动建议
+```
+
+**两轮人工润色**：
+- 第一轮：删掉正确但没信息量的话
+- 第二轮：补上真实判断和使用细节
+
+> AI 帮你铺结构，但文章有没有可信度，最后看你有没有自己的判断。
+
+### Step 4：沉淀为 Skill（别每次都重新教）
+
+把稳定流程写成 Skill：
+- Source Note 生成规范
+- Topic Note 字段模板
+- 账号定位、选题偏好、表达风格
+- 公众号 vs 小红书的差异化要求
+
+**价值**：Agent 越来越像工作流成员，而不是临时聊天窗口。最消耗人的不是某一次写作，而是每次都要重新启动上下文。
+
+### Step 5：发布归档（形成反馈闭环）
+
+每条发布后补归档记录：
+```yaml
+标题: 
+发布时间: 2026-04-28
+平台: 公众号
+对应Topic: [[Topics/xxx]]
+对应Draft: [[Drafts/xxx]]
+链接: 
+封面文案: 
+数据复盘: 
+```
+
+**反馈闭环**：
+```
+Source → Topic → Draft → Published → Review → New Topic
+```
+
+> 只看草稿不看发布结果，永远没法判断什么标题有效、什么选题值得续写。内容系统不能只管生产不管反馈。
+
+---
+
+## 🚀 最小启动版本
+
+不用一步到位，先搭这个：
+
+```
+📁 01-Sources
+📁 02-Topics
+📁 03-Drafts
+📁 04-Published
+```
+
+**固定三个提示词**：
+1. **入库判断**：整理成 Source Note，判断是否值得推进
+2. **拆选题**：基于 Source Note 拆 3 个选题，推荐最适合的一个
+3. **出草稿**：基于 Topic Note 写有真实场景、有方法、有判断的草稿
+
+---
+
+## 📊 适用人群
+
+如果你中了三条以上，就很值得试试：
+- 收藏大量文章但很少转成输出
+- Obsidian 目录越来越复杂，打开频率越来越低
+- 同时管多个账号，素材不知道该分给谁
+- 想让 AI 不只是一次性写作工具，而是参与整个流程管理
+- 已在用 Claude Code/Cursor/Codex/Hermes，想把 Agent 接进真实工作流
+
+---
+
+## 🔑 最大洞察
+
+> **别只把 AI 当写作工具，把它放进流程里。**
+
+让它只写一篇文章，价值是一次性的。让它参与选题、归档、草稿、发布复盘，价值才会累积。
+
+---
+
+## 🔗 关联资源
+
+- [[Skill自动化管理方法]]（空格的知识库管理方案）
+- [[程序员最常用10个AI提示词]]（提示词工程）
+- [[MapLibre Agent Skills研究]]（垂直领域 Agent 技能化）
+- [[Skyvern研究]]（浏览器自动化 Agent）
+
+---
+
+*研究完成，2026-05-02 | 作者超级猛，Hermes Agent + Obsidian 内容生产线，从仓库到生产线的转变*

wiki/Areas/AI编程工具/MapLibre Agent Skills研究.md

@@ -0,0 +1,116 @@
+---
+created: 2026-05-02
+type: source
+tags: [MapLibre, Agent Skills, WebGIS, AI编程, 地图开发, 开源GIS, PMTiles, Martin]
+source: "https://mp.weixin.qq.com/s/C1V3fDBtBJuBG9qGBmfsnA"
+author: WebGIS 公众号
+---
+
+# MapLibre Agent Skills v1.0.0 — AI 重构 WebGIS 开发
+
+> 来源：微信公众号
+> 链接：<https://mp.weixin.qq.com/s/C1V3fDBtBJuBG9qGBmfsnA>
+> 官方仓库：agentskills.io
+> 归档时间：2026-05-02
+
+---
+
+## 📌 一句话总结
+
+> **MapLibre 官方为 AI 编程助手定制的专业技能库 v1.0.0 正式发布，解决大模型写地图代码「瞎编 API、配置出错、专业知识幻觉」的老问题。**
+
+---
+
+## 🏗️ 什么是 MapLibre Agent Skills？
+
+MapLibre 官方为 Cursor、Claude Code、Copilot 等 AI 编程工具定制的**专业技能库**，遵循 agentskills.io 开放标准，封装了：
+
+- 官方 API 规范
+- 最佳实践
+- 避坑指南
+- 瓦片服务配置
+- 迁移方案
+
+**核心价值**：自然语言一句话，AI 直接输出可上线的 MapLibre 标准代码。
+
+---
+
+## ✅ v1.0.0 核心能力（2026 年 5 月）
+
+### 1. 版本正式稳定
+- 5 月 1 日 API 冻结
+- 企业项目、生产环境可直接落地
+
+### 2. 五大官方核心技能
+
+| 技能 | 功能 | 解决痛点 |
+|------|------|---------|
+| **Mapbox 一键迁移** | 自动移除 Token、替换依赖、改写样式地址、适配插件 | 告别手动逐行修改 |
+| **开源瓦片源大全** | 集成 OSM/PMTiles/MBTiles/Planetiler | S3/R2 无服务器托管 |
+| **PMTiles 最佳实践** | 前端直接加载海量数据，内置缓存策略 | 无需搭建瓦片服务器 |
+| **Martin 瓦片服务器** | 明确 YAML 配置、环境变量优先级、反向代理 | **AI 生成配置错误率从 78% → 5%** |
+| **云原生数据直读** | 浏览器加载 COG/FlatGeobuf/GeoParquet | 无需后端预处理 |
+
+### 3. 4-5 月迭代亮点
+- 优化技能触发逻辑，减少误唤醒，降低 Token 消耗
+- 新增专业基线测试机制，保证 AI 输出严谨合规
+- 适配全主流 AI 编辑器：**Cursor / Claude Code / GitHub Copilot / Windsurf / Gemini CLI**
+
+---
+
+## 🔮 未来路线（Q2-Q3 规划）
+
+| 规划 | 说明 |
+|------|------|
+| 专业地图制图 | 图层排序、字体精灵、无障碍地图设计 |
+| Google Maps 迁移 | 一键迁移至 MapLibre |
+| 高阶可视化 | 热力图、分级设色、点聚合、3D 动画 |
+| 跨端适配 | Web 端与 MapLibre Native 差异适配 |
+
+---
+
+## 💻 快速上手
+
+```bash
+# 安装全部官方技能
+npx skills add maplibre/maplibre-agent-skills
+
+# 按需安装单个技能（轻量化无侵入）
+npx skills add maplibre/maplibre-agent-skills/pmtiles
+```
+
+**使用示例**：
+> "帮我把现有 Mapbox 项目迁移到 MapLibre，用 PMTiles 托管矢量瓦片，配置 Martin 服务"
+
+→ AI 自动调用官方技能，直接产出可运行的完整代码 + 配置文件。
+
+---
+
+## 📊 对 GIS 开发者的影响
+
+| 维度 | 影响 |
+|------|------|
+| **提效** | 基础配置、项目迁移、瓦片服务搭建全交给 AI |
+| **质量** | 官方规范约束，告别 API 幻觉 |
+| **门槛** | 前端/后端开发者也能快速上手 WebGIS |
+| **行业** | 垂直领域「官方 Agent 技能化」已成定局 |
+
+---
+
+## 🔗 行业趋势
+
+MapLibre 是首个发布官方 Agent Skills 的开源 GIS 库。预计 **Cesium、OpenLayers 等开源 GIS 库必将跟进**。
+
+垂直领域的「官方 Agent 技能化」正在成为趋势——不仅是 GIS，其他专业领域（金融、医疗、法律）也会出现类似模式。
+
+---
+
+## 🔗 关联资源
+
+- [[Skyvern研究]]（浏览器自动化 Agent）
+- [[Skill自动化管理方法]]（Skill 基础设施管理）
+- [[程序员最常用10个AI提示词]]（提示词工程）
+
+---
+
+*研究完成，2026-05-02 | MapLibre Agent Skills v1.0.0，WebGIS 开发进入 AI 专业化时代*

wiki/Areas/AI编程工具/Obsidian+AI工作流研究.md

@@ -0,0 +1,41 @@
+---
+created: 2026-05-01
+type: knowledge
+tags: [Obsidian, AI, 知识管理, 工作流, 抖音, Aiob]
+source: https://v.douyin.com/gjP5VZmI9_A/
+---
+
+# Obsidian + AI 工作流研究
+
+> 抖音博主 @Aiob 分享：Obsidian + AI，2026 唯一的神
+
+## 为什么 Obsidian 天然适合 AI？
+
+1. **本地 Markdown 文件** — AI 可直接读写，无需 API
+2. **双向链接 + 知识图谱** — 为 AI 提供丰富的上下文
+3. **插件生态丰富** — Remotely Save、Templater、Dataview 等
+
+## 推荐工作流
+
+1. 用 AI 生成笔记内容 → 存入 Obsidian
+2. 利用双向链接构建知识网络
+3. 通过 AI 插件实现对话式查询和总结
+
+## 为什么是"唯一的神"？
+
+- 相比 Notion/语雀等云端方案，Obsidian 数据完全本地
+- 配合 AI 后，知识管理效率提升数倍
+- 开源生态 + 插件，可定制性极强
+
+## 与我们的实践对比
+
+| 方面 | 我们 | @Aiob |
+|------|------|-------|
+| AI 工具 | OpenClaw + obsidian-headless | 通用 AI 插件 |
+| 同步方式 | WebDAV | Remotely Save |
+| 知识管理 | PARA 结构 | 双向链接 |
+| 自动化 | ✅ cron/heartbeat | ❌ 手动 |
+
+---
+
+*基于抖音博主 @Aiob 内容整理 | 归档：2026-05-01*

wiki/Areas/AI编程工具/Obsidian一键发布公众号.md

@@ -0,0 +1,99 @@
+---
+created: 2026-05-02
+type: source
+tags: [Obsidian, 微信公众号, 发布, 插件, 公众号发布助手, Markdown, HTML, BRAT]
+source: "https://mp.weixin.qq.com/s/rQwjzPHY8oEW5RyLhwBEIg"
+author: yoffie
+---
+
+# Obsidian 一键复制公众号（HTML）格式 — 插件方案
+
+> 来源：微信公众号 **yoffie**
+> 链接：<https://mp.weixin.qq.com/s/rQwjzPHY8oEW5RyLhwBEIg>
+> 归档时间：2026-05-02
+
+---
+
+## 📌 核心需求
+
+在 Obsidian 里编辑好文章 → **一键预览公众号效果** → **一键发布到公众号草稿箱**
+
+---
+
+## 🔧 插件 1：公众号发布助手（obsidian-mp-publisher）
+
+### 安装方式
+
+**通过 BRAT 插件安装**（尚未上架社区插件市场）：
+
+1. Obsidian → 设置 → 第三方插件 → 关闭安全模式
+2. 搜索安装 **BRAT**（用于安装 Beta 版插件）
+3. 复制插件地址：`https://github.com/joeytoday/obsidian-mp-publisher`
+4. BRAT → "Add beta plugin" → 粘贴地址 → 确定
+
+### 核心功能
+
+| 功能 | 说明 |
+|------|------|
+| **一键发布** | 左侧工具栏发布按钮，配置公众号信息后直接发布到草稿箱 |
+| **公众号预览** | 编辑器右侧顶部出现"公众号预览"按钮 |
+| **主题编辑** | Ctrl+P 打开主题设置，支持自定义 CSS |
+| **自定义样式** | 可复制预设主题 CSS，让 AI 按需求调整 |
+
+### 使用流程
+
+```
+Obsidian 编辑 Markdown
+  ↓
+Ctrl+P 选择主题样式
+  ↓
+右侧顶部"公众号预览"确认效果
+  ↓
+左侧"发布"按钮 → 一键发布到草稿箱
+```
+
+---
+
+## 🔧 插件 2：Markdown 格式编辑助手（obsidian-editing-toolbar）
+
+### 安装方式
+
+**手动安装**（如社区插件市场打不开）：
+
+1. 下载 Release：`https://github.com/PKM-er/obsidian-editing-toolbar`
+2. 找到 `main.js`、`manifest.json`、`styles.css` 三个文件
+3. 进入 `.obsidian/plugins` 目录
+4. 创建文件夹 `editing-toolbar`
+5. 将三个文件放入
+6. 打开 Obsidian，启用插件
+
+### 核心功能
+
+- 提供类似 Word 的富文本编辑工具栏
+- 选中文字后点击工具栏按钮即可应用样式
+- 不熟悉 Markdown 语法的用户的福音
+
+---
+
+## 💡 自定义主题技巧
+
+**自定义主题 = AI 的主场**：
+
+1. 复制预设主题的 CSS
+2. 发给 AI（如 Claude/Cursor）
+3. 描述你想要的公众号样式效果
+4. AI 帮你调整 CSS
+5. 粘贴回 Obsidian 主题设置
+
+---
+
+## 🔗 关联资源
+
+- [[微信公众号文章编写与发布]]（md2wechat CLI 方案）
+- [[Hermes Agent接入Obsidian内容生产线]]（Obsidian + Agent 工作流）
+- [[Obsidian多端同步方案]]（Remotely Save + 坚果云）
+- [[Obsidian图片整理术]]（Image Converter 插件）
+
+---
+
+*研究完成，2026-05-02 | Obsidian 一键发布公众号插件方案，obsidian-mp-publisher + editing-toolbar*

wiki/Areas/AI编程工具/Obsidian图片整理术.md

@@ -0,0 +1,128 @@
+---
+created: 2026-05-02
+type: source
+tags: [Obsidian, 图片管理, Image Converter, 插件, 笔记整理, 知识库]
+source: "https://mp.weixin.qq.com/s/UrQ9cpX5342hhkOpLJXWjQ"
+author: obsidian指南
+---
+
+# Obsidian 图片整理术 — Image Converter 插件工作流
+
+> 来源：微信公众号 **obsidian指南**
+> 链接：<https://mp.weixin.qq.com/s/UrQ9cpX5342hhkOpLJXWjQ>
+> 归档时间：2026-05-02
+
+---
+
+## 📌 核心问题
+
+Obsidian 图片管理的两大痛点：
+1. **文件名乱码** — 粘贴后变成一长串看不懂的字符
+2. **体积太大** — 微信截图默认 PNG，文件大且公众号不支持
+
+---
+
+## 🔧 四步解决方案
+
+### 第一步：固定图片存放位置
+
+**设置路径**：设置 → 文件与链接 → 附件默认存放路径
+
+推荐选项：**当前文件所在文件夹下指定的子文件夹**
+
+文件夹名：`images`
+
+**效果**：
+```
+写作总结/
+  └── images/        ← 这篇笔记的所有图片
+项目计划/
+  └── images/        ← 这篇笔记的所有图片
+```
+
+每篇笔记的图片独立存放，再也不乱套。
+
+### 第二步：安装 Image Converter 插件
+
+- 社区插件市场搜索 `Image Converter`
+- 安装并启用
+
+### 第三步：自动命名图片
+
+**Filename 格式设置**：
+
+| 格式 | 效果 |
+|------|------|
+| `{{noteName}}-{{timestamp}}` | 笔记名-时间戳 |
+| `{{noteName}}-图片` | 笔记名-图片 |
+| `{{year}}年{{month}}月-{{noteName}}` | 年月-笔记名 |
+
+**效果**：
+```
+公众号写作-1776250760498.png
+教程大纲-1776250761234.png
+```
+
+### 第四步：自动压缩图片
+
+**推荐设置**：
+- 输出格式：**JPEG**
+- 压缩质量：**85%**
+
+**为什么选 JPEG？**
+- ✅ 公众号文章支持
+- ✅ 体积比 PNG 小很多
+- ✅ 网页兼容性好
+- 💡 如果主要本地使用，可选 WebP（更省空间）
+
+---
+
+## 📋 完整工作流
+
+```
+截图/Ctrl+C 复制图片
+  ↓
+Ctrl+V 粘贴到 Obsidian
+  ↓
+自动完成：
+  1. 图片存入对应笔记的 images 文件夹
+  2. 文件名变成"笔记名-时间戳.jpeg"
+  3. 格式从 PNG 优化为 JPEG
+```
+
+---
+
+## 🏆 四大好处
+
+| 好处 | 说明 |
+|------|------|
+| **管理方便** | 一看名字就知道是哪篇笔记的图片 |
+| **节省空间** | PNG → JPEG，体积减少 **50-70%** |
+| **发布省事** | 公众号不用手动转格式，大于 2M 的情况少很多 |
+| **查找快捷** | 文件名带笔记名，搜索一找一个准 |
+
+---
+
+## 💡 实用技巧
+
+### 组合拳：Image Converter + Excalidraw
+
+```
+Excalidraw 画图 → 导出图片
+  ↓
+粘贴进 Obsidian → Image Converter 自动处理
+```
+
+### 配合模板使用
+
+设置自动图片引用格式，让图片在笔记里显示更整齐。
+
+---
+
+## 🔗 关联资源
+
+- [[Hermes Agent接入Obsidian内容生产线]]（Obsidian + Agent 工作流）
+
+---
+
+*研究完成，2026-05-02 | Obsidian 图片管理最佳实践，Image Converter 插件配置指南*

wiki/Areas/AI编程工具/Obsidian多端同步方案.md

@@ -0,0 +1,100 @@
+---
+created: 2026-05-02
+type: source
+tags: [Obsidian, 多端同步, Remotely Save, 坚果云, WebDAV, 免费方案, 跨设备]
+source: "https://mp.weixin.qq.com/s/RV2hWtg8Q46EeeKH_Cmzuw"
+---
+
+# Obsidian 多端同步 — Remotely Save + 坚果云 WebDAV
+
+> 来源：微信公众号
+> 链接：<https://mp.weixin.qq.com/s/RV2hWtg8Q46EeeKH_Cmzuw>
+> 归档时间：2026-05-02
+
+---
+
+## 📌 方案概述
+
+**Remotely Save 插件 + 坚果云 WebDAV** → 实现 PC + PC + 安卓三端**免费实时同步**
+
+**核心优势**：
+- ✅ **完全免费**（坚果云免费版每月 1GB 上传流量）
+- ✅ **三端互通**（多台电脑 + 多部手机）
+- ✅ **国内稳定**（无需科学上网）
+- ✅ **操作简单**（注册坚果云即可）
+
+---
+
+## 🔧 四步配置法
+
+### 第一步：准备工作
+
+1. 所有设备安装 Obsidian
+2. 注册**坚果云账号**（免费版即可）
+3. 获取 WebDAV 信息：
+   - **服务器地址**：`https://dav.jianguoyun.com/dav/`
+   - **账号**：坚果云手机号/邮箱
+   - **密码**：WebDAV **专属密码**（不是登录密码！）
+
+> 💡 在坚果云设置中获取**第三方 WebDAV 密码**
+
+### 第二步：安装插件
+
+- 打开 Obsidian → 设置 → 第三方插件
+- 关闭安全模式
+- 搜索 **"Remotely Save"**
+- 安装并启用
+
+### 第三步：配置同步
+
+| 配置项 | 值 |
+|--------|---|
+| 远程服务 | **webdav** |
+| 服务器地址 | `https://dav.jianguoyun.com/dav/` |
+| Username | 坚果云账号 |
+| Password | **WebDAV 专属密码** |
+
+**同步频率设置**：
+- 保存时自动同步
+- 启动时自动同步
+- 离开编辑页时同步
+- 首次同步可开到 100（秒级同步）
+
+### 第四步：开启同步
+
+- 笔记页面左上角点击**同步按钮**
+- 首次同步完成后自动同步
+
+---
+
+## 📱 手机端配置
+
+- 操作与 PC 端**完全相同**
+- ⚠️ **重要**：所有新设备必须在**全新的知识库**里同步，不要用已有库覆盖！
+
+---
+
+## 🔐 隐私安全
+
+- 数据通过 WebDAV 协议传输
+- 加密/解密都在**本地设备**完成
+- 云服务商无法查看笔记内容
+
+---
+
+## 💡 使用建议
+
+- 坚果云免费版每月 **1GB** 上传流量，个人笔记完全够用
+- 图片多了可用其他插件（如 Image Converter）压缩处理
+- 冲突检测：自动检测冲突文件，避免数据丢失
+
+---
+
+## 🔗 关联资源
+
+- [[Obsidian图片整理术]]（Image Converter 插件）
+- [[Hermes Agent接入Obsidian内容生产线]]（Obsidian + Agent 工作流）
+
+---
+
+*研究完成，2026-05-02 | Obsidian 多端同步免费方案，Remotely Save + 坚果云 WebDAV 配置指南*

wiki/IT趋势/万豪数字化转型与Harness合作.md

@@ -0,0 +1,78 @@
+# 万豪数字化转型与 Harness 合作研究
+
+> 来源: AWS 赞助演示文稿（Harness 赞助）
+> 研究日期: 2026-05-07
+> 文件: 万豪的数字化转型与Harness携手打造未来.pdf
+
+## 演示概述
+
+- **标题**: Engineering the Future of Hospitality: Marriott's Global Digital Transformation
+- **赞助商**: Harness + AWS
+- **演讲者**:
+  - Jyoti Bansal（Harness）
+  - Nick Durkin（Harness）
+  - Adnan Haq（Harness）
+  - Sean Corkum（Marriott International）
+
+## Harness 公司简介
+
+- **使命**: Enable the world's 37 million software developers to deliver code quickly, reliably, efficiently, and securely
+- **定位**: 软件开发效能平台（Software Delivery Platform）
+- **核心领域**: CI/CD、软件交付、DevOps、软件治理
+
+## AI 对工程效能的影响数据
+
+| 指标 | 变化 |
+|------|------|
+| AI 编程采用率 | **+25%** |
+| 交付稳定性 | **-7.2%**（下降） |
+| 交付吞吐量 | **-1.5%**（下降） |
+
+> ⚠️ 有趣发现：AI 采用率上升，但交付稳定性和吞吐量反而下降。可能原因：
+> - AI 生成代码需要更多审查
+> - 代码质量参差不齐
+> - 团队还在适应期
+
+## 万豪数字化转型背景
+
+- **万豪国际**: 全球最大的酒店集团之一
+- **转型范围**: 全球数字化
+- **核心挑战**: 如何在大规模组织中提升软件工程效能
+
+## 关键议题（推测）
+
+基于演讲者和主题，演示可能涵盖：
+
+1. **万豪的工程挑战**
+   - 全球分布式团队
+   - 遗留系统现代化
+   - 多品牌多系统的整合
+
+2. **Harness 平台能力**
+   - CI/CD 管道优化
+   - 软件交付自动化
+   - 安全与合规
+   - 成本优化（FinOps）
+   - 软件目录与治理
+
+3. **转型成果**
+   - 交付速度提升
+   - 部署频率增加
+   - 故障恢复时间缩短
+   - 开发者体验改善
+
+## 与我们的关联
+
+- **DevOps 实践**: Harness 是现代软件交付平台的代表
+- **AI 编程影响**: 数据显示 AI 采用率↑但稳定性↓，值得关注
+- **工程效能**: 大型组织数字化转型的参考案例
+
+## 待补充
+
+由于 PDF 无法完整解析，以下内容缺失：
+- [ ] 万豪具体转型策略
+- [ ] Harness 平台在万豪的具体应用
+- [ ] 转型成果的具体数据
+- [ ] 最佳实践和建议
+
+> 注: 需要安装 pdftotext 或 PyPDF2 才能完整提取 PDF 内容。

wiki/Projects/布拉格散射_BraggScattering.md

@@ -0,0 +1,215 @@
+---
+created: 2026-05-02
+type: concept
+tags: [布拉格散射, Bragg scattering, 雷达, 遥感, 海面, 多普勒, 无人机测流]
+---
+
+# 布拉格散射（Bragg Scattering）
+
+> 电磁波与周期性结构相互作用产生相干散射的物理机制
+> 归档时间：2026-05-02
+
+---
+
+## 📌 基本原理
+
+### 布拉格条件
+
+当入射波的波长 λ 与散射体周期性结构的间距 d 满足特定关系时，会发生**相干增强散射**：
+
+```
+nλ = 2d·sin(θ)
+
+其中：
+n = 散射级数（通常 n=1）
+λ = 入射电磁波波长
+d = 散射体结构周期（如水面波纹波长）
+θ = 入射角（波束与法线夹角）
+```
+
+**物理图像**：入射波被周期性排列的散射体散射，当各散射波的**相位差**为 2π 的整数倍时，发生**相长干涉**，回波信号显著增强。
+
+---
+
+## 🌊 在雷达海面测流中的应用
+
+### 海面粗糙元与布拉格共振
+
+海面存在**毛细重力波**（capillary-gravity waves），其波长与雷达波长匹配时，发生布拉格共振：
+
+```
+λ_雷达 / 2 = λ_水面波
+
+即：雷达波长的一半 = 水面波纹波长
+```
+
+| 雷达波段 | 频率 | 波长 | 共振水面波波长 |
+|---------|------|------|-------------|
+| X波段 | 10 GHz | 3 cm | **1.5 cm** |
+| C波段 | 5 GHz | 6 cm | **3 cm** |
+| Ku波段 | 14 GHz | 2.1 cm | **1.05 cm** |
+| Ka波段 | 35 GHz | 0.86 cm | **0.43 cm** |
+
+### 多普勒频移与流速
+
+布拉格散射的回波携带多普勒频移，与**沿雷达视线方向的水面波相速度**相关：
+
+```
+f_d = 2 × v_phase × cos(θ) / λ_雷达
+
+其中 v_phase 是水面波的相速度
+```
+
+**关键关系**：
+```
+v_phase = √(g·λ_w/(2π) + 2π·σ/(ρ·λ_w))
+
+其中：
+g = 重力加速度
+λ_w = 水面波波长
+σ = 表面张力
+ρ = 水密度
+```
+
+---
+
+## 🔍 布拉格散射的物理机制
+
+### 1. 小扰动近似（Small Perturbation Approximation）
+
+当海面粗糙度远小于雷达波长时（σ_h << λ），可用一阶小扰动理论：
+
+```
+σ⁰ (归一化雷达截面) ∝ |R|² · S(k_Bragg)
+
+其中：
+R = 菲涅尔反射系数
+S(k) = 海面波数谱（wave spectrum）
+k_Bragg = 2k·sin(θ) = 布拉格波数
+```
+
+### 2. 双尺度模型（Two-Scale Model）
+
+实际海面包含**长波**（重力波）和**短波**（毛细波）：
+
+```
+长波（米级）→ 调制局部入射角和速度
+短波（厘米级）→ 产生布拉格散射
+```
+
+**调制机制**：
+- **倾斜调制**（Tilt modulation）：长波改变局部入射角
+- **流体力学调制**（Hydrodynamic modulation）：长波改变短波的能量分布
+- **遮蔽效应**（Shadowing）：长波波谷遮蔽部分散射体
+
+### 3. 极化特性
+
+| 极化 | 散射强度 | 特点 |
+|------|---------|------|
+| VV | 较强 | 对布拉格波敏感，适用于流速测量 |
+| HH | 较弱 | 易受非布拉格散射干扰 |
+| HV/VH | 很弱 | 交叉极化，主要来自非布拉格散射 |
+
+**VV 极化是海面测流的首选**，因为布拉格散射在 VV 极化下最强。
+
+---
+
+## ⚡ 布拉格散射在测流中的误差来源
+
+### 1. 非布拉格散射干扰
+
+```
+总回波 = 布拉格散射 + 非布拉格散射（白冠、破碎波）
+
+非布拉格散射影响：
+- 高风速（>7 m/s）时显著增加
+- 导致多普勒频移偏移
+- 误差可达 0.2-0.5 m/s
+```
+
+### 2. 短波相速度与长波叠加
+
+```
+测量的多普勒速度 = 布拉格波相速度 + 长波轨道速度 + 水流速度
+
+如果仅用布拉格波相速度反演，会引入系统误差
+```
+
+**修正方法**：
+- 使用双频雷达消除长波影响
+- 建立经验校正模型
+
+### 3. 风致偏移
+
+风会使短波的相速度偏离静水面理论值：
+
+```
+Δv_wind ≈ 0.1-0.3 m/s（风速 5-10 m/s 时）
+```
+
+### 4. 入射角敏感性
+
+```
+当 θ 接近布拉格角时，信号最强
+偏离布拉格角时，信号按 cos⁴(θ) 衰减
+```
+
+---
+
+## 📊 布拉格散射 vs 其他散射机制
+
+| 散射机制 | 适用条件 | 散射体 | 多普勒特性 |
+|---------|---------|--------|-----------|
+| **布拉格散射** | 低-中风速，小入射角 | 毛细重力波 | 稳定，可预测 |
+| **白冠散射** | 高风速（>7 m/s） | 破碎波浪 | 随机，不可预测 |
+| ** specular 反射** | 极低入射角 | 平静水面 | 零频移 |
+| **体积散射** | 降雨时 | 雨滴 | 附加频移 |
+
+---
+
+## 🔧 应用要点
+
+### 最佳测量条件
+
+| 参数 | 推荐值 | 原因 |
+|------|--------|------|
+| 风速 | < 7 m/s | 避免非布拉格散射干扰 |
+| 入射角 | 20-60° | 布拉格共振最佳 |
+| 极化 | VV | 布拉格散射最强 |
+| 海况 | 低-中等 | 毛细波稳定存在 |
+
+### 频率选择
+
+```
+低频（L/C波段）：
+- 共振波长较长（几厘米）
+- 对应较慢的相速度
+- 适合低流速测量
+
+高频（X/Ku波段）：
+- 共振波长较短（~1cm）
+- 相速度较快
+- 对高流速更敏感
+```
+
+---
+
+## 📝 与无人机雷达测流的关系
+
+在无人机雷达波测流中，布拉格散射是**核心物理机制**：
+
+```
+无人机搭载雷达 → 照射海面 → 毛细波产生布拉格散射
+→ 回波多普勒频移 → 反演水面波速度 → 推算水流速度
+```
+
+**误差链路**：
+```
+布拉格波相速度误差 → 多普勒频移测量误差 → 流速反演误差
+```
+
+控制布拉格散射的不确定性（风影响、非布拉格干扰、入射角偏差）是提高测流精度的关键。
+
+---
+
+*研究完成，2026-05-02 | 布拉格散射物理机制与雷达测流应用整理*

wiki/Projects/无人机CAAC口诀与高频考点.md

@@ -0,0 +1,222 @@
+---
+created: 2026-05-02
+type: source
+tags: [无人机, CAAC, 口诀, 高频考点, 理论考试, 多旋翼, 超视距, 机长]
+source: "https://mp.weixin.qq.com/s/b0-OU4t851lkKk0TFMtFVQ"
+---
+
+# 无人机 CAAC 口诀 + 考点（2026 最新版）
+
+> 来源：微信公众号
+> 链接：<https://mp.weixin.qq.com/s/b0-OU4t851lkKk0TFMtFVQ>
+> 归档时间：2026-05-02
+
+---
+
+## 一、操作与应急类（1-20）
+
+### 🧭 答题技巧口诀
+
+| # | 口诀 | 说明 |
+|---|------|------|
+| 1 | 看到**操纵**，选有操纵 | 操控类题 |
+| 2 | 看到**链路**，选链路 | 通信类题 |
+| 3 | 看到**平飞**，选平飞 | 飞行状态题 |
+| 4 | **左坡** → 选**右压杆** | 坡度修正 |
+| 5 | **右坡** → 选**左压杆** | 坡度修正 |
+| 6 | **左侧滑** → **向左转** | 侧滑修正 |
+| 7 | 看到**粗猛**，选**没有粗猛**的 | 操作规范题 |
+| 8 | 看到**容器式发射装置**，选它 | 发射装置题 |
+| 9 | **向右偏离** → **向左压杆** | 偏离修正 |
+| 10 | **向左偏离** → **向右压杆** | 偏离修正 |
+| 11 | **左偏力矩较大** → 选**右偏** | 力矩平衡 |
+
+### ⏱️ 飞行时间口诀
+
+| 场景 | 时间 |
+|------|------|
+| 山区飞行 | **20 分钟** |
+| 平原飞行 | **30 分钟** |
+| 晚上山区飞行 | **15 分钟** |
+
+### 📏 农业/水域飞行高度
+
+| 场景 | 高度 |
+|------|------|
+| 农业平原飞行 | **150 米** |
+| 山区农业飞行 | **300 米** |
+| 水域渔业飞行 | **200 米** |
+
+### 🚨 应急口诀
+
+```
+信号丢失切姿态，逆风修正半杆量
+电机失效稳速度，多旋靠余桨调整
+电压骤降立即返，缩短航程不绕弯
+```
+
+---
+
+## 二、法规与空域类（21-40）
+
+### 📋 无人机分类
+
+| 类型 | 空机重量 | 最大起飞重量 | 执照要求 |
+|------|---------|-------------|---------|
+| **微型** | ≤ 0.25 kg | - | 非商业无需 |
+| **轻型** | ≤ 4 kg | ≤ 7 kg | 超视距需持证 |
+| **小型** | ≤ 15 kg | ≤ 25 kg | 商业必须持证 |
+| **中型** | ≤ 150 kg | - | 需对应等级执照 |
+
+### 🛫 空域管理
+
+| 空域 | 要求 |
+|------|------|
+| **管制空域** | 提前 **12 小时** 提交飞行计划并获批 |
+| **适飞空域** | 平台实时报备即可起飞 |
+| **机场净空保护区** | 限制飞行 |
+| **军事禁区** | **严禁飞行**，违者追究法律责任 |
+| **城市核心区** | 需提前申请并获得批准 |
+| **边境地区** | 严禁越境飞行 |
+
+### ⚖️ 法规要点
+
+| 项目 | 要求 |
+|------|------|
+| 实名登记 | **250g 以上**必须实名登记 |
+| 第三者责任险 | 商业飞行保额 ≥ **100 万元** |
+| 视距内飞行 | 半径 ≤ **500 米**，高度 ≤ **120 米** |
+| 超视距飞行 | 需持**机长执照**并申请空域 |
+| 夜间飞行 | 需**开启灯光系统** |
+| 农用无人机 | **150kg 以下**在农林适飞空域可**豁免执照** |
+| 违规处罚 | 最高可处 **10 万元**罚款，情节严重行政拘留 |
+
+### 🔴 "黑飞"行为
+
+- 无证飞行
+- 超视距飞行未报备
+- 禁飞区飞行
+
+---
+
+## 三、飞行原理与系统（41-60）
+
+### ✈️ 飞行原理
+
+| # | 知识点 | 要点 |
+|---|--------|------|
+| 41 | 升力原理 | 伯努利原理 + 气流分离，迎角增大升力增大 |
+| 42 | 推力与速度 | 油门推，速度提，推力大，飞得急 |
+| 43 | GPS 定位 | 至少需 **4 颗卫星**实现三维定位 |
+| 44 | 姿态模式（ATT） | 仅保持高度，需**手动控制水平位置** |
+| 45 | 返航逻辑 | 低电量触发返航阈值通常为 **30%** 电量 |
+| 50 | 重心调整 | 重心偏移会导致悬停时**持续漂移** |
+| 51 | 风对飞行 | 逆风阻力大，顺风速度快 |
+
+### 🔧 飞控系统
+
+| 飞控 | 特点 |
+|------|------|
+| **多轴 KK** | 价格便宜，硬件结构简单 |
+| **APM** | 配有地面站软件，**代码开源** |
+| **DJI NAZA** | 稳定，商业软件，**代码不开源** |
+
+### 🔋 电池与电机
+
+| 知识点 | 要点 |
+|--------|------|
+| 电调 "30A" | 最大**瞬间电流** 30 安培 |
+| 锂电池电压 | 3S = 11.1V，4S = 14.8V |
+| 电池存储 | 电量保持 **40%-60%** |
+| 低温影响 | 容量下降，电机启动困难 |
+| 电机规格 | **前两位**=定子直径，**后两位**=定子高度 |
+
+### 🔄 多旋翼特性
+
+- **对角电机转向相反** → 抵消反扭矩
+- **六轴无人机**可承受单电机失效
+- 桨叶具扭转特性 → 桨根升力系数 > 桨尖
+
+---
+
+## 四、气象与环境（61-81）
+
+### 🌡️ 安全飞行条件
+
+| 条件 | 标准 |
+|------|------|
+| 安全风速 | 多旋翼 ≤ **8 米/秒**，超过停飞 |
+| 能见度 | 低于 **500 米**禁止飞行 |
+| 轻型真高 | ≤ **120 米** |
+| 微型真高 | ≤ **50 米** |
+| 农业飞行最大高度（2026 新规） | **30 米**，超出需特殊许可 |
+
+### 🌦️ 天气应对口诀
+
+```
+雾天避障导航，起降选迎风
+冷锋过境时选下降，避免颠簸
+积云高，雨云低，层云平，飞要避
+```
+
+| 天气 | 应对措施 |
+|------|---------|
+| 高温 | 降低电池续航，影响电子设备 |
+| 高湿度 | 易短路，加强防潮 |
+| 沙尘 | 损坏电机和传感器，飞行后彻底清洁 |
+| 雨天 | **严禁在雨中飞行** |
+| 雷电 | **立即返航**，避免空旷区域停留 |
+| 气压突变 | 调油门校传感，避免高度偏差 |
+
+### 🏔️ 特殊地形
+
+| 地形 | 要点 |
+|------|------|
+| 山谷 | 背风面逆风飞行易遇**乱流** |
+| 山脊 | 气流不稳定，需保持高度 |
+| 海拔升高 | 空气密度↓ → 升力↓ |
+
+### 💨 风的影响
+
+| 场景 | 应对 |
+|------|------|
+| 风中悬停 | 选**逆风**，保持稳定 |
+| 侧风飞行 | 需**压杆修正**航向 |
+| 乱流 | 保持油门稳定，**避免剧烈操作** |
+
+---
+
+## 📝 速记口诀汇总
+
+### 坡度修正
+```
+左坡右压，右坡左压
+左偏右压，右偏左压
+```
+
+### 应急处理
+```
+信号丢失 → 切姿态，逆风修正半杆量
+电机失效 → 稳速度，多旋靠余桨调整
+电压骤降 → 立即返，缩短航程不绕弯
+```
+
+### 天气口诀
+```
+雾天避障，起降迎风
+冷锋下降，避开颠簸
+积云高，雨云低，层云平，飞要避
+```
+
+---
+
+## 🔗 关联资源
+
+- [[无人机CAAC执照]]（证书体系概览）
+- [[无人机考证-中型多旋翼知识点]]（完整知识点手册）
+- [[CAAC无人机理论考试1300题讲解]]（B站视频课程）
+- [[无人机CAAC执照理论基础知识]]（法规+系统+安全完整版）
+
+---
+
+*研究完成，2026-05-02 | 81 条口诀 + 高频考点，考前冲刺必备*

wiki/Projects/无人机CAAC执照理论基础知识.md

@@ -0,0 +1,255 @@
+---
+created: 2026-05-02
+type: source
+tags: [无人机, CAAC, 多旋翼, 理论考试, 执照, 空域管理, 法规, 安全]
+source: "https://mp.weixin.qq.com/s/ZCVxbd8hKuhb1qbaWO4L4A"
+---
+
+# 无人机 CAAC 执照理论基础知识（多旋翼）— 核心要点
+
+> 来源：微信公众号
+> 链接：<https://mp.weixin.qq.com/s/ZCVxbd8hKuhb1qbaWO4L4A>
+> 归档时间：2026-05-02
+
+---
+
+## 一、无人机分类
+
+### 微型 vs 轻型
+
+| 参数 | 微型 | 轻型 |
+|------|------|------|
+| **空机重量** | < 0.25 kg | ≤ 4 kg |
+| **最大起飞重量** | - | ≤ 7 kg |
+| **最大飞行真高** | ≤ 50 m | - |
+| **最大平飞速度** | ≤ 40 km/h | ≤ 100 km/h |
+| **执照要求** | 无需 | 无需 |
+
+### 关键定义
+
+- **空机重量**：机体 + 电池 + 燃料容器，**不含**燃料和任务载荷
+- **最大起飞重量**：设计允许的最大正常起飞重量
+- **飞行真高**：飞行器与地面投影的实时距离
+
+---
+
+## 二、操控员管理
+
+### 执照要求
+
+| 机型 | 是否需要执照 |
+|------|-------------|
+| 微型、轻型 | ❌ 无需 |
+| 小型、中型、大型 | ✅ 需要 |
+| 农用作业 | ❌ 无需（但需操作证书） |
+
+### 责任保险
+
+从事**经营性飞行**或使用**小型及以上**无人机从事非经营性飞行，**必须投保责任保险**。
+
+### 未成年人限制
+
+- 无民事行为能力人 → 只能操控**微型**
+- 限制民事行为能力人 → 只能操控**微型、轻型**
+- 必须有完全民事行为能力人**现场指导**
+
+---
+
+## 三、登记管理
+
+### 登记类型
+
+- **实名登记**：境内飞行必须
+- **国籍登记**：境外飞行必须
+- **不得双重国籍**
+
+### 注销登记情形
+
+1. 所有权/占有权变更
+2. 退出使用、报废或失事
+3. 所有权转移境外
+
+---
+
+## 四、空域和飞行活动管理 ⭐
+
+### 管制空域（需申请）
+
+真高 **120 米以上** + 以下区域：
+
+| 区域类型 | 示例 |
+|---------|------|
+| 机场周边 | 机场及一定范围 |
+| 军事区域 | 军事禁区、管理区 |
+| 重要设施 | 发电厂、变电站、港口、铁路 |
+| 敏感区域 | 核设施、易燃易爆品区域 |
+| 边境 | 国界线、实际控制线 |
+
+### 适飞空域（无需申请）
+
+管制空域以外 = 适飞空域，微型/轻型/小型无人机在此飞行**无需申请**。
+
+### 飞行活动申请
+
+- 拟飞行前 **1 日 12 时前** 向 UOM 平台申请
+- 管理机构 **1 日 21 时前** 作出决定
+- **未经批准不得在管制空域飞行**
+
+### 隔离飞行 vs 融合飞行
+
+- **隔离飞行**：无人机与有人机**不同时**在同一空域
+- **融合飞行**：**同时**在同一空域（需批准）
+
+### 电子围栏
+
+- 小型、中型、大型**必须安装**
+- 重点地区和机场净空区的轻型**必须安装**
+
+---
+
+## 五、行为规范与避让规则
+
+### 行为规范
+
+1. 保持视距内飞行（微型）
+2. 夜间/低能见度 → 开启灯光
+3. **酒后 8 小时内**不得操控
+4. 超视距飞行 → 掌握其他飞行器动态
+5. 不得在药物影响下操控
+
+### 避让规则
+
+```
+有人机 > 无动力航空器 > 地面/水上交通工具
+单架 < 集群（单架避让集群）
+微型 < 其他无人机
+```
+
+---
+
+## 六、法律责任 ⭐
+
+### 常见违规处罚
+
+| 违规行为 | 处罚 |
+|---------|------|
+| 未经实名登记飞行 | ≤ 200 元，情节严重 2000-20000 元 |
+| 无证操控（需持证机型） | 5000-50000 元，情节严重 1-10 万元 |
+| 超出执照范围操控 | 2000-20000 元 + 暂扣 6-12 个月 |
+| 管制空域内未经批准飞行 | ≤ 500 元，情节严重没收 + 1000-10000 元 |
+| 改变出厂性能未更新信息 | 拒不改正 2000-20000 元 |
+| 非法拥有/使用反制设备 | ≤ 5 万元，情节严重 5-20 万元 |
+
+---
+
+## 七、航空器知识 ⭐
+
+### GNSS 系统
+
+包括：**北斗（BDS）、GPS、GLONASS、伽利略（GALILEO）**
+
+GNSS 信号弱的影响：
+- 定位效果变差
+- 光照充足时视觉系统可替代定位
+
+### RTK（实时动态测量技术）
+
+- 厘米级定位精度
+- 由基准站 + 数据链 + 流动站组成
+- 精度随距离增加而降低
+
+### ADS-B 系统
+
+- 广播式自动相关监视
+- 实现飞行信息共享
+- **不能**控制无人机刹停
+
+### 通信频段
+
+**2.4 GHz** 和 **5.8 GHz**，可智能切换
+
+### 电池管理
+
+| 参数 | 值 |
+|------|---|
+| 能量单位 | 瓦时（Wh） |
+| 容量单位 | 毫安时（mAh） |
+| 充电温度 | 5°C ~ 40°C |
+| 存储电量 | 40% ~ 60% |
+| 自放电保护 | 满电若干天后降至 60% |
+
+### 姿态模式（ATTI）
+
+GNSS 信号差 + 指南针受干扰 + 视觉不满足条件时进入：
+- **水平方向漂移**
+- **无法定点悬停**
+- **无法自主刹车**
+- → 尽快降落！
+
+### 自动返航触发条件
+
+- 电池电量不足
+- 遥控器失联
+- 图传信号丢失
+- 操控员主动开启
+
+### 返航高度设置
+
+**必须高于周围最高建筑物的高度**
+
+---
+
+## 八、安全使用知识 ⭐
+
+### 飞行前检查清单
+
+1. ✅ 查询限飞禁飞区域
+2. ✅ 查看天气（大风/雨雪/大雾不飞）
+3. ✅ 等待良好 GNSS 信号
+4. ✅ 检查机身/电机/电池/桨叶/遥控器
+5. ✅ 选择开阔地面，对尾起飞
+6. ✅ 移除保护罩
+7. ✅ 确认电池电量
+8. ✅ 检查螺旋桨安装正确且完好
+
+### 特殊环境飞行
+
+| 环境 | 注意事项 |
+|------|---------|
+| **夏季高温** | 飞行后**禁止立刻充电**（电池>40°C） |
+| **高原地区** | 减少载重、缓慢飞行、更换高原桨 |
+| **山区** | 信号阻挡、乱流、磁场干扰指南针 |
+| **低温环境** | 电池预热、悬停1分钟加热、抗风能力减弱 |
+| **高压线附近** | 干扰信号、视觉系统可能失效 |
+
+### 电池安全
+
+- ❌ 鼓包/漏液 → **严禁使用**
+- ❌ 摔落/撞击 → **不可再用**
+- ❌ 接触液体 → **不可再用**
+- ❌ 强静电/磁场 → 保护板失灵
+- ✅ 长期存放：40%-60%，每 3 个月充放电一次
+
+### 指南针校准注意事项
+
+- 校准时**不要携带铁磁物质**（手机等）
+- 避开：磁矿、停车场、地下钢筋建筑区域
+- 多次失败 → **转移位置**再校准
+
+### 信号中断处理
+
+- **遥控器信号中断** → 调整天线，等待返航，**不要胡乱打杆**
+- **图传中断但数据还在** → 开启自动返航或手动操控返航
+- **大风中** → 降低高度，尽快返航或就近降落
+
+---
+
+## 🔗 关联资源
+
+- [[无人机CAAC执照]]（证书体系概览）
+- [[无人机考证-中型多旋翼知识点]]（完整知识点手册）
+- [[CAAC无人机理论考试1300题讲解]]（B站视频课程研究）
+
+---
+
+*研究完成，2026-05-02 | CAAC 多旋翼理论基础知识完整整理*

wiki/Projects/无人机CAAC执照考试官方攻略.md

@@ -0,0 +1,191 @@
+---
+created: 2026-05-02
+type: source
+tags: [无人机, CAAC, 执照考试, 报考流程, UOM平台, 理论考试, 实践考试, 官方攻略]
+source: "https://mp.weixin.qq.com/s/osybdMMCBVsvuDFc5vdXPg"
+author: 陈右东（编辑）
+---
+
+# 一文读懂｜CAAC 无人机执照考什么？怎么考？（官方攻略）
+
+> 来源：微信公众号
+> 链接：<https://mp.weixin.qq.com/s/osybdMMCBVsvuDFc5vdXPg>
+> 依据：《民用无人驾驶航空器操控员执照考试管理办法》
+> 发布：中国民用航空局飞行标准司
+> 归档时间：2026-05-02
+
+---
+
+## 📌 两个核心考试
+
+| 考试 | 内容 | 形式 |
+|------|------|------|
+| **理论考试** | 无人机航空知识 | 闭卷，全是选择题 |
+| **实践考试** | 实操技能（综合问答、口试、实践飞行、地面站） | 现场操作 |
+
+---
+
+## 01 理论考试
+
+### 一、谁可以考？
+
+1. 持有效身份证件
+2. 完成相应等级培训，由**授权教员**签字认可能力
+3. 补考需教员再次签字证明已补训
+
+### 二、怎么报名？
+
+- 通过 **UOM 平台**（民用无人驾驶航空器综合管理平台）
+- 自行或通过机构报名
+- 至少提前 **5 天** 提交申请
+
+### 三、考试当天注意
+
+| 事项 | 要求 |
+|------|------|
+| 到达时间 | 提前 **30 分钟** |
+| 证件 | 身份证/护照/户籍证明 |
+| 草稿纸 | 不得自带，需向监考申请，考完留下 |
+| 离场 | 中途离开视为**主动结束考试** |
+
+### 四、考不过/缺考
+
+| 情形 | 后果 |
+|------|------|
+| **缺考** | **28 天后**才能再约考 |
+| **补考** | **28 天后**可重新报考同一科目 |
+
+### 五、考什么？
+
+**形式**：机考，选择题
+
+**考试范围**：
+1. 航空法规
+2. 无人机知识
+3. 飞行性能
+4. 气象
+5. 操作程序
+6. 飞行原理
+7. 无线电
+8. 应急处置
+9. 教学法知识（**教员等级加考**）
+
+---
+
+## 02 实践考试
+
+### 一、谁可以考？
+
+1. 完全民事行为能力 + 身份证件
+2. 理论考试通过后 **24 个月内** 申请
+3. 完成飞行训练，教员签字证明
+4. 补考需重新完成补充训练并签字
+
+### 二、报名与入场
+
+- 同样通过 UOM 平台提前 **5 天** 报名
+- 提前 30 分钟到
+- 带身份证 + **对应无人机设备**供检查
+
+### 三、考试顺序
+
+| 等级 | 顺序 |
+|------|------|
+| **非教员** | 先综合问答 → 通过后考飞行/地面站 |
+| **教员** | 先飞行 → 后口试 |
+
+### 四、补考与有效期 ⭐
+
+| 情形 | 间隔 |
+|------|------|
+| **缺考** | **14 天后**可再约 |
+| **补考** | **14 天后**可申请 |
+
+⚠️ **关键限制**：
+
+> 实践考试从**第一科通过起**，有效期只有 **60 天**！
+> 必须在这段时间内通过所有科目，否则**全部重考**。
+
+### 五、考什么？
+
+#### 综合问答（执照/超视距）
+
+- **10 道选择题**
+- **20 分钟**
+- **7 分及格**
+
+#### 口试（教员等级）
+
+- 面对面问答
+- **5 道题**，答对 **3 道**通过
+
+#### 地面站（超视距）
+
+分为四个阶段，**逐阶段通过**：
+1. 预先准备
+2. 飞行前准备
+3. 飞行实施
+4. 飞行后讲评
+
+**考试范围**：
+- 无人机系统基础知识
+- 操控原理
+- 动力系统选配
+- 通用与应急操作程序
+- 教学能力（教员等级）
+
+---
+
+## 📊 考试流程总览
+
+```
+报名（UOM 平台，提前 5 天）
+  ↓
+理论考试（机考，选择题）
+  ↓ 通过后 24 个月内
+实践考试（综合问答 → 飞行/地面站）
+  ↓ 60 天内通过全部科目
+获取执照
+```
+
+---
+
+## 🔢 关键数字速记
+
+| 项目 | 数值 |
+|------|------|
+| 报名时间 | 提前 **5 天** |
+| 到场时间 | 提前 **30 分钟** |
+| 理论缺考/补考间隔 | **28 天** |
+| 实践缺考/补考间隔 | **14 天** |
+| 实践考试有效期 | **60 天**（从首科通过起） |
+| 理论成绩有效期 | **24 个月** |
+| 综合问答题数 | **10 题** |
+| 综合问答时长 | **20 分钟** |
+| 综合问答及格分 | **7 分** |
+| 口试题数 | **5 题**，对 **3 题**通过 |
+| 地面站阶段数 | **4 个阶段**（逐阶段通过） |
+
+---
+
+## 🌐 官方资源
+
+- **UOM 平台**：民用无人驾驶航空器综合管理平台
+- **考点数量**：83 个
+- **培训机构**：3149 个
+
+> 所有考试安排、考点信息、认证培训机构名单，都可在 UOM 官网查询。
+
+---
+
+## 🔗 关联资源
+
+- [[无人机CAAC执照]]（证书体系概览）
+- [[无人机考证-中型多旋翼知识点]]（完整知识点手册）
+- [[CAAC无人机理论考试1300题讲解]]（B站视频课程）
+- [[无人机CAAC执照理论基础知识]]（法规+系统+安全）
+- [[无人机CAAC口诀与高频考点]]（81条口诀）
+
+---
+
+*研究完成，2026-05-02 | CAAC 无人机执照官方考试攻略，报考全流程梳理*

wiki/Projects/无人机雷达波测流误差分析.md

@@ -0,0 +1,219 @@
+---
+created: 2026-05-02
+type: concept
+tags: [无人机, 雷达波测流, 误差分析, 水文测量, 表面流速, 多普勒雷达]
+---
+
+# 无人机雷达波测流误差分析
+
+> 无人机搭载雷达波流速仪进行水面流速测量的误差来源与控制
+> 归档时间：2026-05-02
+
+---
+
+## 📌 雷达波测流原理
+
+**多普勒效应**：雷达波照射水面，水面粗糙元（波纹、微结构）反射回波，产生多普勒频移，频移大小与水面运动速度成正比。
+
+```
+f_d = 2 × v × cos(θ) / λ
+
+其中：
+f_d = 多普勒频移
+v = 水面流速
+θ = 雷达波束入射角
+λ = 雷达波长
+```
+
+**流速计算**：
+```
+v = f_d × λ / (2 × cos(θ))
+```
+
+---
+
+## 🔍 误差来源分析
+
+### 1. 几何误差（系统误差）
+
+#### 1.1 入射角误差
+
+雷达波束与水面法线的夹角 θ 测量不准会直接导致流速计算误差：
+
+```
+Δv/v = tan(θ) × Δθ
+
+当 θ = 45° 时，tan(45°) = 1，
+Δθ = 1° → 相对误差 ≈ 1.7%
+Δθ = 3° → 相对误差 ≈ 5.2%
+```
+
+**控制措施**：
+- 高精度 IMU 测定姿态角（精度 ≤ 0.1°）
+- 雷达安装角度标定
+
+#### 1.2 波束展宽误差
+
+雷达波束有一定宽度（通常 3-12°），照射区域内的流速不均匀会导致测量值偏差：
+
+```
+波束宽度 β = 6°
+流速梯度大时，误差可达 2-5%
+```
+
+#### 1.3 飞行高度影响
+
+无人机高度影响照射面积：
+```
+照射面积 A ≈ π × (H × tan(β/2))²
+
+H = 10m, β = 6° → A ≈ 0.009 m²（小，误差小）
+H = 50m, β = 6° → A ≈ 0.22 m²（大，空间平均效应）
+```
+
+### 2. 物理误差（环境误差）
+
+#### 2.1 风对水面粗糙元的影响
+
+风会改变水面粗糙元的运动速度，导致雷达测量的"表观流速"≠真实水流速度：
+
+```
+v_表观 = v_水流 + v_风影响
+
+风速 5 m/s 时，影响可达 0.1-0.3 m/s
+风速 10 m/s 时，影响可达 0.3-0.6 m/s
+```
+
+**控制措施**：
+- 选择无风或微风条件（<3 m/s）
+- 建立风-流速修正模型
+
+#### 2.2 波浪影响
+
+水面波浪会产生附加多普勒频移：
+- 长波（>1m）影响较小
+- 短波（<0.5m）影响显著，误差可达 0.2-0.5 m/s
+
+#### 2.3 水流垂直分量
+
+雷达波仅测量沿波束方向的分量，垂直方向的流速分量无法测量：
+- 适用于均匀流，误差小
+- 湍流、漩涡区域误差大
+
+### 3. 仪器误差
+
+#### 3.1 多普勒频移测量精度
+
+| 参数 | 典型值 | 对应流速误差 |
+|------|--------|------------|
+| 频率分辨率 | 0.1 Hz | ±0.01-0.02 m/s |
+| 采样率 | 100 Hz | ±0.05 m/s |
+| 信噪比 > 20 dB | 良好 | ±0.03 m/s |
+| 信噪比 < 10 dB | 差 | ±0.1-0.3 m/s |
+
+#### 3.2 姿态传感器精度
+
+| 传感器 | 精度 | 对流速误差影响 |
+|--------|------|-------------|
+| IMU 倾角 | ±0.1° | ±0.5-1% |
+| IMU 偏航 | ±0.5° | ±1-2% |
+| GPS 定位 | ±1 m | 高度标定误差 |
+
+#### 3.3 时钟漂移
+
+采样时钟漂移会导致频率测量偏差，通常影响 < 0.1%。
+
+### 4. 数据处理误差
+
+#### 4.1 频谱分析误差
+
+```
+FFT 频谱分辨率：Δf = fs / N
+fs = 100 Hz, N = 1024 → Δf ≈ 0.1 Hz
+对应流速误差：±0.01-0.02 m/s
+```
+
+#### 4.2 平均时间选择
+
+```
+平均时间太短 → 统计不充分，误差大
+平均时间太长 → 忽略流速变化，响应慢
+推荐：10-30 秒
+```
+
+---
+
+## 📊 综合精度评估
+
+### 典型误差预算
+
+| 误差源 | 误差贡献 | 权重 |
+|--------|---------|------|
+| 入射角测量 | ±1-2% | 25% |
+| 风影响 | ±0.1-0.5 m/s | 30% |
+| 波束展宽 | ±1-3% | 15% |
+| 频谱分析 | ±0.01-0.05 m/s | 10% |
+| 姿态传感器 | ±0.5-1% | 10% |
+| 波浪影响 | ±0.1-0.3 m/s | 10% |
+
+### 总精度
+
+```
+低流速（<1 m/s）：相对误差 5-10%
+中流速（1-3 m/s）：相对误差 3-8%
+高流速（>3 m/s）：相对误差 2-5%
+```
+
+**综合精度**：
+- **绝对误差**：±0.05-0.3 m/s
+- **相对误差**：±3-10%（取决于流速大小）
+
+---
+
+## 🔧 误差控制建议
+
+### 最佳测量条件
+
+| 参数 | 推荐值 | 原因 |
+|------|--------|------|
+| 风速 | < 3 m/s | 减少风对粗糙元的影响 |
+| 波浪高度 | < 0.1 m | 减少波浪附加频移 |
+| 飞行高度 | 10-30 m | 平衡照射面积与信噪比 |
+| 入射角 | 30-60° | 最佳几何条件 |
+| 平均时间 | 10-30 秒 | 统计稳定 |
+| 水面条件 | 有天然粗糙元 | 保证回波质量 |
+
+### 标定与验证
+
+1. **实验室标定**：静水槽中验证仪器精度
+2. **现场比对**：与 ADCP/流速仪同步测量
+3. **交叉验证**：多传感器（雷达+视频）交叉验证
+
+---
+
+## 📈 雷达波测流 vs 视频测流误差对比
+
+| 维度 | 雷达波测流 | 视频测流（LSPIV/ByteTrack） |
+|------|-----------|---------------------------|
+| **系统误差** | 入射角、波束展宽 | 相机畸变、像素标定 |
+| **环境误差** | 风、波浪 | 光照、反光、遮挡 |
+| **仪器误差** | 频率分辨率、信噪比 | 帧率、分辨率、传感器 |
+| **典型绝对误差** | ±0.05-0.3 m/s | ±0.02-0.1 m/s（全局快门） |
+| **典型相对误差** | 3-10% | 2-8% |
+| **适用流速范围** | 0.1-5 m/s | 0.1-5 m/s |
+| **是否需要示踪物** | ❌ 天然粗糙元即可 | ✅ 需漂浮物或投放示踪物 |
+| **全天候能力** | ✅ 雨雾可用 | ❌ 雨雾不可用 |
+| **夜间能力** | ✅ 可用 | ❌ 需补光 |
+
+---
+
+## 📝 行业标准参考
+
+根据 **SL/T 246-2019**《水文测验规范》：
+- 表面流速测量精度要求：±5%
+- 流量计算精度要求：±8%
+- 雷达波测流可满足要求，但需严格控制测量条件
+
+---
+
+*研究完成，2026-05-02 | 无人机雷达波测流误差来源与控制方案整理*

wiki/Projects/软考高项冲刺-知识点.md

@@ -101,6 +101,23 @@ exam_date: 2026-05-24
 
 ## 🏗️ 二、项目管理知识体系 ⭐核心（占 47%）
 
+### 2.0 8 大绩效域（PMBOK 第七版）⭐新增
+
+> **绩效域 = 宏观战略地图（价值实现）** | **10大知识领域 = 施工蓝图（过程控制）**
+
+| 绩效域 | 口诀 | 对应知识领域/过程组 | 详情 |
+|--------|------|-------------------|------|
+| [[团队绩效域]] | 团33：共享所有绩效，文化领导绩效 | 资源管理 | [详情](高项知识领域/绩效域/团队绩效域.md) |
+| [[干系人绩效域]] | 干46：惨痛满无负，十里分忧参督 | 干系人管理、沟通管理 | [详情](高项知识领域/绩效域/干系人绩效域.md) |
+| [[不确定性绩效域]] | 不74：了解识别依赖预测负面改进储备 | 风险管理 | [详情](高项知识领域/绩效域/不确定性绩效域.md) |
+| [[测量绩效域]] | 度46：充分理解及时决策 | 监控过程组 | [详情](高项知识领域/绩效域/测量绩效域.md) |
+| [[规划绩效域]] | 规58：腿细城内挑 | 规划过程组 | [详情](高项知识领域/绩效域/规划绩效域.md) |
+| [[交付绩效域]] | 交53：战果手里满 | 质量管理、范围管理 | [详情](高项知识领域/绩效域/交付绩效域.md) |
+| [[项目工作绩效域]] | 工78：高湿干物采变雪 | 执行过程组 | [详情](高项知识领域/绩效域/项目工作绩效域.md) |
+| [[开发方法与生命周期绩效域]] | 开34：妇联租借发宣泄 | 整合管理 | [详情](高项知识领域/绩效域/开发方法与生命周期绩效域.md) |
+
+**12 大原则口诀：关键干架，互领材质，复风韧变**
+
 ### 2.1 五大过程组
 
 | 过程组 | 说明 | 核心输出 |
@@ -518,7 +535,20 @@ ROI = (收益 - 成本) / 成本 × 100%
 | 风险应对 | 4 种威胁 + 3 种机会 |
 | 合同类型 | 总价/成本补偿/工料 |
 
-### 7.3 冲刺策略
+### 7.3 8 大绩效域速记
+
+| 绩效域 | 口诀 | 核心要点 |
+|--------|------|----------|
+| 团队 | 团33 | 共享责任、高绩效团队、领导力技能 |
+| 干系人 | 干46 | 识别→理解→参与→监督，权力/利益方格 |
+| 不确定性 | 不74 | 风险/模糊性/复杂性，应急+管理储备 |
+| 测量 | 度46 | 度量指标+霍桑效应陷阱 |
+| 规划 | 规58 | 估算/团队/沟通/采购/变更规划 |
+| 交付 | 交53 | 价值交付+可交付成果+质量 |
+| 项目工作 | 工78 | 变更控制/学习/采购/沟通/资源 |
+| 开发方法 | 开34 | 预测vs适应，交付节奏 |
+
+### 7.4 冲刺策略
 
 | 科目 | 策略 |
 |------|------|

wiki/Projects/高项知识领域/十大管理/质量管理.md

@@ -0,0 +1,86 @@
+---
+created: 2026-04-29
+type: knowledge
+tags: [软考高项, PMBOK, 质量管理]
+source: 十大管理.xmind
+---
+
+# 质量管理
+
+> 核心：确定项目质量的方针、目标、职责，通过质量规划、保证、控制、改进来实现
+
+## 3 大过程
+
+### 1. 规划质量管理
+
+**定义**：识别项目可交付成果验收的质量要求、标准，并书面描述项目符合质量要求的证明
+
+**输入**：项目章程、项目管理计划、项目文件
+
+**工具**：
+- 数据收集（**标杆对照**）
+- 数据分析（**成本效益分析**、**质量成本**）
+  - **质量成本（COQ）**：找预防成本和评估成本的投资平衡点，用于规避失败成本
+- 数据表现：
+  - **流程图**（SIPOC：供应商→输入→流程→输出→客户，全景视角）
+  - 逻辑数据模型
+  - **矩阵图**（行列交叉展示因素和目标的强弱关系）
+  - 思维导图、鱼骨图
+- **测试与检查的规划**：α测试、β测试
+
+**输出**：
+- 质量管理计划
+- 质量测量指标
+- 质量核对单
+
+### 2. 管理质量（QA）
+
+### 3. 控制质量（QC）
+
+## 高频考点
+
+### 质量测量指标示例
+
+| 指标 | 说明 |
+|------|------|
+| 网络时延 | 性能指标 |
+| 易用性 | 用户体验 |
+| 事件报警精度 | 准确性 |
+
+### 质量核对单
+
+| 核对项 | 结果 | 备注 |
+|--------|------|------|
+| ... | ✓/✗ | ... |
+
+### QA（质量保证）职责
+
+- **过程辅导**：为项目组提供过程指导
+- **过程审计**：公司内部质量审计
+- **过程改进**：收集数据，数据分析，提出项目质量提升建议
+- **过程度量**
+
+### 管理质量 vs 控制质量
+
+| | 管理质量（QA） | 控制质量（QC） |
+|--|---------------|---------------|
+| 导向 | 过程导向（预防） | 结果导向（检查） |
+| 时机 | 过程中 | 完成后 |
+| 目标 | 确保过程正确 | 确保结果正确 |
+
+### 如何提升项目质量
+
+1. 做好人员培训
+2. 严格执行质量管理计划
+3. 持续过程改进
+4. 加强质量审计
+
+### 质量管理 vs 其他管理
+
+- **范围**：质量的基础，质量核对单里有范围基准定义的验收标准
+- **成本**：质量测量指标影响成本高低，质量成本构成成本
+- **进度**：在高质量和完成时间中找平衡
+
+---
+
+*基于《十大管理》XMind 整理*

wiki/Resources/方法论/机器学习.md

@@ -0,0 +1,53 @@
+---
+created: 2026-04-28
+type: concept
+tags: [机器学习，AI，监督学习，无监督学习]
+---
+
+# 机器学习（Machine Learning）
+
+> 让计算机从数据中自动学习规律，无需显式编程
+
+## 定义
+
+机器学习是人工智能的一个子领域，研究如何通过算法让计算机从数据中学习模式，并用这些模式进行预测或决策。
+
+## 三大范式
+
+| 范式 | 说明 | 典型任务 |
+|------|------|---------|
+| [[监督学习]] | 从标注数据中学习映射 | 分类、回归 |
+| [[无监督学习]] | 从未标注数据中发现结构 | 聚类、降维 |
+| [[强化学习]] | 通过与环境交互学习策略 | 游戏 AI、机器人控制 |
+
+## 工作流程
+
+```
+数据收集 → 数据预处理 → 特征工程 → 模型训练 → 模型评估 → 部署
+```
+
+## 核心概念
+
+| 概念 | 说明 |
+|------|------|
+| 特征（Feature） | 输入数据的属性 |
+| 标签（Label） | 要预测的目标值 |
+| 过拟合（Overfitting） | 模型记住了训练数据的噪声 |
+| 泛化（Generalization） | 模型在新数据上的表现 |
+| [[反向传播]] | 神经网络训练的核心算法 |
+
+## 与深度学习的区别
+
+- **机器学习**：包含所有从数据中学习的算法（包括简单算法如线性回归、决策树）
+- **深度学习**：机器学习的子集，特指使用多层[[神经网络]]的方法
+
+## 相关概念
+
+- [[神经网络]] / [[深度学习]]
+- [[监督学习]] / [[无监督学习]] / [[强化学习]]
+- [[Transformer 架构]]
+- [[RAG]]
+
+---
+
+*基于 AI 基础知识整理*

wiki/concepts/无人机雷达波测流误差分析-mindmap.md

@@ -0,0 +1,157 @@
+---
+
+mindmap-plugin: markdown
+
+---
+
+
+# 无人机雷达波测流误差分析
+
+
+> 无人机搭载雷达波流速仪（Radar Surface Velocimeter）利用多普勒效应测量水面流速，存在多维度误差源
+
+
+## 测量原理
+
+- 雷达波束照射水面，利用**多普勒频移**计算表层流速（0-5cm 深度）
+- 需通过**表面流速系数 K**（通常 0.7~0.9）换算为垂线平均流速
+- 结合断面测量推算流量
+
+## 实测方案：DJI M400 + X-PORT 增稳云台
+
+
+### 硬件配置
+
+
+| 组件 | 型号/参数 | 作用 |
+|------|----------|------|
+| 无人机平台 | 大疆 M400（Matrice 400） | 四旋翼行业级旗舰平台，RTK 定位，IP55 防护 |
+| 增稳云台 | X-PORT 三轴增稳云台 | 机械隔离振动 + 三轴主动增稳（俯仰/横滚/航向） |
+| 载荷 | 雷达波流速仪 | 通过 X-PORT 标准接口挂载 |
+
+
+### X-PORT 对平台误差的优化效果
+
+
+| 原误差项        | 优化前            | X-PORT 优化后  | 优化原理                         |
+| ----------- | -------------- | ----------- | ---------------------------- |
+| **悬停姿态角偏差** | 5°~10° 波动      | **<0.5°**   | 三轴陀螺仪实时补偿，主动抵消横滚/俯仰          |
+| **机身振动传递**  | 螺旋桨振动直接传导      | **衰减 >90%** | 云台减震球 + 电机主动消振，隔离高频噪声        |
+| **高度波动**    | GPS 高度漂移 ±1~2m | **<0.3m**   | RTK 定高 + 云台俯仰轴锁定照射点          |
+| **波束指向偏差**  | 随风向飘移          | **航向锁定**    | X-PORT 航向轴（Yaw）主动稳像，保持波束正对水流 |
+
+
+### M400 平台自身优势（数据来源：DJI 官网）
+
+
+| 特性 | 官方参数 | 对测流的增益 |
+|------|---------|-------------|
+| **四旋翼架构** | 4 电机四旋翼布局 | 结构简洁，维护成本低，飞行稳定性好 |
+| **RTK 厘米级定位** | 水平 ±1cm + 1ppm，垂直 ±1.5cm + 1ppm | 平台位移误差从 0.5~2m 降至 **<5cm**，流速叠加误差可忽略 |
+| **59min 最大续航** | 空载无风环境 | 支持多断面连续测量，实际载荷下约 40~45min，作业效率高 |
+| **6kg 最大载重** | 可挂载 Zenmuse L3 等重型负载 | 雷达流速仪 + 激光测距仪/摄像头一次飞行完成多任务 |
+| **IP55 防护等级** | 防尘防喷水 | 可在小雨环境作业，扩展了测量窗口 |
+| **O4E 图传** | 行业增强版，支持空中中继 | 远距离作业实时监视图传画面 |
+| **激光 + 毫米波避障** | 电线级精细避障 | 复杂环境（桥梁、电线附近）安全作业 |
+
+
+### 综合精度提升对比
+
+
+| 工况             | 优化前误差    | M400+X-PORT 优化后 | 改善幅度      |
+| -------------- | -------- | --------------- | --------- |
+| 理想条件（无风/平静水面）  | 3%~8%    | **2%~5%**       | ↓ 30%~40% |
+| 一般条件（2~3级风）    | 8%~15%   | **4%~8%**       | ↓ 40%~50% |
+| 恶劣条件（4~5级风/小雨） | 15%~30%+ | **8%~15%**      | ↓ 40%~50% |
+
+
+> 📌 X-PORT 主要解决**平台误差**（第 2 类），对表面系数 K 误差（第 1 类）和风生流误差（第 3 类）无直接改善。
+
+
+## 五类误差来源
+
+
+### 1. 雷达原理误差
+
+
+| 误差项         | 说明                   | 影响          |
+| ----------- | -------------------- | ----------- |
+| 表面流速系数 K 误差 | 表层→平均流速的换算系数取值不准     | ★★★★★ 最大误差源 |
+| 布拉格散射偏差     | 无风/平静水面散射信号弱，低流速信号丢失 | ★★★★        |
+| 波束展宽效应      | 波束张角 10°~30°，斑区内流速不均 | ★★★         |
+
+
+### 2. 无人机平台误差
+
+
+| 误差项      | 说明                          | 影响    |
+| -------- | --------------------------- | ----- |
+| 悬停姿态角偏差  | 横滚/俯仰导致入射角偏离，5°偏差≈0.4% 速度误差 | ★★★★★ |
+| 平台位移（漂流） | GPS 悬停精度 0.5~2m，未补偿时叠加到流速中  | ★★★★★ |
+| 机身振动     | 螺旋桨振动引入高频噪声，低流速时明显          | ★★★★  |
+| 高度波动     | 改变照射面积和信号强度                 | ★★★   |
+
+
+### 3. 环境因素误差
+
+
+| 误差项    | 说明                          | 影响    |
+| ------ | --------------------------- | ----- |
+| 风场影响   | 风生流 + 改变散射强度，3~4级风偏差 5%~15% | ★★★★★ |
+| 水面波浪   | 波速与流速多普勒信号混叠                | ★★★★  |
+| 降雨     | 雨滴冲击产生额外散射噪声                | ★★★   |
+| 漂浮物/水草 | 运动速度≠水流速度                   | ★★★   |
+
+
+### 4. 几何与标定误差
+
+
+| 误差项 | 说明 | 影响 |
+|--------|------|------|
+| 入射角标定误差 | 直接影响 cosθ 速度计算 | ★★★★ |
+| 波束指向偏差 | 未正对水流方向，测到的是投影分量 | ★★★★ |
+| 断面测量误差 | 流量=流速×断面积，断面不准放大误差 | ★★★★ |
+
+
+### 5. 数据处理误差
+
+
+| 误差项 | 说明 | 影响 |
+|--------|------|------|
+| 流速分布模型选择 | 对数律/指数律与实际不符 | ★★★★ |
+| 采样时间不足 | 积分时间短导致随机波动大 | ★★★ |
+
+
+## 综合精度
+
+
+| 工况 | 综合误差 |
+|------|---------|
+| 理想条件（无风/平静水面） | 3%~8% |
+| 一般条件（2~3级风） | 8%~15% |
+| 恶劣条件（大风/降雨） | 15%~30%+ |
+
+
+## 减小误差措施
+
+
+### 硬件级
+
+1. **DJI M400 + X-PORT 增稳云台**（推荐方案）
+    - 三轴主动增稳将姿态角偏差降至 <0.5°
+    - 减震系统隔离 >90% 机身振动
+    - RTK 厘米级定位消除平台位移误差
+    - IP55 防护扩展小雨作业窗口
+2. **大机型抗风**：无 M400 时选用 ≥2kg 级机型，提高悬停稳定性
+3. **双载荷同步**：雷达流速仪 + 激光测距仪一次飞行完成流速+断面
+
+### 软件级
+
+1. **RTK + IMU 姿态补偿**：实时记录姿态角，软件修正入射角（无云台时必备）
+2. **多断面多点测量**：减少单点偶然误差
+3. **ADCP 同步比测**：定期标定表面系数 K
+
+### 作业策略
+
+1. **选择测量窗口**：避开大风大雨洪水剧烈变化期
+2. **固定入射角作业**：预设标准入射角（通常 45°），减少标定误差

专业领域/Web3DGS技术调研-汇报总结.md

@@ -0,0 +1,169 @@
+# Web3DGS 技术调研汇报总结
+
+---
+
+## 一、核心结论（Executive Summary）
+
+**推荐方案：SuperSplat / PlayCanvas**
+
+综合数据处理效率、渲染性能、渲染质量、功能完整性四个维度，SuperSplat 在各项对比中表现最优，建议作为项目的高斯泼溅渲染引擎。
+
+---
+
+## 二、技术背景
+
+### 2.1 什么是 3DGS
+
+3D Gaussian Splatting（3DGS）是一种革命性的实时辐射场渲染技术，将3D场景表示为大量微小的"高斯形状斑点"（Splat）集合，通过可微光栅化实现实时高质量渲染。相比 NeRF 方法，3DGS 兼具训练速度和渲染速度的优势。
+
+### 2.2 Web端核心挑战
+
+| 挑战    | 说明                   |
+| ----- | -------------------- |
+| 内存限制  | 浏览器可用内存远小于原生应用       |
+| 带宽限制  | 百万级Splat数据传输成为瓶颈     |
+| 渲染算力  | WebGL/WebGPU并行计算能力受限 |
+| 跨平台兼容 | 桌面、移动、VR设备算力差异巨大     |
+
+### 2.3 LOD 技术的关键作用
+
+LOD（细节层级）是解决上述挑战的核心技术，实现：
+- **场景规模扩展**：使亿级Splat超大场景渲染成为可能
+- **设备适配**：根据设备性能动态调整渲染负载
+- **带宽优化**：通过流式加载减少初始等待时间
+- **帧率稳定**：保持恒定渲染复杂度，避免性能抖动
+
+---
+
+## 三、主流方案对比
+
+### 3.1 方案概览
+
+|             方案              |    类型    |            技术栈             |          特点           |
+| :-------------------------: | :------: | :------------------------: | :-------------------: |
+| **Spark 2.0** (World Labs)  | 开源Web渲染器 |     Three.js + WebGL2      | 连续LOD、GPU虚拟显存、亿级Splat |
+|      **LCC** (XGRIDS)       |  商业化SDK  |           多平台SDK           |  空间分块+LOD耦合、Cesium集成  |
+| **SuperSplat** (PlayCanvas) | 开源编辑器+引擎 | PlayCanvas + WebGL2/WebGPU |    SOG格式、碰撞检测、轻量易用    |
+|        **Visionary**        |   学术研究   |       WebGPU + ONNX        |      每帧推理、插件式架构       |
+|        **gsplat.js**        |  开源通用库   |       类Three.js API        |      轻量级、基础LOD支持      |
+|     **FJD Trion** (丰疆)      |   商业软件   |            专有格式            |        需授权，未试用        |
+
+### 3.2 核心差异对比
+
+| 维度        | Spark 2.0                | LCC        | SuperSplat         |
+| --------- | ------------------------ | ---------- | ------------------ |
+| **渲染预算**  | 固定预算（桌面2.5M/移动500K~1.5M） | 分块LOD机制    | 全局预算管理             |
+| **文件格式**  | .RAD（渐进式传输）              | .lcc（紧凑编码） | .sog（空间有序）         |
+| **内存管理**  | GPU虚拟显存分页                | 压缩+LOD优化   | gsplat.splatBudget |
+| **LOD类型** | 连续LOD（树切面）               | 离散LOD+空间分块 | 离散LOD流式分块          |
+| **碰撞检测**  | 不支持                      | 需自行实现      | 内置体素碰撞数据生成         |
+| **最大场景**  | 1亿+Splat                 | 80万㎡场景验证   | 千万级Splat           |
+
+---
+
+## 四、实测数据
+
+### 4.1 测试场景
+
+| 场景   | 大小    | 来源      | 类型    |
+| ---- | ----- | ------- | ----- |
+| 西北大学 | 2.12G | LCC官方示例 | 外部大场景 |
+| 书店   | 404M  | LCC官方示例 | 内部小场景 |
+| 教堂   | 776M  | LCC官方示例 | 外部小场景 |
+| 台阶   | 1.38G | 中海达数据   | 外部场景  |
+
+### 4.2 测试设备
+
+- **低性能台式机H**：i7-9700 + AMD Radeon R7 430
+- **高性能台式机**：i9-10900K + RTX3070
+- **笔记本W**：i7-9700 + AMD Radeon R7 430
+
+### 4.3 数据处理效率
+
+| 方案 | 台阶场景处理时间 | 备注 |
+|------|-----------------|------|
+| Spark 2.0 | 较长（Rust源码需二次开发） | 部分PLY兼容性有问题 |
+| LCC | ~10秒（LCCEditor） | 存在视觉跳变问题 |
+| SuperSplat | 需二次开发（Node.js库） | 支持碰撞数据生成 |
+
+**碰撞数据生成时间**（笔记本W）：
+- 书店场景：~2分钟
+- 教堂场景：~3分40秒
+
+### 4.4 渲染性能排名
+
+**相同场景、相同模式、相同设备下：**
+
+1. **SuperSplat** — 性能最佳
+2. **LCC** — 与SuperSplat基本相当，部分情况略逊
+3. **Spark 2.0** — 性能表现最差
+
+> 注：LCC2在不同性能模式下表现基本无变化，可能有额外处理逻辑。
+
+### 4.5 渲染质量对比
+
+| 问题 | Spark 2.0 | LCC | SuperSplat |
+|------|-----------|-----|------------|
+| 视觉跳变 | 无 | 有（旋转视角出现模型漏洞） | 无 |
+| 性能模式模糊 | 正常 | 模糊 | 性能模式下模糊，标准及以上正常 |
+| 放大细节 | 可加载清晰细节 | 模糊 | 可加载清晰细节 |
+
+### 4.6 功能对比
+
+| 功能       | Spark 2.0 | LCC        | SuperSplat  |
+| -------- | --------- | ---------- | ----------- |
+| 碰撞检测数据生成 | 不支持       | 需自行实现      | 内置支持（体素八叉树） |
+| 第一人称行走   | 需自行实现     | 有API但需自行实现 | 内置支持        |
+| 点云渲染     | 不支持       | 不支持        | 引擎支持        |
+| Cesium集成 | 不支持       | 支持         | 不支持         |
+
+---
+
+## 五、技术趋势
+
+1. **连续LOD替代离散LOD**：消除视觉跳变，实现无缝过渡
+2. **流式传输标准化**：先展示低精度全局视图，再逐步细化
+3. **WebGL向WebGPU迁移**：计算着色器开启更复杂LOD算法可能
+4. **空间分块与LOD深度融合**：特别适合大地图、城市级实景
+5. **AI驱动智能LOD**：神经网络动态预测最优LOD配置
+
+---
+
+## 六、推荐方案及理由
+
+### 选择 SuperSplat 的核心理由
+
+1. **渲染性能最优** — 实测FPS最高，CPU/GPU耗时最低
+2. **碰撞检测内置** — 支持体素碰撞数据生成+第一人称行走
+3. **无视觉跳变** — 渲染质量稳定，无LCC的旋转漏洞问题
+4. **传输最快** — LOD数据最小，场景初始化最快
+5. **开源生态** — MIT协议，PlayCanvas引擎成熟
+
+### 待解决问题
+
+| 问题      | 说明                                           |
+| ------- | -------------------------------------------- |
+| LOD生成效率 | @playcanvas/splat-transform 需二次开发，当前为Node.js |
+| 碰撞数据质量  | 生成数据质量需进一步研究优化                               |
+| 点云渲染    | 引擎支持但Demo未实现                                 |
+| GIS大场景  | Cesium对3DGS LOD支持不足，仅LCC支持Cesium集成           |
+| 浏览器适配   | 不同手机和PC 浏览器兼容有差异                             |
+|         |                                              |
+
+---
+
+## 七、Hi-LiDAR 数据处理发布流程
+
+已基于 @playcanvas/splat-transform 搭建3DGS在线数据处理和演示系统：
+
+1. **数据接收** — 接收Hi-LiDAR推送 / 支持模型上传
+2. **LOD处理** — 支持自动/手动生成LOD数据
+3. **模型管理** — 在线预览和发布管理
+4. **分享能力** — 链接分享 + 二维码扫码在线查看
+5. **用户管理** — 集成中海达会员系统
+
+**Demo演示地址**：http://172.16.36.73:8092/
+
+---
+
+*汇报完毕，请审阅。*

工作记录/工作日志/未命名思维导图.md

@@ -0,0 +1,19 @@
+---
+
+mindmap-plugin: markdown
+
+---
+
+
+# 水文科研
+
+## 粤港澳大湾区水利创新中心
+
+- 2025-10月
+## 团队协作
+
+- 主体，协作单位
+## 研究方向
+
+- 水文
+- 水利