一些作品
...小于 1 分钟
这是一个基于 uni-app 的麦当劳风格应用项目，包含前端和后端两部分。
项目地址：
Gitee
服务器配置：
阿里云ECS服务器-2g2核3Mbps
已备案已SSL加密
使用nginx进行反向代理
前端部分 (mdl-frontend)
使用 uni-app 框架开发（Vue），支持多平台部署（包括微信小程序）
使用了多个 uni-ui 组件（如 uni-popup、uni-icons、uni-number-box 等）
包含首页、详情页、个人中心等页面
前端 API 基地址配置为 https://639246942.xyz/mdl
...大约 1 分钟
一个用 (C++) C with class实现的控制台2D横板通关游戏（开源、目前已搁置）
项目地址：
Github
Gitee
编译指南：
在windows下
直接编译当前文件夹下的所有.cpp文件，运行生成的.exe文件即可
...大约 1 分钟
2023/10/13 17:04
- √ 1、背景的添加（可以分成上下两层，一个bg，一个map）
- √ 2、颜色在update时的改变，包括背景，前景，人物等
- √3、enemy的添加
- 4、加速度的添加（可以把纵向和横向的updatetime分开来写，以实现重力加速度和横向加速度的效果）
2023/10/14 13:09
- √1、把输入处理、更新游戏状态、渲染画面分开来写
- √2、把C语言的代码改为C++
- 3、把游戏状态改为枚举类型
- √4、状态机
...大约 18 分钟
- ✅ 购买域名：devenv.com.cn
- ✅ 域名备案
- ✅ SSL 证书挂载（阿里云免费证书）
- ✅ 服务器端口配置，个人网站和本项目同时运行
2025/7/14
- ✅ 前端显示问题需要修改
- ✅ 冗余文档删除，简单文档补充
- ✅ 文档归类
现在使用 agent 开发，能做到的事情远超我之前独立开发。
并不是 agent 在辅助我开发，而是我在辅助 agent 开发，因为 agent 的编码能力已经远远在我之上了。
这也导致了我的懒惰，和我在技术上的止步不前，要警惕这种情况。
当然，也许省出来的这部分精力，也让我提升了其它能力。
...大约 25 分钟
本项目从6月末想法初见，到7月12号写下第一行代码，时至今日，已经度过两个月的时间。
其中70％的内容，由augment code完成，15%的内容由copilot完成，5%的内容由我自己完成，剩下的10%由cursor、claude code、豆包平分。
最开始，我把想法告诉了豆包，让它给我生成了《DevEnv 智能开发环境部署工具：从策划到部署》，并丢给刚刚相识的augment code，由此迈出了DevEnv的第一步。
这是我在开发过程中汲取的教训
一、前期规划与文档建设的重要性
-
教训1：缺乏详尽的架构与设计文档，导致后期无序迭代
日志中多次提到“从一开始就没有规范的架构文档和设计文档”，导致功能“一点一点加、一点一点改”，后期维护困难。
👉 启示：项目启动前必须完成核心架构设计、功能边界定义和流程规范文档，避免“想到哪做到哪”。 -
教训2：未明确功能优先级，核心价值功能被忽视
开发后期才发现“核心功能（脚本安装和环境配置）未完成”，却花费大量时间在次要功能（如模板收藏、头像审核）上，导致产品核心价值缺失。
👉 启示：需通过“MVP（最小可行产品）”思路，优先实现核心功能，再迭代补充次要功能。
二、开发流程与规范的必要性
-
教训3：开发流程不规范，版本管理混乱
存在“更新代码无日志、commit信息随意、无规范的版本控制”，甚至“数据库修改未同步到初始化脚本”，导致部署时需重复调试。
👉 启示：必须建立规范的开发流程，包括提交日志规范、版本控制（如Git Flow）、数据库变更同步机制（如迁移脚本）。 -
教训4：多版本管理失控，增加维护成本
最初设想“开发版基于开源版”，最终演变为“两套独立代码”，导致维护成本翻倍。
👉 启示：多版本/分支设计需在初期明确依赖关系（如通过模块化、抽象层隔离差异），避免后期分裂。
三、工具与依赖的合理使用
-
教训5：过度依赖Agent（AI工具），导致自身能力停滞
日志提到“agent编码能力远超自己，导致懒惰和技术止步不前”。虽然工具提升效率，但过度依赖会削弱自身解决问题的能力。
👉 启示：工具应作为“辅助”而非“替代”，需保持对核心技术的理解和实践，避免沦为“工具操作者”。 -
教训6：过度依赖单一第三方工具，抗风险能力弱
因“augment锁区、插件停更”导致开发受阻，暴露了对单一工具的强依赖风险。
👉 启示：关键工具需预留替代方案，避免因第三方变动导致项目停滞。
四、环境与配置管理的疏漏
-
教训7：开发/生产环境隔离混乱，部署效率低
日志多次提到“开发环境调试日志未清理”“docker环境切换未系统化”“生产/开发/开源三套代码环境混乱”，导致部署时问题频发。
👉 启示：提前规划环境隔离方案（如通过配置文件区分环境变量、构建脚本分离），确保开发、测试、生产环境一致且可切换。 -
教训8：数据持久化与配置管理缺失
数据库文件未映射到宿主机，导致“容器重启丢失数据”；SSL证书管理分散（服务器路径与项目文件混杂），增加维护成本。
👉 启示：核心数据（如数据库、用户上传文件）必须通过容器卷映射到宿主机；配置文件（如证书、环境变量）需集中管理并纳入版本控制。
五、测试与问题跟踪的不规范
-
教训9：测试不充分，依赖“部署后调试”，效率低下
大量问题（如前端显示异常、接口500错误）在部署后才发现，本地调试不彻底，依赖“重启容器”排查，浪费时间。
👉 启示：建立本地完整测试流程（单元测试、集成测试），模拟生产环境验证，减少“部署即报错”的情况。 -
教训10：日志与问题跟踪分散，排查困难
日志分散在“与copilot/augment的聊天记录中”，问题列表不独立，导致“很多问题需要回头翻聊天记录”，排查效率低。
👉 启示：使用专门的问题跟踪工具（如Jira、GitHub Issues）记录bug和任务，日志需按模块、时间归档，避免依赖碎片化记录。
六、安全与部署的前置考量
-
教训11：安全意识薄弱，忽视基础安全措施
存在“注册无限制、缺乏防重复注册机制”“安全隐患多”等问题，且未提前规划服务器资源（如“服务器资源紧张需升级”）。
👉 启示：安全设计（权限控制、输入校验、注册限制）应与功能开发同步进行；部署前需评估服务器资源、网络安全（如SSL配置）。 -
教训12：部署流程不规范，数据与配置迁移困难
数据库初始化脚本未整合、容器部署未自动化，导致“新机器部署需手动调整”。
👉 启示：通过Docker Compose或CI/CD工具（如Jenkins）实现部署自动化，确保“一键部署”；数据库初始化脚本需包含全量必要数据。
七、版本与依赖管理的教训
-
教训13：依赖升级与兼容性考虑不足
因Spring Boot版本升级（2.7→3.4）意外解决了“500错误”，但未提前评估升级风险，说明依赖管理随意。
👉 启示：依赖升级需提前做兼容性测试，记录升级影响范围，避免“盲目升级靠运气解决问题”。 -
教训14：开源版与商业版的边界模糊，导致维护分裂
最初设想“开发版基于开源版”，最终因设计缺陷沦为“两套独立代码”，增加维护成本。
👉 启示：多版本开发前需明确“公共核心模块”与“版本差异模块”，通过抽象接口隔离差异，避免代码完全割裂。
这些教训覆盖了项目全生命周期（规划、开发、测试、部署、维护），核心可总结为：“前期规划定方向，流程规范保效率，工具依赖需理性，核心价值不偏离”。
...大约 7 分钟