1. 项目概述为命令行工具注入AI灵魂如果你和我一样日常大部分时间都泡在终端里那么对命令行工具CLI的效率有着近乎偏执的追求。我们习惯于用grep过滤日志用awk处理文本用curl测试接口这些经典工具构成了我们与机器交互的基石。但有没有想过当命令行遇上大语言模型LLM会碰撞出怎样的火花这就是“为Gemini CLI和Antigravity构建自定义命令”这个项目要探索的核心。简单来说这个项目就是教你如何将Google的Gemini大模型通过一个名为“Antigravity”的CLI工具框架深度集成到你的本地终端环境中。它不是简单地调用一个AI聊天接口而是让你能够像定义alias或编写bash function一样创建出能理解自然语言、具备复杂推理和执行能力的“智能命令”。想象一下在终端里输入find-fix “昨天部署后用户登录变慢的原因”AI就能自动分析日志、关联部署记录、给出可能的原因和修复建议或者输入code-review ~/project/src/AI就能对指定目录的代码进行风格检查和安全漏洞扫描。这不再是科幻而是可以通过本项目实现的、提升开发者日常效率的利器。Gemini CLI通常指的是Google官方或社区提供的用于在命令行中与Gemini模型交互的基础工具。它可能是一个Python脚本封装了Gemini API的调用。而Antigravity在这里更像是一个比喻或一个具体的框架名灵感可能来源于Python的import antigravity彩蛋它代表了一个允许你扩展和自定义这些AI命令的“平台”或“脚手架”。本项目的目标就是打通从“有一个AI模型”到“拥有一个能解决实际问题的智能CLI命令”的全链路。适合阅读本文的读者包括任何希望将AI能力无缝融入工作流的开发者、运维工程师、技术爱好者对LLM应用开发感兴趣想从“玩具Demo”走向“生产级工具”的实践者以及所有追求极致终端效率的“键盘流”用户。无论你是想自动化代码审查、智能日志分析、自然语言生成测试用例还是创造一些天马行空的助手这里都有你需要的“脚手架”和“设计图”。2. 核心架构与设计思路拆解在动手敲代码之前我们必须想清楚一个“智能命令”的完整生命周期是怎样的它与传统Shell命令或脚本的本质区别在哪里只有理清了架构才能避免后期陷入“缝缝补补”的泥潭。2.1 智能命令的核心组件模型一个完整的、基于Gemini的自定义命令我认为至少需要五个核心组件协同工作命令解析器Command Parser这是用户交互的第一层。它需要识别用户在终端输入的指令例如my-ai-command --option “query in natural language”。这部分需要处理参数解析、子命令路由如review codevsreview log。我们可以直接利用成熟的库如Python的argparse、click或typer来快速构建它们能生成漂亮的--help文档符合CLI工具的用户习惯。上下文构建器Context Builder这是智能化的关键。AI模型不是神它需要“上下文”才能做出精准回答。对于代码审查命令上下文就是待审查的源代码文件内容对于日志分析命令上下文可能就是最近一段时间的日志片段、相关的系统指标数据。这个组件的职责是根据解析出的命令意图动态地去收集、读取、格式化这些背景信息。例如它可能需要递归读取目录下的所有.py文件或者用subprocess调用git log获取最近的提交历史。提示词工程模块Prompt Engineer这是连接“用户问题”和“AI能力”的桥梁。我们不能简单地把用户查询和原始上下文扔给Gemini。我们需要精心设计一个“提示词模板”Prompt Template。这个模板会定义AI的角色“你是一个资深的Python代码审查专家”、任务“分析以下代码找出潜在的性能问题、安全漏洞和不符合PEP 8规范的地方”、输出格式要求“请按‘严重程度’、‘问题描述’、‘代码位置’、‘修复建议’的表格形式列出”。好的提示词能极大提升结果的准确性和可用性。模型调用与交互层Model Interface这是与Gemini API或其他兼容API通信的封装层。它负责处理网络请求、API密钥管理、模型版本选择如gemini-1.5-pro还是gemini-1.5-flash、设置温度Temperature和最大输出令牌数Max Tokens等参数。这一层需要健壮的错误处理如网络超时、额度不足、内容过滤和可能的退避重试机制。结果后处理器Result Post-processorAI返回的通常是Markdown或纯文本。我们需要将其转化为对用户更友好的形式。这可能包括语法高亮显示代码建议、将表格数据对齐输出、提取关键信息并触发后续自动化操作如自动运行一个linter或者将结果保存到文件。对于某些命令甚至需要实现“交互式修正”循环即让AI根据用户的反馈调整输出。设计思路的核心考量这套架构的核心思想是“关注点分离”和“可插拔”。命令解析、上下文收集、提示词模板、模型调用、结果处理每个环节都应该独立定义。这样做的好处是当你需要创建一个新的智能命令时你很可能只需要编写一个新的“上下文构建器”和“提示词模板”其他组件都可以复用。这也使得调试和测试变得更加容易——你可以单独测试提示词是否有效而不必每次都调用真实的API。2.2 为什么选择“Antigravity”作为框架名在项目中引入“Antigravity”这个概念非常巧妙。它不仅仅是一个酷炫的名字更体现了一种设计哲学。象征意义Antigravity反重力意味着打破常规、提升效率。传统的CLI工具遵循严格的语法而AI命令行工具允许用自然语言模糊表达这本身就是一种“反重力”体验——让操作变得更轻松、更直接。框架定位我们可以将“Antigravity”设计为本项目的核心框架或SDK。它提供了一套基础类BaseCommand, BaseContextBuilder, BasePromptTemplate和注册机制。开发者通过继承这些基类并实现几个关键方法就能像搭积木一样声明一个新的智能命令。框架负责处理命令的注册、发现、路由和生命周期管理。实践示例一个最简单的Antigravity框架入口点可能是一个ag命令。安装后你可以通过ag register my_command.py来注册一个自定义命令然后就能直接在终端使用my_command了。框架内部帮你处理了所有繁琐的胶水代码。注意这里的“Antigravity”是一个项目内的概念。在实际实现时你需要为其创建一个Python包如antigravity_core并发布到PyPI或者直接以可编辑模式pip install -e .在本地开发。避免与任何已有的知名库重名。2.3 技术栈选型与权衡语言Python是几乎唯一的选择。因为它拥有最成熟的AI生态Google官方Gemini SDK就是Python/Node.js同时在CLI开发、文件系统操作、子进程管理等方面都有极其丰富的库支持。CLI框架Typer基于Python类型提示声明式API能自动生成帮助文档开发体验极佳。非常适合本项目。Click更传统和强大生态丰富。两者皆可我个人近期更偏爱Typer的简洁。配置管理使用pydantic-settings或python-dotenv管理API密钥、模型默认参数等配置。绝对不要将密钥硬编码在代码中。异步支持考虑使用asyncio和aiofiles、httpx等异步库。当你的命令需要并行读取多个文件或同时调用多个AI任务时异步能带来显著的性能提升。但这会增加初期的复杂度可以作为进阶优化项。测试务必为你的命令编写测试。使用pytest配合monkeypatch来模拟Gemini API的返回确保核心逻辑的正确性避免因API调用产生高昂费用和不稳定。3. 从零构建你的第一个智能命令code-insight让我们抛开概念直接动手。我将带你一步步创建一个名为code-insight的命令它的功能是对指定Python文件或目录进行高层次的设计思路和潜在改进点分析不同于静态的语法检查。3.1 项目初始化与基础框架搭建首先创建项目目录结构。清晰的目录是良好项目的开端。mkdir gemini-antigravity-cli cd gemini-antigravity-cli python -m venv venv source venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows pip install google-generativeai typer rich pydantic-settings安装关键库google-generativeai是官方SDKtyper用于构建CLIrich用于在终端输出漂亮的格式和颜色pydantic-settings用于管理配置。接下来创建我们的“Antigravity”框架雏形。我们从一个简单的、可扩展的设计开始。# antigravity_core/framework.py import abc from typing import Any, Dict, Optional import google.generativeai as genai from pydantic_settings import BaseSettings class AntigravitySettings(BaseSettings): gemini_api_key: str default_model: str gemini-1.5-flash default_temperature: float 0.2 default_max_tokens: Optional[int] None class Config: env_file .env settings AntigravitySettings() # 初始化Gemini genai.configure(api_keysettings.gemini_api_key) class BaseContextBuilder(abc.ABC): 抽象基类负责为命令构建上下文信息。 abc.abstractmethod def build(self, **kwargs) - str: pass class BasePromptTemplate(abc.ABC): 抽象基类负责生成发送给AI的最终提示词。 abc.abstractmethod def generate_prompt(self, user_input: str, context: str) - str: pass class BaseCommand: 命令基类。每个自定义命令都应继承此类。 def __init__(self, context_builder: BaseContextBuilder, prompt_template: BasePromptTemplate): self.context_builder context_builder self.prompt_template prompt_template self.model genai.GenerativeModel(settings.default_model) def execute(self, user_input: str, **kwargs) - str: 命令执行的主流程。 # 1. 构建上下文 context self.context_builder.build(**kwargs) # 2. 生成提示词 prompt self.prompt_template.generate_prompt(user_input, context) # 3. 调用模型 response self.model.generate_content(prompt) # 4. 返回结果 return response.text这个框架虽然简单但明确了核心抽象。一个BaseCommand依赖一个上下文构建器和一个提示词模板来工作。3.2 实现code-insight命令的各个组件现在我们为code-insight命令实现具体的组件。第一步创建上下文构建器。它的任务是读取并格式化源代码。# commands/code_insight/context_builder.py import os from pathlib import Path from antigravity_core.framework import BaseContextBuilder class CodeContextBuilder(BaseContextBuilder): def build(self, path: str, **kwargs) - str: 读取指定路径的Python文件或目录构建上下文字符串。 target_path Path(path) context_parts [] if target_path.is_file() and target_path.suffix .py: context_parts.append(self._read_and_format_file(target_path)) elif target_path.is_dir(): for py_file in target_path.rglob(*.py): # 可以忽略某些目录如 __pycache__, .venv等 if any(ignore in str(py_file) for ignore in [__pycache__, .venv, .git]): continue context_parts.append(self._read_and_format_file(py_file)) else: raise ValueError(f路径 {path} 不是一个.py文件或目录。) return \n\n---\n\n.join(context_parts) # 用分隔符连接多个文件 def _read_and_format_file(self, file_path: Path) - str: 读取单个文件并格式化为包含文件路径的代码块。 try: content file_path.read_text(encodingutf-8) # 返回格式化的上下文便于AI识别 return f文件路径: {file_path}\npython\n{content}\n except Exception as e: return f文件路径: {file_path}\n[读取文件时出错: {e}]第二步创建提示词模板。这是命令“智能”的灵魂所在。# commands/code_insight/prompt_template.py from antigravity_core.framework import BasePromptTemplate class CodeInsightPromptTemplate(BasePromptTemplate): def generate_prompt(self, user_input: str, context: str) - str: # 这是一个精心设计的系统提示词 system_prompt 你是一个经验丰富的软件架构师和代码审查专家。你的任务是对提供的Python代码进行高层次分析专注于设计模式、架构清晰度、潜在的性能瓶颈、可维护性和可扩展性。 请遵循以下分析框架 1. **整体印象与设计**用一两句话总结代码的整体结构和设计思路。它是否清晰是否符合单一职责、开闭等原则 2. **亮点与优秀实践**指出代码中做得好的地方比如清晰的抽象、恰当的设计模式使用、良好的模块化等。 3. **潜在问题与风险**指出架构或设计层面的问题如紧耦合、循环依赖、上帝对象、可能的内存泄漏或并发问题。 4. **具体改进建议**针对发现的问题提供具体的、可操作的改进建议。如果可能给出简单的代码重构示例。 5. **扩展性思考**如果未来需求变化如数据量激增、需要支持新功能当前架构可能会遇到什么挑战有何预防建议 请以清晰、结构化、友好的语气输出使用适当的标题和列表。如果代码量很大可以聚焦于核心模块。 # 将系统指令、用户问题可选和代码上下文组合成最终提示词 user_query_part f\n用户的具体问题或关注点: {user_input} if user_input else final_prompt f{system_prompt}{user_query_part}\n\n以下是需要分析的代码\n{context} return final_prompt第三步组装命令并用Typer创建CLI入口。# commands/code_insight/command.py import typer from rich.console import Console from rich.markdown import Markdown from .context_builder import CodeContextBuilder from .prompt_template import CodeInsightPromptTemplate from antigravity_core.framework import BaseCommand app typer.Typer(help对Python代码进行AI驱动的设计洞察分析。) console Console() class CodeInsightCommand(BaseCommand): def __init__(self): super().__init__(CodeContextBuilder(), CodeInsightPromptTemplate()) # 创建命令实例 cmd CodeInsightCommand() app.command() def analyze( path: str typer.Argument(..., help要分析的.py文件或目录路径。), question: str typer.Option(, --question, -q, help向AI提出的具体问题例如‘这里的类设计是否合理’), ): 分析指定Python代码的设计与架构。 console.print(f[bold blue]正在分析路径: {path}[/bold blue]) try: # 执行核心逻辑 result cmd.execute(question, pathpath) # 使用Rich漂亮地打印Markdown格式的结果 console.print(Markdown(result)) except Exception as e: console.print(f[bold red]错误: {e}[/bold red], stylered) raise typer.Exit(code1) # 这个模块可以被主CLI应用导入并注册第四步创建主CLI应用来集成所有命令。# main.py import typer from commands.code_insight.command import app as code_insight_app # 创建主Typer应用 main_app typer.Typer() # 将子命令添加到主应用 main_app.add_typer(code_insight_app, namecode-insight) if __name__ __main__: main_app()第五步配置与环境变量。在项目根目录创建.env文件确保在.gitignore中忽略它GEMINI_API_KEYyour_actual_gemini_api_key_here现在你的第一个智能命令就完成了通过python main.py code-insight analyze --help可以看到帮助信息。使用python main.py code-insight analyze ./my_python_project/ -q “这个模块的依赖关系复杂吗”即可运行。3.3 关键细节与避坑指南文件编码务必指定utf-8编码读取文件否则遇到中文注释或特殊字符会报错。这是实践中非常高频的一个坑。上下文长度限制Gemini模型有上下文窗口限制例如32K tokens。CodeContextBuilder在遍历目录时如果代码量巨大需要实现策略要么只分析最近修改的文件要么先总结每个文件再汇总或者提示用户缩小范围。可以在构建器中加入一个max_files或max_tokens的参数。API错误处理在BaseCommand.execute中对genai.generate_content的调用要进行try-except处理genai.types.StopCandidateException或网络超时等异常给出用户友好的提示而不是一堆Python traceback。提示词迭代你第一次写的提示词Prompt很难完美。code-insight命令的效果严重依赖于提示词的质量。你需要准备一些典型的代码样例反复运行命令根据AI输出的不足调整提示词。这是一个迭代的过程。建议将提示词模板设计成可配置的甚至可以从文件加载方便调试。成本控制每次调用都消耗Token。在开发调试阶段可以在AntigravitySettings中设置一个dry_run模式只打印将要发送的提示词而不真正调用API或者使用一个非常便宜的模型如gemini-1.5-flash进行测试。4. 进阶打造可复用的命令工厂与插件系统当我们有了多个命令如code-insight,log-analyzer,sql-optimizer后手动注册和管理会变得繁琐。我们需要一个更优雅的“插件化”系统。4.1 实现自动命令发现与注册我们可以利用Python的importlib和entry_points如果打包为包机制实现命令的自动发现。首先定义一个命令注册表。# antigravity_core/registry.py from typing import Dict, Type import typer class CommandRegistry: _commands: Dict[str, typer.Typer] {} classmethod def register(cls, name: str, app: typer.Typer): 将一个Typer应用注册为一个顶级命令。 if name in cls._commands: raise ValueError(f命令 {name} 已被注册。) cls._commands[name] app classmethod def get_all_commands(cls) - Dict[str, typer.Typer]: return cls._commands.copy() # 修改 main.py使其从注册表动态加载命令 # main.py import typer from antigravity_core.registry import CommandRegistry import importlib import pkgutil import commands # 假设所有命令模块都在commands包下 def discover_and_register_commands(): 自动发现commands包下所有模块并注册命令。 package commands prefix package.__name__ . for _, module_name, _ in pkgutil.iter_modules(package.__path__, prefix): try: module importlib.import_module(module_name) # 约定每个命令模块需要暴露一个 app 变量Typer实例和一个 COMMAND_NAME 变量 if hasattr(module, app) and hasattr(module, COMMAND_NAME): CommandRegistry.register(module.COMMAND_NAME, module.app) except ImportError as e: print(f警告: 无法导入模块 {module_name}: {e}) # 在创建主app前执行发现 discover_and_register_commands() main_app typer.Typer() registered_commands CommandRegistry.get_all_commands() for cmd_name, cmd_app in registered_commands.items(): main_app.add_typer(cmd_app, namecmd_name) if __name__ __main__: main_app()然后在每个命令模块中遵循约定暴露接口。# commands/code_insight/__init__.py from .command import app COMMAND_NAME code-insight这样你只需要在commands目录下新建一个文件夹如log_analyzer实现好对应的组件和app并创建__init__.py声明COMMAND_NAME它就会被自动集成到主CLI中。无需修改main.py。4.2 设计配置驱动的命令行为一个强大的命令框架应该允许用户通过配置文件来调整命令的行为。例如code-insight命令可以允许用户自定义忽略的目录、默认分析的模型、输出的详细程度等。我们可以为每个命令定义一个Pydantic配置模型并允许通过YAML或TOML文件进行覆盖。# antigravity_core/config.py from pydantic import BaseModel from typing import List, Optional class CodeInsightConfig(BaseModel): ignore_dirs: List[str] [__pycache__, .venv, .git, node_modules, dist, build] max_files_to_analyze: Optional[int] 50 focus_on_recent: bool False output_format: str markdown # markdown, json, plain # 在上下文构建器中使用配置 class CodeContextBuilder(BaseContextBuilder): def __init__(self, config: CodeInsightConfig): self.config config def build(self, path: str, **kwargs) - str: # ... 构建逻辑中使用 self.config.ignore_dirs 等 ... pass主设置可以加载一个全局配置文件并合并命令特定的配置节。4.3 实现交互式与流式输出对于耗时长或需要逐步澄清的任务交互式和流式输出能极大改善体验。流式输出Gemini API支持流式响应。我们可以修改BaseCommand.execute方法使用generate_content(..., streamTrue)然后边接收边通过rich的Live面板或直接打印输出让用户立即看到生成过程而不是长时间等待。response self.model.generate_content(prompt, streamTrue) for chunk in response: print(chunk.text, end, flushTrue) # 简单示例交互式对话某些命令可能需要多轮对话。例如用户对AI给出的代码建议不满意可以要求它“用另一种方法实现”。这需要维护一个会话历史。我们可以在BaseCommand中增加一个conversation_history列表属性每次将用户输入和AI回复追加进去并在构建提示词时将整个历史或最近几轮作为上下文发送。这需要更精细的提示词设计来管理对话状态。5. 实战构建一个复杂的log-analyzer命令让我们再实现一个更复杂的命令巩固所学。log-analyzer命令的目标是给定一个日志文件或目录让AI自动分析错误趋势、定位关键问题、并给出排查建议。5.1 设计思路与挑战日志分析不同于代码分析其挑战在于数据量大日志文件可能上GB。格式多样Nginx日志、应用日志、系统日志格式各不相同。信息冗余大部分是正常信息需要从中提取错误、警告。因此我们的上下文构建器需要更智能采样与过滤不能一次性读取所有日志。可以读取最后N行或者用grep -i “error\|exception\|fail”预先过滤出关键行。格式探测与解析尝试自动探测常见日志格式或允许用户通过参数指定格式如--format nginx。时间范围允许用户指定--since “2024-01-01” --until “2024-01-02”。5.2 实现核心组件上下文构建器智能采样与摘要# commands/log_analyzer/context_builder.py import subprocess from pathlib import Path from antigravity_core.framework import BaseContextBuilder class LogContextBuilder(BaseContextBuilder): def build(self, path: str, sample_lines: int 1000, filter_level: str ERROR, **kwargs) - str: log_path Path(path) context_lines [] if log_path.is_file(): # 策略1使用tail获取文件末尾部分避免读取巨大文件 try: result subprocess.run( [tail, -n, str(sample_lines), str(log_path)], capture_outputTrue, textTrue, checkTrue ) logs result.stdout except subprocess.CalledProcessError: # 备选策略直接读取但可能内存不足 with open(log_path, r, encodingutf-8, errorsignore) as f: lines f.readlines() logs .join(lines[-sample_lines:]) # 策略2进一步过滤出关键级别日志 filtered_logs self._filter_logs_by_level(logs, filter_level) context_lines.append(f 日志文件: {log_path} (采样最后{sample_lines}行过滤级别: {filter_level}) \n) context_lines.append(filtered_logs[:50000]) # 防止上下文过长二次截断 elif log_path.is_dir(): # 遍历目录下的.log文件对每个文件采样 for log_file in log_path.rglob(*.log): # ... 类似文件处理逻辑可以限制处理的文件数量 ... pass else: raise ValueError(无效的日志路径。) return \n.join(context_lines) def _filter_logs_by_level(self, logs: str, level: str) - str: # 简单的关键字过滤实际应用可能需要正则表达式匹配日志级别字段 keywords { ERROR: [ERROR, CRITICAL, FATAL], WARN: [WARN, WARNING, ERROR, CRITICAL, FATAL], INFO: [] # 空列表表示不过滤 }.get(level.upper(), [ERROR]) if not keywords: return logs filtered_lines [line for line in logs.split(\n) if any(kw in line.upper() for kw in keywords)] return \n.join(filtered_lines)提示词模板聚焦运维场景# commands/log_analyzer/prompt_template.py from antigravity_core.framework import BasePromptTemplate class LogAnalyzerPromptTemplate(BasePromptTemplate): def generate_prompt(self, user_input: str, context: str) - str: system_prompt 你是一个资深运维专家SRE。请分析以下日志片段并回答 1. **主要问题**出现了哪些类型的错误或异常请按出现频率和严重性排序。 2. **根本原因推测**根据错误信息和时间关联性推测最可能的根本原因例如数据库连接池耗尽、第三方API限流、内存泄漏、配置错误。 3. **影响评估**这些错误对系统可用性、性能或数据一致性可能产生了什么影响 4. **行动建议**给出具体的、可操作的排查步骤和建议。例如检查哪个监控指标、查看哪个相关日志、如何复现问题、可能的代码位置。 5. **预防措施**从架构或运维角度如何避免此类问题再次发生 请以清晰、有条理的方式输出对关键错误信息可以引用原文。如果日志信息不足以下结论请明确指出需要补充哪些信息。 user_part f\n用户的附加问题或关注点: {user_input} if user_input else return f{system_prompt}{user_part}\n\n以下是日志内容\n{context}通过组合这样的构建器和模板log-analyzer命令就能从海量日志中快速提炼出有价值的信息为故障排查提供强有力的AI辅助。6. 部署、分发与持续迭代6.1 打包与发布要让你的工具被他人使用需要将其打包。创建一个标准的pyproject.toml文件。# pyproject.toml [build-system] requires [setuptools61.0, wheel] build-backend setuptools.build_meta [project] name gemini-antigravity-cli version 0.1.0 authors [{name Your Name, email youexample.com}] description A CLI tool to build custom AI-powered commands with Gemini. readme README.md requires-python 3.8 dependencies [ google-generativeai0.3.0, typer[all]0.9.0, rich13.0.0, pydantic-settings2.0.0, ] [project.scripts] ag antigravity_cli.main:main_app # 这里将主入口指向你的main.py中的main_app [tool.setuptools.packages.find] where [.]然后你可以使用pip install -e .在本地开发或使用python -m build构建分发包上传到PyPI。用户就可以通过pip install gemini-antigravity-cli安装并使用ag code-insight analyze ...来调用命令了。6.2 安全与最佳实践API密钥管理始终坚持从环境变量或加密的配置文件读取API密钥。在框架初始化时验证密钥是否存在。内容安全对于企业环境需要考虑AI生成内容的安全审查。Gemini API本身有安全过滤器但对于高度敏感的场景可能需要在结果后处理器中加入额外的关键词过滤。速率限制与重试在模型调用层实现指数退避的重试逻辑并遵守Gemini API的速率限制。日志记录为框架添加日志功能记录命令的执行情况、消耗的Token数等便于监控和调试。但注意不要记录敏感的上下文信息。6.3 性能优化思路缓存对于相同的查询和上下文结果可以缓存到本地文件或数据库如SQLite并设置TTL。这能节省成本并提升重复查询的响应速度。并行处理在分析多个独立文件时如一个目录下的所有模块可以使用concurrent.futures.ThreadPoolExecutor并行调用AI进行分析最后汇总结果。注意API的并发限制。上下文压缩对于超长的代码或日志可以尝试先用一个“总结性”的AI调用将原始内容压缩成摘要再将摘要作为上下文发送给主分析任务。这是一种“两阶段”处理策略。构建自定义的Gemini CLI命令本质上是将大语言模型的“通用智力”通过精巧的工程化设计转化为解决特定领域问题的“专用工具”。Antigravity框架的价值在于提供了实现这种转化的标准化路径和最佳实践。从简单的code-insight到复杂的log-analyzer你可以看到同样的模式在重复应用理解任务、收集上下文、设计提示词、处理结果。掌握了这个模式你就能将AI能力像乐高积木一样自由地拼接到任何你觉得繁琐或需要智能洞察的工作流中。真正的效率提升始于将强大的能力封装成指尖一个简单的命令。现在是时候为你自己的工作流定制第一个“反重力”命令了。
