القائمة
帮助已经有内容、专业经验或个人案例的博主，判断当前知识变现阶段，比较服务、训练营、产品和会员路线，设计第一款可验证的知识产品，并生成30天行动计划。用户提到内容变现、知识付费、卖课、咨询、训练营、会员、个人IP商业化、第一款产品、课程设计、内容很多但不知道卖什么时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 作者或案例背景时，简短说明即可。