不是让 AI 变诚实，而是让它每次下结论前都留下证据。
Claude Code 最烦人的地方，不是写错代码。
写错代码反而好办。类型检查会报错，测试会失败，编辑器会飘红。真正麻烦的是另一种情况：它把没验证过的东西，说得像真的。
比如它会编一个项目里并不存在的函数名，写一个看起来很合理的 import，告诉你“测试已经通过”，但实际根本没跑。你看第一眼会觉得它很自信，第二眼才发现它是在一本正经地胡说。
这也是很多人用 AI 编程助手时最容易踩的坑：模型不是不会写，而是太会把猜测包装成结论。它生成的代码像真的，解释像真的，甚至连错误信息都像真的。等你开始排查，一个不存在的 API 可能已经浪费了半小时。
所以这篇文章不讨论怎么让 Claude Code “更聪明”。我更关心另一个问题：怎么让它少胡说。
我的结论是，不能只靠 prompt 哄它诚实。更有效的办法，是给它一套工程约束：规则写在前面，写代码前先验证，写完自动检查，最后再用一个独立角色复核事实。
简单说，就是下面这 4 层。
第一层：把诚实规则写进 CLAUDE.md
CLAUDE.md 是 Claude Code 读取项目上下文和长期指令的地方。很多人会在里面写项目结构、启动命令、编码规范，但我建议把“诚实规则”放在更靠前的位置。
原因很简单：越重要的约束，越不要埋在长文档后面。你可以把下面这段放到项目根目录的 CLAUDE.md 前面。
## Honesty rules
Before claiming a function, class, type, import, file, command, API,
or test result exists, verify it first.
If you have not verified something, say "I have not verified this".
Do not write code that depends on an unverified claim.
Do not claim tests, builds, lint, or type checks passed unless you
actually ran the command in this session and saw the result.
Never invent error messages, stack traces, API responses, package names,
or file paths. If you did not see it, say so.
When you genuinely do not know, say "I do not know yet" and check first.
这段话的价值，不在于它能神奇地让模型永远不犯错。它真正改变的是默认行为。
如果没有这类规则，模型面对不确定信息时，最自然的动作是继续生成一段“看起来合理”的文本。它不知道某个函数是否存在，但它知道项目里大概会有一个类似名字的函数。它不知道测试有没有跑过，但它知道用户通常期待一句“测试通过”。
诚实规则的作用，是把“继续猜”改成“先承认没验证”。这一步听起来很朴素，但对 AI 编程助手非常关键。
很多时候，Claude Code 胡说不是因为它坏，而是因为我们默认它必须立刻给答案。你越要求它马上完成，它越容易跳过验证。你越允许它说“我需要先查一下”，它越有机会变得可靠。
第二层：写代码前先验证
只写诚实规则还不够。因为“不要胡说”仍然是抽象要求，模型很容易在执行时滑过去。
所以第二层要更具体：凡是要用到函数、类、类型、常量、依赖、配置项，都先验证。
可以继续在 CLAUDE.md 里加一段验证协议。
## Verification protocol
Before writing or editing code that uses a symbol, do at least one:
1. Read the file where the symbol is defined and confirm its signature.
2. Search the repo for the exact symbol name.
3. Check the dependency manifest before using a package.
4. If the claim depends on runtime behavior, run the relevant command.
If verification is skipped, label the claim as unverified instead of
presenting it as fact.
这一步会多花几个 tool call，但通常比后面排查假代码便宜。
举个常见场景。Claude Code 想写：
import { validateToken } from "@/lib/auth";
如果它没有先看过 @/lib/auth，这行代码就只是一个看起来顺眼的猜测。真正可靠的流程应该是：先搜 validateToken，确认它是否存在；如果存在，再看签名；如果不存在，就不要硬写一个“项目里应该有”的名字。
这里也有一个小坑：搜索只能证明字符串出现过，不能证明它真的可用。注释、TODO、旧代码、测试 fixture 都可能被搜出来。TypeScript 项目里，最好再配合 tsc 或 LSP；Python 项目里，最好配合 pyright、ruff 或项目自己的测试命令。
换句话说，搜索是证据的一种，但不是全部证据。
第三层：用 hooks 让假代码立刻暴露
前两层还是偏“提醒”。第三层开始进入真正的工程约束：Claude Code 写完文件后，自动跑检查。
Claude Code 支持 hooks。你可以在设置里配置 PostToolUse，让它在 Write 或 Edit 之后执行命令。官方文档里的示例也是这个思路：匹配写入/编辑工具，然后运行项目脚本。
一个简化版可以长这样：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "npm run typecheck 2>&1 | head -80"
}
]
}
]
}
}
实际项目里不要机械复制这条命令。你应该换成自己项目里最快、最能暴露问题的检查。
| 项目类型 | 可以先跑什么 |
|---|---|
| TypeScript | npm run typecheck、npx tsc --noEmit |
| 前端项目 | npm run lint、关键页面测试 |
| Python | ruff check、pyright、核心单测 |
| Rust | cargo check |
| Go | go test ./... 或目标包测试 |
hooks 的关键不是“跑得越多越好”，而是让错误回到 Claude Code 的上下文里。
如果检查静默写日志，Claude Code 看不到，它还是会继续自信。如果命令输出能直接返回到当前会话，它就能看到自己刚刚写了一个不存在的 import，或者调用了一个签名不对的函数。
这里有个工程取舍：大项目里不要每次写文件都跑完整测试。那样太慢，也容易被一堆无关错误淹没。更合理的做法是，把轻检查放在 PostToolUse，比如类型检查、lint、局部测试；把重检查放在任务结束前，或者在真正提交前再跑。
这一步的本质，是把“模型自称没问题”改成“工具链说没问题”。
第四层：加一个只查事实的 fact-checker
最后一层，是给 Claude Code 配一个专门查事实的 subagent。
这个 subagent 不负责写代码，也不负责解释得更漂亮。它只做一件事：检查刚才那些结论有没有证据。
可以在 .claude/agents/fact-checker.md 里放一个类似这样的角色定义。
---
name: fact-checker
description: Verify claims about code, tests, dependencies, and docs.
tools: Read, Grep, Glob, Bash
---
You verify claims. You do not write code.
For each factual claim, verify independently:
- Code claims: read the file and cite file path or line.
- Test claims: run the command or mark it unverified.
- Dependency claims: check package.json or equivalent manifest.
- API claims: check local docs, package docs, or source.
Report each claim as VERIFIED, WRONG, or UNVERIFIABLE.
Do not accept prior assistant claims as evidence.
它最适合在几个节点使用：提交前、给团队发总结前、引入新依赖后、修完复杂 bug 后。
比如 Claude Code 最后总结说：
“我已经修复登录校验问题，validateToken 现在会处理过期 token，相关测试也通过了。”
fact-checker 就应该拆开检查：
| 结论 | 怎么查 |
|---|---|
| 修复登录校验问题 | 读对应文件，看实际逻辑 |
validateToken 处理过期 token | 找函数定义和测试用例 |
| 测试通过 | 运行测试命令，而不是相信总结 |
这个角色看起来有点麻烦，但它会逼 Claude Code 留下“收据”：改了哪个文件，跑了什么命令，看到什么输出，哪些地方没验证。
很多团队用 AI 编程助手时，最缺的不是更多回答，而是证据链。fact-checker 的价值就在这里：它不负责让答案更顺耳，只负责让结论更可查。
真正要追求的不是聪明，而是可验证
如果把这 4 层放在一起看，它们其实是在做同一件事：把 Claude Code 从“生成文本的工具”，推向“受工程流程约束的协作者”。
第一层让它知道不能乱说。第二层让它在行动前先找证据。第三层让工具链及时暴露错误。第四层让另一个独立角色复核结论。
这不是 Claude Code 独有的问题，而是所有 Agent 系统都会遇到的问题。模型可以生成一个看起来合理的步骤，但这个步骤到底有没有被验证、有没有执行记录、有没有证据支撑，才是真正决定它能不能进生产的地方。
这个方向在 Code w/ Claude 2026 里也被专门讲过。Elicit 的工程负责人 James Brady 有一场分享，叫 Making agentic workflows trustworthy and verifiable with a custom DSL。里面讲的不是简单“怎么写 prompt”，而是他们如何把研究型 Agent 的工作流变成一种更可解释、可执行、可验证的程序。
视频地址在这里：YouTube 视频。
Elicit 后来在产品里也继续沿着这个方向做 Research Agents：不是让模型随手搜索和总结，而是把研究任务拆成步骤，再执行，并尽量让结论有来源和证据支撑。
所以回到 Claude Code，这 4 个配置的意义不只是“防止它胡说”。更准确地说，是让它每次下结论前，都必须经过一点现实世界的摩擦。
文件是否存在，函数是否存在，测试有没有跑，依赖有没有装，命令有没有输出。这些东西不性感，但很管用。
五分钟能做的版本
如果你不想一次性折腾完整流程，可以先做一个最小版本。
第一分钟，把诚实规则放到项目根目录的 CLAUDE.md。
第二分钟，加上验证协议，要求它写代码前先读文件、搜符号、查依赖。
第三到第四分钟，在 .claude/settings.json 里配置一个轻量 hook，让写文件后自动跑最快的检查命令。
第五分钟，创建一个 fact-checker subagent，至少在提交前让它查一次：代码结论、测试结论、依赖结论有没有证据。
做完这几步，你不一定会得到一个永远正确的 Claude Code。但你会得到一个更愿意停下来检查、更容易暴露错误、更不敢随口说“已完成”的 Claude Code。
这就够重要了。
在生产环境里，AI 编程助手的可靠性不是靠“相信它会变乖”，而是靠让它的每一步都能被工具、文件和命令验证。所谓少胡说，本质上不是道德问题，是工程问题。
信息来源
- Claude Code 官方文档：How Claude remembers your project
- Claude Code 官方文档：Hooks reference
- Claude Code 官方文档：Create custom subagents
- Code w/ Claude session：Making agentic workflows trustworthy and verifiable with a custom DSL
- YouTube 视频：Making agentic workflows trustworthy and verifiable with a custom DSL
- Elicit 官方博客：New in Elicit: Research Agents