当 AI 开始自己干活，我想做一个能看懂整个工作流的系统
最近，我越来越明显地感觉到，我使用 AI 的方式变了。
一开始，我主要是和 AI 聊天。想到一个问题，就问它；有了一个想法，就让它帮我整理；遇到不会写的代码，就让它给我一个例子。
后来，聊天开始变成协作。
我会和一个长期的 AI 伙伴讨论方向、整理想法、回顾之前做过的决定。等目标逐渐清晰，再把具体任务交给项目里的执行会话。
执行会话里又有一个 Lead，负责围绕目标组织工作。Lead 可以按需开启不同的 Worker，让它们分别开发、测试、审核，再根据结果调整下一步。
当任务变多，我又接入 GitHub Issue，并开始做自己的任务看板。我想知道每件事进行到哪里、卡在哪里、还缺什么，以及哪些问题需要我来决定。
慢慢地，我发现自己关心的问题也变了。
我不再只问：“这个任务完成了吗？”
我开始想知道：
- 整个项目是怎么流动起来的？
- 一个需求经过了哪些决策和交接？
- 哪些环节总是在等待、返工或者重复沟通？
- AI 做出一个选择时，依据是什么？
- 这一次遇到的问题，能不能帮助下一次做得更好？
这也是我现在想做的一件事：
**把散落在聊天、记忆、文档和 Agent 之间的工作过程，变成一套可视化、可复盘、可以持续改进的工作流系统。**
它目前还在探索中。我已经有一套自己使用的 AI 协作方式，也正在搭建配套工具，但距离我想象中的完整系统还有很长一段路。
这篇文章记录的，就是我为什么走到这里，以及我准备怎么继续往前走。
一、我的愿望：让一个人也能组织复杂的工作
我一直对一件事很感兴趣：一个人到底能完成多大的项目？
过去，一个人有想法，不代表一个人能把它做出来。
做一个软件，需要需求、设计、开发、测试和运营。
做一款游戏，需要世界观、玩法、程序、美术、音效和发行。
做一部短剧，需要选题、剧本、分镜、制作、发布和数据反馈。
这些事情并不是有了一个好点子就能完成的。它们更像一条很长的链：每个环节都有自己的输入、输出、判断和交接。
当链条变长，一个人最大的困难，往往不只是“能力不够”，而是没有足够的时间同时处理所有细节。
AI 出现之后，这件事开始发生变化。
它可以参与研究、写作、设计、开发、审核，也可以帮助我整理信息和制定计划。不同的 Agent 还能围绕同一个目标分工协作。
但我真正期待的，并不是让 AI 替我点击更多按钮。
我更想看到的是：一个人可以借助 AI，组织起原本需要很多环节才能完成的工作，并且逐渐理解这套工作为什么有效、哪里还可以改进。
这不是说一个人从此不需要其他人，也不是说 AI 已经能可靠地完成所有事情。我的愿望更具体一些：先把自己手里真实的项目组织好，让想法有机会经过执行、反馈和复盘，逐渐变成能被验证的成果。
二、我现在是怎么和 AI 一起工作的
目前，我主要使用 Cindy 作为日常的 AI 协作环境，并借助 Pi harness、伙伴、任务会话和 Orca Team，把不同类型的工作分开。
这套方式不是我一开始就设计好的，而是在实际使用中慢慢长出来的。
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 就越好。我更希望它在关键节点检查结果，在发现偏差或遇到阻塞时介入，而不是不停地重复读取状态。
三、关于上下文：我追求的不是装得最多，而是长期用得起
在实际使用中，我还花了不少精力处理上下文和费用之间的关系。
目前我使用的 `gpt6.1-terra` 可以使用约 1M 的上下文。但在我使用的计费条件下，超过 272K 之后，上下文部分的费用会明显上涨。
所以，我并没有把“用满 1M”当成目标，而是选择在接近 272K 前提前压缩上下文。
这背后有一个很实际的判断：
上下文窗口大，不代表每一次任务都应该把它用满。
如果所有背景、所有文档和所有历史记录都塞进同一个会话，表面上看，AI 好像知道了更多；但费用、噪音和维护难度也会一起增加。
我目前的做法是组合使用几种方式：
- 用 **Pi harness** 作为模型调度框架，尽量减少预置提示词占用；
- 把大任务拆成相对独立的小任务；
- 给文档做规范分类，让执行者按需读取；
- 在接近自己设定的阈值前压缩上下文；
- 把重要目标、约束和进度保留在可再次读取的文档中。
在这样的工作方式下，272K 对我的日常对话和任务处理已经比较充裕。
当然，压缩不是免费的“无限记忆”。它可能遗漏某些细节，所以我更希望重要信息不只存在于对话摘要里，而是能回到项目文档、任务记录和交付物中。
我现在的经验不是“272K 是所有人的最佳阈值”，而是：先理解自己使用的模型和计费方式，再结合任务拆解与资料组织，找到可以长期运行的平衡点。
四、当 AI 能持续工作，我开始想看懂整个系统
这套协作方式运行起来以后，我看到了它的价值，也看到了下一层问题。
以前我最关心的是：AI 能不能完成一个任务？
现在我更关心的是：很多任务连接起来以后，整个工作系统到底发生了什么？
举一个软件开发的例子。
一个需求被提出后，可能先进入 Issue；然后由 Lead 理解目标、拆分任务；Worker 完成开发；另一个 Worker 进行审核；测试发现问题后再退回；最后形成可以交付的结果。
这个过程中，每一步都有信息在流动：
同时，参与者也在流动：
如果只看最后的“完成”两个字，很容易错过很多重要信息：
- 开发很快，但审核等待了很久？
- 测试反复失败，是代码问题，还是需求一开始不清楚？
- 某个模型价格便宜，但它的结果需要大量返工？
- 一个决策反复被推翻，是缺少信息，还是没有明确谁负责拍板？
- 同一种卡点出现了三次，下一次能不能提前避免？
这些信息可能存在于聊天记录、任务日志、项目文档和 Issue 中，但它们分散在不同地方。
这让我意识到：自动执行是一回事，看懂执行过程是另一回事。
目前借助 Agent 和自动编排，我已经可以让工作围绕目标持续推进。接下来我想做的，是让这个过程不只是“跑起来”，而是能够被看见、被理解，并且为下一轮工作留下经验。
五、我想做的，不只是一个任务看板
任务看板很有用。
它可以告诉我：哪些任务待处理，哪些正在进行，哪些完成了。
但我想做的东西，比任务状态多走一步。
我希望它能成为一张活的工作地图。
这张地图不仅展示“有什么节点”，还要尽量连接节点背后的真实工作：
- 输入是什么；
- 输出是什么；
- 谁在执行；
- 谁在决策；
- 工作交给了谁；
- 花了多少时间；
- 遇到了什么问题；
- 最后如何验收。
在我目前的设想里，它至少有四个层次。
第一层：看见工作流
我希望先把一个项目的主要流程展示出来。
例如软件开发：
例如短剧制作：
这些图不是为了把工作画得漂亮，而是为了让我能回答一个最基本的问题：
事情现在走到了哪里，下一步需要什么？
不同项目的流程未必完全相同。软件开发有软件开发的交付标准，短剧制作有内容制作和发布的节奏。系统需要允许它们采用不同的节点和路径，而不是把所有工作塞进同一张固定模板。
第二层：看见数据和协作如何流动
工作流不仅是节点之间连一条线。
一份需求交给开发时，开发需要知道什么？测试拿到的是代码、说明，还是一套明确的验收标准？一个节点的产出，能不能被下一个节点理解和使用？
我也想看见参与者之间的关系。
这里的参与者可能是我、其他人、AI 伙伴、Lead、Worker，或者某个外部工具。
我关心的不是给它们安排多少“职位”，而是把职责说清楚：
- 谁提出目标？
- 谁负责执行？
- 谁来检查结果？
- 哪些决定可以自动做？
- 哪些决定需要人确认？
- 出现问题后应该交给谁处理？
当这些关系清楚以后，我才有机会分辨：一个项目卡住，究竟是某个 Agent 能力不足，还是交接本身出了问题。
第三层：看见效率和卡点
我希望系统能逐步帮助我观察每个环节的情况。
例如：
- 一个节点执行了多久；
- 其中多少时间在实际工作，多少时间在等待；
- 哪些任务反复返工；
- 哪些问题经常需要人工介入；
- 哪些决策偏好在持续影响结果；
- 哪些流程看起来很自动化，实际却制造了更多沟通成本。
我不认为所有问题都能靠数字自动解释。
一个节点耗时长，不一定代表它效率低；也可能是任务更难，或者它提前发现了本来会造成更大返工的问题。
所以我想要的不只是一个“效率排行榜”，而是能把数据和上下文放在一起，让我更容易理解：这里究竟发生了什么？
第四层：让复盘影响下一次工作
这是我最期待的部分。
假设我发现，开发任务经常在审核阶段被退回。
继续追踪后，发现原因不是开发能力不足，而是任务派发时没有写清楚验收标准。
那么下一次，我可以尝试在开发之前增加一个检查：
目标是否明确？验收标准是否可验证？不在范围内的事情有没有写清楚？
然后再观察一段时间：审核退回是否减少了？总耗时是否改善了？有没有引入新的等待？
这就是我理解的“工作流迭代”。
它不是简单地让 AI 总结一句“下次注意”，而是让这次经验有机会改变下一次的工作方式，再通过结果验证这个改变有没有用。
我希望未来系统能更主动地发现规律、提出调整建议。但在早期，我更愿意先让它把证据整理出来，由我确认哪些改变值得尝试。
六、通用工作流的困难：不同行业，不能只换一张流程图
我的长期愿望是，这套工具不仅能用于软件开发，也能逐渐支持游戏开发、短剧制作、运营投流等工作。
但我也知道，“通用”不是把软件开发里的“开发、测试、交付”几个词换掉，就能自动适用于所有行业。
软件开发关注代码、测试、版本和交付。
短剧制作可能更关心剧本版本、素材、画面、审美和发布反馈。
运营投流还会涉及预算、渠道、素材表现、转化数据和资金边界。
它们都可以被看作工作流，但每个领域的产物、判断标准和风险并不一样。
所以我现在更愿意把这个问题拆成两部分：
共同的部分，可能是目标、节点、输入、输出、参与者、交接、状态和复盘。
不同的部分，则是每个领域自己的工作内容、工具、数据和验收方式。
如果未来要做成一个通用系统，我希望先把共同的骨架找出来，再允许不同工作流保留自己的结构。
不过，在验证之前，这仍然只是我的产品判断。真正好不好用，要看它能不能承接具体项目，而不是看概念是否完整。
七、我会先从自己最熟悉的场景开始
虽然我想覆盖很多工作流，但第一步不会同时做软件、游戏、短剧和运营。
我准备先从自己每天都在使用的软件开发工作流开始。
原因很简单：这里有真实任务，也有现成的 Issue、会话、代码、测试和审核记录。我可以反复观察，也能比较容易判断某个改进有没有帮助。
第一版，我希望先围绕一个真实任务，把链路连接起来：
如果这条链还不能清楚展示，我就没有必要急着做一个覆盖所有行业的大系统。
我会先问自己几个问题：
- 能不能找到这个任务的目标和验收标准？
- 能不能看见它经历了哪些节点？
- 能不能找到关键产物和验证结果？
- 卡住的时候，能不能知道需要谁处理？
- 复盘出的一个问题，能不能在下一次得到验证？
如果这些基本问题回答不了，再多的图表也只是装饰。
八、当 AI 在执行，我的工作变成了什么？
我有时会半开玩笑地说：AI 能干越来越多的事，我好像只能看着它干活。
但后来我发现，我真正需要做的，不是一直盯着它。
我的工作正在发生变化。
以前，我可能要亲自完成很多具体动作：查资料、写代码、整理文档、检查结果、推进下一步。
现在，其中越来越多的动作可以交给 AI 协助。但这并不意味着目标会自动出现，结果也不会自动变得有价值。
我仍然需要决定：
- 为什么要做这件事？
- 哪个方向值得投入？
- 什么结果才算完成？
- 哪些事情可以让 AI 自己尝试？
- 哪些决定需要我确认？
- 最终产物是否符合我真正想要的东西？
涉及资金、发布、隐私或其他现实影响时，我也会保留相应的授权和检查边界。
所以我现在更愿意把自己的角色理解成：
不是每一步都亲手完成的人，而是为目标、判断和最终结果负责的人。
AI 可以帮助我执行，系统可以帮助我观察，但“我们为什么往这里走”，仍然需要我自己想清楚。
九、我想做的是一张会成长的地图
我现在还没有完成这套通用工作流系统。
我有正在使用的伙伴、Lead、Worker、Issue 和任务看板，也有一个越来越清晰的方向：把它们之间的关系组织起来，让工作过程能够被看见，让经验能够进入下一次工作。
这条路上有很多问题还需要验证。
比如，什么信息值得记录，什么信息只会制造噪音；怎样衡量效率，才不会让系统为了漂亮数字牺牲质量；哪些流程适合自动调整，哪些必须由人确认。
我不想急着给这些问题一个看似完整的答案。
我想先从自己正在做的项目出发，把一个个真实任务跑通，记录它们在哪里卡住、为什么返工、什么方法真的有帮助。
然后再把这些经验慢慢变成工具。
对我来说，这套系统最终不只是为了管理 AI。
它更像一张地图。
地图上有目标，有路径，有参与者，有已经走过的地方，也有还没有解决的问题。每完成一次工作，地图就多一点真实的信息；每做一次复盘，下一次出发时，就能少一些盲目。
当 AI 开始承担越来越多执行工作，我想学习的，不只是如何让它干得更快。
我更想学习的是：如何看懂一件事从想法走向结果的全过程，并让这个过程随着每一次实践变得更好。
Loading...
