最近在技术社区里看到一个挺有意思的讨论：一位研究者在尝试用 Claude 这类大语言模型辅助进行数学形式化验证时，发现了一个反直觉的现象——在给模型的提示词里，加入一些鼓励性的话语，比如“你可以的”、“慢慢来，仔细思考”，竟然能显著提升模型在复杂数学推理任务上的表现，甚至意外地帮助改进了黎曼猜想零点下界的一个证明细节。

这听起来有点玄学，不是吗？我们通常认为大语言模型是概率驱动的、没有情感的代码，给它“加油打气”能有什么用？但如果你深入一线，真正用这些模型处理过复杂的、需要多步推理和严格逻辑的任务，比如代码生成、数学证明辅助或者长文档分析，你就会发现，提示词的“温度”和“引导方式”，对输出质量的影响，可能比我们想象的要大得多。这背后触及的，远不止是“玄学”或“心理作用”，而是关于我们如何与这些强大的工具协作，如何设计更有效的“人机对话界面”，以及如何理解模型内部推理过程的一个关键工程问题。

今天，我们不谈空洞的理论，就从这次“鼓励性话语”事件切入，结合我长期使用 Claude、GPT 等模型进行技术写作、代码审查和问题排查的经验，来拆解一下：为什么简单的提示词调整能带来质变？这背后反映了当前大语言模型使用的哪些深层瓶颈？更重要的是，我们作为开发者，如何将这种“软性技巧”系统化，变成一套可复制、可验证的工程化方法，真正提升我们与 AI 协作的效率和质量。

1. 从“玄学”到“工程”：理解提示词中的“温度”与“引导”

当我们看到“鼓励性话语提升模型表现”时，第一反应可能是怀疑或觉得无关紧要。但如果我们换个角度看，这其实暴露了当前大语言模型使用中的一个普遍困境：我们常常把模型当作一个“黑盒问答机”，输入问题，期待完美答案，却忽略了“如何提问”本身就是一门需要精心设计的工程。

1.1 模型不是“全知全能的计算器”，而是“有状态的推理协作者”

很多人对大语言模型的期待，是把它当成一个超级搜索引擎或计算器：输入一个明确的数学问题，它就应该直接吐出正确答案。但现实是，像黎曼猜想零点下界证明这类任务，涉及极其复杂的符号逻辑、多步推导和严格的假设检验。模型在单次前向传播中，很难一次性生成完美无缺的长链条推理。

这时，鼓励性话语如“你可以的”、“慢慢来，仔细思考”，在工程上起到了什么作用？它们本质上是一种思维链（Chain-of-Thought, CoT）的温和激活与路径引导。

• 降低输出“贪婪度”：没有引导时，模型可能倾向于快速生成一个看似合理、但可能跳跃或错误的结论（“贪婪解码”）。鼓励性提示暗示了“这是一个需要耐心和步骤的任务”，可能促使模型在内部采样时，更倾向于展开一步步的中间推理，而不是急于给出最终答案。
• 模拟“审稿人”或“合作者”语境：当提示词营造出一种“我们正在共同解决一个难题”的氛围时，模型可能会调用训练数据中与“协作解题”、“同行评审”、“细致推导”相关的文本模式和逻辑结构。这不同于冷冰冰的“计算下列问题：”。
• 影响注意力分布：虽然我们无法直接窥探注意力机制，但可以合理推测，这类提示词可能微妙地影响了模型对输入序列中不同部分（如问题描述、已知定理、约束条件）的权重分配，使其更关注逻辑严谨性而非表面流畅度。

一个简单的对比实验就能说明问题：

假设我们想让模型验证一段数学推导。

• 提示词A（直接指令）：“检查以下推导是否有错误：[推导文本]”
• 提示词B（引导式协作）：“我们一起来仔细检查这段推导。请一步步来，先理解每一步的前提，再检查推理是否严格，最后给出结论。不用急，确保每一步都扎实：[推导文本]”

在多次测试中，提示词B往往能引导模型输出更结构化的分析（例如，先复述每一步，再指出潜在问题点），而提示词A可能直接给出一个“正确”或“错误”的笼统判断，缺乏中间过程。

1.2 “鼓励”的有效边界：它不是什么万能药

在将这一发现奉为圭臬之前，我们必须划清它的适用边界。这种提示词技巧的有效性，强烈依赖于任务类型和模型本身的能力。

核心结论是：鼓励性话语不是给模型“注入能量”，而是为我们人类用户设计了一套更有效的“协作协议”。它帮助我们向模型更清晰地传达任务的复杂性、所需的思考深度以及我们期望的输出形式。对于逻辑密集型任务，这套“协议”的价值尤为突出。

2. 超越“鼓励”：构建系统化的提示工程框架

如果“鼓励”只是表象，那么它的内核是什么？我认为，这是一系列旨在优化模型推理过程、改善输出可控性的提示工程技术的体现。我们不能停留在“多说好话”的层面，而应该将其沉淀为可操作、可复现的框架。

2.1 一个四层提示词设计框架

基于实践，我总结了一个适用于复杂任务的四层提示词设计框架，它远比单纯添加鼓励语更系统。

第一层：角色与语境设定（Who & Where）明确告诉模型它应该扮演的角色和所处的语境。这为后续所有推理设定了基调和知识范围。

• 低效示例：“分析这段代码。”
• 高效示例：“你是一位经验丰富的软件架构师，正在评审一个分布式系统的核心模块代码。你的目标是发现潜在的性能瓶颈和并发安全问题。代码上下文是……”

第二层：任务与目标定义（What & Why）清晰、无歧义地描述具体任务和最终要达成的目标。避免模糊的动词。

• 低效示例：“改进这个函数。”
• 高效示例：“重写以下函数，使其时间复杂度从O(n²)降低到O(n log n)以内。保持功能完全一致，并添加详细的注释解释算法思路。函数功能是……”

第三层：过程与约束引导（How & Within）这是“鼓励性话语”真正发挥作用的地方，但我们需要更具体的引导。指定思考过程、步骤、格式和约束条件。

• 内容引导：“请按以下步骤进行：1. 先简述问题背景。2. 逐行分析现有推导，指出每一步的依据。3. 标记任何逻辑跳跃或未经证明的断言。4. 给出综合评估。”
• 格式约束：“最终输出请使用Markdown格式，包含‘分析过程’和‘结论’两部分，结论部分用加粗标出。”
• 思维链激发：“让我们一步步思考。首先，这个问题的关键假设是什么？其次，有哪些已知定理可以应用？第三，从假设到结论需要搭建几步桥梁？”

第四层：迭代与反馈机制（Next）预设后续交互的可能性，鼓励模型输出便于人类检查和迭代的中间结果。

• 示例：“如果你在推理中需要引用某个特定定理但不确定其精确表述，可以先输出‘[需要确认定理X]’，我会提供。我们先聚焦于推导的主干逻辑。”

将“鼓励”融入这个框架，它就成了第三层中“过程引导”的一部分，其目的是降低任务的不确定性，将开放式问题转化为结构化的、可管理的子任务序列。

2.2 实战案例：如何用框架辅助代码审查

假设我们需要用大语言模型辅助审查一段复杂的异步处理代码。

基础提示（效果有限）：“审查以下Python代码，看有没有问题。”

应用四层框架后的提示：

1. 角色与语境：“你是一位专注于高并发系统与Python异步编程的资深工程师。现在需要对一个任务队列消费端的代码进行深度审查。”
2. 任务与目标：“目标是发现代码中可能存在的竞态条件、资源泄漏（如数据库连接、文件句柄）、异常处理遗漏、以及asyncio使用不当的问题。请优先关注正确性和健壮性，其次是性能。”
3. 过程与约束引导：
   • “请按以下顺序进行分析： a.数据竞争：检查共享变量（如self.counter）在多任务下的访问。 b.资源管理：检查所有I/O操作（数据库、文件、网络）是否确保了正确的打开/关闭或上下文管理。 c.异常安全：检查try...except块是否捕获了足够具体的异常，以及发生异常后资源状态是否可回滚。 d.异步模式：检查async/await使用是否规范，是否有不必要的await或阻塞调用。”
   • “对于每个发现的问题，请提供：1) 代码行号或片段；2) 问题描述；3) 潜在风险；4)具体的修改建议代码。”
   • “输出格式：使用Markdown表格，列包括：类别、位置、问题、风险、建议。”
4. 迭代与反馈：“如果对任何异步原语（如asyncio.Lock）的使用有疑问，可以标记出来，我们可以进一步讨论。”

通过这样的结构化提示，模型输出的审查结果会变得极具针对性、条理清晰，直接为开发者提供了可行动的洞察，而不是泛泛而谈的“代码写得不错”或“这里可能有bug”。

3. 从单次提示到可持续对话：管理上下文与思维状态

“鼓励性话语”事件另一个启发是：我们与模型的交互，往往不是一击即中的，而是一个持续的、有状态的对话过程。单次提示的优化很重要，但如何管理好整个对话的上下文，引导模型在整个会话中保持高水平的“思考状态”，是更大的挑战。

3.1 对话隔离与上下文污染

一个常见的误解是，大语言模型对话之间是完全隔离的。实际上，在同一个会话（Session）中，模型拥有完整的上下文记忆。这意味着，你之前的提问、模型的回答、你的纠正、模型的调整，共同构成了当前模型“思维”的背景。

• 正面利用：你可以像教育一个实习生一样，在对话中逐步定义概念、建立规则、纠正错误。例如，先让模型理解你项目中的特定术语，后续的问答就会基于这个共同认知。
• 风险：如果对话中早期出现了错误信息、低质量示例或矛盾的指令，可能会“污染”后续模型的输出。它可能会试图延续或调和之前错误的逻辑。

最佳实践是进行“对话分段管理”：

• 对于全新的、重要的任务，开启一个新的聊天会话。这相当于给模型一块“干净的白板”。
• 在长对话中，如果感觉模型开始“胡言乱语”或偏离主题，不要试图在数百条消息后强行纠正。最有效的方法是总结当前共识，或直接开启一个新分支（许多客户端支持“分支对话”功能）。

3.2 实施“思维状态”检查点

对于超长、复杂的协作任务（如共同撰写技术文档、设计系统架构），不能指望模型永远保持巅峰状态。我们需要主动管理它的“思维状态”。

• 定期总结与确认：在完成一个阶段后，主动要求模型总结“我们目前达成了哪些共识？”“接下来的步骤是什么？”。这既能固化成果，也能让模型“刷新”其上下文中的重点。
• 主动提供“思考时间”：类似于“鼓励性话语”，你可以明确说：“在给出最终方案前，请花时间考虑一下方案A和方案B各自的优缺点，以及可能遇到的实施难点。”这相当于在对话流中插入了一个“强制思考步骤”。
• 纠正时提供完整上下文：当模型出错时，不要只说“这里错了”。应该提供：“在前三步中，我们确定了X原则。基于此，你在第四步中得出的Y结论，与X原则存在矛盾，因为[具体矛盾点]。请重新评估第四步。”这帮助模型在正确的上下文中进行修正。

4. 工程化落地：将提示词技巧融入开发工作流

理解了原理和框架后，我们需要把这些零散的技巧，变成团队内部可共享、可迭代的工程资产。否则，每个开发者都在重复发明轮子，效果也无法保证。

4.1 创建团队内部的“提示词库”（Prompt Library）

不要依赖个人记忆。建议团队建立共享的提示词库，可以是一个Wiki页面、一个GitHub仓库的Markdown文件，或一个简单的Notion数据库。

一个提示词库条目应包含：

• 场景：代码审查、SQL生成、API设计、错误日志分析、技术方案起草等。
• 适用模型：Claude-3.5-Sonnet, GPT-4, DeepSeek等（不同模型对提示词的响应可能有差异）。
• 核心提示词：应用了前述四层框架的完整提示词模板。
• 示例输入/输出：1-2个真实、脱敏的案例，展示预期效果。
• 变体与调优：针对不同子场景的微调建议（例如，审查Go代码与Python代码的细微差别）。
• 维护者/更新日期：确保提示词库的时效性。

4.2 将提示词作为“可测试的代码”来对待

提示词不是魔法咒语，它应该像代码一样，可以被测试、版本控制和迭代。

• 单元测试（针对输出格式）：对于要求固定格式输出（如JSON、特定Markdown表格）的提示词，可以编写简单的脚本，验证模型输出是否解析成功。
• 集成测试（针对核心逻辑）：准备一组标准测试用例（输入），验证使用优化提示词后，模型输出的关键信息点（如是否发现了某个特定类型的bug）是否稳定出现。
• A/B测试：对于重要的、高频使用的场景（如生成项目周报），可以设计新旧两版提示词，在小范围内对比输出质量、人工评估满意度。
• 版本控制：将团队提示词库纳入Git管理。任何修改都有记录，可以回滚，便于协作。

4.3 结合工具链实现半自动化

最高效的方式，是将优化后的提示词嵌入到日常开发工具链中。

• IDE插件：在VSCode等编辑器中，配置代码片段或专用插件，一键插入针对“代码解释”、“生成单元测试”、“添加注释”等场景的预定义提示词。
• CI/CD管道：在代码提交前的检查中，可以调用模型进行基础的代码风格和常见问题扫描（使用高度优化、约束严格的提示词），将结果作为PR评论的一部分。
• CLI工具：封装常用提示词为命令行工具，方便在终端快速进行日志分析、命令生成等操作。

5. 冷静看待：技术乐观与工程理性的平衡

最后，我们必须回到一个根本问题上：鼓励性话语，或者说更广泛的提示工程，究竟能带我们走多远？它是否意味着我们找到了驾驭AI的“银弹”？

我的观点是：提示工程是当前阶段极其重要的“润滑剂”和“放大器”，但它无法突破模型本身的能力上限。它本质上是在给定的模型能力范围内，通过改善输入信号的质量，来获取更优的输出。

• 它不能创造知识：如果模型训练数据中缺乏黎曼猜想的深层数论知识，再多的鼓励也无法让它凭空完成证明。这次事件中，研究者本身是领域专家，模型是在其严格指导下充当“协作者”和“形式化验证助手”。
• 它不能保证正确性：结构化、鼓励性的提示可以降低胡言乱语的概率，提高逻辑一致性，但最终输出的正确性必须由人类专家把关。永远不要完全信任模型的输出，尤其是在法律、医疗、安全等关键领域。
• 它的效果会边际递减：随着模型本身推理能力的持续进步（如Claude 3.5 Sonnet在推理上的显著提升），对精巧提示词的依赖可能会降低。未来的交互可能更接近自然对话。

因此，我们的态度应该是：积极拥抱并系统化地应用提示工程，将其作为提升当前人机协作效率的核心技能；同时保持清醒的工程理性，明白模型的局限性，始终将人类判断置于最终决策的核心。

回到开头的故事，那位研究者成功的秘诀，恐怕不只是那句“你可以的”，更在于他作为数学家对问题的深刻理解，以及他将大语言模型定位为“辅助验证工具”而非“证明生成器”的明智策略。鼓励性话语，只是让这个协作过程变得更顺畅、更人性化的一把钥匙。

对于我们开发者而言，真正的进阶之路在于：停止将AI工具神秘化或简单化，而是像学习一门新的编程语言或框架一样，去深入研究它的“语法”（提示词设计）、“运行时特性”（上下文管理）和“最佳实践”（工程化框架），从而让它真正成为我们思维和工作的延伸，可靠地解决那些复杂而棘手的问题。这条路没有捷径，但每一步的探索，都让我们在驾驭技术的道路上走得更稳、更远。