AtomCode Prompt Engineering 实战：让 AI 精准生成代码的10个核心技巧

爱上纯净的蓝天

15人浏览 · 2026-08-05 11:00:00

爱上纯净的蓝天 · 2026-08-05 11:00:00 发布

前言

作为面向代码场景优化的 AI IDE，AtomCode 的 Prompt 逻辑与通用 LLM（如 GPT-4）存在本质差异：通用 LLM 仅依赖对话历史生成内容，而 AtomCode 会自动注入当前文件、项目结构、Git 状态等代码上下文，同时支持工程规范识别、工具链自动调用（如 Jest、Prisma、Git）。

因此，AtomCode 的 Prompt 不能沿用通用 LLM 的“口语化提问”逻辑，必须结合代码上下文、工程规范、可执行约束三个核心要素，才能让 AI 生成符合项目要求的可运行代码。本文将基于 AtomCode 2024.7 版本的特性，讲解10个专属 Prompt 设计技巧，所有模板可直接复用。

一、AtomCode 与通用 LLM 的核心差异

在开始技巧讲解前，先明确两者的能力边界，避免用通用 Prompt 逻辑浪费 AtomCode 的专属能力：

维度	通用 LLM	AtomCode
上下文来源	仅对话历史	对话历史+当前文件+项目结构+Git状态
工程感知	无	自动识别 `package.json`、`tsconfig.json`、目录规范
工具调用	需明确指定	自动调用 Jest、Prisma、Git、Lint 等工具
代码执行	需手动复制运行	直接在 IDE 中运行、调试、反馈结果
错误处理	仅生成代码	自动捕获错误并生成修复代码

AtomCode 的 Prompt 必须绑定代码上下文、指定工程规范、添加可执行约束，才能发挥其 AI 编码助手的最大价值。

二、结构化 Prompt 基础：AtomCode 专属占位符

AtomCode 支持自动填充的代码上下文占位符，这是通用 LLM 不具备的核心能力，正确使用占位符可以大幅减少 Prompt 编写成本：

占位符	含义	示例内容
`{{current_file}}`	当前打开文件的路径+完整内容	`src/features/user/user.service.ts` 的完整代码
`{{project_structure}}`	项目根目录下的目录树（自动生成）	`src/features/` 下的所有子目录和文件
`{{related_files}}`	与当前文件存在引用关系的文件	`src/features/user/user.controller.ts`、`src/features/user/user.types.ts`
`{{git_status}}`	本地未提交的 Git 变更	`modified: src/features/user/user.service.ts` （含 Diff）
`{{dependencies}}`	项目 package.json 中的依赖列表	`react: 18.2.0`、`zod: 3.21.0`、`jest: 29.5.0`

结构化 Prompt 通用模板

基于占位符，我们可以设计 AtomCode 专属的 Prompt 模板框架，适用于90%以上的编码场景：

// AtomCode Prompt 通用模板（可复用）
const ATOM_PROMPT_TEMPLATE = `
【任务类型】: [生成/修改/重构/测试/调试]
【作用范围】: {{current_file}}
【工程规范】: 
- 参考 {{project_structure}} 下的目录命名规则
- 遵循 {{related_files}} 中的代码风格
- 使用 {{dependencies}} 中已安装的依赖，禁止引入新依赖
【具体要求】: 
1. [明确的功能/修改点，如：实现 userId 参数的权限校验]
2. [边界条件，如：处理 userId 为空、格式错误、不存在用户的情况]
3. [可执行约束，如：生成后自动运行 Jest 测试并修复失败用例]
【输出格式】: 直接生成可在 AtomCode 中运行的代码，包含完整的 import 语句
`;

三、10个 AtomCode 专属 Prompt 设计技巧

技巧1：指定「工程路径」，替代模糊描述

❌ 错误示例：写一个登录功能
✅ 正确示例：在 src/features/auth/login.tsx 中，基于 src/features 下现有的 React Query 状态管理规范，实现邮箱密码登录功能，支持 Remember Me 选项
原理：AtomCode 能自动识别 src/features 的目录规范，参考同目录下的组件写法，生成风格一致的代码。

技巧2：绑定「现有依赖」，避免重新造轮子

❌ 错误示例：写一个表单验证逻辑
✅ 正确示例：使用项目已安装的 zod 库，为 src/features/user/user-form.tsx 实现表单验证，参考 src/utils/validation.ts 中的 validateEmail、validatePassword 函数
原理：AtomCode 会自动读取 package.json，调用已安装的依赖，避免生成不存在的 import 或重复实现现有工具函数。

技巧3：引用「关联文件」，保持代码一致性

❌ 错误示例：定义一个 User 类型
✅ 正确示例：参考 src/features/product/product.types.ts 的定义风格，为 src/features/user/user.types.ts 定义 User 接口，包含 id、email、role、createdAt 字段
原理：AtomCode 会自动提取关联文件的代码结构，保持类型定义、命名规范的一致性，避免团队内部的代码风格混乱。

技巧4：添加「可执行约束」，实现闭环

❌ 错误示例：写一个 add 函数
✅ 正确示例：在 src/utils/math.ts 中实现 add(a, b) 函数，要求支持数字、字符串数字、BigInt 类型，同时生成 src/utils/math.test.ts 的 Jest 测试，覆盖正负数、小数、边界值，生成后自动运行 npm test 并修复失败用例
原理：AtomCode 可以自动调用 npm、Jest 等工具，生成代码后直接执行，捕获错误并生成修复代码，实现“生成→测试→修复”的闭环。

技巧5：利用「Git 上下文」，精准生成 Diff

❌ 错误示例：优化 user.service.ts
✅ 正确示例：基于 {{git_status}} 中 src/features/user/user.service.ts 的变更，优化第23行的 SQL 查询，改为参数化查询，避免 SQL 注入，同时不影响现有功能
原理：AtomCode 能识别未提交的 Git 变更，仅针对修改部分生成代码，而非重写整个文件，减少代码冲突。

技巧6：多文件协同，一次性生成完整模块

❌ 错误示例：（分多次生成）先写 User 类型，再写 User 服务，再写 User 控制器
✅ 正确示例：为 src/features/product/ 生成完整 CRUD 模块：product.types.ts（类型定义）、product.service.ts（Prisma 业务逻辑）、product.controller.ts（Express 接口）、product.routes.ts（路由），参考 src/features/user/ 的模块结构
原理：AtomCode 能一次性生成多个关联文件，保持模块结构的完整性，避免分多次生成时的代码风格不一致。

技巧7：指定「异常场景」，提前规避 Bug

❌ 错误示例：写一个 getUserById 函数
✅ 正确示例：实现 getUserById(id) 函数，处理3种异常：id 为空（返回 400）、id 格式错误（返回 400）、用户不存在（返回 404），错误码参考 src/utils/errors.ts 中的定义，添加对应的单元测试
原理：AtomCode 会自动覆盖边界条件，减少代码上线后的 Bug 率，避免“只实现 happy path”的问题。

技巧8：量化「性能要求」，优化代码质量

❌ 错误示例：优化 findUsers 函数
✅ 正确示例：优化 src/features/user/user.service.ts 中的 findUsers 函数，当前时间复杂度 O(n²)，要求优化到 O(n log n)，保持返回结果一致，添加性能测试用例对比优化前后的耗时
原理：AtomCode 能识别代码的时间复杂度、空间复杂度，生成优化方案并验证，量化性能提升效果。

技巧9：生成「文档关联代码」，保持同步

❌ 错误示例：为 auth 模块写 README
✅ 正确示例：为 src/features/auth 模块生成 README.md，包含模块功能、API 列表、使用示例，所有示例代码从 auth.service.ts 中提取，确保文档与代码同步
原理：AtomCode 会自动关联代码生成文档，避免“代码更新后文档过时”的常见问题。

技巧10：指定「测试覆盖要求」，保障代码质量

❌ 错误示例：写单元测试
✅ 正确示例：为 src/features/order/order.service.ts 生成 Jest 单元测试，要求分支覆盖率 ≥90%，覆盖正常流程、参数异常、依赖失败、边界条件，Mock 所有外部依赖（数据库、API、消息队列）
原理：AtomCode 会根据覆盖率要求生成测试用例，自动 Mock 依赖，避免生成“无效测试”（如不覆盖边界条件、测试不独立）。

四、AtomCode 专属 Prompt 模板库（可直接复制）

模板1：CRUD 模块生成模板

// 替换 {feature}、{fields}、{ref_feature} 即可使用
const CRUD_PROMPT = `
【任务】: 生成 {feature} 模块的完整 CRUD
【作用范围】: src/features/{feature}/
【工程规范】: 参考 src/features/{ref_feature}/ 的模块结构（types→service→controller→routes）
【字段要求】: {fields}（如：id、name、price、stock、createdAt）
【具体要求】:
1. 生成4个文件：{feature}.types.ts、{feature}.service.ts、{feature}.controller.ts、{feature}.routes.ts
2. 服务层使用 Prisma 操作数据库，控制器使用 Express 处理请求
3. 所有接口返回统一格式：{ code: number, data: any, message: string }
4. 添加 zod 参数校验和自定义异常处理（参考 src/utils/errors.ts）
【输出格式】: 直接生成所有文件的完整代码，包含 import 语句
`;

// 使用示例：生成 Product 模块 CRUD
CRUD_PROMPT.replace('{feature}', 'product')
  .replace('{fields}', 'id、name、price、stock、description、createdAt')
  .replace('{ref_feature}', 'user');

模板2：单元测试生成模板

// 替换 {file_path}、{test_file}、{ref_test} 即可使用
const TEST_PROMPT = `
【任务】: 为 {file_path} 生成 Jest 单元测试
【参考】: 项目现有测试风格（{ref_test}）
【具体要求】:
1. 测试文件：{test_file}
2. 覆盖率要求：分支覆盖率 ≥90%
3. 测试场景：正常流程、参数异常、依赖失败、边界条件
4. Mock 规则：使用 jest.mock 模拟所有外部依赖（数据库、API、事件总线）
5. 命名规范：test('should [行为] when [条件]', ...)
【执行约束】: 生成后自动运行 npm test，修复所有失败用例直到通过
`;

// 使用示例：为 user.service.ts 生成测试
TEST_PROMPT.replace('{file_path}', 'src/features/user/user.service.ts')
  .replace('{test_file}', 'src/features/user/user.service.test.ts')
  .replace('{ref_test}', 'src/features/user/user.controller.test.ts');

模板3：代码重构模板

// 替换 {file_path}、{code_range}、{issue}、{target} 即可使用
const REFACTOR_PROMPT = `
【任务】: 重构 {file_path} 的 {code_range}（如：第10-50行）
【当前问题】: {issue}（如：圈复杂度15、存在重复逻辑、违反 DRY 原则）
【重构目标】: {target}（如：圈复杂度≤10、消除重复代码、单一职责）
【约束条件】:
1. 保持功能不变，所有现有测试用例必须通过
2. 遵循 SOLID 原则
3. 提取公共逻辑到 src/utils/
【执行验证】: 重构后自动运行 npm test，确保所有测试通过
`;

// 使用示例：重构 findUsers 函数
REFACTOR_PROMPT.replace('{file_path}', 'src/features/user/user.service.ts')
  .replace('{code_range}', '第20-60行的 findUsers 函数')
  .replace('{issue}', '时间复杂度 O(n²)、存在重复过滤逻辑')
  .replace('{target}', '时间复杂度 O(n log n)、消除重复逻辑');

模板4：问题调试模板

// 替换 {file_path}、{issue} 即可使用
const DEBUG_PROMPT = `
【任务】: 调试 {file_path} 的 {issue}（如：登录接口返回 500）
【上下文】: 当前文件内容、Git 变更、关联文件（自动注入）
【排查步骤】:
1. 分析可能的错误原因（参数校验、数据库连接、依赖异常）
2. 在代码中添加调试日志（使用项目已有的 logger 工具）
3. 生成修复方案，保持功能不变
4. 添加单元测试覆盖异常场景
【输出格式】: 先输出错误原因分析，再输出修复后的代码
【执行约束】: 修复后自动运行 npm test，确保所有测试通过
`;

// 使用示例：调试登录接口
DEBUG_PROMPT.replace('{file_path}', 'src/features/auth/auth.controller.ts')
  .replace('{issue}', '登录接口在密码正确时返回 500');

五、AtomCode Prompt 避坑指南

❌ 坑1：一次让 AI 做太多

错误示例：写一个电商系统，包含用户、商品、订单、支付模块
正确示例：先写 User 模块的 CRUD，再写 Product 模块的 CRUD，分步骤进行
原因：AtomCode 的上下文窗口有限，过多需求会导致代码质量下降，甚至生成不完整的代码。

❌ 坑2：忽略现有代码和依赖

错误示例：写一个表单验证逻辑（不管项目是否有现有验证工具）
正确示例：使用 src/utils/validation.ts 中的 validateEmail、validatePassword 函数，为登录表单实现验证
原因：AtomCode 会读取现有代码和依赖，复用能生成更一致、可维护的代码。

❌ 坑3：模糊的需求描述

错误示例：优化这个函数
正确示例：优化 src/utils/array.ts 中的 findMax 函数，当前时间复杂度 O(n²)，要求优化到 O(n)，保持返回结果一致
原因：模糊需求会导致 AI 生成不符合预期的代码，甚至生成错误的逻辑。

❌ 坑4：不指定边界条件

错误示例：写一个除法函数
正确示例：实现 divide(a, b) 函数，处理3种边界条件：b=0（返回 Infinity）、a/b 为非数字（抛 TypeError）、结果为小数（保留2位）
原因：边界条件是 Bug 的高发区，AI 需要明确的要求才能覆盖。

六、实战案例：Prompt 优化对比

案例：生成带权限校验的用户删除接口

初始 Prompt（模糊，生成质量差）

写一个删除用户的接口

AI 生成的代码问题：

不知道用什么框架/数据库
没有权限校验（任何用户都能删除）
没有异常处理
返回格式不统一

优化后 Prompt（精准，生成质量高）

【任务】: 生成用户删除接口
【作用范围】: src/features/user/user.controller.ts
【工程规范】: 使用 Express + Prisma，参考 src/features/order/order.controller.ts 的风格
【具体要求】:
1. 接口：DELETE /api/users/:id
2. 权限校验：只有 admin 角色能删除，当前用户通过 req.user 获取
3. 业务逻辑：检查用户是否存在、删除用户、返回删除结果
4. 异常处理：用户不存在（404）、权限不足（403）、参数错误（400）
5. 添加 Jest 测试用例（src/features/user/user.controller.test.ts）
【执行约束】: 生成后自动运行 npm test，修复所有失败用例

AI 生成的代码：