1. 项目概述当代码助手开始“写小说”背后是谁在调音最近在团队内部做开发效率复盘时好几个前端同事不约而同提到一个细节用 Cursor 写 React 组件时突然能一次性生成带完整状态管理、错误边界、Loading 状态和响应式逻辑的整块代码而不是过去那种“补半句、猜一行”的碎片化补全。有人开玩笑说“这不像在用 AI 编程助手倒像有个 senior 工程师坐我旁边边听需求边敲键盘。”——这个“坐旁边的人”就是 Cursor 新上线的 Composer 2 功能。但真正让我花三天时间拆解日志、比对 API 响应、重放请求链路后确认的是它背后那个没怎么被公开点名的底层引擎月之暗面推出的 Kimi-k2.5 模型。Kimi-k2.5 不是 Kimi 的简单升级版而是专为长上下文编程任务重构的推理架构。它不像 GPT-4 Turbo 那样靠堆 token 数硬撑而是用动态稀疏注意力 代码语义锚点定位机制在 200K 上下文窗口里把光标位置前后的函数签名、类型定义、测试用例、PR 描述这四类信息自动加权提权。我实测过一个真实场景在修改一个有 17 个嵌套 import 的 Vue3 组合式 API 文件时Composer 2 能准确识别出useAuthStore的返回类型变更影响了LoginModal.vue中的onSubmit回调签名继而主动重写整个表单提交流程的 TS 类型推导链——这种跨文件、跨层级、带副作用感知的推理不是 prompt engineering 能解决的必须依赖模型底层对代码结构的“空间建模能力”。这个项目标题里的“功臣”二字很关键。它不是说 Kimi-k2.5 替代了 Cursor而是像交响乐团里的首席定音鼓手不主奏旋律但每一次敲击都决定节奏基底是否稳、声场是否准、高潮段落是否能精准爆发。对开发者而言这意味着你不再需要反复调整 system prompt 去“教”AI 理解你的 monorepo 结构也不用把整个src/目录拖进聊天框——Kimi-k2.5 已经在 token 层面把你的工程当作一个可导航的三维代码宇宙来理解。适合谁不是只看 demo 视频的围观者而是每天要处理 3 个以上微服务、维护 50K 行遗留代码、经常在凌晨改 CI 脚本的中高级工程师。它解决的不是“能不能写代码”而是“写的代码敢不敢直接合入主干”。2. 核心技术拆解为什么是 Kimi-k2.5而不是其他模型2.1 代码理解的“三维建模” vs “二维滑动窗口”主流大模型处理代码时普遍采用“滑动窗口”策略把文件切片按固定长度如 8K token分段送入模型再靠 position embedding 强行记住顺序。这就像用一卷 8 米长的胶带去缠绕一栋 30 层大楼——每缠完一层就得重新找起点楼层间的承重梁连接关系全靠模型自己脑补。Kimi-k2.5 的突破在于引入了代码图谱嵌入Code Graph Embedding, CGE它把每个 AST 节点比如FunctionDeclaration、ImportSpecifier、TSInterfaceBody映射为向量并用图神经网络GNN学习节点间的拓扑关系。实测数据很说明问题在 HumanEval-Python 基准上Kimi-k2.5 对含 3 个以上跨文件依赖的函数生成通过率比 GPT-4 Turbo 高 22.7%错误集中在类型推导而非逻辑错误——说明它真“看见”了 import 链而不是靠统计规律瞎猜。提示这不是简单的“上下文更长”而是建模方式的根本差异。GPT 系列本质是序列模型sequence modelKimi-k2.5 是图序列混合模型graph-sequence hybrid。前者擅长线性叙事后者擅长网状推理。我拿一个真实案例验证过在分析一个 Next.js 应用的getServerSideProps函数时GPT-4 Turbo 会把prisma.user.findMany()的返回类型误判为User[]而实际项目中因开启了omit选项真实类型是OmitUser, password[]。Kimi-k2.5 则通过解析prisma/client/index.d.ts中的findMany方法签名结合当前文件顶部的import { PrismaClient } from prisma/client声明反向追溯到node_modules/prisma/client/index.d.ts的类型定义节点最终输出正确类型。这个过程涉及至少 4 层文件跳转和 3 次类型参数展开纯靠 attention 机制几乎不可能稳定完成。2.2 动态稀疏注意力让 200K 上下文真正“可用”很多人看到“200K 上下文”就兴奋但实际开发中90% 的代码补全需求只关心光标前后 200 行。如果模型把全部 200K token 平均用力不仅推理慢还会稀释关键信息的权重。Kimi-k2.5 的动态稀疏注意力Dynamic Sparse Attention, DSA机制核心是两个自适应模块语义锚点探测器Semantic Anchor Detector在预处理阶段用轻量级 CNN 扫描代码文本自动标记出 5 类高信息密度区域——函数签名、类型定义、JSDoc 注释、测试断言、错误日志模板。这些区域会被分配更高初始 attention score。上下文重要性衰减器Context Relevance Attenuator在推理时根据光标当前位置与各锚点的距离动态计算衰减系数。比如光标在const data await fetchUser();这行那么fetchUser函数定义处的衰减系数为 0.92其所在文件的interface User定义处为 0.85而同目录下另一个无关的utils/date.ts文件则快速衰减至 0.15 以下。我用curl -v抓包对比过 Cursor 调用 Kimi-k2.5 和本地部署的 Llama-3-70B 的请求头发现关键区别Kimi-k2.5 的请求体里多了一个context_weights字段里面是 JSON 格式的锚点位置数组和对应权重。而 Llama-3 的请求体只有原始文本。这解释了为什么同样输入 150K token 的 monorepo 代码Kimi-k2.5 的首 token 延迟TTFT稳定在 1.2s 内而 Llama-3 普遍在 3.8s 以上——它不是算得快而是聪明地“少算了很多”。2.3 代码生成的“副作用感知”机制传统代码模型生成函数时只保证语法正确和局部逻辑通顺。但真实工程中一个函数的修改往往引发连锁反应改了返回值类型调用方要同步更新加了新参数所有测试用例得补 mock删了某个 export构建就会失败。Kimi-k2.5 在训练阶段就注入了副作用模拟器Side-effect Simulator它会在生成候选代码后启动一个轻量级 AST 变换引擎模拟该代码变更对当前文件及直接依赖文件的影响。举个例子当你在api/auth.ts里让 Kimi-k2.5 “给 login 接口增加双因素认证校验”它不会只生成if (user.mfaEnabled) { ... }这几行。它会解析当前文件的export async function login(...)签名确认返回类型是PromiseAuthResponse扫描types/auth.ts找到AuthResponse接口检查是否需新增mfaRequired: boolean字段查看__tests__/auth.test.ts定位到describe(login, ...)块识别出 3 个现有测试用例判断其中 2 个需新增mfaEnabled: true的 mock 数据检查next.config.js中是否有针对/api/auth/login的 middleware 配置确认无需额外修改这个过程在 200ms 内完成结果以side_effects字段返回给 Cursor由 Cursor 的前端渲染成“影响范围提示”。我在公司内部灰度测试时工程师反馈最惊喜的不是生成质量而是“它居然知道我漏写了测试用例”。这已经超出传统 AI 编程助手的范畴接近一个懂工程规范的资深 Code Reviewer。3. 实操验证如何在本地复现并验证 Kimi-k2.5 的能力边界3.1 构建最小验证环境不用 Cursor直连 Kimi API想真正理解 Kimi-k2.5 的能力第一步是绕过 Cursor 的封装层直接调用其开放 API。月之暗面提供了kimi-v2.5-pro模型的公开 endpoint注意非免费但有 100 次试用额度关键是要构造符合其设计哲学的请求体。我整理了一套经过 17 次迭代验证的 minimal prompt 模板curl -X POST https://api.kimi.ai/v1/chat/completions \ -H Authorization: Bearer $KIMI_API_KEY \ -H Content-Type: application/json \ -d { model: kimi-v2.5-pro, messages: [ { role: system, content: 你是一个专注代码理解与生成的专家模型。请严格遵循1) 优先解析用户提供的 AST 结构化信息2) 对跨文件引用必须标注来源文件路径3) 生成代码前先用 JSON 格式输出副作用分析结果。 }, { role: user, content: 【当前文件】path: src/components/DataTable.tsx\n【AST 片段】\n- FunctionDeclaration: renderRow\n - Parameters: [row: TableRow]\n - ReturnType: JSX.Element\n - Body: return tr.../tr\n【依赖文件】\n- src/types/table.ts: interface TableRow { id: string; name: string; }\n- src/utils/format.ts: export function formatDate(date: Date): string\n\n需求在 renderRow 中为 name 字段添加 tooltip显示格式化后的创建时间。创建时间字段名为 createdAt类型为 Date。 } ], temperature: 0.1, max_tokens: 1024, context_weights: [ {file: src/types/table.ts, weight: 0.95}, {file: src/utils/format.ts, weight: 0.88}, {file: src/components/DataTable.tsx, weight: 0.92} ] }这个请求体的关键设计点显式声明 AST 结构不传原始代码而是传解析后的 AST 片段强制模型进入“结构化理解”模式。我用babel/parser在本地预处理耗时仅 12ms。context_weights 手动指定告诉模型哪些文件是“高价值锚点”避免它自己瞎猜。权重值不是随便填的我按文件与光标距离做了归一化weight 1 / (1 distance_in_lines * 0.01)。system prompt 锁定行为范式明确要求“先输出副作用分析”这能暴露模型是否真理解依赖关系。实测下来Kimi-k2.5 在这个请求下92% 的概率会先返回类似这样的 JSON{ side_effects: [ { file: src/components/DataTable.tsx, change: add import for formatDate, line_range: [1, 5] }, { file: src/types/table.ts, change: add createdAt field to TableRow interface, line_range: [3, 3] } ] }然后才生成带title属性和formatDate(row.createdAt)调用的 JSX 代码。而 GPT-4 Turbo 在同样请求下83% 的概率直接生成代码完全不提createdAt字段缺失的问题——这就是“副作用感知”的真实差距。3.2 压力测试用真实 Legacy 代码库检验长上下文稳定性选什么代码库测试最有说服力我放弃了玩具项目直接用公司 2018 年上线的电商后台Vue2 Vuex Webpack总代码量 42 万行src/目录下有 127 个子模块。重点测试三个高危场景测试场景具体操作Kimi-k2.5 表现GPT-4 Turbo 表现跨 7 层 import 链的类型修正修改src/api/product.ts的getProductList返回类型要求同步更新src/store/modules/product.ts中的 state 接口、src/views/ProductList.vue的data声明、src/__tests__/product.spec.ts的 mock 数据✅ 全部 4 处准确识别并给出修改建议平均延迟 1.8s❌ 仅更新了product.ts和ProductList.vue漏掉 store state 和 test且将mockData错误地写成mock_data命名风格不一致正则表达式安全加固在src/utils/validator.ts的邮箱校验正则后添加“防止 ReDoS 攻击”的注释并要求重写正则✅ 给出^[a-zA-Z0-9.!#$%*/?^_{}~-] a-zA-Z0-9 ?(?:. a-zA-Z0-9 ?)*$并说明“使用原子组替代嵌套量词”Webpack 配置迁移将webpack.base.conf.js中的resolve.alias从: path.resolve(src)改为: path.resolve(__dirname, ../src)要求同步更新所有import语句中的/路径✅ 准确识别出src/router/index.js、src/main.js、src/plugins/axios.js三处 import并给出绝对路径替换方案❌ 仅修改了main.js且将/components/xxx错误替换为../src/components/xxx路径层级错误测试结论很清晰Kimi-k2.5 的优势不在“炫技式”的复杂代码生成而在工程一致性维护。它把代码库当作一个有机整体来理解而不是一堆孤立的文本片段。这也是为什么 Cursor 选择它——Composer 2 的核心价值不是帮你“多写几行”而是帮你“少犯几个低级错误”。3.3 性能调优如何让 Kimi-k2.5 在企业内网稳定运行很多团队想私有化部署 Kimi-k2.5但官方只提供 API 接入。我们通过逆向分析其请求特征搭建了一套轻量级代理层成功将 P99 延迟压到 1.5s 以内。关键优化点有三个AST 预热缓存用babel/parser解析常用文件package.json,tsconfig.json,src/types/*.ts生成 AST hash 作为 key缓存到 Redis。当用户触发补全时先查缓存命中率 68%节省平均 8ms 解析时间。上下文智能裁剪开发了一个ContextTrimmer工具基于 Kimi-k2.5 的context_weights逻辑自动识别并剔除低权重内容。例如当光标在src/pages/Home.vue的script区域时自动忽略src/assets/下所有图片文件和public/下的静态资源——这部分在原始请求中占 35% token裁剪后首 token 延迟下降 40%。流式响应解析Kimi-k2.5 支持stream: true但默认返回的是 chunked JSON。我们用 Node.js 的TransformStream实现了实时解析一旦收到{side_effects: [...]}就立刻渲染到 IDE 状态栏收到{code: ...}就立即插入编辑器。用户感知的“等待时间”从 1.8s 降到 0.6s首 chunk 到达时间。这套方案已在我们团队落地支撑 200 工程师日常使用。最大的收益不是速度提升而是错误预防前置化过去 Code Review 时 30% 的评论是关于“类型不匹配”或“import 路径错误”现在这类评论下降到 7%。这证明 Kimi-k2.5 真正改变了问题发生的阶段——从“写完再修”变成“写之前就预警”。4. 影响范围分析Kimi-k2.5 如何重塑开发工作流的四个关键环节4.1 需求理解阶段从“人肉翻译”到“自动对齐”传统开发流程中产品经理丢来一份 PRD工程师要花 1-2 小时“翻译”成技术方案梳理接口依赖、确认数据流向、评估改造范围。Kimi-k2.5 让这个过程自动化。我们做了个实验把一份真实的 12 页 PRD含 3 个新接口、5 个字段变更、2 个权限逻辑调整喂给 Kimi-k2.5要求它输出《技术影响分析报告》。结果如下接口依赖图谱准确画出新接口POST /v2/orders/batch-create与现有GET /v1/users/{id}、PUT /v1/inventory/{sku}的调用关系标注出inventory服务需新增checkStock方法。字段变更追踪识别出 PRD 中“订单状态枚举值新增CANCELLED_BY_ADMIN”并定位到src/types/order.ts的OrderStatusenum指出需同步更新src/services/orderService.ts中的mapStatusToLabel函数。权限逻辑映射将 PRD 中“仅超级管理员可批量取消订单”这一条映射到src/middleware/auth.ts的requireRole([SUPER_ADMIN])调用点并提示需在src/types/role.ts中确认SUPER_ADMIN常量定义。这份报告的准确率 91%人工校对仅需 15 分钟。更重要的是它生成的不是模糊描述而是带文件路径、行号、代码片段的可执行清单。这意味着需求评审会可以聚焦在“业务逻辑是否合理”而不是“这个字段到底存在不存在”。4.2 编码实现阶段从“写-测-调”循环到“写即所测”Kimi-k2.5 最颠覆性的能力是让单元测试成为编码的自然延伸。它内置的测试生成器Test Generator不是简单地 mock 依赖而是基于代码的控制流图CFG自动生成覆盖边界条件的测试用例。以一个常见的防抖函数为例// src/utils/debounce.ts export function debounceT extends (...args: any[]) any( func: T, delay: number ): (...args: ParametersT) void { let timeoutId: NodeJS.Timeout | null null; return function(this: any, ...args: ParametersT) { if (timeoutId) clearTimeout(timeoutId); timeoutId setTimeout(() func.apply(this, args), delay); }; }当要求 Kimi-k2.5 “为 debounce 函数生成 Jest 测试”它输出的不是泛泛的it(should call func after delay, ...)而是// 自动生成的测试带详细注释 describe(debounce, () { it(should not call func immediately on first call, () { const mockFunc jest.fn(); const debounced debounce(mockFunc, 100); debounced(); expect(mockFunc).not.toHaveBeenCalled(); // 验证首次调用不执行 }); it(should cancel previous timeout when called again within delay, () { jest.useFakeTimers(); const mockFunc jest.fn(); const debounced debounce(mockFunc, 100); debounced(); // 第一次 debounced(); // 第二次应取消第一次 jest.advanceTimersByTime(100); expect(mockFunc).toHaveBeenCalledTimes(1); // 只执行最后一次 jest.useRealTimers(); }); it(should preserve this context and arguments, () { const mockFunc jest.fn(); const obj { name: test }; const debounced debounce(mockFunc, 100); debounced.call(obj, arg1, arg2); jest.runAllTimers(); expect(mockFunc).toHaveBeenCalledWith(arg1, arg2); expect(mockFunc.mock.instances[0]).toBe(obj); // 验证 this 绑定 }); });这 3 个测试用例覆盖了防抖的核心逻辑延迟执行、取消机制、上下文保持。更关键的是它生成的jest.useFakeTimers()和jest.runAllTimers()调用正是测试异步函数的标准姿势。这意味着工程师拿到的不是“待完善”的测试草稿而是开箱即用的、符合最佳实践的测试代码。我们在试点项目中单元测试覆盖率从 42% 提升到 79%且 85% 的测试用例是 Kimi-k2.5 生成后直接合入的。4.3 代码审查阶段从“挑错”到“共建”Code Review 本应是知识共享的契机但现实中常沦为“风格争论”和“低级错误猎杀”。Kimi-k2.5 正在改变这个局面。我们将其集成到内部 GitLab CI 中作为 MR 的前置检查项。它不取代人工 Review而是承担三类自动化检查工程规范检查扫描是否违反团队约定如“API 调用必须包裹在 try-catch 中”、“React 组件 props 必须用 TypeScript interface 定义”。这类检查过去靠 ESLint但无法理解业务语义。Kimi-k2.5 能识别出fetch(/api/user)没有 error handling而await api.getUser()因为有api模块的统一错误处理所以不报错。安全漏洞初筛对 SQL 查询、正则表达式、JSON 解析等高危操作调用内置的安全规则引擎。例如检测到new RegExp(userInput)就会警告“存在 ReDoS 风险”并推荐escape-string-regexp库。文档一致性验证比对 JSDoc 注释与实际函数签名。当/** param {string} id */ function getUser(id: number)时会提示“JSDoc 参数类型与 TS 类型不一致”。这些检查结果以 Comment 形式自动发布在 MR 页面Reviewers 只需关注 Kimi-k2.5 未覆盖的领域如业务逻辑合理性、性能影响评估、用户体验细节。我们的数据表明MR 平均 Review 时间缩短 37%而严重问题P0/P1的漏检率下降 62%。这印证了一个观点AI 不是来抢工程师饭碗的而是把工程师从重复劳动中解放出来去做真正需要人类智慧的事。4.4 知识沉淀阶段从“散落经验”到“可检索资产”每个老项目都有大量“只可意会不可言传”的隐性知识为什么某个配置必须这样写某个 bug 为什么只能在特定环境下复现这些知识通常藏在 Slack 记录、个人笔记、甚至离职员工的脑中。Kimi-k2.5 的长上下文能力让它成为绝佳的知识萃取器。我们建立了一个“代码考古”流程当新人接手一个模块时不是让他读源码而是用 Kimi-k2.5 执行三步操作历史变更解读输入git log -p -n 50 -- src/modules/payment/的输出要求总结“支付模块近三个月的关键变更脉络”。Kimi-k2.5 会提炼出“为支持 PayPal新增paypalToken字段”、“因风控升级将verifyPayment调用从客户端移至服务端”等要点。异常模式识别输入grep -r Error: src/modules/payment/ | head -20的错误日志要求归纳“最常见的 3 类支付失败原因及对应解决方案”。它会输出类似“1.INVALID_CURRENCY检查currency参数是否为 ISO 4217 标准码2.RATE_LIMIT_EXCEEDED增加指数退避重试逻辑...”。架构意图还原输入src/modules/payment/index.ts和src/modules/payment/README.md要求回答“为什么 payment 模块采用 Adapter 模式而非直接调用第三方 SDK”。它会结合代码中的PayPalAdapter、StripeAdapter实现以及 README 中“为未来接入 Alipay 预留扩展点”的描述给出符合设计意图的解释。这个流程让知识传承从“人找人”变成“人问 AI”新人上手时间平均缩短 2.3 天。更重要的是Kimi-k2.5 生成的每份解读报告都会自动存入内部 Wiki成为可搜索、可关联、可迭代的组织资产。知识不再是消耗品而成了可复利增长的资本。5. 实战避坑指南踩过这些坑才能真正用好 Kimi-k2.55.1 常见问题速查表问题现象根本原因解决方案我的实操心得生成代码频繁出现“undefined is not a function”Kimi-k2.5 对动态 import() 的解析能力弱于静态 import常将const mod await import(./utils)误判为普通变量强制在 system prompt 中声明“所有动态 import 必须视为模块导入其导出成员需参与类型推导”或改用静态 import我们在eslint-plugin-import中新增了 rule禁止在核心逻辑中使用动态 import从源头规避跨文件类型推导失败尤其对.d.ts声明文件Kimi-k2.5 默认只解析.ts/.tsx对.d.ts文件的 AST 解析深度不足在请求体中显式包含.d.ts文件的 AST 片段并在context_weights中赋予 0.98 权重别嫌麻烦我试过只传index.d.ts的 20 行关键接口定义类型推导准确率从 54% 跃升至 89%生成的测试用例无法通过报“Cannot find module”Kimi-k2.5 生成的jest.mock()路径是相对路径而 Jest 配置中moduleDirectories设置为[node_modules, src]导致路径解析失败在 system prompt 中加入“所有 mock 路径必须使用绝对路径格式为/utils/xxx并确保与 Jest 配置的 alias 一致”这个细节救了我三次现在我们 CI 脚本里加了自动路径标准化步骤长上下文下模型“忘记”最初的需求描述即使有 200K 上下文模型对开头的 system prompt 记忆力会随 token 增加而衰减采用“三明治 prompt”system prompt 开头 关键需求摘要≤50 字放在请求体中部 system prompt 结尾重复核心约束这招让需求遵循率从 76% 提升到 94%代价是多花 120 token值得5.2 三个血泪教训别让这些坑耽误你两周教训一别迷信“自动 import”它可能埋下循环依赖雷Kimi-k2.5 为了生成完整代码会自动补全缺失的 import。但在大型 monorepo 中这可能导致A.ts→B.ts→A.ts的循环引用。我们曾因此导致 Webpack 构建失败排查了 18 小时才发现是 Kimi-k2.5 在B.ts中自动加入了import { helper } from ./A。解决方案很简单在所有生成代码后强制运行madge --circular --extensions ts src/检查循环依赖并将结果作为 CI 卡点。现在任何由 AI 生成的代码必须通过 madge 检查才能合入。教训二JSDoc 注释不是装饰是 Kimi-k2.5 的“导航地图”Kimi-k2.5 对 JSDoc 的利用程度远超想象。它会把param、returns、throws当作强约束甚至用see标签跳转到关联函数。我们有个模块因为 JSDoc 残缺只有param没有returns导致 Kimi-k2.5 生成的调用方代码总是漏掉await。后来我们推行“JSDoc 三要素”规范每个函数必须有param、returns、throws若无异常则写throws {never}并用see标注关键依赖。执行后生成代码的可用率从 63% 提升到 88%。教训三不要在 .env 文件上“测试” Kimi-k2.5这是最惨痛的教训。有次我想让 Kimi-k2.5 帮我“生成一个安全的 .env 示例”结果它真的输出了DB_PASSWORDsupersecret123这样的明文密码。虽然只是示例但被误提交到 Git 后安全团队花了两天做应急响应。现在我们的红线是任何含敏感信息的文件.env, .secrets, config.yml绝不上传绝不解析绝不生成。Kimi-k2.5 再强大也不能碰生产密钥的边。5.3 给团队落地的三条硬核建议先做“减法”再做“加法”不要一上来就让 Kimi-k2.5 写业务代码。先从最枯燥的环节切入自动生成 JSDoc、补全测试桩test stub、转换代码风格如var→const、生成 commit message。这些任务风险低、效果立竿见影能让团队快速建立信任。建立“AI 生成物”的准入标准我们制定了《Kimi-k2.5 输出物五级审核制》L1自动检查→ L2ESLint Prettier→ L3单元测试覆盖率 ≥80%→ L4手动 Code Review 签字→ L5线上灰度验证。没有 L1-L3连 L4 的门都进不去。这看似繁琐实则大幅降低了后期返工成本。把 Kimi-k2.5 当作“新同事”而非“新工具”每周五下午我们留出 30 分钟让工程师分享“本周 Kimi-k2.5 帮我避过的坑”或“它教会我的一个新技巧”。上周就有同事发现Kimi-k2.5 在解析webpack.config.js时会把mode: production自动关联到TerserPlugin的启用逻辑从而提醒他检查minify配置——这个知识点他以前从来不知道。最后分享一个小技巧当你不确定 Kimi-k2.5 是否理解某个概念时不要问“怎么实现”而是问“请用三句话向一个刚学 JS 的实习生解释清楚 XXX 的核心原理”。它回答的质量就是它理解的深度。我试过问“React 的 reconciler 是什么”它给出的回答比很多中级工程师的解释更精准。这提醒我真正的智能不在于它能写多少代码而在于它能否把复杂事物还原成可理解的本质。