從 C#/.NET 後端到 AI Agent

對習慣使用 C#、ASP.NET Core 和 SQL Server 開發企業系統的工程師來說,投入 AI Agent 開發時,很容易產生一種錯覺:

「我已經把模型接進 Web API,也能呼叫工具、查詢資料庫,這應該算是一個完整的 Agent 專案了吧?」

但真正開始檢視系統設計,或準備在面試中介紹專案時,就會發現:

「能跑起來」、「值得寫進履歷」和「可以正式上線」,其實是三個不同的門檻。

一個展示用的 Agent,可以在順利的情境下完成任務;一個能展現開發能力的專案,必須說得清楚設計取捨;而一個能上線的系統,還必須面對權限、失敗、成本、監控與維運。

面試官不會只問你用了哪個模型、哪套框架。他更可能追問:

「這個需求為什麼要用 Agent?一般工作流程不行嗎?模型選錯工具怎麼辦?呼叫內部系統時,權限由誰檢查?文件改版後,知識庫怎麼更新?你怎麼證明這次調整真的讓效果變好?」

如果這些問題回答不出來,架構圖上放再多模型、資料庫和 Agent,也很難證明真正的工程能力。

從 .NET 工程師的角度來看,轉向 Agent 開發,不是把過去的後端經驗丟掉,而是把原本擅長的系統設計能力,延伸到一個「包含不確定性」的新環境。


一、先找出值得解決的問題,不要先決定「我要做一個 Agent」

開始專案之前,我會先問的,不是「要用哪套 Agent 框架」,而是:

「這個系統,究竟要幫誰減少哪一件麻煩的事?」

例如,企業員工申請費用報支時,可能需要先查制度、確認適用條件、檢查附件,再登入內部系統填寫資料。

這時候,可以考慮設計一個報支助理:協助查詢制度、整理申請條件、辨識缺少的資訊,並產生待確認的申請草稿。

但需求不能只寫成「使用 AI 提升報支效率」。還要繼續拆解:使用者最常卡在哪個步驟?哪些資料能取得?哪些判斷有明確規則?哪些操作需要本人確認?完成任務的標準是什麼?

對 .NET 工程師而言,這其實就是熟悉的需求分析與系統分析,只是多了一個必須判斷的問題:

哪些事情適合交給模型理解,哪些事情必須由程式保證?

理解使用者口語描述、整理文件內容,可以考慮交給模型;金額計算、資格判斷、資料驗證與權限控管,則應該由明確的規則與後端服務處理。

如果需求只是搜尋制度並附上來源回答,檢索加上生成可能就已經足夠,不一定需要自主規劃的 Agent。

專案的價值,不在於它被叫做什麼,而在於它是否解決了真實問題。

二、把 Agent 放進系統架構,而不是讓 Agent 取代系統架構

一個比較完整的 .NET Agent 專案,不應該只剩下:

「使用者輸入 → 呼叫模型 → 回傳答案。」

我會把它當成一套企業應用來設計。

ASP.NET Core Web API 負責接收請求、驗證身分與提供服務入口;應用服務負責管理任務流程、狀態與業務規則;模型存取層處理模型請求與回應;知識檢索層負責文件搜尋及來源資訊;工具層則透過受控介面,存取既有 ERP、EIP 或其他內部系統。

任務紀錄、操作結果與必要的稽核資料,也必須有適當的保存方式。

以報支助理為例,模型可以提出「需要查詢這位使用者的申請狀態」,但真正執行查詢的,仍然應該是經過授權的 C# 服務。

模型不能因為產生了一個員工編號,就自動取得該員工的資料;也不能因為生成了格式正確的參數,就被視為通過業務驗證。

模型負責提出下一步,系統負責決定這一步能不能做。

這正是後端工程師能發揮優勢的地方。

過去處理的介面、資料庫、權限、交易、例外、日誌與並行問題,並沒有因為加入大語言模型而消失。只是系統裡多了一個可能理解錯、判斷錯,也可能輸出不一致的元件。

因此,更需要清楚的責任邊界,而不是更少。

三、不是每個流程都需要 Agent,更不是 Agent 越多越厲害

如果一個流程已經很明確:

「提交申請 → 驗證欄位 → 檢查額度 → 產生單號 → 寫入資料庫。」

那就先把它當成一般業務流程來設計。

這些步驟既然有固定規則,就沒有必要每次都花 Token,請模型重新猜一次下一步要做什麼。

Agent 比較值得介入的地方,是任務路徑無法事先完全確定。例如,使用者只說:「幫我確認這筆出差費用還缺什麼,整理好後讓我送出。」

系統可能需要根據現有資訊,判斷要查哪份制度、讀取哪些申請資料、是否需要追問使用者,以及接下來該呼叫哪個工具。

這時候,模型的理解與動態選擇才有發揮空間。

但即使如此,最終的驗證、核准與寫入,仍然可以維持固定流程。

實務上值得考慮的設計,是讓 Agent 處理不確定的理解與選擇,讓傳統程式處理確定的規則與執行。

多 Agent 也是同樣的道理。

只有當任務真的需要不同專業、不同工具權限或可獨立處理的子任務時,才有理由拆分。否則,只是把一個難除錯的流程,變成好幾個互相傳話、一起難除錯的流程。

架構的成熟度,不取決於 Agent 的數量,而取決於每一個元件是否有存在的必要。

四、RAG 的重點,不是把文件塞進向量資料庫

如果履歷上的專案介紹只有:

「使用 Embedding 將文件向量化,搭配向量資料庫實現 RAG 問答。」

這比較像是在描述技術流程,還沒有說明你真正解決了什麼問題。

企業文件不一定乾淨、完整,也不一定只有一個版本。報支制度可能有附件、表格、例外條件,甚至同一項規定在不同年度有不同標準。

因此,RAG 的設計要從資料開始。

文件如何解析?表格中的金額與適用條件能不能保留關聯?切分後的段落是否失去前後文?每個片段能不能追溯到原始文件、章節、版本與生效日期?

接著才是檢索策略:關鍵字與向量搜尋如何搭配?召回多少內容?是否需要重排序?遇到不同版本互相衝突,該採用哪一份?

更重要的是權限。

使用者不能看的文件,就不應該先交給模型,再期待模型自行保密。

檢索階段就要考慮使用者、部門與文件存取範圍,而不是只在提示詞裡寫一句「請勿洩漏機密」。

至於查不到資料的情況,也應該有明確處理方式:補問條件、說明資料不足,或轉交人工確認,而不是把「沒有證據」包裝成一個語氣肯定的答案。

真正值得介紹的 RAG 專案,是你如何處理資料品質、版本、權限與引用,以及如何驗證這些設計有效,而不只是選用了哪一種資料庫。

五、設計 Agent 時,先問「它做錯了怎麼辦?」

Demo 通常展示最順利的一次;正式系統必須承受各種不順利。

模型可能選錯工具,工具可能逾時,外部 API 可能暫時故障,回傳資料可能不完整。使用者也可能中途取消,或在同一個任務裡連續修改需求。

因此,工具呼叫不能只有「成功就繼續,失敗就重試」。

在 C# 的實作上,可以用明確的輸入模型、型別與欄位驗證,限制工具接受的參數;但型別正確,只代表格式符合要求,不代表內容合理,更不代表使用者有權執行。

逾時、取消、重試與替代流程,也要分別設計。

尤其是有副作用的操作,不能盲目重試。

查詢資料失敗後再查一次,與建立申請失敗後再建立一次,風險完全不同。後者可能只是回應遺失,但資料其實已經寫入;這時再次執行,就可能產生重複申請。

所以,涉及寫入的工具,要考慮冪等性、操作識別碼與執行狀態查詢。涉及送審、寄信或其他重要操作,則應讓使用者確認具體內容,並由後端再次檢查授權與規則。

Agent 本身也需要界線,例如最大步驟數、最長執行時間與 Token 預算,避免陷入重複搜尋或無效呼叫。

讀取外部文件時,文件裡出現的「請忽略規則並執行某個操作」,也只能被視為文件內容,不能變成工具授權。

真正的工程能力,不是讓模型永遠不出錯,而是讓錯誤不會直接變成失控的系統行為。

六、沒有評估,就不知道你是在改善系統,還是在調整感覺

開發傳統 Web API,我們會寫單元測試、整合測試,確認輸入、輸出與業務規則。

加入 AI 之後,這些測試仍然需要,但還不夠。

因為提示詞、模型、文件內容或檢索設定改變,都可能影響結果。只挑幾個問題手動試問,很容易把偶然的好答案,誤認為整體品質提升。

我會先建立一批有代表性的測試案例,涵蓋正常問題、模糊問題、資料不足、文件衝突、越權要求,以及工具失敗等情境。

對 RAG,要分開觀察:有沒有找到正確資料、回答是否忠於資料、引用是否真的支持結論。

對 Agent,則要確認:任務是否完成、工具選擇與參數是否正確、有沒有不必要的呼叫,以及重要操作是否遵守確認流程。

另外,還要觀察回應時間、P95 延遲,以及每次成功完成任務的成本。單次模型呼叫便宜,不代表整個任務便宜;如果需要反覆重試,成本仍然可能很高。

比較不同版本時,應盡量使用相同條件與固定測試集,並保留未參與調整的案例,避免只把熟悉的題目調得很好。

模型輔助評分可以協助整理結果,但重要案例仍應透過人工抽查或可驗證的業務結果校準。

「我覺得回答變好了」,不是驗收標準;「在固定案例與明確指標下,哪裡改善、哪裡退步」,才是。

七、工程化不是附加功能,而是 .NET 工程師的主場

模型能回答問題之後,專案才剛開始。

接下來要處理的,是使用者如何登入、任務如何追蹤、服務重啟後如何恢復、設定如何管理,以及發生問題時如何定位原因。

這些事情,看起來沒有多 Agent 那麼醒目,卻決定了系統能不能被真正使用。

在 .NET 專案裡,我會透過依賴注入分離模型存取、檢索與業務工具,避免所有邏輯都塞進同一個 Controller。模型設定與提示詞也需要版本管理,才能知道某一次結果是由哪個版本產生。

長時間任務則要考慮持久化狀態與可靠的背景處理,而不只是把工作丟到背景就結束。任務做到一半服務重啟,究竟要繼續、重做,還是等待人工處理,必須有答案。

監控也不能只記錄「API 成功或失敗」。

一次任務可能包含多次模型呼叫、檢索與工具執行。需要透過一致的追蹤識別碼,把這些步驟串起來,才能知道時間花在哪裡、哪一步失敗,以及成本為何增加。

同時,日誌不能因為方便除錯,就無限制保存完整對話、個資與機密文件;紀錄範圍、遮罩與存取權限,也屬於設計的一部分。

至於 Redis、訊息佇列、Docker 或 Kubernetes,要依需求選擇,而不是為了讓履歷看起來豐富而全部加入。

工程化不是把技術堆滿,而是讓每一個重要行為都能被控制、追蹤、測試與維護。

八、第一個 .NET Agent 專案,應該怎麼落地?

我會選擇範圍明確、能取得資料,而且可以定義完成標準的場景,而不是一開始就做「什麼都能處理的企業助理」。

以前面的報支助理為例,第一版可以只完成:

查詢制度、讀取本人申請資料、辨識缺少資訊,以及產生待確認草稿。

先不讓它自動核准,也不開放任意 SQL 或任意系統操作。

接著,把流程拆成確定與不確定兩部分:由模型理解需求、選擇受控工具、整理說明;由 C# 服務處理查詢授權、資料驗證、計算與狀態管理。

完成主要路徑後,不是立刻增加更多 Agent,而是補上資料不足、檢索錯誤、工具逾時、使用者取消與重複提交等情境,再建立評估集與部署方式。

最後,整理能被驗證的成果,包括解決了什麼問題、為什麼採用這個架構、有哪些限制,以及測試結果如何。

對於確實完成上述功能的專案,履歷可以寫成:

使用 ASP.NET Core 與 C# 開發企業報支助理,整合制度文件檢索與既有系統 API,提供附來源的制度查詢、申請資訊檢查及草稿產生功能。將工具呼叫限制於授權服務,加入參數驗證、逾時控制與操作確認,並以固定測試集追蹤任務完成率、引用正確性、延遲與成本。

這段描述的重點不是名詞多,而是能讓對方看見你做了哪些設計、解決哪些問題,以及如何驗證。

若有改善數據,就附上實際量測結果與測試條件;沒有就不要編造。專案仍在 PoC 階段,也應清楚標示,不要把「設計上可部署」寫成「已正式上線」。

結語:轉向 Agent,不是離開後端,而是更需要後端思維

對 C#/.NET 工程師而言,投入 AI Agent 開發,不代表過去累積的技術突然失去價值。

恰恰相反,當模型可以參與判斷、選擇工具,甚至觸發業務操作時,介面設計、授權、資料一致性、錯誤處理與可觀測性,只會變得更重要。

一個值得寫進履歷的 Agent 專案,應該讓你清楚說明:為什麼做、為什麼這樣設計、模型與程式如何分工、失敗時如何處理,以及效果如何評估。

你不一定需要龐大的使用者數,也不一定需要複雜的多 Agent 架構,但必須對系統的行為、限制與結果有足夠理解。

Demo 證明模型在某些條件下做得到;工程化專案則要說明,系統如何穩定完成任务,又如何在做不到時安全停下來。

真正的 Agent 開發,不是替模型接上更多工具,而是把模型的不確定性,轉化成可以被驗證、管理與持續改善的服務。

這也是 .NET 工程師最值得帶進 AI 時代的能力。

用 AI 短片,說一點豐原的故事

用 AI 短片,說一點豐原的故事
最近開始嘗試用 AI 工具製作短片,把豐原的地方文化、歷史記憶與生活風景,轉化成歌曲和影像,探索不同的說故事方式。
從熟悉的街道、廟口的熱鬧,到日常生活裡容易被忽略的小細節,都是創作的靈感。透過 AI 協助發想歌詞、生成音樂與畫面,再慢慢整理、調整,讓一段段關於豐原的故事,有機會用更輕鬆、親近的方式被看見與聽見。
製作過程中,最有趣的地方,是思考如何讓作品帶出在地的感覺。一首歌、一段畫面,能不能讓熟悉豐原的人產生共鳴,也讓還不認識這座城市的人,多一點好奇?
涉及歷史的內容,也需要回頭查找資料,分清楚史實與創作想像。AI 能幫忙呈現故事,而故事裡的細節,仍值得花時間理解與確認。
目前還在持續摸索,希望透過這些小小的創作,記錄自己眼中的豐原,也邀請大家一起重新發現家鄉的美。如果你有想聽的豐原故事,或記憶中特別的地方,歡迎留言分享,說不定就會成為下一支短片的靈感!




Redis 走進 AI 架構:從快取資料,到替 Agent 準備正確的上下文

做後端開發,談到 Redis,第一個想到的通常是快取:商品資料先放一份、Session 集中管理、熱門查詢少打幾次資料庫。

但當系統開始加入 AI 助理,新的問題出現了。

使用者前面才說要查台中門市,下一輪問「那今天還有貨嗎?」系統卻不知道「那」指的是哪一項商品。模型回答得很流暢,查到的卻是昨天的庫存。

站在 .NET 系統架構的角度,我更關心的是:每次呼叫模型之前,應用程式能不能把正確、最新,而且符合權限的資料準備好?

Redis 的 AI 能力,值得從這個問題開始理解。

模型負責理解與生成;應用程式必須負責提供可信的上下文。

先釐清:Redis 的 AI 能力有不同層次

「Redis 接入 AI」很容易讓人以為,只要升級資料庫,就會自動多出一個懂業務的助理。

實際上,可以分成資料檢索與上層服務來看。Vector Sets 提供原生向量集合操作;Redis Query Engine 則能在 Hash、JSON 資料上建立索引,組合向量、全文與結構化條件。兩者的操作方式與適用情境不同。Redis 向量索引說明

Redis Iris 則把 Agent Memory、LangCache、Context Retriever 與 Data Integration 組合成上下文服務,涵蓋記憶、語意快取、受治理的資料存取及資料同步。Redis Iris 官方文件

選型時,我會分別確認資料庫版本、部署方案及服務需求。支援某個向量命令,並不表示整套 Agent 記憶流程已經完成設定。

用餐飲 POS 來看:三種問題,需要三種資料

假設我們正在替連鎖餐飲系統開發 AI 客服。使用者可能問:

使用者的問題系統需要的資料我會採用的處理方式
「外帶訂單如何取消?」門市適用的取消規則檢索有效版本的政策文件
「照我上次的口味推薦」已確認的使用者偏好讀取該使用者的長期記憶
「我剛才那筆訂單退款了嗎?」該筆訂單最新狀態驗證身分後查詢訂單服務

這三題都以自然語言提出,資料來源卻完全不同。

退款規則適合從知識庫找;口味偏好適合從記憶找;退款進度應查詢實際訂單。若把所有問題都丟進同一套向量搜尋,很容易找到「看起來相關、實際上不能作答」的內容。

因此,我會先設計問題分流,再決定 Redis 在各條路徑扮演什麼角色。

向量搜尋:先限定資料範圍,再找語意相近的內容

向量可以協助系統找到用詞不同、意思相近的內容。例如「外帶取消」與「撤銷取餐訂單」,不一定包含相同關鍵字,卻可能指向同一份規則。

如果只需要輕量的相似度查詢,可以評估 Vector Sets;若文件還要搭配門市、分類、日期或其他查詢條件,則可以評估 Query Engine。後者提供向量搜尋與 metadata 過濾,向量索引可依需求選擇 FLAT、HNSW 等演算法。Redis 向量搜尋文件

在多租戶系統中,我會讓後端從已驗證的身分取得租戶範圍,把必要的存取限制帶進檢索流程。不能讓使用者輸入一句「查另一家公司的文件」,就改變查詢權限。

資料範圍正確後,才有討論相似度與排序的意義。

Agent 記憶:保存對話,還要管理事實如何更新

Redis Agent Memory 區分會話與長期記憶。啟用相關功能後,可以在背景摘要較早的對話,並抽取值得保留的事實與偏好,形成可搜尋的長期記錄。Agent Memory 官方說明

但「存起來」只是起點。

使用者上個月偏好辣味,今天說最近想吃清淡一點,系統該採用哪一筆?他只是替朋友訂餐,這次選擇又該不該成為本人的長期偏好?

我的設計會讓記憶保留來源、時間與適用對象,並提供更正、刪除與失效機制。對會影響實際交易的資訊,還要有明確的確認程序。

此外,重要條件不能只靠向量搜尋「剛好找到」。應用程式必須明確載入的限制,就應作為固定業務條件處理。

語意快取:相似的問法,未必有相同答案

LangCache 的用途,是讓語意相近的請求有機會重用既有回答,減少重複生成。Redis Iris:LangCache

例如同一門市、同一版本規則下,「外帶怎麼取消?」與「取消外帶的流程是什麼?」可能適合共用答案。

但是「我的退款到了嗎?」與「他的退款到了嗎?」即使語意非常接近,也不能因此共用結果。

我會先定義哪些回答允許快取,再檢查租戶、權限、語言、政策版本與有效期限。即時訂單、庫存與個人交易狀態,則走業務查詢路徑。

衡量成效時,也不只看命中率。錯誤重用答案的比例、政策更新後的失效速度,以及整體回應延遲,都應一起觀察。

放進 ASP.NET Core,責任應該怎麼分?

我會把請求入口設計成以下流程:

  1. 驗證使用者身分,取得租戶、門市與資料存取範圍。

  2. 判斷問題需要政策文件、個人記憶,還是即時業務資料。

  3. 對允許重用的問題檢查語意快取,其他問題直接進入檢索或服務查詢。

  4. 將取得的資料連同來源、時間與必要限制,整理成模型上下文。

  5. 產生回答;資料不足時,要求補充資訊或說明尚無法確認。

  6. 依保存政策更新對話、候選記憶及允許快取的答案。

在程式結構上,我會把知識檢索、記憶存取、快取判斷與訂單查詢拆成不同服務介面,讓 Controller 保持簡單,也方便單獨驗證每個環節。

若涉及取消訂單、退款或修改資料,仍由應用服務驗證權限、狀態轉移與重複請求。模型可以協助理解使用者意圖,交易是否成立則必須由業務規則決定。

這樣一來,未來更換模型或檢索服務時,也不必重寫整套訂單邏輯。

導入前,我會先算清楚兩件事

第一件是記憶體。

以 1,536 維 FLOAT32 向量為例,單筆純向量資料是 1,536 × 4 = 6,144 bytes;一千萬筆約 61.44 GB,還沒計入索引、文件、metadata、副本與其他開銷。

即使採用更低位元表示,也不能直接把純向量的縮小比例,當成整個 Redis 執行個體的節省比例。容量規劃應以實際資料與查詢品質測試為準。

第二件是資料生命週期。

可重建的快取與需要保存的長期記憶,對淘汰、備份及復原有不同要求。我不會因為都能放進 Redis,就直接讓它們共用相同的容量與淘汰策略。是否拆成不同執行個體,要看資料重要性、負載與故障影響。

我會從一個能驗證的小場景開始

第一階段,我會選單一門市的政策問答:整理文件版本,建立檢索,再用一組固定問題檢查答案與來源是否一致。

第二階段,才針對穩定、重複的問法加入語意快取,同時測試「問法相近但答案不同」的反例。

等這些行為可預期後,再加入跨會話偏好與即時訂單工具。每增加一項能力,就驗證它對正確率、延遲與維運成本的影響。

從 .NET 架構師的角度看,Redis 在 AI 時代的價值,是讓我們多了一組管理上下文的工具。真正決定系統品質的,仍是資料來源、權限邊界、更新機制,以及每次回答前的判斷流程。

讓 AI 記得更多之前,先讓系統知道:哪些資訊值得記住、什麼時候必須更新,以及這一次回答到底能相信哪一份資料。

讓 AI 不只會聊天:透過 CLI 擴充 AI 的實際工作能力

生成式 AI 很擅長回答問題、產生程式碼、規劃系統架構與整理技術文件。

但若 AI 只能停留在聊天視窗中,它多半只能告訴你:

  • 指令應該怎麼下
  • 程式應該怎麼寫
  • 系統應該怎麼部署
  • 錯誤可能發生在哪裡

真正要讓 AI 參與開發、測試、部署與維運,就需要搭配 CLI 工具。

CLI 是 Command-Line Interface,命令列介面。透過終端機、PowerShell、Git、Docker、Python、Node.js,以及各種雲端 CLI,AI 才能把「建議」轉換為「可執行的工作流程」。

簡單來說:

聊天介面讓 AI 提供答案,CLI 則讓 AI 有機會把答案轉換成實際操作。

當開發環境準備完成後,AI 可以協助:

  • 建立專案
  • 建立資料夾與程式檔案
  • 安裝開發套件
  • 執行程式
  • 執行測試
  • 分析錯誤
  • 修改程式
  • 操作 Git
  • 建立 Docker 容器
  • 部署雲端服務
  • 操作 Firebase
  • 查詢資料庫
  • 建立 CI/CD
  • 撰寫 PowerShell 自動化腳本
  • 分析系統 Log
  • 重複執行、修正與驗證

這也是 AI Coding Agent、AI CLI、Vibe Coding 與 Agentic Development 的核心基礎。


一、什麼是 CLI?

CLI 是透過文字指令操作電腦、開發工具與雲端平台的介面。

例如,使用 Git 下載專案:

git clone https://github.com/example/project.git

使用 Docker 啟動服務:

docker compose up -d

登入 Azure:

az login

部署 Google Cloud Run:

gcloud run deploy

當 AI 開發工具具備 CLI 操作能力後,通常可以依照以下流程工作:

  1. 理解使用者需求。
  2. 檢查本機開發環境。
  3. 建立專案與資料夾。
  4. 安裝必要套件。
  5. 產生程式碼與設定檔。
  6. 執行建置。
  7. 執行測試。
  8. 分析錯誤訊息。
  9. 修改程式。
  10. 再次執行與驗證。
  11. 建立 Git Commit。
  12. 部署到測試或雲端環境。

因此,CLI 不只是工程師輸入指令的工具,也是 AI 與作業系統、開發工具及雲端平台之間的重要橋梁。


二、Windows 本機建議安裝的基礎工具

若要在 Windows 電腦上使用 AI 搭配 CLI,建議先安裝以下工具。


1. Windows Terminal

Windows Terminal 是 Windows 上的現代化終端機工具。

官方安裝說明:

https://learn.microsoft.com/zh-tw/windows/terminal/install

Windows Terminal 可以同時操作:

  • PowerShell
  • Command Prompt
  • WSL
  • SSH
  • Azure Cloud Shell
  • 各種 CLI 工具

Windows Terminal 可視為整個 CLI 開發環境的主要入口。

安裝完成後,可以從開始功能表開啟 Windows Terminal,並在不同分頁中分別執行:

  • PowerShell
  • Git
  • Docker
  • Node.js
  • Python
  • Azure CLI
  • Google Cloud CLI

2. PowerShell 7

PowerShell 是 Windows 上非常重要的命令列與自動化腳本工具。

官方安裝說明:

https://learn.microsoft.com/zh-tw/powershell/scripting/install/install-powershell-on-windows?view=powershell-7.6

PowerShell 可以用來:

  • 管理檔案與資料夾
  • 安裝軟體
  • 呼叫 REST API
  • 控制 Windows Service
  • 控制 IIS
  • 建立部署腳本
  • 建立備份腳本
  • 建立排程工作
  • 檢查網站健康狀態
  • 分析 Log
  • 操作 Git
  • 操作 Docker
  • 操作雲端 CLI
  • 建立 CI/CD 腳本

確認 PowerShell 版本:

pwsh --version

啟動 PowerShell 7:

pwsh

PowerShell 特別適合以下環境:

  • Windows Server
  • IIS
  • .NET
  • SQL Server
  • Active Directory
  • 企業內部系統
  • 自動部署
  • 自動更新
  • 系統維運

例如,AI 可以協助建立一支 PowerShell 腳本,自動完成:

  1. 下載 GitHub 最新 Release。
  2. 解壓縮檔案。
  3. 停止 IIS。
  4. 備份現有網站。
  5. 保留 appsettings.json。
  6. 更新程式。
  7. 啟動 IIS。
  8. 驗證網站狀態。
  9. 失敗時自動還原。

3. Git

Git 是目前最重要的分散式版本控制工具之一。

官方網站:

https://git-scm.com/

Windows 使用者通常可以從 Git 官方網站下載 Git for Windows。

Git 可以用來管理:

  • 程式碼版本
  • 修改紀錄
  • 分支
  • Commit
  • Tag
  • Merge
  • 衝突處理
  • 程式碼還原
  • 遠端 Repository
  • 團隊協作
  • CI/CD 觸發
  • Release 版本

確認 Git 是否安裝完成:

git --version

查看目前 Git 設定:

git config --list

設定使用者名稱:

git config --global user.name "Your Name"

設定電子郵件:

git config --global user.email "you@example.com"

查看設定結果:

git config --global user.name
git config --global user.email

Git 的基本工作流程

Git 最常見的操作流程如下:

工作目錄
→ 暫存區
→ 本機 Repository
→ 遠端 Repository

查看目前修改狀態:

git status

將修改加入暫存區:

git add .

建立 Commit:

git commit -m "feat: add login feature"

推送到遠端:

git push

建立新的 Git Repository

在目前資料夾初始化 Git:

git init

加入所有檔案:

git add .

建立第一個 Commit:

git commit -m "Initial commit"

設定遠端 Repository:

git remote add origin https://github.com/owner/repository.git

推送至遠端:

git branch -M main
git push -u origin main

下載既有專案

Clone Git Repository:

git clone https://github.com/owner/repository.git

進入專案:

cd repository

查看目前分支:

git branch

取得最新版本:

git pull

建立功能分支

建立並切換到新分支:

git switch -c feature/add-login

較舊的寫法:

git checkout -b feature/add-login

完成修改後:

git add .
git commit -m "feat: add login feature"
git push -u origin feature/add-login

常見 Git 指令

查看 Commit 紀錄:

git log

以精簡格式查看:

git log --oneline

查看程式修改內容:

git diff

查看已暫存的修改:

git diff --staged

查看遠端 Repository:

git remote -v

切換分支:

git switch main

合併分支:

git merge feature/add-login

建立標籤:

git tag v1.0.0

推送標籤:

git push origin v1.0.0

Git 在 AI 開發中的重要性

AI 可以快速修改大量程式碼,但修改範圍越大,風險也越高。

因此,在讓 AI 操作專案前,建議先建立 Git Commit:

git status
git add .
git commit -m "chore: backup before AI changes"

AI 修改完成後,可以透過以下指令檢查差異:

git diff

若修改錯誤,可以使用 Git 還原。

還原單一檔案:

git restore path/to/file

取消暫存:

git restore --staged path/to/file

回到上一個 Commit 前,必須先確認是否會影響尚未保存的修改。

Git 對 AI 開發最大的價值包括:

  • 保留 AI 修改前的版本
  • 比較 AI 修改內容
  • 快速找出錯誤
  • 分批提交修改
  • 容易進行程式碼審查
  • 發生問題時可以還原
  • 可與 GitHub、GitLab、CI/CD 整合

4. Docker Desktop

Docker 可以將應用程式與其執行環境封裝成容器。

官方下載:

https://www.docker.com/products/docker-desktop/

Docker 適合用來建立:

  • PostgreSQL
  • MySQL
  • Redis
  • RabbitMQ
  • Nginx
  • Elasticsearch
  • Qdrant
  • Milvus
  • AI API
  • Python 執行環境
  • .NET 執行環境
  • React 前端
  • 測試環境
  • 微服務架構

確認 Docker 是否安裝:

docker --version

確認 Docker Compose:

docker compose version

查看執行中的容器:

docker ps

查看所有容器:

docker ps -a

例如,使用 Docker 建立 PostgreSQL:

docker run --name postgres-dev `
  -e POSTGRES_USER=postgres `
  -e POSTGRES_PASSWORD=YourPassword `
  -e POSTGRES_DB=appdb `
  -p 5432:5432 `
  -d postgres

AI 可以協助產生:

  • Dockerfile
  • docker-compose.yml
  • Volume
  • Network
  • Health Check
  • 環境變數
  • 多階段建置
  • 正式環境映像檔
  • 容器啟動腳本

5. Node.js

Node.js 是 JavaScript 與 TypeScript 的執行環境。

官方網站:

https://nodejs.org/zh-tw

Node.js 常用於:

  • React
  • Vue
  • Angular
  • Next.js
  • Nuxt
  • Vite
  • Three.js
  • Express
  • NestJS
  • MCP Server
  • AI CLI
  • 自動化工具
  • 前端建置

確認 Node.js:

node --version

確認 npm:

npm --version

建立 Vite 專案:

npm create vite@latest

安裝套件:

npm install

啟動開發環境:

npm run dev

建立正式版本:

npm run build

AI 可以透過 Node.js CLI 協助:

  • 建立 React 專案
  • 安裝 UI 套件
  • 建立 API
  • 建立 Three.js 場景
  • 執行 ESLint
  • 執行測試
  • 建立 Production Build
  • 分析 npm 安裝錯誤

6. Python 或 Anaconda

Python 是 AI、機器學習、資料分析、自動化與後端 API 常用的程式語言。

Python 官方下載:

https://www.python.org/downloads/

Anaconda 下載:

https://www.anaconda.com/download

Python 常見用途包括:

  • OpenAI API
  • Azure OpenAI
  • RAG
  • Embedding
  • 向量資料庫
  • 機器學習
  • 深度學習
  • OCR
  • Whisper
  • YOLO
  • 資料分析
  • Excel 處理
  • 網頁爬蟲
  • FastAPI
  • Flask
  • 自動化腳本

確認 Python:

python --version

確認 pip:

pip --version

建立虛擬環境:

python -m venv .venv

啟用虛擬環境:

.\.venv\Scripts\Activate.ps1

安裝套件:

pip install fastapi uvicorn openai

輸出套件清單:

pip freeze > requirements.txt

安裝專案套件:

pip install -r requirements.txt

Anaconda 則特別適合:

  • Jupyter Notebook
  • 資料科學
  • AI 模型研究
  • 多 Python 環境管理
  • 機器學習套件管理
  • 教學與實驗環境

三、如果要建立雲端服務

若希望 AI 協助建立或部署雲端服務,應安裝對應平台的官方 CLI。


1. Google Cloud CLI

官方網站:

https://cloud.google.com/cli

Google Cloud CLI 的主要指令為:

gcloud

可操作:

  • Cloud Run
  • Compute Engine
  • Cloud Storage
  • Cloud SQL
  • Google Kubernetes Engine
  • Artifact Registry
  • Secret Manager
  • Cloud Functions
  • IAM
  • Service Account
  • VPC
  • Load Balancer

登入 Google Cloud:

gcloud auth login

查看帳號:

gcloud auth list

查看專案:

gcloud projects list

設定預設專案:

gcloud config set project YOUR_PROJECT_ID

查看目前設定:

gcloud config list

設定預設區域:

gcloud config set run/region asia-east1

部署 Cloud Run:

gcloud run deploy

AI 可以根據需求協助:

  1. 建立 Google Cloud 專案。
  2. 啟用相關 API。
  3. 建立 Artifact Registry。
  4. 建立 Docker Image。
  5. 推送映像檔。
  6. 建立 Cloud Run。
  7. 設定 Secret Manager。
  8. 設定環境變數。
  9. 設定自訂網域。
  10. 建立自動部署腳本。

2. Firebase CLI

官方文件:

https://firebase.google.com/docs/cli?hl=zh-cn

Firebase CLI 通常透過 npm 安裝:

npm install -g firebase-tools

確認版本:

firebase --version

登入:

firebase login

查看專案:

firebase projects:list

初始化 Firebase:

firebase init

切換專案:

firebase use PROJECT_ID

部署:

firebase deploy

Firebase CLI 可管理:

  • Firebase Hosting
  • Firestore
  • Authentication
  • Cloud Functions
  • Storage
  • Emulator
  • Remote Config
  • App Hosting
  • Security Rules

AI 可以協助建立:

  • firebase.json
  • Firestore Rules
  • Storage Rules
  • Functions 專案
  • Hosting 設定
  • Emulator 設定
  • CI/CD 部署流程

3. Azure CLI

官方安裝說明:

https://learn.microsoft.com/zh-tw/cli/azure/install-azure-cli?view=azure-cli-latest

Azure CLI 的主要指令為:

az

登入 Azure:

az login

查看訂閱:

az account list --output table

設定訂閱:

az account set --subscription "訂閱名稱或訂閱 ID"

建立 Resource Group:

az group create `
  --name DemoResourceGroup `
  --location eastasia

Azure CLI 可操作:

  • App Service
  • Azure Functions
  • Container Apps
  • Azure Kubernetes Service
  • Azure SQL
  • PostgreSQL Flexible Server
  • Storage Account
  • Key Vault
  • Azure OpenAI
  • Virtual Machine
  • Azure Container Registry
  • Application Insights
  • Azure Monitor
  • Service Bus
  • Redis

AI 可以根據需求產生:

  • 建立資源腳本
  • 更新部署腳本
  • 環境變數設定
  • Key Vault 設定
  • 網路安全設定
  • Application Insights 監控
  • 刪除測試環境腳本

四、資料庫工具

AI 應用通常需要儲存:

  • 使用者資料
  • 系統設定
  • 對話紀錄
  • 文件索引
  • Embedding
  • 分析結果
  • 操作 Log
  • 任務狀態
  • 權限資料
  • AI Agent 執行紀錄

因此,資料庫也是 AI CLI 開發環境的重要部分。


1. PostgreSQL

下載網址:

https://www.enterprisedb.com/downloads/postgres-postgresql-downloads

PostgreSQL 適合:

  • 企業管理系統
  • SaaS
  • AI 應用
  • RAG
  • JSON 資料
  • 全文檢索
  • 地理資訊
  • 向量搜尋
  • 多租戶系統

搭配 pgvector 後,PostgreSQL 也可以儲存與搜尋 Embedding。

確認 PostgreSQL CLI:

psql --version

連線本機 PostgreSQL:

psql -h localhost -U postgres

指定資料庫:

psql -h localhost -U postgres -d appdb

建立資料庫:

CREATE DATABASE ai_demo;

查看資料庫:

\l

查看資料表:

\dt

離開:

\q

2. pgAdmin

官方網站:

https://www.pgadmin.org/

pgAdmin 是 PostgreSQL 的圖形化管理工具,可用來:

  • 建立資料庫
  • 建立資料表
  • 執行 SQL
  • 管理帳號
  • 管理權限
  • 查看連線
  • 備份
  • 還原
  • 查看效能

CLI 適合自動化,pgAdmin 適合視覺化管理,兩者可以搭配使用。


3. SQLite

官方網站:

https://www.sqlite.org/

SQLite 是輕量級嵌入式資料庫,不需要獨立資料庫伺服器。

適合:

  • 桌面程式
  • 手機 App
  • 小型系統
  • 單機工具
  • PoC
  • 快速雛型
  • 開發測試
  • 本機 AI 工具
  • 小型 RAG

資料通常儲存在單一檔案中,例如:

app.db

開啟資料庫:

sqlite3 app.db

查看資料表:

.tables

查看資料表結構:

.schema users

離開 SQLite:

.quit

4. DB Browser for SQLite

官方網站:

https://sqlitebrowser.org/

DB Browser for SQLite 可以透過圖形化介面:

  • 開啟 SQLite
  • 查看資料表
  • 編輯資料
  • 執行 SQL
  • 匯入 CSV
  • 匯出 CSV
  • 查看索引
  • 修改資料表結構

當 AI 產生 SQLite 專案後,可以使用 DB Browser 驗證資料是否正確。


五、版本控制與遠端平台 CLI

Git、GitHub CLI 與 GitLab CLI 是不同層級的工具。

可以簡單理解為:

工具主要用途
Git管理本機與遠端程式碼版本
GitHub CLI操作 GitHub 平台功能
GitLab CLI操作 GitLab 平台功能

GitHub CLI 與 GitLab CLI 不能取代 Git。

一般情況下,應先安裝 Git,再安裝 GitHub CLI 或 GitLab CLI。


1. Git

官方網站:

https://git-scm.com/

Git 負責:

  • Clone
  • Add
  • Commit
  • Pull
  • Push
  • Branch
  • Merge
  • Tag
  • Diff
  • Restore

例如:

git clone https://github.com/owner/repository.git
git switch -c feature/new-page
git add .
git commit -m "feat: add new page"
git push -u origin feature/new-page

2. GitHub CLI

官方網站:

https://cli.github.com/

GitHub CLI 的主要指令是:

gh

登入 GitHub:

gh auth login

查看登入狀態:

gh auth status

建立 Repository:

gh repo create

下載 Repository:

gh repo clone owner/repository

建立 Issue:

gh issue create

查看 Issue:

gh issue list

建立 Pull Request:

gh pr create

查看 Pull Request:

gh pr list

查看 GitHub Actions:

gh run list

查看執行結果:

gh run view

查看失敗 Log:

gh run view --log-failed

GitHub CLI 可讓 AI 協助:

  • 建立 Repository
  • 建立 Issue
  • 建立 Pull Request
  • 查看 Review
  • 分析 GitHub Actions
  • 下載 Release
  • 建立 Release
  • 管理 Workflow
  • 管理 GitHub 專案

3. GitLab CLI

GitLab CLI 發布頁:

https://gitlab.com/gitlab-org/cli/-/releases

GitLab CLI 的主要指令為:

glab

登入 GitLab:

glab auth login

GitLab CLI 可以連線:

  • GitLab.com
  • 自建 GitLab Server

查看 Issue:

glab issue list

建立 Issue:

glab issue create

查看 Merge Request:

glab mr list

建立 Merge Request:

glab mr create

查看 Pipeline:

glab pipeline list

查看 CI 狀態:

glab ci status

GitLab CLI 可讓 AI 協助:

  • 建立 Issue
  • 建立 Merge Request
  • 查看 Pipeline
  • 建立 Release
  • 分析 CI/CD
  • 操作自建 GitLab
  • 管理專案工作流程

需要注意:

GitLab CLI 負責管理 GitLab 平台,真正執行 CI/CD 工作的元件仍是 GitLab Runner。


六、AI 搭配 CLI 可以做哪些事情?


1. 建立網站專案

提示詞範例:

請使用 Vite 建立 React TypeScript 專案。

需求:
- 使用 React
- 使用 TypeScript
- 使用 Tailwind CSS
- 建立首頁
- 建立登入頁
- 建立後台 Dashboard
- 使用 React Router
- 安裝套件
- 執行 npm run build
- 修正所有建置錯誤

AI 可以協助執行:

npm create vite@latest
npm install
npm install react-router-dom
npm run build

並建立:

  • React 元件
  • 路由
  • 表單
  • Dashboard
  • API Service
  • CSS
  • 環境變數

2. 建立 Python API

提示詞範例:

請建立一個 Python FastAPI 專案。

需求:
- 提供健康檢查 API
- 提供使用者登入 API
- 提供 AI 問答 API
- 使用 SQLite
- 使用 SQLAlchemy
- 建立 requirements.txt
- 建立單元測試
- 啟動後驗證 API

AI 可以建立:

app/
├─ main.py
├─ database.py
├─ models.py
├─ schemas.py
├─ services/
├─ routers/
├─ tests/
├─ requirements.txt
└─ README.md

並執行:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install fastapi uvicorn sqlalchemy pytest
uvicorn app.main:app --reload
pytest

3. 建立 Docker 環境

提示詞範例:

請將目前 FastAPI 專案容器化。

需求:
- 建立 Dockerfile
- 建立 docker-compose.yml
- 建立 PostgreSQL
- 建立 Redis
- 建立健康檢查
- 使用環境變數
- 啟動後測試 API

AI 可以執行:

docker compose up -d --build

查看容器:

docker compose ps

查看 Log:

docker compose logs -f

4. 部署 Google Cloud

提示詞範例:

我要在 Google Cloud 建立一個網頁服務。

請使用 gcloud CLI 協助規劃與部署。

需求:
- Python FastAPI
- 使用 Docker
- 部署至 Cloud Run
- 區域使用 asia-east1
- 使用 Artifact Registry
- 使用 Secret Manager 儲存 API Key
- 設定環境變數
- 提供部署與刪除腳本
- 建立付費資源前先列出資源清單

AI 可以依序協助:

  1. 檢查 gcloud。
  2. 登入帳號。
  3. 設定 Project。
  4. 啟用 API。
  5. 建立 Artifact Registry。
  6. 建立 Docker Image。
  7. 推送 Image。
  8. 建立 Secret。
  9. 部署 Cloud Run。
  10. 驗證服務網址。

5. 部署 Azure 服務

提示詞範例:

請使用 Azure CLI 部署一個 .NET Web API。

需求:
- 建立 Resource Group
- 建立 Linux App Service
- 建立 PostgreSQL Flexible Server
- 使用 Key Vault
- 使用 Application Insights
- 設定正式環境變數
- 提供建立、更新與刪除腳本

AI 可以產生與執行:

  • az group create
  • az appservice plan create
  • az webapp create
  • az postgres flexible-server create
  • az keyvault create
  • az monitor app-insights component create

6. 操作 Firebase

提示詞範例:

請使用 Firebase CLI 建立一個 React 網站。

需求:
- 使用 Firebase Hosting
- 使用 Firestore
- 使用 Authentication
- 建立 Security Rules
- 建立本機 Emulator
- 建立 GitHub Actions 自動部署

AI 可以協助執行:

firebase login
firebase init
firebase emulators:start
firebase deploy

7. 操作 Git 與 GitHub

提示詞範例:

請檢查目前專案修改內容。

接著:
1. 建立 feature/login 分支。
2. 將修改分成合理的 Commit。
3. 推送到 GitHub。
4. 使用 GitHub CLI 建立 Pull Request。
5. 在 Pull Request 說明中列出修改內容與測試結果。

AI 可能執行:

git status
git diff
git switch -c feature/login
git add .
git commit -m "feat: add login feature"
git push -u origin feature/login
gh pr create

8. 操作 Git 與 GitLab

提示詞範例:

請分析目前修改內容。

接著:
1. 建立 feature/report 分支。
2. 建立 Commit。
3. 推送到公司自建 GitLab。
4. 使用 glab 建立 Merge Request。
5. 檢查 GitLab Pipeline。

AI 可能執行:

git switch -c feature/report
git add .
git commit -m "feat: add report module"
git push -u origin feature/report
glab mr create
glab pipeline list

9. 自動管理 Windows 與 IIS

提示詞範例:

請使用 PowerShell 建立網站自動更新腳本。

流程:
1. 從 GitHub Release 取得最新版本。
2. 下載 ZIP。
3. 驗證檔案。
4. 解壓縮。
5. 停止 IIS App Pool。
6. 備份目前網站。
7. 保留 appsettings.json。
8. 更新其他程式檔案。
9. 啟動 IIS App Pool。
10. 呼叫健康檢查網址。
11. 失敗時還原。
12. 將完整過程寫入 Log。

AI 可以協助:

  • 撰寫腳本
  • 執行腳本
  • 分析權限錯誤
  • 驗證 IIS
  • 驗證網址
  • 建立失敗還原機制

七、如何撰寫適合 AI CLI 的提示詞?

不建議只寫:

幫我建立一個網站。

這類提示詞過於模糊,AI 很難判斷:

  • 使用什麼程式語言
  • 使用什麼框架
  • 是否使用 Docker
  • 是否需要資料庫
  • 是否需要部署
  • 可以操作哪些 CLI
  • 是否可以安裝套件
  • 是否可以修改現有檔案

建議至少包含以下內容:

  1. 目標。
  2. 技術架構。
  3. 執行環境。
  4. 可使用工具。
  5. 功能需求。
  6. 驗證方式。
  7. 權限限制。
  8. 安全限制。
  9. 部署平台。
  10. 最終交付內容。

建議提示詞模板

你是一位資深軟體架構師、AI 工程師與 DevOps 工程師。

請在目前目錄建立一個可執行的專案。

技術需求:
- 前端:React、TypeScript
- 後端:Python FastAPI
- 資料庫:PostgreSQL
- 快取:Redis
- 容器:Docker Compose
- 雲端:Google Cloud Run
- 版本控制:GitHub

可使用工具:
- PowerShell
- Git
- GitHub CLI
- Python CLI
- Node.js CLI
- Docker CLI
- gcloud CLI

執行要求:
1. 先檢查所有必要工具是否安裝。
2. 查看目前資料夾與既有檔案。
3. 不要直接覆蓋重要檔案。
4. 建立專案結構。
5. 安裝必要套件。
6. 建立資料庫設定。
7. 建立 Dockerfile 與 docker-compose.yml。
8. 建立健康檢查 API。
9. 建立單元測試。
10. 執行建置與測試。
11. 修正所有錯誤。
12. 建立 Git 分支與 Commit。
13. 提供 Cloud Run 部署腳本。
14. 涉及付費資源前,先列出資源與可能費用。
15. 不要將密碼、Token 或 API Key 寫入 Git。

八、網頁 3D 與程式 3D 工具選擇


網頁 3D:Three.js

Three.js 是基於 WebGL 的 JavaScript 3D 函式庫。

適合:

  • 網頁 3D 展示
  • 產品模型展示
  • 3D 模型檢視器
  • 互動式場景
  • 數位孿生介面
  • WebXR
  • 教學模擬
  • 網頁小遊戲
  • 工業設備視覺化

安裝 Three.js:

npm install three

建立 Vite 專案:

npm create vite@latest threejs-demo
cd threejs-demo
npm install
npm install three
npm run dev

Three.js 可以搭配:

  • React Three Fiber
  • Drei
  • Vite
  • Blender
  • GLTF
  • GLB
  • WebXR
  • Cannon.js
  • Rapier

提示詞範例:

請使用 Vite、TypeScript 與 Three.js 建立 3D 網頁。

需求:
- 建立地板
- 建立環境光
- 建立方向光
- 載入 GLB 模型
- 支援滑鼠旋轉
- 支援模型縮放
- 支援物件點擊
- 顯示物件資訊
- 加入載入進度
- 加入效能統計
- 執行 npm run build 驗證

程式、遊戲與工業模擬:Unity

Unity 是跨平台 2D/3D 開發引擎,主要使用 C#。

適合:

  • Windows 3D 程式
  • 手機 App
  • 3D 遊戲
  • AR
  • VR
  • 工業模擬
  • 教育訓練
  • 數位孿生
  • 物理模擬
  • 互動式展示

Unity 適合需要以下能力的專案:

  • 角色控制
  • 動畫系統
  • 物理引擎
  • 碰撞偵測
  • 多平台輸出
  • VR/AR 裝置
  • 複雜場景管理
  • 手機感測器
  • 工業設備模擬

工具選擇參考:

使用情境建議工具
網頁顯示 3D 模型Three.js
網頁互動 3D 場景Three.js
網頁產品展示Three.js
網頁輕量遊戲Three.js
Windows 3D 程式Unity
手機 3D AppUnity
AR/VR 應用Unity
完整 3D 遊戲Unity
工業模擬Unity
教育訓練模擬Unity

九、安全與權限管理

AI 能操作 CLI,代表它也可能執行具有破壞性的指令。

因此,必須建立明確的安全界線。


1. 不要將密碼寫入提示詞或程式碼

避免直接提供:

  • 密碼
  • API Key
  • Access Token
  • GitHub Token
  • GitLab Token
  • 資料庫密碼
  • SSH Private Key
  • Service Account Key
  • Azure Client Secret

建議使用:

  • 環境變數
  • .env
  • User Secrets
  • Azure Key Vault
  • Google Secret Manager
  • GitHub Secrets
  • GitLab CI/CD Variables

.gitignore 建議包含:

.env
.env.*
*.key
*.pem
appsettings.Production.json
secrets.json
service-account.json

2. 執行刪除指令前必須確認

以下指令可能造成嚴重影響:

Remove-Item -Recurse -Force
rm -rf
docker system prune -a
az group delete
gcloud projects delete
git reset --hard
git clean -fd

執行前應先:

  • 顯示操作目標
  • 顯示實際路徑
  • 顯示預計刪除內容
  • 建立備份
  • 建立 Git Commit
  • 優先在測試環境操作
  • 避免直接操作正式環境

3. 使用 Git 保護程式碼

AI 大量修改程式前,先執行:

git status
git add .
git commit -m "chore: snapshot before AI changes"

修改完成後檢查:

git diff
git status

這樣可以:

  • 查看 AI 改了什麼
  • 找出不合理修改
  • 分批審查
  • 還原錯誤
  • 保留歷史紀錄

4. 區分不同環境

建議至少區分:

Development
Testing
Staging
Production

AI 初期應優先操作:

  • Development
  • Testing
  • 個人雲端專案
  • 測試用 Resource Group
  • 測試用 Git 分支
  • 測試資料庫

避免一開始就讓 AI 取得 Production 最高權限。


5. 使用最小權限原則

AI 使用的帳號、Token 或 Service Account,只應取得必要權限。

例如:

  • 部署 Cloud Run 不一定需要 Project Owner
  • 建立 Pull Request 不需要 Repository Admin
  • 查詢資料庫不一定需要 DROP 權限
  • 讀取 Log 不需要系統管理員權限
  • Firebase 部署不一定需要完整 Google Cloud 管理權限

十、安裝完成後的環境檢查

可以使用 PowerShell 快速檢查常用工具是否存在:

$commands = @(
    "pwsh",
    "git",
    "docker",
    "node",
    "npm",
    "python",
    "pip",
    "gcloud",
    "firebase",
    "az",
    "gh",
    "glab",
    "psql",
    "sqlite3"
)

foreach ($command in $commands) {
    $result = Get-Command $command -ErrorAction SilentlyContinue

    if ($result) {
        Write-Host "[OK] $command" -ForegroundColor Green
    }
    else {
        Write-Host "[Missing] $command" -ForegroundColor Yellow
    }
}

也可以進一步檢查版本:

$versionCommands = @{
    "PowerShell" = "pwsh --version"
    "Git"        = "git --version"
    "Docker"     = "docker --version"
    "Node.js"    = "node --version"
    "npm"        = "npm --version"
    "Python"     = "python --version"
    "pip"        = "pip --version"
    "gcloud"     = "gcloud version"
    "Firebase"   = "firebase --version"
    "Azure CLI"  = "az version"
    "GitHub CLI" = "gh --version"
    "GitLab CLI" = "glab --version"
    "PostgreSQL" = "psql --version"
    "SQLite"     = "sqlite3 --version"
}

foreach ($item in $versionCommands.GetEnumerator()) {
    Write-Host "`n=== $($item.Key) ===" -ForegroundColor Cyan

    try {
        Invoke-Expression $item.Value
    }
    catch {
        Write-Host "未安裝或無法執行" -ForegroundColor Yellow
    }
}

十一、建議的 AI CLI 基礎工具組合

初學者可先安裝:

Windows Terminal
+ PowerShell 7
+ Git
+ Node.js
+ Python
+ Docker Desktop

需要使用 GitHub 時,再安裝:

GitHub CLI

需要使用 GitLab 時,再安裝:

GitLab CLI

需要部署 Google Cloud 時,再安裝:

Google Cloud CLI
+ Firebase CLI

需要部署 Azure 時,再安裝:

Azure CLI

需要開發資料庫應用時,可安裝:

PostgreSQL
+ pgAdmin
+ SQLite
+ DB Browser for SQLite

十二、結論

AI 能不能真正參與軟體開發,不只取決於模型本身是否聰明,也取決於它能使用哪些工具。

只有聊天能力時,AI 通常可以:

  • 提供建議
  • 產生程式碼
  • 解釋錯誤
  • 規劃架構
  • 撰寫指令

搭配 CLI 後,AI 則可以進一步協助:

  • 建立專案
  • 建立檔案
  • 安裝套件
  • 執行程式
  • 執行測試
  • 修正錯誤
  • 操作 Git
  • 建立分支與 Commit
  • 建立 Pull Request
  • 建立 Merge Request
  • 建立 Docker 容器
  • 操作資料庫
  • 部署雲端
  • 建立 CI/CD
  • 執行系統維運
  • 產生自動化腳本
  • 驗證最終結果

其中,Git 是 AI 開發流程中非常重要的安全基礎。

Git 可以讓開發者清楚知道:

  • AI 修改了哪些檔案
  • AI 修改了哪些程式碼
  • 哪一個版本發生問題
  • 是否需要還原
  • 是否可以進行程式碼審查

因此,建議至少準備以下環境:

Windows Terminal
+ PowerShell 7
+ Git
+ Node.js
+ Python
+ Docker
+ GitHub CLI 或 GitLab CLI
+ Azure CLI 或 Google Cloud CLI

完成安裝後,可以在提示詞中清楚告訴 AI:

你可以使用 PowerShell、Git、Python、Node.js、Docker 與雲端 CLI。

請先檢查目前環境與 Git 狀態,再開始修改。

執行過程中:
1. 不要直接覆蓋重要檔案。
2. 不要刪除未確認的檔案。
3. 修改前先建立 Git 分支。
4. 修改後執行建置與測試。
5. 顯示完整錯誤訊息。
6. 修正後再次驗證。
7. 不要將密碼與 Token 寫入 Git。
8. 涉及雲端付費資源前,先列出預計建立的資源。

當 AI、CLI、Git、Docker、程式語言與雲端平台整合後,AI 就不再只是回答技術問題的聊天工具,而是能夠參與規劃、開發、測試、版本控制、部署與維運的工程協作工具。

Claude code 搭配 OpenRouter 使用免費的claude code (?)

claude code文件

https://code.claude.com/docs/zh-TW/overview

安裝 claude code (命令提示字元)

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

OpenRouter 註冊

https://openrouter.ai/ 註冊新帳號

OpenRouter 使用在claude code的說明

https://openrouter.ai/docs/guides/coding-agents/claude-code-integration

.claude/settings.local.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": ""
  }
}

加上 “ANTHROPIC_MODEL”:”openrouter/free” (使用系統分配,或是到model 搜尋免費 free https://openrouter.ai/models?q=free)

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "<your-openrouter-api-key>",
    "ANTHROPIC_API_KEY": "",
     "ANTHROPIC_MODEL":"openrouter/free"
​
  }
}

開啟 claude code

Azure 上的 PostgreSQL 如何撐起 ChatGPT 8 億用戶?微軟工程師親揭幕後秘辛

今天要來聊一個超有料的主題——ChatGPT 背後的資料庫架構,以及微軟工程團隊如何幫 OpenAI 撐過爆炸性的用戶成長。 這篇文章源自微軟官方部落格,由 Azure PostgreSQL 工程副總裁 Affan Dar 領銜撰寫。乾貨滿滿,讓我來幫你翻譯成人話。

先說背景:ChatGPT 有多誇張?

OpenAI 過去一年把資料庫規模擴大了 10 倍,要支撐的是高達 8 億月活躍用戶。這個量級是什麼概念?整個系統底層用的是 Azure Database for PostgreSQL,也就是微軟雲端上的 PostgreSQL 託管服務。 PostgreSQL 這個開源資料庫,平常我們可能覺得它就是個「普通關聯式資料庫」,但這次的故事告訴我們:只要配置得當,它真的可以撐到超大規模。

問題一:讀取副本老是跟不上主節點

什麼是讀取副本(Read Replica)?

簡單說,就是把資料庫「複製一份」給其他伺服器來分擔讀取流量,這樣主節點就不用一個人扛所有查詢。ChatGPT 的架構裡,一台主節點撐著超過 50 個分布在多個地區的副本,這數字已經很嚇人了。

發生了什麼問題?

在 OpenAI 某次大型服務上線前,工程師發現一個詭異現象:副本的資料會「越落越遠」,跟不上主節點的更新速度(這叫做 Replication Lag,複製延遲),而且它不會自己恢復,只能靠重啟副本才能解決,然後一天內又再次發生——陷入一個惡性循環。

問題的根源是什麼?

深挖之後,找到了罪魁禍首:TCP 壅塞控制演算法。 預設的 CUBIC 演算法在偵測到封包遺失(跨地區傳輸本來就難免)時,會把傳輸速度猛踩煞車,拼命退讓,導致複製速度大幅下降。

怎麼解決?

微軟團隊做了三件事:

  • 把壅塞控制演算法從 CUBIC 換成 BBR(對封包遺失更不敏感)
  • 調整 TCP 視窗大小設定
  • 引入**公平佇列(Fair Queuing)**網路排程,讓封包傳送更平滑 這三招組合拳下去,問題就解決了。

問題二:讀副本超過 50 個後怎麼辦?

微軟加入了**串聯副本(Cascading Replica)**支援,讓副本可以再複製給下一層副本,不用所有副本都直接連主節點。這樣就能在不影響主節點的情況下,繼續橫向擴展讀取能力。 此外,他們還開發了一個新技巧:從同地區的另一個副本快照建立新的異地副本,避免過去需要跨地區大量複製資料(可能要花幾小時甚至幾天)的痛苦。

問題三:寫入量太大,單台主節點 IOPS 不夠了

讀取問題解決了,但寫入量的成長讓單台 PostgreSQL 主節點的 I/O 效能上限捉襟見肘。這也是為什麼 OpenAI 後來把部分適合拆分的新工作負載移到 Azure Cosmos DB(NoSQL)去了。 但問題是,有些資料就是很難拆分(sharding 困難),這時候怎麼辦? 這就帶出了微軟的新架構:Azure HorizonDB,在 2025 年 11 月進入私人預覽。

Azure HorizonDB:為超大規模打造的 Postgres

這是目前最令人興奮的部分。HorizonDB 從根本上重新設計了 PostgreSQL 的儲存層,核心概念叫做「以 WAL 為中心的儲存模型」。

WAL 是什麼?

WAL(Write-Ahead Log,預寫日誌)是資料庫記錄「我要做什麼改變」的日誌,用來確保資料不會因為系統崩潰而遺失。PostgreSQL 傳統上是先寫 WAL、再把資料頁寫到磁碟。

HorizonDB 的創新在哪?

PostgreSQL 的計算節點不再直接寫資料頁到磁碟,所有持久化都透過 WAL 完成,資料頁由獨立的儲存層負責重建。 儲存層分成兩個獨立服務:

服務優化目標
WAL Server超低延遲的順序寫入
Page Server超大規模的隨機讀寫
WAL Server 可以在一次網路跳轉內就把一筆交易持久化到 3 個可用區域(傳統架構需要 4 次跳轉),大幅降低提交延遲。
Page Server 則把資料分散在大量 NVMe 高速磁碟上,讓單個 PostgreSQL 實例可以達到數十萬 IOPS 的讀取能力。

計算節點變成無狀態引擎

最妙的是,這個架構讓 PostgreSQL 的計算節點從此「輕裝上陣」——備份、複製、Checkpoint 等繁重工作全部交給儲存層,計算節點只需要專心處理業務邏輯,CPU、磁碟、網路資源都省下來了。 讀取副本也不再需要各自保存一份完整的資料拷貝,瞬間就能建立新副本,且每多一個副本完全不影響主節點效能。

總結:從這件事可以學到什麼?

這篇文章最有價值的地方,不只是技術細節,而是工程師解決問題的思路: 先找根本原因,而不是用重啟來掩蓋問題(TCP 壅塞控制的案例)。一步一步拆解問題,先解讀取延遲、再解讀取擴展、最後解寫入擴展。為未來設計,HorizonDB 的架構不是為了應付今天的問題,而是為了更大的明天。 PostgreSQL 在 8 億用戶的規模下能正常運行,背後是無數工程師的調校與創新。下次有人說「PostgreSQL 不能水平擴展」,你可以把這篇故事講給他聽。

原文來源:Microsoft Community Hub — Supporting ChatGPT on PostgreSQL in Azure(2026/1/29)

把 Windows Terminal 變成你的 AI 指揮中心:GitHub Copilot CLI 全攻略

身為每天泡在命令列的開發者,terminal 如果長得像 90 年代駭客電影道具,其實也說得過去;但既然現在都有 AI 幫寫 code 了,終端機不升級一下,好像有點對不起自己。這篇就來聊聊怎麼用 GitHub Copilot CLI 加上 Windows Terminal 的客製化,把你的 terminal 從工具升級成工作室。​


GitHub Copilot CLI 是什麼?

  • GitHub Copilot CLI 就是把 Copilot 搬進 terminal 裡,讓你不用開 IDE 也能在命令列裡問問題、要指令、請它幫你搞定各種工作。​

  • 作者分享會在陌生語言或新專案裡,用它幫忙「怎麼 build」、「怎麼下某個 shell 指令」,甚至讓它生成一個超大 lorem ipsum 檔來當 demo 測試檔案,省下一堆時間。​

安裝其實很簡單,只要一行 npm:

npm install -g @github/copilot

之後在 terminal 打 copilot 就能啟動 CLI,把它當成會寫文件、會記指令、偶爾還會幫你作弊查指令的搭檔就對了。​


先把 Copilot CLI 用爽:Banner、指令與互動

每次啟動都看到那個帥氣 Banner

預設 Copilot CLI 的動畫 banner 只有第一次出現,但作者表示:這麼帥的東西當然要每次看。​

有兩個做法:

  • 到 C:\Users\USERNAME\.copilot\config.json(WSL 則是 ~\.copilot\config.json),把 "banner" 設成 "always"。​

  • 啟動時改下指令:copilot --banner。​

在 Copilot CLI 裡直接跑 shell 指令

進到 Copilot CLI 之後,你輸入的每一行其實都是在跟 agent 聊天。那如果只是想跑個命令怎麼辦?
答案是:指令前面加一個驚嘆號 !。​

  • 例如:!git status、!ls,就會直接在 Copilot CLI 裡跑 shell command。

  • 好處是不用頻繁切來切去,可以一邊問 Copilot「我要怎麼做」,一邊直接執行它建議的指令。​


把 Windows Terminal 變成 Copilot 專屬套房

建一個「GitHub Copilot 專用 Profile」

作者的做法很簡單粗暴又實用:​

  1. 複製現有的 PowerShell profile。

  2. 改名字跟 icon(例如叫「GitHub Copilot」)。

  3. Starting directory 設成你平常放專案的資料夾。

  4. Command line 後面加上 -c copilot,例如:

    text
    "C:\Program Files\PowerShell\7\pwsh.exe" -c copilot

    這樣一開這個 profile,就自動進入 Copilot CLI,不用再多打一行指令。​

用 pane 分割:一半 Copilot,一半 shell

如果你想一邊跟 Copilot 聊天,一邊在另一個 shell 動手做,可以善用 Windows Terminal 的 pane 功能:​

  • 按住 Alt 再從 profile 下拉選單開啟新 profile,就會以分割 pane 方式打開。

  • 要關掉 pane 的話,用 Ctrl + Shift + W 即可。​

對多 repo、microservices、或 dev/test 併行的人來說,pane 基本上就是多工的救星。

啟動就回到上一次的工作現場

開發時最痛苦的就是「重開一次,原本開了哪些 tab 都不見」;作者直接把 Windows Terminal 的 Startup 設定改成「Restore window layout and content」,讓 Terminal 重啟時自動還原上次 tab 佈局。​

對正在 debug 或 demo 的人來說,這個設定等於幫你省下一輪「再把環境全部打開一次」的懲罰。

背景圖 + 復古掃描線特效

  • Windows Terminal 支援每個 profile 設不同背景圖,也可以在 Defaults → Appearance 當中設一張所有 profile 共用的背景圖。​

  • 想要懷舊一點,可以開啟「Retro terminal effects」,讓文字帶一點發光跟掃描線效果,兼具情懷與中二感。​


Prompt 也要穿得體面:Oh My Posh 上場

光只有 Copilot 不夠,terminal prompt 本身也要有點「生活品質」:這時候就輪到 Oh My Posh。​

裝好 Oh My Posh + Nerd Font

  • 安裝 Oh My Posh(作者偏好用 winget):

    bash
    winget install JanDeDobbeleer.OhMyPosh --source winget
    ```[1]
  • 接著下載一套 Nerd Font,作者愛用 Caskaydia Cove,你也可以選自己喜歡的字型,再到 Terminal 裡把該字型設定成 profile 的字型。​

選一個主題,變成你的個人看板

  • 官方主題列表在 Oh My Posh 官網,挑一個順眼的主題後,在 PowerShell profile 裡加上像下面這樣的一行:

    powershell
    oh-my-posh init pwsh --config "THEMENAME" | Invoke-Expression

    之後每次開 PowerShell 都會套用這個主題。​

  • 作者自己還貢獻了一個叫「cinnamon」的主題,可以把現在 Spotify 播放的歌顯示在 prompt 上,對邊聽音樂邊寫 code 的人非常友善。​

用 segment 把資訊塞進一行 prompt

Oh My Posh 的強項在於各種 segment,像是:​

  • Git segment:直接在 prompt 顯示目前 branch、diff 狀態、是否有未提交變更等。

  • npm、React segment:顯示目前使用的 npm 或 React 版本。

  • 音樂、甚至健康狀態 segment 都有,terminal 直接變成迷你 dashboard。​


在 prompt 上看 Copilot 使用量:Copilot segment

如果你是 Copilot 重度用戶,可能會好奇自己 quota 用了多少。從 Oh My Posh 28.1.0 之後,可以新增 GitHub Copilot segment,在 prompt 上顯示 Copilot premium 配額使用百分比。​

作法大致是:

  1. 從官方主題(例如 1_shell)複製一份 JSON 當自訂主題。​

  2. 在右側對齊的 segments 列表中加入一個像這樣的物件:

    json
    {
    "type": "copilot",
    "template": "  {{ .Premium.Percent.Gauge }} ",
    "cache": {
    "duration": "5m",
    "strategy": "session"
    },
    "properties": {
    "http_timeout": 1000
    }
    }
    ```[1]
  3. 在 PowerShell 裡跑一次 oh-my-posh auth copilot 做認證,之後 prompt 上就會出現一個小小的 Copilot 使用量 gauge。​

這樣你就可以一邊寫 code,一邊默默觀察自己今天「抄作業」抄了多少。


收尾:讓命令列變成你的開發主場

整篇下來,可以看到作者的核心理念很簡單:​

  • Copilot CLI 讓你在 terminal 裡有一個隨叫隨到的 AI 搭檔。

  • Windows Terminal 的 profile、pane、背景與啟動設定,讓你把工作流變成一鍵啟動。

  • Oh My Posh 則把 prompt 升級成資訊看板,再加上 Copilot segment,命令列不只是黑框白字,而是你的開發 cockpit。​

如果你每天都會開 terminal,那這些設定多花的那幾分鐘,很可能會在未來幾個月裡幫你省下好幾小時的來回切換和查指令時間。下次打開 Windows Terminal,不妨就從幫 Copilot 開一個專屬 profile 開始。

Claude Code 的問問題(AskUserQuestion)功能使用指南

您是否經歷過這樣的窘境?

告訴 AI 要做什麼,它信心滿滿地衝出去寫程式,但結果出爐時,您才發現它的想像跟您的想像南轅北轍。功能是能用啦,但就是不太對勁。於是您開始改改改,最後花的時間比自己從頭寫還多。

如果有這樣的經驗,恭喜您,您已經發現了 AI 編程最大的痛點:假設。

假設的代價

AI 就像一個對公司環境完全陌生的新人。您說「幫我加個登入功能」,它會馬上開始瞎猜:要用 OAuth 還是 JWT?支援哪些登入方式?需不需要角色權限管理?如果 session 逾時了要怎麼辦?

結果就是,AI 按照自己的想像寫出來的程式,可能根本不是您要的。浪費時間,浪費生命。

Anthropic 最近推出的 Claude Code 新功能「AskUserQuestion」,就是為了解決這個老問題。說白了,就是讓 AI 學會先問清楚再動手。

反轉遊戲規則:AI 來面試你

以前我們痴迷於「提示詞工程」——費盡心思琢磨怎麼跟 AI 說話,才能讓它做對事。現在 Claude Code 的 AskUserQuestion 功能反轉了這個關係:換 AI 來問你。

這聽起來簡單,但威力驚人。

想像這個場景:您跟 Claude 說「幫我整合使用者認證」。以前 Claude 會直接開始寫程式,現在它會停下來,一個接一個地拋出關鍵問題:

  • 您偏好哪種認證方法?(OAuth、JWT、還是傳統的 session?)
  • 要支援哪些登入服務商?(Google、GitHub、email+密碼?)
  • 需要角色式存取控制嗎?
  • session 逾時後要發生什麼?

每個問題都附帶合理的選項和說明,就像在進行一場真實的技術討論。這個過程有個正式的名字,叫做「規格導向開發」(spec-based development)。

三步驟:問、寫、執行

AskUserQuestion 的最佳使用方式分三個階段:

第一步:面試階段

您只需要給 Claude 一個簡單的指令:「幫我建置使用者認證系統,先問我問題好嗎?」

Claude 就會開始提問。每一個問題都精準針對您的代碼庫,給您有意義的選項。

第二步:規格階段

經過一輪問答後,Claude 會產出一份詳細的規格文件。這份文件清楚列出要建置什麼、怎麼建置,一點都不模糊。

第三步:執行階段

有了規格在手,您就可以開始新的開發會話,把規格當作背景資訊。這次 Claude 執行起來精準無誤,因為所有的歧義都已經在一開始就解決了。

不騙您,就是這麼簡單。

Linear 整合:把 AI 變成團隊同事

事情變得更有趣的地方,是 Cyrus(一個整合 Claude 的開發工具)跟 Linear 的配合。

假設 Cyrus 在處理一個 Linear 工單,發現有不清楚的地方。它不會亂猜,也不會停滯,而是直接在 Linear 裡問您問題。您可以在 Linear 的活動區段看到 Cyrus 把工單標記為「需要輸入」,然後丟出問題,並提供清晰的選項讓您選擇。

您甚至不用切換視窗,直接在 Linear 裡點一個選項回應就行。這種異步協作方式超級適合遠端團隊:

  • 異步開發:Cyrus 在您開會時繼續工作,有問題時自己提出來
  • 背景資訊保留:問題和答案都成為工單歷史的一部分
  • 團隊能見度:所有人都看得見決策過程
  • 不打斷工作流:回答問題時不用離開 Linear

為什麼這件事重要

2026 年了,AI 的能力已經不是問題。真正的問題是:AI 有沒有弄懂我想要什麼?

當 Claude 問您「這個 API 應該快速失敗還是自動重試?」時,有個很微妙的轉變發生了。設計上的權衡變得顯而易見。不是在代碼審查時才發現埋藏的假設,而是在便宜的階段——決策剛做出來的時候——就把問題談清楚。

這就像是在玩「選擇你的冒險故事」。每個問題都是一個岔路口。每個答案都讓解決方案的空間變窄一點。到了 Claude 真正開始寫程式時,您們已經一起走過了整個決策樹,還有清楚的紀錄可以回顧每個選擇。

結語

AI 不是要搶您的工作。聰明的開發者已經發現,最有威力的不是 AI,而是懂得怎麼跟 AI 合作的人。

AskUserQuestion 功能就是這種合作的模板。下次當您要用 AI 寫程式時,與其期待它讀心術,不如主動告訴它:「先問我吧。」

結果可能會讓您驚訝。

順利考上 IPAS AI 應用規劃師中級考試!我的高效率備考心法公開

 🎧📚 昨天分享了自己 3 天認真衝刺考上 IPAS AI 中級 的喜悅後,很多人私訊問:「到底怎麼準備的?」
這篇就來完整整理我從 0 到上榜的全流程,讓你照著做也能事半功倍!🔥


🔗 1. 先掌握官方資源

官方網站 👉 https://www.ipas.org.tw/AIAP/
在 培訓資源 裡可以下載「學習指引」:
https://www.ipas.org.tw/AIAP/AbilityPageContent.aspx?pgeno=263534ef-6ab9-4ce9-a9be-4ad9a4ed7440

這份指引就是整個考試的地圖,一定要先看!


🧠 2. 用 notebookLM 建心智圖,快速掌握考試範圍

因為工作忙碌,我大多只有每天晚上 9 點回家後能專心看書。
為了快速理解內容,我會:

  1. 把學習指引上傳到 Google NotebookLM

  2. 讓它自動產生「心智圖」

  3. 先掌握全貌(面)再深入每個章節(線)


🎧 3. 用語音摘要 & AI Studio 做「可聽的筆記」

NotebookLM 的語音摘要很好用!但後來我找到更強的做法:

🎤 Google AI Studio – Generate Speech
👉 https://aistudio.google.com/generate-speech

只要在 NotebookLM 勾選要整理的檔案,並輸入這段指令:

依據內容產生 50 個重點並整理成簡單有趣的問答對話,格式如下:
Speaker 1 您好
Speaker 2 您好!有什麼事嗎?

以純文字方式輸出即可。

就能生成清楚好懂的語音檔,效果媲美語音摘要!


🚇 4. 通勤時間變黃金:我的「聲音筆記學習法」

把這些整理好的語音當作通勤時的「AI 教學 Podcast」。
不懂的地方就隨手記下來,之後再集中複習——
碎片時間瞬間變成高效學習時間!


📚 5. 延伸補充:推薦 ccchen 老師的內容

更多補充資料可以看這邊:
https://vocus.cc/salon/678ac6e5fd89780001eb761c/room/CCCHENAIPP01


💡 這就是我自己的一套「AI 輔助讀書法」

如果你也在準備 IPAS,或對 AI 工具學習法有興趣,歡迎追蹤我,一起交流成長!🚀