对**"李宁"**这个名字，最有印象的，除了体操王子，就是一位计算机图书领域的作者了。前几年就买过一本他写的 python（《Python从菜鸟到高手》）的书，感觉深入浅出，理解深刻，行文易懂。所以对作者怀有敬意和好感。
这几天翻阅他的这本 2023/10月 出版的《AIGC 自动化编程 -- 基于 ChatGPT和 GitHub Copilot》这本书，虽然时光荏苒，技术进步飞速，书中有些内容已经过时，但是看到其中核心思想 -- 解决复杂问题，通用的做法就是先分解后合并，还是颇有裨益，于我心戚戚耶。遗憾没有早几年接触到这本书。
从2024 年初的 ChatGPT 大火，然后 2025年初DeepSeek 的横空出世（对普罗大众而言)，到 2025 年底，Google Genimi 3的发布，LLM 越来越进入人们的日常工具范畴。大模型本身已经足够强大。ChatGPT, DeepSeek, Dobao，Genemi, Claude，QWen 等等都已越来越强大，越来越靠谱。使用好它们，发掘其能力日益成了行业发展的方向。在编程领域的 GitHub Copilot， Cursor，Claude Desktop, CodeGeex 等；在工作流Agent 的 FastGPT (企业级 知识库 RAG)，Dify等；遵循 模型上下文协议MCP （LLM 的外部工具调用协议 ）的种种工具等（可使用VSCode 的插件 Cline 来开发）；A2A Agent间的交互协议；以及最新的 Skill 等，都是为了基于 LLM 能力，实现具体功能/解决具体问题，安全地赋能给私有数据（企业 RAG），而且尽量消除 LLM 的 本身概率性输出带来的不确定性，从而漂亮地落地实施。
在编程领域，把 复杂需求分解（breakdown）然后合并，是传统的做法。借力大模型，更靠谱的路径(approach）也是如此。当前我体会的经验如下（以比较复杂的项目为例）：
1， 手写需求梗概
2，LLM 扩展成详细需求 （多轮对话，反复打磨），最好是对 feature 的分步走式开发：MVP 原型 -> feature delta 1 -> feature delta 2 -> ... -> full feature ready
3，手写设计框架，模块分割，技术架构
4，LLM review 细化 （多轮对话，反复打磨）
5，LLM 生成 代码文件结构，框架代码
6，VSCode 中创建项目，copy LLM code，生成 MVP 原型代码，手动试验
7，VSCode 中 GitHub Copilot 分步实现详细需求中的功能, 渐进式地开发。
-----------------------------分割线，下面为原书摘抄-----------------------------
驾驭 AI 之感悟
到现在为止，我们已经实现负责浏览图像和搜索图像的web 服务，我们没有编写一行代码，这些代码都是ChatGPT和 GitHub Copilot 编写的。通过这两个 AI 工具，完成这些工作只需要几分钟，只要描述准确、严谨，生成的代码几乎是100%准确的。即使生成的代码有一些问题，一般也不用调试，再让 ChatGPT或 Gitffub Copilot重新生成就可以了。孔子说过，"三人行，必有我师焉"。对于AI来说，生成三遍，必有我满意的代码。如果用同一个描述，连续生成三遍，还不能满足自己的需求，或者与自己的需求有很大的差异，那么可能是以下原因。
- AI模型本身不够强大。这种可能性并不大，因为 ChatGPT 是目前最强大的AI模型，尤其是 ChatGPT Plus，它基于 GPT-4，如果GPT-4 不行，那么目前就没有AI模型可以胜任了。
- 描述不够准确 。这种情况下就看你的文学功底了，检查描述是否严谨、是否全面，是否有语病或歧义。
- **描述不合理。**出现这种情况有多种原因。例如，你的要求超出了AI 的能力范围，或者你的要求根本不可能用你指定的技术实现，在这种情况下，ChatGPT 可能就会发挥自己一本正经地胡说八道的本事了，生成的一些代码很可能包含很多不存在的函数、方法、类。因 根本就没有相关的 API 可以实现你要求的功能，所以 ChatGPT 就会根据概率统计，返回根本不存在的函数或方法调用。也就是说。PPeGPT非不知消回的是否正确，只根据概率，挑概率最大的内容返回，哪怕这些内容是错误的。就我对于同一个问题，每次计算得到的概率都是不同的，因此 ChalGiPT 每次的回复也不完全一样。
- 描述过于复杂。其实这个问题是最普遍的 。尽管 ChatGiT、New Bing、 GitHub Copilot这些AI 工具可以接收数百甚至数千字待作为输入，但对于过于复杂的问题，尤其是本来就复杂的编程问题，AI模型也和人类一样，可能会忽略一些细节。于是，就会造成生成的代码只有部分符合自己要求的情況，好像其他的要求自己从來没提过一样。 **但是决这个问题的方法也很简单，就是分治法。将大问题分拆，变成中等的问题。如果中等问题仍然很复杂，再继续将问题分拆，变成小问题。如果小问题仍然很复杂，再继续分拆，变成微问题，直到每一个问题都变得一目了然为止。当每一个小问题被解决后，就会逐渐将小问题合并，组合成大问题。**最终，所有被分拆的问题被组合成最初的超级复杂的问题。
对于让 ChatGPT这样的AI工具为自己编写代码这个工作，也是如此。有人说，ChatGPT的编程能力可以达到中级程序员的程度，其实这样评价ChatGPT 太过肤浅 。 ChatGPT 的能力能达到什么程度很大程度上取决于它的使用者。就像对于同一把价值数百万美元的小提琴，由一个世界顶级的小提琴演奏家演奏的效果和一个小提琴培训班刚毕业的学生演奏的效果肯定是不同的。对于同一把小提琴，不同人演奏，会出现完全不同的效果，云泥之别。
ChatGPT也一样，ChatGPT 到底能解决多复杂的问题很大程度上并不在于ChatGPT本身，而在于使用者如何处理复杂的问题，如何化繁为简。因此，是否能驾驭 ChatGPT 并不完全是很多人所说的撰写提示词的问题。如果问题相当复杂，就算提示词写得完美无缺，ChatGPT可能也无法完美解决问题。要将复杂问题分解，再分解，直到 ChatGPT 可以完美解决为止 。 当然关键点还不是分解，而是ChaIGPT 解决定每一个小问题后，如果将这些小问题合并成最码的大间题。所以关键中的关键是设让一套接口，将小题作为黑盒。不管小问题解决得怎么桂，都不会从根本上影响全局，某一个小问题解决不好，单独处理即可 。就像在4.4 节用ChatGPT 实现的复杂布局一样，将每一部分的布局单独作为一个从 QFrame 派生的类，并放到单独的 Python 文件中。而不是将代码直接插入主程序，就算某一个布局类不能满足自己的要求，重新生成这个类即可，这个类完全不影响其他布局类和主程序。所以影响ChaGPT 的使用效果的关键点有如下几个：
- 提示词：这是最基础的，就像唱歌不跑调是最基本的要求一样，如果提示词不合适，一直没说清楚，ChatGPT 自然也不会为你生成想要的内容了。
- 复杂问题的分拆技巧：这是让ChdGPT升华的关键，也决定着 ChaIGPT处理复杂问题的天花板。关于技巧性的东西，需要自己领悟，本书会通过大量的案例让读者更深地体会如何分拆各种类型的技术问题。
- 设计接口；分拆容易，但 ChatGPT 为你解决了每一个小问题之后，需要将这些小问题再组合成最初的复杂问题，而组合的关键就是接口。
- 组合问题：这是最后一步，也是最关键的一步，如果做不好，前面的分拆毫无意义。组合就是利用接口逐渐将不同级别的小问题逐级合并较大的问题，直到恢复到最初的复杂问题为止。而本书的目的之一就是让读者了解各种复杂问题如何分拆，以及如何合并。
总之，你有多强，ChatGPT 就有多强！
小结：
本章以桌面应用为例，深入讲解了如何将一个复杂的程序分解成多个小部分，然后分别ChaGPT 和 Gitlub Copilot生成不同部分的代码，最后再将这些代码合并成一个大系统。其实 应用 ChatGPT或 Gitlub Copilot的关键点只有一个，就是化繁为简。另外，**ChatGPT与 Gitlub Copil虽然都能生成代码，但是二者并不能互相取代，二者各有千秋。ChatGPT（尤其是 ChatGPTP Plus生成完整方案的能力要比 Gitlub Copilot 强，所以通常使用ChatGP工完成初步的代码生成，利用 Github Copilot的代码补全功能对用 ChatGPT 初步生成的代码进行微调，或者根据上下生成新的函数、方法、语句等，以及完善和检测已经存在的代码。**总之，类似于 ChatGPT、GitllCopilot 这样的AI代码生成工具通常要混合使用，才能达到比较理想的效果。
-----------------------------分割线，摘抄结束-----------------------------