面试题库

分析过程 · 先想清楚再作答

1. 这题的前半句是常识题，后半句才是筛子。能把「描述也是接口」说明白的人，基本都真的运维过工具。
2. 先答常规的四类，官方在讲扩展演进时给过定义，直接可用：删除或重命名字段、改字段类型、改变现有行为的语义、新增必填字段。这四类的共同点是会让已有实现直接失败或者行为不正确。
3. 然后补 MCP 特有的第五类：**改工具描述**。理由是描述是模型选工具的唯一依据，改一句描述就是一次行为变更。举个具体的：某个服务端把描述从「在内部文档库里按关键词搜索」精简成「搜索文档」，代码一行没动，两周后用户反馈助手变笨了——模型不再选它了。
4. 接着讲为什么它**更**危险，这是题眼：改字段名会让调用方立刻报错，错误是响亮的，五分钟内就有人来找你；改描述不报任何错，单元测试全绿、服务端零错误、日志干净，它只会让选中率悄悄掉几个点，最后以「最近变笨了」这种没法定位的形式浮上来。响亮的错误比安静的退化好处理得多，所以描述改动反而更需要闸门。
5. 闸门是什么要说出来：一份三类齐全的评估集，描述改了必须跑一遍，选中率掉了就别合。这也是评估集要能一条命令快速跑完的原因。
6. 顺带把兼容技巧补上：加字段要加成可选的，因为老客户端不会传新参数；要改语义就换个工具名而不是原地改，旧的标弃用、描述里写明替代品、留一段时间再删，因为你不知道多少人的提示词里写死了那个名字。
7. 可预期的追问一：协议自己怎么做版本？MCP 用 YYYY-MM-DD，标的是最后一次破坏性变更的日期，向后兼容的改动不递增版本；弃用的特性至少保留十二个月才可能移除。追问二：发到注册表之后怎么改？改不了——版本号唯一且发布后元数据不可变，打错字只能往上加一个版本，而且范围形式的版本号会被直接拒收。

How to reason about it · think before answering

1. The first half is common knowledge; the second half is the filter. Anyone who can explain that the description is part of the interface has actually operated tools in production.
2. Give the four conventional categories, which the official guidance on extension evolution defines directly: removing or renaming fields, changing field types, altering the semantics of existing behavior, and adding new required fields. All four make existing implementations fail or behave incorrectly.
3. Then add the MCP-specific fifth: editing a tool description. The description is the model's only basis for selecting a tool, so changing a sentence is a behavior change. Concretely, a server shortened 'search the internal doc library by keyword' to 'search documents', shipped no code changes, and two weeks later users reported the assistant had gotten dumber, because the model stopped choosing it.
4. Now the crux, why it is more dangerous. Renaming a field makes callers fail loudly and someone finds you within five minutes. Editing a description raises nothing: unit tests pass, the server reports zero errors, logs are clean, and selection accuracy quietly drops a few points, surfacing weeks later as an undiagnosable 'it got worse'. Loud failures are far easier than silent degradation, so description changes need the stronger gate.
5. Name the gate: an eval set with all three case categories, run on every description change, blocking the merge when selection accuracy drops. That is also why the eval must run fast from one command.
6. Add the compatibility techniques: new fields must be optional, since old clients will not send them; to change semantics, introduce a new tool name rather than mutating in place, mark the old one deprecated with the replacement named in its description, and remove it only after a grace period, because you cannot know how many prompts hardcode that name.
7. Likely follow-ups: how does the protocol version itself? MCP uses YYYY-MM-DD marking the last breaking change, backwards-compatible updates do not bump it, and deprecated features stay for at least twelve months before removal. And can you fix metadata after publishing to the registry? No: versions are unique and immutable once published, a typo costs a new version, and range-looking version strings are rejected outright.

分析过程 · 先想清楚再作答

1. 这题看着像流程题，实际考的是「skill 的接口到底是什么」。想清楚这一点，答案自然出来。
2. 先答要不要：对内可以宽松，**对外发布必须写死版本**。写了版本，用户只在这个值变化时才收到更新，这是可控的；不写的话 Git 来源会拿提交哈希当版本，你每推一次内容用户就更一次，团队内部尚可，对外就是失控。
3. 补一条容易忽略的细节：版本不要在包清单和市场清单两处都写，包自己的清单优先级更高，两边不一致会得到一个你自己都解释不清的状态。
4. 接着答判据。什么改动要升版本？不是「改没改文件」，而是「**用户的行为会不会因此变化**」。描述改了、正文步骤改了、脚本参数改了都要升；修错别字、补注释不用。这跟给库发版一个道理，只不过这里的接口不是函数签名。
5. 本题的拿分点在这里：**skill 的接口是描述与正文**。大家都记得改脚本要升版本，却常觉得「我就是把描述改得更准了一点」不算变更。但描述是唯一的触发面，改宽了会开始抢别的任务，改窄了会突然不触发。**描述的每一次改动都是行为变更**，都要在升级说明里单独写一行。
6. 再给两个升级期的具体坑。一是改包名：包名是命名空间，改名等于把包里所有技能的调用名全改了，用户那边所有写死调用名的地方一起断。二是拆包与合包：一个 skill 从 A 包挪到 B 包，对用户来说是「装了 A 的人突然少了一个能力」，必须在升级说明里显式写迁移步骤。
7. 可预期的追问是「怎么知道升级没升坏」。答案是把第三天那套触发测试当回归跑：改描述前后各跑一次同一组正负例，比触发率而不是凭感觉。

How to reason about it · think before answering

1. It looks procedural but really asks what a skill's interface is. Answer that and the rest follows.
2. Should you version? Internally you can be loose; for public distribution you must pin a version. With a version, users update only when it changes. Without one, git sources use the resolved commit, so every push updates everyone, which is tolerable inside a team and out of control outside it.
3. Add an easily missed detail: do not set the version in both the plugin manifest and the marketplace catalog. The plugin manifest wins, and a mismatch leaves a state you cannot explain.
4. Then the criterion. What requires a bump is not whether a file changed but whether user-visible behavior changes. A changed description, changed body steps, or changed script flags all require a bump; typos and comments do not. It is the same as releasing a library, except the interface is not a function signature.
5. The scoring point: a skill's interface is its description and body. Everyone remembers to bump for script changes but treats a slightly sharper description as cosmetic. The description is the only trigger surface: widen it and the skill starts stealing tasks, narrow it and it silently stops firing. Every description change is a behavior change and belongs in the upgrade notes.
6. Give two concrete upgrade traps. Renaming the package changes the namespace, so every skill's invocation name changes and any hard-coded reference breaks. Moving a skill between packages looks to users like a capability disappearing, so the upgrade notes must spell out the migration.
7. Expected follow-up: how do you know an upgrade did not break things? Run the day-three trigger tests as a regression, comparing hit rates on the same labeled queries before and after.

分析过程 · 先想清楚再作答

1. 题眼在「够不够」三个字，它在提示答案是否定的。先把问题重述成一句判断：**版本不是备份**，这句话说出来这题就答对了一半。
2. 两者的语义不一样。备份是「出事了拿回来」，只需要保留最近一份好状态；版本是「两个都在」，要能并排对比、来回切换，最终选哪个由人定。审核场景要的是后者。
3. 所以每个版本要存三类东西：产物本身（按版本分目录，一个文件都不删）、产生它的输入（那一版的台词与画面描述，否则三天后没人说得清两版差在哪）、以及这一版重跑了哪些节点与原因。
4. 当前版本要设计成一个指针，不是一份拷贝。回滚就是把指针挪回去，不搬文件，因此是瞬时且可逆的；这也让「再切回新版本」变成理所当然的操作。
5. 有一个连带影响必须提到，提了就说明你真做过：**回滚一镜会改变整集的时间轴**。新版配音比旧版长一秒，切回去之后后面所有镜头的起止时间都要重排。所以回滚之后要重算一次时间轴，好在这是纯本地计算，很便宜。
6. 可预期的追问是「版本存多久」。按产物体积和业务价值定：小文本无限存，视频这种大件设一个保留期，过期只留元数据和输入，需要时可以按同样的输入重跑出来。

How to reason about it · think before answering

1. The hinge is are they enough, which signals the answer is no. Restate it as a claim: a version is not a backup. Saying that sentence gets you half the credit.
2. The semantics differ. A backup means restore after an incident and only needs the latest good state. A version means both exist, side by side, switchable, with a human choosing. Review workflows need the latter.
3. So each version stores three things: the artifacts themselves, kept in per-version directories with nothing deleted; the inputs that produced them, the line and the visual description, or nobody can explain the difference three days later; and which nodes reran plus why.
4. The current version should be a pointer, not a copy. Rollback moves the pointer without touching files, which makes it instant and reversible, and makes switching forward again equally natural.
5. Mention the knock-on effect, because it shows you have actually shipped this: rolling back one shot changes the whole episode timeline. If the new take of the voice is a second longer, every later shot shifts, so rollback must recompute the timeline. That part is cheap local computation.
6. Expected follow-up: how long to keep versions. Scale it by artifact size and business value: keep small text forever, put a retention window on video, and after expiry keep only metadata and inputs so the artifact can be regenerated on demand.