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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今天就能立刻试的版本

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

更新附注

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