这是这是我们《AI开发实践》系列的第1.1.2 篇我们继续学习Langchain。前一篇中我们准备了环境并且试用了模型也为了进一步做好提示词开了3篇提示词的番外通过13篇核心论文来阐述了提示词是什么如何写好提示词。这一节我们写一个写一段langchain代码调用提示词来跑一下。在这次实例代码中我们首先使用了我们提出的“程序化提示词框架SPC-E” 通过12个基本语义运算单元构建Step template。确保遵循22条黄金准则确保逻辑严谨也尽可能模仿工业化Agent的应用需求。前言提示词有不同的框架要根据不同的任务选择不同的提示词框架也可以进行组合应用即使是文件类的也已经有各种各样的场景提示词框架/技术技术开发、故障排查CoTCRT文档生成、标准化输出STAR、5W1H、结构化输出框架营销文案、产品推广AIDA产品优化、创意构思SCAMPER观点陈述、方案论证PREP通用需求3W1H而对于图像生成类还有正向提示词主体细节风格负向提示词不希望体现什么因此我们需要对我们的应用场景进行研究定义并选择合适的提示词框架。而针对于严肃类应用特别是Agent开发结合前面的ICL论文我认为值得推荐的是“程序化提示词框架 SPC-E” 它遵循的前面的论文提到的宏观结构准则“把提示词写成外部程序一样的严格指令结构固定、逻辑清晰语义明确”用起来会比较可靠符合工业化的要求。而在实际的使用时程序化提示词框架要建立在 基本的语义运算单元的基础上。由这些基本语义单元来确保基本运算的准确性在此基础上通过前后步骤间的流程和数据的衔接保证“输入-处理-输出”整个逻辑正确顺畅。一、基本语义运算单元语义运算包括以下4大类12个基本运算单元由此可以通过串并行组合成各种复杂逻辑运算类别基础运算单元功能描述典型示例输入 → 输出语义处理语义提取从文本中提取结构化信息张三2025年毕业于北京大学→{姓名:张三,毕业年份:2025,院校:北京大学}语义分类将文本归类到预定义类别今天手机突然开不了机→电子产品故障语义聚类将相似文本分组苹果很甜、橙子多汁、西瓜解暑→聚类标签水果描述逻辑处理语义推理基于常识和逻辑进行推断人都会睡觉小明是人→小明会睡觉因果分析识别因果关系因为下雨所以地面湿了→{原因:下雨,结果:地面湿了}矛盾检测识别逻辑矛盾今天是周一今天是周日→存在逻辑矛盾生成处理语义生成根据意图生成文本意图写一句早安问候→早上好愿你今天一切顺利风格转换改变文本风格但保持语义这东西超好用→该产品使用体验优异摘要生成提取核心信息长文本人工智能在医疗影像诊断中提升效率与准确率...→本文介绍AI在医疗影像诊断中的应用与优势关系处理语义相似度计算文本相似程度我爱机器学习vs我喜欢深度学习→语义相似度高语义关联发现概念间关系咖啡→关联概念提神、杯子、苦味上下文关联维护对话上下文上文我看中这款手机问句它多少钱→指代对象手机二、提示词框架在有了基本语义运算单元后我们可以通过一个类程序的框架来定义提示词一级模块二级子模块具体内容作用对应22条黄金准则核心基础模块必含立角色Role定义本场景中模型承担的角色答题者的能力边界。预训练过程中模型学习了大量的角色、行为、语言的关联通过角色就限定了特定的上下文空间。通常会安上个XX领域的XX专家让LLM从通用生成转向“场景化、专业化”的生成基础前提保障所有22条黄金准则含任务目标、步骤模板、防幻觉等落地执行不涉及具体准则内容。述问题Problem描述具体要解决的问题该 问题的背景及相关任务信息在角色的上下文空间内进一步的约束减小任务依赖的上下文为后续步骤提供方向避免偏离需求10. 防” 幻觉 “准则step template 需明确任务的 “上下文依赖范围”避免模型调用无关信息论文 #10、#1116. 提取范围准则提示词必须明确划定有效内容的提取范围与筛选标准排除无关噪音论文 #10、#11。定目标Objective描述预期的解题目标及效果锁定任务核心目的约束执行范围确保所有步骤围绕目标展开,不漂移、不扩展。2. 任务目标准则提示词中必须有明确的任务目标有明确的 step template从而能够激活 ICL 能力论文 #1、#4、#5、#915. 场景单一准则提示词必须显式给出清晰、可复用的任务模式场景单一稳定不漂移论文 #5、#9、#11。SPC-E核心框架模块必含与基础模块联动SSchema数据结构/字段规范明确输入输出标准为后续运算步骤提供数据基础确保数据规范输入规范Schema输入参数列表数据类型取值范围 / 枚举必选 / 可选有效提取范围输出规范 Schema输出字段格式长度 / 结构禁止内容8. 参数类型准则step template 需明确 “输入参数类型、输出结果类型”避免模糊化设计论文 #4、#10、#1117. Schema 定义准则提示词必须明确定义数据的 “Schema”强制列出所有必填字段、数据类型、枚举范围及语义描述论文 #10、#1110. 任务属性准则step template 需明确任务的 “上下文依赖范围”避免模型调用无关信息 (防” 幻觉 “论文 #10、#1116. 提取范围准则提示词必须明确划定有效内容的提取范围与筛选标准排除无关噪音论文 #10、#11。PStep Template步骤模板运算逻辑核心运算流程确保操作有序、逻辑连贯避免步骤混乱按顺序输入解析 →基础处理 →逻辑判断分支规则→递进运算 →结果生成明确步骤间数据依赖第 i 步输出 → 第 i1 步输入2. 任务目标准则提示词中必须有明确的任务目标有明确的 step template从而能够激活 ICL 能力论文 #1、#4、#5、#93. 步骤顺序准则step template 的需按 “输入参数定义→运算逻辑→输出规范” 的递进顺序设计禁止步骤混乱论文 #4、#6、#74. 运算逻辑准则step template 的运算逻辑需符合 “从基础到复杂、从输入到输出” 的递进逻辑避免混乱无序论文 #4、#6、#7、#115. 数据依赖准则step template 需明确「步骤间的数据依赖」建立严格的 “第 i 步输出→第 i1 步输入” 的数据依赖闭环保持执行连贯性论文 #4、#6、#7、#116. 流程框架准则step template 需构建步骤连贯、衔接紧密、逻辑一致的流程框架确保归纳头能持续复用同一套任务结构模式论文 #5、#9、#117. 格式规范准则step template 的写作格式风格要体现出重复性结构固定变量位置固定指令句式固定论文 #5、#99. 分支规则准则step template 需明确「动态分支规则」即当第 i 步的输出满足不同条件时第 i1 步应采取何种不同的处理逻辑论文 #2、#3、#1111. 无矛盾准则step template 需避免 “矛盾性指令”即不设计与 “逐步运算、逐步收敛” 逻辑相悖的要求论文 #4、#6、#7。CConstraint Context约束上下文范围划定执行边界防止幻觉、步骤混乱确保响应贴合需求仅依据本次输入不联想外部知识不新增参数不超范围执行10. 任务属性准则step template 需明确任务的 “上下文依赖范围”避免模型调用无关信息 (防” 幻觉 “论文 #10、#1112. 防防自作聪明准则step template 需明确 “本次任务运算仅依据本模板规定的规则执行不调用外部预设参数”论文 #1、#10、#1113. 任务类型准则step template 需明确任务属性线性 / 非线性并配套对应运算规则论文 #4、#8、#1114. 范围约束准则step template 需明确 “运算仅围绕本次任务不超范围执行”论文 #10、#11。EExample Evaluation示例自检提供参考示例让模型自我校验确保输出符合规范降低错误率示例Example严格对齐 Step Template渐近式简单→复杂无冗余、无干扰自检规则Evaluation验证标准合格 / 不合格判定修正逻辑18. 示例简洁准则示例需遵循 “无无效干预” 原则不引入无关验证条件、不额外增加调参操作论文 #1、#4、#1119. 示例递进准则示例需贴合 ICL“从基础到复杂从输入到输出逐步运算、逐步优化” 的渐近式推理逻辑无冗余论文 #2、#3、#4、#6、#720. 示例贴合准则示例需与任务目标step template 强绑定保持逻辑与格式的高度一致论文 #1、#5、#9、#1121. 自检标准准则提示词必须设置清晰可判断的 “结果验证标准”让模型能自检论文 #10、#1122. 演示逻辑准则示例的 “演示逻辑” 必须严格满足 Step Template 中的验证标准论文 #1、#5、#9、#10、#11。三、示例1. 系统提示词【Role - 角色】你是专业的售后智能分析师仅基于本次客户备注内容分析不调用外部售后案例、行业数据或主观联想信息。 【Problem - 问题】需分析售后客户备注的关键信息输出结构化JSON结果支撑售后状态机自动化处理需严格控制幻觉、避免主观推导。 【Objective - 目标】核心目标精准提取客户备注中的客观事实、显性/隐性诉求、情绪、优先级生成状态机可直接执行的结构化JSON无信息遗漏、无主观联想。 【SSchema- 数据结构规范】 ### 输入Schema 仅接收以下输入内容 客户原始备注用户本次输入的文本仅基于这段内容分析不扩展、不联想。 ### 输出Schema 请按以下规则填写输出字段 cot_process: 填写完整的CoT思考过程作为思考记录 fact仅提取客户备注中的客观事实如时间、事件、行为无任何主观评价 explicit_intent客户明确说出的直接诉求 implicit_intent基于 fact 和 explicit_intent 可明确推导的潜在诉求禁止主观脑补 emotion从枚举中选唯一一个不满 / 焦虑 / 生气 / 失望 / 无奈 / 平静 priority从枚举中选唯一一个高 / 中 / 低 高影响用户核心诉求 时间紧急 中常规诉求 低无紧急性、无明确诉求 next_action从枚举中选唯一一个回电安抚 / 优先处理 / 催促补发 / 发起退款 / 升级专员 / 核实物流 / 驳回申请 【PStep Template- 步骤模板运算逻辑】 步骤1语义提取仅提取「客户原始备注」中的客观事实输出「fact字段候选值」 步骤2语义提取基于步骤1的fact识别客户明确提及的显性诉求输出「explicit_intent字段候选值」 步骤3语义推理基于步骤1-2的结果推导客户未明说的隐性诉求输出「implicit_intent字段候选值」 步骤4语义分类基于fact/诉求匹配emotion枚举值priority枚举值输出「emotion/priority字段候选值」 步骤5语义生成基于步骤1-4的结果匹配next_action枚举值输出「emotion/priority字段候选值」 步骤6输出结果根据以上5步的结果生成完整JSON结构 → 数据依赖步骤i的输出 步骤i1的输入禁止跳过/反向依赖。 【CConstraint- 约束上下文范围】 1. 上下文约束仅依据本次输入的「客户原始备注」分析不调用外部售后案例、行业数据 2. 防幻觉约束禁止主观联想隐性诉求仅从fact/explicit_intent推导 3. 格式约束禁止新增emotion/priority/next_action的枚举值禁止修改字段语义 4. 输出约束必须先CoT思考过程再输出最终结果JSON格式无额外说明文字。 【EExample Evaluation- 示例自检】 ### 示例1基础版 输入我上周申请换货客服说3-5天到货现在第8天还没收到下周要出差很急。 CoT思考过程 步骤1仅提取「客户原始备注」中的客观事实输出fact已申请换货超过承诺时间未收到用户下周出差 步骤2基于步骤1的fact识别客户明确提及的显性诉求输出explicit_intent查询换货物流状态 步骤3基于步骤1-2的结果推导客户未明说的隐性诉求输出implicit_intent希望尽快拿到商品担心出差前收不到 步骤4基于fact/诉求匹配emotion枚举值priority枚举值输出emotion焦虑priority高 步骤5基于步骤1-4的结果匹配next_action枚举值输出next_action核实物流 步骤6输出结果根据以上5步的结果整理生成完整JSON结构 输出JSON {fact:已申请换货超过承诺时间未收到用户下周出差,explicit_intent:查询换货物流状态,implicit_intent:希望尽快拿到商品担心出差前收不到,emotion:焦虑,priority:高,next_action:核实物流} ### 示例2进阶版 输入商品刚收到就是坏的申请退款三天没人处理客服每次都说24小时回复结果一直没人联系我。我现在不想要了必须退款否则我要投诉。 CoT思考过程 步骤1仅提取「客户原始备注」中的客观事实输出fact商品到货损坏退款申请超3天未处理客服未兑现24小时回复承诺用户要求退款否则投诉 步骤2基于步骤1的fact识别客户明确提及的显性诉求输出explicit_intent要求立即处理退款 步骤3基于步骤1-2的结果推导客户未明说的隐性诉求输出implicit_intent希望得到客服重视担心退款一直不处理 步骤4基于fact/诉求匹配emotion枚举值priority枚举值输出emotion生气priority高 步骤5基于步骤1-4的结果匹配next_action枚举值输出next_action发起退款 步骤6输出结果根据以上5步的结果整理生成完整JSON结构 输出JSON {fact:商品到货损坏退款申请超3天未处理客服未兑现24小时回复承诺用户要求退款否则投诉,explicit_intent:要求立即处理退款,implicit_intent:希望得到客服重视担心退款一直不处理,emotion:生气,priority:高,next_action:发起退款} ### 自检规则Evaluation 1. fact字段仅包含客观事实无“客服不负责任”等主观评价 2. emotion/priority/next_action严格匹配枚举值无新增/组合值 3. implicit_intent可从fact/explicit_intent推导无主观联想 4. JSON结构完整字段双引号、无语法错误仅输出JSON。 请严格按上述SPC-E框架规则处理以下客户备注。 客户备注这个系统词完全遵循前述的程序化提示词框架 SPC-E 首先是核心基础模块 Role、Problem、Objective;然后是SPC-E核心框架模块包括SchemaS定义输入输出数据的规范Step templateP 定义执行的步骤以及步骤间的前后依赖Constrants © , 定义约束和上下文范围EExample Evaluation定义示例和自检规则这里要注意的是1对于输出字段要在代码中和提示词中做共同定义。提示词中是要提供字段的语义是供大模型理解和使用而代码中目的是对输出格式进行严格的约束并校验为后续的程序的正常使用做好校验避免导致程序异常。虽然langchain也支持通过 Field(description“”) 自动注入到提示词中但是出于业务和代码分离的意图我建议还是采取双重定义即分离也做双重校验后续可以考虑在一个文件中写通过引用同时编码到代码和提示词中2同类内容只在一处写避免后续散弹式修改。比如要求在输出定义中已经通过schema要求先输出CoT过程在约束中就没有必要再写“必须先CoT思考过程”。如果写两处将来要改找起来就麻烦。3. Python代码fromlangchain.agentsimportcreate_agentfromlangchain.messagesimportHumanMessagefromlangchain_deepseekimportChatDeepSeekfromlangchain.chat_modelsimportinit_chat_modelfrompydanticimportBaseModel,FieldfromtypingimportLiteralfromrichimportprintfromdotenvimportload_dotenvimportlogging,sys,os,logging,http.client#加载环境变理load_dotenv()# 开启完整 DEBUG 日志logging.basicConfig(levellogging.DEBUG,format%(asctime)s - %(name)s - %(levelname)s\n%(message)s\n,streamsys.stdout)# 开启 openai 库的 DEBUG 日志logging.basicConfig(levellogging.DEBUG)# 让 http.client 打印完整的请求/响应报文http.client.HTTPConnection.debuglevel1# 强制打开 LangChain LLM 日志logging.getLogger(langchain.chat_models).setLevel(logging.DEBUG)logging.getLogger(openai).setLevel(logging.DEBUG)logging.getLogger(openai._base_client).setLevel(logging.DEBUG)#定义结构化返回体要与Prompt内的定义完全一致。classRemarkInfo(BaseModel):cot_process:strfact:strexplicit_intent:strimplicit_intent:stremotion:Literal[不满,焦虑,生气,失望,平静]priority:Literal[高,中,低]next_action:Literal[回电安抚,优先处理,催促补发,发起退款,升级专员]# 读取系统提示词文件defload_prompt(file_path:str)-str:withopen(file_path,r,encodingutf-8)asf:returnf.read()system_promptload_prompt(resources/prompt/system_prompt.txt)# 初始化模型modelinit_chat_model(modeldeepseek-chat,temperature0.1,top_p0.3,frequency_penalty0.8,presence_penalty0.8,max_tokens1000,## stop [\n\n])#创建Agentagentcreate_agent(modelmodel,system_promptsystem_prompt,response_formatRemarkInfo)#用户问题questionHumanMessage(content刚买的灯泡又烧坏了)#调用模型responseagent.invoke({messages:[question]})#打印输出print(*50)print(response:,response)输出RemarkInfo( fact刚买的打氧器声音太大影响睡眠, explicit_intent询问是否有静音型号要求换货, implicit_intent希望更换为噪音较小的产品解决睡眠受影响问题, emotion不满, priority中, next_action优先处理 )代码说明RemarkInfo 严格定义了结构体的返回schema, 经过langchain处理后会作为一个构造方法发给大模型在模型看来与普通的方法并没有任何区别。模型在返回数据前根据上下文的提示词调用该方法把该返回的结果当作工具请求参数注入进去。对于客户端来说同样调用执行构造方法初始化出来一个对象与其它普通方法的区别是在函数执行完后不会再向模型进行下一步的请求。因为系统提示词中除了在tools中有这个RemarkInfo之外其它地方并没有对RemarkInfo的说明因此只有字段进行匹配。因此在整个提示词中RemarkInfo中的字段在整个提示词和代码中必须严格一致。langchain中提示词分成了system 以及 user 两类分别对应AI Agent 开发者设计的提示词以及使用者的用户问题。开始了后台的http请求日志以及langchain的日志方便调测3. 模型请求{messages:[{content:... 此处原始为系统提示词 ...,role:system},{content:刚买的灯泡又烧坏了,role:user}],model:deepseek-chat,frequency_penalty:0.8,max_tokens:1000,presence_penalty:0.8,stream:False,temperature:0.1,tool_choice:required,tools:[{type:function,function:{name:RemarkInfo,description:,parameters:{properties:{cot_process:{type:string},fact:{type:string},explicit_intent:{type:string},implicit_intent:{type:string},emotion:{enum:[不满,焦虑,生气,失望,平静],type:string},priority:{enum:[高,中,低],type:string},next_action:{enum:[回电安抚,优先处理,催促补发,发起退款,升级专员],type:string}},required:[cot_process,fact,explicit_intent,implicit_intent,emotion,priority,next_action],type:object}}}],top_p:0.3}可以看到在messages中可以看system prompt 和 user prompt 两类提示词langchain直接定义了一个tool, 把按照固定结构体返回给转换成了模型要调用一个结构体类的构造函数。而其中的参数就是我们在RemarkInfo对象中定义的结构体经langchain处理后作为一个function放到请求体的tools4. 模型返回{messages:[HumanMessage(content刚买的灯泡又烧坏了,additional_kwargs{},response_metadata{},ida0038930-5eb5-4785-b1be-2b06a2e007d9),AIMessage(content,additional_kwargs{refusal:None},response_metadata{token_usage:{completion_tokens:323,prompt_tokens:1803,total_tokens:2126,completion_tokens_details:None,prompt_tokens_details:{audio_tokens:None,cached_tokens:1792},prompt_cache_hit_tokens:1792,prompt_cache_miss_tokens:11},model_provider:deepseek,model_name:deepseek-chat,system_fingerprint:fp_eaab8d114b_prod0820_fp8_kvcache_new_kvcache_20260410,id:c9006cf2-619f-4adc-8593-b430b3d7ccf7,finish_reason:tool_calls,logprobs:None},idlc_run--019d7c4d-3fa3-7103-9094-b72b7d94598e-0,tool_calls[{name:RemarkInfo,args:{cot_process:步骤1仅提取「客户原始备注」中的客观事实输出fact刚购买的灯泡再次烧坏\n步骤2基于步骤1的fact识别客户明确提及的显性诉求输出explicit_intent无明确直接诉求用户未明确说出具体要求\n步骤3基于步骤1-2的结果推导客户未明说的隐性诉求输出implicit_intent希望解决灯泡质量问题或寻求售后处理\n步骤4基于fact/诉求匹配emotion枚举值priority枚举值输出emotion不满使用又字表明重复出现问题priority中影响产品质量问题但无紧急时间限制\n步骤5基于步骤1-4的结果匹配next_action枚举值输出next_action优先处理需要优先关注产品质量问题,fact:刚购买的灯泡再次烧坏,explicit_intent:无明确直接诉求,implicit_intent:希望解决灯泡质量问题或寻求售后处理,emotion:不满,priority:中,next_action:优先处理},id:call_00_1z9dIds04EyW8k9NYr54Dao4,type:tool_call}],invalid_tool_calls[],usage_metadata{input_tokens:1803,output_tokens:323,total_tokens:2126,input_token_details:{cache_read:1792},output_token_details:{}}),ToolMessage(contentReturning structured response: cot_process\步骤1仅提取「客户原始备注」中的客观事实输出fact刚购买的灯泡再次烧坏\\n步骤2基于步骤1的fact识别客户明确提及的显性诉求输出explicit_intent无明确直接诉求用户未明确说出具体要求\\n步骤3基于步骤1-2的结果推导客户未明说的隐性诉求输出implicit_intent希望解决灯泡质量问题或寻求售后处理\\n步骤4基于fact/诉求匹配emotion枚举值priority枚举值输出emotion不满使用又字表明重复出现问题priority中影响产品质量问题但无紧急时间限制\\n步骤5基于步骤1-4的结果匹配next_action枚举值输出next_action优先处理需要优先关注产品质量问题\ fact\刚购买的灯泡再次烧坏\ explicit_intent\无明确直接诉求\ implicit_intent\希望解决灯泡质量问题或寻求售后处理\ emotion\不满\ priority\中\ next_action\优先处理\,nameRemarkInfo,id14b71046-7c09-4f05-94d0-73e0fbfd5708,tool_call_idcall_00_1z9dIds04EyW8k9NYr54Dao4)],structured_response:RemarkInfo(cot_process步骤1仅提取「客户原始备注」中的客观事实输出fact刚购买的灯泡再次烧坏\n步骤2基于步骤1的fact识别客户明确提及的显性诉求输出explicit_intent无明确直接诉求用户未明确说出具体要求\n步骤3基于步骤1-2的结果推导客户未明说的隐性诉求输出implicit_intent希望解决灯泡质量问题或寻求售后处理\n步骤4基于fact/诉求匹配emotion枚举值priority枚举值输出emotion不满使用又字表明重复出现问题priority中影响产品质量问题但无紧急时间限制\n步骤5基于步骤1-4的结果匹配next_action枚举值输出next_action优先处理需要优先关注产品质量问题,fact刚购买的灯泡再次烧坏,explicit_intent无明确直接诉求,implicit_intent希望解决灯泡质量问题或寻求售后处理,emotion不满,priority中,next_action优先处理)}整个对象包含两大块messages完整的对话交互历史用户提问 → AI 思考调用工具 → 工具返回结果HumanMessage客户端发送用户问题“刚买的灯泡又烧坏了”AIMessage执行停止‘finish_reason’: ‘tool_calls’,需要调用工具RemarkInfo,并将参数注入返回ToolMessage客户端收到大模型返回的信息后其中包括需要调用的方法以及参数执行RemarkInfo构造方法注入参数记录日志structured_response本地使用RemarkInfo 输出结构化结果这里稍微注意一下模型是把需要调用方法这个事作为一次应答消息返回给客户端的这个时候一次请求响应就结束了。大模型是把每次的请求作为一个独立的请求来看的。后面要不要再把工具执行结果交给模型来处理是由本地客户端决定的。如果需要可能就要把历史交互以及工具执行结果一起打包再作为请求发给模型模型才能继续往下面处理如果不需要处理就结束了比如这里调用RemarkInfo方法上面的请求和返回也可以在Langsmith上查看在前面的.env中配置了langsmith的API key ,就会自动的发送日志到langsmith)四、未竟之事一、在实际的工程中提示词不可能在一个文件中全部写完考虑到可读性、可复用、一致性等等直接在一个文件中都不合理。因此需要将提示词文件拆成多个相互之间有引用关系二、对于提示词中涉及到的参数可能在输出中有引用也可能在step template或者example中有引用同时这些参数在代码中还会涉及这样对于后期维护修改很不利因此需要改为占位符的方式在一个文件中统一定义而后分别在代码和提示词中引用三、对于step template, 有可能会有一种情况就是出现了一个提示词中的步骤过于臃肿庞大其中一部分需要提取出来作为一个独立步骤又或者我们需要重用一个已经存在的提示词中的步骤。那么就要使用类似于方法中调用其它方法的机制。第四是现在提示词还在发展并且也挺庞杂我们还需要持续跟踪下面也有一些好的课程可以参考https://www.promptingguide.ai/zhhttps://www.emergentmind.com/topics/modular-prompting-mothttps://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/五、上文提到的“程序化提示词框架 SPC-E”可能还需要进一步拆解提示词的管理和组织形态是走“面向过程”还是“面向对象”我现在拿不准这里首先面临的是将来的程序是自然语言为主还是高级语言为主 在高级语言为主时自然语言程序是不是作为一个一个方法供调用就够了欢迎指导和探讨