前几天我在司内论坛的一个问答中提到了要写一个拉取网络文章文本的 skill，昨天我实现了之后也就开始好奇起 Skills 的底层原理了——相比起各种花里胡哨的 agrnt 应用，我一直以来都很对大模型在纯粹的 HTTP 交互层面是如何交互的更感兴趣。 我们知道，大模型只会对话，聊天，所谓的工具调用也只不过是特化的聊天功能而已。但是各种天花乱坠的 skills，是如何在底层的 HTTP 中，与大模型——这个只会嘴遁的工具交互的呢？
我们以为自己在给 AI 套缰绳。写 Spec、定 Rule、设 Eval、调 Prompt——每一次按下回车，都像是在多拧紧一圈对它的控制。但如果你在某个深夜回头看过自己写下的那份 project.md，你会发现一件让人后背发凉的事——那根缰绳的另一头，系着的不是 AI，是你自己。你手里攥着的不是缰绳，是一面镜子。它正在你每一条 CI 规则、每一次 Code Review、每一份 Spec 里，悄悄把三百年来从未被言说过的你——写成另一种智能能够读懂的文本。这是一场已经开始、躲不过去、并且没有回头路的革命。你唯一的选择是——弄清楚它正在把你推向哪里。
这篇文章讲的事情不复杂：我们用两个 Git 仓库 + AI 编码助手 + 几个 Shell 脚本，替代了传统项目管理中至少 80% 的人肉操作——催周报、搬数据、画图表、对齐进展、写汇报。没有搭平台，没有买 SaaS 工具，就是 Markdown + Shell + Python + AI 的朴素组合。你有没有想过，为什么你的团队每周都在重复这些事情：催 N 个业务线的同学交周报，催到第三遍还是有人没交把即时通讯文档里的零散信息搬到某个在线表格里，格式不统一，粒度随意手动更新一个看板的进度条，更新完发现另一个团队的数据已经过期了从数据平台上捞一堆 SQL 结果，贴到 PPT 里变成"效能报告"开周会的时候发现大家看的信息版本不一样说白了，这些事情的本质就是信息搬运。从人脑搬到文档，从文档搬到看板，从数据仓库搬到图表。每次搬运都有信息损耗、都有延迟、都需要有人盯着——而且这个人通常是团队里技术最好、最不应该做这些事情的人。我们的做法是：让 AI 做搬运工，人只做输入和决策。
本文介绍了一个面向数据开发团队的端到端数据验证 Agent Skill——verify-data。该技能通过自然语言交互，自动完成从表结构获取、基准表发现、代码逻辑分析、验数 SQL 生成、执行到报告发布的全流程，将传统手工验数从"手写多条 SQL + 人工比对"升级为"一句话触发 + 评审级证据输出"。文章从背景痛点、核心架构与能力、实战场景、设计原则、踩坑经验、当前优势与挑战等方面系统展开，并在最后给出未来演进方向的思考，希望为同样在做数据质量保障和 Agent 工具落地的开发者提供参考。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
本文围绕一个核心问题展开：如何让AI助手从“输出文字”进化到“生成界面”？我们基于Google A2UI协议，自研了Vue渲染器和 Agent 完整工具链，形成了一套完整的生成式UI体系。文章将详细阐述Runtime Schema装配、双重校验机制、SSE双通道输出、Wrapper组件扩展等关键设计，为构建标准化、可复用的AI交互界面提供参考。
过去几年，AI 在编码领域的角色一直在升级：从写几行补全、回答几个语法问题，逐步走向能独立完成子任务，甚至端到端完成一个开发需求。 在这条演进路径上，我们尝试做了一个小小尝试：把团队的部分代码质量治理，交给“数字 SRE 员工”，让人类只在关键环节兜底审核，并借此跟大家分享一些个人经验。
“涌现”不是一个玄学词。在复杂系统里，涌现指的是：系统整体表现出某种单个组成部分并不具备、也没有被直接写死的性质。这种性质来自大量局部单元之间的交互。水分子本身没有“波浪”，神经元本身没有“意识”，单只蚂蚁没有“城市规划”，但当它们以某种密度、规则和反馈连接起来，整体就会出现新的层级。大模型的智能，本质上也可以这样理解。单个 token 没有智能，单句话也没有智能。但当海量文本、语义结构、知识关系、推理痕迹、行动描述被压缩进一个语言模型里，模型通过预测下一个词学到的就不只是语法，而是世界在语言中的投影。它没有被显式编程去“理解业务”“做产品判断”“写代码”，但在足够规模的语言训练之后，这些能力从语言结构中长了出来。这就是第一层涌现：文字规模足够大，语言模型中涌现出智能。这篇文章想讨论的是第二层：当智能体之间的上下文交互足够充分，群聊里会不会长出更高质量的协作判断和决策。
