从策划到上线，开发者用DeepSeek与Cursor协作完成微信记账小程序开发

一位独立开发者近期将名为「记账小助手」的微信小程序推进至可提审的 2.1.0 版本。该项目未依赖复杂技术栈，而是以微信小程序 + 云开发为基础，结合 DeepSeek、Cursor 与 Claude 等 AI 编程工具协同完成，总代码量约四万余行。其价值不在于功能炫技，而在于系统性呈现了当前阶段人机协作开发完整产品的可行路径与关键避坑点。

该小程序界面设计强调直觉交互：首页为月历形式，用户点击具体日期即可录入当日收支；支持创建「场景」（如结婚、带娃、旅行），并可选择是否纳入总账统计；预算、计划支出与实际收支严格区分——仅「实际」数据计入总账，计划项到期也不会自动转为支出，必须由用户手动确认发生。这些规则并非默认设定，而是开发者在早期策划阶段反复与 AI 对话厘清后固化为业务逻辑。

项目启动时，开发者并未直接写代码，而是先产出一份口语化但结构清晰的《策划.md》，列出 Banner、列表切换、婚礼礼金记录、AI 省钱报告、订阅消息等模块。然而初步开发即暴露出逻辑冲突：例如“前一天同步到后一天”可能引发重复记账；“场景预算同步至总收支”若直接累加，会导致首页支出虚高。于是他要求 AI 首先基于策划生成原型文档，明确各状态流转与校验规则。这一前置步骤避免了后期大规模返工，被其视为“最值钱”的决策。

在架构层面，系统采用典型云原生设计：前端为小程序页面，后端由三个云函数支撑——常规接口、定时任务与 AI 分析服务；数据库按用户隔离；DeepSeek 的 API 密钥仅存于云函数环境变量中，绝不暴露于前端包。这种设计保障了安全性与可维护性。

真正体现人机协作深度的是开发流程的分工策略。开发者将不同 AI 工具按能力匹配使用：

• Claude 与 Codex 主要用于文档审查与逻辑推演，例如逐条比对策划与原型间的矛盾点，或协助补全单元测试用例；
• Cursor 则擅长真机调试与界面微调，尤其在处理截图反馈时效率突出，例如根据“点击 A 期望 B 实际得 C”的问题描述快速定位代码偏差；
• 关键决策点（如“识图结果仅作草稿，需用户确认后才入库”）会被提炼为短笔记，供后续会话复用，防止长对话导致上下文丢失。

尤为关键的是对 AI 输出的审慎态度。开发者坚持一条底线：AI 识别或生成的内容，只能作为待确认的草稿。例如拍照识图识别出一笔“外卖 ¥42”，系统不会自动记账，而是在 UI 中提示“识别结果：外卖 ¥42，是否确认？” 用户点击确认后，该条目才正式写入数据库。此举杜绝了因识别错误导致账本污染的风险——一旦初始数据失真，后续所有分析都将失效。

功能迭代采取严格的版本控制策略：

• 1.0 版聚焦核心能力：基础记账、收支计算、场景与预算管理；
• 1.1 版增加分享导出、定时提醒与自动记账；
• 1.2 版引入 AI 省钱报告，由程序精确计算数据，模型仅负责语言组织；
• 2.x 版逐步集成语音输入、拍照识图及微信/支付宝账单导入，降低手动录入成本。

每一版本均明确标注“本版不做项”，如 Excel 导出、真 PDF 生成等，因其投入产出比过低而被主动砍掉。这种克制避免了 AI 因“功能丰富”倾向而引入冗余依赖。

在交互细节上，开发者坚守三项原则：

这一实践呼应了行业趋势：AI 赋能正从“单点工具替代”转向“上下文与规范构建”。正如《人人都是产品经理》所指出，当前阶段的核心挑战已非模型能力上限，而是如何建立稳定、可追溯、可验证的协作契约。开发者在文中总结：“跟 AI 合作，不是谁更聪明，而是谁更清楚边界。”

值得注意的是，该案例并非孤例。腾讯近期推出的「企鹅微单」平台，同样强调 AI 创作者需在明确需求上下文内接单，并通过微信内结算闭环保障交付质量。这表明，无论是个体开发者还是平台级生态，AI 辅助开发的成熟路径正在收敛于“规范先行、责任清晰、人控关键节点”三大共识。

目前「记账小助手」已进入提审阶段，其开发过程未依赖外部团队，全程由一人主导、AI 协同完成。该实践为中小型产品团队提供了可复用的方法论：在资源有限前提下，通过强化前期设计、分阶段验证与工具合理分工，可显著提升 AI 辅助开发的可靠性与交付效率。未来随着更多类似工具链（如 TeamAI 等协作框架）落地，人机协同开发或将从“高阶技巧”变为标准工作流。