很多接口源码分析，最后只完成了一半工作。它们可以把代码讲明白，但讲完以后，测试人员还是得自己继续补三件事：到底哪儿可能有 Bug、数据去哪里找、用例怎么落下来。真正费时间的，恰恰是这三段。
我把 api-test-source-analysis 的 SKILL.md 和所有 reference 都看完之后，最直观的判断是：这个 Skill 的重点不是开发视角的 Code Review，而是测试视角的接口破案流程。它默认从接口基础信息和业务语义开始，先把接口做什么讲清楚，再把上下游串起来，然后继续推进到测试数据定位、用例设计、Code Review 和 Bug 研判。
测试同学去看一个接口源码，最常遇到的困难不是“完全看不懂”，而是看完以后没法直接进入验证动作。你知道它查了哪张表，也知道它走了几个 if/else，但你依然要自己判断：这个分支会不会错、错了以后接口会怎么表现、要准备什么数据、怎么写成一条像样的缺陷验证用例。
api-test-source-analysis 就是补这段断层的。它不是做一轮泛泛的技术解释，而是把源码分析一路推到测试执行层。这个定位非常重要，因为它决定了最后产物不是“分析意见”，而是测试人员拿来就能继续验证的正式结果。
这条主线的意思很简单：它不满足于让你“知道代码怎么写的”，它会继续逼问这段代码到底值不值得测、怎么测、会不会错、错了怎么证明。
很多团队已经会调接口，也有 Postman、Swagger、自动化框架，但问题还是会卡在“源码看完之后如何收敛”。因为源码给出的只是原材料，测试真正要的是下一层结果：分支、前置链路、业务状态、数据条件、返回语义，还有最后的 Bug 判断。
它真正解决的，不是“帮测试看懂开发代码”，而是把源码阅读结果变成测试可执行结论。这比单纯做一轮解释值钱得多。
我觉得这条 Skill 最有吸引力的地方，是它把各个动作排成了一个很顺的测试视角顺序。先看接口是什么，再看业务怎么走，再看链路和数据依赖，然后才进入用例和 Bug。这不是简单列节点，而是在模拟一个成熟测试人员分析接口时真正会走的脑内路径。
这篇如果只写“它可以做 Code Review”，其实会把这个 Skill 写矮。因为它真正有辨识度的地方，是对 Bug 输出做了很强的约束。它明确规定：默认外部依赖行为正确，不分析 RPC 超时、缓存击穿、基础设施故障，也不把统一异常兜底本身直接当作 Bug。
这其实是在主动控制误报。因为测试最怕的不是没问题可提，而是提了一堆无法验证、无法复现、最后落不成缺陷的问题。这个 Skill 刻意把范围收窄，只保留那些从接口视角真的能打出来的东西。
我特别建议文章里单独写它的四问标准，因为这是这条 Skill 最能打动专业读者的部分。每个 Bug 在进入列表前，都要回答四件事：
1. 接口如何触发？
2. 源码依据是什么？
3. 实际接口表现是什么？
4. 和业务预期冲突在哪里？
这四问很硬，但也正因为够硬，最后输出的 Bug 才更像正式测试结论，而不是一堆“感觉这里可能有风险”。
如果这篇文章要控制篇幅，我建议不要六个节点平均写，而是重点抓三个最能体现差异化的部分。
这三个点组合起来，刚好构成一个很强的传播句式：先把接口讲清楚，再把数据找出来，最后把 Bug 证出来。 这句话本身就能概括这条 Skill 的价值。
api-test-source-analysis 最值得写的，不是它会做源码分析，而是它把接口测试里最难散、最靠经验的那一段正式收了口。从业务理解到上下游链路，从测试数据到用例设计，再到 Bug 研判，这些原本很容易断开的动作，被它排成了一条稳定主线。
如果上一篇 test-case-writer 讲的是“把测试设计收成流水线”，那这一篇更像是在回答另一个更具体的问题：当测试必须面对真实接口源码时，怎么把代码里的信息继续压成可验证结果。
收藏地址：https://gitee.com/airlsen/cogent-skills
