uipath-maestro-flow

UiPath Flow——TypeScript Builder SDK

可以使用 @uipath/maestro-builder-sdk 包通过 TypeScript 编写 UiPath Flow 编排。 该 SDK 提供了构建器 API，用于构建 Flow 图，让开发者能够以类型安全的方式定义输入、输出、步骤和控制流。 该图会被“编译”为 Flow JSON，这是在 UiPath 平台上执行 Flow 时使用的产物。 也可以将现有的 Flow JSON 反编译回 TypeScript 进行编辑。

**在编写或编辑任何 Flow 源文件之前，请完整阅读 references/author.md。**该文件包含本指南仅作概述的关键规则、范围门槛，以及最终回复必须遵循的完成报告格式。

项目布局

@uipath/maestro-builder-sdk 是全局安装的（npm install -g）；examples/ 包含编写好的示例，references/ 包含本指南指向的详细信息。 Flow 源文件以 .flow-sdk/<Name>.flow.ts 的形式放在项目文件夹 <Solution>/<Name>/ 中，并直接导入该包。

编写源文件的位置是 .flow-sdk/；编译产物不在此目录中。 .flow-sdk/ 是 SDK 自己的工作目录：源文件、bindings.json、connectors/ 和 connectors-local/ 默认都放在这里，相对于运行 uip 的目录。每个 Flow 项目都有自己的工作目录，因此一个解决方案可以包含多个 Flow；Studio Web 不会读取此目录，uip solution pack/upload 和 flow debug 也不会将其包含在内。 从项目文件夹 <Solution>/<Name>/ 运行 SDK 命令（flow check、compile、decompile、merge、registry pull/prepare、node .flow-sdk/*.pipeline.mjs）；如果 shell 不会在命令之间保留当前目录，请使用 ( cd "<Solution>/<Name>" && … )；本指南及其引用文档中的所有 .flow-sdk/ 路径均相对于此文件夹。其他操作则从工作区根目录运行。 先搭建项目，再以其为基础创建源文件，然后将产物写回项目——产物的写入位置由 compile -o 决定。 <Solution> 和 <Name> 取自请求中的名称；若两者只提供了同一个名称（“在同名解决方案中”），或只提供了 Flow 名称，则该名称同时用于两者。<Solution> 保留原样，包括空格；<Name> 仅保留字母、数字、_ 和 -（Headcount report form → HeadcountReportForm）。 **运行 uip solution init 前，请先查找现有解决方案：**运行 find . -maxdepth 2 -name '*.uipx'。如果找到一个且可以询问用户，请询问要使用哪一个（每个解决方案列为一个选项，然后是“创建新解决方案”，最后是“其他”），在用户选择之前不要搭建任何内容；绝不能悄悄创建第二个解决方案。若无法交互，则使用请求中指定的解决方案；否则使用唯一存在的解决方案；若都不符合，则创建一个以上述规则命名的新解决方案，并在最终回复中记录此选择。

uip solution init "<Solution>"
( cd "<Solution>" && uip maestro flow init <Name> --sdk-source )
# edit <Solution>/<Name>/.flow-sdk/<Name>.flow.ts, then run the Lifecycle loop below

不要手写骨架。 --sdk-source 会将 flow init 写入的仅含触发器的产物反编译到项目的 .flow-sdk/<Name>.flow.ts 中，并创建该文件夹；源文件会保留产品已分配的 Flow ID 和名称——手写 flow('<name>') 会生成一个新 ID。 因此，该存根是种子，而非垃圾：首次执行 compile -o 会就地覆盖它。 如果源文件已存在，init 会拒绝执行，除非使用 --force；当源文件已经存在时，不要使用 --sdk-source。 **Maestro Automate 使用同一个 flow init 命令中的 --automate：**如果请求明确指定产品为 Maestro Automate，请运行 ( cd "<Solution>" && uip maestro flow init <Name> --automate --sdk-source )；单独使用动词（“automate invoice intake”）表示创建普通 Flow。 init 之后无需再做其他更改；该标志会将 runtimeOptions.profile 写入 operate.json，并创建 .maestro_automate 标记；compile -o 只会重写 .flow，因此两者都会保留。 现有项目无需执行 init：跳过前两条命令，使用已有的 .flow 执行 ( cd "<Solution>/<Name>" && uip maestro flow decompile <Name>.flow -o .flow-sdk/<Name>.flow.ts --no-pipeline ) 来初始化（--no-pipeline 会跳过棕地项目辅助流程，见 references/brownfield.md）；如果源文件已存在，则跳过反编译。 三个名称必须保持一致：.flow-sdk/<Name>.flow.ts、<Name> 项目目录，以及其中的 <Name>.flow。 只能生成一个 <Name>.flow，且必须位于 <Solution>/<Name>/<Name>.flow，绝不能在工作区根目录再放一份。 只有在打包 SDK 的本地门禁中才应生成到根目录；这些门禁不会搭建项目。先选择循环（生命周期），不要混用两者。

请先安装 SDK，每台机器只需安装一次： npm install -g @uipath/maestro-builder-sdk；如果已安装，则跳过。检查和故障处理请参阅 references/CLI-LOOP.md。

与非 UiPath 系统的集成通过连接器处理。编写节点前先选择节点。 对于外部服务或数据（天气、Slack、REST API），请在本地连接器库中运行 uip maestro registry search '<brand or service name>'，除非请求明确指定传输方式（“通过 HTTP，而非连接器”表示使用 http()）：命中结果表示存在连接器，"total": 0 表示未命中，应使用 http()（外部 Agent 除外：见表格）；如果出现用法错误，说明库尚未缓存，因此请先运行 uip maestro registry pull。对于文档提取或其他租户能力（Agent、流程），本地连接器库不包含这些内容，请运行相应类别的 uip maestro flow registry search（见 references/ixp.md、references/agent.md）。返回固定值的 script() 绝不能替代此步骤；只有搜索确认某项能力不存在时，才能用 mock() 标记该能力。 连接器需要 .flow-sdk/bindings.json。 uip maestro registry pull 会为每个引用的连接器将描述符写入 .flow-sdk/connectors/<key>.ts，并在项目外缓存连接器库本身。 准备好的连接器模块位于 .flow-sdk/connectors-local/<key>.ts；其描述符数据则单独保存在 .flow-sdk/connectors-local/descriptors/<key>/ 下。 由于源文件也位于 .flow-sdk/ 中，因此会通过 ./connectors/<key>.ts 和 ./connectors-local/<key>.ts 导入这些模块。

连接器循环：编写 → 检查 → 准备 → 检查 → 编译

编写时无需等待 prepare：上面的搜索选定节点后，编写源代码前不需要再运行任何发现命令。 根据任务本身的措辞编写连接器步骤——包括你打算使用的字段、用于 ID 的 lookup() 令牌，以及用于通用操作的 { object: '<name-as-the-task-said-it>' }，然后运行 uip maestro flow check .flow-sdk/<Name>.flow.ts --source。 检查名称，确定需要进行的每次 prepare，并使用准确的命令： 对于尚未物化的对象，使用 OBJECT_UNPREPARED；对于不在租户无关快照中的输入，使用 CUSTOM_FIELDS_UNPREPARED；对于没有记录值的查找令牌，使用 LOOKUP_UNRESOLVED；对于操作未声明的字段，使用 CONNECTOR_INPUT。运行对应的一条 uip maestro registry prepare <connector-key> --action <action> 命令——--object、--resolve 和 -f 可以在一次调用中组合使用；它会自行查找连接、写入 .flow-sdk/bindings.json，并将导入路径改指向生成的 ./connectors-local/<key>.ts 描述符——然后重新运行 check 并编译。 如果两个 Flow 导入了同一个连接器，命令会列出它们，而不是猜测，并要求使用 --source。 CONNECTOR_NOT_IN_LIBRARY、CONNECTOR_OBJECT_REQUIRED 和 CONNECTOR_OBJECT_NOT_GENERIC 都需要修复源代码，而不是运行 prepare：connector-params.md。

架构动态操作（loadByDefault、依赖下拉列表、customFieldsRequestDetails）需要在 prepare 检查中提供所有必需的 -f，并在编译后检查缓存：references/connector-params.md。

Hello world Flow

import { flow, script, input, out, types } from '@uipath/maestro-builder-sdk';
export default flow('hello').name('Hello')
  .input({ name: types.string }).output({ greeting: types.string })
  .step('greet', script({ code: 'return `Hello ${$vars.start.output.name}`;' }))
  .return({ greeting: out('greet') }).build();

脚本是一种一等 Flow 节点；它会内联运行 JavaScript 并返回一个值。 start 步骤是“手动触发器”的默认名称，会携带 Flow 的输入。 Flow 可以有输出；Flow 成功完成时，这些输出会返回给调用方。

生命周期

运行任何构建命令前，先选择一个循环；切勿在同一工作区中混用，也不要用一个循环探测另一个循环：

• Product-CLI 循环（仅发出）：当任务要求提供产品 validate/debug 证据，或工作区仅支持发出时使用：package.json 中包含 { "flowSdk": { "emitOnly": true } }（产品运行时评估会设置此项），或设置了 FLOW_SDK_EMIT_ONLY=1。先搭建脚手架（项目布局），然后运行下面的代码块。
• 打包 SDK 本地门禁：其他情况使用：对源代码运行 check，将 compile 输出到根目录，再运行 validate——references/CLI-LOOP.md。

uip maestro flow 命令会将其语义委托给已安装的 @uipath/maestro-builder-sdk。仅发出模式属于项目，而不属于你运行命令的目录：沿目录树向上查找，最近的声明了 flowSdk.emitOnly 的 package.json 决定是否启用该模式；未提及 flowSdk 的嵌套 package.json 会继承该设置，而 emitOnly: false 则会退出该模式。在该模式下，compile 只会序列化源代码，flow check 的两种模式都会拒绝运行，而产品 validate 负责结构验证。基本流程为：发出、绑定任何必需的构件，然后 validate：

( cd "<Solution>/<Name>" && uip maestro flow compile .flow-sdk/<Name>.flow.ts -o <Name>.flow )
uip maestro flow validate "<Solution>/<Name>/<Name>.flow" --output json
# Greenfield only (never a merged or .layout() file), before upload/debug/a designer:
uip maestro flow format "<Solution>/<Name>/<Name>.flow" --output json
# Only for a stated runtime-behavior claim:
( cd "<Solution>" && uip solution resources refresh --solution-folder . --output json )
( cd "<Solution>" && uip maestro flow debug <Name> --log-level error \
  --output-filter "{status:finalStatus,instance:instanceId,url:studioWebUrl,failed:elementExecutions[?status!='Completed'].{id:elementId,status:status},<Out>:variables.globals.<Out>,incidents:incidents}" \
  --output json )

<Out>：每个声明的 out 变量，而不是 variables.globals 中的所有变量。最后一次编辑源代码或绑定后，重新运行从 compile 开始的流程。有效结果是顶层的 Result 加上 Data.Status: "Valid"；除已审核的共享连接提示和 err() 诊断外，将 Data.Warnings 视为失败。若 Completed 包含预期的全局变量且 failed 为空，则属于运行时证据；仅有退出代码不算。调试输入、附件、其他投影和事件：references/CLI-LOOP.md。

编辑现有流程

在棕地工作中，保留提供的源文件、步骤名称和未受影响的连线。插入步骤时，应将原边经过该步骤，而不是创建第二条路径。如果只有已发出的 .flow JSON，请将其反编译，编译原始基线，进行小范围编辑，再将差异合并回原文件。 这些是前后状态的判断；任何最终产物检查器都无法证明这些操作。

对于小范围编辑，decompile 会写入 .flow-sdk/<Name>.pipeline.mjs，该文件会通过两次调用运行循环，并确保基线顺序正确。它也会将基线、编辑后的和合并后的 .flow 文件保存在 .flow-sdk/ 中：

uip maestro flow decompile <Name>.flow -o .flow-sdk/<Name>.flow.ts
node .flow-sdk/<Name>.pipeline.mjs      # captures the pristine baseline
# edit .flow-sdk/<Name>.flow.ts narrowly; no .layout() for added steps (builder-sdk#1320)
node .flow-sdk/<Name>.pipeline.mjs      # compiles the edit and merges it back

将项目备份到 mktemp -d 创建的目录，把合并输出整体 cp 覆盖到备份目录中，并在那里验证（而不是验证编辑后的编译文件），然后删除备份。切勿写入或将 compile 输出到规范 .flow 文件。 如果源文件必须留在 Flow 项目中（例如，为了保留相对路径的附属文件），请将基线、编辑后的和候选 .flow 文件保存在外部 .flow-work/ 目录中。安装候选文件，验证规范产物，并确保项目下恰好只留一个 .flow 文件。以下参考内容包含可复制的安全项目操作流程。

真正的棕地操作流程： references/brownfield.md。

构建器框架

上面的快速入门展示了基本结构——flow(id)、声明、节点、.return(...)、.build()。它没有展示以下三点：

• .var(name, types.*, default?) 声明一个流程变量：可由多个步骤写入或读取的值。.input 和 .output 是流程与调用方之间的契约；var 是中间状态。步骤使用 { updates: { name: <expr> } } 写入变量。输入、输出和 var 使用 Flow CLI 与 Workbench 提供的六种类型之一：types.string、types.number、types.boolean、types.object、types.array、types.file。其他 types 成员（integer、float、double、date、datetime、jsonSchema）来自 Case 和 BPMN 构建器；Flow 构建器和 validate 接受它们，不会报错，但 Workbench 不提供这些类型，因此日期应写作 types.string，整数应写作 types.number。构建器没有读取 Orchestrator 资源的节点：请将设置保留为 var 默认值或输入。

• .return(...) 结束一条路径。.terminate(...) 结束一次运行。 在直线链中，两者看起来可以互换，但实际上并非如此：在 .parallel 分支中，terminate 会中止正在运行的兄弟分支，而 return 会让它们继续运行。

• 表达式用于为步骤指定非字面值。 每种可引用对象都有对应的一种表达式：

  	引用对象
  input(name)	流程输入
  v(name)	流程变量
  out(step, path?)	步骤结果，整体或其中一个字段
  err(step, field?)	FAILED 步骤的错误信封——仅限在其处理器中使用
  ran(step)	步骤是否运行过，返回布尔值
  lit(value)	常量，用于原始值可能产生歧义的情况
  js`…` / tmpl`…`	由你编写的表达式或字符串

  提前提及 ran(step) 是有原因的：多个分支汇合时，通常让它们共享同一后续步骤，比在每个分支中重复相同工作更清晰；而 ran 可以让该后续步骤判断所需值是否已生成。

API 索引

所有签名、选项形状和字段都编入了已安装的 @uipath/maestro-builder-sdk 软件包的索引中，而非本指南；表格中的路径均相对于软件包根目录：

你要查找的内容	查看位置	表格行提供的信息
字段或方法 — outcomePorts、stepToList（通常情况）	dist/api-members.md	声明该内容的结构，以及对应的行
导出的符号 — HitlInputs、hitl、FlowBuilder	dist/api-index.md	该符号的类型、所属区域，以及声明它的行

匹配一个名称；不要从头到尾阅读任一文件。 然后阅读对应片段（例如 dist/core/actions.d.ts:583-597）：包含文档注释的完整声明，一次阅读即可解答问题。阅读 .d.ts，切勿阅读 dist/*.js（没有类型，也没有注释）。两个索引中都找不到的名称，可能是节点引用中包含的 RUNTIME 输出键。有关索引随软件包发布的原因和更多查找规则，请参阅：references/author.md。

支持的节点类型

此表是权威路由指南。编写节点前，请先阅读其 Reference：签名、完整示例和节点注意事项都在其中，而不在本指南中。Example 列出可供复制的唯一完整工作流；examples/ 下的路径均相对于此技能文件夹。

节点或界面	发出的节点类型	构建器	参考	示例
手动触发器	core.trigger.manual	省略 .trigger(...)	手动触发器	examples/GreenhouseWatering.flow.ts
入口点（多个触发器）	每个额外根节点对应一个触发器节点	.entryPoint(id, trigger, { inputs?, version? }, prefixFn?)；在多个根节点间共享一个变量：输入 { type, shared: '<var>' }	手动触发器	—
计划触发器	core.trigger.scheduled	scheduled(...)	计划触发器	examples/HerbariumDispatch.flow.ts
连接器事件触发器；由 HTTP 调用启动	uipath.connector.trigger.<key>.<event>	onEvent(...)	事件触发器、HTTP 调用	examples/DoorbellLog.flow.ts
连接器事件等待	uipath.connector.event.<key>.<event>	waitForEvent(...)	事件触发器	examples/PlanetariumConfirmation.flow.ts
表单触发器	core.trigger.form	formTrigger(...)	表单触发器	examples/BakeOffEntryForm.flow.ts
对话触发器	core.trigger.conversation	conversationTrigger(...)	对话式交互	examples/LibraryDeskChat.flow.ts
语音触发器	core.trigger.voice	voiceTrigger(...)	语音	examples/HarbourRadioLine.flow.ts
独立 HTTP	core.action.http	http({ managed: false, ... })	HTTP	examples/LighthouseSignal.flow.ts
托管 HTTP	core.action.http.v2	http({ managed: true, ... })	HTTP	examples/ObservatorySeeing.flow.ts
脚本	core.action.script	script(...)	脚本	examples/GreenhouseWatering.flow.ts
转换	core.action.transform	transform(...)	转换	examples/TrailLogSummary.flow.ts
筛选	core.action.transform.filter	transform({ variant: 'filter', ... })	转换	examples/TrailLogSummary.flow.ts
映射	core.action.transform.map	transform({ variant: 'map', ... })	转换	examples/TrailLogSummary.flow.ts
分组依据	core.action.transform.group-by	transform({ variant: 'group-by', ... })	转换	examples/TrailLogSummary.flow.ts
Integration Service 操作	uipath.connector.<key>.<action>（Data Fabric / Data Service——原生类型系列缺少的操作：文件记录字段、事件：uipath.connector.uipath-uipath-dataservice.*）	connector(...)	连接器参数	examples/ClubDirectory.flow.ts
Data Fabric 读取	core.datafabric.read（resultMode: 'multiple' 选择其 1.4 定义；limit 上限为 1000）	dataFabricRead(...)	Data Fabric	examples/BeeHiveLedger.flow.ts
Data Fabric 创建	core.datafabric.create	dataFabricCreate(...)	Data Fabric	examples/BeeHiveLedger.flow.ts
Data Fabric 更新	core.datafabric.update	dataFabricUpdate(...)	Data Fabric	examples/BeeHiveLedger.flow.ts
Data Fabric 删除	core.datafabric.delete（不声明任何输出）	dataFabricDelete(...)	Data Fabric	examples/BeeHiveLedger.flow.ts
子流程	core.subflow	subflow(...)	子流程	examples/RecipeScaler.flow.ts
人工任务	uipath.human-in-the-loop	hitl(...)	人工参与	examples/GallerySubmission.flow.ts
人工快速表单	uipath.human-in-the-loop.quick-form（每种结果对应一个出口：.stepSwitch 将它们路由到不同分支，普通 .step() 则对所有结果继续执行）	hitl({ variant: 'quick-form', ... })	人工参与	examples/FieldTripQuickForm.flow.ts
人工操作应用	uipath.human-in-the-loop.coded-action-app	hitl({ variant: 'action-app', ... })	人工参与	examples/KilnReview.flow.ts
RPA 工作流	uipath.core.rpa-workflow.<key>	rpaWorkflow(...)	RPA 工作流	examples/WorkshopInventory.flow.ts
队列项目	core.action.queue.create*	queueItem(...)	队列	examples/HerbariumDispatch.flow.ts
总结	uipath.pattern.deep-rag	summarize(...)	总结	examples/OralHistoryDigest.flow.ts
批量转换	uipath.pattern.batch-transform	batchTransform(...)	批量转换	examples/FossilCatalogEnrich.flow.ts
分支	core.logic.decision	.branch(...)	分支	examples/GreenhouseWatering.flow.ts
切换	core.logic.switch	.switch(...)	切换	examples/BeltProgression.flow.ts
并行 / 合并	core.logic.merge	.parallel(...)	并行与合并	examples/ConcertSoundcheck.flow.ts
循环	core.logic.loop	.loop(...)	循环	examples/ClubDirectory.flow.ts
执行后判断循环	core.logic.dowhile	.doWhile(...)	循环	examples/MeteorShowerPages.flow.ts
返回 / 结束	core.control.end	.return(...)	返回	examples/GreenhouseWatering.flow.ts
终止	core.logic.terminate	.terminate(...)	终止	examples/AquariumSafetyStop.flow.ts
占位符	core.logic.mock	mock()	占位符	examples/FestivalMapScaffold.flow.ts
未知节点类型	注册表中的 nodeType 原样保留（绝不能使用 uipath.connector.*）	rawNode(...)	占位符	—
错误处理器	操作节点上的 error 句柄	.onError(...)	错误处理	examples/ObservatorySeeing.flow.ts
延迟	core.logic.delay	delay(...)	延迟	examples/LighthouseSignal.flow.ts
API 工作流	uipath.core.api-workflow.<key>	apiWorkflow(...)	API 工作流	examples/BirdCountLookup.flow.ts
Agentic 流程	uipath.core.agentic-process.<key>	agenticProcess(...)	Agentic 流程	examples/NeighborhoodWalkPlanner.flow.ts
Agent 资源	uipath.core.agent.<key>	agent(...)	Agent	examples/PlantNameAdvisor.flow.ts
外部 Agent 或自动化	uipath.connector.<key>.<operation>	connector(...)；如果库不支持，则使用 CLI	外部 Agent	—
内联 Agent	uipath.agent.autonomous	inlineAgent(...)	内联 Agent	examples/PostcardCaption.flow.ts
IxP 提取	uipath.ixp.<project>.<version>-<folder>	ixpExtract(...)	IxP	examples/ArchiveCardExtract.flow.ts
文档分类	uipath.document.classify	documentClassify(...)	文档处理管道	examples/SeedPacketReader.flow.ts
动态提取	uipath.ixp.extract-document-builder	dynamicExtract(...)	文档处理管道	examples/SeedPacketReader.flow.ts
已发布函数	uipath.core.function.<key>	publishedFunction(...)	已发布函数	examples/TideTableConverter.flow.ts
对话消息等待	uipath.conversational.wait-for-message	waitForMessage(...)	对话式交互	examples/LibraryDeskChat.flow.ts
对话式 Agent	uipath.agent.conversational	conversationalAgent(...)	对话式交互	examples/LibraryDeskChat.flow.ts
发送对话消息	uipath.conversational.send-message	sendMessage(...)	对话式交互	examples/LibraryDeskChat.flow.ts
语音外拨电话	uipath.conversational.voice.create-outgoing-call	createOutgoingCall(...)	语音	examples/PotteryStudioCallback.flow.ts
语音 Agent	uipath.agent.voice	voiceAgent(...)	语音	examples/PotteryStudioCallback.flow.ts
语音结束通话	uipath.conversational.voice.end-call	endCall(...)	语音	examples/PotteryStudioCallback.flow.ts

编写流程

在注册表中搜索并选择每个节点，不要使用品牌名称；如果请求留下了有限的待定选择，包括输入值、范围或未被任何既定规则涵盖的组合，就要提问（不要把它归入某个既定值；如果请求说明无人会回答（无头模式、CI），则映射到最站得住脚的既定值，并在「待解决问题」下列为 [REQUIRED]）；在每条路径上绑定每个已声明的输出（check 不会发现缺失的输出，运行结果会是 undefined）；只有请求说明了应如何处理错误时才处理错误。其余内容请参阅 references/author.md。 如果请求指定了画布布局，请使用 .layout() 和 at()/dim()：references/operate.md。

操作已部署的流程

上传、部署、调试、触发、检查作业，并管理实例的生命周期。所有这些操作都需要 uip login，且每次上传、发布或调试之前都要运行 uip solution resources refresh。flow debug 是一次真实运行，而不是验证步骤。请阅读 references/operate.md。

诊断运行失败

按顺序排查——先检查已有的调试响应，然后是事件、运行时变量、已部署的制品，最后才看跟踪记录。切勿重新运行 flow debug 来查看。构建器会消除若干经典 .flow 缺陷，但仍会留下其他缺陷，包括实际上是字面量的表达式。请阅读 references/diagnose.md。

评估流程

内联 Agent 不会创建评估器、评估集、数据点或模拟；Flow eval CLI 会将它们作为项目文件进行管理。运行评估集之前，先模拟所有会产生副作用的组件；未经询问，绝不要在评估工作流中运行 solution upload。请阅读 references/evaluate.md。

最终证据

最终检查必须使用与打包模式相匹配的循环，并在最后一次编辑后运行。产品资源的真实状态属于实时证据：请根据租户确认 ID、参数名称、以场景命名的可选输入和警告是否合理。 静态诊断负责检查所有可机械验证的结构；应修复问题根因，而不是将规则复制回此路由器。

让证明与请求的验收标准相匹配。如果还剩一个连线问题，那么当产品验证通过且必需的结构自检通过时，仅验证标准就已满足；不要只为增加信心而添加调试。对于验收标准中列出的每项行为声明，最多规划一次有界的产品调试来回答。如果还剩一个连线问题，就运行一次能区分情况的有界实验，应用其结果，然后停止；不要创建一系列临时解决方案，也不要重复等效变体。