示例能跑，边界就崩
Works on the example, breaks on the edges
智能体实现到示例能通过就停了。空输入、null、边界值和失败路径都没处理。
适用于: Claude Code · Cursor · Codex · Copilot agent
症状
遇到空列表、文件不存在、JSON 不合法、首尾元素就崩。演示时明明是好的。
为什么会这样
“智能体只关注顺利路径。它们实现到示例通过就停了。”（agent-review）。该分类列了 AR029（缺少边界情况）和 AR030（未处理的错误路径）。
示例
摘自 agent-review 分类（AR029、AR030）。
tsfunction median(xs: number[]): number {
return xs[xs.length / 2 | 0]; // empty? even-length? unsorted?
}
const cfg = JSON.parse(fs.readFileSync("cfg.json", "utf8"));
// throws if file missing or JSON invalid
复制即用的修复
按你用的智能体挑选文件。规则片段用英文写，放进任何仓库都能用。
规则
Claude Code：加入 CLAUDE.md
CLAUDE.md## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
规则
Codex、Copilot 编码智能体等：加入 AGENTS.md
AGENTS.md## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
Cursor 规则
Cursor：项目规则
.cursor/rules/happy-path-only.mdc---
description: "AgentFails: Works on the example, breaks on the edges"
alwaysApply: true
---
## Edge cases are part of the task
- For every function you write or change, list its edge cases (empty, null/undefined, zero,
boundary values, very large input, invalid format, I/O failure) and either handle each or say why it can't happen.
- Add at least one test for an edge case and one for a failure path, not only the happy path.
- Every new network, file or parse call needs an explicit failure behavior.
技能
全新上下文的审查技能（子智能体只看 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.