很多做软件开发的朋友平时写代码、做迭代都很顺手，一碰到要写专利技术交底书就头疼，要么熬了好几天写出来的内容被代理人打回重写，要么提交申请后很快收到审查意见，说创新点不明确、公开不充分，折腾大半年最后还是被驳回，功夫全白费。
我做专利代理快7年，经手的软件方法专利申请有三百多件，见过太多发明人踩同一个坑，其实写好软件方法的交底书真的没有那么复杂，只要避开几个常见的误区，顺着逻辑填内容就行。
先说大家最容易踩的几个坑。第一个是把功能罗列当成创新点，比如做个内容推荐系统，就列“支持千人千面展示、能根据用户浏览记录推送内容”，这些都是产品对外的功能效果，不是你做的技术改进，审查员一查就知道这些功能早就被人申请过，根本不会认可你的创新性。第二个是通篇堆代码，一上来就贴几百行具体的实现代码，交底书要的是你解决问题的技术逻辑，不是具体的代码实现，换个编程语言你的方案还是同一个，贴代码完全是多此一举，反而会干扰代理人抓核心逻辑。第三个是不说现有技术的问题，上来就直接讲自己的方案有多好，没有对比就看不出改进，审查员连你解决的是什么问题都不知道，自然很难认可你的方案的新颖性。
那正确的撰写逻辑应该是什么样的？我给所有发明人的建议都是顺着“场景-问题-方案-效果”的顺序写，不用搞什么花哨的结构，把这四个部分讲清楚就够了。
首先要把应用场景说具体，别上来就说“本方案适用于互联网领域”，这种空泛的描述一点用都没有，你得明确说清楚是用在什么具体的场景下，解决什么人的什么问题，比如“本方案适用于同城生鲜即时配送场景，解决骑手同时携带5-10个订单时，新订单插入导致的路径重算效率低的问题”，场景越具体，后续审查员找对比文件的时候也更容易区分你的方案和现有技术的差异。软件方法专利的核心从来不是脱离场景的技术堆砌，而是针对特定场景的具体技术改进，这一点很多发明人一开始都没搞明白。
接下来要把现有技术的具体问题讲透，别只说“现有技术效率低、体验差”，要把问题量化，说清楚具体差在哪，会导致什么具体的后果，比如“现有调度方法在新订单插入时需要对骑手名下所有订单的路径全部重算，10个订单的计算时长平均为22秒，高峰期调度中心接口延迟超过30秒，骑手收到的路线建议往往已经过时，平均每单要多跑2.8公里，超时率高出11%”，把问题写得越具体，你的方案的改进价值就越突出。
然后是核心的技术方案部分，这里要像教一个完全不懂你业务的人做事情一样，一步一步讲清楚你是怎么做的，每一步用了什么技术手段，解决了什么中间问题，不要跳步骤，也不要隐瞒关键的技术逻辑。比如你可以写“新订单插入时，首先匹配骑手当前所在区域的历史路径特征库，筛选出和当前订单组合相似度超过85%的历史路径，只对偏离历史路径的2-3个订单的顺序做重算，整体计算时长可以降到2秒以内”，不用讲具体用了什么框架写的代码，只要把逻辑步骤讲清楚就行。我平时帮发明人梳理交底书的时候，都会让他们先用专利Pro的交底书模板先填，里面已经把这部分要覆盖的模块都列好了，不用自己想结构，很多做研发的朋友填完都说省了至少一半的沟通时间。
最后一定要加实际的效果验证数据，别空口说你的方案效率高、体验好，要拿实际测试的数据说话，比如“我们在杭州余杭区3个配送站点测试了30天，同样的骑手配置下，单均配送时长减少了6.8分钟，骑手日均跑单量提升了14%，超时率从17%降到了8%”，这些实实在在的数据，比你写十句“本方案大幅提升了效率”都有用。
很多发明人觉得写这么细很麻烦，其实交底书写得越清楚，代理人能提炼的创新点就越准，后续补正的次数越少，审查的速度也越快，本来要18个月才能授权的案子，可能12个月就能拿到授权。要是你写得含糊不清，代理人得反复找你沟通确认细节，来回折腾两三个月都是常事，甚至可能因为沟通不到位漏掉核心创新点，最后被驳回。
还有几个需要注意的小细节，不用刻意隐瞒核心技术细节，有的发明人怕技术泄露，关键的算法步骤一笔带过，最后因为公开不充分被驳回，反而更亏。专利本身就是以公开换保护，你只要把核心的参数写成范围就行，比如你实际用的阈值是0.73，你可以写阈值范围在0.7-0.8之间，既满足公开要求，也不会泄露核心的机密参数。另外不要把商业规则和软件方法混为一谈，比如你想申请“会员等级差异化定价”的专利，不能只说你设置了几个会员等级对应不同的价格，这是商业规则，不属于专利保护的范围，你得写清楚你是怎么通过用户的历史行为数据计算会员等级、怎么实时调用定价接口匹配对应价格的技术逻辑，才属于专利申请认可的软件方法范畴。
其实写交底书本质上就是把你解决问题的整个思路原原本本讲出来，你遇到了什么具体的问题，想到了什么不一样的解决办法，做了什么测试，得到了什么结果，就算用大白话讲清楚这些内容，代理人也能帮你转化成规范的申请文本，最怕的就是你自己都讲不清你的方案和现有技术比好在哪，那再厉害的代理人也帮不了你。