一年多來，一直在項目目錄下的update_log.txt里記錄開發日志，今天放到網上來，共?6189個字。

————XiaoHu.ai Standard 代號STD————

2/6 v0.1 項目啟動，第一行負責錄音的代碼被寫了出來

2/8 v0.2 語音助手可以識別正則表達式指令，整合turing獲得聊天功能

2/9 v0.36 更換數據庫架構為xml，編寫了標記技術可以識別輸入語句里變量的存在

2/10 v0.4 添加日程管理：日程添加，日程查詢，日程刪除。編到晚上嗓子疼

2/11 v0.52 #修復日程的兩個bug 搞了一上午和一下午添加了點歌功能

2/12 v0.58 上午嘗試通過微信控制 不斷出現離奇bug 數據庫被清空，花了半個小時重寫了一遍 于是趕忙改了回來，順便優化了一下數據庫下午做了用微信控制電腦的小腳本 開學裝班級電腦上 晚上加了語音輸入和打開office后自動按回車的設置

2/20 v0.7 重新寫了微信控制的代碼，整體良好，在等待用戶輸入這個功能上費了好長時間，因為微信接收消息是被動的。后來一個變量在當前模塊不生效，在其他模塊生效，索性（在當前模塊中調用另一模塊調用的當前模塊里的變量）

2/21 v0.78 用多進程解決了微信版不能檢查提醒的問題，修復了一堆reminding的bug

2/22 v0.9 小虎已經基本完成，又添加了用戶需求的五個功能：[打開，搜索的自定義；修復輸入指令不能輸入回車的bug；自動下載播放本機沒有的音樂；音量的調節；離我最近的提醒]，為了操作網易云音樂下載了兩個大模塊，愣是把所有代碼用3個小時讀通了，把兩個模塊嫁接到了一起。Standard 1.0版本明天就要完成了，23日上午進行最后的完善和校驗，假期最后三天拍演示視頻

2/23 v1.0 Standard 又搞了好久把下載播放音樂的功能編完整了，大功告成~視頻我想等EVO完成后再拍，那樣更驚艷。

————總共1047行代碼————

————XiaoHu.ai Evolve 代號EVO————

?

3/11 開學了，開始小虎EVO版本的開發，大幅簡化播放音樂，添加提醒的過程

3/5-3/19進軍物聯網，第一次刷了raspbian和ha，可以查看燈的狀態但無法控制。于是兩個禮拜來一直刷hassbian和hass.io，結果發現系統都啟動不了，到了貴哥那里知道是供電，于是換了顯示器和電源。不知為啥hassbian和hassio可以啟動但沒有ha，所以又刷了raspbian，情況又和第一天一樣了。持續僵持，暫時休整。

4/5解決了持續快兩個月的大bug，刪除提醒刪除不干凈，于是機智地重寫了一遍，循環刪除，直到全刪除完了為止

4/6從姥姥家回家路上突發奇想，重新啟用科大訊飛api。科大訊飛的aiui自我步入EVO階段就一直想搞可惜它不支持python代碼，神奇的是回家一看發現它支持web post調用，于是申請了一個web應用，一個下午和晚上都忙于訊飛和小虎的對接。晚上再一次更新了數據庫的格式，刪除了一堆冗余的如runmode,runpath的tag，以及把之前一些tag的名字改成更易于理解的單詞，在變量命名上也與訊飛的json看齊，把之前的cmd“指令”改成intent“意圖”。又忙到了十一點..

4/7繼續忙于與訊飛的對接，訊飛的功能的確強大，使我精簡了一堆代碼，截至12點，小虎已經可以完成訊飛上95%的技能，達到小愛的75%水平。從此以后小虎的目標不是Jarvis而是小愛，小愛由于運行在手機上而有著得天獨厚的優勢，我想以后能不能把小虎的客戶端移植到手機上，保留電腦服務器端。不過那是下一個版本要做的事了。

4/21 4/9后給小虎定了10個小目標，兩個禮拜的現在已經基本完成了。多是一些重要優化，以及把放音樂的過程從調用win的media player改成了一個基于pygame的內置播放器，作為單獨進程執行，攻克了進程間共享變量的問題后就基本簡單了。新的播放器沒有窗口，在后臺運行，支持上一首、下一首、暫停、繼續等操作。

5/6期中考試后繼續搞XiaoHu，修復了幾個播放器的bug：在歌單中replay會播放第一首的bug；部分音樂網易沒有版權導致運行時報錯的解決方式；等等。XiaoHu距離物聯網的下一步已經很近了。

5/12 期末前最后一次編XiaoHu，加入了對訊飛API的超時處理，改了圖靈機器人無法處理的反饋。又用了一個小時的時間吧之前的爛代碼格式全部整理了一遍，XiaoHu的代碼現在除了注釋比較少之外基本能看。

4/9立下的十個目標都完成了。下一個是最后階段--HA。

————總共1218行代碼————

?

7/8 期末考完試開始編程，把期末前上廁所想到的“將HA安裝到win上”的想法實現，結果居然沒有報錯！無論是無線開關和夜燈都可以控制了。這是HA階段里程碑的一天。

7/14 新購置的傳感器到貨。添加了“自動化”功能，第一個自動化是通過檢測門窗傳感器達成開儲物間門時燈自動開啟，關門時燈自動關閉。一個bug讓我調了一上午，最后終于調好了。至此XiaoHu-HA階段的理論部分全部完成。剩下就是等月底搬家后大批量購置和建設自動化。由于XiaoHu的智能家居部分是全部模塊化的，所以月底就不用再多編什么代碼。

7/16 重新回到10space 上午做的XiaoHu的流程圖，下午在HA上搞了天氣組件，增加了簡報功能。修復了reminder的bug

7/17 做了一個與播放器原理相同的speaker，簡化了各個模塊的代碼。繼續修復提醒的bug

7/18 開始做電影的查詢和下載，通過編寫電影天堂和豆瓣的爬蟲實現下載、查詢的功能。我使用一個強大的模擬瀏覽器模塊selenium，這個模塊在我1月份開始學py做爬蟲時就聽說過，只是當時還是初學，對py了解不深，安裝都沒有成功。使用selenium可以讓我抓取一些動態網頁，或者是一些難爬的網頁。拿電影天堂為例，在主頁面輸入查詢電影名稱時，它會把電影字符串信息轉成一個ID，我通過Chrome的console試著找到轉換的規律，可并沒有找到。于是我使用selenium讓他模擬打開主頁面，再模擬輸入電影名稱，等轉到搜索頁面時，再把url轉給beautifulsoup，進行爬取。在XiaoHu播報電影查詢結果時，我發現了speaker的一個bug：由于它是連續播報，前一個語句還沒有播報1s，下一個就開始了，導致最后只放出來了最后一句話。7/23 經過調試我發現這是因為我給speaker設定的“同時只能有一個speaker存在”這是為了讓它在說話時可以隨意中斷。但它是異步的，沒有堵塞，就導致了這樣的情況。我、只好給它添加了“等待上一個speaker執行完”，解決了bug，卻犧牲了隨意中斷的能力。下一步我要做一個穩定的手機端client，貴哥建議我使用微信小程序。它使用js編程，有點像網頁。但由于我剛從py的順序結構程序轉過來，對js的事件驅動還不太適應。

7/24 我做了“機器人小程序”，通過使用圖靈機器人的API實現了自動聊天功能。對小程序有了了解，我計劃用py搭建一個服務器，使用http協議進行交互，搞了一晚上，最后發現http POST的方式只能一來一回，而這不符合XiaoHu的工作方式，只好把搭建好的服務器放棄了。我計劃使用socket將服務器與客戶端進行連接，達成一來多回的目的。

7/25 我計劃采用socket.io這一個已經充分封裝好的websocket模塊來通信。搞了一下午才找到合適的服務器，從django和flask中還是選了flask，最終使用flask-socketio，python-socketio和js-socketio分別是服務器和兩個客戶端，用js腳本先模仿微信小程序，指令從js端發出，通過服務器接收，由于服務器由python編寫，所以可以直接與XiaoHu源程序溝通，源程序調用py客戶端的send()方法，將反饋發給服務器，再由服務器轉發給前端。

7/27 上午11點就來到了10space，打算今天搞定小程序。到了之后就立刻開始wxsocketio的安裝，卻發現小程序的socketio無法與python的服務器和客戶端建立連接。無奈之下聽從貴哥的建議，使用node.js搭建服務器。下午搭建好了后發現可以與微信連接，卻不能與py客戶端連接。同時因為沒有了python的服務器，XiaoHu主程序無法獲取到指令。我的第一個方法是使用js的cmd模塊模擬win命令行調用XIaoHu主程序，再獲取程序所有的stdout。這種方法可以處理簡單的指令，但如果程序給的是“非一次性反饋”的話，它也會把所有的反饋湊在一起發給微信，這嚴重影響用戶體驗。而且由于主程序沒有連續運行，XiaoHu的上下文記憶功能受限，由于它的內置播放器是一個相對獨立的進程，如果主進程被迫“死掉”，播放器就會成為“僵尸進程”，不能關閉。我又想到給py客戶端添加接收功能，讓它從服務器獲取到指令信息。但另一個問題是這時的py客戶端由于不知名的原因，還無法與服務器進行連接。我上谷歌查了這種報錯的解決方案，github上說這個python-socketio庫早就停了更新，要使用另一個庫。我安裝了那另外一個庫，問題解決了。好不容易建立了通信，這時我又發現服務器又不能向客戶端發信息了。起初我以為是某個客戶端出了問題，但是經過排查發現都工作得很好。此時已快九點了。接了爸媽電話后又突然有了靈感，因為在25號的server-client模型中，每個發送操作都是需要廣播的，我想了一下，覺得客戶端的發送不需要廣播，反而是服務器需要用廣播把消息發給所有客戶端，于是我加了broadcast，一切正常了！到家，做了內網穿透，使得手機端小程序也可以參與通信。還修復了一些的bug。

————XiaoHu.ai Education 代號EDU————

?

10/5 開學后，XiaoHu轉型智能教室的構想逐漸成熟，docx設計計劃落地，前端設計草圖落地。

11/19 開始著手開發前端系統12/5 前端的HTML搭建基本完成，還剩下最大的一個問題是“div內換行問題”，我要讓我的文字在氣泡（承載了圖片的div）里換行，可是html內一個換行比我的氣泡都大，我用Line-height調整，又導致網頁的布局亂了，下周咨詢一下老師。

12/10 今天問了毛老師，他在div里加了一個p，用p把文字套起來后把line-height放在p里，成功了。好像是說line-height如果放在div內就會影響div的位置，放在p里文字的位置就會受限于div。前端設計完成了，開始搞網絡通信，使用XiaoHuEVO的server,client1,client2框架，因為有先前的經驗積累所以代碼移植過來后測試一次成功，周三把通信整個搞好。

12/13 今天把原EVO里的代碼都移了過來，去除了一些不會被用到的功能，完善了通信系統，可又遇到了新問題：即使這些python文件都放在一個目錄下，卻無法正常的互相引用。這是一個很奇怪的問題，因為在EVO的目錄下他們就可以正常引用。

12/15 今天查了一下import的相對引用和絕對引用，有了一些想法。我在根目錄下建立一個__init__.py，讓目錄成為一個大模塊，讓其余的py文件都成為它的子模塊，引用時通過母模塊調用子模塊，問題就解決了，這更類似于相對引用。我想了一下具體的用戶場景，覺得網頁在老師的手機上是不太方便操控的，而且絕不是最好的交互方式。而微信小程序也受限于其極短的生命周期不能作為前端。最后我選定了服務號，服務號在以前也作為小虎前端搞過，當時用的是itchatmp。現在我再搜索Python服務號解決方案時已經多了很多新的庫，這才五個月啊。

12/16 我的第一個選擇是使用wechatpy搭配一個wsgi使用，功能還不錯但是不知道為什么我一引用XiaoHu其他的py文件就會無法引用，這 樣自然是無法使用的。還有一個選擇是django，明天試試。

12/17 django有些繁瑣且多余文件太多，在查找其他可行解決方式時我看到了werobot，一個非常精簡實用的python微信公眾號庫，測試也是一遍過。但是我引用XiaoHu的brain后就發現它卡住不能運行了。經過一番“print”斷點調試后我排除了werobot自身的問題。并把目光鎖定在了brain自身引用的一堆XiaoHu內部腳本上，我輪流添加了斷點，最終發現了問題所在：brain引用了socket.py，這個socket本來是在之前的server-client架構里使用的，現在已經不用了，而它的代碼里有一行向服務器申請連接的代碼"socket_send = SocketIO('127.0.0.1', 3000)" 然而我連服務器都沒有運行，它自然會陷入無限的重連中。我還沒有把這行放在"if name == main"中。我注釋掉了這行代碼，問題迎刃而解。然而在測試中我又發現它雖然可以接受消息并傳給brain，卻沒有向用戶返回消息。這肯定是brain的問題。我專門有一個reply變量存儲brain作出操作的返回值，而在每次操作后reply被賦值前會有一個speak方法，用來讓XiaoHu說出操作反饋。我把speak注釋掉，發現它成功的返回了返回值。現在我知道是speak堵塞的問題，我試著不運行robot，直接在brain里通過輸入給出命令，不使用werobot的時候就可以說話沒有堵塞。這就成了問題：我要使用werobot，又要讓它語音說出結果。到家后想出了解決辦法：把speak函數放到控制聲音的audio.py里面，然后使用socket連接brain和audio，brain要想要說話，就要發信息給audio，audio再播放。他們是兩個進程，就不會再有進程堵塞了。這個結構頗像由神經連起來的大腦和嘴巴。反正XiaoHu的brain以后會放在全天候運轉的服務器上，是肯定要和控制教室電腦客戶端聲音的audio分開的。這樣就完美解決了問題。服務號開發基本完成了（只用了三天），我 把XiaoHu的聊天功能開放給了同學們，于是整個晚上它都在說話，不得不說它還是很幽默的。

12/19 今天獲得了學校服務器的權限，我試著把XiaoHu服務器程序在服務器上運行起來，費了好大力氣把依賴庫安裝好，結果發現程序老是卡住，不知道為什么。python自帶的ide實在麻煩。

12/23 完善了人臉識別功能，全面換裝了百度v3版api，v3版本沒有了m:n多人識別，枚舉所有用戶來進行1:n識別太慢，不可行。最后的方案是先 使用face_detect檢測出圖片里所有人臉，分別框出輸出成臨時文件，然后對于只有一張人臉的文件，識別與之對應的用戶。百度給出的人臉 框太小了，導致識別身份時有時候會識別不出來，我強行增加了人臉框的大小，準確度就提高了。人臉模塊基本實現了，下一步就是等物聯 網部署后與攝像機的連接。

12/24 今天繼續調試服務器，先是在服務器系統上安裝了pycharm，用了這個ide后發現服務程序竟然可以運行了，十分神奇。于是用ngrok搞了個 內網穿透，綁定了微信服務號的服務器地址，XiaoHu就運行起來了。

“只要北大附的官網還能訪問，小虎就永遠存在。”

?

---------------------------------2 0 1 9----------------------------------------

2/1 之前想接入物聯網時出了離奇的bug，使得我的程序始終不能和網關建立連接，后來改了一下config，成功把網關又接入了XiaoHu，物聯網部 分沒有什么技術問題了。

2/5 修復了之前一直很苦惱的socket通信問題，原來是服務器的問題，服務器的腳本里應該填自身ip而不是127.0.0.1，怪不得本機調試沒有問題，一用遠程服務器就不行了，現在通信的bug也解決了。

2/6 今天，是XiaoHu一周年，但是要鴿了。

2/7~3-26 假期里訂購的攝像頭到貨，調試過程卻不是很順利，照著網上的hack教程做但是沒有起色，問了老師，也同樣無果。開學以來就一直在搞 服務器端和客戶端的連接問題，從學校服務器搞內網穿透，但是只能穿透一個端口，我需要80和3000。后來換了一個外網服務器，但是延遲太 高。在何天陽的幫助下借用了他的服務器，一度好使，不過由于他的一次事故導致原先的服務器壞掉，換了新的，卻不好使了，微信服務器驗證 總是失敗，我一度懷疑werobot的token驗證問題，并想換成php進行驗證。卡了很久，小虎的服務處于半宕機狀態。

3/27 放學后，我回閱覽室去找耳機，恰好碰上何天陽，跟他說了這個問題，他說是不是防火墻問題，因為他之前也在這個服務器上有這種情況，在 防火墻上打開那個端口就好了，我回去打開了80，php腳本就可以運行了。后來我想會不會python的驗證也是這種問題，一試，果然如此。依 次把80和3000端口打開，小虎復活了。

4/4 小虎現在還存在一個問題，那就是會有“答非所問”的情況，有時會把上個問題的答案放到下個問題去回答，而上個問題就沒有了回應，這在同時收到多個問題的情況下更易出現，。我分析了一下，我認為這種問題是由于第一個問題的答案被“堵塞”到了下一個問題，“堵塞”的原因則 是因為我給它設置的嚴苛的超時限制，超時限制是0.05s，50ms，這個時限是我在試圖增加它效率時給添加的，這對于它尚不穩定的服務來說未 免太短了。我把時限增加到了0.5s，同時為了使它能夠應付“連串問題”的情況，而不是收到多個問題后，哪個答案先返回就先說哪個，我在它 的數據包里增加了一個token，token基于當前時間，進行md5加密，可以保證沒有重復。這樣第一個問題在接收到正確token后才會回復答案。 這保證了回復的順序。

4/7 小虎在上個周末的服務很不穩定，重新調試了服務器，同步了兩端的文件，在pyclient上增加了斷線自動重連的設定。增加聊天記錄儲存，增加 以userid+timestamp的md5加密。

4/9 得到了希悅的clientid和clientsecret，這樣就可以用他的rest api,用request庫來發送get和post，post獲取authkey很成功，但是用get獲取課表信息就遇到了問題，他給的api地址里的末尾有一個/:id，我不知道這是干什么，原樣放了進去就404，上網查了好久，沒有結果，因為搜索引擎總是把我的/:這倆符號吃掉，最后受到一篇博客的啟發，用id變量直接代替/:id，成功收到了返回，也是漲知識了，因為之前壓根沒有用過get這種，但這次是沒有權限。

4/10 與希悅的工程師建立了微信溝通，他為我開放了權限，我也在他的指導下成功取得了返回，在通過學號查找獲取數據庫id的過程中，我發現即使 把學號作為參數傳了上去，結果依舊是沒有經過篩選的，后來得知要把id傳到網頁的后綴里，問題就解決了，結果只有查找到的一個學生。回家對 查課表的功能又做了一些拓展。

4/11 修復了小虎因聊天記錄讀寫錯誤而造成服務停機的bug。

總結

以上是生活随笔為你收集整理的XiaoHu.ai开发日志（自2018年2月6日至2019年4月11日）的全部內容，希望文章能夠幫你解決所遇到的問題。

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