Automation on kenji.blog

使用 PowerShell 腳本完全自動化每日例行工作的實例

Sun, 13 Sep 2026 06:00:00 +0900

前言：為什麼要使用 PowerShell 自動化工作？

在現代的 IT 基礎設施與開發環境中，對於使用 Windows OS 作為平台的用戶來說，「日常的例行工作」是無法避免的課題。諸如檔案備份、系統日誌監控、開發資源（Git 儲存庫）的更新與建置等，如果以手動方式進行，不僅容易成為人為失誤的溫床，更會導致寶貴時間的浪費。

過去人們經常使用批次檔（.bat 或 .cmd）或 VBScript，但在現今，最佳的解決方案毫無疑問是 PowerShell。PowerShell 不僅僅是個以文字為基礎的 shell，它更是建構於 .NET Framework（以及 .NET Core）強大的物件導向基礎之上。透過管線（Pipeline）傳遞的資料並非「字串」，而是「物件」，因此我們不需要自行實作複雜的文字解析（例如 grep、awk、sed 等處理），只需指定屬性就能輕鬆存取資料。

本文將介紹 3 個與實務直接相關、使用 PowerShell 撰寫的完全自動化腳本實例（備份至 NAS 與日誌輪替、事件日誌監控與 Slack 通知、多個 Git 儲存庫的批次更新與建置）。此外，在介紹這些實例之前，也會針對必要的基礎技術，如 PowerShell 的執行原則、模組化、與工作排程器的整合等，進行深入探討與解說。

建立 PowerShell 自動化的基礎

為了讓自動化腳本能在正式環境中安全且穩定地運作，我們需要做一些事前準備。這裡將詳細說明對執行原則的理解、提高可重複使用性的模組化，以及穩健的錯誤處理（Error Handling）。

1. PowerShell 的執行原則（Execution Policy）

在 Windows 中，為了防止惡意腳本被意外執行，系統預設設定了「執行原則」，在初始狀態下（Restricted）是無法執行任何腳本（.ps1 檔案）的。為了進行自動化，我們需要將其更改為適當的級別。

執行原則包含以下幾種類型：

Restricted: 不允許執行腳本。（預設值）
AllSigned: 僅允許執行由受信任發行者簽署的腳本。
RemoteSigned: 在本機建立的腳本可直接執行，但從網際網路下載的腳本則需要簽章。
Unrestricted: 可以執行所有腳本，但在執行從網際網路下載的腳本時，系統會顯示警告。
Bypass: 不會封鎖任何項目，也不會顯示警告。通常用於暫時性的腳本執行（例如 CI/CD 管線）。

在企業的本機環境中，如果要在工作排程器等工具中執行自製腳本，最務實且安全的設定是 RemoteSigned。請以系統管理員權限啟動 PowerShell，並執行以下指令。

1

Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

設定完成後，您在本機建立的備份腳本等將不會被封鎖，並能順利運作。

2. 透過模組化實作程式碼重複使用（.psm1 / .psd1）

在進行複雜的自動化處理時，從維護性的角度來看，不建議將所有的處理都寫在一個巨大的 .ps1 檔案中。對於常用的函式（例如日誌輸出、傳送 Webhook 至 Slack、錯誤處理等），應該將其分割成「模組」。

PowerShell 模組主要由腳本模組檔（.psm1）與模組資訊清單（.psd1）組成。

CommonUtils.psm1 的範例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


function Write-CustomLog {
 [CmdletBinding()]
 param (
 [Parameter(Mandatory=$true)]
 [string]$Message,

 [ValidateSet('INFO', 'WARNING', 'ERROR')]
 [string]$Level = 'INFO'
 )

 $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
 $logLine = "[$timestamp] [$Level] $Message"

 # 同時執行畫面輸出與檔案輸出
 Write-Host $logLine
 Add-Content -Path "C:\logs\automation.log" -Value $logLine
}

Export-ModuleMember -Function Write-CustomLog

若要在其他腳本中呼叫此模組，請在腳本的開頭使用 Import-Module。

1
2


Import-Module "C:\Scripts\Modules\CommonUtils.psm1"
Write-CustomLog -Message "開始備份處理。" -Level 'INFO'

3. 穩健的錯誤處理（try / catch）

在自動化過程中，最重要的是「失敗時該如何應對」。在 PowerShell 中，透過設定 $ErrorActionPreference 這個內建變數，我們可以控制指令失敗時的預設行為。雖然預設值為 Continue（顯示錯誤並繼續處理），但在自動化腳本中，最佳實踐是將其設定為 Stop，並使用 try / catch 區塊明確地捕捉例外狀況。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$ErrorActionPreference = 'Stop'

try {
 # 可能會失敗的處理
 $content = Get-Content -Path "C:\NonExistentFile.txt"
} catch [System.Management.Automation.ItemNotFoundException] {
 # 捕捉特定的錯誤
 Write-Host "找不到檔案: $($_.Exception.Message)" -ForegroundColor Red
} catch {
 # 捕捉除此之外的所有錯誤
 Write-Host "發生未預期的錯誤: $($_.Exception.Message)" -ForegroundColor Red
} finally {
 # 不論成功或失敗，必定會執行的清理處理
 Write-Host "結束處理。"
}

透過活用這個基礎，即使是在夜間無人值守的情況下運作，也能建立出安全且可追蹤的腳本。

與工作排程器整合（Register-ScheduledTask）

腳本完成後，接下來就需要一個能定期執行該腳本的機制。在 Windows 中，最可靠的就是「工作排程器」。雖然也可以透過 GUI（taskschd.msc）進行設定，但從基礎設施即程式碼（Infrastructure as Code）的觀點出發，我們將解說如何使用 PowerShell Cmdlet 來註冊工作。

PowerShell 提供了 ScheduledTasks 模組，透過使用它，我們可以詳細定義觸發程序（何時執行）、動作（執行什麼）以及主體（以哪個使用者權限執行）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 1. 動作定義（以隱藏方式執行 PowerShell，並傳入指定的腳本）
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File C:\Scripts\DailyTasks.ps1"

# 2. 觸發程序定義（每天上午 3:00 執行）
$trigger = New-ScheduledTaskTrigger -Daily -At "3:00AM"

# 3. 主體（執行使用者權限）定義（以 SYSTEM 權限執行）
$principal = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest

# 4. 建立工作設定
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -DontStopOnIdleEnd

# 5. 註冊工作
$taskName = "MyDailyAutomationTask"
Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -Principal $principal -Settings $settings -Description "自動執行每日例行工作的工作" -Force

只需執行這段腳本，工作就會註冊到工作排程器中，每天在指定時間，系統將以 SYSTEM 權限（在背景不顯示畫面且具有最高權限）自動執行該腳本。

實踐例 1：備份至外部 NAS 與日誌輪替

每日業務資料的備份是不可或缺的，但手動複製絕對不在考慮之列。在這裡，我們將編寫一個腳本，透過 PowerShell 呼叫 Windows 內建最強的複製指令 Robocopy，不僅輸出執行結果的日誌，還能自動刪除（輪替）舊的日誌檔。

網路傳輸執行時間的理論值（Math）

在設計備份腳本時，估算處理完成所需的時間在營運上非常重要。透過網路備份至 NAS 時的預估所需時間 $T_{backup}$，可透過以下公式近似計算：

$$ T_{backup} = \frac{S_{total}}{B \times (1 - \alpha)} + C \times L $$

其中，各變數的意義如下：

$S_{total}$ : 備份目標的總資料量 (Bit)
$B$ : 網路頻寬 (bps，例：1Gbps = $10^9$ bps)
$\alpha$ : 網路或通訊協定的額外負載（通常 TCP/IP 或 SMB 通訊協定為 0.1 ～ 0.2）
$C$ : 檔案總數
$L$ : 每個檔案的處理延遲 (秒)

特別是在備份大量小檔案（如原始碼）時，由檔案數量 $C$ 引起的延遲項 ($C \times L$) 將成為主導因素。因此，在備份處理中，不應使用單純的檔案複製工具，而是應該利用支援多執行緒傳輸的 Robocopy 才是最佳選擇。

備份腳本的處理流程

flowchart TD
A["開始備份腳本"] --> B{"是否可存取 NAS？"}
B -- 是 --> C["執行 Robocopy (多執行緒)"]
B -- 否 --> D["寫入錯誤日誌並退出"]
C --> E{"Robocopy 是否成功？"}
E -- 是 (ExitCode < 8) --> F["輪替日誌 (保留最近 30 天)"]
E -- 否 (ExitCode >= 8) --> D
F --> G["結束備份腳本"]
D --> G

PowerShell 腳本實作範例 (`Backup-ToNas.ps1`)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


$ErrorActionPreference = 'Stop'

# 設定值
$SourceDir = "C:\WorkData"
$TargetNasDir = "\\NAS01\Backup\WorkData"
$LogDir = "C:\Scripts\Logs"
$DateStr = Get-Date -Format "yyyyMMdd"
$LogFile = Join-Path $LogDir "Backup_$DateStr.log"
$RetainDays = 30

try {
 # 1. 事前檢查：是否能存取 NAS
 if (-not (Test-Path $TargetNasDir)) {
 throw "無法存取 NAS 的目標路徑: $TargetNasDir"
 }

 Write-Host "開始備份: $SourceDir -> $TargetNasDir"

 # 2. 執行 Robocopy
 # /MIR : 鏡像（刪除來源端沒有的檔案）
 # /MT:16 : 以 16 個執行緒進行多執行緒複製
 # /NP : 不輸出進度（%）（為了避免日誌變得凌亂）
 # /R:2 /W:2 : 發生錯誤時重試 2 次，等待 2 秒
 $roboArgs = @(
 $SourceDir,
 $TargetNasDir,
 "/MIR",
 "/MT:16",
 "/NP",
 "/R:2",
 "/W:2",
 "/LOG+:$LogFile"
 )

 # 透過 PowerShell 呼叫外部指令時，使用 Start-Process 是最可靠的
 $process = Start-Process -FilePath "robocopy.exe" -ArgumentList $roboArgs -Wait -NoNewWindow -PassThru
 $exitCode = $process.ExitCode

 # Robocopy 的結束代碼規格: 0-7 為成功或符合規格的行為。8 以上為錯誤
 if ($exitCode -ge 8) {
 throw "Robocopy 因錯誤而結束。ExitCode: $exitCode"
 }

 Write-Host "備份順利完成。ExitCode: $exitCode"

 # 3. 日誌輪替
 Write-Host "正在刪除舊的日誌檔（保留期間: ${RetainDays}天）"
 $limitDate = (Get-Date).AddDays(-$RetainDays)
 Get-ChildItem -Path $LogDir -Filter "Backup_*.log" |
 Where-Object { $_.LastWriteTime -lt $limitDate } |
 Remove-Item -Force

 Write-Host "日誌清理完成。"

} catch {
 $errorMessage = "備份處理期間發生錯誤: $($_.Exception.Message)"
 Write-Error $errorMessage
 # 寫入實際的錯誤日誌檔
 Add-Content -Path (Join-Path $LogDir "Error.log") -Value "[(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] $errorMessage"
 # 為了向工作排程器通知錯誤，以非零值結束
 exit 1
}

這個腳本透過與工作排程器結合，實現了每天的完全自動備份。特別要注意的是 Robocopy 的結束代碼處理非常重要。因為即使 Robocopy 執行成功，在「複製了新檔案」時會回傳 1，「刪除了多餘檔案」時會回傳 2，所以如果僅使用 $LASTEXITCODE -eq 0 來判斷，將無法正確運作。

實踐例 2：系統事件日誌監控與 Slack 通知（Webhook）

在 Windows 伺服器或創作者用的工作站中，及早發現可能導致藍白畫面（BSoD）的磁碟錯誤或應用程式崩潰（Application Error）是非常重要的。在這裡，我們將編寫一個腳本，從過去 1 小時的 System 和 Application 事件日誌中，擷取出「錯誤」和「重大」級別的日誌，並在發現時發送通知至 Slack。

通知處理的循序圖

sequenceDiagram
participant S as "工作排程器"
participant P as "PowerShell 腳本"
participant W as "Windows 事件日誌"
participant Sl as "Slack API"
S->>P: "觸發腳本 (每小時)"
P->>W: "Get-WinEvent (過去1小時的 重大/錯誤)"
W-->>P: "回傳日誌物件"
alt "發現錯誤"
P->>P: "格式化訊息 (JSON)"
P->>Sl: "Invoke-RestMethod (POST webhook_url)"
Sl-->>P: "200 OK"
else "無錯誤"
P->>P: "正常結束"
end

PowerShell 腳本實作範例 (`Monitor-EventLog.ps1`)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


$ErrorActionPreference = 'Stop'

# Slack Webhook URL (需事先在 Slack 的 Incoming Webhooks 整合中取得)
$SlackWebhookUrl = "https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXXXXXXX"

# 搜尋目標的時間範圍（過去 1 小時）
$startTime = (Get-Date).AddHours(-1)

# 使用 XPath 過濾器進行高速事件日誌搜尋
# 級別 1: 重大(Critical), 2: 錯誤(Error)
$xmlFilter = @"
<QueryList>
 <Query Id="0" Path="System">
 <Select Path="System">*[System[(Level=1 or Level=2) and TimeCreated[@SystemTime&gt;='$($startTime.ToUniversalTime().ToString("o"))']]]</Select>
 </Query>
 <Query Id="1" Path="Application">
 <Select Path="Application">*[System[(Level=1 or Level=2) and TimeCreated[@SystemTime&gt;='$($startTime.ToUniversalTime().ToString("o"))']]]</Select>
 </Query>
</QueryList>
"@

try {
 # 使用 Get-WinEvent 取得日誌
 # -ErrorAction SilentlyContinue 是為了忽略找不到日誌時的錯誤
 $events = Get-WinEvent -FilterXml $xmlFilter -ErrorAction SilentlyContinue

 if ($events -and $events.Count -gt 0) {
 $eventCount = $events.Count
 Write-Host "過去 1 小時內發現了 $eventCount 筆錯誤/重大日誌。"

 # 組合通知用的文字
 $messageBody = "*Windows 系統警報* :rotating_light:`n"
 $messageBody += "過去 1 小時內偵測到 $eventCount 筆錯誤。`n`n"

 # 僅附上最新 3 筆的詳細資訊（考量到字數限制等）
 $events | Select-Object -First 3 | ForEach-Object {
 $messageBody += "*$($_.LogName)* - $($_.ProviderName) (EventID: $($_.Id))`n"
 $messageBody += "> $($_.Message -replace '`n', ' ')`n`n"
 }

 if ($eventCount -gt 3) {
 $messageBody += "※還有其他 $($eventCount - 3) 筆錯誤。請查看事件檢視器。"
 }

 # 建立要 POST 至 Slack 的 JSON 負載資料 (Payload)
 $payload = @{
 text = $messageBody
 username = "SystemMonitor"
 icon_emoji = ":desktop_computer:"
 }
 $jsonPayload = $payload | ConvertTo-Json -Depth 3

 # 呼叫 REST API 傳送至 Slack
 Invoke-RestMethod -Uri $SlackWebhookUrl -Method Post -Body $jsonPayload -ContentType "application/json; charset=utf-8"

 Write-Host "已完成 Slack 通知。"
 } else {
 Write-Host "未發現錯誤/重大日誌。系統運作正常。"
 }
} catch {
 Write-Error "事件日誌監控腳本發生錯誤: $($_.Exception.Message)"
 exit 1
}

這個腳本在技術上的重點在於使用了 Get-WinEvent -FilterXml。傳統的 Get-EventLog Cmdlet 或透過管線使用 Where-Object 進行過濾的方式，會將所有的事件物件載入記憶體後再進行處理，因此處理過程會變得非常繁重。透過使用 XML 過濾器，過濾工作會交由 Windows 事件日誌服務端執行，因此能將執行時間縮短至幾秒鐘內，帶來壓倒性的效能提升。

實踐例 3：多個 Git 儲存庫的批次更新與建置自動化

對於開發者而言，每天早上第一件事就是將自己工作用 PC 上的多個 Git 儲存庫（如前端、後端、基礎設施儲存庫等）同步至最新的 main 分支，並視需要執行套件安裝（如 npm install）或建置工作，這實在是一件非常繁瑣的事。因此，我們將建立一個使用 PowerShell 腳本來批次完成這些工作的工具。

此腳本會自動偵測特定父目錄下的所有 Git 儲存庫，如果沒有未提交的變更，就會執行 git pull。此外，如果 Pull 了新的變更，它會自動發出建置指令。

多儲存庫自動更新腳本 (`Update-GitRepos.ps1`)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89


$ErrorActionPreference = 'Stop'

# 放置儲存庫的父目錄清單
$TargetDirectories = @(
 "C:\Dev\FrontendProjects",
 "C:\Dev\BackendProjects"
)

# 探索各個目錄
foreach ($parentDir in $TargetDirectories) {
 if (-not (Test-Path $parentDir)) {
 Write-Warning "找不到目錄: $parentDir"
 continue
 }

 # 取得子目錄清單
 $subDirs = Get-ChildItem -Path $parentDir -Directory

 foreach ($repoDir in $subDirs) {
 $repoPath = $repoDir.FullName
 $gitDir = Join-Path $repoPath ".git"

 # 檢查 .git 資料夾是否存在（確認是否為 Git 儲存庫）
 if (Test-Path $gitDir) {
 Write-Host "---------------------------------"
 Write-Host "正在處理儲存庫: $repoPath" -ForegroundColor Cyan

 # 變更 PowerShell 的目前工作目錄
 Set-Location -Path $repoPath

 try {
 # 檢查是否有未提交的變更
 $status = git status --porcelain
 if ($status) {
 Write-Host "由於存在未提交的變更，跳過此儲存庫。" -ForegroundColor Yellow
 continue
 }

 # 取得目前分支
 $branch = git rev-parse --abbrev-ref HEAD
 if ($branch -ne "main" -and $branch -ne "master") {
 Write-Host "目前分支為 $branch ，因此跳過 (僅針對 main/master)。" -ForegroundColor Yellow
 continue
 }

 # 執行 Pull，並將結果儲存至變數中
 Write-Host "正在從遠端取得最新變更 (git pull)..."
 $pullResult = git pull origin $branch 2>&1

 # 同時輸出到主控台
 $pullResult | ForEach-Object { Write-Host " $_" }

 # 如果不包含 "Already up to date." 字串，則視為有更新
 $isUpdated = $false
 foreach ($line in $pullResult) {
 if ($line -notmatch "Already up to date") {
 $isUpdated = $true
 break
 }
 }

 if ($isUpdated) {
 Write-Host "儲存庫已更新。開始執行建置任務..." -ForegroundColor Green

 # 如果有 package.json，則執行 npm install 和 npm run build
 if (Test-Path "package.json") {
 Write-Host "正在執行 npm install..."
 npm install
 Write-Host "正在執行 npm run build..."
 npm run build
 }

 # 如果有 .sln (Visual Studio Solution)，則執行 msbuild 或 dotnet build
 $slnFiles = Get-ChildItem -Filter "*.sln"
 if ($slnFiles.Count -gt 0) {
 Write-Host "正在建置 .NET 應用程式..."
 dotnet build $slnFiles[0].FullName
 }
 }

 } catch {
 Write-Error "處理儲存庫 $repoPath 時發生錯誤: $($_.Exception.Message)"
 }
 }
 }
}

Write-Host "---------------------------------"
Write-Host "所有儲存庫的更新處理已完成。" -ForegroundColor Green

這個腳本在設計上，即使發生錯誤，也能透過 try / catch 和 foreach 迴圈繼續執行，而不會影響到下一個儲存庫的處理。此外，它利用了針對腳本處理設計的 git status --porcelain 選項，能確實判定工作樹（Working Tree）的乾淨程度。只要將此腳本放置在啟動資料夾中，或是註冊為使用者登入時執行的工作排程，當您開啟 PC 並去沖杯咖啡的空檔，所有的開發環境就能自動更新到最新狀態了。

營運上的注意事項與進階技巧

在長期營運使用 PowerShell 編寫的自動化腳本時，有一些需要注意的最佳實踐。

1. 認證資訊的安全管理

在腳本中以純文字硬編碼密碼或 API 金鑰（例如：Slack Webhook URL、資料庫連線字串），是個極大的安全風險。PowerShell 具備了如 Export-Clixml 和 ConvertFrom-SecureString 等將認證資訊加密並儲存的功能。

1
2
3
4
5
6


# 僅第一次需要手動執行（會顯示密碼輸入對話框）
# Get-Credential | Export-Clixml -Path "C:\Scripts\Creds\admin.xml"

# 在自動化腳本中讀取
$cred = Import-Clixml -Path "C:\Scripts\Creds\admin.xml"
# 使用 $cred 進行遠端伺服器連線等操作

透過這樣的方式，就能實現安全地處理認證資訊，且這些資訊僅能在執行腳本之使用者的設定檔中被解密。

2. 透過轉錄（Transcript）完整記錄執行日誌

在前面的例子中，我們使用了 Add-Content 等指令個別輸出日誌，不過 PowerShell 擁有一個轉錄功能，可以自動將畫面上輸出的所有資訊（包含錯誤訊息與標準輸出）寫入到檔案中。

只要在腳本的開頭和結尾加入以下內容，就能建立強大的稽核日誌。

1
2
3
4
5


Start-Transcript -Path "C:\Scripts\Logs\Execution_$(Get-Date -Format 'yyyyMMdd_HHmmss').log" -Append

# （在此處放入腳本主體的處理）

Stop-Transcript

3. 監控的數學方法與異常偵測 (Math)

在大規模的自動化中，不僅是單純偵測錯誤，透過統計方法偵測「與平時不同」的狀況也非常有效。例如，如果每天的備份時間與平時的平均值出現極端偏差，這可能幾是網路異常或磁碟故障的前兆。

假設每天的備份時間為 $x_1, x_2, \dots, x_n$，那麼樣本平均數 $\mu$ 與標準差 $\sigma$ 即可透過以下方式求得。

$$ \mu = \frac{1}{n} \sum_{i=1}^n x_i $$$$ \sigma = \sqrt{ \frac{1}{n-1} \sum_{i=1}^n (x_i - \mu)^2 } $$

如果當天的執行時間 $x_{today}$ 超過了 $\mu + 3\sigma$（三標準差法則），系統就會將其視為「發生了統計上的異常」，我們甚至可以編寫出能發出警告通知的邏輯。只要活用 PowerShell 的 Measure-Object Cmdlet，這種統計處理只需幾行程式碼就能實作完成。

總結

本文結合了實際範例，針對在 Windows 環境下利用 PowerShell 實現例行工作完全自動化進行了解說。從執行原則的管理與模組化的基礎建立開始，介紹了備份與日誌輪替、事件日誌監控與 Slack 通知，以及多個 Git 儲存庫的自動建置等，能夠在實務上立刻派上用場的腳本。

PowerShell 是一門非常深奧的學問，它雖然是命令列工具，卻是一個能存取幾乎所有 .NET 功能的強大自動化引擎。希望大家能以這次介紹的腳本為基礎，配合自身的業務環境來客製化路徑與處理邏輯，讓自己從繁瑣的手動作業中解放，贏得更多具有創造力的時間。

自動化成功的關鍵在於「從小型腳本開始，並逐步提高錯誤處理與日誌輸出等穩健性」。不妨先從備份自己 PC 裡的一個資料夾開始，展開您的 PowerShell 自動化之旅吧。

PowerShell與C++的整合：系統管理的自動化技巧

Sat, 12 Sep 2026 16:00:00 +0900

簡介

在Windows的系統管理與自動化中，PowerShell已成為事實上的標準工具。無論是Active Directory管理、檔案系統操作或是網路設定變更，幾乎所有任務都可以透過腳本撰寫。然而，雖然PowerShell萬能，但在面對腳本語言特有的效能瓶頸，或是需要存取非常底層的Windows API時，仍會感到吃力。

此時，「與C++整合」便是強而有力的解決方案。C++提供了原生的執行速度，以及對Win32 API和COM物件的完整存取能力。將PowerShell的「高生產力與彈性」和C++的「壓倒性效能與底層控制」結合起來，就能夠最佳化企業環境中極度複雜且大規模的系統管理任務。

本文將針對PowerShell與C++雙向整合的具體架構、實作手法，以及記憶體管理和字串轉換的最佳實踐，進行非常詳細的解說。

為什麼要讓PowerShell與C++整合？

1. 突破效能極限

PowerShell是在.NET Framework（或.NET Core / .NET）上運作，具有直譯式、動態型別的語言特性。因此，在進行大量文字處理、複雜的加密運算，或是解析數百萬行事件記錄檔時，執行速度與記憶體消耗往往會成為瓶頸。

讓我們來思考一下運算量與處理時間的模型。假設整體任務的處理時間為 $T_{total}$，那麼單獨使用PowerShell處理與卸載給C++處理的時間可公式化如下：

$$ T_{total}^{(PS)} = N \times (t_{overhead} + t_{compute}^{(PS)}) $$$$ T_{total}^{(C++)} = t_{interop} + N \times t_{compute}^{(C++)} $$

其中，$N$ 為處理的元素數量，$t_{overhead}$ 是PowerShell迴圈處理伴隨的負擔，$t_{compute}$ 是每個元素的純粹計算時間，$t_{interop}$ 則是透過P/Invoke等邊界呼叫所產生的負擔。

當 $N$ 足夠大時，由於 $t_{overhead} \gg 0$ 且 $t_{compute}^{(PS)} > t_{compute}^{(C++)}$，即使需要付出初期的 $t_{interop}$ 成本，將處理委派（卸載）給C++依然能大幅降低整體的延遲。

2. 存取原生的Win32 API

雖然PowerShell單獨也能透過 Add-Type 經由C#呼叫Win32 API，但要直接用C# / PowerShell定義伴隨複雜結構體或回呼函數的API（例如：Mini-filter驅動程式的控制、進階程序記憶體操作）非常困難。透過建立由C++封裝的原生DLL，再由PowerShell呼叫，就能實現型別安全且可靠的系統控制。

從PowerShell呼叫C++原生DLL

最常見的整合模式，是將繁重或系統特有的處理實作為C++的DLL，並從PowerShell腳本中呼叫它。

C++端的DLL實作 (Win32 API與自訂邏輯)

首先，我們建立一個包含可供PowerShell呼叫之匯出函數的C++ DLL。在此提供一段簡單的C++程式碼作為範例，模擬「處理大規模字串資料的加密、解密，或複雜雜湊計算的函數」。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


// NativeLib.cpp
#include <windows.h>
#include <string>

// 為了方便P/Invoke呼叫，指定C語言連結與__stdcall
extern "C" {

 __declspec(dllexport) int __stdcall ComputeHeavyTask(int multiplier, int dataSize) {
 int result = 0;
 // 刻意模擬繁重的處理
 for (int i = 0; i < dataSize; ++i) {
 result += (i % multiplier);
 }
 return result;
 }

 // 處理字串的函數（為支援Unicode，使用LPWSTR）
 __declspec(dllexport) bool __stdcall ProcessSystemString(LPCWSTR inputString, LPWSTR outputBuffer, int bufferSize) {
 if (inputString == nullptr || outputBuffer == nullptr) {
 return false;
 }

 std::wstring str(inputString);
 // 某種複雜的字串處理（例如：加上系統識別碼）
 std::wstring result = L"PROCESSED_" + str;

 if (result.length() >= (size_t)bufferSize) {
 return false; // 防止緩衝區溢位
 }

 wcscpy_s(outputBuffer, bufferSize, result.c_str());
 return true;
 }
}

記憶體管理與字串轉換 (`BSTR`, `LPWSTR`)

在C++與PowerShell（.NET）之間傳遞資料時，最需要注意的是字串編碼與記憶體管理。

LPCWSTR / LPWSTR：C/C++的寬字串指標（UTF-16LE）。在Windows API的 W 系列函數中為標準用法。在P/Invoke中指定 CharSet = CharSet.Unicode，就會自動與.NET的 String 或 StringBuilder 進行封送處理。
BSTR：在COM（Component Object Model）中使用的帶有長度前綴的寬字串。必須使用 SysAllocString 與 SysFreeString 來管理記憶體。在P/Invoke中須指定 [MarshalAs(UnmanagedType.BStr)]。

當C++端配置新的記憶體並回傳給PowerShell端時，會面臨由誰來釋放記憶體（所有權）的問題。在上述的 ProcessSystemString 函數中，採用了Win32 API的標準模式：「呼叫方（PowerShell）預先配置緩衝區（outputBuffer），再由C++將結果寫入其中」。這麼做可有效防止記憶體洩漏。

PowerShell端的 `Add-Type` 與 P/Invoke

編譯好C++的DLL（NativeLib.dll）後，就能從PowerShell腳本呼叫它。透過 Add-Type 動態編譯C#的P/Invoke簽章並加以利用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


# PowerShell Script: Invoke-NativeDLL.ps1

$signature = @'
using System;
using System.Runtime.InteropServices;
using System.Text;

public class NativeInterop
{
 // 定義C++的 ComputeHeavyTask
 [DllImport("NativeLib.dll", CallingConvention = CallingConvention.StdCall)]
 public static extern int ComputeHeavyTask(int multiplier, int dataSize);

 // 定義C++的 ProcessSystemString
 [DllImport("NativeLib.dll", CharSet = CharSet.Unicode, CallingConvention = CallingConvention.StdCall)]
 public static extern bool ProcessSystemString(string inputString, StringBuilder outputBuffer, int bufferSize);
}
'@

# 將C#程式碼編譯並加入至PowerShell工作階段
Add-Type -TypeDefinition $signature -PassThru | Out-Null

# 1. 呼叫繁重的數值計算
$result = [NativeInterop]::ComputeHeavyTask(7, 100000000)
Write-Host "Compute Task Result: $result"

# 2. 呼叫字串處理
$input = "SYSTEM_NODE_001"
$bufferSize = 256
# 使用 StringBuilder 作為讓C++端寫入資料的緩衝區
$outputBuffer = New-Object System.Text.StringBuilder -ArgumentList $bufferSize

$success = [NativeInterop]::ProcessSystemString($input, $outputBuffer, $bufferSize)

if ($success) {
 Write-Host "Processed String: $($outputBuffer.ToString())"
} else {
 Write-Host "String processing failed." -ForegroundColor Red
}

架構視覺化

以下的循序圖展示了從PowerShell呼叫C++ DLL的流程與記憶體傳遞方式。

sequenceDiagram
participant PS as "PowerShell腳本"
participant CLR as ".NET CLR (P/Invoke)"
participant CPP as "C++原生DLL"
PS->>CLR: "呼叫 ProcessSystemString"
note right of CLR: "將 System.String 封送處理為 LPCWSTR"
note right of CLR: "傳遞 StringBuilder 參考"
CLR->>CPP: "ProcessSystemString(LPCWSTR, LPWSTR, int)"
CPP->>CPP: "執行原生字串操作"
CPP->>CPP: "將結果寫入 LPWSTR 緩衝區"
CPP-->>CLR: "回傳 bool (成功)"
note left of CLR: "讀取修改後的 StringBuilder 緩衝區"
CLR-->>PS: "回傳執行控制權"
PS->>PS: "輸出處理後的字串"

從C++呼叫PowerShell

接下來是反向的作法。有時我們可能會想要從C++打造的系統服務或桌面應用程式中，動態執行PowerShell腳本並取得結果。例如，當C++的監控代理程式偵測到特定異常時，執行PowerShell修復腳本的情境。

主要有兩種作法：

程序啟動（CreateProcess / _popen）：作為獨立程序啟動 powershell.exe，並透過管線（Pipe）連接標準輸入/輸出。
PowerShell Hosting API（透過C++/CLI）：在同一個程序內代管PowerShell執行階段的方法。

本文將針對在系統程式設計中最為穩健且通用的使用管線搭配CreateProcess之手法進行解說。

透過CreateProcess與匿名管線執行

以下的C++程式碼建立了匿名管線（Anonymous Pipes），並將 powershell.exe 作為子程序啟動以執行腳本，最後從標準輸出讀取結果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


#include <windows.h>
#include <iostream>
#include <string>
#include <vector>

std::string ExecutePowerShellScript(const std::string& script) {
 HANDLE hReadPipe, hWritePipe;
 SECURITY_ATTRIBUTES sa;
 sa.nLength = sizeof(SECURITY_ATTRIBUTES);
 sa.bInheritHandle = TRUE; // 讓子程序繼承管線控制代碼
 sa.lpSecurityDescriptor = NULL;

 // 1. 建立管線
 if (!CreatePipe(&hReadPipe, &hWritePipe, &sa, 0)) {
 return "Error: CreatePipe failed.";
 }

 // 2. 設定子程序（PowerShell）的啟動資訊
 STARTUPINFOA si;
 ZeroMemory(&si, sizeof(STARTUPINFOA));
 si.cb = sizeof(STARTUPINFOA);
 si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
 si.hStdOutput = hWritePipe;
 si.hStdError = hWritePipe;
 si.wShowWindow = SW_HIDE; // 隱藏視窗

 PROCESS_INFORMATION pi;
 ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));

 // 建構命令列 (為避開Bypass原則的Base64編碼等簡化版)
 std::string cmd = "powershell.exe -NoProfile -NonInteractive -Command \"" + script + "\"";
 std::vector<char> cmdBuffer(cmd.begin(), cmd.end());
 cmdBuffer.push_back('\0');

 // 3. 建立程序
 if (!CreateProcessA(NULL, cmdBuffer.data(), NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi)) {
 CloseHandle(hReadPipe);
 CloseHandle(hWritePipe);
 return "Error: CreateProcess failed.";
 }

 // 在父程序端不需要寫入管線因此關閉（若不關閉會導致Read阻塞）
 CloseHandle(hWritePipe);

 // 4. 讀取結果
 std::string output = "";
 DWORD bytesRead;
 char buffer[4096];

 while (ReadFile(hReadPipe, buffer, sizeof(buffer) - 1, &bytesRead, NULL) && bytesRead > 0) {
 buffer[bytesRead] = '\0';
 output += buffer;
 }

 // 5. 清理資源
 WaitForSingleObject(pi.hProcess, INFINITE);
 CloseHandle(pi.hProcess);
 CloseHandle(pi.hThread);
 CloseHandle(hReadPipe);

 return output;
}

int main() {
 // 取得程序列表並依照CPU使用率降冪排序，取出前5名的PowerShell命令
 std::string psCommand = "Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 | Format-Table Name, CPU, Id";

 std::cout << "Executing PowerShell from C++..." << std::endl;
 std::string result = ExecutePowerShellScript(psCommand);

 std::cout << "Result:\n" << result << std::endl;
 return 0;
}

Windows登錄檔與PowerShell的整合

在從C++執行腳本時，應避免將動態設定值或執行路徑寫死（hardcode）。在多數情況下，C++應用程式會從Windows登錄檔讀取設定。

在企業系統中，較偏好的架構是在C++端使用 RegOpenKeyEx 與 RegQueryValueEx 從 HKLM\SOFTWARE\MyApp 取得PowerShell腳本的路徑，並將其作為參數傳遞給上述的 CreateProcess。

flowchart TD
A["C++代理服務"] -->|RegQueryValueEx| B["Windows登錄檔"]
B -->|Return Script Path| A
A -->|CreateProcess| C["powershell.exe"]
C -->|Execute| D["管理員腳本 (例如：Restart-Service)"]
D -->|stdout via Pipe| C
C -->|ReadFile| A
A -->|Log| E["事件檢視器 / 記錄檔"]

效能分析與卸載的優勢

為什麼要採用這麼複雜的架構呢？作為具體情境，我們考慮「解析高達數GB的自訂IIS記錄檔」。

若使用PowerShell的 Get-Content 並透過正規表示式逐行解析，由於產生物件與記憶體回收（GC）的負擔，將會消耗大量的CPU時間。

在腳本執行中，記憶體配置次數 $A$ 與GC觸發次數 $G$ 的關係如下式成正比：

$$ G \propto \sum_{i=1}^{N} A_i $$

若將處理移交給C++原生程式碼，可使用記憶體對應（CreateFileMapping, MapViewOfFile）將整個檔案直接展開於記憶體中，並藉由指標運算以零拷貝（Zero-copy）的方式進行字串搜尋。在這種情況下，產生物件的負擔實質上降為零，解析工作能以接近理論記憶體頻寬上限的速度完成。

只要將解析結果（例如：未經授權存取的IP位址清單等）回傳給PowerShell端，P/Invoke的封送處理成本也能降至最低。

實用的系統管理自動化情境

情境1：高速檔案系統掃描與權限變更

在大規模檔案伺服器中，萃取出具備特定副檔名且設定了特定ACL（存取控制清單）的檔案，並批次變更其權限的任務。

C++的角色：使用 FindFirstFile / FindNextFile 與多執行緒極速走訪目錄樹，產生符合條件的檔案路徑清單。
PowerShell的角色：針對從C++接收到的清單，使用 Set-Acl 批次套用權限（或是與Active Directory整合的處理）。

情境2：收集自訂的硬體資訊

監控無法透過WMI（Windows Management Instrumentation）或CIM（Common Information Model）取得資訊的自訂硬體裝置（例如：特殊的PCIe卡或感測器）。

C++的角色：向裝置驅動程式發出 DeviceIoControl 呼叫，負責取得並解析二進位資料的DLL。
PowerShell的角色：定期呼叫DLL，將解析結果格式化為JSON並傳送至監控伺服器的REST API。

記憶體管理與疑難排解的最佳實踐

在整合時最常發生的Bug為記憶體洩漏與存取違規（Access Violation: 0xC0000005）。

指標的有效期間：當從PowerShell端傳遞 [ref] 或 StringBuilder 時，P/Invoke僅會在呼叫期間固定（Pin）該記憶體。切勿在C++端將該指標儲存至全域變數，並在日後存取。若需進行非同步回呼，必須使用 GCHandle 明確固定記憶體。
64位元環境的指標大小：現代的Windows基本上皆為64位元（x64）。C++端的指標大小為8位元組，而PowerShell（.NET）端必須使用 IntPtr。由於Windows中C++的 long 為4位元組，將指標強制轉型為 long 來傳遞等老舊程式碼寫法將成為崩潰的主因。
字串編碼不一致：PowerShell內部使用UTF-16。若C++端試圖以ANSI字串（std::string, char*）接收，將會發生亂碼。請務必使用寬字串（std::wstring, wchar_t*），並在P/Invoke端指定 CharSet = CharSet.Unicode。

總結

在系統管理自動化中，PowerShell與C++的整合是能同時兼顧腳本語言的便利性與原生語言之威力的最強組合。

透過P/Invoke呼叫C++ DLL，可卸載高運算負載的任務，大幅縮短執行時間。反之，從C++應用程式透過程序啟動或管線運用PowerShell豐富的系統管理模組，也能大幅降低開發成本。

雖然需要特別注意邊界區塊的記憶體管理與字串轉換，但只要掌握本文所介紹的架構模式與實作技巧，就能夠建構出更進階、穩健的Windows系統管理工具。

在本技術部落格中，未來也將持續探討有關Windows內部結構與進階自動化的深入主題。如有任何問題或回饋，歡迎在留言區與我們分享。

工程師為了增加技術部落格月流量應該做的事

Sat, 12 Sep 2026 12:00:00 +0900

前言：正因為是工程師才能做到的技術部落格成長駭客

許多軟體工程師都會開設技術部落格，但能聚集一定瀏覽量，並長期間維持與擴大流量的例子卻不多。寫出高品質的技術文章是大前提，但「只要寫出好文章自然就會有人看」的時代已經結束了。現在的搜尋引擎演算法變得非常複雜，而且社群網路上的資訊流動速度也比以往任何時候都要快。

然而，工程師擁有其他職位所沒有的優勢。那就是「理解系統架構、能組合工具進行自動化、能用程式分析數據」。本文將不只停留在單純的寫作技巧，而是將技術部落格視為一個「產品」，極度詳細且實踐性地解說如何利用工程能力來大幅提升月流量的策略。

1. 面向工程師的技術部落格SEO架構

作為部落格基礎的系統（如靜態網站生成器）和HTML結構，是搜尋引擎正確理解內容的最重要項目。

1.1 Core Web Vitals 的最佳化

Google 採用頁面體驗作為排名因素，特別是 Core Web Vitals (LCP, FID/INP, CLS) 在技術部落格中也無法忽視。技術部落格經常大量使用原始碼區塊、數學公式（MathJax / KaTeX）和圖解圖片。這些都會成為延遲頁面渲染的因素。

LCP (Largest Contentful Paint): 首屏主要內容的載入速度。主視覺圖片應使用 WebP 或 AVIF，並加上 fetchpriority="high" 屬性進行預載入。此外，用於語法標明的巨大 CSS 或 JS 應設計為非同步載入，或僅在需要的頁面載入。
CLS (Cumulative Layout Shift): 文章載入過程中的版面偏移。透過 CSS 的 aspect-ratio 等預先保留數學公式和圖片的顯示區域，可以防止後續 DOM 插入時造成的畫面跳動。
INP (Interaction to Next Paint): 對使用者操作的響應性。繁重的 JavaScript（例如客戶端的動態全文檢索或巨大的 Markdown 解析器執行等）不應在主執行緒上執行，必須轉移到 Web Worker，或者在建置時生成靜態 HTML (SSG)。

1.2 結構化資料（JSON-LD）的實作

為了明確地告訴搜尋引擎頁面是「文章」，作者是「誰」，需要實作 JSON-LD 格式的結構化資料。活用 TechArticle 或 SoftwareSourceCode 等 Schema，可以更容易顯示在 Google 的複合式搜尋結果中，從而提升 CTR（點閱率）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "TechArticle",
 "headline": "工程師為了增加技術部落格月流量應該做的事",
 "image": [
 "https://example.com/img/eyecatch.jpg"
 ],
 "datePublished": "2026-09-14T10:00:00+09:00",
 "author": {
 "@type": "Person",
 "name": "Kenji",
 "url": "https://example.com/about/"
 },
 "publisher": {
 "@type": "Organization",
 "name": "Kenji's Tech Blog",
 "logo": {
 "@type": "ImageObject",
 "url": "https://example.com/img/logo.png"
 }
 }
}
</script>

1.3 語意化HTML與文件結構的最佳化

標題（h1〜h6）的適當嵌套是基本中的基本，但在技術部落格中會被要求正確使用 HTML5 的語意標籤，如 article, section, aside, nav。此外，透過適當區分表示原始碼的 <code> 和 <pre>、表示鍵盤輸入的 <kbd>、表示變數的 <var> 等，可以提供機器可讀 (machine-readable) 的 HTML。這對於 AI 的內容索引（LLM 的學習資料收集或 RAG 系統）也是非常有效的手段。

2. 搜尋意圖（Search Intent）的心理學與關鍵字策略

要最大化來自搜尋引擎的流量（自然流量），必須準確解讀使用者「為什麼用那個關鍵字搜尋」的搜尋意圖。技術相關的搜尋意圖大致可分為兩類。

2.1 「錯誤解決型」與「系統性學習・評論型」

錯誤解決型（Troubleshooting Intent）
- 搜尋關鍵字範例: Docker "no space left on device" 解決方案, Python IndexError list index out of range 原因
- 心理: 因為開發中的錯誤而卡住，現在立刻需要能作為特效藥的指令或程式碼片段。
- 策略: 在文章開頭（首屏）提示「結論（解決用的程式碼或指令）」。背景和詳細機制的解說放在後面，首先滿足使用者「想立刻修好」的渴望。這樣可以降低跳出率（Bounce Rate）。
系統性學習・評論型（Learning & Review Intent）
- 搜尋關鍵字範例: React vs Vue 2026 比較, Rust 非同步處理入門, GCP 網路架構設計
- 心理: 想選擇新的技術堆疊，或想從基礎加深理解，已經準備好花時間閱讀。
- 策略: 充實目錄（TOC），大量使用圖解或架構圖（如 Mermaid 等）。客觀比較優缺點，並包含在實際業務中如何使用的案例，可以延長停留時間。

2.2 流量的指數衰減模型與長尾策略

技術文章的瀏覽量，通常在公開後會因為在 SNS 等被瘋傳而形成高峰（Spike），隨後呈現指數型減少的趨勢。這個流量 $V(t)$ 可以用以下數學模型來近似：

$$ V(t) = V_0 e^{-\lambda t} + C $$

這裡的：

$V(t)$: 時間 $t$ 的流量
$V_0$: 公開後因 SNS 瘋傳等造成的初期流量高峰值
$\lambda$: 伴隨內容過時或 SNS 上被遺忘的衰減常數（取決於技術趨勢變化的速度）
$C$: 來自搜尋引擎的穩定自然搜尋流量（基準線流量）

要長期提升流量的關鍵，與其瞄準短暫的爆紅（$V_0$），不如將重點放在如何將常數項 $C$（來自搜尋引擎的持續流量）最大化。涵蓋大量像特定的小眾錯誤、或是特定工具之間的串接方法等，即使搜尋量少但沒有競爭對手的「長尾關鍵字」，來將 $C$ 的總和培育成巨大的流量。

3. 使用 Google Search Console API 的數據驅動內容分析

為了建構穩定的流量基礎 $C$，必須活用 Google Search Console (GSC) 的數據，客觀地分析「被 Google 給予了什麼樣的評價」。然而，在 GSC 的 Web UI 上點擊操作是有極限的。如果是工程師，就用 GSC API 和 Python 將分析自動化吧。

3.1 GSC API 與 Python 的自動化方法

建立一個腳本，自動偵測特定文章的搜尋排名是如何隨時間下降的（Decaying Content），或者顯示次數（曝光）很多但點閱率（CTR）卻異常低「很可惜的文章」。這會使用到 google-api-python-client 和 pandas。

3.2 Python 實作程式碼：自動萃取 CTR 下降的內容

以下腳本範例是從 API 取得過去 30 天的搜尋成效數據，並萃取出顯示次數 1000 次以上且 CTR 在 2% 以下的「標題或描述有很大改善空間的關鍵字與文章 URL」。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import pandas as pd
from google.oauth2 import service_account
from googleapiclient.discovery import build
import datetime

# 1. 認證與建立 API 服務
KEY_FILE_LOCATION = 'path/to/your-service-account-key.json'
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SITE_URL = 'https://your-tech-blog.com/'

credentials = service_account.Credentials.from_service_account_file(
 KEY_FILE_LOCATION, scopes=SCOPES)
webmasters_service = build('searchconsole', 'v1', credentials=credentials)

# 2. 計算請求期間（過去 30 天）
today = datetime.date.today()
end_date = (today - datetime.timedelta(days=2)).strftime('%Y-%m-%d')
start_date = (today - datetime.timedelta(days=32)).strftime('%Y-%m-%d')

# 3. 執行 API 請求
request = {
 'startDate': start_date,
 'endDate': end_date,
 'dimensions': ['query', 'page'],
 'rowLimit': 5000
}

response = webmasters_service.searchanalytics().query(
 siteUrl=SITE_URL, body=request).execute()

# 4. 使用 Pandas DataFrame 進行資料處理與過濾
if 'rows' in response:
 rows = response['rows']
 data = []
 for row in rows:
 data.append({
 'Query': row['keys'][0],
 'URL': row['keys'][1],
 'Clicks': row['clicks'],
 'Impressions': row['impressions'],
 'CTR': row['ctr'],
 'Position': row['position']
 })

 df = pd.DataFrame(data)

 # 過濾條件: 曝光次數 1000 以上 且 CTR 低於 2%
 target_df = df[(df['Impressions'] >= 1000) & (df['CTR'] < 0.02)]

 # 依照排名升冪排序（優先處理排名高卻沒有被點擊的項目）
 target_df = target_df.sort_values(by='Position', ascending=True)

 print("【建議修改標題/Meta Description 的清單】")
 print(target_df.head(10))

 # 根據需求輸出 CSV 等
 # target_df.to_csv('improve_candidates.csv', index=False)
else:
 print("找不到數據。")

透過 cron 或 GitHub Actions 的定期任務來執行這個腳本，就能持續以數據驅動來決定「應該重寫哪篇文章的標題」。不依賴直覺，而是基於數據的持續改善（不是 CI/CD 而是 Continuous Content Improvement）是非常重要的。

4. 文章的生命週期管理與重寫策略

技術文章不是發布了就結束了。隨著技術的演進（框架的版號升級、API 的棄用等），內容很快就會過時。持續提供舊資訊不僅會損害部落格的信譽，在 SEO 上也會獲得負面評價。

4.1 內容・生命週期管理（甘特圖）

用 Mermaid 甘特圖來展示理想的內容營運生命週期。

gantt
title 數據驅動型內容・生命週期管理
dateFormat YYYY-MM-DD
axisFormat %m/%d
section "階段1: 企劃・寫作"
"搜尋關鍵字・趨勢分析" :a1, 2026-09-01, 3d
"草稿・程式碼驗證" :a2, after a1, 5d
"推敲・校對" :a3, after a2, 2d
section "階段2: 發布・推廣"
"透過 CI/CD 管道進行部署" :p1, 2026-09-11, 1d
"自動 SNS 發布 (X, LinkedIn, RSS)" :p2, 2026-09-11, 1d
"擴散至社群書籤等" :p3, after p2, 3d
section "階段3: 觀測・分析"
"GSC 數據累積期間" :m1, 2026-09-14, 28d
"透過 Python API 進行成效評估":m2, after m1, 2d
section "階段4: 改善 (重寫)"
"修改 CTR 下降文章的標題" :r1, after m2, 3d
"程式碼更新至最新版本":r2, after r1, 4d

像這樣，將文章撰寫視為一個軟體開發專案來對待，並將發布後的營運・維護（重寫）階段納入計畫，是維持與提升流量的秘訣。

4.2 內容創作的 ROI（投資回報率）數學模型

既然工程師要花費寶貴的時間寫文章，就應該意識到其投資回報率 (ROI)。部落格的 ROI 可以公式化如下：

$$ ROI = \frac{\sum_{t=1}^{T} \left( Rev_{ad}(t) + Val_{brand}(t) + Val_{skill}(t) \right) - Cost_{time}}{\text{Cost}_{time}} \times 100 \ (\%) $$

$T$: 文章的有效壽命（直到過時的期間）
$Rev_{ad}(t)$: 廣告收益、聯盟行銷收益、贊助等直接收益
$Val_{brand}(t)$: 技術能力展示對職涯產生正面影響（轉職時錄取薪資增加、演講邀約等）的金錢換算值
$Val_{skill}(t)$: 為了撰寫文章，自身進行學習與調查所帶來的自我技能提升價值
$Cost_{time}$: 撰寫文章、製作圖解、驗證程式碼所花費的時間（換算成自己的時薪）

技術部落格最棒的一點是，即使 $Rev_{ad}$ 很少，$Val_{brand}$ 和 $Val_{skill}$ 也有變得極大的傾向。特別是高品質的技術解說會直接成為作品集，在轉職活動或獲取副業時發揮極大的威力。

5. 結合 GitHub Actions 與外部自動化工具的發布機制

建立內容後，如何有效率地傳遞給目標受眾（發布與分發）就成了一個課題。每次都手動將連結貼到各個 SNS 是沒有效率的，也不像工程師的作風。

5.1 社群媒體分享的自動化架構

建構一個架構，從將 Markdown 檔案合併到 GitHub 儲存庫的 main 分支那一刻起，到建置、部署、以及跨平台發布通知，都能完全自動化。

flowchart TD
A["開發者 (Git Push)"] --> B["GitHub 儲存庫"]
B -->|Webhook| C["GitHub Actions (CI/CD)"]
C -->|Build| D["靜態網站生成器 (Hugo/Gatsby)"]
D -->|Deploy| E["主機代管 (Vercel / Cloudflare Pages)"]
D -->|Generate| F["RSS Feed (index.xml)"]
F -->|Polled by| G["Zapier / IFTTT / Make"]
G -->|API Call| H["X (Twitter) 自動發文"]
G -->|API Call| I["LinkedIn 文章發文"]
G -->|API Call| J["Discord / Slack 社群 Webhook"]
C -->|Actions Script| K["Qiita / Zenn 跨平台發布 API"]

5.2 自動化管道的建置重點

透過 GitHub Actions 進行建置與部署 如果使用靜態網站生成器，可利用 GitHub Actions 將 HTML 的生成與部署到主機服務（Vercel, Netlify, Cloudflare Pages 等）自動化。這時，作為前述 Core Web Vitals 的對策，將圖片最佳化流程（例如自動轉換為 WebP）納入建置管道也是非常有效的。
利用 Zapier/IFTTT 搭配 RSS 觸發的 SNS 串接 網站生成器在建置時會產生最新的 RSS feed (XML)。讓 Zapier 或 Make (前 Integromat) 等 iPaaS 讀取這個 feed，並建立「當 RSS 有新增項目時，就將標題和 URL 發布到 X (Twitter) 和 LinkedIn」的工作流程。這樣一來，文章發布的瞬間就能自動通知追蹤者。
交叉發布 (Cross-Post) 到 Qiita/Zenn（Canonical 標籤的活用） 當自家部落格或個人部落格的網域權威（Domain Power）還很弱時，借用 Qiita 或 Zenn 等技術平台的集客力也是一種方法。但是，單純的複製貼上會有被當作重複內容而受到 SEO 懲罰的風險。這個問題可以透過在 Qiita 或 Zenn 文章的 Meta Data 中設定 Canonical 標籤，並指定自家部落格的原創文章 URL 來解決。透過 GitHub Actions 呼叫各種平台的 API，編寫從 Markdown 自動生成文章的腳本，就能完全自動化多管道的發布。

結語：轉動持續改善的循環

為了讓技術部落格的月流量出現戲劇性的成長，除了「寫作」這個行為之外，本次介紹的工程化方法也是不可或缺的。

建立有意識到 SEO 的穩固 HTML 與網站架構
規劃能理解使用者搜尋意圖（錯誤解決 vs 系統性學習）的文章
充分運用 Google Search Console API 與 Python 進行數據分析
意識到 ROI 的內容生命週期管理與重寫
透過 CI/CD 與 Zapier 串接，實現發布的完全自動化

如果能將這些組合成一個系統，技術部落格將會成為強力推動你個人職涯的最強資產（Asset）。如果工程師正為了流量停滯而煩惱，請務必從今天開始嘗試「部落格的成長駭客」。在開發業務中培養出的程式設計技能與架構設計能力，在經營部落格時也一定會成為最強大的武器。