# 从目标到验收的判断路径

以下是整理者从多段工程讨论中归纳的思考框架，不是本人制定或命名的方法论。它最适合辅助分析 AI 编程和软件工程问题。

## 01 · 先明确做什么，以及什么不能变

“重构一下”“做得更好”“让它自动完成”，都还不足以形成稳定的交付标准。先明确目标、兼容要求、允许改变的范围，再区分功能正确与设计质量。

如果目标本身带有矛盾，换更强的模型可能只是让它更努力地完成一个扭曲的方案。

## 02 · 把正确性变成可以执行的约束

能够由编译器、测试或 CI 判断的条件，就让工具来判断。用自然语言反复叮嘱，不能替代能真正阻止错误交付的机制。

这里有一个重要前提：验证本身要有效。充分的既有测试，与实现完成后才随手补出的自证式测试，不具有相同的证明力。

## 03 · 找到问题实际发生在哪一层

遇到 AI 做不好的任务，不急着归结为一句“模型不行”。可以先区分：

- 需求和验收条件有没有讲清楚？
- 模型有没有读到必要的项目知识？
- 构建、调试、测试等工具是否真正可用？
- 模块和接口是否要求它同时记住过多关联？
- 在这些条件具备后，是否仍碰到模型能力边界？

这个拆分是分析顺序，不表示模型永远没有责任。能力不足与基础设施不足都可能真实存在。

## 04 · 看实现是否在绕路

测试全绿以后，仍要关注不必要的结构、重复逻辑、反常的调用关系，以及为了满足要求而不断加上的适配层。

这类信号可能意味着 AI 没理解设计，也可能意味着原来的架构无法自然承载新需求。处理办法不一定是继续补 prompt；有时应回头修设计，再重新实现。

## 05 · 把人放在高价值判断的位置

让自动化承担可重复检查，让人关注目标、边界、验收与设计异常。持续理解代码库有助于降低每次 review 的成本；长期完全脱离以后再回来看，判断成本可能更高。

## 如何实际使用

拿一个具体方案，依次写下目标、约束、验证方法、模块边界和未解决的问题。然后请 AI 用这条路径挑出最薄弱的一环，而不是要求它机械地为所有任务增设同样多的流程。

对于低风险的一次性工作，这套分析也应缩小到合适的程度。