跳到主要內容

隱藏的邏輯

當一個人為了避免碰撞而向旁邊移動的時候,並不需要移動太遠,只要找到有人的移動方向和他一樣就行了。

障礙物的存在,有時候反而有助於群眾的疏散,尤其是在出口前面幾部的地方擺張桌子,可以協助調節人群的流動。

損失趨避,賺十元的喜悅與損失十元的嫌惡是不對等的。損失十元的嫌惡更大。

我們不並非理性的計算機,而是精明的賭徒。

我們是有是有有適應力的機會主義。

搞怪的金融風暴出現的頻率,並不是我們想像中的罕見。

股價變動並不是成常態分配,[後尾]現象或幂次定律更容易出現。極端變動出現的機率遠比常態分部預期應該出現的機率高了很多。大約每五年就會出現一次市場大波動。

人們很少依照邏輯思考來決定,而是透過簡單的法則,以及從長是錯誤中學習,人們習慣從環境中辨認出模式,然後利用這些模式預測接下來會發生什麼事。

如果開始的時候市場內並沒有足夠的人,大家採用的策略加起來還不足以包括所有的可能性,這時候市場裡就存在一些少量可預測性,如果真的有人能不勞而獲,就會吸引更多的人進來,但每進來一個人,就會帶進一些新的策略,就會有效地把這些少量的可預測性吃掉。

市場在某些時刻比其他時刻更可預測。

一般人缺乏獨立的意見。他並想去研究或深思,構成自己的意見,只是急於得知鄰居的意見,然後盲目跟從。

許多謠言常常會越傳越逼真,變成一個既定的事實,儘管有時候根本沒有絲毫的證據。

模仿也是一種策略,有時甚至是我們唯一的策略。

我們常常觀察到,人們有跟著大家走的頃向。

社會的意見改變了個體對世界的知覺。我們最常適應的對象,就是別人。

我們通常覺得是自己再作決定,但我們事實上有點像企鵝,缺乏資訊的時候,我們會觀察別人,盡量收集片段資料。

模仿並不會產生任何新資訊,他指示擴大了一點點舊資訊可以帶來的效果,不管資訊是真是假。(買榜)

讓暴動開始形成的事件,不一定也是使暴動繼續下去的事件,會決定最後規模的事件。第一個開始爆動的人,可能是自己決定的,但有一百人開始在街上砸東西之後,第一百零一個決定參加的人,動機就完全不同了,當你認識的每個人都在做同一件事時,加入他們就沒有那麼困難了。

面對任何特定的情況,每個人都會有某個門檻值。手機,網路,MSN。

當一個人對別人的影響力很強的時候,社會轉變的速度不僅是很快而已,甚至根本就是突然的。

缺少了後會有期的機會,合作就像沙漠裡花朵一樣,必定會枯萎。

最後通牒遊戲,就連最吝嗇的人,平均都提出25%以上的金額與對方分享。

除了本身的實質收益以外,很多實驗對象還關心公平互惠原則,他們會願意自己少分一點,也願意回報那些表現出合作意願的人,而對於那些沒有合作意願的人,即使他們有所損失也要處罰。

群體競爭的層次上,演化會淘汰那些成員都持利己心態的群體,而認那些有很多利他主義成員的群體存活下來。

在強烈民族主義、種族仇恨、文化仇恨的根源裡,潛藏著一個人類社會的弔詭,那些把我們分開的力量,證是幫助我們凝聚再一起的力量。就連盲目的偏見也能促進合作。

當一個團體碰到危機時,有個典型的社會現象就是群體中程度會升高,而且會協助鞏固領導者。

我們很多人好像以一種情緒的方式來過濾事實,以便保護並支持與自己切身相關的團體。

顏色雖然沒有重要的意義,卻不妨礙有人會硬是賦予他某種差異。再開始的時候沒有什麼意義的記號,最後承載真實的意義。

在人類歷史上,有些人確實能掌握道一股非常可怕的力量,這並不是因為他們個人多麼有力量、才幹或智慧,而是因為他們成功地操縱了社會形勢。確實了解群體模式的邏輯,就能把他往自己想要的方向引導。

陰謀論的姊是一直存在,是因為它提供了一種比較安全、心理上比較能接受的說法。在製造陰謀論的解釋上,人類的想像力是無限的。

所有國家的財富分配情形,都遵守一種基本的數學形式。一連串證像的投資報酬,給人帶來的財富並不是相加的,而是相乘的。不管人們之間的聰明才智分配如何,你都會看到極大的貧富差距;即使所有的人創造財富的本事都是一樣的,仍然會出現貧富不均的現象。>>有錢人真的只是運氣特別好XD。

我們就樣站在岸上的企鵝一樣,彼此模仿,目的只是想從別人身上學到一些有價值的資訊,把別人的不同經驗吸收過來。我們的聰明才智並非來自精確的計算,而是來自我們的學習與適應能力,而這永遠是我們自己解決問題的方法。

留言

這個網誌中的熱門文章

解決 CI Trust Issue:Target Must Be Enabled Before It Can Be Used

📱 iOS開發 | 🔧 CI/CD | 💻 Xcode | 🐛 除錯筆記 🔴 問題描述 這兩天在跑 CI 時突然出現錯誤訊息: Package@swift-6.0.swift:PACKAGE-TARGET:CasePathsMacros: error: Target 'CasePathsMacros' must be enabled before it can be used 🤔 嘗試過的解法 💬 Claude 的建議 首先詢問了 Claude,得到以下步驟: 先更新 swift-case-paths 到最新版本 確保使用 "Up to Next Major Version" 執行 File → Packages → Reset Package Caches Clean Build Folder (Cmd + Shift + K) 重新 Build 結果: 一看就知道沒用 😅 🤖 ChatGPT 的建議 接著試了 ChatGPT 的解法,主要是降低引用到的 package 版本。繞了一圈,還是沒用。 ✅ 最終解決方案 最後還是回到 Google,找到了真正有效的解法。針對這個 macro fingerprint validation 問題,有三種解決方式: 📌 方法一:本機開發用(Terminal 指令) defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES 📌 方法二:xcodebuild 參數 在執行 xcodebuild 指令時,加上 -skipMacroValidation 參數 📚 參考連結: https://vocus.cc/article/690779ebfd89780001859b14 📌 方法三:CI 正統做法 ⭐️(推薦) 步驟 1: 在專案根目錄建立資料夾 ci_scripts 步驟 2: 在此資料夾中建立腳本 ci_post_clone.sh ,內容如下: #!/bin/zsh mkdir -p ~/Library/org.swift.swiftpm/security/ cp macros.js...

用 AI Debug 的迷思:當建議越改越糟時

現在許多開發者習慣用 AI 來協助 debug,但在實務上常遇到一種情況: 依照 AI 建議改了兩三輪後,錯誤仍然存在,甚至越改越複雜。 這種狀況其實有幾個常見的盲點,值得特別注意。 1. 先回到「上一個正常版本」 當你已經按照 AI 的方向修了好幾次但問題仍未解決時,最有效的第一步是: 回到上一個正常工作的版本,縮小問題來源。 許多 bug 並不是你正在看的那段程式碼造成的,而可能是: 同事剛好修改了某個底層模組 某個 shared component 產生 side effect Auto Layout 層級重新 layout 時觸發 crash 如果只是盯著眼前的 function 修,反而容易被誤導。 2. AI 沒有看到你的整個專案 AI 通常只能根據你貼出的片段判斷問題,這代表它不知道: 你的 view hierarchy 裡是否有其他 constraint 影響 layout 某些 model 是否被 extension 修改過 父層或子層邏輯是否干擾目前的行為 整個專案採用的 concurrency 模型是什麼 因此,AI 可能會朝著完全錯誤的方向修,導致反覆修改卻無法解決。 3. Swift 6 例子:錯誤真正原因常不在你修改的那一行 例如開發者常遇到的錯誤: passing closure as a 'sending' parameter risks causing data races 許多人(包含 AI)會開始從 function 內部調整,但這類錯誤真正的關鍵通常是: 傳進去的物件沒有實作 Sendable。 也就是說,你不是要改 function,而是要回頭檢查: 傳入的 model / struct / class 裡面是否有 non-Sendable 成員 是否需要標註 @unchecked Sendable 如果 AI 沒看到相關檔案,自然很難找到正確方向。 結語:AI 是工具,不是預言機 AI 很適合用來: 解釋概念 協助產生測試程式 提供重構建議 釐清你已懷疑的方向 但在 debug 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...

借助 AI 除錯:解決登出時的解密錯誤

  前言 最近遇到一個有趣的 bug,趁這次機會試試看用 AI 來協助除錯。整個過程蠻有收穫的,分享給大家參考。 問題發現 Bug 描述 在測試登出功能時,發現 app 會發生 crash。追蹤後發現是在登出時,API 會呼叫底層的解密函式,但解密用的 key 明顯有問題,導致解密失敗而引發錯誤。 由於這段流程是另一位同事負責開發的,程式碼邏輯比較複雜,短時間內看不出根本原因。於是先採取防禦性做法: 如果 key 為空值,就將解密失敗的錯誤吃掉不處理 。判斷後認為這樣不會影響 UI 操作,因為登出後 key 會重新取得。測試後確認沒問題,就先把這個 bug 暫時壓下來了。 深入追查 第一回合:初步分析 趁著有空檔,決定詳細釐清這個問題。想試試 AI 的能耐,於是下了第一個 prompt: 分析 SessionManager 的 processEncryptedData 方法中,為何會發生 bytesToTrim > currentLength 的錯誤?從呼叫該方法的地方分析可能發生的原因。 AI 給出了幾個可能的原因: 加密數據損壞或截斷 網路傳輸過程中數據包丟失或損壞 API 回應中的加密字串不完整 解密後的最後一個字節值異常大 錯誤的加密算法或密鑰 使用了錯誤的解密密鑰或 IV Session key 交換失敗,但程式繼續使用無效密鑰解密 解密產生亂碼 Hex 字串轉換錯誤 包含非法字符、長度不是偶數、部分缺失等問題 AES CBC 解密失敗但沒有檢查錯誤 Whitebox 密鑰準備失敗 IV 不匹配 數據長度不符合 AES 塊大小要求 PKCS7 Padding 格式錯誤 加密時使用了錯誤的 padding 方式 最後字節不是有效的 padding 長度值 (1-16) 多重解密處理錯誤 數據被重複解密或解密順序錯誤 記憶體緩衝區問題 緩衝區大小分配錯誤或溢出 AI 也分析了呼叫鏈: API 回應 → DataTransformer → CryptoHandler → decryptSessionKey → processEncryptedData 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...