跳到正文
docai.cc

DOCAI · 课程 · L3 · 21 分钟 · 基础入门

基本对话交互

把模糊请求改成可执行要求:补目标、范围与验收标准,一次推进一个目标,用文件和报错补上下文,并给一套能反复用的开头模板。

Claude Code 程序员 · 基础使用指南

你将学会

  • 把一句模糊需求改写成可执行的任务描述
  • 用文件引用、报错原文与身份说明补足上下文
  • 用具体反馈推动迭代,而不是反复重开

先承认:答得不好,多半是问得不够

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

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

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

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

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

一个真实的对比例子:

这段登录表单的校验只在提交时触发,我想改成失焦时也校验。只改 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. 通过后进入下一处。

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

补上它拿不到的信息

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

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

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

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

不满意时,具体地说哪里不满意

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

有效的反馈长这样:

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

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

对话跑偏时怎么拉回来

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

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

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

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

一个可以反复用的开头

把下面四行填完,再补任务细节;这类结构的通用写法见提示词模板:

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

填好的样子:

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

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

界面和命令熟悉之后,下一步是让它真正产出代码:从一个小功能开始,走完「描述、生成、验证」的闭环,见基础代码生成。

自测

先自己回答,再展开对照;答不上来就回到对应小节。
  1. 01「帮我优化一下」这句话缺了什么?看答案

    缺优化目标、评价标准和范围。是提速、减内存、提高可读性,还是只改某个函数?目标不同,改法完全相反。

  2. 02为什么一次只推进一个目标?看答案

    多个目标挤在一条消息里,每个都只能浅尝辄止,你也难以验证哪一步出了问题。拆开后每轮都在缩小不确定性。

  3. 03对第一版不满意时,最有效的反馈长什么样?看答案

    指向具体位置,说明哪里不对,给出判断标准。例如「结构可以,第二段太抽象,用具体例子替换并控制在两百字内」。

查看 Markdown

涉及的概念

在知识树上

相关动态

全部新闻 →