零、题外话#

LLM 基础#

大语言模型（LLM，Large Language Model）本质上是基于深度学习的语言模型，是传统 Language Model 在数据规模、参数规模和训练方式上的扩展。它通常基于 Transformer 架构，通过在海量文本数据上进行训练，学习语言中的统计规律，从而能够根据上下文预测下一个 token，实现文本生成、理解等能力。像 ChatGPT、Qwen、DeepSeek 这些产品，本质上是基于 LLM 构建的应用系统，LLM 是它们的核心能力模块。
从原理上讲，LLM 并不具备真正的“理解”或“思考”，而是通过学习概率分布，在给定上下文的情况下生成最可能的输出，因此可以表现出类似推理和对话的能力。

把文本切成 token，转成向量，通过 Transformer 结构理解上下文关系，然后根据已有上下文预测下一个最可能出现的 token，连续预测就生成了回答

1. LLM 的核心架构：Transformer#

Transformer 几乎是当前所有大语言模型的基础架构，其核心在于能够通过“自注意力机制（Self-Attention）”来建模文本中不同位置之间的关系。相比传统的 RNN/LSTM 只能顺序处理数据，Transformer 可以同时处理整个序列，并让每个 token 动态关注上下文中最相关的信息，从而更好地理解语义和长距离依赖。

RNN/LSTM 是一种处理序列数据的神经网络，其核心目标是当前输出既看当前输入也参考之前的信息

相关概念：

• Self-Attention 的本质是：计算“当前词与其他词的相关性”，再进行加权融合
• Multi-Head Attention 让模型能从多个角度（语法、语义、指代）理解同一句话
• Transformer 可以并行计算，训练效率远高于 RNN
• 多层堆叠后，模型从“词级别”逐渐抽象到“语义级别理解”

2. LLM 训练机制#

LLM 的学习过程本质是通过大量文本数据训练一个“预测下一个 token 的模型”。在训练中，模型会不断看到上下文，并尝试预测接下来最可能出现的词，让预测越来越准确，从而逐渐掌握语言规律、知识和表达方式。（所以上下文对于压榨模型预测能力的帮助很关键）
相关概念：

• 训练目标是条件概率：P(next token | context)，不是理解世界本身（似乎是世界模型做的事？）
• 预训练阶段让模型学到语言模式和知识分布
• 指令微调（SFT）让模型学会“按人类方式回答问题”
• RLHF 进一步优化回答的有用性和安全性
• 本质上模型学到的是“语言模式中的知识”，而不是显式知识库

3. 如果说LLM 是预测，那么为什么具备推理能力？#

LLM 的推理能力并不是传统意义上的逻辑推理，而是来源于它在训练数据中学习到大量“推理过程的语言模式”。当遇到类似问题时，模型会生成类似的逻辑推理步骤，从而表现出“会思考”的效果，这种能力在模型规模足够大时会显著增强，被称为“涌现能力”

涌现能力：模型的涌现能力是指，当模型参数规模、训练数据和训练强度达到一定水平后，会突然表现出一些在小模型中不明显甚至没有的能力，比如复杂推理、上下文学习、代码生成和任务规划等。它体现的是模型能力随规模增长出现的非线性提升，也就是一种量变引起质变的现象

相关概念：

• 推理能力本质是“模式匹配”，而非真正逻辑推理
• Chain-of-Thought（思维链）可以显著提升复杂问题的正确率

4. LLM 的核心能力边界#

LLM 本质上仍然是一个概率模型，它并不真正理解世界，也不具备验证事实或执行操作的能力，而这些限制在实际工程中都需要通过系统设计来弥补
ps:

• 幻觉：也就是模型会生成看起来合理但错误的内容
• 模型无法访问实时数据，除非借助 mcp 等工具进行网络搜索实时信息（315 曝光了 GEO 的 AI 投毒，实时搜索有时也不靠谱）
• 模型的上下文窗口有限，长对话或者长文档情况下可能会触发压缩导致丢失一些关键信息
• 每次与模型的对话本质是独立的，需要人为维护记忆

5. Agent 作用#

Agent 的出现，本质上是为了弥补 LLM 在“行动能力”和“系统能力”上的不足。LLM 本身只是一个语言推理模型，无法直接访问外部世界获取实时信息，而 Agent 通过将 LLM 与工具、数据和流程结合，使其能够完成真实任务。

• Agent 将 LLM 与工具（API、数据库）连接起来
• Agent 引入流程控制，使任务可以拆解执行
• Agent 可以引入外部知识（RAG）解决幻觉问题
• 本质上是“LLM + 工程系统”的组合

6. LLM 在 Agent 中的角色#

担任“决策中枢”的角色，负责理解用户输入、规划任务、决定是否调用工具，以及生成综合上文所得出结果的自然语言输出，具体执行过程由外部系统完成

7. Agent 如何弥补 LLM 的缺陷#

在真实工程环境中，Agent 系统会引入各种机制来补足 LLM 的短板

• RAG （检索增强生成）：使用外部知识库减少幻觉
• Tool Calling：让 LLM 具备调用 API 的能力
• Memory：通过对话历史或向量存储实现“记忆”
• Workflow：通过流程编排支持复杂任务
• 多 Agent 写作：不同 Agent 分工完成任务

LLM 和 Agent 的关系也可以理解为 LLM 是一个通用推理引擎，而 Agent 是将推理能力嵌入到具体系统中的工程实现，简单来说就是 LLM 提供智能，Agent 提供能力边界内的可控执行

一、Agent 基础概念#

本质是“LLM + 工具 + 规划 + 记忆 + 反馈闭环”，让模型从单纯的文本生成器变成能够执行复杂任务的智能系统

Agent = LLM + 规划（Planning）+ 记忆（Memory） + 工具 （Tool Use）

基本流程通常是：先理解用户目标，然后拆解任务，选择合适的工具执行动作，再根据工具返回结果进行观察和判断，如果任务还没完成，就继续迭代，直到生成最终结果。这个过程可以概括为 Think、Act、Observe、Repeat。

从工程角度看，Agent 一般由 LLM、Tools、Planner、Memory、Executor 和 Observation 机制组成。其中 LLM 负责理解、推理和决策，Tools 负责连接外部系统，Memory 负责保存上下文和历史信息，Executor 负责执行工具调用和控制流程。

但 Agent 也存在不稳定问题，比如工具选择错误、参数生成错误、任务循环失控、幻觉和权限风险。因此真实业务落地时，通常不会完全让模型自由执行，而是会结合 Workflow、Tool Schema、权限控制、日志追踪、人工确认 和评测机制，提升系统的可控性和可靠性。

Agent、Workflow、多智能体有什么区别？#

三者主要区别在于自主性和复杂度

• Workflow 是预定义好的流程，系统按照节点和边执行，优点是稳定、可控、容易测试和追踪，适合文档处理、规则校验、报告生成这类流程明确的任务
• Agent 是由大模型根据上下文自主决定下一步，比如是否调用工具、调用哪个工具、是否需要追问用户获取更多信息，适合**用户输入开放、任务路径不固定的场景**，比如智能客服、企业办事助手、业务查询助手等场景
• 多智能体则是把复杂任务拆分成多个不同角色的 Agent 协作，比如检索 Agent、分析 Agent、执行 Agent、审核 Agent，适合复杂分析、代码扫描、人才匹配这类多阶段任务，但它的成本、延迟和调试难度也更高

二、主流核心范式#

（一） 核心逻辑#

1. ReAct#

ReAct（Reasoning + Acting）是一种将推理和行动相结合的 Agent 范式。在这个范式中，Agent 会：

• 思考（Reasoning）： 分析当前情况，决定下一步应该做什么
• 行动（Acting）： 执行工具调用或生成最终答案
• 观察（Observation）： 接收工具执行的结果
• 迭代： 基于观察结果继续思考和行动，直到完成任务

而这个循环让 Agent 能够：

• 将复杂问题分解为多个步骤
• 基于中间结果动态调整策略
• 处理需要多次工具调用的任务
• 在不确定的环境中做出决策

2. Two-Stage ReAct 循环#

当我们向大模型发起一次普通的 API 请求时，它只能顺着当前的上下文，凭借概率直觉“一口气”把答案生成出来。如果问题比较复杂，它无法在生成第一个字之前，在脑海里预演几十步的完整计划

提示词工程的破产与驾驭工程的解法

为了激发大模型的“慢思考”，学术界发明了 Chain of Thought（思维链，CoT） 技术，在提示词里加上一句“Let’s think step by step”，相当于是给大模型一张“草稿纸”，让它在输出最终答案前，把中间推理过程写出来
但在 Agent 的工具调用场景下，AI 工程师在构建长程 Coding Agent 时，发现一个致命规律：

“When tools are available, models tend to act quickly rather than think deeply.”
（当工具可用时，模型倾向于迅速采取行动，而不是深入思考）

尽管已经在系统提示词中写了“请仔细规划，然后调用工具”，但大模型往往会无视这句话。只要它在上下文的 Schema 里看到了诱人的 bash 或者 edit 工具，它的预测概率就会瞬间坍塌，转而生成一段 JSON 参数去调用工具
提示词管不住它的“手”，就用架构锁住。驾驭工程（Harness Engineering）给出的解法是： 机制决定行为
在每一次大模型采取行动前，Harness 引擎会向它发起一次没有附带任何工具 Schema 的纯文本 API 请求。那么在这个没有工具诱惑的“小黑屋”里，模型就只能乖乖地输出一段纯文本的深度推理与规划
等它想清楚，Harness 再把这段推理记录追加到上下文中，然后再发起第二次附带工具的请求让其执行，这就是 Two-Stage ReAct 循环

通过物理层面的隔离，将 Agent 的“谋”与“动”彻底分开了。

3. ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？#

💡我理解的这三者是 Agent 开发中最主流的三种设计范式，核心区别在于「决策和执行的关系」
ReAct 是边想边干，走一步看一步，单步迭代实时调整，灵活度最高；
Plan-and-Execute 是先想全再干，先定完整计划再分步执行，适合长流程复杂任务，不容易跑偏；
Reflection 不是独立的完整流程，而是给前两者加的「检查修正 buff」，用来提升输出质量
实际选型就看三个维度：任务复杂度、流程确定性、输出质量要求，新手入门首选 ReAct，复杂任务用 Plan-and-Execute，高要求场景再加 Reflection

Reflection
Reflection 不是一套独立的完整流程，而是给 ReAct、Plan-and-Execute 加上的「buff」，其不改变原本的做事流程，而是在原本的基础上加上一层「自我检查、自我修正」的环节
也就是加上「生成­­­➔评估­­­➔改进」的闭环，专门设置了一个独立的检查环节，判断当前输出有没有问题、达不达标，不达标就重试或调整策略，直到符合要求为止

三、常用开发框架#

四、Function Calling/Tool Calling#

五、MCP 工具#

1. 什么是 MCP#

MCP （Model Context Protocol）是一个开放标准协议，定义了 AI 与外部工具/数据源之间的通信方式
一般由第三方服务平台如 Github、飞书、Slack 等提供，以方便任意外部系统的能力能够快速接入 Agent 系统中被 AI 调用

主要解决「模型接工具太碎片化」的问题
在 MCP 出现之前，每接一个新工具都要单独写集成代码、处理认证、适配格式，而 MCP 的思路就是把这件事标准化：工具提供方按协议实现一个 Server，任何支持 MCP 的 AI 客户端就能直接接进来，一次实现到处复用

协议定义了三类能力：Tools 用于执行有副作用的操作，Resources 是只读数据，Prompts 是提示词模板，底层通信使用 JSON-RPC 2.0

2. 基本架构：Host ­­­➔ Client ➔ Server#

MCP 采用三层架构：

• Host： AI 应用（如 Claude Code），负责协调多个 Client
• Client： Host 内部组件，每个 Client 维护与一个 Server 的专属链接
• Server： 独立进程，向 Client 暴露工具（Tools）、资源（Resources）、提示词模板（Prompts）
  所有通信基于 JSON-RPC 2.0 协议，与传输方式无关

3. MCP 调用机制#

Server 端：用 JSON Schema 声明工具#

六、Agent Skills#

1. 基础概念#

Prompt：AI 的基础指令，可以分为普通提示词和结构化提示词。
Command：把较长的提示词固化为文件，用短命令进行快捷调用。
System Prompt：高优先级的系统指令，AI 对它的遵循度通常更高。
Metadata：提示词文件的描述信息，用来帮助匹配合适的 Skill。 它的作用包括节省 Token、按需匹配。
References：用于存储参考资料，支持渐进式信息披露。
Script：用于存储可执行代码，实现本地操作、文件导出等能力。

2. Skill 核心#

定义#

Skill 可以理解为： 可动态加载的系统提示词文件夹。

组成#

一个 Skill 通常由以下部分组成：

• skill.md 主文件

• References

• Script

3. 工作流程#

Skill 的基本工作流程如下：

1. 把 Skill 放入 skills 目录，完成安装

2. 客户端发送用户需求

3. 加载 Skill 的元数据，供大模型进行匹配

4. 加载对应的 Skill 作为系统提示词

5. 按需读取参考资料或执行脚本

6. 大模型输出最终结果

4. 核心区别#

Skill vs MCP#

MCP：
AI 操控外部工具的协议。

Skill：
更偏向“工具使用的经验和流程”，也就是告诉模型在什么场景下、按什么方式去使用这些工具，类似经验包。

Skill vs Workflow#

Workflow：
设计时就固定好的流程，属于规则编排。

Skill：
由大模型驱动，执行方式更灵活。
或者简单来说是大模型驱动的 workflow。

5. 总结#

Skill 本质上是一套可以被动态加载（渐进式披露）的提示词与辅助资源机制，它不仅包含提示信息，还可以附带资料和脚本，让大模型在合适的场景下更灵活地完成任务。

七、RAG#

1. RAG 是怎么提升生成质量的？#

RAG 的核心不是“检索 + 拼接”，而是把模型从纯参数记忆转成“参数记忆 + 外部证据”的混合生成。它通过召回相关文档，把当前问题所需的事实、背景和证据放进上下文里，降低幻觉概率，也让答案更可追溯。真正好的 RAG 不只是召回准，还要能控制切片粒度、排序质量、证据覆盖和最终引用一致性，否则检索到了也不一定能用好

文档解析 → 切分 Chunk → 向量化 Embedding → 存入向量数据库 → 用户提问 → 问题向量化 → 相似度检索 → 可选重排 Re-rank → 拼接 Prompt → 大模型生成回答

RAGRAG，就是Retrieval-Augmented Generation 检索增强生成，本质上是先检索后生成
可以分为 4 个方面来讲：

第一、补充模型参数里没有的知识#

大模型训练的知识主要来自训练数据，存在知识截止（无法实时获取新知识）、领域覆盖不足（训练数据中没有的领域不熟悉）。而 RAG 可以在用户提问时，从企业知识库、文档库、数据库里动态检索相关内容，然后把这些内容作为上下文提供给模型，那么模型回答时就不再只依赖训练数据参数记忆，而是结合外部事实来生成回答内容

第二、降低幻觉#

纯大模型回答时，遇到一些不确定的问题时也可能“看起来很合理地编”，RAG 给了大模型参考依据，只要召回内容足够相关、足够干净，模型有了相关依据就能够围绕证据作答，而不是自由发挥回答一些看似合理但实际不搭边的内容

第三、提升时效性和领域适配能力#

比如公司制度、产品文档、接口说明、最新政策，这些内容变化快，不适合频繁微调。RAG 只需要更新知识库，就能让回答尽可能的跟上最新内容，主要是企业知识问答、客服、内部助手这些使用场景

对于时效性来说，实时搜索的 MCP #五、MCP 工具 也可以做到，二者区别是什么？

实时搜索的 MCP 更多的是让模型去“现场查”，而 RAG 更像是给模型一套提前建好的知识底座；前者强在开放世界实时性，后者强在私域知识、稳定性、可控性，更多的是互补的关系
真正上线时通常不是二选一，而是路由融合：判断问题属于内部知识还是外部实时信息，再决定走 RAG 还是 MCP 搜索链路

第四、增强答案可解释性和可控性#

RAG 的答案通常能追溯到召回的文档片段，可以做引用、溯源、权限控制，也方便后续评估和优化，这在工程上很重要，因为可解释性比“偶尔答对”更有价值，说明其回答不完全是黑盒

为什么有了 RAG，效果还是不好？#

RAG 也不是接上知识库就一定有效，它中间有很多损耗点

1. 没召回到
   用户问法与文档表达不一致，embedding 召回不到相关内容
2. 召回到了，但召回错了
   相关性不够高，噪声太多，模型被干扰
3. 切块有问题
4. 上下文组织不好
5. 问题本身不是单跳检索能够解决的

2. 如何评价一个 RAG 系统是否 work？#

3. Chunk 切分#

核心环节

大模型上下文有限，向量检索也不是按整篇文档检索，而是按小段文本检索，所以需要将文档切成 chunk

Chunk 切分目标，一个好的 chunk 要满足：单个 chunk 内语义完整，长度适中，方便被检索，也方便模型理解

常见的切分方式#

1. 按固定长度切分：实现简单但不够智能
2. 按标题层级切分：适合制度文档、产品手册、技术文档，适合企业知识库
3. FAQ 问答对切分：把一个问答对作为一个 chunk
4. 语义切分：按语义边界切，优点是语义完整，缺点是实现较复杂

4. Embedding 向量化#

把文本转换成向量，存入向量数据库
而向量数据库负责存储 chunk 的向量、文本内容和 metadata，并支持相似度检索

5. RAG 的完整链路#

RAG 的完整链路可分为离线入库和在线问答两部分

1. 离线阶段
   首先要采集文档，比如 PDF、Word、FAQ、制度文档等；然后做文档解析、清洗，保留标题、章节、页码、来源等结构信息；接着根据文档类型做 chunk 切分，比如 FAQ 按问答对切，制度文档按标题层级切。长文本按语义段落切；然后给 chunk 加 metadata，比如文档名、章节、版本、权限、更新时间；最后通过 embedding 模型把 chunk 向量化，存入向量数据库或检索系统
2. 在线阶段
   用户提问后，可以先做 query rewrite 和意图识别，把口语化问题改写成适合检索的问题；然后通过向量检索、关键词检索或混合检索召回候选 chunk；再通过 rerank 对候选结果重排，选择最相关的内容拼接进 prompt；最后让大模型严格基于上下文回答，并返回引用来源

落地时也需要关注几个问题：chunk 粒度是否合适、召回是否命中正确资料、rerank 是否提升排序、prompt 是否限制幻觉、答案是否可溯源，以及是否有 badcase 评测集持续优化

RAG 真正难点不在于调一个向量库，而在于文档质量、切分策略、检索质量、上下文构造和业务流程融合

Prompt Engineering 主要解决“怎么问模型”；
Context Engineering 解决“给模型什么上下文”；
Harness Engineering 更偏工程治理，解决“怎么把模型稳定、可控、可验证地接入研发流程或业务流程”

八、Prompt Engineering#

模型有没有听懂你在说什么？

• 角色设定
• 风格约束
• 分步引导
• 拒答边界
• 输出格式
• few-shot 示例
  为什么有效？Prompt Engineering 本质上不是“命令模型”，而是塑造一个 局部概率空间，语言设计！

Prompt 主要解决表达问题

1. Prompt 擅长什么？不擅长什么？#

擅长：

• 澄清任务
• 约束输出
• 激发模型已有能力
  不擅长：
• 凭空补齐缺失知识
• 管理大量动态信息
• 处理长链路状态变化

九、Context Engineering#

模型有没有拿到足够且正确的信息？
Context 不只是几段背景资料，而是所有会影响模型当前决策的 信息总和 （RAG？）

• 系统规范
• 安全约束
• Agent 结果
• 用户输入
• 历史对话
• 检索结果
• 工具返回
• 当前任务状态
• 中间产物
• …
  也可以说 prompt 只是 context 的一部分

上下文优化，不只是“给更多”，而是：

• 按需给： 只提供当前任务必需的信息
• 分层给： 从元信息到详细内容的渐进展开
• 在正确时机给： 在触发特定能力时动态加载

0. 零零散散#

Anthropic 官方的 Prompt best practices 讲得很明确：要 clear and direct，明确输出格式和约束，要把步骤写成顺序化指令；few-shot examples 能明显提高一致性（在对输出格式有要求或者需要从对话中提取信息等场景下很有用）；复杂提示可以用 XML tags 把 instructions、context、input 分开，减少歧义。

Codex 的官方 Prompting 也强调：一是让 AI 能验证自己的工作，比如提供复现步骤、校验步骤、lint 和 pre-commit 检查；二是复杂任务要拆成更小、更聚焦的任务
常见结构：角色设定、任务目标、规则约束、输出格式、Few-shot 示例

要任务结构化：把目标、上下文、约束、输出格式、验收标准、验证步骤和失败处理策略写清楚，让模型更像在执行一份工程任务单，而不是自由发挥

任务目标：
你要完成什么功能 / 修复什么问题

项目上下文：
技术栈、模块位置、相关文件、接口约束、已有实现模式

限制条件：
不要改哪些目录 / 不要引入新依赖 / 保持接口兼容 / 遵循现有代码风格

输出要求：
先给计划，再实施；修改后列出变更文件；说明风险点

验收标准：
哪些测试需要通过 / 哪些命令要执行 / 什么结果才算完成

失败策略：
如果信息不足，先列问题或先给最小可行方案，不要直接大改

1. Skill 和 Prompt Engineering 的区别是什么？#

Prompt Engineering 解决的是“这次的任务怎么描述得更清楚”
Skill 解决的是“这类任务以后反复出现，能不能直接复用”
Prompt 更像是一次性的任务说明书，强调目标、上下文、约束、输出格式
Skill 则更像是一个 可复用 SOP 强调触发条件、执行步骤、输入输出和验证动作
PS：

• “帮我补一组单测”是 prompt
• “给 reservation 模块新增接口时，按 controller/service/test 三层结构生成代码并跑指定测试”就可以沉淀成 skill

问题：就算信息给对了，模型也不一定能 稳定执行对 ，在长链路中发生各种意外
提示词优化意图表达，上下文优化信息供给，而在复杂任务执行侧怎么去解决连续行动中的不确定性，如何去监督它、约束它、纠偏它，就引出了 Harness Engineering

十、Harness Engineering#

如果说提示词和上下文是怎么让模型更会想，而驾驭工程则是如何让模型在真实执行里，能不能持续做对？以及怎么让模型别跑偏，跑得稳，出了错还能拉回来

• 任务怎么拆
• 状态怎么管
• 关键步骤怎么校验
• 失败以后怎么恢复

一个成熟的 Harness 一定要包含的三件事：

• 约束： 哪些能做，哪些不能做
• 校验： 输出前怎么检查
• 恢复： 失败以后怎么重试、切路径、回滚到稳定状态

如何在工程上实现兜底机制？#

兜底机制不能只写一句“失败后重试”，应该按失败类型分层。比如模型层可能超时、限流、返回格式错误；检索层可能无结果、召回低相关；工具层可能参数错误、权限失败、下游服务不可用；生成层可能答案无引用或不符合 schema。而不同错误要有不同兜底机制，不能统一重跑。
工程上应该做三层兜底

• 第一层是重试，比如超时、临时网络错误可以指数退避重试
• 第二层是降级，比如大模型失败就切小模型，rerank 失败就用召回分数排序
• 第三层是安全返回，比如证据不足就拒答，工具失败就返回部分结果和失败原因

十一、Loop Engineering#

十二、Vibe Coding#

1. 举一个“Skill+Prompt+验证”的完整案例#

“新增标准 REST 接口”的案例

• 第一步，先做项目级的持久化说明，比如技术栈，各模块的责任，文件变更之后执行 mvn test，输出时要列出修改文件和风险点等等
• 第二步，想新增接口这种肯定不会是单例，那么我们就可以将其抽离出 skill，适用范围可以限定在某个模块，比如 reservation（似乎也可以限定整个项目，然后 skill 下再做路由分到不同的模块）。Skill 里定义（这部分可以根据具体新增接口属于哪个模块特殊处理）：
  • 先阅读某个模块现有的 controller/service 结构
  • 按现有风格生成 DTO
  • 补参数校验
  • 补最小单测
  • 跑指定测试命令
  • 输出变更和验证结果
• 然后在具体任务中，再给 prompt——新增一个查询预约详情接口，要求复用现有响应体风格，不改公共库，不引入新依赖，先给计划再编写代码
• 最后通过 hook 或固定流程，让它改完自动 format、lint、test 等
  更多的不是零散的使用 AI，而是搭一个可复用的 AI 开发流水线

2. Vibe Coding 会带来哪些风险？怎么控制？#

Vibe coding 的正确用法不是“放权给 AI”，而是“让 AI 在受约束、可验证的流程中发挥最大生产力”

第一类是 代码质量风险 ，例如看起来合理但是边界条件没有覆盖
第二类是 安全和权限风险 ，例如误删文件、执行高风险命令、引入不安全实现
第三类是 上下文与数据风险，例如把不该暴露的信息带入上下文
第四类是 团队一致性风险，如果每个人都随意 prompt，输出质量会很不稳定
在控制手段上，我觉得：

• 项目级 instruction 统一默认规范
• Skill 统一高频任务 SOP（Standard Operating Procedure，标准作业流程）
• Hooks 控制高风险操作和验证动作
• MCP 只接必要上下文
• 关键逻辑必须要 human in the loop

3. 如何评估 AI 生成代码的质量？遇到 AI 代码有问题时怎么处理？#

可以从 4 个维度快速 Review

1. 逻辑正确性（边界条件、异常处理）
2. 性能与安全性（N+1 查询、注入风险、内存泄漏）
3. 可维护性（命名、注释、是否符合团队开发规范）
4. 业务契合度

A.怎么保证 AI 生成代码可控？#

可以分成生成前、生成中、生成后三个阶段。

• 生成前先明确工程规范、上下文和验收标准；
• 生成中通过 Rule、Skill、示例代码和分层边界约束模型输出；
• 生成后通过 AI CR、单测、接口测试、覆盖矩阵和人工 Review 验证。
  AI 负责提高覆盖率和执行效率，人负责判断优先级、业务正确性和最终风险。

TDD/SDD#

现在与将来的 TDD / SDD#

在 vibe coding 时代，TDD 和 SDD 和传统开发的“先写测试文档 / 先写设计文档”似乎已经不一样了
它们更多的是给 code agent 加上护栏

SDD 让 AI 知道“要做什么、边界是什么、按什么规则做”；TDD 则负责验证 AI“做出来的东西到底对不对”

传统开发里人是主要编码者，测试和文档更多的是辅助，而现在则更多的是限制或者说边界设定，也就是 规格驱动 + 测试验证 + AI 执行

SDD 防止 AI 一开始就写偏（提供任务边界）；TDD 是防止 AI 写完之后自以为对（提供反馈回路）

同时，

spec清楚 ≠ 实现正确
test通过 ≠ 需求完整

SDD 能尽量减少“方向错”，但不能完全避免“实现错”，所以需要 TDD
TDD 能证明某些行为对了，但不能证明需求完整，所以需要 SDD

SDD 负责“需求和边界完整”，TDD 负责“实现行为正确”

TDD#

传统 TDD：
人写测试 → 人写实现 → 人重构

AI 时代 TDD：
人定义行为和边界 → AI 生成测试初稿 → 人审测试 → AI 写实现 → 自动跑测试 → AI 修复 → 人验收

A/的 Claude Code 最佳实践也体现了这个思路：不要只说“修复 XX bug”，而是描述具体症状、位置和“什么算修好”，例如让 Claude 先写一个能复现问题的 failing test，再修复它
当然重点不是“让 AI 随便生成一堆测试”，而是：
人必须先定义关键行为，尤其是正常路径、异常路径、边界条件和业务不变量
简单来说就是

SDD#

SDD 指的是 Spec-Driven Development，规格驱动开发

当然也不是单纯写“系统设计文档”，而是要把 需求、边界、约束、架构决策、验收标准写成 AI 能持续读取和执行的上下文
Github Spec Kit 官方文档把 SDD 描述为：在构建之前先定义要构建什么，把 specification 放在 AI-assisted development 的重心，通过 Spec ­­­➔ Plan ­­­➔ Tasks ­­­➔ Implemen 这样的流程，给 code agent 提供结构化的上下文，而不是临时、零散的 prompt
所以 SDD 的核心不是写很多文档，而是：

不要让 AI 去猜需求；先把需求和约束沉淀成 spec，再让 AI 基于 Spec 编码

十三、Memory 记忆机制#

Agent 需要记忆才能在多步任务中保持状态，跨任务积累有效上下文
记忆机制可以分四层

• 感知记忆（当前输入的原始内容）
• 短期记忆（上下文窗口里的对话历史）
• 长期记忆（存在外部数据库、语义检索召回）
• 实体记忆（结构化提取的关键事实）

双时态数据模型，给每一条记忆打上“双重时间戳”：（解决时序幻觉）

• 有效时间，当前事实在现实世界的真实生效与失效时间
• 系统时间，该记录被写入数据库系统的时间

在 Agent 查询时，系统执行“时间切片约束，严格区分并隔离“当前状态”和“历史状态”

RAG 陈述性记忆，“是什么”的静态资料与事实，有“仅知规则，缺乏实战能力，收益有限”的局限
程序性记忆，“怎么干”的动态操作与解决技能，将成功交互轨迹过滤无效尝试和，压缩固化为可复用的 Skill，遇到同类问题直接调用，零重复试错（类似 Hermes Agent 的自进化？）

ChatGPT 四层记忆架构#

滑动窗口记忆#

即时活跃的短时记忆。直接依赖模型上下文窗口，不经过外部检索，反应最快
类似瞬时记忆，超过 token 上限最老消息将被直接丢弃

会话元数据#

临时生效的环境信息。例如用户当前设置的“角色”、“语气”等提示词，作为全局变量生效
当前环境信息，当下对话所需, 用完即扔，不进入长期记忆

用户档案卡#

精确可控的核心事实记忆。结构化存储用户提供的关键事实，精准插入
结构化存储，更新时直接覆盖旧数据，确保单一事实来源，实现精确读取

对话摘要记忆#

轻量化的中期主题记忆。对长程对话进行摘要和压缩，以较小的 token 成本保留上下文脉络
类似前情提要