4.4 KiB

Raw Blame History

AI-Box设计评审流程规范

1. 设计评审适用范围

必须进行正式设计评审的重要设计结果：

系统架构设计方案 (孙大圣负责)
产品需求规格书(PRD) (猪小杰负责)
核心模块详细设计文档
接口定义和协议规范
电源管理策略设计
安全性和可靠性设计方案

可以简化评审的常规设计：

工具脚本和辅助程序
非核心功能模块设计
文档格式和排版调整

2. 飞书审批流集成方案

2.1 审批流配置需求

由于当前飞书应用权限限制，需要申请以下审批流相关权限：

approval:approval_instance - 审批实例管理
approval:approval_template - 审批模板管理

2.2 临时审批流程（当前可用）

在获得完整审批权限前，采用以下临时流程：

步骤1: 文档创建与初审

设计者在飞书云文档中创建设计文档
在文档开头添加 【设计评审】 标识
@相关评审人员进行初步技术评审

步骤2: 评审会议组织

在 04 项目会议 文件夹中创建评审会议
邀请所有相关干系人参加
会议议程包含：设计介绍、问题讨论、决策确认

步骤3: 评审结果记录

在会议文档中记录评审结论
明确标注：通过/有条件通过/不通过
列出所有需要修改的问题项和负责人

步骤4: 文档更新与确认

设计者根据评审意见修改文档
在文档修订历史中记录修改内容
评审人员确认修改后，在评论区回复 【确认通过】

2.3 正式审批流流程（权限开通后）

一旦获得审批流权限，将升级为正式审批流程：

自动化审批触发

设计文档保存时自动触发审批流
系统自动识别文档类型并分配相应审批人
审批流包含：技术评审 → 架构评审 → 项目经理确认 → 最终批准

审批状态跟踪

实时显示审批进度
超时自动提醒审批人
审批历史完整记录

3. 评审角色与职责

3.1 评审委员会组成

角色	人员	职责
技术评审员	孙大圣	技术可行性、架构合理性
产品评审员	猪小杰	需求符合度、用户体验
项目经理	唐小僧	进度影响、资源协调
质量保证	测试团队	可测试性、质量标准

3.2 评审标准

技术先进性: 是否采用合适的技术方案
需求符合度: 是否完全满足产品需求
可实施性: 开发团队是否具备实施能力
可维护性: 后续维护和扩展的便利性
风险可控性: 技术风险是否在可接受范围内

4. 评审流程执行细节

4.1 评审准备

提前通知: 评审前至少24小时通知评审人员
材料准备: 提供完整的背景资料和参考文档
环境准备: 确保演示环境和测试数据就绪

4.2 评审会议

时间控制: 单次评审会议不超过2小时
议题聚焦: 严格按照议程进行，避免偏离主题
记录完整: 指定专人记录会议要点和决策

4.3 评审后续

问题跟踪: 所有问题必须有明确的解决计划
状态更新: 每周更新评审问题的解决进度
闭环验证: 问题解决后必须进行验证确认

5. Gitea与飞书协同机制

5.1 双向同步规则

飞书为主: 设计文档以飞书版本为准
Gitea备份: 评审通过的最终版本必须同步到Gitea
版本对应: 飞书文档版本号与Gitea提交哈希对应

5.2 同步时机

评审前: 在飞书创建和编辑文档
评审后: 评审通过24小时内同步到Gitea
重大变更: 任何重大修改都需要重新评审

6. 应急处理机制

6.1 紧急设计决策

对于紧急情况下的设计决策：

快速通道: 项目经理可授权临时决策
事后补审: 72小时内必须补办正式评审
风险评估: 必须记录决策的风险和应对措施

6.2 评审争议处理

当评审出现重大分歧时：

升级机制: 提交给更高层级决策
专家咨询: 邀请外部专家提供意见
原型验证: 通过快速原型验证方案可行性

本规范自发布之日起生效，所有重要设计结果必须遵循此评审流程。项目经理负责监督执行，并根据实际运行情况进行优化调整。