企业官网建设流程全解析

最近这事挺有共鸣。我们经理去外面转了一圈，回来晨会就拍板：“明年产品必须全面接入AI，别人都在做，我们不能落后。”当时我旁边前端同学差点把水喷出来，我倒是很淡定，因为这已经不是第一次遇到“经理想往代码库里塞AI”的时刻。强制接入、凭空造需求、设计稿里硬塞机器人对话……这些所谓“AI bs”迟早会落到每个技术团队头上。与其正面硬刚，或者默默吞下技术债，不如想清楚怎么把它变成一次可控的工程决策。

这篇东西不聊玄学，就聊实际操作。适合遇到过类似要求的后端、前端、测试、设计和你身边的项目经理看。核心思路只有一句话：经理可以拍脑袋，但你要拍清单、拍数据、拍替代方案，用工程的方式回应情绪化的决定。

1. 接到“我们也上AI”的指令后，先做这三件事再动手

1.1 别急着拒绝，先搞懂经理口中的“AI”到底是什么

很多人的第一反应就是：“又来一个不懂技术的瞎指挥。”但我跟你讲，一上来就拒绝，后面肯定吃亏。经理说“我们要上AI”的时候，他自己往往也没想清楚，他脑子里可能装着三四种完全不同的东西：可能是想在官网挂个智能客服，可能是想让相关推荐变得更准，也可能是想写一份漂亮PPT拿去给客户讲故事，甚至可能只是想在下季度汇报里多一个关键词。

你需要做的事情，是在他还没细想的时候，把他泛泛的愿望拆成具体问题。这里有个小技巧，我会拿着笔记本直接问：“你说的AI，希望用户能感受到的是一种新交互，还是背后决策更聪明？是面向客户的，还是内部提效的？”绝大多数情况下，经理只能回答出前者还是后者，但这就够了。只要他把范围缩到某个方向，我们就能从“要不要做AI”的辩论，进入“怎么做AI”的现实讨论。

如果他说“我也不确定，你先研究看看”，那更简单——你获得了一个研究窗口。你可以花一周时间做技术调研，出一页纸的分析报告，用事实给这个想法“降温”或“加温”，主动权就在你手里了。

1.2 把模糊愿望翻译成具体的工程问题

一旦知道经理的大致意图，你需要立刻把这些话变成工程师能评估的语言。比如“接入AI”可以拆成：

• 需要新的能力，还是优化现有流程？
• 数据从哪来？质量够不够？要不要清洗和标注？
• 允许多久延迟？100毫秒还是3秒？
• 出错了怎么办？错误容忍度是多少？
• 这个功能由谁维护？出了问题谁负责？
• 预算上限多少？按调用量付费还是愿意花人力自建？

这些问题看起来基础，但很多团队死在第一步，就是因为没人把模糊的“AI”翻译成一张可讨论的工程清单。你可以把这些整理成一个简单的表格，直接扔给经理填。他没填过，就会知道这不是拍脑袋那么轻松的事。

我自己的经验是，只要这份清单里有三项他答不上来，这个需求就已经成功了一半——要么他会闭嘴，要么他会授权你按专业方式去补充方案。这两种结果对我们都是好事。

1.3 画一条“AI价值-成本”的判断线

接下来把需求放到坐标轴上。横轴是落地成本，包括开发、数据、运维、模型调用费用；纵轴是业务价值，包括客户满意度、收入、效率提升。把所有候选场景都排上去，形成一个优先级矩阵。

• 高价值低成本：马上做，作为首个POC
• 高价值高成本：做预算评估，分阶段投入
• 低价值低成本：可以做，但要限定边界
• 低价值高成本：坚决不做，给出数据依据

这个矩阵不只是给你自己用，更重要的是拿去跟经理对齐。你不需要直接说“这个需求很蠢”，你只需要把一点指给他看：“这个方案在矩阵里处于低价值高成本区，按我们的资源，我建议先把它的优先级降下来，把人力放到高价值低成本的事上。”只要他认可评判标准，就等于他认可这个结论。

2. 技术选型和工程决策：怎么不把现有代码库搞乱

2.1 在“用大模型API”和“本地部署小模型”之间怎么选

等需求基本明确、决定试水时，第一个技术决策就是：模型从哪里来。市面上无非两种路数——调云端API，或者本地部署开源模型。很多人以为这是个纯技术问题，其实它更是成本、隐私、和运维问题。

调API的优势是开发速度快、效果普遍好、不用操心GPU调度；坏处是长线成本不好控，而且数据要出网。如果你的业务涉及用户隐私、未公开代码、客户交易数据，风控就会拦住你。这时候可以考虑大模型的私有化版本，但仍然要把数据合规问题摸清楚。本地部署开源模型，数据可控、离线可用、长期成本有上限，但前期运维代价不低，需要有人懂推理优化，否则一张显卡可能只能跑个寂寞。

我的建议是，在POC阶段优先用云端API，哪怕是企业级试用额度也行。因为我们的目的只是验证业务价值，不是立刻搭一套生产级AI平台。等验证通过后，再根据数据敏感度和调用量，重新评估是否要切换或引入本地模型。这个顺序能省去很多没必要的GPU采购。

2.2 用“防腐层”思路把AI隔离在核心业务之外

这里是我最想强调的工程原则：如果你不可避免要往现有代码库里加AI相关代码，那请务必加一道“防腐层”。现在很多团队写AI功能，直接在网上找到一段示例代码，Ctrl+C到项目里，然后几个service到处调LLM，prompt写在controller里，token key直接放在配置文件里。这已经不是技术债了，这是给自己埋雷。

防腐层的思路很简单：把AI能力当外部依赖看待，所有跟模型提供方相关的调用、prompt、日志、异常处理都收敛到一个独立模块或独立服务里。核心业务代码只依赖一个抽象接口，比如IntelligentSummarizer，而不是直接依赖某个厂商的SDK。这样哪怕明天把底层模型换成另一个，核心业务一行都不用改，你只需要替换防腐层内部实现。

这和你写数据库访问层是一个道理。你不会把SQL散落在各个service里，为什么LLM调用就能随便到处写？尤其在经理强行赶进度时，防腐层能保护你未来三个月不用天天加班修AI相关的边角问题。

2.3 现实世界中的模型选择与prompt治理

模型选型不要只看排行榜。实际生产里，还要看上下文长度、输出格式稳定性、延迟、以及它和你现有技术栈的兼容性。比如你后端是Java生态，那“spring ai”这类封装框架确实能帮你省掉一些底层对接工作，但注意它也在抽象层之上增加了一层自己的规则。要不要引入这类框架，取决于团队是否愿意接受新依赖。

另外，prompt绝不是写一句话就完事。建议从第一天就把prompt当代码管起来：有版本、有comment、有测试。你可以建一个prompts/目录，每个业务场景一个文件，配套样例输入输出。模型升级后，先跑一遍评估集再切线上，避免“模型说自己变好了结果线上效果反而翻车”这类事故。

这里还要专门提醒一下输出稳定性。LLM的输出天生是概率性的，你要做业务逻辑，就必须给模型输出加约束。能上结构化输出的就上结构化输出，能自己做一层schema校验就做校验。如果这一步不做，后面接手的同事一定会骂人。

3. 演示给经理看：用最小可行POC说话

3.1 设计一个可以在半天内出结果的小实验

等一下，我们不要一上来就搞个系统工程。你只需要围绕一个明确、边界清晰、能快速看到效果的业务场景，做一个小POC。比如用户常见问题摘要、客服工单自动分类、商品描述生成初稿，都是经典切入点。

拿客服工单自动分类来举例：从现有系统里导出一千条历史工单，让模型按你们定义的分类体系打标签，然后人工抽查100条，算一下准确率。这一套流程，正常开发能力强的人半天到一天就能跑通。你不需要做前端界面，不需要接后台，只需要写几百行脚本，把数据和结果展示出来。

为什么要刻意做这么小？因为小POC的胜负不会伤筋动骨。如果效果不错，你可以顺势说我们需要进一步做产品化设计；如果效果不理想，你的止损成本也只有一天工时。很多团队一上来就想做“全链路智能客服”，结果三个月做不完，经理还觉得你能力不行。问题根本不在你的能力，而在于切入点选得太大。

3.2 POC阶段不需要完美，但必须带指标

光跑通还不够，你得有数字。没有数字，你就只能靠“感觉”说服人，而“感觉”这东西最容易被情绪和立场左右。这里我建议至少准备四类指标：

• 准确率：比如分类标签和人工标签一致的比例
• 覆盖率：多少样本模型能给出有效结果，剩多少需要人工兜底
• 平均延迟：单次请求从发起到拿到结果的时间
• 单次成本：按API计价折算每次调用的费用

拿一个数据举例：如果你的客服分类准确率只有68%，看起来好像不高，但你同时告诉经理，这套系统如果只处理其中60%高置信度的工单，准确率能到92%，剩下40%还是人工处理。这已经是一个可行方案，而不是“AI不行”。这样谈，经理会看到你的工程判断力，而不是听到你在泼冷水。

我把这些指标做成一张简单表格，演示当天可以直接放出来。这时候你只需要指着表说一句话：“现在这个效果，投入产出比是划算还是不划算，您来定。”决策权交回去，执行思路已经在你手里了。

3.3 让数据替你谈：怎么在演示中给经理“留台阶”

很多人在演示的时候，容易犯一个毛病：拿POC效果不好作为拒绝理由，语气还特别冲。这么干，哪怕经理嘴上不说什么，心里已经记下一笔“这人积极性不高”。但我们真正要做的是让数据替他做决定，同时给他留面子。

如果POC效果好，你就说：“这个方向有戏，但我们需要再花两周设计质量保障方案，再考虑灰度。”如果效果不好，你可以说：“从数据看，主要卡在数据质量上，我们再做一轮数据清洗，准确率还能上去，但值不值得，得您拍板。”注意，这句话不是把锅甩给经理，而是把“是否需要继续投入”变成商业决策，而不是技术决策。

这一招我用了很多次，屡试不爽。经理会觉得你在专业动作上想得很全面，而不是在抵制他的想法。只要他觉得自己的思路被认真验证过，你后面再提“暂缓”“换场景”“加预算”都有得聊。

4. 如果不可避免要落地：如何控制AI代码的质量和技术债

4.1 给AI生成或辅助代码上“紧箍咒”：代码评审规则

有时候，POC效果好得不行，经理说“那直接上生产吧”。这时候你挡不住，但你可以设置过程护栏。第一道护栏就是代码评审。现在很多AI辅助编码工具用得很猛，但团队里可能没有一套适应“AI时代”的评审清单。我列几个关键点：

• 检查AI生成代码是否真的被理解，不能在代码里看到不理解的魔法逻辑
• 检查是否有大量重复相似但又不完全一样的代码，很可能是AI大幅复制粘贴的痕迹
• 检查错误处理是否完整，尤其是调用外部模型接口时的超时、重试、熔断逻辑
• 检查是否有隐藏的无限循环或递归风险，AI很容易写出看起来很对但实际跑不完的代码
• 检查硬编码，包括提示词、模型名称、token上限等，全部要配置化

如果你把这份清单直接发给团队，人人都会觉得你较真，但从产出质量说，确实能拦掉八成无厘头的AI代码。评审不是为了刁难，而是为了让AI功能不至于成为“谁都能往里扔东西的公共垃圾场”。

4.2 让模型输出可观测：结构化输出、schema校验、fallback

第二个护栏是对模型输出的可观测性。这里的关键不是监控“模型服务健康”，而是监控“业务结果是否满足预期”。模型可能返回200，但内容是幻觉；也可能返回一段很流畅的文本，但JSON解析挂了。你要做的，是在模型返回结果时强制做一层schema校验，不满足就触发降级。

举个例子。你要用模型生成商品简介，那就定义一个输出结构：{title, highlights[], riskTips?}。模型返回后，先校验字段是否存在、类型是否正确、长度是否超限。校验不通过，要么重试一次，要么直接使用默认文案。系统必须有一个明确的fallback路径，保证用户的体验不至于因为一次模型抽风而完全中断。

在可观测性上，不要只记录成功和失败，还要记录每次调用的prompt版本、模型版本、耗时、token数、校验结果。这样出现问题时，你可以快速定位是prompt改坏了，还是上游模型更新了行为。模型是外部依赖，外部依赖出了状况，你觉得你不在代码里留一手，到时候线上事故谁背？还是你自己背。

4.3 预算和风控：别让一个AI功能吃掉整年GPU预算

就算功能已经上线，也不能让它在预算上失控。真金白银的教训我见过太多：一个新人用API跑了几天批量任务，账单直接上万。所以从一开始就要做限流和配额。具体做法包括但不限于：

• 按用户维度限制每日调用次数
• 对高成本模型设置单次请求的token上限
• 对非实时场景使用队列和批量处理，避开高峰
• 加一层结果缓存，相同或相似的请求不重复调用模型
• 每日对调用成本做报表，看到异常立刻报警

另外，还要做数据脱敏。凡是发给外部模型的内容，先检查有没有手机号、身份证、密钥、内部系统地址，发现敏感信息就自动替换或拒绝发送。这不是额外负担，这是合规底线。你可以把这个要求写进代码评审清单，也可以做成一个小库，让大家统一调用。关键在于，跨过这道门，你才能放心让AI代码进入你精心维护多年的代码库。

5. 向经理说“不”的沟通艺术（也是保住自己不被背锅的关键）

5.1 用“是，但是”而非“不行”

直接对经理说“不行”通常是下策，但直接说“好好好，马上办”则可能把自己拖进坑。我比较推荐的沟通句式是：“这个方向可以探索，但需要……”看到没，你先承接他的意图，再把约束条件亮出来。约束条件不是拒绝，是让决策在真实条件下发生。

比如经理说：“让我加一个AI助手，最好下周就上线。”你可以回：“可以，但下周上线的话，我们就只能先做一个仅支持固定问答的演示版，不能接真实业务数据，否则风险不可控。如果要接真实业务数据，至少要三周。您更看重哪个？”这句话把选择权交给他，但他只能在“快但浅”和“稳但全”之间选，而不是在“做”和“不做”之间反复横跳。

这种做法还有一个额外好处：经理会慢慢学会用工程思维提需求，而不是继续拍脑袋。时间长了，他会默认你是个靠谱且专业的人，你们的沟通成本会大幅下降。

5.2 三种最常见的无理要求及应对模板

我帮你整理三个高频场景，并给出可落地的话术。第一个，经理说：“竞争对手已经上了AI客服，我们必须也上。”这时候别慌着说对手做得烂。你可以说：“行，我们花两天时间去拆解他们客服的交互范围和回答质量，看哪些场景值得抄，哪些场景其实是自嗨。拿到结果再来确定我们的方案。”这既没有否定他，又没有立刻开启一个高风险项目。

第二个，经理说：“AI这么强，以后不需要那么多测试和人工审核了。”你要小心，这句话可能会影响同事饭碗，也容易把质量和风险往下压。你可以回应：“AI确实能提升测试效率，但核心链路仍然需要人做决策兜底，稳妥起见，我们先拿AI做回归测试覆盖补充，而不是替代现有用例。”让他看到你既拥抱AI，又保护了业务。

第三个，经理说：“让AI把所有代码写了，省人力。”作为工程师，你很清楚目前AI写代码的边界。你可以说：“可以拿AI做脚手架和杂活，但核心架构和关键业务逻辑，我们还得人来review。如果全自动生成，代码质量风险太大。我们可以先在一个模块试点，评估生产力提升。”把全有全无变成小范围试点，是最稳妥的。

5.3 把风险清单递上去：让老板做知情决策

最后，学会用“风险登记表”来管理老板们的预期。不要口头说“有风险”，而是抛一张纸条过去，上面写清楚风险、等级、概率、影响和缓解措施。举个例子：

递出去之后，平静地问一句：“这些风险我们认可接受，并且按缓解措施来执行，那么项目就可以往下走。您确认的话，我们需要再申请对应资源。”这一招相当管用。因为当风险被书面化后，经理就很难再用“不知道”来推卸责任。一旦他确认了，后面项目出情况，你也有据可查，不会自己一个人背锅。

6. 常见问题快查表与实际经验

6.1 踩坑实录：prompt失控、模型幻觉、接口稳定性、数据隐私

我把这两年被AI功能坑过的场景都过一遍。最经典的是prompt失控——明明线上版本一切正常，某天有同事改了prompt里一个词，结果所有结果都变了风格，而且没有测试覆盖。后来我们把prompt版本化和评估集当作硬性要求，才止住这种低级问题。

模型幻觉不用多说，AI一本正经地编造数据，客服回答里出现虚假优惠，推荐理由写得天花乱坠但推荐的未必存在。解决办法只有两层：一层是靠工具强制约束输出，比如用枚举和模板；另一层是在关键业务流里保留人工复核环节。记住，模型输出永远只能当“草稿”，而你已经认可的“定稿”才能进入用户界面。

接口稳定性问题也很要命。早先我们接外部模型API时，遇到对方限流，结果没做重试，用户眼看着白屏。后来老老实实加了超时、重试、熔断和降级逻辑。现在每次模型故障，用户最多只是看不到智能推荐，核心功能不受影响。接口不稳定是外部依赖的常态，你不能把它当例外。

数据隐私这块，真的别等出事才处理。我们有个实验场景把测试库工号传给了外部API，后来被安全团队发现，差点整条业务线被停。从那以后，不管内部还是外部数据，统一走脱敏网关，所有模型输入输出都会留审计日志。这个坑一旦踩了，补代价极高。

6.2 快速自查清单

如果你现在已经被经理推进AI项目，动手前花五分钟过一遍这份清单：

• [ ] 业务目标是否明确，能不能用一句话说清楚“用户得到什么”
• [ ] 当前数据质量是否足以支撑模型效果
• [ ] 是否已经想好失败降级方案
• [ ] 模型调用是否有限流和预算监控
• [ ] prompt和模型版本做了版本管理没有
• [ ] 输出是否有schema校验和人工兜底
• [ ] 是否建立了简单评估集，保证后续改动不倒退
• [ ] 核心代码是否通过防腐层隔离AI依赖
• [ ] 风险是否已同步给经理和团队

如果清单里有超过三项没做，我建议你先暂停编码，回去补设计。不要觉得这些是流程上的负担，它们就是你在混乱需求下保护自己不被半夜叫起来修线上问题的保险。

6.3 最后再分享一点个人心得

我记得最早一次接到经理“塞AI需求”的时候，我也觉得他疯了。后来我转变了心态：他拍脑袋没问题，因为我可以通过工程方法把他的想法变成可验证的选项。真正可怕的不是经理提了个不懂技术的需求，而是工程师不思考就直接照做，或者不试就说做不了。这两种极端都会让团队陷入更差的情况。

后来我每次遇到“AI bs”式的需求，都会先默认它至少有一分价值，然后用POC去放大或证伪这一分价值。如果放大，我就继续投入；如果证伪，我用数据来体面叫停。这套打法既维护了和经理的关系，也没有把代码库变成一个AI玩具场。希望你也能用起来，把主动权抢回自己手里。