跳到主要內容

分紅型保單

昨天下午接到一個要作投資介紹的電話,想想當時沒什麼bug,就去聽看看。下去一看,就看到兩位美女,眼睛登時亮了起來,根據判斷應該是一個老鳥帶一個菜鳥,跟我作介紹的那位美女真的很正,那天早上我還在感嘆,最近上班路途都看不到什麼美女。好久沒跟這種等級的美女談話了,感覺真的很爽,就算是被推銷也很爽。其實這分保單,很適合我,我一直想將一部分的資金丟進這種固定收益的投資裡,裡面提得利率很吸引我,當然我知道不可能年年有那麼多分紅,不過他的固定收益看起來有5%,還不錯。

其實我覺得她跟我推銷的話術,對我完全沒有用,因為從她推銷講的幾個重點,從準備退休預期資金、不受景氣循環影響的投資、此保單可隨時提領利息的優點等,其實都不是很吸引我。可是她應該看出我的眼睛充滿著微笑,沒辦法太久沒跟美女談話了,無論講什麼我都會很高興。不吸引我的原因:

  1. 從退休金額這點來說,以我的生活費計算出我的退休基金,但我的生活費實在太低了,算出來只要五百萬,她也很訝異我的生活費如此的低,其實原因在於,剛出社會的年輕人,不花這麼少怎麼存的到錢。我覺得她如果聽到我的生活費用那麼低,她應該猜得出我是單身,沒有女友要供養,花不了什麼錢,其次不應該從我現在的生活費來計算,應該以合理的費用來計算,例如從房租15000+生活費10000+醫療費5000+娛樂費5000這樣較合理一般的生活費用一個月要35000,在乘以12月然後乘以20年再乘以通貨膨脹率約1.2,所以退休金大概要1000萬以上,數字多起來是不是好一點。但其實數字的多寡都不會吸引到我,因為這不影響這項保單的本質,它能替我賺多少錢,對我而言這才是重點。
  2. 不隨景氣循環影響的投資,聽起來好像不錯,但事實上,根據這分保單三項重要利益來看,每月儲蓄利息,到期利息,分紅,除了到期利息不受景氣影響外,另外兩個其實還是受影響,儲蓄利率是隨著銀行利率變動的,這也是隨著景氣來變化的,分紅指的是富邦的投資獲益,如果富邦賺錢分紅自然多,但是景氣不好,賺的錢還有像去年那麼多嗎?終究來講,事實上只有一項不受景氣循環的影響,便是到期利息收益,這部份啊不就跟銀行定存一樣嗎?就算定存利率是浮動的,但是定存與活存的利率差不多就和這個到期率一致嗎,這利率其實隱含著通貨膨脹率啊。所以不隨景氣循環影響,再我眼裡並不成立。
  3. 可隨時提領利息,嗯這大概算第三個我記得的優點吧,其實也不是什麼優點,利息其實不多,只是在保單約期,可以自由動用小部份資金,流動性依然不佳,不解約而要調度使用本金,還是要使用質借的手段。這或許算相對於銀行定存的優點吧!

我覺得中間他有講投資股票或基金,最近市場大挫,可能賠很多,倒不如買她的保單,這是個不錯的突破點,可惜她又繞回不隨景氣循環的觀點。雖然投資股票和投資基金這種東西,在我認知不能和這種分紅型保單相提並論,收益和風險不能相提並論,因為我願意高收益而承受高風險。如果我是她,在她聽到我有投資基金,而基金裡面有一檔是債券的時候,應該可以猜出我投資債券是來降低風險而收取固定收益,那麼就可以提出說,分紅型保單這商品沒有風險,並且其收益甚至比一般債券基金還要高,這種收益較高的投資管道,完全可以取代債券基金或銀行定存。

其實如果我是她的話,我會先從投資組合來講,許多投資書籍(漫步華爾街、自動千萬富翁)說投資組合中建議有一部份要放入穩定固定收益的投資中,一開始就利用這些書中的觀點來說服人,一定要有部份的金額投入穩定固定收益中。再來開始比較一些穩定的收益方案,例如定存或債券基金,甚至穩定而高股利股票像中鋼、台塑等比較這些投資方案,提出此保單對相對於這些固定收益的投資的優點,而不是將這分保單與高風險的投資作比較,這定位不同。或許這樣比可以說服不懂投資的人,但對我這種看了快20本以上投資書籍的人,這種方式不太能說服我。

今天收到她寄的資料後頗失望,裡面沒有我要的資訊,至少她應該寄給我她當天說明投資範例的表格,而不是網站的資料,網路上的資料實在貧瘠得很。如果更好的話,應該是excel表格,裡面有各項利率公式,可依照輸入本金金額與利率、分紅預估最後的收益。如果她能夠用筆電來說服,我想會更棒。不過我收到信之後,才瞭解這是分紅型保單,我應該會去比較其他家的分紅型保單。

當然我對她的好感十足,不僅漂亮,說起話來很有自信,還是同鄉(這招高,拉近不少距離),雖然她推銷的內容,不是很吸引我,但是人吸引我,就算當交個朋友也很好(雖然心中很扼腕她結婚了,但和美女談話心情就是好)。如果收益和其他家保單沒有差很多的話,其他家也不是美女推銷員的話XD,保單內容也沒麼大問題的話,我應該會買。我覺得她應該很有未來性,如果懂政治手脕,運氣不太差,早晚是個副總級人物。

留言

Link寫道…
其實第二次會面,我正跟爆發中的bug奮戰,跟美女聊天很快樂,但是一想到那榮登bug之王悲哀,就不得不趕快上樓繼續奮戰。說實在的,我有以提振士氣的想法下去的。其實就第二次的講法來說,因為我大致想通這個投資的內容,所以其實好不好並不準,從結果來講是好的,因為我簽下合約了。後來其實想想,這篇感想是有問題的。有空我來寫一個我想像的推銷手法,這個有空也不知道要到何時了。

這個網誌中的熱門文章

解決 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 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...