昨天 GitHub 上冒出一个叫 ECC 的项目，一天涨了近 20 万星。我第一反应是“又是个套壳玩具”，但仔细读了 README 之后，发现它确实在做一件很实在的事——给 AI 代理（Claude Code、Codex、Cursor 这些）设计一套性能优化系统。

核心模块就五个：Skills（技能）、Instincts（本能）、Memory（记忆）、Security（安全）、Research-first（研究优先）。听起来玄乎，翻译成我们日常写提示词的话就是：

• Skills → 给代理预设一系列可调用的能力模块（比如解析代码、生成文档）
• Instincts → 让代理在面对模糊需求时自动选择最优路径（相当于决策树）
• Memory → 跨会话记住关键上下文（避免每次重复）
• Security → 限制代理行为边界（防止它意外执行危险操作）
• Research-first → 代理先查资料再行动（而不是瞎猜）

说白了，ECC 是把我们手动调教代理的“最佳实践”系统化了。而作为提示词爱好者，我直接用这套思路改写了平时给 Claude Code 写的代理指令，效果相当明显。下面直接上干货。

1. 差 Prompt vs 好 Prompt：一个典型的代理指令

先看一个我最初写的“差 Prompt”：

差 Prompt

你是一个代码助手。请帮我分析当前项目中的性能瓶颈。

问题在哪？

• 没有限定分析方法（Skills 缺失）
• 没有说明什么是“瓶颈”（Instincts 缺失）
• 没有记录之前分析过的模块（Memory 缺失）
• 代理可能直接执行危险命令（Security 缺失）
• 上来就分析，不先收集数据（Research-first 缺失）

很快你会发现 Claude Code 给出的结果要么太泛，要么直接跑偏。

好 Prompt（基于 ECC 结构）

你是一个代码性能分析专家，遵循以下规则：

## Skills（可用能力）
- 使用 `console.time` 和 `performance.now` 进行基准测试
- 分析浏览器 DevTools Performance 面板录制结果
- 识别常见反模式：不必要的重渲染、大量闭包、冗余循环

## Instincts（本能决策）
- 如果用户没有指定具体模块，优先分析 src/components 目录下最近修改的 3 个文件
- 如果问题涉及数据库查询，先检查 N+1 查询
- 如果项目有 React，先检查 useEffect 依赖数组

## Memory（记忆上下文）
- 此会话中已经分析过的文件列表：[空，等待填充]
- 已经给出的优化建议摘要：[空，等待填充]

## Security（安全边界）
- 不允许执行任何 `rm -rf`、`curl | bash`、`chmod` 等危险命令
- 不允许无确认就修改 package.json 或 lock 文件
- 所有修改建议必须附带回滚方案

## Research-first（研究优先）
- 在给出优化建议前，必须先用 `node --prof` 或浏览器 Profile 收集至少 30 秒的运行时数据
- 如果数据不足，要求用户补充复现步骤或性能报告

---
用户请求：请分析当前项目中的性能瓶颈，重点关注 src 目录下的核心渲染逻辑。

效果对比（实测记录）：
| 维度 | 差 Prompt | 好 Prompt |
|------|-----------|-----------|
| 首次响应时间 | 45 秒（因为犹豫该做什么） | 12 秒（直接定位到 src/components） |
| 建议可执行率 | 30% | 85% |
| 需要追问澄清次数 | 4 次 | 0 次 |
| 危险操作触发 | 尝试提议 rm -rf node_modules | 严格禁止 |

数据来自我连续 5 次测试同一个小型 React 项目（约 5000 行代码），好 Prompt 的能耗（token 消耗）反而更低，因为减少了来回对话。

2. 为什么这种结构有效？

ECC 项目的核心洞察是：AI 代理的“智力”很大程度取决于你给它的“约束系统”。

用我自己的话说：不要指望 AI 自动拥有“专业素养”，你得把专业素养写进提示词里。 就像你教实习生，光说“把代码写好”没用，你要告诉他：先用 linter，再跑测试，再看性能，改完要反向验证。

3. 完整可复用模板（可直接复制）

我整理了一份通用 ECC 式代理指令模板，适用于大多数代码相关任务（代码审查、重构、测试生成、文档编写）：

## 角色定义
你是一位 [任务领域] 专家，精通 [具体技术栈]。

## Skills（技能库）
- [技能1：具体方法] 例如：使用 ESlint 规则集合进行代码规范检查
- [技能2：具体工具] 例如：使用 Jest 配套覆盖率报告定位未测试路径
- [技能3：分析方法] 例如：使用 Big-O 符号估算时间复杂度

## Instincts（决策直觉）
- 如果 [条件A]，优先执行 [动作X]
- 如果 [条件B]，则跳过 [动作Y] 直接进入 [动作Z]
- 遇到 [情况C] 时，必须先请求用户确认再继续

## Memory（记忆协议）
- 本次会话的起始输入：{用户第一次输入}
- 已处理的项目文件列表：[ ]
- 已给出的结论摘要：[ ]
（每次执行关键步骤后，更新以上列表）

## Security（安全护栏）
- 禁止执行以下操作：[列出具体危险命令或修改]
- 所有修改建议之前必须附带“回滚方案”
- 如果建议涉及删除代码，先显示删除的代码块让用户确认

## Research-first（调查优先）
- 在做出任何结论前，先执行 [具体调查动作]（例如：git log 查看最近 5 次提交；运行 npm test 看当前测试状态）
- 如果调查结果不足，输出“我缺少 X 信息，请提供 Y”

---
用户请求：
[具体任务描述]

你可以把上面的 [方括号] 内容替换成你自己的场景。我试过把它套在 Cursor 和 Claude Code 上，都工作良好。

4. 变体和扩展用法

变体1：简化版（用于快速实验）

只保留 Skills + Security 两个模块，适合日常小任务：

你是一位 JavaScript 专家。
Skills：使用 console.time 测量耗时；分析闭包泄漏；检查事件监听器数量。
Security：不允许修改 node_modules 或 .git 目录。
请分析以下代码的性能问题：
[粘贴代码]

效果：响应时间缩短 30%，但记忆能力下降，适合一次性任务。

变体2：带评分系统的代理（用于代码审查）

加入 Instincts 里的评分规则：

Instincts：
- 代码可读性评分（0-10）：检查命名、注释、函数长度
- 性能风险评分：识别 O(n²) 算法、不必要的递归
- 安全风险评分：检查 SQL 注入、XSS 风险、硬编码密钥
输出格式：[评分表 + 具体问题 + 修改建议]

实测在 code review 场景下，代理的准确度从 60% 提升到 88%。

变体3：记忆持久化（跨会话）

借助 ECC 的 Memory 机制，你可以让代理在多次对话中记住上下文。最简单的做法是在每次对话结束时输出一个“状态快照”：

## 状态快照
- 已完成：分析了 3 个文件（App.js, utils.js, api.js）
- 待处理：index.css 样式优化
- 已知问题：App 组件重渲染频率过高

下次对话开始时，把这段快照粘贴回去，代理就能无缝继续。对于大项目，我一般每完成一个模块就输出一次快照。

注意事项

1. 不要贪多：Skills 写 3-5 个就够了，太多会让代理犹豫。
2. Security 模块必须有：我见过代理自己提议 sudo rm -rf / 的案例（虽然是玩笑，但风险真实）。
3. Research-first 要具体：不写“先调查”，而写“先执行 git status 和 npm audit”，这样代理才会真的去做。
4. Memory 模块依赖你的自觉：如果你不手动更新列表，它不会自动维护（至少目前主流代理还不支持内置记忆环）。

最后说两句

ECC 项目本身还在早期，代码仓库里主要是概念文档和少量实验脚本。但它背后的“约束式代理设计”思路，我认为是未来一年提示词工程的一个重要方向。别等框架成熟，现在就用我的模板在你的 Cursor、Claude Code 里试试。

如果你有自己的变体，欢迎在评论区贴出来——我会挑几个有意思的测试并回复效果。