话说回来，

这两年前端圈有个挺微妙的变化。

一、从传统工程化到 AI 时代的痛点

• 以前我们讨论工程化：monorepo 拆分、组件治理、CI 提速、ESLint 统一、E2E 稳定、设计程序落地、建立调整。
• 现在提到 AI，讨论变成：哪个 Coding Agent 最强；Cursor/Claude Code/Codex CLI 哪个好用；其实，prompt 写法；AI 一次生成整页，前端是否被替代。话说回来，

这两个讨论之间。好像断了一层，按理说，真正经历过复杂业务项目的人都知道：

• AI 写 demo 能够像资深工程师。但在真实项目中往往像新来的实习生。
• AI 不知道哪些组件是团队封装过的。哪些 API 不能直接调，哪些目录是生成代码，哪些样式 token 必须遵循。
• AI 不清楚 Server Component 与 Client Component 的使用规则，也不知道测试选择器为什么不能随手写 nth-child。话说回来，

很多人所以得出“AI 还不够聪明。”其实更准确的是： 我们的前端项目大多只为“人类开发者”设计，没有为“机器协作者”设计。按理说，这倒逼前端工程化重构——不是“AI 写代码，人类点确认”。而是建立一个更清晰、更可验证、更可审计、不依赖口口相传的程序。

二、主要痛点一：知识未显式化

前端项目里有大量知识并不在代码本身。而在：

• 老员工脑子里
• 飞书历史消息里
• 某个过期文档里
• PR 讨论里
• 线上事故复盘里
• "很多人知道" 的团队习惯里

Ai 在真实项目最常见的问题不是“不会 React”，而是“不知道你的项目为什么长成现在这样”。过去工程化解决的是人协作人，现在还要解决人协作机器，这改变了主要目标：

• "让人更容易开发、测试、建立、发布"
• "让机器更容易理解、修改、验证、回滚"

至于痛点梳理。

1. 新人进来不知道哪些目录能改/不能改？
2. AI Agent 进来不知道组件库怎么用？
3. 测试工具无法通过语义找到按钮，而不是靠 DOM 层级？
4. CI 无法判断一次依赖变更是否高风险？
5. 线上出错后 Agent 没有足够上下文定位问题？

如果答案是否定的。那不是 AI 的问题，而是工程程序本身的问题。AI 到来后这些痛点变得更加急迫。其实，

三、主要痛点二：社区争论与实际落地难题

NEXT.js 社区争论如何给 AI coding assistant 提供上下文。有观点认为工具够强就能自动理解 workspace，另一些则强调必须把约定写下来否则记忆会过期。类似争论也出现在 Playwright 社区。 很多人在生成测试时倾向使用 CSS 方法或 nth-child，因为页面本身没有稳定语义。事实是的观点是，Ai 把原本模糊、不稳定的部分放大了如果你不给人清晰边界。人会靠经验补，你不给 Ai 清晰边界，它只能猜。这种猜测可能导致线上事故。

从具体案例来看。

• Ai 生成 `` 时没有意识到它属于 AuthButton，需要权限校验。结果导致安全漏洞，
• Ai 用 `page.locator` 而不是 `getByRole`，导致 UI 更改后测试失效。
• Ai 没有检查 design token 是否存在用硬编码颜色值，引发视觉不一致。话说回来，

四、新框架：AGENTS.md — 明确入口文档。让机器也能读懂上下文

Coding agent 最需要的不仅是启动说明，而是技术边界、推荐/禁止模式、常见任务执行方式和错误排查方法等。建议添加 AGENTS.md 文档，将其视为“项目操作说明书”。示例结构如下这方面，

AGENTS.md 把隐性知识转成显性。让新人、人机协作都能快速定位规则与边界。

至于痛点解决，

新人可以直接阅读 AGENTS.md 知道哪些目录不可改；按理说，CI bot 可以读取一样信息进行门禁检查；Code Review 可依据同一份文件做评估。

五、新框架：组件库文档要写“什么时候用”和“什么时候不用”

a) 当前多数组件库只列出 API props。例如 ButtonProps，其中 type/size/disabled/loading 等属性。只是对 AI Agent 这不足以判断场景匹配度。不过，应补充使用场景与禁用场景，使其成为完整决策表单。至于例如，

该结构让 Ai 能快速判断 “该选哪个组件”。避免错误替换带来的风险，

使用者痛点解读：

团队成员常因缺乏 “何时该用” 指引而频繁修改错误组件，引起回归 bug 和性能下降。通过补充场景教程，可大幅降低此类错误发生率。

六、新框架：测试成为 AI 的反馈回路。而非防御墙

Ai 编写代码可能出现错误，但如果没有可靠反馈机制，就无法修正并防止问题泄漏。话说回来，需要建立一个健壮且语义化的 E2E 测试程序。让 Ai 能得到即时且可操作的信息。

. 优先使用语义化选择器

page.getByRole
page.getByLabel
page.getByTestId

. 用业务意图表达断言
await expect).toBeVisible
await expect).toBeEnabled

. 测试失败信息需可读，可帮助人工或 Ai 快速定位问题。例如的观点是，ts await expect.toBeDisabled

痛点分析这方面。

传统 E2E 经常出现 CSS selector 或 nth-child 引发 flaky 测试，这使 Ai 在修复过程中会误删或降低断言质量，从而导致上线后不可预料的问题。语义化选择器及明确断言可以明显提高稳定性并减少人工干预成本。


七、新框架：MCP — 将上下文从静态转为可调用能力