Claude Max 写商业项目总翻车？从需求拆解到验收的实操方案
有人用 Claude Max 开发多币种 ERP 和商城，结果陷入反复补上下文、修构建错误、改一个坏一个的循环。问题往往不在单点代码能力，而在需求粒度、任务拆解、上下文控制和验收门禁。文章给出一套可操作的 Spec 驱动流程与检查清单。
高价订阅 Claude Max 后，很多人期待它直接产出可卖的 ERP 或 SaaS。实际体验却常常相反：需求说不清，模型反复要上下文；代码能跑出演示，一到构建就报错；让它列 todo 自动修，几个小时后还在改，旧问题没清完又冒出新 bug。边界清楚的小型外贸商城会好一些，但离生产级仍有距离。
围绕这类体验的争论大致有三类：有人认为工具被高估，不如 IDE 类助手；有人认为是使用者没把需求讲清楚；也有人怀疑模型能力出现波动。更稳妥的判断是：Claude Max 是很强的代码生成器，但不是自动项目经理、架构师和测试工程师。商业项目要交付，必须把人的工程流程补上。
先把“翻车”拆成可处理的问题
| 现象 | 常见原因 | 先做什么 |
|---|---|---|
| 反复补上下文 | 任务跨度过大，相关文件没有边界 | 先写需求文档，再按任务带最小上下文 |
| 构建错误多 | 缺少统一类型、依赖和构建检查 | 每个小改动后立即跑构建与测试 |
| 改一个坏一个 | 一次让模型改太多文件，缺少回归测试 | 限制改动面，按分支和提交回滚 |
| 模型“漏改” | 没有可勾选的验收清单 | 把验收条件写成命令和用例 |
| 业务规则不对 | 财务、权限、租户隔离等知识没写进约束 | 人工定规则，模型只做实现 |
所谓“会不会用”，关键不在背多少提示词，而在能否提供三样东西：可验收的需求、受控的上下文、能自动检查的质量门禁。
用 Spec 驱动，把许愿变成施工图
复杂项目不要直接从“帮我写一个多币种 ERP”开始。先把想法整理成需求文档，可以借助另一个模型或文档工具，但最终要人确认。文档至少写清楚：用户角色、核心流程、数据对象、金额与汇率口径、权限与审计、异常场景、非功能要求。
- 让模型先产出 spec，不写代码：数据模型、接口、状态机、边界条件、验收用例。
- 人工 review spec，确认业务规则没有跑偏，再拆任务。
- 任务拆到半天到一天能完成、能单独 review 的粒度。
- 每完成一个任务先看 diff 和测试结果，再进入下一个。
任务模板可以固定成下面这样：
任务：新增汇率表与取数服务
范围：只改 migrations、汇率服务、对应测试
验收：
- 支持按生效日期选择汇率
- 金额计算使用定点小数，明确舍入规则
- 覆盖跨币种换算与边界用例
- 构建、测试、静态检查全部通过
禁止：顺手重构无关模块
Spec 模式的价值就在这里：先对齐再施工，而不是让模型边猜边写。
控制上下文与改动面
- 每个任务新开会话，只带 spec、相关目录、报错和相关测试，不要把整个仓库塞进去。
- 在项目里放一份长期说明文件（如 CLAUDE.md），写清技术栈、目录约定、命令、禁止事项和代码风格；每次会话让它先读。
- 要求模型先给计划：改哪些文件、为什么改、如何验证。计划不合理就停，不要直接放开改。
- 一次只做一个主题。修构建错误时不要同时加功能；重构时不要同时换依赖。
- 用 Git 分支和小提交隔离风险，常用
git diff、git status看模型到底改了什么；不对就回滚。 - 每个任务结束跑固定命令，例如
npm run build、npm test、npm run lint，具体以项目脚本为准。
如果任务需要长时间连续运行，而本地电脑会休眠、网络会抖动，可以把 Claude Code 放到长期在线的远程 Mac 上执行，例如整机在新加坡机房的独享远程 Mac。它改善的是运行稳定性，不会自动补上需求和验收。
验收门禁：只认命令和 diff，不认“已修复”
AI 说改好了不算数，构建、测试、静态检查和人工 diff 才算数。商业项目至少检查：
- 需求覆盖：每个验收点对应代码或测试。
- 数据模型：迁移可回滚，字段类型、索引、唯一约束合理。
- 金额与汇率：精度、舍入、生效时间、跨币种汇总口径。
- 权限与租户：越权访问、租户隔离、审计日志。
- 错误处理：失败重试、幂等、事务边界。
- 安全：输入校验、SQL 注入、XSS、密钥不入库。
- 依赖与构建：锁文件、构建产物、环境变量。
- 回归：修 bug 先补失败用例，再改代码。
对复杂业务，先让模型写测试或验收用例，再实现。修 bug 时要求先复现，再给最小修复。连续两轮修不好，停止对话，回到 spec 和日志，不要继续在同一个会话里叠补丁。
工具取舍：Claude Code、IDE 助手和 Spec 工具怎么选
| 工具类型 | 更适合 | 不太适合 |
|---|---|---|
| IDE 类补全/对话 | 边写边改、小范围补全、快速定位 | 跨多文件的大改造 |
| 终端型编码代理 | 按任务执行、批量重构、跑命令和测试 | 没有 spec 的开放式产品开发 |
| Spec/需求工具 | 复杂项目先拆需求、列任务、做验收 | 替代人工架构判断 |
如果任务只涉及边界清晰的纯代码改动，模型产出通常更稳定；一旦涉及财务口径、权限模型、租户隔离、合规要求，必须由人给出规则和验收标准。把需求整理、实现、审查分给不同工具或模型可以，但不要让多个代理同时改同一仓库。
关于模型是否“变弱”，很难用一次体验下结论。不同时间、不同任务、不同提示差异很大。遇到质量波动，先看官方状态和版本说明，再用固定任务做对比；如果只是某类任务失败，优先调整 spec、上下文和验收，而不是盲目升级档位。
订阅、网络与合规注意事项
不同地区、税项和支付渠道会造成结算金额差异，具体以官方结算页和最新说明为准。不要购买共享账号、代充服务，或用来源不明的礼品卡绕开地区限制。这类做法可能带来封号、付款纠纷、代码和密钥泄露，出问题也缺少官方支持。需要稳定网络时，先保证连接质量；跨境网络和终端环境的选择应以合规、稳定、可维护为前提。
小结
Claude Max 不是不能做商业项目，而是不能替你做商业项目。把它当成执行力强但需要明确任务的初级工程师：人负责需求、架构、验收，模型负责受控范围内的实现和重复劳动。先从小而完整的切片开始，构建、测试、review 都过关，再扩大范围。若连续出现构建失败和回归 bug，先停下来补 spec 和测试，而不是继续加功能。
