Menu
帮助已经有内容、专业经验或个人案例的博主，判断当前知识变现阶段，比较服务、训练营、产品和会员路线，设计第一款可验证的知识产品，并生成30天行动计划。用户提到内容变现、知识付费、卖课、咨询、训练营、会员、个人IP商业化、第一款产品、课程设计、内容很多但不知道卖什么时使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | mdldm-monetize |
| description | 帮助已经有内容、专业经验或个人案例的博主，判断当前知识变现阶段，比较服务、训练营、产品和会员路线，设计第一款可验证的知识产品，并生成30天行动计划。用户提到内容变现、知识付费、卖课、咨询、训练营、会员、个人IP商业化、第一款产品、课程设计、内容很多但不知道卖什么时使用。 |
Turn content into a validated knowledge business.
把麦当 mdldm 从 AI 内容创作、课程交付、会员运营到知识站建设的真实经验，转化为一个面向创作者的诊断与行动系统。
本 Skill 不承诺用户一定赚钱。它负责帮助用户判断：自己现在处于什么阶段、应该先卖什么、如何完成第一次真实验证，以及什么时候才值得课程化、会员化或系统化。
知识付费不是把内容装进收费页面，而是：
把一个明确用户的问题，设计成可购买、可交付、可验收的结果。
判断知识产品是否成立时使用以下公式：
知识产品成立
= 明确的人
× 高频且愿意付费的问题
× 可信的解决能力
× 可感知的交付结果
× 可持续的获客方式
任何一项缺少证据，都应先验证，不应假装产品已经成立。
根据用户请求选择一种模式：
| 模式 | 用户常见表达 | 主要输出 |
|---|---|---|
| Diagnose | 我适合怎么变现 / 帮我看看阶段 | 阶段诊断 + 路线推荐 |
| Offer | 第一款产品卖什么 / 帮我设计产品 | 产品单页 |
| Validate | 怎么证明有人买 / 怎么预售 | 最小验证计划 |
| Deliver | 训练营怎么交付 / 用户如何有结果 | 交付闭环 |
| Systemize | 什么时候录课、做会员、搭站 | 产品化与系统化路线 |
| Review | 我已经做过一轮，帮我复盘 | 证据复盘 + 下一阶段 |
用户没有指定模式时，默认从 Diagnose 开始。
根文件负责总控，不要在每次调用时一次性读取全部子文件。先判断用户当前任务，再加载所需文件：
| 用户任务 | 必读 reference | 使用 template | 需要 example 时 |
|---|---|---|---|
| 判断阶段、判断是否适合知识付费 | references/stage-model.md | templates/diagnosis-report.md | 选择最接近行业的案例 |
| 比较咨询、训练营、课程、会员 | references/monetization-routes.md + references/decision-rules.md | templates/diagnosis-report.md | 选择最接近阶段的案例 |
| 设计第一款知识产品 | references/monetization-routes.md + references/decision-rules.md | templates/offer-onepager.md | 选择最接近行业的案例 |
| 做需求访谈、预售或首期验证 | references/validation-playbook.md | templates/30-day-validation-plan.md + templates/launch-copy.md | 不必默认加载案例 |
| 设计训练营、课程或陪跑交付 | references/common-mistakes.md + references/decision-rules.md | templates/delivery-blueprint.md | 选择相同交付类型的案例 |
| 复盘一轮产品、决定下一阶段 | references/stage-model.md + references/common-mistakes.md | templates/weekly-review.md | 可加载 references/mdldm-case-study.md |
| 询问麦当为什么这样设计 | references/mdldm-case-study.md | 无 | 无 |
加载规则：
SKILL.md 必须完整遵循；每一个关键判断都必须归入以下四类之一：
| 标签 | 含义 | 可以如何使用 |
|---|---|---|
FACT | 用户材料直接证明的事实 | 可以作为结论依据 |
SIGNAL | 重复出现但尚未完成付费验证的信号 | 可以形成假设，不能当作成交证明 |
ASSUMPTION | 为继续推进而做的合理假设 | 必须明确写出，安排验证动作 |
UNKNOWN | 当前缺失且会影响决策的信息 | 优先提问或降低结论置信度 |
以下替代关系一律无效：
高阅读量 ≠ 付费需求
很多收藏 ≠ 用户能完成结果
用户说想学 ≠ 用户愿意付款
一次成交 ≠ 稳定产品
建好网站 ≠ 完成交付系统
完整诊断至少要包含 2 条 FACT。如果没有，先输出“预诊断”，不要伪装成成熟结论。
在给出建议前执行四个 Gate：
不通过：停在 S0/S1，先做问题验证。
不通过：停在 S2，不建议大规模产品化。
不通过：停在 S3，先修交付。
不通过：不建议会员化或复杂系统化。
如果用户提供了文件、文件夹、文章、主页内容、课程大纲、评论、私信或反馈：
| 证据类型 | 要寻找什么 |
|---|---|
| 内容资产 | 反复讲什么、哪些主题表现最好、是否形成系列 |
| 用户信号 | 评论、私信和咨询里反复出现什么问题 |
| 能力证明 | 用户自己或他人做成过什么 |
| 付费证明 | 是否有人为咨询、课程、服务或工具付过钱 |
| 交付能力 | 每周时间、是否能答疑、是否有模板和流程 |
不要把“用户说喜欢”直接当成付费证明，也不要把“内容数据高”直接当成产品成立。
材料不足时，优先一次询问 3 个问题，不要一次把八个问题全丢给用户。
第一组必问：
仍无法判断时，再询问：
如果用户不回答，允许基于现有材料继续，但必须写明假设和置信度。
使用以下阶段模型。证据不足或横跨两个阶段时，默认选择较早阶段，避免过早放大。
| 阶段 | 判断信号 | 当前唯一任务 |
|---|---|---|
| S0 Expression | 主题和专业标签不稳定，没有明确成果 | 找到一个可以持续讲、确实做过的问题 |
| S1 Signal | 有持续内容和互动，但高频问题不明确 | 收集并确认反复出现的用户问题 |
| S2 Validation | 有明确问题和能力证明，但没有稳定付费 | 完成第一次真实收费验证 |
| S3 Delivery | 已有人付费，但交付依赖人肉和临场发挥 | 跑通并记录一次完整交付 |
| S4 Productization | 已重复交付，问题和动作开始稳定 | 模板化、课程化、Skill 化 |
| S5 Systemization | 有稳定获客、产品、交付和持续用户 | 建会员、知识站和成果系统 |
输出阶段时必须附置信度：高 / 中 / 低。
只比较四条主路线：
形式：诊断、咨询、陪跑、代做、顾问。
优先推荐条件：
不推荐条件：用户完全没有时间做高接触交付。
形式：工作坊、小班课、7—14 天训练营、挑战营。
优先推荐条件：
不推荐条件：目标无法在限定周期内形成可见结果。
形式：录播课、模板、资料包、Skill、工具。
优先推荐条件：
不推荐条件：还没有任何收费或交付证据。
形式：会员、社群、订阅、持续更新、工具权益。
优先推荐条件：
不推荐条件：只有一次性内容，没有持续服务机制。
没有付费证据：Service / Cohort 优先
已有重复交付：Product 优先
已有持续需求和运营节奏：Membership 才进入候选
至少给出三条路线：
使用以下字段：
| 字段 | 要求 |
|---|---|
| 路线 | Service / Cohort / Product / Membership |
| 为什么匹配 | 必须引用用户证据 |
| 30 天可验证什么 | 只能写可观察结果 |
| 主要成本 | 时间、交付、内容、技术 |
| 最大风险 | 该用户最容易踩的坑 |
| 进入下一阶段的条件 | 明确退出标准 |
不要仅输出泛泛的优缺点。
产品必须围绕一个可验收结果，而不是知识目录。
使用以下公式：
帮助 [某一类人]
在 [具体场景]
解决 [高频问题]
通过 [交付方式]
在 [合理周期]
完成 [可验收结果]
标准产品单页：
## 第一款产品
- 产品名：
- 服务对象：
- 发生场景：
- 核心问题：
- 承诺结果：
- 结果如何验收：
- 交付方式：
- 交付周期：
- 首期人数：
- 价格假设：
- 价格依据：
- 用户为什么相信你：
- 不适合谁：
- 本期明确不包含：
计划只分四周，每周必须有交付物和退出标准。
目标：确认用户是否真的有这个问题。
默认动作：
退出标准：至少 3 位目标用户确认问题真实且正在寻找解决办法。
目标：测试用户是否愿意为方案付费。
默认动作：
退出标准：出现真实付款，或获得清晰可归因的拒绝理由。
目标：让用户获得一个可验收结果。
默认动作：
退出标准：至少 60% 的参与者完成核心结果；如果人数太少，不强行使用比例，直接记录完成情况。
目标：把交付变成可复用资产。
默认动作：
退出标准：至少形成 1 个完整案例、1 份交付 SOP、1 个下一轮产品修改决定。
只有满足以下至少四项，才建议搭建知识站或复杂交付系统：
未满足时，优先使用文档、表单、群和简单支付完成验证。
知识站的正确角色：
它不是寻找产品的起点，而是放大已经验证过的交付闭环。
完整诊断读取并使用 templates/diagnosis-report.md。
如果用户只问一个局部问题，直接回答该问题，不强制展开完整报告。
回复前检查：
如果任一项为“否”，先修正再输出。
本方法由麦当 mdldm 基于真实 AI 内容创作、课程、会员、答疑、工具权益与知识站运营经验整理。
对外输出中不需要反复宣传作者。只有用户询问方法来源、Skill 作者或案例背景时，简短说明即可。