AI编程使用笔记:Rule/Skill/Prompt
____tz_zs (2026-07-16)
在 AI 编程场景下,这三个概念其实对应不同的"记忆层级",目的都是把你和模型之间反复重复的信息,变成可复用、可持久化的资产。
原则
Rule 写"边界",Skill 写"流程",Prompt 写"任务"。
随着大模型(LLM)的推理能力不断进化,存在"少即是多"的趋势。
模型越聪明,不再需要大段的通用知识,而应该聚焦到项目本身的信息,把 prompt / skill / rule 做得更短、更稳定、更工程化。
小 prompt + 稳定 rule + 专项 skill + 自动化测试
| 类型 | 作用 | 适合放什么 | 不适合放什么 |
|---|---|---|---|
| Prompt | 一次性任务说明 | 本次目标、范围、上下文、验收标准 | 长期规范、团队约定 |
| Rule | 长期默认约束 | 项目架构、代码风格、安全边界、测试命令 | 复杂流程、临时需求 |
| Skill | 可复用工作流 | 多步骤操作、检查清单、产物模板、脚本/参考文件 | 全局常识、简单偏好 |
1、Prompt
Prompt 用于"这一次我要你做什么"。
帮我检查这个 Python 模块的并发安全问题。
重点看:
1. asyncio task 生命周期
2. 异常是否会吞掉
3. 连接池是否会泄漏
4. 是否存在重复下单风险
不要直接改代码,先给我风险列表和修改建议。
目标:要完成什么
范围:看哪些文件/模块
约束:不要做什么
验收:怎样算完成
输出:我希望你怎么汇报
不建议每次 prompt 都写:
你是世界顶级工程师,精通 Python、Node.js、Java、区块链、数据库、gRPC......
这种泛化身份设定现在价值很低。模型本身已经懂很多通用知识,真正有价值的是具体上下文和验收标准。
2、Rule
Rule 用于"永远或经常应该这样做"。
判断标准:如果你发现自己第 3 次提醒 AI 同一件事,就该写成 rule。
适合写成 rule 的内容:
- 本项目 Python 包管理使用 uv,不要生成 requirements.txt。
- 金额、价格、token 数量禁止使用 float,统一使用 int 或 Decimal。
- 修改 proto 文件后,必须重新生成 Python / Node gRPC stub。
- 数据库查询必须使用参数化 SQL,不允许字符串拼接。
- 做市相关逻辑必须考虑幂等性、重试、限频、部分成交和撤单失败。
- 修改撮合、风控、下单模块时,必须先说明潜在资金风险。
不适合写成 rule 的内容:
- 请写高质量代码
- 请遵循最佳实践
- 请不要犯错
- 请认真思考
这些太抽象,模型无法稳定执行。
Rule 的推荐写法
以 Codex / Claude / Cursor 都能理解的通用形式写:
makrdown
# Project Instructions
## Tech Stack
- Python 3.12
- uv for dependency management
- PostgreSQL
- gRPC
- asyncio
## Coding Rules
- Do not use float for money, price, token amount, or quantity.
- Use Decimal or integer base units instead.
- Prefer explicit type hints for public functions.
- Avoid broad `except Exception` unless the error is logged and re-raised or intentionally swallowed.
## Blockchain / Trading Rules
- Any order placement, cancellation, settlement, or balance update must be idempotent.
- Always consider partial fills, retry safety, nonce conflicts, and rate limits.
- Before changing market-making logic, summarize possible financial risks.
## Testing
- Run `uv run pytest` after changing Python code.
- Run gRPC codegen after modifying `.proto` files.
对于不同工具,文件名可能不同:
Codex: AGENTS.md
Claude Code: CLAUDE.md / .claude/skills/...
Cursor: .cursor/rules/*.mdc 或项目 Rules
通用做法: README_AI.md / AI_RULES.md,然后在工具规则里引用
Codex 的 AGENTS.md 支持全局和项目级分层,越靠近当前目录的指令优先级越高,适合 monorepo 或多服务项目。
3、Skill
Skill 用于"可复用的多步骤流程"。
比如你每次都让 AI 做这些事:
1. 读取 diff
2. 判断是否影响资金安全
3. 检查 decimal / nonce / slippage / fee / retry
4. 找相关测试
5. 补测试
6. 输出风险报告
这就不应该每次写 prompt,而应该做成 skill。
Claude Code 官方文档也明确说:当你不断复制同一套说明、清单或多步骤流程时,就适合创建 Skill;Skill 的正文只有在使用时才加载,所以长参考材料不会一直占用上下文。
Skill 示例:DEX 做市代码审查
目录结构:
.claude/skills/dex-mm-review/
SKILL.md
checklist.md
examples.md
SKILL.md:
markdown
---
name: dex-mm-review
description: Use this skill when reviewing DEX market-making, swap, pool, quote, order, balance, or settlement logic.
---
# DEX Market Making Review
## Goal
Review code changes related to DEX / CEX market making and identify correctness, financial, and operational risks.
## Steps
1. Read the relevant diff and identify touched modules.
2. Classify the change:
- quote calculation
- order placement
- cancellation
- balance sync
- settlement
- database persistence
- gRPC interface
3. Check financial correctness:
- no float for token amount or price
- correct decimal handling
- slippage limits
- fee calculation
- rounding direction
- partial fill handling
4. Check operational safety:
- idempotency
- retry behavior
- nonce conflict
- rate limit
- timeout handling
- duplicate order prevention
5. Check tests:
- unit tests
- integration tests
- edge cases
6. Output:
- high-risk issues
- medium-risk issues
- suggested patches
- missing tests
Claude 的 Skill 需要 SKILL.md,并且 frontmatter 里至少要有 name 和 description;官方也提醒 Skill 可能包含指令和代码,所以第三方 Skill 需要审计,避免恶意命令、数据泄露或不匹配的工具调用。
4、Prompt / Rule / Skill 的判断树
可以按这个顺序判断:
只是这一次要做?
=> prompt
以后经常要遵守?
=> rule
以后经常重复同一套流程?
=> skill
需要调用外部系统、API、数据库、链上节点?
=> tool / MCP / script
需要 100% 稳定执行?
=> 写代码,不要只靠 prompt
更工程化一点:
第一次:直接 prompt
第二次:整理成 prompt 模板
第三次:沉淀成 rule 或 skill
可自动化:变成脚本 / CLI / MCP 工具
高风险:加测试、权限、人审
5、模型越来越智能后,还需要这些吗?
需要,但价值变了。
以前 prompt / rule / skill 的作用是"教模型不会的知识"。
现在更多是:
告诉模型:这个项目里,我们选择了什么,不允许什么,哪里有坑。
模型再聪明,也不知道这些:
- 你们项目为什么不用 float
- 哪个 gRPC 字段历史上不能改
- 哪个数据库表不能直接写
- 哪个交易流程必须幂等
- 哪个测试命令才是有效的
- 哪些链上操作有资金风险
- 哪些依赖不能随便升级
所以模型变强以后,通用规则减少,项目规则更重要。
不需要:
- 超长身份设定
- 复制一堆"最佳实践"
- 大而全的 500 行 rule
- 每个框架都贴一份教程
更需要:
- 短规则
- 项目特有约束
- 可执行检查清单
- 明确测试命令
- 高风险操作边界
- 可复用 skill
还有一个现实原因,有研究观察到,仓库级 AGENTS.md 与 AI coding agent 更低的运行时间和输出 token 消耗相关,同时不明显降低任务完成行为;但另一项研究(Gloaguen et al., 2026)发现LLM 自动生成的上下文文件反而会降低在 SWE-bench Lite 等基准上的解决率,agent 会字面执行文件里的指令,哪怕这样做适得其反; AI IDE 生成的大型项目仍可能有重复、复杂度高、框架实践违规、异常处理等设计问题,需要经验开发者审查。规则文件必须是人写的、经过验证的;AI 自动生成然后直接提交的 rule/skill 文档,效果可能是负的。
"少即是多"------"人工筛选过的最小必要集合"