第一次让桌面端 Agent 动真实项目，最该先确定的不是提示词怎么写，而是它的工作范围在哪里。MiniMax Code 这类桌面端编码 Agent 通常以你打开的项目目录为根，读取其中的文件作为上下文，再按指令修改文件；它能看到哪些文件、能写哪些文件，很大程度取决于项目根目录的设置和忽略规则。把范围收紧到“一个仓库”，再用忽略规则挡住构建产物和密钥文件，最后要求它先列改动清单、改完逐个文件比对 diff，是成本较低的一套起手流程。涉及具体设置项名称和菜单位置，以你本地实际界面为准，本文只给通用骨架。

让桌面端 Agent 接手真实项目时，先做三件事：确认会话的根目录是项目仓库本身而不是整个磁盘；用忽略规则挡掉构建产物、依赖目录和密钥文件；要求它先输出待改文件清单再动手。改动落地后用 git status 与 git diff 逐文件核对，发现多余改动按文件回退。这套做法的边界是：范围控制能减少误改，但不能替代你自己审阅 diff，也不适合在未提交任何改动的脏工作区里进行。

在项目根目录确认 Agent 的起始工作范围

桌面端 Agent 的上下文通常和“打开方式”绑定：你是打开一个文件夹，还是打开单个文件，决定了它默认从哪一层开始读。如果直接把用户主目录或整个磁盘挂载点作为工作区打开，它理论上可以把大量无关文件读进上下文，既拖慢响应，也提高误改概率。建议始终先打开项目仓库根目录，再在该目录下发起会话。

• 打开方式：在桌面端选择“打开文件夹/打开项目”一类入口，选中仓库根目录（即包含 .git 的那一层），而不是选中某个子目录或单个源文件。
• 会话内确认：多数工具会在会话面板或标题区显示当前工作目录的绝对路径。先看清这一段路径是否以你的项目名结尾，再输入第一条指令。
• 判断标准：如果显示的路径是你机器上的家目录、下载目录或某个盘符根，说明范围过大，应关闭会话重新从项目根目录打开。

不确定时，可以在第一条消息里直接让它报出工作目录与顶层目录列表，用返回结果和你在文件管理器里看到的结构对照。这一步不做验证，后面所有忽略规则和 diff 核对都会建立在错误的前提上。

用忽略规则把生成产物和密钥文件挡在外面

忽略规则的作用是减少无关文件进入上下文，也降低它们被顺带改写的概率。很多桌面端 Agent 会读取项目里的 .gitignore，或支持一份独立的忽略配置文件；具体文件名和读取优先级以实际界面说明为准。可以先写一份通用的骨架，放在项目根目录：

# 依赖与构建产物
node_modules/
dist/
build/
out/
*.log

# 本地环境与密钥
.env
.env.*
*.pem
*.key
secrets/

# 编辑器与系统文件
.vscode/
.idea/
.DS_Store

# 大体积数据与快照
coverage/
*.sqlite
*.dump

放置位置建议就在项目根目录，与 .gitignore 同级；如果你的工具只认 .gitignore，就把上述条目合并进去，并在提交前确认这些规则本身也进了版本库。验证是否生效的办法很直接：在新会话里让它“列出当前可见的项目文件清单，不要读取内容，只给路径”，然后检查 node_modules、dist、.env 这类条目是否已经从清单里消失。如果仍然出现，说明忽略规则没有被读取，需要回到工具的设置页确认它指向的是哪个文件。

需要注意的边界：忽略规则通常只是不让文件进入上下文，并不等于禁止写入。真正防止误改的仍是后面的清单确认和 diff 核对。密钥文件尤其不要依赖单一手段，建议本来就排除在仓库之外。

要求先输出待改文件清单再动手

把改动范围从黑箱变成可审阅的清单，最省事的做法是在第一条指令里就把顺序固定下来。下面这段提示词模板可以直接替换任务描述后使用：

任务：<用一两句话描述要改的功能或要修的 bug>

执行约束：
1. 先不要修改任何文件。
2. 只读取项目根目录内的内容，忽略规则中的文件不要读。
3. 输出一份待改文件清单，字段为：文件路径、改动理由、预计改动位置（函数或行范围）。
4. 清单外如有你认为必须改的文件，单独列在“待确认”里并说明原因。
5. 等我回复“确认”后再开始修改。

清单至少要能回答两件事：每个文件的改动理由是否和任务直接相关，以及是否存在任务之外的“顺手优化”。人工确认时可以按三条判断：第一，清单里每个路径都在你预期的模块范围内；第二，没有出现配置、依赖锁文件、构建脚本这类高风险文件的非必要改动；第三，改动位置描述足够具体，而不是笼统写“修改相关逻辑”。任一条不满足，就把清单退回让它补充说明，而不是先让它改完再说。

改动落地后逐文件比对 diff

Agent 报告“已完成”之后，先不要继续下一个任务，而是回到终端做一次核对。最基础的组合是：

# 看整体有哪些文件被改动
git status `--short`

# 看全部未暂存的改动内容
git diff

# 按文件逐个查看
git diff -- path/to/file.ts

# 只看被改动的行，快速扫一遍
git diff -U0

逐个文件查看时，重点盯三类地方：与任务无关的格式化改动（缩进、引号、换行）、被顺带删掉的注释或日志、以及看起来像“优化”但没在清单里出现过的函数调整。发现多余改动时，如果只想回退单个文件：

git checkout -- path/to/file.ts
# 或较新版本 git 中
 git restore path/to/file.ts

如果整个改动方向都不对，想全部推倒重来，可以用 git restore . 或 git checkout .，但要先确认工作区里没有你自己未提交的改动，否则会一并丢失。稳妥做法是每次让 Agent 动手之前，先提交一次或至少 git stash 一次当前进度，这样回退的边界才是清晰的。

把确认过的范围写进项目说明复用

每次新会话都重新交代边界很费口舌，可以把它固化成项目根目录下的一份说明文件（例如 AGENTS.md、README 中的专门小节，或工具约定的说明文件名，以实际支持情况为准）。建议至少包含三块内容：

• 可读目录：说明哪些目录属于业务代码、可以读取和修改，例如 src/、tests/。
• 禁止改动目录：列出构建产物、依赖目录、密钥与环境文件、数据库快照等，明确要求不读也不写。
• 验证命令：写清改完之后跑哪条命令做检查，例如构建命令、单元测试命令、静态检查命令，方便 Agent 自检而不是凭感觉收工。

下次会话验证它是否读到这份说明，可以用一句简短提问：“复述本项目允许修改的目录和禁止改动的目录，不要执行任何写操作。”如果回答与说明文件一致，说明说明文件已进入上下文；如果回答含糊或遗漏，就回到文件位置和命名上排查，而不是在提示词里反复重复同样的规则。