代码先开源，专利后想起
一句话版本
我做了一个自己挺满意的功能，代码在公开仓库上跑了三个多月。等想起「这好像能申请个专利」的时候，窗口已经关了。
事情是这样的
我在给学校做一个校园 IT 资产运维平台。其中一个模块，是把散在十几个异构系统里的资产数据——物理机、虚拟机、域名、数据库、Web 服务、监控——拉到一起做关联，画成一张能逐层展开的资源图谱，再让大模型照着规则去判断配置是否合规。
代码写完之后，我按老习惯做了：推到 GitHub，打 tag，发 release。每隔一阵子发一版，看着版本号从 v0.36 涨到 v1.10，挺有成就感。
后来有人说，这玩意儿有创新点，建议去申请专利。我心里一动，回头一查——晚了。
为什么晚了
专利里有一条最基本的规定：申请日之前，你的方案不能已经公开。 只要在申请日之前，公众能够得知你的技术内容，你就等于在自己面前竖起了一道叫「现有技术」的墙，新颖性直接归零。
而我的仓库是 public 的。从第一个 release 到今天，三个多月。我按下 push 的那一刻，就是专利的死亡时间。
有人会问：不是有六个月宽限期吗？
有，但只覆盖三种情形——在中国政府主办或承认的国际展览会上首次展出、在规定学术会议上首次发表、他人未经你同意泄露。自己往公开仓库推代码，一条都不沾。
我错在哪
我一直把「做出来」和「发布」当成同一件事的两个步骤：做完 → 发布。
但专利看的是另一条线：先申请 → 再公开。
两条时间线一撞，就是现在这个结果。这不是技术问题，是节奏问题——我从来没在「动手写」和「推上去」之间，留过任何缓冲。
我现在的做法：30 分钟规则
改法很简单，只在工作流里加一个动作：
每当要做一个有技术含量的功能，动手前先花 30 分钟写一份技术交底书。
为什么必须在动手前？因为那一刻你脑子里最清楚三件事：
- 要解决什么问题
- 现有做法差在哪
- 我打算怎么改
这三样正好是交底书的骨架。等做完了再回头补，细节早忘了，你只会写出一句「我做了个 XX 功能」——这在专利上是废纸。
写完存本地，再发一份到自己邮箱，留个时间戳。然后该写代码写代码，该发版发版，一点不耽误。
交底书不是专利申请文件。 不需要权利要求，不需要法律术语，写得让一个懂技术但不懂你项目的人能看懂、能复现，就够了。
几条反直觉的坑
踩过之后，我专门去读了 2026 年 1 月 1 日施行的新版《专利审查指南》。有几条和直觉相反：
1.「换了个处理对象」不是发明点。
新指南给了一个例子：识别船只数量的方法，跟识别果实数量的对比文件相比，「区别仅在于识别对象的不同」，没对训练方式或模型结构做调整——不具备创造性。所以「我把配置文件换成了资产清单喂给大模型」这种说法，不构成创新。
2. 技术问题得是「计算机的问题」。
「运维效率低」「管理不方便」是业务问题，不算数。要往下钻一层，钻到数据、计算、存储、通信。比如「在十几个数据源、字段口径不一致、又没有统一主键的条件下，怎么消除资产关联的歧义」——这才是技术问题。
3. 宁可写具体，别想着「通用」。
程序员的本能是抽象出一个通用框架，但交底书阶段越具体越好：场景、约束、参数、边界全写死。上位概括是后面撰写阶段才需要考虑的技巧。
4. 算法得跟技术环节「咬合」才算数。
只写「我用了大模型」没有任何用，得说清楚算法是怎么跟具体技术环节相互作用的。
如果你也在边写代码边攒专利
按这个清单来：
- 动手前 30 分钟，写交底书（技术问题 / 技术手段 / 技术效果）
- 交底书存本地 + 发一份到自己邮箱
- 打算申请的东西，绝不推公开仓库，用私有仓库或内网 Git
- 参赛、答辩 PPT、公众号、技术分享、README 里的架构图——全算公开，同样先申请再讲
- 别指望六个月宽限期，自己发布不适用
- 要开源和要专利，二选一；或者「先申请、后开源」
- 先确权：学校 / 公司项目大概率是职务发明，申请人不是你个人
最后一件事
写完上面这些，我愣了一下——
这篇文章本身，也是一次公开。
所以它只讲了方法论和教训，没有写任何具体的技术方案。以后哪位朋友想复盘自己的项目，也请先想清楚：你要说的这件事，会不会把你自己的那个窗口也关上。