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

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