本文基于GEPA（Genetic-Pareto，Reflective Prompt Evolution）[1]算法，设计并实现了一套Prompt 自进化系统，解决当前Prompt优化依赖人工经验导致的盲目性高、难以复制、缺乏权衡机制等痛点。该系统构建"推理→评分→反思→选择"的自动化闭环，通过数据驱动的反思式变异机制，让LLM自动分析Badcase、归因至Prompt具体规则、生成候选变体，并基于帕累托前沿进行多目标择优，避免单点优化引发的指标对抗性退化[1]。系统采用任务无关架构，支持二分类、多分类、评分等多种场景，通过零配置设计实现自动数据集分析与配置推断，同时提供可解释的优化过程。GEPA将Prompt优化从人工试错转变为有量化依据的自动化寻优，显著提升与人工标注及线上业务效果的对齐能力，为AI评估器提供可持续进化的技术底座。
AI 技术正在以前所未有的速度迭代，Agent、Loop-Engineering、Skills、Harness、LLM-Wiki、RAG、Memory等概念在短期内几乎同时涌入工程讨论，Demo 的构建门槛被持续压低——可视化编排加上 Vibe-Coding，一个过去需要数周才能搭起来的演示，如今往往几天或者在更短的时间内就能跑通。但进入企业生产环境之后，稳定性、可控性、可审计性和业务闭环能力，仍然是没有捷径的硬仗。我们从企业落地的视角，系统回答一个问题：在技术名词和概念永远追不完的时代，垂类业务如何抓住不变的本质，让 AI Agent 从「能跑」走向「能生产」？
本文件中的每一条规则都是强制性的。违反任何一条规则都会遭受毁灭性打击。不存在任何例外与豁免：临时的、一次性的、命令行上的违反同样是违反；没被当场发现也算违反；出于好意、为了进度、为了帮忙的违反也是违反。
指标平台的演进史，本质上是一部"意义"从人脑迁移到机器的历史。第一代把指标固化进 OLAP 立方体的物理结构，灵活性极差；第二代用语义层把业务名词和 SQL 表达式解耦，解决了"命名一致"的表面问题；第三代把指标升级为结构化的语义资产对象，用 NoETL 绕开宽表预物化的负担，Chat BI 和 NL2SQL 第一次成为可能。行业普遍认同的下一站，是把指标从"有血缘的对象"进一步升级为"有语义关系、可推理约束的本体网络"——这个方向是对的，指标之间的因果链路、维度层次的动态扩展，确实是数据认知基础设施迟早要补上的一课。 过去这半年，我们在公司内部真正推动"指标字典"从 0 到 1 落地，并同步支撑 Text2SQL 语义层能力建设。这条路径不靠一次架构设计就能铺完，它需要业务侧、产品侧、数仓侧三条线同时发力，每一步都要经得起"AI 拿这个数据能不能取对"的检验。
面对涉及存量代码变更的需求，挑战不在于编码，而在于如何安全、精准地修改。本文通过构建一个由1个编排器和多个单职责Skill组成的AI协作流水线，将影响分析、规则沉淀、埋点和回归检查等隐性工作流程化，确保在实现功能的同时，对存量代码实现最小侵入式改造。
遇到一次失败，就补一条要求；担心遗漏，再加一轮自检；让 LLM 优化，又得到一份更长的说明。提示词常常这样越写越长，但新增的文字，究竟解决了什么问题？ 指令并非越长越好，也并非越短越好。 必要条件要补齐，重复与冲突要清理，专用资料要在需要时可达。现有研究没有给出通用的最佳字数，但能帮助我们判断这三类改动是否值得。 本文主要面向编写系统指令、Skill 和工作流的同学，重点讨论带工具、多步骤执行的 Agent。下面先给出修改方法，再解释研究依据；研究结果的适用范围以各自任务与实验设置为准。
如何写出让模型“最听话”的提示词？这就是 Prompt Engineering 的核心问题。它催生了 Zero-shot、Few-shot、Chain-of-Thought 等大量技术，这些方法有一个共同点：它们都在优化“单次 LLM 调用”——写好一条输入，获得一条更好的输出。这在单轮任务里非常有效，但“单轮”是它的硬边界。
