会改本地文件的助手第一次用就可能删错东西五类高频翻车【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cliGemini CLI 的定位很直白把模型放进终端允许它读你的仓库、写你的文件、跑你的命令。这种能力的另一面是——它第一次启动时你对它的默认值一无所知而它对你要保护什么也一无所知。社区对它的评价也印证了这种能力先行、可靠性待磨合的阶段特征开源、免费额度大、上手极快但同时接近早期预览版距稳定可靠还有距离。这篇文章不谈跑分只谈一件事一个会落盘修改的 agent在头几次使用时最容易从哪些地方翻车以及仓库里已经写好了哪些刹车。以下所有结论都能在当前仓库源码与文档中找到对应实现涉及的具体文件会以仓库相对路径标注。一、为什么第一次用最危险默认值清单在动手之前先把几个关键默认值摆出来它们共同决定了你第一次运行时的风险基线。行为默认状态依据工具执行确认default逐个询问命令行参数自动批准编辑工具需显式auto_edit或yolo同上Checkpoint修改前快照关闭Checkpointing受信任目录Trusted Folders关闭Trusted Folders沙箱需显式开启SandboxingPlan Mode默认可用可设为默认模式Plan Mode注意这两项的对照关系询问是开的但快照和信任校验是关的。这意味着默认状态下工具调用会停下来问你一旦你因为它在跑测试、它在整理目录而连续按下确认剩下的唯一安全网就是你自己对 diff 的阅读速度。而 Chekpointing 默认关闭意味着那一步点击没有任何可回退的落点。二、五类高频翻车第一类陌生仓库的项目级配置先于你的判断生效这是最容易被忽略、也最第一次的一类。克隆一个仓库、cd进去、直接gemini是所有人的标准起手式。问题在于项目级配置是随仓库一起进来的。Trusted Folders 的文档把机制写得很清楚开启后首次进入某个目录会弹出信任对话框并在**发现阶段discovery phase**列出该项目里的 Commands、MCP Servers、Hooks、Skills以及Setting overrides也就是项目级settings.json对你的全局配置的覆盖如果发现自动批准某些工具或关闭安全沙箱这类危险设置CLI 会显式告警。但这项特性默认是关闭的。默认关闭时你不会看到这个对话框项目配置会按正常工作流加载。一旦文件夹被判定为不受信任防线反而是完整的Trusted Folders 列出了七条限制——不加载.gemini/settings.json、不加载项目.env、禁止扩展装卸、工具自动接受被强制关闭即使你全局开了自动批准、不自动加载内存文件、不连接 MCP、不加载自定义命令。换句话说那个对话框不是多问一句而是这七条限制的总开关。怎么防在跑任何陌生仓库之前先做只读侦察——cat .gemini/settings.json、看有没有.gemini/commands、.gemini/hooks、.gemini/skills。想长期解决就把信任机制打开{ security: { folderTrust: { enabled: true } } }CI/无头场景下没有交互界面未受信任的目录会直接抛FatalUntrustedWorkspaceError退出此时才使用--skip-trust或GEMINI_CLI_TRUST_WORKSPACEtrue临时放行——而不是把它们当成日常启动参数。第二类write_file是全量覆盖省略的部分真的会落盘write_file的语义在 文件系统工具参考 里只有一句话写入内容到指定文件存在则覆盖。覆盖本身不是 bug问题在于模型输出天然倾向于节省改一个 800 行的文件它可能只写出改动附近的内容然后在中间留一行// rest of methods ...如果这行被当成文件内容写进去你的文件就在语法上被截断了。仓库对这个场景是有专门防御的——write-file.ts 在参数校验阶段调用 omissionPlaceholderDetector.ts识别rest of code ...、unchanged methods ...、// rest of method ...这类占位符并直接拒绝本次调用const omissionPlaceholders detectOmissionPlaceholders(params.content); if (omissionPlaceholders.length 0) { return content contains an omission placeholder (for example rest of methods ...). Provide complete file content.; }这恰恰说明它曾经是真实痛点检测器是事后补的补丁而不是从来不会发生。还有一层更隐蔽的行为写入前会走ensureCorrectFileContent对内容做一次模型侧修正转义、缩进等再由 diff 展示。好处是确认框里你看到的就是最终要落盘的文本坏处是——如果你不看清 diff 就按y你批准的并不是模型原始输出而是修正后的版本。怎么防在提示词里明确只允许用replace做局部修改不要重写整文件大文件改动一律走replace让old_string的精确匹配成为你的锚点确认框里的 diff 是最后的关卡看到大面积删除整段-行就按n。第三类replace的匹配歧义改对了字符串、改错了位置replace被设计成精确、局部的工具默认要求old_string在文件中恰好出现一次。edit.ts 里的校验逻辑非常明确if (!params.allow_multiple exactOccurrences 1) { // Failed to edit, expected 1 occurrence but found N }失败信息也写得很到位0 次匹配时提示你如果之前的编辑改动了文件或你要改的行不在最近读取窗口内请先用 ReadFile 检查目标行再重试。真正的风险出现在你主动放开的时候。allow_multiple: true会把所有匹配全部替换——如果你给的是一个足够短、足够常见的片段return null;、if (!user)、一个空行组合它会在多个函数里同时命中。这类修改在事后 review 时极难发现因为每一处单独看都像是改对了。另一类失败来自上下文不足模型凭记忆写old_string与磁盘上的实际文本缩进、行尾、注释存在细微差异触发修正路径修正仍失败后它可能退回到那我用write_file重写整个文件——第二类翻车就此接上第一类。怎么防提示词里要求old_string必须包含至少 5 行上下文除非明确要全局替换否则永远不要建议模型开allow_multiple对关键文件先引用进上下文再让它改。上下文越完整old_string越准回退到整文件重写的概率越低。第四类shell 的破坏半径不受工作区约束文件工具是有边界意识的。config.ts 的validatePathAccess会拒绝工作区与项目临时目录之外的路径Path not in workspace: Attempted path ... resolves outside the allowed workspace directories: ...paths.ts 里还专门写了resolveDefensiveToolPath处理模型给出的src/foo.ts这类引用前缀——如果字面路径不存在会剥掉避免真的创建一个名为src的目录。这些都是文件工具层的防线。但run_shell_command是另一回事。它执行的是你系统上的真实 shell 命令Windows 用powershell.exe -NoProfile -Command其他平台用bash -c工作目录只是起点不是边界。rm -rf ~/xxx、 ../../important.txt、git checkout -- .都可以跨出项目目录。仓库对 shell 做的是识别 提示而不是拦截shell.ts 会检测命令替换语法detectCommandSubstitution命中后直接拒绝执行这是防注入的确认弹窗会解析根命令、列出untrustedFlags未经审查的参数并把构建/测试命令 构建文件被改过标为安全警告write_file改了package.json这类构建文件时会通过recordModifiedBuildFile记账随后跑npm install时弹出提示。最后这条设计很值得注意它防的不是删错文件而是**先改package.json再触发依赖安装这条供应链路径**。这也是为什么只读计划、集中执行的模式在安全上更有意义。怎么防不要对 agent 说帮我清理一下构建产物这种开放式命令改成枚举式删除dist/和.turbo/两个目录首次使用一律default确认模式逐条看命令需要放开时用沙箱而不是用yolo。Sandboxing 明确容器内工作目录以相同绝对路径挂载系统其余部分不可见GEMINI_SANDBOXdocker一行即可。第五类自动批准 默认关闭的 checkpoint等于没有后悔药auto_edit会自动批准replace与write_file只对其他工具如 shell保留询问yolo则批准一切。这两者的定位在 参数表 里写得很清楚--yolo已经标记为 deprecated推荐统一走--approval-mode。它们的共同点是跳过的正是那个能看到 diff 的确认框。而默认状态下write_file/replace执行前的快照checkpoint是关闭的。这两件事叠在一起构成最坏的组合没有 diff 可看也没有快照可退。更细节的一层使用--yolo时沙箱会被默认启用这是仓库里少见的负负得正——放开确认的同时收紧了执行边界。但这个默认只在 yolo 下生效auto_edit并不会自动给你套沙箱。怎么防{ general: { checkpointing: { enabled: true } } }注意文档里的提醒--checkpointing命令行开关在 0.11.0 已被移除只能用settings.json开启。很多人以为开了其实是旧文章里的用法。三、动手前的快照与回滚准备回滚能力分为两套机制边界完全不同混用会出事。Checkpoint文件级的时间点开启后每次你批准一个会修改文件系统的工具write_file、replaceCLI 会自动创建 checkpoint包含三样东西Git 快照提交到~/.gemini/history/project_hash下的影子仓库不影响你自己的.git会话历史即将执行的那次工具调用本身。恢复走/restore/restore /restore 2025-06-22T10-00-00_000Z-my-file.txt-write_file检查点文件名由时间戳、被改文件名、工具名拼成恢复后文件与会话都回到那一刻并且原始工具调用会重新出现让你决定重跑、修改还是放弃。这个重放设计比单纯的文件回滚更有价值你可以改一句提示词然后立刻重试同一步。有一个必须知道的副作用恢复的语义是把项目里所有文件还原到快照状态。如果你在快照之后手动改了别的文件那些改动也会被一起覆盖。所以在/restore之前先把手上的未提交改动处理掉。Rewind会话级的回退/rewind或连按两次Esc是另一套选一个交互点然后选择回退会话和代码、只回退会话、只回退代码。它的边界在 Rewind 里写得很清楚而且是本文最重要的一条警示Rewinding only affects file changes made by the AIs edit tools. It doesnotundo manual edits youve made or changes triggered by the shell tool (!).也就是说rm -rf删掉的东西/rewind救不回来只有编辑类工具造成的改动在它的管辖范围内。第四类翻车恰恰落在它的盲区里。所以正确的准备顺序是进仓库先git status确认工作区干净或者至少知道哪些改动没提交打开 checkpointing对要跑破坏性命令的场景改用沙箱而不是依赖回滚区分清楚编辑失误找/rewind或/restore命令失误只能靠备份或沙箱。四、把风险压到最低配置与提示词1. 用 Plan Mode 做第一次接触Plan Mode 是只读环境默认可用gemini --approval-modeplan它会先研究代码、和你确认策略再写一份 Markdown 计划到 plans 目录按CtrlX可以用外部编辑器直接改计划、写批注。对第一次进这个仓库的场景这比任何提示词都有效——你可以在零写入的前提下看清它打算怎么动手。一个细节值得记住enter_plan_mode工具在 YOLO 模式下不可用。也就是说一旦进了 yolo你就失去了让模型自己退一步做规划的路径。2. 用策略引擎做硬性拒绝策略引擎 支持allow/deny/ask_user三种决策按优先级取最高。放在用户级目录~/.gemini/policies/*.toml[[rule]] toolName run_shell_command commandPrefix rm -rf decision deny priority 100[[rule]] toolName run_shell_command commandRegex git (commit|push) decision ask_user priority 100deny比每次都点拒绝更彻底对全局规则不带argsPattern被拒绝的工具会被完全从模型的工具列表里移除模型根本看不到它既安全又省上下文。两个坑需要提前说明commandPrefix和commandRegex不能写在同一条规则里Workspace 层级的策略目前不生效写在项目.gemini/policies下不会起作用请使用 User 或 Admin 策略。这一点在文档里以警告形式明确标注很容易被忽略。3. 用.geminiignore缩小可见面.geminiignore语法与.gitignore基本一致支持!取反.env local-db-dump.sql /archive/ *.md !README.md但要说清它的性质它约束的是尊重该文件的工具文件发现、搜索、引用等的可见范围文档也明确这些文件对其他服务如 Git仍然可见。不要把它当成权限边界——shell 工具可以直接cat任何文件。它的价值在于减少误读、减少上下文污染以及降低敏感内容被模型顺手带进日志的概率。4. 提示词里写清楚不许做什么配置管的是能力边界提示词管的是意图边界。第一次使用时把这几句固定加在任务前面收益远大于任何调优只修改src/foo.ts其他文件保持不动。使用replace做局部修改不要用write_file重写整个文件。不要执行任何安装、删除、git push或修改 lockfile 的命令。先给出将要修改的位置和 diff 摘要等我确认后再动手。这四条分别对应本文的四类翻车越界修改、全量覆盖、破坏性命令、无确认执行。5. 自动批准只给可重建的工作区auto_edit并非不能用它的适用条件很具体这个仓库可以被一条命令完全重建容器、临时目录、干净的 worktree而且你不介意丢掉未提交的改动。在真实业务仓库里它省下的几次回车抵不上一次误覆盖的排查成本。结语把信任拆成可验证的几步这个类别的工具真正的转折点不是模型变多强而是默认值是否站在不丢数据这一侧。从代码看这个仓库已经准备了相当完整的刹车系统路径校验、占位符检测、匹配次数校验、命令替换检测、构建文件记账、checkpoint、策略引擎、多层沙箱。问题在于这些刹车大多默认不踩checkpoint 关着文件夹信任关着沙箱要显式开。它们更像是给知道自己在做什么的人准备的开关而不是给第一次使用的人准备的护栏。所以第一次使用的正确姿势不是先试试看它能做什么而是先花三分钟做三件事看清仓库里的项目级配置、把工作区变成可回滚的状态、把第一次交互限制在只读模式。能力是它给的边界得你自己划。【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/25 12:22:34 · 阅读 1.2k 会改本地文件的助手，第一次用就可能删错东西：五类高频翻车
会改本地文件的助手第一次用就可能删错东西五类高频翻车【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cliGemini CLI 的定位很直白把模型放进终端允许它读你的仓库、写你的文件、跑你的命令。这种能力的另一面是——它第一次启动时你对它的默认值一无所知而它对你要保护什么也一无所知。社区对它的评价也印证了这种能力先行、可靠性待磨合的阶段特征开源、免费额度大、上手极快但同时接近早期预览版距稳定可靠还有距离。这篇文章不谈跑分只谈一件事一个会落盘修改的 agent在头几次使用时最容易从哪些地方翻车以及仓库里已经写好了哪些刹车。以下所有结论都能在当前仓库源码与文档中找到对应实现涉及的具体文件会以仓库相对路径标注。一、为什么第一次用最危险默认值清单在动手之前先把几个关键默认值摆出来它们共同决定了你第一次运行时的风险基线。行为默认状态依据工具执行确认default逐个询问命令行参数自动批准编辑工具需显式auto_edit或yolo同上Checkpoint修改前快照关闭Checkpointing受信任目录Trusted Folders关闭Trusted Folders沙箱需显式开启SandboxingPlan Mode默认可用可设为默认模式Plan Mode注意这两项的对照关系询问是开的但快照和信任校验是关的。这意味着默认状态下工具调用会停下来问你一旦你因为它在跑测试、它在整理目录而连续按下确认剩下的唯一安全网就是你自己对 diff 的阅读速度。而 Chekpointing 默认关闭意味着那一步点击没有任何可回退的落点。二、五类高频翻车第一类陌生仓库的项目级配置先于你的判断生效这是最容易被忽略、也最第一次的一类。克隆一个仓库、cd进去、直接gemini是所有人的标准起手式。问题在于项目级配置是随仓库一起进来的。Trusted Folders 的文档把机制写得很清楚开启后首次进入某个目录会弹出信任对话框并在**发现阶段discovery phase**列出该项目里的 Commands、MCP Servers、Hooks、Skills以及Setting overrides也就是项目级settings.json对你的全局配置的覆盖如果发现自动批准某些工具或关闭安全沙箱这类危险设置CLI 会显式告警。但这项特性默认是关闭的。默认关闭时你不会看到这个对话框项目配置会按正常工作流加载。一旦文件夹被判定为不受信任防线反而是完整的Trusted Folders 列出了七条限制——不加载.gemini/settings.json、不加载项目.env、禁止扩展装卸、工具自动接受被强制关闭即使你全局开了自动批准、不自动加载内存文件、不连接 MCP、不加载自定义命令。换句话说那个对话框不是多问一句而是这七条限制的总开关。怎么防在跑任何陌生仓库之前先做只读侦察——cat .gemini/settings.json、看有没有.gemini/commands、.gemini/hooks、.gemini/skills。想长期解决就把信任机制打开{ security: { folderTrust: { enabled: true } } }CI/无头场景下没有交互界面未受信任的目录会直接抛FatalUntrustedWorkspaceError退出此时才使用--skip-trust或GEMINI_CLI_TRUST_WORKSPACEtrue临时放行——而不是把它们当成日常启动参数。第二类write_file是全量覆盖省略的部分真的会落盘write_file的语义在 文件系统工具参考 里只有一句话写入内容到指定文件存在则覆盖。覆盖本身不是 bug问题在于模型输出天然倾向于节省改一个 800 行的文件它可能只写出改动附近的内容然后在中间留一行// rest of methods ...如果这行被当成文件内容写进去你的文件就在语法上被截断了。仓库对这个场景是有专门防御的——write-file.ts 在参数校验阶段调用 omissionPlaceholderDetector.ts识别rest of code ...、unchanged methods ...、// rest of method ...这类占位符并直接拒绝本次调用const omissionPlaceholders detectOmissionPlaceholders(params.content); if (omissionPlaceholders.length 0) { return content contains an omission placeholder (for example rest of methods ...). Provide complete file content.; }这恰恰说明它曾经是真实痛点检测器是事后补的补丁而不是从来不会发生。还有一层更隐蔽的行为写入前会走ensureCorrectFileContent对内容做一次模型侧修正转义、缩进等再由 diff 展示。好处是确认框里你看到的就是最终要落盘的文本坏处是——如果你不看清 diff 就按y你批准的并不是模型原始输出而是修正后的版本。怎么防在提示词里明确只允许用replace做局部修改不要重写整文件大文件改动一律走replace让old_string的精确匹配成为你的锚点确认框里的 diff 是最后的关卡看到大面积删除整段-行就按n。第三类replace的匹配歧义改对了字符串、改错了位置replace被设计成精确、局部的工具默认要求old_string在文件中恰好出现一次。edit.ts 里的校验逻辑非常明确if (!params.allow_multiple exactOccurrences 1) { // Failed to edit, expected 1 occurrence but found N }失败信息也写得很到位0 次匹配时提示你如果之前的编辑改动了文件或你要改的行不在最近读取窗口内请先用 ReadFile 检查目标行再重试。真正的风险出现在你主动放开的时候。allow_multiple: true会把所有匹配全部替换——如果你给的是一个足够短、足够常见的片段return null;、if (!user)、一个空行组合它会在多个函数里同时命中。这类修改在事后 review 时极难发现因为每一处单独看都像是改对了。另一类失败来自上下文不足模型凭记忆写old_string与磁盘上的实际文本缩进、行尾、注释存在细微差异触发修正路径修正仍失败后它可能退回到那我用write_file重写整个文件——第二类翻车就此接上第一类。怎么防提示词里要求old_string必须包含至少 5 行上下文除非明确要全局替换否则永远不要建议模型开allow_multiple对关键文件先引用进上下文再让它改。上下文越完整old_string越准回退到整文件重写的概率越低。第四类shell 的破坏半径不受工作区约束文件工具是有边界意识的。config.ts 的validatePathAccess会拒绝工作区与项目临时目录之外的路径Path not in workspace: Attempted path ... resolves outside the allowed workspace directories: ...paths.ts 里还专门写了resolveDefensiveToolPath处理模型给出的src/foo.ts这类引用前缀——如果字面路径不存在会剥掉避免真的创建一个名为src的目录。这些都是文件工具层的防线。但run_shell_command是另一回事。它执行的是你系统上的真实 shell 命令Windows 用powershell.exe -NoProfile -Command其他平台用bash -c工作目录只是起点不是边界。rm -rf ~/xxx、 ../../important.txt、git checkout -- .都可以跨出项目目录。仓库对 shell 做的是识别 提示而不是拦截shell.ts 会检测命令替换语法detectCommandSubstitution命中后直接拒绝执行这是防注入的确认弹窗会解析根命令、列出untrustedFlags未经审查的参数并把构建/测试命令 构建文件被改过标为安全警告write_file改了package.json这类构建文件时会通过recordModifiedBuildFile记账随后跑npm install时弹出提示。最后这条设计很值得注意它防的不是删错文件而是**先改package.json再触发依赖安装这条供应链路径**。这也是为什么只读计划、集中执行的模式在安全上更有意义。怎么防不要对 agent 说帮我清理一下构建产物这种开放式命令改成枚举式删除dist/和.turbo/两个目录首次使用一律default确认模式逐条看命令需要放开时用沙箱而不是用yolo。Sandboxing 明确容器内工作目录以相同绝对路径挂载系统其余部分不可见GEMINI_SANDBOXdocker一行即可。第五类自动批准 默认关闭的 checkpoint等于没有后悔药auto_edit会自动批准replace与write_file只对其他工具如 shell保留询问yolo则批准一切。这两者的定位在 参数表 里写得很清楚--yolo已经标记为 deprecated推荐统一走--approval-mode。它们的共同点是跳过的正是那个能看到 diff 的确认框。而默认状态下write_file/replace执行前的快照checkpoint是关闭的。这两件事叠在一起构成最坏的组合没有 diff 可看也没有快照可退。更细节的一层使用--yolo时沙箱会被默认启用这是仓库里少见的负负得正——放开确认的同时收紧了执行边界。但这个默认只在 yolo 下生效auto_edit并不会自动给你套沙箱。怎么防{ general: { checkpointing: { enabled: true } } }注意文档里的提醒--checkpointing命令行开关在 0.11.0 已被移除只能用settings.json开启。很多人以为开了其实是旧文章里的用法。三、动手前的快照与回滚准备回滚能力分为两套机制边界完全不同混用会出事。Checkpoint文件级的时间点开启后每次你批准一个会修改文件系统的工具write_file、replaceCLI 会自动创建 checkpoint包含三样东西Git 快照提交到~/.gemini/history/project_hash下的影子仓库不影响你自己的.git会话历史即将执行的那次工具调用本身。恢复走/restore/restore /restore 2025-06-22T10-00-00_000Z-my-file.txt-write_file检查点文件名由时间戳、被改文件名、工具名拼成恢复后文件与会话都回到那一刻并且原始工具调用会重新出现让你决定重跑、修改还是放弃。这个重放设计比单纯的文件回滚更有价值你可以改一句提示词然后立刻重试同一步。有一个必须知道的副作用恢复的语义是把项目里所有文件还原到快照状态。如果你在快照之后手动改了别的文件那些改动也会被一起覆盖。所以在/restore之前先把手上的未提交改动处理掉。Rewind会话级的回退/rewind或连按两次Esc是另一套选一个交互点然后选择回退会话和代码、只回退会话、只回退代码。它的边界在 Rewind 里写得很清楚而且是本文最重要的一条警示Rewinding only affects file changes made by the AIs edit tools. It doesnotundo manual edits youve made or changes triggered by the shell tool (!).也就是说rm -rf删掉的东西/rewind救不回来只有编辑类工具造成的改动在它的管辖范围内。第四类翻车恰恰落在它的盲区里。所以正确的准备顺序是进仓库先git status确认工作区干净或者至少知道哪些改动没提交打开 checkpointing对要跑破坏性命令的场景改用沙箱而不是依赖回滚区分清楚编辑失误找/rewind或/restore命令失误只能靠备份或沙箱。四、把风险压到最低配置与提示词1. 用 Plan Mode 做第一次接触Plan Mode 是只读环境默认可用gemini --approval-modeplan它会先研究代码、和你确认策略再写一份 Markdown 计划到 plans 目录按CtrlX可以用外部编辑器直接改计划、写批注。对第一次进这个仓库的场景这比任何提示词都有效——你可以在零写入的前提下看清它打算怎么动手。一个细节值得记住enter_plan_mode工具在 YOLO 模式下不可用。也就是说一旦进了 yolo你就失去了让模型自己退一步做规划的路径。2. 用策略引擎做硬性拒绝策略引擎 支持allow/deny/ask_user三种决策按优先级取最高。放在用户级目录~/.gemini/policies/*.toml[[rule]] toolName run_shell_command commandPrefix rm -rf decision deny priority 100[[rule]] toolName run_shell_command commandRegex git (commit|push) decision ask_user priority 100deny比每次都点拒绝更彻底对全局规则不带argsPattern被拒绝的工具会被完全从模型的工具列表里移除模型根本看不到它既安全又省上下文。两个坑需要提前说明commandPrefix和commandRegex不能写在同一条规则里Workspace 层级的策略目前不生效写在项目.gemini/policies下不会起作用请使用 User 或 Admin 策略。这一点在文档里以警告形式明确标注很容易被忽略。3. 用.geminiignore缩小可见面.geminiignore语法与.gitignore基本一致支持!取反.env local-db-dump.sql /archive/ *.md !README.md但要说清它的性质它约束的是尊重该文件的工具文件发现、搜索、引用等的可见范围文档也明确这些文件对其他服务如 Git仍然可见。不要把它当成权限边界——shell 工具可以直接cat任何文件。它的价值在于减少误读、减少上下文污染以及降低敏感内容被模型顺手带进日志的概率。4. 提示词里写清楚不许做什么配置管的是能力边界提示词管的是意图边界。第一次使用时把这几句固定加在任务前面收益远大于任何调优只修改src/foo.ts其他文件保持不动。使用replace做局部修改不要用write_file重写整个文件。不要执行任何安装、删除、git push或修改 lockfile 的命令。先给出将要修改的位置和 diff 摘要等我确认后再动手。这四条分别对应本文的四类翻车越界修改、全量覆盖、破坏性命令、无确认执行。5. 自动批准只给可重建的工作区auto_edit并非不能用它的适用条件很具体这个仓库可以被一条命令完全重建容器、临时目录、干净的 worktree而且你不介意丢掉未提交的改动。在真实业务仓库里它省下的几次回车抵不上一次误覆盖的排查成本。结语把信任拆成可验证的几步这个类别的工具真正的转折点不是模型变多强而是默认值是否站在不丢数据这一侧。从代码看这个仓库已经准备了相当完整的刹车系统路径校验、占位符检测、匹配次数校验、命令替换检测、构建文件记账、checkpoint、策略引擎、多层沙箱。问题在于这些刹车大多默认不踩checkpoint 关着文件夹信任关着沙箱要显式开。它们更像是给知道自己在做什么的人准备的开关而不是给第一次使用的人准备的护栏。所以第一次使用的正确姿势不是先试试看它能做什么而是先花三分钟做三件事看清仓库里的项目级配置、把工作区变成可回滚的状态、把第一次交互限制在只读模式。能力是它给的边界得你自己划。【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考