Demo能跑上线翻车？我把权限日志踩过的坑，写成了能拿到offer的简历

2026/8/6 13:44:23 拓冰建站浏览量

这篇我按“先跑起来、再讲取舍”的方式写《程序员就业怎么选方向？先回答几个现实问题》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

2026年，大模型应用正在从Demo阶段转向生产阶段。我花了一年时间，从一个只会调API写Prompt的"大模型开发"，变成一个能扛住生产环境权限、日志和可观测性的工程师。这篇文章复盘我踩过的坑、学到的技能组合，以及最终怎么把这些经历写进简历拿到offer。

---

市场变了：为什么Demo不再是护城河

去年这时候，我投简历，人家问我"做过什么大模型项目"。我说做过一个智能客服Agent，能调用RAG、能路由多模型、能流式输出。对方点点头，问"那权限怎么设计的？"我愣住了。

又问"用户输入会进日志吗？敏感信息会脱敏吗？"我还是愣住了。

那时候我就意识到，Demo能跑和能上线是两件事。

今年我换了个思路，不再去卷那些花哨的Agent框架，而是把精力放在一个真实项目上——帮一家小公司接了一个内部知识库问答系统。Demo阶段很顺利，RAG、Prompt、流式输出都搞定了。但真正上线前，我们团队花了两周时间解决三件事：权限控制、日志追踪、错误可观测性。

这三件事不是加分项，是必选项。

为什么市场变了？因为2024到2025年，太多人做AI应用Demo，但真正上线的少。企业发现，能写Prompt的人很多，能守住生产环境的人很少。这不是模型的问题，是工程化的问题。

---

企业到底在要什么人

我面过几家创业公司，也面过几家大厂。发现一个规律：技术面试官的问题越来越具体。

他们会问：

你的Agent怎么处理用户越权访问？
模型输出里有敏感信息怎么办？
怎么追踪一个请求从进入系统到模型响应结束的全链路？
失败了怎么重试？重试了几次？谁负责？

这些问题在Demo阶段根本不会遇到。但在生产环境，每一个都是要命的。

我记得有一次面试，面试官让我现场设计一个权限方案。我说"可以用RBAC"。他问"那动态权限呢？比如用户A只能看自己部门的数据"。我又说"可以加个数据过滤层"。他问"过滤逻辑放在哪里？为什么？"

我答上来了，但说实话，之前根本没认真想过这些问题。这次面试让我意识到，企业要的不是"会调API"的人，是"能扛住生产环境"的人。

---

权限、日志、可观测性：三个硬技能

权限控制

权限是最容易被忽视的。很多人做Agent应用，默认假设"所有用户都能用所有功能"。但生产环境不是这样。

我后来做的知识库问答系统，权限设计是这样的：

# 权限控制示例：基于角色的数据访问 class PermissionMiddleware: def __init__(self, user_role: str, tenant_id: str): self.role = user_role # admin, manager, employee self.tenant_id = tenant_id def check_access(self, query: str) -> dict: # 普通员工只能访问公开文档 if self.role == "employee": return { "allowed": True, "filter": {"visibility": "public", "tenant_id": self.tenant_id}, "max_tokens": 500 } # 管理者可以访问部门文档 elif self.role == "manager": return { "allowed": True, "filter": {"tenant_id": self.tenant_id}, "max_tokens": 1000 } # 管理员可以访问全部 else: return { "allowed": True, "filter": {}, "max_tokens": 2000 }

这段代码看着简单，但背后有几个坑：
1. 权限检查要在请求进入模型之前完成，不能等模型输出了再过滤
2. 不同角色的token上限要不一样，防止普通用户被大模型"喂"太多信息
3. 权限配置要支持热更新，不能改完权限还要重启服务

日志追踪

日志不是简单的print。生产环境需要的是结构化日志，要能追踪一个请求从进来到出去的全链路。

我踩过的坑：一开始只记录请求和响应，不记录中间过程。结果线上出问题，根本不知道是RAG召回错了，还是模型生成错了，还是权限过滤错了。

后来改成这样：

import uuid import logging from datetime import datetime # 结构化日志配置 logging.basicConfig( format='%(asctime)s | %(levelname)s | trace_id=%(trace_id)s | user=%(user_id)s | %(message)s', level=logging.INFO ) logger = logging.getLogger(__name__) def log_request(trace_id: str, user_id: str, action: str, details: dict): logger.info( f"{action} | details={details}", extra={"trace_id": trace_id, "user_id": user_id} ) # 使用示例 trace_id = str(uuid.uuid4()) user_id = "u_12345" log_request(trace_id, user_id, "QUERY_START", { "query": "季度销售数据", "role": "manager", "timestamp": datetime.now().isoformat() }) # ... 处理逻辑 ... log_request(trace_id, user_id, "QUERY_END", { "status": "success", "latency_ms": 1200, "tokens_used": 850 })

关键点是：每个请求要有唯一的traceid，所有日志都带上这个ID。这样线上出问题的时候，可以根据traceid把所有相关日志串起来，快速定位问题。

可观测性

可观测性不是监控报警，而是让系统"可解释"。

我后来总结了一个简单框架：
1. 指标：QPS、延迟、错误率、token消耗
2. 日志：结构化日志，带trace_id
3. 追踪：请求链路追踪，从入口到模型输出

这三件事做下来，系统出了问题不再是"瞎猜"，而是能定位到具体环节。

---

简历怎么写：把踩过的坑变成项目亮点

很多人写简历，喜欢写"使用LangChain搭建了智能客服系统"。这种写法面试官已经看腻了。

我后来的写法是：

项目名称：内部知识库问答系统

设计了基于角色的权限控制方案，支持employee/manager/admin三级权限，权限变更无需重启服务
实现了结构化日志和全链路追踪，单个请求可从入口追踪到模型输出，问题定位时间从小时级降到分钟级
接入可观测性监控，覆盖QPS、延迟、错误率、token消耗等核心指标
项目从Demo到上线历时3个月，期间解决了权限绕过、日志丢失、链路断裂等5个生产环境问题

这样写的好处是：
1. 有具体数字（三级权限、3个月、5个问题）
2. 有具体动作（设计、实现、接入、解决）
3. 有具体成果（定位时间从小时级降到分钟级）

---

面试怎么答：从Demo思维到生产思维

面试时，我学会了一个技巧：把每个Demo项目都往生产环境方向想。

比如面试官问"你做过的最有挑战的项目"，我不会只讲功能多复杂，而是讲：

> "我做过一个Agent系统，Demo阶段很顺利。但上线前我们遇到了权限问题——不同用户看到的数据不一样，但模型默认会返回所有知识。我们设计了一个权限中间件，在请求进入模型之前先过滤数据范围，权限配置支持热更新。这个设计让我意识到，Demo和生产的差距不在模型能力，在工程化。"

这种回答的好处是：
1. 展示了技术深度
2. 展示了问题解决能力
3. 展示了从Demo到生产的思维转变

---

总结

2026年，程序员就业的硬通货不是"会调API"，而是"能扛住生产环境"。

我花了一年时间，从一个只会写Demo的"大模型开发"，变成一个能做权限、日志、可观测性的工程师。这个过程不难，但需要转变思维：

1.不要只关注模型能力，要关注工程化能力
2.不要只做Demo，要想想如果上线会怎样
3.不要只学框架，要理解框架背后的设计思路

权限、日志、可观测性，这三件事看似基础，但真正能做好的人不多。这也是为什么2026年，这些能力成了求职的硬通货。

如果你也在准备找工作，不妨从一个小项目开始，试着把它从Demo做到"能上线"。这个过程踩的坑，会比任何教程都让你成长得快。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。

建站实战干货