最近看到一则消息在技术圈里传得很广Grindr 的 CEO 公开表示AI 已经承担了原本 200 名工程师的工作量。对于正在做技术管理、或者正在重新规划职业路线的开发者来说这个表态确实值得停下来多想几秒。它不是一句简单的“AI 替代人类”的感慨而是一个关于软件生产模式正在发生结构性变化的信号。这篇文章不想只复述新闻而是从工程视角出发把“AI 干了 200 人的活”这句话拆开AI 编程到底在哪些环节真正发挥作用、哪些环节被市场夸大了、团队在落地 AI 工具时应该怎么选型、怎么定流程、怎么控制风险以及工程师个体要怎么应对这种变化。无论你是在大厂做架构、在中小团队做全栈还是刚入行的新人这篇文章都会给你一套可参考的思考框架。1. 背景与趋势Grindr 的声明背后藏着什么1.1 事件简述Grindr 是一款全球知名的社交应用主要面向 LGBTQ 群体用户量级和业务复杂度都达到了一定规模。它的 CEO 在公开访谈中表示通过大规模使用 AI 编程工具公司已经能够用极少数量的工程师支撑原本需要一支庞大研发团队才能完成的开发任务按他的话说“AI 做了 200 名工程师的工作”。这个说法引发了不少讨论。有人觉得这是吹牛有人觉得这是给投资人讲故事但在技术圈内部更值得关注的是另一个事实从 2024 年下半年开始AI 编程已经从一个“能帮你自动补全代码”的效率工具变成了“能理解整个代码仓库、独立完成一个完整需求”的智能体AI Agent。1.2 为什么这个话题值得工程师关注对一个普通开发者来说“AI 替代 200 人”听起来还很遥远但实际上它已经改变了以下三个层面的东西团队规模假设不再成立。过去一个中大型 App 的迭代需要 iOS、Android、后端、QA、运维等多角色协作而现在一个 5 到 10 人的小团队配合成熟的 AI 编程工具确实可以维持一个中型产品的开发节奏。工程师的日常不再是“写代码”为主而是转向“提需求、审代码、改架构、做方案”。写代码越来越像是一种可以被 AI 半自动完成的动作而理解和决策依然是人的工作。技术管理者的成本模型变了。以前评估一个需求要多少人力现在要先问这个需求能不能拆成 AI 可执行的任务多长的周期适合 AI 协作人要介入在哪些节点可以说Grindr 的表态只是把已经发生在行业里的变化用一个更夸张的数字呈现出来了。1.3 本文讨论范围需要说明我们不会去讨论 Grindr 内部到底实际裁掉了多少人、它的工程文化是否健康也不讨论裁员本身的对错。这些信息没有公开的完整数据讨论多了反而变成八卦。我们关注的是技术本身AI 编程工具现在的能力边界在哪里团队如何用工程化的方式落地这些工具以及在 AI 编程加速的背景下一个务实的技术团队和工程师个人应该怎样调整自己的工作方式。2. AI 编程能力拆解它到底能做什么、不能做什么2.1 从代码补全到 AI 智能体先简单梳理一下 AI 编程工具的进化路径。最早出圈的是 GitHub Copilot它的核心能力是在 IDE 里根据上下文自动补全代码、生成函数体。这个阶段的 AI 像是一个“更智能的输入法”它依赖你手动把需求想清楚然后帮你把代码敲出来。随后出现的 Cursor、Continue 等工具把 AI 的能力从“单文件补全”升级到了“多文件理解”。你可以在一个 AI 对话窗口里让它读多个文件、跨文件修改接口、统一重构数据模型响应速度也从“逐行预测”变成了“任务执行”。到了 Claude Code、OpenAI Codex、Devin 这类 AI Agent 出现之后AI 已经可以做到读取整个代码仓库的结构。根据一段自然语言需求定位相关文件。设计修改方案并直接执行修改。运行测试、自查错误、迭代修复。最后生成一个可提交的 Pull Request。也就是说AI 已经不只是在“帮你写代码”而是在“独立执行一个开发任务”。2.2 AI 编程的能力分层为了更清晰地评估“AI 替代工程师”这个说法可以把 AI 的能力按层级拆开看能力层级代表任务当前成熟度L1 代码补全自动补全函数体、生成简单 CRUD 代码非常成熟L2 单文件生成根据注释生成整个文件非常成熟L3 多文件编辑跨文件改接口、统一重构较成熟L4 需求级任务读需求文档、定位代码、改代码、跑测试可用但有风险L5 独立交付完整特性从需求到上线自己写测试、文档、配置部分场景可用L6 系统级架构复杂系统拆分、架构演进、长期技术规划远远不够可以看到L1 到 L3 这一层已经远远超出“辅助工具”的范畴它是确定性很高、收益很大的部分。L4 和 L5 非常依赖代码质量、测试覆盖率和业务复杂度在中小型项目里表现惊艳但在大型分布式系统里容易翻车。L6 则基本上还是人类架构师的地盘。2.3 AI 能高效处理的任务类型根据目前的工程实践AI 比较擅长的是以下几类任务模板化代码。 比如 Spring Boot 里新增一个 Controller、Service、Mapper按照分层架构生成对应代码。AI 只需要看一下现有代码风格就能复制出一套完全一致的结构。单元测试生成。 这是 AI 编程工具被低估的能力。它可以根据一个类的输入输出快速生成边界测试用例极大提升测试覆盖率为后续重构提供安全网。跨文件小范围重构。 比如“把项目中所有的 Date 类型改为 LocalDateTime”“统一所有异常处理的日志格式”“给所有接口统一增加参数校验”。这类工作量大但机械的任务AI 执行效率远超人类。技术文档和代码注释生成。 它能自动整理模块设计文档、生成 Mermaid 流程图、补充 Readme。虽然不是核心开发工作但能节省大量时间。代码审查。 让 AI 对新增代码做一轮静态检查可以发现潜在的 NPE空指针、资源未关闭、SQL 注入风险、并发问题等明显缺陷。2.4 AI 目前仍不擅长的事情AI 编程虽然成长很快但有一些硬伤是短期内难以解决的业务语义理解。 业务需求中隐含的“为什么这样做”和“哪些用户场景不能被破坏”AI 很难准确掌握。它能把代码写出来但它不理解业务优先级和产品心智。复杂系统架构。 当系统拆成几十个微服务依赖关系层层嵌套AI 很难在全局视角上设计出一个优雅的架构方案。它能帮你把局部模块写好但系统的整体形态仍需人来把舵。历史遗留代码维护。 对于没有测试、没有注释、业务逻辑混乱的祖传代码AI 生成的修改往往基于错误的假设很容易引入新的 Bug。责任与决策。 代码上线后出了生产事故AI 不会承担责任。最终背锅和补救的仍然是人所以越是关键系统越需要人来把关。安全与合规判断。 AI 不了解公司内部的合规要求、数据保护政策、业务红线。比如某个接口是否应该暴露、某条数据是否涉及用户隐私这些决策必须由人来完成。3. 技术拆解AI 如何把“200 人的工作量”压缩下来3.1 传统研发团队的工作模型要理解 AI 压缩工作量的原理先看看传统工程团队是怎么运转的。假设一个中型 App 需要开发一个新功能流程通常是产品经理写 PRD → 技术方案评审 → 前后端分工开发 → 自测 → 提测 → QA 测试 → 修 Bug → 联调 → 发布。这个链路里真正需要“大量工程师”的主要原因不是代码本身而是多人并行开发同一套代码需要大量沟通对齐。每个环节都有等待周期。不同人写代码风格不一致审查和修改成本高。测试覆盖不充分Bug 返工占据大量开发时间。可以说传统研发团队的损耗很大部分发生在人与人之间的协作摩擦上。3.2 AI 增强后的研发模型引入 AI 编程工具后工作方式发生了几个关键变化单人多角色。 一个工程师可以同时承担“前端开发 后端开发 测试框架维护 自动化脚本开发”多个角色因为 AI 可以快速切换上下文并生成不同技术栈的代码。批量任务的并行化。 以前改造 50 个接口的日志需要花一天AI Agent 可以在几十分钟内完成全部文件的修改并且自动编译和测试。交付节奏加快。 代码生成速度快意味着产品迭代可以更频繁业务方可以更快验证想法减少无效开发的浪费。团队规模形成“倒三角”。 传统团队需要大量执行层工程师由少数架构师做顶层设计。而 AI 增强后执行层的生产力被大幅放大团队结构变成“少数资深工程师 AI 执行层 大量业务验证”。3.3 实践示例用 Python 构建一个自动 PR 审查 Agent为了更直观地理解 AI Agent 的工作原理下面用一个简单示例演示如何用 Python 调用大模型 API搭建一个最小可用的“代码审查 Agent”。这个 Agent 可以读取一个 Pull Request 的 diff再由大模型自动生成审查意见。# 文件路径ai_code_reviewer/reviewer.py import os import requests # 1. 读取 PR 的 diff 信息 def get_pr_diff(pr_number: int) - str: # 这里以 GitHub API 为例实际项目中请使用自己的 Git 仓库地址 token os.environ.get(GITHUB_TOKEN, ) headers { Authorization: fBearer {token}, Accept: application/vnd.github.v3.diff, } url fhttps://api.github.com/repos/your-team/your-repo/pulls/{pr_number} response requests.get(url, headersheaders) if response.status_code 200: return response.text return # 2. 调用大模型进行代码审查 def review_code(diff_content: str, model: str gpt-4o-mini) - str: # 请根据你实际使用的 AI 服务商调整 endpoint 和 API Key api_key os.environ.get(AI_API_KEY, ) headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: model, messages: [ { role: system, content: 你是一名资深代码审查专家。 请从代码质量、潜在Bug、安全问题、可维护性四个维度提出审查意见 并用简洁的中文输出。, }, { role: user, content: f请审查以下代码变更\n\n{diff_content[:12000]}, }, ], temperature: 0.3, } response requests.post( https://api.openai.com/v1/chat/completions, headersheaders, jsonpayload, timeout60, ) if response.status_code 200: data response.json() return data[choices][0][message][content] return fAPI 调用失败{response.status_code} {response.text} # 3. 主流程 if __name__ __main__: pr_id 123 # 替换成实际 PR 编号 diff get_pr_diff(pr_id) if diff: result review_code(diff) print( AI Review 结果 ) print(result) else: print(没有获取到 PR 变更内容请检查仓库地址或 Token 权限。)这段代码的核心作用是把原本需要人工阅读 diff 文件的步骤自动化。对于大型项目团队每天可能收到几十个 PR靠人工逐行审查不仅慢而且容易漏掉隐患。AI 审查 Agent 可以作为第一道过滤层把明显的安全问题、风格问题挑出来再由工程师集中精力处理高价值的逻辑审查。这就是“AI 替人干活”最常见的落地形态之一。需要注意的是示例代码中的 API 地址和模型名称请根据你实际使用的云服务商和模型版本调整。调用远程模型涉及数据传输假如代码仓库属于企业内网建议优先考虑私有化部署模型或者使用服务器所在地域一致的服务避免把敏感代码发送到不安全的地址。3.4 开发环境的基础支撑AI 编程要真正发挥效果还需要一套完善的开发环境基础支撑。下面是一个常见的基础环境配置示例供参考# 推荐使用 Node.js 20 与 Python 3.11 # 安装 AI 编程 CLI 工具示例不代表人工推荐某一个 npm install -g anthropic-ai/claude-code # 或 npm install -g openai/codex # 初始化项目时保留 .ai 目录用于存放 AI 协作规范 mkdir -p .ai在团队规模较小时建议认真维护AGENTS.md或类似的项目说明文件把项目的技术栈、目录结构、编码规范、验证命令都写清楚。AI 工具会优先读取这些说明生成的代码是否符合团队风格很大程度上取决于这个文件做得细不细。# 文件路径AGENTS.md放在项目根目录供 AI 协作工具读取 # 项目技术栈 - 后端Spring Boot 3.2 Java 17 MyBatis-Plus - 前端Vue 3 TypeScript Vite - 数据库MySQL 8.0 # 代码风格 - Controller 层只做参数校验和路由转发不写业务逻辑 - Service 层必须开启事务使用 Transactional - 所有新增接口必须补充单元测试 - 日志使用 Slf4j禁止 System.out # 常用命令 - 本地启动mvn spring-boot:run - 执行测试mvn test - 代码格式化mvn spotless:apply # 重要约定 - 修改数据库表结构必须添加 Flyway 迁移脚本 - 严禁在代码中硬编码数据库连接信息 - 所有对外 API 必须使用 /api/v1 前缀这个文件是让 AI 从“能写代码”变成“会写符合团队规范的代码”的关键基础设施。如果你的团队已经开始使用 AI 编程工具建议把项目规范沉淀到这类文件里它比口头约定或长文档更有效。4. 工程落地团队如何正确引入 AI 编程工具4.1 工具选型的基本思路现在 AI 编程工具非常多很难说哪一个是绝对最好的因为每个团队的代码托管平台、模型访问成本、数据安全要求都不一样。在选择时建议重点评估以下几点代码数据是否出境。 如果团队做的是金融、政务、医疗等高敏感项目优先选择私有化部署模型或在合规的云服务商环境下使用 API避免把源码发送到海外模型的公共接口。与现有 IDE 的集成度。 团队主要使用 IntelliJ IDEA就优先看 JetBrains 插件团队用 VS Code就优先看 VS Code 插件。集成度越高工程师使用的意愿越强。对本地代码的理解深度。 好的 AI 编程工具应该能读取本地索引、理解项目的目录结构、读取 Git 提交历史。如果只是简单地把代码片段发给云端模型效果会差很多。成本模型。 有的工具按席位数收费有的按 token 消耗收费。按 token 收费的工具在高频使用时成本会上升得非常快需要结合团队实际使用量评估。是否支持自定义 Prompt 和私有知识库。 企业级落地时往往需要把公司内部的编码规范、通用组件、历史架构决策注入到 AI 的上下文中。如果工具不支持自定义指令AI 生成的代码就跟团队风格脱节。4.2 试点策略不要让 AI 突然接手核心系统最稳妥的落地方式是在边缘系统或新项目里先跑 AI 编程流程。例如选择一个内部管理系统环境复杂度低、用户量小、不影响线上稳定。挑选 2 到 3 个编码风格统一、熟悉 AI 工具的工程师组成试点小组。要求试点小组必须对 AI 生成的代码做完整 Review并使用自动化测试验证功能。试点两周内重点观察四个指标AI 生成代码的一次性通过率。工程师花在修正 AI 代码上的时间占比。测试覆盖率是否下降。组员的真实使用感受而不只是看工具自带的统计数字。如果试点效果稳定再逐步扩大到核心业务系统并制定更严格的代码审查策略。4.3 重构开发流程而不是简单加工具很多团队引入 AI 编程失败原因是“把 AI 当成一个高级 Copilot”仍然用旧的流程跑项目——需求不明确、测试覆盖差、接口设计混乱。这种情况下AI 生成的代码越多系统就越乱因为 AI 只是在快速放大人原本的错误。正确的做法是先把基础工程秩序建起来完善需求文档。 AI 生成代码依赖足够清晰的输入。如果需求只用一句话描述“增加一个用户导出功能”AI 大概率会按自己脑补的方式实现。你需要把用户角色、功能边界、异常场景、性能要求都写清楚。强制单元测试覆盖。 在 AI 编程时代测试已经从“质量保障手段”变成了“AI 代码的安全笼子”。没有测试兜底AI 每改一次代码你都可能引入新回归。建立 AI 代码审查规范。 不要无条件相信 AI 生成的代码。团队需要明确的审查重点数据访问权限是否合理、事务边界是否清晰、第三方 API 调用是否有超时与降级、敏感信息是否被硬编码。用自动化流水线约束 AI。 在 CI/CD 流水线中加入静态检查如 SonarQube、依赖漏洞扫描如 Trivy、代码格式检查。AI 生成的代码必须和人类代码走同一套质量门禁。4.4 代码审查中的人工介入点AI 负责写代码不代表人就不需要看代码了。实际上AI 编程之后代码审查变得更加重要。人工审查应该重点关注业务逻辑与需求是否一致。异常分支是否覆盖完整。是否有隐藏的性能问题比如 N1 查询、大事务、内存泄漏。接口设计是否符合长期演进规划。是否引入了不必要的复杂依赖。AI 适合做“检查是否合规”人更适合做“判断是否合理”。5. 质疑与风险五个必须直视的问题5.1 “AI 生成的代码质量不行”这是最常见的质疑。确实AI 生成的代码有很强的“班味”——过度封装、命名冗长、逻辑绕圈子、喜欢套用经典设计模式。但这个问题要分两层看第一层是模型能力问题第二层是团队规范问题。如果团队有严格的代码规范、完善的测试体系、清晰的 AGENTS.md 约定AI 生成的代码质量会明显提升。如果这些基础都没有AI 生成的代码自然会劣化。所以“AI 代码质量差”很多时候反映的是团队工程化水平而不是 AI 本身不行。5.2 上下文窗口限制导致问题目前的模型上下文窗口虽然已经很大但足够容纳一个大项目所有代码吗显然不行。AI 在修改一个文件时如果看不到调用方和被调用方的完整逻辑就容易改出“局部正确、整体错误”的代码。应对方法把大模块拆成小模块降低 AI 需要理解的上下文范围。在 AGENTS.md 中写清楚重要的模块边界和依赖关系。让 AI 在动手前先输出修改计划人工确认后再执行。5.3 长期维护问题AI 可以快速生成代码但代码的长期维护仍然需要人。如果一个项目所有人都在用 AI 快速堆功能但没有人花时间做架构演进、技术债清理、性能优化几年后这个系统就会变得难以维护。这个问题的本质是AI 提高了短期生产力但长期维护的复杂度并没有因为 AI 变低。团队需要有人专门关注技术债务定期做重构给 AI 一个干净的基础。5.4 安全合规问题AI 编程工具在使用时通常需要把代码发送到远程模型服务器。对企业来说这意味着代码泄密的隐患。Grindr 是一家互联网公司代码敏感度相对可控但很多传统企业的代码涉及商业机密或用户隐私必须更加谨慎。合规建议对代码进行分级分类高风险模块禁止使用远程 AI 工具。使用私有化部署模型或者购买企业版服务数据不用于训练。在日志审计中记录哪些文件被发送给了 AI便于追踪。5.5 组织与职业危机对工程师个人来说AI 编程工具的普及确实会让一些低水平重复劳动岗位减少。但更现实的情况是AI 首先淘汰的不是工程师而是那些“不会使用 AI 的工程师”。愿意持续学习、能把 AI 工具用到极致的人反而会因为产出大幅提升而获得更多机会。对管理者来说用 AI 做裁员工具是很危险的。Grindr 的方法本质上是对研发流程的重构而不是简单地把人换成 AI。如果管理者没有把基础工程流程理顺只是单纯削减人力那么 AI 生成的代码会很快把系统推向深渊。6. 团队与成本决策AI 替代的不只是人更是低效流程6.1 从“人效”转向“工程杠杆率”传统的研发人效指标关注每个工程师每个迭代能交付多少需求。AI 编程时代更值得关注的是“工程杠杆率”——即一个工程师通过工具、流程和 AI 的杠杆能够撬动多少业务价值。同一个需求AI 时代可能不需要拆给 3 个工程师做 5 天而是 1 个工程师 AI 协作 2 天完成。但前提是需求足够清晰。代码库结构合理。测试覆盖到位。工程师具备拆分任务和监督 AI 的能力。6.2 什么样的情况适合用 AI 放大团队适合用 AI 放大研发团队的场景包括初创公司探索新业务。 业务方向不确定需要快速试错、快速迭代。AI 可以大幅缩短从想法到 Demo 的时间帮助团队验证市场假设。中大型企业的内部系统。 内部管理系统的需求相对标准化不直接面向海量用户业务稳定性要求没那么苛刻。用 AI 快速交付可以把省下来的人力放到核心业务上。成熟产品的例行维护。 比如依赖升级、框架迁移、接口兼容性处理。这类任务有明确的规则和边界AI 执行效率极高。6.3 什么样的情况不适合用 AI 大幅削减人力核心交易系统。 支付、订单、库存这类系统一次事故的损失可能超过一年的人力成本。对这类系统要保持保守AI 只能作为辅助工具不能完全放手。涉及强合规的领域。 医疗、金融、政务等场景有严格的审计要求AI 生成代码需要额外的人工审核和合规备案。严重技术债项目。 代码本身没有测试、没有文档、耦合严重就先不要想着用 AI 提效而是先偿还技术债。否则 AI 只是在给烂代码加速腐烂。6.4 成本测算的参考框架评估是否值得引入 AI 编程工具时不只要看工具订阅费还要看以下几项成本训练和配置成本把团队规范和私有知识库编码到 AI 工具中的初始投入。审查成本AI 生成的代码仍然需要人工 Reviewer 审核这部分时间不能省。错误修复成本AI 代码上线后引入的生产故障修复和善后的成本。人才结构调整成本是否需要招聘更高阶的工程师是否需要对现有团队进行技能培训如果只算订阅成本AI 编程工具的 ROI 看起来极高但如果把这些隐性成本算上结论会理性得多。7. 给工程师和技术团队的行动建议7.1 对工程师个人把自己定位成“AI 的架构师”AI 时代工程师的竞争力不再是“谁敲代码更快”而是以下三个维度需求拆解能力能把模糊的业务诉求拆成 AI 可以执行的一个个清晰任务。代码审查与纠错能力能快速识别 AI 生成的代码是否有隐患、有设计缺陷、有性能风险。架构规划能力能在 AI 完成局部实现之后保证整个系统的长期健康演进。简单说你的职责从“自己动手写代码”变成了“指挥 AI 写代码 审查 AI 的产出 设计 AI 不能设计的系统架构”。这个转变对资深工程师来说是一次机会而对只做基础编码的人来说挑战会更大。7.2 对技术管理者把 AI 当成流程改造的一部分给管理者的建议是不要盲目追求“用 AI 省多少人”而是认真思考“AI 如何改变我们的软件生产流程”。一个比较落地的思路是先聚焦一个具体环节比如测试开发、代码审查、批量重构。引入 AI 工具 配套流程规范试点两个迭代。用数据评估效果哪怕只是“单元测试覆盖率从 40% 提到 80%”“线上故障率下降 30%”这种量化指标。效果好再扩展到更多环节效果不好就及时止损。AI 工程化是一个渐进过程最怕两种极端一种是完全无视坚持用老方法另一种是全员强制使用 AI却没有配套的流程和质量保障最后变成“AI 写的代码 人海修 Bug”。7.3 对刚入行的新人把 AI 作为学习引擎对刚入行的工程师来说AI 编程工具其实是一个非常好的学习助手。你可以在写代码前先让 AI 给出一个参考实现然后逐行理解它的设计意图写完代码后再让 AI 做一轮代码审查指出潜在问题遇到不理解的概念也可以直接让 AI 结合代码上下文解释。但要注意的是不要让 AI 替你思考。当你开始无脑粘贴 AI 生成的大段代码但完全不理解它的原理时你的技术成长就会停滞。正确的方式是“AI 生成 → 人理解 → 人修改 → 人验证”。7.4 一条可以落地的 AI 编程学习路线如果你现在想系统掌握 AI 编程可以考虑按以下路线推进熟练掌握一种主流 AI 编程 IDE 或插件比如 Cursor、Copilot、CodeWhisperer把日常编码流程跑通。学习 Prompt 工程基础特别是如何在代码上下文中给出清晰、具体的指令。在个人项目中实践 AI Agent 的工作流比如让 AI 自动完成一个接口的开发、测试与文档生成。学习私有化模型部署的基础概念了解哪些模型可以本地跑、如何保障代码数据不出内网。深入一个具体业务场景用 AI 工具完成一次完整的项目交付并复盘哪些环节效率提升明显、哪些环节有风险。8. 总结Grindr CEO 说“AI 做了 200 名工程师的工作”这句话在新闻里很醒目但落到技术层面它不是科幻故事而是 AI 编程工具成熟到一定阶段后必然出现的结果。AI 真正代替的不是“有创造力的工程师”而是那些重复度高、规则明确、上下文可穷尽的编码任务。对团队来说AI 是一个杠杆它放大人原有的生产力也放大原有流程中的问题。工具选型、代码规范、测试覆盖、审查策略、安全合规这些基础工作会决定你是在用 AI 提效还是在用 AI 制造更多技术债。对工程师个人来说最理性的应对不是焦虑而是主动改变工作方式把 AI 用起来、把需求拆解能力练起来、把架构和审查能力补起来。当一个工具能把低水平劳动成本降到接近零时真正值钱的不是“会用工具”而是“知道该让工具做什么、为什么这么做”。希望这篇文章能帮你更冷静地看待“AI 取代程序员”这个话题也给你的团队和个人的下一步行动提供一个可参考的起点。如果你对 AI Agent 开发、私有化模型部署或代码审查自动化有更多兴趣可以先从文中的最小示例开始动手验证然后在自己的项目里逐渐扩大应用范围。毕竟AI 编程的很多结论只有自己实际跑过才能真正有体感。