快手 Java 开发日常实习一面凉经（商家技术电商）

《面试题目》

1. 自我介绍
2. 后面工作的方向有没有自己的思考和规划？
3. 你的 AI coding 项目「分布式脚本执行服务」是怎么实现的，讲讲思路和过程？
4. 假如现在让你从 0 到 1 实现一个大型项目，你觉得可以通过哪些 harness 手段来确保 AI 帮你生成项目的质量和准确性？
5. 如果这个项目是 10 万行左右的代码，在项目迭代中你怎么确保质量？有哪些工程上的手段？
6. 你项目里的上下文是怎么做的？
7. 项目里有很多工具，怎么保证工具调用？
8. 假如线上出现 CPU 打满告警，怎么定位和排查？
9. 假如你这个项目要推广到公司的全业务线架构上，怎么设计？
10. 怎么支持多数据源？
11. 反问

《参考解析》

1. 用「能自我验证」的工程手段保证 AI 生成代码的质量：核心思路是把验收标准前移到生成之前，让模型写完能自己判断对不对。具体几层：一是把项目约定写进仓库（目录结构、命名、错误处理方式的示例代码），让模型照抄而不是自由发挥；二是生成后必须过确定性的闸门——类型检查、lint、单测、构建，红了就退回让模型改，人不看没通过闸门的代码；三是把「不许做」的边界写进代码本身（类型只有一个源头、禁止 as any、禁止吞异常），靠工具拦而不是靠人盯。真正有效的 harness 不是加更多规则文档，而是让「错了会被立刻发现」这件事自动化。

2. 十万行规模怎么保证迭代质量：这个量级靠人评审已经不可行了，得靠分层。接口层用类型系统把契约钉死，改一处编译期就报错；模块边界清晰，让改动的影响范围可预测；关键路径有端到端探针（真链路跑一遍，而不是只跑单测），因为单测绿不等于链路通。再加一条：把「不变量」写成可执行的东西（schema 校验、构建期断言），而不是写在文档里等人记。

3. 上下文工程：分三层看——短期是当前任务的对话窗口，中期是把已完成工作和结论落盘成仓库里的文件（比留在对话里可靠），长期是跨会话的项目记忆。关键取舍是「什么该进 prompt、什么该让模型自己去查」：把所有东西都塞进窗口会稀释注意力、也更贵；正确做法是给模型检索的工具和稳定的入口（比如先读哪几个文件），按需拉取。压缩摘要时要保留可追溯性，别把「为什么这么改」的决策丢掉。

4. 工具调用可靠性：工具多了以后出错主要是两类——选错工具、参数不合规。选错靠改描述解决（写清触发条件和适用边界，缩短互相重叠的描述），参数靠 schema 校验拦截并把报错原样回灌给模型自修正，同时设重试上限避免死循环。工程上还要有兜底：工具有副作用时保证幂等（幂等键 / 先去重），失败要能被观测到（结构化日志 + 计数），否则出错是静默的。

5. 线上 CPU 打满怎么查：先止损再定位——限流或摘掉异常实例，避免影响扩大。然后按「是单机还是全量」分流：全量说明是流量或下游变更，单机先怀疑该实例上的热点。定位顺序一般是 top 看是哪个进程、进程内 top -H 看哪个线程，把线程 id 转 16 进制去 jstack 里找栈；如果线程都在跑业务逻辑，看是不是死循环、正则回溯、频繁 GC（GC 线程占用高就 dump 堆分析）；如果 CPU 不高但响应慢，那可能是锁竞争或 IO 等待，属于另一类问题。最后一定要回到「最近改了什么」——灰度、配置、依赖版本。

6. 怎么支持多数据源：抽象掉「连接从哪来」和「SQL 长什么样」两件事。路由层按数据源标识选择连接（配置化注册，新增数据源不改代码）；方言差异用统一的查询构造层收敛，避免业务代码里拼各家的 SQL；事务边界要显式，跨数据源的事务不能假装是原子的，要么用最终一致 + 补偿，要么明确拒绝跨源写。分页、类型映射、超时和连接池参数这些容易踩的点也要在抽象层一次做对，否则每个接入方都会踩一遍。