让用户描述“收到问题后分析，重要操作交给我确认”，比让他逐个建工作空间、配工具和拼引用更接近业务。AI 可以帮助完成配置，但直接修改正在运行的团队，会把一次理解错误变成真实变更。
我把构建放在草稿中。对话提出结构变化，表单精确修改，同一份蓝图展示差异，用户确认后才进入运行配置。
蓝图表达的是可执行关系
成员有稳定标识，阶段、依赖、产出和人工决策点也进入结构。用户要求发布需要批准，蓝图里就出现实际检查点，不能只给某个成员的提示词增加提醒。
下面的结构用来说明这些关系，不包含真实凭证：
{
"draftRevision": 6,
"members": [
{"id": "developer", "role": "implementation"},
{"id": "reviewer", "role": "verification"}
],
"handoffs": [
{"from": "developer", "to": "reviewer", "artifact": "change-bundle"}
],
"actions": [{"id": "publish", "requiresApproval": true}],
"credentialSlots": [{"id": "issue-reader", "requiredScope": "read"}]
}图上的边与配置中的引用必须一致。AI 解释哪个阶段要改，实际修改也落到同一标识，不能对话里改好了、表单却仍显示另一份配置。
两种入口共用草稿与校验
对话和表单提交变更都带 draftRevision，进入相同的结构与业务检查。草稿过期就比较差异，不让旧编辑覆盖新状态。
校验包括必需字段、成员存在、依赖引用、阶段关系、凭证槽位和互斥配置。错误定位到具体路径，两种入口都能修正。允许循环时，需要迭代次数和退出条件；不支持的循环直接拒绝，不能形成无限运行。
构建助手与运行成员分开。试验、文件和聊天历史留在构建空间，只有已应用版本影响运行。当前任务何时采用新配置，由运行版本规则决定。
应用器持续核对受管对象
确认蓝图后生成带稳定 planId 的创建、更新与归档计划，记录预期运行版本。团队同一时刻只有一个有效应用者，以协调租约与条件提交保护；运行版本已变化则停止旧计划，重新比较。每个对象记录 managedBy、blueprintObjectId 和已应用摘要，同一计划的步骤按稳定标识去重。重复应用核对现状，不重复创建，也不能让两个计划互相覆盖。
只有明确属于本蓝图管理的对象可以清理。外部依赖只解除绑定或检查兼容，不能因它出现在蓝图上就删除。用户确认的是一份固定差异，草稿变化后，旧确认不能继续代表新内容。
创建成员成功、绑定工具失败，保存各步骤结果，重试从未满足部分继续。可逆步骤可补偿，不可逆动作和结果未知则保留待核对，不把整个团队删掉重建。
凭证槽位不保存秘密值
AI 可以提出需要哪类能力，草稿只保存槽位、类型和范围。用户通过受管配置补齐，执行侧按授权取用。差异预览和日志也不展示秘密，避免从另一个入口泄露。
最小验收覆盖草稿创建、人工修改、冲突、预览、应用、重复应用和故障恢复。检查重复应用不新增成员、未确认变更不影响运行、失败不误删外部资源。生成不合适就丢弃草稿，已运行版本仍保持可解释的状态，这才是这轮构建流程要交付的能力。