先来看一个真实案例——你需要借助Codeium清洗一批订单数据，但提示词写得太笼统，只说了“清洗订单数据”。结果呢？退款订单未被排除、金额未经验证、时间范围未加限定，最终输出的指标全部偏离预期。下面这个例子展示了一份典型的业务规则清单，你能识别出哪些约束是必须硬编码的吗？

必须满足以下全部条件：必须过滤掉status为'cancelled'或'refunded'的订单，否则会导致GMV虚高12%以上；order_amount字段需要先转换为数值再校验是否大于0，非数字值统一设为NULL，否则pandas会抛出TypeError并中断运行；仅处理created_at在2024-04-01至2024-06-30之间的记录，否则会混入测试环境的历史脏数据；输出结果按照user_id分组，返回每个组的sum(order_amount)、count(*)、max(created_at)三个字段，否则指标口径与BI看板不一致。输入为pandas DataFrame，列名固定为order_id、user_id、status、order_amount、created_at，无索引；使用pandas 2.0+，禁用for循环，必须采用vectorized操作；遇到NaN的created_at按照当前日期往前推90天填充，不抛出错误。

然而，如果你在提示词中仅仅写了“清洗订单数据”，Codeium很可能忽略退款单不参与统计、金额必须大于0、时间范围限定在近90天等关键约束。如何避免呢？下面这四种技巧，是经过多次踩坑后总结出的实用经验。

明确列出所有硬性约束条件

在提示词开头使用「必须满足以下全部条件」来引出限制清单，每条独立成行，不合并、不模糊。例如：
必须排除status为'cancelled'或'refunded'的订单；
order_amount字段需转换为数值后校验>0，非数字值统一设为NULL；
仅处理created_at在2024-04-01至2024-06-30之间的记录；
输出结果按user_id分组，返回各组的sum(order_amount)、count(*)、max(created_at)三个字段。

这一步不要写“大致过滤”或“一般要排除”，因为Codeium会忽略“大致”“一般”——它只识别确定性指令。

用「否则」句式明确后果

对每条限制条件，紧接着写一句「否则……」说明违规后果。例如：
订单状态为'refunded'的记录必须剔除，否则会导致GMV虚高12%以上；
order_amount未转数值就聚合，否则pandas会抛出TypeError并中断执行；
created_at未加日期范围过滤，否则会混入测试环境历史脏数据。

Codeium对「否则」引导的负面结果响应更敏感，相比单纯列出要求，更容易触发严格的校验逻辑。

提供带注释的输入输出样例

方法一：贴一段真实输入片段（5～8行），在关键字段旁用#注释其约束含义：

```csv
order_id,user_id,status,order_amount,created_at
ORD-001,U-101,paid,299.99,2024-05-12 14:30:00 # 正常有效订单
ORD-002,U-102,refunded,149.50,2024-05-10 09:15:00 # 必须剔除：status=refunded
ORD-003,U-103,paid,abc,2024-05-08 20:45:00 # 必须转为NULL：order_amount非数字
```

方法二：直接给出期望输出表头及首行结果，并标注计算依据：

输出字段：user_id, total_amount, order_count, latest_order_time
U-101, 299.99, 1, 2024-05-12 14:30:00 # total_amount=299.99（已剔除refunded及非法金额）

【样例中必须包含至少一个被剔除的行和一个被修正的行】，否则Codeium默认所有输入都合规。

声明数据源与运行环境

第一步：说明数据来源格式，例如「输入为pandas DataFrame，列名固定为order_id、user_id、status、order_amount、created_at，无索引」；

第二步：声明依赖与版本，例如「使用pandas 2.0+，禁用for循环，必须采用vectorized操作」；

第三步：指定异常处理方式，例如「遇到NaN的created_at按照当前日期往前推90天填充，不抛出错误」。

如果缺少环境信息，Codeium可能会默认使用SQL语法或旧版pandas已废弃的方法，导致代码无法直接运行。