戰(zhàn)：從需求規(guī)格到云上部署，AI編程Agent全鏈路復(fù)現(xiàn))
這條標(biāo)題在社區(qū)里刷屏的時(shí)候我一開始沒當(dāng)回事想著無非又是一輪“AI取代程序員”的情緒化宣泄。直到我自己連續(xù)兩周用 AI 編程 Agent 去做 AI 應(yīng)用的落地實(shí)驗(yàn)才發(fā)現(xiàn)問題真正值得回答只是需要先把“自己”和“造”這兩個(gè)詞拆開——?jiǎng)e再抬杠。先說結(jié)論AI確實(shí)能造出一個(gè)新的AI應(yīng)用。代碼、接口、頁面、部署腳本大部分可以交由大模型和AI智能體完成但這不意味著人可以直接躺平。你能看到的所有“AI自己造AI”的真實(shí)樣本背后都有一份清晰得近乎產(chǎn)品說明書式的需求邊界以及一個(gè)人在旁邊做糾偏。別急著爭論“到底算不算”直接看機(jī)制、看流程、看坑會(huì)比站隊(duì)有用得多。下面我按“技術(shù)拆解 → 逐層實(shí)現(xiàn) → 實(shí)戰(zhàn)復(fù)盤 → 問題排查”的順序把我實(shí)際跑通的一條AI造AI鏈路完整記錄下來。1. AI能不能自己造AI先別急著回答1.1 先落定義這里說的“造AI”到底是什么很多討論到最后變成吵架是因?yàn)殡p方對(duì)“AI自己造AI”的定義完全不一樣。有人期待的是像科幻電影里那樣一個(gè)系統(tǒng)在機(jī)房里憑空覺醒然后自己設(shè)計(jì)下一代模型有人期待的是只要對(duì)著對(duì)話窗口說一句“幫我做個(gè)AI產(chǎn)品”一個(gè)完整應(yīng)用就能自動(dòng)交付。這兩個(gè)理解放在今天都不現(xiàn)實(shí)也不必要。行業(yè)內(nèi)真正在發(fā)生的“AI造AI”指的是大模型生成另外一個(gè)AI應(yīng)用的代碼并且讓它跑起來。舉個(gè)更具體的例子我讓一個(gè)AI編程Agent去構(gòu)建一個(gè)“AI短劇靈感工作臺(tái)”這個(gè)工作臺(tái)本身要調(diào)用大模型API來完成劇情創(chuàng)意生成。也就是說AI既負(fù)責(zé)編寫應(yīng)用代碼又負(fù)責(zé)讓這個(gè)應(yīng)用具備理解用戶輸入并生成內(nèi)容的能力。前者是普通軟件開發(fā)后者是AI能力接入當(dāng)一個(gè)AI Agent能把兩件事同時(shí)做完并交付一個(gè)能直接使用的成品時(shí)它在工程意義上就已經(jīng)完成了一次“自己造自己同類產(chǎn)品”的循環(huán)。所以如果你問“AI能不能造AI”我的回答是能但這里的“造”更接近“從無到有搭建一套可運(yùn)行的AI應(yīng)用”而不是“無中生有創(chuàng)造一個(gè)完整的新模型”。1.2 已經(jīng)跑通的樣本有哪些從2024年下半年到2025年我能親眼驗(yàn)證的“AI造AI”案例已經(jīng)不少而且不是那種只截一張代碼截圖就完事的演示。我自己的實(shí)踐是在Cursor AI編程工具里把項(xiàng)目需求、技術(shù)棧、驗(yàn)收標(biāo)準(zhǔn)寫成一段結(jié)構(gòu)化說明然后讓AI Agent去完成完整建模。它產(chǎn)出的東西包括一個(gè)后端服務(wù)、一個(gè)簡單前端頁面、數(shù)據(jù)庫初始化腳本、部署配置。后端不是那種“Hello World”級(jí)別的空殼而是真的接入了大模型API、帶有提示詞模板、能根據(jù)用戶輸入流式返回結(jié)果。整個(gè)過程里代碼修改工作量的九成是由AI完成的我做的就是拆需求、看輸出、跑測(cè)試、發(fā)現(xiàn)問題后把它丟回給Agent 繼續(xù)改。公開開源社區(qū)里也有類似現(xiàn)象。不少人用Codex CLI、Cline、Aider這些工具從一份GitHub倉庫開始依靠AI Agent自動(dòng)完成功能追加、bug修復(fù)和測(cè)試補(bǔ)充最后合并進(jìn)主分支。這些任務(wù)不再是“寫幾行代碼讓你抄”而是經(jīng)歷“讀代碼→改代碼→跑測(cè)試→根據(jù)報(bào)錯(cuò)再改→再跑”的完整工程循環(huán)。媒體上經(jīng)常提到的AI編程能力目前已經(jīng)不只是補(bǔ)全一段代碼而是能自主理解一個(gè)多文件項(xiàng)目結(jié)構(gòu)甚至在任務(wù)過程中自己更新技術(shù)方案。很多質(zhì)疑者還停留在“AI只能生成片段”的認(rèn)知階段但真實(shí)項(xiàng)目的復(fù)盤已經(jīng)證明AI不只會(huì)寫還會(huì)自己驗(yàn)證、自己修錯(cuò)、自己把多個(gè)模塊粘起來。2. “AI自己造AI”依賴的整套技術(shù)棧2.1 模型層代碼智能的上限來自這里如果讓AI去造一個(gè)AI應(yīng)用它的第一個(gè)依賴是底層大模型的代碼理解能力。模型需要能讀懂一個(gè)目錄下幾十個(gè)文件之間的關(guān)系知道哪里的函數(shù)被誰調(diào)用知道給前端返回什么結(jié)構(gòu)的JSON。這看起來基礎(chǔ)實(shí)際上非常考驗(yàn)?zāi)Ｐ偷纳舷挛奶幚砼c推理能力。在實(shí)踐里代碼能力不足的模型會(huì)帶來災(zāi)難性體驗(yàn)。它可能寫出一段看起來邏輯自洽、但實(shí)際無法運(yùn)行的代碼或者在依賴版本上胡說八道。好的模型能減少無效迭代次數(shù)。比如同樣是生成一個(gè)調(diào)用大模型API的Python后端好的模型會(huì)先確認(rèn)SDK版本再寫調(diào)用邏輯最后把異常處理也補(bǔ)上差的模型只會(huì)按記憶里的過期示例輸出等你去踩坑。2.2 Agent層讓大模型從“出主意”變成“干活”大模型本身不會(huì)操作電腦不會(huì)新增文件不會(huì)運(yùn)行測(cè)試。真正把“AI造AI”從可能變成現(xiàn)實(shí)的是AI Agent這一層。AI智能體的工作機(jī)制很像一個(gè)外包團(tuán)隊(duì)它把一個(gè)大任務(wù)拆成小步驟然后逐步執(zhí)行每一步。在AI造AI的場景里Agent需要完成這些動(dòng)作閱讀項(xiàng)目目錄理解現(xiàn)有代碼結(jié)構(gòu)在指定位置創(chuàng)建、修改源文件執(zhí)行命令行命令比如安裝依賴、運(yùn)行測(cè)試查看運(yùn)行結(jié)果根據(jù)報(bào)錯(cuò)信息調(diào)整代碼反復(fù)循環(huán)直到符合驗(yàn)收條件這個(gè)循環(huán)不需要人時(shí)刻盯著但需要保證每個(gè)步驟之間能串聯(lián)起來。讓Agent理解上下文比讓它寫代碼更難因?yàn)橹灰舷挛睦锷倭艘粋€(gè)關(guān)鍵信息它就可能把文件路徑改錯(cuò)或者反復(fù)使用一個(gè)不存在的函數(shù)。2.3 工具層AI編程插件和IDE把意圖變成文件改動(dòng)沒有工具層的配合模型再強(qiáng)也施展不開。我常用的組合是Cursor AI編程工具負(fù)責(zé)多文件級(jí)別的代碼生成與重構(gòu)IDEA系插件負(fù)責(zé)局部代碼補(bǔ)全和審查再用Codex CLI處理那些需要獨(dú)立終端環(huán)境的自動(dòng)化任務(wù)。這三者的分工很有趣。IDE插件更適合“人在回路”的微調(diào)式開發(fā)它不會(huì)替你做架構(gòu)級(jí)改動(dòng)但能在你修改一個(gè)函數(shù)時(shí)同步聯(lián)想到調(diào)用關(guān)系。Cursor這類編輯器則更適合讓AI自主實(shí)現(xiàn)整個(gè)功能。Codex CLI之類則更像一個(gè)獨(dú)立的AI程序員你給它一個(gè)任務(wù)描述它會(huì)自己決定要?jiǎng)幽男┪募缓筮B續(xù)執(zhí)行一系列操作。AI短劇、AI視頻這類產(chǎn)品之所以能快速組裝出來很大程度上也依賴工具層的進(jìn)化。創(chuàng)作者不再需要手寫很多底層調(diào)用代碼AI編程工具能根據(jù)產(chǎn)品描述自動(dòng)生成整合方案。2.4 工程層跑起來只能算原型部署上線才算產(chǎn)品很多人在AI生成代碼后高興地截圖發(fā)動(dòng)態(tài)說“AI自己做出了一個(gè)應(yīng)用”但仔細(xì)一看應(yīng)用只在本機(jī)開發(fā)服務(wù)器上跑通。AI造AI真正要變成可靠生產(chǎn)力還差最關(guān)鍵的一步工程化部署。這個(gè)階段涉及AI基礎(chǔ)設(shè)施比如選擇容器鏡像、API網(wǎng)關(guān)配置、模型服務(wù)的訪問權(quán)限、數(shù)據(jù)庫連接池的參數(shù)調(diào)整。我在實(shí)踐過程中的經(jīng)驗(yàn)是AI Agent能夠處理大部分部署腳本的編寫但它對(duì)“生產(chǎn)環(huán)境特征”的感知天然較弱。如果你只告訴它“寫一個(gè)Dockerfile”它能寫得不錯(cuò)如果你告訴它“這是一個(gè)日活預(yù)計(jì)一萬人的服務(wù)需要考慮并發(fā)”它往往會(huì)忽略很多細(xì)節(jié)。AI應(yīng)用開發(fā)走到這里最需要的是人來定義質(zhì)量標(biāo)準(zhǔn)而不是來寫代碼。AI可以完成百分之七八十的編碼與部署腳本工作那百分之二十的邊界條件、安全防護(hù)、成本優(yōu)化才是決定一個(gè)AI應(yīng)用能否長期運(yùn)行的關(guān)鍵。3. 實(shí)操復(fù)盤讓AI完整搭一個(gè)AI應(yīng)用的七個(gè)步驟3.1 寫出能落地的項(xiàng)目規(guī)格書很多人在這一步就翻車。他們直接丟給AI一句話“幫我做一個(gè)AI短劇生成系統(tǒng)”然后期待它返回一個(gè)完整項(xiàng)目。這個(gè)粒度太粗了AI不是做不到而是最終產(chǎn)出的方向很容易失控。我把“需求規(guī)格書”壓縮到剛好可以讓AI理解用一兩段說明項(xiàng)目目的用列表標(biāo)清核心功能再寫清楚技術(shù)棧和驗(yàn)收標(biāo)準(zhǔn)。以下是實(shí)際用過的規(guī)格片段項(xiàng)目名稱AI短劇靈感工作臺(tái) 核心功能 1. 用戶輸入一個(gè)題材關(guān)鍵詞例如“重生、職場” 2. 系統(tǒng)調(diào)用大模型API生成片名、一句話亮點(diǎn)、分集梗概 3. 頁面顯示生成結(jié)果并提供“重新生成”按鈕 技術(shù)選型 后端使用 Python FastAPI前端使用簡單 HTMLJS不引入重型框架 驗(yàn)收標(biāo)準(zhǔn) 點(diǎn)擊生成后在5秒內(nèi)返回結(jié)果返回結(jié)構(gòu)包含title、logline、episodes三個(gè)字段把規(guī)格說清楚后AI Agent幾乎不會(huì)迷路。這一步也直接證明了“AI造AI”不是純自動(dòng)化人的判斷力和產(chǎn)品思維仍然是決定成敗的首要因素。3.2 讓AI先列出任務(wù)清單和文件結(jié)構(gòu)當(dāng)我把規(guī)格書交給AI Agent后它做的第一件事不是馬上寫代碼而是拆解目錄。它意識(shí)到需要后端啟動(dòng)文件、模型調(diào)用模塊、前端頁面、配置文件和部署腳本。這個(gè)拆解過程很值得觀察。如果AI只給你一個(gè)單文件解決方案往往意味著它打算用硬編碼糊弄你。能做出完整應(yīng)用的行為標(biāo)志是它主動(dòng)把“調(diào)用模型”“啟動(dòng)服務(wù)”“靜態(tài)頁面”拆成了不同模塊。我的做法是讓AI先把計(jì)劃寫在項(xiàng)目里的PLAN.md然后我再人工掃一眼有沒有明顯遺漏。這一步不耗時(shí)卻能在后續(xù)過程中減少很多無效改動(dòng)。3.3 核心模型調(diào)用代碼的實(shí)現(xiàn)“AI造AI”在代碼層面的核心是讓程序具備調(diào)用大模型的能力。這部分并不復(fù)雜卻是整個(gè)應(yīng)用能被稱為AI應(yīng)用的關(guān)鍵。以下是一個(gè)簡化版本演示Agent實(shí)際生成的代碼形態(tài)# llm_service.py import os from openai import OpenAI client OpenAI(api_keyos.getenv(LLM_API_KEY)) SYSTEM_PROMPT 你是一個(gè)短劇策劃助手只負(fù)責(zé)提供內(nèi)容創(chuàng)意。 請(qǐng)確保生成內(nèi)容符合主流價(jià)值觀拒絕輸出違規(guī)內(nèi)容。 def generate_script_idea(topic: str) - dict: user_prompt f用戶想做的短劇題材是{topic}。請(qǐng)返回一個(gè)可執(zhí)行的創(chuàng)意方案。 resp client.chat.completions.create( modelgpt-4.1-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.85, response_format{type: json_object}, ) return resp.choices[0].message.content可以看到這段代碼里沒有多少“黑魔法”但它包含了幾處關(guān)鍵工程決策使用環(huán)境變量保存密鑰、在系統(tǒng)提示詞里明確內(nèi)容邊界、要求模型返回可解析的JSON。這些是模型根據(jù)項(xiàng)目需求自動(dòng)做出來的還是我要求的有一部分是我在需求里提示的有一部分是它在常見實(shí)踐中總結(jié)出來的?；旌蠀f(xié)作往往能獲得最佳結(jié)果。3.4 把前端和串起來前端部分如果從零手寫會(huì)比較耗時(shí)。AI Agent的FastAPI后端實(shí)現(xiàn)好了之后會(huì)再自動(dòng)生成一個(gè)前端HTML頁面。界面的形式不復(fù)雜只有一個(gè)輸入框和展示區(qū)域但這個(gè)過程展示了AI造AI的另一個(gè)能力它能把后端接口與前端頁面正確連接。連接是AI編程新手最容易卡住的地方因?yàn)榍岸撕秃蠖耸莾蓚€(gè)不同世界。后端返回的數(shù)據(jù)結(jié)構(gòu)稍微變了前端就可能渲染不出來。我在實(shí)踐里發(fā)現(xiàn)AI Agent在單次迭代中很少同時(shí)修好兩邊它更傾向于先改后端再回頭改前端。這提醒我遇到跨端問題時(shí)要把“先理清接口契約再改代碼”的指令寫清楚。3.5 配置API密鑰與環(huán)境變量一個(gè)應(yīng)用需要訪問大模型API密鑰管理不交給AI自由發(fā)揮。規(guī)格書要求AI生成.env.example文件然后在本地測(cè)試時(shí)由我自己配置真實(shí)變量。AI會(huì)負(fù)責(zé)任地在代碼里通過os.getenv讀取環(huán)境變量而不是硬編碼。這一步其實(shí)暗含訓(xùn)練時(shí)的安全意識(shí)。AI知道API密鑰不能提交到Git倉庫也知道真實(shí)密鑰要放在不會(huì)被版本管理工具追蹤的文件里。如果Agent在代碼中把密鑰寫死了我會(huì)在審查階段直接糾正。3.6 運(yùn)行與自動(dòng)化測(cè)試測(cè)試環(huán)節(jié)是AI迭代效率的分水嶺。我在讓Agent寫完功能后要求它運(yùn)行一個(gè)自動(dòng)測(cè)試腳本。第一輪測(cè)試通常不會(huì)順利通過可能是缺依賴可能是端口問題也可能是API響應(yīng)結(jié)構(gòu)不符預(yù)期Agent會(huì)抓取終端輸出看完報(bào)錯(cuò)再自己修改。例如有一次前端拿到的是字符串而不是JSON頁面渲染直接失敗。AI Agent讀取報(bào)錯(cuò)后自己補(bǔ)了一行響應(yīng)格式驗(yàn)證并在前端解析前增加了一個(gè)類型判斷。這種調(diào)試能力比寫新功能更讓人驚訝。沒有跑過真實(shí)項(xiàng)目的AI很難產(chǎn)生這種反饋閉環(huán)一旦進(jìn)入“寫代碼→跑測(cè)試→看報(bào)錯(cuò)→修代碼”的循環(huán)AI的進(jìn)步速度會(huì)快得多。使用AI自動(dòng)化測(cè)試的場景很適合用來衡量一個(gè)模型好不好因?yàn)樗竽Ｐ筒恢皇恰吧伞倍且斫馐≡颉：芏嗨^“能寫代碼”的模型在這一步會(huì)原形畢露。3.7 部署到服務(wù)器本地跑通后我把同一個(gè)項(xiàng)目目錄交給Agent完成服務(wù)部署構(gòu)建一個(gè)簡單的Docker鏡像設(shè)置環(huán)境變量暴露端口。下面的文件就是Agent生成的部署配置示例FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8080]生成這樣的部署配置并不難真正要注意的是Agent不會(huì)主動(dòng)想到云服務(wù)器的網(wǎng)絡(luò)策略、HTTPS證書、日志收集。在真實(shí)部署環(huán)節(jié)我還是自己手動(dòng)補(bǔ)了域名的反向代理配置。這不是AI不行而是它當(dāng)前還缺少對(duì)線上環(huán)境狀態(tài)的感知。把它造出來的AI應(yīng)用放到公網(wǎng)后你會(huì)更清醒地看到它在“創(chuàng)造”與“工程化落地”之間的距離。4. AI自主編程時(shí)最容易踩的坑4.1 問題速查表我在兩周實(shí)驗(yàn)里遇到了不少問題整理成下表方便在做“AI造AI”實(shí)驗(yàn)時(shí)直接對(duì)照。常見現(xiàn)象排查方向有效對(duì)策Agent重復(fù)修改某個(gè)文件但問題沒解決上下文里缺少真實(shí)報(bào)錯(cuò)信息把完整終端報(bào)錯(cuò)復(fù)制進(jìn)對(duì)話而不是只問“怎么改”Agent寫出的代碼和已安裝SDK版本不匹配它依賴的訓(xùn)練數(shù)據(jù)可能有滯后讓Agent先執(zhí)行版本查看命令再寫依賴相關(guān)內(nèi)容前后端數(shù)據(jù)對(duì)不上接口契約沒有明確定義在規(guī)格里寫清楚JSON字段名與類型AI陷入無限循環(huán)不停改同一處缺少終止條件給它明確的“最多嘗試5輪如果仍失敗則報(bào)告”指令生成結(jié)果包含危險(xiǎn)或不當(dāng)內(nèi)容提示缺少系統(tǒng)級(jí)安全約束在提示詞和代碼邏輯中加入必要的過濾與拒絕策略Agent把生產(chǎn)環(huán)境需要的配置遺漏了AI不掌握線上環(huán)境狀態(tài)需要人工補(bǔ)充基礎(chǔ)設(shè)施層內(nèi)容改了一個(gè)模塊導(dǎo)致另一個(gè)模塊報(bào)錯(cuò)缺少回歸驗(yàn)證要求每次改動(dòng)后都運(yùn)行一次完整測(cè)試4.2 最值得留意的三個(gè)認(rèn)知第一個(gè)認(rèn)知AI Agent不是全知全能的。它會(huì)基于訓(xùn)練數(shù)據(jù)中的“記憶”來猜測(cè)API行為而不是每次去查最新文檔。如果你讓AI寫一個(gè)非常新的SDK調(diào)用最好先讓它去讀一下當(dāng)前項(xiàng)目的庫文件或者把官方文檔鏈接放進(jìn)去。第二個(gè)認(rèn)知AI在長任務(wù)中會(huì)產(chǎn)生“上下文漂移”。項(xiàng)目剛開始時(shí)它清楚目標(biāo)做到第30步后它可能會(huì)遺忘最初的設(shè)計(jì)約束開始自由發(fā)揮。對(duì)抗方法很簡單把驗(yàn)收標(biāo)準(zhǔn)寫進(jìn)項(xiàng)目根目錄的README.mdAgent每做一輪改動(dòng)前會(huì)讓它重新讀一遍規(guī)格。第三個(gè)認(rèn)知AI生成的應(yīng)用必須安裝內(nèi)容安全機(jī)制。既然標(biāo)題說的是AI造AI應(yīng)用那就必須牢記由大模型驅(qū)動(dòng)的應(yīng)用一定要在提示詞層、輸出校驗(yàn)層同時(shí)設(shè)置控制點(diǎn)。用系統(tǒng)提示詞約束生成方向用戶輸入側(cè)過濾異常內(nèi)容輸出側(cè)再做一次校驗(yàn)。這不是額外的技術(shù)負(fù)擔(dān)而是AI工程實(shí)踐的基本盤。一個(gè)只想著“什么都能生成”的AI應(yīng)用最后一定會(huì)在體驗(yàn)、合規(guī)和口碑上接連翻車。4.3 我堅(jiān)持做的三層檢查為了不讓AI在無人看守的情況下把代碼庫改亂我建立了三層檢查機(jī)制。第一層是每次讓Agent執(zhí)行大改動(dòng)前強(qiáng)制它在項(xiàng)目里先生成一份CHANGELOG.md記錄這次改動(dòng)的目的。這個(gè)文件是給人看的能讓Agent在第二天繼續(xù)工作時(shí)快速回憶起昨天為什么這樣改。第二層是讓Agent運(yùn)行單測(cè)與構(gòu)建命令提供終端真實(shí)日志。我不接受“我覺得沒問題”這樣的表述。AI模型和人類程序員一樣有時(shí)會(huì)高估自己代碼的可用性以運(yùn)行結(jié)果為唯一標(biāo)準(zhǔn)能篩掉很多幻覺。第三層是權(quán)限收斂。我從不把服務(wù)器的生產(chǎn)數(shù)據(jù)庫密碼直接放進(jìn)環(huán)境變量表里給Agent使用。在開發(fā)和測(cè)試階段使用單獨(dú)賬號(hào)在部署時(shí)才切換到最小權(quán)限的生產(chǎn)賬號(hào)。AI確實(shí)能自己造AI但邊界管理還是要人來制定。5. AI造AI的價(jià)值不是取代而是放大人的判斷力回到最初的問題AI到底能不能自己造AI答案是能但它的“能”不是指完全不需要人。我做了一款微型AI應(yīng)用也觀察了AI Agent完整經(jīng)歷需求拆分、編碼、調(diào)試、部署的全過程。整個(gè)工程讓我最明顯的感受是AI的自主能力并不可怕真正稀缺的是“能提出好問題、能寫清邊界條件、能判斷交付質(zhì)量”的人?，F(xiàn)在“AI造AI”在開發(fā)領(lǐng)域愈發(fā)像一種常態(tài)化的AI工程實(shí)踐。過去一個(gè)懂點(diǎn)大模型API的人要搭建一款可用的AI產(chǎn)品至少得花兩周去處理前后端代碼、環(huán)境配置、接口調(diào)試今天在Agent的輔助下這個(gè)過程我壓縮到一天左右。剩下時(shí)間全部用來思考產(chǎn)品方向、數(shù)據(jù)安全、用戶體驗(yàn)與成本控制。如果你也想復(fù)現(xiàn)這個(gè)鏈路我給三條來自實(shí)際操作的提醒第一項(xiàng)目最開始的需求說明一定要具體寧可多花十分鐘把驗(yàn)收標(biāo)準(zhǔn)寫清楚也不要給AI模糊的方向第二不要一開始就讓Agent同時(shí)碰多個(gè)大模塊先從最小可跑通版本開始成功后再逐步擴(kuò)展第三要把AI生成的每一次改動(dòng)都當(dāng)作代碼評(píng)審對(duì)象它寫得快不代表它每一條決定都合理?！皠e吵了有人做出來了”背后真正值得關(guān)注的不是噱頭而是一條正在被反復(fù)驗(yàn)證的路徑AI不是自己獨(dú)立長出來的它是在一套經(jīng)過設(shè)計(jì)的流程里被另一個(gè)“造物主提示詞”一支支點(diǎn)燃的。過去這要求你懂模型、懂框架、懂部署現(xiàn)在它更要求你懂邊界、懂流程、懂取舍。這才是AI造AI這件事最有趣的地方。 AI造AI實(shí)戰(zhàn)：從需求規(guī)格到云上部署，AI編程Agent全鏈路復(fù)現(xiàn)
這條標(biāo)題在社區(qū)里刷屏的時(shí)候我一開始沒當(dāng)回事想著無非又是一輪“AI取代程序員”的情緒化宣泄。直到我自己連續(xù)兩周用 AI 編程 Agent 去做 AI 應(yīng)用的落地實(shí)驗(yàn)才發(fā)現(xiàn)問題真正值得回答只是需要先把“自己”和“造”這兩個(gè)詞拆開——?jiǎng)e再抬杠。先說結(jié)論AI確實(shí)能造出一個(gè)新的AI應(yīng)用。代碼、接口、頁面、部署腳本大部分可以交由大模型和AI智能體完成但這不意味著人可以直接躺平。你能看到的所有“AI自己造AI”的真實(shí)樣本背后都有一份清晰得近乎產(chǎn)品說明書式的需求邊界以及一個(gè)人在旁邊做糾偏。別急著爭論“到底算不算”直接看機(jī)制、看流程、看坑會(huì)比站隊(duì)有用得多。下面我按“技術(shù)拆解 → 逐層實(shí)現(xiàn) → 實(shí)戰(zhàn)復(fù)盤 → 問題排查”的順序把我實(shí)際跑通的一條AI造AI鏈路完整記錄下來。1. AI能不能自己造AI先別急著回答1.1 先落定義這里說的“造AI”到底是什么很多討論到最后變成吵架是因?yàn)殡p方對(duì)“AI自己造AI”的定義完全不一樣。有人期待的是像科幻電影里那樣一個(gè)系統(tǒng)在機(jī)房里憑空覺醒然后自己設(shè)計(jì)下一代模型有人期待的是只要對(duì)著對(duì)話窗口說一句“幫我做個(gè)AI產(chǎn)品”一個(gè)完整應(yīng)用就能自動(dòng)交付。這兩個(gè)理解放在今天都不現(xiàn)實(shí)也不必要。行業(yè)內(nèi)真正在發(fā)生的“AI造AI”指的是大模型生成另外一個(gè)AI應(yīng)用的代碼并且讓它跑起來。舉個(gè)更具體的例子我讓一個(gè)AI編程Agent去構(gòu)建一個(gè)“AI短劇靈感工作臺(tái)”這個(gè)工作臺(tái)本身要調(diào)用大模型API來完成劇情創(chuàng)意生成。也就是說AI既負(fù)責(zé)編寫應(yīng)用代碼又負(fù)責(zé)讓這個(gè)應(yīng)用具備理解用戶輸入并生成內(nèi)容的能力。前者是普通軟件開發(fā)后者是AI能力接入當(dāng)一個(gè)AI Agent能把兩件事同時(shí)做完并交付一個(gè)能直接使用的成品時(shí)它在工程意義上就已經(jīng)完成了一次“自己造自己同類產(chǎn)品”的循環(huán)。所以如果你問“AI能不能造AI”我的回答是能但這里的“造”更接近“從無到有搭建一套可運(yùn)行的AI應(yīng)用”而不是“無中生有創(chuàng)造一個(gè)完整的新模型”。1.2 已經(jīng)跑通的樣本有哪些從2024年下半年到2025年我能親眼驗(yàn)證的“AI造AI”案例已經(jīng)不少而且不是那種只截一張代碼截圖就完事的演示。我自己的實(shí)踐是在Cursor AI編程工具里把項(xiàng)目需求、技術(shù)棧、驗(yàn)收標(biāo)準(zhǔn)寫成一段結(jié)構(gòu)化說明然后讓AI Agent去完成完整建模。它產(chǎn)出的東西包括一個(gè)后端服務(wù)、一個(gè)簡單前端頁面、數(shù)據(jù)庫初始化腳本、部署配置。后端不是那種“Hello World”級(jí)別的空殼而是真的接入了大模型API、帶有提示詞模板、能根據(jù)用戶輸入流式返回結(jié)果。整個(gè)過程里代碼修改工作量的九成是由AI完成的我做的就是拆需求、看輸出、跑測(cè)試、發(fā)現(xiàn)問題后把它丟回給Agent 繼續(xù)改。公開開源社區(qū)里也有類似現(xiàn)象。不少人用Codex CLI、Cline、Aider這些工具從一份GitHub倉庫開始依靠AI Agent自動(dòng)完成功能追加、bug修復(fù)和測(cè)試補(bǔ)充最后合并進(jìn)主分支。這些任務(wù)不再是“寫幾行代碼讓你抄”而是經(jīng)歷“讀代碼→改代碼→跑測(cè)試→根據(jù)報(bào)錯(cuò)再改→再跑”的完整工程循環(huán)。媒體上經(jīng)常提到的AI編程能力目前已經(jīng)不只是補(bǔ)全一段代碼而是能自主理解一個(gè)多文件項(xiàng)目結(jié)構(gòu)甚至在任務(wù)過程中自己更新技術(shù)方案。很多質(zhì)疑者還停留在“AI只能生成片段”的認(rèn)知階段但真實(shí)項(xiàng)目的復(fù)盤已經(jīng)證明AI不只會(huì)寫還會(huì)自己驗(yàn)證、自己修錯(cuò)、自己把多個(gè)模塊粘起來。2. “AI自己造AI”依賴的整套技術(shù)棧2.1 模型層代碼智能的上限來自這里如果讓AI去造一個(gè)AI應(yīng)用它的第一個(gè)依賴是底層大模型的代碼理解能力。模型需要能讀懂一個(gè)目錄下幾十個(gè)文件之間的關(guān)系知道哪里的函數(shù)被誰調(diào)用知道給前端返回什么結(jié)構(gòu)的JSON。這看起來基礎(chǔ)實(shí)際上非常考驗(yàn)?zāi)Ｐ偷纳舷挛奶幚砼c推理能力。在實(shí)踐里代碼能力不足的模型會(huì)帶來災(zāi)難性體驗(yàn)。它可能寫出一段看起來邏輯自洽、但實(shí)際無法運(yùn)行的代碼或者在依賴版本上胡說八道。好的模型能減少無效迭代次數(shù)。比如同樣是生成一個(gè)調(diào)用大模型API的Python后端好的模型會(huì)先確認(rèn)SDK版本再寫調(diào)用邏輯最后把異常處理也補(bǔ)上差的模型只會(huì)按記憶里的過期示例輸出等你去踩坑。2.2 Agent層讓大模型從“出主意”變成“干活”大模型本身不會(huì)操作電腦不會(huì)新增文件不會(huì)運(yùn)行測(cè)試。真正把“AI造AI”從可能變成現(xiàn)實(shí)的是AI Agent這一層。AI智能體的工作機(jī)制很像一個(gè)外包團(tuán)隊(duì)它把一個(gè)大任務(wù)拆成小步驟然后逐步執(zhí)行每一步。在AI造AI的場景里Agent需要完成這些動(dòng)作閱讀項(xiàng)目目錄理解現(xiàn)有代碼結(jié)構(gòu)在指定位置創(chuàng)建、修改源文件執(zhí)行命令行命令比如安裝依賴、運(yùn)行測(cè)試查看運(yùn)行結(jié)果根據(jù)報(bào)錯(cuò)信息調(diào)整代碼反復(fù)循環(huán)直到符合驗(yàn)收條件這個(gè)循環(huán)不需要人時(shí)刻盯著但需要保證每個(gè)步驟之間能串聯(lián)起來。讓Agent理解上下文比讓它寫代碼更難因?yàn)橹灰舷挛睦锷倭艘粋€(gè)關(guān)鍵信息它就可能把文件路徑改錯(cuò)或者反復(fù)使用一個(gè)不存在的函數(shù)。2.3 工具層AI編程插件和IDE把意圖變成文件改動(dòng)沒有工具層的配合模型再強(qiáng)也施展不開。我常用的組合是Cursor AI編程工具負(fù)責(zé)多文件級(jí)別的代碼生成與重構(gòu)IDEA系插件負(fù)責(zé)局部代碼補(bǔ)全和審查再用Codex CLI處理那些需要獨(dú)立終端環(huán)境的自動(dòng)化任務(wù)。這三者的分工很有趣。IDE插件更適合“人在回路”的微調(diào)式開發(fā)它不會(huì)替你做架構(gòu)級(jí)改動(dòng)但能在你修改一個(gè)函數(shù)時(shí)同步聯(lián)想到調(diào)用關(guān)系。Cursor這類編輯器則更適合讓AI自主實(shí)現(xiàn)整個(gè)功能。Codex CLI之類則更像一個(gè)獨(dú)立的AI程序員你給它一個(gè)任務(wù)描述它會(huì)自己決定要?jiǎng)幽男┪募缓筮B續(xù)執(zhí)行一系列操作。AI短劇、AI視頻這類產(chǎn)品之所以能快速組裝出來很大程度上也依賴工具層的進(jìn)化。創(chuàng)作者不再需要手寫很多底層調(diào)用代碼AI編程工具能根據(jù)產(chǎn)品描述自動(dòng)生成整合方案。2.4 工程層跑起來只能算原型部署上線才算產(chǎn)品很多人在AI生成代碼后高興地截圖發(fā)動(dòng)態(tài)說“AI自己做出了一個(gè)應(yīng)用”但仔細(xì)一看應(yīng)用只在本機(jī)開發(fā)服務(wù)器上跑通。AI造AI真正要變成可靠生產(chǎn)力還差最關(guān)鍵的一步工程化部署。這個(gè)階段涉及AI基礎(chǔ)設(shè)施比如選擇容器鏡像、API網(wǎng)關(guān)配置、模型服務(wù)的訪問權(quán)限、數(shù)據(jù)庫連接池的參數(shù)調(diào)整。我在實(shí)踐過程中的經(jīng)驗(yàn)是AI Agent能夠處理大部分部署腳本的編寫但它對(duì)“生產(chǎn)環(huán)境特征”的感知天然較弱。如果你只告訴它“寫一個(gè)Dockerfile”它能寫得不錯(cuò)如果你告訴它“這是一個(gè)日活預(yù)計(jì)一萬人的服務(wù)需要考慮并發(fā)”它往往會(huì)忽略很多細(xì)節(jié)。AI應(yīng)用開發(fā)走到這里最需要的是人來定義質(zhì)量標(biāo)準(zhǔn)而不是來寫代碼。AI可以完成百分之七八十的編碼與部署腳本工作那百分之二十的邊界條件、安全防護(hù)、成本優(yōu)化才是決定一個(gè)AI應(yīng)用能否長期運(yùn)行的關(guān)鍵。3. 實(shí)操復(fù)盤讓AI完整搭一個(gè)AI應(yīng)用的七個(gè)步驟3.1 寫出能落地的項(xiàng)目規(guī)格書很多人在這一步就翻車。他們直接丟給AI一句話“幫我做一個(gè)AI短劇生成系統(tǒng)”然后期待它返回一個(gè)完整項(xiàng)目。這個(gè)粒度太粗了AI不是做不到而是最終產(chǎn)出的方向很容易失控。我把“需求規(guī)格書”壓縮到剛好可以讓AI理解用一兩段說明項(xiàng)目目的用列表標(biāo)清核心功能再寫清楚技術(shù)棧和驗(yàn)收標(biāo)準(zhǔn)。以下是實(shí)際用過的規(guī)格片段項(xiàng)目名稱AI短劇靈感工作臺(tái) 核心功能 1. 用戶輸入一個(gè)題材關(guān)鍵詞例如“重生、職場” 2. 系統(tǒng)調(diào)用大模型API生成片名、一句話亮點(diǎn)、分集梗概 3. 頁面顯示生成結(jié)果并提供“重新生成”按鈕 技術(shù)選型 后端使用 Python FastAPI前端使用簡單 HTMLJS不引入重型框架 驗(yàn)收標(biāo)準(zhǔn) 點(diǎn)擊生成后在5秒內(nèi)返回結(jié)果返回結(jié)構(gòu)包含title、logline、episodes三個(gè)字段把規(guī)格說清楚后AI Agent幾乎不會(huì)迷路。這一步也直接證明了“AI造AI”不是純自動(dòng)化人的判斷力和產(chǎn)品思維仍然是決定成敗的首要因素。3.2 讓AI先列出任務(wù)清單和文件結(jié)構(gòu)當(dāng)我把規(guī)格書交給AI Agent后它做的第一件事不是馬上寫代碼而是拆解目錄。它意識(shí)到需要后端啟動(dòng)文件、模型調(diào)用模塊、前端頁面、配置文件和部署腳本。這個(gè)拆解過程很值得觀察。如果AI只給你一個(gè)單文件解決方案往往意味著它打算用硬編碼糊弄你。能做出完整應(yīng)用的行為標(biāo)志是它主動(dòng)把“調(diào)用模型”“啟動(dòng)服務(wù)”“靜態(tài)頁面”拆成了不同模塊。我的做法是讓AI先把計(jì)劃寫在項(xiàng)目里的PLAN.md然后我再人工掃一眼有沒有明顯遺漏。這一步不耗時(shí)卻能在后續(xù)過程中減少很多無效改動(dòng)。3.3 核心模型調(diào)用代碼的實(shí)現(xiàn)“AI造AI”在代碼層面的核心是讓程序具備調(diào)用大模型的能力。這部分并不復(fù)雜卻是整個(gè)應(yīng)用能被稱為AI應(yīng)用的關(guān)鍵。以下是一個(gè)簡化版本演示Agent實(shí)際生成的代碼形態(tài)# llm_service.py import os from openai import OpenAI client OpenAI(api_keyos.getenv(LLM_API_KEY)) SYSTEM_PROMPT 你是一個(gè)短劇策劃助手只負(fù)責(zé)提供內(nèi)容創(chuàng)意。 請(qǐng)確保生成內(nèi)容符合主流價(jià)值觀拒絕輸出違規(guī)內(nèi)容。 def generate_script_idea(topic: str) - dict: user_prompt f用戶想做的短劇題材是{topic}。請(qǐng)返回一個(gè)可執(zhí)行的創(chuàng)意方案。 resp client.chat.completions.create( modelgpt-4.1-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.85, response_format{type: json_object}, ) return resp.choices[0].message.content可以看到這段代碼里沒有多少“黑魔法”但它包含了幾處關(guān)鍵工程決策使用環(huán)境變量保存密鑰、在系統(tǒng)提示詞里明確內(nèi)容邊界、要求模型返回可解析的JSON。這些是模型根據(jù)項(xiàng)目需求自動(dòng)做出來的還是我要求的有一部分是我在需求里提示的有一部分是它在常見實(shí)踐中總結(jié)出來的?；旌蠀f(xié)作往往能獲得最佳結(jié)果。3.4 把前端和串起來前端部分如果從零手寫會(huì)比較耗時(shí)。AI Agent的FastAPI后端實(shí)現(xiàn)好了之后會(huì)再自動(dòng)生成一個(gè)前端HTML頁面。界面的形式不復(fù)雜只有一個(gè)輸入框和展示區(qū)域但這個(gè)過程展示了AI造AI的另一個(gè)能力它能把后端接口與前端頁面正確連接。連接是AI編程新手最容易卡住的地方因?yàn)榍岸撕秃蠖耸莾蓚€(gè)不同世界。后端返回的數(shù)據(jù)結(jié)構(gòu)稍微變了前端就可能渲染不出來。我在實(shí)踐里發(fā)現(xiàn)AI Agent在單次迭代中很少同時(shí)修好兩邊它更傾向于先改后端再回頭改前端。這提醒我遇到跨端問題時(shí)要把“先理清接口契約再改代碼”的指令寫清楚。3.5 配置API密鑰與環(huán)境變量一個(gè)應(yīng)用需要訪問大模型API密鑰管理不交給AI自由發(fā)揮。規(guī)格書要求AI生成.env.example文件然后在本地測(cè)試時(shí)由我自己配置真實(shí)變量。AI會(huì)負(fù)責(zé)任地在代碼里通過os.getenv讀取環(huán)境變量而不是硬編碼。這一步其實(shí)暗含訓(xùn)練時(shí)的安全意識(shí)。AI知道API密鑰不能提交到Git倉庫也知道真實(shí)密鑰要放在不會(huì)被版本管理工具追蹤的文件里。如果Agent在代碼中把密鑰寫死了我會(huì)在審查階段直接糾正。3.6 運(yùn)行與自動(dòng)化測(cè)試測(cè)試環(huán)節(jié)是AI迭代效率的分水嶺。我在讓Agent寫完功能后要求它運(yùn)行一個(gè)自動(dòng)測(cè)試腳本。第一輪測(cè)試通常不會(huì)順利通過可能是缺依賴可能是端口問題也可能是API響應(yīng)結(jié)構(gòu)不符預(yù)期Agent會(huì)抓取終端輸出看完報(bào)錯(cuò)再自己修改。例如有一次前端拿到的是字符串而不是JSON頁面渲染直接失敗。AI Agent讀取報(bào)錯(cuò)后自己補(bǔ)了一行響應(yīng)格式驗(yàn)證并在前端解析前增加了一個(gè)類型判斷。這種調(diào)試能力比寫新功能更讓人驚訝。沒有跑過真實(shí)項(xiàng)目的AI很難產(chǎn)生這種反饋閉環(huán)一旦進(jìn)入“寫代碼→跑測(cè)試→看報(bào)錯(cuò)→修代碼”的循環(huán)AI的進(jìn)步速度會(huì)快得多。使用AI自動(dòng)化測(cè)試的場景很適合用來衡量一個(gè)模型好不好因?yàn)樗竽Ｐ筒恢皇恰吧伞倍且斫馐≡颉：芏嗨^“能寫代碼”的模型在這一步會(huì)原形畢露。3.7 部署到服務(wù)器本地跑通后我把同一個(gè)項(xiàng)目目錄交給Agent完成服務(wù)部署構(gòu)建一個(gè)簡單的Docker鏡像設(shè)置環(huán)境變量暴露端口。下面的文件就是Agent生成的部署配置示例FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8080]生成這樣的部署配置并不難真正要注意的是Agent不會(huì)主動(dòng)想到云服務(wù)器的網(wǎng)絡(luò)策略、HTTPS證書、日志收集。在真實(shí)部署環(huán)節(jié)我還是自己手動(dòng)補(bǔ)了域名的反向代理配置。這不是AI不行而是它當(dāng)前還缺少對(duì)線上環(huán)境狀態(tài)的感知。把它造出來的AI應(yīng)用放到公網(wǎng)后你會(huì)更清醒地看到它在“創(chuàng)造”與“工程化落地”之間的距離。4. AI自主編程時(shí)最容易踩的坑4.1 問題速查表我在兩周實(shí)驗(yàn)里遇到了不少問題整理成下表方便在做“AI造AI”實(shí)驗(yàn)時(shí)直接對(duì)照。常見現(xiàn)象排查方向有效對(duì)策Agent重復(fù)修改某個(gè)文件但問題沒解決上下文里缺少真實(shí)報(bào)錯(cuò)信息把完整終端報(bào)錯(cuò)復(fù)制進(jìn)對(duì)話而不是只問“怎么改”Agent寫出的代碼和已安裝SDK版本不匹配它依賴的訓(xùn)練數(shù)據(jù)可能有滯后讓Agent先執(zhí)行版本查看命令再寫依賴相關(guān)內(nèi)容前后端數(shù)據(jù)對(duì)不上接口契約沒有明確定義在規(guī)格里寫清楚JSON字段名與類型AI陷入無限循環(huán)不停改同一處缺少終止條件給它明確的“最多嘗試5輪如果仍失敗則報(bào)告”指令生成結(jié)果包含危險(xiǎn)或不當(dāng)內(nèi)容提示缺少系統(tǒng)級(jí)安全約束在提示詞和代碼邏輯中加入必要的過濾與拒絕策略Agent把生產(chǎn)環(huán)境需要的配置遺漏了AI不掌握線上環(huán)境狀態(tài)需要人工補(bǔ)充基礎(chǔ)設(shè)施層內(nèi)容改了一個(gè)模塊導(dǎo)致另一個(gè)模塊報(bào)錯(cuò)缺少回歸驗(yàn)證要求每次改動(dòng)后都運(yùn)行一次完整測(cè)試4.2 最值得留意的三個(gè)認(rèn)知第一個(gè)認(rèn)知AI Agent不是全知全能的。它會(huì)基于訓(xùn)練數(shù)據(jù)中的“記憶”來猜測(cè)API行為而不是每次去查最新文檔。如果你讓AI寫一個(gè)非常新的SDK調(diào)用最好先讓它去讀一下當(dāng)前項(xiàng)目的庫文件或者把官方文檔鏈接放進(jìn)去。第二個(gè)認(rèn)知AI在長任務(wù)中會(huì)產(chǎn)生“上下文漂移”。項(xiàng)目剛開始時(shí)它清楚目標(biāo)做到第30步后它可能會(huì)遺忘最初的設(shè)計(jì)約束開始自由發(fā)揮。對(duì)抗方法很簡單把驗(yàn)收標(biāo)準(zhǔn)寫進(jìn)項(xiàng)目根目錄的README.mdAgent每做一輪改動(dòng)前會(huì)讓它重新讀一遍規(guī)格。第三個(gè)認(rèn)知AI生成的應(yīng)用必須安裝內(nèi)容安全機(jī)制。既然標(biāo)題說的是AI造AI應(yīng)用那就必須牢記由大模型驅(qū)動(dòng)的應(yīng)用一定要在提示詞層、輸出校驗(yàn)層同時(shí)設(shè)置控制點(diǎn)。用系統(tǒng)提示詞約束生成方向用戶輸入側(cè)過濾異常內(nèi)容輸出側(cè)再做一次校驗(yàn)。這不是額外的技術(shù)負(fù)擔(dān)而是AI工程實(shí)踐的基本盤。一個(gè)只想著“什么都能生成”的AI應(yīng)用最后一定會(huì)在體驗(yàn)、合規(guī)和口碑上接連翻車。4.3 我堅(jiān)持做的三層檢查為了不讓AI在無人看守的情況下把代碼庫改亂我建立了三層檢查機(jī)制。第一層是每次讓Agent執(zhí)行大改動(dòng)前強(qiáng)制它在項(xiàng)目里先生成一份CHANGELOG.md記錄這次改動(dòng)的目的。這個(gè)文件是給人看的能讓Agent在第二天繼續(xù)工作時(shí)快速回憶起昨天為什么這樣改。第二層是讓Agent運(yùn)行單測(cè)與構(gòu)建命令提供終端真實(shí)日志。我不接受“我覺得沒問題”這樣的表述。AI模型和人類程序員一樣有時(shí)會(huì)高估自己代碼的可用性以運(yùn)行結(jié)果為唯一標(biāo)準(zhǔn)能篩掉很多幻覺。第三層是權(quán)限收斂。我從不把服務(wù)器的生產(chǎn)數(shù)據(jù)庫密碼直接放進(jìn)環(huán)境變量表里給Agent使用。在開發(fā)和測(cè)試階段使用單獨(dú)賬號(hào)在部署時(shí)才切換到最小權(quán)限的生產(chǎn)賬號(hào)。AI確實(shí)能自己造AI但邊界管理還是要人來制定。5. AI造AI的價(jià)值不是取代而是放大人的判斷力回到最初的問題AI到底能不能自己造AI答案是能但它的“能”不是指完全不需要人。我做了一款微型AI應(yīng)用也觀察了AI Agent完整經(jīng)歷需求拆分、編碼、調(diào)試、部署的全過程。整個(gè)工程讓我最明顯的感受是AI的自主能力并不可怕真正稀缺的是“能提出好問題、能寫清邊界條件、能判斷交付質(zhì)量”的人?，F(xiàn)在“AI造AI”在開發(fā)領(lǐng)域愈發(fā)像一種常態(tài)化的AI工程實(shí)踐。過去一個(gè)懂點(diǎn)大模型API的人要搭建一款可用的AI產(chǎn)品至少得花兩周去處理前后端代碼、環(huán)境配置、接口調(diào)試今天在Agent的輔助下這個(gè)過程我壓縮到一天左右。剩下時(shí)間全部用來思考產(chǎn)品方向、數(shù)據(jù)安全、用戶體驗(yàn)與成本控制。如果你也想復(fù)現(xiàn)這個(gè)鏈路我給三條來自實(shí)際操作的提醒第一項(xiàng)目最開始的需求說明一定要具體寧可多花十分鐘把驗(yàn)收標(biāo)準(zhǔn)寫清楚也不要給AI模糊的方向第二不要一開始就讓Agent同時(shí)碰多個(gè)大模塊先從最小可跑通版本開始成功后再逐步擴(kuò)展第三要把AI生成的每一次改動(dòng)都當(dāng)作代碼評(píng)審對(duì)象它寫得快不代表它每一條決定都合理?！皠e吵了有人做出來了”背后真正值得關(guān)注的不是噱頭而是一條正在被反復(fù)驗(yàn)證的路徑AI不是自己獨(dú)立長出來的它是在一套經(jīng)過設(shè)計(jì)的流程里被另一個(gè)“造物主提示詞”一支支點(diǎn)燃的。過去這要求你懂模型、懂框架、懂部署現(xiàn)在它更要求你懂邊界、懂流程、懂取舍。這才是AI造AI這件事最有趣的地方。