2022 年 4 月 22 日，我在 GitHub 上建了一个仓库。
那天它只有一个 README、一份 setup.py，和一堆我自己在用的脚本。
四年后——
- GitHub 1366 个 star，305 个 fork，29 位贡献者
- PyPI 累计下载 40 万次，最近一年每天还有 300-700 次
- 73 个技能，覆盖 PDF、Word、Excel、PPT、邮件、微信、图片、视频、OCR
- 上周还在提交代码
项目地址：
这四年有人问我：这项目收益怎么样？一个人维护累不累？值不值得？
今天不聊收益，聊点别的——我想把它当成一个"四年长跑的实验"来复盘。
一、它最开始不是给谁做的
现在回头看 README 上那句"the most popular Python office-automation library in the Chinese-speaking world"，说实话有点心虚。
它一开始根本不是为了"给谁做"而写的。
2019 年我在汽车行业一家上市公司做程序员，团队用 Java 和 C，我一个学 Python 的在里面特别憋屈。
憋屈归憋屈，但我当时干了一件挺大胆的事——我想让整个部门都转用 Python。
写脚本、帮他们改工具、写文档、做内部小系统，能想到的办法都试了。
那两年我下班后每天 6 个小时（18:00-24:00），一半时间写文章，一半时间看教程。
python-office 就是从那个时候长出来的。
一开始它甚至不叫这个名字，也没有文档，没有版本管理，只是一堆躺在某个文件夹里的 .py 文件。
后来我做自动化办公内容，学员天天问我同一个问题："老师，这些 Excel 到底怎么才能一键搞定？"
我回答了上百遍。
第 100 遍的时候，我意识到：不该再回答第 101 遍，应该把它写成一个库。
于是 2020 年我开始动手，2022 年 4 月正式发布。
二、我做对的三个决定
决定一：先做"自己天天用"的功能
这个库最早的一批功能，全是我上班时真的要用、但嫌麻烦的东西：
Excel 合并、PDF 转 Word、PDF 加水印、图片转格式、批量重命名……
没有一个功能是"我觉得大家可能会需要"。
这个选择后来救了我。2020 年我做过一次"瞎讲"式的内容尝试——讲"1 亿怎么花"、讲形而上学话题、追各种热点——现在想想那些全是无用功。一个内容账号想靠追热点活下来，方向错了就是错了。
但 python-office 不一样，因为它有根：它一开始就是我自己每天要干的活。
决定二：先做"一行代码"，而不是"功能强大"
这是 python-office 最重要的产品决策。
很多 Python 办公库的做法是给你一堆参数、让你自己研究怎么组合。我的做法是：90% 的场景，一行代码直接出结果。
1 | from skills.pdf import pdf2docx |
不用学类、不用理解继承、不用看一屏参数表。
我后来才明白，这个决策才是"普通人能不能用起来"的分水岭。 库的技术含量不重要，能不能被一个完全不懂 Python 的人用起来，才重要。
决定三：把子库拆开
这是 2025 年才做对的事。
主包 python-office 装下来体积不小，因为里面塞了 PDF 图像处理、Excel 读取、视频抽帧、OCR 依赖……有人就在评论区问："我就转个 PDF，装这么多东西干嘛？"
于是我把功能拆成了独立可安装的子库：
popdf、poexcel、poword、poimage、poocr、poppt、povideo、poemail……
想装哪个装哪个。
1 | pip install popdf # 只装 PDF 相关 |
轻装这件事，用户是会用脚投票的。
三、我也做错了很多事
复盘如果只讲对的部分，那和自我宣传没区别。
错误一：文档一直在拖
从 2022 年发布到现在，文档欠债一直在累积。
我太熟悉这些代码了，所以总觉得"用户应该能看懂"——这是我作为作者最大的傲慢。
新用户不知道该 import 哪个模块，不知道参数叫什么，不知道该看哪个文档。他打开 README 看到那 70 多个功能，第一反应是关掉。
到现在，文档和单元测试覆盖率 STILL 是我最欠的两笔债。
错误二：issue 积压到 33 个
33 个 open issue 躺在那里。
有些是环境问题（Windows 上装某个依赖报错），有些是文档没写清楚，有些是真 bug。
我有一部分回复了，一部分没回。
我知道这不叫"开源精神"，这叫"我先顾我的"。但诚实地说：当一个项目的用户量超过一个人的时间，你必然要选：先做新功能，还是先还债。
我选的是先做新功能。这不对，但我没打算装作它对。
错误三：一个人扛了太久
29 位贡献者，这是个不错的数字。但看贡献分布会发现：主力还是我一个人。
我一直觉得"我再多写一点就行了"，结果就是——单元测试写不动、文档写不动、新功能一加就欠更多债。
这是一个典型的"技术人的自作聪明"陷阱：觉得只有自己能写好，结果把自己写死了。
我现在在公开招募开源伙伴，统一的参数命名、统一的代码风格、每个功能独立目录，欢迎来提 PR。
错误四：太早追求"全"
刚有起色的时候，我很想做一个"什么都能干"的大库。
结果是每个功能都浅。
现在回头看，"先做深一个场景，再横向铺开"才是对的顺序——但我花了两年才想明白。
四、2025 年之后：AI 改变了这个库
2025 年之后，我给每个技能都加了两样东西：SKILL.md 和 YAML 描述。
这不是为了赶时髦。
是因为我发现——现在有越来越多的朋友，是让 AI 帮他们写代码，而不是自己写。
当 AI 接手的时候，它需要知道：
- 这个库能干什么
- 有哪些功能、分别在哪个模块
- 每个功能的调用方式和参数
- 什么场景该用哪个
以前这些信息散在文档和视频里，人得自己去找。现在，我把它们整理成机器能读的形式，直接喂给 AI。
1 |
|
你只需要对 AI 说一句："把这个 PDF 转成 Word"，它自己就能找到 pdf2docx，自己填参数，自己调通。
这是 python-office 这两年最重要的变化。 库的门槛从"你要会写 Python"，降到了"你会说人话"。
这也算是给那些"我不懂编程"的人，准备的一份礼物——虽然我做了四年才想明白这件事。
五、写在最后
四年，1366 个 star，40 万次下载。
这个数字对我来说意味着什么？
意味着有 40 万次，某个人在自己的工作里卡住了，敲了一行 pip install python-office，然后事情办成了。
他们大概率不知道我是谁，也不关心 star 数。
这就对了。
我 2019 年在汽车厂写那些没人看见的脚本时，没人知道那是 python-office 的第 0 行代码。我也没想过它会变成什么。
所以现在有人问我"这项目收益怎么样"，我的回答是：
它给我带来的最大东西，是"我在写一个真的有人用的东西"这件事本身。
而这也是我职业生涯里，最不后悔的一个决定。
有想给 python-office 提 PR 的朋友，仓库在这儿：
想用但不知道用哪个功能的，看这里：
想找人一起维护、加微信备注"开源"：
你用 python-office 做过最有意思的一件事是什么？评论区聊聊。
相关阅读
微信进群
