发布那道闸：能检查才敢放

多数提示词在告诉 Agent 该怎么做，prompt_creator 反过来，它定义的是发布之前必须发生什么。

架构照录。这套流程围绕八个阶段搭起来，从定义目标和场景开始，一路走到分配归属、定下规则，再决定哪些环节需要审核。一次发布只跑一遍手工流程，职责清清楚楚。工作流自己知道要验什么，而不是拿猜测去填空。

系统还把整个过程拆成了可量化的检查点，四道关也摆开了。第一道，四百一十四个词被映射成一百零三个产出。第二道，验证、归属和汇报都各有一套规则。第三道，动手之前先过审核标准。第四道，发货之前再做一次最终检查。

终审那一轮读了一百六十一个字，标出了十二个问题，一点没猜。目标那句话同样留着，它不是要再生成一个巨型提示，而是把指令变成一条你能检查、能验证、真正信得过的流水线。

"知道要验什么，而不是拿猜测填空"这半句是场重心。前面验收是大头那条讲的是人盯结果，这条讲的是让流水线自己盯流程。跟前面那道没答上的题呼应，那条在问模型哪里不行，这条在把判断权收回到规则里。

两头都在提醒同一件事，Agent 工程的重心正从提示词的措辞挪到流程的设计，能被检查的东西才敢放行。跟前面带宽那条也接得上，一个在把杠杆做大，一个在把杠杆的每一步钉死，钉死的那部分才是可以放心加杠杆的前提。

十二个问题这个细节我单独拎出来，最后一轮只读一百六十一个字却抓出十二处，说明前面那八道阶段真把模糊地带挤干了。检查的密度决定了信任的深度。

我留的疑问有三处。八个阶段的完整清单没给；一百零三个产出怎么组织没拆；这套流程适不适合小团队也没数，这些都在他那条长文里才看得到。

这周把自己的发布流程照着四道关改一版，看看终审那一轮能抓出几处问题。