这条标题在社区里刷屏的时候，我一开始没当回事，想着无非又是一轮“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，前端使用简单 HTML+JS，不引入重型框架 验收标准： 点击生成后在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_key=os.getenv("LLM_API_KEY")) SYSTEM_PROMPT = """ 你是一个短剧策划助手，只负责提供内容创意。 请确保生成内容符合主流价值观，拒绝输出违规内容。 """ def generate_script_idea(topic: str) -> dict: user_prompt = f"用户想做的短剧题材是：{topic}。请返回一个可执行的创意方案。" resp = client.chat.completions.create( model="gpt-4.1-mini", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_prompt}, ], temperature=0.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.md，Agent每做一轮改动前，会让它重新读一遍规格。
第三个认知，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这件事最有趣的地方。
