用AI工具零代码开发AI工具

在AI快速演进的浪潮中，“用AI工具开发AI工具”不再是遥不可及的未来，而是今天就能上手的现实。本文结合我使用 Cursor 编程工具和 Autogen 智能体开发框架的体验，聊聊“零代码”开发AI工具的可能性、挑战与思考。

一、对使用AI编程工具的体会

1、新技术的误判，往往源于静态认知与动态现实之间的错位。

挺多人停留在早期对ChatGPT的认知，就没有继续尝试。尤其是ChatGPT类AI工具的认知，仍停留在早期阶段。初次接触时，由于市场宣传激发了极高的期待，但实际体验往往并不理想：AI常常“一本正经地胡说八道”，生成的代码看起来合理，实际却无法运行。这种“期望越高、失望越大”的落差，使得不少用户草草定论：“大模型不靠谱”，从而放弃了进一步尝试。然而，问题并不在于大模型“永远做不好”，而在于大模型的能力正在以超出想象的速度持续演进。很多人基于旧版本的体验就下了判断，却忽视了版本更替带来的质变。

2、大模型只是“发动机”，配套的工具体系才是“底盘”和“车轮”。

大模型是AI能力的基础，但真正释放其价值，还需要强有力的工程化配套工具。我在使用 Cursor 之前，我也尝试过一些主流的编程类插件，它们确实在某些场景下能提供一定帮助，比如改进单个函数或优化一个文件的写法，但整体而言，作用有限，更多时候只是锦上添花，而非雪中送炭。这些插件往往局限于方法级或文件级别的“点状增强”，缺乏对项目全局的理解与上下文保持，因而在实际开发中显得有些鸡肋——用着不痛快，弃之又可惜。Cursor 则带来了完全不同的体验。它不仅接入了能力强大的大模型，还在开发环境中深度融合了诸如上下文保持、跨文件理解、自动重构、智能注释、交互式Debug等实用功能。模型能力+工具能力的双轮驱动，让“AI辅助编程”从实验室走向了生产线。我当时就迫不及待在团队中推广开来的想法，让大家都用起来，提高开发质量和效率。

这次转变也让我真正认识到：大模型只是“发动机”，配套的工具体系才是“底盘”和“车轮”，二者缺一不可。只有当AI的智能能力与工程实践深度结合时，AI开发工具才能从“好看”变得“好用”，最终成为提升研发效率的关键生产力。如果你还没使用过Cursor，建议你试试，网上有很多的视频介绍，我自己是经常关注一些编程类博主，通过他们最新的视频介绍让我快速了解是什么，能做什么，再决定是不是要亲自测试使用下。

3、与大模型协作，不是简单的提问和回答，而是一次交互式的共创过程。

使用大模型进行开发，本质上也是一项“熟能生巧”的技能。它并非一次尝试就能立刻达到理想效果，而是需要开发者不断地与模型“磨合”，理解其优势，掌握其边界，逐步建立起高效的协作方式。很多人初次使用大模型时，期望它能像人类专家一样“一次搞定”，结果稍有偏差就迅速失望，甚至全盘否定。这其实忽视了一个核心事实：与大模型协作，不是简单的提问和回答，而是一次交互式的共创过程。就像驾驭一台性能强劲但操作复杂的机器，想用好它，必须投入时间学习、不断试错，并逐步形成自己的提示技巧和操作习惯。我觉得罗振宇所说的师傅与徒弟的关系非常贴切，你是师傅，大模型工具是你的徒弟，要指导它教它怎么做。有兴趣的可以找一下他的原话，听一下还是挺受益的。

因此，耐心与平常心至关重要，有时它很聪明做得很好，有时它把已经做好的功能悄悄地改动了，有时看似很简单的却反反复复交互很多次才实现，结果代码堆积如山。把大模型当作一个值得信赖但尚需引导的“助手”，而不是全能的“代工者”，才是正确的心态。随着使用的深入，你会发现，它的反馈越来越贴近你的意图，配合度越来越高，最终真正成为日常开发中的得力工具。

举个例子，它写代码很快，很多时候只增加不删减，之前有个复杂一些的前端页面，几天下来一万多行的代码，很多反反复复的css样式，还是需要很具体的告诉它要怎么拆分，怎么做，它才会做出符合你预期的结果。

4、威胁最大的是没有产品思维的程序员。

真正受到冲击的，并不是程序员这个职业本身，而是缺乏产品思维的程序员。大模型在自动生成代码、调试逻辑、优化性能等方面的能力不断增强，正在逐步替代机械性、重复性较强的编程工作。在这样的趋势下，仅具备“把功能写出来”的能力，已经远远不够。未来更具竞争力的程序员，必须具备产品思维：能理解用户需求、洞察业务本质、把控产品逻辑，并基于技术手段提出更优解。这种能力不仅AI暂时无法替代，而且将在人机协作时代中变得尤为重要。换句话说，代码会写的程序员越来越多，能解决问题、创造价值的程序员才真正稀缺。AI降低了“写代码”的门槛，但抬高了“写对的代码”的标准。再说直白一点，我自己是产品经理，我有想法，我为什么还需要多轮的沟通、协调排期，等设计、等原型、等开发、等测试呢？在传统开发流程中，从一个想法的诞生到最终验证，往往需要经历需求梳理、原型设计、技术选型、编码实现等多个环节，周期长、成本高。而现在，通过大模型辅助开发，这一过程被大幅压缩：

• 快速试错许多原本需要几小时甚至几天验证的想法，现在通过与AI的几轮对话即可搭建出基础实现，马上看到效果；
• 高效验证通过自然语言描述，AI能快速生成核心逻辑和UI骨架，使“可行性验证”变得简单直接；
• 高保真 demo 即产品雏形许多AI生成的demo在结构和逻辑上已经相当接近可交付产品，稍作调整即可投入使用，避免了“原型重写”的资源浪费。
  

这些变化不仅提升了研发节奏，更让“从创意到实现”之间的距离被极大拉近。AI不再只是加速工具，而是正在成为产品迭代流程中的重要参与者，让技术和创意之间的转化更加高效、高质、低门槛。

5、没编程经验的人开发一个demo玩具是可以的，但是要开发一个复杂的应用，目前还很难。

当前市面上流行的“零代码”“一句话开发”类AI工具，确实降低了应用开发的门槛，使得非程序员也能轻松构建一些简单的demo或原型，这在用户体验测试、创意验证等场景中具有一定价值。但这类工具在面对复杂业务系统时，仍存在明显的能力边界。目前所谓的“一句话生成应用”，大多仅适用于纯前端页面或简单的脚本逻辑，缺乏完整的权限管理、数据持久化、接口规范、异常处理等能力。没有数据库支持的系统，本质上是不完整的，无法支撑真正意义上的可落地产品。 对于复杂应用的开发，仍然需要系统架构设计、模块拆分、数据建模、部署运维等完整的工程化流程。AI可以极大提升开发效率，但并不能代替对系统性思维、软件工程原则的深刻理解。 因此，不能被“低门槛”所迷惑，更应关注AI工具在真实生产环境下的适用边界。AI可以让更多人入门开发，但真正构建有质量、有稳定性、可迭代的应用，依然离不开专业开发者的介入与主导。

二、Autogen多智能体框架的体验

具体Autogen的技术特性和教程，可以参考官网或一些公开的教程，这里就不赘述了。

1、什么是智能体？

我最早接触智能体开发是使用 MetaGPT 框架，那时候主要还是感受其“编排式”的任务协作。但从 Autogen 0.4 版本开始，整个框架发生了质的飞跃，不仅引入了更丰富的交互模式，更新节奏也非常快。Autogen 不仅提供了面向底层能力的 Core API，也提供了更适合快速上手的 AgentChat API、Extensions API，让开发者能根据不同需求灵活构建属于自己的“智能体”。

我觉得**能够自主思考“怎么做”，并能将想法实际执行出来的系统，才称得上一个真正的智能体。**从技术组成上来说，就是大模型（思考） + 工具function calling、MCP（做） + 记忆 + 工程化 ，形成一个具象化的应用。

• 大模型（LLM）充当智能体的大脑，负责“思考”和“规划”；
• 工具调用（Function Calling）、MCP（工具链）是它的“手脚”，帮助它执行复杂操作；
• 记忆系统（Memory）赋予它上下文感知能力，能积累经验、调整行为；
• 工程化封装将上述能力融合成一个结构清晰、接口明确、可复用的实体系统。
  

前段时间火出圈的 Manus 项目可谓一阵“过山车式”的热潮，引起不少的骚动，马上就出来一个Open Manus，从Open manus的源码来看，说实话没有太大的惊喜，而且还觉得挺简陋的，只能说它让大多数人从技术上了解体智能的根本原理，其实并没有那么神秘，先拆解计划任务再逐个react，关键的还是大模型的能力和提示词，以及整体的用户体验。

2、人们在做具体事情时，还是喜欢确定性

在 Autogen 0.5.6 版本中，官方引入了一个重要的新功能：GraphFlow。这个功能一出现，就让我之前一直困扰的一个问题豁然开朗——在有了AI智能体之后，传统基于流程驱动（workflow-based）的任务处理模型是否还需要存在？

过去很多关于智能体的文章和框架，往往在强调“自主性”“涌现性”这些AI特性时，对它与流程化系统的关系却语焉不详，甚至给人一种“流程设计已过时”的错觉。这种现象就像大模型爆发之后，大数据的讨论声量明显下降一样。

但事实并非如此。GraphFlow 的出现，清晰地回答了这个问题：流程不是被取代，而是被“智能化”了。

GraphFlow 支持将多个 Agent 以有向无环图（DAG）的方式编排在一起，每个节点负责具体任务，按设定顺序完成复杂任务链条。这种设计不仅保留了流程驱动系统的可控性与可预测性，同时融合了智能体的灵活性与决策力。对我个人而言，这也解答了过去的一个疑惑：如果我依然使用“任务流”方式串联多个 Agent，是不是背离了“智能体”的理念？现在我可以更确定地说：这正是走在正确方向上的实践。

大模型的输出虽然强大，但其不确定性也为落地带来了挑战，尤其是在企业级（B端）应用中，流程的稳定性、任务的可复现性、异常的可控性，依然是基本要求。智能体只有在合理的流程框架和工程约束下，才能真正成为可靠的系统构件。

3、大多数智能体的逻辑是浏览器+代码编写的文本生成

如上图所示。OpenAI 此前提出了通往通用人工智能（AGI）的五级发展路径。目前业界普遍认为，我们正处于第三级的初期阶段。在第一级和第二级中，AI在自然语言对话、基本推理与理解方面已经表现得相当成熟，ChatGPT、Claude、Gemini 等产品的广泛使用便是明证。

但需要理性看待的是，离真正的“创新型智能（第4级）”甚至“组织级闭环智能（第5级）”还有很长的路要走。当前市面上面向 C 端的所谓“通用智能体”，虽然在交互体验上颇具智能感，但本质上大多仍停留在以下几个步骤的循环中：

• 通过搜索引擎或爬虫获取互联网公开信息；
• 借助大模型进行内容理解与重组（如代码生成、数据分析等）；
• 使用通用工具（打开文件、运行命令、代码执行、调用API等）完成简单任务流程。
  

这一工作机制虽具一定自动化能力，但其任务完成范围、泛化能力与自主决策仍然极为有限，更多体现的是“可编程性增强的搜索引擎”，而非真正意义上的“类人智能”或“自组织系统”，并且在B域应该不是这样的一套通用智能体逻辑。

值得注意的是，目前这些智能体大多无法实现多目标权衡、自主流程规划和策略调整，更谈不上在真实组织中替代人类角色进行持续任务执行与反馈迭代。这也正是为什么C端“智能体”热度虽高，但在B端实际落地依旧艰难的根本原因。

4、Autogen目前的终止方式是迭代次数或终止标识，应该只是一个过渡方案

目前 Autogen 框架对智能体任务的终止控制，主要依赖两种方式：迭代轮次数上限和显式终止标识（如停止词或指定响应）。但无论是哪种方式，实质上都只是为了防止智能体“跑飞”所设置的静态边界条件，应该属于一种过渡性方案，与期望的灵活、稳定、自主可控的智能体运行逻辑之间，仍存在不小差距。

尤其是按固定轮数终止（如最大5轮、10轮）的问题更为突出：

• 不具备语义理解能力系统无法识别任务是否真正完成，只是“到点就停”，这与智能体“自主完成任务”的目标背道而驰；
• 易导致任务中断或过度对话简单任务可能浪费迭代轮次，复杂任务则可能在关键步骤被强制中断，影响结果质量；
• 不利于行为调试与系统优化开发者很难从迭代次数中分析出任务失败的根本原因。
  

相比之下，更理想的终止机制应具备一定程度的“任务态感知能力”，例如通过动态监测任务完成状态、智能识别重复信息或无效对话，甚至根据上下文主动生成“任务终止建议”，从而实现更精准、语义驱动的终止控制。

三、AI Generate Book的开发初衷

1、使用搜索引擎的比例已经大幅降低。

现在遇到不懂的问题或想学习一些新的知识，基本上都是先在大模型对话，很少在使用搜索引擎了，除非有时大模型给出的结果不是太满意。使用最多的是CharGPT-4o模型，对比过很多国内国外的大模型，还是它最顺手，很多时候都很符合我需要。但是想学一个比较大的知识的时候，总是要很多轮的对话，次数多了之后变得很零散了，很难再结构化地组织起来，形成一个整体，所以想着自己开发一个AI Generate Book小应用，能够形成比较系统、结构化的学习内容，并且可以对每个章节有寻寻渐进的效果，并读不理解或想深入的内容，可以无限扩展知识点，以及标注划重点。相比于以前，大模型确实是提高了学习效率。

在开发AI Generate Book之前，也用Cursor开发过微信小程序、B/S架构的简单任务管理、MAC的原生应用，只是我觉得这个是比较完整的，并且是用AI工具开发的一个基于AI的工具，99%的代码都是用大模型生成的，不到1%是自己手工调整的。

首页

内容及扩展知识点

2、AI Generate Book的技术架构

以下是使用到的技术，总体来说还是很简单的。

大部分应该都很容易它们的用途，这里只介绍几个比较重要的：

• MCP fetch。直接使用开源的MCP fetch Server，用于获取网页的内容；
• function search-web。自定义的函数，用于与searng交互，并提供给大模型function calling；
• searxng。开源的搜索引擎，自行使用docker部署，主流的搜索引擎都是要收费或限制次数的；
• DeepSeekV3。所有的文本生成都是使用它；
• 阿里百炼。使用了文生图的模型，用于生成书本的封面；
  

这是AI Generate Book的地址，有兴趣的可以体验以下，所有的免费token和图片生成调用次数用完，再考虑是否继续维护。如果喜欢的话，也可以页面最下方贡献token，将全用于模型充值。