简打卡
51.76M · 2026-03-28
首先，要明确几个原则：
/compact 大概率是你任务拆分不合格理想的自动化闭环是这样的：
change_releases 表里，可追溯（remark 里记录 git commit ids、Linear issue ids、仓库 remoteUrl）。不再需要任何人手动写“更新说明”，也不用担心漏记或前后端版本冲突。
项目需求管理和问题追踪工具是多人研发团队必备的，可能是禅道、ONES或者飞书等。研发人员需要根据需求来开发功能、根据bug单来一个个处理问题、修复bug之后要标记状态；测试根据bug单来跟踪修复状态；项目经理要根据需求项目管理平台来跟踪研发进度...
但在现在，我们需要尝试用AI跑通这一系列的流程。
我们习惯用非结构化的自然语言表达需求，工具却需要结构化参数才能执行（Function Calling）。 而 MCP 将工具能力的描述与访问协议标准化了，让 Agent 可以识别和使用工具， 在自然语言与工具系统之间建立桥梁。
在这个场景中，如果有 Linear MCP 我们可以在 ChatBox 中用自然语言决定Linear tools的调用。
飞书太重了，不够垂直，且飞书 MCP目前只支持云文档场景。
Linear是专业的项目管理和问题追踪工具，可以将一个issue标记为 bug、feature、improvement 或者自定义的 labels，同样支持@团队成员等。最重要的是他支持MCP。
Linear MCP 提供了 30+ 个工具，分为以下几类：
| 类别 | 工具 | 功能 |
|---|---|---|
| Issues | list_issues, get_issue, save_issue | 列出/获取/创建更新 Issue |
| Teams | list_teams, get_team, list_users | 列出团队、成员 |
| Cycles | list_cycles, get_cycle | 列出周期（Sprint） |
| Projects | list_projects, get_project | 列出项目 |
| Labels | list_issue_labels, create_issue_label | 管理标签 |
核心是 list_issues 和 save_issue：
list_issues 可以筛选团队、状态、负责人、标签等save_issue 可以创建或更新 Issue（根据是否传入 id 判断）tips:
如果你想要知道自己接入的 MCP 有哪些 tools，你可以尝试直接在TRAE/cursor等编辑器的设置找到（当然你直接问agent也可以）：
根据文章开头提到的原则，我们应该让一个 skill 只专注于解决一种相关的流程，所以这专门写个关于 linear的 skill。
注意，很多ai编辑器或ai cli现在都已经内置了 skill-creator 这个 skill，你可以直接把场景和流程告诉它，让它生成，以下是我的原话：
最终生成的 skill内容：（当然你也可以说他是一个rule，但rule和skill的区别这里就不展开说了）
变更日志写给谁看？这是最先要想的问题。
现状非常尴尬：
fix: handle null in payment service —— 老板看不懂，客户更看不懂所以很快就能得出几个基本结论：
Git 才是唯一的真相源
所有代码变动最终都会落在 git commit 里，绕不过去，也最可靠。
Linear 是非常有价值的“上下文补充”，但不能当唯一来源
变更日志必须是给人看的，不是给程序看的
所以要用自然语言、分级标题、面向用户表达，而不是堆砌 commit message 或 issue 标题。
技术实现要可追溯，但不能让追溯信息污染用户阅读体验
→ 把 git commit id、linear issue id、仓库地址等放一个单独字段（remark），用户看不到，前端也不渲染。
图 4-1：代码变更 / Git记录、Linear待办项与最终变更日志的关系
graph TD
A["Git Commit / 代码变更n（唯一真相源）"] -->|关联| B["Linear Issue / 待办项n（上下文补充参考）"]
B -->|关联| C["最终变更日志 contentn（面向用户输出）"]
A -->|记录到| D["remark字段n（可追溯信息）"]
B -->|记录到| D
基于以上思考，最终决定采用最简单也最灵活的方案：
CREATE TABLE change_releases (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
content TEXT NOT NULL COMMENT '面向用户渲染的 Markdown 内容',
remark TEXT COMMENT 'JSON 格式，存放 git remote url、commits、linear issues 等追溯信息',
publish_time DATETIME NOT NULL COMMENT '发布时间',
publisher VARCHAR(100) COMMENT '发布人（或触发者）',
project VARCHAR(100) COMMENT '项目标识，用于多项目区分',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
核心字段作用一览：
| 字段 | 作用 | 谁看 / 谁用 |
|---|---|---|
| content | 用户真正看到的变更文案（Markdown） | 老板、产品、客户、前端渲染 |
| remark | 机器用的追溯信息（仓库地址、git commit ids、linear issue ids 等） | 排查问题、审计、未来数据分析 |
| publish_time | 发布时间 | 排序、展示 |
remark 字段示例（JSON）：
{
"remoteUrl": "https://github.com/team/project.git",
"gitCommitIds": ["abc1234", "def5678", "ghi9012"],
"linearIssueIds": ["ENG-123", "ENG-456", "DES-78"],
"generatedBy": "change-releases-skill",
"project": "your-project"
}
即使几年后仓库地址迁移、改名、迁移到别的平台，只要 remark 里有 remoteUrl，就能快速定位到正确的仓库去查 commit 历史。
## 本次变更内容
### 功能更新
- 新增了支付方式 - Apple Pay / Google Pay
- 支持自定义发票抬头
### 体验优化
- 大幅缩短订单提交加载时间（平均减少 1.8 秒）
- 优化了商品详情页的图片预加载逻辑
### Bug 修复
- 修复了 iOS 端部分用户重复扣款的问题
- 修复了优惠券在特定场景下无法抵扣的异常
前端展示 + AI 发布共需 2 个接口：
| 接口 | 方法 | 路径 | 用途 |
|---|---|---|---|
| 新增变更日志 | POST | /api/admin/change-releases | AI 生成日志后写入数据库 |
| 查询变更日志 | GET | /api/admin/change-releases | 前端分页展示历史记录 |
现在需要写一个专门针对于生成系统变更日志的skill，还是借助于skill-creator这个skill，直接和agent说明这个流程触发的场景，以及具体的流程步骤等：
最终生成的skill目录结构如下：
.cursor/skills/change-releases/
├── SKILL.md
├── assets/
│ └── config.json
└── scripts/
└── releases.py
生成结果如果和预期有偏差需要微调，最终内容因篇幅原因这里就不展示了。
在最开始 rules 出现时就有一个最佳实践是，要 在项目开发中 持续完善rules，一次性写出完美的 rules 是不切实际的。
skill 也一样，我们使用 skill-creator 快速创建一个 skill 之后很可能是和我们预想的有所偏差，偏差原因可能是因为你最开始的 prompt 不够明确，也可能是你描述触发时机不够准确，又或是会存在你预期之外的流程分叉。但无关紧要，我们可以自己 观察触发 skill 时，agent 的思维链，要敏锐捕捉到 agent 在执行skill 流程中和预想中不一样或者是出错的情况，然后去完善。
举个例子：
以上是我第一次执行这个skill 时 agent 的思维链，其中当它发现 Linear MCP 工具不可用时，它无视了这个情况，它会直接根据变更内容生成版本日志。但我认为这会导致功能发布了，但是 issue 没有自动关闭。这里我需要它向我主动确认是否继续执行。后面省略一些调试、优化过程...直接看下面效果。
1. 用 AI 解决流程问题，而不是用 AI 写代码
代码只是执行，流程自动化才是更高维度的效率提升。
2. 技术平权，但工程化思维不可替代
会描述流程本身就是一种稀缺能力。
3. 自然语言描述力 = 生产力
能不能把事情说清楚，决定了 AI 能不能帮你把它实现出来。
4. 发现问题的慧眼比解决问题的能力更稀缺
大多数人只是抱怨重复性工作，而不是去自动化它。
5. 持续迭代的方法论意识
建立"执行 → 观察偏差 → 修正 → 再执行"的闭环。
AI 编程的本质不是让 AI 替代你写代码，而是让你从重复性工作中抽身，把精力放在真正需要思考的地方。时刻保持对身边重复性工作的敏感度，发现它，然后解决它。
