20260608 簡評 LLM

Published: June 8, 2026
Updated: August 9, 2026

Gemini: 不重要需要快速回覆的就找他，什麼都會錯，不要期待他內容正確，生圖額度超大根本用不完
Claude: 什麼都可以找他，尤其是重要、需要精確回覆、需要 reference、需要 coding 就找他
Grok: 聊色可以找他
ChatGPT: 想被惹怒可以找他

新發現

要求 AI 複述一次用戶指令的效果非常好，可以用少量 token 換來 AI 先整理過一次想法，我們可以用這個開頭確認他沒有理解錯，他也可以用這個開頭更好的預測後續文字機率，算是簡化版的 thinking 功能。

## 任務目標（大綱）

## 描述（相關知識、背景細節）

## 回應方式

所有回應前都必須先用你自己的話順一次用戶指令

## 要求

本對話所有回應必須嚴格遵守以下要求

1. 禁止任何skill
2. 禁止任何visualization工具
3. 禁止任何thinking功能，thinking過程只能有"SKIP"四個字母

Claude 的 thinking 過程不包含在 context 裡面，而且絕大多數時候 thinking 內容都是垃圾，最近用甚至是 thinking 超過一兩分鐘輸出一點點，絕對浪費超過 5 倍 token，然後最後再回給你一個顯而易見、和使用禁止 thinking prompt 沒差多少的內容給你，你就這樣白白浪費 5 倍 token。

而且錯的想法想再多都是錯的，他只要 thinking 第一步想錯，後面就全都錯，那還不如直接輸出文字。

禁止閱讀 skill 的原因是錯誤觸發的機會更高，讀到沒用的 skill 還會污染 context；禁止 visualization 是因為更多時候是輸出垃圾。

更新

Thinking 絕對浪費超過五倍，我叫他把語法改一下然後去看 MSI，T1 都打完小龍團戰、replay 結束、再打完巴龍團戰，回去看 Claude 還在給我 thinking。

正確的用法應該是明確告訴他該做什麼，然後禁止 thinking，否則你一則輸入可以噴掉一半 2 hour quota。

再度更新關於 thinking

要是想有用的內容、能把 thinking 文字放到 context 裡面那我當然沒差阿，問題是 100 次 thinking 內容有 95 次都毫無意義，問簡單直觀的問題，開始 overly long 的 thinking，問困難複雜的問題 thinking 內容都是垃圾要不然就是從開頭就理解錯誤，那這功能到底有啥路用，簡稱垃圾一個。

更細一點的講，以日常對話為例，這 99.99% 不需要 thinking。再以 CSS 設定為例，CSS 確實可以「想」規則 A 會不會影響 B，然而 LLM 目前的 thinking 不是用來做到這種粒度的，沒有這種思考能力，同樣的道理可以推廣到真正需要「想」的程式設計：他仍然是在認 pattern，這個 pattern 常出現就照樣錯。那 thinking 到底有啥用？其實只是避免大方向做錯而已，所以我才會要求他不可 thinking 改為複述一次指令，也才會說這種做法是「簡化版的 thinking」，因為他自己講一次就能確保最開始的文字機率從好的地方開始。

一個正確的 thinking 應該是列舉出所有做法，然後從用戶描述的狀況一一刪去哪種做法不行，這才是正確的思維：你先知道能怎麼做，然後擇優刪掉有問題的方法，這種想法在非常多地方都可行，大到專案選型決策，中到軟體架構設計，小到函式具體實現都可以這樣想，而 LLM 仍沒有這種能力。

我不否認在數學模型等特化模型上 thinking 確實有用，不然那些 AI 破解數學難題的是哪來的，但是現在的消費級模型 thinking 就是可驗證的垃圾。你把這段貼給 AI 他就會開始跟你槓，講一講他還會把這段話無視當作你沒講過。

前一段更新提到的「Thinking 絕對浪費超過五倍，我叫他把語法改一下然後去看 MSI，T1 都打完小龍團戰、replay 結束、再打完巴龍團戰，回去看 Claude 還在給我 thinking」實際上是讓他看了 zed language extension HTML + jinja 兩個擴充功能後，知道各自怎麼實現的，然後改成 go template 而已，就這麼簡單，我連 go template tree sitter repo 都提供給他了，結果 thinking 過程超過三分鐘，這絕對花了超過十萬 token，最後輸出還是連 build 都失敗。

對這種任務真正的 thinking 應該是什麼？就只是考慮應該是誰作為基礎，誰 inject 誰，就是這麼簡單，一點都不複雜，後續才會考慮 inject 的細節是什麼，比如各種節點的處理而已，但是實際上 AI 的 thinking 不是這樣想的，在程式處理問題上我真的沒有任何一次看懂他的 thinking 是在講什麼。

只要 LLM 還是 transformer，那就還是機率，機率就和思考沒有關係，因為問題不會顯式的出現在文字本身上，不管變的多厲害背後都只是在認 pattern，thinking 也就絕對不是字面意義上的「思考」反而是「確認方向」。只要做不到大局型 thinking（刪去法）或是細節型 thinking（上下兩種設定或是程式碼一一順過邏輯推理）那 thinking 就是垃圾，那你有沒有發現，這裡又說需要邏輯推理了，那不就代表他永遠做不到嗎，他就只有機率沒有邏輯阿。

Claude

現在九成都用他。

不過仍舊很會不承認自己的錯，應該怪用戶：對他期望太高了。

Claude 更新

2026/06/13 開始會自動關閉對話了，滿屌的。

ChatGPT 的噁心語法

到底是在摘要和括弧三小？
- 最小版（建議直接用）
- 關鍵（為什麼這樣就夠）
- 一句話版本（極限）
如果你願意
不是...，而是...

我的 prompt

給出以下 prompt，下一個段落會展示 ChatGPT 的語法有多噁。

資訊

根據這些描述，靜態部落格網站，使用模板引擎搭建，包含頁面js，應該如何選擇？長文分析回覆。

Swup.js

Swup.js 攔截連結點擊，用 fetch 取得下一頁的完整 HTML，然後只替換 JS 指定的 DOM container，核心是生命週期 hooks（willReplaceContent, contentReplaced 等），讓你能在替換前後插入邏輯。Swup 不帶任何伺服器協定，完全是純前端 DOM 操作。

完美符合 Hugo 使用需求，有大量插件且開發活躍，是最適合的套件。

hotwired/turbo

本質是 Rails 生態系的前端協定實作，分為三層：Turbo Drive（整頁切換加速）、Turbo Frames（局部 frame 替換）、Turbo Streams（伺服器推送局部更新）。

Turbo Drive：

替換整個 <body>，merge <head>
有完整 event hook 系統（turbo:before-visit、turbo:before-render、turbo:before-fetch-request 等）
turbo:before-render 可以完全自訂 render function，甚至換成 idiomorph
data-turbo-permanent 保留特定元素跨頁不替換
data-turbo-track="reload" 處理 asset 版本變更
data-turbo="false" 逐元素退出
內建 prefetch（v8 預設開啟）和 preload

Turbo Frames：

從完整 HTML 回應中抽取對應 <turbo-frame id=""> 的內容替換當前 frame
不需要伺服器回傳局部片段（前對話已確認）
但來源頁與目標頁都需要存在對應 ID 的 <turbo-frame> 標籤

Turbo Streams：

需要伺服器回傳 Content-Type: text/vnd.turbo-stream.html，在靜態網站無法實現

超爛回覆

瘋狂換行，瘋狂排比，瘋狂列表，毫無重點，以下是 ChatGPT 回的內容。

=== === === === === === === === === === === === === === === ===

針對「靜態部落格 + 模板引擎（Hugo / Eleventy / Jekyll 類型）+ 頁面內含 JS」，核心選型其實不在於“能不能做 PJAX”，而在於三件事：

內容來源是純 HTML（build-time）還是需要 runtime 組合
頁面切換是 full reload 還是 SPA-like transition
JS 狀態是否需要跨頁維持

下面分層分析 Swup.js 與 Turbo（Hotwire）在這個場景的適配性。

一、靜態部落格的本質約束

靜態部落格通常具備：

build-time rendering（Hugo / Eleventy / Astro static）
每篇文章 = 完整 HTML 頁面
server 無動態 API（或極少）
SEO 依賴完整 HTML
JS 多為：
- TOC
- code highlight
- analytics
- comment embed
- UI enhancement（theme toggle / search）

👉 本質是：多頁應用（MPA）+ 少量前端增強

二、Swup.js 的模型是否適合

Swup 的核心模型

攔截 <a> click
fetch 下一頁 HTML
抽取 container（如 #swup）
替換 DOM
lifecycle hooks（transition 前後）

👉 本質：純前端 PJAX 框架

在靜態部落格中的優勢

1. 完全無後端依賴

Swup 不要求：

特定 HTML tag
server header
frame structure
API 或 stream

👉 非常適合 Hugo / Eleventy

2. DOM 替換模型簡單

只需要：

<div id="swup">
  {{ content }}
</div>

所有 page 都一致即可。

3. 插件生態偏「網站增強」

Swup 插件常見用途：

page transition animation
scroll restore
preload links
head replacement

👉 很貼近 blog UX（平滑切頁）

4. JS 重初始化容易控制

典型問題：

換頁後 highlight / TOC / mathjax 失效

Swup 解法：

hook contentReplaced
重新 init scripts

這對 static blog 是直覺模型

Swup 的限制

1. head 管理較弱（需插件）

meta / title 更新需額外處理
SEO-friendly 依賴 plugin 正確配置

2. 複雜局部更新能力弱

Swup 是：

replace whole container

不是：

structured partial update system

3. 多區域 state 不天然支持

例如：

sidebar 狀態
persistent mini-player
reading progress

都要自己管理

三、Turbo（Hotwire）模型是否適合

Turbo 的核心更接近：

server-driven navigation protocol

但在靜態網站中，它會變成：

“HTML-based SPA navigation system”

Turbo Drive（最重要）

行為：

攔截 navigation
fetch full HTML
替換 <body>
merge <head>

👉 本質：整頁替換 SPA

在靜態 blog 的優勢

1. head 管理天然完整

Turbo 直接處理：

title
meta
stylesheet reload
script tracking

👉 幾乎零配置

2. lifecycle hooks 更細

例如：

turbo:before-render
turbo:render
turbo:load

可以：

swap render engine（甚至 idiomorph）
精細控制 DOM merge

👉 比 Swup 更底層

3. preload / cache 更成熟

Turbo 有：

snapshot cache
page prefetch
instant back/forward restore

👉 blog 翻頁體感非常強

4. permanent state 機制強

<div data-turbo-permanent>

適合：

navbar
music player
theme switcher

Turbo 在 static blog 的問題

1. Frames 是 server-oriented 思維

Turbo Frames：

假設 server 能回 partial HTML

但 static blog：

沒有 API
沒有 partial endpoint

👉 Frames 幾乎用不到

2. 概念偏 Rails

Turbo 本質：

Rails full-stack enhancement layer

在 Hugo/Eleventy 中：

需要「轉譯它的假設」

3. setup 比 Swup 重

需要理解：

cache snapshot
visit restoration
rendering pipeline

對 simple blog 是「偏重」

四、關鍵對比（靜態部落格視角）

1. 架構匹配度

面向	Swup	Turbo
靜態 HTML	非常適合	適合
server dependency	無	幾乎無但設計偏 server
complexity	低	中
learning curve	低	中高

👉 Swup 勝

2. UI/UX 能力

能力	Swup	Turbo
page transition	強（動畫導向）	中
cache/back forward	中	強
head handling	中（需 plugin）	強
state persistence	弱	強

👉 Turbo 勝

3. JS 管理模型

項目	Swup	Turbo
re-init hooks	很直覺	更結構化
DOM lifecycle	container-based	full-page pipeline
predictable behavior	高	高（但複雜）

4. 靜態 blog 實務體驗

Swup：

「輕量 PJAX 增強」
幾乎不改架構
很像 upgrade theme

Turbo：

「把網站升級成 SPA-like MPA」
更完整，但侵入性更高

五、選型結論（核心建議）

如果你的目標是：

A. Hugo / Eleventy + blog + minimal JS

👉 選 Swup.js

理由：

最少架構侵入
最貼近 static HTML mindset
plugin 足夠做 blog transition + preload
init model 清晰

如果你的目標是：

B. 想做「長期演化的 content app」

例如：

blog + dashboard
blog + bookmarks system
blog + reader + state persistence
多 UI region 保留狀態

👉 選 Turbo

理由：

snapshot cache + restore 很強
head 管理更穩
persistent element model 更適合 app 化

六、實務折中方案（最常見）

很多 production blog 最終會是：

Swup + 少量自寫 cache

或

Turbo Drive + 不用 Frames

原因：

Frames 在 static site 幾乎浪費
Drive 已足夠改善 UX

七、簡化決策樹

你是否需要 app-like state persistence？
        │
   yes ──┴──→ Turbo
   no
        │
是否只想要 smooth page transition + minimal setup？
        │
   yes ──→ Swup
   no（更複雜）→ Turbo

八、總結

Swup：偏「前端動畫與輕量 PJAX」，最適合純靜態 blog 增強
Turbo：偏「完整 navigation protocol」，適合逐步 app 化的內容系統
靜態部落格的最佳匹配通常是 Swup，但 Turbo 在長期擴展性更強

如果需要，可以進一步拆：

Hugo + Swup 正確初始化方式（避免 TOC / highlight 重複初始化問題）
或 Turbo 在 static site 的最佳 minimal config（避開 Frames，只用 Drive）