ai-opportunity-evaluation

AI机会立项判断

项目能不能做，不看它能不能开发出来，而看它能不能解决真实问题，并沉淀 TranFu 的能力。

本 Skill 是 TranFu 第二阶段产品开发的立项门禁。它不是需求包装助手，而是在 PRD 和开发前，帮助团队判断一个想法是否值得继续投入。

When to use

当用户想判断一个产品想法、内部工具、Agent 想法、工作流产品或一句话项目是否值得立项时使用。典型触发短语：

• "判断这个项目怎么样"
• "帮我做个立项判断"
• "这个方向能不能做"
• "这个产品想法值不值得做"
• "用 AI机会立项判断 Skill，帮我分析"

也适用于用户只丢出一个产品名或一句话想法，并且上下文是在讨论产品机会、内部提效、能力沉淀、对外案例或是否进入 PRD。

不适用：用户已经明确要求直接开发、修 bug、部署、写代码，或某个方向已经完成立项并明确要求输出 PRD。

工作模式

CREATE A TODO LIST FOR THE TASKS BELOW: 1) 判断信息是否足够 2) 判断真实问题 3) 判断 TranFu 价值 4) 输出立项判断卡

Step 1: 判断信息是否足够

任务：先识别用户给的是完整立项信息，还是只有一句话想法。

输入：项目名、一句话描述、背景信息、团队上下文。

输出：如果信息不足，只问 2-3 个最关键问题，不输出完整判断卡。

优先追问：

1. 谁会高频使用？
2. 现在怎么解决，最麻烦的地方是什么？
3. 这个项目想验证什么能力、流程、Skill、Agent 或 SOP？

MUST 在 3 轮追问内给出立项判断卡；NEVER 进入第 4 轮追问。

若 3 轮追问后 4 项关键事实（用户 / 现解决方式 / 频率与损失 / 内部使用意愿）仍缺 ≥2 项，MUST 输出立项判断卡，结论字段写"暂不建议做"，核心理由第 1 条写"关键事实不足，待补充后重审"，并退出。

Step 2: 判断真实问题

任务：判断它是不是解决真实、高频、具体的问题，而不是一个随手想到的功能。

重点检查：

• 是否说清楚目标用户。
• 是否说清楚当前解决方式。
• 是否说清楚痛点频率和损失。
• 是否有内部团队愿意反复使用。

输出：保留关键事实和缺口，不要写长篇分析。

Step 3: 判断 TranFu 价值

任务：判断这个项目是否符合 TranFu 第二阶段产品开发原则。

按顺序判断：

1. 真实问题：是不是有人真的需要？
2. 使用频率：是不是高频问题？
3. 内部价值：TranFu 团队会不会反复用？
4. 验证目标：能不能验证流程、Skill、Agent 或 SOP？
5. 沉淀价值：能不能变成官网产品、模板、案例或交付能力？
6. 品牌风险：做出来会不会像低质 Demo，反而影响 TranFu 形象？

结论 MUST 是三档之一：

• 建议做
• 优化后再做
• 暂不建议做

NEVER 使用"可以考虑" / "有一定价值" / "看情况" / "可能值得"这类模糊结论。

Step 4: 输出立项判断卡

任务：用短卡片输出判断，让团队成员一眼知道下一步。

每块 1-2 句话，核心理由最多 3 条，整体控制在一屏以内。

立项判断：建议做 / 优化后再做 / 暂不建议做

核心理由：
1. ...
2. ...
3. ...

真实问题：
...

验证目标：
...

首版范围：
...

风险提醒：
...

下一步：
...

What NOT to do

• ❌ NEVER 直接写 PRD；仅当用户在本 Skill 完成立项判断后另行明确要求写 PRD 时，结束本 Skill 并转入 PRD 任务。
• ❌ NEVER 把普通工具包装成战略产品，例如低配排版器、低配待办页。
• ❌ NEVER 因为"能开发出来"就建议立项，必须看到真实问题和 TranFu 能力沉淀。
• ❌ NEVER 输出长篇产品分析报告；除非用户显式要求详细复盘，否则默认一屏以内。
• ❌ NEVER 一次追问 8 个问题，信息不足时只问最关键的 2-3 个。
• ❌ NEVER 给出模糊结论，必须在三档结论中选择一个。
• ❌ NEVER 建议做会影响 TranFu 品牌形象的低质 Demo。

示例判断

VPN智能路由平台

立项判断：建议做

核心理由：
1. 团队确实有 VPN 资源管理、分发、权限回收的问题。
2. 能验证"资源池管理 -> 可用性监控 -> 订阅分发"的关键流程。
3. 后续可以沉淀为内部网络资源管理 SOP，甚至成为对外案例。

真实问题：
团队网络资源分散，稳定性、权限和设备限制都需要统一管理。

验证目标：
验证资源统一管理、智能分发和权限回收流程。

首版范围：
先做资源录入、成员分配、订阅生成和可用性检查，不做复杂企业后台。

风险提醒：
不要一开始做成大而全平台，先跑通稳定分发闭环。

下一步：
进入 PRD。