远程AI开发者都在做什么？69个真实项目全景拆解

招聘信息上写着「AI开发者」时，它可能描述的是九种完全不同的工作。Cortance对其开发者网络中69个AI产品项目的梳理，给出了一份远比想象中分裂的答案。

Core Insight: 招聘方常把「AI开发者」当成一个统一岗位，但真实的AI项目工程复杂度差异巨大。了解项目类型与开发者画像的对应关系，是高效组建AI团队的前提。

一个标签，九种职业

Cortance开发者网络中，一位开发者花了十四个月训练运行在无人机上的检测模型；另一位则构建了审批队列，阻止CRM智能体未经人工确认就自行处置销售线索。两人都算「AI开发者」，日常工作几乎没有交集。

远程AI开发者主要构建的是模型周边的工程层，而非模型本身。在69个AI产品中，42个基于已有模型构建，覆盖现有应用内的LLM功能、文档检索、带人工审批步骤的智能体，以及面向代码库的AI工具。剩余27个则训练或微调模型，用于计算机视觉、预测和无人机自主导航。

这个分化在写职位描述之前就需要搞清楚。一个需要预约助手的团队和一个需要从人群中识别足球的模型团队，所需的技能完全不同。

69个项目是如何统计的

Cortance开发者在个人档案中记录每个项目：产品功能、自身职责和技术栈。仅靠行业标签会低估AI工作量，团队从四个维度提取记录：AI行业标签、OpenAI/LLM/RAG等AI技能标签、对agents/机器学习/计算机视觉的全文搜索，以及国防标签。截至2026年10月，活跃可用的开发者共产生95条项目记录。

每一条记录都被完整阅读而非依赖标签判断。15条记录带有AI相关标签但并未描述AI工程，如存储协议、视频营销面板或安保应用。2个成人娱乐聊天项目被排除。另有9条记录描述的产品已以其他开发者名义计数，去重后剩余69个独立产品。需要说明两个边界：样本反映的是开发者选择记录的内容，而非全部工时；一个产品可能涉及多种工作，因此按主要类型归类，各分类之间不重叠。

数字化背后的项目类型分布

计算机视觉与现有产品内的LLM功能并列最大类别，各11个产品。检索、智能体和面向软件团队的AI工具紧随其后，所有语言模型相关类别合计占69个产品中的37个。国防自主形成独立集群（6个），几乎全部是无人机的导航、追踪和制导。

职位头衔几乎无法预测项目类型。一位拥有移动端档案的开发者构建了无人机的光学追踪系统，数位前端工程师则在构建AI平台中用户实际接触的部分。阅读项目记录比任何职位字段都更有信息量。

围绕语言模型构建

语言模型工作占据69个产品中的37个，且其中极少涉及训练。这一组中大多数AI开发者将现有模型连接到业务系统、文档存储或内容管线。工程问题在于控制：模型可以触碰什么、必须引用什么，以及当服务提供商故障时会发生什么。

现有产品中的LLM功能

Yaroslav R. 为.NET后端的航班预订系统构建了AI助手层。助手只能通过白名单工具层调用预先批准的操作，每个输入在到达数据库前都经过JSON Schema验证。AI发起的每个预订操作都进入审计日志，记录输入、解析参数和结果。在实践中，模型的行为更像一个权限极窄的用户，而非系统本身。

检索与文档AI

Bohdan B. 在RAG基础上构建了合同合规工具。系统不是对文档进行开放式对话，而是将每份合同通过结构化检查清单运行，逐规则返回可验证结果。其引用匹配引擎将每条发现映射回源文件的精确位置，审计人员可以直接核查证据而无需重读整份合同。每条规则独立运行，一个检查失败不会中断其余审查。

检索的应用远不止这一个工具。样本中有10个产品使用了检索，5个微调或自定义训练了语言模型，2个产品两者兼有。样本中大多数检索项目回答的是关于公司自有文档或知识库的问题，通用模型没有这些上下文就无法作答。

生成内容即产品

Ivan V. 为Mindcast构建了后端，这是一款用克隆声音和虚拟形象生成播客的应用。文本来自OpenAI，声音来自ElevenLabs、Resemble和Azure。他为所有这些提供商设计了一个内部模型，使团队可以在不重写应用的情况下添加或替换供应商。音频通过WebSocket流式传输到达听众，这使延迟成为产品需求而非后端细节。

知道何时停下来的智能体

样本中的智能体项目共享一个设计习惯：智能体在做任何昂贵操作之前先停下来。6个产品描述了白名单工具、人工审批队列或置信度阈值来暂停工作流。市场数据也指向同一方向。据麦肯锡的State of AI调查（2026），约两成受访者表示其组织已在AI智能体方面进入规模化阶段。

Oleh Sh. 为消费者兽医健康应用设计了多智能体管线。基于LangGraph和Temporal的独立阶段处理症状录入、检索、鉴别推理和最终建议。当置信度低于设定阈值时，工作流在显式中断点停止而非猜测。每条建议以结构化裁决形式离开系统，附带置信度评分和书面理由。

在另一个项目中，Oleh构建了一个CRM智能体，对线索打分和分配，然后暂停并将建议传递给运营人员审核。不可变审计日志记录建议、置信度评分、运营人员和最终操作。对采购方来说，这个细节才是有用信号——能解释智能体在哪里停下、由谁审批的AI开发者，通常已经真正交付过一个智能体。

把AI对准代码库本身

样本中有7个产品用AI改变软件的构建方式，而非面向终端用户的功能。同一份麦肯锡调查发现，32%的受访组织因为可以用智能体编码工具自行构建，而决定不购买至少一款软件产品。但以这种方式构建，仍然需要有人为编码助手设定规则。

Danylo P. 接管了一个多租户企业AI平台的前端，并将其重构为模块化架构。他编写了同时面向开发者和AI编码助手（如Claude Code）的文档，以及关于约定和架构边界的项目级指南。后来的UI重设计通过Claude Design和Claude Code完成，现有业务功能保持完整。Cortance将这类画像描述为「AI优先软件工程师」：让代码库对AI助手可用，而不仅仅是对人可用。

Ivan S. 在更底层工作，构建自定义Claude Code插件并针对特定语言和框架版本适配技能。他将这些打包，使多个团队可以跨项目复用同一套配置。随后提示词迭代针对一个具体故障：生成代码中的API幻觉。

为单一任务训练的模型：预测ML与自定义LLM

10个产品为单一任务训练或微调了模型，涵盖游戏工作室的玩家行为预测、油田DNA分类、工厂系统预测性维护，以及通过玩游戏学习的智能体研究。这类工作需要的开发者能够负责数据准备和评估，而非仅做API集成。

Ivan S. 还为一家服务公司构建了估算系统。客户用自然语言描述项目，系统返回任务分解及工作量和成本。Ivan在8B参数规模上微调了Phi-3及后来的Phi-4模型，使用公司历史数据，并导出为ONNX实现完全本地推理。客户数据未到达任何外部提供商，评估数据集让团队在每次部署前比较模型版本。

走出实验室的计算机视觉

计算机视觉占11个产品，且大部分运行在基准数据集无法准备的条件下。温室、洗车站、运动场地和手机摄像头都在样本中出现。一个洗手监控运行在Raspberry Pi配合Intel Neural Stick上，每毫秒的推理时间都至关重要。

Michael Y. 领导了一个足球分析系统，从比赛视频中检测和追踪球员与足球。足球模块必须应对严重遮挡和高速运动。为保持实时推理，团队通过NVIDIA TensorRT运行PyTorch模型。追踪坐标随后转化为跑动距离、冲刺次数和位置热图等球员统计数据，AWS上的GPU实例在比赛日按需扩展。

国防：无GPS的自主导航

国防工作形成独立集群（6个产品），没有一个像聊天机器人。2个产品解决GPS被干扰或缺失时的导航问题，4个处理无人机的机载检测、追踪和制导。这些AI开发者在模拟器、飞控和实地测试之间切换，其中半数项目运行超过一年。

Alexander C. 领导了OMON，一个用于无卫星信号飞行旋翼无人机的视觉-惯性导航系统。系统融合相机图像与IMU数据，基于开源OpenVINS估计器运行在连接到ArduPilot的Raspberry Pi上。在仿真中，1公里任务误差保持在4米。真实飞行更难：5公里任务以最大误差低于500米完成，约为飞行距离的2-5%。

Viktoriia A. 花了14个月从事机载目标检测和追踪，将YOLO模型调优以在无人机上运行，并通过Pymavlink制导。Alex Kh. 从事FPV和固定翼无人机的光学追踪，将算法从Liftoff和Gazebo模拟器迁移到真实硬件的实地测试。在他的项目中，从仿真到现实的这一步占据了很大一部分工作。野外的光照、背景噪声和速度永远不会与模拟器匹配。

视觉-惯性导航（VIO） 的核心思路是不依赖GPS，而是融合相机图像与IMU（惯性测量单元）数据来做位姿估计。IMU能提供高频的加速度和角速度，但积分后会随时间发散；相机图像则提供低频但长期稳定的视觉约束。VIO算法通过紧耦合的方式把两者放进同一个优化框架里，用视觉观测限制IMU积分误差，从而实现长时间、高精度的位置与姿态估计。OpenVINS正是这一领域的开源紧耦合VIO估计器之一，可直接运行在树莓派这类嵌入式平台上，并通过MAVLink等协议与ArduPilot飞控交互，从而实现无人机在无卫星信号条件下的自主飞行。

仿真到现实（Sim-to-Real） 指的是把在Gazebo、Liftoff等模拟器中训练或调优的算法迁移到真实硬件上的过程。模拟器无法完全还原光照变化、背景噪声、空气动力学扰动和传感器误差，因此算法在仿真中表现良好，到了野外却常常迅速退化。缩小这个差距通常需要域随机化、在线校准和大量实地调参，这也是Viktoriia A.、Alex Kh. 等人项目中占据大量时间的原因。

不是模型工作的AI工作

样本中有5个产品需要AI工程但开发者完全不做模型工作。一家医疗机构需要语音AI平台的前端，一个工作场所copilot需要浏览器侧边栏，一个计算机视觉产品需要实时检测仪表盘。搜索AI开发者来填补这些角色会错失重点，因为核心技能是产品工程。

Pavlo H. 为一个企业AI平台构建了客户端WebRTC层，将远程容器化浏览器流式传输给用户。人们在那个浏览器中点击、输入和滚动，如同它本地运行，而WebSocket信令将其命令路由到远程会话。Pavlo还构建了比特率、丢包和往返延迟的监控视图。这些都不触碰模型，但都决定了AI产品是否好用。

将AI开发者匹配到项目类型

项目类型应该在第一次面试前就塑造职位描述。下表将每种工作类型与适合的画像及首轮通话中值得要求的证据配对。

对于前四行，最强信号是描述清楚的控制机制，而非模型名称。对于后三行，信号是来自评估或实地测试的数字。本文每个案例都来自开发者自己的项目记录，那个记录是寻找这些证据的第一站。

结语：为工作招聘，而非为标签

「AI开发者」涵盖无人机导航、预订助手和编码插件，这69个产品展示了这些工作的共同点有多么稀少。约六成基于现有模型构建，难点在于控制、检索质量和产品工程。其余训练模型，成败取决于评估数字。

当你知道项目属于表格中哪一行时，搜索就会变得更窄、更快。从已经构建过该类系统的AI开发者开始，是更务实的起点。