有一类需求特别讨厌：

手动做，蠢。找产品，没有。自己写，不值得。

比如你有 30 份体检报告 PDF，要把里面的姓名全部遮蔽后发给别人。

  • 用 Adobe Acrobat 一个个点？可以，但你会想死。
  • 找个在线工具？要么收费，要么上传隐私文件不放心。
  • 自己写 Python 脚本？你知道 PyPDF2 能搞定，但查文档 + 踩坑要一两个小时。

这种需求卡在一个尴尬的真空地带——不值得上产品，不值得手动做，也不值得从零学一个库。

我最近给解决这类问题的方式起了个名字，叫胶囊编程。

什么是胶囊编程

胶囊编程（Capsule Programming）：

当市面上没有合适工具、手工又很傻、但用代码可以搞定时，你不去苦学某个库、从零堆代码，而是：

把文件丢进一个文件夹，用 AI 在这个目录里「对话式写脚本」，只为解决一个很小、很具体的自动化问题。

它更像是一颗颗「胶囊」：

  • 小而封装，针对单一症状
  • 一颗解决一个小痛点
  • 吞下去就见效

你的工作单元不是「项目」，而是「一个文件夹 + 一段对话 + 一个小脚本」。

什么时候适合胶囊编程

同时满足以下几条，就适合用胶囊解决：

1）市面上没现成产品

要么没有，要么有但太重、太复杂，不值得为这一点小需求上大系统。

2）手动操作可以做，但极其低效

比如几十个 PDF 要重复点来点去，Excel 里要反复改格式、改命名。这些都不是「做不了」，只是「做起来很蠢」。

3）用代码可以一次性解决，但学习成本偏高

你知道 Python 能搞定，但你对某个库又不熟，自己查文档 + 踩坑要 1 ～ 2 小时起步。

4）需求足够清晰、边界明确

输入是什么文件？输出要变成什么样？有几条规则？这些你能说清楚。

这类问题，用「产品形态」去解决太重，用「人肉」去解决太蠢，刚好适合一颗胶囊。

胶囊编程不是什么

划清边界：

  • 不是学一门新语言——你不需要「会」Python，你只需要能描述需求
  • 不是维护一个项目——没有 git、没有 CI、没有版本管理
  • 不是造轮子——你不追求通用性，只解决眼前这一个问题
  • 不追求复用和扩展——用完即走，下次再造一颗新的也无妨

胶囊编程的核心心态是：最小启动，够用就行。

胶囊编程的标准流程

我现在基本都这么干：

第一步：建一个文件夹

新建一个目录，比如 health_reports_redact/，把要处理的原始文件全部丢进去。

第二步：打开 Claude Code

在这个目录里开一个工作区，让 AI 能看到文件结构。

第三步：先聊方案，再写代码

描述需求：

“这里有一堆体检报告 PDF，帮我设计一个方案：批量把包含我姓名的地方全部遮蔽，新文件加 -已脱敏 后缀，原文件不动。”

让 AI 先输出算法思路和步骤。你只做一件事：确认边界（出错怎么处理？文件名规则？是否要日志？）。

第四步：方案确认后，让 AI 写完整脚本

“按这个方案，帮我写一个 redact_pdf.py。”

运气好一次跑通；就算不行，也是小修小补，而不是你从 0 写。

第五步：脚本留在文件夹里，成为一个胶囊工具

以后再有新的报告，只需要：

1
2
python redact_pdf.py

这个文件夹就变成了一个可反复复用的小型自动化装置。这颗脚本，就像一颗放在文件夹里的胶囊，随时吞一颗、立刻见效。

为什么现在才成立

这个模式不是今天才存在，但今天才真正可行。

以前，这类需求的「解决成本」远大于「收益」。你要查文档、踩坑、调试，花两小时写一个脚本，省下的可能只是半小时的手动操作。ROI 算不过来。

现在不一样了。Claude Code、Cursor、GPT 把「写脚本」的门槛打到了接近零。

  • 你不需要记 API
  • 你不需要调依赖
  • 你只需要用人话描述需求

当「写脚本」的成本从 2 小时变成 5 分钟，原本不值得自动化的事情，突然都值得了。

AI 是这个模式成立的关键变量。

结语

胶囊编程不是什么高深的方法论，只是一种姿势的转变：

  • 从「我要学会这个库」变成「我只需要描述清楚问题」
  • 从「我要写一个项目」变成「我只需要一个文件夹」
  • 从「这个需求太小不值得」变成「正因为小，才适合吞一颗胶囊」

久而久之，你的电脑里会长满胶囊。

每个文件夹都是一个微型自动化装置，随时待命。

当你再遇到那种「手动很蠢、产品没有、代码能解决」的需求时，不用犹豫——

建个文件夹，开个对话，吞颗胶囊。