教程概述
系列索引: gstack 教程系列
三种审查技能覆盖不同受众：工程、开发者体验和设计。
你将学到
- ✅ 三种审查类型的区别
- ✅
/plan-eng-review用于架构 - ✅
/plan-devex-review用于开发者体验 - ✅
/plan-design-review用于 UI/UX - ✅ 何时使用哪种审查（决策表）
三种审查类型
flowchart TD
A[计划] --> B{受众是谁？}
B -->|后端/API| C[/plan-eng-review]
B -->|SDK/CLI/文档| D[/plan-devex-review]
B -->|UI/UX/前端| E[/plan-design-review]
B -->|以上全部| F[运行所有三个]
style C fill:#e3f2fd
style D fill:#e8f5e9
style E fill:#fff3e0
/plan-eng-review — 架构审查
覆盖内容
- ASCII 图表 — 系统架构、数据流
- 状态机 — 转换、边缘情况
- 错误路径 — 失败模式、恢复
- 测试矩阵 — 测试什么、覆盖目标
- 安全考虑 — 攻击面、缓解措施
- 性能 — 瓶颈、扩展限制
示例输出
## 工程审查：用户认证
### 架构图
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 客户端 │────▶│ API GW │────▶│ 认证服务 │ └─────────────┘ └─────────────┘ └─────────────┘ │ ▼ ┌─────────────┐ │ 数据库 │ └─────────────┘
### 状态机：会话
[匿名] ──登录──▶ [认证中] ──成功──▶ [已认证] │ │ │ 失败 │ 登出 ▼ ▼ [错误] ◀──────────── [匿名]
### 错误路径
| 错误 | 处理器 | 恢复 |
|------|--------|------|
| 凭证无效 | 返回 401 | 提示重试 |
| Token 过期 | 返回 401 | 刷新 token |
| 服务宕机 | 返回 503 | 退避重试 |
| 速率限制 | 返回 429 | 等待重试 |
### 测试矩阵
| 场景 | 测试类型 | 优先级 |
|------|----------|--------|
| 有效登录 | 集成测试 | 高 |
| 无效密码 | 单元测试 | 高 |
| Token 刷新 | 集成测试 | 高 |
| 会话超时 | 集成测试 | 中 |
| 并发会话 | 集成测试 | 中 |
| SQL 注入 | 安全测试 | 关键 |
何时使用
- 后端/API 开发
- 数据库模式更改
- 微服务设计
- 性能关键路径
- 安全敏感功能
/plan-devex-review — 开发者体验审查
覆盖内容
- 开发者画像 — 谁使用这个？
- TTHW 基准 — Hello World 时间
- 魔法时刻 — 什么让开发者说"哇"
- 摩擦点 — 开发者在哪里卡住？
- 文档需求 — 需要什么文档？
- 错误消息 — 是否有帮助？
示例输出
## DevEx 审查：API SDK
### 开发者画像
| 画像 | 需求 | 痛点 |
|------|------|------|
| 初级开发者 | 清晰示例，好错误 | 选项过多 |
| 高级开发者 | 速度，灵活性 | 样板代码 |
| 企业 | 稳定性，支持 | 版本锁定 |
### TTHW 基准
| 平台 | 当前 | 目标 | 差距 |
|------|------|------|------|
| JavaScript | 5 分钟 | 2 分钟 | 需要更简单的初始化 |
| Python | 8 分钟 | 3 分钟 | 需要更好的文档 |
| Go | 15 分钟 | 5 分钟 | 需要入门模板 |
### 魔法时刻
"SDK 从环境变量猜测了我的配置，不需要设置。"
### 摩擦点（询问 20-45 个问题）
1. 新用户看到的第一个错误是什么？
2. 第一次 API 调用前有多少步骤？
3. 错误消息是否可操作？
4. 示例代码不修改就能工作吗？
5. 安装是一个命令吗？
### 文档需求
- [ ] 快速入门指南（目标：2 分钟阅读）
- [ ] 带示例的 API 参考
- [ ] 错误排查指南
- [ ] 从 v1 的迁移指南
何时使用
- SDK 开发
- CLI 工具
- API 设计
- 文档项目
- 平台/基础设施
/plan-design-review — UI/UX 设计审查
覆盖内容
- 10 维度评分 — 每个维度 0-10 分
- AI 水代码检测 — 通用、懒惰的设计模式
- 交互式审查 — 每个设计选择一个问题
- 前后示例 — 视觉改进建议
10 个设计维度
| 维度 | 衡量什么 |
|---|---|
| 1. 视觉层次 | 用户能扫描和理解吗？ |
| 2. 一致性 | 元素匹配设计系统吗？ |
| 3. 可访问性 | 所有用户都能访问吗？ |
| 4. 响应式 | 在移动/平板/桌面工作吗？ |
| 5. 反馈 | 操作有明确响应吗？ |
| 6. 错误处理 | 错误清晰可恢复吗？ |
| 7. 加载状态 | 空状态/加载状态处理了吗？ |
| 8. 动效 | 动画有目的，不分散注意力？ |
| 9. 排版 | 文本可读可扫描吗？ |
| 10. 颜色 | 颜色使用有意义吗？ |
AI 水代码检测
常见的 AI 生成设计问题：
❌ 检测到 AI 水代码模式：
1. **通用英雄区** — "赋能你的工作流" 占位文本
2. **无意义渐变** — 紫到蓝没有目的
3. **千篇一律卡片** — 相同的 3 列布局
4. **假评价** — 生成的引用配库存照片
5. **空洞 CTA** — "开始使用" 不解释是什么
✅ 应用的修复：
- 英雄区：替换为具体价值主张
- 渐变：使用有目的的品牌色
- 卡片：根据内容类型变化布局
- 评价：删除或使用真实引用
- CTA：添加具体行动描述
何时使用
- 前端开发
- UI 组件
- 落地页
- 用户流程
- 设计系统
何时使用哪种审查？
| 构建… | 计划阶段 | 实时审计 |
|---|---|---|
| 最终用户（UI、Web 应用） | /plan-design-review |
/design-review |
| 开发者（API、CLI、SDK） | /plan-devex-review |
/devex-review |
| 架构（数据流、性能） | /plan-eng-review |
/review |
| 以上全部 | /autoplan |
— |
技能快速参考表
| 技能 | 受众 | 聚焦 | 输出 |
|---|---|---|---|
/plan-eng-review |
后端工程师 | 架构、测试、安全 | 图表、测试矩阵 |
/plan-devex-review |
开发者用户 | TTHW、摩擦、文档 | 画像分析、基准 |
/plan-design-review |
最终用户 | UI/UX、可访问性 | 10 维度评分、水代码修复 |
总结
三种审查对应三种受众：
- 工程 — 架构、测试、安全
- DevEx — 开发者体验、TTHW、文档
- 设计 — UI/UX、可访问性、AI 水代码检测
关键要点
- ✅ 将审查匹配受众
- ✅ 使用
/autoplan自动路由 - ✅ 每种审查有特定输出
- ✅ 对全栈功能运行多个审查
系列导航：
- ← 上一篇: 教程 3：plan-ceo-review
- → 下一篇: 教程 5：设计管道
- 返回: 系列索引