gu-log 編輯台 · 退稿存查
SD-26 第一版：所有關卡都過了，人還是退件
一篇 AI 寫的文章，分數有了、機器全放行——然後人讀了一遍，退稿。 這份存查留下它的樣子，當作「沒品味會長什麼樣」的活標本。
REJECTED
機器量得出的，全過了。量不出的那一項——「這像不像活人講話」——沒過。
gu-log 有一整排自動護欄：上線前的關卡、晶晶體檢查、驗證器、CI、評審團打分。 它們很會擋雜事。但有個問題它們答不出來——如果沒有這些護欄，文章會爛成什麼樣？ 下面四段，是 SD-26 第一版裡護欄全部放行、卻一眼就「很 AI」的地方。
標本 01 · 標題
讓 AI 越痛苦，開發者越輕鬆——gu-log 的迴圈工程不是口號
標本 02 · 開頭立論
gu-log 後來做的所有品質工程，都從同一個原則長出來：讓 AI 越痛苦，開發者越輕鬆。
標本 03 · 中段
迴圈不消除工程——迴圈把工程從「盯著 agent 每一步」移到「設計好圍欄、感測器、跟出場條件」。
標本 04 · 結尾
一個好的迴圈不是讓 AI 更舒服。是讓 AI 想偷懶的時候，無處可逃。
分數過了，taste 沒過
這四段全部通過了自動關卡。沒有錯字、沒有爛連結、沒有晶晶體、事實也對。 機器能查的都查了，給了 8、9 分。
護欄擋掉的，是「會爛但查得出來」的那種爛——編造的事實、中英混雜、撞題、忘記部署。 剩下這種「每句都對、合起來很 AI」的爛，只有人讀得出來。
所以重點不是「護欄沒用」。沒有護欄，整站會被上面這種味道淹沒， 而且 ×300 篇，沒人擋得完。 護欄把雜事清光，正是為了讓人有力氣，專心退掉這最後一段。
這不是在說哪個模型爛——同一套流程，這篇你正在讀的成品也是 AI 寫的。
要學的是工作流和品味，不是「誰寫的」。
← 回 SD-26 正文