最近这事挺有共鸣。我们经理去外面转了一圈回来晨会就拍板“明年产品必须全面接入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功能直接在网上找到一段示例代码CtrlC到项目里然后几个service到处调LLMprompt写在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 把风险清单递上去让老板做知情决策最后学会用“风险登记表”来管理老板们的预期。不要口头说“有风险”而是抛一张纸条过去上面写清楚风险、等级、概率、影响和缓解措施。举个例子风险项等级可能性影响缓解措施模型输出幻觉导致用户误导高中高人工审核限定输出模板外部API成本失控中中中限流、缓存、预算报警数据隐私合规风险高低极高数据脱敏、私有化部署备选长期维护人力和技术栈落后风险中高中独立模块隔离、完善文档递出去之后平静地问一句“这些风险我们认可接受并且按缓解措施来执行那么项目就可以往下走。您确认的话我们需要再申请对应资源。”这一招相当管用。因为当风险被书面化后经理就很难再用“不知道”来推卸责任。一旦他确认了后面项目出情况你也有据可查不会自己一个人背锅。6. 常见问题快查表与实际经验6.1 踩坑实录prompt失控、模型幻觉、接口稳定性、数据隐私我把这两年被AI功能坑过的场景都过一遍。最经典的是prompt失控——明明线上版本一切正常某天有同事改了prompt里一个词结果所有结果都变了风格而且没有测试覆盖。后来我们把prompt版本化和评估集当作硬性要求才止住这种低级问题。模型幻觉不用多说AI一本正经地编造数据客服回答里出现虚假优惠推荐理由写得天花乱坠但推荐的未必存在。解决办法只有两层一层是靠工具强制约束输出比如用枚举和模板另一层是在关键业务流里保留人工复核环节。记住模型输出永远只能当“草稿”而你已经认可的“定稿”才能进入用户界面。接口稳定性问题也很要命。早先我们接外部模型API时遇到对方限流结果没做重试用户眼看着白屏。后来老老实实加了超时、重试、熔断和降级逻辑。现在每次模型故障用户最多只是看不到智能推荐核心功能不受影响。接口不稳定是外部依赖的常态你不能把它当例外。数据隐私这块真的别等出事才处理。我们有个实验场景把测试库工号传给了外部API后来被安全团队发现差点整条业务线被停。从那以后不管内部还是外部数据统一走脱敏网关所有模型输入输出都会留审计日志。这个坑一旦踩了补代价极高。6.2 快速自查清单如果你现在已经被经理推进AI项目动手前花五分钟过一遍这份清单[ ] 业务目标是否明确能不能用一句话说清楚“用户得到什么”[ ] 当前数据质量是否足以支撑模型效果[ ] 是否已经想好失败降级方案[ ] 模型调用是否有限流和预算监控[ ] prompt和模型版本做了版本管理没有[ ] 输出是否有schema校验和人工兜底[ ] 是否建立了简单评估集保证后续改动不倒退[ ] 核心代码是否通过防腐层隔离AI依赖[ ] 风险是否已同步给经理和团队如果清单里有超过三项没做我建议你先暂停编码回去补设计。不要觉得这些是流程上的负担它们就是你在混乱需求下保护自己不被半夜叫起来修线上问题的保险。6.3 最后再分享一点个人心得我记得最早一次接到经理“塞AI需求”的时候我也觉得他疯了。后来我转变了心态他拍脑袋没问题因为我可以通过工程方法把他的想法变成可验证的选项。真正可怕的不是经理提了个不懂技术的需求而是工程师不思考就直接照做或者不试就说做不了。这两种极端都会让团队陷入更差的情况。后来我每次遇到“AI bs”式的需求都会先默认它至少有一分价值然后用POC去放大或证伪这一分价值。如果放大我就继续投入如果证伪我用数据来体面叫停。这套打法既维护了和经理的关系也没有把代码库变成一个AI玩具场。希望你也能用起来把主动权抢回自己手里。
