這種轉變細微但深刻，所以這次我們把它寫成了一整個新章節。今天想跟你聊聊「AI 提示詞寶典」v2.0，以及裡面這個我醞釀很久的主題：Vibe Coding 與 AI 編碼代理。

什麼是 vibe coding？​

先把名詞講清楚，免得我們各說各話。

「Vibe coding」這個詞是 Andrej Karpathy 在 2025 年 2 月提出的。它描述的是一種放鬆、跟著感覺走的開發狀態：你把意圖丟給 LLM，看它跑出什麼，覺得對味就留下，不對味就再叫它改一輪。

但 vibe 歸 vibe，真正讓我覺得這個概念有重量的，是 Simon Willison 給的那個比較嚴格的定義：vibe coding 是用 LLM 來開發，但不去審查它寫的程式碼。注意這個「不審查」：這是重點，也是界線。

所以 vibe coding 到底適不適合用？我的答案是：看場合。

• 拿來做原型、探索想法、週末玩個小工具？太適合了，速度快得會讓你上癮。
• 拿去跑正式上線、要對使用者負責的系統？那就要非常小心了。沒看過的程式碼直接上 production，這不是 vibe，是賭。

換句話說，vibe coding 是一種模式，不是一種紀律。它解放了你的探索力，但它本身不保證品質。

比工具更大的轉變：從 prompt 到 context​

如果你跟我一樣，前兩年都在練 prompt engineering，那你可能也感覺到了：光「會寫 prompt」已經不夠了。

現在真正的功夫，往兩個方向長出去：

• Context engineering（情境工程）：與其雕一句完美的 prompt，不如好好經營 agent 能看到的整個「情境」。它讀得到哪些檔案？知不知道你的專案慣例？有沒有一份說明它該怎麼做事的文件？這些加起來，比任何一句巧妙的措辭都重要。
• Spec-driven development（規格驅動開發）：先把「要做什麼」寫成清楚的規格，再讓 agent 照著規格去實作。規格成了人和 agent 之間的合約。

我自己會用一句話來幫朋友理清這三者的關係：用 vibe coding 探索、用規格驅動交付、用 agentic engineering 當那把專業的大傘。 探索時你可以放飛；交付時你要有合約；而把整件事做得專業、可重複、可信賴，那就是 agentic engineering 要罩住的範圍。

新章節帶你走一遍​

這次的 Vibe Coding 章節我拆成 7 篇，盡量做到「看完就能上手，而且知道為什麼這樣做」。我簡單帶你過一遍：

• 總覽：先把整張地圖攤開，搞清楚 vibe coding、context engineering、spec-driven development、agentic engineering 各自站在哪、彼此怎麼接。
• Claude Code 實戰指南：怎麼把 Claude Code 當成日常的編碼夥伴，從第一次對話到讓它跑完整個任務。
• OpenAI Codex 實戰指南：另一條主流路線。你會發現很多觀念是共通的，差別在使用手感與工作流。
• Context Engineering：CLAUDE.md 與 AGENTS.md：這篇是我私心最推的。怎麼用一份 CLAUDE.md 或 AGENTS.md 把你的專案慣例、邊界、地雷一次交代給 agent，讓它「懂你的專案」。
• Agentic 工作流程：把 agent 接進真實的開發循環（讀、改、跑、驗證、再來一輪），而不是一次性的一問一答。
• 規格驅動開發：把規格當成第一公民，讓「要做什麼」先於「怎麼做」。
• 驗證、安全與工程紀律：這篇是整個章節的安全帶。agent 能跑指令、能改檔案，那要怎麼確保它不會把事情搞砸？

如果你想先暖身，也可以先回去翻翻舊的 程式碼生成教學，再接著讀新章節，銜接會更順。

我真正想說的：工具再強，紀律才是分水嶺​

寫到這裡，才要講這篇文章的核心，也是整個 v2.0 我最想傳達的一句話。

我用過很猛的 agent，也看過很多人被它的速度沖昏頭。但我越用越確定一件事：工具再強，真正拉開差距的，還是那些老派到不行的工程紀律。

具體是哪些？我列幾個我每天都在用的：

• TDD（測試驅動開發）：先寫一個「會失敗的測試」，把它當成 agent 的驗證關卡。agent 改完程式碼，測試由紅轉綠，你才知道它真的做對了，而不是它「看起來」做對了。這比你瞪著程式碼猜有沒有 bug 可靠太多。
• Small CLs（小而聚焦的變更）：一次只改一件事。別讓 agent 一口氣翻動三十個檔案：那種 diff 沒人 review 得動，出事也找不到兇手。小變更，好讀、好驗、好回滾。
• Boy Scout Rule（童子軍原則）：離開營地時，讓它比你來的時候更乾淨一點。你或 agent 動到哪個檔案，就順手讓那個檔案乾淨一點點。日積月累，整個專案的健康度就守住了。
• 避開 LLM 最愛的兩個壞習慣：一是過度生成：它很愛多寫一堆你沒要的功能、沒要的設定、沒要的「貼心」抽象層；二是過早抽象：明明還沒看清需求，它就急著幫你包一層通用框架。這兩件事不擋下來，程式碼會以驚人的速度長出脂肪。

你發現了嗎？這些原則，沒有一條是 2025 年才發明的。TDD、小變更、童子軍原則，在 agent 出現之前就是好工程師的內功。v2.0 真正想說的是：把這些紀律套到 agent 身上。 agent 改變了「誰來打字」，但它沒有、也不該改變「什麼叫做好的工程」。誰能把老紀律穩穩地架在新工具上，誰就能真正吃到這波紅利，而不是被它反噬。

最後​

如果你只從這篇帶走一句話，我希望是這個：讓 agent 跑得快，讓紀律守得住。 速度交給工具，品質交給你自己。

去讀讀新章節吧。我寫的時候，一直想著當年那個「技能樹亂點」的自己（從醫學、電機資訊一路晃到戲劇）。我越來越相信，寫程式跟跨領域學習其實是同一件事：工具會一直換，真正帶得走的，是那套你願意一遍遍打磨的判斷力與紀律。

這份寶典是開源的，它也是被許多人一起讀、一起改、一起變好的。歡迎你來踩、來挑錯、來貢獻：我們在這條從 prompt 到 agent 的路上，一起走。

作者簡介：蔡秀吉，清大電機資訊學院學生，開源社群參與者。興趣橫跨資訊工程、神經科學、心理學、本土語言到戲劇表演。相信跨領域思維與工程紀律，是 AI 時代裡最值得長期投資的兩件事。

為什麼 Prompt Engineering 需要跨領域視角？​

在清大電機資訊學院的學習，讓我理解技術的深度；在政大學習捷克語，讓我體會語言的細膩；而對戲劇的興趣，則讓我明白如何「導演」一場人機對話。

Prompt Engineering 恰恰需要這三者的結合：

• 技術理解：知道 AI 模型的能力邊界
• 語言敏感：精準表達意圖
• 創意思維：設計有效的互動模式

教學框架：CLEAR 方法論​

基於教學經驗，我整理出 CLEAR 框架來教授 prompt engineering：

C - Context（情境設定）​

# 不好的 prompt
"寫一篇文章"

# 好的 prompt - 提供充分情境
"""
你是一位科技記者，正在為《科學人》雜誌撰寫專欄。
讀者群體是對科技有興趣但非專業背景的大眾。
請以淺顯易懂的方式，解釋量子計算的基本概念。
文章長度約 800 字，需要包含一個生活化的比喻。
"""

L - Language（語言精準）​

不同語言背景影響 prompt 效果。我的多語言學習經驗讓我發現：

# 英文 prompt（較直接）
"Analyze the data and provide insights"

# 中文 prompt（較婉轉）
"請協助分析這份數據，並提供您的見解"

# 混合使用（技術詞彙保留英文）
"請分析這個 dataset，找出關鍵的 patterns 和 insights"

E - Examples（範例學習）​

def create_few_shot_prompt(task, examples):
    """
    透過範例教導 AI 期望的輸出格式
    """
    prompt = f"任務：{task}\n\n"
    prompt += "範例：\n"
    
    for i, example in enumerate(examples, 1):
        prompt += f"輸入 {i}: {example['input']}\n"
        prompt += f"輸出 {i}: {example['output']}\n\n"
    
    return prompt

A - Audience（受眾考量）​

根據不同受眾調整 prompt：

audience_prompts = {
    "小學生": "用小朋友能懂的方式，像說故事一樣解釋",
    "專業人士": "使用專業術語，提供技術細節和引用來源",
    "決策者": "重點放在商業影響和 ROI，提供執行摘要"
}

R - Refinement（迭代優化）​

class PromptRefiner:
    def __init__(self):
        self.history = []
    
    def refine(self, prompt, feedback):
        """
        基於反饋迭代改進 prompt
        """
        self.history.append({
            'prompt': prompt,
            'feedback': feedback,
            'timestamp': datetime.now()
        })
        
        # 分析哪些部分需要改進
        improvements = self.analyze_feedback(feedback)
        
        # 生成改進版本
        refined_prompt = self.apply_improvements(prompt, improvements)
        
        return refined_prompt

實踐案例：跨領域應用​

1. 醫學 + AI：症狀分析助手​

結合醫學背景，設計醫療諮詢 prompt：

medical_prompt = """
注意：這只是教育示範，不能替代專業醫療建議。

作為醫學知識助手，請分析以下症狀：
- 症狀描述：{symptoms}
- 持續時間：{duration}
- 年齡性別：{demographics}

請提供：
1. 可能的鑑別診斷（按可能性排序）
2. 建議的檢查項目
3. 何時應該就醫的警訊

輸出格式：使用易懂的語言，避免造成恐慌。
"""

2. 戲劇 + AI：劇本創作​

運用戲劇知識，引導 AI 創作：

drama_prompt = """
你是一位劇作家，請創作一個短劇場景：

【設定】
- 地點：深夜的便利商店
- 角色：店員 A（20歲大學生）、顧客 B（50歲上班族）
- 衝突點：兩人對「成功」的定義完全不同

【要求】
- 對話要展現角色性格
- 包含一個轉折點
- 結尾保持開放性

請用劇本格式撰寫（包含舞台指示）。
"""

3. 教育 + AI：個人化學習​

def create_adaptive_learning_prompt(student_profile):
    """
    根據學生特質生成個人化學習內容
    """
    prompt = f"""
    學生檔案：
    - 學習風格：{student_profile['learning_style']}
    - 先備知識：{student_profile['prior_knowledge']}
    - 興趣領域：{student_profile['interests']}
    
    請為這位學生設計一個關於「{student_profile['topic']}」的學習活動。
    
    要求：
    1. 連結到學生的興趣領域
    2. 符合其學習風格
    3. 從已知概念出發，逐步深入
    4. 包含互動元素
    """
    return prompt

開源精神：共享與協作​

作為開源社群的參與者，我相信知識應該自由流通。以下是一些開源的 prompt engineering 資源：

我的開源貢獻​

• GitHub 專案：各種 prompt 模板和工具
• HackMD 筆記：技術文件和教學材料
• COSCUP 分享：議程規劃和社群交流

推薦的學習資源​

learning_resources:
  基礎:
    - Prompt Engineering Guide (開源)
    - OpenAI Cookbook
    - Anthropic 的 Prompt 設計文檔
  
  進階:
    - LangChain 文檔
    - Few-shot Learning 論文
    - Chain-of-Thought Prompting 研究
  
  實作:
    - Hugging Face 課程
    - Google Colab 範例
    - Local LLM 實驗（Ollama）

給初學者的建議​

1. 從模仿開始：收集好的 prompt，理解其結構
2. 大量實驗：同一個任務嘗試不同表達方式
3. 記錄和反思：建立自己的 prompt 庫
4. 跨領域思考：將其他領域的知識帶入
5. 參與社群：開源協作，互相學習

展望未來：AI 時代的必備素養​

Prompt Engineering 不該只是程式設計師的專利，而應該變成每個人都要有的基本技能。就像我們以前教小朋友怎麼用 Google 搜尋，現在我們需要教的是：

• 跟 AI 溝通的藝術：怎麼讓 AI 懂你在說什麼
• 批判思考：不要全信 AI 的答案，要會判斷對錯
• 負責任使用：不要什麼都交給 AI，要知道界線在哪裡
• 保護隱私安全：不要把個資或公司機密交給 AI 處理

結語​

Prompt Engineering 是技術與人文的交會點。它需要我們既理解機器的語言，也不忘人類溝通的藝術。

正如我的跨領域學習之旅，每個人都可以從自己的背景出發，為這個領域帶來獨特的視角。無論你是工程師、教育者、醫療人員還是藝術家，都能在 prompt engineering 中找到發揮的空間。

期待在 COSCUP 2025 與大家分享更多想法，一起探索 AI 時代的溝通藝術！

作者簡介：蔡秀吉，清大電機資訊學院學生，COSCUP 2025 O-RAN in B5G/6G 議程軌籌辦人。興趣橫跨資訊工程、神經科學、心理學、精神醫學、偏鄉教育、本土語言到戲劇表演。相信跨領域思維是創新的關鍵。

聯繫方式：個人網站 | GitHub | Email: hctsai1006@cs.nctu.edu.tw

台灣電信業的 AI 轉型挑戰​

像中華電信、台灣大哥大、遠傳這些電信三雄，每天都在處理超大量的資料，但這些資料有個毛病：

• 技術門檻超高：滿滿的專業術語跟英文縮寫，連工程師都會頭痛
• 資料來源很雜：Nokia、Ericsson、華為等不同廠商的設備，資料格式都不一樣
• 時效性要求嚴苛：網路一當機，客戶立刻打爆客服電話

這時候 LLM 跟 prompt engineering 就派上用場了！

實際應用案例​

1. 智慧網路故障診斷​

以前網路出問題，工程師要看一大堆 log 跟告警訊息，眼睛都花了。現在用 LLM，情況大不同：

# 故障診斷 prompt 範例 - 以中華電信基地台為例
fault_diagnosis_prompt = """
幫忙分析一下這個網路告警，找出可能的問題根源：

告警資訊：
- 時間: 2025-02-20 下午 2:30
- 設備: 中華電信_台北101基地台_001
- 告警類型: S1 連線中斷
- 影響用戶數: 1,234 人（主要是信義區商辦用戶）

相關系統 log：
[LOG] SCTP association failed (協定連線失敗)
[LOG] Retransmission timeout exceeded (重傳逾時)
[LOG] MME unreachable (行動管理實體無法連線)

請提供：
1. 最可能的問題原因（按機率排序）
2. 建議的檢查步驟
3. 預防措施建議
"""

2. 自動化設備配置生成​

網路設備的設定檔超複雜，一個不小心就會搞砸。透過設計巧妙的 prompts，LLM 能幫忙生成正確的配置：

# Prompt 模板：幫台灣大哥大生成 5G 網路切片配置
prompt_template: |
  請幫忙產生台灣大哥大 5G 網路切片的配置檔：
  
  服務類型: {service_type} (例如：高速上網、遊戲、工業物聯網)
  延遲要求: {latency_requirement} (毫秒)
  頻寬需求: {bandwidth} (Mbps)
  可靠性等級: {reliability} (99.9% 或更高)
  部署區域: 台北、新北、桃園都會區
  
  請產生符合 3GPP 標準的 YAML 配置檔，並加上中文註解說明。

3. 技術文件智慧檢索​

電信標準文件多到爆炸（3GPP、O-RAN、ETSI...），工程師要找個資料得翻半天。現在有了 RAG 技術：

def create_rag_prompt(question, context_docs):
    """
    建立 RAG (檢索增強生成) prompt
    專門用來回答技術文件問題
    """
    prompt = f"""
    根據以下的技術規格文件，幫忙回答問題：
    
    文件內容：
    {context_docs}
    
    問題：{question}
    
    請提供：
    1. 準確的技術答案
    2. 引用的文件來源
    3. 如果可能的話，舉個台灣電信業的實際應用例子
    """
    return prompt

台灣電信業 Prompt Engineering 最佳實踐​

在咱們台灣電信業用 LLM 的時候，我整理出這幾個超重要的 prompt 設計撇步：

1. 灌入台灣電信領域知識​

# 專門為台灣電信業設計的 system prompt
system_prompt = """
你是一位在台灣電信業打滾多年的資深工程師，具備以下專業：
- 熟悉 3GPP 標準（R15-R18）
- 了解 O-RAN 開放架構
- 精通 5G 核心網路跟無線接取網路
- 熟知台灣電信三雄的網路架構
- 掌握各種網路 KPI 指標跟優化策略
- 了解台灣特有的地形跟都市環境對訊號的影響

請用專業但親切的台灣口吻回答問題，必要時舉台灣的實際案例。
"""

2. 結構化故障報告輸出​

# 要求結構化的故障報告 - 台灣電信業適用格式
structured_prompt = """
請分析這個網路問題，用以下格式整理報告：

## 狀況摘要
[用一句話說明發生什麼事]

## 影響範圍
- 受影響的服務：（例如：4G 上網、語音通話、簡訊）
- 受影響用戶數：（預估人數）
- 影響區域：（例如：台北市信義區、新北市板橋區）
- 嚴重程度：（緊急/高/中/低）

## 問題分析
1. 表面現象：（用戶反應什麼）
2. 技術層面：（系統哪裡出包）
3. 根本原因：（為什麼會發生）

## 處理方案
- 緊急應變：（立刻要做的事）
- 長期改善：（預防再次發生的措施）
- 預估修復時間：
"""

3. 透過範例教學 (Few-shot Learning)​

給 LLM 看幾個台灣電信業的實際案例，讓它更懂我們的作業模式：

few_shot_examples = [
    {
        "input": "台北 101 基地台 PRB 使用率飆到 95%",
        "output": "建議處理：1) 開啟載波聚合功能 2) 評估是否需要增加頻譜資源 3) 調整排程演算法分散負載 4) 考慮在附近增設小基站"
    },
    {
        "input": "板橋車站附近切換成功率掉到 85%",
        "output": "排查重點：1) 檢查鄰近基地台的參數設定 2) 調整切換門檻值 3) 確認基地台間的 X2 介面連線正常 4) 考慮人潮聚集導致的訊號干擾"
    },
    {
        "input": "颱風天遠傳基地台大量斷線",
        "output": "緊急應變：1) 啟動行動基地台 2) 調整鄰近基地台功率覆蓋 3) 通知客服準備說明 4) 聯繫搶修團隊優先修復主要幹道基地台"
    }
]

好用的開源工具推薦​

我在研究 LLM + 電信應用的過程中，發現這些開源工具超實用：

• OpenAI Whisper：把客戶語音轉成文字，客服中心必備
• LangChain：打造 LLM 應用的瑞士刀，功能齊全
• Ollama：在公司內部跑 LLM，資料不外洩更安心
• ChromaDB：向量資料庫，拿來搜尋技術文件超好用
• Streamlit：快速做出 demo 介面，老闆看了都說讚

未來展望：台灣電信業的 AI 革命​

隨著 6G 研究持續推進，加上 AI-Native 網路概念越來越夯，LLM 在台灣電信業會變得更重要：

1. 白話文操控網路：直接跟系統說「幫我優化台北市的 5G 覆蓋」，系統自動調整參數
2. 數位雙胞胎網路：在虛擬環境裡用 LLM 模擬各種狀況，預先找出最佳解決方案
3. 全自動網管：結合 LLM 跟機器學習，讓網路真正做到「自己會修自己」
4. 台灣在地化應用：考量台灣獨特的地形、氣候跟用戶習慣，客製化 AI 解決方案

結語​

LLM 跟 prompt engineering 真的為台灣電信業開啟了新的可能性！從讓日常維運變輕鬆，到打造真正聰明的網路系統，這些技術正在翻轉我們經營通訊網路的方式。

身為一個對 AI 跟電信技術都有熱忱的學生，我深信這個跨領域結合會有超多機會。很期待在 COSCUP 2025 跟大家深度交流這些話題，一起腦力激盪！

如果你也對這些技術有興趣，不管是在中華電信、台灣大哥大、遠傳工作，還是在台大、清大、交大、成大念相關科系，都歡迎來聊聊！

本文作者目前就讀於國立清華大學電機資訊學院，同時擔任 COSCUP 2025 O-RAN in B5G/6G 議程軌的籌辦人。歡迎對 AI、電信技術有興趣的朋友一起交流討論，讓台灣在這波技術浪潮中站穩腳步！

O-RAN 的開放精神​

Open RAN（O-RAN）不只是技術規範而已，它代表著整個電信產業的典範轉移。透過開放介面和標準化，我們打破了傳統電信設備的封閉生態系統，為創新開啟超多新的可能性！

為什麼 O-RAN 對台灣超重要？​

1. 打破廠商鎖定：透過標準化介面，中華電信、台灣大哥大這些營運商可以自由選擇不同廠商的設備
2. 促進本土創新：開放架構讓台灣的新創公司和研究機構（像是工研院、資策會）都能參與進來
3. 降低營運成本：競爭和標準化帶來的成本優勢，對台灣這種市場規模的國家特別重要
4. 加速 5G 部署：雲原生架構支援快速迭代和部署，讓台灣能跟上國際腳步

AI 在 RAN 中的實際應用​

AI/ML 技術正在改變我們管理和優化網路的方式，這在台灣的應用場景特別明顯：

即時網路優化 - 台灣案例​

# 範例：使用 AI 進行動態資源分配（台北捷運場景）
def optimize_ran_resources_taipei_mrt(network_data):
    """
    AI 驅動的 RAN 資源優化 - 針對台北捷運尖峰時段
    """
    # 收集網路指標（例如：忠孝復興站的流量）
    metrics = collect_network_metrics(network_data)
    
    # AI 模型預測通勤流量模式
    traffic_prediction = ml_model.predict(
        metrics,
        context="taipei_mrt_rush_hour"
    )
    
    # 動態調整資源配置（考慮台灣用戶習慣）
    optimization_plan = generate_optimization_plan(
        current_state=metrics,
        predicted_traffic=traffic_prediction,
        local_patterns="taiwan_mobile_usage"
    )
    
    return optimization_plan

智慧節能 - 響應台灣能源政策​

在台灣推動綠能和節能減碳的政策下，AI-RAN 的節能功能變得格外重要：

• 離峰時段智慧休眠：深夜時段自動降低基站功耗
• 動態功率調整：根據即時流量需求調整發射功率
• 預測性維護：減少不必要的現場維護，降低碳足跡

台灣在 O-RAN 生態系的機會​

硬體製造優勢​

台灣的 ICT 產業鏈完整，從晶片設計到系統整合都有世界級的能力。像是聯發科、廣達、緯創等公司，都已經積極投入 O-RAN 設備的開發。

軟體創新潛力​

台灣 O-RAN 軟體創新重點領域:
  - RIC (RAN Intelligent Controller) 應用開發
  - xApp/rApp 智慧應用
  - 網路切片管理平台
  - AI/ML 模型訓練平台

場域驗證優勢​

• 5G 專網實驗場域：亞灣 5G AIoT 創新園區
• 智慧工廠應用：台積電、鴻海等大廠的專網需求
• 智慧城市場景：台北、桃園、台中的智慧城市計畫

LLM 在電信網路管理的應用​

大型語言模型（LLM）正在改變網路維運的方式：

智慧故障診斷​

# 使用 LLM 進行網路故障分析
def diagnose_network_issue_with_llm(alarm_data, log_data):
    prompt = f"""
    分析以下台灣電信網路的告警和日誌資料：
    
    告警資訊：{alarm_data}
    系統日誌：{log_data}
    
    請提供：
    1. 可能的根本原因（Root Cause）
    2. 建議的解決方案
    3. 預防措施
    
    考慮台灣特殊環境因素（颱風、地震等）
    """
    
    diagnosis = llm_model.generate(prompt)
    return diagnosis

自然語言網路配置​

營運人員可以用中文自然語言下達指令：

• "幫我優化信義區的 5G 網路覆蓋"
• "調整台北 101 跨年活動的網路容量"
• "分析昨天高雄的網路異常原因"

COSCUP 2025 O-RAN 議程軌預告​

今年 COSCUP 的 O-RAN 議程軌，我們將聚焦在：

1. 實戰經驗分享：台灣電信業者的 O-RAN 部署案例
2. 開源專案展示：O-RAN 相關的開源軟體和工具
3. 產學合作成果：清大、交大、台大的最新研究
4. 新創公司 Demo：台灣 O-RAN 新創的創新解決方案

未來展望：6G 與 AI 的深度融合​

展望 2030 年的 6G 時代，AI 將不只是網路的優化工具，而是網路的核心組成部分：

• AI 原生架構：從設計開始就考慮 AI 的網路架構
• 感知通信一體化：結合感測和通信功能
• 數位孿生網路：完整的網路數位分身
• 自主網路：真正的零接觸自動化營運

結語​

O-RAN 和 AI-RAN 的發展，為台灣的電信產業帶來前所未有的機會。憑藉我們在硬體製造、軟體開發和系統整合的優勢，台灣絕對有機會在全球 O-RAN 生態系中扮演關鍵角色。

歡迎大家來 COSCUP 2025 參加 O-RAN 議程軌，一起探討台灣在下世代通信技術的發展機會！

作者簡介：蔡秀吉（thc1006），國立清華大學電機工程與資訊科學雙主修，COSCUP 2025 O-RAN in B5G/6G Track Organizer，專注於將 AI 技術應用在下世代通信網路。