# Mufeng Virtual Team

> 用 AI 虚拟团队（CTO / 产品经理 / 普通用户三角色）评审一个产品功能是否值得做。适用于：评估新功能、判断某个想法要不要做、担心方案过度设计、想在写代码前暴露盲区。触发词：功能评审、虚拟团队、这个功能值不值得做、多角色评审、CTO 视角、帮我评估这个功能、mufeng virtual team。

- Skill: `ichangyou/mufeng-virtual-team` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ichangyou/mufeng-virtual-team`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ichangyou/mufeng-virtual-team/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ichangyou (https://skillmd.com/u/ichangyou)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ichangyou/mufeng-virtual-team

---


# 虚拟产品团队评审

让 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，默认存到当前工作目录，用户指定了其他位置则以用户为准。文件名格式：`虚拟团队评审-{功能名}-{日期}.md`
- 停在建议阶段，等用户决定后续，不主动开始实现

## 局限（写进报告结尾提醒用户）

- AI 用户不是真实用户，只能模拟常见行为，不能替代真实反馈
- AI 容易给出过度完整的方案，现实项目可能不需要那么复杂
- 背景描述不准确，结论就会偏——输入质量决定评审质量