Marco Casalaina 谈评分标准时给的做法是：先做一版初始标准，跑评估，错误仍会出现；然后让真实用户看输出，但不能只说“这个不对”，要说“这个不对，原因是什么”，这个原因再写回标准，可能是改原有维度，也可能是新增一项⁠1。这正对应你说的“说了后面忘了前面”：标准不是一次讲全的，而是靠每次具体错误累积成文。

立正在另一段里讲自我迭代，道理很朴素：人犯错后记下来，下次做任务前先看这份记录，就少犯同样的错；给大模型也是把这份记录写清楚，让它每次动手前先读⁠2。他也提醒，让模型自己往规则里写会写乱、加一堆东西，性价比不高，需要人在这里多花功夫⁠2。所以更稳的是人来维护这份边界文档，模型只负责执行前读取。

这是 AI 根据上面两点对你处境的推演，不是两位说话人的原话。做法可以是：为大项目单开一份文档，分“已定边界”“判定标准”“待定争议”三栏；每次子项目产出与大项目不一致，就记下具体案例、错在哪、为什么，再决定是改旧条目还是加新条目。判断标准是否在收敛，可以看同一类争议是否还反复出现——如果反复出现，说明那条“为什么”还没写清，而不是你记性不好。

出处 1 2

你现在的循环，是每次发现偏差就口头再讲一遍，系统没记住，你又再讲一遍。可以换一种做法：把这次偏差写成一条具体规则，例如“这个子项目的产出必须包含哪几项、缺哪项算不合格”，然后只改这一条，再拿同一类任务重跑一次看是否通过。Marco Casalaina 在谈 Agent 评分标准时说，标准要提前做，因为“它实际上就是成功标准”，还要提前定义可接受的阈值；他也强调这类系统不是确定性的，会犯错，不可能每次都满分，所以要决定允许多少错误、哪类错误⁠1。这正好对应你的处境：目标不是让它“觉得自己边界不够”，而是让边界变成外部可判定的条目。

立正在一篇实践总结里说，他的流水线“已经证明了这条路能走通”，但还没证明“足够干净、足够稳定、足够可直接发布”；他把质量层描述为“可诊断，但未收口”，并说接下来的工作不该再是模糊地“继续调一调”，而要明确拆成两条后续队列，主流水线先保持边界，不再把所有智能都塞进去⁠2。这是 AI 对这段经验的转述性应用：你反复纠正却越飘越远，可能不是提示词不够，而是边界没有落在一份可修改的规则文档里。每出错一次，就补一条“错在哪、为什么、下次怎么判”，而不是重新讲一遍整体要求。

立正在另一段讨论里提到，从本机跑起来到部署交付是一道真实的鸿沟，很多人停在“localhost:3000”，没法给别人用，也就形不成正反馈⁠3。这提示一个判断方向：如果“交付不够”只是你的感觉，就永远无法收敛；把它换成可观察的检查项，比如“别人能否直接用”“缺了哪一项就算没交付”。这是 AI 基于该段做的推演，不是立正针对你项目的判断。