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