近些年，已经很少写代码，并且行业也有转换（从纯软转到软硬结合），但作为一个老程序员，也算是经历了软件行业很重要的变迁，也想仔细想想到底AI对程序员意味着什么。因为这几年涉及硬件较多，还真是没有怎么关注软件受AI的影响。

        我算是简单用了些AI的编程工具，大概也明白目前的大语言模型的原理和发展过程，今天在应用层，站在程序员的角度来思考一下，应该如何应对？

一：如何理解这一轮的AI技术革命？

        如果对于这一轮AI变革，站在程序员角度，应该如何类比？

        我们都知道，程序员的开始，始于汇编语言，记得我刚毕业时，研究所的老同事还手搓过汇编指令（说是没有编译器？），那个痛苦就不用说了，我也曾经有过把 C 语言程序翻译成汇编3字符指令的经历，可以说效率极低（但把控感还是比较强的）。所以，程序员的第一轮变革，应该是汇编语言到高级编程语言，可能是Fortran，也可能是coble，或者说C语言。

        第二轮变革，差不多我就是完全身处其中了，就是面向对象编程的普及，Java，C++。一切皆是对象，面向对象编程，很快在各种快速编程语言中普及，但它也带来不少的争议，特别是执行效率上，后来，函数式语言也流行过一段时间。

        然后，中间是端语言的流行（javascript，移动开发语言），J2EE企业Bean，微服务流行，容器流行，似乎和程序员的关系也不算太大，起起伏伏，直到这一次的AI浪潮。

1.1：AI编程带来不确定性        

        这些程序的变迁的影响应该是比不上AI的产生。如果非要做最接近的类比，那就是汇编到高级语言了。但是，不得不说，AI显然没有那么简单。而汇编向高级语言的变化，更多是一种从硬件编程的脱离（脱离硬件，以更抽象的方式解决硬件操纵）。

        按照 软件教父 Martin Fowler的说法，AI 带来的不同是将确定性编码变为了不确定的编码？而不简单的是更高一层的抽象。

        如何理解不确定性？由于A I的出现，很多事情变得不确定了。传统的软件编程，我们可以理解是比较确定性的，如果输入一样，那得到的输出就是一样的，这是我们的一种共识。但是，对于大模型确并不是这样，相同的输入，每次可能得到不同的答案。这种转变，很难用抽象来理解，它更加颠覆。现在我们面对的是一个非确定性的环境，如果要使用AI，那我们一定需要改变我们的工作方式。

        也有人认为，AI 给程序带来的终极目标就是用自然语言来完成编程，是从汇编到高级语言之后的又一次褪变。算是抽象层次的提升？我开始也这么认为，但多年的软件工程化经验，让我觉得事情并没有那么简单。因为，软件并不是一锤子买卖，它是一个工程问题，有很长的生命周期。一个真正商用的软件，是有漫长的维护期的，AI 编程目前不能cover.

        我们刚才说了，大模型在编程领域带来了不确定性？如果你仔细看一下AI生成的代码，而不是只看代码的运行结果，你能注意到这一点。目前AI的水平，可以快速的生成一个原型产品，就是行业所谓的“氛围编码”，让人很振奋，快速生成了一个Demo，这作为探索是很好的。但如果要商业使用，或者在此基础上精益求精，你的麻烦就来了。

        首先，你不能盲目相信代码的输出，你需要做确定性的测试。而且，上面那种氛围编程，用来作为长期维护的成果，比较鲁莽。因为AI实现的代码，仍然需要维护和调整，面对大量生成的代码，你可以完全无法调整，只能重头来过。为什么？是因为AI代码写得很烂吗？那倒不一定，那是因为什么？是因为我们在编程时，同时会是一个学习过程，我们在构思，在不断验证，在编程的同时不断在学习，这个过程一旦没有了（大模型取代了这个环节），当你没有经过学习时，你就不知道该如何微调，修改和扩展生成的代码，你能想象，你什么代码都不改，直接让AI改动所有代码，代码能够一直安全的运行下去？你敢赌吗？

1.2：如何面对AI的不确定性？

        上面我们提到，AI生成的代码是不能完全可信的？这是什么意思？因为经常使用AI的同学，一定会发现，大模型输出的代码，在添加测试用例后，会发现它有问题。因为就目前大模型的水平，它确实会犯一些低级的错误，你可以期待在不久的将来，它完全没问题，但现在不行。你必须要遵循 “不信任，要验让” 的原则，必须要对生成的代码进行严格的测试。

        所以，AI最好能帮我们熟悉一门语言，驾驭它陌生的API，这种辅助的作用是OK的。

        对于初级开发工程师，过度依赖AI工具会对成长不利吗？

        AI到底会不会彻底取代软件开发？暂时应该不会，但它确实会带来变革，优秀的软件开发者最重要的能力不是写代码，而是明白哪些东西有写出来的价值——这本质上是一种逻辑能力，谁能掌握这种逻辑能力，谁才会成为最张的专家型通才。

        软件工程师需要有好奇心，对深度的钻研，对广度的拓展。需要有良好的沟通和理解能力，能够高效的协同，这样才能成为一个顶尖的开发者。

二：有哪些强烈推荐的AI使用场景和平台工具？

        说实话，这方面我的经验有限。我们给合ThoughtWorks的技术雷达，可以来看看，有哪些程序员值得使用的场景？

        下面，先讲讲强烈推荐的几个场景：

2.1: 利用大模型来理解遗留代码库

        这个应用场景很普遍，即使公司新成立，实际上只要不断有新员工入职，对于新员工，之前的代码就算是遗留代码，所以，基本上所有软件公司都可以在这点上受益。

        通过很多大公司的实际实践，发现 使用生成式 AI 来理解遗留代码库 可以显著加速对大型复杂系统的理解。诸如 Cursor、Claude Code、Copilot、Windsurf、Aider、Cody、Swimm、Unblocked 和 PocketFlow-Tutorial-Codebase-Knowledge 等工具帮助开发者发现业务规则、总结逻辑并识别依赖关系。它们与开放框架和直接结合LLM提示词一起使用，大大减少了理解遗留代码库所需的时间。

        借助 大模型AI  辅助理解代码非常有效，当然，具体的使用方法和效果会有所不同，如果使用 GraphRAG 这种高级的方法，可能会有一定的工作量，但是，它确实对生产力的影响是持续且显著的。所以，利用 AI 大模型来 理解旧的代码，或者让新人快速熟悉代码，这会是最推荐的AI使用方法。

        在这点上，我也有简单尝试，确实效果明显。我之前有文章讲过，如何利用GraphRAG来进行大的代码工程检索和问答。

2.2 建立团队级的AI 共享指令

        什么叫软件团队精选共享指令？此做法通过分享经过验证的高质量指令，让你能够将 AI 高效地运用于所有交付任务——而不仅仅是编码。最直接的实现方式，是像提交 AGENTS.md 之类的指令文件一样，将它们直接纳入项目仓库。大多数 AI 编码工具——包括 Cursor、Windsurf 和 Claude Code——都支持通过自定义斜杠命令或工作流共享指令。

        对于非编码任务，你可以建立开箱即用的组织级提示词库。这种系统化方法便于持续改进：每当有提示词被优化，全体成员都可受益，从而确保大家始终使用最佳的 AI 指令。

        这个很好理解，因为每个公司都会有一些个性化的业务指令，比如：快速获取某款FPGA的架构信息或设备信息。

        这个其实我并没有在公司中试用，因为公司红区（局域网）只能使用 continue插件，这个插件实在是难用，无法把类似的功能推广起来，如果自行开发插件，工作量有点大。

        但确实，这种程序级的共享，对于程序员来说，易于推广，有非常好的体验。

 2.3: 利用AI 快速生成原型

        这个上面已经提过了，目前对于网站或者前端的一个应用，A I的能力已经很强，所以，在原型生成的效率上，作为演示已经完成足够。

        但是，强烈不建议用于长期维护的商业应用，否则，维护可能会花费更多的成本。在大厂有个笑话，AI 可以编程了，但我们需要大模型代码维护工程师。

        特别是针对 GUI 的原型设计，非常有效。

        工具如 Claude Code、Figma Make、Miro AI 和 v0 使产品经理能够直接通过文本提示生成交互式、可供用户测试的原型。团队无需手动绘制线框图，即可在几分钟内生成可运行的 HTML、CSS 和 JS 工件——具备草图般的速度，却拥有真实的交互性和更高的保真度。这些“一次性”原型以快速学习为目的，牺牲了精细度，非常适合在设计冲刺的早期验证阶段使用。

        然而，较高的保真度可能导致团队过度关注细节或对上线所需工作量产生不切实际的期望——因此，明确的目标设定与期望管理至关重要。 当与用户研究结合使用时，该技术能通过将抽象想法转化为可感知的体验来加速探索过程。然而，团队应谨慎，避免让这些工具取代研究过程本身。如果运用得当，自助式原型设计能缩短反馈循环、降低非设计人员的参与门槛，并帮助团队在速度与质量之间实现健康平衡。

2.4：强烈推荐的技术框架和平台

2.4.1 LangGraph

        LangGraph 是一个用于使用 LLM 构建有状态的多智能体应用的编排框架。它提供节点和边等底层原语，以及内置功能，使开发人员能够精细控制智能体的工作流、内存管理和状态持久化。这意味着开发人员可以从一个简单的预构建图入手，并扩展到复杂且不断演进的智能体架构。通过支持流式处理、高级上下文管理以及模型回退和工具错误处理等弹性模式，LangGraph 使你能够构建健壮的生产级智能体应用。其基于图的方法确保了可预测的、可定制的工作流，并简化了调试和扩展。

2.4.2 vLLM

        如果有可能，最好自已亲手搭建私有大模型，有条件可以进一步进行微调。而搭建大模型的最佳引擎应该就是vLLM了。

        vLLM 是一个高吞吐量、内存高效的 LLM 推理引擎，可在云端或本地运行。它支持多种 模型架构 和流行的开源模型。在 GPU 平台（如 NVIDIA DGX 和 Intel HPC）上部署了容器化的 vLLM 工作节点最佳，托管包括 Llama 3.1 (8B 和 70B)、Mistral 7B 和 Llama-SQL 等模型，用于开发者编码辅助、知识搜索和自然语言数据库交互。vLLM 与 OpenAI SDK 标准兼容，实现一致的模型服务。Azure 的 AI Model Catalog 使用基于 vLLM 的自定义推理容器以提升服务性能，并将 vLLM 作为默认推理引擎，因其高吞吐量和高效内存管理而被广泛采用。vLLM 框架已成为大规模模型部署的首选方案。

2.4.3 Pydantic

        虽然 Pydantic 在 Web API 开发中最为人知，但它在 LLM 应用中也变得不可或缺。我们通常使用 从LLMs获取结构化输出 技术来管理 LLM 的不确定性。通过定义严格的数据模式，它为模型输出的不确定性提供了安全网——将自由格式的文本响应转换为确定性、类型安全的 Python 对象（例如 JSON）。这种方法通常通过 Pydantic AI 或 LangChain 实现，将潜在脆弱的 LLM 交互转化为可靠的、机器可读的数据契约。我们的团队已成功在生产环境中使用 Pydantic 从非结构化文档中提取结构化表示，确保输出符合有效结构。鉴于其成熟度、性能和可靠性，Pydantic 现在是生产级 Python AI 应用的默认选择。

除了强烈推荐的用法，还有一些建议使用，但需要做一些实验的技术和应用。

三：马上学起来，用起来的

3.1：搭建有约束的AI项目

       这有点像 GPTs的做法，当我们已经开始使用AI辅助开发工具，如：cursor，github，copilot……，我们可以为工具所管理的工程定义上下文，说明一下项目的情况，这样，大模型可以读取agent.md里面的规则。而这些约定可以保证AI的处理不会越界。

        这非常重要，因为作为团队，你肯定希望ai的行为是“有组织有纪律”，而不是随意乱改。

        比如：

        * 不允许大范围重构

        * 不允许改公共接口的签名

        * 生成代码前必须先看某个设计文档

        * 每次改完必须跑指定的测试

        * 某些目录不能改，某些文件如果修改需要同步其它地方

        这相当于给项目约定了上下文。包括构建，运行，测试项目，代码规范等都可以约定。

一些重复的话，可以这里统一约定。

        这其实算是一种高级应用，但确实它告诉你了一种正确的打开方式。要想AI辅助编程能在工作中应用，必须要有很多的约定，否则，后果是不可控的。

# AGENTS.md

> NOTE (for humans): 本文件主要是写给 AI 编程助手 / 代码 Agent 看的，
> 描述本 Verilog/FPGA 项目的规则和工作方式。请在修改后正常走 Code Review。

---

## 1. Who you are

You are an AI coding assistant helping with a **Verilog/SystemVerilog digital design project** targeting FPGA/ASIC.

Your primary goals:

1. Keep the RTL **functionally correct and synthesizable**.
2. Respect existing **interfaces, timing, and reset schemes**.
3. Help write **clean, reviewable code** plus **simulation/verification support**.
4. Follow the rules and workflows in this document.

---

## 2. Project overview

- Design type: Synchronous digital logic in Verilog/SystemVerilog.
- Target: FPGA (Xilinx/Intel) or ASIC (fill in: e.g. TSMC 12nm).
- Top-level module(s):
  - `rtl/top/top.sv` (FPGA top)
  - `rtl/core/core_top.sv` (core logic)

The design is **clocked, synchronous, reset-based**, with a clear separation between:
- **Synthesizable RTL** (`rtl/`)
- **Testbenches & verification code** (`tb/`)

……

3.2：AI 如何用于代码迁移

        代码迁移的情况是会发生的，比如：linux的程序要迁移到win平台，mac平台。        

        代码迁移的形式多种多样，从语言重写到依赖项或框架升级，几乎都不是一件小事，往往需要数月的人力投入。我们就有需求要将EDA工具迁移到windows平台，

        区别于全程交由 AI 升级，代码迁移最合理的做法是：将流程细化为可验证的小步骤：分析编译错误、生成迁移差异、反复验证测试。这种混合方法让 AI 编码智能体成为软件维护中的实用协作者。

        在迁移的项目，在节省时间方面结果不好说，但减少开发者重复劳动的潜力十分明显。因为迁移任务相对枯燥，需要细致，使用AI来处理确实是一个不错的选择。

3.3：自助式UI 原型设计

        使用 GenAI 的自助式 UI 原型设计 来描述一种新兴技术，其中工具如 Claude Code、Figma Make、Miro AI 和 v0 使产品经理能够直接通过文本提示生成交互式、可供用户测试的原型。团队无需手动绘制线框图，即可在几分钟内生成可运行的 HTML、CSS 和 JS 工件——具备草图般的速度，却拥有真实的交互性和更高的保真度。这些“一次性”原型以快速学习为目的，牺牲了精细度，非常适合在设计冲刺的早期验证阶段使用。

        然而，较高的保真度可能导致团队过度关注细节或对上线所需工作量产生不切实际的期望——因此，明确的目标设定与期望管理至关重要。

        如果运用得当，自助式原型设计能缩短反馈循环、降低非设计人员的参与门槛，并帮助团队在速度与质量之间实现健康平衡。

        这对于手机应用开发者或者说产品经理，应该是很好用。

        UX Pilot 是一款支持多阶段UX 设计流程的 AI 工具——从线框图，到高保真视觉设计，以及设计评审。它可接受文本或图像输入，并能够自动生成界面、流程和布局。其 Autoflow 功能可创建用户流程过渡，而 Deep Design 则生成更丰富、更细致的输出。

        UX Pilot 还提供 Figma 插件，可将生成的设计导出以在标准设计工具中进行精细化处理。 使用 UX Pilot 进行创意和灵感探索，在 Crazy 8’s 练习 中生成多种方案，并将项目故事列表转化为产品愿景板和Epic级别的设计概念。像 UX Pilot 这样的工具还使非设计人员（如产品经理）能够 快速创建原型 并收集早期利益相关者反馈，这在 AI 辅助设计工作流中正成为一种日益增长的趋势。

        v0 自上次在 Radar 中亮相以来已有所发展。它现在包含设计模式，进一步降低了产品经理创建和调整 自助式 UI 原型 的门槛。最新版本引入了内部模型，具有大上下文窗口和多模态能力，使 v0 能够从文本和视觉输入生成并改进 UI。另一个值得注意的新增功能是其代理模式，允许系统将更复杂的工作拆解，并为每个任务选择合适的模型。然而，这项功能仍处于早期阶段，目前收到的反馈褒贬不一。

3.4：获取结构化输出

        从LLMs获取结构化输出 是指通过对大语言模型进行约束，使其输出符合预定义格式（如 JSON 或特定的编程类）。这一技术对构建可靠、生产级应用至关重要，它能将 LLM 通常不可预测的文本转化为机器可读、确定性的数据契约。

        实现的方案覆盖从简单的提示词格式化、模型原生结构化输出，到更为健壮、借助 Outlines 和 Instructor 等工具实现的约束解码方式，这些工具通常通过有限状态机来确保输出的合法性。

        从各类文档中提取复杂的非结构化数据并转换为结构化的 JSON，以便后续业务逻辑处理。这是非常有用的场景。当然，各种模型结构的转换，应该也是相对容易的。

        其实，对于程序中的模型文件，也可以说是结构化输出文件，比如：电子元器件的Primitive的定义，非常复杂，使用LLM来做转换，是不错的选择。

3.5：搭建企业AI门户

         是一个供组织开发和运行生成式 AI 智能体和工作流以进行内部运营的平台。它提供了一个统一的环境，包括内部聊天助手、用于连接多个 LLM 的 API 层，以及用于构建与 Slack、Confluence 和 Google Drive 等系统集成的智能体工作流的工具。

        该平台强调数据主权，提供本地部署和欧盟托管选项，并符合企业合规标准。 部署 Langdock 的组织仍应密切关注数据治理，并使用AI 有害流程分析等技术来避免致命三威胁。使用者还应考虑平台的成熟度，评估他们需要的具体集成，并规划可能需要的任何自定义开发。

        这个平台好像国内用得很少，因为要收费哈。它很多功能是处理合规，安全，权限的。集成的消息工具主要也是国外的slack之类。

        如果只是搭建Agent，可以使用 difi 来搭建agent，

        如果关注聊天工具，可以使用 OpenWebUI来搭建。

        其实，我们企业内容，用一下OpenWebUI就够了，如果要快速搭建Agent，可以使用 Difi。

3.6：搭建AI的治理平台

        LangSmith 是由 LangChain 团队推出的托管平台，用于为大型语言模型（LLM）应用提供可观测性、追踪和评估功能。它能够捕获链、工具和提示的详细追踪信息，帮助团队调试和分析模型行为、监控性能回退以及管理评估数据集。LangSmith 是一个专有的 SaaS 服务，对非 LangChain 工作流的支持有限，因此主要适用于已经深度使用 LangChain 生态的团队。

        开源替代方案 Langfuse 其实也可以用。

        最有用的呢，是保证 AI 平台的质量不劣化，跟踪调用链，在线评测，Prompt管理，生产监 控和部署。有点像微服务平台的治理工具，需要保证AI平台的最优运行。

        这个呢，我觉得是企业的AI应用很成熟了，才需要考虑的事情。

        对于使用AI来处理工作流的场景，比如：使用多个Agent来完成一个固定的工作流，那对于工作流中的细节监控就非常重要了，否则无法运维。

        Datalog LLM Observability 为大语言模型和智能体应用工作流提供端到端的跟踪、监控和诊断。它将每个提示、工具调用和中间步骤映射到跨度和跟踪中；跟踪延迟、令牌使用、错误和质量指标；并与 Datadog 更广泛的 APM 和可观测性套件集成。 对于已经使用 Datadog 并熟悉其成本结构的组织而言，如果这些工作负载可以进行插桩，LLM 可观测性功能可能是一种直接了解 AI 工作负载的方法。然而，配置和使用 LLM 检测需要谨慎和对工作负载及其实现的深入理解。

        相应的APM可以让我们更好的使用流程型的AI Agent。

3.7：AI的关键服务和工具

3.8.1：MCP

       模型上下文协议（Model Context Protocol，MCP） 是一个开放标准，用于定义 LLM 应用程序和智能体如何与外部数据源和工具集成，从而显著提升 AI 生成输出的质量。MCP 专注于上下文和工具访问，这使其区别于负责智能体间通信的 Agent2Agent (A2A) 协议。

        它定义了服务器（用于访问数据库、Wiki 和服务等数据与工具）和客户端（如智能体、应用程序与代码助手）。

        它比较强大的是它的生态，越来越多的公有MCP产生。

        Context7 是一个 MCP 服务器，旨在解决 AI 生成代码中的不准确性问题。鉴于 LLM 依赖于过时的训练数据，Context7 通过直接从框架的源代码库中提取最新的文档和可运行的代码示例，并在提示时将其注入到 LLM 的上下文窗口中，从而确保 AI 生成的代码对于项目所使用的库和框架而言是准确、最新且版本特定的。

        Context7 极大地减少了代码幻觉和对过时训练数据的依赖。您可以将其配置到 Claude Code、Cursor 或 VS Code 等 AI 代码编辑器中，用于生成、重构或调试依赖于特定框架的代码。

        Fast MCP 正快速成为为 LLM 应用提供上下文和工具的标准。然而，实施 MCP 服务器通常涉及大量的设置、协议处理和错误管理样板代码。FastMCP 是一个 Python 框架，通过抽象协议复杂性并允许开发者使用直观的 Python 装饰器定义 MCP 资源和工具，从而简化了这一过程。这种抽象使团队能够专注于业务逻辑，从而实现更清晰、更易维护的 MCP 实现。 虽然 FastMCP 1.0 已经集成到官方 SDK中，但 MCP 标准仍在快速发展。我们建议关注 2.0 版本发布，并确保团队与官方规范的更新保持同步。

3.8.2：Claude Code

        这里重点推介 Claude 的编程工具，而不是cursor，github copilot，因为它的编程能力确实是最强的。

        Anthropic 的 Claude Code 是一款具备智能体特性的 AI 编码工具，它为规划和执行复杂的多步骤工作流提供了自然语言接口和智能体执行模型。

        基于命令行的编码智能体，如 OpenAI 的 Codex CLI、Google 的 Gemini CLI 以及开源项目 OpenCode 相继推出，而基于 IDE 的助手，如 Cursor、Windsurf 和 GitHub Copilot 也纷纷加入了智能体模式。但 Claude Code 在国外用户最多。

        团队不仅使用它来编写和修改代码，还将其作为通用型 AI 智能体，用于管理规格说明、用户故事、配置、基础设施以及文档。 智能体式编码将开发者的关注点从“编写代码”转移到“表达意图并委派实现”。

        这虽然能够加快开发周期，但也可能导致对 AI 生成代码的自满，从而产生人类和 AI 智能体都更难维护和演化的代码。因此，团队必须严格管理 Claude Code 的使用方式，可采用诸如上下文工程、精选共享指令以及可能的编码智能体团队等技术手段来实现。AI 编程是双刃剑，我们在后面也会提到相应的注意事项。

3.8.3: Pydantic AI

         Pydantic AI 持续证明自己是一个稳定、支持良好的开源框架，适用于在生产环境中构建生成式 AI 智能体。它基于可靠的 Pydantic 基础，提供强类型安全、通过 OpenTelemetry 实现的一流可观测性，以及内置评估工具。2025 年 9 月 4 日发布的 1.0 版本标志着其成熟度的重要里程碑。自那以后，我们发现它因简单性和可维护性而可靠且广泛采用，加入了类似 LangChain 和 LangGraph 等其他流行智能体框架的行列。 近期更新使实现模型上下文协议（MCP）服务器和客户端更为便捷，并增加了对 AG-UI 和 A2A 等新兴标准的支持。凭借其清晰的 API 和不断增长的生态系统，Pydantic AI 已成为我们团队在 Python 中构建生产就绪生成式 AI 应用的有力选择。

        Pydantic AI 主要解决了 AI 项目中数据验证、转换、管理和集成的问题，能够使开发者更高效地处理和维护数据流。它特别适用于需要高效验证和转换输入输出数据的机器学习和深度学习项目，并为模型部署、推理、训练过程中的数据处理提供了坚实的基础。

3.9：AI 设计评审（UI/UX）

        AI Design Reviewer 是一个 Figma 插件，用于进行设计审计或启发式评估，并收集对现有或新设计的可操作反馈。其审计涵盖 UX 批评、UI 不一致性、可访问性差距、内容质量和边缘案例场景。除了识别问题外，它还提供领域感知的建议，帮助团队建立共享的设计词汇和设计选择背后的理由。

        可以使用 AI Design Reviewer 来分析遗留设计——识别要保留的积极体验和要解决的负面体验——这为重新设计的 UX 目标提供了信息。它还可以作为同行评审的替代品，在开发交接之前为新设计提供早期反馈。

3.10 数据质量检查工具

        在以数据为中心的 AI 范式中，改善数据集质量通常比调整模型本身带来更大的性能提升。Cleanlab 是一个开源 Python 库，旨在通过自动识别常见的数据问题来解决这一挑战——如存在于文本、图像、表格和音频数据集之中错误标签、异常值和重复项。基于置信学习原理构建，        

        Cleanlab 利用模型预测的概率来估计标签噪声并量化数据质量。 这种与模型无关的方法使开发者能够诊断和纠正数据集错误，然后重新训练模型以提高健壮性和准确性。我们的团队在生产环境中成功使用了 Cleanlab，确认了它在实际环境中的有效性。

        在 AI 工程项目中，用它来对数据进行质量初步检查，非常重要和必要。

3.11 LLM性能评估框架

        DeepEval 是一个开源的、基于 Python 的 LLM 性能评估框架。它可以用于评估 检索增强生成 (RAG) 和其他使用框架（如 LlamaIndex 或 LangChain）构建的应用程序，也可以用于基线和基准模型。DeepEval 超越了单词匹配得分，评估准确性、相关性和一致性，在现实场景中提供更可靠的评估。它包括诸如幻觉检测、答案相关性和超参数优化等指标，并支持 GEval 创建自定义、用例特定的指标。

        使用 DeepEval 使用 LLM 作为评判者技术微调智能体输出。它与 pytest 和 CI/CD 管道集成，使其易于采用并具有持续评估的价值。对于在受监管环境中构建 LLM 应用程序的团队，由英国人工智能安全研究所开发的 Inspect AI 提供了一个替代方案，更专注于审计和合规性。

       DeepEval最有用的时机是用于自有推理引擎的性能评估。

3.12: 多模型比较实验

        LiteLLM 是一个 SDK，可通过标准化的 OpenAI API 格式 实现与多个 LLM 服务商的无缝集成。它支持多种服务商和模型，为文本生成、嵌入和图像生成提供统一接口。通过屏蔽不同服务商的 API 差异，LiteLLM 简化了集成流程，并会自动将请求路由至对应模型端点。其代理框架还包含生产级特性，如安全控制、缓存、日志记录、限流和负载均衡。随着企业将 AI 应用更深入地嵌入工作流，治理和可观测性变得尤为重要。我们的团队一直将 LiteLLM 用作 AI 网关，以实现企业级 AI 使用的标准化、安全管控和可见性。

四：哪些是不能用的，要规避的？

4.1: 过度依赖AI编程，滥用AI生成的代码

        长期使用编码助手后容易出现惰性和过度依赖的现象。 随着编码智能体推动更大范围的自动化变更，这一风险也被放大，因 AI 助手而增强的自信，往往以批判性思维能力下降为代价——我们也注意到，长期使用编码助手后容易出现惰性和过度依赖的现象。 

        尽管有充分证据显示，这类工具可显著加快开发速度——尤其是在原型开发和全新项目场景中——但研究结果也表明，随着时间推移，代码质量可能会出现下降。重复代码和代码的反复变动比预期增长更多，而提交历史中的重构活动则有所下降。

        由 AI 生成的更大代码变更集更加难以评审。正如任何系统一样，流水线中的某一环提速后，其他环节的压力也会随之增加。要在生产环境中高效安全地使用 AI，必须重新关注和强化代码质量。必须继续落实如 TDD（测试驱动开发）和静态分析等成熟实践，并将这些措施直接集成进开发流程，正如前面所讲的，需要将成功经验提取为共享指令集来使用，而不是任由滥用。

4.2: Text to SQL

        Text to SQL 利用大语言模型（LLM）将自然语言翻译为可执行的 SQL，但其可靠性往往低于预期。

        我有朋友自研了一套BI工具，是基于语义层来生成SQL的，他就断言，目前直接使用Nl2SQL是一条歧路。因为效果很差。

        例如，动态转换用户生成的查询，而输出结果被隐藏或自动化。在这些情况下，LLM 由于对数据库模式或领域理解有限，常常会产生幻觉，导致错误的数据检索甚至意外的数据修改。此外，LLM 输出的非确定性特征也使得调试和审计错误变得更加困难。

        Text to SQL 应该要求对所有生成的查询进行人工审核。对于智能化商业分析场景，应避免直接访问数据库，而应通过受治理的数据抽象语义层来实现，例如 Cube 或 dbt 的语义层；或者使用具有更强语义表达能力的访问层，如GraphQL 或 MCP。

4.3:  替代 IT的所有工作

        影子 IT，用AI取代IT的工作。AI 正在降低非专业开发人员自行构建和集成软件的门槛，使他们无需等待 IT 部门响应自己的需求。尽管我们对这种技术带来的潜力感到兴奋，但同时也开始关注到 AI 加速影子 IT（AI-accelerated Shadow IT） 的初步迹象。一些无代码（No-code）工作流自动化平台已支持对 AI API（如 OpenAI 或 Anthropic）的集成，这使得用户可能倾向于将 AI 用作“胶带”，将此前难以实现的系统集成临时拼凑起来，例如通过 AI 将聊天消息转换为 ERP 系统的 API 调用。同时，越来越多具有自主 Agent 能力的 AI 编码助手，甚至允许仅经过基础培训的非技术人员创建内部工具应用。
        这些迹象呈现出类似于电子表格（Spreadsheets）当年迅速扩散的特征：虽然为企业关键流程提供了快速解决方案，但在长期运行后往往会造成规模更大的技术债（Tech Debt）。如果不加管控，这种新型影子 IT 将导致未经治理的应用程序激增，安全隐患加剧，数据分散在不同系统内。

        这些失控的情况，可能不是企业希望看到的。所以，需要谨慎将IT的事情全权委托给AI处理。

4.4: API 直接变成 MCP

        MCP现在被广泛使用，上面我们也有推卧龙，但是，将内部 API 直接无缝转换为 模型上下文协议（MCP）。并不建议直接进行这种天真的API到MCP转换。API 通常是为人类开发者设计的，往往包含许多细粒度、原子性的操作；如果让 AI 代理串联调用这些操作，可能会导致Token过度消耗、上下文污染，以及智能体性能下降。

        这些 API（尤其是内部接口）常常会暴露敏感数据或允许执行危险操作。对于人类开发者，此类风险可以通过架构模式和代码审核来缓解，但如果将 API 直接暴露给通过 MCP 协议集成的智能体，则无法可靠地阻止自治 AI 智能体误用这些接口。因此，我们建议针对智能体工作流，专门设计并构建安全的 MCP 服务器架构，在现有 API 基础上进行适配。

        简单来说，API不等于MCP，不能简单的把所有API变成MCP。

好了，今天就啰嗦这么多，但感觉还是没有达到我预期的效果，仍然没有把程序员和AI的关系讲清楚，只是罗列了一堆大家应该掌握的内容，有空再持续补充。

        参考资料：ThoughtWorks 技术雷达图