AI Prompt 工程化设计最佳实践-北京尧图网络

核心理念把 Prompt 当作代码大多数开发者与 LLM 交互时是把 prompt 当作自然语言对话来写的❌ “帮我生成一张图片内容是一个苹果风格可爱”工程化的做法是把 prompt 当作代码来管理——有输入、有处理逻辑、有输出格式、有错误处理✅ 输入 → 分类 → 路由到对应模板 → 结构化参数注入 → 组装 → 最终 prompt核心心态转变你不是在和 AI “聊天”你是在编程驱动 AI。这引出了第一条也是最根本的原则。原则一Plan-and-Prompt 分离问题当 LLM 直接生成最终 prompt 时你无法控制哪些内容应该出现、哪些不应该约束是否被遵守输出格式是否一致模式┌──────────────────────────────────────────────────┐│ 你的代码 ││ ││ 输入 ──→ Plan阶段(LLM) ──→ 结构化结果 ││ │ ││ ▼ ││ Build阶段(纯代码) ││ │ ││ ▼ ││ 最终 Prompt ││ │ ││ ▼ ││ 执行阶段(LLM / 图像模型 / …) ││ │└──────────────────────────────────────────────────┘Plan 阶段LLM将高层次需求转为结构化 JSON。LLM 只做语义转换。Build 阶段纯代码将结构化规格确定性地组装成最终 prompt。不经过 LLM。Execute 阶段目标模型将最终 prompt 发送给图像/文本/代码模型。为什么这样做维度 LLM 直接生成 prompt Plan-and-Prompt 分离可控性低——LLM 可能忽略约束高——代码控制最终 prompt 的每个词可调试性低——不知道是理解错了还是表达错了高——可以分别检查 Plan 和 Final Prompt约束遵守不可靠——LLM 经常忘记负向约束代码保证约束一定出现在最终输出中一致性低——每次输出格式可能不同代码保证输出格式始终一致可测试性难——只能端到端测试易——Build 阶段可单独单元测试代码示例❌ 反模式让 LLM 直接生成最终 promptresponse llm.chat(fGenerate an image prompt for: {user_input})final_prompt response.text # 不可控✅ Plan-and-Prompt 分离plan llm.chat_json(system“Extract visual semantics from the input as JSON.”,useruser_input)plan {“mainSubject”: “a red apple”, “style”: “flat illustration”, …}final_prompt build_prompt(plan) # 纯代码确定性“A simple flat illustration of a red apple. Clean lines, centered…”适用场景任何需要精确控制最终 prompt 的场景文生图、文生视频、代码生成、文档生成需要遵守敏感词、合规、品牌安全规则的场景需要支持 A/B 测试 prompt 变体的场景Agent / Tool-calling 的中间步骤规划3. 原则二多阶段流水线问题单一 LLM 调用试图完成理解输入规划内容格式化输出三件事每一步的失败都会污染下一步。模式将复杂任务拆分成独立、可替换、可单独测试的阶段Stage 1 Stage 2 Stage 3 Stage 4┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│ Parse │───▶│ Classify │───▶│ Plan │───▶│ Build ││ (纯代码) │ │ (纯代码) │ │ (LLM) │ │ (纯代码) │└──────────┘ └──────────┘ └──────────┘ └──────────┘输入类型规格最终格式每个阶段的职责阶段执行者职责输入 → 输出Parse 纯代码提取结构化信息原始字符串 → 结构化对象Classify 纯代码判断类型/意图结构化对象 → 分类标签Plan LLM 语义转换、内容规划结构化对象分类 → JSON 规格Build 纯代码 Prompt 组装 JSON 规格 → 最终 prompt判断是否需要拆分的经验法则问题答案这个判断能用 if/else 做吗 → 不要用 LLM用代码这个转换需要理解语义吗 → 用 LLM这个格式化有固定格式要求吗 → 用代码不要依赖 LLM 记忆格式这个约束绝对不能违反吗 → 用代码硬编码不交给 LLM代码示例❌ 反模式一个 prompt 做所有事response llm.chat(f“”Analyze this input: {user_input}Classify its typePlan the visual contentOutput a final image prompt“”)✅ 多阶段流水线parsed parse_input(user_input) # Stage 1: 纯代码解析category classify(parsed) # Stage 2: 纯代码分类plan llm_plan(parsed, category) # Stage 3: LLM 语义规划prompt build_prompt(plan, category) # Stage 4: 纯代码组装4. 原则三Schema 即约束核心洞察LLM 输出的 JSON Schema 不只是数据格式——它是对 LLM 行为的最强约束。Schema 里有什么字段LLM 就会去思考什么Schema 里没有的字段LLM 就不会考虑。你可以通过选择性地暴露或隐藏字段来精确控制 LLM 的注意力范围。实践按场景使用不同 Schema❌ 反模式万能 Schema——包含所有场景的字段universal_schema {“overlayText”: “…”, # 字母卡才需要“allowVisibleText”: True, # 大部分场景不需要“sceneDescription”: “…”,“characterCount”: 0, # 只有人物场景需要# … 10 个字段}→ LLM 会为所有字段分配注意力包括不相关的✅ 按场景使用精简 Schemaif category “letter_card”:schema {“letter”: “…”,“illustration”: “…”,“allowText”: True}elif category “scene_card”:schema {“action”: “…”,“setting”: “…”,“mood”: “…”}# 没有 allowText 字段 → LLM 根本不会考虑要不要写字为什么字段的存在与否比值为 false更有效如果 schema 中有 allowText: falseLLM 仍然看到了 allowText 这个字段名已经被提示了文字这个概念如果 schema 中根本没有 allowText 字段LLM 的注意力完全不会被引导到文字方向同样的逻辑适用于任何你不希望 LLM 考虑的维度政治、暴力、品牌、价格……Schema 设计检查清单每个字段都是当前任务必需的吗不需要的就删掉字段名是否在引导正确的思维方向避免 text, label, caption 等词当任务不需要文字时是否有冗余字段可以用一个字段替代字段顺序是否反映了优先级LLM 通常更关注前面的字段5. 原则四Prompt 模块化组装问题把整个 prompt 写成一个长字符串或一个模板难以增删某个约束根据条件切换某一段单独调试某一部分做 A/B 测试模式Section 化将 prompt 分解为语义独立的 Section每个 Section 是 List 中的一个元素sections [# Section 1: 全局格式硬约束前置——最重要“The output must be a valid JSON array.”,# Section 2: 风格指令正向引导 Use professional, concise language., # Section 3: 条件性指令仅在需要时加入 *([Include citations for each claim.] if require_citations else []), # Section 4: 负向约束放在后面——安全网角色 Do not include personal opinions. Do not speculate.,]组装过滤空字符串用换行符连接final_prompt “\n”.join(s for s in sections if s)Section 的组织原则位置内容类型原因最前前25% 全局格式要求、关键硬约束 LLM 对 prompt 前半部分关注度更高中间任务描述、正向引导告诉 LLM “要做什么”条件根据上下文动态添加的指令按业务逻辑判断是否加入靠后负向约束、禁止列表防止稀释主体指令充当安全网最后输入数据 / 用户内容避免被误解释为指令的一部分为什么不用模板引擎模板引擎Jinja / Handlebars适合文本填空但不适合 prompt 工程条件逻辑写在模板里会变得难以阅读{% if %} 嵌套模板不容易做 Section 级别的 A/B 测试模板的空白符控制经常出问题推荐做法在代码中构建 list[str]最后 join。每个 Section 是一行代码清晰、可调试、可单测。代码示例条件性 Sectiondef build_system_prompt(user_role: str, task_type: str, include_examples: bool) - str:sections [“You are a helpful assistant. Be concise and accurate.”]# 按角色定制 if user_role expert: sections.append(Use technical terminology appropriate for domain experts.) elif user_role beginner: sections.append(Explain concepts in simple terms. Avoid jargon.) # 按任务类型定制 if task_type creative: sections.append(Be imaginative and explore multiple angles. Up to 500 words.) elif task_type analytical: sections.append(Be rigorous and evidence-based. Cite sources. Up to 300 words.) # 可选示例 if include_examples: sections.append(Include 1-2 concrete examples in your response.) return \n\n.join(sections)

AI Prompt 工程化设计最佳实践

相关推荐

AD5593R与PIC18F55K42的硬件协同设计与应用

【JAVA毕设源码分享】基于SpringBoot的房屋租赁系统的设计与实现(程序+文档+代码讲解+一条龙定制)

JDK安装配置全解：从环境变量到多版本共存

更多资讯

基于SpringBoot的班主任管理系统设计与开题实践

开源合规下编程语言选择与许可证管理实践

cocos2d-x中libluajit.a的ABI兼容性解析与集成指南

班主任管理系统毕业设计：SpringBoot+Vue+MySQL实战与开题

KAN网络模型解析：原理、实现与混合架构应用

船舶柴油机可解释故障诊断实战方法

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？