如果最近有一部電影能同時(shí)讓 IT 圈的人和公司管理者坐進(jìn)同一個(gè)放映廳那大概是《奧德賽》。很多人的關(guān)注點(diǎn)并不在于劇情本身而在于一個(gè)反復(fù)出現(xiàn)的隱喻AI 已經(jīng)能生成一個(gè)又一個(gè)逼真的世界但那個(gè)世界是否真正遵循某種物理法則、社會(huì)規(guī)則和因果鏈條你從畫(huà)面上一眼看不出差距。這個(gè)隱喻放在軟件開(kāi)發(fā)里幾乎一模一樣。過(guò)去兩年AI 編程工具的進(jìn)步速度快到讓人眩暈給一段需求描述一次回車(chē)頁(yè)面能生成接口能生成數(shù)據(jù)庫(kù)表能生成連 Dockerfile 都能順手補(bǔ)齊。于是很多團(tuán)隊(duì)開(kāi)始興奮地討論“程序員是不是要被替代了”。可真正在企業(yè)系統(tǒng)里試過(guò)一遍的人往往會(huì)遇到另一種困惑AI 生成的代碼確實(shí)快但系統(tǒng)里真正負(fù)責(zé)“企業(yè)真實(shí)世界”的那部分反而變得很難推進(jìn)——不是寫(xiě)不出來(lái)而是不知道該怎么定義。這篇文章想回答一個(gè)問(wèn)題為什么 AI 可以快速搭建軟件卻搭不出企業(yè)的真實(shí)世界以及當(dāng)我們接受這個(gè)邊界之后到底應(yīng)該怎么用 AI 開(kāi)發(fā)軟件才能既享受速度又不丟掉企業(yè)系統(tǒng)最需要的確定性。文章不會(huì)只停留在觀點(diǎn)層面我會(huì)用一個(gè)采購(gòu)訂單模塊的最小案例把“代碼能跑”和“業(yè)務(wù)正確”之間的差距拆開(kāi)來(lái)看再給出一條適合團(tuán)隊(duì)落地的實(shí)踐路徑。這篇文章真正要解決的問(wèn)題先說(shuō)結(jié)論AI 擅長(zhǎng)的是把“已經(jīng)定義清楚的需求”快速翻譯成代碼但它不擅長(zhǎng)定義需求本身。企業(yè)軟件之所以復(fù)雜不是因?yàn)榇a量大而是因?yàn)闃I(yè)務(wù)規(guī)則藏在組織流程、歷史數(shù)據(jù)、合規(guī)要求和人的決策習(xí)慣里。很多團(tuán)隊(duì)在引入 AI 開(kāi)發(fā)工具時(shí)真正遇到的不是“代碼質(zhì)量問(wèn)題”而是“上下文缺失問(wèn)題”。AI 可以生成一個(gè)非常標(biāo)準(zhǔn)的 HTTP 接口但接口背后的審批流、校驗(yàn)規(guī)則、數(shù)據(jù)權(quán)限、冪等策略、與第三方系統(tǒng)的閉環(huán)并不會(huì)因?yàn)樘崾驹~寫(xiě)得漂亮就自動(dòng)出現(xiàn)。這些內(nèi)容必須由人先定義清楚再讓 AI 去實(shí)現(xiàn)。這篇文章適合三類(lèi)讀者第一類(lèi)是正在評(píng)估“AI 能否替代研發(fā)部門(mén)”的技術(shù)管理者。你需要看到 AI 的能力邊界避免把 Demo 當(dāng)成生產(chǎn)系統(tǒng)。第二類(lèi)是真正使用 AI 編程工具的開(kāi)發(fā)者。你需要理解為什么 AI 生成的代碼偶爾“看起來(lái)很對(duì)跑起來(lái)出事”以及怎么用測(cè)試和架構(gòu)約束把這些風(fēng)險(xiǎn)堵住。第三類(lèi)是參與企業(yè)數(shù)字化轉(zhuǎn)型的人。你需要知道AI 的價(jià)值不在生成代碼那一瞬間而在把業(yè)務(wù)規(guī)則結(jié)構(gòu)化、可驗(yàn)證、可演化的整個(gè)過(guò)程中。電影《奧德賽》與 AI 軟件生成的共同點(diǎn)像不等于真《奧德賽》里最震撼的畫(huà)面往往是那些由算法生成的宏大場(chǎng)景。你看到一個(gè)世界它符合視覺(jué)上的直覺(jué)光影正確、物體清晰、海面有波濤。但如果你追問(wèn)這片海域的潮汐規(guī)律是什么這位船長(zhǎng)根據(jù)什么數(shù)據(jù)決定航線船上的物資能在海上支撐多少天電影并不會(huì)回答因?yàn)樗惴ㄉ傻闹皇恰翱雌饋?lái)合理”的畫(huà)面而不是一個(gè)有完整物理和社會(huì)規(guī)則的模擬世界。AI 生成軟件也是同理。你用 AI 做一個(gè)訂單管理后臺(tái)它能生成表單、按鈕、表格能創(chuàng)建訂單、更新?tīng)顟B(tài)、計(jì)算金額。表面上這已經(jīng)是一套能跑的軟件了。但企業(yè)真正關(guān)心的問(wèn)題往往不在這個(gè)表面上訂單金額超過(guò)多少需要二級(jí)審批供應(yīng)商資質(zhì)過(guò)期了能不能繼續(xù)下單同一個(gè)客戶(hù)在不同渠道的訂單能不能合并結(jié)算這些規(guī)則如果不在提示詞里AI 默認(rèn)不會(huì)知道也不會(huì)主動(dòng)問(wèn)。這就引出了一個(gè)核心概念軟件的表面真實(shí)和本質(zhì)真實(shí)是兩回事。表面真實(shí)是代碼能編譯、接口能請(qǐng)求、頁(yè)面能交互本質(zhì)真實(shí)是軟件在特定企業(yè)的組織、流程、合規(guī)和商業(yè)目標(biāo)下能否持續(xù)輸出正確結(jié)果。AI 生成軟件的速度越快我們?cè)饺菀装驯砻嬲鎸?shí)誤當(dāng)成本質(zhì)真實(shí)。電影里的世界可以只追求“像”企業(yè)系統(tǒng)里的世界卻不能只要“像”它必須“是”。AI 開(kāi)發(fā)工具的能力邊界它擅長(zhǎng)什么不擅長(zhǎng)什么先把 AI 開(kāi)發(fā)工具能做好的事情說(shuō)清楚避免走向另一個(gè)極端。AI 非常擅長(zhǎng)以下幾類(lèi)工作樣板代碼和腳手架工程。比如生成一個(gè)新的服務(wù)模塊、CRUD 接口、前端頁(yè)面、數(shù)據(jù)庫(kù)遷移腳本。代碼解釋和遺留系統(tǒng)分析。給 AI 一段老代碼讓它總結(jié)邏輯、標(biāo)注潛在問(wèn)題通常效率比人逐行讀高得多。單測(cè)和邊界測(cè)試生成。給定一個(gè)函數(shù)和輸入輸出示例AI 可以生成不少有價(jià)值的測(cè)試用例?？缯Z(yǔ)言翻譯和框架遷移。把 Java 代碼改成 Go把 Spring Boot 遷移成其他框架AI 能完成大部分機(jī)械工作。文檔生成和維護(hù)。根據(jù)代碼生成接口文檔、數(shù)據(jù)庫(kù)字段說(shuō)明、部署說(shuō)明能省不少時(shí)間。但 AI 不擅長(zhǎng)的地方恰好是企業(yè)軟件最核心的地方定義業(yè)務(wù)邊界。同一個(gè)“訂單”在電商、制造業(yè)、醫(yī)療、物流行業(yè)里含義完全不同。AI 默認(rèn)會(huì)用互聯(lián)網(wǎng)常見(jiàn)的訂單模型而不是你們公司的訂單模型。識(shí)別業(yè)務(wù)不變量。比如“庫(kù)存不能為負(fù)”“每人每周最多提交 3 次申請(qǐng)”“退款金額不能大于實(shí)付金額”。這些規(guī)則通常散落在制度文件和老員工的腦子里。處理歷史包袱。生產(chǎn)環(huán)境里的臟數(shù)據(jù)、舊系統(tǒng)的接口協(xié)議、被多個(gè)團(tuán)隊(duì)共享的數(shù)據(jù)庫(kù)表AI 看不到也不會(huì)理解。判斷非功能需求。接口要在幾毫秒內(nèi)返回?cái)?shù)據(jù)最多能丟幾秒審計(jì)日志要保留幾年這些問(wèn)題直接影響系統(tǒng)設(shè)計(jì)卻不能靠“生成”解決。如果把 AI 當(dāng)成一個(gè)極其高效的外包程序員它確實(shí)合格。但如果把它當(dāng)成了解你公司業(yè)務(wù)的資深架構(gòu)師它一定不合格。問(wèn)題的關(guān)鍵不在于 AI 能不能寫(xiě)代碼而在于“誰(shuí)負(fù)責(zé)把真實(shí)世界翻譯成 AI 能理解的上下文”。從“訂單模塊”看真實(shí)世界一個(gè)最小案例概念講多了容易飄我們用一個(gè)小而完整的采購(gòu)訂單模塊來(lái)拆解。4.1 AI 生成的“表面正確”代碼假設(shè)某制造企業(yè)需要開(kāi)發(fā)一個(gè)采購(gòu)訂單創(chuàng)建接口。你給 AI 一個(gè)很常見(jiàn)的 prompt用 Python FastAPI 實(shí)現(xiàn)一個(gè)采購(gòu)訂單創(chuàng)建接口。請(qǐng)求參數(shù)包括供應(yīng)商ID、商品列表、總金額。AI 大概率會(huì)生成類(lèi)似下面的代碼# 文件路徑main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class PurchaseOrder(BaseModel): supplier_id: int items: list total_amount: float orders [] app.post(/purchase_orders) def create_po(order: PurchaseOrder): orders.append(order) return {id: len(orders), status: created}這段代碼能運(yùn)行嗎能。寫(xiě)入數(shù)據(jù)了嗎寫(xiě)入了。但在真實(shí)企業(yè)里這段代碼大概率不能直接上線。原因不是語(yǔ)法而是它缺少對(duì)一個(gè)真實(shí)采購(gòu)系統(tǒng)的全部上下文。4.2 真實(shí)業(yè)務(wù)規(guī)則開(kāi)始出現(xiàn)后現(xiàn)在把企業(yè)的真實(shí)規(guī)則加進(jìn)來(lái)。比如只有通過(guò)認(rèn)證的供應(yīng)商才能創(chuàng)建采購(gòu)訂單。訂單總金額超過(guò) 100 萬(wàn)時(shí)必須進(jìn)入兩級(jí)審批。同一供應(yīng)商如果已經(jīng)有一筆待審批訂單且采購(gòu)品類(lèi)相同則不能重復(fù)創(chuàng)建。金額計(jì)算必須使用 Decimal不能用 float避免精度問(wèn)題。這些規(guī)則看起來(lái)不難但每一條都意味著代碼結(jié)構(gòu)的變化。下面是加入部分規(guī)則后的服務(wù)層實(shí)現(xiàn)# 文件路徑services/purchase_order_service.py from decimal import Decimal from domain.purchase_order import PurchaseOrder, OrderStatus from domain.business_rule_error import BusinessRuleViolation def create_purchase_order(repo, supplier_repo, approval_service, order_draft): supplier supplier_repo.find_by_id(order_draft.supplier_id) if supplier is None or not supplier.verified: raise BusinessRuleViolation(supplier must be verified) po PurchaseOrder( supplier_idsupplier.id, itemsorder_draft.items, total_amountcalculate_total(order_draft.items) ) existing repo.find_pending_po_by_supplier_and_category( supplier.id, po.category ) if existing is not None: raise BusinessRuleViolation(duplicate pending po) if po.total_amount Decimal(1000000.00): po.status OrderStatus.PENDING_APPROVAL approval_service.start_flow(po, level2) repo.save(po) return po def calculate_total(items): return sum((Decimal(str(item.unit_price)) * item.quantity) for item in items)這仍然是一個(gè)簡(jiǎn)化版本但已經(jīng)能看出來(lái)真實(shí)業(yè)務(wù)規(guī)則會(huì)影響函數(shù)輸入、狀態(tài)流轉(zhuǎn)、依賴(lài)服務(wù)和異常處理。AI 能不能生成這段代碼如果提示詞寫(xiě)得很細(xì)它大概率也能生成。但問(wèn)題是這些規(guī)則從哪來(lái)不是 AI 能憑空想出來(lái)的而是業(yè)務(wù)人員、財(cái)務(wù)人員、采購(gòu)專(zhuān)員坐在一起經(jīng)過(guò)很多次討論后才確定下來(lái)的。4.3 用測(cè)試把業(yè)務(wù)規(guī)則變成可執(zhí)行約束要保證 AI 生成的代碼不會(huì)破壞業(yè)務(wù)規(guī)則最有效的方法是把規(guī)則轉(zhuǎn)成測(cè)試。下面是一個(gè)針對(duì)“未認(rèn)證供應(yīng)商不能下單”的測(cè)試# 文件路徑tests/test_purchase_order_service.py import pytest from decimal import Decimal from services.purchase_order_service import create_purchase_order from domain.business_rule_error import BusinessRuleViolation def test_cannot_create_po_from_unverified_supplier(): unverified_supplier Supplier(id999, verifiedFalse) repo MemoryRepo() supplier_repo MemoryRepo([unverified_supplier]) approval_service ApprovalService() draft OrderDraft( supplier_id999, items[OrderItem(skuA001, quantity2, unit_priceDecimal(50.00))] ) with pytest.raises(BusinessRuleViolation): create_purchase_order(repo, supplier_repo, approval_service, draft)寫(xiě)這個(gè)測(cè)試的意義比寫(xiě)業(yè)務(wù)代碼本身更重要。因?yàn)樗岩粭l看不見(jiàn)的規(guī)則變成了一個(gè)每次提交代碼都會(huì)自動(dòng)運(yùn)行的“守門(mén)員”。AI 可以快速生成代碼但只有人才能決定哪些規(guī)則必須被測(cè)試固化下來(lái)。運(yùn)行測(cè)試的命令很簡(jiǎn)單pytest tests/test_purchase_order_service.py -v預(yù)期輸出tests/test_purchase_order_service.py::test_cannot_create_po_from_unverified_supplier PASSED如果這條測(cè)試失敗說(shuō)明供應(yīng)商校驗(yàn)邏輯沒(méi)有被實(shí)現(xiàn)或者被后續(xù) AI 重構(gòu)時(shí)改壞了。企業(yè)系統(tǒng)的可靠性本質(zhì)上就是這樣一條一條測(cè)試堆起來(lái)的而不是靠某一次“生成”完成的。為什么真實(shí)世界不能被一次性“喂”給 AI很多人會(huì)想既然 AI 生成代碼需要上下文那我多寫(xiě)一點(diǎn)提示詞把規(guī)則全部塞進(jìn)去不就行了理論上可以但實(shí)踐中行不通。5.1 企業(yè)軟件的“上下文”遠(yuǎn)大于提示詞一個(gè)運(yùn)行五年以上的企業(yè)系統(tǒng)它的真實(shí)上下文包括幾十張數(shù)據(jù)庫(kù)表的歷史含義、多個(gè)系統(tǒng)之間對(duì)賬規(guī)則、不同業(yè)務(wù)部門(mén)對(duì)同一字段的解釋差異、還有因?yàn)樘厥馇闆r留下的兼容邏輯。這些內(nèi)容不可能全部寫(xiě)進(jìn)一次對(duì)話的提示詞里。更現(xiàn)實(shí)的做法是把企業(yè)級(jí)的上下文拆成兩類(lèi)一類(lèi)是穩(wěn)定的業(yè)務(wù)規(guī)則比如“價(jià)格必須大于 0”“訂單不能重復(fù)提交”另一類(lèi)是不斷變化的環(huán)境比如某個(gè)客戶(hù)生命周期在某個(gè)階段需要特殊處理。前者可以結(jié)構(gòu)化地描述給 AI后者必須靠持續(xù)運(yùn)維和反饋閉環(huán)來(lái)修正。5.2 AI 不知道你不知道的規(guī)則這是最容易被忽略的一點(diǎn)。企業(yè)在招聘新人的時(shí)候老員工會(huì)告訴他“我們這個(gè)系統(tǒng)里有個(gè)特殊邏輯三年前因?yàn)槟硞€(gè)大客戶(hù)要求加的文檔里沒(méi)寫(xiě)?！?AI 也一樣它不知道你們企業(yè)內(nèi)部那些“只可意會(huì)”的規(guī)則。如果 AI 生成代碼時(shí)沒(méi)有這些規(guī)則它就會(huì)用自己從海量公開(kāi)代碼里學(xué)到的“通用世界模型”來(lái)填空。通用模型對(duì)大多數(shù) Demo 有用但對(duì)特定企業(yè)來(lái)說(shuō)很可能就是錯(cuò)的。尤其是在金融、醫(yī)療、制造等強(qiáng)合規(guī)行業(yè)用通用模型填充特定業(yè)務(wù)風(fēng)險(xiǎn)極高。5.3 企業(yè)系統(tǒng)的確定性要求電影生成允許隨機(jī)性這次生成的畫(huà)面不滿(mǎn)意可以再生成一次。但企業(yè)系統(tǒng)對(duì)同一輸入必須保證同一輸出。訂單提交后不能因?yàn)槟硞€(gè)模型參數(shù)變化導(dǎo)致金額計(jì)算不同。這種確定性要求決定了 AI 不能作為業(yè)務(wù)邏輯的唯一決策來(lái)源。正確的模式是AI 負(fù)責(zé)生成實(shí)現(xiàn)人負(fù)責(zé)定義確定性規(guī)則測(cè)試負(fù)責(zé)固化規(guī)則架構(gòu)負(fù)責(zé)隔離變化。只要這個(gè)分工清晰AI 才能真正進(jìn)入企業(yè)開(kāi)發(fā)流程而不是停留在玩一玩的層面。企業(yè)引入 AI 開(kāi)發(fā)容易踩的四個(gè)坑在實(shí)際落地過(guò)程中我經(jīng)?？吹綀F(tuán)隊(duì)把 AI 開(kāi)發(fā)工具用成“麻煩制造機(jī)”問(wèn)題通常出在以下四個(gè)地方。第一個(gè)坑把 AI 生成的結(jié)果當(dāng)成需求完成。AI 給出一個(gè)訂單接口團(tuán)隊(duì)直接把接口聯(lián)調(diào)上線但沒(méi)人校驗(yàn)“審批流是否接入”“金額精度是否正確”。等業(yè)務(wù)發(fā)現(xiàn)數(shù)字對(duì)不上問(wèn)題已經(jīng)埋進(jìn)生產(chǎn)環(huán)境。第二個(gè)坑業(yè)務(wù)人員直接用 AI 工具自建系統(tǒng)。業(yè)務(wù)部門(mén)響應(yīng)速度慢于是有人用 AI 寫(xiě)腳本處理核心數(shù)據(jù)比如把手工 Excel 里的數(shù)據(jù)批量導(dǎo)入數(shù)據(jù)庫(kù)。這些腳本沒(méi)有經(jīng)過(guò)審查沒(méi)有日志出錯(cuò)后連備份都沒(méi)有。這實(shí)質(zhì)上是把未受管制的邏輯放進(jìn)了生產(chǎn)鏈路。第三個(gè)坑AI 生成了大量樣板代碼卻沒(méi)人維護(hù)。AI 一天能生成 3000 行代碼很快代碼庫(kù)就膨脹起來(lái)。但企業(yè)系統(tǒng)維護(hù)成本不是按代碼行數(shù)算的而是按業(yè)務(wù)邏輯復(fù)雜度和依賴(lài)關(guān)系算的。樣板越多依賴(lài)越亂后續(xù)改動(dòng)越難。第四個(gè)坑讓 AI 直接修改生產(chǎn)代碼缺少回歸測(cè)試。AI 重構(gòu)很快就完成了但沒(méi)跑測(cè)試沒(méi)看影響范圍。上線后出現(xiàn)數(shù)據(jù)不一致只好回滾?；貪L本身并不可怕可怕的是你根本不知道它改了幾處地方。這四類(lèi)問(wèn)題的根源都一樣我們已經(jīng)非常信任 AI 的執(zhí)行能力卻還沒(méi)有建立起相應(yīng)的治理和驗(yàn)證機(jī)制。一套落地的 AI 輔助開(kāi)發(fā)流程既然 AI 解決不了“真實(shí)世界缺失”的問(wèn)題那我們應(yīng)該把它放在一個(gè)合適的流程里讓它的速度為企業(yè)所用同時(shí)讓企業(yè)規(guī)則不被稀釋。7.1 先寫(xiě)決策記錄再讓 AI 動(dòng)手建議在項(xiàng)目里引入輕量級(jí)的決策記錄文檔不需要很長(zhǎng)但一定要寫(xiě)清楚為什么會(huì)做某個(gè)技術(shù)選型、為什么某條業(yè)務(wù)規(guī)則存在。比如# ADR-001采購(gòu)訂單金額使用 Decimal ## 背景 財(cái)務(wù)結(jié)算要求金額不能有誤差。 使用 float 可能出現(xiàn) 0.1 0.2 不等于 0.3 的問(wèn)題。 ## 決策 所有金額字段使用 Decimal禁止使用 float。 ## 影響 API 層需要做類(lèi)型轉(zhuǎn)換數(shù)據(jù)庫(kù)字段映射為 decimal 類(lèi)型。把 ADR 放在倉(cāng)庫(kù)里并讓 AI 在生成代碼前閱讀這些文檔。如果使用編程 Agent 一類(lèi)的工具可以把 ADR 作為工作區(qū)上下文。這樣AI 生成的代碼就更容易符合團(tuán)隊(duì)已經(jīng)做過(guò)的決策。7.2 用“結(jié)構(gòu)化提示 測(cè)試先行”鎖定業(yè)務(wù)規(guī)則不要只給 AI 一句話需求而是把業(yè)務(wù)規(guī)則、輸入樣例、測(cè)試預(yù)期都寫(xiě)清楚。下面的 prompt 模板比較適合企業(yè)場(chǎng)景請(qǐng)基于以下規(guī)則實(shí)現(xiàn)采購(gòu)訂單創(chuàng)建接口 業(yè)務(wù)規(guī)則 1. 只有已認(rèn)證供應(yīng)商可以創(chuàng)建訂單。 2. 訂單總金額超過(guò) 100 萬(wàn)時(shí)需要二級(jí)審批。 3. 同一供應(yīng)商、同一品類(lèi)、存在待審批訂單時(shí)禁止重復(fù)創(chuàng)建。 4. 所有金額使用 Decimal禁止使用 float。 工程約束 - 使用 FastAPI。 - 服務(wù)層不直接依賴(lài) HTTP 層。 - 輸出單元測(cè)試。 請(qǐng)?jiān)诖a注釋中標(biāo)出每條業(yè)務(wù)規(guī)則對(duì)應(yīng)的實(shí)現(xiàn)位置。關(guān)鍵不是 prompt 寫(xiě)得多長(zhǎng)而是讓 AI 把一個(gè)明確規(guī)則映射到代碼和測(cè)試。如果規(guī)則有歧義不要直接問(wèn) AI“你覺(jué)得怎么做”而是讓人先開(kāi)會(huì)把歧義消除。7.3 用 CI/CD 守住質(zhì)量邊界AI 生成代碼進(jìn)入主分支之前至少應(yīng)該經(jīng)過(guò)自動(dòng)化測(cè)試、靜態(tài)檢查和依賴(lài)掃描。一個(gè)很基礎(chǔ)的 CI 配置長(zhǎng)這樣# 文件路徑.github/workflows/ci.yml name: ci on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest - name: Run tests run: pytest -v如果 AI 生成的代碼不能通過(guò)這條流水線就不應(yīng)該進(jìn)入人工評(píng)審環(huán)節(jié)。這樣AI 的“快”和企業(yè)的“穩(wěn)”之間就有了一個(gè)強(qiáng)制隔離點(diǎn)。常見(jiàn)問(wèn)題與排查思路下面這張表列出企業(yè)在使用 AI 開(kāi)發(fā)時(shí)最容易碰到的問(wèn)題以及對(duì)應(yīng)的排查方式。遇到問(wèn)題不要先懷疑 AI 能力先按表里的順序看。問(wèn)題現(xiàn)象可能原因排查方式解決方案AI 生成的代碼能運(yùn)行但業(yè)務(wù)結(jié)果不對(duì)只描述了功能沒(méi)有描述業(yè)務(wù)規(guī)則對(duì)照需求文檔和代碼中的規(guī)則分支把業(yè)務(wù)規(guī)則寫(xiě)成測(cè)試用例建立規(guī)則清單AI 重構(gòu)舊代碼后原有功能被破壞回歸測(cè)試缺失測(cè)試覆蓋太少查看 git diff運(yùn)行全量測(cè)試在改動(dòng)前補(bǔ)上關(guān)鍵路徑測(cè)試小步提交業(yè)務(wù)人員用 AI 建腳本處理核心數(shù)據(jù)正常需求響應(yīng)太慢治理缺失檢查有沒(méi)有未受管制的腳本、報(bào)表或數(shù)據(jù)庫(kù)連接建設(shè)需求通道和自助數(shù)據(jù)平臺(tái)同時(shí)規(guī)范 AI 使用AI 生成依賴(lài)有安全漏洞依賴(lài)版本過(guò)新或存在已知漏洞運(yùn)行 pip-audit / npm audit 等工具鎖定版本加入依賴(lài)掃描流程團(tuán)隊(duì)內(nèi)代碼風(fēng)格混亂缺少格式化和架構(gòu)約束檢查 review 記錄和靜態(tài)掃描結(jié)果引入 formatter、lint 和架構(gòu)測(cè)試AI 在中間步驟產(chǎn)生幻覺(jué)調(diào)用了不存在的接口上下文不完整工具權(quán)限過(guò)高查看 AI 執(zhí)行日志確認(rèn)模型上下文縮小任務(wù)范圍提供準(zhǔn)確的接口文檔最佳實(shí)踐與工程建議想讓 AI 長(zhǎng)期穩(wěn)定地輔助企業(yè)軟件研發(fā)建議把下面幾件事當(dāng)成制度而不是臨時(shí)動(dòng)作。第一先建模后生成。業(yè)務(wù)邊界、領(lǐng)域?qū)ο?、狀態(tài)機(jī)、權(quán)限模型這些高層決策必須由人來(lái)定義。AI 可以幫你畫(huà)草圖但負(fù)責(zé)判斷和拍板的一定是團(tuán)隊(duì)。第二把業(yè)務(wù)規(guī)則變成資產(chǎn)。為每條核心規(guī)則編號(hào)例如 R-001、R-002并且在代碼里通過(guò)注釋或測(cè)試用例引用對(duì)應(yīng)編號(hào)。這樣后續(xù) AI 在修改代碼時(shí)更容易通過(guò)上下文找到要遵守的規(guī)則。第三測(cè)試從業(yè)務(wù)規(guī)則出發(fā)而不是只追求覆蓋率。覆蓋率高低不是核心目標(biāo)是否正確覆蓋了關(guān)鍵不變量才是。一個(gè) 60% 覆蓋率但覆蓋了所有核心規(guī)則的測(cè)試套件要好過(guò)一個(gè) 95% 覆蓋率卻只測(cè)了正常路徑的測(cè)試套件。第四給 AI 工具設(shè)置權(quán)限邊界。不要讓 AI 直接操作生產(chǎn)環(huán)境數(shù)據(jù)庫(kù)也不要讓它直接往 main 分支推代碼。你要的不是一個(gè)“足夠自由”的助手而是一個(gè)“在邊界內(nèi)高效工作”的助手。第五人工審查不要流于形式。AI 生成的代碼審查者必須能回答三個(gè)問(wèn)題這段代碼真的滿(mǎn)足業(yè)務(wù)規(guī)則嗎如果規(guī)則變化哪里會(huì)受影響異常路徑里數(shù)據(jù)是否保持一致如果審查時(shí)回答不了說(shuō)明上下文還沒(méi)建好。第六把線上的異常反饋?zhàn)兂尚碌臏y(cè)試。生產(chǎn)環(huán)境出現(xiàn)數(shù)據(jù)不一致不要只修數(shù)據(jù)更要追問(wèn)為什么測(cè)試沒(méi)有提前發(fā)現(xiàn)然后把反饋轉(zhuǎn)成測(cè)試用例不斷逼近企業(yè)的真實(shí)世界。這些實(shí)踐看起來(lái)不酷但企業(yè)系統(tǒng)恰恰是靠著這種“不酷”的確定性才敢支撐每天數(shù)百萬(wàn)筆交易。AI 的價(jià)值在于壓縮實(shí)現(xiàn)時(shí)間而不是壓縮驗(yàn)證和治理環(huán)節(jié)。結(jié)語(yǔ)AI 加快建造但定義世界仍是人的工作回到《奧德賽》那個(gè)比喻。AI 可以生成無(wú)數(shù)個(gè)視覺(jué)上足夠真實(shí)的場(chǎng)景但在一場(chǎng)真正的航行中你需要的不是一幀好看的畫(huà)面而是清晰的航線、可靠的船體結(jié)構(gòu)以及在風(fēng)暴來(lái)臨時(shí)仍然有效的判斷規(guī)則。軟件也一樣。AI 可以把代碼這座“建筑”砌得很快但只有人才知道這座建筑為什么存在、給誰(shuí)使用、哪根柱子不能動(dòng)。企業(yè)的真實(shí)世界不是一個(gè)提示詞就能覆蓋的它是一個(gè)由組織流程、數(shù)據(jù)歷史、合規(guī)要求和人組成的持續(xù)演化的系統(tǒng)。如果你正在推進(jìn) AI 輔助開(kāi)發(fā)下一步不是去收藏更多的 prompt 模板而是回到辦公室里和業(yè)務(wù)負(fù)責(zé)人一起把你最核心的訂單、審批、對(duì)賬規(guī)則寫(xiě)清楚。把這條規(guī)則變成測(cè)試放進(jìn) CI再讓 AI 在那個(gè)邊界里盡情發(fā)揮。這才是 AI 開(kāi)發(fā)工具真正值得被信任的方式。