降SpringAI阿里第14掌-损则有孚-溯源源码

降SpringAI阿里第14掌-损则有孚-溯源源码

能跑通的代码，不等于能定位的代码

[读者] 已跑通 Spring AI Alibaba 数字人底座的 Java 工程师
[痛点] 行为一异常就只能搜索和猜，落不到具体文件与行号
[现在读] 进入源码与协作阶段，结论必须钉在确定版本上
[读完] 能用 IDE 与 Git 工具建立模块地图，产出可提交的 Issue/PR 证据

[旧方案] 看 README、搜博客、改配置试错
    |
    v
[新需求] 结论必须对齐 v1.1.2.2 这一确定事实源
    |
    v
[冲突] 主仓、Extensions、Examples 三者版本并不同步
    |
    v
[后果] 定位错版本，结论错误，Issue 无法复现，PR 被退回

我是老李。数字人项目一路走到第 13 掌，注册登录、项目 CRUD、开场白与结束语、Agent 模型与 System Prompt、Web 运行页、LiveKit 实时交互这条基线已经能演示了。上一掌把 A2A 与 Nacos 的跨域通信跑通之后，团队对“框架能做什么”已经没有疑问。

真正的麻烦从行为差异开始。同一个运行页，同一个开场白之后的追问，在测试环境里工具被调用了两次，在本地却只调用一次。有人说是模型问题，有人说是提示词问题，有人翻出一篇博客说“升级到 main 就好了”。争论了两个小时，没有一个人能说出这个行为由哪个类的哪个方法决定，也没有一个人能指出对应的测试用例在哪个目录。

这就是本掌要处理的事情：我们不再讨论功能，而是讨论“怎么知道”。任务是：把一次真实请求的行为，从运行结果反向定位到主仓某个文件、某个方法、某个测试，并把这个定位过程变成可复现的证据。

你有没有这样的经历：对着一个接口按下“查找用法”，结果一条都没有，于是怀疑 IDE 坏了？

如果 main 分支上的源码和你本地跑出来的行为对不上，你会先去改依赖版本，还是先确认自己在读哪一份源码？

当主仓、Extensions、Examples 三个仓库的结论互相打架时，你写出去的 Issue，维护者真的能复现吗？

01、故事

数字人项目的运行页在这周接了一个新需求：用户点“开始对话”之后，开场白播完，如果用户三十秒没说话，系统要自动追问一句。表面上看，这只是加一段提示词的事，实际改起来牵扯到会话状态、图执行和实时通道三块。

团队里的小王先动手。他打开本地工程，改了 System Prompt，重启服务，运行页表现正常。提交前他顺手把依赖升到了最新快照，因为“官方 main 上说这块改过了”。代码评审时，另一位同学在 CI 上跑同一套用例，工具调用次数和他本地的结果不同。

于是出现了一个典型局面：同一个人、同一份代码、同一句提示词，两个环境两种行为。小王的第一反应是去搜错误日志，第二反应是去翻官方文档，第三反应是问 AI。三个动作都做了，得到的都是描述性答案，没有一个能回答“这个行为到底由哪一行代码决定”。

我们把问题收敛成一句话：现在的团队能改，但不能查。能改是因为框架封装得好，不能查是因为封装得好也意味着调用链被抽象层切断。一个真实的请求，从 HTTP 入口进去，经过 ChatClient、ReactAgent、图运行时、检查点持久化，再回到 SSE 通道，中间至少有四层接口多态。你在任何一层按“查找用法”，看到的都可能只是一个接口声明。

所以本轮的目标不是加功能，而是补上工程能力里最容易被跳过的一环：源码定位与开源协作。把事实源锁定到 alibaba/spring-ai-alibaba 的 v1.1.2.2，把模块地图画出来，把一次请求钉到文件与行号，最后形成一份别人能照着复现的 Issue 或一份文档 PR。

这一次，我们不比谁改得快，比谁说得清。

能跑不算懂
会查才算通
版本先锁定
结论才有根

02、问题

旧方案失效得很彻底。我们此前的定位方式有三种：读 README、搜中文博客、改配置试错。这三种方式在功能搭建阶段很有效，因为搭建的目标是“跑起来”；但在行为对齐阶段几乎失效，因为对齐的目标是“说清楚”。

业务影响是直接的。数字人项目的运行页一旦出现行为漂移，团队无法判断这到底是框架缺陷、扩展包版本问题，还是自己的用法错误。判断不了，就意味着要么盲目升级，要么原地打补丁，两种选择都会把技术债往后推。

技术表现集中在三个可观察的点上。第一，结论会随分支漂移：同一个人上午读的是 main，下午切回本地 tag，给出的解释前后矛盾。第二，调用链在抽象层断裂：按“查找用法”看不到运行期真实调用者，因为调用发生在接口、工厂、自动配置与图运行时的多态分派之间。第三，证据不可复现：口头说“可能是检查点没保存”，但拿不出最小复现、拿不出相关测试、拿不出引入该行为的提交。

本篇的完成标准必须可验证，我列了四条：

1. 在锁定的 v1.1.2.2 上，给定一个行为描述，能输出“模块 → 类 → 方法 → 调用者 → 测试”的完整链路，链路中的每一项都是真实存在的文件与行号；
2. 能用 Git 历史工具（blame、tag 与 main 的 diff）说明该行为是何时引入、是否在版本之间变更过；
3. 能产出一个最小复现，并写成一份符合仓库模板的 Issue 正文；若属于文档缺失，则产出一份 docs 提交，提交信息为 docs(ch14): map source modules and contribution workflow；
4. 所有结论都能追溯到主仓这一个事实源，生态仓库只作为补充线索，且各自的仓库状态分别核验。

达不到这四条，本篇不算完成。

猜测无成本
复现才有价
标准先写死
争论自然停

03、原理

先给一个反直觉判断：在 Spring AI Alibaba 这类分层框架里，你在 IDE 里按“查找用法”找不到调用者，通常不是 IDE 的问题，而是调用关系本来就不在编译期显式存在。真实调用经过接口、条件装配、工厂与图运行时的分派，静态可见的只是一个抽象层。把“找不到”理解成“没被调用”，是定位工作的第一个系统性错误。

第二个反直觉判断：main 分支不是事实源，tag 才是。main 是开发中的事实，tag 是发布出去的事实。你本地跑的是哪一份字节码，取决于依赖解析结果，而依赖解析结果取决于你声明的版本，不取决于你打开的是哪个分支的文件。读 main 的源码解释 tag 的行为，等于用未来的代码解释过去的现象。

第三个判断关于测试与示例的关系。在本仓里，tests 是最接近契约的文档：它能表达“官方认为这个行为应该是什么”。而生态仓库里的 examples 只是用法演示，它表达的是“某个人在某一天这样用过”。用法示例可以启发你，但不能作为反驳官方行为的证据。

关于事实优先级，我在实际工作中按这个顺序排：官方文档 → 主仓源码与测试 → 官方 Release 与 CHANGELOG → 官方工程博客 → 其他资料。涉及生态边界时还要多加一层判断：主仓 alibaba/spring-ai-alibaba 是官方事实源；Extensions、Examples 以及 DataAgent、DeepResearch、Lynxe 这类仓库属于 Spring AI Alibaba 生态，具体仓库的状态、版本与维护节奏需要分别核验，不能互相代证。凡是当前无法确认的内容，我会明确写“需按当前官方文档核验”，而不是含糊过去。

这三条判断会直接决定后面的架构：为什么定位要分“下行追踪”和“上行追踪”，为什么必须用 worktree 把两个版本并排放，为什么验证结论一定要回到 tests 而不是回到博客。

眼见不为实
调用有断点
事实在标签
不在主分支

04、架构

[输入] 一次真实请求 / 一个行为疑问
    |
    v
[模块] 主仓 v1.1.2.2：agent-framework / graph-core / core / starters
    |
    v
[数据/状态] 源码 + tests + 提交历史（blame / tag 与 main 的 diff）
    |
    v
[处理] 下行 Call Hierarchy → 上行 Find Usages → 对照 tests → 最小复现
    |
    v
[输出] 模块地图 + 定位结论 + 可提交的 Issue/PR 证据

这张图里的模块划分是定位工作的坐标系，不是仓库目录的精确复制。按当前官方仓库结构，主仓内与数字人项目直接相关的部分大致集中在四块：核心模型与客户端相关模块、Agent 框架相关模块、图运行时相关模块、以及各类 starter 与自动配置。具体模块名与依赖关系，需要以锁定的 tag 下根 pom.xml 的 <module> 列表为准，本文写的名称需按该 tag 核验后再引用。

边界要说清楚。这套方法回答的是“行为由哪段代码决定、历史上有无变更、官方测试期望是什么”，它不回答“这段代码性能如何”“线上表现怎样”。性能与线上观测属于后续章节的范畴，本篇不越界。

收益是明确的。一旦模块地图与定位脚本稳定下来，团队里任何人提出的行为判断，都可以被复算：脚本跑一遍，源码行号、测试用例、引入提交一次给全。争议从“我觉得”变成“文件第几行”。

代价同样明确。第一，时间成本前置：克隆仓库、拉取标签、准备 worktree、跑一遍定位脚本，第一次会花掉小半天。第二，认知成本：你需要同时理解源码语义和构建结构，而不是只读一个类。第三，也是最容易被忽视的代价——事实源锁死之后，你不能再随手用“最新版本已经修了”来搪塞问题，因为你必须拿出对应版本的实际代码。

适用条件有两个。其一，问题必须能被描述成一个可观察的行为，而不是一种情绪。其二，必须存在该版本的源码与测试，否则定位退化为猜测。

模块先画图
边界再落笔
输入到输出
路径不迷航

05、实战一次

环境与版本：JDK 21 LTS，Git，Maven，IntelliJ IDEA（可选但强烈建议），事实源为 alibaba/spring-ai-alibaba 的 v1.1.2.2。官方资料入口包括主仓、Issues 与 Pulls 三个页面，分别用于读源码、查已有问题、看合并标准。

第一步，拿到事实源并锁定标签。标签名在不同版本间可能有前缀差异，所以先查再切，不要凭记忆写。

git ls-remote --tags https://github.com/alibaba/spring-ai-alibaba.git | grep -F '1.1.2.2'

确认标签名之后，克隆并切分支。分支名使用本轮约定的 chapter/14-source-pr。

git clone --branch <确认到的标签名> --single-branch \
  https://github.com/alibaba/spring-ai-alibaba.git saa-1.1.2.2
cd saa-1.1.2.2
git switch -c chapter/14-source-pr
git rev-parse --short HEAD
git describe --tags --always

第二步，读模块地图。模块名以根 pom.xml 为准，这一步决定了后面 grep 的范围。

grep -n '<module>' pom.xml

第三步，准备一份 main 的对照工作区。定位行为变更时，并排比对比来回切换分支更可靠。

git worktree add ../saa-main origin/main
git worktree list

第四步，写定位脚本。这是本篇的核心实现，它把“查源码”变成一条可重复执行的命令。脚本放在 tools/locate.sh，只做三件事：打印事实源、列出主源码命中、列出测试命中。

#!/usr/bin/env bash
set -euo pipefail

KEYWORD="${1:?用法: ./tools/locate.sh <关键词>}"
ROOT="$(git rev-parse --show-toplevel)"

cd "$ROOT"

echo "== 事实源 =="
git describe --tags --always
git rev-parse --short HEAD

echo
echo "== 主源码命中（排除测试） =="
git grep -n -- "$KEYWORD" -- '*.java' | grep -v 'src/test/' || true

echo
echo "== 测试命中 =="
git grep -n -- "$KEYWORD" -- '*.java' | grep 'src/test/' || true

echo
echo "== 最近一次变更该关键词的提交 =="
git log --oneline -n 5 -S "$KEYWORD" -- '*.java' || true

第五步，启动脚本，提出一个真实的行为疑问。这里用“检查点何时写入”作为请求，因为数字人项目的会话恢复直接依赖它。

chmod +x tools/locate.sh
./tools/locate.sh CheckpointSaver

未在当前环境实测，以下为预期结果，输出结构应当类似：

== 事实源 ==
<标签名>
<短 SHA>

== 主源码命中（排除测试） ==
<模块路径>/src/main/java/<包路径>/CheckpointSaver.java:12:public interface CheckpointSaver ...
<模块路径>/src/main/java/<包路径>/<某实现类>.java:31:class <某实现类> implements CheckpointSaver ...

== 测试命中 ==
<模块路径>/src/test/java/<包路径>/<某测试类>.java:58:void <某测试方法>() ...

== 最近一次变更该关键词的提交 ==
<短 SHA> <提交标题>

第六步，验证。验证不是“看起来对”，而是三件事同时成立。其一，命中路径存在于当前 HEAD，用 git ls-files --error-unmatch <文件> 逐条确认。其二，测试命中项能定位到断言，用 git log -L 看该方法的历史。其三，把命中项抄进模块地图文档，正文里的每个类名后面都必须跟真实路径。

git ls-files --error-unmatch <命中的源文件路径>
git log -L 1,60:<命中的测试文件路径>
git blame -L 1,40 -- <命中的源文件路径>

跑完这一轮，你会得到一个最小但完整的能力：输入一个关键词，输出这一版本下的源码位置、测试位置和历史提交。它还不能解释全部行为，但已经足够让你在争论中拿出证据。

先跑最小例
再追一行码
输出有证据
结论不心虚

06、排查

定位过程本身就会踩坑，而且坑的表现和功能调试完全不同。下面三条是我们在这一轮里真实遇到的。

第一条诊断链：在 IDE 里对某个保存方法按 Call Hierarchy，只看到一个接口声明，看不到任何调用者。现象是“似乎没有被调用”。怀疑方向有两个：一是方法确实未被使用，二是 IDE 索引没建好。检查动作是：先 Find Usages 看接口被谁引用，再在仓库内搜该接口的实现类，最后搜自动配置与构建脚本中的注册点。证据是：接口存在多个实现，且实现对象通过配置被注入，运行期才确定具体实例。根因是调用发生在抽象层，编译期不呈现直接引用。修复方式是改为双向追踪：下行从入口类开始按 Call Hierarchy 走，上行从接口开始按实现与注入点走，两端在测试里交汇确认。

错误尝试： 我们一开始直接搜索实现类的类名，想用它反查调用者。这个做法错在实现类往往是通过条件装配或工厂在运行期选择的，源码里不存在写死的引用，因此搜索命中为空是必然的，而不是方法无人调用。

第二条诊断链：本地运行行为与阅读 main 源码得出的结论不一致。现象是“源码明明这么写，跑出来不是这样”。怀疑方向集中在缓存与构建，比如增量编译没生效。检查动作是：先 git rev-parse HEAD 确认当前工作区版本，再核对依赖解析结果，最后用版本区间 diff 查看相关文件是否变更。证据是 diff 输出显示目标文件在锁定的版本之后被修改过，而本地运行时实际加载的是锁定版本。根因是源码事实源与运行时事实源不一致：读的是 main，跑的是锁定版本。修复方式是显式锁定版本，并在定位脚本的第一步打印事实源，让版本信息出现在每一次输出里。

第三条诊断链：生态仓库的示例能跑通，但主仓的同名能力行为不同。现象是“示例里可以，主仓里不行”。怀疑方向是主仓回归。检查动作是：确认示例仓库与主仓的关系、示例依赖的主仓版本、以及示例最近一次提交时间。证据是示例仓库依赖的是另一个版本区间，并不承诺与锁定版本一致。根因是把生态示例当成了官方契约。修复方式是在团队规范里写死一条：行为结论只引用主仓这一个事实源，生态仓库仅作为线索；引用任何生态仓库内容时，必须分别核验其仓库状态。

三条链的共同点是：都不需要改代码，只需要改“查的方式”。这也是本篇最大的收获。

现象引怀疑
检查出证据
根因定修复
少一步都虚

07、优化

第 06 章的证据指向同一个根因：定位失败不是因为工具不好，而是因为事实源没有锁定、调用链没有双向走、生态边界没有分清。V2 就针对这三点改。

修改一：把事实源锁定前置成所有定位动作的第一步。定位脚本第一段输出固定打印标签与提交号，任何人拿到输出都知道自己看的是哪一版。选择这样做，是因为“读错版本”这一根因无法通过更仔细的阅读来避免，只能通过流程来消除。新行为是：任何结论旁边天然带着版本标识，跨人沟通时不再需要口头确认。验证方式是：在不同终端、不同机器上分别执行脚本，输出的版本字段完全一致。

修改二：把追踪方式从单向改成双向，并用测试做交汇点。下行从入口按 Call Hierarchy 走，上行从接口按实现与注入点走，两条路径如果指向不同的文件，说明中间还有一层没找到。选择这样做，是因为第 06 章已经证明“找不到调用者”是框架分层的常态，而不是异常。新行为是：每个定位结论都必须同时给出“谁调它”和“它调谁”，并且能被至少一个测试用例支撑。验证方式是：任意换一个关键词重跑，链路仍然完整，不会出现单端悬空。

修改三：把生态仓库从证据降级为线索。选择这样做，是因为生态仓库的维护节奏与主仓不同步，用它的结论去否定主仓行为，会直接导致 Issue 被判定为不可复现。新行为是：所有跨仓结论都必须标注来源仓库与版本，未确认的写“需按当前官方文档核验”。验证方式是：随机抽三条历史结论复核，每条都能追到唯一来源。

优化完成后，我们得到了一个可以直接落地的东西：docs(ch14): map source modules and contribution workflow 这份文档，配套定位脚本与 Issue 模板。这里的提交信息是团队约定格式，不代表官方仓库的提交规范，向主仓提交前必须按该仓库的贡献指南核验格式要求。

证据定方案
修完再验证
不夸一分好
只求可复现

08、演进

[同一输入：一个行为疑问]
    |
    +--[V1] grep + 读 README + 改配置试错
    |      代价：结论随版本漂移，无法回溯，争论靠语气
    |
    +--[V2] 锁定标签 + 双开 worktree + 双向追踪 + 对照 tests
    |      代价：首次准备成本高，需要理解构建结构
    |
[Trade-off]
得到：可复算、可交叉验证的定位结论
失去：随手用“最新版已修”搪塞问题的便利
适用边界：行为可被描述、且存在对应版本源码与测试

从正确性看，V1 的结论正确与否取决于运气：恰好读对版本、恰好搜到对的博客，结论就对。V2 把正确性从运气转移到流程，只要流程跑完，结论至少是可核验的。

从稳定性看，V1 在不同人、不同时间、不同环境下结论会漂移，因为没有人记录自己读的是哪一版。V2 的输出天然带版本字段，漂移被结构性消除。

从复杂度看，V2 明显更重。多仓库、多工作区、脚本、文档，这些都是真实成本。所以 V2 并不适合所有场景：如果你只是想知道某个注解怎么写，V1 依然更快。V2 的价值只在“结论需要被别人复现”时才成立。

从成本看，V1 单次成本低、累计成本高，因为同一个问题会被反复讨论；V2 单次成本高、累计成本低，因为定位结果可以沉淀成文档。团队规模越大，V2 的边际收益越明显。

适用范围上，V2 适用于版本对齐、行为争议、Issue 撰写与 PR 提交；不适用于快速原型时的 API 试错。

遗留问题也清楚：V2 解决的是“静态可追溯”，不解决“运行时可观测”。一个请求在运行期到底走了哪条分支，还需要日志、指标与追踪来回答，那是后面章节的题目。

旧法求快
新法求准
快慢之间
取舍自明

09、洞见

9.1 版本是定位的第一性问题

反直觉判断：在源码定位这件事上，“读哪一版”比“读得多细”更重要。读错版本时，读得越细，结论越自信，错得越离谱。锁标签这个动作看起来是准备工作，实际上是整个方法的地基。

9.2 抽象层不会消灭调用链，只会隐藏它

反直觉判断：Call Hierarchy 找不到调用者，恰恰说明框架解耦做得好，而不是代码有问题。遇到断链时正确的动作不是换工具，而是换方向——从接口往实现走，从配置往注入点走，最后用测试把两端接上。

9.3 测试是契约，示例只是用法

官方仓库里的测试表达的是“官方承诺这个行为”，生态示例表达的是“某天有人这样用过”。把这两者等同，是提交无效 Issue 的最常见原因。写 Issue 时，能引用测试就引用测试，不能引用测试就提供最小复现。

9.4 生态边界必须在结论里写出来

主仓是官方事实源，Extensions、Examples、DataAgent、DeepResearch、Lynxe 属于生态，仓库状态需要分别核验。这条判断的价值不在写作规范，而在节省沟通成本：一个标注了来源与版本的结论，维护者可以复现；一个没说来源的结论，只能被关闭。

源头只有一
生态各有命
测试即契约
示例非标准

10、系统落地

原来有什么：数字人项目已经具备注册登录、项目 CRUD、标题与主题色、背景图、开场白与结束语、Agent 模型与 System Prompt、Web 运行页、LiveKit 实时交互这条基线，能演示，但行为一旦漂移就只能靠猜。

本篇新增了什么：一份锁定了 v1.1.2.2 的模块地图文档，一个可重复执行的定位脚本，一套双向追踪的操作规范，以及 Issue 与 docs 提交的证据模板。分支落在 chapter/14-source-pr，文档提交约定为 docs(ch14): map source modules and contribution workflow。

现在能做什么：给一个行为描述，能在半小时内输出“模块 → 类 → 方法 → 调用者 → 测试”的链路，并用 Git 历史说明该行为是否在版本之间变更过；如果判断是框架问题，能写出一份带最小复现的 Issue；如果判断是文档缺失，能提一份文档 PR。

还缺什么：缺运行时可观测。定位脚本能告诉你代码在哪，但告诉不了你线上某个请求实际走了哪条分支、耗时多少、是否命中缓存。这部分要靠日志、指标与追踪来补。

下一步如何演进：把这一轮沉淀的定位结论回填到数字人项目的技术文档里，让每个关键行为后面都挂一个源码锚点；下一轮再把定位对象从“源码”扩展到“服务边界”，为服务化与治理做准备。

底座仍可用
地图新增页
能查能复现
才谈下一步

11、小结

Q1 → 查找用法为空不等于没被调用，框架的调用发生在抽象层，必须双向追踪
Q2 → 先确认自己读的是哪份源码，标签是事实源，main 不是
Q3 → 混用主仓与生态仓库的结论写不出可复现的 Issue，来源与版本必须标注
状态 → 已建立模块地图与定位脚本，可把一个行为定位到源码、测试与历史提交

这一轮最实的产出不是某段代码，而是一套“能被别人复算”的定位方法。它把争论从观点层面拉到了文件与行号层面。

三问皆有解
状态落一格
能力可交付
不留悬空账

12、作业

12.1 理解题：为什么“查找用法”在框架代码里经常为空，这说明了什么？

参考答案：因为调用关系通常不体现在编译期的直接引用上，而是经过接口、条件装配、工厂或运行时分派来完成。这说明框架通过解耦获得了扩展性，代价是静态调用链不完整。定位时需要双向走：下行从入口按调用层级深入，上行从接口按实现与注入点回溯，并用测试作为交汇点确认。

12.2 实战题：在你锁定的 v1.1.2.2 上，选一个与数字人会话状态相关的关键词，输出它的源码位置、测试位置与最近一次变更提交。

参考答案：先确认标签名再克隆，切出 chapter/14-source-pr 分支，用定位脚本执行关键词检索，得到主源码命中、测试命中与变更提交三段输出。随后用 git ls-files --error-unmatch 校验源文件存在，用 git log -L 与 git blame 校验测试与历史。最终把每一行结果抄进模块地图文档，确保文档里出现的每个类名都带真实路径。

12.3 排障题：本地运行行为与阅读源码的结论不一致，你的排查顺序是什么？

参考答案：先确认工作区版本，再确认依赖解析到的版本，最后用版本区间 diff 查看相关文件是否在锁定版本之后变更。顺序不能颠倒：先怀疑环境再怀疑代码，先确认事实源再讨论语义。常见结论是源码事实源与运行时事实源不一致，修复方式是显式锁定版本，并让定位脚本每次都打印版本信息。

12.4 架构判断题：生态仓库的示例能跑通而主仓行为不同，应该把示例作为证据提交 Issue 吗？

参考答案：不应该。主仓是官方事实源，Extensions、Examples 以及 DataAgent、DeepResearch、Lynxe 属于生态，仓库状态、依赖版本与维护节奏需要分别核验。示例只能作为线索，提交 Issue 时应提供基于锁定版本的最小复现，或直接引用该版本的测试用例。若某个事实当前无法确认，写明“需按当前官方文档核验”，不要用推测填补。

题不在难易
在能否落地
做完四道题
手上真有活

13、思考

回到本篇的核心冲突：我们能跑通框架，却说不清行为由谁决定。这个冲突的本质不是能力问题，而是事实源问题。当版本不确定、调用链不可见、生态边界不清晰时，任何讨论都会退化成观点对撞。

把版本锁死、把链路双向走通、把来源标注清楚，这三件事做完，工程判断就有了地基。你会发现，很多过去需要争论很久的问题，其实只需要一次可重复的定位就能结束。这也是开源协作里最朴素的规则：先给出别人能复现的证据，再提出你的主张。

一源定真假
一链断复连
一证平争议
一役见真章