吾所到之處，君亦可至
這頁寫給正在被工具名追著跑的 IT 後輩。我重讀侯捷 1997 年這篇讀者問答，想留下三件可檢查的事：怎樣分清語言、工具與 framework，怎樣看待工業界的相容性成本，怎樣把挫折改寫成下一週的練習。
01 / 我為什麼選這篇
《無責任書評》有很多篇技術味更濃，例如 Windows 系統、MFC、OLE、書籍翻譯與出版市場。但如果要替 IT 後輩選一篇反覆讀，我會選〈吾所到之處，君亦可至〉。它表面上是讀者來函整理，實際上在做分類：語言是什麼、工具是什麼、framework 是什麼、工業界現實是什麼、資訊來源品質又該怎麼判斷。
這篇文章的價值，不在於它告訴你 1997 年該學 Visual C++ 還是 C++Builder；那些答案早已過期。留下來的是侯捷處理「技術焦慮」的方法：先拆掉錯誤分類，再把學習路線排回基礎、系統、工具與專案現實。
「吾所到之處，君亦可至。」
作為後輩，我讀到的不是居高臨下的安慰，而是一種嚴格的善意：你可以到，但不是靠捷徑到；你可以慢，但不能亂；你可以換工具，但不能把工具名誤認成學門。
02 / 基礎不是慢，而是未來切換成本的保險
文章一開始處理 C、C++、Turbo C、Visual C++ 這類名稱混淆。今天我們換成 Python、TypeScript、React、Next.js、LangChain、Cursor、Claude Code、Gemini CLI，也一樣常犯同樣錯誤：把語言、工具、框架、IDE、平台、工作流混在一起談。
侯捷替新人重建分類能力。C 和 C++ 是語言；Turbo C、Visual C++ 是廠商工具；MFC、OWL、VCL 是 application framework。這種分類看似基本，卻會直接影響學習決策。分類錯了，就會把「我不會 IDE」誤認成「我不會語言」；把「我不熟框架」誤認成「我沒有工程能力」；把「我被某個 AI 工具加速」誤認成「我已經理解系統」。
語言是表達問題與資料結構的基本文法。今天可以問得更尖一點：你能說清 TypeScript type system 的限制，還是只會接受 IDE 補完？
工具會加速，也會製造幻覺。越強的工具越要求使用者知道它幫你省略了什麼。
Framework 是交付現場，不是全部。你要知道它的主軸、生命週期、擴充點與邊界。
作業系統、網路、資料庫、部署與安全，不一定每天顯眼；一出事，它們會要求你付清欠款。
給 2026 年後輩的翻譯
不要把「我要不要學某某工具」放在第一題。先問：我正在補的是語言能力、系統能力、框架能力、產品交付能力，還是某個工具的操作能力？工具操作能快速換來產出，但如果沒有其他層次支撐，下一波工具更新就會把它歸零。
03 / 工業界不是反新，而是要為相容性付帳
文中討論 MFC 是否會被放棄時，侯捷指出學生與工業界老手之間有一道大峽谷。學生看見的是新工具的漂亮、快速與成就感；工業界看見的是已上市產品、既有客戶、版本維護、回溯相容與主架構穩定。
這段今天尤其值得讀。AI coding 工具、agent framework、低程式碼平台、雲端服務都在變。後輩很容易把「新」等同於「應該立刻重寫」，把「舊」等同於「不求長進」。實務現場不是這樣算帳的。舊系統不只是技術負債，也可能是收入、流程、合約、使用者習慣與監管要求的總和。
讀到這裡，我對「技術品味」的修正
好的技術品味，不是把最新名詞講得最順。它能把工具優點放回專案脈絡裡：誰維護？誰付錢？誰承擔失敗？誰需要與既有資料、流程、權限、監控、部署相容？侯捷說 MFC 主架構不能三天兩頭大變，今天讀起來像是在提醒我們：架構不是展示品，它是承諾。
04 / 技術出版責任，今天變成 prompt 與 AI 摘要責任
文章後半批評當時電腦書籍與翻譯品質。侯捷生氣的點不是文字潔癖，而是高階技術知識會經由書籍、雜誌、翻譯、BBS 擴散給新人；如果品質差，會讓入門者喪失正確認知。
這段在 AI 時代沒有變輕，反而變重。今天會誤導人的不只出版品，還包括 AI 摘要、教學文、prompt 範本、短影音、社群貼文、套件 README，以及自動生成的測試與文件。以前一本壞譯本可能坑一批讀者；現在一段看似合理的 AI 回答，可以在一天內被複製到十個工作流裡。
「多聽擇其善者而從之，多見而識之。」
後輩要學的不是懷疑一切，而是建立「判讀資料」的習慣：看作者是否實作過、看版本與日期、看反例、看錯誤勘誤、看社群批評、看文件是否能跑通。AI 可以幫我們讀得更多，但不能替我們承擔判斷品質的責任。
05 / 挫折感不是缺陷，而是學習路線沒有被照亮
最後一封來函談的是挫折：覺得自己悟性差、花別人兩三倍時間、和高手相比差很多。侯捷沒有把它包裝成雞湯。他承認天份存在，但把重點放回努力程度與長期性。他說自己不是電腦強人，也沒有什麼天份，只是中人之資。
這對後輩很重要。今天我們更容易被「展示型高手」壓垮：社群上有人一天做完 SaaS、有人一晚訓練 agent、有人一篇貼文列出十幾個工具。可是真正進入工作現場，能長期留下來的不是一次展示，而是反覆修補、回頭理解、維持品質、處理相容、扛起維運。
我讀這篇最大的安定感，是侯捷把「我比較慢」轉成「我還在排路線」。慢不是問題，亂才是問題。挫折不是問題，沒有回饋迴路才是問題。後輩需要的不是立刻變成高手，而是把每一次卡住變成可追蹤的索引卡：我卡在語言、工具、框架、系統、專案脈絡，還是資料品質？
06 / 讀完之後，我會留給自己的行動表
這篇文章如果只被讀成「基礎很重要」，就太可惜了。它可以轉成一張每週檢查表：我補了哪一層能力？留下了哪一份證據？
把目前常用工具拆成語言、IDE、framework、runtime、deploy、資料來源六類，標出最薄的一類，寫下本週要補的兩個問題。
挑一個常用框架，整理生命週期、擴充點與錯誤處理，做一份不依賴 tutorial 的重現筆記。
補一項系統基礎：OS、network、database、security、observability 任選其一，做出含實驗步驟與失敗紀錄的筆記。
最終筆記
我喜歡這篇，不是因為它讓人懷舊，而是因為它把 1990 年代的工具焦慮，翻譯成今天仍有效的工程倫理：分類要清楚，基礎要能回頭驗證，工具要放回專案現場，文字要對讀者負責，挫折要被整理成下一步。這就是我作為 IT 後輩能從侯捷身上帶走的東西。