前言：

? ? ? ? ☆ 本文屬于技術總結類干貨分享，是實戰但又不同于實戰，所以不能保證每位同學讀后都可以立馬自己也輸出一篇合格的專利；

? ? ? ? ☆ 但通過本文的總結分享，已經幫身邊同學半年內輸出大于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年了吧，感謝有這樣的平臺可以讓自己分享一些東西。知識嘛，就應該自己融匯了以后分享出去，只有在分享的過程中才能知道自己掌握的程度，這也是一個突破自我瓶頸的方式吧。

????????

? ? ? ? ?之前有個同事的簽名是 見自己，見天地，間眾生。有時候我還開玩笑的說，你站在大街上不就正是也看見自己，看見天地，看見眾生了嗎？其實對于我們做軟件開發的人來說，每個人每個階段都會有一個所謂“見”的認識。之前給朋友們分享專利的思考也是同樣，自己掌握的東西，我不怕分享給別人，并不是分享給了別人自己就會少更多的思路，就會堵住自己的道路。而是自己分享的越多，探討的越多，你才能精進的更多。

????????希望我書寫的內容可以給大家帶來幫助！！！

總結

以上是生活随笔為你收集整理的京东一小伙一年输出20篇专利，其实你也可以的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。