Glossary
詞彙表
AI Agent、RAG、ERP、傳產數位轉型……諾訊科技整理專案中常被問到的技術與導入名詞，用一句話講清楚定義，再補充實務上的常見誤解。
AI Agent
AI Agent 是能自主規劃步驟、呼叫工具並執行任務的 AI 系統，而不只是單輪問答的聊天機器人。
以一家五十人規模的貿易公司為例：客服信箱每天湧入上百封詢價與出貨進度信件，光是把信件分類、比對訂單系統、草擬回覆就佔掉專員大半個上午，累積到月底常常還有信件被漏回。AI Agent 可以先讀信、查詢訂單狀態、草擬回覆，讓專人只需做最後確認與拍板——這類「規則相對明確、但仍需要語言理解」的流程，正是 AI Agent 最適合切入的場景，客服、文件分類、內部知識查詢都屬於這一類，共同特徵是問題重複性高、答案有跡可循。但若詢價內容經常涉及議價彈性、或需要臨場判斷長期客戶的交情與例外，單靠 Agent 就難以取代人工的分寸拿捏，這種情況下比較適合讓 Agent 先草擬、由業務做最後決定。費用上，2026 年台灣市場大致分三級距：只驗證單一情境的 PoC 約新台幣 15-50 萬，部門級正式上線約 80-300 萬，全企業級導入則可能超過 350 萬，差距主要來自串接系統數量與資安要求的嚴謹程度。常見誤解是以為 AI Agent 能處理任何任務，事實上一次性、高度創造性或牽涉大量例外判斷的工作通常不適合自動化，導入前應該先盤點場景是否合適，而不是先買技術再找用途，否則很容易做出一個沒人真正在用的系統。
API 整合
API 整合是透過應用程式介面，讓不同系統之間能自動交換資料，例如串接金流、物流、LLM 或既有企業系統。
API 整合是客製化軟體開發中最常被低估工期與費用的工作，尤其是串接既有系統時，看似只是「接個介面」，實際牽涉的細節遠比想像多。以舊系統翻新為例，若企業只是缺乏對外串接能力、系統核心本身還算穩定，選擇 API 封裝整合——不動舊系統核心，額外包一層介接——中小型案子費用約新台幣 50-150 萬、工期 6-12 週；相對地，若選擇全面重寫同等規模的系統，費用可能落在 150-500 萬、工期拉長到 4-9 個月，兩者差距可達數倍之多。常見誤解是低估整合的測試與除錯成本：舊系統若缺乏文件或 API 不穩定，除錯時間可能占掉整個專案工期的三分之一以上，這也是報價中最容易被低估、也最常導致專案延期的部分。以一家食品工廠串接電商平台訂單為例，功能開發往往只花兩週，但確認資料格式一致、處理平台端偶發的 API 異常與版本更新，反而花了超過一個月。如果舊系統連基本的資料匯出功能都沒有，API 整合可能無從下手，這時候該評估的是系統替換，而不是硬做整合、把資源投入在一個注定卡關的方向上。
ERP（企業資源規劃）
ERP 是整合企業訂單、庫存、財務、生產等核心流程於單一系統的管理軟體，用來取代分散在多個工具中的作業方式。
以一家 30 人規模的貿易公司為例：原本用 Excel 管理進銷貨與客戶對帳，隨著訂單量增加，逐漸出現版本混亂、對帳耗時、跨部門對不上數字的問題，這正是典型該評估 ERP 的時機。台灣中小企業導入 ERP 大致有三條路線：套裝方案採用廠商既有模組、設定參數即可上線，費用約新台幣 30-80 萬、工期 2-4 個月，適合流程接近業界標準的公司；客製方案在套裝基礎上大幅修改流程邏輯，工期拉長到約 4-8 個月；若還要串接電商平台、POS 或既有財務系統，屬於系統整合範疇，費用可能落在 150-600 萬以上，工期更拉長到 6-12 個月。常見誤解是以為導入 ERP 就等於「換掉所有系統」——實務上更常見、也更穩妥的做法，是先整合資料斷點最痛的一兩個環節，讓 ERP 與既有系統並行運作、驗證成效後再逐步擴大範圍。如果公司規模小於 10 人、流程單純到一張 Excel 就能管好，導入 ERP 的投資報酬率通常不高，不需要為了「數位轉型」的名義而硬做，把預算留給更急迫的問題、例如接單流程或庫存管理的人力調度，反而更划算，也更貼近公司實際的規模與需求。
Fine-tuning（模型微調）
Fine-tuning 是用大量範例資料重新調整模型參數，讓模型固定用特定語氣回答或在特定任務上表現更精準的技術。
很多企業一聽到「客製化模型」就直覺想做 Fine-tuning，覺得這樣才夠專屬、夠精準，但這其實是進階選項，而非起手式，貿然一開始就投入反而容易花錢卻看不到對應效果。Fine-tuning 適合場景已經穩定、且累積了足夠且品質一致的標註資料的情況，例如某類文件分類已經穩定運作半年以上，累積數千筆人工確認過的正確答案，模型行為也已經摸清楚哪裡需要微調、哪裡不需要。常見誤解是以為資料不足也能靠 Fine-tuning 補救——實務上，AI Agent 上線後通常需要 1-3 個月的資料累積期，才能觀察到明確的效率或成本改善數字，這段期間累積的資料量，往往還不足以支撐一次有意義的微調，貿然投入反而浪費預算又拖慢上線時程。資料量不足或場景仍在變動時，Fine-tuning 的投入報酬率通常不高，這時候用 RAG 先把知識庫串起來，讓系統邊運作邊累積真實回饋與使用數據，通常是更務實也更便宜的起點，等場景穩定、資料量到位後，再評估是否真的需要微調，而不是一開始就把它當成標準配備，不管場景合不合適都硬加進專案範圍裡。
IoT（物聯網）
IoT 是透過感測器與網路連結實體設備，即時蒐集與傳輸設備運作資料的技術，是智慧工廠與智能製造的基礎。
以一家食品工廠為例，若稼動率長期只能靠老師傅巡場憑經驗估算、憑感覺回報，IoT 感測器可以先裝在最常出問題的一兩台設備上，即時回傳運轉數據，讓管理者第一次看到「這台機器每天真正停機多久、卡在哪個環節」的具體數字，而不是聽師傅口頭估計。常見應用包含設備稼動率監控、產線資料即時分析、預防性維護，通常建議從單一產線試點開始，確認資料能被穩定蒐集與解讀，而非一次全廠部署冒著資源浪費的風險。投資回收期上，智能製造類的專案較長，約需 1-3 年，比單純的流程數位化專案（如訂單管理、庫存盤點，通常 6-18 個月即可回收）需要更多耐心，這是因為 IoT 導入除了系統建置，還涉及硬體採購、產線整合與資料累積的時間成本。常見誤解是先買感測器再想用途——正確順序應該是先確認要監控的關鍵指標，再決定需要哪些感測器與資料頻率。若工廠設備已經老舊到連基本的通訊介面都沒有，可能需要先評估設備汰換或加裝通訊模組，而不是急著加裝感測器硬湊，最後蒐集到的數據反而不能用。
LLM（大型語言模型）
LLM 是經過大量文字資料訓練、能理解與生成自然語言的 AI 模型，是 AI Agent、聊天機器人等應用的核心引擎。
很多企業導入時的第一個誤解，是以為 LLM 本身就知道公司內部資訊——事實上 LLM 只具備訓練時累積的通用知識，就像剛到職的新人只懂產業常識、不懂公司內部流程與眉角，需要搭配 RAG 等機制才能回答與內部資料相關的問題，這是選型前必須先釐清的基本認知，否則會誤以為系統故障。市面上主流 LLM 包含 GPT、Claude、Gemini 等，選型時常被忽略的其實是價格差距：同一家廠商內部，經濟型與旗艦型模型的費用差距可達百倍以上，例如 OpenAI 經濟型每萬則對話約 2.4 美元，旗艦型則約 350 美元，選錯模型等級，換算成年度費用的差距可能高達新台幣百萬元以上，這筆錢往往比模型本身的效能提升更值得先關注。對於客服信件分類、常見問答這類任務，通常經濟型模型已經足夠應付；但涉及複雜推理、契約條款判讀或跨段落邏輯比對，才有必要選用旗艦型，並不是「模型越貴越保險」，選型應該對應任務難度而非預算多寡，隨意升級旗艦模型只會讓每月帳單無謂增加，卻不一定反映在使用者體驗上。
MVP（最小可行產品）
MVP 是只包含核心功能、能讓使用者驗證產品價值的最小可行版本，目的是用最低成本驗證方向是否正確。
客製化軟體開發的時程通常分三段：MVP 版本約 6-12 週可上線，只做最核心的功能來驗證方向對不對；接著依使用回饋擴充到部門可用的完整功能，通常落在 3-6 個月；最後才是長期維運與持續迭代，這三段的預算與心力配置也大不相同。專業團隊在 MVP 階段會採取兩週一個週期的迭代交付方式，讓客戶能持續確認方向、及早發現落差再調整，而不是悶頭做三個月、等到最後一刻才第一次看到成品，那時候要改動範圍已經來不及、成本也高出許多。以一家車隊管理新創為例，與其一次做齊派車、計費、對帳所有功能，更務實的做法是先做「派車」這個最痛的核心流程當 MVP，驗證司機與調度員實際上願意用、動線也順之後，再逐步加上計費與對帳模組，一步一步擴張範圍。常見誤解是把 MVP 當成「陽春版正式產品」——MVP 的重點是驗證假設，不是把功能砍半的閹割版，如果專案一開始需求就已經確定、規模也夠大，直接規劃完整系統反而比繞路先做 MVP 更有效率，不必為了流程而流程、硬套用不適合的開發方法論。
PoC（概念驗證）
PoC 是用最小成本驗證一個技術方案或場景是否可行的階段性成果，通常還不具備正式上線的完整度。
AI Agent 導入的時程通常分兩段：PoC 階段約 2-4 週就能看到可運作的版本，目的是驗證場景可行性與資料品質是否足夠支撐檢索或回答；驗證通過後，才進入完整生產環境部署，這段包含系統整合、監控與合規要求，通常需要再花 6-12 週才能真正上線。以一家食品工廠評估導入品管異常回報機器人為例，PoC 階段只需要用過去累積的歷史異常紀錄測試模型能否正確分類、抓對嚴重程度，不必接生產線的即時資料，成本與風險都比較低；等準確率達到可接受的門檻，才值得投入資源做正式整合。常見誤解是把 PoC 直接當成正式系統上線——PoC 通常還沒處理例外狀況、權限控管與正式監控，直接把 PoC 接上生產環境，一旦模型判斷錯誤又沒有人把關，風險反而比完全不用 AI 更高，等於把未驗證的東西直接推給第一線。如果場景本身複雜到 PoC 都無法在一個月內看出明確方向，通常代表問題定義還不夠清楚，需要先拆解場景，而不是急著動手寫程式，這時候多花一週釐清需求，往往比多寫兩週程式更有效率。
Prompt Engineering（提示工程）
Prompt Engineering 是設計與調整輸入給 AI 模型的指令內容，讓模型輸出更符合預期結果的技巧。
很多人以為寫好一次提示詞就能一勞永逸，實際上使用者的真實問法會隨時間改變，提示詞通常需要依真實回饋持續迭代調整，例如客服機器人上線後才發現客戶常用「多久會到」代替「到貨時間」，或用產品的俗名而非正式型號發問，這類用語落差都得靠上線後的事後調校慢慢補上，不是一次寫完就能涵蓋所有情境。Prompt Engineering 的工作最集中在 AI Agent 上線後的優化階段，包含調整回答語氣、限制回答範圍、避免模型答出超出授權範圍的內容或做出不該由 AI 承諾的保證，這部分與 RAG 知識庫建置合計，在專案報價中通常占整體預算的 35-45%，是持續性的維護成本而非一次性費用。常見誤解是把 Prompt Engineering 當成一次性的文案工作，隨手交給不熟悉系統行為的人員兼職處理——如果沒有人持續追蹤使用者的真實提問並調整提示詞，機器人的回答品質只會隨時間慢慢跑掉走鐘，而不是自動變好，這也是很多專案上線三個月後滿意度反而下滑、客訴變多，團隊卻找不出原因的常見狀況，往往回頭一查才發現提示詞從沒更新過。
RAG（檢索增強生成）
RAG 是讓 AI 模型在回答前，先從企業內部文件中檢索相關內容，再依查到的資料生成答案的技術架構。
很多人以為要讓 AI 懂公司資料，必須先訓練一個屬於自己的模型，動輒要花數個月建置與標註資料，其實多數情況下只要有內部文件、FAQ、操作手冊，透過 RAG 讓模型在回答前先檢索這些資料再作答即可運作，不需要從零訓練模型，知識更新時只要替換文件、不必重新訓練，維護成本低上許多。以一家食品工廠導入客服機器人為例，只要把作業 SOP、常見客訴處理流程、退換貨規則整理成文件餵給系統，Agent 就能在對話當下檢索後回答，不必等資料科學團隊介入寫程式，上線速度也快上不少，文件每季更新一次即可反映到答案上。費用上，RAG 相關的開發與知識庫建置，在 AI Agent 專案報價中通常占整體預算的 35-45%，是成本占比最高的項目之一，也是驗收時最該仔細檢查品質、確認檢索是否真的準確的部分。常見誤解是把 RAG 和 Fine-tuning 混為一談——RAG 解決的是「模型不知道你的資料」，如果問題是「模型講話語氣或判斷邏輯需要調整」，RAG 並不是對的工具，那屬於 Fine-tuning 或 Prompt Engineering 的範疇，兩者處理的層次不同，不該互相取代或期待一種技術解決所有問題。
SaaS（軟體即服務）
SaaS 是以訂閱制透過雲端提供的軟體服務，使用者不需要自行安裝或維護伺服器即可使用完整功能。
SaaS 與客製開發的差異，常被簡化成「訂閱比較便宜」，但實際比較五年總持有成本（TCO）時，兩者經常只相差不到 5%——以中型部署規模估算，SaaS 路線約新台幣 370 萬，客製開發約 369 萬，差距不在總價，而在資料掌控度與長期彈性上。SaaS 常見於數據分析平台、線上教育系統等需要快速上線、多租戶架構的場景，第三方 API／SaaS 訂閱費用一般落在每月新台幣 1.6-16 萬，會隨用量與使用人數逐年成長，不是一次繳清就結束。以一家剛起步的線上課程公司為例，前期用 SaaS 快速把報名與金流串起來，是合理且務實的起點；但等使用者規模擴大、平台功能限制開始卡住成長曲線時，訂閱費用逐年墊高的問題就會慢慢浮現。常見誤解是以為 SaaS 一定比客製化便宜——訂閱費用會隨時間累積，且功能彈性受限於平台本身。如果需求高度標準化、且公司沒有維運系統的工程能力，SaaS 仍然是較快、較低風險的選擇，不必為了「將來可能客製」而現在就急著自建，先用起來、等真正卡到平台功能瓶頸或資料掌控度不足時，再評估轉換也不遲。
客製化軟體
客製化軟體是依企業特定需求從頭設計開發的系統，用來把業務需求、流程與資料整合成可擴張、可維運的數位資產。
客製化軟體與套裝軟體最大的差異，不在於「貴不貴」，而在於能不能貼合既有業務流程——套裝軟體要求企業配合系統邏輯調整作業方式，客製化軟體則是反過來，讓系統配合企業原本的流程設計，不必削足適履。典型中小型客製化專案的費用落在新台幣 30-200 萬之間，涵蓋從單純的內部工具到中型對外平台，MVP 版本通常 6-12 週可上線，用來先驗證核心功能是否符合實際需求。以一家車隊管理公司為例，市面上找不到剛好符合當地法規與計費邏輯的套裝系統，客製化雖然前期投入較高，長期卻省下每年為了配合套裝軟體改版而重新調整作業流程的成本與人力。常見誤解是認為客製化一定比套裝軟體貴很多——實際上取決於功能範圍與整合複雜度，一個簡單的內部工具成本可能不高，反而是想省錢硬套用不合用的套裝軟體，才會產生更多人工繞路處理的隱藏成本。如果需求高度標準化、市場上已有成熟方案，直接採購通常比從零開發更划算，不必堅持一定要客製。
技術債
技術債是為了短期加快開發速度而採取的權宜設計，日後需要額外時間與成本償還，才能維持系統的可維護性。
技術債不只是「程式碼比較亂」的抽象說法，而是有具體代價的：根據 McKinsey 針對 CIO 的調查，企業投入新產品開發的科技預算中，平均有 10-20% 被挪去處理技術債相關問題，CIO 們估計技術債占整體科技資產價值的 20-40%，六成的 CIO 認為過去三年技術債有明顯上升。常見來源包含缺乏測試、架構設計倉促、文件不完整，尤其容易發生在單一接案者交付、後續又換過幾手不同工程師維護的專案。判斷該修補還是該重建，有一個簡單的參考基準：當某個部門的技術債超過其技術資產價值的 50%，重建的效益才會開始超過持續修補的成本，多數情況下這個門檻還沒到，優先修補其實比整套重寫更划算。以一家使用超過八年舊系統的貿易公司為例，與其花大錢全面重寫，不如先盤點哪些模組真正拖慢新功能開發，針對性地還債即可。常見誤解是以為技術債只影響工程團隊的心情——實際上它會直接拖慢後續功能開發速度，並在系統擴充或人力交接時放大風險，是會反映在報價單和上線時程上的實際成本。
數位轉型
數位轉型是把紙本、Excel、老舊系統的作業流程，轉為可追蹤、可稽核、資料驅動的數位系統的過程。
傳產數位轉型建議採取 3-6-12 個月的分階段里程碑，而不是一次到位：前 3 個月先做最痛、也最容易看到成效的單一流程試點，例如把紙本領料單改成手機掃碼登記；驗證有效後，6 個月內擴大到同類型的其他流程，例如同時涵蓋進貨與出貨登記；12 個月則進入跨部門資料串接，例如把生產紀錄與財務對帳打通，減少重複輸入。傳產數位轉型的重點通常不是技術本身，而是系統老舊、資料分散，以及來自現場操作人員的轉型阻力——如果第一階段就選一個牽涉太多部門、太多人習慣要同時改變的流程，很容易卡在「大家開會都說好、卻沒人真的開始用」的尷尬階段。常見誤解是想一次全面轉型，把所有紙本作業同時數位化，結果現場人員疲於應付新舊系統並行，反而拖慢日常作業、士氣也受影響。如果公司規模很小、流程本來就簡單到一人可以全盤掌握，強行分階段導入系統的行政成本，可能反而高於維持現況不動，這種情況下用好一點的 Excel 範本搭配固定的檢核流程，可能就已經足夠。
智慧工廠
智慧工廠是運用 IoT 感測器、即時資料分析與自動化技術，讓生產流程具備即時監控與決策支援能力的製造模式。
智慧工廠的應用層次通常分三層，需要逐層建立而非一步到位：第一層是設備監控，先知道機台稼動率與停機原因分佈；第二層是產線資料即時分析，把多台設備的數據放在同一個儀表板上互相比對、找出瓶頸；第三層才是品質預測與預防性維護，用歷史數據預測設備何時可能故障，提前安排保養排程。以一家中型零件加工廠為例，若已經裝了感測器卻只是把數據存在硬碟裡沒人看，等於只做到第一層的一半——沒有 Dashboard、也沒有人負責定期檢視數據，蒐集再多資料也無法轉化為決策，這是最常見的誤解：以為裝了感測器就等於是智慧工廠。投資回收期上，智能製造類專案通常需要 1-3 年才能看到明確效益，比單純的流程數位化（6-18 個月即可回收）需要更長的耐心與分階段規劃。如果工廠訂單量小、產線變動頻繁到數據還沒穩定就要換模式生產，智慧工廠帶來的分析價值相對有限，優先把生產排程流程理順、把人力配置與交接規則排好，可能比急著上智慧化工具更划算。
系統整合
系統整合是連接企業內多套既有系統（如 ERP、MES、CRM、財務系統），補上資料斷點，讓資訊能正確流動的工程工作。
系統整合和「導入一套新系統」最大的不同，在於目標通常不是把所有系統換成單一套裝軟體，而是讓資訊只需輸入一次、正確流動於既有的 ERP、MES、CRM、財務系統之間，減少人工重複登打與對帳誤差。以規模較大、跨據點經營、使用人數超過 150 人的企業為例，這類系統整合方案費用可能落在新台幣 150-600 萬以上，工期 6-12 個月，遠高於單純的套裝軟體導入，因為重點不在功能開發本身，而在資料一致性與介接穩定度的長期維護。常見誤解是想一次整合所有系統——較穩妥的做法是先整合影響最大的一到兩個資料斷點，例如先讓訂單系統和財務系統對帳自動化，驗證成效後再逐步擴大範圍，而不是一次把五、六套系統全部打通增加失敗風險。如果公司規模小、只使用一兩套系統，且彼此本來就有基本的匯出匯入功能可以手動銜接，未必需要走正式的系統整合專案，先用人工定期匯出比對，可能就足夠應付目前的規模，把整合預算留到公司真正跨出多據點、多系統經營的階段再啟動也不遲。