1. 项目概述一个为AI提示工程服务的“指令银行”最近在折腾大语言模型LLM应用开发的朋友估计都绕不开一个核心环节提示工程。无论是想构建一个能稳定输出JSON格式的智能客服还是一个能遵循复杂步骤进行数据分析的Agent我们都需要和那些看似简单、实则暗藏玄机的“提示词”打交道。写得好了模型乖巧听话输出精准写得不好它要么跟你玩“猜谜游戏”要么直接“放飞自我”输出一堆无法解析的“胡言乱语”。正是在这种反复调试、焦头烂额的日常中我发现了morsa-dev/guidance-bank这个项目。初看名字“guidance-bank”直译过来是“指导银行”或“指引库”有点抽象。但当你点进去看到它的描述——“A collection of prompt templates for various tasks using the Guidance library”一切就豁然开朗了。这本质上是一个专门为guidance这个强大的提示词编程框架服务的“模板库”或“指令集锦”。简单来说guidance库允许你像写程序一样结构化地编写提示词通过占位符、逻辑控制如{{#if...}}、循环等生成动态、可靠且格式可控的提示。而guidance-bank则是由社区贡献者morsa-dev发起和维护的一个开源仓库里面收集了针对各种常见任务如文本摘要、情感分析、代码生成、数据提取等预先编写好的、经过验证的guidance模板。你可以把它理解为一个开源的、可复用的“提示词配方库”。对于开发者而言它的价值在于当你面对一个新任务时不必再从零开始构思和调试提示词结构而是可以在这个“银行”里“取款”——即寻找、借鉴甚至直接复用经过实践检验的模板从而大幅提升开发效率和输出结果的稳定性。无论你是刚接触guidance的新手还是正在寻找最佳实践的老手这个项目都值得你花时间深入探索。2. 核心价值与设计思路拆解2.1 为什么我们需要一个“提示词模板库”在深入guidance-bank的具体内容之前我们有必要先厘清一个根本问题在提示工程已经有很多工具和方法的今天为什么还需要一个集中的模板库这背后反映的是LLM应用开发从“手工作坊”向“工程化”、“标准化”演进的需求。首先提示词的编写存在显著的“重复造轮子”问题。很多基础任务如“将会议纪要转为待办事项”、“从产品描述中提取关键属性”、“给一段代码写注释”其核心的提示逻辑和结构是相通的。但每个开发者或团队都可能花费大量时间独立摸索、调试属于自己的版本。这不仅效率低下而且由于缺乏比较和基准很难判断自己写的是否已是“最优解”。其次guidance框架本身虽然强大但有一定的学习门槛。它引入了一套类似模板语言的语法用于混合自然语言指令和逻辑控制。对于新手理解如何正确使用{{gen}}生成文本、{{#if}}进行条件分支、{{#each}}处理列表并确保整个提示在语法和逻辑上都能被目标LLM如GPT-4、Claude等正确解析需要一个过程。一个高质量的模板库恰好提供了最佳的学习范例。再者可靠性和可复现性是生产级应用的关键。自己写的提示词可能在某个模型版本上工作良好换一个模型或调整一下参数就可能失效。而一个经过社区多人验证、在不同场景下测试过的模板其健壮性通常更高。guidance-bank中的模板往往包含了针对输出格式JSON、XML、YAML、长度控制、思维链Chain-of-Thought等常见难题的解决方案这些都是宝贵的工程经验。因此guidance-bank的设计思路非常清晰建立一个开源、协作、分类清晰的“模板集市”。它不试图发明新的提示工程技术而是致力于将散落在各处的最佳实践收集、整理、标准化并以guidance这一具备强结构化和逻辑控制能力的格式呈现出来使之易于查找、理解、修改和集成。这极大地降低了使用guidance进行复杂提示工程的门槛并促进了知识的共享与沉淀。2.2guidance框架与模板库的共生关系要真正用好guidance-bank必须对其基础——guidance库——有基本的理解。这两者是紧密共生的关系。guidance提供了“语言”和“语法”而guidance-bank则提供了用这种语言写成的“经典范文”和“实用会话”。guidance的核心思想是将提示词视为一个可执行的程序。它允许你在提示词中嵌入变量、逻辑判断和循环。例如一个简单的模板可能是这样的import guidance # 定义guidance模板 program guidance( {{#system}}你是一个有帮助的助手。{{/system}} {{#user}}请分析以下文本的情感倾向并严格以JSON格式输出包含sentimentpositive/negative/neutral和confidence0-1之间的浮点数两个字段。 文本{{input_text}} {{/user}} {{#assistant}} { sentiment: {{gen sentiment}}, confidence: {{gen confidence}} } {{/assistant}} ) # 执行模板 result program(input_text这个产品真是太棒了我非常喜欢) print(result.variables()) # 可能输出{sentiment: positive, confidence: 0.95}在这个例子中{{input_text}}是输入变量{{gen sentiment}}和{{gen confidence}}是指令模型生成内容并存入指定变量。guidance库会负责将整个模板渲染成LLM能理解的提示并解析模型的输出将生成的内容填充到对应的变量中最终以结构化的方式如字典返回给开发者。guidance-bank中的模板就是大量此类guidance程序的集合。它们通常更复杂、更精妙解决了更具体的问题。比如可能包含多轮对话的模拟、复杂JSON Schema的生成、分步骤的推理过程等。通过研究这些模板你可以快速学到如何组织复杂的提示结构何时用{{#system}}、{{#user}}、{{#assistant}}角色标签来模拟对话历史。如何控制输出格式和类型利用guidance的约束功能确保模型输出是有效的JSON、列表或特定选项之一。如何实现高级模式如少样本学习Few-shot的嵌入方式、思维链的引导、自我验证Self-Correction循环等。可以说guidance-bank是guidance框架生态的“加速器”和“质量标杆”。它让开发者不仅能“用上”guidance更能“用好”guidance。3. 仓库内容深度解析与使用指南3.1 项目结构与模板分类morsa-dev/guidance-bank仓库通常采用清晰的项目结构来组织海量模板方便用户按图索骥。虽然具体结构可能随版本更新但核心分类逻辑是稳定的。常见的分类方式包括按任务类型Task-based这是最直观的分类。例如summarization/文本摘要模板可能区分新闻摘要、会议纪要摘要、长文档摘要等。classification/分类任务模板如情感分析、主题分类、意图识别。extraction/信息提取模板如从邮件中提取联系人信息、从文章中提取关键事实、实体识别。generation/文本生成模板如创意写作、邮件撰写、代码生成、营销文案。transformation/格式转换模板如自然语言转SQL、转正则表达式、转API调用参数。reasoning/推理与问答模板包含数学解题、逻辑推理、多步问答等常集成思维链。evaluation/评估与评分模板用于让LLM评估另一段文本的质量、相关性、安全性等。按行业或领域Domain-based针对特定垂直领域优化的模板。legal/法律文书分析、条款提取、合同审查。medical/需注意合规医学文献摘要、患者问答模拟通常非常谨慎。code/代码解释、调试、重构、文档生成。creative/诗歌、故事、剧本创作。按复杂度或模式Pattern-based根据使用的guidance高级特性分类。few-shot/包含少样本示例的模板。chain-of-thought/明确引导分步推理的模板。json-mode/强制输出严格JSON格式的模板通常会内嵌JSON Schema描述。multi-turn/模拟多轮对话的复杂模板。每个模板通常是一个独立的.py或.guidance文件。文件中不仅包含guidance模板字符串还应该理想情况下包含模板描述这个模板是干什么的解决什么问题输入参数说明模板需要哪些变量如input_text,options使用示例一段简单的Python代码展示如何加载和运行这个模板。预期输出示例展示模型在给定输入下应该产生什么样的输出。3.2 如何高效查找与评估模板面对成百上千的模板如何快速找到最适合你当前需求的那一个这里有一些实操建议明确需求关键词搜索首先用仓库的搜索功能GitHub的搜索或直接浏览目录。关键词应具体例如“JSON extraction invoice”发票JSON提取比单纯的“extraction”更有效。阅读模板的元信息和注释打开一个候选模板文件先看最顶部的注释。一个好的模板会清晰说明其目标、输入输出格式、适用的模型如“在GPT-4上测试良好”、以及任何重要的前提假设。检查输入输出接口看模板中定义的变量。这决定了你需要为它准备什么数据以及你会得到什么形式的结果。确保与你现有的数据管道兼容。审视内部逻辑复杂度快速浏览模板内容。它是否过于复杂包含了多少逻辑控制{{#if}},{{#each}}对于简单任务一个轻量级的模板可能更可靠、成本更低。对于复杂任务一个结构严谨、包含验证步骤的模板则是必要的。寻找测试用例或示例如果仓库提供了测试文件或示例脚本优先查看这些。它们能最直观地展示模板的正确用法和预期行为。社区反馈与活跃度查看模板文件的提交历史、最近更新日期以及关联的Issue或Pull Request。一个近期有更新、有讨论的模板通常比一个沉寂多年的模板更可靠。注意模板库是社区贡献的质量可能参差不齐。切勿盲目相信任何一个模板能“开箱即用”。一定要将其视为一个强大的起点和参考而不是最终的解决方案。在你自己的数据和业务场景中进行充分的测试和调整是必不可少的步骤。3.3 模板的集成、定制与调试找到心仪的模板后下一步就是把它用起来。这个过程通常分为三步集成、定制、调试。集成最简单的方式是直接复制模板代码到你的项目中。更工程化的做法是如果你的项目结构允许可以将guidance-bank作为子模块git submodule引入或者编写一个小的加载器函数根据任务类型动态加载对应的模板文件。定制几乎没有模板能完全符合你的所有需求。常见的定制点包括修改系统指令System Prompt调整AI的角色设定使其更贴合你的应用场景。调整输出格式模板输出的JSON字段名可能需要改变或者你需要增加、减少某些字段。注入领域知识在少样本示例Few-shot examples中替换成你自己领域的例子能极大提升模型表现。优化提示词表述某些指令的表述可能不符合你的语言习惯或对模型更有效可以进行微调。调试这是最关键的一步。guidance模板的调试有时比普通代码更棘手因为问题可能出在提示词逻辑、模型理解或两者交互上。首先打印完整的提示词使用guidance库的能力在调用LLM之前先查看渲染后的完整提示字符串。检查变量替换是否正确逻辑分支是否按预期展开。# 假设 program 是你的 guidance 程序 print(program.prompt) # 查看即将发送给LLM的完整文本其次进行小规模测试用少量、有代表性的数据运行模板观察输出。重点关注格式错误、逻辑错误如该进入的if分支没进入和内容错误。使用更智能的模型进行调试如果模板在较小的模型如gpt-3.5-turbo上表现不佳可以先用能力最强的模型如gpt-4测试以确定是模板本身的问题还是模型能力的问题。利用guidance的日志功能一些版本的guidance提供了更详细的执行日志可以帮助你跟踪生成过程。一个重要的心得是将复杂的模板拆解调试。如果一个模板很长很复杂可以尝试先注释掉一部分或者分阶段执行逐步验证每个逻辑模块的正确性。4. 实战从模板库构建一个数据提取应用让我们通过一个具体的场景来看看如何利用guidance-bank快速构建一个可用的功能。假设我们需要从用户提交的产品反馈中结构化地提取出“产品名称”、“反馈类型”Bug、功能建议、用户体验问题、“严重程度”1-5级和“问题描述摘要”。4.1 需求分析与模板搜寻我们的需求很明确非结构化文本 - 结构化JSON。这属于信息提取Information Extraction任务。我们立刻可以到guidance-bank的extraction/目录下寻找相关模板。很可能会找到类似extract_structured_data.guidance或text_to_json.guidance的模板。假设我们找到了一个名为generic_issue_extractor.guidance的模板。它的描述是“从一段文本中提取问题报告的相关字段。” 我们查看其内容发现它预设的字段是[“item”, “issue_type”, “severity”, “description”]与我们的需求基本匹配但字段名略有不同itemvsproduct_name。4.2 模板适配与参数化我们复制这个模板并开始进行定制。首先修改字段名以符合我们的需求。其次我们需要明确定义每个字段的取值规则和格式这通常在系统指令或用户指令中完成。原始模板可能长这样# generic_issue_extractor.guidance (简化版) template_str {{#system}}你是一个信息提取专家。请从用户输入中提取结构化信息。{{/system}} {{#user}}请从以下文本中提取信息并以JSON格式输出包含字段item, issue_type, severity, description。 文本{{input_text}} {{/user}} {{#assistant}} { item: {{gen item}}, issue_type: {{gen issue_type}}, severity: {{gen severity}}, description: {{gen description}} } {{/assistant}} 我们将其适配为# customized_product_feedback_extractor.py import guidance import json guidance.llm guidance.llms.OpenAI(gpt-3.5-turbo) # 设置LLM product_feedback_extractor guidance( {{#system}}你是一个专业的产品经理助理擅长从用户反馈中精准提取关键信息。{{/system}} {{#user}}请仔细分析用户关于产品的反馈文本并提取出以下结构化信息 - **product_name**产品名称。如果文本未明确提及请根据上下文推断一个最可能的通用名称如“移动端App”、“后台管理系统”。 - **feedback_type**反馈类型。必须是以下选项之一[Bug, Feature_Request, Usability_Issue]。 - **severity**严重程度。必须是1到5之间的整数其中1表示轻微5表示严重。 - **summary**问题或建议的摘要。用一句话简洁概括不超过30字。 请严格输出一个JSON对象仅包含上述四个字段不要有任何额外解释。 反馈文本{{feedback_text}} {{/user}} {{#assistant}} json { product_name: {{gen product_name}}, feedback_type: {{gen feedback_type}}, severity: {{gen severity}}, summary: {{gen summary}} }{{/assistant}} )测试test_feedback “你们新上线的支付页面在iPhone Safari浏览器上点击确认按钮没反应刷新也没用这导致我无法完成订单非常着急” result product_feedback_extractor(feedback_texttest_feedback)print(“提取结果”) print(json.dumps(result.variables(), indent2, ensure_asciiFalse))在这个定制版本中我们做了几件事 1. **强化了系统角色**使其更贴近业务场景产品经理助理。 2. **细化了字段规则**为每个字段增加了详细的提取规则和约束如枚举值、数值范围、字数限制。 3. **使用了JSON代码块标记**用 json ... 包裹输出能更明确地指示模型输出格式提高成功率。 4. **添加了严格的指令**“仅包含上述四个字段不要有任何额外解释”这能有效减少模型“说废话”的情况。 ### 4.3 集成到应用流程与批量处理 单个反馈的提取搞定后我们需要将其集成到完整的应用流程中。这可能是一个Web API的后端服务或者一个批量处理脚本。 python # batch_process_feedback.py import guidance import json from typing import List, Dict import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) # 初始化提取器 (同上略) # product_feedback_extractor guidance(...) def process_feedback_batch(feedback_list: List[str]) - List[Dict]: 批量处理用户反馈列表 results [] for idx, text in enumerate(feedback_list): try: logger.info(f”处理第 {idx1} 条反馈长度{len(text)}”) # 调用guidance模板 result product_feedback_extractor(feedback_texttext) extracted_data result.variables() # 基础验证 if not all(key in extracted_data for key in [“product_name”, “feedback_type”, “severity”, “summary”]): logger.warning(f”第 {idx1} 条反馈提取字段不全: {extracted_data}”) extracted_data[“_error”] “incomplete_extraction” else: # 尝试转换severity为整数 try: extracted_data[“severity”] int(extracted_data[“severity”]) except ValueError: logger.warning(f”第 {idx1} 条反馈的severity不是整数: {extracted_data[‘severity’]}”) extracted_data[“_error”] “invalid_severity” results.append(extracted_data) except Exception as e: logger.error(f”处理第 {idx1} 条反馈时发生错误: {e}”) results.append({“_error”: str(e), “original_text”: text[:100]}) # 记录部分原文 return results # 模拟批量数据 raw_feedbacks [ “支付页面在Safari上点击无效无法下单。”, “希望能增加深色模式晚上用太刺眼了。”, “v2.1.0版本个人中心头像上传后显示破碎安卓和iOS都有这问题。” ] processed_results process_feedback_batch(raw_feedbacks) print(“批量处理结果”) for res in processed_results: print(json.dumps(res, ensure_asciiFalse))在这个批量处理示例中我们增加了错误处理、日志记录和基础数据验证。这是将实验性模板转化为生产代码的关键步骤。永远不要假设LLM的输出是100%可靠的必须在后续流程中加入验证和清洗环节。5. 高级技巧与性能优化5.1 利用少样本Few-shot学习提升准确性guidance-bank中许多高级模板都内置了少样本示例。少样本学习是提升模型在特定任务上表现的最有效手段之一。它的原理是为模型提供几个输入-输出的例子让模型“照葫芦画瓢”。当你定制模板时强烈建议加入与你业务高度相关的少样本示例。例如针对我们的产品反馈提取器可以这样修改模板few_shot_extractor guidance(’’’ {{#system}}你是一个专业的产品经理助理擅长从用户反馈中精准提取关键信息。{{/system}} {{#user}}请仔细分析用户关于产品的反馈文本并提取出以下结构化信息 - **product_name**产品名称。如果文本未明确提及请根据上下文推断。 - **feedback_type**反馈类型。必须是以下选项之一[“Bug”, “Feature_Request”, “Usability_Issue”]。 - **severity**严重程度。必须是1到5之间的整数。 - **summary**问题或建议的摘要。用一句话简洁概括。 请严格输出一个JSON对象仅包含上述四个字段。 以下是几个例子 例1 输入“购物车页面点击结算按钮后页面卡死必须强制关闭App。” 输出{“product_name”: “移动端App”, “feedback_type”: “Bug”, “severity”: 4, “summary”: “购物车结算按钮点击后页面卡死。”} 例2 输入“建议在搜索框里加入历史记录功能这样就不用每次都重新打字了。” 输出{“product_name”: “网站搜索功能”, “feedback_type”: “Feature_Request”, “severity”: 2, “summary”: “建议为搜索框添加搜索历史记录功能。”} 例3 输入“这个新版的图标设计太小了颜色对比度也不够老年用户根本看不清。” 输出{“product_name”: “用户界面”, “feedback_type”: “Usability_Issue”, “severity”: 3, “summary”: “新版图标太小且颜色对比度不足影响可读性。”} 现在请处理新的反馈 反馈文本{{feedback_text}} {{/user}} {{#assistant}} json { “product_name”: “{{gen ‘product_name’}}”, “feedback_type”: “{{gen ‘feedback_type’}}”, “severity”: {{gen ‘severity’}}, “summary”: “{{gen ‘summary’}}” }{{/assistant}} ’’’)加入2-3个高质量、覆盖不同反馈类型的例子后模型的提取准确性和格式遵从性通常会得到显著提升。**选择少样本示例的关键在于代表性和清晰性**要覆盖你希望模型处理的主要情况。 ### 5.2 处理复杂逻辑与多步推理 有些任务无法一步完成。例如你需要先让模型判断一段客户咨询的意图再根据不同的意图调用不同的提取模板。guidance 的强大之处在于可以嵌套和组合程序。 假设 guidance-bank 里有两个模板一个通用分类器 intent_classifier.guidance和一个专门用于处理“投诉”类反馈的详细提取器 complaint_detail_extractor.guidance。我们可以这样组合它们 python # 假设我们已经从guidance-bank加载了这两个模板 # intent_classifier guidance(加载的分类器模板字符串) # complaint_extractor guidance(加载的投诉提取模板字符串) def process_customer_message(message: str): # 第一步意图分类 classification_result intent_classifier(user_messagemessage) intent classification_result[“intent”] # 假设输出里有intent字段 if intent “complaint”: # 第二步如果是投诉进行详细提取 detail_result complaint_extractor(complaint_textmessage) return {“intent”: intent, “details”: detail_result.variables()} elif intent “inquiry”: # 其他意图的处理逻辑... return {“intent”: intent, “action”: “route_to_faq”} else: return {“intent”: intent, “action”: “route_to_human”}这种“编排”Orchestration模式使得我们可以用guidance-bank中的原子化模板像搭积木一样构建复杂的工作流。每个模板负责一个单一的、明确的任务通过上层逻辑将它们串联起来。这比编写一个巨型的、包含所有逻辑的单一提示要更清晰、更易维护也更容易复用现有的社区模板。5.3 成本控制与性能权衡使用LLM API如OpenAI是有成本的。在利用guidance-bank构建应用时成本控制是一个必须考虑的现实问题。模板复杂度与Token消耗一个包含大量少样本示例、复杂指令和逻辑控制的模板其渲染后的提示词会非常长导致每次调用消耗的Token数尤其是输入Token很高。需要权衡模板的丰富度和成本。对于简单、高频的任务应追求最精简有效的提示。模型选择guidance-bank中的模板通常在GPT-4上测试效果最佳但GPT-4的成本也最高。在实际应用中可以尝试用gpt-3.5-turbo甚至更小的开源模型来运行这些模板。务必进行效果评估很多时候经过精心设计的提示在gpt-3.5-turbo上也能达到可接受的效果成本却能降低一个数量级。缓存策略对于输入相同、输出也预期相同的确定性任务如根据固定规则格式化文本可以考虑对LLM的调用结果进行缓存避免重复计算。批量处理如果API支持批量调用如OpenAI的ChatCompletion接口可以一次发送多条消息尽量将任务批量处理这通常比多次单独调用更高效、更便宜。一个实用的建议是建立模板的“性能-成本”档案。记录每个模板在不同模型GPT-4, GPT-3.5下的平均Token消耗、调用延迟、以及在你评估集上的准确率。这能为你在具体业务场景中选择合适的模板和模型提供数据支持。6. 常见陷阱、问题排查与社区贡献6.1 使用guidance-bank模板时的常见陷阱即使模板来自社区精选在实际使用中仍会遇到各种问题。以下是一些高频陷阱及应对策略陷阱表现原因分析解决方案格式解析失败程序抛出JSON解析错误或无法正确提取{{gen}}变量。1. 模型没有严格遵循指定的输出格式如JSON。2.guidance模板语法错误导致变量边界识别错误。3. 输出中包含特殊字符如未转义的引号破坏了格式。1. 强化输出格式指令使用代码块标记json。2. 在guidance()调用中启用silentFalse以查看详细日志检查模板渲染。3. 使用guidance的regex或gen的stop参数约束输出。模型“幻觉”或偏离指令模型输出额外解释、重复问题、或完全忽略部分指令。1. 系统指令不够明确或强硬。2. 指令过于复杂模型无法完全理解。3. 少样本示例与当前输入差异过大误导了模型。1. 在系统指令和用户指令中多次、清晰地强调核心要求如“只输出JSON”。2. 简化指令分步骤实现复杂逻辑。3. 检查并优化少样本示例确保其代表性和指令遵从性。性能不稳定同一模板有时输出完美有时输出错误。1. LLM本身具有随机性即使temperature0也有微小波动。2. 输入文本的微小变化如长度、表述方式可能导致模型关注点变化。3. 提示词中存在模糊或歧义的指令。1. 对于关键任务可以设置temperature0并考虑多次调用取最优或投票。2. 对输入文本进行预处理如截断、清理无关信息。3. 进行广泛的测试找出导致不稳定的模糊指令并加以澄清。变量替换错误{{variable}}没有被正确替换或替换了错误的内容。1. 变量名在模板中拼写错误或与传入参数不匹配。2.guidance的版本差异导致语法解析不同。3. 在逻辑块{{#if}}内外部错误地使用了变量。1. 仔细检查模板中所有变量引用确保与调用时传入的字典键名完全一致。2. 确认你使用的guidance库版本与模板编写时兼容。3. 理解guidance的作用域规则避免在逻辑块内定义却在外部引用变量。6.2 问题诊断与排查流程当模板运行不如预期时建议遵循以下排查流程隔离问题首先用最简单、最确定的输入测试模板。排除输入数据本身的问题。检查渲染打印出program.prompt渲染后的完整提示。这是最重要的一步。肉眼检查发送给模型的最终文本是否与你预期的一致。变量是否填充逻辑分支是否正确格式是否工整简化模板如果模板很复杂尝试逐步注释掉部分内容如少样本示例、复杂的条件判断直到它能正常工作。然后再逐步添加回去定位引发问题的部分。更换模型如果在小模型上失败尝试在能力最强的模型如GPT-4上运行。如果GPT-4能成功说明模板逻辑基本正确问题可能在于小模型的能力边界。你需要考虑是否简化任务或接受使用大模型。查阅社区在guidance-bank的GitHub仓库中搜索相关Issue看看是否有其他人遇到类似问题及解决方案。如果找不到可以考虑开一个新的Issue详细描述你的问题、使用的模板、输入输出示例以及错误信息。6.3 向guidance-bank贡献你的模板如果你在使用过程中针对某个常见任务创建了一个效果显著、设计精巧的模板强烈建议你回馈给社区。贡献流程通常是标准的GitHub工作流Fork 仓库将morsa-dev/guidance-bank仓库 Fork 到你自己的GitHub账户。创建分支在你的Fork中创建一个新的功能分支例如add-product-feedback-extractor。添加模板将你的模板文件如product_feedback_extractor.guidance放在合适的分类目录下如extraction/。务必提供完整的文档在文件开头用注释清晰说明模板的目的、输入参数、输出格式、适用的模型以及一个简单的使用示例。如果可能添加一个简单的测试脚本或示例数据证明模板的有效性。提交并推送提交更改并推送到你的Fork。发起 Pull Request (PR)回到原始的guidance-bank仓库发起一个PR描述你添加的模板解决了什么问题有什么特点。在贡献时请确保你的模板是通用的、文档齐全的并且遵循仓库已有的代码风格和目录结构。一个高质量的贡献不仅能帮助他人也能让你的解决方案得到更多人的检验和完善。