解决方案设计

原生方案（Plan A）

如果系统支持增强的验证钩子，可以在 project.md 中添加明确的步骤检查，如在每个任务后验证输出一致性。但当前系统不支持此功能，需要手动实现。

变通方案（Plan B）

设计一个包装器脚本，通过在执行前和执行后添加检查步骤来增强约束。例如，使用 shell 脚本来捕获模型输出，比较预期格式，并重新提示如果不符合。结合 skills，可以预加载验证技能，但由于 skills 不可用，建议在 project.md 中添加详细的 “安全检查” 部分，强制模型在关键步骤报告状态。

架构图

graph TD
    A[用户请求] --> B[路由选择模板]
    B --> C[执行任务]
    C --> D[验证钩子检查]
    D --> E{符合约束?}
    E -->|是| F[完成]
    E -->|否| G[重新执行或警告]
    G --> C

约束与风险

变通方案的风险在于增加复杂性，可能导致性能下降。原生方案受限于当前系统能力，难以实现强约束。

结论与建议

推荐采用变通方案，通过增强 project.md 和添加手动验证步骤来提高确定性。未来一旦 skills 可用，可集成以自动化路由和验证。