如何借助 AI 完成能正式上线的前后端项目？

核心回答

我会把 AI 放进需求明确、前后端贯通、能验证也能维护的交付过程中。先定义用户要完成的核心动作和验收标准，确定页面、接口、数据与运行方式；再让 AI 按小任务实现，每一步都用真实运行结果反馈，最后验证部署后的完整业务链。

以研搜应用为参考：React 前端提交问题和附件、展示进度与下载结果；FastAPI 承接任务与文件接口，WebSocket 推送执行事件；主 Agent 调度业务能力并生成文件。先打通“提交任务—看到进度—取得产物”，再补正式运行需要的身份与文件权限、任务状态持久化、失败处理、监控和发布回退。

AI 可以写页面、接口、测试和配置草稿，工程人员负责明确业务规则、控制改动范围、检查关键实现并判定验收。正式交付应能回答“系统实际做成了什么、失败时怎样处理、上线后如何维护”，而不只是展示生成了多少代码。

展开说明

1. 先明确一条可验收的业务链

从用户动作出发，定义页面状态、接口输入输出、错误情况和数据归属，再选择能支撑它的技术栈。优先使用团队熟悉的框架和已有组件，避免让 AI 每次重新创造目录、错误格式和依赖方案。

研搜例子中，提交任务返回的 started 只表示后台任务已创建，前端仍需接收进度、完成、失败和取消等事件。验收应分别看请求是否被接收、任务是否完成、文件是否真正可下载。页面刷新或连接断开后的表现，也应在设计中明确。

2. 让 AI 逐段实现，再用运行反馈推进

先交给 AI 当前子任务的目标、相关文件、接口约定、现有实现示例和验证方式。例如先实现任务提交接口及测试，再接前端表单，随后补进度显示和下载；不必在一轮对话里生成整个系统。

每次查看实际差异，运行与改动相关的类型检查、构建或测试，失败时提供错误、复现步骤和环境，而不是只说“再修一下”。需求调整后更新相应约定，避免前端与后端继续按不同假设开发。

重复的项目规则和操作流程可以沉淀为规范或 Skill；复杂到确需独立上下文时再拆子 Agent。它们都服务于交付，不是项目正式上线的必要标签。

3. 验收要跨过前后端边界

后端验证参数、权限、数据状态和异常，前端验证输入、加载、错误和重复操作等状态；再用浏览器实际跑一遍核心流程，检查界面展示与服务端结果一致。

研搜参考场景可以验证附件上传后任务能读取、完成后文件能下载、取消后不再启动后续步骤，以及错误能被页面正确展示。根据需求补充超时、依赖失败、刷新重连和跨用户访问等案例。预期来自业务规则和独立样例，不只依赖生成实现的同一个模型判断“应该没问题”。

4. 正式运行需要补哪些具体能力？

先把身份、会话、任务和产物归属关联起来，上传与下载按权限检查，外部服务凭证保留在后端。配置、依赖和构建产物可重复生成，准备合适的 HTTPS、进程启动、重启和日志机制。

长任务还要决定进程重启后能否继续、用户如何查询状态。研搜固定版用进程内字典保存活动任务，适合演示后台执行与取消；需要跨重启或多实例服务时，应把任务状态放入持久存储，并按需求采用独立执行器或任务队列。仅增加 worker 数量不会让这些内存对象自动共享。

发布时记录前后端、配置及相关 Agent 组件版本，先验证目标环境中的核心链路，再按风险逐步放量。观察任务成功、错误、延迟和资源消耗；回退需考虑数据与在途状态兼容，不能假定退代码能撤销已发生的外部操作。所需措施由业务规模和风险决定，不必一开始搭完整分布式平台。

常见追问

前端不熟，能否让 AI 全部完成？

可以让它参考已有组件实现，并用浏览器反馈迭代，但需要掌握页面状态、接口调用、权限和数据流，能判断实际行为是否符合需求。先打通小的完整流程，再逐步扩展，比只看代码截图更容易发现接口和交互问题。

AI 能接日志 MCP，是否就能自动完成线上排障？

日志工具能提供证据，后续还需定位请求、版本、依赖和实际状态。可以让 AI 在授权范围内分析并提出最小修复，用复现和回归验证；是否执行生产变更取决于已授权范围与发布策略，不能把“能读日志”理解成可以任意修改线上系统。

怎样说明自己具体做了什么？

沿一条功能链说清需求判断、架构分工、亲自处理的实现问题、如何用 AI 及如何验证。例如负责接口与前端事件状态对齐，就可以展开 started 与最终结果的区别、错误展示和取消流程。项目指标与实际部署范围按真实记录说明，参考方案用于解释设计选择。

对应教程

参考资料