Jev创始人谈AI融入软件的方向

导读： Jev 创始人 Diogo Almeida 说“下一个时代并不是 Claude Code 时代”。他的重点不是否定编程智能体，而是提出另一种软件形态：智能成为开发者随手调用的能力，由软件在合适的时机使用。方向很诱人，但真正难的，是让每一次调用都有边界、有依据、能验收。

每天打开「Claude Code」，描述任务，等它读文件、改代码、跑测试。这个流程已经很强，却仍有一个默认前提：人先意识到需要 AI，再主动找它帮忙。

Diogo Almeida 在「AI Engineer」大会上讨论的，正是这个前提。他认为，下一步应让智能可靠地融入软件，让用户不必始终意识到 AI 的存在。后续访谈及逐字稿[1]中，他又用数据库和正则表达式作类比，说明开发者应能更自然地调用智能能力。

我觉得这个判断值得认真拆开。因为从“人打开 AI 工具”走到“软件按需调用 AI”，变化的不只是入口位置，而是谁负责触发、约束和检验模型的判断。

01 “Claude Code 之后”，究竟是什么意思

Almeida 曾参与「OpenAI」的「InstructGPT」工作，如今是「TypeSafe」首席执行官及「Jev」创始人。他谈“下一个时代并不是 Claude Code 时代”，讨论的是 AI 融入软件的方向，而不是宣布现有工具失去价值。访谈及逐字稿[2]提供了理解这一观点的语境。

「Claude Code」这类工具的交互中心仍是人：人提出目标，智能体围绕目标读取上下文、调用工具、交付结果。哪怕任务能持续多轮，起点通常还是一次明确的人工委托。

把「Codex」放进同一类产品形态作比较，我认为有分析价值。但这里必须划清事实边界：给定材料确认的大会演讲观点直接涉及「Claude Code」，不能写成 Almeida 在演讲中同时点名批评了 Codex。

这也不是“聊天框该不该存在”的争论。写新功能、处理陌生故障、审查一项复杂改动，人需要明确提出目标，也需要理解过程。主动调用智能体，在这些任务里很合理。

另一类问题却可能早已嵌在软件流程中：一条记录该分到哪个类别，一份材料里哪些判断缺少证据，一次决策是否需要升级人工复核。如果用户每遇到一条记录都要另开对话、复制上下文，软件其实把本该由流程承担的工作推回给了人。

核心区别是： AI 是等人来找的独立助手，还是在已有软件流程中承担一个边界清楚的判断环节？

02 像调用数据库一样调用智能，类比到哪里为止

数据库之所以好用，不是因为开发者“相信数据库很聪明”。开发者知道查询在哪里发起、输入是什么、结果怎样进入后续程序，也能在失败时看到错误。

正则表达式也类似。它可能写错，但至少有确定的输入、规则和输出。Almeida 在访谈里借这两者作类比，指向的是智能能力应当更容易被软件调用；这个类比不等于「Jev」已经具备数据库或正则表达式那样的确定性。来源：Latent Space 访谈及逐字稿[3]

模型擅长处理规则难以完整枚举的内容，比如从自然语言里识别意图、判断一段文本属于哪个业务类别、找出材料中的潜在矛盾。但“能够给出判断”和“这个判断可直接驱动业务”，中间隔着一整套工程问题。

先看输入。软件必须知道模型看到了哪版数据，是否缺少关键字段，引用的外部材料是否过期。输入不完整，再流畅的输出也可能只是把错误包装得更像答案。

再看输出。一个供人阅读的段落，可以保留模糊措辞；一个进入业务流程的结果，则需要明确类别、依据和异常状态。模型说“可能有风险”，程序接下来到底该阻断、提示，还是继续？

所以我理解的“随手调用”，不是在每个按钮后面塞一个模型请求。它要求软件把智能判断变成可检查、可拒绝、可回退的组件。做到这一步，用户才可能不必时时盯着 AI；做不到，隐藏入口只会隐藏问题。

03 真正接住模型的，是 Harness 工程

我之前写过《我让 DeepSeek Harness 当了回包工头》。那个可复现实验里，「Codex」完成后端、「Claude Code」完成前端，两边都显示「DONE」，联调却因 user_id 与 userId 不一致失败。

模型各自完成任务，不等于整体功能可以交付。管理端还得回收结果、检查接口契约、统一运行测试；失败时重新派发修复任务，通过后才算「ACCEPTED」。这个例子说明，完成条件不能只由执行者自己宣布。

把这套思路放到软件内嵌 AI，问题会更尖锐。用户没有主动打开智能体时，谁决定此刻该调用模型？调用前，谁限定它能读哪些数据、能写哪些字段？结果返回后，谁验证它符合业务约束？

这些职责属于「Harness」：它负责组织模型、工具、权限、状态和验收。具体实现可以不同，但责任不能因为入口藏进软件就消失。相反，调用越自然，运行时越要说得清每一步发生了什么。

本号资料库里对「DeepSeek Harness」的描述，也强调模型 Provider、权限边界、工具、插件和会话存储的组织方式。这是一个工程取向的例子，不能据此推断「Jev」采用相同架构，更不能推断某种架构已经解决了内嵌智能的可靠性问题。

我看这条路线时，最关心的不是模型能否再多答几类问题，而是产品团队能否把触发、执行、核验和异常处理接成闭环。缺了其中任何一段，“AI 融入软件”就容易停在演示页面。

04 放到金融场景，先问判断会造成什么后果

拿研报里的置信分析举例。软件可以尝试识别一句结论依赖了哪些材料、哪些证据没有出现在正文、哪些判断需要分析师复核。这是适合探索内嵌智能的环节：它能在阅读流程中提示问题，最终解释权仍留给人。

但“置信”不能只是一枚看起来精确的分数。若系统说某项结论可信，就应能让使用者追到依据、输入版本和判断范围。否则，数字越整齐，越容易让人忽略它其实没有解决证据问题。

数据分类与清洗也有类似机会。软件可以在导入数据时提示字段含义可能不一致、同一实体存在不同写法，或者一条记录需要人工确认。分类建议可以批量产生，批量改写原始数据则需要更严的验收和回退机制。

量化交易的边界更硬。模型可以参与研究辅助、异常解释或候选信号整理；一旦输出要进入下单链路，就不能把一段自然语言判断当作足够的执行依据。策略约束、数据口径、权限和人工负责的环节，必须先由系统设计清楚。

这三个例子只是产品设计推演，不是对「Jev」现有功能或收益的描述。它们共同指向一个问题：同样是“调用智能”，给分析师一条可审阅的提醒，与让系统据此改变数据或触发交易，要求的可靠性根本不同。

05 三道产品关：触发、可靠性、控制权

第一道关是触发时机。软件不能只因为模型“也许能帮忙”就随处插入判断。更好的起点，是寻找已有流程中反复出现、输入相对明确、输出用途也明确的节点：例如导入后的分类建议、提交前的材料检查。

第二道关是可靠性。不是笼统问模型“准不准”，而是问这次结果能否被业务验证。分类可以抽样复核，结构化字段可以检查取值范围，代码改动可以跑测试；无法验证的开放判断，就应降低自动化程度。

第三道关是用户控制权。提示可以由软件自动给出，修改可以等待用户确认，涉及不可逆后果的执行更需要清楚的授权边界。入口越隐形，用户越需要知道系统何时作过判断、依据是什么，以及如何纠正它。

我之前写《Agent越权，权限边界该设在哪里？》，关心的就是类似的问题：模型提出一个操作，不代表工具层应当放行。把 AI 做成基础能力，只会让这层边界更加日常，而不会让它变得多余。

让用户不必始终意识到 AI，不等于让用户失去知情和否决的机会。 好的产品应把低风险、可验证的判断做得顺手；在需要人承担责任的地方，把控制权明确交还给人。

06 开发者该怎么判断：内置，还是明确发起

我会先问四个问题：任务是否高频？输入是否能由软件直接取得？输出能否被检查？判断出错后，能否及时发现并撤回？四个答案越清楚，越适合考虑把智能嵌进流程。

例如数据导入时给出分类建议，通常有固定入口，也能保留原值供人对照。研报提交前提示缺失依据，可以直接服务于审阅。它们的共同点是：模型帮助人更快发现问题，软件仍能展示发生了什么。

相反，目标开放、需要跨多个系统取舍，或结果一旦执行就难以撤销的任务，仍适合让用户明确发起。用户要说清目标、审阅计划，并在关键节点核验。主动使用「Claude Code」或「Codex」，在这类任务里不是落后的交互方式。

这也呼应我之前写《从「对话式」到「目标式」》时坚持的一点：目标要有可验证的完成条件。无论智能来自一个显眼的 Agent，还是藏在业务软件内部，最终都要回答“怎样才算完成”。

Almeida 给出的是一个值得追的方向，不是已经得到验证的行业结论。开发者真正要做的，也不是争论 AI 该不该“消失”，而是逐个流程判断：哪些智能判断值得内置，哪些必须让用户主动委托，哪些暂时就该留给人。

结语：软件按需调用 AI，想象空间很大；决定它能否进入日常工作的，却是触发条件、Harness 的约束与验收，以及用户手里的控制权。把这几件事做好，“随手调用”才会从一句产品口号变成可信的工程能力。

💬 互动话题：你正在做的产品里，哪一步最适合内置智能判断？哪一步你一定会坚持让用户亲自确认？

如果觉得有价值，欢迎「点赞」「在看」「转发」三连 ↓

参考来源：

• Codex和Claude Code都跑偏了，前OpenAI研究员称Jev出现前AI世界是个悲剧[4]（华尔街见闻 最热）

• Codex和Claude Code都跑偏了，前OpenAI研究员称Jev出现前AI世界是个悲剧[5]（36氪 人气榜）

参考链接

[1] 访谈及逐字稿：https://www.latent.space/p/jev

[2] 访谈及逐字稿：https://www.latent.space/p/jev

[3] 来源：Latent Space 访谈及逐字稿：https://www.latent.space/p/jev

[4] Codex和Claude Code都跑偏了，前OpenAI研究员称Jev出现前AI世界是个悲剧：https://wallstreetcn.com/articles/3782531

[5] Codex和Claude Code都跑偏了，前OpenAI研究员称Jev出现前AI世界是个悲剧：https://www.36kr.com/p/3998248835551367