WinGet 可安裝的 Microsoft 官方 Linux 指令群最新動向（2026 年 6 月更新）​

2026 年 6 月，Microsoft 正式公開了 Coreutils for Windows。

winget install Microsoft.Coreutils

透過這個指令可安裝的 Microsoft.Coreutils，是 Microsoft 官方專案，可讓 Linux 與 macOS 日常使用的 ls、cp、rm、cat 等 UNIX 系指令，能在 Windows 上以原生方式執行。

本文將整理專案概要、支援指令、限制事項，以及與 WSL 和 PowerShell 的差異。

概要

Microsoft.Coreutils 是由 Microsoft 維護、面向 Windows 的命令列工具集。

其內部是以以下專案為基礎構建：

• uutils/coreutils
• findutils
• grep

並以 Rust 實作。

Microsoft 將此專案的目的說明為：

降低在 Linux、macOS、WSL、容器、Windows 之間來回切換的開發者摩擦

安裝方法

可透過 WinGet 輕鬆導入。

winget install Microsoft.Coreutils

WinGet 是 Windows 內建的套件管理員，可自動下載並安裝指定套件。

安裝後即可作為一般指令使用。

ls
cat file.txt
grep keyword log.txt
cp source.txt backup.txt

可使用的主要指令

代表性的指令如下。

對 Linux 使用者來說，熟悉的指令可直接使用。

與 PowerShell 的衝突問題

這裡是最大的注意點！

PowerShell 內已經存在同名的別名或內建指令。

例如：

因此，

ls

即使執行了，也不一定會呼叫 Coreutils 版本。

Microsoft 建議使用 PowerShell 7.4 以上版本。

Windows 特有的限制

雖然目標是相容 Linux，但仍存在因 Windows 機制造成的限制。

1. 沒有 POSIX 訊號​

Linux 的

kill
SIGTERM
SIGKILL

機制在 Windows 中不存在。

因此，

kill
timeout

目前尚未提供。

2. 沒有 /dev/null​

Linux：

grep error log.txt > /dev/null

Windows：

grep error log.txt > NUL

會是這樣。

3. ACL 與 POSIX 權限的差異​

Windows 是以 ACL 為基礎的權限管理。

因此，

chmod
chown
chgrp

等指令不會提供。

4. 建立符號連結​

雖然可以讀取，但若要新建立，則需要：

• Developer Mode
• 管理員權限

不提供的主要指令

Microsoft 有意排除了一部分指令。

與 Windows 衝突的項目​

• dir
• more
• paste
• whoami
• expand

與 POSIX 強烈依賴的項目​

• chmod
• chown
• chgrp
• chroot
• nohup
• stty
• tty
• who

目前尚未實作的項目​

• kill
• timeout
• dd

與 WSL 的差異

最常被比較的是 WSL（Windows Subsystem for Linux）。

WSL 是「Linux 環境本身」，而 Coreutils 則是「在 Windows 上使用類 Linux 指令的工具集」。

背景與問題意識​

在日常工作中，使用 Python 腳本進行資料轉換自動化時，常常會遇到以下問題：

• 明明只更新了原始資料的一部分，卻得整體重新執行，白白浪費時間。
• 哪個步驟依賴哪個檔案不夠清楚，難以管理執行順序與遺漏情況。
• 不容易掌握腳本修改會影響哪些產出物。

Makefile 具備「相依關係」與「只重跑差異部分（增量建置）」這些標準功能，能用很少的描述解決上述問題。

Make 的基本概念​

• 目標（target）：產出物（例：output/report.csv）
• 相依關係（dependency）：產出所需的檔案（例：data/clean/*.csv 或腳本）
• 配方（recipe）：用來產出的指令（例：python scripts/aggregate.py ...）

Make 會在「相依關係比目標更新」時才執行配方。如此一來，當原始資料或 Python 腳本更新時，只會自動重跑必要的部分。

最小構成的 Makefile 範例​

以下是一個將 raw 資料清理後，再產生彙總報表的差異執行範例。

# Makefile
SHELL := bash
.SHELLFLAGS := -eu -o pipefail -c
.DELETE_ON_ERROR:
.ONESHELL:
.DEFAULT_GOAL := all

RAW_DIR := data/raw
CLEAN_DIR := data/clean
OUT_DIR := output

RAW := $(wildcard $(RAW_DIR)/*.csv)
CLEAN := $(patsubst $(RAW_DIR)/%.csv,$(CLEAN_DIR)/%.csv,$(RAW))
REPORT := $(OUT_DIR)/report.csv

# 目錄為順序相依（不存在時建立，但不作為更新判定依據）
$(CLEAN_DIR) $(OUT_DIR):
	mkdir -p $@

# 彙總報表依賴已清理的 CSV 與彙總腳本
$(REPORT): $(CLEAN) scripts/aggregate.py | $(OUT_DIR)
	python scripts/aggregate.py -i $(CLEAN_DIR) -o $@

# 由各 raw CSV 產生對應的 clean CSV
$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv scripts/clean.py | $(CLEAN_DIR)
	python scripts/clean.py -i $< -o $@

.PHONY: all clean status

all: $(REPORT)

clean:
	rm -rf $(CLEAN_DIR) $(OUT_DIR)

# 確認哪些項目會被重建的輔助指令
status:
	@echo "RAW   : $(RAW)"
	@echo "CLEAN : $(CLEAN)"
	@echo "REPORT: $(REPORT)"
	@echo
	@echo "Dry-run (what would run):"
	@$(MAKE) -n all

透過這個架構，可以達成以下效果：

• 更新原始資料 data/raw/foo.csv 時，只會重新產生對應的 data/clean/foo.csv。
• 更新 scripts/clean.py 時，只會在必要範圍內重新執行清理流程。
• 更新 scripts/aggregate.py 時，只會重新執行彙總報表。

動作示意​

# 第一次執行（全部產生）
make -j

# 部分 raw 更新（只重新執行該檔案的清理與報表）
touch data/raw/a.csv
make -j

# 清理腳本更新（重新執行所有清理與報表）
touch scripts/clean.py
make -j

# 彙總腳本更新（只重新執行報表）
touch scripts/aggregate.py
make

想事先確認「會執行什麼」時，make -n 很有用。

腳本相依性的設計指引​

• 每個規則都應明確將其直接呼叫的 Python 腳本列為相依關係，這很重要。
• 若拆分成多個模組，應將目標規則所 import 的模組也納入相依關係，才能正確傳遞變更。簡便作法是把目標目錄下所有 Python 檔案變成變數，再加進相依關係中。

例（簡便作法）:

PY_SRCS := $(wildcard scripts/**/*.py) $(wildcard scripts/*.py)

$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv $(PY_SRCS) | $(CLEAN_DIR)
	python scripts/clean.py -i $< -o $@

平行執行與加速​

• 透過 make -j 可以將彼此獨立的檔案轉換平行化。資料點越多，效果越明顯。
• 中間產物切得越細，增量執行越有效，也越能避免整體重算。
• 若 I/O 是瓶頸，可搭配壓縮格式、檔案分割、或本機 SSD 使用。

實務上的訣竅​

• 目錄建立使用順序相依（| dir）處理，可避免不必要的重建。
• 為了在失敗時不留下不完整產物，建議啟用 .DELETE_ON_ERROR。
• 常用入口可用 .DEFAULT_GOAL := all 標準化，讓 make 一次就能執行。
• 除錯時可使用 make -n（只顯示不執行）、make --trace（顯示為何會執行）、make -d（詳細日誌）。
• 清理請使用 .PHONY: clean，並注意只刪除生成物。

虛擬環境與依賴套件（選用）​

Python 執行環境也可以交由 Make 管理。

VENV := .venv
PY := $(VENV)/bin/python

$(VENV)/bin/python: requirements.txt
	python3 -m venv $(VENV)
	$(VENV)/bin/pip install -r requirements.txt
	touch $@

# 後續配方中使用 $(PY)
$(CLEAN_DIR)/%.csv: $(RAW_DIR)/%.csv scripts/clean.py | $(CLEAN_DIR) $(VENV)/bin/python
	$(PY) scripts/clean.py -i $< -o $@

$(REPORT): $(CLEAN) scripts/aggregate.py | $(OUT_DIR) $(VENV)/bin/python
	$(PY) scripts/aggregate.py -i $(CLEAN_DIR) -o $@

更新 requirements.txt 時，只會在必要範圍內重新完成設定。

總結​

• Makefile 是一種能自動化「明確相依關係」與「只重跑差異部分」的工具，能大幅提升資料轉換流程的可靠性與開發速度。
• 正確連結原始資料、腳本與產出物，並將處理細化後，更新影響的範圍就能被快速重新計算。
• 以最少的描述即可獲得可重現性、平行化與可觀測性，讓日常自動化工作變得更加順手。

透過使用 Anthropic API 的 /v1/models 端點，可以從程式中獲取可用的 Claude 模型列表及其規格。

Claude Code 是 Anthropic 官方的程式碼代理工具，但透過設定環境變數可以經由 OpenRouter 使用像 DeepSeek V4 Pro 這類其他模型。本文說明該設定方法。

背景​

櫻花的租用伺服器「輕量方案」以 每月121元 的超低價格提供36個月的預付方案。（12個月預付則為每月165元） 對於靜態文件的託管或 CGI 用途而言，這個價格相當合理，非常適合個人用途的儲存。

然而，所分配的域名會是 用戶名稱.sakura.ne.jp 的子域名， 若想要將自訂域名綁定於特定路徑，就需要一些技巧。

想要達成的目標​

當訪問 https://app.example.com 時， 應該能在不更改 URL 的情況下顯示 https://sakurauser.sakura.ne.jp/app/ 的內容。

為什麼簡單的 DNS 設定無法實現​

DNS 的 CNAME 記錄只能指定主機名稱，無法指定包含 路徑 的 URL，如 /app/。

雖然使用重定向 (301) 也是一種方法，但這樣會使瀏覽器的地址欄中的 URL 變為 sakurauser.sakura.ne.jp/flower/。

使用 Cloudflare Workers 的透明代理方式， 可以讓 URL 保持為 app.example.com。

前提條件​

• 已在 Cloudflare 註冊自訂域名（例如: example.com）
• 使用 Cloudflare 的免費方案即可（每日 100,000 次請求以內免費）

步驟​

1. 創建 Worker​

1. 進入 Cloudflare 儀表板 → Workers & Pages → Create
2. 選擇 Start with Hello World!
3. 輸入 Worker 名稱（例如: storage-proxy）
4. 點擊 Deploy

2. 編輯代碼​

部署後，點擊 Edit code， 將其全部替換為以下代碼。

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const target = new URL("https://sakurauser.sakura.ne.jp");
    target.pathname = "/app" + url.pathname;
    target.search = url.search;

    const newRequest = new Request(target.toString(), {
      method: request.method,
      headers: request.headers,
      body: request.body,
    });

    const response = await fetch(newRequest);

    const newHeaders = new Headers(response.headers);
    newHeaders.delete("content-security-policy");
    newHeaders.delete("x-frame-options");

    return new Response(response.body, {
      status: response.status,
      headers: newHeaders,
    });
  }
};

總結​

• 櫻花租用伺服器的輕量方案價格非常便宜，特別適合用來儲存靜態文件，僅需 每月121元。
• 然而，要將自訂域名指向子路徑的 DNS 設定不是標準功能。
• 通過使用 Cloudflare Workers 作為透明代理，可以在不改變 URL 的情況下提供內容。
• Workers 的代碼大約只需要幾十行，並且可以在 Cloudflare 免費方案的範圍內運作。

我將這個部落格從 AWS S3 移轉到 Cloudflare Pages。過去是用 S3 做靜態網站托管，透過 CloudFront 發佈，但為了簡化管理及提升效能，決定採用 Cloudflare Pages。

本文比較 OpenAI 目前可用的 API 模型——GPT-5.4、GPT-5.4 nano、GPT-5.4 mini、GPT-4o、GPT-4o mini 的費用、規格與效能，並整理各使用情境下的選擇建議。

單位：USD / 100 萬 Token（MTok）。資訊以 2026 年 4 月為準。

費用比較​

GPT-4o mini 的輸入與輸出費用均為最低，但知識截止日期為 2023 年 10 月，不適合需要最新資訊的任務。GPT-5.4 nano 的輸入費用與 GPT-4o mini 相近，同時具備 GPT-5.4 系列的品質及 2025 年 8 月為止的最新知識。GPT-5.4（旗艦）的輸入費用與 GPT-4o 相同，但輸出費用高達 $15.00/MTok，適合需要最高品質推理的場景。

使用區域處理端點時，GPT-5.4 系列將額外收取 10% 加成費用。

規格比較​

GPT-5.4 系列的 Context 視窗大幅擴展至 400K Token，最大輸出也支援 128K Token。GPT-4o / GPT-4o mini 則分別限制在 128K / 16K。

效能比較​

GPT-5.4​

GPT-5.4 系列的旗艦模型。代表 OpenAI 當前世代的最高智能，在複雜推理、長文生成、進階程式開發等方面均大幅超越 GPT-5.4 mini。支援所有原生工具（電腦操作、MCP、網路搜尋等），並完整支援多模態輸入輸出。由於輸出費用高達 $15.00/MTok，建議限定在必須取得最高品質輸出的場景使用。

GPT-5.4 mini​

GPT-5.4 系列的中階模型，針對程式開發、電腦操作及子代理任務進行最佳化。效能穩定超越 GPT-5 mini，並以更快的速度實現接近旗艦 GPT-5.4 的通過率。與 GPT-5 mini 相比，速度提升確認達 2 倍以上，在程式開發工作流程中提供頂級的效能/延遲權衡。

GPT-5.4 nano​

GPT-5.4 系列中體積最小、費用最低的模型。針對速度與成本為首要考量的大量處理使用情境最佳化，例如分類、資料萃取、排序及程式開發子代理。不適合需要深度推理的複雜任務。

GPT-4o​

以通用旗艦模型之姿登場，兼具文字與圖片處理的高智能。目前已被 GPT-5.4 系列取代，定位為舊版模型。雖於 2026 年 2 月從 ChatGPT 退役，但 API 存取仍持續提供。

GPT-4o mini​

設計定位為「最適合微調的小型模型」。透過蒸餾大型模型（GPT-4o）的輸出，以低成本、低延遲實現同等效果。MMLU 分數為 82.0%。適合希望降低簡單任務推理成本的情境。

該選哪個模型？​

• 大量處理・優先考量成本：GPT-5.4 nano 或 GPT-4o mini。若需要最新知識則選 GPT-5.4 nano，若需要微調則選 GPT-4o mini。
• 程式開發・代理任務：GPT-5.4 mini。速度與精確度的平衡最佳。
• 複雜推理・高品質輸出：GPT-5.4。費用為輸入 $2.50、輸出 $15.00/MTok，雖然高成本，但可獲得當代最高品質的輸出。
• 與舊有系統相容：GPT-4o。API 持續提供，可維持現有的系統整合。

性價比最佳選擇​

從性價比角度特別值得關注的是 GPT-5.4 nano 和 GPT-5.4 mini 這兩個模型。

GPT-5.4 nano 的輸入費用與 GPT-4o mini 相近（$0.20 vs $0.15），但可使用 400K Context、2025 年 8 月為止的知識，以及網路搜尋、檔案搜尋、MCP 等所有原生工具。除知識截止日期外，幾乎在所有方面都優於 GPT-4o mini，因此只要不需要微調，遷移至 GPT-5.4 nano 是合理的選擇。

GPT-5.4 mini 的輸入費用（$0.75）低於 GPT-4o（$2.50/MTok），且在程式開發與代理工作流程中的效能超越 GPT-4o。若日常使用 GPT-4o，切換至 GPT-5.4 mini 很可能同時實現降低成本與提升效能的目標。

另一方面，GPT-4o 目前的性價比偏低。輸入費用與 GPT-5.4 相同（$2.50/MTok），在 Context 大小、知識新鮮度及工具支援方面卻全面落後於 GPT-5.4 系列。除非需要微調或與現有系統相容，否則主動選擇 GPT-4o 的理由並不充分。

參考資料​

• OpenAI API 費用
• GPT-5.4 mini 模型詳細說明
• GPT-5.4 nano 模型詳細說明
• GPT-5.4 mini 與 nano 介紹 – OpenAI
• GPT-5.4 模型詳細說明
• GPT-4o mini 模型詳細說明

現代的 UI 設計中，「邊距設定為 8 的倍數」的規則被廣泛使用。這不僅僅是慣例，而是基於 螢幕密度、排版和比例的數學一致性所支持的經驗法則。

針對多種螢幕密度的應對​

現代顯示器具有 1x、1.5x、2x、3x、4x 等像素比率。

8 可以在多種倍率下整除，因此不容易發生次像素渲染的模糊效果。如果使用像 5 px 這樣的值，在 1.5x 環境中會導致 7.5 px 的尾數，渲染會變得不準確。

與排版的相容性​

瀏覽器的預設字體大小為 16 px (= 8 × 2)。行距通常也為 1.5 倍 = 24 px (= 8 × 3)。

使用 8 的倍數設置邊距，可以讓文本的節奏視覺上更一致。因為標題和正文的高度與邊距網格相一致，從而產生整齊的垂直節奏。

便於設計標記的創建​

--space-1: 8px;
--space-2: 16px;
--space-3: 24px;
--space-4: 32px;

這樣的比例簡單，使設計師和工程師能更易於使用共同語言。Material Design 和 Tailwind CSS 也採用了這一思路。

設計師只需指定「這裡是 space-3」，工程師便能毫不猶豫地使用 24px。命名規則的統一降低了代碼評審時的溝通成本。

4 px 基礎的選擇​

對於需要更細微調整的 UI，4 px 基礎 (4、8、12、16...) 也很常見。Tailwind CSS 預設採用 4 px 基礎 (p-1 = 4px)。

4 px 基礎也是 8 px 基礎的子集，因此兩者並不矛盾。可以在組件內部等細微的邊距使用 4 px 單位，在不同區域間等較大的邊距使用 8 px 單位進行區分，這樣的運用也很有效。

總結​

8 px 的倍數作為邊距標準的原因可以歸納為三點。

1. 應對螢幕密度: 在多種像素比率下能整除，防止次像素模糊。
2. 與排版的一致性: 與預設字體大小 (16 px) 和行距 (24 px) 一致，產生垂直節奏。
3. 比例的一致性: 簡單的標記體系成為設計師和工程師的共同語言。

Amazon S3 Files 是一項可以將 S3 桶直接掛載到 EC2 等計算資源的服務，並且以 NFS 檔案系統的形式運行。資料保持在 S3 中，可以使用一般的檔案操作（ls、cp、cat 等）進行讀寫。

S3 Files 是什麼​

S3 Files 是基於 Amazon EFS 建立的共享檔案系統，讓使用者能以檔案系統的形式存取 S3 桶中的數據。

主要特點如下：

運作原理​

S3 Files 將被訪問的資料自動載入高效能儲存系統，並以低延遲的方式提供服務。

• 小檔案（預設小於 128 KB）：直接從高效能儲存中讀取
• 大檔案（1 MB 以上）：直接從 S3 流式傳輸
• 寫入：在高效能儲存中寫入後，自動同步到 S3

高效能儲存中的資料，如果在一定時間內（預設 30 天，可設置為 1 - 365 天）未被訪問，將自動刪除。

前提條件​

• AWS 帳戶
• EC2 實例（Linux）
• S3 桶（與 EC2 相同區域）
• 兩個 IAM 角色
  • 建立檔案系統用：對 S3 桶的讀寫權限
  • EC2 實例用：附加 AmazonS3FilesClientFullAccess 管理策略
• 安全群組：允許 NFS 的 2049 端口通訊

IAM 角色的建立​

S3 Files 需要兩個 IAM 角色。

1. 用於建立檔案系統的角色​

使用管理控制台時會自動創建，因此不需要手動創建

此角色用於讓 S3 Files 存取桶。

# 創建角色
aws iam create-role \
  --role-name S3Files-FileSystem-Role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "s3files.amazonaws.com" },
        "Action": "sts:AssumeRole"
      }
    ]
  }'

# 附加 S3 Files 客戶端策略
aws iam attach-role-policy \
  --role-name S3Files-FileSystem-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FilesClientFullAccess

在創建檔案系統時用 --role-arn 指定此角色。

2. 用於 EC2 實例的角色​

未附加 IAM 角色會導致掛載失敗

在 CloudShell 中創建以下角色。

# 創建角色
aws iam create-role \
  --role-name EC2-S3Files-Role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "ec2.amazonaws.com" },
        "Action": "sts:AssumeRole"
      }
    ]
  }'

# 附加 S3 Files 客戶端策略
aws iam attach-role-policy \
  --role-name EC2-S3Files-Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FilesClientFullAccess

# 創建並附加實例檔案配置
aws iam create-instance-profile \
  --instance-profile-name EC2-S3Files-Profile

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3Files-Profile \
  --role-name EC2-S3Files-Role

將此角色附加到實例上。

設定步驟​

1. 準備 S3 桶​

在 S3 控制台中創建通用桶，也可以使用現有的桶。

需要特別注意的是，必須啟用桶的版本控制設定

2. 創建檔案系統​

從控制台創建​

1. 在 S3 控制台中選擇桶
2. 點擊「檔案系統」標籤 → 「創建檔案系統」

從控制台創建後，所有可用區會自動創建掛載目標和存取點。

3. 指定前綴和 VPC，然後點擊「創建檔案系統」。

記錄下輸出的檔案系統 ID（例如：fs-0123456789abcdef0）。

3. 在實例中掛載​

在終端中執行以下命令。

# 創建掛載點
sudo mkdir /mnt/s3files

# 挂載
sudo mount -t s3files fs-0123456789abcdef0:/ /mnt/s3files

sudo dnf install -y amazon-efs-utils # Amazon Linux, RHEL
# sudo apt install -y amazon-efs-utils (Ubuntu, Debian)

確認掛載情況：

df -h /mnt/s3files

應顯示類似以下內容：

Filesystem      Size  Used Avail Use% Mounted on
<s3files-dns>   8.0E  129M  8.0E   1% /mnt/s3files

4. 確認運行​

cd /mnt/s3files

# 創建檔案
sudo sh -c 'echo "Hello, s3 Files!" > test.txt'

# 讀取檔案
cat test.txt

# 創建目錄
sudo mkdir test-directory

ls -la

# 複製檔案
sudo cp test.txt test-directory/

cd test-directory/

# 確認檔案列表
ls -la

寫入的檔案會在約 1 分鐘內與 S3 桶同步。可以在 S3 控制台確認對象已創建。

aws s3 ls s3://<bucket-name>/

自動掛載設定​

為了在重啟後保持掛載，需要將以下內容添加到 /etc/fstab。

# 添加到 /etc/fstab
fs-0123456789abcdef0:/ /mnt/s3files s3files _netdev,nofail 0 0

_netdev 是一個選項，確保在網路連接後再進行掛載，這是必需的。加入 nofail 可以防止掛載失敗時導致實例無法啟動。

收費​

S3 Files 的收費如下：

• 高效能儲存使用量：檔案系統中數據的儲存費用
• 檔案系統存取費用：對高效能儲存進行讀寫操作的費用
• S3 請求費用：對於直接從 S3 讀取大於 1 MB 的檔案，僅收取 S3 GET 費用

為按量計費的無需配置模式，根據 AWS 的說法，與傳統 S3 和檔案系統間數據複製相比可減少最多 90% 的成本。

總結​

• 使用 S3 Files 可以將 S3 桶掛載為 NFS 檔案系統在 EC2 上
• 數據保留在 S3 中，可以使用 ls、cat、cp 等正常的檔案操作
• 透過高效能儲存提供低延遲，未被訪問的數據會自動退避
• 通過 /etc/fstab 設定自動掛載，即使重啟後也能維持

參考​

• Amazon S3 Files - Amazon Web Services
• S3 Files 使用者指南 - AWS 文件
• 教學：開始使用 S3 Files - AWS 文件

透過將 mitmproxy 設定為中間人代理，可以即時查看 AI 程式碼工具在背後進行的 API 通訊內容。

運作原理​

許多 AI 程式碼工具是以 Node.js 開發的應用程式，透過 HTTPS 與外部 API 進行通訊。將 mitmproxy 作為中間人代理插入，並讓 Node.js 信任 mitmproxy 的 CA 憑證，即可解密加密的通訊內容並即時查看。

安裝​

使用 uv 安裝 mitmproxy 最為方便。

uv tool install mitmproxy

代理設定​

在啟動工具之前，先設定以下環境變數。

$env:HTTPS_PROXY = "http://127.0.0.1:8080"
$env:HTTP_PROXY  = "http://127.0.0.1:8080"
$env:NODE_EXTRA_CA_CERTS = "$env:USERPROFILE\.mitmproxy\mitmproxy-ca-cert.pem"

關於 NODE_EXTRA_CA_CERTS​

只設定 HTTPS_PROXY 和 HTTP_PROXY 會導致 Node.js 的 TLS 驗證失敗而無法通訊。mitmproxy 在中繼 HTTPS 時使用自簽憑證，而 Node.js 預設會拒絕該憑證。

在 NODE_EXTRA_CA_CERTS 中指定 mitmproxy CA 憑證的路徑後，Node.js 便會信任該憑證，通訊也就能順利建立。

產生 CA 憑證​

mitmproxy 在首次啟動時會自動產生 CA 憑證，並儲存至 ~\.mitmproxy\。若尚未產生，啟動一次即可。

mitmweb

瀏覽器會自動開啟，在 http://127.0.0.1:8081 顯示代理管理介面。

啟動工具​

在另一個已設定環境變數的終端機中啟動工具。

開始操作工具後，mitmweb 畫面上就會出現請求流量。

擷取到的通訊內容​

端點​

工具會向以下端點發送請求。

POST https://api.example.com/v1/messages

請求標頭​

x-service-version: ...
content-type: application/json
x-api-key: sk-...

請求本文​

{
  "model": "model-name",
  "max_tokens": 16000,
  "stream": true,
  "system": [
    {
      "type": "text",
      "text": "..."
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "..."
    }
  ],
  "tools": [
    {
      "name": "Read",
      "description": "...",
      "input_schema": {}
    }
  ]
}

設定 stream: true 後，會以 Server-Sent Events (SSE) 格式接收串流回應。

回應​

data: {"type":"content_block_start","index":0,"content_block":{"type":"text","text":""}}
data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"Hello"}}
...
data: {"type":"message_stop"}

可以了解到的資訊​

系統提示詞中包含 AI 程式碼工具的運作原則、可用工具的說明及注意事項等內容。

總結​

• 關鍵在於透過 NODE_EXTRA_CA_CERTS 讓 Node.js 信任 mitmproxy 的 CA 憑證
• API 通訊採用 SSE 串流格式
• 可以查看工具定義和系統提示詞等 AI 程式碼工具的內部結構