项目开发思考与总结

应用概述

应用很简单，流程如下：

• 用户输入需求 → 大模型自动根据需求，构建comfyui提示词 → 触发comfyui出图 → 前端展示 → 滑动下一张，如果遇到不好的照片点击删除就可以了，快速形成自己的图片仓库。
• 目前程序还在本地git还没有上传到远程git，因为现在的部署门槛可能还是太高了
• 目前主要适配手机端，支持上下滑动查看高清大图，底部列表选择图片快速定位。
• 目前应用构建后除了大模型，其余可以完成本地化。
• 应用完成使用claude code搭建开发。

测试策略

测试工作主要还是我手动测试，从以前的程序员角色转换为用户后，发现一款应用要实际用起来，还是要用户参与，不然实际使用的时候还是会存在很多问题，因此前期产品交互这些角色在公司中其实还是比较重要的。

目前应用流程比较简单可以边写代码边测试，如果后面引入了新功能，很有可能引发新增或改动需求a导致b功能受到牵连，因此学习版本管理和一些设计模式，并且知晓什么时候用。

前后端单独测试，后端测试大模型自行完成即可，固化好入参和出参，划重点：一定不能使用mock数据进行测试，非常重要（⭐⭐⭐⭐⭐），前端用户自行测试，如果使用mcp浏览器自动化测试，目前不推荐。

配置参数设计

配置参数，考虑哪些是可配置参数，项目初期就要规划好，目的：

1. 统一配置管理：很多地方使用统一配置，一处改动处处改动，比如：大模型base_url、api_key等，包括增加一个llm_type如果对接2个及以上平台的时候就要考虑了，这里配合设计模式，后续新增大模型平台，不会对程序进行大改动。

2. 增加软件的适配能力：如：目前对接comfyui 工作流配置，如果自己使用写死就可以了，但是如果用户想引入自己的工作流呢？还要改动代码吗？前期或者遇到不同类型的流程的时候就要思考了。

以项目中实际的举例，输入：正向提示词、反向提示词，输出：图片，配置参数就需要考虑配置[正向提示词、反向提示词]的输入，在哪个node上。

设计模式的重要性

设计模式如此重要：

1. 代码组织

不要把大量代码放在一个文件里面，对于大模型来说看就像大海捞针一样，想象一下你发给大模型一段错误，发现错误发生在a文件，结果大模型想看下a文件代码到底怎么回事，结果read_file直接就把上下文撑满了（虽然现在主流的agent支持分段读取了,但还是不推荐,非常不利于代码维护）。

2. 降低耦合度

举例：解析用户需求输出为提示词，看似简单的需求，但这里我可能会先实现大模型对接的代码，然后再增加需求解析方法，并且我会单独一个目录来专门维护大模型的对接（openai、claude等因为他们的对接代码是不一样的），然后使用统一的方法def get_llm_by_type(type):获取通过传入不同的类型来获取指定的大模型实例，这里就会利用到配置参数来决定实际会使用到什么大模型了，然后在需求解析代码中引入get_llm_by_type实现解析转换提示词的功能了。

这有如下好处：

• （1）通过改变配置文件无需修改代码，就可以实现不同大模型的切换了
• （2）新增大模型配置不会改到之前的代码
• （3）代码复用，你能保证只有这里你会用到大模型吗？如果你将"解析用户需求输出为提示词"的需求放在一个代码文件里，下次又要用到大模型的时候又要来一遍代码，哈哈，你不就炸了吗？这就是我们说的屎山代码其中一中，在实际代码中我们能大量看到这种代码
• （4）同样也是有一处改动处处适配的特点

所以不要无脑让大模型傻傻的去干活了。

用户体验

最大可能性去提升用户的体验，把自己当作尖酸刻薄的用户，ai不会对你说no，如果现实中我会给产品说这个功能后面加，如果用起来了，大概这个功能永远也不会上了，但ai不会对你say no，我建议是把自己当成尖酸刻薄用户，又要把自己当成产品思考其他用户会怎么去使用这个程序，最后就是让更多人去使用程序，这些都是书本中没有的，相比于冰冷的代码，如何去"舔"用户，让他们"爽"才是你做东西最宝贵的财富。

MVP的重要性

mvp重要性，我们必须在最短时间验证我们的想法到底是否可行以及选用什么技术路线最好，当前非常流行规范编程，听我一句劝，作为一个普通人如果你直接用你只会白白浪费token，我的建议是先把可执行最小程序mvp做好，并且做好我之前说的版本管理、思考新增需求和修改需求的时候怎么对原来代码改动最小，做好代码规范，对于个人、小规模程序维护迭代而言，就已经足够了。

开发流程

迭代开发

我希望你也可以先实现mvp再嵌入到现有程序中，可以新建git分支完成。

Bug处理

对于顽固bug（ai总是修复不好的bug），先debug定位错误，然后新增test程序验证通过后再修复原来的代码，防止ai乱改，把本来正常的功能给改到了。使用ai编程的时候，在没有完全把握的时候尽量不要改动原来的代码。

版本管理

测试通过后及时提交git，完成一个比较健全可测试的功能后，及时测试，测试通过后形成清晰的commit日志，提交。这样在你下次迭代的时候如果出现了严重偏离你的预料的时候可以及时回滚，整合之前的问题，然后重新规划实现路线。

部署与运维

部署原则

记住一个原则：一键傻瓜式完成部署，绝不让部署成为阻碍用户体验程序的理由，什么依赖环境能自动下载就自行下载。这个可以让大模型帮助我们完成。

自动化流程

如果对自己要求再高点，引入github的actions，可以实现自动测试、打包、部署等操作流程。

版本记录

形成change log,让用户知道，你又引入了哪些好用的功能，修复了哪些bug，大家都会给你点赞的。

未来展望

随着体量的增加，开始考虑如何做数据库读写分离、分布式部署、微服务等，哈哈，幻想罢了。

技术发展思考

时代在进步，这几年变化太大了，从最开始代码补全到现在你可以放心把需求给ai，后面手撸代码可能会成为表演，不知道自己会不会被淘汰。目前来看，表面上都在拉低编程的下限，但是能提高专业人士的上限也是真的。

逆行人生中，男主被裁员，最后干外卖了，作为程序员出身的男主，为了方便找出最佳路线，做了款app，app被大厂看重，最后男主回归到程序员，但是哪些外面员还是外卖员。但我认为男主虽然是程序员但是如果他不跑外卖他就不会做出这个软件。离开了群众，离开了需求，技术本身真的值钱吗？但绝不推荐，认为没必要学设计模式、数据库、数据结构等计算机基础知识了。因为即使侥幸工作了，勉强用ai干了几年，只是产了几年的屎山代码罢了（就是我~）

希望程序员岗位不要只服务于办公室了，而是随着ai编程的发展，可以服务于每个人的各行各业。