AI 编程的真相:AI 跳过工作流把代码写对了,那我建的流程是不是白费了?还剩什么价值?

前言

思考 / 警示：工作流没跑完全程，代码却改对了——那 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 会选择性失明（已体验）

值得做的迭代（你们已经在做）

工作流迭代的终点不是「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 案例时间线（事实锚点）