Spec模式
背景
要让 Agent 发挥更大价值，核心是让它聚焦代码编写，人承担监督角色。但现在真实场景中，人缺乏有效指导 Agent 写代码的手段。
因此我们给出解决方案：人多投入文档撰写的过程，负责核验 Agent 产出的文档与代码是否准确。
把错误尽可能拦在 Agent 写代码之前
智能体Spec模式
Spec模式是一种新的协作方式：让 Agent 先把它的理解与计划写成文档，把要做的事情拆成任务，经过用户确认后，再进行相应的代码编写。
从而让Agent的代码生成质量和效果大幅提升。
具体方案
各阶段以产物视图（Product View）呈现，共设六个 Tab（越往上，用户需要关注的优先级越高）。用户从关心代码转变为只需要关心开始的文档和任务以及最后的结果
1文档Doc：需求目标、实现方案说明（需确认）
2任务Tasks：任务拆解与执行计划（需确认）
3代码变更Changes：执行阶段的代码变更可视化与验证
4网页预览Preview：可视化前端或最终成果预览
5验证Verify（待实现）：通过自动化测试保证任务成功
6任务总结Summary：任务总结与交付结果!
- 流程策略： 不显性展示固定流程，而以“隐性引导”推进（Doc → Tasks → Summary），确保灵活性；特殊情况下允许模型智能跳过环节。
- 聚焦 “单轮完整任务” 流程：用户在确认 Doc 与 Tasks 后，暂不支持回溯修改这两个环节，保证流程简洁清晰。
效果
任务一次成功率显著提升、返工大幅减少、代码质量更稳。
① Spec 解决了“做错”问题：需求理解错误，代码也就错误；需求理解了，代码修改位置不对，代码也写错了
② Spec 解决了“做漏”问题：Agent考虑不周，未有效处理分支和边界条件
③Spec 解决了“做偏”问题：实现了功能，但实现方式不符合用户预期**
基于Github的真实需求Case演示
如何通过Spec模式中解决Agent 需求考虑不周，任务执行偏差的问题
原始query：
“基于nageoffer/12306代码库”
我在公共演示的时候，不希望现场的观众能够使用用户注册，修改信息、下单等功能扰乱我系统中原本的数据。所以我想增加一个demo 模式，能够通过在配置中设定这个 demo 为 true，并配置写操作路径黑名单以及返回状态码、返回消息，就能够拦截这些请求
正确路径：
/api/user-service/passenger/save
/api/user-service/passenger/update
/api/user-service/passenger/remove
/api/user-service/update
/api/user-service/deletion
Spec模式如何解决
Spec 模式通过让用户Doc确认解决了Zulu的问题： Spec 在文档阶段（仅 3 min）就能提前识别问题
- 需要拦截的路径
- 服务边界
- 演示环境下哪些模块不能触碰
- 可能的风险点
- 精准的范围列表
- 用户可编辑、可删改的范围说明
然后用户需要 **确认 Doc** 才能进入下一步。
*1）通过Doc，用户发现不需要拦截的路径不对，快速的和Agent对齐意图 在 Spec 的 Doc 里，AI 不再“默默选一个方案”，而是：*
- 列出不同实现方式（例如：基于 Spring MVC Interceptor / 基于自定义 Filter / 基于配置驱动）；
- 标明每种方案对 **可维护性、扩展性、性能、框架一致性** 的影响；
- 用人能读懂的话解释差异。
- 修改 AI 给出的实现方式描述；
- 明确否决某些方案。
*（2）Tasks 快速发现Agent任务拆分不对，进行相应的纠正 在进入执行前，Spec 会把 AI 计划做的事情拆成 Tasks：*
- 要改哪些路径
- 要动哪些文件
- 每一步预计会修改什么
- 在 Tasks 阶段就发现路径写错了（比如某个 api 路径不对）；
- 直接在任务层面改正，而不是等执行完再面对一堆错误 diff；
- 发现不对可以不让它继续到 Changes 阶段，**相当于在“将要执行”阶段就踩了刹车**。