大语言模型能回答问题、总结文档、写代码，还能和外部系统交互。但把提示词发出去、把回复显示出来，离一个能用的AI应用还差得远。
一个能上线的应用，得管好对话历史、提供相关上下文、安全地调用工具、处理不同类型的响应块，还要评估生成的内容到底有没有用。
有一份面向开发者的教程，用一家虚构网店的客服助手ShopHelper做例子，把这几块拼图一块块装起来。它的目标很具体：让助手用一致的语气回答通用问题、记住客户之前说过什么、通过调用代码里的函数查订单状态、安全处理Claude的多块响应、用工作流处理工单，以及评估提示词改动是否真的让结果变好了。
先解决钥匙别丢的问题
动手之前需要几样东西：基础Python知识、Python 3.9或更高版本、一个Anthropic API密钥，以及对函数和JSON的熟悉。
项目搭建的第一步是隔离环境。创建虚拟环境、装好Anthropic的Python SDK和python-dotenv，然后在.env文件里放API密钥。教程在这里给了一句很硬的提醒：API密钥是机密凭证，绝不能放进浏览器JavaScript、移动应用代码或客户端配置里，也绝不能提交到代码仓库——记得把.env写进.gitignore。
如果之后要加网页界面，密钥必须留在后端，走“浏览器→你的后端→Claude API”这条链路。代码里用一个MODEL常量存模型名，好处是换模型只需要改一个地方。教程还提醒，运行示例前先确认这个模型标识符对你的账号可用。
一次请求里藏着三个关键参数
第一次调用只需要三样东西：model、max_tokens和messages。model决定由哪个Claude模型处理请求，不同模型在能力、速度和成本上有差异；max_tokens限制生成文本的最大量，调小可以降低延迟，但Claude可能在答完之前就停下；messages承载对话，每条消息有role和content，role通常是user或assistant。
一次性请求只包含一条用户消息，多轮对话则要带上之前的用户和助手消息。教程特别点出一个容易踩的坑：Claude返回的response.content是一个带类型的块列表，常见块包括文本块等。示例代码的做法是收集所有文本块，而不是想当然地认为response.content[0]永远是文本。想监控用量的话，可以打印response.usage.input_tokens和response.usage.output_tokens。
记忆不是自动的，得自己搬
Claude不会自动记住两次独立的API请求。想让助手接得上话，每次请求都要把相关的历史一起发过去。教程给了一个直观的例子：先问退货政策，助手答“30天内可退”，再问“那我有多少时间”，只有把助手之前那条回答也放进messages，最后这个问题才能被正确理解。
维护历史可以用一个简单的chat函数：每次调用先把新的用户消息追加进history，把完整历史发给模型，再把Claude的回复追加进history留给下一轮。教程建议，生产环境里要按客户或会话ID来存储历史。
历史越滚越长会带来两个问题：输入体积变大，而且Claude可能更难聚焦。教程给了两条路。一条是只保留最近的消息，用trim_history截取最后若干条，并保证开头是用户消息。
另一条是总结旧对话、保留近期消息：把较早的部分拼成文本，让模型用100词以内总结，并要求保留订单号和尚未解决的问题。总结要作为独立的应用状态保存，在下次请求时作为上下文带上，而不是直接插在近期消息前面当成一条额外的用户消息——那样会造出连续两条用户消息的无效结构。
存储或传输之前还要做脱敏。教程给出的redact函数用正则匹配13到16位的数字串，替换成[REDACTED CARD]。
提示词要有清晰的边界
XML风格的标签只是普通文本，不是API的特殊指令，它的作用是把提示词里每一部分的边界写清楚。教程用customer_reviews标签包住客户评价内容，让模型知道这段文字是什么、从哪里开始、到哪里结束。
热门跟贴