跳到主要内容

需求澄清 Skill 的进化

需求澄清为什么是流程性问题？​

  • 场景: 用户说“把登录页改成支持企业登录”;
  • 直接开工的代价: Agent 可能替用户决定身份提供商、回退方式、是否兼容旧用户和上线范围——这些都是用户尚未考虑过的选择;
  • 全都先问的代价: 无论任务大小都先列十几个问题，会把简单修改变成一次访谈;
  • 张力: 问得太少会导致返工，问得太多会增加打扰;
  • 结论: Skill 要表达的不是“所有任务都必须确认”，而是一条带作用域的判断路径;

初版澄清流程包含哪些判断？​

  1. 先判断任务的歧义程度、风险和返工成本;
  2. 低风险、容易撤销的小改动，说明假设后直接执行;
  3. 涉及架构、数据、权限、公开接口或大范围改动时，集中提出少量真正会改变方案的问题;
  4. 得到答案后生成短 Spec 或 Plan，列出目标、非目标、关键取舍、假设与验收标准，交给用户确认;
  5. 确认后再执行，过程中发现原 Spec 不成立时暂停并重新确认;

需要记录哪些运行证据？​

类别具体内容
任务侧任务类型、澄清问题、Spec 版本、用户修改、执行结果
交付后返工情况
负反馈“做出来的和我想象的不一样”“你问得太多了”
正反馈一次确认后顺利交付；主动修改 Spec 后减少返工；低风险任务中未被多余问题打断
  • 前提: 单独保存一句抱怨不足以触发更新，必须把反馈与具体轨迹、任务类型和结果关联起来;

最小 Skill 更新提案长什么样？​

  • 缺口一: 多个涉及认证架构的任务都在交付后才发现需要兼容旧登录方式;
  • 对应草案: 执行前确认“身份提供商、回退路径和兼容范围”;
  • 缺口二: 大量拼写修复都被 Agent 先问一轮;
  • 对应草案: 收窄高风险与高歧义的触发范围;
  • 共性: 方案都来自多条轨迹反复指向的同一个缺口，而不是单次反馈;

如何验证澄清策略是否更好？​

  • 三种策略对照: 直接执行、先提问再执行、提问后生成 Spec 并确认后执行;
  • 分层: 按任务复杂度分层比较;
  • 指标: 需求偏差率、交付后的返工次数、澄清轮数、首次有效产出时间、用户放弃率、Spec 被修改的比例、高风险操作错误率;
  • 发布门槛: 只有在减少需求偏差的同时没有显著增加打扰，并在未参与提炼的任务上通过回归，才进入灰度发布;

Skill 与 Harness 的边界在哪里？​

  • Skill 负责: 理解语境，主动提出问题，整理 Spec，说明取舍;
  • Harness 负责: 在缺少确认时否决高风险写入、直接操作 main 或绕过发布流程;
  • 不可越界: Harness 中的否决器不能替模型决定 PR 应该怎样描述，也不能代替模型选择需求方案;
  • 随着经验积累，稳定的对话轨迹还可以进一步生成 SFT 或 RL 训练数据;