problem.plus 文章标准模板#
问题 → 方案 → 产品
适用于：孩子教育 / 工作收入 / 技术工具 / 生活问题
目标：让问题本身，最终变成可复用价值
一、文章 YAML 头（非常关键）#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
---
title: "❓ 一个真实问题的完整标题（用疑问句）"
date: 2026-02-03
author: "张三"
categories:
- 学习与成长 # 只能选 1 个主分类
tags:
# 问题对象
- 孩子教育
- 普通家庭
# 问题本质
- 卡点
- 信息不对称
# 方案属性
- 低成本
- 可复制
- 最小方案
# 产品潜力
- 可产品化
---
|
这一段的本质是：
未来你筛选“能卖的方案”的唯一依据
二、P（Problem）——问题本身（必须真实）#
1️⃣ 问题背景（发生在什么场景）#
1
2
3
4
5
6
7
|
## 这个问题是怎么出现的？
（用第一人称或真实场景描述）
谁遇到的？
在什么情况下？
为什么这个问题会反复出现？
|
📌 原则：
2️⃣ 为什么这个问题难解决？#
1
2
3
4
5
|
## 为什么这个问题一直解决不了？
- 有哪些现实约束？
- 之前试过哪些方法？
- 为什么都失败了？
|
📌 这里要写清楚：
不是人不行，而是路径不对
3️⃣ 这个问题的本质是什么？#
1
2
3
4
5
6
|
## 问题的本质是什么？
（用一句话点破）
这个问题，本质上是一个：
- 路径问题 / 决策问题 / 成本问题 / 信息问题
|
📌 这是你和普通博客拉开差距的地方
三、S（Solution）——解决方案（必须可执行）#
4️⃣ 约束条件（非常重要）#
1
2
3
4
5
6
|
## 解决这个问题时，我的现实约束
- 时间：
- 金钱：
- 技能：
- 可持续性要求：
|
📌 没有约束的方案 = 幻想
5️⃣ 最小可行方案（核心）#
1
2
3
4
5
6
7
|
## 最小可行解决方案（MVS）
在这些约束下，我选择的不是“最好方案”，
而是 **能开始、能坚持、能调整的方案**。
方案一句话说明：
> ……
|
📌 problem.plus 只承认 MVS，不追求完美解
6️⃣ 执行步骤（可复制）#
1
2
3
4
5
6
7
8
9
10
11
12
|
## 具体怎么做？（一步一步）
### 第一步：
做什么？
为什么这么做？
### 第二步：
做什么？
避免什么坑？
### 第三步：
如何判断有没有效果？
|
📌 别人能不能照着做，全靠这一节
7️⃣ 结果与验证#
1
2
3
4
5
|
## 执行后的结果如何？
- 哪些地方有效？
- 哪些地方需要调整？
- 有没有失败的地方？
|
📌 允许不完美，
但必须真实
四、P（Product）——产品化潜力（problem.plus 的核心）#
8️⃣ 这个方案，能不能帮到更多人？#
1
2
3
4
5
6
|
## 这个方案是否具有复用价值？
它是否满足：
- 换一个人，也能用？
- 换一个场景，是否成立？
- 是否可以标准化？
|
9️⃣ 如果把它做成一个“最小产品”#
1
2
3
4
5
6
7
8
9
10
|
## 如果把这个方案做成一个产品
它可能是：
- 一个文档 / 清单
- 一个模板
- 一个工具
- 一个服务流程
适合谁？
解决什么？
|
📌 这里不是卖东西，而是“标注潜力”
🔖 产品化标记（固定结构）#
1
2
3
4
5
6
7
|
---
🧩 产品化信息
- 产品形态：文档 / 模板 / 工具 / 服务
- 目标人群：
- 是否可低成本交付：是 / 否
- 是否可重复售卖：是 / 否
---
|
五、结尾（非常克制）#
1
2
3
4
5
6
7
|
## 写在最后
这个方案不是完美答案，
但它在当下条件下，真实地解决了一个问题。
如果你遇到类似情况，
希望它能帮你少走一些弯路。
|
六、problem.plus 的“隐形规则”（你一定要坚持）#
- 不写“应该”
- 不写“正确答案”
- 只写“在这种条件下，我这样做了”
- 允许失败，但不允许空谈
- 每一篇，都要回答：它能不能复用？
七、你已经拥有的，是一个“系统”#
现在你已经有：
- 首页：问题入口
- 分类页：问题场景
- 模板：问题 → 方案 → 产品
- 标签：筛选与产品化
👉 这已经是一个可长期演进的平台骨架