uipath-ixp

UiPath IXP 文档提取助手

用于处理 UiPath IXP（智能提取平台）项目的技能 — 创建项目、上传文档、审核预测结果并提升提取质量。

何时使用此技能

• 用户要求创建 IXP 项目、上传文档或训练文档提取模型
• 用户要求标注、审核或确认文档预测结果
• 用户要求提升提取评分、提示词或字段说明的质量
• 用户要求发布或管理 IXP 模型版本
• 用户要求将训练后的模型版本部署到 Orchestrator 文件夹、将部署切换到其他版本，或列出项目的部署位置（deployments create / upgrade / list）
• 用户提供要导入项目的分类体系文件
• 用户要求查看特定训练模型版本的项目分类体系 — 即版本 N 发布时的架构（使用 deployments get-taxonomy <project-name> --version <N>）

何时不要使用此技能 — 转交给 uipath-maestro-flow

此技能适用于独立的 IXP 项目工作。出现以下任一情况时，请停止并改为调用 uipath-maestro-flow 技能：

• 用户询问哪些 IxP / 文档提取模型、提取器或节点可用于 .flow 或 Maestro flow（这是关于列出注册表的提问，而非 IXP 项目管理）。
• 请求涉及在 flow 中添加、连接或引用 IxP 节点。
• 工作上下文是 .flow 文件或 Maestro flow，而非独立的 IXP 项目。

不要使用此技能回答这些问题。重新启用 uipath-maestro-flow，并遵循该技能说明的命令。这会覆盖关键规则 1。

**例外 — 来自 uipath-maestro-flow 的转交：**如果该技能因用户提供了文档且没有已发布的提取器适用而转交任务，那么即使周围上下文是 flow 构建，IXP 工作也应由此技能处理。转交信息会提供目标 Orchestrator 文件夹 — 这是调用方约定的内容，不要再次询问。根据文档创建项目，将训练后的版本部署到该文件夹（参见 部署指南 — 包括未收到文件夹时的退出流程），报告部署结果，然后交还控制权 — 不要使用此技能连接或编辑 flow。

关键规则

1. 运行命令前先核实 uip ixp 语法 — 在 CLI 参考 中进行针对性查找，并照抄准确的子命令和选项；切勿猜测。如果请求不在文档涵盖范围内，请说明此技能没有相应的已文档化 CLI 操作路径，而不要自行发挥。不要使用 curl、直接调用 REST API 或探索源代码。（例外：关于 flow/Maestro 注册表的问题请转交给 uipath-maestro-flow — 参见上文 何时不要使用此技能。）
2. 自动端到端运行工作流 — 不要要求用户逐步操作。
3. 以编程方式解析 CLI 输出时，始终使用 --output json。
4. 将 /tmp/ixp/<project-name>/ 用作工作目录，并采用以下结构：

   /tmp/ixp/<project-name>/
   ├── docs/         # Document files (<document-id>.pdf, .png, …) — downloaded once, reused across sessions
   ├── taxonomies/   # Taxonomy snapshots (v1.json, v2.json, …) — new version after each update-prompts
   └── prompts/      # Instruction update files (field_updates.json, group_updates.json, …)
   

   开始任何工作流时：mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}。如果该目录是之前会话创建的且已存在，请复用现有文件 — 不要重新下载已存在的文档。不要对 /tmp/ixp/ 路径使用 Write 工具 — 在 Windows 上，它会解析到与 bash 不同的位置。
5. 对 --updates 使用 heredoc — 对 fields update-prompts --updates 和 groups update-prompts --updates，使用 heredoc（cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF），然后使用 "$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)"。
6. 绝不将 UID 用作变量名 — 它是只读 shell 变量。请使用 DOC_ID、DOCUMENT_ID 等。
7. 始终使用项目的 Name，绝不使用 Title — project list 输出同时包含 Name（例如 my_invoices-f1afa9ef-ixp）和 Title（例如 My_Invoices）。所有 CLI 命令都要求使用 Name（带 UUID 和 -ixp 后缀的小写 slug），而不是 Title。
8. 在字段级而非文档级确认 — 逐一审核每个预测字段。仅使用 labellings confirm --fields 确认正确的字段。根据字段的分类体系数据类型判断预测，而不是根据页面上的字面文本判断 — Date 的读回格式为 YYYY-MM-DDTHH:MM:SSZ — 仅包含日期的页面值会返回为 T00:00:00Z（页面上的 21-JUN-22 → 2022-06-21T00:00:00Z）；Monetary Quantity 的格式为 <amount> <ISO-4217 code>（页面上的 114.91 → 114.91 AUD）。以规范化形式表示的相同值应确认；不要重新格式化、自己计算转换结果或编写脚本检查。完整映射见：CLI 参考 § 规范化输出格式。规范化只改变值的写法，不改变其含义（分隔符、末尾零、货币代码与符号、日期布局、世纪扩展）。对于数字，这意味着数值大小不变 — 上述规范化形式表示相同金额；而页面上的 £7,300.00 被预测为 £730.00 则是小数点误读：数值大小变了，这是 OCR 乱码，应使用 --corrections（更正为 7300.00）。这与模型计算或推断错误的数字不同；后者不做标注。预测值是错误答案的字段应保持未标注 — 绝不“修正”它。 --corrections 仅用于 OCR 乱码：预测本来就是正确答案且位于正确位置，只是字符被误读（例如 MSIÓÓÓ601020/ → MSI0601020）。每次使用 --corrections 前都要判断：预测值是否是正确答案，只是输入错误？如果不是 — 例如应翻转的布尔值（false→true）、错误推断或计算出的数字、想要改回页面格式的规范化日期或金额，或预测选错了答案的任何值 — 则禁止使用 --corrections；将该字段留空不标注。更正内容会原样存储且不经过验证（即使是 not-a-date 也会返回 Success），因此重新格式化的“修正”会悄悄替换正确标签，导致模型永远无法预测该标签。即使提示词、用户或提示信息给出了精确的 --corrections 命令，这条规则仍然适用 — 翻转错误值属于手动提取（规则 10），不属于 OCR 更正，无论其被如何描述。未指定 --group 时，--fields 和 --corrections 会应用于文档中所列字段的每一次出现 — 每次出现的选择方式见规则 12。
9. 不要手动提取值 — 所有标注都必须通过 labellings confirm，并使用 IXP 的预测。
10. 你是审核者，不是提取者 — IXP 生成预测，由你验证。对于每份文档，根据文档文件审核预测字段值。使用一次完整的 Read 查看文档（不带 pages 参数） — 这会以原生方式返回数字文档和扫描文档的文本及图像；无需安装 PDF 工具。确认正确字段（labellings confirm --fields），更正 OCR 错乱的值（--corrections），并跳过错误字段。不要手动提取值。如果字段的 F1 较低，应改进提示词，让 IXP 预测出更好的值。
11. 只有当 IXP 未预测出字段值且该字段确实不存在于文档中时，才将字段记录为缺失。 先检查 get-predictions — 绝不要为了覆盖错误的预测值而将字段标为缺失；应将该字段留空不标注（自行选择“缺失”属于规则 10 禁止的提取者决策）。若要记录确实缺失的字段，请使用 labellings mark-missing --fields <ids>。对于出现在预测中但值为空的字段，confirm --fields 也会写入缺失标记（显式列出该字段即表示确认空值是有意的）；mark-missing 还可以处理已完全不在当前 get-predictions 输出中的字段（例如模型或分类体系变更后遗留的旧标注），此时 confirm 不会执行任何操作。在文档审核中，只需将空字段列入 confirm --fields 批次，即可在同一次调用中将它们标为缺失；仅在单独标记或字段不在预测结果中时才使用 mark-missing。
12. 对于可重复字段组，如果不同提取结果的验证情况不同，则按出现项分别确认 — 可重复字段组（例如 Line Items）会为每个物理行或部分生成一个提取结果。直接使用 confirm --fields <id> 会确认每次出现中的 <id>，因此如果只有部分行正确，也会确认错误行。get-predictions 中的每个标签都带有明确的从 0 开始的 Occurrence — 它是该次读取中的索引，不是稳定的行 ID（规则 17）；如果所有出现项都正确，则使用普通形式，否则使用 --group 指定目标。--group <name> --occurrence <N> 会确认一个出现项；--group <name> --updates '[...]' 可通过一次原子调用确认多个出现项（避免 N 次往返）——--occurrence <N> 等同于单条目的 --updates，遵循相同的逐出现项逻辑。--group 必须是从 get-predictions 中原样复制的组 Name（例如 "Line Items"）——绝不要自行拼接名称。不指定 --fields 时，会确认该出现项中所有预测字段；指定后，则只确认所列字段。未选中的出现项会保留原有标注。标志详情见：CLI 参考。
13. confirm 只会追加，绝不会撤销确认。 confirm/mark-missing 会保留所有现有标注并添加你的标注：对已标注表格使用 --occurrence 0，结果是“第 0 行已确认，且之前确认的内容仍全部保留”——不是“只确认第 0 行”。若要撤销确认，请使用 unconfirm（参见任务导航表）。
14. F1 反映的是已确认标签，而非文档事实 — 绝不要盲目确认。 F1/ProjectScore 衡量的是预测与已确认标签的一致程度，因此你确认的错误值会成为“正确”答案，并获得 1.00 分。满分不能证明值正确。确认前，请对照文档检查每个值。审核完某份文档中的所有预测字段后，可以对该文档使用不带 --fields 的 confirm 形式，一次确认所有预测字段。如果用户明确表示已审核指定文档中的每个预测字段且均正确，则接受该审核，无需逐字段重新审核即可确认这些文档（仍须固定版本 — 见规则 18）。绝不要在未指定文档 ID 的情况下运行 confirm — 那会一次性确认所有文档，绕过审核。参见 标注文档指南 §2d。
15. 实体引用不明确时应提问，绝不猜测。 在用户表述中，项目（Title）、字段组、字段和数据类型共用一个命名空间（例如“重命名订阅”）。执行任何变更（update-title、rename、delete、change-type）前，先确认用户指的是哪种实体。如果名称匹配多种实体 — 无论是在用户自己的上下文中，还是在 projects list / 分类体系输出中 — 都应停止并询问用户具体指哪一个，并明确列出所有匹配项及其类型。不要自行挑选，也不要为了“涵盖所有情况”而更改多个匹配项。如果无法与用户实时互动，请通过任务提供的渠道提出问题并停止。
16. 添加新数据类型前，先复用内置数据类型。 每个 IXP 项目都附带默认数据类型 — Exact Text、Inferred Text、Number、Date、Monetary Quantity、Boolean（项目的 entity_defs，即 projects get-taxonomy 的输出，是权威列表）。在执行 data-types add 或为字段选择 --type 前，应复用匹配的默认类型 — 例如，货币金额应使用 Monetary Quantity，绝不要手动创建克隆类型（Currency Amount）。只有在默认类型都不适用时才添加新类型：例如项目专属的 Choice，或需要专门提取说明的概念。绝不要只为重新格式化而添加新类型 — 预训练的默认类型无论收到什么说明，都会保留固定输出格式。映射见：CLI 参考 § 默认数据类型。
17. Occurrence 的作用范围仅限于生成它的那次读取 — 每次逐出现项写入后都要重新读取预测。 get-predictions 会先列出已标注的出现项，再列出未标注项，因此确认可重复字段组中的一行后，该行会在下次读取时成为 Occurrence 0，其余行的编号也会随之变化（IXP UI 中它也会显示在最前面）。不会丢失任何内容 — 该行仍保留自己的值和页面位置 — 但写入前读取的索引不再指向同一行。因此：在一次 --updates 调用中确认或取消确认所有目标（所有索引都按同一次读取解析）；如果必须顺序调用逐出现项操作，则在两次调用之间重新运行 get-predictions，并根据字段值重新定位每一行，绝不要使用之前看到的索引。只有完全未标注和完全已标注的文档才会按文档顺序读回。向用户报告行时应使用值（“运费附加费行”），不要使用索引。
18. 根据审核时的版本确认 — 传入 --model-version。 确认会触发重新训练，因此从 get-predictions 读取到执行 confirm 之间，预测可能发生变化。将读取结果中的 ModelVersion 作为 confirm -m <N> 传入；如果期间模型已重新训练，导致版本发生变化，确认将被拒绝（PredictionVersionChangedError），而不会把你未审核过的值盖章为真值。出现此错误时，重新读取 get-predictions、重新审核，并针对新版本确认。基于用户提供的审核进行确认（规则 14）也不例外：固定用户指定的 ModelVersion，或运行一次 get-predictions 获取该版本 — 单纯为了获取版本而读取，不等于重新审核。
19. DeploymentName ≠ DeploymentTitle，且 create 绝不会重新指向。 deployments create --title 设置自由格式的 DeploymentTitle；运行时解析的名称是 DeploymentName，它是带有每个部署专属后缀的 slug 化标题（invoices → invoices-08963f00-ixp），无法预测 — 请从创建响应或 deployments list 中读取，绝不要自行构造。create 只会新增：将现有部署重新指向其他版本，应使用 deployments upgrade <project-name> <deployment-name>，此命令接受 DeploymentName（传入 Title 会返回 404）。每次 upgrade 前都要运行 deployments list。升级会改变该文件夹和名称的所有运行时调用方所使用的模型版本 — 操作共享文件夹前先确认用户意图。参见 CLI 参考 § 部署。
20. get-metrics 默认使用最新版本，而非线上版本 — 始终注明所报告的版本。 即使项目的线上版本早已固定，训练版本仍会不断累积；最新版本的得分可能低于已部署版本 — 因此，单独运行 get-metrics 会将最新版本的数据与从 list-models 读取的线上版本身份错误地配对。先根据用户的问题确定版本 — 运行表现／生产环境：线上版本（list-models → Tags[] 中 Name=live 的版本；若没有，则使用 Models[] 中最高的 Pinned: true 版本；再否则使用最新版本）；改进说明时的基线：最新训练版本，因为你的修改会对该模型重新训练（改进提示词指南 § 1a）——然后将该版本传入 get-metrics --model-version <N>，并说明得分对应的版本。
21. 比较指标字段时使用 FieldId，报告时使用 Name。 Fields[] 包含 FieldGroup、FieldId 和 Name，因此无需读取分类体系 — 不要获取它。显示名称仅在同一组内唯一，因此两个字段名称相同时，请将对应行显示为 <FieldGroup> / <Name>。Name 是该版本中的字段名称，因此不同版本可能会以不同名称返回同一字段 — 应以 FieldId 关联不同版本，绝不要按 Name 关联，并报告当前版本的名称。参见 CLI 参考 § get-metrics。
22. 未经要求，绝不要切换项目。始终处理指定项目。 解析一次该项目的 Name，并在整个会话中保持不变，在每条命令中都传入它 — Title 可以被重命名，Name 不会（规则 7）。除非用户明确要求，否则不要在其他项目上修改或继续任务，无论它看起来与你的项目多么相似。可以读取其他项目以进行诊断；但要将任务转移到该项目，必须先获得用户明确同意。如果无法询问，请报告阻碍并停止。绝不要将其他项目的结果报告为本任务的结果。
23. 绝不要通过导入分类体系来更改分类体系 — 导入会按名称合并，因此无法重命名或删除任何内容，还会覆盖同名条目的说明。只有在项目没有分类体系时，才使用 projects import-taxonomy 为其设置与另一项目相同的分类体系。应使用 groups/fields/data-types 和 projects update-prompt 修改现有分类体系；groups delete + groups add 也不等同于替换。如果没有针对性的命令满足请求，请说明情况并将用户引导至产品内操作（不支持的功能）——绝不要改用导入，即使用户直接要求导入也不例外。完整机制见：CLI 参考 § import-taxonomy。

快速开始

1. 运行 uip ixp projects list --output json 查看现有项目
2. 创建新项目：按照项目设置指南操作
3. 改进现有项目：按照改进提示词指南操作
4. 为现有项目中的文档添加标签：按照文档标注指南操作
5. 部署模型，以便自动化程序从 Orchestrator 文件夹调用它（Maestro Flow、其他可解析文件夹的调用方）：projects create → list-models → deployments create --folder-key。无需标注或执行 publish — 参见部署指南。

如果用户提供了分类体系文件，或者希望此项目沿用另一个项目的分类体系，请使用 --skip-taxonomy 和 import-taxonomy（项目设置指南中的选项 B）。导入操作绝不会修改已有内容的分类体系（关键规则 23）。

任务导航

用户请求	操作
“创建 IXP 项目” / “将文档上传到新项目”	项目设置指南 — 仅适用于新建项目（一次调用即可上传文档并设置分类体系）。对于现有项目，请参阅下方“上传文档”一行。
“导入此分类体系” / 提供分类体系文件 / “让此项目使用与另一个项目相同的分类体系”	项目设置指南 — 选项 B（--skip-taxonomy + import-taxonomy）；如需复制，先用 projects get-taxonomy 导出源项目。目标项目的分类体系必须为空 — 在该项目上运行 projects get-taxonomy 检查；如果 label_groups 非空，则改为通过针对性的 groups/fields/data-types 调用应用更改（关键规则 23）。
“重命名 / 编辑 / 重构分类体系” / “用此文件替换分类体系” / “编辑分类体系 JSON”	仅使用针对性命令 — 下方“添加 / 删除 / 重命名”各行，以及用于整体说明的 projects update-prompt。不要使用 import-taxonomy，也不要使用 groups delete + groups add（关键规则 23）。如果没有对应的针对性命令（例如 Choice 类型的值），请说明并引导用户在产品内操作 — 参阅不支持的功能。
“标注文档” / “审核预测结果”	文档标注指南
“提高分数” / “修正提示词” / “提高 F1”	改进提示词指南
“发布模型” / “标记为 live”	uip ixp projects publish <project-name> --output json — 发布最新版本，不添加标签。添加 --tag <live|staging> 也可为其添加标签。有关 --model-version/--description，请参阅 cli-reference。发布不会将模型部署到 Orchestrator 文件夹 — 发布会固定版本，而 --tag 会移动 live/staging 标签，该标签用于选择 DU 框架所服务的版本（包括通过它调用的 DU 活动）。从 Orchestrator 文件夹解析模型的调用方（包括 Maestro Flow）只能通过 deployments create 使用模型（见下方“将此模型部署到文件夹”一行）。除非用户要求部署，否则不要在发布后接着部署 — 部署需要文件夹键，并会改变运行时调用方获取的模型。
“回滚到先前版本” / “恢复版本 N”	uip ixp projects publish <project-name> --model-version <N> --output json — 重新发布较早的版本。使用 uip ixp projects list-models <project-name> --output json 获取可用版本。
“取消发布模型” / “将模型移出生产环境”	uip ixp projects unpublish <project-name> --model-version <N> --output json — 从已发布版本集合中移除某个版本（该版本仍处于已训练/可列出状态）。必须提供 --model-version；通过 list-models（Pinned: true）查找已发布版本。要更改当前 live 版本，请改为 publish 另一个版本。
“移除 live/staging 标签” / “取消版本标签”	uip ixp projects untag <project-name> --tag <live|staging> --output json — 移除指定标签（原先指向的版本仍保持已发布状态）。untag 是唯一移除标签的方式 — 不要用 unpublish 或再次 publish 来清除标签（unpublish 移除的是发布状态，而不是标签；不带 --tag 的 publish 会保留现有标签）。要将 live 切换为 staging，请改用 publish --tag staging。
“将此模型部署到文件夹” / “使其可在运行时调用” / “部署版本 N”	uip ixp deployments create <project-name> --version <N> --folder-key <guid> [--title <title>] --output json — 将已训练版本部署到 Orchestrator 文件夹，使活动包和 Maestro Flow 可以调用。必须提供 --version（来自 projects list-models）和 --folder-key（来自 uip or folders list --output json）——如果用户只提供文件夹名称而未提供其键，请通过同一 folders list 查询名称；仅当用户完全未指定文件夹时才询问。--title 默认为去掉 -ixp 的项目名称。create 不会更改现有部署指向的版本 — 如果该文件夹中已有同一标题但版本不同的部署，会返回 409；请使用 upgrade（见下一行）。从响应中读取 DeploymentName：该名称经过 slug 化并附加了后缀，既不是标题，也不是项目名称。参阅 cli-reference § Deployments。
“将部署切换到另一个版本” / “升级已部署的模型” / “该文件夹正在提供旧版本”	uip ixp deployments upgrade <project-name> <deployment-name> --version <N> --folder-key <guid> --output json — <deployment-name> 是 deployments list 返回的 DeploymentName，不是标题（使用标题会返回 404）。这会更改该文件夹和名称的所有运行时调用方获取的版本，因此在共享文件夹上操作前请确认意图。这不是回滚方式 — 目标版本必须仍出现在 projects list-models 中。参阅 cli-reference § create vs upgrade。
“此模型部署在哪里？” / “列出部署” / “运行时使用哪个文件夹或版本”	uip ixp deployments list <project-name> --output json — 返回包含 DeploymentName、DeploymentTitle、ModelVersion、FolderKey、DeployedAt 的数组；从未部署过的项目返回 []。这是获取 DeploymentName 唯一可靠的来源 — 执行任何 upgrade 前先运行此命令。
“显示指标” / “分数是多少？”	uip ixp projects get-metrics <project-name> --model-version <N> --output json — 务必指定版本。如果没有 --model-version，CLI 会返回最新训练版本，该版本不一定是已发布/live 版本；先通过 list-models 获取 live 版本（参阅“此项目的表现如何？”）。按照关键规则 21 标明读取的字段；响应格式： CLI Reference § get-metrics。
“列出项目”	uip ixp projects list --output json
“配置模型”	uip ixp projects configure-model <project-name> [options] --output json
“此项目使用什么模型 / 预处理？” / “查询模型设置”	uip ixp projects get-taxonomy <project-name> --output json — 已配置的抽取模型和预处理设置位于 Data.dataset._model_config 中：model_version 是 --model 的值（例如 gemini_2_5_flash），input_config 必须反向映射为 none/table_mini/table 标记（null = 尚未配置，因此应报告项目默认设置——不是 none）。不存在 get-model-config，而 configure-model 是读取后再写入的操作：切勿为了查询当前设置而调用它，因为它会重写设置。不要依据 list-models 的 ModelName 作答——那是标注器系列（gemini_ixp），不是 --model 的值，也不包含预处理信息。反向映射表：CLI Reference § Reading the current model and pre-processing。
“删除项目” / “移除此项目”	uip ixp projects delete <project-name> -y --output json — 永久且不可撤销；会删除项目文档、分类体系和已训练模型。必须提供 -y/--yes（CLI 不会提示确认）。
“上传文档” / “向现有项目添加文档”	uip ixp documents upload <project-name> <file> --output json — 参阅 CLI Reference § Uploading documents。每次调用上传一个文件；有多个文件时循环调用。对于全新项目，请改用 projects create。
“删除文档” / “移除文档”	uip ixp documents delete <project-name> <document-id> -y --output json — 不可撤销，并会触发重新训练。必须提供 -y/--yes（CLI 不会提示确认）。要按文件名删除，请通过 documents list 查找 DocumentId（Filename 字段显示原始上传文件名）。
“添加 / 删除 / 重命名字段组”	uip ixp groups {add,delete,rename} <project-name> --name <name> ... --output json — 参阅 CLI Reference § Groups。groups add 必须提供 --instructions 和 --fields '<json>' — 在一次 --fields 数组调用中传入新组的所有字段（批量添加）；不要先创建组再逐个添加字段（仅对已存在的组使用 fields add）。delete 必须提供 -y/--yes（CLI 不会提示确认）。
“添加 / 编辑 / 重命名 / 删除数据类型”	uip ixp data-types {add,update-instructions,rename,delete} <project-name> --name <name> ... --output json — 参阅 CLI Reference § Data Types。add 必须提供 --kind（text/date/money/number/boolean/choice）和 --instructions。只有 --kind text 和 --kind choice 必须提供 --input-value（exact-match/inferred）；其他类型没有此属性，CLI 会拒绝这些类型使用该标记。delete 必须提供 -y/--yes（CLI 不会提示确认）；删除数据类型会导致所有引用该类型的字段失效。添加自定义数据类型前，先复用默认数据类型（关键规则 16） — 大多数需求都能映射到内置类型（例如，货币 → Monetary Quantity）。
“添加 / 删除 / 重命名 / 更改字段类型”	uip ixp fields {add,delete,rename,change-type} <project-name> --group <name> --field <name> ... --output json — 参阅 CLI Reference § Fields。delete 必须提供 -y/--yes；change-type 会删除注释，也必须提供 -y/--yes。
“将字段移到另一个组” / “此字段应归入 X”	没有移动命令 — --group 用于指定字段，但不会更改其所属组。通过 projects get-taxonomy 读取字段的 type 和 instructions，然后在目标组中运行 fields add，再运行 fields delete <source> -y。先添加再删除，这样添加失败时字段仍保留在原处。两个组必须已存在；移动字段不会创建组。不可撤销 — 重建的字段会获得新的 field_id，因此已确认的标注不会随之迁移；开始操作前请说明这一点。切勿通过 get-taxonomy → 编辑 → import-taxonomy 移动字段：导入操作会合并，因此字段最终会同时存在于两个组中。完整操作流程：CLI Reference § Moving a field。
“修正受 OCR 影响的值” / “通过更正来确认”	uip ixp labellings confirm <project-name> <document-id> --fields <ids> --corrections '[{"field_id":"<id>","value":"<fixed>"}]' --output json — 确认列出的字段，并记录受影响字段的更正值（在 --fields 中包含已更正字段的 id）。--corrections 仅适用于 OCR 错误 — 预测本来就是正确的答案且位置正确，只是识别有误（例如 MSIÓÓÓ601020/ → MSI0601020）；切勿用它来纠正错误预测，该字段应保持未标注状态（关键规则 8）。对于可重复组中的某次出现，添加 --group <name> --occurrence <N>；在批量形式 --group <name> --updates '[…]' 中，每个条目使用 "corrections": {"<field_id>": "<value>"}（以字段 id 为键的对象，而非扁平数组）。参阅 CLI Reference。
“将文档中的字段标记为缺失”	uip ixp labellings mark-missing <project-name> <document-id> --fields <ids> --output json — 将列出的字段标记为缺失；当字段确实不存在且 IXP 未为其预测任何值时使用。如果预测结果中该字段的值为空，在 labellings confirm --fields 中列出该字段也会记录相同的缺失标记。只有在 IXP 也未预测任何值时，才将字段标记为缺失 — 切勿用此操作覆盖错误预测。参阅关键规则 11。
“撤销 / 取消错误确认”	uip ixp labellings unconfirm <project-name> <document-id> --fields <ids> --output json — 撤销此前对所列字段执行的 confirm 或 mark-missing（confirm 无法撤销确认 — 关键规则 13）。文档上的其他所有标注都会保留。如果只使用 --fields，可重复组中跨多个出现项共用的字段 id 会从所有出现项中移除；要撤销特定出现项，请添加 --group 和 --occurrence <N>，或使用 --updates '[…]'（与 confirm 相同 — 参阅下一行和关键规则 13）。
“确认一条明细 / 一次抽取” / “只确认这次出现”	uip ixp labellings confirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json — 针对可重复字段组中的某次特定抽取（基于最新一次 get-predictions 的从 0 开始索引）。如果不提供 --fields，则确认该出现项中的所有预测字段；提供后则只确认所列字段。其他出现项不受影响。确认后，下次读取时该组会重新编号（已确认的行会移到 Occurrence 0）——因此，应通过一次 --updates '[…]' 调用批量处理多个出现项，而不要基于同一次读取结果连续调用 --occurrence。参阅关键规则 12 和 17。
“取消确认一条明细 / 一次抽取” / “只撤销这次出现”	uip ixp labellings unconfirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json — 撤销对可重复字段组中某次特定抽取的确认（从 0 开始索引，与 get-predictions/confirm 相同）。如果不提供 --fields，则取消确认该出现项中的所有已标注字段；提供后则只取消确认所列字段。其他出现项不受影响。先重新读取 get-predictions — 对于部分已确认的组，已确认的行会排在前面，因此用于确认某一行的索引通常与用于撤销该行确认的索引不同（关键规则 17）。一次调用处理多个出现项时，请改用 --updates '[…]'。参阅关键规则 13。
“设置整体抽取说明” / “更新项目提示词”	uip ixp projects update-prompt <project-name> --prompt "<text>" --output json — 替换整个分类体系的提示词（IXP UI 中的“整体抽取说明”字段）。这不同于 fields update-prompts（针对单个字段）和 groups update-prompts（针对单个字段组）。
“此项目的表现如何？” / “F1 是多少？”	使用 uip ixp projects list-models <project-name> --output json 确定 live 版本，然后运行 uip ixp projects get-metrics <project-name> --model-version <live-version> --output json（关键规则 20）。如果 Data 为 { Metrics: null }，说明模型尚未通过验证——报告这一情况并停止。如果调用返回的是 Result: Failure 且 ErrorCode: not_found（项目尚无已训练模型，例如没有已确认的标注），也按相同方式处理——报告“暂无指标”并停止。否则，Data 为扁平结构；按以下顺序报告：(1) 分数对应的版本及 TrainedTime；(2) 整体 ProjectScore/ProjectScoreQuality；(3) 各组在 FieldGroups[] 中的分数（F1/Precision/Recall）；(4) Fields[] 中按 F1 从低到高排列的各字段分数 — F1 及其 Precision/Recall（F1 低时应采取哪种修正措施，取决于哪一项偏低），以及 Annotations（F1 所依据的样本量）和 ErrorRate（= 错误数/Annotations — 它统计的是漏检，因此不等于 1 - Precision）。忽略 Quality 标签（它们是派生值，且尺度不一致 — 参阅改进提示词指南 § What get-metrics returns）。仅依据 Fields[] 中的字段进行列举和比较（关键规则 21）。直接说明数值；除非用户询问，否则不要评价“表现是否足够好”；分数较低时，引导用户参阅改进提示词指南。仅依据这些调用作答——不要临时进行其他查询（关键规则 #1）。
“描述此项目” / “项目里有什么？”	调用三次，并按顺序报告：(1) 项目信息 — 使用 uip ixp projects get <project-name> --output json 获取 Title/Name；(2) 当前模型版本 — 从 list-models 获取 live/已发布版本及 TrainedTime（已训练的版本，而非已配置的抽取模型——后者请参阅上方对应行）；(3) 分类体系 — 使用 uip ixp projects get-taxonomy <project-name> --output json 获取字段组/字段数量（原始数据中位于 Data.dataset.label_groups 和 Data.dataset.entity_defs，使用 snake_case 命名）。只有用户询问时才补充性能信息（见上方）。不要翻页查询 documents list（其 Data 是分页封装 { Documents, Total, Offset, Limit } — 使用 Total 统计数量），也不要读取部署绑定。仅依据这些调用作答（关键规则 #1）。

常见问题

症状	原因	解决方法
报告的分数与 IXP UI 的构建页面显示的不一致	调用 get-metrics 时未传入 --model-version，因此返回的是最新训练的版本，而 UI（或你自己的句子）指的是线上运行的版本	从 list-models 获取版本，然后重新运行 get-metrics --model-version <N>。如果某个项目的线上版本很久以前就已固定，可能已经有许多更新的训练版本，而最新版本的分数可能更低。参见关键规则 20。
更新提示词后指标没有变化	重新评估尚未完成	等待重新训练完成 — 改进提示词指南 § 等待重新训练。
ModelVersion 没有递增	重新训练仍在进行中	对模型输入（标注或指令）的任何更改都会触发完整重新训练。请按照改进提示词指南 § 等待重新训练中的有上限等待方式重新读取指标 — 固定间隔、限制检查次数，然后停止。切勿无限轮询。
编辑 taxonomy 后留下了重复项，或者尽管返回 {"status":"ok"}，重命名或移除操作仍未生效	重新导入了手动编辑的 get-taxonomy 转储 — 导入操作会合并	重新导入无法撤销这些更改。读取 projects get-taxonomy，用 fields/groups/data-types delete -y 删除每个重复项，然后使用针对性命令重新进行更改。同时检查你原本不打算修改的条目：同名字段或组会从文件中获取其指令和数据类型。重复字段上已确认的标签不会合并回来 — 请明确说明这一点（关键规则 23）。
字段指令与 label_def 指令冲突	fields update-prompts 只会编辑每个字段的指令，不会编辑父级 label_def 指令	开始迭代前，读取 label_def 的 instructions；如果与每个字段的提示词矛盾，请使用 groups update-prompts 更新。
已确认的行项目现在显示为第一行，或者其他行的 Occurrence 编号发生了变化	这是预期行为：读取结果会先返回标注↔预测的匹配对，因此已确认的行会排在未确认行之前	无需修复 — 值和页面位置均未改变。下次按出现次数操作前，重新运行 get-predictions，并根据行的值确定目标行（关键规则 17）。
第二次 --occurrence 调用作用到了错误的行，或者 unconfirm --occurrence N 没有任何效果	索引取自先前的读取结果，而更早的一次确认操作已对组内条目重新编号	在逐个出现次数写入之间重新读取 get-predictions，或者将这些操作合并为一次 --updates 调用。
deployments create 返回 409	该文件夹中已部署了使用不同版本的同名标题 — create 只会新增	改用 deployments upgrade <project-name> <deployment-name>，其中 <deployment-name> 从 deployments list 获取（关键规则 #19）。
deployments upgrade 返回 404	传入了 DeploymentTitle，但此处需要 DeploymentName — 名称会转换为 slug 并附加后缀（invoices → invoices-08963f00-ixp），因此无法根据标题推导	运行 deployments list <project-name> --output json，并原样传入其中的 DeploymentName。

不支持的功能

这些请求超出了此技能的范围。识别请求，回复标准答复，并引导用户。切勿进入发现流程（uip --help、grep、读取源代码）——请参阅关键规则 #1。

用户请求	标准答复
“创建模型”／“创建项目”	提供了文档或分类体系，或要求创建空白项目 → 使用项目设置指南（此技能可创建项目）。否则 → “我处理的是现有 IXP 项目，而不是从零开始创建项目。请在产品中创建项目：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — 之后我可以为其添加标签、进行审核并加以改进。”
“上传这些文件”／“添加文档”	已指定项目名称／项目已在上下文中 → 支持；上传文件（请参阅任务导航中的“上传文档”一行）。否则 → “请提供现有项目的名称，我会为其上传文件；也可以在产品中上传（例如，为新项目上传）：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models。”
“推送到某个环境／其他租户”／“部署到预发布或生产环境”	指定了 Orchestrator 文件夹（文件夹名称确实为 Production）→ 支持；使用任务导航中的“将此模型部署到文件夹”一行。否则 → “IXP 没有环境或跨租户部署目标——一次部署是在单个租户中的一个（文件夹，版本）组合。”请注意，projects publish --tag staging|live 会移动 DU 框架（以及通过该框架调用的 DU 活动）解析的标签——对于这些使用者而言，这就是预发布／生产环境切换；此操作不会创建文件夹部署。
“授予 X 访问权限”／“共享此项目”／“更改角色或权限”	“访问权限、角色和权限由产品内管理，而非通过此技能管理：https://docs.uipath.com/ixp/automation-cloud/latest/overview/managing-access。”
“在我的自动化／工作流／Agent 中使用此模型”／“从某个流程调用提取器”	“在自动化中使用已发布的模型属于创作任务，超出此技能范围。请参阅 https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-consuming-a-workflow。”
“挖掘这些电子邮件／通信内容”／“设置 Communications Mining”	“Communications Mining 是 IXP 的独立功能，此技能不涉及（此技能用于文档提取）。请参阅 https://docs.uipath.com/ixp/automation-cloud/latest/cm-user-guide/introduction-to-uipath-communication-mining。”
“监控已部署的模型”／“它处理了多少份文档？”／“运行时吞吐量或事故”	“已部署模型的运行时／运维监控在 Orchestrator 中进行，不属于此技能：https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/about-monitoring。设计时评分请使用 get-metrics（参见‘显示指标’）。”
“替换／覆盖分类体系”／“将此文件导入现有分类体系并覆盖”	“IXP 不支持替换分类体系——导入到现有分类体系会与其合并并产生重复项。我可以使用针对性的命令逐一应用差异；如果你希望获得干净的分类体系，也可以将文件导入一个新项目（现有项目的文档和标签会保留原样）。”接着列出你将应用的差异，让用户选择。
“编辑数据类型的值”／“添加或移除一个 Choice 选项”	“CLI 可以重命名数据类型、更改其说明（data-types update-instructions）或删除数据类型，但不能添加或移除现有 Choice 数据类型的值。请在产品的‘管理分类体系’页面手动操作：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — 然后继续在此处操作。”
“此项目有哪些验证规则？”／“添加业务规则”	“CLI 无法读取或更新验证（业务）规则。请在产品的‘管理分类体系’页面手动查看或编辑，然后继续在此处操作。”

参考导航

• CLI 命令参考 — 所有 uip ixp 命令及其选项和输出格式
• 项目设置指南 — 创建新项目、审核并标注文档
• 提示词改进指南 — 带回归检测的迭代优化循环
• 文档标注指南 — 用于审核和确认预测的可复用工作流
• 部署指南 — 发布一个版本，或将其部署到 Orchestrator 文件夹，供运行时调用方使用