结构化思维：AI提效的隐藏飞轮
软件开发中大量模糊工作可被结构化，定义可测量指标后AI能自主执行“改-测-判”循环，其产出反过来优化结构化体系，形成飞轮效应。版本控制、自动化测试等工程基础设施是前提，同时需正视LLM不确定性和数据质量等约束。
最近，腾讯云技术社区张思宇发表了一篇文章，探讨如何让一个 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 跑多快。