先给结论：如果你现在还停留在“会写 CRUD、会调接口、会部署服务”这个阶段，在大模型应用快速落地的企业项目里，竞争力正在被明显稀释。这不是贩卖焦虑，而是岗位需求结构正在从“功能实现”转向“模型应用、效果调优、工程化落地”。
这篇文章不追热点，只回答三个层面的问题：企业现在到底需要什么样的程序员？这些岗位对标哪些技术栈？以及从传统开发切到 AI 应用开发，应该按什么路线补技能、做什么项目验证自己。
# AI大模型时代！适配企业需求的程序员需具备哪些生存技能？大模型就业市场和未来趋势及岗位对标哪些技术栈？ 这次我们直接聊一个偏“生存”的话题：AI 大模型时代，程序员到底要会什么，才不会被企业当成“只会写接口的人”？ 先拆一下标题里最核心的三个关键词：AI大模型、程序员、技术栈。很多人的误区是“大模型来了，我的岗位没了”。但实际从招聘需求和项目交付看，更准确的说法是：**岗位没有消失，但要求变了**。以前企业招后端，看的是框架熟不熟、并发处理过没有；现在不少企业招“AI应用开发”，看的是你能不能把模型能力接进业务流，能不能做 RAG，能不能调 Agent，能不能把 prompt 工程化。 这篇文章不会只堆概念，我会按下面几个板块展开： 1. AI 大模型时代程序员的核心能力速览，一张表看清企业需求侧重点。 2. 就业市场变化与未来趋势，结合真实需求端信号来看。 3. 岗位对标与技术栈拆解，从“大模型应用开发”到“Agent 工程师”逐一说清楚。 4. 给传统后端/前端/算法程序员一条可执行的转型路线。 5. 实际开发中高频用到的接口调用、批量任务、RAG/Agent 工程化示例代码。 6. 本地部署与推理性能观察思路。 7. 常见误区与排查思路。 8. 最佳实践与合规边界。 ## 1. 核心能力速览 先把结论性内容放在最前面。下表整理了 AI 大模型时代企业端常见的技术方向、核心技能与岗位对标，方便对号入座。 | 能力方向 | 核心技能 | 技术栈示例 | 对标岗位 | | --- | --- | --- | --- | | 大模型应用开发 | OpenAI 兼容接口、Prompt 工程、RAG、Function Call | Python、FastAPI、LangChain、LlamaIndex、向量数据库 | 大模型应用开发工程师 | | Agent 开发 | 多步任务编排、工具调用、状态管理、记忆机制 | LangGraph、AutoGen、Dify、Coze、Redis | Agent 开发工程师 / AI 智能体工程师 | | 模型本地化部署 | 模型量化、显存评估、推理加速、服务封装 | llama.cpp、Ollama、vLLM、TensorRT-LLM、Docker | 大模型部署工程师 / 推理优化工程师 | | RAG 知识库 | 文档解析、向量化、召回排序、重排 | OCR、Embedding 模型、Milvus、Chroma、Elasticsearch | RAG 应用工程师 / 知识库工程师 | | AI 数据与评测 | 构造评测集、标注、模型效果回归 | Prompt 测试、pytest、数据集管理平台 | AI 评测工程师 / 数据策略工程师 | | AI 平台化 | 统一接入多模型、配额管理、成本监控 | 网关、K8s、模型路由、日志系统 | AI 平台工程师 / MLOps 工程师 | 如果是传统程序员想转型，最优先看第二行和第三行。前者是应用层机会最多的地方，后者是工程化门槛较高但稀缺性更强的地方。 ## 2. AI 大模型就业市场现状与趋势 从最近搜索热度比较高的词来看，有几类需求信号非常明显： - `ai大模型应用开发`、`ai大模型应用开发项目` - `agent开发需要哪些技术栈` - `ai大模型学习路线` - `本地部署ai大模型` - `基于第三方大模型和ai技术平台做二次开发与场景适配的区别` - `信创 ai大模型 文档解析 ocr` - `制造业ai大模型哪家最强` 这些词反映了三个趋势： **趋势一：企业从“要不要用 AI”进入“怎么落地 AI”阶段。** 去年讨论最多的是大模型能力多强，今年讨论最多的是如何在具体业务里跑通一个 AI 功能。文档解析、OCR、知识库、智能客服、AI Agent 都是高频落地点。 **趋势二：岗位需求从“算法模型训练”转向“应用工程化”。** 大多数企业不会从头训练基础大模型，更多是基于第三方大模型或开源模型做二次开发、场景适配。所以市场需要的是懂业务、懂工程、能调模型、能优化效果的工程师，不只是会训练模型的算法研究员。 **趋势三：本地化部署和私有化需求持续增长。** 金融、政务、制造、医疗这些行业对数据安全要求高，本地部署 AI 大模型、私有化知识库、信创环境适配都有明确需求。这也就意味着懂模型部署、懂推理优化、懂信创适配的程序员会有持续市场。 从岗位要求角度来看，核心竞争力不再是“我熟悉某个框架”，而是“我能把模型能力稳定地变成一个业务功能”。谁能更快地用 RAG 解决知识库检索问题，谁能用 Agent 把多步业务流程自动化，谁能把模型服务在低显存环境里跑起来，谁就能拿到不错的 offer。 ## 3. 程序员需要补齐的底层技能 不管什么岗位方向，以下几项底层技能在 AI 大模型时代越来越重要。 ### 3.1 模型认知与 Prompt 工程 第一件事是理解模型不是规则引擎。它输出的是概率，不是固定结果。所以写 Prompt 不能像写代码那样“一次编译，永久运行”，需要根据模型反馈调整。 Prompt 工程的核心能力包括：写清楚角色、任务、背景、输入格式、输出格式、约束条件；用 few-shot 示例稳定输出格式；面对模型输出不稳定时，用后处理解析兜底。 这一项是入门门槛最低、但最容易拉开差距的能力。 ### 3.2 RAG 与知识库能力 企业里大量数据是非结构化的，比如 PDF、Word、扫描件、表格。要让大模型能回答基于这些数据的问题，就得把文档解析成纯文本，切片，向量化，存储到向量数据库，再在用户提问时做检索召回，把相关内容拼进 Prompt，让模型基于上下文回答。 RAG 是目前企业落地大模型最成熟的主流方案，技术栈通常涉及 OCR、文档解析、Embedding、向量数据库、重排模型。这里也是传统后端程序员切入最快的一个方向。 ### 3.3 工程化与稳定性能力 大模型应用和传统应用最大的区别是：不稳定。同一个 Prompt 在不同模型版本下输出可能不同，同一批文档切片后检索效果可能不同。所以工程化能力就变得很关键。 你需要会做：请求重试、超时控制、输出格式校验、结果缓存、日志追踪、效果回归、成本统计。这套东西和传统后端的高可用思路一脉相承，只是对象从“接口”变成了“模型调用”。 ### 3.4 业务理解与场景适配能力 这一点最容易被程序员忽略。从企业需求看，单纯会调 API 的人很多，但能把模型能力落到具体业务场景里的人很少。 拿制造业来说，AI 大模型可以做设备运维知识库、质检报告自动生成、工艺参数辅助决策，但这些场景要落地，必须懂业务逻辑、懂数据分布、懂用户使用习惯。 所以我的建议是：不要只学模型技术，要注重行业知识积累。 ## 4. 岗位对标与技术栈拆解 下面按岗位方向拆技术栈，每个方向给出核心技能和学习重点。 ### 4.1 大模型应用开发工程师 这是需求量最大的方向之一。核心职责是：基于大模型 API 或开源模型，完成业务功能开发，比如智能客服、文档问答、内容生成、信息抽取。 | 技能模块 | 具体内容 | | --- | --- | | 编程语言 | Python 为主，JavaScript/TypeScript 做前端或 Node 服务也常用 | | API 调用 | OpenAI 兼容接口、模型参数调优、流式输出 | | 应用框架 | FastAPI、Flask，或者 LangChain、LlamaIndex | | 向量数据库 | Chroma、Milvus、Weaviate、ES 向量检索 | | 前端/交互 | Streamlit、Gradio 快速搭建演示，正式产品接 Web 前端 | | 工程化 | Docker 部署、日志、监控、成本统计 | ### 4.2 Agent 开发工程师 Agent 比普通应用更进一步：它能根据用户目标，自己规划步骤、调用外部工具、查看结果、调整策略，完成多步任务。 | 技能模块 | 具体内容 | | --- | --- | | Agent 框架 | LangGraph、AutoGen、Dify、Coze、字节跳动 Coze、百度 AppBuilder | | 工具调用 | Function Calling、OpenAPI 工具注册、代码解释器 | | 记忆与状态 | 短期记忆、长期记忆、对话状态管理 | | 任务编排 | 单 Agent、多 Agent、人机协同、任务超时与回退 | | 可靠性 | 工具返回异常处理、循环检测、成本与 Token 控制 | Agent 方向的坑比较多，比如模型在长任务里容易被“带偏”、工具调用链断裂、Token 成本不可控。能把这些坑解决好的人，价值很高。 ### 4.3 RAG 知识库工程师 知识库方向在企业落地非常广，尤其是文档解析和 OCR 相关能力。搜索热词里也有 `信创 ai大模型 文档解析 ocr`，说明这块需求很明确。 | 技能模块 | 具体内容 | | --- | --- | | 文档解析 | PDF 解析、表格抽取、OCR 识别、版面分析 | | 文本处理 | 清洗、去重、切片策略、小标题识别 | | 向量化 | Embedding 模型选型、向量维度、批量入库 | | 检索优化 | 混合检索、重排、rerank、召回率评估 | | 评测 | 构造测试集，评估回答准确率、检索命中率 | | 部署 | Docker、API 服务、向量数据库运维 | ### 4.4 本地部署与推理优化工程师 当企业因为数据安全或合规要求不愿意把数据传到云端 API 时，就需要本地部署开源大模型。 | 技能模块 | 具体内容 | | --- | --- | | 模型选型 | 按显存和业务需求选择 7B、13B、32B、70B 等不同规模模型 | | 量化 | GPTQ、AWQ、GGUF 量化，理解 Q4、Q8 等精度含义 | | 推理引擎 | vLLM、Ollama、llama.cpp、TensorRT-LLM | | 显卡环境 | CUDA 版本、显卡驱动、显存与批处理大小关系 | | 服务封装 | OpenAI 兼容 API、并发控制、流式输出 | | 运维 | GPU 监控、模型热更新、多模型路由 | 本地部署需要关注的实际问题：模型量化后效果损失多少、并发多高、显存多大、响应延迟能否接受。如果只是本地跑起来，难度不大；但要达到生产可用，需要做细致调优。 ### 4.5 AI 平台工程师与 MLOps 当公司里多个业务线都在用 AI 时，会需要统一接入层、统一鉴权、统一成本核算。这是 AI 平台工程师的活。 | 技能模块 | 具体内容 | | --- | --- | | 网关与路由 | 多模型统一接入、负载均衡、限流熔断 | | 资源管理 | GPU 资源池化、任务排队、弹性伸缩 | | 成本监控 | Token 计费、按部门分摊、用量报表 | | 模型管理 | 模型版本管理、灰度发布、回滚 | | 可观测 | 调用链追踪、日志告警、效果监控 | ## 5. 从传统程序员转型 AI 应用开发的可执行路线 如果现在只会 Spring Boot 或只会 Vue，建议按下面的顺序从零到一转型，不绕路。 ### 5.1 阶段一：补 Python 与 API 基础 Python 是 AI 应用开发的事实标准。不要求精通到源码级别，但至少要会：数据类型、函数、类、文件读写、requests 库、json 处理、基本异常处理。 能独立写一个调用大模型 API 的 Python 脚本，并且处理返回 JSON，就算过关。 ### 5.2 阶段二：跑通 Prompt 工程与大模型 API 用 OpenAI 兼容接口或国内大模型 API，写一个简单的对话机器人，要求能实现： - 多轮对话 - 角色设定 - 输出结构化 JSON - 流式输出 - 异常重试 这一步的目标不是“能跑”，而是“能控制输出格式”。实际生产中，模型输出不稳定是常态，所以要用 Prompt 约束加代码校验。 ### 5.3 阶段三：做一个 RAG 知识库项目 自己找一批文档，做一个本地知识库问答系统。技术选型可以用 Ollama 跑一个 7B/8B 模型，用 Chroma 做向量库，用 LangChain 或者自己写一个简化版 RAG 流程。 要能回答：为什么我的 PDF 里检索不到内容？怎么切分文档？Embedding 选什么模型？如何评估回答质量？ 这部分建议看上海交大开源教程《动手学大模型》，对从零搭建大模型应用帮助很大。 ### 5.4 阶段四：完成一个 Agent 项目 做一个有实际业务价值的 Agent，例如： - 自动查天气并提醒穿衣 - 自动解析用户上传的 Excel 并生成分析报告 - 自动在内部 Wiki 中搜索资料并汇总 要掌握：Function Calling 如何定义工具、Agent 如何决定调用哪个工具、工具返回异常如何处理、如何防止死循环。 ### 5.5 阶段五：本地部署与性能优化 找一台常规显卡机器，把开源模型本地跑起来，然后做这几件事： - 看显存占用，理解上下文长度和批处理大小对显存的影响 - 尝试 GGUF 量化，对比不同量化等级下的效果和速度 - 用 GPU 推理和 CPU 推理做对比 - 封装成 OpenAI 兼容 API 服务 到这里，你已经不是“只会调 API”的程序员了，而是能把模型私有化、稳定化、工程化的工程师。 ## 6. 实际开发中的代码示例 下面给出一套在开发中高频复用的大模型应用代码模板。 ### 6.1 通用 API 调用模板 ```python import requests import json import time # 通用大模型 API 调用，接口路径和参数请按实际项目替换 API_URL = "https://your-api-endpoint/v1/chat/completions" API_KEY = "your-api-key" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个企业知识库助手，请基于给定资料回答用户问题。"}, {"role": "user", "content": "请总结这篇文档的核心内容。"} ], "temperature": 0.3, "stream": False } def chat_completion(payload: dict, max_retries: int = 3) -> dict: for attempt in range(max_retries): try: resp = requests.post(API_URL, headers=headers, json=payload, timeout=120) resp.raise_for_status() return resp.json() except requests.exceptions.Timeout: print(f"[{attempt + 1}] 请求超时，正在重试...") time.sleep(2 ** attempt) except requests.exceptions.RequestException as e: print(f"[{attempt + 1}] 请求失败: {e}") time.sleep(2 ** attempt) raise RuntimeError("API 调用超过最大重试次数") if __name__ == "__main__": result = chat_completion(payload) print(json.dumps(result, ensure_ascii=False, indent=2))这个模板已经包含了超时和重试机制。实际项目中，建议把API_URL、API_KEY、模型名配置到环境变量或配置中心，不要硬编码。
6.2 流式输出示例
对话类应用通常需要用流式输出，提升用户体验。
import requests API_URL = "https://your-api-endpoint/v1/chat/completions" API_KEY = "your-api-key" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } payload = { "model": "your-model-name", "messages": [ {"role": "user", "content": "用 50 个字解释什么是 RAG。"} ], "stream": True } with requests.post(API_URL, headers=headers, json=payload, stream=True, timeout=120) as resp: resp.raise_for_status() for line in resp.iter_lines(): if not line: continue line = line.decode("utf-8") if line.startswith("data:"): data = line[5:].strip() if data == "[DONE]": break # 这里按 SSE 格式解析，具体字段以实际接口为准 print(data)6.3 批量任务处理模板
企业里做批量文档分析、批量内容生成很常见。建议用目录加队列的方式：
. ├── inputs/ # 待处理文件目录 │ ├── doc1.pdf │ ├── doc2.pdf │ └── doc3.pdf ├── outputs/ # 处理后输出目录 │ ├── doc1.md │ ├── doc2.md │ └── doc3.md ├── failed/ # 失败任务记录 ├── tasks.json # 任务清单 └── run_batch.py # 批量处理脚本import os import json from pathlib import Path INPUT_DIR = Path("./inputs") OUTPUT_DIR = Path("./outputs") FAILED_DIR = Path("./failed") OUTPUT_DIR.mkdir(exist_ok=True) FAILED_DIR.mkdir(exist_ok=True) def process_file(file_path: Path) -> str: """ 处理单个文件，返回处理结果。 具体逻辑需要按项目替换：可以是文档解析、摘要生成、OCR 识别等。 """ # 示例：这里只做读取和简单处理 content = file_path.read_text(encoding="utf-8", errors="ignore") # 调用大模型接口生成摘要 # result = chat_completion(...) return f"processed: {file_path.name}" def main(): result = {"success": [], "failed": []} for file_path in INPUT_DIR.iterdir(): if not file_path.is_file(): continue try: output = process_file(file_path) output_file = OUTPUT_DIR / f"{file_path.stem}.md" output_file.write_text(output, encoding="utf-8") result["success"].append(file_path.name) print(f"[OK] {file_path.name}") except Exception as e: result["failed"].append({"file": file_path.name, "error": str(e)}) print(f"[FAIL] {file_path.name}: {e}") with open("tasks_result.json", "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2) if __name__ == "__main__": main()批量任务最重要的是可追踪：哪些成功、哪些失败、失败原因是什么。所以不要只打印日志，一定要把任务结果输出成一个 JSON。
6.4 RAG 检索增强生成流程示例
from typing import List # 简化版 RAG 流程，仅展示核心逻辑 class SimpleRAG: def __init__(self, embed_model, vector_store, llm): self.embed_model = embed_model self.vector_store = vector_store self.llm = llm def add_document(self, text: str, doc_id: str): # 先切片，再向量化，再入库 chunks = self._split_text(text, chunk_size=500, overlap=50) for idx, chunk in enumerate(chunks): vector = self.embed_model.embed(chunk) self.vector_store.add( id=f"{doc_id}_{idx}", vector=vector, text=chunk, metadata={"doc_id": doc_id, "chunk_index": idx} ) def query(self, question: str, top_k: int = 3) -> str: # 先向量化用户问题 query_vector = self.embed_model.embed(question) # 检索最相似的文档切片 candidates = self.vector_store.search(query_vector, top_k=top_k) # 组装上下文 context = "\n\n".join([c.text for c in candidates]) # 交给大模型生成回答 prompt = f"""你是企业内部知识库助手，请根据下面资料回答问题。 资料： {context} 问题： {question} 如果资料中没有相关内容，请明确回答“资料中未找到相关信息”。 """ return self.llm.chat(prompt) def _split_text(self, text: str, chunk_size: int = 500, overlap: int = 50): # 简单的按长度切片，实际项目建议按段落、标题层级切分 chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) start = end - overlap return chunks实际项目中，RAG 的切片策略非常影响效果。同一个文档，按 200 字切和按 800 字切，检索结果可以差很多。建议先拿真实文档做小批量试验，对比不同切片长度和 overlap 的召回效果。
7. 本地部署与推理性能观察思路
不少程序员在学 AI 时会接触到本地部署。这里说几个通用观察点，不针对某一款工具，适用于大多数本地大模型推理场景。
7.1 看显存占用
用nvidia-smi看显存占用是最直接的方式。
nvidia-smi更建议开一个实时监控：
watch -n 1 nvidia-smi然后发起一个推理请求，观察模型加载前后显存变化。这里要说明：不同模型、不同量化精度、不同上下文长度下显存占用差异很大，不要轻信别人给的固定数字，要以本机实际观察为准。
7.2 理解量化与精度
本地部署时，GGUF、GPTQ、AWQ 是常见量化方案。量化后模型体积变小、推理变快、显存占用降低，但输出质量会有一定损失。在低显存显卡上跑 7B 或 14B 模型，通常需要量化；如果是企业生产环境，要综合评估量化的质量损失，不能只看显存够不够。
7.3 CPU 与 GPU 推理差异
CPU 推理慢，但部署简单、不需要额外显卡资源，适合演示和低频场景。GPU 推理快，但需要显存足够。实际部署时，要考虑并发数、响应时间要求、显卡资源成本，再决定用哪种方式。
7.4 性能优化思路
- 降低上下文长度，减少不必要的历史消息。
- 使用流式输出，降低首字延迟的感知。
- 并发请求做队列控制，避免打满显存后 OOM。
- 对高频请求做缓存，减少重复计算。
- 根据实际显卡选择量化等级，不要无脑上 4bit。
- 用 OpenAI 兼容 API 做统一入口，方便后续切换模型。
8. 常见误区与排查方法
8.1 误区：大模型是万能的，不用做工程
实际上，企业落地大模型最缺的就是工程化能力。模型输出不稳定、上下文超限、Token 成本不可控、响应延迟高，这些问题都要靠工程手段解决。只调 API 写 demo 很简单，做到生产可用很难。
8.2 误区：只要会 Prompt 就够了
Prompt 工程是起点，不是终点。理解业务、设计评估集、调优 RAG、优化性能，这些才是拉开差距的地方。
8.3 误区：本地部署等于 Ollama 跑一个模型
Ollama 跑起来一个模型只是开始。生产环境还要考虑：并发控制、日志监控、模型切换、数据安全、版本管理、成本统计。这些都是传统后端架构能力的新应用场景。
8.4 常见问题的排查表格
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| API 调用超时 | 网络不稳定或模型响应太慢 | 检查日志和请求耗时 | 增加超时时间，使用流式输出 |
| API 返回空内容 | 触发内容安全过滤或参数错误 | 检查返回状态码和错误信息 | 调整输入文本，检查模型参数 |
| 模型输出格式不稳定 | Prompt 约束不够明确 | 多次测试输出格式 | 增加 few-shot 示例，加代码解析兜底 |
| RAG 检索不到内容 | 文档切分策略不合理或 Embedding 模型不匹配 | 检查召回结果 | 调整切片大小，更换 Embedding 模型 |
| 本地推理显存不足 | 模型太大或并发太高 | 查看 nvidia-smi | 使用量化模型，限制并发，降低上下文长度 |
| Agent 任务卡住 | 工具调用链断裂或死循环 | 查看调用日志 | 添加工具超时、循环检测、人工审批节点 |
| 批量任务失败 | 单个文件格式异常或 API 限流 | 查看任务结果 JSON | 增加重试机制，跳过异常文件，记录失败原因 |
9. 最佳实践与使用建议
结合行业落地情况，给出几条比较实用的建议。
9.1 先从最小场景跑通
不要一上来就搭一个包含所有功能的 Agent 平台。先选择一个业务痛点，比如“自动生成会议纪要”“文档问答”“工单自动分类”，用最小模型 API 跑通，再逐步加复杂度。
9.2 建立评估集
做 AI 应用最容易犯的错误是“凭感觉觉得效果不错”。正确做法是准备一个测试集，包含典型问题和边界情况，每次改动后跑一遍，看准确率、格式正确率、检索命中率有没有变化。这样效果是可回归的。
9.3 控制成本与 Token 消耗
企业落地时，成本是一项硬指标。建议做好这几个动作：设置调用上限、对长文本做摘要后再送入模型、缓存重复问题的高频答案、对模型输出长度做限制。
9.4 合规与隐私边界
涉及生成内容、知识库、用户数据时，一定要关注隐私保护和版权授权。企业知识库里的文档、对话记录、用户画像，都不能随意上传到第三方模型服务。必要时需要选择本地部署或私有化方案。
涉及人脸、声音、版权素材等场景，更要确认授权范围。生成内容和数据使用必须在合法合规范围内测试和应用。
9.5 持续跟进开源社区
开源社区迭代非常快。比如本地部署工具几乎每个月都有新版本，模型效果也在持续提升。保持关注，但不要盲目追新。生产环境用稳定版本，新功能先在测试环境验证。
10. 总结与下一步
这篇内容的核心观点可以压缩成三句话：
第一，AI 大模型时代，程序员的核心竞争力不在“会用某个框架”，而在“能解决具体业务问题”。大模型只是手段，工程化落地能力才是门槛。
第二，市场需求从“训练模型”转向“应用开发与场景适配”。RAG、Agent、本地部署、知识库、效果评测，这些方向都值得投入学习。
第三，转型路径是清晰的：Python 和 API 基础 → Prompt 工程 → RAG 知识库 → Agent 开发 → 本地部署优化。每完成一个阶段，都做一个可演示的项目，形成自己的作品集。
如果你现在还在纠结学什么，就从“调通一个大模型 API、做一个 RAG 问答、写一个 Agent 调用工具”开始。这三件事做完，你对 AI 大模型应用开发基本就有体感了。
下一步可以做的事：
- 注册一个大模型 API，写一个多轮对话脚本。
- 收集 20 篇行业文档，做一个本地知识库回答系统。
- 用 Function Calling 做一个能调用搜索或计算工具的 Agent。
- 如果有机器和显卡，尝试本地部署一个量化模型并对比效果。
大模型应用开发这个领域还处在早期，岗位需求和技能边界都在快速变化。但对程序员来说，这反而是机会：工程能力依然值钱，因为模型本身不能直接变成产品，能把它变成稳定、可控、可评估的业务功能，才是企业真正需要的能力。
