必须加四条限制：①输出仅限五列markdown表格；②用例编号为tc-001起连续三位数字；③步骤用动词开头、结果禁用概率性措辞；④缺信息填“待确认”，不编造。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
把测试场景补成用例表时，提示词必须加的限制条件
你正在用Codeium将一句自然语言描述的测试场景（比如“用户未登录时点击支付按钮应跳转到登录页”）自动扩写成结构化测试用例表格，但发现生成结果混乱、字段缺失、步骤错乱或混入非测试内容——这说明提示词缺少关键约束，不是模型能力不够，而是输入没框住边界。
核心限制条件（缺一不可）
在向Codeium发送补全请求前，必须在提示词开头明确声明以下四条限制：
① 【输出格式强制为 Markdown 表格，且仅含且必须包含五列：用例编号｜场景描述｜前置条件｜执行步骤｜预期结果】。不允许添加第六列，不允许合并列，不允许用“-”“*”等符号替代表格线，不接受列表、段落或JSON格式。
② 每个用例编号必须以 TC- 开头，后接三位数字（如 TC-001），编号从 001 开始连续递增，不跳号、不重复。
③ 执行步骤必须拆解为原子操作，每步以动词开头（点击、输入、选择、等待、验证），禁止出现“检查是否…”“确认…”等模糊表述；预期结果必须是可观测、可断言的终端状态（如“URL 变为 /login”“弹窗显示‘请先登录’”），【禁用‘应该’‘可能’‘大概率’等概率性措辞】。
④ 若原始场景描述中未提及具体字段名、按钮文本、URL路径、错误码等信息，不得自行编造——空缺处统一填“待确认”，不准用占位符如 {username} 或示例值如 “test@example.com”。
按项目类型追加的上下文约束
仅当你的工程属于以下两类时，才需在提示词末尾额外追加对应约束：
方法一：HarmonyOS ArkTS 工程
追加：“所有前置条件须兼容 ohosTest/ets/test 目录下的 Instrument Test 运行环境；执行步骤中涉及 UI 操作的，必须使用 UIAbility 的 getTopWindow() + findComponentByTag() 路径写法，不使用 ID 定位。”
方法二：Web 前端（Vue3 + Pinia）
追加：“执行步骤中的‘点击’动作，需对应到 @click 绑定的函数名或 data 属性名；预期结果中涉及状态变更的，必须指向具体的 store.state 字段或 ref 值，例如 ‘store.state.user.isLoggedIn === false’。”
容易被忽略但致命的隐性约束
Codeium 默认会把长场景拆成多个用例，但你真正需要的是“一个场景 → 一张表”，不是“一个场景 → 多张碎片表”。必须在提示词中写明：【无论输入场景多复杂，只生成一张表格，且表格行数不超过8行】。超过部分截断，不换页、不分表、不加“续表”字样——这是防止它把边界条件、异常流、数据组合爆炸式展开的根本防线。
