Linux自学第三天：从安装nginx到权限与日志排查的完整实战

1. 为什么偏偏是第三天？

严格来说，我不是什么有天赋的学习者。前两天我还在跟终端里的黑框框大眼瞪小眼，甚至一度怀疑自己是不是买了个假的Linux系统。第一天装好系统之后，我干得最多的事情就是打开浏览器，然后把它关掉，再打开文件管理器，再关掉。到了第二天，我终于鼓起勇气敲了ls、cd、pwd这几个命令，当时心里想的其实是：“这不就跟Windows里的文件夹差不多嘛，有什么好吹的。”

但第三天开始，事情变得不一样了。不是因为我突然开窍，而是因为我的第一个实际需求出现了：我要在Linux上做一个简单的网页测试环境，需要装一个服务端程序，还要让它开机自己跑起来。这个需求让我意识到，前两天的“玩一玩”阶段结束了，接下来面对的是一个真正要动手、要动脑的系统。所以这篇文章的记录，是从“第三天早上打开终端”开始的。

这篇文章适合谁看？如果你正在自学Linux，可能和我一样还在前期摸索阶段，那么这篇文章里记录的思路、命令、踩坑过程，应该会对你有帮助。如果你已经学了一段时间，大概率也能从我的错误里找到点共鸣。我不讲那种动不动就要背几千条命令的“高手方法论”，我只讲我在第三天实际做了什么、遇到了什么、以及我是怎么从一团乱麻里把问题捡起来的。

2. 第三天早晨：我的第一个真实任务

2.1 任务拆解，而不是直接开干

我的目标是搭建一个简单的本地网页服务。听起来不复杂，但当我坐下来准备操作时，发现自己其实连“服务”这个词在Linux里意味着什么都不太清楚。Windows下我可能就双击一个安装包，下一步下一步，完事。但在Linux里，我面对的是一个终端，一个没有图形界面的“裸环境”，所有操作都要自己一步步拼出来。

我给自己定了三条路：

• 第一，搞清楚我现在用的这个发行版怎么安装软件包；
• 第二，搞清楚服务程序装完之后放在哪里、怎么启动；
• 第三，搞清楚怎么让它开机自动运行，还要能随时看日志。

这三件事，每件单独拎出来都不至于让人崩溃，但合在一起，就足以让一个初学者在第三天早上对着屏幕发呆半小时。

2.2 确认环境和版本，是学习的第一步

很多新手容易忽略的一件事是：不同Linux发行版之间的操作习惯差异很大。我前两天用的命令，到了第三天才发现，有些是当前系统自带的，有些则压根不存在。为了避免“命令不存在”这种尴尬，我先花了几分钟确认环境信息。

我敲的第一组命令是这样的：

uname -a cat /etc/os-release

uname -a显示内核版本、主机名、架构这些信息；cat /etc/os-release则能让我清楚看到当前发行版的名称和版本号。我看到的结果是“Ubuntu”以及某个具体版本号，心里就有底了：接下来查资料时，只要搜索Ubuntu相关的教程，基本都能对上。

这里有个小建议：不要跳过环境确认这一步。它虽然不产生任何“成果”，但能帮你省下后面大量排查问题的时间。毕竟你在网上搜到一条命令，结果发现在自己的环境里不能用，那不是命令的问题，而是环境差异的问题。

2.3 刷新软件源：安装一切软件的前提

确认完环境之后，我尝试安装第一个软件包。当时我凭记忆敲了install开头的一条命令，结果立刻被提示没有找到相关命令。后来我才知道，Ubuntu下安装软件包的工具叫apt，而它的完整用法需要配合子命令使用。

我当时执行的是：

sudo apt update

sudo是提权用的，意思是“以管理员身份执行”。apt是包管理工具，update会从软件源服务器获取最新的软件包列表。这步操作让我第一次直观感受到Linux和Windows的一个本质区别：Linux的软件安装是依赖“源”的，它不是从某个网站下载一个exe文件，而是从一个配置好的软件源仓库里拉取并解决依赖关系。

跑完update之后，屏幕上刷出一堆进度条，我当时其实也没完全看懂那些数字，只知道最后出现了一行类似“所有软件包均为最新”的提示。不管怎么说，这一步跑通了，接下来就可以正式安装程序了。

3. 第一道坎：软件包安装与依赖地狱的初体验

3.1 安装一个程序，居然要装一堆“顺便”的东西

我准备安装的是一个轻量级网页服务器软件，因为只是想测试，所以选择了体积小、配置简单的方案。命令是：

sudo apt install nginx

输入这行命令后，系统问我是否继续，我按了y，然后就看着终端刷出一整屏的新软件包信息。这里面除了nginx本身，还有一堆我完全不认识的名字。当时我的第一反应是：“我到底装了多少个东西？”

这个感受特别典型。Linux的软件管理系统中，一个软件包往往会依赖另外一些软件包，而这些被依赖的包又可能依赖更多的东西。这不是坏事儿，它在帮你把所有需要的零件一次性备齐，但对于新手来说，确实容易产生“失控感”。我后来才知道，这个机制叫“依赖管理”，是Linux软件生态相对稳定的根基。

apt默认会把依赖包一起装好，不需要我手动操心。这一点比Windows下那种“你缺个运行库，自己去官网找”的体验要省心很多。

3.2 装完之后，我怎么知道它去哪了？

安装过程结束以后，我面临一个新问题：“这东西到底装哪了？”Windows里我会去“开始菜单”里找图标，但Linux服务器环境里没有开始菜单，程序也不是简单躺在某个固定文件夹里。

我试了which nginx，返回了一个路径，类似/usr/sbin/nginx。于是我开始了解Linux目录的大致分工：

• /usr/bin和/usr/sbin是普通用户和管理员命令所在的地方；
• /etc是配置文件的家，nginx的配置很可能就在/etc/nginx/下；
• /var/log是日志的大本营；
• /var/www或/usr/share/nginx/html之类的地方，通常是默认网页文件的所在目录。

我是怎么验证的？直接用了ls /etc/nginx/，果然看到了nginx.conf和一堆乱七八糟的子目录。这个发现对当时的我来说，几乎等于找到了新世界的入口——原来Linux不是没有“安装目录”，而是它把不同功能的文件分散到不同目录里，各司其职。

3.3 如何启动一个服务

安装完之后，我照着直觉去执行了可执行文件，结果发现前台一直被卡住了，终端完全被日志刷屏，连命令都敲不进去。我意识到这不是正确的启动方式。

后来我查到，管理服务的方法通常是用systemctl命令：

sudo systemctl start nginx sudo systemctl status nginx

start是启动服务，status是查看运行状态。执行完status后，终端上会显示一段状态信息，包括当前进程是否在运行、有没有报错、占用资源情况等等。我看到状态栏里写着active (running)的那一刻，整个人是有点激动的。

说实话，这个“active (running)”在别人眼里就是几个英文单词，但在我第三天的认知里，它意味着我成功把一个后台程序拉起来了，而且是通过真正的Linux管理方式搞定的。

4. 权限：新手和系统打架的重灾区

4.1 为什么总提示 “Permission denied”

装好并启动nginx之后，我想修改一下默认网页内容，把我自己的HTML文件放进网站的根目录。当我兴冲冲地用cp命令复制文件时，却收到了一条冷冰冰的提示：

Permission denied

我第一次看到这行字时，心里的独白是：“这是我自己的电脑，凭什么不让我动？”后来才知道，在Linux里，文件和目录有一整套权限体系，权限不够就是不够，哪怕你觉得自己是电脑的主人也不行。

权限这个东西，我用一个类比才彻底理解：Linux把每个文件和目录看成带了三把锁的箱子，一把管“读”，一把管“写”，一把管“执行”。这三把锁分别对应三类人：文件所有者、文件所属组、其他用户。用ls -l查看文件时，那一串类似-rw-r--r--的字符，就是在展示这些锁的开关状态。

我当时执行的命令是：

ls -l /var/www/html/

输出结果显示默认的网页文件是root用户所有的，且普通用户没有写权限。这其实是一个安全设计，防止普通用户随意篡改系统级的网页内容。但如果我真的要改文件，该怎么办？两个思路：

• 第一，用sudo强制提权操作；
• 第二，修改文件的所有者或权限。

4.2 修改权限的“三板斧”

我的第一个思路自然是sudo，但后来发现，如果每个文件都要用sudo去编辑，时间长了会很别扭。于是我开始接触chmod和chown。

chown用来改变文件所有者，比如：

sudo chown -R 我的用户名 /var/www/html

-R表示递归，对目录及其内部所有文件生效。执行完之后，我再用ls -l查看，发现文件的所有者变成了我自己，这个时候就拥有了直接修改的权限。

chmod则用来改变权限位，常见用法有两种：符号模式和数字模式。我一开始觉得数字模式很难记，直到有人告诉我，r=4、w=2、x=1，把它们相加就好。比如755表示所有者可读写执行（7），组内用户可读执行（5），其他用户可读执行（5）。这样记起来就顺多了。

我把自己的网页目录权限设置成了755，然后在里面新建了一个index.html，再次用浏览器访问，终于看到了我自己写的页面。那一刻的成就感，比第一次看到active (running)还要强烈。

5. 第三天最值钱的收获：学会看日志

5.1 程序没问题，为什么访问不了？

我把自己的网页内容替换进去之后，浏览器打开却还是显示默认页面。我当时把配置文件翻来覆去地看，也没看出哪里有问题。后来在一篇教程里看到一句话：“Linux下排查问题，第一步永远是看日志。”

对，就是日志。我顺着这个提示，查看了nginx的日志目录：

ls /var/log/nginx/

目录里通常有access.log和error.log。access.log记录每一次访问请求，error.log记录程序运行时的错误信息。我当时用了一个命令去查看日志的最后几行：

tail -f /var/log/nginx/error.log

-f参数的意思是“实时追踪”，文件有新内容时自动追加显示。在我用浏览器重新访问网站之后，error.log立刻吐出了一行错误信息，内容是找不到某个具体路径下的文件。我顺着错误提示去检查，发现是我把文件放错位置了，一直放在自己创建的临时目录里，而不是nginx实际读取的根目录。

这件事给了我很深的印象：Windows世界里出了问题，很多时候是靠弹窗提示和重启解决；但在Linux里，程序未必会给友好提示，它只会默默把错误记录在日志里。懂不懂看日志，直接决定了你是“瞎猜者”还是“排查者”。

5.2 日志里的常见关键词速查

我把自己第二天到第三天积累的常见日志关键词整理了一下，虽然不全面，但作为新手备忘足够用了：

遇到问题时，先打开对应日志，搜索这些关键词，通常能很快定位问题范围。这个方法在我第三天下午的排查过程中帮了大忙，后续我相信也会一直用下去。

6. 进程管理：原来电脑里藏着这么多“分身”

6.1 查看进程，像查户口一样

nginx跑起来之后，我产生了一个疑问：“它到底是怎么运作的？为什么我关掉终端它还在运行？”后来才知道，这类服务程序会以“守护进程”的方式在后台运行，不会随着终端的关闭而退出。

为了验证，我执行了：

ps aux

ps是“进程快照”命令，aux是一组参数，用来显示所有用户的进程列表。屏幕上刷出几页密密麻麻的信息，我看到有好多条nginx相关的进程，瞬间有点懵：“我只启动了一个服务，为什么有这么多？”

稍微多了解一点之后我才明白，nginx采用的是多进程模型，一个主进程用来管理全局，再派生出多个工作进程来处理并发请求。这就像一家餐厅里，主厨负责全局调度，几个灶台师傅分别负责不同的菜，客人再多也能同时出餐。用这种比喻去看进程列表，就好理解多了。

6.2 干掉一个卡死进程的正确姿势

学进程管理的过程中，我还碰到过一个“僵尸”进程。具体情况对方不重要，重要的是我发现某个进程占用了CPU和内存，始终不退出。我想把它关掉，于是用上了kill命令。

最简单的用法是kill 进程号，但有时候进程比较顽固，单次kill无效。后来我了解到，kill其实是在向进程发送信号，不同信号的含义不同：

• kill -15是礼貌地请求进程退出，给它时间收尾；
• kill -9是强制终结，不让进程做任何善后处理。

我尝试的是先用kill -15，发现那个进程还在；最后只能上kill -9，效果立竿见影。后来我学到一句经验口诀：“平时能用15就不用9，只有实在退不出去才强制。”因为直接强杀可能导致文件损坏或配置未保存，这种风险还是尽量避免。

6.3 观察资源占用：top 初体验

除了ps，我还试了另一个命令top。top会动态刷新显示当前系统资源占用情况，类似Windows的任务管理器。第一次进去时，我被页面上花花绿绿的数据弄花了眼，但这些数据里最关键的两栏是CPU占用和内存占用。如果某一栏一直居高不下，就说明有进程在消耗大量资源，需要重点关注。

退出top的方式是按q键，这一点是我折腾了好一会儿才发现的……当时差点把终端直接关掉重启，实在有点丢人。

7. 目录结构：读懂了它就读懂了大半个系统

7.1 从“文件都在哪”到“为什么这么放”

第三天下午，我决定不再东一榔头西一棒槌地乱敲命令了，而是认真把Linux的目录结构底朝天看一遍。因为一整天都在各种路径之间跳来跳去，如果不知道每个目录的基本用途，永远只能靠死记硬背。

Linux的根目录是/，所有路径都从它开始。我把顶层目录列举了一遍：

ls /

在我这个系统里，显示出来的目录有bin、boot、dev、etc、home、lib、media、mnt、opt、proc、root、run、sbin、srv、sys、tmp、usr、var。每个目录名都不长，但背后承载着不同的职责。

我花了一个下午的时间，逐一进入这些目录查看内容。比如/bin里放的是系统运行所需的基本命令，/usr里是用户安装的软件，/var是经常变化的数据，比如日志和缓存，/tmp是临时文件，/home是普通用户的家目录。

7.2 一个值得养的“家目录”习惯

在家目录里，我给自己建了一个专用的练习文件夹，以后所有临时测试都放在这里，不去污染系统目录：

mkdir -p ~/lab/logs

mkdir -p的意思是连同上级目录一起创建，如果~/lab不存在，也会一并建出来。我在这个目录下创建了一些测试文件、脚本草稿，以及一些从网上复制下来的练习代码。

养成“所有实验都在自己家目录里做”的习惯，可以避免很多安全问题。比如，如果某个文件误删了，至少不会影响到系统级文件。对于自学者来说，这一点尤其重要，因为我们动手试错的机会非常多，而试错的代价不应该由整个系统来承担。

7.3 用 find 找文件，比眼睛靠谱

下午我一度忘记某个测试脚本放在哪个子目录里了。在Windows下我可能会打开资源管理器一个个文件夹翻，但在Linux终端里，我学会了更高效的方案：

find ~/lab -name "*.sh"

这条命令会在~/lab目录下查找所有以.sh结尾的文件。find的粒度可以很细，可以按名字、按类型、按大小、按修改时间来找文件。对新手来说，只要会用-name这一个参数，就已经能解决大多数“我文件呢？”的问题了。

8. 文本处理三兄弟：grep、awk、sed 的前世今生

8.1 grep：在垃圾堆里找针眼

第三天遇到的问题里，有相当一部分可以归结为“信息太多，难以定位”。比如某个配置文件里有几十行内容，但我只想知道其中和端口有关的那几行。这时候grep就派上了用场：

grep "listen" /etc/nginx/nginx.conf

grep会逐行读取文件内容，把包含指定关键词的行打印出来。我当时看到输出里确实有listen开头的几行，才确认端口配置的位置。这个命令在排查日志、检查配置、过滤命令输出时几乎是无处不在的。

我还学了一个特别常用的组合用法：在查看某个软件运行状态时，如果输出内容太多，可以接一个管道符，再交给grep过滤。管道符用|表示，意思是“把前面命令的输出结果，交给后面的命令继续处理”。比如：

ps aux | grep nginx

这一条命令能直接把进程列表里跟nginx相关的行挑出来，不用在一堆数据里慢慢找了。

8.2 awk：按列拆数据的好手

如果说grep是“按行筛选”，那么awk对我来说更像“按列拆数据”。比如我想知道日志文件里每一行的第一列是什么，我可以这样操作：

awk '{print $1}' /var/log/nginx/access.log

这个命令会读取文件每一行，然后打印出第一个字段。awk支持的逻辑远不止这些，但它对第三天的我来说，已经是一个“能看懂输出里每一列代表什么”的得力工具了。整个过程就是从原始数据中抽出一列来看，有点像Excel里只保留某一列一样。

8.3 sed：批量替换配置的利器

一开始我修改配置都是用文本编辑器手动改，后来发现遇到多个相似配置需要改动时，手动编辑实在太慢。于是我开始接触sed的替换功能。

sed最常用的一个小片段是：

sed -i 's/旧内容/新内容/g' 文件名

-i表示直接修改文件，s是替换动作，g表示全局替换。意思就是把文件里所有“旧内容”全部替换成“新内容”。我在调整nginx默认端口时，就是用这条命令把80换成了其他端口，非常方便。

但我后来也发现，sed的替换是纯文本层面的，如果你把某个路径写成变量形式，用它就不太方便。对于新手来说，先把这三个命令各自最核心的用法掌握住，就足以应付日常操作了，不必一开始就追求所有高级功能。

9. 服务器配置的第一次完整闭环

9.1 改配置之前，先备份

下午我觉得对系统有点感觉了，开始尝试修改nginx的默认配置，比如更换监听端口。第一次改之前，我犯了一个几乎每个新手都会犯的错误：忘记备份。

后来我重新把配置文件复制了一份：

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

这样做的意义在于，一旦修改出错导致服务起不来，我可以立刻用备份文件还原并重新加载。经历过一次“改了配置导致服务崩溃”之后，我就把“先备份再修改”刻进了肌肉记忆。

9.2 验证配置是否正确

在修改完配置之后，我没有直接重启服务，而是先执行了：

sudo nginx -t

这条命令会检查配置文件的语法是否正确。输出如果显示类似“syntax is ok”的提示，说明配置至少没有格式问题。这个步骤极其重要，因为如果配置有语法错误，直接重启服务会把服务搞挂，导致网站暂时无法访问。先验证，再重启，是降低风险的标准操作。

9.3 重新加载配置，而不是粗暴重启

我一开始不知道“重启”和“重新加载”的区别，直接用了systemctl restart nginx。后来才知道，对于配置变更类操作，更稳妥的方式是用reload：

sudo systemctl reload nginx

reload会让服务在不停机的情况下读取新的配置文件，平滑生效。而restart则是先停止再启动，过程中会有一段短暂的中断。对本地测试来说差别不大，但如果以后部署真正的线上服务，这个区别就会变得非常重要。

整套流程走下来，我算是把“修改配置、验证配置、重新加载配置、查看日志确认效果”这条链路完整跑通了一遍。这个闭环看起来简单，但确实是我学Linux以来第一次独立完成的一件“正事”。

10. 第三天踩坑实录：三个最容易卡住新手的细节

10.1 写错了路径，还以为是命令不对

我至少浪费了二十分钟在一个问题上：输入nginx提示找不到命令，但软件明明已经安装好了。后来发现，原来当前的用户环境变量里没有包含/usr/sbin这个路径，所以直接输入命令名时找不到它，必须用完整路径/usr/sbin/nginx来执行。

解决方式有两种，一种是用完整路径执行，另一种是把该路径加入环境变量。对新手来说，优先使用完整路径更简单、更安全，也能避免影响系统全局配置。

这个坑的通用教训是：命令提示找不到时，不要马上怀疑软件没装好，先用which 命令名或者ls /usr/bin/命令名查一下实际位置。

10.2 端口被占用，改配置还不够

有一次我改了nginx监听端口，以为重启之后必然生效，结果访问还是失败。日志显示“端口已被占用”。我后来才意识到，可能有其他程序占用了我要使用的端口。解决办法是先确认占用端口的进程：

sudo lsof -i :8080

或者用：

sudo ss -tuln | grep 8080

lsof能列出占用该端口的进程详情，ss -tuln则是查看端口监听状态的常用命令。找到占用进程后，要么关掉它，要么换一个别的端口，问题就迎刃而解了。

10.3 改了配置没生效

这个问题困扰了我很久：配置文件明明改对了，服务也重新加载了，但访问结果还是老样子。最后发现，是因为浏览器有缓存，我看到的其实是旧页面。清掉浏览器缓存之后再访问，新页面立刻就出来了。

这件事的启示是：问题不一定出在系统端，有时候是你自己的“查看方式”有缓存。排查问题时，不要只盯着终端，也要考虑外部因素。

11. 自我复盘与新手心法

11.1 第三天结束时，我到底掌握了什么

我给自己列了一份清单，把当天学到的东西做了一个汇总。这个习惯是从前两天开始养成的，每天结束前都把零散的知识点收拢一遍，第二天回顾时会特别有用。

• 文件系统结构：明白每个主要目录的职责；
• 软件包管理：apt update、apt install、apt remove；
• 服务管理：systemctl start/stop/status/reload；
• 权限体系：chmod和chown的基本用法；
• 日志排查：tail -f、grep查看日志关键词；
• 进程管理：ps aux、kill、top；
• 文本处理：grep过滤、awk取列、sed替换。

说实话，这些内容放在老手眼里，全是基本功中的基本功。但对于三天前的我来说，Linux还是一个“黑乎乎的、不知道点哪里才能运行程序”的系统。能走到这一步，我自己是比较满意的。

11.2 允许自己慢下来，反而学得更快

学Linux的第三天，我最深的心得是：不要急着一天就掌握所有命令。命令是无穷无尽的，而且每条命令都有几十个参数，想把它们全部记住根本不现实。更有效的办法是遇到一个问题，去查解决方案，然后动手做一遍，做的时候自然而然就记住了最常用的部分。

我举个例子：如果我只背“mkdir是创建目录的”，不实际去建几次目录，那我永远不会有“用-p创建多级目录”的需求和认知。只有当我遇到“一次性创建a/b/c三层目录”的场景，才发现单用mkdir会提示父目录不存在，然后一查，原来有mkdir -p这个参数。这种“先踩坑再补齐”的学习路径，虽然慢，但记忆非常牢固。

所以如果你也在自学Linux，不要被那些一天速成、三十天精通之类的说法吓住。每个人的知识背景不同，有的人用Linux时间很长，自然上手快；有的人和我一样是零基础转过来，那就允许自己一天只弄懂一个概念，只要坚持，一定会越走越顺。

11.3 把错误记录成日志，形成自己的排错手册

从第三天开始，我养成了一个习惯：每次遇到报错，不仅把解决方案记录下来，还把当时的错误提示原文也记录下来。比如：

• “Permission denied” 对应的是什么场景下发生的？
• “command not found” 是在键入哪个命令时出现的？
• “Address already in use” 最终是怎么解决的？

我用最简单的文本文件把这些信息保存起来，按日期和关键词分类。这个文件虽然很简陋，但它是我真正亲身踩坑换来的资料。以后如果再遇到类似问题，直接查阅自己的记录，比在网上重新搜索要高效得多。

12. 第三天结束时，我给自己的下一个任务

12.1 从“会敲命令”到“能解决问题”

第三天结束前，我给自己设计了一个小挑战：写一个简单的shell脚本，把每天要做的环境检查动作自动化。这个挑战对我来说有点超前，因为脚本语法我还不太熟，但我觉得有挑战才有进步。

脚本内容也不复杂，就是每天打开终端后执行几条检查命令，包括查看IP地址、查看服务状态、查看磁盘占用、查看内存占用。我发现这些操作我每天都要重复做，干脆用脚本把它们串起来。这个想法虽然简单，但让我第一次体会到“用Linux去自动化Linux操作”的感觉。

脚本大概是这样的：

#!/bin/bash echo "当前登录用户：$(whoami)" echo "当前IP地址：" ip addr show | grep inet echo "nginx服务状态：" systemctl status nginx echo "磁盘使用情况：" df -h

写完之后，我用bash 脚本名执行了一下，看到一串信息依次输出，虽然还不懂每一行背后的原理，但至少我知道，自己已经在用程序员的思路来使用系统了。

12.2 给自己定下第四天的主题

第三天的核心是“把服务跑起来、把日志看懂、把权限理顺”。第四天，我打算围绕“脚本化和自动化”继续深入，学一学变量、条件判断和循环这些基础语法，把今天这个简单脚本扩展成真正能帮我干活的工具。

我给自己定的方向不是去啃大部头教材，而是继续沿用“解决实际问题驱动学习”的方式。哪个环节不顺手，就去查资料搞懂哪个环节。这个过程不需要多么高深的理论支撑，只要前期每一步都走得扎实，后面自然会顺畅起来。

从第三天早晨对着终端不知所措，到第三天晚上能自己写一个简单的检查脚本，这种变化其实是真实且踏实的。Linux并没有传闻中那么可怕，只是它需要你换一种方式去理解“用电脑”这件事：你不再只是点按钮的人，而是逐步变成告诉系统“该干什么”的人。这条路才刚开始，但方向已经清楚了。