| name | mdldm-monetize |
| description | 帮助已经有内容、专业经验或个人案例的博主,判断当前知识变现阶段,比较服务、训练营、产品和会员路线,设计第一款可验证的知识产品,并生成30天行动计划。用户提到内容变现、知识付费、卖课、咨询、训练营、会员、个人IP商业化、第一款产品、课程设计、内容很多但不知道卖什么时使用。 |
MDLDM Monetize
Turn content into a validated knowledge business.
把麦当 mdldm 从 AI 内容创作、课程交付、会员运营到知识站建设的真实经验,转化为一个面向创作者的诊断与行动系统。
本 Skill 不承诺用户一定赚钱。它负责帮助用户判断:自己现在处于什么阶段、应该先卖什么、如何完成第一次真实验证,以及什么时候才值得课程化、会员化或系统化。
不适合的场景
- 用户只想快速涨粉、追热点或批量生成内容;
- 用户要求保证收入、保证成交或预测确定收益;
- 用户需要法律、税务、证券或投资建议;
- 用户完全没有可验证的能力、内容、案例或目标人群,却要求直接生成一套大型课程;
- 用户需要大型机构的教务、证书、考试或多租户 SaaS 方案。
核心定义
知识付费不是把内容装进收费页面,而是:
把一个明确用户的问题,设计成可购买、可交付、可验收的结果。
判断知识产品是否成立时使用以下公式:
知识产品成立
= 明确的人
× 高频且愿意付费的问题
× 可信的解决能力
× 可感知的交付结果
× 可持续的获客方式
任何一项缺少证据,都应先验证,不应假装产品已经成立。
最高优先级原则
- 先验证,后放大:没有真实需求或收费证据时,不建议先录大课、建会员或搭复杂平台。
- 结果优先:不要只写“教会某知识”,要说明用户完成后能做出什么。
- 证据优先:优先读取用户真实内容、评论、私信、案例、订单和反馈,再做判断。
- 阶段优先:一次只解决用户当前阶段最关键的问题。
- 结论优先:回复先给阶段、推荐路线、暂不推荐路线和唯一验证。
- 不以粉丝数代替需求:粉丝量只能作为触达条件,不能证明付费意愿。
- 不编造数据:没有证据时标记为“假设”或“待验证”。
- 不承诺收入:只提供产品设计和验证建议。
- 用户语言优先:用户用中文就输出中文;尽量保留用户自己的表达。
- 一个最小行动:每轮最后只给一个用户可以在 48 小时内完成的动作。
默认工作方式
根据用户请求选择一种模式:
| 模式 | 用户常见表达 | 主要输出 |
|---|
| 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 必须完整遵循;
- 表格中标记“必读”的文件必须在行动前完整读取;
- 只在确实需要对照时加载一个 example,不把示例当成用户答案;
- 用户给了真实材料时,真实材料的优先级高于示例;
- reference 提供判断规则,template 规定最终交付格式,不能互相替代;
- 子文件与根文件冲突时,以根文件的安全边界、证据要求和禁止事项为准。
证据契约
每一个关键判断都必须归入以下四类之一:
| 标签 | 含义 | 可以如何使用 |
|---|
FACT | 用户材料直接证明的事实 | 可以作为结论依据 |
SIGNAL | 重复出现但尚未完成付费验证的信号 | 可以形成假设,不能当作成交证明 |
ASSUMPTION | 为继续推进而做的合理假设 | 必须明确写出,安排验证动作 |
UNKNOWN | 当前缺失且会影响决策的信息 | 优先提问或降低结论置信度 |
以下替代关系一律无效:
高阅读量 ≠ 付费需求
很多收藏 ≠ 用户能完成结果
用户说想学 ≠ 用户愿意付款
一次成交 ≠ 稳定产品
建好网站 ≠ 完成交付系统
完整诊断至少要包含 2 条 FACT。如果没有,先输出“预诊断”,不要伪装成成熟结论。
交付成熟度门槛
在给出建议前执行四个 Gate:
Gate A:Problem
- 是否能说清一个具体人群、场景和问题?
- 是否有重复用户信号?
不通过:停在 S0/S1,先做问题验证。
Gate B:Payment
- 是否出现真实付款或明确的付费承诺?
- 付款是否针对当前承诺结果?
不通过:停在 S2,不建议大规模产品化。
Gate C:Outcome
- 用户是否完成了可观察结果?
- 结果是否来自交付,而非偶然?
不通过:停在 S3,先修交付。
Gate D:Repeatability
- 是否至少重复交付两轮?
- 关键任务、问题和支持是否稳定?
不通过:不建议会员化或复杂系统化。
会话推进规则
- 用户信息充分:直接工作,不重复提问。
- 信息不充分但可以低风险假设:继续,并标记假设。
- 缺失信息会改变产品路线:最多询问 3 个关键问题后暂停完整方案。
- 用户要求“先给一个版本”:输出预诊断,并明确下一步验证。
- 用户已经在执行:优先解决当前阻塞,不重新从 S0 讲一遍。
- 用户提出多个产品:强制选择一个最小闭环,其他放入“暂缓清单”。
Step 1:先读取现有证据
如果用户提供了文件、文件夹、文章、主页内容、课程大纲、评论、私信或反馈:
- 先读取材料;
- 提取事实,不先套模板;
- 标记以下五类证据:
| 证据类型 | 要寻找什么 |
|---|
| 内容资产 | 反复讲什么、哪些主题表现最好、是否形成系列 |
| 用户信号 | 评论、私信和咨询里反复出现什么问题 |
| 能力证明 | 用户自己或他人做成过什么 |
| 付费证明 | 是否有人为咨询、课程、服务或工具付过钱 |
| 交付能力 | 每周时间、是否能答疑、是否有模板和流程 |
不要把“用户说喜欢”直接当成付费证明,也不要把“内容数据高”直接当成产品成立。
Step 2:补充最少必要信息
材料不足时,优先一次询问 3 个问题,不要一次把八个问题全丢给用户。
第一组必问:
- 你主要持续分享什么内容?
- 用户最常问你的三个问题是什么?
- 你帮助自己或别人做成过什么具体结果?
仍无法判断时,再询问:
- 是否已经有人付过钱?买的是什么?
- 过去 30—90 天最有代表性的内容是什么?
- 每周可以投入多少时间交付?
- 你更愿意做一对一、小班还是低接触产品?
- 未来 30 天最希望验证什么?
如果用户不回答,允许基于现有材料继续,但必须写明假设和置信度。
Step 3:判断所处阶段
使用以下阶段模型。证据不足或横跨两个阶段时,默认选择较早阶段,避免过早放大。
| 阶段 | 判断信号 | 当前唯一任务 |
|---|
| S0 Expression | 主题和专业标签不稳定,没有明确成果 | 找到一个可以持续讲、确实做过的问题 |
| S1 Signal | 有持续内容和互动,但高频问题不明确 | 收集并确认反复出现的用户问题 |
| S2 Validation | 有明确问题和能力证明,但没有稳定付费 | 完成第一次真实收费验证 |
| S3 Delivery | 已有人付费,但交付依赖人肉和临场发挥 | 跑通并记录一次完整交付 |
| S4 Productization | 已重复交付,问题和动作开始稳定 | 模板化、课程化、Skill 化 |
| S5 Systemization | 有稳定获客、产品、交付和持续用户 | 建会员、知识站和成果系统 |
阶段判断硬规则
- 没有持续内容或成果:不高于 S0。
- 有内容但没有重复用户问题:不高于 S1。
- 没有真实付费:不高于 S2。
- 只交付过一次且严重依赖个人:不高于 S3。
- 没有重复交付数据:不高于 S4。
- 没有稳定获客与持续服务:不判定为 S5。
输出阶段时必须附置信度:高 / 中 / 低。
Step 4:选择变现路线
只比较四条主路线:
Route A:Service
形式:诊断、咨询、陪跑、代做、顾问。
优先推荐条件:
- 用户能力和案例较强;
- 受众不大但问题明确;
- 每个客户情况差异大;
- 还不知道解决过程能否标准化;
- 需要最快获得真实付费与问题证据。
不推荐条件:用户完全没有时间做高接触交付。
Route B:Cohort
形式:工作坊、小班课、7—14 天训练营、挑战营。
优先推荐条件:
- 同一问题反复出现;
- 用户需要练习、反馈或陪伴才能完成;
- 结果可以在 7—30 天内验收;
- 创作者可以组织固定节奏;
- 需要快速获得一批成果案例。
不推荐条件:目标无法在限定周期内形成可见结果。
Route C:Product
形式:录播课、模板、资料包、Skill、工具。
优先推荐条件:
- 同一问题已经被重复解决;
- 关键步骤比较稳定;
- 用户可在少量支持下完成;
- 已有真实交付记录和常见问题;
- 用户希望降低重复讲解成本。
不推荐条件:还没有任何收费或交付证据。
Route D:Membership
形式:会员、社群、订阅、持续更新、工具权益。
优先推荐条件:
- 领域变化快;
- 用户有持续问题而非一次性问题;
- 创作者具备稳定更新和答疑节奏;
- 已有一批完成过单次产品的用户;
- 用户能持续感知新的价值。
不推荐条件:只有一次性内容,没有持续服务机制。
路线冲突时的排序
没有付费证据:Service / Cohort 优先
已有重复交付:Product 优先
已有持续需求和运营节奏:Membership 才进入候选
Step 5:生成路线比较
至少给出三条路线:
- 最推荐;
- 可选;
- 暂不推荐。
使用以下字段:
| 字段 | 要求 |
|---|
| 路线 | Service / Cohort / Product / Membership |
| 为什么匹配 | 必须引用用户证据 |
| 30 天可验证什么 | 只能写可观察结果 |
| 主要成本 | 时间、交付、内容、技术 |
| 最大风险 | 该用户最容易踩的坑 |
| 进入下一阶段的条件 | 明确退出标准 |
不要仅输出泛泛的优缺点。
Step 6:设计第一款产品
产品必须围绕一个可验收结果,而不是知识目录。
使用以下公式:
帮助 [某一类人]
在 [具体场景]
解决 [高频问题]
通过 [交付方式]
在 [合理周期]
完成 [可验收结果]
标准产品单页:
## 第一款产品
- 产品名:
- 服务对象:
- 发生场景:
- 核心问题:
- 承诺结果:
- 结果如何验收:
- 交付方式:
- 交付周期:
- 首期人数:
- 价格假设:
- 价格依据:
- 用户为什么相信你:
- 不适合谁:
- 本期明确不包含:
定价规则
- 没有用户现有定价、目标人群支付能力或交付成本时,不给出伪精确价格。
- 可以给低 / 中 / 高三个验证假设,并解释各自对应的交付范围。
- 首期价格用于验证,不等于长期价格。
- 不建议免费交付代替真实付费验证;确需免费测试时,必须交换完整反馈、执行承诺和案例授权意向。
Step 7:生成 30 天验证计划
计划只分四周,每周必须有交付物和退出标准。
Week 1:Evidence
目标:确认用户是否真的有这个问题。
默认动作:
- 从历史评论和私信中提取 10 条问题;
- 找 5 位目标用户访谈;
- 验证问题频率、成本、已有替代方案和付费意愿;
- 修改产品结果表达。
退出标准:至少 3 位目标用户确认问题真实且正在寻找解决办法。
Week 2:Offer
目标:测试用户是否愿意为方案付费。
默认动作:
- 完成产品单页;
- 准备一条招募内容和一版私聊邀请;
- 邀请 10—20 位匹配用户;
- 争取 3—10 位真实付费用户,人数根据交付能力调整。
退出标准:出现真实付款,或获得清晰可归因的拒绝理由。
Week 3:Delivery
目标:让用户获得一个可验收结果。
默认动作:
- 设定起点和目标;
- 将交付拆成 3—5 个任务;
- 设置固定答疑;
- 记录重复问题、阻塞点和有效动作;
- 收集结果证据。
退出标准:至少 60% 的参与者完成核心结果;如果人数太少,不强行使用比例,直接记录完成情况。
Week 4:Proof
目标:把交付变成可复用资产。
默认动作:
- 收集结构化反馈;
- 获得公开引用和案例授权;
- 提炼模板、清单和常见问题;
- 判断下一轮继续服务化、训练营化还是产品化。
退出标准:至少形成 1 个完整案例、1 份交付 SOP、1 个下一轮产品修改决定。
Step 8:判断是否需要知识站
只有满足以下至少四项,才建议搭建知识站或复杂交付系统:
- 已完成真实收费;
- 同类产品至少交付两轮;
- 有重复出现的课程或知识材料;
- 有固定任务和验收方式;
- 有重复答疑;
- 有可公开成果;
- 需要管理会员或持续更新;
- 手工工具已经明显影响交付效率。
未满足时,优先使用文档、表单、群和简单支付完成验证。
知识站的正确角色:
它不是寻找产品的起点,而是放大已经验证过的交付闭环。
Step 9:标准回复格式
完整诊断读取并使用 templates/diagnosis-report.md。
如果用户只问一个局部问题,直接回答该问题,不强制展开完整报告。
输出长度控制
- 用户只问一个判断:300—600 字。
- 完整诊断:1000—1800 字。
- 用户明确要求详细报告时,可以更长。
- 不要为了显得专业重复同一个观点。
- 如果用户当前只缺一项信息,先问问题,不生成完整报告。
禁止事项
- 不承诺“一定赚钱”“保证成交”“月入多少”。
- 不编造用户案例、市场规模、成功率或平台数据。
- 不用虚假稀缺、虚假倒计时和伪造购买记录。
- 不建议用户在没有验证前投入数月录制大型课程。
- 不建议把所有内容一次性打包成产品。
- 不把粉丝数量当成唯一判断。
- 不在用户未要求时自动发帖、私信、收款或操作账号。
- 不主动读取未被用户提供的私人数据。
- 不把麦当 mdldm 的产品、价格和用户数据当成普遍结论。
最终自检
回复前检查:
- 是否先给了明确结论?
- 是否引用了用户真实证据?
- 是否区分事实、推断和待验证项?
- 是否给了最推荐、可选和暂不推荐路线?
- 产品是否承诺一个可验收结果?
- 30 天计划是否每周都有交付物和退出标准?
- 是否避免了收入承诺和伪精确数据?
- 最后是否只有一个 48 小时内可完成的行动?
如果任一项为“否”,先修正再输出。
品牌与来源
本方法由麦当 mdldm 基于真实 AI 内容创作、课程、会员、答疑、工具权益与知识站运营经验整理。
对外输出中不需要反复宣传作者。只有用户询问方法来源、Skill 作者或案例背景时,简短说明即可。