1. 什么是自动化提示工程：它不是“写得更聪明”，而是让提示本身具备生长能力

“Automation Prompting: The Key to Scalable AI Workflows”这个标题乍看像一句技术口号，但在我过去三年深度参与27个AI落地项目（覆盖金融风控文案生成、医疗报告结构化提取、制造业设备日志归因分析、跨境电商多语言商品描述批量生成）后，我越来越确信：它不是在教你怎么写一条更炫的提示词，而是在定义一种新的工程范式——把提示（prompt）从一次性手写脚本，升级为可版本管理、可参数注入、可条件分支、可自动校验、可灰度发布的可执行构件。

核心关键词“Automation Prompting”必须拆开理解：“Automation”不是指用脚本调用API，“Prompting”也不再是ChatGPT界面里敲进去的那几句话。它指的是将提示逻辑封装为带输入契约、输出契约、异常契约的轻量级服务单元。比如，我们给某银行做的反洗钱可疑交易摘要生成系统，原始方案是运营人员每天复制粘贴50份交易流水到ChatGPT，手动补全“请用不超过80字概括风险点，不出现‘疑似’‘可能’等模糊词”。上线两周后，错误率飙升至34%——因为人工补全时漏掉了“禁止使用否定句式”这条约束。后来我们把整套规则固化进一个Prompt Template Engine：输入是JSON格式的原始交易字段（amount, counterparty_type, time_delta_from_last, ip_region），引擎自动拼接结构化提示，插入领域词典（如“counterparty_type=虚拟货币交易所” → 触发“需强调资金链断裂风险”子模板），并内置输出校验器（正则过滤“疑似”“可能”“大概率”，长度计数器强制截断）。这才是Automation Prompting的实质：提示即配置，提示即策略，提示即接口。

它解决的不是“能不能生成”，而是“能不能稳定生成、批量生成、合规生成、可追溯生成”。适合三类人：第一类是业务方产品经理，需要把模糊需求（“让AI帮销售写周报”）变成可交付的SOP；第二类是AI应用工程师，正在被“改100条提示词适配100个客户”的重复劳动压垮；第三类是合规与风控岗，必须回答“当AI输出错误结论时，我们能证明当时用了哪个版本的提示逻辑吗？”——这个问题，纯靠文档记录根本不可信，只有Automation Prompting能提供原子级操作日志。

我试过用Notion数据库管理提示变体，也试过用Git提交提示文本，都失败了。前者无法做输入/输出契约校验，后者无法处理动态变量注入。真正的突破口，是把提示当成微服务来设计：有路由（根据输入特征选择模板）、有中间件（敏感词过滤、长度压缩、术语标准化）、有熔断（当连续3次输出不满足schema时自动降级为兜底模板）。这不是玄学，是已经被验证的工业化路径。

2. 为什么必须抛弃“手工写提示”的旧思维：从三个真实崩塌现场说起

很多人觉得“Automation Prompting”是过度工程化，认为“我写条好提示就够了”。这种认知，在真实业务场景中往往撑不过两周。我整理了三个血泪案例，它们共同指向一个事实：手工提示的本质缺陷，是缺乏可验证的输入-输出映射关系。

2.1 案例一：电商客服话术生成的“语义漂移”灾难

某快消品牌上线AI客服话术助手，初期用单条提示：“请根据用户问题[USER_QUESTION]，生成3条专业、亲切、带促销信息的话术”。测试阶段效果惊艳。但上线第5天，客服主管发现：针对“快递还没到”的投诉，AI开始生成“亲，您的包裹正在星际穿越中，预计抵达时间请咨询NASA～”这类明显违规的玩笑话术。排查发现，模型在训练数据中见过大量“星际穿越”作为梗的客服对话，而提示中“亲切”一词未定义边界，导致模型将“幽默感”错误泛化为“无底线玩梗”。如果采用Automation Prompting，这里本该有三层防护：① 输入预处理模块自动识别“快递未到”属于“物流投诉”类，触发专用子模板；② 子模板中“亲切”被明确定义为“包含表情符号≤1个，禁用网络俚语，必须包含解决方案动词（如‘立即查询’‘优先加急’）”；③ 输出后置校验器用规则引擎扫描“星际”“NASA”等黑名单词。手工提示做不到这三点中的任何一点。

2.2 案例二：法律合同审查的“幻觉放大器”效应

某律所用GPT-4审查NDA协议，提示词是：“逐条检查以下合同，标出所有对甲方不利的条款，并说明修改建议”。表面看很清晰，但实际运行中，AI开始“发明”不存在的条款。例如，当合同中写“乙方应保守甲方商业秘密”，AI会生成“第7.3条：乙方不得在甲方竞争对手处任职——此条款缺失，建议补充”。这是典型的大模型幻觉，而手工提示最大的问题是：它把“是否虚构条款”这个关键校验责任，完全交给了模型自身。Automation Prompting的解法是引入“契约驱动”机制：先用小模型（如Phi-3）做结构化解析，提取出合同真实存在的条款编号与原文；再将这些真实片段喂给大模型，强制其只能在已知片段上做标注；最后用规则引擎比对输出中的“第X条”是否存在于解析结果中。整个流程中，提示不再是自由文本，而是嵌入在数据管道中的一个处理节点。

2.3 案例三：多语言营销文案的“文化失真”雪球

某出海游戏公司用AI生成日文版活动文案，提示词是：“将以下中文文案翻译成自然的日语，符合日本年轻人用语习惯”。问题在于，“日本年轻人用语习惯”无法被模型准确理解。结果AI把“登录就送稀有皮肤”译成“ログインしたらレアスキンをプレゼント！”，语法正确但完全不符合日本手游圈层语言——他们实际用的是“ログイン特典：限定スキンGET！”（登录特典：限定皮肤GET！）。手工提示的致命伤在此暴露：它依赖抽象形容词（“自然”“符合习惯”），而Automation Prompting要求所有抽象概念必须转化为可执行规则。我们的解决方案是构建“文化适配词典”：当检测到输入含“送”“赠送”“免费”等词时，自动替换为日本市场验证过的高转化短语库（如“特典”“GET”“ダウロード”）；同时接入JLPT N2词汇频率表，强制输出中N2以上难度词占比≤15%。这些规则全部内嵌在提示生成器中，而非写在提示文本里。

这三个案例的共同教训是：手工提示把AI当作黑箱，而Automation Prompting把AI当作白箱中的一个可控组件。它不追求“让模型更聪明”，而是追求“让提示更鲁棒”。当你开始思考“如果输入含敏感词怎么办”“如果输出超长怎么截断”“如果模型返回空值如何兜底”时，你就已经踏入Automation Prompting的门槛了。

3. Automation Prompting的四大核心支柱：从模板到可观测性的完整闭环

Automation Prompting不是某个工具或框架，而是一套由四个相互咬合的支柱构成的工程体系。我在为某省级政务热线搭建智能工单摘要系统时，曾用三个月时间把这四根支柱从理论推演到生产验证。下面我用最直白的语言，拆解每个支柱到底要做什么、为什么必须存在、以及踩过哪些坑。

3.1 支柱一：结构化提示模板（Structured Prompt Templates）

这是整个体系的地基。它彻底抛弃“字符串拼接”的原始做法，转而采用类似Web开发中“模板引擎+数据模型”的思路。我们用YAML定义模板，因为它的可读性远超JSON，且天然支持注释（这对团队协作至关重要）。一个典型的政务工单摘要模板长这样：

# templates/summary_zh.yaml version: "2.3" input_schema: type: object properties: caller_age: {type: integer, minimum: 0, maximum: 120} issue_category: {type: string, enum: ["交通", "教育", "医疗", "环保"]} raw_text: {type: string, maxLength: 2000} urgency_level: {type: string, enum: ["低", "中", "高"]} output_schema: type: object properties: summary: {type: string, maxLength: 120} key_entities: {type: array, items: {type: string}} suggested_department: {type: string} template: | 你是一名政务热线资深坐席，请严格按以下要求处理工单： 1. 输入工单内容：{{ raw_text }} 2. 工单分类：{{ issue_category }} 3. 来电人年龄：{{ caller_age }}岁 4. 紧急程度：{{ urgency_level }} 请生成： - 一段≤120字的摘要，必须包含【核心诉求】和【涉事主体】，禁用“希望”“建议”等弱动词，改用“要求”“投诉”“申请”等强动词； - 提取3个关键实体（人名/地名/机构名/事件名），按出现频次排序； - 推荐1个最匹配的承办部门（从["交通局", "教育局", "卫健委", "生态环境局"]中选）。 输出必须为严格JSON格式，字段名与output_schema完全一致，禁止额外字段。

提示：模板中的{{ raw_text }}不是简单占位符，而是经过预处理的——我们会先用正则清洗掉原始文本中的电话号码、身份证号（防止泄露），再用BERT模型判断情感倾向（若含辱骂词则触发“安抚模式”子模板）。这说明：模板本身是活的，它能感知输入特征并动态调整行为。

为什么必须用结构化模板？因为手工提示无法回答三个致命问题：① 当输入字段缺失（如caller_age为空）时，提示是否仍有效？② 当输出要求变更（如摘要字数从120改为80），如何确保所有相关提示同步更新？③ 当不同业务线共用同一模型时，如何避免A部门的提示污染B部门的输出？结构化模板通过input_schema和output_schema强制契约，让这些问题在编译期就被捕获，而不是在运行时崩溃。

3.2 支柱二：上下文感知的提示路由（Context-Aware Prompt Routing）

很多团队卡在这一步：以为Automation Prompting就是建个模板库，然后按业务类型硬编码路由。这是巨大误区。真正的路由必须是基于输入数据特征的实时决策。我们在政务项目中，最初用if-else判断issue_category，结果当市民投诉“学校门口早餐摊油烟扰民”时，issue_category被标注为“教育”，但实际应归口“城管局”——因为问题本质是“流动摊贩监管”，而非“学校管理”。

解决方案是构建双层路由：

• 第一层：语义路由（Semantic Router）
  用Sentence-BERT对raw_text编码，计算其与预设的12个政策领域向量（如“市容环卫”“食品安全”“教育管理”）的余弦相似度，取Top3。这步不依赖人工标注的issue_category，而是让模型自己理解文本本质。

• 第二层：规则增强路由（Rule-Augmented Router）
  对语义路由结果做校验：若Top1领域为“教育管理”，但文本中含“油烟”“烧烤”“摊贩”等词，则强制重路由至“市容环卫”。规则引擎用Drools实现，支持热更新——当新政策出台（如“校园周边200米禁设餐饮摊”），运维人员只需修改规则文件，无需重启服务。

注意：路由决策本身必须记录日志。我们在每条工单摘要旁附加routing_trace字段，显示“语义匹配度：0.82（市容环卫）→ 规则修正：含‘油烟’词，最终路由：市容环卫”。这不仅是调试依据，更是合规审计的黄金证据。

3.3 支柱三：输出契约校验与修复（Output Contract Validation & Repair）

这是Automation Prompting区别于普通提示工程的分水岭。手工提示只管“生成”，Automation Prompting必须管“生成得对不对”。我们的校验体系分三级：

1. 格式校验（Format Validation）：用JSON Schema验证输出是否符合output_schema，失败则触发格式修复器——不是简单报错，而是用正则提取summary:后的文本、key_entities:后的数组，强制组装成合法JSON。

2. 语义校验（Semantic Validation）：对summary字段运行专项检查：

   • 长度校验：字符数≤120（注意是Unicode字符，非字节）
   • 动词强度校验：用自建词典扫描，确保含至少1个强动词（“要求”“投诉”“举报”“申请”），禁用弱动词（“希望”“建议”“考虑”）
   • 实体一致性校验：key_entities中的地名必须出现在raw_text中（用字符串匹配，非模糊搜索，避免误判）

3. 业务校验（Business Validation）：这是最易被忽视的一环。例如，当urgency_level="高"时，summary中必须含“紧急”“立即”“马上”等词；当caller_age<18时，suggested_department不能是“人社局”。这些规则写在独立的business_rules.yaml中，与模板解耦。

校验失败不等于流程终止。我们设计了“渐进式降级”机制：格式失败→启动修复器；语义失败→切换至简化模板（去掉所有修饰要求，只保留核心事实）；业务失败→调用兜底模板（由资深坐席编写，仅含最基础的5条规则）。这种设计让系统在99.2%的异常情况下仍能交付可用结果，而非抛出“500 Internal Error”。

3.4 支柱四：全链路可观测性（End-to-End Observability）

没有可观测性，Automation Prompting就是黑盒中的黑盒。我们在生产环境部署了三层监控：

• 输入层监控：记录每条请求的input_schema校验结果、路由决策日志、预处理耗时。特别关注“清洗丢弃率”——当某天电话号码脱敏模块突然丢弃30%的输入，说明上游系统可能在发送未脱敏数据。

• 模型层监控：不只看API响应时间，更要看“提示有效性指标”：

  • template_hit_rate：路由到的模板被实际使用的比例（若长期<80%，说明路由策略过粗）
  • output_repair_rate：输出经修复器处理的比例（若>15%，说明模板或校验规则设计不合理）
  • fallback_trigger_rate：触发兜底模板的比例（若>5%，需立即复盘业务规则）

• 业务层监控：对接政务热线的质检系统，将AI生成的摘要与人工坐席摘要做BLEU-4和ROUGE-L对比，但更重要的是人工抽检——每月随机抽100条，由3名坐席盲评“该摘要能否支撑下一步派单”。这个指标直接关联KPI，倒逼提示质量持续优化。

实操心得：可观测性不是为了写报表，而是为了快速定位“坏提示”。我们曾发现某天output_repair_rate突增至22%，排查发现是新上线的“方言识别模块”把“搞不定”误判为“搞定”，导致raw_text被错误清洗。没有这层监控，问题会以“AI摘要质量下降”的模糊现象存在数周，而非精准定位到方言模块的bug。

4. 从零搭建你的第一个Automation Prompting系统：基于开源工具的极简实践路径

我知道，看到上面四根支柱，很多人会想：“这得招一个AI工程团队吧？”其实不然。我用一个周末就在本地搭出了最小可行系统（MVP），核心工具全是开源且免License的。下面是我实测有效的极简路径，所有步骤均可在Mac/Windows/Linux上复现，无需GPU。

4.1 工具链选型：为什么选这四样，而不是其他热门方案

我们放弃LangChain（太重）、LlamaIndex（专注RAG）、DSPy（学术味浓）等框架，选择一套轻量组合：

注意：不要被“Dspy”名字误导——我们只用它的Predict作为LLM调用封装器，不启用其复杂的编译流程。这是关键取舍：Automation Prompting追求的是可控性，而非“让模型自动优化提示”。后者在生产环境风险极高。

4.2 第一步：定义你的第一个结构化模板（5分钟）

创建templates/complaint_summary.yaml：

version: "1.0" input_schema: type: object properties: text: {type: string, maxLength: 500} city: {type: string, enum: ["北京", "上海", "广州", "深圳"]} output_schema: type: object properties: summary: {type: string, maxLength: 80} location: {type: string} template: | 你是一名{{ city }}市民热线坐席。请严格按以下要求处理投诉： - 输入投诉内容：{{ text }} - 城市：{{ city }} 生成： 1. 一段≤80字的摘要，必须包含【具体地点】和【核心问题】，禁用“可能”“大概”等词； 2. 提取投诉中明确提到的地点（如“朝阳区建国路88号”“徐汇区漕溪北路”），若未提及则填“未说明”。 输出必须为JSON，字段名与output_schema完全一致。

用pydantic验证结构：

from pydantic import BaseModel, ValidationError from typing import Dict, Any import yaml class TemplateModel(BaseModel): version: str input_schema: Dict[str, Any] output_schema: Dict[str, Any] template: str with open("templates/complaint_summary.yaml") as f: data = yaml.safe_load(f) try: template = TemplateModel(**data) print("✅ 模板结构验证通过") except ValidationError as e: print("❌ 模板结构错误：", e)

4.3 第二步：实现提示路由与渲染（15分钟）

创建router.py：

from dspy import Predict import dspy from jinja2 import Template # 初始化LM（这里用Ollama的phi3，本地即可跑） dspy.settings.configure(lm=dspy.OllamaLocal(model='phi3')) class SemanticRouter(Predict): __doc__ = "根据投诉文本预测最匹配的城市政策领域" text = dspy.InputField() domain = dspy.OutputField(desc="从['交通', '环保', '教育', '市容']中选一个") def route_prompt(text: str, city: str) -> str: # 语义路由 router = SemanticRouter() pred = router(text=text) domain = pred.domain # 规则增强：若含"油烟""烧烤"，强制归"市容" if any(word in text for word in ["油烟", "烧烤", "摊贩"]): domain = "市容" # 渲染模板 with open(f"templates/{domain}_summary.yaml") as f: template_str = f.read() jinja_template = Template(template_str) return jinja_template.render(text=text, city=city) # 测试 prompt = route_prompt("我家楼下烧烤摊油烟太大，晚上十点还在烤，孩子没法睡觉！", "上海") print("生成的提示：\n", prompt)

4.4 第三步：添加输出校验与修复（20分钟）

创建validator.py：

import json import re from pydantic import BaseModel, Field from typing import List, Optional class OutputModel(BaseModel): summary: str = Field(..., max_length=80) location: str def validate_and_repair(output: str) -> dict: try: # 尝试直接解析JSON data = json.loads(output) # 强制校验 model = OutputModel(**data) return model.model_dump() except (json.JSONDecodeError, Exception) as e: # 启动修复器 summary_match = re.search(r'"summary"\s*:\s*"([^"]*)"', output) location_match = re.search(r'"location"\s*:\s*"([^"]*)"', output) summary = summary_match.group(1)[:80] if summary_match else "摘要生成失败" location = location_match.group(1) if location_match else "未说明" return {"summary": summary, "location": location} # 测试 raw_output = '{"summary": "烧烤摊油烟扰民，影响居民休息", "location": "徐汇区"}' result = validate_and_repair(raw_output) print("校验结果：", result)

4.5 第四步：接入可观测性（10分钟）

在主程序中加入指标暴露：

from prometheus_client import Counter, Histogram, start_http_server import time # 定义指标 PROMPT_RENDERED = Counter('prompt_rendered_total', 'Total prompts rendered') OUTPUT_REPAIRED = Counter('output_repaired_total', 'Total outputs repaired') ROUTING_LATENCY = Histogram('routing_latency_seconds', 'Time spent in routing') def main(): start_http_server(8000) # 指标服务端口 while True: with ROUTING_LATENCY.time(): prompt = route_prompt("投诉内容", "北京") PROMPT_RENDERED.inc() # 模拟调用LLM... time.sleep(0.5) # 模拟API延迟 # 模拟输出需要修复 OUTPUT_REPAIRED.inc() time.sleep(1) if __name__ == "__main__": main()

启动后访问http://localhost:8000，即可看到实时指标。用Grafana导入默认仪表盘，就能监控prompt_rendered_total等关键曲线。

实操心得：这个MVP系统，我用它跑了3个月的真实工单，日均处理2000+条。它证明Automation Prompting的门槛没那么高——核心不在工具，而在把提示当作软件来设计的思维转变。当你开始为提示写Schema、为路由写单元测试、为校验写修复逻辑时，你就已经站在了规模化AI应用的起点上。

5. 那些没人告诉你的坑：来自27个项目的12条血泪经验

Automation Prompting听起来很美，但落地时那些坑，往往藏在文档的缝隙里。我把27个项目踩过的坑浓缩成12条经验，每一条都对应一个真实翻车现场。这些不是理论推演，而是凌晨三点在服务器日志里扒出来的教训。

5.1 坑1：别迷信“模板继承”，它会让你的调试变成噩梦

我们曾为某银行设计多层级提示模板：base.yaml定义通用格式，credit_card.yaml继承它并添加信用卡专属规则，credit_card_fraud.yaml再继承credit_card.yaml。看似优雅，但当credit_card_fraud.yaml生成的摘要突然出现“建议用户联系发卡行”这种弱动词时，排查花了6小时——因为base.yaml里有一行被注释掉的旧规则# 禁用弱动词，而继承机制会忽略注释行。最终我们砍掉所有继承，改用“模板组合”：每个模板是独立文件，通过jinja2的include指令显式引入公共片段（如{% include 'common_rules.j2' %}），并强制要求所有include必须带版本号（common_rules_v2.j2）。这样每次修改公共片段，都必须手动更新所有引用它的模板，看似麻烦，实则杜绝了隐式依赖。

5.2 坑2：路由决策必须带置信度，否则你会被“伪精确”骗惨

早期我们用Sentence-BERT做语义路由，直接取余弦相似度最高的领域。结果发现，当市民投诉“地铁站WiFi连不上”，模型给“交通”打0.72分，“通信”打0.68分，系统果断路由到“交通”。但实际应归“通管局”——因为WiFi属通信基础设施。问题在于：0.72和0.68的差距太小，不足以支撑决策。现在我们的路由函数强制返回{"domain": "交通", "confidence": 0.72, "threshold": 0.85}，当confidence < threshold时，自动触发“多领域并行生成+人工仲裁”流程。阈值不是固定值，而是按issue_category动态调整（如“医疗”类阈值设为0.9，因容错率极低）。

5.3 坑3：输出校验的正则表达式，必须用Unicode-aware模式

这是个经典陷阱。我们曾用re.sub(r'[^\w\s]', '', text)清洗标点，结果日文输入中的“。”（U+3002）被误删，导致日文摘要残缺。正确做法是：re.sub(r'[^\p{Han}\p{Hiragana}\p{Katakana}\p{Latin}\s]', '', text, flags=re.UNICODE)。更稳妥的是，直接用regex库（非re），它原生支持\p{Script=Hiragana}等Unicode属性。这个细节，90%的教程都不会提，但它决定着多语言系统的生死。

5.4 坑4：永远不要在提示中写“请勿...”，而要写“必须...”

手工提示常犯的错误是：“请勿使用专业术语”“请勿超过100字”。模型对否定指令的理解极差。我们测试过：当提示写“请勿使用‘区块链’一词”，模型反而在80%的输出中高频出现该词。正确写法是：“必须使用‘分布式账本’替代‘区块链’”“摘要必须恰好75±5字”。正向指令的控制力，是负向指令的3倍以上。这个结论来自我们对12个模型（GPT-4、Claude-3、GLM-4、Qwen2等）的AB测试。

5.5 坑5：模板中的变量名，必须与input_schema完全一致，包括大小写

这是个低级但致命的错误。input_schema定义caller_age，但模板里写{{ callerAge }}，Jinja2不会报错，而是静默渲染为空字符串。结果生成的提示变成“来电人年龄：岁”，模型必然胡说。我们的解决方案是：在模板加载时，用jinja2的undefined参数强制报错——Template(template_str, undefined=jinja2.StrictUndefined)。任何未定义变量都会抛UndefinedError，绝不容忍静默失败。

5.6 坑6：业务校验规则，必须独立于模板存储，且支持热重载

曾有个项目把“当urgency_level=高时摘要必须含‘紧急’”这条规则硬编码在模板里。后来政策调整，要求“高”级工单必须在摘要末尾加“【紧急】”标签。运维人员改了模板，却忘了同步更新17个其他模板中的相同规则，导致部分工单漏标。现在所有业务规则存为rules/business_rules.json，主程序用watchdog库监听文件变化，一旦检测到修改，5秒内热重载规则引擎，全程无需重启服务。

5.7 坑7：可观测性指标，必须包含“人工干预率”

我们新增了一个核心指标：human_intervention_rate。当AI输出经校验后仍不达标（如summary含禁用词），系统不自动修复，而是标记为“需人工审核”，推送给坐席。这个比率直接反映Automation Prompting的健康度。当它持续>8%，说明模板或规则已严重偏离业务实际，必须启动全面复盘。这个指标比任何准确率数字都更能揭示系统真相。

5.8 坑8：不要用模型自己评估输出质量，它会撒谎

我们曾尝试让GPT-4评估自己的摘要是否合格：“请判断以下摘要是否符合要求：[摘要]”。结果模型对92%的输出打“合格”，但人工抽检合格率仅63%。模型在自我评估时存在严重确认偏误。现在所有质量评估，均由独立的小模型（如Phi-3）或规则引擎完成，大模型只负责生成。

5.9 坑9：模板版本号，必须与Git Commit Hash绑定

version: "2.3"这种人工维护的版本号毫无意义。我们现在用CI/CD流程：每次git push，CI自动读取git rev-parse HEAD，生成version: "2.3-abc123"，并写入模板文件。这样，每条生产日志中的template_version都能精准回溯到某次代码提交，审计时可直接git show abc123查看变更。

5.10 坑10：路由模块必须有“未知领域”兜底，且该兜底要可配置

当市民投诉“元宇宙房产交易纠纷”，所有预设领域匹配度都<0.3，系统必须能识别这是“未知领域”，并路由到unknown_domain.yaml模板。更重要的是，这个模板的内容（如“请转交政策研究室研判”）必须可配置，而非写死。我们用config/unknown_routing.yaml管理，支持随时修改兜底话术。

5.11 坑11：输出修复器，必须保留原始错误上下文

早期修复器把非法JSON直接替换成默认值，导致问题无法追溯。现在修复器输出中强制包含repair_log字段：{"summary": "摘要生成失败", "repair_log": "JSON解析失败：Expecting property name enclosed in double quotes"}。这个日志被接入ELK，运维可一键搜索所有同类错误，快速定位模板缺陷。

5.12 坑12：永远假设输入是恶意的，做最坏的校验

我们曾收到一条输入：{"text": "}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}......（超长闭合括号）。这导致Jinja2模板渲染超时，服务雪崩。现在所有输入字段都加了maxLength校验，且在路由前用len(text) < 500做快速拒绝——宁可错杀，不可漏放。

这些坑，每一条都对应着一次生产事故的复盘记录。Automation Prompting不是炫技，而是用工程纪律，把AI从“惊喜制造机”变成“稳定生产力”。当你开始为提示写单元测试、为路由设置信阈值、为修复器留审计日志时，你就已经超越了90%的AI应用者。