做错了功能

换成了自己的方案，被指出后立刻说“你说得完全对”

Swapped in its own approach, then "You're absolutely right"

你点名了想要的方案，智能体却提出或实现了另一种；你一指出，它马上附和，既不解释也不重新核对。

适用于: Claude Code · Cursor · Codex · Copilot agent

症状

计划或 diff 用了一个它更熟悉的替代方案（某个平台专用的链接、你没选的库、别的代码库里的套路），而不是你要求的那个。你纠正后，它回一句“你说得完全对”就重写，从不交代为什么偏离。

为什么会这样

在 Thorsten Ball 的《你们为什么还在用 Pull Request？》帖子下，@StanleyMasinde_ 讲了一个例子：他建议给活动邮件附上 ICS 文件，让任何邮件客户端都能自动加入日历；智能体却建议用 Google 日历的 intent 链接，被指出后回了一句 “you're absolutely right to point that out”。他的结论是：代码审查已经不是看语法，而是看业务逻辑。Thorsten Ball 回复说他们团队也会发现 bug，只是不靠 PR。串里其他人也说到同样的反射：智能体“总是同意我”（@adebola_io），“一被质疑，所有模型都承认自己错了”（@danielh164）。附和成本很低，所以它不能证明智能体理解了需求。

示例

根据 @StanleyMasinde_ 的帖子转述；代码为示意。

text

Asked:  attach an .ics file to event emails so mail clients can add it to the calendar
Agent:  adds a "Add to Google Calendar" intent link (works for one provider only)
You:    "I asked for an ICS attachment."
Agent:  "You're absolutely right to point that out!"  (rewrites, no explanation)

复制即用的修复

按你用的智能体挑选文件。规则片段用英文写，放进任何仓库都能用。

规则

Claude Code：加入 CLAUDE.md

CLAUDE.md

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

规则

Codex、Copilot 编码智能体等：加入 AGENTS.md

AGENTS.md

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

Cursor 规则

Cursor：项目规则

.cursor/rules/swapped-approach-then-agreed.mdc

---
description: "AgentFails: Swapped in its own approach, then 'You're absolutely right'"
alwaysApply: true
---

## Use the approach the user named
- If the user named an approach, format, library or protocol, use exactly that one.
- If you think another approach is better, say so before writing code: name both, give the
  trade-off in one or two lines, and wait for the user to choose. Do not substitute silently.
- When the user corrects you, do not just agree. State what you did, what was asked, why they
  differ, and what you will change. Then re-check the rest of the change for the same mistake.
- In your summary, list every place where your implementation differs from what was asked.

模板

SPEC.md 验收标准（先写、先确认，再写代码）

队友直接在这个文件（或设计稿/产物）上批注，而不是事后审一个大 PR。每条验收标准都要能区分“你要的理解”和“你不要的理解”。

SPEC.md

# Spec: <feature name>

## Goal (one sentence, in the user's words)

## Out of scope
- <things a reasonable agent might also do, but must not>

## Acceptance checks (each one runnable)
- [ ] Given <input>, when <action>, then <exact observable result>
- [ ] Example that rules out the wrong reading: <input> -> <expected>, NOT <plausible wrong output>
- [ ] Command that proves it: `<test or curl command>`

## Open questions (agent must ask, not assume)
- <question>

## Approved by: <name> on <date>

技能

全新上下文的审查技能（子智能体只看 diff，不看聊天记录）

沿用 Anthropic 代码审查文章里的做法：先验证，再让一个上下文干净的子智能体审 diff。命名为 review-diff，避免和内置或流行的 /code-review 技能重名。

.claude/skills/review-diff/SKILL.md

---
name: review-diff
description: Review the current diff with fresh context before a PR. Use after /verify passes.
---

# Review the diff

Start a subagent that has NOT seen this conversation. Give it only:
- the original request (one paragraph, verbatim),
- the output of `git diff origin/main...HEAD`,
- the names of the test/build commands.

Ask it to report, with file:line for each finding:
1. **Wrong feature**: does the diff do what the request asked? Quote the request line each change serves.
2. **Bugs**: logic errors, missing edge cases (empty, null, boundary), unhandled errors,
   unawaited promises, invented APIs or packages, swallowed exceptions.
3. **Overreach**: changes no request line needs (refactors, renames, formatting, dependency or
   config edits, public API changes, weakened tests).
4. **Evidence gaps**: claims in the PR description that no command output supports.

Then fix real findings, or list them under "Known issues" in the PR. Do not argue with the reviewer
in the PR text; either fix or explain in one line.

来源与致谢

在 GitHub 上改进这条遇到了、但修复没用？告诉我们