2025 复盘 | 穿越AI焦虑周期，进化为 "AI全栈"

1. 今年一定

好几年没写「年终总结 」，翻了下「掘金」，上一篇还停留在「2021年 」，倒不是这几年没活过，也不是不想写，只是每次都止步于「拖延」。每到年底，脑子里就会蹦出的各种想法，被我零散地记录在 "大纲笔记" 中：

写这玩意挺废「时间」和「心力」，所以总想着 "找个周末，花一大块时间，好好梳理一下"，结果都是一拖再拖：拖到元旦，拖到春节，拖到元宵。

然后，转念一想："这都明年了，还写个🐣毛啊？算了，算了，明年一定！"。2022、2023、2024 就在这样的 "明年一定" 中溜走了...

人到中年 ，主观感觉「时间」过得越来越快，「记性」也大不如前，很多当时觉得 "刻骨铭心 " 的瞬间 (如：结婚、当爹)，如今回忆起，就剩下一个 "模糊的轮廓 "。不写的话，又是「摸 🐟 」一年，趁着 2025 年还没过完，很多感觉还是热乎的，赶紧动笔，今年一定！！！

2. 如此生活30年，直到大厦崩塌

2025 年，对我冲击最大的当属 "AI "，大到让我不得不重新审视「自己的工作和价值」。

我接触 AI 并不算晚，2024 年那会跟风玩了下 ChatGPT ，后面在 GitHub Copilot (便宜盗版，30¥/月) 的协助下，快速交付了一个爬虫单子。尝到 "提效甜头 " 的我，咬咬牙上了 年付正版 (100刀/年) 的车。

当时 AI 在我的眼里，只是个 "比较聪明的代码补全工具 "，可以帮我少些几行代码，仅此而已，因为 逻辑还得我来把控。

但到了 2025 年，事情却变得有点不一样了：

AI能读懂/分析整个项目、重构屎山代码、把一个模糊的业务需求实现得有模有样。

当然，最让我 "破防 " 的还是它的 "解BUG" 能力：

按照以往的习惯，我得去 Google 、翻 Stack Overflow 、看源码，少说得折腾半天。现在，把 报错日志 和 相关代码 丢给它，通常几秒就能：指出问题所在 ，给出解决方案 ，甚至可以 帮我改好并测试通过。

积累多年，一度 "引以为傲 " 的「编程经验 」(对API的熟练程度、快速定位BUG的直觉、配置环境的熟练度等) 在 AI 的面前，变得 "不堪一击 "。渐渐地，我的「工作流程 」也发生了改变，"亲手 " 敲下的代码越来越少，取而代之的是一套 "机械化 " 的 "肌肉记忆"：

写注释 → 等待AI补全 → 按Tab：哪怕脑子里知道下一行该写什么，手指也会下意识停顿，等待那行灰色的建议浮现，然后无脑按下 Tab。
提需求 → 生成代码 → Accept ：把业务逻辑描述一遍，丢给 AI，都不太细看生成的具体实现，直接点击 Accept All ，主打一个 "能跑就行"。
运行报错 → 复制日志 → 丢给 AI：遇到 Bug，第一反应不再是去分析堆栈信息 (Stack Trace)，而是CV日志到对话框，问它："解决报错：xxx"。
效果不对 → 截图 → 丢给 AI：连描述问题的精力都省了，直接截图往对话框里一扔，附上一句 "改成这样"。

代码跑通了，效率提高了，却带来了精神上的「空虚」，我似乎再也感受不到当初那种「编程的快乐」：

为了解决某个问题，苦思冥想，抽丝剥茧，最后成功 "破案 " 时 "多巴胺疯狂分泌 " 的 "快感"。
查各种资料、反复推敲、验证，最终设计出一个自己觉得 "牛逼哄哄 " 代码架构时的 "成就感"。

同时，也陷入了一种深深的「自我怀疑与迷茫」：

越来越搞不清楚自己的「定位」(存在价值)，上面那套 "连招 " 找个实习生培训两天也能干。我曾赖以为生的那些 "技能"，正变得廉价、可替代、甚至有点多余 ...
找不到方向 ，以前「程序员成长路径 」很清晰：学语言 → 学框架 → 学架构 → 学系统设计 → 刷算法 → 搞源码 ... 只要你一步步往上爬，爬到 "山顶 " 就能成为 "大牛 "。而如今却好像 "失效" 了...
可控感被剥夺 ，程序员是典型的「内控型人格 」------ 相信通过逻辑和细节掌控能预测一切。而但 AI 的「黑箱特性 」带来了「工具不可控 」，无法完全准确预测AI输出，调试从 "追踪逻辑 " 变为 "试探模型"。

3. 调整对待AI的心态

3.1. 从 "焦虑" 到 "接纳"

我深知「焦虑」无用，于是开始探寻「破局之道 」，反复阅读大量资料后发现，几乎所有人都在让你「拥抱 AI 」，但具体怎么拥抱法？没人说，或者说得含糊不清，有些甚至还想割我 "韭菜" 🤡 ？屏蔽这些噪音，冷静下来复盘，拨开情绪迷雾，透过现象看本质。

首先，坦诚地「接纳」肯定是没错的，历史的车轮从不因个人的意志而停止转动，当 第一次工业革命的蒸汽机 轰鸣作响时，那些坚守手工工场的匠人们，也经历着相同的困境。精细手艺 在不知疲倦、效率千倍的 机械化工厂 面前显得苍白而无力。大机器生产取代手工劳动，不是一种选择，而是一种必然的 "降维打击"。

现在，我们同样站在了 "生产力变革 " 的周期节点上， "效率至上 " 的底层逻辑从未改变。是选择成为被时代甩下车的 "旧时代纺织工 "？还是进化为驾驭机器的 "新时代工程师 "？回归「第一性原理 」，剥开 "智能 " 的外衣，想想 "AI 的本质是什么?" ------ 「干活的工具」

所以，面对 AI，我们要做的事情就是琢磨 "如何用好这个工具? "，即：详细阅读使用说明后，在合适的场景，用合适的方式，解决合适的问题。

3.2. AI 有什么用？------ 能力放大 + 自学利器

3.2.1. 能力放大器

🐶 经常在 自媒体平台 刷到 "普通人学AI后致富/逆袭 " 的叙事，看到这些 "逆天标题" 没把我笑死：

多的不说，记住这段话就对了：

变现的核心能力从来不是使用工具，而是商业认知、市场洞察、营销推广、客户服务 。AI 只是一个环节，不要高估了工具的作用，而低估了 商业常识的重要性 ，也不要低估了背后的 隐性成本和巨大的工作量。

这些 "AI变现教程 " 的 最大问题：

让你把AI当成一个独立的、全新的、需要从零开始的 "行业" 去卷。

对于 99% 的普通人而言，把AI看作 "能力放大器" 会更靠谱一点，即：

思考如何利用AI，帮我把我已有的技能/兴趣做得更好？

比如：

用 AI 减少重复劳动，提高工作效率和质量，把时间花在更有创造力的事情。
AI 负责广度，你负责深度，在你热爱的小众领域里用AI武装自己，做到 "人无我有，人有我精"。

今年「Vibe Coding (氛围编程) 」很火：

用自然语言描述想要的效果，AI帮你写代码，你只负责验收结果和提修改意见，不用管具体代码怎么实现的。

编程门槛大大降低，普通人 只要能把 创意和感觉 翻译成需求，就能借助 AI 将其快速具象化为 可运行的产品。

但你会发现，绝大多数生成的作品都是 "一次性原型或玩具"：灵光一现即可实现，却缺乏持续迭代、架构设计与用户验证，因此难以具备商业价值、也难形成可持续的产品形态。

真正能够利用 Vibe Coding 实现变现的，往往是具备一定 编程经验 或 产品思维 的 "专业人士 "。他们不仅能用 AI 快速实现灵感，还能对作品进行持续优化、迭代和工程化打磨，从而将 "灵感原型 " 进化为 "可用产品"。

再说一个自己观察到的例子，前阵子 OpenAI 发布了用于生成短视频的「Sora2 」，B站很快涌现了一堆 AI 生成的 "赛博科比" 恶搞视频。

看到一个播放量破百万的作品有点意思，点进 UP 主的主页想看下其它作品，结果发现他并不是突然爆火的 "新人"，人家已经默默做了好几年视频，只是过去的播放量惨淡 (几十几百)。但他却一直坚持创作，尝试不同的方向，能清晰地看到他的剪辑、叙事和整体制作水平在一点点提高。

AI 不会让没有积累的人"平地起飞"，但有可能让有准备的人"一飞冲天"。---《抠腚男孩》

3.2.2. 自学利器

看到这里，可能有人会问：

"那普通人怎么办？我没啥专业技能，也没有长期积累啊？ "

简单，那就 "学" 啊！！！以前学习的最大限制是什么？

没人教、教不好、学不动、坚持难

而现在，你有了一个「全知全能、知无不言、24小时为你服务的免费老师」

不会写代码？手把手教你，从逻辑到示例一步步拆开。
想转行？给你路径、资源、练习清单、复盘建议。
想跨领域？帮你建立知识框架，把陌生领域最难啃的部分变简单。
遇到瓶颈？像一对一导师一样不断提问、引导、纠偏。

当然，想要这台 "自学利器 " 高效运转起来，实现 快速学习/试错/跨域 还需要掌握一些 方法论。

详细解读可以参加我之前写的《如何借助AI，高效学习，实现快速"跨域"》

3.2.3. 不要神化 AI

🐶 2333，经常刷到 "xx公司发布新的 xx 模型/AI产品颠覆行业，xx师要失业了" 的标题，但事实真的如此吗 ？最近 Google 家的 Nano Banana Pro 🍌很火，号称当前 "最强AI生图" 模型，亲身体验下确实强 (本文大部分配图就是它出的)，天天在群里吹爆。

某天晚上，有 "多年专业设计经验" 的老婆收到一个改图需求 (抠素材，按要求调整海报)：

😄 看着简单，感觉 🍌 就能做，于是我提出和老婆 PK 下，她用 PS 改，我用 🍌 嘴遁修图，看谁出的图又快又好。结果：她10分钟不到就改完，而我跟 🍌 Battle了半个小时没搞好，最终的效果图 (左边她的，右边我的)：

🤡 "甲方" 的评价 (破大防了😭)：

观察仔细的读者可能会问："你是不是漏了一个车🚗啊？"，憋说了，这破车把我调麻了...

那一刻，我深刻体会到了什么叫 "不要拿你的兴趣爱好，去挑战别人的饭碗 "，真的是 "降维打击" 啊！

AI 确实拉低了创作的门槛，但目前还处于生成 80分 内容的阶段 (效率)，最后的 10-20 分 (细节、审美、情感) 才是价值的核心。------《抠腚男孩》

后面复盘，老婆看了下我的 Prompt ，说我的流程有点问题，应该让 AI 先把素材全抠出来先，再慢慢组合。后面试了下，效果确实有好一些。不过，不得不说，AI 在 自动抠图 这块确实可以：

🤣 老婆在日常设计时也会用 AI 来偷懒，比如：生成配图、提高清晰度、扩图等。

3.3. AI 是什么? ------ 概率预测机器

现阶段谈论 AI ，其实都是在谈论 大模型 (LLM ) ------ 一个极其复杂的 "概率预测机器"。

通过学习海量数据的 "统计规律 "，逐步逼近这些数据背后的 "概率分布 "，从而能够在给定 "上下文" 时预测最合理的下一步输出。

不同类型产物的生成原理图解 (看不懂没关系，简单了解下即可)：

① 文本

② 图片 (扩散模型 & 自回归模型)

③ 音频 (自回归模型 & Codec + Token 预测 )

④ 视频 (扩散式 & 自回归/时空Token)

3.4. AI 的能力边界 ------ 优/劣势

LLM 擅长发现 "相关性"，但难以进行真正的 "因果推理"，它只是在 "模仿智能"，而非 "真正地理解意图，拥有意识"。 ------ 《抠腚男孩》

弄清楚 AI 的本质是 "概率预测机器 " 后，接着从 "代码生成 " 的角度梳理下它的 "优势 & 劣势"：

了解完 AI 的 优/劣势 后，接着就可以推演「人 & AI 」的 高效协作方式：

一句话概括：

AI 负责 "生产力 " (重复、繁琐、高上下文、高整合的工作)，人负责 "方向与边界" (判断、创造、决策、理解组织与业务)。

4. 必备技能 ------ Prompt

一般译作 "提示词 " 或 "描述词 "，个人认为后者更加贴切，即：描述问题/需求的 "词句组合" 。「Prompt Engineering-提示词工程 」是所有人都必须掌握的 "使用AI的核心技能"。

4.1. 把话说清楚

🐶 别被几个英文单词吓倒，现在的 AI 比几年前聪明多了，普通人 只要能：

把诉求讲得清晰、完整、有逻辑，就能解决绝大多数问题。

示例：

❌ 混乱说法：帮我计划个周末玩的地方。
✅ 有条理说法：周末想带5岁孩子一日游，2大1小，预算500以内，北京，不想跑太远，能放电、有吃饭的地方、避开暴晒，地铁可达最好。

AI输出结果 (前者输出不同城市的游玩方案，后者输出了具体的行程方案)：

4.2. 套框架

再往上走，就是了解一些经典的 "Prompt框架 "，然后再提问时套用，以提高 AI 输出的稳定性、准确性和质量。所谓的 "框架 "，其实就是 "结构化模板 "，规定问题中包含哪些 "要素 "，比如最经典的「CTRF」框架：

套框架示例 (填空题~)：

常见的框架还有 RTF 、COSTAR 、SPAR 、COT 、APE 等等，适用于不同的场景。杰哥整合了自己知道的所有框架精华和高级技巧，弄了通用的「Prompt 最佳实践清单」

无脑套就是了，助记口诀：

也可以用故事流程来串联助记，读者可自行发挥，顺序无需固定：

让一位说书人 (角色 ) ，用生动的语气 (风格语气 ) ，给孩子们 (受众 ) 讲个故事 (指令 ) 。故事的开头 (上下文 ) 是...，结局 (目标 ) 要感人。故事的结构 (格式 ) 要像这样 (示例 ) ，但不要 (约束 ) 出现暴力情节。请先构思情节 (逐步思考 ) ，写完后再想想怎么能更精彩 (反思) 。

😄 懒得记的话，可以用我之前搭的小工具 →「CP AI Prompt助手」

配下 DeepSeek 的 Key ，复制粘贴你写的 简单Prompt，它会基于上面的十个维度对提示词进行优化：

4.3. 写出牛逼的Prompt

明白了怎么 "套框架 " 写 "结构化的Prompt"，但你可能还是会感到疑惑：

用的同样的AI，为什么别人的生成效果就是比我好？

尤其在 AI 生图 领域，看大佬分享的 Prompt，里面一堆看不懂的专业参数：

环境、构图、光影、景深、镜头、光圈、色调、氛围、胶片颗粒、对比度、主体增强、氛围灯...

能写出这么 专业的Prompt ，是因为他们有 "相关领域的行业经验" 吗？

答：有加成，但不全是。高手的核心技能不是 "记这些专业知识 "，而是：知道如何指使 AI 给自己提供专业知识、框架、术语，然后再反向用这些框架让 AI 编写和优化 Prompt。

😄 其实思路很简单，拆解下这套方法论：

维度词 → 术语/词库 → 通用模板 → 填空得第一版Prompt → AI专家视角优化 → 迭代优化沉淀

详细玩法可以看下图：

4.4. Prompt 逆向

Prompt 逆向工程 （RPE ，Reverse Prompt Engineering)，就是：从 "输出 " 反推 "是什么Prompt " 生成了它。一般用于：学习优秀案例 、调试和诊断问题 、构建Prompt库和模板 、企业质量控制 、安全审计 (防御Prompt注入攻击)。

4.4.1. 简单版

普通人 用这个套路就够了，选个聪明点的模型 (如：GPT5 或 Gemini 3 Pro )，粘贴图片，写 Prompt 让它反推：

差得有点远，描述「不满意的点」，让AI继续优化Prompt：

接着用优化后的 Prompt 来生成，可以看到效果差不多了，接着让 AI 提取一个「通用的Prompt」

拿 AI 生成的 Prompt 生图，看效果，描述问题，循环反复，直到稳定生成自己想要的效果~

4.4.2. 专业版

🐶 其实也差不多，只是流程比较 "标准化 "，经常搞还能自己搭个 "工作流"，适合专业选手，思路：

快速拆解 → 推断 Prompt → 提取要素 → 重建 Prompt → 优化迭代 → 模板化沉淀

详细图解：

上面是通用的，还有几个 额外功能 的玩法也罗列下：

5. 锦上添花------懂点AI常识

🐶 懂点AI常识，能让你更 有的放矢 地 用好AI (装逼 )，比如：连 Token 都不知道的话，就有点贻笑大方了。这里只是简单罗列下相关名词，不用死记，有个大概印象即可，不影响你使用AI，跳过也没关系。😄 详细讲解，建议直接复制名词问题AI，也可移步至《AI-概念名词 & LLM-模型微调》自行查阅~

5.1. AI (人工智能) 基础概念

5.2. NLP (自然语言处理)

5.3. Transformer 架构 (大型模型基础)

5.4. 语言模型基础 (Language Models)

5.5. LLM 核心概念 (Large Language Models)

5.6. 数据与训练流程 (Training & Fine-tuning)

5.7. 推理阶段 (Inference)

5.8. RAG (检索增强生成)

5.9. 多模态 AI

5.10. AIGC (生成式内容)

5.11. 模型压缩、部署与加速 (LLMOps)

5.12. Agent (自主智能体)

5.13. AGI (通往通用智能)

6. AI 编程领域专精

😄 最后，聊聊 AI 编程 领域的一些心得~

6.1. 前置知识

6.1.1. 编程模型

AI 代码写得好不好，主要看 "模型 " 的 "编程能力 "，评估 "模型优劣 " 的几个 "常见维度"：

LLM 的能力很难用一句话概括，所以厂商们每次发新模型都会用一堆 Benchmark 来证明 (🐶不服，跑个分？)

① 推理与数学能力 (Reasoning)

"智能的核心指标 "，高分意味着能够做更复杂任务 (如：工程规划、Agent等)，常见基准：GSM8K -小学奥数式数学题、MATH -高难度数学、AIME/AMC -奥林匹克数学、GPQA -博士级科学问答、BigBench Hard (BBH)-推理难题集合等。

② 语言理解与知识能力 (Language / Knowledge)

"通用模型 IQ 测试 "，常见基准：MMLU -大学生多学科理解测试、MMLU-Pro - 更难版本、ARC / HellaSwag - 常识推理、OpenBookQA/TriviaQA - 事实/知识问答等。

③ ✨编程能力 (Coding)

"商业价值极高的应用点 "，常见基准：HumanEval - 函数级别代码生成、MBPP / MBPP+ 简单编程题、SWE-Bench / SWE-Bench Verified ✨：真实 GitHub issue + 多文件工程 (最接近真实开发场景，近两年厂商都在比这个)、Codeforces-算法比赛、CRUXEval / RepoBench-项目级分析等。

④ 多模态能力 (Multimodal)

"下一代 AI 产品的必争之地 " (做 AI 助手、看图、自动化办公等)，常见基准：MathVista ：带图的数学推理、ChartQA / DocVQA ：文档理解、TextCaps / ImageNet ：视觉场景理解、VideoMME ：视频理解、V-Bench / VQAv2：视觉问答等。

⑤ 安全性 (Safety / Robustness)

企业用户很看重 "安全合规 "，常见基准：Harmlessness / Truthfulness 、AdvBench ：对抗攻击、Red Team 红队测试 、Over-Refusal 测试 （不会乱拒绝）、Speculative Safety（推测生成的风险）等。

⑥ 速度/延迟/吞吐 (Performance Metrics)

"决定实际用户体验"，常见指标：Tokens per second (推理速度)、First Token Latency (首字延迟)、Throughput QPS (每秒处理请求数)、Context processing speed (长文档处理速度)。

有时还会发布一些 "技术参数"：

模型规模：模型的参数量大小，影响推理与表达上限，规模越大，能力越强，但成本、延迟和部署难度也越高。如：70B = 70 billion = 700亿参数。
训练数据规模 ：模型预训练时学习的 token 总量，代表其知识 "阅历"。数据越多通常知识覆盖越广，但质量、去重和清洗策略比单纯堆量更关键，高质量数据才能让模型表现更稳。如：15T = 15 trillion = 1.5万亿个token。
上下文窗口 ：模型单次可接收并 "记住 " 的 "输入长度上限"，决定你能塞多少代码、文档和对话历史；窗口越大越适合做整仓分析、长文档问答、复杂任务，但会牺牲成本和延迟，且需要额外机制确保在超长上下文中仍能抓住重点。
推理深度 ：模型答题时的 "思考力度"，深推理模式更准确、适合复杂问题，但会更慢、更贵，适合关键任务而非高频交互。
价格：按 token 收费，区分输入价、输出价与最小计费单位；部分模型提供 "缓存命中 (cache hit) "，对重复提示只按更低费率计费，大幅降低长上下文与多轮调用成本。价格决定模型可否大规模、频繁和低成本使用。
延迟标准 ：包含首 token 延迟 (FTL ) 与 生成速度 (token/s)，分别决定 "多久开始回应 " 和 "内容生成有多快"；低延迟让补全、对话、Agent 流程更流畅，而高延迟会严重影响开发体验与实时性，是工程中比 "更聪明一点" 更重要的性能指标。
模型行为控制能力：通过 Temperature、Top-p、System Prompt、工具权限等机制控制模型的随机性、稳定性与执行边界；行为越可控，越能确保输出一致、不跑偏，并安全地接入工具链或生产系统，是把模型从 demo 提升到可上线能力的关键参数。

🤡 个人 "主观 " 认为的 "编程模型" 能力排名：

😊 一句话概括我的 "选模型策略"：

选好的模型事半功倍！工程大活 找 Claude ，精细小活 (如改BUG) 用 GPT ，写前端页面用 Gemini。

🐶 问：这些都是国外的模型啊，怎么才能用上？A社还锁区，经常封号？而且价格好贵啊？

答：😏 这个问题充钱可以解决.jpg，多逛下海 (xian) 鲜 (yu) 市场，国人的 "薅羊毛 " 能力不是盖的，各种 "镜像站、第三方中转" 。氪金的时候注意找有 "售后 " 的，随用随充，买 "短期 (如月付) "，不要买 "长期 (如年付)"，这种看 LLM官方 政策的，一封就直接G了，说不定就 "卷款跑路"~

6.1.2. AI 编程工具的四种形态

😄 一句话归纳：

普通开发者 & Vibe Coding用户 用 AI IDE/插件 居多，DevOps/后端工程师 用 CLI ，团队/企业系统 用 云端Agent ，AI 应用开发者 用 AI SDK 构建构建 AI 产品与 Agent 系统。

接着说下 "AI编程" 的三种演进层次~

6.2. 第一层：AI 辅助开发

最早期的AI开发方式，以「人主导 + AI辅助」为核心逻辑，由两种交互模式组成：

补全式：基于输入光标前的上下文，预测下一个单词、下一行代码、甚至整个函数。
对话式：在 IDE 侧边栏或网页中，通过自然语言问答来生成代码、解释代码或查找 Bug。如："帮我写一个 Python 的正则来验证邮箱" 或 "这段代码为什么报错？"

这一层的局限：

上下文有限：AI 通常只能看到当前文件或少量相关片段，缺乏对整个项目架构的理解。
被动性：AI 不会主动修改你的代码文件，它生成代码，你负责复制粘贴和校验。
人是瓶颈：所有的决策、文件切换、环境配置都必须由人来操作。

6.3. 第二层：AI 驱动开发流程 (规范+Agent)

目前最前沿、最热门的阶段，AI 不再只是吐出代码片段，而是进化为 Agent (智能体)，拥有了 "大脑 " (规划能力) 和 "手脚 " (工具使用能力)，可以 "自主完成一个多步骤的开发任务"。

变成了「人定目标 + Agent 自主执行」，如："实现一个简单的待办事项 Web 服务，要求：REST API，内存存储即可，有单元测试"，Agent 可能会进行这样的任务拆解并执行：

设计目录结构 → 创建代码文件 → 写业务逻辑 → 写测试 → 运行测试并自我修复。

为了系统地应用 Agent ，业界逐渐采用「 "规范"驱动的开发流程」(Spec-Driven Development)：

需求 → 规范文档 → 任务分解 → Agent执行 → 验证反馈

这个流程确保了 清晰的目标定义 和 可追踪的执行过程 ，而不是让Agent盲目操作。开发者需要维护的 "三类规范" (规范必须比写代码更清晰)：

功能规范：目标、用户故事、输入输出、性能要求、鉴权、边界情况等。
技术规范：模块结构、API、模型字段、状态机、异常流程等，Agent会根据这些自动创建项目。
验收规范：测试通过、接口返回正确、性能满足要求、行为与设计一致，即每个功能的评价方式。

人不再写代码 (或者少写)，负责「定义 + 审核 + 授权 」，人-Agent 协作 的三阶段循环：

人主导-目标设定：范围、约束、边界、不允许做的事情。
Agent主导-执行：分解、规划、写代码、自动Debug、修复、生成报告。
人主导-验收：代码质量、安全性、单元测试覆盖率、偏差是否满足业务需求等。

💡 层2 关注的是「开发流程自动化 」，任务的起点通常是 "已经确定好的需求/feature"。

6.4. 第三层：AI 全栈

所谓的 "AI 全栈 "，本质上就是 "让 AI 同时扮演多个软件开发角色 "，而 "一人分饰多角 " 的自然实现方式就是 "多 Agents "。------《抠腚男孩》

6.4.1. 为什么聊到 "AI全栈" 就会扯到"多 Agents"?

🤔 想象一下让 "AI全栈开发一个应用" 需要经历哪些步骤？

产品需求理解 → 技术选型 → 架构设计 → API 设计 → 前后端代码生成 → 数据库 schema → 错误处理 → 文档生成 → 单测编写 → 测试执行 → 部署脚本 → CI/CD 配置。

让一个 Agent 承包上面所有的工作，会有什么问题？

记忆量爆炸、目标切换频繁、推理链拉得太长，错误积累变大、一旦一步出错，后续全崩、风格、结构、代码质量难统一、难以并行。

软件工程是 "多角色协作 " 的结果：产品经理、架构师、后端、前端、测试、文档、DevOps... 如果想 "AI 模拟完整的软件开发流程 "，自然也需要 "让 AI 也模拟这些角色 "，于是就变成了这些 Agent：

Planner / Architect (产品/架构)：理解需求、拆任务、出计划 (Plan)。
Coder / Implementer (实现)：按计划改代码、增删文件。
Searcher / Context Agent (检索)：在代码库里找相关文件、API、调用链。
Tester / QA (写测 / 跑测)：写测试、跑测试、分析报错。
Fixer / Debug Agent (修BUG)：根据测试/运行结果修复代码。
Reviewer / Critic Agent (代码审阅)：检查风格、一致性、潜在 bug / 安全问题
Ops / Deploy Agent (部署)：写 Docker、CI/CD、部署脚本（有些系统只做到生成，不自动执行）

即「AI 全栈 = AI 软件开发流水线 = 模拟整个软件部门 = 多 Agent 系统」，这是开发任务决定的。

"AI全栈" 需要的三大核心能力：

长任务规划 (Planning)：开发一个系统不是线性的，是树状决策结构，要拆分任务，就需要 Planner Agent。
并行执行 (Parallel Execution)：前端、后端、文档、测试不可能一个个线性做。多 Agent 可以：前端 Agent 改 UI、后端 Agent 写 API、Docs Agent 补文档、Test Agent 补测试。
验证 & 修复 (Validation Loop)：真正让 "AI 全栈" 可行的关键是 "循环 "，写代码、跑测试、找错误、修复、再跑，需要 "多 Agent + 状态机" 才能撑起这个能力。

"AI 全栈系统" 的实现，本质就这四步：

「定义一堆上面这样的角色」
「排布拓扑 」决定这些角色之间的连接结构和调用关系。谁先谁后 (拓扑/顺序)、有没有循环 (写→测→修→再测)、有并行吗 (前后端Agent同时干活？)、是由一个 "主管Agent" 指挥大家？还是大家按照状态机自己转？
「给每个角色接上能用的"工具"，让它真的能动手干活 」常见工具：文件 (读/写代码、生成 diff)、终端 (执行命令)、搜索 (在 repo 里搜符号 / 用法)、HTTP/Browser (查文档、查API)、Git (开分支、commit、生成PR)、结构化分析 (AST分析、调用图、依赖图)。比如：Coder Agent 配置 "文件读写、diff 生成、代码搜索" 的工具，用来 "在受控范围内改代码"。
「套一层安全边界 」权限 (读写、只能改指定目录、终端命令必须在沙箱里执行)、人在回环 (关键操作必须人工确认，如：Plan-任务规划、大范围diff、部署相关改动/高危脚本)、防注入/误操作 (不轻信代码库里的"指令"-如：恶意README 写 "rm -rf /"、对外部输入做过滤-日志/错误信息/用户Prompt、限制重试次数，避免死循环修改)。

一句话概括就是：

AI 全栈 = 一群小模型/小角色 + 一个调度关系图 + 一堆工具函数 + 一圈安全护栏

😄 弄清楚本质，以后看任何 "AI 全栈多 Agents" 方案，都可以基于这三个问题进行快速拆解：

它有哪些角色？(Planner / Coder / Tester / Fixer / Ops...)
这些角色是按什么拓扑 / 流程连起来的？
每个 Agent 有哪些工具？安全边界是什么？

6.4.2. 业界主流多 Agent 架构模式

前面AI常识部分有提到过，这里直接让🍌画个图~

6.4.3. 个人级 "AI全栈" 演进历程

🤡 上面的理论看起来简单，但对于个人来说，想要亲手实现这样 一整套多 Agents AI 全栈系统，工作量爆炸：

得自己写调度、管状态、接工具、控安全、做可视化，还要维护一堆 prompt 和配置，算完整平台工程了...

🤔 笔者认为 "个人级AI全栈" 更倾向于：

在个人可以承受的复杂度和时间成本内，让AI参与尽可能多的开发环节，而不是一次性造一个企业级AI工厂。

😄 其实，你可能已经在无形中体验 "AI 全栈 " 的雏形了，现代 AI 编程工具 本身就内置了 多 Agent 编排能力~

① Claude Code Sub Agents

CC 中允许创建多个带 独立角色与上下文 的 Sub Agent (小型专属AI工作者)，用法简单：

创建 Sub Agent

在 Claude Code CLI 输入 /agents ，选择「Create new agent」
选择作用域：项目级 (推荐，只给当前项目使用)、用户级 (所有项目可用)
填写：name (调用的时候用到)、description (决定CC何时自动调它)
选择可用工具 (file_edit / bash / file_search / git ...)
完善系统Prompt：可以先让 Claude 生成，再自己改

保存后，会在 .claude/agents/ 生成一个类似这样的文件：

markdown 复制代码

---
name: backend-dev
description: "专门负责后端接口、服务逻辑和数据库相关代码的实现与修改"
model: sonnet
tools: [file_search, file_edit]
color: blue
---

你是一个资深后端工程师，精通 Node.js + TypeScript 和这个项目的后端架构。
你的职责：
- 只改后端相关的代码（controllers, services, repositories）
- 遵循项目现有的代码风格和结构
- 所有改动都要尽量小步、安全、可读
在给出修改时：
- 标明文件路径
- 用 patch 的风格展示修改
- 如果需要新增文件，要说明用途和引用关系

不想自动生成，可以在 .claude/agents/ 手动按照上面的格式自己写md，保存后 CC 会自动识别。还可以在命令行启动CC时添加 --agents 参数 (适用于临时挂载场景)：

bash 复制代码

claude --agents '{
  "log-analyzer": {
    "description": "分析测试日志和错误堆栈的专用Agent",
    "system_prompt": "你只负责阅读测试输出、日志，帮助定位问题和怀疑文件，不写代码",
    "tools": ["file_search"]
  }
}'

调用 Sub Agent (串起来) 的三种方式

① 自然语言编排，用普通指令描述任务，由 Claude 自动判断并调用合适的 Sub Agent，最灵活、最贴近自然对话的方式。如：请用 backend-dev subagent 修改 search controller 的分页逻辑。
② 结构化点名调用 ，明确指定要调用哪个 Sub Agent，适合需要精确控制执行顺序或避免模型误判的情况。如：Use the test-runner subagent to run the unit tests.
③ 在 Agentrooms 中使用 @agent-name 直接点名，通过@用户的方式派任务，可同时管理多个 Agent，方便多人视图和多 Agent 协作。如：@backend-dev 帮我调整这个接口的返回格式

多个 Sub Agents 协同工作简单示例 (开发 → 测试 → 分析 → 再开发)：

让 developer 生成补丁
让 test-runner 运行测试
让 log-analyst 分析失败原因
再让 developer 根据分析修复
Claude 会自动接力，也可以由你手动编排~

② Cursor 2.0 多 Agent 编排

2.0 后，Cursor 界面从 "以文件为中心 " 变成 "以Agent为中心 "，多了个 Agent Layout，切换后，侧边栏会显示当前 Agent、计划（plan）和改动，你把需求丢进去，Agent 负责读文件、计划、改代码、跑测试。

支持 同一指令 下，最多可并行 (Parallel) 跑 8 个 Agent ，每个 Agent 会在自己独立的 Git worktree / 沙盒工作区 内工作：各自改代码、build、跑测试，不会互相冲突 (🤡 就是费 Token...)。还多了一个 Plan Mode (先规划再执行 )，在 Agent 输入框 中按 Shift + Tab 可以切换到这个模式 (也可以手动选)：

Cursor 不会直接假设你的需求，而是询问一系列澄清问题：

通过这些澄清，使 AI获得了完整的上下文，可以生成更精确的计划，避免后续的返工。接着会生成一个 plan.md 的计划文档：

你可以对文件进行编辑：增删任务、调整任务顺序、更新技术细节、调整实现方法等。确定无误后，点击 Build ，Agent 会读取最新版本的 plan.md，并完成对应的任务。

🤔 与 CC Sub Agents 可编排不同，Cursor 的 Agent 更像是一个组合能力的 "大Agent "，由它自动编排多个内嵌的、对用户不可见的 Agent 来完成 用户提出的任务 ，收敛复杂性，只展示改动/测试结果。它的 Parallel Agents 探索不同方案，最后再汇总/合并的玩法，不算严格意义上的 "主流多 Agent 架构模式 " 中的 "并行Agents模式"-支持显式地定义 / 分配不同角色的 Agent，并让它们并行协作。

类似的支持 "多Agents" 玩法的 AI 编程工具还有：

GitHub Copilot Workspace ：多步骤 Pipeline Agents，从任务描述 → 生成完整 plan → 自动执行 → 修正，多步骤 cascaded agents，自动提 PR。
Google Gemini Code Assist ：multi-expert prompt routing，任务自动分配给最擅长的模型/agent，复杂 monorepo 搜索 → 专家 agent 提供答案，针对 cloud infra 的执行-验证循环。
Replit 的 AI Dev 环境 ：多工具执行 Agent，轻量一站式多Agent开发流水线。
...等，限于篇幅，就不展开讲了~

觉得 AI编程工具 满足不了，接着就是围绕自己的开发流程，开发基于 LLM 的 API 封装一些 小脚本/小工具。

python 复制代码

// 推进开发闭环的简单伪代码 (需求 → 修改 → 测试 → 修复)
plan = llm("你是架构师，帮我拆解这个改动需求...")
files = find_related_files(plan)

patches = llm("你是后端开发，只能改这些文件...", files + plan)
apply_patches_to_workdir(patches)

test_result = run_tests()

if test_result.failed:
    fix_patches = llm("你是调试工程师，根据报错修复...",
                      test_result + current_code)
    apply_patches_to_workdir(fix_patches)

大多数个人开发者达到这一层，基本够用了，再往上就是加：日志、可配置、一点UI、简单任务管理等，弄成一个仅为自己服务的 "AI 全栈开发小平台 " (😄 此时更像是一个 Agent 工程师 ，搭建 "企业级AI全栈" 的基石)。

6.4.4. 落地方法论

根本原则：

在一个完整开发周期里 (从想法到上线)，有意识地让 AI 参与尽可能多的环节，并用 "多角色思维" 来组织这些调用，但工程复杂度要控制在个人能持续维护的范围内。

① 项目级自检

② 项目阶段拆解

③ 搭建可复用工作流

7. 结语

行文至此，再回看这篇拖了许久的 "年终总结 "，心情早已从最初面对 AI 秒解 Bug 时的 "破防 " 与 "迷茫"，变得平静且笃定，我们：

剥开 AI "智能 " 的外衣，看到了它作为 "概率预测机器" 的本质。
学会用 "结构化的Prompt" 去驾驭它，而不是被幻觉带偏。
也见证了开发模式从简单的 Chat 进化成 Copilot ，再到如今初具雏形的 Agentic Workflow。

但归根结底，AI 带来的最大变量，不在于它替我们写了多少行代码 ，而在于它重塑了 "专业" 的定义。

懂得"底层原理"依然重要------否则你不知道为什么 AI 会把人修成 "汽车"，也无法在它 "一本正经胡说八道" 时进行纠偏。
懂得提问比解答更重要 ------ Prompt 是新时代的编程语言，清晰的逻辑表达 + 对业务的深度理解 ，才是最高效的 "编译器"。
懂得架构比实现更重要 ------当 "AI 全栈" 成为可能，当一个个 Agent 可以各司其职，我们不再是死磕语法的 "搬砖工"，而更像指挥数字化施工队的 "包工头 & 总设计师"。

"技术焦虑 " 的解药，从来不是拒绝变化，而是成为变化的一部分。以前，我们的壁垒是 "熟练度+记忆力 "，以后则是 "想象力+判断力+系统工程能力 "，拥抱AI，在这个属于创造者的时代，进化为无所不能的 "超级个体🦸‍♀️"！