uipath-ixp

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UiPath IXP Document Extraction Assistant

UiPath IXP 文档提取助手

Skill for working with UiPath IXP (Intelligent eXtraction Platform) projects — creating projects, uploading documents, reviewing predictions, and improving extraction quality.

用于处理UiPath IXP（Intelligent eXtraction Platform）项目的技能——包括创建项目、上传文档、审核预测结果以及提升提取质量。

When to Use This Skill

何时使用本技能

User asks to create an IXP project, upload documents, or train a document extraction model
User asks to label, review, or confirm document predictions
User asks to improve extraction scores, prompts, or field instructions
User asks to publish or manage IXP model versions
User asks to deploy a trained model version to an Orchestrator folder, move a deployment to another version, or list where a project is deployed (
```
deployments create
```
/
```
upgrade
```
/
```
list
```
)
User provides a taxonomy file to import into a project
User asks for the project taxonomy at a specific trained model version — what the schema looked like when version N was published (use
```
deployments get-taxonomy <project-name> --version <N>
```
)

用户要求创建IXP项目、上传文档或训练文档提取模型
用户要求标记、审核或确认文档预测结果
用户要求提升提取分数、提示词或字段指令
用户要求发布或管理IXP模型版本
用户要求将训练好的模型版本部署到Orchestrator文件夹、将现有部署迁移到其他版本，或列出项目的部署位置（
```
deployments create
```
/
```
upgrade
```
/
```
list
```
）
用户提供分类文件并要求导入到项目中
用户要求查看特定训练模型版本下的项目分类体系——即版本N发布时的架构（使用
```
deployments get-taxonomy <project-name> --version <N>
```
）

When NOT to Use This Skill — defer to uipath-maestro-flow

何时不使用本技能——转用uipath-maestro-flow

This skill covers standalone IXP-project work. STOP and invoke the

uipath-maestro-flow

skill instead when any of these hold:

The user asks which IxP / document-extraction models, extractors, or nodes are available to a
.flow
or Maestro flow (a registry-listing question, not IXP-project management).
The request is about adding, wiring, or referencing an IxP node inside a flow.
The working context is a
```
.flow
```
file or a Maestro flow rather than a standalone IXP project.

Do not answer these from this skill. Re-activate

uipath-maestro-flow

and follow the commands it documents. This overrides Critical Rule 1.

本技能适用于独立的IXP项目工作。当出现以下任一情况时，请停止使用本技能，转而调用

uipath-maestro-flow

技能：

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

请勿通过本技能回答上述问题。重新激活

uipath-maestro-flow

并遵循其文档中的指令。此规则优先于关键规则1。

Critical Rules

关键规则

Verify
uip ixp
syntax before running a command — use a targeted lookup in CLI Reference and copy the exact subcommand and options; never guess. If the request is not covered, report that the skill has no documented CLI path rather than improvising. Do NOT use curl, call REST APIs directly, or explore source code. (Exception: defer flow/Maestro registry questions to
```
uipath-maestro-flow
```
— see When NOT to Use This Skill above.)
Run workflows end-to-end automatically — do NOT ask the user to do individual steps.
Always use
--output json
when parsing CLI output programmatically.

Use
/tmp/ixp/<project-name>/
as the working directory with this structure:

/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 payloads (field_updates.json, group_updates.json, …)

At the start of any workflow:

mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}

. If the directory already exists from a previous session, reuse existing files — do not re-download documents that are already present. Do NOT use the Write tool for

/tmp/ixp/

paths — on Windows it resolves to a different location than bash.

Use heredocs for
--updates
— for

fields update-prompts --updates

and

groups update-prompts --updates

, use heredocs (

cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF

) then

"$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)"

Never use
UID
as a variable name — it is a readonly shell variable. Use
```
DOC_ID
```
,
```
DOCUMENT_ID
```
, etc.
Always use the project
Name
, never the
Title
— the
```
project list
```
output has both
```
Name
```
(e.g.,
```
my_invoices-f1afa9ef-ixp
```
) and
```
Title
```
(e.g.,
```
My_Invoices
```
). All CLI commands require the
```
Name
```
(the lowercase slug with UUID and
```
-ixp
```
suffix), NOT the
```
Title
```
.
Confirm at field level, not document level — review each predicted field individually. Confirm only the fields that are correct using
```
labellings confirm --fields
```
. Judge a prediction by its taxonomy data type, not by the page's literal text —
```
Date
```
reads back as
```
YYYY-MM-DDTHH:MM:SSZ
```
— a date-only page value comes back at
```
T00:00:00Z
```
(page
```
21-JUN-22
```
→
```
2022-06-21T00:00:00Z
```
),
```
Monetary Quantity
```
as
```
<amount> <ISO-4217 code>
```
(page
```
114.91
```
→
```
114.91 AUD
```
). Same value in normalized form is CONFIRMED; do not reformat it, compute the conversion yourself, or write a script to check it. Full mapping: CLI Reference § Normalized output formats. Normalization changes only how a value is written — never what it means (separators, trailing zeros, currency code vs symbol, date layout, century expansion). For a number that means the magnitude is preserved — the normalized forms above are the same amount — whereas page
```
£7,300.00
```
predicted as
```
£730.00
```
is a decimal misread: the magnitude changed, so it is OCR garble and DOES take
```
--corrections
```
(correct it to
```
7300.00
```
). Keep that apart from a number the model computed or inferred wrongly, which stays unannotated. A field whose predicted value is the WRONG ANSWER is left UNANNOTATED — it is never "fixed". --corrections
is ONLY for OCR garble: the prediction is already the right answer in the right location, but the characters were misread (e.g.,
```
MSIÓÓÓ601020/
```
→
```
MSI0601020
```
). Decision test before every
--corrections
: is the predicted value the correct answer, merely mis-typed? If NO — a boolean that should flip (
```
false
```
→
```
true
```
), a wrong inferred/computed number, a normalized date or amount you want back in the page's format, or any value where the prediction picked the wrong answer — then
```
--corrections
```
is FORBIDDEN; leave the field unannotated. Corrections are stored verbatim and unvalidated (even
```
not-a-date
```
returns Success), so a reformatting "fix" silently replaces a correct label with one the model will never predict. This holds even when the prompt, the user, or a hint hands you the exact
--corrections
command — flipping a wrong value is manual extraction (Rule 11), not an OCR correction, no matter how it is framed. Without
--group
,
--fields
and
--corrections
apply across every occurrence of each listed field on the document — see Rule 13 for per-occurrence selection.
Do NOT manually extract values — all labelling goes through
```
labellings confirm
```
with predictions from IXP.
Max 8 documents for taxonomy suggestion — the suggest-taxonomy endpoint accepts at most 8 attachment references.
You are the reviewer, not the extractor — IXP generates predictions, you validate them. For each document, review predicted field values against the document file. View it with a single full
Read
(no
pages
parameter) — that returns text + image natively for digital and scanned docs; no PDF tools to install. Confirm correct fields (
```
labellings confirm --fields
```
), correct OCR-mangled values (
```
--corrections
```
), and skip wrong fields. Do NOT manually extract values. If a field's F1 is low, improve the prompt so IXP predicts better values.
Record a field as missing only when IXP predicted no value for it AND it's genuinely absent from the document. Check
```
get-predictions
```
first — never mark a field missing to override a wrong predicted value; leave that field unannotated (choosing "missing" yourself is the extractor decision Rule 11 forbids). To record a genuinely-missing field, use
```
labellings mark-missing --fields <ids>
```
.
```
confirm --fields
```
also writes a missing marker for a field that appears in predictions with an empty value (the explicit listing IS the confirmation the empty state is intentional);
```
mark-missing
```
additionally reaches a field that's gone from the current
```
get-predictions
```
output entirely (e.g. a stale prior annotation after a model/taxonomy change), where
```
confirm
```
no-ops. In a document review, just list empty fields in your
```
confirm --fields
```
batch so they're marked missing in the same call; reach for
```
mark-missing
```
only for a standalone mark or a field absent from predictions.
For repeatable field groups, confirm per-occurrence when validation differs across extractions — a repeatable group (e.g.
```
Line Items
```
) produces one extraction per physical line/section. Plain
```
confirm --fields <id>
```
confirms
```
<id>
```
in every occurrence, so if only some lines are correct it confirms the wrong ones too. Each label in
```
get-predictions
```
carries an explicit 0-based
```
Occurrence
```
— an index into that read, not a stable row id (Rule 18); if all occurrences are correct use the plain form, otherwise target with
```
--group
```
.
```
--group <name> --occurrence <N>
```
confirms ONE occurrence;
```
--group <name> --updates '[...]'
```
confirms SEVERAL in one atomic call (avoids N round-trips) —
```
--occurrence <N>
```
≡ a single-entry
```
--updates
```
, same per-occurrence logic.
```
--group
```
must be the FULL label path from the
```
Name
```
field (e.g.
```
"Invoice > Line Items"
```
), not the leaf. Without
```
--fields
```
, every predicted field in the occurrence is confirmed; with it, only those. Occurrences not selected keep their existing annotation. Flag details: CLI Reference.
confirm
is additive — it never un-confirms. The labelling endpoint is full-replacement, so
```
confirm
```
/
```
mark-missing
```
carry every existing annotation forward:
```
--occurrence 0
```
on an already-labelled table yields "row 0 confirmed AND everything previously confirmed stays confirmed" — NOT "only row 0". To roll back a confirmation, use
```
unconfirm
```
(see the task-navigation table).
F1 reflects confirmed labels, not document truth — never blind-confirm. F1/
```
ProjectScore
```
measure prediction-vs-confirmed-label agreement, so a wrong value you confirm becomes the "right" answer and scores 1.00. A perfect score is not evidence the values are correct. Before confirming, sanity-check each value against the document. The per-document no-
```
--fields
```
form (confirm all predicted fields on one document) is fine once you've reviewed them all. If the user explicitly says every predicted field in named documents was reviewed and is correct, accept that review and confirm those documents without re-reviewing them field by field (still pin the version — Rule 19). Never run
```
confirm
```
without a document-id — that confirms every document at once, bypassing review. See Label Documents Guide §2c.
Ambiguous entity reference → ask, never guess. Projects (Titles), field groups, fields, and data types share one namespace in user speech ("rename subscriptions"). Before any mutation (
```
update-title
```
,
```
rename
```
,
```
delete
```
,
```
change-type
```
), resolve which entity KIND the user means. If the name matches more than one kind — in the user's own context or in
```
projects list
```
/ taxonomy output — STOP and ask which one, explicitly listing every matching candidate and its kind. Do NOT pick one, and do NOT mutate several candidates "to cover all cases". When the user can't be asked interactively, surface the question through whatever channel the task provides and stop.
Reuse the built-in data types before adding new ones. Every IXP project ships with default data types —
```
Exact Text
```
,
```
Inferred Text
```
,
```
Number
```
,
```
Date
```
,
```
Monetary Quantity
```
,
```
Boolean
```
(the project's
```
entity_defs
```
from
```
projects get-taxonomy
```
are the authoritative list). Before
```
data-types add
```
or picking a field's
```
--type
```
, reuse a matching default — e.g.
```
Monetary Quantity
```
for a currency amount, never a hand-rolled clone (
```
Currency Amount
```
). Add a new type only when no default covers it: a project-specific
```
Choice
```
, or a concept needing its own tailored extraction instructions. Never add one just to reformat — the pre-trained defaults keep their fixed output format regardless of instructions. Mapping: CLI Reference § Default data types.
Occurrence
is scoped to the read that produced it — re-read predictions after every per-occurrence write. The server pairs annotations with predictions and returns matched pairs first, so confirming one row of a repeatable group moves that row to
```
Occurrence
```
0 on the next read and renumbers the rest (the IXP UI shows it first too). Nothing is lost — the row keeps its own values and page location — but the indices you read before the write no longer identify the same rows. So: confirm/unconfirm every target in ONE
```
--updates
```
call (all its indices resolve against the same read), and when sequential per-occurrence calls are unavoidable, re-run
```
get-predictions
```
between them and re-locate each row by its field values, never by the index you saw earlier. Only fully-unannotated and fully-annotated documents read back in document order. Report rows to the user by value ("the freight-surcharge line"), not by index.
Confirm against the version you reviewed — pass
--model-version
. Confirming triggers a retrain, so predictions can drift between your
```
get-predictions
```
read and your
```
confirm
```
. Pass the read's
```
ModelVersion
```
as
```
confirm -m <N>
```
; if a retrain changed the version since, the confirm is rejected (
```
PredictionVersionChangedError
```
) rather than stamping values you never reviewed as ground truth. On that error, re-read
```
get-predictions
```
, re-review, and confirm against the new version. Confirming on a user-supplied review (Rule 15) is no exemption: pin the
```
ModelVersion
```
the user names, or run one
```
get-predictions
```
to capture it — a read for the version alone is not a re-review.
DeploymentName
≠
DeploymentTitle
, and
create
never repoints.
```
deployments create --title
```
sets a free-form
```
DeploymentTitle
```
; the name the runtime resolves is
```
DeploymentName
```
, which the backend slugs and suffixes per deployment (
```
invoices
```
→
```
invoices-08963f00-ixp
```
) and which cannot be predicted from the request — read it off the create response or
```
deployments list
```
, never construct it.
```
create
```
only ever ADDS: repointing an existing deployment to another version is
```
deployments upgrade <project-name> <deployment-name>
```
, which takes
```
DeploymentName
```
(passing a title there is a
```
404
```
). Run
```
deployments list
```
before every
```
upgrade
```
. Upgrading changes which model version every runtime caller of that folder and name gets — confirm intent before touching a shared folder. See CLI Reference § Deployments.

运行命令前验证
uip ixp
语法——在CLI参考文档中进行针对性查询，复制准确的子命令和选项；切勿猜测。如果请求未被覆盖，请告知用户本技能没有记录的CLI路径，而非自行发挥。请勿使用curl、直接调用REST API或查看源代码。（例外：将流程/Maestro注册表问题转交给
```
uipath-maestro-flow
```
——请参阅上文“何时不使用本技能”部分。）
自动端到端运行工作流——请勿要求用户执行单个步骤。
以编程方式解析CLI输出时始终使用
--output json

使用
/tmp/ixp/<project-name>/
作为工作目录，遵循以下结构：

/tmp/ixp/<project-name>/
├── docs/         # 文档文件（<document-id>.pdf、.png等）——下载一次后在会话间复用
├── taxonomies/   # 分类体系快照（v1.json、v2.json等）——每次更新提示词后生成新版本
└── prompts/      # 指令更新负载（field_updates.json、group_updates.json等）

在任何工作流开始时执行：

mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}

。如果该目录在之前的会话中已存在，请复用现有文件——不要重新下载已存在的文档。请勿对

/tmp/ixp/

路径使用写入工具——在Windows系统中，该路径的解析结果与bash不同。

对
--updates
使用here文档——对于

fields update-prompts --updates

和

groups update-prompts --updates

，使用here文档（

cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF

），然后使用

"$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)"

。

切勿使用
UID
作为变量名——它是只读的shell变量。请使用
```
DOC_ID
```
、
```
DOCUMENT_ID
```
等。
始终使用项目的
Name
，而非
Title
——
```
project list
```
输出同时包含
```
Name
```
（例如
```
my_invoices-f1afa9ef-ixp
```
）和
```
Title
```
（例如
```
My_Invoices
```
）。所有CLI命令都需要
```
Name
```
（包含UUID和
```
-ixp
```
后缀的小写短名称），而非
```
Title
```
。
在字段级别进行确认，而非文档级别——逐个审核每个预测字段。仅使用
```
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
```
也会返回成功），因此重新格式化的“修正”会无声地将正确标签替换为模型永远无法预测的内容。即使提示词、用户或提示信息提供了确切的
```
--corrections
```
命令，此规则依然适用——翻转错误值属于手动提取（规则11），而非OCR修正，无论其表述方式如何。如果不使用
--group
，
--fields
和
--corrections
会应用于文档中每个列出字段的所有实例——请参阅规则13了解如何选择特定实例。
请勿手动提取值——所有标记操作都应通过
```
labellings confirm
```
结合IXP生成的预测结果完成。
分类建议最多支持8个文档——suggest-taxonomy端点最多接受8个附件引用。
你是审核者，而非提取者——IXP生成预测结果，你负责验证它们。对于每个文档，请对照文档文件审核预测字段值。使用完整的
Read
操作查看文档（不要使用
pages
参数）——该操作会原生返回数字文档和扫描文档的文本+图像；无需安装PDF工具。确认正确的字段（
```
labellings confirm --fields
```
）、修正OCR识别错误的值（
```
--corrections
```
），并跳过错误的字段。请勿手动提取值。如果某个字段的F1分数较低，请优化提示词以让IXP生成更准确的预测结果。
仅当IXP未预测到值且该字段确实在文档中缺失时，才标记字段为缺失。请先检查
```
get-predictions
```
的结果——永远不要通过标记字段为缺失来覆盖错误的预测值；请保持该字段未注释（规则11禁止自行决定提取内容）。要标记确实缺失的字段，请使用
```
labellings mark-missing --fields <ids>
```
。当字段在预测结果中显示为空值时，
```
confirm --fields
```
也会为该字段标记缺失状态（显式列出字段即确认空状态是有意的）；
```
mark-missing
```
还可用于处理当前
```
get-predictions
```
输出中完全不存在的字段（例如模型/分类体系变更后过时的旧注释），此时
```
confirm
```
不会执行任何操作。在文档审核中，只需将空字段包含在
```
confirm --fields
```
的批量操作中，即可在同一调用中标记其为缺失；仅在单独标记或字段未出现在预测结果中时，才使用
```
mark-missing
```
。
对于可重复字段组，当不同提取实例的验证结果不同时，请针对单个实例进行确认——可重复组（例如
```
Line Items
```
）会为每个实际行/部分生成一个提取结果。简单的
```
confirm --fields <id>
```
会确认所有实例中的
```
<id>
```
字段，因此如果只有部分行正确，会错误地确认其他行。
```
get-predictions
```
中的每个标签都带有明确的0-based
```
Occurrence
```
索引——该索引针对本次读取，而非稳定的行ID（规则18）；如果所有实例都正确，可以使用简单形式，否则请使用
```
--group
```
进行定位。
```
--group <name> --occurrence <N>
```
会确认一个实例；
```
--group <name> --updates '[...]'
```
会在一次原子调用中确认多个实例（避免N次往返）——
```
--occurrence <N>
```
等效于单条记录的
```
--updates
```
，遵循相同的实例级逻辑。
```
--group
```
必须是
```
Name
```
字段中的完整标签路径（例如
```
"Invoice > Line Items"
```
），而非叶子节点。如果不使用
```
--fields
```
，会确认该实例中的所有预测字段；如果使用
```
--fields
```
，则仅确认指定字段。未被选中的实例会保留其现有注释。详细标记规则请参阅：CLI参考文档。
confirm
是累加操作——永远不会取消确认。标记端点采用完全替换机制，因此
```
confirm
```
/
```
mark-missing
```
会保留所有现有注释：对已标记的表格执行
```
--occurrence 0
```
会得到“第0行已确认，且之前所有已确认的内容仍保持确认状态”——而非“仅确认第0行”。要回滚确认操作，请使用
```
unconfirm
```
（请参阅任务导航表）。
F1分数反映的是已确认标签，而非文档真实情况——切勿盲目确认。F1/
```
ProjectScore
```
衡量的是预测结果与已确认标签的一致性，因此你确认的错误值会成为“正确”答案并获得1.00分。完美分数不代表值是正确的。确认前，请对照文档检查每个值的合理性。在审核完所有字段后，可以使用不带
```
--fields
```
的单文档形式（确认单个文档上的所有预测字段）。如果用户明确表示指定文档中的所有预测字段已审核且正确，可以接受该审核结果并确认这些文档，无需逐字段重新审核（但仍需固定版本——规则19）。切勿在不指定document-id的情况下运行
```
confirm
```
——这会一次性确认所有文档，跳过审核步骤。请参阅标记文档指南§2c。
实体引用模糊时——询问用户，切勿猜测。项目（Title）、字段组、字段和数据类型在用户表述中共享同一命名空间（例如“重命名订阅”）。在执行任何变更操作（
```
update-title
```
、
```
rename
```
、
```
delete
```
、
```
change-type
```
）之前，请明确用户所指的实体类型。如果名称匹配多种类型——无论是在用户的上下文还是
```
projects list
```
/分类体系输出中——请停止操作并询问用户，明确列出每个匹配的候选对象及其类型。切勿自行选择，也不要同时变更多个候选对象以“覆盖所有情况”。当无法与用户交互时，请通过任务提供的渠道提出问题并停止操作。
添加新数据类型前，请先复用内置数据类型。每个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参考文档 § 默认数据类型。
Occurrence
的作用域为生成它的读取操作——每次针对实例的写入操作后，请重新读取预测结果。服务器会将注释与预测结果配对，并优先返回匹配对，因此确认可重复组中的某一行后，该行会在下次读取时变为
```
Occurrence
```
0，并重新编号其他行（IXP UI也会将其显示在首位）。数据不会丢失——该行会保留其值和页面位置——但写入操作前读取的索引将不再指向同一行。因此：请在一次
```
--updates
```
调用中确认/取消确认所有目标（所有索引都针对同一读取操作）；当无法避免连续的实例级调用时，请在调用之间重新运行
```
get-predictions
```
，并通过字段值重新定位每行，而非使用之前看到的索引。只有完全未注释和完全注释的文档会按文档顺序返回。请通过值向用户报告行（例如“运费附加费行”），而非索引。
针对你审核的版本进行确认——传递
--model-version
。确认操作会触发重新训练，因此在你执行
```
get-predictions
```
读取和
```
confirm
```
确认之间，预测结果可能会发生变化。请将读取操作得到的
```
ModelVersion
```
作为
```
confirm -m <N>
```
传递；如果在此期间重新训练改变了版本，确认操作会被拒绝（
```
PredictionVersionChangedError
```
），而非将你未审核的值标记为基准真值。遇到该错误时，请重新读取
```
get-predictions
```
、重新审核，并针对新版本进行确认。即使是用户提供的审核结果（规则15）也不例外：固定用户指定的
```
ModelVersion
```
，或运行一次
```
get-predictions
```
以获取该版本——仅读取版本不属于重新审核。
DeploymentName
≠
DeploymentTitle
，且
create
操作永远不会重新指向。
```
deployments create --title
```
会设置自由格式的
```
DeploymentTitle
```
；运行时解析的名称是
```
DeploymentName
```
，由后端根据部署生成短名称并添加后缀（例如
```
invoices
```
→
```
invoices-08963f00-ixp
```
），且无法根据请求预测——请从创建响应或
```
deployments list
```
中读取该名称，切勿自行构造。
```
create
```
操作仅用于添加部署：将现有部署重新指向其他版本需使用
```
deployments upgrade <project-name> <deployment-name>
```
，该命令需要
```
DeploymentName
```
（在此处传递title会返回
```
404
```
）。每次执行
```
upgrade
```
前，请先运行
```
deployments list
```
。升级操作会更改该文件夹和名称下所有运行时调用者获取的模型版本——在修改共享文件夹前，请确认用户意图。请参阅CLI参考文档 § 部署。

Quick Start

快速入门

Run
```
uip ixp projects list --output json
```
to see existing projects
To create a new project: follow Project Setup Guide
To improve an existing project: follow Improve Prompts Guide
To label documents on an existing project: follow Label Documents Guide

If the user provides a taxonomy file, use

--skip-taxonomy

and

import-taxonomy

(Option B in the Project Setup guide).

运行
```
uip ixp projects list --output json
```
查看现有项目
创建新项目：遵循项目设置指南
优化现有项目：遵循提示词优化指南
为现有项目标记文档：遵循标记文档指南

如果用户提供分类文件，请使用

--skip-taxonomy

和

import-taxonomy

（项目设置指南中的选项B）。

Task Navigation

任务导航

User request	Action
"Create an IXP project" / "Upload documents to a new project"	Project Setup Guide — new projects only (uploads + taxonomy in one call). For existing projects, see the "Upload a document" row below.
"Import this taxonomy" / provides a taxonomy file	Project Setup Guide — Option B ( `--skip-taxonomy` + `import-taxonomy` )
"Label documents" / "Review predictions"	Label Documents Guide
"Improve scores" / "Fix prompts" / "Improve F1"	Improve Prompts Guide
"Publish the model" / "Tag as live"	`uip ixp projects publish <project-name> --output json` — publishes the latest version, untagged. Add `--tag <live\|staging>` to also tag it. See cli-reference for `--model-version` / `--description` . Publishing does not deploy the model to an Orchestrator folder — publishing makes the version usable inside the project; `deployments create` (see the "Deploy this model to a folder" row below) is what makes it callable at runtime by activity packs and Maestro Flow. Do NOT chain a deploy onto a publish unless the user asked to deploy — a deploy needs a folder key and changes what runtime callers get.
"Roll back to a previous version" / "Restore version N"	`uip ixp projects publish <project-name> --model-version <N> --output json` — re-publishes an earlier version. Get available versions from `uip ixp projects list-models <project-name> --output json` .
"Unpublish a model" / "Take a model out of production"	`uip ixp projects unpublish <project-name> --model-version <N> --output json` — removes a version from the published set (it stays trained/listable). `--model-version` is required; find published versions via `list-models` ( `Pinned: true` ). To change which version is live, `publish` a different one instead.
"Remove the live/staging tag" / "Untag a version"	`uip ixp projects untag <project-name> --tag <live\|staging> --output json` — removes the named tag (the version it pointed at stays published). `untag` is the only way to remove a tag — do NOT `unpublish` or re- `publish` to clear it ( `unpublish` removes publication, not the tag; `publish` without `--tag` leaves the existing tag untouched). To switch `live` → `staging` , `publish --tag staging` instead.
"Deploy this model to a folder" / "make it callable at runtime" / "deploy version N"	`uip ixp deployments create <project-name> --version <N> --folder-key <guid> [--title <title>] --output json` — deploys a trained version to an Orchestrator folder, making it callable by activity packs and Maestro Flow. `--version` (from `projects list-models` ) and `--folder-key` (from `uip or folders list --output json` ) are both required; `--title` defaults to the project name minus `-ixp` . `create` never repoints an existing deployment — a title already deployed in that folder on a different version is a `409` ; use `upgrade` (next row). Read `DeploymentName` off the response: it is slugged and suffixed, never the title or the project name. See cli-reference § Deployments.
"Move a deployment to another version" / "upgrade the deployed model" / "that folder is serving an old version"	`uip ixp deployments upgrade <project-name> <deployment-name> --version <N> --folder-key <guid> --output json` — `<deployment-name>` is the `DeploymentName` from `deployments list` , not the title (a title there is a `404` ). Changes which version every runtime caller of that folder and name gets, so confirm intent on a shared folder. Not a rollback path — the target version must still appear in `projects list-models` . See cli-reference § create vs upgrade.
"Where is this model deployed?" / "list deployments" / "which folder or version is live at runtime"	`uip ixp deployments list <project-name> --output json` — array of `DeploymentName` , `DeploymentTitle` , `ModelVersion` , `FolderKey` , `DeployedAt` ; `[]` for a never-deployed project. The only reliable source of `DeploymentName` — run it before any `upgrade` .
"Show metrics" / "What are the scores?"	`uip ixp projects get-metrics <project-name> --output json`
"List projects"	`uip ixp projects list --output json`
"Configure the model"	`uip ixp projects configure-model <project-name> [options] --output json`
"What model / pre-processing does this project use?" / "Query the model settings"	`uip ixp projects get-taxonomy <project-name> --output json` — the configured extraction model and pre-processing are under `Data.dataset._model_config` : `model_version` is the `--model` value (e.g. `gemini_2_5_flash` ), and `input_config` must be inverted to the `none` / `table_mini` / `table` token ( `null` = not configured, so report the project default — not `none` ). There is no `get-model-config` , and `configure-model` is a read-modify-write: never call it to find out the current settings, it rewrites them. Do NOT answer from `list-models` ' `ModelName` — that's the labeller family ( `gemini_ixp` ), not a `--model` value, and it says nothing about pre-processing. Inversion table: CLI Reference § Reading the current model and pre-processing.
"Delete a project" / "Remove this project"	`uip ixp projects delete <project-name> -y --output json` — permanent and irreversible; removes the project's documents, taxonomy, and trained models. Requires `-y/--yes` (the CLI never prompts).
"Upload a document" / "Add documents to an existing project"	`uip ixp documents upload <project-name> <file> --output json` — see CLI Reference § Uploading documents. One file per call; loop for multiple. For brand-new projects use `projects create` instead.
"Delete a document" / "Remove a document"	`uip ixp documents delete <project-name> <document-id> -y --output json` — irreversible, triggers retrain. `-y/--yes` is required (the CLI never prompts). To delete by filename, look up the `DocumentId` via `documents list` (the `Filename` field shows the original upload name).
"Add / delete / rename a field group"	`uip ixp groups {add,delete,rename} <project-name> --name <name> ... --output json` — see CLI Reference § Groups. `groups add` requires `--instructions` and `--fields '<json>'` — pass all of the new group's fields in that one `--fields` array (batch); do NOT create the group then add fields one at a time (use `fields add` only for an already-existing group). `delete` requires `-y/--yes` (the CLI never prompts).
"Add / edit / rename / delete a data type"	`uip ixp data-types {add,update-instructions,rename,delete} <project-name> --name <name> ... --output json` — see CLI Reference § Data Types. `add` requires `--kind` (text/date/money/number/boolean/choice) and `--instructions` . `--input-value` (exact-match/inferred) is required only for `--kind text` and `--kind choice` ; the other kinds don't have this property and the CLI rejects the flag for them. `delete` requires `-y/--yes` (the CLI never prompts); deleting a data type breaks any field referencing it. Reuse a default data type before adding a custom one (Critical Rule 17) — most needs map to a built-in (e.g. currency → `Monetary Quantity` ).
"Add / delete / rename / retype a field"	`uip ixp fields {add,delete,rename,change-type} <project-name> --group <name> --field <name> ... --output json` — see CLI Reference § Fields. `delete` requires `-y/--yes` ; `change-type` deletes annotations and also requires `-y/--yes` .
"Move a field to another group" / "this field belongs under X"	There is no move command — `--group` addresses a field, it never reparents one. Read the field's `type` and `instructions` from `projects get-taxonomy` , then `fields add` into the target group, then `fields delete <source> -y` . Add before deleting, so a failed add leaves the field where it was. Both groups must already exist; a move never creates one. IRREVERSIBLE — the recreated field gets a new `field_id` , so its confirmed labels do NOT follow it; say so before starting. Never move a field via `get-taxonomy` → edit → `import-taxonomy` : the import merges, so the field ends up in both groups. Full recipe: CLI Reference § Moving a field.
"Fix an OCR-garbled value" / "Confirm with a correction"	`uip ixp labellings confirm <project-name> <document-id> --fields <ids> --corrections '[{"field_id":"<id>","value":"<fixed>"}]' --output json` — confirms the listed fields and records the corrected value for the garbled one (include the corrected field's id in `--fields` ). `--corrections` is only for OCR garble — the prediction is already the right answer in the right location, merely misread (e.g. `MSIÓÓÓ601020/` → `MSI0601020` ); never use it to flip a wrong prediction, that field stays unannotated (Critical Rule 8). For one occurrence of a repeatable group add `--group <name> --occurrence <N>` ; in the batched `--group <name> --updates '[…]'` form each entry takes `"corrections": {"<field_id>": "<value>"}` (an object keyed by field id, not the flat array). See CLI Reference.
"Mark a field as missing for a document"	`uip ixp labellings mark-missing <project-name> <document-id> --fields <ids> --output json` — marks the listed fields missing; use when a field is genuinely absent and IXP predicted no value for it. Listing the field in `labellings confirm --fields` records the same missing marker when the field appears in predictions with an empty value. Only mark a field missing if IXP also predicted nothing for it — never to override a wrong prediction. See Critical Rule 12.
"Undo / unconfirm a wrong confirmation"	`uip ixp labellings unconfirm <project-name> <document-id> --fields <ids> --output json` — rolls back an earlier `confirm` or `mark-missing` for the listed fields ( `confirm` can't un-confirm — Critical Rule 14). Every other annotation on the document is carried forward. With `--fields` alone, a field id shared across occurrences of a repeatable group is removed from all of them; to roll back specific occurrences, add `--group` with `--occurrence <N>` or `--updates '[…]'` (mirrors `confirm` — see the row below and Critical Rule 14).
"Confirm one line item / extraction" / "Confirm only this occurrence"	`uip ixp labellings confirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json` — targets one specific extraction of a repeatable field group (0-based index from the latest `get-predictions` ). Without `--fields` , confirms every predicted field in that occurrence; with `--fields` , only those. Other occurrences untouched. Confirming renumbers the group on the next read (the confirmed row moves to `Occurrence` 0) — so batch multiple occurrences into one `--updates '[…]'` call rather than chaining `--occurrence` calls off a single read. See Critical Rules 13 and 18.
"Unconfirm one line item / extraction" / "Roll back only this occurrence"	`uip ixp labellings unconfirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json` — rolls back one specific extraction of a repeatable field group (0-based index, same as `get-predictions` / `confirm` ). Without `--fields` , unconfirms every annotated field in that occurrence; with `--fields` , only those. Other occurrences untouched. Re-read `get-predictions` first — on a partly-confirmed group the confirmed rows sort to the front, so the index that confirmed a row is usually not the index that rolls it back (Critical Rule 18). For several occurrences in one call, use `--updates '[…]'` instead. See Critical Rule 14.
"Set overall extraction instructions" / "Update project prompt"	`uip ixp projects update-prompt <project-name> --prompt "<text>" --output json` — replaces the taxonomy-wide prompt (the "Overall extraction instructions" field in the IXP UI). Distinct from `fields update-prompts` (per-field) and `groups update-prompts` (per-field-group).
"How is this project performing?" / "What's the F1?"	`uip ixp projects get-metrics <project-name> --output json` (+ `list-models` for the live version). If Data is `{ Metrics: null }` the model isn't validated yet — report that and stop. If the call instead returns `Result: Failure` with `ErrorCode: not_found` (a project with no trained model yet, e.g. no confirmed labellings), treat it the same way — report "no metrics yet" and stop. Otherwise Data is flat; report in order: (1) published version — live/published + `TrainedTime` ( `Tags[]` Name= `live` , `Models[]` Pinned); (2) overall `ProjectScore` / `ProjectScoreQuality` ; (3) per-group scores from `FieldGroups[]` (F1/Precision/Recall); (4) per-field scores from `Fields[]` , sorted lowest-F1 first. State numbers plainly; no "good enough" judgement unless asked; route low scores to Improve Prompts Guide. Answer from these two calls only — no ad-hoc discovery (Critical Rule #1).
"Describe this project" / "What's in it?"	Three calls, reported in order: (1) identity — `Title` / `Name` from `uip ixp projects get <project-name> --output json` ; (2) current model version — live/published + `TrainedTime` from `list-models` (the trained version, not the configured extraction model — for that see the row above); (3) taxonomy — label-group/field counts from `uip ixp projects get-taxonomy <project-name> --output json` (raw artifact: counts live under `Data.dataset.label_groups` and `Data.dataset.entity_defs` , snake_case). Fold in performance (above) only if asked. Do NOT page `documents list` (its `Data` is a paged `{ Documents, Total, Offset, Limit }` envelope — use `Total` for a count) or read deployment bindings. Answer from these calls only (Critical Rule #1).

用户请求	操作
"创建IXP项目" / "将文档上传到新项目"	项目设置指南 — 仅适用于新项目（一次调用完成上传+分类体系）。对于现有项目，请参阅下方“上传文档”行。
"导入此分类体系" / 提供分类文件	项目设置指南 — 选项B（ `--skip-taxonomy` + `import-taxonomy` ）
"标记文档" / "审核预测结果"	标记文档指南
"提升分数" / "修复提示词" / "提升F1分数"	提示词优化指南
"发布模型" / "标记为正式版本"	`uip ixp projects publish <project-name> --output json` — 发布最新版本，不带标记。添加 `--tag <live\|staging>` 可同时标记版本。请参阅cli-reference了解 `--model-version` / `--description` 参数。发布操作不会将模型部署到Orchestrator文件夹——发布仅使版本在项目内部可用； `deployments create` （请参阅下方“将此模型部署到文件夹”行）才会使模型可被活动包和Maestro Flow在运行时调用。除非用户要求部署，否则请勿将发布与部署操作关联——部署需要文件夹密钥，并会更改运行时调用者获取的内容。
"回滚到之前的版本" / "恢复版本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/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` ）都是必填参数； `--title` 默认值为项目名称去掉 `-ixp` 后缀。`create` 操作永远不会重新指向现有部署——如果该文件夹中已存在同一title但版本不同的部署，会返回 `409` ；请使用 `upgrade` （下一行）。从响应中读取 `DeploymentName` ：它是带有后缀的短名称，而非title或项目名称。请参阅cli-reference § 部署。
"将部署迁移到其他版本" / "升级已部署的模型" / "该文件夹正在使用旧版本"	`uip ixp deployments upgrade <project-name> <deployment-name> --version <N> --folder-key <guid> --output json` — `<deployment-name>` 是 `deployments list` 中的 `DeploymentName` ，而非title（在此处传递title会返回 `404` ）。该操作会更改该文件夹和名称下所有运行时调用者获取的模型版本，因此在修改共享文件夹前，请确认用户意图。这不是回滚路径——目标版本必须仍出现在 `projects list-models` 中。请参阅cli-reference § 创建与升级对比。
"此模型部署在何处？" / "列出部署" / "运行时哪个文件夹或版本是正式版本"	`uip ixp deployments list <project-name> --output json` — 返回包含 `DeploymentName` 、 `DeploymentTitle` 、 `ModelVersion` 、 `FolderKey` 、 `DeployedAt` 的数组；从未部署的项目会返回 `[]` 。`DeploymentName` 的唯一可靠来源——执行任何 `upgrade` 前请运行该命令。
"显示指标" / "分数是多少？"	`uip ixp projects get-metrics <project-name> --output json`
"列出项目"	`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参考文档 § 读取当前模型和预处理设置。
"删除项目" / "移除此项目"	`uip ixp projects delete <project-name> -y --output json` — 永久且不可逆；会移除项目的文档、分类体系和训练好的模型。需要 `-y/--yes` 参数（CLI不会提示确认）。
"上传文档" / "向现有项目添加文档"	`uip ixp documents upload <project-name> <file> --output json` — 请参阅CLI参考文档 § 上传文档。每次调用上传一个文件；批量上传请循环执行。对于全新项目，请使用 `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参考文档 § 字段组。 `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参考文档 § 数据类型。 `add` 需要 `--kind` （text/date/money/number/boolean/choice）和 `--instructions` 参数。 `--input-value` （exact-match/inferred）仅在 `--kind text` 和 `--kind choice` 时是必填参数；其他类型不支持该参数，CLI会拒绝该标记。 `delete` 需要 `-y/--yes` 参数（CLI不会提示确认）；删除数据类型会破坏所有引用它的字段。添加自定义数据类型前，请先复用默认数据类型（关键规则17）——大多数需求都可以映射到内置类型（例如货币→ `Monetary Quantity` ）。
"添加/删除/重命名/更改字段类型"	`uip ixp fields {add,delete,rename,change-type} <project-name> --group <name> --field <name> ... --output json` — 请参阅CLI参考文档 § 字段。 `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参考文档 § 移动字段。
"修复OCR识别错误的值" / "确认并修正"	`uip ixp labellings confirm <project-name> <document-id> --fields <ids> --corrections '[{"field_id":"<id>","value":"<fixed>"}]' --output json` — 确认列出的字段，并记录识别错误字段的修正值（将修正字段的id包含在 `--fields` 中）。`--corrections` 仅适用于OCR识别错误——预测结果在正确位置上是正确答案，只是字符被误读（例如 `MSIÓÓÓ601020/` → `MSI0601020` ）；切勿使用它来修正错误的预测结果，该字段应保持未注释（关键规则8）。对于可重复组的单个实例，请添加 `--group <name> --occurrence <N>` ；在批量 `--group <name> --updates '[…]'` 形式中，每个条目使用 `"corrections": {"<field_id>": "<value>"}` （以字段id为键的对象，而非扁平数组）。请参阅CLI参考文档。
"标记文档中的字段为缺失"	`uip ixp labellings mark-missing <project-name> <document-id> --fields <ids> --output json` — 标记列出的字段为缺失；仅当字段确实缺失且IXP未预测到值时使用。当字段在预测结果中显示为空值时，将其包含在 `labellings confirm --fields` 中也会记录相同的缺失标记。仅当IXP也未预测到值时，才标记字段为缺失——切勿通过此操作覆盖错误的预测结果。请参阅关键规则12。
"撤销/取消错误的确认"	`uip ixp labellings unconfirm <project-name> <document-id> --fields <ids> --output json` — 回滚之前对列出字段执行的 `confirm` 或 `mark-missing` 操作（ `confirm` 无法取消确认——关键规则14）。文档上的其他注释会保留。仅使用 `--fields` 时，可重复组中共享的字段id会从所有实例中移除；要回滚特定实例，请添加 `--group` 和 `--occurrence <N>` 或 `--updates '[…]'` （与 `confirm` 操作一致——请参阅下方行和关键规则14）。
"确认一个行项目/提取实例" / "仅确认此实例"	`uip ixp labellings confirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json` — 定位可重复字段组的特定提取实例（0-based索引，基于最新的 `get-predictions` 结果）。如果不使用 `--fields` ，会确认该实例中的所有预测字段；如果使用 `--fields` ，则仅确认指定字段。其他实例不受影响。确认操作会在下次读取时重新编号组（已确认的行变为 `Occurrence` 0）——因此请将多个实例的确认操作批量到一次 `--updates '[…]'` 调用中，而非基于单次读取结果连续调用 `--occurrence` 。请参阅关键规则13和18。
"取消确认一个行项目/提取实例" / "仅回滚此实例"	`uip ixp labellings unconfirm <project-name> <document-id> --group <name> --occurrence <N> [--fields <ids>] --output json` — 回滚可重复字段组的特定提取实例（0-based索引，与 `get-predictions` / `confirm` 一致）。如果不使用 `--fields` ，会取消该实例中所有已注释字段的确认；如果使用 `--fields` ，则仅取消指定字段。其他实例不受影响。请先重新读取 `get-predictions` ——对于部分确认的组，已确认的行会排在前面，因此确认行时使用的索引通常与回滚时使用的索引不同（关键规则18）。要一次回滚多个实例，请使用 `--updates '[…]'` 。请参阅关键规则14。
"设置全局提取指令" / "更新项目提示词"	`uip ixp projects update-prompt <project-name> --prompt "<text>" --output json` — 替换分类体系级别的提示词（IXP UI中的“全局提取指令”字段）。与 `fields update-prompts` （字段级）和 `groups update-prompts` （字段组级）不同。
"此项目的表现如何？" / "F1分数是多少？"	`uip ixp projects get-metrics <project-name> --output json` （结合 `list-models` 查看正式版本）。如果Data为 `{ Metrics: null }` ，表示模型尚未验证——请告知用户并停止操作。如果调用返回 `Result: Failure` 且 `ErrorCode: not_found` （例如项目尚未训练模型，没有已确认的标记），请按相同方式处理——告知用户“暂无指标”并停止操作。否则Data为扁平结构；请按以下顺序报告：(1) 已发布版本——正式/已发布状态 + `TrainedTime` （ `Tags[]` 中 `Name=live` ， `Models[]` 中 `Pinned=true` ）；(2) 全局 `ProjectScore` / `ProjectScoreQuality` ；(3) 来自 `FieldGroups[]` 的分组级分数（F1/精确率/召回率）；(4) 来自 `Fields[]` 的字段级分数，按F1分数从低到高排序。请直接报告数值；除非用户询问，否则不要做出“足够好”的判断；分数较低时，请引导用户查看提示词优化指南。仅通过这两个调用获取答案——请勿进行临时探索（关键规则1）。
"描述此项目" / "项目包含什么内容？"	执行三个调用，按顺序报告：(1) 标识信息——从 `uip ixp projects get <project-name> --output json` 获取 `Title` / `Name` ；(2) 当前模型版本——从 `list-models` 获取正式/已发布状态 + `TrainedTime` （训练版本，而非已配置的提取模型——请参阅上方行）；(3) 分类体系——从 `uip ixp projects get-taxonomy <project-name> --output json` 获取字段组/字段数量（原始工件：数量位于 `Data.dataset.label_groups` 和 `Data.dataset.entity_defs` 下，采用蛇形命名法）。仅当用户询问时，才添加性能信息（上文）。请勿分页 `documents list` （其Data是分页的 `{ Documents, Total, Offset, Limit }` 信封——使用 `Total` 获取数量）或读取部署绑定信息。仅通过这三个调用获取答案（关键规则1）。

Common Pitfalls

常见陷阱

Symptom	Cause	Fix
Metrics don't change after a prompt update	Re-evaluation hasn't completed	Wait out the retrain — Improve Prompts Guide § Waiting for retrain.
ModelVersion doesn't advance	Retrain still in progress	Any change to model inputs (labellings OR instructions) triggers a full retrain. Re-read metrics under the bounded wait in Improve Prompts Guide § Waiting for retrain — fixed interval, capped number of checks, then stop. Never poll indefinitely.
Field instructions conflict with label_def instructions	`fields update-prompts` only edits per-field instructions, NOT the parent label_def instructions	Before iterating, read the label_def `instructions` and update them with `groups update-prompts` if they contradict the per-field prompts.
A confirmed line item now reads back as the first row, or the other rows' `Occurrence` numbers shifted	Expected: the read returns annotation↔prediction matched pairs first, so confirmed rows sort ahead of unconfirmed ones	Nothing to fix — values and page locations are unchanged. Re-run `get-predictions` before the next per-occurrence call and target the row by its values (Critical Rule 18).
A second `--occurrence` call landed on the wrong row, or `unconfirm --occurrence N` no-ops	Indices came from a read taken before an earlier confirm renumbered the group	Re-read `get-predictions` between per-occurrence writes, or issue them as one `--updates` call.

症状	原因	修复方案
更新提示词后指标没有变化	重新评估尚未完成	等待重新训练完成——请参阅提示词优化指南 § 等待重新训练。
ModelVersion没有更新	重新训练仍在进行中	模型输入的任何变更（标记或指令）都会触发完整的重新训练。在提示词优化指南 § 等待重新训练中指定的有限等待时间内重新读取指标——固定间隔，限制检查次数，然后停止。切勿无限轮询。
字段指令与label_def指令冲突	`fields update-prompts` 仅编辑字段级指令，而非父label_def指令	在迭代前，请读取label_def的 `instructions` ，如果与字段级提示词冲突，请使用 `groups update-prompts` 进行更新。
已确认的行项目现在显示为第一行，或其他行的 `Occurrence` 编号发生了变化	预期行为：读取操作会优先返回注释↔预测结果的匹配对，因此已确认的行会排在未确认行的前面	无需修复——值和页面位置未发生变化。下次执行实例级调用前，请重新运行 `get-predictions` 并通过值定位行（关键规则18）。
第二次 `--occurrence` 调用指向了错误的行，或 `unconfirm --occurrence N` 未执行任何操作	索引来自之前的读取操作，而之前的确认操作已重新编号了组	在实例级写入操作之间重新读取 `get-predictions` ，或通过一次 `--updates` 调用执行操作。

Unsupported Capabilities

不支持的功能

These requests fall outside the skill. Recognise the request, reply with the standard response, route the user. Do NOT enter discovery (

uip --help

, grep, source reading) — see Critical Rule #1.

User request	Standard response
"Create a model" / "create a project"	Documents or a taxonomy supplied → use the Project Setup Guide (this skill creates the project from them). Otherwise → "I work on existing IXP projects rather than creating them from scratch. Create one in-product: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — then I can label, review, and improve it."
"Upload these files" / "add documents"	Project named / already in context → supported; upload it (see the "Upload a document" row in Task Navigation). Otherwise → "Name an existing project and I'll upload it — or upload in-product (e.g. for a new project): https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models."
"Deploy this model" / "push to staging / production / folder / environment / tenant"	Folder deployment is supported — deploy with `uip ixp deployments create` (see the "Deploy this model to a folder" row in Task Navigation). If the user NAMES a folder rather than giving its key, resolve the name with `uip or folders list --output json` — ask only when no folder was identified at all. For anything that is not an Orchestrator folder: "I deploy model versions to Orchestrator folders. Binding to environments or another tenant is a product-side flow: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models." Note `projects publish --tag staging\|live` tags a version inside the project — it deploys nothing.
"Give X access" / "share this project" / "change roles or permissions"	"Access, roles, and permissions are managed in-product, not through this skill: https://docs.uipath.com/ixp/automation-cloud/latest/overview/managing-access."
"Use this model in my automation / workflow / agent" / "call the extractor from a process"	"Consuming a published model inside an automation is an authoring task outside this skill. See https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-consuming-a-workflow."
"Mine these emails / communications" / "set up Communications Mining"	"Communications Mining is a separate IXP capability this skill doesn't cover (this skill is document extraction). See https://docs.uipath.com/ixp/automation-cloud/latest/cm-user-guide/introduction-to-uipath-communication-mining."
"Monitor the deployed model" / "how many docs did it process?" / "runtime throughput or incidents"	"Runtime/operational monitoring of a deployed model lives in Orchestrator, not this skill: https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/about-monitoring. For design-time scores use `get-metrics` (see 'Show metrics')."
"Edit a data type's values" / "add or remove a Choice option"	"The CLI can rename a data type, change its instructions ( `data-types update-instructions` ), or delete it — but it can't add or remove the values of an existing Choice data type. Do that by hand in-product on the Manage Taxonomy page: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — then continue here."

以下请求超出了本技能的范围。请识别请求，回复标准响应，并引导用户。请勿进行探索（

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。"
"部署此模型" / "推送到预发布/生产/文件夹/环境/租户"	支持文件夹部署 — 使用 `uip ixp deployments create` 进行部署（请参阅任务导航中的“将此模型部署到文件夹”行）。如果用户指定了文件夹名称而非密钥，请通过 `uip or folders list --output json` 解析名称——仅当未识别到任何文件夹时才询问用户。对于非Orchestrator文件夹的部署："我会将模型版本部署到Orchestrator 文件夹。绑定到环境或其他租户属于产品端流程：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models。" 请注意 `projects publish --tag staging\|live` 仅在项目内部标记版本——不会执行部署操作。
"授予X访问权限" / "共享此项目" / "更改角色或权限"	"访问权限、角色和权限在产品内管理，而非通过本技能：https://docs.uipath.com/ixp/automation-cloud/latest/overview/managing-access。"
"在我的自动化/工作流/代理中使用此模型" / "从流程中调用提取器"	"在自动化中使用已发布的模型属于创作任务，超出了本技能的范围。请参阅https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-consuming-a-workflow。"
"挖掘这些电子邮件/通信内容" / "设置通信挖掘"	"通信挖掘是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`（请参阅‘显示指标’）。"
"编辑数据类型的值" / "添加或删除Choice选项"	"CLI可以重命名数据类型、更改其指令（ `data-types update-instructions` ）或删除它——但无法添加或删除现有Choice数据类型的值。请在产品内的管理分类体系页面手动操作：https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — 之后可继续使用本技能。"

Reference Navigation

参考导航

CLI Commands Reference — all
```
uip ixp
```
commands with options and output formats
Project Setup Guide — create a new project, review and label documents
Improve Prompts Guide — iterative optimization loop with regression detection
Label Documents Guide — reusable workflow for reviewing and confirming predictions

CLI命令参考 — 所有
```
uip ixp
```
命令及其选项和输出格式
项目设置指南 — 创建新项目、审核和标记文档
提示词优化指南 — 包含回归检测的迭代优化循环
标记文档指南 — 用于审核和确认预测结果的可复用工作流