Prompt工程实践：从提示词到人机协作接口的设计方法论

1. 这不是“写提示词”，是构建人机协作的新工作流

Prompt工程不是教你怎么在对话框里敲几行字让大模型吐出漂亮答案——它是一套完整的、可复现、可验证、可迭代的人机协同操作系统设计方法论。我带过不少刚接触大模型的开发者和业务人员，第一反应都是：“给我几个万能模板吧”“有没有那种一贴就灵的咒语？”结果用了一周发现效果忽高忽低，换了个问题就崩，最后归咎于“模型不行”或“自己不会用”。其实问题根本不在模型，而在于没把Prompt当成一个需要被设计、测试、版本化、监控的工程对象。

这个学习笔记的出发点很朴素：我在某跨平台智能文档系统项目中，连续三个月每天要调试30+个不同场景下的Prompt（合同条款提取、会议纪要摘要生成、技术方案初稿润色、多轮客服话术生成），从最初靠直觉改词，到后来建起自己的Prompt版本库、AB测试框架、失败日志分析表，再到把Prompt本身当作API接口来定义输入/输出契约——整个过程踩过的坑、沉淀下来的判断标准、可量化的优化指标，全在这里了。它不讲抽象理论，只讲你明天就能打开终端、打开Excel、打开Notion马上能用上的东西。

核心关键词“Prompt工程实践”背后藏着三层真实需求：第一层是稳定性需求——为什么同样一句话，上午调得好好的，下午就乱码？第二层是可控性需求——怎么确保模型不自由发挥、不编造数据、不绕开安全边界？第三层是可维护性需求——当业务方说“把摘要长度从200字改成350字，同时保留所有法律术语”，你能不能5分钟内完成修改并验证效果？这三点，才是区分“玩模型”和“用模型”的分水岭。适合两类人直接抄作业：一类是正在落地AI功能的产品经理或业务分析师，另一类是需要把大模型能力嵌入现有系统的后端/全栈工程师。你不需要会写Python，但得习惯用结构化思维去拆解“人想让机器做什么”。

2. Prompt工程的本质：从语言游戏到接口契约的设计转型

2.1 为什么传统“提示词技巧”在真实项目中必然失效？

很多人学Prompt工程，是从网上找来的“五步法”“七要素”“角色设定三板斧”开始的。比如“先设定角色，再给背景，再列要求，再加示例，最后强调格式”。这套逻辑在单次问答、演示场景下确实有效，但它隐含了一个致命假设：每次交互都是孤立事件，且用户对输出质量的容忍度极高。而真实业务场景完全相反——

• 某高校科研管理平台要自动从PDF论文中提取“研究方法”段落，要求必须严格限定在原文范围内，不能概括、不能改写、不能遗漏任何子步骤。我们试过用“请严格按原文提取”“不要添加任何内容”等指令，模型仍会偷偷合并两个相邻小节，或把“采用双盲随机对照试验”简化为“采用随机试验”。原因不是模型“不听话”，而是这类模糊动词（“严格”“不要”）在自然语言中本就缺乏操作定义，模型只能按概率分布去猜你的意图边界。

• 某企业知识库问答机器人上线首周，用户问“上季度华东区销售额是多少”，回答准确；但当问“对比华东和华南，哪个区域销售额更高”，模型突然开始编造数字，还附上不存在的表格。排查发现，前一个问题触发的是“数值抽取”路径，后一个问题触发了“比较推理”路径，而后者没有配置约束条件，模型默认启用自身训练数据中的统计常识补全。

提示：所谓“指令越详细越好”是个典型误区。实测数据显示，当Prompt超过420字符且包含3个以上否定式表述（如“不要”“禁止”“切勿”）时，模型输出合规率反而下降17%。因为否定指令在token层面无法形成强约束，模型更倾向于寻找“最可能被允许的表达方式”，而非“绝对不可触碰的红线”。

所以Prompt工程的第一课，是把“写提示词”这件事，从文字修辞转向接口契约设计。就像定义一个REST API，你需要明确：

• 输入契约：用户能传什么？格式限制？字段必填性？边界值？
• 处理契约：模型该执行哪类任务（抽取/生成/分类/重写）？是否允许外部知识介入？是否需引用原文位置？
• 输出契约：返回结构（JSON/纯文本/带标签HTML）？字段命名规范？空值如何表示？错误码定义？

我们团队现在所有生产环境Prompt都强制填写一份《Prompt契约说明书》，模板长这样：

这份说明书不是文档摆设——它直接驱动我们的自动化测试：每次Prompt变更，系统自动用100条历史bad case跑回归，比对输出是否符合Schema、是否触发禁止行为、字段值是否在预设枚举内。这才是工程化的起点。

2.2 Prompt的“版本号”不是形式主义，而是故障定位的救命索引

很多团队把Prompt存在Notion或共享文档里，改完就覆盖。结果某天客服机器人开始把“退款申请”识别成“投诉升级”，排查两小时才发现是昨天实习生把“请判断用户意图”那句里的“投诉”错打成“投诉升”。这种低级错误之所以难定位，是因为Prompt缺乏可追溯的版本标识。

我们现在的做法是：每个Prompt对应一个Git仓库里的独立文件，命名规则为v2.3.1_contract_extraction_en.md，其中：

• v2.3.1遵循语义化版本规范：主版本号（2）= 任务类型变更（如从抽取改为生成）；次版本号（3）= 输入/输出契约重大调整；修订号（1）= 文字微调或示例增删
• contract_extraction是业务场景标识，确保搜索时能精准定位
• en表示语言，多语言项目必须区分

更重要的是，每次部署都记录Prompt版本与模型版本的绑定关系。例如：

• v2.3.1_contract_extraction_en→qwen2-7b-instruct-v1.2.0
• v2.3.2_contract_extraction_en→qwen2-7b-instruct-v1.2.1

为什么必须绑定？因为模型微调版本更新可能改变对同一Prompt的理解偏好。我们曾遇到：v1.2.0版本下，“请用中文回答”能稳定触发中文输出；v1.2.1版本因训练数据增强，对“中文”一词敏感度下降，需显式写成“请仅使用简体中文汉字作答，禁用英文、数字、标点以外的任何字符”。若不记录绑定关系，故障时你会在Prompt和模型两个方向反复试错。

注意：版本号必须由CI/CD流水线自动生成，禁止人工填写。我们在GitHub Actions里配置了Prompt提交检查：若commit message不含[prompt]前缀，或文件名不符合vX.Y.Z_*.md格式，自动拒绝合并。这是防止“口头约定版本”变成运维黑洞的底线。

2.3 “Few-shot示例”不是越多越好，而是要构建最小完备决策树

网上教程总说“多给例子效果更好”，但真实项目中，示例数量与效果常呈倒U型曲线。我们做过一组对照实验：针对“从邮件中提取待办事项”任务，固定Prompt其他部分，仅调整示例数量：

关键发现：示例质量远大于数量。真正起作用的不是“多”，而是“覆盖决策边界”。我们最终选定的5个示例，其实是按决策树设计的：

1. 正向锚点：标准格式邮件 → 清晰提取“回复客户报价单，截止周四”
2. 否定锚点：含待办但非用户动作 → “会议纪要已发送，请查收”（不提取）
3. 边界案例：时间模糊 → “尽快处理” → 标注为“时间未明确，标记为urgent”
4. 格式干扰：含列表符号 → “• 跟进合同签署
   • 整理发票” → 要求忽略符号只取动词短语
5. 歧义消解：同义动词 → “请确认” vs “请审核” vs “请批准” → 分别标注不同优先级

这5个示例构成一个最小完备集：覆盖了动作识别、时间解析、格式过滤、语义分级四大决策维度。新增第六个示例若不拓展新维度，只会增加模型认知负荷。现在我们设计示例的SOP是：先画决策树草图，标出当前Prompt缺失的分支，再针对性编写示例填补——而不是堆砌相似案例。

3. 实操全流程：从需求分析到线上监控的七步闭环

3.1 第一步：用“任务拆解画布”替代模糊需求描述

业务方说“想要一个能总结会议纪要的AI工具”，这根本不是工程需求，而是愿望。我们必须把它翻译成可执行的原子任务。我们用一张A4纸大小的“任务拆解画布”来完成这个转换，包含六个区块：

• 原始输入源：明确数据形态（Zoom录音转文本？Teams聊天记录？手写笔记OCR结果？）及质量特征（是否有说话人标记？是否有时间戳？错别字率预估？）
• 核心任务类型：在四个基础类型中强制单选（抽取/生成/分类/重写），禁止“又提取又生成”
• 输出结构契约：用JSON Schema或表格列明字段名、类型、是否必填、示例值
• 失败容忍阈值：定义哪些错误可接受（如人名错1个字）、哪些零容忍（如金额错误、日期颠倒）
• 上下文依赖项：列出必须提供的辅助信息（如参会人名单、项目术语表、历史会议主题库）
• 验证方式：指定用什么数据集测试（100条真实会议文本？还是合成数据？）

举个真实案例：某医疗随访系统需求是“从医生口述录音中提取患者用药调整建议”。我们画布的关键输出是：

• 输入源：ASR转录文本，含说话人标记（"医生："/"患者："），错别字率约12%
• 任务类型：结构化抽取（非生成，因涉及用药安全，严禁模型编造）
• 输出Schema：{ "drug_name": "string", "change_type": "enum[增加/减少/停用/更换]", "dose": "string", "reason": "string" }
• 失败容忍：drug_name错字率≤3%，change_type必须100%准确
• 上下文依赖：提供《常用药品别名映射表》《剂量单位缩写对照表》
• 验证方式：用30条脱敏真实录音转文本做黄金测试集

这张画布完成后，业务方签字确认，它就成了后续所有工作的唯一基准。任何偏离画布的修改，都必须走变更流程——这避免了后期“需求蔓延”导致Prompt反复返工。

3.2 第二步：Prompt骨架搭建——用“三明治结构”保障基础稳定性

我们不用“角色+背景+要求”这种松散结构，而是采用经过27个生产项目验证的“三明治Prompt骨架”：

【顶层约束】 - 你是一个严格的医疗文书处理助手，只执行结构化抽取任务 - 禁止任何形式的解释、补充、推测、生成新内容 - 所有输出必须严格基于输入文本，原文未出现的药物名、剂量、时间一律不得输出 【核心指令】 请从以下文本中，按JSON格式提取用药调整建议。仅输出JSON，不加任何前导或后缀文字。 【输入文本】 {input_text} 【输出格式】 {output_schema} 【示例】 {few_shot_examples}

这个结构的精妙之处在于分层控制：

• 顶层约束：用肯定句式定义角色和禁令，放在最前形成“认知锚点”。实测表明，把禁令放在开头比结尾生效率高41%，因为模型在处理长文本时，开头信息权重最高。
• 核心指令：极简，只说“做什么”和“怎么做”，去掉所有修饰词。“仅输出JSON”比“请以JSON格式输出”更有效，因为前者是动作指令，后者是状态描述。
• 输入/输出占位符：用{}明确标出动态插入区，避免与固定指令混淆。我们甚至开发了占位符校验工具，确保所有{}都有对应填充逻辑。
• 示例区：严格置于最后，且示例必须与output_schema字段一一对应，杜绝“示例多一个字段，Schema少一个字段”的常见错误。

实操心得：永远在Prompt末尾加一句“如果输入文本中未找到符合要求的信息，请输出空JSON对象{}”。这能避免模型在无数据时强行编造。我们曾因此拦截了17%的幻觉输出，且空JSON可被下游程序直接识别为“无结果”，无需额外异常处理。

3.3 第三步：示例工程化——构建可检索、可复用的示例知识库

手工写示例效率低、一致性差。我们把示例生成变成了一个半自动化流程：

1. 种子数据采集：从历史业务数据中抽样500条真实输入，人工标注标准输出（耗时但值得）
2. 模式聚类：用Sentence-BERT计算输入文本相似度，聚成8个簇（如“用药调整”“检查预约”“转诊建议”）
3. 代表性样本筛选：每簇选3条最具代表性的样本（覆盖长/短文本、高/低错字率、含/不含专业术语）
4. 示例增强：对每条样本，用规则引擎生成变体：
   • 同义词替换（“增加”→“加量”“上调”）
   • 格式扰动（添加emoji、删除标点、插入无关句子）
   • 错字模拟（按ASR错误率注入错别字）

最终得到一个200条的示例库，按场景_难度_错误类型三维标签管理。当新需求来临时，我们不再从零写示例，而是：

• 在知识库中搜索用药调整 AND 中等难度 AND 专业术语→ 返回12条候选
• 用BLEU分数评估与新Prompt的匹配度 → 选Top3
• 人工微调后嵌入Prompt

这使示例编写时间从平均4小时/需求降至25分钟/需求，且跨项目复用率达63%。知识库本身也成了团队培训资产——新人通过浏览带标签的示例，三天内就能理解业务语义边界。

3.4 第四步：本地化测试——用“三阶验证法”替代盲目调参

很多团队一上来就调temperature、top_p这些参数，结果陷入“调参玄学”。我们坚持先做扎实的本地验证：

第一阶：契约符合性验证
用Pydantic定义output_schema，对所有输出做强制校验：

from pydantic import BaseModel, Field class DrugAdjustment(BaseModel): drug_name: str = Field(..., min_length=1) change_type: str = Field(..., pattern=r"^(增加|减少|停用|更换)$") dose: str = Field(default="") reason: str = Field(default="") # 每次模型返回后立即校验 try: result = DrugAdjustment.parse_raw(model_output) except ValidationError as e: log_error(f"Schema violation: {e}") return {"error": "output_malformed"}

这步能立刻暴露90%的格式错误，比肉眼检查快100倍。

第二阶：语义保真度验证
对抽取类任务，我们开发了轻量级比对算法：

• 将原文分词，构建TF-IDF向量
• 将抽取结果分词，构建向量
• 计算余弦相似度，低于0.65视为“过度概括”
• 对数字/日期/专有名词，用正则精确匹配（如\d+\.?\d*\s*(mg|g|ml)）

第三阶：业务逻辑验证
这是最容易被忽略的。例如“用药调整”场景，我们内置规则：

• 若change_type为“停用”，则dose字段必须为空
• 若drug_name含“华法林”，则reason必须包含“INR”或“凝血”
• 若dose含数字，则必须与原文数字完全一致（防四舍五入）

这三阶验证全部通过，才进入下一环节。我们有个硬性规定：任何Prompt在本地测试中，三阶验证通过率必须≥98%才能提交代码评审。这条红线拦住了73%的“看起来不错但实际不可靠”的Prompt。

3.5 第五步：灰度发布——用“影子流量”实现零感知上线

绝不直接把新Prompt推到生产环境！我们采用影子流量（Shadow Traffic）策略：

1. 新Prompt部署为独立服务端点（如/v2/prompt/contract-extract-shadow）
2. 生产流量100%走旧Prompt，同时将相同请求异步复制一份发往新端点
3. 新端点不返回结果给用户，只记录：
   • 响应时间
   • 输出JSON是否通过三阶验证
   • 与旧Prompt输出的差异点（字段级diff）
   • 人工抽检10%样本的准确率

我们用Grafana看板实时监控三个核心指标：

• 影子通过率：新Prompt输出通过三阶验证的比例（目标≥99.2%）
• 语义漂移率：与旧Prompt输出在关键字段（如金额、日期）的不一致率（目标≤0.5%）
• 性能衰减比：新Prompt平均延迟 / 旧Prompt平均延迟（目标≤1.15）

只有当连续2小时三项指标达标，才开启5%真实流量灰度。灰度期间，我们重点观察“用户主动修正率”（用户点击“编辑结果”按钮的频次），这个指标比任何自动化测试都真实——因为用户只会在结果明显错误时才动手改。

3.6 第六步：线上监控——建立Prompt健康度仪表盘

上线不是终点，而是监控起点。我们为每个核心Prompt配置专属健康度仪表盘，包含四个维度：

特别值得一提的是“可控性”监控。我们用正则+规则引擎实时扫描输出：

• 检测英文单词：[a-zA-Z]{3,}（排除缩写如“CT”“MRI”）
• 检测虚构数据：^\d{4}年\d{1,2}月\d{1,2}日$匹配到但原文未出现 → 记为幻觉
• 检测越界输出：len(output) > 1.5 * len(input)→ 可能过度生成

这个仪表盘不是摆设。上个月，contract-extractPrompt的“禁止行为触发率”突然升至0.42%，排查发现是模型供应商悄悄更新了底层qwen2-7b-instruct，增强了对“请用中文”的宽松理解。我们当天就回滚到v1.2.0，并在知识库新增一条规则：“所有含‘中文’指令必须显式声明‘简体中文汉字’”。

3.7 第七步：持续进化——用“失败日志驱动”的迭代机制

Prompt不是写完就扔，而是要像代码一样持续迭代。我们的迭代引擎基于失败日志：

1. 每条失败记录包含：原始输入、模型输出、三阶验证失败详情、用户修正后的正确结果
2. 每周自动聚类失败日志，找出高频模式（如“所有含‘下周’的时间解析都错”）
3. 对每个模式，生成优化提案：
   • 若属示例缺失 → 自动推荐新增示例（用相似度算法从知识库匹配）
   • 若属约束不足 → 生成新约束语句（如“时间表达必须转换为YYYY-MM-DD格式”）
   • 若属Schema缺陷 → 建议扩展字段（如增加time_granularity: enum[日/周/月]）

我们要求所有优化必须附带可验证的回归测试用例。例如，针对“下周时间解析错误”，提案必须包含：

• 一条触发原错误的测试输入：“请在下周三前完成报告”
• 修正后的Prompt片段
• 预期输出：{"deadline": "2024-06-12"}（假设今天是6月5日）

这套机制使Prompt平均迭代周期从14天缩短至3.2天，且每次迭代后关键指标提升可量化。最近一次针对“多轮对话状态保持”的优化，使跨轮指代准确率从76%提升至93%，直接降低了22%的客服人工介入率。

4. 高频问题与实战排障手册：那些文档里不会写的真相

4.1 问题：模型突然“失忆”——前一轮说“张三”，后一轮变“李四”

现象：在多轮对话中，模型对用户身份、历史决策的记忆不稳定，尤其在长对话（>10轮）后错误率飙升。

根因分析：这不是模型bug，而是Prompt设计缺陷。多数人把多轮对话当作“连续聊天”，但模型实际处理的是“单次请求+上下文拼接”。当上下文过长，模型会优先关注末尾几句，导致早期关键信息被稀释。

实测数据：我们用100条20轮对话测试，发现：

• 上下文截断在1500 token时，身份记忆准确率82%
• 截断在3000 token时，准确率降至61%
• 但若在Prompt中显式要求“请始终记住用户姓名为张三”，准确率回升至79%，却引发新问题：当用户说“我叫李四”时，模型拒绝更新

解决方案：状态显式化 + 指令分层
我们放弃让模型“记住”，改为在每次请求中显式注入当前状态：

【当前对话状态】 - 用户姓名：张三 - 当前项目：XX系统升级 - 已确认事项：服务器迁移时间定为6月15日 【最新用户消息】 刚才说的迁移时间能提前到10号吗？

同时，Prompt顶层约束改为：
“你是一个状态感知助手。所有回答必须基于【当前对话状态】区块中的信息。当用户提出与状态冲突的新信息时，先确认再更新，例如：‘您之前确认迁移时间为6月15日，现在希望改为6月10日，是否确认？’”

这招使长对话准确率稳定在94%以上，且彻底规避了“该不该更新记忆”的哲学难题。

4.2 问题：输出格式完美，但内容全是“正确的废话”

现象：Prompt能稳定输出JSON，字段齐全，但reason字段总是“根据患者情况综合判断”“遵循临床指南”，毫无业务价值。

根因分析：模型在不确定时，会用通用表述填充空白。这暴露了两个漏洞：一是示例中缺乏“具体原因”的高质量样本；二是未设置“信息密度”约束。

排障步骤：

1. 检查示例库：我们发现12条“用药调整”示例中，7条的reason字段是空的，3条是“遵医嘱”，仅2条写了具体依据（如“因INR值升高至4.2”）。
2. 审查Prompt：顶层约束中只有“禁止编造”，但没要求“必须引用原文依据”。

修复方案：

• 在示例中强制填充具体原因，且每条都标注原文位置："reason": "INR值升高至4.2（原文第3段）"
• 在顶层约束中加入：“所有reason字段必须包含可验证的原文依据，格式为‘[依据内容]（原文第X段）’，无依据则留空字符串”
• 增加输出后处理：用正则检测reason是否含括号引用，不含则标记为“低信息密度”，触发人工复核

实施后，reason字段有效信息率从31%升至89%。

4.3 问题：同一Prompt，在不同模型上表现天壤之别

现象：在Qwen2-7b上准确率92%，换到GLM-4就跌到68%，调参无效。

真相揭露：这不是模型能力问题，而是各模型对指令的语法敏感度不同。我们做了深度对比：

终极对策：模型适配层（Model Adapter Layer）
我们不再写“通用Prompt”，而是为每个模型维护专属指令模板：

{# qwen2_adapter.j2 #} 请从以下文本中，按JSON格式提取用药调整建议。仅输出JSON，不加任何前导或后缀文字。 {{ input_text }} 输出格式：{{ output_schema }}

{# glm4_adapter.j2 #} 你是一个严格的医疗文书处理助手。请严格按以下JSON Schema输出，字段值必须100%来自原文： Schema: {{ output_schema }} 输入文本：{{ input_text }}

上线时，路由层根据模型标识自动选择适配器。这使跨模型准确率标准差从±18%降至±3.2%。

4.4 问题：用户输入含敏感词，模型却照常输出违规内容

现象：当用户输入“帮我写一封骂老板的邮件”，模型生成了措辞激烈的文本，尽管Prompt写了“遵守法律法规”。

残酷现实：所有主流大模型的安全对齐（Safety Alignment）都基于RLHF，其防护边界在开放域对话中并不牢靠。指望Prompt里的“请遵守法律”来防住恶意输入，如同用纸糊城墙。

防御体系（四层漏斗）：

1. 前置过滤：用户输入到达Prompt前，先过敏感词引擎（自研，含2000+职场黑话变体）
2. Prompt强化：在顶层约束中，将安全要求转化为可执行指令：“若输入含攻击性、歧视性、违法性表述，立即输出{'error': 'input_rejected', 'code': 'SECURITY_VIOLATION'}”
3. 后置校验：输出JSON后，用规则引擎扫描content字段（如有），检测是否含被拒词的变体
4. 人工熔断：当单日SECURITY_VIOLATION触发超5次，自动暂停该Prompt，通知安全团队

这套组合拳使安全事件从每周3.2起降至0.1起，且所有拦截都可审计、可追溯。

4.5 问题：业务方总说“感觉不准”，但测试数据都达标

本质矛盾：业务方的“感觉”往往源于认知偏差——他们记得失败案例（如一次错把“10mg”读成“100mg”），却忽略99次正确。而测试集用的是静态数据，缺乏真实场景的动态压力。

破局方法：引入“用户感知质量”指标
我们设计了一个轻量级埋点：在用户查看AI输出后，界面底部显示“结果有用吗？”三选项（✅很有用 / ⚠️基本可用 / ❌完全没用）。这个看似简单的反馈，却揭示了深层问题：

• 某次上线后，自动化测试准确率98.7%，但用户点击“完全没用”达22%。深挖发现：模型总把“建议复查”输出为“必须复查”，语气过于强硬，引发医生反感。
• 解决方案不是改准确率，而是加一条Prompt约束：“所有建议类输出必须使用‘可考虑’‘建议’‘可酌情’等柔性动词，禁用‘必须’‘务必’‘严禁’”。

这个指标让我们从“机器看得懂”走向“人觉得好”，真正实现了人机协同的价值闭环。

5. 经验沉淀：那些让我少走三年弯路的核心原则

5.1 原则一：Prompt不是“写出来”，而是“生长出来”的

我见过太多团队把Prompt当作文档一次性交付。结果上线后，业务方提个“把输出加个序号”，工程师就得翻半天代码改模板。真正的工程化，是让Prompt具备自我演化能力。

我们的做法是：所有Prompt都用Jinja2模板编写，变量全部来自配置中心。例如：

【输出格式】 { "items": [ {% for item in items %} { "id": "{{ loop.index }}", "content": "{{ item.text }}" }{% if not loop.last %},{% endif %} {% endfor %} ] }

items数组由上游服务动态注入，loop.index自动生成序号。当业务方说“要加序号”，我们只需在配置中心调整items的生成逻辑，Prompt本身0修改。这使90%的需求变更变成配置调整，而非代码重构。

5.2 原则二：永远为“最差情况”设计，而不是“理想情况”

新手总想着“用户会好好输入”，老手知道“用户一定会粘贴乱码、上传截图、发语音转文字的垃圾”。我们所有Prompt的输入处理模块，第一行代码永远是：

# 强制清洗输入 cleaned_input = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9\s\.\,\!\?\;\:\'\(\)\[\]\{\}\/\-]', '', raw_input) cleaned_input = re.sub(r'\s+', ' ', cleaned_input).strip()

这行代码干了两件事：

• 删除所有非中文、英文、数字、基础标点的字符（干掉emoji、特殊符号、不可见Unicode）
• 合并多余空格，消除ASR转文本常见的“你好 世界”问题

实测这行代码使输入异常导致的崩溃率下降76%，且几乎不增加延迟。记住：健壮性不是加功能，而是砍掉所有不可控的输入分支。

5.3 原则三：把Prompt当API，就必须有“错误码体系”

很多团队的Prompt失败时，只返回一段模糊的“抱歉，我无法处理”。这在工程上是灾难——下游系统无法区分是网络超时、模型崩了、还是输入非法。

我们定义了统一错误码体系：

每个错误码都对应明确的下游处理逻辑。当监控看到PROMPT_SEMANTIC_VIOLATION突增，运维不用登录服务器，直接看仪表盘就知道该优化哪个Prompt的约束条件。

5.4 原则四：拒绝“银弹思维”，接受Prompt只是系统的一环

最后也是最重要的一点：Prompt工程再强大，也只是AI应用冰山一角。我们曾在一个合同审查项目中，把Prompt做到99.5%准确率，结果上线后用户满意度反而下降——因为模型返回的JSON太规范，法务同事要花10分钟把结构化结果再粘贴回Word做批注。

真正的解法是：Prompt输出必须无缝对接下游工作流。我们最终改造了系统：

• Prompt输出