mufeng-virtual-teamlisted

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