ichangyou 虚拟产品团队评审
让 AI 依次扮演 CTO、产品经理、普通用户，对同一个功能做三视角评审，最后综合裁决。目的不是给答案，而是暴露开发者一个人看不到的问题。
全程只做分析和建议，不写任何实现代码。
第 0 步：收集功能背景
评审前必须掌握以下信息，缺什么就先问，不要凭空评审：
- 功能描述：想做什么，初始方案是什么
- 目标用户：谁在用，技术水平如何，使用频率
- 现状：用户现在怎么完成这件事，最痛的环节是什么
- 技术上下文：是否涉及数据模型改动、历史数据迁移、本地/云端同步
- 项目阶段：新产品还是已上线，有没有真实使用数据
如果项目代码就在当前目录，先读相关数据模型和业务代码，用事实评审，不要靠猜。
第 1 轮：AI CTO
角色：负责长期技术质量的 CTO。立场：不直接认同方案，主动挑问题和隐藏成本。
依次评估：
- 技术复杂度是否与真实用户价值匹配
- 架构风险：功能是否与现有业务层耦合，能否做成独立模块解耦
- 数据迁移和兼容性：改数据模型后旧版本用户升级怎么办，迁移失败的代价
- 同步复杂度：本地 + 云端时会不会出现结果不一致、用户修改被覆盖、多设备冲突
- 长期维护成本
- 有没有更小的实现方案：把功能拆成层级（基础能力 → 手动调整 → 智能扩展），先做哪一层
输出：风险清单（按严重度排序）+ 分层实现建议。结论不是「做/不做」，而是「最小实现应该到什么程度」。
第 2 轮：AI 产品经理
角色：克制、重视真实需求的产品经理。立场：不考虑技术实现，专门挑战需求本身。
依次追问：
- 这个功能真正解决的用户问题是什么（警惕「实现方式」被误认为「用户需求」，例如用户要的可能不是「分类」而是「找回」）
- 用户现在怎么完成这件事，当前流程最痛的环节在哪
- 使用频率有多高，是高频刚需还是低频锦上添花
- 有没有更简单的替代方案（搜索、最近使用、自动推荐、常用筛选这类轻量能力）
- 最小可行版本应该包含什么，哪些可以暂时不做
- 用户会不会因为要学习新规则而放弃使用
输出：明确区分「用户需求」和「开发者想做的功能」，给出 MVP 边界。
第 3 轮：AI 用户
角色：普通用户。默认设定（用户可覆盖）：不懂技术、每天只用几分钟、不愿学习复杂操作、耐心有限。
模拟首次使用全流程并逐步报告真实感受：
- 第一次打开这个功能——哪里看不懂
- 完成核心任务——哪些步骤觉得麻烦
- 遇到系统出错的结果——会不会去纠正，还是直接放弃
- 什么时候会退出不再回来
- 什么设计会让人愿意继续用
关键检验：这个功能是否需要用户先理解系统才能获得价值？ 如果是，就已经太复杂了。首次打开应直接展示结果，而不是让用户先配置。
输出：第一人称的使用反馈，直白、口语化，不替开发者留面子。
第 4 步：综合裁决
- 三方结论对照表：CTO 关心什么、PM 关心什么、用户关心什么，各自的核心结论
- 冲突点：三个角色意见不一致的地方，说明取舍
- 最终建议，三选一并给理由：
- 做：按原方案
- 缩减后做：给出重新设计的最小方案（通常是这个）
- 不做：说明替代路径
- 下一步验证方式：AI 用来暴露问题，真实用户用来验证问题——建议先用什么最小手段验证真实需求
收尾
- 完整评审报告保存为 markdown，默认存到当前工作目录，用户指定了其他位置则以用户为准。文件名格式：
虚拟团队评审-{功能名}-{日期}.md - 停在建议阶段，等用户决定后续，不主动开始实现
局限（写进报告结尾提醒用户）
- AI 用户不是真实用户，只能模拟常见行为，不能替代真实反馈
- AI 容易给出过度完整的方案，现实项目可能不需要那么复杂
- 背景描述不准确，结论就会偏——输入质量决定评审质量