2.2 Workflow 比 Prompt 更重要——稳定产出的关键在于流程设计

少林码僧
3 阅读13分钟

模块二：AI 协作方法论 | 第02讲：Workflow 比 Prompt 更重要——稳定产出的关键在于流程设计

项目：VibeNote 智能笔记 · 技术栈：Next.js / React / TypeScript / Tailwind
本讲核心论断：单条 Prompt 再漂亮，也只能赢一局；Workflow 才能让你天天赢。
一句话带走：先流程，后提示词；先边界，后代码。

一、开场：为什么「一句提示词」撑不起真实项目

很多同学习惯在群里求「有没有万能 Prompt」。我理解这种心态：大家都想走捷径。但如果你读过参考库里关于 Agentic Engineering 与 Coding Agents 的讨论，会反复看到同一个结论：真正让代理可用的是委托方式、检查点与反馈回路，而不是某句咒语。

再补一个来自「世界级智能体工程师」那条线的提醒：决定产出的往往不是敲代码速度，而是组织上下文、拆解任务和约束执行的能力（见核心概念文章列表的整理）。这句话听起来像鸡汤，拆开了其实很硬——组织上下文是第03讲，拆解任务与约束执行就是本讲的 Workflow。

结合 reference/practice/vibe-coding-methodology.md 里的实践经验，还有一条更「狠」的判断：作者明确说模型生成已经够快了，他要刻意让协作慢一点、稳定优先、小步慢跑。这不是反效率，而是认清了现实——复杂系统一次性无 bug 交付仍然不现实，上下文越长，模型越容易在依赖迷宫里迷路。

所以本讲要把话说透：Prompt 是单词，Workflow 是语法；没有语法，单词只能拼出句子，拼不出文章。 你的目标如果是 VibeNote 这种要持续迭代的产品，必须把「计划 → 审查 → 实现 → 验证」固化成肌肉记忆。

你也可以把 Workflow 理解成对 AI 「高方差输出」的控制系统：模型每一次生成都像一次抽样，流程要做的是缩小方差——不是扼杀创造力，而是让创造力落在正确边界里。

二、单 Prompt 模式的天然天花板

单 Prompt 适合三类事：小改动、孤立文件、规则极其明确。一旦任务跨越多文件、涉及数据模型与 UI 联动、或需要你在中途做架构取舍，单 Prompt 会出现典型症状：

  1. 实现跑偏：模型按自己的「默认架构」补全，你看到的是能跑，但不是你系统的跑法。
  2. 隐性债务：为了凑结果引入多余抽象、重复函数、未使用 import。
  3. 验证缺口：happy path 很亮，边界态一碰就碎。
  4. 上下文污染：同一对话里混着 A 需求与 B 需求，后续修改互相打架。
flowchart TD
  subgraph 单Prompt模式
    U[用户一句需求] --> AI[模型边想边写]
    AI --> C[代码堆积]
    C --> T[人工救火测试]
  end

flowchart TD
  subgraph 设计先行Workflow
    P[Plan 方案] --> R[Review 人审]
    R --> I[Implement 分步实现]
    I --> V[Verify 验证]
    V -->|失败| P
    V -->|通过| S[提交/合并]
  end

第二张图才是工业界在 AI 时代更「像样」的流水线：人仍然在关键节点做闸门。

三、「方案先行、实现为后」：从参考方法论到日常工单

参考实践文章里有一条我强烈建议你抄作业：每个功能实现前，先让大模型输出技术方案，由你 review 微调，再让它写代码。原因写得很技术——方案文本会成为后续生成的锚点，减少「边想边写」的逻辑断层。

把它翻译成可执行的 Workflow，就是四张「出口票据」：

  1. 方案票：模块边界、数据流、文件清单、风险与不做项。
  2. 审查票：你对方案的删改记录（哪怕三行批注）。
  3. 实现票：按文件分批合并，每批都有明确范围。
  4. 验证票：命令、页面路径、边界用例勾选。

没有这四张票，你只是在「聊天」；有了票，你才是在「做工程」。

四、Design-first：Plan → Review → Implement → Verify 详解

1. Plan（计划）

计划的最低合格线：能说清输入输出与失败语义。对 VibeNote 而言，「加一个 AI 扩写」不够；「选区文本 → 服务端流式 → 替换选区；空选区提示；错误可重试」才够。

2. Review（审查）

审查不是礼貌性点赞。你要重点砍三类东西：过度设计、隐式假设、越界改动。参考文章也提到模型会堆设计模式；审查阶段就该砍掉。

3. Implement（实现）

实现阶段请坚持小步：一次 diff 聚焦一个可验证目标。作者的做法是「DAO / Service / Controller 一口气生成」——那是因为边界已由方案锁死；你若方案没锁死，就别学「一口气」。

4. Verify（验证）

验证要分层：类型检查 / 构建 / 手工关键路径 / 必要时的自动化测试。参考方法论强调「每一步最后都能验证」，这不是鸡汤，是为了防止 bug 堆积后在长上下文里集中爆炸。

把四阶段串起来，你会得到一个很实用的判据：任何一次让 AI「继续」之前，都问「上一阶段的输出物是否已经落盘」。方案如果只停留在聊天窗口里，它就不算完成；验证如果只在你脑子里过一遍，它也不算完成。落盘可以是 PR 描述、issue 勾选、docs/ 里一段记录——形式不重要，可检索很重要。

五、任务拆解策略：我常用的四把刀

刀 1：按数据流切

用户动作 → API → 持久化 → 回到 UI。任何一步不清楚，就先不写代码。

刀 2：按风险切

高风险（权限、金额、删除）先做方案与小原型；低风险（纯展示）可以快。

刀 3：按可回滚切

每一小步都能 git revert，比「一天一个巨型 commit」安全得多。

刀 4：按「可演示」切

每个迭代结束都能给同事演示 30 秒，说明链路真的通了。

六、Workflow 模板 A：新功能（Feature）

阶段产出物人类闸门
需求澄清用户故事 + 非目标你确认「不做什么」
技术方案模块/接口/状态你审查边界
竖切实现最小可用链路你控制每批范围
验证清单 + 截图/录屏你签字
文档同步更新目录 README你抽查

参考方法论里的「分形文档结构」会在第03讲展开；这里先记住：功能落地后更新文档不是可选，是 Workflow 的一环。

七、Workflow 模板 B：Bug 修复

Bug 最怕「头痛医头」。参考文章描述过「无效调试循环」：模型在错误假设上打补丁。Workflow 要求是：你先定位根因，再把根因写进工单里让模型改（第05讲会专项强化）。

最短路径：

  1. 复现步骤（可拷贝）
  2. 期望 vs 实际
  3. 你已经排除的路径
  4. 你认为的根因一句话（若还没定位，就先写「未定位，需要一起排查」）

八、Workflow 模板 C：重构（Refactor）

重构 Workflow 的核心是「行为不变」四字。建议强制加入：

  • 基线测试（哪怕先手工脚本）
  • 机械重命名与搬文件分步
  • 每步 build 过

九、可运行示例：用 Node 脚本生成「分阶段工单」

把 Workflow 工程化的一种便宜做法：用脚本生成 issue 正文，强迫自己填字段。

// scripts/gen-workflow-ticket.mjs
// 运行: node scripts/gen-workflow-ticket.mjs

const ticket = {
  title: "[VibeNote] Markdown 分栏预览",
  type: "feature",
  nonGoals: ["不替换 textarea 为重型编辑器", "不做协同编辑"],
  planSections: [
    "数据模型是否变化？（是/否，说明）",
    "API 是否变化？（是/否，说明）",
    "UI 状态机（idle/loading/error）",
    "风险与回滚策略",
  ],
  verify: [
    "pnpm lint",
    "pnpm build",
    "手动：新建笔记 → 输入标题与正文 → 预览同步滚动检查",
  ],
};

function render(t) {
  const lines = [];
  lines.push(`# ${t.title}`);
  lines.push(`类型: ${t.type}`);
  lines.push("\n## 非目标（本期不做）\n");
  t.nonGoals.forEach((g) => lines.push(`- ${g}`));
  lines.push("\n## 方案提纲（先填再写代码）\n");
  t.planSections.forEach((s) => lines.push(`- [ ] ${s}`));
  lines.push("\n## 验证清单\n");
  t.verify.forEach((s) => lines.push(`- [ ] ${s}`));
  return lines.join("\n");
}

console.log(render(ticket));

这段脚本的价值不在代码本身，而在字段化：字段化之后，团队对话会从「感觉」变成「勾选」。

十、与「自上而下设计、自底向上实现」对齐

参考方法论里还有一条节奏：自上而下逐层细化，自底向上逐模块推进。翻译成 VibeNote：

  • 自上而下：先清楚「笔记 → 标签 → 搜索 → AI 辅助」的产品地图。
  • 自底向上：先做笔记持久化与编辑最小闭环，再叠 AI。
flowchart TB
  T[自上而下: 蓝图/模块/依赖] --> B[自底向上: 数据层]
  B --> M[中间层: API/Server Actions]
  M --> U[上层: UI/交互]
  U --> E[端到端集成]

十一、人机分工表：别用 AI 替代你该做的判断

直接借用参考文章里的思想（并改成 VibeNote 语境）：

环节你AI
架构取舍决策提供备选与评审
CRUD 与样板代码审查生成与同步字段
根因定位主导辅助推理与补丁
测试脚本设计边界生成脚手架

关键原则：AI 擅长体力活，你擅长判断与闭环。

十二、Workflow 反模式：这些「省时间」会在下周加倍讨回来

  1. 跳过方案直接写：短期爽，长期调试成本指数上升。
  2. 同一对话堆多个需求：上下文交叉污染。
  3. 不记录非目标：模型会「贴心」地多做，你还得删。
  4. 没有验证清单就合并：等于把 QA 外包给线上用户。
  5. 把审查变成形式：你只扫一眼「能跑」，债务会在第 N 次需求时反弹。

十三、把 Workflow 嵌进 Cursor：检查点怎么设

实践上我建议你给 AI 设三类检查点：

  1. 方案检查点：输出方案后必须停，等你回复「批准/修改点」。
  2. 范围检查点：每次改文件前输出「将修改以下路径：…」。
  3. 验证检查点：改完输出「我将运行哪些命令；若失败如何回滚」。

这不是迷信流程，是在用低成本机制对抗模型的「过度主动」。

十四、与课程原稿的关系：本讲替你们把骨架立起来

课程内容/2.2 Workflow比Prompt更重要：稳定产出的关键路径.md 原稿只有泛化流程与重复段落；本讲把它收敛成：可复制的分阶段工单 + 三类模板 + 反模式 + 可运行生成器。你可以把原稿当作「提醒你看 Workflow」，把本讲当作「直接能用的手册」。

十五、案例走读：VibeNote「AI 改写选区」如果不用 Workflow 会怎样

假设你直接在 Cursor 里说：「加个 AI 改写」。常见演化路径是：模型先找一个它熟悉的编辑器组件装上，再顺手改你的布局，再加一个客户端直连第三方 API 的示例——三件事都“合理”，但对你都是灾难：bundle 变大、密钥风险、设计体系被破坏。

如果换成 Workflow，第一阶段的方案票就会强迫你们对齐：继续用 textarea + 选区 API，服务端统一走 Route Handler，UI 只增加一个工具条入口。审查票里你会明确写：「禁止引入 ProseMirror/Lexical 除非单独开 RFC」。实现票按「API → 客户端 hook → UI」三步走，每步都有验证命令。你会发现：流程把“默认发挥”关进笼子里。

这个案例也说明 Workflow 的真正价值不是“慢”，而是把不确定性从上线后前移到方案评审；前移的代价是一次对话，后移的代价是一周救火。

十六、把 Workflow 写成团队的「版本化资产」

建议团队在仓库里固定三类文档（名字可自定）：

  1. docs/workflow/feature.md：新功能模板 + 案例链接
  2. docs/workflow/bugfix.md：根因工单模板 + 日志脱敏规范
  3. docs/workflow/refactor.md：行为不变声明 + 分步策略

它们的价值在于：新同事实习成本下降，并且 AI 也能读到——下一讲你会看到，这类文档属于“被动上下文”，越稳定越该长期挂载。

十七、节奏建议：个人开发者 vs 小团队

个人开发者最容易犯的错是「我心里有数就不用写方案」。请你至少写十行 bullet，这是给未来 48 小时后的自己看的——你很快会忘记当时为什么那样选。

小团队要把「审查」定义成可轮换角色：不必每次都同一个人，但必须有人签字。签字不代表全懂，而是代表「我确认范围与非目标」。

十八、与工具链文章的一条暗线对齐

reference/articles/03-toolchain-frameworks.md 强调：问题不在于装多少能力，而在于模型在正确时机拿到正确上下文、走正确流程。本讲其实是在落实「正确流程」这一半；下一讲落实「正确上下文」。当你把两边都做完，工具选型争论会少一半——因为你会发现：流程与上下文不对，换十个 IDE 也救不了。

十九、可运行示例 2：把「检查点」做成 TypeScript 常量

下面这段适合放进 lib/ai/workflow.ts 或独立脚本，用来提醒你在 Prompt 里插入检查点（与具体 AI SDK 无关）。

// lib/workflow/checkpoints.ts
export const WORKFLOW_CHECKPOINTS = {
  afterPlan: [
    "请停止生成代码，直到我回复「批准方案」。",
    "若方案需要新增依赖，请列出理由与替代方案。",
  ],
  beforeEdit: [
    "列出将修改的文件路径与每个文件的目的（各一行）。",
    "声明本期不修改的目录（例如 prisma/、migrations/）。",
  ],
  afterImplement: [
    "给出我将运行的验证命令（按顺序）。",
    "列出 3 个边界用例并说明期望行为。",
  ],
} as const;

export function renderChecklist(phase: keyof typeof WORKFLOW_CHECKPOINTS): string {
  return WORKFLOW_CHECKPOINTS[phase].map((s) => `- ${s}`).join("\n");
}

// Demo
console.log(renderChecklist("afterPlan"));

二十、Workflow 与「规范是新的源代码」

在核心概念文章列表里有一篇标题很抓人：规范是新的源代码。把它翻译进本讲就是：当你的 Workflow 要求「先方案后代码」，你其实在强迫团队把可执行规范写出来。规范写得越清楚，AI 生成越省提示词；反过来，提示词堆得很长但规范缺失，仍会持续返工。

二十一、对比表：Workflow 成熟度 Level 0～3（自检用）

Level表现建议动作
0想到哪做到哪先只加「方案停」检查点
1有方案但无验证清单补 Verify 三段式（lint/build/手工）
2有模板但执行随缘把模板接进 PR 描述或 issue
3模板+审查+度量化复盘每次返工归因到缺失环节

二十二、时间盒：Workflow 会不会把迭代拖慢？

这是团队引入流程时最常见的质疑。我的回答是：Workflow 的目标不是增加会议，而是减少无效尝试。你可以给每个阶段设时间盒：方案 30～60 分钟必须出第一版；审查 15 分钟必须给「批准/三点修改」；实现按竖切每段不超过半天。

真正拖慢团队的，往往不是写方案那 30 分钟，而是三天后在生产环境发现架构选错。时间盒强迫你们用便宜的方式提前支付成本。

二十三、PR 与对话的映射：让 Git 记录你的 Workflow

一个很实用的习惯：把「方案摘要 + 非目标 + 验证勾选」复制进 PR 描述。这样未来你用 AI 做回归时，可以直接 @ 那次 PR 作为上下文锚点。Workflow 不只是过程，它还会变成可检索的历史，这在长线项目里极其值钱。

二十四、VibeNote 专属：从「想法」到「迭代」的一条推荐路径

第 0 天：只验证「笔记创建 → 列表展示 → 再次编辑」闭环。
第 1 周：补标签与搜索任一（不要同时）。
第 2 周：补 Markdown 预览（第13讲实战会落地）。
第 3 周：再补 AI 辅助写作（摘要/扩写/改写分层上线）。

这条路径与参考方法论里的「自底向上」一致：先把地基打实，再让 AI 在明确边界里加速。

二十五、再补一张图：把「反馈」画进流水线

sequenceDiagram
  participant You as 你
  participant AI as AI
  participant CI as 验证(CI/本地)
  You->>AI: Plan 工单(含非目标)
  AI-->>You: 方案输出
  You->>AI: Review 批注
  AI-->>You: 修订方案
  You->>AI: Implement 授权(范围清单)
  AI-->>You: 代码变更
  You->>CI: lint/build/test
  CI-->>You: 通过/失败
  alt 失败
    You->>AI: 结构化回传失败信息
  else 通过
    You->>You: 合并与发布
  end

二十六、每日站会式自检：三个问题（solo 也适用）

  1. 我今天要交付的最小闭环是什么？（必须能演示）
  2. 我是否在未批准方案前就让模型改了三个以上文件？（若是，立刻停）
  3. 我今天是否更新了文档/注释，让明天的上下文不断层？（参考分形文档，见第03讲）

二十七、从「个人 Workflow」到「团队 Workflow」：三条最低规范

  1. 统一工单字段：至少包含「背景 / 非目标 / 验收 / 风险」。
  2. 统一验证命令：例如固定 pnpm lint && pnpm build，不要每人一套。
  3. 统一合并门槛：至少一条手工关键路径 + CI 通过（哪怕 CI 很轻）。

这三条不性感，但能把 AI 生成的高方差压下去。

二十八、失败复盘模板（建议你复制到 docs/incidents/template.md）

  • 现象：用户看到什么？系统日志关键行是什么？
  • 影响面：多少用户、多少数据、是否可回滚？
  • 时间线：何时引入、何时发现、何时修复？
  • 根因：一句话 + 证据链接（commit/PR）。
  • 为什么流程没拦住：缺了哪张「票」？
  • 下次预防：Workflow 调整点（新增检查点/新增自动化）。

你会发现：真正让团队变强的不是「这次修好了」，而是「下次更早拦住」。

二十九、Workflow FAQ：八个高频质疑与我的回答

Q1：我单人项目也要这么重吗？
A：把「重」理解成「字段化」。你可以只有你自己，但仍需要票据，否则三天后你会不认识自己的代码。

Q2：方案会不会写不完？
A：方案不需要完美，它需要可否决。先写十行，再迭代。

Q3：AI 写方案会不会胡编？
A：会。所以方案阶段的价值是让你更早看到胡编，而不是让它代替你判断。

Q4：每次都审查会不会变成瓶颈？
A：审查应当分级：小改快审，大改严审。Workflow 不是官僚化，是风险管理。

Q5：我已经有 Code Review，还需要这个吗？
A：需要。Code Review 往往发生在事后；Workflow 把关键闸门前移到方案与范围。

Q6：敏捷是不是讨厌文档？
A：敏捷讨厌无价值的文档，不讨厌能降低返工的文档。十行方案通常比一页会议纪要便宜。

Q7：我能不能让 AI 自动走完整流程？
A：可以辅助，但批准权建议仍在人。否则你会得到「自动生产的债务」。

Q8：Workflow 和测试哪个先？
A：并行。方案里就要写「如何验证」；没有验证意识的方案，直接打回。

三十、把 Workflow 写进 Cursor：一句能救仓库的规则

你可以在项目规则里加一句很朴素的话：「任何超过单文件的小改动必须先输出方案并等待我确认」。这句话比一百条技巧都狠，因为它系统性阻止了「边聊边改把整个仓库卷进去」。当然，你也要真的做到快速评审，否则流程会被人为绕开——流程永远对抗的是人性，不是工具。

三十一、本讲小结

  • 单 Prompt 赢一局，Workflow 赢一局又一局。
  • 「方案先行、实现为后」是稳定性的杠杆点。
  • Plan / Review / Implement / Verify 是最小闭环。
  • 新功能、修 bug、重构三类任务要用不同模板，但共享同一纪律：先边界、后动手、每步可验证。
  • 人机分工要明确：定位与架构在你，生成与样板在 AI。

最后一句话送给正在做 VibeNote 的你：别用更快的生成骗自己「流程可以省略」。生成越快，越需要流程；否则你会以更高速度制造返工。把 Workflow 当作刹车片，不是累赘。

三十二、思考题

  1. 你当前最常用的协作模式更接近「单 Prompt」还是「四阶段」？如果只做一项改造，你会先改哪一项？
  2. 你会把「方案必须经我批准」写进团队规范吗？阻力可能来自哪里，你如何说服？
  3. 回顾一次痛苦的调试：如果当时强制插入「根因一句话」检查点，能提前在哪个时刻止损？

附加题：把本周一个真实需求按本讲的「四张票」重写一遍，看看你会在 Plan 阶段删掉多少「顺手做」的冲动。

三十三、下讲预告

下一讲进入上下文工程：窗口、成本、主动与被动上下文、分形文档、以及 Cursor 的 @file / @folder / @codebase 策略。你会理解：Workflow 解决「顺序」，上下文解决「给什么」——两者乘起来才是稳定交付。提前做个小作业：打开你最近一个长对话，标出其中 20% 真正影响决策的句子——你会直观看到「噪声上下文」有多贵。

参考阅读：reference/practice/vibe-coding-methodology.md（方案先行、小步验证、无效调试预警）；reference/articles/01-core-concepts.md（Agentic Engineering / Coding Agents 工作方式）；课程内容/2.2 Workflow比Prompt更重要：稳定产出的关键路径.md。坚持一周，你会回来感谢流程。

avatar
文章
阅读
粉丝