chat-to-notes

对话转笔记

把对话变成一篇文章，不是一份报告。

像在跟朋友讲"我今天搞了个什么事"一样，自然地把探索过程写出来。读者看完应该觉得"这人真的在分享经验"，而不是"这是 AI 按模板填的"。

---

最重要的一条规则

没有固定结构。 结构为内容服务，不是反过来。

不要出现这种机械的骨架：

❌ 禁止的套路：
## 背景
## 探索过程
### 第一版：xxx
### 第二版：xxx
## 关键结论
## 实用启发
## 遗留问题

好文章的结构是从内容里"长"出来的，不是提前规定好的。每篇笔记的小标题应该是独特的、跟内容强相关的，而不是通用的分类标签。

---

怎样才算好文章

对比感受一下

模板感的写法（不要）：

背景

产品经理希望有一个 skill，能根据需求描述快速生成原型。

探索过程

第一版：直接输出 Vue 代码

最初的想法是输出 Vue 代码...

第二版：改成 HTML Demo

换了思路...

关键结论

• 原型的核心是"可演示"
• 改造优于新建

套路一眼就看穿了——几篇下来，读者就知道你永远是这几个板块换皮。

文章感的写法（要这样）：

原型不是画出来的，是从代码里"长"出来的

事情的起因很简单：产品经理想要一个能快速出原型的工具。需求进来，原型出去，双击就能给客户演示。

最开始我想的是直接输出 Vue 代码——毕竟最终是要开发的嘛，一步到位多好。产品经理看了一眼问我："这个……能点吗？"

不能。.vue 文件得跑在开发环境里，产品经理又不可能装 Node.js。原型的价值是"拿来就能演"，不是"拿来就能编译"。想明白这一点，整个方向就变了。

改成输出单个 HTML 文件之后，新的问题冒出来了——开发拿到这个 HTML 怎么办？照着重写一遍？那原型不就成了一次性的东西？

解法是在 HTML 里埋注释……

区别在哪？后者在讲一个有起伏的故事，读者会想知道"后来怎样了"。前者在汇报工作，读者只想快进到结论。

---

写作指引

开头：一句话勾住人

用标题和第一段把读者拉进来。好的开头让人想继续读。

• 标题要具体且有观点："原型不是画出来的，是从代码里长出来的"，而不是"原型设计 Skill 开发记录"
• 第一段交代为什么值得读，不是交代背景信息

中间：跟着好奇心走

按"一个问题引出下一个问题"的节奏展开，而不是按时间线或版本号罗列。

关键要写出来的东西：

• 动机：当时为什么这么想？
• 意外：哪里跟预期不一样？
• 转折：什么时候改变了思路？为什么？
• 判断：做了什么取舍？放弃了什么？

不需要每个都有，挑最有信息量的写。

结尾：自然收束

不需要一个"总结"板块。如果前面写得好，读者已经知道结论了。

可以用一两句话收尾——一个感悟、一个未解的问题、一个对未来的想法。像聊天结束时的最后一句话，不是结业报告。

代码怎么放

代码片段嵌在行文中，作为论据出现，不要单独攒一个"代码展示"区域。就像写技术博客时贴代码一样自然。

---

表达要求

要	不要
"试了一版发现不对"	"经过评估，方案存在不足"
"产品经理看了一眼问我：能点吗？"	"用户反馈该方案不满足交互需求"
"想明白这一点，方向就变了"	"基于以上分析，我们调整了技术方案"
"后来发现一个巧妙的办法"	"综合考虑后，我们提出了优化方案"
把结论融进叙事里	单独拉一个"关键结论"清单

核心：写出"一个人在真诚地分享他的探索经历"的感觉，而不是"一个人在交作业"。

---

工作流程

第一步：通读对话，找到故事

回顾整段对话，问自己：

• 如果我要跟朋友讲这次经历，我会怎么开头？
• 最有意思的转折是什么？
• 读者看完能"带走"什么？

第二步：写初稿

从最想讲的那个点开始写，不要从"背景"开始。让行文自然地带出背景信息。

写的时候想象你在跟一个聪明但不了解这件事的朋友聊天。

第三步：自检

• 把所有 ## 标题单独列出来看一遍——它们像是文章的目录，还是像一个固定模板的字段名？
• 把结尾的"结论清单""启发清单"删掉，看文章是不是已经把这些信息讲清楚了。如果是，就不需要清单
• 找一段连续读三遍，有没有"在念文件"的感觉？有就改到没有为止
• 有没有任何一句以"综上""基于以上""总而言之"开头的？删掉