1. 从「写完就交卷」到「自己翻答案」Codex 自验证到底解决了什么Codex 最近放出的两个更新里浏览器开发者模式基于 Chrome DevTools Protocol简称 CDP是最容易被划走、但实际影响最深远的一个。简单说它让 Codex 在生成代码之后能主动读取浏览器的 console 报错、网络请求状态码、DOM 结构和未捕获异常而不是像以前那样写完就把代码丢给你剩下的调试全靠你自己跑、自己看、自己贴回去。适合谁适合所有在前端调试循环里反复当「人肉传话筒」的开发者——你写 fetch、调接口、改样式报错了截图粘给 AI它再猜一轮这个来回本身就是最耗时间的部分。我先把老流程拆开讲清楚你才知道新流程省掉了什么。以前你让 Codex 修一个登录后白屏的 bug它的动作是读代码 → 推测可能是 token 没带上 → 改一版 → 交给你。你本地跑起来F12 打开 DevTools发现某个请求返回 401把这条错误信息复制出来再发回给 Codex它才知道「哦是 Authorization header 缺失」。这一轮里Codex 看不见运行结果你是它和浏览器之间唯一的通道。CDP 开发者模式把这个通道去掉了。Codex 现在能直接通过 CDP 协议连到浏览器实例读取 console 输出、Network 面板的请求与响应、当前 DOM 快照以及运行时抛出的异常。它写完代码后可以自己「翻一下答案」请求挂没挂、状态码是多少、按钮在不在 DOM 里、样式有没有被别的选择器覆盖。这个能力单独看是「加了个工具」但放到工作流里它把 AI 从「生成」这一截推进到了「生成 验证」的闭环。这里有个关键点值得说透写代码和验证代码是两件事。生成那几行代码往往是最快的真正吃时间的是「跑起来看效果 → 定位根因 → 修了再跑 → 再验」这个循环。一个只覆盖生成的助手等于帮你做了流程里最轻松的部分把最耗精力的调试留给你。CDP 这一步是 Codex 开始接验证这个盘。口子一开它的价值主张就从「帮你写代码」变成「帮你写还帮你看结果对不对」。那这跟 TaoToken 有什么关系关系在于你要复现这套自验证流程得先有一个稳定的模型调用通道把 Codex 或兼容的编码 Agent 接上再让它去连 CDP。TaoToken 在这里扮演的就是统一 Key / API 通道的角色——一个 Key 打通模型对话、编码 Agent、控制台管理省掉你在多个平台之间来回切配置的麻烦。下面我按「前置准备 → 可复制配置 → 本地验证 → 排障」的顺序把整套骨架给你搭出来。2. TaoToken 前置统一 Key 与 API 通道准备在动手配 CDP 之前先把模型调用这条链路理顺。TaoToken 的定位是统一接入层你注册后拿到一个 API Key就能通过统一的 API 地址调用模型不用为每个工具单独维护一套凭证。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 这个地址不加 UTM 参数配置里直接写它。你需要准备的东西不多一个 TaoToken 账号、一个 API Key、本地装好的 Node.js建议 18 以上和 Chrome。API Key 在控制台的 API Keys 页面生成地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。生成后先复制存好后面配置里要用。注意API Key 属于敏感凭证不要写进会提交到 Git 的配置文件里。建议用环境变量注入或者放在本地.env并加进.gitignore。如果你还没决定用哪种接入方式可以先想清楚场景只是想让模型对话验证一下思路用模型对话页就够要长期跑编码任务、挂 Agent 流水线那更适合 Coding Plan。这两个入口后面 CTA 部分我会分别给。现在先把 Key 拿到手我们进入配置环节。配置分两块一块是给编码 Agent 用的settings.json以 Claude Code 风格的配置为骨架一块是给 Codex 类工具用的config.toml。两块都指向同一个 TaoToken API 基址这样你无论用哪个前端底层通道是一致的。3. 可复制配置骨架settings.json 与 config.toml先看settings.json。这个文件通常放在你的用户配置目录下比如~/.claude/settings.json或项目根目录的.claude/settings.json。核心是把 API 基址和 Key 通过环境变量注入让 Agent 走 TaoToken 通道。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-your-taotoken-key-here, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Bash(npm run *), Bash(node *), Read, Write, Edit ] } }这里几个字段解释一下。ANTHROPIC_BASE_URL指向 TaoToken 的 API 基址注意结尾不要多加斜杠SDK 会自己拼路径。ANTHROPIC_AUTH_TOKEN填你刚才生成的 Key。ANTHROPIC_MODEL按你实际要用的模型名填不同模型名对应不同能力档位杂活可以用便宜档重活再切。permissions.allow是给 Agent 的操作白名单我建议至少放开Bash(npm run *)和Bash(node *)因为自验证流程里 Agent 需要自己跑构建、跑脚本、起本地服务。再看config.toml这是给 Codex 类工具用的骨架一般放在~/.codex/config.tomlmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [features] browser_devtools true cdp_endpoint http://127.0.0.1:9222base_url同样指向 TaoToken API 基址。env_key指定从哪个环境变量读 Key所以你要在 shell 里导出export TAOTOKEN_API_KEYsk-your-taotoken-key-here[features]这一段是自验证的关键。browser_devtools true打开浏览器开发者模式cdp_endpoint指向你本地 Chrome 的调试端口。注意这个端口不是随便写的需要你用调试模式启动 Chrome 才会监听。启动带 CDP 的 Chrome命令如下macOS 示例Windows 把路径换成chrome.exe的绝对路径/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --remote-debugging-port9222 \ --user-data-dir/tmp/chrome-cdp-profile--remote-debugging-port9222就是让 Chrome 监听 CDP 端口--user-data-dir指定一个独立配置目录避免和你日常用的 Chrome 冲突。启动后访问http://127.0.0.1:9222/json/version能看到返回的 JSON 就说明 CDP 通道通了。提示如果你日常 Chrome 已经开着直接加参数启动可能不生效因为端口被占用或复用已有实例。用独立的--user-data-dir是最稳的做法。两块配置都指向同一个 TaoToken 通道这样你的模型调用和浏览器验证是在同一条链路上跑的。配置写完下一步就是实际发一次请求看它能不能真的读到浏览器状态。4. 本地验证让 Agent 自己读一次 console 报错配置就绪后我们来复现一次完整的自验证动作。目标很具体起一个会报错的本地页面让 Agent 通过 CDP 读到 console 里的错误并定位到出问题的代码行。第一步写一个故意报错的 HTML!DOCTYPE html html headtitleCDP 验证测试/title/head body h1自验证测试页/h1 button idloginBtn登录/button script document.getElementById(loginBtn).addEventListener(click, async () { const res await fetch(https://httpbin.org/status/401); const data await res.json(); console.log(登录结果, data); }); /script /body /html这个页面点按钮会发一个返回 401 的请求然后尝试解析 JSONconsole 里会出现报错。把它保存为test.html用前面带 CDP 的 Chrome 打开或者用npx serve起个本地服务再访问。第二步在 Codex 里发一条指令让它自己去读浏览器状态打开 http://127.0.0.1:9222 对应的浏览器标签页 点击 #loginBtn然后读取 console 输出和 Network 面板里最近的请求 告诉我哪个请求失败了、状态码是多少、失败原因是什么。如果 CDP 通道配好了Agent 会通过 CDP 协议连上浏览器执行点击、抓取 console 和网络记录然后返回类似这样的结果检测到 1 个失败请求 - URL: https://httpbin.org/status/401 - 状态码: 401 Unauthorized - 触发位置: test.html 第 9 行 fetch 调用 - console 报错: SyntaxError: Unexpected token U, Unauthorized is not valid JSON 根因请求返回 401响应体不是 JSONres.json() 解析失败。 建议在 fetch 后先判断 res.ok非 2xx 时走错误分支。这一步跑通说明你的自验证链路是活的Agent 不再需要你截图、粘报错它自己就能看到运行结果。你可以再让它直接改代码把 test.html 里的 fetch 改成先判断 res.ok 非 2xx 时在 console 打印状态码并 return不要直接解析 JSON。改完后让它重新加载页面、再点一次按钮、再读一次 console确认报错消失。这就是「写 → 跑 → 看 → 改 → 再跑」的完整闭环。整个过程你只发了两条指令中间没有手动开 DevTools、没有复制粘贴报错。实测下来这套流程对前端调试的提速是实打实的尤其是那种「代码逻辑看着没问题但跑起来就是不对」的场景。Agent 能直接看到 401、看到 DOM 里按钮被覆盖、看到未捕获异常定位速度比纯靠代码推测快一个量级。5. 本篇常见错排查配置和验证过程中最容易卡住的几个点我列出来对照排查。CDP 端口连不上。现象是 Agent 报connect ECONNREFUSED 127.0.0.1:9222。原因通常是 Chrome 没带--remote-debugging-port启动或者你日常的 Chrome 实例已经占用了默认配置目录新参数没生效。解决完全退出 Chrome用独立的--user-data-dir重新启动再访问http://127.0.0.1:9222/json/version确认返回 JSON。API 返回 401 或 403。现象是模型调用直接失败。先检查ANTHROPIC_AUTH_TOKEN或TAOTOKEN_API_KEY有没有正确导出echo $TAOTOKEN_API_KEY看是不是空。再确认base_url写的是https://taotoken.net/api没有多余斜杠或拼错。Key 失效的话去控制台重新生成一个。模型名不匹配。现象是报model not found。config.toml里的model和settings.json里的ANTHROPIC_MODEL要填你账号实际可用的模型名别照抄示例里的名字。不确定的话先用模型对话页发一条消息看它默认走的是哪个模型。Agent 读不到 DOM 或 console。现象是 CDP 连上了但返回空。检查你让它操作的标签页是不是当前活跃页CDP 默认连的是第一个标签。多标签场景下指令里最好明确 URL 或页面标题让它定位到正确的 target。权限被拦。现象是 Agent 想跑npm run dev但被拒绝。检查settings.json的permissions.allow有没有放开对应命令。自验证流程需要 Agent 能起服务、跑脚本白名单太窄会卡住。注意CDP 调试端口只监听本地回环地址不要把它暴露到公网。--remote-debugging-port配合--user-data-dir在本地用没问题但别在服务器上开这个端口对外。排查完这几类基本能覆盖 90% 的配置问题。剩下的多半是模型侧或网络侧的偶发重试一次或换个时间段再试。6. 把通道和验证串起来下一步怎么走整套流程跑通后你手里其实有了两样东西一条统一的模型调用通道TaoToken 的 Key API 基址和一套让 Agent 自己验证运行结果的能力CDP 开发者模式。前者解决「用哪个模型、走哪条链路」的问题后者解决「写完代码谁来验」的问题。两个合起来才是完整的自验证闭环。如果你现在卡在配置或接入环节最直接的入口是先把 Key 管起来去 API Keys 页面生成一个再对照接入文档把settings.json和config.toml填好。文档里有各语言的调用示例比对着改最快接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你只是想先验证一下模型通不通、思路对不对不用急着配 Agent直接去模型对话页发一条消息确认 Key 和通道没问题https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算长期跑编码任务、挂 Agent 流水线那 Coding Plan 更合适额度调度和通道稳定性都是按持续使用设计的https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后说个我自己的习惯CDP 验证跑通后我会把「起服务 → 点按钮 → 读 console → 判断报错」这几步固化成一个脚本让 Agent 每次改完前端代码自动跑一遍。这样它不只是「写完自己看一眼」而是「写完自己跑一遍测试再交给我」。这个习惯帮我省掉的正是以前最烦的那段人肉传话时间。
写代码之后 AI 还能自己验证？Codex 这两个更新有点值得聊：TaoToken 统一 Key 接入与 CDP 验证配置骨架
1. 从「写完就交卷」到「自己翻答案」Codex 自验证到底解决了什么Codex 最近放出的两个更新里浏览器开发者模式基于 Chrome DevTools Protocol简称 CDP是最容易被划走、但实际影响最深远的一个。简单说它让 Codex 在生成代码之后能主动读取浏览器的 console 报错、网络请求状态码、DOM 结构和未捕获异常而不是像以前那样写完就把代码丢给你剩下的调试全靠你自己跑、自己看、自己贴回去。适合谁适合所有在前端调试循环里反复当「人肉传话筒」的开发者——你写 fetch、调接口、改样式报错了截图粘给 AI它再猜一轮这个来回本身就是最耗时间的部分。我先把老流程拆开讲清楚你才知道新流程省掉了什么。以前你让 Codex 修一个登录后白屏的 bug它的动作是读代码 → 推测可能是 token 没带上 → 改一版 → 交给你。你本地跑起来F12 打开 DevTools发现某个请求返回 401把这条错误信息复制出来再发回给 Codex它才知道「哦是 Authorization header 缺失」。这一轮里Codex 看不见运行结果你是它和浏览器之间唯一的通道。CDP 开发者模式把这个通道去掉了。Codex 现在能直接通过 CDP 协议连到浏览器实例读取 console 输出、Network 面板的请求与响应、当前 DOM 快照以及运行时抛出的异常。它写完代码后可以自己「翻一下答案」请求挂没挂、状态码是多少、按钮在不在 DOM 里、样式有没有被别的选择器覆盖。这个能力单独看是「加了个工具」但放到工作流里它把 AI 从「生成」这一截推进到了「生成 验证」的闭环。这里有个关键点值得说透写代码和验证代码是两件事。生成那几行代码往往是最快的真正吃时间的是「跑起来看效果 → 定位根因 → 修了再跑 → 再验」这个循环。一个只覆盖生成的助手等于帮你做了流程里最轻松的部分把最耗精力的调试留给你。CDP 这一步是 Codex 开始接验证这个盘。口子一开它的价值主张就从「帮你写代码」变成「帮你写还帮你看结果对不对」。那这跟 TaoToken 有什么关系关系在于你要复现这套自验证流程得先有一个稳定的模型调用通道把 Codex 或兼容的编码 Agent 接上再让它去连 CDP。TaoToken 在这里扮演的就是统一 Key / API 通道的角色——一个 Key 打通模型对话、编码 Agent、控制台管理省掉你在多个平台之间来回切配置的麻烦。下面我按「前置准备 → 可复制配置 → 本地验证 → 排障」的顺序把整套骨架给你搭出来。2. TaoToken 前置统一 Key 与 API 通道准备在动手配 CDP 之前先把模型调用这条链路理顺。TaoToken 的定位是统一接入层你注册后拿到一个 API Key就能通过统一的 API 地址调用模型不用为每个工具单独维护一套凭证。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 这个地址不加 UTM 参数配置里直接写它。你需要准备的东西不多一个 TaoToken 账号、一个 API Key、本地装好的 Node.js建议 18 以上和 Chrome。API Key 在控制台的 API Keys 页面生成地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。生成后先复制存好后面配置里要用。注意API Key 属于敏感凭证不要写进会提交到 Git 的配置文件里。建议用环境变量注入或者放在本地.env并加进.gitignore。如果你还没决定用哪种接入方式可以先想清楚场景只是想让模型对话验证一下思路用模型对话页就够要长期跑编码任务、挂 Agent 流水线那更适合 Coding Plan。这两个入口后面 CTA 部分我会分别给。现在先把 Key 拿到手我们进入配置环节。配置分两块一块是给编码 Agent 用的settings.json以 Claude Code 风格的配置为骨架一块是给 Codex 类工具用的config.toml。两块都指向同一个 TaoToken API 基址这样你无论用哪个前端底层通道是一致的。3. 可复制配置骨架settings.json 与 config.toml先看settings.json。这个文件通常放在你的用户配置目录下比如~/.claude/settings.json或项目根目录的.claude/settings.json。核心是把 API 基址和 Key 通过环境变量注入让 Agent 走 TaoToken 通道。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-your-taotoken-key-here, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Bash(npm run *), Bash(node *), Read, Write, Edit ] } }这里几个字段解释一下。ANTHROPIC_BASE_URL指向 TaoToken 的 API 基址注意结尾不要多加斜杠SDK 会自己拼路径。ANTHROPIC_AUTH_TOKEN填你刚才生成的 Key。ANTHROPIC_MODEL按你实际要用的模型名填不同模型名对应不同能力档位杂活可以用便宜档重活再切。permissions.allow是给 Agent 的操作白名单我建议至少放开Bash(npm run *)和Bash(node *)因为自验证流程里 Agent 需要自己跑构建、跑脚本、起本地服务。再看config.toml这是给 Codex 类工具用的骨架一般放在~/.codex/config.tomlmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [features] browser_devtools true cdp_endpoint http://127.0.0.1:9222base_url同样指向 TaoToken API 基址。env_key指定从哪个环境变量读 Key所以你要在 shell 里导出export TAOTOKEN_API_KEYsk-your-taotoken-key-here[features]这一段是自验证的关键。browser_devtools true打开浏览器开发者模式cdp_endpoint指向你本地 Chrome 的调试端口。注意这个端口不是随便写的需要你用调试模式启动 Chrome 才会监听。启动带 CDP 的 Chrome命令如下macOS 示例Windows 把路径换成chrome.exe的绝对路径/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --remote-debugging-port9222 \ --user-data-dir/tmp/chrome-cdp-profile--remote-debugging-port9222就是让 Chrome 监听 CDP 端口--user-data-dir指定一个独立配置目录避免和你日常用的 Chrome 冲突。启动后访问http://127.0.0.1:9222/json/version能看到返回的 JSON 就说明 CDP 通道通了。提示如果你日常 Chrome 已经开着直接加参数启动可能不生效因为端口被占用或复用已有实例。用独立的--user-data-dir是最稳的做法。两块配置都指向同一个 TaoToken 通道这样你的模型调用和浏览器验证是在同一条链路上跑的。配置写完下一步就是实际发一次请求看它能不能真的读到浏览器状态。4. 本地验证让 Agent 自己读一次 console 报错配置就绪后我们来复现一次完整的自验证动作。目标很具体起一个会报错的本地页面让 Agent 通过 CDP 读到 console 里的错误并定位到出问题的代码行。第一步写一个故意报错的 HTML!DOCTYPE html html headtitleCDP 验证测试/title/head body h1自验证测试页/h1 button idloginBtn登录/button script document.getElementById(loginBtn).addEventListener(click, async () { const res await fetch(https://httpbin.org/status/401); const data await res.json(); console.log(登录结果, data); }); /script /body /html这个页面点按钮会发一个返回 401 的请求然后尝试解析 JSONconsole 里会出现报错。把它保存为test.html用前面带 CDP 的 Chrome 打开或者用npx serve起个本地服务再访问。第二步在 Codex 里发一条指令让它自己去读浏览器状态打开 http://127.0.0.1:9222 对应的浏览器标签页 点击 #loginBtn然后读取 console 输出和 Network 面板里最近的请求 告诉我哪个请求失败了、状态码是多少、失败原因是什么。如果 CDP 通道配好了Agent 会通过 CDP 协议连上浏览器执行点击、抓取 console 和网络记录然后返回类似这样的结果检测到 1 个失败请求 - URL: https://httpbin.org/status/401 - 状态码: 401 Unauthorized - 触发位置: test.html 第 9 行 fetch 调用 - console 报错: SyntaxError: Unexpected token U, Unauthorized is not valid JSON 根因请求返回 401响应体不是 JSONres.json() 解析失败。 建议在 fetch 后先判断 res.ok非 2xx 时走错误分支。这一步跑通说明你的自验证链路是活的Agent 不再需要你截图、粘报错它自己就能看到运行结果。你可以再让它直接改代码把 test.html 里的 fetch 改成先判断 res.ok 非 2xx 时在 console 打印状态码并 return不要直接解析 JSON。改完后让它重新加载页面、再点一次按钮、再读一次 console确认报错消失。这就是「写 → 跑 → 看 → 改 → 再跑」的完整闭环。整个过程你只发了两条指令中间没有手动开 DevTools、没有复制粘贴报错。实测下来这套流程对前端调试的提速是实打实的尤其是那种「代码逻辑看着没问题但跑起来就是不对」的场景。Agent 能直接看到 401、看到 DOM 里按钮被覆盖、看到未捕获异常定位速度比纯靠代码推测快一个量级。5. 本篇常见错排查配置和验证过程中最容易卡住的几个点我列出来对照排查。CDP 端口连不上。现象是 Agent 报connect ECONNREFUSED 127.0.0.1:9222。原因通常是 Chrome 没带--remote-debugging-port启动或者你日常的 Chrome 实例已经占用了默认配置目录新参数没生效。解决完全退出 Chrome用独立的--user-data-dir重新启动再访问http://127.0.0.1:9222/json/version确认返回 JSON。API 返回 401 或 403。现象是模型调用直接失败。先检查ANTHROPIC_AUTH_TOKEN或TAOTOKEN_API_KEY有没有正确导出echo $TAOTOKEN_API_KEY看是不是空。再确认base_url写的是https://taotoken.net/api没有多余斜杠或拼错。Key 失效的话去控制台重新生成一个。模型名不匹配。现象是报model not found。config.toml里的model和settings.json里的ANTHROPIC_MODEL要填你账号实际可用的模型名别照抄示例里的名字。不确定的话先用模型对话页发一条消息看它默认走的是哪个模型。Agent 读不到 DOM 或 console。现象是 CDP 连上了但返回空。检查你让它操作的标签页是不是当前活跃页CDP 默认连的是第一个标签。多标签场景下指令里最好明确 URL 或页面标题让它定位到正确的 target。权限被拦。现象是 Agent 想跑npm run dev但被拒绝。检查settings.json的permissions.allow有没有放开对应命令。自验证流程需要 Agent 能起服务、跑脚本白名单太窄会卡住。注意CDP 调试端口只监听本地回环地址不要把它暴露到公网。--remote-debugging-port配合--user-data-dir在本地用没问题但别在服务器上开这个端口对外。排查完这几类基本能覆盖 90% 的配置问题。剩下的多半是模型侧或网络侧的偶发重试一次或换个时间段再试。6. 把通道和验证串起来下一步怎么走整套流程跑通后你手里其实有了两样东西一条统一的模型调用通道TaoToken 的 Key API 基址和一套让 Agent 自己验证运行结果的能力CDP 开发者模式。前者解决「用哪个模型、走哪条链路」的问题后者解决「写完代码谁来验」的问题。两个合起来才是完整的自验证闭环。如果你现在卡在配置或接入环节最直接的入口是先把 Key 管起来去 API Keys 页面生成一个再对照接入文档把settings.json和config.toml填好。文档里有各语言的调用示例比对着改最快接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你只是想先验证一下模型通不通、思路对不对不用急着配 Agent直接去模型对话页发一条消息确认 Key 和通道没问题https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算长期跑编码任务、挂 Agent 流水线那 Coding Plan 更合适额度调度和通道稳定性都是按持续使用设计的https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后说个我自己的习惯CDP 验证跑通后我会把「起服务 → 点按钮 → 读 console → 判断报错」这几步固化成一个脚本让 Agent 每次改完前端代码自动跑一遍。这样它不只是「写完自己看一眼」而是「写完自己跑一遍测试再交给我」。这个习惯帮我省掉的正是以前最烦的那段人肉传话时间。
