初始化：上传嵌入式知识库

.gitignore

+ai-public.rar

00_project_map/ai-entry-guide.md

+# AI Entry Guide
+
+AI 参与任务前，先判断任务级别。
+
+## Level 1: 随手辅助
+
+适合：解释代码、生成小函数、补一段测试、分析报错。
+
+记录方式：可以不建任务记录，由人工确认后使用。
+
+## Level 2: 模块内任务
+
+适合：修复明确 bug、新增局部功能、重构一组文件。
+
+记录方式：放到对应代码仓库的 `ai/03_task_runs/`。
+
+## Level 3: 跨模块任务
+
+适合：算法与 CBox 接口变化、CBox 与 g6 协议变化、集成流程变化。
+
+记录方式：公共部分放 `ai-public/40_integration_tasks/`，模块内部细节放各自代码仓库的 `_ai/`。
+
+## 代码修改原则
+
+AI 可以生成代码、补丁或直接修改本地工作区，但提交应由人工确认后完成。
+
+## 团队协作规范
+
+团队统一说明见 	eam-ai-workflow.md。
+

00_project_map/module-boundaries.md

+# Module Boundaries
+
+原则：共享接口，不共享内部实现。
+
+## 可以放到公共仓库的信息
+
+- 模块输入输出字段
+- API / 协议 / 数据格式
+- 错误码和状态码
+- 版本兼容策略
+- 跨模块性能约束
+- 集成测试要求
+- 对外可共享的领域知识
+
+## 不应放到公共仓库的信息
+
+- 算法核心实现逻辑
+- 模型参数、训练数据、实验记录
+- 私有源码和未公开补丁
+- 模块内部敏感设计
+- 只属于单个团队的调试记录
+
+## 跨模块协作规则
+
+跨模块变更应先更新 `20_interfaces/` 中的接口文档，确认后再分别进入各模块代码仓库实现。

00_project_map/project-overview.md

+# Project Overview
+
+VAServer 总项目由算法、CBox 软件、g6 嵌入式软件以及公共 AI 协作资料组成。
+
+## 模块
+
+- `algorithm`: 算法代码仓库，模块 AI 资料放在 `algorithm/_ai/`。
+- `cbox`: CBox / Analysis Service 软件代码仓库，模块 AI 资料放在 `cbox/_ai/`。
+- `g6`: g6 嵌入式 / Sensor 相关代码仓库，模块 AI 资料放在 `g6/_ai/`。
+
+## 公共 AI 协作仓库
+
+- `ai-public`: 公共 AI 资料，所有相关人员可读，只放架构、接口、规范、共享需求、集成任务和可共享知识。
+
+## 私有 AI 资料位置
+
+模块私有 AI 资料跟随代码仓库权限，统一放在各代码仓库的 `_ai/` 目录中。
+

00_project_map/repo-map.md

+# Repo Map
+
+| 仓库/目录 | 类型 | 主要用途 | 建议权限 |
+| --- | --- | --- | --- |
+| `ai-public` | AI 公共仓库 | 架构、接口、规范、共享知识库、集成任务 | 所有人可读，负责人/架构可写 |
+| `algorithm` | 代码仓库 | 算法源码、测试、构建；`_ai/` 放算法 AI 私有资料 | 算法组可见 |
+| `cbox` | 代码仓库 | CBox 软件源码、测试、部署；`_ai/` 放 CBox AI 私有资料 | 软件组可见 |
+| `g6` | 代码仓库 | g6 嵌入式源码、测试、构建；`_ai/` 放 g6 AI 私有资料 | 嵌入式组可见 |
+

00_project_map/team-ai-workflow.md

+# Team AI Workflow Guide
+
+本文档用于向团队说明 VAServer 项目的 AI 辅助开发目录结构、权限边界和使用规范。
+
+## 1. 总体原则
+
+VAServer 项目采用“公共 AI 资料 + 各代码仓库私有 _ai 目录”的方式组织 AI 辅助开发资料。
+
+核心原则：
+
+- 公共仓库只放跨团队可共享的信息。
+- 模块私有 AI 资料跟随代码仓库权限。
+- AI 默认是局部辅助工具，不改变原有人工开发、确认、提交流程。
+- AI 生成的代码、方案和文档必须经过人工确认。
+- 跨模块协作共享接口和行为，不共享内部实现。
+- AI 按 Superpower 模式使用团队共享 Skill：先加载项目上下文和规范，再执行任务。
+- 需求、设计、开发、测试四个过程都需要评审；重要任务必须留下评审结论。
+
+## 2. 顶层目录结构
+
+当前推荐结构：
+
+```text
+VAServer/
+  ai-public/        # 公共 AI 资料：架构、接口、规范、集成、共享知识、共享 Skills
+  algorithm/        # 算法代码仓库
+    _ai/            # 算法模块 AI 辅助资料，不参与编译
+  cbox/             # CBox / Analysis Service 代码仓库
+    _ai/            # CBox 模块 AI 辅助资料，不参与编译
+  g6/               # g6 嵌入式代码仓库
+    _ai/            # g6 模块 AI 辅助资料，不参与编译
+```
+
+## 3. ai-public 放什么
+
+`ai-public` 是公共 AI 协作资料区，所有相关团队可读。
+
+适合放：
+
+- 项目地图和仓库说明
+- 总体架构
+- 跨模块接口和协议
+- 共享需求
+- 集成任务
+- 通用编码规范
+- 通用 AI 编程规则
+- 团队共享 Codex Skills
+- 可共享领域知识
+
+不应放：
+
+- 算法核心实现逻辑
+- 模型参数、训练数据、实验记录
+- 模块私有源码
+- 模块内部敏感设计
+- 只属于单个团队的调试记录
+- 未确认的 AI 代码草稿
+
+## 4. 各项目 _ai 目录放什么
+
+每个代码仓库下的 `_ai/` 是本模块自己的 AI 辅助资料目录，权限跟随代码仓库。
+
+统一结构：
+
+```text
+_ai/
+  00_requirements/       # 本模块需求
+  01_prompts/            # 本模块常用 prompt
+  02_design/             # 本模块内部设计
+  03_task_runs/          # 重要 AI 任务记录
+  04_code_drafts/        # 未确认代码草稿、patch、diff
+  05_review_notes/       # 人工 review 和确认记录
+  90_standards/          # 本模块补充规范
+  93_knowledge_base/     # 本模块私有知识库
+  README.md
+```
+
+说明：`_ai/` 是辅助目录，不参与编译，不应被构建脚本当成源码目录处理。
+
+## 5. AI 辅助开发分级
+
+### Level 1: 随手辅助
+
+适合：解释代码、生成小函数、分析报错、补一段测试。
+
+处理方式：可以不建正式任务记录，人工确认后使用。
+
+### Level 2: 模块内任务
+
+适合：修复明确 bug、新增局部功能、重构一组文件、补充模块测试。
+
+处理方式：记录到对应项目的 `_ai/03_task_runs/`。
+
+建议一次任务一个目录：
+
+```text
+_ai/03_task_runs/2026-06-07-task-name/
+  input.md
+  plan.md
+  result.md
+  changed-files.md
+  test-result.md
+```
+
+### Level 3: 跨模块任务
+
+适合：算法与 CBox 接口变化、CBox 与 g6 协议变化、集成流程变化。
+
+处理方式：
+
+- 公共部分放到 `ai-public/40_integration_tasks/`。
+- 接口文档放到 `ai-public/20_interfaces/`。
+- 模块内部细节放到各自代码仓库的 `_ai/`。
+
+## 6. 代码修改和提交规则
+
+默认规则：
+
+1. 人工提出需求或选择任务。
+2. AI 使用 `$vaserver-development` 或读取 `ai-public/95_skills/vaserver-development/SKILL.md`。
+3. 需求评审：确认目标、验收标准、模块范围、接口影响和风险等级。
+4. 设计评审：确认实现方案、兼容性、回退、异常处理、日志和测试策略。
+5. 开发评审：确认改动范围符合设计，不破坏接口、配置、数据格式和风险控制要求。
+6. 测试评审：确认已运行测试、未运行原因、人工验证项和剩余风险。
+7. 人工 review AI 的最终改动。
+8. 人工运行或确认必要测试。
+9. 人工确认后提交代码。
+
+AI 默认不直接提交代码。提交权和最终责任在人工开发人员。
+
+## 7. 权限边界
+
+推荐权限：
+
+| 目录 | 可见范围 | 说明 |
+| --- | --- | --- |
+| `ai-public` | 所有相关团队 | 只放公共信息 |
+| `algorithm` / `algorithm/_ai` | 算法组 | 算法代码和算法私有 AI 资料 |
+| `cbox` / `cbox/_ai` | 软件组 | CBox 代码和软件私有 AI 资料 |
+| `g6` / `g6/_ai` | 嵌入式组 | g6 代码和嵌入式私有 AI 资料 |
+
+跨团队沟通时，优先通过 `ai-public/20_interfaces/` 和 `ai-public/40_integration_tasks/` 协作。
+
+## 8. 团队成员开始使用时先读哪些文件
+
+公共入口：
+
+1. `ai-public/00_project_map/project-overview.md`
+2. `ai-public/00_project_map/repo-map.md`
+3. `ai-public/00_project_map/module-boundaries.md`
+4. `ai-public/00_project_map/ai-entry-guide.md`
+5. `ai-public/00_project_map/team-ai-workflow.md`
+
+规范入口：
+
+0. 如果当前 AI 环境支持 Skill，优先使用 `ai-public/95_skills/vaserver-development/` 对应的 `$vaserver-development`。
+1. `ai-public/90_standards/ai-coding-rules-common.md`
+2. 对应模块的补充规则：
+   - 算法：`ai-public/90_standards/ai-coding-rules-algorithm.md`
+   - CBox：`ai-public/90_standards/ai-coding-rules-cbox.md`
+   - g6：`ai-public/90_standards/ai-coding-rules-g6.md`
+3. 各自项目 `_ai/README.md`
+
+## 9. 命名建议
+
+- 公共 AI 资料目录：`ai-public/`
+- 团队共享 Skill 目录：`ai-public/95_skills/skill-name/`
+- 项目内部 AI 辅助目录：`_ai/`
+- 任务记录目录：`YYYY-MM-DD-short-task-name`
+- 文档优先使用 Markdown：`.md`
+
+示例：
+
+```text
+algorithm/_ai/03_task_runs/2026-06-07-optimize-preprocess/
+cbox/_ai/03_task_runs/2026-06-07-fix-upload-timeout/
+g6/_ai/03_task_runs/2026-06-07-sensor-reconnect/
+```
+
+## 10. 一句话版本
+
+公共内容放 `ai-public`，共享 Skill 放 `ai-public/95_skills`，模块私有 AI 资料放各自代码仓库的 `_ai/`；AI 用 Skill 作为 Superpower，需求、设计、开发、测试逐步评审，代码最终由人工确认和提交。

90_standards/ai-coding-rules-algorithm.md

+# AI Coding Rules Algorithm
+
+算法模块 AI 补充规则：
+
+- 明确输入、输出、维度、单位和边界条件。
+- 涉及精度、稳定性、性能的修改必须标注验证方式。
+- 不把算法核心实现、模型参数、训练数据、实验记录放入公共仓库。
+- AI 适合辅助脚本、测试、接口包装、结果整理和局部分析。
+- 核心算法策略和关键参数必须由算法人员确认。
+- 涉及抓拍、误抓保护、接入信号异常、球机控制和算法验收指标的改动，必须按 `product-risk-control-standard.md` 做专项验证说明。

90_standards/ai-coding-rules-cbox.md

+# AI Coding Rules CBox
+
+CBox / Analysis Service AI 补充规则：
+
+- 优先保持接口兼容性和服务稳定性。
+- 异常处理、日志、配置和回滚路径要明确。
+- 涉及跨模块调用时，先检查 `20_interfaces/`。
+- AI 适合辅助接口适配、日志改进、测试补充、局部重构和 bug 排查。
+- 涉及上传、配置、升级、兼容性、日志、存储和异常恢复的改动，必须按 `product-risk-control-standard.md` 做专项检查。

90_standards/ai-coding-rules-common.md

+# AI Coding Rules Common
+
+通用规则：
+
+- AI 默认只做局部辅助，不改变原有代码管理流程。
+- AI 不直接提交代码，提交由人工确认后完成。
+- 修改前先阅读相关需求、接口文档、模块边界和现有代码。
+- 不擅自扩大修改范围。
+- 不把私有仓库内容写入公共仓库。
+- 接口变更必须先更新公共接口文档并经过确认。
+- 输出结果要说明改了什么、为什么改、测试情况和剩余风险。
+- 开发前阅读 `product-risk-control-standard.md`，涉及 S/A 级风险时必须说明保护机制、验证方式和回退方案。
+- 重要任务必须经过需求评审、设计评审、开发评审和测试评审；AI 应在结果中说明四个评审的结论或跳过原因。

90_standards/ai-coding-rules-g6.md

+# AI Coding Rules g6
+
+g6 / 嵌入式 AI 补充规则：
+
+- 注意内存、实时性、功耗、线程/中断和硬件约束。
+- 不擅自引入动态内存、阻塞等待或不可控延迟。
+- 涉及寄存器、时序、硬件保护逻辑的修改必须由嵌入式人员确认。
+- AI 适合辅助协议解析、状态机草稿、调试脚本、mock、文档和局部测试。
+- 涉及校时、看门狗、存储、日志、升级、断电恢复和异常重启的改动，必须按 `product-risk-control-standard.md` 做专项检查。

90_standards/code-review-checklist.md

+# Code Review Checklist
+
+Review AI 辅助代码时重点检查：
+
+- 是否完成需求评审、设计评审、开发评审和测试评审，或说明跳过原因
+- 是否符合需求
+- 是否改动范围过大
+- 是否破坏接口兼容性
+- 是否有异常处理和日志
+- 是否有测试或验证说明
+- 是否引入性能、内存、实时性或安全风险
+- 是否泄露私有模块信息
+
+产品风险控制补充检查：
+
+- 是否识别了 S/A/B/C 风险等级，S/A 级是否有评审和回退说明。
+- 校时、速度、抓拍、上传链路是否避免批量误处罚。
+- 升级后是否保持配置、检测区域、标定线和历史数据兼容。
+- 存储、日志、Flash/EMMC 写入是否会影响设备寿命或稳定性。
+- 看门狗、假死处理、异常重启和网络异常是否有明确策略。
+- 算法指标和误抓保护是否有验证方式，是否避免用临时逻辑掩盖根因。

90_standards/coding-standard.md

+# Coding Standard
+
+本文件记录团队通用编码规范。模块特殊规则放在各模块 AI 仓库或对应补充规范中。
+
+建议至少补充：
+
+- 命名规范
+- 目录结构规范
+- 日志规范
+- 错误处理规范
+- 配置管理规范
+- 注释规范
+- 兼容性要求
+
+## 产品风险控制
+
+开发默认遵循 `product-risk-control-standard.md`。涉及执法、抓拍、校时、速度、上传、升级、配置、存储、稳定性和算法指标的改动，必须先识别风险等级，再编码。
+
+- 配置文件与程序文件分离管理，程序运行中不得隐式修改关键配置。
+- 日志集中写入指定目录，支持定期清理，不得写入程序目录或系统只读区。
+- 对外部输入、网络异常、视频异常、信号异常、存储异常和断电重启必须有容错处理。
+- 涉及升级的改动必须保持历史配置、数据格式和设备兼容。
+- 禁止将 Flash/EMMC 作为高频业务数据存储介质；涉及存储写入的改动需说明写入频率。
+- 涉及 S/A 级风险的逻辑必须有保护阈值、异常隔离、日志和告警设计。
+- 通信协议里禁止用汉字，涉及编码兼容问题

90_standards/git-workflow.md

+# Git Workflow
+
+默认流程：
+
+1. 人工提出需求或选择任务。
+2. AI 辅助生成方案、代码或补丁。
+3. 人工 review diff。
+4. 人工运行必要测试。
+5. 人工提交代码。
+
+AI 默认不直接提交代码。

90_standards/product-risk-control-standard.md

+# Product Risk Control Standard
+
+本文根据 `temp/产品设计风险控制列表.xlsx` 和 `temp/组织经验教训列表 (1).xls` 整理，用于指导产品、软件、算法开发和评审。后续开发默认按本规范检查；如业务需求与本规范冲突，应先提交风险说明并由负责人确认。
+
+## 风险等级
+
+- S 级：可能造成恶劣社会影响、人身财产重大损失或大量误处罚的问题，必须尽全力避免。
+- A 级：可能给外部客户或公司人员、财产造成严重损失的问题。
+- B 级：可能影响公司商誉、造成客户损失或显著增加内部维护成本的问题。
+- C 级：可能造成内部效率低下、测试和维护成本增加的问题。
+
+## 通用开发原则
+
+- 修改前明确本次变更涉及的风险等级；涉及 S/A 级风险时，必须补充设计说明、异常处理、验证方式和回退方案。
+- 与执法、抓拍、校时、速度、上传相关的逻辑默认按 S 级风险处理，宁可隔离异常数据，也不得直接产生或上传可疑违法数据。
+- 升级、配置、存储、兼容性、看门狗、重启策略等基础能力默认按产品级能力设计，不按单点项目临时处理。
+- 对外宣传或产品定义中承诺的检测能力，必须在设计、实现、测试中闭环验证，不允许只为应付检测增加临时判断。
+- 关键问题应从设计根因解决；临时规避逻辑必须标注适用范围、失效条件和后续治理计划。
+
+## 产品定义和设计
+
+- 产品功能、硬件接口、配套外设、应用场景、使用环境和检测标准范围必须定义清楚。
+- 设备稳定性、处理能力、检测指标、视频和图片处理速度必须有明确量化要求。
+- UI 和客户端设计应优先考虑易用性、统一性和现场维护效率，避免一个产品依赖多个调试客户端。
+- 新设备、新平台、新工具必须考虑向前兼容；老设备核心能力不能因升级链路变化被放弃。
+- 转产前必须提供转产文件、质检方法、检验标准、测试工装、老化工具和受控的软件版本。
+- 外购或选型产品必须完成基本测试、现场环境模拟测试、室内外效果测试和入库检测方案；质量责任、赔偿条款、合格率、保质期和备件要求应写入采购约束。
+
+## 校时和违法数据
+
+- 设备时间必须有可靠校时方案；支持 NTP 时优先使用 NTP，网络中断时可使用 GPS，网络恢复后应进行二次校验。
+- 校时失败、时间跳变、时间异常时必须报警或进入异常状态，不得静默继续产生高风险业务结果。
+- 时间异常数据必须隔离保存到独立路径，不得按正常违法数据上传。
+- 速度异常不得生成超速违法结果。
+- 短时间大量抓拍、报警或违法数据必须触发阈值保护和隔离机制，避免批量误抓、误处罚。
+- 对误抓问题必须保留原因分析线索，能够定位输入、算法、配置、时间、速度或上传链路中的责任环节。
+
+## 升级、配置和兼容性
+
+- 升级工具应支持批量升级，并向前兼容历史设备；新产品也应接入统一升级工具。
+- 升级完成后不得改变原有参数设置，包括检测区域、标定线、任务配置和业务阈值。
+- 配置信息不得在程序运行中被自动、隐式修改；异常重启、断电、升级失败后配置应保持一致。
+- 配置文件应与程序文件分离并集中管理，降低升级误覆盖风险。
+- 系统盘应尽量只读；日志集中写入指定目录，不能写到程序目录。
+- 产品应关注操作系统、浏览器、OCX 插件、NVR、国标 GB 28181、ONVIF 及常用网络协议的兼容性。
+
+## 存储和日志
+
+- TF/SD 卡、SSD、硬盘等存储介质必须监测读写频率、介质状态、坏块和坏道。
+- 相机 Flash、终端 EMMC 不得作为频繁读写的数据存储介质使用；发布前应统计关键存储写入量。
+- 对异常重启、断电、硬盘读写异常应有保护、报警和恢复方案。
+- 日志文件必须支持定期自动删除，避免占满空间导致业务异常。
+- 存储介质应有碎片和冗余日志治理策略。
+
+## 稳定性和异常处理
+
+- 设备必须具备假死处理方案，硬件看门狗应守护系统主线程或关键业务线程。
+- 设备应支持定时重启，但不能因配置错误、网络异常或视频异常而反复重启。
+- 一般软件错误不得影响系统核心功能持续运行；异常输入、异常操作、网络丢包、视频花屏和卡顿均应有容错设计。
+- 网络较差时，视频流处理和上传链路应具备降级、重试、隔离或告警能力。
+
+## 算法设计
+
+- 算法方案必须明确捕获率、有效率、车牌识别率等指标和验证方式。
+- 算法不得随意控制球机频繁无效运动，避免缩短设备寿命。
+- 雷达、红灯信号采集器、补光灯、视频画面等接入信号异常时，算法应有明确处理机制。
+- 误抓保护属于 S 级要求，必须支持短时间异常数据保护。
+- 算法问题应优先从算法设计根源解决，不能长期依赖外层逻辑判断掩盖。
+
+## 经验教训约束
+
+- 交通执法系统时间错误曾导致批量误抓和赔偿风险；任何时间相关改动必须纳入重点回归。
+- 大文件升级和版本数据不兼容会造成数据问题和高额维护成本；涉及数据结构、配置格式、模型版本的升级必须提供兼容策略。
+- 授权文件、只读系统盘、Flash/EMMC 写入、统计精度等问题应在设计评审和发布验证中显式检查。
+- 客户要求的统计精度、检测精度和验收指标必须转化为可执行测试用例。
+
+## 发布前检查
+
+- 是否涉及 S/A 级风险，是否已完成设计说明、评审和验证记录。
+- 是否覆盖校时异常、速度异常、短时间大量数据、上传隔离和误抓保护。
+- 是否验证升级后配置不变、历史设备兼容、数据格式兼容。
+- 是否验证异常重启、断电、存储满、坏块、网络丢包、视频异常和信号异常。
+- 是否统计关键存储写入量，确认没有频繁写 Flash/EMMC。
+- 是否验证日志自动清理、看门狗、假死处理和定时重启策略。
+- 是否说明未覆盖的硬件环境、现场条件和人工验证项。

90_standards/security-rules.md

+# Security Rules
+
+- 不把私有源码、密钥、账号、模型参数、训练数据写入公共仓库。
+- 不在 prompt、任务记录或日志中粘贴敏感信息。
+- 跨权限协作时，只共享接口、行为和约束，不共享内部实现。

90_standards/testing-standard.md

+# Testing Standard
+
+建议每次较重要的 AI 辅助改动至少说明：
+
+- 已运行的测试
+- 未运行测试的原因
+- 需要人工验证的点
+- 回归风险
+- 硬件/环境依赖
+
+## 高风险回归项
+
+涉及以下能力时，必须补充专项验证或说明无法验证的原因：
+
+- 校时：NTP、GPS、网络中断、时间跳变、校时失败和恢复后二次校验。
+- 抓拍/违法数据：速度异常、短时间大量数据、误抓保护、异常数据隔离和禁止上传。
+- 升级：批量升级、历史设备兼容、升级后配置不变、数据格式兼容。
+- 存储：断电重启、存储满、坏块/坏道、日志清理、Flash/EMMC 写入频率。
+- 稳定性：假死处理、看门狗、定时重启、网络丢包、视频花屏/卡顿。
+- 算法：捕获率、有效率、车牌识别率、接入信号异常和误抓原因定位。

92_prompt_templates/fix-bug.md

+# Fix Bug Prompt Template
+
+请先定位问题来源，再做最小范围修复。
+
+输出需要包含：
+
+- 根因判断
+- 修改文件
+- 修复说明
+- 验证方法
+- 剩余风险
+
+AI 不直接提交代码。

92_prompt_templates/implement-feature.md

+# Implement Feature Prompt Template
+
+请按以下顺序工作：
+
+1. 阅读需求和相关接口文档。
+2. 阅读 `ai-public/90_standards/ai-coding-rules-common.md`。
+3. 阅读对应模块的 AI 补充规则。
+4. 搜索相关代码。
+5. 给出简短计划。
+6. 实现局部修改。
+7. 说明测试结果、风险和需要人工确认的点。
+
+AI 不直接提交代码。

92_prompt_templates/review-code.md

+# Review Code Prompt Template
+
+请以代码审查方式输出：
+
+1. 先列问题，按严重程度排序。
+2. 给出文件和位置。
+3. 说明影响和建议修复方式。
+4. 最后简短总结。

92_prompt_templates/update-interface.md

+# Update Interface Prompt Template
+
+接口变更前请先更新公共接口文档，并说明：
+
+- 变更原因
+- 输入输出变化
+- 兼容性影响
+- 版本策略
+- 需要哪些模块同步修改

92_prompt_templates/write-tests.md

+# Write Tests Prompt Template
+
+请根据现有测试风格补充测试，优先覆盖：
+
+- 正常路径
+- 边界条件
+- 错误输入
+- 回归场景
+
+说明如何运行测试。

93_knowledge_base/README.md

+# Knowledge Base
+
+公共知识库放可共享的领域知识，例如：
+
+- 术语表
+- 硬件约束摘要
+- 算法原理的非敏感摘要
+- g6 / Sensor 行为说明
+- 性能约束和常见问题
+
+私有知识应放到对应代码仓库的 `ai/93_knowledge_base/`。
+

95_skills/vaserver-development/SKILL.md

+---
+name: vaserver-development
+description: Use when working in the VAServer workspace or its algorithm, cbox, g6, ai-public modules. Guides Codex to read the shared project map, module boundaries, AI coding rules, product risk controls, testing standards, and review checklist before code or documentation changes.
+---
+
+# VAServer Development
+
+Use this skill for any VAServer development, review, debugging, documentation, integration, or AI-assisted coding task.
+
+## Workspace Assumption
+
+The current workspace root should be the VAServer repository root. If `ai-public/` is not present, locate the VAServer root before continuing.
+
+Do not copy private implementation details into `ai-public/`. Public docs may include interfaces, behavior, constraints, shared requirements, integration notes, and standards.
+
+## Superpower Mode And Skill Principles
+
+Use this skill as the project superpower: load the right project knowledge before acting, keep the working context focused, and turn team standards into executable checks.
+
+Follow Karpathy-style skill principles:
+
+- Skills are compact operational memory, not long essays.
+- Load only the references needed for the current task.
+- Prefer reusable workflow and checklists over one-off prompting.
+- Keep detailed standards in `ai-public/90_standards/`; this skill only routes and enforces.
+- If a repeated pattern appears during work, propose adding or updating a skill or reference instead of relying on chat memory.
+
+## Start Every Task
+
+1. Read the minimum project context:
+   - `ai-public/00_project_map/project-overview.md`
+   - `ai-public/00_project_map/repo-map.md`
+   - `ai-public/00_project_map/module-boundaries.md`
+   - `ai-public/00_project_map/ai-entry-guide.md`
+2. Read common rules:
+   - `ai-public/90_standards/ai-coding-rules-common.md`
+   - `ai-public/90_standards/coding-standard.md`
+3. Identify the touched module and read its rule file:
+   - algorithm: `ai-public/90_standards/ai-coding-rules-algorithm.md`
+   - cbox: `ai-public/90_standards/ai-coding-rules-cbox.md`
+   - g6: `ai-public/90_standards/ai-coding-rules-g6.md`
+4. If the task crosses modules, read relevant interface docs under `ai-public/20_interfaces/` before changing code.
+
+## Phase Review Gates
+
+Every non-trivial task must pass four review gates. Do not skip a gate unless the task is clearly Level 1 and no code, interface, config, data format, deployment behavior, or test behavior changes.
+
+### 1. Requirements Review
+
+Before design or coding, restate:
+
+- user goal and acceptance criteria
+- touched module or modules
+- public interface impact
+- product risk level, especially S/A risk
+- missing information or assumptions
+
+If requirements are ambiguous and a wrong assumption could create product risk, ask before implementing.
+
+### 2. Design Review
+
+Before implementation, outline:
+
+- intended approach and affected files
+- compatibility and rollback considerations
+- abnormal handling and logging
+- test strategy
+- open risks
+
+For cross-module or S/A-risk work, require explicit human confirmation or a clearly documented existing decision before changing behavior.
+
+### 3. Development Review
+
+During implementation, check:
+
+- change scope stays within the reviewed design
+- public interfaces and historical data/config compatibility are preserved
+- no private implementation details are moved into public docs
+- risk controls from `product-risk-control-standard.md` are implemented when applicable
+- code follows existing module patterns
+
+If implementation diverges from the design, stop and update the design review notes before continuing.
+
+### 4. Test Review
+
+Before final response, review:
+
+- tests run
+- tests not run and why
+- manual hardware, field, model, or legacy toolchain validation still needed
+- regression risk
+- evidence that S/A-risk protections were checked
+
+## Risk Gate
+
+Always check whether the task involves any of these areas:
+
+- time sync, device time, NTP, GPS
+- capture, illegal/violation data, speed, upload
+- false capture, abnormal burst data, enforcement result
+- upgrade, rollback, compatibility, data format migration
+- configuration, persistent settings, calibration line, detection area
+- storage, logs, Flash, EMMC, SD/TF card, SSD, disk full
+- watchdog, deadlock/hang, abnormal reboot, power loss recovery
+- algorithm metrics, signal abnormality, PTZ/ball camera control
+
+If yes, read `ai-public/90_standards/product-risk-control-standard.md` before implementation. Treat enforcement data, time sync, speed, upload, and false-capture protection as S-level risk unless the project documents say otherwise.
+
+For S/A-level risk, the final response or task record must state:
+
+- protection mechanism
+- abnormal-data isolation behavior
+- compatibility or rollback impact
+- tests run and tests not run
+- remaining hardware, field, or manual validation risk
+
+## Implementation Rules
+
+- Keep changes local to the requested module and existing ownership boundaries.
+- Preserve public interfaces unless an interface change is explicitly requested and documented.
+- Do not silently change runtime configuration, calibration, detection regions, or historical data formats.
+- Do not introduce frequent writes to Flash/EMMC or program directories.
+- Keep logs centralized, bounded, and cleanable.
+- For algorithm work, define inputs, outputs, dimensions, units, boundary conditions, metrics, and verification method.
+- For embedded/g6 work, consider memory, real-time behavior, power, blocking waits, hardware protection, watchdog, and reboot behavior.
+- For cbox/service work, preserve service stability, logging, configuration, rollback path, upload behavior, and compatibility.
+
+## Testing And Review
+
+Before finalizing, read:
+
+- `ai-public/90_standards/testing-standard.md`
+- `ai-public/90_standards/code-review-checklist.md`
+
+Report:
+
+- what changed
+- why it changed
+- result of requirements, design, development, and test reviews
+- tests or verification performed
+- tests not performed and why
+- remaining risk, especially S/A-level product risk
+
+If tests cannot be run because hardware, model, field environment, or legacy toolchain is missing, say so directly and name the manual validation needed.

95_skills/vaserver-development/agents/openai.yaml

+interface:
+  display_name: "VAServer Development"
+  short_description: "Shared VAServer project rules, risk controls, and review flow."
+  default_prompt: "Use $vaserver-development to work on this VAServer task according to the shared project and risk-control standards."
+
+policy:
+  allow_implicit_invocation: true

README.md

+# ai-public
+
+公共 AI 协作仓库，只放所有相关团队可以共享的信息。
+
+这里适合放：
+
+- 项目地图和仓库说明
+- 跨模块架构
+- 模块接口协议
+- 共享需求
+- 集成任务
+- 通用开发规范和 AI 使用规则
+- 团队共享 Codex Skills
+- 可共享领域知识
+
+这里不放：
+
+- 算法内部实现细节
+- 私有源码
+- 私有实验记录
+- 模块内部敏感设计
+- 未确认的 AI 中间代码
+
+AI 开始跨模块任务前，优先阅读：
+
+1. `00_project_map/project-overview.md`
+2. `00_project_map/repo-map.md`
+3. `00_project_map/module-boundaries.md`
+4. `00_project_map/ai-entry-guide.md`
+5. 与任务相关的 `20_interfaces/` 和 `90_standards/`
+
+团队 AI 协作规范入口：`00_project_map/team-ai-workflow.md`
+
+团队共享 Skill 入口：`95_skills/vaserver-development/`