前言

过去两年，基本上没有哪个一线研发能完全躲开 AI：大语言模型（Large Language Model， LLM）、AI Coding、Agent、各种"Vibe Coding 编程工具"轮番上场。我在 AI 团队到现在已经快一年了。这一年里参与了多个AI项目，推动了一些AI工具落地，也看到了大量真实的AI工具使用场景、反馈与困惑。这篇文章尝试系统整理这段时间的思考与实践经验：既包括模型原理，也包括工具选型、提示词工程、工程实践，以及 Agent / MCP / Skill 等高级能力的落地方式。

文中观点不是“真理”，我觉得更像一版可讨论的实践手册，欢迎大家补充、讨论和纠正。

一、大语言模型的本质与局限

先把底层的东西说清楚，后面才不至于对它抱"玄学期待"。

大语言模型的本质

技术细节可以很复杂，但对工程实践来说，可以粗暴概括成一句话： 一个在海量文本上训练出来的“下一个词预测器”。

底层主要是 Transformer 结构，核心是 Self-Attention 机制：当模型处理一段文本时，会为每个 token 计算它与其他 token 的相关性权重，有点像人类读文章时会不自觉地“多看几眼关键词”。 训练阶段，它看过几十 TB 级别的文本：论文、代码、新闻、书籍、网页……这些内容中的表达习惯、知识结构和套路，都被压缩进了模型参数。 因此，你看到它生成的代码、文档、解释，本质上是对“类似场景下人类写过的东西”的统计重组，而不是它真的像人一样“思考”后得出的结论。

物理级别的限制

从原理出发，有几个几乎是“物理级”的限制，这直接决定了它的边界。

1. 上下文长度与复杂度限制 自注意力的计算复杂度接近 O(n²)。上下文太长，会导致显存与计算成本爆炸。 现实效果是：上下文越长，注意力越容易被稀释；长上下文下更容易漏关键信息、前后不一致。

2. 缺乏长期记忆

它没有真正的“记忆”，只有当前有限的上下文窗口；训练参数里压缩的统计规律。忘记对话前面说的话、跨会话连续性差，是自然结果。

1. 推理能力有限 目前的推理更像是“见过类似推理套路”的模式匹配：模板化数学题、逻辑题表现不错；需要严格多步推导、全局一致性的任务，仍然不稳定。

2. 幻觉（Hallucination） 模型会一本正经地给出“非常像真话”的错误答案。 对它而言，只是在生成统计上“看起来合理”的续写，并不会主动区分“真 / 假”。

数据层面的挑战

LLM的"世界观"完全来自训练数据。所谓"高质量文本"（百科、书、论文、主流媒体）本身是有限的，业界已经在讨论高质量文本几年内耗尽的问题。继续走"模型更大+数据更多+时间更长"的路线，很快就会撞到资源上限。下图展示了这种趋势：

大语言模型不是终极答案，它更像一个通用的"知识执行层"，上面仍然要有工程和方法论。我们现在常说的"工具调用、RAG、Agent"，其实都是在给它外挂"真能力"：让它查资料、跑代码、看日志、用外部记忆，尽量弥补"只会预测 token"的天生缺陷。

---

二、AI Coding 工具实践经验

很多人现在天天在用 Cursor、Copilot、Cline 之类的工具，其实可以想象成：

在你的 IDE 里住了一个"看过整个 GitHub"的实习生。

它是怎么工作的？

以 TAB 补全为例，本质是大语言模型在海量代码库（如 GitHub 公开项目）上微调的产物。它每时每刻都在做几件事：

1. 监控上下文：实时追踪你当前打开的文件、光标位置、最近改动

2. 构建知识图谱：在项目里搜索相关文件、symbol，通过索引或向量检索拼出"当前任务相关的上下文"

3. 调用模型推理：把这些上下文+你的指令喂给后端大语言模型

4. 输出建议：把返回的结果插进你的代码里，或展示成补全建议

背后有大量工程优化：

• 限制一次塞进去的内容长度

• 优先包含你刚刚修改的调用链

• 用智能索引快速定位相关代码

它能做什么，不能做什么？

擅长的事：

• 快速写 DTO、Controller、API Client 这类样板代码

• 在几万行的仓库里，沿着调用链往上往下跳，找逻辑入口

• 生成初版单元测试和接口文档

• 解释不熟悉的代码片段

短板也很明显：

• 只知道上下文窗口里的世界，跨仓库、跨服务容易"断片"

• 改动链长一点，或涉及架构层面调整，很容易在局部做对、整体搞乱

• 性能、安全、可靠性、可运维性，靠的是工程经验，而不是"见过很多代码"

• 它主要加速"写代码"，而非"做工程"

所以，把 AI Coding 工具当成 "超级 IDE+初级结对程序员" 比较合适，而不是"自动开发机"。

随着工程和算法的深入，AI Coding 的上限也在不断的突破，我们相信"自动开发机"在不久的未来也会实现。但目前距离“任意复杂系统全面自动开发”依然很远。

因此，在现阶段，我们需要学会使用 AI Coding 工具。否则，你可能会经历如下的心路历程。

一个 AICoder 新手的内心写照

以下这个段子非常流行，但是许多新手的真实写照：

• 一开始只是很朴素的需求：

> 「代码有一点 bug 你修一修」

> 「我不要部分代码 你把修改后的完整代码发给我」

> 「给我生成完整代码」

> 「不要只生成框架 生成完整代码」

> 「你的代码还是有问题」

> 「你写的代码有问题 跑不了！」

> 「不是刚刚还能跑 怎么现在跑都跑不了了？」

> 「新的代码运行不了 给我回去之前的版本」

• 多次被“推倒重写”或大改后，开始极度在意“原代码不被破坏”：

> 「我的意思是让你改进我的代码，不是重新写一个新的代码」

> 「不要改变我原来的代码」

> 「请不要修改我原先的代码基本逻辑」

> 「在我的代码上修改..」

> 「不要改我的变量名！！！」

> 「不要改原有的函数名啊啊啊」

> 「不要污染我的变量」

> 「不要修改我原来的代码」

• 多轮沟通后，期望与结果持续不匹配，出现情绪化表达：

> 「你没听懂我的意思吗？」

> 「听不懂人话是吧」……（此处略去若干不适合作为训练数据的词语）...

从一开始把 AI 当成一个“聪明的自动修 bug 工具”，到不断经历“代码跑不了 → 被乱改原代码 → 语言/逻辑/风格不符合预期 → 沟通反复失效”，最后情绪崩溃。骂也没用，骂也算 token，你这个月的额度还够吗？

导致这个现象的原因通常不是“AI 不行”，而是：

• 需求表达不清；

• 上下文信息不足或混乱；

• 把“写代码”当成独立任务，而不是工程流程的一部分；

• 对 AI 的边界不清楚，错误期待“它帮我一把解决所有问题”。

为了避免反复陷入这个陷阱，本文后面会就这个话题继续深入。

---

编程工具的选择策略

目前 AI 编程工具可以分为三类，其中代表为：Cursor、Copilot 和 Claude Code。理解它们的差异，能帮你选对适合自己阶段的工具。

三种工具的定位

当前常见的三类 AI 编程工具，大致可以放在一条轴上：

• 从易用性看：Cursor > Copilot > Claude Code；

• 从灵活性看：Claude Code > Copilot > Cursor。

Cursor - 新手友好型

Cursor 的特点包括：

• 新开项目后会自动索引整个仓库；

• 即使你不主动提供上下文，它也能引用到较远的文件；

• 同一个问题往往会附带较长的上下文摘要和引用。

本质上，Cursor 在 IDE 后台做了大量“自动上下文工程”，这是它的核心价值。 代价是：

• 无论问题是否复杂，往往都要组装大量上下文；

• 实测中，相同任务下，Cursor 的 token 消耗约为 Copilot 的 2–3 倍。

用编程语言打比方：Cursor 有点像 Python——开箱即用、对新手友好，但“烧 Token”。

所以对Cursor来说，按对话次数收费是不划算的，按token收费才能真实反映他的成本。

Copilot - 进阶灵活型

随着你不断使用，你会发现上下文不是越多越好。对于大语言模型来说，上下文增加意味着注意力的分散。对深度用户而言，通用的大上下文反而成为模型输出效果的上限。

注意，不是说上下文越短越好，对复杂任务，「信息不足」往往比「上下文偏大」更致命。具体的衡量抉择，需要具体任务具体分析。

Copilot 相对来说上下文组装比较克制，所以你可以在上下文中有更灵活的操作。你可以把大部分关键信息手动组装好，对上下文有更多的掌控，针对特定任务提供最佳的信息和指引。

但这也意味说明你需要花更多的时间来准备提示词，否则效果会打折扣。

用编程语言打比方，Copilot 有点像 C#——平衡了易用性和控制力。

Claude Code - 高级定制型

随着工具的进一步深入，你希望定制系统提示词、提供子 Agent 来隔离特定任务的上下文，或者精细管理目录的 AI 规则和项目知识。这个时候，Claude Code 正是你需要的工具。

Claude Code 以极高的灵活性，大大提高了 AI 编程的上限。用编程语言打比方，它有点像 C++——强大但需要更多的掌控力。

工具的选择建议

• Cursor：在 IDE 内集成了较重的「项目索引 + 自动上下文工程」，对“单人高效率改动一个仓库”非常友好；代价是 Token 消耗和部分不可控上下文引入。

• Copilot：与 GitHub 生态和主流 IDE 紧密结合，自动补全体验优异，Chat 模式也在增强上下文工程；适合已经习惯 GitHub / VS Code 流程的人。

• Claude Code：强调可配置的系统提示、项目规则、子 Agent 结构，更适合团队级规范化、模板化使用。

这些工具适配不同场景的开发者，选择适合自己的工具，比盲目跟随主流或好高骛远更重要。

从发展趋势来看，工具同质化也越来越严重，这导致以前某个工具的独特优势很快就会被其他工具模仿。另一方面，AI Coding工具的发展飞快，我们日常大部分编程工作，大部分AI Coding工具已经能轻松胜任了，工具之间的界限也越来越模糊，最终还是回到人本身。

LLM模型的选择建议

不同 LLM 模型之间，有不同的“性格”；一个编程工具，大概率会针对不同模型，设计不同的系统提示词，使其输出结果最优。至于在什么任务选择什么模型，每个人都有不同的看法。但是总体上某些模型适合具体任务的实现，某些模型的知识面广适合方案探索。尝试不同的模型，摸清楚他们的“脾气和性格”，也是提高工具使用效率的重要环节。

在实现某个AI Agent功能，选择模型时，可以结合几个重要维度来看：

1. 任务类型匹配

   1. 偏编程/代码重构：优先看 HumanEval / MBPP 等编程评测，结合社区口碑（如谁在实际 IDE 场景里表现更好）。

   2. 偏数学/逻辑推理：重点看 GSM8K / MATH / BBH 等指标，关注「解题过程是否清晰」「是否容易胡编」。

   3. 偏知识问答/方案探索：看 MMLU、知识类基准，以及 Chatbot Arena 这类综合主观评分。

   4. 偏长文总结/写作：更看重上下文长度、长文本稳定性，以及主观体验。

2. 模型规模与架构差异

   1. 参数规模（几 B / 十几 B / 几十 B / 上百 B）

      • 大模型一般在复杂推理、多步规划、大型项目理解上更稳，但成本高、延迟大；

      • 中小模型适合做「工具里的内嵌助手」，或做前置过滤/摘要。

   2. 架构特点

      • 有的模型针对代码做了专项训练或指令微调（Code Llama、专用 Code 模型等），在编程任务上会明显更强；

      • 有的模型针对多语言/多模态（图文、语音）做了加强，适合做跨模态场景；

      • 有的模型强调长上下文（几十万 token），适合处理大文档、整仓代码分析。

3. 你自己的体验与约束条件

   1. 响应速度 / 成本：有些任务（如日常小问答、简单工具调用）不需要上旗舰模型；

   2. 隐私与部署：内部敏感代码、数据，需要私有化部署的开源模型；

   3. 生态与工具集成：你常用的 IDE / 平台里默认集成的是哪几个模型，也会影响实际可用性。因为很多工具是针对某个模型进行调优的，这种情况下生硬地换模型可能会“水土不服”。

4. 除此之外，还需要有可持续性与成本意识：

   1. 识别 AI 的隐性成本结构：

      • Token 成本（尤其长上下文、多轮对话）；

      • 工程投入（构建 RAG 索引、维护 MCP 工具链）；

      • 人力成本（Prompt 调优、结果验证时间）。

   2. 绿色 AI 实践：

      • 小任务用小模型；

      • 缓存高频查询结果（如“常用工具函数解释”）；

      • 设置 Token 预算告警。

   3. ROI 思维：并非所有场景都值得用 AI。例如，在某些场景下写一个简单脚本可能比调优 Prompt 更快。

   4. 识别根本问题：如果某个系统已经很难用，与其希望开发一个MCP来让AI操作这个系统，不如重新设计系统的用户交互界面。

养成这种「先识别任务 → 再选模型」的习惯，就不容易陷入「迷信某一个模型万能」的误区，也能真正做到——在合适的场景用合适的模型。

LLM榜单的局限性

在做 AI 应用开发时，“选哪个模型”的问题中很多人第一反应是去看各类榜单（MMLU、GSM8K、Code 评测、Chatbot Arena 等），这是必要的，但远远不够。

需要先搞清两件事：

1. 这些榜单到底在测什么？

1. 大部分基准测试的输入质量都很高：题目清晰、信息完整、歧义较少，目的是尽可能测出模型的“智力上限”。在这种环境下，模型主要考验的是推理能力、知识广度、代码正确率等。

1. 但在真实业务中，你更多面对的是“半截需求 + 模糊描述 + 上下文不完整”的场景：

   • 用户不会一次性把信息说全；

   • 提示词有歧义、上下文有噪音；

   • 你需要模型帮你“揣摩意图、主动补全条件”。

     这类能力，在很多传统 benchmark 里其实测得并不充分。

1. 不同榜单的评分方式也很重要

     你要选哪个榜单参考，就要看：它的测试集、评分机制，和你自己的实际场景有多接近。

   1. 纯自动判分的基准（比如编程题是否通过样例、选择题是否选对），更接近“机器能不能给出正确答案”；

   2. 像 Chatbot Arena 这类“人类盲测投票”的榜单，则更能反映：在开放式对话、模糊任务中，用户更愿意长期使用哪种模型。

一个实用的方法是三步走：

1. 先用榜单做粗筛：根据任务类型（编程、问答、推理、写作、多模态…）从公开评测中挑出 2–3 个表现靠前的候选模型。

2. 再用小规模真实任务做对比：用你自己的提示词、你自己的业务数据，给这几个模型跑同一批任务，对比输出质量、稳定性和成本。

3. 最后结合“人机交互体验”做决策：特别是面向终端用户的应用，要看模型在模糊输入下能否“帮用户把话说完整”，而不仅仅是榜单分数高不高。

总结一句：榜单用来“缩小搜索空间”，真实场景的小规模试用用来“做最终决策”。既不要迷信任何一个分数，也不要只凭感觉拍脑袋选模型。

模型在AI Coding时代的变迁

这两年 AI Coding 的模型有一个很明显的升级方向：以前大部分模型的工作模式是——你给一大坨上下文，它“憋一口气”算完，然后把完整答案吐给你； 新一代的思路是：边想边干。

Anthropic 在 Claude 4 系列里正式定义了一个叫 interleaved-thinking-2025-05-14 的 header，Interleaved Thinking 也可以翻译成“步进推理”，其主要思想是：

• 用户提问

• 模型先想一步（生成思考片段）

• 再调用工具干一步（读文件、跑测试、查网页）

• 看结果，再想一步，再干一步

• 如此循环，直到任务完成

也就是说，模型的工作方式变成跟程序员一样：边调试边思考，而不是一次性脑补整个世界。

早在 2022 年，其实就有 ReAct（Reason + Act）、Toolformer 这些工作，提出了“思考–行动交替”的框架。但那一代更多是靠 Prompt 模板在模拟交错思维——你在 Prompt 里教它：“先输出 [Thought]，再输出 [Action]，然后是 [Observation]……”，模型看起来是在“交替思考和行动”，但它的“思考过程”本质上还是一次性生成出来的字符串，没有被系统当成真正的“状态”。

真正把AI Coding带到新一个台阶的技术，不只是工具数量变多了，而是思考过程本身被当成了一等公民。正是这项技术，让AI Coding从玩具和Demo变成真正的生产力。

---

三、提示词工程实践经验

提示词（Prompt ）的本质是什么？

提示词的本质，不是某种“咒语”，而是限制搜索空间。

你面对的是一个受训于全网文本的大模型，它“脑子里”有成千上万种可能的续写方式。

提示词要做的事情，就是尽可能明确地告诉它：

• 你现在扮演谁

  • 资深后端、架构师、Code Reviewer、技术文档写手…

• 你现在要干哪一步

  • 分析需求？设计接口？写伪代码？补边界条件？生成测试用例？

• 你应该以什么形式输出

  • 只输出 diff？只输出代码？先给大纲再展开？不需要解释？

换句话说：Prompt 是你给模型设定的“工作岗位说明书 + 当前任务说明 + 输出格式约束”。

写好这三件事，输出质量就已经赢了一半。

接下来，根据我的经验，细化分享一些具体的优秀实践。

---

实践一：拆步骤执行

很多人用 AI 写代码的默认姿势是：

“帮我实现一个 XXX 系统，要求高并发、高可用，顺便给点优化建议。”

然后期待模型“一把写完”。更稳妥的方式是拆步骤执行，把一个复杂任务拆成几轮对话：

• 第一步：先让它帮你确认需求，补全遗漏的边界条件；

• 第二步：让它给出接口设计、数据结构与模块划分；

• 第三步：再让它按模块实现代码；

• 第四步：最后要求测试用例、错误处理、监控指标。

好处有两个：

1. 每一步的目标更清晰，模型不需要在一次对话里“又分析、又设计、又实现、又测试”，注意力更集中；

2. 你可以在每个阶段做人工 review，及时纠偏，避免“写到一半发现方向错了，只能整体推倒重来”。

实践二：上下文隔离与任务分解

从模型原理来看，它在一个对话里能关注的信息是有限的，你让它关注的东西越多，注意力越分散。

一个实用策略是：用上下文隔离来做任务分解，例如自顶向下地分两轮：

• 第一个会话

  • 让 AI 把核心流程和总体架构设计好；

  • 写清楚主要模块、函数声明和注释；

  • 对具体实现先留 TODO。

• 第二个会话

  • 把上一轮输出作为输入；

  • 让 AI 搜索所有 TODO，一条条补完。

这样做有几点好处：

• 架构设计阶段不会被实现细节打断；

• 实现阶段可以专注于局部逻辑；

• 每一轮对话的上下文都更干净，模型更不容易“跑偏”。

实践三：保持上下文干净

一个任务一个对话，尽量避免在同一轮对话里：

• 一会儿聊业务策略；

• 一会儿问架构方案；

• 一会儿又让它写脚本、生成 SQL；

• 中间还穿插闲聊、吐槽。

上下文越混乱，模型越难判断“当前轮到底应该延续前面的哪一段”，输出自然会跟着乱。

实践中可以遵循一个简单原则：

• 问题相互独立 → 新开对话；

• 强相关的连续步骤 → 放在同一条链路里，逐步推进。

实践四：提供具体示例（Few-shot）

在许多任务上，提供 1–2 个高质量示例，效果远好于给一段抽象描述。

比如要让模型按某种风格写接口文档，你可以：

• 先贴一段「你自己写的、符合预期格式的」文档；

• 再说「请按完全相同的结构和风格，为下面这个接口生成文档」。

Few-shot 的作用在于：

• 让模型从“模糊理解你的描述”变成“直接对齐到你给的样例分布”；

• 把复杂的格式要求、风格要求，变成一个具体可模仿的目标。

实践五：提高信息密度（控制上下文）

很多人用 AI 时，上下文最大的问题不是「不够多」，而是信息密度太低。

典型例子：后端接口返回了一大段 JSON，你有两种常见做法：

• 做法 A：直接把某次真实请求的完整 JSON 响应粘进去；

• 做法 B：只粘「JSON 的字段结构/类型约束」（用工具从实际 JSON 抽出 schema）。

问题在于：

• 一次真实 JSON 里充满了用户 ID、订单号、时间戳等具体业务数据；

• 这些信息对“理解数据结构”几乎没什么帮助，却大量占用上下文。

相比之下，抽象结构（schema）更有价值：

• 精确描述字段名、类型、必填/选填、含义；

• 删除与当前任务无关的细节；

• 在不损失关键语义的前提下，大幅提高「信息 / token」的比值。

实用原则：

• 如果你是让模型理解结构 / 协议 / 格式，优先提供「抽象结构（schema）」而不是「一次真实数据的长截图」；

• 只有当具体数据本身很关键（例如排查特定 Bug）时，再有选择地贴部分真实样例。

本质上，控制上下文的信息密度，就是在帮模型过滤噪音。

在相同的上下文长度下，信息密度越高，你能传递给模型的有效约束就越多，输出质量也就越稳。

实践六：合理使用 Plan / 规划模式

对于体量较大、结构复杂的任务，带“规划能力”的模式（Plan / Agent 等）是值得用的，它可以：

• 帮你把问题拆成若干阶段（分析 → 设计 → 实现 → 验证）；

• 在每个阶段明确当前目标、输入输出和检查点；

• 避免一上来就“直接开写”，导致后面大量返工。

但前提是：任务本身确实足够复杂。

• 如果只是一个小脚本、小函数、小 Bug 修复，硬要套完整 Plan 流程，只会把简单问题复杂化；

• 模型会为了“凑步骤”虚构不必要的阶段，反而增加偏离预期的概率。

简单经验：

• 小任务：给清晰需求 + 必要上下文，一两步完成即可；

• 中大型任务：由你先粗划几个阶段，再用 Plan/规划模式帮助细化步骤和检查点。

规划工具的价值在于帮你更有条理地完成复杂任务，而不是“为了炫技，把任何任务都包装成一个复杂的工作流”。

目前大部分AI编程工具都支持由Agent自主决定是否需要开启plan模式，如果发现自助决策不符合预期，可以明确要求AI写TodoList进行分步实现。

但是不得不说，AI Coding工具进化速度很快，大部分任务AI Coding工具目前已经能很准确地，自动选择采用直接完成，或者TodoList分解完成，甚至调用子Agent完成等方式，大大提高了这些工具的易用性和效果。

实践七：方向错了就重开，不要死磕微调

一个非常常见的坑：

• 第一个 Prompt 没设计好，模型产出了一大坨和你预期差别巨大的代码；

• 然后你试图一遍遍用「请在上面基础上修改」「再优化一下结构」来挽救。

在当前能力水平下，这是性价比很低的用法：

• 主流大模型在从头生成一套逻辑连贯的代码/方案上能力已经很强；

• 但在对一份「整体方向错误、架构不对」的代码做精细、全局一致的修改上依然偏弱，尤其通过 MCP 等方式做大范围结构调整时更是如此。

更稳妥的做法：

• 一旦发现整体方向都不对（需求理解错、架构不合适、边界条件大量缺失），与其在错误基础上补丁，不如：

  • 直接“撤销”这次尝试（新开一轮对话）；

  • 重新梳理需求和约束，优化你的首个 Prompt；

  • 让模型在更清晰的前提下重新生成整体方案或代码。

• 只有当你确认「原始代码大体方向正确，只需要局部修改或小规模重构」时，才适合在当前结果上做增量迭代。

一条简单记法：

• 方向错了：重启对话 + 重写 Prompt；

• 细节错了：在当前结果上做局部、可控的增量修改。

实践八：避免主观臆想影响输出

同一个模型，问法稍一变化，结论可能完全相反。比如：为一个移动端项目选 REST 还是 GraphQL。

• 问法一（偏向 REST）：

    → 模型很可能建议继续 REST。

  • “团队对 REST 熟悉，之前项目用 REST 很顺利，现在考虑 REST 和 GraphQL，你觉得哪个更适合？”

• 问法二（偏向 GraphQL）：

    → 模型很可能倾向 GraphQL。

  • “移动端网络不稳定，需要灵活获取数据，听说 GraphQL 在这方面不错，现在考虑 REST 和 GraphQL，你觉得哪个更适合？”

两次其实说的是同一个项目，只是在问题描述中埋下了不同暗示：

• 一次强调团队已有 REST 经验；

• 一次强调网络不稳定、GraphQL 优势。

在信息不足的情况下，模型会像“过分配合的顾问”，迎合你的暗示。

尽量避免自己的提示词出现这种主观臆想的情况。转而提供尽可能丰富的客观事实信息。

本质上，LLM 不是“有自己观点的人”，LLM的观点是系统提示词赋予的，如果你的提示词带有偏见，那么答案也幸免于难。

---

常见几个坑

1. 把 Prompt 当玄学

   1. 以为多加几个“你是一个资深的…”，“请一步一步思考”就能起死回生。

   2. 如果你自己都没想清楚需求、边界和约束，换 100 种语气也没用。

2. 用 Prompt 替代理解

   1. 直接丢：“帮我实现一个高并发、高可用的订单系统”。

   2. 模型确实能吐出一堆“看起来合理”的代码和架构图，但如果你没经历过分析、拆分、权衡，后面调试和维护时，你是在跟一个你根本不懂的系统搏斗。

3. 提示词空洞无物

   1. 不要以为把“写一篇 1000 字深度文章”改成“写一篇 10 万字深度文章”，质量就会提高。

   2. Garbage in, garbage out. 提示词质量不看长度，只看信息是否全面、具体、有约束。

4. 过度依赖让 AI 写提示词

   1. 一些规划 Agent / Plan 模式，本质是让 AI 帮你丰富提示词、细化方案，这有用，但不是万能药。

   2. 更好的用法是：先尽量把事实与约束写全，再让 AI 帮你重构、精简、结构化提示词，便于后续复用和自动化。

   3. 如果你自己提供的信息已经很完备，那么即便不用这些工具，也能获得相当高的输出质量。

5. 不做验证

   1. 没有测试、没有 code review、没有边界 case，仅仅因为“是 AI 写的”就默认“应该没问题”，这种做法除了浪费 Token 没任何意义。

最后

本节内容太多，不容记忆，我们用一句话来总结每个经验来加强理解：

1. 实践一：拆步骤执行 —— 避免让模型“一口气从需求分析写到上线” 核心：把复杂任务拆成“分析 → 设计 → 实现 → 测试”多步，让每一步目标单一、可 review，降低方向性错误和推倒重来。

2. 实践二：上下文隔离与任务分解 —— 一轮对话只解决一类问题 核心：用“先设计、后实现”的分轮会话，把架构决策和具体实现解耦，每轮上下文更干净，模型更不易跑偏。

3. 实践三：保持上下文干净 —— 一个任务一条链路 核心：避免在同一对话里夹杂业务讨论、脚本编写、闲聊吐槽，把强相关的问题放一条链，不相关的另开会话。

4. 实践四：提供具体示例（Few-shot） —— 用“示范样本”对齐模型风格 核心：用 1–2 个高质量样例，比抽象描述更能让模型对齐你想要的格式和风格。

5. 实践五：提高信息密度 —— 用关键信息占满有限的 token 核心：少贴“整坨真实数据”，多贴抽象结构（schema）、接口约束等高价值信息，用更少的 token 传递更多有效约束。

6. 实践六：合理使用 Plan / 规划模式 —— 在“真复杂任务”上用计划，不炫技 核心：中大型任务上先让模型/你一起做任务规划，小任务则直接给清晰需求，避免为简单事强行套复杂工作流。

7. 实践七：方向错了就重开，不要死磕微调 —— 重写首个 Prompt 往往更划算 核心：发现整体理解或架构方向错误时，宁可新开对话重写提示词，也不要在错误结果上打补丁。

8. 实践八：避免主观暗示污染输出 —— 多给事实，少给“偏好引导” 核心：在问题描述中少埋立场暗示，多提供客观约束，让模型基于事实权衡，而不是“迎合你的预设答案”。

说一千道一万，从使用者的角度来看，Prompt 本质是 高级的人机协作语言。

Garbage in， garbage out ：AI 会放大你输入中的偏见；AI 会配合你的情绪倾向；AI 无法自动补全你没说出口的关键前提（除非极其常识）。

真正高质量的 Prompt，一般会像一份结构化的技术文档：

• 事实与观点分离；

• 尽量用可量化的指标；

• 列清所有关键约束；

• 请提供所需功能的示例

• 明确需要处理的极端情况。

• 参考代码库中已有的模式

• 明确期望的输出格式（结构、字段、示例）。

所以说：Prompt 是一种“比日常自然语言更高抽象级别的人机协作语言”。

如果你自己都没想清楚问题，AI 也很难帮到你。

花更多时间来准备提示词（Prompt），就能花更少的时间来 review 和 debug。这个过程是你 prompt 能力提升的过程，也是AI Coding效率提高的过程。

---

四、研发工程实践经验

AI 编程不是“换个输入法”，而是对整个开发流程的重构。

这里选择几个对大多数团队都实用的点。

从“写代码”转向“编排任务”

以重构一个历史悠久的某个模块为例。

传统做法：

• 自己读半天代码，硬啃旧逻辑；

• 手工画依赖图、调用关系；

• 想好新架构，再一点点迁移。

现在可以这样做：

1. 让 AI 帮你读代码

   1. 把关键文件丢给 AI，让它总结职责；

   2. 列出关键实体 / 关系；

   3. 画出调用链、时序图。

2. 人做关键决策

   1. 你来定义新的边界、接口、抽象；

   2. AI 可以帮你罗列多种方案的优缺点，但最终取舍由你拍板。

3. 让 AI 帮你迁移实现

   1. 定好新接口与目标行为；

   2. 让 AI 按模块迁移旧逻辑、补测试。

效果：

你的脑力主要用在“建模与决策”，而不是被大量机械阅读和样板代码绑死。

规格驱动开发：用 OpenSpec 固化需求与演化

很多人现在用 Cursor / Claude Code 做“vibe coding”（边聊边写），常见问题是：

• 自己脑子里的需求是模糊的，只能一遍遍说“差不多就是这样”；

• 每次调 AI 都像即兴创作，缺乏可复用结构；

• 换项目 / 换助手，又得从头讲业务逻辑。

本质是：

需求从未被系统化固化下来。

一个有价值的思路是 规格驱动开发（Spec-Driven Development）。

以开源工具 OpenSpec 为例，它做的事情很简单：在项目里维护两个目录：

openspec/ ├── specs/ # 当前系统的真实规格：现在到底长什么样 └── changes/ # 每一次变更的提案：准备把系统改成什么样

典型工作流：

1. 写变更提案（proposal.md）

     → 可以反复丢给 AI 帮你补边界条件、发现遗漏。

   1. 背景、要解决的问题；

   2. 计划新增/修改的内容；

   3. 可能影响的模块。

2. 写任务清单（tasks.md）

     → 后续在 Claude Code / Cursor 里，直接让 AI 按任务清单执行。

   1. 改哪些文件、新增哪些模块、哪些不能动；

   2. 每一步希望 AI 产出什么（代码、测试、文档）。

3. 实现 + 归档

   1. 变更完成后，用命令把 changes/ 合并进 specs/；

   2. 保证 specs 始终是“系统当前真实状态”。

这种方式的好处是：对个人：需求不再散在聊天记录和脑子里，而是变成结构化、可审计的规格；未来回看，能清楚知道“当时为什么这样改”。对团队：可以像 review 代码一样 review 需求变更；AI 助手可以稳定围绕 specs 工作，而不是每次从 0 理解业务。

一句话总结：有意识地把“需求 → 规格 → 任务 → 实现”变成一个可复用、可追踪的闭环，AI 才能真正发挥“工程助手”的作用。

用工具兜底 AI 输出质量

AI 写完代码，下一步通常不是“合上电脑”，而是“让机器和工具帮你先做一轮验收”。以下是笔者的实践建议：

给项目配置静态分析与类型检查

• 确保项目的 Lint / 类型检查正确配置：

  • JS/TS：ESLint + TypeScript 编译器

  • Python：Ruff / Flake8 / Pylint + MyPy / Pyright

• 即使是 Python，也建议：

  • 可以加 type hints；使用 MyPy/Pyright 做静态类型检查；

  • 制定规则：新代码必须带类型标注。

合理的单测策略

• 不必追求极高的覆盖率（过高往往运行慢、维护成本高）；

• 但对关键逻辑要尽力增加单测覆盖，特别是：

  • AI 修改触达核心业务逻辑的时候；

  • 有单测兜底，回归更稳。

建立“AI 自检”流程

• 让 AI 在提交前自动跑：Lint → Build → Unit Test；

• 若出现错误，让 AI 先根据错误信息尝试修复；你的精力是宝贵的，不要花精力去处理AI的低级错误。

• 你再做最后一轮 review。

总之，用人给AI做质量检查，一定是AI Coding的效率瓶颈。我们应该多用成熟的，工程化的，可靠的方法，把尽可能多的问题用工具拦下，提高AI最终的代码质量。

技术栈选择：为 AI 时代做优化

大仓的价值在 AI 时代放大

“大仓”本质是信息共享与联通。

在 AI 编程场景下：如果前后端分离、过度微服务化、模块分库分仓，会导致本来一次 prompt 可以搞定的改动，变成多次复杂提示和联调；上下文难以完整组装，AI 获得的信息更碎片化。

当然，单仓与安全、架构之间需要平衡。但需要意识到：信息连通对 AI 非常友好。

从效率的角度出发，“大仓”必然利大于弊。

强约束语言的“时代红利”

在 AI 编程时代，强类型 + 严格编译器 更有价值。以 Rust 为例：

• 所有权 / 借用 / 生命周期 + 强类型 + 编译器，可以在编译期拦截大量错误；

• 许多在 C/C++ 需要经验和工具才能发现的问题，在 Rust 中根本编不过；

• 编译错误信息本身就是“高质量上下文”：

  • 可以直接丢给模型，让它据此修复。

实际上：严格约束不是和 AI 对立，而是与 AI 强互补。AI 负责快速生成候选实现；类型系统与编译器负责自动做第一轮“硬性审核”。类似价值也存在于：TypeScript、Kotlin、Swift 等强类型语言；Protobuf / OpenAPI 等规范明确的接口定义。与之相对的，弱类型语言的很多错误只能在运行时暴露，AI 不易通过“编译器 + 静态检查”自动闭环修复。

总之，我们应该多用成熟的，工程化的，可靠的方法，把尽可能多的问题用工具拦下，提高AI最终的代码质量。

选择生态成熟的框架

在 AI 编程时代，尽量少用自研框架（尤其 UI / 图形框架），优先选：

• React / Vue / Svelte 等前端框架；

• Qt / Electron / Flutter 等主流 UI 技术。

原因很直接：主流 LLM 在训练中已经大量接触这些框架的代码、文档和问答；在这些栈上，模型往往有“先验经验”，能给更成熟的建议。自研框架缺乏公开资料和大量使用样本，模型基本没有“见过”，很多问题只能从零推理，效果明显打折。

个体效率 ≠ 团队效能：

• 个人写码快，但若 AI 生成的代码可读性差、测试覆盖率低，反而增加团队维护成本。

• 避免审阅跟不上AI的输出：Ai写的快，人审阅的慢。AI生成代码速度过快的时候，人往往还没看明白代码细节，虽然功能一切看起来正常，但实际上已经开始埋雷了。要确保消化好已经写好的AI代码，再写新的。否则后面会像技术债务那样失控。而且失控的速度比传统的编程方式累计的技术债要快得多。

• 从更大范维看，这些维度也不容忽视：

  • 正确性：单元测试通过率、静态检查数；

  • 可维护性：代码重复率（Clone Detection）、圈复杂度变化；

  • 协作成本：Code Review 轮次、返工率；

  • 长期影响：技术债指数（如 SonarQube 技术债评分）是否上升。

• 警惕“虚假生产力”：AI 快速生成大量代码，但若未经过设计评审，可能固化错误架构。

简而言之：不要只追“写得多、写得快”，要看“团队整体是否更容易理解、维护和演进系统”。

安全与隐私

目前，训练大模型的公开高质量文本信息面临枯竭，很多公司内部的保密的高质量代码，AI会话记录等信息，在可预见的未来，也必然成为大语言模型训练场的“灰色地带”。

• 代码泄露风险：Copilot/Cursor 等工具默认将用户代码发送至云端模型（除非使用本地部署版）。例如GitHub 曾因 Copilot 训练数据包含 GPL 代码引发法律争议。

• 内部知识外泄：开发者无意中将敏感逻辑（如风控规则、密钥生成算法）输入 AI 聊天窗口，可能被记录或用于后续训练。

• 供应链攻击新形态：攻击者可故意在开源项目中植入“诱导性注释”（如 // TODO: fix this security flaw in auth），诱使 AI 生成含漏洞的修复代码。

我们在享受AI Coding工具的便利的同时，也需要有安全风险意识。

---

五、高级工具：Agent、MCP、Skill等

现在 Agent 概念很火，很多宣传听起来有点"魔法感"。冷静拆开来看，其实很朴素：

一个 Agent，就是一个会调用工具的 LLM + 状态管理。

Agent 按这种循环工作：

1. 读当前目标和状态

2. 用 LLM 决定"下一步要做什么"（调用哪个工具、传什么参数）

3. 执行工具、更新状态

4. 判断是否完成/失败/继续

多 Agent/子 Agent 本质就是：

• 你把一个复杂任务拆成几个角色：

  • 需求分析 Agent

  • 代码生成 Agent

  • 测试与验证 Agent

• 它们之间靠"协议"沟通，比如共享任务队列、读写统一的知识库

自定义控制器 : MCP

"自定义 MCP/控制器"这种高级玩法，比如：

• 让模型直接操作你的 IDE、浏览器、数据库

• 自动跑测试、分析监控、甚至执行运维操作

本质上，就是把 AI 接入了你的生产系统。真正重要的是：

• 权限和边界：它能干什么，不能干什么？

• 审计和追责：做错事怎么追溯？怎么回滚？

• 可解释性：出了问题，你能不能看懂"为啥它做了这个决定"？

MCP实战建议

不要认为挂越多的 MCP 工具，AI 的能力就越大。 MCP 会占用上下文，分散 AI 的注意力，降低输出质量。

因为工具描述本身要占用上下文；模型需要在这些描述中“选择工具”，增加推理负担；复杂工具的参数说明和错误消息会反复出现在上下文中，进一步稀释注意力。一些研究中指出，在特定的实验场景中，随着上下文长度增加，模型的准确率会明细下降。其本质是源于注意力机制的局限性、对无关内容的注意力分散，以及在长距离上下文中检索信息的能力下降。

最佳实践：

• 按需提供 MCP 工具

• 注意设计 MCP 工具时的易用性，过于复杂的工具 AI 会用晕，后面的输出质量会崩掉

• MCP 工具适合操作外部系统，或者获取动态信息

• 不太适合用于获取静态信息（文档、规范、说明等）；高频的，值得常驻的信息，也不适合 MCP 获取。因此需要明确哪些信息是高频、高价值的，值得常驻上下文。

关于静态信息：

如果从高质量追求出发，这些静态信息（如文档，API 说明）适合在上下文工程中提前处理好、组装好，传递给大语言模型。这能获得最高的输出质量。

从追求方便使用的角度出发，静态信息等内容通过 MCP 获取也不是不可以，例如大型文档或频繁变更的信息，通过 MCP/工具层统一访问也是合理方案。但确保这类MCP的易用性，避免AI出现反复使用MCP工具查询文档都没找到关键内容。

我的个人经验是，在 AI Coding 场景中，随着使用的深入，当你对大语言模型的上下文非常的关注的时候，你做的第一件事情一定是把这些不必要的 MCP 拿走。除非你是在开发一套实现某个特定功能的工作流；或者通过上下文工程无法获取必要信息。

Agent设计建议

现在很多开发已经开始设计自己的Agent了。如果要设计一个好的 Agent，一般来说：

1. 任务拆分： 把任务拆得足够清楚

2. 避免滥用： 当前任务是不是非要开子 Agent？大部分任务在旗舰大语言模型中，一次上下文窗口就能轻松应对

3. 接口设计： 合理的定义好 Agent 之间的接口和边界

4. 合理预期： 不要寄希望于通过设计一套复杂的 Agent 架构，大幅提高大语言模型的智力，发现新大陆。不过，确实可以通过堆 Agent，让大长度的模型输出质量得以保证，缓解模型输出长度过高时质量下降的问题

5. 监控能力： 要设计靠谱的监控、评测和回滚机制

6. 可解释性: 尽量让大部分的输出结果具有较高的解释可解释性。本身大语言模型就能看成一个机制复杂的黑盒，我们在这个黑盒之上搭建工程，尽量的提高结果可解释性。只有具备可解释性，我们才能够实现接下来的迭代和优化。

7. 输出的稳定性。不能只关注agent输出的最优结果，如果一个agent中输出的结果时好时坏，不如一个可以稳定输出一个中上质量的结果。尽量在设计阶段就降低这种不确定性。

接下来我们用一个具体的例子，可能更容易理解这些原则。

一个Agent设计的例子

举个贴近实际的例子：现在很多人都在做「AI Code Review（AI-CR）」的 Agent。

反面做法：一把梭的“大 Agent”

有人会这么设计：

“开个 Claude Code，把 diff、部分上下文贴进去，让它自己去看 diff、读代码、查文件，然后直接输出 Code Review 结果。”

这类设计的问题在于：

• 很难监控和评测：

  • 同一个 diff，你反复跑几次，结果可能差异很大；

  • 你也很难判断：到底是上下文没给够，还是提示词不行，还是模型随机性。

  • 在这种架构下，你可能需要大量的时间来做promot的优化，做大量的评测对比。消耗大量的token。但这种设计的天花板已经定死了，花大精力去优化，投入产出比很低。

• 观察不到中间过程：

  • 模型到底看了哪些文件？

  • 它是不是漏掉了某个关键调用链？

  • 作为使用者几乎无从下手。

在这种“一把梭”的大 Agent 里，任务拆分、上下文整理和审查逻辑都混在一起，出错了只能模糊地归因为“AI 今天状态不好”。

两阶段的 AI-CR Agent 拆分

如果是我来设计这个 AICR Agent，我会把任务明确拆成两块：

1. Agent A：负责“收集代码上下文”

   1. 1.   职责非常单一：只做代码相关的上下文整理（不是 AI 对话上下文，而是「这次 CR 需要看的代码片段」）。给它挂的工具也非常克制：只提供「读取文件」「代码搜索」「按符号/调用链跳转」这类工具；不让它做任何审查结论。

      1.   输出内容类似于：本次 diff 与本次改动直接相关的函数/类/调用链片段；必要的配置文件/接口定义等补充上下文。

      1.   这个阶段的好处是：输出结构清晰，很容易评测：相关代码片段是不是收集完整？有没有明显遗漏模块/调用链？一旦发现“CR 结论总是漏某些场景”，可以先看是不是 Agent A 收集得不够好。

2. Agent B：负责“真正做 Code Review”

   1. 1.   输入只来自两部分：Agent A 整理好的代码片段；明确、结构化的 CR 规则（比如安全规范、性能要求、编码规范等）。

      1.   不挂任何外部工具：不让它再去随便搜索、乱翻仓库，只专注于“阅读输入片段 + 按规则做审查”。

      1.   输出为：按规则分类的 CR 意见（安全/性能/可读性/潜在 bug 等）；需要进一步人工确认的点。

这样设计的几个直接好处：

1. 角色清晰：Agent A 只管“把东西找全、找对”；Agent B 只管“在给定上下文和规则下做判断”。

2. 评测简单：Agent A 的输出很好评测：你可以用脚本检查它是否覆盖了所有改动文件、所有相关调用；Agent B 的输出可以用人工抽样 + 对比人工 CR 结果的方式评测。

3. 问题定位容易：如果某些问题没有被 CR 出来，先看是不是 Agent A 漏上下文；如果上下文是完整的，再看是不是 Agent B 的规则或提示词设计不当。很快就能判断“是信息没喂够，还是模型用法有问题”。

4. 扩展性好：后续可以给 Agent A 加上 RAG 搜索能力，深度挖掘一些关键的相关架构与信息，继续提高其项目的广度理解。Agent B 也可以继续拆分，如按“安全规则集”“性能规则集”“编码规范规则集”拆成多个子 Agent，各自负责一类检查，再聚合结果。Agent B拆分后可以并发执行，提高系统响应速度，提高CR质量。

其实Agent的设计没有固定模式，以上的设计也是抛砖引玉。但是掌握这些核心精髓，你很容易根据工程目标，设计出一个优秀的Agent。

何时需要子 Agent？

子 Agent 的核心价值在于：上下文隔离 + 策略隔离 + 并行化执行。

在模型和上下文比较受限的早期，Agent 是提升效果的关键手段之一，例如：给不同子任务单独开上下文，可以避免信息冲突；每个子 Agent 只关注自己那部分内容，输出相对更稳定。

而在旗舰大模型、长上下文逐渐普及之后，我们也看到另一面：对很多任务，一个强模型在单条上下文里“线性推进”就够用；不一定需要复杂的多 Agent 调度系统。

子 Agent 更适合在这些场景使用：

1. 任务规模 / 复杂度很高

   1. 小模型在“短上下文 + 短输出”场景下往往表现不错（写个斐波那契没问题）；

   2. 但在几万行代码、跨模块大重构这类任务中，很容易“丢信息、断逻辑”。

2. 这背后涉及两个维度：

   1. 输出规模 + 上下文复杂度；

   2. 模型容量 + 注意力分配能力。

3. 大模型能在长上下文下保持较好的整体性，小模型就需要拆步 + 降复杂度。

4. 需要明确阶段边界和角色分工

   1. 例如前面的 AI-CR：上下文收集和规则检查应拆开；

   2. 或者“需求分析 → 架构设计 → 代码生成 → 测试与验证”这些阶段。

5. 工具描述复杂，容易污染主上下文

   1. 一些 MCP 工具描述极长、参数复杂；

   2. 为了避免主任务上下文被这些工具说明淹没，可以开专用子 Agent 去操作工具，再把结果以压缩形式返还主链路。

在使用子 Agent 时，可以记住一个经验法则：

• 简单任务 + 强模型 → 尽量一条链路搞定；

• 中等任务 / 小模型 → 合理拆步，但不滥开子 Agent；

• 超大任务 / 工具复杂 / 需强隔离 → 使用子 Agent 做分治。

关键在于你对“任务规模”和“模型能力”的评估，而不是为了“显得高级”去堆多 Agent 架构。

Agnet的更多思考

DeepMind 在 2024 年 11–12 月连发两篇论文，系统地拆解了两个核心假设：

1. More Agents ≠ Better Performance 在《Towards a Science of Scaling Agent Systems》中，他们用 180 组受控实验，对比了多种 Agent 架构（单 Agent、独立多 Agent、去中心化多 Agent、中心化多 Agent、混合架构），覆盖金融分析、网页浏览、游戏规划、工作流等场景。 结论之一是：在开放复杂任务中，单纯增加 Agent 数量，往往会引入巨大的“协调税”——

   1. 每个 Agent 都要理解工具说明、维护上下文、读写中间结果；

   2. 工具数量一多，传递信息的成本迅速超过并行带来的收益；

   3. 错误还会在多 Agent 架构中被放大，出现所谓的“巴别塔效应”。 只有在边界极清晰、步骤高度标准化的任务（比如严格 SOP 的金融分析）里，中心化多 Agent 才表现出明显优势。

2. More Budget ≠ Effective Scaling 在《Budget-Aware Tool-Use Enables Effective Agent Scaling》中，DeepMind 发现：

   1. 单纯把工具调用预算从 10 次加到 100 次，性能提升非常有限，Agent 往往只用掉一小部分预算；

   2. 模型并不知道自己“还有多少资源可以用”，也没有“机会成本”的概念，容易在错误路径上越挖越深，甚至因为上下文过长导致表现下降。 为此他们提出了 BATS（Budget-Aware Test-time Scaling），通过预算感知的规划与验证：

   3. 用结构化的 checklist 管理子任务和资源消耗；

   4. 在每轮推理后做约束检查，决定是继续深挖当前路径还是及时止损、换路； 在多项基准上，BATS 在相似成本下显著超过传统 ReAct Agent。

这些结果指向同一个结论：

目前的 Agent 能力，还远没到“丢一堆 Agent 进去，让它们自组织分工、自发进化出结构”的阶段。真正能在生产中跑起来的系统，几乎都依赖于：

• 人工设计的任务拆分和 SOP，

• 严格受控的工具层抽象，

• 极其啰嗦的系统提示和流程约束，

• 再加上一点点“模型本身的智能”。

在这样的现实约束下，“Agent 元年”与其说是“通用智能觉醒”，不如说是：我们开始认真把一个有一定理解和决策能力的模型，嵌入已有的工程体系，用它当更聪明的自动化组件。真正意义上“靠 Agent 自己长出结构”的时代，还没到。

Workflow 低代码平台

最早的时候，WorkFlow 和 Agent是泾渭分明的两个概念，Workflow一般指预定义编排，Agent则是运行时自主决策。从实践上来看，只要挂了MCP工具的都可以认为是Agent；只要流程是固定的也可以认为是Workflow。但随着技术的发展，这两个方式往往是互相融合，而非严格排他的。在本文中，侧重表现一个AI系统的“预定义编排”的特点的时候，我们称其为workflow；侧重表现一个AI黑盒系统的时候，我们也会用Agent来表示。

除了前文中讨论的手写 Agent 代码，很多低代码 AI 工作流平台如 Dify、n8n、LangGraph 或 Flowise通过拖拽式界面，即可构建包含 LLM 调用、工具执行、条件判断、人工审核 的完整工作流，实现复杂的AI系统功能。

网上大量关于这些平台的评测和热捧，那么如何客观冷静的看待这些工具呢？

我们先从工具的价值入手。这些平台的价值主要有：

• 降低试错成本：传统 Agent 开发需反复调试 Prompt 和工具参数，而可视化平台提供 实时预览、节点日志、输入/输出快照，大幅缩短反馈循环。例如，Dify 支持对每个 LLM 节点单独查看 token 消耗与响应内容，便于快速定位幻觉或上下文缺失问题。

• 促进跨角色协作：产品经理可通过流程图理解 AI 决策路径，测试工程师可注入 mock 数据验证分支逻辑，运维人员可监控各节点成功率——这正是 “工程化优先”方法论 的体现。

• 内置最佳实践：主流平台已集成 RAG、函数调用、多轮对话状态管理等模块。例如，n8n 的 “AI Agent” 节点 自动处理工具描述压缩，避免上下文污染；Dify 的 “知识库” 功能 支持按业务域分片检索，提升 RAG 精准度。

这些平台并非万能。低代码 AI 工作流仍处于“期望膨胀期”，实际落地中常见问题包括：

• 灵活性受限：当需要动态调整上下文窗口、实现复杂记忆机制（如向量记忆+符号记忆融合）时，可视化节点难以表达；

• 性能瓶颈：平台抽象层可能引入额外延迟，在高 QPS 场景（如实时 Code Review）中不如原生实现；

• 调试黑盒：虽然流程可见，但 LLM 内部推理过程仍不可控，很多错误根因分析需结合日志与人工判断，导致调试和维护成本高。

如何选择？一个简单原则：

• 若任务为 标准化、可枚举步骤（如“用户提问 → 查知识库 → 调 API → 生成报告”），优先用 Dify/n8n 快速搭建；

• 若任务涉及 复杂状态管理、动态规划、需要深度调优或高性能要求，仍建议手写 Agent + 精细控制上下文。

• 如果被识别为：侧重快速验证的，无需复杂的调试和调优的，无需长期维护的系统，适合用这种低代码平台开发。

Claude Skill 的本质

前面在讲 Agent 和 MCP 的时候，重点放在“如何拆任务、如何编排工具”上。

Claude Code 的 Skill 看起来又多了一层概念，实际本质上，它就是一种 “工程化的 Prompt 组合”。

从发展历程来看，最早系统提示词不过几千字。后来随着功能迭代，很快出现上万字的系统提示词，现在很多系统的系统提示词已经达到10万字级别，快速膨胀的系统提示词为AI提供了详细的指引和事例，增强了输出的稳定性，但是膨胀的系统提示词也带来很明显的问题，例如维护复杂，成本偏高，注意力稀疏等。 Claude code skill就是希望解决这个问题，避免一次把所有的提示词都塞给大模型，而是让提示词在需要的时候出现。并且把提示词按skill的维度维护和复用。

从 Claude 的视角看，一个 Skill 会影响三件事：

• 怎么理解你的需求

description 和正文里的说明(也称为元数据)，告诉模型：

• 这个 Skill 适合处理什么问题；

• 在什么触发条件下应该使用它。

• 用什么“角色与步骤”来思考

SKILL.md 中的 Instructions，其实就是一段固定的系统提示：

• 当前扮演什么角色；

• 解决这类问题时按照什么步骤来做；

• 有哪些必须检查的边界条件。

• 可以用哪些工具 / 资源

  • allowed-tools 限制可以调用的工具范围；

  • scripts/ 和 templates/ 提供了可调用的脚本、复用的输出框架。

一句话总结，Claude Code Skill是采用元数据常驻+按需加载完整提示+拼接至当前对话上下文的机制，由主模型结合Agent能力执行，无独立新上下文或者模型。

Skill 的本质是 Prompt 的自定义组合。从底层实现看，Skill 并没有对模型做什么“魔法增强”，例如，只是改变输入给模型的“系统提示和上下文”；不引入新的推理能力，只是帮你提前做好“角色设定 + 步骤约束 + 工具限制”；也不神秘调用额外 API，本质上是把一组约定好的文件内容按需拼到上下文里。

Skill 带来了几个工程层面的好处：

• 可重用：一次写好，在任何符合条件的交互中自动复用；

• 可发现：Claude 可以基于 description 自动决定何时使用哪个 Skill，而不是靠你记住一堆 Prompt 文本；

• 可协作：SKILL.md 和脚本可以进 git，团队一起维护；

• 可控：通过 allowed-tools 做边界控制，比在 Prompt 里“口头约定不要修改文件”更可靠。

Claude 的 Subagents / Skills / Plugins：关系与选型

我们在前面已经分别对这些概念进行了梳理，这一小节中我们简要地综合放在一起讨论。它们看起来名字很多，本质可以简单理解为三层封装，从“轻”到“重”：Skill → Subagent → Plugin。

Subagents：专用“小 Agent”，侧重“上下文隔离 + 工具配置”

官方定义里，Subagent 是：

• 一个预配置好的“AI 人格”；

• 有独立的系统提示、独立的上下文窗口；

• 可以配置自己专用的工具权限；

• 当主 Agent 遇到匹配场景时，可以把任务委派给对应的 Subagent。

它解决的问题主要有三个：

1. 上下文隔离：子 Agent 有自己的上下文，不会被主对话里的噪音污染；特定任务（比如“安全审计”、“日志分析”）可以在干净的上下文里反复迭代。

2. 专业化配置：每个子 Agent 可以用不同的系统 Prompt、不同的工具组合；比如“只读日志分析 Agent” → 只开 Read/Grep 等工具；“部署 Agent” → 只开 CI/CD 相关工具。

3. 可复用、可分享：一个设计好的子 Agent，可以跨项目复用；在团队内共享，形成统一的“专用助手库”。

可以把 Subagent 看成是：“一个带独立 Prompt、独立上下文、独立工具权限的小 Agent”。

Skills：Prompt + 资源的工程化模块

前面已经讲过：Skill 本质是“Prompt 组合 + 资源打包”。再强调几点：

• 它是model-invoked：Claude 根据描述自动决定何时用某个 Skill；

• 它主要解决：重复性 Prompt 的收敛与复用；为某类任务提供稳定的“思考路径 + 步骤说明”；挂接脚本 / 模板，让模型在需要时自动引用。

如果说 Subagent 是“一个专用助手”，那 Skill 更接近：“这个助手的一项具体技能/套路”。

比如子 Agent：“安全审计 Agent” 的Skills有：“扫描常见 XSS 注入点”，“检查依赖库安全告警”，“生成安全修复建议的标准模板”等。一个子 Agent 可以内部调用多个 Skill，Skill 则是更细粒度的“Prompt 模块 + 工具组合”。

Plugins：把一整套 Agent / Skills / MCP 打包对外分发

Plugin 的层级更“外壳化”一些：

• 插件可以包含：预配置的 Agents / Subagents；一组 Skills；MCP 工具；Slash commands、hooks等。

• 安装一个插件，就等于“安装一整套能力”。

比如某个 PDF 处理插件，内部可能带：一个专用 PDF 助手 subagent；若干 PDF 相关 Skills（抽文本、填表单、合并拆分等）；调用外部 PDF 工具的 MCP 或脚本。

从工程视角看，Plugin 解决的是：

• 分发问题：如何把一套 Agent/Skills/MCP 很方便地分享给其他项目和团队；

• 版本管理问题：如何为整套能力做版本号、依赖管理、升级与回滚。

可以把 Plugin 理解为：“把若干 Agent / Subagent / Skill / 工具封装成一个可安装的产品包”。

如何选择：什么时候用 Skill，什么时候用 Subagent，什么时候做 Plugin？

可以用一个简单决策表来思考：

1. 只是一段经常复用的 Prompt / 步骤 / 模板

   1. 1.   例如：“生成我们团队统一格式的 commit message”；“按照既定规范写某类接口文档”。优先做成 Skill。

      1.   好处：编写成本低，只是写 SKILL.md + 少量资源；Claude 可以自动发现并调用；放在项目 .claude/skills/ 里，全团队共享。

2. 需要独立上下文、独立工具权限的专用助手

   1. 1.   例如：“日志分析 Agent”（只看日志、不改文件）；“合规检查 Agent”（只读规范和代码，不执行部署）。考虑做成 Subagent。在这个 Subagent 里再组合若干 Skills，形成完整工作流。

3. 希望打包成产品，在多个项目 / 团队 / 组织间分发适合做成 Plugin。

简单归纳：

• 小而聚焦的套路 → Skill

• 需要独立“人格”和上下文 → Subagent

• 要对外发布 / 多项目分发 → Plugin

把这三者放在一个谱系上看，就更容易设计你的高级能力体系：先从 Skill 把“好用的 Prompt + 流程”沉淀下来，再在此基础上封装成 Subagent，最后根据复用范围决定是否打包为 Plugin。

在线搜索的工作原理

本文希望传递一个理念：“理解一个工具的原理，才能用好这个工具”。对于 AI 在线搜索也是如此。

大部分 AI 聊天工具的在线搜索功能，其背后原理是搜到相关关键字的多个网页，爬下来再使用 RAG（Retrieval-Augmented Generation，检索增强生成）提取出几十段相关性较高的内容送给 AI，很少直接把网页完整地送给模型，这样上下文会爆掉。

因此，很多 AI 在线搜索功能采用的是一种 RAG 流程：搜索 → 抓取 → 向量检索/重排 → 送给大语言模型回答。 为了响应速度，往往只选少量片段给模型，用得好可以兼顾广度与效率；但在一些需要深度阅读与推理的任务上，仅靠一次浅层 RAG 很容易不够用。

相对的，如果开个小模型去做总结和观点提炼，用户体验上一定会慢很多。但输出信息密度不会明显丢失，因此深度是够的。

在使用 AI 搜索时的建议： 如果任务特别依赖深度的话，反而这种在线搜索的效果会不好。注意，这里出现的一切对比都是相对的。当然，大部分日常的工作对搜索深度的要求并不高。

深度研究的本质

深度研究功能在豆包，ChatGPT，Gemini等对话助手都能使用，开启深度研究后，AI会针对问题收集更多的信息，整理更多的内容，汇总更多的要点，输出更高的质量。

开源社区也有很多研究型 Agent，内部也是通过复杂的工作量实现任务目标。

但这类用户体验有一个关键的特点：慢。

本质上深度研究就是一个通用的 AI 工作流，通过分解任务来增加长文本输出的质量。和“AI 联网搜索”功能相对，这个方式的信息整理时大概率用了一些小模型提取内容，而非采用以 RAG 为主要获取信息的手段。

深度研究模式往往会在搜索/RAG 的基础上叠加：多轮抓取与递归摘要；对不同维度（事实、论点、反例、结论）的结构化抽取；基于小模型或同一大语言模型的多阶段处理等。

因此该方式适用场景：需要长文本输出；需要在量文本中深度检索信息；回答的问题需要高质量整理信息的上下文场景。本质上是弥补了RAG快速搜索劣势。现阶段不建议对“深度研究”抱料事如神的期望。

难点在哪里？

深度研究功能背后思路其实高度相似：用规划 + 多轮检索 + 结构化中间结果，换取更可控、更可验证的输出质量。真正的能力差异，不在于“模型是不是更聪明”，而是你能不能把这个工作流设计好、选对场景去用。

也就是说，难的地方在于对当前任务的理解深刻，明白什么时候应该用什么工具，什么方式，达到什么预期效果。

很多人不重视预期效果，如果你的预期效果是没有的，那么没法验证思路和迭代闭环。

---

六、AI 时代的开发者能力与未来趋势

1. 不要神化，也不要矮化 LLM

虽然从数学形式看，大模型确实是在做“下一个 token 的概率预测”。但为了把这件事做好，它不得不在训练中抽取和压缩：语言习惯与语法结构；概念之间的关联；常见推理链条和问题拆解方式；代码、公式、自然语言之间的对应关系等等复杂的内部逻辑。

这些被编码在高维参数空间里的模式，让它呈现出一种前所未见的“类智能行为”，例如：

• 能举一反三写出没直接见过的框架代码；

• 能把业务描述翻译成相对合理的数据模型和接口设计；

• 能在复杂文本里抓关键约束，给出结构化总结。

我们可以把 LLM 看成“高维模式抽取器 + 语言表达器”，再用工程手段把它驯化为可复用的生产力。

2. 模型演化方向：从堆料到效率

在数据和算力逼近上限后，演化方向必然会从“堆料”转向“效率与工程化”。

可预期的技术层面的变化包括：

• 更长的上下文（含更高效的长序列架构）；

• 更自然的工具调用和多模态理解（代码、UI、图像、日志等）；

• 更强的推理能力、更少的幻觉。

另外，在方法论层面包括：

• 工程化优先：系统思维、评测闭环、人机协作流程成为基础设施；

• 数据质量优先：强化多轮训练、人类反馈、指令微调；

• 渐进式演化：从“AI 辅助”到“AI 驱动”，再到部分场景“AI 自主”。

我们可以持续对这些领域保持关注。

3. 开发者的核心竞争力：变与不变

在 AI 时代，开发者的核心竞争力有变化，但底层没有变。笔者认为：

技术深度依然重要：理解系统底层原理；性能优化与故障排查；做架构设计与权衡。

工程素养变得更关键：需求分析与拆解能力；系统思维和整体权衡；质量意识和测试思维。

人机协作能力成为新基础：Prompt 与上下文工程能力；高效利用 AI 工具的能力；判断与验证 AI 输出的能力。

学习与适应能力变得更重要：快速学习新技术和工具；批判性思维：能质疑模型输出；保持好奇心和长期主义。

简而言之，编程的核心从来不是“敲代码”，而是建模世界、做出合理抽象与选择。AI 可以替你敲键盘，但不能代替你思考和抉择。

---

结语：拥抱 AI，守住本质

AI 不再是“要不要用”的问题，而是“你怎么用得好”的问题。

它会加速一些既有趋势：乐于学习、愿意动脑的人，会被显著放大能力；拒绝变化、只追求短期爽感的人，也会很快暴露问题。更现实一点说：AI 会放大你的能力，也会放大你的短板。

如果你有判断力、有好奇心，并且愿意对输出负责，它能让你在同样时间产出更高质量的系统与产品。

如果你懒得思考，只把它当“自动代码生成器”，那么你可能在短期看上去很高产，但谁都不敢接你的代码。

AI 浪潮既是机遇，也是镜子。它会放大你的能力，也会放大你的短板：

• 有判断力、有好奇心、愿意对输出负责的人，会被显著放大生产力；

• 把 AI 当“自动代码生成器”、不愿思考和验证的人，短期看似高产，长期往往在制造技术债。

技术最终服务于人。 让 AI 帮我们提高产品质量和用户体验，而不是单纯堆功能和速度；在自动化的同时，仍要坚持对工程本质和质量底线的理解。 希望这篇文章，能帮你少踩一些坑，更快地把 AI 变成自己的“生产力放大器”。

---

致谢

感谢在 AI 编程实践中与我交流、讨论、碰撞观点的同事和朋友。

本文的许多想法来自我们的共同探索。如你有补充或不同观点，欢迎随时交流，一起迭代这套方法论。