团队引入 Anthropic 模型时，技术负责人应提前确立的准则

本文由 AI 撰写并编辑，经运营者审核后发布。缩略图也可能由 AI 生成。

一位新加入项目的同事负责重构遗留模块。为了理解这份包含数千行代码的文件，他将整个代码复制粘贴到像 Claude 3 Opus 这样的高性能模型中，并开始提问。结果令人满意，但其他做类似工作的团队成员却使用了不同的模型或提问方式，得到了截然不同的答案。

到了月底，结算账单让所有人大吃一惊。他们发现某些特定任务的成本比预期高出数十倍，原因就是无节制地输入了长上下文。尽管个人生产力可能暂时提高了，但从整个团队来看，这导致了成本无法预测，且产出一致性缺失的问题。

本文将探讨在团队引入 Anthropic 模型时，技术负责人或高级开发人员应提前制定的一些规则和基本设置。这有助于可预测地管理成本，并确保团队成员的输出质量保持在一定水平。

© AI 生成图片

为什么需要规则：在自由与混乱之间

将 LLM API 集成到团队工作流中的最大优势在于其处理海量信息的能力。然而，这一优势也可能同时成为与成本直接相关的缺点。如果没有明确的指导方针，每个人都会以不同的方式使用模型，这很快就会导致不可预测的成本和产出差异。

最常见的问题是“最高性能模型万能论”。尽管某些任务更适合使用更轻量、更快的模型，但人们往往倾向于无条件选择最昂贵的模型（例如 Claude 3 Opus）。此外，由于缺乏关于如何以及提供多少上下文的标准，导致重复性地将整个文件作为输入。

因此，在团队层面制定最低限度的规则并非为了限制个人自主性，而是为了团队整体的可持续利用所必需的过程。

1. 模型选择和用量上限设置

并非所有任务都需要 Opus 模型。仅仅指导根据任务性质选择合适的模型，就能大大节省成本。建议团队制定并分享以下简单标准：

• Claude 3 Haiku：适用于快速且成本效益高的任务，例如简单的代码格式转换、生成注释、编写提交信息。
• Claude 3 Sonnet：作为大多数开发工作（编写函数、逻辑分析、生成测试用例）的默认选项。它在性能和成本之间提供了最佳平衡。
• Claude 3 Opus：仅限于需要深度推理且可接受高成本的任务，例如复杂架构分析、大规模遗留代码重构建议，需与团队负责人讨论后使用。

此外，在直接调用 API 的脚本或内部应用程序中，必须设置 max_tokens 参数，以防止因意外过长的响应而导致成本激增。

import anthropic

client = anthropic.Anthropic(
    # API 密钥从环境变量中读取。
    api_key="<YOUR_ANTHROPIC_API_KEY>",
)

# 为了可预测的成本，必须设置 max_tokens。
# 通常 4096 个 token 足以获得充分的响应。
MAX_TOKENS_FOR_RESPONSE = 4096

message = client.messages.create(
    model="claude-3-sonnet-20240229",
    max_tokens=MAX_TOKENS_FOR_RESPONSE, # 输出 token 限制
    messages=[
        {"role": "user", "content": "分析这个 Python 函数的时间复杂度。"}
    ]
)

print(message.content)

这样在代码层面设置安全措施，系统就能弥补开发者的失误。

2. 系统提示词（System Prompt）标准化

团队成员使用不同的系统提示词会导致模型响应的语气、格式和关注点各异。特别是在代码审查或文档生成等规范化任务中，产出的一致性至关重要。

建议创建团队通用的系统提示词模板，并鼓励大家使用。例如，用于代码审查的系统提示词可以这样创建：

You are an expert software developer with a focus on writing clean, maintainable, and robust code.
Your task is to review the provided code snippet.

Please follow these instructions:
1.  **Primary Goal**: Identify potential bugs, performance issues, and deviations from best practices.
2.  **Clarity**: Provide clear and concise feedback. For each point, explain *why* it's an issue and suggest a specific improvement.
3.  **Tone**: Maintain a constructive and collaborative tone. Avoid overly critical language.
4.  **Format**: Structure your feedback using markdown. Use headings for major points and bullet points for details.
5.  **Scope**: Do not comment on code style (like indentation or line length) unless it severely impacts readability. Focus on logic and structure.

将此类模板注册到维基或团队共享文档中，并指导团队成员在各自环境中将其设置为默认提示词，可以大大减少产出差异。

3. 上下文长度和格式指南

需要明确的规则来管理导致最大成本的上下文输入。

• 规则 1：不要输入整个文件。
  • 仅选择并传递问题所需的最小函数、类或代码块。
• 规则 2：总结提供依赖信息。
  • 在询问特定类时，不要输入该类继承的父类或使用的其他对象的完整代码，而是仅提取所需的 方法签名 或 属性，并以文本形式进行描述。
  • 例如：当询问 User 模型时，明确告知“此模型继承自 BaseModel，并具有 created_at 和 updated_at 字段”，这比粘贴整个 BaseModel 代码要高效得多。
• 规则 3：明智地管理对话历史记录。
  • 在聊天界面中继续对话时，之前的对话都会包含在上下文中，从而累积成本。
  • 如果主题改变或不再需要之前的信息，应将开始一个新的对话窗口作为规则。

这些规则与其强制执行，不如向团队成员充分解释其必要性（节省成本、引导更准确的回答），以形成共识。

结论：根据实际情况应用规则

并非所有团队都适用相同的规则。关键在于根据团队规模、项目性质和预算大小制定适当级别的指导方针。

AI 模型是强大的工具，但成本和一致性之间存在明显的权衡。如果我们能根据团队实际情况制定最低限度的规则并持续改进，将能更可持续、更有效地利用这一工具。

参考资料

• Messages API
• Prompt Engineering