把 OpenSpec 写进简历，重点不在于证明自己记住了多少命令，而在于说明：你能够把模糊需求变成可追踪的工程规范，并让 AI 按照明确边界完成实现和验收。招聘方真正关心的不是工具名称本身，而是你是否解决了需求漂移、跨模块协作、验收困难和文档失真等工程问题。
[!SUCCESS] 简历可以写得有分量，但每一句都应该经得起追问。没有实际完成过的流程、没有统计依据的效率数据，以及并不存在的项目能力，都不要写成既成事实。
先把 OpenSpec 翻译成招聘方能理解的能力
如果简历上只写“熟悉 OpenSpec”，它与“了解 Git”“使用过 Docker”没有本质区别，很难体现你的工程价值。更有效的表达方式，是先说明 OpenSpec 解决了什么问题，再说明你采取了什么动作，最后给出可以核验的交付物。
📷 [图片 token=CSogbeCKjoTsVbxcqTDcmndxnOg（未能下载，见飞书原文）]
问题： AI Coding 容易把需求理解成一次性提示词，随着对话变长，功能边界、异常分支和验收标准会逐渐丢失。
动作： 使用 OpenSpec 把变更拆分为 Proposal、Design、Tasks 和规格增量，先明确目标与非目标，再进入代码实现。
工程约束： 将共享契约、数据库迁移、租户隔离、失败状态、前后端联动和测试要求写入任务及验收标准，约束 Codex 的执行范围。
可验证结果： 需求、设计、任务、实现、测试与归档在仓库中形成对应关系，后续开发者能够根据规格继续维护，而不是重新翻阅聊天记录猜测背景。
把这四部分连起来，OpenSpec 就不再是一个孤立工具，而会体现为规范驱动开发、需求建模、工程治理和 AI 协作能力。
📷 [图片 token=X9o9bflE8oX4W7xFcI0c6StOnvg（未能下载，见飞书原文）]
OpenSpec 应该写在简历的什么位置
OpenSpec 可以出现在技能概述和项目经历中，但两处承担的任务不同。技能概述只负责让招聘方快速发现关键词，项目经历则必须说明你怎样使用它完成真实工作。
技能概述中的写法：
AI Native 工程实践：熟悉 Codex 与 OpenSpec 协作流程，能够完成需求澄清、规格设计、任务拆解、实现验证和变更归档。
这句话适合放在技术技能末尾。它只能作为入口，不能代替项目证据。真正有区分度的内容，应写在一个你能够完整讲解的项目下面。
📷 [图片 token=A1kDbpls6o2xPcxKXjncMn8Tn3c（未能下载，见飞书原文）]
🔥结合 OncallAgent 的可直接使用的项目描述
智能 OnCall Agent 平台｜AIOps 智能运维工作台
**项目介绍：**面向研发与运维团队构建的一体化 AI Agent 平台，整合知识库、智能对话与 AIOps 故障诊断能力，实现从业务咨询、告警分析、工具取证到诊断报告和案例沉淀的自动化闭环，降低 OnCall 人工检索与故障排查成本。
**技术栈：**FastAPI、Vue 3、TypeScript、LangChain、LangGraph、RAG、BM25、RRF、Rerank、SQLite、MCP、SSE、OpenSpec、Codex
个人职责：
负责 AI Agent 总体架构设计，基于 LangChain、LangGraph 构建知识索引 Agent、工具调用式 Chat Agent 和
Plan-Execute-ReplanAIOps Agent，实现知识检索、任务规划、工具执行与报告生成等能力。负责 RAG 知识库系统设计，将单路向量检索升级为“Milvus 向量召回 + BM25 关键词召回 + RRF 融合 + Qwen Rerank 精排”的混合检索链路，并实现文档分块、异步索引、权限过滤和答案引用。
负责 AIOps 诊断链路开发，接入真实腾讯 CLS 日志查询等 MCP 工具，实现“告警分析—知识检索—诊断规划—工具取证—根因分析—报告生成—案例入库”的完整闭环，并持久化诊断步骤与证据。
引入 OpenSpec 规范驱动开发流程，将跨前端、后端、数据库和向量存储的需求拆解为 Proposal、Design、Tasks 与 Delta Specs，明确 API/SSE 契约、tenant 隔离、异常分支和验收标准，推动 Codex 按规格完成实现与验证。
项目亮点：
设计模块化 Agent 工作流，由 Agent 根据上下文自主选择知识检索及 MCP 工具；AIOps 采用有界
Planner—Executor—Replanner—Report图编排，避免无约束执行并保证诊断过程可追踪。构建可解释的混合检索链路，同时保留 Vector、BM25、RRF 和 Rerank 各阶段分数与引用来源；检索及精排前严格应用 user、tenant、知识库和文档权限过滤。
将文档索引和 AIOps 诊断升级为持久化后台任务，支持服务重启恢复、客户端断线续跑、超时、重试和取消；结合 SSE 实时输出对话内容、工具状态与诊断进度。
通过 OpenSpec 建立“需求—设计—实现—测试—归档”的可追溯工程闭环，将 AI Coding 的临时对话上下文转化为仓库内长期规格，降低跨模块开发中的需求遗漏和契约不一致风险。
OpenSpec 相关项目职责（任选一条写即可）：
引入 OpenSpec 规范驱动开发流程，将功能需求沉淀为 Proposal、Design、Tasks 和 Delta Specs，建立从需求分析、技术设计到实现验收的可追踪链路。
使用 OpenSpec 管理知识检索、MCP 工具治理和 AIOps 诊断等跨模块变更，明确功能边界、异常分支、tenant 数据隔离与完成标准。
将大需求拆分为可独立验收的纵向闭环，协调共享 HTTP/SSE 契约、FastAPI 后端、Vue 前端、SQLite/Milvus 持久化和自动化测试同步演进。
结合 Codex 按 Tasks 执行实现，并通过 OpenSpec 校验、类型检查、后端测试、前端测试和文档构建核对实现与规格的一致性。
在变更完成后归档 OpenSpec 产物，使已经落地的行为进入长期规格，保留设计背景、验收依据和后续维护入口。
基于 OpenSpec 建立规范驱动开发流程，将需求拆解为 Proposal、Design、Tasks 与 Delta Specs，形成“需求—设计—实现—测试—归档”的可追溯闭环。
用一个真实功能讲清 OpenSpec 的价值
面试官通常不会停留在“你用过什么命令”，而会继续追问 OpenSpec 如何影响实际开发。此时可以用 OncallAgent 的混合检索链路举例。
📷 [图片 token=B1AibI0zxoWRszxy6buc6FXenQg（未能下载，见飞书原文）]
实现知识检索时，我没有把需求只写成“增加 RAG 功能”，而是先在规格中明确向量检索、BM25L、RRF 融合和 Rerank 各自承担的职责，同时规定检索必须携带当前用户、tenant、知识库和文档范围。随后把工作拆分为共享契约、后端检索、Milvus 过滤、引用返回、前端展示和测试验证。Codex 按任务执行后，再根据验收项核对权限过滤、无命中结果和失败状态。这样交付的不只是一个能够演示的接口，而是一条边界清楚、可以验证和继续维护的检索链路。
📷 [图片 token=LjNvbTs3poTsDJx4rqhcc8vhnhf（未能下载，见飞书原文）]
这段回答的重点，是展示你能够从功能名称继续下钻到边界、契约、失败处理和验收，而不是堆砌模型或框架名。如果你对混合检索不熟，也可以换成自己真正参与过的 MCP 连接、流式 Chat、知识文档索引或 AIOps 诊断变更。
📷 [图片 token=QC0YbVlJCooSsHxfQRFcnL0nnuf（未能下载，见飞书原文）]
面试时怎样回答“为什么要用 OpenSpec”
可以先从没有规范时的问题讲起，再说明 OpenSpec 如何改变协作方式：
单纯在聊天窗口里给 Codex 描述需求，早期看起来很快，但功能一旦涉及前后端、持久化、权限和测试，模型就容易遗漏约束。OpenSpec 的价值是把聊天中的临时上下文转成仓库内的长期事实来源。我会先通过 Proposal 说明为什么做和不做什么，通过 Design 确定关键边界，再把实现拆进 Tasks 和规格增量。完成后根据测试及验收项验证，最后归档进入主规格。这样 AI 负责提高执行速度，人仍然负责方向、边界和工程决策。
📷 [图片 token=KuNWbItKeoS2LZxkQ5AcVs3Cnqh（未能下载，见飞书原文）]
回答时不必把所有 OpenSpec 命令背一遍。面试官更希望确认你理解为什么先定义行为、为什么要保留非目标、为什么任务必须可验收，以及规格与实际代码不一致时应该怎样处理。
不要把工具经历包装成无法证明的成绩
下面几类描述看起来醒目，但很容易在追问中失分：
“精通 OpenSpec，研发效率提升 300%”——除非有明确的统计范围、基准和记录。
“使用 OpenSpec 自动生成完整项目”——OpenSpec 负责规格与变更管理，不替代工程判断。
“独立研发 OpenSpec 框架”——这TM是开源的，千万不要说是你做的，只是使用而已。
“通过 OpenSpec 保证代码零缺陷”——规范和测试能够降低风险，但不能承诺零缺陷。
只罗列 Proposal、Design、Tasks 等名词，却无法解释它们如何改变一次真实交付。
📷 [图片 token=Swn2bZkUyonyvBxW1l0cIA07nyg（未能下载，见飞书原文）]