一个窗口和很多窗口,我都用累过
我最早用 AI 做开发时,几乎所有事情都放在一个对话里。产品想法、页面修改、代码问题、发布记录,全往同一个窗口里塞。这样做有个很直接的好处:不用找东西,打开它就能接着聊。
用久以后,这条对话开始变得很重。刚讨论完首页,旧的支付问题又被带回来;昨天确认过的决定夹在几百条消息里,新任务还要重新解释一遍。AI 处理一个耗时任务时,我也只能停在那里等。界面和上下文越来越重,原本连续的思考反而被等待切断。
我随后走到另一个极端。只要一个任务要等,我就新开对话。短期看确实并行了:这个窗口改页面,另一个查账号,再开一个写文章。很快,我同时开到了七八个,后来更多。
窗口多起来以后,记忆工作落回了我身上。我得记住每个窗口发过什么、正在等什么、哪个结论已经作废。两个任务碰到同一条产品规则,还要重复解释。切换窗口的动作很快,重新进入那段上下文却一点都不快。
一个超长对话把所有事情挤在一起,很多零散对话又把我变成了人工调度员。我想保留多任务并行,也想让自己的注意力只停在一处。
我不再记窗口,开始记「这件事该找谁」
变化从给对话改名开始。以前的名字是「前端修改」「查订单」「写博客」,听起来都像一次性任务。任务结束以后,这个窗口也失去了位置。
我把它们换成真实公司的职位:产品经理、支付工程师、设计主理人、博客主编、版本与发布工程师。名字一换,我判断事情的方式也跟着变了。新需求出现时,我不用回忆它属于哪号窗口,只要判断该由哪个职位负责。
我给这套正在运行的做法起了一个名字:FlowOS。这里的 OS 借用了「工作方式」的意思。它目前是我给自己搭的 AI 公司工作台,还没有变成安装后自动运转的软件。职位长期存在,任务有明确负责人,确认过的规则写进项目手册,完成结果先进入待送达队列。
产品 A
产品 A|产品经理 产品 A|账号与套餐产品经理 产品 A|邀请运营 产品 A|支付工程师共用专业角色
金田 AI 设计室|设计主理人 金田 AI|版本与发布工程师 金田 AI|自动化管家内容与其他产品
AI 小白博客|主编 GPT 充值站|产品经理主对话只保留一个,它也不包办所有工作
我每天主要待在「金田 AI|董事长助理」这条对话里。新想法、临时问题、项目取舍,都从这里开始。它先听懂我在说什么,补齐必要边界,再把事情交给合适的长期角色。
董事长助理不会因为自己能写代码,就顺手把设计、开发、检查和发布全部做掉。它负责把问题送到对的人那里,遇到会改变方向、碰到权限或需要我判断的地方,再把决定带回主对话。
这条边界对我很重要。主对话一旦下场包办,过一会儿又会变回最初那个超长窗口。职责收窄以后,它才能一直留出空间,让我继续思考下一件事。
一次真实需求,是怎么在后台流转的
最近我在主对话里提过一个前台需求。我原话的大意是:
导航的液态玻璃要能轻微看到下面内容;用户中心余额要高亮;页面滚动以后,余额进入导航栏。
这句话同时碰到了视觉、产品口径、前端实现和发布。以前我会把它塞进一个开发窗口,再一边改一边补充。现在它会经过下面这条路。
只说想达到的用户体验,不负责拆设计和代码任务。
产品经理接住需求,先确认这次改动的业务边界。
设计主理人决定液态玻璃和滚动状态;账号与套餐产品经理确认余额口径;唯一代码 Owner(代码负责人)实现页面。
Git、生产备份、部署和公网复测只在视觉通过以后开始,发布角色不替产品和设计做决定。
后台处理前台需求时,我仍在董事长助理这里讨论「把 FlowOS 写成一篇博客」。
内容任务由另一个长期职位负责,产品改版和博客写作可以同时往前走。
设计、实现、核查和文章结果不轮流抢话,等到可观察的自然停顿,再合并成一个信封送回主对话。
这个过程里,设计主理人不领导产品经理,产品经理也不长期管理发布工程师。谁负责最终结果,谁就临时组织需要的专业角色。下一次可能是支付工程师找产品经理确认状态,也可能是博客主编请设计室做一张图。
模型会忘,项目手册把结论留下来
职位分开以后,还有两个问题必须解决:长期记忆放在哪里,完成结果什么时候回来。
LLM 的上下文会变长,也会被压缩。换一个任务以后,它不该靠「好像记得」来决定产品规则。我把已经确认的事实、职责、操作红线和验收方法写进 Wiki 或项目手册。新任务先读手册,工作中得到稳定的新结论再写回去。
项目手册补的是可查的外部记忆。它不会让模型永久记住一切,也不会自动判断所有新旧冲突。规则有变化时,仍要明确更新;过期结论也要被替换。
结果送回的方式同样影响心流。每个后台角色一完成就插话,我的主对话会不断被「已完成」「请确认」「又有更新」切碎。我现在把这些结果先放进回流队列,像一排等待送达的信封。
所谓「注意力感知」,只允许使用明确事件:我说完一段话、主动查看进度、当前回复刚结束。系统不能读心,也不知道我是否正在现实世界里思考。我给它定下的目标,是在这些可观察的边界把几条结果合成一份短摘要;稳定自动执行仍在补齐。
我第一次跑,就把异步又做回了串行
职位分工开始运行后,我很快遇到了第一个失败。董事长助理已经把任务派到后台,我却又让它同步等结果。主对话在那里等了约 8 分钟,我也跟着看了约 8 分钟。角色换了名字,使用方式却退回了「发完任务守着窗口」。
后来还有一次,某个任务已经完成,只在自己的任务里留下了 NEEDS_USER(需要我确认)。它没有主动回到董事长助理。我以为事情还在进行,直到追问才发现结果早就等在那里。
按职位分工已经真实运行,后台任务也能独立完成。注意力感知回流队列还没有完成端到端自动送达:有时主对话仍会错误同步等待,有时完成结果还停在原任务里。
我后来开始补统一回执规则:完成、阻塞、需要我决定、等待外部反馈,都应该主动回到主对话。主对话收到后先保存,不急着每条都打断我。这个方向已经明确,自动合并和稳定送达仍在继续补。
哪些已经在运行,哪些还在补齐
已经在运行
我只在董事长助理这条主对话里持续思考;长期任务按真实职位命名;产品、设计、工程和内容角色能在后台分工;确认过的规则会写进项目手册;发布仍保留审图、Git、备份和公网复测。
仍在补齐
后台完成结果还需要更稳定地主动送回;多条回执要自动合成一封;自然边界的判断只能依赖可观察事件;项目手册也需要持续整理,避免旧规则和新结论同时存在。
FlowOS 现在更像一套边运行边修正的方法。它已经改变了我每天怎么和 AI 工作,但还没有变成打开网站、安装 Skill 就能复制的成品。我会继续把真实用法和失败补进去,等它足够稳定,再整理成网站和可复用 Skill。
我为什么还会继续这样用
角色名字只是入口。我继续这样用,是因为注意力终于有了固定位置。
我少了很多守着 AI 窗口等待、在多个对话之间来回找进度的时间。主对话接住正在形成的想法,后台职位接住已经能明确交付的工作,项目手册接住需要长期保留的结论,回流队列接住完成但不必立刻打断我的结果。
这套做法没有消灭沟通成本。职责要写清,手册要维护,回执要能送达,主对话也必须克制自己不下场包办。它只是把原来全部压在我脑子里的调度工作,逐步放回一套看得见、能检查的流程里。
我现在打开「金田 AI|董事长助理」,仍然像打开一条普通对话。区别在后台:我说完一件事以后,可以继续想下一件;那些已经知道该怎么做的工作,会去找自己的负责人。