跳到主要內容

巴菲特原則

看完智慧型股票投資人和非常潛力股後,再看集兩位作者大成的巴菲特,讓我對價值投資更有感覺,只是看完後,突然回想台灣有那種適合巴菲特原則的股票嗎?鴻海、統一可能是吧,他的獨占性質讓我印象深刻。

對比智慧型股票投資人和非常潛力股,巴菲特原則較特別的一點是,獨占消費的原理和扣稅因素,獨占消費是造成持續成長的原因,賣出股票獲利必須考慮扣稅問題,可是現行國內除了股利之外好像沒有對股票投資獲利苛稅,還得再思考一下。

書摘

思考的基本方式

  • 你付出的買價決定投資報酬率的高低。
  • 為了決定你的投資報酬率,你必須先能合理地推算企業的未來盈餘。

分析變數

  • 每年每股盈餘數字
  • 他的可預測性
  • 股票市價

一個二流的企業最有可能仍舊是二流的企業,而投資人的結果也可能是二流的。

商品型企業(價值低)

  • 低利潤
  • 低回收率
  • 缺乏對品牌的忠誠度
  • 大量的生產者
  • 實質生產力過剩
  • 變化不定的利潤
  • 收益幾乎完全仰賴管理階層有效運用公司的資產。

消費獨占確認

如果一個人擁有數十億美元,以及全美最優秀的前50位經理人員,他能建立一家企業然後成功的與問題中的企業競爭嗎?如果是「不」,這家公司有某種強大的消費獨占特性保護著。

找出值得投資的優質企業

  • 該公司是否具有明顯的市場獨占特質。
  • 該公司的獲利是否很強,而且呈現成長的局面?
  • 該公司是否採取較保守的財務策略?
  • 該公司是否能經常維持高股東權益報酬率?
  • 該公司是否保留他的盈餘?
  • 該公司要花費多少成本才㡪維持現行的營運?
  • 該公司是否能自由運用保留盈餘,並轉投資在其他新的企業,或者用以擴充營運,或者購回自家公司股票?而該公司的營運管理階層處理上述問題的能力?
  • 該公司是否能任意調整其產品價格以反應通膨壓力?
  • 公司運用保留盈餘所帶來的附加價值是否能增加該公司股票的市值?

「過橋收費」概念企業

  • 能生產使用率很高且耐久性短的產品的企業,但這些多半是耳熟能詳的消費性品牌,所以商家都必須販售這些商品以維持基本營運量。(可口可樂)
  • 能提供重複性服務的傳播事業,也是廠商必須利用來說服大眾購買其產品的工具。(ABC電視網)
  • 能提供一般大眾與企業持續需要的重複消費服務的企業。(美國運通)

具有企業主眼光的經理人

  • 將資產分配在獲利高的投資上。
  • 盡可能保持高資產報酬率。
  • 如果沒有更好的投資機會,把保留盈餘當股利配發出去,或用來買回自家股票。

如果你已經證實某家公司具有營運良好或者消費獨占特性或兩者兼具,就可以預期該公司一定可以在經濟不景氣的狀況下生存下去,一旦度過這個時期,將來的營運表現一定比過去更好。

你所設定的投資報酬率最起碼要等於通貨膨脹率加上所得稅率,才是其對實質財富所造成的抵減幅度。

企業財務測試

  • 預估企業盈餘
  • 決定期初報酬率
  • 決定每股成長率
  • 和公債比較決定一家公司價值

不要在意一家公司來年可以賺多少,而看重這家公司10年內可以賺多少。

好企業能抓牢客戶,持續為股東賺取高盈餘,就算本益比非常高,也往往還是合算的買賣。

本益比,用過去10年的平均最合適。

以某價位買入買公司股票,在已知的公司資料中,他的10年預期年報酬率會是多少?決定預期報酬率後。在將他與其他投資機會的報酬率以及超越通貨膨脹率必須的報率合併考慮。

針對特定期間內該事業的每股保留盈餘,與一段時間內每股盈餘的成長相比較。

只在正式公告出售或合併之後才會著手進行投資套利。

先檢視該公司然後在由市場價格決定是否買進。

個案分析步驟

  1. 是否消費獨占
  2. 如何營運
  3. 財務狀況是否嚴謹
  4. 是否賺錢,前景是否看好
  5. 資金分配只限在他專門知識領域上。
  6. 是否買回庫藏股
  7. 運用保留盈餘
  8. 資產報酬率在平均值以上
  9. 不受拘束地因應通貨膨脹調整價格
  10. 是否需要將大筆資金消耗在持續更新公司的廠房或設備上

價格分析

  • 期初報酬率與政府公債的相對價值。
  • 是愈投資的股票為「股權債券」。
  • 過去每股盈餘的成長預估每年的複利報酬率。

留言

這個網誌中的熱門文章

解決 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...

萬年季

這個活動上上個禮拜六看到新聞,我以為只有一天,禮拜日就沒去,感覺有點可惜。沒想到是九天的活動,看到阿蓮他們也要去。那就剛好約一起去囉!前一天剛騎完充滿自我鍛練的阿里山之旅,又摔車,左手臂形同殘廢,但是既然約好了還是要去,捨命陪美女。那天阿蓮一直說他可能遲到,沒想到當天因為跑去看醫生,結果遲到的人是我。拍謝啦!當天中午吃飯,虹君還問我明明知道馥菁沒來,為什麼還要來,ㄟ!太明顯囉!我是這種人嗎?我會讓Jim獨享兩位美女嗎?喔!不!我會拋棄Jim嗎?約了就要來啊!虹君後來說,他原本拔智齒也不太想來,臉太腫了。不會啊!我看不出來,都一樣圓!ㄜ!不!一樣可愛!笑起來,頗令人心動(有圓回來嗎..) 所有照片http://picasaweb.google.com/cccmail/JVqzQG# 從中午就一直繞著蓮池潭逛,上次來的時候還在清潭,封閉中,這次來看果然漂亮很多,和小時候的印象完全不一樣。大家好像不喜歡照相,身為高雄人在蓮池潭照相,有種詭異的感覺。 照這種人形立牌,是我很喜歡做的事,看得出來誰是誰嗎? 過七關,有意思的祈福關卡,但是太多人了沒去排。 阿蓮與蓮花。蓮花太小了。 偷照擺Pose。 當天在廟口前的表演,人太多,只能從狹縫中看到一點,兩位女生,完全看不到.. 看了一陣子,他們終於受不了,拉我們走了。順便去吃晚餐,Jim也受不了,他要找個位置坐下來,他說那天好像行軍,走的腳超酸。結果途中遇到馥菁帶著學妹來逛,78年次,喔!這個補!喔!不!真年輕。哥哥可以裝年輕嗎?很多人看我不是還是學生就是剛畢業!看樣子我可以講我75年次,這有人相信嗎? 歷經20多年再走一次龍虎塔與春秋閣,之前的18層地獄好像換掉了。我覺得是很棒的特色ㄟ,可惜了童年的回憶。 最後主舞台也是人山人海,只能看大螢幕。 失去舞台的舞獅,在人群中自己表演起來了。 主辦單位邀請各廟宇,舞獅或跳人偶的來表演。但是大家好像都表演得很盡興,無法控制長度,主持人一直在趕人,"XX國小,時間咖控制機勒,節目已經Delay了",國台英語交雜,頗有喜感。表演隊伍也很有意思,原本以為只是表演各廟宇慶典活動或民俗技藝,但沒想到還有原住民舞...

用 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 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...