---
title: "全端與跨領域的學習科學"
date: "2026-04"
category: "隨筆"
tags: ["隨筆"]
description: "我最近確實是發現了，全端開發確實能讓人洞察到更多東西，尤其是那些前端和後端分別不同的坑和雷點。前端的bug有時候純粹是後端背鍋，比如出錯了卻只説出錯，而完全不提為什麼出錯，導致前端除錯除的寸步難行..."
source: "https://enriquemark.com/zh-hant/posts/%E5%85%A8%E7%AB%AF%E8%88%87%E8%B7%A8%E9%A0%98%E5%9F%9F%E7%9A%84%E5%AD%B8%E7%BF%92%E7%A7%91%E5%AD%B8"
---

我最近確實是發現了，全端開發確實能讓人洞察到更多東西，尤其是那些前端和後端分別不同的坑和雷點。前端的bug有時候純粹是後端背鍋，比如出錯了卻只説出錯，而完全不提為什麼出錯，導致前端除錯除的寸步難行。或者反過來，前端報錯，後端什麼都不清楚，卻「感覺」似乎是後端的問題，結果找半天發現方向錯誤。這些東西只有兩個領域都待過才能知道，其中的「領域知識」需要實際的操作過才能明白。光看文字而沒有實際體會過那種痛苦，就會始終隔著層紗。尤其是當我需要付出真實的成本去考量前後端開發時，就更是如此。只有自己體會過那段痛苦，才會有意的在開發時進行最佳化，付出額外的精力去顧及可能「不屬於自己」的問題。

甩鍋不是個好習慣，也許開發者自身是沒有惡意的，但是懶惰會讓人下意識節省掉一些本該有的東西，進而造成配合方的不便。往往為了剋制這種懶惰，要麼會使用制度來強制要求某些開發規則，要麼就是靠自律——而後者是最難的。這也是踩坑帶來的最大加成，它會讓你下意識去自律，不是我想這麼做，而是不這麼做我真的會痛苦萬分。只有debug de到力竭的人才能體會到那種想怒噴前/後端祖宗十八代的感覺：你就加個log，幾行程式碼的事兒，為啥不給我弄上。雙方都這麼想，結果就是互相給對方上強度。當然有些情況可能是企業制度的原因，但從個人的角度看，可以在制度之外將標準做法內化，正是技術能力的體現之一。

拋開靈活性，另一方面我覺得是洞察：知識的跨領域再現。我目前在前後端使用的都是強型別語言，TS+C#的組合也讓我看到許多共同的設計原則。比如DI，TS在做法上和C#幾乎是一致的，也意味著我可以同時在前後端使用這種模式。亦或者是關於泛型，這對任何強型別的語言來説都是一致的。也許有人會覺得，這和全端開發不盡然相關，更多的是語言問題。但當前後端前後端使用的語言和框架都不同時，正是全端開發給我提供了這種跨語言的理解環境。否則下意識泡在舒適區的任何人，恐怕都不會每天深度在多個語言之間切換。只有工作上的要求會迫使我寫完了TS前端再去看C#後端——而我在個人專案上都是TS一條龍穿到底，前端用React後端用nestJS的，誰會換另一個語言給自己找麻煩。

跨領域的再現有時會給人一種明確的「頓悟」感，我蠻享受這種感覺的。我們常説「看山不是山」，但具體如何體會卻總被認為是可遇不可求的。但我認為，這種感覺完全是可以是自己主動去製造出來的產物——關鍵便是主動的嘗試和跨領域，並用已有領域的內容來看新領域，並嘗試尋找可以遷移的知識。從學習科學的角度來説，這正是重構大腦神經連結，搭建自身知識網路的過程。和教科書不同，大部分真實知識從來都不是綫性、結構分明、體系明確的（數學可能例外），而是更傾向於來回跳躍。教科書上的知識也許是ABCDE，但到了具體完全可以是A到C到E最終才會回到B。因為工程上我們總是遇到了問題才會再去考慮這東西到底是啥，應用領先於理論，而應用上的我呢提也會成為我接觸理論的動機和出發點。最終我掌握了理論的目的也是要讓其回饋到我的工程上去，不像學校是為了應付考試。

另一個概念是「默會知識」或者説「隱性知識」。它正是一種讓人難以捉摸而大多存在於人之感覺中的只是。難以成文化，而只能靠工程師的經驗或直覺來把握的存在。像這種知識，在我看來體現的正是知識結構網路本身——不是以邏輯，而是以結構為存在的知識形式。隱性知識是對知識結構的把握。這種結構有時候難以言説，但卻真實的儲存在我的大腦之中。當需要時，從一個入口（訊號）開始，我會逐漸啟用整個網路，進而向前端推送出那種感覺。而這一網路是需要在不斷地互動和實踐踩坑中去獲取的。除此之外，搭建網路的另一個有效方法，便是跨領域的知識遷移。

通過遷移，知識在不同的新領域（生理上來説可以是新的神經組成）構建連結，進而湧現出此前未曾察覺的新內容。當兩個原先區隔的知識碰撞和互動時，新的知識也會在其中生成——而他們不盡然是可以言説的，也當然存在哪些作為「感覺」而存在的知識。

同時，不斷地遷移過程中，我自身關於「如何學習」的元能力也會得到訓練。每次遷移，我對這種跨領域就會適應一份，進而我的思維也越不會被已有的知識結構和體系限制。每次遷移，我所學到的東西都可能會和我預料不到的已有知識結構發生碰撞，進而源源不斷的產生連我自己都無法得知的新東西。只有跨領域能給人這種頻繁的「見山不是山」的體驗，這是長期浸泡在單一領域難以體會的。

跨領域時常被人反對的一點就是深度和廣度的取捨。但我覺得這裡不完全是矛盾的——深度和廣度可以互相促進。精力有限，我當然難以兼顧廣度和深度。但是擁有極其廣度知識的情況下卻能培養我的另一個能力——那就是學習的能力。同時，無論是前後端，事實上又都同屬於一個領域，即電腦科學。作為子領域來説，前後端的確是區分的，但他們又共同依賴著電腦科學這個大領域的知識主題。所以這裡的知識結構就會體現為大的套小的，小的再套更小的。前後端，就其知識本身來説有不少都是共通的。而這種共通也會加速我學習想要學習的指定領域之知識的速度。

就拿前端來説，有些人會認為知識的深度體現為對框架和工具的使用，或者是前端最佳化、實作中具體操作的標準解法。但是，高難度的前端當然不只是切版：效能調優、網路協議、甚至部分後端的高並發與資料結構、演算法等等，這些不是全部，但也都是前端深度知識的構成之一。我們都説前端一年一變，可即便如此，也總有些知識能夠儲存下來——比如跨框架共通的設計原則——一旦吃透，那麼我就可以快速掌握到深度之中。當我轉換框架時，實際上已經進行了一次前端內部的「跨領域」知識遷移。只是跨的幅度不大，有時候讓人難以察覺而已。

但是，如果我本就擁有經常跨領域的經驗，必然會很快察覺到這裡的共通性之所在。所謂的第一性的那些東西，往往都是共通的東西。如果說，長久的跨領域培養了我對第一性的洞察和學習能力，那麼我對所謂「深度」知識的掌握速度，也會遠遠大於一個多年泡在單一領域的人。一個多年前端可能對某些具體的專精知識鑽研的極深，我當然認為這樣的人是值得尊重且至關重要的。但是我們對大多數人來説，我不需要知道V8框架的某個深層細節到底是啥，而需要的是快速的工程能力——即達到工程可用的深度，這才是企業所需要的。那麼，如果我具備這種快速學習的能力，那我達到深度的效率也會讓我在需要的時候切換狀態，從廣度馬上轉換為「可用的深度」。因此，與其擔憂「廣度影響深度」，不如轉換視角，思考這樣一點：「我真的需要那麼多深度嗎？」

往往説這句話的人，他們看向的是專家，而不是可用的、深度的工程師。比起前者，企業在量上反而更需要後者。除非真的是特別要求專家知識的行業，或者就立志要進入到對專家深度有明確要求的崗位，否則「廣度」對個人的加成都始終是正向的，而非是像世人嘲諷的那般，所謂「多而不精」。因為他們只看到了「多」，卻忽略了更本質的層面——如何多？拉開差距的正是學習能力，一個「多」者必然有其自身的快速學習方法論，否則他不可能掌握那麼多。而一個能夠快速學習，掌握了「元學習技巧」的人，更能夠在需要的時候切換為「深度」的狀態，而且還可以是「多個領域的深度」。他之所以無法達到專家是因為精力和時間有限——但如果，他中途決定轉換道路或精深某一領域。他追趕並成為專家的速度和效率，也會超過那些長期只在單一領域待過的人。至少在這裡，「多」從不天然成為被嘲諷的「劣勢」，「如何多」才是關鍵。

如果我具備了能快速成為此類人的能力，自然就具備了更多的機會。跨領域作為一種優勢被如此嘲弄，反而磨滅了真正能夠創造價值的能力。一個有效的工具被「認為」是低效的，從工程角度來説，這毫無疑問是浪費。並且在我看來，之所以它會被這麼認為，恰恰是因為大多做出此類判斷的人缺少跨領域的知識——比如我就是從「學習科學」的角度來論證這件事的，若他從未接觸過學習科學，他當然就看不到這樣的角度。這至少就表明了拓展知識帶來的附加效果，有時候角度本身就很重要。