评估这个项目是否能帮助 AI Agent 在遗留项目中少写错业务逻辑。
第一版评估不追求统计显著性，而是追求尽快发现方向是否值得继续。
对每个任务进行对照：
A 组：普通 AI Agent 直接根据任务修改代码。
B 组：先生成业务逻辑护栏，再让 AI Agent 修改代码。
为了减少偶然性，建议至少选择 3 个任务，最好覆盖不同类型的业务风险。
优先选择这些任务：
- 真实维护中出现过，或很可能出现。
- 涉及业务条件、状态流转、金额计算、权限、配置或特殊客户逻辑。
- 不是纯样式、纯重命名、纯依赖升级。
- 熟悉项目的人能判断结果对错。
- 任务范围可控，能在一次 agent 会话中完成。
不适合作为第一批评估任务：
- 需要大规模架构改造的任务。
- 没有人知道正确业务行为的任务。
- 只能靠线上数据验证的任务。
- 测试环境完全不可用且无法人工判断的任务。
检查 agent 是否识别并保留关键业务规则，是否正确处理特殊分支、历史约束、状态判断和框架行为。
评分建议：
- 0：遗漏核心规则，结果不可用。
- 1：识别部分规则，但漏掉重要例外。
- 2：覆盖主要规则，少量边界不清楚。
- 3：覆盖关键规则和主要例外，并标注不确定点。
检查 agent 是否完成任务明确要求的工程产物，而不是只让主流程看起来可用。
评分建议：
- 0：缺少关键产物，例如任务要求的 API、model/type、入口改造或验证说明。
- 1：产物部分完成，但存在明显结构缺口，例如 API 全部使用
any、缺少模型文件、旧实现处理不清。 - 2：主要产物完整，少量类型、清理或说明仍需补充。
- 3：产物完整，类型、边界、旧实现处理和验证说明都符合任务要求。
重点检查：
- 是否满足 Task Guardrail Pack 中的“必须产物”。
- 是否维护模块私有 model/type，或说明为何不需要。
- API 方法是否避免全部使用
any。 - 是否正确处理新旧框架返回结构。
- 旧实现删除或保留是否有引用检查依据。
检查 agent 是否选择了合理、局部、低风险的修改路径。
评分建议：
- 0：大范围乱改。
- 1：改动能工作但范围偏大。
- 2：改动基本聚焦。
- 3：改动入口准确，避免无关重构。
检查 agent 是否提供足够测试或人工验证场景。
评分建议：
- 0：没有有效验证。
- 1：只覆盖 happy path。
- 2：覆盖主要路径。
- 3：覆盖关键旧规则、例外和回归风险。
有效验证可以包括自动测试、类型检查、引用检查、构建检查、人工走查说明或熟悉业务的人确认。不能只写“看起来没问题”。
由熟悉项目的人判断 agent 的解释和改动是否可信。
评分建议：
- 0：明显误解业务。
- 1：需要大量人工纠偏。
- 2：整体可信，但仍需人工补充。
- 3：能准确说明依据、风险和验证方式。
记录 agent 完成任务所花的时间、对话轮次、上下文规模或 token 消耗。
评分建议：
- 0：成本显著更高，且没有换来质量提升。
- 1：成本更高，但带来一定质量提升。
- 2：成本接近基线，质量有所提升。
- 3：成本接近或低于基线，且质量明显提升。
时间和 token 成本是次级指标。若业务正确性或工程完整性下降，即使成本降低，也不能判定为成功。
每个实验至少记录：
- 任务名称。
- 任务类型。
- Baseline 的结果。
- Guardrail 的结果。
- 两组是否都完成修改。
- 两组是否遗漏关键业务规则。
- 两组是否满足必须产物。
- 两组是否存在类型或 model 缺口。
- 两组是否正确处理框架返回结构。
- 两组是否误改公共 API、公共模型、全局配置或非目标模块。
- 两组是否删除或保留旧实现，以及引用检查依据。
- 两组修改文件数量。
- 两组测试或验证方式。
- 人工评分。
- 生成护栏所花时间。
- 护栏是否包含错误或过期信息。
token 消耗可以记录，但不作为第一优先指标。
如果 Guardrail 组在 3 个任务中至少 2 个任务明显减少业务遗漏，MVP 方向暂定有效。
如果 Guardrail 组没有减少业务遗漏，但显著提升了工程完整性、验证证据或方案可信度，方向可以保留，但需要重新设计护栏内容。
如果 Guardrail 组引入了错误上下文，导致 agent 更自信地写错代码，方向必须收缩，优先解决来源引用和不确定性标注。
如果 Guardrail 组业务行为更正确，但缺少任务明确要求的工程产物，应判定为“部分有效但不合格”。这类结果说明护栏对业务理解有帮助，但必须把产物、类型和审查要求写成硬约束。
如果 Guardrail 组减少了 token 或时间，但业务正确性、工程完整性或修改范围控制下降，应判定为失败。当前 MVP 不以成本下降作为第一成功标准。