《狂人日记NO.10》— 我的AI使用经验分享

Imchendiana
0 阅读23分钟

零. 前言

ScreenShot_2026-07-07_082750_652.png

思维链：

这周要在公司做一次自己使用AI的经验分享，怎么编写呢？

首先我并没有非常重度的使用AI，为了让分享内容更丰满，我决定除了写出自己AI的使用经验外，还要写一点AI的基本概念等科普内容。

大部分问题归根结底讨论的就是三个词“what”、“why”、“how”，以这三个角度切入，从基础到进阶，从原理到应用，从使用到优化分别阐述AI的使用。

  1. 第一节：什么是AI。

    1.1 以CodeBuddy应用为例，分别简要说说AI中的AI模型、Agent智能体、Skill技能、MCP、Commond命令、Rule规则、 Memory记忆等概念的本质、作用、应用场景。

  2. 第二节：为什么用AI。

    2.1 简单说说为什么要用AI模型、智能体、技能、MCP、命令、规则、记忆等。

  3. 第三节：怎么用AI。

    3.1 详细说说如何使用AI模型、智能体、技能、MCP、命令、规则、记忆等。

  4. 第四节：我是怎么使用AI的。

    4.1 我正在用的技能(git-daily-report、md2pdf、md2word)、规则（模型思考规则、生成代码注释规则、禁止编造谎言规则）、MCP（gitee MCP 服务/）、以及MCP市场网站 https://mcpmarket.cn/的分享。 4.2 我在编码和写文档过程中，是怎么使用AI的？ 4.3 在AI时代，我建议前端一定要用 TypeScript！当使用 AI 工具写代码时，AI 需要「理解」你的代码，如果是松散的 JavaScript，没有类型信息，AI 只能靠猜——猜这个变量是啥、这个函数返回什么，猜错了就给你生成一坨跑不通的代码。但换成 TypeScript，情况完全不一样。类型，就是一份机器可读的「接线图」。 每个变量什么类型、每个函数收什么吐什么，清清楚楚写在那。AI 不用猜了，照着类型这份「契约」来，生成的代码准得多、在生产里也可靠得多。因此 AI 越普及，类型安全的价值就越高。而且有TypeScript类型加持，当让AI生成接口说明等文档时，也会更准确。

  1. 结语

    引用：Linus 谈 AI 编程，编程的本质没变：AI 只是另一个“编译器”，从手写机器码到使用汇编器，再到高度依赖编译器，编程工具的演进一直在提高抽象层级。AI 只是这漫长演进链条上的最新一环。编译器将生产力提高了 1000 倍，AI 可能会将你的生产力提高 10 倍。AI 很棒，但它并没有颠覆编程。他创造了一个非常有意思的词——“氛围编程（Vibes-based Programming）”，对于那种一次性的、写完就扔的玩具项目，通过不断调整提示词（Prompt）让 AI 帮你生成代码，效果确实非常出色。但如果你要构建的是一个需要维护 的严肃项目，那就不能只靠写提示词，让别人或 AI 替你生成代码。在 AI 时代，优秀的开发者依然优秀，因为他们真正理解系统和复杂性，知道如何引导 AI 产出高质量代码；而对系统缺乏理解的人，往往只会让 AI 生成更多隐藏的 Bug。即使在使用现代编译器，甚至让 AI 辅助生成代码的今天，他依然会去检查最终生成的汇编代码，以确保程序真的按照预期在运行。在浮躁的 AI 时代，这或许是对所有开发者的最佳警醒：不要满足于当一个只会写 Prompt 的“需求翻译机”。工具的门槛越低，理解系统底层运作原理、驾驭复杂工程架构的能力，就越是你不可替代的护城河。

真正的结语：右键点击该文件，然后点击添加到CodeBuddy对话，然后输入提示词：帮我完善该文档。

注：本文档在 AI 辅助下完成：先由人工构思大纲和核心观点，再由 AI 根据大纲扩展详细内容，最后人工审校定稿。

壹. 什么是AI？

在聊怎么用之前，先弄清楚几个基本概念。很多人一提到"AI 编程"就觉得是一个大黑箱，但其实拆开来看，每个组件都不复杂。

1.1 AI 模型（Model）

本质：一个"超级文本预测引擎"。你输入一段文字，它基于海量训练数据预测最合理的后续内容。

作用：理解自然语言指令，生成代码、文档、分析结论。

在 CodeBuddy 中：你看到的所有回答——代码补全、架构分析、Bug 修复——底层都是 AI 模型在工作。CodeBuddy 支持切换不同模型（如 Claude、DeepSeek 等），不同模型的能力侧重点不同。

1.2 Agent 智能体

本质：给 AI 模型装上"手和脚"。普通对话是你问一句它答一句；Agent 模式下，它能自己制定计划、调用工具、读写文件、执行命令，像一个人一样完成多步骤任务。

作用：把"对话式 AI"升级为"同事式 AI"。你不需要逐步指导，只需要告诉他"把这个功能做了"，他会自己分析代码、改文件、验证效果。

应用场景：

  • 跨多个文件实现一个新功能
  • 自动定位 Bug 并修复
  • 重构代码（重命名、提取函数、调整架构）

1.3 Skill 技能

本质：一个预定义的"工作流模板"。把某个领域的最佳实践、操作步骤、脚本工具打包成一个可复用的单元。

作用：让 AI 在特定场景下"自动知道该怎么做"，不需要你每次重新描述流程。

举个例子：你想从 Git 提交记录生成日报。没有 Skill 时，每次都要说："请读取今天的 git log，按功能/优化/修复分类，生成 Markdown 日报"。有了 git-daily-report Skill 后，只需说"写日报"，Skill 自动提供完整的分类规则和输出模板。

Skill 的边际成本递减：第一次生成架构图转 base64 花了多轮调试（SVG 转义问题、sharp 路径、& 符号处理），但封装成 Skill 后第二次只需要一句话触发。

1.4 MCP（Model Context Protocol）

本质：一个标准化的"外接设备接口"协议。就像 USB 协议让电脑可以连接任意 USB 设备，MCP 让 AI 可以连接任意外部服务。

作用：突破 AI 只能访问对话内容的天花板，让 AI 直接操作 GitHub、数据库、文件系统、浏览器等外部资源。

应用场景：

  • Gitee MCP：让 AI 直接读写 Gitee 仓库（查 PR、创建 Issue、获取提交记录）
  • 飞书/企微 MCP：AI 直接发消息、读消息
  • 数据库 MCP：AI 直接查询和操作数据库
  • MCP 市场：类似"应用商店"，有大量现成的 MCP 服务可直接安装

关键区别：Skill 是告诉 AI "怎么做"（工作流），MCP 是给 AI 装"新能力"（新工具）。两者配合使用效果最佳。

1.5 Command 命令

本质：一句话快捷指令。在对话输入框里以 / 开头的预设命令。

作用：减少重复输入，快速触发高频操作。本质就是一个 Skill 的快捷入口。

常见命令：/fix（修复代码）、/explain（解释代码）、/test（生成测试）等。

1.6 Rule 规则

本质：给 AI 的"员工手册"。告诉 AI 在特定场景下必须遵守的行为准则。

作用：约束 AI 的行为边界，确保输出质量一致。规则的优先级高于 AI 的"自由发挥"。

我配置的规则：

规则说明为什么重要
模型思考规则外科手术式修改、简单优先、思考过程返回简体中文等，可参考github 188K Star 资深大佬的skill - andrej-karpathy-skills阅读 AI 思维链时更直观
生成代码注释规则生成符合 TypeDoc 规范的注释，不遗漏参数确保文档生成质量一致
禁止编造谎言不知道就说不知道，不为了讨好而编造真实性 > 用户满意度

💡 小建议：新手最容易忽视的就是 Rule。你的编码习惯、团队规范、项目特有的注意事项，都可以写成 Rule。比如"本项目 Cesium 不能 import，必须用 window.Cesium"，AI 知道后就不会写出报错代码。

1.7 Memory 记忆

本质：AI 的"长期记忆"。跨对话持久保存的关键信息。

作用：让 AI 在每次对话中自动加载之前的分析结论，不需要你重复解释。

实际价值：这篇文章我是在项目工程下写的，当我让AI生成文章的时候，AI自己会用我的最近做的卫星网络仿真项目，进行举例。

贰. 为什么用AI？

2.1 不是"要不要用"，而是"怎么用得更高效"

AI 模型：让你不再从零开始。面对一个陌生代码库、一个新需求、一个奇怪 Bug，AI 能帮你快速建立认知地图。

Agent 智能体：把"我知道要做什么但不想逐行写"变成现实。改 5 个文件的关联逻辑，传统做法是逐个文件手动改，Agent 一次搞定。

Skill 技能：一次投入，反复复用。日报、周报、文档生成、代码审查这些重复性工作，封装成 Skill 后就是一句话的事。

MCP：打破 AI 的"信息茧房"。没有 MCP 时，你要把外部数据手动复制粘贴给 AI；有了 MCP，AI 自己去查、自己去写。

Rule 规则：不用每次纠正 AI。新对话开始时 AI 不记得上次你说过什么——Rule 就是"永久生效的纠正"。

Memory 记忆：避免重复劳动。分析过一次的大型结论，存入记忆后所有后续对话共享。

2.2 一个真实的效率对比

在这个卫星网络仿真项目中：

任务传统方式AI 辅助效率提升
后端：增删改查接口手写 Controller → Service → Repository 全套样板代码给出 Entity 和 DTO 定义，AI 自动生成全套 CRUD 代码~20x
后端：Entity/DTO 创建逐个字段敲 TypeORM 装饰器、校验装饰器、Swagger 文档装饰器粘贴字段列表，AI 一次生成完整类定义~15x
后端：大数据文件分表分析数据分布 → 手写分表 SQL → 测试 → 反复调试描述分表策略，AI 生成 DDL + 分表路由逻辑~10x
前端：3D 场景性能分析手工打点计时 → 逐个测试 entity 数量 → 录屏对比一句话让 AI 分析渲染管线瓶颈，定位性能热点~8x
前端：BusinessClassStore 重构逐个方法审视 → 手动拆分 → 修改所有引用人工设计架构方案，AI 执行重复性拆分和引用替换~6x
前端：图表可视化自动生成翻 ECharts/D3 文档 → 拼配置项 → 调样式 → 反复试错给数据结构+需求，AI 根据组件上下文和第三方库自动生成完整图表~10x
项目文档生成打开 Word 从头写（二次开发手册、接口说明书、数据格式说明）提供代码+结构大纲，AI 批量生成 Markdown 文档~10x
分析 9 个组件的 watch 策略逐个打开文件，手写笔记对比一句话提问，AI 批量扫描分析~10x
生成 Git 日报翻 git log → 手动分类 → 排版一句"写日报"~3x

叁. 怎么用AI？

3.1 AI 模型的使用技巧

  1. 写好 Prompt：把 AI 想象成一个非常聪明但对项目一无所知的新同事。你需要清楚地告诉他：

    • 你在做什么（项目背景）
    • 你想要什么（具体输出）
    • 有什么限制（约束条件）

    ❌ 差的 Prompt：「帮我修这个 bug」 ✅ 好的 Prompt：「useMapScene.tsx 中 satellite 图层的 toggle 切换后，旧 entity 没有被移除。帮我定位原因，看是 clear 函数的问题还是 entity ID 命名冲突。」

  2. 渐进式对话：不要一上来就问终极问题。先用小问题建立上下文，再逐步深入。

  3. 给 AI 看代码：拖拽文件到对话框、@ 引用文件、直接粘贴关键代码段，比纯文字描述准 10 倍。

3.2 Agent 智能体的使用技巧

  1. 信任但验证：Agent 改完代码后，用 git diff 检查改动，特别是涉及业务逻辑的部分。
  2. 任务拆解：大任务拆成小任务，每个小任务验证后再推进。不要一次性让 Agent 改 10 个文件。
  3. 明确边界：「只改 src/hooks/ 下的文件，不要碰 store」——这种约束会大幅降低出错率。

3.3 Skill 技能的使用

  1. 什么时候创建 Skill：当同样的任务你做了 3 次以上，就该封装成 Skill。
  2. Skill 包含什么：操作步骤 + 模板格式 + 常见边界处理。
  3. 复用已有 Skill：优先在 Skill 市场或团队内寻找现成的，避免重复造轮子。

3.4 MCP 的连接与使用

  1. 去哪里找 MCP：MCP 市场 是最大的中文 MCP 索引站。
  2. 怎么安装：在 CodeBuddy 设置 → MCP 服务中添加 JSON 配置。
  3. 使用注意：MCP 给了 AI 操作外部系统的能力，权限越大风险越大。建议：
    • 生产环境的数据库 MCP 慎用
    • 写操作的 MCP（如 Git push）确认后再执行
    • 敏感 API 的 Token 不要暴露在 MCP 配置文件中

3.5 Rule 规则的配置

  1. 全局规则 vs 项目规则：通用行为规范放全局（如"不许编造谎言"），项目特定约束放项目（如"使用 TypeDoc 注释规范"）。
  2. 规则要具体：「写清楚」比「覆盖广」更重要。
  3. 规则会过期：定期检查规则是否仍然适用，及时更新。

3.6 Memory 记忆的管理

  1. 记忆什么：跨对话需要复用的分析结论、项目特有问题、非标准的技术选型。
  2. 记忆不要太碎：把相关的知识点合并成一条，而不是分散成 10 条。
  3. 定期清理：过时的记忆比没有记忆更危险。

肆. 我是怎么使用AI的？

4.1 我的工具栈

正在使用的 Skills：

Skill用途触发场景
git-daily-report从本地 Git 提交生成中文日报每天下班说"写日报"
gitee-daily-report从 Gitee 远端 API 获取提交记录生成日报本地没同步时使用远端日报
md2pdfMarkdown 转 PDF需要将文档交付给非技术人员时
md2wordMarkdown 转 Word正式文档归档
svg-to-base64-image手写 SVG 转 PNG base64 嵌入 Markdown文档需要专业图片时

正在使用的 Rules：

1. 思考过程返回简体中文
2. 代码注释生成时使用 TypeDoc 规范，不遗漏参数
3. 禁止编造谎言：不知道就说不知道

正在使用的 MCP：

  • Gitee MCP：通过 API 操作 Gitee 仓库（查 PR、创建 Issue、获取提交详情）
  • MCP 市场：发现新的 MCP 服务

4.2 我在编码过程中怎么用 AI

以下场景与 2.2 效率对比表 一一对应，按效率提升从高到低排列。

后端：增删改查接口的批量生成（~20x）

在 satellite-network-simulation-server 后端项目中，典型的业务模块包含 Controller → Service → Repository 三层，加上对应的 Entity、DTO、VO 各种对象转换。一个实体模块往往需要十几份样板文件。

做法：

  1. 先人工定义好 Entity（数据库映射）和 DTO（输入输出结构）——这些是业务核心，不能交给 AI 猜
  2. 把 Entity 和 DTO 的定义粘贴给 AI，描述接口需求（"基于此 UserEntity 生成完整的增删改查接口，包含分页查询和批量删除"）
  3. AI 自动生成 NestJS 的 Controller、Service、Repository（TypeORM）全套代码
  4. 人工检查业务逻辑正确性，微调后即可运行

效果：

  • 一个标准 CRUD 模块从手写 2-3 小时降到 10 分钟（包含微调时间）
  • 代码风格统一：所有 AI 生成的接口都遵循相同的命名规范、异常处理、返回值包装

💡 关键心得：业务核心的 Entity/DTO 定义由人把关，AI 只负责"编译器级别的翻译工作"——把语义明确的定义翻译成符合框架规范的样板代码。这种分工模式下，AI 几乎不会犯错。

后端：Entity/DTO 创建（~15x）

手写一个带校验装饰器、Swagger 文档装饰器、TypeORM 列映射的 Entity 类动辄 100+ 行，字段多了之后非常枯燥且容易遗漏。

做法：

粘贴字段列表 → AI 一次生成完整类定义
例如："id, name, email, status, createTime, updateTime"
→ AI 自动生成带 @Column(), @ApiProperty(), @IsNotEmpty() 等装饰器的完整 Entity 类

效果：从逐个字段敲 10 分钟降到 30 秒。

后端：大数据文件分表（~10x）

后端需要处理千万级的仿真数据文件，单表查询性能不达标，需要实现分表路由。

做法：

"当前表 satellite_data 按 sat_id 哈希分 8 张表，
帮我生成：1. 分表 DDL（satellite_data_0 ~ satellite_data_7）
2. 分表路由工具类（根据 sat_id 计算表名）
3. 改造现有查询/插入接口，自动路由到对应表"
→ AI 生成完整方案 → 人工验证哈希均匀性 → 执行

效果：分表方案的 DDL + 路由代码 + 接口改造，从预估 1 天缩短到 1 小时。AI 对这类"规则明确、逻辑重复"的任务特别擅长。

前端：3D 场景性能分析（~8x）

Cesium 渲染 3000+ 颗卫星时出现明显卡顿，需要定位性能瓶颈。

做法：

"分析 useMapSceneSatellite.tsx 中的渲染管线，
找出当 satelliteList 达到 3000 条时的性能瓶颈，
重点看：entity 创建频率、Cesium 的 Entity API vs Primitive API、
是否存在不必要的全量重绘"
→ AI 阅读渲染管线代码 → 分析 entity 创建模式 → 给出优化建议

效果：AI 定位到关键问题——每次数据更新时全量重建 entity 而非增量更新；同时指出 Cesium 的 Entity API 在海量对象下性能远不如 Primitive API，建议了迁移方向。这种分析纯人工做需要深入理解 Cesium 内部机制+反复实验，AI 几分钟给出端到端分析。

前端：图表可视化自动生成（~10x）

前端项目中大量使用 ECharts 和 D3 进行数据可视化——网络评估面板的拓扑图、延迟分布图、卫星覆盖率热力图、链路质量趋势图等。传统方式下，每个图表都需要翻文档、配 option、调样式。

做法：

  1. 把数据结构和需求一起给 AI： "我有一个 NetworkEvaluationData 类型的数据（粘贴类型定义）， 需要在 NetworkEvaluationPanel.vue 中新增一个 ECharts 图表： - X 轴：时间轴（formatTime 字段） - Y 轴：链路带宽利用率（百分比） - 双数据系列：上行/下行分别用蓝/绿色折线 - 需要 dataZoom 缩放组件、tooltip 显示详情、legend 可切换 参考项目中已有的图表风格"
  2. AI 自动处理上下文：读取组件文件 → 理解 Vue 模板结构 → 知道项目中已安装 echarts → 参考现有图表的代码风格（颜色、间距、响应式处理）
  3. 生成的代码包含：完整的 ECharts option 配置、Vue 响应式绑定、窗口 resize 监听、数据为空时的 placeholder 展示
  4. 人工微调：检查数据映射是否正确、颜色是否符合设计规范、交互行为是否符合预期

效果：

  • 一个复杂图表从手写 2-3 小时降到 15 分钟
  • AI 的独特优势：它同时"知道"三件事——你的数据结构（类型定义）、ECharts 的全部 API（训练数据覆盖）、你项目的代码风格（读取了上下文中的现有代码）。这三者结合，让它生成的 option 配置比你自己翻文档拼出来的更准确
  • 图表多了之后，AI 还能保持风格一致性——颜色调色板、间距、字号都是统一从已有代码推断的

💡 关键心得：图表可视化是 AI 效率最高的场景之一。因为它是典型的"规则密集型"任务——你需要的是正确的 API 调用和无数的细节配置，而不是创造性思考。AI 恰好擅长把"数据结构的语义"翻译成"图表库的配置语言"。

前端：BusinessClassStore 重构（~6x）

前端项目中 BusinessClassStore.ts 膨胀到了 1400+ 行，需要按职责拆分成多个子 store，但重构涉及几十处跨文件引用修改，纯手工操作繁琐且容易遗漏。

做法：

  1. 人做设计：分析 1400 行代码的职责边界，决定拆分为 SatelliteStore、NodeStore、LinkStore、EvaluationStore 四个子模块
  2. AI 做执行： "将 BusinessClassStore 中 satellite 相关的方法和状态迁移到新的 SatelliteStore， 更新所有引用文件中的 import 和调用路径" → AI 读取原文件 → 提取 satellite 相关代码 → 创建新 store → 扫描所有引用 → 批量更新 import 路径

效果：

  • 重构从预估 1 天压缩到不到半天
  • 关键是人机分工明确：架构决策（拆成几个、按什么维度拆）由人把握，机械性的代码迁移和引用替换由 AI 执行
  • git diff 显示引用路径的替换 100% 准确——这恰恰是 AI 最擅长的"有明确规则、大量重复"的工作

项目文档生成（~10x）

项目需要交付三份核心文档：二次开发手册、接口说明书、数据格式说明。传统方式要么从零手写，要么代码和文档割裂维护。

做法：

  1. 给出文档大纲结构："二次开发手册包含环境搭建、项目架构、核心模块说明、常见场景扩展指南"
  2. 结合 CODEBUDDY.md 中的项目架构说明 + 实际代码中的类型定义，AI 批量生成 Markdown 初稿
  3. 图表部分：ASCII 草图 → AI 转矢量图嵌入文档
  4. 接口说明部分：让 AI 读取 snss-types 包中的类型定义，自动生成 HTTP API 文档
  5. 数据格式部分：从 window.customStyles 的类型声明自动推导出配置格式说明

效果：

  • 三份文档从预估 5 人天压缩到 1 人天（含人工审校）
  • 文档与代码保持同步：类型定义更新后可以重新生成对应的文档章节
  • CODEBUDDY.md 既是 AI 的上下文，也是人类新人的上手指南——一份维护、两份受益

分析 9 个组件的 watch 策略（~10x）

需要分析多个组件的 Pinia watch 策略——这些文件分布在 4 个目录下。

做法：

"分析所有对 businessStore 做 watch 的地方，区分浅监听和深监听"
→ AI 批量扫描 → 汇总表格 → 给出性能结论

效果：几分钟出结果。手动做的话至少要半天，而且容易遗漏。关键结论（"全部使用浅监听，依赖整体重新赋值"）存入 Memory 后，后续对话自动生效。

生成 Git 日报（~3x）

做法：下班前说一句"写日报"，AI 自动从 Git 提交记录分类（功能/优化/修复/重构）并生成 Markdown 日报。

效果：从 10 分钟降到 10 秒。封装成 git-daily-report Skill 后，一句触发。

其他高频场景

场景做法效果
理解陌生代码拖文件进对话框 + "这段在干什么"；追踪调用链时让 Agent 跨文件搜索项目上手从 2-3 天压缩到半天
ASCII 框图转矢量图手写 SVG 描述 → AI 转 PNG/base64 → 自动嵌入 Markdown5 分钟完成，传统方式要在 Figma 画半天
跨文件追踪渲染管线一句话让 Agent 追踪 useMapScene → useMapSceneSatellite/Node/Link 的调用链无需手动 grep，一次拿到完整链路

4.3 建议大家使用 TypeScript

在 AI 辅助编程时代，TypeScript 不是可选项，而是必选项。

核心逻辑：AI 需要"理解"你的代码才能生成正确的代码。JavaScript 没有类型信息，AI 只能靠猜——猜这个变量是什么类型、这个函数返回什么。猜错了，就生成跑不通的代码。

TypeScript 的类型系统，就是一份机器可读的"接线图"：

// JavaScript：AI 只能猜
function processData(data, options) {
  // AI: "data 是啥？options 里有什么字段？"
}

// TypeScript：AI 一目了然
function processData(
  data: SatelliteInfo[],
  options: { layer: SatelliteLayer, highlight: boolean }
): ProcessedResult {
  // AI: "收到，入参是卫星数组和图层/高亮选项，返回 ProcessedResult"
}

三个实际好处：

  1. AI 生成的代码准确率更高：有类型约束，AI 不会给你传错参数类型
  2. AI 生成的文档更准确：类型的 JSDoc/TypeDoc 注释就是天然的文档素材，AI 能准确描述接口签名
  3. 重构更安全：改一个 interface，所有引用处的 AI 提示都会同步更新

因此 AI 越普及，类型安全的价值就越高。如果你的项目还在用纯 JavaScript，现在迁移到 TypeScript 的投资回报率比以往任何时候都大。

伍. 结语

AI 只是又一个"编译器"

Linus Torvalds 在最近一次访谈中说了一段发人深省的话：

编程的本质没变：从手写机器码到汇编器，再到编译器，编程工具的演进一直在提高抽象层级。AI 只是这漫长演进链条上的最新一环。编译器将生产力提高了 1000 倍，AI 可能会将你的生产力提高 10 倍。AI 很棒，但它并没有颠覆编程。

他创造了一个非常有洞察力的词——"氛围编程（Vibes-based Programming）"：

  • 对于一次性的、写完就扔的玩具项目，通过不断调整 Prompt 让 AI 生成代码，效果确实出色
  • 但如果你要构建一个需要长期维护的严肃项目，就不能只靠写 Prompt 让别人或 AI 替你生成代码

优秀的开发者依然优秀

在 AI 时代，优秀开发者与普通开发者的差距不会缩小，反而会拉大：

  • 优秀开发者真正理解系统和复杂性，知道如何引导 AI 产出高质量代码
  • 对系统缺乏理解的人，往往只会让 AI 生成更多隐藏的 Bug

Linus 本人即使在使用现代编译器、甚至让 AI 辅助生成代码的今天，依然会去检查最终生成的汇编代码，以确保程序真的按预期运行。

我的核心建议

  1. 不要满足于当一个 Prompt 工程师。工具门槛越低，理解底层原理、驾驭复杂架构的能力，就越是你不可替代的护城河。
  2. AI 的输出要验证，不要盲信。用 git diff 看改动、跑测试、review 逻辑——这些习惯在 AI 时代比以往更重要。
  3. 使用TypeScript编写代码。迁移到 TypeScript，写好类型注释。这是你能给 AI 提供的最好"项目文档"。
  4. 把重复劳动交给 AI，把深度思考留给自己。AI 擅长检索、分类、模板生成；你擅长领域建模、架构决策、业务理解。各司其职，效率最高。
  5. 持续维护项目的 AI "认知基础设施"：CODEBUDDY.md、Rule、Memory、Skill。这些投入的回报是指数级的——它们让每一次 AI 对话都站在上次的肩膀上。
avatar
文章
阅读
粉丝