MonkeyCode 提示词工程：写出高效 AI 编程指令的 30 个核心技巧

引言

"好的提示词是 AI 编程助手发挥威力的关键。" 同样的 MonkeyCode，有人觉得它只是简单的代码补全工具，有人却能用它完成复杂的架构设计、自动化重构和全栈开发。

差距在哪里？提示词工程（Prompt Engineering）。

本文将系统分享 30 个经过实战验证的 MonkeyCode 提示词技巧——从基础语法到高级策略，从单行补全到多文件协作，帮助你把 MonkeyCode 的能力发挥到极致。

🎯 核心信息

GitHub 仓库: https://github.com/monkeycode-ai/monkeycode

开源协议: Apache License 2.0

欢迎提交 Issue: 分享你的提示词技巧！

基础篇：提示词的核心原则（技巧 1-8）

技巧 1：明确指定编程语言和框架

❌ 模糊提示：
"写一个用户登录功能"

✅ 精确提示：
"用 TypeScript + Express + TypeORM + JWT 写一个用户登录 API，
包括邮箱密码验证、token 生成、密码 bcrypt 哈希（cost=12），
遵循 RESTful 规范，返回 JSON 格式"

为什么有效：明确语言和框架后，AI 可以直接使用对应的惯用法、库函数和最佳实践，减少猜测。

技巧 2：提供上下文而非孤立请求

// ❌ 孤立请求
"修复这个 bug"

// ✅ 提供完整上下文
/*
当前问题：用户登录后 session 在 5 分钟内过期，
预期应该是 24 小时。

相关代码位置：src/auth/session.ts
当前配置：{ maxAge: 300 } （单位：秒）
需求：将过期时间改为 24 小时，
同时实现滑动续期（每次操作自动延长）
*/

原则：上下文越充分，AI 的回答越精准。至少包含：

你在做什么
当前行为是什么
期望行为是什么
相关代码/配置

技巧 3：使用结构化输出格式

请按以下格式输出：

## 实现方案
[简要描述方案]

## 代码变更
### 新增文件
- `path/to/file`: [说明]

### 修改文件
- `path/to/file`: [具体改动]

### 删除文件
- `path/to/file`: [原因]

## 注意事项
- [潜在风险]
- [需要手动确认的事项]

效果：结构化输出让 AI 的回答更有条理，也方便你逐项检查和执行。

技巧 4：给出示例（Few-Shot Learning）

// 请按照以下风格编写 API 错误响应：

// 示例 1：参数缺失
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is required",
    "details": [{ "field": "email", "issue": "required" }]
  }
}

// 示例 2：未授权
{
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Invalid or expired token",
    "details": []
  }
}

// 现在，请为"余额不足"场景编写错误响应

原理：通过 1-3 个示例，AI 能快速理解你的编码风格和期望格式，大幅提高输出一致性。

技巧 5：分步骤描述复杂任务

请帮我完成以下任务，每一步都先确认再继续：

**Step 1**: 分析现有的 User 模型定义（src/models/User.ts），
列出所有字段及其类型

**Step 2**: 基于 Step 1 的分析，设计一个 UserProfile 扩展模型，
包含头像、简介、偏好设置等字段

**Step 3**: 编写数据库迁移脚本

**Step 4**: 创建对应的 Repository 层代码

请在每个 Step 完成后暂停，等我确认后再进行下一步。

适用场景：复杂重构、新功能开发、架构迁移。避免一步到位导致偏差累积。

技巧 6：告诉 AI 你的约束条件

// ✅ 明确约束的提示词
/*
请优化以下函数的性能：

约束条件：
1. 不能引入新的外部依赖
2. 需要保持向后兼容（API 签名不变）
3. 必须处理空值/边界情况
4. 时间复杂度要求 O(n)
5. 需要添加 JSDoc 注释
6. 遵循项目现有的 ESLint 规则
7. 不能使用 async/await（同步函数）
*/

关键：提前声明"不能做什么"和"必须满足什么"，避免返工。

技巧 7：利用角色设定（Persona）

你是一位拥有 15 年经验的资深后端架构师，
专精于高并发分布式系统设计。
你熟悉微服务架构、事件驱动设计、DDD 领域驱动设计，
对性能优化有深入理解。

请审查以下代码，从架构合理性、可扩展性、
可维护性和性能四个维度给出专业意见。
语气要直接但建设性，像 Code Review 一样。

可用角色：

角色	适用场景
资深架构师	架构评审、技术选型
安全专家	安全审计、漏洞排查
性能工程师	性能优化、瓶颈分析
测试工程师	测试用例生成、覆盖率提升
技术文档 writer	文档生成、注释完善
初学者导师	学习引导、概念解释

技巧 8：使用否定式排除法

请为我生成一个 React 表格组件，

❌ 不要使用：
- class 组件（必须用函数组件 + Hooks）
- any 类型（需要完整的 TypeScript 类型）
- 内联样式（使用 CSS Modules 或 Tailwind）
- 第三方表格库（纯手写）
- useEffect 做数据获取（使用 React Query）

✅ 要求：
- 支持排序、筛选、分页
- 虚拟滚动（处理万级数据）
- 可访问性（ARIA 属性）
- 单元测试友好

效果：明确排除项比只说"要什么"更有效，能避免 AI 使用你不想要的技术方案。

进阶篇：高级提示策略（技巧 9-18）

技巧 9：链式推理（Chain of Thought）

请按以下思路分析这个性能问题：

1️⃣ **现象描述**: API 响应时间从 200ms 恶化到 5s

2️⃣ **可能原因分析**:
   - 数据库查询变慢？（索引失效？数据量增长？）
   - 外部服务调用超时？
   - 内存泄漏导致 GC 频繁？
   - 锁竞争？
   - 网络延迟？

3️⃣ **排查优先级**: 按可能性从高到低排列

4️⃣ **诊断方法**: 每种原因对应的具体排查手段

5️⃣ **解决方案**: 最可能的 2-3 种修复方案

请逐步展开你的思考过程，不要跳步。

适用场景：Debug、架构决策、复杂问题分析。让 AI 展示推理过程，便于你判断其结论是否可靠。

技巧 10：自检与反思（Self-Reflection）

请完成以下代码编写后，进行自我审查：

📋 自检清单：
1. 是否有潜在的 null/undefined 引用？
2. 是否有资源泄漏风险（连接、句柄、订阅）？
3. 边界情况是否覆盖（空数组、超大输入、特殊字符）？
4. 错误处理是否完善？
5. 是否有安全风险（注入、XSS、敏感信息泄露）？
6. 命名是否清晰表达意图？
7. 是否有可以简化的冗余逻辑？

如果发现任何问题，请直接修正并标注修改原因。

效果：强制 AI 进行二次思考，能发现并修复 30-50% 的初级错误。

技巧 11：对比式提示

请对比以下两种方案实现用户权限管理：

**方案 A: RBAC (基于角色的访问控制)**
- 角色：admin, editor, viewer
- 权限绑定到角色

**方案 B: ABAC (基于属性的访问控制)**
- 基于用户属性、资源属性、环境属性动态决策

请从以下维度逐一对比：
1. 实现复杂度
2. 运行时性能
3. 灵活性
4. 可维护性
5. 审计便利性
6. 对我们团队（10 人后端团队，50+ 权限点）的适配度

最终给出推荐及理由。

技巧 12：思维导图式输出

请为以下项目生成架构思维导图（用 Markdown 格式）：

电商后台管理系统

要求涵盖：
- 前端模块划分
- 后端服务拆分
- 数据库设计概要
- 第三方集成点
- 核心业务流程

格式示例：
# 项目名称
## 模块A
### 子模块A1
#### 功能点
#### 技术栈
### 子模块A2
...

技巧 13：测试驱动提示（TDD Style）

请按照 TDD 流程完成以下功能开发：

**需求**：实现一个 URL 短链服务的生成算法

**Red 阶段**：先写测试用例
- 正常 URL 生成短链
- 相同 URL 返回相同短链
- 空输入处理
- 超长 URL 处理
- 特殊字符转义

**Green 阶段**：写最少代码使测试通过

**Refactor 阶段**：优化代码质量

请依次输出三个阶段的代码。

技巧 14：增量式迭代

// 第一轮：基础版本
"写一个快速排序函数"

// 第二轮：基于第一轮改进
"很好，现在请增加以下功能：
1. 支持自定义比较函数
2. 处理重复元素（稳定排序）
3.对小数组(< 10)切换为插入排序"

// 第三轮：进一步优化
"现在请优化：
1. 三数取中选 pivot
2. 尾递归优化
3. 添加类型泛型支持"

优势：每轮迭代都有基础，比一次性要求完美更容易得到好结果。

技巧 15：引用权威资料

请参考以下资料来实现我们的 API 设计：

📚 参考资料：
1. Google API Design Guide (https://google.github.io/styleguide/json/api_style_guide.html)
   → 字段命名规范、错误格式、分页设计
   
2. RFC 7807 (Problem Details for HTTP APIs)
   → 标准化的错误响应格式
   
3. OWASP API Security Top 10
   → 安全相关的最佳实践

请确保我们的 API 符合以上规范，
任何偏离的地方请特别说明理由。

技巧 16：代码审查专用提示模板

## 📋 Code Review Request

**PR 目标**: [简要描述]
**涉及文件**: [文件列表]
**变更规模**: [+xxx / -yyy 行]

**Review 重点**:
- [ ] 逻辑正确性
- [ ] 性能影响
- [ ] 安全风险
- [ ] 可读性与命名
- [ ] 测试覆盖

**背景信息**:
[相关的设计文档链接或架构说明]

**已知限制**:
[已知的 trade-off 或临时方案]

请以严格的 Reviewer 视角审查，
发现问题请标明严重程度：🔴 Must Fix / ⚠️ Should Fix / 💡 Nice to Have

技巧 17：文档生成增强

请为以下函数生成完整的 JSDoc 文档：

/**
 * [一行摘要]
 *
 * [详细描述：做什么、为什么、注意事项]
 *
 * @param {Type} paramName - [参数说明，含取值范围/默认值]
 * @param {Type} param2 - [同上]
 * @returns {ReturnType} [返回值说明，含各种可能的情况]
 * @throws {ErrorType} [什么情况下抛出]
 * 
 * @example
 * ```ts
 * // 示例 1：正常情况
 * const result = functionName(arg1, arg2)
 * // result: ...
 * 
 * // 示例 2：边界情况
 * const edge = functionName(null, arg2)
 * // throws: ...
 * ```
 *
 * @see [相关函数或文档链接]
 * @since v1.0.0
 * @author [作者]
 */

技巧 18：重构引导提示

请对以下代码进行重构，遵循以下原则：

🎯 重构目标：
1. **单一职责**: 每个函数只做一件事
2. **开放封闭**: 对扩展开放，对修改封闭
3. **依赖倒序**: 依赖抽象而非具体实现
4. **迪米特法则**: 最少知识原则

⚠️ 重构约束：
- 保持外部行为完全一致（所有现有测试必须通过）
- 不改变公共 API 签名
- 逐步重构，每步都可验证

📊 重构前指标：
- 圈复杂度: 23
- 函数长度: 180 行
- 重复代码率: 15%

🔄 请输出：
1. 重构计划（分几步，每步做什么）
2. 每步的具体代码变更
3. 重构后的预期指标改善

专家篇：高阶技巧（技巧 19-26）

技巧 19：多文件协作提示

我正在开发一个用户认证模块，涉及以下文件：

📁 项目结构：

src/
├── auth/
│ ├── types.ts # 类型定义
│ ├── strategy.ts # 认证策略接口
│ ├── jwt.strategy.ts # JWT 具体实现
│ ├── session.ts # Session 管理
│ └── middleware.ts # Express 中间件
├── models/
│ └── user.ts # 用户模型
└── config/
└── auth.ts # 认证配置


请按依赖顺序（types → models → config → auth）逐文件生成代码，
并在每个文件中标注与其他文件的依赖关系。
跨文件的引用要使用正确的 import 路径。

技巧 20：模式识别与复用

我在项目中反复遇到以下模式：

[粘贴 3-5 个类似的代码片段]

请分析这些代码的共同模式，
然后：
1. 提炼出通用的抽象层/工具函数
2. 用提炼出的通用方案重写这些代码片段
3. 给出未来类似场景的使用指南

技巧 21：性能基准对比

请为以下三种实现方式编写性能对比测试：

方案 A: for 循环 + push
方案 B: Array.map + filter
方案 C: Array.reduce

测试维度：
1. 小数据集 (n=100)
2. 中等数据集 (n=10,000)
3. 大数据集 (n=1,000,000)

测量指标：
- 执行时间 (ms)
- 内存占用 (MB)
- GC 压力 (GC 暂停次数)

请输出完整的 benchmark 脚本（使用 Node.js performance API）
以及预期结果分析。

技巧 22：安全审计提示

请对以下代码进行安全审计：

[粘贴代码]

按照 OWASP Top 10 和 CWE Top 25 检查清单逐一审查：

🔴 注入类:
- SQL Injection
- NoSQL Injection
- Command Injection
- LDAP Injection

🔴 XSS 类:
- Reflected XSS
- Stored XSS
- DOM-based XSS

🔴 其他:
- SSRF
- Path Traversal
- IDOR (不安全的直接对象引用)
- 敏感数据暴露
- 认证/授权缺陷

对每个发现的漏洞，请给出：
- 严重程度 (Critical/High/Medium/Low)
- CVE/CWE 编号（如有）
- 利用场景描述
- 修复建议代码

技巧 23：国际化/本地化提示

请将以下代码改造为支持国际化的版本：

当前：硬编码中文文案

目标：
1. 提取所有用户可见字符串到 i18n 资源文件
2. 支持 zh-CN / en-US / ja-JP 三种语言
3. 使用 react-i18next 或类似库
4. 处理插值变量、复数形式、日期/数字格式化
5. 保持类型安全（key 不允许拼写错误）

请输出：
- i18n 资源文件结构
- 改造后的组件代码
- 语言切换的实现方案

技巧 24：遗留代码理解

请帮我理解这段 legacy 代码：

[粘贴难以理解的代码]

请按以下格式输出：

## 📖 代码解读
### 整体功能
[一句话概括]

### 核心逻辑流程
[逐步解释执行流程，用自然语言]

### 关键变量含义
| 变量名 | 类型 | 含义 | 生命周期 |

### 设计意图推测
[作者为什么要这样写？有什么历史原因？]

### 潜在风险
[哪些地方容易出 bug？]

### 改进建议
[如果要重构，应该从哪里入手？]

技巧 25：Git Commit Message 生成

请根据以下 diff 生成规范的 Git Commit Message：

[粘贴 git diff 输出]

要求：
1. 遵循 Conventional Commits 规范
2. type: feat/fix/docs/refactor/test/chore/style
3. scope: 影响的模块
4. subject: 不超过 50 字符，中文可接受
5. body: 详细说明变更内容和原因
6. 如果关联 Issue，加上 closes #xxx

同时生成对应的 GitHub PR Description。

技巧 26：技术选型决策辅助

我们需要为新项目选择状态管理方案，候选者：

A. Zustand
B. Jotai
C. Redux Toolkit
D. Signal (来自 Solid.js 理念)

请从以下维度打分（1-10 分）并给出加权总分：

| 维度 | 权重 | A | B | C | D |
|-----|------|---|---|---|---|
| 学习曲线 | 20% |   |   |   |   |
| Bundle Size | 15% |   |   |   |   |
| TypeScript 支持 | 15% |   |   |   |   |
| DevTools 体验 | 10% |   |   |   |   |
| 中间件生态 | 10% |   |   |   |   |
| 性能 | 15% |   |   |   |   |
| 团队熟悉度 | 15% |   |   |   |   |

我们的团队背景：5 个中级前端开发者，
项目规模：中型 SaaS 应用，
预计开发周期：6 个月。

团队协作篇（技巧 27-30）

技巧 27：团队编码规范注入

以下是我们团队的编码规范，请在所有后续代码生成中严格遵守：

## 强制规则
1. 函数不超过 30 行
2. 嵌套层级不超过 3 层
3. 禁止使用 var
4. 禁止 any（除非有明确注释说明原因）
5. 所有 public 方法必须有 JSDoc
6. 错误必须使用自定义 Error 类
7. 异步函数必须有 try-catch 或 .catch()

## 命名规范
- 变量: camelCase
- 常量: UPPER_SNAKE_CASE
- 类: PascalCase
- 接口: PascalCase + I 前缀
- 类型别名: PascalCase + T 后缀
- 文件名: kebab-case

## Git 工作流
- feature 分支从 main 创建
- commit message 用英文
- PR 必须有 reviewer approval

请确认你已理解以上规范，回复 "OK" 后我将开始提问。

技巧 28：Onboarding 导师模式

我是团队的新成员，刚加入这个项目一周。

请作为我的技术导师，帮助我理解以下内容：

1. **项目概述**: 这个项目是做什么的？技术栈是什么？
2. **目录结构**: 每个主要目录的职责是什么？
3. **入门路径**: 如果我要修改 X 功能，应该从哪个文件开始看起？
4. **常见陷阱**: 新人最容易踩的坑有哪些？
5. **开发环境搭建**: 从零跑起来需要几步？
6. **调试技巧**: 出问题时怎么排查？

请用友好的、循序渐进的方式讲解，
假设我有 3 年的开发经验但不熟悉本项目的技术栈。

技巧 29：知识库构建提示

请将以下对话中有价值的知识提取出来，
整理成团队知识库条目：

[粘贴一次有用的 AI 对话]

输出格式：
---
## 知识条目
**标题**: [简洁标题]
**分类**: [API/架构/调试/最佳实践/陷阱]
**标签**: [tag1, tag2, tag3]
**内容**: [详细描述]
**适用场景**: [什么时候会用到这个知识]
**相关代码位置**: [涉及的文件/函数]
**来源**: [原始讨论链接或 PR 编号]
**置信度**: [高/中/低] — 这个知识的可靠性如何
---

技巧 30：提示词版本管理

# MonkeyCode 提示词模板库

## 📝 常用提示词模板

### template-01: 功能开发
```prompt
用 {language} + {framework} 实现 {feature}，
要求：{constraints}，
参考：{references}，
输出格式：{format}

template-02: Bug 修复

修复以下 bug：{description}
现象：{symptom}
期望：{expected}
环境：{environment}
已尝试：{attempted}

template-03: 代码审查

审查以下代码，重点关注：{focus_areas}
严格程度：{strictness_level}
输出格式：🔴 P0 / ⚠️ P1 / 💡 P2

template-04: 重构

重构以下代码，
目标：{goal}
约束：{constraints}
保持：{invariants}

建议: 将团队常用的提示词保存为模板，
在 IDE 中设置 snippet 快速调用，
保证团队输出的一致性。


---

## 总结：提示词效能金字塔

╱╲
╱ ╲ Level 5: 策略层
╱ 🧠 ╲ 系统思维 + 多轮迭代
╱──────╲
╱ 🎯 ╲ Level 4: 上下文层
╱ 结构化 ╲ 完整约束 + 角色设定
╱────────────╲
╱ 📋 精确 ╲ Level 3: 明确层
╱ 语言+框架+格式 ╲ 无歧义的需求描述
╱──────────────────╲
╱ ✅ 具体 ╲ Level 2: 清晰层
╱ 不是"写个功能" ╲ 有具体的输入输出
╱───────────────────────╲
╱ 💬 自然语言 ╲ Level 1: 基础层
╱ 能让人理解的请求


**记住**：每一层提升都能带来显著的输出质量改善。不必追求完美的 Level 5，从 Level 2-3 开始就能看到明显效果。

---

## 下一步行动

1. **收藏本文** 作为日常参考手册
2. **挑选 3 个技巧** 在今天的开发中试用
3. **建立团队的提示词模板库** 分享给同事
4. **在 GitHub 分享你的发现** 👉 [提交 Issue](https://github.com/monkeycode-ai/monkeycode/issues)

> **最好的提示词不是一次写成的，而是不断迭代优化的产物。**

**现在就打开 MonkeyCode，试试这些技巧吧！** 🚀

---

*本文由 MonkeyCode 团队原创，采用 Apache 2.0 许可证发布。*

**关键词**: `MonkeyCode` `提示词工程` `Prompt Engineering` `AI编程` `效率技巧` `开源` `GitHub` `Issue`

posted on 2026-06-25 12:09 MonkeyCode 阅读(26) 评论(0) 收藏举报

刷新页面返回顶部

导航