第10篇提示词工程的企业级实践——从单次调用到生产系统适用人群高阶→架构师 | 字数约25,000字 | 预计阅读时间60分钟前言如果你一直跟着这个系列读到了这里恭喜你——你已经掌握了提示词工程的全部招式认知框架第1篇理解提示词的本质方法论工具第2~3篇四步法与避坑指南进阶技术第4~6篇角色设定、结构化、Few-shot/CoT高级专题第7~9篇CoT深度解析、Agent、多模态但有一个问题所有这些能力目前都是个人技能——你可以自己写出很好的提示词但如何让整个团队、整个组织都具备这种能力这就是第10篇要解决的问题提示词工程的企业级实践。我们将从以下六个维度展开团队协作——多人如何共同开发和维护提示词版本管理——提示词也需要Git质量保障——测试、评估、监控成本控制——Token预算与性能优化安全合规——企业级的安全治理组织建设——从个人英雄到工程文化第一章团队协作——从个人到组织1.1 提示词开发的孤岛问题在很多组织中提示词开发目前处于孤岛状态产品经理写了一套提示词工程师写了一套提示词运营团队也写了一套提示词各套之间没有统一标准没有知识共享结果同样的错误在三个团队中重复犯好的做法没有被沉淀。1.2 提示词的生命周期管理就像一个软件产品有生命周期提示词也应该有需求阶段 → 设计阶段 → 开发阶段 → 测试阶段 → 部署阶段 → 监控阶段 → 迭代阶段每个阶段的责任人阶段责任人产出物需求分析产品经理提示词需求文档设计提示词工程师提示词设计方案含测试用例开发提示词工程师提示词初版测试QA工程师测试报告部署运维工程师部署配置监控数据工程师监控面板迭代全团队迭代优化记录1.3 提示词评审机制就像代码需要 Code Review提示词也需要Prompt Review。审查清单□ 角色设定是否清晰、具体 □ 任务定义是否明确、无歧义 □ 上下文信息是否完整、无矛盾 □ 输出格式是否指定、合理 □ 是否包含约束条件 □ 是否考虑了边界情况和异常处理 □ 是否包含安全性要求 □ 是否存在冗余或重复的信息 □ 是否存在否定黑洞大量不要· □ Token预算是否合理审查流程作者提交提示词 设计文档至少 1 名高级提示词工程师审查审查通过后进入测试阶段测试通过后部署上线1.4 提示词知识库企业应该建立内部的提示词知识库沉淀最佳实践提示词知识库/ ├── 模板库/ │ ├── 内容生成模板.md │ ├── 数据分析模板.md │ ├── 客服回复模板.md │ └── 代码审查模板.md ├── 用例库/ │ ├── 成功案例.md │ ├── 失败案例.md │ └── A/B测试记录.md ├── 规范/ │ ├── 命名规范.md │ ├── 格式规范.md │ └── 安全规范.md └── 学习资源/ ├── 新手上手指南.md └── FAQ.md第二章版本管理——提示词也需要Git2.1 为什么需要版本管理很多团队还在用Word文档文件名来管理提示词的版本“提示词_v2_最终版.docx”“提示词_v2_最终版_修改版.docx”“提示词_v2_最终版_修改版_真的最终版.docx”这种方式在只有 1-2 个人时凑合能用但在团队协作中绝对是灾难。2.2 提示词版本管理的要素每个提示词版本应该记录版本号v2.1.0 作者张三 创建时间2026-05-19 最后修改2026-05-20 修改内容 - 新增增加了对边界情况的处理 - 修改优化了角色设定的措辞 - 删除移除了不必要的约束条件 审批人李四 状态已部署 关联测试用例TC-20260519-0012.3 使用Git管理提示词把提示词当作代码一样用 Git 管理prompt-repo/ ├── prompts/ │ ├── customer-service/ │ │ ├── complaint-resolution.prompt.md │ │ └── order-inquiry.prompt.md │ ├── content-generation/ │ │ ├── blog-post.prompt.md │ │ └── social-media.prompt.md │ └──># 可复用的角色定义│ ├── formats/# 可复用的输出格式定义│ └── snippets/# 可复用的提示词片段└── docs/ ├── CONTRIBUTING.md └── STYLE_GUIDE.mdGit工作流# 创建新提示词gitcheckout-bfeature/new-analysis-prompt# 开发和测试...修改提示词文件...运行测试# 提交gitaddprompts/data-analysis/sales-report.prompt.mdgitcommit-mfeat: 新增销售分析提示词 v2.1# 创建PRgitpush origin feature/new-analysis-prompt# → 触发 Review 流程# 合并到主分支gitcheckout maingitmerge feature/new-analysis-promptgittag v2.1.02.4 提示词的语义化版本参考 SemVer语义化版本提示词可以这样管理版本号主版本号.次版本号.修订号 主版本号提示词结构发生重大变化如新增/删除了主要模块 次版本号提示词功能有增强如新增了约束条件 修订号微小修改如修复了措辞错误 示例 v1.0.0 → 初始版本 v1.1.0 → 新增了输出格式模块 v1.2.0 → 改进了角色设定 v1.2.1 → 修复了一处错别字 v2.0.0 → 整体重构了提示词结构第三章质量保障——测试、评估、监控3.1 提示词的测试金字塔类似软件测试提示词测试也可以分层/\ / \ 手动评估少量、高价值 / \ /______\ 自动化质量检查中等数量 / \ / \ 单元测试大量、自动化 /____________\第一层单元测试检查提示词格式是否合规检查变量是否都能正确替换检查是否有语法错误deftest_prompt_format(prompt_template):# 检查所有变量是否都有对应的值variablesextract_variables(prompt_template)assertall(vintest_dataforvinvariables),fMissing variables:{variables-test_data.keys()}# 检查提示词长度assertlen(prompt_template)MAX_TOKENS,Prompt exceeds token limit# 检查是否有未闭合的标记assertprompt_template.count({)prompt_template.count(})第二层自动化质量检查用测试用例运行提示词检查输出是否满足约束条件检查输出格式是否正确deftest_prompt_output(prompt,test_cases):forcaseintest_cases:outputrun_llm(prompt,case.input)# 检查格式assertcheck_format(output,case.expected_format)# 检查约束assertlen(output)case.max_lengthassertnotcontains_forbidden_terms(output,case.forbidden_terms)# 记录结果record_test_result(case.id,output)第三层手动评估由领域专家评估输出质量评估准确性、完整性、可用性给出定性反馈3.2 评估指标体系企业级的提示词评估需要量化指标定义测量方式目标值格式遵从率输出符合指定格式的比例自动化检查 95%约束满足率满足所有约束条件的比例自动化检查 90%首次通过率一次生成即达到质量标准的比例人工评估 70%用户满意度用户对输出的评分用户反馈 4.0/5.0平均迭代次数达到质量标准所需的修改轮数系统记录 2轮Token消耗每次请求的平均Token数系统记录持续优化3.3 回归测试当提示词更新时必须进行回归测试确保旧功能不被破坏。defregression_test(old_version,new_version,test_suite):old_resultsrun_test_suite(old_version,test_suite)new_resultsrun_test_suite(new_version,test_suite)regressions[]improvements[]forcase_idintest_suite:oldold_results[case_id]newnew_results[case_id]ifnew.passedandnotold.passed:improvements.append(case_id)elifold.passedandnotnew.passed:regressions.append(case_id)assertlen(regressions)0,fRegression detected in cases:{regressions}3.4 生产监控上线后需要持续监控提示词的表现需要监控的指标响应时间模型返回结果的速度错误率模型返回错误/异常的比例Token消耗每次调用的Token数影响成本用户反馈用户主动给出的反馈隐性指标如用户是否在收到结果后继续追问可能是结果不够好监控面板示例┌─────────────────────────────────────────────────────────┐ │ Prompt Monitoring Dashboard │ ├─────────────────────────────────────────────────────────┤ │ Prompt: sales-report-generator v2.1.0 │ │ │ │ 今日调用量1,234 Token消耗987,654 │ │ 平均耗时2.3s 错误率1.2% │ │ 格式遵从率97.8% 约束满足率95.3% │ │ 用户满意度4.2/5.0 │ │ │ │ 趋势图[最近7天的指标变化折线图] │ │ │ │ 最近错误 │ │ - [10:23] 输出超出字数限制 │ │ - [09:45] 格式解析失败 │ │ │ └─────────────────────────────────────────────────────────┘第四章成本控制——Token预算与性能优化4.1 提示词的成本结构企业使用 LLM 的成本主要由以下因素决定总成本 输入Token数 × 输入单价 输出Token数 × 输出单价 API调用次数 × 固定费用 其中 - 输入Token数 提示词长度 历史对话如果包含 - 输出Token数 模型回答的长度 - 输入单价 输出单价写入成本低于读取成本4.2 Token优化策略策略一精简提示词优化前优化后Token节省“你是一位非常出色、经验丰富、有十年从业经历的资深市场分析师”“你是资深市场分析师10年经验”~40%“帮我写一份非常详细、全面、深入、完整的市场分析报告”“写一份市场分析报告”~50%策略二复用系统提示词把不变的 System Prompt 和变化的 User Prompt 分开System Prompt长但只传输一次缓存或固定在API请求中User Prompt短每次变化只传变化的部分在支持角色分离的API中System Prompt 在长连接中可以只传一次。策略三控制历史对话长度对于长对话定期做对话压缩defcompress_conversation(conversation_history,max_tokens2000):iftoken_count(conversation_history)max_tokens:returnconversation_history# 保留最近的N轮对话recentconversation_history[-5:]# 对较早的对话做摘要earlierconversation_history[:-5]summarysummarize_conversation(earlier)return[{role:system,content:f早期对话摘要{summary}}]recent策略四使用更短的模型对于简单任务使用更小、更便宜的模型如 GPT-4o-mini 而不是 GPT-4o。任务复杂度推荐模型相对成本简单翻译/格式化小型模型1x中等分析/生成中型模型3-5x复杂推理/Agent大型模型10-20x4.3 API调用的批处理对于大批量相似任务使用批处理可以降低成本# 不推荐的逐条调用foriteminitems:responsecall_llm(single_prompt(item))# 推荐的批处理batch_promptf请依次处理以下{len(items)}个项目按顺序输出结果\nfori,iteminenumerate(items):batch_promptf项目{i1}:{item}\nbatch_prompt\n请按同样的顺序输出每个项目的处理结果。responsecall_llm(batch_prompt)但要注意批处理的质量上限——一次处理太多项目可能导致每个项目的质量下降。一般建议每次 5-10 个项目。4.4 缓存策略对于重复性高的查询缓存可以显著降低成本classPromptCache:def__init__(self,llm):self.cache{}self.llmllmdefcall_with_cache(self,prompt,temperature0):# 对于 temperature0 的调用结果可预测可以缓存cache_keyhash(prompt)ifcache_keyinself.cache:returnself.cache[cache_key]resultself.llm.call(prompt,temperaturetemperature)self.cache[cache_key]resultreturnresult典型的缓存命中场景固定的模板内容生成如每日报告的格式固定知识库查询相同的问题返回相同答案系统提示词的输出角色定义等不变化的输入第五章安全合规——企业级的安全治理5.1 提示词注入攻击的防护提示词注入是企业级 AI 应用面临的最大安全威胁。攻击方式用户通过输入恶意内容覆盖 System Prompt用户尝试引导模型泄露敏感信息用户尝试让模型执行未授权的操作防护策略策略一输入过滤在用户输入到达模型之前检测并过滤恶意内容defsanitize_input(user_input):# 检测常见的注入模式injection_patterns[r忽略(所有)?(之前|前面)?的(指令|指示|规则),rsystem\s*(prompt|message),r(忘记|无视|不要管)(所有|之前的)?(指令|限制)]forpatternininjection_patterns:ifre.search(pattern,user_input,re.IGNORECASE):returnNone,输入包含不允许的内容returnuser_input,None策略二输出过滤模型返回的内容也应当检测防止敏感信息泄露defsanitize_output(model_output):# 检测是否包含敏感信息sensitive_patterns[rpassword,rapi[_-]?key,rsecret,r\b\d{4}-\d{4}-\d{4}-\d{4}\b# 信用卡号]forpatterninsensitive_patterns:ifre.search(pattern,model_output,re.IGNORECASE):returnNone,输出可能包含敏感信息returnmodel_output,None策略三权限分离模型不直接访问敏感系统而是通过中间层用户 → 模型 → 中间层权限控制 → 外部系统中间层负责验证模型的操作请求是否合法限制可操作的资源范围记录所有操作日志5.2 数据隐私保护原则一最小化数据原则只向模型传递完成任务所需的最少数据。❌ “用户张三身份证号110101…手机号138…地址北京市…要求退款。”✅ “用户张三要求退款。”原则二数据脱敏如果必须传递敏感数据先做脱敏处理defmask_pii(text):textre.sub(r\b1[3-9]\d{9}\b,[手机号已脱敏],text)# 手机号textre.sub(r\b\d{18}[\dXx]\b,[身份证已脱敏],text)# 身份证textre.sub(r\b\d{16}\b,[银行卡已脱敏],text)# 银行卡号returntext原则三数据不落地模型返回的内容也不应包含原始敏感数据。在 System Prompt 中明确要求“在回答中不得包含用户的个人隐私信息姓名、电话、地址、身份证号等使用’该用户’、相关账户’等替代。”5.3 合规要求不同的行业和地区有不同的合规要求地区/行业法规对AI应用的要求中国《生成式人工智能服务管理暂行办法》内容安全、真实标注欧盟GDPR数据最小化、用户知情权金融行业《个人信息保护法》不允许用客户数据进行模型训练医疗行业HIPAA美国PHI受保护的健康信息不得泄露企业合规检查清单□ 是否有数据分类分级制度哪些数据可以喂模型 □ 是否有用户告知机制用户知道他们在和AI对话吗 □ 是否有内容审核机制模型输出是否需要人工审核 □ 是否有数据保留策略对话记录保留多久 □ 是否有模型选择依据为什么选择这个模型合规吗 □ 是否有应急预案如果模型输出违规内容怎么处理第六章组织建设——从个人英雄到工程文化6.1 提示词工程师的角色定义在企业中提示词工程师可以有不同定位角色一提示词专家Individual Contributor专注于写高质量提示词为其他团队提供提示词咨询维护提示词模板库和最佳实践角色二AI应用架构师设计企业级AI应用的提示词架构设计Agent系统、RAG系统、多模型路由制定提示词的工程规范角色三AI产品经理定义AI产品的行为模式设计用户体验中的AI交互平衡质量、成本、速度三者关系6.2 团队技能矩阵一个成熟的提示词工程团队应该具备以下能力初级工程师 □ 能写清晰的提示词 □ 理解基本的角色设定 □ 知道常见的错误模式 中级工程师 □ 精通结构化提示词设计 □ 能使用Few-shot和CoT □ 能设计和评估测试用例 □ 理解成本优化 高级工程师 □ 能设计Agent系统 □ 能搭建提示词工程流水线 □ 能进行生产系统的监控和优化 □ 能给团队做培训和指导 架构师 □ 能设计企业级AI架构 □ 制定规范和标准 □ 评估和选型AI技术栈 □ 推动组织的AI文化建设6.3 建立提示词工程文化文化要素一共享所有提示词对团队可见好的做法及时分享失败的案例也不隐藏文化要素二持续学习定期组织提示词工作坊跟踪最新研究和技术进展实验新的提示词技术文化要素三数据驱动所有提示词的效果都可量化决策基于数据而非直觉持续做A/B测试文化要素四安全第一安全审查是上线的前置条件敏感操作有记录安全意识渗透在每个人的日常工作中第七章10篇系列总结与知识图谱7.1 系列回顾让我们回望整个系列的学习路径入门篇 进阶篇 高阶篇 ┌─────────────────┐ ┌──────────────────────────┐ ┌────────────────────────────┐ │ 第1篇认知 │ │ 第4篇角色与上下文 │ │ 第7篇CoT深度解析 │ │ 什么是提示词 │──▶ │ 如何让AI扮演专家 │──▶ │ 推理能力如何解锁 │ │ ─────────────── │ │ ──────────────────────── │ │ ────────────────────────── │ │ 本质信号系统 │ │ 三要素角色模型 │ │ Self-Consistency │ │ Token工作机制 │ │ 上下文分层管理 │ │ Tree-of-Thought │ │ 五个功能层次 │ │ 角色上下文协同效应 │ │编程/数学/逻辑专题应用 │ └─────────────────┘ └──────────────────────────┘ └────────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────┐ ┌──────────────────────────┐ ┌────────────────────────────┐ │ 第2篇四步法 │ │ 第5篇结构化提示词 │ │ 第8篇Agent模式 │ │ 黄金四步法 │──▶ │ 从聊天到系统化输出 │──▶ │ 让AI从说话到做事 │ │ ─────────────── │ │ ──────────────────────── │ │ ────────────────────────── │ │ Who→What→ │ │ 模板化→模块化→管道化 │ │ ReAct循环 │ │ Context→Format │ │ 条件逻辑动态注入 │ │ 工具调用机制 │ └─────────────────┘ └──────────────────────────┘ │ 多Agent协作 │ │ │ └────────────────────────────┘ ▼ ▼ │ ┌─────────────────┐ ┌──────────────────────────┐ │ │ 第3篇避坑指南 │ │ 第6篇Few-shotCoT │ │ │ 8个常见错误 │──▶ │ 教会AI如何思考 │ │ │ ─────────────── │ │ ──────────────────────── │ │ │ 从失败中学习 │ │ 示例驱动的学习方法 │ │ └─────────────────┘ │ 思维链引导推理 │ │ └──────────────────────────┘ │ ┌────────────────────────────┐ │ 第9篇多模态提示词 │ │ 文本图像代码协同 │ │ ────────────────────────── │ │ 视觉设计原则 │ │ 图文生成与编辑 │ │ UI→代码 │ └────────────────────────────┘ │ ▼ ┌────────────────────────────┐ │ 第10篇企业级实践本篇 │ │ 从个人技能到组织能力 │ │ ────────────────────────── │ │ 团队协作·版本管理·质量保障 │ │ 成本控制·安全合规·组织建设 │ └────────────────────────────┘7.2 核心能力模型学完这10篇你应该具备以下核心能力能力一提示词设计能力能够根据任务需求设计高质量的提示词掌握角色设定、上下文管理、输出控制等技术能够识别和避免常见错误能力二提示词工程能力能够设计结构化、可复用的提示词模板能够使用 Few-shot、CoT 等高级技术能够设计 Agent 系统和工具调用能力三提示词质量管理能力能够建立测试体系和评估指标能够进行回归测试和A/B测试能够监控和分析生产环境中的表现能力四提示词架构能力能够设计企业级的提示词架构能够平衡质量、成本、速度能够确保安全合规7.3 持续学习的方向提示词工程是一个快速发展的领域。以下是几个值得持续关注的方向自动提示词优化DSPy、Prompt Optimizer 等工具正在快速发展未来提示词的编写可能更多由 AI 完成人类转向审查和策略定义。多模态深化视频理解、3D生成、实时交互等多模态能力正在快速发展提示词设计需要适应新的模态。Agent 生态Agent 框架LangChain、AutoGPT、CrewAI等正在快速成熟与提示词的结合越来越紧密。端侧模型小模型如手机端、IoT设备上的模型的提示词设计和大模型有显著不同这是一个尚未充分开发的领域。提示词安全随着 AI 应用的普及提示词注入、数据泄露等安全问题将越来越重要。写在最后——给读者的一封信亲爱的读者如果你读完了这10篇大约用了 10 个小时的阅读时间。但这 10 小时可能节省你1000 小时的自我摸索时间。提示词工程是一个实践出真知的领域——所有理论最终都要回到写出来、跑一下、看结果这个循环。这 10 篇给你的不是标准答案而是一张认知地图、一套方法论工具箱、一份避坑指南。接下来你要做的三件事是第一用起来。读完第2篇就立刻用四步法重写你今天要用的提示词。读完第6篇就在你的下一个任务中加入让我们一步一步思考。读完第8篇就想想你工作中有哪些场景可以引入 Agent 模式。第二建立自己的案例库。每次写好一个优质的提示词把它保存下来加上注释为什么这么写、解决了什么问题。半年后你就有了一份个人最佳实践集。第三分享出去。把你学到的教给别人。教是最好的学——当你向同事解释为什么角色设定要包含三要素时你对这个概念的理解会再深一层。最后记住一句话提示词的终极目标不是让模型回答正确而是让模型的正确回答可直接用于你的工作流。愿你在提示词工程的道路上越走越远。—— 系列完 ——所有伟大的工程师都是从写好第一行代码开始的。所有伟大的提示词工程师都是从写好第一个提示词开始的。你已经有了10篇的知识储备——现在去写你的第一个、第十个、第一百个提示词吧。
第10篇：提示词工程的企业级实践——从单次调用到生产系统
发布时间：2026/5/20 1:45:23
第10篇提示词工程的企业级实践——从单次调用到生产系统适用人群高阶→架构师 | 字数约25,000字 | 预计阅读时间60分钟前言如果你一直跟着这个系列读到了这里恭喜你——你已经掌握了提示词工程的全部招式认知框架第1篇理解提示词的本质方法论工具第2~3篇四步法与避坑指南进阶技术第4~6篇角色设定、结构化、Few-shot/CoT高级专题第7~9篇CoT深度解析、Agent、多模态但有一个问题所有这些能力目前都是个人技能——你可以自己写出很好的提示词但如何让整个团队、整个组织都具备这种能力这就是第10篇要解决的问题提示词工程的企业级实践。我们将从以下六个维度展开团队协作——多人如何共同开发和维护提示词版本管理——提示词也需要Git质量保障——测试、评估、监控成本控制——Token预算与性能优化安全合规——企业级的安全治理组织建设——从个人英雄到工程文化第一章团队协作——从个人到组织1.1 提示词开发的孤岛问题在很多组织中提示词开发目前处于孤岛状态产品经理写了一套提示词工程师写了一套提示词运营团队也写了一套提示词各套之间没有统一标准没有知识共享结果同样的错误在三个团队中重复犯好的做法没有被沉淀。1.2 提示词的生命周期管理就像一个软件产品有生命周期提示词也应该有需求阶段 → 设计阶段 → 开发阶段 → 测试阶段 → 部署阶段 → 监控阶段 → 迭代阶段每个阶段的责任人阶段责任人产出物需求分析产品经理提示词需求文档设计提示词工程师提示词设计方案含测试用例开发提示词工程师提示词初版测试QA工程师测试报告部署运维工程师部署配置监控数据工程师监控面板迭代全团队迭代优化记录1.3 提示词评审机制就像代码需要 Code Review提示词也需要Prompt Review。审查清单□ 角色设定是否清晰、具体 □ 任务定义是否明确、无歧义 □ 上下文信息是否完整、无矛盾 □ 输出格式是否指定、合理 □ 是否包含约束条件 □ 是否考虑了边界情况和异常处理 □ 是否包含安全性要求 □ 是否存在冗余或重复的信息 □ 是否存在否定黑洞大量不要· □ Token预算是否合理审查流程作者提交提示词 设计文档至少 1 名高级提示词工程师审查审查通过后进入测试阶段测试通过后部署上线1.4 提示词知识库企业应该建立内部的提示词知识库沉淀最佳实践提示词知识库/ ├── 模板库/ │ ├── 内容生成模板.md │ ├── 数据分析模板.md │ ├── 客服回复模板.md │ └── 代码审查模板.md ├── 用例库/ │ ├── 成功案例.md │ ├── 失败案例.md │ └── A/B测试记录.md ├── 规范/ │ ├── 命名规范.md │ ├── 格式规范.md │ └── 安全规范.md └── 学习资源/ ├── 新手上手指南.md └── FAQ.md第二章版本管理——提示词也需要Git2.1 为什么需要版本管理很多团队还在用Word文档文件名来管理提示词的版本“提示词_v2_最终版.docx”“提示词_v2_最终版_修改版.docx”“提示词_v2_最终版_修改版_真的最终版.docx”这种方式在只有 1-2 个人时凑合能用但在团队协作中绝对是灾难。2.2 提示词版本管理的要素每个提示词版本应该记录版本号v2.1.0 作者张三 创建时间2026-05-19 最后修改2026-05-20 修改内容 - 新增增加了对边界情况的处理 - 修改优化了角色设定的措辞 - 删除移除了不必要的约束条件 审批人李四 状态已部署 关联测试用例TC-20260519-0012.3 使用Git管理提示词把提示词当作代码一样用 Git 管理prompt-repo/ ├── prompts/ │ ├── customer-service/ │ │ ├── complaint-resolution.prompt.md │ │ └── order-inquiry.prompt.md │ ├── content-generation/ │ │ ├── blog-post.prompt.md │ │ └── social-media.prompt.md │ └──># 可复用的角色定义│ ├── formats/# 可复用的输出格式定义│ └── snippets/# 可复用的提示词片段└── docs/ ├── CONTRIBUTING.md └── STYLE_GUIDE.mdGit工作流# 创建新提示词gitcheckout-bfeature/new-analysis-prompt# 开发和测试...修改提示词文件...运行测试# 提交gitaddprompts/data-analysis/sales-report.prompt.mdgitcommit-mfeat: 新增销售分析提示词 v2.1# 创建PRgitpush origin feature/new-analysis-prompt# → 触发 Review 流程# 合并到主分支gitcheckout maingitmerge feature/new-analysis-promptgittag v2.1.02.4 提示词的语义化版本参考 SemVer语义化版本提示词可以这样管理版本号主版本号.次版本号.修订号 主版本号提示词结构发生重大变化如新增/删除了主要模块 次版本号提示词功能有增强如新增了约束条件 修订号微小修改如修复了措辞错误 示例 v1.0.0 → 初始版本 v1.1.0 → 新增了输出格式模块 v1.2.0 → 改进了角色设定 v1.2.1 → 修复了一处错别字 v2.0.0 → 整体重构了提示词结构第三章质量保障——测试、评估、监控3.1 提示词的测试金字塔类似软件测试提示词测试也可以分层/\ / \ 手动评估少量、高价值 / \ /______\ 自动化质量检查中等数量 / \ / \ 单元测试大量、自动化 /____________\第一层单元测试检查提示词格式是否合规检查变量是否都能正确替换检查是否有语法错误deftest_prompt_format(prompt_template):# 检查所有变量是否都有对应的值variablesextract_variables(prompt_template)assertall(vintest_dataforvinvariables),fMissing variables:{variables-test_data.keys()}# 检查提示词长度assertlen(prompt_template)MAX_TOKENS,Prompt exceeds token limit# 检查是否有未闭合的标记assertprompt_template.count({)prompt_template.count(})第二层自动化质量检查用测试用例运行提示词检查输出是否满足约束条件检查输出格式是否正确deftest_prompt_output(prompt,test_cases):forcaseintest_cases:outputrun_llm(prompt,case.input)# 检查格式assertcheck_format(output,case.expected_format)# 检查约束assertlen(output)case.max_lengthassertnotcontains_forbidden_terms(output,case.forbidden_terms)# 记录结果record_test_result(case.id,output)第三层手动评估由领域专家评估输出质量评估准确性、完整性、可用性给出定性反馈3.2 评估指标体系企业级的提示词评估需要量化指标定义测量方式目标值格式遵从率输出符合指定格式的比例自动化检查 95%约束满足率满足所有约束条件的比例自动化检查 90%首次通过率一次生成即达到质量标准的比例人工评估 70%用户满意度用户对输出的评分用户反馈 4.0/5.0平均迭代次数达到质量标准所需的修改轮数系统记录 2轮Token消耗每次请求的平均Token数系统记录持续优化3.3 回归测试当提示词更新时必须进行回归测试确保旧功能不被破坏。defregression_test(old_version,new_version,test_suite):old_resultsrun_test_suite(old_version,test_suite)new_resultsrun_test_suite(new_version,test_suite)regressions[]improvements[]forcase_idintest_suite:oldold_results[case_id]newnew_results[case_id]ifnew.passedandnotold.passed:improvements.append(case_id)elifold.passedandnotnew.passed:regressions.append(case_id)assertlen(regressions)0,fRegression detected in cases:{regressions}3.4 生产监控上线后需要持续监控提示词的表现需要监控的指标响应时间模型返回结果的速度错误率模型返回错误/异常的比例Token消耗每次调用的Token数影响成本用户反馈用户主动给出的反馈隐性指标如用户是否在收到结果后继续追问可能是结果不够好监控面板示例┌─────────────────────────────────────────────────────────┐ │ Prompt Monitoring Dashboard │ ├─────────────────────────────────────────────────────────┤ │ Prompt: sales-report-generator v2.1.0 │ │ │ │ 今日调用量1,234 Token消耗987,654 │ │ 平均耗时2.3s 错误率1.2% │ │ 格式遵从率97.8% 约束满足率95.3% │ │ 用户满意度4.2/5.0 │ │ │ │ 趋势图[最近7天的指标变化折线图] │ │ │ │ 最近错误 │ │ - [10:23] 输出超出字数限制 │ │ - [09:45] 格式解析失败 │ │ │ └─────────────────────────────────────────────────────────┘第四章成本控制——Token预算与性能优化4.1 提示词的成本结构企业使用 LLM 的成本主要由以下因素决定总成本 输入Token数 × 输入单价 输出Token数 × 输出单价 API调用次数 × 固定费用 其中 - 输入Token数 提示词长度 历史对话如果包含 - 输出Token数 模型回答的长度 - 输入单价 输出单价写入成本低于读取成本4.2 Token优化策略策略一精简提示词优化前优化后Token节省“你是一位非常出色、经验丰富、有十年从业经历的资深市场分析师”“你是资深市场分析师10年经验”~40%“帮我写一份非常详细、全面、深入、完整的市场分析报告”“写一份市场分析报告”~50%策略二复用系统提示词把不变的 System Prompt 和变化的 User Prompt 分开System Prompt长但只传输一次缓存或固定在API请求中User Prompt短每次变化只传变化的部分在支持角色分离的API中System Prompt 在长连接中可以只传一次。策略三控制历史对话长度对于长对话定期做对话压缩defcompress_conversation(conversation_history,max_tokens2000):iftoken_count(conversation_history)max_tokens:returnconversation_history# 保留最近的N轮对话recentconversation_history[-5:]# 对较早的对话做摘要earlierconversation_history[:-5]summarysummarize_conversation(earlier)return[{role:system,content:f早期对话摘要{summary}}]recent策略四使用更短的模型对于简单任务使用更小、更便宜的模型如 GPT-4o-mini 而不是 GPT-4o。任务复杂度推荐模型相对成本简单翻译/格式化小型模型1x中等分析/生成中型模型3-5x复杂推理/Agent大型模型10-20x4.3 API调用的批处理对于大批量相似任务使用批处理可以降低成本# 不推荐的逐条调用foriteminitems:responsecall_llm(single_prompt(item))# 推荐的批处理batch_promptf请依次处理以下{len(items)}个项目按顺序输出结果\nfori,iteminenumerate(items):batch_promptf项目{i1}:{item}\nbatch_prompt\n请按同样的顺序输出每个项目的处理结果。responsecall_llm(batch_prompt)但要注意批处理的质量上限——一次处理太多项目可能导致每个项目的质量下降。一般建议每次 5-10 个项目。4.4 缓存策略对于重复性高的查询缓存可以显著降低成本classPromptCache:def__init__(self,llm):self.cache{}self.llmllmdefcall_with_cache(self,prompt,temperature0):# 对于 temperature0 的调用结果可预测可以缓存cache_keyhash(prompt)ifcache_keyinself.cache:returnself.cache[cache_key]resultself.llm.call(prompt,temperaturetemperature)self.cache[cache_key]resultreturnresult典型的缓存命中场景固定的模板内容生成如每日报告的格式固定知识库查询相同的问题返回相同答案系统提示词的输出角色定义等不变化的输入第五章安全合规——企业级的安全治理5.1 提示词注入攻击的防护提示词注入是企业级 AI 应用面临的最大安全威胁。攻击方式用户通过输入恶意内容覆盖 System Prompt用户尝试引导模型泄露敏感信息用户尝试让模型执行未授权的操作防护策略策略一输入过滤在用户输入到达模型之前检测并过滤恶意内容defsanitize_input(user_input):# 检测常见的注入模式injection_patterns[r忽略(所有)?(之前|前面)?的(指令|指示|规则),rsystem\s*(prompt|message),r(忘记|无视|不要管)(所有|之前的)?(指令|限制)]forpatternininjection_patterns:ifre.search(pattern,user_input,re.IGNORECASE):returnNone,输入包含不允许的内容returnuser_input,None策略二输出过滤模型返回的内容也应当检测防止敏感信息泄露defsanitize_output(model_output):# 检测是否包含敏感信息sensitive_patterns[rpassword,rapi[_-]?key,rsecret,r\b\d{4}-\d{4}-\d{4}-\d{4}\b# 信用卡号]forpatterninsensitive_patterns:ifre.search(pattern,model_output,re.IGNORECASE):returnNone,输出可能包含敏感信息returnmodel_output,None策略三权限分离模型不直接访问敏感系统而是通过中间层用户 → 模型 → 中间层权限控制 → 外部系统中间层负责验证模型的操作请求是否合法限制可操作的资源范围记录所有操作日志5.2 数据隐私保护原则一最小化数据原则只向模型传递完成任务所需的最少数据。❌ “用户张三身份证号110101…手机号138…地址北京市…要求退款。”✅ “用户张三要求退款。”原则二数据脱敏如果必须传递敏感数据先做脱敏处理defmask_pii(text):textre.sub(r\b1[3-9]\d{9}\b,[手机号已脱敏],text)# 手机号textre.sub(r\b\d{18}[\dXx]\b,[身份证已脱敏],text)# 身份证textre.sub(r\b\d{16}\b,[银行卡已脱敏],text)# 银行卡号returntext原则三数据不落地模型返回的内容也不应包含原始敏感数据。在 System Prompt 中明确要求“在回答中不得包含用户的个人隐私信息姓名、电话、地址、身份证号等使用’该用户’、相关账户’等替代。”5.3 合规要求不同的行业和地区有不同的合规要求地区/行业法规对AI应用的要求中国《生成式人工智能服务管理暂行办法》内容安全、真实标注欧盟GDPR数据最小化、用户知情权金融行业《个人信息保护法》不允许用客户数据进行模型训练医疗行业HIPAA美国PHI受保护的健康信息不得泄露企业合规检查清单□ 是否有数据分类分级制度哪些数据可以喂模型 □ 是否有用户告知机制用户知道他们在和AI对话吗 □ 是否有内容审核机制模型输出是否需要人工审核 □ 是否有数据保留策略对话记录保留多久 □ 是否有模型选择依据为什么选择这个模型合规吗 □ 是否有应急预案如果模型输出违规内容怎么处理第六章组织建设——从个人英雄到工程文化6.1 提示词工程师的角色定义在企业中提示词工程师可以有不同定位角色一提示词专家Individual Contributor专注于写高质量提示词为其他团队提供提示词咨询维护提示词模板库和最佳实践角色二AI应用架构师设计企业级AI应用的提示词架构设计Agent系统、RAG系统、多模型路由制定提示词的工程规范角色三AI产品经理定义AI产品的行为模式设计用户体验中的AI交互平衡质量、成本、速度三者关系6.2 团队技能矩阵一个成熟的提示词工程团队应该具备以下能力初级工程师 □ 能写清晰的提示词 □ 理解基本的角色设定 □ 知道常见的错误模式 中级工程师 □ 精通结构化提示词设计 □ 能使用Few-shot和CoT □ 能设计和评估测试用例 □ 理解成本优化 高级工程师 □ 能设计Agent系统 □ 能搭建提示词工程流水线 □ 能进行生产系统的监控和优化 □ 能给团队做培训和指导 架构师 □ 能设计企业级AI架构 □ 制定规范和标准 □ 评估和选型AI技术栈 □ 推动组织的AI文化建设6.3 建立提示词工程文化文化要素一共享所有提示词对团队可见好的做法及时分享失败的案例也不隐藏文化要素二持续学习定期组织提示词工作坊跟踪最新研究和技术进展实验新的提示词技术文化要素三数据驱动所有提示词的效果都可量化决策基于数据而非直觉持续做A/B测试文化要素四安全第一安全审查是上线的前置条件敏感操作有记录安全意识渗透在每个人的日常工作中第七章10篇系列总结与知识图谱7.1 系列回顾让我们回望整个系列的学习路径入门篇 进阶篇 高阶篇 ┌─────────────────┐ ┌──────────────────────────┐ ┌────────────────────────────┐ │ 第1篇认知 │ │ 第4篇角色与上下文 │ │ 第7篇CoT深度解析 │ │ 什么是提示词 │──▶ │ 如何让AI扮演专家 │──▶ │ 推理能力如何解锁 │ │ ─────────────── │ │ ──────────────────────── │ │ ────────────────────────── │ │ 本质信号系统 │ │ 三要素角色模型 │ │ Self-Consistency │ │ Token工作机制 │ │ 上下文分层管理 │ │ Tree-of-Thought │ │ 五个功能层次 │ │ 角色上下文协同效应 │ │编程/数学/逻辑专题应用 │ └─────────────────┘ └──────────────────────────┘ └────────────────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────┐ ┌──────────────────────────┐ ┌────────────────────────────┐ │ 第2篇四步法 │ │ 第5篇结构化提示词 │ │ 第8篇Agent模式 │ │ 黄金四步法 │──▶ │ 从聊天到系统化输出 │──▶ │ 让AI从说话到做事 │ │ ─────────────── │ │ ──────────────────────── │ │ ────────────────────────── │ │ Who→What→ │ │ 模板化→模块化→管道化 │ │ ReAct循环 │ │ Context→Format │ │ 条件逻辑动态注入 │ │ 工具调用机制 │ └─────────────────┘ └──────────────────────────┘ │ 多Agent协作 │ │ │ └────────────────────────────┘ ▼ ▼ │ ┌─────────────────┐ ┌──────────────────────────┐ │ │ 第3篇避坑指南 │ │ 第6篇Few-shotCoT │ │ │ 8个常见错误 │──▶ │ 教会AI如何思考 │ │ │ ─────────────── │ │ ──────────────────────── │ │ │ 从失败中学习 │ │ 示例驱动的学习方法 │ │ └─────────────────┘ │ 思维链引导推理 │ │ └──────────────────────────┘ │ ┌────────────────────────────┐ │ 第9篇多模态提示词 │ │ 文本图像代码协同 │ │ ────────────────────────── │ │ 视觉设计原则 │ │ 图文生成与编辑 │ │ UI→代码 │ └────────────────────────────┘ │ ▼ ┌────────────────────────────┐ │ 第10篇企业级实践本篇 │ │ 从个人技能到组织能力 │ │ ────────────────────────── │ │ 团队协作·版本管理·质量保障 │ │ 成本控制·安全合规·组织建设 │ └────────────────────────────┘7.2 核心能力模型学完这10篇你应该具备以下核心能力能力一提示词设计能力能够根据任务需求设计高质量的提示词掌握角色设定、上下文管理、输出控制等技术能够识别和避免常见错误能力二提示词工程能力能够设计结构化、可复用的提示词模板能够使用 Few-shot、CoT 等高级技术能够设计 Agent 系统和工具调用能力三提示词质量管理能力能够建立测试体系和评估指标能够进行回归测试和A/B测试能够监控和分析生产环境中的表现能力四提示词架构能力能够设计企业级的提示词架构能够平衡质量、成本、速度能够确保安全合规7.3 持续学习的方向提示词工程是一个快速发展的领域。以下是几个值得持续关注的方向自动提示词优化DSPy、Prompt Optimizer 等工具正在快速发展未来提示词的编写可能更多由 AI 完成人类转向审查和策略定义。多模态深化视频理解、3D生成、实时交互等多模态能力正在快速发展提示词设计需要适应新的模态。Agent 生态Agent 框架LangChain、AutoGPT、CrewAI等正在快速成熟与提示词的结合越来越紧密。端侧模型小模型如手机端、IoT设备上的模型的提示词设计和大模型有显著不同这是一个尚未充分开发的领域。提示词安全随着 AI 应用的普及提示词注入、数据泄露等安全问题将越来越重要。写在最后——给读者的一封信亲爱的读者如果你读完了这10篇大约用了 10 个小时的阅读时间。但这 10 小时可能节省你1000 小时的自我摸索时间。提示词工程是一个实践出真知的领域——所有理论最终都要回到写出来、跑一下、看结果这个循环。这 10 篇给你的不是标准答案而是一张认知地图、一套方法论工具箱、一份避坑指南。接下来你要做的三件事是第一用起来。读完第2篇就立刻用四步法重写你今天要用的提示词。读完第6篇就在你的下一个任务中加入让我们一步一步思考。读完第8篇就想想你工作中有哪些场景可以引入 Agent 模式。第二建立自己的案例库。每次写好一个优质的提示词把它保存下来加上注释为什么这么写、解决了什么问题。半年后你就有了一份个人最佳实践集。第三分享出去。把你学到的教给别人。教是最好的学——当你向同事解释为什么角色设定要包含三要素时你对这个概念的理解会再深一层。最后记住一句话提示词的终极目标不是让模型回答正确而是让模型的正确回答可直接用于你的工作流。愿你在提示词工程的道路上越走越远。—— 系列完 ——所有伟大的工程师都是从写好第一行代码开始的。所有伟大的提示词工程师都是从写好第一个提示词开始的。你已经有了10篇的知识储备——现在去写你的第一个、第十个、第一百个提示词吧。
)
