企业官网建设流程全解析

AI来了，20年老程序员怎么办？凉拌，把AI变成产品的功能！

看到这个标题，估计不少同行会心一笑。很多写代码写了十几二十年的人，这两年心情都挺复杂。一方面大模型的能力确实吓人，GitHub Copilot、ChatGPT、Claude 这些工具一个比一个猛；另一方面，又怕自己手里的饭碗哪天突然不值钱了。我身边就有不少干了二十年左右的老哥们儿，天天焦虑地刷新闻，越刷越慌。

我自己的看法比较简单：焦虑没用，干就完了。二十年前Windows开发火的时候，有人焦虑；十年前移动互联网来了，还有人焦虑；后来云计算、大数据一波接一波，每轮都有所谓的"末日论"。结果呢？真正活下来的，都是埋头把新技术塞进自家产品里的人。AI这事儿也一样——它不是一个职业的终结者，而是一个产品功能的新原料。

这篇文章不聊虚的，就聊一个核心思路：老程序员怎么把AI从"聊天框"变成产品的正经功能。你会看到我是怎么拆解需求、选模型、搞评测、控制成本的，也会看到踩过的几个大坑。如果你也是个写了很多年代码、现在面对AI有点手足无措的开发者，这篇东西就是给你写的。

1. 先说结论：你的核心竞争力从来不是"写代码"

20年老程序员最容易被绕进去的一个思维误区，就是把自己的价值等价于"打字速度"和"语法熟练度"。但冷静想想，如果是这样，那确实早该焦虑了，因为任何年轻人练几个月就能赶上。我们真正的护城河从来不是API和语法，而是三类特别难被替代的东西。

第一类，是对业务逻辑的理解。一个订单状态机里有几个隐藏分支、一个支付流程为什么必须这么设计、某个历史包袱是怎么来的、哪些代码注释其实是"不能删的墓碑"——这些东西大模型不知道，因为它在训练数据里看不到你公司的私有业务，更看不到你踩过的坑。真正值钱的，是你能把业务需求翻译成技术方案，而不是把技术方案翻译成代码。

第二类，是对成本和安全的本能敏感。大模型给出的代码看起来很美，但它不会考虑这个接口每秒并发是多少、这条SQL在百万级数据下会不会爆炸、这个密钥放这里会不会泄露。这些"生产环境教会我们的道理"，是五年以下经验的工程师很难具备的。

第三类，是工程化的整合能力。一个AI功能真正上线，绝不是"调个API返回一段文字"那么简单。它牵扯到系统架构、数据处理、权限控制、监控告警、灰度发布、回滚策略。这些东西，恰恰是写了20年代码的人闭着眼睛都能干的事。

所以我的结论很直接：老程序员的最大危机不是"被AI替代"，而是"看见AI只想到替代自己"。换个角度，如果你把AI当成一个能力组件装进自己的产品，让用户因为AI而愿意用你的东西，那AI越强，你的产品越好用，你的价值反而越高。这一进一出的差距，才是接下来几年程序员之间的真正分水岭。

拿我自己举个例子。我前两年接了个传统行业的项目，一套老旧的管理系统，跑了好多年，用户天天抱怨操作繁琐。客户第一次听到"AI"两眼放光，但你要让他全盘重构系统，他肯定不干。后来我们的方案很简单——老系统一颗螺丝都不动，单独加一个"智能助手"模块，接入大模型，让用户能用自然语言查询数据、生成报表。就这么一个功能，客户满意度直接上去了。这就是"把AI变成产品的功能"的典型打法。

2. 想清楚再动手：AI功能的五个关键决策点

很多团队做AI功能失败，不是技术不行，而是动手之前没想清楚几个问题。我建议你在写第一行代码之前，先过一遍下面这五个决策点。每一项我都给了自己的经验判断，不一定绝对正确，但能帮你少走弯路。

2.1 这个功能是给用户省时间，还是给用户找乐子？

AI功能大概分两类：效率型和体验型。效率型功能，比如自动生成周报、智能客服、信息抽取、文书辅助，它的价值是确定性的，用户看一眼就知道"省了我10分钟"；体验型功能，比如个性化推荐、智能陪聊、创意文案生成，它的价值是"惊喜感"，用户未必能立刻说出有什么用，但会觉得产品很聪明。

这个判断极其重要，因为它决定你后面所有设计。效率型功能，你要重点考虑准确率和容错率，因为用户把活交给你了，你做错了是要背锅的；体验型功能，你要重点考虑延迟和惊喜感，答案哪怕不完美，只要响应快、语调对，用户也愿意接受。我见过不少团队把效率型功能做成了聊天玩具，也见过把体验型功能做成了严谨工具，结果两头不讨好。

用一句话判断：你的用户是"不得不完成一项任务"，还是"逛一逛找点新鲜感"？前者走效率路线，后者走体验路线。这会影响你选大模型参数（温度调多少）、影响你做不做"答案校验"、影响你页面上那句引导文案怎么写。

2.2 大模型在你这儿是"大脑"还是"嘴"？

这个决策点我特别想展开说。很多功能设计者有一种错觉，觉得大模型既然那么聪明，就应该把整个业务都给大模型来承担。这种想法很危险。打个比方，如果你的产品是一个人，大模型应该是他的嘴和一部分小脑，而不是大脑——大脑应该是你自己的业务逻辑和规则系统。

举两个典型的反面案例。有人做一个AI法律咨询产品，直接把问题丢给大模型，让它以律师的口吻回答，结果模型时不时一本正经地胡说八道，用户一旦当真，出了事谁都担不起。正确的做法是：用你自己的业务逻辑先判断"这个问题属于哪个法域、哪种案件类型"，再去本地数据库检索相关的条文和判例，把检索到的确定性内容作为"事实依据"，最后才让大模型把依据组织成自然语言。大模型只负责"说话"，不负责"断言"。

再比如说客服系统。如果你让大模型直接回答用户关于退款政策的问题，就等于把政策的解释权交给了概率。更好的方案是：先用规则引擎匹配关键词和路径，命中预设答案的直接返回；只有规则引擎覆盖不到的长尾问题，才交给大模型生成回答，并且必须附上"仅供参考，以人工客服为准"的兜底。这就是真正的工程思维——把AI放在它擅长的地方，而不是把所有环节都押注给一个概率模型。

2.3 模型的"幻觉"能不能被容忍？

聊大模型就绕不开幻觉这个事儿。所谓幻觉，就是模型一本正经地编造出看起来合理但实际是错误的信息。有人觉得幻觉是bug，其实它是大模型这种技术天生的副产品，你只能控制它，不能消灭它。

你得在动手前就想好：这个功能如果产生幻觉，用户能不能接受？后果有多严重？

我一般会把功能分成三个容忍等级。等级一，容错度极高，比如文案润色、头脑风暴、创意生成，偶尔胡扯两句没影响，甚至还能有点惊喜。等级二，中等容错，比如代码补全、概括总结，模型产出的东西需要用户过目确认，用流程来兜底。等级三，零容错，比如医疗建议、法律条文、金融计算、身份判断，这个等级绝不能直接把模型输出呈现给用户，必须有逻辑校验、数据库比对、二次确认机制。

针对等级三的功能，我常用的一个技巧是"给模型加约束链"。把提示词写成"你只能基于我提供的以下资料回答，资料里没有的信息，明确说不知道"，然后把从数据库查出来的真实资料拼在提示词后面。虽然不能100%杜绝幻觉，但实测能把胡说八道的概率从百分之十几降到百分之二三。再配上"不确定就说不确定"的训练指令，用户观感会好很多。

2.4 你准备为每次调用付出多少成本？

这可能是老程序员比年轻同事更容易想清楚的事。大模型API的成本并不是一个固定数字，它由好几部分组成：输入token数乘以输入价格、输出token数乘以输出价格，再加上你为了让模型表现更好而拼进提示词里的"物料"费用。

我见过最离谱的烧钱方式，是把整个文档库每轮对话都塞给模型。看起来每次调用也就几毛钱，但一旦有几十万用户，一个月账单就是几十万。这类问题必须在设计阶段就做预判。参考一下我们的实践，做了一个简单但有效的分层方案。冷门用户问的通用问题，直接走预设话术，hits命中就返回，根本不调用大模型；中等复杂度问题，用中小尺寸模型（比如7B-13B级别的开源模型，或者云端API的中档规格）来接，反正要求不高，不需要最强的模型；只有真正复杂的推理任务，才启用最大号的模型。

这么一分层，整体成本大概能降到原来的四分之一到三分之一。老程序员最大的优势其实在这儿——你对成本有直觉，你知道一个看起来很美的功能背后要烧多少钱，所以你能在老板拍脑袋之前，给出一份理性的账本。

2.5 出了错，锅谁来背？谁负责兜底？

这个决策点最容易被技术团队忽视。AI功能上线之后总会有出错的时候，关键在于出错之后有没有兜底机制。我见过某团队做了一个AI自动回复，结果模型在某个用户问题下生成了完全不合规的回答，因为没有人工审核环节，第一时间没人发现。虽然没有酿成大事，但内部复盘时大家都很后怕。

在做AI功能前，强烈建议你列出三张表。第一张是风险清单，逐条列出"如果AI在这个环节错了，最坏结果是什么"；第二张是兜底方案表，针对每个风险写明责任人和补救动作；第三张是日志记录要求，明确哪些输入输出必须留痕，以便事后审计和模型迭代。不要觉得这是大公司才需要的流程。哪怕你的产品只有一千个用户，一次没有兜底的AI事故，就足够让你的项目被砍掉。

3. 从零上线一个AI功能的完整实操记录

理论铺垫了这么多，现在走一遍实操。我以一个虚拟的"智能工单分类助手"功能为例，完整记录从需求到上线的全过程。这个功能很小，但麻雀虽小五脏俱全，涵盖了工程落地的大部分关键动作。

3.1 需求定义：让AI做一件事，而不是做所有事

项目背景是一家做企业服务的某公司，内部客服每天收到大量用户工单，描述五花八门，有的说"登录不了"，有的写"界面报错400"，还有的直接说"你们软件是不是坏了"。历史数据里，客服人工给每个工单打分类标签，大概用了百分之六十的精力在"阅读和理解"上，剩下百分之四十才是在解决。我们的目标很简单：用AI自动完成工单分类，把分类准确率从原来的"人工优势"提升到可接受水平，减轻客服负担。

最开始产品经理找过来，提的需求是"做一个AI客服，能自动回复用户所有问题"。我直接给否了——范围太大，没有明确边界，幻觉风险高，成本不可控。我们把它收缩成"工单智能分类"，只做一件事：输入工单文本，输出预先定义好的分类标签。这个收缩极其关键，它让整个项目的复杂度呈指数级下降。

定义清楚功能边界后，我们去翻了过去一年的历史工单数据，统计出排名前10的工单类型，覆盖了总工单量的百分之九十五，分别是账号问题、计费问题、功能咨询、数据异常、性能问题、集成问题、界面问题、权限问题、报表问题、其他。然后去看每个类别下有哪些典型话术，把这些整理成一个分类字典，这个字典后面有大用。

3.2 提示词工程：别一上来就丢给大模型

很多人觉得提示词就是"你好，请帮我分类"。真到实际业务里一定不够。我们最终版本的提示词分了四层结构，我逐层拆解一下。

第一层是角色定义。告诉模型"你是一个企业客服工单分类专家，你只做文本分类，不回答任何额外问题"。这一层是为了限制模型的输出范围，防止它在分类之外又自作主张回答用户的问题。

第二层是任务说明和输出格式约束。明确"你的任务是将用户工单分到以下类别之一，只输出JSON，格式为{'category': '账号问题'}，不要输出任何解释"。

第三层是分类字典。把上面整理的10个类别和每个类别下的典型特征、典型样例全部列进提示词里。这一步是提高准确率的关键，相当于给模型一份"分类标准答案"。

第四层是边界规则和拒答机制。写明"如果用户工单信息不足以判断类别，输出{'category': 'other'}；如果用户输入的内容不是工单而是一句闲聊，请输出{'category': 'invalid'}，不要尝试理解或回答"。

整套提示词写完后，我拿真实历史数据做了五十条测试，初版准确率只有七成出头。发现问题主要出在类别定义模糊，比如"数据异常"和"功能咨询"之间的区分不清晰。于是又拉上客服主管一起，把每个类别的定义重申了一遍，补充了更多典型关键词和边界样例，第二版准确率提升到了八成五。这个"初版-测试-修正-再测"的循环，就是提示词工程的标准循环。

3.3 模型选型和成本预算：从贵到便宜，逐步降级找平衡

模型选型的原则是"够用就好"，不要在战斗力溢出的大模型上花冤枉钱。我们当时对比了三档方案。第一档是最大的云端模型，API价格相对较高，单次分类成本折合人民币差不多一毛五到两毛，准确率最高但太贵。第二档是中小型模型，单次成本大约三四分钱，准确率略低一点。第三档是纯规则匹配，完全不花钱，但只有字典里的精确命中才能分类。

我做了个测算表。按每月五万条工单算，如果全部用最大模型，成本大约7500到10000块钱；全部用中小模型，不到两千；纯规则匹配几乎为零，但能命中的可能只有三成。后来采取的办法是三级漏斗。先进规则匹配，命中者直接出结果，不花钱；没命中的进中小模型；中小模型置信度低的再进大模型兜底。这样跑下来，整体平均单次成本被压在了四五分钱左右，月成本不到2500，准确率还在九成以上。这个"漏斗结构"，就是在成本、准确率、覆盖率之间找平衡。

另外，给所有调用API的地方加了token用量日志。每次记录prompt输入长度、输出长度、模型名称、响应耗时。这个日志排除了一个问题——某天成本突然涨了40%，一查发现是某个用户疯狂发长工单，每单都携带了超长历史记录，把token消耗拉高了。如果不提前记录token用量，这种问题查起来会非常费劲。

3.4 数据回流与评测体系：好功能是"喂"出来的

AI功能上线不等于结束，它恰恰是另一件事的开始——评测和迭代。很多团队做AI功能不做评测体系，上线后全凭用户口碑感知好与坏，这是不对的。我们的做法是建一个"评测集"和"回归测试"流程。

从历史工单里抽了五百条人工标注过的数据，作为评测集。每次修改提示词或切换模型，都必须跑一遍这五百条数据，看准确率是否下降。没有评测集，你和产品经理在公司里吵一天也说不清"现在的模型到底比上版好还是差"。有评测集，一句话就解决：上一版89.2，这一版91.5，改了哪几条，你来看。这个习惯花半天时间就能建立，但后续省下的沟通成本是巨大的。

同时把每个分类错误的工单捞出来，走人工复盘。如果是模型判断错误，就看是否有规律可循。比如我们一度发现"集成问题"的准确率特别低，原因是一些用户写的是"和别的系统对接不上"这种口语化描述，但工单类别定义里写的是"第三方接口对接异常"，说法不一致。把这类新话术补充进分类字典后，准确率又上了一个台阶。这其实就是把AI当成一个需要持续训练的员工，而不是一劳永逸的工具。

3.5 灰度发布与应急兜底：先小范围跑，再全量推

我们发布时没有一步到位，而是先在内部群和两个客户那里小范围试用了一周。这一周里果然发现了一些问题，但幸好影响可控。

有一个问题是，某类工单带了附件截图，模型的推理依据只在文字部分，而截图里能明确看到是什么错误，容易造成误判。这个短时间内没法靠模型解决，于是做了个折中方案：凡带截图的工单，AI分类结果仅供参考，必须有客服人工确认。另一个问题是极少数用户输入的内容是乱码，模型硬给它分了一类，明明应该是"invalid"。这暴露了边界规则还不够强，我们在提示词里加了更强的限制，同时前端的输入框加了简单的乱码检测。

灰度结束后才全量开放，但因为有了这一周的缓冲和日志，全量后的稳定性明显好很多。说句实在话，AI功能最怕的不是上线前有bug，而是上线前没bug、上线后才暴露问题，因为那说明你的测试集覆盖面和真实场景脱离了。灰度就是弥合这种差距的最有效方式。

4. 独立实践心得：关于把AI做成产品的几条干货

实操流程走完，再单独聊几条干货。这些结论都是我从真实项目中摸爬滚打总结出来的，可能比那些"教你三步调好大模型"的帖子要实用得多。

4.1 藏在提示词之外的两个性能杀手

很多人以为AI功能慢，主要是因为大模型生成速度慢。实际做下来，我们发现更多时候性能瓶颈在别的地方。一个是大模型的API调用是串行的，有些团队在一个操作里连续调用两三次大模型，比如先生成标题，再生成摘要，再生成关键词，每次都要等网络往返，整体延迟直接翻倍。解决办法是合并调用，把多个任务塞到一次prompt里，让模型一次输出结构化JSON，通常只需要一次API往返。我们有个功能从四次调用减到一次，响应延迟从二十秒降到四秒。

另一个杀手是prompt里塞了太多无用物料。你每往prompt里拼一段文字，模型的输入token就多一份，花的钱和耗的时间也就多一份。有些同事习惯把整本手册都贴进prompt，根本不看模型到底用不用得着。好的习惯是只塞和当前任务直接相关的最小必要信息，其他动态检索，用多少拿多少。群里有个数据挺惊人：单单是精简prompt这一项，就让某个功能的平均响应时间从六秒降到了三秒，成本砍掉了一半。

4.2 给AI输出加一把"安全锁"

做AI功能最怕的就是输出不可控。我给项目里的所有AI输出都统一加了一个"输出过滤器"，分三层。第一层是格式校验，如果要求输出JSON但模型输出了markdown，直接重试或者标错；第二层是关键词过滤，把政治敏感词、暴力词、行业禁忌词挡在门外，防止模型脑子一热输出风险内容；第三层是业务规则校验，比如工单分类的结果必须出现在预定义的类别列表里，凡是列表之外的，一律视为非法输出，走兜底流程。

这个过滤器看着简单，但实际救了两次命。一次是模型在一个回复里疑似生成了某个客户的负面评论，被关键词过滤拦住了。还有一次是分类模型输出了一个不属于任何类别的标签，被业务规则校验抓了个正着。强烈建议你把过滤器做成独立模块，这样每上一个新AI功能都可以复用，而不是每个功能各自写一遍。

4.3 老程序员怎么学AI最快

说到这儿，肯定有同行想问：二十年没碰新东西，现在学AI从哪里下手？我的建议很直白，别从数学开始，别去想弄清楚注意力机制里的矩阵乘法，学习路线越实用越好。

第一步，把主流大模型的API文档过一遍，搞清楚一个输入请求长什么样，能传哪些参数，输出怎么解析。这是工程师的命脉。第二步，拿你刚学到的API去做一个极小的端到端demo，比如一个脚本，读入一段文本，返回一个摘要，跑通它。哪怕是个玩具，跑通了你就有了手感。第三步，去GitHub上找三五个开源的AI项目，看它们的提示词是怎么写的，怎么处理异常，怎么做缓存的，比看一百篇文章强十倍。

这里有个经验挺有意思。我接触过的资深开发者，普遍"睡了一觉就会了"。所谓睡了一觉，其实是他某个晚上花了三个小时，按照上面这套流程把API文档和开源项目过了一遍，第二天醒来就有底气了。大模型本质上就是一个带有概率分布的函数，你只要会用它的调用方式，结合上老程序员对业务和系统的理解，很快就能产出东西。

4.4 别迷信AI，它还是一个概率模型

最后一条干货，是想给所有做AI功能的人提个醒。大模型没有你想象的那么"懂"业务。它本质是在海量文本上学习到的一种"文字接龙"能力，只是这种接龙的模式非常复杂，以至于在很多场景下表现得像有理解力。但它没有常识，没有责任感，也没有判断力——它的输出只是概率上的下一个词。

所以，凡是涉及重要业务判断的功能，都要把决策权留在自己的代码里。AI可以建议、可以起草、可以辅助，但最终拍板的，必须是有确定性逻辑的规则引擎，或者人工审核。我见过一些同行做的AI功能，完全信任模型输出，结果被一个明显荒谬的答案打了脸。做技术这件事，永远要留一手，给用户留一个"撤销"和"人工介入"的入口。

5. 避坑速查：把AI变成产品功能的常见问题清单

最后整理一份避坑清单，这十几条都是我亲身踩过、或者亲眼看着别人踩过的坑。内容比较密，建议收藏起来，做AI功能的时候对照着一条条看一眼。

再补一个很多人忽略的点：AI功能的上线和使用过程，一定要有可追溯的日志。哪一条prompt、哪一个输出、哪一个用户，都要能查。这不只是排查问题的需要，也是产品出事故后保护你自己和团队的证据。日志不完善的时候，出了问题没人说得清，最后往往就只能靠猜。

6. 写在最后的个人体会

在AI这个话题下写了这么多，说点真心话。大多数写了20年代码的人，在业务理解、架构设计、成本控制、工程化落地这些方面，依然是顶尖的。AI可以让我们写代码更快，但它替代不了我们判断"什么值得做"的能力。把这个逻辑想通了，你就不会再焦虑了——你不是被AI追着跑的落伍者，你是一个比AI更懂业务的操盘手。

回到标题那句话：凉拌。它不是自嘲，而是真的有一盘"凉拌菜"可以做——把AI切成丝，码进你产品的各个角落，让系统的每一处都沾上AI的味儿。这才是老程序员在这个时代最该干的事。

每次上线一个AI功能，我都会问自己一句：如果大模型明天更强十倍，这个功能会不会变得更好？如果会，那就说明我做对了；如果不会，说明我只是在用AI表演AI。努力的方向，应该是让AI成为产品真正的肌肉，而不是一层好看但一戳就破的皮肤。