企业官网建设流程全解析

近期笔者因为工作原因，开始大规模使用Vibe Coding的方式来编写后端项目。说实话，笔者目前大概99%的代码都是通过Vibe Coding生成的，已经基本不手写代码了。

在先前的文章里，笔者也聊到了用Vibe Coding写前端原型的经验，而这篇文章则聚焦后端侧，也是更加偏重于业务工程的研发场景，今天这篇文章，笔者让AI列举了一些后端项目Vibe Coding场景下，各位开发者都比较关心的问题，然后做一些简练的回答。

一、项目代码量膨胀后，AI的上下文管理怎么做？

除去模型本身能力来看，一套好的项目架构，好的代码结构化的展现，能够让AI更容易理解，在不同上下文切换的时候，能够更快速知道怎么去改某个内容。所以一个action是，在项目代码量不膨胀的时候，做好架构设计，预防这类问题。

当然如果项目本身已经很臃肿了，这个时候就需要遵循「好记性不如烂笔头」的原则，多沉淀一些memory，对于具备业务上下文的逻辑去多打一些注释，日常多搞一些脚本或者skill，复刻自己的研发习惯。

二、怎么减少AI生成代码的坑点，比如并发或者DB访问类的？

后端开发场景下，一个项目可能是多人开发，如果AI不知道哪块实现是best-practice的，那就容易踩坑。所以这里的重点是，自己需要判断怎样的实现是best-practice。

并发类的，以笔者常用的Golang为例，可能存在部分地方直接go func，也有可能某些地方通过某些并发库起goroutine，封装一些异常处理，这样会更优雅一点。在某些http框架中，随意go func可能带进一些cancel掉的ctx，这也可能是坑，解决方法就需要独立的ctx复制各类value然后再带进去。

DB访问类的，比如Update某个Record，AI可能从最小实现原则出发，做全量record修改，但某些业务场景下可能只需要改某几个字段值，这种情况最好的处理方式就是单独抽一个改这些字段值的函数，体现其业务属性。如果不告诉AI的话，AI也不会立刻明白

所以很多坑点，其实都还是要经过自己梳理一遍，然后再告诉AI怎么做，否则当年自己踩的坑，AI也会再踩一遍。

三、AI写的代码出问题时，怎么提升返工效率，做好harness？

这个和上一个问题有关联，但更加关注出了一次问题之后，怎么避免第二次。自己写的代码，出了问题通常能快速定位，因为你知道自己当时是怎么想的，代码逻辑的来龙去脉都在脑子里。但AI生成的代码不一样，你虽然review过，但对它的"思维方式"并不熟悉。出了问题之后，你往往需要先花时间理解AI为什么这么写，然后才能判断是逻辑错误还是边界条件没考虑到。所以有几个个好的办法：

• 要求AI做计划和确认：沉淀一个rule，实现代码之前，需要强制让AI给你代码实现计划，做问题澄清和确认，然后执行。
• 要求AI写注释：在rules里明确要求AI对关键逻辑写清楚注释，说明"为什么这么做"而不只是"做了什么"，这样CR的时候能快速理解代码意图。
• 要求AI生成单元测试：是一个可选项，更是为了在出问题时有一个回归测试的基础，修改bug之后跑一遍单测，确认没有引入新问题。单测的内容尽量简洁，让自己快速看懂即可。
• 建立CR的CheckList：每次实现完之后，需要检查是否遵循自己的best-practice。既然代码的负责人是自己，那么实现的效果就需要遵循自己的原则。

通过以上一些措施，就能够让AI生成的代码更加符合自己的taste，做好harness。

四、作为Old School程序员，如何应对Vibe Coding时代带来的焦虑？

这个问题笔者想认真聊一下，因为它比任何技术问题都更真实：传统Old School程序员，怎么应对AI时代，AI可以代替传统程序员的这个事实。笔者的答案是，保持学习，坚持判断。

AI能够代替Old School程序员的是编码本身，但是一套程序怎么做最优雅的设计，怎么反映业务，怎么满足共识，这些也都是技术研发的一部分，并且都是依赖自己的判断，是AI代替不了的。所以一方面，对于AI Vibe Coding，需要逐步适应逐步学习，这样以后能够减少手工编码，腾出更多时间；另一方面，需要把更多精力放在技术架构设计上，提升自己在技术上的判断力，这样才能够和AI做到更加效率的协作。

说白了，可以把AI当做一个智商跟知识面顶级，但对业务共识不会深刻了解的INTP，作为Vibe Coding开发者需要做的，一是给AI足够的业务上下文，让AI的思路和判断逐渐和你一致，从而发挥其最大潜力；二是把控好交付效果，把更多思考留到怎么样让Vibe Coding出来的产品落地到更多工作场景上，这样才能实现工作层面的AI提效。