1. 真实需求分析阶段，Claude Code 最危险的不是“写错代码”，而是“写对了但不该写的代码”我在三个 SaaS 项目的需求分析阶段踩过同一个坑：用 Claude Code 把一份模糊的客户邮件快速转成了结构清晰的 API 接口定义、数据库字段列表和状态流转图。团队当天就开了评审会，前端开始搭骨架，后端建了表结构，测试写了用例模板——看起来效率爆表。两周后，客户在 UAT 环境里点开第一个功能页，当场问：“这个‘审批流跳过二级’的按钮，我们从来没提过，谁加的？”没人加。是 Claude Code 在解析“支持灵活审批”时，基于它见过的 200+ SaaS 审批系统案例，自动补全了“跳过二级”这个常见变体，并把它写进了接口文档和 ER 图注释里。它没写错——逻辑自洽、符合行业惯例、甚至带了 RBAC 权限校验伪代码。但它彻底偏离了客户原始诉求的边界。这不是个例。过去 18 个月，我参与交付的 7 个中型 SaaS 项目（年合同额 80–300 万），有 4 个在需求分析阶段因 Claude Code 的“合理发挥”导致返工。平均每个项目多花 3.2 人日重新对齐需求，其中 2 次直接触发合同补充条款谈判。最致命的是：这些错误在代码层面完全合法，在 PRD 文档里却找不到任何依据——它把“推测”变成了“事实”，而团队默认信任了 AI 输出的“专业性”。这揭示了一个被严重低估的事实：在需求分析环节，Claude Code 的最大风险不是生成低质量代码，而是以高置信度输出逻辑正确但需求失真的内容。它的训练数据来自海量开源项目与技术文档，天然倾向“通用解法”，而 SaaS 项目的灵魂恰恰在于业务规则的非标性——那个“必须手动触发