AI生成浏览器操作系统：单文件HTML实现桌面环境与持久化文件系统
1. 项目概述：一个由AI“种”出的浏览器操作系统
最近在GitHub上闲逛，发现了一个让我这个老前端下巴差点掉下来的项目——JISHENG OS。这玩意儿本质上是一个完整的、具备持久化能力的操作系统，但它就只是一个HTML文件。没错，一个index.html，双击用浏览器打开，一个功能齐全的桌面环境就蹦出来了。更离谱的是，根据项目作者“蓝龙虾”的说法，这个项目的每一行代码，从开头的<!DOCTYPE html>到复杂的窗口管理逻辑，都不是人手敲出来的，而是完全通过向AI模型描述意图，由AI生成代码迭代出来的。
这听起来像天方夜谭，但当你真正把它下载下来，拖几个文件进去，关掉浏览器再打开，发现文件还在；当你打开内置的虚拟机，在里面又启动了一个操作系统时，那种“套娃”般的震撼感是实实在在的。它不是一个CSS皮肤玩具，而是一个拥有真实文件系统、窗口管理器、应用套件甚至虚拟机环境的“浏览器中的浏览器OS”。今天，我就来深度拆解一下这个项目，看看它到底是怎么实现的，以及这种“零手写代码”的开发模式，给我们这些老码农带来了哪些冲击和启发。
2. 核心架构与设计哲学解析
2.1 为什么是“单文件HTML”？
看到“单文件操作系统”，很多人的第一反应可能是性能或复杂度问题。但JISHENG OS选择这个形式，恰恰体现了其核心设计哲学：极致的可移植性与零部署成本。
传统的Web应用，尤其是复杂的单页应用（SPA），离不开npm install、webpack打包、依赖管理等一系列工程化流程。而JISHENG OS反其道而行之，将所有依赖（第三方库、样式、脚本、甚至图标字体）全部内联或通过CDN引入，最终凝结成一个HTML文件。这样做有几个显著优势：
- 开箱即用：用户无需安装任何环境，不需要Node.js，不需要HTTP服务器。直接下载文件，用浏览器打开，系统即启动。这极大地降低了体验门槛。
- 版本即文件：整个系统的状态就是一个文件。分享、备份、回滚变得异常简单——复制这个HTML文件即可。
- 规避构建复杂性：没有构建步骤，意味着没有因工具链版本、配置差异导致的环境问题。开发（或者说“引导AI开发”）的焦点可以完全集中在功能逻辑本身。
当然，代价也是有的。一个超过万行、包含大量内联资源的HTML文件，在文本编辑器里打开会非常卡顿，代码可读性对“人”来说几乎为零。但这似乎恰恰印证了项目的主题：这本来就不是给人阅读和维护的代码，它是AI生成的一个可运行的“制品”。
2.2 持久化文件系统的基石：BrowserFS + IndexedDB
一个操作系统，灵魂在于文件系统。浏览器环境本身是沙盒化的，传统上我们只能用localStorage（容量小，仅键值对）或IndexedDB（容量大，但API是NoSQL的，没有文件树概念）。JISHENG OS的核心魔法在于引入了BrowserFS。
BrowserFS是一个用JavaScript实现的、可挂载多种后端存储的文件系统库。你可以把它理解为一个“文件系统模拟器”。在JISHENG OS中，BrowserFS被配置为使用IndexedDB作为其后端存储。
这里面的技术细节值得深挖：
- 文件系统语义：BrowserFS提供了完整的POSIX风格API（如
fs.readdir,fs.writeFile）。这意味着在JISHENG OS内部，操作文件（创建、读取、写入、移动、删除）的代码，看起来和Node.js环境下的非常相似。 - 持久化与容量：数据实际存储在浏览器的IndexedDB中。其容量通常是用户磁盘的很大一部分（不同浏览器策略不同，但通常可达数百MB甚至数GB），远超
localStorage的5MB限制。并且，只要用户不主动清除网站数据，这些文件就会一直存在，实现了“关闭浏览器，明天回来文件还在”的承诺。 - 内核存活：所谓的“内核存活”，其实就是指BrowserFS的文件系统实例及其在IndexedDB中的数据，在页面刷新后能够被重新正确初始化并挂载。JISHENG OS在启动时，会初始化BrowserFS，并尝试从IndexedDB中加载上一次的文件系统状态，从而实现了系统状态的持久化。
实操心得：在调试这类重度依赖IndexedDB的应用时，浏览器的开发者工具（F12）中的“Application”标签页下的“IndexedDB”和“Storage”部分是你的主战场。你可以在这里直观地看到文件系统的“数据库”内容，手动清除数据以测试初始化逻辑，或者排查数据读写异常。
2.3 虚实交互：文件拖放与物理文件夹挂载
如果只是浏览器内部自娱自乐，那还称不上惊艳。JISHENG OS实现了虚拟世界与真实物理世界的双向文件交互。
1. 虚拟文件拖出到物理桌面：这利用了浏览器的“下载”API。当你在JISHENG OS中长按一个文件图标，触发拖拽时，系统会：
- 通过BrowserFS读取该文件的二进制内容。
- 在拖拽事件中，创建一个指向内存中文件Blob对象的
URL.createObjectURL。 - 通过设置
DataTransfer对象的items和files属性，浏览器会将其识别为一个可拖出到系统文件管理器（桌面）的“文件”。当你松开鼠标，浏览器会触发下载流程，将文件保存到你放置的位置。
2. 物理文件拖入到虚拟桌面：这更直接一些，监听桌面区域的drop事件。当用户从系统文件管理器拖入文件时，浏览器会提供File对象列表。JISHENG OS遍历这些File对象，通过BrowserFS的API将其写入虚拟文件系统的对应路径下。
3. 物理文件夹挂载（File System Access API）：这是更高级的特性，依赖于较新的File System Access API。这个API允许Web应用在获得用户明确授权后，直接访问用户设备上的特定文件夹（或文件）。
- 授权与持久化：用户通过一个选择器对话框授权JISHENG OS访问某个物理文件夹。关键点在于，这个API支持将授权句柄（一个权限令牌）序列化后保存到IndexedDB中。这意味着用户只需授权一次，即使刷新页面，JISHENG OS也能从IndexedDB中恢复这个句柄，重新获得该文件夹的访问权限，无需再次弹窗询问。
- 双向同步：挂载后，JISHENG OS可以监听该物理文件夹的变化（需要一定的轮询或使用更高级的API），并在虚拟文件系统中创建一个“镜像”入口。在虚拟系统中对镜像文件的操作（如修改），可以通过API直接写入物理文件，反之亦然。这实现了深度的系统集成感。
注意事项：File System Access API目前仅在基于Chromium的浏览器（如Chrome、Edge）中得到较好支持。在Firefox或Safari中，此功能不可用。因此，JISHENG OS的相关功能需要做兼容性检测和降级处理（例如，降级为单文件拖入）。
3. 核心功能模块深度拆解
3.1 窗口管理系统的实现
在浏览器里实现一个类似Windows或macOS的窗口管理器，需要处理大量底层交互逻辑。JISHENG OS的窗口系统支持拖动、缩放、最小化、置顶等功能，其实现可以拆解为以下几个层面：
1. DOM结构与样式：每个窗口本质上是一个绝对定位（position: absolute）的<div>容器。窗口标题栏、内容区、边框控制点都是这个容器内的子元素。通过CSS的backdrop-filter: blur(40px)实现了所谓的“超玻璃态”毛磨砂效果，这是现代操作系统视觉风格的体现。
2. 拖动逻辑：
- 事件监听：在标题栏的
mousedown（或touchstart）事件中，记录下鼠标/触摸点相对于窗口当前位置的初始偏移量（offsetX,offsetY）。 - 实时更新：随后监听
document的mousemove（或touchmove）事件。在事件回调中，根据当前鼠标/触摸点的全局坐标，减去初始的偏移量，动态计算并设置窗口的left和topCSS属性，实现跟随拖动。 - 释放：在
document的mouseup（或touchend）事件中，移除移动监听器。这里要特别注意事件冒泡和防止文本被选中（user-select: none）等细节。
3. 缩放逻辑：通常在窗口的右下角或边框放置一些小的<div>作为缩放手柄。
- 监听手柄的
mousedown事件，记录初始窗口的宽高和鼠标位置。 - 在
mousemove事件中，计算鼠标移动的差值（deltaX,deltaY），将其加到窗口的初始宽高上，并同时更新窗口的width、height以及可能需要的top/left（如果是从左上角缩放）样式。 - 需要设置
min-width和min-height来防止窗口被缩得过小。
4. 窗口栈与聚焦管理：所有窗口对象在一个全局数组（栈）中维护。当点击一个窗口时，将其从数组中移除并推入数组末尾（或置顶），同时通过CSS的z-index属性确保其显示在最上层。被激活的窗口通常会有不同的边框样式以示区分。任务栏的窗口图标列表就是这个栈的可视化体现。
5. 性能优化：频繁的mousemove事件和DOM样式更新可能引发性能问题。一个常见的优化是使用requestAnimationFrame来节流位置更新，确保重绘与浏览器的刷新率同步，避免卡顿。
3.2 内置应用套件的技术选型
JISHENG OS集成了多个实用应用，它们大多是基于成熟的第三方库进行封装集成：
| 应用 | 核心库/技术 | 关键实现点 |
|---|---|---|
| 浏览器 | iframe+ 站点白名单 | 现代网站普遍禁止被嵌入iframe（通过X-Frame-Options或Content-Security-Policy）。JISHENG OS的解决方案是维护一个已知可嵌入的站点白名单，并利用一些“技巧”，如Google搜索的旧版参数（?igu=1）来绕过限制。这更像是一个“互联网考古”展示柜。 |
| 记事本 | textarea或contenteditable | 核心是文本的读写。通过BrowserFS API打开/保存文本文件。难点在于实现“另存为”功能，这需要创建一个新的文件节点并写入内容。 |
| 画图 | HTML5 Canvas API | 监听鼠标/触摸事件在Canvas上绘制路径。实现压力感应需要处理PointerEvent的pressure属性（支持触控笔的设备）。导出PNG则是将Canvas的toDataURL(‘image/png’)生成的数据，通过BrowserFS写入文件。 |
| 计算器 | JavaScripteval（需谨慎）或数学表达式解析器 | 实现一个安全的计算器，绝不能直接使用eval处理用户输入，否则是严重的安全漏洞。需要自己实现或引入一个数学表达式解析库（如math.js）来安全地求值。 |
| PDF阅读器 | pdf.js(Mozilla) | PDF.js是一个将PDF渲染为Canvas的Web标准解决方案。JISHENG OS需要将其库文件内联或CDN引入，并提供一个iframe或直接嵌入的容器来展示PDF。处理翻页、缩放、文本选择等交互。 |
| HTML编辑器 | CodeMirror 或 Monaco Editor | 提供了代码高亮、缩进、折叠、查找替换等专业编辑器功能。JISHENG OS需要将其与文件系统对接：打开时从文件读取内容填充编辑器，保存时将编辑器内容写回文件。 |
| 虚拟机 (V86) | v86 (WebAssembly x86 模拟器) | 这是最“疯狂”的部分。v86是一个用WebAssembly编译的x86 PC模拟器。JISHENG OS需要配置v86（指定内存、CPU、虚拟硬盘镜像等），并将其输出的模拟VGA画面渲染到一个<canvas>上，同时将键盘、鼠标事件转发给模拟器。 |
避坑指南：集成多个大型第三方库到一个HTML文件中，最大的挑战是命名冲突和资源加载顺序。所有库的代码都被压缩并内联到同一个全局作用域下，如果两个库都使用了类似
$或_的全局变量，或者修改了原生原型，很容易发生冲突。AI在生成代码时，必须非常小心地处理库的封装（例如使用IIFE立即执行函数表达式）或选择兼容性好的构建版本。
3.3 漫画阅读器与归档引擎的巧思
漫画阅读器的功能看似简单，但要做好体验，细节很多：
- 目录扫描：当用户打开一个图片文件时，阅读器需要自动定位该文件所在虚拟目录，并使用BrowserFS的
fs.readdir列出所有文件。 - 自然排序：简单的字符串排序会把“10.jpg”排在“2.jpg”前面。需要实现一个“自然排序”算法，将文件名中的数字部分提取出来进行数值比较，才能得到“1, 2, 3, …, 10”的正确顺序。
- 无限滚动与预加载：为了实现Webtoon式的流畅阅读，需要监听滚动事件。当用户滚动到接近当前已加载图片的底部时，异步加载下一批图片。同时，可以预加载当前视口上下方的几张图片，以提升体验。
- 全屏沉浸：通过浏览器的Fullscreen API (
element.requestFullscreen())实现，并隐藏所有OS自身的UI元素，只保留图片。
归档引擎则展示了在浏览器端处理压缩文件的能力：
- ZIP格式：使用JSZip库，这是一个纯JavaScript的ZIP文件处理库，可以解压和创建ZIP文件。
- 其他格式 (RAR, 7z, Tar等)：这里用到了一个更强大的工具——7z-wasm。这是著名的7-Zip压缩工具的WebAssembly移植版。通过它，浏览器获得了处理多种压缩格式的能力。
- 工作流程：用户将一个
.rar文件拖入虚拟系统 → JISHENG OS通过BrowserFS读取该文件的ArrayBuffer → 将ArrayBuffer传递给7z-wasm的解压模块 → 模块返回解压后的文件列表和各自的数据 → JISHENG OS将这些文件通过BrowserFS写入到用户指定的目标目录。整个过程完全在浏览器沙盒内完成，无需服务器中转。
4. “零手写代码”的开发流程探究
这是JISHENG OS项目最引人争议和思考的部分。作者声称“零手写代码”，并非指项目没有代码，而是指代码的创作主体是AI。根据项目提交历史，我们可以推测其开发模式：
4.1 迭代式AI提示工程
这绝非一次性的魔法指令。66次提交，历时3个月，从v1.0到v10.5.1，描绘了一个典型的迭代式AI辅助开发过程。
- 从零到一（搭建骨架）：最初的提示词可能是：“创建一个单HTML文件的浏览器桌面环境，包含一个可以拖动的窗口和一个简单的文件列表。”AI会生成一个包含基础HTML结构、CSS样式和JavaScript事件绑定的代码块。
- 功能追加（描述意图）：随后，作者会基于现有代码提出新需求：“在刚才的桌面环境中，增加一个功能：当用户从本地电脑拖拽一个图片文件到桌面区域时，将这个图片显示在桌面上。”AI需要理解现有代码的上下文，并生成能够集成文件拖放API和图片预览功能的代码。
- 问题修复与优化（调试反馈）：生成的代码很可能有bug或性能问题。作者会向AI反馈：“窗口拖动时很卡顿，如何优化？”或者“解压RAR文件的功能在Safari浏览器中报错，如何做兼容性检测？”AI则根据这些具体问题，提供修改建议或代码片段。
- 代码重构与组织：随着功能增多，单文件代码会变得极其臃肿。作者可能会提示AI：“将文件系统操作的相关函数提取到一个单独的、逻辑统一的模块中，并保持整体仍为单文件。”这要求AI具备一定的代码重构和架构理解能力。
4.2 人类扮演的角色：架构师与测试员
在这个过程中，人类开发者（作者）的角色发生了根本性转变：
- 从“码农”到“需求架构师”：他的核心工作不再是敲击键盘实现具体函数，而是精确地定义问题、描述场景、拆解功能模块。他需要有一个清晰的系统架构蓝图在脑中。
- 从“调试者”到“系统测试员与提示词调优师”：他需要运行AI生成的代码，发现不符合预期或错误的地方，然后将这些现象转化为更精确的提示词，反馈给AI进行修正。这更像是在训练和引导一个具有强大代码生成能力的“实习生”。
- 版本控制与决策：他仍然需要管理Git提交，决定哪些AI生成的代码可以接受并合并，哪些需要打回重做。他掌控着项目的最终方向和代码质量底线。
4.3 技术可行性与局限性分析
可行性：当前最先进的大语言模型（如GPT-4、Claude 3等）在代码生成、理解和补全方面已经非常强大。对于实现已知模式、集成成熟库、完成特定功能片段的任务，它们确实可以生成高质量、可运行的代码。JISHENG OS项目就是一个活生生的证明，它涉及的许多技术点（BrowserFS、拖放API、Canvas绘图）都有丰富的在线文档和示例，正是AI学习的绝佳材料。
局限性：
- 复杂状态与交互逻辑：窗口管理器中窗口叠放次序、焦点状态、任务栏同步等涉及复杂状态管理的部分，AI可能难以一次性生成完美逻辑，需要多次迭代和人工干预修正边界条件。
- 性能优化与底层调试：当遇到拖动卡顿、内存泄漏等深层性能问题时，AI生成的通用优化建议可能不够对症。最终仍需开发者凭借经验，使用性能分析工具定位瓶颈。
- 代码风格与架构一致性：在漫长的迭代中，不同时期、针对不同功能生成的代码，其风格、变量命名习惯、错误处理方式可能不一致。后期需要大量的人工整理或通过强约束的提示词来统一。
- 创新与未知问题：AI擅长组合已知模式，但对于解决前所未有的、需要真正“创新”算法的问题，其能力仍有待观察。JISHENG OS中那些巧妙的设计（如持久化文件夹句柄）其核心思路很可能仍来源于人类。
5. 实战：尝试运行与扩展思路
5.1 如何本地运行与体验
- 获取文件：访问项目GitHub仓库（github.com/SFGFDSD/JISHENGOS），直接下载
index.html文件。由于国内网络环境，如果GitHub访问不畅，可以尝试使用Gitee镜像或开发者加速服务。 - 运行环境：强烈建议使用最新版的 Chrome 或 Edge 浏览器。因为它们对File System Access API、WASM等现代Web特性支持最完整。用浏览器直接打开下载的
index.html文件（可以通过双击，或拖入浏览器窗口）。 - 基础操作：
- 拖入文件：直接从你的电脑桌面或文件夹，拖拽任意文件（图片、文本、压缩包）到JISHENG OS的桌面区域。你会看到文件图标出现。
- 文件操作：右键点击文件或桌面，可以新建文件夹、重命名、删除。试试框选（鼠标拖拽出矩形）多个文件，或者按住Ctrl键点选多个文件。
- 打开应用：双击“此电脑”或桌面上的应用图标。试试用画图画点东西，然后保存到桌面。
- 体验持久化：随意操作一番后，直接刷新浏览器页面（F5）。你会发现，桌面状态、你创建的文件、打开的应用位置，几乎都恢复了。
- 高级玩法：
- 挂载真实文件夹：在文件管理器里，找找“挂载本地文件夹”之类的选项（可能需要右键菜单或设置里）。授权选择一个本地文件夹。之后，这个文件夹就会以“驱动器”的形式出现在虚拟系统中，实现双向同步。
- 启动虚拟机：打开V86虚拟机应用。你需要一个操作系统镜像文件（例如，一些开源的小型DOS或Linux的磁盘映像
.img文件）。将这个.img文件拖入JISHENG OS，然后在V86应用里配置镜像路径并启动。你就能在浏览器里的操作系统里，再运行一个操作系统了。
5.2 可能遇到的问题与排查
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 页面打开空白或控制台报错 | 1. 浏览器安全策略限制（直接打开本地HTML文件时，某些API受限）。 2. CDN资源加载失败（网络问题）。 | 1. 尝试使用本地HTTP服务器启动。最简单的方法：在index.html所在目录打开命令行，运行npx serve .(需安装Node.js) 或python3 -m http.server，然后通过http://localhost:端口访问。2. 检查网络，或尝试使用能访问国际网络的网络环境。 |
| 文件拖入无效 | 浏览器不支持或限制了本地文件的直接访问。 | 确保使用Chrome/Edge，并检查浏览器设置中是否禁用了相关功能。尝试通过“挂载文件夹”功能替代。 |
| 虚拟机启动黑屏/报错 | 1. 镜像文件不兼容或损坏。 2. WASM未成功加载。 | 1. 尝试使用项目Wiki或社区推荐的、经过测试的小型镜像文件（如FreeDOS）。 2. 查看浏览器控制台是否有WebAssembly相关错误。 |
| 操作卡顿明显 | 1. 浏览器硬件加速未开启。 2. 系统资源占用过高（如虚拟机运行中）。 | 1. 在浏览器设置中开启“使用硬件加速”。 2. 关闭不必要的应用，尤其是虚拟机。浏览器内模拟x86是计算密集型任务。 |
5.3 扩展思路：如果你来“提示”AI改进它
JISHENG OS已经是一个功能丰富的演示，但作为一个“操作系统”，它还有巨大的扩展空间。如果你来引导AI进行下一步开发，可以从哪些方向入手？
- 应用生态：
- 提示词：“在现有的HTML编辑器中，集成一个简单的静态HTTP服务器功能。当用户点击‘运行’时，能在浏览器内新标签页中预览当前编辑的HTML页面。”
- 提示词：“为系统添加一个‘应用商店’面板，允许用户从一个预设的URL列表（指向其他单HTML文件应用）下载并安装新的应用到桌面。”
- 系统集成：
- 提示词：“实现一个系统级的‘通知中心’。当后台任务（如下载完成、虚拟机启动完毕）或应用事件发生时，在屏幕角落弹出非阻塞式通知，并汇总在任务栏的一个图标中。”
- 提示词：“为文件管理器增加文件内容搜索功能。输入关键词，能快速搜索虚拟文件系统内文本文件的内容。”
- 网络能力：
- 提示词：“开发一个简单的FTP客户端应用，允许用户连接远程FTP服务器，浏览和传输文件到虚拟桌面。”
- 提示词：“在设置中增加‘网络驱动器’选项，允许用户通过WebDAV协议挂载远程存储。”
- 用户体验：
- 提示词：“优化移动端触控体验。实现双指捏合缩放桌面图标视图，为触屏优化右键菜单（长按替代）。”
- 提示词：“增加多主题支持（深色/浅色模式），并将主题偏好保存到持久化设置中。”
这些扩展每一个都是不小的工程，但通过拆解为具体的、可描述的模块，并利用AI生成基础实现，再由人类进行集成、调试和优化，是完全有可能逐步实现的。这或许就是未来一种新的“人机协作”开发范式：人类负责高层次的架构设计、需求定义和系统集成测试，AI负责生成实现细节的代码草稿。
6. 对开发者思维的冲击与启示
JISHENG OS项目，与其说是一个炫技的产品，不如说是一个关于“软件开发范式可能如何演变”的强有力实验。它给我们这些传统开发者带来了几个维度的思考：
1. 工具属性的根本性改变：过去，IDE、编译器、调试器是我们的核心工具。未来，自然语言可能成为最直接的“编程接口”。编写精确的提示词（Prompt）的能力，其重要性可能会逼近甚至超越编写特定语法代码的能力。你需要学会如何与AI“沟通”，如何将模糊的需求转化为AI可理解、可执行的步骤描述。
2. 知识重心的迁移：“精通JavaScript数组的28个方法”这种细节记忆的重要性在下降。而系统设计能力、架构权衡意识、调试与问题分解能力的价值在飙升。你需要更清楚“要做什么”以及“为什么这么做”，至于“具体怎么做”的细节，可以更多地交由AI辅助完成。你的价值体现在对问题更深的理解和更优的解决方案设计上。
3. 原型验证的加速：像JISHENG OS这样的复杂概念原型，在过去需要一个熟练的前端工程师数周甚至数月的密集开发。而在AI辅助下，这个周期被极大地压缩。这允许开发者用极低的成本快速验证天马行空的想法，将精力更多地集中在创意和创新本身，而不是重复的底层编码劳动上。
4. 代码所有权的模糊化：当一个项目的每一行代码都源于AI生成，那么项目的“作者”是谁？是提供创意和提示的人，还是AI模型，抑或是训练AI模型的原始数据的所有贡献者？这带来了新的开源协议、版权和伦理问题。JISHENG OS项目采用MIT许可证，是一个积极的尝试，但更大范围的共识尚未形成。
5. 警惕“黑箱”与技术债：完全依赖AI生成代码，最大的风险是引入“黑箱”。你可能并不完全理解一段复杂代码是如何工作的，这会给后期的调试、维护和安全性审查带来巨大挑战。AI生成的代码也可能存在隐藏的低效模式或潜在的边缘情况Bug。因此，严格的代码审查、测试和必要的重构，不仅没有过时，反而变得更加重要。你不能当一个“甩手掌柜”。
在我个人看来，JISHENG OS不是一个即将取代传统开发的“未来形态”，而是一个清晰的信号。它标志着AI从一个简单的代码补全工具，进化为了一个能够理解复杂意图、生成完整功能模块的“初级开发伙伴”。恐惧或排斥没有意义。更积极的态度是，像这个项目的作者一样，主动去探索如何与这个强大的新伙伴协作，将我们的创造力从繁琐的实现细节中进一步解放出来，去挑战那些更宏大、更复杂的问题。未来的优秀开发者，或许将是那些最擅长“引导”AI的“导演”或“架构师”。