很多人卡住，卡在协作方式

很多人第一次真正把 AI 用进工作流时，都会经历一个很像的阶段：前面几次特别惊艳，后面开始越来越痛苦。它一次能给很多东西，速度也快，但你慢慢发现自己像是在接一团已经展开的线球，越往后越难收。

Jeremy 这篇最有价值的地方，就是把这个问题说得非常直接。很多时候，麻烦不在 AI 不够强，而在于我们太容易用一种对自己不利的方式跟它协作。

小步协作，听起来保守，其实更快

最常见的误区是把一个完整问题整包扔给 AI，然后期待它整包还回来。看起来很爽，长期却经常更慢。

更稳的做法往往是把问题拆成一串小步。先定义一个最小问题，让 AI 只做其中一小步，人来检查，再进入下一步。这个过程听上去没有那么像“自动化革命”，但它更接近真正能持续工作的节奏。

原因很简单。每一小步都能看懂、能验证、能停下来。你没把判断力一起交出去。

这也是为什么很多人用 AI 写周报、写脚本、写分析时，最舒服的方式往往是“先起个框架，我们一段一段往前推”，而不是“帮我全部写完”。

拿一个最常见的小活来说就很明显。比如你要把一份脏兮兮的 CSV 清洗后导进后台。如果你一口气说“帮我全处理完”，它也许会给你一份很长的脚本；但如果你先让它只做字段识别、再做异常值处理、再补导入校验、最后写一个回滚脚本，你每一步都更敢看，也更敢用。

开发者最容易产生共鸣的地方

如果你已经开始被 AI 提速，但又隐约担心自己是不是越来越不理解代码，这篇会很有代入感。

因为它实际上是在帮你保住一种很重要的东西：对问题的控制权。关键不在于你要写得比模型快，而在于你始终知道现在在解决哪个具体问题，下一步为什么是这一小步。

这会让你发现，真正值得练的，是“把复杂问题切成 AI 和人都接得住的小段”。

这套方法对产品和测试也一样成立

产品也可以用这套方法。与其一上来让 AI 出完整方案，不如先让它拆任务、列风险、问澄清问题，再逐步补细节。测试也一样，不必一开始就让它写完整测试计划，先让它补场景，再筛选，再人工重写，往往反而更有用。

它真正改变的，是 AI 进入你思考过程的方式。

对 Agent Engineer 来说，它其实在讲节奏

这篇对 Agent Engineer 最有启发的地方，是它几乎像一堂交互节奏设计课。好系统不只是会回答，还要知道什么时候继续，什么时候停，什么时候请求确认，什么时候把判断交还给人。

换句话说，设计的单位不该只是一次输出，而该是下一步行动。

很多 Agent 产品之所以让人用两天就累，就是因为它们特别擅长一下子给很多，却不太擅长和人一起把下一步收窄。真正顺手的系统，常常会在关键节点主动停下来问一句：“你要我继续改，还是先给你看 diff？”这种节奏感，比多会几个花哨能力更重要。

今天就能立刻试的版本

今天随便选一个小任务，强迫自己用四轮最小协作完成：描述、生成、检查、修正。你可以试试补一个单测、改一段埋点、整理一次会议纪要。做完后再看一眼，这种节奏虽然不花哨，但通常比“一把梭哈”更稳，也更容易复用。

更新附注

  • 版本：v1.1
  • 更新日期：2026-03-20
  • 更新原因：为系列文章补充统一阅读序号，帮助读者在趋势篇后顺畅进入协作方法篇。