Spec 模式:从代码驱动到规范驱动
更新时间:2026-05-20
Spec 模式的核心理念
传统开发中的代码文档,往往是等代码写完才去补充,有时甚至来不及维护。而 Spec 模式要求在动手写代码之前,先让 AI 生成一个能指导 AI 的规格说明书——它需要可共享、可评审、可执行,变得和代码一样重要。


“可控 AI 编码”的本质:强化软件工程思想 ,在不确定性中通过工程化手段构建确定性系统。
关键抓 5 件事:
- 双端约束:约束输入(需求)与输出(代码规范),减少幻觉。
- 架构兼容:让 AI 明确目录结构、架构模式、模块职责。
- 质量与效率平衡:找到合适的任务粒度,避免效率高但质量失控。
- 规模化复用:将规范与流程沉淀为可复用资产,避免“每人一套玩法”。
- 审查→优化闭环:自动审查 + 人工把关,形成持续进化机制。
Comate Spec模式介绍
-
Spec模式下,各阶段以产物视图(Product View)呈现,共设六个 Tab(越往上,用户需要关注的优先级越高)。用户从关心代码转变为只需要关心开始的文档和任务以及最后的结果
- 文档Doc:需求目标、实现方案说明(需确认)
- 任务Tasks:任务拆解与执行计划(需确认)
- 代码变更Changes:执行阶段的代码变更可视化与验证
- 网页预览Preview:可视化前端或最终成果预览
- 验证Verify(待实现):通过自动化测试保证任务成功
- 任务总结Summary:任务总结与交付结果

流程策略: 不显性展示固定流程,而以“隐性引导”推进(Doc → Tasks → Summary),确保灵活性;特殊情况下允许模型智能跳过环节。
任务一次成功率显著提升、返工大幅减少、代码质量更稳:
- 解决了“做错”问题:需求理解错误,代码也就错误;需求理解了,代码修改位置不对,代码也写错了
- 解决了“做漏”问题:Agent考虑不周,未有效处理分支和边界条件
- 解决了“做偏”问题:实现了功能,但实现方式不符合用户预期
优势1:风险前置
Spec 在开始执行前会生成 Doc,其中明确列出各种细节:
- 需要拦截的路径
- 服务边界
- 演示环境下哪些模块不能触碰
- 可能的风险点
- 精准的范围列表
- 用户可编辑、可删改的范围说明 然后用户需要 确认 Doc 才能进入下一步。

优势2:快速修正Agent意图
用户发现执行方向不对,可以通过修改Spec的Doc,快速的和Agent对齐意图 在 Spec 的 Doc 里,AI 不再“默默选一个方案”,而是:
- 列出不同实现方式(例如:基于 Spring MVC Interceptor / 基于自定义 Filter / 基于配置驱动);
- 标明每种方案对 可维护性、扩展性、性能、框架一致性 的影响;
- 用人能读懂的话解释差异。

优势3:节省token消耗
Spec合理设计下可显著降低Token消耗,从而减少模型消耗费用或提高上下文利用率。
评价此篇文章
