一条 IM 消息
事情的起点是即时通讯软件上的一条消息：
Sales wants to have an option for visitors to schedule a demo from our site. We are using Calendly.
这就是全部需求描述。没有 PRD，没有设计稿，没有验收标准。
Agent 的处理方式值得记录，因为这是一个”从模糊需求到可部署实现”的完整闭环。
第一步：不要急着写代码
Agent 的第一个动作是分析现状，而不是直接找 Calendly 的嵌入代码。
它扫描了现有网站结构，发现一个关键语义冲突：
- 网站已有 “Request Demo” 按钮
- 但这个按钮的实际行为是弹出产品环境选择器（Live / Sandbox），不是预约销售演示
- 首页底部另有一个通过 EmailJS 发邮件的 Demo Request 表单
结论：新需求不是在现有按钮上加链接，而是重做整条销售线索路径——把原来碎片化的”联系销售”流程，收束为一个统一的、可追踪的 Calendly 预约入口。
这一步分析决定了后续方案不上错方向。
第二步：方案对比
Agent 对比了三种集成方案：
| 方案 | 方式 | 交互 |
|---|---|---|
| A: 内联嵌入 | Calendly inline widget 直接嵌在页面中 | 用户不离开网站 |
| B: 弹窗嵌入 | Calendly popup widget 点击后弹出 | 轻量覆盖 |
| C: 外链跳转 | 直接链接到 Calendly 预约页面 | 最简单 |
方案 C 最简单但用户体验差（跳离网站）。方案 A 体验最好但占大量页面空间。最终推荐方案 B：按钮点击后弹出 Calendly 预约弹窗。
同时建议了三处放置点：导航栏（全局可见）、首页 Hero 区域（最高转化）、Pricing 页面（购买意图最强）。
第三步：实现
实现本身很简单——Calendly 提供标准的 popup widget SDK：
Calendly.initPopupWidget({
url: 'https://calendly.com/your-org/demo'
});但有一个关键设计决策：预约链接通过环境变量配置，不硬编码。
生产环境用真实 Calendly 链接，本地开发可以用测试链接或不加载 widget。这样不同的部署环境不需要改代码，只需要改一个 CALENDLY_DEMO_URL 环境变量。符合网站”薄代理前端”的定位——所有配置从环境注入，代码保持通用。
三处按钮（导航栏、Hero、Pricing）都使用同一个变量，统一入口。
第四步：工程化
实现完成后，Agent 做了以下几件事：
- 代码提交：按约定式提交规范，写清楚 feat、docs、fix 三类 commit
- 文档记录：在项目规则文件中记录了 Calendly 的配置方式和隐私说明
- 无障碍优化：补充了 aria 标签，修复了 Calendly 回退链接
- 项目管理登记：在项目管理工具中对应的 Task 记录了关联 commit
第三点值得展开：Calendly 的 popup widget 在某些场景下（移动端、广告拦截器、网络问题）可能加载失败。加了回退链接——widget 加载成功时显示按钮+弹窗，加载失败时显示普通链接跳转。
第五步：外部阻塞
上线后出现一个未预期的问题：销售人员没有收到 Calendly 的会议通知邮件。
查了一圈后发现不是代码问题——Calendly 的邮件通知是服务端行为，通知发送依赖 Calendly 自身的事件系统。代码只是嵌入了 widget 并触发了预约流程，后续的邮件通知完全在 Calendly 服务端。
于是提交了服务商工单，同时在项目管理工具中将这个 Task 标记为 “On hold”，等待外部确认。
这是 Agent 驱动开发的一个典型场景：能完成代码层面的工作，但遇到外部依赖阻塞时，需要准确识别边界并把接力棒交回给人类。
反思
这个需求从 IM 消息到上线，全过程 Agent 承担了：
- 需求分析和语义冲突发现
- 方案对比和技术选型
- 代码实现和配置设计
- 文档和工程化工作
- 项目管理状态同步
人的参与点是：确认方案、提供 Calendly 账户配置、处理外部服务商工单。
这个分工是合理的。Agent 擅长”在已知约束下找到最优方案并执行”，人擅长”做不可逆决策和处理外部依赖”。把这个边界弄清楚，协作效率会高很多。