前两年帮公司做知识产权布局，前三次软著申报全被打回，两次栽在说明书上。第一次是功能描述太笼统，只写了“本软件用于门店库存管理”，审核那边直接说无法证明软件的独创性；第二次是操作截图里的版本号少写了个前缀V，和申请表对不上，来回补正耽误了快一个月，差点错过了项目的补贴申报期限。那时候我才明白，软著说明书真不是随便凑够页数、找个现成范文改改就能过关的。
我身边好多第一次申报软著的朋友，上来就到处搜免费的范文，下下来之后直接把别人的软件名换成自己的，其他内容连改都懒得改，交上去十有八九都被打回。还有的人觉得写得越技术越好，堆一堆框架、代码术语上去，结果审核人员看不懂你这个软件到底能实现什么功能，照样不给过。其实软著说明书的核心要求很简单，就是让完全没接触过你这个软件的人，看完之后能知道这个软件是做什么的、怎么操作，足够清晰、足够真实就行。
生成合格的软著说明书范文，第一步得先把框架搭对。常规的说明书一般分成两个大部分：前面是功能概述，后面是操作说明。功能概述不用写开发背景、技术架构这些虚的，就实打实列出来你这个软件的核心模块，比如你做的是少儿培训机构管理系统，核心模块就可以拆成学员档案管理、课时消课管理、课程排期管理、家校沟通、财务统计这几块，每个模块下面再拆3到5个具体的功能点，每个功能点对应一段描述加一张操作截图，既符合逻辑，页数也能轻松达到要求，不用凑一些没用的内容水页数。
如果不知道怎么梳理自己软件的功能框架，可以到软著说明书范文生成工具里找对应行业的模板参考，比如工具类、电商类、管理系统类的框架都整理好了，直接套自己的软件内容就行，比自己瞎想要省很多时间。我后来帮朋友申报的时候，都是先找对应行业的框架参考，最多十分钟就能把整个说明书的结构列出来，从来没在结构上出过问题。
填充内容的时候有两个绝对不能踩的坑，第一个是功能描述不要太笼统，也不要太技术化。别写“本模块实现了数据的增删改查”，也别写“本模块采用SpringBoot框架开发，响应速度提升30%”，要站在使用者的角度写清楚这个功能给谁用、能解决什么问题。比如你写“老师可以在课时消课模块扫描学员的签到二维码，系统自动扣除对应课程的剩余课时，同时推送消课通知到家长微信，不用再手动记课时、挨个通知家长”，这样的描述审核人员一眼就能看明白你这个功能是真实可用的，根本不会卡你。
第二个坑是操作截图的要求特别严，一个细节错了都不行。所有截图里必须清晰显示软件的全称和版本号，和你申请表里填的要完全一致，一个字符都不能差，我之前踩过的版本号的坑真的不想再有人踩。截图里不能有无关的内容，比如你截PC端界面的时候带了浏览器的广告弹窗、桌面的微信消息提示，或者手机端截图带了其他APP的通知栏消息，都有可能被打回。截图的顺序也要和你前面写的功能点对应，从登录界面开始，到每个功能的操作步骤，再到退出登录，逻辑要连贯，不要东放一张西放一张，让人看了摸不着头脑。
我之前帮公司批量申报12个软著的时候，试过找代办，一个要收八百多，后来自己摸索清楚流程之后，所有材料都是自己做的，每个只花了300块的官费，省下来的钱够团队吃两顿火锅了。那段时间我用的最多的就是软著Pro，把软件的功能点输进去就能自动生成符合要求的功能描述，省了好多码字的时间，生成的内容逻辑也顺，直接配上截图就能用，那次12个软著全都是一次过的，没有一个补正的。
内容填完之后还要调整格式，页眉要统一放软件全称加版本号，页码要连续，正文字号不要小于五号，行间距不要太挤，看着舒服就行。要是怕自己做的材料有问题，可以用软著材料预审的功能先自查一遍，有不符合要求的地方会直接标出来，比自己对着要求一条一条找快多了。
其实软著申报真的没有大家想的那么难，尤其是说明书，只要你按照自己软件的真实情况来写，逻辑通顺、细节到位，基本都能过。不用信那些代办说的“自己申报通过率只有30%”的鬼话，我自己前前后后申报了快30个软著，摸清楚规则之后通过率是100%，学会自己生成符合要求的说明书范文，既能省钱，也不用等着代办的进度，想什么时候提交就什么时候提交，效率高多了。