share-files

外观

AI 辅助开发 ​

涉及使用经历时，只说自己真正使用过的工具和场景；了解原理但没落地的内容，可以直接说明。

1. 用过哪些 AI 工具进行开发？ ​

  1. 先说实际用过的工具：例如 AI 编辑器、代码助手或对话工具，不需要罗列一堆没有用过的产品。
  2. 再说具体用途：阅读陌生代码、解释错误、写重复逻辑、补测试、整理文档，都是可以结合实际经历展开的场景。
  3. 说明自己做了什么：给业务背景、定位相关文件、补充约束，再检查生成代码，不能只说“AI 帮我全部做了”。
  4. 讲一个完整案例：原来有什么问题，给了 AI 什么信息，它产出了什么，自己怎样验证，最终效果如何。
  5. 效果用事实说话：没有测量过节省时间或性能提升，就不要编百分比。只说“减少了重复代码编写”等真实感受也可以。

可以这样组织：

我在【真实工具】里主要用 AI 做【任务】。例如【具体问题】，我提供了【代码、日志和约束】，让它先分析原因再给修改方案。最后我检查了差异，并通过【构建、测试或页面验证】确认结果。

2. Agent 的 MCP 有什么作用？ ​

  1. MCP 是连接外部能力的统一协议：让 AI 应用通过约定好的方式访问工具和数据，不是模型本身，也不是把资料直接训练进模型。
  2. 服务端暴露能力：例如搜索文档、查询订单、读取文件；应用侧客户端负责连接并调用，模型可以在应用允许的范围内选择使用工具。
  3. 常见能力分三类：Tools 是可调用操作，Resources 是可读取上下文，Prompts 是可复用提示模板。具体支持哪些，要看客户端和服务端。
  4. 实际过程是调用再读取结果：用户提出问题，应用让模型识别需要的工具，检查权限与参数后执行，再把结果提供给模型组织回答。
  5. 价值是减少重复对接：服务按统一接口暴露后，更容易接入不同的兼容应用，但仍要处理认证、版本和运行环境差异。
  6. 接入不等于无限授权：写文件、修改数据等操作需要最小权限和适当确认；工具返回的文档内容也不能直接当作新的执行指令。

参考：MCP 服务端能力。

3. AI 聊天遇到按钮、图片、数学公式等特殊格式，怎么处理？ ​

  1. 先约定消息结构：不要只靠一大段字符串猜内容。可以把消息拆成 text、image、math、action 等有明确类型的片段。
  2. 普通文字用文本或 Markdown 渲染：代码块使用代码组件；如果允许 HTML，需要严格清洗，不能直接执行模型输出。
  3. 图片用图片组件：校验 URL 和来源，处理加载失败，预留尺寸，并提供替代文字。需要鉴权的图片要使用受控访问方式。
  4. 数学公式用专门渲染器：例如 KaTeX 或 MathJax，处理不完整公式和非法语法，不开放不必要的高风险功能。
  5. 按钮映射到预先定义的动作：模型只能返回允许的 action ID 和参数，前端校验后绑定已有处理函数，不能把模型给出的 JavaScript 当按钮逻辑执行。
  6. 流式内容要先组装再渲染：网络片段可能切在一个字符、JSON 或代码块中间，先解码并积累到完整事件，不能假设一次收到的数据就是一条完整消息。
  7. 兼容异常状态：未知类型显示可理解的兜底内容，提供失败提示、停止生成和重试；有副作用的动作要避免重复执行。

下面是业务自定义结构的示例，不是 MCP 或 AG-UI 的标准字段：

json
{
  "id": "message-1",
  "parts": [
    { "type": "text", "text": "请选择接下来要做的操作" },
    { "type": "math", "latex": "x^2 + y^2 = z^2" },
    {
      "type": "action",
      "label": "查看订单",
      "actionId": "openOrder",
      "params": { "orderId": "123" }
    }
  ]
}

按钮参数通过前端校验后，服务端仍然要检查当前用户是否能查看这个订单。

参考：KaTeX 配置与信任选项。

4. 平时如何使用 Cursor 或其他 AI 工具开发？ ​

  1. 先圈定任务范围：明确目标、相关文件、技术版本和验收标准，比如“修复重复提交，保持现有接口不变”。
  2. 给足必要上下文：提供报错、复现步骤、接口示例和关键代码；不要把整个项目毫无重点地塞进去。
  3. 复杂任务先分析再改：先确认原因和方案，再让 AI 分步骤实现，避免一次生成大量难审查的代码。
  4. 小任务直接产出：类型定义、重复组件、说明文档等可以直接生成，但仍要检查是否符合项目规范。
  5. 每一步都验证：看代码差异，运行相关测试或构建；涉及页面就实际检查显示、交互和异常情况。
  6. 不满意时反馈具体证据：指出哪一步仍出错、实际结果是什么，不只反复说“重新写”。
  7. 最后由开发者负责交付：确认依赖、数据处理和边界情况，按照项目流程提交、评审和发布。

5. Agent 和普通聊天有什么区别？ ​

  1. 普通聊天主要生成回答：给出文字或代码建议，后续操作通常由人完成。
  2. Agent 可以围绕目标执行多步任务：读取资料、选择工具、执行操作、查看结果，再决定下一步。
  3. 核心是一个反馈循环：观察当前状态，执行动作，检查结果，必要时调整方案，而不是只生成一次答案。
  4. 需要明确边界：限制可用工具、可修改范围、调用次数和时间，遇到无法解决的问题要退出或交给人。
  5. 并不是越自主越好：固定业务流程用明确的工作流可能更可控，需要动态判断时再引入 Agent。

6. MCP、A2A、AG-UI 怎么区分？ ​

  1. MCP：Agent 访问工具和数据，例如调用搜索服务。
  2. A2A：Agent 与 Agent 协作，例如把分析任务交给另一个专门的 Agent。
  3. AG-UI：Agent 与用户界面交互，例如把任务进度、消息和状态变化传给前端。
  4. 可以配合但不强制一起使用：它们规范的对象不同；AG-UI 也不等于让模型随意输出 HTML 页面。

参考：A2A 说明、AG-UI 说明。

7. 怎么减少 AI 胡编和错误代码？ ​

  1. 给可验证的资料：提供真实接口、项目版本和相关文件，缺少的信息让它明确指出，不要默认补全不存在的 API。
  2. 要求结论有依据：重要判断对应代码位置、文档或测试结果，不能只看回答是否流畅。
  3. 缩小每次修改范围：一次处理一个清楚的问题，更容易定位 AI 改错了哪里。
  4. 用程序验证结果：类型检查、测试、构建和实际运行，比“再问一次对不对”更可靠。
  5. 重要操作保留人工审核：涉及权限、数据修改和发布时，检查执行对象、参数和影响范围。
  6. 不能保证完全消除错误：检索和工具能提供依据，但资料本身也可能过时或有误，需要持续评估。

8. RAG 是什么？和微调有什么区别？ ​

  1. RAG 是先查资料再回答：先从知识库找相关片段，再让模型结合这些内容生成答案。
  2. 常见流程：文档清洗、切分、建立索引；提问时检索、筛选，再把相关原文提供给模型。
  3. 通常不改变模型权重：更新资料后重建对应索引，就能让后续问答使用新内容。
  4. 微调是训练模型参数：更适合调整特定任务表现、输出风格或模式，不是更新企业事实资料的唯一方法。
  5. 权限和来源很重要：只检索当前用户有权查看的内容，保留原文出处；没有足够依据时应说明不确定。
  6. 效果要分步骤评估：先看有没有检索到正确资料，再看模型是否正确使用，不能把所有错误都归给模型。

9. AI 流式输出的前端要注意什么？ ​

  1. 先确定服务端协议：可能是 SSE、WebSocket 或普通 HTTP 响应流，前端要按对应格式解析。
  2. 分清网络片段和业务消息：一次读取可能只有半条消息，也可能包含多条，需要缓冲后按边界拆分。
  3. 中文解码要支持流式：使用流式文本解码，避免把 UTF-8 字符的字节切开后变成乱码。
  4. 减少频繁渲染：可以短时间合并更新，不必每来一个字符就重新解析整篇 Markdown。
  5. 管理消息状态：区分生成中、完成、停止、失败；用消息 ID 和请求 ID 避免多个回复串在一起。
  6. 停止不只是按钮变灰：前端终止读取后，后端还需要配合取消任务；断线重试也要考虑重复消息和重复执行工具。