记、写、发：我的内容流水线（附 mdcli）
“你不会升到自己目标的高度，只会掉到自己系统的层级。” — James Clear《原子习惯》
不管是产品对外，还是给自己留档，写下来一般是不亏的。没人看时，至少是底稿；有人看了，同一篇还能改。我把「记什么、怎么写、发哪里」整理成一套自己能维护的流程。今天写一版，免得两个月后忘了当时为什么这么定。
选题：三个固定入口
我不靠「等灵感」。灵感像间歇性信号，靠不住。干脆每天留三个入口，不知道写什么时，至少知道从哪里翻：
早上：扫一眼新闻，再看 X、Reddit、GitHub 上有什么新东西。不必追热点，只看有没有和手头工作能对上的线。
晚上：新闻联播后写一小段「璞奇拓展」。把当天补上的盲点、值得留一句的信息，挑几条记下来。重点是补盲区，不是写评论。
白天项目：方案、选型、踩坑、运维——和创业直接相关的，当天记。这类材料最怕「以后再写」。一过夜，细节就没了，只剩一句「当时很麻烦」，等于没记。
三条线不必天天齐。项目线尽量不断；另外两条，有则写，无则跳过。
「全自动」：不是成本高不高，而是走不通
「从选题到多平台、零人工」听起来省事。真往下做会撞墙：所谓全自动，既没有谁给你一套开箱即跑、包打天下的方案；各平台也不会配合你把人踢出环路——审核、版权、首图、话题、版式，规则写在后台里，本质是人要为结果负责。平台拒绝的，往往不是技术实现不了，而是不允许你把责任也自动化掉。
再往「零介入」上硬推，多半是在跟注意力、容错和真实节奏较劲，违背常情，去追求一个不符合实际的极限。不如把目标说小：人定方向，AI 和脚本吃掉确定性的重复；该点的发布、该改的一句，留给人。
做法前两步照旧：
- 选题清楚后，用 AI 出 Markdown 初稿，口吻往自己靠；链接、图，人过一遍。
- 博客走 GitHub Pages，线上 blog.zendong.com.cn 用手机扫一眼，别扭再改。发布前自己读一遍，仍是最省事的检查。
第三步——多平台草稿——下面单独说：最近把工具开源了，用起来更理直气壮一点。
markdown-cli：新开源的多平台草稿同步器
markdown-cli 是我在 zendong 组织下新开源的命令行工具，解决一件很具体的事：本地已经有一篇 Markdown，还要反复打开各平台后台、复制粘贴时，人很容易烦，步骤也容易抄错。
它做的事可以概括成三句话：
- 用 Chrome DevTools Protocol (CDP) 连上你本机正在跑的浏览器；
- 在 Doocs/MD 里完成渲染（和你在页面上看到的版式一致）；
- 借助 Chrome 扩展 COSE，把当前内容推进各平台编辑器的草稿——具体支持哪些平台，以扩展与仓库说明为准。
也就是说：CLI 负责「写进去、触发同步」；标题要不要改、图要不要换、最后点不点发布，仍得人决策。这和嘴上说的「全自动发稿」不是一类东西——后者在平台和人性这两头，本来也立不住。
安装时进入 markdown-cli 目录执行 make global（或按 README 用 pnpm build 再全局 link），本机就有 mdcli 命令。Chrome 需按 README 用远程调试端口启动，编辑器页和 COSE 扩展先就位——第一次略折腾，跑通以后省的是每次复制粘贴。
同步时，在 CLI 里指定目标平台，让浏览器里已打开的 Doocs/MD 与扩展配合完成一轮写入；大致是「本地 md → 进编辑器 → 触发 COSE 同步」这一条链。
例如要落到微信公众号后台，可以在浏览器里看到草稿区已有内容，再按平台规则补图、改格式、点发布——工具减少的是重复劳动，不替你承担「能不能发」的判断。
更细的参数、平台列表与故障排查，直接看仓库 README，这里不重复说明书。
多平台：别指望一条 md 通用
mdcli 只做「把内容送进编辑器」这一跳。各平台对图、排版、话题的规则不同，一条 Markdown 原封不动发全渠道，不现实。
我的分法：
- 博客版当母稿：结构清楚，链接可用，图有稳定托管。
- 每个平台再改一版：删什么、图放哪、标签怎么写，用 AI 写在 skill 里。脚本可以批量跑，规则仍要人更新。
图分两类：公众号可走素材库上传，再替换文内链接；其他我倾向阿里云 OSS 做统一外链。OSS 要配 Referer，否则有的平台会拦图。那是运维问题，不是 Markdown 能单独解决的。
所以「一个脚本跑多平台」的前提，是同一套校验过的输入在循环，不是同一串字符不加区别地群发。有点像同一套源码打不同目标架构：入口一样，补丁不一样。
璞奇启示
璞奇做的事一句话：用 AI 把用户感兴趣的内容变成能练、能跟进的题，让学习轻一点。上面「记—写—发」几条，和做学习产品有重合处。
第一，入口要轻。
三个时间入口，目的是降低「开始写」的阻力。璞奇也一样：第一次别像考试，像试玩，人才愿意继续。
第二，人机边界要清楚。
AI 出初稿，人核对事实；CLI 进草稿，人决定发不发。做题同理：机器可以出题、改表述，目标要人说清楚，否则容易好看不好用。
第三，别指望「全自动」替用户扛责。
多平台规则会变；不切实际的零人工幻想，和学习里「一键通关」一样，容易好看不好用。产品里接能力边界，也要留人能在环里改规则的余地，而不是追求反人性的极限。
小结
写下来是留底，发出去是对齐。流程以后还会改，核心两句：开写时知道从哪进，发之前有人把关。 下一篇也许来自今天项目里的一个坑——那种材料，别人最难抄。