那么，如果大模型正在重新构建软件工程的未来，我们是否应该遵循一些基本原则呢？

如果模型能做到的是事情，就不要写代码；模型会变得更好，但代码不会。

在当今的时代，模型的价值日益凸显。与传统的编程方法不同，现在的开发思路更倾向于“模型优先”。这意味着，当我们面临一个问题或任务时，我们首先应思考是否可以利用现有的模型来解决它，而不是立刻着手编写代码。因为代码是固定的，而模型有着巨大的发展空间。随着时间的推移，模型强大的学习和适应能力能够在不断迭代中自我优化和进步。因此，我们的首要任务是发掘模型的潜力，让它成为我们解决问题的利器。

对于整个系统而言，目标是利用LLM的规划和理解意图的能力，以此来构建高效的项目。在这个过程中，我们可能会受到诱惑，想要回到那种命令式的思维模式，为程序的每个细节编写代码。但是，我们必须抵制这种诱惑，在一定程度上，现在可以让模型可靠地做一些事情，随着模型的发展，它会变得更好、更健壮。

利用权衡杠杆换取精准，使用交互来缓解模糊。使用LLM进行编码时的正确心态不是“让我们看看我们能让跳舞的熊做什么”，而是从系统中获得尽可能多的杠杆作用。例如，可以构建非常通用的模式，如“从数据库构建报告”或“教授一年的科目”，这些模式可以通过纯文本提示进行参数化，从而轻松产生非常有价值和差异化的结果。

在追求高精准度的同时，我们必须权衡其与其他因素之间的关系。为了达到这种平衡，我们可以引入交互的方式，来消除可能出现的歧义和误解。这种策略不仅提高了精准性，还增加了操作的灵活性和效率。

在使用LLM进行编码的过程中，关键的心态不应该是“试试看能做什么”，而应该思考如何从系统中获得最大的杠杆效应。这意味着，我们不应仅仅满足于简单的功能实现，而是要深入挖掘系统的潜力，让其为我们创造更大的价值。

实际应用中，我们可以构建一些通用的模式。比如，“从数据库生成报告”这样的模式，它具有很强的适应性，可以通过简单的文本提示进行参数调整，从而应对各种需求。再例如，“教一年的深度学习课程”这样的模式，它整合了丰富的教育资源，同样可以通过交互方式轻松调整，满足个性化的教学需求。

通过这些通用模式的应用，不仅提高了工作效率，还能轻松产生有价值、与众不同的结果。这种权衡精准性与交互消歧的策略，无疑是基于大模型应用设计中的重要思维方式。

在现代编程领域，代码和模型之间的分工变得越来越明确。简而言之，代码主要负责语法和过程的实现，而模型则专注于语义和意图的生成与解读。这种分工在实际应用中有多种表达方式，但核心思想是一致的：代码是用来执行特定指令和流程的工具，而模型则用来解读、生成和推理语言的深层含义和目标。

从根本上说，模型在推理语言的意义和目标时表现出色，相形之下，当它们被要求执行特定的计算和过程时，往往表现得不如代码。例如，一个高级模型可能很容易为求解数独编写代码，但如果让它自己亲自去解数独，可能就会变得相对困难。

每种代码都有其独特的优势，关键在于针对特定的问题选择最适合的工具。语法和语义之间的界限，正是大模型应用设计的主要挑战。在这个背景下，我们需要更深入地理解代码与模型各自的优缺点，以便更为有效地利用它们解决问题。

在构建任何系统时，一个不可忽视的事实是，系统的整体强度往往由其最脆弱的部分决定。这一观点不仅适用于传统的软件系统，对基于大模型的应用同样适用。

在追求系统灵活性和高效性的过程中，特别要避免硬编码。硬编码指的是将特定的值或逻辑直接写入代码，而不考虑未来的变化或扩展。这种做法在短期内可能带来便利，但长期来看，会导致代码僵化，难以维护。因此，我们应该在代码和算法中加入更多的推理和灵活性。

当设计提示语和交互时，应该尽量让其包含足够的信息和逻辑，以便系统能够自主地进行决策和推理，而不是简单地执行预定义的命令。通过这种方式，不仅可以减少硬编码的使用，还能更好地利用LLM的能力，让系统更加智能、更加灵活。

大模型确实展现出了非凡的能力，如同“受过良好教育的”个体，但在实际应用中，它们仍然缺乏某些背景和主动性。

简单来说，如果你向这些模型提出一个简单或开放式的问题，它们会给你一个简单或通用的答案。这种答案可能缺乏深度或细节，无法满足所有需求。如果希望得到更为详尽和深入的答案，那么提问的方式和策略就需要更为明智。

这其实是“Garbage in，Garbage out”原则在人工智能时代的一种体现。无论技术有多么先进，输入的数据质量仍然至关重要。如果输入的数据是模糊、不准确或不完整的，那么模型输出的答案也可能同样如此。

因此，为了确保LLM模型能够给出高质量、有深度的答案，需要确保输入的数据是准确、详尽且上下文丰富的。这也意味着，数据质量仍然至上。只有重视并确保数据的质量，才能期望从这些先进的模型中获得真正有价值、有深度的信息。

每当模型遇到不确定的情况，我们不能简单地忽略它或给出一个模糊的答案。相反，我们应该依赖于与用户的互动意图来澄清这种不确定性。

在程序设计中，当一组嵌套的提示中存在不确定性时——比如一个提示的结果可能有多种解读，我们应采取一种类似于“异常抛出”的策略。这意味着，应该将这种不确定性传递到堆栈中的更高级别，直到到达一个可以与用户交互或澄清不确定性的层级。

这样的设计策略可以确保了程序在面对不确定性时能够做出适当的回应，从而提供更为准确和可靠的结果。

文本已然成为了一种通用协议，这主要归功于LLM对于自然语言、意图和语义的出色解析能力。因此，文本成为了在提示语、模块以及基于LLM的服务之间传递指令的首选格式。

尽管自然语言在某些应用场景下可能略显不精确，但相较于其他结构化语言（如XML），其优点在于简洁、直观且易于人类理解。当然，对于那些需要高度精确和结构化的任务，仍然可以少量地采用结构化语言进行辅助。但多数场景下，自然语言在传递指令和意图方面表现得相当出色。

更为值得一提的是，随着这些基于LLM的普及和进步，文本作为一种“未来证明”的自然交互方式，将进一步促进不同系统、不同提示之间的互通与理解。如果两个完全不同的LLM服务都能够理解和响应相同的文本指令，那么它们之间的协作和交互将变得如同人类之间的沟通一样自然、流畅。

将文本视为通用协议，不仅有助于我们更好地利用LLM的能力，也为构建一个更加智能、更加互通的应用程序打下了坚实的基础。

当面对一个复杂问题时，不仅对人来说是一个挑战，对大模型而言也同样如此。在实际应用中，如果我们直接将复杂问题的提示语作为程序的一部分，可能会遇到问题，因为我们真正需要的只是推理的结果。

为了解决这个问题，一种有效的方法是使用“元”提示。这种提示不仅可以给出问题，还能提供详细的答案，然后要求模型从中提取关键信息。这种方法的效果会很好，因为它实际上是将一个复杂的认知任务转化为了一个相对简单的任务。想象一下，如果给一个人一个“阅读这篇文章并找出答案”的任务，即使该用户没有相关领域的专业知识，他也很有可能完成这个任务，因为自然语言的力量是巨大的。

因此，在设计基于大模型的应用时，需要注意：对一个普通人来说很难的事情，对模型来说也可能同样困难。面对这种情况，最好的策略往往是将复杂的问题或任务分解为更简单的步骤。这样不仅可以降低处理的难度，还能提高答案的稳定性和准确性。

模型不仅是一种工具，它也可以成为我们对抗自身错误的利器。很多时候，我们容易将LLM（大语言模型）的运作想象成一个“头脑”的内部过程。然而，必须认识到，尽管模型与人类思维在某些方面有相似之处，但二者之间仍存在许多有意义的差异。

这其中有一个特点尤为重要：模型在短时间的交互中往往缺乏持久记忆。这意味着，模型在从一分钟到下一分钟的交互中，不太可能记住所有的细节。这一特点为我们提供了某种控制的可能性。

这种控制不仅限于代码审查。事实上，模型还可以作为代码的安全监视器，确保代码的运行安全；它也可以作为测试策略的一个组件，帮助我们制定更为有效的测试方案；甚至可以作为内容过滤器，协助我们生成高质量的内容。

因此，只要我们对模型进行适当的控制和引导，它就能成为我们工作中得力的“助手”。而这种控制的基础，就是我们对模型内部机制和特点的深入了解和掌握。

大语言模型的能力确实令人惊叹，它们可以处理和解析大量的文本数据，生成有逻辑和连贯性的文本，甚至在某些任务上超越了人类的表现。然而，这并不意味着我们应该盲目崇拜这些大模型，认为它们无所不能。

事实上，大模型仍然存在着许多局限性和边界。尽管它们可以处理大量的文本数据，但它们并不能像人类一样真正理解语言和语境的细微差别。此外，它们的表现也受到训练数据和算法选择的限制，可能会出现一些偏见和错误。

因此，我们在使用大模型时，应该保持理性和谨慎的态度，既要欣赏它们所带来的便利和进步，也要警惕它们的局限性和潜在风险。这样，才能更好地利用这些模型，推动基于大模型应用的健康发展。