我这一个月基本把日常里能交给语言模型的活儿都换成了 Claude 4从写周报、整理会议纪要到搭批量处理脚本明显感觉产出速度快了一截。上一篇文章讲了入门向的基础玩法这篇接着往下走重心放在真正提升生产力的三块内容提示工程的实际打法、拿到就能改着用的提示模板、以及用 Python 调 API 的完整姿势。我会先把 Claude 4 处理指令的底层逻辑讲清楚再给模板和脚本最后用一个真实项目把整个流程串起来方便你照着自己的场景复现。1. Claude 4 理解指令的底层逻辑为什么同样一句话换个说法效果差好几倍提示工程不是玄学它建立在模型如何处理文本的基础上。Claude 4 的指令理解方式和前代相比有个明显变化它对“角色设定”和“任务边界”的敏感度更高但对“啰嗦话”的容忍度反而降低了。换句话说你给的提示越靠近一份“任务说明书”它输出的东西就越稳定你给的提示像随手写的小纸条它就会用发散的方式补全你的意图。这一节先把底层逻辑梳理清楚后面模板和脚本才能用得明白。1.1 系统提示是那个“看不见的管理者”用 API 调用 Claude 4 时官方接口提供一个system字段专门用来放系统提示。很多人以为系统提示就是“角色扮演开关”其实它更像一个前置工作准则。模型在阅读每一轮用户消息之前会先把系统提示当作默认立场和行为边界。你可以把它理解为入职培训你告诉新员工公司价值观、工作流程、汇报格式他在具体干活的时候就会按这套标准处理问题而不是每次等你叮嘱。实操里我最常用的一条系统提示模板是你是一名资深的内容运营专家擅长把技术信息转化为普通用户能看懂的语言。 你在回答时会遵循以下规则 1. 先确认用户需求再给结论 2. 结论控制在100字以内 3. 如果有必要解释原因用生活化类比。对比一下如果只是写“帮我写一段产品介绍”Claude 4 也能完成但输出风格完全不可控。加上系统提示之后同样的任务输出更像你团队里培养过的员工。这个差异在 API 调用场景里尤其明显因为我可以在代码里固定系统提示、只替换用户消息实现批量生成且风格统一。提示system字段在官方 SDK 里是顶层参数不是放在messages数组里面的。1.2 上下文给得太少它就只能靠猜我在公司做过一次小实验让同事用 Claude 4 写一篇产品发布公告。第一批提示只给了“写一篇公告500字”第二批提示给了产品名、目标用户、核心卖点、发布渠道和语气要求。结果是第二批明显更接近可直接发布的状态修改成本大概少了三分之二。原因不难理解大模型的生成过程本质上是在做概率预测信息越充分预测范围越小输出越贴近目标。但这里有个陷阱不是上下文越多越好。把二十页的聊天记录全部塞进去模型容易“捡了芝麻丢西瓜”反而忽略最新、最关键的指令。我的习惯是把提示拆成三块背景用户是谁、产品是什么、这次任务发生在什么场景任务明确要做的事情最好用一个动词开头比如“改写”“提取”“翻译”约束字数、格式、语气、禁忌项。这三块不是固定顺序但必须在一段提示里都能找到。模板部分我会按这个结构给出具体例子。1.3 “要什么”和“不要什么”一定要分开写这是提示工程里被低估的一条原则。人话沟通时你说“别把咖啡洒在键盘上”对方能听懂但大模型处理否定式指令时常常会把注意力放在“咖啡洒在键盘上”这个词组本身反而更容易在生成内容时带出相关字眼。更稳妥的做法是直接给正面指令“保持工作区整洁液体远离电子设备。”我第一次意识到这个问题是在做电商评论分析的时候。我在提示里写“不要输出无关内容”结果模型在每个段落结尾都莫名其妙地加了一句“本段为无关内容”。改成“只输出与产品质量相关的三个要点并注明信息来源”输出立刻干净了。所以做提示工程的时候建议把“不要”开头的句子全部翻译成“要”开头的句子。比如“不要写太长” ← 改为“全文控制在300字以内”“不要编数据” ← 改为“如果数据不在给定资料中明确标注‘未提供’并跳过”“不要用专业术语” ← 改为“使用初中生能理解的日常词汇”。这样模型就有了明确行为指引而不是靠猜“边界在哪里”。2. 50 提示模板按场景分类拿来改一改就能用标题里说的 50 模板我按场景把它们分成了六个库内容创作、编程提效、数据分析、工作流拆解、学习辅助、个人效率。这一节不把所有模板一页铺开而是把每个库的“设计逻辑”和几个代表性模板写出来。学会了规律你可以自己组装出更多组合。整套模板的核心骨架是一致的角色 背景 任务 约束 输出格式。2.1 内容创作类从标题到长文一条提示走完内容创作是提示词需求量最大的场景也是模板复用率最高的地方。常用的变形包括写标题、写文章大纲、扩写段落、改写语气、生成多平台分发文案。下面这个模板我几乎每周都会用用于把一篇文章拆成不同平台的发布稿角色你是一名全平台内容运营专家。 背景下面这篇原始文章是关于[主题]的深度内容已经过专业编辑审核。 任务将原文改写为适合在[平台名称]发布的版本。 约束 - 保留原文核心观点不新增事实性内容 - 字数控制在[目标字数]以内 - 语气匹配该平台用户习惯 - 开头第一句必须能引起阅读兴趣。 输出格式直接输出改写后的文本不要解释过程。我在实际使用时只替换方括号里的内容效果非常稳定。针对标题生成我会把任务改成“生成 10 个标题覆盖悬念型、利益型、故事型三种风格每个标题不超过 20 字”约束里加上“不得使用感叹号堆砌”输出格式限定为“编号列表”。提示内容创作类模板要想长期复用最好把“角色”和“约束”固定只变更“任务”和“背景”。这样批量生成时风格能保持一致。2.2 编程与调试类让它当结对程序员而不是代码生成器编程类提示的关键是让 Claude 4 进入“审查-解释-修改”的工作流而不是直接让它甩给你一段代码。直接甩的代码容易对但成本往往也是你必要的审查如果你让它先说明思路再给代码你得到的答案通常更容易理解和维护。以下是我常用的三个方向角色你是一名有多年前端开发经验的工程师。 背景项目使用 React TypeScript代码库结构如下[粘贴关键文件或目录说明]。 任务审查以下代码找出潜在的性能问题和错误处理缺失。 约束 - 按照严重程度从高到低排序 - 每个问题给出修改建议 - 不要重写整个文件只给出差异片段。 输出格式问题列表 建议代码块。调试场景里我还会在任务里明确加上“请先复述你对报错信息的理解再给出排查步骤”这能明显减少模型瞎猜的概率。生成单元测试是另一个高频使用点把被测函数贴进去要求“基于边界值和异常输入设计 5 个用例”最后用表格输出用例名、输入、预期输出、覆盖场景。2.3 数据整理与结构化输出类把散装信息变成表格Claude 4 对结构化数据的理解比较强但你要给它一个明确的目标格式。最典型的是把一段会议记录转成表格或者从一堆文本里抽取关键字段。这个模板是我做项目管理时的常备品角色你是一名数据分析助理。 背景下面是一段会议讨论记录内容涉及[项目/活动名称]。 任务从记录中提取决策事项、负责人、截止日期、风险点。 约束 - 只提取文本中明确提到的信息 - 如果某项信息缺失在对应位置填“未提及”。 输出格式Markdown 表格列为事项类型、内容描述、负责人、截止日期、风险说明。把“会议记录”换成“客户反馈”“面试记录”“合同条款”模板照样能用。我还常用它生成 JSON 结构方便后续程序处理。写法是在“输出格式”里直接给出期望的 JSON schema模型按字段名输出。2.4 工作流拆解类把大任务缩小到可执行步骤这一类模板是“AI Agent”玩法的基础。面对一个复杂任务先让 Claude 4 拆出一个可执行的步骤列表再把每一步分别填入前面的提示模板执行。我自己做方案时常用下面这个拆解模板角色你是一名有十年经验的项目经理。 背景我需要完成[整个目标/交付物]。 任务请把目标拆解为可直接执行的任务列表。 约束 - 每个任务必须有明确的完成标准 - 任务之间标注依赖关系 - 估算每项任务需要的时间和资源。 输出格式编号列表每项包含任务名称、完成标准、前置任务、备注。这个模板看起来简单但配合代码自动化能力时价值很高。你可以循环读取每个任务把它单独丢给 Claude 4 去生成更细的执行说明实现“目标-任务-动作”的自动下钻。2.5 学习辅助与个人效率类把模型当陪练学习类场景的核心不是“让模型告诉你答案”而是“让模型引导你思考”。我用得最多的三个模板是概念解释用生活类比、苏格拉底式提问练习、错题分析。举一个英文学习场景角色你是一名耐心的英语口语教练。 背景学习者的水平是[初级/中级/高级]目标是[备考/日常交流/职场表达]。 任务围绕[话题]和我进行一轮对话练习。 约束 - 每轮只回复不超过三句话 - 如果我的表达有误先重复正确的说法再解释原因 - 对话结束后用列表总结我出现的三个问题。这套模板用在复盘和写作反馈上也行。把“对话练习”换成“阅读我的文章并指出逻辑漏洞”就是一套个人评审工具。3. Python 调 Claude 4 API从环境配置到并发优化模板离线用是一回事接进 Python 才能真正释放生产力。这一节讲的是最实用的 API 接入方式如何处理消息、流式输出、工具调用以及怎么设计健壮的调用代码。所有步骤基于现网常用的anthropic官方 SDKPython 版本要求 3.8 以上建议直接用 3.10 或 3.11。3.1 环境准备比想象中简单但有一个坑安装 SDK 只需要一条命令pip install anthropic接下来是配置密钥。我不建议直接把 API Key 硬编码到脚本里万一你把代码传到公开仓库密钥就泄露了。标准做法是用环境变量export ANTHROPIC_API_KEY你的密钥然后在 Python 里这样初始化客户端import os import anthropic client anthropic.Anthropic( api_keyos.environ.get(ANTHROPIC_API_KEY), )这里有个我踩过的坑SDK 初始化时会自动读取环境变量里的ANTHROPIC_API_KEY所以如果你写了api_keyos.environ.get(ANTHROPIC_API_KEY)而环境变量没设置Python 不会直接报错而是到真正发起请求时才抛认证异常。建议在初始化后立刻打印client.api_key的前几位做校验或者加一个显式的if not client.api_key: raise ValueError(API key missing)。3.2 第一次完整调用messages.create 的参数逐个说Claude 4 的 API 采用messages.create这个入口核心参数是model、max_tokens、messages以及可选的system、temperature、stop_sequences。下面是一个完整的示例脚本import anthropic client anthropic.Anthropic() response client.messages.create( modelclaude-4-sonnet, # 具体模型名以官方文档为准 max_tokens1024, temperature0.7, system你是一名技术写作助手擅长将复杂概念讲清楚。, messages[ {role: user, content: 请用三句话解释什么是 API并用快递柜做类比。} ], ) print(response.content[0].text)响应对象里最常用的是这几个字段content一个列表content[0].text就是模型输出的文本usage包含input_tokens和output_tokens用于统计开销stop_reason表示模型结束生成的原因可能是“stop_sequence”或“max_tokens”。我在生产脚本里一定会把usage打印到日志里做好成本追踪。不要嫌啰嗦等你发现某个脚本跑了一个月消耗了十几万 tokens 时就会感谢当初加的这行日志。3.3 流式输出与异步并发体验和效率一起拿如果直接在 API 调用里等完整结果长时间任务会等待很久用户端体验也不好。流式输出的做法是开启streamTrue让响应以增量的方式返回。用官方 SDK 的写法是with client.messages.stream( modelclaude-4-sonnet, max_tokens1024, messages[ {role: user, content: 写一段关于 Python 装饰器的简短介绍。} ], ) as stream: for text in stream.text_stream: print(text, end, flushTrue)这种写法的好处是首字延迟大幅降低尤其适合聊天式应用。另一个实用场景是并发处理如果你想一次性处理二十个文件不要用 for 循环挨个请求那样太慢。正确做法是用concurrent.futures或asyncio做并发控制import concurrent.futures from functools import partial def make_summary(content: str) - str: response client.messages.create( modelclaude-4-sonnet, max_tokens500, messages[{role: user, content: f总结以下内容{content}}], ) return response.content[0].text texts [...] # 你的文本列表 with concurrent.futures.ThreadPoolExecutor(max_workers5) as executor: results list(executor.map(make_summary, texts))注意并发数不要拉太高。API 有速率限制直接开 50 个并发大概率会触发限流反而拖慢整体速度。我个人测试下来max_workers5到max_workers8之间比较稳妥。3.4 异常处理与重试服务不会永远稳定调用外部 API 最容易出问题的三件事网络超时、限流、内容触发安全策略。我做脚本时一般会写这样的重试逻辑import time import anthropic def safe_call(client, **kwargs): max_retries 3 for attempt in range(max_retries): try: return client.messages.create(**kwargs) except anthropic.APIError as e: wait 2 ** attempt print(fAPI 错误{e}等待 {wait} 秒后重试) time.sleep(wait) except anthropic.APIStatusError as e: if e.status_code 429: time.sleep(10 * (attempt 1)) continue raise raise RuntimeError(重试次数耗尽)这里用了指数退避的方式第一秒第二次重试是 2 的幂次第三次是 4 秒再往上你基本要人工介入了。另外如果请求体里带了大段文本超过 10 万 tokens你需要在前端做好分块不能指望 API 帮你截断。否则会一直报输入过长的错误而且白白消耗重试时间。3.5 工具调用让模型操作外部函数和本地资源API 模式下最让人惊喜的功能是工具调用。它允许 Claude 4 在对话过程中主动调用你定义的 Python 函数比如查数据库、读文件、发请求。这个机制比单纯生成文本有用得多因为它让模型真正“做事”而不只是“说话”。先定义函数def get_weather(city: str) - str: 模拟天气查询实际使用时可接真实接口。 return f{city} 的天气晴26℃然后在 API 请求里声明这个工具response client.messages.create( modelclaude-4-sonnet, max_tokens1024, messages[ {role: user, content: 北京今天天气怎么样} ], tools[ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string} }, required: [city] } } } ], )模型返回的结果里如果没有直接给出答案而是要求调用get_weather你就执行函数把结果发回去再让模型基于工具结果组织最终回答。这里有个关键点工具调用的参数由模型生成所以你必须在函数体里做好参数校验。千万别信任模型给的“可能值”否则当一个不该出现的城市名传进来时你的系统会打出莫名的异常。4. 实战案例批量文档摘要与结构化提取项目的完整落地过程前两章的模板和脚本如果只是分开看价值有限。这章我把它们揉进一个真实项目里还原从需求分析到上线运行的整个过程。这个项目的需求是每周处理约两百份客户拜访记录输出摘要和三个关键字段客户预算意向、决策人、风险点。之前是人工一条条看现在要改成半自动流程。4.1 需求拆解不是“让 AI 做全部”而是“让人做决策”接到需求后我第一件事不是写提示词而是拆边界。我明确了两条规则AI 只负责初筛和格式化不能做最终判断涉及金额和合作意向的字段必须保留原文片段方便人工复核。这个边界设定很关键它决定了后面的提示词怎么设计。于是我把每个客户记录的处理流程定为读取全文、交给 Claude 4 生成结构化摘要、抽取三个关键字段、同时保留相关原文句子。最后再把全部结果写成 JSON 或 Excel供团队复核。比起让模型“自动生成结论”这种设计更能落进实际业务流程。4.2 提示词的私人订制从通用模板改到首发可用初始版本几乎照搬了第 2 章的数据整理模板跑完发现两个问题字段经常漏填摘要里出现“根据客户反馈”“综合来看”这类套话。于是我重写了提示把约束改得更具体角色你是一名资深销售运营助理。 背景以下是一段客户拜访记录需要生成用于内部CRM系统的结构化摘要。 任务提取三个字段预算意向高/中/低/未知、决策人姓名、主要风险点。 约束 - 摘要不超过80字使用第三人称 - 每个字段必须给出从原文摘录的支撑句子 - 原文没有提及的内容一律写“未提及”禁止推测。 输出格式 摘要... 预算意向... 决策人... 风险点... 支撑句...改动最大的地方是加了“禁止推测”和“必须给支撑句”。加了之后幻觉率肉眼可见地下降。因为模型知道输出要能被核对它就不敢随便编预算数字了。4.3 Python 脚本把“单条”变成“流水线”脚本部分我做得比较简单但完整读取一个 Excel 或 CSV 文件对每一行做 API 请求把返回结果写进新文件。核心就在这里代码长这样import csv import time import anthropic client anthropic.Anthropic() SYSTEM_PROMPT 你是一名资深销售运营助理严格遵循用户指令不推测不编造。 def process_record(record_text): response client.messages.create( modelclaude-4-sonnet, max_tokens512, systemSYSTEM_PROMPT, messages[ {role: user, content: f处理以下客户记录\n{record_text}} ], ) return response.content[0].text with open(records.csv, r, encodingutf-8) as infile, open(results.csv, w, encodingutf-8) as outfile: reader csv.DictReader(infile) writer csv.writer(outfile) writer.writerow([原文ID, 结果, 耗时]) for row in reader: started time.time() output process_record(row[record]) writer.writerow([row[id], output, round(time.time() - started, 2)])跑 200 条记录单条大约 3 到 6 秒总耗时大概在二十分钟左右。如果你觉得慢可以按第 3 章的方法加并发但我当时刻意没加因为团队还处在人工复核阶段输出太快反而来不及审。4.4 这个项目里踩过的三个坑第一个坑是模型把“未提及”写成“未知”。这在字段里看似差不多但业务语义完全不同。针对这个问题我在提示里同时给出两种选项如果是原文没写输出“未提及”如果是写了但看不懂才允许标“未知”。这个区分非常重要。第二个坑是 CSV 的分隔符问题。个别记录里的摘要包含逗号导致写入后字段错位。后来我在csv.writer里显式指定quotingcsv.QUOTE_ALL问题才解决。这种问题跟模型无关但自动化流程里必须处理。第三个坑是数量大之后偶发性的 API 超时导致整批任务中断。后来我套上了第 3 章那个safe_call函数并在循环外层加了断点续跑逻辑记录已经处理到的行号失败时从该行继续而不重头再来。这个能力对生产环境几乎是刚需。5. 让 Claude 4 更可靠防幻觉、控成本、管上下文模板和脚本都跑通之后真正拉开差距的是“可靠性”。这一节把我的实战心得浓缩成四条每一条都对应具体操作。5.1 防幻觉的正确姿势限制猜测空间要求可溯源模型幻觉没法根除但可以压制。最有效的一句话是要求它“必须指出信息来源或支撑句”。只要输出里有“根据原文”“原文未提及”“无法确认”这类标记模型编造的概率就低很多。我给所有数据提取类提示都加上了这条规则。个人经验是防范幻觉靠的不是“请诚实地回答”而是给模型一个可以返回“不知道”的安全出口。如果你把所有字段都设为必填模型就倾向于用幻觉填满空白让它允许“未提及”它就会更坦然地承认信息缺失。5.2 控制成本的思路不只看单次消耗要看“输出质量单价”成本优化不是把max_tokens调小那么简单。真正省钱的思路是提升单次请求的“有效产出率”。举个例子让模型一次生成 5 个标题比调用 5 次、每次生成一个标题省 80% 的输入 tokens。批量生成文案时我一般要求模型一次性输出全部内容然后再自己切分而不是循环调用。另一个实用技巧是用temperature0处理事实性提取任务。这个参数虽然不影响 token 计费但能减少无意义的措辞变换让回答更稳定间接降低你为了“得到正确答案”而反复请求的次数。还有一个很容易忽略的开销点把长文本完整塞进用户消息每跑一轮请求都要重新计费。如果是一些固定不变的背景资料我建议你在代码层做裁剪或摘要只把当前任务相关的上下文传进去。别把大段合同条款全塞进提示里让模型“看着办”它会抓住无关细节还烧钱。5.3 上下文窗口管理的三个策略Claude 4 有较大的上下文窗口但所有模型越长越容易“走神”。如果任务涉及长文档我会分三步走先让模型做分段摘要每段 500 字左右再把分段摘要拼接为新的输入最后基于摘要生成完整结论。这个方法的本质是把高密度信息保存在上下文里而不是让模型在原始文本里大海捞针。如果你需要模型对文本做定位引用那就不能压缩而是要原样截取相关段落标注行号再提问。比如“第 12 段中提到的方案存在什么问题”这种基于位置的提问比直接说“这份方案好不好”精确得多。5.4 调试提示的常规流程别靠感觉搭评估集提示词是不是好用不能靠感觉要用评估说话。我在项目里会划分一个小评估集大概 20 到 30 条有代表性的输入然后记录每次提示改动带来的输出变化。比较有效的做法是列出“必达项”比如字段完整率、错误推断率、格式合格率。改动提示后跑一遍评估集分数涨了才保留分数跌了就回滚。这个流程做起来很简单甚至不需要复杂框架就是个 Excel 加几个脚本。但它的价值非常大。有一次我为了“更自然”改了一个系统提示自测单条结果很满意结果跑评估集发现字段完整率从 96% 掉到 80%差点线上翻车。从此之后凡是动提示我必须先跑评估集再发布。最后分享一个小技巧把你所有提示按“角色-背景-任务-约束-输出格式”这五段固定下来长期固化成一套自己的模板库。初期会有点不适应但用上一周后你会发现95% 的场景都是在往这套骨架里换血换肉。把模板固化成习惯Claude 4 在你手里才算真正“精通”。