谷歌内部新项目：让AI自己定KPI写代码

谷歌正在测试一种完全不同的AI编程方式：开发者不再逐条下指令，而是直接甩一个目标过去——比如"把内存泄漏降低20%"，然后等结果。

这个叫Jitro的内部项目，核心赌注只有一个：AI能不能从"执行工具"变成"结果负责人"。

从Jules到Jitro：同一条产品线的两次迭代

Jitro并非凭空出现。它建立在Jules的基础上——谷歌现有的异步编程代理，但架构上有本质区别。

Jules V1的操作模式和你熟悉的工具没两样：你写提示，AI执行，你检查，再写下一个提示。开发者同时兼任项目经理、调度员和质检员。AI很快，但始终是被动的。

Jitro试图打破这个循环。泄露的工具定义显示，它的工作空间API暴露了几项关键操作：列出目标、在协助清晰表述后创建目标、列出洞察、获取洞察的更新历史、列出已配置的工具集成（包括MCP远程服务器和API连接）。

最后一项尤其关键。MCP（模型上下文协议）远程服务器和各种API连接意味着Jitro会主动确保自己拥有所需的上下文，而不是等开发者喂给它。

工作空间模型：持久协作而非一次性交易

Jitro的专用工作空间设计，暗示谷歌把它视为一个长期合作者，而非用完即走的工具。

早期信号指向一个三层结构：目标列表、洞察追踪、工具集成配置。这种连续性是当前编程代理普遍缺失的。

你在工作空间里设定目标后，AI不会默默干活。它会暴露推理过程——解释为什么选这个库、为什么重构那张表。你批准大方向，它处理执行。

透明是设计内置的，不是事后补丁。

谁需要这种工具？

Jitro真正发挥价值的场景，恰恰是现有工具最痛苦的领域。

降低错误率成为目标本身，而非调试单个函数；提升测试覆盖率成为指标，而非手动跨文件写用例；提高转化率成为优先级，而非无策略地调整孤立页面元素。

这些任务的共同特征：重要性高，但拆解成可执行步骤的过程极其消耗认知资源。

当前主流工具（GitHub Copilot、Cursor、Windsurf、OpenAI Codex）都要求开发者完成这个拆解。Jitro的赌注是，AI可以自主识别代码库中需要改变什么、以推动指标向正确方向移动。

产品逻辑：为什么是现在？

谷歌这一步并非技术炫耀。它回应了一个真实的用户疲劳：提示工程正在成为新的技术债务。

开发者花越来越多时间管理AI——设计提示链、验证中间输出、修复上下文断裂。当AI能力越强，这种管理开销反而越显眼。

Jitro的KPI驱动模式，本质是把"如何达成"的决策权部分让渡给AI，换取开发者的注意力解放。这不是自动化程度的线性提升，是交互范式的切换。

风险同样明显。目标设定本身成为关键技能——模糊的目标（"让代码更好"）会导致AI在错误方向自主迭代。工作空间的透明度设计，某种程度上是在缓解这种失控焦虑。

对行业的实际影响

如果Jitro的内部测试转化为公开产品，它可能重塑两个竞争维度。

第一，评估标准。当前编程代理比的是代码生成速度、上下文窗口、多语言支持。Jitro引入的新维度是：目标-结果对齐度——AI能否准确理解业务指标，并自主规划技术路径。

第二，用户分层。提示驱动模式对技术用户友好，KPI驱动模式可能降低非技术管理者的使用门槛。但反过来，技术用户可能反感失去对执行细节的控制。

谷歌的选择暗示了它的判断：企业级市场的决策者（而非一线开发者）才是付费意愿更强的群体。

你可以关注什么

Jitro目前仍是内部项目，公开信息有限。但几个信号值得追踪：MCP生态的成熟度——它决定了AI能接入多少外部上下文；谷歌是否会把工作空间模型开放给第三方工具；以及最关键的——实际场景中，AI自主设定的技术路径与人类专家的方案差异有多大。

如果差异小到可以忽略，提示工程确实会贬值。如果差异显著，透明度设计能否让开发者足够信任地放手，将成为产品成败的分水岭。