【AI编程】使用笔记：Rule/Skill/Prompt-平芜编程栈

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 都能理解的通用形式写：

# 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：

--- 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 文档，效果可能是负的。

“少即是多”——“人工筛选过的最小必要集合”