最近看到得物技术分享的一篇实战复盘标题很长但核心问题其实很简单AI 到底能把编程这件事推进到什么程度它真正的边界又在哪里这不是一个适合空谈的话题。因为过去大家聊 AI Coding往往容易滑向两个极端 一边觉得它已经快把程序员替掉了另一边觉得它不过就是“高级补全”。但真正有价值的答案从来不在口号里而在真实项目里。而这次复盘最有意思的地方在于它不是随便写几个 demo也不是做一个玩具项目而是拿Claude Code在10 天内从 0 到 1 完成一个企业级中后台项目然后把整个过程拆开给你看。数据也很直接10 天开发周期25,546 行净增代码217 条人工指令2,754 次工具调用整体提效 36%看上去很猛但真正值得关注的不是这些数字本身而是数字背后那套方法论。作者最后其实讲明白了一件事AI 编程真正的提效不在于“让 AI 直接写代码”而在于先用规范、规格和上下文把不确定性消灭在执行之前。这篇文章我想换一个更适合公众号阅读的方式和你聊聊它到底讲了什么以及它为什么值得每一个做开发、做产品、做 AI 工具的人认真看一遍。一、AI 编程最容易被误解的地方现在很多人理解 AI Coding还是停留在一个很表层的想象里给它一句需求它吐出一段代码。这种方式当然能用甚至在很多简单场景下还挺爽。改个文案修个样式写个小组件确实很像多了一个二十四小时在线的高级外包。但问题也恰恰出在这里。当需求一复杂链路一变长涉及多个文件、多个模块、多个角色协作时你会很快发现AI 最大的问题不是“不会写”而是不知道你真正想要什么也不知道哪些东西不能乱动。它的执行力很强但它没有天然的业务常识它能快速生成但它并不自动理解团队规范它可以不断尝试但它并不知道你们公司的线上环境到底埋了哪些历史包袱。所以AI Coding 的核心挑战从来都不是“让 AI 写代码”而是如何让 AI 在正确的边界内写代码。这也是这篇文章提出 Spec Coding 的真正背景。二、Spec Coding 到底是什么所谓Spec Coding说白了就是四个字先写规格再写代码。听起来很朴素甚至有点像传统软件工程的“返场演出”但它放在 AI 场景里意义完全不一样。在这套工作流里每个功能变更不是直接开干而是先经过几个阶段proposal为什么做design怎么设计specs具体规格是什么tasks拆成哪些步骤执行也就是说AI 不是一上来就开始敲代码而是先拿到一份“蓝图”。这个蓝图的价值非常大。它不是为了增加流程感也不是为了显得专业而是为了避免 AI 最擅长做的一件危险的事在目标不够清晰的时候自己脑补一个“看起来合理”的答案。很多人用 AI 写代码踩坑本质上都踩在这里。你以为你说清楚了其实你只说了一个模糊目标 你以为 AI 会反问结果它直接开始执行 你以为它是在“理解你”其实它是在“补全你”。而 Spec Coding 的作用就是在 AI 补全之前先把该讲清楚的都讲清楚。这一步决定了后面到底是一路丝滑还是一路返工。三、这次实战项目到底验证了什么文章里做的是一个标准企业级中后台项目包含表格、表单、卡片列表、数据看板等常见模块。整个过程分成四个阶段。1. 设计阶段这一阶段还没开始写业务代码重点是把产品方向、UI 设计稿和 PRD 先做出来。有意思的是AI 在这里并不是只扮演“工程师”而是分别切换成不同角色扮演产品经理先定义需求扮演 UI 设计师生成高保真 HTML 设计稿再生成研发可读的 PRD 文档这其实说明一个非常关键的趋势AI 不是只能接管 coding它其实正在往整个软件生产链条里渗透。从需求定义到设计表达再到研发对齐它都可以参与。当然参与不等于替代但这已经足够说明问题了。2. 项目搭建阶段这一阶段主要做基础设施搭建熟悉技术栈、配置环境、建立项目结构并完成第一个核心列表页面。这里 AI 更像一个高效搭子帮你快速铺好地基。3. 功能开发阶段这是整个项目最核心的阶段。作者明确提到大约80% 的功能代码都是在这个阶段完成的而且这一阶段真正引入了 Spec Coding 工作流。也就是说他们不再是“给 AI 下指令”而是“先和 AI 定义规格再让 AI 按规格执行”。这个变化很关键。因为从这个时刻开始AI 不再只是一个被动响应器而更像一个能够在既定规则中持续推进任务的执行系统。4. 细节打磨与部署阶段最后进入优化、重构、部署和排障。到这里AI 的价值依然很高但它的能力边界也开始逐渐暴露。尤其是在构建失败、环境差异、依赖问题、CI 无法复现这种场景里AI 就不像前期那样“势如破竹”了。这也让整篇文章从“AI 很强”走向了更诚实的一个结论AI 确实能大幅提效但并不是所有工程问题都能靠它独立解决。四、AI 最强的不是创造而是执行确定性我觉得这篇文章里最值钱的一句话不是哪个数据也不是哪个案例而是作者对 AI 的重新定义AI 不是 Copilot而是一个极度服从、无限耐心、但没有内部业务常识的顶级执行者。这个描述非常到位。为什么因为它一下子把 AI Coding 的能力模型讲透了。1. 它极度服从你写给它的规范越清晰它执行得越稳定。但反过来这也是风险所在。AI 不会天然提醒你“这个需求可能有问题”也不会总是质疑“这样设计真的合理吗”。它往往会在你给出的边界内尽可能把事情做完。所以一旦规范含糊、目标模糊它也会非常努力地把一个错误方向执行到底。2. 它无限耐心人类最容易疲劳的地方在 AI 这里几乎都不是问题。重构 34 个任务联调 9 组接口跨会话恢复上下文不断更新任务状态这些工作对人来说极其消耗意志力但 AI 不会烦也不会累。这意味着它非常适合处理那种重复但不能出错复杂但可以拆解冗长但规则明确的任务。3. 它没有业务常识这也是边界所在。它不知道你们公司的线上环境有什么历史遗留 它不知道某个接口虽然文档没变但实际字段已经偷偷调整 它也不知道某个交互看起来合理但放到真实用户场景里会被骂。这些东西不在它的上下文里它就不知道。换句话说AI 强在显性知识弱在隐性系统。五、AI 失效往往不是随机的文章里总结了三种非常典型的失效模式我觉得每个团队都值得对照一下。模式一规范真空当某个领域没有明确规范时AI 会自动补上“合理默认值”。它写出来的东西可能功能没错但风格、结构、目录分层、命名方式很容易慢慢偏离团队标准。这也是为什么很多人刚开始觉得 AI 写得挺快写着写着却发现项目越来越乱。不是 AI 故意乱来而是因为没人提前告诉它“在这里什么叫对”。模式二信息孤岛AI 拿到的是当前会话里的上下文快照它并不能天然看到系统外部状态。所以你会遇到这种情况本地跑得好好的CI 一跑就炸AI 每次分析都看起来对但解决的只是当前暴露出来的那一层问题这类问题的可怕之处在于AI 并不是不聪明而是它缺少决定性信息。模式三目标模糊很多时候用户说的是“优化一下”“改得更好看一点”“这里不太对”这种表述对人类同事来说也许还能边聊边磨但对 AI 来说很可能就变成了一个危险信号。它会自动把模糊目标翻译成具体动作然后开始执行。结果就是你只是想微调它却顺手重构了 你只是想优化体验它却动了核心结构 你本来需要它先问一句它却已经改完了三版。所以很多时候不是 AI 太能干而是我们给得太模糊。六、那场 4 小时排障为什么特别有代表性整篇文章里我觉得最值得反复回味的不是成功案例而是那个失败得很“真实”的排障场景。某一天项目测试环境构建失败。最后他们花了4 小时7 个会话15 次以上方案尝试59 条指令才最终定位问题。这里最精彩的地方在于AI 每次分析都没有错。问题不在分析能力而在于这个问题本身的结构超出了 AI 的可观测范围。比如问题发生在云端本地无法复现每次验证都要提交代码、等待 CI反馈周期很长多个根因层层遮挡修一层才露下一层真正的根因藏在依赖内部源码里没有任何显式文档最终定位出来的原因也很工程化.npmrc的历史副作用误伤了依赖安装Prisma 的下载行为在境外环境里沉默卡死pnpm 的跨平台 lockfile 造成安装结果不一致这类问题其实已经不是单纯的“代码问题”而是环境、依赖、平台、构建链路、历史配置共同作用下的系统问题。而系统问题恰恰是当前 AI 最难独立解决的领域之一。这件事给我的启发很大。它说明AI 不怕复杂AI 怕的是看不全。只要信息足够完整规则足够稳定它能把复杂任务拆得很漂亮 但只要关键状态藏在上下文外面它就会像蒙着眼进迷宫局部推理再强也很难一次性走出去。七、真正让 AI 变稳的不是一句提示词而是一套规范体系文章里专门讲了一个非常重要的部分规范体系。他们把规范分成三层。第一层约束层这一层负责告诉 AI禁止什么必须怎样做比如 TypeScript 规范、命名规范、注释规范、代码风格、页面目录结构、接口生成规范等等。这是“护栏”。第二层示范层这一层负责告诉 AI标准答案长什么样比如 pro-table、pro-form、editable table、drawer 等模板代码。这是“样板房”。第三层视觉层这一层负责告诉 AI页面应该长什么样通过 HTML 设计稿让它理解布局、样式、间距和视觉意图。这是“参考图”。这三层结构看似简单其实非常重要。因为很多团队只做了第一层也就是只告诉 AI 不能做什么却没有给它足够多的“正向参考”。结果就是 AI 虽然没违规但写出来的东西总有种说不出的别扭。作者总结得很准确规范文件只是约束不是能力。AI 知道什么不能做并不代表它天然知道什么是“符合团队风格的最佳实践”。所以你不能只给它红线还要给它样例、给它设计、给它上下文。说得更直白一点别只教 AI 避坑也要教它什么叫“走得漂亮”。八、MCP 工具的意义不只是“接个工具”那么简单文章里还提到两个非常有意思的 MCP 接入场景接口文档直连飞书云文档直读很多人看 MCP容易只把它理解成“给 AI 装插件”但这个理解其实有点浅。MCP 的真正价值在于消除 AI 上下文里的信息断层。为什么前端联调经常返工因为接口文档不在当前上下文里开发者只能手动复制字段、枚举、必填项一旦漏一点AI 生成的接口定义就可能偏掉。为什么需求理解经常断档因为 PRD、设计文档、协作文档散落在飞书里每次都要来回复制粘贴不仅打断思路还容易丢信息。当这些信息源能被 AI 直接读取时很多原本靠人工搬运的上下文就能被自动补齐。这本质上是在做一件事让 AI 看见原本看不见的东西。而一旦看见很多问题就不再是问题。九、开发者不会消失但角色一定会变化这篇文章的结尾没有停在“AI 很厉害”而是落到了一个更现实的问题上开发者接下来最重要的能力会变成什么我觉得作者的判断非常准。未来真正值钱的可能不再只是“你能亲手写出多少代码”而是你能不能把模糊需求定义清楚你能不能设计出稳定的规范和边界你能不能把复杂任务拆成 AI 能可靠执行的步骤你能不能识别哪些问题属于系统问题哪些问题适合交给 AI你能不能把质量控制前移到设计阶段而不是等代码生成完再返工说到底AI 并没有让开发者变得不重要反而让开发者从“执行者”更明显地变成了“系统设计者”。过去一个优秀工程师的价值可能更多体现在写代码的速度和质量上。而接下来一个优秀工程师的价值会越来越体现在能不能为 AI 构建一个高确定性的执行空间。谁更会定义边界谁就更能放大 AI 谁更会设计规则谁就更能稳定提效 谁更懂系统谁就更知道什么时候该信 AI什么时候必须自己下场。十、最后的结论AI 负责冲锋人负责定边界如果要用一句话总结这篇文章我会写成这样AI 编程的本质不是让 AI 替你写代码而是用结构化规范和工作流把不确定性消灭在执行之前。AI 负责在确定性空间里高速执行 人负责维护、扩展和修正那个确定性空间的边界。这可能才是 AI Coding 真正成熟之后的样子。不是一句提示词包打天下也不是程序员一夜失业而是软件开发从“手工执行密集型”慢慢转向“规则设计密集型”。回头看这次 Claude Code 的实战最重要的收获并不是“10 天写了多少行代码”而是它让我们更清楚地看见了AI 哪里真的能提效AI 哪里会稳定失效什么样的工作流能让 AI 更可控开发者未来真正该修炼的能力是什么说得再锋利一点就是以后拉开人与人差距的也许不是谁更会写 Prompt而是谁更会把混乱问题压缩成可执行系统。而在这件事上Spec Coding 不是一个小技巧它更像是一块路标。它提醒我们AI 时代的工程竞争力不只是写代码的手更是定义规则的脑。结语如果你只是把 AI 当成自动补全工具这篇文章会告诉你它远不止于此。如果你已经在用 AI 写代码这篇文章会提醒你真正的瓶颈不在模型而在规范、上下文和工作流。如果你在带团队这篇文章也许更值得看。因为它本质上讨论的不是某个工具而是未来团队研发方式会如何变化。AI 不会自动把软件工程变简单。但它会逼着我们重新思考一件事什么该交给机器执行什么必须由人来定义。也许这才是这次实战最有价值的地方。如果你也在用 Claude Code、Cursor 或其他 AI Coding 工具欢迎聊聊你遇到过的“高光时刻”和“翻车现场”。很多时候真正的经验不在演示视频里而在那些你以为 AI 能搞定结果最后还是你自己顶上去的深夜里。为什么有些 Claude、Codex 模型这么便宜看完你就明白了国区最新充值 ChatGPT Plus 教程2026 最新版