1. 从手动填坑到AI代劳一个开发者的真实痛点每次产品迭代发布前最让我头疼的不是代码合并冲突也不是线上Bug修复而是坐在那里对着空白的文档一个字一个字地敲变更日志。这活儿说难不难就是繁琐。你得从Linear我们团队用的项目管理工具里把过去一个周期里所有关闭的Issue和PR链接一个个找出来然后根据功能、修复、优化这些类别手动分类再提炼出用户能看懂的人话描述。一个版本下来几十个提交项整理加润色没个把小时根本搞不定还容易漏掉关键项或者分类错误。更别提有时候忙起来这事儿就拖到发布前最后一刻仓促写出来的东西自己都看不下去。直到我接触到了MCPModel Context Protocol和Skill的概念整个工作流才迎来了转机。简单来说Skill可以理解为给AI大模型比如Claude、GPT安装的“技能插件”让它能调用外部工具或访问特定数据而MCP则是这些Skill与AI模型之间通信的标准化协议。当我把Linear的MCP Server配置好再结合一个专门编写变更日志的SkillAI就能自动读取Linear项目数据理解提交历史并生成结构清晰、语言专业的变更日志草案。这个过程我称之为“Skill MCP Linear”的自动化工作流。它解决的远不止是“省时间”的问题更是将开发者从重复、低创造性、高错误率的文档工作中解放出来让我们能把精力真正聚焦在代码和产品逻辑本身。无论你是独立开发者、小团队的技术负责人还是大厂里疲于应付流程的工程师这套自动化方案都值得你花十分钟了解一下。2. 核心组件拆解Skill、MCP与Linear如何协同工作在动手搭建之前我们必须先理清这三个核心组件各自扮演的角色以及它们是如何串联起来的。很多人一开始容易混淆Skill和MCP或者不明白为什么需要MCP这个“中间层”。2.1 Linear项目管理的“事实来源”Linear是我们这个工作流的数据源头。它是一个非常优秀的项目管理工具尤其受科技公司和产品团队青睐因为它设计简洁、速度快并且与开发者工作流如GitHub集成得很好。在我们的场景里Linear承载了所有功能需求Feature、故障修复Bug、优化改进Improvement的Issue。每个Issue的标题、描述、状态是否完成、所属周期通过Milestone或Cycle标记、关联的Git提交或PR链接都结构化的存储在这里。AI需要获取的正是这些已经由开发团队标记和关闭的、关于“本次发布做了什么”的原始信息。没有这个高质量、结构化的输入后续的自动化就成了无源之水。2.2 MCPAI与外部世界的“安全通道”MCP全称Model Context Protocol是由Anthropic提出的一种开放协议。你可以把它想象成AI模型的USB-C扩展坞。原生的大模型就像一个只有基础功能的笔记本电脑它很强大但无法直接读取你Linear里的数据也无法操作你的日历或数据库。MCP定义了一套标准化的通信方式让外部的工具称为MCP Server能够以一种安全、可控的方式向AI模型MCP Client提供额外的“能力”或“上下文”。在这个工作流中我们需要一个“Linear MCP Server”。这个Server本质上是一个小型的后台服务它知道如何用Linear的API密钥去认证并按照MCP协议规定的格式对外提供诸如“获取某个项目下所有已关闭的Issue”、“查询某个Cycle内的变更”等功能。AI模型通过支持MCP的客户端如Claude Desktop、Cursor或Codex不需要知道Linear API的细节它只需要按照MCP协议向这个Server发送请求比如“请给我项目A在最近一个Cycle内的所有已完成Issue”Server就会处理好认证和API调用并把整理好的数据返回给AI。注意MCP的核心价值在于“标准化”和“安全”。标准化意味着不同的工具Linear, Jira, Notion只要实现了MCP Server就能被同一个AI客户端使用安全意味着你可以严格控制AI能访问哪些数据通过Server的权限控制而不是把API密钥直接交给AI。2.3 SkillAI执行具体任务的“操作手册”如果说MCP给了AI“伸手”的能力那么Skill就是告诉AI“手该怎么动”的指令集或工作流程。一个Skill通常包含对AI的指令Prompt、可能用到的工具Tools这里就包括通过MCP暴露的Linear工具以及一些逻辑判断。针对“生成变更日志”这个任务我们会创建一个或使用一个现成的Skill。这个Skill的指令可能是“你是一个专业的工程师请根据提供的Linear项目数据生成一份面向用户的变更日志。请将变更分类为‘新功能’、‘功能改进’、‘问题修复’等并使用清晰、简洁的语言描述每一项。同时生成一份面向开发团队的、包含更多技术细节的内部版本说明。”当这个Skill被激活时AI客户端会首先通过MCP调用Linear Server获取原始数据。然后AI会基于Skill中的指令对数据进行理解、分类、归纳和重写最终输出符合要求的变更日志。Skill的质量直接决定了输出结果的专业度和可用性。3. 环境搭建与配置从零开始手把手连接理论清晰后我们进入实操环节。这里我以目前兼容性较好的Claude Desktop作为MCP Client和cursor作为代码编辑器兼AI客户端为例演示如何搭建整个环境。你可以根据自己常用的工具进行调整。3.1 第一步准备Linear访问凭证一切始于Linear API。你需要一个具有项目读取权限的访问令牌。登录你的Linear工作空间。点击右上角个人头像进入“Settings” - “API”。点击“Create personal API key”。为它起个名字比如“Changelog-AI-Agent”。创建成功后立即复制生成的API Key并妥善保存。它只会显示一次。为了后续测试方便你还需要知道你的项目ID。在Linear中打开你的项目浏览器地址栏的URL通常包含类似.../project/team-name-123/...的结构其中team-name-123就是项目ID。或者你也可以通过Linear的API或GraphQL playground来查询。3.2 第二步配置MCP Server以linear-mcp为例我们需要一个实现了Linear API的MCP Server。社区中有多个选择例如linear-mcp。这里我们使用一个基于Node.js的流行版本进行配置。确保Node.js环境你的电脑上需要安装Node.js建议版本16和npm。安装MCP Server打开终端全局安装或克隆相应的Server。例如对于某个特定的linear-mcp包你可能需要npm install -g modelcontextprotocol/server-linear请注意包名可能变化请以GitHub上最新项目为准。如果没有合适的全局包你可能需要克隆GitHub仓库进行本地运行。配置Server连接信息MCP Server需要你的Linear API Key才能工作。通常你需要通过环境变量来传递。在终端中可以临时设置export LINEAR_API_KEY你的Linear_API_Key为了持久化更推荐将配置写入Claude Desktop或Cursor的MCP设置文件中。3.3 第三步在AI客户端中启用MCP Server这是最关键的一步告诉你的AI客户端去哪里找这个新加的“扩展坞”。对于Claude Desktop找到Claude Desktop的配置文件夹。在macOS上通常是~/Library/Application Support/Claude/claude_desktop_config.json。在Windows上是%APPDATA%\Claude\claude_desktop_config.json。编辑这个JSON文件添加你的MCP Server配置。一个配置示例可能如下{ mcpServers: { linear: { command: npx, args: [ -y, modelcontextprotocol/server-linear ], env: { LINEAR_API_KEY: 你的Linear_API_Key, LINEAR_PROJECT_ID: 你的项目ID可选用于限定范围 } } } }保存文件并完全重启Claude Desktop。重启后在聊天界面你应该能看到一个新的工具图标比如一个螺丝刀或插件图标点击它如果能看到“Linear”相关的工具如list_issues说明配置成功。对于CursorCursor内置了MCP支持。打开Cursor进入设置Settings。找到“MCP Servers”或“AI Tools”相关配置项。其配置方式可能与Claude Desktop类似也是通过JSON配置。你需要参考Cursor的官方文档添加上述linearserver的配置。配置完成后在Cursor的AI聊天框中你应该能通过提及或工具调用的方式使用Linear功能。3.4 第四步创建或应用Changelog Skill现在通道已经打通我们需要定义任务。如果你使用的AI客户端支持Skill市场如Codex可以直接搜索“changelog”、“release notes”相关的Skill并启用。如果找不到或者你想高度定制就需要自己编写Skill指令。一个基础的Changelog Skill指令Prompt可以这样写你是一名技术文档工程师。请根据我提供的Linear项目数据生成一份本次软件发布的变更日志。 **数据来源**我将通过Linear工具为你获取项目“你的项目名”在上一个发布周期或指定Cycle内所有状态为“Done”的Issue。 **请你完成以下任务** 1. **获取数据**使用Linear工具列出相关Issue。 2. **分析归类**仔细阅读每个Issue的标题和描述。根据其内容将其归类到以下类别中 - 新功能 (New Features): 新增的用户可见功能。 - ✨ 功能改进 (Improvements): 对现有功能的优化和增强。 - 问题修复 (Bug Fixes): 修复的程序错误。 - 技术债 (Technical Debt): 代码重构、性能优化等底层变更。 - 文档 (Documentation): 文档更新。 3. **撰写内容** - 为每个类别生成一个章节。 - 对每个Issue用一句**简洁、面向用户**的话描述变更。避免使用技术术语和提交哈希。例如将“Fix null pointer exception in user profile API”改写为“修复了用户个人资料页面在某些情况下无法加载的问题”。 - 如果Issue关联了GitHub PR或Commit请在描述后附上链接格式为 [#PR编号] 或 [Commit缩写]。 4. **输出格式**最终输出一个格式良好的Markdown文档包含版本号如v1.2.0、发布日期如果已知和上述分类列表。 **开始吧**。首先请使用Linear工具获取数据。你可以将这个Prompt保存为一个文件或在支持Skill的客户端中将其创建为一个自定义Skill。当需要生成日志时只需激活这个SkillAI就会自动执行上述流程。4. 工作流实战一次完整的自动化日志生成过程配置好环境后让我们跑通一个完整的场景看看AI是如何一步步包揽这项工作的。假设我们刚刚完成了一个开发周期Linear中的Cycle 15准备发布版本v1.5.0。4.1 触发与数据获取我打开Claude Desktop在聊天框中输入“请运行‘生成变更日志’技能针对项目‘WebApp’在上一个已结束的CycleCycle 15内的变更准备版本v1.5.0的发布日志。”AI接收到指令后首先会识别出需要调用Linear MCP Server。它在后台执行的操作类似于我们手动调用工具调用list_issues并附带过滤器参数如projectId: webapp-123,cycleId: cycle-15,state: { name: { eq: Done } }。MCP Server响应Server接收到请求使用配置的API Key向Linear的GraphQL API发起查询获取到一份结构化的Issue列表其中包含每个Issue的title,description,state,labels,url等信息然后通过MCP协议返回给AI客户端。这个过程对我完全透明我不需要编写任何GraphQL查询语句。4.2 AI的理解、分类与重写AI拿到原始数据后就进入了核心处理阶段。它会逐一分析每个Issue原始Issue标题“[Bug] User avatar sometimes fails to upload on slow network”AI分析识别标签Bug理解内容是上传功能在网络不佳时失败。这属于“问题修复”。重写输出“修复了在网络连接较慢时用户头像上传可能失败的问题。”原始Issue标题“[Feature] Add dark mode toggle in user settings”AI分析识别标签Feature内容是新增深色模式开关。这属于“新功能”。重写输出“在用户设置中新增了深色模式切换开关。”原始Issue标题“Refactor payment service to use idempotency keys”AI分析没有功能或Bug标签描述涉及代码重构和支付幂等性。这属于“技术债”或“后端改进”。重写输出“重构支付服务引入幂等键以防止重复扣款。”在这个过程中AI不仅在做简单的文本匹配而是在理解语义。这是手动复制粘贴无法比拟的。我实测中发现只要Issue的标题和描述写得相对清晰这也是个好习惯AI的分类准确率能达到90%以上。对于模糊的条目我可以在生成的草稿上快速修正这比从零开始撰写要轻松太多。4.3 输出、审查与发布AI处理完所有Issue后会按照Skill中规定的格式输出一份完整的Markdown文档# v1.5.0 变更日志 (2023-10-27) ## 新功能 - 在用户设置中新增了深色模式切换开关。 - 支持通过CSV文件批量导入用户数据。 ## ✨ 功能改进 - 优化了仪表板的数据加载速度大幅减少首次渲染时间。 - 搜索结果的排序逻辑现在更符合用户预期。 ## 问题修复 - 修复了在网络连接较慢时用户头像上传可能失败的问题。 - 修复了在Safari浏览器中日期选择器显示错位的bug。 - 解决了移动端侧边栏偶尔无法关闭的问题。 ## 技术变更 - 重构支付服务引入幂等键以防止重复扣款。 - 升级了内部日志库版本提升错误追踪能力。我的工作就变成了审查者和编辑。快速浏览一遍检查是否有分类错误比如把某个重构误认为新功能或者描述是否足够清晰。通常我只需要花5分钟做微调就可以直接复制这份日志到GitHub Release、内部Wiki或者发布公告中。5. 进阶技巧与个性化定制让AI更懂你的团队基础流程跑通后你可以根据团队的具体需求对这个工作流进行深度定制让它产出质量更高、更贴合你们文化的文档。5.1 定制分类与标签映射不同的团队对变更的分类可能不同。你可能想增加“安全更新”、“实验性功能”或“用户体验优化”等类别。这可以通过修改Skill指令中的分类列表来实现。更高级的用法是利用Linear的标签系统。在Linear中为Issue打上诸如changelog:feature、changelog:bug、changelog:infra的标签。然后在Skill指令中告诉AI“请根据Issue的标签进行首要分类。如果标签包含changelog:feature则归入‘新功能’如果标签包含changelog:bug则归入‘问题修复’……对于没有特定changelog标签的Issue再根据其标题和内容进行智能分类。”这样做的好处是分类权完全掌握在开发人员手中AI只需执行明确的映射规则准确率接近100%。这要求团队养成打标签的习惯但一旦形成流程收益巨大。5.2 融入团队写作风格与规范每个团队的文档风格各异有的喜欢活泼emoji风有的要求严肃正式。你可以训练AI模仿你们的风格。方法一在Skill指令中提供范例。在指令末尾添加“请参考以下风格示例进行撰写”示例风格“‘登录页面视觉焕新采用了更现代的配色方案和布局。’这是一个改进描述”避免风格“‘更新了登录页面的CSS。’过于技术化”方法二提供历史变更日志作为参考上下文。在运行Skill前你可以将上一两个版本的优秀变更日志作为上下文粘贴给AI并说“请模仿以上文档的语言风格和详细程度撰写新版本的日志。” AI在生成时会学习其中的措辞和结构。5.3 实现完全自动化与CI/CD管道集成终极目标是让这个过程在每次代码合并到发布分支时自动触发。这需要将AI客户端和Skill脚本化。一种思路是使用支持命令行调用的AI工具如通过OpenAI API编写一个Node.js/Python脚本。这个脚本的工作流程是监听GitHub仓库的main分支推送事件通过GitHub Actions。触发脚本脚本调用Linear API获取自上次Tag以来的所有已关闭Issue。将Issue数据整理成Prompt发送给大模型API如GPT-4。接收AI生成的Markdown自动创建GitHub Release草案或提交一个包含变更日志的PR。这样每当完成一个发布周期开发人员只需合并最后的PR一份初步的变更日志就已经静静地躺在Release页面等待最终审核了。这实现了从“开发-管理-发布”文档的闭环自动化。6. 常见问题与避坑指南在实际搭建和使用的过程中我踩过不少坑。这里总结几个最常见的问题和解决方案希望能帮你节省时间。6.1 MCP Server连接失败或权限错误问题现象在AI客户端中看不到Linear工具或者调用工具时返回“Authentication failed”或“Permission denied”。排查步骤检查API Key这是最常见的问题。确保你的Linear API Key没有过期且具有足够的权限至少需要对你指定的项目有读取权限。可以在终端用curl命令快速测试curl -H Authorization: Bearer YOUR_API_KEY https://api.linear.app/graphql -d {query: { issues(first: 1) { nodes { title } } }}如果返回错误说明Key有问题。检查环境变量确认MCP Server的配置文件中LINEAR_API_KEY环境变量是否正确设置并且被Server进程读取到。有时在图形化客户端中配置环境变量容易出错可以尝试在启动Server的命令行中直接设置。检查项目ID如果你在配置中指定了LINEAR_PROJECT_ID请确认这个ID是否正确并且API Key有权访问这个特定项目。重启客户端修改MCP配置后必须完全退出并重启Claude Desktop或Cursor否则新配置不会生效。6.2 AI生成的分类或描述不准确问题现象AI把某个Bug修复归类到了“新功能”或者对某个技术重构的描述过于晦涩或过于简单。解决方案优化Issue源头AI的输入质量决定输出质量。推动团队在创建和关闭Issue时撰写清晰、具体的标题和描述。例如“Fix bug”是糟糕的标题“Fix crash when submitting form with empty optional field”就好得多。细化Skill指令在Skill的Prompt中提供更详细的分类规则和描述范例。比如明确说明“如果Issue标题或描述中包含‘refactor’、‘migrate’、‘upgrade library’等关键词优先考虑归入‘技术变更’类。”人工审核的必要性必须认识到目前这仍是一个“AI辅助”流程而非“AI全权负责”。将AI定位为“高级起草助手”它的价值是完成80%的机械性工作剩下的20%需要人类进行质量把关和风格润色。这个比例随着你指令的优化和团队习惯的养成可以不断提高。6.3 处理大量Issue时的性能与上下文限制问题现象当一个发布周期包含上百个Issue时AI可能无法一次性处理所有数据或者响应缓慢。应对策略分批次处理在Skill指令中让AI先获取Issue的数量如果超过某个阈值比如50个则分多次获取和处理。例如“请先获取Cycle 15中Done状态的Issue总数。如果超过50个请先获取前50个并进行处理完成后我再给你下一个批次。”利用Linear筛选器在MCP工具调用时使用更精确的过滤器减少不必要的数据传输。例如可以按标签筛选只获取打有changelog相关标签的Issue忽略那些内部重构或不需对外公布的变更。总结与归纳对于非常庞大的变更集可以要求AI先进行总结归纳而不是列出每一项。例如“请先总结本次发布的3-5个最主要亮点然后再分大类列出所有变更。”这样既保证了重点突出又满足了完整性需求。6.4 与现有工作流的融合问题团队已经有用Git提交信息生成日志的脚本或者在使用其他工具如Jira。思路MCP和Skill的灵活性正在于此。你完全可以创建一个更强大的Skill让它同时调用多个MCP Server。可以配置一个git-mcpserver来读取仓库提交历史。再配置linear-mcpserver读取项目管理数据。 然后在Skill指令中要求AI“请综合分析来自Linear的Issue列表和来自Git仓库的提交历史合并去重生成一份统一的变更日志。”这样就能融合多个数据源得到更全面的视图。对于使用Jira的团队只需寻找或开发一个jira-mcpserver即可Skill的逻辑可以基本复用。从我自己的实践来看引入这套自动化工作流后撰写发布日志从一项令人厌烦的“作业”变成了一个只需点击几下、稍作审核的轻松环节。它带来的不仅是时间上的节省更是一种心理上的减负——你知道这项繁琐但重要的工作已经被可靠地系统化了。技术的进步不就是为了把人从重复劳动中解放出来吗现在是时候让AI来包揽这些变更日志工作了。