最近把李宁老师的《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, headerNone, skiprows1) 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, indexFalse ) if __name__ __main__: parser.add_argument(--dir, default.) args parser.parse_args() process_csv(args.dir)这段代码拿来跑基本没问题但我复查时候发现了两个问题。第一这里漏了parser argparse.ArgumentParser()这一行也就是说直接跑会报错。第二如果某个 CSV 文件第一行并不是表头而是直接就是数据skiprows1会把真实数据跳过一行这个脚本就漏数据了。这就是书里反复强调的一件事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(engineopenpyxl, sheetNone)这种半对半错的调用因为sheet并不是合法参数。遇到这种问题不要和 AI 反复纠缠让它“再想想”直接去查官方文档以文档为准。AI 的训练数据有时效性它对某个库的 API 变化的感知是滞后的。第二个是一本正经的错误设计。有时候 AI 会按照错误的前提去设计一个功能比如你让它做一个缓存模块它默认并发安全但你的场景其实不需要或者反过来它给出了一个完全不考虑并发的方案但你的服务是高并发的。这类问题靠提示词约束可以解决一部分但真正的防线还是你本人的技术判断力。第三个是版本依赖陷阱。AI 很可能给你的代码里使用了较新的语法但你项目里实际跑的是老版本运行时。这个问题的排查思路很简单生成代码后把关键依赖版本通过人工确认一遍确保代码用到的语法特性在你的环境里真的支持。4.3 生产效率陷阱AI 代码的维护成本最后想聊聊一个比较“反直觉”的问题用 AI 写代码短期效率很高但长期维护成本可能比手写还高。我见过不少团队在 AI 辅助编程上的做法就是“能甩给 AI 就甩给 AI”结果半年之后代码库里堆了很多风格完全不一致、注释缺失、没有单元测试的“AI 生成代码”出问题时根本没人愿意去碰。书里对这个问题给出的解法非常务实AI 生成的代码必须第一时间补上两样东西——单元测试和架构边界说明。让 AI 顺手生成测试是成本极低的事情但如果你跳过这一步后续维护时这些代码就是一个黑箱。另外一个更关键的原则是AI 生成代码的归属权是人的AI 只是工具“这段代码为什么这么写、为什么选这个方案”的责任必须由人来承担。我个人的习惯是AI 生成的每一段核心逻辑都会在代码评审时单独过一遍同时要求 AI 补一份简短的“设计说明”写清楚它考虑了哪些边界条件、为什么选择某种实现。这份说明不需要很正式但能帮三个月后的自己快速恢复上下文。我把这段时间实操过程中最容易踩的坑和排查思路整理成一张速查表你可以直接保存下来问题现象常见原因解决办法Copilot 长时间不给建议上下文缺失或当前文件语法错误写注释或函数签名触发补全检查文件是否处于语法错误状态AI 生成了不存在的 API模型训练数据陈旧或幻觉以官方文档为准手工修正代码不要继续追问AI 生成的代码风格与项目不一致没有给 AI 提供项目上下文打开相关文件、配置项目级指令文件再生成AI 生成的代码跑通但结果错误业务语义理解有偏差让 AI 先解释关键逻辑人工逐行核对业务分支大量 AI 代码进入项目后难以维护缺少测试和设计说明要求 AI 同步生成单元测试和简要设计说明最后再分享一个我自己的经验读完这本书之后我把 AI 编程工具的使用重心从“让 AI 帮我写完代码”调整成了“让 AI 帮我减少上下文切换”。以前写代码需要在编辑器、文档、搜索引擎、调试器之间来回跳现在这些环节里相当一部分被 AI 接住了我可以更长时间保持在一个连续的思维流里。这个变化带来的效率提升比 AI 替我写的那几行代码本身大得多。