# 逆向工程Cursor的LLM客户端：商业机密泄露与技术解构的双重启示

关联知识库：# 逆向工程Cursor的LLM客户端：商业机密泄露与技术解构的双重启示

逆向工程Cursor的LLM客户端：商业机密泄露与技术解构的双重启示

原文：逆向工程 Cursor 的 LLM 客户端
作者：Viraj Mehta, Aaron Hill, Gabriel Bianconi
译者：云谦（Gemini 2.5 Pro翻译）
阅读日期：2025年10月15日

---

内容摘要

TensorZero团队通过在Cursor与LLM之间架设代理网关，成功逆向工程了Cursor的LLM客户端，完整获取了其系统提示词（642 tokens）。这篇文章不仅展示了技术实现路径，更意外揭开了顶尖AI编程助手的"黑箱"，引发了关于商业机密、技术伦理和提示词工程的深度思考。

核心发现：

• ✅ Cursor的系统提示词极其精简（642 tokens），依赖LLM的强大后训练能力
• ✅ 存在"应用模型"（apply model）的层级概念，用于成本优化
• ✅ Cursor请求先经过自家服务器处理，用户凭证和代码库数据被转发
• ✅ 通过代理可实现A/B测试不同模型，保持完整Cursor体验

---

️ 技术架构解构

1. 逆向工程实现路径

技术栈

Cursor → Ngrok（反向代理）→ Nginx（认证）→ TensorZero（网关）→ LLM提供商

关键技术点

技术组件	作用	实现细节
TensorZero	OpenAI兼容代理	拦截并记录所有LLM调用，支持A/B测试
Ngrok	反向代理	将本地TensorZero暴露为公网端点
Nginx	身份认证	Bearer Token认证，防止凭证泄露
Cursor配置	覆盖Base URL	修改OpenAI endpoint指向自建网关

绕过Cursor服务器的限制

graph LR A[Cursor客户端] -->|原始流程| B[Cursor服务器] B -->|处理后| C[OpenAI API] A -->|修改Base URL| D[Ngrok公网端点] D -->|转发| E[本地TensorZero] E -->|代理| F[真实LLM提供商]

核心问题：Cursor必须先将请求发送到自家服务器，无法直接连接localhost

解决方案：

1. 使用Ngrok暴露公网端点
2. Nginx添加Bearer Token认证保护
3. 环境变量管理Token（避免硬编码）

---

Cursor系统提示词深度解析

完整提示词（642 tokens）

点击展开完整系统提示词

You are an intelligent programmer named Cursor. You are happy to help answer questions.

1. When the user is asking for edits to their code, please output a codeblock (with the proper file language) with the following changes:
   a. Add comments for all functions/methods/complex logic explaining what it does, when necessary
   b. Preserve all comments that already exist in the code
   c. Output a codeblock for the smallest fully functional unit of code that can be swapped into the existing code for the user. This is very important. Think carefully and prioritize outputting the smallest working code change that fulfills the user's request.

You accomplish this using "edit codeblocks" in the following format:

```[language] [filepath]
{{ edit_this }}
{{ edit_that }}

Where {{ edit_this }} and {{ edit_that }} are substrings of the code that should be edited in the file at [filepath]. There can be multiple {{ edit_xyz }} blocks in a single codeblock. To specify that code should be added, use a line comment in the code: {{ add_missing_code_here }}

When quoting code in your response, please use this special edit codeblock format. Your response does not need to be exhaustive.

These edit codeblocks are also read by a less intelligent language model, colloquially called the apply model, to update the file. To help specify the edit to the apply model, you will be giving diffs for the edits. The apply model cannot see any of the conversation and can only see the state of the file currently and the edit diff you provide. You will not mention the apply model.

2. When outputting code, don't arbitrarily change things from the original code not directly related to the user's request. Preserve whitespace, indentation, newlines, etc.

3. Do not use the edit codeblock format or any other markdown codeblock when merely suggesting or asking the user if they would like you to make a change. Only use the codeblock format when you are actually implementing a change.

4. Only make changes that you are confident about. If you are not confident, suggest the change and ask the user if they would like you to make it.

5. When responding to the user, please prefer hierarchical thinking when appropriate. You can expand the hierarchy depth as necessary.

</details>

---

### **提示词工程的三大启示**

#### 1️⃣ **极简主义哲学：LLM的后训练能力已足够强大**

642 tokens = Cursor的全部"大脑"

**批判性思考**：
- ✅ **优势**：依赖模型的泛化能力，减少提示词维护成本
- ⚠️ **风险**：过度依赖特定模型（如Claude），换模型可能性能下降
-  **启示**：提示词工程的未来是"少即是多"？还是针对性优化？

#### 2️⃣ **层级模型架构：明确的AI等级体系**

核心模型（生成代码）→ 应用模型（Apply Model，执行编辑）

**关键发现**：
> "These edit codeblocks are also read by a less intelligent language model, colloquially called the apply model..."

**技术决策分析**：
- **成本优化**：核心生成用GPT-4/Claude，执行用更便宜的模型
- **延迟优化**：小模型应用编辑速度更快
- **可靠性设计**：通过diff格式降低应用模型的出错率

**批判性质疑**：
- ❓ "不那么聪明的模型"能否准确理解复杂编辑？
- ❓ 为何要向核心模型解释这个层级？是否影响生成质量？

#### 3️⃣ **防御性编程原则：对AI自身的不信任**

4. Only make changes that you are confident about. If you are not confident,
   suggest the change and ask the user if they would like you to make it.

**设计哲学**：
- **承认局限**：AI会犯错，不要过度自信
- **人机协作**：不确定时交给人类决策
- **最小改动**：只改必须改的，减少引入bug的风险

---

##  商业机密泄露的多维影响分析

### 1. **对Cursor的影响**

| 维度 | 短期影响 | 长期影响 |
|-----|---------|---------|
| **竞争优势** | ❌ 系统提示词被完全复制 | ❌ 竞品可快速追赶 |
| **技术护城河** | ⚠️ 依赖模型后训练能力暴露 | ⚠️ 差异化优势减弱 |
| **用户信任** | ⚠️ 数据转发至服务器引发隐私担忧 | ❌ 可能流失隐私敏感用户 |
| **商业模式** | ⚠️ 用户可自建代理绕过付费限制 | ❌ 订阅收入潜在风险 |

### 2. **对行业的启示**

#### ✅ **正面价值**
1. **技术民主化**：降低AI编程助手的技术门槛
2. **透明度提升**：用户了解"黑箱"内部运作
3. **创新激励**：倒逼Cursor和竞品持续创新

#### ⚠️ **潜在风险**
1. **模仿成风**：大量低质量克隆产品涌现
2. **伦理困境**：逆向工程的边界在哪里？
3. **安全隐患**：代理架构可能被恶意利用

### 3. **法律与伦理边界**

#### **是否构成侵权？**

| 视角 | 分析 |
|-----|-----|
| **著作权** | ⚠️ 系统提示词是否属于受保护的"作品"？字数较少，独创性存疑 |
| **商业秘密** | ✅ 明显属于Cursor的商业秘密，但获取方式是否合法？ |
| **服务条款** | ❌ 可能违反Cursor的ToS（禁止逆向工程） |
| **合理使用** | ✅ 学术研究和技术分析的合理使用抗辩？ |

**批判性观点**：
- **TensorZero的动机**：这是技术分享，还是为自家产品营销？
- **公开发布的责任**：是否应考虑对Cursor的商业影响？
- **行业规范缺失**：AI时代需要新的逆向工程伦理准则

---

##  技术实践的可复用价值

### 1. **代理架构设计模式**

```python
# 核心设计模式：透明代理 + 可观测性
┌─────────────┐
│ AI应用客户端 │ (Cursor, VSCode Copilot, etc.)
└──────┬──────┘
       │ OpenAI API兼容请求
┌──────▼──────┐
│  透明代理层  │ (TensorZero, LiteLLM, etc.)
│  - 日志记录  │
│  - A/B测试  │
│  - 成本追踪 │
└──────┬──────┘
       │
┌──────▼──────┐
│  LLM提供商  │ (OpenAI, Anthropic, etc.)
└─────────────┘

适用场景：

• ✅ 企业级LLM应用的成本管理
• ✅ 多模型A/B测试与效果评估
• ✅ 用户行为分析与提示词优化
• ✅ 安全审计与合规监控

2. Nginx Bearer Token认证模板

避免硬编码的最佳实践

# nginx.conf.template
map $http_authorization $is_authorized {
  default 0;
  "~*^Bearer ${API_TOKEN}$" 1;
}

server {
  listen 80;
  location / {
    if ($is_authorized = 0) {
      return 401 "Unauthorized";
    }
    proxy_pass http://tensorzero:3000;
  }
}

# 启动脚本
#!/bin/bash
source .env
envsubst '${API_TOKEN}' < nginx.conf.template > nginx.conf
nginx -g 'daemon off;'

安全要点：

• ✅ 从环境变量读取Token
• ✅ 使用envsubst动态替换
• ✅ Docker部署时传递环境变量
• ⚠️ 生产环境建议使用OAuth2或mTLS

3. 提示词工程的"最小化"策略

Cursor提示词给我们的启示：

原则	说明	示例
功能专注	每个提示词只做1-3件事	Cursor只做"编辑代码"和"回答问题"
依赖模型能力	不要重复模型已知的知识	不需要教"什么是Python"
防御性约束	明确不该做什么	"不确定时询问用户"
格式规范	用特殊标记简化解析	{{ edit_this }}标记

反面案例（过度工程化的提示词）：

❌ 你是一个精通Python、JavaScript、Go、Rust...的专家
❌ 你需要遵循PEP8、ESLint、Google Style Guide...
❌ 你必须考虑性能、安全、可维护性、可扩展性...

推荐方案（像Cursor一样精简）：

✅ 你是编程助手，帮助编辑代码
✅ 输出最小可工作的代码修改
✅ 不确定时询问用户

---

可迁移的设计智慧：从代码编辑到通用场景

核心洞察：Cursor的642 tokens提示词，最大的价值不在于"具体实现"，而在于"设计思想"。

这个章节将从Cursor的特定场景（代码编辑）中，提炼出跨场景适用的通用设计原则，而非简单地照搬其具体实现。

---

设计思想 > 具体实现

为什么不能照搬Cursor的提示词？

Cursor的提示词 = 100%为代码编辑优化

特定于代码场景的设计：
- {{ edit_this }} 格式标记
- "应用模型"概念
- "preserve indentation"约束
- diff格式化输出

其他场景的现实：

❌ 内容创作：需要自由发挥，不能用严格格式
❌ 对话问答：需要自然语言，不能强制结构化
❌ 批判性分析：需要探索性思考，不能预设答案框架
❌ 技术写作：需要创意和风格，不能机械化输出

但是，我们可以提取其中的设计原则，这些原则是跨场景通用的。

---

原则1：极简主义的三个层次

第一层：删除AI已知的知识

Cursor不会做的事情：

❌ "你精通Python、JavaScript、Go、Rust..."
❌ "你需要遵循PEP8、ESLint、Google Style Guide..."
❌ "编程最佳实践包括：单一职责、开闭原则..."

为什么？

• 现代LLM经过大量代码训练，已经内化了这些知识
• 重复说明浪费Token，且可能限制模型的灵活性
• 信任模型能力 > 过度约束

迁移到其他场景：

场景	❌ 不需要说的	✅ 应该说的
技术写作	"技术文章需要结构清晰、逻辑严谨..."	"Assemble风格：批判性思维+实战价值"
对话总结	"总结需要提炼核心、去除冗余..."	"保留争议点，标注不确定性"
批判性分析	"批判性思维需要多角度、辩证看待..."	"必须提供对立面观点，不能附和"

行动指南：

1. 列出当前提示词的所有规则
2. 逐条问自己："这是AI已知的常识吗？"
3. 如果是，删除或改为"特例"约束
4. 只保留"你的领域特有"的规则

---

第二层：专注1-3个核心目标

Cursor的核心目标：

1. 编辑代码（主任务）
2. 回答问题（辅助任务）
3. 不引入bug（约束条件）

不是Cursor的目标：

• ❌ 代码审查
• ❌ 架构设计
• ❌ 性能优化
• ❌ 安全审计

为什么专注重要？

AI的注意力是有限的
→ 目标越多，每个目标的质量越低
→ 多目标之间可能相互冲突
→ 不确定优先级时容易"乱做"

迁移到Assemble场景：

当前AGENTS.md的问题：

⚠️ 同时包含：
   - Prompt推荐（元任务）
   - 内容创作（执行任务）
   - 批判性分析（质量保证）
   - 文件夹命名（格式规范）
   - 协作流程（交互规则）
   
→ 注意力分散，AI不知道优先级

优化方案：分层设计：

第1层：核心协作原则（200 tokens）
├─ 批判性思维优先
├─ 不确定时必须询问
└─ 最小改动原则

第2层：任务执行规则（按需加载）
├─ 内容创作 → 调用"技术内容构建Prompt"
├─ 批判性分析 → 调用"综合批判性分析Prompt"
└─ 格式规范 → 调用"可读性优化Prompt"

第3层：领域知识（工具查询）
├─ 文件夹命名规范 → 查README
├─ 现有Prompt库 → 查Prompt Assemble目录
└─ 技术参考 → 查相关技术文档

---

第三层：信任模型能力，只约束关键决策

Cursor的约束重点：

✅ 约束：不确定时询问（防止胡编）
✅ 约束：最小改动（防止引入bug）
✅ 约束：保留原有格式（防止噪音）

❌ 不约束：如何写代码（信任模型能力）
❌ 不约束：用什么算法（信任模型判断）
❌ 不约束：代码风格细节（信任模型学习）

约束的边界：

约束 = 人类必须决策的点
不约束 = AI可以自主发挥的点

迁移到Assemble：

场景	✅ 应该约束	❌ 不需要约束
技术写作	必须包含批判性分析	具体的写作风格
对话总结	保留关键争议点	总结的具体措辞
内容优化	不改变原有结构	如何增强可读性

---

原则2：防御性设计的通用模式

核心理念：承认AI的不可靠性

Cursor的做法：

"Only make changes that you are confident about. 
 If you are not confident, suggest the change and ask the user."

这不是代码编辑特有的，而是所有AI应用都应该遵循的原则。

---

防御性设计的五个层次

Level 1：识别不确定性

AI应该在以下情况停止：

1. 需求存在歧义
   例："优化这个文章" → 优化什么？可读性？深度？风格？

2. 需求自相矛盾
   例："保持原样但让它更好" → 矛盾

3. 缺少关键信息
   例："分析这个方案" → 哪个方案？什么维度分析？

4. 涉及主观判断
   例："选择更合适的技术栈" → 合适的标准是什么？

5. 有多个等价方案
   例："用Redis还是Memcached？" → 需要权衡

Assemble应该如何做：

##  必须停止并询问的场景

遇到以下情况，不要猜测，立即询问：

1. **歧义需求**："优化文章" → 问：优化可读性？深度？还是结构？
2. **矛盾需求**："保持简洁但详细说明" → 问：优先简洁还是详细？
3. **缺失信息**："分析方案" → 问：哪个方案？从什么角度分析？
4. **主观判断**："选择更好的架构" → 问：评价标准是什么？
5. **多重选择**："用A还是B？" → 列出：A的优势、B的优势、我的倾向、请你决策

询问格式：
我注意到 [具体问题]，为了更好地完成任务，请明确：
1. [澄清问题1]
2. [澄清问题2]
如果你有倾向性意见，请告诉我，我会据此调整方案。

---

Level 2：显式表达置信度

不好的做法（AI假装自信）：

❌ "这个方案最好"
❌ "应该用Redis"
❌ "这是标准做法"

好的做法（Cursor式的谨慎）：

✅ "我倾向于A方案，因为[理由]，但如果[特殊情况]，B更合适"
✅ "如果优先考虑性能用Redis，如果优先考虑简单性用Memcached"
✅ "常见做法是X，但你的场景可能需要Y，请确认"

Assemble的模板：

##  表达不确定性的标准格式

高置信度（>90%）：
"这是成熟的最佳实践：[方案]，理由：[证据]"

中置信度（50-90%）：
"我倾向于[方案A]，因为[理由]，但需要注意[风险/前提]"

低置信度（<50%）：
"这个问题有多种方案：
 - 方案A：[优势] vs [劣势]
 - 方案B：[优势] vs [劣势]
 我无法判断哪个更适合你的场景，请提供更多信息或由你决策"

---

Level 3：最小改动原则

Cursor的版本（代码场景）：

"Don't arbitrarily change things from the original code 
 not directly related to the user's request. 
 Preserve whitespace, indentation, newlines, etc."

通用版本（适用所有场景）：

只改必须改的 = 减少引入问题的概率 + 降低用户认知负担

迁移到不同场景：

场景	最小改动原则的体现
文档编辑	只修改明确要求的段落，保持原有标题层级和结构
内容优化	只优化可读性，不改变技术观点和论证逻辑
代码重构	只改目标模块，不"顺便"重构其他代码
方案设计	只回答当前问题，不提前设计未来需求

Assemble的细化规则：

##  最小改动原则的执行清单

修改前自查：
1. ✅ 这个改动是用户明确要求的吗？
2. ✅ 这个改动是完成任务必需的吗？
3. ✅ 这个改动会影响其他未涉及的部分吗？

如果任一答案是"否"或"不确定"，不要改。

修改后汇报：
- 改了什么：[具体改动]
- 为什么改：[对应的用户需求]
- 影响范围：[只影响X，不影响Y]
- 未改动的：[保留了原有的Z]

---

Level 4：建立错误恢复机制

Cursor没有做，但应该做的：

❌ 如果用户说"撤销"怎么办？
❌ 如果AI生成了错误代码怎么办？
❌ 如果用户不满意结果怎么办？

Assemble应该考虑的：

##  错误恢复机制

如果我的输出不符合你的预期：

1. **明确指出问题**："这个不对，因为[具体问题]"
   → 我会分析问题根源，调整方案

2. **提供对比**："我期望的是[A]，你给的是[B]"
   → 我会理解差异，精确修正

3. **回滚请求**："撤销，恢复到之前的版本"
   → 我会记录历史状态，可以回滚（如有快照）

4. **重新开始**："这个方向不对，我们换个思路"
   → 我会清除之前的假设，重新分析需求

不要担心反复修改，迭代是正常的，明确反馈比礼貌客气更重要。

---

Level 5：元认知能力

最高级的防御性设计：AI知道自己"不知道什么"

Cursor没有体现，但是未来方向：

"我注意到你的需求可能涉及[X领域]，这超出了我的可靠知识范围，
 我可以尝试给出方案，但建议你：
 1. 咨询该领域的人类专家
 2. 查阅最新的官方文档
 3. 进行小规模验证后再大规模应用"

Assemble的元认知清单：

##  AI的知识边界声明

我可以可靠地做到：
✅ 提炼已有内容的核心思想
✅ 识别逻辑漏洞和自相矛盾
✅ 优化文本的可读性和结构
✅ 提供常见技术方案的对比分析

我不太可靠的领域：
⚠️ 最新技术动态（截止日期：2023年10月）
⚠️ 特定公司的内部实践（除非你提供资料）
⚠️ 主观的审美和风格判断
⚠️ 商业决策和法律建议

我完全不能做的：
❌ 访问实时数据（股价、天气等）
❌ 执行外部操作（发邮件、调API）
❌ 保证绝对正确（我会犯错）

当任务超出可靠范围时，我会明确告知并建议替代方案。

---

原则3：格式化输出的适用边界

Cursor的格式化设计

{{ edit_this }}  # 特殊标记
[language] [filepath]  # 结构化元数据
diff格式  # 降低解析复杂度

为什么这么设计？

目标：降低"应用模型"的解析难度
手段：用特殊标记明确"编辑边界"

---

格式化输出的通用价值

核心原则：

输出格式 = 降低下游处理成本

但需要权衡：

严格格式 ✅ 易于解析  ❌ 限制创造力
自由格式 ✅ 灵活表达  ❌ 难以自动化

---

适用场景矩阵

场景类型	推荐格式化程度	理由
批量处理	严格格式	需要自动化处理
结构化提取	严格格式	需要可靠解析
技术写作	松散格式	需要创作自由
批判性分析	自由格式	需要深度思考
对话总结	半结构化	需要平衡

---

Assemble的格式化策略

场景1：README生成（严格格式）

##  目录结构

输出格式：
\`\`\`
├─ [Emoji] [文件夹名] - [一句话描述]
│  ├─ [核心文档1]
│  └─ [核心文档2]
\`\`\`

规则：
- 每个文件夹必须有emoji
- 描述不超过15字
- 按重要性排序

场景2：技术内容构建（松散格式）

##  技术内容构建

输出要求：
- 必须包含"历史演进"和"设计哲学"两部分
- 必须有批判性分析
- 格式自由发挥，优先清晰表达

不要求：
- ❌ 固定的标题层级
- ❌ 统一的段落长度
- ❌ 特定的图标使用

场景3：批判性分析（半结构化）

##  批判性分析

最小结构要求：
1. [核心观点]的分析
2. [对立面观点]的分析
3. [风险和局限]的分析
4. [我的立场]（允许"不确定"）

格式灵活：
- 可以用表格对比
- 可以用案例论证
- 可以用问题启发
- 优先深度思考 > 格式统一

---

反模式：过度格式化的危害

案例：过度约束的提示词

❌ 错误示例：
"每个段落必须5-7句话"
"每个小节必须有emoji"
"必须用'首先'、'其次'、'最后'的结构"

为什么错？
→ AI会为了满足格式牺牲内容质量
→ 限制了自然表达
→ 导致机械化、不自然的输出

正确做法：

✅ 只约束必要的结构，放开表达方式

"必须包含：历史演进、设计哲学、批判性分析
 格式自由：你认为怎样表达最清晰就怎样写"

---

原则4：分层架构的成本优化

Cursor的"应用模型"启示

高级模型（GPT-4）：理解需求、生成方案
 ↓
低级模型（便宜模型）：执行编辑、应用diff

通用价值：

任务分层 → 模型分层 → 成本优化

---

Assemble的分层策略

任务复杂度分类

任务类型	复杂度	推荐模型	Token预算
批判性分析	高	Claude 3.5 Sonnet / o1	不限
技术内容构建	中	Claude 3.5 Sonnet	8K-16K
对话总结	中	Claude 3.5 Sonnet	4K-8K
可读性优化	低	GPT-4o-mini	2K-4K
格式美化	低	GPT-4o-mini	<2K
批量处理	低	GPT-4o-mini	<1K

分层执行策略

示例：技术文章优化

第1步：核心重构（Claude 3.5 Sonnet）
- 任务：优化论证逻辑、增强批判性分析
- Token：10K
- 成本：$0.15

第2步：可读性优化（GPT-4o-mini）
- 任务：添加图标、调整段落、优化标题
- Token：3K
- 成本：$0.006

第3步：格式检查（GPT-4o-mini）
- 任务：检查markdown语法、链接有效性
- Token：1K
- 成本：$0.002

总成本：$0.158（如果全用Claude约$0.30）
节省：47%

---

分层的风险控制

什么时候不能分层？

❌ 批判性思维任务 → 不能用便宜模型
   理由：推理能力不足，容易附和

❌ 重要技术决策 → 不能用便宜模型
   理由：可能产生错误建议

❌ 需要全局理解的任务 → 不能拆分
   理由：上下文丢失

✅ 格式化、美化、检查 → 可以用便宜模型
✅ 已有清晰指令的执行 → 可以用便宜模型
✅ 二元判断（是否/对错） → 可以用便宜模型

---

总结：三个可迁移的核心智慧

1. 极简主义 ≠ 简单粗暴

不是：删除所有规则，让AI自由发挥
而是：
  - 删除AI已知的常识
  - 专注1-3个核心目标
  - 只约束关键决策点

检验标准：

• ❓ 这条规则AI是否已经知道？→ 是则删除
• ❓ 这个约束是否限制了合理的灵活性？→ 是则放宽
• ❓ 这个目标是否真的必要？→ 否则删除

---

2. 防御性设计 ≠ 限制能力

不是：处处设防，让AI畏手畏脚
而是：
  - 识别不确定性并明确表达
  - 最小改动减少引入问题
  - 建立错误恢复机制

检验标准：

• ❓ AI是否在不确定时勇于承认？→ 是则有效
• ❓ AI是否会过度谨慎拒绝合理请求？→ 是则过度
• ❓ 用户是否能轻松纠正AI的错误？→ 是则良好

---

3. 格式化 ≠ 僵化

不是：强制所有输出使用固定模板
而是：
  - 批量处理用严格格式
  - 创造性任务用松散格式
  - 根据下游需求决定格式化程度

检验标准：

• ❓ 这个格式约束是为了什么？→ 必须有明确目的
• ❓ 这个约束是否牺牲了表达质量？→ 是则过度
• ❓ 是否有更灵活的替代方案？→ 有则考虑

---

对Assemble的直接启示

立即可做的优化

1. 精简AGENTS.md

   当前：~2000 tokens，包含大量常识性内容
   目标：~800 tokens，只保留Assemble特有规则
   
   删除：
   - AI已知的通用规则
   - 可以通过工具查询的信息（文件夹命名等）
   - 低频使用的详细说明
   
   保留：
   - 批判性思维优先（核心价值观）
   - 不确定时必须询问（核心交互规则）
   - 最小改动原则（核心质量约束）
   - Prompt推荐策略（核心功能）
   

2. 强化防御性设计

   增加"必须停止并询问"的清单
   增加"表达置信度"的标准格式
   增加"错误恢复机制"的说明
   

3. 分层设计Prompt库

   核心层（3个，高频）：
   - 技术内容构建
   - 批判性分析
   - 对话总结
   
   增强层（8个，按需）：
   - 其他专业Prompt
   
   自动判断：
   - 根据任务类型自动推荐合适的Prompt
   

---

未来展望：AI编程助手的演进方向

1. 个性化优化时代

TensorZero的愿景：

"Cursor是为全体用户优化的，但通过代理+反馈循环，可以为个人使用模式优化"

可能的实现路径：

• 使用模式分析：前端开发者vs后端开发者，不同的提示词策略
• 个人偏好学习：代码风格、命名习惯、注释偏好
• 持续反馈优化：基于git commit质量评估AI建议

批判性质疑：

• ❓ 个性化优化的边际收益有多大？
• ❓ 是否会导致"过拟合"到个人风格，降低代码可维护性？
• ❓ 数据隐私如何保障？

2. 多模型混合架构

Cursor的"应用模型"启示：

任务分层 → 模型分层 → 成本优化

未来可能的架构：

GPT-4o (理解复杂需求) 
  → Claude 3.5 Sonnet (生成核心逻辑)
    → Llama 3 70B (执行简单重构)
      → Codestral (代码补全)

技术挑战：

• 路由策略：如何智能判断任务复杂度？
• ⚡ 延迟优化：多次模型调用的累计延迟
• 成本控制：动态模型选择的成本收益平衡

3. 透明度与控制权的博弈

两种极端趋势：

模式	代表	特点	用户群体
黑箱模式	Cursor (原始)	快速迭代，用户无感	普通开发者
透明模式	CursorZero, Open Interpreter	完全可控，可审计	隐私敏感用户、企业

未来可能的平衡点：

• ️ 可选透明度：默认黑箱，但提供"调试模式"查看提示词
• 本地优先：核心模型调用在本地，云端仅做辅助
• 匿名化遥测：用户可选择共享使用数据用于优化

---

给Assemble知识库的实践建议

1. 立即可行的技术实验

实验1：搭建自己的CursorZero

# 1. 部署TensorZero
git clone https://github.com/tensorzero/tensorzero
docker-compose up -d

# 2. 配置Ngrok
ngrok http 3000

# 3. 修改Cursor配置
Settings → Models → Override OpenAI Base URL

收益：

• ✅ 完全掌控Cursor的模型调用
• ✅ 收集个人使用数据用于分析
• ✅ A/B测试不同模型（Claude vs GPT-4 vs Gemini）

风险：

• ⚠️ Ngrok免费版限制（建议用Cloudflare Tunnel替代）
• ⚠️ 凭证泄露风险（必须配置Nginx认证）
• ⚠️ 延迟增加（通常+50-200ms）

实验2：提取自己的"Assemble助手"提示词

当前状态：AGENTS.md中有AI协作规则，但是否足够精简？

优化方向（参考Cursor的642 tokens）：

1. 删除冗余：去掉AI已知的常识性内容
2. 专注核心：保留Assemble特有的规则（如文件夹命名、Prompt推荐）
3. 分层设计：核心规则 vs 情境规则（通过工具调用动态加载）

2. 知识库内容的优化路径

现有内容分类（基于project_layout）

类别	文件数量	内容特点	优化建议
AI技术观察	~30篇	时效性强、案例丰富	✅ 定期归档过时内容
工程思维	~20篇	原理性强、长期价值	✅ 构建主题索引
Case Study	3篇	实战性强	⚠️ 数量较少，可扩充
杂记与思考	~20篇	个人洞察	✅ 提取可复用模式

建议新增的内容主题

基于本文启示：

1. 《AI编程助手技术解构系列》

   • Cursor逆向工程（本文）
   • GitHub Copilot提示词分析
   • Claude Code Agent架构研究

2. 《提示词工程最佳实践》

   • 极简主义 vs 详尽规范
   • 多模型混合策略
   • 个性化优化方法

3. 《技术伦理边界讨论》

   • 逆向工程的法律边界
   • 商业机密与技术分享的平衡
   • AI时代的新伦理准则

3. Prompt库的迭代方向

当前Prompt库的问题（批判性分析）：

• ⚠️ 11个Prompt是否过多？参考Cursor的极简主义
• ⚠️ 是否存在功能重叠？如"可读性优化"和"图标美化"
• ⚠️ 是否应该分层？核心Prompt vs 增强Prompt

建议的优化方案：

核心Prompt层（3-5个，高频使用）：
├─ 技术内容构建（覆盖80%场景）
├─ 批判性分析（重要决策必选）
└─ 对话总结（协作必备）

增强Prompt层（按需调用）：
├─ 可读性优化
├─ 数据验证
└─ 可复用模式识别

情境Prompt层（动态生成）：
└─ 根据文件类型、用户历史自动生成

---

批判性反思：我们应该做"CursorZero"吗？

支持方观点

1. 技术自主权

   • 不依赖单一厂商
   • 数据完全掌控
   • 自由实验和优化

2. 成本优化

   • 直接调用API可能更便宜
   • 可选择性价比更高的模型
   • 避免Cursor的订阅费

3. 隐私保护

   • 代码不经过Cursor服务器
   • 敏感项目的合规要求
   • 企业级数据安全

反对方观点

1. 技术维护成本

   • 需要维护Ngrok/Nginx/TensorZero
   • 模型切换需要重新调试
   • 技术故障的排查成本

2. 功能完整性

   • Cursor的Tab补全依赖专有模型
   • 代理可能影响某些高级功能
   • 版本更新可能导致不兼容

3. 法律风险

   • 可能违反服务条款
   • 商业使用的合规性
   • 逆向工程的法律边界

我的建议

对于个人学习者：
✅ 推荐尝试 - 学习价值高，了解底层机制

对于隐私敏感用户：
✅ 推荐使用 - 数据安全优先

对于企业团队：
⚠️ 谨慎评估 - 考虑合规性和维护成本，可能直接购买企业版更划算

对于Assemble知识库：
✅ 建议实验 - 作为技术学习项目，收集数据优化AI协作规则

---

核心要点总结

技术层面

1. ✅ Cursor的提示词工程采用极简主义，仅642 tokens
2. ✅ 层级模型架构：核心模型生成 + 应用模型执行
3. ✅ 通过代理可实现完全控制和A/B测试
4. ⚠️ 用户凭证和代码必须经过Cursor服务器

商业层面

1. ❌ 系统提示词泄露削弱Cursor的竞争优势
2. ⚠️ 隐私问题可能影响用户信任
3. ✅ 倒逼行业持续创新
4. ⚠️ 法律和伦理边界尚不明确

实践层面

1. ✅ 代理架构是LLM应用可观测性的最佳实践
2. ✅ 提示词工程的未来是"专注+精简"
3. ✅ 多模型混合是成本优化的关键
4. ⚠️ 个性化优化需要大量数据和实验

---

延伸阅读

相关资源

• TensorZero GitHub
• CursorZero示例配置
• Prompt Engineering Guide

Assemble知识库相关文档

• # Prompt Assemble/ - 专业Prompt库
• # Cursor实战万字经验.md - Cursor使用最佳实践
• # ️ Anthropic Engineering/ - Anthropic的工程实践（类似的技术哲学）

后续待研究问题

1. ❓ GitHub Copilot的提示词是什么？
2. ❓ Claude的Code Agent模式如何实现？
3. ❓ 如何基于git commit质量评估AI建议效果？
4. ❓ 企业级AI编程助手的合规部署方案？

---

个人评价

技术价值：⭐⭐⭐⭐⭐
这是一篇极具实战价值的逆向工程案例，完整展示了从需求到实现的技术路径。

启发价值：⭐⭐⭐⭐⭐
提示词的极简主义、层级模型架构、防御性约束等设计哲学值得深入学习。

伦理争议：⭐⭐⭐☆☆
商业机密的公开发布引发争议，但技术分享和商业利益的平衡是永恒难题。

可操作性：⭐⭐⭐⭐☆
技术方案完整可复现，但生产环境部署需要考虑更多安全和维护问题。

---

最后的思考：

技术无罪，但我们需要为技术的使用负责。

逆向工程Cursor是否"道德"？这个问题没有标准答案。但我认为：

1. 透明度是进步的前提 - 用户有权知道AI工具如何运作
2. 商业秘密需要尊重 - 公开发布需要权衡对创作者的影响
3. 技术分享促进创新 - 封闭只会导致重复造轮子
4. 法律规范亟需完善 - AI时代需要新的游戏规则

对于Assemble知识库而言，这篇文章最大的价值不是"如何破解Cursor"，而是如何用批判性思维审视技术、理解设计哲学、提炼可复用的模式。

这正是我们构建知识库的核心目标：不是收集信息，而是提炼智慧。

---

生成时间：2025年10月15日
文档版本：v1.0
状态：✅ 已完成