踐)
這兩年“AI Coding”幾乎是從工具圈一路火到了管理層。打開技術(shù)社區(qū)滿屏都是“AI 輔助編程”“AI Agent 寫代碼”的話題打開招聘 JD不少崗位也把“熟悉 AI 編程工具”寫成了加分項(xiàng)。但真正在一線把 AI 用到生產(chǎn)項(xiàng)目里的團(tuán)隊(duì)往往一邊享受效率提升一邊又有一肚子苦水AI 生成的代碼花團(tuán)錦簇但跑不起來改一個(gè)字段引發(fā)三處連帶報(bào)錯(cuò)看似 80% 的代碼由 AI 完成剩下的 20% 卻要花掉 80% 的時(shí)間去修。這篇文章不打算去神化 AI Coding也不打算唱反調(diào)而是以工程落地的視角把 AI Coding 的核心概念、主流工具、工作流程、實(shí)戰(zhàn)案例、常見坑點(diǎn)、工程化建議一次性梳理清楚。既適合剛接觸 AI 編程的新手也適合已經(jīng)在團(tuán)隊(duì)里推行 AI Coding、卻總在“效率與失控”之間反復(fù)搖擺的開發(fā)者。1. 背景與核心概念A(yù)I Coding 到底是什么1.1 從“代碼補(bǔ)全”到“編程智能體”AI Coding字面意思是“用 AI 寫代碼”。但這個(gè)詞的內(nèi)涵在過去兩年里已經(jīng)發(fā)生了很大變化。早期大家熟悉的 AI 編程本質(zhì)上是“代碼補(bǔ)全增強(qiáng)版”你寫了一個(gè)函數(shù)名AI 幫你補(bǔ)出函數(shù)體你寫了一個(gè) SQL 的開頭AI 幫你猜 WHERE 條件。這種模式的核心是概率預(yù)測模型根據(jù)你當(dāng)前的代碼上下文推斷下一步最可能出現(xiàn)的 token。代表性工具有 GitHub Copilot、通義靈碼等。到了 2024 年下半年以后AI Coding 的概念明顯往“智能體Agent”方向演進(jìn)。工具不再只是做行級(jí)補(bǔ)全而是可以讀取整個(gè)項(xiàng)目的目錄結(jié)構(gòu)和關(guān)鍵文件理解用戶用自然語言描述的需求自主規(guī)劃要改哪些文件、調(diào)用哪些函數(shù)生成代碼、運(yùn)行測試、根據(jù)報(bào)錯(cuò)自動(dòng)修復(fù)甚至提交 Pull Request。這種模式下的 AI不再是你敲代碼時(shí)的“輸入法”而是“結(jié)對程序員”——雖然這個(gè)程序員偶爾會(huì)自信地寫出一個(gè)不存在的 API。1.2 AI Coding 解決的核心問題為什么 AI Coding 會(huì)這么快流行起來本質(zhì)上是它切中了軟件開發(fā)中幾個(gè)長期存在的痛點(diǎn)重復(fù)勞動(dòng)占比高CRUD 接口、DTO 轉(zhuǎn)換、單元測試模板、配置文件這類代碼模式固定、邏輯簡單但數(shù)量巨大?？缯Z言、跨框架切換成本高一個(gè)后端工程師臨時(shí)要寫一段 Python 腳本或者一個(gè)前端要理解一段 Java 老代碼AI 可以快速翻譯和解釋。從需求到代碼的翻譯損耗很多開發(fā)時(shí)間不是花在“怎么寫”而是花在“查文檔、試錯(cuò)、對齊接口”上。AI 可以把這一步壓縮到很短時(shí)間內(nèi)。入門門檻對于剛學(xué)編程的人來說AI 可以作為一個(gè) 7x24 小時(shí)在線的“答疑老師”把報(bào)錯(cuò)、語法、邏輯講得明明白白。1.3 常見應(yīng)用場景AI Coding 在現(xiàn)階段的典型應(yīng)用場景包括場景說明適合程度腳手架搭建生成項(xiàng)目結(jié)構(gòu)、初始化配置、創(chuàng)建基礎(chǔ)代碼高接口與模板代碼Controller、Service、Mapper、DTO 等重復(fù)性代碼高單元測試生成根據(jù)業(yè)務(wù)代碼生成測試用例和樁數(shù)據(jù)高代碼解釋與重構(gòu)閱讀陌生代碼、提取公共邏輯、調(diào)整結(jié)構(gòu)高Bug 定位與修復(fù)結(jié)合報(bào)錯(cuò)信息縮小排查范圍中腳本工具編寫寫數(shù)據(jù)處理、日志分析等一次性腳本高復(fù)雜業(yè)務(wù)系統(tǒng)開發(fā)涉及多個(gè)模塊、強(qiáng)耦合狀態(tài)、架構(gòu)設(shè)計(jì)的核心業(yè)務(wù)低可以看到AI Coding 擅長的是“范圍清晰、模式成熟、反饋及時(shí)”的任務(wù)。越是邊界模糊、需要大量業(yè)務(wù)判斷的任務(wù)AI 的可靠性越差——這一點(diǎn)在后面的“Discontents不滿”部分會(huì)詳細(xì)展開。2. 從 Vibe Coding 到 Spec CodingAI 編程的兩種姿勢如果你關(guān)注過 AI 編程相關(guān)的討論一定見過兩個(gè)高頻詞Vibe Coding和Spec Coding。這兩個(gè)概念代表了兩種截然不同的 AI 編程姿勢也直接決定了項(xiàng)目的走向。2.1 Vibe Coding順著感覺寫代碼“Vibe Coding”這個(gè)詞最早是由 AI 大神 Andrej Karpathy 在一次分享中提出的大意是你不再逐行敲代碼而是描述需求、把 AI 生成的代碼直接接受下來即使你不完全理解每一行在做什么。你跟著“感覺”走像是一個(gè)樂隊(duì)在跟著氛圍即興演奏。Vibe Coding 的優(yōu)點(diǎn)非常明顯原型速度快得驚人。一個(gè)簡單的網(wǎng)頁、一個(gè)數(shù)據(jù)腳本可能幾分鐘就能跑起來。非常適合個(gè)人開發(fā)者做 Demo、Hackathon 項(xiàng)目、一次性工具。降低了寫作代碼的心理門檻很多非專業(yè)開發(fā)者也能“做出東西”。但它的缺點(diǎn)同樣致命代碼質(zhì)量不可控。AI 生成的代碼常?！翱雌饋砗侠怼钡赡艽嬖谶壿嬄┒?、安全隱患、性能問題。沒有人真正理解系統(tǒng)的整體結(jié)構(gòu)。一旦項(xiàng)目變大任何人都無法維護(hù)。錯(cuò)誤會(huì)被不斷放大。AI 會(huì)在錯(cuò)誤的代碼基礎(chǔ)上一本正經(jīng)地繼續(xù)生成錯(cuò)誤修復(fù)。所以Vibe Coding 適合什么適合“跑通流程做驗(yàn)證”的場景。它解決的痛點(diǎn)是“從 0 到 1”不解決“從 1 到 100”。2.2 Spec Coding先寫規(guī)格再寫實(shí)現(xiàn)Spec Coding 是針對 Vibe Coding 的失控問題衍生出來的另一種實(shí)踐。所謂 Spec就是規(guī)格說明。在讓 AI 動(dòng)手寫代碼之前開發(fā)者先寫清楚這個(gè)模塊要解決什么問題輸入是什么、輸出是什么邊界條件有哪些依賴哪些外部服務(wù)性能要求是什么驗(yàn)收標(biāo)準(zhǔn)是什么。然后 AI 根據(jù)這份 Spec 去生成實(shí)現(xiàn)代碼。這樣做的好處是需求被顯式地表達(dá)出來AI 不再“猜”你的意圖代碼結(jié)構(gòu)更可控因?yàn)?Spec 本身就定義了邊界代碼審查有據(jù)可依Review 時(shí)對照 Spec 檢查實(shí)現(xiàn)是否偏離即使 AI 生成質(zhì)量不佳人也能通過 Spec 快速發(fā)現(xiàn)問題。拿我自己的經(jīng)驗(yàn)來說一個(gè)需求描述如果只有一句話AI 生成的代碼大概率只有一種“標(biāo)準(zhǔn)答案”而真實(shí)業(yè)務(wù)往往有十幾種隱藏約束。Spec 就是把隱藏約束顯式化的過程。2.3 兩種姿勢怎么選維度Vibe CodingSpec Coding適用階段原型驗(yàn)證、個(gè)人工具、Demo生產(chǎn)代碼、團(tuán)隊(duì)協(xié)作、核心業(yè)務(wù)需求表達(dá)口頭化、模糊結(jié)構(gòu)化、顯式代碼質(zhì)量不可控相對可控維護(hù)成本高低適合人群新手、設(shè)計(jì)師、產(chǎn)品經(jīng)理專業(yè)開發(fā)者、技術(shù)團(tuán)隊(duì)一個(gè)務(wù)實(shí)的策略是先用 Vibe Coding 快速驗(yàn)證方向再切換到 Spec Coding 讓代碼“配得上上線”。兩者不是對立關(guān)系而是項(xiàng)目不同階段的不同工具。3. AI Coding 主力工具與工作流程3.1 工具形態(tài)插件、IDE、云端平臺(tái)目前的 AI Coding 工具大致分三類編輯器插件型在 VSCode、JetBrains 等現(xiàn)有 IDE 中安裝插件如 GitHub Copilot、通義靈碼、Continue 等。這類工具上手成本低但能力上限受限于編輯器的上下文感知能力。AI 原生 IDE 型以 Cursor 為代表底層基于 VSCode 改造深度集成了 AI 對話、多文件編輯、全局代碼索引。Cursor 的特點(diǎn)是對整個(gè)項(xiàng)目的理解能力更強(qiáng)適合作為主力開發(fā)環(huán)境。云端開發(fā)與編程計(jì)劃型類似阿里云百煉的 Coding Plan、Qwen Code 等把 AI 編程能力和云端資源、模型 API 管理結(jié)合在一起。團(tuán)隊(duì)層面可以利用這類平臺(tái)統(tǒng)一管理模型配額、上下文策略和團(tuán)隊(duì)成員的使用權(quán)限。另外還有一個(gè)概念最近頻繁出現(xiàn)Credits積分/配額。在 AI 編程工具里Credits 通常指用戶可消耗的算力額度。每次調(diào)用大模型生成代碼、執(zhí)行一次深度分析都會(huì)消耗一定數(shù)量的 Credits。團(tuán)隊(duì)在使用云端 AI 編程平臺(tái)時(shí)需要關(guān)注 Credits 的分配和消耗策略避免某個(gè)成員一次性把團(tuán)隊(duì)額度全部用完。3.2 什么是 Coding Plan“Coding Plan”在不同語境下含義略有不同但核心指向是一致的一套結(jié)構(gòu)化的 AI 編碼方案不只是“給 AI 一個(gè) prompt”而是明確 AI 如何理解需求、如何拆解任務(wù)、如何驗(yàn)證產(chǎn)出。在阿里云百煉等平臺(tái)上Coding Plan 往往表現(xiàn)為選擇編程任務(wù)的類型如 Web 應(yīng)用開發(fā)、數(shù)據(jù)處理腳本、單元測試生成配置使用的基礎(chǔ)模型如 Qwen 系列設(shè)定 AI 的行為規(guī)則如是否允許修改現(xiàn)有文件、是否需要生成測試代碼生成一個(gè)任務(wù)執(zhí)行計(jì)劃交給人確認(rèn)后再開始編碼。在團(tuán)隊(duì)場景下Coding Plan 的意義還在于它把“團(tuán)隊(duì)成員如何使用 AI”這件事規(guī)范化了。不同人寫出來的 prompt 水平參差不齊導(dǎo)致 AI 產(chǎn)出質(zhì)量差異巨大。一個(gè)統(tǒng)一的 Plan 模板可以讓 AI 的輸出更穩(wěn)定也更容易審計(jì)。3.3 多 Agent 協(xié)同AI Coding 的下一個(gè)階段如果你關(guān)注 2026 年以后的 AI 編程動(dòng)態(tài)“多 Agent 協(xié)同”是個(gè)繞不開的關(guān)鍵詞。所謂多 Agent 協(xié)同簡單說就是不再由一個(gè) AI 從頭干到尾而是讓多個(gè)扮演不同角色的 AI Agent 分工合作需求分析 Agent負(fù)責(zé)把模糊描述拆成結(jié)構(gòu)化需求產(chǎn)出任務(wù)清單編碼 Agent根據(jù)任務(wù)清單生成或修改代碼測試 Agent為代碼生成測試用例并運(yùn)行反饋結(jié)果審查 Agent檢查代碼風(fēng)格、安全隱患、潛在性能問題文檔 Agent同步更新 README、接口文檔、變更記錄。多個(gè) Agent 之間通過共享的任務(wù)上下文協(xié)作類似一個(gè)微型虛擬研發(fā)團(tuán)隊(duì)。好處是每個(gè) Agent 的任務(wù)邊界清晰上下文不容易混亂產(chǎn)出并行效率更高質(zhì)量閘門分散問題更容易被發(fā)現(xiàn)。但多 Agent 協(xié)同也帶來了新的挑戰(zhàn)上下文如何同步一個(gè) Agent 修改了接口另一個(gè) Agent 還在按舊接口寫測試怎么協(xié)調(diào)這本質(zhì)上和人類團(tuán)隊(duì)協(xié)作遇到的問題是一樣的只是把“溝通成本”轉(zhuǎn)移成了“上下文管理成本”。如果你的團(tuán)隊(duì)正在嘗試多 Agent 協(xié)同建議從“兩個(gè) Agent 起步”一個(gè)負(fù)責(zé)寫代碼一個(gè)負(fù)責(zé)寫測試和做代碼審查。等流程跑順了再逐步增加角色。3.4 團(tuán)隊(duì) AI Coding 的協(xié)作方式個(gè)人用 AI 寫代碼和團(tuán)隊(duì)用 AI 寫代碼完全是兩件事。個(gè)人寫的代碼崩了影響范圍通?？煽貓F(tuán)隊(duì)里如果有人不加約束地用 AI 生成代碼項(xiàng)目很快就變成一座“補(bǔ)丁疊補(bǔ)丁”的屎山。團(tuán)隊(duì)協(xié)作的核心建議是統(tǒng)一工具鏈團(tuán)隊(duì)內(nèi)盡量使用相同的 AI 編碼工具和模型配置避免不同成員生成風(fēng)格迥異的代碼。沉淀 Prompt 模板把常用的需求描述、代碼審查、測試生成 prompt 固化下來形成團(tuán)隊(duì)資產(chǎn)。約定 AI 的使用邊界哪些模塊允許 AI 直接生成、哪些模塊必須人工編寫、哪些操作如數(shù)據(jù)庫遷移需要審批。建立審查機(jī)制AI 生成的代碼必須走代碼審查和人工代碼一視同仁。4. 完整實(shí)戰(zhàn)案例用 AI Coding 從零完成一個(gè)日志分析工具前面講了不少概念這一節(jié)我們來做一個(gè)完整的實(shí)戰(zhàn)。目標(biāo)是用 AI Coding 的方式從需求描述到可運(yùn)行代碼完成一個(gè) Python CLI 日志分析工具。我會(huì)模擬一下人工與 AI 的協(xié)作過程包括需求描述、AI 生成、人工審查和修復(fù)。4.1 需求描述假設(shè)業(yè)務(wù)方給了一個(gè)很樸素的需求有一個(gè)應(yīng)用日志文件 app.log里面每行類似2026-08-12 10:23:45 [ERROR] Failed to connect to database2026-08-12 10:24:01 [INFO] User login success我需要一個(gè)命令行工具統(tǒng)計(jì)各級(jí)別日志數(shù)量找出最近 10 條 ERROR 日志并能按時(shí)間段過濾。如果是 Vibe Coding 模式我們可以直接把這個(gè)需求丟給 AI讓它生成腳本。但為了體現(xiàn) Spec Coding 的思路我們先寫一個(gè)簡易 Spec# 日志分析工具 Spec 功能點(diǎn) 1. 輸入?yún)?shù)日志文件路徑必填、時(shí)間范圍可選、錯(cuò)誤數(shù) N可選默認(rèn) 10。 2. 統(tǒng)計(jì) INFO / WARN / ERROR / DEBUG 各級(jí)別出現(xiàn)次數(shù)。 3. 輸出最近 N 條 ERROR 日志的完整內(nèi)容。 4. 日志格式時(shí)間 級(jí)別 消息三級(jí)以上日志單獨(dú)統(tǒng)計(jì)。 5. 要求Python 3.8僅使用標(biāo)準(zhǔn)庫提供命令行入口。4.2 讓 AI 生成代碼把上面的 Spec 和樣例日志格式發(fā)給 AI它可能生成類似這樣的核心代碼。注意這是AI 生成版本的示意我們特意保留了幾個(gè)常見問題方便后面演示人工審查。#!/usr/bin/env python3 # 文件路徑log_analyzer.py import argparse import re from collections import Counter from datetime import datetime def parse_line(line): 解析單行日志返回 (時(shí)間字符串, 級(jí)別, 消息)。 pattern r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w)\] (.*) match re.match(pattern, line) if not match: return None timestamp_str, level, message match.groups() return timestamp_str, level, message def load_logs(path): logs [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue parsed parse_line(line) if parsed: logs.append(parsed) return logs def filter_by_time(logs, startNone, endNone): 按時(shí)間范圍過濾日志。start 和 end 格式為 YYYY-MM-DD HH:MM:SS。 if not start and not end: return logs filtered [] for ts, level, msg in logs: if start and ts start: continue if end and ts end: continue filtered.append((ts, level, msg)) return filtered def analyze(log_path, startNone, endNone, error_count10): logs load_logs(log_path) logs filter_by_time(logs, start, end) counter Counter(level for _, level, _ in logs) error_logs [(ts, msg) for ts, level, msg in logs if level ERROR] print( 日志級(jí)別統(tǒng)計(jì) ) for level in [DEBUG, INFO, WARN, ERROR]: print(f{level}: {counter.get(level, 0)}) print(f\n 最近 {error_count} 條 ERROR 日志 ) for ts, msg in error_logs[-error_count:]: print(f{ts} {msg}) def main(): parser argparse.ArgumentParser(description日志分析工具) parser.add_argument(log_path, help日志文件路徑) parser.add_argument(--start, help開始時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(--end, help結(jié)束時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(-n, --error-count, typeint, default10, help顯示最近 N 條 ERROR 日志) args parser.parse_args() analyze(args.log_path, args.start, args.end, args.error_count) if __name__ __main__: main()運(yùn)行方式python3 log_analyzer.py app.log python3 log_analyzer.py app.log --start 2026-08-12 10:00:00 --end 2026-08-12 12:00:00 -n 54.3 人工審查發(fā)現(xiàn)的問題這個(gè)腳本看起來能跑但“能跑”和“能上線”之間隔著幾個(gè)問題。我把這些問題列出來大家可以對照一下自己的使用習(xí)慣——AI 生成代碼后多少人會(huì)做這一步審查問題 1時(shí)間比較方式錯(cuò)誤。代碼里start and ts start是字符串比較。當(dāng)時(shí)間字符串格式完全一致時(shí)YYYY-MM-DD HH:MM:SS字典序比較恰好等于時(shí)間比較這暫時(shí)沒問題。但一旦輸入的時(shí)間格式稍有不同例如2026-8-1而不是2026-08-01比較就會(huì)出錯(cuò)。規(guī)范化輸入或顯式解析時(shí)間才是正解。問題 2沒有處理文件不存在、空文件等邊界情況。真實(shí)業(yè)務(wù)中日志文件可能不存在、可能被占用、可能是空文件。腳本會(huì)直接拋出FileNotFoundError對用戶不友好。問題 3沒有處理無效日志行。parse_line返回 None 時(shí)load_logs直接丟棄用戶不知道有日志行沒有被解析。這在排查“統(tǒng)計(jì)數(shù)字對不上”時(shí)會(huì)很頭疼。問題 4盲目相信 AI 的“標(biāo)準(zhǔn)答案”。大家注意腳本里的分析邏輯是 AI 根據(jù)我給的樣例格式寫的。如果生產(chǎn)環(huán)境的日志格式有變化——比如時(shí)間格式、日志級(jí)別大小寫、多行堆棧——這個(gè)腳本會(huì)靜默地產(chǎn)生錯(cuò)誤統(tǒng)計(jì)結(jié)果。4.4 人工加固后的版本針對上面這些問題我做了部分加固核心片段如下#!/usr/bin/env python3 # 文件路徑log_analyzer_fixed.py import argparse import re import sys from collections import Counter from datetime import datetime from pathlib import Path LOG_PATTERN re.compile( r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w)\] (.*) ) VALID_LEVELS {DEBUG, INFO, WARN, ERROR} def parse_line(line): match LOG_PATTERN.match(line.strip()) if not match: return None timestamp_str, level, message match.groups() if level not in VALID_LEVELS: return None return timestamp_str, level, message def parse_time(value): try: return datetime.strptime(value, %Y-%m-%d %H:%M:%S) except ValueError: raise argparse.ArgumentTypeError( f時(shí)間格式應(yīng)為 YYYY-MM-DD HH:MM:SS收到{value} ) def load_logs(path): log_file Path(path) if not log_file.exists(): sys.exit(f錯(cuò)誤文件不存在 - {path}) if not log_file.is_file(): sys.exit(f錯(cuò)誤路徑不是文件 - {path}) logs [] skipped 0 with log_file.open(r, encodingutf-8) as f: for line in f: if not line.strip(): continue parsed parse_line(line) if parsed: logs.append(parsed) else: skipped 1 if skipped: print(f警告{skipped} 行日志無法解析已跳過。, filesys.stderr) return logs def filter_by_time(logs, startNone, endNone): if not start and not end: return logs start_dt datetime.strptime(start, %Y-%m-%d %H:%M:%S) if start else None end_dt datetime.strptime(end, %Y-%m-%d %H:%M:%S) if end else None filtered [] for ts, level, msg in logs: ts_dt datetime.strptime(ts, %Y-%m-%d %H:%M:%S) if start_dt and ts_dt start_dt: continue if end_dt and ts_dt end_dt: continue filtered.append((ts, level, msg)) return filtered def analyze(log_path, startNone, endNone, error_count10): logs load_logs(log_path) logs filter_by_time(logs, start, end) if not logs: print(沒有符合條件的日志記錄。) return counter Counter(level for _, level, _ in logs) error_logs [(ts, msg) for ts, level, msg in logs if level ERROR] print( 日志級(jí)別統(tǒng)計(jì) ) for level in [DEBUG, INFO, WARN, ERROR]: print(f{level}: {counter.get(level, 0)}) print(f\n 最近 {error_count} 條 ERROR 日志 ) for ts, msg in error_logs[-error_count:]: print(f{ts} {msg}) def main(): parser argparse.ArgumentParser(description日志分析工具) parser.add_argument(log_path, help日志文件路徑) parser.add_argument(--start, typeparse_time, help開始時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(--end, typeparse_time, help結(jié)束時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(-n, --error-count, typeint, default10, help顯示最近 N 條 ERROR 日志) args parser.parse_args() analyze(args.log_path, args.start, args.end, args.error_count) if __name__ __main__: main()一個(gè)簡單的案例從“AI 能跑”到“人工可維護(hù)”中間差的就是這份審查和加固。這也是整篇文章想表達(dá)的重點(diǎn)AI Coding 的下限由模型決定上限由人決定。5. AI Coding 的“不滿”與高頻踩坑清單標(biāo)題里的 Discontents 在這里集中體現(xiàn)。我整理了一些團(tuán)隊(duì)和個(gè)人在使用 AI Coding 時(shí)最常見的問題每個(gè)問題都附上了排查思路和解決方向。問題現(xiàn)象常見原因解決思路AI 生成代碼使用了不存在的 API 或庫模型幻覺訓(xùn)練數(shù)據(jù)中沒有該 API 的準(zhǔn)確信息審查依賴版本運(yùn)行時(shí)報(bào)錯(cuò)后把完整堆棧反饋給 AI使用官方文檔中的示例作為上下文修改一個(gè)功能后其他地方接連報(bào)錯(cuò)AI 只看到了局部上下文沒有理解全局依賴建立項(xiàng)目索引使用支持多文件上下文管理的工具顯式要求 AI 先搜索引用關(guān)系再改代碼AI 生成了“看起來正確”但邏輯錯(cuò)誤的結(jié)果需求本身模糊AI 選擇了最簡單的理解寫 Spec用測試用例約束行為人工補(bǔ)充邊界條件代碼風(fēng)格與團(tuán)隊(duì)規(guī)范不一致沒有給 AI 提供團(tuán)隊(duì)編碼規(guī)范把團(tuán)隊(duì)規(guī)范文件如 style guide加入上下文利用工具的項(xiàng)目級(jí)規(guī)則配置AI 過度設(shè)計(jì)或過于簡略prompt 缺少約束條件在 prompt 中明確“最小實(shí)現(xiàn)”、“不要引入額外依賴”、“遵循現(xiàn)有代碼風(fēng)格”團(tuán)隊(duì)多人使用 AI 后代碼風(fēng)格千奇百怪缺少統(tǒng)一工具鏈和規(guī)范統(tǒng)一 AI 工具和模型建立 prompt 模板在 CI 中增加自動(dòng)化風(fēng)格檢查Credits/額度消耗過快高頻調(diào)用大模型做簡單任務(wù)區(qū)分“簡單補(bǔ)全”和“深度生成”為不同任務(wù)選擇不同模型設(shè)置單次任務(wù)配額敏感信息進(jìn)入公共模型服務(wù)開發(fā)者把密鑰、生產(chǎn)數(shù)據(jù)粘貼到 AI 對話中建立數(shù)據(jù)安全規(guī)范部署私有化模型使用云平臺(tái)的企業(yè)級(jí)隔離區(qū)域5.1 模型幻覺AI 最穩(wěn)定的“不滿來源”模型幻覺是 AI Coding 里最讓人頭疼的問題。表現(xiàn)是AI 生成了一段看起來結(jié)構(gòu)完整、變量命名合理、注釋也寫得很專業(yè)的代碼但引用的某個(gè)庫函數(shù)實(shí)際上不存在或者某個(gè)方法的參數(shù)順序是錯(cuò)的。為什么會(huì)出現(xiàn)這個(gè)問題因?yàn)榇竽Ｐ蛯W(xué)習(xí)的是“文本的概率分布”而不是“代碼的真實(shí)運(yùn)行語義”。它知道requests.get(url, params...)這種寫法在訓(xùn)練數(shù)據(jù)中經(jīng)常出現(xiàn)所以會(huì)合理地生成它但如果某個(gè)第三方庫在 2.0 版本改了 API模型的訓(xùn)練數(shù)據(jù)如果沒有覆蓋到它就會(huì)按舊 API 生成代碼。排查思路很直接不要把 AI 的輸出當(dāng)成最終產(chǎn)物而是當(dāng)成初稿。遇到報(bào)錯(cuò)時(shí)把完整堆棧信息粘貼回 AI讓它根據(jù)真實(shí)報(bào)錯(cuò)修正。同時(shí)盡量讓 AI 引用它訓(xùn)練數(shù)據(jù)中最常見的穩(wěn)定 API減少使用“聽起來很合理”的冷門方法。5.2 上下文丟失為什么 AI 改著改著就“失憶”了很多 AI IDE 看起來是“懂整個(gè)項(xiàng)目”的但實(shí)際使用時(shí)你會(huì)發(fā)現(xiàn)它經(jīng)常只關(guān)注你當(dāng)前打開的幾個(gè)文件或者它認(rèn)為相關(guān)的幾個(gè)文件。比如你讓 AI 修改UserService它改了然后你讓它修改調(diào)用UserService的OrderService它可能沒有意識(shí)到UserService的方法簽名已經(jīng)變了于是生成了一段完全對不上的調(diào)用代碼。解決思路有幾個(gè)保持對話粒度一次對話聚焦一個(gè)模塊不要在一個(gè)對話里跨多個(gè)無關(guān)任務(wù)。顯式提供依賴信息在 prompt 里寫清楚“OrderService 中調(diào)用了 UserService 的 xxx 方法該方法的簽名是 xxx”。利用項(xiàng)目文檔把接口變更記錄、模塊依賴說明寫進(jìn)項(xiàng)目的 docs 目錄AI 工具讀取全局索引時(shí)能獲得更完整的圖景。引入測試驗(yàn)證讓 AI 在改完代碼后運(yùn)行相關(guān)測試通過反饋閉環(huán)來校正“失憶”問題。5.3 安全邊界AI 代碼的隱蔽風(fēng)險(xiǎn)AI 生成的代碼在安全方面往往存在兩類風(fēng)險(xiǎn)一類是顯式安全隱患比如把密鑰硬編碼、拼接 SQL、不對用戶輸入做校驗(yàn)。這類問題通常發(fā)生在 AI 不了解項(xiàng)目安全規(guī)范的情況下人工代碼審查可以攔截。另一類是隱性邏輯風(fēng)險(xiǎn)比如 AI 生成的權(quán)限校驗(yàn)邏輯遺漏了某個(gè)角色或者分頁邏輯在多線程場景下有并發(fā)問題。這類風(fēng)險(xiǎn)更難發(fā)現(xiàn)因?yàn)榇a“能跑”但只在特定條件下出錯(cuò)。應(yīng)對建議把安全和異常處理寫進(jìn)編碼規(guī)范讓 AI 在生成代碼時(shí)遵循同時(shí)所有 AI 生成的代碼必須經(jīng)過人工代碼審查尤其是涉及權(quán)限、支付、用戶數(shù)據(jù)的模塊不要把安全邊界交給模型來把握。6. 工程化建議與最佳實(shí)踐6.1 用 Spec 補(bǔ)上需求的“最后一公里”與其抱怨 AI 生成的代碼不符合預(yù)期不如在源頭上把需求描述清楚。我之前試過幾種方法最有效的是用 bullet point 列出功能點(diǎn)而不是寫一大段散文明確輸入、輸出、邊界條件告訴 AI 當(dāng)前項(xiàng)目已有的技術(shù)棧和約束要求 AI 先輸出實(shí)現(xiàn)計(jì)劃人確認(rèn)后再寫代碼。一個(gè)簡單的 prompt 示例請幫我實(shí)現(xiàn)一個(gè)用戶注冊接口要求如下 1. 使用 Python 3.10 FastAPI數(shù)據(jù)庫用 PostgreSQLORM 使用 SQLAlchemy 2.x。 2. 注冊參數(shù)username3-20位字母數(shù)字、password至少8位必須包含字母和數(shù)字、email格式校驗(yàn)。 3. 用戶名重復(fù)時(shí)返回 409參數(shù)校驗(yàn)失敗時(shí)返回 400。 4. 密碼存儲(chǔ)使用 bcrypt 加鹽哈希禁止明文存儲(chǔ)。 5. 注冊成功后返回 201 和用戶簡要信息不返回密碼字段。 6. 不要?jiǎng)?chuàng)建額外文件修改現(xiàn)有的 app/api/user.py、app/models/user.py、app/schemas/user.py。 請先生成實(shí)現(xiàn)計(jì)劃等我確認(rèn)后再開始編碼。這個(gè) prompt 看起來長但它把需求邊界、技術(shù)棧、錯(cuò)誤碼、安全要求、文件范圍全部約束住了。AI 生成的代碼質(zhì)量會(huì)顯著提升。6.2 把 AI 當(dāng)成“結(jié)對程序員”而不是“自動(dòng)生成器”一個(gè)心理模型很重要AI Coding 不是“輸入需求輸出上線代碼”的自動(dòng)流水線而是一個(gè)“結(jié)對程序員”——它比你快但你需要對它負(fù)責(zé)。這意味著AI 生成的代碼審查者是你不是 AIAI 寫的每一段邏輯你都要能解釋清楚“它為什么這么做”遇到 AI 反復(fù)給出錯(cuò)誤答案時(shí)不要繼續(xù)消耗 Credits 硬試而是停下來拆解問題、補(bǔ)充上下文對 AI 產(chǎn)出的信任應(yīng)該在測試通過、審查通過之后建立而不是在生成之后。6.3 團(tuán)隊(duì)層面統(tǒng)一工具鏈、規(guī)范與審查團(tuán)隊(duì)推行 AI Coding 時(shí)最容易踩的坑是“所有人都開始用 AI但各自為戰(zhàn)”。建議從三個(gè)層面收攏工具層面統(tǒng)一 AI 編碼工具和模型配置保證生成代碼風(fēng)格一致。如果有私有化部署條件優(yōu)先使用私有化模型處理敏感代碼避免核心代碼進(jìn)入公網(wǎng)服務(wù)。規(guī)范層面把“是否允許 AI 直接修改文件、哪些模塊禁止 AI 參與、AI 生成代碼是否需要標(biāo)記”寫入團(tuán)隊(duì)開發(fā)規(guī)范。有些團(tuán)隊(duì)還會(huì)在 PR 描述中要求注明“該 PR 中 XX% 代碼由 AI 生成人工審查要點(diǎn)是 XX”便于 Reviewer 聚焦重點(diǎn)。審查層面AI 生成的代碼必須走和人工代碼一樣的 Code Review 流程。不能因?yàn)椤癆I 寫的就不需要看了”。實(shí)際上AI 生成的代碼可能比人工代碼更需要注意審查因?yàn)樗赡苓`反一些隱含的項(xiàng)目約束。6.4 上下文管理是 AI Coding 時(shí)代的新核心技能如果說傳統(tǒng)軟件開發(fā)的核心技能是“抽象思維”和“架構(gòu)設(shè)計(jì)”那么在 AI Coding 時(shí)代上下文管理已經(jīng)悄然成為一項(xiàng)關(guān)鍵能力。這里的上下文管理包括知道什么時(shí)候該讓 AI 看整個(gè)項(xiàng)目什么時(shí)候只讓它看某個(gè)文件能把關(guān)鍵信息依賴關(guān)系、接口定義、業(yè)務(wù)規(guī)則顯式放在 AI 可以讀取的位置能判斷當(dāng)前對話的上下文是否足夠不夠時(shí)及時(shí)補(bǔ)充而不是硬著頭皮讓 AI 繼續(xù)猜能把大任務(wù)拆成多個(gè)小任務(wù)保證每個(gè)小任務(wù)都在一個(gè)可控的上下文范圍內(nèi)完成。這個(gè)能力的重要性在大型項(xiàng)目中尤其明顯。一個(gè) AI 工具能“看到”的上下文是有限的決定產(chǎn)出質(zhì)量的關(guān)鍵往往不是你給了它多少 token而是你給了它多少“正確的 token”。6.5 關(guān)于多 Agent 協(xié)同的落地建議如果你的團(tuán)隊(duì)想嘗試多 Agent 協(xié)同不建議一開始就搭一個(gè)復(fù)雜的多 Agent 系統(tǒng)。更務(wù)實(shí)的路徑是先用單 Agent 把單個(gè)任務(wù)的質(zhì)量穩(wěn)定下來增加一個(gè)“測試 Agent”讓寫碼和驗(yàn)證分離增加“審查 Agent”在合入前做靜態(tài)檢查最后再考慮“需求分析 Agent”“文檔 Agent”等更復(fù)雜的角色。始終保持一個(gè)原則Agent 的每一次修改都應(yīng)該有跡可循、可以被回滾。AI 編程工具的使用必須在版本控制的保護(hù)傘下進(jìn)行。7. 結(jié)尾AI Coding 是一場“人機(jī)協(xié)作習(xí)慣”的轉(zhuǎn)變聊了這么多AI Coding 本質(zhì)上不是一個(gè)“工具升級(jí)”問題而是一個(gè)“協(xié)作習(xí)慣”問題。它帶來的不是簡單的效率翻倍而是把開發(fā)者從“寫代碼”這個(gè)動(dòng)作中部分解放出來轉(zhuǎn)而要求我們在更高層級(jí)上做判斷需求是否清晰、實(shí)現(xiàn)是否安全、邊界是否完整、上下文是否充分。那些對 AI Coding 的不滿大部分并不是因?yàn)?AI 太弱而是因?yàn)槭褂谜哌€在用舊習(xí)慣迎接新工具。依賴幻覺問題可以通過上下文和測試來緩解上下文丟失問題可以通過任務(wù)拆分來緩解安全問題可以通過規(guī)范和審查來緩解。沒有一種方式能徹底消除這些 Discontents但工程化的使用方式可以讓它們在可控范圍內(nèi)。如果你準(zhǔn)備開始我給的建議是選一個(gè)你熟悉的小項(xiàng)目先寫一份 Spec再讓 AI 去實(shí)現(xiàn)然后認(rèn)真做一遍代碼審查和測試看看哪些地方 AI 做得比你好、哪些地方需要你兜底。這個(gè)過程跑完你對 AI Coding 的真實(shí)能力邊界會(huì)有非常具體的感覺。下一步可以繼續(xù)研究 Spec Coding 的細(xì)化方法、AI 編程中的測試生成策略、以及團(tuán)隊(duì)場景下的 Coding Plan 落地實(shí)踐。如果本文對你有幫助可以收藏備用也可以把你在項(xiàng)目中遇到的 AI 代碼問題分享出來一起討論。 AI Coding全景指南：從工具選擇到工程化落地實(shí)踐
這兩年“AI Coding”幾乎是從工具圈一路火到了管理層。打開技術(shù)社區(qū)滿屏都是“AI 輔助編程”“AI Agent 寫代碼”的話題打開招聘 JD不少崗位也把“熟悉 AI 編程工具”寫成了加分項(xiàng)。但真正在一線把 AI 用到生產(chǎn)項(xiàng)目里的團(tuán)隊(duì)往往一邊享受效率提升一邊又有一肚子苦水AI 生成的代碼花團(tuán)錦簇但跑不起來改一個(gè)字段引發(fā)三處連帶報(bào)錯(cuò)看似 80% 的代碼由 AI 完成剩下的 20% 卻要花掉 80% 的時(shí)間去修。這篇文章不打算去神化 AI Coding也不打算唱反調(diào)而是以工程落地的視角把 AI Coding 的核心概念、主流工具、工作流程、實(shí)戰(zhàn)案例、常見坑點(diǎn)、工程化建議一次性梳理清楚。既適合剛接觸 AI 編程的新手也適合已經(jīng)在團(tuán)隊(duì)里推行 AI Coding、卻總在“效率與失控”之間反復(fù)搖擺的開發(fā)者。1. 背景與核心概念A(yù)I Coding 到底是什么1.1 從“代碼補(bǔ)全”到“編程智能體”AI Coding字面意思是“用 AI 寫代碼”。但這個(gè)詞的內(nèi)涵在過去兩年里已經(jīng)發(fā)生了很大變化。早期大家熟悉的 AI 編程本質(zhì)上是“代碼補(bǔ)全增強(qiáng)版”你寫了一個(gè)函數(shù)名AI 幫你補(bǔ)出函數(shù)體你寫了一個(gè) SQL 的開頭AI 幫你猜 WHERE 條件。這種模式的核心是概率預(yù)測模型根據(jù)你當(dāng)前的代碼上下文推斷下一步最可能出現(xiàn)的 token。代表性工具有 GitHub Copilot、通義靈碼等。到了 2024 年下半年以后AI Coding 的概念明顯往“智能體Agent”方向演進(jìn)。工具不再只是做行級(jí)補(bǔ)全而是可以讀取整個(gè)項(xiàng)目的目錄結(jié)構(gòu)和關(guān)鍵文件理解用戶用自然語言描述的需求自主規(guī)劃要改哪些文件、調(diào)用哪些函數(shù)生成代碼、運(yùn)行測試、根據(jù)報(bào)錯(cuò)自動(dòng)修復(fù)甚至提交 Pull Request。這種模式下的 AI不再是你敲代碼時(shí)的“輸入法”而是“結(jié)對程序員”——雖然這個(gè)程序員偶爾會(huì)自信地寫出一個(gè)不存在的 API。1.2 AI Coding 解決的核心問題為什么 AI Coding 會(huì)這么快流行起來本質(zhì)上是它切中了軟件開發(fā)中幾個(gè)長期存在的痛點(diǎn)重復(fù)勞動(dòng)占比高CRUD 接口、DTO 轉(zhuǎn)換、單元測試模板、配置文件這類代碼模式固定、邏輯簡單但數(shù)量巨大?？缯Z言、跨框架切換成本高一個(gè)后端工程師臨時(shí)要寫一段 Python 腳本或者一個(gè)前端要理解一段 Java 老代碼AI 可以快速翻譯和解釋。從需求到代碼的翻譯損耗很多開發(fā)時(shí)間不是花在“怎么寫”而是花在“查文檔、試錯(cuò)、對齊接口”上。AI 可以把這一步壓縮到很短時(shí)間內(nèi)。入門門檻對于剛學(xué)編程的人來說AI 可以作為一個(gè) 7x24 小時(shí)在線的“答疑老師”把報(bào)錯(cuò)、語法、邏輯講得明明白白。1.3 常見應(yīng)用場景AI Coding 在現(xiàn)階段的典型應(yīng)用場景包括場景說明適合程度腳手架搭建生成項(xiàng)目結(jié)構(gòu)、初始化配置、創(chuàng)建基礎(chǔ)代碼高接口與模板代碼Controller、Service、Mapper、DTO 等重復(fù)性代碼高單元測試生成根據(jù)業(yè)務(wù)代碼生成測試用例和樁數(shù)據(jù)高代碼解釋與重構(gòu)閱讀陌生代碼、提取公共邏輯、調(diào)整結(jié)構(gòu)高Bug 定位與修復(fù)結(jié)合報(bào)錯(cuò)信息縮小排查范圍中腳本工具編寫寫數(shù)據(jù)處理、日志分析等一次性腳本高復(fù)雜業(yè)務(wù)系統(tǒng)開發(fā)涉及多個(gè)模塊、強(qiáng)耦合狀態(tài)、架構(gòu)設(shè)計(jì)的核心業(yè)務(wù)低可以看到AI Coding 擅長的是“范圍清晰、模式成熟、反饋及時(shí)”的任務(wù)。越是邊界模糊、需要大量業(yè)務(wù)判斷的任務(wù)AI 的可靠性越差——這一點(diǎn)在后面的“Discontents不滿”部分會(huì)詳細(xì)展開。2. 從 Vibe Coding 到 Spec CodingAI 編程的兩種姿勢如果你關(guān)注過 AI 編程相關(guān)的討論一定見過兩個(gè)高頻詞Vibe Coding和Spec Coding。這兩個(gè)概念代表了兩種截然不同的 AI 編程姿勢也直接決定了項(xiàng)目的走向。2.1 Vibe Coding順著感覺寫代碼“Vibe Coding”這個(gè)詞最早是由 AI 大神 Andrej Karpathy 在一次分享中提出的大意是你不再逐行敲代碼而是描述需求、把 AI 生成的代碼直接接受下來即使你不完全理解每一行在做什么。你跟著“感覺”走像是一個(gè)樂隊(duì)在跟著氛圍即興演奏。Vibe Coding 的優(yōu)點(diǎn)非常明顯原型速度快得驚人。一個(gè)簡單的網(wǎng)頁、一個(gè)數(shù)據(jù)腳本可能幾分鐘就能跑起來。非常適合個(gè)人開發(fā)者做 Demo、Hackathon 項(xiàng)目、一次性工具。降低了寫作代碼的心理門檻很多非專業(yè)開發(fā)者也能“做出東西”。但它的缺點(diǎn)同樣致命代碼質(zhì)量不可控。AI 生成的代碼常?！翱雌饋砗侠怼钡赡艽嬖谶壿嬄┒?、安全隱患、性能問題。沒有人真正理解系統(tǒng)的整體結(jié)構(gòu)。一旦項(xiàng)目變大任何人都無法維護(hù)。錯(cuò)誤會(huì)被不斷放大。AI 會(huì)在錯(cuò)誤的代碼基礎(chǔ)上一本正經(jīng)地繼續(xù)生成錯(cuò)誤修復(fù)。所以Vibe Coding 適合什么適合“跑通流程做驗(yàn)證”的場景。它解決的痛點(diǎn)是“從 0 到 1”不解決“從 1 到 100”。2.2 Spec Coding先寫規(guī)格再寫實(shí)現(xiàn)Spec Coding 是針對 Vibe Coding 的失控問題衍生出來的另一種實(shí)踐。所謂 Spec就是規(guī)格說明。在讓 AI 動(dòng)手寫代碼之前開發(fā)者先寫清楚這個(gè)模塊要解決什么問題輸入是什么、輸出是什么邊界條件有哪些依賴哪些外部服務(wù)性能要求是什么驗(yàn)收標(biāo)準(zhǔn)是什么。然后 AI 根據(jù)這份 Spec 去生成實(shí)現(xiàn)代碼。這樣做的好處是需求被顯式地表達(dá)出來AI 不再“猜”你的意圖代碼結(jié)構(gòu)更可控因?yàn)?Spec 本身就定義了邊界代碼審查有據(jù)可依Review 時(shí)對照 Spec 檢查實(shí)現(xiàn)是否偏離即使 AI 生成質(zhì)量不佳人也能通過 Spec 快速發(fā)現(xiàn)問題。拿我自己的經(jīng)驗(yàn)來說一個(gè)需求描述如果只有一句話AI 生成的代碼大概率只有一種“標(biāo)準(zhǔn)答案”而真實(shí)業(yè)務(wù)往往有十幾種隱藏約束。Spec 就是把隱藏約束顯式化的過程。2.3 兩種姿勢怎么選維度Vibe CodingSpec Coding適用階段原型驗(yàn)證、個(gè)人工具、Demo生產(chǎn)代碼、團(tuán)隊(duì)協(xié)作、核心業(yè)務(wù)需求表達(dá)口頭化、模糊結(jié)構(gòu)化、顯式代碼質(zhì)量不可控相對可控維護(hù)成本高低適合人群新手、設(shè)計(jì)師、產(chǎn)品經(jīng)理專業(yè)開發(fā)者、技術(shù)團(tuán)隊(duì)一個(gè)務(wù)實(shí)的策略是先用 Vibe Coding 快速驗(yàn)證方向再切換到 Spec Coding 讓代碼“配得上上線”。兩者不是對立關(guān)系而是項(xiàng)目不同階段的不同工具。3. AI Coding 主力工具與工作流程3.1 工具形態(tài)插件、IDE、云端平臺(tái)目前的 AI Coding 工具大致分三類編輯器插件型在 VSCode、JetBrains 等現(xiàn)有 IDE 中安裝插件如 GitHub Copilot、通義靈碼、Continue 等。這類工具上手成本低但能力上限受限于編輯器的上下文感知能力。AI 原生 IDE 型以 Cursor 為代表底層基于 VSCode 改造深度集成了 AI 對話、多文件編輯、全局代碼索引。Cursor 的特點(diǎn)是對整個(gè)項(xiàng)目的理解能力更強(qiáng)適合作為主力開發(fā)環(huán)境。云端開發(fā)與編程計(jì)劃型類似阿里云百煉的 Coding Plan、Qwen Code 等把 AI 編程能力和云端資源、模型 API 管理結(jié)合在一起。團(tuán)隊(duì)層面可以利用這類平臺(tái)統(tǒng)一管理模型配額、上下文策略和團(tuán)隊(duì)成員的使用權(quán)限。另外還有一個(gè)概念最近頻繁出現(xiàn)Credits積分/配額。在 AI 編程工具里Credits 通常指用戶可消耗的算力額度。每次調(diào)用大模型生成代碼、執(zhí)行一次深度分析都會(huì)消耗一定數(shù)量的 Credits。團(tuán)隊(duì)在使用云端 AI 編程平臺(tái)時(shí)需要關(guān)注 Credits 的分配和消耗策略避免某個(gè)成員一次性把團(tuán)隊(duì)額度全部用完。3.2 什么是 Coding Plan“Coding Plan”在不同語境下含義略有不同但核心指向是一致的一套結(jié)構(gòu)化的 AI 編碼方案不只是“給 AI 一個(gè) prompt”而是明確 AI 如何理解需求、如何拆解任務(wù)、如何驗(yàn)證產(chǎn)出。在阿里云百煉等平臺(tái)上Coding Plan 往往表現(xiàn)為選擇編程任務(wù)的類型如 Web 應(yīng)用開發(fā)、數(shù)據(jù)處理腳本、單元測試生成配置使用的基礎(chǔ)模型如 Qwen 系列設(shè)定 AI 的行為規(guī)則如是否允許修改現(xiàn)有文件、是否需要生成測試代碼生成一個(gè)任務(wù)執(zhí)行計(jì)劃交給人確認(rèn)后再開始編碼。在團(tuán)隊(duì)場景下Coding Plan 的意義還在于它把“團(tuán)隊(duì)成員如何使用 AI”這件事規(guī)范化了。不同人寫出來的 prompt 水平參差不齊導(dǎo)致 AI 產(chǎn)出質(zhì)量差異巨大。一個(gè)統(tǒng)一的 Plan 模板可以讓 AI 的輸出更穩(wěn)定也更容易審計(jì)。3.3 多 Agent 協(xié)同AI Coding 的下一個(gè)階段如果你關(guān)注 2026 年以后的 AI 編程動(dòng)態(tài)“多 Agent 協(xié)同”是個(gè)繞不開的關(guān)鍵詞。所謂多 Agent 協(xié)同簡單說就是不再由一個(gè) AI 從頭干到尾而是讓多個(gè)扮演不同角色的 AI Agent 分工合作需求分析 Agent負(fù)責(zé)把模糊描述拆成結(jié)構(gòu)化需求產(chǎn)出任務(wù)清單編碼 Agent根據(jù)任務(wù)清單生成或修改代碼測試 Agent為代碼生成測試用例并運(yùn)行反饋結(jié)果審查 Agent檢查代碼風(fēng)格、安全隱患、潛在性能問題文檔 Agent同步更新 README、接口文檔、變更記錄。多個(gè) Agent 之間通過共享的任務(wù)上下文協(xié)作類似一個(gè)微型虛擬研發(fā)團(tuán)隊(duì)。好處是每個(gè) Agent 的任務(wù)邊界清晰上下文不容易混亂產(chǎn)出并行效率更高質(zhì)量閘門分散問題更容易被發(fā)現(xiàn)。但多 Agent 協(xié)同也帶來了新的挑戰(zhàn)上下文如何同步一個(gè) Agent 修改了接口另一個(gè) Agent 還在按舊接口寫測試怎么協(xié)調(diào)這本質(zhì)上和人類團(tuán)隊(duì)協(xié)作遇到的問題是一樣的只是把“溝通成本”轉(zhuǎn)移成了“上下文管理成本”。如果你的團(tuán)隊(duì)正在嘗試多 Agent 協(xié)同建議從“兩個(gè) Agent 起步”一個(gè)負(fù)責(zé)寫代碼一個(gè)負(fù)責(zé)寫測試和做代碼審查。等流程跑順了再逐步增加角色。3.4 團(tuán)隊(duì) AI Coding 的協(xié)作方式個(gè)人用 AI 寫代碼和團(tuán)隊(duì)用 AI 寫代碼完全是兩件事。個(gè)人寫的代碼崩了影響范圍通?？煽貓F(tuán)隊(duì)里如果有人不加約束地用 AI 生成代碼項(xiàng)目很快就變成一座“補(bǔ)丁疊補(bǔ)丁”的屎山。團(tuán)隊(duì)協(xié)作的核心建議是統(tǒng)一工具鏈團(tuán)隊(duì)內(nèi)盡量使用相同的 AI 編碼工具和模型配置避免不同成員生成風(fēng)格迥異的代碼。沉淀 Prompt 模板把常用的需求描述、代碼審查、測試生成 prompt 固化下來形成團(tuán)隊(duì)資產(chǎn)。約定 AI 的使用邊界哪些模塊允許 AI 直接生成、哪些模塊必須人工編寫、哪些操作如數(shù)據(jù)庫遷移需要審批。建立審查機(jī)制AI 生成的代碼必須走代碼審查和人工代碼一視同仁。4. 完整實(shí)戰(zhàn)案例用 AI Coding 從零完成一個(gè)日志分析工具前面講了不少概念這一節(jié)我們來做一個(gè)完整的實(shí)戰(zhàn)。目標(biāo)是用 AI Coding 的方式從需求描述到可運(yùn)行代碼完成一個(gè) Python CLI 日志分析工具。我會(huì)模擬一下人工與 AI 的協(xié)作過程包括需求描述、AI 生成、人工審查和修復(fù)。4.1 需求描述假設(shè)業(yè)務(wù)方給了一個(gè)很樸素的需求有一個(gè)應(yīng)用日志文件 app.log里面每行類似2026-08-12 10:23:45 [ERROR] Failed to connect to database2026-08-12 10:24:01 [INFO] User login success我需要一個(gè)命令行工具統(tǒng)計(jì)各級(jí)別日志數(shù)量找出最近 10 條 ERROR 日志并能按時(shí)間段過濾。如果是 Vibe Coding 模式我們可以直接把這個(gè)需求丟給 AI讓它生成腳本。但為了體現(xiàn) Spec Coding 的思路我們先寫一個(gè)簡易 Spec# 日志分析工具 Spec 功能點(diǎn) 1. 輸入?yún)?shù)日志文件路徑必填、時(shí)間范圍可選、錯(cuò)誤數(shù) N可選默認(rèn) 10。 2. 統(tǒng)計(jì) INFO / WARN / ERROR / DEBUG 各級(jí)別出現(xiàn)次數(shù)。 3. 輸出最近 N 條 ERROR 日志的完整內(nèi)容。 4. 日志格式時(shí)間 級(jí)別 消息三級(jí)以上日志單獨(dú)統(tǒng)計(jì)。 5. 要求Python 3.8僅使用標(biāo)準(zhǔn)庫提供命令行入口。4.2 讓 AI 生成代碼把上面的 Spec 和樣例日志格式發(fā)給 AI它可能生成類似這樣的核心代碼。注意這是AI 生成版本的示意我們特意保留了幾個(gè)常見問題方便后面演示人工審查。#!/usr/bin/env python3 # 文件路徑log_analyzer.py import argparse import re from collections import Counter from datetime import datetime def parse_line(line): 解析單行日志返回 (時(shí)間字符串, 級(jí)別, 消息)。 pattern r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w)\] (.*) match re.match(pattern, line) if not match: return None timestamp_str, level, message match.groups() return timestamp_str, level, message def load_logs(path): logs [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue parsed parse_line(line) if parsed: logs.append(parsed) return logs def filter_by_time(logs, startNone, endNone): 按時(shí)間范圍過濾日志。start 和 end 格式為 YYYY-MM-DD HH:MM:SS。 if not start and not end: return logs filtered [] for ts, level, msg in logs: if start and ts start: continue if end and ts end: continue filtered.append((ts, level, msg)) return filtered def analyze(log_path, startNone, endNone, error_count10): logs load_logs(log_path) logs filter_by_time(logs, start, end) counter Counter(level for _, level, _ in logs) error_logs [(ts, msg) for ts, level, msg in logs if level ERROR] print( 日志級(jí)別統(tǒng)計(jì) ) for level in [DEBUG, INFO, WARN, ERROR]: print(f{level}: {counter.get(level, 0)}) print(f\n 最近 {error_count} 條 ERROR 日志 ) for ts, msg in error_logs[-error_count:]: print(f{ts} {msg}) def main(): parser argparse.ArgumentParser(description日志分析工具) parser.add_argument(log_path, help日志文件路徑) parser.add_argument(--start, help開始時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(--end, help結(jié)束時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(-n, --error-count, typeint, default10, help顯示最近 N 條 ERROR 日志) args parser.parse_args() analyze(args.log_path, args.start, args.end, args.error_count) if __name__ __main__: main()運(yùn)行方式python3 log_analyzer.py app.log python3 log_analyzer.py app.log --start 2026-08-12 10:00:00 --end 2026-08-12 12:00:00 -n 54.3 人工審查發(fā)現(xiàn)的問題這個(gè)腳本看起來能跑但“能跑”和“能上線”之間隔著幾個(gè)問題。我把這些問題列出來大家可以對照一下自己的使用習(xí)慣——AI 生成代碼后多少人會(huì)做這一步審查問題 1時(shí)間比較方式錯(cuò)誤。代碼里start and ts start是字符串比較。當(dāng)時(shí)間字符串格式完全一致時(shí)YYYY-MM-DD HH:MM:SS字典序比較恰好等于時(shí)間比較這暫時(shí)沒問題。但一旦輸入的時(shí)間格式稍有不同例如2026-8-1而不是2026-08-01比較就會(huì)出錯(cuò)。規(guī)范化輸入或顯式解析時(shí)間才是正解。問題 2沒有處理文件不存在、空文件等邊界情況。真實(shí)業(yè)務(wù)中日志文件可能不存在、可能被占用、可能是空文件。腳本會(huì)直接拋出FileNotFoundError對用戶不友好。問題 3沒有處理無效日志行。parse_line返回 None 時(shí)load_logs直接丟棄用戶不知道有日志行沒有被解析。這在排查“統(tǒng)計(jì)數(shù)字對不上”時(shí)會(huì)很頭疼。問題 4盲目相信 AI 的“標(biāo)準(zhǔn)答案”。大家注意腳本里的分析邏輯是 AI 根據(jù)我給的樣例格式寫的。如果生產(chǎn)環(huán)境的日志格式有變化——比如時(shí)間格式、日志級(jí)別大小寫、多行堆棧——這個(gè)腳本會(huì)靜默地產(chǎn)生錯(cuò)誤統(tǒng)計(jì)結(jié)果。4.4 人工加固后的版本針對上面這些問題我做了部分加固核心片段如下#!/usr/bin/env python3 # 文件路徑log_analyzer_fixed.py import argparse import re import sys from collections import Counter from datetime import datetime from pathlib import Path LOG_PATTERN re.compile( r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w)\] (.*) ) VALID_LEVELS {DEBUG, INFO, WARN, ERROR} def parse_line(line): match LOG_PATTERN.match(line.strip()) if not match: return None timestamp_str, level, message match.groups() if level not in VALID_LEVELS: return None return timestamp_str, level, message def parse_time(value): try: return datetime.strptime(value, %Y-%m-%d %H:%M:%S) except ValueError: raise argparse.ArgumentTypeError( f時(shí)間格式應(yīng)為 YYYY-MM-DD HH:MM:SS收到{value} ) def load_logs(path): log_file Path(path) if not log_file.exists(): sys.exit(f錯(cuò)誤文件不存在 - {path}) if not log_file.is_file(): sys.exit(f錯(cuò)誤路徑不是文件 - {path}) logs [] skipped 0 with log_file.open(r, encodingutf-8) as f: for line in f: if not line.strip(): continue parsed parse_line(line) if parsed: logs.append(parsed) else: skipped 1 if skipped: print(f警告{skipped} 行日志無法解析已跳過。, filesys.stderr) return logs def filter_by_time(logs, startNone, endNone): if not start and not end: return logs start_dt datetime.strptime(start, %Y-%m-%d %H:%M:%S) if start else None end_dt datetime.strptime(end, %Y-%m-%d %H:%M:%S) if end else None filtered [] for ts, level, msg in logs: ts_dt datetime.strptime(ts, %Y-%m-%d %H:%M:%S) if start_dt and ts_dt start_dt: continue if end_dt and ts_dt end_dt: continue filtered.append((ts, level, msg)) return filtered def analyze(log_path, startNone, endNone, error_count10): logs load_logs(log_path) logs filter_by_time(logs, start, end) if not logs: print(沒有符合條件的日志記錄。) return counter Counter(level for _, level, _ in logs) error_logs [(ts, msg) for ts, level, msg in logs if level ERROR] print( 日志級(jí)別統(tǒng)計(jì) ) for level in [DEBUG, INFO, WARN, ERROR]: print(f{level}: {counter.get(level, 0)}) print(f\n 最近 {error_count} 條 ERROR 日志 ) for ts, msg in error_logs[-error_count:]: print(f{ts} {msg}) def main(): parser argparse.ArgumentParser(description日志分析工具) parser.add_argument(log_path, help日志文件路徑) parser.add_argument(--start, typeparse_time, help開始時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(--end, typeparse_time, help結(jié)束時(shí)間格式 YYYY-MM-DD HH:MM:SS) parser.add_argument(-n, --error-count, typeint, default10, help顯示最近 N 條 ERROR 日志) args parser.parse_args() analyze(args.log_path, args.start, args.end, args.error_count) if __name__ __main__: main()一個(gè)簡單的案例從“AI 能跑”到“人工可維護(hù)”中間差的就是這份審查和加固。這也是整篇文章想表達(dá)的重點(diǎn)AI Coding 的下限由模型決定上限由人決定。5. AI Coding 的“不滿”與高頻踩坑清單標(biāo)題里的 Discontents 在這里集中體現(xiàn)。我整理了一些團(tuán)隊(duì)和個(gè)人在使用 AI Coding 時(shí)最常見的問題每個(gè)問題都附上了排查思路和解決方向。問題現(xiàn)象常見原因解決思路AI 生成代碼使用了不存在的 API 或庫模型幻覺訓(xùn)練數(shù)據(jù)中沒有該 API 的準(zhǔn)確信息審查依賴版本運(yùn)行時(shí)報(bào)錯(cuò)后把完整堆棧反饋給 AI使用官方文檔中的示例作為上下文修改一個(gè)功能后其他地方接連報(bào)錯(cuò)AI 只看到了局部上下文沒有理解全局依賴建立項(xiàng)目索引使用支持多文件上下文管理的工具顯式要求 AI 先搜索引用關(guān)系再改代碼AI 生成了“看起來正確”但邏輯錯(cuò)誤的結(jié)果需求本身模糊AI 選擇了最簡單的理解寫 Spec用測試用例約束行為人工補(bǔ)充邊界條件代碼風(fēng)格與團(tuán)隊(duì)規(guī)范不一致沒有給 AI 提供團(tuán)隊(duì)編碼規(guī)范把團(tuán)隊(duì)規(guī)范文件如 style guide加入上下文利用工具的項(xiàng)目級(jí)規(guī)則配置AI 過度設(shè)計(jì)或過于簡略prompt 缺少約束條件在 prompt 中明確“最小實(shí)現(xiàn)”、“不要引入額外依賴”、“遵循現(xiàn)有代碼風(fēng)格”團(tuán)隊(duì)多人使用 AI 后代碼風(fēng)格千奇百怪缺少統(tǒng)一工具鏈和規(guī)范統(tǒng)一 AI 工具和模型建立 prompt 模板在 CI 中增加自動(dòng)化風(fēng)格檢查Credits/額度消耗過快高頻調(diào)用大模型做簡單任務(wù)區(qū)分“簡單補(bǔ)全”和“深度生成”為不同任務(wù)選擇不同模型設(shè)置單次任務(wù)配額敏感信息進(jìn)入公共模型服務(wù)開發(fā)者把密鑰、生產(chǎn)數(shù)據(jù)粘貼到 AI 對話中建立數(shù)據(jù)安全規(guī)范部署私有化模型使用云平臺(tái)的企業(yè)級(jí)隔離區(qū)域5.1 模型幻覺AI 最穩(wěn)定的“不滿來源”模型幻覺是 AI Coding 里最讓人頭疼的問題。表現(xiàn)是AI 生成了一段看起來結(jié)構(gòu)完整、變量命名合理、注釋也寫得很專業(yè)的代碼但引用的某個(gè)庫函數(shù)實(shí)際上不存在或者某個(gè)方法的參數(shù)順序是錯(cuò)的。為什么會(huì)出現(xiàn)這個(gè)問題因?yàn)榇竽Ｐ蛯W(xué)習(xí)的是“文本的概率分布”而不是“代碼的真實(shí)運(yùn)行語義”。它知道requests.get(url, params...)這種寫法在訓(xùn)練數(shù)據(jù)中經(jīng)常出現(xiàn)所以會(huì)合理地生成它但如果某個(gè)第三方庫在 2.0 版本改了 API模型的訓(xùn)練數(shù)據(jù)如果沒有覆蓋到它就會(huì)按舊 API 生成代碼。排查思路很直接不要把 AI 的輸出當(dāng)成最終產(chǎn)物而是當(dāng)成初稿。遇到報(bào)錯(cuò)時(shí)把完整堆棧信息粘貼回 AI讓它根據(jù)真實(shí)報(bào)錯(cuò)修正。同時(shí)盡量讓 AI 引用它訓(xùn)練數(shù)據(jù)中最常見的穩(wěn)定 API減少使用“聽起來很合理”的冷門方法。5.2 上下文丟失為什么 AI 改著改著就“失憶”了很多 AI IDE 看起來是“懂整個(gè)項(xiàng)目”的但實(shí)際使用時(shí)你會(huì)發(fā)現(xiàn)它經(jīng)常只關(guān)注你當(dāng)前打開的幾個(gè)文件或者它認(rèn)為相關(guān)的幾個(gè)文件。比如你讓 AI 修改UserService它改了然后你讓它修改調(diào)用UserService的OrderService它可能沒有意識(shí)到UserService的方法簽名已經(jīng)變了于是生成了一段完全對不上的調(diào)用代碼。解決思路有幾個(gè)保持對話粒度一次對話聚焦一個(gè)模塊不要在一個(gè)對話里跨多個(gè)無關(guān)任務(wù)。顯式提供依賴信息在 prompt 里寫清楚“OrderService 中調(diào)用了 UserService 的 xxx 方法該方法的簽名是 xxx”。利用項(xiàng)目文檔把接口變更記錄、模塊依賴說明寫進(jìn)項(xiàng)目的 docs 目錄AI 工具讀取全局索引時(shí)能獲得更完整的圖景。引入測試驗(yàn)證讓 AI 在改完代碼后運(yùn)行相關(guān)測試通過反饋閉環(huán)來校正“失憶”問題。5.3 安全邊界AI 代碼的隱蔽風(fēng)險(xiǎn)AI 生成的代碼在安全方面往往存在兩類風(fēng)險(xiǎn)一類是顯式安全隱患比如把密鑰硬編碼、拼接 SQL、不對用戶輸入做校驗(yàn)。這類問題通常發(fā)生在 AI 不了解項(xiàng)目安全規(guī)范的情況下人工代碼審查可以攔截。另一類是隱性邏輯風(fēng)險(xiǎn)比如 AI 生成的權(quán)限校驗(yàn)邏輯遺漏了某個(gè)角色或者分頁邏輯在多線程場景下有并發(fā)問題。這類風(fēng)險(xiǎn)更難發(fā)現(xiàn)因?yàn)榇a“能跑”但只在特定條件下出錯(cuò)。應(yīng)對建議把安全和異常處理寫進(jìn)編碼規(guī)范讓 AI 在生成代碼時(shí)遵循同時(shí)所有 AI 生成的代碼必須經(jīng)過人工代碼審查尤其是涉及權(quán)限、支付、用戶數(shù)據(jù)的模塊不要把安全邊界交給模型來把握。6. 工程化建議與最佳實(shí)踐6.1 用 Spec 補(bǔ)上需求的“最后一公里”與其抱怨 AI 生成的代碼不符合預(yù)期不如在源頭上把需求描述清楚。我之前試過幾種方法最有效的是用 bullet point 列出功能點(diǎn)而不是寫一大段散文明確輸入、輸出、邊界條件告訴 AI 當(dāng)前項(xiàng)目已有的技術(shù)棧和約束要求 AI 先輸出實(shí)現(xiàn)計(jì)劃人確認(rèn)后再寫代碼。一個(gè)簡單的 prompt 示例請幫我實(shí)現(xiàn)一個(gè)用戶注冊接口要求如下 1. 使用 Python 3.10 FastAPI數(shù)據(jù)庫用 PostgreSQLORM 使用 SQLAlchemy 2.x。 2. 注冊參數(shù)username3-20位字母數(shù)字、password至少8位必須包含字母和數(shù)字、email格式校驗(yàn)。 3. 用戶名重復(fù)時(shí)返回 409參數(shù)校驗(yàn)失敗時(shí)返回 400。 4. 密碼存儲(chǔ)使用 bcrypt 加鹽哈希禁止明文存儲(chǔ)。 5. 注冊成功后返回 201 和用戶簡要信息不返回密碼字段。 6. 不要?jiǎng)?chuàng)建額外文件修改現(xiàn)有的 app/api/user.py、app/models/user.py、app/schemas/user.py。 請先生成實(shí)現(xiàn)計(jì)劃等我確認(rèn)后再開始編碼。這個(gè) prompt 看起來長但它把需求邊界、技術(shù)棧、錯(cuò)誤碼、安全要求、文件范圍全部約束住了。AI 生成的代碼質(zhì)量會(huì)顯著提升。6.2 把 AI 當(dāng)成“結(jié)對程序員”而不是“自動(dòng)生成器”一個(gè)心理模型很重要AI Coding 不是“輸入需求輸出上線代碼”的自動(dòng)流水線而是一個(gè)“結(jié)對程序員”——它比你快但你需要對它負(fù)責(zé)。這意味著AI 生成的代碼審查者是你不是 AIAI 寫的每一段邏輯你都要能解釋清楚“它為什么這么做”遇到 AI 反復(fù)給出錯(cuò)誤答案時(shí)不要繼續(xù)消耗 Credits 硬試而是停下來拆解問題、補(bǔ)充上下文對 AI 產(chǎn)出的信任應(yīng)該在測試通過、審查通過之后建立而不是在生成之后。6.3 團(tuán)隊(duì)層面統(tǒng)一工具鏈、規(guī)范與審查團(tuán)隊(duì)推行 AI Coding 時(shí)最容易踩的坑是“所有人都開始用 AI但各自為戰(zhàn)”。建議從三個(gè)層面收攏工具層面統(tǒng)一 AI 編碼工具和模型配置保證生成代碼風(fēng)格一致。如果有私有化部署條件優(yōu)先使用私有化模型處理敏感代碼避免核心代碼進(jìn)入公網(wǎng)服務(wù)。規(guī)范層面把“是否允許 AI 直接修改文件、哪些模塊禁止 AI 參與、AI 生成代碼是否需要標(biāo)記”寫入團(tuán)隊(duì)開發(fā)規(guī)范。有些團(tuán)隊(duì)還會(huì)在 PR 描述中要求注明“該 PR 中 XX% 代碼由 AI 生成人工審查要點(diǎn)是 XX”便于 Reviewer 聚焦重點(diǎn)。審查層面AI 生成的代碼必須走和人工代碼一樣的 Code Review 流程。不能因?yàn)椤癆I 寫的就不需要看了”。實(shí)際上AI 生成的代碼可能比人工代碼更需要注意審查因?yàn)樗赡苓`反一些隱含的項(xiàng)目約束。6.4 上下文管理是 AI Coding 時(shí)代的新核心技能如果說傳統(tǒng)軟件開發(fā)的核心技能是“抽象思維”和“架構(gòu)設(shè)計(jì)”那么在 AI Coding 時(shí)代上下文管理已經(jīng)悄然成為一項(xiàng)關(guān)鍵能力。這里的上下文管理包括知道什么時(shí)候該讓 AI 看整個(gè)項(xiàng)目什么時(shí)候只讓它看某個(gè)文件能把關(guān)鍵信息依賴關(guān)系、接口定義、業(yè)務(wù)規(guī)則顯式放在 AI 可以讀取的位置能判斷當(dāng)前對話的上下文是否足夠不夠時(shí)及時(shí)補(bǔ)充而不是硬著頭皮讓 AI 繼續(xù)猜能把大任務(wù)拆成多個(gè)小任務(wù)保證每個(gè)小任務(wù)都在一個(gè)可控的上下文范圍內(nèi)完成。這個(gè)能力的重要性在大型項(xiàng)目中尤其明顯。一個(gè) AI 工具能“看到”的上下文是有限的決定產(chǎn)出質(zhì)量的關(guān)鍵往往不是你給了它多少 token而是你給了它多少“正確的 token”。6.5 關(guān)于多 Agent 協(xié)同的落地建議如果你的團(tuán)隊(duì)想嘗試多 Agent 協(xié)同不建議一開始就搭一個(gè)復(fù)雜的多 Agent 系統(tǒng)。更務(wù)實(shí)的路徑是先用單 Agent 把單個(gè)任務(wù)的質(zhì)量穩(wěn)定下來增加一個(gè)“測試 Agent”讓寫碼和驗(yàn)證分離增加“審查 Agent”在合入前做靜態(tài)檢查最后再考慮“需求分析 Agent”“文檔 Agent”等更復(fù)雜的角色。始終保持一個(gè)原則Agent 的每一次修改都應(yīng)該有跡可循、可以被回滾。AI 編程工具的使用必須在版本控制的保護(hù)傘下進(jìn)行。7. 結(jié)尾AI Coding 是一場“人機(jī)協(xié)作習(xí)慣”的轉(zhuǎn)變聊了這么多AI Coding 本質(zhì)上不是一個(gè)“工具升級(jí)”問題而是一個(gè)“協(xié)作習(xí)慣”問題。它帶來的不是簡單的效率翻倍而是把開發(fā)者從“寫代碼”這個(gè)動(dòng)作中部分解放出來轉(zhuǎn)而要求我們在更高層級(jí)上做判斷需求是否清晰、實(shí)現(xiàn)是否安全、邊界是否完整、上下文是否充分。那些對 AI Coding 的不滿大部分并不是因?yàn)?AI 太弱而是因?yàn)槭褂谜哌€在用舊習(xí)慣迎接新工具。依賴幻覺問題可以通過上下文和測試來緩解上下文丟失問題可以通過任務(wù)拆分來緩解安全問題可以通過規(guī)范和審查來緩解。沒有一種方式能徹底消除這些 Discontents但工程化的使用方式可以讓它們在可控范圍內(nèi)。如果你準(zhǔn)備開始我給的建議是選一個(gè)你熟悉的小項(xiàng)目先寫一份 Spec再讓 AI 去實(shí)現(xiàn)然后認(rèn)真做一遍代碼審查和測試看看哪些地方 AI 做得比你好、哪些地方需要你兜底。這個(gè)過程跑完你對 AI Coding 的真實(shí)能力邊界會(huì)有非常具體的感覺。下一步可以繼續(xù)研究 Spec Coding 的細(xì)化方法、AI 編程中的測試生成策略、以及團(tuán)隊(duì)場景下的 Coding Plan 落地實(shí)踐。如果本文對你有幫助可以收藏備用也可以把你在項(xiàng)目中遇到的 AI 代碼問題分享出來一起討論。