作者 | 路遙、迪迪

審校 | 千山

今年6月份，在經過近1年的測試以后，微軟GitHub AI編程工具Copilot以每月10美元的價格正式上線。

Copilot可以根據上下文自動寫代碼，包括注釋、函數、代碼等等，只要你給出提示，就可以寫出完整的函數。

在很多場景當中，打上注釋，函數就出來了，即便是在一些“稀巴爛”的函數當中，它也能知道你要干啥。

此外，Copilot甚至可以提供關于完整的方法和復雜的算法等建議，以及模板代碼和單元測試的協助，這樣一來開發效率和工作的幸福感都可以得到很大程度的提高。

但顯然，微軟的開發團隊想讓它變得更智能一些。

在近日召開的GitHub Universe 2022活動上，GitHub正在為其Copilot軟件測試一種新的基于語音的交互系統——“嘿，GitHub！”，將允許程序員只用聲音而不用鍵盤來寫代碼，就像對Siri說話一樣。

GitHub在一篇博文中解釋說：“借助你的聲音的力量，我們很高興有可能把GitHub Copilot的好處帶給更多的開發者，包括那些用手打字有困難的開發者。'嘿，GitHub！' 只是減少了在VS Code內編碼時對鍵盤的需求，但我們希望通過進一步的研究和測試擴展其功能。”

借助該功能，程序員能夠命令Copilot移動到不同的代碼行，或者只用聲音導航到方法或塊。甚至可以控制Visual Studio Code，使用“運行程序”或“切換禪定模式”等命令。如果想了解某塊代碼的作用，甚至可以要求進行代碼總結。

自動編程+語音輸入，兩者的結合可能會讓很多入門級別的程序員更容易上手。

不過問題也隨之而來。

針對這一功能的公布，程序員對此的看法褒貶不一：

有人吐槽：這肯定是某個不懂GitHub也不了解程序員工作流程的高管或投資者想當然的決定。

也有人表示：這種工具實際提升了可訪問性，一定會有開發人員從中受益。

還有人提出了細節疑問：很難想象語音識別軟件對于變量名的識別可以非常精確。

除此之外，還有很多現實問題需要考慮。

首先就是識別問題，先不說口音的問題，就是同音詞、語速、環境音等等，這些都容易造成識別不準的現象，也增加了開發者后期修改的時間成本。

其次，定位比較麻煩。官方的解釋“程序員能夠命令 Copilot 移動到不同的代碼行”，加入在幾百行的幾幾幾，這樣的操作明顯不如鼠標鍵盤操作起來方便。

最后就是語音也未必有鍵盤輸入快、準，想一想下面的場景：

Hello World!

空格!

左花括號!

右括號！

system！

…

而且目前大多數人都是用IDE編程，很多代碼都是用快捷鍵、自動填充來完成。在這方面，語音編程或許真的不如敲鍵盤來的更快捷。

但在程序員當中，有這樣一群特殊的群體更依賴語音編程—盲人程序員。

一直以來，盲人程序員依靠屏幕閱讀器、盲文顯示器等幫助編寫代碼，因為看不見的緣故，很多的代碼都要靠背誦來識記，每寫百行代碼，可能需要背上萬個字符。

所以語音編程的出現，不僅可以降低軟件開發的準入門檻，也可以讓這些特殊群體受益。

目前語音編程還處于起步階段，雖說還不完美，但它已經達到了可作為編程選項的地步。

究竟何時能夠被廣泛采用還是未知，不過可知的是，語音編程給我們的未來帶來了更多的可能性，就像GitHub所說的那樣：“正如編程語言和開源徹底改變了行業一樣，人工智能正在改變軟件開發的未來”。

當然不容忽視的是，GitHub Copilot的出現固然是自動化工具的里程碑，但是此前因其采用的代碼引發的版權爭議依舊懸而未決。在GitHub繼續用新功能加強其服務的同時，這一問題也亟待解決。

程序員Matthew Butterick提出“我的代碼沒經授權出現在了Copilot自動填充的代碼行中”。在他發起的集體訴訟中，指出微軟、GitHub和OpenAI從網絡上抓取受版權保護的材料來訓練Copilot，而Copilot在復制代碼時沒有適當的署名。最終這起訴訟的結果不僅可能影響Copilot的合法性，還可能影響整個生成型AI模型的合法性。

參考鏈接：https://www.theverge.com/2022/11/9/23449175/hey-github-voice-copilot-code-programming-system