我们今天有另一个关于Claude Code的重要更新：它现在可以在Windows上原生使用。

查看我们最新一集的第一部分，嘉宾是来自 @vercel 的 @tomocchino （再次感谢 vercel 让我们在总部拍摄）

作为提醒，斜杠命令允许您将自定义提示存储为 Markdown 文件，并通过 /your-command 调用它们。 通过此更新，您现在可以： - 从斜杠命令执行 bash 命令 - @ 提及文件以提供上下文 - 在命令中使用关键字启用扩展思考

开始使用评估并不需要太多。我们看到的小团队成功的模式很像应用于AI工程的测试驱动开发： 1/ 将评估锚定在用户故事中，而不是抽象的基准测试：与您的产品/设计伙伴坐下来，列出您的模型需要为用户做的具体事情。“准确回答保险索赔问题”、“从自然语言生成SQL查询”。对于每一个，写出10-20个代表性输入和期望的输出/行为。这是您的第一个评估文件。 2/ 从第一天开始自动化，即使它很脆弱。抵制“只看一眼”的诱惑。好吧，感觉不能持续太久。将您的评估包装在代码中。您可以编写一个简单的pytest，循环遍历您的示例，调用模型，并断言某些子字符串出现。这很粗糙，但这是一个开始。 3/ 使用模型引导更难的评估数据。手动编写数百个边缘案例是昂贵的。您可以使用推理模型（o3）生成合成变体（“给我50个涉及火灾损害的索赔问题”），然后手动筛选。这加快了覆盖率而不牺牲相关性。 4/ 不要追逐排行榜；迭代失败的地方。当某些东西在生产中失败时，不要只是修复提示——将失败的案例添加到您的评估集中。随着时间的推移，您的套件将增长以反映您的实际失败模式。定期切片您的评估（按输入长度、按地区等）以查看您是否在特定段上回归。 5/ 随着产品成熟，发展您的指标。随着规模的扩大，您会希望有更细致的评分（语义相似性、人类评分、成本/延迟跟踪）。在您的评估工具中构建钩子以记录这些并随时间推移趋势。为您的UI设置工具以收集隐性反馈（用户是否点击“点赞”？）并将其反馈到您的离线评估中。 6/ 使评估可见。在团队和利益相关者面前放置一个简单的仪表板，显示评估通过率、成本、延迟。在站会上使用它。这创造了责任感，并帮助非ML人员参与权衡讨论。 最后，将评估视为核心工程工件。分配所有权，在代码审查中审查它们，当您添加一个新的棘手案例时庆祝。随着规模的扩大，这种纪律将带来复合收益。