北京
上周和一位在班加罗尔待了四年的朋友吃饭，他说了句让人愣住的话："现在不是讨论AI能做什么的时候了，我们在做的事，是让公司本身变成AI的容器。"他指的是一家美国零售巨头在印度的布局——不是简单采购几个模型接口，而是把AI嵌进采购、库存、收银、排班的每一个毛细血管里。
《印度时报》拿到了一组内部数据：这家零售商目前在印度的技术团队规模已超过其在硅谷总部的工程师数量。团队结构也完全不是传统的外包模式——印度这边负责核心算法的训练与部署，美国那边更多在做前端体验和商户关系。一位参与项目的工程师对媒体描述："我们写的不是某个功能的代码，是在重新定义公司操作系统。"
这一转向背后的逻辑值得拆解。过去三年，零售业的AI应用大多停留在"用AI"的阶段——客服机器人回答退货政策、推荐引擎猜测你还想买什么、仓储系统告诉你哪个货架快空了。这些功能的共同点是：AI是外挂，主系统不需要它也能跑。而现在这家零售商尝试的路子是"跑在AI上"——核心业务流程的调度权逐步交给模型，人的角色从操作者变成了监控者和例外处理者。
正方观点认为这是必然方向。人力成本、库存损耗、门店坪效，零售业的利润像毛巾里的水，拧了几十年，能挤的都挤完了。AI不是锦上添花，是下一波效率红利的唯一来源。而且印度的工程师池提供了"不可能在美国达到的迭代速度"，一位印度裔高管在内部信里这样写道。
反方的担忧同样具体。把供应链决策权交给模型，出了错谁来担责？一次采购偏差可能造成数百万美元的过期损耗。更隐蔽的风险在于，当数千家门店的运行节奏都被同一个系统调控时,故障不再是一座孤岛——2023年感恩节当天某云服务宕机导致其电商瘫痪四小时的旧账，至今还在董事会的复盘文件里挂着。
《印度时报》在报道中指出了一点容易被忽略的事实：团队的真正瓶颈不在模型精度，而在数据质量。印度团队花了整整七个月清洗历史库存记录，发现超过11%的入库时间戳存在偏差，3%的货品编码重复。一位数据工程师的原话是："我们以为自己在训练AI，其实头半年只是在教公司怎么记账。"
我的判断倾向于正方的方向，但反方的问题才是真正的关卡。零售业和互联网产品不一样——后者可以灰度发布、快速回滚、用A/B测试慢慢磨出最优解。但一家实体门店的库存预测错了，货架上就是真的空了，顾客是真的走了。这意味着"跑在AI上"不是技术问题，是组织问题：谁有权限叫停模型、人工介入的触发阈值设在哪里、一线店长的经验如何被编码进系统反馈闭环里。
报道里提到的一个细节让人印象深刻。印度团队在试点门店的后台装了一个物理按钮，店长如果觉得AI的补货建议明显不合理，按下按钮就可以切换回人工决策模式，同时按钮按下的那一刻的系统快照会自动上传到模型团队做归因分析。这个设计不像硅谷风格，更像在孟买街头学到的智慧——承认不确定性，用可逆的机制对冲风险。
另一篇配套分析指出，这家零售商的印度技术中心过去十二个月的招聘方向发生了明显变化。纯算法岗位的比例在下降，增长最快的是两个看似相悖的角色：懂零售业务的数据产品经理，和做模型可解释性的工程师。这个信号比任何行业报告都更诚实地说明了竞争正在走向哪里——不是堆参数，是在现实世界的约束条件下让AI稳定地产生商业回报。
对于在看类似方向的公司，有三条参考线值得标在墙上：先跑通一个窄场景的端到端闭环，别急着铺全业态；把成功标准定在业务指标上，不要用"模型准确率"安慰自己；从第一天就让业务负责人和工程团队坐在一间屋子里。报道特别强调，在这家零售商的印度办公室里，商品部门的采销老员工和25岁的算法工程师共用同一排工位，背景完全不同的人因为共享同一组KPI而被迫找到共同语言。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
