analyze-idea
Skill9 starsChanged 3 months agoMITView on GitHub
分析一个商业想法或点子,判断值不值得做、适不适合当前的人/资源去做、如何最小代价验证。包含调研与证据收集环节:市场规模、客户痛点、竞争、合规等信息通过桌面调研、访谈、实地观察、小成本实测获取,证据分级记录,避免拍脑袋决策。当用户提出"我有个想法/点子/机会""这个 idea 可行吗""要不要做""帮我想想这个生意能不能做"、或需要在投入产品开发之前先评估一个想法时使用。适用场景包括:门店经营者(如房产中介门店)的副业/新业务想法、创业者评估方向、任何"先别写代码,先判断值不值得"的讨论。输出为结构化分析报告与 Go/调整/No-Go 决策简报,通过后再衔接 vibecoding-orchestration 进入产品开发。
In this repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- pil-diagramSkill
- ui-design-intelligenceSkill
- vibecoding-orchestrationSkill
The file
Files
Analyze Idea(想法分析)
定位
这是 vibecoding-orchestration 的上游前置阶段。在投入任何需求蒸馏或产品开发之前,先回答三个问题:
- 这个想法值得做吗?(价值判断)
- 适不适合当前的人/资源来做?(匹配判断)
- 如果要验证,最小代价怎么验?(验证路径)
回答完这三个问题并拿到决策后,才进入 vibecoding-orchestration 的需求锚定。
工作流
S0 想法捕捉 → G1 快速筛选 → S2 调研(证据收集)→ S3 深度分析(六维度)→ G2 决策 → 衔接 vibecoding-orchestrationS0 想法捕捉
把口头想法固化成一份 01-idea-brief.md:
- 一句话假设:为谁,解决什么问题,凭什么赚钱
- 提出者背景:谁、有什么资源、为什么是他
- 当前信息缺口清单(不知道什么,先列出来)
规则:想法不落盘不算捕捉完成。 落盘后才知道缺什么信息。
G1 快速筛选(否决项,15 分钟内)
逐项检查,任一命中即 No-Go 或大幅重定向:
- 是否违法、违规或踩行业监管红线?
- 是否明显超出提出者的资源边界(钱、人、时间、渠道)?
- 是否明显没有付费方(没人会为它掏钱)?
- 是否明显红海且毫无差异化?
- 是否与现有主营业务冲突、会伤主业?
检查表见 references/decision.md。G1 由提出者 + 分析者共同快速过一遍,不做深度调研。
S2 调研(证据收集)
G1 通过后,用调研把"我觉得/听说"变成"有来源的证据":
- 方法:桌面调研(市场/政策/平台规则/竞品)、访谈调研(老客户/潜在客户/同行)、实地观察(门店/商圈)、小成本实测(问卷/预售/试点)
- 证据逐条记入
05-research-log.md,标注来源、日期、级别(A 一手 / B 二手官方 / C 二手非官方) - 结束检查:六维度要回答的问题是否都有证据;没有证据的问题转入"待验证假设",禁止脑补填补
完整方法见 references/research.md。没有证据支撑的结论必须标注"待验证假设",不能当作事实。
S3 深度分析(六维度)
按 references/framework.md 的框架,用调研证据逐维度分析,每个维度产出:现状、证据、缺口、1-5 分。
| 维度 | 核心问题 |
| 1 客户与痛点 | 谁?多痛?多频繁?现在怎么解决的? |
| 2 市场与时机 | 规模多大?趋势?为什么是现在? |
| 3 商业模式 | 怎么赚钱?成本结构?单店/单位经济? |
| 4 资源与竞争 | 现有资源能复用多少?对手是谁?优势在哪? |
| 5 风险与合规 | 监管、资金、平台规则、执行风险? |
| 6 验证路径 | 最小代价怎么验?成功/失败标准? |
深度报告用模板 03-deep-analysis.md。行业适配(房产门店场景)见 references/real-estate.md。
G2 决策
用 scripts/score_idea.py 对六维度加权评分,然后产出 04-decision-brief.md:
- Go:进入 vibecoding-orchestration 需求锚定
- 调整后 Go:列出必须调整的项 + 重新评估条件
- No-Go:归档并写明原因(废案文化,和需求锚定的废案归档一致)
决策者是人,不是 agent。 agent 提供证据和评分,人做最终决定。
方向变动与回退(不用一路翻到底)
单线推进 ≠ 变动就从头再来。方向变动时按被推翻的假设级别决定回退深度,而不是按当前走到哪:
| 变动类型 | 被推翻的是什么 | 回退到 | 重跑范围 |
| 核心假设被推翻(为谁 / 解决什么 / 凭什么赚钱) | 一句话假设 | S0 | 重写 brief,版本 +1,旧版归档 |
| 调研证据与现有结论冲突(市场 / 竞争 / 合规) | 支持性证据 | S2 | 只补受影响证据,重跑受影响维度 |
| 触发 G1 否决项(红线 / 资源 / 无付费方) | 前提条件 | G1 | 重新判定 No-Go 或重定向 |
| 局部调整(定价 / 渠道 / 表述) | 细节 | 不回退 | 当前环节内修订并记录 |
原则:
- 回退到最浅的必要环节;禁止把"从头重跑"当默认。
- 每次方向变动 = 版本 +1,保留旧版和变更理由(可追溯增量,不是重做)。
- 也禁止反向错误:新证据已推翻方向,还无视证据硬往下走。
详细规则见 references/decision.md。
角色
| 角色 | 职责 |
| 提出者 | 提供想法、资源真相、行业信息,参与访谈/数据提供 |
| 分析者(agent) | 设计调研、结构化、找证据、指出缺口、评分 |
| 决策者(人) | 最终 Go / 调整 / No-Go |
衔接 vibecoding-orchestration
- Go → 把
04-decision-brief.md的结论 +01-idea-brief.md+05-research-log.md作为 vibecoding-orchestration 需求锚定的输入。 - No-Go → 归档到
docs/00-requirements/raw/discarded/,注明原因,避免以后重复评估同一个想法。 - 调整后 Go → 先在 brief 里把调整项补完,再重跑 S2/S3 相关环节,不跳过。
参考文档
- 调研与证据收集方法:
references/research.md - 六维度深度分析框架:
references/framework.md - 房产中介门店行业适配:
references/real-estate.md - G1/G2 检查表、决策矩阵与方向变动回退规则:
references/decision.md
产物模板
assets/templates/ 下的模板,按需复制到项目中:
01-idea-brief.md:想法捕捉02-quick-screen.md:G1 快速筛选03-deep-analysis.md:六维度深度报告04-decision-brief.md:一页决策简报05-research-log.md:调研证据清单
红线规则
- 未过 G1 不得进入调研。
- 调研证据不足以支撑的结论,必须标"待验证假设",禁止脑补填补。
- 行业监管、合规事项不确定时,标注"需向平台/当地主管部门确认",禁止编造规则。
- 最终决策权在人,agent 只提供证据与评分。
- 方向变动必须按回退规则处理:先判定被推翻的是核心假设还是支持性证据,再决定回退深度;每次变动记录版本与原因。
- 想法分析不做需求细化、不写代码、不做方案设计——那是 vibecoding-orchestration 的事。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

