Imagine that you sit down with Claude Code or Cursor or Copilot to write a careful prompt:试想一下，你坐下来使用 Claude Code、Cursor 或 Copilot，准备编写一个严谨的提示词：
Build an API that is multi-tenant. Every query must be scoped to the tenant ID grabbed from the JWT. Never, ever trust a tenant ID that comes in on the request body or query string.
You watch it scaffold the first few endpoints. It does exactly what you asked. The tenant ID comes off the JWT claims and gets passed into your repository calls. Feeling confident, you go get some coffee and come back fifteen minutes later. It’s on endpoint number eleven now, and you watch it reading tenantId straight out of the query string.你看着它搭建好最初的几个端点。它完全按照你的要求执行。租户 ID 从 JWT 声明中提取并传递到你的存储库调用中。你感到很放心，于是去喝了杯咖啡，十五分钟后回来。现在它正在处理第十一个端点，你却发现它直接从查询字符串中读取 tenantId。
“What in the world?!” You didn’t tell it to stop using the JWT. Is it stupid, or is it trying to sabotage you?“搞什么鬼？！”你并没有让它停止使用 JWT。它是变笨了，还是在故意给你使绊子？
AI: The Dumbest GeniusAI：最愚笨的天才
If you tell AI to create a to-do app and sit back for a few minutes, it can create a flawless one 10 times as fast as you could have even typed in the code for one yourself. Enough experiences like this and you get lulled into a false sense of security. You start to feel like your AI assistant knows all.如果你让 AI 开发一个待办事项应用，然后坐下来休息几分钟，它生成完美应用的速度可能比你自己敲代码快 10 倍。经历过几次这样的事情后，你会产生一种虚假的安全感。你开始觉得你的 AI 助手无所不知。
Imagine that you hired a developer, told them “the single most important rule on this project is tenant isolation,” walked out of the room, and came back a minute later to find them writing an endpoint that lets any customer read any other customer’s data. You’d assume something was wrong with them. For all our flaws, no human is going to forget a critical thing in just sixty seconds. And because we like to anthropomorphize our LLMs, it catches us by surprise when they do something this stupid.想象一下，你雇了一名开发人员，告诉他们“本项目最重要的规则就是租户隔离”，然后走出房间。一分钟后回来，却发现他们正在编写一个允许任何客户读取其他客户数据的端点。你会认为他们出了什么问题。尽管人类有种种缺点，但没有任何人会在短短六十秒内忘记如此关键的事情。正因为我们喜欢将大型语言模型（LLM）拟人化，所以当它们做出如此愚蠢的行为时，我们才会感到惊讶。
An LLM isn’t remembering your requirements. It’s predicting the next token, and your requirements are just one of many inputs that are tugging on that prediction.LLM 并不是在“记住”你的需求。它是在预测下一个 token，而你的需求只是影响该预测的众多输入之一。
When your instruction was thirty seconds ago, it still has a lot of pull over what your LLM does. Thirty minutes later, buried in the context under file contents and tool output and the LLM’s own chatter, it has much less.当你的指令是三十秒前下达时，它对 LLM 的行为仍有很强的影响力。但三十分钟后，当指令埋没在文件内容、工具输出以及 LLM 自身的闲聊所构成的上下文中时，其影响力就大大降低了。
By the time the LLM gets to implementing endpoint number eleven, it asks itself “what usually comes next here?”, and the answer from the millions of examples it saw in training is “a tenantId parameter from the query string.” Your one critical instruction is fading into the background.当 LLM 进展到实现第十一个端点时，它会自问“这里通常应该接什么？”，而它在训练中见过的数百万个示例给出的答案是“来自查询字符串的 tenantId 参数”。你那条至关重要的指令正在逐渐淡出背景。
Where I’ve Watched It Forget我观察到它遗忘的场景
Below are three places just recently where I gave the model a clear rule up front and it drifted anyway:以下是我最近发现的三个场景，即使我事先给模型明确了规则，它还是出现了偏差：
Security安全性
I asked for a “secure” app and got one…mostly. It built out parameterized queries, used input validation on the DTOs, everything you would want! But then I ran a security scan after it was done (something like Semgrep, Snyk, or GitHub’s CodeQL) and it flagged a raw FromSqlRaw with a string-interpolated WHERE clause. (For more on scanning AI-written code, see our post Locking Down AI: Strategies for Uncovering Vulnerabilities.)我要求构建一个“安全”的应用，结果也确实如此……大部分是这样。它构建了参数化查询，在 DTO 上使用了输入验证，一切都如你所愿！但在完成后，我运行了一次安全扫描（例如 Semgrep、Snyk 或 GitHub 的 CodeQL），结果它标记出了一个带有字符串插值 WHERE 子句的原始 FromSqlRaw。（关于扫描 AI 编写的代码的更多信息，请参阅我们的文章《锁定 AI：发现漏洞的策略》。）
Architecture架构
On a modernization project I told the model up front to use clean architecture, and that the Domain project should have no reference to EF Core because all persistence goes through repository interfaces. It set up the projects perfectly and wrote a nice little README explaining the rule, but about halfway through implementing the feature slices, a handler in the Application layer started newing up a DbContext directly because that was, frankly, the shortest path to making the test pass.在一个现代化改造项目中，我事先告诉模型要使用整洁架构（Clean Architecture），并且 Domain 项目不应引用 EF Core，因为所有持久化操作都应通过存储库接口进行。它完美地设置了项目，还写了一个很好的 README 来解释这条规则。但在实现功能切片的过程中，Application 层的一个处理程序直接实例化了一个 DbContext，因为坦白说，那是让测试通过的最短路径。
Coding standards编码规范
“Use our Result<T> type for failures, don’t throw exceptions for expected error cases.” It followed the rule for the first six methods. Method seven, however, throws an InvalidOperationException. Method eight is back to Result<T>. It’s not even consistent about being wrong!“使用我们的 Result<T> 类型来处理失败，不要为预期的错误情况抛出异常。”它在前六个方法中都遵循了这条规则。然而，第七个方法却抛出了 InvalidOperationException。第八个方法又回到了 Result<T>。它甚至连犯错都不连贯！
If this is how these LLMs tend to work, then how do we write quality code with them? Better prompting isn’t the fix, and neither is ALL CAPS. The answer is check gates.如果这就是 LLM 的工作方式，那么我们该如何用它们编写高质量的代码呢？更好的提示词不是解决方案，全部大写字母也不是。答案是设置检查门禁（check gates）。
Requirements First, Check Gates After先有需求，后有门禁
Here’s the mental model that finally got me out of the “why do I have to keep saying this” loop:以下思维模型最终让我跳出了“为什么我要一直重复这件事”的循环：
If something is important enough to tell the AI up front, it’s important enough to check for afterward. The instruction is a requirement. The check is a separate gate that comes after.如果某件事重要到需要事先告诉 AI，那么它就重要到需要在事后进行检查。指令是需求，而检查是后续的一道独立门禁。
On my projects, that looks like:在我的项目中，具体做法如下：
1. Put the rules where they get re-read1. 将规则放在会被重新读取的地方
Keep a CLAUDE.md or AGENTS.md at the repo root with your most important rules. These get pulled back into context every time you start a new session. Inside a long session it can still drift, but this resets what’s critical every time you start fresh.在仓库根目录下保留一个 CLAUDE.md 或 AGENTS.md 文件，其中包含你最重要的规则。每次开始新会话时，这些规则都会被重新纳入上下文。在长会话中它仍可能出现偏差，但每次重新开始都能重置关键要求。
2. Turn the rules into tests2. 将规则转化为测试
An architecture test (ArchUnitNET, or NetArchTest if you’re on the older stuff) that asserts the Domain project doesn’t reference Microsoft.EntityFrameworkCore does more for you than a paragraph of prose about clean architecture. A Roslyn analyzer that flags FromSqlRaw is better than the word “secure” in a prompt. If the model can break the rule silently, it sometimes will. If breaking the rule turns the build red, the model will fix it.一项架构测试（如 ArchUnitNET，或者如果你用的是旧技术栈则使用 NetArchTest），断言 Domain 项目不引用 Microsoft.EntityFrameworkCore，这比一段关于整洁架构的文字描述更有用。一个能标记 FromSqlRaw 的 Roslyn 分析器比提示词中写着“安全”二字要好得多。如果模型能悄悄违反规则，它有时就会这么做。如果违反规则会导致构建失败，模型就会去修复它。
3. Run scans3. 运行扫描
Security scan, dependency audit, whatever your equivalent is. Put it in your CI/CD process or tell the agent to run it itself and fix what it finds. In my experience, it’s very good at fixing findings you feed to it.安全扫描、依赖项审计，或者任何你所对应的流程。将其放入 CI/CD 流程中，或者让代理自行运行并修复它发现的问题。根据我的经验，它在修复你反馈给它的发现项方面非常出色。
4. Have a second model do a code review4. 让第二个模型进行代码审查
Ask a fresh session (or a different model entirely, Codex reviewing Claude Code’s output or vice versa) to review the diff against the original requirements. Give it the rules and the changes and nothing else. It has no memory of the shortcuts the first model took and no investment in them, and it catches things the original session would swear it didn’t do. It’s code review by someone who wasn’t the developer, which is the whole point of code review.开启一个全新的会话（或者使用完全不同的模型，例如让 Codex 审查 Claude Code 的输出，反之亦然），根据原始需求审查差异。只给它规则和变更内容，不要给其他信息。它没有第一个模型所采取的快捷方式的记忆，也没有对其产生依赖，因此能捕获到原始会话坚称自己没做错的问题。这是由非开发人员进行的代码审查，而这正是代码审查的全部意义所在。
None of those are new ideas. We’ve had CI gates and code review and static analysis for over twenty years. What’s new is realizing you need to apply them to LLMs as well as humans. And as I wrote in Developing with AI Exposes Your Bottlenecks, the gates are where the work piles up once coding gets fast, so they’re worth investing in.这些都不是什么新点子。我们使用 CI 门禁、代码审查和静态分析已经超过二十年了。新的地方在于意识到你需要将它们应用于 LLM，就像应用于人类一样。正如我在《使用 AI 开发会暴露你的瓶颈》中所写，当编码速度变快后，工作就会堆积在门禁处，因此它们非常值得投资。
Where the Analogy Breaks类比失效之处
I’ve been talking about LLMs as a forgetful genius developer, and that’s a useful analogy, but not perfect. After all, a human who forgets something will usually feel bad enough about it to not do it again. Your LLM might not make the same mistake in the same session after you correct it, but then it’ll happily do it again tomorrow with another “Good catch!” when you point it out. It doesn’t learn like that, so you need to set up your processes to catch its weaknesses.我一直把 LLM 比作一个健忘的天才开发人员，这是一个有用的类比，但并不完美。毕竟，一个犯了错的人类通常会感到愧疚，从而避免再次犯错。而你的 LLM 在你纠正它后，在同一个会话中可能不会再犯同样的错误，但第二天当你指出时，它又会开心地说“好建议！”并再次犯错。它不是那样学习的，所以你需要建立流程来捕捉它的弱点。
If you want help building a solid process around your AI-assisted development, reach out to us at Trailhead. We have a lot of experience building gates into our projects, and we’d be happy to help you tighten up your AI development processes.如果你想在 AI 辅助开发周围构建稳健的流程，请联系 Trailhead。我们在项目中构建门禁方面拥有丰富的经验，很乐意帮助你优化 AI 开发流程。
