Xiazhou Hexo https://000902.icu/ All rights reserved 2026, Xiazhou 工单系统 · 前端工程化 · Vue 生态 Xiazhou's Blog 2026-09-10T13:48:38.086Z Xiazhou AI 又又造词，Graph 就又要替代 Loop 了？

本文转载自掘金，作者：恋猫de小郭。原文链接：点击查看

OpenClaw 的 Peter 是懂嘲讽的，之前也是他提的，Prompt Engineering 已经成为过去，开始要进入 Loop Engineering 了，然后最近他发现，大家已经开始炒 Gr

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/23/ai-%E5%8F%88%E5%8F%88%E9%80%A0%E8%AF%8D-graph-%E5%B0%B1%E5%8F%88%E8%A6%81%E6%9B%BF%E4%BB%A3-loop-%E4%BA%86/ 2026-07-23T16:00:00.000Z OpenClaw 的 Peter 是懂嘲讽的，之前也是他提的，Prompt Engineering 已经成为过去，开始要进入 Loop Engineering 了，然后最近他发现，大家已经开始炒 Gr AI 又又造词，Graph 就又要替代 Loop 了？ 2026-09-10T13:48:38.086Z Xiazhou 被 iOS 弹窗支配的恐惧

先说现象

线上反馈：iOS 上工单流程弹窗显示不全——底部被切掉一块，点不到按钮。

复现场景：

设备结果
Android正常
iOS 微信内置浏览器弹窗底部被截断
iOS Safari同上
PC Chrome正常

弹窗用的是 uni-app 的 u-popup / u-drawer 组件（基于 uView UI），弹出的内容区域有 scroll-view 滚动列表。

核心报错：Maximum call stack size exceeded，查了后才确认是 Safari 对 max-height: 100% 的解析问题。

第一阶段：浮层被挡住

最开始，弹窗内容被页面上的导航条和筛选栏挡住了。查 CSS 发现 u-drawer / u-modal 的 z-index 只有 10090，但页面的固定 header 用了 z-index: 999——按理说弹窗还是更高，但 iOS 上 fixed 层级渲染有差异。

修复： 在 App.vue 覆盖全局 z-index：

1
2
3
4
5
.u-drawer,
.u-modal,
uni-modal {
  z-index: 19999 !important;
}

这一步解决了「挡住」问题，但「底部截断」还在。

第二阶段：底部截断，排查定位

弹窗本身样式加了 max-height: 90%，在 Android 上正常工作，iOS 上却把弹窗撑满全屏，内容溢到屏幕外。

检查 DOM 发现绘制出来的 .u-drawer 的 scrollHeight 远超预期。

关键线索是控制台报错：

1
RangeError: Maximum call stack size exceeded

搜了一圈，这其实是个 Safari 的老坑：当一个元素的 max-height 是百分比，且父容器的 height 不确定时，Safari 会重新进入布局计算循环，导致栈溢出。

具体到我们的组件链：

1
视图区 → scroll-view → .u-drawer__content → ... → 内容（动态高度）

中间某个环节的 height 没有被明确定义，Safari 就会因为 max-height: 100% 反复计算，最终栈溢出、渲染错误。

第三阶段：柔性修复方案

方案 A：固定 scroll-view 高度（√ 采用）

最直接的办法是给弹窗里的 scroll-view 一个固定高度，而不是依赖百分比继承：

1
2
3
scroll-view {
  max-height: 60vh;  /* 折中值，适配不同屏幕 */
}

这解决了大部分场景，但不同流程的弹窗内容高度差异大——有的只有几条数据，60vh 显得太空；有的很长，又不够用。

方案 B：MutationObserver + 动态 max-height（√ 最终方案）

考虑到不同弹窗、不同流程的内容量不可控，写死一个值显然不优雅。最终方案是：

MutationObserver 监听内容高度变化 → 动态计算并设置 max-height。

核心思路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 监听弹窗 open
MutationObserver.observe(scrollContainer, {
  attributes: true,       // 监听 style/class 变化
  childList: true,        // 监听内容增减
  subtree: true,          // 深度监听
})

function adjustMaxHeight() {
  const viewportHeight = window.innerHeight
  const contentHeight = scrollContent.scrollHeight
  // 弹窗本身有 padding/header 占用约 200px，再多留 20px 安全边距
  const maxHeight = Math.min(contentHeight, viewportHeight - 220)
  scrollContainer.style.maxHeight = maxHeight + 'px'
}

关键细节：

  1. 触发时机：不能只在 DOM 变化时算，还需要在弹窗的 CSS 动画（transition）完成后触发——否则拿到的 scrollHeight 不对。所以加了 setTimeout 延迟 100ms。
  2. 限制条件：只在 iOS 上启用（const isIOS = !!navigator.userAgent.match(/\(i[^;]+;( U;)? CPU.+Mac OS X/)），Android 上不受影响，避免不必要的性能开销。
  3. 备用方案：如果 Observer 没来得及触发（极快速切换），还保留了 max-height: 80vh 托底。

最终代码结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// related-to-me.vue + TodoTicketReport.vue

if (isIOS) {
  const observer = new MutationObserver(() => {
    clearTimeout(this.adjustTimer)
    this.adjustTimer = setTimeout(() => {
      const vh = window.innerHeight
      const sh = content.scrollHeight
      content.style.maxHeight = Math.min(sh, vh - 220) + 'px'
    }, 100)
  })
  observer.observe(scrollContainer, {
    attributes: true, childList: true, subtree: true
  })
}

第四阶段：overflow 清理

排查过程中还发现 detail.vue 里有一个前期遗留的 overflow: hidden——它会强制裁剪弹窗外层，让 iOS 下弹窗底部的阴影阴影消失。顺手去掉。

总结：时长与经验

整个修复过程分三波：

阶段改动文件耗时
z-index 提升App.vue~30 min
iOS 栈溢出 + MutationObserverrelated-to-me.vue, TodoTicketReport.vue~2 天
overflow 清理detail.vue~10 min

几个教训

  1. 不要相信 max-height: 100%——在 Safari 的布局引擎里，这行代码就是一个栈溢出炸弹。在非标准文档流（弹窗、浮层、drawer）中尤其危险。
  2. MutationObserver + vh 是动态布局的银弹——当 CSS 无法满足时，用 JS 算一次最靠谱。但要注意触发时机（CSS transition 完成后再读尺寸）。
  3. iOS 上 each 层级渲染不同——z-index 在 Android 和 iOS Safari 的行为有差异，不要用 Android 调试 iOS 样式。
  4. 输出日志——排查过程中借助了 vconsole 来捕获 iOS 端的异常堆栈（RangeError），如果没有在移动端打出这个栈信息，可能还在盲目调 CSS。
]]> https://000902.icu/2026/07/23/ios-popup-fix/ 2026-07-23T16:00:00.000Z 线上工单流程弹出层被页面 fixed 元素挡住，深扒 iOS Safari 栈溢出的底层原理，MutationObserver + z-index 双管齐下搞定。 被 iOS 弹窗支配的恐惧——一次 H5 弹窗层级问题的排查与修复 2026-09-10T13:48:38.087Z Xiazhou Kimi K3 重构10000行单文件屎山代码！

本文转载自掘金，作者：甲维斯。原文链接：点击查看

Vibe Coding 的“恶果”来了！！

最近在升级 JClaude，发现 Tokens 消耗特猛，然后分析了代码，发现其中有一个代码文件已经快 10000 行了。

大概算了下，光这一个文件上下文就有十几万 Token 了！

虽然程序运行完全正常，但是技术债越来越重了，所以必须重构一下。

最近刚好在测试 Kimi K3，我就把这个任务交给它了！

这个测试应该比做一个动画效果来得更有实际意义吧。

下面就来看一下，它的重构过程，以及重构后的结果。

1、项目简介

先简单介绍一下这个项目的情况：

这是我之前做的 Claude Code 中文界面版，完全克隆了 Claude 桌面版的界面，然后调用 Claude Code 终端，自动接入第三方模型。也就是说第三方模型可以直接用 Anthropic 家最强编程智能体，不受账号限制。

当然，如果你接入了 Opus 4.8，那这个软件的能力基本上约等于 Anthropic 官方的 Claude 桌面版。

因为最近加入了这个角色和技能相关的功能，就发现这个项目文件已经膨胀到让人无法接受的程度了。

这个项目开始于一个简单的界面克隆测试，所以当时并没有在意代码结构的问题。然后在修改的过程中，也没有强制提出重构的需求，所以 AI 就一直在堆“屎山”！

我估计很多很多的 Vibe Coding 项目都会面临这样的问题。刚开始呢是试着玩玩的，玩得爽了，就越改越大。

2、基础情况

这个项目是Tauri+Rust开发的，安装包和很小，内存开销也很低，可以制作多平台的发行包。界面部分主要是JS+CSS+HTML等前端代码，界面效果可以做的很好，后端是Rust，可以高效的和系统进行交互。开发支持热更新，效率很高。这是基础情况。

要重构代码的话，先得了解一下具体的代码的情况！

所以我们的对话是这么开始的：

当前代码中有哪些文件代码行数特别多？有没有做一下优化的必要性？

然后得到了这样一个结果：

从这里可以看到 main.js 已经 9338 行了，真的是快接近万行了，里面有 400 个函数！！！

接下来就是具体看一下里面有什么了！

main.js 内部结构

它本身是纯 script（无 import/模块化），靠 30 个 // ==== 注释分段。

最大的几段：

• Claude Code CLI bridge—— 约 2160 行，最大的单一块 • Experts & Skills 管理—— 约 800 行 • i18n—— 约 620 行，基本是翻译数据 • Code workspace panels / Projects / Settings / Providers—— 各 500-600 行

其实模块还是很清晰的，但是文件确实太大了！

有没有优化必要？

大概情况知道了，接下来就是判断一下有没有必要优化了。

K3 的结论是：有，但要看你们接下来的开发节奏，且不建议一次性大改。

支持拆分的理由：

bash
代码解读复制代码`• 单文件 9k+ 行已超过可维护性的常见阈值，多人协作时合并冲突几乎不可避免
​
• 部分段落是天然的拆分候选，成本低收益高：
​
• i18n 是纯数据，抽成 i18n/zh.json、i18n/en.json 之类，零风险
• CLI bridge 2000+ 行自成一体，抽成独立模块后主文件立刻瘦 1/4

• Tauri 支持原生 ES modules，拆 <script type="module"> 不一定需要引入打包工具

1
2
3
4
5
6
7
8

它这里提到了很关键的一点，就是多人协作冲突是一个大问题。对我而言还好，我就是多 AI 合作，一把梭。

需要权衡的点：

 代码解读复制代码`• 目前测试覆盖很薄，大重构没有安全网，回归风险高
• 大文件本身不是病——如果这段代码已经稳定、很少改动，靠分段注释导航也能用

建议的优先级：

如果近期要持续加功能（尤其是 CLI bridge、Skills 相关），就按 “i18n → CLI bridge → 各 workspace 面板” 的顺序增量抽取，每抽一块跑一遍现有测试；

如果只是维护期、改动少，可以先不动，只把 i18n 数据分离出去。

3、多维度分析

目前的情况看来，除了大之外，没有特别大的问题。其实我比较担忧的是大文件情况下 AI 读写和 Token 消耗的问题。

所以我第二轮的需求是：

下面我们从代码设计、AI 读写以及 Token 消耗的角度来判断一下优化的必要性。

下面是 K3 的分析结果。

1、代码设计角度

python
代码解读复制代码`• main.js 的问题不只是”长”，而是无模块化的长：约 400 个函数全部是全局作用域，通过
一个全局 state 对象和 DOM id 隐式耦合。你没法只改”设置”而不碰”对话”，因为它们共
享同一片命名空间。
​
• 这直接导致可测试性差——测试薄（只有 3 个针对性测试）很大程度上是这个结构的果，不
是因。函数无法单独 import，就没法单测。
​
• lib.rs 同样 4148 行单文件，但 Rust 有模块系统和编译器兜底，拆分安全且容易，风险
远低于 main.js。
​
• styles.css 4836 行在 CSS 里不算异常，危害最低，可放最后。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

单看代码设计：有必要拆，但属于"慢性病"，不致命。

2、AI 读写角度

这是大文件代价最直观的地方：

scss
 代码解读复制代码`• 读不完整：主流 AI 工具单次读文件上限约 1000 行，9338 行的文件 AI 永远只能看局部
。改一个功能时，它读到目标段落，却看不到 3000 行外那个依赖同一全局状态的函数——
改坏联动的概率显著上升。
​
• 编辑易误伤：AI 编辑靠精确字符串匹配。9k 行文件里相似代码片段多（比如那 14 个并
排且结构几乎一样的 persistXxx() 函数），匹配唯一性差，误替换风险高。
​
• 定位成本高：目前靠 // ==== 分段标记 + grep 还能工作，但跨段依赖（全局 state、跨
段调用）对 AI 不可见，每次都要重新摸索。

拆成模块后，每个文件能被 AI 一次整读，心智模型完整，改动质量明显上升。

3、Token 消耗角度

按中英文混合代码约 3.5 字节/token 粗估：

perl
代码解读复制代码`• main.js 全量读入 ≈ 13 万 tokens，一次就吃掉大半个上下文窗口。
​
• 实际工作模式是 grep + 分页读若干段，但每次任务往往要读 state 定义段 + 目标功能段 +
相关 persist/i18n 段，累计轻松到 3-5 万 tokens，而且每次会话都重复消耗。
​
• 拆成模块后，一个任务通常只需整读 1-2 个相关文件（几千 tokens），单次任务省 80%+，
且是持续性收益——每次让 AI 改代码都在省钱。
​
• i18n 那 620 行是纯数据，最冤：经常被卷入上下文，却几乎不需要全部内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

这确实是个大问题，太浪费了。修改后能节省 80%，这个诱惑还是很大的。

4、综合判断

单看代码设计，拆分是"应该做但不紧急"；

叠加 AI 读写和 token 成本后，必要性明显升级——因为我主要就是用 AI 辅助开发，大文件的税是每次任务都在交的。

结论不变：增量拆分，顺序 i18n → CLI bridge → 各面板。

4、深入分析

其实，我心中早就有数了，因为我已经让 Opus 4.8 拆分过一次了。这次很明显也是让它按拆分的方向去的。

为了谨慎起见，或者说为了更好地引导 K3 完成任务，我再问它第三个问题：

那我们就先把 main.js 这个文件拆分一下吧。

那你觉得如何来拆分这个文件比较合适？

拆分到什么样的颗粒度比较合适？

拆分过程中应该注意什么？

如何保障成功完成这个重构任务？

1、怎么

对齐现有分段，分层 + 自下而上。加载方式从 `<script src="./main.js">` 改为 `<script type="module" src="./main.js">`。

然后按现有 `// ====` 分段抽取，分层依赖：

bash
 代码解读复制代码`• 第 0 层（纯数据，零依赖）：i18n、DEFAULTS、MODEL_BLURB/system prompt、action chip
prompts
​
• 第 1 层（基础）：state（全局 state + KEYS + 14 个 persistXxx）、storage、Tauri API
封装
​
• 第 2 层（UI 基建）：theme、sidebar、tooltip、菜单
​
• 第 3 层（功能域）：chat、projects、settings、providers、experts/skills、code
panels、CLI bridge、browser、code stats、mentions
​
• main.js 最终只剩入口：import + init/boot 顺序

2、颗粒度

一个分段一个模块，200–800 行/单文件

bash
代码解读复制代码`• 目标：每个文件能被人或 AI 一次整读（<1000 行），预计拆出 15–20 个文件，收进
src/js/ 之类的子目录。
​
• 不要再细：拆成 50 个 100 行的小文件会让 import 清单本身变成维护负担，跨文件跳转反
而更累。
​
• 也别贪全：chat/projects/settings 核心段耦合最重，如果拆到那里发现代价陡增，留一个
较大的 app.js（2000 行以内）也完全可以接受——80% 的收益来自前 20% 的抽取。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

3、注意事项（按翻车概率排序）

javascript
 代码解读复制代码`1. 测试 eval 耦合：如上所述，搬 DEFAULT_EXPERTS 等被测代码块时必须同步改测试的 SRC
路径，标记字符串原样保留。
​
2. 循环依赖：功能模块间必然互相调用（chat ↔ workspace ↔ projects）。ESM 循环导入在"
仅运行期调用、无顶层副作用"下是安全的——所以搬移时保持 function foo() {} 声明形式
（有提升），禁止在模块顶层执行跨模块调用，init 统一由 main.js 触发。
​
3. 共享 state 唯一性：state 对象（main.js:474）必须从 state.js 导出同一个引用，所有
模块 import 它，绝不能复制。
​
4. 只搬不改：每次提交只做机械搬移 + 补 import/export，不顺手优化逻辑。重构成败的关键
就是 diff 可审查。
​
5. import 清单遗漏：400 个函数分散后，漏一个 import 就是运行期 ReferenceError，静态
检查抓不住（项目无 lint）。对策见下。
​
6. init 顺序：boot splash、applyWorkspace 等有 DOM 时机依赖（index.html 注释专门提过
），入口处的初始化顺序原样保留。
​

虽然只是拆一个文件，其实难度还是有的。因为不同模块之间是有耦合的，我之前让 Opus 分析过，有些模块间的耦合度有几十个。一个拆完之后，文件行数和文件数量都会变化，所以模型必须重新学习新的结构，再进行后续的解耦。

4、如何保障成功

这一点很关键：

bash
代码解读复制代码`• 试点先行：第一步只做 i18n + state 两段，跑通”搬移 → 改测试 → 验证”全流程，确认模式
可行再批量搬。
​
• 每步三道闸：npm test 全绿（3 个 node 测试 + cargo test）→ npm run dev 启动冒烟（主
界面、聊天、设置、Code workspace 各点一遍，看控制台报错）→ 独立 commit。出问题单步
回退即可。
​
• 明确的完成标准：main.js 只剩入口（<300 行）、测试全绿、冒烟清单通过、每个被搬分段
都能在新文件里被 grep 到。
​
• 顺序：i18n → 纯数据 → state/storage → UI 基建 → CLI bridge（最大但自成一体，瘦 1/4
就靠它）→ experts/skills、code panels、browser → 核心段（视情况收尾）。

从它的回答看，应该是理解得比较透彻了。我已经经过 3 轮引导，它应该已经掌握了关键信息。所以，最后一句话就是：开干！5、重构过程下图是它自己做的 todo 任务列表：改完之后，还问了我两个问题：第一个是用 git 管理版本，方便回退。第二个是冒烟测试怎么做。这个还是很稳的！但是我对它的测试选项不是太满意，怎么可以把手动启动 dev 放在推荐呢？必须你来启动，我来看啊！另外说一点细节，可以作为对比参考。Opus 4.8 改的时候，虽然改得很细，但是很自信地告诉我它会自己做 dev 测试，我就做了个甩手掌柜。由于第一轮独立性比较强，整体修改非常快。我测试了一下，没有这么大问题。唯一的问题是无法调用 Claude Code！我不确定它为什么把内置CC给我跳过了，正常没有理由弹这个的。我把情况给它说了一下，它就成功解决这个问题了。那就没啥大问题了，继续推进！随着修改的深入，逐渐变得复杂起来了！改到中间环节的时候，验证点逐渐变多了，修改的时间也越来越久了。6、重构结果整个重构过程大概消耗了小半天时间。最后把这个 `main.js` 从 9938 行压缩到了 263 行，减少 97%。全部改成模块化设计，拆成了 24 个模块，每个 33-2177 行。总共提交了 13 个 commit，每步可单独回退。基础语法检查和其他校验它已经做好了，然后我人工检查了各项功能，全部是正常运转的。这次重构非常成功，而且毫无波澜！重构是要点脑子的，而且是一个非常严谨的问题，容不得一点错误。K3 能改完，没有错误，这一点还是略微出乎我的意料。2.8T 的参数了，果然是稳了很多！这一次测试结果还比较理想的！下一篇将要让它修改桌面软件的疑难 Bug 了，敬请期待！
]]> https://000902.icu/2026/07/23/kimi-k3-%E9%87%8D%E6%9E%8410000%E8%A1%8C%E5%8D%95%E6%96%87%E4%BB%B6%E5%B1%8E%E5%B1%B1%E4%BB%A3%E7%A0%81/ 2026-07-23T16:00:00.000Z Vibe Coding 的“恶果”来了！！ 最近在升级 JClaude，发现 Tokens 消耗特猛，然后分析了代码，发现其中有一个代码文件已经快 10000 行了。 大概算了下，光这一个文件上下文就 Kimi K3 重构10000行单文件屎山代码！ 2026-09-10T13:48:38.087Z Xiazhou 为什么很多人觉得前端很简单？

本文转载自掘金，作者：ErpanOmer。原文链接：点击查看

前端看似简单，实则复杂远超表象。视觉反馈快感掩盖了90%的隐性工作量，包括对抗失控的宿主环境、处理异步竞态灾难和防范内存泄漏。资深工程师用复杂机制伪装出简洁界面，在机器逻辑与人类行为间架起桥梁。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/21/%E4%B8%BA%E4%BB%80%E4%B9%88%E5%BE%88%E5%A4%9A%E4%BA%BA%E8%A7%89%E5%BE%97%E5%89%8D%E7%AB%AF%E5%BE%88%E7%AE%80%E5%8D%95/ 2026-07-21T16:00:00.000Z 前端看似简单，实则复杂远超表象。视觉反馈快感掩盖了90%的隐性工作量，包括对抗失控的宿主环境、处理异步竞态灾难和防范内存泄漏。资深工程师用复杂机制伪装出简洁界面，在机器逻辑与人类行为间架起桥梁。 为什么很多人觉得前端很简单？ 2026-09-10T13:48:38.088Z Xiazhou 全网都在吹的 Kimi K3，到底怎么样？

本文转载自掘金，作者：stormzhangV。原文链接：点击查看

国产最贵、速度还慢，凭什么还是国产之光？Kimi K3 前端能力全球第一梯队，长任务处理稳，还是开源模型，这次是真敢跟顶尖闭源模型掰手腕了。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/20/%E5%85%A8%E7%BD%91%E9%83%BD%E5%9C%A8%E5%90%B9%E7%9A%84-kimi-k3-%E5%88%B0%E5%BA%95%E6%80%8E%E4%B9%88%E6%A0%B7/ 2026-07-20T16:00:00.000Z 国产最贵、速度还慢，凭什么还是国产之光？Kimi K3 前端能力全球第一梯队，长任务处理稳，还是开源模型，这次是真敢跟顶尖闭源模型掰手腕了。 全网都在吹的 Kimi K3，到底怎么样？ 2026-09-10T13:48:38.088Z Xiazhou 用 Kimi K3 交付一个真实项目后：很强，但还有不足

本文转载自掘金，作者：孟健AI编程。原文链接：点击查看

大家好，我是孟健。 Kimi K3 正式发布了。这个结果，我终于可以公开说了：发布之前，我已经把 ShipSolo 微信小程序这个真实项目整个交给它，从需求梳理到部署验证走完全程，最终完整交付。 交付

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/19/%E7%94%A8-kimi-k3-%E4%BA%A4%E4%BB%98%E4%B8%80%E4%B8%AA%E7%9C%9F%E5%AE%9E%E9%A1%B9%E7%9B%AE%E5%90%8E-%E5%BE%88%E5%BC%BA-%E4%BD%86%E8%BF%98%E6%9C%89%E4%B8%8D%E8%B6%B3/ 2026-07-19T16:00:00.000Z 大家好，我是孟健。 Kimi K3 正式发布了。这个结果，我终于可以公开说了：发布之前，我已经把 ShipSolo 微信小程序这个真实项目整个交给它，从需求梳理到部署验证走完全程，最终完整交付。 交付 用 Kimi K3 交付一个真实项目后：很强，但还有不足 2026-09-10T13:48:38.089Z Xiazhou 停更的这一年，All In AI、陪媳妇生娃、还考了个研

本文转载自掘金，作者：我是Allen。原文链接：点击查看

停更的这一年，All In AI、陪媳妇生娃、还考了个研 打开掘金 App，看了一眼自己的最近更新——停在了整整一年前。 不是不想写，是这一年确实被塞得太满了。如果非要用几个关键词来概括，那就是： A

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/17/%E5%81%9C%E6%9B%B4%E7%9A%84%E8%BF%99%E4%B8%80%E5%B9%B4-all-in-ai-%E9%99%AA%E5%AA%B3%E5%A6%87%E7%94%9F%E5%A8%83-%E8%BF%98%E8%80%83%E4%BA%86%E4%B8%AA%E7%A0%94/ 2026-07-17T16:00:00.000Z 停更的这一年，All In AI、陪媳妇生娃、还考了个研 打开掘金 App，看了一眼自己的最近更新——停在了整整一年前。 不是不想写，是这一年确实被塞得太满了。如果非要用几个关键词来概括，那就是： A 停更的这一年，All In AI、陪媳妇生娃、还考了个研 2026-09-10T13:48:38.088Z Xiazhou Vue 和 React 真正的差距，不在语法，而在团队犯错成本

本文转载自掘金，作者：ErpanOmer。原文链接：点击查看

React 与 Vue 的本质区别在于：前者给予开发者极大自由度，但需团队具备高水平才能避免常见陷阱；后者通过底层机制自动兜底，显著降低犯错成本，更适合多数业务场景。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/16/vue-%E5%92%8C-react-%E7%9C%9F%E6%AD%A3%E7%9A%84%E5%B7%AE%E8%B7%9D-%E4%B8%8D%E5%9C%A8%E8%AF%AD%E6%B3%95-%E8%80%8C%E5%9C%A8%E5%9B%A2%E9%98%9F%E7%8A%AF%E9%94%99%E6%88%90%E6%9C%AC/ 2026-07-16T16:00:00.000Z React 与 Vue 的本质区别在于：前者给予开发者极大自由度，但需团队具备高水平才能避免常见陷阱；后者通过底层机制自动兜底，显著降低犯错成本，更适合多数业务场景。 Vue 和 React 真正的差距，不在语法，而在团队犯错成本 2026-09-10T13:48:38.088Z Xiazhou 为什么 AI 写前端时，总是优先选择 React，而不是 Vue？

本文转载自掘金，作者：ErpanOmer。原文链接：点击查看

AI编程工具默认生成React+Tailwind代码，而非Vue，本质是模型对语言结构纯粹性的偏好。React的JSX在AST层面更接近标准JS，而Vue的模板与脚本分离增加了模型理解成本，导致生成质量下降。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/15/%E4%B8%BA%E4%BB%80%E4%B9%88-ai-%E5%86%99%E5%89%8D%E7%AB%AF%E6%97%B6-%E6%80%BB%E6%98%AF%E4%BC%98%E5%85%88%E9%80%89%E6%8B%A9-react-%E8%80%8C%E4%B8%8D%E6%98%AF-vue/ 2026-07-15T16:00:00.000Z AI编程工具默认生成React+Tailwind代码，而非Vue，本质是模型对语言结构纯粹性的偏好。React的JSX在AST层面更接近标准JS，而Vue的模板与脚本分离增加了模型理解成本，导致生成质量下降。 为什么 AI 写前端时，总是优先选择 React，而不是 Vue？ 2026-09-10T13:48:38.088Z Xiazhou 一键还原任意网站，这套 Playwright + 多 Agent 工程流太猛了

本文转载自掘金，作者：我不是外星人。原文链接：点击查看

一 前言 哈喽，大家好，我是 alien，今天我们来讲一个能够将精美网站一键复制的功能——ai-website-cloner-template 的使用和实现原理。 通过本篇文档你能收获到哪些内容？ A

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/14/%E4%B8%80%E9%94%AE%E8%BF%98%E5%8E%9F%E4%BB%BB%E6%84%8F%E7%BD%91%E7%AB%99-%E8%BF%99%E5%A5%97-playwright-%E5%A4%9A-agent-%E5%B7%A5%E7%A8%8B%E6%B5%81%E5%A4%AA%E7%8C%9B%E4%BA%86/ 2026-07-14T16:00:00.000Z 一 前言 哈喽，大家好，我是 alien，今天我们来讲一个能够将精美网站一键复制的功能——ai-website-cloner-template 的使用和实现原理。 通过本篇文档你能收获到哪些内容？ A 一键还原任意网站，这套 Playwright + 多 Agent 工程流太猛了 2026-09-10T13:48:38.088Z Xiazhou 星云SDK + 油猴：给LLM塑造肉身，陪伴你在每个网页

本文转载自掘金，作者：石小石Orz。原文链接：点击查看

作为一名前端开发者，我一直有一个愿景：让大模型不再只是冰冷的输入框，而是能以具身交互智能数字人形象，出现在我们浏览的每一个网页上，一直陪伴我们。 这个想法其实来自钢铁侠的“贾维斯”，我希望在我使用浏览

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/13/%E6%98%9F%E4%BA%91sdk-%E6%B2%B9%E7%8C%B4-%E7%BB%99llm%E5%A1%91%E9%80%A0%E8%82%89%E8%BA%AB-%E9%99%AA%E4%BC%B4%E4%BD%A0%E5%9C%A8%E6%AF%8F%E4%B8%AA%E7%BD%91%E9%A1%B5/ 2026-07-13T16:00:00.000Z 作为一名前端开发者，我一直有一个愿景：让大模型不再只是冰冷的输入框，而是能以具身交互智能数字人形象，出现在我们浏览的每一个网页上，一直陪伴我们。 这个想法其实来自钢铁侠的“贾维斯”，我希望在我使用浏览 星云SDK + 油猴：给LLM塑造肉身，陪伴你在每个网页 2026-09-10T13:48:38.089Z Xiazhou Fiber 节点 —— 一个数据结构如何承载整个 React 运行时

本文转载自掘金，作者：老王以为。原文链接：点击查看

React通过 Fiber 节点去承载整个 React 的运行时，今天我们通过这篇文章来梳理一下 React 是如何做的，为什么要这样做，这样做背后的考量是什么？

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/08/fiber-%E8%8A%82%E7%82%B9-%E4%B8%80%E4%B8%AA%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E5%A6%82%E4%BD%95%E6%89%BF%E8%BD%BD%E6%95%B4%E4%B8%AA-react-%E8%BF%90%E8%A1%8C%E6%97%B6/ 2026-07-08T16:00:00.000Z React通过 Fiber 节点去承载整个 React 的运行时，今天我们通过这篇文章来梳理一下 React 是如何做的，为什么要这样做，这样做背后的考量是什么？ Fiber 节点 —— 一个数据结构如何承载整个 React 运行时 2026-09-10T13:48:38.086Z Xiazhou 凌晨睡不着，我给台风巴威写了个追踪网站

本文转载自掘金，作者：HiSt。原文链接：点击查看

索性爬起来，打开电脑，用 Claude Fable 5 把想法一点点敲了出来。把基于中央气象台、日本气象厅、美国 JTWC、台湾气象署四家的路径数据放在同一张地图上之后，很多事一眼就看明白了

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/07/%E5%87%8C%E6%99%A8%E7%9D%A1%E4%B8%8D%E7%9D%80-%E6%88%91%E7%BB%99%E5%8F%B0%E9%A3%8E%E5%B7%B4%E5%A8%81%E5%86%99%E4%BA%86%E4%B8%AA%E8%BF%BD%E8%B8%AA%E7%BD%91%E7%AB%99/ 2026-07-07T16:00:00.000Z 索性爬起来，打开电脑，用 Claude Fable 5 把想法一点点敲了出来。把基于中央气象台、日本气象厅、美国 JTWC、台湾气象署四家的路径数据放在同一张地图上之后，很多事一眼就看明白了 凌晨睡不着，我给台风巴威写了个追踪网站 2026-09-10T13:48:38.088Z Xiazhou 豆包和千问同时关了智能体，我用它们搭的 3 个自动化全废了——迁移方案整理

本文转载自掘金，作者：kyriewen。原文链接：点击查看

豆包和千问 7/15 同时下线智能体功能。整理了 4 种替代方案对比（Coze/Dify/Claude Code/自建API），附迁移操作指南和数据导出 Checklist。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/06/%E8%B1%86%E5%8C%85%E5%92%8C%E5%8D%83%E9%97%AE%E5%90%8C%E6%97%B6%E5%85%B3%E4%BA%86%E6%99%BA%E8%83%BD%E4%BD%93-%E6%88%91%E7%94%A8%E5%AE%83%E4%BB%AC%E6%90%AD%E7%9A%84-3-%E4%B8%AA%E8%87%AA%E5%8A%A8%E5%8C%96%E5%85%A8%E5%BA%9F%E4%BA%86-%E8%BF%81%E7%A7%BB%E6%96%B9%E6%A1%88%E6%95%B4%E7%90%86/ 2026-07-06T16:00:00.000Z 豆包和千问 7/15 同时下线智能体功能。整理了 4 种替代方案对比（Coze/Dify/Claude Code/自建API），附迁移操作指南和数据导出 Checklist。 豆包和千问同时关了智能体，我用它们搭的 3 个自动化全废了——迁移方案整理 2026-09-10T13:48:38.089Z Xiazhou 别被模型宣传骗了，真实 Agent 任务一跑就知道

本文转载自掘金，作者：轻口味。原文链接：点击查看

现在市面上能调用的模型确实越来越多了，各家都有自己的亮点和侧重点，光看宣传文档和跑分数据其实很难判断哪个真正适合自己——尤其是当任务从单轮对话延伸到多步操作的时候，情况就更加复杂了。 所以我就想着，不

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/05/%E5%88%AB%E8%A2%AB%E6%A8%A1%E5%9E%8B%E5%AE%A3%E4%BC%A0%E9%AA%97%E4%BA%86-%E7%9C%9F%E5%AE%9E-agent-%E4%BB%BB%E5%8A%A1%E4%B8%80%E8%B7%91%E5%B0%B1%E7%9F%A5%E9%81%93/ 2026-07-05T16:00:00.000Z 现在市面上能调用的模型确实越来越多了，各家都有自己的亮点和侧重点，光看宣传文档和跑分数据其实很难判断哪个真正适合自己——尤其是当任务从单轮对话延伸到多步操作的时候，情况就更加复杂了。 所以我就想着，不 别被模型宣传骗了，真实 Agent 任务一跑就知道 2026-09-10T13:48:38.088Z Xiazhou 首屏加载半秒开！还有谁！！！

本文转载自掘金，作者：锋行天下。原文链接：点击查看

这是我的网站登录页目前加载时间，毫秒级加载，嗖的一下就出来啦，现在总结一下怎么做到的 一，路由 懒加载，这是常规操作 二，UI组件库动态导入 一定不要在入口main.js里全部注册组件,使用插件动态自

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/04/%E9%A6%96%E5%B1%8F%E5%8A%A0%E8%BD%BD%E5%8D%8A%E7%A7%92%E5%BC%80-%E8%BF%98%E6%9C%89%E8%B0%81/ 2026-07-04T16:00:00.000Z 这是我的网站登录页目前加载时间，毫秒级加载，嗖的一下就出来啦，现在总结一下怎么做到的 一，路由 懒加载，这是常规操作 二，UI组件库动态导入 一定不要在入口main.js里全部注册组件,使用插件动态自 首屏加载半秒开！还有谁！！！ 2026-09-10T13:48:38.089Z Xiazhou 我用 Codex 重写了同事维护三年的代码，他没说谢谢——而是找了领导

本文转载自掘金，作者：kyriewen。原文链接：点击查看

我用 Codex 花一个周末重写了同事维护三年的代码，提了一个大 PR。他没有说谢谢，而是找了领导。这篇文章复盘了我在 AI 时代犯的一个典型错误：技术上正确不等于做法正确。

本文为自动转载草稿，请编辑后发布。

]]> https://000902.icu/2026/07/03/%E6%88%91%E7%94%A8-codex-%E9%87%8D%E5%86%99%E4%BA%86%E5%90%8C%E4%BA%8B%E7%BB%B4%E6%8A%A4%E4%B8%89%E5%B9%B4%E7%9A%84%E4%BB%A3%E7%A0%81-%E4%BB%96%E6%B2%A1%E8%AF%B4%E8%B0%A2%E8%B0%A2-%E8%80%8C%E6%98%AF%E6%89%BE%E4%BA%86%E9%A2%86%E5%AF%BC/ 2026-07-03T16:00:00.000Z 我用 Codex 花一个周末重写了同事维护三年的代码，提了一个大 PR。他没有说谢谢，而是找了领导。这篇文章复盘了我在 AI 时代犯的一个典型错误：技术上正确不等于做法正确。 我用 Codex 重写了同事维护三年的代码，他没说谢谢——而是找了领导 2026-09-10T13:48:38.089Z Xiazhou AI 编程工作流：上下文、任务拆分与代码审查

AI 编程不是”把需求丢进去，代码自己就写好了”。真实项目里，你需要管理上下文、拆分任务、审查代码、控制变更范围。这篇文章把我在项目中总结的 AI 编程工作流整理出来。

完整工作流

1
需求分析 → 任务拆分 → 上下文准备 → AI 实现 → 代码审查 → 测试验证 → 提交上线

每个环节都很重要，跳过任何一步都可能出问题。

第一步：需求分析

在让 AI 写代码之前，先自己想清楚：

问自己三个问题

  1. 要做什么：功能的边界是什么？
  2. 怎么做：技术方案是什么？
  3. 不能做什么：有哪些约束和限制？
1
2
3
4
5
# 让 Claude 帮你梳理需求
claude "我要给用户列表加分页功能，帮我梳理一下需求：
1. 需要考虑哪些场景？
2. 前后端分别需要改什么？
3. 有什么边界情况需要处理？"

第二步：任务拆分

大任务拆成小任务，每个小任务独立可验证。

拆分原则

原则说明
独立性每个任务独立完成，不依赖其他未完成的任务
可验证每个任务完成后都能验证是否正确
小粒度每个任务改 1-3 个文件，不超过 100 行代码

拆分示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
需求：用户列表加分页

任务 1：后端接口支持分页参数
  - 修改 UserMapper.xml 的查询语句
  - 修改 UserService 的分页逻辑
  - 修改 UserController 的参数接收

任务 2：前端分页组件
  - 创建 Pagination 组件
  - 在用户列表页引入组件

任务 3：前后端联调
  - 调用接口测试分页
  - 处理异常情况

任务 4：测试和优化
  - 添加单元测试
  - 优化加载速度

第三步：上下文准备

给 AI 提供必要的上下文，让它理解任务背景。

上下文清单

1
2
3
4
5
6
7
8
✅ 相关代码文件（当前要改的 + 相关的）
✅ 接口文档（如果有）
✅ 数据库表结构（如果涉及数据库）
✅ 相关的工具函数（如果要复用）
✅ 错误信息（如果有报错）
❌ 不相关的代码
❌ 敏感信息（密码、密钥）
❌ 过多的历史对话

实际操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 不好的做法：把所有文件都给 Claude
cat src/**/*.js | claude "加分页"

# 好的做法：只给相关的
claude "给用户列表加分页，相关文件：
- src/views/user/list.vue（列表页）
- src/api/user.js（API 请求）
- src/components/Pagination.vue（分页组件，已有）

接口返回格式：
{
  code: 200,
  data: {
    list: [...],
    total: 100,
    page: 1,
    size: 20
  }
}"

第四步：AI 实现

让 AI 先说再做

1
2
3
4
5
# 不好的做法：直接让 AI 改代码
claude "修改用户列表页，加上分页"

# 好的做法：先让 AI 说方案
claude "用户列表页要加后端分页，先说说你打算怎么改？确认后再动手"

控制变更范围

1
2
3
4
5
6
# 明确告诉 AI 只改哪些文件
claude "只修改以下文件：
1. src/views/user/list.vue - 添加分页组件和请求逻辑
2. src/api/user.js - 修改 getList 方法添加分页参数

不要修改其他文件"

分步验证

1
2
3
4
5
# 每完成一步就验证
claude "先修改 src/api/user.js 的 getList 方法，添加 page 和 size 参数"

# 验证无误后继续
claude "再修改 src/views/user/list.vue，引入分页组件"

第五步：代码审查

AI 写的代码必须过审，不能盲目信任。

审查清单

功能正确性

  • 代码是否实现了需求？
  • 边界情况是否处理？（空值、空列表、超长输入）
  • 异常情况是否处理？（网络错误、权限不足）

安全性

  • 用户输入是否校验？
  • SQL 注入风险？
  • XSS 风险？
  • 敏感信息是否泄露？

性能

  • 有没有不必要的循环？
  • 有没有重复查询？
  • 大数据量是否分页？

可维护性

  • 命名是否清晰？
  • 逻辑是否易懂？
  • 有没有重复代码？

使用 Claude 辅助审查

1
2
3
4
5
6
7
8
# 审查当前改动
git diff | claude "审查这些改动，重点关注：
1. 安全性：有没有注入风险？
2. 性能：有没有可以优化的地方？
3. 边界情况：空值处理是否完善？"

# 审查特定文件
cat src/api/user.js | claude "审查这个文件的错误处理是否完善"

第六步：测试验证

单元测试

1
2
3
4
5
6
# 让 AI 生成测试
claude "为 src/utils/pagination.js 生成单元测试，覆盖以下场景：
1. 正常分页
2. 页码为 0 或负数
3. 每页条数为 0
4. 总数为 0"

手动测试

1
2
3
4
✅ 正常流程：能分页、能切换页码
✅ 边界情况：第一页点上一页、最后一页点下一页
✅ 异常情况：网络断开、接口报错
✅ 性能：大数据量是否流畅

第七步：提交上线

提交规范

1
2
3
4
5
6
7
8
9
# 小步提交，每个 commit 都是独立可回滚的
git add src/api/user.js
git commit -m "feat(user): 添加用户列表分页参数"

git add src/views/user/list.vue
git commit -m "feat(user): 用户列表添加分页组件"

git add src/components/Pagination.vue src/utils/pagination.js
git commit -m "feat(pagination): 新增分页组件和工具函数"

提交信息格式

1
2
3
4
5
6
7
8
类型(范围): 简短描述

类型：
- feat: 新功能
- fix: 修复 bug
- refactor: 重构
- test: 测试
- docs: 文档

回滚策略

Git 回滚

1
2
3
4
5
6
7
8
9
# 回滚最近一次提交
git reset --hard HEAD~1

# 回滚到指定提交
git reset --hard <commit-hash>

# 回滚已推送的提交（谨慎使用）
git revert <commit-hash>
git push

分支策略

1
2
3
4
5
6
7
8
9
# 功能开发在分支上
git checkout -b feat/user-pagination

# 完成后合并到主分支
git checkout main
git merge feat/user-pagination

# 出问题时回滚合并
git revert -m 1 <merge-commit-hash>

常见问题

AI 改动太大

1
claude "只修改 src/api/user.js 这一个文件，不要动其他文件。如果需要改其他文件，先告诉我，我确认后再改"

AI 理解错了需求

1
2
# 先让 AI 说方案
claude "先描述一下你打算怎么改，包括会修改哪些文件、每个文件改什么。我确认后再动手"

AI 生成的代码有 bug

1
2
# 提供错误信息
cat error.log | claude "这段代码报错了，错误信息如下：xxx。帮我定位问题并修复"

上下文不够

1
2
# 补充上下文
claude "补充一下背景：这个项目的用户表结构是 xxx，之前已经有一个不分页的查询接口"

效率对比

场景纯手写AI 辅助效率提升
写 CRUD2小时30分钟4x
写测试1小时15分钟4x
代码审查30分钟10分钟3x
排查 bug1小时20分钟3x
重构3小时1小时3x

注意：这是建立在正确使用 AI 的前提下。如果上下文管理不好、任务拆分不合理，效率可能反而下降。

小结

  • AI 编程是一个完整的工作流，不是一步到位
  • 上下文管理是关键：只给相关的，不给多余的
  • 大任务拆成小任务，每步都验证
  • AI 写的代码必须过审，不能盲目信任
  • Git 是安全网，小步提交，方便回滚
]]> https://000902.icu/2026/07/02/ai-coding/ai-coding-workflow/ 2026-07-02T16:00:00.000Z AI 编程在真实项目中的完整工作流，包括需求分析、任务拆分、实现、审查和回滚 AI 编程工作流：上下文、任务拆分与代码审查 2026-09-10T13:48:38.086Z Xiazhou Claude Code 使用指南：从配置到实战

Claude Code 是 Anthropic 推出的 CLI 编程工具。它不是简单的代码补全，而是一个能理解整个项目、执行复杂任务的 AI 功手。但要把它用好，你得知道怎么配置、怎么给上下文、怎么拆任务。

这篇文章从实际使用角度，讲 Claude Code 的核心配置和工程实践。

安装与配置

基础安装

1
npm install -g @anthropic-ai/claude-code

项目级配置：CLAUDE.md

CLAUDE.md 是 Claude Code 的项目规则文件，放在项目根目录。它告诉 Claude 这个项目的背景、规范和约束。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 项目规则

## 技术栈
- Vue 3 + TypeScript + Vite
- 后端：Spring Boot + MyBatis-Plus
- 数据库：MySQL 8.0

## 代码规范
- 使用 Composition API，不用 Options API
- 组件命名：PascalCase
- 工具函数放 src/utils/
- API 请求放 src/api/

## 禁止事项
- 不要直接修改 node_modules
- 不要删除测试文件
- 不要改变现有 API 接口格式

CLAUDE.md 的层级结构

1
2
3
4
项目根目录/CLAUDE.md          # 项目级规则
├── src/
│   ├── components/CLAUDE.md  # 组件目录规则
│   └── utils/CLAUDE.md       # 工具函数规则

原则：越具体越好。不要写”遵循最佳实践”，要写”组件用 Composition API + setup 语法糖”。

核心命令

常用命令

命令作用
claude启动交互式会话
claude "问题"直接提问
claude -p "问题"非交互模式，适合脚本
/help查看帮助
/cost查看 Token 消耗
/clear清空上下文

工作流命令

命令作用
/review代码审查
/simplify简化代码
/loop N 命令重复执行 N 次

实用技巧

1
2
3
4
5
6
7
8
9
10
11
# 批量修改文件
claude "把 src/ 下所有 .js 文件中的 var 改成 const"

# 生成测试
claude "为 src/utils/date.js 生成单元测试"

# 代码审查
git diff | claude "审查这些改动，指出潜在问题"

# 解释代码
cat src/complex-function.js | claude "解释这个函数的逻辑"

上下文管理：最关键的技能

Claude Code 的效果很大程度上取决于你怎么给上下文。

原则一：相关性优先

1
2
3
4
5
# 不好的做法：把所有文件都给 Claude
cat src/**/*.js | claude "修改这个函数"

# 好的做法：只给相关的文件
cat src/api/user.js src/utils/request.js | claude "修改用户 API 的请求方式"

原则二：明确目标

1
2
3
4
5
# 不好的做法：模糊的指令
claude "修复这个 bug"

# 好的做法：具体的指令
claude "用户列表页点击分页后，数据没有刷新。问题可能在 src/views/user/list.vue 的 fetchList 方法，或者 src/api/user.js 的 getList 接口"

原则三：提供约束

1
2
3
4
5
6
7
8
# 不好的做法：没有约束
claude "重构这个组件"

# 好的做法：明确约束
claude "重构 src/components/UserTable.vue：
1. 从 Options API 改成 Composition API
2. 不要改变现有的 props 和 events 接口
3. 保持现有的样式不变"

上下文窗口管理

Claude Code 有上下文窗口限制。处理大项目时：

1
2
3
4
5
6
7
8
9
# 1. 分阶段处理
# 第一阶段：理解项目结构
claude "先看一下 src/ 目录结构，告诉我这个项目的架构"

# 第二阶段：定位问题
claude "用户模块的 API 请求在哪个文件？"

# 第三阶段：具体修改
claude "修改 src/api/user.js 中的 getList 方法，添加分页参数"

任务拆分：大任务拆成小步骤

不好的做法

1
claude "给这个项目加上用户认证功能"

这个任务太大，Claude 可能会：

  • 改太多文件
  • 遗漏某些步骤
  • 引入新的 bug

好的做法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 步骤 1：设计
claude "帮我设计用户认证的技术方案，包括：登录接口、Token 存储、路由守卫"

# 步骤 2：实现登录接口
claude "实现登录接口 POST /api/auth/login，返回 JWT Token"

# 步骤 3：Token 管理
claude "实现 Token 的存储和刷新逻辑，放在 src/utils/auth.js"

# 步骤 4：路由守卫
claude "在 src/router/index.js 中添加路由守卫，未登录跳转登录页"

# 步骤 5：测试
claude "为以上功能编写测试用例"

代码审查：AI 写的代码要过审

审查清单

  1. 功能正确性：代码是否实现了需求？
  2. 边界情况：空值、异常、并发是否处理？
  3. 安全性：SQL 注入、XSS、敏感信息泄露？
  4. 性能：有没有不必要的循环、重复查询？
  5. 可维护性：命名是否清晰、逻辑是否易懂？

使用 Claude 辅助审查

1
2
3
4
5
6
7
8
# 审查当前改动
git diff | claude "审查这些改动，重点关注安全性和性能"

# 审查特定文件
cat src/api/user.js | claude "审查这个文件的错误处理是否完善"

# 检查测试覆盖
cat src/utils/date.test.js | claude "检查测试用例是否覆盖了边界情况"

多模型协同

不同任务适合不同的模型：

任务推荐模型原因
写代码Claude Sonnet性价比高，速度快
审查代码Claude Opus推理能力强
排查问题Claude Opus需要深度分析
简单修改本地模型快，不需要联网
1
2
3
4
5
# 在 CLAUDE.md 中配置
## 模型使用建议
- 简单任务用默认模型
- 复杂任务用 claude-sonnet-4-20250514
- 关键代码审查用 claude-opus-4-20250514

回滚策略

AI 改的代码出了问题，怎么回滚？

Git 是你的安全网

1
2
3
4
5
6
7
8
# 改动前先提交
git add -A && git commit -m "保存当前状态"

# 让 Claude 修改
claude "修改 xxx"

# 如果不满意
git reset --hard HEAD~1

小步提交

1
2
3
4
5
# 不要一次性改太多
# 每完成一个功能点就提交
git add src/api/user.js && git commit -m "feat: 添加用户登录接口"
git add src/utils/auth.js && git commit -m "feat: 添加 Token 管理"
git add src/router/index.js && git commit -m "feat: 添加路由守卫"

常见问题

Claude 改动太大怎么办

1
claude "只修改 src/api/user.js 这一个文件，不要动其他文件"

Claude 理解错了需求

1
2
# 先让 Claude 说说它的理解
claude "先描述一下你打算怎么改，我确认后再动手"

Claude 生成的代码有 bug

1
2
# 提供错误信息
cat error.log | claude "这段代码报错了，帮我修复"

小结

  • CLAUDE.md 写清楚项目规则，越具体越好
  • 上下文管理是关键：相关性、明确目标、提供约束
  • 大任务拆成小步骤，每步都验证
  • AI 写的代码必须过审，不要盲目信任
  • Git 是安全网，小步提交，方便回滚

下一篇：AI 编程工作流：上下文、任务拆分与代码审查

]]> https://000902.icu/2026/07/01/ai-coding/claude-code/ 2026-07-01T16:00:00.000Z Claude Code 的核心配置、常用命令、上下文管理和最佳实践 Claude Code 使用指南：从配置到实战 2026-09-10T13:48:38.086Z Xiazhou 2026 年微前端选型指南：wujie、qiankun、micro-app、Module Federation 全面对比

你有没有这种场景：旧系统只维护不改，新系统想用新技术栈独立开发，但用户需要一个统一的入口。

我最近就在做这个事——一个基于 Vue 3 + Element Plus + Avue + Vuex 的老管理后台，决定不再重构，新功能另起炉灶。经过完整的方案调研和 POC，这篇文章把四个主流方案的对比写清楚。

为什么需要微前端（以及你可能不需要）

先诚实说一句：微前端有成本。沙箱隔离、联调部署、数据通信——这些在单体应用里不需要操心的东西，微前端都要管。

什么时候真的需要：

条件说明
多个独立系统需要统一入口用户不用记多个 URL
旧系统不敢动代码太老、太乱、没人敢重构
多团队独立部署每个团队可以自由发版
渐进式技术栈迁移Vue 2 → Vue 3，jQuery → React

什么时候不需要：

  • 小团队（1-3 人）做新项目 → 单体应用更高效
  • 旧系统还在频繁迭代 → 微前端会拖慢迭代速度
  • 性能敏感型应用（编辑器、地图、大屏） → 沙箱有开销

我的场景属于”旧系统只维护 + 新系统独立开发 + 需要统一入口”，正好在微前端的适用区。

四个方案概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
             ┌─────────────┐
             │ 微前端方案   │
             └──────┬──────┘
                    │
    ┌───────────────┼───────────────┐
    │               │               │
┌───┴───┐     ┌────┴────┐     ┌───┴───┐
│ wujie │     │ qiankun │     │micro- │
│(腾讯) │     │ (阿里)   │     │ app   │
└───┬───┘     └────┬────┘     │(京东) │
    │               │          └───┬───┘
    │               │              │
    └───────────────┼──────────────┘
                    │
            ┌───────┴───────┐
            │ Module        │
            │ Federation    │
            │ (构建时方案)   │
            └───────────────┘

详细对比

wujie（无界）— 腾讯

核心原理：iframe 沙箱 + Web Components 容器

1
旧系统原样部署 → wujie 用 iframe 加载 → 通过 Web Components 挂载到主应用 DOM

接入方式：

1
2
3
4
5
6
7
<template>
  <WujieVue
    name="old-app"
    url="//old-app.example.com"
    :props="{ token }"
  />
</template>

关键特征：

维度评价
旧系统改造成本零—不改任何代码，原样部署
CSS 隔离天然隔离（iframe 物理隔离）
JS 沙箱天然隔离（iframe 自洽，无逃逸可能）
性能好—iframe 创建有开销，但 wujie 做了保活和预加载
Vite 子应用支持原生支持，不需要插件
数据通信props + window.$wujie
学习成本低—核心 API 就几个

适合：旧系统完全不动、异构技术栈、需要强隔离的场景。

注意：

  • iframe 的弹窗/全屏跨域问题 wujie 做了处理，但非降级模式下仍有边界情况
  • 英文文档几乎没有

qiankun（乾坤）— 阿里

核心原理：Proxy 沙箱 + HTML 入口加载

1
2
3
4
5
6
7
8
9
10
11
12
import { registerMicroApps, start } from 'qiankun'

registerMicroApps([
  {
    name: 'old-app',
    entry: '//localhost:8080',
    container: '#container',
    activeRule: '/old',
  }
])

start({ sandbox: { experimentalStyleIsolation: true } })

关键特征：

维度评价
旧系统改造成本有—必须改构建配置 + 导出生命周期函数
CSS 隔离experimentalStyleIsolation 有坑，依赖命名约定
JS 沙箱Proxy 沙箱，性能开销比 iframe 大
性能中等—沙箱劫持开销 + 子应用每次切换重建
Vite 子应用支持需要 vite-plugin-qiankun 插件
数据通信initGlobalState
学习成本中等—沙箱配置复杂，踩坑指南要熟读

曾经是微前端的事实标准，但 2023-2024 年后维护节奏明显放缓，核心团队已转向 wujie。 2026 年不推荐新项目使用。

适合：已在用 qiankun 的项目维持现有架构，不建议新接入。

micro-app（京东）

核心原理：Web Components <micro-app> 标签 + 资源劫持

1
2
3
4
5
<micro-app
  name="old-app"
  url="//old-app.example.com"
  baseroute="/old"
></micro-app>

关键特征：

维度评价
旧系统改造成本少，但需要少量配置
CSS 隔离Scoped CSS，边界情况仍存在
JS 沙箱Proxy 沙箱，与 qiankun 类似
使用体验像用原生 HTML 标签一样，体验好
Vite 子应用支持需要插件
学习成本低

注意：

  • 刷新后子应用路由状态有丢失问题
  • 社区比 wujie 小，踩坑参考少

适合：想用 Web Components 方式接入、愿意接受少量改造。

Module Federation（构建时方案）

核心原理：Webpack 5 / Vite 编译时模块共享

1
2
3
4
5
6
7
// webpack 5
new ModuleFederationPlugin({
  name: 'main_app',
  remotes: {
    old_app: 'old_app@//localhost:8080/remoteEntry.js',
  },
})

关键特征：

维度评价
旧系统改造成本必须改构建配置
CSS 隔离无—完全互通
JS 隔离无—完全互通
跨技术栈困难—适合同栈
开发体验好—组件可以直接 import
Vite 支持@module-federation/enhanced（2024 年才稳定）

不是沙箱方案，而是构建时模块共享。适合同技术栈、新建项目的场景。

适合：多个新项目共享组件库/工具库、同栈微前端。

横向对比表

维度wujieqiankunmicro-appModule Federation
维护状态✅ 活跃⚠️ 变慢✅ 活跃✅ 标准能力
旧系统改造零必须改少量必须改
CSS 隔离iframe 物理隔离Scoped（有坑）Scoped无
JS 沙箱iframe 物理隔离Proxy 沙箱Proxy 沙箱无
Vite 子应用原生支持需插件需插件需插件
性能好（保活+预加载）中等中等好（编译时）
同栈体验一般一般一般最好
学习成本低中等低中等
中文文档有有有有
英文文档几乎没有少量几乎没有有

2026 年选型建议

场景一：旧系统零改造接入（最推荐 wujie）

1
2
3
旧系统：jQuery / Vue 2 / PHP / 任意老旧项目
旧系统策略：不改代码
新系统：Vue 3 / React

➡ wujie。唯一真正做到零侵入的方案，旧系统原样部署，新系统 <WujieVue> 加载。

场景二：同技术栈多应用共享组件

1
2
主应用 + 子应用，都是 Vue 3 + Vite
需要共享组件库、工具库、甚至 store

➡ Module Federation。编译时共享，体验最顺，类型安全。

场景三：已有 qiankun 的项目

1
已经在用 qiankun，跑得还行

➡ 继续保持 qiankun。迁移成本高于收益，等下次大改版再考虑切换。

场景四：高安全/金融场景

1
对 JS/CSS 隔离要求极高，不能有任何互相影响

➡ wujie。iframe 提供的是浏览器级别的物理隔离，这是 Proxy 沙箱做不到的。

场景五：小团队新项目

1
1-3 个人，从零开始

➡ 不建议用微前端。单体应用 + 合理的模块划分就够了。

我的选择：wujie

回到开头的场景——旧管理后台不动，新功能用 Vue 3 独立开发。

选了 wujie，理由很简单：

  1. 旧系统一行代码都不用改—原样部署，风险为零
  2. iframe 沙箱最省心—不需要操心 Proxy 劫持的边界情况
  3. 新系统完全自由—Vue 3 + TypeScript + Pinia，想怎么搭都行
  4. 配置极少—核心代码不超过 20 行

架构示意图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌──────────────────────────────────────────┐
│           新系统 Shell                     │
│  ┌────────────────────────────────┐       │
│  │  统一顶部导航栏                   │       │
│  ├──────────┬─────────────────────┤       │
│  │ 统一侧边    │  内容区               │       │
│  │ 栏菜单     │                      │       │
│  │          │  ┌─────────────────┐ │       │
│  │          │  │ wujie 加载旧系统  │ │       │
│  │          │  │ （原样部署）      │ │       │
│  │          │  └─────────────────┘ │       │
│  │          │  ┌─────────────────┐ │       │
│  │          │  │ 新系统原生页面    │ │       │
│  │          │  └─────────────────┘ │       │
│  └──────────┴─────────────────────┘       │
└──────────────────────────────────────────┘

总结

  • 2026 年活着的微前端方案主要四个：wujie、qiankun、micro-app、Module Federation
  • qiankun 不再推荐新项目使用，核心团队已转向 wujie
  • wujie 是零侵入最优解，旧系统不改任何代码就能接入
  • Module Federation 适合同技术栈的新建项目，但没有沙箱隔离
  • 小团队新项目不建议上微前端，单体应用更高效
  • 选方案先问自己：旧系统能改吗？团队几人？需要强隔离吗？

参考资源：

]]> https://000902.icu/2026/06/30/micro-frontend-landscape-2026/ 2026-06-30T16:00:00.000Z 旧系统不敢动，新系统想用 Vue 3——微前端怎么选？本文从实际项目角度对比 wujie、qiankun、micro-app、Module Federation 四个方案，给出 2026 年的选型建议。 2026 年微前端选型指南：wujie、qiankun、micro-app、Module Federation 全面对比 2026-09-10T13:48:38.087Z