AI-native 企業(yè)這個概念過去一年頻繁出現(xiàn)在技術(shù)管理、產(chǎn)品設(shè)計和工程團隊的討論里。它指的不是某個團隊接入了大模型 API而是公司核心工作流在設(shè)計階段就默認(rèn)存在一個 AI 層內(nèi)容生成、代碼編寫、數(shù)據(jù)處理、客服響應(yīng)都盡可能由程序自動完成人在其中的角色從“執(zhí)行者”變成“定義規(guī)則、處理例外、驗收結(jié)果”的人。于是標(biāo)題里的問題就變成一個非常具體的工程問題如果技術(shù)與 AI 自動處理了 75% 的工作系統(tǒng)如何知道自己正在處理的是哪一側(cè)剩下的 25% 應(yīng)該交給誰如何把這 25% 自動識別出來并帶著完整上下文送到人類面前這篇文章會從 AI 工程實踐的角度拆解這個問題適合正在做 AI Agent、AI 編程助手、內(nèi)容自動化管線、AI 應(yīng)用開發(fā)或模型部署落地的開發(fā)者、技術(shù)負(fù)責(zé)人和產(chǎn)品經(jīng)理閱讀。讀完你會得到一條可執(zhí)行的思路哪些任務(wù)該進(jìn)入自動化流水線哪些必須保留人工判斷以及技術(shù)上如何設(shè)計這條邊界。1. AI-native 企業(yè)的 75% 到底是什么在自動做1.1 AI-native 不是“用了 AI”而是“流程默認(rèn)有 AI 層”先糾正一個常見誤解。一家公司不定時用 AI 寫文案、畫圖、寫代碼并不等于 AI-native。真正的 AI-native 企業(yè)是業(yè)務(wù)系統(tǒng)在架構(gòu)設(shè)計時就把模型推理當(dāng)作基礎(chǔ)設(shè)施像使用數(shù)據(jù)庫和消息隊列一樣自然。任務(wù)從進(jìn)入系統(tǒng)開始就按照“先嘗試自動處理處理不了再升級給人”的路徑運行。換句話說75% 不是事后統(tǒng)計出來的而是流程設(shè)計出來的。對開發(fā)者來說這意味著要寫的不是一個聊天窗口而是一個工作流引擎。它負(fù)責(zé)接收任務(wù)、判斷任務(wù)類型、調(diào)用合適的模型和工具、檢查輸出質(zhì)量、決定是否交給人工復(fù)核。這個工作流引擎本質(zhì)上是一個圍繞模型能力重構(gòu)的業(yè)務(wù)系統(tǒng)。理解這一點后面討論自動化邊界才有基礎(chǔ)。1.2 75% 通常落在四類重復(fù)性工作上不同行業(yè)差異很大但根據(jù)目前 AI 應(yīng)用開發(fā)的常見場景可以自動化的 75% 通常集中在四類工作里。工作類型典型任務(wù)自動化輸出適合自動化的原因內(nèi)容生成營銷文案、短視頻腳本、廣告素材、報告初稿文本、圖文、視頻素材批量需求大模板化程度高軟件研發(fā)代碼生成、單元測試補全、接口文檔、Bug 分析代碼、測試用例、文檔輸出可編譯、可測試、可回滾數(shù)據(jù)與知識數(shù)據(jù)清洗、報表摘要、文檔問答、信息抽取結(jié)構(gòu)化數(shù)據(jù)、摘要、答案規(guī)則可描述結(jié)果可校驗交互服務(wù)客服響應(yīng)、工單分類、郵件起草、流程引導(dǎo)回復(fù)、分類結(jié)果、草稿高頻重復(fù)人工處理成本高這里有一條規(guī)律能被自動化的 75%幾乎都是“輸入明確、輸出可校驗、風(fēng)險可承受”的工作。輸入明確指任務(wù)邊界清楚比如“把這張表轉(zhuǎn)成 JSON”輸出可校驗指結(jié)果能用規(guī)則、測試或另一個模型判斷好壞風(fēng)險可承受指出錯不會造成不可逆損失。這三個維度也是后續(xù)設(shè)計自動化邊界時最核心的判斷標(biāo)準(zhǔn)。1.3 75% 是工程目標(biāo)不是一個天然成立的統(tǒng)計數(shù)字必須說明75% 來自標(biāo)題給出的場景假設(shè)它不是一個權(quán)威機構(gòu)發(fā)布的統(tǒng)計結(jié)果也不代表每個團隊都能達(dá)到。現(xiàn)實里一個客服團隊可能只能自動化 40%而一個內(nèi)容團隊可能自動化 90%。把 75% 當(dāng)成工程目標(biāo)會比當(dāng)成既定事實更合理。這個目標(biāo)的有意義之處在于它逼著團隊回答三個問題第一當(dāng)前哪些任務(wù)在重復(fù)發(fā)生且邊界清晰第二自動化后的失敗率是否可接受第三失敗后能不能讓人快速接管。這三個問題的答案直接決定自動化率能做到多少。不要先上模型再想邊界而是先按任務(wù)清單算清楚哪些適合自動、哪些必須人工再把邊界做成系統(tǒng)規(guī)則。2. 支撐自動化的四層技術(shù)棧模型、編排、工具、評測2.1 模型層決定能力上限也決定成本與延遲模型層是整個自動化系統(tǒng)的計算核心。學(xué)習(xí)環(huán)境和生產(chǎn)環(huán)境的差別在這里非常明顯學(xué)習(xí)環(huán)境可以直接調(diào)用云端模型 API先把流程跑通生產(chǎn)環(huán)境要考慮成本、延遲、數(shù)據(jù)出域和權(quán)限問題可能需要私有化部署開源模型或者通過統(tǒng)一的模型網(wǎng)關(guān)管理多個供應(yīng)商。選擇模型時要同時看四個維度上下文長度決定單次能接收多少材料推理質(zhì)量決定輸出能不能直接用延遲決定任務(wù)吞吐成本Credits 或 Token 費用決定自動化在經(jīng)濟上是否劃算。注意模型只是“能力上限”它不能保證一致性。同一個提示詞在不同時間可能返回不同結(jié)果所以模型層之上必須有編排層來約束行為。2.2 編排層用 AI Agent 把單次對話變成多步驟工作流AI Agent 是當(dāng)前 AI 應(yīng)用開發(fā)里最重要的編排范式。它把復(fù)雜任務(wù)拆成多個步驟讓模型在“規(guī)劃-調(diào)用工具-觀察結(jié)果-繼續(xù)執(zhí)行”的循環(huán)里完成工作。比如生成一份周報Agent 會先讀取數(shù)據(jù)源、再執(zhí)行 SQL 查詢、把結(jié)果交給模型組織語言、最后交給校驗器檢查格式。Agent 與普通聊天的區(qū)別在于聊天是“模型回答一次”Agent 是“系統(tǒng)多次調(diào)用模型和工具直到任務(wù)完成或達(dá)到終止條件”。在軟件研發(fā)場景里Cursor、GitHub Copilot、JetBrains AI Assistant 這類 AI 編程工具已經(jīng)證明代碼生成可以進(jìn)入自動化流水線但提交前仍然需要編譯檢查和人工評審。Agent 的核心參數(shù)包括最大迭代次數(shù)、單次超時時間、失敗重試次數(shù)和終止條件這些參數(shù)直接影響自動化率迭代次數(shù)太少復(fù)雜任務(wù)容易半途而廢太多成本和耗時又會失控。2.3 工具層讓 AI 從“能說”變成“能做”工具層是 Agent 的“手”。常見工具包括數(shù)據(jù)庫查詢接口、文件讀寫、代碼執(zhí)行沙箱、搜索 API、圖像生成接口、視頻成片接口、內(nèi)部業(yè)務(wù)系統(tǒng) API 等。設(shè)計工具層時最重要的原則是“最小權(quán)限”Agent 只能調(diào)用完成當(dāng)前任務(wù)需要的工具而且每個工具都要有超時、限流和審計。工具返回結(jié)果的格式也要統(tǒng)一。建議所有工具都返回結(jié)構(gòu)化數(shù)據(jù)并帶執(zhí)行狀態(tài)和錯誤信息這樣編排層才能判斷是重試、換工具還是升級給人。如果工具返回的是自由文本模型很容易誤解自動化鏈路就會變得不可靠。2.4 評測層決定自動化率能不能被信任很多團隊把注意力放在“生成”上卻忽略了“判斷”。沒有評測層系統(tǒng)不知道輸出是好是壞也就不知道該不該交給人工。評測層通常由三類檢查組成規(guī)則檢查比如字段格式、長度、關(guān)鍵詞、金額范圍程序檢查比如代碼能否編譯、測試是否能通過模型檢查比如用一個評測模型對輸出打分或者讓兩個模型互相校驗。評測結(jié)果可以是分?jǐn)?shù)或一組布爾條件編排層根據(jù)結(jié)果決定放行、重試還是升級人工。AI 幻覺問題也在這里暴露模型生成的回答看起來很合理但可能包含虛假事實。高風(fēng)險場景需要設(shè)計事實核查步驟比如要求模型引用數(shù)據(jù)來源或者把關(guān)鍵結(jié)論與知識庫做一致性比對。3. 一個最小可落地的“自動 75%”任務(wù)流水線3.1 選任務(wù)高頻、低風(fēng)險、結(jié)果可校驗不要一開始就做“全能助手”先把一個任務(wù)做到高自動化率。推薦選“周報生成”這類任務(wù)輸入是結(jié)構(gòu)化數(shù)據(jù)輸出是格式化文檔質(zhì)量可以用規(guī)則和人工抽查校驗出錯不會造成嚴(yán)重?fù)p失。跑通之后再把同一套流水線復(fù)制到更多任務(wù)上。3.2 流水線配置用 YAML 描述路由、執(zhí)行和升級規(guī)則把自動化策略做成配置而不是寫死在代碼里是 AI-native 系統(tǒng)的重要實踐。下面是一個任務(wù)流水線的 YAML 示例。pipeline: name: weekly_report_generation trigger: scheduler intake: source: internal_data_platform required_fields: [report_type, period, team_id] route: rules: - if: report_type not in supported_types target: human - if: period is invalid or data_missing target: human - default: ai ai: model: 按部署環(huán)境填實際模型標(biāo)識 temperature: 0.2 max_iterations: 5 max_retries: 2 tool_timeout_seconds: 30 verify: checker: rule_based llm_as_judge min_score: 0.8 escalate: channel: human_review_queue ttl_hours: 4這個配置里有三點值得注意。第一路由規(guī)則先于 AI 執(zhí)行把明顯不能自動處理的任務(wù)直接送人工避免浪費模型調(diào)用。第二verify 是流水線的強制環(huán)節(jié)不是可選項。第三escalate 給人工隊列設(shè)置超時時間防止工單堆積后無人處理。3.3 核心代碼能自動就自動拿不準(zhǔn)就升級給人下面是一段演示任務(wù)執(zhí)行主循環(huán)的 Python 偽代碼。它只展示設(shè)計思路實際項目里要替換為真實的模型調(diào)用、工具客戶端和隊列系統(tǒng)。import json THRESHOLD 0.8 def run_task(task: dict, llm, tools, checker) - dict: record { task_id: task[id], route: ai, status: running, human_review_required: False, steps: [], result: None, } try: plan llm.plan(task[request]) record[steps].append({step: plan, detail: plan}) for step in plan[steps]: if step[action] tool: output tools.run(step[tool], step[args]) else: output llm.generate(step[prompt]) record[steps].append({step: step[name], output: output}) record[result], score checker.validate(record) if score THRESHOLD: record[route] human record[human_review_required] True record[reason] fvalidation_score{score} {THRESHOLD} return record except Exception as exc: record[route] human record[status] error record[reason] f{type(exc).__name__}: {exc} return record關(guān)鍵邏輯只有一條無論執(zhí)行成功還是異常只要驗證分?jǐn)?shù)低于閾值任務(wù)就進(jìn)入人工隊列。人工隊列不是“出了問題再看”的垃圾桶而是整個系統(tǒng)的兜底通道。record 里的每一步都會被保留人工接手時能直接看到模型是怎么規(guī)劃、調(diào)用了哪些工具、在哪里失分。3.4 關(guān)鍵參數(shù)怎么調(diào)參數(shù)含義推薦值調(diào)小的表現(xiàn)調(diào)大的表現(xiàn)temperature輸出隨機性0.1-0.3更穩(wěn)定但可能機械更發(fā)散但容易跑題max_iterations任務(wù)最多輪數(shù)5-10復(fù)雜任務(wù)中途失敗成本和耗時增加max_retries工具失敗重試1-3偶發(fā)錯誤直接升級人工錯誤反復(fù)重試拖慢任務(wù)min_score驗證通過分?jǐn)?shù)0.8放行更多壞結(jié)果大量任務(wù)升級人工tool_timeout工具超時10-30 秒慢工具頻繁超時故障時等待過長注意這些參數(shù)不是設(shè)完就固定的。上線后要根據(jù)“升級率”“重試率”“人工修正率”持續(xù)調(diào)整尤其是 min_score它直接控制 75/25 邊界的位置。設(shè)得太低壞結(jié)果會流到用戶側(cè)設(shè)得太高人工隊列會被塞滿自動化率反而下降。4. 剩下的 25% 是判斷不是“AI 做不了的雜活”4.1 需求歧義和目標(biāo)權(quán)衡需要人做決策自動化的前提是輸入明確但現(xiàn)實任務(wù)經(jīng)常帶著歧義。比如“把市場部最新的活動做成一版投放物料”這里的“最新”“合適”“投放物料”都需要人在具體語境里判斷。模型可以生成候選方案但選擇哪個方向、預(yù)算怎么分、觸達(dá)哪些人群本質(zhì)上是目標(biāo)權(quán)衡。這類決策應(yīng)該由人來做AI 負(fù)責(zé)提供信息和備選方案。4.2 低概率異常應(yīng)該由系統(tǒng)主動交給人類即使模型很強仍然會遇到訓(xùn)練數(shù)據(jù)里幾乎沒有的異常。比如數(shù)據(jù)源突然返回完全不同的字段結(jié)構(gòu)、用戶提出了一個越權(quán)或違規(guī)的請求、業(yè)務(wù)規(guī)則在月底有臨時調(diào)整。系統(tǒng)面對這些情況時最穩(wěn)妥的行為不是硬猜而是主動升級。把異常升級設(shè)計成正常流程的一部分而不是等到用戶投訴才介入。4.3 質(zhì)量標(biāo)準(zhǔn)、責(zé)任歸屬和對外承諾不能完全委托客戶合同、合規(guī)承諾、對外公告、涉及大額資金的操作這些場景出錯成本極高不適合讓模型擁有最終決定權(quán)。人可以借助模型起草、預(yù)檢、翻譯、總結(jié)但最終確認(rèn)必須有人簽字。這也是很多企業(yè)要求“AI 生成結(jié)果 人工審核”的原因而不是直接全自動對外發(fā)布。4.4 用一張表劃分 75% 與 25%判斷維度交給自動化75%保留人工25%輸入結(jié)構(gòu)明確模糊、沖突、需要澄清輸出可校驗、可測試好壞沒有客觀標(biāo)準(zhǔn)風(fēng)險低出錯可回滾高不可逆或涉及責(zé)任頻率高頻重復(fù)低頻但重要判斷性質(zhì)執(zhí)行已知規(guī)則權(quán)衡目標(biāo)、定義規(guī)則一張表無法覆蓋所有任務(wù)但可以作為任務(wù)上線的體檢模板一個任務(wù)如果五個維度都落在左側(cè)放心交給自動化只要有一項落在右側(cè)就要考慮增加人工檢查點。5. 把 25% 設(shè)計進(jìn)系統(tǒng)人在回路是機制而不是補丁5.1 三條必備機制升級、審計、回滾升級機制解決“誰來接管”的問題。它由觸發(fā)條件和目標(biāo)隊列組成。觸發(fā)條件包括驗證分?jǐn)?shù)低于閾值、工具調(diào)用連續(xù)失敗、任務(wù)命中敏感規(guī)則、用戶主動要求人工介入。目標(biāo)隊列可以是企業(yè)微信或釘釘群、工單系統(tǒng)也可以是專門的審核后臺。審計機制解決“出了問題怎么追溯”的問題。每次 AI 執(zhí)行都要記錄輸入任務(wù)、使用的模型版本、完整提示詞、工具調(diào)用記錄、模型返回內(nèi)容、驗證分?jǐn)?shù)、最終處理人。沒有審計AI-native 系統(tǒng)在故障面前會非常無力因為你無法判斷問題出在模型還是編排?；貪L機制解決“做錯了怎么辦”的問題。凡是會對外發(fā)布、寫入數(shù)據(jù)庫、發(fā)送消息的任務(wù)都應(yīng)該支持“先預(yù)覽后執(zhí)行”或“生成草稿待確認(rèn)”。把不可逆操作拆成“生成-預(yù)覽-確認(rèn)”三步是降低自動化風(fēng)險最有效的手段。5.2 升級記錄的格式從模型輸出到人工工單升級不是把一段文本丟給人工而是生成一份帶上下文的工單。下面是一個 JSON 示例。{ task_id: task_20250101_001, route: human, trigger: low_validation_score, validation_score: 0.62, model_version: model-a-2025.01, task_request: 為華東區(qū)團隊生成周報并發(fā)送, ai_result: { summary: 華東區(qū)本周銷售額環(huán)比下降8%, data_source: sales_weekly_20250101.csv }, human_review_note: 下降原因缺少業(yè)務(wù)解釋需要補充市場活動信息, status: pending }人工收到工單后可以直接看到任務(wù)請求、AI 結(jié)果、失分原因和模型版本不需要重新梳理上下文。這能顯著縮短人工處理時間也方便后續(xù)把人工修正結(jié)果回灌給系統(tǒng)。5.3 人工修正結(jié)果要回流到評測集和提示詞很多團隊把人工審核當(dāng)成終點但 AI-native 系統(tǒng)里人工修正應(yīng)該是持續(xù)改進(jìn)的來源。每一條人工修正都可以派生成三類資產(chǎn)一是更新評測集把這次輸入和正確輸出加入回歸用例二是更新提示詞加入一類典型錯誤作為 few-shot 示例三是更新路由規(guī)則讓同類任務(wù)從一開始就加強校驗或直接升級。只有建立了這個反饋回路自動化率才會穩(wěn)定上升。否則人工修正永遠(yuǎn)是重復(fù)勞動AI 也永遠(yuǎn)不會變得更適合這個團隊的業(yè)務(wù)。6. 常見坑自動化率數(shù)字很好看系統(tǒng)卻很快壞掉6.1 把“能生成”當(dāng)成“能交付”現(xiàn)象演示時模型生成的結(jié)果很完整上線后發(fā)現(xiàn)用戶無法直接使用格式、口徑、數(shù)據(jù)來源都不可靠。原因生成和交付之間隔著校驗。解決把校驗做成強制環(huán)節(jié)用規(guī)則檢查格式、用程序檢查可執(zhí)行性、用模型檢查語義。至少要有兩道檢查才能進(jìn)入交付。6.2 沒有評測集質(zhì)量爭吵永遠(yuǎn)無法收斂現(xiàn)象