同一句提示词跑两遍结果不一样，我用 3 条命令锁死

大家好，我是Zack。

前几天我让 agent 给 AIHOT 加个小功能，提示词就一句话：「把站点流量统计加上，改一下相关文件。」

跑完它动了 9 个文件。第二天原样重跑一遍，这次动了 6 个，两次只有 3 个重合。

一开始我以为是模型抽风，后来发现不是：「相关文件」这四个字谁说了算，我根本没说。

同一句提示词跑两遍结果不一样，八成不是模型的问题，是我留给它的不确定太多。

这类不确定集中在三处：改哪些文件、装哪个版本、留下哪些垃圾。 三处各用一条命令定死。

一、原来的做法：找文件也交给它

我以前的提示词都这么写：

看一下这个项目，把站点流量统计加上，相关文件都改一下。

听起来清楚，其实三处全交给它猜了。

哪些文件算「相关」。 它得先列目录再挑文件读。500 多文件的仓库，它一次能顺手读十几个，一半跟这事没关系。上下文被占满，真正要改的地方反而写得糙。

装哪个版本。 让它装依赖，它写 npm i xxx，装的是当天最新版。下周跑同一句，装回来的可能就不是同一个包。

跑完留下什么。 我习惯 git add . 一把梭，它生成的临时文件、.bak 备份全进了提交，review 的人分不清哪个是我真要改的。

二、换成三条命令

1. 动手前先用 rg 把文件清单定死

rg -n "traffic" -l

rg 是比 grep 快很多的搜索工具（Rust 写的），-n 带行号，-l 只输出文件名。

只输出文件名很关键：我要的是一份能贴进提示词的清单，不是一大段匹配内容。

实测一次（AIHOT：521 个被跟踪文件，含未跟踪共 720 个）：

$ time (rg -n "agent" -l -i | wc -l)
72
( ... )  0.00s user 0.02s system 276% cpu 0.009 total

0.009 秒，列出 72 个文件。 同样的事换 grep -ril，同样结果，耗时 0.35 秒 —— 差了约 39 倍。

快不是重点，重点是清单是我给的，不是它猜的。现在提示词长这样：

只改下面这几个文件，不要动其它任何文件：
- apps/api/src/routes/traffic.ts
- apps/web/app/components/SiteTraffic.tsx
- packages/backend/src/publication/traffic.ts
- tests/traffic.test.ts

如果这些文件不够用，先停下告诉我缺哪个，不要自己去找。

不给最后那句，它发现文件不够时还是会自己翻，清单就白给了。

2. 装依赖写精确版本，别写 ^

提示词里我现在写死一句：

装依赖一律写精确版本号（npm i xxx@1.20.0 -E），不要出现 ^ 和 ~。
装完必须把 package-lock.json 一起提交。

-E 是 --save-exact 的简写，装完 package.json 里写的是 "axios": "1.20.0"，不是 "axios": "^1.20.0"。

一个字符的差别：^1.20.0 是「1.x 里最新都行」，1.20.0 是「就这一个」。

查一下今天的最新版做对照：

$ npm view typescript version
7.0.2

AIHOT 的 package.json 里正好是精确版本：

"devDependencies": {
  "@modelcontextprotocol/client": "2.1.0",
    "typescript": "7.0.2"
}

没有 ^，没有 ~。半年后 clone 下来重装，装到的还是这几版。

装完再补一眼，确认锁文件真动了：

git diff --stat package-lock.json

没输出反而要警觉：说明它没走包管理器。Python 同理，写 requests==2.32.3，别写 >=。

3. 跑完先 `git clean -nd` 看一遍，再清

这条是今天最有感的一条。agent 跑完，我不再直接 git add .，先跑：

git clean -nd

-n 是 dry-run，只打印「将要删除什么」，一个字节都不动；-d 连目录一起列。

今天在 AIHOT 跑出来的（节选，一共 24 项）：

$ git clean -nd
Would remove android/AndroidManifest.xml
Would remove apps/api/src/routes/traffic.ts
Would remove scripts/__pycache__/
Would remove scripts/us-close-report.py
...

这 24 项里，只有 scripts/__pycache__/ 是真垃圾。

android/ 整个目录、traffic.ts、迁移文件、测试文件，全是我还没提交的工作成果。

按老习惯直接 git clean -fd，这二十几项一次全没，回收站都找不回来。

看清后再决定清哪些：

git clean -fd                    # 确认全是垃圾再执行
git clean -fd -e "android/"      # 排除某个目录

三、前后对比

	改之前	改之后
改动范围谁定	它自己找，两次跑出 9 个 / 6 个文件	我给清单，两次都是清单里那几个
拿清单耗时	—	0.009 秒（521 文件仓库）
依赖版本	`^1.20.0`，下次可能变	`1.20.0`，锁文件一起提交
提交里的无关文件	每次手动挑一遍	先看 24 项预览再清
误删风险	直接 `-fd`	先 `-nd`，本次拦下 20+ 项未提交工作

诚实说一句：这是这一周在两三个仓库上记的数，样本很小，别当统计结论看。

而且这三招只管「输入不确定导致的返工」，管不了需求本身没想清楚 —— 那种跑多少遍都是错，命令救不了。

四、两条能迁移到自己工作里的原则

第一条：能在动手前定死的东西，别留到跑完再检查。

文件清单、版本号、改动范围，写提示词时就能定。判断方法：这句话里还有没有「相关」「适当」「一些」，有就说明没定死。

第二条：凡是会删东西的命令，先加一次 dry-run。

git clean -nd、--dry-run、rm 先换成 ls。多花 3 秒看清单，省的是找回文件那半小时。

我给 agent 定的规矩：删除、覆盖、批量改名的脚本必须支持干跑参数，没有的我不收。

你最近一次让 agent 返工，最后发现是哪一处没定死？

欢迎在留言里说说，我一条条看。

公众号：Zack说AI

大厂程序员，现独立开发者，分享 AI 技术与过程。每篇讲一个能落地的提效做法。

Think Deep,Work Lean

目录