Composer agent 跑了一条 npm test，输出”3 passing”，它说”全部通过 ✅“。你打开终端跑同一命令——10 failing。或者它 cd packages/web && npm install，几秒后说装完了，你 ls node_modules 发现根本没装。Cursor 的 agent 终端不是你日常 zsh 的完美映射：它有独立 cwd 状态、不一定 source 你的 .zshrc、长输出会被截断、连续命令的 shell state 也可能不持久。
修法是把”假设它自动知道”换成”prompt 里显式告诉”。
常见原因
1. Working directory 不是你以为的那个
agent 新开终端 session 默认在 workspace 根。你以为它在 packages/web/，它其实在 monorepo 根，npm test 跑成了另一个包。
如何判断：让 agent 跑 pwd 再说话；对照你期望的目录。
2. agent 用 npm 但项目是 pnpm / yarn / bun
训练 prior 默认 npm。仓库有 pnpm-lock.yaml 它也可能视而不见，跑 npm install 把 lockfile 全乱了。
如何判断：
ls *-lock.* 2>/dev/null
# 看是 pnpm-lock.yaml / yarn.lock / bun.lockb / package-lock.json 哪个agent 跑命令前没看到对应工具 = prior 占上风。
3. .envrc / direnv / .env 没在 agent shell 里加载
direnv 靠 shell hook 触发；Cursor agent 起的 subprocess 可能不加载。process.env.DATABASE_URL 在 agent 跑里是 undefined。
如何判断：让 agent 跑 env | grep MY_VAR；空 = 没加载。
4. 长输出被截断，agent 看到的不全
Cursor 把 stdout 截到一定行数（通常几百行）后扔给模型。test 输出 5000 行时它只看到前 500，可能恰好是 “Running tests…” 之类无信息部分。
如何判断：让它 echo last 50 lines，对比真实输出尾部是否被截。
5. 后台进程污染 terminal
之前 agent 起了 npm run dev，没杀掉，新命令出现在它的 log 输出里，agent 混淆。
如何判断：lsof -i :3000 或 ps aux | grep node 看有没有遗留。
6. 命令成功 ≠ 业务正确
npm install 退出码 0、git push 报 “Everything up-to-date”——agent 把退出码当结果，不真正校验后果。
如何判断：agent 说成功后你手动验证（curl 接口、看页面、查数据库）—— 不一致就是它没真正验证。
动手前先确认
- 区分是 Composer agent 自动跑的还是你手动让 Cursor terminal 跑的——前者经常没 source 完整 shell init。
- 复现前 commit 一次或开 branch，避免错命令污染仓库。
- 记下 Cursor 版本、当前模型、是 agent 还是 chat。
需要收集的信息
- agent 跑的命令全文 + 它显示的输出 + 它的结论。
- 你手动跑同命令的真实输出。
- 仓库的 lock 文件类型（pnpm-lock.yaml 等）。
- 是否用 direnv /
.envrc。 - 是否有 background process 残留。
最短修复路径
按”先验证状态 → 后纠正用法”。
Step 1：让 agent 自己核验状态
把 agent 跑命令的标准前缀固定下来：
Before running any command, first run and report:
1. `pwd` — confirm working directory
2. `which pnpm npm yarn bun` — confirm package manager available
3. `cat package.json | grep \"name\"` — confirm correct package
Only proceed if all three match the expected target.Step 2：显式指定包管理器 + 路径
Run this exact command, do NOT substitute:
cd packages/web && pnpm test -- --run--run 一类 flag 避免 watch 模式挂住。永远 cd 而不是依赖 cwd。
Step 3：把 env 显式 source
direnv 项目里：
Before running any code that needs env vars, source .envrc explicitly:
source .envrc && env | grep DATABASE_URL
Verify the var is set, then run the actual command.或一开始把所有需要的 env 列在 .cursorrules 里让模型知道：
# .cursorrules
This project requires the following env vars:
- DATABASE_URL
- REDIS_URL
- STRIPE_SECRET_KEY
To load them: `source .envrc` (uses direnv) or `set -a && . .env && set +a` (uses dotenv).
You MUST verify these are set before any database / API command.Step 4：让 agent 跑测试的输出尾部
After running `pnpm test`, run:
tail -100 <(pnpm test 2>&1)
Or pipe to a file:
pnpm test > /tmp/test-output.log 2>&1; tail -200 /tmp/test-output.log避免截断丢关键信息。
Step 5：清理 background process
# 找到端口占用
lsof -i :3000
# 杀进程
kill -9 <PID>
# 或一次性杀所有 node
pkill -f nodeagent 重启 dev server 前先 lsof -i :3000 看是否已有再决定 kill。
Step 6：让 agent 做业务级验证，不要只看退出码
After `npm install`, verify by:
ls node_modules | wc -l # should be > 100
cat node_modules/.package-lock.json | jq '.packages | length'
After `git push`, verify by:
git log origin/main --oneline | head -3 # should show your commitStep 7：用 package.json scripts 当唯一入口
把所有常用命令放进 package.json scripts：
"scripts": {
"dev": "...",
"test": "vitest run",
"build": "vite build",
"db:migrate": "prisma migrate deploy"
}prompt 改成”run pnpm test”而不是”run vitest run”。脚本一旦改动，所有 prompt 自动跟上。
怎么确认已经修好
- 重启 Cursor 后再触发一次原操作，确认不是会话内的临时状态。
- 切换到另一个仓库 / 另一台机器复现，区分是 Cursor 配置问题还是项目本身问题。
- 让同事打开同一个仓库重试，确认不是只有你的本地缓存被修好。
如果还是没修好
- 把复现缩到最小：一条命令 + 一次
pwd。 - 回滚最近一次
.cursorrules或 settings.json 改动。 - 在 forum.cursor.com 搜 “agent terminal wrong dir” / “agent didn’t see env”；附 prompt + 输出。
- 抓 View → Output → Cursor 的 agent 日志贴 Bug Reports。
预防建议
.cursorrules里固定写 “Always pwd before any command” + 包管理器名 + env 加载方式。- 一个仓库只用一个包管理器；删冗余 lock 文件。
- 复杂命令永远走
package.jsonscripts，不让 agent 直接拼底层命令。 - 后台 dev server 用
tmux/screen/ VS Code 独立 task 跑，别留在 agent terminal 里。 - agent 说”完成”后 prompt 它做业务级验证（接口 / 数据 / 文件存在），不只是退出码。