当前位置：首页 > news >正文

Demo能跑就敢投大模型岗位？真正卡住你的是这三样东西

news 2026/8/6 23:25:12

聊《别急着重做程序员职业规划，先看岗位到底在筛什么》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

前阵子帮几个朋友改简历，发现一个挺有意思的现象：很多人项目经历写得很漂亮，"基于LangChain搭建智能客服系统"、"实现了RAG问答链"，看起来每一步都踩在热点上。但细问下去，这些项目基本都停在Jupyter Notebook里，或者最多部署到本地跑个API。一旦我说"那权限控制呢？日志追踪呢？线上出问题了怎么定位？"，对方就开始支支吾吾。

不是大家不想学，而是学习路线本身出了问题。大多数教程的叙事是：装环境、调API、写Prompt、跑通Demo。没人告诉你，Demo跑通只是入场券，真正决定你能不能进团队的是另外三件事。

岗位到底在筛什么

先说个真实情况。我最近看了一些大模型相关岗位的JD，把要求拆开来分类，发现一个规律：初级岗位和中级岗位的要求差得比你想的大。

初级岗位基本都在说"会用"——会调API、会写Prompt、会用LangChain或LlamaIndex搭个链子。这类岗位面试也简单，给你一个场景让你写个Demo，能跑就行。

但中级岗位的要求突然变了。JD里开始出现"可观测性"、"权限控制"、"链路追踪"、"生产环境部署"这些词。面试官不再问你"怎么实现RAG"，而是问你"你的系统出错了怎么定位？用户输入敏感信息怎么过滤？"

这不是招聘方在刁难，而是现实。去年我们团队接了一个内部Agent项目，Demo阶段丝滑得很，一上生产环境就出问题：权限越界、日志丢失、链路追踪断掉。最后花了一个月补工程化能力，比最初写业务逻辑还久。

判断标准很简单：如果你的项目只能证明"我会用框架"，那你竞争的是初级岗位；如果你的项目能证明"我能把东西放到生产环境"，你才有资格谈中级。

权限、日志、可观测——为什么是这三样

先说权限。很多人做Agent项目，默认模型输出是可信的，直接执行。这在Demo里没问题，在生产环境里是隐患。我们见过一个案例：一个内部知识库问答Agent，没有做权限隔离，普通员工通过Prompt注入拿到了高管薪酬数据。这不是理论风险，是真实发生过的。

权限控制不是什么复杂技术，核心就是两点：身份认证和输入过滤。身份认证解决"你是谁"，输入过滤解决"你能访问什么"。代码层面不难，但大多数人连这个意识都没有。

# 一个简单的权限校验中间件示例 class PermissionMiddleware: def __init__(self, access_control: AccessControl): self.ac = access_control def check(self, user: User, query: str) -> bool: # 1. 身份认证 if not user.is_authenticated: return False # 2. 输入过滤：检测敏感信息 if self.ac.contains_sensitive_data(query): return False # 3. 权限检查：用户是否有权限访问相关数据源 data_sources = self.ac.extract_data_sources(query) return all(self.ac.has_permission(user, ds) for ds in data_sources)

再说日志。Demo里的日志通常长这样：打印一下输入和输出，完事。生产环境的日志需要解决三个问题：这个请求从哪来、经过了哪些节点、每个节点耗时多少。

很多团队上线后出问题，第一件事是"日志在哪？"——发现根本没记。或者记了但找不到，因为缺少trace_id贯穿整个链路。这不是模型的问题，是工程习惯的问题。

可观测性听起来很高大上，其实就是一句话：系统出问题时，你能多快定位到原因。这需要日志、指标、链路追踪三件套配合。现在市面上有现成的方案，比如OpenTelemetry，接入成本不高，但能救命。

短期学习计划：从Demo到可上线

如果你现在的项目还停留在Demo阶段，别急着学新框架，先把这三件事补上。我的建议是按这个顺序来：

第一周：给现有项目加权限控制。不用重写，加一个中间件层就行。把用户输入做过滤，把模型输出做校验，把数据访问做隔离。这一步能帮你建立"生产意识"。

第二周：加结构化日志。用JSON格式记录每个关键节点的信息，包括请求ID、时间戳、输入输出摘要、耗时。确保你能从日志里还原一次完整请求的链路。

第三周：接入链路追踪。用OpenTelemetry或者类似的工具，给每个请求生成trace_id，贯穿整个调用链。这一步完成后，你的项目就有了可观测性的基础。

第四周：模拟线上故障。故意制造一些问题——权限越界、日志丢失、链路断裂——然后修复。这个过程能帮你理解每一层的价值。

这四周的时间投入，比学三个新框架更有价值。

中期项目沉淀：简历上怎么写

很多人的简历项目描述是这样的："使用LangChain实现了智能问答系统，支持多轮对话。"

这种描述的问题是：它只证明你会用工具，没证明你能解决问题。面试官想看到的是你对工程化的理解。

试试这样写：

> 基于LangGraph构建内部知识库问答Agent，实现了基于角色的权限控制（RBAC），支持细粒度数据源访问隔离；接入OpenTelemetry实现全链路追踪，覆盖Prompt调用、工具调用、模型响应三个阶段的耗时和错误率监控；设计结构化日志方案，支持按trace_id检索完整请求链路，线上问题定位时间从小时级降至分钟级。

两段描述看起来信息量差不多，但后者能回答面试官的三个问题：你会不会考虑安全问题、你会不会处理线上故障、你能不能量化项目价值。

关键原则：不要只写"做了什么"，要写"解决了什么问题"和"带来了什么变化"。数字比形容词有力，具体比笼统可信。