第8期：AI编程工具从无节制到规范化

CSS Masonry：新一代原生瀑布流布局

CSS Masonry 正在 Chrome 和 Edge 140 及以上版本中进入开发者测试阶段。该特性旨在为 Web 布局带来原生的瀑布流（masonry）能力，解决以往只能依赖 JavaScript 库或复杂 CSS hack 的局限。

Masonry 布局的核心特性

Masonry 布局允许元素像砖块一样紧密排列，自动填补空隙。与 grid、flexbox 或 multi-column 不同，masonry 只在一个方向上有约束，另一方向则“自由呼吸”。例如，图片墙、博客卡片、新闻流等场景，masonry 能最大化利用空间，而无需关心元素的视觉顺序。

举例：想象一条高速公路，每条车道长度和宽度不同，车辆（元素）会尽量靠近起点排列，形成紧凑的队列。

现有方案的局限

目前常见的实现方式包括：

• JavaScript Masonry 库：性能开销大，维护复杂。
• CSS grid/flexbox/multi-column：难以实现自动填补空隙，跨列/跨行支持有限，代码冗长。

这些方案在处理元素跨列、动态排序、响应式调整时，往往需要大量额外代码，维护成本高。

CSS Masonry 的语法与用法

目前规范仍在讨论中，主要有两种语法提案：

1. display: masonry
   直接将容器设为 masonry 布局，结合 grid-template-columns 或 grid-template-rows 定义轨道。

2. display: grid; grid-template-*: masonry;
   在 grid 布局基础上，通过 grid-template-columns: masonry 或 grid-template-rows: masonry 启用 masonry 模式。

Chromium 实现目前采用第一种方案。示例代码如下：

.masonry { display: masonry; grid-template-columns: repeat(auto-fit, minmax(160px, 1fr)); gap: 10px; }

还可通过 masonry-direction 控制主轴方向，或使用 masonry 简写属性一次性定义方向和轨道。

Track 尺寸与默认行为

Masonry 默认采用 repeat(auto-fill, auto) 作为轨道定义，无需手动指定列数或行数。这样可以根据容器宽度自动生成合适数量的轨道，提升布局自适应能力。

进阶特性

• 自定义轨道尺寸：支持不同宽度/高度的轨道组合，灵活适配多样化内容。
• 元素跨轨道：通过 grid-column 或 grid-row 让重要元素跨越多个轨道，突出显示。
• item-tolerance：控制元素在主轴上的容忍度，优化自动排列时的视觉顺序。
• 与 grid 属性兼容：可继续使用 grid-row、grid-column、grid-area 等属性，增强布局表达力。

现阶段限制

当前实现尚不支持 dense packing、reverse placement、subgrid、out-of-flow、baseline、DevTools、fragmentation、gap decoration 等高级特性。开发团队鼓励开发者积极测试并反馈问题，推动规范完善。

反馈与参与

开发者可通过 GitHub issue、社交媒体等渠道参与规范讨论，帮助 CSS Masonry 走向成熟。

Masonry布局的现状与实现方法

当前，CSS原生Masonry布局的标准尚未统一。主流方案有三种：display: masonry、grid-template-rows: masonry、item-pack: collapse。Firefox已支持第二种语法，Chrome正在测试第一种，但各浏览器实现不一致，导致生产环境难以直接采用。

兼容性方案与核心思路

为实现跨浏览器的Masonry布局，作者提出了一种仅需66行JavaScript的方案。其核心流程如下：

• 通过CSS Grid定义列数，设置grid-auto-rows: 0px和row-gap: 1px，让每个网格项初始高度为零。
• 使用JavaScript获取每个网格项的实际高度（getBoundingClientRect），并动态设置gridRowEnd，让每个项根据内容高度自动跨越合适的行数。
• 通过读取column-gap，将其与实际高度相加，确保行间距与列间距一致，视觉效果统一。

细节处理与健壮性

• 方案支持任意列数，单个网格项可跨多列。
• 在布局前，需等待图片或视频等媒体资源加载完成，否则高度计算会出错。通过Promise.all结合自定义的areImagesLoaded和areVideosLoaded函数实现。
• 为保证响应式，利用ResizeObserver监听容器尺寸变化，自动重新布局。

生产可用性与扩展

该实现方式兼容主流浏览器，且比基于Flexbox的“伪Masonry”方案更灵活。结合Tailwind等工具可进一步提升自定义能力。对于希望快速集成的开发者，可直接使用作者在Splendid Labz开源的相关库。

总结

通过CSS Grid与少量JavaScript的结合，可以在当前浏览器环境下实现高兼容性、响应式的Masonry布局。该方案结构清晰，易于维护，适合有一定前端基础的开发者深入理解与应用。

响应式视频的实现与优化

本页详细探讨了如何在网页中实现高效、响应式的视频嵌入，强调了自托管视频相较于YouTube、Vimeo等平台的优势。作者以实际项目为例，梳理了从视频压缩、格式兼容、响应式布局到性能优化的完整流程。

自托管视频的优势

• 可自定义播放器样式，保持网站设计一致性。
• 避免第三方平台在部分地区被屏蔽的问题。
• 完全掌控视频压缩与质量的权衡。
• 无需遵循外部内容审核政策。
• 更易与自有CMS集成。

视频压缩与格式选择

作者通过Handbrake将1.5分钟的4K MP4视频压缩为7MB的WebM文件，极大减小了体积。WebM格式在全球主流浏览器中已获得广泛支持，但部分地区（如德国）仍需兼容MP4。MP4压缩时建议使用Handbrake的“Web Optimized”选项，以提升加载体验。

响应式视频的HTML结构

通过<video>标签配合多个<source>，可根据viewport的宽高比自动切换横屏或竖屏视频。例如：

<video>
  <source src="vertical.webm" media="(max-aspect-ratio: 1 / 1)" />
  <source src="horizontal.webm" />
</video>

这种方式无需JavaScript即可实现基础的响应式切换。

多分辨率与多格式支持

为适配不同设备和网络环境，作者建议为每种方向和格式分别生成多种分辨率的视频文件。实际项目中，作者为每种方向、格式、分辨率和像素密度共生成了84个<source>标签。虽然数量庞大，但能有效减少不必要的数据传输，提升加载速度。

CSS与布局优化

为避免内容抖动，推荐通过CSS的aspect-ratio属性为视频预留空间。例如：

video { aspect-ratio: var(—aspect-ratio, var(—vertical-aspect-ratio, 9 / 16)); } @media (min-aspect-ratio: 1 / 1) { video { —aspect-ratio: var(—horizontal-aspect-ratio, 16 / 9); } }

这样可确保视频加载前页面布局稳定。

全屏与动态切换

浏览器不会在切换全屏或调整窗口大小时自动加载更高分辨率的视频。为此，需要监听resize和fullscreenchange事件，手动调用video.load()，并通过防抖处理避免频繁重载。播放进度可通过currentTime属性保存和恢复，但切换时会有短暂卡顿。

poster与懒加载

HTML的poster属性仅支持单一图片，难以实现响应式。可通过JavaScript动态切换poster，或采用高压缩高分辨率图片权衡。视频的懒加载可通过preload="none"实现，避免未播放时浪费带宽。

字幕与辅助功能

建议为视频添加字幕，提升无声环境下的可访问性。<track>标签可用于嵌入字幕文件，label属性有助于用户识别和切换。

自动化与批量处理

手动生成多种格式和分辨率的视频文件效率低下，易出错。可利用Handbrake的命令行工具或Cloudinary等服务实现自动化批量处理，提升生产效率。

结论

自托管响应式视频能带来更优的用户体验和性能表现。通过合理的视频压缩、格式兼容、分辨率适配和布局优化，可以在保证画质的同时显著降低加载压力。对于重视视频内容的网站，这一方案值得投入精力实现。

Still.js：简化前端开发的新选择

Still.js 是一款主打极简主义的前端框架，旨在降低现代 JavaScript 框架的复杂性。它不依赖于繁琐的构建工具或打包流程，开发者可以直接使用原生 JavaScript 进行开发。这种方式让 Still.js 能够与 React、Angular、Vue 等主流框架共存，甚至可以在不干扰旧有代码的前提下，帮助现代化老旧项目。

架构与核心理念

Still.js 采用 Service、Controller 和 View 的架构。Service 负责数据处理和事务（如 HTTP 请求），Controller 管理视图的行为和 DOM 操作，View 则专注于用户界面的展示。整个流程没有打包或编译环节，所有渲染都在运行时完成。模板中 80% 的内容是 vanilla JavaScript，只有少量特殊指令由 Still.js 解释器处理。

状态管理与性能

框架支持本地和全局状态管理。与 React 的虚拟 DOM 不同，Still.js 避免引入额外的抽象层，直接操作真实 DOM。这种方式减少了性能损耗，适合对性能有较高要求的场景。

与主流技术栈的兼容性

Still.js 可以与 Java、ASP、PHP 等后端技术栈集成。它还支持在 React 等框架中嵌入 Still.js 组件，实现微前端架构。开发者可以将 Still.js 组件作为独立前端嵌入现有应用，获得完整的导航和功能支持。

组件与扩展能力

框架内置组件化 UI、HTML 模板、指令、权限管理、路由和表单校验等功能。Still.js 还引入了 vendor components 概念，允许开发者自定义并复用功能组件。此外，Still.js 利用 JSDoc 和 JavaScript 注释，在运行时动态添加特性，实现类型提示和部分 TypeScript 能力。

适用场景与发展现状

Still.js 适合需要模块化、权限管理、组件路由、微前端等企业级应用。它无需依赖 WebPack、Vite 等打包工具，降低了开发和维护成本。虽然框架本身较新，但已具备构建大型复杂应用的能力，且对社区贡献持开放态度。

JavaScript 运行时的多样化演进

过去十年，JavaScript 运行时（runtime）和引擎（engine）数量激增。JavaScript 已经从浏览器扩展到云端、边缘计算、智能电视、移动设备和微控制器等多种环境。每种环境对运行时的需求不同，导致没有一种通用的最佳方案。

边缘计算的兴起

最早的边缘计算方案由 Akamai 在 2002 年推出，但 JavaScript 直到 Node.js（2009）和 AWS Lambda（2014）才进入服务端领域。2017 年，Lambda@Edge 让 JavaScript 首次在边缘运行。随后，Cloudflare Workers 以 Service Worker API 为核心，成为第一个直接产品化的 JavaScript 运行时。Deno、Bun、Wasmer 等新兴项目相继出现，推动了边缘计算领域的多样化。不同运行时背后采用的引擎也各不相同：V8、JavaScriptCore、SpiderMonkey、QuickJS 等各有侧重。

微控制器与极简引擎

微控制器资源极为有限，无法运行完整的 Node.js。为此，Duktape、Espruino、mjs、JerryScript、Moddable、elk 等极简引擎应运而生。这些引擎通常能在 64KB 甚至更小的内存中运行，但在性能等方面做出权衡。部分引擎如 JerryScript、Duktape 还衍生出 IoT.js、low.js 等专为物联网设计的运行时。

Polyglot 引擎与多语言互操作

部分 JavaScript 引擎基于通用虚拟机（如 JVM、.NET），实现与其他语言的无缝互操作。典型如 Rhino、Nashorn、Graal.js（均基于 Java 平台），以及 .NET 的 jint、Python 的 PyNarcissus、Ruby 的 Opal、Go 的 elsa、Rust 的 Boa 等。还有一些项目直接用 JavaScript 实现 JavaScript 引擎，如 Narcissus、Porffor，展示了语言本身的灵活性和生态活力。

原生应用开发

JavaScript 在原生应用开发领域有两大路线：WebView 和跨平台框架。

• WebView 路线：PhoneGap（后开源为 Cordova）、Ionic、Capacitor 等框架通过嵌入 WebView 实现跨平台开发。Electron 和 NW.js 则主导了桌面端，许多主流桌面应用（如 Discord、Slack、VS Code）均基于 Electron。
• React Native 路线：React Native 通过 JavaScript 运行时与原生平台通信，最初采用 JavaScriptCore，后由 Facebook 推出 Hermes 引擎以提升性能。React Native 逐步实现引擎无关化，支持 V8、QuickJS、Chakra、Duktape 等多种引擎。移动端 React Native 应用数量远超 WebView 方案，桌面端则以 Electron 为主。

NativeScript 与 Node.js 的补充

NativeScript 提供 iOS、Android、Windows 的全平台运行时，最初基于 JavaScriptCore 和 V8，后统一为 V8。新架构通过 Node-API 实现引擎无关的 JS↔native 绑定，提升了与主流框架的集成能力。Node.js 虽然主要用于服务端，但也有移动端移植版本，支持多种引擎（如 ChakraCore、JavaScriptCore、JerryScript），但在 GUI 应用开发领域影响有限。

生态与创新

JavaScript 运行时的多样化源于不同场景对性能、启动速度、包体积、API 支持和原生访问能力的不同需求。V8 和 JavaScriptCore 依然主导主流，但 Hermes、QuickJS 等新引擎在特定领域展现出竞争力。健康的竞争推动了技术创新，也为开发者提供了丰富的选择。

附录与新动向

文章还提及了如 Lynx（基于 PrimJS）、LibWeb（Ladybird 浏览器）、gjs、MuJS、JXA、dukluv、Napa.js、txiki.js、Bare、lo.js 等未详细展开的运行时。这些项目进一步丰富了 JavaScript 运行时的生态。

JavaScript 已成为几乎所有设备类型的通用开发语言。不同运行时的出现，是对多样化需求的直接回应，也是技术生态不断演进的体现。

Vibe Code 与 Legacy Code

本文探讨了“vibe coding”与“legacy code”的关系。Andrej Karpathy 首次提出 vibe coding，指的是在 AI 辅助下，开发者几乎不再关注代码本身，更多依赖 AI 生成和维护代码。这种方式让开发者“忘记代码的存在”。

Legacy Code 的本质

Legacy code 通常指无人理解的代码。虽然代码本身还在，但理解和维护变得极其困难。作者指出，代码的可维护性远比代码量更重要。理解一段陌生代码需要大量时间，维护难度高，容易引入新 bug。编程的核心是“theory building”，即构建对系统的理解，而不是单纯产出代码。

Vibe Coding 的适用场景

Vibe coding 适合原型开发和一次性项目。作者举例说明，自己用 vibe coding 快速开发了几个小型应用，这些项目无需长期维护，因此即使代码难以理解也无妨。对于这类项目，vibe coding 能显著提升开发效率。

Vibe Coding 的理解程度光谱

Vibe coding 并非非黑即白，而是一个理解程度的光谱。开发者对代码理解越深，vibe coding 的成分就越少。即使是有经验的工程师，在使用 AI 辅助开发时，也会根据项目复杂度和维护需求调整对代码的把控。

风险与隐喻

让非程序员用 vibe coding 构建大型、需长期维护的项目，风险极高。作者用“给小孩信用卡”作比喻，强调这种做法会带来巨大的技术债务。初期开发顺利，但后期维护会变得异常艰难，甚至需要推倒重来。

AI 时代的严肃开发

对于需要长期维护的严肃项目，作者建议将 AI 视为“过于自信但不够可靠的实习生”。开发者应保持谨慎，严格把控代码质量，利用 AI 辅助学习和提升效率，但不能完全依赖。

Val Town 的实践

Val Town 团队在产品中集成了多种 AI 功能。例如 Townie，可以自动读写代码并持续迭代。作者认为，AI 工具适合 vibe coding，也适合在开发者严格把控下进行精细修改。AI 正在快速改变编程方式，但“theory building”依然是构建复杂系统的核心。

结语

作者提醒，vibe coding 并非万能。对于追求高质量、可维护性的项目，开发者必须主动理解和掌控代码结构。否则，技术债务会迅速积累，最终影响项目的可持续发展。

Gemini CLI 文件丢失事故分析

近期，一位开发者在使用 Gemini CLI 进行文件管理操作时，遭遇了严重的数据丢失问题。事件经过如下：用户原本希望将一个文件夹重命名，并将其中的文件移动到新目录。Gemini CLI 在执行过程中，未能正确创建目标目录，却误以为操作成功，随后执行了文件移动命令。最终，原文件夹被清空，而目标文件夹并未生成，所有数据丢失。

关键故障点

1. 命令执行反馈误判
   Gemini CLI 在执行 mkdir 命令时，未能正确解析命令的实际执行结果。即使目录未被创建，CLI 依然认为操作成功。这种误判直接导致后续操作基于错误前提继续进行。

2. 缺乏操作后验证
   工具未在每一步操作后进行状态验证。例如，未通过 ls 或 dir 检查目录是否真实存在。缺乏“先写后读”的验证机制，使得错误被不断放大。

3. move 命令的覆盖机制
   在 Windows 环境下，move 命令如果目标目录不存在，会将源文件重命名为目标名称。多次执行会导致文件被反复覆盖，最终只剩下最后一次移动的文件，其他数据全部丢失。

4. 错误恢复失败
   当用户尝试让 Gemini 恢复文件时，工具依然基于错误的假设操作，无法找到原始数据。安全沙盒机制进一步限制了对系统其他目录的访问，导致恢复无效。

其他 AI 工具的类似问题

不仅 Gemini CLI，Claude、GitHub Copilot 等主流 AI 编程工具也被用户曝出过类似的误删文件、数据库等事故。常见表现包括：误删超出预期范围的文件、在未确认的情况下执行破坏性命令、对 diff 处理不当导致文件残缺等。

根本原因分析

这些问题并非单一模型的 bug，而是当前 SOTA（state-of-the-art）模型在面对不确定性时的系统性缺陷。模型被训练为持续输出、有问必答，缺乏在不确定时中止操作的机制。尤其在具备实际执行能力的 Agent 模式下，缺乏“敬畏终端”的意识，极易导致数据丢失和逻辑错误。

工程实践建议

• 在使用 AI 工具进行文件或数据库操作前，务必做好版本控制（如 git commit）。
• 不要完全信任 AI 工具的反馈，关键操作后应手动验证结果。
• 对于具备实际执行能力的 AI Agent，建议限制其自动化权限，避免无确认执行高风险命令。

结语

AI 工具在自动化开发流程中展现出巨大潜力，但其在实际操作系统层面的可靠性仍有待提升。工程师在使用此类工具时，应保持高度警惕，建立完善的备份和验证机制，以防止不可逆的数据损失。

核心内容梳理

1. 娃哈哈的股权结构

   • 文章详细梳理了娃哈哈自成立以来的股权变迁。通过具体的历史节点，分析了公司在不同发展阶段的股东构成。
   • 以实际案例说明，娃哈哈的股权并非始终集中在某一方手中，而是经历了多轮调整和利益再分配。

2. 利益相关方的博弈

   • 文章指出，娃哈哈的所有权归属问题并非单一法律或合同问题，而是多方利益博弈的结果。
   • 通过“分蛋糕”的比喻，解释了企业在成长过程中，原始股东、管理层、外部投资者等多方如何通过谈判、协作甚至冲突来重新分配企业控制权和收益权。

3. 历史事件与现实影响

   • 结合娃哈哈与达能的合资、分歧与解约等历史事件，分析了外部资本介入对企业所有权结构的影响。
   • 文章强调，企业所有权的归属往往受到政策、市场环境和企业家个人能力等多重因素影响。

4. 企业治理与控制权

   • 文章讨论了企业治理结构对所有权归属的影响。通过娃哈哈的案例，说明了在中国企业环境下，实际控制权有时比名义股权更为重要。
   • 以具体例子说明，企业创始人通过对公司运营、管理团队和关键资源的掌控，能够在股权分散的情况下依然保持对企业的主导权。

关键术语与概念解释

• 股权结构：指企业各股东持有股份的比例及其变化过程。通过图表或时间线可以直观展示不同阶段的股东分布。
• 实际控制权：不仅仅是持股比例，更包括对公司决策、资源分配和人事安排的主导能力。
• 利益博弈：企业发展过程中，不同利益相关方围绕资源和权力进行的动态调整过程。

总结

文章以娃哈哈为案例，系统梳理了中国民营企业在成长过程中所有权归属的复杂性。通过历史事件、股权结构变化和利益方博弈的具体分析，揭示了企业所有权并非一成不变，而是多因素共同作用的结果。文章强调，理解企业所有权归属，需要结合法律、管理、历史和现实多维度视角。

主要内容梳理

1. Vibe Coding 竞赛背景

   • Vibe Coding 是一场面向开发者的编程竞赛，旨在推动AI辅助编程工具的落地与普及。
   • 竞赛吸引了众多国内外团队参与，成为检验大模型实际能力的舞台。

2. 阿里巴巴新模型的表现

   • 阿里巴巴团队凭借自研大模型在竞赛中取得领先。
   • 新模型在代码生成、自动补全、Bug 定位等方面展现出高效与准确。
   • 文章通过具体案例，展示了模型在复杂业务场景下的实用性。例如，面对多层嵌套的前端组件，模型能够准确推断数据流和状态变化，极大提升开发效率。

3. 大模型对前端开发的影响

   • 传统前端开发依赖于工程师对业务逻辑和UI细节的高度把控。大模型的引入，使得部分重复性工作可以自动化完成。
   • 例如，UI 设计稿转代码、样式自动生成、交互逻辑推断等环节，模型能够根据设计规范和历史项目经验，生成高质量的代码片段。
   • 这不仅降低了新手工程师的上手门槛，也让资深开发者能够将更多精力投入到架构设计和创新上。

4. 行业趋势与挑战

   • 文章指出，AI辅助编程工具的普及将重塑前端开发的工作方式。工程师需要不断学习如何与模型协作，提升 prompt 设计和代码审查能力。
   • 同时，模型的泛化能力和安全性仍是当前技术发展的瓶颈。例如，在处理业务边界条件和异常场景时，模型可能会生成不符合预期的代码，需要人工介入校验。

5. 未来展望

   • 随着大模型能力的提升，前端开发将逐步从“手工编码”转向“人机协作”模式。
   • 工程师的角色将从单纯的代码实现者，转变为需求分析师和系统架构师，负责定义业务目标和技术边界，指导模型生成符合预期的解决方案。

总结

本网页通过对 Vibe Coding 竞赛的剖析，展现了阿里巴巴新一代大模型在前端开发领域的实际应用与行业影响。文章强调，AI与代码的深度融合正在推动开发范式的转变，工程师需要不断适应和提升自身能力，以应对未来更为智能化的开发环境。

澳大利亚对未成年人注册YouTube账号的新规

澳大利亚政府宣布，Google需确保16岁以下儿童无法注册YouTube账号。这一决定改变了2024年原本将YouTube排除在外的政策，使其与Facebook、Instagram、Snapchat、TikTok和X等平台一样，必须采用年龄验证技术。

政策核心与实施方式

新规并未禁止未成年人使用社交媒体。政府的目标是防止平台通过账号追踪未成年人。例如，孩子可以通过家长账号、无账号模式或使用YouTube Kids等专为儿童设计的服务访问内容。这样做的本质是减少平台对未成年人数据的收集和分析。

政府与平台的合作关系

澳大利亚政府强调与社交平台的合作，而非对抗。总理Anthony Albanese指出，社交平台具备精准广告投放能力，因此也应有能力保护未成年人。政府希望通过持续协作，逐步完善监管措施，应对绕过限制的行为。

争议与挑战

Google对政策调整表示不满，认为YouTube是视频分享平台而非社交媒体，并通过广告和声明表达立场。但澳大利亚监管机构认为，YouTube已成为未成年人网络风险的重要来源。政府还需解决年龄验证技术本身存在的缺陷，否则新规的实际效果可能受限。

未来展望

澳大利亚此举被视为全球领先的监管尝试。如果政策取得成效，可能会影响其他国家对未成年人网络保护的立法方向。当前，政府仍在评估最合适的年龄验证技术，以确保法律的有效实施。

CEO推动AI取代人工的现象

当前网页报道了部分CEO公开表达用AI取代员工的积极态度。Elijah Clark是一位为企业提供AI应用咨询的CEO，他坦言，自己因AI裁员感到“极度兴奋”。Clark强调，AI不会罢工，也不会要求加薪，这些特性让管理者更易于控制成本和提升效率。

AI取代人工的实际案例

Clark曾在带领的销售支持团队中，裁掉了30人中的27人，仅用AI和极少数员工就能在极短时间内完成原本需要一周的工作。对于企业来说，效率和利润成为主要考量。Clark指出，许多CEO已经在筹划未来半年到一年内进一步裁员，几乎所有公司都在寻找节省成本的方法。

AI替代带来的风险与反噬

并非所有AI替代案例都顺利。Klarna的CEO Sebastian Siemiatkowski曾大力推行AI客服，结果客户体验大幅下降，导致公司亏损加剧。Siemiatkowski反思，过度关注成本导致服务质量下降。即使想要回头，Klarna已裁掉约40%的员工，恢复原状变得困难。

行业趋势与未来展望

JLL的Peter Miscovich指出，2025年，20%的财富500强企业员工数量已低于2015年。许多公司计划将员工数量削减30%至40%。Clark直言，自己被雇佣的主要任务就是帮助CEO用AI裁员，这一趋势正在发生，并非遥远的未来。

AI能力与局限

尽管AI在某些任务上提升了效率，但目前的AI模型仍存在信息捏造、规则失效等问题。AI并不需要完全取代人类，只要能自动化部分流程，就足以让企业减少人力并让剩余员工承担更多工作。企业在追求效率的同时，也面临服务质量下降和客户流失的风险。

Gemini CLI 新增自定义 Slash 命令功能

Google Cloud 官方宣布，Gemini CLI 现已支持自定义 slash 命令。这一功能允许开发者通过本地 .toml 文件或 Model Context Protocol (MCP) prompt，定义可复用的 prompt，从而提升命令行交互的效率。用户只需升级到最新版 Gemini CLI，即可体验该功能。

.toml 文件作为命令基础

自定义命令的核心在于 .toml 文件。每个命令对应一个 .toml 文件，文件名即为命令名（区分大小写）。只需设置 prompt 关键字即可实现最基础的命令。命令支持参数（通过 {{args}} 占位符）和 shell 命令执行（通过 !{...} 语法），便于灵活扩展。例如，/review <issue_number> 命令可自动拉取 GitHub PR 信息、diff、校验 commit message，并生成标准化的 review。

命名空间与命令分组

命令的命名空间由文件路径决定。主目录下的命令如 ~/.gemini/commands/test.toml 对应 /test，而子目录如 ~/.gemini/commands/git/commit.toml 则对应 /git:commit。这种方式便于将相关命令分组管理，提升项目结构的清晰度。

构建自定义命令的流程

1. 创建命令文件
   在 ~/.gemini/commands/ 目录下新建如 plan.toml 文件，即可定义 /plan 命令。命令既可作用于个人（用户目录），也可作用于项目（项目目录）。

2. 编写命令内容
   以 plan.toml 为例，description 字段描述命令用途，prompt 字段详细规定交互流程。该命令要求 Gemini CLI 仅输出详细的战略计划，不涉及任何代码实现。输出内容需包含目标理解、分析步骤、战略方案、验证策略及风险评估等部分，结构清晰，便于团队协作和反馈。

应用场景与优势

自定义 slash 命令极大提升了命令行工具的可扩展性和自动化能力。开发者可根据实际需求，快速搭建标准化的工作流。例如，代码评审、需求拆解、项目规划等场景均可通过自定义命令实现自动化和流程规范化。这种方式降低了重复性操作的门槛，使团队协作更加高效、透明。