云策Omni 本地部署完成后，界面上通常已经带着一批可用的能力入口，比如对话、检索、工具调用、定时触发这类模块。真正需要判断的问题在于，这些入口里哪些是平台内置、只需要开关或填写参数就能用，哪些必须由你自己补上定义（提示词、工具描述、模型路径、触发条件）。如果分不清这一点，很容易把原本能跑通的流程改坏。稳妥的顺序是：先把当前可见条目原样记录下来，再用两条标准划分内置与可自定义的边界，然后只挑一项写清目标、做前后对比，最后登记进清单并写明回滚办法。整个过程可以只靠页面行为、配置文件和日志来核对，不需要额外的测试数据。

本地跑起云策Omni 后，建议先做一次能力盘点，不要急着改配置。判断标准可以简化为两条：该条目是否暴露可编辑参数，是否能绑定本地模型文件路径。只满足开关的条目按内置能力使用，不要改动；两条都满足的才视为可自定义，单独立项。每次自定义都要固定输入、固定模型，做一次改动前后输出对比，并把回滚操作写进个人能力清单。这样做的边界是：只对能观察到输出变化的改动负责；无法用日志或页面行为验证的效果，不记为已生效。

在设置页逐项记录当前可见的能力条目

第一步不是改，而是记录。打开设置页或能力管理页，按界面从上到下的顺序，把每个条目名称和当前开关状态抄下来。记录时同时写下记录时间和你所在的页面路径，便于后面回看时确认是同一版本。菜单名、分组名要照抄界面上真实显示的文字，不要凭印象改写或补全，否则后面排查时会找不到对应位置。

可以先写成一张临时表，字段少一点没关系，但要能逐条对应：

记录时间：2025-xx-xx xx:xx
所在页面：设置 > 能力（以界面实际名称为准）

序号 | 条目名称        | 状态 | 备注
1    | 对话            | 开   | 有参数入口
2    | 知识检索        | 开   | 未见参数
3    | 定时任务        | 关   | 未见参数
4    | 工具调用        | 开   | 可填配置

备注栏只写你能看到的现象：有没有输入框、有没有下拉选项、有没有指向文件路径的字段。这一步的作用是把“我记得它开着”变成“某时某页它处于某个状态”，后续任何改动都能对照这份原始快照回退。

用两条标准区分内置能力与可自定义能力

区分不必靠猜，看界面暴露了什么就够。第一条标准：条目是否暴露可编辑参数。有输入框、多行文本框、下拉选项、数值调节，说明这个能力允许你改变行为；只有一个开关，通常意味着内部逻辑固定，你只能决定用不用。第二条标准：是否能绑定本地模型文件路径。出现文件选择、目录填写、模型名下拉、路径输入这类字段，说明这一项和本地模型文件是解耦的，可以换模型；如果没有这类字段，模型是被平台固定住的，改动空间很小。

界面上各举一个可见特征：可编辑参数型，比如“工具调用”条目里有一个填写工具描述的多行输入框，改这里的文字就会影响工具被调用的方式；路径绑定型，比如某个推理条目里有一行“模型路径”，旁边带浏览按钮，指向本地某个目录下的模型文件。两条都满足，可以按自定义能力对待；只满足第一条，按“可配置的内置能力”对待，改参数但不换模型；两条都不满足，就只当开关用，不要试图从配置里硬改。

这个划分的意义在于控制风险：只当开关用的条目，出问题时把开关拨回去就能恢复；暴露参数的条目，改之前要备份原值；能绑路径的条目，换模型前后要能说清用的是哪个文件。

把想自定义的能力写成一句可检验的目标

目标写得虚，后面就没法验证。可检验的意思是：这句话能对应到一个输入、一个预期输出，以及一个可观察的位置。三条示例：

• “让工具调用条目在收到含‘查库存’的输入时，优先调用库存查询工具，而不是走普通对话。”验证方式：用同一句输入各跑一次，看返回里是否出现工具调用记录。
• “把对话条目的默认模型换成本地某个模型文件，并确认启动日志里加载的是该文件。”验证方式：查启动日志中的模型加载行。
• “给定时任务条目加一条每天固定时间触发的任务，触发后能在任务列表里看到执行记录。”验证方式：看任务列表与运行日志。

写完之后先和自己刚记下的条目清单对一遍：如果平台内置能力已经覆盖了这个行为，就说明重复了，不要另建一套。判断重复的办法是拿同一条输入分别喂给内置能力和你的自定义配置，看输出是否已经一致；一致就说明内置能力够用，改动只会增加维护成本。

用同一段输入做改动前后对比

确认自定义是否真的改变了输出，最省事的办法是控制变量。固定一段输入文本，固定使用同一个模型，只在改动前后各跑一次，然后逐字段比对。

建议固定成类似这样的输入，写进一个文本文件反复复用：

请查询编号 A-1001 的库存，并只返回数量。

观察的字段可以包括：返回正文的措辞与结构、是否出现工具调用标识或调用记录、日志里命中的模型名与加载路径、耗时大致量级、是否出现报错或降级提示。两次结果的差异点要具体写出来，比如“改动前返回一段解释性文字，改动后返回单个数字”，而不是笼统写“效果变好了”。如果两次输出完全一致，说明这项改动没有生效，先去查配置是否保存、是否重启加载、日志里读的是不是旧配置，而不是继续叠加改动。

把这次改动写进能力清单并标注回滚办法

验证通过后再登记。清单可以是一个表格文件，字段至少包含以下几项，按你能实际执行的方式填写：

名称       | 触发方式         | 关联模型             | 改动位置                     | 回滚操作
库存查询优先 | 输入含“查库存”   | 本地模型文件（路径略） | 工具调用条目 > 工具描述   | 恢复备份的原文，重启服务
默认对话模型 | 每次对话         | 本地模型文件（路径略） | 推理条目 > 模型路径        | 改回原路径，确认日志加载旧模型

回滚操作要写到能直接照做的程度：改回哪个字段、原值是什么、改完是否需要重启、重启后从哪条日志确认已经生效。触发方式一栏写清楚是关键词、定时还是页面点击，方便后续判断冲突。建议每改一项就更新一次清单，不要等攒了几项再补，否则改动位置很容易记错。清单本身就是这套本地环境的能力地图，下次再遇到“这个开关是干什么的”，先查清单，再动配置。