工组是「工作组」的简称，在绘而码产品体系中专指为完成某一类任务而预先编成的一组 AI 协作单元：参与角色、所用模型与协作规则在组内统一配置，可整体命名、单独选用。通俗地说，工组是一支可一键调用的 AI 协作队伍。选定工组，即决定由哪一支队伍承担当前任务，用户无需自行甄别与挑选模型。

技术背景

单一模型难以同时满足成本、速度与质量三项要求：能力上限更高的模型调用昂贵、响应较慢，轻量模型在困难任务上可靠性不足。随着大模型被广泛使用，这一矛盾成为 AI 工程领域持续被讨论的重要议题。围绕它，业界形成了三条可相互配合的技术路线，并叠加一项底层工程约束。

1. 模型路由（Model Routing / LLM Router）：依据问题难度、成本预算、质量目标与用户偏好，把请求分发至适配的模型。
2. 模型级联（LLM Cascading）：先由轻量模型作答，质量不足时逐级上升到更强的模型。
3. 多智能体工作流（Multi-Agent Workflow）：把完整复杂任务拆解为规划、实现、验证、审查等立场，由多个角色协同完成，CrewAI、AutoGen、MetaGPT 等开源框架属于这一方向。

底层工程约束来自计费方式：大模型通常按输入与输出的 token 计费，长会话中反复发送的输入上下文往往占成本比例较大。厂商的提示词缓存（Prompt Caching）可以对稳定的输入前缀给出折扣，但在跨模型、跨档位切换时，已建立的输入侧缓存往往失效，需要重新发送全部上下文。因此上下文工程（Context Engineering，即怎样组织提示词、何时才允许换挡）直接决定调度能否真正省钱。

这一方向上的公开研究为上述判断提供了依据：FrugalGPT（Chen 等，斯坦福与加州大学伯克利分校，arXiv:2305.05176，2023）实例化了级联策略，报告在其实验设置下可在匹配最佳单个模型表现的同时降低成本至多 98%；RouteLLM（Ong 等，加州大学伯克利分校 LMSYS，arXiv:2406.18665，2024）则从路由方向给出类似结论。需要说明的是，这些数字属于论文自身的实验结果，具体效果取决于模型、任务、缓存策略与评测集，也以路由判断足够可靠为前提，不等同于绘而码上的实际节省幅度。

绘而码的工组不是在上述路线之外另造一套概念，而是把它们收拢为使用者可以一次点选的对象：不同工组之间的切换，是把模型路由的判断命名化、显式化，交给使用者按任务形态决定；工组内部的自动升降档，遵循级联思路，先由低档承担、遇到阻力再上升；工程工组则把多智能体工作流固定成一支常设班底。三条路线在工组这一层合成为一个动作：选一支班底。这也是工组把前沿调度技术落到日常使用的关键环节。

设计思路

工组的设计目标可以概括为一句话：把路由、分工与智能换挡的决策留在系统内部，把选择权收敛为一次点击。 支撑这一目标的是三条原则。

低档承担、高档兜底。

工组的定档原则为「就低」，即在满足任务要求的最低档位启动；仅当系统识别到可观测的受阻信号（工具调用出现失败，且连续几轮没有实质推进）时，才上升一档。任务回到顺流有进展的状态后，工组又会降回更经济的档位；换挡的冷却按对话轮次计、不按时间，因此不会在短时间内来回跳动。需要说明的是，换挡判断依据的是任务有没有向前推进，并不评判答案内容本身是否正确，因而上升不意味着上一轮的回答是错的，也不保证下一轮不再出错。还要提醒一句边界：受阻信号只看工具调用，写方案、改文案、做分析这类全程不调工具的任务，不会因为答得不好而自动上升，需要更高投入时要你手动处理（机制详见「标准工组」）。

通俗地说，日常请求默认走最经济的通道，只有确认做不动时才交给更强的模型；正因存在这条兜底通道，低档优先在多数场景下不会以牺牲答案质量为代价。

这几层关系的默认状态是：工组由使用者选择，档位交给系统判断。选定工组后即为自动挡，由系统按消息长度、涉及文件数量与任务步骤数等信号确定起始档位，执行中再按上面的信号升降；也可以在工组内锁定某一档位，锁定后不再自动换挡，已积累的上下文需重新发送。工程工组不分档，由项目长按任务需要把活分派给不同角色、可并行协作；指定单个模型则完全退出这套调度。

把上下文的代价算进调度。

工组在提示词组织上将稳定内容前置、易变内容后置，以提高提示词缓存的命中率；同时对自动换挡的频率加以限制、为升档设置冷却期。通俗地说，换挡本身会产生额外成本，因此系统不会频繁换挡，以免把省下的部分重新付回去。

按使用场景编队。

绘而码按任务场景预先编好若干支 AI 工作组，各自的适用边界如下：

• 免费工组：日常提问、文字润色与图片识别，是不占用积分的基础通道。
• 轻型工组：改文档、写片段、查资料、做摘要这类随手可完成的轻任务。
• 标准工组：多数日常办公、学习与创作任务的推荐选择，兼顾响应速度与处理复杂请求的能力。
• 工程工组：完整项目与交付级任务，需要规划、实现、测试、审查分头把关时使用。
• 同系工组：由同一品牌、同一系列的模型编成，适合超长文档的连续改写、大批量同构任务，以及对输出风格一致性要求较高的内容工作。同系列模型的能力边界与表达风格高度一致，因此长任务中输出不易出现前后跳变；若上游厂商的缓存策略支持同系列前缀复用，换挡带来的额外成本可能更低，个别环节不可用时还可在同系内部顺延。
• 自建工组：面向有明确偏好的用户，可自行配置模型、设定档位与规则，把验证过的班底固化为长期复用的配置。

这几支工组的划分依据并不完全相同：免费看的是是否计积分（积分是绘而码的使用计量单位），轻型与标准看的是投入强度，工程看的是任务形态，同系看的是所用模型的来源，自建则是把配置权交给你。按当下最在意的那一点选择即可，不必把它们放进同一个坐标系比较。

需要与「直接选模型」区分开：指定单个模型是把任务交给某一个确定的模型，价格与行为完全可控；选择工组则是把整套调度决策交给一支预先配好的队伍，任务在不同档位与模型之间如何流动由系统决定。这两种方式在输入框里只能二选一：一旦指定了单个模型，工组的自动调度就不再介入。

实现价值

• 在成本控制与质量保障之间取得平衡。 文档修订、资料检索、片段撰写、内容摘要等日常请求由低档模型承接，高能力模型不被用于低复杂度工作，积分的消耗因此与任务难度相匹配（以实际的 token 用量与档位计价为准）；一旦任务变难，卡壳信号会触发升档，困难请求在多数情况下不会停留在能力不足的档位；复杂度回落后工组又主动降档，收尾阶段继续由更经济的档位承担。
• 长会话的成本更可预测。 在厂商缓存策略不变、且不频繁跨模型切换的前提下，稳定内容前置与克制的换挡能让同一段对话中反复发送的上下文持续获得缓存折扣；同系工组因模型规格一致，在条件允许时这一优势更明显，长时间、大体量的改写任务不易出现成本随轮次显著攀升的情况。
• 结果可预期、可复用。 同一类任务选用同一工组，路由行为、输出风格与响应特性保持一致，效果可预判、可比较、可复盘；自建工组把验证过的配置固化为具名班底，个人与团队可以长期复用同一套选择。
• 交付流程更完整。 工程工组让规划、实现、验证、审查由不同角色分别承担，单点失误的概率降低，问题更早暴露；需要上线的成果经过多个立场分别把关。但角色分工不等于独立审计，最终结论仍需使用者确认。

概括地说，工组降低了使用者理解模型路由、档位调度与缓存机制的成本，并在多数场景下同时兼顾成本、速度与质量兜底；这些判断默认由自动挡完成，无需用户干预。复杂的调度留给系统，简单的选择留给用户。

使用建议

• 若感到回答过于简略，或任务难度突然提升，可以切换到投入更高的工组；收尾与简单事项交给更轻的工组更划算。回答变简略也可能是长会话中历史被压缩所致，未必等于档位不足，换档前先确认任务本身是否变难。
• 频繁切换工组或锁定配置，会使已经积累的上下文重新发送，成本随之上升、响应变慢；常规场景建议交由系统自动换挡。
• 需要严格控制支出，或者对数据隔离、结果由同一模型完全复现、响应延迟有硬性要求时，直接指定单个模型更合适：此时单位价格可预期，但总支出仍取决于实际的 token 用量，且不再享受自动兜底。
• 工程工组由项目长按角色分工协作把关，流程更完整、耗时也更长；一次性简答与轻量咨询建议先用轻型或标准工组。
• 自建工组建议先用现成工组运行一段时间，摸清自己任务的难度分布与风格偏好，再据此固化配置。
• 自建工组会用到第三方模型，这些模型各自规定数据如何使用、内容可用到什么程度，选用前建议先确认，相关合规责任由使用者承担。
• 模型会更新、也可能下线，固化下来的配置隔一段时间值得复核一次，不必指望一次配置长期不变。

相关词条

免费工组 · 轻型工组 · 标准工组 · 工程工组 · 同系工组 · 自建工组 · 智能换挡 · 自动挡 · 积分 · 绘而码

工程工组是绘而码面向完整项目与交付级任务的一支工组。它不是“换一个更强的模型”，而是把任务交给一支有分工的 AI 班组：由一名项目长统筹调度，指挥多名各司其职的专家，分别承担实现、测试、调研、审查、验证、排障等不同立场。通俗地说，工程工组是一支可按需组建的专家团；用户把需求交给它，任务如何拆解、派给哪一类专家、先后与并行怎样安排，都由组内协调完成，用户不必亲自分派，也不必先弄懂该找谁。

技术背景

单一模型一次性输出，很难同时胜任交付级任务里的多种立场：既要有人把功能写出来，又要有人独立地测试它、审查它的风险、验证界面是否真的可用、出问题时定位根因。把这些立场压在同一趟生成里，它们容易互相挤占，也缺少相互校验；同一个模型既当运动员又当裁判，问题常常被一并带过。业界为此发展出多智能体工作流（Multi-Agent Workflow）：把一个复杂任务拆成规划、实现、验证、审查等环节，由多个各司其职的角色协同完成，CrewAI、AutoGen、MetaGPT 等开源框架即属这一方向。

工程工组把这一思路收拢成用户可以一次选用的对象：选定它，就是把任务交给一套预先编排好的分工班底，而不是交给单点的模型输出。它与只挑一个模型的用法是两条路。挑单模型，是完全可控、价格与行为固定、由你自己把握每一步；工程工组则把“谁来做什么、按什么流程协作”交给项目长协调，换来的是多立场分别把关的流程完整性。前者换来可控，后者换来分工。

设计思路

工程工组的运转可以概括为一句话：项目长负责调度与汇总，动手的执行交给对应角色的专家。 支撑它的是几条相互配合的分工原则。

项目长只调度，不亲自执行。 项目长是这支班组的协调者：它理解需求、拆解任务、把每一项活指派给合适的专家，最后汇总产出；它自己不直接写业务代码、不直接跑命令。凡是要落笔改文件、执行命令这类动手的动作，都要通过委派交给对应角色的专家去做。这样安排的用意，是让统筹者专注于全局的拆解与把关，而不被具体实现分散；具体执行则落到那个带齐了相应工具、同时也被限定在相应权限里的角色手上。必要时，项目长可以把某个还不到位的结果再交回对应的角色重做，之后再统一汇总。

按任务需要派对应角色，可以并行协作。 工程工组的专家各有明确职责：工程师实现和修改代码；QA 运行测试与构建、收集整理验证结果与证据；调研员做前期摸底、代码定位与依赖梳理，必要时还能联网查证外部资料、检查运行环境；审查长审查代码、识别风险并提出改进建议；验证员从界面与端到端的角度走查、复现可视化问题；排障员复现故障、定位根因并给出修复建议。项目长依据任务实际涉及哪些环节，决定派哪几类角色、派几名；彼此独立执行、各交各的产出，必要时可同时并行多名，而不必事事排成一条长队。为防止力气花在重复的活上，短时间内对同一件事的重复指派会被拦下。

各司其职，权限各有限定。 每个角色只开放完成本职所需的工具，而不是什么都能做。能改动业务代码的只有工程师；调研员、审查长、验证员、排障员等以读取和验证为主，其中审查长的审查又独立于执行者，不与被审的改动混在一处。这种最小化的权限划分，让“谁能改、谁只能看”有一条清晰的边界，既降低了越权误改的风险，也让每个角色的产出天然落在它该负责的范围内。

实现与把关分开。 工程工组把写实现和做校验交由不同角色承担：工程师只负责把功能实现出来，QA 负责写测试并把它跑通，两者的结论并不合并成一个自说自话的结果。立场分开之后，问题更容易在交付前被另一双眼睛发现，而不是被同一个执行者一并带过。不过要如实说明：这种分工并不等于独立的外部审计，各角色仍出自同一套系统，最终成果仍需使用者自己确认。

独立上下文，跨对话各自成团。 同一支班组是按对话组织的：在一个对话窗口里用到的每个角色，都会绑定一位相对固定的成员，不同窗口之间不复用同名成员；每位专家独立执行、只带着与本职相关的信息工作，彼此不共享上下文。这一方面让不同任务之间互不串味，另一方面也减少无关内容对单个角色的干扰。

简单的问题不惊动专家团。 并非每次提问都会启动一整套委派流程。遇到设计咨询、原理讲解、代码问答这类不需要产出文件的纯问答，项目长会直接作答，不组建专家团、不产生落盘动作。只有当任务确实需要动手实现与多环节把关时，才展开完整的分工流程。这让轻量请求不必为一句咨询也付起重流程的代价。

实现价值

• 交付级任务的流程更完整。 实现、测试、审查、验证、排障由不同角色分别承担，单点失误的概率降低，问题更早暴露，需要交付的成果经过多个立场分别把关，而不必把一整件复杂事压进一次性输出。
• 权限与职责边界清晰。 改动业务代码的权限收敛在工程师一处，调研、审查、验证、排障等角色以读取和验证为主，审查独立于执行，越权误改与自我背书的风险随之下降。
• 过程可追溯、结果可复核。 每位专家的产出分别呈现，谁做了哪一步、给出什么结论都各自留下，便于使用者回看、逐项确认，而不是面对一整块无法拆分的输出。
• 投入与任务形态更匹配。 需要多立场把关的重任务才展开专家团，纯问答类请求由项目长直接回答，避免为轻请求强行走成一套重流程。

概括地说，工程工组把“多智能体协作”这件本就复杂的事，收敛成使用者可以一次选用的班底：分工、调度与把关留在组内，用户只管把需求交给它，并在交付时确认结果。

使用建议

• 工程工组适合完整项目、交付级、需要把规划与实现、验证、审查分头把关的任务；一次性简答、轻量咨询交给更轻的工组更划算。
• 班底分工多、协作链路长，工程工组在把流程走全的同时也更耗时；追求快速一问一答的场景不宜首选它。
• 工程工组不向使用者提供档位选择，任务在角色之间如何流动由项目长协调；你无需指定谁先谁后，把目标讲清楚即可。
• 若只是问设计思路、原理或某段代码的含义，项目长会直接回答；要它动手产出时，请把可实现的目标与落点交代清楚，好让它判断该派哪些角色、把任务拆到什么粒度。
• 需要严格控制支出、要求数据完全隔离、或希望结果由同一个模型逐字复现时，直接指定单个模型更合适；工程工组换来的是流程完整与多立场把关，而非单点可控。

相关词条

工组 · 轻型工组 · 标准工组 · 免费工组 · 同系工组 · 自建工组 · 智能换挡 · 自动挡 · 积分 · 绘而码

标准工组是绘而码面向日常主力任务的一支工组，内部有五个档位，由系统在档位之间自动调度，从低到高依次是轻量、经济、标准、增强、性能。问答与资料检索、文档处理、代码改动等日常任务都可以交给它：选定工组后不必判断当前请求该落在哪一档，需要固定行为时也可以手动锁定其中一档。

先把几个概念的关系说清：工组是使用者选择的那一支班底，档位是一支工组内部的投入层级，自动挡不是第六个档位，而是「不锁定、把定档与升降交给系统」的那种用法，智能换挡则是自动挡背后那套判定机制的统称。另外要提醒一处重名：「标准工组」是工组名，「标准」又是它内部第三档的名字，两者不是一回事；本篇不改动档名本身，需要区分时用序号说「第三档」，其余靠上下文辨别。还有一样东西容易和档位混起来：每个档位内部另有更细的投入层级，它不是档位、也不跨档，本篇不展开它的名称与对应的执行体。

技术背景

一支工组之所以要在内部再分档位，根源是模型能力与使用成本之间的对应关系：能力更强的模型把困难环节做成的把握更大，单位代价也更高；更轻的模型代价低，但撑不住硬骨头。把所有请求都压到同一档，要么成本过高，要么能力不足。

为此业界有两条相互配合的路线。模型路由（Model Routing）解决「从哪一档起步」：先判断请求的难度与所需资源，再分配到匹配的档位。模型级联（LLM Cascading）解决「做不动怎么办」：先由较轻的档位承担，不足时逐级上升，FrugalGPT（Chen、Zaharia、Zou，arXiv:2305.05176，2023）是这一策略的公开研究之一。标准工组并不是那篇论文的照搬：这一类级联思路多为同一条请求先交给较轻的模型、不满意再交给更贵的模型逐档重试；标准工组的做法是在同一段对话内按运行情况上下调整档位，并延续已有的上下文，已经做成的部分不推倒重来。这里的「延续」指任务状态与已有结论保留，不保证输入侧的缓存不失效（跨档时仍要重发一次，见下文代价）。

换挡本身是有代价的。大模型按输入与输出的 token 计费，提示词缓存（Prompt Caching）会对稳定的输入前缀给出折扣，而跨档切换会清空已经建立的缓存、把上下文重新发送一遍。所以一支分档的工组必须同时管理换挡的频率与收益，否则档位带来的节省会被切换开销抵回去。标准工组就是这两条路线在绘而码中的落点：起点由系统判定，执行中按信号升降，使用者侧只保留「选哪支工组」这一次选择，以及必要时锁定档位的权力。

设计思路

标准工组的设计目标可以概括为：把五档之间的取舍收进系统，让使用者只面对一支工组。 支撑这一目标的是五条原则。

定档就低，判不准时更低。

请求进入标准工组时先做一次静态评分：只看这条消息本身能看到的特征，量的是消息长度、涉及几个文件路径、有没有出现重构迁移这类复杂度关键词、有没有分多步骤陈述，以及整体表述的复杂程度；要用哪些工具、希望什么输出格式都不参与评分。特别简单或明显困难的请求据此直接定档：所谓明显简单，是消息很短、只涉及一处、没有列出步骤，也不含实现、修改这类需要理解代码的说法；用户明确限定「就改这一处」时，即使背景写得很啰嗦也不会因此被判成复杂任务。落在中间地带的再由一个独立的判定环节按任务原文复核一次并给出把握度，这个环节不叠在每一个请求上：两端能定的请求不花这次额外判断；把握度不足就不采纳复核结论，直接采用静态评分的兜底档，兜底只在较低的两档里选，不会再往下压一档。这里的「就低」是相对评分结果偏低，不是无脑取最低档：难度明显的任务会直接落在较高的档位。

连续对话的取档另有一条规则：短时间内接着上一轮继续问，会沿用上一轮定下来的档位，免得每换一句话就重判一次导致来回震荡；如果接着问的只是极简问题，这一轮会临时落到更省的档位执行，做完照常回到原档。

受阻先在档内加投入，加到顶仍不够才跨档。

每个档位内部还有更细的投入层级，只能逐级上移，不会跳级，它和跨档是两件事。而且并非所有失败都算「这一档撑不住」，报错会先分病因：限流、超时、网络这类资源问题去切备用执行体重试，不算能力失败；引用的文件或符号找不到属于信息不足，先要求补探查；同一个报错反复出现说明方向可能错了，要求停下重新规划；内容被安全规则拦下则直接终止，既不升档也不重试。判为能力不足且连续几轮如此，才把当前档位的投入层级往上提一级。这一层的变化不重发整段历史，因此不产生跨档那种重建代价；它的单位价格也不变：同一档位内部的几个投入层级共用同一个执行体与同一份牌价，变的只是投入开关。但更高的投入意味着产出更多内容，而这些内容都算进输出、按输出单价计费，所以档内加投入省下的只是重发那一笔，并不是白加；部分厂商侧切换投入开关还会让已建立的缓存重新开头，这一项代价目前不计入那道代价账。变化时对话里会留下一行提示。本档最强的投入层级用尽后仍然连续受阻，这一轮才被记为「无进展」，进入跨档评估。

升档看推进，降档看顺流。

换挡依据的是可观测的执行情况，而不是主观感受。判断「这一轮有没有实质推进」只看到一层：本轮的工具调用是否全部正常返回。这条判据有两层局限必须说清。第一层：工具正常返回不等于拿到了你想要的结果，读错了文件、返回了不匹配的内容，只要没报错就算有推进；反过来，它也不会因为答案写得不好而升档。换挡只判断任务有没有向前走，不评判答案内容本身是否正确，不要指望系统能发现答错了，答案的核验仍然由使用者负责。第二层更关乎使用者：完全没有调用工具的那一轮，会被直接计为有推进。写方案、改文案、做分析这类纯文本任务因此不会因为答得不好而自动升档，档内投入也不会自动加大（加大投入同样需要失败信号才触发）；连你的不满与纠正也不参与换挡判定，它只改变当轮的做法。反而这些顺流轮会被计入降档信号：一段以纯问答为主的会话，若当前不在最强投入上，连了几轮就可能被判为能力有余而自动下沉。所以纯文本类任务的档位主要靠你自己调：要么手动锁到更高的档，要么换用投入更高的工组。

两个补充。定档判轻了的请求不会硬等几轮：第一次工具执行结束后，如果发现工具报错或返回的内容体量远超预期，系统会当场补一档并告知你，这是给初始判断的纠错口子，目前只在偏低的判断上开、反向不开。降档看的是反向信号：在并非最强投入的情况下连续更多轮顺流推进，说明当前档位能力有余，工组会逐档下沉；下沉之前同样先在档位内部把投入层级收回更省的一级，并要求连续几轮平稳且无事才算放行，跨档之后还有一段按轮次计算的冷却，避免短暂顺利几轮就降、紧接着又遇难点要升的这种往返。

换挡先算代价，算不过来的那一步不由系统替你决定。

自动升档前，系统会按这一次任务处理过程中已经产生的输入与输出估算一次重发代价（历史输出比历史输入计得更重），只算这段任务自己的量、不参考同类任务的历史实际消耗。过程做得越久、积累越多，估算值越大；超过那条线就不自动升档，而是在对话里给出提示，确实需要时要你手动指定目标档才会升上去。这不是把升档永久关掉：只要还需要升档，之后每一轮都会重新算这笔账，而同一段任务里的累计量只增不减，所以被拦过的会话后面基本都得你手动决定。降档同样要过这道代价账，且降档的线比升档宽得多：判定该降但重发损耗过大时也会先不降。

防止档位来回跳动的是同一个闸口，它依次拦三件事，不是三选一：同一次任务处理过程中已经完成的「升上去又退回来」循环达到两次，第三次就不再自动上升、转为提示你手动决定；整段会话累计的跨档升档次数达到上限，这个上限恰好等于从最低档一路走到最高档所需的跳数，达限后升档动作停手并告警；处于冷却窗口内不触发同向升档，刚发生过升退循环的窗口会翻倍。三者的关系是：升退循环只要发生过一次，就先落入翻倍的冷却窗口（窗口内不升）；要累计到两次，才彻底转为只提示不自动升。冷却一律按对话轮次计算、不按时间，既防止任务难度反复波动时档位来回跳动，也限制了缓存被反复失效重建的次数。换挡一律可见，但可见的程度不同：常规换挡留下的是一行记录，跨档切换会显示升降的方向与大致代价，档位内部的层级调整也是如此；只有当升档被代价账或防震荡闸口拦下时，才会额外给出需要你决定的建议性提示。任何一次升降都不会静默发生。

容量和档位是两件事。

五个档位的上下文容量是一致的，更高的档位不等于能装下更多历史。当一段对话的上下文超出容量上限时，工组的做法是压缩历史消息并保留任务要点：最近的若干轮保留原文，更早的部分压成摘要，必要时提前给出提示，而不是靠升档来腾出空间（各档容量相同，升过去也装不下）。这里有两处副作用必须知道：摘要不等于原文，被压掉的细节此后系统就看不到了，后面用得上时要你重新提供；压缩会重写这段历史，已经建立的缓存就要重建一次。压缩不会让换挡判定从头开始，升降的连续轮次照常累计。

五个档位从低到高，定位如下（同一任务落在不同档位，单位积分消耗通常随档位上升而增加）：

• 轻量：短问短答、格式化改写、单点的小改动，是工组内单位消耗最低的档位。
• 经济：日常主力档位，文档修订、资料检索、内容摘要与中等规模的改动通常由它承担。
• 标准（第三档）：需要多步骤推进与连续工具调用的任务，也是较低档位受阻后的常见落点。
• 增强：复杂调试、跨文件的改动、需要更长推理的分析工作。
• 性能：困难任务与对成果质量要求较高的场合，单位消耗最高，一次性简答不值得使用。

与轻型工组、工程工组横向对齐：档位与调度上，轻型工组只有三档、跨度较小，标准工组有五档、跨度最大，工程工组不分档而按角色流程推进；适用场景上，轻型工组适合随手可完成的轻任务，标准工组适合难度不齐的日常主力任务，工程工组适合需要交付且希望规划、实现、验证、审查分头把关的任务；投入特征上，轻型最省，标准工组随档位递增，工程工组因角色更多而整体投入更高。介于标准工组与工程工组之间的那类任务，判据是是否需要把规划与验证拆给不同立场分别把关：需要就交给工程工组，只是难度大则留在标准工组由自动挡升降。两样同时成立时以是否需要分头把关为准：难度可以由档位解决，分头把关不可能靠单条执行链路实现。标准工组内部始终是同一条执行链路在推进，并不存在多角色分工；真要分角色请选工程工组。相关机制见「智能换挡」「自动挡」与「工组」。

实现价值

• 一次选择覆盖全部难度。 从一句话的提问到需要连续推进的复杂任务都可以交给同一支工组，档位由系统判定，使用者不需要理解五档的差别，也不会因为选错档位而付了不该付的代价。
• 花费与难度相匹配。 定档取向就低、受阻才上移，常见的简单与中等任务一般停在较低档位，高消耗档位只在真正需要时出现；你不必为了省钱刻意压低任务，也不必担心简单问题被送到贵的一档。
• 困难环节有兜底，加钱不静默。 受阻时先在本档加大投入、再逐档上升，回落后自动下沉，你不在场也能推进；会多花投入的升降都会留下可见记录，代价过大时不擅自上去、而是先停下来问你。
• 长会话的行为可以理解，自动与可控可以随时切换。 上下文涨到上限时压缩历史而不是悄悄换档，你对「这一轮为什么变简略」有明确的判断依据；需要固定行为与可预期单价时锁定档位，不需要时交回自动挡。

概括地说，标准工组把「该用哪一档」这件事从你面前移走。档位由系统挑选，工组由你挑选。 日常任务直接选标准工组、保持自动挡即可。

使用建议

• 日常主力任务交给标准工组并保持自动挡即可；只有当你明确知道任务属于哪一档、或需要可预期的固定单价时，才手动锁定。但写完一段方案、改一段文案、做一类分析这种全程不调工具的任务，不会因为答不到点上而自动上移（机制见上文）；觉得当前档位不够用时，直接手动锁到更高的档或换用投入更高的工组，不必等系统自己上去。
• 自动挡多数情况下更省，但不是永远：任务一开始被判得偏轻、随后连续受阻，工组会一档一档往上走，加上每次跨档换挡都要重发上下文，总花费有可能高于直接从合适的档位起步；一段任务里反复上移又回落时，最坏情况是每一档都做过一遍功、每次都重发一次。看到「自动升档被拦」或「跨档升档未执行」这一行提示时，先结合任务还剩多少步判断是否真有必要；确实要升，手动指定目标档即可。
• 锁档的代价与边界：改变所在档位（从不锁改锁、或从一档改锁另一档），这段会话已建立的缓存会失效重建；锁回的就是当前所在档位时通常没有这笔额外重发，但锁档会把该档位内部的投入层级复位到它的常规起点，若此前已经加过投入，这次复位同样可能带来一次重建。锁定之后自动定档、自动降档、档内自动加大投入都会暂停（切回自动挡即恢复），遇到超出该档能力的环节不会擅自往上加钱，只给一行提示由你决定；唯一还会发生的自动上行，是第一次工具执行发现任务比当初判定更复杂时的那次补档。所以锁档不等于这一档绝不会变，要真正可预期还得选对档位。
• 一次性简答、简单改写与轻量咨询交给免费工组或轻型工组更划算。回答变简略、推进不顺时，原因可能是任务难度超出当前档位，也可能是长会话历史被压缩了、需求描述发生了变化，或者只是模型当次输出的波动与工具服务的临时异常，不必一律归结为档位不足；先确认任务本身是否变难，再决定锁更高档位或换用投入更高的工组。
• 两种走向。顺流的那种：一段对话先做资料摘要，几轮顺流停在较经济的档位；接着要改一处跨文件的代码，工具调用连续失败，投入层级先在本档加一级，仍不够才上升一档继续推进；改完后回到普通问答，几轮顺流之后又降回原档，全程不需要你干预。被拦下的那种：一段很长的会话改到后半程开始反复报错，工组判定该升一档，但重发整段历史的代价已经过高，于是这一轮不升、在对话里留下一行提示；你看了还剩两步，手动指定目标档，事后由你决定何时切回自动挡。

相关词条

工组 · 智能换挡 · 自动挡 · 免费工组 · 轻型工组 · 工程工组 · 同系工组 · 自建工组 · 积分 · 绘而码

轻型工组是绘而码面向轻量任务的一支工组，内部有三个档位，由系统在档位之间自动调度，从低到高依次是一档、二档、三档。它的定位是快：三个档位配置的都是更小的模型，单位代价更低、反应更快，适合随手可完成的提问、单点的小改动、资料查询、短平快的代码活儿。选定工组后不必判断这一轮该落在哪一档，需要固定行为时也可以手动锁定其中一档。

先把几个概念的关系说清：工组是使用者选择的那一支班底，档位是一支工组内部的投入层级，自动挡不是第四个档位，而是「不锁定、把定档与升降交给系统」的那种用法，智能换挡则是自动挡背后那套判定机制的统称。轻型工组与标准工组都分档、都走这一套思路，但档位数量与档名不同：轻型三档，档名就是序号式的一档、二档、三档；标准五档，另有五个专名。还有一处结构差别要说在前头：轻型工组内部没有比档位更细的投入层级，它的换挡只有跨档这一件事，一次走一级；升降档的完整机制见《标准工组》。

技术背景

轻型工组之所以要在内部再分档位，大前提与所有分档工组一样：能力更强的执行体把困难环节做成的把握更大，单位代价也更高、起步也更慢；更轻的执行体代价低、反应快，但撑不住硬骨头。属于轻型的那一半问题是它承担的任务大多很简单。如果为了少数干不动的活把所有请求都压到高档，绝大多数请求就在为一件不需要的事付等待和代价，「快」这个卖点会被自己抵消掉。所以轻型必须同时做到两件事：把随手可完成的活留在最轻的一档，把偶尔干不动的活尽快送上去。

换挡本身是有代价的。大模型按输入与输出的 token 计费，提示词缓存会对稳定的输入前缀给出折扣，而跨档切换会清空已经建立的缓存、把上下文重新发送一遍。轻型对这件事的回应比标准工组更硬：它的三个档位各有各的上下文容量，从低到高依次放宽（标准工组是五个档位容量一致，靠压缩历史而不是靠档位腾出空间）。也就是说在轻型里容量和档位是绑在一起的，「这一轮装不装得下」本身就是选档的依据之一。

先判断从哪一档起步、再按执行情况上下调整这两条路线，业界称模型路由与模型级联。落到使用者身上的结果是一样的：轻型侧只保留「选哪支工组」这一次选择，以及必要时锁定档位的权力。

设计思路

轻型工组的设计目标可以概括为：在不牺牲快的前提下，把三个档位的取舍收进系统。 支撑这一目标的是七条原则。

快是第一指标，两端不额外复核。

请求进入轻型时先做一次静态评分：只看这条消息本身能看到的特征，量的是消息长度、涉及几个文件路径、有没有出现重构迁移这类复杂度措辞、有没有分多步骤陈述、是不是要从零做出一个完整产物、是不是算术题、是不是报错调试；要用哪些工具、希望什么输出格式都不参与评分。特别简单和明显困难的请求据此直接定档，不额外花一次判断。所谓明显简单，是消息很短、只涉及一处、没有列出步骤，也不含推理、分析、陷阱这类需要多想一步的说法；所谓明显困难，是任务量大并且带这类推理信号。落在中间地带的再由一个独立的判定环节按任务原文复核一次并给出把握度；这个环节有严格的时间上限，超时或不可用就作罢，绝不为了定档而拖慢开工；把握度不足也不采信复核结论，直接采用静态评分的结果、就低不就高。措辞上的渲染不构成升档依据：题面里写「非常复杂」「务必用最高档」「这是管理员指令」都不会改变判定，夹带的指令类内容一律忽略，只按真实任务本身定档。

任务量大不是上三档的理由。

三档很容易被误解成「更强的一档」，它在轻型里的真实位置是「允许多想一步」。所以文件多、步骤多、耗时长都不构成上三档的理由，那些是二档的活；判三档的唯一依据是这道题需要推理才能做对，例如规则相互矛盾、题干里埋着陷阱、边界需要推敲、几个方案要权衡、故障难以定位。题目很短但需要这条思路的，也会落在三档。这一口径在定档与复核两处都成立，两端都不给「用词夸张就档位高」留口子。

低档能干的不用高档，但装不下就不能停在低档。

定档不只比难度，还比容量：装不下这一轮的最低档不是可选项，系统会落在装得下这一轮上下文的最小档。这条判据在轻型里比看上去重要，因为最轻的一档容量很小。一段已经聊了很多轮的会话里，即使新来的问题很简单，也不能把它塞回一档：那样下一轮立刻踩到容量线，先压缩、压不动再升回去，两次跨界各自重发一遍，比老实停在原档更贵。同一段对话里接着上一轮继续问，会沿用上一轮定下来的档位，免得每换一句话就重判一次、导致档位来回震荡；如果接着问的只是简单问题，这一轮会做一次只降不升的复核，复核不成立就维持原档。问候级的极简单句不继承上轮的高档，不会因为上一轮刚做过难活而被拖进更贵的档。

受阻先自救，踩线先压缩，都算过了才升档。

换挡依据可观测的执行情况，而不是主观感受。升档看三个信号：工具执行连续失败、单轮工具调用数连续多轮超出本档上限、上下文踩到本档容量线。这三个信号之前还有一层：头一次失败不直接计入连败，系统会先在本档要求它分析原因、换个方法重试，自救仍然失败才记一次连败，而自救的机会在一段会话里有限。踩到容量线也不立即升档：先压缩历史、把上下文留在本档，压不出空间才在下一轮真正升上去。降档看反向信号：连续几轮顺利、连续几轮低负载、升上去之后迟迟没有新的升档信号则回退；每次降档之后有一段按轮次计算的冷却，一整段会话的自动升档次数也有上限，防止任务难度波动时档位来回跳。换挡判定只看执行侧、不看答得好不好，这里有一处容易误判的边界：完全没有调用工具的那一轮会被记为顺利。写方案、改文案、做分析这类纯文本任务不会因为答得不好而自动上移，你的不满与纠正也不参与换挡判定；反过来，这些顺流轮会被计入降档信号。

换挡要算代价，所以降档比升档慢。

既然每次跨档都要重发上下文，轻型对往下走格外谨慎：判定为会清空缓存的降档与回退，要求双倍的信号才执行，而升档不设这道加倍闸（升档多由连续失败、容量吃紧这类硬信号触发、偏紧急；降档只为省钱、还要防档位来回跳）。因此降档明显比升档慢，这是有意的取舍，不是缺陷。降档还多一道容量闸：更低一档的容量线已经被当前上下文踩到，就不降，等压缩把上下文降下来再说。这里的「低负载」指的是只用了一两个很轻的动作、且都顺利的那几轮。任何一次升降都不会静默发生：换挡前会先在对话里给出一行预告，换挡处会留下一张标明方向与档名的卡片。

一档的动作面是收窄的，整支工组都不派子代理。

最轻的一档定位为「问路级」：只给它只读与检索类的动作，读文件、列目录、搜索、查网页、向用户提问这一类；写文件、执行命令、操控浏览器都不在这一档的能力面里。收窄有两个理由，一是它的容量很小，把所有动作清单声明一遍就要吃掉大半预算；二是这些动作本来就不该由最轻的执行体承担。要提醒一条真实的边界：被裁剪的正是自动挡的一档，所以一句很短的「把某文件那一行改一下」如果被定到这一档，它手上并没有写文件的动作、做不了这一步；真要落笔改文件或执行命令，锁到二档最稳妥，那里动作齐全。这条裁剪只在自动挡的一档生效，手动把档位锁在一档时拿到的是完整的动作清单。另外，轻型工组整支都不承担「把活派给子代理、多代理编排」这类分工：这些动作在轻型的清单里根本不给，模型凭习惯直接调用也会被拒绝并说明原因。需要规划、实现、验证分头把关的任务，请交给工程工组。

遇到不可用和余额不足，只往下走，不往上走。

某一档对应的执行体被停用时，系统就近换到还能用的档去跑，而不是让这一轮撞在死档上；如果三个档全都不可用，会明确拒绝这一轮并告知暂无可用模型，而不是让你逐轮重试。上游因余额或额度不足拒绝某个档位时，系统会自动降到更省的档重试并说明原因，此后这一段会话不再自动升档，否则刚降下来又被顺利信号顶回去、撞上同一处不足。

三个档位从低到高，定位如下（同一任务落在不同档位，单位代价通常随档位上升而增加）：

• 一档：问候、闲聊、直接回答、单点事实查询、读完就能答的问题，不需要多步骤工具协作、也不落笔改文件的那一类。
• 二档：干活的主力档位。单个或少量文件的常规开发与修改、资料检索与分析、多步骤但路径清楚的活都归这里，任务量大也仍然在这里。
• 三档：兜底档位。它不比二档更能干，只是被允许多想一步，专门留给「不多想一步就做不对」的情形。

与免费工组、标准工组、工程工组横向对齐：适用场景上，轻型适合随手可完成的轻任务，标准工组适合难度不齐的日常主力任务，工程工组需要规划、实现、验证分头把关；结构上，轻型三档、无档内层级、容量按档递增，标准工组五档、另有档内更细的投入层级、各档容量一致，工程工组不分档而按角色流程推进。论单档能力，轻型最高的三档大致与标准工组最低的轻量档相当，整支轻型因此坐落在标准工组能力起点的下方，是一条专为轻活准备的更低坡道。在轻型和标准之间犹豫时，判据是这一件事是否随手可完成：需要连续多步推进、跨文件改动、或对成果质量要求较高，就交给标准工组由五档去承接。相关机制见「智能换挡」「自动挡」与「工组」。

实现价值

• 随手活真的快，也不必为难活买单。 两端直接定档、零额外判断，中间地带那次复核有硬时间上限、判不准就往低走；最轻的一档还额外收窄动作面，把省下来的容量留给对话本身。
• 档位少，行为更容易预期。 三档、没有档内层级、跨档一次一级，「这一轮为什么是这个表现」在轻型里比在五档工组更容易说清；容量按档递增意味着长会话会自动往装得下的档走，而不是靠悄悄降质来腾地方。
• 花费与任务相匹配，加钱不静默。 就低不就高、量大不上三档、受阻先自救、踩线先压缩；每一次换挡都有预告和记录，上去之后没有新信号还会自己退回来。
• 能力边界是明说的，不是藏着的。 一档不做写入与执行、轻型不做子代理分工；需要换档时系统会按容量与受阻信号把它择到做得动的档，择不过去的由你手动升档或换一支工组，而不是让你在同一个档上等出奇迹。

使用建议

• 随手可完成的活、要求响应快、单点改动、问答与查资料，交给轻型并保持自动挡；难度不齐的日常主力任务交给标准工组，需要分头把关的交给工程工组。纯文本类的活（写方案、改文案、连续追问）不会因为答得不好而自动上移，反而会因为几轮不调工具而往下走；觉得当前档位不够用时，手动锁到更高的档或换一支工组，不必等系统自己上去。
• 手动锁档是可用的，但要知道边界：锁定期间自动定档、自动升降、自救与按档的容量预警都会暂停，遇到干不动的环节不会擅自往上加钱，只给提示由你决定；锁在一档时动作清单不被裁剪（与自动挡的一档不同），而它的容量仍是三档里最小的，长会话更容易吃紧。改变锁定的档位会让这段会话已建立的缓存失效重建。
• 一次要读入很长的文档或大文件正文的任务不该由最轻的一档承担：系统会因容量把它定到更高的档，你也可以一开始就锁在二档。反过来，一句简单的提问不该因为上一轮刚做过难活而落在更贵的档，这种情形系统会在当轮复核降下来。
• 算术与调试类请求不会由最省的档承担：需要多步的算式会被送到更稳的档，单步的简单计算除外；带报错、调试、修复一类说法的请求也不会被直定到最轻的一档。这解释了两件容易被当成故障的事：为什么一句很短的「这个函数报错帮我修」没有飞快返回，以及为什么一道多步算术题落在比你预期更高的档。
• 轻型不做子代理与多代理编排，需要分工把关请选工程工组。看到「已降到更省的档」这类因余额或额度而降档的提示时，这一段会话不会自己升回去，需要上行请手动锁档或换工组；看到「暂无可用模型」时，是这一支工组的三个档都不可用，换一支工组或稍后再试即可。

相关词条

工组 · 标准工组 · 自动挡 · 智能换挡 · 免费工组 · 工程工组 · 同系工组 · 自建工组 · 积分 · 绘而码

免费工组是绘而码面向日常问答的一支常备工组（也就是你选定的一支 AI 班底），定位是一条不占用积分的基础通道。平时随手提问、文字润色与改写、资料查询、图片识别，都可以交给它，而这几件事不消耗你的积分。它内部同样分档、由系统按任务复杂度自动决定投入的深浅，选定即可使用，你不必判断这一轮该落在哪一档；注册使用者与访客都能用它，但都以每天的使用次数为限、不逐次扣费。

先把几个词的关系说清：工组是你选择的那一支班底；档位是一支工组内部的投入层级；自动挡不是第四个档位、也不是另一支工组，而是「不锁定、把这一支工组内部的定档与升降都交给系统」的那种用法，免费、轻型、标准都支持它。至于「智能换挡」，它是自动挡背后那套自动定档与升降机制的统称，作用范围始终在一支工组之内；工组与工组之间不会自动切换，用哪一支由你手动决定。免费与轻型、标准、工程这四支平台常驻的工组并列，它与其余三支的差别不在「更强或更弱」，而在是否计积分与承担什么形态的活。这里有一条容易混淆的边界要说清：免费做的是「在对话里直接把结果给回你」这一类，问答、润色改写、查资料、识图、联网检索都算。润色、改写只是把结果写在对话里、并不落到你的文件；而写文件、执行命令、改代码、把任务拆给多个角色分头把关这类「要落地动手」的活，免费不做。也就是说，区别在是否落到文件、是否动手执行，不在文字本身改不改。免费与轻型一样分档，但差别有二：一是免费的三档共用同一条上下文长度上限、不随档位放宽（轻型则按档依次放宽）；二是出于成本考虑，免费定档时不额外起一次独立的判定复核。

技术背景

免费之所以单独成为一支工组，是因为「随手就能问、不必为每一次问答算积分」这件事值得单独做成一条常开的通道。大模型通常按输入与输出的 token 计费，而日常问答里绝大多数请求都很轻，为它们逐次计价既打断体验、也不划算。于是绘而码把这一类请求归拢到不占用积分的通道上，改用「每天可用次数」而非逐次扣费来管理它。

实现上，免费复用轻型那套按复杂度自适应的分档思路：一段消息进来，先看它本身能看到的特征（长度、是否列出多个步骤、需不需要多想一步），特别简单的直接落在最轻的一档，确实需要推理的才往上走，落在中间地带的按「拿不准就往低判」处理。与轻型不同之处有两点：一是免费的上下文上限被钉在同一个值上、不随档位放宽；二是更重的工组在定档时还会另起一次独立判定来复核这条消息该给多高，免费为省成本、保响应，只依赖上述这一次静态判断。图片识别另走一条独立的图像理解通道：先把图片读成文字描述，再交给对话去理解和回答，同样不占用逐次扣费。

设计思路

免费工组的设计目标可以概括为：把「不占用积分的日常问答」做稳、做轻，同时把能力边界说清楚，不让人在越界处空等。 支撑这一目标的是下面几条原则。

不占用积分，使用记录仍在。 免费通道的使用不扣你钱包里的积分，但每一次使用仍会照常留下记录，只是跳过扣款这一环。这样「不占用积分」是一条明确的通道属性，而不是无从追溯的免单。

日常问答自动分档、就低不就高。 免费按任务的复杂度自动决定投入，只看这条消息本身看得到的特征来定档：能一句话答清的留在最轻的一档，需要多想一步的才往上给，落在中间地带的就低判。因为免费面向的多是随手问答，系统不为给它定档而额外多起一次独立判定，以免把「快」这个卖点抵消掉。代价也如实说清：就低不就高意味着偏难的纯问答可能被定在偏省的档、想得不够深；遇到这种情形，手动锁到更高的档、或直接改用标准、工程工组即可，不必等它自己往上爬。

只做对话、识图与联网检索，不做要动手的活。 免费给你的是问答、把图片读成文字来理解、以及联网检索这一类能力；写文件、执行命令、改代码、把任务拆给多个角色分头把关，都不在免费的能力面里，需要这些请换用轻型、标准或工程工组。这里说的「动手」，指的是改文件、跑命令、动代码这类要落到你的系统上的操作；识图只是把图片读成文字再据以回答，归在问答这一类，不算动手。把动手类活挡在门外，才能把额度与上限都留给对话本身。

上下文有一个统一长度上限，踩线先自动压缩。 免费给一段对话能同时携带的上下文设了长度上限，三档共用同一个值、不随档位放宽（这里说的是上下文窗口的长度，不是按你发了几条消息来算）。接近上限时，系统会先把较靠前的中间历史自动摘要压缩、保留关键的最近几轮，并把这份摘要转成可在后续召回的记忆，也就是说早先的内容不是直接删掉、而是浓缩保留；不过浓缩成摘要后，较早的细节未必都还完整，重要信息建议再给一次，你一般无需为此手动新开会话；如果压缩后仍然超限，会明确告知这条上限，请你精简过长的粘贴后再问。

有按天的次数额度，用完给明确的下一步。 免费以「每天可用的次数」而非逐次扣费来约束：注册使用者有一份按人、按本地日重置的对话额度，访客则按来源各自另有一份额度，到次日 0 点重置。一次指一轮问答（你发一条、免费答一轮），不会因为这一轮答得长、或内部多查了几次而重复计数。图片识别另有自己的一份按天次数，对话次数与识图次数是两个独立的每日额度、互不挤占。额度用完时不会让你撞上无声的失败，而是提示你可以切换到其他工组用积分继续，或等次日重置再来。

与轻型、标准、工程横向对齐：免费是不占用积分的入门通道，适合随手问答、润色改写、查资料与识图；轻型会占用积分、以「快」为先，三档容量随档递增，适合随手可完成但要落地的轻活；标准适合难度不齐的日常主力任务，由五档去承接；工程适合需要规划、实现、验证分头把关的交付级任务。在免费与其他工组之间犹豫时，判据有两层：一是这件事要不要落地改动或执行：要写文件、跑命令、改代码，就别留在免费；二是这件事虽不动手、但难不难：纯问答里若要多步推理、长篇推导，免费的静态定档容易压得偏省，这类更该交给承接复杂请求的标准工组（轻型胜在快与省，并不以难任务见长）。纯问答与随手查询留在免费即可。相关机制见「智能换挡」「自动挡」与「工组」。

实现价值

• 随手问答不必先算钱。 日常提问、润色、查资料、识图这类轻活走一条不占用积分的通道，用按天额度而非逐次扣费来管理，问了不心疼，也省掉每一次「该用哪一档、要花多少」的纠结。
• 体验尽量无缝，边界提前说清。 上下文逼近上限时先自动压缩、把摘要转成记忆，而不是让你频繁手动重开；哪些活能做、哪些不做（不动文件、不跑命令、不派子代理）都在工组定位里写明，需要动手时有明确的换组指引，而不是在免费里空等一个做不出的结果。
• 与更重的工组分工清楚、可上可下。 免费坐落在整条能力坡道的入口：够用就留在免费，不够用时切到轻型、标准或工程是很自然的一步，切换的判据也在同一套工组叙述里对齐，不必逐支去猜边界。

使用建议

• 纯提问、文字润色与改写、查资料、图片识别这类只在对话里出结果、不落地改文件的活，优先交给免费，并保持系统自动分档即可，一般不用你干预。
• 看到「今日次数已用完」一类提示时，切换到其他工组用积分继续、或等次日重置即可，不必对同一句反复重试；识图次数与对话次数各自独立，一边用完不影响另一边，额度都在次日 0 点重置。
• 需要改文件、跑命令、写代码、把任务拆给多个角色分头把关，或虽不动手但要多步推理、长篇推导的难题，都不适合留在免费：前者交给轻型、标准或工程工组，后者建议直接用承接复杂请求的标准工组（或工程工组）。
• 一次性粘贴很长的内容可能触到免费的上下文长度上限、被自动摘要压缩或要求精简；压缩后较早的细节未必完整保留，重要内容建议再给一次，或把长文档的连续改写、跨文件推进直接交给标准工组。
• 识图走的是「先把图片读成文字、再据文本回答」这条通道，若图中的关键信息很具体，用文字一并说明一句会更稳妥。
• 访客也能直接用免费，额度按访问来源计；登录为注册使用者后，会改为按你的账户计一份每日额度。

相关词条

工组 · 轻型工组 · 标准工组 · 工程工组 · 自动挡 · 智能换挡 · 同系工组 · 自建工组 · 积分 · 绘而码