先说结论
我用 AI 辅助编程工具（Trae IDE） ，2 天内从零搭建出了一个生产级的卡路里追踪系统：
- ✅ 微信小程序端（拍照识别 + 手动记录 + 统计分析）
- ✅ Web 管理后台（食物库管理 + 用户管理）
- ✅ 后端 API 服务（30+ 接口 + AI 视觉识别）
- ✅ 179 种食材数据库 + 营养数据 + 图标
- ✅ 90 个自动化测试用例 + 36 条踩坑文档
总代码量 13,500+ 行，我没有手写一行代码。
这不是标题党，下面是我的完整工作流程和真实体验。
我的产品需求是什么样的？
作为产品经理，我用产品语言描述了需求，而不是技术语言：
核心用户故事
作为一个关注健康饮食的用户，
我希望拍一张照片就能知道食物的热量和营养成分，
以便记录每日摄入、控制饮食目标。
我给 AI 的需求清单（原文）
1. 用户拍照或选择图片 → 调用AI识别是什么食物、大概多少克
2. 识别结果确认后 → 自动记录到当日饮食日志
3. 支持手动添加食物（搜索食材库，输入份量）
4. 每日汇总：早中晚加餐四餐热量 + 三大营养素
5. 历史趋势：近7天/30天摄入曲线
6. 食材库：179种常见食材，含完整营养数据
7. Web后台供管理员维护食材和管理用户
注意：没有一行技术术语。没有说"用FastAPI"、"RESTful"、"SQLAlchemy"。只有我要什么功能。
我的日常工作流：PM × AI 协作模式
第一步：让 AI 出技术方案
第二步：按模块逐个提需求，AI 写代码
这是我最核心的工作方式——把 PRD 变成对话：
第三步：AI 帮我排查问题（这是最爽的部分）
作为 PM，我实际做了哪些事？
说实话，不是完全不动手。我做的事情更偏向"产品侧"
需求拆解与描述：40%，把功能拆成 AI 能理解的需求卡片；
UI/UX 设计决策：25%，决定布局、配色、交互流程
验收测试：20%，
暂时还没找到很好的和AI协同做功能测试的方案，目前AI仅帮我做接口测试和写测试用例
文档整理：10%，让 AI 输出踩坑文档、测试报告，统一整理项目资料库
服务部署：5%，同样使用AI将服务部署到线上，AI让我免去了运维的烦恼
项目最终交付物
功能清单
📱 微信小程序（8个页面）
├── 首页 今日热量圆环 + 四餐快捷入口
├── 拍照识别 相机拍照 → AI识别 → 一键记录
├── 手动添加 搜索食材库 → 选食物 → 输入份量
├── 历史记录 按日期查看 + 按时间排序 + 图片展示
├── 每日日记 四餐详情 + 营养素饼图
├── 统计分析 7天/30天趋势 + 热门食物
├── 食材库 左右分栏 + 179种食材 + SVG图标
└── 个人中心 目标设置 + 历史概览
💻 Web管理后台（6个页面）
├── 仪表盘 数据概览
├── 食物管理 CRUD + 分类筛选 + 批量导入
├── 用户管理 用户列表 + 权限管理
├── 记录管理 全量记录查看
├── API配置 智谱AI密钥管理 + 连接测试
└── 审计日志 操作记录追踪
⚙️ 后端服务（30+ API）
├── 认识模块 图片上传/AI识别/热量计算
├── 食物模块 列表/搜索/分类/CRUD
├── 记录模块 创建/更新/删除/查询
├── 统计模块 概览/趋势/热门
├── 用户模块 登录/信息/权限
└── 系统模块 健康/清理/配置
项目截图：
这套工作法的核心方法论
方法论：PRD → Prompt → Preview → Iterate
PM 使用 AI 编程的 5 条经验
1️⃣ 需求越具体，AI 输出越准确
❌ "做个登录功能" ✅ "用户通过微信一键登录，获取昵称和头像，后端创建或更新用户记录，返回 user_id 和 token 用于后续鉴权"
差距：后者包含了边界条件（重复登录怎么办）、数据格式（返回什么字段）、安全考量（token机制）。
2️⃣ 一次只提一个功能点
不要一口气丢 10 个需求。我一个文件一个文件地让 AI 做：
- 先做 app.json 配置
- 再做 config.js 环境
- 然后 api.js 封装
- 最后才做业务页面
原因：上下文越小，AI 越不容易出错。
3️⃣ 让 AI 解释它写的代码
每次 AI 生成代码后，我都会问一句：
"这段代码的逻辑是什么？有哪些需要注意的地方？"
这让我能：
- 理解代码在做啥（即使不看代码）
- 发现潜在问题（AI 自检时会暴露）
- 积累知识（下次能自己判断类似问题）
4️⃣ 踩坑文档是团队资产
每遇到一个问题，我都让 AI 记录下来。现在项目里有 PITFALL.md，包含 36 条踩坑记录。
下次遇到类似问题，直接问 AI："参考 PITFALL.md ，检查当前代码有没有这个问题"。零重复踩坑。
5️⃣ 保持"产品思维"，不要被技术带跑
AI 有时会过度工程化。比如它想给我加 Redis 缓存、消息队列、Docker 部署……
我会拦住："MVP 阶段不需要，先跑通主流程。" —— PM 的职责是控制范围，不是追求技术完美。
这种方式适合谁？不适合谁？
✅ 适合
- 产品经理 / 业务方：有明确产品想法但不会代码
- 独立开发者 / 创业者：需要快速验证 idea
- 学生 / 初学者：想学全栈但不知道从哪开始
- 内部工具需求：公司内部小工具，不值得排研发资源
❌ 暂时不适合
- 高并发 / 高可用系统：需要专业架构师设计
- 涉及硬件 / 底层系统：AI 对物理世界的理解有限
- 需要长期维护的企业级应用：代码质量需要专业 Code Review
- 团队协作的大项目：多人开发需要统一的编码规范和流程
一个 PM 的真心话
vibe coding最大的问题是不知道自己想要什么。
一旦你能清晰地说出"我要什么"，AI 就能把"怎么做"这件事做得比你想象的好。
当然，这不意味着 PM 可以完全替代工程师。好的工程师做的架构决策、性能优化、安全防护，是 AI 目前做不到的。
但在 0→1 的阶段——从一个想法到一个能跑的原型——PM + AI 的组合，已经足够强大。
如果这篇内容让你有所启发，欢迎点赞收藏！
后续我会持续分享：
- PM 如何做技术选型（不靠猜，靠 AI 分析）
- 如何用 AI 做竞品分析和需求挖掘
- 从 MVP 到正式产品的迭代经验
#产品经理 #AI编程 #无代码开发 #微信小程序 #TraeIDE #产品交付 #MVP
