那天遇到的是一个看起来很直接的命令行问题：我给一个计划工具加上问题参数，希望它在完成技能预检的同时，顺便回答一个具体问题。命令写法符合包装层公开出来的用法，可执行后却立刻失败，提示底层命令不认识这个参数。
我一开始差点把它当成一个小小的兼容性缺口。既然包装命令支持这个参数，底层命令为什么不支持？是不是底层版本旧了，或者只是少写了一个参数定义？但继续往下看才发现，真正的问题不在“有没有这个参数”，而在于这个参数被送到了哪一个子命令。
这件事让我重新意识到，命令行里的参数并不是漂浮在整条命令上方的公共语言。它通常属于某一个具体子命令。包装层如果把参数当成全局选项随手拼接，表面上是在传递能力，实际上可能已经改变了原本的调用语义。
报错表面只是最后一跳
复现时，包装命令先做技能加载，再尝试把问题一起交给底层处理。报错信息很明确：底层不接受 --ask。如果只看这一行，最容易得出的结论是“底层缺少 --ask，给它补上就好了”。
但我没有先去改底层。因为一条完整命令不是一块平面文本，而是一条有边界的调用链：入口命令接收参数，包装层重新组织参数，然后选择某个子命令执行。报错发生在最后一跳，不等于错误就产生在那里。
这次的包装层把 --ask 直接拼给了加载子命令。加载子命令的职责是找到并准备技能，它的参数表里没有问题查询选项。真正支持问题查询的，是另一个独立的询问子命令。也就是说，参数本身没有错，错的是它被送进了不负责这件事的入口。
如果不处理这个边界，后果不只是命令失败。更隐蔽的风险是，有人为了让它返回成功，可能在包装层吞掉错误，或者在底层命令上增加一个同名参数。这样一来，命令也许不再报错，但它到底有没有完成问题查询，就变得无法判断。
先画参数流，再看改哪一层
我后来把排查过程收窄成一张很简单的参数流：用户输入什么，包装层保存什么，第一步调用哪个子命令，第二步调用哪个子命令，每一步允许哪些参数，最后输出哪些字段。这样做的好处是，问题不再是“这条长命令哪里不对”，而变成“某个参数在某个边界上走错了”。
接着，我逐个对照底层各子命令的参数定义，而不是只搜索 --ask 这个字符串。这个区别很重要。搜索只能告诉我某个词出现在哪里，参数定义才能告诉我它归谁所有、什么时候有效、缺失时应该怎样失败。
对照之后，调用关系变得清楚：加载动作应该保持原样；问题查询需要使用加载结果里的技能路径，单独进入询问子命令。包装层原本已经预留了 ask_report 字段，说明设计上早就期待有一份问答报告，只是这条报告生成路径没有真正接通。
排查包装命令时，我先确认参数属于哪个具体子命令，再决定是改路由还是改能力。
这个判断也决定了修复范围。我选择只改包装层，是因为底层已经有正确的询问入口，扩大底层参数表反而会制造两套语义：一个参数既能在加载阶段出现，又能在询问阶段出现，后续很难解释它究竟以哪种方式生效。
修复不是把错误变成成功
修复后的路径分成两步。第一步照常加载技能，不再把问题参数透传给加载子命令。第二步读取加载结果中的技能路径，再独立调用负责询问的子命令，把原问题传进去。由于第一步已经完成同步，第二步关闭重复同步，避免一次查询又做一遍不必要的工作。
这里最容易误判的是，“调用成功”就等于“功能成功”。如果只把退出码改成 0，包装命令看起来会恢复，但报告字段可能仍为空；如果只补上报告路径，又不检查实际内容，也可能只是把一份错误结果包装得更像成功。
所以我同时关注了 3 件事：参数有没有送到正确的子命令，问答报告有没有写入预期字段，失败时退出码有没有保留失败语义。包装命令还会把实际执行的命令保存成可以直接复制的形式，带空格的路径和问题文本不会因为引号丢失而变成另一条命令。
我选择保留失败退出码，是因为调用者往往依赖它做自动判断。可靠的包装器不是让每次调用都返回 0，而是让成功和失败都准确地表达真实状态。 如果不存在的技能被包装器吞成成功，后续流程会继续使用一个并不存在的路径，错误反而会从当前步骤蔓延到更远的地方。
用等价查询确认语义没变
修完以后，我没有满足于“包装命令不再报参数错误”。真正要确认的是：包装层只是替用户选择了正确的路由，还是悄悄改变了查询本身？为此，我把测试拆成包装调用和直接调用两条路径。
两条路径使用同一个技能、同一个问题和同一个关闭重复同步的条件。包装调用从公开入口进入，直接调用则绕过包装层，直接进入负责询问的底层子命令。然后比较两份问答报告，而不是只比较屏幕上那句“完成”。
结果显示，除时间戳外，两份报告的字段逐项一致，包括术语、查询内容和文件提示等信息。这个“除时间戳外”的限定也很关键：时间本来就会变化，不能因为它不同就误判语义不一致；其他报告字段相同，才说明包装层没有重新解释问题。
我把这看成一种等价查询：先定义什么应该保持不变，再忽略那些天然会变化的记录字段，最后比较业务结果。它比单纯比较退出码严格，也比比较整段原始输出更有意义。包装器的职责是路由和整理，不应该偷偷改变底层回答。
回归矩阵要覆盖失败边界
为了避免只修好这一条成功路径，我保留了一个最小回归矩阵。第一格是修复前的复现，确认原问题确实能被稳定观察到；第二格是带问题参数的包装调用，确认报告字段出现且退出码为 0；第三格是等价的直接调用，确认两份报告语义一致。
另外两格也不能少：不带问题参数的原路径，以及不存在技能时的失败路径。不带参数的检查用于证明原有加载行为没有被顺手改坏；不存在技能的检查用于证明包装层仍会报告错误并返回非 0，而不是因为新增了问题查询就把所有情况都当成成功。
最终，这组检查通过了语法验证、包装与直接查询的逐字段比对、原路径回归、失败退出码验证以及现有测试套件。这里的价值不在于测试数量多，而在于每一项都对应一个可能被修复动作影响的边界。
一个流程成熟的标志，不是它能跑通一次，而是它能证明自己没有改变原来的语义。 这也是为什么我没有只记录“修复后成功”，而是把“包装调用”和“等价直调用”放在同一张回归表里。
下次我会怎么做
下次再遇到命令行包装器的参数报错，我会先暂停添加新参数，按入口、包装层、具体子命令和输出字段画出参数流。然后逐个查看子命令的参数定义，确认每个选项的归属、调用顺序和失败方式。只有确认底层确实缺少能力，我才会考虑改底层；如果能力已经存在，就优先修正路由。
我也会把验证分成 3 层。第一层是复现原错误，确保自己没有误解问题；第二层是修复后的包装调用，确认公开入口完成了预期工作；第三层是等价直调用，比较报告中的稳定字段，确认只是换了一条路，没有换一种含义。最后再补上原路径和失败路径，守住没有被用户要求改变的行为。
最容易走的错误捷径，是看到参数报错就给底层 CLI 加一个同名参数，或者只让命令返回 0。它们都在修复症状，却没有回答“这个参数究竟应该由谁处理”。我更愿意把这次经验记成一条简单规则：参数透传前先对齐子命令边界，修复完成后再用等价查询证明语义不变。
表面上我是在修一条命令，其实是在修调用者对系统的信任。调用者相信包装器会把自己的意图准确送达，也相信失败时会得到真实反馈。只要这两件事还能被回归测试证明，包装层才不只是少报一个错，而是真正把复杂性挡在了正确的位置。