把 AI 放进工作流

发表于 更新于 分类于 本文字数： 3.7k 阅读时长 ≈ 14 分钟

前面两篇文章分别谈了程序员的职责和 GPT 的能力边界：代码、工具与人：AI 时代的程序员，以及 GPT 有智能，但不是责任主体。

这一篇继续往下走，谈一个更具体的问题：日常工作里，我到底应该怎样使用 AI？

我现在越来越觉得，AI 不是靠一次提示词用好的。

提示词当然重要。但真正决定效果的，往往不是某一句话写得多漂亮，而是 AI 被放进了什么样的工作方式里：什么时候先澄清，什么时候先读上下文，什么时候可以动手，什么时候必须验证，什么时候应该把结论写回文档。OpenAI 在谈 Codex 的 agent-first 实践时，把工程师的角色描述为设计环境、指定意图和建立反馈循环；Anthropic 在讨论 agentic systems 时，也区分了预定义路径的 workflow 和由模型动态决定步骤的 agent。[1][2]

也就是说，问题不是“怎么让 AI 回答得更像一个聪明人”，而是“怎么让 AI 参与一个可靠的工作流”。

不要只和 AI 聊天

很多时候，我们会反复对 AI 说同样的东西：先理解上下文，不要急着改；修 bug 前先复现；写完以后要验证；不要随便宣布完成；重要结论要沉淀到文档里。

如果每次都靠临时提醒，这件事很容易失效。因为对话会变长，上下文会变脏，人的注意力也会松。AI 可能这次听进去了，下次又回到它更熟悉的生成模式里：先给一个看起来合理的答案。

所以我把这些重复要求整理成了 skill：https://cnb.cool/ryuu64/skills。

skill 对我来说，不是“更长的提示词”，而是一种协作协议。它把那些反复出现的工程判断写成可复用流程，让 AI 知道在什么场景下该采用什么工作方式。这个判断也和 Codex、Claude Code 的官方建议相近：稳定的项目偏好应该进入 AGENTS.md、skill 或项目文档，而不是每次都靠临时 prompt 重复。[3][4]

先决定当前阶段

AI 很擅长生成内容，但它不一定天然知道什么时候该停下来理解上下文，什么时候该先验证假设，什么时候该把结论写回文档。

所以我更倾向于先判断当前需求处在哪个阶段。对复杂、模糊或多步骤任务，先 plan 再动手，比直接进入实现更稳；对简单任务，则没有必要把流程做重。[5]

当我还没有想清楚方案时，grill-then-docs 对我很重要。它先用 grill 的方式把一个决策点问透：有哪些选项，各自的代价是什么，推荐哪一个，为什么。等结论稳定以后，再把这些结论写回项目文档。这样 AI 不只是陪我聊了一轮方案，而是把这轮讨论变成项目之后还能复用的上下文。

比如看不懂一段代码时，我不希望 AI 直接解释当前文件，而是先使用 zoom-out 拉高一层，弄清楚它在系统里的位置：上游是谁、下游是谁、核心概念是什么、下一步应该读哪里。Claude Code 的常见工作流里也建议先从 broad questions 开始，再逐步深入具体组件和执行路径。[6] 这样后面的修改才不会只盯着局部。

修 bug 时，我会更希望它进入 diagnose 的流程：先建立反馈循环，再复现问题，然后提出可证伪的假设，用日志、测试或调试器去验证。很多 bug 真正难的地方不在改动本身，而在确认自己没有修错方向。Anthropic 的 coding agent 讨论也指出，代码任务之所以适合 agent，很大一部分原因在于代码可以通过自动化测试验证，agent 可以用测试结果迭代。[7]

如果是在实现一个明确的新行为，我会倾向于用 tdd。先列业务规则、边界条件和验收范围，再写失败测试，再写最小实现。AI 可以很快生成代码，但测试会把它拉回到具体行为上，不让它只写出一段“看起来像那么回事”的实现。

任务做完以后，我还会要求 verification-before-completion。AI 不能只说“已经完成”，而要先运行对应的验证命令，读输出，再根据结果判断能不能做完成断言。这个 skill 对我很重要，因为 AI 很容易在语气上显得很确定，但工程上真正需要的是证据。Codex 的最佳实践也把测试、lint、type check、行为确认和 diff review 放在可靠性收口里。[8]

如果过程中形成了稳定结论，比如某个模块的约束、某种排障方法、某个架构决策，我会再用 project-docs-sync 或 project-docs-writing 把它同步回项目文档。否则这次对话结束以后，经验又散掉了，下次还要重新解释。OpenAI 在 Harness Engineering 里把 repository knowledge 作为 system of record，并把短入口文件、结构化文档和渐进式披露放在一起使用；这其实是在解决同一个问题：让 AI 能从项目内部重新找到稳定上下文。[9]



flowchart TD
    A[遇到需求] --> B{当前最需要澄清什么}
    B -->|方案还不清楚| K[grill-then-docs<br/>先问透决策，再写回文档]
    B -->|不熟悉代码| C[zoom-out<br/>先建立上下文地图]
    B -->|排查 bug| D[diagnose<br/>复现、假设、验证、收敛根因]
    B -->|实现新行为| E[tdd<br/>测试先行，按行为推进]
    K --> F
    C --> F[修改或继续分析]
    D --> F
    E --> F
    F --> G[verification-before-completion<br/>用新鲜证据确认结果]
    G --> H{形成稳定结论?}
    H -->|是| I[project-docs-sync / project-docs-writing<br/>写回项目文档]
    H -->|否| J[结束任务]
    I --> J

这些流程看起来琐碎，但它们决定了 AI 是在帮你推进工程，还是只是在生成一堆看起来合理的文本。

处理 AI 的失控

把 AI 放进工作流，并不是因为 AI 不会做事。恰恰相反，是因为它太容易流畅地做事，甚至在方向不对的时候也显得很有把握。

上下文污染

我使用 AI 的过程中遇到过不少问题。最常见的一类，是上下文变得太长、太杂以后，AI 开始不理解业务。它会抓住对话里某个局部信息，然后沿着一个不对的方向继续推理，甚至越解释越偏。

这种时候，继续在原来的对话里纠正，不一定是最好的办法。因为问题有时不在某一句提示词，而在整个上下文已经被污染了。OpenAI 对“大 AGENTS.md”的反思很有代表性：上下文是稀缺资源，太多指导反而会挤掉任务、代码和真正相关的文档。[10] 我会选择新开一个对话，或者先清理上下文，再把真正重要的背景、约束和当前目标重新说清楚。如果项目里已经有文档，就让 AI 先看文档，而不是继续依赖一段越来越长的聊天记录。

调试时跳过证据

另一类问题出现在 debug 时。AI 很容易想直接根据代码猜原因，然后给出一个修复方案。这个过程看起来很快，但风险很高，因为它可能只是在修一个“看起来像问题”的地方。我遇到过 AI 死活不肯先插桩、不肯根据日志复现，而是反复尝试直接改代码。

后来我用 diagnose 去约束这个过程，并且反复调整它的规则：先建立反馈循环，先复现，再提出假设；需要日志就插有明确目的的日志；每次观察结果以后更新假设，而不是直接跳到修复。这样做会慢一点，但它能把 AI 从“猜一个答案”拉回到“拿证据收敛问题”。这也是人在环（Human-in-the-Loop）真正有价值的地方：人不只是最后点确认，而是在高不确定、高风险或缺证据的位置把流程停住。[11]

混淆计划和事实

还有一类更隐蔽的问题：AI 看起来像是知道自己在干什么，但实际上它可能只是选择了一个“看起来合理”的位置。

比如我的 grill-then-docs，它的目标是先把方案问清楚，再把稳定结论沉淀下来。可在一开始，AI 经常会把 grill 之后“接下来要做什么”写进 ./docs/features 或 ./docs/architecture。从表面看，这很合理：方案讨论和功能、架构都有关。但实际上这是错误的，因为 grill 后续要做的事情只是计划，不是已经成立的功能事实，也不是架构事实。

它应该先进入 ./docs/plan，等实现完成、结论稳定以后，才有资格进入 features 或 architecture。

这个错误很有代表性。AI 能根据文字相似性把内容放到看起来相关的地方，但“语义相关”不等于“事实身份正确”。一个计划即使和架构有关，也仍然只是计划；一个候选方案即使描述得很完整，也还不是系统事实。Microsoft 的 Human-AI Interaction Guidelines 也提醒我们，AI 系统需要让用户能理解、纠正和恢复，而不是把一个看似合理的输出直接当作事实。[12]

这背后更完整的能力边界，我在 GPT 有智能，但不是责任主体 里单独写过。放到工作流里看，解决办法不是指望 AI 自己突然理解项目知识治理，而是把规则明确写进去：grill 之后形成的后续计划，应该写到 /docs/plan，不能直接写进 /docs/features 或 /docs/architecture。

这不是一个简单的目录偏好，而是在告诉 AI：什么东西还只是计划，什么东西才可以被当作项目事实。

把偏好变成约束

使用 AI 写代码时，很多问题不是 AI 不会，而是它不知道你在意什么。

你在意命名是否贴合领域，注释是否解释意图而不是复述代码，提交信息是否清楚，文档是否跟着代码一起更新，这些偏好如果每次都临时说明，就很容易遗漏。

skill 的价值在于把这些偏好变成稳定约束。它不是让 AI 替我做判断，而是让 AI 在我设定的边界里工作。更准确地说，skill 管的是“在某类任务里如何行动”，而不是“把人的责任外包出去”。

这也是为什么我不太愿意把这件事叫作“写提示词”。提示词更像一次性的表达，工作流则会问另一组问题：

  • 这个需求现在处在哪个阶段？
  • AI 应该先读什么上下文？
  • 什么情况下可以动手？
  • 什么结果可以算完成？
  • 需要什么证据才能宣布完成？
  • 哪些结论应该写回文档？

这些问题比一句漂亮提示词更重要。

让 AI 更像协作者

skill 是一种协作协议。它让 AI 知道在什么场景下该采用什么工作方式，也让我不用每次都从零开始解释自己的工程习惯。

这也对应了前面两篇文章的结论：AI 可以加速表达、生成和试探，但程序员仍然要负责判断、边界和验证。把 AI 放进工作流，就是把这些责任拆成更清晰的流程，让 AI 更稳定地参与其中。

好的 AI 使用方式，不是把人从流程里拿掉，而是让人更清楚地站在该负责的位置上。

参考与延伸阅读

  • OpenAI, Harness engineering：适合理解为什么 AI coding 的关键不只是提示词，而是环境、工具、反馈和知识系统。
  • OpenAI Developers, Codex best practices：适合理解 AGENTS.md、plan-first、测试验证和 review 如何进入日常工作流。
  • Anthropic, Building Effective AI Agents：适合理解 workflow、agent、自主性、测试反馈和 guardrails 的边界。
  • Anthropic Docs, Claude Code common workflows：适合把“看代码、修 bug、写测试、写文档”拆成可执行工作流。
  • Anthropic Docs, Extend Claude with skills：适合理解 skill 为什么应该聚焦入口和按需加载，而不是变成大而全说明书。
  • Microsoft Research, Guidelines for Human-AI Interaction：适合理解人在 AI 系统中的控制、纠错和恢复位置。

  1. OpenAI, Harness engineering: leveraging Codex in an agent-first world。这里引用它来支撑“AI 使用效果取决于环境、意图、工具和反馈循环，而不只是 prompt”的判断。 ↩︎

  2. Anthropic, Building Effective AI Agents。Anthropic 区分 workflow 与 agent，并提醒只在复杂度确实需要时提升自主性。 ↩︎

  3. OpenAI Developers, Codex best practices。这里引用的是“把重复指导沉淀到 AGENTS.md、skill、配置和自动化工作流”的实践建议。 ↩︎

  4. Anthropic Docs, Extend Claude with skills。Claude Code 的 skill 文档强调 SKILL.md 保持聚焦，细节放入按需加载的 supporting files。 ↩︎

  5. OpenAI Developers, Codex best practices: Plan first for difficult tasks。这里引用它来支撑复杂任务先规划、再执行的工作流。 ↩︎

  6. Anthropic Docs, Claude Code common workflows。其中“理解代码库”和“查找相关代码”的建议都强调从广到窄地建立上下文。 ↩︎

  7. Anthropic, Building Effective AI Agents。这里引用的是 coding agents 适合用测试反馈迭代的判断。 ↩︎

  8. OpenAI Developers, Codex best practices: Improve reliability with testing and review。这里引用它来支撑“完成断言必须绑定测试、检查、行为确认和 review”。 ↩︎

  9. OpenAI, Harness engineering。这里引用的是“repository knowledge as the system of record”和渐进式披露的实践。 ↩︎

  10. OpenAI, Harness engineering。这里引用的是“大型指令文件会挤占任务、代码和相关文档”的上下文管理经验。 ↩︎

  11. 参见 Microsoft Research, Guidelines for Human-AI Interaction；以及 NIST, AI Risk Management Framework。这里引用它们来支撑“人工介入点需要上下文、控制、恢复和责任边界”的说法。 ↩︎

  12. Microsoft Research, Guidelines for Human-AI Interaction。这份 CHI 2019 论文提出并验证了 18 条 Human-AI Interaction 设计指南，适合支撑“AI 输出需要可理解、可纠正、可恢复”的边界。 ↩︎