这是什么
把整段需求直接丢给 AI 写代码，跑到一半偏题、中断接不上——这是近期中文开发者社区的高频吐槽。掘金上这篇文章给出一个解法：别追更聪明的模型，而是给 AI 编程套一层"工程外壳"。
作者自研的 Harness Workflow（驾驭式工作流）把开发拆成 12 道固定工序——需求澄清、方案设计、任务拆解、测试计划、方案复核、编码、代码审查、端到端测试（E2E）、人工验收、提交、归档——每道交给一个只做一件事的子代理，主代理统一调度，关键节点留人拍板。中断、换人、换工具，状态都落盘，下次能续上。
框架入口是 CLAUDE.md 文件，只挂流程指针和项目知识库索引；主代理是唯一读它的角色，子代理只通过结构化协议对话——这避免了"上下文通胀"（输入越长模型越抓不住重点）。
行业怎么看
支持者认为，这是 AI 编码从"玩具"走向"生产线"的关键一步。Anthropic 和 OpenAI 推出的 AI 编程代理（Coding Agent，能自主写代码的工具）能力已够用，缺的更可能是一层流程治理——把质量门禁、状态机（决定下一步该做什么的规则表）、人工把关这些软件工程老办法接回来。
反对声音同样清晰。一是这套设计依赖 Claude Code 或 Codex 的子代理能力，迁移成本不低；CLAUDE.md 作为单一入口也意味着项目知识被绑在 Anthropic 生态里。二是对中小项目和独立开发者来说，12 道工序可能过度工程化——一个晚上能写的脚本，硬走流程反而拖慢节奏。三是真正的瓶颈也许仍在模型本身：上下文足够长、推理足够准时，过程治理的边际收益会递减。
对普通人的影响
对企业 IT：采购 AI 编码工具时，要评估"有没有流程层"，而不再只比模型跑分；研发治理将从"代码规范"扩展到"AI 协作规范"。
对个人职场：程序员的比较优势会从"写得快"转向"拆得清"——能把需求拆成可调度阶段的人，比单纯提示词写得好的人更值钱。
对消费市场：短期感知有限，但当这套流程被团队采纳，AI 写的应用会更快上线、bug 更早被门禁拦下——你用的软件可能"更新得更勤、出错更慢"。