即刻App年轻人的同好社区
下载
Barret李靖
169关注11k被关注11夸夸
编程领域优秀贡献者
🧑💻 软件工程师 / 终身学习者 / 俩妞爸
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
在启动一个需要 vibe coding 的项目前，进入目录的第一件事，不是输入一句话需求，而是先给项目“立规矩”，或者说是，编写“LLM 宪法”，让 LLM 做事时有理可依、有据可循。
LLM 会在一个解空间里反复探索，直到达成目标，有约束但又不失开放性的宪法，可以让 LLM 少走弯路，并且在整个项目周期都能记住项目目标。
例如我在一个 vibe learning 的目录下，会给 Claude 提出这样的初始化要求：
"""
本仓库是用来做 vibe learning 的，所有的 MCP、Skills 等尽量安装在本目录下的合适子目录里，控制好结构，避免上下文爆炸。整体设计要尽量克制，不要复杂，目录要清晰、干净。
你需要把主流媒体平台的 CLI 工具尽量接进来，我是要从这里获取大量资讯的。我现在推荐了一个 opencli，其他的你可以自己去互联网找一找，选那些真正有用的工具。抓回来的内容可以考虑存到本地，但一定要克制，不要把一堆垃圾数据搬进来，尽量只留下高质量的信息。
我本身也在做自媒体，会在 微博、即刻和 X 上发内容，所以你需要在这个仓库里沉淀我的风格、规则、偏好，甚至可以主动去分析我各个平台的内容表现。所有要发布的内容，也需要在这里有一个沉淀和演化的过程。
有一类资讯是适合做 daily 或 weekly 学习的，这类内容需要重点处理。你要记录数据源，并设计一个定时拉取策略，把这些高质量内容持续沉淀到本地。本地存储尽量用 MD 格式，同时把关键附件也管理好。
如果涉及脚本处理，技术栈优先用 bun，可以直接跑 typescript。如果要做应用，尽量用 Next 或 Nuxt，保持简单。数据库本地用 sqlite，同时要预留 mysql 的 adapter。能用 CLI 的地方优先用 CLI，不要一上来就用 MCP。同时要定期 review 我的规则文件，看哪些需要合并、归档，做好短期记忆和长期记忆的分层，在使用的时候也要有召回机制。
还有一件事，我每次写的 prompt，你要帮我做定期整理，可以按天输出一份，把里面值得沉淀的表达、模式抽出来，慢慢变成长期资产。整个仓库用 git 管理，所有内容都是可演进、可回溯的。
将以上内容，拆解后，根据 Claude 官网的最佳实践，初始化写入到本仓库的 CLAUDE.md 和 AGENTS.md。
"""
LLM 会在一个解空间里反复探索，直到达成目标，有约束但又不失开放性的宪法，可以让 LLM 少走弯路，并且在整个项目周期都能记住项目目标。
例如我在一个 vibe learning 的目录下，会给 Claude 提出这样的初始化要求：
"""
本仓库是用来做 vibe learning 的，所有的 MCP、Skills 等尽量安装在本目录下的合适子目录里，控制好结构，避免上下文爆炸。整体设计要尽量克制，不要复杂，目录要清晰、干净。
你需要把主流媒体平台的 CLI 工具尽量接进来，我是要从这里获取大量资讯的。我现在推荐了一个 opencli，其他的你可以自己去互联网找一找，选那些真正有用的工具。抓回来的内容可以考虑存到本地，但一定要克制，不要把一堆垃圾数据搬进来，尽量只留下高质量的信息。
我本身也在做自媒体，会在 微博、即刻和 X 上发内容，所以你需要在这个仓库里沉淀我的风格、规则、偏好，甚至可以主动去分析我各个平台的内容表现。所有要发布的内容，也需要在这里有一个沉淀和演化的过程。
有一类资讯是适合做 daily 或 weekly 学习的，这类内容需要重点处理。你要记录数据源，并设计一个定时拉取策略，把这些高质量内容持续沉淀到本地。本地存储尽量用 MD 格式，同时把关键附件也管理好。
如果涉及脚本处理，技术栈优先用 bun，可以直接跑 typescript。如果要做应用，尽量用 Next 或 Nuxt，保持简单。数据库本地用 sqlite，同时要预留 mysql 的 adapter。能用 CLI 的地方优先用 CLI，不要一上来就用 MCP。同时要定期 review 我的规则文件，看哪些需要合并、归档，做好短期记忆和长期记忆的分层，在使用的时候也要有召回机制。
还有一件事，我每次写的 prompt，你要帮我做定期整理，可以按天输出一份，把里面值得沉淀的表达、模式抽出来，慢慢变成长期资产。整个仓库用 git 管理，所有内容都是可演进、可回溯的。
将以上内容，拆解后，根据 Claude 官网的最佳实践，初始化写入到本仓库的 CLAUDE.md 和 AGENTS.md。
"""
22 17
早期做 Coding Agent 都比较喜欢将本地代码库进行向量化，结合 IDE 上下文，提前构建一份“高质量上下文”，再交给大模型去推理。这种方式延续了很久，为了加速响应，甚至会在本地部署一个小模型，用于做 tab-tab 的决策。
Claude Code 出来之后，整个流派就发生了变化，开始倾向于转到 Terminal 编程，cc 的行为特别像人类工程师 debug 的过程：看代码 → grep → 试改 → 跑命令 → 报错 → 再查 → 再改 → 直到跑通。
它对代码仓库的理解是比较片面的，但这并不影响它解决问题。通过最小试错的方式，一边做任务一边理解全貌，这个操作反而更符合直觉。
一个巨石应用在运转的时候发生了错误，我们不需要对巨石应用有全面了解，只需要根据报错特征，修复当前的报错问题就好了。
有个库叫做 CodeGraph，它支持跟 Claude Code 协作，首先将仓库代码进行向量化，然后提供 MCP 给 cc 调用，以替代 cc 的 grep 操作。它的核心目标是节省 token，从数据看，确实可以节省大概 20%+ 的 token，但效果大概率会有折扣。
CodeGraph 这类方案，存在几个比较难搞定的问题：1）代码是活的，图谱很容易过期，而 grep 永远是新的；2）很多时候并非找不到代码，而是改得对不对，得去改、去执行、去验证，CodeGraph 只解决了查找问题；3）一大堆的图谱数据交给 LLM，它能不能正确消化？要知道 LLM 也是不稳定和有幻觉的。
不过度依赖“看得很准”，才开始动手。 一边做，一边修正，一边逼近答案。这就是 Claude Code 的编程哲学。
Claude Code 出来之后，整个流派就发生了变化，开始倾向于转到 Terminal 编程，cc 的行为特别像人类工程师 debug 的过程：看代码 → grep → 试改 → 跑命令 → 报错 → 再查 → 再改 → 直到跑通。
它对代码仓库的理解是比较片面的，但这并不影响它解决问题。通过最小试错的方式，一边做任务一边理解全貌，这个操作反而更符合直觉。
一个巨石应用在运转的时候发生了错误，我们不需要对巨石应用有全面了解，只需要根据报错特征，修复当前的报错问题就好了。
有个库叫做 CodeGraph，它支持跟 Claude Code 协作，首先将仓库代码进行向量化，然后提供 MCP 给 cc 调用，以替代 cc 的 grep 操作。它的核心目标是节省 token，从数据看，确实可以节省大概 20%+ 的 token，但效果大概率会有折扣。
CodeGraph 这类方案，存在几个比较难搞定的问题：1）代码是活的，图谱很容易过期，而 grep 永远是新的；2）很多时候并非找不到代码，而是改得对不对，得去改、去执行、去验证，CodeGraph 只解决了查找问题；3）一大堆的图谱数据交给 LLM，它能不能正确消化？要知道 LLM 也是不稳定和有幻觉的。
不过度依赖“看得很准”，才开始动手。 一边做，一边修正，一边逼近答案。这就是 Claude Code 的编程哲学。
15 14
周末撸的这个小产品，让我找回了五六年前玩自媒体的感觉，😄，一键多发，信息回流。
感触也很深，这个产品，十多轮 AI 对话就搞好了，整个代码实现我几乎没干预。可以这么说，专属于程序员的 AI 编程时代已经过去，人人都可以轻松撸一个软件。
也 review 了软件质量，水平一般吧，距离服务化和规模化还差一百轮对话。
感触也很深，这个产品，十多轮 AI 对话就搞好了，整个代码实现我几乎没干预。可以这么说，专属于程序员的 AI 编程时代已经过去，人人都可以轻松撸一个软件。
也 review 了软件质量，水平一般吧，距离服务化和规模化还差一百轮对话。
17 42
编程，正在变成一件几乎不需要消耗专注力的事情。
你不再需要长时间盯着屏幕推敲实现路径，也不再需要在脑子里反复模拟执行流程。尤其是在从零到一的阶段，做一个只服务自己的小工具，写一个解决当下问题的产品，这种变化最明显。把需求讲清楚，让它生成，跑起来，能用就行。不满意，再来一版。软件从“需要被设计好”，变成“先被生成出来”。
更微妙的变化，是控制权的转移。起初我们在定义问题，后来在修正答案，再后来，开始顺着它的思路往下走。那句“你这个思路继续展开”，说多了之后，人会慢慢放下判断，转而去筛选。经验没有消失，但它的使用方式变了，从提前定调，变成事后挑选。AI 会不断给出路径，它不太在意路径之间是否统一，它更在意能不能把事情做成。
这也是边界开始出现的地方。AI 在从零到一的生成上非常激进，但一旦进入长期维护，它就开始失控。它的目标很直接，把当前问题解决掉，于是会不断引入新的结构、新的依赖、新的路径。局部看都成立，整体却在变形。系统的复杂度没有被消化，只是被一层一层覆盖。时间一长，代码会“写飞”，稳定性和可维护性被悄悄透支。
于是你会看到一个很清晰的分裂。一边是个人工具、一次性产品，被压缩到极致，从想法到可用，只需要很短的时间，软件像内容一样被生产和消费。另一边是复杂系统，依然需要架构、需要约束、需要人去维持边界，AI 还没有能力吞掉这部分复杂度。
软件在加速蒸发。
1. 在从零到一、为自己而生的场景里，它已经变成即时产物，写出来，用掉，替换掉，不再积累历史，不再追求长期形态。软件在这里变得越来越轻，也越来越不值钱。
2. 而真正有重量的部分，留在系统里。留在那些需要长期演化的结构、需要被约束的复杂度、需要被持续看住的边界里。AI 可以不断生成答案，但系统这件事，仍然需要有人盯着它，让它不至于在“不断做成事情”的过程中，悄悄失去形状。
你不再需要长时间盯着屏幕推敲实现路径，也不再需要在脑子里反复模拟执行流程。尤其是在从零到一的阶段，做一个只服务自己的小工具，写一个解决当下问题的产品，这种变化最明显。把需求讲清楚，让它生成，跑起来，能用就行。不满意，再来一版。软件从“需要被设计好”，变成“先被生成出来”。
更微妙的变化，是控制权的转移。起初我们在定义问题，后来在修正答案，再后来，开始顺着它的思路往下走。那句“你这个思路继续展开”，说多了之后，人会慢慢放下判断，转而去筛选。经验没有消失，但它的使用方式变了，从提前定调，变成事后挑选。AI 会不断给出路径，它不太在意路径之间是否统一，它更在意能不能把事情做成。
这也是边界开始出现的地方。AI 在从零到一的生成上非常激进，但一旦进入长期维护，它就开始失控。它的目标很直接，把当前问题解决掉，于是会不断引入新的结构、新的依赖、新的路径。局部看都成立，整体却在变形。系统的复杂度没有被消化，只是被一层一层覆盖。时间一长，代码会“写飞”，稳定性和可维护性被悄悄透支。
于是你会看到一个很清晰的分裂。一边是个人工具、一次性产品，被压缩到极致，从想法到可用，只需要很短的时间，软件像内容一样被生产和消费。另一边是复杂系统，依然需要架构、需要约束、需要人去维持边界，AI 还没有能力吞掉这部分复杂度。
软件在加速蒸发。
1. 在从零到一、为自己而生的场景里，它已经变成即时产物，写出来，用掉，替换掉，不再积累历史，不再追求长期形态。软件在这里变得越来越轻，也越来越不值钱。
2. 而真正有重量的部分，留在系统里。留在那些需要长期演化的结构、需要被约束的复杂度、需要被持续看住的边界里。AI 可以不断生成答案，但系统这件事，仍然需要有人盯着它，让它不至于在“不断做成事情”的过程中，悄悄失去形状。
33 513
去年给家里娃报了个 Scratch 培训班，一年下来学的也差不多了，今天培训班老师打电话过来，说接下来的系列课程是 Python 进阶，现在报名有很大优惠，时不我待。
作为一个写了十多年代码，当下又被 AI 猛烈冲刷的老码农，我思考了大概两分钟，然后，毅然回绝了。
编程这门传统手艺，正在逐渐走向大众化。
培训班的教学核心，一方面是帮助学生了解逻辑，另外一方面是通过场景化实战让学生掌握逻辑，if/then/else/while。这套体系在过去是有效的，因为掌握语法和结构，本身就代表了生产力。
但今天的问题在于，这些内容正在被 AI 快速吞没。只要能把需求用自然语言描述清楚，大模型就可以生成一份可运行的代码，语法熟练度带来的优势正在迅速贬值。
近期观察娃，经常跟豆包视频聊天做家庭作业，跟 ChatGPT 语音聊天画图，当下的 AI 已经让孩子可以跳过大量基础训练，直接拿着最先进的工具去表达和创作了。
我准备把娃学习编程的预算，拿来养虾🦞和给她买 Token，在更多真实的创作场景里，陪着她一起把想法变成作品。
啥时候培训班也开始这么玩了，倒是可以考虑重新让她回炉学一下，😄
作为一个写了十多年代码，当下又被 AI 猛烈冲刷的老码农，我思考了大概两分钟，然后，毅然回绝了。
编程这门传统手艺，正在逐渐走向大众化。
培训班的教学核心，一方面是帮助学生了解逻辑，另外一方面是通过场景化实战让学生掌握逻辑，if/then/else/while。这套体系在过去是有效的，因为掌握语法和结构，本身就代表了生产力。
但今天的问题在于，这些内容正在被 AI 快速吞没。只要能把需求用自然语言描述清楚，大模型就可以生成一份可运行的代码，语法熟练度带来的优势正在迅速贬值。
近期观察娃，经常跟豆包视频聊天做家庭作业，跟 ChatGPT 语音聊天画图，当下的 AI 已经让孩子可以跳过大量基础训练，直接拿着最先进的工具去表达和创作了。
我准备把娃学习编程的预算，拿来养虾🦞和给她买 Token，在更多真实的创作场景里，陪着她一起把想法变成作品。
啥时候培训班也开始这么玩了，倒是可以考虑重新让她回炉学一下，😄
23 52
过去几周，在 AI 实践过程中的一些经验分享😄
方法论
文档编程 ＞ 代码编程
www.weibo.com
AI Coding 正在重构软件开发
www.weibo.com
让 AI 复用经验，把代码写得更好
www.weibo.com
执行方式
让 AI 并发编程
www.weibo.com
并发 2
www.weibo.com
让 AI 学会并发干活
weibo.com
如何让 AI 进入疯狂工作模式
www.weibo.com
让 AI 输出效果提升五倍
weibo.com
工具与实践
给 openclaw 打造更锋利的剑
www.weibo.com
AI 解放双手，如何把工作托管给浏览器
www.weibo.com
效率跃迁
AI 时代的软件开发速度
www.weibo.com
能力重构
AI 时代对程序员的新要求
weibo.com
AI 时代，如何面试候选人
www.weibo.com
行业变化
程序员也会迎来一波下岗潮
www.weibo.com
个体路径
普通人的 AI 成长之路
weibo.com
方法论
文档编程 ＞ 代码编程
www.weibo.com
AI Coding 正在重构软件开发
www.weibo.com
让 AI 复用经验，把代码写得更好
www.weibo.com
执行方式
让 AI 并发编程
www.weibo.com
并发 2
www.weibo.com
让 AI 学会并发干活
weibo.com
如何让 AI 进入疯狂工作模式
www.weibo.com
让 AI 输出效果提升五倍
weibo.com
工具与实践
给 openclaw 打造更锋利的剑
www.weibo.com
AI 解放双手，如何把工作托管给浏览器
www.weibo.com
效率跃迁
AI 时代的软件开发速度
www.weibo.com
能力重构
AI 时代对程序员的新要求
weibo.com
AI 时代，如何面试候选人
www.weibo.com
行业变化
程序员也会迎来一波下岗潮
www.weibo.com
个体路径
普通人的 AI 成长之路
weibo.com
33 315
昨晚睡前给 AI 布置了一个任务，让它帮我做一个社交媒体管理工具，能够一键发布到多平台，也能从多平台中将互动信息收集回来。提示词大概写了一两千字，样式让它直接一比一复刻 Twitter，一觉醒来，完成度非常高，基本能用了😄
自动化登录流程太麻烦了，我让它通过 Chrome devtools MCP 直接读取了我在浏览器上的已有登录态，然后在数据抓取时将 cookies/localstorage 再传递给 playwright，走 headless 完成自动化。
网页元素分析的工作难度也比较高，我让它直接参考开源的 opencli —— gihtub 接近 1w stars，它做到了几乎所有主流媒体网站的信息抓取能力。其实原理也很简单， opencli 先让用户先安装它提供的 Chrome 插件，插件具备 page debugging 能力，原理跟 Chrome devtools MCP 一样，都走的 cdp 协议驱动，它支持对网页的 DOM/Request 做劫持和分析。
样式复刻就更绝了🤣。我让 AI 一边写代码，一边打开 Chrome 去对比当前网页和 Twitter 网页的 DOM 和 style 差异，并且做完之后还得 review 了三次，结果就是，还原效果异常地高！
这个程序，我在五六年前也写过，当时前前后后调了十来天，适配了四个社交媒体，全部是体力活儿，后面也因为媒体网站改版弃坑了。今天有了 AI 之后，睡一觉的功夫，效果就出来了，生产力简直是爆炸啊！💥
自动化登录流程太麻烦了，我让它通过 Chrome devtools MCP 直接读取了我在浏览器上的已有登录态，然后在数据抓取时将 cookies/localstorage 再传递给 playwright，走 headless 完成自动化。
网页元素分析的工作难度也比较高，我让它直接参考开源的 opencli —— gihtub 接近 1w stars，它做到了几乎所有主流媒体网站的信息抓取能力。其实原理也很简单， opencli 先让用户先安装它提供的 Chrome 插件，插件具备 page debugging 能力，原理跟 Chrome devtools MCP 一样，都走的 cdp 协议驱动，它支持对网页的 DOM/Request 做劫持和分析。
样式复刻就更绝了🤣。我让 AI 一边写代码，一边打开 Chrome 去对比当前网页和 Twitter 网页的 DOM 和 style 差异，并且做完之后还得 review 了三次，结果就是，还原效果异常地高！
这个程序，我在五六年前也写过，当时前前后后调了十来天，适配了四个社交媒体，全部是体力活儿，后面也因为媒体网站改版弃坑了。今天有了 AI 之后，睡一觉的功夫，效果就出来了，生产力简直是爆炸啊！💥
35 28
给本地 Claude Code / Codex / Copilot 装上 Chrome MCP，可以很大程度释放双手，它会直连到你当前打开的浏览器，网页各种登录态和浏览器插件依旧都在，也省却了很多环境配置复杂度。
无论是文档写作、表格处理、资料搜索还是网页开发，甚至是游戏开发、后台运营，它都可以长时间跑下去，20～60min，直到将任务完成。
这些任务，凭借着自己的“眼疾手快”和“经验丰富”，需要的时间其实也差不多，但现在可以交给 AI 了，何乐而不为呢？😄，推荐大家都试一试，把自己的工作流跑通。
我验证下来，让 AI 操作浏览器去解决问题，对 Token 的消耗没有想象中那么大。很多人会直觉认为浏览器自动化一定很重，但只要把链路设计清楚，它就是一种可控的观测系统，关键在于如何做任务拆解。举几个例子：
如果你的 AI 不够聪明或者表现不好，就把下面这段话发给它，让它先学习学习。
第一个是样式验证。
很多人第一反应是截图对比，但 Chrome MCP 更稳定的方式是先做结构确认。先拿页面快照，关注 DOM 结构和可访问性树，确认关键节点是否存在、层级是否正确，再用脚本读取计算样式，例如 getComputedStyle 或直接读 class、style 字段。只有在结构和样式都符合预期的情况下，才做一次截图作为最终确认。这样做的好处是把“视觉问题”拆成“结构问题 + 样式问题”，前两步都是低成本、低 token 的判断，截图只是兜底，用的不多。
第二个是模拟用户操作。
这里的核心不是“点按钮”，而是让每一步都有状态反馈。AI 会先确认当前页面和上下文，再去执行 click、fill、键盘输入等操作，但关键在于它不会连续盲点。每一次交互之后，都会用脚本去读状态，比如页面是否跳转、某个节点是否出现、文本是否变化、某个状态位是否被更新。如果没有变化，它会判定这一步“无效”，进而调整策略，比如重新定位元素、等待异步完成，或者回溯上一步。这其实是在浏览器里构建了一个非常轻量的状态机。
第三个是执行流校验。
人做这件事，往往靠感觉，觉得“好像不对劲”。AI 的方式更偏显式约束。你在一开始就定义好几个关键断点，例如页面标题、URL、关键 DOM、某个接口返回值、甚至是某段文本的存在与否。每走一步，它都会去对齐这些断点。如果某一步之后，断点没有满足预期，它就会认为执行流发生偏移，然后触发排查路径，一般是查看控制台日志、网络请求和当前状态快照。通过这三块信息，它可以定位是前端状态没更新、接口失败，还是页面结构发生了变化。
第四个是接口与数据链路验证。
Chrome MCP 并不直接替你发请求，它更像一个旁观者，去观察真实页面发生的请求。AI 会在关键操作之后抓取网络请求列表，定位到目标请求，再分析请求参数和响应结果。如果发现接口返回异常，它可以把这一步和前面的用户操作串起来看，从而判断问题是在输入阶段、交互阶段，还是后端返回阶段。相比直接写接口测试，这种方式更接近真实用户路径。
从上面四个例子就可以看出来，它为啥不怎么耗 Token：先定位上下文，再读取结构和状态，然后执行最小必要操作，最后用多维信号去验证结果。一旦验证失败，就回到观测层重新判断，而不是继续往下硬跑。
大家可以尝试将自己的工作做经验拆解，定义好清晰节点，配置好显式化的验证规则。剩下的，就交给 AI 吧～😄
无论是文档写作、表格处理、资料搜索还是网页开发，甚至是游戏开发、后台运营，它都可以长时间跑下去，20～60min，直到将任务完成。
这些任务，凭借着自己的“眼疾手快”和“经验丰富”，需要的时间其实也差不多，但现在可以交给 AI 了，何乐而不为呢？😄，推荐大家都试一试，把自己的工作流跑通。
我验证下来，让 AI 操作浏览器去解决问题，对 Token 的消耗没有想象中那么大。很多人会直觉认为浏览器自动化一定很重，但只要把链路设计清楚，它就是一种可控的观测系统，关键在于如何做任务拆解。举几个例子：
如果你的 AI 不够聪明或者表现不好，就把下面这段话发给它，让它先学习学习。
第一个是样式验证。
很多人第一反应是截图对比，但 Chrome MCP 更稳定的方式是先做结构确认。先拿页面快照，关注 DOM 结构和可访问性树，确认关键节点是否存在、层级是否正确，再用脚本读取计算样式，例如 getComputedStyle 或直接读 class、style 字段。只有在结构和样式都符合预期的情况下，才做一次截图作为最终确认。这样做的好处是把“视觉问题”拆成“结构问题 + 样式问题”，前两步都是低成本、低 token 的判断，截图只是兜底，用的不多。
第二个是模拟用户操作。
这里的核心不是“点按钮”，而是让每一步都有状态反馈。AI 会先确认当前页面和上下文，再去执行 click、fill、键盘输入等操作，但关键在于它不会连续盲点。每一次交互之后，都会用脚本去读状态，比如页面是否跳转、某个节点是否出现、文本是否变化、某个状态位是否被更新。如果没有变化，它会判定这一步“无效”，进而调整策略，比如重新定位元素、等待异步完成，或者回溯上一步。这其实是在浏览器里构建了一个非常轻量的状态机。
第三个是执行流校验。
人做这件事，往往靠感觉，觉得“好像不对劲”。AI 的方式更偏显式约束。你在一开始就定义好几个关键断点，例如页面标题、URL、关键 DOM、某个接口返回值、甚至是某段文本的存在与否。每走一步，它都会去对齐这些断点。如果某一步之后，断点没有满足预期，它就会认为执行流发生偏移，然后触发排查路径，一般是查看控制台日志、网络请求和当前状态快照。通过这三块信息，它可以定位是前端状态没更新、接口失败，还是页面结构发生了变化。
第四个是接口与数据链路验证。
Chrome MCP 并不直接替你发请求，它更像一个旁观者，去观察真实页面发生的请求。AI 会在关键操作之后抓取网络请求列表，定位到目标请求，再分析请求参数和响应结果。如果发现接口返回异常，它可以把这一步和前面的用户操作串起来看，从而判断问题是在输入阶段、交互阶段，还是后端返回阶段。相比直接写接口测试，这种方式更接近真实用户路径。
从上面四个例子就可以看出来，它为啥不怎么耗 Token：先定位上下文，再读取结构和状态，然后执行最小必要操作，最后用多维信号去验证结果。一旦验证失败，就回到观测层重新判断，而不是继续往下硬跑。
大家可以尝试将自己的工作做经验拆解，定义好清晰节点，配置好显式化的验证规则。剩下的，就交给 AI 吧～😄
14 05