这是上周日我在亦庄模数 OPC（WaytoAGI 社区运营）做的一次线下分享，现场收到了一些好评。回来整理成文字，分享给大家。
工具越来越多，模型越来越厉害，但如果用法没变，人反而可能越来越忙。
一个窗口写文章，一个窗口做图，一个窗口改代码。看起来拉起了一支 AI 团队，实际上每个窗口都在等你回话。你得搬资料、补背景，告诉它下一步干什么，发现不对再回来改。
AI 确实干了不少活，但你也没闲着，只是从亲手干活，变成了到处传话。
我现在不太想这么用了。
我是老金。除了自媒体，我现在还在做得到和私域的课程，同时推进几个自己的项目：多媒体助手、金融量化助手、Meta_Kim、工作台，还有个人助理。这些项目大多还在开发，谈不上成熟，更谈不上躺着收钱。
但有一件事确实变了：越来越多的工作，不用等我亲手干完上一件，下一件就能开工。
不是因为我突然会写代码了，也不是因为我把每个行业都学了一遍，而是我慢慢摸出了一套自己的 AI 工作方式。
先做研究，把事情弄明白，再判断自己到底要什么。然后把目标和标准跟 AI 对齐，选合适的工具，拆任务、做编排、往下执行，最后拿真实结果验收。
这套流程，现在贯穿了我写内容、做课程、开发产品的很大一部分工作。 
先把陌生的事研究明白，再决定怎么做
进入一个不熟悉的题材，我第一步通常是先做深度研究（Deep Research）。
只说我自己的使用体验：这一块我最认可 ChatGPT 网页版，没有之一；其次是 Gemini；国内我会用豆包，这是我的使用判断。
我看重的是我把问题和需求交代清楚之后，它能不能围着这个问题，帮我把一个领域的重要信息铺开。
这个领域是什么情况，有哪些关键概念，大家在争论什么，有什么典型案例，哪些说法有依据，哪些还有分歧。
有时候，它还会把我一开始压根没想到的问题带出来。
这个能力对我特别重要，以前进入一个陌生领域，最麻烦的往往不是资料少，恰恰是资料太多。搜一下，几十篇文章，再搜一下，又几十个观点。你不知道哪个重要，哪个只是噪音，甚至不知道自己还漏了什么。
深度研究先给我的，不是最终答案，而是一张地图。
它让我知道这个领域大概长什么样，重要的问题在哪里，哪些地方值得继续往下挖。至于往哪条路走，还得结合我要做的事情判断。
当然，我不觉得做一次深度研究，就能把一个领域的资料收全。它能研究到什么程度，一开始就跟题材、目标和问题范围有关。
但对一个本来不懂的人来说，先把重要问题过一遍，建起一个相对完整的认识，再顺着关键问题往下问，已经很有价值了。
过去最难受的，是连自己不知道什么都不知道。现在至少可以从这张地图出发，一步步核对、理解和验证。
我还会特别要求它找反证。我的判断可能错在哪里，有没有相反案例，哪些地方的证据还不够。如果 AI 只是把我本来就相信的东西说得越来越漂亮，那不叫研究，那叫给自己壮胆。
先研究，不是为了拖延开工，而是为了少在错误的方向上忙活。 
写公众号，我关心普通人为什么值得关注，这次变化到底厉害在哪里，宣传和实际使用之间有没有落差，怎么讲才能让读者理解。
做课程，我会看哪些能力稳定、哪些操作能复现，学员最容易卡在哪里，怎么拆成一个能学会的过程，最后到底能交出什么。
开发产品，我又会去看用户需求、现有竞品、替代方案、技术边界和实现成本。做得出来是一回事，值不值得我继续投入，是另一回事。
所以，我不太喜欢研究一结束，就把整份报告原样扔给另一个 AI，说帮我写一篇文章。这样当然也能写，但很容易写成资料汇总，信息很多，判断很少。
我的做法是先取舍：哪些东西真正改变了我的判断，读者或用户最该知道什么，哪些内容虽然有意思，但跟这次要解决的问题没关系。
该删就删，该继续查就继续查，最后留下的才进入制作阶段。
题材决定研究范围，目的决定信息取舍。研究里冒出十种机会，不代表我就要做十种。 
进入制作阶段，工具要按场景选
自媒体和课程创作，我现在主要用 Codex。文章、课程讲稿、流程图、思维导图、封面和配图，还有一些 HTML 展示页面，都在同一个项目环境里往前推。
其他场景，我还会用 Claude Code、ZCode、DSH（也就是 DeepSeek Harness）、WorkBuddy，以及豆包工作。
具体用哪个，按任务来。哪套做法已经在某个环境里跑顺了，就继续在那儿用，不会为了显得工具齐全，每次把所有软件都打开一遍。
而且我现在越来越在意生态。
豆包工作我会多用一点，一个重要原因就是飞书生态。资料在飞书，协作也在飞书，成果最后还要回到飞书，能不能接进原来的工作环境，会直接影响体验。具体能读写到哪一步，还是看实际接入和授权的范围。
我判断工具好不好用，看它能替我完成哪一段，结果又能不能直接接到下一段。
单个回答有多漂亮，我现在没那么在意。少让我来回搬几次，才是真省事。 
我在手机上看一张图，就能发现很多没对齐的地方
做课程时，我经常把复杂关系画成流程图、思维导图。哪一步先做，什么条件满足才能往下走，放进图里，比一大段说明更容易看清楚。
做产品，我也会先看原型。
拿工作台来说，我要的是看清任务做到哪了、谁在负责、卡在哪里。先把这个页面画出来，我就能检查它有没有抓住重点。如果最该出现的任务入口都找不到，界面再精致也得改。
这个时候，在手机上把问题指出来，让 AI 调整原型，比等代码写完再返工，代价小得多。
我不是在手机上画每一个按钮，我是在手机上判断它有没有做对。
文字把规则说清楚，图把结构摆到眼前，交互和异常状态再放到真实页面里验。三个环节接起来，我才敢让后面的制作继续。
还有我会把AI做的事情，和飞书都打通，每天早上我的 AI 小助手就会给我按照优先级整理事项，什么做完了，直接语音告他，所有相关的状态一并更改。 
以前做游戏策划的习惯，现在反而更有用了
我以前做了很多年游戏研发。现在回头看，这段经历对我使用 AI 的影响挺大。
游戏策划案本身就是一套复杂的东西，不是列几个功能点就完了。我手上还有一个原本用来写策划案的 Skill，从目标、制作原则、用户体验，一路写到模块、功能、流程、原型，最后甚至细到字段定义。
比如我会用我做的这个工作台来串工作流： 
这些内容必须是一条线。
为什么做这个东西，哪些原则不能破坏，我希望用户得到什么感受，然后才是具体做什么、怎么呈现、需要记录哪些数据。
不能前面说降低用户理解成本，后面却设计五层菜单、十几个按钮和一堆复杂状态。那前面写得再漂亮，也没有意义。
一个状态在规则里有，在原型里没有，到了数据定义里又换了个名字，后面的人就只能一边做一边猜，返工也会接着来。
所以现在做产品、做课程，甚至写内容，我也会一直往前追：这个东西为什么存在，它服务哪个目标，这个功能、这张图、这段文字，真的在服务那个目标吗？
不服务，就考虑删掉，别因为已经做出来了，就舍不得。
这个 Skill 真正值得留下的，不是一份看起来完整的文档，而是一套每一步都能往前找到理由的方法。 
一个人为什么更快？很多等待被拿掉了
我做过项目，很清楚一件事从提出到做完，中间花的时间不全是在制作。
要排期，要交接，要重新解释。有时候大家都很忙，一份东西已经好了，却得等下一位有空才能继续。每个人单独看都没问题，项目还是走得慢。
我现在经常用 subagent，把不同的活儿分出去：有的管内容，有的管设计，有的管开发，还有专门负责检查的，最后由主 Agent 统筹。
听起来很爽，但这里面有一个很大的坑：人多不等于效率高，AI 也一样。
如果几个 Agent 理解的目标不同，它们做得越快，最后合起来就越麻烦。
比如做一门课程，学习目标还没确定，就让一个 Agent 写讲稿，一个做图，一个出练习。大家同时开工，看起来效率拉满，最后一看，做的是三门课。
这不叫并行，这叫并行制造返工。
所以分工之前，我先把目标、成功标准和共同依据定下来。哪些已经定了，哪些不能自己拍板，交给下一步的东西长什么样，都得说清楚。
能独立完成的，就并行。有前后依赖的，就等待。前面的结论没出来，后面别靠猜继续往下做。
真需要几个成员共享任务、直接沟通时，我才会用 Agent Teams 这类协作方式。串行还是并行，看的是任务之间的依赖，不是团队叫什么名字。
对我来说，真正值得看的不是同时开了多少个 Agent，而是它们的结果能不能接起来，出了问题能不能找到对应的人和环节。 
Meta_Kim：把组织这一层补上
我有一个 GitHub 开源项目，叫 Meta_Kim，中文名元架构。
我做它的原因很直接：模型越来越会干活以后，真正开始变难的，是谁来组织这些会干活的能力。
它要补上的，是需求对齐、能力选择、任务编排、审查和验证这一层，而不是再造一双会写代码的手。
先说需求对齐。我说了一句话，AI 得先弄明白我真正想改变什么，而不是立刻冲出去开工。
最近加了个可视化界面，大概长这样，还没做完。 
如果两个选择会导致项目走向不同方向，它就应该问我。比如同样做一个工具，先给自己用，还是准备做成对外产品，后面的权限、数据、部署、交付和维护都会不同。
这种选择，AI 不能偷偷替我决定。但如果风格已经确认，只是某个间距要调整，或者一个明确的错误要修，就别每次都回来开会。
我想保留的是决定方向的权力，不是亲自批准 AI 的每一次鼠标移动。
方向对齐以后，再盘点当前环境里真正能用的能力。有哪些 Agent、Skill、MCP 和工具，权限够不够，输入输出是什么，最后的成果能不能被下一步接住。
不是把电脑里装过的工具名字列出来，就算拥有了这些能力。
然后才进入编排。谁做什么，哪个先做，哪个后做，哪里并行，哪里等待。哪一步不通过，退回哪里，什么条件满足以后才进入交付。
编排者不一定亲自把所有事都做了，但它要负责让这些能力别互相打架。
以前做游戏项目也是一样。程序、美术、策划、测试都很厉害，不代表项目会自然变好。还得有人把目标、顺序、交接和验收组织起来。AI 团队并没有绕过这个问题。 
设好 Goal，让工作继续往前走
如果每完成一步，AI 都停下来问我"接下来呢"，那我并没有真正离开执行，只是变成了一个不停回"继续"的项目经理。
所以我会先用 GoalPro 把目标说清楚：真实意图是什么，做完以后要改变什么，什么算成功，哪些事这轮不做，要留哪些证据，什么情况必须停下来。
对的，这个也在我的Github开源项目上。
它管的是整理 Goal Prompt 和 Loop Prompt，自己不执行任务。也不是在提示词里写一句"每天继续"，就等于有了后台自动化。真正干活的，还是 Codex、Claude Code 这些执行工具。
这些约定做好，再让执行工具往下走。做完以后，我也不会只看它说完成了。
我现在越来越不信这三个字，我想看证据。
文章有没有讲清楚要解释的问题，页面能不能完成目标操作，测试有没有真的跑，修改有没有解决原来的故障，又有没有把其他地方搞坏。
不通过，就回到对应环节改。通过了，再往下走。不能做完以后，临时挑几项容易过的检查，给自己交差。
所以，我要的不是 AI 永远不要停，而是在目标、权限和约定范围都没有变化时，它能自己继续推进。真正会改变结果，或者需要超出授权范围的时候，再回来找我。
连续折腾几轮却拿不出新东西，也该停。那只是在换着说法重复自己，再跑下去没有意义。
我不需要一台永远忙碌的电脑，我需要一件越来越接近完成的工作。 
这时候再接上向日葵这样的远控工具，我在手机上就能查看电脑、操作界面，处理需要人接手的环节。
我要做的，更多是看看这轮交了什么，哪里不满意，哪条路线要改。具体的活儿还在电脑上的执行环境里跑，我不用在手机上逐字写文章、逐行改代码。电脑保持开机，进度保存好就行。
当然，这么跑很吃额度，具体有多费，我后面单独说。
不过话说回来，以前同样一批事摆过来，得先找人、分工、排时间，很多想法连第一版都轮不上。
这两种烦恼，我更愿意处理现在这一种。
现在经常卡住我的，反而是额度
这套工作方式有个特别现实的问题：吃额度。
按我现在的强度，文字、图片、课程加上几个项目一起推，Codex 的量有时候一天都撑不住，哪怕用 GPT-6 的轻模式，也烧得很快。当然，这只是我的实际感受，不代表所有人都会这样。
所以我现在不太喜欢只看这一轮生成花了多少，而是看交出一份真正能用的成果，一共付出了多少时间、用量和人工收尾。
结构没定就批量出图，方向一变全部重做。几个 Agent 反复阅读同一批无关资料，看起来都在研究，其实在重复花钱。局部错误导致整个任务从头再来，也是成本。
最便宜的一次生成，不一定能带来最便宜的一次交付。
这也是为什么前面的研究和对齐不能省。方向没想清楚的时候，执行得越积极，浪费可能越大。
如果一轮工作跑下来，既没有更清楚的判断，也没有更可用的成果或者新的依据，那就该停下来看看：究竟是在推进，还是只在消耗。
写在最后
我现在能并行做内容、课程和几个项目，不是因为这些工作都不需要我了，而是它们可以处在不同阶段。
哦对，顺带说一句，我的Github是KimYx0207，开源了不少，希望对你有帮助。 
有的还在研究，有的已经进入制作，有的正在测试。能自己推进的部分先往前走，真正需要我拍板的问题，再集中回来。
但同一个项目内部，依赖关系仍然存在。目标没确认，不能急着大规模开发；核心规则没定，也别让一堆 Agent 各写一套。
多个项目并行，不代表每个项目里的所有步骤都要并行，更不代表发现一个机会，就立刻再开一个项目。
对一个人来说，AI 让可执行的事情变多了，但我的注意力没有跟着无限增加。哪些先做，哪些后做，哪些干脆不做，反而更需要我决定。
知道先不做什么，也是生产力。
我做过团队项目，知道要把研究、内容、设计、开发和测试凑到一起，需要多少准备。
对一个刚开始做事的人来说，还没验证想法，先得解决谁来做、怎么配合、成本能不能承担。这一步就会挡住很多事情。
现在，我可以先拿着手机，把本地电脑上的 AI 组织起来，完成文章和课程材料，推进产品开发，再根据真实结果往前走。
不是每个项目都会成功，也不是所有问题都能交给 AI。但一个人已经有机会，接住过去要一个小团队才能接住的工作。
这件事给我的底气，比又学会一个新工具大得多。
以前得先凑齐人，才敢开始验证一个想法。
现在，我可以先把东西做出来。
至于它值不值得继续，让结果告诉我。
谢谢你读我的文章。
如果觉得不错，随手点个赞、在看、转发三连吧🙂
如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章。
开源知识库地址（实时更新交流群）：