Pi与SDD开发流程

写这篇文章有几层意思：一是把自己这两年的 AI 编程工具选型史理一遍；二是交代我为什么在 OpenSpec、Superpowers、grill-me 之间最终选了 OpenSpec；三是把我现在每天都在用的 op-* 五段式流程和五个 prompt 原文存档，给未来的自己留个底。

文章标题叫「Pi与SDD开发流程」，但你要说它是「我的 AI 工作流养成记」也行——内容就是这么个东西。声明一下：以下对比全部基于 2026-09 为止我自己的使用体感，不是评测，不跟版本。

工具选型：从 opencode 到 pi

迁移史

我重度用过一段时间的 opencode。单任务、单会话的场景下它够用，我的习惯也是从那时候养成的——贴需求、看 diff、提意见，循环往复。

但任务一多就卡住。不是某一类任务卡，是「多任务并行」这件事它扛不住：会话一多上下文互相不记得，改了个文件回头就忘了谁改的，任务顺序一乱整个会话就迷路。到后期我几乎是能不开新任务就不开，全挤在一个会话里，结果更卡。

后来迁到 pi，日常的改代码、架构讨论、写文章，慢慢全由 pi 接管。真正让我下定决心的不是某个 bench 数字，而是它把任务拆开、分派、并行这一套跑得起来——同样的活，在 pi 这边不会因为「任务多了」就整体瘫痪。如今 opencode 基本退役，pi 接管一切。

维度对比

下面按维度列差异。能写出来的都是我真实踩过的，没经历过的参数对比不编。

一句话总结迁移结论：opencode 任务一多就卡住；pi 接管一切——因为我需要的不是更强的对话，而是能并行、能分工、能记住规矩的工具。

工程纪律方法论对比

工具选型之后是方法论选型。这半年我把三条主流路线都全流程用过，次数不多。

三者的定位

• grill-me：输入侧的追问技能。写需求之前先被连环追问，逼你把需求想清楚再动手。它是单技能，管的是「需求进规格之前」这一段。
• Superpowers：执行层方法论。核心是 TDD 驱动——把「怎么写代码」拆成可复用的步骤，按部就班执行。管的是「设计落成代码」这一段。
• OpenSpec：治理层/规格 artifact 工作流。每个变更以 design / spec / tasks 三件规格文件为契约，走评审，完成后归档进主规格。管的是「变更从提案到归档的整个生命周期」。

三者其实不在同一层：grill-me 管输入，Superpowers 管执行，OpenSpec 管治理。拿「盖房子」打比方——grill-me 是开工前被人反复问「你到底要什么」，Superpowers 是施工标准作业流程，OpenSpec 是图纸、验收单和备案档案。

我的使用感受

三条路线我都全流程用过，次数不多，共同感受是：比较繁琐。

• grill-me：每写一个需求都要被反复盘问，小需求也逃不掉，问到最后我自己的耐心先没了。
• Superpowers：仪式感强，简单改动也要拆成一大套步骤，改完感受不到收益在哪。
• OpenSpec：也繁琐，但繁琐的方向不同——它是「正式一些」，每条变更都有档案，事后能翻。

结论

最终我选了 OpenSpec 作为落地方案，理由就两个字：可追溯。我的项目需要正式一点的工作流——delta spec 记录每一次变更的增量，归档后同步进主规格，几个月后翻历史，一个变更为什么这么做、当时怎么定的，全有据可查。grill-me 的追问和 Superpowers 的 TDD 纪律没有完全扔掉，但它们的角色从「独立路线」降成了流水线里的局部环节（详见下文 op-* 流水线）。

结论：OpenSpec 最适用于自己的项目——因正式、因可追溯（delta spec / 归档）。

op-* 流水线

上面三章是选型，这一章是落地。我把 OpenSpec 的治理骨架和 pi 的技能机制拼成了五个 prompt，日常任何变更都走这条流水线：

需求（一句话/一个想法）
   |
   v
[op-explore]  -- 探索与澄清：只做分析和澄清，不产出规格、不改代码
   |
   v
[op-propose]  -- 把需求落成正式 delta 规格：design / spec / tasks
   |
   v
[op-apply]    -- 实现 + review-loop：先异步启动 worker 按规格实现，
   |             再并行派 fresh-context reviewer 评审（标 P0/P1/P2），
   |             有 P0/P1 就启动修复 worker 返工，默认最多 3 轮
   |
   v
[op-verify]   -- 对照 delta spec 做契约核验（与 review-loop 的代码质量
   |             门禁分开，这是规格契约检查）
   |
   v
[op-archive]  -- 收尾归档：把 delta spec 同步进主规格
   |
   v
完成

五步里只有 op-apply 会动代码，前两步是「想清楚 + 写契约」，后两步是「验契约 + 留档案」。下面逐个贴 prompt 原文（含 frontmatter，原样存档），每个下面一句话说明这步在干什么。

对照前文三种方法论：op-explore 吸收了 grill-me 的追问，op-apply 的 review-loop 承袭了 Superpowers 的评审纪律——它们没被扔掉，只是降成了这条流水线里的局部环节。

① op-explore

---
description: opsx 流程 ① 探索/分析（不产出规格）
argument-hint: "[需求]"
---
按 opsx-explore 流程，探索并分析以下需求：$@。只做分析和澄清，不产出正式规格、不改代码。

这步在干什么：把需求问明白——探索、澄清、分析，让需求从「一句话」变成「说得清的问题」，但刻意不产出规格、不动代码。

② op-propose

---
description: opsx 流程 ② 把探索落成正式规格（design/spec/tasks）
argument-hint: "[需求]"
---
按 opsx-propose 流程，把需求 $@ 生成完整的 delta 规格：design、spec、tasks 三个 artifact，为后续实现和评审提供契约依据。

这步在干什么：把问题落成契纸——产出 design / spec / tasks 三个 delta 规格 artifact，后续实现和评审都以这份契约为依据。

③ op-apply

---
description: opsx 流程 ③ 实现 + review-loop 评审（默认最多3轮）
---
按 opsx-review-loop-pipeline 的步骤 3 执行：在 opsx-apply 阶段，先异步启动 worker 按 delta spec 实现，再并行派 fresh-context reviewer 评审（标 P0/P1/P2 + merge verdict，默认最多 3 轮），父会话综合并启动修复 worker，直到无 P0/P1。父会话拍板，不设硬 toolBudget。

这步在干什么：让代码按契约长出来并被审——worker 按规格实现，fresh-context reviewer 以全新上下文评审挑毛病（标 P0/P1/P2），有 P0/P1 就返工修复，默认最多 3 轮，直到干净。

④ op-verify

---
description: opsx 流程 ④ 对照规格核验实现
---
按 opsx-verify 流程，对照 delta spec 核验实现是否匹配契约（这是规格契约检查，与 review-loop 的代码质量门禁分开）。给出是否通过。

这步在干什么：对账——实现完了，逐条对照 delta spec 核验「是不是真的按契约实现了」。这跟 review-loop 的质量评审是分开的两道闸。

⑤ op-archive

---
description: opsx 流程 ⑤ 收尾归档
---
按 opsx-archive 流程，收尾并归档已完成的 change，把 delta spec 同步到主规格。

这步在干什么：留档——变更收尾，把这次变更的 delta spec 同步进主规格，让「可追溯」闭环。

流水线里可能出现的 opsx-* 是我内部的技能名，读者不用懂每个技能的具体内容——记住五步是「想说清 → 写成契 → 按契做 → 验契约 → 留档案」就够了。五个 prompt 加起来不到三十行，这就是我的整套 SDD。

收尾：规范对象从人变成了 AI

2021 年我写过一篇《开发规范》。那时候的规范是给人看的：约定命名、代码风格，靠人读、人记、人去执行——规范写在文档里，执行在每个人的习惯里，最大的问题是「写了没人看」和「看了不执行」。

2026 年的今天，本文是给 AI 看的规范。同样的东西换了个载体：prompt 即规范（frontmatter 是元数据，正文是行为约定），delta spec 是变更契约，review-loop 是执行门禁，归档是记忆。AI 不会「不记得规矩」，因为规矩本身就是它每次运行前读入的文件。

五年，规范对象从人迁到了 AI。这是我这两年做 AI 编程最大的体会：与其写给人看、求人遵守，不如写成给 AI 执行的 artifact——可记录、可追溯、不会阳奉阴违。2021《开发规范》管的是人，2026 本文管的是 AI；中间的五年，是我从「求人守规矩」走到「把规矩写成代码」的五年。