这句话是四年前的需求评审会上说的。说这话的是后端组的L，入职两年，技术不错，说话一贯有点冲。当时在讨论一个新功能的发布计划，我提了句要预留回滚窗口，他就笑着接了这句："运维嘛，出了问题重启一下不就好了。"旁边坐着产品、测试、还有我们组长。大家都听到了，有人低头看手机，有人假装在记笔记。我没有立刻回他。由于是政府的项目，接口的错误率在五分钟内从0.1%飙到了38%，写入开始大量失败。我从床上爬起来，开电脑，登跳板机，第一眼看到的是数据库连接池耗尽的报错：连接池最大设置的200，全部被占满，新请求全部超时。我拉了一下慢查询日志，发现有一个SQL在疯狂跑全表扫描，平均耗时从正常的...

牛友们，这是不是坑啊，实习完了把我开了咋办

二面一天半了一直这样，是在横向吗

1. 自我介绍2. 为什么要通过微调模型来做代码生成？为什么不用纯 prompt 或 spec coding？答案：纯 prompt 和 spec coding 确实可以提升模型在单次任务上的表现，但它们更多是推理时约束，解决的是“让模型按要求做事”的问题。微调解决的是模型行为分布的问题，比如固定代码风格、内部框架 API 使用习惯、异常处理模式、日志规范、单测模板、目录结构约定，这些如果全部靠 prompt 塞进去，成本很高，也容易在长任务里被稀释。在缺陷修复 Agent 里，我选择微调不是为了让模型记住业务代码，而是让它学习稳定的工程动作：先读测试，再定位调用链，再改最小范围，再补回归测试...