工程计划审查 (plan-eng-review)

工程计划审查（plan-eng-review）

概述

plan-eng-review 让 AI 以 CTO/技术负责人 的视角审查技术计划。它的核心是：从技术可行性、架构、风险角度评估你的方案。

作为一个程序员，你可能遇到过：

“我觉得这个方案技术上行得通”——但没有系统性分析
“这个技术方案有什么风险？“——回答不上来
“这个架构合理吗？“——不确定

plan-eng-review 就是解决这些的。

为什么需要 CTO 视角

1. 技术决策影响深远

一个技术选型可能影响：
- 未来 1-2 年的开发效率
- 招聘难度
- 运维成本
- 扩展性

2. 避免技术债务

CTO 视角会问：
- 这个方案会产生技术债务吗？
- 3 年后还能维护吗？
- 团队有能力驾驭吗？

3. 风险识别

CTO 视角会关注：
- 技术风险
- 人员风险
- 时间风险
- 依赖风险

审查维度

1. 技术可行性

问题：
- 技术上能实现吗？
- 有没有未解决的技术难题？
- 团队有相关经验吗？

评估：
- ✅ 可行
- ⚠️ 有挑战
- ❌ 不可行

2. 架构合理性

问题：
- 架构符合系统设计原则吗？
- 扩展性如何？
- 维护性如何？
- 和现有系统兼容吗？

评估：
- ✅ 合理
- ⚠️ 需要调整
- ❌ 不合理

3. 复杂度评估

问题：
- 实现复杂度有多高？
- 需要多长时间？
- 需要多少人？

评估：
- 🟢 低 (1-2 周)
- 🟡 中 (1 个月)
- 🔴 高 (> 1 个月)

4. 风险识别

风险类型	风险点	严重程度
技术风险	新技术不成熟	高
人员风险	没人懂这项技术	中
时间风险	工期评估不准	高
依赖风险	依赖第三方服务	中

5. 替代方案

问题：
- 有没有更简单的方案？
- 最小可行方案是什么？
- 能否分阶段实现？

实践案例

案例 1：微服务改造

背景：要把 monolith 拆分成微服务

plan-eng-review 会问：

1. 技术可行性
   - 服务拆分的技术方案成熟吗？✅
   - 团队有相关经验吗？⚠️ 需要培训

2. 架构
   - 拆分边界清晰吗？✅
   - 服务间通信方案？REST vs RPC
   - 数据一致性怎么保证？

3. 复杂度
   - 规模：🔴 高 (3 个月)
   - 风险：很高

4. 风险
   - 迁移期间怎么保证服务连续？
   - 团队能否驾驭？
   - 基础设施跟得上吗？

建议：先做服务拆分可行性验证 (MVP)

案例 2：引入新技术栈

背景：要从前端用 React 改成 Vue

plan-eng-review 会问：

1. 技术可行性
   - Vue 能实现 React 的所有需求吗？✅
   - 迁移成本多高？

2. 架构
   - 组件需要完全重写？
   - 状态管理方案？

3. 复杂度
   - 规模：🔴 高 (2 个月)
   - 风险：中等

建议：
- 方案 A：渐进式迁移
- 方案 B：新功能用 Vue，老功能不动

案例 3：技术债偿还

背景：要把 jQuery 重构成 React

plan-eng-review 会问：

1. 价值
   - 重构带来的价值是什么？
   - 不重构的代价是什么？

2. 风险
   - 重构会不会引入新 bug？
   - 怎么保证回归？

建议：
- 先建立完善的测试覆盖
- 分模块逐步迁移
- 每个模块迁移后验证

常用问题清单

技术可行性

技术上能实现吗？
有没有未解决的技术难题？
团队有相关经验吗？
需要的依赖都稳定吗？

架构设计

复杂度

实现复杂度有多高？
需要多长时间？
需要多少人？
有哪些不确定因素？

风险

技术风险是什么？
人员风险是什么？
时间风险是什么？
依赖风险是什么？

替代方案

有更简单的方案吗？
最小可行方案是什么？
能否分阶段实现？

速查卡片

审查视角

技术可行性
架构合理性
复杂度评估
风险识别

核心问题

能实现吗？
架构合理吗？
复杂度多高？
有什么风险？

输出

可行性评估
风险清单
替代方案
建议

与其他技能

plan-ceo-review - 从 CEO 视角审查产品计划
plan-design-review - 从设计视角审查方案
brainstorming - 探索方案
office-hours - 产品思考伙伴

查看源文件: GitHub原始文件