企业官网建设流程全解析

你正在写一个无关紧要的配置模块，经理从线上开会回来，丢下一句"我们得在这个版本里把AI加上"。你问加什么AI、解决什么问题、给谁用，经理说"就是那种AI，你懂的，别人都有了，我们不能落后"。

然后你的代码库里就多了一堆调用大模型API的散装函数，界面上多了几个输入框，生成出来的东西没人敢用也没人敢删。这就是很多人正在经历的"AI bs"。我经历过不止一次，也花了很长时间才摸索出一套既不跟经理撕破脸、又能保住代码库和设计质量的处理方法。

这篇文章不是教你拒绝AI，而是教你怎么把一股脑塞过来的"AI bs"消化成真正有价值的功能，或者干净利落地让它死在需求澄清阶段。无论是工程师、设计师还是技术负责人，只要你的团队里有"拍脑袋加AI"的决策者，这篇文章都值得看完。

1. 你面对的到底是真需求，还是"经理式AI上头"

先把"AI bs"这个词拆开。bs在这里不是骂人的话，而是一种状态：需求听起来像AI，但本质上是焦虑、跟风、KPI压力，或者对AI能力的严重误读。要想处理它，第一步不是改代码，而是识别它属于哪种类型。

1.1 三种最常见的"AI bs"类型

我把这些年遇到的"AI bs"归纳成三类，你可以对照一下自己遇到了哪个。

第一种是包装型。一个本来用规则、查表或者传统算法就能解决的问题，被硬生生套上AI的外壳。比如"用AI自动给商品分类"，你打开后台一看，商品总共就五个大类，全部分类规则早就写在代码里了。经理说要"AI分类"，只是为了在汇报材料里多一张图。这种需求的本质是想要一个卖点，而不是一个功能。

第二种是幻想型。经理在大模型Demo里看到了能力，就以为它无所不能。"我们要做一个AI自动写周报、自动给客户发邮件、自动处理所有工单，全自动。"但你仔细一问，他期望的是"不用人看，准确率100%"。这种需求的问题在于它对技术边界完全没有概念。AI的输出是概率性的，不是确定性计算，一旦进入实际业务，错误率的代价可能是灾难性的。

第三种是合理但没想清楚型。这个最棘手，因为它不是纯粹的bs。比如"用AI帮用户总结长文档"，方向对，但经理没想过文档来源是什么、格式有哪些、总结要多长、摘要错了怎么办、延迟能不能接受。这类需求有救，但需要你花时间去把细节磨出来。

1.2 先别急着骂街：识别需求背后的真实动机

遇到这三类需求，最错误的做法是直接说"No"或者说"这很难"。前者会让你变成"挡路的人"，后者会让你的工作量翻十倍但永远交不了差。我吃过这个亏，后来学乖了：先问清楚"为什么要做这个"。

动机不外乎几种：竞争对手加了AI你就得加；销售打单的时候需要一个AI故事；技术团队想尝试新东西；老板在行业会议上听了概念觉得项目要拥抱AI。不同的动机决定了你该怎么应对。

如果是竞争压力，可以去查一下竞争对手的AI功能具体长什么样。你有很大概率发现，对方也只是在聊天框里套了一个Prompt。这个弱化版的"AI功能"，你的团队完全可以用周一上午的时间复制出来，关键是别把它嵌入核心链路。

如果是销售需要故事，那就做个Demo级别的功能，让销售去讲，不用上生产环境。销售并不在意功能真的有多智能，他们在意的是能不能在十页PPT里放一张AI截图。

如果真的有一个具体业务场景需要AI能力，那才开始进入正题。你要做的第一件事，就是把"加个AI"这个模糊指令翻译成一个具体的、可验收的工程任务。

2. 需求澄清的提问清单：把"加个AI"变成可执行任务

我自己的习惯是：任何涉及AI的需求，先拒绝直接进排期，用一到两次会议把它彻底问透。经理可能会觉得你在拖，其实你在帮他排除错误选项。大部分所谓AI需求在第三个问题就会自己崩溃。

2.1 用五个问题逼出真实场景

第一个问题：你要帮用户解决什么痛点？让经理具体描述一个用户操作前和操作后的对比。比如"现在用户要花10分钟读文档，AI让他10秒钟得到结论"。

第二个问题：这个功能的主要用户是谁？是内部员工还是外部客户？是每天用100次的重度用户，还是一个季度碰一次路的边缘用户？用户群决定性能设计、成本投入和容错标准。

第三个问题：现在有没有临时解决方案？如果之前靠手工、靠Excel、靠肉眼，那AI要替代的就是那个工具。替代一个已有的临时方案比创造一个全新方案成功率高得多，因为需求已经被验证过了。

第四个问题：错误发生的概率能接受多少？这是最关键的一个问题。如果AI的准确率是95%，剩下5%的错误用户会看到什么？客户会因为错误流失吗？还是说错了也无所谓？经理如果说"不能错"，那就要么换成规则引擎，要么老老实实做人工复核。

第五个问题：我们有哪些可用数据？没有数据，AI就是空中楼阁。你想做一个"智能客服知识库"，那得先有历史工单、产品文档、常见问题FAQ。什么都没有，大模型再强也答不出你们公司的具体业务。

2.2 判断可行性时，先看数据和成本

五个问题问完，基本能判断这个需求该不该继续。但作为工程师，你还要用数据说话。

先用最小的成本估算一下数据量。一个典型的分类或抽取任务，至少需要几百条标注样本做效果验证。如果团队连几十条真实样本都凑不齐，说明这个需求对应的业务场景根本没有数据沉淀，做一个模型也是无源之水。

再看运行成本。大模型API不是免费的，尤其是生产环境高并发场景。一个小团队的产品，如果每天有1万次调用，光API费用可能就超过了一个开发人员月薪。这个成本不应该由你默默承担，必须让经理知道。你可以做一个粗略的估算表格，把单次调用成本乘以预估调用量，放在会议里给他看。

提示：很多经理对AI成本的认知还停留在"几块钱一个月"。你把账单模型打出来，他自己就会开始重新评估需求。

2.3 一个实际沟通案例：从"AI审核评论"到"敏感词库+规则引擎"

举个例子。去年我们经理提了一个需求："所有用户评论必须用AI过滤，AI觉得不能发的就拦截。"听起来无懈可击吧？AI审核，做不做？

我问了几个问题：现在的垃圾评论是什么类型？最多的是广告、辱骂，还是政治敏感？数量有多大？经理只说了"每天几百条投诉"。

我拉了一个月的历史评论样本，跑了几个简单的关键词规则，发现其中80%以上的违规内容都符合明确的关键词和正则规则，比如"加微信看片""代开发票"。剩下20%是变形词和图片，用AI也未必能准确识别。最后我们定下来的方案是：先用规则引擎做第一道过滤，拦截率80%以上，剩下的进人工队列。AI？一个标准的分类模型都没用上，别说大模型了。

这个方案成本低、速度快、效果可量化。经理想要的"用AI处理垃圾评论"变成了"用技术有效处理垃圾评论"，目标达成，但没被AI绑架。这就是需求澄清的价值。

3. 代码库层面的"防污染"设计：让AI功能是插件，不是肿瘤

有些需求躲不开，确实要做。这时候我们要考虑怎么在不破坏现有系统架构的前提下，把AI功能优雅地加进去。很多人的做法是把大模型的调用直接写在业务代码里，今天加一个函数，明天加一个调用，半年后代码库到处都是call_gpt()，一查还发现是不同人写的不一样。

3.1 用接口与适配器把AI隔离在主业务之外

我推荐的模式是防腐层（Anti-Corruption Layer）。简单说，在你的核心业务和外部AI供应商之间加一层壳，核心业务永远不知道调的是OpenAI、Claude还是本地模型。

具体来说，定义一个接口，比如AiService：

public interface AiService { AiResponse summarize(AiRequest request); // 其他需要的AI能力 }

然后写一个适配器实现这个接口，内部调用大模型API。业务代码只依赖AiService，再也不直接集成某个大模型的SDK。

这样做的好处是：第一，换供应商的时候只需要改适配器，不用动业务逻辑；第二，可以把一些通用逻辑——比如限流、重试、日志、缓存、敏感信息过滤——放在适配器里统一处理；第三，以后不想用AI了，用一个返回固定结果的Mock实现替换掉，就可以瞬间"卸载"AI功能。

很多同学觉得这层抽象是过度设计。等你的某个大模型服务突然涨价、某个API一个月挂了三次、或者上级要求换成国产模型的时候，你就会发现这层壳是救命稻草。

3.2 特性开关和独立部署：随时能关，关了不炸

除了代码隔离，还要有运行时隔离。我强烈建议任何AI功能都加上特性开关（Feature Flag），至少分"全量开""小流量开""仅内部开""关闭"四档。

为什么？因为AI模型的输出是不可控的。你测试的时候写了一个提示词发了五次，结果都正常。上线后第一批用户就触发了一个边缘case，模型回了一段垃圾话。没有特性开关，你就只能紧急发布新版本。有开关，你的操作只有一步：关掉功能，然后慢慢排查。

更彻底的做法是把AI功能做成独立的微服务或Serverless函数，不要和主应用一同部署。主应用通过HTTP或消息队列调用它。这样AI服务CPU跑满、内存泄漏、甚至宕机，都不会拖垮主进程。你还可以单独对它做扩容、做监控、做版本管理。

把AI功能放主进程里跑，就像在公司主水管上接了一个不稳定的水泵。水压一波动，整个楼都停水。

3.3 测试策略：AI不可控，但你的代码可控

AI功能测试是很多团队的盲区。传统单元测试断言一个函数返回某个值，但大模型每次输出的文本都可能不同，不能直接做这种断言。于是很多人干脆不写测试，结果出问题变成玄学。

我建议用契约测试的思路：验证输入和输出的结构，而不是具体内容。比如调用摘要接口，断言返回值包含summary字段，类型是字符串，非空，长度在一定范围内。至于摘要内容对不对，用一组回归样例在集成环境里人工或半自动验证。

更重要的是对异常路径的测试。模型超时怎么办？返回 JSON 解析失败怎么办？内容包含非法信息怎么办？这些都是可以测试的。你需要在代码里写清楚：AI 不靠谱的时候，系统怎么回退？是返回缓存结果、返回默认文案，还是把错误信息传递给用户？这些降级策略才是你代码里最值得测试的部分。

4. 设计层面的兜底与体验：别让用户被AI的自信坑了

代码层面处理完了，接下来是产品体验设计。AI功能做得好不好，一半在模型，一半在交互设计。很多AI功能翻车，不是模型不行，而是产品设计给了用户不该有的期待。

4.1 明确AI的能力边界：是辅助，不是决策者

在设计AI相关界面时，最重要的事情是管理预期。如果你做一个"AI生成周报"的功能，不应该把一个大输入框和生成按钮放在正中央，让用户敲几个词就等结果。更好的设计是提供清晰的模板选项、示例提示词、可编辑的生成结果。

错误示例： ------------------------------------------------ [输入框] [一键生成] ------------------------------------------------ 推荐示例： ------------------------------------------------ 周报要点（选择你的任务）： [ ] 完成登录模块重构 [ ] 修复支付超时问题 [ ] 排查线上告警 可选择风格：简洁 / 详细 / 汇报向 [生成草稿] 生成后的内容可自由编辑，所有内容仅供参考。 ------------------------------------------------

后者之所以更可靠，是因为它把AI限制在了一个明确的任务里，而且用户可以对结果进行修改和控制。同样的道理适用于所有AI生成类功能：AI负责起草，用户负责决策。界面上的按钮文案建议从"一键生成"改成"生成草稿"或"帮你起个开头"，不要制造"一键搞定"的错觉。

4.2 兜底方案与降级策略：模型挂了UI也不能挂

一个生产级AI功能，必须考虑模型失效的兜底。最典型的场景：大模型的API超时了，或者触发了服务端限流，用户点了一下按钮，转圈圈30秒后报错。用户不会觉得是模型服务出了问题，他只会觉得你们产品是垃圾。

我建议设计师和开发一起定义"AI不可用"时的界面形态。比如：

• 正常状态：按钮显示"生成摘要"，点击后显示加载动画；
• 超时失败：自动重试一次，如果还是失败，显示一个友好的错误提示，但界面其余部分仍然可用；
• 降级状态：如果AI功能关闭了，原来的入口收起，或者显示"当前不可用，请联系管理员"。

这里有个残酷的现实：越是AI生成的内容，用户越可能误把AI的错误当成果断。比如AI自动把一封客户邮件归类为"投诉"，但其实是表扬信，用户的处理方式可能完全不同。所以在高风险场景必须设计确认环节，而不是自动执行。

4.3 把用户反馈变成迭代数据，而不是甩锅现场

AI功能上线不等于结束，而是开始。你需要为AI功能单独埋点，收集用户对生成结果的反馈："这个结果是否有用？" "满意/不满意" "哪里不行？"这些反馈是优化提示词和调整模型的重要依据。

同时建议记录每一次AI输出的内容和用户后续操作。比如用户是否修改了AI生成的文本、是否删除重写、复制粘贴了多少次。这些行为信号比直接问用户更真实，能帮你判断AI到底有没有帮上忙。

需要注意一点：用户反馈不要变成"AI背锅"的工具。我之前见过某个产品，用户点击"不满意"之后直接把AI生成的原话和用户操作日志丢给管理员，没有任何聚合分析。这样等于设计了一个投诉通道，但没有人看。正确做法是每周汇总反馈分类，找出最常被吐槽的模式，然后针对性优化。比如如果70%的不满意集中在"摘要太长"，那就去调Prompt里的长度限制。

5. 化被动为主动：把经理从"拍脑袋加AI"变成"和你一起定AI优先级"

处理"AI bs"的终极手段不是每次都去接需求和解释为什么不行，而是建立一套机制，让经理在提出AI需求前就和团队达成共识。这个过程需要一定的软技能，但一旦建立起来，后续会顺畅很多。

5.1 建立团队内的AI需求评估清单

我建议每个团队都维护一份公开的"AI需求评估清单"。每当有人提出AI相关想法，不需要空口探讨，直接按清单打分评估。这样能把个人的主观判断变成团队共识，经理也会觉得流程严谨而不是你在刁难。

这张评估清单可以包含但不限于以下维度：

每一项按0到5分打分，然后乘以权重汇总，总分超过3.5才建议进入立项讨论。这个流程看似死板，却能在经理头脑发热的时候给他一个台阶下："这个想法很好，但按我们的标准，现在数据不足，是不是先做个小规模验证？"

5.2 用最小可行试点代替大承诺

比起直接答应做一个覆盖全体用户、完整功能的AI模块，我更推荐大家引导经理做"最小可行试点"。范围要小、周期要短、效果要看得见。

比如经理想要做"AI智能客服"，不要第一版就做全渠道、全知识库、全自动。先选一个渠道，比如PC网页端，再选一个高频的问题类型，比如"如何重置密码"，把范围限定在100个用户、2周时间。成功标准可以是"用户自助解决率提升10%"。范围小，出错的代价低；周期短，经理很快就能看到东西，愿意继续投入。

试点还有一个隐藏价值：当试点失败，你不需要再去说服经理"这个不靠谱"，因为数据会告诉他。我见过太多项目在完整开发后才暴露出AI效果不达预期，那时候浪费的时间和资金已经收不回来了。小范围试点其实是在保护团队的弹药。

提示：试点一定要定义"什么是成功、什么是失败"。不要只说"试试看"。没有明确成功标准的试点，最后一定会变成"再优化一下就行"的无限期项目。

5.3 让经理变成投资人而不是监工

最后聊一点人情世故。你的经理其实也是被KPI和老板压力推着走的人，他想要的不是代码，而是"我们团队在AI上做了一些事情"这个叙事。只要你能帮他建立这个叙事，他未必非要逼你上某个具体功能。

所以在沟通时，不要只讲困难，更要讲机会。定期整理一份AI行业动态、社区里好用的案例、你们团队可以借鉴的方向，发给经理。你会发现，当你能提出比经理更具体的AI方向时，他就会开始听你的建议，而不是拿着别人家的截图过来让你照着做。

这个转变很关键。你从一个"被安排做AI bs的人"，变成了"团队里AI方向的顾问"。经理不会事事都问你了，但他提想法的时候会先问一句"你觉得这个靠谱吗"。你终于不用再处理那些离谱需求了，因为你已经处在了需求被定义之前的位置。

我在实际工作里的体会是：AI本身不会毁掉一个代码库，毁掉代码库的是盲目的接入和缺乏边界的设计。只要你愿意多花一点时间在需求澄清、架构隔离、体验兜底和向上沟通上，大部分"AI bs"都能转化为可以被衡量、被控制的工程实践，或者干脆在萌芽阶段被体面地枪毙掉。这套方法帮我熬过了好几次AI热潮，希望也能帮你。