帮程序员把代码和文档一键整成专利交底书的 Skill

前两天我在 GitHub 上闲逛，刷到一个仓库。

名字很直白，patent-disclosure-skill。

我愣了好几秒。

不是哥们，这玩意还能开源？

写专利交底书这件事，我印象里一直是那种很"老钱"的活。找个专利代理人坐下来聊半天，整理材料，来回改稿，最后出来一份你可能都看不懂但又不得不签的文件。

这玩意怎么能变成一个 GitHub skill？

我点进去仔细看了看，然后一发不可收拾。

事情是这样的。这个项目的作者叫 handsomestWei，做的事情其实一句话就能说清楚：帮程序员把自己写的代码和文档，一键整理成专利交底书。

但你仔细看它的设计思路，会发现这个人是真的懂程序员在写专利时有多痛苦。

很多朋友可能不知道，我先简单解释一下什么叫"专利交底书"。

其实就是要申请专利的时候，你得给专利代理人一堆材料。告诉他你这个发明是干啥的，技术方案是什么，跟现有技术比有啥区别，怎么实现的，能解决什么问题。整理成文档，就是交底书。

传统上，这活是发明人和专利代理人协作完成的。发明人提供技术内容，代理人负责包装成法律语言，符合专利法的要求。

听起来很合理对吧？

问题在于，这中间有一道巨大的信息鸿沟。

程序员的脑子里全是"这个函数调了那个 API""这个模块用了什么算法"，他不知道怎么把这些翻译成"本发明提供一种 XXX 系统，包括 XXX 模块..."这种法律行话。

而专利代理人呢，他可能完全不懂你写的代码是啥意思，只能靠你口述。

结果就是，交底书经常写得很拧巴。程序员觉得"我说的不是这个意思啊"，代理人觉得"你说的那堆技术名词我也听不懂啊"。

来回拉扯，改个七八稿是常态。

你想想看，一个程序员的核心竞争力是写代码，不是写专利文档。让他花一两周整理交底书，简直是暴殄天物。

我之前听一个在某大厂做技术 leader 的朋友讲，他想把自己团队的几个核心创新点申请成专利。前前后后折腾了三个月，花了好几万给代理所，最后出来的交底书他自己看都看不太懂。

这种事太常见了。

那么这个 patent-disclosure-skill 是怎么解决的呢？

我跟你说，它的思路特别工程化。

不是上来就"用 AI 写专利"这么简单粗暴，而是把整个写交底书的过程拆成了一个个具体的步骤，每个步骤对应一个 prompt 模板。

你按照这些步骤一步步跑下来，最后就能产出一份完整的交底书。

回到项目本身，我觉得最值得聊的，是它里面几个让我眼前一亮的设计。我按从基础到进阶的顺序说。

第一个，docx/pptx 先转 Markdown 再扫描。

你手里肯定有现成的技术文档对吧？Word 写的设计文档，PPT 做的方案汇报。

这些文件直接喂给 AI 效果其实很差，因为格式很乱，有用信息被各种样式、字体、颜色淹没了。

这个 skill 的做法是先把这些文档转成 Markdown，提取纯文本内容，再喂给 AI 去分析。

说起来简单，但这步其实非常影响最终产出的质量。

我一直觉得，做 AI 应用最容易被忽视的就是这种"数据预处理"的环节。大家都盯着模型本身怎么样怎么样，其实喂进去的东西干不干净，决定了输出的天花板。

第二个，mermaid 自动出图。

交底书里经常需要系统框图、流程图、时序图这些东西。传统做法是用 Visio 或者 draw.io 画，再贴到文档里。

程序员一听就头大。我代码都写不完，你还让我画图？

这个 skill 的做法是直接用 mermaid 语法描述，AI 帮你生成对应的图。

mermaid 这玩意，就是那种用文本写图表的工具。程序员天然喜欢这个，因为图表本身也是代码，可以放进 git 里管理。

你写一段 mermaid 语法进去，它就给你渲染成一张图。

这个设计真的特别懂程序员。

第三个，分步 prompts 模板。

这个项目里所有的 prompts 都是分步的、可读的、可迭代的。

什么意思呢？就是你不是一个 prompt 把所有事情干完，而是把整个写交底书的过程拆成好几个阶段。

比如"梳理技术方案"是一个 prompt，"提炼创新点"是一个 prompt，"撰写权利要求"又是另一个 prompt。

这样做的好处是，你可以在任何一个步骤停下来，看一下产出，修改一下，再继续往下走。

我自己的感受是，这比那种"一键生成完整专利"的黑盒强太多了。

你想啊，专利这玩意，每个公司、每个技术领域的要求都不一样。一个统一的 prompt 模板肯定不可能适配所有情况。

但分步可迭代的 prompts，你可以根据自己的实际情况调整。哪一步效果不好，就改哪一步的 prompt。

不追求大而全的自动化，而是把每个环节都做得可解释、可调整。

这其实是一种非常工程师思维的解法。

第四个，时间戳命名 + 对话记录实现版本追溯。

这个设计比较骚。

每次你跑这个 skill 的时候，它会自动给你生成一个带时间戳的目录，把所有的中间产物和对话记录都存下来。

这样你每次迭代交底书的时候，完整的修改历史都在。

我看到这个设计的时候，真的被震撼到了。

因为这解决了一个超级痛点：交底书改来改去，版本管理混乱。

这个事儿我也踩过坑。有一次帮人整理材料，改了十几稿，最后他自己都搞不清哪一稿是最新的。

结果他用了一个特别原始的方法，在文件名后面加 v1、v2、v3...

v1_final.docx v1_final_真的final.docx v1_final_真的final_这次不改了.docx

你敢信？？？

这个 skill 的做法完全解决了这个问题。每次跑都自动存档，版本之间的关系清清楚楚。

你甚至可以回滚到任何一个历史版本，看当时的对话记录。

这种体验太好了。

第五个，优先调用国知局官方站查新。

写专利之前，你得先确认你的发明是不是新的，有没有别人已经申请过类似的东西。这个步骤叫"查新"。

传统上，查新要么是自己去国知局的网站上搜，要么花钱让代理所做。

这个 skill 的做法是优先调用国知局的官方检索接口。你写完技术方案之后，它先帮你查一遍，看看有没有相似的现有技术。

这块需要注意一下。查新结果会直接影响你后面怎么写交底书，尤其是"有益效果"和"区别技术特征"那部分。如果查出来太像了，你可能得调整技术方案的角度。如果查出来是全新的，那你就可以大胆吹。

这玩意放在以前，是专利代理人的核心工作之一。

现在，AI 直接帮你跑一遍，而且用的是官方数据源，不是网上随便搜搜。

我当时就愣住了。

其实吧，这个项目还有一层意义，我觉得更值得聊聊。

你有没有发现，这个项目的作者，本身就是程序员？

他没有假装自己是专利代理人，也没有试图写一个"AI 写专利的通用工具"。

他的做法是，站在程序员的角度，思考"程序员写专利时最痛苦的是什么"，然后用工程化的方式去解决。

这种"从用户视角出发"的产品思路，其实正是当下 AI 应用最稀缺的东西。

很多所谓的"AI 写专利"工具，都是从专利代理人的角度出发的。它们想的是"怎么用 AI 替代专利代理人"。

但 patent-disclosure-skill 不是。它的出发点是"程序员自己怎么搞定这件事"。

这两种思路的差异，体现在产品的每一个细节里。

比如优先调用国知局官方站查新，而不是用某个商业专利数据库。这是因为程序员更相信官方数据源。

比如用 mermaid 出图而不是 Visio。这是因为程序员本来就用代码管理图表。

比如分步 prompts 而不是一键生成。这是因为程序员喜欢可控、可迭代的工具。

比如时间戳 + 对话记录的版本管理，而不是简单的文件命名。这是因为程序员本来就活在 git 的世界里。

你看，每一个选择都透着一种"我懂你"的味道。

这种"懂你"的感觉，在 AI 产品里其实很少见。

很多 AI 产品都是技术很强，但用起来就是不顺手。问题出在哪？出在设计产品的人没有真正站到用户的角度去思考。

但这个项目不是。

你用一下就能感觉到，这玩意是真真切切给程序员用的。

你想想看，这其实也反映了一个更大的趋势：AI 应用的下一个阶段，一定是"垂直化"和"人格化"的。

不是一个大模型搞定所有事，而是无数个像 patent-disclosure-skill 这样的小 skill，各自服务好一个具体的场景、具体的一群人。

这个生态，才刚刚开始。

我跟你说，我现在看到一个新 skill 发布，第一反应已经不是"这个 AI 能干啥"，而是"这个 skill 是给谁用的"。

如果它能精准地服务好一个具体的用户群，解决一个具体的痛点，那它就有价值。

如果它想做"通用 AI 助手"，那我基本就划走了。

这话听着有点刺耳，但不是说通用 AI 没用，而是在当下的阶段，垂直化和人格化才是真正的机会窗口。

说真的，我其实挺佩服这个作者的。

他做的事情，在法律上、技术上、商业上都有很多不确定性。

比如用 AI 写出来的交底书，能不能通过专利代理人的审核？比如这个 skill 产出的内容，符不符合专利法的要求？比如如果真的有人用这个 skill 申请专利并且成功了，会不会引发新的法律问题？

这些事，他可能自己也不完全确定。

但他就是先做了。先把东西做出来，让用户去用，让市场去检验。有问题再迭代。

这种"做出来再说"的工程师精神，我觉得是这个项目最打动我的地方。

可能有些想法还不成熟，但至少它在动。它在尝试用一种新的方式解决一个老的问题。

而且，它还开源了。

好了，说了这么多。

回到开头那个问题。

我在 GitHub 上刷到 patent-disclosure-skill 的时候，第一反应是"？？？写专利还能做成 skill？"

但看完之后，我的反应变成了另一个"？？？"

为什么这么晚才有人做这件事？

专利申请这个场景，天然适合 AI Agent 来做。

它有明确的工作流程（查新、撰写、修改），有大量的模板化内容（权利要求书、说明书、摘要），有清晰的输入和输出（技术文档→交底书）。

这种场景，简直就是为 AI Skill 量身定做的。

但偏偏，过去这么多年，市面上一直没有一个像样的开源工具。

直到这个项目出现。

我有时候觉得，AI 时代真正稀缺的，不是技术，而是"发现具体场景"的眼睛。

技术一直在进步，模型越来越强，框架越来越多。但真正能把技术用对地方的人，其实很少。

patent-disclosure-skill 的作者，就属于这种"眼睛很亮"的人。

他看到了一个具体的、真实的、还没被满足的需求，然后动手做了一个开源的解法。

这件事本身，比代码本身更值得讨论。

我始终坚信，AI 真正的价值，不是让少数人变得更强，而是让很多原本做不到的事情，变得人人可做。

专利申请这件事，就属于"原本做不到但其实应该做到"的那种。一个发明人，不应该因为不会写交底书，就放弃申请专利。这项权利，本来就是他的。

你也可以回想一下，你身边有哪些事情，是"听起来很专业所以没人敢碰，但其实 AI 可以帮上忙的"？

欢迎在评论区聊聊。