## Github下載網頁
https://github.com/kuanding/TaiwanSimpleFinanceCalculator/tree/main
下載檔案中的Release.zip檔案
2025/12/30
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. 規劃比提示更重要
建議流程：
先讓代理只讀檔案，不寫程式
要求它提出完整計畫
人類審核與修正
再開始實作
否則模型常會選擇短期可行、但長期脆弱的解法。
3. AI 不一定讓你更快
2025 年一項隨機對照研究發現：
資深開發者使用 AI 工具反而慢了約 19%
儘管主觀感覺更快
對大型、成熟程式庫特別明顯
新模型是否改變結果，仍是未知數。
目前最適合的使用場景
較適合：
概念驗證（PoC）
內部工具
實驗性重構
大量樣板程式碼任務
較不適合：
安全關鍵系統
成熟的大型產品
缺乏人類審核的專案
總結
AI 程式設計代理是強大的半自主工具，而不是能負責任的工程師。
它們用壓縮換規模、用成本換速度、用自動化換取人類監督。
用得好，它們是助力；用得盲目，它們會讓事情更糟。
2025/12/24
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，代表中間有洞
為什麼這個寫法更好？
使用
LEAD：邏輯上我們常想著「這一號跟下一號有沒有連著」，LEAD語意上更符合直覺（當然用LAG效果完全一樣）。明確指出缺口範圍：直接告訴你「缺了 6 到 7 號」，而不只是「5 號後面有斷掉」。
4. 架構層面的建議 (Architectural Advice in 2025)
如果你的業務需求非常在意「連續編號」（例如：統一發票、會計傳票），不要依賴 IDENTITY。
在 2025 年的系統設計建議如下：
接受跳號 (Accept Gaps)：
對於訂單編號、會員 ID 等，跳號通常是可以接受的。為了追求連續號碼而犧牲資料庫的高併發寫入效能（需要 Table Lock）是不划算的。
如果必須連續，請自建序號表 (Custom Sequence Table)：
如果法律規定必須連續，請建立一張獨立的表格來管理序號，並在交易中使用 UPDLOCK 來確保取號。這會犧牲效能，但能保證連續。
考慮使用 SEQUENCE 物件：
SQL Server 2012 引入了 CREATE SEQUENCE 物件。雖然它預設也有快取導致的跳號問題，但它提供了 NO CACHE 的選項（雖然會降低效能），且可以跨多張 Table 共用同一個序號池，比 IDENTITY 更有彈性。
總結
這篇 2017 的筆記結論在 2025 年依然正確。
結論：使用 視窗函數 (
LAG/LEAD) 是尋找不連續資料的唯一正解。效能：依然是最高的。
心態調整：除非是會計與法規需求，否則在雲端與微服務架構當道的今天，「視跳號為常態」 是更健康的系統設計思維。
訂閱：
意見 (Atom)