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

计算机专业就业：用一次交付过程做复盘

news 2026/7/11 21:51:21

聊《计算机专业就业：一次新的项目切入》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近帮几个学弟学妹改简历，我发现一个很有意思的现象：大家的项目经历越来越“高大上”了。以前是“基于 Spring Boot 的商城”，现在全是“基于 LangGraph 的多 Agent 协作系统”。听起来很酷，但面试官一问细节，往往就露馅——要么答不上来状态管理的逻辑，要么说清楚不了为什么选这个框架而不是那个。

我甚至看到一份简历，里面有一个“企业级知识库问答”项目，号称支持高并发和低延迟。仔细一看，代码里连最基本的错误重试机制都没有，日志只打了print("done")。这在大模型应用刚刚起步的 Demo 阶段可能没问题，但现在市场变了。招聘 JD 里不再只盯着“会调 API”，而是明确要求候选人具备权限控制、日志追踪、可观测性以及异常处理的工程化能力。

大模型应用正在从“能跑就行”转向“能稳得住”。对于计算机专业的学生来说，这意味着你的学习重心需要从单纯的 Prompt Engineering 或框架调用，转移到后端工程的核心素养上。今天我们就来复盘一下，在这个新阶段，我们该如何拆解能力，并在项目中做出正确的取舍。

基础课的价值：不仅仅是背书

很多学生觉得，既然搞 AI，那操作系统、网络、数据库这些基础课就可以放一放，或者只看看概念。这是一个巨大的误区。

当你的应用只是一个简单的 Chatbot 时，基础课确实显得“无用”。但当你要处理 Token 限制、并发请求、敏感数据过滤、以及模型幻觉带来的业务风险时，基础课里的知识就成了你设计的基石。

计算机网络：理解 HTTP/HTTPS、WebSocket 以及长轮询（Long Polling）对于处理流式响应至关重要。你知道为什么有些 AI 应用在前端会卡顿时，往往是因为没有正确处理 SSE（Server-Sent Events）连接的生命周期。
操作系统：理解进程、线程以及内存管理，有助于你设计合理的 Worker Pool 来处理耗时的 Embedding 计算或 RAG 检索任务，避免阻塞主线程。
数据库：RAG 的核心之一是向量数据库，但传统的关系型数据库依然不可或缺，用于存储用户会话历史、权限元数据以及业务状态。不懂事务一致性，你的“记忆”模块就会出 bug。

不要把这些当成负担，它们是构建稳健系统的砖瓦。

从 Demo 到工程：能力拆解与练习顺序

为了应对新的就业要求，我建议将大模型应用的开发能力拆解为三个层级，并按顺序练习。

第一层：可控的执行流（State Management）

早期的 LangChain 教程喜欢把逻辑写成线性的 Chain，但在实际生产中，业务逻辑往往是分支复杂的。你需要掌握状态机的概念。

实战建议：尝试用 LangGraph 或者自建的有限状态机（FSM）重构一个简单的“智能客服”项目。

场景：用户提问 -> 意图识别 -> 如果是查订单，走数据库查询；如果是闲聊，走 LLM 回复；如果涉及投诉，转人工。
关键点：定义清晰的状态节点和边。确保每个节点都有明确的输入输出 schema。
代码示例：展示一个简单但健壮的错误处理节点。

def handle_error(state: GraphState) -> dict: """ 统一的错误处理节点 """ error = state.get("last_error") logger.warning(f"Error in workflow: {error}") # 决策分支：是重试还是降级？ if state.get("retry_count", 0) < MAX_RETRIES: return {"next_node": "retry_step", "retry_count": state.get("retry_count", 0) + 1} else: return { "next_node": "fallback_response", "final_output": "抱歉，系统暂时无法处理您的请求，已记录日志。" }

第二层：可观测性与日志（Observability & Logging）

这是目前面试中最容易被忽视，也是最能体现工程素养的地方。当模型输出不符合预期时，你怎么快速定位问题？是 Prompt 写得不好？是检索回来的文档不对？还是模型本身能力不足？

练习重点：
1. 结构化日志：不要打印 JSON 字符串，要打结构化日志（JSON format），包含 traceid, spanid, prompttokens, completiontokens 等字段。
2. Trace 追踪：集成 OpenTelemetry 或类似工具，可视化整个请求链路。
3. 评估集（Eval Set）：建立一个小规模的黄金测试集，每次修改 Prompt 或模型后，自动运行评估，看准确率是否下降。

第三层：安全与权限（Security & Access Control）

大模型应用不再是黑盒。你需要考虑谁可以访问什么数据。

RBAC（基于角色的访问控制）：不同部门的数据，通过 LLM 检索出来时，必须经过权限过滤。
Prompt 注入防护：对用户输入进行清洗，防止恶意指令覆盖系统提示词。
数据脱敏：在发送给 LLM 之前，务必对 PII（个人身份信息）进行掩码处理。

实习准备：用“故障报告”代替“功能列表”

在找实习或校招时，如果你的简历上写着“实现了 RAG 系统”，这很普通。但如果你能写出：“通过引入向量数据库分片策略，将检索延迟从 200ms 降低至 50ms，并设计了基于 Trace 的慢查询监控告警”，这就完全不同了。

我的建议是：
在准备项目复盘时，不要只讲“我怎么做的”，要多讲“我遇到了什么问题，我是怎么排查的，最后做了什么权衡”。

例如：

问题：早期版本中，由于 Embedding 模型调用频繁，导致服务器压力过大。
排查：通过日志发现，大量重复 query 被反复 Embedding。
解决：引入了语义缓存（Semantic Cache），使用 MinHash 算法近似判断 query 相似度，命中则直接返回缓存结果。
取舍：牺牲了极少量的精确度，换取了 80% 的性能提升，符合业务场景需求。

这种基于真实生产痛点的思考过程，才是面试官最想听到的。

求职路径：不要盲目追逐最新框架

市场上有很多新出的 Agent 框架，今天一个，明天一个。对于初学者，我的建议是：先精通一个，再涉猎其他。

1. 第一阶段：掌握 Python 基础，熟悉 FastAPI 或 Flask，能够独立搭建一个包含数据库、缓存、API 接口的后端服务。
2. 第二阶段：深入理解 LangChain 或 LlamaIndex 的基本组件（Chain, Agent, Memory, Tool）。不要贪多，把一个组件吃透，知道它的底层实现逻辑。
3. 第三阶段：结合工程化实践。在一个完整的项目中，刻意加入日志、监控、权限控制和异常处理。把这个项目部署到云上（AWS/Azure/阿里云），配置 CI/CD 流水线。
4. 第四阶段：关注前沿。此时你可以去研究 LangGraph, AutoGen, CrewAI 等新框架，对比它们与你已有知识的异同。