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