2026年9月28日 星期一

iPhone 行動數據統計怎麼每月自動歸零?用「捷徑」一次搞定

你有沒有發現,iPhone 的「行動數據」頁面明明有每個 App 的流量排行,卻從來不會自己歸零?用了半年,數字大到根本看不出這個月是誰在偷跑流量。

其實只要用「捷徑」的自動化功能,就能讓它在每月帳單日自動重置。這篇教你怎麼設定。

先搞懂:為什麼要在手機上重置?

打開「設定」→「行動服務」,可以看到累計用量和各 App 的流量排行。這份資料有兩個特點:

  • 只有 iPhone 自己看得到每個 App 的用量。 電信業者的 App 只能告訴你 SIM 卡的總流量,看不出是誰用掉的。
  • 它是 iPhone 自己計算的,不會自動重置。 iPhone 只會在手動按下重置時,才會重新統計數據,所以你的統計數據會包含按下重置後,到當下的所有流量。

手動重置的路徑是:設定 → 行動服務 → 拉到最下面的「重置統計數據」。既然每月都要做,就交給自動化吧。

設定步驟

步驟 1:進入自動化
打開「捷徑」App,點下方的「自動化」分頁。

步驟 2:設定執行時間

  • 「何時」設定特定時間設成 00:00
  • 「重複」選擇每月
  • 「開始」日期選你的帳單日(例如你帳單日是 10日就設為每月 10日)
  • 選「立即執行」,時間到了,會自動觸發。
  • 點「下一步」完成時間設定。

步驟 3:新增動作
選擇「新增捷徑」,然後在搜尋列輸入「重置」,找到「重置行動數據統計」這類動作並加入。

步驟 4:儲存
按右上角的打勾。回到自動化清單,看到剛才那一條出現,就完成了。

幾個小提醒

想保留每月紀錄? 重置前流量資料就沒了,可以在同一個捷徑裡,把重置動作前面加上截圖或記錄動作,把當月數字留下來。

總量還是看業者的。 iPhone 的統計和電信業者的數字常有落差,拿它來找「誰是流量大戶」很好用,但是否超量請以電信業者 App 為準。

結語

設定只要幾分鐘,之後每個計費週期你都能拿到一份乾淨的 App 流量排行榜。如果你也在意流量,不妨現在就去設定看看。


參考Apple 官網: 在 iPhone 或 iPad 上的「捷徑」中製作新個人自動化操作



2026年9月20日 星期日

你以為的角色代入,可能只是包裝過的上帝視角

 

一個很常見的場景

我請一位工程師用角色代入的方式重新看一遍需求。

他照做了。他很認真地想,也寫了一份東西給我。裡面確實提到了使用者、提到了操作情境、提到了他認為使用者會需要什麼。

但整份東西,從頭到尾都是上帝視角。

更麻煩的是,他不知道。他不是敷衍,也不是抗拒,他是真心認為自己剛剛做的那件事,就叫做角色代入。而且看起來,他已經這樣認為很久了。

問題不是「做不到」,而是「以為自己做到了」

如果一個人說「角色代入對我來說很難,我不太會」,這其實是好處理的。他有自覺,你可以給他框架、給他案例、給他回饋,他知道自己在進步還是沒進步。

難處理的是另一種:他心裡有一套「這就是使用者角度」的定義,那套定義從來沒有被檢驗過,而且很可能已經產出過很多份規格、得到過不少認可。因為表面上看,他確實有在「思考使用者」,只是那個思考的引擎,從頭到尾都是工程邏輯,只是換上了使用者的語彙。

這種狀況,你不是在補一個洞,而是要先讓一個人看見:他原本以為對的東西,其實是錯的。

幾個可以自我檢查的徵兆

假代入之所以難以察覺,是因為它長得很像真的。以下幾個徵兆,是我覺得比較好辨識的破綻:

描述需求時,主詞是系統,不是人。
「系統應該要擋掉這種情況」「邏輯上這裡要先判斷」——這些都是從系統內部往外看。真正的代入,主詞會是使用者:「他這時候會看到什麼」「他在這裡會不會知道自己該做什麼」。

解釋設計決策時,理由永遠是「合理」而不是「好用」。
「這樣比較嚴謹」「這樣比較好維護」「這樣邏輯比較一致」——這些都是對的,但它們回答的是工程問題,不是使用者問題。如果一個人解釋十個決策,十個理由都在這個範疇裡,那他思考的對象從來就不是使用者。

被問到「使用者當下知道這件事嗎」,答案是「應該知道吧」。
這個「應該」是最明顯的破綻。因為它代表回答的人,是用自己的全知去推測別人的認知邊界。真正代入過的人,會清楚知道這個角色手上有什麼資訊、沒有什麼資訊,答案不會是「應該」。

用第三人稱在想,而不是第一人稱。
「使用者應該會希望……」這種句式,本質上還是旁觀者在猜測。真正的代入是第一人稱的:「我現在要做的事情是……我現在卡住的地方是……」。句式不同,思考模式就不同。

為什麼會這樣?這不是態度問題

我想強調的是,這件事很少是因為誰不用心。它背後有幾個結構性的原因:

第一,知識的詛咒。
一個人一旦知道系統怎麼運作,要他假裝不知道,是違反大腦運作方式的。而諷刺的是,最常被要求做角色代入的人(資深工程師、最懂系統的人),剛好就是受這個詛咒影響最深的人。這是認知結構的限制,不是努力程度的問題。

第二,「站在使用者角度想」這句指令,本身就沒什麼用。
它只有九個字,聽起來很輕鬆,但它沒有給任何邊界。這個角色是誰?他知道什麼、不知道什麼?他現在的處境跟情緒是什麼?沒有這些限制條件,一個人很自然就會退回自己最熟悉的視角,也就是全知視角。指令的簡潔,掩蓋了背後需要的準備量。

第三,這件事沒有驗收標準。
use case 寫錯了,邏輯不通,看得出來。規格漏了流程,測試會抓到。但「你代入得夠不夠深」這件事,沒有格式可以對照、沒有人會說你錯,甚至連自己都判斷不出來。一個沒有回饋機制的能力,人是有可能用錯誤的方式做上好幾年的。

這為什麼重要

有人可能會說:需求分析是 PM 的事,工程師照規格做就好。

但實際開發的時候,規格永遠有縫隙。這個欄位留空要顯示什麼、這個 API 逾時使用者該看到什麼、這兩條規則衝突時誰優先——這些問題每天都在發生,而當下做決定的人是工程師,不是 PM。那些決策點,根本沒有機會回到需求端被審視。

所以如果角色代入這一步是失真的,後面再嚴謹的 use case、再完整的規格文件,也只是把錯誤的假設包裝得很整齊而已。

我自己的理解是:產品初期的需求分析,訂的是方向;工程師落地時做的,是把方向導正成真實路徑。兩者用的是同一種能力,只是解析度不同、發生的時間點不同。前者是巨觀的代入(這群人整體要什麼),後者是微觀的代入(這個人在這一秒、這個畫面下會怎麼反應)。

這也解釋了一個很常見的現象:方向明明沒錯,成品卻走鐘。因為使用者感受到的,從來不是方向對不對,而是無數個微觀決策累積出來的體驗。

所以,這是基本功

我一開始以為角色代入是一件很基本、很理所當然的事。後來才發現,它確實很基本,但一點都不簡單。

問題出在我們對「基本功」的直覺理解——我們常常把「基本」等同於「簡單」,但這兩件事從來就不是同一回事。

橫豎撇捺是書法的基本功,但寫好一橫要練很久。蹲馬步是武術的基本功,但蹲得標準、蹲得住,才最見真章。練音階是音樂的基本功,卻也是最容易看出程度差距的地方。

基本功之所以是基本功,是因為它使用頻率最高、影響範圍最廣、是所有進階能力的地基。正因為它離核心最近,反而最難精通,也最容易被輕忽。

基本功難,才是基本功的常態,不是例外。

而角色代入最難的地方,或許不是學會它,而是發現自己其實還沒學會。

2026年9月11日 星期五

Nikola Jokic:「別把我當榜樣」

 Nikola Jokic 最近在一個塞爾維亞的 podcast 上說了幾句不太討喜的話。

他說他越來越受不了自己的人氣,對主動跑來找他的人越來越沒耐性,也不太跟人拍照,因為那是屬於他自己的時間。然後他講了更重的一句:「有些人可能不喜歡我這麼說,但我不認為他們應該把我當成榜樣。」

三屆 MVP,用這種語氣談論喜歡他的人。乍聽之下,這確實像是一個站得太高的人,忘了自己是被誰抬上去的。

但我讀第二遍的時候,注意到一件別的事。


他每講一句,都會先幫自己踩一次煞車。

「這聽起來可能有點老套。」

「我知道這樣聽起來又很沒禮貌,但我能怎麼辦?」

「就算我的意見可能不受歡迎,我還是這麼認為。」

這不是一個遲鈍的人會說的話。遲鈍的人不知道自己踩到了什麼,所以他們說完就走了,不會回頭修補。Jokic 是每說一句就預判了一次對方的臉色,知道自己正在得罪誰,然後還是說了下去。

一個人如果一邊講一邊道歉,那表示他從頭到尾都很清楚這些話的重量。他不是失言,他是權衡過之後,選擇了誠實。


有意思的是,這個講法我以前在一個完全不相干的人身上聽過。

金城武談到「金城武」這三個字的時候說,他對經營這個名字完全沒有興趣,你應該去看他演出來的角色,不需要知道他是誰。接著他反問了一句:「你知道我是誰幹嘛,我一定不是那個金城武。」

他說,大家喜歡的那個人,其實是大家自己做出來的一個形象,而且不同地方的人想像出來的還都不一樣,裡面裝的是各自的投射。他只是莫名其妙待在那個殼子裡,陪著大家到現在。

而且金城武走得更遠。Jokic 懷疑的是「我夠不夠格被崇拜」,金城武懷疑的是更前面一層——那個被崇拜的人,根本就不是他。


一種被誤會成傲慢的自知之明

那為什麼會是他們兩個?

金城武十五歲那年去拍一支汽水廣告,動機是想賺錢買一台摩托車代步。他沒有想過要當明星,就這樣誤打誤撞被推了進去。

Jokic 在 2014 年選秀會的第二輪第 41 順位被丹佛選中,當時的轉播畫面正在播一支速食店廣告。

他們都不是衝著名氣來的。名氣對他們而言是副作用——是在做別的事情的過程中,不小心長出來的一個東西。

沒有人會對副作用產生責任感。只會想辦法讓它輕一點。


最後我想回到 Jokic 那段話裡,最不像抱怨的一句。

他說,比起那些跑來說「我好崇拜你」的人,他其實更希望有人跟他說點別的——比如你去動物園,拍了張照片。

他不是想要沒有人靠近,他只是希望靠近他的人,把他當成一個可以聊天的對象。


2026年9月3日 星期四

十萬元

 九月二日,國家電影及視聽文化中心辦台語片七十週年的活動。一位從高雄搭車北上的女士走上前,把十萬元交給文化部。她叫葉金杏,平時靠賣口香糖和資源回收維生。

她從國家電影資料館的時代到今天的影視聽中心,已經持續捐款三十年。

三十年來沒有人為她開過記者會,也沒有人需要她的故事。

今年不一樣了。

一個年度預算兩百九十六億的中央部會,收下一位靠資源回收維生的人捐的十萬元。

文化部長李遠:「葉金杏女士是上天派來安慰的天使,她的熱情、良心與義氣,也成為文化團隊在嚴酷考驗下繼續前行的最大動力。」

接著媒體接手。有一家報紙的標題是這樣的:「氣立院濫刪預算 婦靠資源回收存10萬捐文化部 李遠婉拒 結局超催淚」。

三十年的堅持,被壓縮成一則標題。她不再是一個影迷,她成了一個論據。

這份心意被收進口袋,然後被拿出來,給我們每個人看了一次。

她捐了三十年,而我們用了一次。

2026年9月2日 星期三

無人機真能保衛台灣嗎?

月產十萬架、地獄景象、二十萬架無人載具——這幾年,「無人機」幾乎成了台灣防衛的信仰。數字一個比一個大,聽起來充滿決心。

但我一直有個很基本的疑問:這些無人機,到底要用來打哪一場仗?

順著這個問題往下追,我越追越心驚。因為最後的答案,跟無人機幾乎沒關係——它關乎的是一件更根本的事:台灣到底該用什麼方式,讓一場戰爭「不必發生」。

這篇文章,就是我一路推下來的過程。


一、先講一個殘酷的事實:台灣打不起消耗戰

無人機在戰場上最耀眼的價值,是消耗戰——用大量便宜的東西,持續磨掉對方昂貴的兵力。烏克蘭就是這樣,一架幾百美元的無人機換掉俄羅斯一輛幾百萬美元的戰車,硬生生把俄軍拖進泥淖。

聽起來很適合台灣,對吧?弱者用便宜武器對抗強者。

問題是——台灣恰恰是最打不起消耗戰的那一方。

這不是氣話,是硬指標:能源九成七仰賴進口,天然氣安全存量只有十來天,海島沒有陸地補給線,封鎖一啟動供應鏈就斷。消耗戰的時間尺度是「月」、是「年」,而台灣連「週」都撐得勉強。

於是第一個矛盾就冒出來了:無人機的核心優勢在消耗戰,但台灣是最不能打消耗戰的一方。把一件「消耗戰利器」當成主力,交給一個「必須速決、拖不起」的防禦方——從戰爭邏輯的根上,就錯配了。

二、中共真的會登陸嗎?別忘了孫子怎麼說

要決定買什麼武器,得先搞清楚對手會怎麼來。

孫子兵法兩千年前就排好了順序:「上兵伐謀,其次伐交,其次伐兵,其下攻城。」 登陸攻城,是成本最高、風險最大、擺在最後才考慮的下策。連解放軍自己的作戰思想,都把兩棲入侵放在選項序列的末端。

今年的伊朗,就是最好的教材。伊朗根本沒有入侵美國的能力,但它光是威脅要封鎖荷姆茲海峽,就讓全球油價震盪、市場一片恐慌。

封鎖的門檻遠低於入侵,殺傷力卻不成比例地大。

對一個能源命脈全靠進口的海島來說,這才是真正該冒冷汗的地方:中共很可能根本不需要登陸,光靠封鎖、甚至準封鎖,就能把台灣逼到牆角。

那問題就尖銳了——一整套為「反登陸」打造的無人機大軍,是不是正在拚命準備一場對手大概率不會選的仗?

三、那反登陸還有意義嗎?有,但意義被講錯了

有。只是它的意義,不在「打贏登陸戰」,而在一個更微妙的地方:把登陸這扇門堵死,逼中共退回封鎖選項。

這是一種「陽謀」——而陽謀最厲害的地方,就是被看穿了也照樣有效。

一般的計謀,被識破就失效了。但這套邏輯不一樣。就算中共的軍事菁英算準了「台灣是故意把登陸代價墊高,好逼我改走別條路」,他也沒輒——因為堵死登陸的是物理現實,不是心理錯覺。氣墊船不會因為他看穿了就變得更抗打,灘岸的傷亡數字不會因此少一個。看穿之後重算一遍,答案還是四個字:登陸不划算。

有人會問:把對手推向封鎖,不就是把他趕進台灣最打不贏的房間嗎?

沒錯,封鎖一樣是死局,它不會自己變好。但登陸和封鎖這兩種死局,有一個決定性的差別——時間。

登陸要的是速戰速決、既成事實,把時間壓縮到零。政權沒了就是沒了,沒有下一回合。

封鎖不一樣。它把時間攤開成一段中共控制不了的漫長過程:國際會不會介入?供應鏈的震盪會不會反過來重創中共自己?拖得越久,國際的反對會不會越硬?這些變數,沒有一個是北京說了算。

對弱者來說,確定的局面永遠不利——強弱已定,確定就等於認輸。只有不確定,才留得住翻盤的縫隙。台灣要爭的,從來不是「贏」,而是把「確定的失敗」,換成「不確定的僵局」。

而時間,是唯一能完成這個轉換的東西。

四、真正的目標:讓對手自己「算出」不要打

講到這裡,無人機的問題已經不是技術問題,而是戰略問題了。

台灣真正要的,不是一支能打贏解放軍的軍隊——國力擺在那,那不可能。台灣要的,是把整個台海的局勢,佈置成一個特殊的樣子:

讓中共的軍事菁英,用他們最引以為傲的孫子兵法,認真、聰明地算一遍,然後自己得出結論——「登陸是最爛的選項,不如退一步。」

這比「嚇到對手不敢打」還要高一個層次。

嚇阻,靠的是「對手忌憚你的力量」,那需要你真的夠強。但這套設計,靠的是「對手信任他自己的智慧」——他不是被你嚇退的,是照著他自己的兵法邏輯,主動選了對台灣傷害較小的那條路,甚至還會覺得,這是他自己下的一步高招。

這才是「不戰而屈人之兵」的真義。孫子說:「百戰百勝,非善之善者也;不戰而屈人之兵,善之善者也。」最高明的屈敵,不是讓對手怕你,而是讓對手用他自己的腦、走你鋪好的路,還以為那是他自己的選擇。

而這套設計最牢固的地方在於:對手越聰明、越懂兵法,就越會走進這個結局。 這是世界上唯一一種「對手越強、你反而越安全」的結構。

五、回到無人機:它為什麼是錯的工具

現在,再回頭看無人機,一切就清楚了。

這套設計要成立,只有一個關鍵:擺在對手面前的那盤棋,必須讓他怎麼算都算不出縫。 任何讓對手覺得「我有辦法破、我或許有機可乘」的東西,都在破壞這個局。

而無人機,恰恰是中共最容易「算出縫」的那一個。

為什麼?因為他不是在應付一個陌生威脅——他自己就是無人機世界第一。 你拿他最擅長的東西去嚇他,他手上有四張現成的牌可以拆:

  • 電子戰:無人機的死穴是電磁依賴,而登陸作戰本來就伴隨大規模電磁壓制。你的無人機在最需要它的渡海、灘岸那一刻,恰好最容易被癱瘓。
  • 反無人機體系:他打的,是自己家最熟悉的東西。
  • 產能碾壓:跟世界工廠比誰便宜、比誰量大?這是弱者最不該選的賽道。
  • 供應鏈:台灣無人機的部分上游零組件,至今仍捏在中國市場手裡。

當中共推演完台灣的無人機牆,他的結論不會是「登陸太貴,算了」,而是「這道牆我有四種辦法拆,而且每一種我都比你強」。那一瞬間,「登陸不划算」的局就裂了縫。

你要他算出唯一答案,無人機卻遞給他一個「或許有機可乘」的反算空間。用無人機去嚇一個無人機大國,等於跑到對手的主場、用對手最強的武器跟他對賭——這是弱者的大忌。

更別說,烏克蘭的成功根本搬不過來。

烏克蘭的無人機神話,建立在三個條件上:野戰、游擊、消耗。而台海把這三個全部反轉——渡海不是野戰,狹小的本島無處可游,速決撐不起消耗。同樣是弱者,烏克蘭是「拿無人機的弱者」,台灣卻是「被對方無人機壓著打的一方」。我們搬來了武器的軀殼,卻搬不來讓它生效的戰場。

至於無人機真正能發揮烏克蘭式威力的場景——「登陸已經成功、進入陸地巷戰」之後——那更是台灣絕對不能走到的未來。真打到那一步,共軍已經站在台灣的土地上,在自己的街道、自己的家園裡消耗中共,就算獵殺再多戰車,也是贏了戰術、輸了一切。

無人機的優勢,恰好長在台灣的傷口上。

結論:先擋住對手的王牌,別急著模仿它

如果戰略目標是「讓對手算出不打」,那台灣真正該重壓的,是兩樣東西。

第一,是在對手兵法推演裡「折不出縫」的傳統機動武器。 抗干擾、不吃電磁、藏得住、必須用實體火力硬清的反艦飛彈、水雷、岸置火力——它們讓渡海這一段,無論對手怎麼算,都是一台血肉磨坊。這種嚇阻折不了價,因為中共沒有一張「這領域我世界第一」的牌可以打。

第二,是反無人機。 因為無論中共最後選登陸、封鎖還是灰色地帶施壓,他都會鋪天蓋地地放無人機。你擋不住對方的無人機之眼,就連「把戰力保存到決勝那一刻」都做不到。漢光演習連四天都攔不下侵擾的無人機——這已經是夠響的警鐘了。

在台海,無人機首先是一個「威脅」,其次才可能是一個「工具」。 弱者的第一要務,永遠是先擋住對手的王牌,而不是急著去模仿它。


說到底,台灣要打的,從來就不是解放軍的部隊,而是解放軍的決策。

所有的裝備、所有的部署,最終都服務於同一個目的:讓對手用他自己最聰明的算計,算出「不打」這個答案,並且心甘情願地走上這條路。

這不是一場武器規格的比拚,這是兵法。

而一支會讓對手覺得「有機可乘」的無人機大軍,削弱的,正是這盤棋最需要的那個東西——一個再聰明的對手,都算不出縫的「勢」。

2026年8月25日 星期二

從一則租屋貼文開始,我重新想了一遍「該不該買房」這件事

 

簡短版:老了租不到房是真議題,但會隨制度演進被解決;房價未來會走向區域分化而非全面噴漲;真正該擔心的不是「以後買不起」,而是「寬限期結束後還不還得起」。

起點是一則論壇貼文,說「包租代管有潛規則,超過45歲或50歲就不給租」。我一開始以為是憑空捏造,去查了之後發現:年齡歧視這個現象確實存在,但「包租代管潛規則」這個說法應該是混淆了兩件事——年齡歧視是一般房東的普遍心態,而包租代管其實是政府的媒合政策,裡面反而有針對45歲以下青年的加碼補貼。兩件事被拼在一起,就變成了一個聽起來很嚇人、但細節不太對的說法。

不過查證的過程讓我一路往下挖,最後想通的東西反而跟租屋沒什麼關係,是關於買房決策的。以下是整理下來的心得。

一、「老了租不到房」是真議題,但沒有想像中可怕

日本的產業調查顯示,全國632家租賃住宅管理公司中,約49%坦承過去一年曾因年齡拒絕過高齡租客;日本厚生勞動省的政策文件更直接寫明,高齡者被拒租的理由中約九成是擔心屋內死亡事故。這不是台灣網友的錯覺,是有數據支撐的普遍現象。

但拆開來看,房東在意的風險其實是兩塊:

  • 收租穩定性——這塊可以用穩定收入或資產證明化解。
  • 孤獨死/身後事風險——這塊跟你有沒有錢完全無關,買房也解決不了。你自己的房子一樣需要有人在你過世後處理繼承、清空遺物。

日本從2001年就開始立法因應,現在已經發展出終身建物賃貸借(租約在承租人死亡時終止、不由繼承人繼承)、居住支援法人代辦遺物處理,以及物聯網感應器搭配孤獨死保險的商業方案。台灣目前還停留在個案報導階段,但隨著2025年底正式進入超高齡社會,這個議題遲早會被迫進入政策議程。

我的結論是:這是一個會隨制度與保險科技成熟而逐漸被解決的趨勢性問題,不是恆定不變的懲罰。用一個20-30年後很可能已有解方的未來風險,去綁架現在的財務決策,權重明顯失衡。

二、房價不會全面噴漲,但也不會全面崩盤——會走向分化

日本的現況很有參考性:東京市中心新建公寓均價創下歷史新高(2025上半年約1.3億日圓),但鄉下地區卻出現大量「空屋」,有些物件只要兩三百萬日圓,甚至有地方政府倒貼求人入住。

原因很直白:房價漲不漲,除了資金,還得有人來撐腰。人口流入的地方漲,人口流出的地方跌。

台灣的人口結構走得比日本更快——2018年跨過高齡社會(14%),2025年底就進入超高齡社會(20%),只花7年;生育率0.87是全球最低;25-44歲適婚族的未婚率從1990年的21%攀升到2020年的43%。這些數字幾乎鎖死了未來20-30年的軌跡。

所以我認為分化是必然的:蛋黃區因稀缺性和資金磁吸效應持續緩漲,蛋白區在人口流失壓力下,長期恐怕連「持平」都守不住。

另一個常被忽略的因素是:台灣央行現在手上的工具(選擇性信用管制)比QE時代精準得多,可以只鎖定房市降溫、不必動用會波及出口和整體經濟的全面升息。而金融體系裡的利害關係人(公股銀行、壽險業)本身持有大量不動產相關資產,他們要的是溫和上漲、不是暴漲泡沫——因為泡沫吹得越大,被迫戳破時的資產減損越慘。這解釋了為什麼房價很難被放任狂飆,也很難被打到真正崩盤。

由此延伸出一個我覺得最實用的判斷準則:思考「現在不買以後就買不起」這句話時,要問的是——你買得起的標的,是不是那些「有人想保護」的標的? 如果是雙北蛋黃精華地段,這句話可能有幾分道理;如果是蛋白區、缺乏在地就業支撐的重劃區,那這句話對你適不適用,值得打一個大問號。用蛋黃區的漲勢故事去合理化蛋白區的購買決定,本身就是範疇錯置。

三、兩句經典話術的問題

「現在辛苦一點,以後薪水漲了就輕鬆」

中研院的研究指出,台灣實質薪資自1990年代末就與GDP成長脫鉤,2001-2012年間兩者甚至呈現高度負相關。2025年1-10月經常性薪資中位數是38,319元(不含年終獎金),年增率約3%。但新青安寬限期一到,月付金可能從1.5萬跳到3.5萬——五年薪水累積漲17%,還款壓力卻暴增130%以上。這句話預設的前提,過去25年沒有發生過。

「現在不買以後就買不起」

這句話的陷阱在於:只要房價長期趨勢向上,它在任何時間點講都成立——十年前講對、現在講對、十年後大概還是對。一句永遠正確的話,本身就不含任何可用來做決策的資訊。它唯一的功能是製造急迫感,讓人跳過「我到底負擔不負擔得起」這個真正該問的問題。

四、最危險的安全網幻覺:「大不了寬限期後賣掉」

這可能是整套話術裡最致命的一環,因為它同時解除了「買不買」跟「還不還得起」兩層焦慮,讓人放心跳進去。但這個退路建立在三個你完全無法控制的假設上:房子要漲得比貸款餘額多、市場要有人願意接手、時機要剛好對你有利。

現實是:寬限期到期就是月付金瞬間翻倍的那一刻,你被迫在短時間內脫手,而房子的流動性遠不如股票。市場冷卻時買方只會更往抗跌的蛋黃區集中——你不是在挑買家,是在求買家,議價能力最弱的時刻,正好是你最需要脫手的時刻。

至於「順便躲房地合一稅」的算盤更是誤解:房地合一稅的持有年限級距(2年內45%、2-5年35%)設計初衷就是懲罰短期持有。寬限期五年內脫手,正好落在制度想課重稅的靶心上,不是鑽到什麼漏洞。

結論:把「累積資產」跟「一定要買房」分開想

買房只是資產累積的其中一種形式,不是唯一形式,更不是任何時候都適合的形式。

當下的環境——全國房貸負擔率超過四成、台北市超過六成、新青安寬限期斷崖將至、機動利率正常化風險未解、人口結構對特定區域不利——對資金本來就緊繃的人來說,容錯空間比過去小得多。

話說回來,我不是反對買房。 如果你的收入穩定、買的是有實質就業與人口支撐的區位、而且用完整本息攤還(不是寬限期優惠月付)加上比現在更高的假設利率去試算,結果仍在合理負擔範圍內,那買房當然是好決定,甚至是很好的資產配置。

我在意的只是:不要因為怕老了租不到房,就被恐懼推著做出超出能力的槓桿決定;也不要因為輿論說「以後會更慘」,就跳過那個唯一該誠實面對的問題——

拿掉寬限期的糖衣、用比現在更高的假設利率去算,這個月付金,你現在真的撐得住嗎?

房子從來不是安全感唯一的來源。管好自己能驗證、能控制的財務現實,比賭一個高度不確定的總體趨勢,實在得多。


主要資料來源:內政部房價負擔能力統計、國家發展委員會人口推估、行政院主計總處薪資統計、中研院經濟所薪資停滯研究、日本國土交通省與厚生勞動省住宅政策資料、at home 高齡者賃貸居住調查。

2012年10月24日 星期三

WPF概觀:什麼是WPF



WPF是 Windows Presentation Foundation 的簡稱,中文直譯就是視窗表示介面基礎....翻得很爛,換個方式講就是視窗程式中編寫程式表達層(一般指UI)的技術與工具,他是微軟.NET 3.0表發表的幾個應用程式框架當中之一,以下節錄MSDN的描述:
----------------------------------------
WPF 是以 .NET Framework 型別子集的形式存在,這些型別多半位於 System.Windows 命名空間中。如果您以前曾使用 ASP.NET 和 Windows Forms 等 Managed 技術,以 .NET Framework 開發應用程式,那麼您應該熟悉基本 WPF 程式設計的過程,包括具現化類別、設定屬性、呼叫方法以及處理事件,全都使用您偏好的 .NET Framework 程式語言,如 C# 或 Visual Basic。
----------------------------------------
    看不懂?我們先別以程式語言的角度來看。
從發展史角度來看,以微軟對圖形化使用者介面(GUI)開發工具的支援發展史觀察「Win32API → MFC → ActiveX/COM/VB → Windows Forms(.NET Framework)」一直到現在.NET 4.5都還持續擴充的Windows Presentation Foundation (WPF) ,可見WPF應該是未來微軟主推支援GUI的重要開發工具之一。

    從支援架構角度來看,簡單利用多層式架構來講解一下WPF的應用範圍;在多層式架構資料應用程式中至少包括三層:
1.          展示層(Presentation Tier):是使用者與應用程式進行互動的那一層,其中通常也包含其他應用程式邏輯,例如一醫療系統中,病人如何開始進行看病的流程;看病過程中各種資料呈現的方式(藥師的藥單、病人的收據)。常見的展示層通常包含:
n          資料繫結元件,例如 BindingSource 和 BindingNavigator。
n          資料的物件表示,例如在展示層中使用的 LINQ to SQL 實體類別。
n          本機資料庫,通常是作為資料庫快取的功能。
2.          中介層(Middle Tier): 是展示層和資料層用來彼此通訊的那一層 (Layer),例如醫生可以看哪些病人,掛號到取藥有什麼程序、住院到出院有什麼流程等。 典型的中介層元件包含下列各項:
n          商務邏輯,例如商務規則 (Business Rule) 和資料驗證。
n          資料存取元件和邏輯,例如ADO.NET、驗證、授權和個人化等。
3.          資料層(Data Tier): 基本上是儲存應用程式資料的伺服器 (如SQL Server 的伺服器),例如醫院的藥品列表、人員列表、病例列表等。

其中,WPF的功能就是用來編寫應用程式的展示層,而中間層與資料層的開發上,微軟也有提出新的技術WCF(Windows Communiation Foundation)與WF(Windows Workflow Foundation);當然,若程式的只是一個視窗的獨立程式,也一樣適合用WPF來架構(即展示層程式可視為Cient端程式,Cient端程式可視為獨立應用程式)。
從上面看起來好像WPF只是一個比較新版本的GUI編輯工具而已,跟以前的MFC、VCL(Borland)等有何不同呢?當然有不同,而且是整個程式設計模式概念上的不同,不過可能要從WPF架構上開始講起才能講得比較明確,但這又是一段很長的故事了(其實是小弟所學未精的關係),簡單來講,WPF對於使用者介面的描述採用可延伸應用程式標記語言 (XAML)  (XML的一種)來進行實作,而相關需求功能行為則隱藏在背景的程式語言(如C#)實作 - MSDN稱為Managed 程式語言)。