企业官网建设流程全解析

普通程序员转型大模型应用开发：先别慌，你手里的底牌比想象中多得多

这两年大模型的风向，几乎是把“转型”两个字怼到了每个程序员脸上。尤其是做传统业务开发的朋友，心里多少都有点打鼓：API 调包侠还有没有饭吃？CRUD 写久了，会不会哪天就被智能体端了饭碗？我身边确实有不少同事、同行在焦虑这个事，但老实说，真正开始动手转型的人很少，大部分还在观望。问我为什么知道？因为我就是从普通后端开发转过来的人，而且转过之后发现一个非常反直觉的事实——普通程序员做传统业务开发的那些经验，恰恰是大模型应用开发中最值钱的部分。

这篇文章不是什么理论科普，就是想告诉你：一个写了好几年业务代码、没碰过算法、也没跑过深度学习的普通程序员，到底该怎么一步步挪到大模型应用开发的轨道上来。我会按照自己的转型路径，拆成几个可执行的步骤，把每一步背后的为什么、怎么做、踩过什么坑都交代清楚。如果你正好在纠结“要不要转、怎么转”，这篇文章应该能帮你看清楚局面。方向对了，剩下就是时间问题。

1. 转型前的认知准备：先搞清楚“应用开发”和“算法研究”是两码事

很多人一想到转型大模型，脑子里就浮现出读论文、推公式、调 loss、跑 GPU 集群的场景，直接把自己劝退了。但我可以负责任地告诉你：大模型应用开发，跟你想象的那种算法岗完全是两条路线。你不需要从零开始啃 Transformer 的数学原理，也不需要自己训练模型。

1.1 大模型应用开发的真实工作内容

我可以先快速拆解一个典型的大模型应用，看看背后到底需要什么能力。比如做一个企业内部的知识库问答助手，看起来不过是一个问答界面，实际上它是这么拼起来的：

• 接入大模型的 API 或部署好的模型服务
• 写提示词：把用户问题加工成模型能更好回答的形式，约束格式、风格、边界
• 写检索逻辑：把企业文档切片、向量化、存到向量库里，查回来再塞给模型
• 编排流程：比如先判断意图，再决定要不要检索、要不要调外部工具
• 处理模型的输入输出，加缓存、做兜底、处理模型“胡说八道”的情况

看到没有？这里面真正需要“重新学”的只有提示词、检索这块，而且它们背后的工程本质——把数据处理好、把接口调通、把逻辑编排清楚——跟你写后端服务是高度相似的。你的接口设计经验、异常处理习惯、数据库思维、甚至是写单元测试的意识，在大模型应用开发里全部派得上用场。

1.2 为什么普通程序员的工程经验反而成了优势

这是我最想强调的一点。大模型应用开发这个领域，真正缺的不是懂模型的人，而是懂工程的人。道理很简单：模型本身是一个极强的能力源，但要把这个能力源在产品里落地，你需要做的是把它包装成稳定、可维护、可测试的服务——这件事，传统软件工程的方法论基本上是可以平移的。

比如我在转型过程中发现，自己在传统开发里养成的几个习惯，在大模型应用开发里被放大了价值：

• 拆解问题域的习惯。我习惯把一个复杂问题拆成模块去实现，面对一个大模型应用，我也习惯拆解成“生成、检索、记忆、工具调用”等模块，而不是把一堆逻辑塞进一个提示词里。
• 异常处理的敏感度。传统业务里我会处理接口超时、参数非法、数据缺失，到了大模型应用里，这些经验直接迁移过来面对模型的幻觉、超时、格式不合法。
• 测试意识。以前写单测是为了保住业务不出 bug，现在写评测用例是为了保住模型不改烂——本质是一样的。

所以我建议你现在就先调整一个心态：别再觉得“我不会算法”是致命短板。会算法的竞争对手可能还在烦恼怎么把工程做稳，而你的工程底子可以让你更快交付落地的东西，这在应用层是决定性优势。

2. 第一步必杀技：提示词工程，零成本切入大模型开发的第一道门

提示词工程是目前门槛最低、见效最快、也最容易帮普通程序员建立信心的大模型开发技能。它不需要你装环境、不需要你租卡，只需要你打开任意一个大模型的对话窗口，就能开始练。很多人觉得提示词就是“跟 AI 说话”，不值得当个技能去学，这是大错特错。我后面踩的坑至少有三分之一跟提示词的质量有关。

2.1 提示词不是“说话”，是“给模型写需求文档”

我后来总结了一个更容易理解的说法：写提示词，本质上就是给一个能力超强但记忆力差、容易脑补、情绪不稳定的实习生写需求文档。你不会只丢一句“把这事办了”给实习生对吧？你一定会交代背景、目标、约束条件、输入输出格式、注意事项。写提示词也一样。

一个好的提示词，尤其是用在应用里的那种，至少应该包含这四块：

• 角色设定：告诉模型“你是什么”，比如“你是一个资深的售后客服，擅长用简洁友好的口吻解答问题”。
• 任务目标：明确这次调用要完成什么，比如“根据提供的售后政策文档，回答用户的赔付问题”。
• 输入内容：把需要模型处理的信息用明确的标签包起来，比如用 XML 标签包裹用户问题和文档片段。
• 输出约束：规定格式、长度、风格、引用要求，比如“如果文档中没有答案，直接回复‘未找到相关信息’，不要推测”。

我刚开始转型时写过一条很经典的失败提示词，大概是“帮我写一个活动文案”，结果模型给了我一篇辞藻华丽但完全不能用的东西。后来我改成：

你是一个电商运营专家，擅长写促销活动文案。 请根据以下商品信息和活动主题，写一篇不超过300字的公众号推文。 要求：口语化，有吸引力，突出性价比，结尾带行动引导。 商品信息：{{商品}} 活动主题：{{主题}}

同样一个模型、同样一个意图，因为提示词的结构不一样，产出的质量天差地别。这就是提示词工程的本质——把你的业务理解、格式要求、判断标准，翻译成模型能理解的语言。

2.2 提示词工程中必学的三个底层技巧

技巧一：用“思维链”引导模型做推理。当你需要模型完成复杂的推理任务（比如分析一段对话中的用户意图），不要只给问题，要引导模型“先思考，再回答”。你可以直接在提示词里写明“请按照以下步骤推理：1. 提取用户表达的核心诉求；2. 判断诉求类型；3. 给出回答”。这比直接让模型给结论准得多。

技巧二：用“few-shot”示例法约束输出风格。如果你需要模型输出特定格式的 JSON 或特定风格的文字，不要只描述你要什么，直接给它一两个输入输出配对的示例，模型的模仿能力很强，给示例比给描述管用得多。

技巧三：把“不能做什么”写进去。人们容易只写“要什么”，忘了写“不要什么”。比如你不希望模型在不知道答案时编造，就明确写“如果信息不足，请回答‘信息不足’”；你不希望回答过于专业晦涩，就写“请用小学六年级学生能听懂的语言解释”。负面约束在很多时候比正面要求更重要。

我要特别提醒你：提示词工程不是“会写”就行，而是要“会测”。同一个提示词，换一个模型版本，产出的结果可能就不一样了。所以严格意义上，提示词工程要求你有迭代意识——写一版、测几轮、发现问题、改一版。这套迭代方法论，跟你在传统开发里调接口、改参数是一个逻辑。

3. 第二步关键技能：函数调用与工具使用

如果提示词工程是入门，那函数调用（Function Calling / Tool Use）就是普通程序员真正发挥工程优势的地方。因为它是把大模型从一个“只会聊天的生成器”变成一个“能干活的任务执行器”的关键一步，而这背后的思路对资深程序员来说几乎是天然熟悉的——把模型当成一个会做意图识别和决策的工具分发器。

3.1 理解函数调用的运作机制

传统程序里，逻辑是你写死的：用户点这个按钮，就执行这个函数。但在大模型应用里，用户的输入是开放的、无法枚举的，你不能预判每个人都会用哪种句式提出需求。函数调用的思路就变成：模型负责理解用户意图，并把意图翻译成对指定函数的一次调用请求。

举个最简单的例子。你想做一个能查天气的对话机器人，传统做法是：

• 用户输入“北京天气”，你用正则或关键词匹配，命中“天气”就把城市参数传进去

这个做法在表达方式稍微变化一下（比如用户说“北京那边今天冷不冷？”）就失灵了。而函数调用的做法是：

• 你定义了一个get_weather(city: string)函数，告诉模型“当用户询问天气相关问题时，调用该函数，并从对话中提取城市参数”
• 模型判断用户输入“北京那边今天冷不冷？”是一个天气查询意图，于是返回一个结构化的请求：调用get_weather(city="北京")
• 你的代码收到这个请求后，执行真实的天气 API 调用，再把结果返回给模型，模型组织成自然语言回答用户

你会发现，模型在这里扮演的角色，本质上是一个“意图识别 + 参数抽取”的调度器。而调度器的活，对后端工程师来说不要太熟悉。

3.2 设计函数定义的最佳实践

大多数主流大模型平台都支持 JSON Schema 风格的工具定义。实际操作中，我会推荐你按这样的格式去定义工具：

{ "name": "get_weather", "description": "查询指定城市当前天气情况，当用户询问天气、温度、降雨等话题时使用", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，如北京、上海" } }, "required": ["city"] } }

这里有几个看起来不重要但实际影响很大的细节：

• description 一定要写清楚“何时使用”。模型是靠 description 来判断要不要调用这个函数的，你要是只写“查询城市天气”，模型在用户问“今天要带伞吗”时就不一定联想到调用；但如果你写“当用户询问天气、降雨、出行带伞建议等话题时使用”，模型的判断准确率会明显提升。这本质上是把提示词优化的经验迁移到了工具描述上。
• 参数描述要够细。你要把每个参数的含义、格式、允许的值域说清楚，否则模型可能给你传个“明天”作为城市名。该加枚举就加枚举，该加格式说明就加格式说明。
• 函数数量一次别太多。模型在大量工具之间做选择时，准确率会下降。我实测下来的经验是，一次给模型可选的工具最多控制在 8~10 个以内，如果业务工具很多，要先做一层意图粗分类，分路由到不同的子模块，而不是一次性把所有工具全抛给模型。

3.3 为什么函数调用对普通程序员来说是大机会

因为函数调用让“后端 CRUD 工程师”的能力模型跟大模型开发完美接上了。你不需要研究模型是怎么思考的，你只需要设计好“模型能用的 API 列表”——这不就是你做后端接口设计的工作吗？只不过调用方从“前端”变成了“模型”。

我第一次在项目里把函数调用跑通时的感受是：原来如此，这不就是我做了一百遍的外部接口对接吗。把函数定义好，处理一下模型返回的调用请求，执行逻辑，把结果回传，加一点上下文管理——整个流程，跟我以前写一个短信服务对接、第三方支付对接没有本质区别。

这一章我必须再补一刀：函数调用是你从“用 AI 聊天”走向“用 AI 干活”的分水岭。一个只会聊天的应用，用户玩两次就腻了；但一个能调用你的系统、查询你的数据库、执行真实操作的 AI 助手，才是企业愿意付费的东西。而这个能力，恰恰需要工程经验来支撑。

4. 第三步核心技术：RAG 与向量数据库

如果说提示词工程和函数调用是“把模型用好”，那 RAG（检索增强生成）就是“让模型知道那些它本来不知道的东西”。这也是目前大模型应用开发中最实用、最落地、企业需求最强烈的技术方向。它解决的痛点是：通用大模型没有读过你的私有知识，比如你的企业内部文档、你的行业知识库、你产品的 FAQ。

4.1 RAG 解决的是什么问题

先把这个场景说明白。你让通用大模型写一篇周报，它写得很好，因为网上有海量周报素材。但你如果问它“我们公司食堂几号搬迁”或者“这台设备报错 X 代码该按哪个顺序排查”，它一定答不上来，因为它的训练数据里根本没有这条信息。它唯一能做的，就是编一个看上去很像样的答案——这就是所谓的“一本正经地胡说八道”。

RAG 的思路分三块：

1. 预处理：把你的私有文档切分成小块，对每块做向量化，存到向量数据库里。
2. 检索：收到用户问题后，把问题也向量化，去向量库里找语义上最相关的若干文本块。
3. 生成：把检索到的文本块和用户问题一起交给大模型，让模型基于这些资料来回答。

本质上，RAG 是给模型开卷考试。你不再要求它“背出”所有知识，而是允许它“查资料”再作答。这样既解决了知识时效性和私有性的问题，又大幅降低了幻觉的概率。

4.2 从零搭一套 RAG 需要做哪些事

把一个 RAG Demo 搭建出来，按当前的生态来看其实很简单，甚至 30 分钟内就能跑通。但要做好、用在生产环境，那是一条很深的沟。我先按最小可运行方案拆解：

第一步，文档加载与切分。把 PDF、Word、Markdown 等文档读出来，切成一段一段。切分是 RAG 里最容易被低估的技术活。

• 切太长，比如一整个章节塞一段，会导致检索命中后噪声太大，模型被无关内容带偏；
• 切太短，语义会不完整，比如把一个知识点的“前提”和“结论”切开，模型检索到的只是片段，回答就会断章取义。

我的经验是，切分长度不能只看“字符数”这个硬指标，还要结合文档本身的结构来做。比如对技术文档，按 Markdown 标题层级切，效果往往比按固定 500 字切更好。文字密度高的语料，切小段一点；对话流类的数据，最好按轮次切。

第二步，向量化。把文本块变成向量，需要一个嵌入模型（Embedding Model）。这里的选择也很关键——你可以用大模型厂商提供的向量化接口，也可以本地部署开源嵌入模型。

嵌入模型的选择决定了检索质量的上限。我会建议至少对比两三个不同的嵌入模型，用一批真实业务问题去测试检索效果，不要只凭“魔塔社区下载量高”就拍板。我认识不少朋友是用着用着发现，某嵌入模型对英文效果好，换成中文业务语料就拉胯了——这个坑太常见了。

第三步，存储与检索。现在可用于 RAG 的数据库非常多，从专门的向量数据库，到支持向量索引的传统数据库，再到云厂商托管方案，都有。选型的时候不要只看微信文章里的“排行榜”，要看自己的场景：

• 数据量不大、想快速验证的，可以用轻量方案
• 数据量几百 G 甚至更多，还要高并发线上服务的，要选支撑大规模检索的分布式方案
• 如果企业已有 PostgreSQL 之类的传统库，配合 pgvector 这类插件也能实现“少引入一套组件”的效果

第四步，生成。把检索到的相关片段拼进提示词，交给大模型组织答案。这里有个细节：不是所有检索到的片段都要塞给模型。很多实现里会做一个“相关性过滤”（score threshold 排序、重排），因为低质量的检索结果一旦进入生成阶段，反而会干扰输出。

4.3 RAG 效果调优的实操心得

我踩过最深的坑是，一开始以为 RAG 效果不好是“模型不够强”，后来发现 90% 的问题出在检索环节。模型再强，检索回来的资料驴唇不对马嘴，它也没法给你好答案。所以 RAG 调优的主战场在检索，而不在生成。下面是我比较常用的排查顺序：

• 先看检索回来的 Top5 片段跟问题相关度如何，如果相关度就不行，查切分粒度、查嵌入模型、查查询方式；
• 再试对用户问题做改写、扩充（比如把缩写展开、补全上下文，再拿改写后的文本去检索），这一步往往能明显提升召回率；
• 紧接着看是否需要加入重排模型（Reranker），用一个交叉编码器对初步召回的片段做更精细的排序，成本大了点但效果一般很明显；
• 最后再考虑调整提示词里对资料的组织方式。

另外再提一个反直觉的经验：不只在 RAG 搭建初期要测试检索效果，而是每换一次嵌入模型、每改一次文档切分逻辑，都应该把用例拿来重跑一遍。因为你会发现，某个看起来更智能的嵌入模型，替换后对某些特定领域词汇的检索效果反而会下降。语义检索这个东西没有银弹，只有持续回归测试才能兜底。

5. 第四步工程化实践：从 Demo 到可上线的完整链路

很多人转型过程中最大的错觉是：跑通了一个 Demo，等于会了大模型开发。实际上，Demo 和可上线的应用之间，隔着很多传统工程问题——这一点普通程序员有天然优势，因为你知道要考虑稳定性、并发、监控、成本。在大模型开发里，这层工程化能力反而变得极其稀缺。

5.1 大模型应用的完整组成

我来画一个真实落地项目的组成地图。虽然不能用图，但可以把常见的模块列清楚：

• 接入层：对上层应用提供 API 接口，通常会有一个统一的网关服务，屏蔽底层模型供应商的切换变化。
• 编排层：负责实现业务逻辑的编排，是大模型应用的“大脑”。判断意图，决定走纯对话、RAG 检索、还是调用工具；多个步骤之间怎么衔接；上下文怎么维护。
• 数据层：包括向量数据库、业务数据库、缓存、知识库文件存储。
• 模型层：可以是多模型组合——对话模型、嵌入模型、重排模型，加上模型服务网关做负载均衡和超时控制。
• 运维与安全层：日志、监控、成本追踪、内容安全过滤、数据权限管理。

你从一个普通后端开发的角度一看就明白了，这就是一个典型的多层服务架构。唯一的区别是，原来的“业务逻辑实现在代码里”，现在有一部分“业务逻辑实现在提示词和编排配置里”——这是最大的思维变化点。

5.2 普通开发者转型必须补齐的三个工程能力

第一，结构化输出能力。你会经常需要让模型输出 JSON 而不是自然语言。不要依赖模型“默认”输出正确 JSON，要在提示词里给定 Schema、用 JSON Mode 或结构化输出的接口、代码里加解析异常兜底。以前后端接口返回的数据结构是你定的，现在模型产出的结构你是靠“引导 + 强校验”拿到的，两者套路不同，但校验的意识相同。

第二，成本与超时控制能力。模型的调用成本不像传统接口那么便宜，一次长文字生成可能消耗大量的 Token，并发一高，成本瞬间飞涨。你要在设计阶段就考虑：

• 用缓存减少重复调用（相同问题的答案直接命中缓存）
• 用模型降级策略（复杂模型超时或失败时降级到便宜模型）
• 给模型输出做 Token 上限清理（能少输出就少输出）
• 评估模型输入里塞了多少无关上下文（塞得越多越贵）

第三，效果回归测试能力。传统开发里你写单元测试断言输出；大模型应用里输出是概率性的，不能简单断言“等于”。所以你要建一个“评测集”，把典型用户问题整理成几十上百条用例，每次改动提示词或模型版本，都拿评测集跑一遍，用规则或者更强的模型打分来判断效果有没有退化。这不是可选项，那种靠肉眼在对话框里试的效果回归，等模型一换版本就全面崩坏，而你还浑然不觉。

5.3 建议的首次实战项目选择

转型这件事，光看书看文章没用，必须有一个自己能从头到尾做完的项目。但我强烈不建议你第一步就做一个面向 C 端的聊天机器人——太泛了，做完你也不知道自己会了什么。我比较推荐可以选一类有明确业务边界的助手，然后把 RAG、函数调用、工程化全链路都串起来。比如：

• 企业内部知识库问答助手
• 私有数据报表分析助手（让模型帮你查数据库并把结果转成图表描述）
• 客服工单自动回复与分类助手

选项目就记住一句话：项目要小到你能一个人做完，又要大到能覆盖“四个能力”——提示词设计、函数调用、RAG、工程化部署。做完这个项目，你才算是真的摸到了大模型应用开发的门。

6. 常见问题与避坑实录：这些坑我都替你踩过了

转型过程里会遇到很多让人怀疑人生的问题，我挑几个最典型的写出来，希望能帮你在没踩坑之前就把坑绕开。

6.1 模型“不听话”怎么办

“我提示词写得很清楚了，它为什么不按我说的做？”这个问题几乎所有人都会遇到。我现在的处理方式是别急着怪模型，先自查这几项：

• 提示词里有没有明确的“输出格式”示范？光说“按 JSON 输出”不如直接给一个 JSON 示例
• 有没有把约束写在最后？实践下来，模型对提示词靠前和靠后的内容关注度都偏高，中间段容易被忽略
• 是不是温度参数（temperature）设太高了？生产环境的要求是要稳定，温度通常要调到 0.2 甚至更低，而不是默认的 1.0
• 是不是这个任务本身超出了模型能力？那就换成能力更强的模型或拆分任务，不要在一个模型上死磕

6.2 检索不到想要的内容怎么办

如果你测试 RAG 时经常发现“明明库里有这个内容，但答不上来”，大概率不是模型的问题，而是检索链路的问题。按这个顺序排查：

1. 直接看召回的 TopK 片段里有没有相关的内容，没有就说明第一步就歪了
2. 检查切分方式，是不是把一个完整知识点切得过于零碎
3. 换一个嵌入模型做对比实验，很多情况下只是嵌入模型对你这套业务词汇不敏感
4. 试一下加一个重排模型（Reranker），把招回的 top 20 重新排序再取 top5，精度会有可感知的提升

6.3 上下文爆掉（Context Overflow）怎么办

大模型输入长度有限制，但很多人是在“多次对话”场景里，每一次都把整个历史记录一股脑塞给模型，没聊几轮就把窗口塞满了。解决办法不复杂：

• 给历史消息设上限，比如只保留最近 10 轮
• 做“摘要压缩”，把更早的历史先让模型总结成要点，再拼接进对话
• 对长文档用 RAG 按需检索，而不是把整本手册一次性塞进上下文

这类问题说白了还是传统工程的“资源管理”思维，只不过资源从“内存”变成了“上下文窗口”，本质没变。

6.4 模型幻觉问题

只要用大模型，幻觉就一定存在，只能缓解不能消除。我的主要策略是：能靠检索兜底的就靠检索；必须靠记忆的就明确告诉模型“只基于以下资料回答”；回答中需要引用原文的，就要求模型标注引用来源；代码层面对拿捏不准的答案，加一层“未匹配到资料则拒绝回答”的兜底逻辑。承认模型会犯错，并在系统层面兜住这个错，是应用开发者的责任。

6.5 关于“换模型”的决策焦虑

今天这个模型效果好，明天那个模型又出了新版本，天天换模型不现实。我的建议是：在应用架构上做好“模型层抽象”，屏蔽底层具体厂商。业务代码与模型解耦，后续随时能低成本切换、做 A/B 测试。模型换起来有多痛，取决于当时你把提示词跟代码耦合得有多深——我这里建议不要把提示词直接硬编码在业务逻辑里，而是抽成配置项或模板文件，想换模型时改配置就行。

7. 转型路线图与学习节奏：按周安排的可执行方案

讲了这么多方法论和坑，最后给一个落地的时间路线图。我是按大约 8~10 周的时间完成的转型，前面两周准备，中期五到六周集中做项目，最后两周做总结和拓展。你可以根据自己的节奏调整，但大体结构可以参考。

7.1 第 1 周：建立提示词直觉

• 目标：把提示词的结构化写法练成本能
• 每天至少写 10 条不同类型任务的提示词，主动包含角色、目标、输入、输出约束四要素
• 分别尝试 zero-shot、few-shot、思维链三种模式，体会不同写法对结果的影响
• 完成一个小的“提示词调优实验”：同一任务，用三版不同的提示词，记录模型输出的差异，总结规律

这里我说得直接一点：不要以为“看几篇文章就会写提示词”。提示词的功力完全靠练出来的，类似于写 SQL 一样，理解了 join 的概念和真正写出高效的查询是两回事。

7.2 第 2 周：熟悉开发框架与函数调用

• 目标：能写代码调通大模型 API，能实现函数调用的完整链路
• 找一个官方文档和代码示例最丰富的开源框架，先跑通里面所有官方示例
• 尝试自定义两个业务函数（比如查数据库、查第三方接口），用测试输入验证模型是否能正确触发调用
• 这一周不追求复杂的业务，重点是把“模型 ↔ 函数 ↔ 业务代码”的闭环跑通

语言和框架的选择我多说一句：如果你本来就有后端开发经验，优先用你熟悉的语言，不用为了“追新”专门换语言。大模型框架在各主流语言下都有很不错的支持，你熟 Java 就继续 Java，熟 Python 就直接 Python，不要在这个阶段加入“学新语言”的负担。

7.3 第 3~6 周：主导一个 RAG 项目

• 目标：从零搭一个 RAG 应用，并完成一轮质量调优
• 前三周把加载、切分、向量化、检索、生成的完整链路跑通，做一个能演示的版本
• 后两周集中做检索质量调优：对比不同切分策略、不同嵌入模型、是否加重排
• 把评测集建起来，至少准备 30 条真实用户问题，每次改动都回归一遍

这个阶段的最大挑战是“不要陷入完美主义”。RAG 永远有优化空间，你需要做的是先让链路完整转起来，然后再迭代。

7.4 第 7~8 周：工程化与上线准备

• 目标：把 Demo 变成可以被别人访问、可测试、可监控的“产品”
• 加接口封装、加缓存、加日志、加评测流程
• 设计好“模型降级”策略：模型调用失败或者超时，系统如何表现
• 写一份简单的部署文档，把项目部署到服务器上，让别人能用上

7.5 第 9 周之后：持续积累与方向拓展

转型完成之后的路径也很清晰：向智能体（Agent）方向发展，把多个工具调用编排成自动执行的复杂流程，再配合长期记忆和反思机制，实现更接近“数字员工”的效果。或者是深入垂直行业的项目，积累特定领域的知识库构建经验。无论走哪条，你已经有能力应对大模型应用开发的主战场了，剩下就是项目数量和时间的问题。

我个人的感受是，这个领域最大的魅力在于“迭代快”。以前做传统开发，一个系统上线后就基本固定了，而大模型应用可能每隔几周就会因为模型能力的升级而刷新一次体验上限。对我们这种从普通业务开发转过来的人来说，反而是回到了最舒服的状态：有不限量的新东西可学、可做、可怕踩完再爬起来。转型不难，难的是不再拿“我不会算法”给自己设限。