- 删除 01~05 旧中文教程目录 - 将 03 核心功能教程拆分为各 framework 模块的子文档 - 06 工具脚本移入 modules/frameworks/编辑器工具/UI工具/ - 非框架内容合并进 rules/20-开发规则.md 与 rules/40-工作流清单.md - 更新所有交叉链接与文档关联表 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.6 KiB
6.6 KiB
工作流清单
本文档是 UnityAI / StrayFog 框架知识库的长期规则,为 Codex (AGENTS.md) 和 Claude Code (CLAUDE.md) 共同引用。
任务分类
| 类型 | 特征 | 处理方式 |
|---|---|---|
| 简单修复 | 查询、解释、小范围修改、影响面低、用户已给出明确方式 | 直接处理,完成后验证并归档检查 |
| 旧模块修复 | 已有框架模块的 bug 修复、逻辑补全、局部优化 | 读取模块文档,分析影响范围后修复,验证并归档 |
| Spec 任务 | 新增框架模块、调整架构/目录/依赖、批量修改迁移 | 走 OpenSpec 流程 |
简单修复流程
- 确认任务范围。
- 读取相关模块文档。
- 直接修改。
- 验证(如可运行测试、检查链接、预览 Markdown)。
- 执行归档检查。
- 简短说明结果。
旧模块修复流程
- 定位已有模块文档和相关内容。
- 简短分析影响范围和风险。
- 直接修复。
- 验证。
- 按 50-归档规则.md 同步相关模块文档。
Spec 任务流程
大需求 / 新模块统一走 OpenSpec:
- 分析目标、影响范围、风险和依赖。
- 给出 2-3 个方案。
- 用户确认后创建 OpenSpec change。
- 生成
proposal.md、design.md、tasks.md。 - 实现。
- 验证。
- 归档并同步文档。
详见 60-新特性工作流.md。
开发流程
1. 文档学习
根据任务类型阅读对应模块文档:
| 任务类型 | 必读文档 |
|---|---|
| UI 开发 | UI 窗口系统 |
| UI 界面设计 | UI 界面拼接设计指南 |
| 相机控制 | 相机系统 |
| 实体开发 | 实体系统 |
| 事件使用 | 事件系统 |
| 资源加载 | 资源管理 |
2. 需求分析
- 明确需求:理解业务需求,确定需要实现的功能。
- 评估复杂度:判断是否需要核心库支持或扩展。
- 设计方案:规划代码结构和调用关系。
3. 代码编写
- 在
GameFunction/下按职责创建模块目录。 - 遵循编码规范,使用核心库提供的 API。
- 在 Unity 中测试功能正确性。
4. 代码审查
- 自我检查:检查是否符合规范,是否有潜在问题。
- 团队审查:提交代码进行团队审查。
- 修复问题:根据审查意见修改代码。
5. 集成测试
- 模块测试:测试单个模块功能。
- 集成测试:测试模块间交互。
- 回归测试:确保不影响现有功能。
文档变更联动检查
修改任何文档前,确认它是否被其他文档引用:
- 模块文档变更 → 同步检查模块索引、模块登记规则、架构说明。
- 架构/目录变更 → 同步检查模块索引、相关模块 README、架构说明。
- 规则文件变更 → 同步检查
rules/项目规则入口.md、ai/AI接入入口.md、AGENTS.md、CLAUDE.md、RULES.md。 - spec/change 完成 → 同步更新相关模块 progress.md,并建立
specs/openspec/归档。
提交前检查
提交信息格式
推荐格式:
[模块][类型]: 简短描述
- 详细说明 1
- 详细说明 2
类型:feat、fix、docs、refactor、test、chore。
模块名示例:framework、entity、ui、event、resource、docs、rules、hooks。
示例:
[entity][docs]: 补充实体池索引机制说明
- 添加 onlyid -> entity 映射说明
- 补充 HFBasicPool/HFEnemyPool/HFHumanityPool 边界
历史格式说明:早期文档使用
【操作原因】具体操作内容(如【修复】xxx)。该格式已弃用,新提交统一使用[module][type]: description。
分支管理
| 分支名称 | 用途 |
|---|---|
master |
主分支,稳定版本 |
develop |
开发分支,日常开发 |
feature/* |
功能分支,开发新功能 |
bugfix/* |
Bug 修复分支 |
Git 操作原则
- 执行 Git 操作前确认当前操作路径是否正确。
- 遵循项目既定的分支策略。
- 使用语义化提交信息,清晰描述更改内容。
- 重要功能提交前建议先创建分支进行测试。
- 开发完成后及时推送到远程仓库。
提交前检查项
- 文档链接可点击且指向正确。
- 文档关联表已更新。
- 模块索引已同步(如新增/拆分了模块)。
- 无拼写或明显格式错误。
- 未引入外部项目专属内容。
- 业务参考内容只出现在
business-reference/下。
新增内容流程
新增框架模块
- 在 模块索引 中登记。
- 创建
modules/frameworks/<module>.md;复杂模块可拆分为modules/frameworks/<module>/README.md加子文档。 - 在 架构说明 中补充依赖方向。
- 更新相关模块的文档关联表。
新增编辑器工具
- 在 模块索引 中登记。
- 创建
modules/editor-tools/<tool>.md或补充汇总文档。 - 说明使用入口、生成输出、依赖项。
新增业务参考
- 放入
business-reference/<project>/。 - 不进入
modules/模块索引.md主索引。 - 在
business-reference/<project>/业务框架映射接口.md中补充映射关系。
生成/构建流程
若项目使用 StrayFog 框架配套的生成工具:
- 优先修改源表、proto 或 schema,而不是生成输出。
- 生成后检查输出目录,确认变更符合预期。
- 缺失的生成步骤记录到对应模块文档。
文档关联
当本文档发生变更时,应同步检查以下关联文档,避免信息不一致。
| 文档 | 关联原因 |
|---|---|
| rules/项目规则入口.md | 工作流清单是项目规则入口索引的关键规则 |
| rules/50-归档规则.md | 归档规则与工作流清单互相引用 |
| rules/60-新特性工作流.md | 新特性工作流是工作流清单的延伸 |
| rules/20-开发规则.md | 提交格式与开发规则互相引用 |
| modules/模块索引.md | 新增模块登记需同步模块索引 |
| hooks/commit-check.ps1 | 提交检查脚本需与本文件格式一致 |