TL; DR: 做了個在兩個群中央相互轉發新聞的機械人 (github)，對聊天機械人的一些思慮，可以把文本懂得加出去做成心思的運用。 比來看到了一些基于微信機械人的成心思的運用，好比用微信報告請示模子的練習狀況（TensorFlow，Keras）。這個是個很好的動身點。聊天機械人 (chatbot) 這個概念在 slack, telegram, skype 乃至最早的 谷歌 wave 下面風行曾經有一段時光了。年夜家重要用它來： 停止一些推送辦事 。一個例子就是下面的模子練習。還有連續集成（continuous integration）上也有一些 bot 可讓你曉得軟件編譯，測試和安排的狀況。 供給簡略的信息辦事，好比可以查氣象，查 github issue 的 bot。 供給一些基于指令的辦事。好比扎克伯格做的 bot，輸出開門的指令可以把門翻開。 用必定水平的天然說話懂得來陪聊. 但我認為這些并沒有表現聊天機械人的焦點優勢。細心看這四個方面的運用，它們其實都可以欠亨過聊天來完成，乃至欠亨過聊天能夠會更便利。好比推送辦事有體系信息推送（pushbullet, IFTTT notification等）， 查氣象體系就有app，智能家居我更愿望點點按鈕而不是打字，陪聊這個必需要聊天沒方法。年夜家情愿把它做到聊天法式外面去，重要是由于用戶其實是太話嘮了，許多時光都花在聊天法式外面，如許做成bot等于多了一個進口，何樂而不為？但如許做其實不代表這個進口是最優的或許無可代替的。 那聊天機械人合適甚么場景呢？要思慮這個成績必需起首要明白聊天機械人和其他平臺的差別在甚么處所。除 UX 層面必需基于文字，用戶常常在用之外，還有一個焦點差別是這個機械人實際上是可以拿到聊天記載的（固然還取決于隱私設置 ）。在這個條件下可以做許多許多成心思的運用。一個例子是我們有個科年夜校友 AI 群，外面年夜多半情形都是在賣力評論辯論AI相干的話題。但微信群是為了聊天設計的，評論辯論上究竟不比基于主題的 BBS，沒有主題，沒有答復，沒有話題（hashtag），全部信息流異?；靵y。但人類懶的本性又決議了，這類評論辯論更多的是在微信（或許其他即時通訊軟件）上完成的，不太能夠把它搬到 BBS 上去——每次填個主題，點個答復太費事了。有無能夠用微信機械人，一方面又堅持這類基于聊天軟件的便捷的特征，一方面又能整頓全部信息流，讓信息變得有組織？好比一小我一天沒看群了，早晨跑來看看機械人整頓的總結，就了如指掌。今后搜刮也便利。這是個很成心思的成績。 “讓信息有組織”照樣太籠統了。詳細地說，可以從以下幾個方面停止： 跨群轉發。這是個異常適用的功效。對群來講，由于微信一個群最多 500 人， 跨群轉發可以有用地把兩個群拼到一路，完成更普遍的評論辯論。對小我來講，也能夠用有選擇的轉發來把信息歸檔。好比看老板或許妹子在你加的幾個群里天天都說了啥等等。 聊天新聞的主題合并，剖析和搜刮。微信聊天的根本單元是新聞，但新聞自己長短常碎片化的，很不合適搜刮和剖析。機械人可以把相干主題的新聞合并起來，一方面可以年夜幅減小信息過載，一方面也能夠從中獲得更有價值的信息（相似視頻剖析外面把幀釀成鏡頭）。如許剖析今后可以做常識歸檔，用OneNote/印象筆記乃至"號把評論辯論的結果沉淀上去。 聊天頭緒的梳理。群里的人一多，常常會涌現幾個話題并行涌現的情形。這類情形關于懂得和搜刮都長短?；逇獾?。機械人也須要把聊天的頭緒停止梳理，在統一時光，把分歧主題分離開。 根本的統計數據。好比談話時光的散布，群的活潑度，成員的活潑度等等。做成英俊的可視化，用戶應當也會愛好，給產物加分。 在可行性方面這個也是能夠的。好比有基于 python 的 itchat 和基于 typescript 的 wechaty。但穩固性能夠是個成績，由于它們都不是微信官方支撐的 SDK，而是從 Web 微信的接口中抓包獲得的 API?；?itchat，我做了一個在兩個群之間無腦轉發新聞的機械人 (github)，應當蠻有效的，愿望能拋磚引玉。 在后面的知乎中的近義詞系列里（一，二，三，四），我們引見了一些基于文本懂得的小運用，好比主動鑒別近義詞，文章的分類，索引和搜刮。那末這個微信機械人系列，就會測驗考試把這些技巧用到聊天群外面去，看能不克不及做出一個真正有效的智能機械人。
