AI 研究在談什麼？其實「很少在談孩子」

 

近年來，「人工智慧（AI）」快速進入各行各業，從製造業、醫療、金融，到內容創作與教育本身，都正在經歷深刻轉變。
但一個關鍵問題是：當 AI 正在重塑產業與就業市場時，我們現在的孩子，真的被好好準備了嗎？

這篇文章整理了近年國際學術研究的發現，嘗試用比較貼近日常的方式，和你一起思考：學校與學習的重心，是否需要重新調整？又該怎麼調整？

---

一、研究在談什麼？其實「很少在談孩子」

在檢視大量與「AI、教育、就業、市場」相關的學術研究後，一個現象非常明顯：

👉 多數研究聚焦在大學與專業教育，而不是中小學。

研究主題大多是：

• 大學生或研究生的 AI 能力

• 工程、醫療、管理等專業如何因應 AI

• 產業 4.0、5.0 所需要的人才技能

真正直接討論「國小、國中、高中該怎麼調整課程與學習重心」的研究，其實非常少。

這意味著：
孩子正在進入一個被 AI 深刻影響的未來，但學術與政策討論，往往是在他們「長大之後」才開始。

---

二、研究一致認同的事：未來不只需要「會用工具的人」

雖然研究多半集中在高等教育，但它們對「未來需要什麼能力」其實有高度共識：

未來不是只需要「懂 AI 技術的人」，而是需要具備以下能力的人：

• 問題解決與批判思考

• 學習如何學習（適應變化）

• 跨領域合作與溝通

• 倫理判斷與責任感

• 數位與 AI 素養（不是寫程式而已）

換句話說，AI 越強，人類越需要的是「不容易被取代的能力」。

這其實對中小學教育是一個重要提醒：
👉 基礎教育的任務，可能不是教孩子「追最新科技」，而是培養長期可轉移的能力。

---

三、很多創新做法，但不一定適合每一所學校

研究中也出現大量「看起來很先進」的教育做法，例如：

• 學習工廠、虛擬實境（VR）

• 數位分身（Digital Twin）

• AI 個人化學習系統

• 專題導向與情境模擬學習

這些做法確實能縮短「學校學習」與「真實工作世界」的距離。

但問題是：

• 它們多半資源密集

• 需要高度師資與設備

• 通常發生在大學或企業合作場域

👉 如果直接套用到國民教育，可能會加劇城鄉與學校間的不平等。

---

四、一個尚未解開的核心拉鋸：學校是為了誰而改？

研究之間其實存在一個重要張力：

一邊認為：

教育應該快速對齊產業需求，否則孩子會失業。

另一邊提醒：

如果學校只為市場服務，可能會犧牲人文、倫理與公民價值。

這個拉鋸，在「兒童與青少年教育」特別關鍵。

因為對孩子來說，學校不只是職前訓練場，更是：

• 建立自我認同的地方

• 學習與他人相處的地方

• 理解社會與世界的起點

AI 時代的教育調整，不只是技術問題，而是價值選擇。

---

五、這些研究告訴我們什麼？三個重要提醒

1️⃣ 不要太晚才開始談未來

如果等到大學才開始調整，可能已經太慢。
「如何面對 AI 的未來」，應該是從小逐步累積的學習歷程。

2️⃣ 課程調整不等於加新科目

與其急著開「AI 課」，不如思考：

• 語文、數學、社會、自然，能否用不同方式培養思考力？

• 是否留有空間給探索、失敗與提問？

3️⃣ 教育需要系統性思考

單一科技或單一課程，無法解決結構性問題。
課程、教師、評量、政策，需要一起調整。

---

結語：也許，這正是現在該開始問的問題

這些研究最大的價值，不在於給出標準答案，而是在提醒我們：

如果 AI 正在重新定義工作與產業，
那麼「什麼是值得孩子花時間學習的事」，
本身就值得被重新討論。

這不只是教育者的責任，也關係到每一位學生與家長。

長時間用電腦、滑手機，真的會造成脖子痛嗎？目前我們已經知道的，和還不確定的事

 低頭看手機、長時間坐在電腦前，已經成為很多人每天的生活日常。

也因此，脖子痛、肩頸不舒服，幾乎成了現代人的共同經驗。

這些年，相關研究其實累積了不少證據。有些事情，現在已經相當明確；但也有一些問題，仍然值得繼續深入了解。

---

一、目前已經相當確定的事

✔ 長時間使用電腦或手機，和脖子痛「有關」

這一點在不同族群、不同國家、不同年齡層中都反覆被觀察到。

無論是：

• 辦公室工作者

• 學生

• 長時間使用手機的人

只要每天維持久坐、久低頭的狀態，出現脖子痛、僵硬或活動受限的比例，確實比較高。

---

✔ 姿勢不良會增加頸部的負擔

研究顯示，當頭部長時間向前或向下傾斜時，頸部承受的機械負荷會明顯增加。

這種狀態下，頸部肌肉容易疲勞、緊繃，長期下來可能影響活動度與日常功能。
這也是為什麼「前傾頭姿勢」常常被拿來討論。

---

✔ 運動與復健介入，對改善脖子痛是有幫助的

這是另一個相對一致的發現。

許多研究都顯示：

• 規律的頸部與肩頸運動

• 穩定與姿勢相關的訓練

• 搭配姿勢提醒或生活習慣調整

都能在短期內減輕疼痛、改善功能，讓人比較能正常活動與工作。

---

二、還沒那麼確定，但值得繼續研究的方向

🔍 姿勢真的「單獨」決定會不會痛嗎？

雖然姿勢不良和脖子痛有關，但並不是每個低頭的人都會出現問題。

有些研究開始指出：

• 睡眠品質

• 平常活動量

• 是否長時間久坐不動

可能同樣扮演重要角色。

未來的研究，或許需要跳脫「姿勢好或不好」的單一觀點，改用更全面的生活型態角度來看待這個問題。

---

🔍 為什麼有些人是「痠痛」，有些人卻是「麻、刺、電」？

目前多數研究關注的是疼痛程度與功能表現，但對於「神經相關的不適」探討相對有限。

像是：

• 放射痛

• 麻木感

• 神經敏感

這些常見於現實生活中的症狀，還沒有被充分納入研究設計中，這是一個明顯的研究空白。

---

🔍 改善效果能不能維持？

很多復健或運動介入在 4–8 週內都有不錯效果，但較少研究追蹤半年或一年之後的狀況。

問題在於：

• 停止介入後，效果會不會消失？

• 哪些改變能真正成為長期習慣？

這些都需要更長時間的研究來回答。

---

三、對一般人與研究者都很實際的提醒

從目前的證據來看，有幾件事情是相對合理、也不太有風險的方向：

• 避免長時間維持同一個姿勢

• 在使用電腦或手機時，適度調整高度與角度

• 保持基本的活動量與規律運動

• 不要忽略睡眠品質與生活節奏

而對研究者來說，未來或許可以更進一步思考：

• 為什麼相同使用習慣，影響卻因人而異？

• 哪一類人最需要介入？

• 介入的「關鍵成分」到底是什麼？

---

結語

長時間使用電腦和手機，已經不是「要不要」的問題，而是「怎麼用」的問題。

目前的研究已經告訴我們：
姿勢、使用時間與復健介入，確實會影響脖子健康。

但同時，也提醒我們：
真正的答案，可能不只藏在脖子本身，而是在整個生活方式裡。

這也是未來研究，最值得繼續探索的方向。

當 AI 很耗電，而人類其實很省電

 

為什麼我們需要重新思考人類 × AI 的任務分工？

近年來，人工智慧模型——特別是大型語言模型與深度學習系統——在能力上突飛猛進，但伴隨而來的，是一個越來越難忽視的問題：
AI 非常耗電。

訓練與執行一個大型 AI 模型，往往需要龐大的計算資源、資料中心與能源支撐；相較之下，人類在許多任務上的能量消耗其實相當低，而且具備高度彈性與適應力。
這不禁讓人產生一個關鍵疑問：

在 AI 高能耗、人類低能耗的情境下，哪些任務真的「應該」交給 AI？哪些其實更適合由人類完成？

而令人意外的是——
當我真正去檢視相關學術文獻時，發現這個問題幾乎沒有人認真回答過。

---

人類 × AI 協作研究，其實「很少談能源」

在過去十多年中，「人類–AI 協作」（Human–AI Collaboration）是一個非常熱門的研究主題。
你可以輕易找到大量文獻討論：

• Human-in-the-loop（人在決策迴圈中）

• Hybrid intelligence（混合智慧）

• Mixed-initiative systems（人機共主導）

• 任務分配、工作負載、決策支援

這些研究普遍告訴我們一件事：
👉 人類和 AI 搭配得好，效能會比單獨使用其中一方更好。

但問題在於——
這些研究幾乎都把「能源」當成背景條件，而不是分析變數。

---

AI 很貴，但我們假裝它不影響決策

即使在最新的研究中，學者們已經開始承認：

• 大型 AI 模型是 compute-intensive

• 訓練與推論成本極高

• 碳足跡與能源消耗不可忽視

然而，當研究進入「任務分配」或「人機協作設計」時，決策邏輯仍然幾乎只看：

• 誰比較準？

• 誰比較快？

• 誰比較不容易出錯？

• 誰比較安全、可控？

能源消耗，並沒有真正進入任務分工的判斷公式中。

換句話說，我們一方面承認 AI 很耗能，
另一方面卻在設計系統時，假裝這件事「與任務決策無關」。

---

「工作負載」被研究很多，但只研究了一半

另一個有趣的現象是：
在這些研究裡，「工作負載（workload）」是一個被大量討論的概念。

但它幾乎永遠只指：

• 認知負荷

• 心理壓力

• 操作複雜度

• 時間成本

卻很少有人問：

• 人類在完成這些任務時，實際的能量消耗是多少？

• 與 AI 的計算能耗相比，差距有多大？

• 在能源受限或永續目標下，這樣的分工是否合理？

結果就是：
👉 人類被默默假設成「低成本、可無限使用」的資源。

---

一個被忽略的結構性問題：能源的「不對稱」

如果我們把問題攤開來看，其實非常清楚：

• 人類的能量

  • 有上限

  • 可恢復

  • 任務依賴、情境依賴

• AI 的能量

  • 高度集中於資料中心

  • 與模型規模、推論次數直接相關

  • 在大規模使用時快速放大

這是一種結構性的能源不對稱。

但目前的 AI 協作研究，幾乎沒有把這個不對稱當成理論問題來處理。

---

那我們真正缺的是什麼？

回顧整個文獻脈絡後，一個結論變得非常清楚：

我們缺的不是更多「人類 × AI 很厲害」的案例，
而是「能源感知（energy-aware）」的人類–AI 任務分工思維。

也就是說，我們需要開始認真思考：

• 哪些任務「非 AI 不可」？

• 哪些任務其實由人類完成更節能？

• 在效能相近時，是否應該優先選擇低能耗的一方？

• 能不能把「能源成本」當成和準確率、速度一樣重要的設計指標？

---

為什麼這件事現在非做不可？

因為如果我們繼續只用「效能最大化」的邏輯設計 AI 系統，那麼：

• AI 會越來越大、越來越耗能

• 人類只被視為「監督者」或「瓶頸」

• 永續、碳排、能源限制永遠只能在政策層面補救

但如果我們反過來問：

在人類很省電、AI 很耗電的前提下，
我們該如何重新設計協作？

那麼，人類–AI 協作就不只是「更聰明」，
而有機會變成 真正可長期維持的智慧系統。

---

結語

人類與 AI 的協作，從來不只是「誰比較厲害」的問題。
在能源與永續成為現實限制的時代，
它同時也是一個如何分配有限資源的問題。

也許下一個關鍵突破，不是更大的模型，
而是更節能、更有意識的人類 × AI 分工方式。

收入 稅金 保險 財務計算小工具

 ## Github下載網頁

https://github.com/kuanding/TaiwanSimpleFinanceCalculator/tree/main

下載檔案中的Release.zip檔案

AI 程式設計代理如何運作——以及使用時該記住的

以下是繁體中文版的精要整理與說明：

https://arstechnica.com/information-technology/2025/12/how-do-ai-coding-agents-work-we-look-under-the-hood/

---

AI 程式設計代理如何運作——以及使用時該記住的事

從壓縮上下文的技巧到多代理協作，以下說明 AI coding agents（AI 程式設計代理）為何能運作、又為何不能被神話。

---

AI 程式設計代理的核心原理

1. 基礎是大型語言模型（LLM）

每一個 AI coding agent 的核心，都是一個大型語言模型（LLM）。
LLM 是在大量文字與程式碼資料上訓練的神經網路，本質上是一種模式預測器：

• 它根據提示（prompt）

• 從訓練中「壓縮」過的統計模式

• 產生看起來合理的延續內容

這使它能跨領域推理，但也會在判斷失準時產生自信但錯誤的結果（幻覺）。

為了讓模型更有用，基礎模型通常還會經過：

• 精細微調（fine-tuning）

• 人類回饋強化學習（RLHF）
  以學會遵循指令、使用工具、完成實際任務。

---

2. Coding agent 不是單一模型

所謂的「代理」其實是一個多模型系統：

• 一個「主管模型」負責理解使用者的目標

• 多個「工作模型」並行執行子任務（寫程式、跑測試、檢查檔案）

• 主管模型負責中斷、檢查與整合結果

常見的運作循環是：
蒐集脈絡 → 採取行動 → 驗證成果 → 重複

---

3. 工具存取讓代理強大，也帶來風險

Coding agents 通常能：

• 讀寫檔案

• 執行 shell 指令

• 跑測試與 lint

• 抓取網頁或下載程式

本機 CLI 工具需要使用者明確授權；
網頁版代理則通常在沙箱雲端環境中執行，以隔離風險。

---

最大限制：上下文（Context）

LLM 有有限的「短期記憶」，稱為上下文視窗。

重點問題包括：

• 每次回應都要重新處理整個對話與程式碼歷史

• 計算成本隨上下文大小呈平方成長

• 上下文越長，模型回憶準確度越低（稱為「context rot」）

• 大型程式碼庫很快就會耗盡 token 與成本

研究人員把這稱為有限的注意力預算。

---

Coding agents 的應對技巧

1. 把工作外包給工具

代理會主動：

• 撰寫腳本

• 使用 grep、head、tail

• 直接查詢資料庫

而不是把整個大型檔案塞進模型上下文，既省 token 又更準確。

---

2. 上下文壓縮（Context Compression）

當接近上下文上限時，代理會：

• 摘要自己的歷史內容

• 保留：架構決策、未解 bug、重要限制

• 丟棄：冗長的工具輸出與細節

這代表代理會「忘記」很多事，但能透過重新讀取程式碼與說明文件快速恢復方向。

---

3. 外部記憶文件

為了跨越上下文重置，建議使用：

• CLAUDE.md：常用指令、架構、風格

• AGENTS.md：代理行為指引（已成跨公司標準）

這些檔案就像代理的「長期筆記」。

---

4. 多代理並行架構

在長時間任務中：

• 主代理負責規劃與協調

• 子代理並行探索不同面向

• 只回傳濃縮後的重要結果

代價是：

• token 使用量約為聊天的 4 倍

• 多代理系統可達 15 倍

因此只適合價值夠高的任務。

---

人類使用者該記住的事

1. 「Vibe coding」很危險

在不了解程式碼的情況下直接部署，會：

• 引入安全漏洞

• 累積技術債

• 在專案成長時迅速崩壞

真正有價值的不是產生大量程式碼，而是證明它能正確運作。

---

2. 規劃比提示更重要

建議流程：

1. 先讓代理只讀檔案，不寫程式

2. 要求它提出完整計畫

3. 人類審核與修正

4. 再開始實作

否則模型常會選擇短期可行、但長期脆弱的解法。

---

3. AI 不一定讓你更快

2025 年一項隨機對照研究發現：

• 資深開發者使用 AI 工具反而慢了約 19%

• 儘管主觀感覺更快

• 對大型、成熟程式庫特別明顯

新模型是否改變結果，仍是未知數。

---

目前最適合的使用場景

較適合：

• 概念驗證（PoC）

• 內部工具

• 實驗性重構

• 大量樣板程式碼任務

較不適合：

• 安全關鍵系統

• 成熟的大型產品

• 缺乏人類審核的專案

---

總結

AI 程式設計代理是強大的半自主工具，而不是能負責任的工程師。
它們用壓縮換規模、用成本換速度、用自動化換取人類監督。

用得好，它們是助力；用得盲目，它們會讓事情更糟。

Quora 上多位作者對「人生中應該知道的事」

 ## 一、自我認知與人生態度

- 沒有人真的在意你擁有什麼，不要把快樂建立在他人眼光上  

- 思考你想成為什麼樣的人，而不只是追求成就或標籤  

- 你終將會死亡，這件事本身應該影響你如何活著  

- 人生的意義不需要依賴另一個人來完成  

- 永遠付出比「被要求的」多一點  

---

## 二、人際關係與情感連結

- 世界上確實存在少數真正關心你的人，珍惜他們  

- 把人生花在「會在乎你」的人身上，而不是試圖取悅所有人  

- 找能給你誠實回饋的朋友，他們會在關鍵時刻救你  

- 不要因外表、地位、金錢或刺激而結婚  

- 原諒父母、家人與那些不理解你的人，這是為了讓自己自由  

---

## 三、責任、倫理與內在價值

- 你對他人有責任，但你的人生只對自己負責  

- 誠實、正直、善良、可靠應成為你「被看見的日常狀態」  

- 行事應來自內心的真實，而非情緒或理性表演  

---

## 四、金錢、風險與現實世界

- 金錢很多，但不值得用一生去換  

- 金錢也很殘酷，不要對財務風險掉以輕心  

- 避免為虛榮或短暫滿足而背負債務  

- 為意外與失序保留餘裕，永遠準備備案  

- 理解基本的財務與會計概念，避免被制度或他人剝削  

---

## 五、思維能力與學習重點

- 學會溝通與修辭，看懂話術、影響他人，而不被操控  

- 用「系統思維」理解世界，而不是只看表面  

- 理解人類心理，能大幅減少人生彎路  

- 學會清楚表達自己（說、寫、創作），不要讓一生處於「無聲狀態」  

---

## 六、身心健康與長期人生

- 健康是長期資產，越早照顧，回報越高  

- 正確營養決定你未來是活著，還是只是撐著  

- 音樂與藝術能穩定情緒、擴展精神與人際世界  

---

## 七、文化、社會與更大的脈絡

- 理解政府與制度如何「實際運作」，而非理想版本  

- 理解不同文化與價值觀，才能真正走向更大的世界  

- 認識自己的家族故事，建立穩定且超越成敗的身份感  

- 找到超越自我的精神核心或信念，而不只圍繞自己  

---

## 一句總結

> 清醒地看世界，誠實地對自己，  

> 把時間留給重要的人與真正重要的事。

IDENTITY 不保證連續 以及 視窗函數（Window Functions）

 這篇 2017 年的筆記在核心觀念上非常正確，即便到了 2025 年，IDENTITY 不保證連續 以及 視窗函數（Window Functions）是解決此類問題的最佳解 這兩點依然是 SQL Server 的黃金準則。

不過，經過了 8 年的演進（SQL Server 2019, 2022 以及 Azure SQL 的普及），我們可以用更現代的視角來補充細節與最佳實踐。

以下是用 2025 年的技術狀態 對這篇筆記的重新解釋與建議：

---

1. 核心觀念驗證：為什麼 2025 年還是會有跳號？

筆記中提到「IDENTITY 保證唯一，不保證連續」，這點在 2025 年依然是鐵律。跳號的原因除了 2017 年提到的 交易退回 (Rollback) 之外，在現代雲端與高並發環境下，還有一個更常見的原因：

• 快取 (Cache) 機制與伺服器重啟：

  現代版本的 SQL Server（尤其是 2012 之後及 Azure SQL Database），為了提升效能，預設會對 IDENTITY 進行快取（Cache）。如果伺服器意外重啟或服務切換（Failover），記憶體中未使用的號碼就會丟失。這導致你不只會看到跳 1、2 號，有時會看到跳 1000 號 或 10000 號 的斷層。

  • 2025 註解：這是為了高併發效能所做的權衡，通常被視為「特性」而非 Bug。

2. 效能評比更新：誰是冠軍？

2017 年的筆記比較了三種方法，結論是 LAG 函數成本最低 (18%)。

在 2025 年，這場比賽已經不用比了。

• Self Join (自我連結)：已被視為過時的寫法（Legacy pattern）。

• OFFSET：雖然可用，但語法較冗長，可讀性不如視窗函數。

• LAG / LEAD (視窗函數)：依然是 絕對的霸主。

現代 SQL Server 的優化器（Query Optimizer）對於視窗函數的優化已經非常成熟。使用 LAG 或 LEAD 來解決「Gaps and Islands」（間隙與孤島）問題是標準的 Best Practice。

3. 2025 年的最佳實作程式碼 (Modern T-SQL)

原本 2017 年的 LAG 範例寫得不錯，但我們可以讓它更精簡且資訊更豐富（不僅找出哪裡跳號，還能算出跳了幾號，以及缺少的號碼範圍）。

推薦寫法：

SQL

-- 2025 Modern Approach
WITH GapAnalysis AS (
    SELECT 
        c1 AS CurrentID,
        -- LEAD 往後看一筆，直接與下一筆比較，比 LAG 往前看更直觀一點
        LEAD(c1) OVER (ORDER BY c1) AS NextID 
    FROM tblNum
)
SELECT 
    CurrentID + 1 AS GapStart,       -- 缺號開始
    NextID - 1 AS GapEnd,            -- 缺號結束
    (NextID - CurrentID) - 1 AS GapCount -- 缺了幾個號碼
FROM GapAnalysis
WHERE NextID - CurrentID > 1; -- 只要下一號減現在這號大於1，代表中間有洞

為什麼這個寫法更好？

1. 使用 LEAD：邏輯上我們常想著「這一號跟下一號有沒有連著」，LEAD 語意上更符合直覺（當然用 LAG 效果完全一樣）。

2. 明確指出缺口範圍：直接告訴你「缺了 6 到 7 號」，而不只是「5 號後面有斷掉」。

4. 架構層面的建議 (Architectural Advice in 2025)

如果你的業務需求非常在意「連續編號」（例如：統一發票、會計傳票），不要依賴 IDENTITY。

在 2025 年的系統設計建議如下：

1. 接受跳號 (Accept Gaps)：

   對於訂單編號、會員 ID 等，跳號通常是可以接受的。為了追求連續號碼而犧牲資料庫的高併發寫入效能（需要 Table Lock）是不划算的。

2. 如果必須連續，請自建序號表 (Custom Sequence Table)：

   如果法律規定必須連續，請建立一張獨立的表格來管理序號，並在交易中使用 UPDLOCK 來確保取號。這會犧牲效能，但能保證連續。

3. 考慮使用 SEQUENCE 物件：

   SQL Server 2012 引入了 CREATE SEQUENCE 物件。雖然它預設也有快取導致的跳號問題，但它提供了 NO CACHE 的選項（雖然會降低效能），且可以跨多張 Table 共用同一個序號池，比 IDENTITY 更有彈性。

總結

這篇 2017 的筆記結論在 2025 年依然正確。

• 結論：使用 視窗函數 (LAG / LEAD) 是尋找不連續資料的唯一正解。

• 效能：依然是最高的。

• 心態調整：除非是會計與法規需求，否則在雲端與微服務架構當道的今天，「視跳號為常態」 是更健康的系統設計思維。