这条标题在社区里刷屏的时候我一开始没当回事想着无非又是一轮“AI取代程序员”的情绪化宣泄。直到我自己连续两周用 AI 编程 Agent 去做 AI 应用的落地实验才发现问题真正值得回答只是需要先把“自己”和“造”这两个词拆开——别再抬杠。先说结论AI确实能造出一个新的AI应用。代码、接口、页面、部署脚本大部分可以交由大模型和AI智能体完成但这不意味着人可以直接躺平。你能看到的所有“AI自己造AI”的真实样本背后都有一份清晰得近乎产品说明书式的需求边界以及一个人在旁边做纠偏。别急着争论“到底算不算”直接看机制、看流程、看坑会比站队有用得多。下面我按“技术拆解 → 逐层实现 → 实战复盘 → 问题排查”的顺序把我实际跑通的一条AI造AI链路完整记录下来。1. AI能不能自己造AI先别急着回答1.1 先落定义这里说的“造AI”到底是什么很多讨论到最后变成吵架是因为双方对“AI自己造AI”的定义完全不一样。有人期待的是像科幻电影里那样一个系统在机房里凭空觉醒然后自己设计下一代模型有人期待的是只要对着对话窗口说一句“帮我做个AI产品”一个完整应用就能自动交付。这两个理解放在今天都不现实也不必要。行业内真正在发生的“AI造AI”指的是大模型生成另外一个AI应用的代码并且让它跑起来。举个更具体的例子我让一个AI编程Agent去构建一个“AI短剧灵感工作台”这个工作台本身要调用大模型API来完成剧情创意生成。也就是说AI既负责编写应用代码又负责让这个应用具备理解用户输入并生成内容的能力。前者是普通软件开发后者是AI能力接入当一个AI Agent能把两件事同时做完并交付一个能直接使用的成品时它在工程意义上就已经完成了一次“自己造自己同类产品”的循环。所以如果你问“AI能不能造AI”我的回答是能但这里的“造”更接近“从无到有搭建一套可运行的AI应用”而不是“无中生有创造一个完整的新模型”。1.2 已经跑通的样本有哪些从2024年下半年到2025年我能亲眼验证的“AI造AI”案例已经不少而且不是那种只截一张代码截图就完事的演示。我自己的实践是在Cursor AI编程工具里把项目需求、技术栈、验收标准写成一段结构化说明然后让AI Agent去完成完整建模。它产出的东西包括一个后端服务、一个简单前端页面、数据库初始化脚本、部署配置。后端不是那种“Hello World”级别的空壳而是真的接入了大模型API、带有提示词模板、能根据用户输入流式返回结果。整个过程里代码修改工作量的九成是由AI完成的我做的就是拆需求、看输出、跑测试、发现问题后把它丢回给Agent 继续改。公开开源社区里也有类似现象。不少人用Codex CLI、Cline、Aider这些工具从一份GitHub仓库开始依靠AI Agent自动完成功能追加、bug修复和测试补充最后合并进主分支。这些任务不再是“写几行代码让你抄”而是经历“读代码→改代码→跑测试→根据报错再改→再跑”的完整工程循环。媒体上经常提到的AI编程能力目前已经不只是补全一段代码而是能自主理解一个多文件项目结构甚至在任务过程中自己更新技术方案。很多质疑者还停留在“AI只能生成片段”的认知阶段但真实项目的复盘已经证明AI不只会写还会自己验证、自己修错、自己把多个模块粘起来。2. “AI自己造AI”依赖的整套技术栈2.1 模型层代码智能的上限来自这里如果让AI去造一个AI应用它的第一个依赖是底层大模型的代码理解能力。模型需要能读懂一个目录下几十个文件之间的关系知道哪里的函数被谁调用知道给前端返回什么结构的JSON。这看起来基础实际上非常考验模型的上下文处理与推理能力。在实践里代码能力不足的模型会带来灾难性体验。它可能写出一段看起来逻辑自洽、但实际无法运行的代码或者在依赖版本上胡说八道。好的模型能减少无效迭代次数。比如同样是生成一个调用大模型API的Python后端好的模型会先确认SDK版本再写调用逻辑最后把异常处理也补上差的模型只会按记忆里的过期示例输出等你去踩坑。2.2 Agent层让大模型从“出主意”变成“干活”大模型本身不会操作电脑不会新增文件不会运行测试。真正把“AI造AI”从可能变成现实的是AI Agent这一层。AI智能体的工作机制很像一个外包团队它把一个大任务拆成小步骤然后逐步执行每一步。在AI造AI的场景里Agent需要完成这些动作阅读项目目录理解现有代码结构在指定位置创建、修改源文件执行命令行命令比如安装依赖、运行测试查看运行结果根据报错信息调整代码反复循环直到符合验收条件这个循环不需要人时刻盯着但需要保证每个步骤之间能串联起来。让Agent理解上下文比让它写代码更难因为只要上下文里少了一个关键信息它就可能把文件路径改错或者反复使用一个不存在的函数。2.3 工具层AI编程插件和IDE把意图变成文件改动没有工具层的配合模型再强也施展不开。我常用的组合是Cursor AI编程工具负责多文件级别的代码生成与重构IDEA系插件负责局部代码补全和审查再用Codex CLI处理那些需要独立终端环境的自动化任务。这三者的分工很有趣。IDE插件更适合“人在回路”的微调式开发它不会替你做架构级改动但能在你修改一个函数时同步联想到调用关系。Cursor这类编辑器则更适合让AI自主实现整个功能。Codex CLI之类则更像一个独立的AI程序员你给它一个任务描述它会自己决定要动哪些文件然后连续执行一系列操作。AI短剧、AI视频这类产品之所以能快速组装出来很大程度上也依赖工具层的进化。创作者不再需要手写很多底层调用代码AI编程工具能根据产品描述自动生成整合方案。2.4 工程层跑起来只能算原型部署上线才算产品很多人在AI生成代码后高兴地截图发动态说“AI自己做出了一个应用”但仔细一看应用只在本机开发服务器上跑通。AI造AI真正要变成可靠生产力还差最关键的一步工程化部署。这个阶段涉及AI基础设施比如选择容器镜像、API网关配置、模型服务的访问权限、数据库连接池的参数调整。我在实践过程中的经验是AI Agent能够处理大部分部署脚本的编写但它对“生产环境特征”的感知天然较弱。如果你只告诉它“写一个Dockerfile”它能写得不错如果你告诉它“这是一个日活预计一万人的服务需要考虑并发”它往往会忽略很多细节。AI应用开发走到这里最需要的是人来定义质量标准而不是来写代码。AI可以完成百分之七八十的编码与部署脚本工作那百分之二十的边界条件、安全防护、成本优化才是决定一个AI应用能否长期运行的关键。3. 实操复盘让AI完整搭一个AI应用的七个步骤3.1 写出能落地的项目规格书很多人在这一步就翻车。他们直接丢给AI一句话“帮我做一个AI短剧生成系统”然后期待它返回一个完整项目。这个粒度太粗了AI不是做不到而是最终产出的方向很容易失控。我把“需求规格书”压缩到刚好可以让AI理解用一两段说明项目目的用列表标清核心功能再写清楚技术栈和验收标准。以下是实际用过的规格片段项目名称AI短剧灵感工作台 核心功能 1. 用户输入一个题材关键词例如“重生、职场” 2. 系统调用大模型API生成片名、一句话亮点、分集梗概 3. 页面显示生成结果并提供“重新生成”按钮 技术选型 后端使用 Python FastAPI前端使用简单 HTMLJS不引入重型框架 验收标准 点击生成后在5秒内返回结果返回结构包含title、logline、episodes三个字段把规格说清楚后AI Agent几乎不会迷路。这一步也直接证明了“AI造AI”不是纯自动化人的判断力和产品思维仍然是决定成败的首要因素。3.2 让AI先列出任务清单和文件结构当我把规格书交给AI Agent后它做的第一件事不是马上写代码而是拆解目录。它意识到需要后端启动文件、模型调用模块、前端页面、配置文件和部署脚本。这个拆解过程很值得观察。如果AI只给你一个单文件解决方案往往意味着它打算用硬编码糊弄你。能做出完整应用的行为标志是它主动把“调用模型”“启动服务”“静态页面”拆成了不同模块。我的做法是让AI先把计划写在项目里的PLAN.md然后我再人工扫一眼有没有明显遗漏。这一步不耗时却能在后续过程中减少很多无效改动。3.3 核心模型调用代码的实现“AI造AI”在代码层面的核心是让程序具备调用大模型的能力。这部分并不复杂却是整个应用能被称为AI应用的关键。以下是一个简化版本演示Agent实际生成的代码形态# llm_service.py import os from openai import OpenAI client OpenAI(api_keyos.getenv(LLM_API_KEY)) SYSTEM_PROMPT 你是一个短剧策划助手只负责提供内容创意。 请确保生成内容符合主流价值观拒绝输出违规内容。 def generate_script_idea(topic: str) - dict: user_prompt f用户想做的短剧题材是{topic}。请返回一个可执行的创意方案。 resp client.chat.completions.create( modelgpt-4.1-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.85, response_format{type: json_object}, ) return resp.choices[0].message.content可以看到这段代码里没有多少“黑魔法”但它包含了几处关键工程决策使用环境变量保存密钥、在系统提示词里明确内容边界、要求模型返回可解析的JSON。这些是模型根据项目需求自动做出来的还是我要求的有一部分是我在需求里提示的有一部分是它在常见实践中总结出来的。混合协作往往能获得最佳结果。3.4 把前端和串起来前端部分如果从零手写会比较耗时。AI Agent的FastAPI后端实现好了之后会再自动生成一个前端HTML页面。界面的形式不复杂只有一个输入框和展示区域但这个过程展示了AI造AI的另一个能力它能把后端接口与前端页面正确连接。连接是AI编程新手最容易卡住的地方因为前端和后端是两个不同世界。后端返回的数据结构稍微变了前端就可能渲染不出来。我在实践里发现AI Agent在单次迭代中很少同时修好两边它更倾向于先改后端再回头改前端。这提醒我遇到跨端问题时要把“先理清接口契约再改代码”的指令写清楚。3.5 配置API密钥与环境变量一个应用需要访问大模型API密钥管理不交给AI自由发挥。规格书要求AI生成.env.example文件然后在本地测试时由我自己配置真实变量。AI会负责任地在代码里通过os.getenv读取环境变量而不是硬编码。这一步其实暗含训练时的安全意识。AI知道API密钥不能提交到Git仓库也知道真实密钥要放在不会被版本管理工具追踪的文件里。如果Agent在代码中把密钥写死了我会在审查阶段直接纠正。3.6 运行与自动化测试测试环节是AI迭代效率的分水岭。我在让Agent写完功能后要求它运行一个自动测试脚本。第一轮测试通常不会顺利通过可能是缺依赖可能是端口问题也可能是API响应结构不符预期Agent会抓取终端输出看完报错再自己修改。例如有一次前端拿到的是字符串而不是JSON页面渲染直接失败。AI Agent读取报错后自己补了一行响应格式验证并在前端解析前增加了一个类型判断。这种调试能力比写新功能更让人惊讶。没有跑过真实项目的AI很难产生这种反馈闭环一旦进入“写代码→跑测试→看报错→修代码”的循环AI的进步速度会快得多。使用AI自动化测试的场景很适合用来衡量一个模型好不好因为它要求模型不只是“生成”而是要理解失败原因。很多所谓“能写代码”的模型在这一步会原形毕露。3.7 部署到服务器本地跑通后我把同一个项目目录交给Agent完成服务部署构建一个简单的Docker镜像设置环境变量暴露端口。下面的文件就是Agent生成的部署配置示例FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8080]生成这样的部署配置并不难真正要注意的是Agent不会主动想到云服务器的网络策略、HTTPS证书、日志收集。在真实部署环节我还是自己手动补了域名的反向代理配置。这不是AI不行而是它当前还缺少对线上环境状态的感知。把它造出来的AI应用放到公网后你会更清醒地看到它在“创造”与“工程化落地”之间的距离。4. AI自主编程时最容易踩的坑4.1 问题速查表我在两周实验里遇到了不少问题整理成下表方便在做“AI造AI”实验时直接对照。常见现象排查方向有效对策Agent重复修改某个文件但问题没解决上下文里缺少真实报错信息把完整终端报错复制进对话而不是只问“怎么改”Agent写出的代码和已安装SDK版本不匹配它依赖的训练数据可能有滞后让Agent先执行版本查看命令再写依赖相关内容前后端数据对不上接口契约没有明确定义在规格里写清楚JSON字段名与类型AI陷入无限循环不停改同一处缺少终止条件给它明确的“最多尝试5轮如果仍失败则报告”指令生成结果包含危险或不当内容提示缺少系统级安全约束在提示词和代码逻辑中加入必要的过滤与拒绝策略Agent把生产环境需要的配置遗漏了AI不掌握线上环境状态需要人工补充基础设施层内容改了一个模块导致另一个模块报错缺少回归验证要求每次改动后都运行一次完整测试4.2 最值得留意的三个认知第一个认知AI Agent不是全知全能的。它会基于训练数据中的“记忆”来猜测API行为而不是每次去查最新文档。如果你让AI写一个非常新的SDK调用最好先让它去读一下当前项目的库文件或者把官方文档链接放进去。第二个认知AI在长任务中会产生“上下文漂移”。项目刚开始时它清楚目标做到第30步后它可能会遗忘最初的设计约束开始自由发挥。对抗方法很简单把验收标准写进项目根目录的README.mdAgent每做一轮改动前会让它重新读一遍规格。第三个认知AI生成的应用必须安装内容安全机制。既然标题说的是AI造AI应用那就必须牢记由大模型驱动的应用一定要在提示词层、输出校验层同时设置控制点。用系统提示词约束生成方向用户输入侧过滤异常内容输出侧再做一次校验。这不是额外的技术负担而是AI工程实践的基本盘。一个只想着“什么都能生成”的AI应用最后一定会在体验、合规和口碑上接连翻车。4.3 我坚持做的三层检查为了不让AI在无人看守的情况下把代码库改乱我建立了三层检查机制。第一层是每次让Agent执行大改动前强制它在项目里先生成一份CHANGELOG.md记录这次改动的目的。这个文件是给人看的能让Agent在第二天继续工作时快速回忆起昨天为什么这样改。第二层是让Agent运行单测与构建命令提供终端真实日志。我不接受“我觉得没问题”这样的表述。AI模型和人类程序员一样有时会高估自己代码的可用性以运行结果为唯一标准能筛掉很多幻觉。第三层是权限收敛。我从不把服务器的生产数据库密码直接放进环境变量表里给Agent使用。在开发和测试阶段使用单独账号在部署时才切换到最小权限的生产账号。AI确实能自己造AI但边界管理还是要人来制定。5. AI造AI的价值不是取代而是放大人的判断力回到最初的问题AI到底能不能自己造AI答案是能但它的“能”不是指完全不需要人。我做了一款微型AI应用也观察了AI Agent完整经历需求拆分、编码、调试、部署的全过程。整个工程让我最明显的感受是AI的自主能力并不可怕真正稀缺的是“能提出好问题、能写清边界条件、能判断交付质量”的人。现在“AI造AI”在开发领域愈发像一种常态化的AI工程实践。过去一个懂点大模型API的人要搭建一款可用的AI产品至少得花两周去处理前后端代码、环境配置、接口调试今天在Agent的辅助下这个过程我压缩到一天左右。剩下时间全部用来思考产品方向、数据安全、用户体验与成本控制。如果你也想复现这个链路我给三条来自实际操作的提醒第一项目最开始的需求说明一定要具体宁可多花十分钟把验收标准写清楚也不要给AI模糊的方向第二不要一开始就让Agent同时碰多个大模块先从最小可跑通版本开始成功后再逐步扩展第三要把AI生成的每一次改动都当作代码评审对象它写得快不代表它每一条决定都合理。“别吵了有人做出来了”背后真正值得关注的不是噱头而是一条正在被反复验证的路径AI不是自己独立长出来的它是在一套经过设计的流程里被另一个“造物主提示词”一支支点燃的。过去这要求你懂模型、懂框架、懂部署现在它更要求你懂边界、懂流程、懂取舍。这才是AI造AI这件事最有趣的地方。