glm-5.3-flash 在「步骤指令」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：glm-5.3-flash
- 用例名称：步骤指令
- 测试类型：文本生成
- 评测维度：指令遵循
系统提示词（System Prompt）
这是给 AI 模型的背景设定和角色指令：
你是一名生活技能指导专家，擅长将日常操作分解为清晰、易懂的步骤说明。 回答要求： 1. 严格按照指定的步骤数量输出，不多不少。 2. 每个步骤使用编号（如「步骤1：」）开头，结构清晰。 3. 每个步骤描述一个独立且完整的动作，步骤之间具有自然的先后顺序。 4. 语言简洁明了，避免冗余信息，确保普通读者能够直接照做。
用户提示词（User Prompt）
这是用户给 AI 模型的具体任务要求：
请用**恰好3个步骤**说明如何泡一杯茶。 要求： - 步骤总数必须为3步，不能多也不能少。 - 每个步骤用「步骤1 / 步骤2 / 步骤3」编号标注。 - 每个步骤只描述一个核心动作，并简要说明该动作的要点（如温度、时间等关键细节）。 - 步骤之间需体现合理的操作顺序。
任务要求
AI 模型需要满足以下要求：
- 步骤数量严格等于3，既不能合并为2步，也不能拆分为4步及以上。
- 每个步骤有明确的编号标识（步骤1、步骤2、步骤3）。
- 三个步骤覆盖泡茶的完整流程（准备/冲泡/完成），不遗漏关键环节。
- 步骤之间存在清晰的先后依赖关系，顺序合乎逻辑。
- 每个步骤包含至少一个具体的操作要点（如水温、浸泡时间等），而非仅有笼统描述。
评测结果
综合得分
该模型在此用例的得分为：94.5 分（满分 100 分），已通过
基础难度评测结果
- 得分：94.5 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
步骤1：烧水。将清水烧开，然后根据茶叶种类调节水温——绿茶晾至约80℃，红茶、乌龙茶可直接使用约95–100℃的热水。 步骤2：投放茶叶。取适量干茶放入杯中，一般每150毫升水搭配约3克茶叶（约一小撮），避免过多导致茶汤苦涩。 步骤3：注水冲泡。将热水沿杯壁缓缓倒入，水量至杯子的七八分满，盖上杯盖或静置闷泡2–3分钟后即可饮用。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】该候选输出整体表现优秀，严格遵守了「恰好3个步骤」的核心指令约束，格式规范，流程完整，每步均附有关键操作细节（水温、用量、时间），语言简洁易懂。与参考答案相比，主要差异在于未按茶叶类型细化闷泡时间，以及缺少预热杯具的步骤，但这些并非硬性缺失，整体质量仍属高水准。 【GEMINI】候选输出表现完美。它不仅严格遵循了所有的格式和数量指令，而且在内容质量上表现优异，提供了非常具体、量化的操作细节（如温度、配比、时间），步骤逻辑清晰，是一份高质量的泡茶指南。 【KIMI】候选输出整体表现优秀，严格遵循了3步约束和编号格式要求，内容具体可操作。主要不足在于步骤划分的逻辑衔接：将「投茶」与「注水」拆分为两步导致中间出现干茶叶状态，且冲泡后的等待与饮用合并使得操作边界不够清晰；内容层面缺少不同茶类的浸泡时间差异及滤茶收尾动作。属于良好水平的回答。
进阶难度评测结果
- 得分：94.9 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
以下是从零搭建个人博客的完整流程，共 5 个主要步骤、15 个子步骤，前后环节层层衔接： 1. **规划定位与技术选型**（核心目标：明确博客方向，为后续所有环节奠定决策基础） 1. 明确博客定位与受众：确定写作领域、内容风格与更新频率，输出一份简要的内容规划清单。 2. 选定技术方案：对比静态站点生成器（如 Hugo、Hexo）与动态 CMS（如 WordPress），依据自身技术能力做出选择。 3. 规划域名与预算：拟定候选域名并查询可用性，估算域名与托管服务的年度成本。 2. **搭建本地开发环境**（核心目标：完成工具链安装与项目初始化，获得可运行的博客雏形） 1. 安装基础开发工具：安装对应运行时（Node.js 或 Go）、Git 与代码编辑器，并验证版本命令可用。 2. 初始化博客项目：执行脚手架命令创建站点骨架，启动本地服务确认预览页面正常渲染。 3. 注册远程代码仓库：在 GitHub 创建仓库并完成首次提交推送，为后续自动化部署提供源码入口。 3. **主题定制与内容准备**（核心目标：将默认模板改造为个性化站点，储备上线所需的首批内容） 1. 导入目标主题：从官方主题库中挑选风格匹配的主题并替换默认模板，跑通渲染流程。 2. 定制站点信息与样式：修改站点标题、头像、导航菜单与社交链接，统一配色与字体方案。 3. 撰写首批文章：创作 3–5 篇高质量文章，配置好分类、标签与封面图等元数据。 4. **部署上线与域名绑定**（核心目标：将本地站点发布至公网，实现自有域名的安全访问） 1. 配置自动化部署：接入 GitHub Pages、Vercel 或 Netlify 并关联仓库，实现“推送即构建发布”。 2. 解析自定义域名：在域名服务商处添加 CNAME 或 A 记录，将域名指向托管平台分配的地址。 3. 启用 HTTPS 加密：在托管平台申请 SSL 证书并开启强制跳转，确保全站加密访问。 5. **测试验收与运营启动**（核心目标：确保站点稳定可访问，建立长期可持续的更新机制） 1. 执行全面功能测试：逐项检查移动端适配、内外链有效性与评论订阅等功能是否正常。 2. 完成 SEO 与统计配置：向 Google/Bing Search Console 提交 sitemap，并接入访问分析工具监测流量。 3. 制定持续更新计划：设定固定写作节奏与选题储备机制，定期回顾数据并迭代站点体验。 按此流程推进时，前四步通常可在 1–3 天内集中完成，第五步则需长期坚持——博客的价值最终取决于内容的持续产出。
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出整体表现优秀，对各项硬性指令的执行精确度极高，5步15子步骤均符合规范，动词开头、核心目标说明、Markdown 格式等要求一一落实。内容深度良好，工具引用具体，逻辑链条清晰。与参考答案相比，主要差异在于将「博客定位规划」与「技术选型」合并为第 1 步，并将「内容创作」并入第 3 步，导致内容准备阶段略显单薄，但整体瑕疵较小，属于高质量输出。 【GEMINI】候选输出是一份极其优秀的回答。它不仅在字面和格式上百分之百地履行了系统提示词和用户指令的所有约束，而且在内容质量、逻辑合理性以及技术细节的专业度上都表现得无可挑剔，完全达到了资深技术博客搭建顾问的水平。 【KIMI】候选输出是一份高质量的个人博客搭建指南，严格遵循了所有格式与数量约束，逻辑链条完整，内容具体可操作。与参考答案相比，主要差异在于步骤1将规划与技术选型合并、步骤3将主题定制与内容准备合并，这种整合在15个子步骤的限制下是合理的权衡，未损害整体逻辑。整体表现优秀，接近满分。
困难难度评测结果
- 得分：96.2 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
# 软件产品研发项目管理流程 · 标准WBS文档 > **文档定位**：本流程遵循PMBOK五大过程组思想，结合软件研发生命周期特点，划分为五个阶段、20个关键活动，形成“启动→规划→执行→验证与监控→交付收尾”的闭环管理链条。 ## 〇、流程总览 | 阶段 | 阶段名称 | 核心目标 | 活动范围 | 阶段里程碑 | |---|---|---|---|---| | 一 | 启动阶段 | 论证项目价值，获得正式授权 | 1.1 ~ 1.4 | M1 项目正式立项 | | 二 | 规划阶段 | 冻结需求，建立进度/成本/范围三大基准 | 2.1 ~ 2.4 | M2 规划基准获批 | | 三 | 执行阶段（设计与开发） | 完成可通过测试的系统实现 | 3.1 ~ 3.4 | M3 开发完成·功能冻结 | | 四 | 验证与监控阶段 | 质量达标验证，绩效受控推进 | 4.1 ~ 4.4 | M4 版本发布就绪 | | 五 | 交付与收尾阶段 | 业务验收、上线移交、正式关项 | 5.1 ~ 5.4 | M5 项目交付关闭 | **主链路**：`1.1 → 1.2 → 1.3 → 1.4 → 2.1 → 2.2 → 2.3/2.4 → 3.1 → 3.2 → 3.3 → 3.4 → 4.1 → 4.2 → 4.3 → 5.1 → 5.2 → 5.3 → 5.4` **并行支线**：`4.4`（绩效监控与变更控制）自 2.3/2.4 基线确立后，与第三、四阶段活动**并行运行**。 --- ## 一、启动阶段（Initiating） ### 活动 1.1 商业论证与立项评估 | 要素 | 内容 | |---|---| | **输入 Input** | 公司战略规划、市场需求/客户线索、初步竞品调研资料 | | **输出 Output** | 技术、经济、运营三维度可行性结论及投资建议 | | **责任人 Owner** | 产品总监（协同：商务分析师） | | **交付物 Deliverable** | 《商业论证报告》 | | **前置依赖** | 无 | | **依赖逻辑** | 项目源头活动，为项目章程提供立项与投资决策依据 | ### 活动 1.2 项目章程编制与批准 | 要素 | 内容 | |---|---| | **输入 Input** | 《商业论证报告》（1.1） | | **输出 Output** | 获批准的项目目标、高层级范围、预算授权、项目经理任命 | | **责任人 Owner** | 项目发起人（编制：项目经理） | | **交付物 Deliverable** | 《项目章程》（签署版） | | **前置依赖** | `1.1 → 1.2` | | **依赖逻辑** | 章程中的目标与预算额度必须以商业论证的投资回报结论为直接依据 | ### 活动 1.3 干系人识别与分析 | 要素 | 内容 | |---|---| | **输入 Input** | 《项目章程》（1.2） | | **输出 Output** | 干系人清单及权力/利益方格分类结果 | | **责任人 Owner** | 项目经理 | | **交付物 Deliverable** | 《干系人登记册》 | | **前置依赖** | `1.2 → 1.3` | | **依赖逻辑** | 章程载明的组织架构与高层级角色是识别干系人的权威来源 | ### 活动 1.4 项目启动会 | 要素 | 内容 | |---|---| | **输入 Input** | 《项目章程》（1.2）、《干系人登记册》（1.3） | | **输出 Output** | 全员目标共识、沟通机制与决策升级通道建立 | | **责任人 Owner** | 项目经理 | | **交付物 Deliverable** | 《启动会会议纪要》《项目沟通计划（初版）》 | | **前置依赖** | `1.2 → 1.4`、`1.3 → 1.4` | | **依赖逻辑** | 须持有效授权文件向全员宣贯，并按登记册定向邀请关键干系人到会 | #### 🏁 里程碑 M1：项目正式立项 - ✅ 《项目章程》获发起人书面签署，授权范围与预算额度表述明确、无歧义项； - ✅ 关键干系人识别覆盖率 ≥95%，启动会核心成员到岗率 100%、整体出席率 ≥90%。 --- ## 二、规划阶段（Planning） ### 活动 2.1 需求获取与分析 | 要素 | 内容 | |---|---| | **输入 Input** | 《项目章程》高层级需求（1.2）、《干系人登记册》关键用户名单（1.3）、用户访谈与市场输入 | | **输出 Output** |...
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】该候选输出是一份质量极高的软件产品研发WBS文档，几乎完美满足所有指令要求。五阶段、每阶段四活动的结构清晰，四要素内容具体且无模糊表述，依赖关系逻辑闭环，里程碑验收标准可量化可核查。专业深度超出一般模板——EVM、CCB、CI/CD、P95等行业术语的准确运用，附录依赖校验表的设计，均体现了资深项目管理实战视角。格式规范、层次清晰，可直接作为实际项目管理文件使用，属优秀交付水准。 【GEMINI】这是一份堪称教科书级别的软件产品研发项目管理流程WBS文档。模型不仅完美无缺地执行了所有的硬性约束指令，更在专业深度、逻辑闭环设计以及排版美化上展现出了极高的水平。附带的‘依赖关系闭环校验表’进一步确保了流程的严密性，是一份极具实用价值的高质量输出。 【KIMI】该候选输出是一份高质量的软件产品研发项目管理WBS文档，在指令遵循、逻辑深度和结构呈现三个维度均表现优异。不仅完全满足所有硬性约束，更通过闭环校验表、并行监控活动设计、量化验收标准等细节体现了资深项目管理专家的实操水准。文档可直接用于真实项目交付，具备很强的实用价值。与参考答案相比，在活动数量（20 vs 17）、并行依赖设计、量化指标颗粒度等方面甚至有所超越，仅在依赖标注的绝对标准化（如'辅助依赖'表述）上存在极轻微偏差。
相关链接
您可以通过以下链接查看更多相关内容：
