章节 1：引言：上下文工程与“复利工程”理念

📝 本节摘要：

本节作为全篇的开场，Alex 提出了核心概念——上下文工程（Context Engineering）。他引用了 Anthropic 的官方指南和 GitHub 对 2500 多个仓库的分析，旨在解决 AI 辅助编程中“重复劳动”的问题。本节重点介绍了“复利工程”（Compounding Engineering）的定义：即通过每一次互动教会 AI 你的模式和偏好，使其随时间推移变得越来越聪明，从而从被动反应转变为主动出击。同时，他还梳理了不同工具（Claude.md, Agents.md, Cursor rules）中通用的“持久化上下文”机制。

[原文] [Alex]: in my top 10 video I said context is king and a lot of you asked for the deep dive how do you actually do context engineering what goes into these markdown files or rule files how do you structure them so that the AI stops making the same mistakes

[译文] [Alex]: 在我的“十大技巧”视频中，我说过上下文为王，你们很多人要求进行深入探讨：究竟如何进行上下文工程（context engineering）？这些 markdown 文件或规则文件中应该包含什么？如何构建它们以便 AI 不再犯同样的错误？

[原文] [Alex]: today I'm going all in on this this is the ultimate guide to rule files for your AI assisted coding let's go

[译文] [Alex]: 今天我将全力以赴探讨这个问题，这是针对你的 AI 辅助编程的规则文件的终极指南，我们要开始了。

[原文] [Alex]: hey Alex here from Grit AI Studio anthropic just published their official guide to Claude MD files and GitHub analyzed over 2,500 repositories to find what actually works and I'm going to break down exactly how to build these files step by step so you can stop repeating yourself and start getting consistent results

[译文] [Alex]: 嘿，我是来自 Grit AI Studio 的 Alex。Anthropic 刚刚发布了关于 Claude.md 文件的官方指南，GitHub 分析了超过 2,500 个仓库以找出真正有效的方法，我将逐步拆解如何构建这些文件，这样你就可以停止自我重复，开始获得一致的结果。

[原文] [Alex]: if you watch the 10 tips video you know I'm obsessed with compounding engineering the idea that every interaction should teach your AI tools your patterns your preferences your corrections over time they generate better code with less guidance eventually we move from reactive to proactive

[译文] [Alex]: 如果你看了那个“十大技巧”视频，你就知道我痴迷于“复利工程”（compounding engineering），即每一次互动都应该教给你的 AI 工具你的模式、你的偏好、你的纠正，随着时间的推移，它们能在更少的指导下生成更好的代码，最终我们从被动反应转变为主动出击。

[原文] [Alex]: these rule files play a big role in how you make that happen they're the foundation of compounding engineering set them up right and every future session starts smarter set them up wrong or not at all and you're back to explaining the same things over and over again ai slop waiting to happen

[译文] [Alex]: 这些规则文件在你如何实现这一目标中扮演着重要角色，它们是复利工程的基础。如果设置得当，每一个未来的会话开始时都会更聪明；如果设置错误或根本不设置，你就只能一次又一次地解释同样的事情，这简直就是等着产生 AI 垃圾（AI slop）。

[原文] [Alex]: claude MD is Antropics approach for Claude code it lives in your repository and Claude reads it at the start of every conversation it becomes part of the system prompt persistent context loaded automatically

[译文] [Alex]: Claude.md 是 Anthropic 针对 Claude Code 的解决方案，它存在于你的仓库中，Claude 会在每次对话开始时读取它，它变成了系统提示词的一部分，即自动加载的持久化上下文。

[原文] [Alex]: agents MD is equivalent for GitHub copilot or codeex just to name a few and cursor rules work similar in cursor same concept but different file name cursor also support claude MD files

[译文] [Alex]: Agents.md 是 GitHub Copilot 或 Codex 等工具的等效文件，仅举几例；Cursor 规则（Rules）在 Cursor 中的工作方式也类似，概念相同但文件名不同，Cursor 也支持 Claude.md 文件。

[原文] [Alex]: the underlying principle is identical across all of them give persistent context so you stop repeating yourself whatever tool you're using these principles apply

[译文] [Alex]: 它们的基本原理都是一样的：提供持久化上下文，这样你就不用重复自己了。无论你使用的是什么工具，这些原则都适用。

章节 2：核心痛点：消除重复劳动与 LLM 注意力预算

📝 本节摘要：

在本节中，Alex 直击痛点，描述了没有上下文文件时开发者的尴尬处境——每次对话都是“冷启动”，必须重复解释技术栈和代码规范。他引入了 LLM 的“注意力预算”（Attention Budget）概念：上下文太少会导致幻觉，太多则降低性能。精心编写的上下文文件能精准击中“甜蜜点”（Sweet Spot），让 AI 即使在项目初期就能遵循你的编码风格和测试命令。这种一致性在数百次交互中积累，才是真正的价值所在。

[原文] [Alex]: so here's the pain this removes and if you've been coding with AI for a while you've definitely felt this without these files every conversation starts cold you explain your text stack you explain your folder structure that you prefer type hints that your API routes all start with / API v1 then you do it again tomorrow and the next day

[译文] [Alex]: 这就是它所消除的痛苦，如果你用 AI 写代码有一段时间了，你肯定对此深有体会：没有这些文件，每一次对话都是“冷启动”（starts cold）。你解释你的技术栈，你解释你的文件夹结构，解释你偏好类型提示（type hints），解释你的 API 路由都以 /API v1 开头，然后明天你再做一遍，后天再做一遍。

[原文] [Alex]: remember what I said in the 10 tips video llms have a fundamental constraint their attention budget too much context performance degrades too little hallucinations the model fills in the blanks because it's trained to please you

[译文] [Alex]: 记得我在“十大技巧”视频里说过的吗，大语言模型（LLMs）有一个根本性的限制，即它们的注意力预算（attention budget）。上下文太多，性能会下降；上下文太少，则会产生幻觉（hallucinations），模型会自行填补空白，因为它是被训练来取悦你的。

[原文] [Alex]: a well-written context file hits that sweet spot the AI already knows your patterns it writes code that matches your style it runs your actual test commands it puts files in the right places

[译文] [Alex]: 一个写得好的上下文文件能击中那个“甜蜜点”（sweet spot）：AI 已经知道了你的模式，它写出的代码符合你的风格，它运行你实际的测试命令，它把文件放在正确的位置。

[原文] [Alex]: small improvements to consistency compounded hundreds of times across a project that's where the real value is

[译文] [Alex]: 这种对一致性的小改进在一个项目中复利叠加数百次，那才是真正的价值所在。

章节 3：架构解析：高效上下文文件的六大核心领域

📝 本节摘要：

依托 GitHub 对超过 2500 个代码仓库的分析数据，Alex 在本节详细拆解了构建高效上下文文件的“六大支柱”。从最基础的常用命令和项目结构地图，到具体的技术栈版本（精确到版本号以避免 API 混淆），再到代码风格示例（Show, don't tell）。此外，他还强调了Git 工作流规范以及最重要的边界（Boundaries）设定——明确告诉 AI “绝不能做什么”，例如绝不提交密钥或删除失败的测试。

[原文] [Alex]: github's analysis of more than 2500 repositories found a clear pattern the best context files cover six areas let me walk you through each one

[译文] [Alex]: GitHub 对超过 2500 个仓库的分析发现了一个清晰的模式，最好的上下文文件涵盖了六个领域，让我带你一一了解。

[原文] [Alex]: number one commands put your actual executable commands early in the file not just npm but npm test npm run build include the flags that you actually use the AI will reference these constantly

[译文] [Alex]: 第一，命令（Commands）。把你实际的可执行命令放在文件的前面，不仅仅是 npm，而是 npm test、npm run build，包括你实际使用的标志（flags）。AI 会不断地参考这些内容。

[原文] [Alex]: number two project structure give the AI a map of your project what's in the source folder what's in the test folder where do config files live simple directory tree does wonders if you're using domain driven design or a specific architectural pattern say so

[译文] [Alex]: 第二，项目结构（Project Structure）。给 AI 一张你项目的地图：源文件夹里有什么，测试文件夹里有什么，配置文件放在哪里。一个简单的目录树就能创造奇迹。如果你使用的是领域驱动设计（DDD）或特定的架构模式，请明确说出来。

[原文] [Alex]: number three text stack with versions don't say React project say React 18 with TypeScript 5.3 Vite for bundling Tailwind CSS for styling and so on specifics matter because different versions have different APIs you don't want the AI guessing which syntax to use

[译文] [Alex]: 第三，带版本的技术栈（Tech Stack with versions）。不要只说“React 项目”，要说“React 18 搭配 TypeScript 5.3，使用 Vite 打包，Tailwind CSS 进行样式设计”等等。细节很重要，因为不同版本有不同的 API，你不想让 AI 猜测该用哪种语法。

[原文] [Alex]: number four code style one real code example beats three paragraphs of explanations show what good looks like in your codebase naming conventions error handling patterns how you structure functions show it don't tell according to GitHub

[译文] [Alex]: 第四，代码风格（Code Style）。根据 GitHub 的说法，一个真实的代码示例胜过三段文字解释。展示在你的代码库中什么样的代码是好的：命名约定、错误处理模式、你如何构建函数。展示它，不要只是描述它（Show, don't tell）。

[原文] [Alex]: number five Git workflows branch naming conventions commit message format PR requirements this is especially important if you're using agents to create branches and pull requests

[译文] [Alex]: 第五，Git 工作流（Git Workflows）。分支命名约定、提交信息格式、Pull Request（PR）要求。如果你正在使用 Agents 来创建分支和提交 PR，这一点尤为重要。

[原文] [Alex]: number six boundaries this is critical tell the AI what it should never do never commit secrets never modify the vendor directory never delete failing tests the most common helpful constraint in GitHub's analysis never commit secrets

[译文] [Alex]: 第六，边界（Boundaries）。这很关键，告诉 AI 它绝不应该做什么：绝不提交机密信息（secrets），绝不修改 vendor 目录，绝不删除失败的测试。在 GitHub 的分析中，最常见且有用的约束是：绝不提交机密信息。

章节 4：实战构建：从初始化到捕捉“血泪经验”

📝 本节摘要：

这一章节进入实操阶段。Alex 演示了如何利用 Claude Code 的 `/init` 命令快速生成上下文文件的雏形，但他强调这只是起点。真正的核心在于根据团队习惯进行定制（如 TDD 流程、边界条件）。最精彩的部分在于他提出的“痛苦转化机制”：每当经历一次艰难的 Debug 过程，不要直接翻篇，而应立刻让 AI 总结这次掉进的“兔子洞”（rabbit holes）并将其转化为规则。这种“在摩擦中成长”（grow through friction）的方法，能将一次性的教训转化为永久的机构知识（Institutional Knowledge）。

[原文] [Alex]: let me show you how I build one of these from scratch in Cloud Code you can use the /init command it explores your entire repository and writes a summary in your Claude MD file

[译文] [Alex]: 让我展示一下我在 Claude Code 中是如何从零开始构建这些文件的。你可以使用 /init 命令，它会探索你的整个仓库，并在你的 Claude.md 文件中写入摘要。

[原文] [Alex]: you can use that even if you're not normally using Claude code just copy it into your favorite coding assistant claude scans your package files existing docs config files code structure and then it generates a starter file

[译文] [Alex]: 即使你通常不使用 Claude Code，你也可以使用它，只需将其复制到你喜欢的编码助手中即可。Claude 会扫描你的包文件、现有文档、配置文件、代码结构，然后生成一个启动文件。

[原文] [Alex]: now here's the important part this is a starting point not a finished product the generated file catches obvious patterns but misses the nuances of how your team actually works

[译文] [Alex]: 现在最重要的是：这只是一个起点，而不是成品。生成的文件能捕捉到明显的模式，但会漏掉你团队实际工作方式中的细微差别。

[原文] [Alex]: let me show you some examples of what I normally add first I'm making the commands more specific the actual commands that I would typically run

[译文] [Alex]: 让我给你展示一些我通常会添加的例子。首先，我会让命令更具体，即我通常会运行的实际命令。

[原文] [Alex]: second I try to provide workflow instructions for this project we write tests first so I add when implementing new features write failing test first then implement then verify test pass

[译文] [Alex]: 第二，我尝试提供工作流说明。对于这个项目，我们要先写测试，所以我添加了：“当实现新功能时，先写失败的测试，然后实现功能，再验证测试通过。”

[原文] [Alex]: third adding boundaries never modify these files in migrations without explicit approval or never remove existing test cases always preserve backward compatibility in public APIs

[译文] [Alex]: 第三，添加边界。比如“在迁移中未经明确批准绝不修改这些文件”，或者“绝不删除现有的测试用例”，“在公共 API 中始终保留向后兼容性”。

[原文] [Alex]: fourth and this is where compounding engineering really kicks in I add common gotchas things that have bitten us before the database connection pool exhausts if you don't close connections in test always use the test DB fixture so on

[译文] [Alex]: 第四，这也是复利工程真正发挥作用的地方，我添加了常见的陷阱（gotchas），即那些曾经困扰过我们的事情。比如“如果你不在测试中关闭连接，数据库连接池会耗尽，请始终使用测试数据库夹具（fixture）”等等。

[原文] [Alex]: every time you fix a painful bug add a line here teach your AI coding assistant to learn from its mistakes this is how you build institutional knowledge

[译文] [Alex]: 每当你修复一个痛苦的 bug 时，就在这里加一行，教你的 AI 编码助手从错误中吸取教训。这就是你构建机构知识（institutional knowledge）的方式。

[原文] [Alex]: oh and I said add a line here but I of course meant ask your AI to add a line here in Claude code use the hash key to add the things you want Claude to remember

[译文] [Alex]: 哦，我说“在这里加一行”，但我当然是指让你的 AI 在这里加一行。在 Claude Code 中，使用井号键（#）来添加你希望 Claude 记住的事情。

[原文] [Alex]: when you've gone through painful debugging and finally solved something don't just move on say "Summarize all the rabbit holes we went through so that we avoid these mistakes in the future." Then hit hash and add it to your claw MD

[译文] [Alex]: 当你经历了痛苦的调试并最终解决了问题时，不要就这样翻篇了，要说：“总结我们经历的所有兔子洞，以便我们在未来避免这些错误。”然后点击井号键（hash）并将其添加到你的 Claude.md（原文口误为 claw MD）中。

[原文] [Alex]: build the file through actual use the best context files grow through friction not upfront planning

[译文] [Alex]: 通过实际使用来构建文件，最好的上下文文件是在摩擦中成长的，而不是通过预先规划。

章节 5：专家模式：利用专业分工与子代理架构

📝 本节摘要：

随着项目复杂度增加，Alex 提出了一种进阶策略：专家代理（Specialist Agents）。与其依赖一个全能的通用助手，不如组建一支“团队”。他展示了两个具体案例：文档代理（Docs Agent）（仅负责文档，拥有绝不修改源码的硬性边界）和测试代理（Test Agent）（QA 工程师人格，专注于测试结果分析，绝不掩盖失败的测试）。这种分工不仅让每个代理保持“激光般的专注（laser focused）”，还巧妙利用了 Claude Code 中子代理（Sub-agents）拥有独立上下文窗口的特性，防止了任务间的干扰。

[原文] [Alex]: now let me show you something powerful that you can do in both Clo and in GitHub Copilot specialist agents instead of one general assistant you create a team each agent has a specific role specific knowledge and specific boundaries

[译文] [Alex]: 现在让我展示一些强大的功能，你在 Claude（原文口误为 Clo）和 GitHub Copilot 中都可以做到：专家代理（specialist agents）。与其使用一个通用助手，不如创建一个团队，每个代理都有特定的角色、特定的知识和特定的边界。

[原文] [Alex]: here's a docs agent it's an expert technical writer it reads code from source and writes documentation to /docs it knows to run npm run docs build to check for broken links and critically it never modifies source code that's a hard boundary

[译文] [Alex]: 这是一个文档代理，它是一位专家级的技术作家，它从源文件中读取代码并将文档写入 `/docs` 目录。它知道运行 `npm run docs build` 来检查断开的链接，而且关键是，它绝不修改源代码，这是一条硬性边界。

[原文] [Alex]: here's the test agent qa engineer persona writes tests runs them analyzes results writes to the test folder and only that folder key boundary it never removes a failing test if a test fails it investigates why it doesn't delete the evidence

[译文] [Alex]: 这是一个测试代理，拥有 QA 工程师的人格。它编写测试、运行测试、分析结果，并写入测试文件夹——且仅写入该文件夹。关键边界是：它绝不删除失败的测试。如果测试失败，它会调查原因，而不是删除证据。

[原文] [Alex]: this separation is powerful because each agent can be laser focused the docs agent doesn't get confused by testing requirements and the test agent doesn't accidentally modify production code

[译文] [Alex]: 这种分离非常强大，因为每个代理都可以高度专注（laser focused）。文档代理不会被测试需求搞混，测试代理也不会意外修改生产环境的代码。

[原文] [Alex]: and if you're using cloud code remember that sub aents have their own context window same principle applies define specialized sub aents for different type of work

[译文] [Alex]: 另外，如果你使用的是 Claude Code，请记住子代理（sub-agents）有它们自己的上下文窗口。同样的原则也适用：为不同类型的工作定义专门的子代理。

章节 6：避坑指南：五大成功技巧与常见误区

📝 本节摘要：

在这一章节，Alex 总结了构建高效上下文文件的五大黄金法则（Tips）。他主张“从简单开始”，不要一开始就追求大而全，让文件在解决实际问题中自然生长（Tip #1）。他再次强调了“简洁至上”（Tip #2）和“示例优先”（Tip #3），因为上下文窗口寸土寸金。此外，他还提出了“分层管理”（Tip #4），即在根目录、项目目录和子目录分别放置不同层级的规则文件，以及像对待代码一样对待这些规则文件的版本控制（Tip #5）。最后，Alex 列举了必须避免的反模式：模糊的指令（如“你是一个有用的助手”）、过时的信息以及最危险的行为——在文件中泄露密钥。

[原文] [Alex]: let me give you the tips that have made the biggest difference for me tip number one start simple and then expand through friction don't try to write a comprehensive file up front start with the basics command structure and the stack then every time the AI does something wrong add a line to prevent it next time your cloud MD should evolve from real problems not just theoretical concerns

[译文] [Alex]: 让我给你分享一些对我影响最大的技巧。技巧一：从简单开始，然后在摩擦中扩展。不要试图一开始就写一个包罗万象的文件。从基础开始：命令、结构和技术栈。然后每次 AI 做错事时，加一行来防止下次再犯。你的 Claude.md 应该从实际问题中演变而来，而不是仅仅基于理论上的担忧。

[原文] [Alex]: tip number two keep it concise the file loads into the context window every single time remember context is precious a 2,000line CL code MD eats into space for actual work every line should earn its place

[译文] [Alex]: 技巧二：保持简洁。这个文件每次都会加载到上下文窗口中。记住，上下文是宝贵的。一个 2000 行的 Claude.md 文件会侵占实际工作的空间。每一行都必须证明它存在的价值。

[原文] [Alex]: tip number three code examples over explanations show don't tell a single example of your error handling pattern communicates more than a paragraph describing it

[译文] [Alex]: 技巧三：代码示例胜过解释。展示它，不要只是描述它。一个关于你错误处理模式的单一示例，比一整段描述它的文字能传达更多信息。

[原文] [Alex]: tip number four layer your files you can have a cloud MD in your home directory for universal instructions one in your repo route for projectwide context and one in subdirectories for module specific guidance they stack use this for monor repos or when different parts of your codebase have different conventions

[译文] [Alex]: 技巧四：分层管理你的文件。你可以在你的主目录（home directory）中放一个 Claude.md 用于通用指令，在你的仓库根目录放一个用于全项目上下文，在子目录中放一个用于特定模块的指导。它们会叠加生效。在单一代码库（monorepos）或代码库的不同部分有不同约定时使用此技巧。

[原文] [Alex]: tip number five version control this is documentation review it in pull requests when conventions change update the file when someone joins the team they get that AI context for free

[译文] [Alex]: 技巧五：版本控制。这就是文档，在 Pull Request 中审查它。当约定发生变化时，更新该文件。当有人加入团队时，他们可以免费获得这些 AI 上下文。

[原文] [Alex]: let me also tell you what doesn't work you're a helpful coding assistant that's way too vague this tells the AI nothing useful you might as well not have a file at all

[译文] [Alex]: 让我再告诉你什么是不起作用的。“你是一个有用的编码助手”，这也太模糊了，这没告诉 AI 任何有用的信息，你还不如根本没有这个文件。

[原文] [Alex]: i would also avoid putting commands at the bottom the AI references commands constantly put them near the top where they're easy to find and less likely to get pushed out of attention

[译文] [Alex]: 我也会避免把命令放在底部。AI 会不断引用命令，把它们放在靠近顶部的地方，这样容易找到，也不容易被挤出注意力范围。

[原文] [Alex]: not defining boundaries if you don't tell the AI what not to do it will eventually do something destructive be explicit about protected files directories and actions

[译文] [Alex]: 不定义边界。如果你不告诉 AI 什么不能做，它最终会做一些破坏性的事情。对受保护的文件、目录和操作要明确说明。

[原文] [Alex]: and you should definitely avoid stale information a clude MD file that references an old text stack or deprecated patterns is worse than no file it actively misleads keep it current

[译文] [Alex]: 你绝对应该避免过时的信息。一个引用旧技术栈或已弃用模式的 Claude.md 文件比没有文件更糟糕，它会主动误导 AI。保持它的时效性。

[原文] [Alex]: and of course don't put any secrets in the file this file often gets committed to version control never put API keys credentials or sensitive URLs in the file

[译文] [Alex]: 当然，不要在文件中放入任何机密信息。这个文件通常会被提交到版本控制中，绝不要在文件中放入 API 密钥、凭据或敏感的 URL。

章节 7：高阶技巧：上下文动态管理与总结

📝 本节摘要：

作为全篇的总结，Alex 分享了一个高阶技巧：利用子代理（Sub-agents）独立的上下文窗口来进行“无污染”的安全审查，避免之前的调试思路干扰分析。他还重申了上下文清理（Context Clearing）的重要性，建议在任务切换时使用 `/clear` 命令去除累积的噪音，仅保留核心的 `Claude.md` 规则。最后，他再次回顾了“复利工程”的愿景——将每一次“痛苦的调试”和“兔子洞”经历转化为机构知识（Institutional Knowledge），让 AI 随着项目的发展变得越来越聪明。

[原文] [Alex]: one more advanced technique that ties back to the top 10 tips video remember I said each sub agent has its own context window use that strategically

[译文] [Alex]: 还有一个高阶技巧，它和那个“十大技巧”视频有关。记得我说的吗，每个子代理都有它自己的上下文窗口，要策略性地利用这一点。

[原文] [Alex]: here's the scenario you've spent an hour debugging authentication now you want a security view of that code problem all that debugging context colors the security analysis

[译文] [Alex]: 场景是这样的：你花了一个小时调试身份验证问题，现在你想从安全角度审查那段代码。所有那些调试的上下文都会干扰（colors）安全分析。

[原文] [Alex]: claude might overlook issues because it's still thinking about the fixes the solution here is to tell CLA to use a sub agent for the security review that gives a fresh context and it focuses solely on vulnerabilities

[译文] [Alex]: Claude 可能会忽略一些问题，因为它还在思考修复方案。这里的解决方案是告诉 Claude 使用一个子代理来进行安全审查，这会提供一个新鲜的上下文，并且只专注于漏洞。

[原文] [Alex]: same goes for/clare when you finish one piece of work and move on to something unrelated clear the context your claude MD stays loaded the accumulated noise goes away

[译文] [Alex]: 同样的道理也适用于 /clear（原文字幕误为 /clare）。当你完成了一部分工作并转向不相关的事情时，清除上下文。你的 Claude.md 仍然保持加载状态，但累积的噪音消失了。

[原文] [Alex]: think of it like the markdown trick that I mentioned in the 10 tips video summarize where we are create next steps put it in a markdown file clear and then new conversation and then you can attach that file and you're in control of how you compact

[译文] [Alex]: 把它想成我在“十大技巧”视频中提到的 Markdown 技巧：总结我们在哪，制定下一步骤，把它放入 Markdown 文件，清除上下文，然后开始新对话，接着你可以附上那个文件，这样你就可以控制如何压缩信息。

[原文] [Alex]: okay I'll include a template in the description below so you can get started today start with the /init command to generate the file from Claude describe your project text stack and give a map of your project with key directories

[译文] [Alex]: 好的，我会在下面的描述中包含一个模板，这样你今天就可以开始了。用 /init 命令从 Claude 生成文件开始，描述你的项目技术栈，并提供一个带有关键目录的项目地图。

[原文] [Alex]: oh and remember to provide boundaries and keep adding your painful lessons learned compound when you end up repeating yourself turn that into a slash command in Claude Code

[译文] [Alex]: 哦，记得提供边界，并不断添加你学到的痛苦教训。当你发现自己在重复时，把它变成 Claude Code 中的斜杠命令（slash command）。

[原文] [Alex]: and there you have it that's the deep dive on better rule files and context engineering for AI assisted coding start simple add instructions when you hit friction keep it concise and version control it

[译文] [Alex]: 就是这样，这就是关于 AI 辅助编程的更好的规则文件和上下文工程的深度探讨。从简单开始，当遇到摩擦时添加指令，保持简洁，并进行版本控制。

[原文] [Alex]: and remember this is how compounding engineering actually works every painful debugging session every rabbit hole every oh that's why it broke capture it teach your AI to learn from its mistakes over time your context file becomes institutional knowledge that makes every future session better

[译文] [Alex]: 记住，这就是复利工程的实际运作方式。每一次痛苦的调试会话，每一个“兔子洞”，每一个“哦，原来是因为这个才坏的”，捕捉它，教你的 AI 从错误中学习。随着时间的推移，你的上下文文件变成了机构知识（institutional knowledge），让未来的每一次会话都变得更好。

[原文] [Alex]: thanks a lot for watching and I'll see you in the next

[译文] [Alex]: 非常感谢观看，我们下期见。