> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2026/w38-everything-can-be-engineered.md). # W38-萬物皆可工程化 最近做的幾件事，讓我越來越強烈地感到，AI 正在改變我處理複雜問題的方式。 以前，一個問題複雜到一定程度，我通常只能投入更多注意力。記住配置，維護文檔，反覆解釋背景，出錯後再排查。即使知道可以寫程序解決，也未必值得為它搭建和維護一套系統。 現在，我更願意把它變成一個工程。 把事實和規則寫下來，把重複操作交給程序，為變化增加驗證，保留歷史和回退路徑。以後遇到新需求，就在這個基礎上繼續擴展。 工程化的方法早就存在。**AI 降低了實施和維護這些方法的成本，讓許多過去不值得做的工程，現在值得做了。** ## 從代理配置到一個可以維護的工程 第一個例子是我的 Mac 代理配置。 最初，這只是讓幾個應用正常聯網的問題。隨著需求增加，它逐漸涉及不同網站的分流、公司網絡直連、命令行與桌面應用的環境差異，以及配置更新和設備遷移。 每次單獨處理都不算難。但這些規則疊加以後，很難僅靠記憶維護。今天解決一個問題，過一段時間，可能已經忘了為什麼要這樣配置，也不知道下一次修改會影響哪裡。 我後來把這套方案整理進了一個私有倉庫。 倉庫裡有配置模板、分流規則、生成和校驗腳本，也有恢復、維護和排障手冊。修改之前可以預覽，安裝之前可以備份，出了問題有回滾路徑。遷移到另一臺 Mac，也有明確的步驟和驗收要求。 我已經在另一臺電腦上完成了實際遷移，驗證了這套方案的有效性和效率。原來需要逐項排查、手工配置的過程，現在可以按照倉庫裡的規則和流程完成。這個工程也因此有了經過實測的複用能力。 對我而言，變化在於，我終於能把這套配置當作一個長期維護的系統來處理。增加一個應用或調整一條規則時，有地方修改，有方法驗證，也能查清過去做過什麼。 **複雜度仍然存在，但它有了明確的存放位置和處理方式。** ## Agent Team 本身也需要工程化 第二個例子，是我運行了一段時間的 Agent Team。 一個人工作時，如果只用一兩個 Agent，直接對話、分配任務，通常就夠了。 但當我需要多個 Agent 分角色處理不同的事情，並讓它們自行組織、協作解決複雜問題時，就需要一套明確的運行規則。 誰來拆解任務，誰負責實現，誰負責評審，任務如何交接，遇到問題由誰接手，都需要事先安排。給團隊或工程增加自動化任務後，還要管理這些工作如何觸發和運行。比如自動查找代碼變更並做 PR review，或者在集成倉庫合入後，自動將對應內容投影到各個子倉庫。 這些需求逐漸超出了手工維護幾份提示詞的範圍。於是，我把 Agent 的角色配置、協作規則和自動化任務整理成了一個可以管理、運維和持續擴展的工程。 角色職責、協作規則和運行策略都保存在倉庫中。倉庫聲明團隊應該是什麼狀態，同步工具負責檢查它與運行狀態之間的差異。修改可以先預覽，應用後再核對是否一致。 這讓我可以持續調整團隊，而不必每次都重新拼裝一遍。 **一次有效的協作經驗，可以變成所有相關角色共同遵守的規則。** 一次失敗暴露的問題，也可以進入配置和驗證流程，成為下一次工作的基礎。 我開始把 Agent Team 當作一個需要運維和迭代的系統。模型能力是其中一部分，角色邊界、任務交接和驗收方式同樣需要持續改進。 ## 把團隊的工作上下文放進同一個版本 第三個例子，是正在進行中的報稅 MVP。 我們在 BFO 的集成倉庫裡推進這個項目。產品與架構文檔、接口契約、驗收規格、前後端代碼和 Agent 工具，都進入同一個集成倉庫，形成共同的版本基線。 **我想實現一種文檔即代碼、代碼即產品的工作方式。** 產品規則發生變化時，相關文檔、契約、實現和驗收標準可以一起修改、一起評審。我們能夠回到某個版本，查看當時的要求是什麼、代碼如何實現、用什麼標準判斷它做對了。 過去，這些上下文往往散落在文檔、聊天記錄和不同人的記憶裡。跨角色協作時，需要反覆搬運和解釋。產品講一次，研發理解一次，測試再還原一次。需求變化之後，還要重新確認每個人拿到的是不是同一個版本。 集成倉庫讓這些工作有了共同的依據。 它不能消除人與人之間的理解差異，但可以減少尋找資料、核對版本和重複解釋背景的成本。討論可以圍繞具體變更展開，結論也有明確的地方沉澱。 AI 同樣可以讀取這些材料。接到一個任務後，它能夠沿著需求、契約、實現和測試查找上下文，而不必完全依賴當前對話裡臨時提供的信息。 這個 MVP 還在進行中，長期收益尚待驗證。但我尤其看重後續的日常迭代。只要這些資產隨著產品一起維護，每一輪工作就有機會為下一輪留下更完整的基礎。 **以前做過的工作，能夠繼續降低未來工作的成本。** ## 財務管理中的事實與表達 第四個例子還沒有實現，是我計劃中的個人財務與投資管理工程。 目前，我在 Google Drive 中維護家庭財務相關的每週、每月和每季度審查材料，也在持續做市場觀察。 我準備把這些工作逐步整理進一個私有工程。包括家庭財務的基本情況、投資標的、投資渠道、市場觀察，以及定期審查的記錄。 **這裡最吸引我的，是可以把事實源和表達方式分開。** 過去，當我決定用表格、文檔還是 PPT 記錄信息時，往往已經在考慮它最終應該長什麼樣。數據的組織方式，很容易被展示工具決定。 以後，我希望先維護一份有來源、有時間、有版本的基礎記錄，再根據具體問題生成表達。 想看資產結構，就生成圖表。想做月度審查，就生成報告。想了解某項變化，就沿著歷史記錄追問。不同的呈現都來自同一份基礎數據，也都能回到它核對。 這樣，我就不需要為了每一種表達重新整理一遍事實。圖表和報告可以隨時生成、調整，長期維護的重點則是底層信息是否準確、完整、及時。 這也是我理解工程化的一次變化。工程裡可以承載事實、規則和決策記錄，再按需要生成供人閱讀和使用的界面。 ## AI 讓工程化的投入更容易收回來 這幾個案例有一個共同點。它們都積累了一定複雜度，也都需要持續維護。 過去，我未必願意為它們建立工程。寫腳本、補文檔、做驗證、維護工具，都需要投入。很多個人需求規模太小，收益不足以覆蓋成本，最後只能繼續手工處理。 AI 降低了這筆投入。 當整理配置、編寫腳本、補充測試和維護文檔變得更便宜時，我願意用工程方法處理的問題就更多了。代理配置、Agent 協作、團隊工作上下文，乃至家庭財務，都開始進入這個範圍。 **可靠性仍然需要具體機制支撐。** 事實要核對，變更要驗證，失敗要能被發現，必要時要能回退。AI 可以幫助建立和維護這些機制，但不能替代它們。 有了這些基礎，我才更有把握繼續增加能力。**系統能處理的問題變多，也不必要求我按同樣的比例增加記憶和注意力。** 我現在有一個越來越清晰的判斷，萬物皆可工程化。 更準確地說，**只要一個問題中有可以明確描述、計算和驗證的部分，我就有機會把它組織成一個可以持續維護的工程。** 判斷和取捨仍然由人承擔，但圍繞它們的信息整理、執行和反饋，可以不斷改善。 以前面對複雜問題，我首先想到要投入多少精力。現在，我會先想，能不能為它建立一個以後還可以繼續生長的系統。