modern-web-guidance-src 能直接装吗？

不能把 modern-web-guidance-src 直接装进 Coding Agent。它是 Modern Web Guidance 的内容工程仓库，负责指南内容的编写、校准与评测；如果目标是让 Coding Agent 遵守 Chrome 的现代 Web 指南，应接入官方发布项，也就是 npm 包 modern-web-guidance 和技能仓库 GoogleChrome/modern-web-guidance。

这几个名称容易混淆，用途如下：

只有在团队需要维护自有规则时，才在 -src 仓库中完成 authoring、calibrating 和 evaluating；内容准备好后，仍要通过官方 npm 包和技能仓库交给 Agent，而不是把 -src 当作运行时安装包。

掘金热榜那篇《AI 写的前端代码为什么总像 5 年前的？Chrome 官方出手了》提到的现象混着两类问题。 一类是模型知识或通用提示带来的平台技术滞后：模型可能仍在使用已经不再是项目目标的旧 API、布局和浏览器能力。另一类是生成代码本身的工程债，例如语义结构不足、内联样式过多、逻辑硬编码，以及 SEO 和可访问性缺口。后一类并不意味着浏览器平台“过时”，两者的修复方向也不相同。

接入时不要先让 Agent 全面重写项目。更稳妥的顺序是，先根据项目实际支持的浏览器设定 Baseline 目标，再让 Agent 针对同一个页面分别生成普通建议和带 Modern Web Guidance 规则的版本，然后逐项比较输出。Baseline 是项目愿意支持并验证的能力范围，不是“代码里出现的 API 越新越好”；如果团队还支持旧浏览器，就不能因为指南推荐了新能力便直接替换。

安装环节也不要从二手文章复制一条未经核对的 npx 命令。现有资料里的官方 Codelab 命令片段并不完整，而且具体接入方式可能随 Agent 和版本变化。至少先用下面的 npm 命令核对公开包名及仓库信息，再以官方 Codelabs 和仓库 README 中当前给出的命令为准：

npm view modern-web-guidance name version description repository.url

这条命令只用于确认分发对象，不能代替 Coding Agent 的实际接入步骤。

对于已有项目，先让 Agent 做只读审核，列出建议修改的文件和理由；然后在同一个页面上比较普通建议与指南增强后的结果，确认差异后才开始改代码。改动应按文件或小功能拆开提交，不要让 Agent 一次性重写整个前端，否则即使代码更“现代”，也很难定位行为回归。

修改完成后，仍然要跑项目原有的 lint、test 和 build。脚本名称各项目不同，可以先列出当前 npm scripts，再执行仓库实际定义的任务：

npm run
npm run lint
npm test
npm run build

这些脚本不是每个项目都有，某个脚本不存在时，应使用项目自己的检查命令。构建通过也不能代替浏览器验证，还需要在项目选定的目标浏览器中检查关键交互、布局和错误状态。如果项目还有 HTML 或 a11y 债务，可以辅以 html-validate 和 axe-cli 扫描，但它们是通用检查工具，不能替代 Modern Web Guidance 的规则审查。

新项目可以在脚手架阶段就附加选定的指南约束；团队则可以固定提示词和审查要求，将它们纳入代码评审或 CI。Modern Web Guidance 提供的是现代 Web 规则与审查提示，不会替团队决定业务架构、依赖、安全、部署和可观测性；“现代”最终要以项目自己选定的 Baseline 为准。