一天、392行代码：他把十年的复制粘贴自动化了

一个Emacs老用户，复制GitHub Issue复制了很多年。每次都是手动把标题和描述搬进Org文件，重复到他自己都数不清多少次。

上周，他用392行Elisp、花一天时间写了个叫fj的小工具，把这件事自动化了。数字听着单薄，但背后是个更大的问题：同样一件事，普通软件公司要立项、排期、测试、发版，一个人在Emacs里一天就干完了。差距从哪来，能不能复制到别处，是这篇真正该问的问题。

一天里，他做了什么

fj只做四件事：浏览某个仓库的Issues、把一条Issue复制成Org任务、用Org语法直接创建新Issue、在浏览器里打开某条Issue。

认证和API请求全部丢给gh命令行处理——不是不需要认证，是作者刻意把这层麻烦交出去，自己只管调用gh、解析返回的JSON。界面用Transient做菜单、vtable做列表；Org转Markdown靠ox-gfm，Markdown转回Org靠Pandoc。

时间线很干脆：基础功能（拉取、显示）花了2.5小时，覆盖全部需求花了一天，cloc量出来的代码量是392行。这些数字来自作者自述，没有独立复现，只能当作者本人的实测参考。

可塑软件换来的，是定义权

Steven Sinofsky讲过一件事：微软调研发现，Office里几乎每个功能都有人用，但没有一个用户用得到全部功能。这是"供给型软件"的宿命——产品定义权攥在厂商手里，厂商想服务所有人，功能集就必须庞大，九成用户用不上的部分，厂商还得照样维护。

Emacs走的是另一条路。它不给你一个完整产品，只给积木：Elisp、Transient、vtable、gh、Pandoc，谁想要什么形状，自己拼。fj是一个用户自己拼出来的答案，前提是他自己既是产品经理，也是全部用户——产品定义权，从生产者手里转到了使用者手里。

这对谁有意义？长期在Emacs、Org里工作的人，尤其是那种"每天都要跟某个外部系统打交道，但官方客户端总差一口气"的场景——不只是GitHub，Jira、日历、笔记同步都算。这类用户看完fj，大概率会想：我自己那个重复了很多年的手动步骤，是不是也能一天解决。

Build for 1 与 Build for N：谁该试，谁该等

fj一天能写完，前提是它只服务一个人。这条件一旦变，成本结构就完全不同。

把"一天写出能用的工具"外推成"通用GitHub客户端也该这么便宜"，是这类故事最容易踩的坑。fj好用，恰恰因为它从没打算好用给别人。

这也跟"动态语言比静态语言更高效"没关系。fj的优势来自Emacs运行时可扩展、组件现成、边写边跑，不是Elisp这门语言天生占优。

真正该学的不是fj这个工具，是它划出的那条线：build for 1几乎零成本，build for N要加测试、文档、兼容性、长期维护、分发渠道——这是数量级差异，不是量的差异。适合复制这条路的，是那些"只服务自己"的重复性痛点；不适合的，是任何打算给团队、给陌生用户用的东西。

原文没提到fj是否会开源、是否会补上错误处理和权限校验，这部分目前还看不清。如果作者真把它推向"给更多人用"，才是检验这套判断的下一个节点。