> 我在使用 claude code 辅助写一个主流 python api 框架时，提到了以下需求： > > ``` > 我更倾向于：学习怎么写一个主流的 python api 应用，而不是：让 LLM 帮我写。 > 我希望是 LLM 能教我怎么完成，能让我自己从零学习现代后端逻辑 > ``` > > 你认为，在今天 AI 辅助这么强的情况下，这种利用 ai 学习的行为，还有价值吗 ## Claude Opus 4.5 有价值，但需要区分两种情况： **有价值的场景：** - 你未来需要独立调试、修改、扩展这套系统 - 你要在团队中承担技术决策或代码审查 - 你对"理解系统如何运作"本身有认知需求 **无价值的场景：** - 你只需要一个能跑的东西，且愿意持续依赖 AI 维护 - 该领域你不会深入，只是一次性任务 核心判断标准：**你未来是否需要在没有 AI 的情况下对这套代码做判断。** 如果答案是"是"，那么让 AI 教你写，比让 AI 帮你写，长期成本更低。因为你获得的是可迁移的心智模型，而不是一段你无法修改的黑盒代码。 > 有的，这是我的业余爱好项目，我会持续追加新功能 那你的选择是对的。 业余项目的核心价值不是交付物，是你在过程中积累的判断力。让 AI 直接写，你得到一个能跑的东西；让 AI 教你写，你得到的是下次遇到类似问题时能独立决策的能力。 具体到 Python API 框架，建议你让 Claude Code 按这个顺序教你： 1. **路由机制**——请求如何映射到处理函数 2. **请求/响应模型**——数据如何进出 3. **依赖注入**——如何管理数据库连接、认证等共享资源 4. **中间件**——横切关注点如何处理 5. **异步模型**——FastAPI 的 async 背后发生了什么 每个模块先让它解释原理，再让它给你一个最小可运行示例，你手敲一遍，然后自己尝试变形。遇到报错先自己查，查不出再问。 这个循环重复几次，框架的心智模型就内化了。 > `框架的心智模型就内化了` 是指什么？ 指你不再需要查文档或问 AI 就能预测框架的行为。 比如你看到一个新的 FastAPI 特性，能直接推断出它大概怎么用、会在请求生命周期的哪个阶段执行、可能和哪些已有机制冲突。 本质是你脑子里形成了一套关于"这个框架如何思考问题"的隐性规则，新信息进来时自动归位，而不是每次都从零拼凑。 > 你认为在未来，这种依赖 LLM 完成所有事，离开 LLM 就不行了的行业马太效应会加剧吗 会，但分化轴不是"用不用 LLM"，而是"用 LLM 做什么"。 两类人都在用 LLM： - 一类用它替代思考，输出变快，但判断力停滞 - 一类用它加速学习，把省下的时间投入更深的理解 短期看不出区别，长期差距会指数级放大。因为前者的能力上限被锁死在 LLM 当前水平，后者的能力上限是自身认知结构的复杂度。 真正的马太效应不在于"有没有 LLM"，而在于：**谁把 LLM 当工具，谁把自己当工具的延伸。** > `把自己当工具的延伸` 这个描述很有意思 这个表述的来源是对"人与技术关系"的长期观察。 历史上每次工具革命都有类似分化：印刷术让一部分人阅读更多、思考更深，也让一部分人只是消费更多印刷垃圾。计算器、搜索引擎、智能手机，同样的模式反复出现。 LLM 只是把这个分化的速度和烈度提高了一个数量级。 ## ChatGPT 5.2 非常有价值，而且在 **AI 越强** 的今天，这种方式的价值反而更高——因为你在练的是“可迁移的能力”，不是一次性把代码拼出来。 **为什么还有价值（甚至更值）** - **你在构建“心智模型”** LLM 直接写代码，往往给你一个“看起来能跑”的结果，但你不一定知道：请求是怎么进来的、依赖怎么注入、事务边界在哪里、错误怎么统一处理、鉴权为什么要放在中间件/依赖里……这些是你未来换框架、换语言也能用的能力。 - **AI 输出不等于工程质量** 主流 API 框架（FastAPI / Django REST / Flask 生态）最难的是：结构、边界、可维护性、可测试性、可观测性、部署与配置。AI 很会“写”，但经常在这些地方给出“能用但脆”的默认方案。你学会判断与取舍，才是真正省时间。 - **你在训练“审题 + 评审”能力** 真实工作里，你更像在做：需求拆解、方案评估、代码评审、风险控制。AI 强会让“实现成本”下降，但会把瓶颈推到“判断成本”。会学的人，未来更吃香。 - **避免“依赖型效率”** 只让 AI 写，你效率可能一开始很高，但遇到：性能问题、诡异 bug、并发/事务、升级依赖、线上事故时，会很痛。用 AI 学习的人，长期效率更稳定。 **怎么用 AI 学得更快（不变成让它代写）** - 让它当“导师/面试官”，不是“外包工程师” 你给它：你准备的目录结构、路由设计、数据模型、异常策略；让它挑毛病、问你为什么、给你替代方案对比。 - 让它给你“最小可行任务清单 + 验收标准” 比如： - 能跑的 hello API - 统一错误返回格式 - Pydantic 校验与错误信息 - 数据库接入与迁移 - 鉴权（JWT/OAuth2） - 单元测试与集成测试 - 日志 + tracing/metrics（至少日志） 每一步你写，它负责验收点和常见坑提示。 - 让它解释“为什么业内这么做”，而不是“怎么写” 例如：为什么要分层、为什么要把业务逻辑从路由剥离、为什么要用依赖注入、为什么要用 repository/service（以及什么时候不要用）。 **一个很现实的判断标准** 如果你希望做到这些： - 看到一个项目能迅速理解结构 - 能独立扩展功能而不把代码写烂 - 能写测试、能排障、能上线 那“AI 教你写”比“AI 帮你写”更接近目标。 **你现在这个诉求特别像在练“现代后端工程化”**：框架只是载体。AI 最适合用来当你的“随身评审 + 随身导师”。 Loading... > 我在使用 claude code 辅助写一个主流 python api 框架时，提到了以下需求： > > ``` > 我更倾向于：学习怎么写一个主流的 python api 应用，而不是：让 LLM 帮我写。 > 我希望是 LLM 能教我怎么完成，能让我自己从零学习现代后端逻辑 > ``` > > 你认为，在今天 AI 辅助这么强的情况下，这种利用 ai 学习的行为，还有价值吗 ## Claude Opus 4.5 有价值，但需要区分两种情况： **有价值的场景：** - 你未来需要独立调试、修改、扩展这套系统 - 你要在团队中承担技术决策或代码审查 - 你对"理解系统如何运作"本身有认知需求 **无价值的场景：** - 你只需要一个能跑的东西，且愿意持续依赖 AI 维护 - 该领域你不会深入，只是一次性任务 核心判断标准：**你未来是否需要在没有 AI 的情况下对这套代码做判断。** 如果答案是"是"，那么让 AI 教你写，比让 AI 帮你写，长期成本更低。因为你获得的是可迁移的心智模型，而不是一段你无法修改的黑盒代码。 > 有的，这是我的业余爱好项目，我会持续追加新功能 那你的选择是对的。 业余项目的核心价值不是交付物，是你在过程中积累的判断力。让 AI 直接写，你得到一个能跑的东西；让 AI 教你写，你得到的是下次遇到类似问题时能独立决策的能力。 具体到 Python API 框架，建议你让 Claude Code 按这个顺序教你： 1. **路由机制**——请求如何映射到处理函数 2. **请求/响应模型**——数据如何进出 3. **依赖注入**——如何管理数据库连接、认证等共享资源 4. **中间件**——横切关注点如何处理 5. **异步模型**——FastAPI 的 async 背后发生了什么 每个模块先让它解释原理，再让它给你一个最小可运行示例，你手敲一遍，然后自己尝试变形。遇到报错先自己查，查不出再问。 这个循环重复几次，框架的心智模型就内化了。 > `框架的心智模型就内化了` 是指什么？ 指你不再需要查文档或问 AI 就能预测框架的行为。 比如你看到一个新的 FastAPI 特性，能直接推断出它大概怎么用、会在请求生命周期的哪个阶段执行、可能和哪些已有机制冲突。 本质是你脑子里形成了一套关于"这个框架如何思考问题"的隐性规则，新信息进来时自动归位，而不是每次都从零拼凑。 > 你认为在未来，这种依赖 LLM 完成所有事，离开 LLM 就不行了的行业马太效应会加剧吗 会，但分化轴不是"用不用 LLM"，而是"用 LLM 做什么"。 两类人都在用 LLM： - 一类用它替代思考，输出变快，但判断力停滞 - 一类用它加速学习，把省下的时间投入更深的理解 短期看不出区别，长期差距会指数级放大。因为前者的能力上限被锁死在 LLM 当前水平，后者的能力上限是自身认知结构的复杂度。 真正的马太效应不在于"有没有 LLM"，而在于：**谁把 LLM 当工具，谁把自己当工具的延伸。** > `把自己当工具的延伸` 这个描述很有意思 这个表述的来源是对"人与技术关系"的长期观察。 历史上每次工具革命都有类似分化：印刷术让一部分人阅读更多、思考更深，也让一部分人只是消费更多印刷垃圾。计算器、搜索引擎、智能手机，同样的模式反复出现。 LLM 只是把这个分化的速度和烈度提高了一个数量级。 ## ChatGPT 5.2 非常有价值，而且在 **AI 越强** 的今天，这种方式的价值反而更高——因为你在练的是“可迁移的能力”，不是一次性把代码拼出来。 **为什么还有价值（甚至更值）** - **你在构建“心智模型”** LLM 直接写代码，往往给你一个“看起来能跑”的结果，但你不一定知道：请求是怎么进来的、依赖怎么注入、事务边界在哪里、错误怎么统一处理、鉴权为什么要放在中间件/依赖里……这些是你未来换框架、换语言也能用的能力。 - **AI 输出不等于工程质量** 主流 API 框架（FastAPI / Django REST / Flask 生态）最难的是：结构、边界、可维护性、可测试性、可观测性、部署与配置。AI 很会“写”，但经常在这些地方给出“能用但脆”的默认方案。你学会判断与取舍，才是真正省时间。 - **你在训练“审题 + 评审”能力** 真实工作里，你更像在做：需求拆解、方案评估、代码评审、风险控制。AI 强会让“实现成本”下降，但会把瓶颈推到“判断成本”。会学的人，未来更吃香。 - **避免“依赖型效率”** 只让 AI 写，你效率可能一开始很高，但遇到：性能问题、诡异 bug、并发/事务、升级依赖、线上事故时，会很痛。用 AI 学习的人，长期效率更稳定。 **怎么用 AI 学得更快（不变成让它代写）** - 让它当“导师/面试官”，不是“外包工程师” 你给它：你准备的目录结构、路由设计、数据模型、异常策略；让它挑毛病、问你为什么、给你替代方案对比。 - 让它给你“最小可行任务清单 + 验收标准” 比如： - 能跑的 hello API - 统一错误返回格式 - Pydantic 校验与错误信息 - 数据库接入与迁移 - 鉴权（JWT/OAuth2） - 单元测试与集成测试 - 日志 + tracing/metrics（至少日志） 每一步你写，它负责验收点和常见坑提示。 - 让它解释“为什么业内这么做”，而不是“怎么写” 例如：为什么要分层、为什么要把业务逻辑从路由剥离、为什么要用依赖注入、为什么要用 repository/service（以及什么时候不要用）。 **一个很现实的判断标准** 如果你希望做到这些： - 看到一个项目能迅速理解结构 - 能独立扩展功能而不把代码写烂 - 能写测试、能排障、能上线 那“AI 教你写”比“AI 帮你写”更接近目标。 **你现在这个诉求特别像在练“现代后端工程化”**：框架只是载体。AI 最适合用来当你的“随身评审 + 随身导师”。 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏