很多人卡住,卡在协作方式
很多人第一次真正把 AI 用进工作流时,都会经历一个很像的阶段:前面几次特别惊艳,后面开始越来越痛苦。它一次能给很多东西,速度也快,但你慢慢发现自己像是在接一团已经展开的线球,越往后越难收。
Jeremy 这篇最有价值的地方,就是把这个问题说得非常直接。很多时候,麻烦不在 AI 不够强,而在于我们太容易用一种对自己不利的方式跟它协作。
小步协作,听起来保守,其实更快
最常见的误区是把一个完整问题整包扔给 AI,然后期待它整包还回来。看起来很爽,长期却经常更慢。
更稳的做法往往是把问题拆成一串小步。先定义一个最小问题,让 AI 只做其中一小步,人来检查,再进入下一步。这个过程听上去没有那么像“自动化革命”,但它更接近真正能持续工作的节奏。
原因很简单。每一小步都能看懂、能验证、能停下来。你没把判断力一起交出去。
这也是为什么很多人用 AI 写周报、写脚本、写分析时,最舒服的方式往往是“先起个框架,我们一段一段往前推”,而不是“帮我全部写完”。
拿一个最常见的小活来说就很明显。比如你要把一份脏兮兮的 CSV 清洗后导进后台。如果你一口气说“帮我全处理完”,它也许会给你一份很长的脚本;但如果你先让它只做字段识别、再做异常值处理、再补导入校验、最后写一个回滚脚本,你每一步都更敢看,也更敢用。
开发者最容易产生共鸣的地方
如果你已经开始被 AI 提速,但又隐约担心自己是不是越来越不理解代码,这篇会很有代入感。
因为它实际上是在帮你保住一种很重要的东西:对问题的控制权。关键不在于你要写得比模型快,而在于你始终知道现在在解决哪个具体问题,下一步为什么是这一小步。
这会让你发现,真正值得练的,是“把复杂问题切成 AI 和人都接得住的小段”。
这套方法对产品和测试也一样成立
产品也可以用这套方法。与其一上来让 AI 出完整方案,不如先让它拆任务、列风险、问澄清问题,再逐步补细节。测试也一样,不必一开始就让它写完整测试计划,先让它补场景,再筛选,再人工重写,往往反而更有用。
它真正改变的,是 AI 进入你思考过程的方式。
对 Agent Engineer 来说,它其实在讲节奏
这篇对 Agent Engineer 最有启发的地方,是它几乎像一堂交互节奏设计课。好系统不只是会回答,还要知道什么时候继续,什么时候停,什么时候请求确认,什么时候把判断交还给人。
换句话说,设计的单位不该只是一次输出,而该是下一步行动。
很多 Agent 产品之所以让人用两天就累,就是因为它们特别擅长一下子给很多,却不太擅长和人一起把下一步收窄。真正顺手的系统,常常会在关键节点主动停下来问一句:“你要我继续改,还是先给你看 diff?”这种节奏感,比多会几个花哨能力更重要。
今天就能立刻试的版本
今天随便选一个小任务,强迫自己用四轮最小协作完成:描述、生成、检查、修正。你可以试试补一个单测、改一段埋点、整理一次会议纪要。做完后再看一眼,这种节奏虽然不花哨,但通常比“一把梭哈”更稳,也更容易复用。
更新附注
- 版本:v1.1
- 更新日期:2026-03-20
- 更新原因:为系列文章补充统一阅读序号,帮助读者在趋势篇后顺畅进入协作方法篇。
还没有评论,你可以写下第一条。