「邻里车位」小程序参赛贴
【Code With SOLO】用 Trae Solo 10 天独立开发上线一个微信小程序，解决小区停车难问题
一、摘要
用 Trae Solo 从零开发了一个微信小程序"邻里车位"，实现小区业主发布空闲车位、访客在线预约停车、时间自动匹配与冲突检测。原本需要前后端配合、至少 2-3 周的工作量，我用 Solo 模式 10 天独立完成开发、测试、上线准备，代码量 8000+ 行，覆盖 15 个页面。
二、背景
我是一名开发者，所在小区停车位紧张，业主经常有空闲车位时段浪费，而外来访客找不到临时停车位。小区物业没有提供数字化管理工具，业主和访客之间信息不对称。
具体挑战：
- 需要快速开发一个小区内部使用的车位共享工具
- 涉及多种角色（业主、访客、管理员）的权限管理
- 时间匹配逻辑复杂（需要判断时段冲突）
- 必须符合微信小程序隐私审核要求
- 个人开发，没有后端团队支持
为什么选 Trae Solo：
- 想验证 Solo 模式下一个人能否独立完成完整项目
- 需要 AI 辅助处理重复性代码和页面结构
- 希望快速迭代，边做边改
三、实践过程
3.1 任务拆解
我把项目拆成 6 个阶段，按优先级逐步推进：
| 阶段 | 内容 | Solo 辅助程度 |
|---|---|---|
| 1. 需求分析 | 写需求文档、设计角色权限 | 80% AI 辅助 |
| 2. 基础框架 | 创建项目结构、tabBar、全局配置 | 90% AI 生成 |
| 3. 核心页面 | 首页、登录注册、车位发布、车位预约 | 70% AI 生成 + 30% 手动调整 |
| 4. 业务逻辑 | 时间匹配、冲突检测、过期过滤 | 50% AI 辅助 + 50% 手动编写 |
| 5. 合规审查 | 隐私政策、用户协议、角色权限过滤 | 60% AI 辅助 |
| 6. 测试优化 | 单元测试、错误处理、UI 优化 | 40% AI 辅助 + 60% 手动 |
3.2 用了 SOLO 哪些能力
Spec 模式（规范驱动开发）：
- 用
/spec命令创建 spec.md、tasks.md、checklist.md - 每个功能先写规范再编码，避免返工
- 累计创建了 20+ 个 spec 文档，覆盖了：
- 上线前优化（pre-launch-optimization）
- 隐私合规（simplify-privacy-hide-longterm）
- 角色权限（role-permissions-expiry-filter）
- Bug 修复（fix-bugs-optimize）
Agent 模式（快速迭代）：
- 用搜索工具快速定位代码问题
- 批量修改文件（如统一更新小程序名称、隐私政策同步）
- 单元测试代码生成
3.3 关键操作过程
示例 1：首页角色权限过滤
需求：业主看到全部功能按钮，访客只能看到"预约临停车位"
我的 prompt：
/spec 根据业主、访客角色重新优化能看到的菜单和功能按钮，
访客无法发布和申请、查看长租车位，只能预约临时车位、查看自己预约、匹配结果
Solo 输出：
- 创建了完整的 spec.md，分析了影响范围
- 生成了 tasks.md，明确任务依赖关系
- 实现了 wx:if 条件渲染逻辑
- 更新了 checklist.md，逐项验证
示例 2：隐私合规审查
需求：小程序要符合微信"未采集用户隐私"要求
我的 prompt：
/spec 检查代码，整理是否还有涉及用户隐私的内容，使用了哪些用户隐私。
需要符合微信小程序中"用户隐私保护指引设置"的"未采集用户隐私"
Solo 输出：
- 全面扫描了所有 JS/WXML 文件
- 列出了 15+ 个隐私 API 的检查清单
- 确认无调用任何微信隐私接口
- 更新了隐私政策文档，明确"不采集"声明
示例 3：过期车位自动隐藏
需求：临停车位和长租车位过期后自动不展示
我拆解了任务，让 Solo 创建了 utils/expiry.js 工具函数：
isExpiredTemporary()— 判断临停车位是否过期isExpiredLongterm()— 判断长租车位是否过期filterExpiredParks()— 过滤过期车位
3.4 踩过的坑
坑 1：requiredPrivateInfos 配置错误
一开始在 app.json 里加了 "requiredPrivateInfos": ["chooseAvatar"]，真机调试直接报错：
requiredPrivateInfos[0] field needs to be chooseAddress,chooseLocation...
解决： requiredPrivateInfos 只接受位置相关 API，chooseAvatar 不需要在此声明。最终完全移除了这个字段。
坑 2：隐私政策与实际不符
最初隐私政策里写了"收集您的昵称和头像信息"，但代码已经改成了用户自愿填写，导致审核不通过风险。
解决： 重新审查代码，更新隐私政策，明确声明"不通过微信隐私保护接口采集任何用户隐私信息"。
坑 3：时间匹配逻辑
临停车位的时间判断需要考虑：
- 开始日期不能早于当前日期
- 结束时间必须晚于开始时间
- 自动计算 8 小时后的默认结束时间
手动写了 3 版都有 bug，最后让 AI 辅助写了 autoAdjustEndTime() 函数，一次性解决。
四、成果展示
项目截图
项目架构
邻里车位/
├── app.js # 全局入口
├── app.json # 全局配置
├── pages/
│ ├── index/ # 首页（角色过滤功能按钮）
│ ├── profile/ # 我的页面（角色过滤菜单）
│ ├── visitor/ # 车位申请
│ ├── parkowner/ # 车位发布（业主）
│ ├── longterm/ # 长租车位
│ ├── register/ # 注册/完善信息
│ ├── match/ # 匹配结果
│ ├── history/ # 历史记录
│ ├── admin/ # 系统管理（管理员）
│ ├── feedback/ # 意见反馈
│ ├── privacy/ # 隐私政策
│ └── useragreement/ # 用户协议
├── utils/
│ ├── cloud.js # 云开发封装
│ ├── expiry.js # 过期判断工具
│ ├── validation.js # 表单验证
│ └── privacy.js # 隐私授权管理
└── __tests__/ # 单元测试
核心功能
-
角色权限系统
- 业主：发布临停/长租车位、管理车位
- 访客：预约临停车位、申请车位
- 管理员：查看全部数据、系统管理
-
时间匹配与冲突检测
- 自动判断时段是否冲突
- 过期车位自动隐藏
- 智能推荐可用时段
-
隐私合规
- 无微信隐私 API 调用
- 所有信息用户自愿填写
- 完善的隐私政策和用户协议
-
云开发 + 本地存储双模式
- 支持微信云开发
- 云不可用时自动降级到本地存储
代码统计
| 指标 | 数据 |
|---|---|
| 页面数 | 15 |
| JS 文件 | 20+ |
| 代码行数 | 8000+ |
| 单元测试 | 50+ |
| Spec 文档 | 20+ |
| 开发周期 | 10 天 |
五、效果与总结
提效对比
| 工作项 | 传统方式 | SOLO 模式 | 提效 |
|---|---|---|---|
| 页面搭建 | 2 天/页 | 0.5 天/页 | 75% |
| 样式编写 | 手写 CSS | AI 生成 + 微调 | 60% |
| 单元测试 | 手动写 | AI 生成 + 补充 | 50% |
| 隐私合规审查 | 逐文件检查 | 批量扫描 + 报告 | 80% |
| 整体开发周期 | 2-3 周 | 10 天 | 50%+ |
SOLO 在我流程中做了什么？
- 规范驱动开发 — Spec 模式强制先想清楚再写代码，减少了 70% 的返工
- 代码生成 — 重复性代码（页面结构、表单、列表）直接生成，我专注业务逻辑
- 批量操作 — 统一修改文件名称、同步隐私政策等，一键完成
- 问题定位 — 用搜索工具快速找到问题代码，不用手动翻文件
可复用的方法
- 先写 Spec 再编码 — 即使是小项目，花 5 分钟写清楚需求再动手，效率反而更高
- 按角色拆分权限 — 业主/访客/管理员的权限用
wx:if条件渲染，清晰易维护 - 工具函数集中管理 — 过期判断、表单验证等逻辑放在
utils/目录，多处复用 - 云 + 本地双模式 — 核心逻辑不依赖云开发，云不可用时自动降级
思考
SOLO 不是"一键生成项目"的工具，而是一个思考放大器。它不会替你决定业务逻辑，但能帮你把想法快速落地。最大的收获是：当你清楚知道要什么的时候，Solo 的效率是惊人的；当你自己都没想清楚的时候，Solo 也帮不了你。
小程序名称： 邻里车位
一个人，10 天，一个完整的小程序。Solo 模式让我验证了：AI 辅助编程不是未来，而是现在。