蚂蚁集团二面面经（CIO 线）：CLI 编译分发、Skill 设计与 AI 时代的内部基建

《面试题目》

面试提问

1. 现在还在实习吗？为什么要离开 Shopee？
2. 在 Shopee 实习下来，自己的感受是什么？
3. 你在 Shopee 得到的最大的锻炼是什么？
4. 你这里面涉及了一些 CLI 的开发，包括我看到有 CLI 的编译、分发链路，你这个链路是怎么做的？详细一点介绍一下。
5. 还写了 Skill，CLI 的 Skill 是做什么的，具体怎么设计的？
6. 在做 CLI 的这个过程中，你遇到了什么困难？
7. 实习经历很丰富，简历上看到三家公司负责的事情不太一样，业务也不完全相同，这三个工作大概给你的感受是什么样的？
8. Shopee 那边转正的情况怎么样？还有其他的 Offer 吗？
9. 自我介绍的时候，你说自己倾向于做企业内部基建，现在是 AI 时代，你认为 AI 和企业基建的关系是什么？

候选人反问

10. 业务的数据源是哪里？数据要怎么处理？数据的消费方是谁？是怎么消费的——写 Skill 还是做 RAG？
11. 初步数据的处理是谁在做？用 Flink 还是有其他的东西？
12. 会涉及数据计算引擎的个性化开发与维护吗？
13. 和您探讨一下 AI 时代对于校招同学的要求。

（帖内提到：面试原定 11 点开始，面试官因线上问题迟到约 10 分钟，全程 37 分钟，其中反问约 7 分钟。）

《参考解析》

CLI 的编译与分发链路该讲哪几层。 这类问题面试官想看的是你有没有把工具当成一个「要给别人用的产品」来做，而不是本地跑通的脚本。链路可以按四段讲：构建——用什么语言与打包方式（Go/Rust 编静态二进制、Node 用打包器产出单文件、Python 用 zipapp 或打包成可执行）、多平台多架构交叉编译、版本号与变更记录、可复现构建（锁定依赖、固定工具链版本）。产物管理——把编译产物推到制品库或对象存储，目录按版本与平台组织，同时产出校验和与签名，保证下载的东西和构建出来的东西一致。分发与安装——一键安装脚本（curl 到本地执行）、包管理器渠道（npm/brew/apt 等）、私有源的鉴权与代理、内网镜像加速；要处理 CPU 架构识别、依赖探测、权限与路径问题。升级与回滚——内置自更新检查、灰度放量、版本钉住与强制升级开关、升级失败回滚（保留上一版本二进制、原子替换而非覆盖写）。踩坑点很集中：本地能跑、换机器缺动态库；macOS 签名与公证；Windows 路径与换行；企业代理与证书；不同 shell 的配置文件差异。把这些讲出来，面试官自然相信你真的分发过。

CLI 的 Skill 是什么、怎么设计。 在 AI 工具链里，Skill 是把「某类任务的做法」封装成可复用、可按需加载的能力包，通常包含三部分：说明（什么时候用、边界在哪、失败怎么处理）、可执行能力（脚本或 CLI 子命令）、资源与模板（提示词片段、配置样例、参考文档）。设计要点：一是触发描述要精确，写清使用场景与不适用场景，否则加载时机错了反而干扰模型；二是渐进式加载，正文只放必要信息，细节放在按需读取的文件里，避免每次对话都占满上下文；三是确定性优先，能由脚本算的（解析、转换、校验）不交给模型推理，模型负责判断与组织；四是可验证，产出有明确的结构与验收标准，跑完能自查；五是版本与依赖声明，脚本依赖的 CLI 版本要写清，缺失时给出可执行的安装提示而不是静默失败。常见的错误是把它写成一大段提示词而没有可执行部分，或者把多个不相关的任务塞进同一个 Skill 导致触发混乱。

实习经历、离职原因与转正问题怎么答。 这三类问题在二面里几乎必问，本质是评估稳定性和职业成熟度。讲实习收获时给「能力变化」而不是「工作感受」：比如从只会按需求实现，到能自己定义问题边界、能独立推动跨团队依赖、能把一次排查沉淀成可复用的工具。回答离职原因要中性、聚焦在「我要什么」而不是「原来那里差在哪」——例如实习期结束、原团队没有合适的转正方向、想做的方向与团队重心不一致，都可以直说，但避免抱怨具体的人或流程。三段实习对比是很好的展示机会：把三家公司分别给你的东西讲成互补的三块（一家给工程规范与协作、一家给业务理解、一家给从零做工具的能力），并落到「所以我判断自己适合做内部基建」这个结论上。至于转正与其他 offer，如实回答即可，同时表达清楚选择的优先级与理由；如果手里确实有别的流程，说明时间点，别含糊其辞——面试官问这个是在评估你能不能来、什么时候能来。最后，反问是二面里唯一能自己控场的时间，像帖主那样围绕业务数据源、数据消费方式、是否自研计算引擎提问，既确认了岗位实质，也顺带展示了自己的技术视野。

AI 与企业内部基建的关系。 这道题适合给一个有层次的判断：第一层，AI 是内部基建的新「消费方」——过去基建服务的是人与应用，现在还要服务 Agent，这意味着接口要机器可读、权限要能细粒度委派、操作要可审计、错误信息要可执行，基建的「用户体验」从页面变成了 API 与工具描述。第二层，AI 也是内部基建的新「生产工具」——写代码、写测试、生成文档、做数据清洗、把重复排障流程自动化，能显著降低做基建的人力成本；但前提是数据资产本身被治理好。第三层，也是最关键的一层，是数据与上下文的治理成为 AI 落地的前提：企业里大量的知识散落在文档、工单、代码、聊天记录和数据库里，格式不一、权限混乱、时效不清，直接喂给模型只会产生漂亮而错误的答案；所以需要有人把数据源接进来、清洗、打上元数据（来源、负责人、更新时间、权限），再以 Skill、检索或指标的形式提供给消费方。这正是「企业数据资产上下文工程」的价值所在。往上再走一层是治理与安全：谁能用哪些数据、模型的输出如何追溯、哪些动作必须留人工确认，这些都是基建要提供的护栏。能讲到「AI 让基建从支撑系统变成生产力系统，同时也让数据治理第一次有了明确的买单理由」，这题就答得很有高度了。