---
title: "基本对话交互"
description: "把模糊请求改成可执行要求：补目标、范围与验收标准，一次推进一个目标，用文件和报错补上下文，并给一套能反复用的开头模板。"
updated: 2026-11-13
canonical: https://docai.cc/learn/basic-chat-interaction/
markdown_mirror: https://docai.cc/learn/basic-chat-interaction.md
---
## 先承认：答得不好，多半是问得不够

同一个工具，有人用它一次改对，有人来回十轮还在原地。差别往往不在模型，而在输入里缺了什么。

新手最常漏的三样：目标是什么、限制在哪里、怎么算完成。补上这三样，答案的形状会立刻不同；顺序反了，先抠措辞，改十遍还是偏。提示词的基本构成，可以看[提示词](/concepts/prompt/)。

## 把「帮我看看」换成可执行的要求

模糊的请求没有边界，它只能给你一个平均答案。

| 模糊说法 | 缺什么 | 改成 |
|---|---|---|
| 帮我看看这段代码 | 语言、报错、期望行为 | 贴最小复现，说明实际结果与预期 |
| 帮我优化一下 | 优化目标 | 说明是提速、减内存还是提高可读性 |
| 帮我写个函数 | 输入输出与边界 | 给出签名、示例、异常情况 |

一个真实的对比例子：

> 这段登录表单的校验只在提交时触发，我想改成失焦时也校验。只改 `src/views/Login.vue`，提示文案保持原样，不要动接口层。改完跑相关测试，把差异和测试结果一起给我。

这句话里有范围、有禁区、有验收标准。它能直接动手，你也能直接判断。

## 两个改写示范：文案与报错

第一个是营销文案。原话只有「帮我写个文案」，模型不知道产品、人群、渠道和长度，只能给一份谁都能用的稿子。补全后是这样：

> 帮写一条朋友圈文案，推广一款面向 18–28 岁学生的防晒霜，主打轻薄不闷痘；语气轻快，最多两个表情符号，一百字以内，结尾加一句购买入口提示。

第二个是代码报错。只说「代码为什么出错」，它既不知道语言，也看不到错误。把现场给全：

> JavaScript 项目，执行这段代码时报 `TypeError: Cannot read properties of undefined (reading 'name')`：`const user = users.find(u => u.id === 7); console.log(user.name)`。数组里可能没有 id 为 7 的记录。说明报错原因，并给出两种改法，一种保持调用方不变，一种在调用前判空。

两段都没用什么高级技巧，只是把用途、对象、限制和可验证的结果摆出来。前者能直接发布，后者能直接改代码。

## 一次只推进一个目标

把五件事塞进一条消息，得到的往往是五段浅尝辄止的说明。更好的节奏是：

1. 先让它读懂现状，输出判断；
2. 你确认方向；
3. 再让它改一处，验证；
4. 通过后进入下一处。

多轮不是效率低。每一轮都在缩小不确定性，比一次性拿到一大坨无法验证的改动要快。上下文该怎么分配，可以看[上下文窗口](/concepts/context-window/)。

## 补上它拿不到的信息

它看不到你的屏幕，也看不到你没让它打开的文件；数据库里的内容更不会自动出现。三种补充最有效：

- 用 `@` 点名文件，别用「那个配置文件」这种描述；
- 贴真实的报错原文和触发步骤，不要转述；
- 说明你的身份与经验，决定它解释的深度。

最后一条常被忽略。同样问「什么是缓存」，对新手要打比方，对后端工程师可以直接讲失效策略。你不说，它只能猜。

还有一件事不要做：拿它当实时信息源。行情、新闻、今天的汇率、刚发布的版本号，都不适合直接问。它的知识有截止时间，也可能编出一个像样的数字。需要最新信息时，三条路：自己贴最新资料、接检索或外部工具、换用带联网能力的产品。资料越新，越该由你提供，别让它凭记忆补全。把「查事实」和「做推理」分开，能省掉很多返工。

## 不满意时，具体地说哪里不满意

「不太好，重写」是最低效的反馈。它不知道你不喜欢结构、语气还是深度，只能重新掷一次骰子。

有效的反馈长这样：

> 结构可以，但第二段太抽象。用一个具体例子替换，控制在两百字内；结论提前到开头。

指向位置、说明问题、给出标准。三轮之内通常能收敛。

## 对话跑偏时怎么拉回来

有些问题不是一句反馈能修的，而是对话本身跑偏了。按现象对号入座：

| 现象 | 为什么 | 怎么办 |
|---|---|---|
| 答案放之四海皆准 | 没写读者、用途和验收标准 | 补一句「给谁看、拿来做什么、什么算合格」 |
| 越聊越散 | 旧目标、旧材料都堆在上下文里，互相干扰 | 新开一轮，用三五句摘要带上已确认的结论 |
| 它说改好了，你却没看到变化 | 没有回读文件或运行验证 | 要求贴出改动位置和测试输出，自己再跑一遍 |
| 回答中途停住 | 输出长度到了上限 | 让它从断点继续，或先要提纲再分段展开 |
| 同一个问题两次答案差很多 | 采样有随机性，或提示里的条件不全 | 把评判标准写死，需要稳定时固定输出格式 |

这张表还有一个用法：把它当成写提示前的检查单。五行里只要有任意一行可能命中，就先补条件再发送。

还要认清适用边界。规则明确的批量转换，比如把两百个文件名统一成一种格式，写成脚本比来回对话可靠；需要逐字核对的法务、财务数字，必须有人复核；涉及删文件、改数据库这类不可逆操作，先让它说明影响范围、给出可回滚的步骤，确认后再执行。对话擅长的是目标清楚、路径需要试探的任务，不是所有任务。

## 一个可以反复用的开头

把下面四行填完，再补任务细节；这类结构的通用写法见[提示词模板](/concepts/prompt-template/)：

```text
我是谁：<角色、经验、熟悉的领域>
我要什么：<最终产物，以及它将被谁使用>
别做什么：<禁区、不能改的文件、不能引入的依赖>
怎么算完成：<验收标准，最好能自动检查>
```

填好的样子：

```text
我是谁：转行做运营三个月，之前五年做销售
我要什么：给部门周会写一页进展说明，读者是部门负责人
别做什么：不要罗列日常琐事，不要用「赋能」「闭环」这类词
怎么算完成：五条以内，每条一行，至少包含一个数字或日期
```

这四行不是仪式。它们分别解决视角、目标、边界和验收，正好对应大多数失败对话缺的那一块。

界面和命令熟悉之后，下一步是让它真正产出代码：从一个小功能开始，走完「描述、生成、验证」的闭环，见[基础代码生成](/learn/basic-code-generation/)。