精读笔记｜个人品牌与技术写作：从笔记到博客的发布工作流案例研究（三博主流程拆解） 未开始

题记与说明

• 日期：2026-10-31（任务发起于 2026-10-30 深夜，跨零点完成）
• 形式：主题研究（topic research）——按主题检索 3-5 个来源精读，拆解 3 位真实博主的"笔记 → 博客"发布工作流
• 三位博主：Simon Willison（自动化管线派）、Josh W. Comeau（重工程内容即软件派）、Manuel Moreale（极简手工派）
• 来源数量：5 个（全部本次实际读取，方法与引述见下）

0. 检索与精读记录（本次实际执行）

检索词（WebSearch × 4）：

1. Simon Willison TIL "Today I Learned" git repo notes publish workflow simonwillison.net
2. Josh W Comeau "How I Built My Blog" MDX writing workflow
3. Manuel Moreale "People and Blogs" interview bloggers writing publishing process
4. Simon Willison "Things I've learned" TIL datasette publish GitHub Actions notes blog 2020

检索修正一处：搜索摘要声称 TIL 部署到 Google Cloud Run；实测当前 build.yml 为 datasette publish fly tils.db --app simonw-tils（Fly.io）。早期确为 Cloud Run，但本笔记以实测 workflow 文件为准。

未读/未验证项（诚实标注）：Manu 2017 年《Personal brand is a stupid concept》仅在站点存档列表中见到标题，正文 404 未能读取，本文不引用其内容。三篇 WebFetch 来源为模型摘要+引述，非逐行全文。

1. 三个真实博主的流程拆解

案例一：Simon Willison —— "commit 即发布"的 TIL 流水线（自动化管线派）

身份：Django 联合创始人、Datasette 作者，simonwillison.net 是其职业声誉引擎。

笔记形态：simonw/til 仓库中的 Markdown 文件，按主题目录组织（80+ 个目录：python、sqlite、llms、github-actions……甚至 cocktails/cooking），README 自动生成索引。精读时仓库含 583 条 TIL、2,195 次 commit。

工作流拆解（据 build.yml 实测）：

1. 捕获：学到任何小东西 → 写一个 Markdown 文件放进对应主题目录；
2. 发布：git push 到 main 即触发 GitHub Actions（on: push: branches: - main）；
3. 构建：python build_database.py 把 Markdown 汇入 SQLite（tils.db），先从 S3 拉上一次的数据库增量合并；
4. 质检：datasette . --get / | grep "Simon Willison: TIL" ——发布前自动验证站点活着；
5. 索引自维护：python update_readme.py --rewrite 自动重写 README 并 commit 回仓库；
6. 上线：s3-credentials put-object 存数据库 + datasette publish fly 部署到 Fly.io，带 sqlite-vec / graphql 等插件。

关键引述（《What to blog about》）：

"the most liberating form of content I know of"（TIL 是我所知最解放人的内容形式）

"Call it a TIL—that way you're not promising anyone a revelation or an in-depth tutorial." / "I just figured this out: here are my notes, you may find them useful too."

"most of them took less than 10 minutes to write"（自 2020 年 4 月起 346 条时的统计）

"writing about something is the cost I have to pay for building it."（把"写出来"定义为造东西的固定成本）

个人品牌机制：三类内容 = 学到的（TIL）/ 造出来的（项目，"Add 'write about it' to your definition of done"）/ 找到的（link blog，2024-12 新增）。TIL 流是持续的专业性证据流——不承诺深度，只承诺真实的学习记录。

案例二：Josh W. Comeau —— 博客即软件产品（重工程派）

身份：React 教育者，博客是付费课程 The Joy of React 的获客与信任基础设施。

笔记形态：MDX 文件（"essentially a combination of Markdown and JSX"），VS Code 直接编辑、当作代码提交，元数据写在 frontmatter。

工作流拆解（据全文）：

1. 写作：MDX，可在文中内嵌交互式 React 组件（互动演示、代码 playground：Sandpack / 自研 <Demo> 组件）；
2. 渲染：Next.js App Router + next-mdx-remote；代码高亮用 Shiki（编译期执行，"adds 0kb to the JavaScript bundle"），并自研行级标注逻辑；
3. 发布：整个站点 100,000+ 行代码，"I have to re-deploy the whole app to fix a typo"——改个错字也要全站重新部署；
4. 分发：Vercel 部署 + MongoDB 存 like 数据 + Algolia 站内搜索 + Buttondown 式邮件订阅（博客本身带搜索与互动层）。

关键引述：

"In terms of workflow, I edit my MDX files directly in VS Code and commit them as code."

早年全 React 方案的教训："The writing experience was awful. Having to wrap each paragraph in a <p>… gets old really fast." 且 "There was no way to access the content as data."——这解释了为什么他坚持 Markdown 系而非纯组件化。

代价的诚实披露（全文精读最有价值的部分）：App Router 迁移后 Lighthouse 分数持平（88 → 88），"the performance of my new blog is slightly worse than my old blog"；dev server 启动从 7-12 秒涨到 "30-60+ seconds"；单页 CSS 加载 245kb 只用 47kb；结论是 "The App Router may have been marked as 'stable', but honestly it still feels pretty nascent to me."

个人品牌机制：博客的极高质量本身就是产品演示——课程期末项目就是"搭一个 MDX 博客"（"the final project has you build an interactive MDX-based blog… you can use it as the foundation for your actual blog!"）。写《How I Built My Blog》既内容又获客。

案例三：Manuel Moreale —— 无草稿、无自动化（极简手工派）

身份：独立设计师/开发者，People and Blogs 系列主理人（每周访谈一位博主，已 50+ 期）。

工作流拆解（据全文，两类内容两条流水线）：

Moment（图文短帖）：iPhone 拍照 → Snapseed 微调 → 登录站点后台 → 标题固定以 "A moment…" 开头 → 直接写完保存。原文："There's no proofreading involved, no drafts, no nothing."

Regular post（正文）：

"1. I open iA Writer 2. I write my post 3. When I feel I'm done I copy-paste into Grammarly to check for typos or other silly issues 4. I open my site's dashboard 5. I create a new post 6. I copy-paste from Grammarly and I hit publish 7. I then log into Buttondown.email… because there are some 100 or so people who want to get my posts via email"

想法捕获："I have a to-do list with a bunch of random ideas that usually appear in my head out of nowhere when I'm outside for a walk."（散步时的想法进待办清单，一条线或"标题+一句描述"）

对自动化的态度（本主题最锋利的一句话）：

"Could I add an auto-publish feature on my site? Sure. Would that save me time? Maybe 20 seconds a week. Is it worth it? Absolutely not."

P&B 访谈的流程（多博主编排管线）：Airtable 嘉宾池 → 冷邮件邀约 → 发问题 → 收答案后排 markdown + 前后语存草稿 → 上线周发草稿链接给嘉宾终审 → Buttondown 定时周五发布 → 手机 5 分钟提醒 → 手动点发布。

50 期访谈的横截面数据（《Fifty shades》）：共 91,141 词、均值 1,822 词（最短 Derek Sivers 487 词，最长 Matthew Graybosch 5,666 词）；词频第一是 "I"，非停用词第一 "quite fittingly, blog"；"the overwhelming majority of guests spend a similar amount of money to run their blogs"——几乎所有人都落在每年 $50-150 区间。

个人品牌机制：他自己不经营"个人品牌"（存档可见 2017 年标题《Personal brand is a stupid concept》，正文未读），但 P&B 系列本身把他变成独立 web 社区的中心节点——品牌是做系列的副产品。

2. 横向对比：同一问题的三种答案

三者共同点（本研究核心发现）：写作入口都嵌在已有习惯的工具里（git / VS Code / iA Writer），没人用"专门的写作软件"作为瓶颈环节；且都把单篇的心理承诺压到最低——TIL 不承诺教程、Manu 不承诺修改、Josh 把复杂度藏在组件后面。

3. 七维提取

核心问题

个人技术博主如何设计"从笔记到博客"的发布工作流，让写作长期可持续（低摩擦），并同时成为个人品牌/职业声誉的资产？自动化程度应该多高？

主要主张

1. 发布摩擦是持续写作的决定性变量：三人不约而同压缩"想法→上线"的步骤数——Simon 压到一次 git push，Manu 压到复制粘贴两次，Josh 至少保证"写作体验"本身不被工具拖累（拒绝纯 React 写作）。
2. 笔记与博客的边界可以消除：TIL 模式证明"笔记"本身就能公开出版——"here are my notes, you may find them useful too"。
3. 工作流本身是内容与品牌：Josh 写《How I Built My Blog》直接服务课程转化；Manu 用 P&B 访谈把"别人家的流程"做成自己的品牌资产；Simon 的 TIL 流是专业声誉的滚动证明。
4. 自动化程度应匹配发布量与商业模式，而非越高越好：Manu 的"20 秒测试"（省 20 秒/周的自动化绝对不值）与 Josh 的 10 万行代码是同一原则的两端。

方法

主题式检索（4 组检索词）→ 选 3 位真实博主的一手自述共 5 个来源 → webReader 全文精读 / WebFetch 结构化提取 → 提取原文引述与自述数据 → 按"捕获/加工/发布/分发/维持机制"五环节横向对比 → 七维综合。方法论上属于多案例研究（n=3 + 50 期访谈的聚合数据作旁证）。

数据与证据

• Simon：583 条 TIL、80+ 主题目录、2,195 commits（GitHub README 实测）；build.yml 逐行（push 触发 → build_database.py → grep 质检 → update_readme.py 自动提交 → S3 + Fly 部署）；"most of them took less than 10 minutes to write"；2020-04 起 346 条（发文时）。
• Josh：100,000+ 行代码；Lighthouse 88→88；dev server 7-12s→30-60+s；单页 CSS 245kb/实际用 47kb；Shiki 0kb bundle。
• Manu：完整 7 步发布流程原文；~100 邮件订阅者；P&B 50 期 91,141 词、均值 1,822 词、$50-150/年成本收敛（74 人 Ko-Fi 支持）。
• 证据充分性：工作流环节三人自述完整（一手），但均为自报数据，无第三方核验；Josh 的性能数字是单机 Lighthouse 自测。

结论

不存在标准化的"最佳发布工作流"；存在一个从纯手工到全自动的谱系，位置由发布频率、内容形态（静态笔记 vs 交互教程）和商业模式决定。可复用的最大公约数是：①把写作入口嵌进日常工具；②消除草稿/修改的心理税；③让"笔记够格发布"的门槛显式降低（TIL 化）；④工作流可被观察本身就是品牌内容。个人品牌在三个案例里都不是"运营"出来的，而是持续发布×真实流程暴露的副产品。

局限

1. 三位均为英语独立博客圈男性开发者，无中文博主对照，结论外推到中文技术写作生态需谨慎；
2. Josh 文章基于 2024-09 的技术栈（页脚称 2026-05 有更新，但正文未覆盖之后变化）；Next.js/AI 相关判断时效性短；
3. Simon 的《What to blog about》与 Manu 的《Fifty shades》经 WebFetch 摘要提取，非逐行全文；《Personal brand is a stupid concept》正文 404 未读，仅存档标题可见；
4. 检索曾出现一处错误信息（Cloud Run），靠实测 build.yml 修正——说明二手摘要不可直接引用；
5. 未见三人流量/收入/转化率的系统披露，"品牌收益"只能从行为推断，不能量化。

对我的启发

1. TIL 形式可直接移植到夜跑知识库：七维精读之外，把"小而确定"的发现拆成 <10 分钟一条的 TIL 式短条目（本目录未来可设 til/ 前缀），用"不承诺教程"换取发布频率——这正是当前笔记目录缺的轻量层。
2. Manu 的"20 秒测试"应作为本工作流的自动化守门标准：nightshift 的自动化（矩阵、日志）省的是分钟级，值得；为省 20 秒而加的脚本不值得维护。
3. 工作流本身即素材：我的"笔记→matrix.csv→backlog→nightly-log"管线就是一篇现成的 how-I-publish 博文——三个案例都证明"暴露真实流程"比"包装完美人设"更有品牌效力。
4. 想法捕获前移：Manu 把灵感捕获放在"散步时的一条待办"，与发布环节完全解耦；对应到我，是先往 backlog 丢一行再谈精读，不让"要不要写成完整笔记"阻塞捕获。

4. 来源清单（原文链接）

1. Josh W. Comeau, *How I Built My Blog: 2024 App Router Edition* — https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2
2. Manuel Moreale, *My blogging workflow* — https://manuelmoreale.com/thoughts/my-blogging-workflow
3. Manuel Moreale, *Fifty shades of people and their blogs* — https://manuelmoreale.com/thoughts/fifty-shades-of-people-and-their-blogs
4. Simon Willison, *What to blog about* — https://simonwillison.net/2022/Nov/6/what-to-blog-about/
5. simonw/til 仓库与发布 workflow — https://github.com/simonw/til ｜ https://raw.githubusercontent.com/simonw/til/main/.github/workflows/build.yml

（检索辅助：til.simonwillison.net、manuelmoreale.com People and Blogs 系列页）