京东一小伙一年输出20篇专利，其实你也可以

前言：

        ☆ 本文属于技术总结类干货分享，是实战但又不同于实战，所以不能保证每位同学读后都可以立马自己也输出一篇合格的专利；

        ☆ 但通过本文的总结分享，已经帮身边同学半年内输出大于100篇专利，所以如果你细致的读到最后，再结合自己的实际开发经验，是可以有所思，有所为的；但如果只是走马观花的看一遍，可能是没有效果的。

        ☆ 本文发布于CSDN平台，不带有任何业务信息，不带有任何代码信息，立足于行业内总结思考而分享。

        ☆ 希望本文可以给你带来帮助。

目录

一、为什么要写专利

1、各有原因

2、写专利的好处

3、给面试带来的好处

4、开发人员不爱分享

二、做为开发人员，我们写什么？

1、微小而垂直的创新

2、你熟悉的领域

3、找痛点

4、有些东西不能带到专利里

5、从哪里找到那么多痛点？

三、一篇技术专利的生命周期

1、构思阶段

2、利用模板文档书写

3、提交，等待专家评审

4、外部撰写机构

5、等待专利局评审

四、当场写一篇吧

描述准备：

1、当前业内问题

2、当前行业内的解决方案

3、目前解决方案的痛点

4、本方案要实现的核心

5、本方案的实现步骤（语言步骤）

6、本方案实现步骤（流程图步骤）

7、专业名词解释

最后

 

一、为什么要写专利

1、各有原因

        有人是被动的，公司内部有要求，年初或者季度之初有KPI，每个人要求产出一定量的专利；有人是主动的，通过工作中发现的痛点，进行业内方案实现与总结，再利用模板快速输出；有的人没有输出过，干过的公司没有这个业务模块，没有这个要求，身边的人没有类似经验，所以一直还以为专利是一个非常高精尖的产物，非常人所不能，所以不知道怎么产出。

 

2、写专利的好处

        专利这个词如此的高端，写了一定是有好处的。有的公司会给予的一定的奖励，有的公司会进行表彰没有奖励，有的公司甚至没有这项业务。

        写一篇专利，首先锻炼的是自己对于某一个技术实现的思路创新，慢慢影响的时候身边的人，或者需要用到这项技术实现的所有人。

        所以你得到的不仅仅是一张纸，可能是额外的金钱，可能是圈子内甚至业内的专业影响力，还可能会更多。

 

3、给面试带来的好处

        也许你输出的只是一篇普普通通的专利，但如果你可以表现在简历上，这绝对胜过一个重点项目。HR一定会觉得此人头脑灵活，可以帮助团队解决问题。而技术leader看到你的专利，至少他会觉得你可以给他们的团队带来一定的活力，将来一定可以带动整个团队的专利事项。

 

4、开发人员不爱分享

        一直到现在我发现很大一部分开发人员有一个共性，不爱分享。宁愿自己熬夜加班做需求，但不喜欢跟别人review自己的代码；可能让他研究一项技术点，但他却不想跟人分享他是如何完成的，甚至答应下来要分享，却也不知道以何种形式来分享，搞得分享会很多人就是听一听，他讲一讲，只要别人不用你这项研究成果，那么他就不会主动去参与讨论；很多人不想分享，怕自己的点子被人提出质疑，让自己难堪；有的人不敢当众讲话，紧张，记得有一次晋升述职，有个同事讲着讲着断片了，讲得自己满头大汗。

        也就是不爱分享，不想分享，怕自己写的专利被人质疑，甚至感觉自己会受到嘲笑，所以宁可不参与。以上的各种技术人员的惰性，担忧，一旦你输出一篇有力的专利，影响到别人，不就可以在提升自己影响力的同时，战胜掉那些惰性和担忧吗？

 

二、做为开发人员，我们写什么？

1、微小而垂直的创新

        现在如果你想做一个大的创新，那已经很难了，但我们仍然可以从日常手头的工作中去发现某些小的技术类创新。

 

2、你熟悉的领域

        而专利写的一定是你所熟悉的领域，也就是开发领域。切不可发现马桶哪里不合适了你写一写，你发现快递盒子哪里不合适了，思考一下。这是很难的，因为你对那个领域不够熟悉，那么你想出来的很可能是人家已经淘汰掉的思路。

 

3、找痛点

        其实刚开始我听到痛点这个词的时候，听着挺别扭的，觉得就是很多人爱噪生词，痛点痛点，听着真难听。但久而久之，发现这个词是真的很恰当。因为痛，我们才要费心费力去解决。这里从前端角度随便举几个例子吧，怎么算痛点。下一步呢，我会随便举一个例子，带大家分步骤写一篇专利。

        △ 比如你网站的图片特别大，所以每次渲染的时候就很慢，这已经算痛点了吧，你经过查资料，去各种平台查，又问过很多朋友，经过努力发现已经达到最大的进步空间了。这个时候你再想出来的点子，使大图片渲染的更快的这个点子，就是你独一无二的专利初衷；

        △ 比如你的管理平台已经做到第4期了，前3期都用的elementUI，到第4期的时候做一项工作，出了一个技术难题，比如el-table那根线就是怎么弄也弄不好。而更换UI组件已经不可能了，而目网上以至于element团队都没有解决这个问题。你经过自己的发力，最后采用了何种手段得以解决，这就是你的专利点子；

        △ 比如你的H5页面要嵌套到webview内，发现了一个问题。而这个问题业内为了达到相同效果，没有解决而是选择绕道而行的方式，那么你的解决方案就是独一无二的；

        △ 可能前3种都比较有难度，也可以是某一种实现方案，目前大家都是如何做的，但基于事物的两面性，每一项实现方案都是又带来了弊端的，那么你就可以想一种方案，只要是与其他几种实现方案不同的，而且也不会带来他们的弊端，也是可以写的。

 

4、有些东西不能带到专利里

        专利总计出来以后是一个方法论，是解决整个行业内某个问题点的方法论，所以你的专利里切记不带有某一项平台内的特殊业务，因为可能你这个平台业务在外面的公司平台根本就没有，而且你写出去也有泄漏公司业务机密的风险；

        不能带有代码，你的步骤，实现应该一种方法论，而不是特定的某一种开发语言的代码，所以有代码的部分要用语言去实现。而且要让别人可以看懂你的思路，步骤，解决的问题，而不是贴一段代码。

 

5、从哪里找到那么多痛点？

        当然是你最熟悉的开发领域，从你日常的开发工作中，只要你足够细致，你会发现每天日复一日的工作可能大家都是这么做，但你却在一个bug中发现了与众不同的东西；

        从日常的分享会中，只要有人分享，那么他一定是经过深思熟虑过的，而你经常他的思想的指引，再结合自己已知的实现思路，相信只要肯用心，总能憋出一种新的方案；

        读别人的博客，虽然现在博客良莠不齐，但读的多了，总能发现哪些人是在分享干货，哪些是在拷贝别人的经验去增加自己的平台积分，相信百篇博客中总能找到一篇与众不同的，也许这个与众不同的就会给你带来思路。

 

三、一篇技术专利的生命周期

1、构思阶段

        专利最重要的就是你这个点子是否足够新颖，是否足够解决当前痛点，所以在决定要写一篇专利的时候，一定要衡量，对比自己的这个思路，是否可以成型，是否会被评审专家否决掉，如果有人提出质疑你该如何提出自己准备好的观点；

 

2、利用模板文档书写

        专利最初的文档也就是交底书，是有一定的模板规范的。而不是自己写一篇流水账文章就完事了。不过这篇模板总算不是特别难，而且只要你写一个，根本谈不上难。

        记得有一次需要写PPT，我就想到了这么多年的office软件经历。word是干什么用的？写字的。excel是干什么用的？写字的。PPT是干什么用的？好像还是用来写字的。

 

3、提交，等待专家评审

        其实很多大公司可能有所谓的评审专家，他们可以根据自己的经验，去评判你这个点子或者构思是否足够新颖，解决了你所描述的问题。但有的公司所谓的专家，可能你写的东西他也不知道，也不懂；甚至有的公司没有评审，总共也没几个人，没法评审，直接就跳到下一步了；

 

4、外部撰写机构

        几乎很多公司吧，内部不设有专利撰写部门，有第三方专业的团队进行撰写。他们同样会根据你的初始稿也就是那篇超级简约的交底书进行评审，他们可以搜索到更全的平台文档，根据题目，内容，思路做对比。如果有重合度较高的，会问你是否还要补充或者想出更加不同的实现点子；如果他们这一步也通过了，最后会写一份专利提交文档，准备提交给国家专利局的，他们会把这份文档发给你看看，对他们写的有没有什么异议。一般人估计这一步也提不出异议来，因为你当时写的也就是一页，而他们给看的是一份80页的文档，里面几乎已经找不到你思路的影子了。你就大致看一看就可以了；

 

5、等待专利局评审

        这一步很漫长，2年到5年都有可能，所以慢慢的你会忘记你还有一篇专利在专利局，也可以更好的让你放心期待的心情，去准备构思下一篇。

        不过在公司输出的专利属公司所有，如果你哪天离职了，哪怕通过了，也不属于你了。

 

四、当场写一篇吧

 

描述准备：

        今天我们随便写一篇大众一点的，就不写奔驰一点的了。

        比如某些平台C端展示的是一个图片，用户点击图片的时候会跳转到对应的链接去。而这个链接是由管理员配置上去的。我们都知道管理平台输入链接的地方一定是一个输入框，而这个输入框带来的弊端就是很灵活，管理员高兴了输入一个链接，不高兴了想输入啥输入啥；就算他高兴了，由于每天事物繁杂，可能输入的是一个错误的链接，比如这个链接根本就是一个无效链接，C端用户点了直接跳转到404页面去了，这是一个非常大的用户体验问题。所以今天这篇专利就围绕判断链接有效性来展开。

        以下说的是具体的书写步骤，如果大家觉得这个例子不太适合自己，或者觉得下面的书写步骤比较简单，自己写的时候好好润色一下。

 

1、当前业内问题

        在当前软件行业平台中，C端前端很多链接URL都是通过对应的后台管理系统配置出来的，而由于管理系统配置存在很大的人为因素，所以时而导致C端链接无效，致使用户在点击到这一元素的时候跳转到了非预先准备得页面，严重影响用户体验。

 

2、当前行业内的解决方案

        一般情况下为了使管理员在配置链接URL的时候，会进行链接的校验，一般都是通过前端正则表达式，判断输入的链接是否是有效链接，从而很大程度降低了错误链接的配置。

 

3、目前解决方案的痛点

        由于正则表达式的校验只是判断了链接的格式是否正确，但如果管理员配置的是一个格式正确，但是已经失效的链接，仍然会致使用户跳转到非预备的页面，根本问题仍然得到解决。

 

4、本方案要实现的核心

        本方案希望可以在验证链接URL的正确性后，利用链接URL的HTTP网络属性，进行一次网络请求，一旦请求未返回HTML文档内容，则表示次链接异常，并做出提示；一旦正常返回HTML文档内容，则表示链接正常，可以继续做配置操作。

 

5、本方案的实现步骤（语言步骤）

        ☆ 在配置链接URL的输入框后布局一个检测按钮；

        ☆ 当管理员输入完链接URL后，可点击按钮做验证操作；

        ☆ 先通过正则表达式判断链接格式是否正确，进行第一步验证；

        ☆ 验证通过后，向此链接发送AJAX的GET请求；

        ☆ 请求dataType格式设置为HTML格式；

        ☆ 等待请求结果

        ☆ 成功返回，则表示链接正确，给出相应提示；

        ☆ 返回异常，则表示链接失活，给出相应提示

        ☆ 以上，不仅通过前端格式验证，还通过提前试探请求链接URL是否存活的方式，大大改善了配置错误链接的几率，从而有效提升了用户体验。

 

6、本方案实现步骤（流程图步骤）

 

7、专业名词解释

        这里是对本方案中一些专业名词的解释，例如方案中提到的AJAX请求、正则表达式等等，目的就是使比较不懂技术的人也能明白方案的可落地性。

 

最后：

        使用CSDN平台已经有10年了吧，感谢有这样的平台可以让自己分享一些东西。知识嘛，就应该自己融汇了以后分享出去，只有在分享的过程中才能知道自己掌握的程度，这也是一个突破自我瓶颈的方式吧。

        

         之前有个同事的签名是 见自己，见天地，间众生。有时候我还开玩笑的说，你站在大街上不就正是也看见自己，看见天地，看见众生了吗？其实对于我们做软件开发的人来说，每个人每个阶段都会有一个所谓“见”的认识。之前给朋友们分享专利的思考也是同样，自己掌握的东西，我不怕分享给别人，并不是分享给了别人自己就会少更多的思路，就会堵住自己的道路。而是自己分享的越多，探讨的越多，你才能精进的更多。

        希望我书写的内容可以给大家带来帮助！！！