最近看到得物技术分享的一篇实战复盘，标题很长，但核心问题其实很简单：
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 最新版）
