OpenClaw 走红背后：Agent、AI Coding 与团队协作的新问题

一方面，它因能够打通聊天工具、桌面环境与技能系统，让用户通过对话驱动电脑持续执行任务，而迅速出圈；另一方面，围绕它的争议也几乎同步出现：它到底是新一代 Agent 产品的雏形，还是又一个被过度放大的技术概念？它真的是普通用户也能上手的低门槛工具吗？当越来越多团队开始把它与 AI Coding、SPEC Driven、团队协作流程放在一起讨论时，问题也随之变得更具体了——Agent 能否真正进入研发流程？AI 写代码的边界到底在哪里？团队又该如何在效率和可控之间找到平衡？

近日 InfoQ《极客有约》X QCon 直播栏目特别邀请到 淘宝闪购高级技术专家邓立山、网易智企-CodeWave 业务中心技术负责人姜天意、平安科技高级专家工程师褚秋实 一起，在 QCon 全球软件开发大会·2026 北京站 即将召开之际，围绕 OpenClaw 的爆火、实际使用体验、能力边界、安全风险，以及 AI Coding 在团队中的落地方式展开了持续讨论。

部分精彩观点如下：

• OpenClaw 并不像许多公众号描述的那样是一个“低门槛”产品。要真正用好它，需要熟悉 JSON 配置、具备排障能力，并持续调试和优化 skill，对普通用户仍存在相当门槛。

• 在需求理解阶段通过 SPEC 将需求结构化，再通过 task 和 architecture 转化为技术设计，供架构师评审技术栈、方案和接口是否合理，之后再进入 plan 阶段逐步执行，这样可以在一定程度上保证 AI coding 在可控框架内落地。

• 未来程序员编写规范和设计架构比编写具体代码更有价值，具体实现则交给 AI 完成。

• 要想真正放飞效率，必须先打好基础；在开发过程中，不仅要完成业务功能，还要为代码库留下知识和规范。

以下内容基于直播讨论整理，经 InfoQ 删减。

邓立山：最近 OpenClaw 很火，大家第一次听到或看到 OpenClaw 的时候，第一判断是什么？

姜天意：OpenClaw 与 Manus 的出现有其相似性，这类产品并非突然涌现，而是技术能力达到某个阈值后的自然结果。以 Manus 为例，早在 2023 年，OpenAI 就已较为清晰地提出了 agent 的工具使用、memory 和 context 等关键概念；2024 年 9 月，工具使用能力逐渐成熟，MCP 随之出现；2025 年年中，大上下文窗口模型开始普及，类似 Manus 的产品才真正落地。OpenClaw 的情况类似，它赶上了大模型能力快速发展的浪潮。其核心能力之一是灵活编写 skill，通过编码持续扩展智能体能力。从技术角度看，它有效利用了 Claude Code 4.6 的长上下文能力，以及 Programmatic Tool Calling (PTC)（ https://www.anthropic.com/engineering/advanced-tool-use ）和 skill 的工具使用机制。因此，这类产品的出现并非偶然的技术突破，而是多项技术逐渐成熟后的集中呈现。

未来还会出现类似 OpenClaw 的产品，它代表的是一种“product–technology fit”趋势——当技术能力与产品形态真正契合时，这类产品就会应运而生。从产品角度看，OpenClaw 迅速走红，很大程度上是因为它满足了特定用户群体的需求：多渠道信息收集、数据分析、自动发帖的 Bot 操作，以及运维和信息聚合能力，高度契合自媒体从业者、一人公司和独立开发者的使用场景。

Desktop agent 和 Remote agent 在很多公司已有实践。例如 Anthropic 的 Cowork 较早提出了 Desktop agent 的概念，此后阿里的 QoderWork、腾讯的 Workbody，以及 Minimax 的 Minimax Desktop Agent 也均属于桌面 Agent。

OpenClaw 的创新在于抓住了一个关键痛点：将桌面 Agent 与聊天工具打通。它通过 channel 网关等机制连接不同渠道，用户只需开箱即用的配置便可快速建立通信通道，通过聊天工具驱动 Agent 执行任务。

褚秋实： 我最初是在春节期间注意到 OpenClaw 的。当时看到同事在朋友圈晒 Mac mini，称其为“养虾”，他通过 IM 聊天工具与龙虾持续对话，让它每十分钟汇报一次任务进度。我的第一感受是，这是一个面向 ToC 用户的工具，开放了 computer use 的权限，使用户可以通过聊天工具驱动电脑执行各种操作。

我最先关注的是它如何实现长时间持续执行任务，关键在于它能够持续形成长期记忆：通过不断让 AI 记录并迭代笔记，避免上下文窗口耗尽。只要电脑保持开启，任务就可以持续执行。这种工程设计值得借鉴，本质上是将前人经验与新的模型能力整合而成的集大成产品。

春节后，我们公司也开始尝试类似实践，出于合规考虑倾向通过云桌面部署。我们发现，直接让 AI 修改代码往往不够准确，且可能直接提交到分支，给代码合并和审查带来问题。因此我们换了一种方式：不让 AI 直接改代码，而是让它生成设计文档级别的修改方案。这份文档详细列出每一步代码修改，但不实际执行，同时生成可视化的 HTML 报告，将所有需要修改的代码片段整理出来，通过邮件发送给我。我打开报告后，可以逐条勾选需要采用的片段。

我们惊讶地发现，约有 60% 的代码片段可以直接使用。勾选后将其复制到 IDE 的 AI 工具或 CLI 工具中，让模型基于这些较可靠的片段继续生成完整代码，准确率非常高。

我们认为这可能会成为一种新的开发模式：在版本开始时，将整个版本需求交给 Agent，让它先生成草稿。如果项目已有较完整的规范和文档，输入业务需求后，Agent 可生成包含大量代码片段的设计方案，其中 70%—80% 可直接使用。开发人员只需筛选调整，便能快速完成开发，相当于将 AI 编程转化为更精细化的人机协作。

还有一个典型场景：我每天需要花约一小时查看研发平台上各个 CI/CD 流水线的状态和项目进展。未来或许可以让 Agent 在上班前自动整理这些信息，生成报告或提示关注点。在研发管理中，这类应用场景其实非常多。

邓立山： 现在的情况有点像 ChatGPT 刚出现时，当时有很多关于它取代各类职业的讨论，但真正使用后会发现仍存在不少问题和门槛。

褚秋实： 它的 Token 消耗其实相当大。还有一个典型的踩坑案例。我曾让 AI 通过 Chrome Use 打开浏览器，分析某个页面加载了哪些接口。但由于指令不够清晰，AI 将其理解为需要研究这些 API 的作用，随即直接调用了这些接口。其中有些是删除接口，最终把我在评论平台上的评论全部删除了。

邓立山： 外网上也有类似案例，用户让 Agent 帮自己处理工作，结果它把电脑上的所有数据都删除了。

褚秋实： 所以很多人会专门找一台旧电脑或购置一台 Mac mini 来运行这些 Agent。

姜天意： 在我们的实践中，OpenClaw 的稳定性管理非常重要。它的配置文件并不稳定，一旦重启，JSON 配置可能被自动修改甚至损坏，因此我搭建了一个大龙虾定期做探针检查并自动备份配置文件。此外，浏览器访问的稳定性也有待提升。针对 Token 消耗问题，我引入了新的记忆系统，参考字节的 OpenViking 方案，通过文件方式管理记忆，从而显著减少 Token 消耗，原本只有一个 memory.md 和一个塞满信息的 context，改造后效果明显改善。

因此，OpenClaw 并不像许多公众号描述的那样是一个低门槛产品。要真正用好它，需要熟悉 JSON 配置、具备排障能力，并持续调试和优化 skill，对普通用户仍存在相当门槛。

邓立山： 我第一次了解 OpenClaw 是看到一篇文章，称有 150 万个 agent 涌入一个由 agent 自主发起的社区，人类无法参与讨论只能旁观，这促使我进一步研究了它的技术栈和原理。它不仅自己规划流程执行任务，还能进行反思和迭代。例如当缺少某项技能时，它会主动在网上收集资料，为自己编写新的规范和技能，最终完成任务。这对编程工作也很有启发，代码完成后，可以借助这种反思模式让 AI 持续检查代码质量和测试用例并不断修正。

褚秋实： 目前还有一个问题：如何将这些能力转化为团队层面的共享记忆。现在很多使用方式仍停留在个人层面，但在团队开发项目中，成员使用 Agent 过程中积累的推理经验本应能够共享。OpenClaw 目前通过 MD 文件存储记忆，如何在企业环境中打通这些记忆，是一个值得思考的问题。

姜天意： 它的核心思想是 Programmatic Tool Calling (PTC)，用代码描述整个工作流程。遇到无法解决的问题时，它会自己生成 Python 脚本并在沙盒中运行，从而解决很多通过 MCP 或传统 tool calling 难以处理的问题。MCP 工具的注册和开发本身有一定门槛，而通过 skill 实现 Programmatic Tool Calling (PTC)，很多事情可以自动完成，甚至 MCP 调用代码本身也可以由大模型生成并执行。因此，OpenClaw 的关键在于：一个好的架构理念，加上 Claude 这样强大的编码模型。

褚秋实： 那是否意味着 coding agent、办公 agent 等都可以作为它的下层，成为细分领域的专业 agent？

姜天意： 它的架构是这样的：核心只有一个名为 Pi 的智能体，相比 Claude Code 的 Coding 智能体更为轻量，只保留记忆检索和 tool calling 等能力。在此之上搭建一个网关，接收不同渠道的请求并转发给 Pi，具体能力则全部沉淀在 skill 工具中。这种架构扩展性较强，而核心保持轻量。

褚秋实： 那还需要 Claude Code 或 Gemini CLI 吗？是用龙虾调用这些工具，还是龙虾加上好模型就可以替代这些 coding agent？

姜天意： 两种方式都可行。例如我们有一只龙虾专门负责插件开发，它将 Claude Code 作为一个 skill 注册到 Pi 上。我们发现，如果 Pi 接入强模型，不仅能生成 Python 脚本，任务拆解和理解能力也更强，相比之下部分国产模型稍弱。因此理想情况下，既需要优秀的编码模型，也需要规划能力强的模型。规划能力不足时，可以用规划能力较强的模型（如 Minimax 或 Kimi K2.5）作为 fallback，编码阶段再接入 Claude Code。

褚秋实： 以前我们用 LangChain 或 CrewAI 这样的 agent 框架搭建多 agent 或 workflow，未来这些是否也会变成 skill 被整合进 OpenClaw？

邓立山： 我认为是可以的。skill 是动态加载的，只需要用 MD 文件描述清楚，需要时便会自动检索并加载。OpenClaw 目前的运作方式也是如此：需要某项技能时，它会到 skill 市场检索并安装，然后执行相应任务。

邓立山：2026 年了，AI Coding 最大的真问题是什么？

姜天意： 核心问题在于 AI 生成代码的不稳定与不可控。主要体现在以下几个方面：一是幻觉问题，AI 对需求的理解容易出现偏差，自然语言本身具有模糊性，对人尚且如此，对 AI 歧义更多；二是生成的技术栈与团队现有技术栈不一致，很多模型在训练时主要使用国外主流技术栈（如 Next.js、Tailwind CSS），对企业内部私有框架或定制库支持较弱，强行引导也难以完全贴合团队技术体系；三是 AI 生成代码的可维护性较差。当前阶段，很多团队在大规模使用 AI coding 后，逐渐不再认真阅读 AI 写出的代码，往往只要功能达到预期便通过。但我认为更重要的是结果驱动（RDD），必须通过完善的测试用例在结果层面验证各种 case，才能真正判断 AI 生成代码的可靠性。

举个典型例子：我们曾尝试开发一个在线截图工具，按常规思路只需启动无头浏览器执行截图即可。但 AI 直接用 curl 请求调用了第三方截图 API，功能虽然实现了，却完全不是我们想要的方案。这正是 AI coding 中技术方案不可控的典型体现。SPEC driven 方法的价值就在于此：在需求理解阶段通过 SPEC 将需求结构化，再通过 design 和 architecture 转化为技术设计，供架构师评审技术栈、方案和接口是否合理，之后再进入 plan 阶段逐步执行，这样可以在一定程度上保证 AI coding 在可控框架内落地。

褚秋实：AI 的代码输出速度极快，但软件开发本质上是一个从模糊到清晰的过程，需要不断与业务方确认并持续迭代。目前最困扰我的是，AI 很难在业务功能层面遵循一套清晰的规则。在技术规范方面，我们可以结合 CI/CD 工具以及 ArchUnit、PMD 等工具，将原本存在于 Markdown 文档中的规范转化为可执行的规则；代码一旦违反，便能明确指出问题来源，AI 在修复通用问题或代码缺陷方面的自愈能力也较为有效。这样，项目的开发架构就能从无形的规范转变为工具化、可检测、可约束的体系。

但在业务功能层面就复杂得多。即使使用 Given–When–Then 的验收条件，让 AI 自行检查时也未必可靠，它往往认为自己已经按照描述完成了实现。因此，开发人员仍需进行集成测试，这一环节目前依然是比较困难的部分。

一个关键问题是：如何将“什么是正确的需求实现”转化为 AI 可验证的形式？如果采用多 Agent 模式，分别负责开发、设计和检查的 Agent 通过互相博弈发现问题，那么需求描述方式就变得至关重要，如何表达需求才能让负责检查的 AI 更容易发现问题？目前的困境在于：让单个 AI 在提示词中按照规范进行自检，它往往非常自信地认为没有违反规则；但当人指出具体问题后，它又会承认确实违反了规范，这说明当前体系很难形成真正的闭环。

邓立山： 质量问题是我们目前面临的最大挑战，主要从两方面进行约束：一是提升 AI 对需求的理解，二是规范代码生成过程。首先要确保 AI 正确理解需求，AI 本质上是基于概率推断，输入语料越准确、结构越清晰，推断结果就越可靠。

在代码生成阶段，我们结合团队研发经验制定了相应规范，要求 AI 先理解文档中的业务逻辑，再根据规范约束进行编码。质量检查则从多个维度进行：最重要的是确保代码实现与业务逻辑一致，此外还需关注可维护性、代码设计质量，以及是否存在性能隐患或安全问题，这些规范可以逐渐沉淀到整个研发体系中。

这与 OpenClaw 的启发类似，从规划、执行到反思，再到下一轮执行，形成闭环。在编码过程中，可以让一个模型生成代码，另一个模型负责审核。由于是不同模型进行检查，往往能发现更多问题，而不会陷入自认为没有问题的困境。

褚秋实： 至少要用新的会话，即独立的上下文窗口来进行检查。

姜天意： 很多传统软件工程方法在 AI 时代反而更具价值。例如 BDD 可以在需求阶段就定义测试行为，使测试尽可能前移；SPEC driven 方法也可以通过 SPEC 自动生成 TDD 测试。AI 出现之前，开发人员通常不太愿意编写测试用例；而现在，TDD、BDD 等工作可以交由 AI 完成，这对开发流程是很大的利好。

褚秋实： 不过 TDD 的核心不仅是写测试，而是设计能力，要求开发者在实现功能之前思考需求如何抽象、职责如何划分，以及如何让代码变得可测试。很多人习惯在 service 里不断堆叠逻辑，如果代码本身不可测试，再好的工具也难以发挥作用。

在 AI 时代，如果能够采用更正交化的设计方式，明确每个职责，新增功能时只需创建新的类或业务概念并在旧代码中加入一个调用点，再结合 AI 自动生成代码、TDD 测试保障以及规范化的代码规则，就能在一定程度上控制技术债务、提升整体代码质量。

邓立山： 大家都在走向规范化编码的方向。值得一提的是，据说 OpenClaw 的创作者 Peter 几乎完全借助 AI 完成了整个项目的开发，后来他表示自己基本不再阅读代码，主要关注 AI 编码过程中遵循的规范文档。未来程序员编写规范和设计架构比编写具体代码更有价值，具体实现则交给 AI 完成。

褚秋实： 过去很多系统在应用架构层面往往做得不错，但开发架构层面却缺乏重视，功能运行正常，代码结构却混乱。在这种情况下引入 AI，风险其实更大。因为大模型是直接基于代码库生成代码，如果代码库结构混乱，AI 就很难遵循统一规范，甚至连规范本身都难以制定。因此在 AI 时代，代码组织方式和结构一致性的重要性会被进一步放大。如果原本已有清晰规范，只需将其转化为 AI 可理解的形式，让 AI 与开发者共同遵守即可。但现实中很多企业存在大量历史遗留系统，结构复杂、规范不统一，推进这类改造仍具有相当难度。

姜天意： 关于如何避免需求理解偏差，我们团队使用了 EARS 规则（Easy Approach to Requirements Syntax）。这是软件工程中一种需求描述方法，最早在航空航天领域使用，能够清晰描述需求中的 when、how、where 等条件。

2025 年 Amazon Kiro 将 EARS 引入 SPEC driven 方法中。其核心思想是，无论用户提交的是口头需求还是 PRD 文档，都先通过 EARS 规则将其转化为标准化需求描述，既能帮助人类消除歧义，也能帮助 AI 更准确地理解需求。例如 PRD 中一句“登录需要验证”，通过 EARS 可以细化为：在何种情况下验证、是弹窗提示还是等待多少时间等。这样产品经理与程序员可以双向确认，AI 理解也更准确。在 SPEC driven 的实践中，使用 EARS 编写 SPEC 是非常有效的方法。

褚秋实： 我们也在尝试使用 EARS，例如用“当……发生时，系统应当……”这种结构化方式表达需求，将需求实例化并以统一格式约束需求文档。我认为，当需求文档质量提升后，代码生成和自动生成测试用例都会顺畅很多。如果只在开发后半段发力，而需求源头质量很差，整个流程都会举步维艰。

邓立山：哪些场景可以 Vibe，哪些必须先 SPEC？你们怎么定强制门槛？

姜天意：SPEC driven 是一种比较正规的 AI coding 方法。如果需求本身具有探索性，例如在尝试新想法或新产品，可以使用 Vibe Coding，Cursor、Claude Code、Trae 等工具都适合在需求不确定的情况下通过不断试错来探索方案。但如果需求已经明确，例如存在 PRD、团队技术栈有明确要求，并且需要对最终结果负责，则不建议直接使用 Vibe Coding，而应先采用 SPEC driven 或类似方法，将需求转化为 SPEC 再进行设计与开发。

即便觉得 SPEC driven 流程较为复杂，也至少应该先写一个详细的开发计划，例如在 Claude Code 的 plan mode 中或以 plan.md 的形式将开发步骤明确列出，经人工审核后再让 AI 执行。此外必须以结果为导向，既然很多开发者不愿意写测试用例，就应该让 AI 大规模生成测试用例，例如根据 SPEC 的 feature 自动生成 E2E 测试，并让 AI 在 CI/CD 流程中执行，以验证 AI coding 的结果。

褚秋实： 也可以从复杂度和精度要求两个维度来判断。高复杂度且高精度要求的生产级业务系统，如果需要长期维护，使用 Vibe Coding 风险很高，AI 时代技术债务的累积速度会被放大，这类场景更适合规范化流程。如果复杂度高但精度要求低，例如探索性原型项目或一次性的个人工具，在可控范围内使用 Vibe Coding 是合理的。

目前我们团队在实践中，很多人会用 Vibe Coding 开发内部小工具，用 Go、Python 等语言快速解决临时需求，这类场景是有价值的。

邓立山：Vibe Coding 刚出现时大家都觉得很惊艳，即便是不懂技术的人也能快速生成网站或应用。但随后也出现了很多吐槽，例如后期需要修改功能时发现代码难以维护。

如果只是开发 demo 或做技术探索，可以先用 Vibe Coding 生成初始版本，再通过 SPEC 模式让 AI 实现最终版本。对于需要长期维护的生产系统，更建议使用 SPEC Driven 方法，并在过程中制定清晰的需求分析规范、架构规范和编码规范，从而生成质量更高、可长期维护的代码。

姜天意： 团队决策者需要具备判断能力，能够根据应用规模、复杂度和风险来确定 AI 生成代码的边界，以及如何验证生成结果。否则可能出现这样的问题：过去是人类开发者制造屎山代码，现在则变成 AI 批量制造屎山代码。

褚秋实： 第一批 Vibe Coding 的受害者已经出现，他们需要招聘氛围编程代码修复师（Vibe Code Fixer）来修复这些代码，甚至被戏称为 Vibe Coding 治疗师。Vibe Coding 可以快速做出能运行的东西，但稳定性、鲁棒性、可维护性等非功能性需求往往并没有得到保障。

邓立山：说到 SPEC，就必然会落到 review 和责任。那 AI 写的代码，review 重点是什么？责任怎么落？有没有必须人类拍板的红线？

姜天意：SPEC driven 模式反而更适合多团队协作。在 PRD 编写阶段，可以先由 AI agent 生成初稿并转换为标准 SPEC 文档，但产品经理不能退出流程，需要参与 SPEC 评审，与研发一起确认模块划分是否合理，避免过度设计。架构设计阶段需要技术架构师参与，评估技术栈是否合理、模型设计是否恰当、接口是否冗余、数据库表结构是否合理，以及系统是否具备高可用策略和必要的兜底机制，架构设计充分评审后开发才可以继续推进。在 plan 阶段，一线研发需要特别关注结果的可验证性，很多 SPEC driven 工具支持从 SPEC 自动生成测试用例，因此在执行 SPEC 时一定不要省略这一步，应基于 SPEC 生成 TDD 用例并在 CI/CD pipeline 中执行。

褚秋实： 在 SPEC SDD 这些概念出现之前，我们已经做过类似实践：在工程中写大量针对具体问题的 Markdown 文档，每个文档只聚焦一个问题，说明背景、要求和目标效果；再由工程师手动将需求拆解为技术任务，写成提示词让 AI 生成代码，这样可以显著提高准确率。后来看到 OpenSpec 这类框架，才意识到它提供了一套完整流程：先提出 proposal，生成 task，执行 apply，最后归档。

归档非常重要，如果某次对话成功解决了问题，应该把这次高质量的解决方案总结成 Markdown 文档加以沉淀。这样不仅技术规范可以积累，业务模块层面的知识也可以逐渐丰富。第一次开发某个功能时可能需要大量人机协作，但当这些经验被归档后，下次开发类似功能时 AI 的准确率就会明显提高。随着规范积累到一定程度，规范驱动开发也会逐渐呈现出类似 Vibe Coding 的效率体验。

邓立山： 无论采用哪种方式，代码质量最终都需要由人来负责。AI 代码 review 的重点主要有几个方面：一是检查功能实现与原始需求是否一致；二是评估是否符合既定架构设计，保证代码的长期可维护性；三是重点关注代码质量，例如性能、安全和并发处理等。如果 AI 写错了代码，责任仍然在开发者。AI 是为我们服务的工具，人始终是代码质量的第一责任人。

邓立山：要做到可控而不是放飞，大家团队里认为最有效的 3 条护栏是什么？

姜天意： 首先是需求层面的控制，需要通过需求标准化来实现，例如将需求转化为 EARS，或通过智能体将其转换为团队标准的需求文档，保证需求质量和协作效率。其次是避免生成结果失控，关键手段是 TDD，尽量让 AI 自动生成测试用例，无论是基于 SPEC 还是基于现有代码，测试流程不能省略，至少应在 CI/CD 流程中执行。第三，不同成员使用的 AI 工具规范不统一同样会导致结果失控，因此需要制定统一的 Skills、Lint 规则、CI 规则以及 Constitution 等约束机制，保证团队产出的稳定性。

褚秋实： 如果希望开发过程保持一定的 Vibe 感，前提是先把规范体系建设好。例如将规范文档、代码标注等放在代码仓库中，并在开发过程中让 AI 持续总结每个模块，逐渐形成树状结构的知识体系，使代码库本身变得智能。我们现在还让 AI 对历史代码进行总结，例如通过 RepoMix 等方式压缩和分析仓库内容，自动生成与代码库匹配的规范，使新生成的代码至少能保持与现有代码一致的风格。要想真正放飞效率，必须先打好基础；在开发过程中，不仅要完成业务功能，还要为代码库留下知识和规范。

邓立山： 代码 CR 和 TDD 在这个过程中都非常重要。可以用 A 模型生成代码，再用 B 模型进行评审，相当于交叉检查，能发现更多问题。此外，传统研发的三板斧仍然非常重要：可监控、可灰度、可回滚，上线前做好充分监控，发布时采用小步灰度，持续观察系统状态，发现问题及时回滚。

邓立山：往后 6–12 个月大家觉得 AI Coding 最可能出现的拐点是什么？会先在什么环节发生？

姜天意： 第一是多模态能力的提升，目前无论是图像识别准确率，还是对复杂文档的理解能力，都仍有提升空间，这可能成为一个重要拐点。第二是 Context 与 Codebase 的处理方式变化。过去由于上下文窗口较小，Cursor、Windsurf 等工具通常需要先将代码向量化再通过向量搜索找到相关片段；而 Claude Code 一开始就采用了直接通过 GREP 搜索并将代码放入上下文的方式。随着上下文窗口不断扩大，这种方式可能逐渐成为主流，传统向量检索方式可能逐渐被淘汰。第三是代码生成能力在底层领域的突破，例如驱动开发、系统编程或 Rust 代码生成。如果 AI 能够在这些领域取得进展，甚至实现跨平台驱动自动适配，将对整个产业产生颠覆性影响。

褚秋实： 目前大部分应用仍然是为人设计的，前端界面中的交互细节即使有规范驱动，通过自然语言描述也可能存在偏差。但如果未来应用形态发生变化，AI 原生应用大量出现，应用可能只需要一个超级框架，功能封装为 skills，AI 既负责开发又负责调用，那么 AI Coding 用来开发 AI 原生应用，可能会成为一个爆发点。

邓立山： 从自动化角度来看，AI Coding 未来会朝着更高的自动化程度发展。类似 OpenClaw 的系统，不再局限于单个应用或 IDE 插件，而是在更高层级协调多个系统。未来有可能是这样的流程：AI 接收到需求后，直接将任务拆分给各个微服务，每个微服务自动完成本模块的分析、设计和编码，再结合反思机制，比如 TDD 和 CR 不断循环生成、检查和修复代码，接着自动完成集成测试并在发现问题时继续修复。整个研发流程将会变得更加自动化和智能化。

观众：怎么看 OpenClaw 最近被发现的裸奔安全问题？

姜天意： 这个问题没有想象中严重。OpenClaw 的网关服务中，他的控制台 console 会暴露 18789 端口。部分用户为方便部署或因云平台默认配置不当，将该端口直接暴露到公网；若配置中 bind 设置为 lan，则允许局域网访问，从而导致服务暴露。实际上，在 OpenClaw.json 中可以限制控制台 console 只允许本机访问，因此这更多是使用方式的问题。这也再次说明，它并不是一键部署就能安全运行的系统，仍需要一定技术基础。

褚秋实： 不过我认为风险仍然存在。它以我的权限操作电脑，但 AI 的行为不一定完全符合真实意图，前面提到的误删数据就是例子。未来或许需要在传统 RBAC 之外增加意图层的控制，AI 虽已获得授权，但系统还需根据其具体意图进行进一步验证，类似自动驾驶需要开启特定模式一样。

姜天意： 在我们的实践中，通常会在 tool 的 profile 配置中为不同龙虾设定不同权限：有些只能发送消息，有些只能读取文件，没有删除权限。这在一定程度上能降低风险，但仍不如完整的 RBAC 体系成熟，很多权限还需在各个系统中单独配置。

观众：小公司有没有必要自己开发龙虾这样的 Agent？还是用开源的？

姜天意： 我认为龙虾开源的 PI Agent Core 就非常好用。它的核心非常简单，大约只有一千多行代码，没有像 Claude Code 那样包含大量复杂的内部机制，主要只做两件事：Agent Loop 和 Tool Use。因此在网易内部，基于类似框架可以很快做出一个桌面 Agent。它的设计思路是做减法，弱化了复杂的 plan mode 或 MCP 支持，将重点放在工具调用上。对于大多数公司来说，没有必要重复造轮子，可以直接基于 PI Agent 进行二次开发，或者直接 Fork 龙虾项目。

褚秋实： 关键还是要看使用目的。如果只是解决自身业务问题，可以开发一些 skills，或者将基于 CrewAI、LangChain 等框架构建的 Agent 封装为 skills 供其调用；如果涉及编码任务，也可以再接入 Claude Code 或 OpenCode 等工具，让龙虾作为总控和调度系统，形成一种数字员工或人机协作模式。但如果目标是做一个类似龙虾的产品，则需要从产品设计层面重新考虑整体架构。

邓立山： 建议先部署体验一下，看看它能完成哪些任务，以及是否能解决自身业务问题。整体来说它的扩展性很强，大多数情况下只需开发适合自己的 skills，或从开源社区寻找现成组件即可。

观众：可不可以让 PM 把任务直接交给 AI，然后由 AI 监督程序员的进度，而程序员使用 Claude Code 进行开发？

褚秋实： 可以。这相当于让 AI 成为 PM 的助手，负责催进度、收作业。用龙虾很适合这个场景，例如通过定时任务，定期检查任务卡片是否有进展、是否完成移测、验收文档是否提交等。

姜天意：有的，比如 Vibe Kanban，或者 Claude Dashboard 之类。很多公司都在做类似产品。

观众：你们实践 SPEC Driven 开发多久了？团队的接受度如何？SPEC 是一次性的文档吗？如何保证它持续更新？

姜天意： 我们是在去年 9 月 Kiro 发布后开始实践的，契机是亚马逊到网易进行技术交流。SPEC driven 有一个很大的利好，就是高层管理者非常重视，并提出了 SPEC 先行的概念，即所有软件开发任务都应该从 SPEC 开始，目前网易几乎所有事业部都在尝试大规模落地这一理念。

实践形式不限于 specKit、Open SPEC 等工具，也有团队采用 BDD 思路，或者通过 plan mode 加上严格的团队流程约束来实现类似效果。推广的根本原因在于，大家发现它能解决 Vibe Coding 中不可控的问题。

据我了解，Claude Code 或 Google Gemini 这样的工具团队，也在尝试用 SPEC driven 方式开发相关工具，效果不错。

褚秋实： 这本质上是一种团队层面的规范积累。规范在项目中可以分为不同维度：项目层面的技术规范，如如何定义 API 接口、实体对象、值对象或 RPC 调用等，一旦确定最佳实践就可以长期复用；围绕具体需求展开的规范则会随每个需求变化，通常需要借助 AI 通过封装好的指令或 skills 生成一版方案，再进行人工调整。此外，还需要让 AI 持续总结每个功能模块，使整个项目逐渐形成可理解的知识体系，这样下次只需用业务语言描述功能，AI 就能准确理解。关键在于把这种思路传递给整个团队共同参与，而不是让个别人单独维护，否则既缺乏动力，也难以形成统一的开发方式。