当我不得不在假期免费工作……而客户还是我妻子 😄

有些客户，你会和他们谈报价、工期和项目范围。还有另一种客户：他们知道你住在哪里，知道你的假期安排，还能在你休假的时候非常自然地告诉你：“这不就是一个小网站嘛。” 对我来说，这位特别难搞的客户，就是我妻子。😄

今年暑假，Eva 想做一个网站，用来发展她的物理治疗业务，同时提供在线视频形式的适应性体育活动。最初的需求听起来甚至有点轻松：几页业务介绍、一个联系表单，再加一页介绍线上课程。

换句话说：一个小型展示网站。那种开发者会觉得“晚上抽几个小时就能搞定”的项目。

当然，事情完全没有按这个方向发展。

01最危险的客户：和你住在一起的那位

我原本以为，这么多年过去之后，Eva 至少已经理解我工作中的一个基本原则：当我要求一份完整的需求说明时，并不是为了用文档和会议折磨客户。

需求不完整，并不会因为已经开始写代码就自动消失。它只会在稍后重新出现，而且通常是在最糟糕的时候：技术方案已经定了，而每一个“再加一个小功能”都会顺便推动另外三个功能一起变化。

所以剧情非常经典：“先把我的业务介绍一下就行”，然后变成“最好还能让用户预约”，接着是“那他们得能付款”，然后“是不是还需要一个账号”，最后就是“那我自己怎么管理课程？”

几轮迭代之后，这个“小型展示网站”非常安静地决定把自己升级成一套应用。

02从展示网站到真正的业务应用

随着需求逐渐被梳理清楚，Mumkine.fr 的实际范围也变得越来越大。

现在，这个项目已经包含多块功能：

• 公开网站：介绍业务、服务内容、服务区域以及线上活动。
• 联系表单：让用户能够针对物理治疗服务快速联系。
• 用户空间：身份验证，以及访问相关活动所需的信息。
• 日历：发布并查看可参加的课程。
• 在线预约：报名课程、管理名额以及完整用户流程。
• 在线支付：为相关活动集成 Stripe。
• 管理后台：管理课程、用户、内容以及日常运营。
• 事务邮件：统一通过我已经熟悉的 mailcow 基础设施发送。
• 博客：发布与项目和业务相关的实用内容。

公开网站还清楚地区分了两个不同路径：一边是法国伊夫林地区的围产期物理治疗，另一边是可以在线参加的适应性体育活动。

这听起来只是一个小细节，但其实非常重要。当一套应用开始承载多种业务时，最好不要把所有用户都塞进同一个巨大的流程里。业务规则、支付方式和所需信息并不一定相同。

03一个悖论：用 AI 规划一个由 AI 辅助开发的项目

这个项目真正有意思的地方在于，我们在两个完全不同的层面使用了人工智能。

第一个层面不是开发，而是需求梳理和项目范围定义。

在要求 AI 生成文件、路由、数据库或界面之前，你仍然必须先知道自己到底想做什么。

这正是我在 Vibe Coding 中经常遇到的问题：工具可以极快地产生代码，但如果你不断改变方向，它也能以同样惊人的速度生成多个版本的错误架构。

04用 Léopold 把想法变成可执行需求

为了把 Eva 的想法整理得更清楚——顺便挽救一下我剩下的假期——她使用了 Léopold。

Léopold 是我与 Jean-Francis Ochs 合作开发的 AMOA / 业务分析助手。它的目标，就是从仍然比较模糊的需求开始，通过提问、记录决策，最终生成真正能够被项目使用的交付物。

我并不需要一份没人会读的超长需求文档。我需要的是足够结构化的信息，能够快速回答一些非常具体的问题：有哪些角色、有哪些用户路径、哪里需要登录、哪些数据要持久化、后台需要管理什么、什么时候支付、发送哪些邮件、取消时发生什么，以及有哪些业务规则。

Léopold 可以生成项目范围摘要、需求规格、详细分析、数据模型、UX 建议，以及 OpenAPI 合约的初始基础。通过导出功能，我可以直接把这些结果作为开发上下文继续使用。

这大概也是整个故事里最重要的一点：AI 并没有让业务分析消失，反而让它变得更有价值。

05故意做得容易部署的架构

当需求足够稳定之后，我做了一个很简单的选择：我希望上线过程最好“无聊到没什么可说”。

不要十五个组件需要手工安装。不要几十页部署文档。也不要一台服务器，半年后还得靠记忆去想某个文件是不是曾经被手动改过。

所以这套应用围绕一个紧凑的 Docker 部署来设计，通过持久化卷保存所需数据，让备份、升级和重新部署都更加可预测。

当然，这并不会消除经典问题：环境变量、密钥、备份、数据库迁移、日志、监控和回滚依然必须处理。但对于这种规模的项目，我更愿意掌握一个结构清晰的部署单元，而不是无缘无故增加大量外部依赖。

06别忘了电子邮件

在 Web 项目里，有一个功能几乎总是被低估：电子邮件。

创建账号、预约、确认、实用信息、取消、找回密码、后台通知……一个“小网站”很快就会开始发送大量邮件。

因此，我重新利用了自己的 mailcow 基础设施。mailcow 是一套基于 Docker 的开源邮件套件，其中整合了 Postfix、Dovecot、Rspamd、SOGo 等组件。

对我来说，最大的好处是不用每做一个新项目就重新设计一套邮件方案。当一个组件已经熟悉、已经监控、也已经有备份时，重复使用它通常比重新搭一整套基础设施更合理。

07Stripe、MCP，以及巨大的效率提升

支付部分，大概最能体现现在这些工具带来的生产力变化。

我们最终选择了 Stripe。

关于增值税（TVA），这里需要说明一个重要点：税务处理取决于服务本身的具体性质。物理治疗师在其受监管专业范围内提供的医疗服务可能享受免税，但这并不意味着由物理治疗师提供的所有活动都会自动获得同样的税务待遇。因此，这个问题必须按具体活动分别判断。

从技术角度，真正让我感兴趣的是 Stripe 的官方 MCP 服务器。MCP，也就是 Model Context Protocol，可以让 Agent 或兼容的开发环境访问某个服务明确暴露出来的工具。

Stripe 现在提供官方 MCP Server，可以搜索其文档，并与很大一部分 Stripe API 交互。在我的项目中，我把它直接接入了 Codex 环境。

当然，我并不是说四天的工作永远都能变成两小时。具体结果完全取决于项目。但在这次集成中，节省的时间确实非常夸张。

其中很大一部分，其实是过去浪费在“来回查资料”上的时间：翻文档、确认参数名、重新找某个方法、创建测试对象，或者弄清楚一个 API 错误到底是什么意思。

08为什么不直接用 CMS 和插件？

先说清楚：Mumkine 完全可以使用其他技术来实现。

WordPress、建站工具、专业预约系统、支付插件，再加上一些 SaaS 服务，当然也能够做出一个可以工作的方案。

我并不反对这些工具。当需求恰好符合它们预设的工作方式时，它们往往就是最好的选择。

问题出现在需求开始稍微偏离这些模块的标准路径时。先装一个预约插件，再装支付模块，然后为了修改一个规则又加扩展，再装一个连接账号的扩展，再写 Hook，再加一点 CSS……最后，你确实得到了一套“几乎没有开发”的系统，但已经没有人真正理解它整体是怎么工作的。

AI 辅助开发改变了这个经济平衡。以前需要一天才能实现的定制功能，现在有时可以快很多。这让一些小型项目重新有了定制开发的价值——前提是你仍然具备维护自己所构建系统的能力。

09Vibe Coding 真正改变了什么

这个项目再次确认了我的一个判断：Vibe Coding 并没有真正取代开发者，而是重新分配了开发者工作的重心。

所以开发者并不会变成旁观者。恰恰相反：AI 写代码越快，错误决策被实现的速度也越快。

仍然必须有人能够说：不，这段逻辑不能复制三份；不，这个密钥不能放进 Git；不，浏览器端显示支付成功并不代表订单就已经安全确认；有时候还要直接说：不，我们根本不需要这个功能。

10AI 仍然不会替你做什么

这大概是 Vibe Coding 文章里最不“性感”的一部分，但它非常重要。

Agent 可以帮你写 Stripe 集成，但它不会为错误支付承担责任。

它可以生成数据库结构，但不会替你决定哪些数据真的应该保存。

它可以生成 Dockerfile，但不会自动验证：当某一天服务器彻底没了，你的备份是否真的能够让服务恢复起来。

它也完全可以围绕一个错误的功能决策，生成大量非常整洁的代码。

11那我的假期呢？

回到标题本身：没错，我当时确实是在休假。

而且我确实工作了。

而且是的，这位客户到现在还没有付账。😄

不过，这个家庭小项目最后变成了一个非常好的实验室。它让我真正测试了：当需求被正确梳理、架构保持一致时，今天的 Agent 辅助开发到底可以把效率推到什么程度。

结论并不是“任何人只要随便跟 AI 描述一个想法，两小时就能做出完整业务软件”。

真正更有意思的结论是：一个真正懂业务的人、一次好的功能需求梳理，再加上一个知道如何正确驾驭 Agent 的开发者，现在确实可以非常快地把一个想法变成真正可用的产品。

节省时间，并不一定意味着工作更少。

对我来说，它主要意味着：我妻子可以在假期结束之前继续增加更多功能。😂