---

1. 低效提问现场：一个“模糊需求”的血泪史

上周，我帮同事调试一段 Python 爬虫，想让它自动识别反爬策略。他直接把下面这句话丢给 ChatGPT：

“帮我写个能绕过反爬的脚本。”

结果返回了 300 行通用代码，混杂 Selenium、代理池、随机 UA，却完全没提到目标站点用的是 Cloudflare Turnstile。
问题拆解：

• 缺少“目标站点技术栈”上下文，模型只能泛化回答
• 缺少“可接受成本”边界，导致方案过度设计
• 缺少“输出格式”约束，代码风格与项目规范不符

一次请求烧掉 1 200 token，却只得到 20 % 可用内容——这就是典型的低效提问。

---

2. 提问范式对比：技术视角下的差异

范式	技术特征	适用场景	风险点
开放式	高自由度，temperature 0.7+	头脑风暴、需求探索	答案发散，token 浪费
封闭式	可枚举答案，temperature 0～0.3	布尔判断、单选结果	过度约束导致漏召回
单轮	上下文独立，message 只有 user/assistant 两轮	快速问答、脚本生成	无法追问，误差累积
多轮	system/user/assistant 交替，携带 history	复杂调试、渐进澄清	历史冗余，逼近 4 k/8 k 上限

实验数据：在“生成 SQL 优化建议”任务中，多轮比单轮平均减少 32 % 后续修正请求，但首 token 延迟增加 260 ms；封闭式提问 token 消耗降低 18 %，却牺牲 9 % 的覆盖率。

---

3. 三种可复用结构化模板

3.1 角色-任务-格式（RTF）模板

原理
通过 system 消息固化角色，压缩后续重复描述，降低 10 %～15 % token。

Python 示例

import openai, os

openai.api_key = os.getenv("OPENAI_API_KEY")

def sql_review(schema: str, query: str) -> str:
    try:
        rsp = openai.ChatCompletion.create(
            model="gpt-3.5-turbo",
            temperature=0.2,
            messages=[
                {"role": "system",
                 "content": "你是一名MySQL DBA，只返回JSON，包含字段：risk_level(高/中/低), suggestion, rewritten_sql"},
                {"role": "user",
                 "content": f"schema: {schema}\nSQL: {query}"}
            ],
            max_tokens=400
        )
        return rsp.choices[0].message.content
    except openai.error.OpenAIError as e:
        return f"API异常: {e}"

# 调用
print(sql_review("CREATE TABLE user(id INT PRIMARY KEY, email VARCHAR(100));",
                 "SELECT * FROM user WHERE email LIKE '%@gmail.com'"))

预期输出

{"risk_level": "高", "suggestion": "LIKE 前缀通配导致全表扫描", "rewritten_sql": "SELECT * FROM user WHERE email >= '@gmail.com' AND email < '@gmail.com\\xFF'"}

3.2 思维链（CoT）模板

原理
在 user 消息末尾追加“Let’s think step by step”，激活逐步推理，提高逻辑题准确率 40 % 以上。

Python 示例

def solve(word_problem: str) -> str:
    prompt = f"{word_problem}\nLet's think step by step."
    rsp = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        temperature=0.0,
        messages=[{"role": "user", "content": prompt}],
        stop=["\n\n"]  # 防止过度展开
    )
    return rsp.choices[0].message.content

预期输出
问题“100 人两两握手，共多少次” → 逐步列出组合公式 C(100,2) = 4950，减少跳步错误。

3.3 示例-反例（Few-shot + Neg-shot）模板

原理
在 user 消息中同时给出“期望示例”和“反例警告”，利用对比学习抑制幻觉。

Python 示例

def gen_commit_msg(diff: str) -> str:
    demo = """
[期望]
feat: add retry decorator to HTTP client

[反例]
fixed stuff
"""
    rsp = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        temperature=0.3,
        messages=[{"role": "user", "content": f"{demo}\n\n根据以下diff生成符合规范的commit message:\n{diff}"}]
    )
    return rsp.choices[0].message.content.strip()

预期输出
返回 50 字符内、带类型前缀的规范消息，反例风格被抑制。

---

4. 性能优化三板斧

4.1 Token 消耗估算

• 英文 1 token ≈ 4 字符，中文 1 token ≈ 2.5 汉字
• 用 tiktoken 库实时计数：

import tiktoken
enc = tiktoken.encoding_for_model("gpt-3.5-turbo")
count = len(enc.encode(prompt))

上线前预留 10 % 余量，避免触及长度上限导致截断。

4.2 响应延迟优化

1. 流式接口：设置 stream=True，首 token 提前 200～400 ms 返回
2. 降低 max_tokens，缩短模型生成长度
3. 本地缓存：对相同 prompt 做 SHA256 索引，TTL 5 min，命中率 25 % 时平均延迟下降 30 %

4.3 对话状态管理

• 滑动窗口：保留最近 3 轮 history，超过 2 k token 时丢弃最早一轮，减少总长度
• 摘要压缩：对 history 做 LLM 摘要，再注入 system，压缩率 60 %～70 %
• 状态外置：将会话快照存到 Redis，key 为 user_id:thread_id，实现跨设备续聊

---

5. 安全与可信

5.1 敏感信息过滤

正则脱敏 + 关键词库双重策略：

import re
def desensitize(text: str) -> str:
    text = re.sub(r"\b\d{15,16}\b", "[银行卡]", text)
    text = re.sub(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b", "[邮箱]", text)
    return text

请求前清洗，返回后同样对 assistant 内容再过滤，防止二次泄露。

5.2 结果可信度验证

• 事实核查：对数值、日期调用维基或企业知识图谱 API 交叉验证
• 置信度打分：让模型输出 <confidence>0.85</confidence>，低于 0.7 触发人工复核
• 多模型投票：同一问题发向 Claude 与 ChatGPT，结果不一致时降权或标记“待确认”

---

6. 实战挑战：设计你的业务 Prompt

场景
你负责一款跨境电商 ERP，需自动生成“商品描述+标题”，要求：

• 包含 3 个卖点、1 个场景句、SEO 关键词密度 2 %
• 禁止出现“最便宜”“第一”等广告法违禁词
• 输出 JSON，字段：title, description, keywords

任务

1. 基于本文模板，编写 system + user 消息
2. 用 Python 调用 OpenAI API，打印结果
3. 记录 token 消耗、首 token 延迟、违禁词检测结果
4. 将优化思路（如温度调整、Few-shot 数量）回复到评论区，与社区共享

---

7. 下一步：把对话能力搬进“实时语音”

当你掌握了文本 Prompt 的精细控制，不妨再往前一步：让 AI 直接“开口”。
我最近在 从0打造个人豆包实时通话AI 动手实验里，把同样严谨的 Prompt 工程套进了火山引擎豆包语音模型：

• 用 ASR 把用户语音转成文字 → 经过 RTF 模板润色 → 让 LLM 生成回答 → TTS 实时播报
• 整个链路延迟稳定在 600 ms 内，token 预算节省 20 %，而且支持自定义角色音色，相当于给 Prompt 加了“声音皮肤”。

实验提供了现成的 Web 脚手架，本地 npm run dev 即可跑起来。
如果你已熟悉 OpenAI 的调参套路，把相同思路迁移到豆包模型几乎零成本，还能体验低延迟对话的爽感。
Prompt 优化 + 实时语音，双buff 叠加，才算把 AI 交互做到极致。

---