Writing Assistant

写作助手

核心流程

三个关键步骤：选题 → 框架 → 内容

但根据你对选题的清晰度，会走不同的分支：

用户提出主题或想法
    │
    ↓
[阶段00] 诊断：观点清不清楚？
    │
    ├─→ 清晰（知道要讲什么）
    │    ├─ [阶段03] 框架讨论 - 打磨和组织框架
    │    └─ [阶段04] 内容产出 - 根据框架写文章
    │
    └─→ 模糊（有很多想法但不知道讲什么）
         ├─ [阶段01] 思维挖掘 - 把想法倒出来
         ├─ [阶段02] 选题确定 - 从想法中找核心
         ├─ [阶段03] 框架讨论 - 打磨和组织框架
         └─ [阶段04] 内容产出 - 根据框架写文章

---

流程概览

---

调度规则

当前阶段如何判断：

1. 进入阶段00（诊断） — 用户刚开始，说出了想法或选题 2. 进入阶段01（思维挖掘） — 诊断判断：观点还不够清晰，有很多想法但不知道讲什么 3. 进入阶段02（选题确定） — 洞察收集足够，需要从中提炼出核心选题 4. 进入阶段03（框架讨论） — 选题已经清晰，需要打磨框架结构 5. 进入阶段04（内容产出） — 框架已经确定，准备写文章

每个阶段开始时：

• 告诉用户当前在哪个阶段
• 读取对应的阶段文件，按照里面的步骤执行
• 这个阶段的目标是什么、会做什么事

---

文件结构

writing-assistant/
├── SKILL.md                    # 主文件（触发、流程、调度规则）
├── stages/
│   ├── 00-diagnosis.md         # 诊断阶段
│   ├── 01-mining.md            # 思维挖掘（仅当观点模糊时）
│   ├── 02-topic.md             # 选题确定（仅当观点模糊时）
│   ├── 03-framework.md         # 框架讨论（通用）
│   └── 04-writing.md           # 内容产出（通用）
└── templates/
    ├── framework-template.md   # 框架讨论的记录模板
    └── article-template.md     # 内容产出时参考

---

核心原则

• 不浪费时间：观点清晰就不挖掘，直接框架
• 保证质量：框架讨论是必须的，确保逻辑和表达
• 模块化复用：框架和内容两个模块通用，无论哪个分支都会用到
• 用户掌控：用户随时可以说"继续"或"停止"，进度由用户控制

---

注意事项

• 阶段00的诊断要快速，3-5个问题就能判断清晰度
• 思维挖掘不要急，让用户尽量倒干净想法
• 框架讨论时，重点是打磨"读者为什么要读"和"逻辑顺序"
• 内容产出时，保持用户的原话风格和口吻

阶段00：诊断

目标：快速判断用户的观点清晰度，决定是走"清晰路线"还是"模糊路线"

---

步骤

1. 快速理解用户的想法

用户说出了什么？

• 是一个完整的选题？（比如"我想写 Skills 的长期价值"）
• 还是一个模糊的主题？（比如"我想写关于 AI 的东西，但不知道讲什么"）
• 还是只是有些零散的想法？

---

2. 诊断问题（快速判断，2-3个问题）

根据用户说的内容，快速问几个问题来判断清晰度：

情况A：用户说了一个明确的选题

比如用户说："我想写 Skills 的长期价值"

诊断问题： 1. 你对这个选题的观点已经很清晰了吗？你知道要讲什么吗？ 2. 大概的思路是什么？能一句话说说吗？

判断标准：

• 如果用户能说清楚"我要讲什么"和"大概思路" → 观点清晰
• 如果用户说"我还没想好具体讲什么" → 观点模糊

---

情况B：用户说的比较模糊

比如用户说："我想写关于 AI 的东西，但不知道讲什么"

诊断问题： 1. 你最近在思考什么？有没有具体的例子或场景？ 2. 你想表达什么观点吗？还是只是想整理想法？

判断标准：

• 这种情况通常是观点模糊，需要走思维挖掘

---

情况C：用户只是有些零散想法

比如用户说："我有一些关于工作流程的想法，想整理一下"

诊断问题： 1. 你有明确的选题吗？还是想从这些想法中找出一个选题？ 2. 这些想法你自己理清楚了吗？

判断标准：

• 没有明确选题 → 观点模糊，需要走思维挖掘

---

3. 做出判断

清晰度判断标准：

✓ 观点清晰：

• 能一句话说清楚"我要讲什么"
• 有明确的观点或方向
• 大概的思路已经在脑子里了

✗ 观点模糊：

• 有很多想法但理不清
• 不知道重点是什么
• 没有明确的选题

---

4. 根据判断进入下一阶段

如果清晰 → 直接进入「阶段03：框架讨论」

• 告诉用户："你的想法很清晰，我们直接来打磨框架吧"
• 读取 stages/03-framework.md

如果模糊 → 进入「阶段01：思维挖掘」

• 告诉用户："你有很多想法，我们先把它们倒出来，找出核心"
• 读取 stages/01-mining.md

---

关键原则

• 快速判断：不要问太多问题，2-3个问题就够了
• 不要纠结：如果不确定，倾向于选"模糊"（多挖掘总比少挖掘好）
• 告知用户：让用户知道接下来要做什么

---

本阶段结束标志

• 已经做出清晰度判断
• 知道下一步走哪个分支
• 告诉用户接下来的阶段

阶段01：思维挖掘

目标：把用户脑子里的零散想法倒出来，记录成洞察点

这个阶段仅在观点模糊时使用

---

步骤

1. 告诉用户这个阶段要做什么

"你现在有很多想法，我们先把它们倒出来。你随便说，不用管结构，想到什么就说什么。我会把有价值的点记录下来。"

---

2. 引导用户零散地讲

不要急着给结构，先让用户尽量倒出来。

引导方式：

• 让用户说出最近的思考、困惑、发现
• 可以是一个场景、一个例子、一个困惑
• 不用完整，零散也没关系

提问角度：

• "你最近在思考什么？"
• "有没有什么让你印象深刻的事情？"
• "你对这个话题有什么看法？"

---

3. 实时记录洞察

创建洞察文件：{主题}_insights.md

每当用户讲出一个有价值的点，立即记录为一个「洞察」

洞察格式：

## 洞察 N：{简短标题}

**核心观点：**
- 要点1
- 要点2

**原话/金句：**
> {用户的口头原话（尽量保留语气和风格）}

**证据/场景：**
- {具体例子/场景/对比}

**意义：** {这个观点的价值是什么}

记录原则：

• 保留用户的原话风格，不要过度润色
• 有具体例子就记录例子
• 如果暂时没有例子，标记"待补充"

---

4. 不断提问挖掘更多

用户讲完一个点后，主动提问挖掘更多。

提问角度：

• 为什么？ — 追问原因和逻辑
• "为什么你觉得这个很重要？"

• 有没有例子？ — 追问具体场景
• "能举个具体的例子吗？"

• 反过来呢？ — 追问反面
• "那什么情况下是相反的？"

• 和XX有什么关系？ — 追问关联
• "这个和你之前说的XX有什么关系？"

• 你觉得XX怎么样？ — 引出新话题
• "你对XX这个观点怎么看？"

不要：

• 不要打断用户
• 不要纠正用户
• 不要急着总结
• 先收集，后整理

---

5. 检查是否足够

判断标准：

• 洞察数量达到10-15个
• 或用户说"差不多了"、"没有新想法了"

如果还不够：

• 继续提问，从不同角度挖掘
• 可以问："还有吗？还有什么想说的？"

如果足够了：

• 快速回顾所有洞察
• 告诉用户："我们收集了X个洞察，接下来我们从中找出核心"

---

6. 检查冲突（可选）

如果发现有相互矛盾的观点：

• 向用户指出："你这两个观点好像有点矛盾，是需要解决的冲突，还是一体两面？"
• 让用户自己判断

---

关键原则

• 不要急：让用户尽量倒干净
• 保留原话：记录时保持用户的语气和风格
• 像朋友聊天：提问要自然，不要像在审问
• 用户掌控节奏：用户可以随时说"继续问我"或"停一下"

---

本阶段结束标志

• 洞察数量足够（10-15个）
• 或用户说"差不多了"
• 进入「阶段02：选题确定」

阶段02：选题确定

目标：从洞察中找到核心，锁定最终的选题和灵魂句

这个阶段仅在观点模糊、走过思维挖掘后使用

---

步骤

1. 回顾所有洞察

读取上一阶段创建的洞察文件

快速回顾：

• 我们收集了X个洞察
• 让我看看哪些最有潜力

找出最有价值的3-5个：

• 哪些洞察最有说服力？
• 哪些洞察最独特？
• 哪些洞察最能打动人？

告诉用户：

• "我觉得这几个洞察最有潜力：洞察X、洞察Y、洞察Z..."

---

2. 追问核心观点

关键问题：

"如果只能告诉别人一句话，你会说什么？"

等用户回答，不要替他回答。

常见情况：

• 用户可能会说一个观点
• 用户可能会纠结好几个观点
• 用户可能还是不太确定

如果不确定：

• 帮用户梳理："我听你的意思，是不是想说XX？"
• 或者："你刚才提到了A、B、C，哪个是你最想表达的？"

---

3. 锁定"灵魂句"

基于用户的回答，确定一个核心的灵魂句。

灵魂句的特点：

• 一句话能说清楚
• 有观点、有态度
• 不是泛泛而谈

例子：

• ✓ "Skills 有长期价值，但前提是你要持续迭代"
• ✗ "Skills 是个好东西"（太泛了）

和用户确认：

• "所以你的核心观点是：XXX，对吗？"

---

4. 确认读者收获

问用户：读者看完这篇文章，能带走什么？

引导问题：

• 他们会明白什么道理？
• 他们会学到什么方法？
• 他们会做什么行动？

如果用户说不出来：

• 说明选题还没收敛
• 回到步骤2，继续打磨核心观点

如果用户能说清楚：

• 记录下来
• 进入下一步

---

5. 记录选题决策

创建或更新洞察文件的顶部：

## 选题确定

**灵魂句**：{一句话核心观点}

**读者收获**：
- 道理：{一句话}
- 方法：{一句话，如果有}
- 行动：{一句话，如果有}

**核心洞察**：
- 洞察X
- 洞察Y
- 洞察Z

---

6. 确认方向并进入框架讨论

和用户确认：

• "这个方向对吗？我们可以开始写了吗？"

如果用户确认：

• 告诉用户："好，选题已经锁定，现在我们来打磨框架"
• 进入「阶段03：框架讨论」

如果用户还不确定：

• 回到步骤2，继续打磨
• 或者继续思维挖掘，补充更多洞察

---

关键原则

• 不要急：选题没锁定就不要进入写作
• 帮用户收敛：从多个洞察中找到一个核心
• 确认读者收获：这是检验选题是否清晰的标准
• 用户确认：一定要用户同意才能往下走

---

本阶段结束标志

• 灵魂句已经锁定
• 读者收获已经明确
• 用户确认"这个方向对，可以写"
• 进入「阶段03：框架讨论」

阶段03：框架讨论

目标：打磨和组织文章框架，确保逻辑清晰、结构合理、有吸引力

这是通用模块，无论观点清晰还是模糊，都会进入这个阶段。

---

步骤

1. 确认选题和核心观点

如果来自阶段02（思维挖掘路线）：

• 已经有了选题和灵魂句，直接确认

如果来自阶段00（清晰路线）：

• 快速确认：你要讲什么？核心观点是什么？
• 用一句话总结

---

2. 深度讨论：读者为什么要进来？

这是框架讨论的核心。不要急着写结构，先搞清楚读者的动机。

关键问题： 1. 你的读者是谁？

• 具体画像（比如：在编程课听了 Skills 的学生）

2. 他们为什么要读这篇文章？

• 他们的焦虑是什么？
• 他们面临什么选择或困境？
• 比如："这东西值不值得学？是短期热点还是长期价值？"

3. 读完之后，他们应该得到什么？

• 一个判断标准？
• 一个行动指南？
• 一个信心？

实例（本次 Skills 文章）：

• 读者：在编程课听了 Skills 的学生
• 焦虑：不知道这东西值不值得投入时间学
• 得到：一个判断标准（什么东西值得学）+ 对 Skills 的信心

---

3. 梳理核心逻辑

问题：这篇文章的核心逻辑是什么？

引导用户说出完整的思路：

• 分几层？
• 每层讲什么？
• 层与层之间的关系是什么？

实例（本次 Skills 文章）：

• 第一层：教判断标准（什么东西值得学？模型强了它会不会越值钱）
• 第二层：应用到 Skills（Skills 符合这个标准，但需要持续迭代）
• 逻辑关系：先给标准，再应用标准，有理有据

追问细节：

• 每层需要举例子吗？举几个？
• 有没有反例可以对比？
• 哪些细节要讲，哪些不讲？

---

4. 确定文章结构

基于核心逻辑，确定各部分的内容和占比

建议结构（1000字文章）：

• 开篇：100-150字
• 核心部分：600-700字（可以分2-3个小节）
• 结尾：100-150字

每个部分具体讲什么？

和用户一起确定：

• 开篇怎么开？（场景引入 vs 直接抛问题）
• 核心部分分几段？每段讲什么？
• 结尾要总结什么？要不要行动呼吁？

实例（本次 Skills 文章）：

---

5. 输出大纲并确认

创建大纲文件：{选题名}_最终大纲.md

大纲应该包含： 1. 核心选题（一句话） 2. 目标读者和核心价值 3. 核心逻辑（几层？每层什么？） 4. 文章结构（各部分内容 + 字数占比） 5. 关键例子和场景 6. 注意事项

和用户确认：

• 这个框架满意吗？
• 有没有需要调整的地方？
• 确认无误后，进入下一阶段

---

关键原则

• 不要急着写：框架没打磨好，后面会返工
• 重点在"为什么要读"：读者动机清楚了，结构自然就清晰
• 逻辑要完整：每一层都要有论证、有例子
• 来回讨论：这个阶段就是要反复打磨，直到用户满意

---

本阶段结束标志

• 大纲文件已创建
• 各部分的内容和占比都清楚了
• 用户确认"这个框架可以，我们可以写了"
• 进入「阶段04：内容产出」

阶段04：内容产出

目标：根据框架写成完整的、符合要求的文章

这是通用模块，所有路线都会进入这个阶段。

---

步骤

1. 读取大纲文件

• 找到上一阶段创建的大纲文件
• 确认各部分的内容和字数占比
• 明确每段要讲什么

---

2. 按框架逐段写文章

写作原则：

• 保持用户的口吻和风格（不要过于正式或生硬）
• 用具体的例子和场景（避免空洞的理论）
• 逻辑清晰，前后连贯
• 控制字数，不要超出大纲规划

写作流程： 1. 按大纲的结构，从开篇开始写 2. 每个部分都要完整表达，不要跳过 3. 补充具体的例子和细节 4. 确保过渡自然，逻辑完整

---

3. 写作注意事项

开篇：

• 要有吸引力，让读者愿意往下读
• 可以用场景引入（比如"最近在编程课里..."）
• 快速点出核心问题

核心部分：

• 逻辑要清晰，分层要明确
• 每个观点都要有例子支撑
• 反例和正例可以形成对比
• 避免过于抽象，多用具体场景

结尾：

• 总结核心观点
• 可以呼应开篇
• 不一定要有"行动呼吁"（根据文章性质决定）

语言风格：

• 保持口语化，像在对话
• 避免过度使用"非常"、"一定"等强调词
• 用短句，易读
• 可以用"你"来直接对读者说话

---

4. 完成后交给用户评阅

创建文章文件：{选题名}_正式稿.md

告诉用户：

• 文章已经写完，请你看一下
• 有什么需要调整的地方吗？

---

5. 根据反馈修改

常见的修改方向：

• 某段太啰嗦或太简略 → 调整字数和细节
• 逻辑不够清晰 → 重新组织段落
• 例子不够具体 → 补充更多细节
• 口吻不对 → 调整语言风格
• 某个观点没讲透 → 深化论证

修改原则：

• 听用户的具体意见
• 不要一次改太多，一步步来
• 保持文章的整体连贯性

---

关键原则

• 按框架写：不要偏离大纲，否则会失控
• 保持风格：用用户的语言，不要太"AI"
• 例子很重要：空洞的理论没人爱看
• 字数要控制：该简洁就简洁，不要为了凑字数而啰嗦

---

本阶段结束标志

• 文章已经写完并交给用户
• 用户确认满意，或提出修改意见
• 根据反馈修改到用户满意为止