你正在写一个无关紧要的配置模块经理从线上开会回来丢下一句我们得在这个版本里把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还是本地模型。具体来说定义一个接口比如AiServicepublic 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相关想法不需要空口探讨直接按清单打分评估。这样能把个人的主观判断变成团队共识经理也会觉得流程严谨而不是你在刁难。这张评估清单可以包含但不限于以下维度维度问题权重业务价值这个AI功能能带来多少用户价值或内部效率提升30%数据完备性我们有哪些数据或历史样本可以支撑模型训练/验证20%技术可行性当前技术栈和团队能力能否实现20%成本与维护上线后的API成本、人工审核成本、模型维护成本有多高15%风险与合规输出错误会导致什么后果有没有合规红线15%每一项按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热潮希望也能帮你。