standmeet·文章
简体中文
← 返回文章
Use is a person using AI; collaborate is person-to-person; coordinate is session-to-session. Underneath, one move: cut the work into blocks that don't depend on each other, leave an explicit interface, no cosplay anywhere.文章 · standmeet2026.10.30 · 文章
2026.10.30·1 分钟阅读

Use, Collaborate, Coordinate: How I Actually Work with AI / 使用、协作、协同——我怎么用 AI

Use is a person using AI; collaborate is person-to-person; coordinate is session-to-session. Underneath, one move: cut the work into blocks that don't depend on each other, leave an explicit interface, no cosplay anywhere.

使用、协作、协同——我怎么用 AI

先把三个词分开,别混着说。使用是我用 AI,我使唤它。协作是人和人,我和队友一起干。协同是会话和会话,我同屏开一排 AI,各跑各的。

网上教「如何用好 AI」,基本只讲第一件,还常常只到「会写 prompt」。但有杠杆的地方,是看懂这三件底下是同一个动作在三个尺度上重复:把一摊活拆成互不依赖的块,块之间留一个显式接口。一直拆到底、落在一个 AI 一个上下文里,就是使用。

还有一条贯穿始终:不管哪一级,我们都不玩 cosplay。没有谁 act as 资深架构师,也没有哪个 agent 被安成测试专家。角色扮演解决不了任何事。拆的是活,交出去的是判据——什么算对、拿什么量——不是一件戏服。

使用:把 AI 用进一个干净的闭环

能用结构堵死的,就不靠规矩守。 这有个梯度。最差是靠叮嘱「记得要 XX」,迟早有一次没人记得。中间是写进机制拦住:hook 拦掉用 sed 读文件、用脚本改文件;文档里禁「可能」「大概」,一个偶发挂的测试,它不能跟我说「应该无关」,得拿 master 和修复版各跑五次、2/5 对 5/5,把数据摆出来。再往上一层,是让坏写法根本写不出来:一个事实只存一个地方,没有第二份就没有写错的那一份;路径从不存成能改的字段,永远从树结构现算;SQL 里名字只走格式化、值只走参数位,你连一条注入都拼不出来。能让错误写不出来,就别停在拦住它。

交活给判据,完成由机制判。 我给的是判据:什么算对、拿什么量、哪种算失败。「做完了」写成一条从外部核的常驻检查,它自己说了不算。

完成  ⟺  判据(测试绿∧eval 过) 由外部核 ≠ agent 自称“好了”\text{完成}\iff \text{判据}(\text{测试绿}\wedge\text{eval 过})\ \text{由外部核}\ \neq\ \text{agent 自称“好了”}

先验证,再谈做完。 修 bug,先写一个红的端到端测试把问题复现出来,再改到绿。不许拿 UT 绕,不许加重试,不许固定等几秒蒙混。有次一个兑码测试红了,它从日志里拆出两个根因:节流把页面刷新吞了,消息总线的授权又晚到零点几秒;一个补刷新,一个改成先等授权,分别发版。

我不写长需求,在关键处插一句。 需求你永远写不全,边界都是干到一半才冒出来的。它准备收尾时我一句「先看看人家的规矩」,它才回头去读人家的 AGENTS.md,单测风格和文档跟着返工。

协同:按上下文把活拆成一排会话,并行跑

为什么拆成多个,而不是一个会话从头干到尾?上下文。一个会话就是一个上下文窗口,什么都往里塞,它越来越胀、越来越钝、越容易串味。所以我把活切成互不依赖的块,一块一个会话,各有一个干净上下文,同时往前走。独立是前提:块之间不依赖,才能并行,我也不用在中间来回同步。这比一件件串着做快得多,快不在 AI 变聪明,在我没让它们互相等,也没让谁的上下文被别的事拖脏。

拆分分两层。我先拆:把一摊活切成几条独立的线,一条一个会话,就是屏幕上那排 tab。难的不是切,是切得真独立,切完每条能自己跑到头。然后 agent 自己拆:每个会话再把自己那条线往下分,该开 subagent 就开,它自己掌控。它最常拿 subagent 保上下文——会把主窗口塞爆的重活,比如拉上千个文件、翻几十万字日志,丢给 subagent 去跑,只把结论收回来,过程不进主上下文。

多数时候它们各干各的,协同只在两条线真碰上时才发生:一个会话的产物交给另一个接着做,一个重活要占资源先打声招呼,一个卡住了去问别的会话拿经验。该说话才说话,否则一排会话互相喊,先被淹的是我。

并行一多,稀缺的不是算力,是我的注意力。所以每个会话得自己掂量什么时候该找我:能往下走就别打扰,卡住了、要拍板、或者一件事做完验过了,再浮上来。消息发不到的时候,我就是那条总线,替它们转。

产出 ≈ ∑i=1Nsessioni ,瓶颈=我的注意力 (不是算力)\text{产出}\ \approx\ \sum_{i=1}^{N}\text{session}_i\,,\qquad \text{瓶颈}=\text{我的注意力}\ (\text{不是算力})

协作:人和人,用 issue 板当解耦中间件(最上一级)

再放大一级,不是我和一排会话,是我和真人队友。我俩各自用 AI,两个独立闭环,谁也不看对方的会话。把我们接起来的是一块 issue 板,它就是中间件,而一条 issue 常常是两边 AI 产出汇合的地方。

举个真的。一个队友传了本日文 PDF,正文全丢。他那边也在用 AI,在本地做了完整复现:逐行对出一样的乱码,定位到解析时少传了一个参数,还点出「有七百多字、不算空,所以没触发 OCR」,顺带给了修复方向和回归测试。这条 issue 本身就是一份能直接执行的交接单。我说一句「我认领」,交给我这头的 AI:把参数补上,加一条「每页字太少就走 OCR」的判据,补端到端用例(原书他没附,就按形状造个夹具),先红后绿,冒烟,再回到 issue 上写清楚修了什么、哪些还没覆盖,等我点头才发、才关单。他那边的 AI 把现象变成根因加复现,我这边的 AI 把 issue 当规格去实现和验收,issue 的评论就是两边汇合的点。整个过程我俩谁也没看过对方的会话。

当中间件,就有中间件的规矩。消息得能路由到对方那一端:有次 AI 修完只推了 main 和 prod、没合到 dev,队友只在 dev 上验收,一看修复没了——后来写成死规矩,提交后必须合 dev。板上传的是症状,结论要 AI 自己坐实成证据。碰到不可逆的动作,板上得装一道人工闸。

有次 AI 以为邮件接口某个参数能把收件人限成一个,连调四次,结果那接口是群发给所有人,几封定时的上线邮件被提前发出去,真人收到了,收不回;从那以后定死,AI 永远不碰发送,凡是对外可见、收不回的动作,最后一下人来按。还有条小规矩:git log 里有两个作者,AI 不许把队友的提交当成我写的。

一个没解决的坑

把完成写成机制判,好,但我反复栽在一处:判据写成「全部实现」,却没把「只能人推的外部前提」划出去。买开发者账号、桌面发版后手点、重启机器,这些 AI 推不动,于是那条检查每轮都判没做完,它一遍遍回我「没有变化」,我说「算完成」它都清不掉。

工具越自治,越得明说:哪些是它的活,哪些只能等人。这条我还在调。

使用、协作、协同是三件事,底下是同一招,在三个尺度上重复:把活拆成互不依赖的块,留显式接口,按判据交出去,全程不 cosplay。拆到哪一级都一样,只有一下永远留给人——会越过接口、落到别人身上又收不回的那一下,人按。

就这篇文章向 AI 提问·上下文：“use, collaborate, coordinate: how i actually work with ai / 使用、协作、协同——我怎么用 ai”
›
试试“What's the practical takeaway from "use, collaborate, coordinate: how i actually work with ai / 使用、协作、协同——我怎么用 ai"?”/“How does this relate to the owner's current work?”