深度探索我在驾驭大语言模型（LLMs）中学到的策略

庆祝这一里程碑 — 真正的胜利在于宝贵的学习经历！

2023年11月，我非常荣幸地在新加坡政府科技局（GovTech）组织的首届 GPT-4 提示工程大赛中脱颖而出，这场比赛吸引了超过 400 名杰出的参与者。

提示工程是一门将艺术与科学巧妙融合的学科 — 它不仅关乎技术的理解，更涉及创造力和战略思考。这里分享的是我在实践中学到的一些提示工程策略，这些策略能够精准地驱动任何大语言模型为你服务，甚至做得更多！

作者的话： 在写作本文时，我特意避开了那些已经广泛讨论和记录的常规提示工程技巧。相反，我更希望分享一些我在实验中获得的新洞见，以及我个人在理解和应用这些技巧时的独到见解。希望你能从中获得乐趣！

本文涵盖以下主题，其中 🔵 代表初学者友好的技巧，而 🔴 代表高级策略：

1. 🔵 借助 CO-STAR 框架构建高效的提示
2. 🔵 利用分隔符来分节构建提示
3. 🔴 设计含有 LLM 保护机制的系统级提示
4. 🔴 仅依靠大语言模型分析数据集，无需插件或代码 — 实际案例分析 Kaggle 的真实数据集

1. 🔵 借助 CO-STAR 框架构建高效的提示

在使用大语言模型时，有效的提示构建至关重要。CO-STAR 框架，由新加坡政府科技局数据科学与 AI 团队创立，是一个实用的提示构建工具。它考虑了所有影响大语言模型响应效果和相关性的关键因素，帮助你获得更优的反馈。

CO-STAR 框架 — 作者提供的图像

如何应用 CO-STAR 框架：

• (C) 上下文：为任务提供背景信息 通过为大语言模型（LLM）提供详细的背景信息，可以帮助它精确理解讨论的具体场景，确保提供的反馈具有相关性。
• (O) 目标：明确你要求大语言模型完成的任务 清晰地界定任务目标，可以使大语言模型更专注地调整其回应，以实现这一具体目标。
• (S) 风格：明确你期望的写作风格 你可以指定一个特定的著名人物或某个行业专家的写作风格，如商业分析师或 CEO。这将指导大语言模型以一种符合你需求的方式和词汇选择进行回应。
• (T) 语气：设置回应的情感调 设定适当的语气，确保大语言模型的回应能够与预期的情感或情绪背景相协调。可能的语气包括正式、幽默、富有同情心等。
• (A) 受众：识别目标受众 针对特定受众定制大语言模型的回应，无论是领域内的专家、初学者还是儿童，都能确保内容在特定上下文中适当且容易理解。
• (R) 响应：规定输出的格式 确定输出格式是为了确保大语言模型按照你的具体需求进行输出，便于执行下游任务。常见的格式包括列表、JSON 格式的数据、专业报告等。对于大部分需要程序化处理大语言模型输出的应用来说，JSON 格式是理想的选择。

CO-STAR 框架的实用示例

这里有一个 CO-STAR 框架为何有用的现实案例。假设你担任社交媒体经理，需要草拟一条 Facebook 帖子，用以推广公司的新产品。

Read More

一、超越传统开发方式

传统的开发方式由单一专业职能团体组成，反馈环延迟甚至薄弱，使用预言性质的计划和从分析到测试流程，这在变化无常的当今世界中成效甚微。由于直到开发后期才会有真正可工作的软件，这种方式会延迟反馈、学习，以及潜在投资回报。从而导致透明度不足、改进能力缺失、灵活度减少、商业和技术风险增加。

取而代之的是跨专业职能团队与迭代开发，这种方式也存在了几十年，但并不如传统模式那样被广为使用。

Scrum把已被证实的产品开发概念打包到简单的框架中，包括:真正的团队、跨职能团队、自管理团队、短迭代全周期反馈环、降低变动成本。这些概念提升了敏捷性与反馈、使提早实现投资回报成为可能并降低风险。

二、概述

Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周(最常见的是两周)，并且无间歇地相继进行。 Sprint是受时间盒限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由 Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。在每个Sprint的初始，跨职能团队(大约7名成员)从排好优先级的列表中选择事项(客户需求)。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。在Sprint过程中不可以增加新事项，Scrum在下 一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团 队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint 中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、 完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。其中的主要角色、工件和事件如 图表1所总结。

图1 Scrum概述

Scrum中的一大主题就是“检视并调整”。因为开发工作不可避免地包含学习、创新和意外事件， Scrum强调进行小步骤开发，同时检验最终产品和当前实践的功效，然后调整产品目标与过程实践。 周而复始。

Read More

大家都讲敏捷（Agile），这个词的不等于单纯的快，而是灵活适应，快速响应变化的意思。

那么，哪些因素可以提高组织敏捷性呢？这里提出一个基于风险ROI的模型，讲各种因素统一融合起来。

$$
ROI=\frac{Impact*p%}{Cost}
$$

（p%=概率或确定性，Impact=影响程度或收益程度，Cost=成本）

风险偏好心理补偿作用：对不确定和犯错的容忍

由于心理对变化和不确定性的恐惧，而影响到ROI临界值的判断。

旧版

（摘要）

[TOC]

自动化测试的价值

开发者应该编写自动化测试，以便当发现回归问题时就使构建失败。而且，测试先行的编程风格已有大量的专业研究，使用自动化测试不仅是保护回归，而且是帮助设计，在编写代码之前就指出代码的期望行为，从而在验证实现之前先验证设计。

来认识一下小马。小马是著名的编程奇才，两年前刚毕业，然后加入了本地一家投行的IT部门，为银行开发用于在线自助服务的web应用程序。作为团队中最年轻的成员，起初他保持低调，集中精力学习银行的领域知识，熟悉“这里做事的方式”。

几个月后，小马注意到团队的工作很多都是返工：修复程序员的错误。他开始关注团队修复错误的类型，发现单元测试可以轻易地捕获到其中大多数。当他感觉到哪里存在特别容易出错的代码时，小马就对其编写单元测试。

测试帮助我们捕获错误。

一段时间以后，团队其他人也开始到处编写单元测试。Marcus已被测试感染 (test-infected) 了，他碰过的代码几乎都具有相当高的自动化测试覆盖率。除了在第一次时犯错，他们不会再花费时间修复过去的错误，待修复缺陷的总数在下降。测试开始清晰可见地影响着团队工作的质量。

自从小马编写第一个测试，已经过去近一年了。团队的测试覆盖率在近几个月快速提高，达到了98%的分支覆盖率。小马曾认为他们应该推动那个数字直到100%。但过去几周，他打定了主意——那些缺失的测试不会给他们带来更多价值，花费更多精力来编写测试不会带来额外的收益。许多没有测试覆盖的代码，只因所用的API要求实现某些接口，但小马的团队并未用到它们，那么何必测试那些空方法桩呢？

100%测试覆盖率不是目标

100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了，不论程序的行为是否满足要求。与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。

后来，高级软件架构师老赛加入了自助服务团队，并快速地成为了低级成员的导师，包括小马在内。小马习惯于先写代码，在提交到版本控制系统之前再补充单元测试。但老赛的风格是先写一个会失败(很明显是这样)的测试，再写足够使测试通过的代码，然后写另一个失败的测试。他重复这个循环直到完成任务。

与老赛共事，小马意识到自己的编程风格开始转变。他的对象结构不同了，代码看起来稍微不同了，只是因为他开始从调用者的角度来审视代码的设计和行为了。

测试帮助我们针对实际使用来塑造设计。

想到这些，小马觉得好像明白了一些道理。当他试图用语言表达出他的编程风格是如何改变的，以及收到了哪些效果时，小马明白了他写的测试不仅仅是质量保证的工具，或是对错误及回归的保护。测试作为一种设计代码的方式，提供了具体的目的。编写使失败测试通过的代码比以前的方式简单多了，而且该做的也都做了。

通过明确地指出所需的行为，测试帮助我们避免镀金。

主人公小马的经历正如许多爱好测试的编程人员一样，在不断地认识和理解测试。我们经常因为相信单元测试有助于避免尴尬、耗时的错误而开始编写它们。随后我们会学到，将测试作为安全网只是等式的一部分，而另一部分——或许是更大部分——其好处是我们将测试表达为代码的思考过程。

大多数人同意说编写一些测试是不费脑筋的。但随着我们接近完全的代码覆盖率，我们不那么确定了——我们差不多已经为一切都编写了测试，而剩下的没有测试的代码是微不足道，几乎不会破坏。这就是某些人所谓的收益递减。因此，

编写测试的最大价值不在于结果，而在于编写过程中的学习。

（略，请阅读正版原书）

何为优秀与代码坏味道

可读性、可维护性、可信赖性…

单元测试代码的可读性

原始类型断言

断言应该表达某种假设或意图。它们应该声明代码的行为。基本断言的问题在于它们缺乏意义，因为断言的基本原理和意图隐藏在看上去无意义的单词和数字背后，造成它们难以理解，并且难以验证断言的正确性。

下面例子展示了一个**全局正则搜索(grep)**程序的测试。grep程序其实就是逐行处理某种文本输入，在处理时可以包括或排除掉含有特定子串或模式的文本行。测试应当是你的对象所提供功能的具体例子，那么我们来看一看这个测试是否说清楚了grep程序该做的事情。但愿这个测试没有受到原始类型断言的折磨！

1
2
3
4
5
6
7

@Test
public void outputHasLineNumbers() {
   String content = "1st match on #1\nand\n2nd match on #3";
   String out = grep.grep("match", "test.txt", content);
   assertTrue(out.indexOf("test.txt:1 1st match") != -1);
   assertTrue(out.indexOf("test.txt:3 2nd match") != -1);
}

这个测试在干什么？首先，我们定义了文本字符串content来表示一段输入，然后调用grep程序，然后对grep结果输出中的某些东西进行断言。这些东西就是问题所在。断言的目标并不清楚，因为断言过于基本——它与测试的其他部分说着不同的语言。

具体来说，我们在这个断言中是要计算输出结果中的另一个文本字符串的索引，并将其与-1进行比较；如果索引为-1，那么测试失败。测试的名字叫做outputHasLineNumbers，显然，对于在代码中grep()的具体调用，输出结果应当包含正在进行逐行查找的文件名，后面加上行号。

不幸的是，我们不得不经过这个思考过程才能理解为什么我们要计算索引，为什么查找test.txt:1而不是其它东西，为什么与-1进行比较，当索引是-1或不是-1时测试是否会失败？这无需火箭科学就能找到答案，但却是我们大脑的不必要的认知工作。

Read More

你可能没有意识到，但是当你购买敏捷教练（特别是企业级教练）时，你所购买的是他们带来自己方式、他们的理智、他们的自制、他们的意义建构、以及他们的人性。正是由于很少人能带来那些东西，所以你值得付出—————金钱，以及（暂时性）的迷失方向和一定程度的不舒适，而这些将最终转化为舒适。你购买的是种子，这些种子会为你的组织赋予人性。

“You may not realize this, but when you pay an agile coach (especially an enterprise coach), you’re paying for the way they bring themselves, their consciousness, their self-mastery, their sense-making, and their humanity to your organization. And because it is so rare for people to bring these things, it’s going to cost you - both in terms of money, and in terms of (temporary) disorientation and a certain discomfort, which will eventually turn to comfort. You’re paying for the seed to humanize your organization.” - Posted on LinkedIn by Oluf Nissen

背景

德国的敏捷专家 Den Sunny 在2020年发起了一个全球性的签名运动，网站 http://remove-scrum-from-safe.tilda.ws/。

我们喜欢 Scrum。我们反对 SAFe（规模化敏捷框架）创建和推广的对 Scrum 的误解。

理由主要在在于规模化敏捷SAFe官网对Scrum、Scrum Master等概念的描述与Jeff Sutherland 和 Ken Schwaber 制定的《Scrum指南》有多处出入，造成误解和误用。

…像 SAFe 这样的框架 … 与 Scrum 指南不一致，并且编纂了可能削弱团队多年的功能障碍。

– 杰夫·萨瑟兰(Jeff Sutherland), Co-creator of Scrum

呼吁和诉求

我们呼吁 SAFe 的所有者尊重个人和组织，停止承诺可以在 SAFe 中使用 Scrum 和 Scrum Master 角色！

许多组织相应地实施规模化敏捷 SAFe，并具有各自的角色和流程。由于当前 SAFe 描述中的陈述，他们可以合理地期望能够在此结构中使用 Scrum。相反，SAFe 角色和流程迫使他们使用****大量 Scrum 反模式并造成严重的功能障碍。

然而，这些组织认为这正是 Scrum 框架，他们在此基础上了解 Scrum。它引入了对 Scrum的完全错误的理解，并剥夺了组织实现目标的机会。

此外，对于决定在 SAFe 中培养 Scrum Master 技能的人来说，这会导致重大的职业损失. 他们学习了错误的理论并采取了功能失调的行为。之后，他们很难理解真正的区别，以便能够有效地帮助组织正确采用 Scrum。

Read More

（原文由博主mebusw于2009年发表于现已不在的桌游论坛BGC。”Race For The Galaxy” 策略类卡片桌游是一种很好地团建方式，节奏快，时间段，易上手，寓教于乐，特别适合于敏捷团队，笔者于2007年开始尝试这种方式带团队，收到很好的效果。今日偶然翻到这篇旧文，忆往昔DIY的日子，唏嘘不已。）

随着空间跃迁知识的传播，一个古代种族开始蠢蠢欲动，而另一个种族需要逃离行将灭亡的恒星。银河帝国的力量不断增长，导致了更加严重的叛乱和佣兵的出现。在这个面临战争的银河系里，你能建立起最为繁荣强大的国家么？

简介

本扩展里加入了新的起始星球和新的游戏卡牌，为第五玩家准备的行动卡牌和VP筹码，以及银河竞逐的目标卡。此外这里还提供了一个独立的单人游戏，一种轮抽玩法以及一些空白卡牌，以便玩家自己设计星球和开发设施牌。

Read More

本文是之前为Scrum Gathering 2013敏捷大会准备话题时总结的一些想法，又在台北RSG2022大会进行了重制。更多是从内部做ScrumMaster和敏捷教练时的体会。重点是：对齐目标 收服人心，用魔戒甘道夫作比喻，借假修真地阐述敏捷教练打造敏捷团队的秘诀，最主要的能力就是”填坑”（Fill the Gap）。

点击观看幻灯片演讲实录：

对齐目标 收服人心——魔戒甘道夫用“血泪”填坑 | 打造敏捷团队的秘诀 敏捷教练借假修真

（关于Scrum Master与Agile Coach的区别，笔者认为不大，SM也不只是懂Scrum就够了。其实可以从团队级和组织级来区别工作范围，而不是纠结名字）

SM是新的角色，很多时候定位不是那么清楚。The Scrum Master is primarily responsible for “How” - using Scrum the right way.

Read More

大家都讲敏捷（Agile），这个词的不等于单纯的快，而是灵活适应，快速响应变化的意思。

那么，哪些因素可以提高敏捷性呢？这里不讲各种方法论实践，而是试图从“法”的角度来列举一些来源。

敏捷性获得的因素

Read More

作为一个合格的敏捷教练，既要理解领域知识，又要懂得过程的重要性，是各种综合能力的体现。

[

对于《敏捷回顾》这本书，大家一定不陌生了，很多敏捷教练都会到其中的5步法来引导回顾会议。

最近学习了杰拉德老师讲的ToP的引导技术，发现ORID可以作为一种新的引导方式，而且问题的设计更加结构化。那么究竟如何来设计这个过程呢？

Read More