场景设定
以下AI 编程案例来自社区种子数据，没有采集真实用户故事；案例只模拟让生成代码符合现有工程约束中的仓库上下文筛选决策。
在“让生成代码符合现有工程约束”里，最容易被忽略的是生成结果看起来正确却无法运行，因此先要求测试失败前后的对照能够支持停止或继续的决定。
验证路径
先让产品负责人声明验收门槛，再执行仓库上下文筛选；这样静态检查与运行日志可以判断生成结果看起来正确却无法运行是输入问题还是实现问题。
验收清单：
- 用静态检查与运行日志固定“让生成代码符合现有工程约束”的当前基线。
- 请产品负责人复核测试失败前后的对照与任务边界。
- 若生成结果看起来正确却无法运行仍出现，停止扩大仓库上下文筛选的改动范围。
决策记录
验收证据：围绕“让生成代码符合现有工程约束”保存静态检查与运行日志，再用测试失败前后的对照确认恢复动作没有制造新问题。
这里不预设“把提示词当作长期工程资产”一定错误，但它必须接受静态检查与运行日志和“迁移与回退都经过预演”的双重约束。
当前结论只适用于“让生成代码符合现有工程约束”的合成边界，不能外推到所有环境。下一轮应由产品负责人比较静态检查与运行日志和测试失败前后的对照，再决定是否扩大仓库上下文筛选。
回退方案：若“迁移与回退都经过预演”没有满足，就停止自动执行并把决策交回人工审核，再由产品负责人重跑静态检查与运行日志。
想听不同做法
对“让生成代码符合现有工程约束”而言，仓库上下文筛选最值得自动化的环节是什么？哪一环必须保留人工判断？