拿到李宁老师的《AIGC 自动化编程——基于 ChatGPT 和 GitHub Copilot》那天我刚被一段 AI 生成的代码坑完看起来逻辑完整、注释齐全一运行直接把我维护了两天的状态数据清掉了。所以翻开这本书时我多少带点较真的心态——AIGC 自动化编程到底靠不靠谱怎么才能让 AI 写的代码真正扛得住生产环境整本读完之后我的感受从“怀疑”变成了“方向没问题但落地方法天差地别”。李宁老师在书里没有把 ChatGPT 和 GitHub Copilot 当成“会写代码的魔法师”而是当成两个需要分工、需要约束、需要验证的协作者。这本书适合两类人一类是有过几年开发经验、正在尝试用 AI 提效但总差口气的工程师另一类是刚入门编程、想知道怎么借助 AI 建立规范学习路径的新手。它不是工具说明书而是一套关于“人和 AI 怎么协作干活”的方法论所以这篇笔记我也不打算写书摘而是把书中对我最有用的思路结合我自己的实操经验拆开揉碎讲一遍。1. 先把“自动化编程”这件事说透AI 到底替你干哪部分活1.1 自动化编程不是“一键生成”而是人机流水线提到“自动化编程”很多人第一反应是我把需求扔给 AI它把代码吐出来我直接上线。李宁老师在书里花了不少篇幅纠正这个误解。自动化编程的本质是一套流水线人负责拆解目标、定义验收标准、做关键决策AI 负责把意图翻译成代码、处理重复劳动、生成测试和文档。这就像一个装修工程——AI 是施工队但图纸、主材、验收标准必须由业主你定。如果你连某个功能到底要解决什么问题都没想清楚AI 生成的代码越“流畅”埋的雷越多。书里反复强调“人机协作流水线”这个概念核心是五个环节需求澄清、方案设计、代码生成、测试验证、重构交付。传统开发里这五个环节全靠人肉推进AIGC 时代前三个环节可以大幅加速后两个环节也有人在侧。但关键变化是“验证”这个动作的频率必须提高。以前你可能写完整个模块才跑一次测试现在 AI 每生成十行二十行代码你就该立刻验证一次。原因是生成式模型基于概率输出它不保证对只有测试能兜底。我在实际项目中试过两种用法对比很明显。一种是把整个功能描述塞进去让 AI“一口气写完 service、repository、controller”结果代码结构漂亮但业务逻辑错了两处我花了半小时在几百行代码里找错。另一种是每次只让 AI 生成一个函数、一个接口生成完立刻跑测试十分钟搞定。这本书给我最大的一个启发就是自动化编程的自动化程度跟你任务拆分颗粒度成正比。1.2 读这本书前先建立这几个底层概念书中第一章提到“插件化开发”“插件化编程环境”等概念但我认为最核心的其实是四个基础概念理解了它们后面所有章节都顺了第一个是上下文窗口。ChatGPT 和 GitHub Copilot 能“记住”的信息量是有限的超过上限模型就“失忆”。很多人发现 AI 生成到一半跑题、忘记你最初的约束多半是上下文太长或关键约束被淹没。实操上要注意提示词里最重要的约束放在开头项目相关的背景信息尽量精简。第二个是提示词Prompt。很多人把提示词理解为“问问题”书里把它当成一种“需求规格说明书”的写法背景、目标、约束、输入、输出、验收条件缺一不可。提示词不是玄学本质是压缩需求信息让模型更容易生成你要的结果。第三个是补全模型和对话模型的差异。GitHub Copilot 偏向补全模型适合在你写代码的过程中“接着写”十几行ChatGPT 是对话模型适合你反复追问、讨论、修改。两者不是替代关系而是配合关系。书里的做法是Copilot 负责快ChatGPT 负责深。第四个是模型幻觉。这是所有 AI 编程工具都绕不开的问题。模型会一本正经地引用一个不存在的函数、不存在的库版本甚至伪造运行结果。李宁老师在书中多次提醒AI 生成的代码默认不可信必须靠编译、测试、人工走查三重验证。理解了这四个概念后面章节里的提示词模板、工作流设计就都有了解释。2. ChatGPT 辅助编码的实战方法论从提示词到代码评审2.1 把需求写成“六要素提示词”而不是闲聊书里给了很多提示词示例我把它归纳成“六要素模板”这也是我目前最常用的写法。六个要素分别是背景、目标、约束、输入、输出、验证方式。举一个实战例子我需要写一个 Python 函数校验一批订单号是否符合规则背景我在维护一个订单系统订单号由日期流水号组成例如 20240101-000123。 目标写一个函数校验输入字符串是否为合法订单号。 约束只使用标准库日期部分必须真实存在流水号必须是6位数字。 输入一个字符串。 输出返回布尔值非法时给出具体原因。 验证方式提供5个测试用例覆盖合法、非法日期、流水号位数不足、空字符串、带空格五种情况。你会发现提示词写得越具体AI 生成结果的可用率越高。原因在于模型的生成空间非常大约束越明确它越不需要“猜”你的意图。很多初学者抱怨“ChatGPT 生成的代码不是我要的”大概率是背景和目标没写清楚。还有个细节把“验证方式”放进提示词非常关键。让模型先给出测试用例其实是在生成代码之前先对齐“什么是正确”。我见过太多人拿到代码后自己写测试才发现理解偏差返工成本极高。先让 AI 生成测试用例等于在动手前先签了一份“验收合同”。2.2 大任务拆小一次只让 AI 做一件事李宁老师在书中多次强调“任务分解”。这不是泛泛的效率建议而是有实际技术原因的。对话模型在长对话中会逐渐偏离初始目标你让 AI 从零生成一个完整系统时它会调用大量“想象中的代码”——那些看起来合理但从未跑过的函数。反之当任务足够小时模型生成的内容更容易被验证即使错了定位成本也低。我的操作习惯是把一个模块拆成“数据层 → 业务层 → 接口层”三个步骤每一步再拆成单个函数。比如开发一个文件上传功能我先让 ChatGPT 设计存储目录结构再让它生成文件名生成函数再生成上传处理逻辑。每个函数生成完我立刻写一行调用代码跑一下错了就当场调整。这样做的额外好处是AI 的“手感”越来越好。它看到你返回的错误信息后会基于上下文修正自己的输出有点像结对编程里的“即时反馈”。错误的示范是把“帮我写一个完整的用户注册接口包括邮箱验证、密码加密、限流、日志”一次丢给模型。它确实能生成很长的代码但你根本没法逐行审查测试失败也分不清是哪里出的问题。你没有被 AI“取代”你被 AI 带进了调试泥潭。2.3 让 AI 先写测试再写实现这一节是我全书中收获最大的部分之一。李宁老师的思路是测试先行这件事在 AI 编程时代变得更重要了。传统 TDD测试驱动开发在国内团队里推起来阻力很大因为写测试太花时间。但如今你完全可以先让 ChatGPT 生成测试用例再让它生成实现——成本极低。举个例子我自己写过一个时间区间解析功能需求是“把 2024Q3 转成该季度的起止日期”。我先让 ChatGPT 给出 6 个测试用例包括正常季度、跨年季度、非法输入、闰年 2 月、字符串前后带空格、大小写混合。AI 写出这些用例之后我才让它写实现代码。结果它第一次生成的实现代码里有 2 个用例跑不过我把失败信息反馈给它它马上意识到是“季度结束日期计算方式”理解错了修正后一次通过。这个流程告诉我一个道理测试用例是 AI 和开发者之间最重要的沟通语言。你不需要费劲解释“这个函数应该怎么算”因为测试用例本身就在定义行为。而 AI 生成测试用例的能力目前已经非常成熟——它吃过的优秀测试代码样本比我们这辈子见过的都多。2.4 用“代码评审模式”抓住幻觉和逻辑漏洞书里专门有一节讲如何让 ChatGPT 当代码评审员这招我非常推荐。常见的用法有三种一是让 AI 解释它自己刚生成的代码二是让 AI 审查你自己写的代码找 bug 和安全隐患三是把两段不同方案丢给它让它做对比分析。我自己最常用的 prompt 是请审查下面这段代码从这几个角度给出意见 有没有潜在的边界条件 bug 是否存在内存或资源泄漏风险 异常处理是否合理 可读性是否可以改进 有没有更简洁的写法。 不要直接改代码先列问题清单。这一步可以筛掉大量低级错误。比如 AI 生成的代码里漏判了空指针、循环里忘了处理最后一个元素、正则表达式存在“灾难性回溯”风险这些问题让模型“自审”往往一抓一个准。但注意AI 的评审意见也可能出错真正的判定标准永远是测试跑出来的结果。我会让 AI 列问题清单然后逐条核实而不是直接接受它的修改版本。书里还有个观点很戳我不要只在出错的时候求助 AI代码刚刚写完的“新鲜期”才是评审的最佳窗口。等你在现场环境里被线上 bug 打脸之后再回头审查代价完全不同。3. GitHub Copilot 实操要点把补全工具用到刀刃上3.1 Copilot 和普通补全的本质区别很多人把 GitHub Copilot 当成 IDE 自带的智能补全的高级版这是一个很常见的误解。普通补全是在你已经输入的字符基础上猜测下一个单词或短句Copilot 则是基于当前文件的完整上下文——函数名、注释、前后的调用关系、语言语法、项目里的其他文件——直接生成一整段逻辑。我试过一次很典型的场景写 Java 的分页查询接口时刚敲完方法签名和一句注释“按创建时间倒序分页查询用户列表”Copilot 就补出了完整的 Mapper 层调用、排序条件、分页参数校验。这已经不属于“补全”而是“小规模生成”。书里管这种状态叫“结对编程”Copilot 是坐在副驾帮你查地图的导航员但方向盘还在你手里。理解了这一点你就会明白为什么 Copilot 有时候会“越权”生成一堆你不想要的东西。它看到你定义了一个getUser()可能会自作主张补出setUser()、updateUser()、deleteUser()。这不是 bug而是模型在“顺着惯性写”。你把 Copilot 当“自动完成”用它就会给你带来惊喜你把它当“自动写代码”用它就会给你带来惊吓。3.2 注释驱动让意图成为第一优先级李宁老师书里提到“在写代码前先写详细注释”这一点在 Copilot 的使用中体现得淋漓尽致。Copilot 对注释的敏感度极高你注释里写了什么意图它生成的代码就围绕那个意图展开。我把这个技巧称为**“注释优先”或“注释驱动”**。实操套路是三步。第一步先写函数签名把函数名、参数类型、返回值类型定下来第二步在函数上方写一段自然语言注释交代清楚这个函数要做什么、边界条件是什么、有哪些注意点第三步回车让 Copilot“接着写”。举一个我实际写过的例子注释是这样写的/** * 计算两个日期之间的工作日天数。 * 排除周末和法定节假日节假日字典从外部传入。 * 若 startDate 晚于 endDate直接返回 0。 */注释刚写完Copilot 补出来的代码几乎就是我心中所想的样子循环遍历日期、判断星期、查字典、处理非法输入。并不是说它每次都完美但注释明确后生成的代码可接受率从“一半靠运气”涨到了“八成直接能跑”。这个技巧背后的原理是注释给模型提供了意图约束。模型在预测代码时会优先匹配注释中的语义信息。很多初学者抱怨 Copilot 总往下接“无关代码”其实是你自己的注释写得像“xx功能”这样含糊模型只能猜测。把注释写成需求说明它立刻变乖。3.3 Copilot Chat 在处理既有代码时的威力如果你只用过 Tab 补全就错过了 Copilot 一半的能力。Copilot Chat现在已深度集成在 VS Code、Visual Studio 2026 里可以基于整个 IDE 工作区的上下文回答问题。我有一次接手一个遗留项目里面有一个三百多行的老函数逻辑绕来绕去。我直接在 Chat 面板里告诉它选中的这个函数帮我梳理它的执行流程标出递归调用和状态修改的位置 然后给我一个等价的重构版本行为不能变但把复杂度拆解掉。它很快给出了流程说明和一份候选重构代码。我把重构代码放到分支里跑完所有既有测试才合并。这个流程大大降低了我接触陌生代码的心理门槛。但这里有一个非常关键的操作习惯给 Chat 提问前一定先用鼠标选中代码。你选中哪段它默认就以哪段为上下文。不选代码直接问“这个项目怎么启动”它给的答案很可能来自通用知识而不是你项目的真实细节准确率会打折扣。书里也花了篇幅讲“如何在 IDE 中高效使用对话助手”核心观点就是能选中的别手打选中之后再加上具体问题比聊天式提问高效得多。3.4 快捷键和配置建议从“干扰”到“顺手”Copilot 用起来烦不烦很大程度取决于配置和快捷键。默认设置下Copilot 在你输入的时候频繁弹出建议有时候甚至会打断思路。我的建议是第一记住几个关键快捷键。Tab 是接受当前建议Esc 是忽略建议在 VS Code 里按住方向键或 Ctrl 回车可以查看更多备选方案。不要用鼠标去点“接受”Keyboard-first 才能保持写作节奏。第二合理配置触发方式。Copilot 在 VS Code 里支持“自动建议”和“手动触发”两种模式。自动建议适合写样板代码重复性 CRUD、单元测试骨架手动触发更适合写核心业务逻辑因为它不会频繁打扰你的思考。我一开始图新鲜开了自动建议结果写算法时老被打断后来改成手动触发舒服多了。第三Copilot 的“可接受率”是可以训练的。每当你忽略它的建议模型会捕捉这个反馈你多写几种风格、多写注释它后续的建议会逐渐贴合你的语言习惯。所以刚开始不要因为建议差就关掉它给它一点“调教”时间。Copilot和ChatGPT的定位有个很形象的区别Copilot 是“扶着你的手写字”的助手ChatGPT 是“坐在对面和你讨论方案”的顾问。书里大部分实战章节也是建立在这个分工上。4. 用 ChatGPT 加 Copilot 搭一套完整的自动化编程工作流4.1 需求设计阶段AI 是方案起草员自动化编程不是从敲代码那一刻才开始。李宁老师在书中把流程起点放在“需求分析”这一点我很认同。拿到一个需求之后我现在的习惯是先把需求“说”给 ChatGPT让它产出一份技术方案初稿内容包含模块划分、核心接口、数据结构、风险点、测试策略。它会给出一些我没想到的角度比如并发安全、缓存失效的边界条件。这里有个注意点方案可以让 AI 出拍板必须你自己来。AI 给出的方案不一定最优它经常倾向于“看起来全面”而不是“真的契合你的业务场景”。我会把 ChatGPT 生成的方案当成一张思维导图圈出它提到但在我们的系统里不适用的部分再让它基于我的反馈重新生成。这样得到的方案比我自己从零写快很多也比直接接受 AI 版本靠谱很多。我实际做过一个数据导入模块的设计需求是“从 Excel 导入客户名单并做重复校验”。ChatGPT 给出的初稿用了pandas 内存去重 逐行校验我补充了一个约束“数据量可能达到百万行”它立刻改成了分块读取 哈希去重 分批入库的方案。这种“方案迭代式对话”特别适合设计阶段安全性、性能、扩展性全都可以在写代码前聊清楚。4.2 编码实现阶段小步生成持续验证编码阶段是我使用 AI 最密集的地方但也是踩坑最多的地方。书里强调“大任务分解小小任务直接生成”我的落地节奏是这样的第一步按设计拆任务。一个模块拆成若干函数或接口每个任务尽量控制在半小时内完成。第二步为每个任务写函数签名和注释然后让 Copilot 生成代码或把签名与注释复制给 ChatGPT 让它补充实现。第三步生成完立刻编译 跑测试绝不攒着一起跑。第四步通过后再进行下一段。有一个反直觉的经验AI 生成几百行代码比生成十几行代码更容易“翻车”。长代码里的依赖关系、变量名一致性、状态流转都容易出错而且错误被大段代码淹没后极难定位。小步生成时错误最多一两处反馈修复的成本低到你不会心疼。我还会在整个编码工程里频繁使用git commit。每次一个函数跑通就提交一次。这样 AI 偶尔“把代码改烂”时我可以随时回滚到上一个可用状态而不是在坏代码上反复跟它纠缠。你可以把每一次小步提交理解为“给 AI 画一条安全边界”。4.3 测试与排错阶段让 AI 当第二双眼睛测试与排错是 AI 自动化编程里性价比极高的环节。传统的排错是你盯日志、查文档、猜原因现在你可以把报错信息直接甩给 ChatGPT同时附上相关代码它会给你列出可能的原因和排查顺序。我常用的 prompt 是下面这段代码跑出了一个异常请根据调用栈帮我定位问题 1. 指出最可能出错的位置 2. 列出可能导致该异常的 3 个原因按概率排序 3. 给出每个原因的验证方式 4. 不要直接给修改后的代码先让我按步骤排查。这个 prompt 的精妙之处在于第 4 条不让它直接改代码而是先排查。因为直接给修改代码容易让你跳过验证过程误以为“改了就等于对了”。我自己试过很多次AI 给出的原因排序往往极其贴近真实尤其是空指针、类型转换、资源未关闭之类的常见问题一抓一个准。测试数据也可以用 AI 生成。我让 ChatGPT 先根据表结构生成造数 SQL再让它写单测再用 Copilot Chat 在 IDE 里生成测试骨架。三者合一之后测试覆盖率从“看心情”变成“像样”。当然人工确定测试边界仍然不可省毕竟业务语义只有人最清楚。4.4 收尾阶段提交信息、README 与代码走查很多人忽略了收尾阶段的 AI 提效空间。李宁老师的书里也提到“AI 能帮你写注释、写文档”我实操下来最能感受到效率提升的其实是三件事。第一件是生成 Git 提交信息。把改动文件列表和git diff摘要交给 ChatGPT它会给出一个简洁、格式统一的提交信息省得每次写完代码还要绞尽脑汁总结。第二件是生成 README。项目跑通了但 README 永远是空白这是大多数项目的真实写照。我把项目结构、启动命令和核心模块说明丢给 ChatGPT它会生成一份结构完整、可读性不错的 README 初稿。这事的价值在于你本来可能一拖再拖现在有了初稿润色十分钟就能发出去。第三件是代码走查。合并分支前我会把新增代码整体过一遍选中一段让 Copilot Chat 做“变更审查”让它标记出可疑逻辑和代码风格问题。这个过程不是替代人工 Review而是先由机器筛一遍让同学/同事的 Review 能聚焦在真正的业务问题上。团队协作时这个习惯能显著提高 Code Review 效率。5. 自动化编程常见问题与排查技巧实录5.1 AI 生成代码编译不过这是最普遍的翻车现场。遇到时别慌更别急着让 AI 重新“写一遍”。正确的排查顺序是先看编译器报错的第一行定位到具体文件和行号然后只把“报错那一行 函数签名”发给 ChatGPT它会精准修复最后验证通过后继续下一步。把整个文件丢进去让它重写是下策因为它可能把已经能跑的部分也改坏。我踩过的坑是一次让 ChatGPT 修一个语法错误结果它顺便重构了另一个函数引入了新的问题。从此以后AI 的修改范围尽量用“提问”锁死比如“只修改第 23 行的参数类型不要改其他逻辑”。5.2 生成代码看着对跑起来错这类问题多半是边界条件没覆盖。比如处理空列表、除零、时区转换、浮点数比较AI 在这些地方最容易产生幻觉。解决办法是强制它“先生成测试用例”。你可以在提示词里加一句在写实现之前先写出覆盖以下边界条件的测试用例空输入、单元素输入、极限值、非法格式。等测试用例通过了你的理解校验再让它写实现。这样即使实现有问题测试能立刻给出反馈比你在数据堆里翻日志高效得多。5.3 Copilot 频繁给出无关建议如果你发现 Copilot 老是打断你的思路、补出的东西完全不想用先不要卸载它。试试三个调整一是把触发方式从自动改为手动二是检查当前文件是否有大量含糊的注释这类注释容易误导模型三是多写规范代码少写“脏乱差”代码——模型学的是你所在文件的风格文件写得乱它补得也乱。另外要注意Copilot 给出的建议不一定是你原计划的实现方式。它有可能会把简单几步重构成一个“看起来更聪明”的方案比如引入隐式状态、过度封装。这种情况直接 Esc 即可不要被它的“炫技”带走。5.4 引用了不存在的库或已废弃的 API模型训练数据有时间截止点它会一本正经地写xxx.framework里从没出现过的 API。遇到这种问题我一般会在提示词里加“只准使用 xxx 版本中存在的 API不确定的 API 标注出来”之类的约束。生成之后用搜索核对版本号和函数签名。不要信任模型记忆中的“最新版本”尤其是做依赖升级时人工查证还是不可省的。5.5 越改越乱AI 陷入重复错误循环有时候你在一个问题上跟 ChatGPT 来回拉锯好几轮它的方案越改越丑甚至出现“修复了 A 又破坏了 B”的循环。这时候最有效的动作是跳出当前对话或者还原代码版本。你可以在新对话里这样问我有一个函数需要实现某功能下面是当前失败代码和报错信息。 请不要基于之前任何错误的修复思路重新给我一个干净的方案。新对话意味着上下文被重置模型不太容易“继承”之前钻进的牛角尖。配合 git 回滚这已经是我处理 AI 编程问题的刹车装置了。常见问题快速定位思路避坑要点编译不过看第一行报错定位到具体行只让 AI 修局部禁止顺手重构运行结果错误让 AI 先出测试用例别盲改先对齐“正确”的定义Copilot 建议干扰改手动触发、检查注释质量及时 Esc保持主导权用了不存在的 API核对官方文档版本号提示词里写版本和“未知要标注”修改陷入循环新开对话、git 回滚不在一条错路上无限拉锯6. 读完这本书后我实际发生的几个变化6.1 从“让 AI 写代码”变成“让 AI 帮我验证想法”读这本书之前我使用 AI 的方式非常直接有需求 → 发给它 → 拿代码 → 跑。遇到 Bug 再发给它 → 修代码 → 再跑。循环往复效率时高时低。书里“自动化编程”强调先拆任务、再定验收、最后生成这让我彻底调整了使用习惯。现在我会先写设计草稿、先列测试用例、先定函数签名AI 只是把这些决策快速“翻译”成代码。这个转变看起来只是流程顺序变了实际效果却差了一个量级AI 生成代码的可接受率大幅上升返工时间大幅下降。6.2 我开始认真写注释和函数签名了很反直觉的一点是AI 编程时代最该坚持的好习惯反而是写文档、写注释、规范函数签名。因为注释不只是给人看的也是给 AI 看的。你在注释里写清楚“这个函数排除周末”Copilot 就真的会写排除周末的逻辑——它没有读心术但它读注释。现在我的习惯是函数写之前先写一个“给人类也给你 AI 看”的意图注释。这件事坚持下来之后我的代码可读性变好了AI 补全的质量也变好了。6.3 开发节奏从“憋大招”变成“小步快跑”以前我写模块喜欢一口气写完再联调出了问题排查巨慢。现在受书中“自动化流水线”思路影响我把开发节奏固定成“拆小任务 → 生成 → 验证 → 提交 → 下一个”。AI 把重复劳动吃掉了留出来的时间我全部用来思考和验证。那种“让 AI 写代码结果我自己变成测试机器”的荒诞感总算是消失了。最后分享一个小技巧也是我认为这本书最实用的“遗产”当你想让 AI 帮你解决一个复杂的编程问题时不要直接说“给我代码”改成“先告诉我你的分析思路我想确认方向对不对”。就这一句话的差别能帮你省下大量被“看似正确但方向错误”的代码浪费掉的时间。这也是我对 AIGC 自动化编程最深的理解效率不来自工具本身而来自你控制工具的水平。