软件正在变成对话的副产品

今天下午，我被一件小事折磨得脑子疼：

把博客文章发到 X.com 的文章编辑器里。

听起来很简单对吧？复制粘贴不就完了？

问题是：

粘贴过去，格式全丢
标题没了、列表没了、代码块更是一坨乱码
X.com 编辑器支持富文本，但你得用它的工具栏一个个点
一篇长文章，光调格式就能调半小时

我当时的状态是：

这破玩意儿怎么这么难用？一定有人做过类似的工具吧？

然后我搜了一下，还真有。

GitHub 上有个项目叫 x-article-publisher-skill，专门干这事：解析 Markdown、转成 HTML、用富文本方式复制到剪贴板、粘贴时格式全保留。

但我没有把它 clone 下来。

我直接跟 Claude 说：

“帮我写一个 skill，把 Markdown 文章发到 X.com 编辑器，保留格式。”

然后就开始了一段”现场造轮子”的对话。

过程比结果更有意思

一开始，Claude 给我输出的是纯文本。

粘贴过去，格式全丢。

我说不对，X.com 编辑器支持富文本。

Claude 说好，那我把 Markdown 转成 HTML，用 pbcopy 复制。

还是不对。pbcopy 只能复制纯文本，富文本需要用 NSPasteboard 设置 HTML 格式。

Claude 说好，那我用 pyobjc-framework-Cocoa。

但系统 Python 不让装包。

Claude 说好，那我建个虚拟环境。

虚拟环境建好了，复制成功了。

粘贴过去，格式有了，但代码块没了。

我说 X.com 不支持代码块。

Claude 说好，那我把代码块转成引用块。

粘贴过去，引用块有了，但表格没了。

我说 X.com 也不支持表格。

Claude 说好，那我把表格转成列表。

终于，能用了。

整个过程大概 40 分钟。

这件事让我意识到一个变化

以前，软件是”产品”。

你有需求 → 找工具 → 下载安装 → 学习使用 → 解决问题。

中间有大量的”寻找成本”和”学习成本”。

现在，软件正在变成”对话的副产品”。

你有需求 → 描述问题 → AI 现场生成 → 不对就改 → 用完即走。

今天这个 post-to-x skill，我没有去 GitHub 上 clone 那个现成的项目。

不是因为它不好，是因为”描述需求然后让 AI 写”这条路径，比”找到项目、理解结构、配置环境、跑起来”更短。

而且，AI 写出来的东西，是完全贴合我的项目结构的。它知道我的 _posts 目录在哪，它知道我的文章格式是什么，它知道我用的是 macOS。

这不是”通用工具”，这是”现场定制”。

软件工程可能正在消失

这句话有点吓人，但我越来越觉得它是真的。

传统软件工程的核心假设是：

软件是昂贵的，所以要复用。

于是我们有了：

需求分析（确保做对）
架构设计（确保能扩展）
代码规范（确保能维护）
测试体系（确保不出错）
文档体系（确保能交接）

这一切的前提是：代码写一次，要用很久。

但如果代码变得廉价呢？

如果”写一个工具”的成本，低于”找到并学习一个现成工具”的成本呢？

那很多软件工程的实践，就失去了存在的理由。

你不需要”复用”，因为现场生成更快。

你不需要”文档”，因为代码就是对话的产物，上下文就在对话里。

你不需要”交接”，因为下一个人可以直接问 AI “这段代码在干什么”。

但有些东西不会消失

今天这 40 分钟里，Claude 写了好几版代码，改了好几次方向。

每一次”不对”，都是我说的。

我知道纯文本粘贴不会保留格式
我知道 pbcopy 只能复制纯文本
我知道 X.com 不支持代码块和表格
我知道要用 NSPasteboard 设置 HTML 格式

Claude 不知道这些吗？

它知道。但它不会主动告诉我”你这个思路走不通”。

它只会顺着我的指令往下写，直到我发现不对。

所以真正值钱的，不是”能写代码”，而是”能判断对不对”。

AI 让”写出来”变得廉价。

但”知道该写什么”、”知道哪里会出问题”、”知道什么时候该停下来换个方向”——这些判断，还是人的事。

结尾

今天这个 skill，我不会把它发到 GitHub 上。

因为它太贴合我的项目了，别人用不了。

但这恰恰是它的价值：

它不是”通用工具”，它是”我和 AI 的一次对话的产物”。

用完即走，下次再聊。

软件正在变成液态的、流动的、一次性的。

这听起来有点浪费，但也许这才是软件本来该有的样子：

解决问题，然后消失。