❶ 請教一下，什麼是智能硬體開發
智能硬體開發是指通過設計、製造、測試等環節，將物聯網技術、人工智慧技術、大數據分析等融入到硬體產品中，創造出全新的硬體產品形態，以適應不同的應用場景和需求。
智能硬體開發需要具備多方面的技能和知識，包括硬體設計、軟體開發、系統集成、測試驗證等。其中，硬體設計涉及到材料選擇、電路設計、感測器應用、機械結構設計等方面；軟體開發涉及到嵌入式系統開發、APP 開發、雲端平台開發等方面；系統集成涉及到設備連接、數據交互、流程式控制制等方面。
如果您想了解更多關於智能硬體開發的內容，機智雲物聯網是一個很好的選擇，他們有物聯網自助開發平台和智能硬體開發方案的相關案例。
機智雲是一家專業的物聯網雲平台服務商，擁有豐富的硬體設計和軟體開發實踐經驗，能夠提供高品質、高性能的智能硬體開發方案，包括從硬體設計、軟體開發到系統整合的全面服務。藉助他們的智能硬體開發方案，無需編寫代碼即可輕松實現設備智能化，免去設備智能化復雜的開發流程，大大縮短了開發周期，又避免研發生產新品的高投入。
❷ 智能硬體產品的軟體設計
我一直相信努力會有回報，一直在公司推的擴展器APP項目終於做起來了。目前UI，UE已經完成，軟體開發和APP開發的介面也對好了，就等排期進行開發了。我覺得自己的運氣也是極好的，本來一個APP項目是很難立起來的，這期間經歷的挫折和打擊也不少，還好搭著costdown項目的順風車一起做了起來。本文主要講講整個硬體產品的軟體設計中自己的經驗，雖然以擴展器為例，但是這些點適用很多智能硬體產品的軟體設計了。
既然APP都要做了，則索性將PC端和H5端都進行了一次迭代，由於接手過來的時候PC端和H5端產品都已經做了一個初版，但是都沒有相關的文檔，所以自己全部重新整理了一遍PC端，H5端的文檔。當寫一個新的產品或者功能的prd的時候，我是可以根據自己的邏輯和思路一氣呵成的，但是這個我需要在同一個文檔里既整理出現有產品的內容還得加入新的想法進行改進。這就要求我得先對已有的功能邏輯完全了解，然後思考這個邏輯是否合理，有沒有更好的方案。更奇葩的是，有些邏輯我覺得是混亂的，在詢問之前團隊時，他們居然說當時有些異常情況沒有遇到，沒有去做相關的測試，所以沒有梳理相關邏輯。因為項目的推動不容易，主要是因為開發資源比較緊張，在和開發商量的時候答應過開發，PC端和H5端的升級會盡量減少開發的工作量。因此在梳理文檔的時候，只是整理現有邏輯，修改不合理的邏輯，梳理之前團隊沒有想的邏輯，新功能一個都沒有添加。關於PC端和H5端這塊，我只想給出以下建議：
遇到中途接手的項目，並且沒有相關文檔可以參考的時候，三點建議：
第一：一定是需要把已有的邏輯了解透徹，記錄下邏輯還有優化的點以及邏輯混亂的點，自己先梳理一遍之後再去和現有的開發團隊對一下有沒有什麼問題；
第二，考慮到開發也是根據現有的程序做修改，在文檔中把有改動的點一定要做標記，清楚描述現有邏輯是怎樣的，修改後是怎樣的，這樣方便程序員查看；
第三，除了有些邏輯進行了相關改動，為了更好的用戶體驗，交互方面也做了些改動。坑爹的是，翻看公司之前的UE和UI資料，發現做出來的產品和資料對不上，這可苦了UE和我了。我給UE把整個產品操作流程錄了下來方便她對著現有做出來的查看，然後把要修改的地方在文檔中標記出來，拜託她對著標記的地方做相應的修改。最後我再把她做出來的UE圖仔仔細細對好幾遍，有不對的地方得記錄下來拜託她再修改，這還得來回好幾次。
雖然過程繁瑣了點，但是比推項目的時候開心多了。而且這樣一來，我相當於把一個硬體產品所需要的軟體設計全部做了一遍。雖然說擴展器的功能比較簡單，但是能把架構和細節都過一遍，也學到了不少東西。畢竟之前做路由APP的時候全部做的是功能點，沒有一個整體的概念。
這部分主要是根據自己做擴展器APP的經驗，介紹一下在設計智能硬體產品APP的時候需要注意的部分重點。智能硬體產品APP不同於純互聯網APP，它的設計需要考慮的端比較多，每一個邏輯都需要考慮到所有的端的情況，不同端之間會相互影響，不同的網路情況又會對不同的端造成不同的影響。所以那個情況多呀，異常多呀，有些功能稍微復雜點的寫出來的prd快趕上一個APP了。今天呢，不談這些細節，細節還是放在具體的功能設計裡面去說比較合適，今天只說在新做一個硬體產品APP時需要考慮的切入點。
一般來說，對硬體產品APP而言，重要的有如下模塊：
接入，首配，工具
對於一個剛起步的硬體產品APP來說，其中最重要的是 接入 和 首配， 只有簡易快速的配置連接硬體，才談的上控制硬體，即工具和APP的其他功能設計。
接入主要考慮的是APP如何識別出硬體產品，識別是不是自己公司的產品（只有自家的產品才能進行通信控制）以及是自家公司的哪個產品（不同的產品，其首配，工具等等很多功能都是不一樣的）。由於公司的硬體產品比較多，最好的是能夠將相同性質的硬體產品集成在同一個APP裡面，這樣既方便產品的開發，用戶體驗也會更加友好。擴展器同路由器一樣同屬網路產品，再加上擴展器本身就需要搭配路由器使用，因此我所負責的擴展器APP是直接集成到現有的路由APP里。識別是否為自家公司的產品好做，一般待配置產品的SSID（網路名稱）都是帶有自家公司的名稱的，根據SSID就可以直接判斷了。那如何識別這是一台路由器還是一個擴展器呢？連接上設備的網路後，路由器是有IP地址的，APP可直接通過訪問IP發送消息來確認是路由器。但是擴展器只有在擴展成功後才會有分配的IP，而且還是變化的，因此不能使用和路由器一樣的方法進行識別。產品處於待配置狀態時會廣播一些欄位，其中就有MAC地址，原以為可以通過對Mac地址進行管控，直接將一段Mac地址對應一類產品，這樣就可以直接通過Mac地址進行識別產品類型。然而首先我們公司並沒有做Mac地址的管控，其次APP通過廣播接收的Mac地址信息會有一定的不準確性，因此這種方法不可行。但是廣播出來的欄位又沒有其他有用信息可利用了，所以又回到了SSID上，我們決定給SSID加上後綴名，表徵它是一個擴展器。因用戶在首配和無線設置中是可以修改SSID的，為了始終能夠識別（除了首配的時候需要進行識別，在用APP切換設備管理的時候也需要對連接設備進行識別），後綴名不能讓用戶改動，這個我們在交互層面上做了一定的設計，而在理解上，則參考Word之類的文檔名稱一樣，只能修改名稱，不能修改後綴名。從SSID上進行識別只是一個初步識別，在初步識別後還會通過嘗試通信讓擴展器發送一個產品類型的欄位進行確認。
這樣整個識別接入的邏輯才算完整，開發做起來相對簡單，用戶體驗也沒有太大影響。
不同的產品的首配流程是不一樣的，這里只談一些共識點。首配需要首先檢測是否首配過，檢測方法在了解後略微有點low。主要是根據WiFi名稱是否被更改過以及是否有設置密碼來判斷。當然，若恰好某台配置過的路由器既沒有修改WiFi名稱還沒有設置密碼，那不好意思，我們判斷不了，可能需要重新配置一次了。整個首配流程在設計的時候一定要簡單並且防呆工作做好，不然一步錯導致步步錯就會帶來極差的用戶體驗，而首配的失敗會讓用戶對整個品牌和產品的好感度消失。無論是在路由配置還是擴展器配置中，首配基本上都是「一氣呵成」的，也就是把所有的設置項都選好後記錄下來，中間沒有任何生效的點，只有最後一步才會將所有的設置生效。而有一點不一樣，就是管理員密碼的設置是直接生效的。在體驗產品的時候會發現，在保存管理員密碼後不進行接下來的配置，退出後再次進入則需要輸入管理員密碼；而且輸入後不能進入首頁（也就是不能），而是進入繼續配置的頁面。為什麼要提到這些，因為有兩個方向的考慮點，一是管理員密碼有沒有必要和接下來的配置分離開，二是用戶就是不想配置連網就想使用工具控制設備的場景怎麼處理。PC端現在做的還是分離和不能進入，而APP不同的是，用戶在輸入管理員密碼後可以跳過配置，直接進入首頁，因為考慮到APP是有與硬體不相關的功能（比如社區）和賬戶體系（比如我）。分離是為了設備管理的安全性著想；不能進入考慮的是大部分場景：沒有擴展連網，設備的意義不大，所以還是盡量引導用戶去配置完成。
以上幾點是首配中比較容易混亂的大的邏輯點，其他的步驟是根據不同設備的連網需求而有所不同的，這個裡面的細節也是非常的多，本文就不做過多的描述了。
不得不說，文章排版有點.......（不過內容可是真真切切的的實戰干貨）我實在不想把時間花在排版上，因為還有好多東西要學，好多內容要盡快輸出。此時的我已經換了個部門，現在已經不是硬體產品經理了，目前是一名社區產品經理。所以很多東西要盡快學習熟悉起來，不然要被人懟死。以後輸出的和硬體相關的產品設計文章可能不多了，社區產品相關的文章請拭目以待。