AI編程助手那些事兒
最近跟身邊的程序員老桿子討論需求時，驚奇的發現，他居然沒使用AI編程助手。一時間有2個想法從大腦閃過，然后心里還帶了一絲輕蔑：
- AI編程助手這么好的東西，你居然不用。
- 作為老程序員，你居然不跟上時代步伐，在想啥呢。
不過確實有一些老桿子是用過AI編程助手，又選擇了放棄，具體啥原因，我們來聊聊。首先說說市面上常用的幾款AI編程助手。
一、幾款AI編程助手
1.GitHub Copilot
GitHub Copilot是由GitHub和OpenAI聯合推出的AI編程助手，是我最早使用的一款編程助手。剛推出時我立馬嘗鮮，真香！當時立馬感覺解放了許多生產力。對于中文的理解以及生成的代碼質量我還是滿意的。
但是，因為價格的原因（一年需要1000多元），我一直使用的學生版和代理版。但是半年前發現GitHub對于代理版和學生版查的比較嚴，Copilot經常掉線，在加上服務器本來就在國外，有時候生成代碼的響應速度確實有些慢，漸漸地放棄了。
2.文心快碼
文心快碼（Comate），是百度推出的AI編程助手。放棄了GitHub Copilot之后，在國內尋找，當時發現可用的基本就是文心快碼了。試用了一段時間后，覺得生成代碼的速度還行，但是代碼的準確率或者被采用率，有點堪憂。
不過當時想著免費嘛，就隨便用用吧，不合適的代碼一個ESC鍵也就過了，合適的代碼一個TAB鍵就采納了，多少也能節省些工作量吧。
畢竟當時我 對于 不熟悉的領域 或者 大片段的代碼，都是讓ChatGPT生成的，我使用文心快碼的主要場景是輔助生成一些簡單或重復的代碼。
3.通義靈碼
通義靈碼是阿里巴巴推出的AI編程助手，基于強大的Qianwen2大模型。通義靈碼是我最近正在使用的AI編程助手。
一次偶然的機會，我被邀參加阿里的一個AI沙龍會，當時有一個小專題是講通義靈碼的。本來用文心快碼時覺得效果一般，心里想著，通義靈碼估計也就那樣吧。
后來看那位宣講通義靈碼的哥們，激情滿滿，特別自豪，好像這款產品是他造出來的。這倒引起了我的好奇心。當時，他自豪地說他們的大模型怎么好怎么牛，通義靈碼做了多少多少的微調，做了多少多少的優化，他們對安全是怎么怎么重視。
雖說，他的話我不全信，但真的是被他當時的激情所感染（也許是出于一個產品人的同理心吧）。
當晚，我就試用了通義靈碼。安不安全的我不知道，但是，生成代碼的速度挺快。隨后，我又寫了1個小時的代碼測試，發現生成的代碼正確率和被采用率還不錯，后來就一直在用了。
通過這次選擇，更加說明一個道理自助者天助之。一個產品人一定要對自己的產品充滿自行。即使是一名程序員，在AI時代，也要將自己看做一個產品人。
4.ChatGPT
ChatGPT真的是永遠的No1。要說生成代碼的準確率和自然語言的理解力，即使是中文場景，ChatGPT也是最好的。
下面是一個ChatGPT與通義靈碼針對同一需求實現代碼的小示例，朋友們可以自行感受下。
需求：
我有一個Html文件，想批量替換里面的font-size的數值，放大兩倍。還要替換line-height的數值，也是放大兩倍。請你用java寫出代碼
ChatGPT實現：
import java.io.*;
import java.nio.file.*;
import java.util.regex.*;
public class HtmlFontSizeLineHeightMultiplier {
public static void main(String[] args) {
String filePath = "htmlFile.html";
try {
String content = new String(Files.readAllBytes(Paths.get(filePath)));
String updatedContent = updateFontSizeAndLineHeight(content);
Files.write(Paths.get("updatedHtmlFile.html"), updatedContent.getBytes());
System.out.println("File updated successfully.");
} catch (IOException e) {
e.printStackTrace();
}
}
private static String updateFontSizeAndLineHeight(String content) {
// Pattern to match font-size and line-height in CSS
Pattern fontSizePattern = Pattern.compile("font-size\\s*:\\s*(\\d+(\\.\\d+)?)(px|em|rem|%)", Pattern.CASE_INSENSITIVE);
Pattern lineHeightPattern = Pattern.compile("line-height\\s*:\\s*(\\d+(\\.\\d+)?)(px|em|rem|%)", Pattern.CASE_INSENSITIVE);
// Replace font-size values
Matcher fontSizeMatcher = fontSizePattern.matcher(content);
StringBuffer updatedContent = new StringBuffer();
while (fontSizeMatcher.find()) {
String originalValue = fontSizeMatcher.group(1);
String unit = fontSizeMatcher.group(3);
double newValue = Double.parseDouble(originalValue) * 2;
fontSizeMatcher.appendReplacement(updatedContent, "font-size: " + newValue + unit);
}
fontSizeMatcher.appendTail(updatedContent);
// Replace line-height values
Matcher lineHeightMatcher = lineHeightPattern.matcher(updatedContent.toString());
updatedContent = new StringBuffer();
while (lineHeightMatcher.find()) {
String originalValue = lineHeightMatcher.group(1);
String unit = lineHeightMatcher.group(3);
double newValue = Double.parseDouble(originalValue) * 2;
lineHeightMatcher.appendReplacement(updatedContent, "line-height: " + newValue + unit);
}
lineHeightMatcher.appendTail(updatedContent);
return updatedContent.toString();
}
}通義靈碼實現：
import java.io.*;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class HtmlFontSizeModifier {
public static void main(String[] args) {
String inputFilePath = "path/to/input.html"; // 輸入文件路徑
String outputFilePath = "path/to/output.html"; // 輸出文件路徑
try {
modifyFontSizesAndLineHeights(inputFilePath, outputFilePath);
} catch (IOException e) {
System.err.println("Error processing file: " + e.getMessage());
}
}
/**
* 修改HTML文件中的font-size和line-height值為原來的兩倍。
*
* @param inputPath 輸入文件路徑
* @param outputPath 輸出文件路徑
* @throws IOException 如果文件處理過程中出現錯誤
*/
public static void modifyFontSizesAndLineHeights(String inputPath, String outputPath) throws IOException {
try (BufferedReader reader = new BufferedReader(new FileReader(inputPath));
BufferedWriter writer = new BufferedWriter(new FileWriter(outputPath))) {
String line;
Pattern fontSizePattern = Pattern.compile("(font-size:\\s*([0-9]+)(px|em|rem))");
Pattern lineHeightPattern = Pattern.compile("(line-height:\\s*([0-9]+)(px|em|rem))");
while ((line = reader.readLine()) != null) {
Matcher fontSizeMatcher = fontSizePattern.matcher(line);
Matcher lineHeightMatcher = lineHeightPattern.matcher(line);
if (fontSizeMatcher.find()) {
String fontSize = fontSizeMatcher.group(2);
String unit = fontSizeMatcher.group(3);
double newSize = Double.parseDouble(fontSize) * 2;
line = line.replaceFirst(fontSizeMatcher.group(), "font-size: " + newSize + unit);
}
if (lineHeightMatcher.find()) {
String lineHeight = lineHeightMatcher.group(2);
String unit = lineHeightMatcher.group(3);
double newLineHeight = Double.parseDouble(lineHeight) * 2;
line = line.replaceFirst(lineHeightMatcher.group(), "line-height: " + newLineHeight + unit);
}
writer.write(line);
writer.newLine();
}
}
}
}可以看到，在對于需求的理解上ChatGPT更好，在實現正則匹配的邏輯方面ChatGPT也更完善。
5.我推薦的用法
對于AI編程助手的選擇，我的建議是雙管齊下：ChatGPT + 國內某個大廠的AI編程助手。
核心原因有3個：
- ChatGPT的自然語言理解能力是最強的，生成代碼的準確率也是最強的，可以用來生成小塊需求代碼。
- 國內某個大廠的AI編程助手雖說在 自然語言理解能力 和 代碼的準確率 方面可能弱一些，但是用來生成簡單重復代碼 和 完成簡單需求 這些方面是OK的。而且國內的編程助手，生成代碼的速度都比較快。
- 國內大模型的發展速度我們親眼所見，雖說跟國外的大模型還有些差距，但也在不停的追趕。我們要對國內大模型的發展有信心。
二、AI編程助手的工作原理
AI編程助手的背后是大語言模型和強大的算力。在大模型的基礎上，進行了編程領域的代碼和文檔的微調訓練，使其更加使用編程場景。
具體在編程時，AI助手會根據你的代碼注釋、函數名、代碼文件等上下文信息，結合之前已經喂給它的開源代碼庫，生成與當前需求有相關性的代碼片段。
三、AI編程助手的優缺點
目前，仍有許多開發者由于種種原因對AI編程助手持排斥態度，我們確實也要承認AI編程助手有缺點，但是也有許多優點。
優點：
- 提升效率節省時間：AI編程助手可以快速生成代碼，減少手動編寫的工作量。尤其是在重復性高 和 常規邏輯的編程任務中，它能夠顯著提升效率，讓開發者有更多時間專注于核心邏輯和創新。
- 代碼質量的提升：有時候能感覺到，AI生成代碼質量比我自己寫的好。
- 加速獲取知識：通過AI編程助手，開發者可以快速獲取各種編程知識和技術方案，明顯縮短學習曲線。在寫代碼時，它也能夠提供即時的建議，避免開發者長時間的搜索和查閱資料。這一點，我感受非常深刻，記得兩年前學Flink和Golang時，當時掃過文檔之后，對應如何實踐項目還是無從下手，幸好有AI編程助手，讓我快速學會了未知領域的知識，并且能快速做出項目。
- 向AI學習：開發者在與AI的交互過程中，也會不斷地接觸到新的代碼模式和最佳實踐，從而提升自己的編程能力和技術水平。
缺點：
對復雜邏輯的處理能力有限：雖然編程助手在處理簡單和常見的代碼片段上的表現挺好，但是對于復雜邏輯的處理能力較弱。在涉及到復雜算法或者業務邏輯的情況下，基本上給不出合適的代碼。所以，大部分時候，AI編程助手生成的代碼仍然需要自己過一遍。
- 存在安全隱患：在使用AI編程助手時，需要將代碼丟給AI編程助手，然后它去猜測相關代碼。至于它拿到代碼，會不會做點什么，我們無從得知。
- 容易存在依賴性：對于長期使用AI編程助手的開發者，很容易形成依賴性。大部分場景會養成等待AI生成的習慣，一旦離開了AI編程助手，確實有些不習慣。不過這一點算是仁者見仁智者見智吧，AI的發展是大勢，就像當年的互聯網一樣，所有的不習慣未來都會變得像空氣一樣無處不在。
- 容易養成不思考的習慣：長期使用AI編程助手的開發者，除了思考業務邏輯之外，大部分的代碼實現都懶得自己思考了。為了避免自己變得懶惰，每次AI助手生成代碼之后，我都會翻閱一遍，再與自己的思路做個對比。不過這也不一定算缺點吧，AI的出現不就是為了解放我們的思想和生產力嘛，不就是為了讓我們從一個簡單的執行者，變成一個操盤者嘛。
四、為什么有的開發者不使用AI編程助手
之前看過一個數據，中國約有1000萬程序員，預計有200多萬在使用AI編程助手，而且數字一直在飆升。我也從一些渠道了解到有些開發者不愿意使用AI編程助手，原因如下：
- 自動提示的災難：在使用AI編程助手時，幾乎每次敲擊都會生成提示代碼，這讓許多開發者覺得AI會打斷自己的思路，或者有時強迫癥，非要去看一眼AI提示代碼是否正確。這個痛點各大廠商都在極力解決，最近我已經明顯感覺到觸發提示的地方變少了，相信會越來越智能的。
- 安全隱患：部分個人和企業比較擔心使用AI助手會泄露自己的核心代碼，所以一直不敢用。雖然各大廠商都在極力宣傳自己的安全策略，極力強調自己不會存儲和使用代碼，但是好像沒人信。
- 不愿意跟進時代：有些開發者確實比較保守，故步自封，不愿意嘗試新事物。我倒是覺得，不管一個新事物好壞，起碼先嘗試下。
- 低估AI的能力：有些開發者覺得AI的能力不行，寫的代碼不好。我倒是覺得AI的能力一直在增強，而且某些方面比人強多了，沒必要那么自信，多嘗試幾次，你會發現AI在寫重復代碼和簡單邏輯方面還是很強的。把雜事兒丟給AI，自己多留點精力想想復雜業務問題，不是更香嘛。
對于部分開發者和企業擔心的安全問題，我有幾點想說：
- 大廠沒必要拿你的代碼做二次訓練，因為大廠如果想AI助手變得更好，他需要更多優質的代碼。你的代碼質量未必有多好，他只會拿優質的開源代碼做訓練。
- 如果你的主營業務是賣代碼，估計你會擔心自己的核心資產泄露。大可不必擔心。因為AI只會小片段的生成代碼，AI無法生成一個項目的完整代碼。
- 如果你擔心大廠拿你的代碼去做業務，那也不可能。以大廠的能力，要想做某塊業務，肯定會與自己的也有業務相結合，不可能直接用你的代碼。而且，要是真想做某塊業務，最好的辦法是收購你，不會拿你的代碼去用。講實在話，代碼有時候是負債，真正值錢的是你的業務。
五、未來的超級個體時代
AI的定位一直都是助手，而且AI會越來越強大。AI未來一定會淘汰碼農，但是AI一定會與優秀的開發者共生。開發者應該抓住這個時代的機會，努力讓自己成為一個超級個體。
在未來的超級個體時代，知識的掌握已經不再是唯一的重要因素。隨著AI技術的發展，更多的創意、資源整合能力和產品能力將成為核心競爭力。
AI編程助手能夠處理大量的重復性工作，釋放開發者的創造力。開發者可以將更多的時間和精力投入到創新和創意上，開發出更好的產品。
經過了這一輪的經濟的洗禮，有點企業倒閉了，有的企業活下來了。即使是活下來的企業，相信也學會了更靈活的用工方式。未來，有了AI的加持，個體的能力一定會被放大。屆時，企業一定更傾向于找獨立的個體合作。
六、總結
本篇主要聊了幾款AI編程助手、它的工作原理、它的優缺點、超級個體等等。我鼓勵開發者積極擁抱AI，讓自己成為一個全棧開發者和超級個體，讓AI幫助自己釋放更多的生產力和創意，讓自己充滿無限可能。
