聊《AI大模型就业为什么越规划越焦虑？问题可能不在路线》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。
摘要
摘要：从业务方提需求到项目上线，大模型岗位的门槛早已不是"Demo能跑通"。本文复盘一次完整的技术选型过程，对比三种方案的取舍与翻车现场，拆解权限、日志、可观测性的排查链路，给出准备作品集和面试时的实用建议。
---
目录
- 业务方的一句话，怎么变成技术方案
- 技术选型对比：三种方案的取舍
- 翻车现场一：权限控制没落地
- 翻车现场二：日志追踪断链
- 翻车现场三：可观测性缺失
- 排查过程与失败原因拆分
- 必备技能栈与项目作品集建议
- 求职路线：从Demo到能干活
- 总结
---
目录
- 业务方的一句话，怎么变成技术方案
- 技术选型对比：三种方案的取舍
- 翻车现场一：权限控制没落地
- 翻车现场二：日志追踪断链
- 翻车现场三：可观测性缺失
- 排查过程与失败原因拆分
- 必备技能栈与项目作品集建议
- 求职路线：从Demo到能干活
- 总结
业务方的一句话，怎么变成技术方案
上次跟业务方对齐需求，对方甩来一句话："现在竞品都有Agent，我们也做一个，能回答问题的那种。"
简单吧？但真正把这句话落到代码里，事情远没有想象中轻松。
我先问清楚三个问题：
1. 调用场景：是前台用户实时对话，还是后台定时批量处理？
2. 输出责任：Agent的回答涉及哪些数据权限？能不能泄露敏感信息？
3. 异常兜底：模型答错了怎么办？需要人工复核吗？
业务方的回答基本是："实时对话、别泄露内部数据、答错了就答错了。"
我听了就知道，这个项目上线第一天大概率会出问题。
---
技术选型对比：三种方案的取舍
针对这个场景，我对比了三种技术选型：
| 方案 | 优点 | 缺点 | 适用场景 |
|------|------|------|----------|
| 直接调API + 简单函数调用 | 开发快，一周能出Demo | 没有权限控制，日志全靠打印 | 内部工具、非敏感数据 |
| LangGraph工作流 | 可观测性强，节点可控 | 学习成本高，联调复杂 | 企业级Agent |
| 封装现有框架（如Semantic Kernel） | 生态完善，插件丰富 | 黑盒多，定制困难 | 快速验证、MVP |
我的选择是LangGraph。原因很简单：面试时面试官问的不是"你会不会调API"，而是"你能不能把Agent做成生产可用的系统"。
---
翻车现场一：权限控制没落地
现象：上线第一天，有用户通过构造恶意prompt，获取到了其他用户的订单信息。
排查过程：
1. 查看日志，发现用户输入包含"帮我看一下订单ID 12345的信息"
2. 模型正常返回了订单详情
3. 检查代码，发现RAG检索时没有做权限过滤
根本原因：RAG检索阶段只做了语义匹配，没有校验当前用户是否有权限访问该数据。
# 错误的做法：直接检索
def retrieve_documents(query: str, user_id: str) -> List[Dict]:
# 没有用户权限校验
results = vector_store.similarity_search(query, k=5)
return results
# 正确的做法：检索前先过滤权限
def retrieve_documents(query: str, user_id: str) -> List[Dict]:
# 先获取用户有权限的数据范围
allowed_ids = permission_service.get_allowed_document_ids(user_id)
# 再用语义检索 + 权限过滤
results = vector_store.similarity_search(query, k=10)
filtered = [doc for doc in results if doc['doc_id'] in allowed_ids]
return filtered[:5]代码解释：
- 输入：query（用户问题）、user_id（当前用户）
- 核心逻辑：先获取用户权限范围，再检索，最后过滤
- 输出：符合权限的文档列表
- 异常处理：应该增加权限服务调用失败的兜底逻辑，比如降级到空结果或提示无权限
失败原因拆分：这是配置错误。开发时只关注了检索准确率，忽略了权限配置。应该把权限校验作为基础设施的一部分，而不是事后补充。
---
翻车现场二：日志追踪断链
现象：线上发现问题后，日志里只有最终输出，看不到中间的思考过程。
排查过程：
1. 用户反馈回答错误，查看应用日志，只有最终回复内容
2. 查看模型API日志，有完整请求和响应
3. 发现中间节点（如检索、重排序）的日志没有串联
根本原因：每个节点独立打印日志，没有trace_id贯穿全程。
import uuid
import logging
# 配置logger时传入trace_id
logger = logging.getLogger(__name__)
def call_agent(query: str):
trace_id = str(uuid.uuid4())
logger.info(f"[{trace_id}] 收到请求: {query}")
try:
# 检索节点
docs = retrieve_documents(query, trace_id)
logger.info(f"[{trace_id}] 检索到 {len(docs)} 条文档")
# 生成节点
response = generate_answer(query, docs, trace_id)
logger.info(f"[{trace_id}] 生成完成")
return response
except Exception as e:
logger.error(f"[{trace_id}] 执行失败: {e}")
raise代码解释：
- 输入：query
- 核心逻辑：生成trace_id，贯穿所有节点
- 输出：最终回复
- 异常处理：每个节点都应该捕获异常并记录trace_id，方便事后回溯
失败原因拆分：这是工程习惯问题。开发时图方便直接用print，没有统一日志规范。应该一开始就把可观测性作为基础要求。
---
翻车现场三：可观测性缺失
现象：模型响应时间突然变长，但没有告警，业务方反馈后才发现问题。
排查过程：
1. 查询监控系统，发现P99延迟从2秒涨到8秒
2. 分析调用链，发现是向量检索耗时增加
3. 检查索引状态，发现向量库磁盘空间不足
根本原因：没有对关键指标设置阈值告警。
失败原因拆分：这是环境问题。运维没有及时清理磁盘，监控也没有覆盖这个维度。应该在项目启动时就配置好关键指标的告警。
---
排查过程与失败原因拆分
总结这三个翻车现场，可以按以下框架归类：
| 失败类型 | 特征 | 排查方法 | 修复优先级 |
|----------|------|----------|------------|
| 业务错误 | 逻辑实现不符合需求 | 对照需求文档逐项验证 | 高 |
| 配置错误 | 参数不对、权限缺失 | 检查配置文件、环境变量 | 高 |
| 环境问题 | 依赖服务不可用、资源不足 | 检查基础设施、监控指标 | 中 |
我的排查原则是：先看日志，再查配置，最后看环境。大多数问题都属于前两类。
---
必备技能栈与项目作品集建议
如果你想转向大模型方向，以下几点是面试官真正在意的：
技能栈优先级：
1. Python基础 + 异步编程：大模型应用基本都是异步IO密集
2. 向量数据库：理解RAG的基本原理和常见问题
3. Agent框架：LangGraph、LangChain等，重点理解工作流设计
4. 工程化能力：日志、监控、权限、缓存
项目作品集建议：
不要只放一个"问答机器人"Demo。建议展示：
- 一个完整的Agent应用，包含权限控制和日志追踪
- 一份问题排查报告，展示你如何定位和修复线上问题
- 一个性能优化案例，说明你如何降低延迟或成本
---
求职路线：从Demo到能干活
我的建议是：
1. 先做一个完整的项目：不要只做Demo，要把权限、日志、监控都加上
2. 主动找问题：自己给项目加压测试，看看能撑住多少并发
3. 准备排查故事：面试时会问"你遇到过什么线上问题，怎么解决的"，提前准备1-2个完整案例
4. 关注工程细节：代码规范、测试覆盖、部署流程，这些是区分"会调API"和"能干活的"的分水岭
---
总结
大模型岗位的门槛正在提高。Demo能跑通只是及格线，面试官更看重你能不能把项目做成生产可用的系统。
权限控制、日志追踪、可观测性，这三点决定了你的Agent是玩具还是工具。面试前，建议至少有一个包含这些要素的完整项目。
如果你在准备过程中遇到问题，欢迎在评论区交流。
资料展示
下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。
需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。
262
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
