昨天发了一篇帖子，说我用 AI 工作流系统跑完一个需求只花了 51 分钟。

评论区有人问：你是不是只写了个简单组件就算"跑完"了？

不是。今天聊聊"跑完"到底包含什么——以及为什么我认为，前端开发真正的效率瓶颈不是写代码，而是围绕代码的一切。

---

📅 你的一天是怎么过的？

早上 10 点，收到一个需求。你打开 PRD，开始写需求分析——梳理边界条件、列待澄清问题。30 分钟过去了。

然后写设计文档：组件怎么拆、数据怎么流、改哪些文件。1 小时过去了。

下午开始写代码。写完后跑一遍自测清单，20 分钟。写单元测试，又 1 小时。

提测前要填提测文档：需求链接、分支名、修改范围、影响面评估……复制粘贴，15 分钟。

一天下来，真正写业务逻辑的时间可能不到 2 小时。

其余时间都在处理"围绕代码的工作"：文档、格式、信息同步、重复填写。

---

🔁 这些工作有什么共同特点？

1. 重复性高：每个需求都要写需求分析、设计文档、提测文档，格式大同小异
2. 信息冗余：同样的信息（分支名、修改范围）在 3 份文档里重复出现
3. 上下文依赖：需要读 PRD、读代码、读接口文档，然后综合判断
4. 格式敏感：团队有规范，但每次都要回忆"设计文档应该包含哪些部分"

这些工作的本质是：把分散的信息，按固定格式，组织成结构化文档。

这恰恰是 AI 最擅长的事。

---

🛠️ 我的解法：Spec-Driven 工作流

我花了两个月搭建了一套系统，核心思路是：

把团队规范编码成 AI 可执行的配置，让 AI 按规范自动推进流程。

具体来说：

1. 规范即配置

团队的编码规范、文档模板、技术栈约束，不再是 Wiki 上没人看的文档，而是 AI 每次执行时必须遵循的约束文件。

改一行配置，下一个需求就按新规范执行。不需要发通知，不需要培训。

2. 流程即流水线

需求分析 → 设计文档 → 代码开发 → 单元测试 → 提测，每个阶段有明确的输入输出。

AI 自动推进，在每个阶段完成后停下来等我确认。我说"继续"，它就进入下一阶段。

3. 上下文自动关联

AI 生成设计文档时，会自动读取需求分析的产出。生成提测文档时，会自动回填分支名、修改范围。

信息只需要产生一次，后续自动流转。

4. 断点可恢复

下班了？明天回来说一句"继续"，AI 自动识别当前进度，从断点接着跑。

不需要花 10 分钟回忆"我昨天做到哪了"。

---

📊 提效的本质

不是"AI 帮我写代码写得更快"——代码开发本身的提效大概 30-50%，因为业务逻辑还是需要人思考。

真正的提效在文档类工作：

环节	传统耗时	AI 辅助耗时	提效
需求分析	30-60 min	8-15 min	~80%
设计文档	1-2 h	4-15 min	~85%
单元测试	30-60 min	5-10 min	~80%
提测文档	20-30 min	3-8 min	~85%
日报	5-10 min/天	0 min	100%

日报是 0 分钟——因为 AI 在执行流程的过程中自动记录了每一步做了什么，日报是自动生成的副产品。

---

🧩 为什么不是每个人都能做到？

因为这不是"装个插件"就能解决的事。

核心难点在于：

• 你需要把团队的隐性规范显性化（写成 AI 能读的配置）
• 你需要设计流程的编排逻辑（哪些步骤可以自动化，哪些必须人确认）
• 你需要持续迭代优化（AI 第一次跑的结果不完美，需要反馈机制让它越来越好）

这不是"用 AI"的问题，是**“设计 AI 怎么用”**的问题。

---

明天最后一篇，聊聊这件事对前端开发者意味着什么——以及为什么我认为，未来三年开发者会分成三个层级。

---

💬 你团队的文档工作占开发时间的比例是多少？欢迎评论区聊聊。

---