我是一名经济学专业的学生，也是“数智星图”校园服务平台的负责人。面对高校后勤报修中普遍存在的 “责任边界模糊、派单耗时数小时” 等痛点，我利用 TRAE SOLO 独立端的 Code 模式，全程以自然语言对话的方式，独立完成了整个 Web 管理后台 及配套移动端核心功能的开发，并成功上线。
SOLO 独立端帮我 零代码 从 0 到 1 快速完成了核心交互落地，特别是 智能派单规则引擎 这部分逻辑的代码生成。整个 前端交互与后端逻辑的构建 大幅提效，让我能把更多精力放在打磨业务逻辑和优化用户体验上。
我并没有一股脑把需求丢给 SOLO，而是按模块循序渐进：
第一阶段：需求交底
我将 项目书 和 API 需求文档 粘贴到工作区，并 Prompt：“请通读项目书，我是经济学专业，完全按照提供的 API 设计初稿来开发。你需要记住 八大业务模块 和 六类角色 的功能。”
SOLO 深度理解了复杂的业务模型与权限矩阵，构建出了完整的功能认知。
第二阶段：智能派单引擎（最硬核的核心）
这是项目的核心亮点，SOLO 帮我设计了 “四维加权评分模型”：
-
责任归属知识图谱（维度1） ：让 SOLO 处理 156 条历史报修数据，自动识别故障类型→责任部门。
-
负载均衡（维度2） ：查询维修人员的当前积压工单数。
-
紧急程度（维度3） ：根据报修源（教室/宿舍/食堂）加权。
-
地理距离（维度4） ：匹配离故障点最近的空闲师傅。
坑点 1：后端数据逻辑的一致性
最初生成后端接口时，SOLO 对 Node.js 和 Python Flask 的部分异步处理稍有差别，导致“智能派单”接口在高并发调度时偶尔超时。我加上 Prompt：“把这部分逻辑改为同步队列处理，并增加 redis 缓存层”，SOLO 立刻自我修正，重新生成了更稳定的代码块。
坑点 2：跨端 API 路径的严格适配
小程序端与 Web 管理后台共用一套后端，初期总报 request:fail url not in domain list 错误。
Prompt：“全面检查微信小程序的合法域名配置，并生成全局请求封装代码，务必加上超时重试机制”。
SOLO 立刻为我生成了一个极为健壮的 api.js 封装文件，报错率大减。
技能调用
我还使用了 SOLO 3.0 的 技能库（Skills） ，在生成复杂的表格管理后台时，调用了 TDesign Skill（企业级 UI 组件库技能） ，让 Web 后台的表格、表单、数值面板直接具备了高度美观的中后台界面风格。在排查小程序登录报错时，还调用 Claude Code Debugger 技能精准定位了“真机调试与模拟器环境差异”导致的参数断裂问题，快速解决了 Bug**-25**。
4. 成果展示
经过数轮“对话-生成-纠错-迭代”，数智星图校园服务平台 顺利诞生：
-
Web 管理后台：覆盖 智能报修、考试通知、空教室与失物招领、卫生/违规电器/访客管理等八大模块，包含直观的数据驾驶舱与维修人员绩效看板。
-
微信小程序：师生无需下载，扫码报修、自动定位、进度追踪、故障拍照一应俱全。
-
智能派单引擎实测：将传统 4-6 小时的派单流程优化为 分钟级自动流转，维修师傅接单准确率从 60% 提升至 90% 以上。
你可以通过 Web 端查看实时看板，或使用小程序扫码提交报修，真实感受 AI 驱动的极速流转。
从 2 个月到 1 周：对于非技术出身的我，过去用传统模式可能连开发环境都搭不起来。现在 TRAE SOLO 直接充当了我的全栈技术合伙人。我只需关注业务痛点（比如责任归属不清），具体的 SQL 建表、异步派单逻辑、API 路由等，完全交给 SOLO。
“喂数据，而非只给文字” 是利用 SOLO 开发复杂业务系统的关键。如果我只是口头描述“我要智能派单”，SOLO 会按大众模板生成。但我把 156 条真实报修记录 传给它，加上一句 “分析这些数据的责任归因规律，并生成派单算法”，它就自主掌握了本校园独有、不可复制的最佳实践。
TRAE SOLO 不是让程序员下岗，而是让有想法、懂业务的人，拥有了亲手解决实际问题的超级能力。
