为什么你的AI助手Demo很爽,实战很废?

先从一个翻车现场说起

你有没有见过这种场面。

模型智商看着 140，写代码的时候神采飞扬，解释架构的时候头头是道，结果真把它丢进仓库里干活，十几分钟后 PR 直接炸了。

其实它不是不会写，而是不会交付。

为什么会这样呢?

因为它没接通 GitHub API，不知道当前分支已经落后 main 很久了；因为它不会看 CI 状态，只顾着往前改；因为它没有稳定的记忆持久化，上一轮刚确认过的约束，下一轮就忘；因为它没有明确的状态机，任务切到第二步时，整个执行上下文已经开始飘；因为它能写代码，但它没有真正接进交付链。

这也是我这几天越来越强烈的一个判断:

AI 编程的下半场，不是谁模型更强，而是谁先把交付链补齐。

模型当然重要，但如果仓库接不进去、issue 接不进去、PR 提不稳、上下文留不住、权限边界一塌糊涂，那模型再强，也很容易停在“Demo 很爽，实战很废”这个尴尬位置。

说难听一点，很多所谓“很强的 AI 编程”，现在还只是一个会写代码的单机版助手。

离真正可交付，差得远。

为什么这个问题现在必须聊

因为行业的热闹点和真正的价值点，已经开始错位了。

表面上大家还在卷:

• • 谁 benchmark 更高
• • 谁更像高级工程师
• • 谁前端页面一把梭更丝滑

可一旦进入真实开发现场，真正决定成败的反而是另外几件事:

这段要点先看图：repo 怎么接、issue / PR / A…、agent 之间怎么 han…、任务状态怎么保存、记忆怎么持久化、权限怎么收。

这些东西不解决，AI 编程就会一直卡在一个很拧巴的位置:

看起来很聪明，真上生产就发虚。

我自己最近一直在整 OpenClaw、Codex、公众号和小红书这套流水线，感受特别明显。单点能力其实不难找，真难的是整合:

• • 信息怎么进来
• • 状态怎么保住
• • 哪一步自动
• • 哪一步审批
• • 哪一步能直接发
• • 哪一步必须卡人

你把这些串起来，它才像一个系统。

不然就是一堆会说话、会跑脚本、会生成内容的模块，摆在那儿挺唬人，跑起来一地鸡毛。我去，这种场面真看多了。

先把问题问透：AI 编程到底什么时候才算“能交付”？

真正该问的，不是“哪个模型更强”。

而是:

AI 编程，到底什么时候才算真正能交付?

这个问题一旦立住，很多看起来热闹的讨论就会自动失焦，真正重要的只剩三件事:

Why：为什么模型越来越强，交付还是不稳

因为过去大家主要在卷单点能力，真正决定落地的工具接入、流程编排、权限治理，还没有补齐。

What：什么叫交付链

不是单次代码生成。

而是从需求、上下文、工具调用、执行轨迹、测试、提交，到权限边界和回放审计的一整套闭环。

How：谁更可能赢

谁先把这套链补齐，谁就更像下一阶段的基础设施。谁还在单纯吹“我模型更聪明”，谁大概率还得在 Demo 区多站一阵子。

交付链到底是什么

我把它压缩成三段。

第一段，接入真实世界

这一步说白了就是工具接入。

别再让 agent 在真空里写代码了。真正有价值的，是让它能接触真实软件开发现场:

这段要点先看图：GitHub 仓库、issue、PR、branch、commit、CI / Actions。

这一步解决的是一个特别基础、但以前老被绕开的问题:

它到底能不能碰真实世界?

碰不到，模型再聪明也只是本地 Demo。

GitHub 官方把 MCP Server 放出来，我非常看重，就是因为这件事终于开始从“工具能力”进入“标准接线能力”了。仓库、issue、PR、Actions 这些东西一旦接顺，agent 才有资格进入真实开发链路。

第二段，把动作串成流程

这一步才是最容易把人骗过去的地方。

很多 AI 编程产品演示时看起来很强，是因为它只展示了一个动作:

• • 写一个函数
• • 改一个 bug
• • 生一个页面

但现实开发从来不是单动作游戏。

真正的链路一般是这样的:

这段要点先看图：读需求、查 issue、看仓库上下文、改代码、提 PR、跑测试。

一到这一步，问题就不是“会不会写”，而是:

• • 有没有状态机
• • 有没有记忆持久化
• • 多个 agent 能不能 handoff
• • 执行轨迹能不能追
• • 中断后能不能恢复

这一步就是交付链最硬的内功。

很多系统不是死在不会生成代码，而是死在没有稳定的 state machine，也没有靠谱的 memory persistence。任务一长，状态就飘；步骤一多，约束就丢；一换 agent，前面确认过的东西又得重来。

这种系统，看起来像 agent，实际上更像一阵风。

这一步解决的是:

它到底能不能把事做完?

OpenAI 这轮把 Responses API、内置工具、Agents SDK 讲得这么重，本质上也不是在炫模型，而是在补这条流程骨架。

第三段，把风险收住

这一段最不性感，但最决定能不能进生产。

因为模型越强，乱动的能力也越强。

你不给它边界，它就不是提效工具，它是在帮你扩大事故半径。

所以真正能进生产的 AI 编程系统，最后都绕不开这些东西:

这一步解决的是:

它到底会不会闯祸?

Claude Code 那篇讲 sandboxing 的工程文章，我建议做 agent 的人都认真看一遍。那篇文章最值钱的地方，不是它证明了模型更聪明，而是它承认了一个现实:

AI 编程不是不能进生产，问题是你有没有能力把它关进笼子里。

这话有点刺，但特别对。

很多人一聊 agent 就兴奋，觉得以后一个人能顶一整个开发组。可真到你自己要部署的时候，你第一批冒出来的问题绝对不是“它会不会写 React”，而是:

• • Linux 权限怎么控
• • 网络出口怎么收
• • 哪些命令能跑
• • 哪些目录不能碰
• • 出问题谁来追

还有运维呢。

真别把“它会写代码”当成故事结尾，那只是开头。

对独立开发者来说，交付链成熟不是压力，是角色升级

这一段我想换个角度讲。

很多人一说独立开发，就默认你得更苦、更累、更能扛。

这当然没错，但还不够爽。

更准确的说法应该是:

交付链一旦成熟，独立开发这件事会从“手工作坊”升级成“自动化工厂”。

以前是什么状态?

你是工人，AI 是个会递扳手的学徒。

它能帮你补几段代码，查几个资料，写点文案，但最后真正把东西交出去，还是你自己一锤一锤敲。

现在如果交付链补齐了，角色会直接变:

你是厂长，AI 是一整条流水线。

它去监听输入、拉上下文、执行步骤、留日志、发通知、交结果。你不是消失了，而是从“亲手干每一步”，变成“设计系统、定义边界、卡关键审批”。

这个变化，对想做独立开发的人来说，诱惑力其实比“模型更强”大多了。

因为它不只是提效，它是在重写你的工作方式。

所以现在真正值得写的，不是模型新闻，而是工程问题

所以我现在越来越不想追那种“某某模型又更新了”的题。

新闻当然有流量。

但新闻最大的问题，就是太容易写成播报。今天 A 家发一个，明天 B 家跟一个，后天 C 家再套个壳，三天过去，标题不一样，骨架差不多。

这类内容写多了，很容易死板，也很容易过时。

可“交付链”这个题不一样。

它不是一条新闻。

它是一个问题。

而好文章，很多时候就是被一个好问题驱动的。

因为真正值得看的，从来不是发布会那一刻有多热闹，而是几周之后，它到底能不能接进真实流程，能不能把结果稳稳交出去。

我现在的判断

接下来半年，AI 编程圈最值得看的，不是“最强模型”排行榜。

我更关心的是:

• • MCP 生态会不会继续标准化
• • agent 的 handoff 和状态管理会不会成熟
• • 记忆持久化会不会变成默认能力
• • sandbox 和权限治理会不会成为标配
• • repo、CI、浏览器、文档这些能力会不会被真正接顺

这些东西一旦成熟，AI 编程的讨论重点会彻底变掉。

大家以后问的就不会只是:

• • 这个模型强不强

而会变成:

这才像工程。

也更像生意。

说到底，真正能拿走预算的，从来不是最会表演的 Demo。

而是那个能把结果稳定交出去的系统。

所以如果这篇文章只留下一句话，我希望是这句:

你的 AI 助手之所以总在 Demo 很爽、实战很废，不是因为它不会写，而是因为它不会交付。

下一篇我准备直接拆一个闭环

下一篇我不准备再写概念了，直接写链路。

我会拆我自己最关心、也最容易让人一眼看懂价值的一条闭环:

我是如何让 AI 自动监听 GitHub Issue，并在 10 分钟内完成：查库 -> 改代码 -> 跑测试 -> 提 PR -> 发飞书通知，同时保证它碰不到生产环境敏感数据的。

这篇如果写透，大家会更直观地看到:

• • 交付链到底怎么搭
• • 哪一层最容易翻车
• • 审批卡点怎么设计
• • 权限边界怎么收
• • 真正可用的 AI 编程系统，到底长什么样

这个题我已经开始拆了，缺的再补补。

参考文章

[1] 原文链接: https://github.com/github/github-mcp-server[2] 原文链接: https://docs.github.com/en/copilot/concepts/coding-agent/mcp-and-coding-agent[3] 原文链接: https://github.blog/changelog/2025-07-02-copilot-coding-agent-now-has-its-own-web-browser/[4] 原文链接: https://openai.com/index/new-tools-for-building-agents/[5] 原文链接: https://openai.github.io/openai-agents-python/sessions/[6] 原文链接: https://modelcontextprotocol.io/introduction[7] 原文链接: https://www.anthropic.com/engineering/claude-code-sandboxing