---
title: 2026 4Q季會
description: "###### 面相AI 新時代，甩開舊包袱，以創業精神全新重新開始。 (2027…"
url: "https://help.bethel.com.tw/docs/2026-4q%e5%ad%a3%e6%9c%83/"
updated: "2026-10-28"
category: 公司營運紀錄 / 2026 平台企業元年
---

# 2026 4Q季會

###### <彙總>面相AI 新時代，甩開舊包袱，以創業精神全新重新開始。

(2027年，一定要做跟2026年不一樣的。也必須要突破行銷業務困境)

這是季會公開說明【組織轉型】的決心!!   **11月底前，大家都需要對明年有所期望與計畫，讓他人與公司認為你有價值。**

PS. 各主管們需要以此內容，與同事們一起展開 workshop 討論共創合作，展開新的旅程。

借助AI Agent 的幫助，我們用 【原生AI企業】的解析對比我們公司的現況，並以【技術基因】【組織基因】【價值基因】三個面向來思考與分析報告。參考季會內容，這些都非常重要，往後有機會要多讀幾次，會有所幫助的。

經過多年的轉型，目標是成為一家【平台企業】，看來與AI 原生企業不謀而合。

我們現在面對的困境，是組織老化問題，知道歸知道但就是不會長出新能力出來。

另外，我們也可能在不知不覺中疏忽很多細節，以致執行力不到位，如下圖所說明的。希望大家都能有創業精神重新學習，長出新的能力出來!!

[![](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-1024x566.png)](https://help.bethel.com.tw/wp-content/uploads/2026/09/image.png)

**未來的【組織轉型】**，我們每個人借住AI 都須要往前一步，大家都需要面向市場與客戶。最後成為二階的人才， 一是 【市場營業人員】發揮顧問與連結的能力，幫客戶賺錢，爭取自己最大的品牌力與利益。二是【產品技術支援人員】，善用AI 辦事能力，面相市場與客戶(同事)，成為別人的幫助，支撐出更大的發展價值。

[![](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-1-1024x546.png)](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-1.png)

[![](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-2-1024x576.png)](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-2.png)

**我們不能再只是銷售或服務系統而已，我們需要幫客戶經營出成果**，這是我們的發展方向。
我們的商業模式是創造被利用的價值，新共創平台【經銷商發展模式】，賦能全世界各地的【老闆們】增值賺錢。

你我每一個人都是老闆!!

[![](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-3-1024x502.png)](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-3.png)

---

![](https://help.bethel.com.tw/wp-content/uploads/2026/09/image-4-1024x265.png)

##### 檢討與展望 (**很多公司不是被對手打垮的，是被自己前幾年欠下的債拖死的)**

[https://player.vimeo.com/video/1235291876?dnt=1&app_id=122963](https://player.vimeo.com/video/1235291876?dnt=1&app_id=122963)

過去我們做很大的改革，也經過多年，雖然已經完成改進並升級很多系統了，但為何現在還沒辦法突破困境呢?
今天，我要跟大家說，我們團隊與做法，都老化了，存在以下兩大負擔與包袱!!
**技術債**，借助AI 幫助，我們已經完成過去十年做不到的技術與改進! 也更有底氣來面對未來擴大營業，因為過往每次有機會擴大營利時，瓶頸都出現在【程式設計師】不夠上。

這兩年的營收與發展過程檢討，最後的問題就是 **組織與人的債**。

**團隊待久了，養老的心態出來了**；
**位置坐久了，怠惰與不求上進變成了習慣**；
**資歷深了，自以為是的傲慢成了組織的絆腳石**。
當管理層把這些當成「包容」與「人情」，這筆**人事債**就開始在背後利滾利。
出來混，債總是要還的。
差只在於：**你是早點痛定思痛去還，還是拖到最後連本帶利被討回去？**
**企業的衰敗很少是突發事件，那些慢慢沉下去的船，只是到了該算總帳的時候而已。**

經過這八年的轉型，我領悟到了! 我們不可能讓宣揚電腦這老公司老組織團隊全部<<轉型>>成功!! 該斷就要斷，我們必須有置於死地而後生的決心，然後，從市場客戶端發展出<新創團隊><新的價值出來>，不能再倚靠傳統方法與客戶；舊思維與經驗來做生意，大家認為呢?

其實，不管宣揚電腦或我們自己，過去多麼成功或失敗，面對這百年一遇的AI 民主化平等智能浪潮，都必須<<歸零、重新開始>>。這是可以確定的一件事。

謹記! 這是大家需要【改變】的時間了!! 不能再倚靠舊經驗與技能!! 當個新人一樣，爭取價值與存在感!!

---

年底前，11月底，我們要做全新轉型的準備讓新團隊新方法來面對明年，我不要還是跟上一年還有今年一樣的結果。
也就是面對AI 浪潮，用創業精神，重新開始，把自己當品牌來經營 !! 這創業的本質，就是在了解自己，而且要很誠懇地面對自己。

從公司執行策略的角度說明，作法如下二點:

1. 營運處自己要負全責，不要虧損。產品處要精實且提高績效。然後，全公司全力轉型，善用既有客戶與市場，發展出更多價值。
2. 然後，讓有創業精神的團隊先長出<行銷業務>能力出來外，強化既有客戶與市場價值，突破傳統資訊公司困境，帶領團隊全速轉型成【AI 原生的平台企業公司】。

大家都是合作夥伴，自己要對自己的品牌與價值負責!! 未來，沒有人應該要為你負責!!

##### 未來企業發展趨勢: 原生AI 企業

[https://player.vimeo.com/video/1235290038?dnt=1&app_id=122963](https://player.vimeo.com/video/1235290038?dnt=1&app_id=122963)

##### 技術基因: 技術與產品開發

###### 端末POS組的報告

###### JD 開發平台優化說明

> ##### JD 系統效能與穩定性改善成效
>
>
>
> ---
>
>
>
> ###### 一、一句話總結
>
>
>
> 這段期間處理的不是單一功能的快慢，而是**「系統撐不撐得住長時間運轉」**：
>
>
>
> - 以前公雲伺服器**平均每天當掉 2.6 次**，現在**連續 13 天 0 次**
> - 以前JD AWS正式機**每天約 4,000 筆請求逾時**（畫面轉圈、等到超時），現在**逾時率 0.3%**
> - 以前主機記憶體**每分鐘增加 25–30 MB**、撐幾天就滿，現在**不再累積**
>
>
>
> 這些都是**使用者直接有感**的改變：不再莫名其妙卡住、不用等管理員重開、 操作到一半不會突然失去連線。
>
>
>
> ---
>
>
>
> ###### 二、成效數字（全部有實測）
>
>
>
> ###### 2-1 穩定性
>
>
>
> | 項目 | 改善前 | 改善後 |
> | --- | --- | --- |
> | 公雲主機服務中斷次數 | 139 天內 **277 次**（平日 2.61 次／日） | 13 天 **0 次** |
> | 記憶體成長速度 | 每分鐘 **25～30 MB**（持續累積不釋放） | **0**（連續 2 小時持平） |
> | 事故當下的記憶體佔用 | **919 MB**（達上限、整台卡死） | 修正重啟後 **144 MB** |
>
>
>
> ###### 2-2 回應速度
>
>
>
> | 項目 | 改善前 | 改善後 |
> | --- | --- | --- |
> | 主畫面請求逾時率（ERP 正式機） | **11～15%**，每天 4,000 筆以上逾時 | **0.3%**（46,797 筆中僅 155 筆） |
> | 登入 | — | **快約 51%** |
> | 切換方案（Solution） | — | **快約 26%** |
>
>
>
> ###### 2-3 連線資源
>
>
>
> | 項目 | 改善前 | 改善後 |
> | --- | --- | --- |
> | 快取（Redis）連線數 — MACACA主機 | **3,550 條** | **5 條** |
> | 快取連線數 — EIP主機 | 23 條 | **2 條** |
> | 快取連線新增速率 — POS 主機 | 每秒新建 **45～58 條** | 每秒 2.1 條 |
>
>
>
> ###### 2-4 傳輸與載入量
>
>
>
> | 項目 | 改善前 | 改善後 |
> | --- | --- | --- |
> | 前端主要程式庫傳輸量 | — | **減少 73%**（啟用壓縮後） |
> | 靜態檔快取期限 | 30 天 | **365 天**（並以版號自動更新，不必清快取） |
> | 報表 PDF 中文字型 | 一進頁面就下載 **11 MB** | 改成**按下匯出才載** |
> | 前端共用清單 | — | 瘦身 **183 KB** |
> | 開啟模組頁的設定查詢 | 每頁 **2 次**額外往返 | **0 次**（改由伺服器直接帶入） |
>
>
>
> ---
>
>
>
> ###### 三、做了哪些事（依使用者感受分類）
>
>
>
> ###### 3-1 「系統不會再越跑越慢、越跑越胖」
>
>
>
> **原本的問題** 系統每接到一個請求，就把該支業務程式**重新讀取一次**。舊的那份沒有被釋放， 一直堆在記憶體裡。實測同一支程式的內容，**25 分鐘內堆了 182 份、約 30 MB**。 堆到上限就整台卡住 —— 這時候畫面會轉圈轉到逾時，但伺服器看起來「還活著」， 所以不容易被發現。
>
>
>
> **改善** 改成**預設重複使用已載入的程式**，不再每次重讀。 （開發環境若需要改了立刻生效，可另外設定關閉此快取。）
>
>
>
> **你會感覺到** 服務不再需要定期重開；長時間使用不會越來越慢。
>
>
>
> ---
>
>
>
> ###### 3-2 「不會再莫名其妙斷線、整台沒反應」
>
>
>
> **原本的問題** 系統每執行一次資料庫查詢，就對快取伺服器**新開一條連線**，只為了查一個開關值。 其中一台累積到 **3,550 條連線**，另一台每秒新增 45～58 條。 連線用完就是整台服務異常。
>
>
>
> **改善** 改為**共用同一條長連線**，不再每次開新的。
>
>
>
> **你會感覺到** 不會再出現「操作到一半突然沒反應、重新登入才好」。
>
>
>
> ---
>
>
>
> ###### 3-3 「畫面開得更快」
>
>
>
> | 做法 | 說明 |
> | --- | --- |
> | 啟用壓縮傳輸 | 主要程式庫傳輸量**少 73%**，網路慢的門市感受最明顯 |
> | 靜態檔長期快取 | 從 30 天延長到 **365 天**；改版時以版號自動更新，**不需要清瀏覽器快取** |
> | 設定值改由伺服器帶入 | 每開一個模組頁少 **2 次**往返 |
> | 字型按需載入 | 報表字型 11 MB 改成按下匯出才下載 |
> | 登入與切換方案並行處理 | 登入快 **51%**、切換方案快 **26%** |
> | 移除不再使用的元件庫 | 省下 116 MB |
>
>
>
> ---
>
>
>
> ###### 3-4 「系統內部的清理」（使用者不直接感受，但影響長期穩定）
>
>
>
> - 前端元件的動態求值（`eval`）**全部移除**，改走明確的呼叫方式 —— 共 188 處
> - 前端載入流程重寫：清單單一來源、載入順序明確、改為平行載入
> - 修正「同一頁只會初始化最後一個元件型別」的隱性缺陷
> - 關閉高頻路徑上的除錯訊息輸出、修正一處會隨資料量平方成長的掃描
> - 部署映像檔 **7.12 GB → 3.94 GB**、版控倉庫 5.9 GB → 1.9 GB（加快部署與更新）
>
>
>
> ---
>
>
>
> ###### 四、效能問題的專項調查
>
>
>
> 除了上述改善，這段期間也針對反映較慢的功能做了實測分析，**結論同樣重要**：
>
>
>
> | 調查對象 | 結論 |
> | --- | --- |
> | 進貨匯入（IMPT_BAS） | 真正的瓶頸是**暫存表累積到 10 萬筆以上**（成功時沒有清除）與缺少索引，不是查詢寫法 |
> | POS 慢查詢統計 | 慢的集中在少數幾支程式（單一程式佔 29.8%、單一模組佔 41%）；**兩台硬體表現一致 → 瓶頸在程式不在硬體** |
> | 儀表板（0_POS_HI） | 已完成改寫實測，列出後續可優化空間 |
> | 資料庫連線池 | 已評估，列出適用條件 |
>
>
>
> > **一個值得記住的教訓**：量測期間若環境有變動，會得到完全相反的結論 （同一支查詢曾測到 25 秒、也曾測到逾時）。 所以上述數字都是在**可重現的條件**下取得的。
>
>
>
> ---
>
>
>
> ###### 五、怎麼確認自己這台已經套用
>
>
>
> 正式機目前（2026/10/05 實測）**八台全部在安全狀態**。 若要確認某一台：
>
>
>
> 1. **記憶體是否穩定** —— 連續觀察數小時，看的是**回收後的低點**有沒有一直墊高， 不是看瞬時值（瞬時值呈鋸齒狀，會誤判）
> 2. **快取連線數** —— 正常值是個位數；若是數十、數百條就不正常
> 3. **服務中斷次數** —— 直接數系統記錄中的異常終止，不要用「排除排程時段」的估算法 （排程一改就失準，也會把人工重啟誤算成當機）
>
>
>
> > ⚠ 判斷「某台快取伺服器能不能停用」時，**「目前沒有被查詢」不等於沒有人用** —— 必須確認程式裡沒有寫死該位址。這一點曾經踩過。

###### JD 開發平台增加二次開發

讓SA 面對需求了解，不用了解元件與程式開發，就能完成採購單維護 5000多行。

##### 行銷業務流程

##### 轉型成為平台企業，如何發展經銷商合作夥伴

##### 每個人都是老闆