怎么用AI写2000行的大作业

Haibin
Computer Science
2025-11-16
778 Views
0 Comments
1912 Words

2026年3月16日更新：

看看这篇文章：

从 FAST26 SPECFS 看新时代 infra 开发者工作范式 - SPtuan的文章 - 知乎
https://zhuanlan.zhihu.com/p/2015537008425055371

人类已经丛底层编码走向编排者角色。我们需要编排agent去建立完善的控制体系。

最近分布式课程有一个作业。作业内容是要写一个商城的后端。商城消费者通过网页API访问/消费商品，后端商品数据库有CRUD、产品消费消息订阅服务。分解开来，要有OpenAPI Service后端接口服务，Database Service数据库服务和logging Service日志服务，3个微服务全上docker，工程量2000-3000行python。

这个作业在我与GPT、Deepseek的配合下，一个晚上6小时写完，并且我基本没有碰代码，完全指挥AI写，最后API都对上，完全能工作。可以说AI真的是大大增强了生产力。同时我发现，如何使用AI也是非常重要的，如果直接把作业文档传给AI，AI的力量就完全没发挥出来：要么写的代码不全，要么就是API不对。

通过这次作业我想总结：怎么用AI写大作业/大系统？

首先我得出一个工程结论，哪怕是一个2000行的系统工程，直接让AI生成完整全对的代码还是有点困难的。比如假如有一天NASA告诉AI：“请你帮我生成阿波罗计划，要求是送三个人类往返月球，帮我生成土星五号、登月舱、返回舱、指挥舱、控制系统的全部图纸和代码，帮我完成所有的计算。”这听起来有点搞笑了，并且如果AI真的生成了，NASA敢用吗？其实人也一样，一个资深的软件工程师也不敢一次性就能给你输出完整的复杂系统代码。他们一定是一步步迭代出来的。

因此，核心在于“让AI一次只专注一件小事情”。 经过几次尝试后，我的操作是这样的：我是工程总指挥，负责管理各个AI+文档，同时做测试；“计划AI”负责读取任务文档，并将大任务分解为多个小任务；“接口AI”负责理解与处理后端数据的接口（比如登录服务怎么生成JWT，登录的密码是什么数据类型）；“数据库AI”负责生成数据库代码（如连接池、gRPC），并提供文档；“日志AI” 负责日志服务；“docker AI”负责将服务打包上云；“运维AI” 负责解答我的随机运维问题，“决策AI”负责辅助我具体的决策（比如修改密码/user/me接口要不要输入密码还是用JWT），“测试AI”负责自动化测试的代码。

我的6小时大概可以非常几个步骤：

1. 计划

我首先将作业文档发送给了AI，然后说，“请你分析一下我们这次作业要干什么，主要完成哪些服务。”然后AI帮我分析了下。接着问“请你帮我生成一个合理的工程计划表，先完成什么，然后完成什么。”

随后“计划AI”就帮我写下了整个计划：

明确所有从前端输入来的OpenAPI （“接口AI”负责）
生成对应的OpenAPI YAML，并生成对应的FLASK/GO BIN代码（“接口AI”负责“）
完善后端PostgreSQL数据库的CRUD代码（”数据库AI“负责）
完善PG与FLASK的gRPC Proto，并生成PG端的gPRC代码（”数据库AI“负责”）
完善FLASK到PG的gRPC通信代码（“接口AI”读取”数据库AI“生成的文档）
完善日志服务，对接Kafka；随后完善日志与FLASK的gRPC通信（“日志AI”负责）
三个服务上docker的docker compose代码，配置PG与Kafka的代码（“docker AI”负责）

2. 接口API

AI最容易错的是API。比如一个商品有“price”、“amount”、“name”等7-8个数据类型，但是作业文档里给的很含糊。这些API必须是人为钉死的。因此我亲力亲为，做了数据类型的API：

when clients come into the webpage, they can see & view the page and products:

RESTful API	Method	Description	Need Passwd?	Need JWT?	Return
/	GET	Greeting	❌	❌	"Hello!"
/products	GET	List products	❌	❌	All Products
/products/{id}	GET	Get product	❌	❌	Product

For every products, they should have:

Feature	Data type
`id`	key int
`Name`	string
`Description`	string
`Category`	string
`price`	DECIMAL
`slogan`	string
`stock`	int
`created_at`	time

To place orders, the client have to register an account in the system. The following API can help them deal with their account information with register, login, getting profile, update profile and delete account:

RESTful API	Method	Description	Need Passwd?	Need JWT?
/users/register	POST	Register	✅	❌
/users/login	POST	Login	✅	❌ (login will generate JWT)
/users/me	GET	Get my profile	❌	✅
/users/me	PATCH	Update my profile	❌	✅
/users/me	DELETE	Delete an account	❌	✅

Every user can see their Profile info :

User	Data type	Can be seen?	Changeable?
`id`	int	✅	❌
`username`	string	✅	✅
`email`	string	✅	✅
`sid`	string	✅	❌
`created_at`	time	✅	❌
`password`	string	❌	✅(Change hash in db)

这里这些API和参数都要详细定义好，以确保AI能理解+生成完全正确的代码。
生成好OpenAPI后，就能自动生成FLASK框架。但是此时代码没有接到后端，怎么验证？

3. 单元测试

“目前FLASK是生成好了，请你写一些dummy code，验证API的有效性。”

很明显，让4-5个AI全部开发完，再进行验证，这样太冒险了，并且开发者一定对中间过程是一窍不通的。因此一定要有dummy code，比如说 /products 访问的数据库后端的商品然后返回这些数据，那么在没有数据库情况下，我们可以先直接 return product(XX,XX,XX) ，假装已经完成。这样，一个个完成单元API测试。之后遇到bug来了，AI都可以更好的定位问题。

4. 数据库

基本上确定了数据库的表，就能让AI自动生成代码了。
记得做好防SQL注入就行。我们可以先出CRUD代码，再防注入。

5. gRPC：例子/文档

gRPC的通信很特殊。由于我们的开发宗旨是“让AI一次只干一件事”，而gRPC涉及“接口AI”和“数据库AI”生成的代码，我的操作是这样的：

在数据库AI生成了CRUD代码后，我说：

“请你就这个数据库代码，生成一个gRPC框架来操作数据库。要求你必须给一个client连接例子。”

随后“数据库AI”会给出gRPC代码+gRPC例子。随后，我们把这个gRPC例子喂给“接口AI”，作为文档，然后让它自动生成gRPC通信代码。

这里，文档发挥了至关重要的作用，AI在有这种连接例子的情况下，成功率大大增加。

6. AI自动化测试

把给”接口AI“的文档喂给“测试AI”，其生成了自动化测试代码，然后每次其他AI修改后，跑一次测试。

总指挥的职责

决策：数据库用连接池还是简单连接，哪个服务要不要上docker，哪些API要加密加盐
纠正幻觉：有时有的AI出的代码会出bug，要纠正它
查看效果：及时检测效果是否和需求一致

“运维AI”负责找出docker 或者机器的环境文章，“决策AI”辅助决策。

总结

从这点来看，AI基本上可以完成大部分的底层工程。但是其实这个过程中，人类还是要非常清楚自己在干什么，比如数据库连接池，API数据类型等，只有非常清醒，才能完成工作，不懂的人还是做不了。