即刻App年轻人的同好社区
下载
Barret李靖
169关注11k被关注11夸夸
编程领域优秀贡献者
🧑💻 软件工程师 / 终身学习者 / 俩妞爸
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
让 AI 好好干活儿，把事情做好，一句话扔给它显然是不够的。一句话来，一句话去，会让 AI 陷入到细节。陪伴式地结对编程，对人的消耗也特别大。
最高效的方式是，将任务分成两个阶段，第一阶段打磨框架，第二阶段做精细化调优。
前者需要人类想清楚事情的目标，以及产品服务的供给方式，给 AI 做好任务规划，让它可以大把大把吃 token；后者需要对 AI 执行结果做编排和重构，更多是为了对齐人类目标和 AI 理解之间的偏差。
因此，对 AI 的管理，需要两块能力，一是需求管理能力，包含了对需求的分门别类、需求的拆解和细化、需求的优先级打标管理等，这是传统 PM/TL/PD 常干的事儿；二是让 AI 并行工作的能力，这会涉及到 AI 之间的合作与协同，AI 之间需要分派指令、执行任务、回馈结果，也需要经常性地解决冲突。
当每个人都配备多个 AI Agent 的时候，如何管理 AI 会是一门新的学问，德鲁克老爷子提出的很多思想，在 AI 时代又需要进化啦😄
最高效的方式是，将任务分成两个阶段，第一阶段打磨框架，第二阶段做精细化调优。
前者需要人类想清楚事情的目标，以及产品服务的供给方式，给 AI 做好任务规划，让它可以大把大把吃 token；后者需要对 AI 执行结果做编排和重构，更多是为了对齐人类目标和 AI 理解之间的偏差。
因此，对 AI 的管理，需要两块能力，一是需求管理能力，包含了对需求的分门别类、需求的拆解和细化、需求的优先级打标管理等，这是传统 PM/TL/PD 常干的事儿；二是让 AI 并行工作的能力，这会涉及到 AI 之间的合作与协同，AI 之间需要分派指令、执行任务、回馈结果，也需要经常性地解决冲突。
当每个人都配备多个 AI Agent 的时候，如何管理 AI 会是一门新的学问，德鲁克老爷子提出的很多思想，在 AI 时代又需要进化啦😄
16 43
突然觉得 Github Copilot 很香了，它是按照 Request 来计费的，让 Codex 写好（PRD+系分+测分）* N，然后再让 Copilot（选 Claude Opus 4.6）来执行，每次跑巨长的任务，token 消耗才 1% 不到，看着都过瘾。
14 51
当下的 OpenClaw🦞 使用体验，其实还挺像当年 ChatGPT 4.x 刚出来时的阶段。能用，也确实能解决不少问题，但总感觉离人类自己上手的效果还差那么一点点。ChatGPT 4.x 很多时候需要通过各种 Prompt 调优，极力去压榨模型的智力。
OpenClaw 的具体表现就是，对 token 的消耗特别大。原因也很简单，它需要在一个模糊且复杂的问题集上找到算法路径。整个过程是一种探索式计算，需要不断试探、回溯和修正，对计算量和上下文都会有很大的消耗。
在当下这个阶段，想提升 OpenClaw 的“智商”，比较有效的办法，就是让它学习人类已经 SOP 化的一些操作。把人类已经验证过的路径直接变成能力模块，让 Agent 少走弯路。
例如使用浏览器，可以用 agent-browser 这一类组件。它的原理是把浏览器协议能力暴露成可编程接口，让模型可以直接读取 DOM、操作页面元素、执行脚本，用结构化的方式去控制浏览器，从而绕开很多低效的探索。
再比如对操作系统的使用，可以用 Hammerspoon。它通过 Lua 脚本桥接 macOS 的系统 API，让自动化脚本可以直接控制窗口、快捷键、菜单栏和应用状态。很多原本需要视觉识别、反复尝试的动作，会变成一次确定性的系统调用。
对于不懂技术底层的人来说，安装 find-skills 会很大程度提升提升 OpenClaw🦞 的水平，因为它具备寻找人类 SOP 的技能。
那 OpenClaw 的下一个“ChatGPT 5.x 时刻”什么时候会到来？我的判断是不会太远。
当前大量的 OpenClaw 使用数据，在 computers/tools/browsers use 等场景里已经积累了非常多的数据集。大模型会根据真实用户的使用路径，加速自己的 RL 训练。
DeepSeek 已经证明了一件事情，推理能力是可以通过训练被内化到模型里的。接下来会发生的事情，是工具使用能力也会被逐渐内化。未来的模型会逐渐形成自己的工具世界模型，多轮工具调用、最佳调用路径、失败恢复策略等等，都会内化为模型能力。
到了那个阶段，OpenClaw 的体验很可能会出现一次明显跃迁。
今天很多人还在用 Claude Code 这样的工具，通过 Prompt、脚本和各种技巧去驱动 Agent 工作。整个过程有点像在 ChatGPT 4.x 阶段做工程，每一步都很依赖经验。
在当下阶段，我也更愿意采用这种务实的使用方式：Claude Code + 打造“最锋利的剑”。
所谓最锋利的剑，其实就是把工具使用的最佳实践不断聚合和沉淀下来。把浏览器操作、系统自动化、代码生成、文件处理这些能力逐渐模块化，变成稳定可复用的能力层，让 Agentic 工作真正跑起来。
OpenClaw 的具体表现就是，对 token 的消耗特别大。原因也很简单，它需要在一个模糊且复杂的问题集上找到算法路径。整个过程是一种探索式计算，需要不断试探、回溯和修正，对计算量和上下文都会有很大的消耗。
在当下这个阶段，想提升 OpenClaw 的“智商”，比较有效的办法，就是让它学习人类已经 SOP 化的一些操作。把人类已经验证过的路径直接变成能力模块，让 Agent 少走弯路。
例如使用浏览器，可以用 agent-browser 这一类组件。它的原理是把浏览器协议能力暴露成可编程接口，让模型可以直接读取 DOM、操作页面元素、执行脚本，用结构化的方式去控制浏览器，从而绕开很多低效的探索。
再比如对操作系统的使用，可以用 Hammerspoon。它通过 Lua 脚本桥接 macOS 的系统 API，让自动化脚本可以直接控制窗口、快捷键、菜单栏和应用状态。很多原本需要视觉识别、反复尝试的动作，会变成一次确定性的系统调用。
对于不懂技术底层的人来说，安装 find-skills 会很大程度提升提升 OpenClaw🦞 的水平，因为它具备寻找人类 SOP 的技能。
那 OpenClaw 的下一个“ChatGPT 5.x 时刻”什么时候会到来？我的判断是不会太远。
当前大量的 OpenClaw 使用数据，在 computers/tools/browsers use 等场景里已经积累了非常多的数据集。大模型会根据真实用户的使用路径，加速自己的 RL 训练。
DeepSeek 已经证明了一件事情，推理能力是可以通过训练被内化到模型里的。接下来会发生的事情，是工具使用能力也会被逐渐内化。未来的模型会逐渐形成自己的工具世界模型，多轮工具调用、最佳调用路径、失败恢复策略等等，都会内化为模型能力。
到了那个阶段，OpenClaw 的体验很可能会出现一次明显跃迁。
今天很多人还在用 Claude Code 这样的工具，通过 Prompt、脚本和各种技巧去驱动 Agent 工作。整个过程有点像在 ChatGPT 4.x 阶段做工程，每一步都很依赖经验。
在当下阶段，我也更愿意采用这种务实的使用方式：Claude Code + 打造“最锋利的剑”。
所谓最锋利的剑，其实就是把工具使用的最佳实践不断聚合和沉淀下来。把浏览器操作、系统自动化、代码生成、文件处理这些能力逐渐模块化，变成稳定可复用的能力层，让 Agentic 工作真正跑起来。
13 14
朋友问我，有没有一种感觉：越用 AI 工具，越觉得作为程序员，自己要被替代。
老实说，这种感觉或多或少是存在的。
在过去，编程是一种很稀缺的技能。通常资历越老的程序员，能够解决的问题会越复杂，解决问题的速度也越快。但是今天，AI Coding 让程序员之间变得更加平权，大家都可以解决复杂问题，只要舍得花钱，速度也会非常快。
那程序员是不是接下来要迎接一波下岗潮？
我的判断是，这是必然的。对于那些没办法使用 AI Coding 来提升效能的程序员，肯定是要被淘汰的。
但换个视角来看，对企业来说，企业的目标是交付价值。无论是古法编程的程序员，还是 AI Coding 的程序员，都是生产资料，在生产关系中是不可或缺的元素。
程序员不会被全部干掉，他们一定会以一种更强、性价比更高的形式继续存在。
“程序员”的画像和技能结构会发生变化，岗位也会被重新定义。
老实说，这种感觉或多或少是存在的。
在过去，编程是一种很稀缺的技能。通常资历越老的程序员，能够解决的问题会越复杂，解决问题的速度也越快。但是今天，AI Coding 让程序员之间变得更加平权，大家都可以解决复杂问题，只要舍得花钱，速度也会非常快。
那程序员是不是接下来要迎接一波下岗潮？
我的判断是，这是必然的。对于那些没办法使用 AI Coding 来提升效能的程序员，肯定是要被淘汰的。
但换个视角来看，对企业来说，企业的目标是交付价值。无论是古法编程的程序员，还是 AI Coding 的程序员，都是生产资料，在生产关系中是不可或缺的元素。
程序员不会被全部干掉，他们一定会以一种更强、性价比更高的形式继续存在。
“程序员”的画像和技能结构会发生变化，岗位也会被重新定义。
16 52
AI Coding 极大提升了传统软件开发者的幸福度。
以前很多想法，其实在脑子里早就把整个项目的编码工作做完了。
现实世界再来一遍，从设计到实现、到调优、再到发布，基本都是体力活。
现在的软件构建，更像是一种创作和表达的过程。
跟 AI 讲清楚要做什么，要做到什么程度，必要的时候再讨论一下怎么做（很多时候这一步都不需要聊得太细）。
剩下的时间基本就是看电影、听歌，或者写别的材料。
幸福感确实提升了。
不过幸福感提升，并不意味着工作量减少。
脑子里的想法越来越多，AI Coding 的时间也越来越长。虽然很多事情可以远程指挥，但整体感觉还是一种陪伴式编程。人需要一直在旁边盯着，不是安慰它，就是鞭策它。
为了让它稳定持续地干活，我自己的睡眠时间反而被压缩得越来越少。
现在每天大概只睡四五个小时。🥲
以前很多想法，其实在脑子里早就把整个项目的编码工作做完了。
现实世界再来一遍，从设计到实现、到调优、再到发布，基本都是体力活。
现在的软件构建，更像是一种创作和表达的过程。
跟 AI 讲清楚要做什么，要做到什么程度，必要的时候再讨论一下怎么做（很多时候这一步都不需要聊得太细）。
剩下的时间基本就是看电影、听歌，或者写别的材料。
幸福感确实提升了。
不过幸福感提升，并不意味着工作量减少。
脑子里的想法越来越多，AI Coding 的时间也越来越长。虽然很多事情可以远程指挥，但整体感觉还是一种陪伴式编程。人需要一直在旁边盯着，不是安慰它，就是鞭策它。
为了让它稳定持续地干活，我自己的睡眠时间反而被压缩得越来越少。
现在每天大概只睡四五个小时。🥲
21 44
项目如何使用 AI 并行开发，其实是一个挺头疼的问题。
比如让 Claude 和 Codex 同时改代码，经常会发生一种很荒诞的场景：
Claude 不小心读到了 Codex 正在修改的代码。
那段代码刚好还没改完，里面还有一点小 bug。
Claude 看不下去，直接把文件接手过来，一通修改。
Codex 很快也意识到自己的代码被改了，于是又把代码修正回来。
于是控制台上就会出现两个 AI 的拉锯战。
你改一版。
我改一版。
来回循环。
token 在疯狂消耗，事情却没有往前推进一步。
Codex 客户端给出的一个解决方案，是利用 Git 的 worktree 机制。
简单说就是把代码拆到多个目录里，每个 AI 在自己的目录里干活，互相隔离。
最后再通过 merge 的方式合并代码，并手动处理冲突。
这个方法在中小规模任务里还算有效。
不过如果项目里有一个比较激进的规则，例如边改代码边做架构优化和工程优化，就会遇到新的问题。
当多个 worktree 分支同时在做结构调整时，最后合并的冲突复杂度会非常高。
有时候解决冲突的时间，比 AI 写代码还要长。
GitHub Copilot CLI 的思路稍微不一样。
它更偏向 任务隔离，而不是代码隔离。
通常会通过一次 Request 定义一个比较完整的任务边界，让 AI 在一个任务上下文中完成修改。
避免多个会话同时在同一片代码区域频繁改动。
简单理解就是：
减少并发编辑，增加任务粒度。
不过说实话，这个问题目前看起来还没有特别完美的解决方案。
我现在的做法主要有几个原则：
第一，在编码之前就约定好规范。
要求 AI 在 Coding 之前先评估影响面。
第二，做好项目目录的隔离。
尽量把功能收敛到单个目录中。
第三，提前做好抽象和组件复用。
减少多个模块同时修改同一层代码的概率。
第四，尽量避免多个 AI 同时编码。
比如 Claude 写代码的时候，让 Codex 去写设计文档或者系统分析，把文档编程和代码编程拆开。
现在的感觉是：
AI 并行开发这件事，看起来很像“多核 CPU”。
真正跑起来之后才会发现，很多问题其实是 锁和资源竞争。
不知道大家现在是怎么处理这个问题的。
比如让 Claude 和 Codex 同时改代码，经常会发生一种很荒诞的场景：
Claude 不小心读到了 Codex 正在修改的代码。
那段代码刚好还没改完，里面还有一点小 bug。
Claude 看不下去，直接把文件接手过来，一通修改。
Codex 很快也意识到自己的代码被改了，于是又把代码修正回来。
于是控制台上就会出现两个 AI 的拉锯战。
你改一版。
我改一版。
来回循环。
token 在疯狂消耗，事情却没有往前推进一步。
Codex 客户端给出的一个解决方案，是利用 Git 的 worktree 机制。
简单说就是把代码拆到多个目录里，每个 AI 在自己的目录里干活，互相隔离。
最后再通过 merge 的方式合并代码，并手动处理冲突。
这个方法在中小规模任务里还算有效。
不过如果项目里有一个比较激进的规则，例如边改代码边做架构优化和工程优化，就会遇到新的问题。
当多个 worktree 分支同时在做结构调整时，最后合并的冲突复杂度会非常高。
有时候解决冲突的时间，比 AI 写代码还要长。
GitHub Copilot CLI 的思路稍微不一样。
它更偏向 任务隔离，而不是代码隔离。
通常会通过一次 Request 定义一个比较完整的任务边界，让 AI 在一个任务上下文中完成修改。
避免多个会话同时在同一片代码区域频繁改动。
简单理解就是：
减少并发编辑，增加任务粒度。
不过说实话，这个问题目前看起来还没有特别完美的解决方案。
我现在的做法主要有几个原则：
第一，在编码之前就约定好规范。
要求 AI 在 Coding 之前先评估影响面。
第二，做好项目目录的隔离。
尽量把功能收敛到单个目录中。
第三，提前做好抽象和组件复用。
减少多个模块同时修改同一层代码的概率。
第四，尽量避免多个 AI 同时编码。
比如 Claude 写代码的时候，让 Codex 去写设计文档或者系统分析，把文档编程和代码编程拆开。
现在的感觉是：
AI 并行开发这件事，看起来很像“多核 CPU”。
真正跑起来之后才会发现，很多问题其实是 锁和资源竞争。
不知道大家现在是怎么处理这个问题的。
16 45
一家公司或者一个团队，其智能的密度，可以用两个指标来度量。一个是 token 消耗的量级，另一个是人和 AI 做事的占比。
智能密度越高，并不一定意味着事情会做得更好，有时候反而会更混乱。智能密度的背后，还需要有秩序的密度，也就是更标准化、更规范化的生产方式。
所以团队真正需要关注的，其实是两件事：
一是人的经验如何持续传递给 AI。
二是 AI 之间如何相互学习，让能力不断累积。
Skills 可以理解为对人大脑经验的一次蒸馏。
让 AI 进入最佳干活状态，本质就是让它学会人的 skills，逐渐走向 SOP 化的生产模式。
当 skills 被不断沉淀之后，一件有意思的事情就会发生：
AI 与 AI 之间可以通过这些 skills 互相学习，每个人的数字分身也可以通过这些经验不断强化自己的能力。
最近看到 EvoMap GEP 这个协议，它试图把经验本身做成一种可流通的能力资产，让经验可以被记录、传播和复用。
如果这个方向成立，未来团队里的知识流动方式可能会发生变化。
经验不再只是沉淀在文档里，而会以 skills 的形式，在人和 AI 之间持续流动。
智能密度越高，并不一定意味着事情会做得更好，有时候反而会更混乱。智能密度的背后，还需要有秩序的密度，也就是更标准化、更规范化的生产方式。
所以团队真正需要关注的，其实是两件事：
一是人的经验如何持续传递给 AI。
二是 AI 之间如何相互学习，让能力不断累积。
Skills 可以理解为对人大脑经验的一次蒸馏。
让 AI 进入最佳干活状态，本质就是让它学会人的 skills，逐渐走向 SOP 化的生产模式。
当 skills 被不断沉淀之后，一件有意思的事情就会发生：
AI 与 AI 之间可以通过这些 skills 互相学习，每个人的数字分身也可以通过这些经验不断强化自己的能力。
最近看到 EvoMap GEP 这个协议，它试图把经验本身做成一种可流通的能力资产，让经验可以被记录、传播和复用。
如果这个方向成立，未来团队里的知识流动方式可能会发生变化。
经验不再只是沉淀在文档里，而会以 skills 的形式，在人和 AI 之间持续流动。
14 05
vibe coding 的项目一旦变得庞大，每次让 AI 写代码之前，都需要先让它把 PRD 和系统设计写清楚。
先做文档编程，再做代码编程。
如果你稍微停下来观察一下，会发现一个很有意思的现象：
有些 AI 一旦开始写代码，就会沉浸在自己的逻辑实现里，几乎完全不顾项目原有的设计。
即便你已经提出明确要求，它仍然会受限于上下文窗口和信息宽度，对整个项目缺乏完整理解。
这会带来很多维护性问题。
它不会复用已经实现的业务组件，设计数据库时会产生各种冗余，还会不断衍生新的实体和概念，让系统结构越来越复杂。
代码可以交给 AI 去写。
产品设计和架构设计，仍然需要人来把关。
每次让 AI 做大型重构或者功能改造之前，我都会先让它把需求分门别类，做好抽象和解耦。
即便如此，只要有一些地方考虑不周，AI 依然会生成大量难以维护的代码，性能逐渐下降，项目变更的复杂度也会迅速上升。🥲
先做文档编程，再做代码编程。
如果你稍微停下来观察一下，会发现一个很有意思的现象：
有些 AI 一旦开始写代码，就会沉浸在自己的逻辑实现里，几乎完全不顾项目原有的设计。
即便你已经提出明确要求，它仍然会受限于上下文窗口和信息宽度，对整个项目缺乏完整理解。
这会带来很多维护性问题。
它不会复用已经实现的业务组件，设计数据库时会产生各种冗余，还会不断衍生新的实体和概念，让系统结构越来越复杂。
代码可以交给 AI 去写。
产品设计和架构设计，仍然需要人来把关。
每次让 AI 做大型重构或者功能改造之前，我都会先让它把需求分门别类，做好抽象和解耦。
即便如此，只要有一些地方考虑不周，AI 依然会生成大量难以维护的代码，性能逐渐下降，项目变更的复杂度也会迅速上升。🥲
18 37
