用豆包做“反例改写”：把一段含糊要求改得可判定

“写得简洁一点”“分析得深入些”“别太机械”——这类要求人能懂，程序没法执行，模型也只能靠猜。我用一个固定动作处理：让豆包做反例改写，把含糊要求翻成一组能通过/不通过的判据。

提示词

下面是一段写作/输出要求：「<原话>」。

请改写为一组可判定的规则，并输出三部分：

1. 规则清单：每条必须能回答“符合 / 不符合”，不要出现“尽量”“适当”“较好”这类词；

2. 合格示例一条、不合格示例两条，每个示例后用一句话说明违反了哪条规则；

3. 仍无法判定的部分：原要求里有哪些词无法转成规则，建议我补充什么信息。

第 2 部分的反例比正例重要。人对“不合格”往往更敏感，两条反例一摆，边界立刻清楚。第 3 部分则负责兜住那些真的说不清的词——比如“有温度”，往往得先问清楚是对谁、什么场景。

一次实际改写

原话：“摘要别写太长，要抓重点，别堆形容词。”

改出来的规则是：不超过三句；每句含一个来自原文的事实；不出现评价性形容词；不出现“本文介绍了”这类开场。再看两条反例，一条是超了字数，一条是把“重要的”当成事实写进去。

改写完之后，这几条就能直接放进输出契约里。判据能机械判定，后续校验才有意义。设计这类规则时，BackendWiki 把参数与取值列成表的方式 很适合当参照；而要把规则固定成可重复执行的流程，可以看 WorkBuddy 官方文档 的编排说明。

两个边界

别让它替你决定标准。 它负责把“简洁”翻成“不超过三句”，但三句是不是合适，取决于你的场景。

一次只改写一条要求。 一整段一起改，出来的规则会互相打架，逐条来更稳。

小结

含糊要求不是表达问题，是缺少判据。用豆包做一轮反例改写，把形容词换成能通过/不通过的规则，输出质量就不再是碰运气，而是可以核对的事。