大语言模型（LLM）出错很常见，但大语言模型正在改变我们编写Salesforce代码的方式。

Vibe编码工具在底层使用这些大语言模型来为APEX和LWC生成代码建议。但大多数开发者没有意识到的是：大语言模型（LLMs）会犯错，并且不理解Salesforce的独特限制，它们生成的代码在IDE中可以编译，但在生产环境中会出错。

当你使用大语言模型（LLM）生成Apex、LWC代码时，它会借鉴通用的编程模式。但Salesforce是有着自身平台限制的框架。所以如果不对AI Coding进行一些约束规则，就会遇到下面这些常见的错误场景：

1、编译错误：

1.1  SOQL查询数据，但未把代码中使用的字段都在查询中包含；子查询若没有特殊说明也是；导致编译错误：SObject row was retrieved via SOQL without querying field

1.2、不判断字段类型操作，例如 赋值公式字段，导致字段不可写的编译错误

1.3、不查看元数据结构，例如 缺少必填字段错误：REQUIRED_FIELD_MISSING, 缺少必填字段

1.4、使用一些java类或语法，但在salesforce中并不可用，例如 StringBuilder

2、执行时报错

2.1 不会做空指针校验

2.2 没有trigger的基础使用规范，例如更新自身数据需要在before中执行

3、部署时报错

3.1 会遗漏生成XML文件

3.2 依赖类的处理经常容易出错

总之，大语言模型（LLMs）是强大的代码生成工具，但它们缺乏对Salesforce独特约束条件的理解。通过识别这些常见的错误模式，你可以更有效地审查大语言模型生成的代码，并在错误进入生产环境之前发现它们。

综上所述，我们可以根据自己使用的经验，搭配Cursor的规则来约束AI；简单来说，Cursor Rules 就是一系列自定义规则，用于指导 Cursor 编辑器中的 AI 如何生成代码、提供建议和进行代码补全。这次我们主要看前2个

用户规则：在设置 - Rule - 可以配置如下，此处的配置会在全局生效（版本不同，入口稍微有差异）

项目规则：配置在 .cursor/rules 中

AI 在会话层面持续应用这套规则（不是你执行一次 sf 命令就去磁盘读一次 .mdc），当规则生效后（尤其 alwaysApply: true），AI 会把它当作持续上下文来遵循。

下面是我自己根据我的项目做的mdc示例：

---
description: Enforce Salesforce command and metadata execution rules
alwaysApply: true
---

# Salesforce Command Policy

Apply this rule whenever the task involves Salesforce development commands (`sf`, `sfdx`) or metadata updates in `force-app/main/default/**`.

- Follow `.cursor/rules/apex.md` as the primary Salesforce implementation checklist.
- Enforce SOQL completeness, LWC no-inline-template-expressions, and Apex null/map safety rules.
- For Aura/LWC callable Apex methods, require `@AuraEnabled` and `public static`.
- For metadata changes, update permission metadata (`objectPermissions`, `fieldPermissions`, `classAccesses`) in the same change set.
- After command execution, run targeted validation/tests and report any compliance gap with a fallback plan.

下面是自己总结搜集来的规则文件，可供参考

# Salesforce Apex AI Coding Operating Guidelines

**Version**: 1.1  
**Last Updated**: 2026-03-16

This document extends the general operating principles in `.cursorrules/core.md` with **Salesforce + Apex-specific** engineering rules. When conflicts exist, **platform safety (security, limits, data integrity)** wins.

---

## SOQL

- Query ALL fields that will be accessed, including relationship fields (Parent.Field)
- No filtering on LongTextArea or encrypted fields

## LWC TEMPLATES

- NO inline expressions: {a + b}, {condition ? x : y}, {items.length}
- Use JavaScript getters for all computed values
- Import decorators: import { LightningElement, api, track, wire } from 'lwc'

## APEX

- Use 'with sharing' by default
- Add null checks before property access
- Use Map.containsKey() before Map.get()
- No Java types: StringBuffer→String, HashMap→Map, ArrayList→List
- No addMilliseconds() - use addSeconds()
- Add recursion guards for triggers

## AURA/LWC CALLABLE

- Methods need: @AuraEnabled, public static
- Wrap exceptions in AuraHandledException

## AGENTFORCE/FLOW

- Use @JsonAccess(serializable='always' deserializable='always') for return types
- InvocableVariable only supports primitives and sObjects
- Dispatch 'valuechange' event from custom editors

## DEPLOYMENT

- Add fieldPermissions and classAccesses to permission sets
- Deploy order: Objects → Fields → Classes → Layouts → Permissions

## SALESFORCE COMMAND EXECUTION POLICY

- This rule applies to Salesforce development commands (`sf`, `sfdx`) and metadata changes under `force-app/main/default/**`.
- Before running command-related implementation, review this rule and follow all sections in this file.
- If a command would conflict with any rule in this document, stop and adjust implementation to comply.
- For metadata changes, always update both business metadata and required permission metadata together.

### Pre-Command Checklist

- Confirm SOQL fields are complete for every accessed field.
- Confirm LWC templates contain no inline expressions and use JS getters.
- Confirm Apex methods called by Aura/LWC are `@AuraEnabled` and `public static`.
- Confirm null checks and safe map access (`containsKey`) are present where needed.

### Post-Command Checklist

- Run targeted validation/tests after deployment commands.
- Verify permission sets include required `objectPermissions`, `fieldPermissions`, and `classAccesses`.
- If a requirement cannot be satisfied, explicitly report the gap and propose a compliant fallback.