视角的提升 - Zong

这个月继续着 Vibe Coding ，使用“古法”编程只占到了不到 1% 。可以说是少之又少。

也想明白了一些事情，之前想着让 AI 做全链路 DevOps ，但是这似乎并不现实，抛开生成测试用例、生成对应的 E2E 测试脚本，就算 AI 能执行完全。

我做为提出需求的人，也就是用户方，我同样需要验收这个需求。当然了，就目前我并没有很深入的去实践测试这个角色的 AI 能力。

我更注重的是提出需求和验收需求。这也引出了为什么我会说我视角的提升。

不难发现从今年开始，我的视角才真正的转变成架构师，就算之前我开始慢慢接触后端，就算我开始负责一个项目，但是我的视角依然会有些空白的地方，因为接触后端的部分只是为了像 Java 那样去实现，并没有很深度的思考为什么这么做。好就用，没有根据场景权衡利弊。

但是现在不一样了，我沉浸在 Vibe Coding 中，享受着更高的视角来监督项目的发展。

从中我获得了产品经理的角色，虽然没那么专业，但是我会很主动的去思考项目应该如何、如何才会有好的体验以及 PRD 落地。

从中我获得了架构师的角色，从前我设计前端低代码引擎的架构、现在我设计 AI 应用的架构，从前端转向整个项目的架构设计（前端、后端，当然现在这个项目后端为主），将主流的、适合项目的架构模式应用到项目，和我产品这个角色进行权衡取舍，从而让项目更贴近目标和用户群体。

这是我很真实且明显的感受，我能够从更高的视角来看待问题和解决问题。虽然项目主要还是以 TypeScript 作为开发语言来运行，但是我并不惧怕 Java 、 Python 等其他语言，可以通过 AI 的力量让我驾驭他们，毕竟语言之间是互通的。

为什么会在开头还提到“古法”编程，是因为在一些特定的问题场景，逻辑的问题暴露的不是那么明显的时候（引入架构模式同样会带来副作用、我能接受它的利 对项目好 ，当然也要接住它的弊 调试难、开发难 ，毕竟不是银弹）， AI 并不能很好的找到问题的根源（当然也有可能是我用的模型烂），这时候需要人工的介入很必要，利用 Vibe Coding + “古法”的调试技术同样可以很好的复现问题场景，从而解决问题。

我之所以会这么说是因为 Vibe Coding 确实释放了很多以前的编程时间，从而让我的视角能够聚焦更多的事情、让我能够更全面的审视项目。

其实这样的好处确实还不止这一个，传统项目中的多种角色之间产生的沟通损耗，在当前项目中大大减少，几乎可以说是没有了。

另外我总结了一点经验，关于文档的落地，其实不止于 PRD ，还需要我们架构师常提的 4+1 视图，从产品的角度描述项目应该如何，从架构师角度描述产品具体如何，从而让 AI 更好的理解项目最终如何。这也是能够让你更好的驾驭 Vibe Coding 成果的基础，同样在这个过程中你会跟深刻的理解这一切。