程序员花3小时写脚本，把VS Code变成了个人发布系统

一个刚学Go语言的开发者，用3小时写了个脚本，把VS Code终端变成了内容发布后台。没有CMS，没有仪表盘，一条命令直接推送。

这事听起来像极客玩具？但背后藏着一类产品的典型困境：工具越"完整"，启动成本越高；越"简陋"，反而跑得越快。

从"学语言"到"造工具"的72小时

作者的原话很直白：「This is a test post published directly from my VS Code terminal」。测试帖，但测试的是一整套工作流。

Go语言以编译快、部署轻著称。新手常陷入的陷阱是：先学语法，再学框架，再学最佳实践——三个月过去，什么都没做出来。这位开发者反着来：语法还没学完，先问自己"我现在最想解决什么问题"。

答案是：写好的内容，不想手动复制粘贴到各个平台。

于是脚本的核心逻辑极简：本地Markdown → API调用 → 发布完成。没有数据库，没有用户系统，没有审核流程。硬编码的配置，命令行里的成功提示，就是全部交互。

这种"半成品"状态，恰恰是个人项目最健康的阶段。功能刚好够自己用，代码丑但能动，改需求不用开周会。

为什么大厂不做这个？

字节有飞书内容库，腾讯有企鹅号后台，网易号也有完整的编辑器。但它们的共同特点是：为"所有人"设计，意味着要为"最不可能的用户"预留功能。

权限系统、版本回滚、富文本解析、多平台适配、合规审核……每个功能都合理，叠加起来就是启动一座工厂的时间成本。

个人开发者的优势在于：知道自己不要什么。不要协作，所以不用权限；不要排版，所以直接传Markdown；不要数据看板，所以连数据库都省了。

作者提到的下一步更有意思：「build a personal analytics backend」。分析后台，但限定词是personal（个人的）。不是要做第二个Google Analytics，是要解决"我自己的数据，我想怎么看就怎么看"。

命令行里的产品哲学

这个脚本最反直觉的设计，是把发布入口放在VS Code终端里。不是浏览器插件，不是桌面应用，是程序员本来就开着的那块黑框。

产品经理看到这会皱眉：用户门槛太高，非程序员用不了。但开发者算的是另一笔账：目标用户就是我自己，而我整天开着VS Code。

这像极了Notion早期的选择。2016年的Notion没有手机App，没有API，甚至加载慢得要死。但它在"能忍受这些缺陷的人"里面，做到了笔记工具的极致。

工具的第一版，应该让目标用户觉得"终于有人懂我了"，而不是"所有人都能用"。

作者的项目还在早期，代码没有开源，功能也仅限于发布测试帖。但工作流已经跑通：写内容、本地保存、命令行推送、线上可见。四个步骤，没有等待，没有转格式，没有"您的内容正在审核中"。

个人基础设施的兴起

2023年以来，类似的项目在GitHub上明显变多。个人RSS聚合器、自托管书签服务、私有笔记同步方案……主题各不相同，动机高度一致：平台提供的工具越来越重，而"刚好够用"的替代品，自己动手写反而更快。

这不是对大厂产品的否定。飞书文档的协作、Figma的实时同步、Notion的数据库，这些复杂功能有其不可替代的场景。

但当需求收缩到"我一个人，想快速发布"，重型工具就像用挖掘机种花——能行，但每一次启动都要深呼吸。

作者的Go脚本只有几百行，错误处理大概很粗糙，边界情况肯定没覆盖全。但它解决了一个真问题，而且解决得够快。

「More coming soon」——这句话写在测试帖的结尾。没有产品路线图，没有版本规划，只有一个开发者对自己下一步工作的承诺。