夜雨聆风前言
思考 / 警示：工作流没跑完全程，代码却改对了——那 OpenSpec、Superpowers 还有用吗？
核心问题：一次真实项目开发问题实录, 我描述需求，然后使用工作流来编码, 追求的是无人值守，编码一步到位。
工作流：从需求稿md文档 -> 工作流自动 AI 编码并验证 AI 产物 -> 完成需求开发
一、你以为的 vs 真实的
你以为的过程
你：描述需求 + @工作流 → Agent 严格执行阶段 0→5 → OpenSpec 契约、4a 验证、4b 验收 → 交付报告 ✅ → 你才能放心合并真实发生过的过程（auto-sign 案例）
你：描述需求 + 「请使用 ai-workflow」 → Agent 读了 CHANGELOG 和 sign-auto.vue → 直接改 standard-file.vue、utils/index.js → 没写需求对齐、没写openspec文档，没跑 4a/4b、没出 delivery-report... → 你一看：逻辑好像对，能联调(直接写的产物)所以第一个要纠正的认知是：
大模型 + 内置工具，在「熟悉领域 + 有参考实现 + 单点需求」时，确实经常能跳过你自建工作流，交出一份「看起来够用」的初稿。
这不是幻觉，是我昨天亲眼验证过的事实。
压根就跳过工作流，没有走工作流设定的一系列流程步骤，原因是我工作流中没有硬性要求。
我当时就方了。因为写的代码没问题确实符合需求要求。
二、那工作流、OpenSpec、Superpowers 是不是已经失效了？
短答
没有失效，但它们的战场变了。
它们早年的卖点容易被理解成：
「让 AI 写得更聪明。」
而 2026 年的现实是：
聪明这件事，模型和 Agent 默认已经做得不错；工作流真正买的是别的东西。
长答：三类任务，三种打法
| 划算 | ||
| 常常够用 | ||
| 不够 | 必须 |
auto-sign 这次人脸刷脸改造，落在第二档和第三档之间：
•第二档：所以「没走工作流也改对了」说得通；
•第三档：submitFileSurvey 三参是否后端支持、真机 E2E、日失败上限——工作流本该帮你把这些标成 Open Question 和 deferred AC，而不是藏在「感觉对了」里。
OpenSpec / Superpowers / 自建工作流，卖的不是「更会写代码」，而是：
1.可追责 — 谁批准了什么需求、验收标准是什么
2.可重复 — 下一个人、下一轮迭代不用重新猜
3.可降级 — 知道哪些是 blocking、哪些可以联调后补
4.可组织 — 把 Agent 的软约束变成团队契约
模型再强，也替不了你签字。
三、人的作用只剩「写提示词」吗？
你以为人的角色
把需求描述清楚，剩下的交给 AI。
更真实的人机分工（2026）
提示词只是入口。你真正不可替代的部分，集中在下面五类决断：
1. 划边界：什么必须人审，什么可以 Agent 自洽
•isSkipSign 只含 type 1/2，还是包含 3？——产品决断
•要不要 guardSubmit（72 小时失效重刷）？——风险决断
•真机 E2E 没过，能不能标「条件通过」合并？——发布决断
工作流里的 停顿点 C、4b blocking AC，就是把这类决断从「Agent 猜」改成「人确认或显式 deferred」。
2. 定真源：以谁为准
对话？PRD？OpenSpec？后端 YApi？
你后来要求文档不要堆在 output/，而要进 openspec/changes/<id>/——这就是元决断：团队以后信哪份文件，不信哪份。
没有这一步，每个人用的都是「昨天那次对话里的 AI 记忆」。
3. 验收契约：什么叫「对」
「看起来对」≠「可交付」。
•静态代码对照 AC：可以 Agent 做
•真机刷脸回跳、后端收三参：要你或 QA 拿证据
人的作用是定义 AC，并在证据不足时说：可以进分支，不能标全绿。
4. 组织记忆：别让同一个坑付两次学费
工作流 IMP-036（全流程硬闸）、IMP-038（OpenSpec 路径规范），价值不在于让这一次写得更快，而在于：
下一次换一个人、换一个 Agent，也不会再跳过 4a/4b。
这是知识管理，不是提示词技巧。
5. 品味与取舍：做减法
工作流、OpenSpec、Superpowers 叠太多，Agent 也会偷懒——我昨天已经看见了。
人的另一项职责是：知道什么时候不必全开工作流。
When NOT to Use 不是废话，是资深工程师的克制。
四、一个警示：「初稿可用」陷阱
这是全文最想留给你的警示。
舒适区： 需求 → 直接改代码 → 结论还行 → 「工作流可有可无」盲区： - 没有 AC 矩阵 → 联调失败时不知道漏了哪条 - 没有 Open Questions → 后端字段名错了要重新猜 - 没有 delivery-report → 三个月后没人记得为什么删了验证码弹窗 - 没有 E2E 证据 → 上线后人脸在部分机型失败，责任说不清大模型越强，这个陷阱越深。
因为「初稿更像成品」，你会更早放下戒心。
工作流不是为了让第一次写得慢，是为了让你别在不知不觉中把技术债当成完成度。
五、工作流还要迭代吗？要，但别往「更重」方向迭代
不必做的迭代
•再叠 10 个 Skill，指望 Agent 更听话——边际递减
•每个改一行文案都跑 0→5——仪式化
•把 Superpowers + OpenSpec + 自建工作流全绑死——Agent 会选择性失明（已体验）
值得做的迭代（你们已经在做）
| 硬闸 | ||
| 路径规范 | openspec/changes/<id>/workflow/ | |
| 补跑模式 | ||
| 有尺寸 |
工作流迭代的终点不是「Agent 100% 遵守」，而是「团队知道什么时候必须遵守」。
六、给不同读者的行动建议
如果你是个人开发者、原型验证
•可以直接描述需求让 AI 改代码
•至少自己列 3 条验收标准（哪怕不写 OpenSpec）
•合并前问一句：如果换一台电脑、换一个 Agent，我还能证明它是对的吗？
如果你在团队 / 生产 / 合规场景（人脸、支付、签约）
•声明走工作流时，必须落盘 change + workflow + 4b
•允许 retroactive，不允许没有 AC 矩阵就标全绿
•文档真源写进 openspec/project.md，别靠口头约定
如果你在维护 ai-workflow 这类工具
•继续强化 enforcement + 补跑 + 路径规范
•少加阶段，多加 「何时不必跑全流程」的决策树
•用真实项目（auto-sign）做 regression，而不是只改 SKILL 正文
七、结论（可单独转发）
1.大模型变强，并没有让方法论失效；它让「方法论存在的理由」从「帮 AI 写对」转向「帮组织负责、可审计、可迭代」。
2.你昨天的体验完全真实：很多时候不用工作流，初稿也够好——但这只覆盖探索态，不自动覆盖交付态。
3.人的价值远不止是写提示词；你是边界制定者、验收裁判、真源维护者和减负决策者。
4.工作流仍要迭代，但方向是更准、更硬、更轻——不是更厚。
5.最大警示：别把「Agent 第一次没翻车」当成「流程可有可无」。越强的大模型，越需要你在关键节点留下可追责的脚印。
附录：auto-sign 案例时间线（事实锚点）
openspec/changes/standard-contract-face-auth/ |
