2026-10-14 秋招XX AI测试开发一面复盘

10月14日晚参加了AI测试开发的一面。自我介绍之后主要聊项目，中间穿插了Linux、MySQL和AI辅助研发流程的问题。下面按问题整理参考回答。

如何跟踪持续增长的日志

场景是程序不断往一个日志文件里写内容，希望在终端里持续看到新增日志。

可以用：

tail -f app.log

tail 默认显示最后10行，-f 会继续跟踪文件末尾的新内容。如果想先看最近100行，再继续跟踪，可以写成：

tail -n 100 -f app.log

如果日志会轮转，比如原文件被改名，程序又创建了一个同名日志文件，更适合用：

tail -F app.log

GNU tail 的 -f 默认跟踪已经打开的文件描述符，原文件改名后仍可能继续跟着旧文件。-F 相当于 --follow=name --retry，会按文件名跟踪，并在文件暂时不存在时继续尝试打开，适合这种日志轮转场景。GNU Coreutils：tail

先分清想看整台机器的内存，还是某个进程的内存。

看系统整体内存，可以用：

free -h

-h 会用较容易读的单位展示物理内存、交换空间等信息。判断还能分配多少内存时，可以关注 available，它估算的是不使用交换空间时，可供新应用使用的内存，不能只看 free 一列。procps-ng：free

想看哪些进程占用较多，可以用 top 动态观察，也可以直接按内存占比排序：

top -o %MEM

进程列表里的 RES 是驻留物理内存，%MEM 是它占整机物理内存的比例；VIRT 是虚拟内存大小，不能直接当作实际占用的物理内存。procps-ng：top

如果已经知道进程ID，只想看它当前的内存信息，可以用：

ps -p 1234 -o pid,comm,%mem,rss,vsz

这里的 1234 换成实际进程ID。rss 是驻留物理内存大小，vsz 是虚拟内存大小，单位都是KiB。ps 给的是查询时的快照；需要持续观察变化时，用 top 更方便。procps-ng：ps

WHERE 在分组前过滤行，决定哪些记录参与后续分组和统计；HAVING 对分组后的结果做过滤，可以使用 COUNT、SUM 等聚合结果作为条件。MySQL：SELECT

比如，想统计每个部门工资超过10000的员工人数，并且只保留这类员工超过5人的部门，可以写：

SELECT department, COUNT(*) AS employee_count
FROM employees
WHERE salary > 10000
GROUP BY department
HAVING COUNT(*) > 5;

先由 WHERE 筛出工资超过10000的员工，再按部门分组，最后由 HAVING 筛出计数超过5的部门。这里数的是每个部门中工资符合条件的人，不是部门总人数。

像 salary > 10000 这样针对单条记录的条件放在 WHERE；像 COUNT(*) > 5 这样针对当前分组聚合结果的条件放在 HAVING，不能直接拿到同一层查询的 WHERE 里用。

项目部分还问到了AI辅助开发工具，以及它们在整套研发流程里分别做什么。

AI Coding主要帮助开发者生成、修改和理解代码，也可以辅助调试和编写测试。CR通常指Code Review，也就是代码审查，主要围绕一组代码变更检查问题。两者有交集，但关注点不同：写出修改是一件事，检查这次修改是否合适、会不会引入问题，是另一件事。

代码审查通常围绕PR或MR进行：开发者提交变更，发起合并请求，审查者阅读差异、提出意见，开发者再修改。审查通过并满足项目的其他合并条件后，才进入合并环节。GitHub：Pull request reviews

AI可以辅助找出潜在问题，但审查意见还需要结合代码上下文判断，也需要测试验证。一次审查给出了建议，并不等于问题已经修复。

如果要把代码审查接入工单流程，还需要记录问题对应的代码位置、处理人和状态，在修复后重新检查，确认原问题是否解决。这样才能从“给出一份审查意见”继续走到“跟踪问题的处理结果”。这也是介绍这类项目时需要说明的部分：模型负责什么，流程负责什么，最后怎样确认问题处理完成。