当 AI 开始自己干活，我想做一个能看懂整个工作流的系统
最近，我越来越明显地感觉到，我使用 AI 的方式变了。
一开始，我主要是和 AI 聊天。想到一个问题，就问它；有了一个想法，就让它帮我整理；遇到不会写的代码，就让它给我一个例子。
后来，聊天开始变成协作。
我会和一个长期的 AI 伙伴讨论方向、整理想法、回顾之前做过的决定。等目标逐渐清晰，再把具体任务交给项目里的执行会话。
执行会话里又有一个 Lead，负责围绕目标组织工作。Lead 可以按需开启不同的 Worker，让它们分别开发、测试、审核，再根据结果调整下一步。
当任务变多，我又接入 GitHub Issue，并开始做自己的任务看板。我想知道每件事进行到哪里、卡在哪里、还缺什么，以及哪些问题需要我来决定。
慢慢地，我发现自己关心的问题也变了。
除了“这个任务完成了吗”，我还想知道：
- 整个项目是怎么流动起来的？
- 一个需求经过了哪些决策和交接？
- 哪些环节总是在等待、返工或者重复沟通？
- AI 做出一个选择时，依据是什么？
- 这一次遇到的问题，能不能帮助下一次做得更好？
这也是我现在想做的一件事：
把散落在聊天、记忆、文档和 Agent 之间的工作过程，变成一套可视化、可复盘、可以持续改进的工作流系统。
它目前还在探索中。我已经有一套自己使用的 AI 协作方式，也正在搭建配套工具，但距离我想象中的完整系统还有很长一段路。
这篇文章记录的，就是我为什么走到这里，以及我准备怎么继续往前走。
一、我的愿望：让一个人也能组织复杂的工作
我一直对一件事很感兴趣：一个人到底能完成多大的项目？
过去，一个人有想法，不代表一个人能把它做出来。
做一个软件，需要需求、设计、开发、测试和运营。
做一款游戏，需要世界观、玩法、程序、美术、音效和发行。
做一部短剧，需要选题、剧本、分镜、制作、发布和数据反馈。
这些事情并不是有了一个好点子就能完成的。它们更像一条很长的链：每个环节都有自己的输入、输出、判断和交接。
链条一长，即使每个环节都愿意学，一个人的时间和精力也很难同时照顾到所有细节。
AI 出现之后，这件事开始发生变化。
它可以参与研究、写作、设计、开发、审核，也可以帮助我整理信息和制定计划。不同的 Agent 还能围绕同一个目标分工协作。
我期待的是，一个人可以借助 AI，组织起原本需要经过许多环节才能完成的工作，同时慢慢弄明白这套方法为什么有效、哪里还能改进。
这不是说一个人从此不需要其他人，也不是说 AI 已经能可靠地完成所有事情。我的愿望更具体一些：先把自己手里真实的项目组织好，让想法有机会经过执行、反馈和复盘，逐渐变成能被验证的成果。
二、我现在是怎么和 AI 一起工作的
写下这篇文章这一部分时，我主要使用 Cindy 作为日常的 AI 协作环境，并借助 Pi harness、伙伴、任务会话和 Orca Team，把不同类型的工作分开。这是当时的状态。最近，我开始尝试把需要跨 Provider 协作、多个任务并行或 worktree 隔离的工作放进 Paseo；日常单 Agent 任务仍优先使用合适的官方客户端。这不是全量迁移。两者的定位差异，以及这次调整和我想做的工作流系统之间的关系，我会在本节后单独说明。
这套方式是在一次次实际使用中慢慢摸索出来的。
1. 伙伴：陪我思考长期方向
我有一个长期交流的 Cindy 伙伴。
我会和它讨论项目、想法、计划和遇到的问题，也会借助它整理记忆、梳理方向。
它像一个长期了解我背景的伙伴，聊起项目时，我们可以接着之前的话题往下走。
有些事情适合在这里慢慢聊。
比如：
- 我为什么想做这个项目？
- 现在的方向是否值得继续？
- 几个项目之间是什么关系？
- 一个模糊想法能不能拆成具体任务？
它不一定要立刻给我一份完美方案，但它能帮我把脑子里零散的东西整理出来。
2. 任务会话：把具体事情交给具体项目
当一个想法足够清晰，我会把它变成项目文件夹里的任务。
任务可以由我自己创建，也可以在和伙伴聊天后委托它创建。
我希望每个任务都尽量有明确的目标、边界和交付要求。这样执行时，不需要把所有历史聊天都重新讲一遍，也不需要让一个会话同时承担整个项目的全部背景。
当有大量任务需要持续推进，我会接入 GitHub Issue，并在本地开发的看板里查看状态、进度、卡点、需求和任务明细。
对我来说，这一步很重要：想法只有进入任务系统，才开始有机会被安排、执行、检查和复盘。
3. Lead 和 Worker：把执行拆成协作
每个需要协同执行的任务，会有一个 Lead 会话。
Lead 负责围绕目标组织工作：理解任务、拆解工作、派发给 Worker、检查结果，再决定下一步。
Worker 则按需要承担更具体的工作，比如代码开发、测试或者审核。
目前，我和伙伴聊天时使用的模型，以及执行任务的 Lead，采用的是
gpt6.1-terra。开发和审核等工作，则会按需交给使用 Claude 的 Worker。这是我结合使用体验、任务类型和成本，逐渐摸索出的选择。换一个人或任务，也许会有不同的搭配。
Lead 开启目标模式后，会持续围绕任务目标推进。执行过程中，Lead 可以和 Worker 沟通：普通信息可以排队，需要及时纠偏时也可以尝试插话。
我喜欢这种方式，是因为它同时保留了两件事：
一方面，Worker 可以专注处理具体问题；另一方面，Lead 仍然对整体方向负责，不会因为某个局部任务做得很投入，就忘了最初要解决什么。
当然，这不意味着 Lead 越频繁地查看 Worker 就越好。我更希望它在关键节点检查结果，在发现偏差或遇到阻塞时介入，而不是不停地重复读取状态。
我个人对 Claude 和 ChatGPT 的使用感受
选择模型时，我越来越在意它能否帮我看清问题，以及找到更合适的做事方法。
如果条件允许，我会尽量选择 Claude Opus 5.5。对我来说，它更像一位经验丰富的智者：不会只是顺着我的想法往下做，还会帮我判断什么值得做、什么暂时不该做，以及有没有更快、更稳妥的路径。
ChatGPT 给我的感觉则不太一样。它更像一个工作习惯很好、表达能力强、思维逻辑清晰的伙伴。它擅长理解我的意图，用我比较舒服的方式配合我，把一件事情有条理地推进下去。
我还有一个不太严谨，但很贴近我使用感受的比喻。
有些 AI 像一个聪明、努力的孩子。它愿意尝试，也能做很多事，但面对一个超出当前认知的难题时，可能会一直围绕目标努力，却迟迟捅不破那层窗户纸。它不断尝试、积累，期待在足够多的量变之后，碰到一次质变。
Claude 带给我的感觉不同。它更像一个有丰富成功经验、认知层次比我高出几个台阶的人：我迈不过去的坎、始终抓不住的关键问题，或者没能看清的第一性原理，它有时能很快帮我指出来，让我意识到自己原来是站错了位置。
一个更像依靠量变积累，等待质变发生；另一个则像凭借更高的认知，从另一个维度打开突破口。
这也是为什么，在我的个人使用体验里，Claude 和 ChatGPT，以及其他大多数 AI，给我的感觉并不在同一条水平线上。
这只是我的个人体验。不同模型有各自的特点，任务、成本和协作方式也会影响我的选择。目前我的部分 Lead 工作仍然使用 GPT，开发和审核则按需交给 Claude。我愿意把模型看作各有所长的伙伴，根据眼前的问题选择合适的搭档。
这个感受后来还影响了我对整套系统的看法，我会在第九节回过头来说。
从 Cindy 到 Paseo：我开始按任务选择协作环境
最近我开始使用 Paseo。它是一个开源的 Agent 开发环境，不是模型本身，也不只是一个终端窗口。它有自己的桌面和移动界面，可以在工作区里查看文件、Diff、终端和内置浏览器，并组织 Claude Code、Codex、Pi 等编码 Agent、项目与会话。
这里有一个我现在会特别区分的地方：Paseo 提供的是编排和工作区界面，Agent 仍通过各 Provider 的 CLI 或接口启动。按 Paseo 的接入文档，Codex 通过官方
codex CLI 与 app-server 接入，Claude Code 则通过 claude CLI 与 Claude Agent SDK 接入（Codex 接入，Claude Code 接入）。它可以保留 Provider 的配置、Skills 和 MCP 等工作方式，但这不等于完整复制 Codex、Claude 官方桌面应用的所有专有体验或云端功能。对我来说，是否值得用 Paseo，要看工作区与并行管理省下的时间，能否抵过我在具体任务里对原生产品功能的需要。所以，我没有打算把所有编码工作都迁进一个编排层。单 Agent、而且依赖某家原生客户端专属体验的任务，我会优先用相应官方应用；跨 Provider 协作、多个独立任务并行或需要隔离工作区时，再考虑 Paseo。开始时，我会拿两三个真实任务小范围试用，观察省下的协调时间，以及是否损失了我确实需要的原生能力。
我会先按目标建立任务会话：简单的事情就在当前工作区直接处理；需要并行推进时，再把研究、开发或审核拆成清楚的任务，交给不同会话。如果几项工作可能改到同一批文件，我会考虑用独立分支和 Git worktree 把工作区隔开（并行开发说明）；如果选择共享目录的 local 模式，就要先写清谁能改什么、哪些改动必须等上游完成。即使使用 worktree，也要明确任务边界并检查产出，隔离不是自动验收。
这次调整也让我更清楚地看到几个层次的区别。官方客户端提供各自厂商的原生体验；Paseo 帮我组织正在工作的 Agent、项目、工作区和会话；而我想做的工作流系统，还要回答更上游和更下游的问题：需求为什么出现、关键决策是什么、任务在哪里等待或返工、结果如何验收，以及一次复盘怎样影响下一轮工作。它们可以搭配使用，但不是同一件产品，也不需要互相替代。
我不会把多 Agent 编排当作自动保证不冲突或自动验收的机制。任务边界、代码隔离和结果检查仍需要明确设计；涉及发布、资金或外部系统的动作，我也会保留人工确认。
在 Pencil 中切换不同的搭档
我在使用 Pencil 时，也很喜欢一种顺手的体验：可以把当前会话快速新建为标签，再根据手头的工作切换不同的 Agent 模型。遇到需要梳理思路的事情，我可以选择擅长分析的模型；进入具体实现或检查环节时，再换一个更适合当前任务的模型。
这样的切换让我更容易沿着同一件事继续往下做，少花一些时间在窗口之间来回整理。我仍会在切换后看一眼新会话带过来的背景是否完整，尤其是已经做过的决定和当前任务边界，确保新搭档接得上前面的工作。
三、关于上下文：找到长期用得起的方式
在实际使用中，我还花了不少精力处理上下文和费用之间的关系。
目前我使用的
gpt6.1-terra 可以使用约 1M 的上下文。但在我使用的计费条件下，超过 272K 之后，上下文部分的费用会明显上涨。因此，我选择在接近 272K 前提前压缩上下文，给日常使用留出更合适的成本空间。
这背后有一个很实际的判断：
上下文窗口大，不代表每一次任务都应该把它用满。
如果所有背景、所有文档和所有历史记录都塞进同一个会话，表面上看，AI 好像知道了更多；但费用、噪音和维护难度也会一起增加。
我目前的做法是组合使用几种方式：
- 用 Pi harness 作为模型调度框架，尽量减少预置提示词占用；
- 把大任务拆成相对独立的小任务；
- 给文档做规范分类，让执行者按需读取；
- 在接近自己设定的阈值前压缩上下文；
- 把重要目标、约束和进度保留在可再次读取的文档中。
在这样的工作方式下，272K 对我的日常对话和任务处理已经比较充裕。
当然，压缩不是免费的“无限记忆”。它可能遗漏某些细节，所以我更希望重要信息不只存在于对话摘要里，而是能回到项目文档、任务记录和交付物中。
我的经验是：先了解自己使用的模型和计费方式，再结合任务拆解与资料组织，找到可以长期运行的平衡点。272K 是我在当时计费条件下选的阈值，其他人可以根据实际情况调整。
四、当 AI 能持续工作，我开始想看懂整个系统
这套协作方式运行起来以后，我看到了它的价值，也看到了下一层问题。
以前我最关心的是：AI 能不能完成一个任务？
现在我更关心的是：很多任务连接起来以后，整个工作系统到底发生了什么？
举一个软件开发的例子。
一个需求被提出后，可能先进入 Issue；然后由 Lead 理解目标、拆分任务；Worker 完成开发；另一个 Worker 进行审核；测试发现问题后再退回；最后形成可以交付的结果。
这个过程中，每一步都有信息在流动：
同时，参与者也在流动：
如果只看最后的“完成”两个字，很容易错过很多重要信息：
- 开发很快，但审核等待了很久？
- 测试反复失败，是代码问题，还是需求一开始不清楚？
- 某个模型价格便宜，但它的结果需要大量返工？
- 一个决策反复被推翻，是缺少信息，还是没有明确谁负责拍板？
- 同一种卡点出现了三次，下一次能不能提前避免？
这些信息可能存在于聊天记录、任务日志、项目文档和 Issue 中，但它们分散在不同地方。
这让我意识到：自动执行是一回事，看懂执行过程是另一回事。
目前借助 Agent 和自动编排，我已经可以让工作围绕目标持续推进。接下来，我希望把过程也呈现出来：看清发生了什么，理解为什么会这样，再为下一轮工作留下经验。
五、我想做一张能看见工作过程的地图
任务看板很有用。
它可以告诉我：哪些任务待处理，哪些正在进行，哪些完成了。
但我想做的东西，比任务状态多走一步。
我希望它能成为一张活的工作地图。
这张地图不仅展示“有什么节点”，还要尽量连接节点背后的真实工作：
- 输入是什么；
- 输出是什么；
- 谁在执行；
- 谁在决策；
- 工作交给了谁；
- 花了多少时间；
- 遇到了什么问题；
- 最后如何验收。
在我目前的设想里，它至少有四个层次。
第一层：看见工作流
我希望先把一个项目的主要流程展示出来。
例如软件开发：
例如短剧制作：
画出这些流程，是为了回答一个最基本的问题：
事情现在走到了哪里，下一步需要什么？
不同项目的流程未必完全相同。软件开发有软件开发的交付标准，短剧制作有内容制作和发布的节奏。系统需要允许它们采用不同的节点和路径，而不是把所有工作塞进同一张固定模板。
第二层：看见数据和协作如何流动
工作流不仅是节点之间连一条线。
一份需求交给开发时，开发需要知道什么？测试拿到的是代码、说明，还是一套明确的验收标准？一个节点的产出，能不能被下一个节点理解和使用？
我也想看见参与者之间的关系。
这里的参与者可能是我、其他人、AI 伙伴、Lead、Worker，或者某个外部工具。
比起安排多少“职位”，我更关心怎样把职责说清楚：
- 谁提出目标？
- 谁负责执行？
- 谁来检查结果？
- 哪些决定可以自动做？
- 哪些决定需要人确认？
- 出现问题后应该交给谁处理？
当这些关系清楚以后，我才有机会分辨：一个项目卡住，究竟是某个 Agent 能力不足，还是交接本身出了问题。
第三层：看见效率和卡点
我希望系统能逐步帮助我观察每个环节的情况。
例如：
- 一个节点执行了多久；
- 其中多少时间在实际工作，多少时间在等待；
- 哪些任务反复返工；
- 哪些问题经常需要人工介入；
- 哪些决策偏好在持续影响结果；
- 哪些流程看起来很自动化，实际却制造了更多沟通成本。
我不认为所有问题都能靠数字自动解释。
一个节点耗时长，不一定代表它效率低；也可能是任务更难，或者它提前发现了本来会造成更大返工的问题。
我希望把数据和当时的背景放在一起看，弄清楚这里究竟发生了什么。
第四层：让复盘影响下一次工作
这是我最期待的部分。
假设我发现，开发任务经常在审核阶段被退回。
继续追踪后，发现任务派发时的验收标准写得不够清楚。
那么下一次，我可以尝试在开发之前增加一个检查：
目标是否明确？验收标准是否可验证？不在范围内的事情有没有写清楚？
然后再观察一段时间：审核退回是否减少了？总耗时是否改善了？有没有引入新的等待？
这就是我理解的“工作流迭代”。
我希望这次经验能真正影响下一次的工作方式，再通过结果验证改变有没有用。
我希望未来系统能更主动地发现规律、提出调整建议。但在早期，我更愿意先让它把证据整理出来，由我确认哪些改变值得尝试。
六、通用工作流的困难：不同行业，不能只换一张流程图
我的长期愿望是，这套工具不仅能用于软件开发，也能逐渐支持游戏开发、短剧制作、运营投流等工作。
但我也知道，“通用”不是把软件开发里的“开发、测试、交付”几个词换掉，就能自动适用于所有行业。
软件开发关注代码、测试、版本和交付。
短剧制作可能更关心剧本版本、素材、画面、审美和发布反馈。
运营投流还会涉及预算、渠道、素材表现、转化数据和资金边界。
它们都可以被看作工作流，但每个领域的产物、判断标准和风险并不一样。
所以我现在更愿意把这个问题拆成两部分：
共同的部分，可能是目标、节点、输入、输出、参与者、交接、状态和复盘。
不同的部分，则是每个领域自己的工作内容、工具、数据和验收方式。
如果未来要做成一个通用系统，我希望先把共同的骨架找出来，再允许不同工作流保留自己的结构。
不过，在验证之前，这仍然只是我的产品判断。真正好不好用，要看它能不能承接具体项目，而不是看概念是否完整。
七、我会先从自己最熟悉的场景开始
虽然我想覆盖很多工作流，但第一步不会同时做软件、游戏、短剧和运营。
我准备先从自己每天都在使用的软件开发工作流开始。
原因很简单：这里有真实任务，也有现成的 Issue、会话、代码、测试和审核记录。我可以反复观察，也能比较容易判断某个改进有没有帮助。
第一版，我希望先围绕一个真实任务，把链路连接起来：
如果这条链还不能清楚展示，我就没有必要急着做一个覆盖所有行业的大系统。
我会先问自己几个问题：
- 能不能找到这个任务的目标和验收标准？
- 能不能看见它经历了哪些节点？
- 能不能找到关键产物和验证结果？
- 卡住的时候，能不能知道需要谁处理？
- 复盘出的一个问题，能不能在下一次得到验证？
如果这些基本问题回答不了，再多的图表也只是装饰。
八、当 AI 在执行，我的工作变成了什么？
我有时会半开玩笑地说：AI 能干越来越多的事，我好像只能看着它干活。
但后来我发现，我真正需要做的，不是一直盯着它。
我的工作正在发生变化。
以前，我可能要亲自完成很多具体动作：查资料、写代码、整理文档、检查结果、推进下一步。
现在，其中越来越多的动作可以交给 AI 协助。但这并不意味着目标会自动出现，结果也不会自动变得有价值。
我仍然需要决定：
- 为什么要做这件事？
- 哪个方向值得投入？
- 什么结果才算完成？
- 哪些事情可以让 AI 自己尝试？
- 哪些决定需要我确认？
- 最终产物是否符合我真正想要的东西？
涉及资金、发布、隐私或其他现实影响时，我也会保留相应的授权和检查边界。
所以我现在更愿意把自己的角色理解成：
为目标、判断和最终结果负责的人。
AI 可以帮助我执行，系统可以帮助我观察，但“我们为什么往这里走”，仍然需要我自己想清楚。
在画完这张地图之前，我还想先回答一个问题：这套系统，是不是一直都有必要？
九、一个坦白的前提：这套系统，也是一种妥协
回头看我现在的这套方式：伙伴负责陪我想，Lead 负责组织，Worker 分头开发和审核，Issue 记录任务，看板盯着进度，复盘负责把偏差拉回来。每一层都有它的用处。
但它们为什么需要存在？
很大一部分原因是，通用的 AI 还不能稳稳地把一件复杂的事，从头到尾独自扛下来。
所以我把大事拆小，把小事分给不同的角色，在中间设检查点，出了偏差再靠复盘纠正。我自己搭的这些可视化 AI 工作流，本质上是在用外部结构，去补通用 AI 独自撑不住复杂工作的那一部分缺口。
我把它叫作一种妥协。这不是贬义，意思是：这套结构是“在现有条件下能走通的办法”，而不是“事情本来就应该这样做”。
这个判断来自一个很具体的假设。
如果我手里有稳定、量大的 Claude Opus 算力供应，不用盘算额度，也不用在上下文长度和费用之间反复权衡，那么我现在搭的大部分东西，可能就没有必要了。
我只需要创建一个目标，让 Claude 自己运行下去。拆解、分工、自检和纠偏，它会在过程中自己完成。
这是我目前的判断，还没有被我完整验证过。它至少取决于三个前提：算力足够稳定和充裕；目标能被说清楚、能被验收；涉及资金、发布和隐私的事情，我依然保留授权和检查。
那我为什么还要继续搭？
第一个原因很现实。第三节我写过，我花了不少精力在上下文和费用之间找平衡。稳定而量大的顶级模型算力，并不是随手可得的条件，至少现在不是我的日常条件。条件不够的时候，结构的作用，就是把有限的算力用在刀刃上。
第二个原因，是我的一个推测。如果“编排”这一层，终究会被更强的模型自己吃掉，那么留下来的，可能是另一类东西：我为什么做这个决定，目标有没有真的达成，这一次的经验有没有被留下来。这些属于“看懂”，而不是“指挥”。也就是第四节说的那句话：自动执行是一回事，看懂执行过程是另一回事。
所以我现在这样给自己定位：
Lead、Worker 这类编排结构，更像施工时搭起来的脚手架。楼盖得越稳，它越可以逐步拆掉。
目标、决策记录和复盘，则更可能留在楼里，长期有用。
我会按这个顺序投入：先做能让我看见过程、留下经验的部分；编排层则保持轻量，随时准备跟着模型能力的变化一起收缩。
十、我想做的是一张会成长的地图
无论脚手架最后会被拆掉多少，眼下我要做的事情是清楚的。
我现在还没有完成这套通用工作流系统。
我有正在使用的伙伴、Lead、Worker、Issue 和任务看板，也有一个越来越清晰的方向：把它们之间的关系组织起来，让工作过程能够被看见，让经验能够进入下一次工作。
这条路上有很多问题还需要验证。
比如，什么信息值得记录，什么信息只会制造噪音；怎样衡量效率，才不会让系统为了漂亮数字牺牲质量；哪些流程适合自动调整，哪些必须由人确认。
我不想急着给这些问题一个看似完整的答案。
我想先从自己正在做的项目出发，把一个个真实任务跑通，记录它们在哪里卡住、为什么返工、什么方法真的有帮助。
然后再把这些经验慢慢变成工具。
对我来说，这套系统更像一张地图，帮助我看清自己和 AI 一起走过的路。
地图上有目标，有路径，有参与者，有已经走过的地方，也有还没有解决的问题。每完成一次工作，地图就多一点真实的信息；每做一次复盘，下一次出发时，就能少一些盲目。
随着 AI 承担越来越多执行工作，我也想继续学习：如何看懂一件事从想法走向结果的全过程，让每一次实践都为下一次积累经验。
Loading...
