企业官网建设流程全解析

1. 从写业务代码到折腾模型，程序猿转型 AI 到底在转什么

干了七八年 Java 后端，CRUD 写得飞起，突然发现招聘 JD 上开始要求“熟悉大模型应用开发”“有 AI 工程化落地经验”，心里多少有点慌。这两年身边不少同行都在聊转型 AI 的事，有人已经跳进这个赛道拿到了不错的 offer，也有人买了一堆课、跑通了几个 demo，结果面试一问三不知。我自己是从两年前开始有意识地往 AI 方向靠，踩了不少坑，也攒了一些实在的经验，今天就把“程序猿转型 AI 必须知道的几件事”掰开揉碎聊一聊。

先说清楚一个前提：程序猿转型 AI，绝大多数人走的不是“去搞算法研究”这条路。你不是去跟科班博士卷 Transformer 结构改进，也不是去训一个千亿参数的基础模型。那条路门槛极高，需要扎实的数学功底和论文积累，对大部分业务开发出身的人来说性价比很低。真正适合程序猿的转型方向，是AI 应用开发、AI 工程化、大模型落地这一层——说白了，就是把大模型当成一个新的“基础设施”，用它来构建产品、解决业务问题。这个定位非常关键，它决定了你该学什么、不该学什么。

我见过太多人一上来就去啃《深度学习》花书、推导反向传播，啃了两个月放弃了，觉得自己不是这块料。其实方向就错了。你是一个工程师，你的核心价值在于工程能力——把不确定的东西做成稳定可用的系统。大模型本身有不确定性（幻觉、输出不稳定），怎么用工程手段把它约束住、让它可靠地服务于业务，这才是程序猿的主场。所以转型的第一件事，是重新定位自己：你不是要变成算法科学家，你是要变成“懂 AI 的工程师”。

那具体要懂哪些东西？我把它拆成几个层次。最底层是对大模型能力边界的认知——它擅长什么、不擅长什么、什么场景能用、什么场景是坑。往上一层是提示词工程和上下文管理——怎么跟模型“说话”才能拿到想要的结果。再往上是AI 应用架构——RAG、Agent、工具调用这些模式怎么组合。最上层是工程化落地——部署、成本、监控、评测、迭代。这几层不是孤立的，是层层递进的。很多人卡在第二层就以为自己在做 AI 了，结果做出来的东西只能 demo，上不了生产。

还有一个心态问题得说清楚。转型不是“推倒重来”，而是“能力叠加”。你原来会的 Java、Spring、数据库、分布式、系统设计，一样都没白学。恰恰相反，AI 应用落地最缺的就是既懂业务系统又懂 AI 的人。一个纯算法背景的人可能不知道怎么设计高并发的服务、怎么做灰度发布、怎么保证数据一致性；而这些正是你的强项。所以别妄自菲薄，你的存量能力是资产，不是包袱。转型的本质是在原有工程能力上，长出一块 AI 的新能力，而不是把原来的自己删掉重装。

我刚开始接触这块的时候，犯过一个典型错误：总想着“我要系统学习 AI”，于是列了一个巨大的学习清单，从线性代数到概率论到机器学习到深度学习，恨不得把计算机系的课重上一遍。结果就是进度极慢，学的东西跟实际工作脱节，越学越焦虑。后来我想明白了：以项目驱动学习，而不是以学科驱动学习。你想做一个智能客服，就去研究 RAG 和对话管理；你想做一个代码助手，就去研究提示词和工具调用。带着具体问题去学，效率高十倍，而且学完就能用。这个思路的转变，是我转型路上最重要的一个转折点。

2. 转型路上必须搞懂的核心技术点

2.1 提示词工程：不是玄学，是有章法的沟通

很多人对提示词工程有误解，觉得就是“跟 AI 聊天”，随便写写就行。真到生产环境你就知道，提示词写得好不好，效果能差出十万八千里。我做过一个信息抽取的任务，同样的模型，提示词改了三版，准确率从 60% 出头提到了 90% 以上。这不是玄学，是有方法论的。

核心原则我总结成几条。第一，角色和任务要明确。别上来就说“帮我处理一下这段文本”，模型不知道你是谁、要干什么。你得说“你是一个资深的合同审核助手，你的任务是从下面的合同文本中提取甲方、乙方、签约日期、金额四个字段，以 JSON 格式输出”。角色、任务、输出格式，三要素齐全，模型才知道往哪个方向使劲。

第二，给例子比讲道理管用。这叫 Few-shot，就是你在提示词里塞几个输入输出的示例。模型会照着例子的模式来。我做过实验，一个复杂的分类任务，光靠文字描述规则，模型经常理解偏；给三五个标注好的例子，准确率立刻上一个台阶。例子要覆盖边界情况，别只给简单的正例。

第三，把复杂任务拆开。别指望一个提示词解决所有问题。我见过有人写一个巨长的提示词，既要模型理解意图，又要检索知识，又要生成回答，还要控制格式，结果哪一块都做不好。正确的做法是拆成多个步骤，每一步一个提示词，前一步的输出作为后一步的输入。这叫 Chain of Thought 的工程化应用。虽然多调用几次模型会增加成本，但效果和可控性提升明显。

第四，输出格式要强约束。生产环境里，模型的输出是要被程序解析的，格式一乱整个链路就崩了。所以能用 JSON 就用 JSON，并且在提示词里明确要求“只输出 JSON，不要有任何其他文字”。有些模型支持结构化输出（比如 JSON mode），能用就用，比靠提示词约束靠谱得多。即便如此，解析的时候也要做容错，因为模型偶尔还是会“不听话”。

提示：提示词不是写完就完事了，它是要版本管理的。我习惯把提示词当成代码一样放在 Git 里，每次改动都记录效果变化。这样出了问题能回滚，效果提升能追溯。

2.2 RAG：让模型说“自己知道”的话

大模型有个致命问题：它的知识是训练时固化的，而且它会一本正经地胡说八道。你问它公司内部的产品文档，它要么不知道，要么编一个。RAG（检索增强生成）就是解决这个问题的核心方案。思路很朴素：先从知识库里检索出相关内容，再把内容和问题一起喂给模型，让它基于检索到的内容回答。这样模型就不用“凭记忆”了，而是“看着资料”回答。

RAG 听起来简单，做起来坑很多。第一个坑是文档切分。你把一篇长文档切成小块，切得好不好直接决定检索质量。切太大，检索出来的内容冗余，模型抓不住重点；切太小，上下文丢失，语义不完整。我的经验是，按语义切分比按固定字数切分好，比如按段落、按标题层级切。如果文档结构清晰，优先按结构切；如果是一大坨文本，那就得用滑动窗口加重叠的方式，保证边界信息不丢。

第二个坑是向量化和检索。文本要转成向量才能做语义检索，这就要选 embedding 模型。选型的时候要考虑语言支持（中文场景得选中文效果好的）、维度（维度高精度好但存储和计算成本高）、成本。检索的时候，纯向量检索有时候不如“向量+关键词”混合检索。因为向量检索擅长语义相似，但对精确匹配（比如产品型号、专有名词）不敏感。混合检索能兼顾两者，实测效果更稳。

第三个坑是重排序。初步检索出来的 Top-K 结果，未必都是最相关的。这时候可以加一个 rerank 模型，对候选结果重新打分排序，把最相关的排前面。这一步能明显提升最终效果，尤其是知识库大的时候。代价是多一次模型调用，延迟和成本都会增加，得权衡。

第四个坑是上下文组装。检索出来的内容怎么塞进提示词，也有讲究。塞太多，超出上下文窗口，而且模型容易被无关信息干扰；塞太少，信息不够。我的做法是控制检索结果的数量和总长度，并且给每段内容标上来源，让模型知道哪些是资料、哪些是问题。如果检索结果之间矛盾，还要在提示词里告诉模型怎么处理冲突。

2.3 Agent 与工具调用：让模型“动手干活”

光会聊天的大模型价值有限，真正有想象力的是让它能调用工具、执行动作。这就是 Agent 的核心。比如你问“帮我查一下明天北京的天气，如果下雨就提醒我带伞”，模型需要调用天气 API，拿到结果，再做判断。这个“调用工具”的能力，把大模型从“嘴炮”变成了“能干活”的助手。

工具调用的实现方式，主流的是 Function Calling。你在请求里定义好有哪些工具、每个工具的参数是什么，模型会根据用户的问题决定调不调用、调用哪个、参数填什么。然后你的程序执行这个工具，把结果再喂回给模型，模型生成最终回答。这个循环可以多轮，模型可以连续调用多个工具完成复杂任务。

做 Agent 最容易踩的坑是循环失控。模型可能陷入“调用工具→结果不满意→再调用→还不满意”的死循环，烧钱又耗时。所以必须设置最大轮次限制，超过就强制结束。另外，工具的幂等性要考虑，尤其是写操作（比如下单、发消息），模型可能重复调用，你得保证重复执行不会出问题。还有错误处理，工具调用失败是常态，网络超时、参数错误、权限不足都可能发生，你得让模型知道失败了，并且给它重试或者换方案的机会。

我个人的经验是，Agent 适合任务边界清晰、步骤可枚举的场景，比如“查数据→分析→生成报告”这种。对于开放式、需要大量探索的任务，Agent 目前还不够可靠，容易跑偏。别被 demo 里那些炫酷的自主 Agent 忽悠了，生产环境里，可控性比自主性重要得多。

2.4 模型部署与选型：不是越大越好

程序猿转型 AI，绕不开模型部署这个话题。是自己部署开源模型，还是调用云端 API？这是每个项目都要做的决策。我的判断逻辑是这样的：如果数据敏感、要求私有化、调用量大且稳定，考虑本地部署；如果追求效果、快速上线、调用量波动大，优先用 API。

本地部署开源模型，现在门槛已经低了很多。有 Ollama、vLLM 这类工具，拉个模型跑起来不算难。但“跑起来”和“跑得好”是两回事。你得考虑显存够不够、推理速度能不能接受、并发能力怎么样。一个 7B 的模型，量化之后消费级显卡能跑，但效果和云端的大模型差距明显。70B 级别的模型效果好了，但部署成本高，推理慢。所以选型的时候，先明确你的效果要求和成本预算，再倒推选什么模型。

我做过一个对比测试，同一个任务，用不同规模的模型跑，效果和成本的差异非常直观。小模型便宜快，但复杂任务容易出错；大模型效果好，但贵且慢。实际项目里，我经常用“大小模型配合”的策略：简单任务用小模型，复杂任务路由到大模型。这样能在效果和成本之间找到平衡点。

还有一个容易被忽视的点是推理框架的选择。同样的模型，用不同的推理框架，吞吐量能差好几倍。vLLM 的 PagedAttention 对吞吐提升明显，TensorRT-LLM 在特定硬件上性能更好。这些细节在 demo 阶段无所谓，但上了生产，直接关系到你的服务器成本和用户体验。

3. 一个完整的 AI 应用落地实操过程

3.1 需求拆解：先想清楚要解决什么问题

我拿一个真实做过的项目来串一遍流程。需求是给一家公司做一个内部知识问答助手，员工可以问产品、流程、制度相关的问题，系统基于内部文档回答。这个需求听起来简单，但拆解下来有不少门道。

首先要明确边界。这个助手只回答内部文档里有的内容，文档里没有的，要明确说“我不知道”，而不是瞎编。这一点必须在产品设计阶段就定死，否则用户问了个文档里没有的问题，模型编一个答案，反而造成误导。所以“拒答能力”是这个项目的核心指标之一，不是可有可无的。

其次要明确用户和场景。是给全员用的，还是给特定部门用的？问题类型是事实查询为主，还是需要推理分析？这决定了知识库怎么建、检索策略怎么定。我们这个项目是全员用，问题以事实查询为主，偶尔有流程性的问题，所以 RAG 是主力方案，不需要太复杂的 Agent 逻辑。

最后要明确成功标准。什么叫“做得好”？我们定了几个指标：回答准确率（人工抽检）、拒答准确率（该拒的拒、不该拒的不拒）、响应时间（P95 控制在几秒内）、用户满意度。有了这些指标，后面优化才有方向，不然就是凭感觉调。

3.2 知识库构建：脏活累活都在这里

需求定了，接下来是建知识库。这一步是整个项目里最不起眼但最耗时的部分。文档来源五花八门，有 Word、PDF、Confluence 页面、飞书文档，格式乱七八糟。第一步是统一格式，把各种文档转成纯文本或 Markdown。PDF 转换尤其麻烦，表格、图片、页眉页脚都是干扰，得做清洗。

然后是切分。我们按文档的标题层级来切，一级标题下的内容作为一个大块，如果太大再按二级标题切。每个块保留标题路径作为元数据，比如“员工手册 > 考勤制度 > 请假流程”。这样检索的时候，模型能看到内容的上下文归属，回答更准确。切分完，每个块大概几百字，既保证语义完整，又不至于太长。

接着是向量化。我们选了一个中文效果不错的 embedding 模型，把每个块转成向量存进向量数据库。这里有个细节：标题路径也要参与向量化，因为它包含了重要的语义信息。另外，我们给每个块生成了几个“假设性问题”，就是假设用户会怎么问这个问题，把这些问题和内容一起向量化。这样用户提问和知识块的匹配度更高。这个技巧叫“问题增强”，实测对召回率有帮助。

最后是元数据管理。每个知识块除了内容和向量，还存了来源文档、更新时间、权限标签等信息。权限标签很重要，因为不同部门的文档访问权限不同，检索的时候要过滤掉用户无权访问的内容。这个在 demo 阶段容易忽略，但生产环境必须做。

3.3 检索与生成链路：把各个环节串起来

知识库建好了，接下来是问答链路。用户提问进来，先做查询理解。有时候用户的问题很模糊，比如“那个报销的事”，直接拿去检索效果很差。所以我们加了一步：用模型把用户问题改写成更明确的检索查询，比如“差旅费报销的流程和标准是什么”。这一步能明显提升召回质量。

然后是混合检索。我们同时做向量检索和关键词检索，各取 Top-K，然后合并去重。向量检索负责语义匹配，关键词检索负责精确匹配。合并之后，用一个 rerank 模型重新排序，取最相关的几个块。这一步是效果的关键，rerank 模型选得好，最终答案质量提升明显。

检索结果拿到后，组装提示词。提示词里包含：系统角色说明、检索到的知识块（带来源标注）、用户问题、输出格式要求。输出格式我们要求模型给出答案的同时，标注引用了哪些来源，这样用户可以追溯，也方便我们排查问题。

最后是生成和兜底。模型生成答案后，我们做一层校验：如果答案里没有引用任何来源，或者模型明确说“根据提供的资料无法回答”，那就走拒答流程，返回“抱歉，我暂时没有找到相关信息”。如果答案有来源，就正常返回。这个兜底逻辑保证了系统不会瞎编。

3.4 评测与迭代：上线只是开始

系统上线不是终点，而是起点。我们建了一个评测集，包含几百个真实用户问题和标准答案，每次改动（换模型、调提示词、改检索策略）都跑一遍评测，看指标变化。没有评测集，优化就是盲人摸象。

评测之外，还有线上监控。我们记录了每次问答的完整链路：用户问题、检索结果、模型输出、用户反馈（点赞/点踩）。定期分析这些数据，找出 bad case，归类原因。是检索没召回？是提示词没写好？是模型能力不够？定位清楚了再针对性优化。

迭代过程中，我发现一个规律：大部分问题出在检索环节，而不是生成环节。检索没找到正确的知识块，模型再强也答不对。所以优化的时候，优先优化检索，而不是急着换更大的模型。这个认知帮我省了不少钱。

4. 转型过程中常见的坑与排查技巧

4.1 效果不稳定：先查数据，再查模型

AI 应用最让人头疼的就是效果不稳定，同样的输入，今天答得好，明天答得差。遇到这种情况，我的排查顺序是：先看检索结果变没变，再看模型输出变没变，最后看提示词有没有被改动。

检索结果变化，往往是知识库更新导致的。比如有人往知识库里加了一批新文档，检索的 Top-K 被新内容挤占了，原来的好结果排后面了。这时候要么调整检索策略，要么对新文档做质量筛选。模型输出变化，可能是模型版本更新了（云端 API 会静默升级），或者温度参数被改了。提示词被改动就更常见了，多人协作的时候，谁改了一版没通知，效果就飘了。所以提示词一定要版本管理，改动要有记录。

4.2 成本失控：Token 是要花钱的

做 demo 的时候不觉得，上了生产才发现 Token 消耗惊人。一个不注意，一个月账单能吓死人。控制成本的核心是减少不必要的 Token 消耗。几个实用技巧：提示词能精简就精简，别塞一堆用不上的说明；检索结果控制数量，别把 Top-20 全塞进去；简单任务用小模型，别什么都上大模型；缓存高频问题的答案，同样的问法直接返回，不用再调模型。

还有一个隐蔽的成本点是重试。模型调用失败重试、Agent 循环重试，都会成倍增加消耗。所以重试要有上限，并且要区分错误类型，网络抖动可以重试，参数错误重试也没用。

4.3 幻觉问题：让模型“有据可依”

幻觉是大模型的固有缺陷，没法根除，只能缓解。最有效的手段就是 RAG，让模型基于检索到的事实回答。但 RAG 也不是万能的，检索结果本身可能不相关，模型可能过度解读。所以还要加约束：提示词里明确要求“只基于提供的资料回答，资料里没有的就说不知道”；输出里要求标注来源，方便核查；加一层后置校验，检查答案和来源是否一致。

我个人的经验是，拒答率是一个需要监控的指标。拒答率太低，说明模型在瞎编；拒答率太高，说明检索或提示词有问题，该答的没答上来。找到一个平衡点，需要反复调。

4.4 常见问题速查表

4.5 几个我踩过的坑

第一个坑是过早优化。项目刚起步，我就花大量时间调检索参数、换 embedding 模型，结果发现最大的瓶颈其实是文档质量太差。后来先把文档清洗干净，效果立刻上来了。所以先保证数据质量，再优化算法，顺序不能反。

第二个坑是迷信大模型。一开始什么都用最大的模型，效果是好，但成本扛不住。后来做了大小模型路由，简单问题小模型搞定，复杂问题才上大模型，成本降了一大半，效果几乎没损失。

第三个坑是忽视评测。早期凭感觉调，改了一版觉得“好像好点了”，但到底好多少说不清。后来建了评测集，每次改动跑一遍，数据说话，优化效率高多了。评测集不用很大，几百条高质量的就够用。

第四个坑是低估工程复杂度。以为接个 API 就完事了，实际上要考虑并发、限流、重试、降级、监控、日志，这些工程问题一个都不能少。好在这些是我的老本行，做起来还算顺手。这也印证了前面说的：程序猿的工程能力，在 AI 落地里是核心竞争力。

5. 给正在转型路上的同行几句实在话

转型这件事，急不得，但也等不得。我的建议是边做边学，以战养战。别等“学好了”再动手，找个实际的小需求，哪怕就是给自己做个文档问答助手，动手做起来。做的过程中遇到问题，再去查资料、学原理，这样学到的东西是活的，记得牢。

学习路线上，我建议这个顺序：先搞懂大模型的基本能力和调用方式（API 怎么用、参数什么意思），再学提示词工程（这是最直接能见效的），然后学 RAG（这是应用最广的模式），最后学 Agent 和工程化（这是进阶方向）。每一步都要动手实践，光看不动手等于没学。

工具和框架方面，别贪多。Python 生态里 LangChain、LlamaIndex 这些框架很火，但我的建议是先用原生 API 把流程跑通，再考虑用框架。框架封装了很多细节，新手直接用容易“知其然不知其所以然”，出了问题不会排查。等你把底层逻辑搞清楚了，再用框架提效，事半功倍。

最后说个心态问题。AI 这个领域变化太快了，今天学的技术，可能半年后就过时了。所以别追求“学完”，要追求“学会学习”。底层的东西——工程思维、系统设计、问题拆解——是不变的，把这些练扎实，上面换什么技术都能快速上手。我做了这么多年开发，最大的体会就是：技术会过时，能力不会。你作为程序猿积累的那些硬功夫，在 AI 时代一样值钱，甚至更值钱。

这个领域还在快速演进，今天的最佳实践明天可能就被推翻。保持好奇，保持动手，保持记录，剩下的交给时间。