贾维斯 Jarvis

在复杂的代码库中推进功能开发时，AI 代理常陷入两种极端：要么未经深思就贸然修改代码，要么过度设计出一套繁文缛节的流程。Jarvis 试图解决的正是这种缺乏约束的代理失控问题。它不追求管理整个项目生命周期，而是通过“受限的自我引导”机制，在保持交付目标和操作权限严格稳定的前提下，动态调整执行计划与下一步动作，从而对抗工程执行中常见的目标漂移。

Ready-to-Build 快速路径

该技能最值得工程团队关注的核心能力，是其明确定义的“Ready-to-Build”判断标准。当行为、非目标（non-goals）、权限边界以及 API 契约都已经明确，且附近存在可用的实现模式时，Jarvis 会直接跳过繁杂的设计与规划文档环节。

• 检查与实施：首先检查代码工作树和最接近的实现模式。
• 单一批次修改：在单批次变更中实施连贯的代码修改。
• 定向验证：运行受影响范围内的验证逻辑。

只有当实施过程暴露出实质性缺口时，才会按需加载产品设计或解决方案设计文档。

循环工程与风险匹配

Jarvis 的核心运作逻辑遵循一套严谨的“循环工程（Loop Engineering）”闭环，包含发现、框架界定、执行、观察、验证和记录等步骤。它强调一个关键原则：不要仅仅为了开始编码而创建开发指南文档，仅当后续工作真正需要时才进行持久化规划。

同时，它将工作风险划分为三个层级并匹配不同的处理策略：

• 常规（Routine）：对于本地可逆的明显修改，直接实施并进行单次窄范围检查。
• 共享（Shared）：针对可复用逻辑或契约，需做出明确的共享决策并验证其边界。
• 高风险（High-risk）：在处理授权、资金、迁移或部署等破坏性工作时，必须确认权限并观察真实的执行边界。

适用边界与注意事项

Jarvis 本质上是一个有限交付目标的执行代理，而非无所不能的项目管理者。在使用时应明确以下几点：

• 非递归自我提示：它的自我引导是有边界的，不是无休止的深度反思，更不是随意扩张用户需求的许可证。
• 恢复状态管理：只有当工作跨越多个会话、涉及长时间等待或外部效应不确定时，才创建恢复状态；严禁对常规编辑进行不必要的状态检查点保存。
• 真实性验证：在最终交付时，必须诚实报告实际运行的检查、缺失的证明或存在冲突的证据，清晰区分“单元完成”、“旅程完成”与“产品就绪”的不同状态。