| 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 作者或案例背景时，简短说明即可。
