 ThearchyHelios
|
9f0e453884
|
整篇包在 ``markdown 里、中间再套一段一样长的 ``sql 时照样去掉外层围栏：带信息串的一行开、不带的一行收，两两配对。以前一样长的内层围栏一律不去，模型最常见的这种写法仍是 0 句结论，裁判和反方审稿没有句子可审，正式运行照样出具
规则：中间和外层同种符号的围栏行，比外层短的跳过，比外层长的不去（规格原文），一样长的按配对看——带信息串的开一个代码块，不带的收掉它；没有可收的 ``` 说明外层在这里就收了（好几个代码块），开着时又来一个 ```sql、扫到最后还开着的，都不去。去掉外层后 compose_doc 和前端每见到一行 ``` 开合一次，配好的一对正好切成一个代码块，原 docstring「见到 ``` 就收」的理由不成立，改准确了。
一样长的行只认 compose_doc 和前端认得的写法（信息串是紧跟着的一个词）：``` sql 这种它们不认，算一行正文。不然它会和后面的 ``` 配成一对、去掉外层，而后面那个 ``` 在它们眼里成了开头，把结论句吞进代码块。比外层长的照旧按行首判，````sql title 这样的也不去。
外层反引号里套 ~~~、四个以上反引号的代码块照常去掉外层：compose_doc 和前端只认 ``` 围栏，这段按正文核对，和模型不包外层、直接这么写时一样，比整篇一个代码块强；docstring 写明，测试钉住。
测试：same-fence-inside 挪到去的一边，补多段内层代码块、~~~ 里套 ~~~、反引号里套 ~~~；不去的补没有可收的 ```、开着时又来 ```python、内层没收、``` sql 开头、更长的带词围栏。compose_doc 一级补 ```markdown 套 ```sql（SQL 仍是代码块，结论句 2 句）和 ~~~ 块按正文核对。端到端（正式运行，裁判 + 反方审稿 + 出具契约）加一组套 ```sql 的写法：两句都判、都审，完整出具。裁判退回改写（rewrite_once）那一稿也包在代码块里时照样去掉：改写稿被采用，第二轮判到改过的那句，以前这条路没有测试守着。每条判断各做过一次去掉、测试变红。
|
2026-10-06 13:32:38 +08:00 |
|