那天遇到的需求，表面上很简单：以后只要给系统一个链接，它就自动把内容送到合适的地方解析。短视频平台 A 的链接，交给原来的解析通道；社交平台 B 的视频链接，则交给另一条更适合它的通道。用户并不是想要一个“什么都能试一下”的万能入口，而是希望系统能先认出链接来自哪里，再做后面的事。
我一开始也差点把它看成“再加一个重试分支”。原来的流程已经可以处理一种链接，于是最直接的想法是：解析失败了，就换另一个工具再试一次。后来我停下来重新看这件事，发现真正要解决的不是失败后的补救，而是成功前的判断。一个链接还没有被送进解析器之前，系统其实已经拥有一条很重要的信息：它的来源。
自动化的第一步不应该是调用工具，而应该是判断这个输入属于哪一条车道。
这次问题从一个链接暴露出来
当时用户给了一个社交平台 B 的视频链接，并明确提出一个长期规则：短视频平台 A 继续走原来的通道，社交平台 B 走另一条通道。这个要求里有一个容易被忽略的变化。它不是要求某个工具“多支持一种格式”，而是在同一个入口下，建立两套不同的处理路径。
如果只看入口，确实可以把所有链接都交给同一个解析器。只要某次碰巧能返回内容，调用方甚至察觉不到问题。但解析器并不是抽象的“内容机器”。它们依赖不同的平台结构、不同的登录状态和不同的内容理解能力。一个通道能理解短视频平台 A，不代表它也能理解社交平台 B。
这件事让我重新意识到，统一入口不等于统一处理。入口可以只有一个，内部却必须承认输入之间存在差异。把差异藏起来，短期看起来更省事，长期只会把平台判断、失败原因和重试成本混在一起。
表面是解析失败，实际是来源判断缺失
原流程的问题并不是完全不能工作。它处理熟悉链接时可以顺利完成，后续的内容整理也有既定结构。问题出在它默认所有链接都属于同一种输入，于是把“来源识别”这一步直接省掉了。
省略的步骤不会消失，只会在更晚的时候回来。解析器收到不认识的链接，可能返回空内容，可能只拿到页面标题，也可能给出一个看起来像成功、实际没有台词的结果。之后如果继续重试，系统又会把同一个错误输入交给同一个能力边界不匹配的工具。
如果不处理这个缺口，后面会导致两个麻烦。第一，用户很难知道失败是链接本身的问题，还是解析器的问题。第二，系统可能静默切换到另一条通道，最后虽然得到了一段文字，却无法说明它来自哪个判断，准确度也没有依据。失败被掩盖以后，下一次就更难改进。
所以我没有把目标写成“让原解析器支持所有平台”，而是把目标改成“让入口能够识别来源，并把来源送进唯一匹配的解析车道”。这是范围上的收缩，却让行为边界清楚了。
先核对接线点，再决定怎么分流
动手之前，我先用只读方式核查了现有流程。重点不是马上改代码，而是确认两个能力分别从哪里进入、入口参数是什么、后面的步骤哪些可以继续共用。这样的核查看起来慢了一点，但它能避免把平台路由做进错误的层级。
核查结果说明，原来的入口可以保持不变，变化只需要发生在内容提取层。短视频平台 A 仍然沿用原通道；社交平台 B 则需要独立的解析通道，不能把它当成原通道的另一种输入格式。等内容被提取出来以后，后续的整理、切段和生成提示内容仍然可以沿用原来的流程。
我选择只在提取层分叉，是因为平台差异存在于“如何拿到内容”，而不是存在于后面如何整理内容。
这个判断很重要。要是把两条链路从入口一路复制到结尾，系统很快会出现两套重复的整理逻辑。以后修一个格式问题，要改两处；以后加一道质量门，也要记得两边同时补。只在真正不同的地方分开，既保留了平台能力边界，也避免把差异扩散到不相关的步骤。
试水的结果也要写清准确度边界
在写详细计划时，我没有把另一条通道“理论上可以解析”当成事实，而是先安排了一个低风险探针。这个探针仍然属于只读验证，不发送正式任务，也不生成后续成品。它只回答一个问题：给定的社交平台 B 链接，能不能真实返回可用的内容。
试水结果是能返回具体台词，而且内容细节与视频标题相互吻合。这说明服务端确实能够把链接里的视频描述带进理解过程。不过，探针也暴露了能力边界：它能做描述级提取，却不能在这条通道里逐帧截图核对字幕。也就是说，“能解析”不等于“逐字准确”。
这里最容易误判的是开场提示。有时通道会先说自己无法访问链接，但后面的正文却给出具体台词。判断成功与否，不能只看第一句，也不能只看有没有返回文字，而要看结果是否包含与目标内容相关、可以复核的细节。与此同时，不能因为一次试水成功，就把准确度写成逐帧级别。
我把这项限制保留在计划里，并调整了后续验收方式：这条车道先做提取和结构化整理，跳过它无法完成的逐帧自核；产物明确标注为描述级结果。一个流程可靠，不是因为它把所有能力都说成有，而是因为它知道哪些能力还没有被验证。
错误捷径：所有链接都交给同一个解析器
最容易误判的错误捷径，就是把“一个入口”理解成“一个解析器”。这样做的好处只有一个：初始代码可能更短。但一旦输入来源增加，问题就会从简单的失败变成无法解释的混乱。
另一种相似的捷径，是失败后静默切换。短视频平台 A 失败了，就试社交平台 B；社交平台 B 失败了，再倒回去。表面上这是提高成功率，实际上它把路由规则变成了猜谜。系统可能用不合适的能力得到一份半成品，用户却不知道它已经换了车道。
我更愿意让未知来源直接拒绝。拒绝听起来不如重试积极，但它给出了可行动的信号：当前规则没有覆盖这个链接，需要补充来源识别或另立计划。未知输入的明确拒绝，比带着错误归因的“成功”更值得信任。
这也是为什么来源识别必须在付费、发送或生成动作之前完成。已知来源可以进入对应的只读预检；未知来源停在入口，既不消耗外部用量，也不产生难以撤回的副作用。先判断，再行动，实际上是在给自动化保留刹车。
把路由做成可复用的流程
这次之后，我把方法概括成 4 步。第一步是归一化链接：处理协议、大小写、短链跳转和明显的多余参数，让同一个来源不要因为外观不同而被判成多个来源。第二步是识别来源：只根据已经确认的平台特征匹配，不靠“看起来像”去猜。
第三步是为每一种已知来源配置唯一车道，并写清它负责什么、不负责什么。短视频平台 A 的车道负责原有内容提取；社交平台 B 的车道负责描述级内容提取；后面的整理步骤作为公共部分继续复用。第四步是处理未知来源：直接返回原因，不静默换车道，并把它留给下一次规则扩展。
这个流程里还要加一层动作边界。涉及外部发送、生成或可能产生用量的动作，先输出只读计划和预检结果，再进入实际执行。计划阶段只证明入口、参数和能力边界被核对过，不把计划文件本身当成已经完成的功能。执行以后，还要独立验收结果，确认内容确实来自预期车道。
一个流程成熟的标志，不是它能跑通一次，而是它能在下次少依赖临场记忆。把“来源—车道—能力边界—未知处理”写下来，下一次遇到新链接时，就不用重新争论所有工具是否都值得试一遍。
下次我会怎么做
下次再遇到“给一个链接，自动完成后续处理”的需求，我会先问 3 个问题：链接有哪些已知来源？每种来源真正匹配哪条能力？未知来源应该停在哪里？这 3 个问题没有答案之前，我不会先加重试，也不会先把所有工具串起来。
我会先做只读核查，确认现有入口、参数和公共后处理，然后用一个真实但低风险的样本做探针。探针不只看“有没有返回”，还会看返回内容是否包含可核对细节，并记录它的准确度等级。任何没有验证过的能力，都不写进流程承诺里。
最终留下的规则应该足够朴素：一个入口可以接收各种链接，但每个已知来源只有一条明确车道；未知来源不猜，涉及副作用的动作先计划后执行。真正值得复用的不是某个平台的接法，而是先识别输入、再选择能力、最后保留拒绝权的判断顺序。
这件事让我重新意识到，自动化并不只是把更多工具接在一起。工具越多，越需要在它们之前放一个清楚的判断。否则系统得到的不是更强的能力，而是更多没有解释的尝试。把链接按来源分车道，表面上是在做路由，实际上是在把责任边界重新放回流程里。