# AI + OpenSpec 协作方式

这个项目后续推荐采用 **OpenSpec 定义变更 + AI 落地实现** 的方式持续迭代。

一个标准流程如下：

## 1. 先定义变更，而不是先写代码

* 明确这次要新增/修改什么组件能力
* 明确是视觉需求、参数需求、结构需求，还是项目规则需求
* 使用 OpenSpec 生成 `proposal / design / specs / tasks`

## 2. 让 AI 基于 OpenSpec 实施

* 读取当前变更上下文
* 按 tasks 逐项实现
* 代码、shader、配置、文档同步更新

## 3. 在实现过程中允许回写规则

* 如果这次实践形成了稳定经验
* 不要只修当前组件
* 要把经验提升为项目规则，回写到 `openspec/config.yaml`、README 或变更设计中

## 4. 把“做完一次”变成“以后都这么做”

组件实现完成后，不仅交付代码，还要沉淀：

* 约束
* 目录规范
* 参数设计方式
* 预览接入方式
* 验证方式

---

# 推荐时间节奏

如果以后继续通过 AI + OpenSpec 增加组件功能，推荐按下面的节奏推进：

## 1. 需求澄清（10~20 分钟）

目标不是写技术方案，而是把下面几件事说清楚：

* 组件做什么
* 有哪些可调参数
* 哪些是视觉要求，哪些是结构要求
* 哪些部分不能碰

## 2. 变更提案（10~20 分钟）

使用 OpenSpec 生成本次变更：

* `proposal.md`：为什么做
* `design.md`：怎么做
* `spec.md`：行为和规则
* `tasks.md`：实现步骤

这一步的重点是：
**把模糊想法变成可执行任务。**

## 3. AI 实施（20~90 分钟，按复杂度浮动）

AI 按 tasks 实施时，应同步处理：

* 组件代码
* shader 文件
* `dcsConfig.ts`
* 预览接入
* 文档 / 规则回写

这一步的重点是：
**实现不能只改代码，还要保持项目结构和方法一致。**

## 4. 验证与修正（10~30 分钟）

至少要检查：

* build 是否通过
* 变更相关文件 lint 是否通过
* 预览是否符合预期
* 是否误改了公共层文件

## 5. 规则沉淀（5~15 分钟）

如果这次实践形成了“以后都要遵守”的经验，就不应该停留在聊天记录里。

应该回写到：

* `openspec/config.yaml`
* `README.md`
* 当前 change 的 `design/spec/tasks`

这一步的重点是：
**让这次经验成为项目资产。**