公地悲劇—The tragedy of the commons

從前有個小村莊,旁邊有一大片公有的草原。

公地悲劇—The tragedy of the commons

從前有個小村莊,旁邊有一大片公有的草原。

有一天,有個牧羊人帶了一批羊在這邊放牧,他成功大賺一筆。接著,雖然知道過度放牧會導致草地承受不住,他還是帶著大批的羊,再次狠賺一波!隨後所有的牧羊人發現了,一股腦的跟進,草原上的牧草被過度使用,悲劇就發生了—— 這片草原再也不能放牧。

上述的故事,就是公地悲劇,是所有人的損失,甚至是跨世代的損失。但,你不覺得,身為人類的我們非常能能想像每個牧羊人的「理性」決定嗎?

每增加一隻羊隻能增加利潤。

開始的代價是相對小的。草原的消耗,是由所有的牧羊人一起承擔。加上賽局理論的思維,雖然知道羊隻過多會損害長期草原上的產值,牧羊人一定會想:『如果我不去放牧,其他人也肯定會去的,那我豈不是看著別人爽爽賺?

這樣的故事,似乎會在以下的前提不斷的重複發生

  • 草原是公有的,近乎零成本的使用
  • 牧羊人可以從增加的羊隻上獲得所有的利潤
  • 牧場的承載力因為額外增加的羊隻有所耗損

個人使用資源的成本小於社會的成本,資源被過度使用。

背後的啟示

人人所有,人人沒有

耗竭的草原在這個故事中,是一種誰都應負責任,誰都不負責任的狀況,出現的極端現象。在以下兩種前提之下,幾乎必然發生:
  • 資源的產權不確定(公有的草原)
  • 任何人近乎零成本使用,也無法排斥他人使用

以下也是類似公地悲劇的例子:

  • 過度砍伐的森林
  • 過度捕撈的漁業
  • 污染的河流和空氣

個人利益 vs 公共利益的矛盾

開始失去賺頭之後,部分的人才會開始退場。用一張圖就能看出追求個人利益和公共利益的矛盾。當人數在c/2的時候,有最大的公共利益,又能永續經營。因為每個人進場成本低,甚至超過c/2這個最佳人數之後,還是會不斷的有新人加入戰局,直到非常後期(草原快耗竭時)才會停止加入。

來源:https://blogs.cornell.edu/info2040/2015/12/03/23415/

解決方案

那要如何阻止公地悲劇的發生,根據過去的歷史,有三個方法:

公地私有化

任何資源應明確規範所有權和使用權。比如說這片草原是A所擁有,可以租給B、C、D來使用,A會為了長遠利益考量,而控制B、C、D的牧羊數量。

甚至可以把收益權和處置權更加的劃分清楚,來避免悲劇發生。

道德懲罰

這點是我認為最有趣的。過去的人類活在 50人左右的小群體,彼此認識,如果濫用公共利益來獲取個人利益,就會被大家自然排擠 。小範圍、資訊公開的前提下,可以想像依然是有用的方式。如:黑心企業造成環境污染,民眾就不願意去消費。

加強管理

雖然是公有的,但規範各種規定。如:分批增加進場資源競爭者的成本:對於新進的資源競爭者提高成本,甚至在高過於最大公共利益(c/2)之後有額外的懲罰機制,讓獲利急遽下滑,避免資源耗竭。


參考:

Read more

掌握幣圈脈動,告別 FOMO 的資訊自動化流程嘗試

掌握幣圈脈動,告別 FOMO 的資訊自動化流程嘗試

幣圈訊息瞬息萬變,是否常常覺得很 FOMO 呢? 常常一個小時不看新聞就可能錯過了新的趨勢或是有用的消息。因此,我嘗試打造一條「獲取資訊自動化流程」。我希望透過以下幾個步驟,將「從 RSS 收集內容 → 摘要與翻譯 → 儲存 → 在發文時快速取得重點資訊」的流程自動化或半自動化,讓我在想要發佈 Twitter (X) 貼文時,能有即時且經過整理過的資訊可供參考。 整體流程概述 目標流程:RSS → Apify → OpenAI → Airtable → Chrome Extension → 快速分享 * 取得 RSS 新聞來源:定期自動抓取最新文章列表。 * 解析並擷取內文(Apify):從原始頁面擷取重點文字段落。 * 整理與生成摘要(OpenAI):運用 AI 將冗長文章化為精簡摘要。 * 儲存到 Airtable:將標題、連結、摘要等資訊結構化存放,方便後續查詢。 * Chrome

最常見的 Git 工作流程 - GitHub Flow

一種簡單的工作流程,適用於快速開發和持續部署的小型專案。 流程 1. 始終從 Main 分支創建功能分支:bashCopy codegit checkout main git checkout -b feature/my-feature 2. 在功能分支中開發,並隨時提交: git add . git commit -m "Implement feature" 3. 開發完成後推送到遠端 git push origin feature/my-feature 4. 發起 Pull Request 並進行代碼審查: * 在 GitHub 上創建 Pull Request。 * 通過代碼審查(Code Review)。 5. 審核完成後合併到

測試驅動開發 (TDD) 與單元測試、整合測試的概念簡述

在現代軟體開發中,測試已成為不可或缺的一部分。不僅能幫助開發者捕捉錯誤,還能促進代碼的模組化和可維護性。本文將深入探討單元測試、整合測試的區別,以及測試驅動開發 (TDD) 的核心流程和實踐技巧,幫助你快速掌握測試的精髓。 也許 AI 程式碼生成工具,最能快速優化寫測試的開發時間。多少來學習一點測試相關的知識。 * 理解單元測試 (Unit Test) 和整合測試 (Integration Test) 的區別。 * 熟悉測試驅動開發 (TDD) 的概念。 單元測試 vs 整合測試 * 單元測試: * 適合測試邏輯簡單且內部不依賴外部資源的功能,例如算法、數據處理函式等。 * 主要用於開發階段,快速檢查某段程式碼的邏輯。 * 整合測試: * 適合測試業務邏輯需要依賴外部模組(例如資料庫、第三方 API)時的交互行為。 * 用於確認系統內部的協作是否無誤,通常在測試環境下執行。 特徵單元測試 (Unit Test)整合測試 (Integration Test)測試範圍單個模組或函式多個模組或系統的整合依賴性獨立,不依賴其他模組或外部資源需要依

PM 加速開發:ChatGPT 到 Cursor 再到 Windsurf 的體驗比較

我是技術背景出身的產品經理,十年前曾是一名寫 Objective-C 的 iOS 工程師。近年來,我利用零碎時間,結合 AI 工具,進行產品發想與概念驗證,並打造一些功能型網站。自 2024 年 6 月起,我的體驗大致可分為三個階段,以下是我的學習與心得分享。 第一階段:ChatGPT 助力,但流程繁瑣 最早是用 ChatGPT 協助產 Code,我一筆一筆貼到我的程式碼下。我要詢問怎麼改動的話,也要將程式碼貼回 ChatGPT,在大量的複製貼上等待的過程,非常慢跟耗時,瀏覽器也會隨著大量的文檔開始變慢。這時候,我從不會到能做出一個聊天機器人網頁,大概花一個禮拜。我也是在這個階段學會了如何用 Vercel 快速部署架站,還有基本的 Git 指令。遇到一點問題常常會卡關很久,要邊做邊學。 第二階段:Claude 加速開發流程 Claude