FDE做能落地的AI解決方案，關鍵是理解和控制邊界

做了數十個 AI 解決方案項目後，我越來越覺得：要落地，最關鍵的不是一上來證明 AI 有多強，而是先把邊界想清楚。

哪些事情應該讓系統自動完成？
哪些事情應該讓 AI 參與判斷？
哪些事情必須保留人工確認？
AI 能看什麼數據？能調用什麼工具？能不能寫入系統？
出了錯誰負責？結果怎麼驗證？

這些問題如果沒提前想清楚，項目看起來能跑，一進入真實業務就會出問題。

所以我認為，FDE 的價值不只是"把需求轉成方案"，更重要的是：把一個模糊的 AI 想法，放進一套有邊界、有流程、有驗證、有責任的業務系統裏。

這就涉及到 Harness Engineering 的思路。

我對 Harness Engineering 的理解很簡單：模型不是產品，圍繞模型建立起來的運行環境，才是真正的產品。

模型只是一個能力。它會理解、會生成、會推理，但它不天然知道企業的權限，不知道哪些數據能看，不知道哪些動作有風險，也不知道一個結果錯了以後會帶來什麼後果。

所以真正要做的，不是把模型接進來，而是給模型設計一個可控的工作環境。

這個環境裏要有上下文、工具、權限、流程、狀態、日誌、人工確認和結果驗證。

換句話說，FDE 要設計的不是"AI 能不能做"，而是：

這才是企業 AI 落地真正難的地方。具體可以拆成七個邊界。

一、任務邊界：不是所有環節都需要 Agent

很多人一聽到客戶說要 AI Agent，就默認所有環節都要 Agent 化。這個判斷很危險。

有些任務根本不需要 AI。

數據清洗、字段轉換、格式校驗、基礎圖表生成、報表模板渲染，本質上都是確定性任務。規則清楚，輸入輸出清楚。用 Pipeline、腳本、SQL、工作流，反而更穩定。

硬用 Agent，成本更高，結果還更不穩定。

有些任務需要 AI。

數據洞察、異常解釋、商品賣點提煉、創意方向拆解、經營建議生成，背後有語義理解、上下文判斷和不確定性。這個時候 AI 才有價值。

有些任務才真正需要 Agent。

比如讀取數據、分析問題、調用工具、生成方案、等待反饋、繼續推進。它不是單次生成，而是連續行動。這種場景才需要 Agent。

還有些任務屬於高風險任務。

預算調整、客戶發送、正式發佈、財務動作、批量修改業務數據，就算 AI 能做，也不能一開始全自動做。必須有人審、有日誌、有回滾、有責任邊界。

所以 FDE 做方案的第一個判斷，不是"要不要用 AI"，而是判斷這件事到底屬於哪一類：

是確定性流程？
是語義判斷？
是連續行動？
還是高風險決策？

邊界一旦判斷錯，後面的方案就會走偏。

以數據運營 AI Agent 項目為例，客戶想要的是"讓沒有數據基礎的人也能出報告"。但這不代表整個鏈路都要 Agent 化。

▎ 數據清洗用 Pipeline。

▎ 數據可視化用圖表模板。

▎ 指標口徑用規則和字典。

▎ AI 放在洞察解釋和行動建議環節。

▎ 最後報告是否成立，由業務人員確認。

這才是合理的任務邊界。

二、上下文邊界：AI 不是知道得越多越好

很多項目喜歡把資料、文檔、數據一股腦塞給模型，好像給得越多，AI 就越聰明。

但企業場景裏，這樣很容易出問題。

AI 能看到哪些數據？
這些數據來自哪裏？
字段是什麼意思？
指標口徑是什麼？
數據是否過期？
哪些是事實，哪些是推測？
哪些內容只能當前任務使用，哪些可以沉澱成長期經驗？
不同崗位看到的上下文是否一樣？

這些都必須提前定義。

比如數據分析場景，只給 AI 一張表，它可以寫出一段看起來不錯的分析。但它可能不知道這個指標代表什麼，不知道最近業務策略變了，更不知道這個渠道剛換過素材。

結果就是分析有語言，但沒有判斷。

真正有價值的上下文，不只是數據本身，而是數據背後的業務語義。

FDE 要設計的不是"把數據接給 AI"，而是讓 AI 在正確的數據、正確的口徑、正確的權限、正確的業務背景下工作。

這就是上下文邊界。

三、工具邊界：Agent 一旦能調用工具，風險就變了

AI Agent 一旦能調用工具，它就不只是聊天了，它開始有行動能力。

它能不能讀數據庫？
能不能生成報表？
能不能寫入系統？
能不能發消息？
能不能導出文件？
能不能扣費？
能不能發佈內容？

這些工具不能隨便開放。每一個工具都應該被聲明清楚：

它是做什麼的？
輸入是什麼？
輸出是什麼？
風險是什麼？
失敗了怎麼處理？
調用前需不需要權限判斷？
調用後需不需要記錄？

以數據運營 Agent 為例，可能有很多工具：讀取數據源、執行清洗任務、生成圖表、查詢指標口徑、生成分析初稿、導出報告、寫入業務系統。

但這些工具的風險完全不同。

▎ 讀取數據和寫入系統不是一回事。

▎ 生成草稿和正式導出不是一回事。

▎ 給內部看和發給客戶不是一回事。

所以方案裏必須寫清楚：哪些工具第一階段開放，哪些工具只讀，哪些工具只能生成草稿，哪些工具必須人工確認，哪些工具暫時不開放。

這不是保守，而是讓客戶放心。

四、動作邊界：不能把"自動處理"混為一談

"AI 自動處理業務流程"，這種說法太粗了。

自動處理什麼？
讀數據？寫數據？生成建議？發送客戶？調整預算？刪除記錄？發佈內容？

這些動作不能混在一起。

我認為至少要分成六類：

▎讀取：看數據、查資料、讀文檔。

▎草稿：生成報告、生成建議、生成素材方案。

▎低風險寫入：保存草稿、更新任務狀態。

▎外部發送：發郵件、發客戶消息、發佈內容。

▎財務動作：扣費、投放、預算調整。

▎不可逆動作：刪除、覆蓋、批量修改、正式提交。

不同動作，邊界完全不同。

AI 可以自動讀取，也可以自動生成草稿，但不代表它可以自動發送、自動扣費、自動發佈、自動刪除。

這就是為什麼企業 AI 不能只靠一句"需要人工審核"。

真正的設計應該是：

在哪個節點審核？
誰審核？
審核什麼？
審核後進入哪裏？
審核記錄保存在哪裏？
出錯後怎麼追溯？

只有這樣，AI 才能進入正式流程。

五、模型邊界：成本、幻覺，以及不能綁死

大模型有能力，也有邊界。

最明顯的是成本邊界和幻覺邊界。

成本邊界不是隻看一次調用多少錢。一個任務人工做一次可能只要十分鐘，看起來不值得自動化。但如果這個任務每天發生、每個人都做、每次還依賴經驗，那成本就不只是十分鐘。

它還包括培訓成本、返工成本、經驗流失成本、響應速度成本。

所以判斷 AI 值不值得用，不能只看 API 花費，要看它能不能降低長期組織成本。

幻覺邊界也一樣。

大模型可能會錯，這是它的基本屬性。關鍵不是假裝它不會錯，而是把可能出錯的地方放進可控流程裏。

▎ 低風險內容，可以讓 AI 直接生成。

▎ 中風險內容，需要人工確認。

▎ 高風險決策，必須有審核和記錄。

▎ 不能承擔錯誤後果的事情，就不能交給 AI 自動完成。

除此之外，還有一個重要邊界：模型不能綁死。

一個成熟系統不應該把業務邏輯綁定在某個模型上。模型會變，價格會變，能力會變，供應商也會變。

真正應該沉澱的是流程、工具、數據、權限、評估和業務知識。

模型可以替換，但系統能力不能推倒重來。

六、組織邊界：個人用和組織用，不是一回事

個人用 AI，更關心效率。

只要對自己有用，能幫自己快一點、好一點，就可以接受。

但組織用 AI，問題複雜很多。

組織會關心：

誰發起了任務？
AI 用了哪些數據？
調用了哪些工具？
花了多少錢？
結果誰審核過？
誰修改過？
客戶數據有沒有泄露？
不同部門數據有沒有串？
出了問題怎麼追責？
經驗能不能沉澱給新人？

所以企業 AI 系統不只是提效工具，它一定會變成組織管理系統的一部分。

這時候就必須有記錄、權限、審計、版本、成本、審批和覆盤。

這些東西不是錦上添花，而是組織使用 AI 的基礎設施。

如果沒有這些，AI 越強，風險越大。

七、驗證邊界：沒有驗證，就沒有結果承諾

AI 項目不能只靠感覺判斷好不好。

很多項目演示時效果不錯，但上線以後沒人用，或者用了幾次就放棄。原因就是沒有定義什麼叫成功。

數據運營報告什麼叫成功？

▎ 生成時間縮短？

▎ 指標口徑錯誤減少？

▎ 非數據人員也能出初稿？

▎ 業務負責人審核通過率提升？

▎ 行動建議真的被採納？

Amazon 圖文物料什麼叫成功？

▎ SKU 上架週期縮短？

▎ 圖片返工次數下降？

▎ Listing 完整度提高？

▎ 素材複用率提升？

▎ 風格更統一？

▎ 轉化相關指標變好？

這些必須提前寫清楚。

所以 FDE 不能只交一個功能清單，而要交一套驗證方式：用什麼樣本測，測什麼指標，誰來判斷，錯誤怎麼記錄，後續怎麼優化。

這才是 AI 從演示走向上線的關鍵。

邊界不是限制，而是信任的來源

"邊界"這個詞，很容易被誤解成限制。

但在企業 AI 落地裏，邊界不是限制，而是信任的來源。

沒有邊界，AI 看起來很自由，但客戶不敢真正用。
有了邊界，AI 看起來沒那麼炫，但它能進入真實流程。

FDE 的價值，不是把 AI 講得無所不能，而是把 AI 放到企業真正敢用的位置。

真正的價值是：你能幫客戶判斷，哪些事情該做，哪些不該做；哪些地方該自動化，哪些地方該智能化；哪些結果可以直接用，哪些必須審核；哪些能力可以上線，哪些還要驗證。

這才是解決方案的專業度。

因為客戶最終買的不是一個模型，也不是一個 Agent。

所以 FDE 做方案，最重要的不是把 AI 講得多厲害，而是把 AI 放進正確的邊界裏。

當邊界清楚了，流程才清楚。
流程清楚了，責任才清楚。
責任清楚了，客戶才敢用。
客戶敢用，AI 才真正進入企業。