TECH SKILLS

把模型接到产品里

林舟 · AI 应用工程师 · 6 年全栈交付

我不太写「精通 xxx 框架」这种空简历。更想说清楚一件事：我擅长把大模型从 Demo 做成能上线、能观测、能迭代的产品能力——前端交互、服务稳定性、检索质量、评测门禁和成本，都在同一条责任链上。

过去两年主战场是企业知识库问答、客服辅助、内部 Agent 工作流。合作对象通常是产品、业务专家和平台同学。我的默认姿态是：先把「什么叫可用」定义成指标，再谈模型选型与花活。

下面分三块：能力自评（带边界说明）、两段可核验案例、以及我怎么选工具和怎么协作。

能力与边界

满分标准：能独立设计、上线并兜底；不是「跟做过」或「看过文档」。

LLM 应用架构

92

能从业务问题拆出检索、生成、工具调用、人工接管的边界；会做 RAG 链路设计、Agent 编排、失败回退与成本控制。不擅长也不吹嘘「从零训基座模型」——训练侧我只做到理解数据与评测，落地交给更专的同学。

TypeScript 全栈交付

90

Next.js + Node 是我默认交付栈。能把对话流、权限、流式输出、错误态做成可维护模块；类型边界写清楚，避免「前端一套、后端一套」的双倍债。复杂可视化或重度动画我会主动找前端专项协作。

Python 服务与数据管道

84

FastAPI 做模型侧网关与批处理；文档切分、embedding 任务、评测跑批是日常。能写稳的流水线，但大规模分布式调度不是我的主场——会明确依赖平台团队的队列与资源编排。

可观测与线上兜底

78

会把召回率、拒答率、幻觉投诉、P95 延迟、单次 Token 成本做成发布前后都要看的数。容器发布与基础排障能扛；多集群调度、网络策略深水区会拉 SRE 一起进。

只写我主导或核心负责的部分，方便对方对照问细节。

CASE 01 · 企业知识库问答

人工接管率 41% → 18%

背景　业务方已有两轮「接了大模型」试点，演示好看，上线后大量答非所问。客服团队不敢关人工入口，接管率长期停在四成以上，成本与体验双输。

我做了什么　先和业务一起定义「可自动结束会话」的标准，而不是盲目换更大模型。重建文档切分与权限过滤；给高风险意图加拒答与转人工；把 Top 失败问题做成周更回归集。前端补「来源引用 + 一键反馈」，让坏答案能回流到评测，而不是消失在聊天记录里。

结果　全量 8 周后人工接管率降至 18%；P95 延迟压在 1.6s 内；幻觉相关客诉周均下降约一半。更重要的是发布有了门禁：回归集不过，不允许直接推生产。

CASE 02 · 内部 Agent 工作流

把「会聊天」做成「能办事」

背景　运营同学希望 Agent 帮查工单、起草回复、拉报表。早期版本工具乱调、权限过大，出过一次误发内部通知的事故，项目差点被叫停。

我做了什么　把工具调用改成白名单 + 二次确认；高危动作必须人工点确认。编排层拆成「理解意图 → 选工具 → 生成草稿 → 确认执行」四步，每步落日志。补一套影子模式：新策略先对历史会话回放，再灰度真人。

结果　核心流程自动化覆盖率到 63%；误操作工单归零；业务方愿意继续加场景。项目从「怕模型乱动」变成「敢加能力，但门禁更严」。

先定义失败长什么样，再写第一行业务代码。AI 功能最容易死在「说不清什么叫好」——所以我会逼自己和产品把指标写进文档：拒答算不算成功？引用错了算不算事故？这些不事先谈清，上线后只能互相甩锅。

默认小步发布。模型、Prompt、检索策略任意一项变更，都尽量可回滚。我会维护一份「坏例子集」，每次改动先跑，比纯看 demo 对话靠谱得多。

合作上我喜欢把边界说死：哪些我能独扛，哪些必须平台 / 算法 / 设计一起进。宁可前期显得「计较」，也比中期职责糊成一锅粥强。

语言与框架　TypeScript / Next.js / Node · Python / FastAPI。业务默认 TS 全栈；模型侧网关与批处理用 Python。

数据与检索　PostgreSQL、对象存储、向量库（按项目选型）。关心的是切分策略、权限过滤和召回评测，而不是追新库名。

模型与编排　主流云厂商 API + 开源编排层。会做 Prompt / 工具调用的版本管理，避免「线上不知道跑的是哪一版话术」。

观测与发布　OpenTelemetry 链路、基础指标看板、容器化发布。目标是坏变更能在小时级被发现并回滚，而不是靠用户投诉。

需要看代码或更完整的项目说明？

技术主页有脱敏案例与架构笔记，欢迎约聊具体场景。

打开技术主页