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