---
title: "基础代码生成"
description: "从一句话需求到可合并的代码：把技术栈、输入输出、出错行为和项目约束写进提示，再用测试与改动范围逐轮收紧。"
updated: 2026-11-13
canonical: https://docai.cc/learn/basic-code-generation/
markdown_mirror: https://docai.cc/learn/basic-code-generation.md
---
## 一句话需求，只能换来通用代码

打开项目目录，叫起 Claude，说一句「写个函数，输入一组单词，去掉重复项后按字母顺序排列」，几秒就有结果。放进练习够用，放进真实仓库往往要重写：命名不合团队习惯、类型缺失、一出错就崩。

问题多半不在模型，而在输入。一句话描述只能换来通用答案。动手前先问自己三件事：这段代码放在哪个文件、被谁调用、用什么标准判断它写完了。三问答不上来，说明需求还没想清楚。想先了解它的定位，看[这个命令行工具是什么](/concepts/claude-code/)。

## 把需求拆成四件事

写提示之前，过一遍这四项：技术栈、输入输出、出错行为、禁区。

| 项目 | 模糊说法 | 可执行说法 |
|---|---|---|
| 技术栈 | 写个发邮件的函数 | 用 Node 的邮件库；TS 项目；主机、端口、账号、密码从环境变量读取 |
| 接口 | 处理一下用户输入 | 传入字符串，返回去掉空白与特殊字符后的安全串 |
| 出错 | 加点错误处理 | 找不到文件就返回空值，不抛异常；解析失败写日志，同样返回空值 |
| 边界 | 别乱用库 | 不新增依赖；不改公开参数；只动这一个文件 |

表格右列多花的三十秒，经常能省掉一轮返工。四项里最容易被忽略的是「出错」：你越早说清失败时返回什么、记录什么，生成结果越接近能上线的状态。把四项写成短句附在需求后面，比长篇背景描述更有用：背景说明它为什么做，约束说明它做到什么程度。

## 在已有项目里写：先读再写

它读得到仓库里的文件，这一点要用足。别急着下命令，先让它看相邻代码：

> 读一下 src/lib 下的两个工具文件，留意命名、注释和出错时的写法。
> 然后新增一个日期格式化函数，放在同目录，导出方式与它们一致。
> 先别改已有文件。

这一步的价值在于对齐风格。团队约定则提前写进项目根目录的 `CLAUDE.md`：目录职责、命名规则、哪些操作必须先问你。写一次，之后每次生成都会照着执行，也省得你反复解释。

生成完成后看一眼改动范围。如果它顺手改了你没提的文件，直接要求退回，只保留新增部分。

## 整块生成：拆成验收点

路由、组件、数据模型这类整块代码，一次生成看着痛快，审起来很痛苦。把验收点列出来，让它逐项交付：

> 做一个用户信息卡片组件，按顺序完成：
> 1. 列出 props 与类型定义；
> 2. 写出加载中、无数据、出错三种状态；
> 3. 样式只使用项目里现成的类名；
> 4. 每完成一项先停下，等我看过再继续。

行为拿不准时，反过来先要测试。比如密码强度判断，先把分级规则写成输入与期望输出，让它先交测试文件，你确认规则无误，再让它补实现。测试在前，返工在后，顺序不能反。验收点写得越具体，你回看时越省力；写成「做好一点」等于没写。

## 一个完整例子：从需求到补丁

把前面那四项压进一条提示，效果是这样：

```
在 src/lib/mailer.ts 新增 sendMail，供现有的通知服务调用。
- TypeScript，用项目已装好的邮件库，不新增依赖
- 连接信息从环境变量 SMTP_HOST、SMTP_PORT、SMTP_USER、SMTP_PASS 读取
- 入参 { to: string; subject: string; text: string }，返回 { ok: true } | { ok: false; error: string }
- 连接超时 10 秒，失败重试 1 次；仍失败就写日志并返回 ok: false
- 不抛异常，不改动其他文件
先给类型定义和函数签名，我确认后再写实现和单元测试。
```

这条提示里每一句都对应一个验收点：技术栈决定写法，环境变量决定配置来源，返回类型决定调用方怎么接，超时和重试决定失败行为，最后一句限制改动范围。少写哪一条，就得在 review 时补哪一条。

写完先跑类型检查和测试，再看 diff。只有这三样都过，才谈得上合并。

## 先定接口，再填实现

验收点管的是交付顺序，接口管的是依赖顺序。写路由、数据模型这类模块时，先把函数签名和返回类型定下来，再填业务：

1. 先让它列接口：有哪些函数、入参出参、会碰哪些表；
2. 再写失败分支：参数不合法、找不到记录、权限不足，各自返回什么；
3. 然后补正常路径；
4. 最后生成测试，覆盖前三步列出的每种情况。

比如新增一个商品接口，提示可以这样写：

> 参照 src/api/users.ts 的结构，为 products 建路由骨架。
> 先只列 CRUD 四个处理函数的签名和返回类型，不要写业务逻辑。
> 错误处理沿用项目现有的中间件，不要自己发明格式。

骨架确认后再逐段填。这样每一步的 diff 都短，出了问题也知道是哪一轮引入的。需求本身还没说清时，先看[如何把需求讲清楚](/learn/clear-requirement-description/)，比反复改代码省事。

## 三种最常见返工

| 现象 | 为什么 | 怎么办 |
| --- | --- | --- |
| 生成结果引入新依赖 | 提示里没说可用范围 | 写死「不新增依赖，只用运行时自带能力」 |
| 错误处理只有一层捕获 | 「健壮一点」不是可执行要求 | 列出参数校验、超时、重试、日志四项，逐项验收 |
| 缩进引号与项目不一致 | 靠形容词描述风格，没给配置 | 让它按仓库里的格式化配置跑一遍，再看 diff |

同一类问题连续出现两次，就把对应的限制补进规范文件，别等第三次再解释一遍。

交付前自己跑一遍测试，或者让它跑完把输出贴出来。它说通过不算数，命令说通过才算。遇到同类任务反复出现的问题，可以考虑固化成可复用的做法，参见[提示词模板](/concepts/prompt-template/)。

生成只是起点，读得懂才敢合并。下一节从一个陌生文件读起：[基础代码理解](/learn/basic-code-comprehension/)。