1.1 手工调优时代的日常与武器库
1.1 手工调优时代的日常与武器库
本节摘要：还原提示词手工调优时代工程师的真实工作现场：三大武器（系统指令、少样本示例、思维链话术）如何组合使用，一次典型的调优会话如何展开，以及这套打法为什么能让早期产品跑起来、又在什么规模下开始吃力。本节在知识体系中的位置是"起点"——后面所有抽象都是为了替代本节描述的这些手工动作。
先看一段真实感十足的提示词，它来自某电商客服项目的系统提示，我们隐去业务细节后原样呈现：
你是「XX 商城」的客服助手。规则如下： 1. 只回答与订单、物流、售后相关的问题； 2. 用户情绪激动时，先道歉再处理； 3. 涉及退款，统一引导到"我的订单-申请退款"入口； 4. 不知道答案时说"这个问题需要人工客服为您确认"，禁止编造； 5. 不要讨论竞品； 6. 语气亲切，多用"亲"开头…… （后面还有 40 多行，第 7 到 47 条是历史事故里一条条补出来的补丁）
别以为这是反面教材——在那个年代，这份提示词算得上相当敬业的作品：它有明确的角色设定、有负向约束、有兜底话术，甚至能看到迭代沉淀的痕迹。问题不在写得好不好，而在这种"规则越补越多"的形态本身：每一条规则都是某次事故的遗迹，彼此之间没有任何一致性保证。第 47 条规则与第 3 条规则冲突吗？没人知道，因为没有机制能验证，只能等下一次事故来暴露。
武器之一：系统指令模板
系统指令是手工调优时代的骨干。工程师们很快总结出各种模板结构：角色-任务-约束-格式四段式、CRISPE 框架、Few-Shot 骨架等等。模板的价值确实存在——它给了新手一个起手式，让"写提示词"从空白页恐惧中解脱出来。但模板解决的是"从零到能看"，解决不了"从能看到可靠"。一个典型证据是：同一个模板，换了业务领域，效果波动极大；同一个业务，换了模型版本（比如底层模型从 3.5 升级到 4），原来调好的句式可能整体失效。模板传授的是"形"，而提示词的可靠性与"形"的关系远比想象中弱。
下面这段伪代码还原了当时很多团队的"提示词管理系统"——说是系统，其实就是字符串拼接：
# 手工调优时代的典型写法：提示词散落在业务代码各处 SYSTEM_PROMPT = "你是客服助手……（前面那段 47 条规则）" FEWSHOT = """ 问：我的快递到哪了？ 答：亲，请在"我的订单"页查看物流详情。 问：怎么开发票？ 答：亲，请前往"个人中心-发票管理"申请。 """ def build_prompt(user_input: str) -> str: return f"{SYSTEM_PROMPT}\n{FEWSHOT}\n用户问题：{user_input}\n助手回答：" # 改一次提示词 = 改一个巨型字符串常量 + 重新部署整个应用
三个致命特征已经埋在这段代码里：提示词与应用逻辑硬编码耦合，改一句话就要走完整发布流程；示例（FEWSHOT）的挑选全凭工程师手感，没有人能说清为什么是这两条而不是那两条；整个系统的"业务逻辑"其实活在一段自然语言里，任何静态分析、单元测试、代码评审手段对它统统失效。
武器之二：少样本示例
少样本（few-shot）示例是第二件武器，思路朴素：模型不会做，就给它看例子。它在分类、格式化、风格模仿类任务上立竿见影，一时间"攒示例"成了团队的核心资产积累活动。但少样本有个被普遍低估的软肋：示例的选择本身就是隐形的超参数。换一组示例，输出分布明显漂移；示例数量从两条加到五条，效果未必单调变好；示例里哪怕混进一条标注错误的，模型会忠实地把错误也学走。手工时代没有人系统回答"该放哪几条示例"，因为它本质是一个搜索问题，而手工调优者没有搜索引擎。
武器之三：思维链话术
思维链（Chain-of-Thought）是这套武器库里最接近"科学发现"的一件：在提示词里加一句"让我们一步一步思考"，多步推理类任务的准确率就有可观提升，而且模型越大提升越明显。它的流行有合理的机理——它把模型内部的中间计算显式化了，给了解码过程更多"落脚点"。但注意它的边界：思维链提升的是推理形态的任务，对纯知识问答、格式转换未必有效甚至有害（多出的思考段落反而稀释了答案质量）；而且"一步一步思考"这句话本身也要调——放在开头还是结尾、用"让我们"还是"请"，不同模型的最优写法不一样。一件武器是否灵验、怎么用才灵验，全部依赖当前这个具体模型的具体版本。
一次典型的调优会话
把三件武器放进真实的一天。背景：客服机器人把"发票丢失如何报销"的问句错误地引导到了物流查询。工程师的操作序列大致是：先复现问题（在测试框里输入几个变体问句）；然后猜测原因（可能是"发票"这个意图没有被示例覆盖）；接着动手（在 FEWSHOT 里加一条发票示例，同时在系统提示第 48 条追加"发票类问题引导到发票管理页"）；再测试原来的问句——通过了；最后顺手把之前测过的十几个问句再过一遍——发现"如何修改收货地址"的跳转被新示例带偏了，于是回去微调示例的措辞；如此往复两三个小时，凭记忆确认"好像都好了"，收工上线。
这个会话里藏着本教程后面全部主题的种子：那次"顺手把之前测过的问句再过一遍"就是评估体系在用户脑海中的原始形态——它本该是一套自动化回归集；那次"微调示例措辞"就是示范优化，本该由算法完成；那次"猜测原因"暴露的是提示词没有中间表示，出了问题既不能定位也不能调试。手工时代不是不努力，是努力没有沉淀为可累积的资产。
手艺的传承方式及其局限
武器库知识的传递方式也值得记一笔，因为它解释了为什么那个年代的团队水平差异如此之大。传承主要靠三种非正式渠道：师傅带徒弟式的口口相传（"这句要放在开头，模型更认"）、社区里的咒语交换帖（各种"万能提示词模板"满天飞）、以及事故复盘会（把踩过的坑变成团队的内部禁忌清单）。三种渠道的共同问题是传递的都是"具体写法"而非"判断依据"——新人学到了"这句要放开头"，却学不到"什么情况下放开头才有用"，于是换一个任务、换一个模型，学到的规则全部失效，又要从头再学一遍。
这种传承结构还造成一个组织现象：提示词能力成为个人资产而非团队资产。同一家公司里，A 团队的机器人对答如流，B 团队的机器人答非所问，差距完全取决于 A 团队里那位老师傅的积累。管理层看到的是"玄学"，工程师看到的是"没有沉淀机制的手工业"。DSPy 出现之后回头看，这个传承困局的本质是：提示词知识缺少一个可版本化、可复用、可组合的载体——它只能寄生在人的记忆和聊天记录里。一个领域什么时候开始拥有自己的"载具"，什么时候才算成为工程学科；提示词的载具，直到编译范式出现才补上。
本节要点回顾
- 武器库三件套：系统指令模板给结构、少样本示例给模仿对象、思维链话术给推理脚手架；三件都有效，但全都依赖手感与具体模型版本。
- 提示词即隐式程序：规则互相耦合、没有中间表示，任何修改的副作用无法静态推演，只能靠测试暴露。
- 示例是隐形超参数：选择哪几条少样本示例，本质上是一个没有搜索引擎支撑的搜索问题。
- 调优成果不可累积：每一次事故的修复都以"追加补丁"的形式存在，知识长在个人记忆和巨型字符串里。
- 过渡到下一节：这些日常痛点并非孤立的操作问题，而是可以被归纳为四道结构性的天花板——那是 1.2 节的任务。