最近把李宁老师的《AIGC 自动化编程——基于 ChatGPT 和 GitHub Copilot》从头到尾翻了一遍，越读越觉得这本书踩中了很多人用 AI 写代码的真正痛点。市面上聊 AIGC 和编程的书不少，但大多数要么停在“AI 能帮你写代码”的演示层面，要么一上来就铺概念、画大饼。这本书不一样，它直接把 ChatGPT 和 GitHub Copilot 这两样工具拆开揉碎，讲清楚它们在真实开发流程里到底该怎么用、能解决什么问题、会在什么地方掉链子。

如果你现在正处在“知道 AI 能写代码，但自己上手总觉得生成的东西不靠谱”的状态，或者你想系统搞懂 AIGC 自动化编程的完整流程、想从“用 AI 玩代码”升级到“用 AI 做项目”，那这本书非常值得花时间过一遍。它适合三类人：刚接触 AI 辅助开发的程序员、想转型 AIGC 应用工程师的开发者，以及团队里负责推行 AI 开发规范的负责人。整本书读完，我的核心感受就一句话：自动化编程不是让 AI 替你把项目写完，而是把重复劳动、样板代码、测试补全、文档整理这些脏活累活交出去，把人的精力留在设计和决策上。

1. 先别急着开干：这本书到底在解决什么问题

1.1 自动化编程不是“让 AI 写完全部代码”

很多人在接触 AI 编程工具时都有过一种错觉：我只要把需求描述清楚，AI 就能把整个项目吐出来。李宁老师在书里反复强调一个观点，也是我读完最认同的一句：AI 自动化编程的本质，是把“编码”这个动作从手工操作变成人与 AI 的协作流程，而不是把“编程”这件事本身完全交给机器。

这个区别特别重要。我见过不少刚上手 Copilot 的同事，写个函数连需求都懒得想清楚，直接在编辑器里敲两行注释，让 AI 把剩余代码补全，结果生成出来的东西看着像模像样，一跑全是坑。书里对这类场景讲得很直白：AI 是你的结对编程搭档，不是替你拍板的需求分析师。它能帮你快速生成可执行的代码草稿，能帮你补全重复性逻辑，能帮你把一段晦涩的代码翻译成人话，但它不知道你的业务约束是什么，不知道你的部署环境有什么限制，更不知道你代码里埋了哪些设计上的坑。

书里做了一个很清晰的定位：自动化编程的价值在于“更快的产出、更低的重构成本、更完整的覆盖”，而不是“零人工干预的软件工厂”。这个定位对心态建设特别重要，它能避免你陷入两个极端：要么觉得 AI 编程是智商税，要么觉得 AI 能替代所有程序员。

1.2 两个工具，两条路线：ChatGPT 与 GitHub Copilot 的定位差异

这本书的书名里同时出现了两个工具，这不是偶然的。李宁老师在书里花了相当多篇幅讲两者的区别，核心结论我列一下，我自己实际用了大半年，感受和书里基本一致。

ChatGPT 是“对话式编程助手”，它的强项在于理解完整需求、生成整段逻辑、跨文件解释代码、帮你设计方案。它适合在写代码之前的“思考阶段”介入：比如我要写一个复杂的 Excel 处理脚本，我先跟 ChatGPT 把需求对齐，让它帮我设计数据结构、梳理异常分支，再让它输出完整代码。它的问题也很明显：它看不到你的整个工程上下文，你需要在提示词里手动补充背景信息。

GitHub Copilot 是“嵌入式补全引擎”，它内嵌在 VS Code、Visual Studio、JetBrains 这些 IDE 里，直接读你当前打开的文件、最近的编辑记录、项目结构，在你写代码的过程中实时给建议。它适合在执行阶段介入，比如你在写一个重复性很高的映射函数，刚起了个头，它已经把你接下来五行猜得八九不离十了。

书里给了一个很实际的使用策略：大需求用 ChatGPT 定方案、出框架，小逻辑用 Copilot 补实现、提速。两条路线不是二选一，而是配合使用。

我后来在自己的项目里就是完全照这个思路组织的。先用 ChatGPT 把模块设计聊透，让 AI 生成接口定义和核心函数框架，然后把框架代码放进 VS Code，剩下的具体逻辑、边界条件、异常处理交给 Copilot 一边写一边补。

2. 把 ChatGPT 当结对编程搭档：书里的提问方法论

2.1 高质量提示词的三层结构

读这本书最大的收获之一，是让我把“怎么向 AI 提问”这件事从玄学变成了工程方法。全书关于提问的核心方法论可以归纳成一个三层结构：角色设定、任务描述、约束条件。

第一层角色设定是很多人容易忽略的。同样是“帮我写一段爬虫”，如果你只说这么一句，AI 给你的东西基本是教科书模板，拿过来根本不能用。如果你在前面加一句“你是一名有十年经验的 Python 爬虫工程师，专注于数据采集和反反爬策略”，生成结果的专业度会明显上一个台阶。这不是魔法，而是因为角色设定让模型在生成时自动对齐了相关的知识分布和代码风格。

第二层任务描述必须包含“输入、处理、输出”三个要素。这么说有点抽象，我拿书里的例子改一下：你让 AI 写一个批量重命名文件的脚本，至少要说清楚文件在哪个目录、按什么规则命名、是否需要递归处理子目录、是否有冲突时的处理策略。描述得越具体，AI 需要考虑的分支就越明确，生成出来的代码就越接近可直接运行的状态。

第三层约束条件是对齐代码质量的关键。你要告诉 AI 用什么语言和库、要不要考虑跨平台、性能优先还是可读性优先、是否要求兼容 Python 3.8、输出代码的同时是否要附带单元测试。这些约束在大多数情况下决定了一段生成代码能不能直接落到项目里。

我自己的习惯是建了一个 prompt 模板文件，每次让 ChatGPT 写业务代码时直接套用。这里给一个简化版：

你是一名资深 [语言/方向] 工程师，项目背景是 [一句话描述项目或业务场景]。 请完成以下任务：[具体功能描述，包含输入、处理、输出]。 约束条件： - 技术栈：[语言、框架、关键库及版本] - 代码风格：[简洁 / 工程化 / 面向对象等] - 需处理边界情况：[空值、超时、异常、并发等] - 输出要求：[是否包含注释、是否附带测试用例、是否给出调用示例] - 性能要求：[可忽略 / 中等 / 高]

这个模板看起来简单，但实际用下来，它对生成结果的影响是决定性的。书里也讲了同样一个道理：你给 AI 的定义越清晰，AI 返回的结果越接近你的真实需求；如果你自己都描述不清楚，AI 就只能给你一个含糊其辞的通用答案。

2.2 一次真实的“AI 写代码”演示：从需求到可运行模块

我之前在公司内部做过一次分享，用到书里一个很经典的演示思路：让 ChatGPT 从零生成一个文件批处理工具，然后完整走一遍验证和修正闭环。这次实操我换个更贴近日常的场景演示给你看，假设我们现在需要一个脚本，批量读取目录下所有 CSV 文件，按第一列分组，统计每组第二列的求和结果并输出到新文件。

我没有一开始就扔给 ChatGPT 让它“写一个处理 CSV 的脚本”，而是按三层结构组织需求：

你是一名 Python 数据工程师。当前目录下有多个 CSV 文件，每个文件第一列是分类名称，第二列是数值。 请写一个脚本，遍历指定目录下所有 .csv 文件，按第一列的值分组，对每组第二列求和，最后输出一个汇总 CSV。 要求： 1. 用 pandas 实现，兼容用户传入目录参数，默认处理当前目录。 2. 跳过表头，忽略空值和无法转换为数值的行。 3. 输出列名为：category, total。 4. 为脚本编写简单的命令行参数解析。

ChatGPT 给的结果我精简一下核心部分：

import pandas as pd from pathlib import Path import argparse def process_csv(directory: str, output: str = "result.csv"): results = {} for file in Path(directory).glob("*.csv"): df = pd.read_csv(file, header=None, skiprows=1) for _, row in df.iterrows(): try: value = float(row[1]) except (ValueError, TypeError): continue results[row[0]] = results.get(row[0], 0) + value pd.DataFrame(results.items(), columns=["category", "total"]).to_csv( output, index=False ) if __name__ == "__main__": parser.add_argument("--dir", default=".") args = parser.parse_args() process_csv(args.dir)

这段代码拿来跑基本没问题，但我复查时候发现了两个问题。第一，这里漏了parser = argparse.ArgumentParser()这一行，也就是说直接跑会报错。第二，如果某个 CSV 文件第一行并不是表头，而是直接就是数据，skiprows=1会把真实数据跳过一行，这个脚本就漏数据了。

这就是书里反复强调的一件事：AI 生成的代码一定要经过人工审查，审查的重点不是语法，而是业务语义。我后来把复活后的需求原样反馈给 ChatGPT，让它修复这两个问题，它给出的结果是对的。但这个过程说明了一个事实：AI 能帮你把 80% 的代码写出来，剩下 20% 的边界条件和业务正确性，必须由人来把关。

有一个很别扭但很真实的经验：让 AI 生成代码之后，多问一句“这段代码有没有我可能忽略的边界情况，请列出 5 个需要测试的场景”。这一句话能让 AI 主动站在测试者的角度审视自己的输出，比你自己吭哧吭哧读代码快得多。

2.3 书里强烈建议的“代码审查闭环”

读完这本书之后，我在团队里推行了一个“AI 代码审查闭环”，核心就是三步：让 AI 生成代码，再让 AI 解释代码里每段关键逻辑，最后让人做最终决策。

第二步往往被很多人跳过。其实“让 AI 解释代码”是一个特别有效的审查手段，因为如果 AI 解释它自己写的代码时开始含糊其辞，或者解释的逻辑和代码实际行为对不上，那就说明这段代码可能真的有潜在问题。

这里我举个例子，很多人喜欢让 AI 生成一个单例模式，ChatGPT 往往会给出一段基于类属性_instance的经典实现。你追问它一句“这段代码在多线程环境中有什么风险”，它会告诉你这种实现不是线程安全的，需要加锁或使用模块级单例。如果你不追问、不审查，这段代码在并发环境下就会时不时创建出多个实例，Bug 还特别难查。

书里把这个闭环总结成一个流程图式的思路：生成草稿 —— 人工审查 —— 提出修正 —— 验证结果。本质上和日常结对编程的节奏完全一致，只是同事从人换成了 AI。别把 AI 当权威，把它当成一个反应速度极快的初级工程师，你要做的事永远是复核和决策，而不是盲信和搬运。

3. GitHub Copilot 的沉浸式体验：补全之外的关键细节

3.1 让补全“更听话”的输入方式：注释驱动、函数名驱动、Tab 键

GitHub Copilot 最核心的用法是内联补全，但“补全”这个词特别容易让人误解，很多新手以为 Copilot 就是光标放在哪它就把后面的代码猜出来，实际上它的触发逻辑和使用技巧完全不是这样。

书里对 Copilot 的讲解贯穿一个概念：你要给 AI 一个“接话茬”的钩子。如果你打开一个空文件，光标停在第一行，Copilot 大概率给不出任何有价值的建议，因为它没有任何上下文。但如果你先写一行注释，描述你接下来要做什么，它就能顺着注释往下把整段逻辑补出来。这种方法叫注释驱动补全，是我平时用 Copilot 最高频的方式。

比如我想写一个解析 JSON 配置文件并按域名分组的函数，我先敲这行注释：

# 读取 content.json，提取所有包含 "url" 字段的条目，按 url 的域名分组，统计每组数量

然后按回车，Copilot 会直接给出一个完整的函数体，从import到return全都有。实测下来，注释里包含的信息越具体——比如字段名、分组依据、统计口径——补全质量越高。反过来说，如果你只写“解析 JSON 文件”，它给出的东西就非常泛，基本没法用。

第二个技巧是函数名驱动。先写好一个能表意的函数签名，比如def merge_user_data_from_csv(base_df: pd.DataFrame, new_file: str) -> pd.DataFrame:，Copilot 会根据函数名和参数名猜测函数体的实现逻辑，补全准确率非常高。这个方法特别适合你脑子里面已经清楚大概流程、只是不想手敲样板代码的场景。

还有一个细节是 Tab 键的正确用法。很多人以为 Copilot 给的建议只能整段接受，实际上它可以逐词接受，按 Ctrl/Option + → 可以一个字一个字地接受，遇到部分满意的代码可以只接受前半句，自己补后半句，这样比全盘接受再改或者全部拒绝效率高得多。

3.2 让 Copilot 理解项目结构：工程上下文的养成习惯

Copilot 本身有上下文感知能力，它能看到你当前打开的文件、相邻的文件、项目里的语言和框架信息。但这个能力有边界，它不会主动去通读你整个项目的历史包袱。所以书里讲到一个很关键的实操原则：开启一个新代码补全之前，尽量把和你当前任务相关的文件都打开。比如你要改一个文件读取逻辑，就把对应的数据格式定义文件也开着，Copilot 在给建议时会更贴近你的项目现状。

这里面我踩过一个很实际的坑。有一次我正在改一个老项目，里面用了公司的内部日志库，而我在 Copilot 没感知到项目内日志约定时让它补全一个异常处理模块，它给我生成了 Python 标准库logging的代码，看起来完全合理，但和项目整体风格完全不搭。后来我先把项目中现有的日志封装文件打开，再让 Copilot 补全，它给出的方案就变成了使用内部库的调用方式。

如果你用的是 VS Code，还可以利用.github/copilot-instructions.md文件给 Copilot 写项目级指令，例如声明代码风格、禁止使用某些库、模块注释规范等。这个文件和.editorconfig类似，本质上是在给 AI 输入项目规范，让它生成的代码从一开始就符合团队约定。

3.3 Copilot Chat 与斜杠命令：从补全到对话

书里还花了不少篇幅介绍 Copilot Chat，也就是 IDE 里直接和 AI 对话的功能。这个功能把 ChatGPT 式的问答能力和 IDE 的实时上下文结合在了一起，实用价值比单独用内联补全高不少。

我最常用的斜杠命令有三个：/explain可以选中一段代码让 AI 解释它在干什么，适合接手老项目时快速理解逻辑；/tests可以为选中函数自动生成单元测试，虽然生成的断言经常需要调整，但作为测试骨架非常好用；/fix可以直接针对当前文件里编译报错或 lint 报错让 AI 给出修复建议。

还有一个小细节值得提一下：Copilot Chat 的回答质量高度依赖你当下打开的文件和选中的代码片段。如果你问“帮我看看这个项目哪里性能有问题”，它没法回答，因为上下文太大了。但如果你选中一个具体的函数问“这个函数在大批量数据下有什么性能瓶颈”，它的回答就非常具体和有用。这是和 AI 协作的一个通用原则：问题越聚焦，答案越靠谱。

4. 自动化编程的常见失败模式与排查思路

4.1 “AI 写的代码有 Bug，怎么办”的正确姿势

我在推行 AI 辅助编程的过程中，听到最多的抱怨就是“AI 写的代码有坑，还不如我自己写”。这个判断部分正确，但问题往往不出在 AI 身上，而在于使用者的提问方式。

最常见的错误提问是直接说“这段代码有 Bug，帮我修一下”。这句话的信息量为零，AI 不知道你是否已经定位了问题，不知道你期望的行为是什么，也不知道 Bug 的复现条件。正确的做法是分两步：先让 AI 解释现状，再让它提出修复方案。

具体来说，我会把报错信息、相关代码、期望行为一起抛给它，然后用这个句式：

以下代码在执行 [场景描述，比如“处理超过 10000 行的 CSV 时”] 出现 [具体问题，比如“内存占用飙升”]。 请先分析可能的原因，按概率从高到低列出，然后对每个原因给出对应的验证方法和修复方案。

这样 AI 会先给出一个分析框架，而不是上来就改代码。逻辑上，如果你能通过 AI 的分析先定位到根因，再让它针对根因做修复，成功率高得多。书里对这类场景的处理思路，本质上就是把调试流程从“瞎猜”变成“假设验证”。

4.2 “AI 幻觉”与过时依赖：宁可信文档，不可信记忆

AI 生成代码时存在几个非常典型的失败模式，书里举了很多例子，我自己也都遇到过。

第一个是虚构 API。AI 有时会生成一些看起来像模像样但根本不存在的库函数。比如它可能给你写出pandas.read_excel(engine="openpyxl", sheet=None)这种半对半错的调用，因为sheet并不是合法参数。遇到这种问题，不要和 AI 反复纠缠让它“再想想”，直接去查官方文档，以文档为准。AI 的训练数据有时效性，它对某个库的 API 变化的感知是滞后的。

第二个是一本正经的错误设计。有时候 AI 会按照错误的前提去设计一个功能，比如你让它做一个缓存模块，它默认并发安全，但你的场景其实不需要；或者反过来，它给出了一个完全不考虑并发的方案，但你的服务是高并发的。这类问题靠提示词约束可以解决一部分，但真正的防线还是你本人的技术判断力。

第三个是版本依赖陷阱。AI 很可能给你的代码里使用了较新的语法，但你项目里实际跑的是老版本运行时。这个问题的排查思路很简单：生成代码后，把关键依赖版本通过人工确认一遍，确保代码用到的语法特性在你的环境里真的支持。

4.3 生产效率陷阱：AI 代码的维护成本

最后想聊聊一个比较“反直觉”的问题：用 AI 写代码，短期效率很高，但长期维护成本可能比手写还高。

我见过不少团队在 AI 辅助编程上的做法就是“能甩给 AI 就甩给 AI”，结果半年之后，代码库里堆了很多风格完全不一致、注释缺失、没有单元测试的“AI 生成代码”，出问题时根本没人愿意去碰。

书里对这个问题给出的解法非常务实：AI 生成的代码必须第一时间补上两样东西——单元测试和架构边界说明。让 AI 顺手生成测试是成本极低的事情，但如果你跳过这一步，后续维护时这些代码就是一个黑箱。另外一个更关键的原则是：AI 生成代码的归属权是人的，AI 只是工具，“这段代码为什么这么写、为什么选这个方案”的责任必须由人来承担。

我个人的习惯是，AI 生成的每一段核心逻辑，都会在代码评审时单独过一遍，同时要求 AI 补一份简短的“设计说明”，写清楚它考虑了哪些边界条件、为什么选择某种实现。这份说明不需要很正式，但能帮三个月后的自己快速恢复上下文。

我把这段时间实操过程中最容易踩的坑和排查思路整理成一张速查表，你可以直接保存下来：

最后再分享一个我自己的经验：读完这本书之后，我把 AI 编程工具的使用重心从“让 AI 帮我写完代码”调整成了“让 AI 帮我减少上下文切换”。以前写代码需要在编辑器、文档、搜索引擎、调试器之间来回跳，现在这些环节里相当一部分被 AI 接住了，我可以更长时间保持在一个连续的思维流里。这个变化带来的效率提升，比 AI 替我写的那几行代码本身大得多。