技術方案梳理以下是從發明人那里收到的技術方案：傳統的導航或路徑推薦系統，通常是從客觀因素（如路況、交通情況、時間和距離等）來推薦路線。但是，沒有考慮駕駛員本身的狀態（如精神狀態、疲勞程度）適合的路線可能不同。本方案能夠根據駕駛員當下的狀態推薦省心的路線。

   具體包括:導航系統提供用戶輸入接口或監控裝置，用于獲取用戶狀態。例如，情緒狀況、精力水平、是否分心、焦慮程度、急迫性、駕駛經驗以及對導航區域的熟悉程度等。另外，系統還實時獲取路況信息（如哪里在堵車/施工、其他司機反饋的路段難度等），以及各個候選路徑的環境信息（如道路質量、交叉口數量、彎道情況、照明情況等）。

   然后，系統根據獲取的實時路況和候選路徑的環境信息，可以確定每條路線的路線壓力。例如，根據實時路況和環境信息為每條候選路徑打分，分值越高路線壓力值越大。其中，路線壓力值越大，駕駛難度越大。為用戶推薦路線。可以在屏幕上用不同顏色標出路線難度，讓駕駛員一目了然。如果系統發現司機狀態很差（比如頻繁急剎車），還會自動切換更簡單的備用路線。 

   接下來，再看看基于上述技術方案寫的權要，能發現什么問題嗎？

   初始權要一種導航系統，其特征在于，所述系統由處理器執行，所述處理器被配置為：響應于接收到用戶的自身輸入數據，基于定位數據、路況數據和車內監測數據中的至少一種，確定多條候選路線的多個壓力數據；基于所述自身輸入數據和所述多個壓力數據，確定所述多條候選路線中的目標路線，并將所述目標路線推薦給所述用戶。其實單看權要本身，整體表述和邏輯沒什么大問題。但是結合技術方案，有沒有覺得權要后一步和技術方案不太匹配？問題出在哪里？

   根據上述技術方案，其實主要是基于實時路況和道路環境確定的路線壓力，對各個候選路徑進行打分排序，并標注出難度情況展示給駕駛員。到這里，路線推薦方法其實就完整了，和用戶自身輸入數據（即用戶狀態）幾乎沒太大關系。并且，如果是從省心的角度，那直接考慮路況推薦簡單的路線不就行了，不需要考慮用戶狀態。但是方案中大篇幅描寫了用戶狀態，肯定不是隨便寫寫。那這個用戶狀態與路線推薦、或者說與路線壓力值之間有什么關系呢？技術方案中并未說清楚。遇到這樣的技術方案怎么辦呢？

   正確的做法是：暫停權要的構建，及時找發明人溝通，澄清技術方案。經澄清，合理的邏輯是：相同的路況，對于不同狀態的用戶，壓力值是不同的。例如，新手司機在復雜路口的駕駛難度會更大；疲勞司機在夜間狹窄路段、急彎路段等駕駛難度會更大；著急趕路或者精神緊繃的司機在擁堵路線的駕駛壓力會更大。所以，這個方案的關鍵是要結合用戶狀態來確定各個推薦路線的壓力值；再根據壓力值排序，為用戶進行路線推薦。

   也就是說，方案中大篇幅描寫的用戶狀態其實才是技術重心。但是由于沒交代清楚，撰寫可能也未深究，導致權要出現了偏離。我們再來看看，根據澄清后的技術方案寫的權要，和澄清前有什么不同？修改后權要一種路徑推薦方法，其特征在于，所述方法包括：確定用戶的實時狀態，所述實時狀態反映用戶的情緒、精力和對行程的緊急程度中的至少一種；基于所述實時狀態、候選路徑的環境信息和實時路況，確定所述候選路徑的壓力狀況；基于所述壓力狀況，確定路徑推薦信息。

   可以看出，修改后權要在確定路線壓力狀況時，將用戶的實時狀態納入考慮；確定推薦路線時根據壓力狀況進行推薦；整體符合澄清后的技術方案邏輯，能達到結合駕駛員當下狀態推薦省心路線的目的。 前面說過，澄清前的權要寫法，從表面看其實也看不出問題。那是不是基于澄清前的技術方案繼續撰寫也沒問題？千萬別有這種“省事兒”的想法。一時“省事兒”，未來麻煩可能不少。一時“省事兒”會帶來哪些麻煩？雖然從權要表面看，技術方案的邏輯是沒有問題。

   但是，在撰寫說明書時，難免會因為忽略了技術方案邏輯上的“bug”而沒將方案寫清楚。一旦這個不清楚的“隱患”埋下，答審時才發現，可能就難以補救了。一些簡單的缺陷如果審查之初發現，可能說明書還有補救的機會。但如果直接被審查員指出邏輯問題，方案無法實現或者無法解決相應的技術問題，想授權就難了。即使審查員沒發現，在新創性答復時，如果需要抗辯“方案是結合用戶的實時狀態、路況信息和道路環境等共同進行路線推薦”。此時才發現說明書撰寫內容無法支撐觀點，也將導致答復的力度大打折扣。

來源：知觀知行  免責聲明：版權歸原創所有僅供學習參考之用，禁止用于商業用途，部分文章推送時未能及時與原作者取得聯系，若來源標錯誤侵犯到您的權益煩請告知我們將立即刪除。