龙虾、智能体与 Geek 的未来

今天想和大家聊的主题是：龙虾、智能体，以及 Geek 的未来。

前一阵子 OpenClaw 龙虾出圈，其实它带来的不只是一个有趣的硬件或者 demo。
它更像是一个信号：
我们理想中 Geek 的样子，正在发生变化。

Peter 在社交媒体上发布过一个很理想化的场景：开发者可以在任意环境里和智能体协作，想法随时能变成行动。

但理想和现实之间往往有差距。过去我们说写代码，默认画面是坐在桌前，打开 IDE，进入一个比较固定的工作状态。
现在这个边界正在变松。
AI 已经从办公桌渗透到了厨房。
你可以一边做饭，一边让 agent 跑任务、检查结果、继续推进工作。

这背后真正重要的不是姿势变了，而是 agent 的可达性变了。
它不再只是一个你坐到电脑前才能调用的工具，而是在越来越多场景里可以持续协作的工程伙伴。

在 AI agent 时代，Geek 的未来会是什么样，工程师又该怎样重构自己的工作方式。

身在此山中

在讨论未来之前，我们先定位当下。

有一句诗大家都很熟：“不识庐山真面目，只缘身在此山中。”
我们现在谈 AI、谈 agent，其实很容易陷在眼前的工具更新里：今天哪个模型更强，明天哪个 IDE 支持了新功能，后天哪个 harness 又出了新玩法。

但如果只盯着工具，很容易失去坐标。我们需要先回答一个问题：

今天到底站在什么阶段？

只有把当前位置判断清楚，才能推断下一阶段会发生什么，也才能决定今天的工程决策应该往哪里倾斜。

从前、当下、将来

把 AI 参与编程的过程粗略分成几个阶段

第一阶段是 Tab 补全
AI 第一次真正摸到代码，是从补全开始的。它在你写代码的动作里出现，帮你补几行、补一个函数、补一个模式。那时 AI 更像是“增强输入法”。

第二阶段是 Chatbot
这个阶段的模型能力强了很多，但协作方式是割裂的。我们在浏览器或者聊天窗口里提问，模型回答，然后再把代码复制粘贴回编辑器。它能帮忙，但工作流很断裂。

第三阶段是 AI Editor
智能体进入 IDE，开始读仓库、理解上下文，生成大段代码，甚至能做局部修改。这时候 AI 不再只是回答问题，而是参与到仓库内部的执行闭环里。

第四阶段，也就是我们正在经历的阶段，是 Code Agent。
它可以自主运行、调试、提交，处理更长时任务，需要的人类指令更少，协作跨度更大。

这四个阶段背后有一条线：人从编码主体，逐渐上移到辅助位和验收位

人开始成为瓶颈

到了当前阶段，我们开始明显体会到：

人正在逐渐成为软件开发里的瓶颈。

人类工程师当然也在持续学习、积累经验，但这个增长大体上是线性的。

模型能力和配套工具的发展则呈现出更快的跃迁。

尤其在一些关键模型和 agent 能力提升之后，很多人的体感会突然发生变化：模型在越来越多工程任务上的能力，已经超过了自己原本愿意承认的范围。

这个感知阈值很重要。当大部分工程师开始承认 AI 的能力远超自己在局部任务上的执行速度和覆盖面时，工程师的价值重心就会发生迁移。

我们不再只是问“怎样更快写代码”，而是开始问“怎样稳定交付正确结果”。开发者的工作上移到定义问题、设定边界、做取舍、做验收。实现本身仍然重要，但它不再是唯一瓶颈。

趋势汇报

这场分享不是工具横评，也不是泛泛地讲 AI 未来。它更多是一个工程体验和实践分享

为了让大家对接下来讨论的尺度有概念，我会先给一个背景。以下内容都以个人身份分享，并且只在可公开、已脱敏的范围内介绍。它的作用是给大家一个基准：这些实践不是发生在玩具项目里，而是发生在真实的大规模工程环境中。

规模背景

先看规模背景

这个实践场景里，主要实现语言是 Swift 和 Objective-C。代码规模大约 250 万行，模块数大约 650 个，文件数大约 25,000 个。

在这样的规模下，一个单独的 agent 很难稳定覆盖全局。它会遇到上下文限制、模块边界、历史决策、验证成本等一系列问题。所以我们不能只靠“把问题丢给 AI”这种朴素方式，而必须有系统化的工程方法。

接下来几页趋势数据，是为了说明这段时间开发者体验发生了什么变化。

PR 趋势

先看 PR 趋势。这里有两个维度可以并列观察。

第一个维度是 PR 数量和粒度。总体上，PR 数量保持稳定，但单个 PR 的粒度在变大。也就是说，agent 可以一次完成更完整的任务，而不是只帮你补几行代码。

第二个维度是合并时间。合并时间出现了明显缩短。原因并不只是“AI 写得快”，还包括 AI 生成的 PR 更规范，描述更完整，改动更容易被 review，也更容易进入已有的验证流程。

这个数据本身不用展开太久，它主要是为后面更有冲击力的现象做铺垫：AI 协作已经从个体尝鲜进入团队工作流。

AI 协作占比

在半年的时间里，AI 协作占比从大约 1% 增长到 50%。对于一个大型团队来说，这是一个相当不错的结果。

这个增长大概从去年 12 月开始加速，和模型能力的台阶式提升基本吻合。一开始是少数人尝鲜，后来逐渐变成团队日常。AI 不再只是几个爱折腾的人在用，而是开始进入更多人的常规工作。

但这并不意味着组织已经完成转型。恰恰相反，下一个问题马上出现：使用 AI 的人之间，差距变得非常大。

AI 使用两极分化

如果把开发者按 commit 数和 AI co-author 占比画成散点图，会看到一个很有意思的结构。

右上角是一群高产出、高 AI 使用占比的人。这些人已经进入高手飞轮：他们越用越熟，越熟越能把任务交给 agent，产出继续提高。

但图的底部还有大量蓝点，代表完全没有开始使用 AI，或者使用比例极低。也就是说，少数人全面拥抱 AI，大量人几乎零介入。差距非常显著。

这件事需要主动治理。否则 AI 带来的不是组织整体提效，而是团队内部效率断层扩大。

序章已落下

经过一系列评估和业界实践，王巍老师判断是：大方向已经相当明确，Code Agent 是理想的协作形态。

前面讲的四个阶段，可以看作人类与 AI 共同编程的序章。现在序章已经落下，地基已经打好，人类科技树在软件开发这个分叉上已经点亮。围绕 agent 的基础设施、工具链和生态正在快速发展，后续也会以这个方向继续演化。

所以接下来有两个方面。

第一，是王巍老师观察到的现象和比较有效的实践。
第二，是推进 AI 在工程团队里落地时遇到的真实阻力，以及对应的处理方式。

今天的话题

在这个过程中遇到的课题非常多，但今天只聊最重要的三个。

第一，上下文工程。核心问题是信息要喂对、喂好。

第二，团队化积累。少数高手的做法要如何推广、沉淀，变成团队资产。

第三，协作新范式。王巍老师的团队正在从“人指挥多个 agent”，走向“agent 和 agent 自协作”。

每一组都会先讲约束，再讲实践。因为工具会变，但底层约束相对更稳定。

约束一：有限的 Context vs 膨胀的任务

第一组约束是：有限的 context，面对不断膨胀的任务。

现在 SOTA 模型的上下文窗口可能是 200K、400K token，甚至有更大的宣传数字。但实际工程任务也在膨胀：多模块、多历史、多决策链、多验证路径。上下文变大，并不等于问题消失。

1M 上下文不是万灵丹。塞得越多，问题越明显。

首先是推理成本飙升。attention 的计算复杂度决定了，长上下文不是免费的。其次是 recall 下降，尤其是中间位置的信息容易被忽略。再其次是注意力涣散，输出质量变得不稳定。

所以在 agent 开发里，context 不是免费的聊天历史，而是最贵的资源之一。它更像内存：有限、紧张，需要预算和管理。

上下文出问题的常见症状

上下文出问题时，症状其实很容易识别。

比如突然跳 context compact，然后你发现这次白干了。模型压缩之后，关键决策、细节和边界丢失，后面的行为开始偏离。

又比如你反复说“这里不对，修一下”，模型却一直绕圈。它不是不努力，而是 recall 已经下降，或者关键约束在上下文里被稀释了。

再比如你开始对模型说“求求你别再动那个文件”。这通常说明边界信息丢失了，模型没有稳定记住哪些地方不能碰。

还有一种更典型：“我们不是约好了么？”架构约定、接口约定、产品约定在长上下文里被忘掉了。

这些不是偶发现象，而是上下文有限的必然结果。

上下文工程：精简注入

应对策略的第一类是精简注入：只给必要信息。

比如项目里的 AGENTS.md 不要无限膨胀。我更倾向于控制在 100 行以内，只写真正有用的领域知识和关键约束。不要把所有东西都塞进去。

更好的方式是行为式引用和渐进式披露。先告诉 agent 遇到某类问题时应该去哪里看，而不是一开始就把所有文档全部注入上下文。

辅助脚本也很重要。比如模块查找、架构速查、常见路径定位，这些工具能减少 agent 盲目搜索。工具输出也要为 agent 优化，给它结构化、短而准的信息。

还有一点很现实：选顶级模型，不要在关键任务上省钱。弱模型更容易犯错，而错误会消耗更多上下文去纠正，最后形成恶性循环。

上下文工程：控制边界

第二类策略是控制边界。

如果一个任务超过一个 context window，就必须拆。每个子任务最好能在一个上下文窗口内完成，并且明确边界、依赖和验收条件。

上下文压缩在复杂工程任务里几乎是致命的。它可以救场，但不能作为主要设计。真正可靠的做法是先拆好任务，让每段任务天然短小、边界清晰。

Sub-agent 很有用，但前提也是先拆好任务。不能指望 sub-agent 替你理解一个巨大的、模糊的目标。你要先把问题切成合适的工作单元，再让不同 agent 分工。

同时，一个任务一个 thread，避免历史污染。新的任务就开新线程，让任务描述和关键约束始终处在高注意力位置。

Context 像内存一样管理

模型注意力有一个近似 U 型分布：开头和最近的信息更强，中段更弱。

所以精简注入的意义，是把重要规则放在开头。控制边界的意义，是让上下文保持短，避免关键信息被挤到中段。新开 thread 的意义，是让任务描述始终在高注意力位。

核心不是“喂得越多越好”，而是管理信息在上下文中的位置和密度。

可以把它类比成早期移动设备的内存管理。你不能无限申请内存，也不能假设系统会帮你处理一切。你必须知道哪些信息常驻，哪些信息按需加载，哪些信息应该被隔离。

这就引出第二组问题：AI 使用的两极分化。

约束二：Agent 的天花板还是看人

第二个约束是：agent 的天花板依然由使用者决定。

同一套工具，在高手和入门者手里，效果可能天差地别。高手有丰富的 memory 和 skill，有自己的任务拆分方法、提示习惯、验证脚本、踩坑记录。他们一天可以处理十多个 issue。

入门者可能几乎没有积累，只是把一句模糊需求丢给模型。结果不好，就觉得工具不行。这样一来，差距会被拉得非常大。

这种差距甚至远超 agent 前时代。过去团队里高手和普通开发者之间可能有 2 到 3 倍差距，现在在 AI 使用效率上可能是数十倍。

但个人强不等于组织强。如果组织不治理，这会变成团队断层。

组织挑战：处理团队断层

两极分化必须在组织层面解决。

比较现实的路径通常是自下而上。少数高手会率先摸索，效率显著提升。接着团队开始形成共识：哪些 memory 值得沉淀，哪些 skill 值得共享，哪些流程可以复用。

再往后，这些实践要扩展到组织能力中。它们不应该只存在于个人电脑、个人提示词或者个人脑子里，而应该在聊天、工单、PR、文档和工具链中可见。这样才能逐步拉平 AI 格差。

所以正确路径不是一开始就制定统一标准，而是高手先跑，沉淀经验，团队复用，最后制度兜底。

释放高手，沉淀实践

在这个阶段，组织应该尊重高手判断，让他们自由编排工具链。

现在没有公认的最佳实践。过早统一标准，反而会限制探索。只要守住安全合规底线，就应该放手让核心开发者尝试不同工具和流程。

比如鼓励多 harness 并存：Claude Code、Codex、OpenCode，或者其他自建工具。充分体验它们的长短，最后再抽选最适合团队的方案。

自定义 harness 也已经变得可行。AI 让团队定制开发成本大幅下降。以前你可能不会专门为内部流程写一套工具，现在 agent 可以帮你很快搭出一个适配团队领域知识的工作台。

真正有价值的是：domain 知识乘以 agent 实践。这会成为团队最大贡献。

沉淀团队资产

接下来的问题是：高手经验困在个人脑中，怎样让 agent 也能继承？

我会把 memory 分成几层。

第一层是 project memory，所有 agent 都应该读。它包含项目级约束、架构边界、全局规范。

第二层是 module memory，面向某个模块或领域。它更聚焦，避免全项目信息污染每一次任务。

第三层是 personal memory。它来自个人实践，但应该鼓励共享。不是所有个人经验都要进公共文档，但有价值的部分应该可以流动。

Skill 则是另一种沉淀方式。可以建立内部的 skill marketplace，让开发者贡献可复用流程，再经过精选和评审，最后共享到团队 repo。

Memory 做沉淀，skill 做分享。目标是让每一次 agent 会话都站在团队肩膀上，而不是从零开始。

协作范式在变

第三组约束是协作范式的变化。

当前很多人已经在做“人指挥多个 agent”。你开几个窗口，让一个 agent 查资料，一个 agent 改代码，一个 agent 跑测试，自己在中间调度。

但这种模式里，人类注意力很快会成为瓶颈。手动编排只是过渡态。

下一阶段更重要的是 agent 和 agent 自协作。人做策略设定和异常兜底，而不是每一步都介入。

所谓 10x，可以来自一个人指挥多个 agent。但如果想让组织达到“人均 10x”，就需要 agent 自协作。直接驱动因子很简单：开发者注意力稀缺。

从 Human in the Loop 到 Agent to Agent

现状：Human in the Loop

现在大多数 agent loop 仍然是 human in the loop。

典型流程是：人启动，打开 CLI 或工具，输入提示词。然后 agent 执行，跑流程，生成 PR。最后人审核，review 改动，做最终决策。

这个流程里，起点是人，终点也是人。人既负责触发，也负责验收。

如果目标是无人值守，就要把人从 loop 中逐步移除。可以分两步：先去掉起点，再去掉终点。

去掉起点：自动触发

去掉起点相对简单，因为 CI/CD 成熟工具链已经可以直接复用。

常见触发方式有三类：webhook 事件、cron 定时任务、pipeline 级联。

比如 issue 创建后自动触发分析，CI 失败后自动触发修复任务，某个定时任务定期扫描可改进项。这些都可以复用现有基建。

真正的难点不在起点，而在终点：agent 做完之后，谁来验收？怎样判断它真的完成了？

去掉终点：自动验收

去掉终点的关键，是把验收标准前置，让 agent 能够自证完成。

以视觉验收为例，核心流程是：自动启动 simulator，按照剧本操作，可以优先使用 accessibility，必要时用 vision 兜底；执行过程中截图、录屏、收集日志；最后用 AI 做语义断言，判断结果是否符合预期。

这就是我们在探索的“视觉验证”路径。

核心原则是：先定义“怎么算做完”，再开始做。人只在异常时介入。

从这里开始，就进入更具体的实践：新时代的 BDD 应该怎样落地。

新时代的 BDD

从“道”进入“术”，第一件事是：每个任务必须有 spec。

如果希望无人值守 loop 能跑起来，就必须配备完整文档。这里的 spec 形态可以因任务而异。

如果是 PR review，spec 可以是 PR description。
如果是 feature，spec 可以是确认后的 wiki。
如果是 bug fix，spec 可以是 QA ticket 的复现步骤。
如果是 CI failure，spec 可以是 CI 错误日志。

重点不是形式统一，而是先有 spec。Agent 按 spec 执行，也按 spec 验收。这可以理解为新时代的 BDD。

验收前置

验收前置的本质是先定义“怎么算做完”。

事后生成测试通常没有意义。AI 很容易只是把实现翻译成测试，这并不能验证行为。对人来说，这种测试也很难验收，因为你不知道它是在证明需求，还是在复述实现。

BDD 天然贴近自然语言，而 LLM 做自然语言到自然语言的转换几乎无损。所以更好的路径是：根据 spec 生成 spec test。人 review 的对象从代码变成 spec，成本会大幅下降。

这会推导出开发者的新任务：把 idea 翻译成可自动化测试的案例。

验收自动化

评估剧本

端到端验收是整个 loop 中最重的一环。

一个可行做法是写“评估剧本”。它可以是自然语言 UI 测试，由 action 和 eval 交替组成。

Action 表示用户操作，比如点击某个入口、输入某段文本、滚动列表。Eval 表示预期结果断言，比如页面应该出现某个状态，某个按钮应该可点击，某个流程不应该卡死。

这种自然语言写的 UI 测试，人和 AI 都能理解。它是 BDD 在 E2E 场景里的自然延伸。

执行与验收

从评估剧本到全自动验收，可以形成一条管线。

首先是剧本，然后 compile，把自然语言转换为结构化 tool calls。接着进入 runner loop，在 operate 和 evaluate 之间循环。执行操作，观察状态，判断是否满足预期，必要时继续下一步。

剧本编译可以由 LLM 完成，把自然语言转成结构化调用。Simulator 操作由 runtime 编排，按照 tool call 执行。能用 accessibility 就优先用 accessibility，必要时用 vision LLM 兜底。

执行完成后，要收集证据，交给断言框架。评估框架可以结合确定性断言和 AI 语义断言，并保留截图、日志作为证据。

这样，agent 不只是“说自己做完了”，而是能拿出可审计的验收材料。

闭环：Agent to Agent

把前面的内容串起来，就得到一个新的闭环。

初始状态是：人启动，agent 执行，人审核。

下一步，起点变成 trigger，终点变成 agent 自行验收，全链路都由 agent 驱动。验收不通过时，可以自动触发下一轮修复。每一轮都是独立 context，避免历史污染。

人的角色变成“定规矩”：一次性定好 spec 和验收标准。完成之后，再把有价值的经验沉淀成 memory 和 skill。

这就是从 human in the loop 走向 agent to agent 的核心路径。

NavigationStack 假死排障

起点

接下来用一个实际案例说明：SwiftUI NavigationStack 假死排障。

我们收到一个 ticket：iOS 18 下，多层跳转之后 UI 可能假死。这个问题不是一句“修一下”就能交给 agent 的，它需要复现、定位、验证。

第一步，把 ticket 喂给 LLM，让它输出结构化排障剧本，包括复现路径和验收条件。

第二步，人 review 这个 spec。比如补充已知信息：iOS 26 下正常；修正一些错误方向；明确验收条件是 UI 可交互、未假死。

到这里，人的工作基本结束。后面交给 agent loop 执行。这个 spec 剧本由 action 和 eval 交替组成，agent 需要按剧本复现、排查、修复，并用验收条件证明结果。

执行

Agent 接手 spec 之后，自主排障。整体过程有点像二分法。

第一轮，它假设问题和 ViewModel 创建时机有关。实验之后仍然假死，于是排除这个方向。

第二轮，它假设 NavigationPath 状态冲突。结果部分改善，说明方向接近，但还不是根因。

第三轮，它继续缩小范围，构建了一个最小复现工程，只需要三个文件就能稳定复现问题。

第四轮，它定位到根因：model 链路断裂。修复之后，验收通过。

最后产出包括方案提交、写入 memory、最小复现归档。这个过程的重点不是“AI 修了一个 bug”，而是排障流程被标准化，并且可复用。

还有什么在变？

除了前面三组核心话题，还有一些工程实践也在变化

有些旧观点在弱化

• DRY 的边际价值下降。

过去我们非常强调消除重复，但在 agent 时代，局部重复有时可以换来更强的可理解性和更低的上下文耦合。

• 语言专精也在被拉平
• review 形态在变化
• 调试风格也在变化

也有一些既有实践变得更重要。

• 知识共享更透明
• 架构杠杆被放大
• 系统需要支持自主改善
• 代码和文档都要更多考虑“为 agent 而写”

所以不是“少做工程”，而是“重排工程优先级”

建设建议

Stage 1：早期建设

如果团队或个人刚起步，王巍老师给出了几个建议。

1. 挑靠谱的模型商。API 要稳定，上下文要够大，合规要求要满足。
2. 大量消耗 token。早期不要过度限制使用量，而是设预算、做 A/B 对比、试探边界。你需要知道模型能做什么，不能做什么，在哪些任务上稳定，在哪些任务上不稳定。
3. 迁移工作流。不要一开始就挑战最复杂的任务，可以从重复性工作入手，先辅助，再逐渐主导。
4. 不要过度纠结工具选型。工具会变，思维模式才是核心。你真正要学的是如何定义任务、控制上下文、前置验收、沉淀经验。

Stage 2：中期建设

如果团队已经有了一些实践，希望系统化提升，可以进入中期建设。

1. 建立 harness 评测。为自己的团队和业务场景建立 benchmark，形成“评测、调优、再评测”的闭环。
2. 沉淀经验。把高手 workflow 共享化，建立案例库，逐步缩小团队内部 AI 使用格差。
3. 推进验收自动化。先从核心路径开始写评估剧本，再逐步扩大自主验收范围。
4. 建设 agent-friendly 基础设施。文档要结构化，工具要 CLI 或 API 化，日志和验证结果要让 agent 容易读取和判断。

收束

最后收束成几句话。

1. 把问题讲清楚。定义、约束、验收，是 agent 时代工程师最重要的输入能力。
2. 把系统搭到 agent 能发挥。上下文、可观测性、自动化验证、工具接口，这些都是 agent 能否稳定工作的基础设施。
3. 把成功路径变成团队资产。Memory、skill、模板、案例库，都是把一次成功转成长期复利的方法。

软件开发和产品设计会持续从 to-human 走向 to-agent。过去我们主要为人设计界面和流程，未来越来越多流程也要为 agent 设计。

Memory 和 skill 的构建，本质上也是一种渐进式披露：不要一次把所有东西塞给模型，而是让系统在正确时机暴露正确知识。

如果明天就要做一个最小落地，我会建议从一件事开始：建立一个模板，加上一条可验证循环。让 agent 做一个明确任务，按明确标准验收，再把过程沉淀下来。