2025 技术复盘：穿越 AI 焦虑，进化为“AI 全栈”

一、被推迟的复盘，与被加速的时间

连续几年没写年终总结，理由每次都很充分：工期紧、心力有限、想找个完整的周末认真梳理。结果一拖再拖，拖过元旦，拖过春节，等到重新想起这件事时，新的一年已经铺开，于是顺理成章地告诉自己“明年一定”。这样的循环重复了几轮之后，我意识到问题不在于时间，而在于缺少一个强制沉淀的契机。

人到中年，对时间的感知会发生变化：主观上越来越快，记忆却越来越模糊。很多当时以为会刻骨铭心的节点，几年后只剩下一个轮廓。技术人的年度复盘尤其如此——如果不写下来，一年里那些真正改变工作方式的转折点，很快就会被下一波需求淹没。趁着 2025 年还没完全过去，感受仍然新鲜，这次必须动笔。

而 2025 年最值得复盘的变量，毫无疑问是 AI。

二、从“聪明的补全”到“项目级理解”

我接触 AI 编程工具不算晚。最初阶段的体验可以用一句话概括：一个比较聪明的代码补全器。它能帮我少敲几行样板代码，但逻辑主线仍由我把控——变量怎么设计、模块怎么切分、异常怎么兜底，全在我脑子里。工具的价值是线性的，省下的是击键时间。

到了 2025 年，能力边界明显外移。几个变化让我印象很深：

其一，项目级上下文理解。 早期的补全只看当前文件甚至当前几行，而现在智能编程工具能够读取整个代码仓库的结构，理解模块之间的调用关系，进而完成跨文件的重构。面对一段历史遗留的复杂代码，它可以给出分层的改造建议，而不是机械替换。

其二，模糊需求的落地能力。 把一个描述得并不精确的业务需求交给它，它能给出一个“有模有样”的实现骨架，包含接口定义、数据流转和基础错误处理。虽然细节仍需人工校正，但起点从零变成了六十分。

其三，缺陷定位的降维打击。 这是最让我“破防”的一点。以往排查一个报错，习惯动作是搜索、翻技术社区、读源码，半天起步。现在把堆栈日志和相关代码片段交给 AI，通常几秒内就能指出问题所在、给出修改方案，甚至直接产出可验证的补丁。

多年积累的、一度引以为傲的“编程经验”——对 API 的熟练度、快速定位缺陷的直觉、环境配置的肌肉记忆——在这些能力面前，确实显得脆弱。这不是自我贬低，而是必须承认的事实：经验中可被模式化的部分，正在被快速商品化。

三、工作流程的悄然异化

能力提升的另一面，是习惯的变形。我复盘了自己这一年的操作路径，发现已经形成了几条近乎机械的“肌肉记忆”：

路径一：写注释 → 等待补全 → 按 Tab
路径二：描述需求 → 生成代码 → Accept All
路径三：运行报错 → 复制日志 → 粘贴给对话框

第一条路径的问题在于，哪怕脑子里清楚下一行该写什么，手指也会下意识停顿，等待那行灰色建议浮现。表面上效率提升了，实际上主动思考被替换成了被动筛选。

第二条路径更危险。“能跑就行”是一种极具欺骗性的满足感——代码通过了编译和冒烟测试，但实现细节没被认真读过。等到线上出现边界条件问题时，作者本人对自己的代码是陌生的。

第三条路径则直接跳过了分析环节。遇到异常的第一反应不再是读堆栈、看调用链、缩小复现范围，而是把日志丢出去等答案。短期看是加速，长期看是放弃了最重要的诊断能力训练。

这三条路径共同指向一个风险：工具在增强产出的同时，可能在削弱能力。 就像长期依赖导航会退化方向感，长期依赖生成会退化设计感。焦虑的来源不是“AI 会不会取代我”，而是“我是否正在主动交出那些构成竞争力的底层能力”。

四、重新定义“AI 全栈”

面对这种局面，消极抵制没有意义，盲目拥抱同样危险。我给自己定的方向是成为“AI 全栈”——不是指什么都懂一点，而是指在 AI 参与的完整交付链条上，每一环都具备判断力和掌控力。具体拆成四个层次：

第一层：问题建模能力。 AI 擅长在给定问题下产出方案，但“把模糊业务转化为可计算问题”这一步仍然高度依赖人。需求拆解、边界界定、约束识别，这些决定了后续所有生成内容的上限。输入质量决定输出质量，这一层不能外包。

第二层：人机协作规范。 把 AI 当作团队成员而非自动售货机。具体做法包括：为生成代码设定明确的验收标准；要求产出附带设计说明与复杂度分析；对关键路径代码坚持逐行审阅；把“生成—审阅—测试”固化为流程而非可选项。协作的关键不是速度，而是可追溯性。

第三层：系统设计与取舍。 单个函数可以由 AI 写，但模块边界怎么划、状态放在哪里、一致性如何保证、失败如何降级，这些架构层面的决策需要对业务和运行环境的整体理解。AI 可以提供候选方案，但取舍责任在人。

第四层：验证与运维闭环。 生成代码的真正成本在验证。建立完善的自动化测试、可观测性指标和灰度发布机制，才能让“快速生成”不至于演变为“快速埋雷”。这一层恰恰是很多追求提效的团队最容易忽略的部分。

五、可落地的几条实践

复盘的价值在于转化为行动。以下是我在 2025 年下半年开始执行、并准备延续下去的几条做法：

1. 保留“手写时间”。 每天留出固定时段，不开启任何辅助，独立完成核心逻辑。目的是维持设计与调试的“手感”，避免能力单向退化。
2. 建立提示词与产出的对应档案。 对重要模块，记录需求描述、生成结果、人工修改点及原因。这份档案本身就是团队的隐性知识资产。
3. 把审阅成本显性化。 在排期时明确为“审阅 AI 产出”预留工时，而不是默认它零成本。凡是跳过审阅直接合并的代码，视为技术债登记。
4. 强化测试先行。 在让 AI 生成实现之前，先自己写清测试用例。测试即规格，有了规格约束，生成结果的可用性会显著提升，也便于自动校验。
5. 定期做能力体检。 每季度回看：哪些工作已经完全交给 AI、哪些判断仍然只能由自己完成。如果后者在持续减少，就该警惕了。

六、结语

2025 年给我的最大冲击，不是某个具体功能的强大，而是能力商品化的速度。曾经需要多年打磨才能获得的熟练度，正在变成随取随用的基础服务。这既是解放，也是筛选——它筛掉的不是会用工具的人，而是只会用工具的人。

真正的“AI 全栈”，不是把键盘交出去，而是在更高的抽象层级上重新站位：定义问题、设计系统、约束产出、验证结果。工具越强，判断力越贵。穿越焦虑的唯一方式，是让自己的能力结构跑在工具进化的前面，而不是跟在它后面被动适配。

明年这个时候再复盘，希望记录的不是“又多用了几款工具”，而是“在哪些问题上，我比 AI 判断得更准”。