1. 项目概述：Bonsai，一个为 Cursor 注入“极简主义”灵魂的规则集

如果你和我一样，日常重度依赖 Cursor 这类 AI 编程助手，那你肯定也经历过这样的时刻：你只是问了一个简单的代码问题，比如“如何用 CSS 垂直居中一个元素？”，结果 AI 洋洋洒洒给你回了一大段。它先是礼貌地问候，然后列举了四五种方法，从 absolute 定位到 flexbox ，再到 grid ，每种方法都附上一段“值得注意的是...”或“请记住...”的说明，最后还不忘贴心地加上一句“如果您有任何问题，请随时告诉我”。你需要的核心代码，可能就藏在第三段的某个角落里。这种“过度礼貌”和“信息冗余”在需要快速迭代、聚焦问题的开发场景中，尤其让人分心。更关键的是，这些冗余的文本会消耗宝贵的上下文 Token，在长对话或多轮迭代中，可能让你更快地触及上下文窗口的上限，导致 AI“失忆”。

Bonsai 项目就是为了解决这个问题而生的。它不是一个插件，也不是一个需要复杂配置的工具，而是两个极其轻巧的 .mdc 规则文件。你可以把它理解为一套为 Cursor AI 助手定制的“沟通准则”或“写作风格指南”。这套准则的核心思想是： 只说必要的，去掉所有修饰和填充 。它的目标用户非常明确：任何希望从 Cursor 获得更直接、更精炼、更聚焦于代码本身回答的开发者。无论是前端新手想快速得到一个可用的代码片段，还是资深工程师在排查复杂 Bug 时希望 AI 的回复能直击要害，Bonsai 都能显著提升沟通效率。

2. 核心原理与设计哲学：为什么是规则文件，而非插件？

要理解 Bonsai 的巧妙之处，首先得了解 Cursor 编辑器的一个内置特性： 项目级规则（Project Rules） 。在 Cursor 项目中，如果存在一个 .cursor/rules/ 目录，并且其中存放着 .mdc （Markdown Cursor）格式的文件，那么 Cursor 的 AI 模型在生成针对该项目的回复时，会自动读取并尝试遵循这些文件中定义的指令。这本质上是将“系统提示词（System Prompt）”的能力下放给了每一个独立的项目。

Bonsai 正是利用了这一点。它提供的两个文件—— lean.mdc 和 no-filler.mdc ——就是精心编写的系统提示词。当它们被放置在项目的 .cursor/rules/ 目录下，并且设置了 alwaysApply: true 属性后，就相当于每次你与 Cursor 对话时，都无声地附加了一条最高优先级的指令：“请用最精炼的语言回答，保留所有代码和技术细节，但省略所有客套话、冗余解释和不确定性的表达。”

2.1 规则文件深度解析

让我们拆开这两个文件，看看它们具体做了什么。

lean.mdc ：构建极简回复的骨架 这个文件是核心，它定义了回复应该呈现的“结构”和“风格”。其规则通常包含以下几个层面：

1. 代码至上原则 ：首要规则是绝对保留并优先展示所有代码块。任何解释性文字都不能以牺牲代码的完整性和可读性为代价。
2. 碎片化与列表优化 ：鼓励使用片段式回答和紧凑列表。例如，将“首先，你需要做 A。然后，第二步是 B。最后，别忘了 C。” 优化为 “- A - B - C”。这并非简单地删除连接词，而是在保证逻辑连贯的前提下，追求信息密度的最大化。
3. 消除不确定性词汇 ：避免使用“可能（might）”、“也许（could）”、“通常（usually）”等显得犹豫或不够肯定的词汇，除非在描述客观概率时。这能让回答显得更权威、更确定。
4. 直接断言 ：用肯定的陈述句代替试探性的疑问句或条件句。例如，将“你是否考虑过使用 X 方法？” 改为 “使用 X 方法。”

** no-filler.mdc：精准剔除语言“脂肪”** 如果说 lean.mdc 定义了风格，那么 no-filler.mdc` 就是一把精准的手术刀，负责切除那些特定、无意义的填充短语。它通常包含一个“黑名单”，列出了 AI 回复中常见但无实际信息的开头、中间和结尾用语。

• 开头黑名单 ：例如 “Sure thing!”，“Absolutely!”，“I'd be happy to help.”，“Great question!”。
• 中间黑名单 ：例如 “It's worth noting that...”，“Keep in mind that...”，“Another thing to consider is...”，“As you may know...”。
• 结尾黑名单 ：例如 “Let me know if you have any questions.”，“I hope this helps!”，“Feel free to ask if you need more details.”。

注意 ：这种“黑名单”式过滤需要谨慎设计。Bonsai 的规则经过精心调校，旨在剔除的是纯粹的社交润滑剂，而非重要的转折或强调语句。一个设计拙劣的黑名单可能会误伤有实际语义的句子。

2.2 技术实现的无侵入性

Bonsai 最吸引人的特性之一就是其“无侵入性”。它不修改 Cursor 编辑器本身，不需要安装任何插件，不调用外部 API，也没有构建步骤。你只需要复制两个文件到你的项目里。这意味着：

• 零开销 ：不会引入任何运行时性能损耗。
• 完全本地 ：所有规则在本地生效，无需网络请求，无隐私顾虑。
• 即时生效 ：文件放入后，重启 Cursor 或手动触发规则重载，即刻生效。
• 项目隔离 ：你可以为不同的项目配置不同的规则集。例如，为一个快速原型项目启用 Bonsai 追求极致效率，而为一份需要详细注释的教学文档项目则使用默认或更详细的规则。

这种设计哲学体现了 Unix 工具集的“单一职责”和“组合使用”思想，Bonsai 只做好“让 AI 回复变简洁”这一件事，并且以最轻量、最标准化的方式（文件）来实现。

3. 实操指南：从安装到验证的全流程

理解了原理，接下来就是动手环节。将 Bonsai 集成到你的工作流中非常简单，以下是几种常见的安装方式及其适用场景。

3.1 安装方法选择与步骤详解

方法一：使用 curl 命令（推荐用于快速尝鲜或自动化脚本） 这是最直接、最快捷的方式，尤其适合你已经在终端前，并且想要立即为当前项目启用 Bonsai。

# 1. 确保当前目录是你的项目根目录
# 2. 创建必要的目录结构（如果不存在）
mkdir -p .cursor/rules

# 3. 下载 lean.mdc 规则文件
# 注意：将 <you> 替换为实际的项目所有者，例如 marcomondelli
curl -fsSL -o .cursor/rules/lean.mdc \
  https://raw.githubusercontent.com/marcomondelli/bonsai/main/.cursor/rules/lean.mdc

# 4. 下载 no-filler.mdc 规则文件
curl -fsSL -o .cursor/rules/no-filler.mdc \
  https://raw.githubusercontent.com/marcomondelli/bonsai/main/.cursor/rules/no-filler.mdc

执行完上述命令后，两个规则文件就已经安静地躺在你的项目里了。你需要 完全关闭 Cursor 编辑器再重新打开 ，或者在其设置中找到“重载规则”的选项，以使新规则生效。

方法二：使用 Git Clone（适合需要查看或修改源码） 如果你希望先浏览一下规则文件的内容，或者未来可能想基于 Bonsai 定制自己的规则，那么克隆整个仓库是更好的选择。

# 1. 克隆 Bonsai 仓库到本地临时位置
git clone https://github.com/marcomondelli/bonsai.git

# 2. 将克隆仓库中的 .cursor 文件夹复制到你的项目根目录
cp -R bonsai/.cursor /path/to/your/project/

# 3. （可选）删除克隆的仓库
rm -rf bonsai

这种方法让你能直接看到 benchmark 和 scripts 目录，方便你后续进行效果测试或使用附加工具。

方法三：手动创建（适用于网络受限或深度定制） 如果你无法访问 GitHub，或者你想从零开始完全理解并创建这两个文件，可以手动创建。

1. 在你的项目根目录创建 .cursor/rules/ 文件夹。
2. 在 rules 文件夹内创建 lean.mdc 文件，并填入类似以下内容（具体以官方最新版为准）：

   ---
   alwaysApply: true
   ---
   # Lean Responses
   - **Never truncate code blocks.** Preserve every line, indentation, and comment.
   - Answer in fragments, lists, or tight paragraphs. Omit conversational fluff.
   - Be direct. Avoid “might,” “could,” “usually” unless describing objective probability.
   - If the question is simple, answer is short. No preambles.
   

3. 创建 no-filler.mdc 文件，填入短语黑名单。

3.2 验证规则是否生效

安装完成后，如何确认 Bonsai 在起作用？最直观的方法就是进行对比测试。

1. 临时禁用/启用 ：最简单的方法是将 .cursor/rules/ 文件夹临时改名（如改为 .cursor/rules_backup/ ），重启 Cursor，问一个问题。然后再改回来，重启，问同一个问题。对比两次的回答风格和长度。
2. 使用项目内建脚本 ：如果你用 Git Clone 方式安装，可以尝试运行项目自带的基准测试脚本，这不仅能验证，还能量化效果。

   cd /path/to/bonsai-clone/benchmark
   npm install  # 首次运行需要安装依赖
   node measure.js
   

   这个脚本会使用 tiktoken （OpenAI 的 Token 计算库）在本地对比几组预设的“普通回答”和“精炼回答”，并输出 Token 节省的百分比。看到类似 Average reduction: 65% 的输出，就证明规则逻辑和测试环境都是正常的。

实操心得 ：我建议在安装后，先向 Cursor 提一个你经常问的、典型的技术问题（例如：“如何在 Python 中反转一个列表？”）。观察其回复。一个生效的 Bonsai 回复应该是：没有开头寒暄，直接给出方法（可能是 list.reverse() 、 reversed() 或切片 [::-1] ），并附上简短的代码示例。如果回复以“当然！”开头，那很可能规则没有正确加载，请检查文件路径和 Cursor 重启情况。

4. 效果评估与量化：65%的 Token 节省意味着什么？

项目宣称在样本测试中平均减少了 65% 的 Token 使用量。这个数字很吸引人，但我们需要理性看待它背后的含义和实际价值。

4.1 基准测试是如何进行的？

Bonsai 的基准测试方法值得借鉴，因为它透明、可复现、且无需 API 密钥。其核心步骤如下：

1. 构建样本对 ：作者精心准备了四组“问答对”。每组包含同一个问题的两种 AI 回答版本：一个是 Cursor 默认生成的“普通（Normal）”版本，另一个是人工优化或期望的“精炼（Lean）”版本。例如，“解释 React Hooks”和“修复未定义变量错误”就是两组样本。
2. 本地 Token 计数 ：使用 tiktoken 库的 cl100k_base 编码器（这是 GPT-3.5/4 等模型使用的编码方式）分别计算两个版本的 Token 数量。
3. 计算节省率 ：对每一组样本，计算 (Normal - Lean) / Normal ，得到单样本节省百分比，然后求平均值。

样本描述	普通版本 Token 数	精炼版本 Token 数	节省 Token 数	节省百分比
React Hooks 解释	123	59	64	52%
修复未定义变量（代码）	60	19	41	68%
Git merge vs rebase 解释	115	39	76	66%
CSS 居中（代码）	113	26	87	77%

平均节省率：65%

4.2 这个数字的实际影响

1. 上下文窗口（Context Window） ：这是最直接的收益。假设你的 Cursor 模型上下文窗口是 128K Tokens。在长对话中，节省 65% 的辅助消息（AI 回复）Token，意味着你可以进行更多轮对话，或者携带更长的代码文件和历史记录，而不会因为“失忆”被迫开启新会话。这直接提升了复杂、多轮调试或设计会话的可行性。
2. 响应速度 ：更少的 Token 通常意味着更快的生成速度。虽然对于单次简短问答感知不明显，但在需要连续、快速交互的场景下，累积的时效提升会很可观。
3. 阅读与认知效率 ：这是无法量化的巨大收益。剔除冗余信息后，答案的核心结构（代码、关键步骤、结论）一目了然。开发者不再需要从一段“小作文”中费力搜寻关键行，注意力得以更好地集中在解决问题本身。项目 README 中的 CSS 居中示例完美地展示了这一点：从一段包含多种方法、附带说明的段落，精简为一行标题加一个紧凑的代码块。
4. 成本考量（若涉及 API） ：虽然 Cursor 的商业模式可能不直接按 Token 向用户收费，但 Token 消耗是 AI 服务提供商的核心成本之一。更高效的交互从宏观上看，有利于服务的可持续性和稳定性。

4.3 理性看待“65%”

必须清醒认识到， 65% 是一个在特定、优化过的样本上取得的基准测试结果，而非使用保证 。实际节省率会根据你的使用场景大幅波动：

• 纯代码生成场景 ：节省率可能较低。如果 AI 的回答本身就是一大段代码，Bonsai 规则的首要原则是“不截断代码块”，因此可压缩的空间主要在于代码前后的解释文字。
• 概念解释、方案设计场景 ：节省率会非常高。这类回答中包含大量的叙述性、解释性、比较性文字，正是 Bonsai 规则重点优化的对象。
• 问题复杂度 ：对于极其复杂、需要多角度分析的问题，AI 可能仍然需要一定篇幅来确保回答的严谨性，规则的影响会相对减弱。

我的经验是 ：在日常前端开发中，询问具体 API 用法、错误解释、代码重构建议时，节省效果最为明显，回答变得非常“干练”。而在进行开放式架构讨论时，AI 的回答虽然去掉了废话，但必要的分析段落依然存在，整体阅读体验依然提升显著。

5. 高级应用与自定义：让 Bonsai 为你量身定制

Bonsai 开箱即用的规则已经非常有效，但真正的力量在于它的可定制性。你可以根据个人偏好或项目特定需求，调整这些规则。

5.1 自定义规则文件

.mdc 文件本质上是 Markdown 格式，顶部用 --- 分隔的 YAML 区域用于定义元数据（如 alwaysApply: true ），下面是具体的规则描述。你可以直接编辑 lean.mdc 或 no-filler.mdc 。

• 调整严格度 ：如果你觉得某些“填充词”在某些语境下是有用的，可以从 no-filler.mdc 的黑名单中移除它们。
• 添加项目特定规则 ：例如，如果你正在做一个 Rust 项目，可以在 lean.mdc 中追加：“- 当解释错误时，优先引用官方 Rust 文档中的章节。”或者“- 代码示例中必须包含 #[derive(Debug)] 如果结构体需要打印。”
• 创建新的规则文件 ：你可以在 .cursor/rules/ 下创建 my-style.mdc 。例如，一个专注于代码审查的规则：“- 在提供优化建议时，必须同时指出潜在的风险或副作用。” 只要设置 alwaysApply: true ，它就会和 Bonsai 规则一起生效。

5.2 利用辅助脚本进行深度分析

Bonsai 仓库附带的 scripts/ 目录提供了一些实用工具，帮助你更深入地了解效果。

• whispers-inspect.js ：这个脚本的名字可能来源于其“窃窃私语”般分析对话的理念。它有两个功能：
  • node whispers-inspect.js paste ：将剪贴板中的文本进行 Token 计数。你可以手动将一段 AI 回复粘贴过来，看看它“价值”多少 Token。
  • node whispers-inspect.js session ：这个功能更有趣。它尝试模拟或对比“有规则”和“无规则”下，AI 对同一组问题的回答差异。你需要按照脚本提示提供一些问题。
• cursor-inspect.js ：这是一个更具探索性的脚本。它会尝试读取 Cursor 编辑器本地存储的 SQLite 数据库（其中可能保存了历史对话），并估算应用 Bonsai 规则后可能节省的 Token 总量。 需要特别注意 ：该脚本的 README 明确指出了其“尽力而为（best-effort）”的性质，因为 Cursor 的本地数据库结构并非公开 API，可能随版本变更。运行此脚本前，请确保你理解其原理，并最好在备份后操作。

5.3 与其他工作流结合

Bonsai 的规则是静态文件，这使其能轻松融入各种自动化流程。

• 项目模板 ：将 .cursor/rules/ 文件夹加入你的项目脚手架或 dotfiles 仓库。这样，每次用模板创建新项目时，Bonsai 规则自动就位。
• 团队共享 ：在团队内部，可以将定制好的 Bonsai 规则文件提交到代码仓库的根目录。这样能确保所有团队成员在使用 Cursor 分析该项目代码时，都遵循同一套简洁沟通标准，提升协作效率。
• 条件性应用 ：虽然 Bonsai 默认规则是 alwaysApply ，但你可以创建更复杂的规则。例如，一个规则只在文件路径包含 /docs/ 时生效，用于生成更详细的文档；而 Bonsai 规则则在其他路径生效，用于代码生成。

6. 常见问题与排查技巧实录

即使按照步骤操作，你也可能会遇到一些问题。以下是我在实践过程中遇到的一些典型情况及解决方法。

6.1 规则未生效

症状 ：Cursor 的回复依然以“Hi!”，“Sure!”开头，冗长如旧。

• 检查文件路径和名称 ：确保规则文件位于 [项目根目录]/.cursor/rules/ 下，且文件名是 lean.mdc 和 no-filler.mdc 。注意 .cursor 是隐藏文件夹。
• 检查文件内容 ：用文本编辑器打开 .mdc 文件，确认其包含 --- 分隔的 YAML 前端元数据，并且有 alwaysApply: true 这一行。规则描述部分是否完整？
• 重启 Cursor ：这是最关键的一步。修改规则文件后，必须 完全退出 Cursor 编辑器（不仅仅是关闭窗口，可能需要从任务管理器或活动监视器中确认进程已结束），然后重新启动。
• 检查多项目工作区 ：如果你在 Cursor 中打开了多个项目（Workspace），请确认当前活跃的编辑器标签页对应的项目目录下存在规则文件。规则是按项目加载的。
• 查看 Cursor 规则状态 ：某些 Cursor 版本可能在设置界面有规则管理或状态显示，检查那里是否识别到了你的规则文件。

6.2 规则“过激”，导致回答不完整或难以理解

症状 ：AI 的回答过于简略，甚至省略了关键的前提条件或步骤，导致需要反复追问。

• 调整规则强度 ：编辑 no-filler.mdc ，将一些你认为有用的过渡句或强调句从黑名单中移除。例如，保留 “Note that...” 但删除 “It's worth noting that...”。
• 修改 lean.mdc 的优先级 ：在 lean.mdc 中，可以补充说明：“在追求简洁的同时，必须保证回答的完整性和准确性。对于复杂操作，列出关键步骤是必要的。”
• 使用多个规则文件 ：不要把所有规则都塞进一个 alwaysApply 的文件。可以为不同的任务创建不同的规则文件，通过 Cursor 的指令手动触发（例如，在提问前输入 @rule: detailed ）。

6.3 与其他扩展或设置冲突

症状 ：安装了其他 Cursor 插件或修改了全局 AI 设置，导致 Bonsai 效果不稳定。

• 排查插件 ：暂时禁用其他 Cursor 插件，观察 Bonsai 是否恢复正常。有些插件可能会修改 AI 的系统提示词，与项目级规则产生冲突。
• 检查全局设置 ：Cursor 的用户设置中可能有关于 AI 行为模式的选项。确保没有开启“详细模式”或“教学模式”等与 Bonsai 目标相悖的全局设置。
• 规则加载顺序 ：理论上，项目规则 ( alwaysApply: true ) 的优先级很高。但如果冲突依然存在，可能需要查阅 Cursor 的官方文档，了解其提示词组合的具体逻辑。

6.4 量化脚本运行报错

症状 ：运行 benchmark/measure.js 或 scripts/ 下的脚本时出现 Module not found 错误。

• 安装依赖 ：确保在运行脚本的目录下（如 benchmark/ ）已经执行了 npm install 。这些脚本依赖 tiktoken 等 Node.js 包。
• Node.js 版本 ：确保你的 Node.js 版本符合脚本要求（通常 LTS 版本即可）。
• 网络问题 ： npm install 可能因网络问题失败，尝试使用镜像源或检查网络连接。

6.5 对非英语内容的效果

Bonsai 的规则主要是针对英语语料设计和优化的。如果你主要用中文或其他语言与 Cursor 交流，其“填充词黑名单”可能无法完全生效。不过， lean.mdc 中关于“代码至上”、“直接断言”、“使用碎片化列表”等结构性规则，在一定程度上是跨语言通用的。你可以尝试根据中文 AI 常见的冗余表达（如“首先，很高兴为您解答...”，“总的来说，...”），创建自定义的 no-filler-zh.mdc 文件。

7. 总结与个人实践体会

经过一段时间的深度使用，Bonsai 已经成为了我每个技术项目的“标配”。它带来的改变是静默但深刻的。我不再需要在一大段 AI 生成的文字中“淘金”，回复变得像经过优秀工程师 review 过的代码注释一样直白有力。这种效率的提升，在日积月累中节省了大量的认知带宽和时间。

我个人最欣赏 Bonsai 的几点在于：

1. 极简的哲学 ：它用最小的代价（两个文件）解决了一个真实存在的痛点，完美诠释了“少即是多”。
2. 对开发者习惯的尊重 ：它不强迫你改变工作流，只是安静地优化了工作流中的一个环节。
3. 透明与可控 ：规则是纯文本，你可以完全看清、理解并修改它，没有黑盒魔法。

最后分享一个进阶技巧：我创建了一个 lean.mdc 的变体，我称之为 lean-with-why.mdc 。它在追求简洁的基础上，增加了一条规则：“ 在提供代码片段或解决方案后，用一行‘// 原因：’的注释解释最关键的设计决策或潜在陷阱。 ” 这样，我既能得到精炼的代码，又能快速理解其背后的逻辑，在学习和解决问题之间找到了更好的平衡。这或许就是 Bonsai 这类工具最大的魅力：它不是一个终点，而是一个让你可以在此基础上构建更高效、更个性化人机协作方式的起点。