返回文章

AI 写代码，最缺的不是 Prompt，而是一个能暴露错误的现场

2 分钟阅读时间
AI 编程Harness EngineeringContext EngineeringPrompt Engineering前端工程Coding Agent
Edit

我最近用 AI 改前端代码时，经常有一个感觉：它不是不会写，而是太容易自信地写错。

你让它改一个页面，它很快就能给出一版代码。看 diff 好像没什么问题，变量名正常，组件结构也合理，有时候第一眼跑起来也能看。但真正麻烦的是，另一个页面的样式被影响了，移动端按钮点不到了，或者某个状态要连续点几次才会出错。

这时候你会发现，问题不只是 prompt 没写好。

Prompt 当然重要。你把需求说得越清楚，模型越不容易跑偏。你告诉它不要改业务逻辑、优先复用现有组件、输出前先检查类型错误，它大概率会比你随口一句“帮我优化一下”做得好。

但写代码不是答题。

答题只要给出一个看起来合理的答案。真实开发不一样，它要理解项目、修改文件、跑起来、看到错误、继续修，最后还要确认没有把别的地方弄坏。这里真正难的，不是让 AI 给你一段代码，而是让它知道这段代码在你的项目里到底有没有做对。

所以我现在越来越觉得，AI 编程的下一阶段，不是问得更巧，而是系统搭得更好。

问得更好，只解决了第一层问题

一开始我们都在研究怎么把问题问清楚，后来这个东西被叫作 Prompt Engineering。

这当然有价值。尤其是写代码时，如果 prompt 太模糊，模型就会自动补全很多你没说的东西。你说“优化页面”，它可能改样式；你说“修一下 bug”，它可能顺手重构；你说“加一个功能”，它可能引入一套新依赖。

所以，一个好的 prompt 至少要讲清楚目标、边界和验收标准。比如“只修这个交互问题，不要改接口，不要调整页面结构，改完后说明影响范围”。这比一句宽泛需求靠谱很多。

但 prompt 的边界也很明显。它只能解决“我怎么把任务说清楚”，解决不了“模型是否理解这个项目”。

这就像你让一个新同事修 bug。你把问题描述得再清楚，如果他不知道项目结构，不知道历史包袱，不知道哪些组件被很多页面复用，他还是很容易修出新问题。不是他不会写代码，而是他不知道自己站在哪里。

AI 也是一样。很多时候它写错，不是因为它不聪明，而是因为它没有项目现场感。

它不知道这个组件被谁引用过，不知道这个样式是不是全局影响，不知道这个接口为什么看起来奇怪但不能动，也不知道某段代码其实是为了兼容一个历史 case。它看到的是一段局部代码，于是它就按局部最优来改。

局部看起来没问题，放进系统里就出问题。这是 AI 写代码最常见的坑之一。

只给上下文，也还差一步

所以后来大家开始讲 Context Engineering。简单说，就是不要只给模型一句需求，而要把项目背景、代码结构、接口文档、组件规范、业务规则这些上下文也给它。

这个方向是对的。因为模型缺的很多时候不是语法能力，而是项目知识。

比如一个前端项目里，按钮组件可能有自己的设计规范，弹窗可能有统一的层级管理，接口错误可能有统一兜底，路由跳转可能有埋点要求。如果这些东西模型不知道，它就会写出一段“孤立看没问题，放进项目就不合适”的代码。

但这里也有一个很容易被忽略的问题：你把资料放在那里，不代表模型会在正确的时候去看。

模型最麻烦的地方，有时不是“不知道”，而是“不知道自己不知道”。它会很自信地根据旧经验写出一段代码，看起来很合理，实际却不适合当前项目，或者不适合当前版本。

我看到 Vercel 有个实验，挺能解释这个现象。他们在 Next.js 16 API 相关的 eval 任务里，不是单纯让模型自己想起来去查文档，而是把一份压缩到大约 8KB 的文档索引放进 AGENTS.md，让模型一开始就能看到。结果在这个任务集里，被动注入的 AGENTS.md 方案通过率达到 100%，而让模型主动调用 skill，即使加了明确指令，最高也只有 79%。

这个结果最有意思的地方，不是 AGENTS.md 有什么魔法，而是它减少了一个决策成本。

主动检索有一个前提：模型要先意识到自己该查资料。但真实情况是，它经常意识不到。它会直接用旧知识开写，等你跑起来才发现不对。

所以我更愿意把 AGENTS.md 理解成项目地图，而不是知识仓库。它不需要塞满所有文档，而是应该告诉模型：项目怎么组织，当前技术栈是什么，常用命令怎么跑，遇到接口问题看哪里，遇到组件问题看哪里，哪些目录不要乱改。

地图不替你走路，但能减少你走错路。

真正关键的是反馈现场

再往深一层看，Prompt 和 Context 还是不够。

因为真实工程里，最关键的不是“模型知道什么”，而是“模型能不能发现自己错了”。

一个人修 bug，不可能只靠脑补。他要能启动项目，打开页面，复现问题，看控制台，改代码，再重新验证。如果改完以后还是坏的，他要马上看到新的错误，然后继续往下排。

AI 也是一样。

如果它只能在聊天框里改代码，它其实是在想象页面。它想象这个组件会正常渲染，想象这个状态会正确更新，想象这个样式不会影响别的地方。但前端最怕的就是“应该没问题”。很多线上问题，最开始都是从这句话来的。

所以这里真正关键的不是模型多会写，而是它有没有一个能暴露错误的现场。

这个方向现在有人叫 Harness Engineering。简单说，就是给 AI 搭一个能工作的环境。这个环境里不只有 prompt 和文档，还要有文件系统、命令行、测试、浏览器、日志、截图、权限边界和反馈循环。

Prompt 让 AI 听懂你。
Context 让 AI 理解项目。
Harness 让 AI 进入工程现场。

这个小框架我觉得挺好记，也能解释为什么很多 AI 编程体验一开始很惊艳，后面又让人不放心。因为前两层做到了，第三层没跟上。

模型听懂了你，也看了一些项目资料，但它没有稳定的验证环境。它能生成代码，却不能持续确认自己有没有做对。结果就是：写得很快，但你不敢直接合并。

这就是差距。

前端的问题，很多不在代码里

前端在这件事上尤其典型。

不是说前端一定比后端更难。后端也有分布式一致性、数据库迁移、缓存失效、消息队列、Kubernetes 配置，这些都不简单。但后端很多问题，会比较早地被类型检查、编译、单元测试、集成测试或者日志暴露出来。

前端麻烦在于，很多错误反馈非常晚，而且强依赖真实运行环境。

一个页面在 Chrome 里正常，在 Safari 里可能崩。桌面端看起来没问题，移动端按钮可能点不到。你改了一个 CSS 选择器，以为只影响当前组件，结果因为优先级、继承关系或者全局样式，另一个很远的页面被影响了。

举个很小的例子。你让 AI 调整一个按钮样式，它看到当前页面里用了 .btn，就顺手改了这个类。当前页面确实好了，但这个类可能在订单页、支付页、弹窗确认按钮里也被用了。你不打开这些页面，根本不知道哪里被影响了。模型也不知道，因为它只看到了当前问题。

这就是前端麻烦的地方：很多问题不是写代码时出现，而是运行之后、点击之后、换设备之后、进入某个特殊状态之后才出现。

React 里的旧闭包、异步状态竞态、组件卸载后的状态更新、弹窗 z-index、滚动穿透、移动端视口差异，也都是类似问题。它们不一定会在写代码时立刻暴露，但会在真实使用时冒出来。

所以前端不是只需要“生成代码”，而是特别需要“运行后的反馈”。

模型能不能打开页面？能不能看到控制台错误？能不能读取网络请求？能不能用 Playwright 点一遍核心链路？能不能截图对比？能不能发现自己改了一个样式后影响了别的组件？

这些问题，比“它能不能写出一个组件”更重要。

Anthropic 在做长时间应用开发的 harness 设计时，也不是只让模型生成代码，而是让 evaluator 借助 Playwright 去真实访问页面、点击功能、观察结果，再把反馈给回模型。这个方向我觉得很对。因为前端质量本来就不是只看代码能判断的，它必须被打开、被点击、被观察。

没有反馈，AI 就是在黑屋子里写代码。

有了反馈，它才是在工程现场里工作。

一个好的 AI 前端工作台

如果把这个思路落到前端工程里，我会把一个好的 AI 工作台拆成几层，但不用想得太复杂。

先要有项目地图，比如 AGENTS.md、README、docs/index.md。它们不用写得特别长，但要告诉模型项目结构、常用命令、文档入口和高风险目录。

然后要有事实源，比如接口文档、组件规范、设计系统、路由规则、状态管理约定、错误码说明。这些东西最好放在仓库里，跟代码一起版本化，而不是散落在聊天记录、飞书文档和某个人脑子里。

再往下是执行环境。模型要能启动项目、安装依赖、跑 lint、跑测试、打开浏览器。如果它只能写代码，不能运行代码，它就永远只做了一半。

最后是反馈机制和完成标准。控制台错误、网络请求、截图、测试结果、DOM 结构、CSS 计算结果，都应该能回到模型手里。什么叫做好了，也要尽量说清楚：页面不报错算不算？移动端要不要看？核心链路要不要跑？设计稿要不要对齐？有没有影响其他页面？

如果这些标准不写清楚，模型就会用自己的标准来猜。而模型的标准，往往不是你的产品标准。

这个地方其实不复杂，但有几个点容易踩坑。第一个坑，是把 Harness 理解成“多写一点提示词”。这不够。提示词只是入口，真正有价值的是验证链路。第二个坑，是把上下文堆得太满。模型不是资料仓库，无关信息太多，反而会干扰它判断。

我个人会更建议把 AGENTS.md 写成地图，把详细资料放进结构化文档，把验证流程尽量自动化。这样 AI 每次进来，都不是从零开始猜，而是沿着项目已经铺好的路往前走。

前端工程师的新价值

很多人担心 AI 会替代前端工程师。我觉得它会先替代一种工作方式：只会接需求、切页面、交代码，但不关心工程系统的人。

真正有价值的前端工程师，会越来越像系统设计者。

你不仅要自己会写代码，还要让 AI 能在你的项目里写好代码。你要设计上下文，告诉它什么重要；你要设计约束，告诉它哪里不能乱动；你要设计反馈，让它知道自己错在哪里；你还要设计完成标准，让它知道什么才算真的做好。

这件事听起来不像传统前端，但它其实很前端。

因为前端本来就站在代码、体验、设计、交互和工程之间。以前这些东西主要靠人来协调，以后会越来越多地变成一套可以被 AI 使用的工作台。

所以我现在会越来越少纠结哪一句 prompt 更神，而是更关心项目本身有没有整理好。文档在哪里，命令怎么跑，错误怎么反馈，AI 改完以后怎么知道自己有没有改对。

这些东西以前看起来像工程洁癖，现在可能会变成 AI 编程时代的基础设施。

AI 编程的下一阶段，不是问得更巧，而是系统搭得更好。

只有系统搭好了，AI 才不是在回答问题，而是在完成工作。

参考资料