前端转 AI 100 天 Day 36：Prompt 工程入门——从“感觉对了就行”到方法论

前端转 AI 第 36 天：Prompt 工程入门 - 从"感觉对了就行"到方法论

昨日回顾

Day 35 上了结构化输出，让 LLM 稳定返回 JSON。

但输出的"内容质量"还是玄学------问同样的问题，改几个字就效果天差地别。

今天进入 Prompt 工程------把"写提示词"从玄学变成方法论。

Day 36 目标：搞懂 Prompt 的组成、写法和常见反模式，能写出稳定可复用的 Prompt。

一、Prompt 不只是"提问"

1. 新手的第一反应

"Prompt？不就是问问题吗？"

python 复制代码

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "帮我写个 Python 快速排序"}],
)

能跑，但能写出来的质量看运气。

2. 老手是怎么写的

同样的需求：

python 复制代码

messages = [
    {
        "role": "system",
        "content": """你是一个资深 Python 工程师，擅长算法教学。

写代码时：
- 用类型注解
- 加 docstring
- 处理边界情况（空列表、单元素、重复值）
- 在关键步骤加注释解释思路
- 最后给一个使用示例

不要解释基础概念，假设读者有 Python 基础。""",
    },
    {
        "role": "user",
        "content": """写一个快速排序，要求：
- 输入：list[int]
- 输出：排好序的 list[int]
- 原地排序
- 时间复杂度说明""",
    },
]

区别：

维度	新手	老手
角色	没说	"资深 Python 工程师"
约束	无	类型注解、docstring、边界处理
范围	泛	"假设读者有基础"
输出	随便	有示例、有复杂度说明

结果：好 3-5 倍。

3. Prompt 的四个组成部分

一个完整的 Prompt 通常包含：

复制代码

┌─────────────────────────────────────┐
│ 1. 角色设定（Role）                  │
│    你是一个 xxx                       │
├─────────────────────────────────────┤
│ 2. 任务描述（Task）                  │
│    用户要做什么                       │
├─────────────────────────────────────┤
│ 3. 约束条件（Constraints）           │
│    输出格式、长度、风格、禁忌         │
├─────────────────────────────────────┤
│ 4. 示例（Examples）                  │
│    给 1-3 个样本，模型照着做          │
└─────────────────────────────────────┘

这四块不是必须全有------根据任务复杂度选用。

但记住这个结构，写 Prompt 就不会漏关键信息。

4. 前端视角：Prompt 就是"组件 Props 文档"

做过前端的你会觉得很熟悉：

jsx 复制代码

/**
 * 用户卡片组件
 * 
 * @param {string} name - 用户名，必填
 * @param {number} age - 年龄，必填
 * @param {string} [avatar] - 头像 URL，可选
 * @param {'small'|'medium'|'large'} [size='medium'] - 尺寸
 */
function UserCard({ name, age, avatar, size = "medium" }) {
  ...
}

Prompt 就是"给 AI 看的 Props 文档"：

复制代码

你是一个 xxx（组件名）
用户会给你 xxx（输入 Props）
请返回 xxx（输出格式）
注意 xxx（约束）
例如 xxx（示例）

你在前端养成的"写清楚接口文档"的习惯，就是 Prompt 工程的基础。

二、System Prompt：真正的大杀器

1. System 和 User 的区别

三种角色：

角色	用途	优先级
system	设定 AI 的身份、行为准则	最高
user	用户输入	中
assistant	AI 的历史回复	中

关键认知：

System prompt 是"准则"，User message 是"具体问题"。

准则管"怎么做"，问题管"做什么"。

这就是为什么改 System 比改 User 效果差 10 倍。

2. 一个对比实验

场景：让 AI 审代码。

只用 User：

python 复制代码

messages = [
    {"role": "user", "content": "帮我看看这段代码有没有问题：\n\n" + code}
]

结果： 会给你泛泛的评价，可能漏掉关键 bug。

用 System：

python 复制代码

messages = [
    {
        "role": "system",
        "content": """你是一个严格的代码审查员（Senior Code Reviewer）。

审查代码时，按以下清单逐项检查：
1. 正确性：逻辑是否正确？边界条件是否处理？
2. 安全性：是否有注入、越权、数据泄漏风险？
3. 性能：是否有 N+1、不必要的循环、内存泄漏？
4. 可维护性：命名是否清晰？是否有重复代码？
5. 错误处理：异常是否被正确捕获和上报？

输出格式：
## 严重问题
- [行号] 问题描述 + 修复建议

## 一般问题
- [行号] 问题描述

## 建议
- 改进点

如果某项没有问题，跳过该项。不要写"看起来不错"这种废话。""",
    },
    {"role": "user", "content": code},
]

结果： 结构化、抓关键、可执行。

差别巨大------System prompt 定了"审查"的方法论。

3. System Prompt 的核心要素

好的 System prompt 包括：

要素	作用	示例
身份	让 AI 进入角色	"你是一个资深 Python 工程师"
能力边界	说明能做什么	"你只能回答编程问题"
行为规则	怎么做	"回答前先思考，再给结论"
输出格式	输出长什么样	"用 Markdown，带代码块"
禁止事项	不能做什么	"不要编造 API 名称"
示例	展示期望	"例如：..."

不是每个 Prompt 都要全写。 简单任务 2-3 条就够，复杂任务才写全。

4. System Prompt 也能"注入"

有个高级技巧：动态生成 System prompt。

python 复制代码

def build_system_prompt(user_profile: dict, context: dict) -> str:
    """根据上下文动态构建 System prompt"""
    parts = ["你是一个友好的 AI 助手。"]

    # 用户偏好
    if user_profile.get("language"):
        parts.append(f"请用 {user_profile['language']} 回答。")
    if user_profile.get("tone") == "concise":
        parts.append("回答要简洁，不超过 3 句话。")

    # 场景
    if context.get("scene") == "code_review":
        parts.append("当前场景：代码审查，请严格检查。")

    # 时间
    parts.append(f"当前时间：{datetime.now().strftime('%Y-%m-%d')}")

    return "\n".join(parts)

每次调用前根据上下文组装。

这就是"个性化"的实现方式------不同用户、不同场景，Prompt 不同。

三、写 Prompt 的 6 条原则

不吹"心法"，直接给可操作的规则。

原则 1：指令要"具体、明确、有边界"

❌ 差的写法：

复制代码

帮我写个总结。

✅ 好的写法：

复制代码

请总结以下文章，要求：
- 字数 100-150 字
- 保留所有具体数字和人名
- 用"总-分"结构：先一句话概括，再 2-3 个要点
- 不要加入文章没有的观点

原则： 把"你想的"变成"能写下来的"------你能写下来，模型才能执行。

原则 2：给例子（Few-shot）

最有效的技巧之一：给 1-3 个例子。

零样本（Zero-shot）：

复制代码

把下面的句子改写成"正式"风格：
"这玩意儿太难用了"

少样本（Few-shot）：

复制代码

把下面的句子改写成"正式"风格。

示例：
输入：这东西真香
输出：该产品体验良好

输入：别整那些花里胡哨的
输出：建议采用简洁方案

输入：这玩意儿太难用了
输出：

示例的威力：

方式	效果
光描述	80%
描述 + 1 例	90%
描述 + 3 例	95%+

经验：

1-3 个例子最合适：太少不够，太多浪费 token
例子要有代表性：覆盖不同情况
例子要正确：错的例子会让模型学错

原则 3：把输出格式说清楚

模型能理解各种格式描述：

Markdown：

复制代码

输出为 Markdown，用 ## 标题、列表、代码块。

JSON：

复制代码

输出为 JSON，字段：name (string), age (int)。
（或直接用 Day 35 的结构化输出）

特定模板：

复制代码

按以下格式输出：
- 概述：[一句话]
- 优点：[3 条]
- 缺点：[3 条]
- 结论：[一句话]

越具体越好。

原则 4：把步骤拆开（Chain-of-Thought）

复杂任务要"分步执行"。

❌ 一口气：

复制代码

分析这篇文章的情感倾向，并给出理由。

✅ 分步：

复制代码

按以下步骤处理：

步骤 1：识别文章中的关键观点（列出 3-5 条）
步骤 2：判断每条观点的情感极性（正面/负面/中性）
步骤 3：综合所有观点，给出总体情感倾向
步骤 4：用一句话总结理由

输出格式：
【关键观点】
- ...

【极性分析】
- ...

【总体倾向】
...

分步的好处：

每一步更简单：模型不容易出错
结果可追溯：能看到模型怎么想的
问题可定位：哪一步错了改哪一步

原理： 这叫 Chain-of-Thought（CoT）------让模型"先思考再回答"，类似前端调试时的"打个断点看看"。

原则 5：告诉模型"不要做什么"

模型有很多"默认习惯"，你要主动约束。

常见"不要"：

复制代码

不要解释基础概念。
不要重复问题。
不要用"好的"、"当然"开头。
不要编造不存在的 API。
不要给"仅供参考"这种废话。

更狠的：

复制代码

如果信息不足，直接说"信息不足，无法判断"，不要猜测。

这一条能极大减少"AI 幻觉"。

原则 6：把"角色"用足

不同角色会产生不同的输出风格。

同一个问题："解释一下什么是闭包"

角色：老师

复制代码

闭包就像一个小背包，函数走到哪都带着它的"出生环境"...

角色：面试官

复制代码

闭包是 JS 中的一个核心概念，考察点包括：
1. 定义（必答）
2. 使用场景（至少 2 个）
3. 内存泄漏风险（加分项）

角色：资深工程师

复制代码

闭包（Closure）= 函数 + 它的词法环境。
关键点：
- 内部函数引用外部变量
- 外部函数返回后，变量不会被回收
- 典型场景：回调、防抖节流、模块化

同一个模型，换个角色，效果差很多。

选角色要和"目标读者"匹配。

四、Prompt 反模式

这些坑，新手天天踩。

反模式 1：模糊指令

❌ 差的写法：

复制代码

帮我优化一下这个代码。

模型：

"优化"啥？性能？可读性？安全？

✅ 好的写法：

复制代码

优化以下代码，重点：
1. 减少重复（提取公共函数）
2. 性能优化（避免 N+1）
3. 保留现有行为不变

不要修改函数签名和返回值。

反模式 2：一次给太多任务

❌ 差的写法：

复制代码

帮我写一个用户管理系统，要支持：
注册、登录、权限、订单、支付、退款、客服、报表...

模型： 每个都敷衍一点，都不深入。

✅ 好的写法：

拆开：

复制代码

第一个 Prompt：设计数据模型
第二个 Prompt：实现注册登录
第三个 Prompt：实现权限控制
...

一次做一件事，每次都能得到高质量输出。

反模式 3：负向指令

❌ 差的写法：

复制代码

不要写得太长，不要太复杂，不要有 bug。

模型： 容易忽略"不要"，反而做了。

✅ 好的写法：

复制代码

控制在 200 字以内。
用简单句子，避免专业术语。
注意边界情况（空值、异常）。

原则： 说"要什么"，比说"不要什么"有效。

反模式 4：Prompt 太长

❌ 差的写法：

把 5000 字的背景文档塞进 prompt。

问题：

占 token：贵
噪声大：模型注意力被稀释
变慢：响应慢

✅ 好的写法：

给摘要，不给全文
给相关片段，不给全部
用 RAG（Day 46 讲）按需检索

Prompt 不是越长越好，是越"精准"越好。

反模式 5：不说清楚输出格式

❌ 差的写法：

复制代码

总结一下这个新闻。

结果可能是：

一段话（100 字）
一篇分析（1000 字）
带标题的总结
带 bullet point 的

✅ 好的写法：

复制代码

用以下格式总结：
- 标题：不超过 15 字
- 摘要：一段 100 字以内的总结
- 关键点：3-5 个 bullet
- 情绪倾向：正面/中性/负面

反模式 6：在 User 里放"系统指令"

❌ 差的写法：

python 复制代码

messages = [
    {"role": "user", "content": "你是一个资深 Python 工程师，请帮我..."}
]

问题：

容易被忽略：User 消息优先级低
多轮对话后失效：后续 user 消息会覆盖
无法复用：每次都写一遍

✅ 好的写法：

python 复制代码

messages = [
    {"role": "system", "content": "你是一个资深 Python 工程师"},
    {"role": "user", "content": "请帮我..."},
]

永远用 System 放"准则"。

五、实战：一套完整的 Prompt 模板

把上面的原则落成一个可复用的模板。

1. 模板结构

创建 day36/prompt_template.py：

python 复制代码

"""Prompt 模板"""
from dataclasses import dataclass, field


@dataclass
class PromptTemplate:
    """一个可复用的 Prompt 模板"""

    role: str = "你是一个友好的 AI 助手"
    task: str = ""
    constraints: list[str] = field(default_factory=list)
    output_format: str = ""
    examples: list[dict] = field(default_factory=list)
    forbidden: list[str] = field(default_factory=list)

    def build_system(self) -> str:
        """构建 System prompt"""
        parts = [self.role]

        if self.constraints:
            parts.append("\n约束条件：")
            for c in self.constraints:
                parts.append(f"- {c}")

        if self.output_format:
            parts.append(f"\n输出格式：\n{self.output_format}")

        if self.forbidden:
            parts.append("\n禁止事项：")
            for f in self.forbidden:
                parts.append(f"- {f}")

        if self.examples:
            parts.append("\n示例：")
            for i, ex in enumerate(self.examples, 1):
                parts.append(f"\n【示例 {i}】")
                parts.append(f"输入：{ex.get('input', '')}")
                parts.append(f"输出：{ex.get('output', '')}")

        return "\n".join(parts)

    def build_messages(self, user_input: str) -> list[dict]:
        """构建完整的 messages"""
        return [
            {"role": "system", "content": self.build_system()},
            {"role": "user", "content": user_input},
        ]

2. 用它写一个"邮件助手"

python 复制代码

"""邮件助手 Prompt"""
from prompt_template import PromptTemplate


EMAIL_ASSISTANT = PromptTemplate(
    role="你是一个专业的商务邮件助手，帮助用户撰写、优化和回复邮件。",

    constraints=[
        "根据用户提供的语境调整语气（正式/友好/紧急）",
        "邮件结构要清晰：称呼、正文、结尾",
        "正文控制在 3 段以内",
        "用中文回答；如用户要求英文，则用英文",
    ],

    output_format="""请按以下格式输出：

【主题】xxx

【正文】
xxx

【语气】正式/友好/紧急""",

    examples=[
        {
            "input": "给张三写封邮件，明天上午 10 点的会议推迟到下午 2 点",
            "output": """【主题】关于明天会议时间调整

【正文】
张三你好：

由于临时安排冲突，原定于明天上午 10 点的会议需要调整到下午 2 点，地点不变。给你带来的不便敬请谅解。

如有问题请随时联系。

祝好
【你的名字】

【语气】正式""",
        },
    ],

    forbidden=[
        "不要编造会议地点或参会人员",
        "不要添加'希望您收到这封邮件时一切顺利'这种模板开头",
    ],
)

3. 使用

python 复制代码

"""使用邮件助手"""
import os
from openai import OpenAI
from prompt_template import PromptTemplate
from email_assistant import EMAIL_ASSISTANT


client = OpenAI(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com/v1",
)


def write_email(user_request: str) -> str:
    messages = EMAIL_ASSISTANT.build_messages(user_request)
    response = client.chat.completions.create(
        model="deepseek-chat",
        messages=messages,
        temperature=0.7,
    )
    return response.choices[0].message.content


if __name__ == "__main__":
    # 测试 1
    print(write_email("给张三写封邮件，明天上午 10 点的会议推迟到下午 2 点"))
    print("=" * 60)

    # 测试 2
    print(write_email("给团队写封邮件，本周五团建，地点在公司楼下咖啡厅"))

输出（测试 2）：

复制代码

【主题】关于本周五团建的通知

【正文】
各位同事：

本周五我们将组织一次团队活动，地点定在公司楼下的咖啡厅，时间待通知。
希望大家提前安排，届时参加。

祝好
【你的名字】

【语气】友好

格式稳定、质量可控。

4. 模板的价值

好处：

维度	手写 prompt	模板
一致性	每次不同	同一模板
可维护	分散各处	集中管理
可复用	复制粘贴	import 使用
版本管理	无	git 追踪
可测试	难	便于单测

这就是"Prompt 工程"从"手工艺"到"工业化"的关键一步。

六、给 Agent 的 Prompt 设计

Agent 场景的 Prompt 更复杂------因为多轮对话 + 工具调用。

1. Agent System Prompt 要素

一个 Agent 的 System prompt 通常包括：

复制代码

1. 身份与能力：你是什么，能做什么
2. 工具说明：有哪些工具，怎么用（工具 Schema 会单独传）
3. 行为准则：什么时候用工具，什么时候不用
4. 输出格式：回复怎么组织
5. 兜底策略：信息不足、无法处理时怎么办

2. 实战模板

src/ai_assistant/prompts/agent.py：

python 复制代码

"""Agent 的 System Prompt"""

AGENT_SYSTEM_PROMPT = """你是一个智能助手，可以调用工具来帮助用户完成任务。

## 行为准则

1. **优先直接回答**：如果问题不需要工具，直接回答，不要调用工具。
2. **需要实时信息时必须用工具**：涉及天气、时间、新闻、价格等，必须调用工具。
3. **一次只做一件事**：如果用户要求多步，先完成第一步，再根据结果决定下一步。
4. **工具失败时不要编造**：如果工具返回错误，如实告知用户，而不是瞎编答案。
5. **信息不足时主动询问**：比如要订票但没给日期，先问清楚。

## 输出要求

- 用中文回答
- 简洁明了，不要啰嗦
- 涉及数据时，引用工具返回的具体数字
- 不要暴露工具的内部细节（比如不要写"我调用了 get_weather 函数"）
"""


def build_agent_system_prompt(
    user_name: str | None = None,
    context: dict | None = None,
) -> str:
    """动态构建 Agent System Prompt"""
    parts = [AGENT_SYSTEM_PROMPT]

    if user_name:
        parts.append(f"\n用户的名字是 {user_name}，可以称呼他/她的名字。")

    if context:
        if context.get("timezone"):
            parts.append(f"当前时区：{context['timezone']}")
        if context.get("language"):
            parts.append(f"请用 {context['language']} 回答。")

    return "\n".join(parts)

3. 关键设计思想

1. 明确"边界"

"不要编造" 这条对 Agent 极其重要。没有它，模型会瞎编工具结果。

2. 说明"何时用工具"

"涉及实时信息时必须用工具"------告诉模型判断标准。

否则可能出现：

该用时不用：问天气直接编
不该用时用：问常识也去搜

3. 多步任务的策略

"先完成第一步，再根据结果决定下一步"------引导模型按顺序思考，而不是一次规划全部。

这正是 ReAct 模式的雏形（Day 62 讲）。

4. 不暴露工具细节

"不要写'我调用了 get_weather 函数'"------用户不关心你怎么实现的。

只说结果。

4. Prompt 版本管理

Prompt 是代码，要版本管理。

src/ai_assistant/prompts/__init__.py：

python 复制代码

"""Prompt 版本管理"""

AGENT_SYSTEM_PROMPT_V1 = """..."""

# 当前使用的版本
CURRENT_AGENT_PROMPT = AGENT_SYSTEM_PROMPT_V2 = """..."""

改进 Prompt 时：

新增一个版本 （V2）
写测试对比新旧效果
确认改进后切换 CURRENT
保留旧版本便于回滚

把 Prompt 当代码管理------这是从"玩具 Agent"到"生产 Agent"的必要习惯。

七、评估 Prompt 效果

Prompt 改进了，怎么知道真的更好？

答案：写测试。

1. 简单评估框架

创建 day36/eval_prompt.py：

python 复制代码

"""Prompt 评估框架"""
import json
from dataclasses import dataclass
from typing import Callable


@dataclass
class TestCase:
    """一个测试用例"""
    input: str
    expected_contains: list[str]      # 必须包含的关键词
    expected_not_contains: list[str]  # 不能出现的关键词
    max_length: int | None = None


def evaluate_prompt(
    prompt_func: Callable[[str], str],
    test_cases: list[TestCase],
) -> dict:
    """评估 Prompt 效果"""
    results = []
    passed = 0

    for i, case in enumerate(test_cases, 1):
        output = prompt_func(case.input)

        # 检查必须包含
        contains_ok = all(kw in output for kw in case.expected_contains)

        # 检查不能出现
        not_contains_ok = all(
            kw not in output for kw in case.expected_not_contains
        )

        # 检查长度
        length_ok = (
            case.max_length is None
            or len(output) <= case.max_length
        )

        ok = contains_ok and not_contains_ok and length_ok

        results.append({
            "case": i,
            "input": case.input[:50],
            "passed": ok,
            "contains_ok": contains_ok,
            "not_contains_ok": not_contains_ok,
            "length_ok": length_ok,
            "output_preview": output[:100],
        })

        if ok:
            passed += 1

    return {
        "total": len(test_cases),
        "passed": passed,
        "pass_rate": passed / len(test_cases) if test_cases else 0,
        "details": results,
    }

2. 用它测"邮件助手"

python 复制代码

"""评估邮件助手 Prompt"""
from eval_prompt import TestCase, evaluate_prompt
from write_email import write_email


TEST_CASES = [
    TestCase(
        input="给张三写封邮件，明天会议推迟",
        expected_contains=["【主题】", "【正文】", "【语气】"],
        expected_not_contains=["好的", "当然", "希望您收到"],
    ),
    TestCase(
        input="给团队发通知，周五团建",
        expected_contains=["【主题】", "周五"],
        expected_not_contains=["我调用了", "AI 助手"],
    ),
    TestCase(
        input="回复李四的询价邮件，价格 100 元",
        expected_contains=["100"],
        expected_not_contains=["不确定", "可能"],
        max_length=500,
    ),
]


if __name__ == "__main__":
    result = evaluate_prompt(write_email, TEST_CASES)
    print(f"通过率: {result['passed']}/{result['total']} = {result['pass_rate']:.1%}")
    print()

    for d in result["details"]:
        status = "✅" if d["passed"] else "❌"
        print(f"{status} Case {d['case']}: {d['input']}")
        if not d["passed"]:
            print(f"  contains_ok: {d['contains_ok']}")
            print(f"  not_contains_ok: {d['not_contains_ok']}")
            print(f"  output: {d['output_preview']}")

运行：

复制代码

通过率: 3/3 = 100.0%

✅ Case 1: 给张三写封邮件，明天会议推迟
✅ Case 2: 给团队发通知，周五团建
✅ Case 3: 回复李四的询价邮件，价格 100 元

这就是"Prompt 工程"的工业化做法------不是靠感觉，靠数据。

3. 进阶：A/B 测试两个版本

python 复制代码

def compare_prompts(prompt_a, prompt_b, test_cases):
    """对比两个 Prompt 版本"""
    result_a = evaluate_prompt(prompt_a, test_cases)
    result_b = evaluate_prompt(prompt_b, test_cases)

    print(f"A 版通过率: {result_a['pass_rate']:.1%}")
    print(f"B 版通过率: {result_b['pass_rate']:.1%}")

    if result_a["pass_rate"] > result_b["pass_rate"]:
        print("→ A 版更好")
    elif result_b["pass_rate"] > result_a["pass_rate"]:
        print("→ B 版更好")
    else:
        print("→ 两版持平")

    return result_a, result_b

改 Prompt 前跑一次，改完再跑一次，对比数据。

这才是"Prompt 工程"，不是"Prompt 玄学"。

八、前端视角：Prompt 是"组件的说明书"

把 Prompt 想象成一个"复杂组件的说明书"：

组件文档	Prompt
组件名	角色设定
Props	输入格式
输出说明	输出格式
使用示例	Few-shot 示例
注意事项	约束条件
不允许的场景	禁止事项
边界情况	"信息不足时怎么办"

写组件文档时你会想：

用户会怎么用？
什么输入是合法的？
边界情况怎么处理？
出错怎么办？

写 Prompt 时也一样想。

核心心法：

Prompt 不是"你问 AI 什么"，而是"你给 AI 写了一份说明文档"。

文档写得好，AI 表现就好。文档模糊，AI 就"自作主张"。

你前端写文档、写类型、写注释的能力，就是 Prompt 工程的底子。

九、今日踩坑

System Prompt 太长 → 模型注意力被稀释，关键指令可能漏掉
示例给太多 → token 消耗大，效果提升边际递减
示例本身有错 → 模型会学着犯错
否定指令太多 → 模型容易忽略"不要"，改成正面表述
在 User 里放系统指令 → 被后续消息覆盖，要用 System
Prompt 里变量没转义 → 用户输入含 {} 可能干扰模板渲染
忘了说输出语言 → 中文输入可能返回英文
没说"信息不足怎么办" → 模型会编造
一次要求太多 → 拆成多次调用效果更好
Prompt 没版本管理 → 改坏了找不到旧版回滚
没写测试就改 Prompt → 改了不知道好坏
Few-shot 示例和实际输入差太远 → 模型照搬示例，不灵活
忽略 temperature → 该确定的场景用了高温度，输出不稳定
Prompt 太礼貌 → "麻烦你"、"如果可以的话"会被模型当成可选
Prompt 里的"你/我"指代不清 → 谁是"你"，谁是"我"，明确写

十、今日总结

今天核心收获三件事：

Prompt 四要素 ：角色 + 任务 + 约束 + 示例，不是随便问一句
System Prompt 是大杀器：放"准则"而不是"具体问题"，一次写好处处用
Prompt 是可测试的工程产物：给测试用例、A/B 对比、版本管理

一个感受：

Prompt 工程最反直觉的一点：

写得越详细，效果反而越好。

新手总觉得"AI 应该能懂我的意思"，结果给一个模糊的 prompt，得到一个模糊的答案。

老手知道："AI 不会读心术，你必须把要求说清楚。"

这和带新人一模一样。

带新人：写清楚的文档、给示例、说明边界

写 Prompt：写清楚的角色、给示例、说明约束

你带过新人，你就会写 Prompt。

从今天起，你的 Prompt 不再是"问问题"，而是"写文档"。

这是"AI 用户"和"AI 开发者"的分界线。

Day 36 完成度：✅

明日预告（Day 37）

Few-shot 和 CoT 实战 ：
- Few-shot 的最佳实践
- Chain-of-Thought 的威力
- Zero-shot CoT（"让我们一步步思考"）
- Self-Consistency（多次采样投票）
- ReAct 模式入门（Reasoning + Acting）
让模型从"能回答"到"能推理"

最后

如果这篇对你有用，点个赞让我知道有人在看。

评论区互动： 你写过最得意的 Prompt 是干什么用的？踩过什么坑？欢迎分享。

有问题评论区见，我们第 37 天继续。

100 天，第 37 天见。

附录：系列目录

第一阶段（已完成 ✅）

阶段	天数	内容
Python 基础	01-15	语法 + 命令行助手
后端工程化	16-30	数据库/测试/FastAPI/Docker/上线

第二阶段：大模型应用（进行中 🎯）

天数	内容
31-35	LLM 入门 + 工程化 + 结构化输出 ✅
36	Prompt 工程入门 ✅
37-40	Few-shot / CoT / 多模型 / 成本优化
41-45	本地模型 + 阶段复盘

第三阶段：RAG（Day 46-60）

第四阶段：Agent（Day 61-80）

第五阶段：完整项目（Day 81-100）

36 天已过，64 天继续。

一起从切图仔变成 Agent 开发者。