是的，您可以使用龙书中描述的技术来编写解释器。
无论如何，您都需要一个词法分析器和一个解析器。
正如其他人指出的那样，您确实需要编写代码来执行实际执行——但对于一个简单的解释器，这可能与龙书中描述的语法导向翻译基本相同。
其他一切都是可选的。
如果你想直接从解析器跳到执行，你可以。这将为您留下一个非常简单的语言，它可能有好有坏——请查看Tcl以获得这种语言的示例。
如果你想在解析每一行时解释它，你也可以这样做；这是大多数命令行解释器（Unix shell 脚本、Microsoft 的 cmd.com 和 PowerShell）所做的，以及用于 Python 和 Ruby 等语言的交互式“REPL”（Read-Eval-Print-Loops）。
“语义分析器”对我来说似乎含糊不清，但听起来它应该包括大多数类型的加载时一致性检查。这也是可选的，但解释器的优点是不会接受任何旧垃圾并尝试将其作为程序执行......
“中间代码”也有点模糊，但可以说是可选的。如果您不是直接从程序字符串执行（如在 Tcl 中），您需要某种内部表示来存储您的代码，一旦您读入它。一个流行的选择是从内部树结构执行，基于更多或者不太接近您的解析树，这可以说与生成“中间代码”不同。另一方面，如果您的“中间代码”或多或少可以直接从您的内部树结构中写出，那么您不妨将内部结构算作您的“中间代码”。
有一些重要的问题你没有解决；一个突出的是：你想如何处理名字？大概您希望程序员能够定义和使用他自己的名称（例如，用于变量、函数等），因此您需要为此实现某种机制。
究竟如何处理名称是一个重大的设计决策，对您的语言的可用性和可实施性有重大影响。最简单的实现选项是使用单个全局哈希映射来实现单个全局命名空间——但请注意，这种选择存在众所周知的可用性问题......
我可以编写一个读取源代码并立即执行步骤的基本解析器吗？
你可以，但你会很难做到。
例如，我是否需要编写一个词法分析器、一个语法分析器、一个语义分析器和一个中间代码生成器？
您可以跳过中间代码生成，除非您想编写基于 VM 的解释器。比如 Perl，用来直接执行它的解析图；这与生成中间字节码的 Java 或 Python 不同。
基于 VM 的语言的解释器部分通常比必须理解解析图的解释器更简单（因此系统中的每个组件都更简单），但是当您不需要时，整个解释器堆栈的复杂性通常更简单定义一种中间字节码语言。所以选择你的毒药。