Codeium测试场景补用例表：提示词限制条件详解
将测试场景转换为用例表时，若提示词未明确几项关键约束，输出极易产生偏差。问题不在于模型能力，而在于输入未有效划定边界。
测试场景转换用例表时提示词必备限制条件
以下四条核心限制缺一不可。
第一条：输出格式强制为Markdown表格，严格限定五列：用例编号｜场景描述｜前置条件｜执行步骤｜预期结果。禁止添加第六列、合并列或用符号替代表格线。不接受列表、段落或JSON格式。
第二条：用例编号须以TC-开头，后接三位数字（如TC-001），从001连续递增，不可跳号或重复。
第三条：执行步骤需拆解为原子操作，每步以动词开头（如点击、输入、选择、等待、验证），禁用“检查是否”等模糊表述。预期结果必须为可观测、可断言的终端状态（如URL变为/login，弹窗显示“请先登录”），禁止使用“应该”“可能”“大概率”等概率性措辞。
第四条：原始场景中若缺少字段名、按钮文本、URL路径、错误码等具体信息，禁止自行编造；空缺处一律填写“待确认”，不得使用占位符或示例值。
根据项目类型追加的上下文约束
两种情况：仅当工程属于以下两类时，才需在提示词末尾追加对应约束。
第一种：HarmonyOS ArkTS工程——追加约束：所有前置条件须兼容Instrument Test运行环境；UI操作使用getTopWindow() + findComponentByTag()路径，不用ID定位。
第二种：Web前端工程（如Vue3 + Pinia）——追加约束：点击动作需对应@click绑定的函数名或data属性名；预期结果中涉及状态变更的，必须明确指向具体的store.state字段或ref值。
容易被忽略却致命的隐性约束
Codeium默认会将长场景拆成多个用例，但实际需要的是一个场景对应一张表，而非多张碎片表。因此必须在提示词中明确：无论输入场景多复杂，只生成一张表格，行数不超过8行；超出部分直接截断，不换页、不分表、不加“续表”。这是防止边界条件、异常流、数据组合爆炸式扩展的根本防线。