让 AI 编码 Agent 先想清楚再动手：SpecOps 的规格驱动工作流
AI 编程助手很擅长快速生成代码，但“快”不等于“理解需求”。当你只说“加上 OAuth 登录”，Agent 可能立刻选定某个提供商、决定令牌方案并开始改文件；等你发现遗漏，再花时间把它拉回正轨。SpecOps 选择在编码前增加一段可审阅、可追踪的规格过程，适合需求有多个约束、又希望跨会话保留决策的开发者。
它把实现拆成四个阶段
SpecOps 的工作流依次是：理解代码库与上下文、整理需求/设计/有序任务、依据规格实施，最后按验收标准完成检查。规格以 Markdown 文件保存在仓库中，因此可以纳入 Git 评审，不必依赖某个云端服务保存上下文。项目 README 列出的平台包括 Claude Code、Cursor、OpenAI Codex、GitHub Copilot 与 Google Antigravity；不同平台的触发方式不完全相同。
这不是“让模型多写一份文档”这么简单。先把验收条件写清楚，可以把“做完了”从模型的主观判断变成可核对的清单；把任务按依赖排序，也能让人提前发现需求缺口。SpecOps 还提供规格漂移检查、团队审批门、依赖引入评估，以及生产环境经验记录等机制。它们是否适合某个团队，仍取决于团队流程与项目配置，不能假设启用后就自动保证正确性。
安装与第一次使用
仓库 README 给出的 Claude Code 插件市场安装方式如下：
/plugin marketplace add sanmak/specops /plugin install specops@specops-marketplace /reload-plugins
也可以按 README 中的跨平台安装命令安装（运行远程脚本前，建议先检查脚本内容）：
bash <(curl -fsSL https://raw.githubusercontent.com/sanmak/specops/main/scripts/remote-install.sh)
在支持的 Agent 中，向它提出一个具体需求，例如：
/specops Add user authentication with OAuth
首次尝试不要只写“做登录”，而要说明目标用户、已有认证方式、必须支持的提供商、兼容性限制和验收条件。SpecOps 会围绕这些信息组织需求、设计与任务；准确产物要以当前版本和所用平台的文档为准。
让规格真正有用的三个习惯
把决策点写成问题。 如果需求没有说明 OAuth 提供商、账号关联规则或失败后的行为，应让 Agent 先列出待确认项，而不是默许它自行选择。关键假设最好在开始实现前由开发者确认。
验收条件要能验证。 “体验良好”“安全可靠”难以直接检查。可以改写为具体行为，例如：未认证请求返回约定状态码；重复回调不会创建重复账号；相关路径有自动化测试。条件越清晰，最终审查越有效。
把规格当作代码的一部分维护。 规格文件进入版本控制后，应在评审时检查它是否仍代表团队认可的行为。实现变化时同步更新规格；否则文档会成为新的漂移来源。工具的检查机制可以帮助发现问题，但不能代替代码审查、测试与安全评估。
哪些场景值得尝试
小型、边界清晰的修改，直接对话可能更省事。涉及多个模块、需要团队审批、跨会话持续推进，或必须记录“为什么这样设计”的任务，则更适合先形成规格。SpecOps README 还描述了将大型功能拆成多个相互依赖规格的流程，适合分阶段交付，但项目是否能按预期拆解，仍应先用小任务验证。
SpecOps 是 MIT 许可证的开源项目，规格以仓库文件为核心，降低了绑定单一模型平台的风险；它也引入了额外流程与维护成本。建议先挑一个真实但范围有限的功能试跑，观察规格质量、人工确认次数和后续返工，再决定是否推广。