pretty code

2026年5月18日 星期一

PDF 翻譯 Part 02

前天使用自製工具翻譯了一份文件,大概快 900 頁,下面是 API 使用情況。

=== Summary ===
Paragraphs translated : 4186
Input tokens          : 211,790
Output tokens         : 302,468
Estimated cost        : $7.0905 USD

還不賴,比一本書便宜。

另外,PDF 翻譯工具需改進,一個是動態調整 RPM 限制,另一個則是要考慮如何保存中間結果。

因為我遇到一個 5000 頁的文件,做到約 2250 頁時,系統當機,應該是我同時做很多事,導致記憶體用到快 16 G。


AI 給的 RPM 修改建議方向

先做:查你目前的狀態(5 分鐘)

查 Tier 在哪裡

方法 1:Console 介面

  1. 登入 console.anthropic.com
  2. 左側選單 → SettingsLimits(或 Plans & Billing
  3. 會看到「Tier 1 / 2 / 3 / 4」字樣,以及對應的 RPM、ITPM、OTPM 數字

方法 2:用 curl 直接問 API(更準)

打開 cmd 或 PowerShell,把 YOUR_KEY 換成你的 API key:

curl https://api.anthropic.com/v1/organizations/rate_limits ^
  -H "anthropic-version: 2023-06-01" ^
  -H "x-api-key: YOUR_KEY"

回傳的 JSON 裡會直接告訴你每個模型的 RPM/ITPM/OTPM,對照下面的表就知道 Tier:

Tier Sonnet RPM Sonnet ITPM
1 50 30,000
2 1,000 80,000
3 2,000 800,000
4 4,000 2,000,000

查 prompt caching 有沒有開

直接搜你的翻譯工具程式碼,看 system 那段:

# 在你的翻譯工具資料夾
findstr /S "cache_control" *.py
  • 有輸出 → 有開 caching
  • 沒輸出 → 沒開 caching

或更簡單:跑一次翻譯,在你的程式裡 print 出 response.usage,看有沒有這兩個欄位:

  • cache_creation_input_tokens(第一次跑會有)
  • cache_read_input_tokens(第二次以後會有)

兩個都是 0 → 沒開 caching。


然後:直接用 Batch API 改造你的工具

既然你選「注重速度,可以掛著等」,Batch API 是完美解答。我直接幫你準備好可以丟給 Claude Code 的修改說明。

Batch API 對你的好處(再次確認)

  • 不受 RPM 限制 — 5,000 段一次提交也沒事
  • 價格 5 折(input 和 output 都打 5 折)
  • 24 小時保證,實測通常 1–2 小時
  • 與 prompt caching 可疊加(更便宜)
  • ⚠️ 結果是「全部一起回」,不能邊跑邊看
  • ⚠️ 中途無法取消個別請求

給 Claude Code 的修改 prompt

你可以新開一個 Claude Code session,把這份貼過去(同時也把你現有的翻譯工具程式碼放在資料夾裡):

請幫我把這個 PDF 翻譯工具的 Claude API 呼叫,從「同步單筆呼叫」改成「Batch API + Prompt Caching」模式。

## 背景
- 目前工具:用 Anthropic SDK 逐段呼叫 `client.messages.create()`
- 模型:claude-sonnet-4-6(或更新的 Sonnet)
- 痛點:800 頁論文要跑 4 小時,撞到 RPM 限制
- 工作流:可以掛著等,不需即時看結果

## 修改目標
1. 加上 prompt caching(針對 system prompt + glossary)
2. 改用 Batch API 一次提交全部段落
3. 加入 batch 狀態輪詢與結果取回
4. 保留現有的「翻譯完回貼成 PDF 圖層」功能不變

## 詳細修改項目

### 1. Prompt Caching

修改現有的 API 呼叫,把 system prompt 和 glossary 標記為可快取:

```python
# 從這樣:
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    system=SYSTEM_PROMPT,
    messages=[{"role": "user", "content": text_to_translate}]
)

# 改成這樣(system 改用 list 形式並加 cache_control):
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + "\n\n" + glossary_text,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": text_to_translate}]
)
```

重要:cache_control 加在 system prompt 的「最後」一個元素。
注意:cache 至少需要 1024 tokens 才會生效,如果 SYSTEM_PROMPT + glossary 不到,
請先確認 token 數(用 client.messages.count_tokens()),不夠就提早 return「caching 不適用」並用原本的方式呼叫。

### 2. Batch API 流程

新增一個模式(用 CLI 參數 --batch 切換),流程如下:

#### Step 1: 抽取所有要翻譯的段落
從 PDF 抽出所有段落,建立一個 list of (segment_id, text) tuple。

#### Step 2: 建立 batch requests

```python
from anthropic.types.messages.batch_create_params import Request

requests = []
for seg_id, text in segments:
    requests.append(Request(
        custom_id=seg_id,  # 用來回對映,例如 "page-12-para-3"
        params={
            "model": "claude-sonnet-4-6",
            "max_tokens": 4096,
            "system": [
                {
                    "type": "text",
                    "text": SYSTEM_PROMPT + "\n\n" + glossary_text,
                    "cache_control": {"type": "ephemeral"}
                }
            ],
            "messages": [{"role": "user", "content": text}]
        }
    ))
```

注意:一次 batch 最多 100,000 個請求或 256 MB,請判斷是否需要分批提交。

#### Step 3: 提交 batch

```python
batch = client.messages.batches.create(requests=requests)
print(f"Batch ID: {batch.id}")
print(f"Status: {batch.processing_status}")

# 把 batch.id 存到本地檔案(例如 .batch_state.json),
# 這樣程式中斷後還能用同個 batch_id 繼續輪詢
```

#### Step 4: 輪詢狀態

```python
import time

while True:
    batch = client.messages.batches.retrieve(batch.id)
    counts = batch.request_counts
    print(f"Status: {batch.processing_status} | "
          f"Done: {counts.succeeded}/{counts.processing + counts.succeeded + counts.errored + counts.canceled + counts.expired}")
    
    if batch.processing_status == "ended":
        break
    
    time.sleep(60)  # 每分鐘查一次
```

#### Step 5: 取回結果

```python
results = {}
for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        translated = result.result.message.content[0].text
        results[result.custom_id] = translated
    elif result.result.type == "errored":
        print(f"Error on {result.custom_id}: {result.result.error}")
        results[result.custom_id] = None  # 標記失敗,後面用單筆 API 重跑
```

#### Step 6: 重跑失敗的段落
對 results 裡值為 None 的 custom_id,用原本的單筆 messages.create 重新翻譯。

#### Step 7: 把翻譯結果回貼成 PDF 圖層
沿用現有的回貼邏輯。

### 3. CLI 介面

請新增三個指令:

```bash
# 提交 batch 並等待完成(前景模式)
python translator.py --batch input.pdf output.pdf

# 提交 batch 立刻退出(背景模式)
python translator.py --batch-submit input.pdf
# 程式印出 Batch ID,使用者可以關掉終端機

# 輪詢狀態
python translator.py --batch-status BATCH_ID

# 取回結果並產出 PDF
python translator.py --batch-fetch BATCH_ID output.pdf
```

背景模式方便你睡覺前提交、隔天起床取結果。

### 4. 錯誤恢復

請建立一個 `.batch_state.json`,內容如下:

```json
{
  "batch_id": "msgbatch_xxx",
  "submitted_at": "2026-05-17T10:00:00",
  "input_pdf": "path/to/input.pdf",
  "output_pdf": "path/to/output.pdf",
  "segment_map": {
    "page-12-para-3": "...原文段落...",
    ...
  }
}
```

這樣即使程式或電腦中斷,重新執行 `--batch-status` 或 `--batch-fetch` 還能繼續。

### 5. 成本與時間預估

請在提交前印出:
- 預估 input tokens 總數(用 count_tokens API 或保守估算)
- 預估 cost(Sonnet 4.6 batch 價格:$1.50 / MTok input, $7.50 / MTok output)
- 預估完成時間(保守說「1-24 小時」)

讓使用者確認後才真正提交。

## 不要做的事
- 不要拿掉原本的「逐段呼叫」模式,保留它做為 fallback
- 不要在 batch 提交後鎖死 UI,使用者要能關掉終端機去做別的事
- 不要假設 batch 一定 1 小時內完成,要支援 24 小時等待

改完之後的預期效果

以你 800 頁論文為例:

方案 時間 你需要在電腦旁
現況 ~4 小時 全程
+ Prompt caching ~3 小時 全程
+ Tier 升級 (-> 2) ~30 分鐘 全程
改 Batch API 1–2 小時 0 分鐘(掛著等)
Batch + Tier 升級 1–2 小時 0 分鐘

Batch API 對你的價值不只是「快」,而是「解放你的時間」 — 提交完就可以關電腦睡覺,醒來結果就在那。

成本方面:800 頁論文(假設 50 萬 input tokens、20 萬 output tokens)大致估算:

方案 預估成本(粗估)
現況 ~$4.50
+ Caching ~$3.00
+ Batch API ~$2.25
Caching + Batch ~$1.50

數字僅供參考,實際看你的文件密度。改完最多省 2/3 成本,外加 4 小時變 1-2 小時、還不用顧。


給你的執行順序建議

  1. 先查 Tier(用上面 curl 或 console)
  2. 新開 Claude Code session,把你的翻譯工具資料夾打開,把上面那段 prompt 貼進去
  3. 試跑一份小檔案(10-20 頁)驗證 batch 流程沒問題
  4. 正式跑 800 頁那份,掛著去睡覺
  5. 醒來檢查結果,用我們之前規劃的那個 PDF Compare Viewer 並排看 Google Translate 版 vs Claude API 版

整個工作流就完整了。

原來之前都在玩玩具

難得本週不用推 Code,於是便想繼續完成 PDF 翻譯相關的想法。

途中好奇,想要自己寫個 PDF Viewer 好方便我比較不同 Translator API 的差異,跟 Web Claude 討論的結果,他也覺得自己寫會比現成的方便,於是我就請 Web Claude 規劃,分階段實作及驗收。

目前來到 M3 階段,終於第一次碰到 Limit 限制,提示我必須等到 11:50 AM 過後才能繼續。

抓個圖留作紀念。


Web Claude 使用多少 token 未知,但本機用量如下。


Claude 各方案比較


限制詳細說明


API 使用限制


Pro 5 小時上限估計


換算成實際工作比較



AI 給的建議

給你的實戰建議

根據這些數字,Pro 規劃工作流的原則

1. 開新對話的時機

  • 對話超過 20-30 輪就考慮開新對話
  • 任務切換時開新對話(不要在同一對話跨多個專案)
  • 把當下對話的「結論」貼到新對話起頭,可以用很少 tokens 換到清爽 context

2. 模型選擇策略

  • 日常對話、寫文件:用 Sonnet(你目前模型 Opus 4.7 約 5x 貴)
  • 複雜推理、艱難 debug:才用 Opus
  • 如果只是「優化措辭」之類的小任務,可以切到 Haiku

3. 上傳檔案的成本意識

  • 一份 800 頁 PDF(你的論文)一上傳可能就 200-400K tokens,超過 Pro 5 小時池子十倍
  • 大檔案優先用 API 處理(你的翻譯工具就是對的方向)
  • 想討論大檔內容,先用工具抽出關鍵段落,貼進 Claude 對話

4. 你目前的工作流估算

你過去這 6-7 輪我們的對話,加上 spec / prompts 文件產出,大概用掉 30-50K tokens。 意思是:這種「規劃 + 寫規格」的對話,一次 5 小時的 Pro 配額大概可以撐 2-3 個專案

但如果你還要同時用 Claude Code 開發那個 PDF Viewer,Claude Code 燒很快(一次 1-2 小時的開發就可能吃完 5 小時池子)。

5. 撞牆時的判斷

情境建議
每週撞 5 小時牆 1-2 次改用「開新對話」「換 Sonnet」習慣
每週撞 3+ 次認真考慮 Max 5x($100),ROI 大幅提升
Claude Code 一天用 4+ 小時Max 5x 起跳,重度的話 Max 20x

給你的核心收穫

Pro 5 小時 ≈ 44K tokens ≈ 30-50 則中等對話,這是你規劃工作的心理基準。

實務上你可以這樣抓:

  • 「跟 Claude 規劃個東西、寫個規格」→ 30-50K tokens,剛好用滿 5 小時池子的一半到全部
  • 「用 Claude Code 做半天開發」→ 容易撞牆
  • 「上傳大檔深度分析」→ 一次就用很多,挑著用

如果你想更精確地監控,可以在 claude.ai 設定裡看 Usage 頁面(如果有開放給 Pro),或在 Claude Code 裡跑 /status 看當下用量。

2026年5月16日 星期六

PDF 翻譯 Part 01

很多技術文件都是英文,無奈個人英文差,常常自以為的解釋其實跟原文差了十萬八千里XD

上星期突然想到是否可以請 Claude Code 寫個程式來幫我翻譯?

之所以要這麼搞剛,是因為 Web AI 都聽不懂人話居多,請他逐字逐字翻譯,結果都無法照做?當然也有可能是我不會用導致?不過,我並沒有用其他第三方的 AI 網站,而是直接使用我有訂閱的 Gemini 或是 Claude。

一開始 Claude 就知道要用 PyMuPDF 來處理 PDF,不過,對於圖表或是程式碼的判斷差強人意。

隔天有空搜尋了一下,原來這套函式庫非常有名,大家都是使用他來處理 PDF。

官方也很貼心的提供一個範例,並將翻譯過的內容使用圖層的方式貼到原本文字上,這意味著當翻譯不好時,我們隨時可以關掉圖層直接看原文,這實在是很方便的一個功能。

於是我第二版的程式就以官方範例為底稿,直接請 Claude Code 增添功能。

配合圖層的設計,終於我也有一個堪用的 PDF 翻譯工具了。

過程中,也釐清了一些我原來不懂的問題。

也許網路上還有更好的解法,但現在的方法對我來說已經夠用了,缺點就是要花時間把手邊一些文件重新翻譯。

NotebookLM 不是說不好,但有些時候,你還是需要閱讀原文才知道 AI 是不是有誤會什麼?

下面節錄我請 AI 整理的報告內容

七、關於 PDF 格式語意結構的討論
--------------------------------
問:check.py 都是自己判斷格式,是 PDF 格式沒有定義,還是函式庫的問題?

答:主要是 PDF 格式本身的設計所致,與函式庫(PyMuPDF)無直接關係。

  PDF 的設計初衷是「視覺呈現」,儲存的是:
    - 文字的座標、字型、大小
    - 圖片像素資料
    - 向量圖形繪圖指令
  PDF 格式本身不儲存語意結構,不知道「這段是頁首」「這段是程式碼」。

  PDF 有一個選用規格稱為 Tagged PDF(PDF/UA),允許文件作者加入語意標籤:
    <H1> 章節標題 </H1>
    <P>  段落文字 </P>
    <L>  清單(項目符號)</L>
    <Table> ... </Table>
  PyMuPDF 可以讀取這些標籤,若 PDF 有正確標注則不需要啟發式規則。

  本文件的實際情況:
    - 產生工具:PDFium
    - Tagged PDF:否(未加語意標籤)
    - PyMuPDF 回傳的 XML 標籤(block、line、char)是函式庫自行解析的
      幾何結構,並非 PDF/UA 語意標籤
    - 結論:PyMuPDF 無從得知各 block 的語意角色,因此必須以啟發式
      規則(正規式、座標範圍、關鍵字)自行推斷

  簡言之:這是絕大多數市面上 PDF 的共同現況,並非 PyMuPDF 的限制。


八、目前已知限制與未來改進建議
--------------------------------
  1. 項目符號:僅跳過 • 等符號開頭的 block,若使用其他少見符號需手動擴充
     BULLET_PATTERN。

  2. 程式碼偵測:以「同時含 { 與 ;」為條件,可能誤判含這兩個字元的自然語句。
     更精確的做法是檢查文字區塊所使用的字型名稱(等寬字型如 Courier、
     Consolas 通常代表程式碼)。

  3. 頁首/頁尾:比例閾值(8%)適用於大多數標準排版,但若文件邊距特別大
     或小,可能需要調整,或升級至方案 B(自動偵測重複內容)。

  4. 表格偵測:PyMuPDF 的 find_tables() 對有明顯框線的表格效果佳,對無框線
     表格可能漏判。安裝 pymupdf_layout 套件可提升偵測精確度。

  5. 翻譯品質:使用 Google Translate API(免費版),有次數限制與品質限制,
     專業術語翻譯可能不準確。


有了 AI 不用白不用,以下是 Web Claude 給的解決方案

英文技術文件翻譯成中文:5 個最佳方案

針對技術文件的完整翻譯,我為你整理了五個經過實測效果不錯的方案,並依照不同使用情境分類。


方案一:Claude / ChatGPT / Gemini(大型語言模型)

直接將文件內容貼到對話框,或上傳檔案請 AI 翻譯。

優點

  • 翻譯品質目前在技術文件領域是最高的,能理解上下文、保留技術術語的一致性
  • 可以下指令客製化,例如「保留程式碼區塊不翻譯」、「使用台灣繁中習慣用語」、「術語表優先」
  • 能處理 Markdown、HTML 等格式,輸出後排版幾乎不需要再整理
  • 遇到模糊語意時會根據語境合理判斷,而非機械式直譯

缺點

  • 長文件需要分段處理,否則容易遇到輸出長度限制(通常一次 3000–5000 字較穩定)
  • 不同段落之間的術語一致性需要自己維護術語表,或在 prompt 中明確指定
  • 免費版本通常有用量限制,重度使用需要訂閱
  • 偶爾會出現幻覺,特別是專有名詞或版本號,需要人工校對

最適合: 重視翻譯品質、文件量中等(一份文件數千到數萬字)、願意動手調整 prompt 的人。


方案二:DeepL(含 DeepL Pro / DeepL Document Translator)

專注於翻譯的服務,支援 .docx、.pptx、.pdf、.txt 等檔案上傳,整份翻譯後下載。

優點

  • 翻譯流暢度極佳,中文輸出比 Google 翻譯更自然
  • 文件上傳後會完整保留原始排版(字型、表格、圖片位置)
  • 操作極簡,零學習成本
  • 有 API 可串接到自己的工作流程

缺點

  • 對於最新的技術術語(特別是 AI、區塊鏈等新領域)有時不如 LLM 精準
  • 免費版有每月字數和檔案大小限制(單檔約 5MB、每月 3 份)
  • 無法針對特定術語做客製化翻譯記憶(這是 Pro 才有的 Glossary 功能)
  • 對程式碼區塊的處理不如 LLM 細緻,有時會誤譯變數名稱

最適合: 需要保留原始檔案排版、追求穩定輸出、不想花時間調整參數的人。


方案三:Immersive Translate(沉浸式翻譯)瀏覽器擴充功能

主要用於網頁翻譯,但也支援 PDF、EPUB 等文件,採雙語對照顯示。

優點

  • 雙語對照模式對技術文件閱讀極友善,原文與譯文並列方便核對
  • 可以串接多種翻譯引擎(Google、DeepL、OpenAI、Claude、自訂 API 等)
  • 支援線上文件(GitHub README、官方文件網站)即時翻譯
  • PDF 翻譯保留原始排版,輸出雙語 PDF
  • 免費版功能已足夠日常使用

缺點

  • 串接 OpenAI/Claude API 需要自己申請金鑰並支付費用
  • PDF 翻譯的進階功能(如完整檔案翻譯下載)需要 Pro 訂閱
  • 對於要交付的「翻譯成果」不是最佳選擇,比較適合自己閱讀
  • 排版複雜的 PDF 偶爾會出現對位錯誤

最適合: 主要是「自己要看懂」技術文件、會頻繁瀏覽英文網頁文件、想要保留原文對照的人。


方案四:Crowdin / Lokalise / Weblate(專業在地化平台)

針對軟體與技術文件設計的協作翻譯平台,支援多種檔案格式(Markdown、JSON、PO、XLIFF 等)。

優點

  • 有完整的翻譯記憶庫(TM)和術語表(Glossary)功能,確保跨文件術語一致
  • 支援團隊協作、版本控管、審校流程
  • 可直接串接 GitHub/GitLab,文件更新時自動同步
  • 整合機器翻譯(MT)作為初稿,再由人工校對
  • 適合長期維護的文件專案

缺點

  • 學習曲線較陡,初次設定需要花時間
  • 主要為團隊與企業設計,個人偶爾使用過於笨重
  • 免費方案限制較多(Crowdin 有開源專案免費方案,Lokalise 沒有真正的免費版)
  • 不適合一次性的翻譯任務

最適合: 持續維護的技術文件(如開源專案 docs、產品手冊)、團隊協作、需要版本控管的場景。


方案五:Google 翻譯(含 Google Docs 內建翻譯 / Google 文件翻譯)

老牌通用翻譯工具,可直接上傳文件或在 Google Docs 中使用「翻譯文件」功能。

優點

  • 完全免費,無使用量限制
  • 支援格式廣泛,文件上傳可保留基本排版
  • 速度極快,整份文件幾秒鐘完成
  • 與 Google Workspace 整合良好

缺點

  • 翻譯品質在技術文件上明顯落後於 DeepL 和 LLM,中文常有「翻譯腔」
  • 不擅長處理技術術語,有時會把專有名詞硬譯
  • 無法客製化術語或語氣
  • 程式碼區塊處理粗糙

最適合: 對品質要求不高、需要快速理解大意、預算為零的場景。


我的建議組合

如果是要交付的正式翻譯成果,實務上最有效率的做法是混搭:

LLM(Claude/ChatGPT)做初翻 → 人工校對 → DeepL 或 Immersive Translate 對照檢查

如果你能告訴我這份技術文件的類型(API 文件?產品手冊?學術論文?)、長度,以及翻譯後的用途(自己看 / 交付給客戶 / 發佈),我可以給你更具體的方案推薦。

2026年5月12日 星期二

如果我有 AI

這是一個我今天在思考的問題?

今天是第一次透過 script 把所有相關應該手動 patch 的東西,都在 script 中自動化搞定!

我想這跟我昨天下午請了半天假休息有關,今天整個人神清氣爽,不然真的是感覺很久沒放假了!假日為了推 Code,人都被綁在書桌前面,出去吃個飯也是急忙趕著回家觀看 make build 結果,一整個心累。

又或許也跟我們終於有一版比較完整的 script 版本,這也有助於我自動化所有 patch 瑣事。

因為這些手動 patch 真的很瑣碎,我實在很難開好 spec 請 AI coding,因為描述這個問題的打字,可能我直接寫 script 還是比較快。

更別提我們根本不可能在客戶環境內使用 AI?

總之,今天這個 script 的建立,當我們下次換新 tag 繼續驗證時,至少可以節省 60% 以上的時間。

因為我已經建立了一套 SOP,下次行動就有準則了。

比如說,copy 要怎麼做?

copy 的 reference 也要建立一個 reference_tag 的資料夾供 reference。

遇到要手動改檔案的地方,如果那個檔案不能參考 reference _tag 的話,改將相關東西放到 tools/git_patch 裡面,使用 git apply 的方式上 patch。

另外,上面這個路徑,也可以放客戶 patch 有問題時,我 patch 他的 patch 檔案。

難怪古人說:不以規矩,不能成方圓。 

2026年5月10日 星期日

ScreenBar Halo 2 入手

我最近的人生終於有光明了XD

問了幾家附近的 3 C 買場都沒有賣此掛燈,上網購買又得避開晚上送貨,不知為啥也不能選擇常去的便利商店取貨?

今天雖然推 Code 不順,還是抽空去了三創一趟,既然好不容易上去台北,還是每層樓都走馬看花一下,很多店家動線貌似都有重新調整,逛起來舒服多了。

來到現場,看不出來這款掛燈特殊之處,可能是展場燈光本來就很亮的緣故。

反正我就是要買,故也沒多做考慮,一個放家裡,一個放公司。

回家剛裝上時,還覺得是不是裝錯了,感覺一點用處都沒有,後來才發現原來燈管可以旋轉調角度,調整過後果然好多了。

可惜現在老了不在書桌看書寫字了,不然我這鍵盤處的一小塊天地,真的是充滿光明。

明天去公司時應該就能點光明燈了XD

官修正史董狐筆

吾善養吾浩然正氣。

風簷展書讀,古道照顏色。

雖說百無一用是書生,但至少讀書人有風骨。

我的修為還是太淺了些,希望在今年生日前能夠進入無界力量XD


誰說武道止於十境?這個作者的眼界也太小了點!

就像《碧血劍》中描述的華山派內功一樣,雖說由外功練起,但最後也是殊途同歸,由外而內。

這部小說,我喜歡的有齊聖人,當然還有主角陳平安。

沒有這本書,我現在應該翻桌了,每個星期推 Code 都要搞人,髒話都罵了三千字了XD

2026年5月9日 星期六

Fix make build

果不其然,今天要推 Code 時又 Gone 了,明明昨天早上還檢查過(後記:push 時跑的驗證跟第一次檢查環境跑的不是同一個!)。

為了這個,也是搞得我心煩意亂,害我 Debug 時不能靜心,浪費了快兩個小時。

凡事要靠自己,我又不像陳平安有齊聖人照看XD

檢討一下,下次不要再犯錯了!

1. 雖然看出 UVM 有錯誤,但還是懶得問 AI,畢竟要自己打字也是心累。

我的 Debug 方向是對的,因為心煩所以想岔了路,一直想要將缺少的 interface 檔案,透過 BUILD_OPTION 傳進去,也就是想要餵給 XRUN,所以我透過 Makefile 修改問題,有符合我的解題思路。

但因為 Verilog 本質上比較像 C 語言,所以找不到的 interface 檔案,應該要放在同檔案上方用 include 解決。

2. 不要在未確定客戶後續是否還有 commit 未 pull,就先執行 make build。

誠如上次我猜的那樣,客戶的 Makefile 相依性有問題,明明執行完 make build,後續還有 commit 且 commit 中有包含 DV 相關的 testbench 裡的檔案,但因為 git push 判斷 make build 已成功,故並未重新執行 make build。

3. 同前,既然無法確定客戶後續是否還有 commit ,我應該要嚴格執行之前訂定的 SOP。

不過此番看來,PM 4:00 過後還是太趕,改成 PM 8:00?


希望下一次推 Code 可以順利一些﹍

2026/05/10 更新

還好今天母親節聚餐延後,不然我還真的沒辦法繼續了。

昨天晚上好不容易解決掉 make build 問題,你他媽的跑驗證又有問題,重點還不只 1 個問題。

但這次嚴守紀律,不為了這個熬夜,還是準時在 12 前上床。

現在再來盡最後一次的努力。

首先,我以下的理解應該無誤:

- 客戶透過 .git/hooks/pre-push 強制我跑驗證才能 push。
- 驗證跑的 test 跟平常跑的不一樣,至少跟第一次驗證環境的不一樣。
- 驗證要跑的東西是放在真正跑驗證那層的 testfiles 資料夾內,由 Makefile 決定是哪個。
- 跑驗證時,是透過跑驗證那層的上一層裡的 bin 資料夾裡的 perl 程式來 dispatch。
- 跑驗證的 log 在哪我還找不到,但有錯的 log 是放在驗證那層所有 fail 開頭的檔案。

但奇怪的點是我兩個錯誤的測試,其中一個在 test list 裡卻是註解狀態,理論上不應該被 random 挑選到才對?

還有就是在目前這個時間點,星期日早上 7 點,看起來都還有人 commit。

前幾次不知道,我想那個人內心一定很幹,怎麼有人放假在推 Code!如果我的速度比他快,他就會遇到我之前平日推 Code 遇到的死結一樣,因為我比他先 push,導致他推 Code 會失敗。

重點他的 commit 還有持續 fix 驗證問題,難道驗證失敗是因為他的問題?

總之,是否要為此調整 SOP?

另外,屋漏偏逢連夜雨,所有的 Server 目前都已停擺,工作無法 dispatch,就不知道是真的掛點還是接近 +0 時區的午夜,Server 正在重開機或是執行什麼任務?

如果最後真的是因為 Server 無法推 Code,那我也真的沒轍了!

我可以改 Verilog、Makefile、Script,甚至是 Perl 檔案,只為了讓整個 flow 打通,但是遇到 IT 問題我就沒辦法了,畢竟孤臣無力可回天呀!

2026/05/10 下午更新

Server 還是斷斷續續的工作,整個進度非常緩慢。

全部 4 台只有一台恢復正常,至少剛剛檢查情況是這樣。

另外,驗證清單確實是放在 testfiles,只是要注意裡面還有 INCLUDE 其他 test 檔案。

這樣一來我的疑惑完全打通了。