评测卡先写场景和基线，再写输入约束、提示版本、允许访问的数据、人工复核点与失败回退。固定样本后保存输出快照，才有机会比较迭代前后变化。它不是为了给模型打一个漂亮分数，而是为了知道“哪一步可以交给工具，哪一步必须留给人”。
一次评测的最小字段
scenario / baseline_steps / sample_id
prompt_version / model_version / context_limit
allowed_data / redaction_rule / expected_shape
pass / needs_review / fail / fallback_action
latency_ms / cost / reviewer_note / captured_at
场景要写成可执行任务，例如“把一份工程日志整理成待办”，同时保留人工基线：原来需要哪些步骤、哪些地方最容易漏项。样本至少包含成功、边界、空输入、格式错误和故意冲突五类；每个样本保存输入摘要、输出快照与审核结论。通过不等于无需复核，needs_review 应该单独统计。
比较版本时不改变题目
提示词或模型版本变化时，不要只挑新结果好的样本。使用同一批样本跑旧版和新版，再记录延迟、成本、失败类型及人工修改量。可以把结果分成“结构正确、内容需核对、格式失败、拒答/超时”四类，并为每类写下一步动作。若样本集发生变化，要在评测卡中说明原因，不能把不同题目混成一张趋势图。
先设权限和回退
若输出包含工程文件、个人信息或账号字段，评测前先做脱敏，并记录允许访问的目录和关闭开关。AI 只生成草稿或候选项时，正式写入仍由用户确认；模型不可用时，原来的本地流程应继续可用。评测结果保留版本、时间和摘要即可，不为追求复现而复制整份敏感资料。
当前资料没有上线 AI 产品的用户量或准确率，因而本文不填“提升百分比”。只有当样本、成本和延迟真的测过，才把它们放进文章正文；在此之前，评测卡本身就是交付物。
评论区