我是一粟，一个写了 6 年 Web 全栈的后端工程师。React、Node、Python、微服务、CI/CD，该踩的坑基本都踩过一遍。去年拿了腾讯、字节、京东三家的大模型方向 offer，最后选了现在这条做 AI 应用的路。
说实话，做出转型决定的那天，我以为最难的部分会是「学新东西」——Transformer 原理、提示词工程、RAG、Agent 框架，随便拎一个出来都是一座山。
结果第一周打完，我发现我错了。
新东西不难。真正让我难受的，是我带了 6 年的旧习惯，在新领域里到处碰壁。
今天这篇不讲技术干货，讲讲一个后端老兵转型第一周，被迫放下的四样东西。如果你也在考虑转 AI 方向，这篇可能帮你省掉我这一周的痛苦。
放下的第一样：确定性思维
做后端久了，人会形成一种信仰：系统是确定的。
接口要么返回 200，要么返回 500。数据库要么查到，要么查不到。代码审查时我们讨论的是「这个边界条件处理了没有」，而不是「这个函数今天心情怎么样」。
然后我调了大模型。
同一个请求，第一次返回 JSON，第二次返回「好的，以下是您要的 JSON：」然后才给我 JSON，第三次直接告诉我它做不到。
我的第一反应是：这玩意儿有 bug。
我花了整整一个下午去「排查」这个问题——检查请求参数、对比请求体、翻文档——最后在一个前辈的提醒下才意识到：这不是 bug，这就是它的工作方式。大模型的输出是概率性的，不是「不稳定」，是「本来就稳定不下来」。
那一刻我的后端直觉崩了一小块。
后来我慢慢想明白了：做传统后端，你的工作是消灭不确定性；做 AI 应用，你的工作是和不确定性共处。模型给你的永远是一个「大概齐」的答案，你的工程价值体现在：怎么用护栏、重试、校验、降级，把这个「大概齐」变成用户能接受的「足够好」。
这不是技术的变化，是世界观的挪移。第一周最大的震荡，来自这里。
放下的第二样：「先设计完美架构，再动手」
后端做久了会有职业病：动手前先画架构图。
数据库怎么分表、接口怎么分层、异常怎么统一处理、以后怎么扩展——不把这些想清楚，一行代码都不愿意写。这个习惯在传统开发里是美德，六年里它救过我无数次。
第一周我准备搭我的第一个 Agent，很自然地打开了画图工具，准备先设计一套「完美的 Agent 架构」：消息怎么流转、工具怎么注册、上下文怎么管理……
画了半天，我发现一个尴尬的问题：我不知道该画什么。
因为我根本不知道这个 Agent 跑起来会是什么表现。提示词怎么写才有效？工具调用的失败率有多高？上下文多长会开始「失忆」？这些答案没有一个能靠设计推出来，只能靠跑出来。
AI 应用开发的迭代单位，不是「版本」，是「提示词的某一次修改」。你改一句话，系统的行为就整个变了。在这种开发模式下，花三天设计的完美架构，可能跑一次就被推翻。
所以我放弃了画图，用两百行代码先跑了一个能动的最小循环（就是上一篇分享的那个）。跑通之后再看，哪些地方真的需要设计，哪些地方纯属我自己的强迫症。
不是架构不重要了，而是架构的来源变了：从「提前设计」变成「从实际运行的血泪里长出来」。
顺便说一句，这个转变对老后端其实特别痛苦——相当于承认你过去最引以为豪的能力，在新领域里暂时派不上用场。
放下的第三样：对 100% 正确率的执念
这个是我劝自己劝得最辛苦的。
上线一个接口，正确率必须 100%，这是刻在后端骨头里的东西。测试覆盖率不够不敢发，边界条件没处理不敢发。
但第一周搭 Agent 的时候，我遇到了一个现实问题：模型完成任务的正确率，大概在 85% 左右。剩下 15% 的情况，它会自信满满地给你一个错误答案。
我的第一反应是：这玩意儿不能上线。
但后来我算了笔账。我做的那个场景（自动化数据整理），人工处理一遍要 40 分钟，模型处理只要 1 分钟，剩下的 15% 错误，用一个校验层拦住打回人工，人工只处理被拦下来的部分。
整体算下来，效率还是提升了 20 倍以上，而且错误被拦在了用户看到之前。
那一刻我意识到，「能不能上线」的判断标准变了。传统后端问的是「正确率够不够高」；AI 应用问的是「错了之后的兜底成本，能不能覆盖它带来的效率收益」。
85% 的正确率 + 完善的兜底，很多场景下完胜 100% 正确率但昂贵的纯人工。
这个思维不开，你做 AI 应用会处处觉得「不能用」；这个思维一开，满地都是可以落地的场景。
放下的第四样：其实没什么可放下的（这是好消息）
最后说个反转，给同样在考虑转型的后端同学一点信心。
第一周结束我做复盘，列了一下这一周实际用到的东西：
- 调 API？就是 HTTP 请求，我用
requests裸写，比以前调的第三方支付接口简单多了 - 组织上下文、管理会话状态？不就是状态管理吗，Web 后端干了很多年
- 设计护栏和兜底逻辑？就是异常处理和降级方案，老本行
- 部署、监控、控制成本？后端基本功
真正「全新」的东西，可能只占 20%——提示词的写法、模型行为的直觉、一些领域黑话。剩下的 80%，全是工程能力的迁移。
所以「放下旧东西」这个说法其实不精确。准确的说法是：放下旧习惯，但旧能力全都在。
被放下的确定性思维、完美架构执念、100% 正确率信仰，说到底都是「外壳」；底下那六年的工程素养，才是转型时真正带着走的行李。
这也是我敢接 30 天挑战的底气——新东西学得会，旧能力用得上，唯一要过的坎，是自己脑子里那几道弯。
30 天怎么走？我给自己排了四步：
30 天四步走（4 周 4 个台阶）：
| 阶段 | 目标 | 对应成果 |
|---|---|---|
| 第 1 周 · 打地基 | 不碰框架，手写一个能跑的最小 Agent 循环 | 上一篇那个 200 行架构 |
| 第 2 周 · 装记忆 | 短期上下文 + 长期记忆，解决多轮任务「失忆」 | 下一篇实操 |
| 第 3 周 · 接工具 | 工具调用、RAG 检索，让 Agent 真能干活 | 会调 API 干活的 Agent |
| 第 4 周 · 上生产 | 护栏、成本控制、部署上线 | 第一个能跑通的小应用 |
每一天我都会记录实操、踩坑、代码和思考，你可以直接抄着我的路径走，把我踩过的坑绕过去。
写在最后
第一周最大的感悟，浓缩成一句话：
转型的瓶颈从来不在知识的多少，而在思维方式的松绑。
知识可以查文档、看教程、抄作业；但「确定性思维」「完美主义」这些你赖以为生多年的东西，没有一篇文章能帮你放下，只能靠你自己跑第一个 Agent、翻第一次车、算第一次兜底账，在具体的挫败里一点点松开。
如果你也是后端工程师，也在考虑往 AI 应用方向转，我正在进行的「30 天从零学 Agent」挑战会把每一天的实操、踩坑、代码和思考都记录下来，你可以直接抄着我的路径走，把我踩过的坑绕过去。
想跟我一起学习进步的，微信扫码添加好友 一起交流学习，我把整理的 30 天学习资源清单分享给你～
