我试过很多流程：先写文档、先冻结需求、先把方案评审到"完美"再开工。
最后都卡在同一个地方：需求一定会改。
在 AI 场景下，我现在更认同一套更务实的流程：
先用前端 + Mock 数据把 UI 和交互做出来，先跑起来，再定稿，再补后端。
这套方法的核心不是"偷懒"，而是把变化成本压到最低。
为什么传统流程在 AI 时代越来越慢
- 需求很难一次定死，前期写再多文档，后面一样会变。
- 从 PRD 到 Figma 到前端，再到后端，是多次"转译"，每一层都损耗。
- 岗位切得太细，交接等待时间比开发时间还长。
AI 让"先做出可用版本"这件事变得非常便宜，所以流程应该跟着变。
我现在用的流程（掘金可落地版）
flowchart TD
A[需求输入] --> B[AI生成前端+Mock粗稿]
B --> C[部署测试环境]
C --> D[产品/设计评审]
D --> E{是否定稿}
E -- 否 --> F[继续改UI与交互]
F --> C
E -- 是 --> G[后端实现]
G --> H[AI辅助单测/集成测试]
H --> I[人工测试]
I --> J{是否通过}
J -- 否 --> K[修复并回归]
K --> H
J -- 是 --> L[前后端代码审核+AI辅助]
L --> M[合并master并上线]
关键做法
1）先前端 + Mock，不先后端
先把页面和交互做出来，直接放测试环境给人看。
这一步的目标不是"代码完美"，是"把需求聊清楚"。
2）评审前置，变化前置
产品看需求理解是否正确，设计看风格和体验，测试提前介入。
变化都尽量在前端阶段消化，改得快，成本低。
3）前端定稿后再补后端
页面和交互定得差不多，后端实现会非常顺，返工会少很多。
这也是为什么我强调前期用 Mock：变化不可怕，怕的是改动太晚。
4）一个人执行，外围审核
"每个人都是全栈"不等于不要审核。
是一个人把链路跑通，外围角色做专业把关：产品、设计、前后端、测试都要审。
AI 时代的代码原则（偏实战）
- 单一职责拉满：一个页面尽量一个文件，一个接口只做一件事。
- 降低耦合：前后端边界清晰，模块可替换。
- 业务层谨慎复用：宁可直白一点，也不要为了"优雅"做过度抽象。
- 少谈套路，多谈可改性：IOC/AOP/复杂模式不是不能用，是没有收益就别上。
目标很直接：让 AI 看得懂、改得动、不容易改崩。
测试这件事，反而比以前更重要
很多人以为 AI 能写代码，测试就不重要了。恰恰相反。
我的经验是：AI 时代要重点设计两件基础设施：
- Mock 体系
- 测试框架（单测 + 集成测试）
TDD 在这个阶段非常有价值。每次跑绿，心里有底，改动也敢放开做。
组织层面的落地建议
- 把业务约束、代码风格、评审规则沉淀成
skills + 文档。 skills可以公司共建（GitHub 托管，统一工具链管理），也可以自己做 CLI。- 老项目不要想着一次改完，按模块逐步补齐。
总结
我的结论很简单：
AI 时代最优流程不是"先把一切定义完再做"，而是"先做出可运行前端样稿，让真实页面驱动需求收敛"，再进入后端和测试上线。
这套流程的本质是：
把变化留在最便宜的阶段，把质量放在可验证的环节。
这不是降低标准，而是更高效地把标准落地。