开发编程进化论：openspec的魔力

1. 开发进化论：从 Autocomplete 到 Vibe Coding，再到 SDD：

阶段	AI 的角色	典型场景	代表技术 / 工具	主要价值
Autocomplete	🧩 辅助书写	自动补全、函数生成、快速模板化	GitHub Copilot,	提高编码速度与一致性
Vibe Coding	🤝 协作伙伴	上下文理解、代码重构、跨文件逻辑联动、自动打 tag	Cursor Agents, Claude Code	提升协作效率、减少重复劳动
SDD (Spec-Driven Development)	🧠 联合设计者	读取 PRD / Wiki、生成 OpenSpec、任务追踪、变更归档	openspec, spec-kit	建立上下文一致性与变更可追溯性

2. openspec 实践

2.1 基本介绍与使用

简单介绍与使用可以直接参考官方文档。GitHub

2.2 使用及过程中遇到的问题

bash 复制代码

`/openspec-proposal`  
Here is the PRD address link https://wiki.hosecloud.com/pages/viewpage.action?pageId=487751864 .  
Understanding the PRD, then proposal the spec for me. If you have doubt, Don't worry about bothering me.

发现了一些问题：

因为配置了 "mcp-atlassian "，所以是希望都能调用 MCP 去获取信息，但是偶先会使用fetch去爬虫获取。
生成的文档需要改动的文件、逻辑与正在实现的逻辑相差甚远。
文档中缺少需求涉及的流程信息、关键代码等

2.3 优化过程

1.3.1 优化mcp使用

这个可能是个人困局。之前我一直以为配置了MCP之后，在特定场景里会自动触发。比如在prompt中出现了wiki或者jira时，会在需要详情时自动调用mcp-atlassion获取内容。但是这样并不稳定，会偶尔用"网页搜索"的方式去获取数据。而网页搜索其实是在爬虫，如果涉及到权限等问题，基本就无法访问了。mcp通过配置权限参数就能解决这个问题。mcp提供的各种工具，类似 markdown形式输出让获取的内容更加具有可读性。

使用 use mcp-atlassion ，基本能稳定触发 mcp工作。

1.3.2 生成的文档需要改动的文件、逻辑与正在实现的逻辑相差甚远。

原因可能是：

费控主应用的项目过大，文件特别多，类似的文件名、函数名非常多
openspec 生成规范时使用的文档中涉及的关键词，借助 grep、 search 进行全局搜索

虽然openspec的 AGENT.md中备注了存在疑问时，会提一两个问题来澄清，但是基本也解决不了这个问题。

If request is ambiguous, ask 1--2 clarifying questions before scaffolding

解决方式：手动提供上下文的能力。

咱们去理解上下文，然后把核心逻辑的文件地址、函数名提供给模型。甚至用Browser Tab提供相关逻辑的重要的元素给模型。

1.3.3 文档中缺少需求涉及的流程信息、关键代码等

模型是根据 openspec提供的 AGENT.md来生成文档规范的，咱们可以微调提示词让其满足自己的需求。没有标准答案，只要能提高效率、帮助到咱们开发都是好答案。

解决方式：微调 openspec，让输出文档包含自己期望的特性。

1.3.4 优化之后的结果

vbnet 复制代码

/openspec-proposal 

I've shared the PRD here: https://wiki.hosecloud.com/pages/viewpage.action?pageId=487751864. using the **"mcp-atlassian"** .

Please read and understand the PRD thoroughly, then draft a **openspec proposal** based on the context.

Here are some files that related to the PRD updates, and they must help you a lot.
1. feeDetail edit mode @FeeDetailEdit.js 
2.  RelatedDetail is in @RelatedDetails.tsx 
3. feeDetail readonly mode @FeeDetailReadonly.js 
4. RelatedDetail in readonly mode is in @RelatedDetails.readonly.tsx  file
5. the render login of the missed content is in "DetailItemExpandFields"  component @DetailItemExpandFields.js 

Don't hesitate to ask follow-up questions if something is unclear --- I'd rather you verify than assume.

Aim for a concise, well-structured document that could serve as the foundation for development discussion.

结果：

mcp工具文档调用
精确的上下文，更快速高效地定位需求改造点。

文档中包含了需求的流程代码

openspec/AGENTS.md 中包含了该 Agent 的prompt，根据自己的需求微调，使其更加符合咱们自己的场景。

2.4 openspec提供的价值之一：快速追溯

因为openspec保留提案里的所有规范、设计、任务等详细数据，使用openspec的历史信息可以快速定位、修复问题。

这里其实很依赖于jira里的详细描述，因为这个bug的描述很清楚，所以 AI立马能明白这个问题是什么（也反映了提示词的重要性）。

2.5 trade-off

是否使用openspec：

Pro:

能够更加明确需求
1. Review the proposal with your AI assistant until everyone agrees.
规范即文档
1. 如果你对之前的需求上下文不了解，可以在openspec文档帮助下，更快速熟悉上下文。
2. 你的修改会有完整的历史记录，基于spec也可以做出快速修改（你或者同事都可以）
spec可能提供多种实现方案可选，轻松打破认知壁垒。
方案的选择、落实也有迹可循（2.4 也体现了这一点。）

Con：

真的挺费 Tokens

2.6 工具

mcp-atlassian github.com/sooperset/m... 快速获取wiki、jira内容
提示词优化工具

prompt参考来源：prompts.chat/embed/?prom...

3. DRY：创建AGENT

在不同的需求，我们都要使用类似上面的流程，所以这里可以通过创建通用agent去简化这个流程。

基于上面的流程，可以创建了一个 wiki-spec-generator agent。

claude本身的create agent 是自带优化提示词的:

bash 复制代码

1.通过`mcp-atlassian`提取wiki链接资源  
2.让用户提供核心逻辑文件、函数等，甚至是可能的解决方案。
3.调用 openspec command 生成文档

然后可以通过

ini 复制代码

wiki-spec-generator https://wiki.hosecloud.com/pages/viewpage.action?pageId=487751864

4. 感谢

最近微调提示词才发现这真的是一个工程，对我来说真的很难。需要时间和精力不断地打磨。我还是一个初学者，如果文章中有不对的地方，欢迎来聊，不惜赐教。

感谢大家听我的分享。如果我的经验对你有一些帮助或者引起你的一些思考，那我就很荣幸了。