文章目錄

41 個專案之後，我才搞懂什麼叫做「知識資產」

AI 讓開發速度提升十倍之後，最大的敵人不再是寫程式，而是遺忘。

作者：Mr. τ／風雲網通系統 | 標籤：知識工程 PCPiLOT SMB AI

「你有沒有一個機制，讓 AI 幫你掃描、萃取、歸檔過去寫過的好東西？」
我問過很多工程師。沒有人說有。

事件：29 次掃描，0 次成功

AI 助理出現之後，有一件事悄悄發生了。

開發速度變快了。快很多。以前一年做三個專案，後來一個月可以做三個。SPA、Python 串接、API 模組、診斷小工具……專案數量在我幾乎沒有意識到的情況下，突破了四十個。

然後，遺忘開始追上來。

「哪個專案有 OAuth 模組？」「上次那個 Ollama 串接，是在哪裡寫的？」「GPU 監控的邏輯，我記得優化過，但是在哪一個專案？」——這些問題開始頻繁出現。最大的敵人，不再是開發速度，而是自己累積的東西太多、太快、太散。

我試過用程式自動比對這 41 個專案的相似度，希望找出可以重用的部分。跑了 29 次，設計了各種比對邏輯，結果全部失敗。不是技術問題，是方向錯了——我一直在找「哪裡一樣」，而不是在想「什麼值得留下來」。

工程師寫工具，有一個慣性：從「發現問題」出發。程式碼有沒有重複？有沒有 bug？有沒有技術債？

但知識萃取需要的不是這個。開一個新案子的第一個問題，從來不是「我之前有沒有寫過類似的 bug」——而是「我之前有沒有解決過類似的需求」。

這是 PCPiLOT 工程日誌裡記下的一條教訓：
掃描工具應該對齊「開案時的需求」，而不是對齊「發現問題」。這兩個方向，工具架構完全不同。

說穿了就是：你需要的不是程式碼比對器，你需要的是架構解剖台。

我重新設計了 PCPiLOT 的專案解剖流程，分三個階段：

專案群組化
自動掃描目錄，排除實驗性的零散檔案，以「專案」為單位識別核心模組。不是每一個 .py 都值得被當成知識，這一步的工作是去蕪存菁。

主程式識別
不讓 LLM 逐行讀程式碼，而是請它扮演「架構師」：根據專案摘要，判斷哪個是 entry point、哪裡是核心邏輯。這一步讓 LLM 的準確率大幅提升，也省下大量 token。

雙層解剖
架構層：設計模式是什麼？技術選型的理由？哪些亮點值得繼承？
模組層：每個函式與類別打上標籤（UI / API / Auth / Pipeline），並標記「可複用」或「專案特定」。

現在，PCPiLOT 每個新案開始前，我都會打開自動生成的 L3_architecture_library.md。

程式碼是消耗品，設計模式才是資產。

這不是程式碼的複製貼上，這是設計模式的繼承。兩件事的本質完全不同：一個是搬磚，一個是繼承建築語言。

問自己這三個問題：

✔ 我知道自己寫過最好用的 Auth 模組在哪裡嗎？

✔ 新開案時，我是從「空白檔案」出發，還是從「SDK 框架」出發？

✔ 我有沒有讓 AI 幫我把過去的好設計，萃取成可以被下一個案子繼承的形式？

技術的積累，不在於你寫了多少行程式碼，而在於你留下了多少下一個案子開得起來的知識原子。

停止掃描，開始萃取。你的下一個 40 個專案，會因為這一次的系統化整理，變得輕鬆非常多。

作者：Mr. τ／風雲網通系統有限公司（PCPiLOT）
專注於 SMB 企業 AI 地端架構、知識工程與系統整合。