一個企業 AI 項目，應該怎麼從需求走到解決方案？
整理版優先睇
企業AI項目要從業務目標開始，唔係從技術出發；需求只係入口，流程先係現場，機制先係問題核心。
呢篇文章出自彭俊旗，一個FDE（前端開發工程師？但文中FDE似是指方案設計角色），佢分享咗自己處理企業AI項目嘅經驗同反思。作者發現好多初級FDE一聽到客戶需求就諗工具，但呢個順序係反嘅。佢引用咗Google Cloud、OpenAI、Anthropic、McKinsey、NIST嘅公開資料，指出業界共識：AI項目要從業務目標開始，定義可衡量結果，理解端到端流程，揀最簡單可控嘅架構，提前設計評估同風險邊界。整體結論係：由需求到解決方案，本質係將一個模糊表達翻譯成一條可執行、可驗證、可上線、可持續迭代嘅業務鏈路。
文章詳細拆解咗九個步驟，由還原客戶真正想要嘅結果，到畫出業務鏈路、分析問題反覆發生嘅機制、判斷AI應唔應該介入、設計人-AI-系統分工、收斂到第一階段閉環、定義驗證方式、寫清楚風險邊界，最後交付一份完整嘅解決方案。作者強調，解決方案唔係功能清單，而係要包含業務目標、當前流程、問題機制、AI介入點、系統分工、數據資料、第一階段閉環、驗證指標、風險邊界同迭代路徑。
呢篇文嘅價值在於提供咗一套可操作嘅思考框架，幫助方案設計者由客戶一句「我想做AI Agent」開始，逐步拆解成真正跑得鬱嘅業務系統。
- AI項目第一步係唔好直接諗工具，要還原客戶最終想改善嘅業務結果，例如更快、更準、更穩定。
- 將需求放返真實流程入面，畫出業務鏈路，找出最耗時、最容易返工、全靠經驗嘅節點。
- 問題反覆發生係因為機制有問題，例如數據輸入唔穩定、指標口徑唔統一；要改機制而唔係只加AI工具。
- 唔係所有環節都需要AI，確定性事情用Pipeline、腳本等系統，語義理解先用AI，複雜任務先用Agent。
- 解決方案要寫清楚人、AI、系統嘅分工，包括邊啲動作只生成草稿、邊啲必須人工確認，同埋定義明確嘅驗證指標同風險邊界。
由業務目標開始，還原客戶真正想要嘅結果
客戶講「我要一個數據分析Agent」，好多時只係佢想像中嘅解法，唔係真正問題。FDE第一件事唔係問功能，而係問：你最終想令邊個結果變好？係更快、更準、更穩定、更可複製，定係令新人做到熟手先做到嘅事？如果呢個結果講唔清，之後所有方案都會飄。因為工具可以好多，但業務結果只有一個方向。
- 寫低客戶最終想改善嘅指標，例如報告生成時間、圖文返工次數、銷售跟進穩定性。
- 用呢個結果反推需要咩能力，而唔係由模型或框架開始。
將需求放返真實流程，畫出業務鏈路
需求唔可以孤立看待。客戶話「報告太慢」，你要睇報告點樣生產出嚟：數據邊度嚟？邊個導出？邊個清洗？指標口徑邊個定義？圖表邊個做？業務背景邊個補？結論邊個審？報告俾邊個睇？睇完有冇action？下次會唔會複用？呢啲細節先係現場。
畫出業務鏈路，唔係畫靚流程圖，而係拆出真實動作：邊個做、用咩資料、經過邊啲系統、邊度最耗時、邊度最容易返工、邊度全靠經驗、邊度冇人負責閉環。
- 記錄每個步驟嘅負責人、輸入產出、耗時、返工率。
- 標記出「全靠經驗」嘅節點，呢啲位通常係AI最佳切入點。
找出問題反覆發生嘅機制，而唔係只治標
好多方案寫得太淺，只寫症狀：報告慢就自動生成報告，圖片返工就AI出圖。但FDE要繼續問：點解呢個問題會反覆發生？報告慢可能唔係唔識寫分析，而係數據輸入唔穩定、指標口徑唔統一、業務上下文冇固定輸入方式。圖片返工可能係商品賣點、品牌風格、渠道規格、審核標準冇預先定義清楚。
- 列出問題反覆出現嘅根本原因，例如數據源唔統一、審核標準模糊。
- 針對機制設計解決方案，而唔係單靠AI生成。
判斷AI係咪要介入，定係用自動化就得
唔係所有環節都需要AI。確定性嘅事情——字段清洗、格式轉換、指標計算、模板渲染、權限校驗、狀態流轉——規則清楚、輸入輸出穩定，用Pipeline、腳本、SQL、工作流往往更可靠。需要語義理解同判斷嘅地方先適合AI，例如解釋異常、提煉賣點、生成內容方向、拆解客戶意圖。需要連續觀察、調用工具、根據結果推進嘅複雜任務，先考慮Agent。
方案入面一定要寫清楚：邊啲地方唔用AI、邊啲用自動化、邊啲用AI生成或分析、邊啲用Agent、邊啲必須人工確認。
- 列舉任務類型：固定規則用自動化，語義彈性用AI，多步驟動態用Agent。
- 講得清「唔用AI」嘅地方，反而令客戶更信任。
設計人、AI、系統各自嘅位置同責任
好多方案淨係寫「AI自動完成」，呢句太粗。AI自動完成啲乜？讀取資料？整理數據？生成草稿？提出建議？寫入系統？發俾客戶？調整預算？正式發佈？呢啲動作風險完全唔同。解決方案必須將人、AI、系統嘅分工寫清楚：AI負責咩、系統記錄咩、人判斷咩、邊個審核、邊個負責、邊度留痕、邊度可以回滾。
- 數據報告場景：AI生成洞察同action建議，業務人員確認背景，負責人判斷係咪執行。
- 圖文物料場景：AI生成賣點、brief、Listing、圖片方向，運營或品牌負責人判斷市場策略、品牌風格、平台風險。
收斂成第一階段閉環，由細開始驗證
好多AI方案落唔到地，因為一開始太大：全流程智能化、全公司統一平台、多智能體協同、所有系統打通。聽起嚟完整，但交付風險高，客戶難睇到結果。更合理嘅做法係先選一個真實、高頻、可驗證嘅小閉環。例如數據營運，唔好一開始做全公司智能分析平台，先做一個固定報告場景：周度經營分析、投放覆盤、渠道表現報告，將數據輸入、清洗、指標計算、圖表生成、業務背景補充、AI洞察、人工確認、報告輸出跑通。
第一階段最重要係令客戶見到「呢條鏈路真係跑得鬱，結果真係驗證到，後面真係可以擴展」
- 揀一個高頻、痛點明顯、數據相對乾淨嘅場景做試點。
- 第一階段範圍要細，但必須完整——由輸入到輸出到人工確認。
「AI 項目唔可以由技術開始，要由業務目標開始。要定義可以量度嘅結果，要理解由頭到尾嘅流程，要揀最簡單最可控嘅架構，要預先設計評估同風險邊界。」 |
呢段時間，我發現一個初級 FDE 做 AI 項目，最易犯嘅一個錯，就係客一講需求，服務方就開始諗工具。
客戶話：“我想做一個 AI Agent。”於是即刻諗：用咩模型？用咩框架？要唔要多智能體？要唔要接知識庫？要唔要做工作流？
但我而家越來越覺得，呢個順序係反嘅。
一個企業 AI 項目，真正應該先解決嘅，唔係“用咩工具做”，而係“呢個需求到底要解決咩業務問題”。
我睇咗一啲公開資料，包括 Google Cloud、OpenAI、Anthropic、McKinsey、NIST 呢啲關於企業 AI 落地同智能體建設嘅內容。佢哋表述方式唔同，但底層共識好一致：AI 項目唔可以由技術開始，要由業務目標開始。
要定義可以量度嘅結果，要理解由頭到尾嘅流程，要揀最簡單同可控嘅架構，要預先設計評估同風險邊界。呢個同我做 FDE 項目嘅感受係一樣嘅。
企業 AI 項目由需求走到解決方案，本質上唔係寫一份方案文件，而係將一個模糊表達，翻譯成一條可執行、可驗證、可上線、可持續迭代嘅業務鏈路。
一、第一步，唔係接住需求，而係還原結果
客戶講出來嘅需求，好多時唔係問題本身，而係佢想像中嘅解法。
佢話“我要一個數據分析 Agent”，可能真正想要嘅係：令到冇數據基礎嘅業務人員，都可以更快、更準咁出經營報告。
佢話“我要 AI 做圖文物料”，可能真正想要嘅係：縮短 SKU 上架週期，減少圖文返工，令商品賣點、圖片同 Listing 更一致。
佢話“我要做 AI 培訓”，可能真正想要嘅係：令團隊真係將 AI 用到業務裏面，而唔係聽完課之後仲係唔識做項目。
所以 FDE 第一件事，唔係問“你想做邊啲功能”。而係問：你最尾想令邊個結果變好？係更快？更準？更穩定？更可複製？定係令新人都可以完成以前只有熟手先做到嘅事？
如果呢個結果講唔清，後面所有方案都會漂。因為工具可以好多，架構可以好多，但業務結果只有一個方向。
二、第二步，將需求放返真實流程裏面
需求唔可以孤立咁睇。客戶話“報告太慢”，你唔可以淨係睇報告。你要睇報告係點樣被生產出來嘅。
數據從邊度來？邊個導出？邊個清洗？指標口徑邊個定義？圖表邊個做？業務背景邊個補？結論邊個審核？報告俾邊個睇？睇完之後有冇 action？下次會唔會複用？
客戶話“圖文物料效率低”，你都唔可以淨係看出圖。商品資料從邊度來？賣點點樣提煉？關鍵詞點樣整理？圖片 brief 邊個寫？Listing 同圖片邊個對齊？邊個審核？返工原因有冇記錄？高轉化素材有冇複用？
呢一步嘅核心，係畫出業務鏈路。唔係畫一張靚仔嘅流程圖，而係將真實現場裏面嘅動作拆出來：
▎ 邊個在做？
▎ 用咩資料？
▎ 經過邊啲系統？
▎ 邊度最耗時？
▎ 邊度最容易返工？
▎ 邊度全靠經驗？
▎ 邊度冇人負責閉環？
好多 AI 項目嘅破局點，唔喺客戶嘅嗰句話裏面，而喺呢條流程裏面。流程一畫出來，你先知 AI 應該企喺邊個位置。
三、第三步，揾到問題反覆發生嘅機制
好多方案寫淺咗，係因為淨係寫症狀。報告慢，就寫自動生成報告。圖片返工，就寫 AI 出圖。銷售跟進唔穩定，就寫 AI 銷售助手。呢啲唔夠。
FDE 要繼續問落去：呢個問題點解會反覆發生？
報告慢，可能唔係因為唔識寫分析，而係數據輸入唔穩定、指標口徑唔統一、業務上下文冇固定輸入方式。圖片返工，可能唔係因為設計效率低，而係商品賣點、品牌風格、渠道規格、審核標準冇喺前面定義清楚。銷售跟進差，可能唔係因為銷售唔識寫話術，而係客戶畫像、需求判斷、跟進節奏、成交經驗冇結構化。
如果機制唔改，淨係做一個 AI 工具，項目好容易變成 demo。睇落好似行到，但入唔到真實業務。真正嘅解決方案，必須打喺機制上。
四、第四步，判斷 AI 到底要唔要介入
唔係所有環節都需要 AI。呢個係好多企業 AI 項目裏面最容易被忽略嘅一點。
確定性嘅事情，優先採用確定性系統。字段清洗、格式轉換、指標計算、模板渲染、權限校驗、狀態流轉，呢啲事情規則清楚，輸入輸出穩定，Pipeline、腳本、SQL、工作流往往更可靠。
需要語義理解同判斷嘅地方，先更適合 AI。例如解釋異常、提煉賣點、生成內容方向、拆解客戶意圖、形成行動建議、整理多種可能原因。
需要連續觀察、調用工具、根據結果繼續推進嘅複雜任務，先考慮 Agent。
所以方案裏面一定要寫清楚：
▎ 邊啲地方唔用 AI。
▎ 邊啲地方用自動化。
▎ 邊啲地方用 AI 生成或分析。
▎ 邊啲地方需要 Agent。
▎ 邊啲地方必須人工確認。
能夠將“唔用 AI 嘅地方”講清楚，反而會令客戶更信任你。因為客戶要嘅唔係你炫技，而係結果穩定。
五、第五步，設計人、AI、系統各自嘅位置
好多方案最大嘅問題，係淨係寫“AI 自動完成”。呢句話太粗疏喇。
AI 自動完成啲咩？讀取資料？整理數據？生成草稿？提出建議？寫入系統？發俾客戶？調整預算？正式發佈？呢啲動作風險完全唔同。
所以解決方案必須將人、AI、系統嘅分工寫清楚。AI 負責咩？系統記錄咩？人判斷咩？邊個審核？邊個負責？邊度留痕？邊度可以回滾？
例如數據報告場景，AI 可以生成洞察同 action 建議，但業務人員必須確認背景是否成立，負責人要判斷 action 是否執行。例如圖文物料場景，AI 可以生成賣點、brief、Listing、圖片方向，但運營或品牌負責人要判斷是否符合市場策略、品牌風格同平台風險。
企業 AI 化，唔係將人拎走。而係令人從大量中間動作裏面出來，企喺判斷同負責嘅位置上。
六、第六步，將方案收斂成第一階段閉環
好多 AI 方案落唔到地，係因為一開始太大。一嚟就做全流程智能化、全公司統一平台、多智能體協同、所有系統打通。聽落好完整，但交付風險好高，客戶都好難即刻見到結果。
更合理嘅方式，係先揀一個真實、高頻、可驗證嘅小閉環。例如數據運營，唔好一開始就做全公司智能分析平台。先做一個固定報告場景：周度經營分析、投放覆盤、渠道表現報告。將數據輸入、清洗、指標計算、圖表生成、業務背景補充、AI 洞察、人工確認、報告輸出跑通。
例如 Amazon 圖文物料，唔好一開始覆蓋所有平台同品類。先揀一個品類，將商品理解、賣點提煉、圖片 brief、Listing 生成、圖片 QA、導出交付包跑通。
第一階段唔係越大越好。第一階段最重要係令客戶見到：呢條鏈路真係行到，結果真係驗證到，後面真係擴展到。
七、第七步，喺方案裏面提前定義驗證方式
OpenAI 關於 evals 嘅資料裏面有一個觀點我好認同：如果你唔可以定義咩叫“好”，你就好難真係做得好。
企業 AI 項目都係一樣。唔可以淨係話“提升效率”“提升質量”“降低成本”。呢啲都太大。要具體到：
▎ 報告生成時間有冇縮短？
▎ 指標錯誤有冇減少？
▎ 非數據人員可唔可以獨立完成初稿？
▎ 圖文返工次數有冇下降？
▎ Listing 完整度有冇提高？
▎ 銷售準備時間有冇減少？
▎ 新人上手週期有冇縮短？
▎ 審核通過率有冇提高？
驗證指標唔一定一開始就非常完美，但必須要有。冇驗證，項目就只能靠感覺。感覺唔錯，唔代表業務真係變好咗。
所以 FDE 寫解決方案，一定要預先寫清楚：第一階段用咩樣本測，測咩指標，邊個判斷，結果唔達標點樣迭代。
八、第八步，寫清楚風險邊界同責任邊界
企業 AI 項目唔係個人玩工具。一旦 AI 進入業務流程，就會涉及數據、權限、客戶、品牌、財務、合規、責任。
所以方案唔可以淨係寫功能，仲要寫邊界。AI 可以睇邊啲數據？唔可以睇邊啲數據？可唔可以調用工具？可唔可以寫入系統？邊啲動作只可以生成草稿？邊啲動作必須人工確認？出咗錯點追溯？日誌保存喺邊度？邊個最終負責？
NIST 嘅 AI 風險管理框架講嘅係更大嘅風險治理，但落到企業項目裏面，其實就係呢啲問題。如果呢啲邊界唔清楚，AI 越能幹，客戶越唔敢用。
邊界唔係限制 AI。邊界係令 AI 可以進入正式業務嘅前提。
九、最後，解決方案應該交付啲咩
我認為一份真正可以打動客戶嘅 AI 解決方案，唔應該只係功能清單。佢至少應該交付呢啲嘢：
▎ 業務目標：客戶到底想令咩結果變好。
▎ 當前流程：呢件事而家係點做。
▎ 問題機制：點解呢個問題會反覆發生。
▎ AI 介入點：AI 應該企喺邊啲節點。
▎ 系統分工：邊啲用 Pipeline，邊啲用 AI，邊啲用 Agent，邊啲由人判斷。
▎ 數據資料：需要邊啲業務上下文、知識、樣本、標準。
▎ 第一階段閉環：先行邊條最小鏈路。
▎ 驗證指標：點證明項目有效。
▎ 風險邊界：邊啲動作唔可以自動化，邊啲結果必須審核。
▎ 迭代路徑：第一階段行通之後，後面點樣擴展。
呢個先叫由需求走到解決方案。唔係客戶話要 Agent，你就俾佢 Agent。而係客戶話要 Agent，你可以繼續問落去：你到底想改善邊件事？而家點解做唔到？呢條流程點行？邊度反覆出問題？AI 應該承擔邊一段？人應該保留邊一段判斷？第一階段點驗證？後面點樣沉澱成系統能力？
結語
企業 AI 項目由需求走到解決方案，最難嘅唔係寫 PPT，亦唔係揀模型。最難嘅係將客戶一句模糊嘅需求，拆成真實業務問題，再將真實業務問題，設計成一條行得鬱嘅業務鏈路。
需求只係入口。流程先係現場。機制先係問題。邊界決定可唔可以上線。驗證決定有冇結果。沉澱決定呢個項目可唔可以從一次性交付，變成企業自己嘅能力。
呢個都係 FDE 喺企業 AI 落地裏面嘅價值。唔係將 AI 工具搬入企業。而係幫企業睇清楚：邊條業務鏈路值得改，AI 應該企喺邊度，人應該負責啲咩，系統應該記錄啲咩，最後點樣證明呢件事真係做成咗。
一個 AI 項目，只有行完呢條路，先唔只係一個 demo。佢先有機會變成企業裏面真正行得鬱嘅業務系統。
唔係將 AI 工具搬入企業。 需求只係入口，流程先係現場。 |
Resona · 鳴 · 令每一次對話，都有迴響 2026-06-04 · 彭俊旗 |
「AI 項目不能從技術開始，要從業務目標開始。要定義可衡量的結果，要理解端到端流程，要選擇最簡單可控的架構，要提前設計評估和風險邊界。」 |
這段時間，我發現一個初級 FDE 做 AI 項目，最容易犯的一個錯，就是客戶一說需求，服務方就開始想工具。
客戶說：“我想做一個 AI Agent。”於是馬上想：用什麼模型？用什麼框架？要不要多智能體？要不要接知識庫？要不要做工作流？
但我現在越來越覺得，這個順序是反的。
一個企業 AI 項目，真正應該先解決的，不是“用什麼工具做”，而是“這個需求到底要解決什麼業務問題”。
我看了一些公開資料，包括 Google Cloud、OpenAI、Anthropic、McKinsey、NIST 這些關於企業 AI 落地和智能體建設的內容。它們表述方式不同，但底層共識很一致：AI 項目不能從技術開始，要從業務目標開始。
要定義可衡量的結果，要理解端到端流程，要選擇最簡單可控的架構，要提前設計評估和風險邊界。這和我做 FDE 項目的感受是一樣的。
企業 AI 項目從需求走到解決方案，本質上不是寫一份方案文檔，而是把一個模糊表達，翻譯成一條可執行、可驗證、可上線、可持續迭代的業務鏈路。
一、第一步，不是接住需求，而是還原結果
客戶說出來的需求，很多時候不是問題本身，而是他想象中的解法。
他說“我要一個數據分析 Agent"，可能真正想要的是：讓沒有數據基礎的業務人員，也能更快、更準地出經營報告。
他說“我要 AI 做圖文物料”，可能真正想要的是：縮短 SKU 上架週期，減少圖文返工，讓商品賣點、圖片和 Listing 更一致。
他說“我要做 AI 培訓”，可能真正想要的是：讓團隊真的把 AI 用到業務裏，而不是聽完課以後還是不會做項目。
所以 FDE 第一件事，不是問“你想做哪些功能”。而是問：你最終想讓哪個結果變好？是更快？更準？更穩定？更可複製？還是讓新人也能完成以前只有熟手能做的事？
如果這個結果說不清，後面所有方案都會漂。因為工具可以很多，架構可以很多，但業務結果只有一個方向。
二、第二步，把需求放回真實流程裏
需求不能孤立看。客戶說“報告太慢”，你不能只看報告。你要看報告是怎麼被生產出來的。
數據從哪裏來？誰導出？誰清洗？指標口徑誰定義？圖表誰做？業務背景誰補？結論誰審核？報告給誰看？看完以後有沒有 action？下次會不會複用？
客戶說“圖文物料效率低”，你也不能只看出圖。商品資料從哪裏來？賣點怎麼提煉？關鍵詞怎麼整理？圖片 brief 誰寫？Listing 和圖片誰對齊？誰審核？返工原因有沒有記錄？高轉化素材有沒有複用？
這一步的核心，是畫出業務鏈路。不是畫一張好看的流程圖，而是把真實現場裏的動作拆出來：
▎ 誰在做？
▎ 用什麼資料？
▎ 經過哪些系統？
▎ 哪裏最耗時？
▎ 哪裏最容易返工？
▎ 哪裏全靠經驗？
▎ 哪裏沒人負責閉環？
很多 AI 項目的破局點，不在客戶的那句話裏，而在這條流程裏。流程一畫出來，你才知道 AI 應該站在哪個位置。
三、第三步，找到問題反覆發生的機制
很多方案寫淺了，是因為只寫症狀。報告慢，就寫自動生成報告。圖片返工，就寫 AI 出圖。銷售跟進不穩定，就寫 AI 銷售助手。這不夠。
FDE 要繼續往下問：這個問題為什麼會反覆發生？
報告慢，可能不是因為不會寫分析，而是數據輸入不穩定、指標口徑不統一、業務上下文沒有固定輸入方式。圖片返工，可能不是因為設計效率低，而是商品賣點、品牌風格、渠道規格、審核標準沒有在前面定義清楚。銷售跟進差，可能不是因為銷售不會寫話術，而是客戶畫像、需求判斷、跟進節奏、成交經驗沒有結構化。
如果機制不改，只做一個 AI 工具，項目很容易變成 demo。看起來能跑，但進不了真實業務。真正的解決方案，必須打在機制上。
四、第四步，判斷 AI 到底要不要介入
不是所有環節都需要 AI。這是很多企業 AI 項目裏最容易被忽略的一點。
確定性的事情，優先用確定性系統。字段清洗、格式轉換、指標計算、模板渲染、權限校驗、狀態流轉，這些事情規則清楚，輸入輸出穩定，Pipeline、腳本、SQL、工作流往往更可靠。
需要語義理解和判斷的地方，才更適合 AI。比如解釋異常、提煉賣點、生成內容方向、拆解客戶意圖、形成行動建議、整理多種可能原因。
需要連續觀察、調用工具、根據結果繼續推進的複雜任務，才考慮 Agent。
所以方案裏一定要寫清楚：
▎ 哪些地方不用 AI。
▎ 哪些地方用自動化。
▎ 哪些地方用 AI 生成或分析。
▎ 哪些地方需要 Agent。
▎ 哪些地方必須人工確認。
能把“不用 AI 的地方”講清楚，反而會讓客戶更信任你。因為客戶要的不是你炫技，而是結果穩定。
五、第五步，設計人、AI、系統各自的位置
很多方案最大的問題，是隻寫"AI 自動完成”。這句話太粗了。
AI 自動完成什麼？讀取資料？整理數據？生成草稿？提出建議？寫入系統？發給客戶？調整預算？正式發佈？這些動作風險完全不同。
所以解決方案必須把人、AI、系統的分工寫清楚。AI 負責什麼？系統記錄什麼？人判斷什麼？誰審核？誰負責？哪裏留痕？哪裏可以回滾？
比如數據報告場景，AI 可以生成洞察和 action 建議，但業務人員必須確認背景是否成立，負責人要判斷 action 是否執行。比如圖文物料場景，AI 可以生成賣點、brief、Listing、圖片方向，但運營或品牌負責人要判斷是否符合市場策略、品牌風格和平台風險。
企業 AI 化，不是把人拿掉。而是讓人從大量中間動作裏出來，站到判斷和負責的位置上。
六、第六步，把方案收斂成第一階段閉環
很多 AI 方案落不下去，是因為一開始太大。上來就做全流程智能化、全公司統一平台、多智能體協同、所有系統打通。聽起來很完整，但交付風險很高，客戶也很難馬上看到結果。
更合理的方式，是先選一個真實、高頻、可驗證的小閉環。比如數據運營，不要一開始做全公司智能分析平台。先做一個固定報告場景：周度經營分析、投放覆盤、渠道表現報告。把數據輸入、清洗、指標計算、圖表生成、業務背景補充、AI 洞察、人工確認、報告輸出跑通。
比如 Amazon 圖文物料，不要一開始覆蓋所有平台和品類。先選一個品類，把商品理解、賣點提煉、圖片 brief、Listing 生成、圖片 QA、導出交付包跑通。
第一階段不是越大越好。第一階段最重要的是讓客戶看到：這條鏈路真的能跑，結果真的能驗證，後面真的能擴展。
七、第七步，在方案裏提前定義驗證方式
OpenAI 關於 evals 的資料裏有一個觀點我很認同：如果你不能定義什麼叫“好”，你就很難真正做到好。
企業 AI 項目也是一樣。不能只說“提升效率”“提升質量”“降低成本”。這些都太大。要具體到：
▎ 報告生成時間有沒有縮短？
▎ 指標錯誤有沒有減少？
▎ 非數據人員能不能獨立完成初稿？
▎ 圖文返工次數有沒有下降？
▎ Listing 完整度有沒有提高？
▎ 銷售準備時間有沒有減少？
▎ 新人上手週期有沒有縮短？
▎ 審核通過率有沒有提高？
驗證指標不一定一開始就非常完美，但必須有。沒有驗證，項目就只能靠感覺。感覺不錯，不代表業務真的變好了。
所以 FDE 寫解決方案，一定要提前寫清楚：第一階段用什麼樣本測，測什麼指標，誰來判斷，結果不達標怎麼迭代。
八、第八步，寫清楚風險邊界和責任邊界
企業 AI 項目不是個人玩工具。一旦 AI 進入業務流程，就會涉及數據、權限、客戶、品牌、財務、合規、責任。
所以方案不能只寫功能，還要寫邊界。AI 能看哪些數據？不能看哪些數據？能不能調用工具？能不能寫入系統？哪些動作只能生成草稿？哪些動作必須人工確認？出了錯怎麼追溯？日誌保存在哪裏？誰最終負責？
NIST 的 AI 風險管理框架講的是更大的風險治理，但落到企業項目裏，其實就是這些問題。如果這些邊界不清楚，AI 越能幹，客戶越不敢用。
邊界不是限制 AI。邊界是讓 AI 能進入正式業務的前提。
九、最後，解決方案應該交付什麼
我認為一份真正能打動客戶的 AI 解決方案，不應該只是功能清單。它至少要交付這些東西：
▎ 業務目標：客戶到底想讓什麼結果變好。
▎ 當前流程：這件事現在怎麼做。
▎ 問題機制：為什麼這個問題會反覆發生。
▎ AI 介入點：AI 應該站在哪些節點。
▎ 系統分工：哪些用 Pipeline，哪些用 AI，哪些用 Agent，哪些由人判斷。
▎ 數據資料：需要哪些業務上下文、知識、樣本、標準。
▎ 第一階段閉環：先跑哪條最小鏈路。
▎ 驗證指標：怎麼證明項目有效。
▎ 風險邊界：哪些動作不能自動化，哪些結果必須審核。
▎ 迭代路徑：第一階段跑通後，後面怎麼擴展。
這才叫從需求走到解決方案。不是客戶說要 Agent，你就給他 Agent。而是客戶說要 Agent，你能繼續往下問：你到底想改善哪件事？現在為什麼做不到？這條流程怎麼跑？哪裏反覆出問題？AI 應該承擔哪一段？人應該保留哪一段判斷？第一階段怎麼驗證？後面怎麼沉澱成系統能力？
結語
企業 AI 項目從需求走到解決方案，最難的不是寫 PPT，也不是選模型。最難的是把客戶一句模糊的需求，拆成真實業務問題，再把真實業務問題，設計成一條能跑起來的業務鏈路。
需求只是入口。流程才是現場。機制才是問題。邊界決定能不能上線。驗證決定有沒有結果。沉澱決定這個項目能不能從一次性交付，變成企業自己的能力。
這也是 FDE 在企業 AI 落地裏的價值。不是把 AI 工具搬進企業。而是幫企業看清楚：哪條業務鏈路值得改，AI 應該站在哪裏，人應該負責什麼，系統應該記錄什麼，最後怎麼證明這件事真的做成了。
一個 AI 項目，只有走完這條路，才不只是一個 demo。它才有機會變成企業裏真正跑得起來的業務系統。
不是把 AI 工具搬進企業。 需求只是入口，流程才是現場。 |
Resona · 鳴 · 讓每一次對話，都有迴響 2026-06-04 · 彭俊旗 |