WordPress視覺排版設計超入門：CSS與HTML
104學習
HTML
是用來建立網頁結構的標記語言，負責定義文字、圖片、連結等內容的排列和呈現方式。掌握這項技能能讓你理解網站如何運作，並能與前端設計師或工程師有效溝通。對於從事網頁設計、前端開發或數位行銷相關工作的人來說，是基本且必備的技能，有助於提升職場競爭力。
提升你的實力，朝專業更進一步
精選課程
充實自己，讓能力持續成長
成為前端工程師｜透過 HTML 與 CSS 認識網頁設計，從 0 到 1 打造實用介面 (上集)
成為前端工程師｜透過 HTML 與 CSS 認識網頁設計，從 0 到 1 打造實用介面 (下集)
成為前端工程師｜jQuery 入門密技，愉快打造互動式網頁不求人
JSP + Servlet | 吳永志Java Web 技術開發
C# 從零開始前進.NET物件導向程式全攻略
智能文件編輯：AI和Word的整合
WordPress新手架站10堂課
Python Crawler AI爬蟲與自動化實戰：新手入門到精通！打造你的數據助手！
工程師救星-用Bootstrap速成響應式網頁開發
精選證照
考取專業證照，讓能力被市場看見
ITS HTML and CSS 程式語言核心能力
Information Technology Specialist（IT 資訊科技專家認證），簡稱 ITS，是Pearson VUE／Certiport 推出符合產業趨勢的初階資訊科技認證，涵蓋 IT 資訊技術、資料庫、軟體研發、新興科技四大領域，共十三個科目，透過 IT 資訊科技專家訓練課程，可驗證考生是否具備雇主所需的 IT 技能，幫助考生為未來職涯做好準備。
即使是國際性的專業認證、英文證書，但是在試題上可以自由選擇語系，因此，在國內的 ITS 認證考試亦提供有正體中文化試題，只要通過 Certiport 的認證考試，即頒發全球通用的國際性證書。
IT 資訊科技專家課程的目標對象為正在考慮或剛剛開始踏上資訊科技職涯的人士。考生能夠驗證他們在各個 IT 領域中的知識，其中包含軟體開發、資料庫管理、網路與安全、行動與裝置管理、程式開發、編程與代碼、雲端運算以及人工智慧。
Certiport
SSE HTML5國際認證
網頁設計的工具有許多，但是最基礎也是最重要的是HTML語言，特別是對於資訊科技的學生或網頁設計師，當了解HTML語言後，你可以全盤了解網頁畫面的設計方法以及徹底了結網頁結構的精神與意義，更進一步你也可以了解應如何設計一個可以讓搜尋引擎搜尋到，以及增加瀏覽率的網頁。通過本測驗，可得到HTML5認證書，代表你已擁有設計及修改HTML文件的能力。
Silicon Stone Education (SSE)
SSE CSS3國際認證
CSS3是設計網頁的重要技術，和HTML搭配使用，基本上是HTML5的延伸，在W3C官方組織中，基本上將網頁的文件內容設計與外觀設計分開，CSS3重點是處理網頁的外觀設計，特別是應用在大型網站。通過本測驗，可得到CSS3認證書，代表你已擁有設計及瀏覽別人所設計大型網站HTML5+CSS3文件的能力。
Silicon Stone Education (SSE)
Adobe Certified Dreamweaver Developer
Adobe Certified Dreamweaver Developer認證為Adobe所發之國際認證，針對多媒體網頁設計之核心應用能力，所規劃的認證項目。其協助網頁工作者，能有效使用Dreamweaver 軟體進行創作展現實力。
Adobe
MCSD for .NET
MCSD for .NET 證照代表具備使用微軟.NET技術進行應用程式開發的專業能力，涵蓋前端與後端設計、Web服務及資料庫整合等技能，適合軟體工程師與系統開發人員提升職場競爭力。持有此證照表示熟悉Visual Studio開發環境，能運用C#、ASP.NET等技術完成企業級應用，符合現代軟體開發需求。
尚未查核發照單位
SSE C程式語言國際認證
C語言已經是目前欲進入資訊科技殿堂最重要的程式語言，也是最好找工作的程式語言，目前大部分的半導體，工業工程，無人車，虛擬實境和手機開發等和硬體相關的開發都是使用C語言完成。掌握C語言是軟體工程師最重要的技能。讓你在各個不同領域都能得心應手完成困難的工作。通過我們的認證，你將證明自己具備高人一等的C語言開發能力。
Silicon Stone Education (SSE)
精選貼文，掌握第一手知識
軟體業Technical Writer工作在做什麼？技術文件為何不是由PM寫？
軟體產業的Technical Writer工作在做什麼？和PM產品經理工作有什麼差異？Technical Writer職位結合「內容寫作」和「技術寫作」的專業，可以將硬梆梆的技術內容、轉換成一般使用者也能好理解的技術＋商業內容。本文作者以自身經驗分享，解答包括Technical Writer工作內容及為什麼不由PM來寫技術文件。
文／朱麒
本文目錄（點擊可快速前往）
1. Technical Writer到底要幹嘛？2. 為什麼需要Technical Writer？3. 為什麼不由PM來寫技術文件？
我曾經擔任PM將近6年的時間、在新職位—Technical Writer工作也已經快9個月的時間，這篇文章想分享關於「寫文件」這件事情。
一開始有許多朋友和我討論說「為什麼不交給PM做就好？」在親身體驗與想過之後，我發現這兩者的定位與價值是完全不同的。這篇文章分享Technical Writer在做些什麼，以及簡單比較跟「產品經理（Product Manager）」的差異。
如果你對軟體產業有興趣、正在當PM的人、或是潛在想當Technical Writer的人看（有這樣的朋友嗎），一起來看看這篇文章吧。
備註：請留意此篇文章的脈絡都是以「軟體開發」的角度來談。
1. Technical Writer到底要幹嘛？
簡單說，就是替公司的產品寫一份「攻略本」。
攻略本是電玩產業的詞，能幫助新手玩家快速學會操作方法、了解遊戲目標，接著就可以比較開心的在遊戲的世界中玩耍。
而「技術寫作（Technical Writing）」就是替公司的產品寫使用文件，用來引導消費者更好地使用公司產品。技術寫作也可以視為公司品牌、產品使用體驗的一環，能影響消費者對於公司產品的整體觀感。
這就像「攻略本」會先告訴新手玩家基本的操作方法，讓玩家在別在超大的遊戲世界中不知所措的亂跑、被怪打死而感到挫折（可能一開始連「基礎戰鬥知識」都沒有就跑出新手村）。
好的技術文件，應該能夠把公司產品複雜的功能與規格，在適當的時間點、用適當的方式告訴使用者。
2. 為什麼需要Technical Writer？
對呀，為什麼不由最熟悉產品功能與規格的程式開發者或產品經理，來寫技術文件就好了呢？
先從「軟體開發者」的角度來說。由於技術文件（例如API Documentation）是技術含量相當高的文件，最好的寫作者當然是由開發者來寫。
然而多數的開發者在寫文件的時候，容易從非常技術的角度撰寫文件—多數狀況是「只解釋程式功能，但不解釋程式對於使用者的目的」。由於程式往往有自己的商業邏輯（例如建立訂單的流程、訂單對帳與請款的方式），使用者在不清楚商業邏輯的前提下直接閱讀，往往一頭霧水。
因此Technical Writier誕生了，這個職位結合「內容寫作（Content writing）」和「技術寫作（Technical Writing）」的專業，可以將硬梆梆的技術內容、轉換成一般使用者也能好理解的技術＋商業內容。
Technical writer像是一位翻譯員，要把「技術」國家的語言翻譯給「商業」國家的人理解。
3. 為什麼不由PM來寫技術文件？
行行好，放過PM吧！
PM的工作包山包海，要跟業務單位／客戶對需求、花時間整理規格、跟設計師／工程師／QA／營運團隊溝通。
PM職責範圍確實也包含寫產品的規格與規劃，例如：
使用者故事（User Story）： 即 As a（使用者）, I want（做什麼事情）, so that（得到什麼成果），讓產品團隊理解每個功能為誰而做、要做什麼、做完成果。
User Story Acceptance Criteria Test Cases：寫完User Story後，必須要進一步描述這個功能的細節，透過「Given（在什麼情況下），When（當使用者做了什麼），Then（會發生什麼事情）」才能讓工程師與QA（測試工程師）執行。
Product Roadmap：告訴C字輩的老闆接下來的產品發展，這一季要做什麼、為什麼要做、要打哪些用戶、如何衡量成效、成效好與不好的相對應措施是什麼。
可以看到，PM的寫作文件通常是「對內」，告訴團隊接下來要做些什麼、不做些什麼；但Technical Writer通常是「對外（外部使用者）」，告訴使用者產品從哪裡開始用、要完成對應的事情該怎麼做、技術細節要到哪裡去查……等。
PM和Technical Writer的技能樹不同，前者更多在溝通、後者更多在引導。更多文章分享，可至「朱騏部落格」閱讀。
（原文標題：軟體產業中的 Technical Writer 在做些什麼，為什麼「寫文件」這件事情不都交給 PM 做就好？）
[joblist_plugin title='更多104【Technical Writer】工作機會' url='https://www.104.com.tw/jobs/search/?keyword=Technical%20Writer' amount='4']
精選 Claude 該選 Haiku、Sonnet、Opus 還是 Fable？三個問題選對模型，額度用更久
同一個問題丟給 Claude，有時又快又好，有時卻等很久、還把額度用光？
問題往往不在你的提問，而是模型沒選對。
打開 Claude 的模型選單，會看到四個名字。可以把它們想成四種同事：
Haiku：反應最快的助理，適合快速摘要、擷取重點（免費版可用）
Sonnet：什麼都能接的主力，寫作、分析、程式都行（免費版可用）
Opus：擅長深度思考的資深顧問，適合複雜研究與推理（Pro 以上）
Fable：能自己規劃、自己檢查的專案負責人，適合從零做出完整成品（付費方案）
能力越強，回答越慢，也越吃使用額度。拿 Opus 或 Fable 去做 Haiku 就能完成的事，只是白白燒掉額度。
選之前，先問自己三個問題：
1. 這件事要想多深？
查詞、摘要新聞 → 輕的模型就夠；比較企劃、找數據矛盾 → 需要深度思考
2. 做錯的代價多大？
內部草稿 → 錯了改就好；要給主管決策、要對外發布 → 用更強的模型，也要更仔細檢查
3. 要它自己做多久？
一問一答 → Sonnet 就很夠；從粗略想法做到完整成品 → 交給 Fable
記住一個原則：先輕後重，不夠再升級。
Haiku → Sonnet → Opus → Fable
另外，選單裡還有一個「Effort（思考深度）」：整理會議紀錄時調低，回得快；審合約、找風險時調高，想得更完整。
最常見的三個錯誤：
・什麼都用最強的模型
・答案不好只會換模型，卻沒先把需求講清楚
・只看答案長短，不看有沒有抓到重點
小練習：下面三件工作，你會各選哪個模型？
① 回覆客戶的簡單詢問
② 分析半年銷售數據寫成報告
③ 從零規劃一套新人訓練
（參考答案：① Haiku ② 先用 Sonnet，要給主管決策就升 Opus ③ Fable）
想看完整五分鐘影音說明，104學習免費課程「5分鐘學會挑選Claude模式」已經上線，免費報名就能看：
https://nabi.104.com.tw/course/104nabi/47f0bb26-3b67-4f8c-80f4-39dd215c0d01
也歡迎在留言分享：你平常最常用哪個模型？有沒有拿兩個模型比較過同一件工作？
資料來源：
Claude Academy〈Choosing the right Claude model〉
https://academy.claude.com/tutorials/choosing-the-right-claude-model
（模型版本與方案以 2026 年 11 月官方說明為準：Haiku 5.5、Sonnet 5.5、Opus 5.5、Fable 5.1）
一鍵讓文字變高級！10+ 種 Unicode 特殊字體產生器完整攻略
最近在研究社群貼文排版與個人品牌視覺，發現一個超強的免費 Unicode 字體工具網站，不用安裝任何字型，輸入文字就能一鍵轉換成各種風格。以下整理我最常用的 10+ 個頁面，每種風格都用實際效果展示給大家看 👇
𝟏. 粗體文字產生器（首頁）
最基礎也最萬用的功能，適合 LinkedIn 標題、IG 簡介、論壇暱稱。
示範效果：
𝐁𝐨𝐥𝐝 𝐒𝐞𝐫𝐢𝐟 — 數學粗體（襯線）
𝗕𝗼𝗹𝗱 𝗦𝗮𝗻𝘀 — 無襯線粗體
𝑩𝒐𝒍𝒅 𝑰𝒕𝒂𝒍𝒊𝒄 — 斜體粗體
🔗 https://bold-text.com/
𝟐. 酷字體大全（Cool Fonts）
這頁收錄了各種裝飾性字體，從復古到現代應有盡有。
示範效果：
𝓢𝓬𝓻𝓲𝓹𝓽 — 手寫花體（適合邀請函、浪漫貼文）
𝔉𝔯𝔞𝔨𝔱𝔲𝔯 — 哥德黑體（遊戲 ID、復古海報）
𝔻𝕠𝕦𝕓𝕝𝕖 𝕊𝕥𝕣𝕦𝕔𝕜 — 雙線空心字（視覺超搶眼）
𝕲𝖔𝖙𝖍𝖎𝖈 𝕭𝖔𝖑𝖉 — 粗體哥德字
🔗 https://bold-text.com/cool-fonts
𝟑. 泡泡字 & 圓圈字（Bubble & Circled）
可愛風格必備！做 IG 限動標題、Discord 狀態、派對邀請超適合。
示範效果：
ⓑⓤⓑⓑⓛⓔ — 空心圓圈字
🅑🅤🅑🅑🅛🅔 — 實心圓圈字（反白）
🄱🅄🄱🄱🄻🄴 — 方框字
🅱🆄🅱🅱🅻🅴 — 正方框字
𝟒. 小寫大寫 & 上下標（Small Caps & Superscript）
低調又有質感的排版選擇，適合品牌名稱、專業簡介。
示範效果：
ꜱᴍᴀʟʟ ᴄᴀᴘꜱ — 小寫大寫（看起來像大寫但體積較小）
ˢᵘᵖᵉʳˢᶜʳⁱᵖᵗ — 上標字
ₛᵤᵦₛ𝒸ᵣᵢₚₜ — 下標字
𝟓. 刪除線 & 底線（Strikethrough & Underline）
社群貼文常用技巧，做促銷對比、幽默修正常用。
示範效果：
H̶e̶l̶l̶o̶ — 標準刪除線（暗示「這句話不算」）
H̲e̲l̲l̲o̲ — 底線強調
H̅e̲l̲l̲o̲ — 上線 + 底線雙重效果
H̴e̴l̴l̴o̴ — 波浪刪除線（更有個性）
𝟔. 航海錨點字體（Anchor Fonts）
夏天、海洋、航海主題的貼文或品牌文案必備！
示範效果：
⚓ 𝐀𝐧𝐜𝐡𝐨𝐫 𝐒𝐭𝐲𝐥𝐞 — 錨點裝飾粗體
⛵ 𝓝𝓪𝓾𝓽𝓲𝓬𝓪𝓵 𝓢𝓬𝓻𝓲𝓹𝓽 — 航海手寫體
🌊 𝖂𝖆𝖛𝖊 𝕱𝖔𝖓𝖙 — 波浪復古風
🔗 https://bold-text.com/anchor-fonts
𝟕. 等寬字體（Monospace）
程式碼風格、極簡設計感，適合科技類帳號或開發者社群。
示範效果：
𝚃𝚑𝚒𝚜 𝚒𝚜 𝙼𝚘𝚗𝚘𝚜𝚙𝚊𝚌𝚎 — 等寬字體
Ｗｉｄｅ Ｔｅｘｔ — 全形寬字（每個字佔兩倍空間）
𝟖. 鏡像 & 反轉文字（Flip & Reverse）
趣味效果，做彩蛋、隱藏訊息或惡搞貼文超好用。
示範效果：
ɘɿɘʜT ɘƨɿɘvɘɿ — 左右反轉
ƧbɿAwkↄAd — 鏡像反轉
ǝʞɐɯ oʇ ʎɐʍ ǝɥʇ sᴉ sᴉɥ┴ — 上下顛倒
𝟗. 空格 & 間距調整（Spaced Out）
讓文字更有呼吸感，適合極簡風格標題。
示範效果：
S P A C E D O U T — 字母間加大空格
Ｓｐａｃｅｄ Ｏｕｔ — 全形空格版本
𝟏𝟎. 混搭組合技巧
最強大的用法是組合多種效果！以下是幾個我實際用過的範例：
表格
應用場景 組合效果 示範
LinkedIn 標題 Sans Bold 𝗕𝗼𝗹𝗱 𝗧𝗲𝘅𝘁
IG 簡介 Script + Emoji 𝓢𝓬𝓻𝓲𝓹𝓽 ✨
遊戲暱稱 Fraktur 𝕲𝖆𝖒𝖊𝖗 𝕿𝖆𝖌
夏日貼文 Anchor Style ⚓ 𝐒𝐮𝐦𝐦𝐞𝐫
促銷對比 Strikethrough + Bold ~~$199~~ → 𝗦𝗮𝗹𝗲 $99
重要通知 Double Struck ℕ𝕠𝕥𝕚𝕔𝕖
專業簡介 Small Caps ꜱᴍᴀʟʟ ᴄᴀᴘꜱ
可愛風格 Bubble ⓑⓤⓑⓑⓛⓔ
💡 為什麼推薦這個工具？
✅ 完全免費 — 不用註冊、不用付費
✅ 即時預覽 — 輸入文字立刻看到所有風格
✅ 一鍵複製 — 點一下自動複製，直接貼到任何平台
✅ 全平台通用 — IG、Twitter、Discord、LinkedIn、WhatsApp 都能顯示
✅ 隱私安全 — 純瀏覽器處理，不會儲存你的文字
🚀 快速上手三步驟
Step 1 → 打開網站，在輸入框打字
Step 2 → 瀏覽下方所有風格預覽
Step 3 → 點擊喜歡的風格，自動複製，直接貼上！
大家有沒有什麼特別喜歡的字體風格？或者你會怎麼把這些效果用在日常貼文裡？歡迎在留言區交流分享！🎨✨
前端工程師2025年必學技能清單：10大工具與技術指南，職場增能懶人包整理
前端工程師需要掌握的技能和專業涵蓋了多個方面(HTML、CSS 、 JavaScrip...等)，包括基礎的網頁開發知識、前端框架、以及與團隊合作的工具等。本篇文章將深入探討前端工程師必備的 10 大核心技能與工具，幫助您在職涯中站穩腳步，開發出高效且吸引人的網站與應用。
1. HTML、CSS 和 JavaScript
HTML: 用於結構化網頁內容，是前端開發的基礎語言。
CSS: 負責設計和佈局，使網站具有視覺吸引力。
Java Script: 增加互動性，處理用戶事件和動態內容。
⚡推薦課程⚡
成為前端工程師｜透過 HTML 與 CSS 認識網頁設計，從 0 到 1 打造實用介面 (上集)
https://nabi.104.com.tw/course/tibame/f5b246b2-ec79-4f0d-8ef5-2fdf8d6f5bcb
成為前端工程師｜Java Script 入門：帶你逐步培養網頁開發技能
https://nabi.104.com.tw/course/tibame/830671fb-2c58-48fa-9a5a-6c1f1798598a
【更多課程學習】https://user266414.pse.is/6ps94k
2. 前端框架和庫
React.js: 一個用於構建用戶界面的 JavaScript 庫，能夠快速開發單頁應用（SPA）。
Vue.js: 一個漸進式框架，適合於小型到大型應用的開發。
Angular: 一個全面的前端框架，適合大型企業級應用。
Svelte: 新興的前端框架，以其高效的性能和簡化的開發體驗而受歡迎。
⚡推薦課程⚡
Let’s Vue! 前端開發入門到實戰
https://nabi.104.com.tw/course/tibame/ee965aa9-eb02-43d5-ae79-1dcd50f965dc
3. 版本控制工具
Git: 版本控制系統，用於跟蹤代碼變更，方便團隊協作。
GitHub 或 GitLab: 托管代碼庫，協作開發和版本管理的主要平台
⚡推薦課程⚡
Git 速成攻略：2.5 小時變身版本控制達人
https://nabi.104.com.tw/course/tibame/20a2bbd6-ee21-4d92-8899-18e59ea3b97f
AI助理GitHub Copilot | 提升前端開發效率
https://nabi.104.com.tw/course/tibame/c4795096-ae10-43a5-b5e3-2a6548c30e8c
GitHub Copilot AI賦能開發實戰訓練班
https://nabi.104.com.tw/course/tibame/2617c99d-b815-442d-89b4-aa35a360273a
4. 預處理與構建工具
Sass 或 Less: CSS 預處理器，能夠提高樣式表的可維護性和可重用性。
Webpack、Parcel 或 Vite: 模塊打包工具，用於優化資源加載、處理 JavaScript 模塊化等。
【更多課程學習】https://user266414.pse.is/6psa64
5. 響應式設計與跨平台兼容
響應式網頁設計: 掌握使用 CSS 媒體查詢（Media Queries）以適應不同屏幕尺寸的布局技巧。
跨瀏覽器兼容性: 確保網站在不同的瀏覽器（如 Chrome、Firefox、Safari、Edge）上的一致性。
⚡推薦課程⚡
RWD響應式網頁設計入門
https://nabi.104.com.tw/course/tibame/9e4a630f-6e3b-4261-adf6-a6ac1edf1ea8
工程師救星-用Bootstrap速成響應式網頁開發
https://nabi.104.com.tw/course/tibame/9e4a630f-6e3b-4261-adf6-a6ac1edf1ea8
6. 調試與測試
Chrome DevTools: 瀏覽器內建的開發者工具，用於調試 JavaScript、分析網頁性能。
前端測試框架: 如 Jest、Mocha、Cypress，用於自動化測試和單元測試。
7. API 與 AJAX 技術
Fetch API 或 Axios: 用於與後端服務進行 HTTP 通信，拉取數據或發送數據。
RESTful API 與 GraphQL: 理解如何與 API 交互並消費 API 提供的數據。
8. 設計工具和基礎設計原則
Figma 或 Adobe XD: 瞭解設計工具以便與設計師協作。
UX/UI 基礎: 基本的用戶體驗和用戶界面設計原則，確保設計既美觀又實用。
⚡推薦課程⚡
UI/UX 新時代指南：產品設計 x 商業思維 x AI 工具
https://nabi.104.com.tw/course/ppa/d9785ca3-7de2-4567-aae5-2c771a5471e8
UI/UX新手實務班｜UI介面設計，洞悉使用者體驗
https://nabi.104.com.tw/course/tibame/1550e806-07b1-49a2-a8e8-42668911d4ca
9. 性能優化
代碼分割與懶加載: 減少初次加載時間，提升網站性能。
圖片優化與資源壓縮: 優化圖片格式與大小，減少網頁加載時間。
10. SEO（搜索引擎優化）
理解基本的 SEO 概念，確保網站在搜索引擎中具有良好的可見度，包括結構化數據的應用和適當的標題標籤。
⚡推薦課程⚡
SEO搜尋引擎優化七大密技｜攻上頂端排名寶座
https://nabi.104.com.tw/course/tibame/b0d286b0-9106-406c-beff-c53918ab2270
具備以上這些技能，能幫助前端工程師在現代網頁開發中具備更強的競爭力與靈活性。
一頁式網站是什麼？一頁式網頁設計優缺點與費用解析
很多人的第一個網站是被一則廣告逼出來的。點進一個連結，畫面一路往下滑，商品或方案從頭講到尾，滑到底的時候旁邊跳出填寫框，人就順手把手機號碼留了下來。整個過程沒有換過頁面，也沒有點過任何選單。這種把一件事從頭講到尾的頁面，就是一頁式網站（One Page Website），也有人說一頁式網頁、單頁網站。
它聽起來像一句行銷話術，其實是很樸素的工具：把該說的資訊排成一條動線，讓人不用自己找路。下面把一頁式網站能做的事、不能做的事，以及我們實際做過的幾種型態講清楚，幫你在決定花錢之前，先想明白自己到底需不需要。
一、一頁式網站是什麼
一頁式網站的全部內容都在同一個網址裡。首頁上方有主視覺和一句主打的話，往下依序排服務介紹、案例、價格、常見問題，最後放聯絡表單。頁面頂端通常會留一個選單，點了不會跳到別的頁面，而是往下滑到這一段。這種跳法叫錨點跳轉，是長頁能讀得下去的前提。
和多頁式網站比起來，差別在資訊的位置。多頁式網站把公司介紹放在「關於我們」，產品放在「產品專區」，案例放在「案例分享」，訪客要自己點進去找；一頁式網站把這些東西排在一起，順序由你決定。訪客的差別是，前者要做出選擇，後者只要一直滑。
順帶講一個常被混用的名詞。Landing Page（著陸頁）講的是位置，也就是「訪客從廣告點進來後抵達的那一頁」；一頁式網站講的是形式，也就是「這頁總共只有一頁」。位置和形式是兩件事，一頁式網站可以當著陸頁用，你官網裡的某一個服務頁也可能是著陸頁，只是它不是單頁。
同場加映：月光創意另寫了一篇一頁式網站與 Landing Page 中文意思的完整版文章：https://www.moon-d.com/blog/one-page-website.php
一頁式網頁設計這幾個字在業界被使用得很寬鬆，實際上做的事情差很多。有的是把公司現有的簡介貼成一頁，動一下滑就到底；有的是花時間重新安排內容節奏、處理視覺階層、把表單和追蹤都接好。兩者外觀看起來都像一頁式網站，做出來能不能用，是兩回事。
二、你到底該不該做一頁式網站
在動工之前，先回答五個問題，問完大概就有答案了。
第一，你的網站要回答的問題是不是只有一個？「我們做什麼、為什麼值得信、要怎麼找我」，三句話講完就沒了，適合一頁式。如果對方會問到你沒做的部分，例如各項方案的差異、服務據點、維修收費、多年案例，那就需要多頁式。
第二，商品或服務的數量是不是收斂的？一個課程、一檔新商品、一次促銷、一項專業服務，都是好例子。整間公司二十條產品線擺進一頁，會變成一張沒人想讀的清單。
第三，你的流量從哪裡來？如果主要靠 Google 自然搜尋，建議直接跳過這個選項，理由下一節會說明。如果是投廣告、發社群、寄電子報、印在名片或 DM 上讓人掃碼，流量來源集中在一兩個地方，一頁式非常合用。
第四，內容會不會一直長下去？每月都要新增文章或案例的網站，單頁結構會很快撐不住。反過來，內容穩定、期數固定的頁面，用一頁式最省事。
第五，你要訪客做的動作是同一件事嗎？「填表預約」是，「填表之後還要選加購、加入會員、下載應用程式」就不是。一頁式的力量來自專心，如果頁面上同時有六個按鈕要人選，等於把難度還給了訪客。
五個問題裡，只要「要做 SEO」或「服務項目很多」任一成立，就該認真考慮多頁式。其餘都偏向可以使用一頁式網站。
三、一頁式網站的好處
動線短，是最實在的一項。訪客從點進來到按下送出，中間沒有換頁、沒有開新視窗、沒有回到上一頁找路。每多一個跳出點，就多一次放棄的機會，尤其是手機上。表單放在頁尾，不代表它一定被填，但它至少在視線內。
手機閱讀友善是另一個好處。現在多數人上網的動作就是滑，滑這個動作不需要學習，也不需要等頁面載入。一頁式網站的節奏本來就適合手機，設計時把手機版當主版本就好，不會出現「桌機版很好看，手機版擠成一團」的窘況。
製作快，後續修改也單純。頁面只有一個，東西要改就是改那一處，不會出現「首頁改了，內頁沒改」的情況。對只有一兩個人要維護的團隊來說，這點很實際。
還有一個比較少被講的好處：訊息會被迫一致。當你只有一個頁面可以放內容，產品文案、服務說明和價格就不容易各說各話。資訊一集中，矛盾的地方反而會自己浮出來。
四、缺點，以及最常見的三個誤區
第一個誤區是「一頁式網站也能做 SEO」。實情是它先天吃虧。所有主題共用一個網址，等於只有一個標題、一組網頁描述可以寫。你想同時被「XX 室內設計」「XX 維修」「新北 裝修推薦」找到，需要的是多個頁面各自對應一個搜尋意圖，單一長頁做不到。這不代表一頁式網站完全不會被搜尋到，而是它很難成為自然流量的主力。若網站存在的目的就是讓不認識你的人從 Google 找到你，請把預算留給多頁式。
第二個誤區是「只有一頁，所以便宜」。頁面數量不等於工作量。訪談、文案、圖片、影片授權、響應式適配、表單串接、追蹤設定、測試與上線，每一項都跟頁數無關，還常常是一頁式專案最花時間的部分。真正會讓報價拉開差距的，是這些工作有沒有被認真做。
第三個誤區是「看起來比較有規模」。這正好講反了。在金融、醫療、法律、上市上櫃這些產業，一頁式網站常被讀成小公司、沒制度、隨便做做。所以這類客戶通常會把一頁式網頁用在活動或產品募資上，正式的企業形象還是做多頁式官網。
還有幾個實際限制要知道。所有東西共用一個網址，之後想分析「哪一段的訪客最多、哪一段開始離開」，資料會比較難拆解。滑完就走的人很多，又沒有其他頁面可以逛，跳出率看起來會偏高，拿它跟多頁式官網直接相比沒有意義。頁面拉得太長也會有後果：圖片太多會拖慢載入，區塊順序亂會讓人滑到一半就放棄。一頁式能塞多少字，最後是由訪客的耐心決定，跟版面空間無關。
五、我們做過的三種一頁式網站
講完道理，換三個我們真的做過的案子，差別會比較清楚。
第一個是金融投信推出的黃金礦業 ETF 募集頁。這種頁面要在很短的時間內讓投資人相信這檔標的值得研究，所以視覺走黑金路線：深色岩質底襯出金色的光澤，標的代碼用大字級的金屬質感字型放在第一眼的位置，資訊則用比較克制的排版往下列。重點不在裝飾，而在於把「這是什麼」和「我要做什麼」分開處理。頁面右側做了懸浮的快捷工具列，申購單與銷售機構的入口一直掛在畫面上，訪客不論滑到哪一段都能立刻行動，不必回頭找。
第二個是電商通路品牌的活動頁，背景是一整檔檔的促銷套組。這種頁面最怕滑到底還是不知道要買哪一組，所以節奏比資訊更重要。做法上，讓背景的雲朵與愛心有呼吸感的微動態，商品和「立即購買」按鈕在滑入時做漸顯與微幅放大，讓「點這裡」的手感成立；影片與底部按鈕的切換也刻意調過節奏，避免看起來像被塞進去的廣告。這種頁面沒有太多字，設計的任務就是讓手指繼續往下滑。
第三個是醫療健檢中心的一頁式官網。這個型態真正的難題是信任，視覺只是外層。健檢是低頻、高單價、又牽涉身體的消費，訪客在意的是項目內容、檢查流程、院所環境、醫師陣容與預約方式。這頁的排法是照著看診的順序走：健檢項目與差別、流程說明、環境照片、醫師介紹、費用與預約入口。資訊夠完整，信任感才有地方生出來；這也是為什麼它不能只做漂亮，內容深度得跟上一頁。
三個案子擺在一起，同一種形式的側重點可以差很多。募集頁要的是權威感與行動捷徑，活動頁要的是節奏與衝動，官網要的是資訊完整與可信度。動工前先決定這一頁要說服誰，設計才有依據。
六、從想法到上線的流程
第一步，寫出一句話說明這頁要對誰說什麼。如果這一句話需要三個不同的受眾、五項服務和四種行動才能講完，問題不在頁面太短，在於任務還沒拆開。
第二步，排區塊順序。順序要照訪客的疑問走，不照公司的組織圖。訪客通常先問「這是什麼」，再問「跟你競爭的有什麼不同」，然後才問「要多少錢」「怎麼找你」。誰先誰後要想清楚。
第三步，備素材。文字、照片、影片、標誌、價格與常見問題，缺一項就會在製作階段卡住。照片建議一次備齊同尺寸，影片要先確認長度與比例。這一步沒做，後面會一直等。
第四步，決定誰做。這是整個流程裡最關鍵的一個決定，下一節會講。
第五步，驗收，而且用手機驗。檢查項目不多：首屏的主張和按鈕有沒有被蓋住、表單能不能真的收到、頁面在慢速網路下會不會卡、每張圖片有沒有替代文字、按鈕點下去有沒有被記錄。這五項沒過，不要上線。
七、自己做，還是找人做
誠實講，一頁式網站確實有免費工具能用。個人作品集、履歷、單一課程的招生頁、一次性的活動，這些用現成平台或自己動手做得又快又省錢，這點不用否定。
撐不住的情況是另一種：頁面要自己長期更新、要在上面賣東西、要能被 Google 找到、要代表一家有規模的公司、還要在手機上又快又穩。這種情況自己做的成本通常比想像中高，因為時間會卡在你根本不熟的地方，美化反而不是瓶頸。
我們（月光創意網頁設計）做的是後半段：客製化的一頁式網頁設計、響應式適配、把內容節奏重新排過、表單與系統串接、追蹤設定，以及最重要的——上線之後還可以繼續幫你改內容、追蹤數據並調整。這種頁面最好在規劃階段就把後續維護一起談掉，因為一頁式網站的內容要更新，沒有後台可以靠就會變成一份靜態文件。
八、常見問題
一頁式網站等於著陸頁嗎？
不對等。著陸頁描述的是訪客從哪裡進來，一頁式網站描述的是頁面有幾頁。前者可以有多頁，後者只有一頁。
一頁式網站能放多少商品？
沒有固定數字，判準是「滑到底還願不願意讀」。實務上把十來件、差異明確的商品放在一頁是讀得完的，數量再往上，建議改用多頁式加上分類。
做一頁式網站還需要做響應式嗎？
需要，而且建議直接以手機版為主版本再放大到桌機。絕大多數訪客是拿手機進來的，先做桌機再等比例縮小，字級和間距會一直卡住。
之後想擴充成多頁式，可以嗎？
可以，但成本不等於把頁面切開。內容重新歸類、導覽重新設計、網址與標題重新規劃都要重做。所以如果本來就預計三年內會擴充，一開始就做多頁式比較省。
九、如果還在猶豫怎麼開始
一頁式網站能不能用，取決於你的內容能不能收斂成一條線。收斂得了，它是最省力的做法；收斂不了，多花時間做也只會得到一張很長的網頁。
如果你手上的素材很多，卻不確定該排成活動頁、募集頁還是一頁式官網，可以先看月光創意整理的「一頁式網站完整指南」： https://www.moon-d.com/blog/one-page-website.php
裡面把一頁式網站的定義、與 Landing Page（著陸頁）的差別、優缺點、設計原則、報價行情與免費平台比較整理成一頁，也放了可互動的範例，建議直接存起來。
歡迎直接帶著你的需求來聊，我們會先幫你確認這一頁該不該做成一頁式。
月光創意網頁設計：https://www.moon-d.com/
加了結構化資料，AI 就會引用？先核對文章的三個欄位
裝了結構化資料外掛，不代表 AI 已引用文章。今天把標記裡的標題、作者、發布日期與畫面對照，交出三筆紀錄。適合自行維護網站的個人、工作室與中小企業；準備瀏覽器、記事本及公開文章，不需後台或付費工具。
【目標】
結構化資料用標準格式描述頁面。JSON-LD 是其中一種寫法，通常放在 HTML 的 script 區塊，正文不會直接顯示整段資料。它不能替文章增加不存在的作者、資格或成果。
Google 說 AI Overviews、AI Mode 沿用基本 SEO，沒有額外必備的特殊 schema；既有標記應與可見文字相符。這適用於 Google 搜尋，不能當成所有 AI 產品的共同規則。符合要求也不保證抓取、收錄或呈現。
【四步操作】
1. 選一篇文章，先在一般畫面抄下主標題、作者署名及標示為「發布」的日期，記網址與查核日期。另畫五欄：「欄位／標記值／畫面文字與位置／判定／待辦」。沒有看到作者，就記未找到，別拿網站頁尾的公司名直接補上。
2. 按右鍵選「檢視網頁原始碼」，搜尋 application/ld+json，找描述本篇的 Article 或 BlogPosting 項目；可能放在 @graph 裡，也可能有多個區塊。別把 Organization 名稱或麵包屑項目誤當文章欄位。原始碼找不到時先記未找到，交維護者查渲染後內容，不直接判定全頁沒有標記。
3. 抄三個值：headline 是文章標題；author 裡的 name 是作者名稱；datePublished 是首次發布日期。author 若列多人，分別核對，別合併成一個人；publisher 是發布者，不能直接當成作者。這三項只是本次抽查範圍，不是完整必填清單。
4. 回到畫面比對。標題換行不同，先確認是否同一句；多出「保證第一名」就不能當排版差異。日期要分發布與更新，不能拿 dateModified 對「首次發布」。沒有時刻與時區，就只記日期已核對，不補凌晨零點。
判定用「相符／有差異／資料不足」。有差異時記兩個原值與位置；缺依據就待確認，不猜答案。抽查一頁不能推論全站。
【本日核對】
2026/10/18，我以 HTTP 只讀文末客脈 GEO 教學的原始 HTML，回應 200，並核對瀏覽器畫面。Article 的標題為「GEO 內容寫作實作：把測試紀錄變成可查證的答案」，對應主標；作者名稱為「客脈 AI」，對應上方署名；發布日期為 2026-09-18，畫面為「發布 2026.09.18」。
三筆可記「文字與日期相符」。本次未核對發布時刻，也未跑 Rich Results Test、查 Google 採用結果或測 AI 引用。JSON 能解析、三欄相符、搜尋呈現是不同階段，不能合寫「GEO 已成功」。
【虛構錯誤練習】
假設一篇「錄音整理教學」畫面作者是小林，標記卻是另一位不存在的專家，應列作者差異，查清實際責任者，再由有權限的人修正。不能因想增加可信度，就在標記裡加名人或資格。
另一篇畫面發布日是 9/1，只有排版微調，卻把首次發布日改成今天。應保留差異及修改紀錄，確認發布與更新的用途；今天檢查不等於今天首發。以上都是虛構紙上教材。
【作業與驗收】
用自己的公開文章或文末範例，完成五欄三列及待辦；全部相符就寫「本次三項未見差異」，不用捏造問題。請另一人依表格找到同一標記與畫面位置，說明判定理由；未複核就記自行核對。
預期成果是三筆對照與待辦。若日後在自己的網站修正，要重新讀取正式頁並核對；在原始碼視窗看見文字，不表示已修改。常見錯誤還包括把語法能解析當成內容正確、只查三欄就宣稱完整合規，以及把測試工具通過當成 AI 推薦。
本練習可零額外工具費完成，人工仍需時間；外掛進階功能與正式維護可能另計，不需買訂閱。今天未改官網、量測排名或商業成效；引用須另留實際回答與來源證據。
官方文件（2026-10-18 查核）：
https://developers.google.com/search/docs/appearance/ai-features
https://developers.google.com/search/docs/appearance/structured-data/article
練習頁：核對主標、作者與發布日期
https://kemai-ai.com/blog/geo-evidence-based-content-guide?utm_source=nabi&utm_medium=community&utm_campaign=nabi_daily&utm_content=20261018_schema_match
整理／配圖：客脈 AI。配圖為 AI 示意圖，非真實網站、驗證報告或引用證明。
戰國策虛擬主機 vs GoDaddy：台灣企業 WordPress 主機完整比較評測
GoDaddy 是全球最大的網域名稱註冊商，同時也是全球最大的主機服務提供商之一。它的名字幾乎是「買網域、架網站」的代名詞，在台灣也有相當高的品牌知名度。但知名度高，不等於對台灣企業來說是最好的選擇。本文將深入比較 GoDaddy 與戰國策虛擬主機，從台灣企業的實際使用需求出發，給你一個清楚的比較結論。
GoDaddy 在台灣市場的定位
GoDaddy 在台灣的知名度主要來自兩個方向：一是大量的廣告投放，二是網域註冊業務的便利性。對很多台灣用戶來說，第一次買網域可能就是在 GoDaddy 上完成的。
然而，網域購買和主機服務是兩件不同的事。GoDaddy 的主機服務在台灣市場有幾個實際的限制，需要在選擇之前仔細評估。
GoDaddy 主機服務的核心問題
第一個問題：初始優惠價格具有高度誤導性。GoDaddy 的廣告通常主打極低的入門價格，有時甚至不到一個月一美元。但這個價格只適用於第一個合約期，且通常需要一次性購買多年才能享有。合約到期後，續約價格往往是原始優惠價的三到五倍，讓很多用戶在不知情的情況下面臨大幅漲價的困境。
第二個問題：主機性能在業界評價偏低。在全球多項主機性能測試中，GoDaddy 的共享主機在伺服器回應速度和穩定性方面的評分普遍不高。性能不佳直接影響網站的載入速度，進而影響用戶體驗和 SEO 排名。
第三個問題：附加銷售和捆綁式推銷問題嚴重。GoDaddy 的購買流程中充斥著大量的附加產品推銷，從網站安全工具、備份服務、電子郵件方案到 SEO 工具，每一個步驟都在推銷額外的付費項目。對於不熟悉的用戶來說，很容易在不知不覺中購買了一堆不必要的服務。
第四個問題：台灣本地支援薄弱。雖然 GoDaddy 有提供中文介面和中文客服，但台灣在地的技術支援深度和響應品質，與本土服務商相比仍有落差。特別是在需要快速解決技術問題的緊急情況下，差距更為明顯。
第五個問題：伺服器位置不在台灣。GoDaddy 在亞太區的伺服器主要位於新加坡，對台灣訪客的連線速度不如本地伺服器，這對以台灣市場為主的企業網站的 SEO 表現有負面影響。
戰國策虛擬主機的全面優勢
針對 GoDaddy 在台灣市場的幾個核心問題，戰國策虛擬主機提供了更符合台灣企業實際需求的解決方案。
費用透明，無任何隱藏漲價陷阱。戰國策虛擬主機的定價結構清晰穩定，你看到的費用就是實際支付的費用，不存在「優惠期結束後三倍漲價」的問題。對企業來說，可預期的費用結構是財務規劃的基礎。
台灣本地伺服器，真正的速度優勢。戰國策的伺服器基礎建設位於台灣，對台灣訪客的連線延遲遠低於 GoDaddy 的新加坡節點。在 Google 的頁面速度評估中，本地伺服器的優勢會直接反映在 Core Web Vitals 評分上。
繁體中文客服，本土技術支援。戰國策提供台灣在地的繁體中文專業客服，在台灣工作時間內快速響應技術問題，不需要語言轉換和跨時區溝通，解決效率遠高於 GoDaddy 的客服體驗。
WordPress 優化環境，性能穩定可靠。戰國策虛擬主機針對 WordPress 進行了專門的性能優化，確保 WordPress 網站在最佳的環境下運行，伺服器回應速度和穩定性優於 GoDaddy 的通用共享主機。
沒有附加銷售困擾。戰國策的服務購買流程清晰，你購買的是主機服務，不需要擔心被引導購買一堆不必要的附加項目。
GoDaddy 到底適合誰？
GoDaddy 的主要優勢在於品牌知名度和域名服務的便利性。如果你只是需要購買網域，GoDaddy 是一個合理的選擇。但如果你的目標是架設一個高效能、高穩定性、對 SEO 友善的 WordPress 企業網站，GoDaddy 的主機服務並不是最佳選項，尤其對台灣市場而言更是如此。
SEO 表現全面比較
對於重視 SEO 的台灣企業來說，這個比較的結論相當清楚。戰國策虛擬主機在伺服器速度（對台灣訪客）、穩定性、以及整合 SEO 行銷服務這三個 SEO 關鍵維度上，全面優於 GoDaddy 的主機服務。
更重要的是，戰國策不只是主機服務商，同時也是台灣 AI SEO 和 GEO 領域的專業顧問。選擇戰國策虛擬主機的企業，可以同時獲得主機環境和行銷策略的完整支援，這種整合優勢在一個全球性的主機服務商如 GoDaddy 完全找不到。
結論
GoDaddy 是一個知名的全球主機和域名服務商，但對台灣企業的 WordPress 主機需求來說，它在性能、定價透明度、本地服務支援等方面都存在明顯的不足。戰國策虛擬主機以台灣本地伺服器、透明費用、繁體中文客服，以及整合了 SEO 行銷服務的完整生態，是台灣企業主更值得優先考慮的選擇。
了解更多戰國策虛擬主機方案：https://www.nss.com.tw/wordpresshosting/
#虛擬主機 #GoDaddy比較 #戰國策 #WordPress主機 #台灣主機 #SEO主機 #網域 #台灣網站架設
Google 商家SEO不是大量建立商家頁面！從語意與主題權威，看地方搜尋真正的競爭邏輯
許多企業執行在地 SEO 時，最常採取的做法，就是把「服務名稱＋縣市或行政區」大量組合成頁面。
例如：
「台中網頁設計」、「北屯網頁設計」、「西屯網頁設計」、「南屯網頁設計」，甚至繼續細分到每一個行政區。
這種做法表面上看起來涵蓋了大量地方關鍵字，實際上卻可能製造出一堆內容高度相似、搜尋意圖重疊，而且沒有獨立價值的頁面。
我認為，在地 SEO 真正的重點，不是企業可以建立多少個地區頁面，而是每一個頁面是否有充分理由獨立存在。
搜尋引擎需要瞭解的也不只是「這個頁面出現幾次台中」，而是這間公司提供什麼服務、服務哪些地區、具有哪些經驗、能解決什麼問題，以及為什麼值得被推薦。
這也是我閱讀 Search Engine Land 關於語意與主題權威的案例分析後，認為最值得台灣企業重新思考的地方：地方搜尋的競爭，已經從關鍵字排列組合，轉向網站能否建立清楚、完整且可驗證的商業語意。
在地 SEO 最大的問題，往往不是頁面太少，而是無效頁面太多
原文提出一個相當實用的觀念，稱為「Query Deserves a Page」，也就是：這個搜尋需求，是否真的值得建立一個獨立頁面？
我認為這個問題，比「這個關鍵字有沒有搜尋量」更加重要。
假設一家沙發清洗公司主要服務高雄，網站想要布局以下關鍵字：
高雄沙發清潔
左營沙發清潔
鼓山沙發清潔
三民沙發清潔
高雄皮沙發清潔
高雄布沙發清潔
這些關鍵字不一定全部都需要建立獨立頁面。
「皮沙發清潔」與「布沙發清潔」可能具有不同的設備、施工方式、價格與注意事項，因此有機會分別建立完整服務頁面。
但是「左營沙發清潔」與「鼓山沙發清潔」若只是更換行政區名稱，其他內容、照片、價格與服務流程全部相同，我通常不建議急著拆成兩個頁面。
Google 要理解的不是地名，而是服務與地區之間的關係
Google 官方說明，在地搜尋結果主要會考量相關性、距離與知名度。換句話說，頁面出現地區名稱，只能解決部分相關性問題，無法單獨補足商家的地理距離、品牌知名度、評論、網站權威與實際服務證據。
因此，我不會把在地 SEO 理解為「服務關鍵字後面加上縣市名稱」，而會把它拆解成以下關係：
重點：在地搜尋可見度＝服務相關性 × 地區證據 × 品牌可信度 × 頁面回應能力
以「台中 WordPress 網頁設計」為例，搜尋引擎需要看到的不只是「台中」與「WordPress」兩組文字同時出現，而是：
公司是否真的提供 WordPress 網頁設計。
是否服務台中企業。
是否具備台中客戶案例。
是否能說明網站規劃、設計、SEO、維護與費用。
是否有明確公司名稱、聯絡方式與服務區域。
外部網站、商家檔案與評論是否也呈現一致訊息。
頁面是否能協助訪客完成比較、評估與詢問。
這些內容共同建立的，才是完整的「服務—地區—品牌」語意。
我認為，許多企業網站排名不理想，並不是因為關鍵字密度不足，而是網站沒有讓搜尋引擎看懂：這間公司到底是誰、主要做什麼、在哪裡提供服務，以及有什麼證據可以支持這些主張。
主題權威不是文章數量，而是完整解決顧客的決策問題
談到主題權威，很多人第一時間想到的是大量撰寫文章。
例如，想提升「高雄沙發清潔」排名，就開始撰寫：
＊沙發清潔多少錢？
＊不能拆的沙發怎麼洗？
＊到府洗沙發多少錢？
＊沙發很髒怎麼清？
這些內容確實有價值，但文章數量本身不等於主題權威。
我所理解的主題權威，是網站是否能夠完整回答顧客由發現問題、比較服務、評估風險到決定聯絡的整段歷程。
一個具有地方主題權威的網站，通常需要四個層次。
第一層：核心服務內容
主要服務頁必須清楚說明服務內容、適用對象、流程、價格、差異、限制與聯絡方式。
核心服務頁不是只負責排名，更應該是整個網站最重要的業務承接頁面。
第二層：決策支援內容
企業應回答顧客在購買前最常出現的問題，例如價格怎麼計算、不同方案有什麼差別、服務需要多久、可能有哪些風險，以及應該如何選擇廠商。
這些內容可以是文章，也可以直接整合在服務頁面中。
第三層：在地經驗與實際證據
包括地區案例、施工照片、服務紀錄、顧客評價、合作品牌、門市資訊、交通方式與服務範圍。
我認為，這一層是許多台灣企業最容易忽略的部分。
網站可能寫了五十篇知識文章，卻沒有任何實際案例、團隊資訊或服務證據。這種網站或許涵蓋很多關鍵字，卻不一定能建立足夠的信任。
第四層：品牌與實體資訊一致性
網站、Google 商家檔案、社群平台、產業名錄與外部報導中的公司名稱、電話、地址、服務項目與品牌描述，都應盡量保持一致。
企業也可以使用合適的 LocalBusiness 或 Organization 結構化資料，協助 Google瞭解營業時間、地點、聯絡方式與組織資訊。不過結構化資料只是提供明確線索，不能取代頁面上使用者真正看得到的內容。
語意 SEO 不只是寫作問題，更是企業資訊整理問題
許多人會把語意 SEO 想得非常複雜，開始研究實體、屬性、三元組、向量與各種搜尋專利。
這些技術概念確實有助於理解搜尋引擎，但以多數中小企業網站來說，我認為最重要的第一步，仍然是把自己的商業資訊整理清楚。
企業至少要能明確回答：
我們是誰？
我們提供哪些主要服務？
每一項服務適合哪些人？
我們實際服務哪些地區？
我們具備哪些經驗與證明？
顧客為什麼應該選擇我們？
顧客下一步可以怎麼行動？
當這些問題沒有答案時，再多的語意關鍵字與結構化資料，也很難建立穩定的搜尋權威。
反過來說，當企業資訊本身足夠完整，我們就能把這些內容安排到首頁、服務頁、案例頁、關於我們、FAQ、商家檔案與外部平台，形成一致的品牌語意。
因此，我認為語意 SEO 的本質，不是把文章寫得更學術，而是降低搜尋引擎與潛在顧客理解企業時的不確定性。
網頁版面也是語意的一部分，不是把長文貼上去就完成
原文另一個值得注意的觀點，是「視覺語意」。
一個網頁不只是文字集合。標題、表格、卡片、圖片、流程圖、價格區塊、案例、評論與行動按鈕，都在告訴搜尋引擎及使用者：這個區塊的功能是什麼。
例如，搜尋「台北植牙費用」的使用者，通常希望快速看到：
單顆植牙大約多少錢。
費用包含哪些項目。
哪些情況會增加費用。
是否可以分期。
初診需要進行哪些檢查。
假如頁面只放一篇五千字長文，卻沒有費用表、療程流程、醫師資訊、案例與預約方式，即使文字相當完整，使用體驗與轉換能力仍然可能不足。
真正優秀的語意頁面，不只是「談到所有相關主題」，而是使用最適合的方式回答每一種問題。
AI 搜尋時代，在地權威已經延伸到網站之外
在傳統 SEO 中，企業可能只關心自己的網站能不能排名。
但進入 AI Overviews、AI Mode 與各類生成式搜尋工具之後，品牌能否被推薦，逐漸取決於系統能不能從不同來源確認同一件事。
原文將這種作法稱為外部主題地圖，強調藉由相關網站、地方媒體與第三方內容，建立品牌、服務、地區與特定屬性之間的共同出現及外部共識。
我的實務解讀是：企業不能只在自己的網站上說自己最好，而要讓外部世界也能提供可以核對的證據。
例如，一間高雄冷氣清洗公司希望被 AI 推薦，就不能只建立「高雄冷氣清洗推薦」服務頁，還應逐步累積：
Google 商家評論。
實際清洗案例。
在地媒體或部落格報導。
居家清潔相關網站的專業內容。
社群平台上的顧客經驗。
品牌名稱與服務項目的穩定關聯。
可驗證的服務範圍與聯絡資訊。
我認為，這也是 SEO 與 GEO 開始融合的地方。
SEO 解決的是網站能不能被搜尋引擎發現、理解與排名；GEO 更進一步處理品牌能不能在跨來源比對之後，被生成式引擎視為可信任的答案。
我同意原文的方向，但不建議把所有理論當成固定公式
這篇 Search Engine Land 文章引用了許多搜尋專利、演算法推論、案例數據與 Google 內部資料相關討論，技術深度相當高。
其中「不要無限制建立相似頁面」、「集中排名訊號」、「以搜尋需求決定頁面架構」與「文字和版面應共同回應搜尋意圖」，都是我高度認同的方向。
不過，我不建議企業把任何專利、洩漏資料、精確比率或單一案例，直接當成適用所有網站的排名公式。
搜尋專利代表搜尋引擎可能採取的技術方向，不一定表示每項機制都以相同方式套用在目前的搜尋結果。個別案例的成長，也可能同時受到內容、技術、品牌、競爭環境與演算法更新影響。
Google 官方對 SEO 的基本定義，仍然是協助搜尋引擎理解內容，同時幫助使用者找到網站並做出是否造訪的決定。
因此，以台灣中小企業來說，我會把執行順序放在：
先確認真正有商業價值的服務與地區。
判斷哪些搜尋需求值得獨立成頁。
整併高度重複或沒有價值的內容。
補足服務、價格、案例與地方證據。
建立清楚的網站架構與內部連結。
統一網站、商家檔案及外部平台資訊。
持續觀察曝光、排名、詢問與成交表現。
Google 在索引過程中會將相似頁面分組，並選擇其中最具代表性的標準網址；過多重複或高度近似的頁面，也可能導致 Google 選擇的標準頁面與網站原先預期不同。
這也是為什麼我一直認為：在地 SEO 不是比誰的頁面多，而是比誰的每一個頁面都更有存在的理由。
我認為地方搜尋最後競爭的是「被推薦的合理性」
做了多年 SEO 與網站規劃後，我越來越確定一件事：Google 與 AI 搜尋真正需要解決的問題，不是「哪個網站最會寫關鍵字」，而是「哪一間企業最適合回答這次搜尋」。
語意讓搜尋引擎瞭解品牌、服務、地區、需求與證據之間的關係；主題權威則證明企業能持續、完整且可信地回答這個領域的問題。
對企業而言，真正需要建立的不是一座充滿關鍵字頁面的網站，而是一套能夠清楚回答以下問題的數位資訊系統：
你是誰？你在哪裡服務？你擅長什麼？你有什麼證據？為什麼這次應該推薦你？
當網站內容、頁面架構、商家檔案、實際案例、顧客評價、外部提及與品牌資訊，都能共同回答這些問題時，企業才真正建立了在地搜尋所需要的主題權威。
所以，我對在地 SEO 的總結很簡單：
不要急著建立更多頁面，先讓每一個頁面變得更有意義；不要只增加關鍵字，而要增加搜尋引擎與顧客可以共同驗證的證據。
參考資料來源：
1. https://searchengineland.com/how-semantics-and-topical-authority-improve-local-seo-482980
2. https://support.google.com/business/answer/7091?hl=en&utm_source=chatgpt.com
網頁標題字很大，卻不是 H1？做一張標題層級表
把一句話放大、加粗，不代表網頁已經把它標成標題。今天只練一件事：替一個頁面做出「畫面文字、實際標記、內容層級、處理建議」四欄表，讓維護者能找到同一段重查。適合自己建站、編輯內容的個人、工作室與中小企業；準備桌面 Chrome、一個公開網址及記事本即可，不需要買外掛。
【先寫大綱，再看程式標記】
選一頁，記完整網址、查核日期及範圍，例如只看文章正文。用一句話說明這頁在回答什麼，再列各節主題。先判斷內容關係，別為了字比較小就選 H3，也別讓每個醒目句都變成 H1。
W3C 說標題能表達內容組織，也能讓瀏覽器與輔助科技提供頁內導覽。H1 到 H6 是層級，不是六種字體大小。往下開子節時應盡量避免跳級，例如 H2 直接接 H4；結束子節，從 H3 回到下一個 H2，則可以是正常的大綱結構。
以下是虛構的「影像備份教學」大綱，並非真實網站：H1「拍攝素材如何備份」，下面放 H2「備份前準備」、H2「複製與核對」、H2「還原練習」；「複製與核對」若要再分兩個子題，才安排 H3「複製原檔」及 H3「核對檔案」。同層標題回答相近層次的問題，不必每一層都湊滿。
【照四步做標題表】
1. 打開選定頁面，從正文主標開始。在文字上按右鍵，選「檢查／Inspect」，Chrome 會開啟 Elements。只讀標記；不要在正式後台改內容，也不需要貼程式到 Console。
2. 找到與畫面文字對應的元素，記 H1、H2 等標記。如果選到標題裡的 span，往外看包住它的元素，不能因內層是 span 就說沒有標題。若只看到 div 或 p，先記實際所見；遇到 role="heading"、aria-level 等寫法，一併留下給維護者確認，不只靠標籤名稱下結論。
3. 往下抽查三個章節，照出現順序抄文字與標記，並寫它是「整頁主題、同層章節、前節子題」哪一種。導覽、側欄及頁尾另註區域，不與正文混成同一串；只查正文就不要宣稱全頁已查完。
4. 把畫面暫放一旁，只讀你寫的大綱，是否能理解文章在教什麼？若三個 H2 都叫「了解更多」，可提出更具體的名稱；若某段只是提示句，保留一般段落也合理。建議與已修改分開記，找到可疑項目不等於已修好。
【一個當日已核對的例子】
2026/10/15，我只讀查看文末客脈一頁式網站教學的瀏覽器 DOM。文章主標「一頁式網站是什麼？適合誰、範例架構、費用與信任感怎麼做」為 H1；接著的「一頁式網站適合哪些情況？」「什麼情況不建議只做一頁？」及「一頁式網站範例：四種常見架構」皆為 H2。
這四筆可記「主題＋三個同層章節，標記已觀察」。它們是當次頁面內容，不代表整站、螢幕閱讀器或搜尋表現都通過；本篇沒有修改官網，也沒有量測排名與詢問。讀者重查時若文字變了，就照當日版本記，不把更新直接判成錯誤。
【修正後怎麼驗收】
有編輯權的人，可在自己的草稿頁把正文主標設定為適當的標題層級，再按內容關係設定章節。文字大小另外調整。儲存預覽後重新讀取標記，核對與大綱是否一致；有共用版型時，也要看其他使用該版型的頁面是否受影響。
只在 Elements 改字或標籤，是瀏覽器當下的變動，不能當成網站已保存。沒做正式修改，就把狀態留在「建議待處理」。也不要為了看到一個 H1 就刪掉其他區塊，先確認每個標題的用途與所屬範圍。
預期成果是至少四筆紀錄，附一份內容大綱及待辦。請另一人照網址找到相同文字，核對標記，再說出每節屬於哪個主題；沒請人複核就記自行核對。常見錯誤是只看字體、把檢查到的內層 span 當成全部、混入頁尾標題，以及只查四筆就宣稱完整無障礙合規。
今天的作業：用自己的公開頁完成四欄表；沒有網站，就用上述虛構大綱填預期層級，實際標記填「無頁面，未查」。紙筆與瀏覽器可零額外工具費完成，平台進階編輯、改版及完整稽核可能另有成本；本練習不要求買訂閱。成果是可重查的結構紀錄，不是 SEO 成效保證。
官方來源（2026-10-15 查核）：
https://www.w3.org/WAI/tutorials/page-structure/headings/
https://developer.chrome.com/docs/devtools/dom/
練習頁：抽查主標與前三節的標記
https://kemai-ai.com/blog/one-page-website-guide?utm_source=nabi&utm_medium=community&utm_campaign=nabi_daily&utm_content=20261015_headings
整理／配圖：客脈 AI。配圖為 AI 示意圖，非實際網站或驗證報告。
每張圖都塞關鍵字？先用三種用途決定替代文字
圖片能載入，還要讓讀者理解用途。今天只完成一件事：替同一張圖片在三種位置寫出合適的 alt，並核對網頁實際保存的值。適合自行維護網站的個人、工作室與中小企業；準備瀏覽器、純文字編輯器，以及有權使用的圖片，不需買 SEO 外掛。
【先認識 alt】
alt 是 HTML 圖片元素的替代文字。它跟檔名、滑鼠提示、畫面下方圖說是不同欄位；有圖說，不代表網頁已填 alt。Google 說會把替代文字、頁面內容與影像辨識一起用來理解圖片，也提醒避免塞滿關鍵字。填好文字不保證收錄或排名。
W3C 的圖片決策樹先看用途：傳達資訊的圖片描述相關意義；作為連結或按鈕唯一內容的圖片，說明目的地或動作；純裝飾或已由附近文字完整表達的內容，可使用空替代文字。複雜圖表還需要在頁面提供完整資訊，不能把整張表硬塞進一句 alt。
【用同一張虛構圖片練習】
本篇配圖是 AI 生成的藍色資料夾與白色文件，不是真實文件或客戶照片。同一張圖放在不同位置，答案可以不同。
A 資訊：若文章正在介紹這張圖的畫面，可寫「手指指向桌上的藍色資料夾，夾內露出白色文件；AI 示意圖。」只說可見且對段落有用的內容，不補文件數量、品牌、地點或備份成功等看不出的事實。
B 功能：若整張圖是前往歸檔步驟的唯一入口，可寫「查看文件歸檔步驟」。讀者需要知道按下去做什麼，不能只寫「藍色資料夾」或「點這裡」。若旁邊已有同一連結內的清楚文字，則要連同整個連結一起判斷，避免重複。
C 裝飾／資訊重複：若附近已完整寫出 A 的描述，圖片只重複相同意思，可保留 alt=""。空字串不是刪掉整個屬性；是否適合留空，取決於圖片在當前段落有沒有新增資訊，不能看見圖片漂亮就一律當裝飾。
【照四步做】
1. 先用紙筆畫四欄：「圖片位置／用途／替代文字草案／核對結果」。把 A、B、C 各填一列，寫出留空或不留空的理由。不要先湊關鍵字，再倒推圖片用途。
2. 在自己有權編輯的草稿頁放同一張圖三次，依上述情境設定替代文字。找編輯器的「替代文字／alt」欄，不要誤填標題或說明。沒有這個欄位就先留草稿，詢問維護者；不知道設定在哪裡，不代表正式頁一定缺少 alt。
3. 使用 HTML 的讀者，可在本機另建一頁，把圖片另存 folder.png 放在同一資料夾。放三個 img，src 都設為 folder.png；A 的 alt 填描述，B 的 alt 填「查看文件歸檔步驟」，把 B 包在指向 #steps 的連結內，並給目的標題 id="steps"。C 在完整的畫面描述後放圖，設定 alt=""。保存為 UTF-8 的 demo.html，再用瀏覽器開啟；確認副檔名不是 .html.txt。這是本機教材，不必上傳官網。
4. 儲存並重新開啟草稿，用瀏覽器的「檢查／Inspect」選到實際 img，逐項抄下 alt 的值。A 應保留描述，B 應保留功能文字，C 應看到 alt=""。只在 Elements 暫時改字，不等於已保存到網站；把實際狀態與建議修改分開記。
【今天已核對的範圍】
2026/10/22，我建立本機三情境 HTML，用同一張原創資料夾圖，透過本機 HTTP 在桌面 Chrome 開啟。三張圖均載入；DOM 中 A 為描述、B 為「查看文件歸檔步驟」、C 有 alt 屬性且值為空字串。頁面語意快照可見 A 的圖片名稱及 B 的連結名稱，C 未列為有名稱的圖片。
這只核對本機屬性及快照，沒有測實際螢幕閱讀器、鍵盤操作、全站無障礙或 Google 採用結果，也沒有修改正式網站。不能把本機示範寫成搜尋成效。
【作業、驗收與限制】
交出三列四欄表，附每個位置的段落、草案及保存後實際值。請另一人只讀文字，說出圖片提供什麼資訊，或連結要去哪裡；未請人複核就標自行核對。遇到圖表、圖片內文字或用途不明，回到官方決策樹，不直接套 C。
常見錯誤是每張圖都複製頁面標題、堆地區與推薦詞、把空 alt 當成缺漏，以及只改檔名卻以為已改替代文字。紙筆與本機範例可零額外工具費完成；平台進階設定、人工維護及完整無障礙驗收可能另計，不需買訂閱。
官方文件（2026-10-22 查核）：
https://www.w3.org/WAI/tutorials/images/decision-tree/
https://developers.google.com/search/docs/appearance/google-images
整理／配圖：客脈 AI。配圖為 AI 示意圖，非真實文件、網站畫面或 SEO 成效證明。
ChatGPT生成Apps Script程式碼4技巧！Google Sheets自動化範例用AI加持
想把重複的Google Sheets試算表工作自動化，用ChatGPT就可以快速生出可用的Apps Script程式碼，相較於手動編寫、錄製巨集，使用生成式AI的技術門檻最低！作者分享2個範例，並提醒用AI生成Apps Script程式碼的Prompting技巧。本文節錄自《AI 加持！Google Sheets 超級工作流》。
文／杜昕 Mic Tu
本文目錄（點擊可快速前往）
撰寫Apps Script程式碼的3種方式使用生成式AI生成Apps Script程式碼▶ 範例1：資料統計▶ 範例2：生成圖表用AI生成Apps Script程式碼的Prompting技巧
Google Apps Script（以下簡稱Apps Script）是一個強大的雲端腳本語言，讓使用者能透過類似JavaScript的程式碼整合Google的試算表、文件、簡報、日曆等功能，自動化重複性的工作，完全免費且不需要安裝任何開發環境即可完成。
若要在Google Sheets中使用Apps Script，只要點選「擴充功能 → Apps Script」進入Apps Script的編輯器介面，便能開始撰寫程式。
撰寫Apps Script程式碼的3種方式
撰寫Apps Script程式碼的方式可分成手動編寫、錄製巨集、使用生成式AI 3種，優缺點分別如下：
撰寫方式優點缺點手動編寫完全根據需求客製化程度高。需要花較多的時間學習與實際撰寫。錄製巨集錄製後自動生成程式碼，只需根據需求手動調整即可。錄製的程式碼較基本，複雜的需求可能要大幅的手動調整，因此仍需具備程式基礎。使用生成式AI可直接複製貼上生成的程式碼，大幅提高撰寫效率，也能解決較複雜的案例。撰寫程式碼時會備註各程式碼的用途，可供快速學習。較冷門的需求可能會回答錯誤，若要提升生成品質則會需要訂閱。有時程式碼較冗餘，影響執行效能與可閱讀性。
雖然3種方式皆有優缺點，但使用生成式AI需要的時間、技術門檻最低，因此後續各章節主要會使用ChatGPT生成程式碼，提供輸入的Prompt及對應的輸出。
使用生成式AI生成Apps Script程式碼
本節將使用兩個範例說明如何使用ChatGPT生成程式碼，只要將程式碼複製到Apps Script中並執行函式即可，兩範例的需求、Prompt與ChatGPT (4o mini)生成程式碼如下：
本節範例使用之「會員資料檔」Google Sheets
會員資料檔範例（圖／旗標）
▶ 範例1：資料統計
需求：統計會員資料檔中的會員職業，各職業依會員數多到少排序。
問：生成Apps Script程式碼，統計工作表「會員資料檔」的 E2:E 每個值出現的次數，依次數由高到低輸出到工作表「5.4.3 使用生成式 AI 生成程式碼」的 A:B 中，並將兩欄的標題分別設為「職業」和「會員數」。
ChatGPT輸出結果（以下為作者撰寫時生成之版本，每次生成可能有些許差異，請各位讀者稍加留意）：
▶ 範例2：生成圖表
需求：延續上例，將統計結果繪製成柱狀圖。
問：生成Apps Script程式碼，將工作表「5.4.3 使用生成式AI生成程式碼」的 A2:B 繪製成柱狀圖，兩欄分別為「職業」和「會員數」，並貼上至工作表的 C1 儲存格中。
ChatGPT 輸出結果：
兩範例的最終結果如下圖所示：
（圖／旗標）
用AI生成Apps Script程式碼的Prompting技巧
在撰寫Prompt時要清楚描述需求，以增加生成式AI正確的機率，可以使用以下的Prompting架構增加正確輸出的機率：
問：(1) 生成Apps Script程式碼，(2) 完成以下步驟：1. (3) 將工作表「○○○」的 ○○:○○ 儲存格 (4) 匯總 / 繪製圖表 / 計算...，其中 A / B / C 欄位依序為 △△△ / △△△ / △△△…。2. 將 …3. 將 …，(3) 把最終結果輸出至工作表「○○○」的 ○○ 儲存格。
(1) 在一開始就提及Apps Script，避免AI輸出其他程式語言。
(2) 若要求非常複雜時，建議化為多個步驟，或是分多次Prompt漸進式說明。
(3) 清楚說明資料來源與最終輸出的位置，提及「工作表/儲存格/範圍/欄/列」避免判斷錯誤，並建議用括號標示工作表名稱。
(4) 說明計算過程時可以說明應用場景，但要說明各欄位的名稱，避免判斷錯誤。若欄位的名稱較難判斷資料型態時，可以增加舉例說明。
節錄自：旗標《AI 加持！Google Sheets 超級工作流》／杜昕 Mic Tu 著
推薦閱讀：
AI家教上線！ChatGPT和Gemini學習模式實測4招馬上用
AWS免費課程幫你打造AI「學力」證明，攻搶12萬AI職缺！
除了ChatGPT還有哪些生成式AI？16種AI工具應用解析
用Codex操作Chrome瀏覽器，自動讀Gmail、寫Google Sheet教學！設「3層護欄」防AI亂點亂寄
想讓AI幫忙操作Chrome瀏覽器、讀Gmail、下載附件、寫進Google Sheet，又怕它亂點、亂寄信？作者以教師可能遇到的「自動批改作業信」為例，示範用Codex Chrome Extension設定白名單、二次確認與留痕log三層護欄，再一步步放手讓AI操作瀏覽器。本文節錄自《ChatGPT × Codex全攻略》。
文／曾慶良（阿亮老師）
本文目錄（點擊可快速前往）
動手做前準備清單全章流程地圖：4步由小到大動手實作：讓Codex操作你的Google Chrome動手操作3大禁區
編按：作者以「老師自動批改學生作業信」為範例，示範讓Codex讀取Gmail「作業繳交」標籤的來信、下載附件、產出評語，再逐列寫進Google Sheet。雖然示範情境在教學現場，但換個主題就能套用到職場，例如整理應徵者的履歷信、客戶詢價信或活動報名回覆；文中的白名單、二次確認、留痕log三層護欄，也適用於任何讓AI代操瀏覽器的工作。※本文以「Chrome Extension」模式操作，是由Codex直接在你的Chrome「已登入」的Gmail等分頁操作，不必處理OAuth、API token（這些憑證都不用辦），看得到它在做什麼。
動手做前準備清單
項目規格沒有怎麼辦Codex CLI + 桌面App已完成、能登入補安裝，Codex CLI 、桌面AppChrome Extension從Codex App Plugins內裝補安裝，Chrome extensionGmail帳號有「作業繳交」標籤、收得到信Gmail內建立一個Label「作業繳交」Google Sheet一張空白工作表，欄位先排好Drive內新建一張，命名「本學期_作業批改」
Google Sheet欄位先排好
第一列填入這6個欄位（順序很重要，等下Skill要按這個順序寫入）：
ABCDEF批改日期學生姓名作業主題AI評語字數建議評分
權限設「僅特定人員」或「限校內帳號（你的學校網域）可存取」，把你自己（和真的需要看的同事）逐一加進去。不必也不要用「擁有連結的任何人可檢視」，Codex用你登入的身分操作，本來就進得去，不需要開公開連結。
此表含學生個資（姓名＋評語），絕對不可以用「擁有連結的任何人可檢視/可編輯」公開連結分享。公開連結等於把全班個資丟到網路上任人抓取。務必設成「僅特定人員」或「限校內帳號」，並定期到「共用」設定檢查存取名單有沒有跑進不該有的人。
【補充】企業導入前置（用公司信箱、下載含個資附件前必看）
本章讓Codex操作你「已登入」的信箱、下載附件、寫進Sheet，放在公司環境要先過3關，別自己一個人默默開跑：
公司信箱須經IT /資安核准：使用Codex Extension操作公司Gmail / Workspace前，先問過IT或資安窗口，確認符合公司對第三方工具存取信箱的規範，否則別用個人身分擅自授權公司帳號。
先用測試帳號跑通：第一輪用一個測試信箱＋假資料把流程走順，確認護欄有效，再碰真實信箱。
附件含個資要確認合法性、用完清除：下載的.docx /客戶附件若含個資，先確認你有處理的合法依據（同意/業務必要），處理完就從~/Downloads/inbox-essays/之類暫存夾刪除，別長期堆在本機或同步到公開雲端夾。
全章流程地圖：4步由小到大
1 授權與護欄 Chrome Extension 範圍限定 + 二次確認
↓
2 寫 Skill auto-email-processor 四階段定義
↓
3 跑 1 封測試 盯著看，確認沒亂點
↓
4 放開跑全部 批次處理 + 失敗重試 + 總結報告
絕不可跳過步驟3，跑1封測試看看，這是整章最關鍵的安全閘門。沒看過第1封就放執行，等同把你的Gmail鑰匙交給陌生人。
動手實作：讓Codex操作你的Google Chrome
步驟1-A 授權與三層護欄
確認Codex桌面App已開啟、已登入
確認Chrome已裝Codex Extension
Chrome右上工具列點Codex圖示
看到「Chrome plugin connected」狀態 = 正常
Codex桌面App內的Plugins區也顯示「Chrome plugin connected」，兩邊都看得到 = OK
Codex從這裡開始就有能力「在你登入的Chrome內」做事。所以下一步馬上設範圍限制，沒設好就不要往下做。
步驟1-B 護欄1：範圍限定（白名單）
Codex Extension預設「進入新網站會問」。但更穩的做法是明確設一份白名單。在Codex對話開頭就先宣告：
本對話只允許操作 mail.google.com、docs.google.com、sheets.google.com。
任何其他網域請拒絕並回報給我。
明確列出允許與禁止的清單：
# 允許 Codex 操作的網域白名單
mail.google.com # Gmail
docs.google.com # Google Sheet / Docs
sheets.google.com # Google Sheet（舊網域別名）
# 禁止：其它一律不行
✗ bank.example.com # 銀行
✗ pay.example.com # 支付
✗ facebook.com / x.com # 社群媒體
這是用文字下的範圍限制，搭配Extension預設的「進新網站問一次」雙重防護。
步驟1-C 護欄2：二次確認
在Codex對話開頭就先指定下面五類動作必須先暫停問你，得到「OK」才能繼續：
刪除任何信件 → 必須問
寄出任何信件 → 必須問
移動信件到垃圾桶 → 必須問
修改Sheet既有列（非新增）→ 必須問
修改Gmail filter / forwarding設定 → 必須問
「標記為已讀」、「加標籤」、「下載附件到自己電腦」、「在Sheet新增一列」這幾項算可逆操作，不需要每次都問。
步驟1-D 護欄3：留痕log
叫Codex把它做的每一步寫成log，方便事後抽查：
請建立一個 ~/codex-logs/email-processor.log
每次處理一封信，寫一行 JSON：
{"ts":"2026-05-17T10:00:00Z","subject":"...","sender":"...","action":"已批改寫入Sheet","ok":true}
失敗時 ok:false，多寫 reason 欄位。
請在每次跑完 Skill 後自動 append。
跑完一輪後，cat ~/codex-logs/email-processor.log（Windows PowerShell：Get-Content $HOME\codex-logs\email-processor.log）看得到N行JSON，每行對應一封信。
動手操作3大原則
範圍限定：只開放特定網域，其餘一律拒絕
二次確認：刪/寄/改既有資料必須先問
留痕：每次操作寫log，可事後追查
三個都做到了，才往下進步驟2寫Skill。
步驟2-A 寫auto-email-processor Skill
macOS / Linux（或在Git Bash執行）：
mkdir -p ~/.agents/skills/auto-email-processor
cd ~/.agents/skills/auto-email-processor
touch SKILL.md
Windows PowerShell寫法（同一件事的PowerShell寫法）：
New-Item -ItemType Directory -Force $HOME\.agents\skills\auto-email-processor
Set-Location $HOME\.agents\skills\auto-email-processor
if (-not (Test-Path SKILL.md)) { New-Item -ItemType File SKILL.md }
如果Windows使用者希望直接沿用Bash指令，可以在~/.agents/skills/的上層資料夾右鍵 → Open Git Bash Here，就能在Git Bash內原樣執行mkdir -p、touch。兩個方式擇一即可，不必兩邊都跑。
為什麼用Skill而不是直接打prompt？Skill寫一次、用很久。下次要批改只要說「跑auto-email-processor」，不必再貼整段流程描述。
2026新功能NEW：Record & Replay（錄一次、重播多次）
Skill有3種建立法：
手寫SKILL.md（本節做的）
對話中請Codex幫你生
Record & Replay，你手動把一連串網頁操作（點「作業繳交」標籤 → 過濾未讀 → 下載.docx）錄製一遍，Codex會把它存成可重播的Skill。像Gmail這種步驟固定、重複性高的流程特別適合這種方式，錄完再回頭微調SKILL.md補上護欄。搭配always-allow（總是允許）：把重播時重複跳出來的權限請求（例如每次都問「可以操作mail.google.com嗎」）設為「總是允許」，就不會一直被打斷，但只對白名單網域開always-allow，刪/寄/改既有資料這類敏感動作仍維持二次確認。
步驟2-B SKILL.md開頭：frontmatter與Scope
SKILL.md一定要以YAML frontmatter開頭（name、description是必要欄位，觸發詞寫進description，Codex才會自動觸發）：
---
name: auto-email-processor
description: 讀 Gmail「作業繳交」標籤內的未讀信，抓 .docx 附件，套 essay-feedback Skill 批改，寫回 Google Sheet「本學期_作業批改」。觸發詞：批次批改、處理交作業信、跑 email processor。
---
# auto-email-processor
## Scope
- 允許網域：mail.google.com、docs.google.com、sheets.google.com
- 禁止：其它任何網域
- 允許動作：讀信、下載附件、加標籤、Sheet 新增列
- 禁止動作：刪信、寄信、修改 Sheet 既有列
Skill的「身分證」段落，讓Codex知道「我可以做什麼、不能做什麼」。
步驟2-C 中段：四階段Steps
## Steps
### Phase 1 讀
1. 開新分頁到 https://mail.google.com
2. 點左側「作業繳交」標籤
3. 加「is:unread」過濾條件
4. 列出信件主旨與寄件者，不要點開
### Phase 2 分（過濾）
對每封信，符合所有三條件才處理：
- 寄件者是學生（你的學校網域，例：@school.edu.tw）
- 主旨含「作業」或「homework」
- 有 .docx 附件
### Phase 3 處（批改）
1. 下載 .docx 到 ~/Downloads/inbox-essays/
2. 從寄件者名 / 主旨解析學生姓名與作業主題
3. 呼叫 essay-feedback Skill 批改
4. 把回傳的「評語/ 字數/ 評分」記下來
### Phase 4 記
1. 開 Google Sheet「本學期_作業批改」
2. 新增一列：日期 / 姓名 / 主題 / 評語 / 字數 / 評分
3. 回 Gmail 標該信「已讀」+ 加「已批改」標籤
4. 寫一行 log 到 ~/codex-logs/email-processor.log
【補充】Phase 3那句「呼叫essay-feedback Skill」是哪來的？
這支批改Skill在「多檔案批次處理」篇建立過，該章resources/essay-feedback/有現成檔案，只要將其複製到~/.agents/skills/essay-feedback/就能被本章觸發。還沒建也能先跑通流程，把Phase 3第3步暫時換成這3行替代做法：
用Codex內建能力讀出.docx純文字內容
請Codex直接寫一段150字評語、估算字數、給A / B / C建議評分
把這三個值當成回傳結果往Phase 4傳（先能寫進Sheet，之後再換成正式的essay-feedback）
步驟2-D 末段：Rules護欄
## Rules
### MUST（必須）
- MUST 敏感操作前停下來問我（刪信、寄信、改既有列）
- MUST 處理失敗的信維持「未讀」、加標籤「需人工處理」
- MUST 每處理一封寫 log
- MUST 全程操作我這個帳號，不可切到別人的 Gmail
### NEVER（絕不）
- NEVER 自動回信給學生
- NEVER 跨網域操作（白名單以外）
- NEVER 刪除任何信件
- NEVER 修改 Sheet 既有列（只能 append）
## Tools
- Codex Chrome Extension（Gmail / Sheet 操作）
- Codex 內建 .docx 解析
- essay-feedback Skill（subagent 呼叫，來源見第三篇 CH19）
Skill寫完存檔。Codex下次看到觸發詞會自動讀SKILL.md。
準備測試素材：先讓信箱有東西可讀
Skill寫好了，但如果「作業繳交」標籤裡一封信都沒有，步驟3的測試就沒東西可跑。動手前先花3分鐘，自己造1～2封測試信，讓自動化有真實素材可讀。這步驟做完，跑步驟3才有意義。
準備1～2份.docx測試檔：隨手開Word（或Google Docs →下載為.docx）打一段假作文，存成例如：測試作文_王小明.docx。想更真實就做兩份、換個學生名。
自己寄給自己：在Gmail點「撰寫」，收件者填你自己的Gmail，主旨故意帶關鍵字（例：第八單元作文 作業繳交 王小明，一定要含「作業」讓Phase 2過濾條件吃得到），把剛才的.docx當附件夾進去，寄出。寄1～2封。
建一個標籤：Gmail左側sidebar往下拉找到「建立新標籤」，命名為作業繳交（就用這章Skill要讀的標籤名，別另取，不然Skill讀不到）。若動手前清單那步已經建過，這步跳過。
手動把測試信貼上該標籤：回收件匣，勾選剛剛那1～2封自寄信 → 點上方「標籤」圖示（或右鍵）→ 勾「作業繳交」。現在這個標籤底下就有真實的未讀作業信可供Codex練習了。
【提醒】用「自寄信」當測試素材最安全就算Codex跑歪了、標錯標籤，動到的也只是你自己建立的虛假信件，不會影響到學生真正交的作業。等步驟3測試通過，再放真實信件進來。
步驟3-A 跑1封測試（最關鍵的一步）
進Codex：
codex
輸入：
請執行 auto-email-processor Skill，但這次只處理 1 封測試：
1. 開 Gmail
2. 找到「作業繳交」標籤內第一封符合條件的未讀信
3. 完整跑完 Phase 1-4
4. 跑完後回報你做了什麼（步驟列表、最後 Sheet 寫了哪一列）
整個過程請在我面前跑、不要靜默。
每動一步先告訴我「我準備做 X」，等我說 OK 才執行。
【提醒】請全程盯著螢幕看！不要去泡咖啡、不要切到別的視窗。第一次跑就是要確認「它真的有照規矩來」。
步驟3-B 盯著看的時候要確認什麼？
Codex跑的時候，眼睛確認這6件事：
Codex開的是正確的Gmail標籤（不是收件匣全部）
它沒有點開不該點的信（例如沒有.docx的、或寄件者不是學生的）
下載.docx時沒覆蓋你既有檔案
批改完Sheet新增一列（不是修改既有列）
信件標為「已讀」+ 加「已批改」標籤，沒刪除、沒進垃圾桶
log檔有一行新紀錄
任何一項不對 → 立刻按Esc中止（在CLI內跑則按Ctrl + C）、修SKILL.md、再跑一次測試，不要現在就往步驟4前進。
步驟3-C 第一次跑常見的「走偏」
Q1：Codex點到收件匣不是「作業繳交」標籤
回答：Gmail介面更新時，標籤位置會變動。SKILL.md改成「在左側sidebar用文字找『作業繳交』再點」，不要靠固定位置。
Q2：把作文老師個人信也當成作業處理
回答：Phase 2過濾條件不夠嚴。再加「主旨必須有作業/homework」「附件必須是.docx」雙條件。
Q3：Sheet寫到錯的工作表（同一活頁簿有多張表）
回答：Skill補上「先點底部tab確認是『本學期_作業批改』再寫」。
Q4：標完「已批改」標籤後又標「重要」
回答：Codex在學Gmail介面，可能誤點。Rules補：「只加『已批改』標籤，其他不准動」。
步驟4-A 測試OK了，跑全部未讀
同一個Codex對話內輸入：
很好，剛才測試正確。現在請執行 auto-email-processor Skill
處理「作業繳交」標籤內所有未讀信。
需求：
1. 並行數：1（順序處理，方便我看）
2. 失敗自動重試 1 次
3. 重試仍失敗的信：加標籤「需人工處理」，跳過，繼續下一封
4. 全部跑完給總結報告：成功 N 封 / 需人工 N 封 / 失敗 N 封
5. 列出需人工的信件主旨與寄件者，方便我之後處理
開始。
「並行數1」會比較慢，但安全。等你跑過3-5次都OK再考慮加到2-3並行。
步驟4-B 預期看到的總結報告
✅ auto-email-processor 處理完成
成功批改：23 封
需人工處理：2 封
- 「期中作文.docx 附件損壞」 / 小明 <ming@...>
- 「忘記附檔」 / 阿花 <hua@...>
失敗：0 封
Google Sheet 已新增 23 列
Gmail 標記已讀 + 標籤「已批改」：23 封
標籤「需人工處理」：2 封
log 寫入 ~/codex-logs/email-processor.log：25 行
數字加總 = 標籤內未讀信總數 = Sheet新增 + Gmail標記 = log行數，四個數字對得起來就是完成。
步驟4-C 抽查Sheet內容是否正確
打開「本學期_作業批改」工作表
隨機挑3列，對應到原信件
檢查欄位：日期、姓名、主題、評語、字數、評分都對
檢查AI評語有沒有亂寫（這部分是essay-feedback Skill的責任，但這次順便抽查）
Gmail內隨便開一封看是否標籤「已批改」+「已讀」
看log檔最後幾行有ok:true
6項都對 = 整套流程信任度 +1。下次可以放心多並行、少盯著。
動手操作3大禁區
把這3個禁令寫在便條紙貼在螢幕上：
不操作金融帳戶：銀行、支付、券商、加密貨幣交易所，一律白名單外。不論看起來多簡單的「查餘額」也不行，因為AI沒辦法分辨「查」和「轉」之間只差一個按鈕。
不自動寄信給真人：草稿可以、儲存可以，但按下「寄出」這個動作絕對是你自己按。AI寄錯信沒辦法收回，後果你扛。
不超範圍：Skill寫了什麼就只做什麼。不要在同一個Codex對話「順便叫它做別的事」，授權邊界會模糊掉。要做別的就開新對話、重新設權限。
節錄自：博碩文化《ChatGPT × Codex全攻略：從零基礎到自動化，打造你的AI Agent工作流》／曾慶良（阿亮老師） 著
有任何收穫或想分享的，都來和大家一起聊聊吧！