Claude规范驱动工作流

使用Claude进行代码生成的速度足够快，以至于瓶颈不再是打字。瓶颈是在Claude编写之前确切知道你想要什么。规范驱动工作流将思考前置，使得实现阶段变成执行而非探索。

能够与Claude很好协作交付的团队是那些在AI工具出现之前就建立了规范纪律的团队。陷入困境的团队是那些试图通过让Claude自己去想象来跳过规范的团队。

我用三四句话向Claude描述问题。然后我要求Claude提出五个问题，这些问题的答案会改变设计。我回答它们。然后我要求Claude用200字总结得出的产品规范。

这个阶段需要30到60分钟，产出一份书面规范，其他所有工作都基于它展开。这五个问题通常是我如果直接写代码就会跳过的那些；通过头脑风暴阶段把它们浮现出来，这就是整个价值所在。

有了规范在手，我让Claude识别出那些在下游有最高杠杆作用的架构选择。数据库结构、API表面、渲染策略、部署模式。对每一个，Claude都提出两到三个选项及其权衡。

我来选择。决策被记录在同一份文档中，这样构建阶段就有单一的信息源。在这个阶段做出的决策比在实现过程中发现的决策修改成本低10倍。

代码生成是最后一个阶段，速度最快，因为规范已经完成了。Claude按大致顺序写出模式、查询、组件、路由、测试。我审查每一个提交。

大多数审查会发现一些小的重构或遗漏的边界情况；当规范清晰时，完整的重写很少见。速度是无辅助工程在绿地项目上的两到五倍。

从头脑风暴到代码上线之间有三个审查关卡：

规范关卡：在写任何代码之前，200字的规范从上到下被读过一遍。任何模棱两可的地方都要澄清。任何抱负性的内容都要删除。

架构门禁：在任何数据库迁移运行之前，架构决策会根据规范进行审查。任何不符合规范的内容都会被重新考虑。

提交门禁：每个 Claude 撰写的提交在合并前都要接受人工审查。审查速度比自己写代码快，但这是必不可跳过的。Claude 不会批准自己的拉取请求。

探索性或研究性工作，目标是学习可能性而不是构建已知的东西。对于这类工作，规范阶段会产生模糊的规范，这会对 Claude 造成不必要的限制。迭代式聊天搭配具体的制品是更合适的模式。

原因不明的错误修复。规范阶段假设你知道目标在哪里；调试是找出你当前在哪里。对于调试，直接跳到系统性调试模式（复现、隔离、诊断、修复），跳过规范阶段。

UI 优化，其中每次迭代都很小，视觉反馈是信号。对于这类工作，Cursor 中的 Claude 搭配热重载和并排对比是正确的工具，而不是书面规范。