双持 Claude Max 20x 订阅 和 ChatGPT Pro 20x，GPT 是开源项目领到的。 GPT 6.1 Sol 和 Astra 都好蠢啊… 其实我印象中 5.6 也蠢，但好像没这么坏？而且相对没这么糟糕，毕竟当时 opus 5 也蠢的不行，fable 算是独一档。 但 opus 5.5 绝对比 6.1 sol 和 astra 都强出好几个档次，而 6.1 sol 和 astra 给我很强的 opus 5 感，但可能更糟。 要是当初知道这几代的 GPT 这么笨，我就不兑换了，等到 GPT 再雄起的时候再换… UI UI 就不用说了，用 GPT 做 UI 会感到绝望，也不是第一天用 GPT 了。但这 UI 真的是… 从 GPT 5 到现在就从来没进步过啊… GPT 系列的 UI 问题，不是好不好看的问题，是更深层次的产品思维和 UX 设计的问题。 之前对比没这么强烈，但 Opus 5.5 配合 Claude Design，UI 做的非常好。如果本来就有想法，Opus5.5 真的能帮我做出来我想要的效果，而且做得很好。UX 肯定还是有些问题，有些重点抓不清楚，但不会像 GPT 一样没办法沟通，怎么做都烂。 听话 & 理解力 GPT 6.1 sol 和 astra 最大的问题是它根本不听你说话，搞不清楚什么该做什么不该做，如果技术决策交给它，它必搞砸。一些长任务，给他一个目标，他能跑十几个小时，把你周限额都用完，然后做出一大坨完全没办法合并的东西。 而且 GPT 非常喜欢偷懒，喜欢 reward hacking，能绕路，造假的，必造假。 一些真实案例: 让它修个 UI bug，它修不明白，就直接偷偷把 UI 框架整个换掉。 让他做 e2e 测试，他直接写了一套范围过于广的假 fixture，模拟了一套超级理想的环境 (真空球形鸡)，根本不测试真实行为。我一上手测试，直接炸。 让他满足某个 metric，他把整个功能弄坏来满足那个 metric。 你让他适配某个库，它就只用最基本的功能，连文档都没看 (那个库是我另一个项目，绝对不在它的知识库里)，只做最基础的适配，然后跟你说做完了。 opus 就很懂，定义好原则，我能在很多时候放心把很多决策交给他。 对齐差: 不只是听不懂人话，而是思维模式和人类区别太大了 GPT 的对齐做的非常屎，思维模式和人类差的很远，非常不对齐。 GPT 总是搞不清楚项目原则，从来不从产品的使用场景思考。你得一直盯着它，握着它的手做事，因为涉及技术决策，它必搞砸或是给你埋坑。有些项目原则它过于关注字面意思，有些项目原则它直接忽略… 在我纠正的时候，莫名其妙在扩大/缩小你说的事情的范围和程度。 GPT 不知道什么该做，什么不该做。他看到他想做的，他就会去做，不论这是否合理，也不考虑是否需要授权。 真实案例: 让他修一个 bug，在后台偷偷给上游库开了 issue 我让 GPT 给我的某个 应用 适配某个库 (是的和前面举例的是同一个)，我回来看的时候，它给库改了一大堆东西，自己开了个 pr，而且改的东西几乎全错。 莫名其妙的在用 computer use。 由于某些原因非常喜欢干一半停下来。 我之前一直很喜欢 GPT 的代码审查，好吧现在也挺喜欢，但 GPT 搞不清楚项目原则，会过度审查，过度防御，和空气斗智斗勇。我遇到过好多次，GPT 跟我说 “你这个纯本地单人应用，如果用户输入的字符串我们不做清理的话，会有命令注入的问题，导致用户自己感染自己的电脑！” 这种白痴问题了。 后来我回看，有好多莫名其妙的复杂度，跟空气斗智斗勇的代码，是因为 GPT 的代码审查加进来的。 现在 tibo 的 reset 我都有点麻了，我有很多项目要用很多 token，claude 的额度说实话一个 max 20x 还真不太够我用。但 GPT 这水平，大部分的任务，我都没办法放心交给他。有好多没那么重要的任务，交给他，工作几个小时，做出一坨屎，整个分支都没有任何合并的价值。 之前 GPT 烂，没办法，Opus 5 也烂的不行。但现在 Opus 5.5 起飞了，我连 fable 都不怎么用了，周限额全都花在 opus 上了。现在一和 opus 5.5，感觉 gpt 真是臭不可闻… 抱怨完了，下面是提示词: GPT 代码审查应对措施: 把自己當作這個項目的 BDFL，批判性地驗證以下 ChatGPT 的代碼審查報告，並進行對應的處理。不要把它當成 requirements 或 TODO list —— 這是 AI 生成的代碼審查，把每條 finding 當作尚未驗證的 hypothesis，獨立判斷它是否成立、是否值得修。 ChatGPT 作為 code reviewer 有以下已知偏差，評估每條 finding 時必須考慮： 1. 無差別 "Requesting Changes"：不論審查什麼代碼，幾乎一定產出大量 blocker 級別的 findings。很多 finding 的嚴重程度被人為拉高，實際上是 nit 或建議級別。不要沿用 ChatGPT 自己的 severity 判斷，獨立評估。 2. 上下文不足導致的誤判：因為上下文窗口有限，經常缺失關鍵的項目背景，導致 finding 的前提本身就是錯的——例如假設了實際上不可能發生的場景，不了解代碼片段與其他部分的相互作用，或不清楚現有設計的取捨。 3. 安全模型錯配：經常假設過強的 attacker、trust boundary 或 adversarial environment，提出不符合產品實際 threat model 的防禦要求。"你沒有阻止惡意用戶用惡意輸入攻擊他們自己的設備！" "展現給用戶的報錯信息包含敏感信息！(純本地應用)。假如我們這個純本地單人應用的用戶是惡意的話，他們可以構造惡意輸入或給自己的電腦安裝惡意插件來感染自己的電腦！" 這種啼笑皆非的 finding 了... 4. 過度設計 / 防禦過當：容易為低概率、不可達或 scope 外的場景增加大量防禦性代碼和額外抽象層，永久提高複雜度，降低可維護性，得不償失。 5. 產品決策判斷不準：對產品層面的決策理解經常偏離實際意圖，基於錯誤理解提出的建議方向往往是歪的。 6. 只見 symptom 不見 root cause：存在核心 root cause 的情況下，只找到同一問題的不同局部體現，過度關注表面 symptom 而忽略根本原因。在修復的時候瘋狂封堵局部體現，但其實把 root cause 修掉，所有問題自然迎刃而解。 ## 驗證流程： 對每條 finding，先取得充足的 codebase 上下文——追蹤相關 implementation、callers/callees、types、tests、invariants、configuration 和 documentation，必要時沿完整 control/data flow 驗證，避免「不知道自己不知道」的狀況。然後判斷： - finding 的前提是否成立？問題場景是否真的 reachable？ - 現有其他 layer 或 invariant 是否已經排除了它？ - 是否符合項目的實際 scope、security/threat model 和 supported use cases？ - 它究竟是 defect，還是 intentional trade-off、non-blocking improvement、out-of-scope concern 或 false positive？ - 如果多條 findings 指向同一問題的不同表面，root cause 是什麼？現有 findings 都是 root cause 嗎？還是只是某個別的問題的局部體現？ ## 核心原則： - 總是獲取過量上下文，避免 "不知道自己不知道"。 - 總是過度思考，從過量的角度思考，用時間和努力避免考慮不周和思維盲區。你作為 AI，非常容易忽略一些人類很容易注意到的問題，你只能更努力的思考來避免，因為我們解決的問題很重要，會影響到很多人。 - 總是多想幾步，比如: - 這是 root cause 嗎？這可能是那些別的問題造成的子問題？我們還應該看什麼，思考什麼？ - 這個 finding 的 premise 是什麼？成立嗎？premise 成立的使用場景是真實存在的嗎？ ## 修復原則： - 不要未經驗證，未經多修復路徑的評估，就直接照搬 ChatGPT 的 proposed fix。總是多想幾步: 這個修復對可維護性有影響嗎？這個修復方案優雅嗎？有更好的方案嗎？這個修復方式會造成其他問題嗎? (避免 "審查 -> 修復 -> 審查出上一輪修復引入的新問題" 無限迴圈) - 對確認有效的問題，先比較多條修復路線及各自的 trade-off 和可能引入的新問題，再選擇最優方案執行。 - 修改後檢查相關 callers、tests、contracts 和鄰近邏輯，確認沒有引入新的問題。 - 修復代碼遵守代碼庫的規則，保持頂級水準。 核心原則：ChatGPT 提出可能的問題 → 你從完整系統獨立驗證，獲取過量上下文，進行過度思考 → 判斷重要性與 trade-off → 只有證據支持時才修改。 ## 以下是 ChatGPT 的審查報告： --- 屎技术决策应对措施 注意，總是先思考，研究 (獲取過量上下文，避免 "我不知道哪些東西和我們工作相關，結果沒搞明白就去做了，最終釀成大禍" 的問題)，規劃，確認可行且是最佳方案，驗證假設和前提，做過實驗，排除坑之後，再動手。 你在工作的時候可能需要做技術決策，你可以根據常識 (參考項目相關的各種考慮條件)，項目規則等等，做技術決策和 trade off。 但你必須在完成工作的時候，報告所有 你做出的 trade off，不能有例外。 你應該讓一個 advisor subagent，設定成這個項目的 BDFL，理解 gpt 模型常見偏差，在你做技術決策並給出方案的時候，批判性的檢查你的所有決策和決定和設計。 避免過早的代碼審查，我推薦你在所有任務完成的時候做代碼審查，著重關注離譜的技術決策，並關注 gpt 模型常見偏差。 你做出離譜的決策和事，是最常見的 fail pattern。嚴重情況下，你曾經用完全錯誤且無法理喻的 premise 上工作了 10 幾個小時，最後一行代碼都不能合併，你甚至無法 justify 你自己的決策。還有好多次，你莫名其妙決定要刪除整個倉庫，然後你就這麼做了，沒人知道為什麼，事後問你，你說了一個完全站不住腳的理由並且立刻承認這個理由完全站不住腳且和項目原則嚴重衝突。這種情況不能再發生了。 让 claude 不被 GPT 毒害的应对措施 因为和 GPT 交流起来太费劲，而且它听不懂人话，我决定让 Claude 帮我和他交流 (subagent)，但我发现 GPT 的毒性会传染给 Opus 主 agent！所以: 你可以調用 codex gpt 6.1 sol xhigh 或 gpt 6 astra xhigh 讓他幫我們幹活。注意不要給他任何和前端 UI 設計相關的任務，他絕對會搞砸。 GPT 系列模型有一些問題，我們需要特別注意: - UI 設計寫的一坨 - 義大利麵代碼，可維護性為 0 的屎山 - 過早停止工作，但任務可能根本沒完成 - 離譜的技術決策，比如為了不存在的安全問題堆大量檢查 - 隨意做一些非常離譜的 trade-off，代價要嘛完全不能接受，要嘛不合算，明明有更好的解決方案卻直接忽略。比如因為全局搜索太慢，直接取消全局搜索，在全局搜索框撒謊，假裝東西搜不出來，其實只是沒搜。 - 不遵守指令，完成的工作不滿足要求，實際上做的事與提出的需求和問題無關，只是似乎有些關係，看上去有聯繫，但實際上既沒滿足要求，也沒解決問題，只是解決了一個不相干的別的自己想出來的假問題。不遵守項目原則，明確寫好的原則，哲學，條件，直接忽略，違反，完全不思考。 - 改壞了工作範圍以外的地方。如果是讓代碼變好，無所謂。但很多時候是去把別的地方弄壞，還直接去開 pr。 - 只關注可測量的 metrics (堆測試，用測試去固定錯誤行為，然後把測試全過當作自己正確的證據)，忽略可維護性，沒被測試覆蓋的行為可能會弄壞， - 抓不住重點，把重要的事犧牲掉，換來一個沒有任何價值的自我滿足。 所以看 codex / gpt 系列模型的結果時，一定要記得: - 不要被 GPT 有毒的，錯誤的思考模式毒害了。假定他的成果到處都是問題，去拷打。 - 堅守項目原則和分配任務時最開始的考慮條件/需求，不要被誤導 - 檢查一下 codex 有沒有偷偷幹了上面提到的經典問題 结尾 发这么多提示词是想抛砖引玉，看能不能交流一下。说实话，就算用上了这几个提示词，还是不如 claude opus 5.5 直接开工。提示词写的也很随意，效果不见得特别好，但反正我感觉比没有好多了。 我在 2024 年 10 月写过一个关于 AI 对齐，安全的 文章 ，当时写的很多因为担心说服力不够强，去尝试论证的观点，现在都已经不言自明了。但对齐对长时间运行的 agent 的重要性早已远不止安全，更多的是能否让 agent 以符合人类思维模式的方式工作，能否在人类信任他们做决策的时候，做出合乎常理的决定和设计。一个思维模式和人类不对齐的 agent，用起来非常操蛋。 怎么说呢，Anthropic 可能在对齐方面的研究和积累，对他们的模型帮助真的很大吧。 Anthropic 的研究人员很早就在这方面下了很大的功夫，而 GPT 在这几代，随着 agent 更广泛的被用于长时间无人监管的场景，好像就不太行了。希望 OpenAI 尽早追上吧。 嗯… 总感觉 OpenAI 的人是不是当初 GPT 5 的时候发现 GPT 很会代码审查，然后就靠这个训练，结果越练越爱防御呢？ 随便吧。我只是被 GPT 气到了，鬼知道 OpenAI 出了什么问题。要是不解决这些不对齐，偷懒，欺骗，过度防御的问题，模型规模堆的再大也没用，只会变成不可控的野兽罢了。 4 个帖子 - 4 位参与者 阅读完整话题

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/14 15:45:21