从 Harness 理念到 Spec-Driven 实践，如何用一套 Skill 体系把"需求到提测"的流程工作提效 80%

---

📅 引言：一个前端开发的日常困境

早上 10 点，你收到一个需求：在现有业务模块中新增一个时段售卖配置功能。

你打开 PRD，一边读一边在本地新建 Markdown 文件，开始写需求分析。写完已经 10:30 了——主要是梳理待澄清问题和边界条件。

然后开始写设计文档：组件设计、数据流、修改文件清单……写到 11:30，差不多有个雏形。

下午 2 点开始开发，创建分支、写代码，联调时发现接口文档还没给，先 Mock 着。写完后手动跑一遍自测清单，20 分钟。写单元测试，又一个小时。

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

这一天真正写业务代码的时间可能不到 2 小时，其余时间都在处理"围绕代码的工作"。

更让人头疼的是：

• 每次写文档格式都不一样，这次漏了流程图，下次忘了边界条件
• 需求做到一半被中断，回来要花 10 分钟回忆"我做到哪了"
• 周报要汇总这周干了什么，翻聊天记录、翻 Git log
• 同样的信息在需求文档、设计文档、提测文档里反复填

这不是某个人的问题，这是前端开发流程的系统性困境。

核心矛盾很清楚：人的时间应该花在创造性的业务逻辑和技术方案上，却被大量重复性的"流程工作"占用了。

而 AI 的出现，让我们第一次有机会重新思考这件事——不是"用 AI 偶尔帮忙写点代码"，而是把 AI 作为整个开发流程的执行引擎。

---

🤖 第一章：重新定义 AI 的角色

1.1 AI-Augmented vs AI-Native

在讨论具体方案之前，有必要先厘清两个概念。

AI-Augmented（AI 增强）：人是流程的主人，AI 是辅助工具。你在思考、做决策、执行动作，AI 偶尔被调用——比如问 ChatGPT 一个问题，或者用 Copilot 补全一行代码。

AI-Native（AI 原生）：AI 是流程的执行引擎，人是决策者和审核者。AI 主动推进流程，在关键节点停下等人确认，人的角色是"拍板"而不是"动手"。

区别不是程度，而是设计起点：

维度	AI-Augmented	AI-Native
AI 的角色	辅助工具，被动响应	执行引擎，主动推进
流程设计	人驱动，AI 偶尔介入	AI 驱动，人在关键节点确认
规范形式	人读的文档（Wiki/Confluence）	AI 可执行的配置（Markdown 即代码）
上下文传递	人脑记忆 + 手动同步	系统自动关联
反馈闭环	定期复盘，人工总结	每次执行自动沉淀，规范持续进化

一个简单的判断标准：人是"调用"AI，还是"被 AI 引导"？

• 打开 ChatGPT 问问题 → Augmented
• AI 主动说"需求分析已完成，请确认待澄清问题" → Native

1.2 和现有产品的对比

市面上已经有一些 AI 开发工具，它们各自解决了一部分问题：

产品	定位	擅长	局限
GitHub Copilot	代码补全	行级/函数级代码生成	不管流程，只管代码片段
Cursor / Windsurf	AI IDE	代码生成 + 对话式开发	单次任务，缺乏流程编排
Copilot Workspace	任务拆解 + 代码生成	从 Issue 到 PR 的自动化	只覆盖"代码"环节，不管文档
Devin	全自动 AI 工程师	端到端自主完成任务	黑盒，人难以介入和控制
Replit Agents	从零搭建项目	快速原型	适合新项目，不适合存量代码

我做的事情和它们的本质区别是什么？

它们解决的是"代码生成"问题。我解决的是**"开发流程"问题**。

代码生成只是开发流程中的一个环节。在它之前有需求分析、设计文档；在它之后有单元测试、CR、提测。这些环节加起来占了开发者 60-80% 的时间，但几乎没有工具在系统性地解决。

另一个关键区别：Human-in-the-loop。

Devin 追求全自动，但现实中你不可能让 AI 自己决定技术方案、自己决定组件怎么拆。我的设计是 AI 执行 + 人决策——每个关键节点都有确认点，人始终掌握控制权。

这不是妥协，这是务实。在企业级项目中，"可控"比"全自动"重要得多。

1.3 Harness 理念的启示

Harness 是持续交付领域的标杆产品，它的核心理念是：将软件交付流程抽象为一条可编排、可追踪、可回溯的流水线。

这个思想完全可以迁移到前端开发流程中：

• 可编排：需求分析 → 设计文档 → 代码开发 → 联调 → 测试 → 提测，每个阶段有明确的输入输出
• 可追踪：每个阶段的产出有明确关联，形成完整链路
• 可回溯：流程中断后可以从断点恢复，不用从头开始
• 人机协作：AI 执行流程，人在关键节点做决策

关键洞察：前端开发流程本质上也是一个"流水线"，只是传统上这个流水线的执行者是人。 AI 可以成为流水线的执行引擎，而人升级为"调度者和审核者"。

---

📐 第二章：Spec-Driven 开发——规范即配置

2.1 传统规范的困境

每个团队都有自己的规范文档，放在 Wiki 或飞书上。但现实是：

• 没人看：规范文档动辄几十页，新人入职看一遍，之后就再也没打开过
• 不一致：同样的规范，不同人理解不同，执行出来五花八门
• 难更新：规范改了，要发通知、等大家消化，真正落地遥遥无期
• 无法验证：没有人检查代码是否符合规范，规范成了"摆设"

问题的本质是：规范是给人读的，而不是给工具执行的。

2.2 规范编码化

Spec-Driven 的思路是：把规范写进 AI 能读的配置文件中。

具体来说，从项目的实际代码中提取规范：

# tech-stack.md

## 技术栈约束
- React 18 + Ant Design 5 + TypeScript 5.x
- 状态管理：Zustand
- 构建工具：Rspack

## 编码规则
- 函数风格：表达式（func-style: expression）
- 命名规范：驼峰（camelCase）
- 禁止使用 moment.js（使用 dayjs）

## 目录结构
- src/ 目录分层：pages/components/services/utils
- 路径别名：@/ 指向 src/

这些规范不是"建议"，而是 AI 在生成代码时必须遵循的约束。相当于每个开发者都有了一个"随时在线、严格执行规范"的助手。

2.3 改动即生效

最关键的一点：规范文件是纯 Markdown，修改后立即生效。

• 不需要发通知
• 不需要组织培训
• 不需要等人消化

团队决定升级技术栈？改一行配置，下一个需求就按新规范生成代码。团队换了新的 lint 规则？改配置文件，AI 自动遵守。

规范不是写出来的，是跑出来的。

---

🏗️ 第三章：Multi-Agent 协作架构

3.1 为什么需要多 Agent？

单一 Agent 有两个问题：

• 上下文爆炸：一个 Agent 处理所有事情，prompt 会越来越长，最终难以维护
• 耦合过重：需求分析、代码生成、测试、CR 是不同性质的任务，放在一起互相干扰

解决方案是 Multi-Agent 架构——把系统拆分为一个"编排 Agent"和多个"专项 Agent"。

3.2 架构全景图

Agent	职责	独立使用	何时被调用
编排 Agent	流程编排、状态管理、记忆维护	—	始终在线
需求评审 Agent	PRD 质量评审 + 代码对照分析	✅	流程第一步
设计文档 Agent	分析代码结构，生成设计方案	✅	流程第二步
编码规范 Agent	规范查询、代码风格检查	✅	代码生成时
代码走查 Agent	多维度走查，输出报告	✅	CR 阶段
单元测试 Agent	生成测试、运行、修复	✅	测试阶段
提测文档 Agent	自动生成提测文档	✅	提测阶段

每个 Agent 都可以独立使用，也可以被编排 Agent 按流程调度。

3.3 核心设计模式

模式一：编排-调度

编排 Agent 不执行具体任务，只负责：判断当前处于哪个阶段 → 调用对应的专项 Agent → 等待用户确认后推进到下一阶段。

模式二：确认点机制

每个阶段完成后，AI 停下来等待用户确认。用户可以说"确认"、“继续”、“修改 xxx”。AI 不会擅自推进。

核心理念：AI 执行，人决策。

模式三：断点重连

会话中断后（比如关闭 IDE、下班回家），用户只需要说"继续"。AI 会自动：

1. 读取当前 Git 分支名
2. 匹配到对应的需求
3. 读取该需求当前所处的阶段
4. 直接从断点继续

不需要用户说"我在做 xxx 需求，做到 yyy 阶段了"——AI 自己知道。

模式四：需求移交

需求中途换人时，AI 自动生成移交摘要：当前进度、待办事项、关键决策、相关链接。接手人切换到对应分支，说"继续"即可接上，零学习成本。

---

🧬 第四章：自我进化——反馈驱动的持续优化

4.1 静态规范的问题

即使是可执行的规范，也有一个问题：规范是静态的，而团队的协作习惯是动态的。

团队可能有自己的偏好：日报格式喜欢用列表而不是段落；设计文档里一定要有架构图；提测文档里某些字段不填"待补充"，直接留空。

这些偏好很难在一开始就写进规范。更合理的方式是：让规范在使用过程中自然进化。

4.2 反馈学习机制

核心机制是结构化的反馈记录：

反馈类型	触发条件	动作
用户驳回	≥1 次	立即标记高优，下次执行时主动确认
用户确认	≥3 次	固化为最佳实践，自动写入规范
AI 自发现	执行中识别	阶段结束时一并提出，不打断节奏

4.3 实际案例

在首次跑通全流程的过程中，通过这个机制迭代了 12 项优化：

优化	来源	影响
日报格式改为"完成 xxx"+ 换行	AI 自发现	日报可读性大幅提升
第一步即创建 Git 分支	用户指出	分支名作为断点重连标识
接口文档自动回填设计文档	AI 自发现	减少一次手动复制
开发变更自动同步设计文档	用户指出	设计文档保持最新
单元测试 Bug 自动记录测试报告	AI 自发现	测试报告完整可追溯
提测文档留空而非"待补充"	用户指出	避免无效信息

每一条优化都来自实际使用，而非预先设计。规范不是写出来的，是跑出来的。

---

📊 第五章：真实数据与诚实复盘

5.1 提效数据

环节	传统耗时	AI 辅助耗时	提效幅度	说明
需求分析	30-60 min	8-15 min	~75%	含人工审核确认时间
设计文档	1-2 h	4-15 min	~80%	含人工审核调整时间
代码开发	视需求	视需求	~30-50%	业务逻辑仍需人思考
接口联调	1-2 h	10-20 min	~70%	不含等待后端时间
单元测试	30-60 min	5-10 min	~80%	含自动修复时间
提测文档	20-30 min	3-5 min	~85%	信息自动回填
日报	5-10 min/天	0 min	100%	流程副产品，自动生成

重要说明：以上数据基于中等复杂度的前端需求（表单类、配置类），不含需求澄清等待时间。复杂的架构设计类需求，AI 辅助的比例会降低。

5.2 真实需求实践

用一个真实的中等复杂度需求（销售时段配置）跑通了全流程：

阶段	耗时	产出
需求分析	~8 min	结构化分析文档 + 10 条待澄清问题
设计文档	~4 min	组件设计 + 数据流 + 修改文件清单
代码开发	~10 min	创建分支 + 编写核心组件
单元测试	~21 min	生成测试 + 发现并修复 2 个 Bug
提测文档	~8 min	完整提测文档
合计	~51 min

5.3 失败案例：AI 不是万能的

诚实地说，这套系统也有翻车的时候。

案例一：设计文档完全跑偏

有一个涉及多模块联动的需求，AI 生成的设计文档把组件拆分方式搞错了——它按 UI 结构拆，但实际应该按业务域拆。我审核时没仔细看就确认了，结果开发到一半发现架构不对，推翻重来。

教训：确认点不是走过场，人的审核质量决定了系统的上限。

案例二：单元测试的 Mock 地狱

AI 生成的单元测试过度依赖 Mock，测试通过了但实际上没测到真正的逻辑。后来我在规范里加了一条：“优先测试纯函数和数据转换逻辑，减少对组件渲染的 Mock 测试”。

教训：规范需要在失败中迭代，不可能一开始就完美。

案例三：复杂交互需求的局限

涉及拖拽排序、复杂动画、Canvas 绑定这类需求，AI 的代码生成质量明显下降。这类需求目前还是以人为主，AI 辅助查文档和生成骨架代码。

教训：知道 AI 的能力边界，比盲目信任更重要。

5.4 质量提升

除了时间提效，还有三个质量维度的提升：

• 规范一致性：每次输出严格遵循同一套规范，消除个人风格差异
• 遗漏率降低：单元测试自动覆盖核心维度，AI 自动修复失败用例
• 可追溯性：所有文档和状态变更形成完整交付链路，随时可查

---

🌐 第六章：跨团队适配——从个人工具到团队基础设施

6.1 三层文件架构

为了让这套体系能够跨团队复用，设计了"三层文件架构"：

层	文件	管理者	说明
通用规则	SKILL.md	AI 维护	通用流程定义，不包含技术栈特定内容
引导配置	references/	用户编辑	技术栈/团队/个人偏好，换团队时替换
学习反馈	LEARNING.md	AI 管理	基于反馈自动学习，沉淀规范

核心原则：

• SKILL.md 是通用的，不包含任何技术栈特定内容
• references/ 是可替换的，换团队/换技术栈只需替换这个目录
• LEARNING.md 是自动生长的，使用越多越精准

6.2 换技术栈只需替换配置

场景一：React → Vue

只需要替换 references/ 下的技术栈相关文件。SKILL.md 和 LEARNING.md 完全不需要改。

场景二：前端 → 后端

同样的架构，替换为后端相关配置。流程框架（需求分析 → 设计 → 开发 → 测试 → 提测）完全复用，只是每个环节的具体规范不同。

这意味着：这不是一个"前端工具"，而是一个"开发流程框架"。 前端只是我验证它的第一个场景。

6.3 渐进式采纳

新团队接入时，不需要一次性把所有规范写完美：

1. 先用默认配置跑一个需求——看 AI 的表现
2. 执行过程中使用反馈机制——AI 会学习团队偏好
3. 定期沉淀——确认 ≥3 次的操作固化为规范
4. 几周后就有了一套专属规范

规范不是从零写的，是在使用中"长出来"的。

---

⚠️ 第七章：挑战、局限与未来

7.1 当前局限

• 模型能力天花板：复杂架构设计、创新性方案，AI 目前还做不好
• 上下文窗口限制：大型项目的代码量超出模型处理能力，需要精心设计"喂什么给 AI"
• 工具链成熟度：飞书等协作工具的 API 能力有限，部分操作还需要人工介入
• 学习成本：搭建这套系统本身需要投入时间，不是"装个插件"就能用的

7.2 适用场景

这套系统最适合：

• 中等复杂度的 CRUD/配置/表单类需求
• 有明确规范的团队
• 需求量大、重复性高的业务

不太适合：

• 高度创新性的技术探索
• 复杂的图形/动画/交互开发
• 没有任何规范基础的团队（需要先建立基本规范）

7.3 未来方向

• 从"需求分析 → 提测"扩展到需求全生命周期（向前延伸到需求评审，向后延伸到发布监控）
• 跨团队规范复用（公司级基础规范 + 团队级业务规范 + 个人级偏好）
• 与 CI/CD 深度集成（单元测试自动触发流水线，提测文档自动关联项目管理工具）

---

🎯 结语：AI-Native 不是未来，是现在

回到开头的问题：前端开发的时间去哪了？

答案不是"写代码太慢"，而是**"围绕代码的工作"太多**。

AI-Native 工程化的本质，不是用 AI 替代开发者写代码，而是让 AI 成为流程的执行引擎，把开发者从重复性工作中解放出来。

这套体系已经在真实项目中跑了两个月：

• 纯需求流程耗时 ~51 分钟
• 文档类工作提效 80%+
• 日报实现零人工
• 12 项规范优化在使用中自然沉淀

但这只是一个开始。

AI-Native 工程化是一个全新的领域，没有现成的路标。本文提供的是一种思路、一套架构、一些可复用的模式。

如果你也在思考类似的问题，欢迎交流。

淘汰你的不是 AI，而是会用 AI 的同行。而你，可以成为设计"AI 怎么用"的那个人。

---

关于作者

一个在探索 AI-Native 开发工作流的前端工程师。相信"规范不是写出来的，是跑出来的"。

如果你对这套系统感兴趣，或者在做类似的探索，欢迎评论区交流。后续会开源核心框架，关注不迷路。

---

欢迎指导：https://github.com/sleepyccat/ai-native-workflow