这篇真正要收的，不是几个名词，而是控制面升级#

如果回头看 Part 2 前面四篇，它们其实已经把项目起盘最关键的判断收过一轮了：

1. 需求收敛收的是版本判断
2. 技术栈定盘收的是最小底板
3. 仓库起盘收的是协作界面
4. 系统设计收的是一页边界初稿

按理说，讲到这里，项目应该已经能继续往下做了。

但真实情况通常不是这样。
更常见的情况是：

• 大家知道需求不能直接丢给 AI 开写
• 也知道技术栈不能一次拍死
• 也知道仓库和系统边界要先立住
• 甚至已经写出第一版 proposal 和系统设计初稿

可一转身，团队又回到了老路上：

• 还是在聊天里临时提醒 AI 这次该注意什么
• 还是在评论区反复补“别顺手改这里”
• 还是靠人脑记住哪些边界要检查
• 还是每次重写一遍 issue、spec、design 的组织方式

所以 05 真正要收的，不是再认识一遍 Spec、Rules、Skills。
它真正要回答的是：

为什么前四篇收下来的判断，不能继续活在人脑、聊天记录和临场 prompt 里，而必须升级成项目控制面资产。

这一篇的主线只有一句话

AI Native 的升级，不是“文档变多了”，而是项目判断、长期边界和高复用经验，都开始被外置成可以稳定复用的控制面资产。

为什么前四篇讲完之后，光靠人记和临场 prompt 已经不够了#

这件事在传统开发里还没那么痛，是因为很多经验本来就默认装在工程师的隐性知识里。

比如：

• 看到某类需求，知道先补 issue
• 做状态流转设计，知道顺手检查审计和通知
• 碰到复杂模块，知道先想边界和职责
• 写 proposal 时，知道哪些该写、哪些不该提前写

以前这些东西靠“人比较熟”还能撑住。
但 AI 一旦进场，问题就会立刻暴露：

1. AI 没法稳定继承工程师的隐性经验
2. 临场 prompt 太依赖当下有没有想起来
3. 聊天记录不是可靠的长期载体
4. 同一类判断如果每次都重写，成本会越来越高

所以 AI Native 的问题从来不只是“模型够不够强”，而是：

那些原本靠资深工程师脑内调用的经验，到底有没有被外置出来。

Example：同一个退款需求，为什么光靠临场提醒一定会漂#

假设现在来了一个需求：

“退款驳回原因要标准化，并且以后可能会加双人复核。”

如果只靠聊天里的临场提醒，团队通常会说：

• 记得补驳回原因字段
• 记得考虑通知
• 记得考虑审计
• 记得设计时想想扩展性

这些话当然都对，但问题是它们都太依赖“这次有没有想全”了。
AI 这轮想到了三条，下一轮可能只想到一条；人这次补了通知，下次可能忘了审计。

这就是为什么前四篇讲的那些判断，如果不进一步沉淀，最后还是会退化成“反复口头提醒”。

AI Native 的升华，不是多写文档，而是把判断外置成控制面资产#

很多人会把这一步误解成：
既然 AI 不稳定，那就多写点文档、多写点规范、多加点说明。

但这还不够，甚至经常会适得其反。

因为“文档更多”不等于“控制面更强”。
真正的关键不是数量，而是这些判断有没有被放到正确的载体里。

这一步更准确的理解可以收成三件事：

1. 原来活在人脑里的判断，开始被写成结构化资产
2. 原来活在聊天记录里的提醒，开始被写成长期规则
3. 原来靠临场发挥调用的经验，开始被收成可复用能力

这时候，项目才算真正进入 AI Native 的下一层。
因为从这一步开始，AI 不再只是拿到一个任务就硬做，而是开始在一套外置控制面里工作。

一段最该被记住的短对照#

这才是这一篇真正的“升华感”所在。
不是项目里多了几个新名词，而是原来隐性的东西，终于开始被工程化。

为什么“多写文档”不等于控制面升级

还是拿退款审核系统举例。

第一种做法是飞书里补一页说明，聊天里提醒一句“记得通知和审计”，PR 评论里再补一句“以后还要考虑双人复核”。
这种做法文档确实更多了，但没有任何东西真的稳定下来，下一个人接手，还是要重新读、重新猜、重新补。

第二种做法是把这次 change 收成 proposal / design / tasks，把“状态流转改动必须同步检查通知和审计”沉淀成长期规则，再把“生成系统设计初稿”和“检查设计模式与异常链路”做成 skill。
这时候多出来的不是文档数量，而是可复用的控制面。

真正的主线，是把同一个问题在不同载体里一路收紧#

真正成熟的 spec-first 流程，不是“先有 issue，再有 OpenSpec，再有 skill”，好像每一层都是独立模块。
更接近真实项目的理解应该是：

同一个问题，会在不同载体里被连续压缩很多次。

最原始的时候，它只是讨论里的一个模糊判断。
进入协作之后，它先被压成 issue。
进入 change 之后，它又被压成 proposal.md、design.md、specs/ 和 tasks.md。
如果文档质量还不够，再由 skill 和 rules 继续把这些资产做深。

所以 05 更该讲清楚的，不是“OpenSpec、Rules、Skills 分别是什么”，而是：

一个问题到底怎样从讨论一路收成可实现的 change。

先把最容易混淆的几层放到一起看，会清楚很多：

这里最值得单独指出的一点是：
issue 和 proposal 经常在说同一件事，但它们不是重复文档。

• issue 面向的是协作系统，解决“这个问题为什么值得现在排进来”
• proposal 面向的是当前 change，解决“这个问题为什么值得为它开一组正式 spec 资产”

所以可以把 issue 理解成 proposal 的前一道收敛，但不要把它们写成互不相干的两条线。

参考：

• OpenSpec 官方站
• OpenSpec GitHub 仓库

同一个问题，为什么会先长成 issue，再长成 proposal

还是拿退款审核系统举例。

讨论里最早冒出来的可能只是一句：“退款驳回原因现在太散，后面可能还要加双人复核。”

这句话还不能直接实现。它先会被压成 issue，变成一个可协作的问题：

• 这次先只做驳回原因标准化
• 双人复核暂时不进入本轮
• 当前风险是审核状态流转和通知审计容易漏
• 验收口径是页面、数据契约和通知链路都要一致

等它再进入 OpenSpec change，proposal 才会接着把它变成正式立论：

• 为什么现在要开这个 change
• 当前 change 明确不做什么
• 哪些架构问题已经定了
• 哪些问题还不能在实现里偷偷拍板

这样看时，issue 和 proposal 不是两份互相陌生的文档，而是同一个问题在两个系统里的连续收敛。

从讨论到 issue：先把问题收成可协作对象#

如果没有这一步，后面的 proposal.md、design.md、tasks.md 很容易从一开始就建在松土上。
因为 OpenSpec 再强，也不负责替项目决定“这次到底先收哪一刀”。

GraphSpec 现有的 gh-issue-driven 正是在接这个断层。
它不是普通“帮忙建一个 GitHub issue”的 skill，而是把 discussion、OpenSpec seed 或零散请求，重新压成开发 issue：

• 先补背景和 why now
• 再补范围、非目标、未决点和子任务树
• 再按当前 phase 补最有价值的验收和验证要求

这一步真正接管的是：
把模糊讨论变成一个后面能继续被 spec-first 流程接住的问题。

GraphSpec 的 AGENTS.md 其实已经把这条要求写进仓库规则了：
如果由 AI 代创建开发 issue，优先使用 gh-issue-driven，而且 issue 不能退化成施工单，必须写出 why now、前置依赖、未决点和子任务树。

这就已经不是“仓库里恰好有一个 skill”这么简单了。
它说明项目开始把“讨论如何落成 issue”这件事，从人脑经验迁移成了控制面。

为什么 discussion 不该直接跳到 change

GraphSpec 的 v0-local-cli-view 这一轮，如果直接从讨论跳到实现，很容易变成下面这种失控：

• 有人觉得先把 scanner 做出来
• 有人觉得先画一版图
• 有人又想顺手把 CLI、Web、MCP 一起铺开

这些方向都像是在推进项目，但其实都还没回答同一个问题：当前到底先收哪一层不确定性。

而当它先被压成开发 issue 之后，问题就会变成更可操作的句子：

• 当前先收主图资产，而不是扫描器
• 当前先收 CLI 主入口，而不是完整 graph edit 协议
• 当前先收节点相关内容和证据层边界，而不是业务流全家桶

到这一步，OpenSpec change 才有可靠入口。

从 issue 到 OpenSpec change：proposal、design、specs、tasks 是同一个 change 的四个面#

很多文章一提 OpenSpec，就会下意识只写三份文档：proposal.md、design.md、tasks.md。
但只要真正去看实际 change，很快就会发现这还不够。

GraphSpec 的 v0-local-cli-view 这一轮，除了 proposal / design / tasks 之外，还有一组 specs/：

• specs/cli-init-view/spec.md
• specs/graph-schema/spec.md

这两份文件特别关键，因为它们把 change 继续往行为要求层压了一次：

• proposal.md 负责说明这次 change 为什么存在
• design.md 负责说明 change 准备怎么做
• specs/<capability>/spec.md 负责说明相关能力在行为上必须成立什么
• tasks.md 负责说明这些要求怎样被分解成可执行任务

如果没有 specs/ 这一层，proposal 很容易过于宏观，design 很容易过于解释性，tasks 又很容易直接退化成施工顺序单。
而有了 specs/ 之后，change 里就会多出一层非常重要的约束：

能力级要求必须被写成 requirement 和 scenario，而不是只停留在设计判断。

openspec-propose 这类 skill 真正值钱的地方，也就不再只是“帮忙生成三份文档”。
它的真正价值是把 change 所需的 artifacts 长出来，直到进入 apply-ready 的状态。
在实际 schema 下，这通常就不止 proposal / design / tasks，而是还会包含与 capability 对应的 specs/。

GraphSpec 的 specs/ 到底在补哪一层

v0-local-cli-view 这一轮里，proposal.md 已经把大方向说清楚了：

• GraphSpec 的主资产是架构图
• scanner 只能是证据层
• Phase 1 先做整体图、模块下钻和节点相关内容

但如果只停在这里，后面的实现仍然可能继续猜。

于是这轮 change 里又有两份 capability spec：

第一份是 cli-init-view/spec.md。它把 CLI 和视图这一层压成 requirement：

• CLI 必须作为主图资产的主入口
• view 必须支持整体图和模块下钻
• 节点详情必须返回相关内容
• scanner 只能作为辅助证据层

第二份是 graph-schema/spec.md。它把图资产这一层压成 requirement：

• 必须存在独立的主图资产
• 主图资产必须支持嵌套结构
• 主图资产必须支持多类关系
• 主图资产必须支持挂接证据
• 主图资产必须可被后续 CLI / Skill 读写

这样看时，specs/ 不是装饰层，而是在替 proposal 和 design 把行为要求钉死。

Design 和 Tasks 的强化，不是平行流程，而是在继续改同一个 change#

这里最需要单独说清的，是不要把“系统设计初稿”“设计模式检查”“任务并行规划”“验证入口设计”写成 OpenSpec 外面的第二套工作流。

更准确的写法应该是：

• 系统设计初稿，是在继续加固 design.md
• 设计模式、耦合度、可观测性、失败链路检查，是在继续加固 design.md
• 依赖关系、并行切片、review gate、验证动作，是在继续加固 tasks.md

也就是说，这些 skill 不是在 change 外面再包一层，而是在继续把同一个 change 做实。

这一点在实际试做出来的 Design 强化 skill 上特别明显。
一个真正合格的 design review skill，不会只写一句“请考虑设计模式和扩展性”，而是会强制同时读取：

• proposal.md
• design.md
• tasks.md
• specs/**/*.md

然后再去检查：

• 主资产 / 证据层 / 投影层边界
• 官方路径 / 兜底路径 / 禁止旁路
• 已定 / 待定 / 不进本 phase
• 同步 / 异步 / 编排决策
• 异常链路、回滚 / 补偿 / 审计
• 观测性
• 设计模式 / 反模式
• scanner 有没有越位
• proposal、design、specs、tasks 之间有没有互相打架

这时候，所谓“八股”“设计经验”“架构判断”才真正落了地。
它们不是漂浮在聊天里的提醒，而是被组织成一套继续改进 design.md 的工作流。

Tasks 也是一样。
一个值钱的 Tasks 强化 skill，目标不是把任务写得更多，而是把 tasks.md 从“施工顺序单”改成“交付图”：

• 哪些任务是串行阻塞项
• 哪些任务可以并行
• 哪些节点必须回看 design
• 哪些节点必须先过 build、test、benchmark、review
• 如果项目偏好多 Agent 并行，写入边界怎么切、合流点怎么设

为什么 Design 强化 skill 必须同时读 proposal、design、tasks、specs

还是用退款审核系统举例。

假设 openspec-propose 已经生成了第一版 change：

• proposal 写了“这次做驳回原因模板化，不做双人复核”
• design 写了“审核服务负责通知与审计”
• spec 写了“驳回原因必须标准化”
• tasks 写了“改数据库、改后端、改前端、测试”

如果这时只看 design.md，很容易觉得已经差不多了。

但一个真正会加固设计的 skill，不会只看这一份文件。它会顺手发现一整串更深的问题：

• proposal 说双人复核不进本轮，design 却已经开始给双人复核拍状态机
• spec 说的是行为要求，design 却还没说模板到底属于事实层还是配置投影
• design 已经引入通知和审计副作用，tasks 却没有任何 review gate 和失败链路处理节点

这时 skill 真正接管的，不是“多想一点”，而是跨 artifact 的一致性检查。

现成 skill 已经能接住前半程，后半程则继续往 Design 和 Tasks 上长#

顺着这条线再看 GraphSpec 现有 skill，意义会比“罗列技能清单”清楚得多。

如果把这张表按流程读一遍，就会发现：

• 前半程的“讨论 -> issue -> change 创建”，GraphSpec 已经有相当强的 skill 覆盖
• 后半程真正最需要继续长的，不是再来一个“再生成一遍 change”的工具
• 而是继续把 design.md 和 tasks.md 做深的 skill

这也是为什么后续最有价值的 skill，往往会集中在两类：

要减少人工调度，就把触发条件写进 skill description，把顺序写进 AGENTS#

全文如果只讲到这里，还是会留下一个现实问题：

这些 skill、rules 和 spec 资产虽然已经能串起来了，但如果每次都靠人工记住“现在该调用哪个 skill”，效率仍然会很低。

真正更高效的做法，通常有两层。

第一层：skill description 不是简介，它本身就是触发面#

如果 skill 的 description 只写成“一个用来优化设计的 skill”，那 agent 很难在正确时机主动想到它。
但如果 description 直接把触发条件写清楚，效果就会完全不同。

比如一个真正值钱的 Design 强化 skill，description 就应该明确写出类似这种语义：

• 当 change 已经创建完成
• 当目标是 review / tighten / patch design.md
• 当时机是在实现前，或者 issue 拆分前
• 当输入要同时读 proposal / design / tasks / specs

这样写时，description 就不再只是仓库说明文案，而是 skill 的渐进式索引入口。
agent 在创建完 change、准备进入实现、或者发现 design 质量不稳时，更容易自动加载到正确能力。

Tasks 强化 skill 也是一样。
description 里应该直接写明：它适合在 tasks.md 已经存在、但仍然太线性、太缺依赖图、太缺并行切片时触发。
这样 agent 才知道它不是“写代码之前随便看一眼”，而是特定节点上的下一步动作。

第二层：AGENTS 负责把整条顺序写死#

只有 skill description 还不够。
因为 description 解决的是“现在像不像该触发这个 skill”，而不是“整个仓库默认要求先做什么、后做什么”。

这一层更适合交给 AGENTS.md。

GraphSpec 当前的 AGENTS.md 其实已经在做这件事了：

• 如果由 AI 代创建开发 issue，优先使用 gh-issue-driven
• 如果由 AI 接手开发 issue，优先使用 gh-issue-delivery
• 解决 issue 前必须先提问、先产出可审核 spec、再等待人工审核
• tasks 必须按依赖关系和并行性组织，不能只写直线施工顺序

这就已经不是“技能列表”，而是仓库级流程编排了。

如果项目想进一步自动化，还可以继续把顺序写得更明确：

1. 讨论收住之后，先进入 gh-issue-driven
2. issue 确认后，进入 gh-issue-delivery 或等价的 issue-to-change bridge
3. change 生成后，自动触发 Design 强化 skill
4. design 收口后，自动触发 Tasks 强化 skill
5. 然后才进入 openspec-apply-change
6. 全部完成后再进入 openspec-archive-change

到这一步，项目就不再只是“有一堆 skill 可用”，而是开始有一条能够自己往前滚的控制面主线。

为什么 skill description 和 AGENTS 要一起用

还是用退款审核系统举例。

如果只有一堆 skill 文件摆在仓库里，团队通常还是要靠人工记住：

• 先写 issue，还是先开 change
• design 写完后要不要再 review
• tasks 拆完后要不要再做并行规划

这类工作很快又会退回口头调度。

但如果 skill description 已经写清触发条件，AGENTS 又把顺序写成默认规则，流程就会顺很多：

• 讨论收住后，AI 更容易先触发 issue skill
• issue 进入实现前，AI 更容易先触发 issue delivery 或 issue-to-change bridge
• change 创建后，AI 更容易继续触发 design review skill
• design 收口后，AI 更容易继续触发 tasks planner

这时候项目真正外置出来的，就不只是某个 skill，而是整条默认工作流。

到这里，Part 2 才真正收束#

Part 2 前四篇收下来的，是项目起盘阶段最关键的判断：
需求怎么收，技术栈怎么定，仓库先立哪些协作界面，系统设计先交出什么样的一页初稿。

05 再往前走了一步。
它真正收住的，不是“又认识了 OpenSpec、Rules、Skills 这几个名词”，而是看清了一条更完整的主线：

• discussion 先被收成可协作的 issue
• issue 再被收成 change 的 proposal
• proposal、design、specs、tasks 一起构成同一个 change 的不同收束面
• 系统设计初稿、设计模式检查、任务依赖图、并行切片，不是平行流程，而是在继续加固这个 change
• skill description 负责让正确能力在正确时机被触发
• AGENTS.md 负责把整条默认顺序写成仓库规则

所以这一章最后真正留下来的判断是：

AI Native 项目的升级，不是多了几个工具入口，而是项目终于学会把同一个问题从 discussion、issue、proposal、design、specs、tasks 一路收紧，并把这条顺序外置成可复用的控制面流程。

到这里，Part 2 才算真正完成。
前四篇把项目的起盘判断立住，这一篇则把这些判断推进成一套可以长期稳定生效的开发控制面。

下一篇：《从 Change 到 Execution Graph》