火山引擎：
企业采用 AI 的服务通道。
我的理解：客户在这里购买和使用模型及云服务，但业务价值仍要落到具体任务。售前交流时，我会先问清谁在用、替代哪个流程、价值怎么验证，再讨论适合的能力组合。
飞书等工作入口可连接企业流程；产品协同关系与公司组织归属需要分开理解。
ROLE EXPLORATION · DATA AML
豆包 AI 大模型产品解决方案实习生
理解客户的难题。
动手验证方案。
把落地推进下去。
我想做一个能动手的“技术商务连接者”：把客户的问题拆清楚，把模型、知识和工具接起来，用评测说明方案是否有效，再把现场反馈带回产品与算法团队。这份工作具有 FDE 式的特点，也是我希望深入学习的方向。
客户在业务里使用
应用与工作入口
自有系统 · 飞书等入口 · 业务流程
承载模型服务的
火山方舟
模型服务 · 评测精调 · 工具与运行环境
提供基础能力的
豆包等模型
理解 · 生成 · 推理 · 多模态
模型、平台与业务应用的关系示意。火山方舟是火山引擎的大模型服务平台；飞书、扣子等可成为入口或构建工具，具体组合取决于场景与权限。来源 ↗
01 / MY UNDERSTANDING
技术、业务与交付，
需要有人连接起来。
我对这个岗位的理解：
懂场景，能动手，愿意把问题跟到底。
我理解的岗位定位
以产品解决方案实习生的职责切入，
学习 FDE 面向客户、动手交付的工作方式。
FDE（Forward Deployed Engineer，前向部署工程师）强调贴近客户的真实流程，设计并实现解决方案。我借鉴的是这种工作方法；是否驻场、生产交付的责任范围、实习生参与深度，都需要与团队进一步确认。查看依据与边界 ↗
火山引擎：
火山方舟：
把模型服务接入应用。
官方产品资料介绍推理、评测、精调等服务；Harness 可提供搜索、记忆、代码执行等工具层能力。做方案时，我需要核查具体模型、API、套餐与权限，而不是默认所有能力都能直接组合。
例如 Computer Use 的云端环境有适用套餐与使用条件；个人 Agent Plan 与企业生产接入也要分别核查。
豆包等模型：
按任务组合能力。
语言、视觉、语音与视频生成解决的任务不同。客服场景需要看知识、规则和工具执行；内容生产需要看素材、编辑与审核链路。选模型时，我会用业务样例比较效果、稳定性、延迟与成本。
Seedance 是视频创作模型；相关数据合成或仿真用途，不能直接推导为可控制机器人或汽车。
02 / HOW THE ROLE WORKS
一条客户链路，
两类工作产出。
以需求、原型、评测和问题记录推进协作。
以下是我对执行方式的拆解，不预设固定工时比例。
客户与解决方案支持 点击阶段，查看我会怎样推进
我会交付
一份能验证的需求清单
问清使用者、现有流程、数据与系统权限，和售前确认基线及验收标准；按业务价值、可行性与风险排序，区分模型能力、知识检索和工具执行需求。
我会交付
一页方案与待确认问题
面向业务方讲清流程价值与成本，面向技术方说明 Agent / Workflow、RAG、接口和部署依赖；用架构图与原型支持讨论，未核实的效果和服务承诺交由对应负责人确认。
我会交付
一个小范围、可复现的 POC
在获授权的数据与环境中，用 Python、API、RAG 或 Agent 搭建最小原型；固定测试集，比较基线与不同模型组合的效果、工具成功率、P50 / P95 延迟及单任务成本，再决定是否需要精调。
我会交付
一份能被接手的 Bad Case
先看日志和请求 / 响应结构，收集请求标识、模型版本与最小复现；区分鉴权、限流、超时、检索、工具与模型问题。在权限范围内排查，复杂问题交给对应负责人，回归后同步结果。
产品化与 GTM 的反馈回路
客户需求 / 负面案例 → 产品与算法反馈 → 方案、FAQ 与行业材料 → 下一轮客户沟通
协作关系
销售客户与商务
↔我 · 支持与推进记录 / 原型 / 评测 / 跟进
↔售前 · 产品 · 算法方案把关与专业处理
POC 是我对“方案初步落地”的执行理解。推动问题闭环不等于承诺现场解决所有故障；生产变更、效果承诺和发布权限应由对应负责人把关。
VALUE → ADOPTION → BUSINESS
我会同时看业务结果、
工程表现和持续使用。
调用量和商业转化是需要关注的结果；我更希望先说明：方案帮客户完成了什么，以及每完成一次任务的总成本。
任务完成率、人工处理时间、返工或升级比例；与同一任务的原流程比较。
工具成功率、超时与失败、P50 / P95 延迟；计算模型、检索、工具、重试与人工复核成本。
试点是否进入实际流程、是否持续使用、能否沉淀方案；转化与续费由团队共同推进。
成本口径：单次成功任务成本 = 约定周期内相关总成本 ÷ 成功完成的任务数。ROI 需和客户确认收益、成本及观察周期，再开展测算。
03 / PUBLIC CUSTOMER RESEARCH
从公开案例，
看见不同的落地方式。
以下为官方披露的历史合作案例。
卡片中的“我的观察”是岗位分析。
汽车 · 模型应用
领克汽车
SalesCopilot · 销售 AI 助手销售数据 / 对练
→豆包助手
→销售顾问
官方披露：基于豆包的销售 AI 助手已整合进直营销售系统，支持数据分析、销售对练和个性化策略建议。
我的观察先嵌入已有工作流，再定义服务对象与效果指标。
火山引擎官方案例 ↗金融 · 垂直模型共建
海尔消费金融
消费金融大模型 · 联合创新实验室行业需求
→模型精调
→业务人员
官方披露：共建基于字节自研模型精调的垂直模型，由方舟等工具支撑，探索客服、贷后管理与风控等场景。
我的观察行业数据、模型适配与安全要求，需要一起进入方案。
火山引擎官方案例 ↗智能终端 · 多模型应用
OPPO
方舟上的智能体应用实践不同意图
→多模型组合
→终端应用
官方披露：在火山方舟上组合意图识别、联网总结、个性化人物及豆包模型，构建通用问答、面试官等智能体。
我的观察按子任务组织模型与工具，并用真实用户任务验证体验。
火山引擎官方发布 ↗金融 · 智能体生态合作
招商银行
掌上生活优惠 · 财富看点金融服务
→扣子智能体
→豆包 APP
官方披露：两款依托扣子构建的金融智能助手在豆包 APP 上线，提供优惠查询、权益解读等服务。
我的观察构建工具、分发渠道与底层模型，应在调研中分别确认。
火山引擎官方案例 ↗案例说明其披露时的合作形态，不代表当前合同状态或本岗位的具体客户名单；招商银行案例的公开信息主要说明智能体生态合作。
04 / EXPERIENCE → CONTRIBUTION
已有经历，
怎样迁移到客户现场。
我已经有原型、评测与 GTM 实践。
也清楚企业生产交付还有需要补的课。
01需求与沟通
把业务问题
拆成可讨论的方案。
已有经历壳牌场站调研 → 方案 / Demo / 路演
队长 · 商业挑战赛第二名
对应岗位
需求澄清 · 方案表达 · 跨背景协作
02Agent 与原型
把知识、规则与工具
组织成服务链路。
已有经历OntoCare → 双本体 / 工具调用 / 客服原型
方案架构 · 产品设计 · 团队工程作品
对应岗位
Agent / RAG 原型 · 多模块协作 · POC 展示
03评测与反馈
用失败样例定位问题，
用回归验证修复。
已有经历OntoCare → 对抗测试 / 硬断言 / 人工回归
核心任务通过率 83.8% → 98.6% · 历史单轮
对应岗位
复现记录 · 效果评估 · 产品与算法反馈
04GTM 与决策
把市场信息
整理成产品决策依据。
已有经历追觅 GTM → 用户 / 竞品 / 渠道 / 商业测算
智能硬件海外 GTM · 30+ 报告 · 8,000+ 评论
对应岗位
用户与市场理解 · 行业材料 · 价值与成本沟通
我为什么想做这份工作
安克黑客松让我练习了在有限时间里澄清需求、和队友把原型做出来，再用实机与测试结果说明方案。追觅海外 GTM 让我更关注用户、市场和商业约束。这两段经历，让我想继续走“理解业务 + 技术动手 + 方案交付”这条路。
我愿意配合客户交流与出差，也愿意从请求日志、接口联调和失败样例这些细节做起。现阶段，我积累的是竞赛原型和项目实践；企业多租户权限、生产监控、灰度发布与跨团队交付，是我希望在实习中继续补足的能力。我能迁移的是用户与市场分析、方案表达及成本测算方法；企业级交付经验，需要在真实客户项目中继续积累。
进一步展开：Multi-Agent 深度研究实践
任务拆分 → 并行研究 → 来源整理 → 红队反馈；项目代码尚未公开。
05 / MY APPROACH
从一个小场景开始，
把验证做扎实。
这是我的落地判断，
也是希望在岗位中继续积累的能力。
单点 POC
小范围数据
明确基线与验收标准
受控试点
与负责人确认数据与权限
联调、监控、人工兜底及回滚
可复用方案
效果 / 时延 / 成本一起看
沉淀案例与行业材料
我希望进一步了解的团队实践
- 01实习生从 POC 到生产试点分别参与哪些环节，交付负责人是谁？
- 02团队怎样同时评价客户价值、方案采用与商业转化，如何定义试点成功？
- 03客户 Bad Case 怎样形成可复现证据、进入产品算法迭代，并沉淀为共性方案？