20250625 多用 AI 遲早腦中風

多用 AI 遲早腦中風,我只是想知道 commit amend 時是否可以不要更新 committer date,就像 rebase 的參數 committer-date-is-author-date 一樣,然後拿這段話問 AI:

git commit amend如何不更新committer date?

他就會跟你介紹什麼是 committer date,多種不同方式,注意事項...哪來這麼多廢話。當然這在一般交流有 context 是正常的,但顯然他分不出來指令需求和聊天需求,同樣問題丟給 Claude, Gemini, ChatGPT, Grok 全都一樣廢話一堆。

那麼不考慮這種工程師需求呢?因為我蠻不會寫那種超有禮貌的 issue,所以請他潤飾文章,你以為 AI 語言能力很強各種答題都可以超越人類水準沒錯吧?大錯特錯,潤飾變成意思亂改,prompt 要求改稍微客氣一點就變成奴隸對主人講話,要求改不要這麼誇張的用語就直接把幾乎所有潤飾全部給刪了,這 AI 再多用下去我還不先腦中風。

尤其是 ChatGPT,經過兩年 AI 大戰後,上述的 Claude, Gemini, ChatGPT, Grok 四個裡面用的最不爽的就是 ChatGPT,回答最爛,限制最多,問 A 答 B,現在 ChatGPT 贏過別人的只有前端設計,這算哪門子 AI 公司。

再不然我們下一個超強的 prompt,就像是這篇文章中每次都要這麼長的 prompt 會不會更好?除了內文說到很多模型根本處理不了這麼長的上下文以外,更重要的問題是我們不會一天只處理一個問題讓你在那邊慢慢打 prompt,就算長 prompt 真的能有效解決問題,但真正的問題是在 copy-paste 的過程人類不會成長,下次遇到同樣的問題我們還是一樣需要 30 分鐘寫 prompt。

好吧,那不要要求實際問題,來聊天好了,那恭喜喜提前後文長度限制 + lost in the middle 問題。

LLM 只要還是 transformer 就不要妄想解決這些問題,沒可能解決,說真的我覺得 AI 最有用的就是小範圍問題,一兩百行程式碼之內就能解決的問題他能快速精確的解決,再來就是 code review,生一些本來就沒人會認真看的文案,最後就是生色圖,現在很多色圖已經沒有以前那種噁心感了。

載入評論