把一串看起来没什么规律的字符丢给 AI让它“解码并生成代码”它确实能还你一段能跑的程序——但这个过程的可靠性远没有表面看起来那么高。前几天一位朋友拿xooooxxoooxxx来问我AI 到底是怎么“看”这串字符的它凭什么觉得自己解对了我做 AI 辅助开发工具好几年这类问题几乎每周都能碰到。这篇文章就把这条链路从输入到输出完整拆开AI 如何对模式串做结构归纳、如何选择解码假设、又如何把假设翻译成可执行代码以及最容易翻车的地方在哪里。先给结论AI 能做好这件事靠的是三样东西——训练语料里沉淀的大量编码/解码套路、对输入序列做统计归纳的能力、以及提示词把意图约束清楚之后的推理稳定性。但这里有个很多人没意识到的前提xooooxxoooxxx这类字符串本身并没有唯一正确的“解码结果”。所谓解码本质是选一个能自圆其说、又被场景支持的生成规则。理解了这句话后面所有内容都好办了。1. 先拆解 xooooxxoooxxx这串字符在机器眼里到底是什么1.1 肉眼分组与机器分组的差异人看到xooooxxoooxxx的第一反应是按视觉惯性分组x / oooo / xx / ooo / xxx。这个分组其实已经抓住了核心结构——五个连续段长度分别是 1、4、2、3、3相邻段的字符交替变化。换句话说这串字符的信息量不在“长什么样”而在“每一段有几个、是哪一种字符”。把这个观察量化成一张游程表run-length table就是后面所有工作的地基段字符长度1x12o43x24o35x3你可能会觉得这点事还用 AI 来解但注意模型在处理原始字符串时并没有“分组”这个显式操作它是靠统计字符之间的转移关系来推断结构的。后面我会讲这个差异是怎么影响生成质量的。1.2 多种假设并存没有唯一正确的“解码”同一个游程表可以派生出一大堆合法解释。我把常见的几种列出来你会发现它们之间没有绝对的谁对谁错游程编码RLE把xooooxxoooxxx压缩成1x4o2x3o3x解码就是展开这个过程。二进制串把 x 当作 1、o 当作 0得到1000011000111十进制是 4295十六进制是0x10c7。正则语言它属于xoxox这个语言族任意满足 5 段交替的字符串都算同类。摩尔斯变体把 x 当短音、o 当长音或反过来能拆出几个数字和字母但语义很牵强。这个多解性不是我在抬杠而是解码问题的本质没有上下文任何符号串都可以套进不同的解释框架。AI 能做的是根据任务场景给每个假设打分然后把分数最高的那个翻译成代码。意识到这一点你就明白为什么“给我解码”这种模糊提问经常得到离谱答案了。2. 大模型处理模式串的内部机制分词、注意力与“伪计数”2.1 分词模式串在进模型前已经被切碎了很多人以为模型是按字符读xooooxxoooxxx的其实不是。主流大模型用的是子词分词器BPE 或 SentencePiece输入会先被切成若干 token。这串字符可能被切成xoooo / xx / ooo / xxx也可能被切成x / oooo / xx / ooo / xxx极端情况下如果某个词表里恰好收录了它整体它甚至会被当成一个 token 处理。这个切法直接决定了模型能不能“数清楚”。如果模式串被切成一个整体 token模型看到的就是一个离散符号它只能靠记忆或上下文去猜测内部结构如果被切成多个 token它才有机会在注意力层里做跨 token 的比较。这也是为什么很多模型在数长串字符时会翻车——不是它笨是分词器根本没给它“逐字”的视角。2.2 注意力与统计归纳模型不是真的在“数数”LLM 的核心计算单元是注意力机制。面对xooooxxoooxxx注意力层会学到一件事相邻 token 之间如果反复出现同一个字符那这个字符就是同一个游程的一部分一旦出现字符切换游程就结束了。这本质上是一个统计归纳过程跟人眼分组用的是同一套逻辑。但注意注意力并不精确计数。它给的是“概率倾向”不是“准确长度”。模型可能感知到这里有一段比较长的 o但到底有四个还是五个它并没有一个循环计数器来保证。训练语料里大量 RLE、base64、十六进制编码样本让模型学会了“看到这种结构应该输出 RLE 解释”但它对长度的把握依然是模糊的。这是后面所有坑的根源模型擅长选规则不擅长执行规则。3. 把解码假设显式化一套能稳定产出代码的提示词流程3.1 一条无效提示词为什么翻车我拿“帮我解码 xooooxxoooxxx 并生成代码”这种问法试过不少模型结果很有代表性模型通常会挑一个最“像编码”的解释常见的是二进制然后写一段int(..., 2)之类的代码。问题是二进制要成立必须先约定 x1、o0这个约定在提问里根本不存在纯属模型脑补。更糟的是因为分词器切碎或注意力计数不准它生成的二进制串偶尔还会少一位多一位代码能跑但结论是错的。这类失败不能全怪模型。“解码”在自然语言里本来就是歧义巨大的任务——解成游程是解解成二进制也是解解成正则匹配还是解。提示词没有给模型任何约束它只能在训练先验里随便抓一个最显眼的。3.2 五步提示模板从游程表到可验证代码我自己在项目里用的套路是强制模型先产出中间结果再写代码。五个步骤缺一不可先拆游程表要求把每个连续段的字符和长度列出来当作后续所有步骤的依据。列出候选规则基于游程表给出至少三种解释并说明每种解释的成立条件。指定一条路线由你根据业务场景选或者让模型按“可逆性优先”选。生成代码必须包含从输入到解码结果的完整函数不接受只写核心片段。附验证函数要求代码里带上一个能判断“解码结果能否还原成原串”的测试。一个我常用的提示词大概是这样的把 xooooxxoooxxx 按连续相同字符拆成游程表 基于游程表列出至少三种解码规则说明每种规则的成立前提 从中选择一种用 Python 实现解码函数 代码必须包含一个验证函数用于检查解码结果能否还原成原串 最后执行验证并打印结果。模型的输出思路大致是先给出游程表 x×1、o×4、x×2、o×3、x×3然后列出 RLE、正则、二进制三种假设并指出 RLE 的“可逆性最好、不需要额外符号约定”所以选它接着写游程解析和展开两个函数最后调用验证函数打印 True。这个套路的核心是让中间产物显式化。模型一旦把游程表写出来后续代码就有明确依据而不是凭感觉生成验证函数则把“对不对”的判断从人眼交给了程序。我实测下来这五步流程能把这类任务的可用率从五成左右拉到九成以上。4. 四条解码路线的实测RLE、正则、状态机与进制转换4.1 RLE可逆性最好的基线方案如果没有任何额外背景我默认优先让 AI 走 RLE 路线因为它是唯一能“原路返回”的解释编码和解码互为逆操作验证起来最简单。让 AI 生成的代码大致长这样def runs(text): if not text: return [] result [] prev text[0] count 1 for ch in text[1:]: if ch prev: count 1 else: result.append((prev, count)) prev ch count 1 result.append((prev, count)) return result def expand(rle): return .join(ch * n for ch, n in rle) raw xooooxxoooxxx rle runs(raw) print(rle) print(expand(rle) raw)输出是[(x, 1), (o, 4), (x, 2), (o, 3), (x, 3)]并且expand(runs(raw)) raw返回 True。这是判断代码有没有写对的硬标准。RLE 的缺点也很明显它只刻画了这一串字符本身的重复结构没法解释为什么是 1、4、2、3、3 这几个数。如果你想从这串字符里读出更深层的语义RLE 帮不上忙。4.2 正则只描述不还原如果任务是“检查别的字符串是不是同类”那应该走正则路线。让 AI 生成代码的方式很简单import re raw xooooxxoooxxx exact_regex rxo{4}xxo{3}xxx generic_alternating r^xoxox$ print(bool(re.fullmatch(exact_regex, raw))) # True print(bool(re.fullmatch(generic_alternating, raw))) # True print(bool(re.fullmatch(generic_alternating, xooooxxxooo))) # False结尾不是 x 段这段代码里exact_regex忠于原始模式generic_alternating则允许每段长度任意变化只保留 5 段交替的结构。正则的好处是表达能力强坏处是它只做匹配不做还原用它“解码”其实不太恰当——除非你的目标就是写一个过滤器。我见过不少人让 AI 生成“匹配所有同类串”的正则结果 AI 给了一串硬编码这类输出一定要在提示词里强调“参数化、不要写死”。4.3 状态机适合流式识别的重型方案还有一种更工程化的选择是把 5 段游程定义成一组期望状态写一个识别器。它读入完整字符串按顺序核对每一段是否满足预期exact_runs [(x, 1), (o, 4), (x, 2), (o, 3), (x, 3)] def match_run_structure(text): pos 0 for ch, length in exact_runs: if text[pos:pos length] ! ch * length: return False pos length return pos len(text) print(match_run_structure(xooooxxoooxxx)) # True print(match_run_structure(xoooxxoooxxx)) # False第二段 o 只有 3 个状态机的好处是结构清晰、可扩展、天然适合流式输入——每来一个字符走一步不需要把整串加载完。缺点是代码量比前两个方案大而且它同样只能做识别不能还原。如果你的场景是网络协议解析或者逐字节处理状态机是正解如果只是处理这一个字符串它有点杀鸡用牛刀。4.4 进制转换需要外部上下文才靠谱二进制解释只有在两种情况下值得选一是系统里明确出现过 x/o 代表 0/1 的约定二是你正在处理某个设备或协议导出的标志串。代码非常简单raw xooooxxoooxxx binary raw.replace(x, 1).replace(o, 0) print(binary) # 1000011000111 print(int(binary, 2)) # 4295 print(hex(int(binary, 2))) # 0x10c7如果没有任何上下文我一般不建议选这条路。因为它强加了一个符号映射而这个映射完全可以被替换成任意一对字符没有理由非选 x1、o0 不可。AI 在没有约束时优先选二进制更多是因为训练语料里二进制编码案例多而不是因为它更合理。4.5 四条路线的横向对比路线一句话能力可逆性泛化性典型场景RLE压缩与还原是中序列规整、数据压缩正则匹配同类串否高输入校验、过滤状态机流式识别否高协议解析、逐字节处理进制转换符号转数值是低位标志、固定符号约定我拿这几个方向试过模型基本能在一次对话里全部给出来区别在于谁更贴合你的问题。我的建议是默认 RLE需要匹配用正则需要流式处理用状态机只有确认了符号约定再考虑进制。选型不是比谁的代码高级而是比谁更匹配你要解决的问题。5. 最容易翻车的三个环节以及我常用的验证兜底5.1 计数错误让模型写代码别让它自己数最典型的翻车是模型把 o 的数量从 4 数成 5或者在生成二进制串时多写一位。原因是前面说的注意力只给概率不给计数。解决办法很简单一切计数都交给模型生成的代码去做。提示词里加一句“请写一个函数来统计每个连续段的长度不要直接在回答里数数”错误率立刻降一个量级。有一次我让模型直接回答“这串里 o 连续出现了几次”它答得犹豫改成让它写一个runs()函数结果一次就对。这是我在实际使用中体会最深的一条把计算交给代码把规则判断交给模型两者各干各擅长的。5.2 假设锁定给 AI 多个候选别让它猜另一个翻车模式是模型对第一个冒出来的假设过度自信你问它“还有别的解吗”它才会改口。对付这个最有效的办法是在第一轮提示词里就强制它列候选而不是让它直接给答案。我常用的措辞是“在你选方案之前先列出至少三种可能的解释并说明各自需要什么前提条件。”这一步相当于给模型加了约束逼它做多假设对比而不是走捷径。真实场景里我遇到过模型一口咬定这是二进制并且生成了一段能跑通的代码。但我拿往返测试一验发现它根本没有定义“还原”逻辑只是把字符串硬编码成了一个数值。追问之下它才承认如果要求“解码结果必须能还原原串”RLE 会更稳。这个案例说明模型给答案的速度很快但答案的合理性完全取决于你给它设了多少检查点。5.3 往返验证解码代码的唯一验收标准无论模型选了哪条路线我的验收标准只有一个能否通过往返测试。对 RLE 来说是expand(runs(s)) s对进制转换来说是把十进制重新转回二进制再替换回 x/o要求与原串完全一致对正则和状态机来说是拿正例和反例各测一遍确认它能接受xooooxxoooxxx而拒绝xoooxxoooxxx。把这套测试要求直接写进提示词让模型在生成代码的同时自己写断言你会发现它交出来的代码明显更完整。因为生成测试的过程会迫使模型重新检查自己的逻辑相当于一次自审。你甚至可以要求模型把验证结果打印出来这样代码跑没跑、对不对一眼就能看到。最后说个我自己的习惯。每次拿到这种模式串任务我不会先问 AI“这是什么”而是先问“我打算拿它干什么”。要还原就 RLE要过滤就正则要流式识别就状态机要数值就进制转换——需求定了提示词自然就清楚了AI 翻车的概率也小得多。说白了xooooxxoooxxx本身没有答案你的场景才是答案。能明白这一点你使用 AI 解码类功能的水平就已经超过大半人了。
AI解码模式串：从xooooxxoooxxx到可验证代码的完整链路
把一串看起来没什么规律的字符丢给 AI让它“解码并生成代码”它确实能还你一段能跑的程序——但这个过程的可靠性远没有表面看起来那么高。前几天一位朋友拿xooooxxoooxxx来问我AI 到底是怎么“看”这串字符的它凭什么觉得自己解对了我做 AI 辅助开发工具好几年这类问题几乎每周都能碰到。这篇文章就把这条链路从输入到输出完整拆开AI 如何对模式串做结构归纳、如何选择解码假设、又如何把假设翻译成可执行代码以及最容易翻车的地方在哪里。先给结论AI 能做好这件事靠的是三样东西——训练语料里沉淀的大量编码/解码套路、对输入序列做统计归纳的能力、以及提示词把意图约束清楚之后的推理稳定性。但这里有个很多人没意识到的前提xooooxxoooxxx这类字符串本身并没有唯一正确的“解码结果”。所谓解码本质是选一个能自圆其说、又被场景支持的生成规则。理解了这句话后面所有内容都好办了。1. 先拆解 xooooxxoooxxx这串字符在机器眼里到底是什么1.1 肉眼分组与机器分组的差异人看到xooooxxoooxxx的第一反应是按视觉惯性分组x / oooo / xx / ooo / xxx。这个分组其实已经抓住了核心结构——五个连续段长度分别是 1、4、2、3、3相邻段的字符交替变化。换句话说这串字符的信息量不在“长什么样”而在“每一段有几个、是哪一种字符”。把这个观察量化成一张游程表run-length table就是后面所有工作的地基段字符长度1x12o43x24o35x3你可能会觉得这点事还用 AI 来解但注意模型在处理原始字符串时并没有“分组”这个显式操作它是靠统计字符之间的转移关系来推断结构的。后面我会讲这个差异是怎么影响生成质量的。1.2 多种假设并存没有唯一正确的“解码”同一个游程表可以派生出一大堆合法解释。我把常见的几种列出来你会发现它们之间没有绝对的谁对谁错游程编码RLE把xooooxxoooxxx压缩成1x4o2x3o3x解码就是展开这个过程。二进制串把 x 当作 1、o 当作 0得到1000011000111十进制是 4295十六进制是0x10c7。正则语言它属于xoxox这个语言族任意满足 5 段交替的字符串都算同类。摩尔斯变体把 x 当短音、o 当长音或反过来能拆出几个数字和字母但语义很牵强。这个多解性不是我在抬杠而是解码问题的本质没有上下文任何符号串都可以套进不同的解释框架。AI 能做的是根据任务场景给每个假设打分然后把分数最高的那个翻译成代码。意识到这一点你就明白为什么“给我解码”这种模糊提问经常得到离谱答案了。2. 大模型处理模式串的内部机制分词、注意力与“伪计数”2.1 分词模式串在进模型前已经被切碎了很多人以为模型是按字符读xooooxxoooxxx的其实不是。主流大模型用的是子词分词器BPE 或 SentencePiece输入会先被切成若干 token。这串字符可能被切成xoooo / xx / ooo / xxx也可能被切成x / oooo / xx / ooo / xxx极端情况下如果某个词表里恰好收录了它整体它甚至会被当成一个 token 处理。这个切法直接决定了模型能不能“数清楚”。如果模式串被切成一个整体 token模型看到的就是一个离散符号它只能靠记忆或上下文去猜测内部结构如果被切成多个 token它才有机会在注意力层里做跨 token 的比较。这也是为什么很多模型在数长串字符时会翻车——不是它笨是分词器根本没给它“逐字”的视角。2.2 注意力与统计归纳模型不是真的在“数数”LLM 的核心计算单元是注意力机制。面对xooooxxoooxxx注意力层会学到一件事相邻 token 之间如果反复出现同一个字符那这个字符就是同一个游程的一部分一旦出现字符切换游程就结束了。这本质上是一个统计归纳过程跟人眼分组用的是同一套逻辑。但注意注意力并不精确计数。它给的是“概率倾向”不是“准确长度”。模型可能感知到这里有一段比较长的 o但到底有四个还是五个它并没有一个循环计数器来保证。训练语料里大量 RLE、base64、十六进制编码样本让模型学会了“看到这种结构应该输出 RLE 解释”但它对长度的把握依然是模糊的。这是后面所有坑的根源模型擅长选规则不擅长执行规则。3. 把解码假设显式化一套能稳定产出代码的提示词流程3.1 一条无效提示词为什么翻车我拿“帮我解码 xooooxxoooxxx 并生成代码”这种问法试过不少模型结果很有代表性模型通常会挑一个最“像编码”的解释常见的是二进制然后写一段int(..., 2)之类的代码。问题是二进制要成立必须先约定 x1、o0这个约定在提问里根本不存在纯属模型脑补。更糟的是因为分词器切碎或注意力计数不准它生成的二进制串偶尔还会少一位多一位代码能跑但结论是错的。这类失败不能全怪模型。“解码”在自然语言里本来就是歧义巨大的任务——解成游程是解解成二进制也是解解成正则匹配还是解。提示词没有给模型任何约束它只能在训练先验里随便抓一个最显眼的。3.2 五步提示模板从游程表到可验证代码我自己在项目里用的套路是强制模型先产出中间结果再写代码。五个步骤缺一不可先拆游程表要求把每个连续段的字符和长度列出来当作后续所有步骤的依据。列出候选规则基于游程表给出至少三种解释并说明每种解释的成立条件。指定一条路线由你根据业务场景选或者让模型按“可逆性优先”选。生成代码必须包含从输入到解码结果的完整函数不接受只写核心片段。附验证函数要求代码里带上一个能判断“解码结果能否还原成原串”的测试。一个我常用的提示词大概是这样的把 xooooxxoooxxx 按连续相同字符拆成游程表 基于游程表列出至少三种解码规则说明每种规则的成立前提 从中选择一种用 Python 实现解码函数 代码必须包含一个验证函数用于检查解码结果能否还原成原串 最后执行验证并打印结果。模型的输出思路大致是先给出游程表 x×1、o×4、x×2、o×3、x×3然后列出 RLE、正则、二进制三种假设并指出 RLE 的“可逆性最好、不需要额外符号约定”所以选它接着写游程解析和展开两个函数最后调用验证函数打印 True。这个套路的核心是让中间产物显式化。模型一旦把游程表写出来后续代码就有明确依据而不是凭感觉生成验证函数则把“对不对”的判断从人眼交给了程序。我实测下来这五步流程能把这类任务的可用率从五成左右拉到九成以上。4. 四条解码路线的实测RLE、正则、状态机与进制转换4.1 RLE可逆性最好的基线方案如果没有任何额外背景我默认优先让 AI 走 RLE 路线因为它是唯一能“原路返回”的解释编码和解码互为逆操作验证起来最简单。让 AI 生成的代码大致长这样def runs(text): if not text: return [] result [] prev text[0] count 1 for ch in text[1:]: if ch prev: count 1 else: result.append((prev, count)) prev ch count 1 result.append((prev, count)) return result def expand(rle): return .join(ch * n for ch, n in rle) raw xooooxxoooxxx rle runs(raw) print(rle) print(expand(rle) raw)输出是[(x, 1), (o, 4), (x, 2), (o, 3), (x, 3)]并且expand(runs(raw)) raw返回 True。这是判断代码有没有写对的硬标准。RLE 的缺点也很明显它只刻画了这一串字符本身的重复结构没法解释为什么是 1、4、2、3、3 这几个数。如果你想从这串字符里读出更深层的语义RLE 帮不上忙。4.2 正则只描述不还原如果任务是“检查别的字符串是不是同类”那应该走正则路线。让 AI 生成代码的方式很简单import re raw xooooxxoooxxx exact_regex rxo{4}xxo{3}xxx generic_alternating r^xoxox$ print(bool(re.fullmatch(exact_regex, raw))) # True print(bool(re.fullmatch(generic_alternating, raw))) # True print(bool(re.fullmatch(generic_alternating, xooooxxxooo))) # False结尾不是 x 段这段代码里exact_regex忠于原始模式generic_alternating则允许每段长度任意变化只保留 5 段交替的结构。正则的好处是表达能力强坏处是它只做匹配不做还原用它“解码”其实不太恰当——除非你的目标就是写一个过滤器。我见过不少人让 AI 生成“匹配所有同类串”的正则结果 AI 给了一串硬编码这类输出一定要在提示词里强调“参数化、不要写死”。4.3 状态机适合流式识别的重型方案还有一种更工程化的选择是把 5 段游程定义成一组期望状态写一个识别器。它读入完整字符串按顺序核对每一段是否满足预期exact_runs [(x, 1), (o, 4), (x, 2), (o, 3), (x, 3)] def match_run_structure(text): pos 0 for ch, length in exact_runs: if text[pos:pos length] ! ch * length: return False pos length return pos len(text) print(match_run_structure(xooooxxoooxxx)) # True print(match_run_structure(xoooxxoooxxx)) # False第二段 o 只有 3 个状态机的好处是结构清晰、可扩展、天然适合流式输入——每来一个字符走一步不需要把整串加载完。缺点是代码量比前两个方案大而且它同样只能做识别不能还原。如果你的场景是网络协议解析或者逐字节处理状态机是正解如果只是处理这一个字符串它有点杀鸡用牛刀。4.4 进制转换需要外部上下文才靠谱二进制解释只有在两种情况下值得选一是系统里明确出现过 x/o 代表 0/1 的约定二是你正在处理某个设备或协议导出的标志串。代码非常简单raw xooooxxoooxxx binary raw.replace(x, 1).replace(o, 0) print(binary) # 1000011000111 print(int(binary, 2)) # 4295 print(hex(int(binary, 2))) # 0x10c7如果没有任何上下文我一般不建议选这条路。因为它强加了一个符号映射而这个映射完全可以被替换成任意一对字符没有理由非选 x1、o0 不可。AI 在没有约束时优先选二进制更多是因为训练语料里二进制编码案例多而不是因为它更合理。4.5 四条路线的横向对比路线一句话能力可逆性泛化性典型场景RLE压缩与还原是中序列规整、数据压缩正则匹配同类串否高输入校验、过滤状态机流式识别否高协议解析、逐字节处理进制转换符号转数值是低位标志、固定符号约定我拿这几个方向试过模型基本能在一次对话里全部给出来区别在于谁更贴合你的问题。我的建议是默认 RLE需要匹配用正则需要流式处理用状态机只有确认了符号约定再考虑进制。选型不是比谁的代码高级而是比谁更匹配你要解决的问题。5. 最容易翻车的三个环节以及我常用的验证兜底5.1 计数错误让模型写代码别让它自己数最典型的翻车是模型把 o 的数量从 4 数成 5或者在生成二进制串时多写一位。原因是前面说的注意力只给概率不给计数。解决办法很简单一切计数都交给模型生成的代码去做。提示词里加一句“请写一个函数来统计每个连续段的长度不要直接在回答里数数”错误率立刻降一个量级。有一次我让模型直接回答“这串里 o 连续出现了几次”它答得犹豫改成让它写一个runs()函数结果一次就对。这是我在实际使用中体会最深的一条把计算交给代码把规则判断交给模型两者各干各擅长的。5.2 假设锁定给 AI 多个候选别让它猜另一个翻车模式是模型对第一个冒出来的假设过度自信你问它“还有别的解吗”它才会改口。对付这个最有效的办法是在第一轮提示词里就强制它列候选而不是让它直接给答案。我常用的措辞是“在你选方案之前先列出至少三种可能的解释并说明各自需要什么前提条件。”这一步相当于给模型加了约束逼它做多假设对比而不是走捷径。真实场景里我遇到过模型一口咬定这是二进制并且生成了一段能跑通的代码。但我拿往返测试一验发现它根本没有定义“还原”逻辑只是把字符串硬编码成了一个数值。追问之下它才承认如果要求“解码结果必须能还原原串”RLE 会更稳。这个案例说明模型给答案的速度很快但答案的合理性完全取决于你给它设了多少检查点。5.3 往返验证解码代码的唯一验收标准无论模型选了哪条路线我的验收标准只有一个能否通过往返测试。对 RLE 来说是expand(runs(s)) s对进制转换来说是把十进制重新转回二进制再替换回 x/o要求与原串完全一致对正则和状态机来说是拿正例和反例各测一遍确认它能接受xooooxxoooxxx而拒绝xoooxxoooxxx。把这套测试要求直接写进提示词让模型在生成代码的同时自己写断言你会发现它交出来的代码明显更完整。因为生成测试的过程会迫使模型重新检查自己的逻辑相当于一次自审。你甚至可以要求模型把验证结果打印出来这样代码跑没跑、对不对一眼就能看到。最后说个我自己的习惯。每次拿到这种模式串任务我不会先问 AI“这是什么”而是先问“我打算拿它干什么”。要还原就 RLE要过滤就正则要流式识别就状态机要数值就进制转换——需求定了提示词自然就清楚了AI 翻车的概率也小得多。说白了xooooxxoooxxx本身没有答案你的场景才是答案。能明白这一点你使用 AI 解码类功能的水平就已经超过大半人了。