我用 AI 写完一个需求后才发现，最难的不是 prompt，而是验收

一句话看懂：一位开发者在掘金复盘用 Claude Code 写需求的经历，指出 AI 把编码时间压缩到几分钟后，真正的瓶颈从 prompt 转向了验收——METR 的对照实验中，用 AI 的资深开发者实际耗时反而比手写慢 19%，而他们事前预期是快 24%。

2026 年 9 月 11 日，开发者 kyriewen 在掘金发布复盘文章，描述当前前端需求的典型流程：在 Claude Code 里写清需求，组件、样式、请求逻辑会被一次性生成，主流程几分钟即可跑通。但作者发现，提交前的真正阻碍不是生成速度，而是”怎么确认这份代码达到可提交标准”。

文章以”用户列表 + 关键词搜索”为例：AI 生成的组件类型齐全、渲染正常，却在三态（加载、空、错误）、边界值（空关键词、超长输入、竞态）、副作用清理、运行时数据校验、回归范围五个必验项上全部缺失。作者给出的解法是把验收标准直接写进 prompt，并要求 AI 逐条自查、输出改动文件清单。

文中引用的关键数据来自 METR 的对照实验：使用 AI 工具的资深开发者实际完成时间比手动慢 19%，而其主观预期是快 24%，两者相差 43 个百分点。

这篇文章触及了 AI 编程工具落地阶段一个被低估的问题：大模型显著降低了代码”生成”的边际成本，却没有同步降低”确认正确性”的成本。功能路径的完成度最容易制造”已完成”的错觉，而边界条件、竞态、类型与运行时数据脱节、外溢改动这些风险，恰恰是 AI 默认不覆盖的部分。

它同时说明，prompt 工程的重心正在迁移——从措辞优化转向验收标准的显式表达。对 AI 编程工具厂商而言，能否把静态检查、测试生成、diff 范围约束、自查机制内建到产品里，可能比模型本身的代码能力更能决定实际提效幅度。

对使用 Claude Code、Cursor 等工具的开发者，这篇文章给出的 5 项清单可直接复用：三态覆盖、空/超长/快速连续输入、卸载后请求取消、搜索 any 与 as 及非空断言、用 git diff 圈定改动范围并逐行检查共享工具函数和全局配置。

AI 工具推荐

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

更实际的变化是工作方式：把验收标准连同需求一起交给 AI，让它逐条自查并标注结果，可降低返工率，自查输出本身也能区分”能力不足”还是”沟通遗漏”。但作者明确强调，模板不转移责任，最后一道人工抽验仍不可省——验收标准写得再细，也没人能替你判断错误提示用户是否看得懂。

对团队而言，这意味着前端价值的分化点正在从”能不能写出来”转向”能不能把什么算对说清楚、能不能高效确认”。

一是 AI 编程工具是否会内建验收辅助能力，例如自动生成三态 UI、竞态检测、diff 范围约束与请求取消提示。二是 METR 那 43 个百分点的预期偏差是否会在更大样本、更长周期中被验证或修正。三是团队层面是否会把”验收标准模板”沉淀为需求规范，从而改变代码评审与测试分工。

来源：juejin

发表回复取消回复