<彙總>面相AI 新時代，甩開舊包袱，以創業精神全新重新開始。 #
(2027年，一定要做跟2026年不一樣的。也必須要突破行銷業務困境)
這是季會公開說明【組織轉型】的決心!! 11月底前，大家都需要對明年有所期望與計畫，讓他人與公司認為你有價值。
PS. 各主管們需要以此內容，與同事們一起展開 workshop 討論共創合作，展開新的旅程。
借助AI Agent 的幫助，我們用 【原生AI企業】的解析對比我們公司的現況，並以【技術基因】【組織基因】【價值基因】三個面向來思考與分析報告。參考季會內容，這些都非常重要，往後有機會要多讀幾次，會有所幫助的。
經過多年的轉型，目標是成為一家【平台企業】，看來與AI 原生企業不謀而合。
我們現在面對的困境，是組織老化問題，知道歸知道但就是不會長出新能力出來。
另外，我們也可能在不知不覺中疏忽很多細節，以致執行力不到位，如下圖所說明的。希望大家都能有創業精神重新學習，長出新的能力出來!!
未來的【組織轉型】，我們每個人借住AI 都須要往前一步，大家都需要面向市場與客戶。最後成為二階的人才， 一是 【市場營業人員】發揮顧問與連結的能力，幫客戶賺錢，爭取自己最大的品牌力與利益。二是【產品技術支援人員】，善用AI 辦事能力，面相市場與客戶(同事)，成為別人的幫助，支撐出更大的發展價值。
我們不能再只是銷售或服務系統而已，我們需要幫客戶經營出成果，這是我們的發展方向。
我們的商業模式是創造被利用的價值，新共創平台【經銷商發展模式】，賦能全世界各地的【老闆們】增值賺錢。
你我每一個人都是老闆!!
檢討與展望 (很多公司不是被對手打垮的，是被自己前幾年欠下的債拖死的) #
過去我們做很大的改革，也經過多年，雖然已經完成改進並升級很多系統了，但為何現在還沒辦法突破困境呢?
今天，我要跟大家說，我們團隊與做法，都老化了，存在以下兩大負擔與包袱!!
技術債，借助AI 幫助，我們已經完成過去十年做不到的技術與改進! 也更有底氣來面對未來擴大營業，因為過往每次有機會擴大營利時，瓶頸都出現在【程式設計師】不夠上。
這兩年的營收與發展過程檢討，最後的問題就是 組織與人的債。
團隊待久了，養老的心態出來了；
位置坐久了，怠惰與不求上進變成了習慣；
資歷深了，自以為是的傲慢成了組織的絆腳石。
當管理層把這些當成「包容」與「人情」，這筆人事債就開始在背後利滾利。
出來混，債總是要還的。
差只在於：你是早點痛定思痛去還，還是拖到最後連本帶利被討回去？
企業的衰敗很少是突發事件，那些慢慢沉下去的船，只是到了該算總帳的時候而已。
經過這八年的轉型，我領悟到了! 我們不可能讓宣揚電腦這老公司老組織團隊全部<<轉型>>成功!! 該斷就要斷，我們必須有置於死地而後生的決心，然後，從市場客戶端發展出<新創團隊><新的價值出來>，不能再倚靠傳統方法與客戶；舊思維與經驗來做生意，大家認為呢?
其實，不管宣揚電腦或我們自己，過去多麼成功或失敗，面對這百年一遇的AI 民主化平等智能浪潮，都必須<<歸零、重新開始>>。這是可以確定的一件事。
謹記! 這是大家需要【改變】的時間了!! 不能再倚靠舊經驗與技能!! 當個新人一樣，爭取價值與存在感!!
年底前，11月底，我們要做全新轉型的準備讓新團隊新方法來面對明年，我不要還是跟上一年還有今年一樣的結果。
也就是面對AI 浪潮，用創業精神，重新開始，把自己當品牌來經營 !! 這創業的本質，就是在了解自己，而且要很誠懇地面對自己。
從公司執行策略的角度說明，作法如下二點:
- 營運處自己要負全責，不要虧損。產品處要精實且提高績效。然後，全公司全力轉型，善用既有客戶與市場，發展出更多價值。
- 然後，讓有創業精神的團隊先長出<行銷業務>能力出來外，強化既有客戶與市場價值，突破傳統資訊公司困境，帶領團隊全速轉型成【AI 原生的平台企業公司】。
大家都是合作夥伴，自己要對自己的品牌與價值負責!! 未來，沒有人應該要為你負責!!
未來企業發展趨勢: 原生AI 企業 #
技術基因: 技術與產品開發 #
端末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 實測）八台全部在安全狀態。 若要確認某一台：
- 記憶體是否穩定 —— 連續觀察數小時，看的是回收後的低點有沒有一直墊高， 不是看瞬時值（瞬時值呈鋸齒狀，會誤判）
- 快取連線數 —— 正常值是個位數；若是數十、數百條就不正常
- 服務中斷次數 —— 直接數系統記錄中的異常終止，不要用「排除排程時段」的估算法 （排程一改就失準，也會把人工重啟誤算成當機）
⚠ 判斷「某台快取伺服器能不能停用」時，「目前沒有被查詢」不等於沒有人用 —— 必須確認程式裡沒有寫死該位址。這一點曾經踩過。
JD 開發平台增加二次開發 #
讓SA 面對需求了解，不用了解元件與程式開發，就能完成採購單維護 5000多行。