In digital transformation initiatives, organizations often rush to talk about AI, automation, and system upgrades. But if the process itself has not been clearly understood, AI will only accelerate chaos. During the planning of our new facility, we intentionally returned to a classic operational tool: Value Stream Mapping (VSM) The Origin of VSM: Lean Thinking…
Blog
當精實管理遇上 AI：從 VSM（價值溪流圖）到智慧倉儲轉型
在企業數位轉型的過程中，我們常常會急著談 AI、談自動化、談系統升級。 但如果流程本身沒有被看清楚，再多的 AI 也只是「加速混亂」。 這也是為什麼在新廠規劃過程中，我重新回到一個經典工具： VSM（Value Stream Mapping，價值溪流圖） VSM 的源頭：來自 Toyota 的精實思維 VSM 起源於 Toyota Motor Corporation 的精實生產系統（TPS），由 Taiichi Ohno 等人發展。 它的核心只有一句話： 客戶願意付錢的才叫價值，其餘都是浪費。 這句話，看似簡單，卻足以改變整個企業運作邏輯。 什麼是 VSM？ VSM 不是單純的流程圖。 它是一張把「整條價值創造流程」攤開來看的圖，包含三個關鍵元素： 一張典型的 VSM 長這樣 與一般流程圖不同的是： 通常你會發現一件震撼的事： 真正創造價值的時間，可能只有 5%–10%。 VSM 的四個核心觀念 1️⃣ 價值（Value） 例如在倉儲作業中： 這些是客戶願意為之付費的。 2️⃣ 浪費（Waste） 精實理論中的七大浪費，在倉儲場景裡非常常見： 浪費類型 倉儲例子 等待 等主管簽核 搬運 重複搬棧板 動作 多餘走動 過度加工…
Planning and Key Considerations for IT Data Room Construction
A Practical Guide Based on a Medium-Scale Factory Deployment In new factory construction or major facility upgrades, the IT data room is often not considered a primary architectural element. However, it ultimately becomes the operational backbone of all digital systems.Design omissions at an early stage almost always lead to higher costs, operational risk, and downtime…
IT 機房建置的規劃與考量
——以中型工廠新建案為例的實務整理 在企業新廠建置或既有廠房升級的過程中，IT 機房往往不是建築的主體，但卻是 所有系統穩定運作的核心。一旦在設計初期忽略，後續補救的成本、風險與停機影響，往往遠高於一開始就規劃到位。 本文以一個 中型工廠、4 櫃等級、含 AI / GPU 應用的 IT 機房 為背景，整理在規劃階段必須納入的關鍵考量。 一、機房不是放伺服器的房間，而是一個「系統」 許多問題的根源，來自於一個錯誤認知： 「機房就是找個空間，把機櫃放進去。」 實務上，機房是一個由以下系統組成的整體： 這些系統 彼此高度耦合，任何一項單獨規劃，都可能導致整體失衡。 二、空間規劃：機櫃只是其中一部分 以 4 個 42U 機櫃為例，實務上需要考量的空間包含： 實務建議 機房最怕的不是太大，而是沒有餘裕。 三、空調與冷熱通道：熱氣要「有路可走」 1. 冷熱通道的本質 如果沒有妥善規劃： 2. 熱氣最後去哪裡？ 在中型機房中，常見做法是： 不一定要做到全封閉熱通道，但至少要： 四、電力系統：從市電到機櫃的完整邏輯 1. UPS 的角色要先想清楚 UPS 解決的不是「長時間供電」，而是： 在工廠環境中： 2. 為什麼 UPS 用 kVA，而不是 kW？ 實務選型時： 3. UPS 不等於插座排 這是一個常被誤解的重點： UPS…
Token/s and Concurrency:
The Two Most Misunderstood Metrics in Enterprise LLM Deployment When evaluating Large Language Model (LLM) deployment options, many teams focus on GPU models and parameter counts—70B, 235B, 671B—while overlooking two metrics that actually determine whether a system is usable in real life: These two metrics directly affect: This article explains what Token/s and concurrency really…
Token/s 與並發：企業導入大型語言模型時，最容易被誤解的兩個指標
在評估大型語言模型（LLM）部署方案時，許多人會被顯卡型號、模型參數量（70B、235B、671B）所吸引，卻忽略了兩個真正決定「用起來好不好」的核心指標： 這兩個指標，直接決定了： 本文將從「工程實務」的角度，說清楚這兩個概念，以及企業在規劃本地或私有化 LLM 時，應該如何正確看待它們。 一、什麼是 Token/s？它其實就是「AI 的輸出速度」 1. Token 是什麼？ 在 LLM 中，模型不是一次輸出一句話，而是一個 Token 一個 Token 地生成內容。 模型的所有「思考與輸出」，本質上都是 Token 的連續生成。 2. Token/s 的實際意義 Token/s = 模型每秒能生成多少 Token 舉例來說： Token/s 不影響模型會不會回答對，但會直接影響： 二、Token/s 與使用者體感的真實關係 實際使用 LLM 時，使用者會感受到兩個時間點： 這兩者常被混在一起，但意義完全不同。 實務比較範例 假設模型要輸出 400 Token： 情境 TTFT Token/s 總等待時間 A 0.5 秒 10 約 40 秒 B 3 秒…
Running OpenCode AI using Docker
A Practical, Reproducible, and Enterprise-Ready Implementation Guide AI coding tools such as OpenCode AI can significantly improve developer productivity. However, installing them directly on developer machines quickly becomes problematic in team or enterprise environments: This guide shows how to run OpenCode AI inside a Docker container, following best practices for security, reproducibility, and enterprise governance….
使用 Docker 實際運行 OpenCode AI
一個可重現、可控、可維運的 AI Coding 環境實作指南 AI Coding 工具（如 OpenCode AI）若直接安裝在開發者本機，雖然方便，但在團隊或企業環境中，往往會帶來： 本文將示範 如何依照實務最佳做法，使用 Docker 建立一個可實際運行的 OpenCode AI 容器環境，讓 AI Coding 工具成為一個 可管理的工程元件。 一、整體設計目標 本實作的設計目標如下： 二、專案目錄結構 建議建立一個乾淨的目錄： 三、Dockerfile（核心實作） 以下是一份 可直接使用的 Dockerfile，已包含實務上必要的修正與安全考量。 四、Build Image 建立 build.sh： 執行： 五、執行容器（關鍵實作） OpenCode AI 需要使用者的認證資料，這些資料 必須存在主機上，再掛載進容器。 1️⃣ 主機端準備（只做一次） 登入一次 OpenCode（或依你實際使用方式）後，通常會產生： 2️⃣ run.sh（正式使用方式） 執行： 六、實際使用情境 進入後，你會在容器內： 這讓 OpenCode AI 的行為符合： 「工具可丟棄，資料留在主機」的雲原生設計原則 七、為什麼這種做法適合企業 ✔ IT…
Security Risks and Governance Models for AI Coding Tools
From Developer Productivity to Enterprise Control AI coding tools such as OpenCode AI, Copilot-style assistants, and code-generating agents are rapidly transforming how software is written. While the productivity gains are undeniable, these tools also introduce a new and often underestimated security surface. For enterprises, the critical question is no longer: “Is this tool useful?” but…
AI Coding 工具的資安風險與治理模型
從工程效率工具到企業可控的 AI 能力 AI Coding 工具（如 OpenCode AI、Copilot 類型助手、Code Agent）正在快速改變軟體開發的方式。然而，當企業開始大規模導入這類工具時，真正的挑戰往往不在「功能」，而在 資安與治理。 企業必須思考的問題已不再是： 「這個工具能不能提升工程師效率？」 而是： 「我們是否有能力在可控、可稽核、可治理的前提下使用 AI Coding 工具？」 本文將系統性說明 AI Coding 工具帶來的主要資安風險，並提出一套 適合企業導入的治理模型。 為什麼 AI Coding 工具是一個新的資安風險類型 傳統開發工具（IDE、編譯器、Formatter）本質上是被動工具；AI Coding 工具則完全不同。 AI Coding 工具通常具備以下特性： 從資安角度來看，它更像是一個： 具高權限、可連網、能操作原始碼的自動化代理程式 這使得 AI Coding 工具成為一個全新的攻擊與風險面。 AI Coding 工具的五大核心資安風險 1️⃣ 原始碼外洩風險（Source Code Leakage） AI Coding 工具通常需要讀取： 潛在風險包括： 一旦原始碼離開企業邊界，實際上就失去控制權。 2️⃣ 憑證與權限暴露風險 AI Coding…