先分清“构建者”可能指哪几类活

消息提到，一档名为 AI That Works 的内容以“软件工厂：与真实构建者的实操体验”为看点，把智能体构建当作工程实践来讨论。但素材没有说明这期具体讲了哪些工具、框架，也没给出参与者的团队规模和岗位设置。所以它更像一个信号：这个方向正在被当成“动手做”的活来聊，而不是一个边界清晰的职位名称。

对想转岗的开发者来说，第一步不是背概念，而是把“智能体构建”拆成可核查的工作内容。常见的有四块：流程编排（把任务拆成步骤、定义状态和失败重试）、工具接入（让智能体调用外部接口或内部系统）、评测与调试（构造用例、看失败样本、定位是提示问题还是工具问题）、与业务方协作（确认场景边界和验收标准）。不同团队可能只做其中一两块，也可能一人全包。

假设一个模拟场景：两个岗位都叫“AI Agent 开发”。A 岗日常是接业务需求、调提示词、跑评测集；B 岗日常是写后端服务、做接口封装和并发优化。两者要补的技能并不一样。读岗位描述时，看到“开发与维护智能体”这类表述，还要确认：交付物是能上线的服务，还是内部试验流程？

面试时把问题问到具体动作上

素材强调“实操体验”，这提示我们：与其问“你们用什么模型”，不如问日常动作。可以这样问：

  • 这个岗位最近一个月交付了什么？是流程、接口还是评测报告？
  • 智能体出错时，谁负责定位？是构建者还是业务方？
  • 有没有现成的评测集，还是每次靠人工看结果？
  • 和算法、后端、业务的协作边界在哪里？

这些问题不保证你能拿到录用，但能帮你判断岗位实际偏哪一块。如果对方只谈愿景不谈交付物，就要多留一个问号。

转岗前先补可迁移的工程能力

素材只提供了实操分享的预告信息，没有给出技能门槛或招聘结论，所以不必因为一场分享就认定存在某个固定准入标准。更稳妥的做法是：先练可迁移的工程能力——读接口文档、写清晰的调试记录、把一次失败案例复盘成可复用的检查项。

一个实际可做的小建议：找三个你感兴趣的智能体岗位描述，把里面的动词圈出来，看是“编排”“接入”“评测”还是“协作”出现最多，再对照自己现有经验，判断哪一块你已经有真实记录可讲。这样比笼统地说“我想做 AI”更容易在面试里说清楚。 延伸阅读：程序员简历针对性制作指南：告别一稿多投，面试率提升300%