Menú
根据 Rubric 评审 Anthropic Cookbook notebook。当请求 notebook 审查或审计时使用。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
此技能根据财务报表数据计算关键财务比率和指标，用于投资分析
此技能将一致的企业品牌和样式应用于所有生成的文档，包括颜色、字体、布局和文案
此技能提供一套高级金融建模套件，包含 DCF 分析、敏感性测试、蒙特卡洛模拟和用于投资决策的情景规划
| name | cookbook-audit |
| description | 根据 Rubric 评审 Anthropic Cookbook notebook。当请求 notebook 审查或审计时使用。 |
使用 style_guide.md 中的指南和评分标准审查请求的 Cookbook notebook。根据评分指南提供评分，并给出改进 cookbook 的建议。
样式指南提供了详细的模板和示例，涵盖：
重要：在进行审计之前，请务必先阅读 style_guide.md。样式指南包含可参考的标准模板以及好/坏示例。
按照以下步骤进行全面审计：
style_guide.md 以了解当前的最佳实践python3 validate_notebook.py <path> 捕捉技术问题并生成 markdown
scripts/detect-secrets/plugins.py 中定义的自定义模式scripts/detect-secrets/.secrets.baseline 中的基线进行检查tmp/ 文件夹中生成一个 markdown 文件以便于审查（与原始 .ipynb 相比节省上下文）
请使用以下结构展示你的审计结果：
[简要理由及具体示例]
[简要理由及具体示例]
[简要理由及具体示例]
[简要理由及具体示例]
[优先级排序的、可操作的改进列表，并引用特定章节]
[展示 notebook 的具体摘录，并提出具体的改进建议]
使用此清单确保全面覆盖：
引言（参见 style_guide.md 第 1 节）
前置条件与设置（参见 style_guide.md 第 2 节）
结构与组织
结论（参见 style_guide.md 第 4 节）
代码质量
输出管理
内容质量
技术要求
Cookbook 主要以行动为导向，但策略性地融入了理解内容，并受 Diataxis 框架指导。
核心原则：
一个好的 Cookbook 不仅帮助用户解决当下的问题，还能帮助他们理解解决方案背后的基本原则，鼓励他们识别何时以及如何调整方法。用户将能够对 AI 系统设计做出更明智的决策，培养对模型输出的判断力，并建立可迁移到未来 AI 系统的技能。
Cookbook 不是纯教程：我们假设用户具备基本的技术技能和对 API 的熟悉度。我们在 cookbook 中明确说明前置条件，并引导用户前往 Academy 学习更多主题。 它们不是全面的解释：我们不教 Transformer 架构或概率论。我们需要理解，用户遵循我们的 cookbook 是为了解决他们今天面临的问题。他们很忙，正处于学习或构建的过程中，并希望能够运用所学来解决当前的需求。 Cookbook 不是参考文档：我们不会详尽地记录每个参数，我们会根据需要链接到文档中的适当资源。 Cookbook 不是简单的技巧和窍门：我们不教授仅适用于当前模型代际的“黑客技巧”。我们不过度承诺而交付不足。 Cookbook 不是生产就绪的代码：它们展示用例和能力，而非生产模式。不需要过度的错误处理。
dotenv.load_dotenv() 而非 os.environ使用 %%capture 移除多余输出：
显示相关输出：
详细模板和示例请参见 style_guide.md
必须包含：
❌ 避免：以机制开头（“我们将构建一个研究代理……”） ✅ 做法：以问题/价值开头（“你的团队花费数小时对 CI 失败进行分类……”）
必须包含：
%%capturedotenv.load_dotenv() 而非 os.environMODEL 常量按逻辑步骤或阶段组织，每个阶段包含：
必须包含：
❌ 避免：通用总结（“我们演示了 SDK 如何实现……”） ✅ 做法：可操作的指导（“考虑将其应用于 X……接下来，尝试 Y……”）
详细的好/坏示例请参考 style_guide.md。注意以下问题：
❌ 以机制开头：“我们将使用 Claude SDK 构建一个研究代理……” ❌ 功能堆砌：列出 SDK 方法或工具能力 ❌ 模糊的学习目标：“了解代理”或“理解 API” ✅ 以问题为导向的框架，配合具体、可操作的学习目标
❌ 未使用 %%capture 的嘈杂 pip install 输出
❌ 多个独立的 pip install 命令
❌ 使用 os.environ["API_KEY"] = "your_key" 而非 dotenv
❌ 全文硬编码模型名称，而非使用 MODEL 常量
✅ 干净的设置，合并安装项，使用 dotenv 和常量
❌ 代码块之前没有解释性文字 ❌ 运行代码后没有解释我们学到了什么 ❌ 注释解释代码做“什么”（代码应自文档化） ❌ 过度解释显而易见的代码 ✅ 代码前有背景，代码后有见解，注释解释“为什么”
❌ 通用总结：“我们演示了 SDK 如何实现……” ❌ 仅重述 notebook 做了什么，没有指导 ❌ 未呼应陈述的学习目标 ✅ 关于将学到的知识应用到用户具体场景的可操作指导