能力要靠消费方认账

更新于 2026-09-22

能力要靠消费方认账

# 能力要靠消费方认账

结论

一个能力有没有，不由「你这边做了多少」决定，而由「对面认不认」决定。 你反复遇到的失败形状是：自己这一侧全部就绪 —— 代码写了、参数传了、bridge 起了、 配置文件在、按钮在 —— 但对面那一侧根本不看它。 症状统一是「做了但没用」，且不报错。

判据一句话：这个能力依赖的每一项，谁在对面认账？ 答不出认账方，就等于没做。

九处证据

出处自己这侧做了对面没认账的是什么症状
远程控制本机Agent要让bridge跑在本机bridge 跑在云服务器上，功能全对文件系统在 Mac 上，不在服务器上能连上、能对话，但看不到 /Users/...
移动应用正式分发需要签名打包成功、装得上系统只认受信任开发者的签名装上了却白屏 / 打不开
运行时依赖属于平台不属于业务代码业务代码里找了半天没引入依赖由运行时注入（Hermes），不在 package.json反复怀疑自己引错了东西
改协议要同时改两端bridge 侧协议已改客户端监听的是另一套连接设置页显示「已连上」，聊天页没反应
控件参数要在下游被消费控件传出了 --heading-gap模板 CSS 里根本没这个变量「调了没反应」，不报错
环境变量校验要按模块懒加载变量都声明在 env.ts启动流程一刀切校验，未开发模块也拦只想登录，却因 AI key 缺失起不来
worktree是独立目录产物与配置都隔离主目录里改了 .env.local、重启了服务你访问的是另一个目录的产物「改了环境变量不生效」
手机后台推送要靠服务端远程推送本地通知、前台 WebSocket 都写好了iOS 系统会在退后台时挂起 App电脑上跑完了，手机没推
能力链路打通不等于默认开启模型原生支持 + thinking_delta 事件转发 + 用量统计 + 前端思考块 UI，链路全通调用参数：路由里 thinkingLevel 除 Deep Insight 外恒为 off普通对话看不到思考过程，像是「没这个能力」

综合判断

  1. 「我这边就绪」和「能力可用」之间隔着一个别人的判定。 九处的对面分别是：另一台机器的文件系统、手机系统、运行时、客户端、模板 CSS、启动流程、 另一个工作目录、iOS 后台策略、发给 provider 的调用参数。它们有一个共同点 —— 它们都不是你写代码的那个地方。

    推论：「对面认账」不总是别人的系统，也可能只是你自己链路里最后那一行参数。 开关类能力的最后一跳（thinkingLevel、reasoning_effort）最容易漏，因为前面的链路 全都看得见、都正常，只有末端那一次请求里没有它。开启与否往往还是成本决策 （延迟 + reasoning token），所以合理形态是按用途分级，而不是全局一刀切。

  2. 所以排查方向应当是「从消费方倒推」，不是「从实现方顺推」。 顺着自己的代码查，永远查不出问题：代码确实是对的，只是没人在对面读它。 这也解释了为什么这些坑全都不报错 —— 对面不认账不是错误，是沉默。

  3. 可迁移的动作：任何一个「能力没生效」的现象，先画一张两栏表 —— 左栏「我这边提供了什么」，右栏「谁在对面读它、以什么形式读」。 右栏为空的那一行就是根因。补充动作：确认你操作的那一份，就是你运行时读的那一份 （worktree / 运行目录 / 产物版本 —— 见 功能缺失先确认运行的是哪份产物）。

与既有 synthesis 的关系

  • 分层要落到运行时才有效 —— 讲「约束要有人读」；本条把「有人」具体化成对面那一侧： 分层失败往往不是没写校验器，而是校验器/消费方在另一台机器、另一个目录、另一个进程里。
  • 存量不会自动跟上新逻辑 —— 讲「新逻辑要覆盖存量对象」；本条讲「新逻辑要覆盖对面的读取方」。 两条合起来是同一句：生效 = 有执行者 × 所有对象都会经过它 × 执行者在正确的机器上。
  • 先定位归属层再动手 —— 本条是它在「能力建设」侧的镜像：先定位认账方在哪一层，再动手。

为什么这是 synthesis

单看每一页，都是某个领域的常识（bridge 要跑本机、App 要签名、hook 脚本要适配器）。 并排之后才看得出它们共享同一个失败形状：提供方就绪 ≠ 消费方认账。 这个形状与平台无关，可以直接带走。

相关