企业官网建设流程全解析

1. “AI造AI”到底在造什么

1.1 先厘清概念：AI造AI不等于AI自我进化

最近半年，“AI能不能自己造AI”这个问题在开发者圈子里被反复吵上热搜，吵架的双方经常根本不是在聊同一件事。有人理解的“造AI”是“让AI设计出比自身更聪明的下一代AI”，这是AGI层面的问题，现阶段确实做不到；而有人理解的“造AI”是“让AI去写AI应用、训练脚本、推理服务、部署配置”，这个事不仅已经有人做出来了，而且做出来的效果已经可以进生产环境用了。

我自己最近就干了一件挺有仪式感的事：扔给一个AI Agent一份任务简报，让它从零开始开发一个“产品文档RAG问答机器人”——包含后端接口、向量检索、模型接入、前端页面、Docker部署，最后Agent自己跑测试、自己修bug、自己把服务拉起来，我用浏览器访问时发现页面都能正常出来。整个过程里我只做了三件事：写清楚需求、盯着它别偏、最后做验收。

所以你看，如果我们把“AI造AI”定义成“AI作为工程师，完成AI应用的设计、开发和部署”，那这个标题没什么可吵的，答案就是“能”。它不是科幻，是工程效率的一次实实在在的突破。

1.2 为什么争议这么大：能力边界与想象力的错位

争议大的核心原因，是“造AI”这个词太容易被过度解读。网上讨论AI自我复制、AI自行进化，天然自带流量，但落到工程现场，我们关心的其实是更具体的问题：AI能不能把一份模糊需求变成可运行的代码？能不能在编译报错时自己定位问题？能不能把一个模型推理服务完整部署上线？

从我自己实操以及身边团队的使用情况看，答案是明确的“能”，只是有条件。条件是：任务边界要清晰，执行环境要给足，反馈回路要完整，人工审核不能缺位。AI Agent不是神仙，它更像一个执行力极强但需要环境配合的初级工程师。给它一台能跑命令的电脑、一套能回传报错信息的工具链、一份够具体的需求说明，它就能像人一样，一个文件一个文件把项目搭起来，再通过运行结果倒逼自己修正。

这篇文章我就把自己做“AI自己造AI”的完整过程、技术选型、踩坑记录和边界思考全部摊开。适合谁看？想用AI Agent提升开发效率的工程师、正在评估“AI能否承担部分研发工作”的技术管理者，以及单纯好奇AI能力边界的产品和测试同学。

2. 工具选型：让AI“自己动手”需要怎样的底座

2.1 核心组件：大模型 + Agent框架 + 执行环境

想让AI Agent真正完成开发任务，光有一个聊天窗口远远不够。你需要三个东西协同工作：一个会思考的大模型、一套能调度工具的Agent框架、一个允许Agent动手操作的真实环境。

大模型是“大脑”。最好选代码生成能力强的模型，同时要求支持长上下文和工具调用。我这次的主力模型是支持Function Calling的版本，规划任务时用它的强推理能力，写代码时用它的代码补全能力。如果你的环境允许，也可以考虑本地部署的开源模型，比如用Ollama跑Qwen系列，这样简单模块可以交给本地模型执行，复杂规划和设计再交给云端模型，成本会更可控。

Agent框架是“手和脚”。常见的开源方案有LangGraph、AutoGPT，也有偏应用层的Dify，Java生态里还有Spring AI。它们本质都是给AI提供文件读写、终端执行、网页访问、工具调用等能力，并维护“规划—执行—观察—再规划”的循环。如果你只是做一个快速验证，用LangGraph搭一个最小循环就够了；如果是企业内部落地，我更推荐Dify或自研一套轻量框架，便于控制权限和审计。这次演示我用的就是基于LangGraph改的极简Agent，总共就两层：主Agent负责任务拆解，工具层负责读写文件和执行shell命令。

执行环境是“工地”。这也是新手最容易低估的部分。AI Agent必须能真正跑在沙箱环境里，能够执行pip install、运行pytest、读取报错输出，才能形成“写代码—看结果—改代码”的闭环。我用的是一台带Docker的Linux服务器，所有操作都在容器里进行，宿主机只挂载了一个工作目录。这样既给了Agent足够的自由度，又不至于让它碰到系统关键目录。

注意：给Agent的“工地”一定要隔离。它会在里面执行任意命令，所以绝不能和生产环境、密钥文件混在一起。用容器隔离是底线，不是可选项。

2.2 为什么不是“一句提示词”就能完成

现在很多人习惯在ChatGPT里发一句“帮我写一个RAG机器人”，然后复制粘贴代码。这不算AI造AI，这只是AI当百度用。真正的AI Agent开发，要求AI自己管理整个项目生命周期，它要知道该建哪些文件、依赖装什么、程序怎么跑、报错怎么修。

我尝试过一个对比场景。同一个小型情感分析API，让普通聊天模型“一次输出”和让Agent“自主迭代开发”是两种完全不同的结果。前者会给你一个看起来完整、但大概率跑不起来的代码片段；后者会自己创建虚拟环境、安装依赖、启动服务、用curl打接口验证，最后交付的是一个实际上线可用的服务。差别在哪？差别就在于有没有“运行反馈”。

所以我把这次实践的关键总结成一句话：AI造AI的本质，不是AI一口气写出完整程序，而是AI在一个能自我验证的环境里，通过多轮试错把程序改到能跑。这就意味着工程约束比模型本身的智商更重要。你得把任务目标量化、把验收标准写清楚、把迭代轮次卡住，AI才能真正为你创造价值，而不是给你制造一堆需要返工的半成品。

3. 实操记录：我是怎么让AI Agent从0到1做一个RAG问答机器人

3.1 第一步：给AI写一份“任务简报”

这次我选了一个很典型的AI应用场景：产品文档问答机器人。用户传入一段问题，系统从本地文档库里检索相关资料，然后让大模型基于检索结果生成回答。这类应用是RAG（检索增强生成）的经典落地形态，也是AI应用开发里最有代表性的“AI工程”活。

我先把任务简报写好，简报里写明了技术栈、目标接口、验收标准和约束条件。如果你也想复现，可以直接参考这份结构：

• 项目目标：基于产品文档，构建一个RAG问答API，支持上传文档、检索、问答三个接口。
• 技术栈要求：Python 3.11、FastAPI、Chroma向量数据库、一个Embedding模型、一个LLM接口（我用的是兼容OpenAI格式的本地模型服务）。
• 功能范围：上传PDF/Markdown时自动切分；问答接口先检索top-k相关片段，再让大模型生成答案；结果返回引用来源。
• 明确“不要做”：不要做用户登录、不要做前端复杂交互、不要做权限管理。
• 验收标准：/upload接口能上传并检索；/ask接口能基于文档内容回答问题；/health接口返回200；每个模块都要有测试。
• 运行约束：所有命令必须在项目虚拟环境内执行，目录结构遵循FastAPI官方最佳实践。

你可能会问，为什么非要写这么细？因为AI Agent在面对模糊任务时，最大的风险是自由发挥。它会给你加一堆花哨但没用的功能，也会忽略你真正关心的细节。任务简报的价值，就是给Agent划定边界，让它把精力集中在核心交付上。这个步骤花了我大概半小时，但它决定了后面几小时的输出质量。

3.2 第二步：Agent从规划到动手

任务简报写好之后，我把Agent启动，它会先输出一份项目规划。这一步真的很有意思，它产生了这样一个目录结构：

doc-qa/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI入口 │ ├── models.py # 数据模型 │ ├── ingest.py # 文档加载与切分 │ ├── retriever.py # 向量检索 │ ├── generator.py # LLM生成回答 │ └── config.py # 配置管理 ├── tests/ │ ├── test_health.py │ ├── test_ingest.py │ ├── test_retriever.py │ └── test_api.py ├── docs/ # 测试用文档 ├── requirements.txt └── README.md

它没有问我任何问题，直接按照任务简报给的约束搭好了骨架，然后开始逐文件写代码。这里我截取一段它生成的检索模块核心代码：

# app/retriever.py import chromadb from app.config import settings class Retriever: def __init__(self) -> None: self.client = chromadb.PersistentClient(path=settings.CHROMA_PATH) self.collection = self.client.get_or_create_collection( name="doc_snippets", metadata={"hnsw:space": "cosine"} ) def add_snippets(self, ids: list[str], documents: list[str], metadatas: list[dict]) -> None: self.collection.upsert( ids=ids, documents=documents, metadatas=metadatas ) def search(self, query: str, top_k: int = 4): result = self.collection.query( query_texts=[query], n_results=top_k, include=["documents", "metadatas", "distances"] ) return result

这段代码虽然不是多复杂，但它用到了持久化向量存储、cosine距离、upsert操作，基本是当前RAG工程的标准写法。Agent能够生成这种代码不稀奇，稀奇的是它接下来知道自己要去跑测试，而不是把代码丢给我就完事。

3.3 第三步：自主运行与调试

Agent写完第一批文件后，自动在终端里执行了这么一串命令：

cd /workspace/doc-qa python -m venv .venv source .venv/bin/activate pip install -r requirements.txt pytest tests/ -v --tb=short

第一次运行不出意外地挂了。测试失败信息显示，test_retriever.py里调用的get_or_create_collection和已安装的Chroma版本行为不一致：旧版本需要传embedding_function参数，新版本默认用了某个内置模型，导致维度不匹配。这里我发现一个很关键的设计：Agent能读取终端返回的完整输出流，包括stderr里的红色traceback，然后根据这些报错信息去改代码或调整依赖版本。

它几秒后给出了解决方案，把依赖版本锁定到兼容区间：

chromadb>=0.4.15,<0.5

然后重新执行了安装和测试。经过三轮“写代码—跑测试—看报错—改代码”的循环，测试全部通过。我全程没有碰键盘。这个自主调试的过程，说真的，比看到它一次写出完美代码更令我震撼，因为这才是真实工程开发的状态，没有人能一次写对，但能做到快速定位、快速修正，就是生产力。

3.4 第四步：部署上线

测试通过后，Agent没有停。它自动生成了Dockerfile和docker-compose.yml，把模型服务也编排了进去。最终部署后我用到这几个文件也没改，Agent生成的docker-compose长这样：

services: embedding: image: ghcr.io/ollama/ollama:latest command: serve volumes: - ollama_data:/root/.ollama api: build: . ports: - "8000:8000" environment: - CHROMA_PATH=/data/chroma - LLM_BASE_URL=http://embedding:11434/v1 - LLM_MODEL=qwen2.5:7b volumes: - ./data:/data depends_on: - embedding

部署完成后，Agent自己执行了冒烟测试，用curl请求了/health接口，又向/ask接口提了一个和测试文档内容相关的问题，验证返回结果里包含预期内容。我是在它全部完成之后，才打开浏览器输入http://服务器IP:8000/docs，看到了FastAPI自动生成的Swagger文档页面。那一刻我是真的有点恍惚，这个应用虽然不算复杂，但它是AI从零到一自己构建、自己调试、自己部署上线的，这就是“有人做出来了”最直观的证明。

4. 一路上踩过的坑与排查技巧实录

4.1 AI“自嗨式开发”怎么防

我实操中第一个遇到的坑，是Agent很容易陷入“自嗨式开发”。什么意思？就是它不停写代码、不停生成文件，但从不主动运行验证，最后交给你一堆根本跑不起来的东西。这在早期的Agent框架里特别常见，OpenAI的Codex和AutoGPT都有这个问题。

解决办法是在任务简报里写死循环规则：每完成一个模块，必须运行对应的测试，不通过就不允许进入下一个模块；所有命令必须在终端里真实执行，不允许模拟；任何依赖变更后都要重新跑全量测试。我后来就给Agent加了一个“强制验证”工具，所有写文件操作之后都要跟着执行一个状态检查，做不到就报错，逼它遵守纪律。

另一个细节是轮次上限。Agent一旦陷入反复改同一个bug的情况，会无限消耗token。我会在框架里设定最大迭代次数，比如20轮。超过之后，Agent会被要求停下来，输出“问题摘要”和“建议人工介入点”，由我来决定是继续还是换思路。实测下来，大多数问题在10轮内都能解决，20轮基本是兜底。

4.2 依赖地狱与版本飞镖

RAG相关的Python生态，版本冲突是重灾区。Chroma、pydantic、fastapi、embedding模型之间经常出现“明明前几天还能跑，今天重新安装就报错”的情况。Agents自动装依赖时，往往会选择最新版本，结果往往触发各种兼容性问题。

我踩过一个特别典型的坑：Chroma对pydantic的版本要求很严格，如果系统里已经装了一个较新的pydantic，Chroma导入时直接抛出“无法从pydantic导入字段”之类的错误。第一次跑的时候，Agent傻傻地试了五六种解决方法，最后才意识到应该用虚拟环境并锁定版本。

这个坑我现在已经有了一套标准动作：

• 尽量用uv pip compile生成锁文件，锁定所有传递依赖版本。
• 所有依赖安装都在项目自己的虚拟环境或容器内进行，绝不使用全局环境。
• 涉及AI应用时，优先让Agent参考项目模板里的requirements版本，而不是自己盲猜最新版。
• 遇到版本冲突，先让Agent检查所有依赖的声明约束，再决定升级还是降级，不要一次改多个包。

有个细节值得单独提一句：chromadb在0.4.x和0.5.x之间的存储格式不兼容，如果你中途升级了版本，旧的持久化数据可能直接没法读取。所以一旦项目开始跑，就不要频繁改向量库的主版本，这个教训我帮大家踩过了。

4.3 成本与时间失控

AI Agent的token消耗非常惊人，尤其是让它“想清楚了再干”的模式。有一次我扔给它一个中等复杂度的任务，让它先做详细设计再写代码，结果光设计阶段就花了接近两万token，最后写代码反而只用了八千。这种消耗不完全是浪费，但规划部分过长了确实是一种成本失控。

我的控制策略是这样的：

• 把任务拆分，不要一次性让Agent完成整个大项目，而是分模块、分阶段提交。
• 简单但重复的工作，比如生成单元测试模板、写DTO类，可以切到本地小模型执行，复杂规划和重构才用云端大模型。
• 在Agent框架的每次调用里都设置max_tokens上限，防止一次生成超长但不必要的内容。
• 监控token消耗，设一个硬预算，比如“整个任务最多消耗30万token”，到了以后强制停止并输出阶段性成果。

时间失控也值得注意。Agent在等待模型返回时如果遇到网络超时，很多框架会直接判定失败，导致整个任务反复从头开始。我一般会让Agent框架内置重试机制，但重试次数不要超过3次，避免在一个僵死的请求上无限等待。

4.4 安全与合规底线

现在市面上有一些打着“无限制”“无审核”旗号的AI工具，我个人是不推荐把这类工具引入工程环境的。Agent本身就是高风险组件，它既能写代码又能执行命令，如果再用“无限制”的思路去使用，跟把生产服务器的钥匙挂在门口没有区别。

我在实践中总结出几条安全红线，希望在工程化AI Agent时能守住：

• Agent运行环境与生产环境严格隔离，Agent只能操作指定的工作目录，不能访问系统目录、密钥、数据库地址。
• 所有Agent生成的代码在合并到主分支前，必须有真人评审。这是流程底线，不是效率问题。
• Agent执行任何安装类命令前，要弹出“执行确认”钩子，尤其是在非容器环境里。
• 日志记录Agent的每一步操作，方便事后审计。你永远不知道它会在第几轮迭代里做出什么奇怪操作。
• 对接企业数据时，要提前给Agent配置最小权限，不能因为“它是AI”就让它接触所有数据。

说得直接一点，AI造AI要想进生产环境，“有审核、有护栏”是基本前提，这不应该成为妥协项。一个能自己跑代码的Agent，必须有比人类员工更严格的权限管控，因为我们还无法完全预测它在边界条件下的行为。

5. 冷静看待“AI造AI”：边界、收益与工程师的新角色

5.1 现阶段能做什么、不能做什么

这次实践跑通之后，我并没有整天喊“AI要替代程序员了”，反而对这件事的边界更清楚了。现阶段AI Agent能做的，是那些需求明确、验证方式清晰、技术栈成熟的开发任务。比如开发一个CRUD管理后台、写一个模型推理服务、生成单元测试、修复编译错误、编写部署脚本，这些事它做得又快又稳，效率普遍是纯人工的好几倍。

但它目前还做不好的事情也很明确。第一，它不理解模糊的业务意图。你跟它说“给客户做一个更好的体验”，它不知道“更好”具体指什么，需要你把需求翻译成可验证的指标。第二，它在做架构权衡时经常给出平庸的方案。它不是不会选型，而是缺乏对业务生命周期的判断，容易选择短期写着爽但长期维护困难的方案。第三，它对自己的输出质量有过度自信，如果不强制验证，你拿到手的东西质量是完全不可控的。

所以我的判断是：AI造AI在工程层面已经是真命题，但它造的更多是“能工作的AI应用”，而不是“高瞻远瞩的AI架构”。工程师的价值不在于和AI比写代码速度快，而在于定义边界、做出取舍、判断什么叫“足够好”。

5.2 工程师如何与AI协同

既然AI能承担越来越多的开发执行，那工程师的新定位是什么？我的观察是，工程师正在从“实现者”变成“验收者+架构师+安全闸门”。我们不再需要把每个接口都手敲一遍，但我们需要设计清楚系统边界、任务流程和验收标准。

几个实战建议供参考：

• 任务拆解粒度要小。我建议把一个大项目拆成“每个子任务能在30分钟内验证结果”的粒度。任务越小，AI的失控概率越低。
• 验收标准一定要可执行。不要写“性能要好”这种话，要写“首页接口在100并发下P95延迟低于300ms”。
• 强制AI先生成测试，再写实现。测试即需求说明书，对AI的约束作用立竿见影。
• 用Git管理AI的所有产出。每次Agent修改代码都生成独立分支，方便回溯和评审。

其中“先生成测试，再写实现”这个技巧我特别想强调。让AI自己写测试，实际上是逼它先思考“这段代码该怎么定义正确”，而不是急着堆功能。实测下来，用这个流程能让AI交付代码的通过率提升一半以上，而且返工次数明显减少。

5.3 下一步可以延伸的方向

这次跑通的是单Agent完成一个小型AI应用。再往下延伸，有几个方向我判断会很快成熟。

第一个是多Agent协作。让一个Agent专门写代码，另一个Agent专门做代码评审和测试设计，两个Agent相互制约，质量会明显高于单Agent。已经有团队用这种方式跑通了中等复杂度的项目，效果很可观。

第二个是AI Agent与AutoML的结合。现在的Agent能写训练脚本，但超参搜索、模型选择、效果评估这些还是靠人工在管。如果把主动学习和Agent结合起来，让AI自己去看指标曲线、自己调整训练参数，那才是真正意义上的“AI训练AI”。

第三个是Agent接入企业级AI应用开发平台。比如Spring AI目前已经在Java生态里提供了一套成熟的AI应用抽象，如果你所在团队是Java技术栈，可以基于Spring AI构建自己的AI服务，再让Agent利用这些组件做开发。这比从零搭建一套Agent工具链要省事得多。

第四个是把Agent用于AI测试。我们团队已经在用Agent自动生成AI应用的测试用例、生成badcase数据、做回归验证。这个方向非常实用，因为AI应用的不确定性很高，人工测试根本覆盖不过来，让AI测试AI，闭环刚好。

我个人看法是，AI Agent会先从“完成独立小任务”进化到“参与复杂项目的完整生命周期”，但这个过程需要大量的工程注入，不是模型越强就自动发生的。它需要工具链、流程、评估体系、安全机制一起跟上，这也是接下来一两年AI infra方向最值得投入的地方。

最后再分享一个我在这次实践里发现的小技巧：如果条件允许，让Agent在写代码之前，先把项目的README写到一半，只描述完项目定位和快速开始，然后逼它自己把剩余部分补完。这个办法看似绕路，但效果出奇的好，因为它能倒逼AI在动手编码前就建立起项目整体的逻辑地图。你也不妨在自己团队的Agent工作流里试试这一手。