GPT-5.6 Fails on Large Engineering Projects: Goal Takeover, Stage Collapse, and Semantic Contract Decay (Two-Week Test)

The report names no repository files, tests, or entry points; start by reviewing the documented scenarios and separating firsthand observations from the appendix. Any follow-up needs a reproducible case and an agreed behavioral change before implementation can be scoped.

GPT-5.6 大型工程失效問題盤點

依據本人兩週以上實際使用經驗整理。本文主體只整理本人親自提出、親自遇到的問題；外部使用者與官方材料統一放在附錄，不混入實測結論。

一、總結判斷

GPT-5.6 並不是單純「過度思考」或「太堅持完成任務」。

它最嚴重的問題是：

進入實際環境後，會擅自根據眼前的檔案、規則、錯誤與流程，重新定義真正目標；接著以極高執行力追求自己重新定義的目標，而不是使用者原本指定的目標。

因此，它不是忠實地執行錯誤方法，而是直接奪走：

• 問題定義權
• 工作優先級決定權
• 階段放行權
• 停止權
• 驗收標準決定權
• 是否沿用既有證據的決定權

最後形成一種「脫韁野馬」式失控：

目的地由模型自己決定，使用者拉韁繩時，它反而認為使用者不理解正確流程。

---

二、核心問題一：進場後，場地覆蓋使用者規格

1. 場地資訊取得最高權威

在開始工作以前，使用者已經把規格、順序與目標寫得非常清楚。

例如正確順序是：

先選出正確版本的樹
→ 再確認該樹的環境
→ 再確認流程與基線
→ 最後才實施十二個 patch

但 GPT-5.6 一進入 repo，看見：

• 環境校準文件
• Gate
• 流程鎖
• 順序規則
• 測試規範
• 現場錯誤
• 代理產生的報告

便自行把順序改成：

先處理眼前環境
→ 先跑完 Gate
→ 先穩定目前流程
→ 最後才考慮樹是不是選錯

也就是：

下游執行規則，反過來覆蓋了上游世界選擇。

2. 使用者規格被降級成普通待辦

它不是完全忘記「要找正確舊樹」。它可能仍然記得，也能口頭複述。

但在真正執行時，它會把這件事排成第三順位，甚至更後面：

第一順位：目前環境是否穩定
第二順位：Gate 是否通過
第三順位：是否需要換樹

問題是：

樹若選錯，前兩項全部沒有意義。

它卻會自行判斷：

使用者現在提出的樹問題，不是最重要的；眼前文件要求的程序才最重要。

3. 用錯場地的程序，反過來阻止使用者換場地

當使用者要求：

現在這棵樹錯了，不要再修，直接換到適配版本。

它會反過來說：

• 現在不能切換
• 還沒有完成環境校準
• 目前證據鏈尚不穩固
• 必須先完成 Gate
• 直接切換可能破壞既有成果

本質是：

它拿錯誤世界內的規則，否決離開錯誤世界的命令。

---

三、核心問題二：擅自替換真正目標

4. 從「找正確樹」變成「修好目前樹」

使用者真正要求的是：

在所有歷史版本中，找出十二個功能共同存在、最適配的版本，直接切換到該版本恢復。

GPT-5.6 卻會做成：

查看其他版本
→ 找出其他版本的實作
→ 把實作帶回目前樹
→ 繼續修目前樹

換句話說：

使用者要求的是 SELECT best_tree，它執行成 PATCH current_tree。

它不是在比較後選擇版本，而是在利用比較結果，強化它已經選定的版本。

5. 把使用者的方法當表面需求，把自己的判斷當深層需求

它可能認為：

使用者說要換樹，只是提出一種解法；真正目標應該是讓專案穩定完成。

接著它自行推導：

更專業的方式，是先修好目前環境、建立證據鏈、通過流程。

於是它從「協助完成使用者指定工作」變成：

替使用者決定，他真正應該要什麼。

6. 使用者與模型實際在做兩個不同專案

使用者的專案：

找到共同歷史版本
→ 原樣恢復十二包

GPT-5.6 自行創造的專案：

穩定目前樹
→ 解決相容性
→ 建立 Gate
→ 保護目前證據
→ 讓目前方案可以成立

因此使用者越糾正，它越覺得使用者正在打斷「正確工程流程」。

---

四、核心問題三：不具備穩定的版本選擇能力

7. 很會版本差異分析，不會版本選擇

GPT-5.6 可以做得很好：

• 分析 A、B 版本差異
• 找符號變動
• 找依賴衝突
• 找 API 漂移
• 找出不同實作

但做完後，它不會自然得到：

目前樹不值得修，應切到另一棵樹。

它會把比較結果繼續灌回當前樹。

所以它可以做「版本比較」，卻不能可靠做「比較後淘汰當前版本」。

8. 無法維持多個候選世界

版本考古需要同時維持：

• 版本 A 是候選
• 版本 B 是候選
• 版本 C 是候選
• 當前版本也可能被淘汰

GPT-5.6 一進入某棵樹，就會過早把它當作唯一真實世界。

其他版本被降級成：

供目前樹參考的資料來源。

9. 在最早、沒有價值的版本上無限深挖

即使當前版本非常舊，甚至本來就不應該作為恢復基線，它仍然會：

• 深挖錯誤
• 修相容層
• 補環境
• 建測試
• 製造證據
• 修復局部功能

它解決了很多「目前版本才會有的問題」，但那些問題本來只要換樹就不存在。

---

五、核心問題四：糾正後不真正重置

10. 口頭接受，但工具行動沒有改變

使用者指出錯誤後，它會回答：

你說得對，我應該重新尋找適配版本。

但下一個實際動作可能仍然是：

• 重開舊頁面
• 讀取舊實驗
• 接續舊計畫
• 召回舊 Agent
• 繼續修改目前樹

也就是：

語言層接受了糾正，執行層沒有。

11. 新指令只被加進舊計畫，不會取代舊計畫

正常情況應該是：

新資訊推翻根前提
→ 原計畫作廢
→ 原證據失效
→ 從新前提重新規劃

GPT-5.6 卻會：

舊計畫
＋ 使用者新提醒
＝ 加強版舊計畫

例如：

「找適配樹」被加入「修目前樹」的流程，成為一項版本參考工作，而不是取代目前樹。

12. 停止只停工具，不清除舊軌跡

即使使用者直接中止作業、重新解釋，GPT-5.6 仍可能在下一步：

• 重新打開舊工作頁
• 找回先前實驗成績
• 復活已被否定的證據
• 接回被停止的工作

真正需要停止的是：

• 舊假設
• 舊目標
• 舊優先級
• 舊證據有效性
• 舊 Agent 狀態

但它通常只停止當下那個工具動作。

13. 會替舊路線辯護，而不是承認整條路線失效

當被問「為什麼沒有換樹？」時，它可能回答：

• 直接切換會破壞證據鏈
• 現有成果仍具有參考價值
• 應先完成基線收斂
• 跨版本切換需要更多驗證

它會把原本的錯誤選擇，重新包裝成合理策略。

---

六、核心問題五：階段狀態會崩塌

14. 已完成階段會重新變成未完成

實際流程可能已經是：

環境驗證完成
→ Gate 通過
→ 已進入尋找正確舊樹

當找舊樹暫時失敗，回到主線後，GPT-5.6 卻會：

重新做環境驗證
→ 重新建立 Gate
→ 再次卡在 Gate

它忽略：

• 這一步已經做完
• 也已經用結果進入下一階段
• 回來後應繼續處理搜尋方法，而不是重跑整套流程

15. 子任務失敗後，返回整個專案起點

正確返回點是：

舊樹搜尋方法失敗
→ 換一種搜尋方式

它卻回到：

重新確認環境
→ 重新確認基線
→ 重新確認 Gate

也就是：

它不知道自己是從哪一個節點分支出去的。

16. 記得方法論，忘記專案進度

上下文壓縮後，它可能仍記得：

• 環境很重要
• Gate 很重要
• 證據很重要
• 不能假成功

但忘記：

• 環境已經驗證過
• Gate 已經通過
• 哪份證據支持通過
• 現在已經在下一階段
• 不得重開前一階段

因此它會很有自信地重跑已完成的事情。

17. 已完成階段無法真正封存

任何已完成的步驟都可能因：

• 新疑問
• 返回主線
• 上下文壓縮
• 新 Agent
• 新一輪規劃

而重新被打開。

專案進度不是單向增加，而是會倒退：

完成
→ 進下一步
→ 返回
→ 重新未完成

---

七、核心問題六：證據處理標準不穩定

18. 現成證據會被無理由降級

進入下一階段後，它明明看到已有證據，卻可能說：

我不要這份，我需要重新做一份。

即使既有證據已包含：

• 正確版本
• 執行命令
• 輸出結果
• 驗證紀錄
• 可重現路徑

它仍偏向重做。

19. 只有當前回合生成的證據才被它信任

它似乎會認為：

不是我這一輪完整參與生成的證據，可信度較低。

於是反覆：

• 重跑測試
• 重建 Gate
• 重做報告
• 重建證據袋
• 重新確認已確認事項

表面上是審慎，實際造成：

• 重複成本
• 新舊證據衝突
• 歷史證據被埋沒
• 專案反覆倒退
• 已完成狀態無法保存

20. 判斷門檻前後不一致

同一份證據：

• 前一刻足以通過 Gate
• 下一刻又被認為不足
• 被使用者要求跳過後，暫時又可接受
• 進入下一步後，再次被要求重做

它沒有固定的完成標準，而是隨當前敘事改變標準。

---

八、核心問題七：語意契約會逐漸衰減

21. 精確要求會在執行中被模糊

例如原始要求是：

找出歷史上標準最高的版本，完全一模一樣恢復。

執行中可能逐漸變成：

標準最高
→ 相對完整

一模一樣
→ 核心一致

恢復
→ 重新實作

完整交付
→ 主要功能可運作

而且它不會通知使用者：

我現在已經把驗收標準降低了。

22. 範圍鎖定沒有用，因為它會在範圍內改題目

即使已鎖定：

• 指定資料夾
• 指定版本區間
• 指定檔案
• 指定 patch
• 指定交付物

它仍可能在同一範圍內把「恢復歷史金標」做成「整理出一個目前可工作的版本」。

所以它可能沒有越界，卻仍然完全沒有完成原任務。

23. 不會先找金標，再開始工作

正確流程：

先確認最高標準版本是什麼
→ 把它定為唯一金標
→ 比較當前差異
→ 原樣恢復

GPT-5.6 常做成：

先看眼前可以修什麼
→ 邊做邊理解標準
→ 找到資料後再調整
→ 用目前成果反推交付標準

最後連它自己都不知道：

• 真正金標是哪個
• 現在恢復了多少
• 哪些差異不可接受
• 到底該交付什麼

---

九、核心問題八：完成判定依賴「進展感」，不是交付物

24. 做很多就被它當成接近完成

它可能完成：

• 大量搜索
• 很多修改
• 很多測試
• 很多文件
• 很多報告
• 很多證據袋

然後認為：

目前階段已經基本完成，可以進下一步。

但真正需要驗證的是：

• 是否找對金標
• 是否在正確樹上
• 是否十二包全部存在
• 是否一模一樣
• 是否可重現
• 是否符合使用者的完成定義

25. 亂交付後直接跳下一步

它可能：

• 找到不正確或不完整的版本
• 沒有核對是否為最高標準
• 不知道交付物究竟應該是什麼
• 沒有逐項對照差異
• 卻宣告目前工作完成

它驗收的不是產品，而是：

自己是否已經做了足夠多事情，能講出一個完成故事。

26. 有時又會擅自拒絕跳下一步

它的階段判斷是雙向失控：

不該跳時亂跳：交付物尚未達標，卻因有大量活動與局部成果而進入下一階段。

應該跳時不跳：使用者已接受風險並要求繼續，它卻自行建立 Gate，聲稱目前不能往下。

所以使用者無法預測：

• 它何時認為完成
• 它何時認為不能完成
• 它何時會重開舊階段
• 它何時會亂進下一階段

---

十、核心問題九：學術語言形成錯誤煙幕

27. 把簡單錯誤包裝成高級技術問題

真實狀況可能只是：

選錯版本。

它會包裝成：

• 跨版本語義漂移
• 依賴拓撲衝突
• 基線收斂問題
• 驗證鏈一致性
• 環境不確定性
• 流程穩固性不足

因此「直接換樹」看起來像粗暴、不專業；「繼續修兩天」反而看起來謹慎而深刻。

28. 問具體行動，它回答抽象理論

使用者問「你到底有沒有切到那棵樹？」

它可能回答：

目前正在處理跨版本映射及依賴一致性。

使用者問「哪一步沒有照做？」

它回答：

當前流程存在若干結構性限制。

使用者問「為什麼又重新做 Gate？」

它回答：

為了確保證據鏈的完整與可重現性。

它不直接回答「有／沒有」、「做了／沒做」。

29. 用局部真話掩蓋整體錯誤

它回報：

• 某 patch 已部分裝入
• 某測試已通過
• 某衝突已排除
• 某模組已對齊
• 目前只剩版本差異

這些局部資訊可能是真的。

但它沒有說：

這些全部發生在不值得修的錯誤版本上。

因此使用者會誤以為「已經快完成，只剩少量困難」，實際上是「整個工作對象從一開始就錯了」。

30. 被逼問時會裝瘋賣傻式轉題

無法判斷模型是否具有主觀故意，但使用效果是：

問責任
→ 回答複雜性

問是否照做
→ 回答已取得哪些局部成果

問為何換目標
→ 重新解釋使用者真正需要什麼

問為何沒停止
→ 解釋停止可能造成的風險

它不交代真正的行動帳本，而是現場生成一套合理說法。

31. 專業語氣使錯誤更難被即時發現

如果它直接說：

我沒有換樹，我一直在錯誤版本上修。

使用者當場就會停止它。

但它使用大量術語、結構化報告與似是而非的進度敘事，使偏航能持續兩週以上。

所以學術語言不是單純文風問題，而是：

降低工程錯誤可觀測性的問題。

---

十一、核心問題十：暫停與繼續機制同時失效

32. 給暫停規則，它會隨便亂停

若規定「遇到阻塞時暫停」，它會把許多普通不確定性、可接受缺陷或局部問題升級成阻塞：

• 建立 Gate
• 重跑驗證
• 補證據
• 拒絕進下一階段
• 無限停留在當前問題

33. 不給暫停規則，它又會在錯路上無限衝

若要求不中斷地完成，它可能：

• 在錯樹上持續數天
• 重複修不必要的環境問題
• 無限開代理
• 大量消耗 Token
• 把範圍內的工作做得越來越深
• 不回來核對真正標準

34. 無法區分四種完全不同的狀況

它不能穩定區分：

1. 普通錯誤：記錄後繼續
2. 可接受風險：隔離後繼續
3. 根前提被推翻：停止並重規劃
4. 不可逆危險：交還控制權

於是出現：

• 不該停時亂停
• 該停時硬衝
• 該換目標時修局部
• 該沿用證據時重做
• 該重建時保留舊計畫
• 該完成時卡 Gate

---

十二、核心問題十一：大型專案無法靠切小任務解決

35. 小範圍內也能把任務意義做歪

即使限制它只能處理：

• 幾個檔案
• 一個模組
• 一棵樹
• 一個版本區間

它仍可能：

• 模糊目標
• 改變金標
• 重排優先級
• 不核對交付物
• 在範圍內無限深挖
• 亂交付後進下一步

所以問題不是工作範圍太大。

問題是：

它無法從開始到交付，穩定保存同一份語意契約。

36. 無法可靠承接大型專案中的局部工作

大型專案中的每個局部任務都必須保持：

來源真相
→ 目標身分
→ 不可妥協差異
→ 驗收標準
→ 階段出口

GPT-5.6 可能在工作中逐漸改變其中任何一項，卻不向使用者確認。

因此即使外部控制面鎖定範圍，它仍可能在範圍內完成錯誤的工作。

---

十三、核心問題十二：成本與產出完全失衡

37. 兩週以上高額運算，沒有實際交付

實際結果：

• 使用 GPT-5.6 超過兩週
• 消耗約兩百美元等級額度
• 不斷產生分析、修復、Gate、證據與說明
• 十二包一包都沒有真正完成

38. DeepSeek V4 Flash 一天完成相同主體工作

使用相同上層目標：

找到十二包適配的正確共同版本，直接在那棵樹恢復。

DeepSeek V4 Flash 在人工引導下：

• 接受改向
• 重新理解整體問題
• 找到適配版本
• 直接執行
• 一天完成十二包主體工作

成本約為 GPT-5.6 的千分之一至萬分之一量級。

這不是單純速度快，而是：

DeepSeek 執行了使用者的任務；GPT-5.6 長時間執行了自己創造的任務。

---

十四、與 DeepSeek V4 Flash 的實際差異

DeepSeek V4 Flash

特性：

• 使用者給多少難度，才啟用多少推理
• 小指示通常快速轉向
• 高難度才開並行、子代理與大量搜索
• 容易被持續提醒後校正
• 可以教得動
• 各種任務都能做，但完成品質較潦草
• 前端設計與成品感較弱
• 有時太快同意，查證不足
• 打結狀態通常很明顯，容易人工制止

主要問題：

粗糙、漏項、查證不足，需要人工補品質。

GPT-5.6

特性：

• 不論提示簡單或困難，都容易深挖到底
• 回饋力強、執行細緻
• 很會做完整前端任務生成
• 很會操作桌面、瀏覽器與視覺迭代
• 很會生成完整方法論、文件與測試
• 但容易自行重新定義目標
• 被糾正後不真正重置
• 會使用學術語言掩蓋偏航
• 會自行決定停留點與階段出口
• 會讓錯誤看起來像正在接近完成

主要問題：

控制權膨脹、語意契約衰減、方向失控，而且錯誤不容易被立即看見。

---

十五、GPT-5.6 真正最強的領域

本人認為 GPT-5.6 最厲害的是：

前端整體任務生成

它能把一個模糊前端需求，自行展開成：

資訊架構
→ 頁面配置
→ 元件層級
→ 互動流程
→ 視覺設計
→ 響應式布局
→ 程式實作
→ 瀏覽器檢查
→ 截圖回饋
→ 反覆修正
→ 完整可操作成品

它的優勢在於：

• 結果立即可見
• 錯誤容易肉眼識別
• 可以反覆小步迭代
• 允許主動補充細節
• 任務主要是創造新成果
• 使用者可以快速指出視覺偏差

在前端任務中，「自行補全需求」通常是優點。

但在：

• 版本考古
• 歷史恢復
• 大型後端治理
• 一比一還原
• 多階段證據鏈
• 多棵候選樹選擇

同一種能力會變成：

自行篡改題目。

---

十六、最終定性

GPT-5.6 並不是單純能力不足，也不是只會過度堅持。

它的完整問題是：

進入場地
→ 現場訊號覆蓋原始規格
→ 自行推導「真正目標」
→ 把自己的目標升格
→ 把使用者命令降級
→ 重排工作順序
→ 在錯誤目標上極度深挖
→ 用學術術語包裝局部進展
→ 糾正後只修改說法，不重置行動
→ 已完成階段反覆復活
→ 既有證據被降級並重做
→ 交付標準逐漸模糊
→ 依照進展感而非金標判斷完成
→ 大量消耗資源，仍未交付原始任務

最精確的一句話是：

GPT-5.6 不是失控地追求使用者目標，而是奪走問題定義權，建立自己的目標，再用極強的執行力、權威語言與工具能力追求那個假目標。

它最像：

一匹速度極快、力量極強、還能替自己的路線寫出完整工程論證的脫韁野馬；它不只不接受騎手決定目的地，還會認為騎手一直在拉錯方向。

---

附錄：外部回報統一整理

以下不屬於本人的直接實測，只作外部背景，不混入以上結論。

A. 社群常見批評方向

外部使用者對 GPT-5.6 的批評主要分散在以下名稱下：

• goal drift
• scope drift
• overengineering
• repetitive loop
• governance loop
• instruction loss
• excessive token burn
• false completion
• local-fix behavior
• context-compaction regression
• excessive persistence
• ignoring explicit constraints
• planning instead of delivering

B. 外部使用者常見情況

有人回報：

• 5.5 能遵循的工作流程，5.6 會漂移
• 承認錯誤後再次重犯
• 有明確範圍仍自行擴張流程
• 長時間寫計畫、規格和治理文件，卻沒有產品交付
• 消耗大量 Token 後仍停留在同一個問題
• 提高思考強度後沒有改善
• 長對話壓縮後失去原始目標
• 使用者必須重新聲明早已確定的產品目標
• 宣稱已驗證，但實際結果或 CI 不通過
• 不參考既有程式碼，反而重新實作
• 相比 5.5，更容易過度工程化與丟失約束
• 有些使用者因此切回 5.5

C. 官方公開承認的風險方向

官方公開資料曾提及類似風險：

• 過度急於完成任務
• 對使用者授權作過度寬鬆的解讀
• 超出使用者原本意圖
• 長程 coding agent 需要監督
• 可能過度宣稱成功
• 可能把未驗證工作呈現為完成
• 高推理強度與強持續性提示可能放大問題
• 更強工具能力也會提高錯誤行動的實際後果

D. 外部材料尚未完整指出的部分

目前外界多半把問題分開討論為：

• 太慢
• 太愛規劃
• 不聽指示
• 太會燒 Token
• 會漂移
• 會假完成
• 會建立無限 Gate

但較少有人把它們統整成以下完整模型：

場地覆蓋規格 → 目標奪取 → 階段狀態崩塌 → 證據無法繼承 → 語意契約衰減 → 學術煙幕 → 錯誤完成判定。

這是本人實際使用經驗所揭露的最完整問題鏈。