1.3 对话式 AI 时代：通过讨论完成代码草稿与问题分析

向同事请教问题时，你可以先描述现象，再补充背景，直到双方把问题说清楚。对话式 AI 把这种交流方式带进了编程：你不必先写出函数开头，可以直接描述想要实现的功能，或者询问一段代码为什么报错。

它降低了表达需求的门槛，也让学习和开发交织在一起。生成实现之前，可以先讨论方案；看到陌生语法时，可以要求结合当前代码解释；对结果不满意时，可以继续指出具体差异。

从一句需求到一段代码

以“整理读书笔记”为例，一开始不必直接要求生成完整项目。可以先说明：笔记保存在几个文本文件里，希望按书名分类，并输出一份目录。

接下来要逐步明确文件格式、目录位置、重名处理和输出样式。对话越能围绕这些具体问题展开，生成的代码越容易检验。

对话阶段	可以提供的信息	希望得到的结果
确定范围	要处理哪些文件，有什么限制	可执行的小任务
补充示例	一份输入文件和期望输出	对规则的共同理解
生成实现	运行环境、现有代码、禁止修改的部分	代码及运行说明
处理错误	完整报错、执行命令、实际现象	原因判断与修复建议
验收	正常和异常输入	与需求逐项核对的结果

比“帮我修一下”更有用的反馈

“代码不行”只表达了不满意，没有提供定位线索。可以改成：“输入文件有 20 条记录，输出只有 18 条；漏掉的两条书名包含空格。下面是其中一条原始记录。”这会把问题缩小到读取或拆分规则。

报错也不要只复制最后一句。错误类型说明发生了什么，调用栈说明从哪条路径走到这里。发送前去除密钥和个人信息，保留运行命令、文件名、相关代码和完整异常信息。

如果 AI 提出三种原因，可以让它说明如何区分，再逐项验证。一次只调整一个有依据的地方，更容易确认是哪项改动起了作用。

对话界面能看见什么

可以把模型想成远程顾问：你没有发给它的资料，它未必能够取得。对于未接入本地文件或执行工具的纯聊天界面，它主要依靠你提供的文字、附件和应用已加载的信息进行判断。

由此会产生几个实际问题：

• 文件版本不同步：你已经在本地改过，模型却仍按上一轮的代码回答。
• 相关信息遗漏：只提供了报错函数，没有提供调用者或数据格式。
• 代码拼接错误：把“只替换这段”的内容当成整个文件覆盖。
• 运行结果缺席：生成了代码，但没有人真正执行验证。

部分聊天产品提供文件连接、代码执行或预览功能，这些可以减少上述问题。判断能力时应看当前会话接入了什么工具，不能仅凭“在网页里聊天”判断它是否能执行任务。

常见平台应该怎么看

ChatGPT、Claude、DeepSeek 和 Gemini 都是常见的对话入口。它们的模型、附件支持和工具能力会持续调整，本节不把某个型号固定称为“编程最强”。

试用时，可以用同一道自己的小题：解释一段报错、修改一个函数，再判断回答是否贴合资料、是否指出未知条件、是否提供可验证的结果。比起回答是否流畅，这些表现更接近实际需要。

怎样把一次有效对话留下来

当功能完成后，把最终运行命令、依赖版本和关键决定记到项目文档中。例如：“笔记文件统一使用 UTF-8；输出覆盖前保留备份；书名从第一行读取。”下一次开发时，这些信息应随项目提供给 AI。

聊天记录适合探索，项目文档适合保存已经确定的约定。如果所有决定都散落在长对话里，换一个会话或换一位协作者，就要重新解释。下一节介绍的编辑器集成，正是为了更直接地连接讨论与项目现场。