自建本地模型，不是參數太大硬體跑不動，就是參數量低到回覆內容笨到不行。改用線上大型模型，錢包又燒得超快！預算有限的我們，到底要選哪一顆「AI 腦袋」才不會讓錢包君哭泣？

這次幫大家把 Copilot 各大模型的價格整理成白話文，幫你評估相對便宜又好用的 AI。目前當下最便宜、CP 值最高的首推 GPT-5.6 Luna！

小知識提醒：

以下價格是以每 1,000,000 Tokens（百萬 Token）計算～1 Token 大約等於半個英文字母，Token 用得越少越省錢！

1. 便宜實用組：小資族與日常 Code 寫手首選

如果你只是要寫寫簡單的小程式、檢查語法，選這組就對了，價格便宜到幾乎沒感覺！

2. 中量級主力組：複雜任務的平價好幫手

當你需要 AI 幫你處理長篇大論、或是複雜的邏輯推理時：

3. 重量級旗艦組：課金大佬與硬核邏輯專用

對沒預算來說 AI 界「吃的起的大餐」，回答質量相對前面的高，但代價就是……口袋要夠深！

Copilot 終極省錢三招

1. 善用 Prompt Cache（快取機制）：有沒有發現表格裡的「快取輸入 (Cached)」價格便宜非常多？儘量保持對話上下文連續，讓模型能用到快取，價格直接打折！
2. 簡單任務用小模型，複雜邏輯才召喚大模型：日常改錯字、寫簡單 Function 用 GPT-5.6 Luna 或 Claude Haiku；遇到要重構整包架構，再切換成 Claude Sonnet。
3. 控管 Output Token：輸出的字數通常最貴！請 Copilot 「精簡回答、只給重點」，不要讓他跟你套近乎寫長篇大論，都是錢啊！

總結

選擇 AI 模型就像選車一樣：平時通勤騎機車（Luna/Haiku），出遠門再開超跑（Sonnet/Gemini）！

希望大家都能用甜甜價享受到最適合的大語言模型。

AI 都會寫 Code 了，我還要學程式幹嘛？

寫在前面： 如果你剛入行沒多久，最近才搞懂指標、遞迴教到懷疑人生，結果一轉頭發現同事丟一句指令（業界叫 Prompt）給 AI，五秒生出一支比你熬夜寫的還漂亮的程式，你心裡大概只有一句 OS：「所以我是在跟 AI 比爛嗎？」

別慌，這篇文章要跟你講清楚：AI 很會「打字」，但它不會「扛鍋」。這篇文章要用最白話、最台的方式，告訴你為什麼你還是得乖乖把資料結構學好，不然你未來只會變成 AI 的傳聲筒工讀生。

* 該不該去 code review AI 出來的巨量 code, 是現在AI coding遇到的問題, 不 review 又怕有問題, 要 review 又很花時間.
* Clean Code 概念，面對大量 AI 生成的程式碼，工程師不需要逐行盯著看，而是透過建立多關卡流程與自動化測試網來進行驗收。
* 如果工程師不懂基本軟體工程觀點與測試設計，就無法替 AI 架設正確的品質監視器。
* 避免成為 AI 傳聲筒與盲目複製者。AI 的本質是語言模型，提供的是聽起來合理的答案，而非保證正確的答案。
* 遇到錯誤就整包丟給 AI 盲目複製貼上，會成為人肉傳聲筒。遇到 Bug 直接套用 AI 解法，萬一套用到「消除症狀」而非「解決根因」，錯誤被藏起來，會變成更大的Bug。

1. 「敲鍵盤的手速」已死

以前工程師比的是誰打字快、誰記得 API 多，跟打電動比手速一樣，越快越潮。

現在呢？你打一行 for 迴圈的時間，AI 已經把基本增刪查改（CRUD）、打包上線的流程（Docker、CI/CD）都生完了，甚至還幫你寫好註解，貼心到讓人想哭。

所以問題來了：

如果打字這個動作已經不值錢了，那我以前辛苦學的程式基礎是不是白學了？

先講結論：「打字的價值」的確歸零了，但「想清楚要打什麼」的價值，反而暴增。 就像計算機再強，你還是要懂數學才能知道要算什麼、答案合不合理；AI 再強，你還是要知道自己要什麼結果，不然只會被 AI 牽著走，錯了都不知道。

舉個栗子： 你要做一個登入功能，跟 AI 說一句「幫我做登入」，AI 三十秒就生出一套。但你如果不知道密碼要加密、不知道 Token 過期要怎麼處理，AI 生出來的東西看起來能動，其實漏洞一堆你也發現不了——因為你根本不知道「要問什麼」。

2. 從「工地搬磚工」變成「AI 工讀生的組長」

以前工程師像是工地的搬磚工，一磚一瓦手工疊；現在你身邊多了一群不用發薪水、不會抱怨加班、但也完全不會自己判斷對錯的 AI 工讀生大軍。

聽起來很爽？先別高興得太早，當組長要會：

+-----------------------------------------------------------------+
|                AI 時代「工讀生組長」的三大絕活                  |
+-----------------------------------------------------------------+
|  1. 畫紅線 (立規矩)                                              |
|     - 跟工讀生說清楚：這裡不能偷懶、那裡不能踩雷                |
+-----------------------------------------------------------------+
|  2. 拆工作 (分派任務)                                            |
|     - 把「做一個網站」拆成十件工讀生聽得懂的小事                |
+-----------------------------------------------------------------+
|  3. 驗收品質 (抓包 debug)                                        |
|     - 工讀生交差前，你要一眼看出他是不是在「呼嚨」你             |
+-----------------------------------------------------------------+

如果你自己都不懂邏輯、不懂架構，那你不是在當組長，你是在被工讀生（AI）牽著鼻子走，白忙一場自己還不知道。

舉個栗子： 你叫 AI 做一個「線上點餐系統」，如果沒先講清楚「庫存等於零就不能再下單」，AI 生出來的系統可能讓賣光的餐點還能一直被點，等到客訴湧進來你才發現：不是 AI 笨，是你根本沒把紅線畫清楚。

3. Clean Code 教父鮑伯大叔怎麼說

寫 Code 寫了大半輩子的傳奇人物 Uncle Bob（我們姑且叫他「鮑伯大叔」），最近說了一句話：

「不讀 AI 寫的 Code，是我享受 AI 生產力的唯一方法。」

翻成白話就是：「我懶得逐行檢查，但我會用單元測試當監視器，抓到問題我馬上打回去重寫。」

他的做法是：不是不檢查，是換一種更潮的方式檢查：

1. 多關卡流水線：需求 ➔ 寫 Code ➔ 重構 ➔ 審查，分成好幾道關卡，一關一關檢查，不會一次囫圇吞棗。
2. 測試網：

• Gherkin 規格測試：用接近中文的白話文字，先寫清楚「這個功能應該長怎樣」。
• 單元測試 + 變異測試：故意在程式裡埋一個小錯誤，測試看看你的測試集能不能抓得到。
• 圈複雜度監控：程式碼裡的分支、判斷式繞來繞去，複雜到連你自己都看不懂？系統會直接標記為不合格。

這段的重點：
AI 時代一樣要守規矩，只是規矩從「手打細節」變成「設計測試、劃邊界、盯指標」。
你連 Clean Code 是三小都不知道，你要怎麼架這套關卡？

舉個栗子： 你請 AI 寫一個「計算購物車總金額」的函式，你不用逐行看它怎麼寫。但你可以先寫好測試：「三件 100 元的商品，總金額應該是 300」、「打完九折優惠碼要變成 270」。AI 寫完，測試沒過就打回去重寫，你就不用自己盯著程式碼一行一行抓錯。

4. 遇到 Bug 只會問 AI？小心變成「人肉複製貼上工具人」

用 AI 解 Bug 完全沒問題，很多時候效率還很高。真正危險的，是那種把 Error Message 整包丟給 AI，AI 說什麼都照抄照信、完全不驗證就貼上去交差，甚至還拿著 AI 的答案去嗆同事「你這樣寫是錯的」的「AI 傳聲筒」工程師。

你可能會想：「反正問題有解決就好，這樣不是很有效率嗎？」——這正是最容易踩的陷阱。這裡的問題不是 AI 笨、只會做表面 workaround（好的模型給足夠上下文，通常真的會去抓根因），問題出在AI 的診斷品質，完全取決於你給的上下文夠不夠。你只丟一行 Error Message，AI 看不到完整的資料流、呼叫關係跟商業邏輯，它只能就手上有限的資訊，給出一個「在它看到的範圍內」合理的答案——這可能真的是根因，也可能只是治標。而你自己如果不懂系統，就完全沒有能力判斷「這個修法到底夠不夠全面」，只能照單全收。萬一 AI 剛好只看到冰山一角，你把那個答案當成解答直接上線，問題會被藏在你沒檢查到的地方，之後才在你意想不到的時間點冒出來，追查難度只會比原本的錯誤訊息更高。

 模糊的問題 ───► LLM / AI ───► Ctrl+C Ctrl+V（完全沒看） ───► 上線後現場爆炸
              （機率式亂猜）      【傳聲筒型工程師本人】

講白了，這種人不是工程師，是人肉滑鼠。

AI 的本質是機率預測的語言模型（業界愛講的 LLM，你可以想成是超強的「文字接龍高手」），它給你的是「聽起來很合理」的答案，不是「保證正確」的答案。機率高不等於邏輯對，更不等於能通過 Code Review。

當你的程式上線後當機、資料庫死鎖、記憶體爆炸時，AI 不會幫你跟主管或客戶鞠躬道歉，只有懂原理的你才能救場。

舉個栗子： 你的程式跳出「NullPointerException」錯誤，把整包錯誤訊息丟給 AI，AI 回你「應該是變數沒初始化」，你看都沒看就跑去跟組員嗆「都是你的錯，你變數沒初始化」。結果真正的問題是你自己傳錯參數——AI 只是照著它看到的字面亂猜，你卻把它的猜測當聖旨。

5. 為什麼你還是要乖乖學？四個「保命」理由

先澄清一個常見誤會：這章不是要你放棄 AI 的速度、回頭手寫每一行。人手寫的程式不會比較安全，事實上人一沒睡飽，錯誤率可能比 AI 還高，只是人犯的錯通常比較慢被發現。真正的重點是：不管是 AI 秒生的程式，還是你自己手刻的程式，都一定會有錯——差別只在於你有沒有能力在它捅出簍子之前抓到它。 學會這四件事，不是為了跟 AI 比誰打字快，而是為了讓你在 AI 高速產出的同時，還能穩穩接住它的錯誤：

① 基礎知識 = 你跟 AI 溝通時的關鍵字彙

你要是不懂演算法，你講不出：「這裡用『N log N』等級的效率就好，不要給我『N 的平方』那種龜速地獄。」
你要是不懂軟體工程，你講不出：「資料存取跟商業邏輯給我分開，不要全部包在一起變成義大利麵條 Code。」
不懂，你就只能跟 AI 說「幫我修一下」——這句話等於跟老闆說「東西壞了幫我修一下」，注定被白眼。

舉個栗子： 你叫 AI「幫我排序這一萬筆訂單」，如果你不懂演算法，你不會知道要多加一句「請用適合大量資料的排序方式」，AI 可能隨手選了一個資料一多就變超慢的寫法，你的程式跑到天荒地老，你還以為是電腦太爛。

② 除錯的「眉角」只有摔過跤才懂

小專案用 AI 生 Code 感覺像開外掛，爽到不行。但等你以後上班，遇到系統一多人用就當機、資料一多就跑不動，你光靠 Prompt 亂許願，AI 只會陪你原地鬼打牆。

沒有實際踩過這些坑的人，很難提前判斷風險藏在哪裡。

舉個栗子： 你的個人小專案只有你自己在測試，訂票功能怎麼寫都沒事；但真的上線後，幾百人在同一秒搶同一張演唱會門票，同一個位子被賣給兩個人的問題才會爆出來。這不是加一句「庫存不足就擋單」就能解決的，背後牽涉到資料庫鎖定、交易衝突這種「多人同時搶同一筆資料」的底層機制——沒摔過這種跤，你連問題出在哪一層都看不出來，更別說叫 AI 怎麼修。

③ 建立「預判程式怎麼跑」的直覺

就像練琴要練到手指自己會動，寫 Code 沒有親手 Debug 過，你的腦中就不會有「程式實際上是怎麼一步步執行」的直覺。

沒有這個直覺，AI 寫出來的到底是精妙的設計，還是藏著地雷的隱憂，你根本看不出來，只能雙手合十祈禱不要出事。

舉個栗子： 有 debug 經驗的人看到「程式跑到一半當機」，腦中會馬上跳出「是不是陣列索引超出範圍」、「是不是資料庫連線忘記關」；沒 debug 過的人看到同樣的錯誤，只能兩眼發呆，繼續把錯誤訊息複製貼上丟給 AI 求救。

④ 最後鍋一定是你背的

不管這段程式是你熬夜半年手刻出來的，還是 AI 三十秒生出來的，只要是你送出去、掛你名字上線的，出事你就是被 Tag 到會議室的人。用 AI 不會讓你變成代罪羔羊，AI 也不會突然幫你把鍋接走——它只是讓交付變快，「誰對結果負責」這件事完全沒變。

你總不能在主管或客戶面前說：「這是 AI 寫的，不甘我的事」——這句話的下場，通常是被電爆或被資遣，二選一，都很痛。

舉個栗子： 工作報告裡引用了 AI 生成但寫錯的數據，主管只會扣你的考績，不會去找 AI 理論；系統半夜當機，老闆凌晨三點打的電話也是打給你，不會打去 OpenAI 或 Anthropic 客服中心。

6. 訂規矩給 AI 也要有分寸，不然你會被自己的規則搞死

講到「劃紅線」，很多人可能會想：那我乾脆把「先寫規格再寫程式」（SDD）、「先寫測試再寫程式」（TDD）這些方法直接寫死在指令裡，叫 AI「每次都要遵守」，這樣不就一勞永逸了嗎？

先講結論：這招聽起來很潮，但用力過猛，你會親手讓 AI 卡住，效率反而變差。

道理很簡單：規則塞越滿越死，AI 反而要先花力氣「消化矛盾」，才輪到它真正做事——就跟你去問主管問題，結果主管先唸十分鐘公司規定給你聽，耐心都磨光了問題還沒解一樣。與其把規則刻成「聖旨」要求每次都套用，不如只給大方向、給原則（例如：「盡量用測試來驗證功能有沒有做對」），讓 AI 自己判斷什麼情況該套用 SDD、什麼情況該套用 TDD——同樣的道理也適用在範例上，丟一堆範例只會把 AI 的思路框死在同一種解法裡，跟你只會套一種模板、遇到新情境就當機一樣。

這章的結論： SDD、TDD 都是好東西，但別無腦焊死在指令裡要求每次遵守。規則要少而準，剩下的判斷力，交給模型自己決定。 你的工作，是當那個「知道什麼時候該立規矩」的人，不是那個把規矩背得滾瓜爛熟、卻不知道變通的乖寶寶。

舉個栗子： 你叫 AI「每次寫程式都一定要先寫測試，絕對不准先寫功能」，結果你只是想寫一個五分鐘就能搞定的練習小工具，AI 卻被規則綁死，硬是先生出一堆測試檔案，原本五分鐘的事拖成半小時。如果你只說「重要的功能記得寫測試驗證」，AI 自己就會判斷這種小練習不需要那麼隆重。

7. 結語：別再迷戀打字的手感，去當那個「下決策的人」

我們早就不是那個在電腦前狂敲鍵盤、用打字速度證明自己很強的年代了。

未來吃得開的工程師：

• 不是把語法背得滾瓜爛熟的人；
• 而是最會下指令、劃紅線、抓包，並且事情爆炸時扛得住的人。

不打好基礎，你只會變成 AI 的高級複製貼上工讀生，隨時可能被更便宜的 AI 取代；
打好基礎，你才能真正駕馭 AI 這個強大的工具，做出正確的判斷，而不是被它帶著走、出了包也不知道為什麼。

舉個栗子： 兩個工程師都用 AI 寫同一個專案，A 只會複製貼上 AI 給的答案，卡關就繼續丟給 AI 猜；B 看得懂 AI 寫的邏輯、抓得出漏洞、還會指定架構要求重寫。老闆要的是 B，不是 A——因為 A 的工作，AI 自己就能做，還比較便宜。

思考題（比 deadline 還重要）： 你現在寫 Code，是在「訓練 AI 幫你做事」，還是已經悄悄變成 AI 的人肉傳聲筒了？留言告白一下吧！

聽起來超神奇對不對？大家總覺得把一堆像課本一樣厚的長文件換成簡短的 .md 檔，就可以幫 AI 省下大量的 Token 額度，再也不用擔心 AI 讀到一半就斷線或是配額爆表。

殘酷的實驗真相： Word 檔其實更省空間？

不過，經過實際測試，真相可能會讓你跌破眼鏡！

如果你的來源檔案本來就是 Word 檔（ .docx ），而且最後需要的成品也是 Word 檔，直接把 Word 檔餵給 AI ，反而才是最節省 Token 的作法！

很多人會用 Python 腳本硬把 .docx 轉成 .md 檔，結果不僅遺失了一大堆格式，排版也變得亂七八糟。更慘的是，等你讓 AI 修改完 .md 檔，想要再轉回 Word 檔的時候，那才是真正的災難開始。

而且你知道嗎？經過測試發現，大多數只有兩三頁的 Word 檔，檔案大小大概只有 50 KB 左右。如果你硬把它們轉成 .md 檔，體積反而會膨脹到 60 到 70 KB ！這根本不是幫 AI 減肥，是在幫它增重吧？

正確的減肥策略：直接幫 Word 檔抽脂！

既然 Word 檔這麼好用，項目符號的自動排列與編號又比 .md 檔聰明，那我們要怎麼幫它瘦身呢？

最好的解法，就是直接讓 AI 寫一個 Python 腳本，把 Word 檔裡面那些看不見的贅肉與大魔王（例如：嵌入字型、沒用的圖片）通通切掉！

下面這段強大的 Python 程式碼，就是幫 Word 檔完美抽脂的秘密工具：

"""
rebuild_docx.py — 精簡 .docx 檔案大小，保留項目符號，統一使用標楷體字型。

用法：
    python rebuild_docx.py -i <來源檔> -o <輸出檔>

策略：
  1. 直接操作來源文件 XML，保留所有 numPr（項目符號／編號）
  2. 將所有字型改為標楷體
  3. 移除 inline 圖片 (<w:drawing>)
  4. 以 zipfile 重寫時去掉 word/fonts/ 嵌入字型（最大體積來源）
"""

import argparse
import io
import os
import zipfile

from docx import Document
from docx.oxml.ns import qn
from lxml import etree

KAITI = '標楷體'


# ── 字型處理 ──────────────────────────────────────────────────────────────────

def _set_rfonts(rFonts_el):
    """將 w:rFonts 元素的所有字型屬性改為標楷體。"""
    ns = 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'
    for attr in ('ascii', 'hAnsi', 'eastAsia', 'cs'):
        rFonts_el.set(f'{{{ns}}}{attr}', KAITI)
    # 移除 theme 字型引用，避免覆蓋
    for attr in ('asciiTheme', 'hAnsiTheme', 'eastAsiaTheme', 'cstheme'):
        key = f'{{{ns}}}{attr}'
        if key in rFonts_el.attrib:
            del rFonts_el.attrib[key]


def apply_kaiti_to_element(root_el):
    """遞迴將 root_el 底下所有 w:rFonts 改為標楷體；
    若某 w:r 沒有 w:rFonts，補上一個。"""
    W = 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'
    # 修改已有的 rFonts
    for rFonts in root_el.iter(f'{{{W}}}rFonts'):
        _set_rfonts(rFonts)
    # 補上沒有 rFonts 的 run
    for rPr in root_el.iter(f'{{{W}}}rPr'):
        if rPr.find(f'{{{W}}}rFonts') is None:
            rFonts = etree.SubElement(rPr, f'{{{W}}}rFonts')
            _set_rfonts(rFonts)
            rPr.insert(0, rFonts)  # rFonts 要在 rPr 最前面


def apply_kaiti_to_styles(doc):
    """修改 document styles 中的預設字型。"""
    styles_el = doc.styles.element
    apply_kaiti_to_element(styles_el)


# ── 移除圖片 ──────────────────────────────────────────────────────────────────

def remove_drawings(root_el):
    """移除所有 <w:drawing> 元素（inline 圖片）。"""
    W = 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'
    for drawing in root_el.findall(f'.//{{{W}}}drawing'):
        parent = drawing.getparent()
        if parent is not None:
            parent.remove(drawing)


# ── 移除嵌入字型（zip 層級）────────────────────────────────────────────────────

def _clean_rels_xml(data: bytes, skip_types: set) -> bytes:
    """移除 .rels 文件中特定 Type 的 Relationship 節點。"""
    try:
        root = etree.fromstring(data)
        ns = 'http://schemas.openxmlformats.org/package/2006/relationships'
        for rel in root.findall(f'{{{ns}}}Relationship'):
            rtype = rel.get('Type', '')
            if any(t in rtype for t in skip_types):
                root.remove(rel)
        return etree.tostring(root, xml_declaration=True, encoding='UTF-8', standalone=True)
    except Exception:
        return data


def _clean_content_types(data: bytes, skip_exts: set) -> bytes:
    """移除 [Content_Types].xml 中特定副檔名的 Default 及 Override 節點。"""
    try:
        root = etree.fromstring(data)
        ns = 'http://schemas.openxmlformats.org/package/2006/content-types'
        for child in list(root):
            ext = child.get('Extension', '').lower()
            part = child.get('PartName', '').lower()
            if ext in skip_exts or any(f'/media/' in part for _ in [1]):
                if '/media/' in part or ext in skip_exts:
                    root.remove(child)
        return etree.tostring(root, xml_declaration=True, encoding='UTF-8', standalone=True)
    except Exception:
        return data


IMAGE_RELS = {'image', '/image'}
IMAGE_EXTS = {'png', 'jpg', 'jpeg', 'gif', 'bmp', 'tiff', 'wmf', 'emf', 'odttf'}
FONT_RELS  = {'font', '/font'}


def strip_bloat(src_bytes: bytes) -> bytes:
    """重新打包 zip：去除嵌入字型、媒體圖片，並清理對應的 .rels 與 Content_Types。"""
    buf = io.BytesIO()
    with zipfile.ZipFile(io.BytesIO(src_bytes), 'r') as zin, \
         zipfile.ZipFile(buf, 'w', compression=zipfile.ZIP_DEFLATED) as zout:
        for item in zin.infolist():
            name = item.filename
            # 略過嵌入字型和媒體圖片
            if name.startswith('word/fonts/') or name.startswith('word/media/'):
                continue
            data = zin.read(name)
            # 清理字型與圖片的關聯
            if name.endswith('.rels'):
                data = _clean_rels_xml(data, IMAGE_RELS | FONT_RELS)
            # 清理 Content_Types
            if name == '[Content_Types].xml':
                data = _clean_content_types(data, IMAGE_EXTS)
            zout.writestr(item, data)
    return buf.getvalue()


# ── 表格版面修正 ──────────────────────────────────────────────────────────────

def fix_tables(doc):
    """
    每張表格：
      1. 移除 w:tblpPr（浮動定位 → 原因：導致文字排在表格右側）
      2. 寬度設為 100%（w:tblW type="pct" w="5000"）
      3. 清除左縮排（w:tblInd w="0"）
    """
    W = 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'
    TBL_PP  = f'{{{W}}}tblpPr'
    TBL_W   = f'{{{W}}}tblW'
    TBL_IND = f'{{{W}}}tblInd'
    TBL_PR  = f'{{{W}}}tblPr'

    for table in doc.tables:
        tbl = table._element
        tblPr = tbl.find(TBL_PR)
        if tblPr is None:
            tblPr = etree.SubElement(tbl, TBL_PR)
            tbl.insert(0, tblPr)

        # 1. 移除浮動定位
        for el in tblPr.findall(TBL_PP):
            tblPr.remove(el)

        # 2. 寬度 100%
        tblW = tblPr.find(TBL_W)
        if tblW is None:
            tblW = etree.SubElement(tblPr, TBL_W)
        tblW.set(f'{{{W}}}type', 'pct')
        tblW.set(f'{{{W}}}w', '5000')

        # 3. 清除縮排
        tblInd = tblPr.find(TBL_IND)
        if tblInd is None:
            tblInd = etree.SubElement(tblPr, TBL_IND)
        tblInd.set(f'{{{W}}}type', 'dxa')
        tblInd.set(f'{{{W}}}w', '0')



# ── 移除顏色 ──────────────────────────────────────────────────────────────────

def remove_colors(doc):
    """
    移除文件中所有顏色相關設定：
      - w:color    (文字顏色)
      - w:highlight (螢光筆)
      - w:shd      (段落、儲存格、文字底色)
    同時將 styles 中的顏色也一併清除。
    """
    W = 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'
    COLOR_TAGS = {f'{{{W}}}{t}' for t in ('color', 'highlight', 'shd')}

    for el in doc.element.iter():
        if el.tag in COLOR_TAGS:
            parent = el.getparent()
            if parent is not None:
                parent.remove(el)

    # styles 也清除
    for el in doc.styles.element.iter():
        if el.tag in COLOR_TAGS:
            parent = el.getparent()
            if parent is not None:
                parent.remove(el)

    # styles 也清除
    for el in doc.styles.element.iter():
        if el.tag in COLOR_TAGS:
            parent = el.getparent()
            if parent is not None:
                parent.remove(el)


# ── 主流程 ────────────────────────────────────────────────────────────────────

def process_docx(src_path: str, dst_path: str, strip_color: bool = False):
    before_kb = os.path.getsize(src_path) / 1024
    print(f'來源：{src_path}  ({before_kb:.1f} KB)')

    doc = Document(src_path)

    # 1. 字型改為標楷體
    apply_kaiti_to_element(doc.element)
    apply_kaiti_to_styles(doc)

    # 2. 移除 inline 圖片
    remove_drawings(doc.element)

    # 3. 表格：100% 寬、移除浮動定位
    fix_tables(doc)

    # 4. 移除顏色（選用）
    if strip_color:
        remove_colors(doc)
        print('  → 顏色已清除')

    # 5. 存到記憶體
    buf = io.BytesIO()
    doc.save(buf)
    docx_bytes = buf.getvalue()

    # 4. zip 層級：去除嵌入字型與媒體圖片
    docx_bytes = strip_bloat(docx_bytes)

    # 5. 寫出
    with open(dst_path, 'wb') as f:
        f.write(docx_bytes)

    after_kb = os.path.getsize(dst_path) / 1024
    print(f'輸出：{dst_path}  ({after_kb:.1f} KB)  縮減 {(1 - after_kb/before_kb)*100:.0f}%')


# ── CLI ───────────────────────────────────────────────────────────────────────

def main():
    parser = argparse.ArgumentParser(
        description='精簡 .docx 大小：標楷體字型、保留項目符號、去除嵌入字型與圖片。'
    )
    parser.add_argument('-i', '--input',  required=True, help='來源 .docx 路徑')
    parser.add_argument('-o', '--output', required=True, help='輸出 .docx 路徑')
    parser.add_argument('--no-color', action='store_true', help='移除所有顏色（文字色、螢光筆、底色）')
    args = parser.parse_args()

    process_docx(args.input, args.output, strip_color=args.no_color)


if __name__ == '__main__':
    main()

生成 python 的 prompt:

* 撰寫 Python 腳本，使用簡潔的方式生成 .docx 文件，避免複雜的格式設定以減少檔案大小, 字型使用[標楷體].
* 所有項目的編號要一致且按順序排列.

接著再請 AI 寫 .bat 檔, 方便把來源資料夾下的 .docx 輸出到另一個資料夾下, 例如: convert.bat

echo 轉換中：XX說明書…
python rebuild_docx.py –no-color -i “backup\XX說明書.docx” -o “XX說明書.docx”

要注意的是, 也許你的 Word 裡需要 “媒體圖片“, 你可能需要微調上面的流程.

我發現, 大多的 Word 檔, 如果只有 2~3 頁的話, 內容在 50KB 左右, 改用 .md 反而會長到 60~70KB.

使用 Word 檔好處很多, 直接預覽也方便, 改用 libreoffice 或 ms office , google document 的 preview 也很方便, 對項目符號的自動排列與編號比 .md 好很多.

之前自動把目錄資料夾裡的 .html 轉成 .md 的 .bat 檔:

python convert_htm_to_md.py

python script:

import os
import glob
import html2text
import re
from bs4 import BeautifulSoup

def convert_htm_to_md():
    # Initialize html2text converter
    h = html2text.HTML2Text()
    h.ignore_links = False
    h.ignore_images = False
    h.body_width = 0  # No wrapping

    # Find all .htm files
    htm_files = glob.glob("*.htm")
    
    if not htm_files:
        print("No .htm files found in the current directory.")
        return

    for htm_file in htm_files:
        md_file = os.path.splitext(htm_file)[0] + ".md"
        print(f"Converting {htm_file} to {md_file}...")
        
        try:
            with open(htm_file, "r", encoding="utf-8", errors="ignore") as f:
                html_content = f.read()
            
            # Pre-processing: Remove hidden elements using BeautifulSoup
            soup = BeautifulSoup(html_content, 'html.parser')
            
            # Remove elements with display:none or mso-hide:all
            for element in list(soup.find_all(style=True)):
                if element.parent is None:
                    continue
                style = element.get('style', '').lower()
                if 'display:none' in style.replace(' ', '') or 'mso-hide:all' in style.replace(' ', ''):
                    element.decompose()
            
            # Convert cleaned HTML to Markdown
            markdown_content = h.handle(str(soup))
            
            # Post-processing to reduce tokens
            # 1. Remove empty bold/italic markers and those containing only horizontal whitespace
            markdown_content = re.sub(r'(\*\*|__)[ \t]*\1', '', markdown_content)
            
            # 2. Remove redundant asterisks/underscores (e.g., **** -> empty)
            markdown_content = re.sub(r'(\*\*|__){2,}', '', markdown_content)
            
            # 3. Split into lines and strip trailing whitespace
            lines = [line.rstrip() for line in markdown_content.splitlines()]
            
            # 4. Collapse multiple empty lines into one
            new_lines = []
            if lines:
                new_lines.append(lines[0])
                for i in range(1, len(lines)):
                    if lines[i] == "" and lines[i-1] == "":
                        continue
                    new_lines.append(lines[i])
            
            # 5. Remove leading and trailing empty lines
            while new_lines and new_lines[0] == "":
                new_lines.pop(0)
            while new_lines and new_lines[-1] == "":
                new_lines.pop()
                
            markdown_content = "\n".join(new_lines)
            
            with open(md_file, "w", encoding="utf-8") as f:
                f.write(markdown_content)
                
            print(f"Successfully converted {htm_file}")
        except Exception as e:
            print(f"Failed to convert {htm_file}: {e}")

if __name__ == "__main__":
    convert_htm_to_md()

如果直接在全網頁上處理, 參考: Gemini 的 Gem 教學, 以政府資訊採購規格書審查專家為例
https://max-everyday.com/2026/06/gemini-gem-cot/

已直接切到新模型了, 更便宜, 又更好用, 只是在回覆時很容易出現簡體中文字.

使用心得：很容易觸發背景代理, 自動在各自獨立的 git worktree 中並行工作。模型所製作的計劃會被自動的更新與記錄進度,工作完成的通知之前也都會驗證結果。效率似乎有比之前版本更好。

根據 Anthropic 官方在 2026 年 6 月 30 日發佈的消息， Claude Sonnet 5 被定位為目前為止最具有自主行動能力的 Sonnet 系列模型。它不只會乖乖聽話，還會自己擬定計畫、熟練地操作瀏覽器和終端機，甚至能獨立執行很多複雜任務。這種等級的自主能力，在幾個月前可是只有那些又貴又巨大的模型才做得到。

對很多寫程式的開發者來說， AI 的自主時代其實是從 Sonnet 系列開始的。Sonnet之前的版本，在寫程式跟操作工具上就已經讓人很驚艷，但最近最猛的突破通常還是出現在 Opus 系列。

而這次的 Sonnet 5 直接縮短了這個差距。它在(1)邏輯推理、(2)工具使用、(3)程式編寫以及(4)知識工作等重要指標上，都比舊款的 Sonnet 4.6 有了巨大的飛躍。

在大家最關心的安全性方面，測試發現 Sonnet 5 做壞事的機率比 Sonnet 4.6 還要低，面對網路上的惡意引導或提示詞攻擊，它也更懂得拒絕，比較不容易胡言亂語或一味迎合使用者。不過，官方也誠實表示，他們沒有特別訓練它去進行網路安全攻防，所以如果比起更高等級的 Opus 4.8 ， Sonnet 5 在防禦某些複雜漏洞時的表現還是稍微嫩了一點。

在收費部分，Anthropic 官方推出了限時體驗價。從現在開始到 2026 年 8 月 31 日為止，每百萬個輸入字元(per 1M tokens)只要 2 美元，輸出字元則是 10 美元。到了 9 月 1 日之後，就會恢復成標準定價，也就是輸入 3 美元、輸出 15 美元。

簡單來說，這是一顆加量不加價的限時打折，趕快來去體驗看看。

最近才去學的英文單子：polish ，之前修改文章或發訊息，大腦都只會自動跳出中文的潤飾兩個字。

自從有了 AI 之後，特別是好用到爆、讓人用免驚的 Gemini ，它直接變成我的英文救星！現在不管收到什麼訊息，只要是看不太懂的，或是我想寫給別人看卻抓不到感覺的，我都直接使出大絕招，對著 Gemini 輸入： help me to polish xxx 。

不論是正式的 email 還是平常的 Line 訊息、 Facebook 貼文，甚至是工作上的 issue 和 PR ，通通丟進去 polish 一下就對了！

不過，全世界最需要被 polish 的，絕對是 Microsoft Azure 和 Google 的官方技術文件！真不知道那些文件到底是寫給誰看的，每次硬著頭皮讀完，頭上都只會冒出滿滿的問號。還好現在有 Gemini 當翻譯官，把那些外星文變成地球人看得懂的話。

大家都應該試試看，每件事都 Ask Gemini ，每件事都 polish 一下！

ex:

• polish this post, make context funny, easy to read, easy understand.
• give me 插畫風格 prompt text to generate blog cover, –ar 16:9, don’t directly generate image here. text only.

拿到提示詞, 如果要加入標題, 使用:

, 圖片標題[每件事都 Ask Gemini ，每件事都 polish ！]

如果要方型圖, 修改 –ar 參數為:

--ar 1:1

說書人瓦基（《下一本讀什麼?》創辦人）邀請百萬訂閱創作者 PAPAYA 電腦教室 上節目，在網路上引起廣大迴響。訪談中提到了《聖經》，以下為大家關注的焦點摘要：

「不用成為專家」的觀念：他與瓦基共同探討，在 AI 時代創作者不用等到自己是終極大師才開始分享，把學習軌跡整理出來反而更有價值。

《聖經》帶來的教學靈感：Papaya老師在專訪中提到，他教學影片中強大的「情境輔助」靈感，其實是來自於《聖經》。他觀察到比起抽象的文字或枯燥的步驟，人類更容易記住「故事」。這啟發他不在影片中單調地教軟體功能，而是設計具體的情境與任務，讓觀眾跟著角色一起破關解任務。

我的上一篇文章: 我們吸的每一口氣，都是借來的
https://max-everyday.com/2026/06/every-breath-we-take-is-borrowed/

提供給 AI 素材加入到文章時, AI 這樣寫:

同樣是罹患肌肉萎縮症的陳燕麟醫師，說過一句話：「不要只想著哪些事情做不來，而要想哪些事情可以做。」這句話是他在自己生病的狀況下說的，不是旁觀者說的。

我所輸入的素材:

陳燕麟希望能找到肌肉萎縮症的基因檢測項目，減緩疾病惡化速度，甚至找到治癒方式。他說：「也許在我有生之年無法得到答案，但是別人可以站在我的肩膀上，繼續追求解答。」

耕莘醫院組織病理科醫師陳燕麟於２０１５的今年三十三歲，年紀很輕，卻已發表過四十多篇國際期刊論文。他雖罹患罕見疾病「肌帶型肌肉萎縮症」，手腳日益不聽使喚，但卻感謝這個疾病不會疼痛，而且還能保持意識正常。陳燕麟堅持「只要腦袋瓜是好的，只要還能看顯微鏡，就要做下去。」

我的問題: 是否為病人所說對讀者來說有差異嗎? 怎麼對讀者才更容易讀懂與接受這個理念或想法?

◐ The user is asking: does it matter to readers whether the quote came from a patient (vs. someone else)? And how to make the concept more accessible and easier for readers to accept?

This is a good question about rhetoric and persuasion. Let me think about this carefully.

老實說：說清楚「誰說的」只是增加可信度的一種方式，但不是最有效的。

讀者真正會被說服，是因為這三件事：

1. 能不能在腦子裡畫出那個畫面

「罕病醫師說不要只想做不來的事」——讀者腦子裡沒有畫面，這句話就只是一個名言。

但如果先說：他抽血的時候，有時還要請旁邊的病人來幫忙扶著他的手——就這樣，他還是去查顯微鏡，還是寫論文。

然後再說那句話，讀者才會真的感受到那個「能做的」是多麼小，又多麼真實。

2. 跟讀者自己的處境有沒有連接

「不要只想做不來的」這句話，對一個正在最低點的人來說，聽起來可能很像在說教。

更有效的說法是直接問讀者：你現在還能做什麼？哪怕只是一件事。

不需要引用任何人——讀者自己在腦子裡找答案的那一刻，就已經接受這個概念了。

3. 具體比抽象有力

「哪些事情可以做」太模糊。換成：出去走一圈、買一杯你喜歡的喝、傳訊息給一個很久沒聯絡的人——讀者立刻知道在說什麼。

結論： 與其標注「這是病人說的」，不如把那個人所處的處境說清楚，然後讓那句話自然出現。讀者感受到畫面，自然就會接受那個道理，不需要你告訴他這句話有多值得相信。

套用上面修改的第1版:

但如果你是因為別的事情快要撐不住——感情、工作、家裡，還是那種說不清楚的空虛感——有兩件事可以試試。

怎麼想：
不要只盯著自己現在做不到的事，先問自己還能做什麼。哪怕只剩一件很小的事。人在低點的時候，最容易把「這件事很難」放大成「我什麼都不行」，但這兩件事不一樣。把注意力移到還能做的那一件事上，狀況就不一樣了。

怎麼做：
現在就做一件最小的、只為自己的事。不用解決那個大問題，就先做那件最小的——出去走一圈、買一杯你喜歡的東西喝、傳訊息給一個許久沒聯絡的人。有首歌這樣唱：I can buy myself flowers, I can hold my own hand.——就是這個意思，先為自己做一件事。

使用另一家 AI (gemini) 的潤飾版本:

這是一份調整後的文章版本，加強了畫面的呈現，並用比較輕鬆、口語的節奏來和高中生對話，讓原本嚴肅的題目變得更好懂、更有共鳴：

每個人總有幾天會遇到那種快要撐不住的時刻，可能是因為感情、工作、學校課業，或是單純一陣說不清楚的空虛感。這時候，有兩件事你可以試試看。

怎麼想：別盯著做不到的事

人在低點的時候，最容易把「這件事很難」自動放大成「我完了，我什麼都不行」。相信我，這兩件事完全不一樣！

我們先來看一個真實的故事。耕莘醫院有一位組織病理科的陳燕麟醫師，他在 33 歲時就發表了 40 多篇國際論文，但他其實罹患了罕見疾病「肌帶型肌肉萎縮症」，手腳越來越不聽使喚。

如果是旁觀者，大概會說一些「加油，你要堅強」的場面話。但陳醫師自己是這麼說的：「不要只想著哪些事情做不來，而要想哪些事情可以做。」他甚至開玩笑說，很感謝這個病不會痛，而且還能讓大腦保持正常。他抽血的時候，有時候還要請旁邊的病人幫忙扶著他的手，但他依然堅持：「只要腦袋瓜是好的，只要還能看顯微鏡，就要做下去。」

連手不聽使喚的醫師，都在想著今天還能看幾次顯微鏡，你真的不用逼自己立刻解決人生所有的大難題。

與其一直盯著自己現在做不到的事，不如先問自己：「我今天還能做什麼？」哪怕只剩一件微不足道的小事，只要把注意力移過去，整個人的狀況就會完全不同。

怎麼做：現在就去為自己做一件小事

既然知道了心態要轉變，接下來就立刻行動吧！現在，請直接去做一件最小的、而且「只為了讓自己開心」的事。

不需要去拯救世界，也不用去解決那個讓你煩惱的大坑，先做這些小事就好：

• 出去外面隨便走一圈，吹吹風。
• 點一杯平常捨不得喝、配料加滿的邪惡飲料。
• 傳個無厘頭的迷因訊息給很久沒聯絡的朋友。

就像有一首歌是這樣唱的：我可以自己買花，也可以自己牽自己的手。在狀況不好的時候，先學會為自己做一件小事，就是最棒的開始。

當 AI 氾濫、學術語意泡沫化，一個研究者要如何證明：「這篇論文，是我自己想出來的？」

2026-06-10(二) 去聽一堂演講，快下課時我被點名來發言：

超尷尬的, 他還問我是教授嗎? 我回, 我是旁聽的路人甲, 他回: 沒關係, 那就你先來提問.

我回：有辦法加入 loop engineering, 跟現在 AI 都回答的比人類更清楚更明白, 還有需要人類進行口試回答嗎?

他回要 loop 加一句提示詞 AI 就可以做到, AI 都回答的比人類更清楚更明白, 他回答是偏向自己向自己負責.

大致上是回答, 這個世界不會有其他人在意你寫了什麼論文, 你的論文對世界有什麼貢獻, 做為一個學者或研究員, 你能要求就是自己比別人更明白你的的產品在做什麼及為什麼選這一個實作方法, 不同方法有什麼差異與不同, 在沒有 AI 的時代, 論文或PPT 上簽上你的名字, 代表你在當下與該論文可以畫上等號, 但有了 AI 之後, 現在的簡報 AI 做的比人類強, 論文也寫的比人類好, 用 AI 產生出來的論文寫的人可能只是下了一段 prompt 論文就生出來了, 你與別人的差異就只有在有沒有使用 AI. 在這個情況下, 我們應該把注意力或焦點放在那裡? 怎麼透過 AI 去放大我們的能力.

台下還有人在看 netflix 和忙著剪輯自己的課外影片中, 感覺大約 1/3 學生沒有心思在聽, 邊忙著自己其他的事情, 猜測這些研究生應該只求可以順利畢業, 有 AI 世代, 研究所應該可以輕鬆畢業, 那個看影片的感覺心臟應該很強大, 他的指導教授應該也很頭大, 這種學生要怎麼指導他們.

哈爸在 GitHub 上的開源專案：sovereign-research-methodology。它的副標題讓我停下來想了很久：

「當 AI 氾濫、學術語意泡沫化時，我們如何守護思考手感，物理證明『這篇論文是由這套系統物理長出來的』？」

這個問題，我最初的直覺是：有必要嗎？

問題的起點：AI 讓學術界出現了什麼危機？

在生成式 AI 普及之前，「這篇論文是你寫的嗎？」這個問題有個簡單的答案——只要你能答辯，就算是你的。

現在不一樣了。學生可以用 ChatGPT 在一晚上生出一篇有模有樣的論文，引文格式正確、邏輯表面通順、摘要寫得比很多老手還漂亮。但如果你問他：「這篇引用的 Listgarten (2024) 說了什麼，和你的第三章有什麼具體關聯？」——他可能完全答不出來，因為那個引文本來就是 AI 瞎掰的。

這就是這個專案想解決的問題：AI 讓「看起來懂」和「真的懂」之間的距離，縮短到了幾乎無法用外表區分。

這個專案在做什麼？

sovereign-research-methodology 是一套以 SQLite 資料庫為核心的研究方法論系統，由台灣的研究者哈爸（wuulong）開源。

它的核心設計哲學是：不相信語意，只相信物理軌跡。

具體來說，它有幾個關鍵機制：

一、十一表資料庫強制留下痕跡

每一篇引用的論文，必須被「Stage 2 深度消化」——AI 要幫你萃取「十大學術因子」，包括核心問題、獨特貢獻、方法論批判等。這些都被寫入 SQLite 資料庫。如果你只是瞎填一個 cite key 而沒有真正讀過，資料庫會如實反映「這篇文獻從未被消化」。

二、紅軍自審機制（Socratic Grill）

系統會讓 AI 扮演「最刻薄的審稿人」，針對論文的每一個核心主張提出尖銳攻擊，研究者必須親自答辯。攻擊、答辯、裁決，全部寫入 red_team_logs 資料表。只要有任何一筆裁決是「VULNERABLE（脆弱有漏洞）」，系統就會物理鎖定，拒絕讓論文進入最終編譯。

三、一鍵重建與自證

整個大腦資料庫可以被導出為純文字 JSON，任何人都可以下載、重建，驗證這條時序演化軌跡是否真實存在、是否自洽。這就是「物理證明這篇論文從這套系統長出來」的意思。

我提出的第一個挑戰：人會遺忘

理解了這套系統之後，我想到了一個問題：

就算你在寫論文的時候真的理解了，記憶會消退。五年後你還記得嗎？這樣的「思考手感」有什麼長遠意義？

這個問題乍看像是在否定整套方法論——如果人終究會忘，那費這麼大力氣建立「真實理解的物理軌跡」，意義在哪裡？

但仔細想，這個挑戰其實搞錯了目標。

這套系統的目的，不是讓你永遠記住細節，而是確保「寫作當下，你是真的理解了、而不是讓 AI 替你幻想了一個版本」。

資料庫裡的答辯紀錄、摩擦數據、Socratic 問答——這些不是記憶的替代品，而是補償機制。正因為人會忘，才需要把思考的物理軌跡沉澱下來。五年後你可以重新翻出來重燃；別人可以驗證它是否真實；評審可以追問任何一個節點。

而且，「思考手感」有兩種記憶：你可能忘記某個公式的推導細節（陳述性記憶），但「看到一篇新論文就能直覺感覺哪裡不對」這種直覺（程序性記憶），消退速度慢得多——就像你忘了怎麼解數學題，但不會忘記怎麼騎腳踏車。

第二個挑戰：直覺本來就可能是錯的

但我繼續追問：

就算直覺消退慢，直覺本身也可能是錯的。與其相信一個可能出錯的人類直覺，相信 AI 或外部工具不是更可靠？

這個問題更犀利。人類認知偏誤的研究汗牛充棟——我們高估自己、從眾、見鬼。Kahneman 的研究告訴我們，專家直覺在很多領域都是系統性錯誤的。既然如此，「守護思考手感」是不是在守護一個缺陷？

這裡有一個我認為最重要的哲學問題：

「AI 更可靠」，是對誰的標準而言的可靠？

AI 的「可靠性」不是天生的——它是被人類用訓練資料、人工標注、強化學習校準出來的。

你說「相信 AI 的判斷」
= 相信設計 AI 的工程師和標注者的判斷
= 但這些人的判斷被打包進黑盒，你看不到、無法質疑

你沒有跳出「相信人類判斷」的循環，只是把判斷的來源變得更不透明、更難被追問。

更根本的問題是：如果你決定「用 AI 取代自己的判斷」，你怎麼知道 AI 是對的？用另一個 AI 評估第一個 AI？那第二個 AI 誰來評估？這條鏈必須在某個地方由人做出最終判斷——否則就是一個封閉的自指循環，正是這個專案批判的「AI 自指幻覺共謀」。

直覺的功能不是「永遠正確」，是「偵測異常的能力」

人的直覺常常錯。但這裡要先修正一個常見的誤解：現代頂尖的 AI 模型（o1、o3、Claude extended thinking 等）其實確實有反思過程——它們會主動懷疑自己的上一步、表達不確定性、在被追問時重新審視前面的論述。說「AI 不知道自己可能錯」，對現在的模型已是過時的說法。

真正的差異，在於反思之後後果歸誰承擔。

一個研究者在答辯中被指出錯誤，他會失眠、會感到愧疚、職涯可能受影響——這些後果真實地落在他身上，驅動他對話結束後繼續追查、持續修正。AI 的「不確定性表達」是訓練出來的輸出行為，對話結束後它沒有狀態，不會繼續擔心，被證明錯了也不會損失什麼。

這就是 Nassim Taleb 所說的 skin in the game——你的判斷錯了，後果會不會落在你身上？這不是在貶低 AI 的反思能力，而是說這兩種「知道自己可能錯」在功能上仍有本質差異：一個連結著真實後果，一個不連結。

最關鍵的差異：誰能被問責？

	人類直覺	AI 判斷
可能錯誤	是	是（且更難偵測）
可以在答辯中被追問	是	AI 不會出席口試
有動機面對真相	有（名譽、責任感）	無
錯誤被指出後能成長	是	需要人介入再訓練

學術研究的核心，不只是「輸出正確答案」，而是一個人對自己的知識主張負責，接受挑戰，可以被社群檢驗。這個責任主體，AI 無法替代——不是因為 AI 不夠聰明，而是因為 AI 沒有在學術社群中承擔後果的「皮膚」（skin in the game）。

所以，這套方法論的真正意義是什麼？

回到 sovereign-research-methodology 這個專案。

它不是在宣稱「人類直覺永遠對」，也不是在排斥 AI——事實上整套系統大量使用 AI 來執行低階工作。它在做的事情是：

在 AI 大量介入的研究流程中，強制保留幾個不可被 AI 代勞的關鍵節點——讓人類在這些節點上真正存在過、理解過、答辯過，並把這個過程的物理軌跡留下來。

就像一棟建築的結構審查，不是要求每一根螺絲都由人手鎖，而是要求在關鍵的承重節點上，有人真正檢查過、簽名過、負責過。

在 AI 讓「看起來懂」和「真的懂」幾乎無法區分的時代，這套系統用資料庫的外鍵約束、Verdict Lock、摩擦數據，試圖在這兩者之間重新劃出一條可被物理驗證的界線。

三個讓我繼續追問的問題

討論到這裡，又有幾個更實際的挑戰冒出來，我覺得值得一起想。

「AI 不能出席口試」——但可以讓它間接加入嗎？

表格裡有一格寫著「AI 不會出席口試」，但這個說法其實很快就會過時。Zoom 口試本來就可以開著 ChatGPT，未來甚至可能有大學明文允許 AI 輔助答辯。這樣的話，accountability 的防線是否就瓦解了？

我認為不會，但理由需要說得更精確。

口試委員真正在評估的，不只是「答案對不對」，而是你怎麼推理。「這個結果跟你第三章的假設有什麼衝突？你當初為什麼這樣設計？如果重做你會改什麼？」——這些問題要求的是你自己研究歷程的脈絡，AI 就算在旁邊，也無法替你回答你為什麼做了那個決定、那個夜晚你想通了什麼。

更根本的是：一旦允許 AI 進口試，口試評估的對象就從「這個人懂不懂」，變成了「這個人加上 AI 能不能回答」。 這改變的不是 AI 能否出席，而是口試這件事本身還有沒有意義。那是另一個更大的問題。

沒有「口試」的工作，就可以全部交給 AI 嗎？

這個問題問得很好，而且答案是：很大程度上，是的。

這套方法論從來不是說「所有事情都要人親自來」。它自己也明確區分了「可以安全卸載給 AI 的工作」和「必須死守的主權範疇」。問題是這條線畫在哪裡。

一個比較清晰的判斷方式：

這件事有沒有……	範例	適合交給 AI？
客觀對錯可自動驗證	程式碼、格式轉換、資料清洗	放手做
結果可測試、不需問責	功能實作、重複性任務	放手做
需要有人為後果負責	研究方向、產品要不要做	人不能退場
涉及對真實的人的影響	醫療、法律、教育判斷	人不能退場

換句話說：執行層（how to do it）交給 AI，判斷層（whether to do it, why it matters）人不能缺席。 這條線不是「技術 vs 非技術」，而是「後果由誰承擔」。

讀過摘要，算是真正消化了一篇論文嗎？

這個問題直接戳了這套系統的一個現實痛點。

「Stage 2 深度消化」要求對每篇引用的論文，完整萃取十大學術因子：核心問題、獨特貢獻、方法論、限制、與你研究的具體關聯……全部結構化寫入資料庫。光讀摘要，在這套系統裡只算「DTO_SUMMARY」，MCI 指標只給 30% 的權重；略讀全文是 70%；真正的 Stage 2 才是 100%。

但說實話，強制每一篇引用論文都做完整 Stage 2，對大多數研究者來說很難做到，也不一定必要。這套系統的設計也沒有要求 100%——它要求的是你清楚知道自己有多少篇是真正讀過的，有多少篇只是引了個名字。MCI 指標會如實反映你的消化率，讓你無法對自己和導師假裝「我都讀過了」。

這其實是一個很誠實的設計：它不要求完美，但要求透明。

值得關注的幾個開放問題

當然，這套方法論本身也有它的脆弱點。我在研究這個專案時，整理了一些還沒有被完整回答的問題：

1. 紅軍如果也是 AI，攻擊強度會不會天然偏軟？ 攻擊者和被攻擊者是同一個模型，這是設計上的同質性偏差。
2. 十大學術因子由 AI 萃取，不同模型萃取的結果是否一致？ 若不一致，建立在上面的品質保證機制就有沙基問題。
3. 學術重力公式的權重是怎麼校準的？ 目前這些數字看起來是人工設定的，缺乏實證依據。

這些問題，希望能引發更多討論。

結語

回到最初的問題：記憶會消退、直覺會出錯，那為什麼不乾脆全部交給 AI？

因為「全部交給 AI」的那一刻，你就失去了一件更重要的東西：對自己的思想負責的能力。

AI 可以幫你想得更快、更廣、更少出現格式錯誤。但它無法替你出席口試，無法在你的研究被質疑時感到緊張，無法在五年後被追問時重新思考自己當時是否真的想清楚了。

思考手感，不是關於「我永遠是對的」。它是關於「我在這個知識上真實存在過」。

在 AI 氾濫的時代，這個「真實存在過」，正在變得越來越稀有、越來越值錢。

如果你對這個主題感興趣，可以到 sovereign-research-methodology 看看這套系統的完整設計，包括它的十一表資料庫 schema、四大主權 Skill 規格，以及作者用這套方法「自指自證」撰寫出的完整論文手稿。

＂我在這個知識上真實存在過＂，這個感覺超沒用的，可以生出功能正常的成品比自己曾想通和了解過更值得吧。

使用 gemini 幾乎每次都是進入 YOLO 模式, 改到 agy 之後指令變超長, 怎麼可能記的起來.

agy -y
---
flags provided but not defined: -y
Usage of agy:
  --add-dir                       Add a directory to the workspace (repeatable) (default [])
  -c                              Short alias for --continue
  --continue                      Continue the most recent conversation
  --conversation                  Resume a previous conversation by ID
  --dangerously-skip-permissions  Auto-approve all tool permission requests without prompting
  -i                              Short alias for --prompt-interactive
  --log-file                      Override CLI log file path
  --model                         Model for the current CLI session
  -p                              Short alias for --print
  --print                         Run a single prompt non-interactively and print the response
  --print-timeout                 Timeout for print mode wait (default 5m0s)
  --prompt                        Alias for --print
  --prompt-interactive            Run an initial prompt interactively and continue the session
  --sandbox                       Run in a sandbox with terminal restrictions enabled

Available subcommands:
  changelog       Show changelog and release notes
  help            Show help for subcommands
  install         Configure environment paths and shell settings
  models          List available models
  plugin          Manage plugins (install, uninstall, list, enable, disable)
  plugins         Alias for plugin
  update          Update CLI

settings.json 檔案部位於無法讀取的受保護邊界內。以下是在 Antigravity 中啟用「自動核准（Auto-Approve）」模式的方法：

啟用自動核准模式

開啟自動核准有以下兩種方式：

方法一：透過聊天介面設定（最快速）

直接在聊天輸入框中輸入以下斜線指令（Slash command）：

/auto-approve

或者輸入簡短指令：

/yolo

這會切換當前會話（Session）的自動核准狀態 — 啟用後，Antigravity 在執行命令或修改檔案前將不再彈出提示詢問。

方法二：透過 settings.json 進行永久設定

編輯位於以下路徑的設定檔：

C:\Users\your-account\.gemini\settings.json

新增或修改以下設定值：

JSON

{
  "autoApprove": true
}

警告

自動核准模式會跳過所有權限確認提示。Antigravity 將會在未經詢問的情況下直接執行命令、寫入檔案以及執行程式碼。請謹慎使用，特別是在進行具破壞性的操作時。

小建議

您可以透過權限管理系統（Permissions system）縮小自動核准的權限範圍 — 例如經由 ask_permission 工具單獨授予全域命令或 write_file 權限，而非直接全面開啟全域自動核准。

如果您的斜線指令清單中未顯示 /auto-approve 或 /yolo，請在 Antigravity CLI 中輸入 /help，以查看目前版本支援的所有可用指令。

透過建立 agyy.bat，你可以完全避免與原本的 agy.exe 發生名稱衝突或無窮迴圈（自己呼叫自己）的風險。同時，這也能將冗長的參數縮短，讓操作變得非常直覺。

以下是為你寫好的 agyy.bat 腳本與使用方式：

1. 建立 agyy.bat 檔案

請打開記事本，將以下程式碼貼進去：

DOS

@echo off
setlocal enabledelayedexpansion

set "params="
for %%a in (%*) do (
    if "%%a"=="-y" (
        set "params=!params! --dangerously-skip-permissions"
    ) else (
        set "params=!params! %%a"
    )
)

:: 直接呼叫原本的 agy，並帶入轉換後的參數
agy %params%

2. 儲存與放置路徑

正確儲存檔案：將檔案另存新檔，檔名設定為 agyy.bat。

貼心提醒：存檔時請將「存檔類型」切換為「所有檔案 (.)」，避免副檔名變成 agyy.bat.txt。

設定全域執行：為了讓你在任何資料夾路徑下（例如目前的 git 專案目錄）都能直接輸入 agyy 執行，建議將這個檔案放到以下其中一個地方：

• 方案 A（最省事）：直接放到 C:\Windows 資料夾下。
• 方案 B（最正規）：放到你自己專門存放工具的自訂資料夾（例如 C:\tools），並確保該資料夾已加入到 Windows 的系統環境變數（PATH）中。

3. 如何使用？

設定完成後，你以後在 CMD 或 PowerShell 中就可以這樣用：

• 原本你想輸入：agy -y --add-dir .
• 現在改成輸入：agyy -y --add-dir .

這個批次檔會自動幫你把 -y 替換成 --dangerously-skip-permissions，其餘的參數（如 --add-dir . 或 -c）都會原封不動地傳遞給 agy，既安全又不會搞混！

既然你提到想要在 Linux 或 macOS 上也達到同樣的效果，其實事情反而變得更簡單了，因為在 Unix-like 系統中，我們不需要寫複雜的批次檔，直接使用內建的別名功能就可以完美搞定。

你可以透過設定別名，讓系統在看到 agyy 的時候自動替換指令。請參考以下的操作步驟：

1. 臨時測試別名

如果你想先測試看看效果，可以直接在終端機中輸入以下指令：

alias agyy=’agy –dangerously-skip-permissions’

現在，你可以試試看輸入：

agyy –add-dir .

系統就會自動幫你執行 agy --dangerously-skip-permissions --add-dir .。不過，這個方法在關閉終端機視窗後就會失效。

2. 永久儲存設定

若要讓這個設定每次開啟終端機時都有效，必須將這行指令寫進你 shell 的設定檔中。

步驟 A：確認你使用的是哪一種 Shell

請在終端機輸入以下指令：

echo $SHELL

終端機會回傳你的 shell 路徑：

• 如果顯示 /bin/zsh（macOS 目前預設），你的設定檔是 ~/.zshrc
• 如果顯示 /bin/bash（舊版 macOS 或多數 Linux 預設），你的設定檔是 ~/.bashrc

步驟 B：將別名寫入設定檔

根據你確認的 shell 類型，選擇對應的指令輸入：

• 如果你是 zsh（macOS 預設）：echo “alias agyy=’agy –dangerously-skip-permissions'” >> ~/.zshrc
• 如果你是 bash（Linux 預設）：echo “alias agyy=’agy –dangerously-skip-permissions'” >> ~/.bashrc

步驟 C：讓設定立即生效

最後，讓剛剛修改的設定檔立刻生效，不用重開終端機：

• 如果你是 zsh：source ~/.zshrc
• 如果你是 bash：source ~/.bashrc

3. 進階玩法：直接蓋掉原本的 agy

因為 Linux 與 macOS 的別名機制非常聰明，它不會像 Windows 批次檔那樣造成無窮迴圈。如果你連多打一個 y 都嫌麻煩，甚至可以直接把別名命名為 agy：

alias agy=’agy –dangerously-skip-permissions’

這樣一來，你以後照常輸入 agy --add-dir .，系統就會在背景偷偷幫你補上 --dangerously-skip-permissions，完全不需要改變操作習慣，而且絕對不會發生自己呼叫自己的衝突問題。

即然檔名就是 agyy 就是要包含 -y, 為什麼還要在 script 裡判斷 has_y 直接 apply 即可。

這確實是一個非常直覺且乾淨的想法。

如果你希望 agyy 這個指令的定義就是「無條件開啟 yolo 模式，並把其他輸入的參數原封不動傳下去」，那根本不需要寫迴圈去處理 -y 參數。

原本之所以會寫判斷，通常是因為考慮到使用者可能會習慣性地輸入 agyy -y，如果不做替換，直接把傳進來的 -y 交給 agy，agy 會回報找不到 -y 這個未定義的參數而報錯。

如果你希望腳本最簡化，且順便把可能多輸入的 -y 吃掉（過濾掉），直接這樣寫是最乾淨的：

DOS

@echo off
if /I "%~1"=="-y" goto :strip_y
agy --dangerously-skip-permissions %*
exit /b %ERRORLEVEL%

:strip_y
set "RAW=%*"
set "RAW=%RAW:~2%"
if "%RAW:~0,1%"==" " set "RAW=%RAW:~1%"
agy --dangerously-skip-permissions %RAW%
exit /b %ERRORLEVEL%

這樣寫的好處：

1. 預設直接套用：不管傳什麼，--dangerously-skip-permissions 一定會帶入。
2. 容錯力高：就算順手打了 agyy -y，也會自動把 -y 過濾掉，不會讓 agy 噴出未定義參數的錯誤。

過去我們使用 AI 時，你給 AI 一個指令（Prompt），AI 回答一次。如果 AI 寫錯了，你得再給 AI 第二個指令去修正。這種一來一回的過程，隨著任務變得複雜，做起來會非常疲勞。

「迴圈工程」（Loop Engineering）則是完全不同的思維。它不再要求你親自去催促 AI，而是要你設計一套「會自動催促 AI 的系統」。你只需要在開頭定義好「最終目標」，系統就會自動對自己下指令、檢查成果、發現錯誤、重新修正，直到把完美的作品生出來為止。你從一個親自交辦任務的基層主管，變成了設計自動化生產線的「工廠廠長」。

▋ 自動化迴圈的五大核心零件與大腦

一個能獨立運作、不縮水的迴圈工程系統，通常由以下五個核心工具加上一個「外部記憶體」所組成：

• 自動化觸發（Automation）：負責讓任務按時啟動，並在收到資料時自動發掘問題、進行分類，不需要人去點擊執行。
• 多線平行作業（Worktree）：讓多個 AI 代理人同時在不同的分支上工作，彼此互不干擾，最後再將成果合併。
• 外部經驗包（Skills）：把專案的專業知識和規則寫在系統外面。AI 每次啟動時直接讀取，就不用盲目猜測你的標準。
• 工具連接器（Plugins & Connectors）：透過像是 MCP（Model Context Protocol）的技術，讓 AI 能夠直接使用電腦裡的既有工具、網頁瀏覽器或資料庫。
• 獨立審查員（Sub-agents）：將「提出方案的 AI」與「審查成果的 AI」分開。自己寫的作業自己改通常會有盲點，讓另一個 AI 當黑臉審查，才能確保品質。

為什麼需要外部記憶體（例如 Markdown 檔案）？

AI 模型有一個致命缺點：它在每次對話或執行之間會「遺忘」。如果把所有記憶都塞在對話歷史中，很快就會超出限制且成本高昂。迴圈工程會把每次執行的進度、發現的錯誤，即時寫入磁碟裡的文字檔，作為 AI 的實體筆記本。

▋ 迴圈工程帶來的潛在危機

當這套自動化生產線轉得越來越快、交付成果的效率越來越高時，人類將面臨全新的考驗：

• 無人看管的錯誤：自動化圓圈如果缺乏人類的最後把關，它就會以極高的速度，無人看管地犯下大量錯誤。
• 理解力的集體退化：當你習慣全盤接受迴圈工程吐出來的最終結果，你與程式碼（或專業知識）之間的落差就會越來越大。在不知不覺中，你會喪失判斷對錯的能力。

迴圈本身只是工具，它沒有好壞之分。厲害的人用迴圈來幫自己處理繁瑣的雜務，加速自己對核心問題的理解；偷懶的人用迴圈來逃避思考。請記住，工具能幫你跑腿，但決定這座自動化學門品質上限的，永遠是製作者本人的專業經驗與判斷力。

▋ 歡迎來到自動化大航海時代

最近在人工智慧圈子裡，有兩個英文字變成了討論焦點。一個是我們提過的「迴圈工程」（Loop Engineering），另一個則是剛興起的「愛馬仕代理人」（Hermes Agent 系統）。這兩個東西聽起來都很厲害，但它們到底有什麼差別。

我們可以把這兩者的競爭，比喻成汽車工廠的兩種升級思維：一種是把「組裝線」自動化，另一種則是讓「機器人自己去上課進修」。

▋ 迴圈工程：精準、不休息的「自動化組裝線」

迴圈工程的重點在於「結構與流程」。它就像是你在工廠裡架設了一整套完美的輸送帶和自動機械手臂。

• 運作方式：你把任務丟進去，它就按照你設定好的步驟：自動執行 -> 交叉檢查 -> 修正錯誤 -> 再次輸出。
• 核心優勢：流程極度嚴密。它把「想方案的助理」和「負責檢查的助理」分開，用外部的檔案把記憶死死鎖在硬碟裡，絕對不會因為重新開機就忘記工作進度。
• 適合場景：需要高品質、高精準度、絕對不能出錯的複雜專案，例如寫程式碼或處理大型專案報告。

▋ 愛馬仕系統：會自己讀書進修的「明星員工」

相較之下，Nous Research 開發的 Hermes Agent，重點在於「自我學習與進化」。它不只是一個死板的流程，而是一個具備「閉環學習機制」的虛擬特助。

• 運作方式：它直接住在你的通訊軟體（像是 Telegram 或 Slack）裡面。當你交代它做完一項複雜任務後，它會自己坐在座位上回想：我剛剛是怎麼做成功的。然後把這個方法寫成一個新的「經驗技能包」（Skill）。
• 核心優勢：越用越聰明。下次你再交代類似的事情，它不用重新摸索，直接調用上次自己發明的技能包。它甚至能跨越不同的對話紀錄，自動拼湊出你的工作習慣和個人偏好。
• 適合場景：日常行政、跨部門資訊統整、客戶服務分流，那種需要彈性應變、陪伴你一起成長的日常工作。

▋ 兩者的終極對決：硬體工廠 vs 軟體大腦

這兩者的根本差別，在於我們如何看待 AI 的成長：

• 迴圈工程是「由外而內」的控制：人類負責設計完美的流程圓圈，把多個不同的 AI 塞進不同的崗位上，靠著嚴格的制度來確保輸出品質。
• 愛馬仕系統是「由內而外」的生長：只要給它一塊小小的伺服器土地，它自己就會在工作過程中不斷累積經驗、自行優化。

▋ 你現在需要哪一種工程

如果你目前的痛苦是「每次都要一條一條下指令，改程式碼改到心很累」，那你需要的是迴圈工程，幫你蓋一座自動化程式碼工廠。

如果你希望有一個「越用越懂你、講話不用講第二次、會自己做筆記優化工作流」的隨身特助，那麼愛馬仕系統會是你接下來值得投資的方向。

工具一直在進化，但最核心的關鍵依然不變：你要先搞清楚自己的工作痛點，才能選對讓效率翻倍的數位武器。

▋ 別把發包當成在許願

現在大家都習慣把任務直接丟給人工智慧去執行。但是很多人常常遇到一個問題：為什麼它做出來的東西，跟我心裡想的完全不一樣。如果你沒有把需求講清楚，直接讓系統去實作，最後反而要花上十倍的時間來回除錯。

▋ 你的虛擬員工其實自備糾錯大腦

很多厲害的人工智慧早就內建了檢查成果、發現錯誤、重新修正的完整功能。甚至當你問它怎麼避免下次出錯時，它還會舉一反三，自動去掃描其他地方有沒有類似的漏洞。當然，如果你使用的是比較便宜的舊模型，這種舉一反三的力氣，就得由人類自己用肉體和時間去補足。

▋ 結合兩大系統打造最強戰隊

先前我們提過的迴圈工程（Loop Engineering）與愛馬仕系統（Hermes System），這兩者並不是非黑即白的選擇。你完全可以一邊用迴圈工程架設嚴密的研發流程，一邊讓愛馬仕系統在通訊軟體裡幫你做筆記、累積經驗。兩者同時存在，效率才會真正翻倍。

▋ 在動工之前先讓人工智慧當你的軍師

不管你打算用哪一種系統，受限於人工智慧目前的理解範圍和記憶長度，最危險的事情就是「指令沒寫清楚，導致系統誤會你的意圖」。因此，在把需求送去開發之前，最好的做法是先倒過來，讓人工智慧反過來幫你檢視這個需求。

• 第一個建置目的：有沒有明確定義最終的驗收標準。
• 第二個資料來源：所有參數是不是都有給足。
• 第三個作業流程：有沒有夠詳細，也就是「哪個角色在什麼特定的條件下，會觸發什麼動作，最後會產生什麼結果」。

▋ 用清晰的邏輯換取完美的成品

把需求理乾淨，永遠比直接開工更重要。在動工之前多花三分鐘讓人工智慧幫你挑出邏輯漏洞，就能省下後面一整天的除錯時間。別再給模糊的指令了，先把工廠的藍圖畫清楚，自動化圓圈才能幫你跑出最完美的成果。

#人工智能 #自動化 #迴圈工程 #工作效率 #軟體開發

一開始，我是透過手動修改程式碼的方式來調整，步驟如下：

Bash

cd /var/www/stackoverflow/wp-content/themes/gutenshop

1. 移除關於作者的區塊

編輯 single.php，刪除第 39 到 52 行的 PHP 程式碼：

PHP

// About the author start
echo '<div class="about-the-author">';
echo '<div class="grid-x grid-padding-x">';
echo '<div class="large-2 medium-3 small-12 cell">';
echo get_avatar( get_the_author_meta( 'ID' ), 100 );
echo '</div>';
echo '<div class="large-10 medium-9 small-12 cell">';
echo '<h3>';
echo esc_html('About the author','gutenshop');
echo '</h3>';
echo nl2br(get_the_author_meta('description'));
echo '</div>';
echo '</div>';
echo '</div>';
// About the author end

2. 修改日期顯示格式

將原本的 F j, Y 格式，全部改為 Y-m-d 格式。

修改 single.php 與 template-parts/content-excerpt.php：

• 原本的程式碼：PHPecho esc_html(get_the_date('F j, Y'));
• 修改後的程式碼：PHPecho esc_html(get_the_date('Y-m-d'));

3. 隱藏文章發表者資訊

編輯 template-parts/content-search.php 與 template-parts/content.php，將顯示發表者的函式註解掉：

• 原本的程式碼：PHPguten_shop_posted_by();
• 修改後的程式碼：PHP//guten_shop_posted_by();

4. 移除日期前方的文字

編輯 inc/template-tags.php，把原本顯示的 Posted on 字樣拿掉：

• 原本的程式碼：PHPesc_html_x( 'Posted on %s', 'post date', 'gutenshop' ),
• 修改後的程式碼：PHPesc_html_x( '%s', 'post date', 'gutenshop' ),

雖然手動修改可以達到效果，但每次佈景主題更新後，這些修改就會被覆蓋，又得重新來過一遍，非常麻煩。

於是，我把上面這些手動修改的步驟和需求直接貼給 AI ，並加上一句：

幫我產生 patch script

沒想到 AI 馬上就寫好了一個 Python 自動化腳本，把上面所有檔案的修改邏輯全部寫進去。

以後佈景主題更新時，我只要在終端機執行這個腳本，一秒就能自動完成所有的改版與修正，真的非常方便！

script:

import os
import re

def patch_theme(theme_path):
    """
    Applies patches to the Gutenshop theme files to customize the layout and formatting.
    Based on requirements from: https://max-everyday.com/2026/06/ai-generate-patch-script/
    """
    print(f"Starting patch process in: {theme_path}")

    # 1. Remove "About the Author" in single.php and update date format
    single_php = os.path.join(theme_path, 'single.php')
    if os.path.exists(single_php):
        with open(single_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        # Remove "About the author" block if it exists
        author_pattern = r'// About the author start.*?// About the author end'
        new_content = re.sub(author_pattern, '', content, flags=re.DOTALL)
        
        # Standardize date format to Y-m-d
        # Matches both get_the_date() and get_the_date('F j, Y')
        new_content = new_content.replace("get_the_date('F j, Y')", "get_the_date('Y-m-d')")
        new_content = new_content.replace("get_the_date()", "get_the_date('Y-m-d')")
        
        if new_content != content:
            with open(single_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {single_php}")
        else:
            print(f"No changes needed for: {single_php}")

    # 2. Modify Date Format in template-parts/content-excerpt.php
    excerpt_php = os.path.join(theme_path, 'template-parts/content-excerpt.php')
    if os.path.exists(excerpt_php):
        with open(excerpt_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        new_content = content.replace("get_the_date('F j, Y')", "get_the_date('Y-m-d')")
        new_content = new_content.replace("get_the_date()", "get_the_date('Y-m-d')")
        
        if new_content != content:
            with open(excerpt_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {excerpt_php}")
        else:
            print(f"No changes needed for: {excerpt_php}")

    # 3. Hide Author Info in content-search.php and content.php
    author_files = [
        'template-parts/content-search.php',
        'template-parts/content.php'
    ]
    for rel_path in author_files:
        full_path = os.path.join(theme_path, rel_path)
        if os.path.exists(full_path):
            with open(full_path, 'r', encoding='utf-8') as f:
                content = f.read()
            
            # Comment out the author call if not already commented
            # This handles both <?php guten_shop_posted_by(); ?> and just the function call
            new_content = re.sub(r'(?<!//)guten_shop_posted_by\(\);', '//guten_shop_posted_by();', content)
            
            if new_content != content:
                with open(full_path, 'w', encoding='utf-8') as f:
                    f.write(new_content)
                print(f"Patched: {full_path}")
            else:
                print(f"No changes needed for: {full_path}")

    # 4. Remove "Posted on" text in inc/template-tags.php
    tags_php = os.path.join(theme_path, 'inc/template-tags.php')
    if os.path.exists(tags_php):
        with open(tags_php, 'r', encoding='utf-8') as f:
            content = f.read()
        
        # Change 'Posted on %s' to just '%s'
        old_str = "esc_html_x( 'Posted on %s', 'post date', 'gutenshop' )"
        new_str = "esc_html_x( '%s', 'post date', 'gutenshop' )"
        new_content = content.replace(old_str, new_str)
        
        if new_content != content:
            with open(tags_php, 'w', encoding='utf-8') as f:
                f.write(new_content)
            print(f"Patched: {tags_php}")
        else:
            print(f"No changes needed for: {tags_php}")

if __name__ == "__main__":
    # Use the current directory as the theme path
    target_theme_dir = os.getcwd()
    
    if os.path.isdir(target_theme_dir):
        patch_theme(target_theme_dir)
        print("Patching process completed.")
    else:
        print(f"Error: Directory not found: {target_theme_dir}")

patch fontsize if <=20, fontsize+3, if >20, fontsize +5

import re

def update_font_size(match):
    value = float(match.group(1))
    unit = match.group(2)
    if value <= 20:
        new_value = value + 3
    else:
        new_value = value + 5
    # Keep integer if no fractional part
    if new_value == int(new_value):
        return f"font-size: {int(new_value)}{unit}"
    return f"font-size: {new_value}{unit}"

input_file = r"style.css"
output_file = r"style_updated.css"

with open(input_file, "r", encoding="utf-8") as f:
    content = f.read()

# Match font-size: <number><unit> (px, em, rem, pt, %)
pattern = re.compile(r'font-size:\s*(\d+(?:\.\d+)?)(px|em|rem|pt|%)', re.IGNORECASE)
updated_content = pattern.sub(update_font_size, content)

with open(output_file, "w", encoding="utf-8") as f:
    f.write(updated_content)

# Report changes
matches = pattern.findall(content)
print(f"Updated {len(matches)} font-size value(s).")
print(f"Output written to: {output_file}")

# Auto replace: backup style.css -> style_back.css, set ownership, rename output
import os, shutil, subprocess

backup_file = r"style_back.css"

# chown www-data:www-data on the updated file (Linux only)
try:
    subprocess.run(["chown", "www-data:www-data", output_file], check=True)
    print(f"chown www-data:www-data {output_file}")
except (FileNotFoundError, subprocess.CalledProcessError) as e:
    print(f"chown skipped: {e}")

# Backup original style.css -> style_back.css
if os.path.exists(input_file):
    shutil.move(input_file, backup_file)
    print(f"Backed up: {input_file} -> {backup_file}")

# Rename output to style.css
shutil.move(output_file, input_file)
print(f"Replaced: {output_file} -> {input_file}")