端到端交付2.0：像工业流水线一样的生产和交付需求¶
Ch01.1439 端到端交付2.0：像工业流水线一样的生产和交付需求¶
📊 Level ⭐⭐ | 2.8KB |
entities/端到端交付20像工业流水线一样的生产和交付需求.md
端到端交付2.0：像工业流水线一样的生产和交付需求¶
WeChat-阿里云开发者 | 发布于 2026-07-21 | 评分入库 v×c≥49
核心内容¶
原创 悟壳 2026-07-21 08:30 浙江 阿里妹导读 文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 在聊2.0之前，先看看当前面对的局面。 1.0 端到端体系从25年12月开始建设，是基于Spec + Harness框架的需求生成模式。 整个链路聚焦在了能从需求按规范稳定的生成代码 这个过程在大部分应用沉淀了较充分的规范约束和技能（constitution、rules、skills），但本质上是"人操作Agent执行"——人是主角，在用Qoder、Cursor、CC等工具驱动Agent干活。 到今天，绝大部分需求在已经走Spec驱动的代码生成，但快起来之后问题也集中爆发了。 质量检查跟不上了 - Agent哗哗出代码，一个CR动不动几万行，但没有经过系统性检查，谁也不敢直接上线，最后还是要人逐行review、手动兜底。 信息处理的成本没有降低 - PRD的规范还没指定，Agent不能拿着要素缺失的需求就开始干，人还是得做澄清补全。更关键的是，信息从上游传到下游，每经过一个环节就会衰减——测试要看SRE保障需求，SRE要看研发变更影响，下游的各类要求没有一开始就确定，还是靠人来缝缝补补。 干复杂度高的事就像在抽卡 - 简单聚焦的事情，当下模型能处理得很好；但一旦复杂度升高、需要拆解分段来做就容易走偏。干到一半上下文丢了，模型偶尔还会随机"降智"，本该一步到位的逻辑有时效果很好，有时被拆得七零八落，最终又得靠人来缝缝补补。 Top模型活干得好但太贵太脆 - 之前一直在用Opus和Codex作业，效果确实好，但动不动封号、服务不稳定、价格贵得离。
关键要点¶
相关实体¶
Agent Architecture Agent Orchestration Patterns Harness Engineering Framework Agent Harness Engineering Paradigm