主观题看起来“没标准”，其实最怕的是改一次就悄悄变味，回归跑不起来。这篇文章梳理一套最小可用的评测方法：先定 Fail-fast 底线（编造事实、违背规则红线、瞎改工具结果直接判 Fail），再用 0/1/2 三档 Rubric 从事实一致性、完成度、可执行性、清晰度四个维度打分。最后挑了 5 条黄金主观题（日报总结、忘打卡风险提醒、明日计划、复盘建议、规则边界说明）拆出 must-have /

最近在梳理 AI 辅助测试时发现，行业讨论大多停留在“生成测试用例”，但从工程实践看，真正有价值的方向已经在转向：让 AI 参与测试工程本身，比如日志分析、回归差异对比、评测问题生成与质量总结等。同时，在传统测试流程中，AI 也可以作为辅助工具，帮助做需求风险梳理、测试点检查、数据生成和报告整理。整体来看，AI 更适合嵌入到测试流程中提升效率，而不是替代测试工作本身。

最近很火的大模型问法：洗车50米该走路吗？父母结婚我不在场？两种情况，一个先进入情绪安慰模式，另一个先做逻辑判题（认为这是个“时空前提不成立”的问题）。这类差异说明，大模型在面对语义歧义时，会优先走不同的“理解入口”，而不仅仅是能力差异。

一次使用千问点奶茶失败的经历，引发了我对 Agent 系统完整链路的重新审视。本文不是从模型能力出发，而是从真实执行失败的现象入手，拆解了一次 Agent 任务从输入理解、规划、工具调用到业务系统执行的完整过程，并分析了失败通常发生在哪些环节。在此基础上，进一步梳理了 Agent 场景下性能与稳定性测试的关注重点，说明为何很多问题并不出在大模型本身，而是在链路设计与失败处理机制上。

本文记录项目一在迭代二阶段的工程化演进过程：从单用户脚本升级为支持多用户的 HTTP API 服务。本轮迭代重点不在功能扩展，而在接口 contract 稳定性、模型不可控行为的工程约束，以及测试视角下的可回归设计。通过引入 author 隔离、最小事实输入门槛与统一响应结构，解决了模型误判、低质量碎片写入与测试不可复现等问题，并给出了对应的接口测试用例与验证结论。

本文记录了在持续测试 RAG 系统过程中，发现的一类问题：检索命中相关 chunk 后，系统仍可能给出不成立的回答。通过多次问法复现，梳理了从 PDF 切分、检索打分到回答生成的实际流程，明确了问题并非出在检索本身，而在于将“命中证据”等同于“可以回答”。这一观察为后续拒答与兜底策略的设计提供了直接依据。

本文记录了在 RAG 系统中对检索阶段的一次实际验证过程。通过查看 PDF 切分结果与检索输出，梳理了 chunk 的生成方式、chunk_id 与 page 的含义，以及固定问题下检索结果为何命中这些内容。重点在于确认检索行为是否可观察、可解释，为后续的引用与边界控制打基础。

在完成 RAG 最小闭环后，没有立即引入向量数据库，而是先对现有链路进行了一轮回归测试。通过一组带明确预期的问题，逐步暴露出当前系统在检索命中率、生成可控性和结果稳定性方面的问题。本阶段不引入新模型或新组件，仅通过增强检索过程的可观测性、修复中文检索策略以及加入拒答约束，使 RAG 从“能跑”过渡到“可验证、可回归”。这一过程为后续引入向量数据库和 embedding 奠定了工程基础。

在该项目中已完成 RAG 的最小闭环，实现了基于 PDF 文档的内容生成。但在继续推进时发现，问题并不在模型能力，而在输出结果的稳定性与可控性：同一份文档多次运行，输出形态不一致，难以复现与信任。为此，本阶段引入“输出契约”的工程思路，将同一输入拆分为“课程大纲”和“项目说明”两种输出模式，通过 prompt 明确约束结果结构，并对项目说明模式固定为三页结构。该实践使 RAG 从“能跑”迈向“可信

本篇记录跑通 Tool Calling + 本地 PDF 接入的全过程：先定义 tools schema 与两段关键 prompt（触发工具调用 / 基于证据生成），再让模型在 tool_choice=auto 下自动触发 read_local_pdf(file_path)，由代码执行工具读取 PDF 文本并返回“文件名+摘录”作为 evidence，最后将 evidence 回填 message