Simon Willison 6 月 15 日在个人站点发了一条很短的 quotation。来源是 Julia Evans 的《write for 1 person》。核心意思是：她写作时不会先想象一个抽象大众，而是想一个具体的人。这个人常常是“三年前的自己”，或者一位朋友。
这不是技术圈大新闻。Willison 也不是在写一篇长评论。他只是转引并收藏了这句话。
但这句话对技术写作很有用。它把一个老问题说穿了：很多教程不是知识不够，而是不知道自己在帮谁。
这条内容的边界：转引，不是新理论
能确认的事实很简单。原始观点来自 Julia Evans 的《write for 1 person》。Simon Willison 在自己的站点引用了这句话，并标注来源。
这里要把边界画清楚。材料只能说明 Willison 在 2026 年 6 月 15 日引用了它。不能推成 Julia Evans 当天发布新文章，也不能推成 Willison 做了系统分析。
| 能确认的事 | 不该扩写成 |
|---|---|
| Willison 转引并收藏一句话 | Willison 发表长篇写作方法论 |
| 引语来自 Julia Evans《write for 1 person》 | 这是 Willison 的原创观点 |
| 主题是写作时想象具体读者 | 技术内容行业出现新趋势 |
| 适用场景更偏技术写作、教程、经验分享 | 所有内容生产都该照搬 |
这个边界不只是考据。它也提醒技术作者：别把一条好引语包装成“大事件”。小题大做，反而会稀释它真正有用的地方。
真正有用的地方，是它能改写一篇技术文章的出发点。
“为一个人写”，是在解决教程失焦
技术写作最常见的失焦，是一开头就想“让所有开发者都看懂”。听起来很体面，写出来常常很散。
因为“所有人”没有具体问题。新手看不懂前提，熟手嫌你铺垫太长。最后文章像一页百科，概念不少，路线不清。
“为一个人写”逼作者先做选择。这个人到底是谁？
是三年前的自己，已经会 Python，但第一次被打包、依赖、环境变量卡住。还是一位朋友，懂 SQL，但第一次排查索引为什么没生效。
对象一清楚，取舍就会变简单。哪些概念要补，哪些废话能删，哪里要给命令，哪里要写失败路径，都会更明确。
这和官方文档不是一回事。官方文档追求覆盖面，教程和经验分享更该追求到达率。
| 写作场景 | 更合理的读者设定 | 作者该调整什么 |
|---|---|---|
| 技术教程 | 正在完成某个任务的人 | 写清前提、步骤、验证方式 |
| 经验复盘 | 过去的自己或相似团队 | 交代环境、约束、判断过程 |
| 团队内部方案 | 接下来要接手的人 | 补齐背景、取舍理由、风险点 |
| 官方文档 | 产品的广泛使用者 | 保持完整、准确、可检索 |
限制也在这里。写给一个人，不等于只服务一个人。
它是一种校准工具，不是偷懒的理由。作者仍然要写清版本、环境、前提和适用边界。否则“像对朋友说话”会变成只有熟人才看得懂。
对技术作者最直接的动作：先定读者，再写结构
最该受影响的，是两类人。
一类是写公开教程的开发者内容创作者。动笔前不要只写“这篇讲 Docker”或“这篇讲 PyPI 发布”。先写一句读者设定：这个人会什么、不会什么、现在卡在哪一步。
比如：读者会写 Python，但第一次发布包；读者懂后端开发，但第一次处理容器网络；读者会 SQL，但不知道为什么索引没被用上。
这会直接影响标题和开头。标题应该让人知道对象和任务。开头应该交代读者需要具备什么，不需要具备什么。步骤里要留出验证点和失败路径。
另一类是写团队内部文档的人。内部文档最容易默认“大家都知道背景”。结果新人接手时，看到的全是结论，看不到当时为什么这么选。
对这类作者，更实际的做法是：把读者设成“下个月接手这块的人”。然后补三样东西：当前约束、被放弃的方案、出问题时先查哪里。
写完后，最该检查的不是这句话有没有被引用得漂亮，而是四个位置：
- 标题有没有说明对象和任务；
- 开头有没有交代前提；
- 正文有没有覆盖关键失败路径；
- 结尾有没有告诉读者下一步做什么。
如果这四处都含糊，文章大概率还是写给“所有人”的。看似宽，实际虚。
Willison 收藏这句话的意义，也就落在这里。它不是新理论，更像一把尺。拿它量一下自己的文章，就会发现很多技术稿不是不专业，而是没有一个清楚的读者。