AI焦虑？不存在的，我们服务端研发只是换了种活法。
大家好，我是十三！
最近有个很奇妙的感觉，我发现自己越来越像一个“产品经理”。我的团队成员有点特殊：Gemini、Claude、豆包、通义灵码... 我每天的工作，就是给他们“提需求”、“审代码”，而我自己的精力，则更多地放在了“做什么”（What）和“为什么做”（Why）上。
这，可能就是AI时代服务端研发的新常态。
我的新团队：一群效率惊人但没有“品味”的AI实习生
得承认，我的这群“AI实习生”效率高得吓人。
就在上周，我准备搞个自己的博客，把它做成一个独立的服务。搁在以前，从设计API、建表、编写业务逻辑到部署，没个一两周根本下不来。
但现在呢？我的工作流变成了这样：
- 我：花半小时写一份清晰的 Markdown 文档，定义好 API 接口、数据库表结构和核心的转换逻辑。
- AI团队：
Cursor读取了我的文档，几分钟内就生成了符合go-zero规范的项目骨架、gRPC 定义和基础的 CRUD 代码。 - 我：提出需求：“为这个接口编写单元测试，覆盖正常和异常场景。”
- AI团队：
Cursor迅速补上了对应的测试用例。
整个过程下来，核心功能的实现从“天”缩短到了“小时”。这效率，真的让人头疼，尤其是对我这种老兵来说，感觉自己这么多年的手速算是白练了。
但冷静下来，我发现了这群AI实习生的“致命缺陷”：他们快，但没有“品味” 。
他们生成的代码能跑，但可能存在一些“坏味道”：
- `` 变量名可能是
data,res,result这种万金油。 - `` 错误处理就是简单的
if err != nil { return err }，缺乏上下文，对调试极不友好。 - `` 代码逻辑直来直去，不懂得适当的封装和抽象。
- `` 不同对话生成的代码风格不一致。
- `` Gemini甚至会偷懒！
就像下面这段AI生成的代码：
// AI generated this, it works, so don't touch it. For now.
// Post is a struct for blog posts.
func GetPostBySlug(slug_string string) (*Post, error) {
// ... a bunch of database query logic ...
// ... to find a post by its slug ...
var post Post
return &post, nil
}
能用吗？能用。但优雅吗？离“作品”还差得远。
他们是出色的工具人，是完美的“实现者”，但他们永远无法替代那个定义问题、把控质量、拥有“技术品味”的人。
我的新角色：从“代码实现者”到“技术决策者”
于是，我发现我的角色彻底变了。我不再是那个埋头吭哧吭哧砌砖的工人，而是成了那个审图纸、定方案、最后拍板验收的“技术主管”或者说“产品经理”。
我的核心工作，从写代码（How），转向了三个更上游的环节：
1. 定义问题（What）
工作的起点不再是接到一个清晰的需求文档，而是主动去发现、分析、并用AI能理解的语言去清晰地定义一个技术问题。
我不再关心 for 循环怎么写，而是关心 我们为什么要在这里写一个循环？它想解决的核心问题是什么？有没有更高性能、更优雅的替代方案？
2. 架构设计（Why）
工作的核心不再是实现某个模块，而是决策整个系统的蓝图。
AI可以告诉我，实现一个缓存可以用 Redis，也可以用本地缓存。但它无法告诉我：
- 在这个业务场景下，数据一致性和性能哪个更重要？
- 考虑到未来的流量增长，我们的缓存策略应该如何设计才能避免雪崩？
- 这个技术选型，能不能撑得起我们未来三年的业务发展？
这些充满权衡（Trade-offs）的决策，才是一个资深工程师真正的价值所在。
3. 结果验收（Quality）
工作的终点不再是“代码能跑”，而是对AI生成物的质量负总责。
我花在 Code Review 上的时间甚至超过了写代码本身。我要像一个严苛的“代码洁癖”患者，去审查AI提交的每一行代码，为它注入“灵魂”：
- 这个变量名能更清晰吗？
- 这里的错误处理能提供更多上下文吗？
- 这段逻辑是不是可以抽象成一个独立的函数？
如何当好一个“AI产品经理”？
既然角色变了，我们的能力模型也得跟着升级。想领导好这支特殊的“AI团队”，有三项能力至关重要：
1. 学会写“PRD” -> 精通 Prompt Engineering
给AI提需求，就像给产品经理写需求文档（PRD）。你写得越清晰、越具体，拿到的产出质量就越高。
以前我可能会说：
"写个函数，把文件上传到OSS"
现在我会说：
"写一个Go函数
UploadFileToOSS。它接收bucketName,objectKey,fileContent []byte三个参数。使用aliyun-oss-go-sdk。必须包含完整的错误处理，使用fmt.Errorf包装关键错误信息。在遇到网络抖动时，加入指数退避的重试逻辑，最多3次。成功后返回文件在OSS的URL。"
你看，后者才是一个合格的“技术需求”，AI才能准确地理解并执行。
2. 培养“技术审美” -> 锤炼 Code Review 能力
AI 会放大我们的能力，也会放大我们的缺陷。如果我们自己对“好代码”没有概念，就无法判断AI生成物的好坏，最终只会生产出一堆能跑的“数字垃圾”。
把AI节省下来的时间，去阅读优秀开源项目的源码（比如 go-zero），去学习设计模式，去思考代码背后的架构哲学。你的“技术审美”越高，你的“AI团队”产出的质量就越高。
3. 绘制“产品路线图” -> 建立系统化思维
跳出单个功能点，从整体视角规划你的“AI团队”要去构建什么。我发现，我花在 README.md 和设计文档上的时间越来越多了。
在动工前，先有一个清晰的 Roadmap 和 Checklist。谋定而后动，这不仅是好的工程习惯，更是领导AI团队高效工作的必备前提。
写在最后
聊了这么多，其实就想说一件事：
AI没有抢走我们的工作，它只是给我们每个人都发了一份“晋升”通知，邀请我们从“码农” 晋升为“技术产品经理” 。
焦虑毫无意义，恐慌大可不必。迎接新的角色，领导你的AI团队去创造更大的价值，这才是属于我们每个服务端研发的，最好的时代机遇。
** 一起聊聊：**
- 你在工作中是怎么使用AI的？它改变了你的工作流吗？
- 对于“技术品味”，你有什么自己的看法和标准？
- 你认为未来几年，我们服务端研发还应该培养哪些“AI无法替代”的核心能力？
如果这篇文章对你有帮助，请：
- 点个赞：让更多技术同学看到这次的分享
- 转发分享：相信做架构的朋友都会很感兴趣
- 留言讨论：分享你的想法，一起交流进步
- 收藏备用：方便日后回顾，说不定哪天就用上了
关于十三Tech
资深服务端研发工程师，AI编程实践者。
希望能和大家一起写出更优雅的代码！
联系方式：569893882@qq.com
GitHub：@TriTechAI
微信：TriTechAI（备注：十三Tech）
本文同步自掘金
如果发现内容有误或需要更新，请访问掘金原文进行查看。
如果这类内容对你有帮助
这里放了一个阿里云 AIGC 活动入口。如果你本来就有相关需求，可以顺手了解；如果产生推广收益，我会优先用于支付服务器、域名和网站维护费用。