API 设计评审模板:先定契约,再写实现
API 评审应检查资源模型、请求响应、错误码、权限、兼容性、分页和可观测性。
模版资源0002026-06-21
API 评审应检查资源模型、请求响应、错误码、权限、兼容性、分页和可观测性。
架构评审会议需要明确背景、方案、备选项、风险、开放问题和决策结果,避免只讨论偏好。
代码审查应优先关注行为正确性、边界条件、数据流、验证证据、安全和维护成本。
工程复盘应基于事实和指标,识别有效做法、问题根因、改进行动和后续 owner。
增长实验模板应包含用户假设、实验方案、指标、样本、风险、上线窗口和复盘方式。
故障复盘应记录影响、时间线、根因、检测缺口、修复动作和预防措施,避免停留在责任归因。
工程新人清单应覆盖本地环境、项目地图、验证命令、发布流程、关键文档和第一个小任务。
AI 功能 PRD 需要覆盖用户问题、输入输出、模型边界、评测标准、失败处理和上线指标。
发布说明应区分新功能、改进、修复、兼容变化和已知问题,并用用户语言说明影响。
Web 安全评审应覆盖输入校验、鉴权、权限、敏感数据、依赖、日志、上传和第三方集成。
技术设计文档应包含背景、目标、非目标、架构、数据流、风险、验证和发布计划。
测试计划应从需求风险出发,明确单测、集成测试、E2E、浏览器验收和人工检查的覆盖边界。
好用户故事应说明角色、目标、价值、业务规则和 Given-When-Then 验收标准。