之前用AI协助开发了一个Vue模块，感觉意犹未尽，所以决定再让AI 来协助我做一个todo list。
todo list对我来说真是一个刚需，从我决定做一件事情，到这件事情做完，我的todo list不但不会减少，反而会增加。
回来说说应用AI这件事情。我之前使用AI的量和现在比，相对要少很多，其中一个原因是我之前对那些技术细节很"熟悉"，使用AI帮忙写代码总是有隔靴搔痒的感觉。我对Vue的了解细节相对于React要少一些，因此，在应用AI上，感觉思想上的排斥要少很多。
这次，我打算在Rust上继续尝试使用AI，从1月29日开始，到2月7日，完成todo list的开发工作。
为什么是这段时间？因为这段时间是旅行时间，白天都在外拍照打卡，只有晚上才有时间来写代码，我要的就是要尽量压缩自己写代码的时间，更多让AI来下场写代码。
今天是2月7日，这个todo list应用的开发工作基本完成，此刻，我正在珠海金湾机场写这篇博客。
todo list的应用gitee 地址：https://gitee.com/hanshu_alan/todolist/tags
开始正文，来谈谈我的感受。首先，我发现我是比较适合这么干的。回想10多年前，我做tech lead时，我会将项目拆分成多个尽量简单的小任务，将这些小任务分配给组内的开发者。我记得我在做项目任务拆分时，不只是简单的拆分，还会考虑设计模式，并且还会经常先完成一些框架代码。因此，从接到项目到项目开始的这一小段时间里，我会非常忙碌。当任务分配出去之后，我又会感到轻松许多。
这段经历和我现在使用AI的体验特别像，最显著的区别是之前我是和人沟通，而现在我是同AI沟通。
在我让AI来帮忙写代码时，我也在体验另外一个大家的关注的问题，即AI能否代替程序员？对于这个问题的内省与体验，我目前的答案是"能"和"不能"。
说"能"，我想不用我说，很早就有人用AI生成正则表达式的相关功能代码，从这个角度来说，AI 已经替代了程序员的工作了。我也晒晒我在开发todo list使用到的prompt
bash
帮我创建一个Rust的yew组件，这个组件包含一个多行文本框和一个按钮。按钮上显示的文本是"添加"，点击按钮时，会出发on_add_todo事件，on_add_todo事件传递的参数时文本框的当前值。在文本框上，当用户按下"ctrl+enter"组合健时，也要触法on_add_todo事件。
这个组件也包含一个属性，这个属性的值用于多行文本框的value值
bash
使用Rust的sqlx框架，基于下面这个实体的定义，以owner_key为条件，返回所有满足该条件的实体，实现的代码中，要使用sqlx::query_as::<_, TodoItem>
#[derive(Debug, PartialEq)]
pub struct TodoItem {
id: String,
owner_key: String,
title: String,
description: Option<String>,
finished: bool,
created_at: DateTime<Utc>,
updated_at: DateTime<Utc>,
}这两个prompt比较有代表性，一个是前端的，一个是后端的。AI都能生成代码，或者从一个程序员的角度来说，AI都能把代码写出来。因此，说AI"能"代替程序员是有道理的，甚至可以激进一点说，AI已经能代替程序员了。
但是，这些代码并不能直接使用，就拿使用的yew框架来说。我现在使用的是yew 0.21版本。而AI生成的代码，应该是基于0.18的yew的版本。也就是说，AI帮我生成的前端代码几乎不能直接使用，还要我自己翻译一遍。另外，当我需要把代码组装时，这些地方还是需要我自己亲自下场。这倒不是说AI不能干，而是这里的业务逻辑比较复杂，它本身就是一个黑洞，需要开发者本身去探索，因此，自然也不知道该如何告诉AI了。因此， 从这个角度来说，AI是代替不了程序员的。嗯，不对，可能不能再用"程序员"这个称呼，我觉得"开发者"或者"创造者"更合适。
写到这里，我感觉到了一个更加宏伟的蓝图。
如果你稍微留意一下todo list v0.0.3的代码，你会发现它是比较臃肿的，因为，这个版本只是通过组装AI写出来的代码，完成了功能的开发。它的可维护性是比较低的，还需要继续迭代。而这个迭代的需求来源于我们对未来的探索。
最后，我说明一下文中提到的"AI"，我使用的是"文心一言"和"ChatGPT-3"。
欢迎大家留言区交流。
2024.2.7 珠海.金湾机场
这篇文章收录我的Rust-实战专栏。请关注我，不要错过更新哟。