北京
给AI编程助手写一份20步的清单式提示词，几乎成了行业默认动作。第1步挑issue，第2步读代码写方案，第3步等人批准，第4步先写失败测试……一路排到第17步处理机器人评审、更新文档、清理现场。纸面上看，这像一份交给新实习生的标准作业流程，工整得让人安心。
但一进生产环境，它就会稳定地崩成一团乱麻。
清单越长，模型越容易迷路
大语言模型本质上是概率性的下一个词预测器。一份20步的线性清单，等于制造了一场程序状态的组合爆炸。随着对话历史被编译器日志、测试输出和git diff填满，模型的注意力开始退化——清单顶部早已漂到几万个token之外的过去。
更糟的是命令式跳转陷阱。第6步测试失败了怎么办？第9步之后自动评审机器人留了三条评论怎么办？提示词作者只能开始写扭曲的路由规则：如果第9步后机器人有评论，跳到第12.2步；如果需要改代码，回到第5步，但不要从第1步重建分支，然后继续到第8步，但不要新建PR，只做lease推送，再回到第12.4步……
让模型在150轮工具调用中模拟一台带嵌套循环计数器和条件跳转的虚拟机，它做不到。它会忘记自己站在哪，跳过中间的关卡，或者纯粹因为上下文疲劳而幻觉出一个退出条件。
还有一个更日常的灾难：代理开了PR，暂停等CI跑完，你两小时后唤醒它说“CI在widget测试上挂了，评审机器人建议重构”。线性清单代理会重新读到技能文件顶部的“第1步：挑一个issue”，然后开始幻觉，问你要做哪个工单，或者从零开始考古。人类操作员被迫回到微观管理：“不，别挑工单，你在第12步B子步——去修测试然后推送！”
1976年，贝尔实验室已经解过这道题
1976年，斯图尔特·费尔德曼在贝尔实验室解决的正是这个系统问题：依赖追踪与状态协调。他没有写一个命令式shell脚本说“先编译foo.c，再编译bar.c，然后链接成baz”。他意识到命令式构建脚本之所以脆弱，是因为它没能建模现实的结构。
于是有了三个概念：目标，即我们想产出的最终状态产物或已验证条件；前置条件，即构建这个目标之前必须存在、且比目标更新的上游产物；配方，即从前置条件产出目标的具体命令或动作。
make不关心步骤编号，它关心的是依赖关系构成的有向无环图。
费尔德曼留下过一句话：“写软件时的大多数问题，都来自不知道什么依赖什么。”
代理的工作流不是脚本，是一张依赖图
一个自主AI编程代理的工作流，同样不是过程式脚本，而是由物理软件产物和已验证不变量构成的有向无环图。与其写20个脆弱的编号步骤，不如把整个软件工程生命周期表达成一份声明式的Makefile依赖图，放进代理的技能定义里，让每个人工检查点和质量门槛都成为有明确前置条件的目标。
这套目标体系大致长这样：
- ticket-assigned：工单已分配，是整张图的起点
- approved-plan：方案已获人工批准，前置是已调研的工单
- implementation-diff：实现差异，前置是已批准方案和红绿TDD的失败复现
- approved-adversarial-report：对抗性报告通过，要求六支柱评审零阻塞项
- commit与push：各自带一道人工闸门
- ci-quiescent：CI安静且所有机器人意见已分诊
- land：落地，前置是ready-to-land和人工落地批准
关键在于，当机器人发现新问题或编辑弄脏了工作树，前置条件会自动失效，图会把你拉回implementation-diff重新走一遍。不需要谁去写“跳回第5步但别重建分支”这种规则——依赖关系本身就完成了路由。
派一个代理去处理新工单时，顶层目标永远只有一个：make finish。它不需要记住自己在第几步，只需要知道，要完成finish，还差哪些前置条件没被满足。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
