ACE的落地案例应用
1 背景介绍【AI大模型教程】
开发者以细粒度和目标明确的方式，有意识地为LLM设计、构建和提供相关信息的过程被称为上下文工程。它侧重于为特定任务收集和选择输入数据，包括相关的指南、配置文件、文档和示例代码片段。
传统的README文件是为人类开发者编写的上下文工程，提供快速入门指南和项目描述，而AI配置文件则是明确为AI智能体设计的上下文工程，它提供一个机器可读的上下文和过程知识的中心来源。其内容从构建和测试项目的终端命令，到文档资源的链接、常见工作流、编码和命名规范、创建拉取请求的指令、安全考量等等。
由于提示在内容生成后很少被保留，AI配置文件提供了一个独特的机会来研究开发者如何根据其需求定制AI智能体、他们认为哪些相关信息值得包含、如何呈现这些信息。文章提出了重要的未解问题包括：
RQ1 开源软件项目在多大程度上采用了AI配置文件？
RQ2 开源开发者在AI配置文件中提供了哪些信息，以及他们如何呈现这些信息？
2 数据收集与问题解答
文章从GitHub上的开源项目中收集了真实世界的AI配置文件。排除已归档、禁用或锁定的仓库，从225,582个仓库的初始样本中，筛选了符合OSI标准的开源许可证的仓库，并过滤掉非用于软件的许可证（例如字体许可证），使用次数低于中位数261的许可证，提交次数少于271次（中位数）或关注者少于7个（中位数）的仓库，得到了包含49,311个仓库的最终样本。最终基于平衡项目流行度和成熟度的自定义排名方法选择了10,000个仓库。
问题解答1：开源软件项目在多大程度上采用了AI配置文件？
只有466个（5%）已经采用了文章考虑的至少一种格式。从语言使用上，AI配置文件存在于135个以TypeScript为主要语言的仓库中，其次是58个Go，58个Python，56个C#，36个Java，34个JavaScript，32个C++，29个Rust，19个PHP和9个C。
问题解答2：开源开发者在AI配置文件中提供了哪些信息，以及他们如何呈现这些信息？
AI配置文件中，代码规范和最佳实践、贡献指南、架构或项目结构等主题频繁出现，而关于故障排除或安全性的章节则较少出现。
此外，文章还注意到了写作风格的差异。写作风格可以从五个维度进行描述：描述性、规定性、禁止性、解释性和条件性。有些章节是描述性的，记录现有规范而不给出明确指令，例如，“本项目使用Linux内核风格指南。”此类陈述总结了AI智能体应了解的当前实践或配置，而不是规定行为。其他章节是规定性的，以直接命令的形式编写，指示如何行动，例如，“对所有测试数据使用工厂模式”或“遵循现有的代码风格和规范。”这种风格提供了明确的行为指导，通常格式化为简洁的要点，被解释为明确的规则。禁止性陈述也很常见，明确指示不应做什么，例如，“切勿直接向主分支提交。”这些禁令设定了界限，阐明了AI智能体应遵守的约束。一些项目在规则后添加简短解释，形成了解释性风格，例如，“避免硬编码等待，以防止CI环境中的时序问题。”此处的理由（“以防止时序问题”）为为何存在该规范提供了上下文，旨在支持理解而非仅仅要求遵守。最后，我们观察到条件性表述，规定了在特定情况下该做什么，例如，“如果需要使用反射，请使用ReflectionUtils API。”这种风格编码了情境逻辑，指定了取决于智能体任务上下文的条件性操作。
3.结论
当前项目越来越多地包含AI配置文件，为AI编码智能体提供指令和上下文。但结果表明，这种新形式文档的约定仍处于变动之中。项目在编码什么（例如，架构、规范、工作流）以及如何表达它（例如，规定性、禁止性、解释性）方面差异很大。这些风格上的变化反映了更广泛的提示写作实践，并引发了关于语气和措辞是否以及如何影响智能体的遵从度或输出质量的问题。
AI配置文件应被视为受维护的软件工件：版本化、经过评审、质量保证和测试。未来的工作需要评估其内容、结构和风格影响智能体行为和任务性能的方式，以及自动化的反馈循环如何根据观察到的结果，更新或改进这些文件。
