風雲網通系統 – 強化您的企業 IT 戰力

不得不對外：NAS 公開服務的「相對安全」存取指南

工程師思路系列・事出必有因　NAS 勒索潮番外・第二篇不得不對外：NAS 公開服務的「相對安全」存取指南 Mr. τ ｜風雲網通系統｜資訊截至 2026-11-02 #NAS#Synology#遠端存取#VPN#IPsec#GeoIP#修補窗口#風險接受想像一下老闆說：「我在外面要看一下檔案。」業務說：「行事曆能不能也同步？」您明明知道這樣不安全，卻很難回他們一句「不行」。這篇不教您說不，而是教您怎麼說「好」，但更安全。 🧭 三種讀法，挑一種開始 ⚡ 30 秒只看下面的「5 句話」。 ☕ 5 分鐘 5 句話，加 30 秒自測，再看措施階梯、短中長期建議。 📖 完整版（約 29 分鐘）從第一節讀起；每節有重點框，結尾可回目錄。 ⚡ 先看這 5 句話 1 對外服務的風險不可能歸零：廠商修補前誰也縮不了，您能縮短的只有自己更新的那一段。 2 先把需求縮成四個最小：誰、用什麼服務、從哪裡、多久，通常真正非開不可的比想像少。 3 措施像一把梯子：VPN、Site-to-Site、前置驗證、直接對外加縮限；GeoIP 是濾網，不是圍牆。 4 短期一週止血、中期三個月改架構、長期把對外服務與核心資料分離；做不到就寫一頁風險接受聲明。 5 自架 Ubuntu 不是逃生口，修補窗口只是換人負責；NAS 上的 WordPress 要檢查... » read more

Read

steven written 5 hours ago

NAS 勒索潮不是玄學：用「攻擊鏈」找出隘口，一關一關自檢

工程師思路系列・事出必有因 NAS 勒索潮不是玄學：用「攻擊鏈」找出隘口，一關一關自檢 Mr. τ ｜風雲網通系統｜資訊截至 2026-11-02 #NAS#Synology#L0CK3D#C3RB3R#攻擊鏈#MITRE ATT&CK#資安自檢想像一下週一早上，您打開 NAS，發現所有檔案都多了 .L0CK3D 副檔名，每個資料夾裡躺著一份 read-me3.txt。這不是科幻，是上週在各社群與論壇真實出現的畫面。如果只能提早一天知道一件事，您希望是什麼？答案藏在「攻擊鏈的隘口」裡，而且比您想的少。 🧭 三種讀法，挑一種開始 ⚡ 30 秒只看下面的「5 句話」。 ☕ 5 分鐘 5 句話，加 30 秒自測，再看決策樹總覽、逐關詳解。 📖 完整版（約 35 分鐘）從第一節讀起；每節有重點框，結尾可回目錄。 ⚡ 先看這 5 句話 1 這波災情的共通點，不是密碼太弱，而是服務從網際網路看得到、系統沒更新、攻擊發生在登入之前，所以兩步驟驗證也擋不住。 2 入侵途徑各方說法不一，但入口的「類型」很穩定，不必等完整報告就能防。 3 火力集中在五個隘口：不被看見、補洞、限縮損害、救得回、看得見。 4 最優先兩件事：收掉對外入口，並確保有一份攻擊者碰不到的備份。 5 PHP2Shell、Node.js、Tailscale 是另外幾件事，不要混為一談；NAS 上有網站（WordPress）要另外檢查... » read more

Read

steven written 5 hours ago

群暉 NAS 勒索事件（L0CK3D／C3RB3R）：從疫情實況、防禦到善後

工程師思路系列・事出必有因群暉 NAS 勒索事件（L0CK3D／C3RB3R）：從疫情實況、防禦到善後作者：Mr. τ ／風雲網通系統　・　資訊更新至 2026-10-30，事件仍在發展中這幾天社團有成員反映，看到群暉 NAS 被勒索的消息，覺得受到威脅。有趣的是，原廠指出的漏洞是 2024 年底就已經修補的舊問題，攻擊卻是這個禮拜才大規模出現。這代表一件事：漏洞老不老不重要，重要的是你的 NAS 有沒有被留在那個「還沒修、又對外開放」的角落。這篇文章依序談三件事：沒中招的人現在該做什麼、不得不對外或沒辦法更新的人怎麼辦、以及萬一中招了還能做什麼。本文關鍵術語看不懂的名詞，點一下就會在術語表顯示該字卡（另開新分頁）。內文中的虛線底線詞，也都可以點。勒索軟體攻擊面（暴露面）連接埠轉送與 UPnP虛擬補丁QuickConnect多因素驗證（2FA）快照異地備份與離線備份查看本文全部術語（44 則）→ 一分鐘版本 ✔ 先封入口：關掉路由器連接埠轉送、UPnP 與不必要的對外服務，遠端改走 VPN。 ✔ 再補強系統：DSM 與套件更新到修補版本，啟用雙重驗證、停用預設帳號。 ✔ 確保能復原：快照加異地或離線備份，而且備份要讓攻擊者「摸不到」。一、先說事實：這波疫情的實況 10 月 28、29 日起，大量群暉用戶回報檔案被加密，Synology 在 10 月 29 日發布聲明證實。症狀很好認： ✔ 檔案副檔名變成 .L0CK3D（或 .LOCK3D，是數字 0 和 3） ✔ 每個資料夾出現 read-me3.txt 勒索信，指向 Tor... » read more

Read

steven written 3 days ago

不續約防火牆資安服務後 …

資安｜防火牆｜ Windows 內建防護｜ Pico-UTM 100 ｜ ZYXEL USG FLEX 200 作者：Mr. τ ／風雲網通系統　·　2026-10-27 不續約防火牆資安服務後，電腦與瀏覽器的內建防護能支撐「已知威脅」，支撐不了「網路設備被直接攻擊」和「事後沒有紀錄」。風險升在網路入口與設備這兩處。 ✔ 可以勉強支撐：已知的釣魚與惡意網站、已知的惡意檔案、本機的勒索行為偵測。前提是 Windows 有更新、Defender 與 SmartScreen 都開著。 ✔ 照顧不到：NAS、伺服器與舊設備被直接攻擊、手機與訪客、郵件的第一層過濾、自動隔離、集中的網路紀錄。 ✔ 該做的事：到期前匯出報表與日誌、提醒同仁、確認備份與更新，再決定繼續續約、加裝 Pico-UTM 100，或先觀察。 Pico-UTM 100 對應 FLEX 200 的網址、攻擊、病毒三層，但沒有應用程式管控、垃圾信過濾與自動隔離，詳見對照表。背景防護依賴：沒出事，不代表沒有東西被擋防護成功的時候，使用者什麼也看不到。用了幾年之後，同仁自然把「沒事」當成理所當然，不知道網路入口有一層檢查一直在運作。這會默默養鈍風險敏感度：信件看起來正常就打開，連結看起來正常就點，因為過去點了也沒發生事。真正的原因不是「那些連結都安全」，而是「那些危險連結在到達電腦之前已經被擋掉」。防護服務到期後，行為習慣不會跟著改變，這段空檔最危險。同仁仍照「有防護」的習慣操作，而防線已經少了一層。所以不續約的第一件事，是讓同仁知道「以前有人在擋，現在沒有了」。 FLEX 200 與 Pico-UTM 100 功能對照核心的網址、攻擊、病毒三層，Pico-UTM 100 都有對應；差在 Pico-UTM 沒有應用程式管控、垃圾信過濾與自動隔離。防護面向 ZYXEL... » read more

Read

steven written 6 days ago

外掛式資安服務與資安閘道器的位置差異

工程師思路系列・事出必有因企業訂閱電信業者的資安外掛服務（例如中華電信資安艦隊），是好消息。對供應鏈資安查核而言，這是一項具體的邊界防護佐證。但外掛服務擺在業者端，和擺在公司內網入口的設備，看到的東西並不一樣。這篇文章用「位置」來說明兩者的差異與搭配。圖：兩類佐證各自回答不同的查核問題。本圖為架構說明，不構成任何合規認證。外掛式服務（中華電信資安艦隊這類）的優點與位置界線優點：不必自行維護設備，且在網路業者端先行攔阻已知威脅，減少帶威脅的流量進入公司。服務範圍界線則是位置：設備位於業者端，看到的是企業防火牆送出的連線，通常以單一公網位址呈現。若某條連線有疑慮，較難進一步指出是公司內部哪一台電腦或設備發起的。簡單地說資安艦隊這類服務，在外面把火勢擋下來，但看不出是公司內網哪一台設備一再點火。圖解：方案擺放位置不同，帶來不同效果圖：兩種方案擺放位置不同，看到的內容也不同。下方示意圖再把位址轉換（NAT）的邊界標出來。位址轉換前：公網側位址轉換後：內網側網際網路 → 中華電信資安艦隊外部邊界防護 → 防火牆路由器／閘道 ⇢ Pico-UTM 100 內部行為可視 → 主交換器 → 內網設備電腦・伺服器・AP NAT 邊界資安艦隊的觀察範圍進出口流量，通常以單一公網位址呈現 Pico-UTM 100 的觀察範圍名稱解析與對外連線，可對應到個別設備資安艦隊在位址轉換之前，Pico-UTM 100 在位址轉換之後。放在防火牆之後，才有機會分辨每一台設備。資安閘道器補上的位置資安閘道器（Pico-UTM 100）串接在防火牆與主交換器之間，是全公司設備對外連線的必經位置：防火牆 → Pico-UTM 100 → 主交換器 → 全公司電腦與設備（內部網路）內部網路這一區是日常行為與異常最常出現的地方，也是需要公司與維運方持續跟進改善的地方，但是並不在外掛式服務（資安艦隊這類）的服務範圍內。內網常見的兩類弱點 1 使用者端的資安風險意識。同仁一時閃神點到釣魚連結，或安裝來路不明的軟體，是資安事件最常見的起點之一。 2... » read more

Read

steven written 6 days ago

續篇：我們努力過了——請 AI 助理陪我探查舊 NAS 的真實環境

工程師思路系列・事出必有因續篇：我們努力過了——請 AI 助理陪我探查老舊主機的真實環境 Mr. τ ｜風雲網通系統｜ 2026-10-22 昨天那篇談的是「更新不動、換機不實際、放著不管、廠商不扛」四道難題。有人問我：你說得頭頭是道，那你自己的呢？這篇就是交代。我沒有憑印象下結論，而是請 AI 助理陪我確認一台對外主機的實際狀況。為了不替別人提供地圖，這篇刻意不寫品牌、型號、版本、位址與路徑，只談做法和結論。一、我是怎麼做的流程：AI 助理擬出唯讀指令，我貼到主機上執行，再把輸出貼回去讓它判讀。它自己能做的，只有從外網做最基本的連線測試，只看回應狀態。它一度想直接遠端登入，驗證失敗後就停手，沒有重試，也沒有猜密碼。檢查指令本身都是唯讀的。唯一的設定變動，是我為了檢查而暫時啟用了一個高權限帳號【請確認：檢查後是否已停用並更換密碼】。二、查到什麼 1 平台沒有修復路徑（以我的系統版本而言）。這台機器已升到它能升的最後一版系統，而平台提供的執行環境選項，全都停在已終止支援的舊分支，沒有任何一個落在官方的修復線上。這不是我忘了更新，是平台已經沒路了。 10/23 補充：設備廠商後來針對較新的系統版本發布了 PHP 更新，所以是否有修復路徑，取決於你的系統版本；較舊或已終止支援的系統仍沒有直接的路。【請依自己實際的系統版本確認：是否在廠商更新涵蓋範圍內】 2 PHP 實際被誰用。對外的網站只用到單一一組執行環境。同一台機器上另有少數附屬套件各自帶有執行環境，網站目錄裡也堆著多年累積的舊專案與測試檔。 3 對外曝露。網站前面有 CDN，從正式網域測試未使用的管理介面，回應是找不到。但來源主機的另一個入口上，仍有一個沒在使用的管理介面入口沒有來源限制，只要有人知道來源位址就可能連到。另外，我從外網確認有少數不該公開的檔案可以直接下載。漏洞公告逼你檢查，而檢查常常先翻出自己留下的爛攤子。 4 入侵跡象。我掃描了常見的後門特徵，也檢查了使用者上傳區：沒有命中。近期被修改的程式檔，我還在確認是否都出自我自己的更新。另有少數項目因為權限問題，檢查帳號讀不到；我查了擁有者、權限和內容開頭，判斷是我自己先前測試時留下的，網站程式本身也讀不到它。所以「沒有發現入侵證據」只涵蓋上述這幾項，不等於「沒事」。 5 順手發現的雜物。網站程式本身落後多年；附加元件很多，我還沒逐一確認哪些有啟用、哪些仍在維護；有些檔案的權限開得過寬；網站目錄裡有開發測試殘留。這些在多數老站都很常見，建議你也逐項檢查。三、同一台機器上別的套件呢？給也在用類似設備的讀者：不是每個套件都共用網頁服務的 PHP。我順便查了郵件類套件：執行中的行程和相依項目裡都沒有 PHP，所以在我這台機器上看不到它們使用 PHP 的跡象。10/23 補充：廠商公告提到部分郵件類套件需要手動更新，不同廠商、不同套件的實作不同，請以自己設備的公告為準。【請確認自己使用的郵件套件是否在受影響清單內】但有些套件會自帶獨立的執行環境，改網頁服務的設定改不到它。這只代表我這台機器，你的情況請自己查。四、今天的新情況 ✔ 攻擊活動變多了。據報導，雲端業者的蜜罐最早在 10/17 就觀察到攻擊嘗試，PoC 公開後嘗試快速增加。相對地，資安廠商在 10/21 的報告裡寫的是尚未獨立確認有大規模利用。兩者其實只是時間差，而且講的都是「嘗試」。我仍未看到可靠證據確認有網站被成功入侵，但風險已從「可能被利用」變成「正在被大量嘗試」，所以日誌建議至少從 10/17... » read more

Read

steven written 2 weeks ago

NAS 架站的四道難題：更新不動、換機不實際、放著不管、廠商不扛，然後呢？

工程師思路系列・事出必有因 NAS 架站的四道難題：更新不動、換機不實際、放著不管、廠商不扛，然後呢？ Mr. τ ｜風雲網通系統｜ 2026-10-21 晚間今天（10/21）PHP 官方釋出緊急安全更新，修補兩個 CVSS v4.0 評分 9.2 的遠端程式碼執行漏洞（代號 php2shell，CVE-2026-109618、CVE-2026-109619）。WordPress 核心的 CVE-2026-87902 則早在 9/22 就已修補，並已被美國 CISA 列入「已知遭利用漏洞」清單。這篇不是漏洞通報，我已經另外在社團發過。我想談的是：當你的網站架在一台更新不動的 NAS 上，到底該怎麼辦。一、這不是你一個人的問題我自己的官網，最早是一台自己安裝套件的 PC Linux 主機。後來考慮到費電，改用 NAS，前後換過兩代。每一步都合理：省電、省維護、快速上線。大家平常都忙著日常工作，建站這件事，本能就會挑「懶人包」。就算本職是工程師，也一樣：能省時間的 Appliance，就用 Appliance。但 Appliance 賣的是「不用自己維護」，這個承諾有一個隱含條件：廠商要持續維護。型號老舊、原廠不再支援的那天，承諾就消失了，而網站還掛在外網上，沒有人通知你這個條件已經不成立。二、為什麼更新總是被拖更新的成本是現在就要付的： ✔ 先備份網站、資料庫、系統與設定 ✔ 嘗試升級，失敗要能退回 ✔ 就算成功，可能還要轉換一些設定與規格檔案更新的回報卻是看不見的：做好了，什麼都不會發生；沒做，也往往很久都不會出事。所以只有兩種情況會認真做：有人付維護費，或是出事之後。有維運責任的工程師，其實都不想碰這件事，但早晚會遇到。這是痛點，不是疏失。三、四道難題把處境攤開，會發現是四個條件互相卡住： 1 NAS 的網站功能好用，會繼續用。內建功能方便、上線快，沒有理由放棄。... » read more

Read

steven written 2 weeks ago

沒料到的隱藏路由器：一次韌體更新，揪出區網裡的小天地

工程師思路系列・事出必有因沒料到的隱藏路由器：一次韌體更新，揪出區網裡的小天地原廠來信說有新版韌體，修了兩個 CVE，建議客戶盡速更新。我照做了，幾家客戶都順利過關，只有一家，更新完就從我的 CMS 設備清單裡消失了。接下來的追查，讓我發現這家企業的區域網路裡，還躲著一台沒人記得的 IP 分享器。起因：一封原廠通知信那天檢視 E-Mail，看到原廠通知：Pico-UTM 100 推出新版本，解決了兩個 CVE 資安問題，建議客戶盡速更新。我替一些客戶安裝建置了 Pico-UTM 100，也透過原廠提供給經銷商夥伴的 Lionic CMS 系統管理它們。只要在客戶端的 Pico-UTM 100 填入敝公司的 CMS 主機資訊，就能持續看到企業端推播過來的資安紀錄與統計資訊。這對於協同客戶一起了解企業面臨哪些網路資安威脅，是很好的輔助設計；CMS 也包含了「對企業端 Pico-UTM 發起韌體更新要求」的功能，這次就派上用場。 📌 補充：Pico-UTM 100 擺在哪裡？為什麼它的「WAN 端」是內網 IP？（點此展開） Pico-UTM 100 是單 WAN 埠、單 LAN 埠的結構，常見擺放位置在路由器（防火牆）與主交換器之間。這個樞紐位置，可以同時看到全內部網路的電腦與設備，以及它們與網際網路之間的連線情況。這樣擺放時，會採用原廠所稱的「橋接模式」，也就是一般網通廠說的「透通模式」。要注意的是，雖然介面上寫著 WAN / LAN 字樣，但在這個架構下，Pico-UTM 100 的 WAN 端 IP，被設定派發的仍是原本內網區域網路的網段，主要是方便內部網路管理者在同一網段就能直接管理這台資安閘道器。至於設備預設的 LAN 網段，則是比較少見的... » read more

Read

steven written 2 weeks ago

從氣冷極限到後 3M 時代：解密 AI 伺服器散熱的物理限制與商業博弈

工程師思路系列・事出必有因從氣冷極限到後 3M 時代：解密 AI 伺服器散熱的物理限制與商業博弈作者：Mr. τ ／風雲網通系統隨著生成式 AI 與大型語言模型的爆發，AI 晶片的功耗正以恐怖的速度飆升。當單顆 GPU 的功耗跨越 1000W 大關、單一機櫃發熱量衝破 120kW 時，散熱技術已經不再是硬體的「附屬品」，而是決定 AI 算力能否完整釋放的核心關鍵。 💡 本文要回答的問題許多科技影片都說「氟化液浸沒式散熱比傳統氣冷強 10 倍」。這在物理上是如何辦到的？既然如此強大，為何當前的 AI 機房依然以局部水冷（冷板式）為絕對主流？本文從物理特性、成本效益、應用場景與風險控制，全面拆解這場散熱革命。一、氣冷（風冷）的「物理天花板」傳統資料中心依賴風扇帶動空氣流動，配合機房冷氣進行解熱。然而，風冷系統存在著無法跨越的物理極限： ✔ 單櫃解熱上限：工程實務上，傳統氣冷機櫃的散熱極限普遍落在 15 ~ 25 kW。即便透過極致的氣流優化與後門熱交換器（RDHx），頂多也只能勉強推至 30 ~ 40 kW。超過這個範圍，熱點（Hot Spot）累積與風扇自身的功耗將會急劇上升。 ✔ 物理性質的孱弱：空氣的熱傳導與帶熱能力天生弱勢。常溫下的比熱容僅約 1.0 kJ/kg·K，且體積熱容極低，這意味著要帶走相同的熱量，需要極為龐大的風量。 ✔ 能源與噪音代價：為壓制高功耗晶片，風扇必須拉高至上萬轉。這不僅帶來如同飛機場般的機械振動與噪音，更使資料中心的 PUE（電力使用效率）高達 1.3 ~ 1.8，大量電力被白白浪費在「吹風扇」與空調上。當前主流的 AI 伺服器機櫃（如... » read more

Read

steven written 2 weeks ago

三顆基地台同時拿不到 IP：「重開就好」其實是最貴的答案

工程師思路系列・事出必有因　#DHCP　#無線基地台　#路由器汰換　#Nebula　#SMB IT 三顆基地台同時拿不到 IP：「重開就好」其實是最貴的答案一個住家網路的小事件，從現象判讀、根因推論，一路走到下一台閘道器怎麼選。今天收到客戶訊息：家裡各房間的三顆 ZYXEL NWA50AX 商用基地台，忽然全部拿不到 IP，燈號綠、橘交替閃。但同一時間，有線連接的電腦都能正常上網。客戶自己的推論很有道理：基地台半夜自動更新韌體或重開，醒來後向 ASUS RT-AC66U 要 IP，路由器卻沒有發放。重開 RT-AC66U 之後，一切恢復正常。事情就這樣結束了嗎？對客戶來說是。對工程師來說，「重開就好」只是止血，還沒有回答「為什麼」。一、先把現象讀對觀察我的判讀 AP 燈號綠橘交替 AP 本身正常開機，卡在「等 DHCP」這一步有線電腦正常上網電腦手上還有舊租約，沒到續約時間，不代表 DHCP 服務是好的重開 RT-AC66U 後恢復問題在路由器端（服務卡死、記憶體、過熱），不在 AP 端關鍵觀念：「有線電腦能上網」是最容易讓人誤判的證據。DHCP 只在「要 IP」和「續租約」的瞬間才被考驗；已經拿到 IP 的設備，在租約期內完全感覺不到 DHCP 服務已經死了。三顆 AP 同時重開、同時要 IP，才讓問題一次暴露。二、根因推論：四個嫌疑犯誠實聲明：這次重開前沒有留下 log，所以下面是推論，不是定論。工程師最怕把「合理的猜測」寫成「確定的原因」。 1 散熱不良。這台路由器放在家庭輕鋼架上，距離天花板很近，天花板附近是熱空氣積聚處。老機長期高溫，最典型的症狀就是「跑久了怪怪的」。 2 長期不重開導致服務卡死。路由與 NAT 還在轉發，但發放... » read more

Read

steven written 3 weeks ago

八年的電腦，與工程師的停損點 : 版本二｜完整脈絡版（含系統紀錄附註）

工程師思路系列・事出必有因八年的電腦，與工程師的停損點版本二｜完整脈絡版（含系統紀錄附註）起點：八年似乎是電腦的壽命上限這兩天處理了兩台出廠、售出八年多的電腦：ASUS ESC500 G4 工作站，與 ASRock DeskMini 110 迷你電腦。 ESC500 G4 全板固態電容，卻徹底不開機，無過電反應。DeskMini 110 開機無畫面，修整後換了好幾種 USB Live Linux，結果都一樣：不定期當機，而 CPU 與主機板溫度感應器的數值看起來都正常。為什麼溫度正常，機器還是會死這兩台我當年都做過熱處理：ESC500 G4 售出時為 PCH 加裝直吹的 8 公分風扇；DeskMini 110 拆下散熱器重塗散熱膏，把溫度壓在 40～60°C。熱的變因幾乎被排除，機器仍然走到終點。八年的瓶頸不全在溫度，而在材料與時間本身： ✔ 焊點疲勞：無鉛焊料經過數千次冷熱循環，產生微裂紋，症狀就是時好時壞。 ✔ 供電老化： VRM 的 MOSFET、電感與電容老化，只會在電流瞬變時發作，與溫度感應器無關。 ✔ 韌體資料衰退： SPI Flash 的資料保存有期限，只與時間有關，與溫度無關。 ✔ 電源與變壓器老化：迷你機的外接變壓器是唯一電源，老化後在負載瞬變時電壓下陷，板上溫度當然正常。一般經驗是：消費級與入門商用機約 6～8 年進入故障率上升期，工作站與伺服器級在環境良好時可以更久。這兩台剛好落在這個區間。找同期主機板，沒有意義換上去的是另一塊同樣老化八年的板子，焊點、電容、SPI Flash... » read more

Read

steven written 1 month ago

[理論框架] AI 協作認知模型

AI 協作認知模型 2026-09-28 · PCPiLOT 工程師思路系列大多數人以為自己需要被「教」，其實需要的是被「觸發」。人腦一直都有答案，只是沒有被喚醒的條件。越不需要學工具，就越需要學會判斷。越容易產生答案，就越需要知道什麼值得成為問題。越容易讓 AI 替你完成，就越需要保留自己能夠說「不對」的能力。概覽：六大群組與流向六個概念群組依因果流向排列 ① 時間與壓縮 ② 人腦機制 ③ AI協作結構 ④ 知識落地 ⑤ 稀缺性（貫穿全程） ⑥ 執行自動化一、觀念清單本討論串涉及的核心觀念，依出現順序整理： # 觀念說明 01 技術壓縮悖論效率提升不會自動轉換為自由，中間需要轉換機制 02 三種時間的區分工具時間 / 思考時間 / 目的時間 03 技能位置轉移從 How 往 What / Why / Is it correct 移動... » read more

Read

steven written 1 month ago