结构化是 AI 提效的地基

最近看到 腾讯云技术社区 的 张思宇 写了一篇文章，讲他怎么让一个 Skill 自己迭代、自己评测、自己回滚，19 轮跑下来零翻车。原文链接放在文章结尾。

引起我兴趣的不是 Skill 调优本身，而是下面两个方面。

1. 把一件『看上去是靠手感』的事拆解成了可测量的流程。这让我想到，软件开发里大量『说不清』的工作，其实都可以走类似的路——而一旦结构化完成，AI 就能跑得飞快，反过来又让结构化更完善。软件开发里大量说不清的工作，都可以走类似的路——首先要结构化(输入/过程/输出)。一旦结构化完成，AI 就能跑得飞快，反过来又让结构化更完善。这是个飞轮。
2. 广泛借鉴他人的成果，结合自己的问题，形成新的更完整的解决方案。也就是：把现存的方法进行有机结合，形成新的方法。

1

那些『说不清』的工作

软件工程里有不少工作，你知道它重要，但很难说清楚『做到什么程度算好』。

Skill 调优就是一个。表面上看是写 prompt，实际上触发条件、安全规则、引用一致性互相牵扯，改了 A 就可能弄坏 B。需求文档也类似，产品觉得自己写明白了，开发能读出三个意思。代码 Review 更不用说，格式问题挑了一堆，逻辑漏洞一个没抓住。

这些活儿有个共同点：靠经验，靠手感，质量不好复现。你原来是没法写个 CI 来判断『这份需求文档及格了』。

但换个角度想，它们并非真的没法结构化。只是我们没去认真做这件事，因为这个“事”在没有人做之前，自己想一想，都觉得麻烦。

现在 AI 来说，似乎这个方向是可行的。

但前提是，你自己需要先建立结构化评估方法，然后在推广前要持续迭代。

2

张思宇做了什么

他没有继续在『多试几轮、多加点规则』里打转，而是把『好不好』这个模糊判断拆成了可测量的东西。

首先是标准答案(GT: Ground Truth)。每个测试用例都有明确的期望输出，过就是过，不过就是不过，没有『差不多』。

然后是分层评测。不是一口气全跑，而是秒级的程序检查先筛一轮，分钟级的语义评测跟上，十分钟级的全量验证只在需要时才跑。每一层都是筛子，尽早把不合格的改动淘汰掉。

听起来是不是有一点“熟悉感”，对吧？

TDD、SLO、OKR 都是类似的思路。

还有一个细节值得说：他用 AND 门控代替了加权打分。每轮改动必须在五个维度上同时达标，不允许拿 A 的高分补 B 的低分。 质量涨了 10% 但 token 翻倍？AND 门控不会放过你。

区别在于，他把这套东西落地到了 Skill 这个几乎没人认真结构化过的领域，而且验证了可行性。

3

结构化之后，AI 才跑得动

『好不好』一旦变成可测量的指标，有意思的事就来了：AI 可以自己跑循环了。

不需要人每轮都去判断『这次改得行不行』。评测体系就是裁判，通过就留下，不通过就回滚。人从『每轮参与判断』退到了『设计评测体系、偶尔调整方向』的位置。

他的 skill-evolver 就是这样跑的。每轮只改一个东西，跑评测，五维全过才 commit，任何一个不满足就 git revert，当这轮没发生过。19 轮下来，测试用例从 17 个自动扩到 31 个，代码量砍了 60%，通过率 100%。

其中有个例子挺典型。第 7 轮，工具给自己加了个 git 状态检查——状态不干净就拒绝执行。测试全过了，作者自己测不出问题，因为他所有 Skill 都在 git 仓库下。但真实用户可能连 git init 都没做过。第 12 轮，工具自己发现了这个回归，改了初始化逻辑，在一个空目录上跑了端到端测试，通过了。

结构化的评测加上 AI 的循环迭代，能够触达人天然够不到的边界。不是 AI 更聪明，是它能不知疲倦地跑更多的路径。

4

飞轮怎么转

到这里飞轮的轮廓就出来了。

起点是结构化——你把一件模糊的工作拆成可定义、可测量的指标。这是人最需要投入的环节，你得想清楚什么叫好，然后把它编码成规则或数据。

结构化到位之后，AI 介入的效率会急剧提升。它不需要理解你的意图，只需要在明确的目标下做『改-测-判』的循环。目标越清晰，迭代越有效。

而 AI 的每一轮迭代，都可能发现新的边界条件和失败模式，这些产出沉淀回评测体系，让下一轮判断更准确。

这个逻辑不限于 Skill 调优。

5

更多地方可以用

软件开发里不少灰色地带都能走这条路。

需求工程。『需求文档写得清不清楚』是个模糊判断。但如果定义一套质量标准——每个功能点必须有输入输出定义、异常分支覆盖、与现有功能的交互说明——AI 就能对照标准逐项检查、补全缺失项、生成边界测试用例。

代码 Review。目前质量高度依赖 Reviewer 的经验。如果定义『好 Review』的标准——每个函数变更都有原因说明、安全敏感路径的变更必须有安全评审标记、性能变更必须附带基准测试——AI 就能完成第一轮筛选，只把需要人判断的部分提交上来。

架构决策记录（ADR）。决策通常散落在会议纪要、聊天记录甚至个人脑子里。如果每个决策记录都要求包含背景、备选方案、选择理由、预期风险、重新评估触发条件，AI 就能定期扫描，识别过时的决策、发现自相矛盾的约束。

运维预案也一样。『预案靠不靠谱』很难量化，但如果定义质量标准——每个告警有对应的恢复脚本、脚本有演练记录、失败率超过阈值自动升级——AI 就能持续迭代预案库。

这些例子的模式是一致的：先定义好的标准，再让 AI 在这个标准下循环，迭代产物反过来丰富标准本身。

6

但有个前提

结构化不是凭空发生的，它需要工程基础设施撑着。 所有的过程结果都应该被『写下并归档』。

张思宇 的实践能跑通，不光是因为他设计了一套评测体系。他还有版本控制，每一轮改动都有 git commit，回滚是原子操作。有自动化测试，评测程序化执行，不需要人介入。有可追溯的执行记录，每次迭代的 trace 都落盘，下一轮诊断时有据可查。还有清晰的数据边界，训练集和 holdout 集严格分离，防止过拟合。

换句话说，良好的软件工程实践——版本控制、自动化测试、日志追踪、数据管理——不只是项目管理的需要，更是让 AI 发挥效率的地基。

7

也要清醒

当然不是万能的。

LLM 本身有不确定性。同一份代码、同一组测试，跑四次结果可能在 0.79 到 0.92 之间波动。你的改动到底是让结果变好了，还是模型今天状态好？分不清。评测体系本身也需要容错。

数据质量决定天花板。 标准答案本身有争议的话，AI 再怎么迭代也过不了。先审视数据，再质疑工具。

成本是真实的。自动化迭代意味着大量的 API 调用，省了人力，花了算力。

还有，第一轮需要人。评测体系的设计、GT 数据的准备、门控规则的制定，这些前置工作的质量直接决定后续循环的效果。别指望丢进去睡一觉就行。

8

回到核心

这篇文章不是在讲 Skill 怎么训练，对此感兴趣的读者可以直接看 张思宇 的原文。

我想说的是：软件开发中大量看似只能靠经验来完成的工作，都有被结构化的可能。结构化一旦发生，AI 就能在框架内高效运转，产出又反过来强化结构化。

这个飞轮的起点不是 AI，是工程方法。版本控制、自动化测试、清晰的接口定义、可追溯的执行记录——这些『传统』的软件工程基本功，恰恰是 AI 发挥效率的前提条件。

与其问 AI 能帮我做什么，不如问我的工程基础设施能让 AI 在上面跑多快。

轨道修得好，火车自然快。

要点总结

• 软件开发中大量『说不清、靠手感』的工作都有结构化的空间，第一步是定义『什么算好』
• 结构化是 AI 高效运转的前提——目标可测量、结果可判定，AI 才能真正自主迭代
• 飞轮：结构化让 AI 提效，AI 的产出反过来丰富结构化，循环加速
• 版本控制、自动化测试、日志追踪、数据管理这些工程基础设施是飞轮的地基
• LLM
   不确定性、数据质量、成本、前置人工投入都是现实约束
• 与其问 AI 能做什么，不如问基础设施能让 AI 跑多快

本文灵感来自 腾讯云技术社区张思宇 的文章《让 Skill 自己训练自己：8 阶段 Loop、3 层评测、5 维 AND 门控，从此实现自进化》。Skill 自进化的技术细节请移步原文。