从氛围编程到工程护栏：我的AI编程工作流如何转变
内容提要
文章主张从“氛围编程”转向“工程护栏”，为AI编程建立可执行、可验证、可恢复的流程，核心是管理任务边界、上下文路由、验证循环和失败处理四件事。失败需分类为停止、重试、修补护栏或记录；外部搜索只解决具体工程问题，结论应沉淀为规范或测试。建议先落实三步：写清完成标准与范围、编辑前列出证据与改动面、失败后先补测试或规则。
延伸解读
从单任务到长任务：工作流转变的动因
文章指出，早期的氛围编程适合单任务，但任务变长后会出现上下文膨胀、重试偏离、策略靠猜、难以判断保留哪些改动等问题。因此作者转向工程护栏，用可执行、可验证、可恢复的流程管理AI编程。这提醒读者，当AI任务从短时交互变为长时间运行时，仅靠优化提示词不够，需要建立系统化的工程约束。
四件核心事：边界、路由、验证与失败处理
作者强调管理任务边界、上下文路由、验证循环和失败处理。任务边界需明确完成标准、范围、改动面和验证命令；上下文路由将AGENTS.md作为索引而非百科全书；验证循环按读、搜、改、验、记顺序进行；失败处理则分类为停止、重试、修补护栏或记录。这些做法旨在减少模型猜测，让失败可恢复。
外部搜索的定位：解决具体工程问题
文章认为外部搜索不应追逐宽泛趋势，而应针对具体工程问题，如超时设置、重试策略、主流工具边界等。搜索结论不能直接照搬，需适配当前仓库，并沉淀为规范、规则、测试或脚本，避免重复搜索。这提示读者，外部信息应作为参考框架，最终决策要结合项目实际。
可立即复制的三步实践
作者建议团队先落实三步：为每个中型任务写明完成标准和范围；编辑前让代理列出文件、证据和改动面；失败后先修补测试、规则或脚本再继续。这三步无需平台化投入，却能推动AI编程从“能产出”向“可交付”转变。对于想引入工程护栏的团队，这是低门槛的起点。
Q&A
什么是Harness Engineering？它和早期的Vibe Coding有什么区别？
Harness Engineering是在AI编程中建立工程护栏，让任务可执行、结果可验证、失败可恢复。早期Vibe Coding主要解决入门问题，如描述需求、写AGENTS.md、用测试和审查兜底，但更偏向单任务工程。当任务变长时，会出现上下文膨胀、重试偏离、策略靠猜、难以判断保留哪些改动等问题，因此需要升级到Harness Engineering。
在AI编程工作流中，需要管理哪四件事？
需要管理四件事：1. 任务边界：明确完成标准、范围、改动面和验证命令；2. 上下文路由：将AGENTS.md作为索引，按需打开长上下文；3. 验证循环：按读、搜、改、验、记的顺序进行；4. 失败处理：将失败分类为停止、重试、修补护栏或记录。
AI编程中失败后应该如何处理？
失败后先分类再处理：停止（用户拒绝、权限阻止、副作用风险、反复空转）应中断循环；重试（网络抖动、可修复参数、无副作用读取失败）应小步重试并保留日志；修补（同类错误出现两次）应添加测试、规则、脚本或日志；记录（可能再次发生）应保存触发条件、验证命令和证据入口。
外部搜索在AI编程工作流中应该怎么用？
外部搜索用于解决具体工程问题，如超时设置、是否重试、默认策略拆分、主流工具边界、真实issue中的失败样本等，而不是搜索宽泛趋势。不要直接复制外部答案，应将其作为参考框架，最终决策要适配当前仓库。有用的结论应沉淀到规范、项目规则、测试或脚本中，避免重复搜索。
Autoresearch和Ralph Loop分别适合什么场景？
Autoresearch适合有明确指标的长循环，需先给目标、护栏和验证命令，每轮只允许一个可回滚的改动，防止漂移。Ralph Loop适合持久单负责人执行，先有PRD和测试规范，再让代理运行长任务，更注重保留上下文、判断和验证线索，而不是过早增加代理。两者共同点是先定义轨道再让代理运行。
如果要在团队中落地这套工作流，最先应该做哪三步？
三步：1. 为每个中等任务写清完成标准和范围；2. 在允许编辑前，让代理列出文件、证据和改动面；3. 失败一次后，先修补测试、规则或脚本，再让代理继续。这三步落实后，AI编程会从“能产出”向“可交付”迈进。
