最近在腾讯云技术社区看到了张思宇的一篇深度文章，主题是如何让一个 Skill 实现自主迭代、自我评测与自动回滚，经过 19 轮测试后零失误。技术细节极具参考价值，但真正让我受到启发的，是文章背后蕴藏的两层深层思考。
第一层，他把一件看似完全依赖直觉与经验的工作，拆解成了一整套可量化、可度量的流程。这让我联想到，软件工程中大量“说不清、道不明”的任务，其实都存在类似的优化空间。一旦完成了结构化——把输入、过程和输出都明确定义——AI 就能高效运转起来；而 AI 的迭代成果又会反过来反哺并持续优化这个结构化体系。这正是典型的正向飞轮效应。
第二层，他广泛借鉴了前人的成熟方法，结合自身实际场景，最终拼凑出一套更完善的解决方案。简单来说，就是通过“有机组合”现有方法论，创造出了新的实践体系。
那些“说不清”的工作
在软件工程中，有不少任务你明明知道它很重要，但就是很难说清楚“做到什么程度才算合格”。
Skill 调优就是一个典型例子。表面上看是写 prompt，实际上触发条件、安全规则、引用一致性等因素相互影响，改动了 A，很可能导致 B 出现问题。需求文档也一样——产品经理觉得自己写得清楚明白，开发同学读完后却可能理解出三个完全不同的意思。代码 Review 更是不用说，格式问题抓了一堆，但真正关键的逻辑漏洞却往往一个都没发现。
这些工作的共同点在于：高度依赖个人经验和手感，质量难以稳定复现。你无法写一个 CI 脚本来判断“这份需求文档已经达到了合格标准”。
但从另一个角度看，它们并非真的无法被结构化。只是我们在真正行动之前，自己就先觉得太麻烦，所以一直拖延着没去尝试。
现在 AI 的出现，让这个方向变得可行。但前提是——你自己必须先建立起一套结构化的评估方法，并且在推广之前，持续进行迭代和打磨。
张思宇做了什么
他没有继续在“多试几轮、多加点规则”的泥潭里打转，而是把“好不好”这个模糊的判断，拆解成了可度量的具体指标。
首先是标准答案（GT：Ground Truth）。每个测试用例都有明确的期望输出，通过就是通过，不通过就是不通过，绝不存在“差不多”这种模棱两可的说法。
然后是分层评测的机制。不是一口气把所有测试都跑完，而是先用秒级的程序检查做一轮快速筛选，再用分钟级的语义评测跟进，最后只有在必要时才会启动耗时十分钟的全量验证。每一层都像一个筛子，目的是尽早淘汰掉不合格的改动。
听起来是不是有点熟悉？没错，TDD、SLO、OKR 这些方法论，本质上都是类似的思路。
还有一个细节特别值得一说：他使用的是“AND”门控机制，而不是加权打分。每一轮改动，必须在五个维度上同时达标才行。不允许拿 A 维度的高分去弥补 B 维度的低分。如果质量提升了 10%，但 token 消耗翻了一倍？AND 门控不会放过你。
张思宇最厉害的地方，在于他把这套方法落地到了 Skill 调优这个几乎没人认真做过结构化的领域，并且实实在在地验证了它的可行性。
结构化之后，AI 才跑得动
一旦“好不好”变成了可度量的指标，有意思的事情就发生了：AI 可以自主跑循环了。
不再需要人每轮都去判断“这次改得行不行”。评测体系本身就是裁判，方案通过就留下，不通过就自动回滚。人的角色从“每轮都要参与判断”退到了“设计评测体系，偶尔调整方向”。
他的 skill-evolver 就是这样运行的。每一轮只改一个东西，然后跑评测，五个维度全部通过才 Commit，任何一个维度不满足就 Git Revert，就当这轮从未发生过。19 轮下来，测试用例从 17 个自动扩展到了 31 个，代码量削减了 60%，通过率达到了 100%。
其中有个例子特别典型。在第 7 轮，工具给自己加了一个 Git 状态检查——如果工作区状态不干净，就拒绝执行。当时所有测试都通过了，作者自己也测不出问题，因为他所有的 Skill 项目都在 Git 仓库下。但真实的用户，可能连 Git Init 都没做过。到了第 12 轮，工具自己发现了这个回归缺陷，并修改了初始化逻辑，在一个空目录上跑了端到端测试，最终通过了。
这个例子说明：结构化的评测体系，加上 AI 的循环迭代，能够触及人类天然够不到的边界。不是 AI 更聪明，而是它能不知疲倦地跑通更多的路径。
飞轮怎么转
到这里，整个飞轮的轮廓就很清晰了。
起点是“结构化”——你把一件模糊的工作拆解成可定义、可度量的指标。这是人最需要投入精力的环节，你必须想清楚什么叫“好”，然后把它编码成规则或数据。
结构化到位之后，AI 介入的效率会急剧提升。它不需要理解你的深层意图，只需要在一个明确的目标下，执行“改-测-判”的循环。目标越清晰，迭代就越有效。
而 AI 的每一轮迭代，都可能发现新的边界条件和失败模式。这些产出会沉淀回评测体系，让下一轮的判断更加精准。
这个逻辑，并不局限于 Skill 调优。
更多地方可以用
软件开发中，不少灰色地带都能走这条路。
需求工程。“需求文档写得清不清楚”是个模糊判断。但如果定义一套质量标准——比如每个功能点都必须有输入输出定义、异常分支覆盖、与现有功能的交互说明——那么 AI 就能对照这些标准，逐项检查、补全缺失项、甚至生成边界测试用例。
代码 Review。代码 Review 的质量，目前高度依赖 Reviewer 的个人经验。如果能定义“好 Review”的标准——比如每个函数变更都必须有原因说明、安全敏感路径的变更必须有安全评审标记、性能变更必须附带基准测试——那么 AI 就能完成第一轮筛选，只把那些真正需要人类判断的部分提交上来。
架构决策记录（ADR）。架构决策通常散落在会议纪要、聊天记录甚至个人的脑子里。如果规定每个决策记录都必须包含背景、备选方案、选择理由、预期风险、重新评估的触发条件，那么 AI 就能定期扫描，识别出过时的决策，或者发现自相矛盾的约束条件。
运维预案。“预案靠不靠谱”同样很难量化。但如果定义质量标准——比如每个告警都有对应的恢复脚本、脚本有演练记录、失败率超过阈值时自动升级——那么 AI 就能持续地迭代和维护预案库。
这些例子的模式高度一致：先定义“好”的标准，再让 AI 在这个标准下循环，最终的迭代产物反过来丰富和强化了标准本身。
但有个前提
结构化不是凭空发生的，它需要工程基础设施来支撑。所有的过程与结果，都应当被“写下来”并归档。
张思宇的实践能跑通，不光是因为他设计了一套评测体系。他还拥有版本控制——每一轮改动都有 Git Commit，回滚是原子操作。他有自动化测试——评测可以程序化执行，不需要人工介入。他有可追溯的执行记录——每次迭代的 Trace 都落盘，下一轮诊断时有据可查。他还有清晰的数据边界——训练集和 Holdout 集严格分离，防止过拟合。
换句话说，良好的软件工程实践——版本控制、自动化测试、日志追踪、数据管理——不仅仅是项目管理的需要，更是让 AI 发挥效率的、不可或缺的地基。
也要清醒
当然，这并非万能药。
首先，LLM 本身具有不确定性。同一份代码、同一组测试，跑四次的结果可能在 0.79 到 0.92 之间波动。你很难分清，这次的改进到底是你的方案变好了，还是仅仅因为模型今天“状态好”。因此，评测体系本身也需要具备一定的容错性。
其次，数据质量决定了天花板。如果标准答案本身都存在争议，那 AI 再怎么迭代也过不了那道坎。任何时候，都应该先审视数据，再去质疑工具。
成本也是真实的。自动化迭代意味着大量的 API 调用，省了人力，但花了算力。
最后，也是最关键的一点：第一轮必须有人。评测体系的设计、GT 数据的准备、门控规则的制定——这些前置工作的质量，直接决定了后续循环的效果。别指望把工作丢进去，自己就可以睡大觉。
回到核心
这篇文章其实不是在讲 Skill 怎么训练，对此感兴趣的读者可以直接去看张思宇的原文。
我真正想表达的是：软件开发中，大量看似只能靠经验来完成的工作，都有被结构化的可能。而一旦完成了结构化，AI 就能在这个清晰的框架内高效运转，其产出又会反过来强化和优化这个结构化体系。
这个飞轮的起点，不是 AI，而是工程方法本身。版本控制、自动化测试、清晰的接口定义、可追溯的执行记录——这些看似“传统”的软件工程基本功，恰恰是让 AI 发挥效率的前提条件。
与其问“AI 能帮我做什么”，不如问“我的工程基础设施，能让 AI 在上面跑多快”。
轨道修得好，火车自然快。
- 软件开发中大量“说不清、靠手感”的工作都有结构化的空间，第一步是定义“什么算好”。
- 结构化是 AI 高效运转的前提——目标可测量、结果可判定，AI 才能真正实现自主迭代。
- 飞轮效应：结构化让 AI 提效，AI 的产出反过来丰富结构化，循环加速。
- 版本控制、自动化测试、日志追踪、数据管理等工程基础设施，是飞轮运转的地基。
- LLM 的不确定性、数据质量、成本、前置人工投入，都是必须正视的现实约束。
- 与其问 AI 能做什么，不如问基础设施能让 AI 跑多快。
