在公司做 Android 稳定性的,应该都经历过这种时刻:
GKI 升级一来,几百个 commit,像洪水一样拍你脸上。
SPM/测试部都拉着你,想要你评估这次GKI升级的测试建议。
虽然很想说FullTest!!!测试没人力和我没关系!但是吧,有时候就是会很无奈。
比如从 android13-5.15-2025-01_r1 升到 android13-5.15-2025-01_r7,但带进来一串 upstream/backport/Android 特有 patch——里面有文件系统、有网络、有 bpf/vsock、还有一堆你根本不关心但必须确认的 ABI 维护提交。
你不可能每一笔都细看 diff;但你又必须回答:
这次升级改了哪些模块?
有没有明显的稳定性/性能/安全风险?
QA 回归应该先测什么?怎么排优先级?
哪些 commit 必须人工复核?
问题是:提交多、信息碎、时间不够、容易漏。
我不想每次都靠“经验 + 直觉 + 焦虑”,所以写了一个工具:Aegis(神盾)。我自己取的代号,后续我写的一些小工具我都会取一个比较酷的代号- 。-
好了,下面介绍一下这个小工具:
这个工具解决了什么问题?
把“提交列表”变成“影响分析”
你需要的不只是 commit subject,而是:
这笔改动在改什么(what_changed)
它想解决什么问题/bug(problem_fixed)
风险点是什么(stability/perf/security/compat/abi…)
对应应做哪些模块级回归方向(suggested_tests)
以及 AI 的置信度(confidence)
并且这些信息最好能被程序继续消费(比如做排序、做汇总、做可视化)。
把“泛泛的回归建议”变成“与本次升级强相关的策略”
传统“通话/WiFi/蓝牙/相机/音频/…全测一遍”不是不对,但它不够“贴合”。
Aegis 的目标是:根据本次变更的模块、风险类型、提交语义,生成更可执行的回归重点。
把“报告”变成“可交付件”
最终输出一个 HTML:
顶部整体总结(AI 生成)
图表:模块分布、风险分布、变更规模
高风险 commit 卡片列表(可搜索)
点击 commit 弹窗展示:AI 分析 + touched files + diff(可截断)
这玩意儿能直接丢给项目、QA、甚至老板:“看这个,优先测这些。”
这个工具能够得到什么?
Aegis 会产出三类东西:
每个 commit 都产出统一 schema 的 JSON(核心资产)
{
"module": "NET",
"module_candidates": [{"name":"NET","score":0.82,"reason":"..." }],
"suggest_new_module": null,
"what_changed": "…",
"problem_fixed": "…",
"evidence": ["…"],
"risk": [{"type":"stability","detail":"…"}],
"suggested_tests": ["…"],
"confidence": 0.73
}
为什么要结构化?
可排序:按 risk_score 排 “Top 风险提交”
可聚合:按 module 汇总,算 insert/delete,算风险累计
可追踪:每条 suggested_tests 能追溯来自哪些 commit
可视化:chart 一画就出来了
你最终产出的 HTML 报告,本质就是把这个 JSON “消费”了一遍。
Markdown 报告(方便 diff / 存档 / CI)
render_markdown() 输出包括:
模块统计(commit 数、insert/delete、风险累计)
Top 高风险列表(用于优先回归)
按模块分组的 commit 明细
低置信度/信息不足项(提醒人工复核)

炫酷 HTML 报告(面向“读者”)
render_fancy_html() 是真正让工具“产品化”的部分:
图表、卡片、搜索、弹窗、主题、甚至“AEGIS-神盾”的 branding。





Aegis 的核心设计
校验 tag 并获取 commit 范围
使用:
git rev-parse --verify <tag>git rev-list --reverse old..new
提取 commit 信息
用 git show 拿到了:
--format:sha/subject/author/date/body--shortstat、--stat--name-onlygit show sha作为diffdetail
本地规则 + 关键词做模块候选
路径前缀规则(硬规则):
mm/-> MM,fs/-> FS,net/-> NET…关键词 hint(软提示):subject/body 匹配
tcp/udp-> NET,f2fs-> FS…
这样做的好处是:
即使 LLM 摆烂,也能给出基本模块归类,并且把候选传给模型能减少它“乱猜”。
AI 逐提交分析
用 ThreadPoolExecutor 做了并发 worker,并做了:
sleep控制节流失败 fallback(不会让全流程崩掉)
针对 GKI symbol list 更新做 shortcut(不调用 LLM,直接低风险归类)
像 ANDROID: GKI: Update symbol list ... 这种提交,调用 AI 是浪费钱+浪费时间
这里也是我花费时间最多的地方,主要是这个提示词,一直调的不够好,这里也列一下几段提示词,后续还是要继续优化一下!!!
AI分析的好不好,全靠提示词写的怎样!
每一笔commit进行分析的提示词
system提示词
SYSTEM_PROMPT = """你是一位资深的内核安全与稳定性专家,专门负责Android/Linux内核的代码审查与分析,特别是在Android手机GKI升级评估方面有丰富经验。
你将收到一个内核提交的信息(提交信息、涉及文件、统计信息、以及相关的链接摘要)。
你的任务:输出严格的JSON格式结果,用于生成Android手机GKI升级影响分析报告。
重要要求:
1) module字段必须从提供的MODULE_LIST中选择一个;如果无法匹配任何模块,使用module="OTHER",并提供suggest_new_module(字符串)及原因。
2) 所有输出内容必须使用中文
3) 不要编造不存在的事实;信息不足时使用"unknown",并相应降低置信度
4) evidence必须基于输入信息(提交信息/文件/统计/链接摘要),用简短句子描述
5) suggested_tests必须提供具体的、可执行的Android手机测试项目,针对模块级和功能级测试
6) 只输出JSON,不要包含其他任何文本
分析维度:
1) **风险评估**:评估此提交对Android手机的安全性、稳定性、性能、兼容性、ABI等风险
2) **问题修复**:描述此提交修复的问题或引入的新功能,特别关注对Android手机的影响
3) **性能分析**:如果涉及性能改进或可能影响性能,详细说明对Android手机用户体验的影响
4) **依赖性分析**:分析此提交与其他提交、模块或Android系统功能的依赖关系
5) **安全性**:如果涉及安全漏洞或修复,详细说明对Android手机安全性的影响
6) **推荐测试**:根据提交内容和风险评估提供具体的Android手机测试项目
特别针对Android手机的测试建议需要包含但不仅限于:
- 模块级功能测试(如:调度器压力测试、内存压力测试等)
- Android特定功能测试(如:应用兼容性、系统服务、HAL层测试等)
- 性能测试(如:应用启动时间、系统响应速度、电池续航等)
- 稳定性测试(如:长时间运行测试、压力测试、热测试等)
- 兼容性测试(如:应用兼容性、驱动兼容性、外围设备兼容性等)
- 安全性测试(如:权限检查、安全策略验证等)
JSON schema:
{
"module": "string",
"module_candidates": [{"name":"string","score":0.0,"reason":"string"}],
"suggest_new_module": null | "string",
"what_changed": "string",
"problem_fixed": "string",
"evidence": ["string", ...],
"risk": [{"type":"stability|performance|power|security|compat|abi","detail":"string"}],
"suggested_tests": ["string", ...],
"confidence": 0.0
}
"""user提示词
user = f"""背景:这是一个Android手机GKI内核升级的提交分析。请特别关注对Android手机的影响。
MODULE_LIST = {json.dumps(modules, ensure_ascii=False)}
Commit: {ci.sha}
Subject: {ci.subject}
Author: {ci.author} <{ci.email}>
Date: {ci.date}
Message body:
{body}
Parsed tags (from body): {tags_json}
Shortstat:
{ci.shortstat}
Diffstat:
{ci.diffstat}
Touched files (first 200):
{chr(10).join(ci.files[:200])}
Diffdetail:
{ci.diffdetail}
Rule-based candidate modules: {rule_modules}
Keyword-hint modules: {hint_modules}
Linked context (best-effort, may be none):
{link_block if link_block else "none"}
请特别考虑以下Android手机相关的测试方向:
1. 功能测试:通话、网络、蓝牙、WiFi、相机、音频、传感器、显示、触控等
2. 性能测试:应用启动时间、系统响应速度、游戏性能、多任务切换、电池续航
3. 稳定性测试:长时间运行、压力测试、热测试、Monkey测试、重启测试
4. 兼容性测试:应用兼容性、驱动兼容性、外围设备兼容性
5. 安全性测试:cts/vts/gts等测试,权限检查、安全策略、漏洞验证
"""最后汇总所有commit进行分析的提示词
system提示词
你是Android内核架构师和GKI升级专家,专注于Android手机的内核升级评估,用中文提供专业、具体、可执行的建议。user提示词
summary_prompt = f"""你是一位资深的Android内核架构师和GKI升级专家。请对以下Android GKI内核版本升级进行整体评估分析,特别针对Android手机设备:
升级范围:{old_tag} → {new_tag}
总提交数:{total_commits}
模块统计:
{json.dumps(module_stats, indent=2, ensure_ascii=False)}
风险类型分布:
{json.dumps(risk_type_counts, indent=2, ensure_ascii=False)}
高风险提交(risk_score >= 3)列表:
{[{'sha': c['sha12'], 'subject': c['subject'][:100], 'module': c['module'], 'risk_score': c['risk_score']}
for c in sorted(all_commits, key=lambda x: x.get('risk_score', 0), reverse=True)[:10]]}
以下是根据每个提交提取的测试建议:
{json.dumps(all_test_suggestions, ensure_ascii=False)}
测试策略不仅限于下面:
- 功能测试(通话、网络、蓝牙、WiFi、相机、音频等)
- 性能测试(应用启动、游戏性能、多任务等)
- 稳定性测试(Monkey测试、压力测试、长时间运行等)
- 兼容性测试(应用兼容性、驱动兼容性等)
- 安全性测试(权限检查、安全策略等)
请从以下几个方面提供详细的中文分析,特别关注对Android手机的影响:
1. **整体风险评估**:基于所有提交的聚合分析,评估本次升级对Android手机的整体风险等级(高/中/低)及具体理由
2. **关键变更领域**:识别最重要的变更模块和对Android手机的影响面,说明主要关注点
3. **Android手机安全性影响**:分析对Android手机安全性的影响,包括安全修复、潜在漏洞等
4. **Android手机稳定性影响**:评估对Android手机系统稳定性的影响,包括可能引入的崩溃、死机、重启等问题
5. **Android手机性能影响**:分析可能的性能变化(应用启动、系统响应、电池续航、发热等)及原因
6. **测试用例**:要综合所有commit的suggested_tests,按以下要求提供:
- 必须覆盖所有提交中提到的测试项,不允许遗漏
- 按测试类型分类,分类不仅限于:功能测试、性能测试、稳定性测试、兼容性测试、安全性测试
- 根据问题commit命中测试分类后,每个分类下至少包含3-5个具体可执行的测试用例
- 标记哪些是高频建议的测试项(被多个提交推荐的)
- 确保每个测试用例都是针对Android手机的具体操作步骤
7. **需要特别关注的提交**:列出对Android手机影响最大的3-5个提交及原因,说明需要重点测试什么
请以JSON格式返回分析结果,所有字段内容都使用中文:
{{
"overall_risk_level": "高|中|低",
"overall_risk_score": 0-10,
"key_changes": ["string", ...],
"security_impact": "string (详细说明对Android手机安全的影响)",
"stability_impact": "string (详细说明对Android手机稳定性的影响)",
"performance_impact": "string (详细说明对Android手机性能的影响)",
"regression_test_strategy": "string (详细的Android手机测试策略,按照序列号换行)",
"suggestion_test_cases": "json (具体的测试用例)",
"upgrade_recommendations": ["string (具体的升级建议)", ...],
"critical_commits": [
{{
"sha": "string",
"reason": "string",
"action": "string (具体的测试或验证建议)"
}}
],
"summary": "string (详细中文总结,重点说明对Android手机的影响)"
}}整体总结 + 报告渲染
AI返回的数据
单笔commit分析的数据

generate_overall_summary():把聚合后的模块统计、风险类型分布、高风险提交列表发给 LLM,让它产出“整体结论 + 回归策略 + 关键提交”

render_markdown()/render_fancy_html():把 AI输出回来的结果 渲染成报告
这样的一个工具就完成了,很简单吧!
我会如何评价 Aegis 的价值?
我觉得它的价值不在于“AI 多聪明”,而在于它改变了我的工作方式:
以前:我盯 git log,靠经验归类,写回归建议
现在:工具产出结构化证据链,人只做关键复核
最后交付给Team的,不再是“我觉得要测这些”,而是:
这次升级涉及模块分布
高风险提交排名与理由
每笔提交的 evidence / risk / suggested_tests
聚合后的回归策略(可追溯)
这就从“经验输出”升级成“工程化产物”。
其实我还想将我司测试部的庞大的测试用例向量化,让AI去根据本次GKI升级的改动来选择具体的测试用例,这才是真正的能够节省大量的人力成本的关键!
但是吧,有可能涉及到公司的保密协议,这部分可能不再会往下继续探索,些许遗憾。。。