從前端到 Harness Engineering：我給自己定的三年方向
先承認一件事
我對自己有個還算誠實的判斷：實現能力強於系統設計能力。給我清晰的邊界，我能很快做出可用的東西；但讓我從零設計一個高複雜度、重治理的平台，我會力不從心。
這個元認知很重要——它直接決定了我該往哪走、不該往哪走。我不適合一上來就挑戰大平台架構，更適合邊界清晰的小工具與自動化工作流，在做的過程中慢慢補系統設計的短板。
主棧是 Vue，但我不想停在「寫界面」
我的主棧是 Vue 3 / TypeScript，往 Next.js / NestJS 延伸做全棧。這套技能能養活我，但有個問題：它的天花板正在被 AI 壓低。
會寫 CRUD 界面的人越來越多，AI 輔助下中小型全棧系統的實現門檻也在快速下降。如果我的護城河只是"會用 Vue 寫頁面"，那這條河每年都在變窄。
所以問題不是"我會什麼"，而是"三年後什麼還稀缺"。
押注：Harness Engineering
我的答案是 Harness Engineering——為 AI Agent 設計它運行的"框架"：
- 它能調用哪些工具、不能碰什麼（能力邊界）；
- 它跨會話、跨機器怎麼記住事情（記憶）；
- 多個 Agent 之間怎麼協作、怎麼不打架（協作協議）；
- 怎麼驗證它真的做對了，而不是看起來做對了（可驗證性）。
為什麼押這個？
- 它稀缺。模型本身有大廠在卷，但"怎麼把模型裝進一個可靠、可審計、能協作的殼子裏"——這件事遠沒被解決，工程含量極高。
- 它吃工程能力，不吃天才。這恰好是我的強項區：把一個模糊的協作問題，拆成清晰邊界的小模塊，逐個驗證、逐步演進。
- 它有複利。每搭一層 harness，下一個 Agent 任務就更省力。這和"一次性實現一個需求"完全不同。
我已經在做的事
方向不是空想，是有抓手的。過去幾個月我把它落在兩個具體項目上：
- nestwork：用 Git 給多機器、多 Agent 同步一個會成長的大腦——這就是"記憶"和"協作協議"兩層。
- cheat-on-content：一套會校準的內容運營工作流，核心是"盲預測 + rubric 迭代"——這是"可驗證性"在內容領域的落地。
它們看起來一個偏工具、一個偏內容，但內核是同一件事：給一個不完全可控的智能體，套上一個可靠、可演進、可審計的框架。
給同處轉型期的人的三條具體建議
如果你也是個"實現強、設計弱"的工程師，想往 AI Agent 方向走，我自己在用的三條：
- 不要追大平台，先做邊界清晰的小工具。 在小工具裏練系統設計，代價低、反饋快。
- 每個項目都標出「可驗證性」和「自動化槓桿」。 不是為了交付一次，是為了讓它能被複用、被驗證、長出複利。
- 把方向寫下來，並定期打臉。 我把"三年方向"寫成文檔，每隔一段時間回看：哪些判斷錯了？這比悶頭乾重要得多。
這篇不是結論，是一個還在路上的人的方向標註。三年後回看，大概率有些判斷會被打臉——但有方向地犯錯，比沒方向地忙碌，強太多了。