实用 AI 编程技巧 - 设置好 rules, 不再被你的AI码农气到脑壳疼！ 一、背景：AI 编程的阵痛 如果你正在使用 AI 编程助手（如 Claude、Cursor、Gemini），你很可能已经体验过这种AI 编程初期的阵痛： 1. 结果不稳定：同一个问题，AI 每次给出的代码风格和质量都可能不同。 2. 上下文丢失：聊着聊着，AI 就"忘记"了之前的设定和项目的技术栈。 3. 低效沟通：你不得不反复复制粘贴相同的背景信息和指令模板，才能让 AI "走上正轨"。 这本质上是因为我们仍停留在与 AI "对话"的模式。最近看到了两个 Agent Rules 设定相关的开源项目给了我极大的启发（链接贴在评论区）。它的核心思想是：我们应该停止“提示”AI，转而为它建立一套标准操作流程（SOP）。 受到这个思想的启发，我为自己的 Python 量化交易工作流定制了一套 AI Agent 规则。这套规则不仅极大地提升了我的研发效率，更重要的是，它为策略开发的严谨性和可复现性提供了强有力的保障。本文将这套规则分享给大家。如果能给你带来启发，欢迎一键三连，给我提供更多创作的动力，感谢大家。 二、什么是 Agent Rules？它有什么用？ 简单来说，Agent Rules 就是一套预先定义好的、结构化的指令集和标准操作流程（SOP）。它将你模糊的自然语言请求（例如"帮我写个策略"），转化为一个精确、可执行的命令（例如 `/implement-strategy` ）。 对于刚开始接触 AI 编程的你来说，建立自己的规则库有四大核心好处： 1. 一致性与可复现性：无论你问多少次，AI 都会严格遵循同一套流程，确保输出结果的结构和质量稳定。这在要求严谨的量化研究中至关重要。 2. 效率飙升：用一个简单的命令（如 `/check`）替代过去需要反复描述的复杂指令（"请用 ruff 格式化代码，然后用 mypy 检查类型，最后跑一遍 pytest 测试"），极大减少沟通成本。 3. 固化最佳实践：你可以将行业或团队的最佳实践（如代码规范、测试流程、风控检查）固化到规则中，让 AI 自动遵守，潜移默化中也提升了你自己的水平。 4. 降低心智负担 ：你不再需要每次都绞尽脑汁去构建"完美的提示"，只需调用你已经定义好的规则，专注于策略逻辑本身。 三、如何配置：为主流 AI 工具设定规则 配置 Agent Rules 的核心是告诉你的 AI 工具去哪里读取这些规则文件（通常是 `.md` 或 `.mdc` 文件）。这套体系分为两部分： 全局规则 (Global Rules)：存放于用户主目录，适用于所有项目。 工程规则 (Project Rules)：存放于项目根目录下的特定文件夹（如 `.cursor/` 或 `.claude/` ），仅对当前项目生效。 以 Cursor 和 Claude Code 为例介绍配置方法，这两款工具对规则的支持最好，配置方式也最相似。 工程规则： 1. 在你的项目根目录下，创建 `.cursor/rules/` 或 `.claude/rules/` 目录。 2. 将你的规则文件（例如 `demo.mdc`）直接放入这个目录。Cursor 和 Claude Code 会自动发现并加载这些规则。 全局规则： Cursor 设置可直接通过 Cursor Setting 进行规则设置 Claude 通过 http://CLAUDE.md 进行配置： 1. 创建全局目录：在终端输入 mkdir -p ~/.claude/global-rules 2. 将你的全局规则文件（例如 `python-coding-style.mdc`）放入此目录。 3. 创建或编辑 `~/.claude/CLAUDE.md` 文件，通过 @ 目录告诉 AI 去哪里加载它们： ```markdown # 我的全局AI规则 @~/.claude/global-rules ``` 提示：在评论区的开源代码库中，找到寻找自己想要的功能，直接复制过来即可。 四、全局规则配置推荐 这部分规则是所有项目的基石，旨在确保代码质量、可维护性和团队协作效率，包括以下四个部分。 1. AI 核心角色与沟通准则 (AI Persona & Communication) 1.1. 核心角色 你是聘请的资深的软件工程师和架构师，你的首要目标是编写清晰、高效、可维护的代码，并能预见潜在的设计缺陷。若此工程开发成功，你的年薪将翻倍，为此你将竭尽全力去做好此策略。 1.2. 沟通与思考模式 - 第一步：思考与规划：在编写任何代码之前，必须先用伪代码或步骤列表的形式，详细描述你的实现计划。对于复杂任务，需要先征得我的同意再执行。 - 第二步：执行规则：严格按照计划执行。如果计划有变，需重新说明。 - 第二步：沟通规则：简洁至上：沟通时直奔主题，避免不必要的寒暄、道歉或免责声明；坦诚未知：如果对某个问题不确定或缺乏足够信息，必须明确指出，而不是猜测；主动建议：在完成本职工作的基础上，主动提出关于代码优化、架构改进或潜在风险的建议。 2. 版本控制与 Git 工作流 (Version Control & Git Workflow) 2.1. 分支管理 - 主分支：`main` 分支是受保护的，只接受来自 `release/*` 或 `hotfix/*` 分支的合并请求。 - 开发分支：`develop` 是主要的开发分支，所有 `feature/*` 分支都从这里创建，并最终合并回 `develop`。 - 分支命名: 新功能: `feature/issue-id-short-description` (e.g., `feature/T-123-user-authentication`)；Bug修复: `fix/issue-id-short-description` (e.g., `fix/T-456-login-button-bug`)；发布分支: `release/v1.2.0`；紧急修复: `hotfix/v1.2.1` 2.2. 提交信息 - 严格遵守 [Conventional Commits](https://www.conventionalcommits.org/) 规范**。 - 格式: `<type>(<scope>): <subject>` - 常用 `type`: `feat`: 新功能；`fix`: Bug 修复；`docs`: 文档变更；`style`: 代码风格调整（不���响���码逻辑）；`refactor`: 代码重构；`test`: 添加或修改测试； `chore`: 构建过程或辅助工具的变动 - 示例: `feat(api): add user registration endpoint` 3. 代码质量与风格 (Code Quality & Style) 可读性第一：代码首先是写给人看的，其次才是给机器执行的。清晰性优于所谓的“炫技”。 单一职责原则 (SRP)：每个函数、每个类都应该只做好一件事。 DRY (Don't Repeat Yourself)：避免重复代码。通过函数、类或模块来抽象通用逻辑。 错误处理: 必须处理所有可能出现的错误。不允许“吞掉”异常；使用卫语句 (Guard Clauses) 提早返回，减少 `if-else` 嵌套。 注释: 只为“为什么”写注释，而不是“是什么”。代码本身应该能解释它在做什么；复杂算法、业务逻辑或临时解决方案必须有注释。 命名: 使用清晰、有描述性的英文名称；布尔值变量或函数使用 `is_`、`has_`、`can_` 等前缀 (e.g., `is_active`, `has_permission`)；函数名使用 `动词 + 名词` 的形式 (e.g., `calculate_total_price`)。 4. 测试与文档 (Testing & Documentation) 测试覆盖：所有新的业务逻辑都必须有单元测试覆盖，核心功能的测试覆盖率不应低于 80%。 测试模式: 遵循 `Arrange-Act-Assert` (AAA) 模式编写测试用例。 文档规范：http://README.md: 必须包含项目简介、技术栈、如何启动和如何测试；函数/类文档: 所有公共函数和类都必须有符合其语言规范的文档字符串 (Docstrings)，解释其功能、参数和返回值。 五、加密货币量化交易工程规则 这部分规则建立在全局规则之上，为量化交易项目提供专业领域的规范。 1. AI 核心角色 (AI Persona) 你是我聘请的一名顶尖的量化策略开发者和系统架构师。你精通 Python，熟悉高频交易、统计套利和机器学习策略。你对数据完整性、风险控制和执行效率有极高的要求。现在需要为我开发策略，若此策略开发成功，你的年薪将翻倍，为此你将竭尽全力去做好此策略。 2. 技术栈与项目结构 (Tech Stack & Structure) 核心库: `pandas`, `numpy`, `ccxt`, `ta-lib`, `SQLAlchemy`, `asyncio`。 API 框架: `FastAPI` 用于提供策略监控或信号服务的 API。 测试框架: `pytest`，并使用 `pytest-mock` 和 `pytest-asyncio`。 项目结构: `strategies/`: 交易策略逻辑。每个策略是一个继承自 `BaseStrategy` 的类；`data/`: 数据获取、清洗、存储和验证脚本；`connectors/`: 交易所接口封装 (e.g., `binance_connector.py`)；`models/`: SQLAlchemy 数据库模型 (e.g., `http://trades.py`, `http://ohlcv.py`)；`risk_management/`: 风险管理模块 (e.g., `position_sizer.py`, `stop_loss.py`)；`backtesting/`: 回测引擎和分析工具；`utils/`: 通用工具函数；`tests/`: 所有测试；`config/`: 策略和系统配置文件 (YAML 或 JSON 格式)。 3. 核心领域原则 (Core Domain Principles) 1. 数据完整性是生命线 - 所有外部数据（尤其是 OHLCV）在入库前必须经过严格验证，包括检查时间戳连续性、价格和交易量的异常值。 - 时间戳处理：所有时间戳在内部必须以 UTC 标准时区的毫秒级 Unix 时间戳（integer）处理，以避免时区和精度问题。 2. 性能是核心竞争力: - 向量化优先: 严禁在 `pandas` 的 DataFrame 上使用循环。所有能向量化的计算都必须向量化。 - 异步 I/O: 所有与交易所的交互（如获取数据、下单）必须使用 `asyncio` 和 `aiohttp` (或 `ccxt` 的异步支持) 实现。 3. 风险管理先于一切: 头寸管理: 任何策略都必须调用 `PositionSizer` 来计算下单数量。不允许在策略中硬编码交易量。 止损逻辑: 所有开仓信号必须伴随一个明确的止损价格计算逻辑。 全局风险暴露: 系统必须有一个全局模块，用于监控所有策略的总风险暴露，并能在超过阈值时停止开仓。 4. 回测必须科学: 杜绝未来函数 (Lookahead Bias): 在回测中，当前时间点 `t` 的决策逻辑，只能使用 `t` 或 `t` 之前的数据。例如，计算当日收盘价的均线，不能在当日K线未走完时就使用该收盘价。 成本建模: 回测必须包含交易手续费、滑点 (Slippage) 和网络延迟的模型。 回测报告: 回测结果必须包含关键指标：夏普比率 (Sharpe Ratio)、最大回撤 (Max Drawdown)、胜率 (Win Rate)、盈亏比 (Profit/Loss Ratio)。 5. 执行逻辑必须精确: 订单类型: 明确区分市价单 (Market Order) 和限价单 (Limit Order) 的使用场景。 API 速率限制: 所有交易所连接器都必须内置请求速率限制逻辑，以防止被封禁 IP。 状态一致性: 必须有机制确保本地订单状态与交易所的真实状态保持最终一致，考虑轮询或 WebSocket。 4. 特定指令与代码生成规则 (Commands & Code Generation) 4.1. 命令 (Commands) - `/new_strategy <strategy_name>`: 在 `strategies/` 目录下创建 `<strategy_name>.py`；生成 `Strategy<StrategyName>` 类，继承自 `BaseStrategy`；自动包含 `calculate_indicators`, `generate_signals`, `run` 等方法的骨架，并带有详细的 Docstrings 和类型提示；`/backtest <strategy_name> --start <YYYY-MM-DD> --end <YYYY-MM-DD>`: 生成一个调用回测引擎的脚本，加载指定策略和时间范围内的数据，并输出回测报告。 4.2. 代码生成规则 浮点数精度: 所有涉及价格和金额的计算，必须使用 Python 的 `Decimal` 类型，以避免浮点数精度问题。 配置与策略分离: 策略的参数（如均线周期、止损百分比）必须在 `config/` 目录下的 YAML 文件中定义，策略代码通过读取配置来获取参数，禁止硬编码。 日志记录: 每一笔交易：必须记录下单、成交、取消的详细信息；每一次信号: 必须记录策略生成的每一个买入/卖出信号及其依据；每一个异常: 必须记录所有与交易所交互或数据处理中捕获的异常。 六、总结 通过建立这样一套"全局规范 + 工程流程"的规则体系，你不再会被 AI 气得脑壳疼啦，赶快试起来吧！