Cherry Studio 的 Consumer Review 阶段在代码审查中审计共享接口的真实消费者【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio本篇技术文章解析 Cherry Studio 仓库内置代码审查技能/gh-pr-review位于 .agents/skills/gh-pr-review中的第二个审查阶段——Consumer Review消费者审查。该阶段专门审计 diff 中新增或扩张的共享面shared surfaceAPI、DataApi/IpcApi 路由、端点、参数、类型、字段、配置键或架构扩展点是否拥有真实、合法的消费者。读完本文你将掌握一套完整的消费者考古学方法论七步工作流程、四级证据分类、五项架构需求测试、七种处置决策以及如何用合理化防护表抵御评审中的常见自欺话术并能将其落地到 Cherry Studio 的注册表、IpcApi 路由等真实代码结构上。阶段定位它在全流程中站在哪里.agents/skills/gh-pr-review是 Cherry Studio 的自动化代码审查入口支持本地分支、PR、commit、文件和架构文档的审查。它的 SKILL.md 定义了六个严格有序的审查阶段每个阶段只审查通过了上一阶段的对象绝不推翻前序裁决#阶段适用范围参考文档1Product Demand产品需求门任何影响产品语义的变更SKILL.md 内联定义2Consumer消费者审查任何新增或扩张共享面的变更consumer-review.md3Architecture-First代码、混合、架构文档、项目技能cherry-review-guidance.md4Implementation代码 / 文档code-checklist / doc-checklist5Style / conventions代码 / 文档同上Consumer Review 是消费者考古学不是实现质量审计——它回答的问题只有一个这个共享面应不应该存在谁应该拥有它具体规则见 local-review.md 的 Step 2 第 2 步只有存活下来的共享面surviving surfaces才继续进入 Architecture-First 及实现审查被移除、推迟或合并的共享面连同其处置决策一并报告不再做实现质量审查。触发条件由 diff 语义决定绝不由变更标签决定原文档对触发条件的定义非常强硬只要 diff 新增或扩张了共享面就必须运行该阶段——包括 API、DataApi/IpcApi 路由、端点、参数、类型、字段、配置键或架构扩展点——无论变更被标记为feat、fix、refactor、docs、test、chore还是工具链变更。一个引入新路由、新参数或新扩展点的 fix 或技能/工具文档修改同样要接受消费者考古学。唯一的跳过条件diff 没有新增或扩张任何共享面。这个设计与 SKILL.md 中 Stage 1 的精神一脉相承——变更标签不是充分证据change labels are not sufficient evidence。从 jobRegistry.ts 的实现可以看到为什么这条规则重要一个仅十几行的 commit 只要给JobRegistry接口加了一个 key就等于扩张了整个调度系统的共享契约面。核心原则因果链与调用点的正确地位在审计实现质量之前先审计这条因果链root outcome or invariant → normalized demand → owning layer → contract → consumer 根结果或不变量 → 归一化需求 → 拥有层 → 契约 → 消费者原则部分只有一句话但它是整个阶段的判准A call site proves usage, not legitimacy or shape.调用点证明的是被使用了而不是使用得合法或契约形态正确。同时没有任何调用点也不提高证明负担更不是自动拒绝——真实需求可能配错了消费者或抽象。也就是说有人用不是免死金牌没人用也不是死刑判决两侧都要走完整的证据流程。七步工作流程对每个新增面逐一执行原文档要求把每一步应用到 diff 中的每一个新增 API、通道、参数、类型、字段、配置或扩展点上。以下逐节展开。第 1 步重构需求Reconstruct the demand列出所有新共享面及其被精确消费的维度一个合法消费者不能为未使用的字段背书追踪当前消费者和关联消费者直到它们背后的用户结果、业务规则或系统不变量检视相邻实现然后自问如果删掉当前 API 及其历史需求是否依然存在这份契约是否依然自然不能只依赖 PR 描述作为需求证据。如果删掉历史契约是否依然自然是识别 Legacy-shaped 消费者的关键操作很多字段只有在旧架构里才有意义。第 2 步审计消费者合法性Audit consumer legitimacy把每个消费者归入四类之一类别含义Legitimate合法使用了正确的拥有者和边界Compensating补偿式因为正确的能力缺失被迫用最近的 API 加变通逻辑硬凑Legacy-shaped历史形态反映过时格式、过渡架构或历史包袱Misplaced错层需求真实但服务放在了错误的层解析、重试、排序、重复状态、check-then-act、跨层访问都是补偿的信号。关键纪律把这些消费者视为上游需求未被满足的证据永远不是对当前共享面的背书。一个满是 hack 的消费者如果反过来被用来冻结它的变通逻辑进共享契约就是第 4 节红旗之一。第 3 步归一化相关需求Normalize related demands从需求陈述中剥掉名称、历史格式和变通手段按结果、真相源、拥有者、事务、安全、生命周期聚类合并历史差异和调用方专属差异对真正的所有权、权限、原子性、生命周期、副作用或失败模式差异保留独立契约优先稳定核心 薄适配器反对重复工作流或最小公分母式 API。第 4 步证据分类Classify evidence每个共享面的证据归入四级之一证据等级定义Direct直接有合法的当前消费者正在消费该维度Committed已承诺同一变更或关联的近期工作中存在具体消费者Architectural架构性必须先于消费者存在的最小接缝用于保护某个具体的不变量Unsupported speculation无支撑推测只说了未来可能需要没有具体场景、没有拥有者、没有缺失成本注意原文的补充限定直接消费证明的是压力pressure不是放置placement或形态shape——有人用不代表应该放这里、长这样。第 5 步架构性需求的五条件测试Test architectural demand对没有合法当前消费者的共享面必须同时满足以下五条具体的消费者类别或扩展场景拥有该机制的层与被保护的不变量因果性的缺失成本omission cost——边界被破坏、机制重复、不兼容实现、安全缺口或迁移锁定为什么这个接缝必须先于第一个消费者存在保护该不变量的最小稳定机制。任何一条不满足就推迟defer或移除remove。如果五条全过也只保留最小的铺好的路paved road删掉所有猜测性的维度。以下话术在无关联证据和因果失败路径时一律拒绝未来功能需要、灵活性、集中化、技术约束、迁移风险。第 6 步职责与重叠检查Check responsibility and overlap按所有权而非代码行数放置行为安全、权限、事务、不变量、共享策略向中心集中表现层和调用方专属组合留在消费者一侧当拥有者可以原子性地强制约束时优先直接尝试操作try-the-operation而非预先检查对比契约时按语义、拥有者、权限、暴露面、原子性、生命周期、失败模型、成本逐项比较仅共享数据不能证明重复只有上述维度等价时才谈复用。第 7 步处置决策并移交Decide, then hand off对每个共享面或归一化后的需求组七选一决策含义Keep需求与形态都成立Narrow删掉无支撑的维度Split把有效核心与无关关注点拆开Consolidate把表达同一需求的多个面合并Replace保留需求更换消费者、拥有者或抽象Defer需求尚属可能不提交Remove需求已不存在或已有等价契约拥有它报告顺序有强制要求先报告根结果、证据、消费者合法性、本质差异、拥有者、备选方案与决策。只有存活面继续进入 Architecture-First 与 Implementation 审查。原文档还特别交代了一个容易踩的边界本阶段与 Architecture-First 阶段在所有权问题上有意重叠。Consumer 问的是这个面该不该存在、该由谁拥有而 cherry-review-guidance.md 问的是已存在的代码是否尊重了文档化的边界。同一个缺陷只应在更早的阶段报告一次并且两个阶段都套用 cherry-review-guidance.md 的Fix Recommendation Policy修复海拔规则——修复必须发生在缺陷真实所在的层然后在该海拔上做最小的完整修复。合理化防护表Rationalization Guards原文档最有实战价值的部分是一张针对评审者/作者自欺话术的免疫表。完整继承如下话术标准回应API 很干净类型设计很优雅。质量不能证明存在性。它有消费者。验证合法性与精确消费变通逻辑不构成背书。它没有消费者。走五条件架构测试零消费本身不决定任何事。导出没用到加个测试覆盖吧。测试验证行为不创造需求。架构以后会需要它。说出不变量、因果缺失成本、消费者类别、为什么是现在、最小接缝。是技术约束要求的。把约束追溯到根需求约束不是公理。存在与否是架构师的裁量。权威既不豁免需求审查也不把它降级成小问题。调用方一行代码就能算出来。按所有权和不变量放置策略不按代码长度。已有 API 返回同样的数据。先完整对比语义再宣布重复。这些消费者只是略有不同。证明差异是语义性的而非历史或调用方专属。它是向前兼容/增量式的。只保留具体需求增量式契约承担永久成本。最后一条值得强调additive只增不改在直觉上是安全操作但文档指出增量式契约自带永久成本——每多一个无人消费但留着以备将来的参数、字段或配置键都是所有未来读者要理解的永久税。这与 define.ts 中defineRoute的注释哲学完全一致IpcApi 故意不提供跳过校验的开关YAGNI——将来某个热点路由真被 profile 证明需要时再加字段。红旗Red Flags出现即回退到第 1 步原文档列出四种必须暂停、并从第 1 步重启的情形在还没有陈述根需求、证据和合法消费者之前实现层评论开始堆积把某个调用点当作契约应该放在这里/形态正确的证据把零当前消费当作自动拒绝或当作接受架构主张的通行证两种极端都错用补偿式或 hack 味浓的消费者来冻结它的变通逻辑写入共享契约。校准案例Calibration文档末尾给了两个标准尺度的判例展示了有消费者 ≠ Keep与无消费者 ≠ Remove的中间地带关联独立模块若不通过注册接缝就会直接导入特权内部实现保留最小注册接缝删掉猜测性的旋钮渲染端因为缺少原子操作而自行解析原始错误并重试替换该抽象而不是扩张错误分类学。第二条正好是第 2 步Compensating消费者的标准处置下游的重试代码是上游能力缺失的症状正确动作是向上提供原子操作而不是把解析原始错误这类补偿逻辑固化进共享契约。源码纵深Consumer Review 在 Cherry Studio 代码结构中的落点Consumer Review 审计的共享面在 Cherry Studio 中有非常具体的物理形态。cherry-review-guidance.md 的 Architecture-First 章节揭示了这个代码库在每个深度重复出现的结构模式通用引擎 声明面generic engine paired with a declaration surface——WindowManagerwindowRegistry、生命周期容器 serviceRegistry phase/依赖装饰器、JobManager/SchedulerServicejobRegistry、SeedRunnerseederRegistry、MigrationEnginemigrators/、DataApi/IpcApi 路由 单点 schema 与 handler 注册、CacheService/PreferenceService 共享 schema 注册表、AI runtime 注册表 驱动、工具/MCP 管线 领域工具单元。把这套结构代入 Consumer Review 的语言可以得到几条可操作的落地判据1. 新增路由/参数就是扩张共享面。IpcApi 的每个路由都是 define.ts 中defineRoute声明的route → { input, output }zod schema 对运行时是恒等函数但 schema 在一处捕获后向 handler 签名、preload、渲染端 facade 全链路推导。给 input schema 加一个字段就扩张了整个进程间契约面——按触发规则这类 diff 即使标记为chore也必须跑消费者考古追问这个字段被精确消费的维度是什么有没有别的消费者需要它。契约命名与字段风格的规范见 docs/references/ipc/ipc-schema-guide.md。2. 注册表声明合并是架构性证据的典型场景。jobRegistry.ts 是一个编译期类型目录业务模块通过 TypeScript 声明合并declare module main/core/job/jobRegistry注册jobType → payload映射之后jobManager.enqueue的参数就被类型系统精确检查。这正是第 5 步架构性需求五条件测试要保护的对象注册接缝必须先于消费者存在才能保证所有 enqueue 调用点获得编译期校验缺失成本 字符串 job type 散落各处、改名不触发类型报错。反过来如果给这个接口加了一个没有任何模块声明合并使用的 key就落入Unsupported speculation——该 key 应被 Narrow 或 Remove。3. 跨进程共享层的准入本身有需求门槛。docs/references/architecture/shared-layer.md 要求src/shared/中的代码必须被 main 和 renderer真实使用预期复用prospective reuse不足以支撑放置且共享层不得导出可变运行时状态或活动单例。cherry-review-guidance.md 的 Main/Renderer/Shared 章节同样重申放进shared前必须有双进程的实际消费。也就是说Consumer Review 的第 4 步证据分类在src/shared/有明文文档支撑——未来可能需要Unsupported speculation在这里连架构性主张都不构成。4. 补偿信号的源码级对照。第 2 步列举的补偿信号在 guidance 文档的实体泄漏表格中有对应实体通用 dispatcher/pipeline/registry 按具体 id 分支、只被一个领域消费却挂在通用契约上的参数如共享ToolHandler.run签名上只有知识域 handler 才用的allowedIds、渲染端因为缺少原子操作而自行解析原始错误重试——全部属于未满足的上游需求Consumer Review 的处置方向与 guidance 的Fix Direction: Restore Ownership, Never Annotate the Leak一致把行为移回拥有层而不是在通用契约上加旗标、旁表或特判。方法论小结Consumer Review 阶段的整套机制可以浓缩为三条纪律按 diff 语义触发不按标签——任何扩张共享面的变更无论feat/fix/chore都要过消费者考古证据先于质量——调用点证明使用但不证明合法性与形态零消费不判死刑但必须通过五条件架构测试七种决策一次报告——每个面给出 Keep/Narrow/Split/Consolidate/Replace/Defer/Remove 之一先报决策与证据链存活面才进入后续 Architecture-First 审查与后阶段的所有权发现按更早阶段唯一报告原则分工。对维护 Cherry Studio 的开发者而言这套流程的价值在于把这个新参数/新路由/新注册键该不该合入从主观裁量变成了可执行的证据清单重构需求、审计消费者合法性、归一化需求、分类证据、跑架构测试、检查职责重叠、落一个决策——每一步都有原文档给出的判准和防自欺的防护表可复用于任何往 DataApi/IpcApi 路由、注册表接缝或共享层契约添加表面的 PR 审查。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cherry Studio 的 Consumer Review 阶段：在代码审查中审计共享接口的真实消费者
Cherry Studio 的 Consumer Review 阶段在代码审查中审计共享接口的真实消费者【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio本篇技术文章解析 Cherry Studio 仓库内置代码审查技能/gh-pr-review位于 .agents/skills/gh-pr-review中的第二个审查阶段——Consumer Review消费者审查。该阶段专门审计 diff 中新增或扩张的共享面shared surfaceAPI、DataApi/IpcApi 路由、端点、参数、类型、字段、配置键或架构扩展点是否拥有真实、合法的消费者。读完本文你将掌握一套完整的消费者考古学方法论七步工作流程、四级证据分类、五项架构需求测试、七种处置决策以及如何用合理化防护表抵御评审中的常见自欺话术并能将其落地到 Cherry Studio 的注册表、IpcApi 路由等真实代码结构上。阶段定位它在全流程中站在哪里.agents/skills/gh-pr-review是 Cherry Studio 的自动化代码审查入口支持本地分支、PR、commit、文件和架构文档的审查。它的 SKILL.md 定义了六个严格有序的审查阶段每个阶段只审查通过了上一阶段的对象绝不推翻前序裁决#阶段适用范围参考文档1Product Demand产品需求门任何影响产品语义的变更SKILL.md 内联定义2Consumer消费者审查任何新增或扩张共享面的变更consumer-review.md3Architecture-First代码、混合、架构文档、项目技能cherry-review-guidance.md4Implementation代码 / 文档code-checklist / doc-checklist5Style / conventions代码 / 文档同上Consumer Review 是消费者考古学不是实现质量审计——它回答的问题只有一个这个共享面应不应该存在谁应该拥有它具体规则见 local-review.md 的 Step 2 第 2 步只有存活下来的共享面surviving surfaces才继续进入 Architecture-First 及实现审查被移除、推迟或合并的共享面连同其处置决策一并报告不再做实现质量审查。触发条件由 diff 语义决定绝不由变更标签决定原文档对触发条件的定义非常强硬只要 diff 新增或扩张了共享面就必须运行该阶段——包括 API、DataApi/IpcApi 路由、端点、参数、类型、字段、配置键或架构扩展点——无论变更被标记为feat、fix、refactor、docs、test、chore还是工具链变更。一个引入新路由、新参数或新扩展点的 fix 或技能/工具文档修改同样要接受消费者考古学。唯一的跳过条件diff 没有新增或扩张任何共享面。这个设计与 SKILL.md 中 Stage 1 的精神一脉相承——变更标签不是充分证据change labels are not sufficient evidence。从 jobRegistry.ts 的实现可以看到为什么这条规则重要一个仅十几行的 commit 只要给JobRegistry接口加了一个 key就等于扩张了整个调度系统的共享契约面。核心原则因果链与调用点的正确地位在审计实现质量之前先审计这条因果链root outcome or invariant → normalized demand → owning layer → contract → consumer 根结果或不变量 → 归一化需求 → 拥有层 → 契约 → 消费者原则部分只有一句话但它是整个阶段的判准A call site proves usage, not legitimacy or shape.调用点证明的是被使用了而不是使用得合法或契约形态正确。同时没有任何调用点也不提高证明负担更不是自动拒绝——真实需求可能配错了消费者或抽象。也就是说有人用不是免死金牌没人用也不是死刑判决两侧都要走完整的证据流程。七步工作流程对每个新增面逐一执行原文档要求把每一步应用到 diff 中的每一个新增 API、通道、参数、类型、字段、配置或扩展点上。以下逐节展开。第 1 步重构需求Reconstruct the demand列出所有新共享面及其被精确消费的维度一个合法消费者不能为未使用的字段背书追踪当前消费者和关联消费者直到它们背后的用户结果、业务规则或系统不变量检视相邻实现然后自问如果删掉当前 API 及其历史需求是否依然存在这份契约是否依然自然不能只依赖 PR 描述作为需求证据。如果删掉历史契约是否依然自然是识别 Legacy-shaped 消费者的关键操作很多字段只有在旧架构里才有意义。第 2 步审计消费者合法性Audit consumer legitimacy把每个消费者归入四类之一类别含义Legitimate合法使用了正确的拥有者和边界Compensating补偿式因为正确的能力缺失被迫用最近的 API 加变通逻辑硬凑Legacy-shaped历史形态反映过时格式、过渡架构或历史包袱Misplaced错层需求真实但服务放在了错误的层解析、重试、排序、重复状态、check-then-act、跨层访问都是补偿的信号。关键纪律把这些消费者视为上游需求未被满足的证据永远不是对当前共享面的背书。一个满是 hack 的消费者如果反过来被用来冻结它的变通逻辑进共享契约就是第 4 节红旗之一。第 3 步归一化相关需求Normalize related demands从需求陈述中剥掉名称、历史格式和变通手段按结果、真相源、拥有者、事务、安全、生命周期聚类合并历史差异和调用方专属差异对真正的所有权、权限、原子性、生命周期、副作用或失败模式差异保留独立契约优先稳定核心 薄适配器反对重复工作流或最小公分母式 API。第 4 步证据分类Classify evidence每个共享面的证据归入四级之一证据等级定义Direct直接有合法的当前消费者正在消费该维度Committed已承诺同一变更或关联的近期工作中存在具体消费者Architectural架构性必须先于消费者存在的最小接缝用于保护某个具体的不变量Unsupported speculation无支撑推测只说了未来可能需要没有具体场景、没有拥有者、没有缺失成本注意原文的补充限定直接消费证明的是压力pressure不是放置placement或形态shape——有人用不代表应该放这里、长这样。第 5 步架构性需求的五条件测试Test architectural demand对没有合法当前消费者的共享面必须同时满足以下五条具体的消费者类别或扩展场景拥有该机制的层与被保护的不变量因果性的缺失成本omission cost——边界被破坏、机制重复、不兼容实现、安全缺口或迁移锁定为什么这个接缝必须先于第一个消费者存在保护该不变量的最小稳定机制。任何一条不满足就推迟defer或移除remove。如果五条全过也只保留最小的铺好的路paved road删掉所有猜测性的维度。以下话术在无关联证据和因果失败路径时一律拒绝未来功能需要、灵活性、集中化、技术约束、迁移风险。第 6 步职责与重叠检查Check responsibility and overlap按所有权而非代码行数放置行为安全、权限、事务、不变量、共享策略向中心集中表现层和调用方专属组合留在消费者一侧当拥有者可以原子性地强制约束时优先直接尝试操作try-the-operation而非预先检查对比契约时按语义、拥有者、权限、暴露面、原子性、生命周期、失败模型、成本逐项比较仅共享数据不能证明重复只有上述维度等价时才谈复用。第 7 步处置决策并移交Decide, then hand off对每个共享面或归一化后的需求组七选一决策含义Keep需求与形态都成立Narrow删掉无支撑的维度Split把有效核心与无关关注点拆开Consolidate把表达同一需求的多个面合并Replace保留需求更换消费者、拥有者或抽象Defer需求尚属可能不提交Remove需求已不存在或已有等价契约拥有它报告顺序有强制要求先报告根结果、证据、消费者合法性、本质差异、拥有者、备选方案与决策。只有存活面继续进入 Architecture-First 与 Implementation 审查。原文档还特别交代了一个容易踩的边界本阶段与 Architecture-First 阶段在所有权问题上有意重叠。Consumer 问的是这个面该不该存在、该由谁拥有而 cherry-review-guidance.md 问的是已存在的代码是否尊重了文档化的边界。同一个缺陷只应在更早的阶段报告一次并且两个阶段都套用 cherry-review-guidance.md 的Fix Recommendation Policy修复海拔规则——修复必须发生在缺陷真实所在的层然后在该海拔上做最小的完整修复。合理化防护表Rationalization Guards原文档最有实战价值的部分是一张针对评审者/作者自欺话术的免疫表。完整继承如下话术标准回应API 很干净类型设计很优雅。质量不能证明存在性。它有消费者。验证合法性与精确消费变通逻辑不构成背书。它没有消费者。走五条件架构测试零消费本身不决定任何事。导出没用到加个测试覆盖吧。测试验证行为不创造需求。架构以后会需要它。说出不变量、因果缺失成本、消费者类别、为什么是现在、最小接缝。是技术约束要求的。把约束追溯到根需求约束不是公理。存在与否是架构师的裁量。权威既不豁免需求审查也不把它降级成小问题。调用方一行代码就能算出来。按所有权和不变量放置策略不按代码长度。已有 API 返回同样的数据。先完整对比语义再宣布重复。这些消费者只是略有不同。证明差异是语义性的而非历史或调用方专属。它是向前兼容/增量式的。只保留具体需求增量式契约承担永久成本。最后一条值得强调additive只增不改在直觉上是安全操作但文档指出增量式契约自带永久成本——每多一个无人消费但留着以备将来的参数、字段或配置键都是所有未来读者要理解的永久税。这与 define.ts 中defineRoute的注释哲学完全一致IpcApi 故意不提供跳过校验的开关YAGNI——将来某个热点路由真被 profile 证明需要时再加字段。红旗Red Flags出现即回退到第 1 步原文档列出四种必须暂停、并从第 1 步重启的情形在还没有陈述根需求、证据和合法消费者之前实现层评论开始堆积把某个调用点当作契约应该放在这里/形态正确的证据把零当前消费当作自动拒绝或当作接受架构主张的通行证两种极端都错用补偿式或 hack 味浓的消费者来冻结它的变通逻辑写入共享契约。校准案例Calibration文档末尾给了两个标准尺度的判例展示了有消费者 ≠ Keep与无消费者 ≠ Remove的中间地带关联独立模块若不通过注册接缝就会直接导入特权内部实现保留最小注册接缝删掉猜测性的旋钮渲染端因为缺少原子操作而自行解析原始错误并重试替换该抽象而不是扩张错误分类学。第二条正好是第 2 步Compensating消费者的标准处置下游的重试代码是上游能力缺失的症状正确动作是向上提供原子操作而不是把解析原始错误这类补偿逻辑固化进共享契约。源码纵深Consumer Review 在 Cherry Studio 代码结构中的落点Consumer Review 审计的共享面在 Cherry Studio 中有非常具体的物理形态。cherry-review-guidance.md 的 Architecture-First 章节揭示了这个代码库在每个深度重复出现的结构模式通用引擎 声明面generic engine paired with a declaration surface——WindowManagerwindowRegistry、生命周期容器 serviceRegistry phase/依赖装饰器、JobManager/SchedulerServicejobRegistry、SeedRunnerseederRegistry、MigrationEnginemigrators/、DataApi/IpcApi 路由 单点 schema 与 handler 注册、CacheService/PreferenceService 共享 schema 注册表、AI runtime 注册表 驱动、工具/MCP 管线 领域工具单元。把这套结构代入 Consumer Review 的语言可以得到几条可操作的落地判据1. 新增路由/参数就是扩张共享面。IpcApi 的每个路由都是 define.ts 中defineRoute声明的route → { input, output }zod schema 对运行时是恒等函数但 schema 在一处捕获后向 handler 签名、preload、渲染端 facade 全链路推导。给 input schema 加一个字段就扩张了整个进程间契约面——按触发规则这类 diff 即使标记为chore也必须跑消费者考古追问这个字段被精确消费的维度是什么有没有别的消费者需要它。契约命名与字段风格的规范见 docs/references/ipc/ipc-schema-guide.md。2. 注册表声明合并是架构性证据的典型场景。jobRegistry.ts 是一个编译期类型目录业务模块通过 TypeScript 声明合并declare module main/core/job/jobRegistry注册jobType → payload映射之后jobManager.enqueue的参数就被类型系统精确检查。这正是第 5 步架构性需求五条件测试要保护的对象注册接缝必须先于消费者存在才能保证所有 enqueue 调用点获得编译期校验缺失成本 字符串 job type 散落各处、改名不触发类型报错。反过来如果给这个接口加了一个没有任何模块声明合并使用的 key就落入Unsupported speculation——该 key 应被 Narrow 或 Remove。3. 跨进程共享层的准入本身有需求门槛。docs/references/architecture/shared-layer.md 要求src/shared/中的代码必须被 main 和 renderer真实使用预期复用prospective reuse不足以支撑放置且共享层不得导出可变运行时状态或活动单例。cherry-review-guidance.md 的 Main/Renderer/Shared 章节同样重申放进shared前必须有双进程的实际消费。也就是说Consumer Review 的第 4 步证据分类在src/shared/有明文文档支撑——未来可能需要Unsupported speculation在这里连架构性主张都不构成。4. 补偿信号的源码级对照。第 2 步列举的补偿信号在 guidance 文档的实体泄漏表格中有对应实体通用 dispatcher/pipeline/registry 按具体 id 分支、只被一个领域消费却挂在通用契约上的参数如共享ToolHandler.run签名上只有知识域 handler 才用的allowedIds、渲染端因为缺少原子操作而自行解析原始错误重试——全部属于未满足的上游需求Consumer Review 的处置方向与 guidance 的Fix Direction: Restore Ownership, Never Annotate the Leak一致把行为移回拥有层而不是在通用契约上加旗标、旁表或特判。方法论小结Consumer Review 阶段的整套机制可以浓缩为三条纪律按 diff 语义触发不按标签——任何扩张共享面的变更无论feat/fix/chore都要过消费者考古证据先于质量——调用点证明使用但不证明合法性与形态零消费不判死刑但必须通过五条件架构测试七种决策一次报告——每个面给出 Keep/Narrow/Split/Consolidate/Replace/Defer/Remove 之一先报决策与证据链存活面才进入后续 Architecture-First 审查与后阶段的所有权发现按更早阶段唯一报告原则分工。对维护 Cherry Studio 的开发者而言这套流程的价值在于把这个新参数/新路由/新注册键该不该合入从主观裁量变成了可执行的证据清单重构需求、审计消费者合法性、归一化需求、分类证据、跑架构测试、检查职责重叠、落一个决策——每一步都有原文档给出的判准和防自欺的防护表可复用于任何往 DataApi/IpcApi 路由、注册表接缝或共享层契约添加表面的 PR 审查。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考