以前我用 AI，有个特别明显的问题：
越用越乱。
不是说所有主题都塞进同一个窗口。
大多数认真用 AI 的人，都会按项目或主题开不同窗口。
但真实工作里，一个项目内部也经常会混在一起。
比如做一个产品功能，前面还在聊需求和定位，接着就让 AI 改代码，再往下又让它写说明文档、整理发布内容、顺手记几个待处理问题。
刚开始还好。
聊着聊着，上下文就开始漂。
AI 一会儿要理解产品取舍，一会儿要进入开发细节，一会儿又要切到内容表达。
它不是不聪明。
而是同一个项目窗口里，被塞进了太多不同性质的工作。
我后来想到一个很形象的说法：
这就像一个工位坐了五个人。
RAGino Sans GB", "Microsoft YaHei", "Helvetica Neue", Helvetica, Arial, sans-serif;text-align: start;font-size: 18px;font-weight: bold;text-wrap-style: initial;color: rgb(255, 76, 0);letter-spacing: 0.544px;text-decoration: underline;">问题不是 AI 不够强，而是没分工
现实公司里，不会让开发、测试、项目经理、文案、顾问全坐一个工位。
因为不同岗位关注的东西不一样。
开发关心需求、代码、问题记录和当前任务。
测试关心验证步骤、缺陷状态和复现路径。
写作关心素材、表达、读者和历史文章。
项目管理关心目标、拆解、优先级和推进节奏。
但以前我们用 AI，即使已经按项目开了窗口，也经常会在一个项目窗口里混着做很多不同性质的事。
这其实很容易把上下文弄乱。
所以后来我开始做一件很简单的事：
给 AI 分工位。
工位不是人格，而是上下文入口
我现在说的 AI 工位，不是给 AI 起人格名字。
更不是说它真的变成了某个岗位的人。
它本质上是不同类型工作的上下文入口。
比如：
writer，写作工位，负责内容输出和素材整理； pm，规划工位，负责目标拆解和任务安排； dev，开发工位，负责开发实现和问题处理； qa，测试工位，负责测试验证和风险检查； consultant，顾问工位，负责方案分析和建议。
这些英文名只是目录和指令里的短名字。
真正重要的不是名字，而是每个工位进入项目后，会读取不同的资料。
写作工位会更关注素材池、历史文章、内容风格、用户画像和观点沉淀。
开发工位会更关注需求说明、问题记录、开发计划、技术资料和当前任务状态。
测试工位会更关注验证清单、缺陷复现、测试结果和风险边界。
同一个 AI，进入不同工位，看到的上下文不一样，工作状态也会不一样。
AI 开始像进入了一个岗位
慢慢地，我发现一个变化：
AI 不再像一个万能聊天机器人。
它开始像进入了一个具体岗位。
不是因为它突然有了长期记忆。
而是因为我把它要看的资料、要做的事情、要遵守的边界，都放到了对应的工作位置里。
它进来以后，不是从一句问题开始猜。
而是先看这个工位该看的上下文，再接着做事。
这张图先不用全部看懂。
这一篇只看其中一层：roles，也就是不同工位。
至于 AI 真正在哪里接任务、读资料、更新状态，我下一篇再展开。
Agent 系统" dir="auto" style="margin: 32px 8px 0px;letter-spacing: 0.578px;line-height: 1.75em;">这不是复杂 Agent 系统
很多人看到这里，第一反应可能会是：
“你是不是搞了什么复杂 Agent 系统？”
其实不是。
很多时候，我仍然是用 Claude Code、Codex、Markdown 和文件夹，把不同工作放到不同位置。
再由我来决定什么时候进入哪个工位，交给 AI 做哪一段。
所以这不是“AI 自己开公司”。
也不是全自动系统。
更像是一个基于文件的 AI 协作工作区。
人负责切任务、控方向、做验收。
AI 负责读取上下文、执行具体动作、整理记录、协助推进。
不同 AI，也会逐渐形成不同分工
还有一个很现实的变化。
我现在并不是“哪个 AI 最强，就全都用它”。
而是慢慢形成了自己的使用分工。
比如近期对我来说，Codex 更多用于写作、内容整理、规划和分析，Claude Code 更多用于开发、调试、测试和脚本。
这不是工具能力的绝对判断。
只是我持续试错接近一年以后，最近才逐渐固定下来的一点个人习惯。
有点像现实团队里，不同的人会慢慢形成自己的工作侧重。
分工的价值，是减少上下文混乱
所以我给 AI 分工位的价值，不是为了看起来高级。
它真正解决的是一个很直接的问题：
不要让所有工作挤在同一个上下文里。
一个项目窗口里什么都混着聊，最后 AI 很容易不知道自己此刻到底应该站在哪个工位上。
分工以后，每个工位尽量围绕一类事情展开，资料更集中，目标更清楚，交接也更容易。
这不是一套已经成熟运行很久的方法。
更准确地说，它仍然是一个偏早期的工作样板。
只是对我来说，它已经开始解决真实问题。
这也是我这一年最大的体感之一：
AI 越强，越不能只靠临时聊天。
它需要进入工作结构。
如果你也经常在一个 AI 窗口里混着写文案、改代码、做规划，可以先做一个很小的动作：
把最常做的两类工作拆开，各自列出 AI 进入时必须读取的资料。
你现在最想给 AI 分出的第一个工位是什么？
欢迎留言告诉我。
下一篇，我想继续讲这个结构里最关键的一层：
真正重要的，可能不是提示词。
而是 AI 的工作台。
在变化快、事情多、信息又杂的环境里，
个人或团队，怎样把事情一步步坐稳，不返工、不翻车，几年后还能用得上，
那我们关注的，其实是同一个问题。
我逐渐把一些“容易出问题的地方”和“更稳的做法”，
整理成了一套可以反复使用的判断与结构，
也写进了书和方法论里。
