AI 已经会写代码了,但它还不太会“交付”
孤松AI记 · 工具观察
Loom 这个项目有意思的地方,不是又做了一个 coding agent,而是试图给 Codex、Claude Code、opencode 这些工具外面套一层交付流程:规划、验证、修复、预览、交接,都要留下证据。
近年用 AI 写代码,最容易产生一种错觉:
好像软件开发已经被解决了。
你给它一句需求,它能写页面、补接口、改样式、加测试。几分钟后,一个 demo 跑起来。那一刻确实挺爽。
但真正麻烦的地方,通常从 demo 之后才开始。
需求有没有被完整实现?
中间改过几轮,原始目标还在不在?
测试是真测过,还是 AI 自己觉得差不多?
浏览器预览有没有证据?
会话一压缩、工具一切换,它还能接着干吗?
这些问题,比"AI 会不会写代码"更现实。
最近看到一个开源项目:Loom。
它自己的说法是,给现有 coding agent 做一个 open delivery harness。说白了,它不是替代 Codex、Claude Code、opencode,而是给这些 agent 加一层交付流程。
它支持的方向也很明确:把一次开发任务变成规划、实现、验证、修复、预览、交接这一整套循环。
怎么使用?
你不用换掉手上的工具——在 Codex 里本来你打"写个访客登记系统",现在在前面加个@loom就行(Claude Code、opencode 里是/loom),它就从"随手生成"切换成"结构化交付"。
接管之后,它不再一次性把代码吐给你,而是先规划,再一个个任务往下做。想从上次的状态接着干,一句@loom continue;想让它自查一遍,一句@loom review。
过去我们聊 AI 编程,注意力大多放在模型上:哪个模型代码能力更强,哪个 agent 更会改项目,哪个 IDE 体验更顺。
但真实项目里,模型只是一部分。
长任务真正容易崩的地方,是流程失控。
●比如做到一半就宣布完成。
●比如上下文压缩之后,忘了前面确认过的边界。
●比如修了 A,又把 B 搞坏了。
●比如明明还有失败日志,却给你一个"已完成"的总结。
Loom 想解决的,就是这类问题。
它会把项目上下文、任务契约、测试结果、预览证据、修复记录、交接报告这些东西落到项目本地的.loom/里。
这样下一次继续,不是让 agent 凭感觉猜"我现在该干嘛",而是从已有状态恢复。
也正因如此,它对"做完了没"卡得比较死。验证不是 agent 嘴上说句"测过了",而是真去跑烟雾测试、Playwright 那类检查,把日志和错误摘要留下来,没过就生成修复请求、再验一遍。预览也不是截张图——是用本地 Docker Compose 把项目真跑起来给你看。
这个设计不花哨,但很工程。
因为 AI coding 往下走,拼的可能不是谁更会"一次性生成",而是谁更能把一个需求稳定做完。
AI coding 的下一阶段,不只是让 agent 更聪明,而是让它进入一套可复盘、可验证、可交接的工程流程。
这件事没那么性感。
但如果你真的想把 AI 用到实际项目里,而不是只停在 demo,可能缺的正是这一层。
项目链接 · github.com/valkor-ai/loom
如果这些文字能让你少走一段弯路,或者只是会心一笑,那这棵"孤松"就算扎下根了。我们下一篇见。
孤松AI记
把重复交给 AI,把判断留给自己。
