从前端到 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 方向走，我自己在用的三条：
- 不要追大平台，先做边界清晰的小工具。 在小工具里练系统设计，代价低、反馈快。
- 每个项目都标出「可验证性」和「自动化杠杆」。 不是为了交付一次，是为了让它能被复用、被验证、长出复利。
- 把方向写下来，并定期打脸。 我把"三年方向"写成文档，每隔一段时间回看：哪些判断错了？这比闷头干重要得多。
这篇不是结论，是一个还在路上的人的方向标注。三年后回看，大概率有些判断会被打脸——但有方向地犯错，比没方向地忙碌，强太多了。