凌晨四点十七分我手机上弹出三条推送合并请求通过测试覆盖率98.7%构建产物上传完毕。单看结果会以为是有个夜班程序员熬了一整夜。但实际上过去十二个小时我并没有坐在电脑前——我把一个订单服务价格模块的重构任务丢给编码智能体它自己完成了需求解读、代码编写、单测补充、报错修复和变更提交。我早上醒来要做的事情变成了一边喝咖啡一边评审它留下的变更记录顺便确认它有没有跑偏。这个场景放在两年前很难想象。那时候市面上能看到的编程工具最多帮你补全几行代码、生成一个函数模板稍微复杂一点的需求还是得自己动手。而今天AI连续跑12小时已经从实验变成日常。随之而来的是一连串更本质的问题如果代码可以由智能体完成开发者这个身份到底还剩下什么软件工程的节奏、交付方式、团队协作模式还有多少会被继续改写这篇文章不打算写那种宏大叙事就想把我实际观察到的、跑过几十次长任务之后总结出来的经验原原本本拆给你看。1. 从写代码的人到制定规则的人AI连续工作正在重置开发者画像1.1 十二小时连续工作到底是什么概念先别急着想象AI像程序员一样连续工作12小时的画面。真实的运行状态跟人完全不同。人在写代码的时候注意力会波动过几个小时需要休息、喝水、切换任务。Agent没有身体疲劳它的连续工作实际是一个长程自主循环读取任务文件生成一份计划按计划逐个文件修改每改完一部分就跑到临时目录里编译、跑测试遇到报错就把日志塞回模型里再生成修复方案继续验证。这个循环会一直转下去直到所有验收条件都满足或者达到你预设的失败上限。我做过一次内部压力测试。任务是重构一个中型订单服务里的价格计算模块Agent连续运行了11小时47分钟中间重启过三次会话完成了87次代码文件写入提交了16个变更集自动修复了70多个测试失败。它中途发现一个旧接口的字段命名与文档不一致主动改了兼容层并在交接记录里说明了原因。这就是所谓连续工作12小时的真实规模几十次循环迭代、几百次工具调用、几千行代码变更。重要的不是时长而是Agent具备了跨越多个上下文会话持续追踪目标的能力。以前它只能做一步到位的单点任务现在可以做需要多步规划、多次验证、中途修正的工程级任务。这种变化对我们这些一线开发者的冲击比你想象中来得更直接。以前我们把AI当插件现在AI当执行者。你要做的事从自己写变成定清楚什么算完成然后验收它完成的到底对不对。1.2 寒武纪大爆发背后的四个成熟条件很多人以为寒武纪大爆发指的是模型智能一夜之间发生了质的飞跃其实不是。模型能力在过去两年是渐进式的提升真正的爆发发生在应用层——围绕AI编程的工程生态在半年内突然出现了物种级的多样性。这个现象背后不是某个单点突破而是四个基础设施在时间上凑巧同时成熟了。第一个是工具调用协议标准化。早期让模型调外部工具是一件很痛苦的事每个框架的写法都不一样。到后来社区逐渐形成了一套统一思路把编译器、测试执行器、shell、代码搜索这些能力封装成一个个可被模型调用的外部工具模型的输出变成结构化工具调用而非纯文本。这就像给一个只会打字的人配上了鼠标、键盘之外的整套外设。协议统一之后各种智能体框架的接入成本急剧下降。第二个是Agent执行框架成熟。所谓框架就是那个能控制计划-执行-验证-修复循环的外壳。以前想让模型自动修一个编译错误需要你自己写一大堆胶水代码去截取日志、拼prompt、再喂回去。现在框架把循环、重试、会话管理、断点续跑都做好了。你只需要告诉它跑这个任务最多试三次剩下的交给框架。第三个是上下文与记忆工程开始实用化。长上下文窗口只是一个前提真正解决问题的是分层摘要、状态持久化、断点恢复。Agent把关键决策、已完成的步骤、失败记录持续写入外部文件在上下文快耗尽的时候清理现场、开新会话、把摘要重新载入。没有这套机制模型窗口再大跑一整夜也会把自己聊懵。第四个是沙箱评测体系的出现。连续跑12小时如果没有下限约束模型很可能偷偷干出超范围的事。现在常见的做法是在隔离容器里执行全部代码改动配合测试覆盖率门禁、lint检查、安全扫描Agent的产出有了一套客观的准入标准。这套体系越成熟我们越敢把真正的任务交给它跑过夜。这四个条件单独出现都不足以引发爆发但凑在一起之后就像寒武纪的氧气含量、环境温度、食物链结构同时达标物种多样性突然就涌现了。作为从业者我的感受非常直接半年之前要自己拼装好几套开源工具才能搭出一个勉强能跑长任务的Agent半年后就连团队里最保守的老开发也开始讨论要不要让AI先做一版。2. 拆解连续工作的黑盒Agent长程运行的四个支撑机制2.1 闭环任务循环计划-执行-验证-修复如果要把连续工作12小时背后的机制浓缩成一句话我会说它是一个带反馈的闭环系统而不是一段超长的对话。理解这一点你就理解了大半。可以用一个简化的伪代码来表示核心循环while not task.is_complete() and attempts max_attempts: plan agent.make_plan(task.spec, current_state) for step in plan: code agent.write_code(step) result test_runner.run(code) if result.has_failures(): agent.fix(result.logs) if agent.stuck_on_same_error(logs): agent.record_and_stop(重复失败需要人工介入) break else: agent.commit_and_record(step) agent.verify_acceptance_criteria()拆开看每个环节都缺一不可计划模块负责把一个大目标拆成小步骤。编码模块负责生成实现。验证模块通过真实运行测试来检查结果。修复模块读取失败的报错日志定位失败点并调整代码。最后的verify则把最终产物拿回到需求层面做一次整体校验。这个循环最像的其实是工业里的恒温器设定目标温度实时测量当前温度偏离了就加热或降温再测量直到稳定在目标范围。Agent运行的传感器不是视觉而是编译结果和测试输出它的执行器是代码写入它的目标是你写下的验收标准。我在实践中最看重的是这个闭环有没有彻底的验证环节。如果Agent写完代码不跑测试就拿给你看那不叫连续工作叫连续生成。真正稳定跑过夜的系统每一层都有验证反馈被测试失败卡住的概率反而更低因为它在每次小步迭代里就及时修正了错误而不是攒到最后一起爆。2.2 分层的上下文管理摘要、持久化与断点恢复十二个小时的Agent运行一次模型调用是绝不可能完成的。以主流商用模型动辄几十万到上百万的上下文窗口来看单独一轮对话能承载的内容已经非常惊人但一个12小时任务产生的中间产物、日志、决策历史、失败记录量级远超窗口容量。如果把这些全部塞进同一个上下文模型输出的质量会在几小时后急剧下降——不是模型不够聪明而是它眼前的信息太杂了关键目标反而被淹没。所以实际工程里几乎都用三层处理第一层是分层摘要。每完成一个阶段Agent把当前目标、已完成、未完成、关键决策、使用过的接口签名、遗留风险压缩成一份几百字的结构化摘要。摘要不能太长要只保留能影响下一步决策的内容。第二层是状态持久化。把摘要、待办清单、失败记录、文件状态写入磁盘上的一个状态文件比如agent_state.yaml。这个文件是交班文档——Agent随时可以停下下次新开会话时通过加载这个文件恢复记忆。第三层是断点恢复。一旦上下文占用量达到警告线Agent主动结束当前会话清理出干净窗口把最新的状态文件重新载入然后继续执行。整个过程不需要人工干预。我见过很多初学Agent的人犯一个典型错误让一个任务在同一个会话里连续跑一上午中间不改需求、不换上下文。结果通常是后半个小时模型的输出越来越飘开始重复自己早先的结论或者把旧文件里的过时假设当成最新事实。正确的做法是小步快跑。给Agent设定里程碑比如完成模块A并跑通全部单测就自动开一个全新的会话跟着最新状态文件继续。这样每次模型的视野都是清晰的不会被12小时前某个错误判断污染。2.3 工具调用与外部反馈让编译器当Agent的眼睛一个闭着眼睛写代码的人不管多聪明写出来的东西都只能靠猜。Agent也一样。它如果只能读你自己的描述再从模型内部生成一段看起来合理但没有验证过的代码那本质上是在做预测不是在做工程。长程稳定的Agent有一个关键设计它必须能主动调用外部工具让真实环境里的反馈信号参与决策。编译器的报错、单测的失败堆栈、lint的警告、类型检查器的提示这些对Agent而言就是眼睛和耳朵。它写完代码之后跑一遍编译看到的错误信息成为下一轮修复的依据修完再跑又得到新的反馈。这个生成-执行-读取反馈-再生成的循环就是Agent版本的人类开发者调试过程。工具调用这件事听起来简单实际落地时有个细节很重要反馈信号的格式要干净。原始日志往往成千上万行如果直接把整份日志塞进上下文Agent的注意力会被大量无关信息稀释。我会做一层预处理抓取首个编译错误的文件路径、行号、错误码截取堆栈的前20行如果有测试失败就只保留断言信息。把经过清洗的反馈再给模型相当于帮Agent戴上了一副聚焦眼镜它定位问题的效率会高非常多。我在配置里还会特意告诉Agent不要在拿到任何反馈之前就盲目重写整个文件。没有传感信号就挥拳只会越改越乱。这个约束听起来很基础但实际能减少一大堆无意义改动。2.4 稳跑一夜的前提超时、限额与人工审批我把十二小时的长任务比作让一个远程实习生独立值夜班这个实习生勤奋、诚实、不知疲倦但它也有两个特点一是可能沿着错误的路线陷入死循环二是可能胆子大得超乎你想象改一些你没授权的东西。所以任何一个能连续工作数小时的Agent系统必须在自己身上装几道保险丝。我常用的保险丝参数大致如下参数含义参考值max_attempts整个任务最大尝试次数3~5 轮max_consecutive_failures连续失败多少次后停下来3 次max_run_minutes单次会话最长运行时长120 分钟cost_limit单任务API开销上限按预算评估approval_gate遇到敏感操作是否暂停审批打开checkpoint_interval状态文件保存频率每 15 分钟重点解释几个容易被忽略的连续失败阈值是一条硬底线。Agent不会觉得烦它可以在同一个编译错误上反复尝试二十次每次只改动一个标点然后继续失败。这种执着对人是美德对机器是灾难。所以我设定同一个错误签名出现3次它就必须停下来输出完整诊断报告。审批门禁则是针对胆子太大的保险。涉及数据库结构变更、删除文件、新增依赖、修改对外接口签名这些危险动作Agent必须停止并等待人工确认。夜里跑批时一旦触发审批就会一直挂在那早上起来你看到的是一个清晰的卡点说明而不是一堆已经执行完的破坏性操作。很多教程会告诉你Agent多聪明但我要强调的反而是可靠性的价值。12小时连续工作这件事难的不是让模型能写出正确的代码而是让整套系统在无人值守的情况下不失控、不把仓库搞得一团糟、不在你醒来之前执行掉所有不该执行的东西。稳定才是长跑的第一位。3. 实操指南把一个编码智能体稳定跑过夜3.1 先写任务说明书再开Agent可验证的验收标准是底线跑了一夜的Agent第二天给你一堆代码结果方向全错——几乎都是因为任务说明书写得太模糊。我自己踩过这个坑。早期我把把价格模块重构一下交给Agent睡醒后它对八成文件动了手加了一个自认为很合理的缓存层顺手改了数据库索引。不能说完全没用但和我脑子里想的目标差了很远。后来我把所有长任务都规范成一份任务说明书结构固定强制自己把什么算完成写清楚。一份合格的说明书最少包含四块任务背景、验收标准、边界范围、负面清单。一份实际用过的模板长这样# 任务重构订单服务价格计算模块 ## 背景 - 现有价格计算逻辑散布在订单服务三个文件中存在重复代码 - 需要新增一个计价策略扩展点支持后续接入供应商活动 ## 验收标准机器可验证 - 所有价格计算逻辑迁移至 src/pricing/ 目录旧目录不再被调用 - 接口返回字段与旧逻辑完全兼容兼容测试通过 - 单元测试覆盖率 90% - 性能回归 5%基准测试对比结果附在 PR 描述中 ## 边界范围 - 不修改数据库表结构 - 不改变对外 API 路径 - 不改变现有折扣优先级 ## 负面清单 - 不允许引入新的重量级第三方依赖 - 不允许删除旧模块的兼容代码保留但标记 Deprecated - 不允许绕过 code review 直接合并验收标准一定要能被机器验证这是整份说明书的灵魂。如果你写保证算法效率高Agent没法验证效率高三个字就变成了它自由发挥的空间。但如果你写性能回归不超过5%在基准测试中对比它就可以跑测试、读数据、调整实现直到满足这个数字。边界范围和负面清单同样重要。它们存在的意义是给Agent划定一个不能越过的栅栏减少它自由探索带来的风险。我经验里最值钱的一条是负面清单写得越具体你第二天早上需要擦的屁股越少。3.2 让Agent先写测试再写实现它需要一条可以企及的终点线人类开发者对先写测试再写实现的争论有很多但放到Agent场景里这个顺序几乎成为必须。为什么因为测试是Agent少有的客观反馈源。如果让Agent直接写实现它只能依据模型内部的知识去猜测业务需求到底长什么样最终代码可能语法正确、也能跑通但逻辑和真实业务场景对不上。反过来如果任务开始前先有一组明确的测试用例Agent的整个执行过程就变成一件目标明确的事让测试从红变绿。它每调一次代码立刻知道离终点近了还是远了。我通常的强制策略是ai-dev test_first \ --spec spec_price_refactor.md \ --test-dir tests/pricing \ --green-threshold 90% \ --repo ~/project/order-service在实践里这套做法有个很直观的效果Agent的自我修复能力会被大幅激活。测试先行的项目中Agent如果中途把某个接口实现错了测试执行器会给它一条明确的失败路径它循着路径修正即可。而如果没有测试它可能对着半成品代码反复琢磨最终拿出来的是一个看起来很对但没有任何证据支撑的结果。玩过TDD的同事应该能理解测试之于Agent就像路边画了线的跑道之于夜跑的人。它告诉你应该在哪一条道上跑也知道什么时候算跑完了。我再补充一点测试不要只写覆盖率高的快乐路径至少要有两三组边界用例比如价格为0、折扣叠加顺序、金额四舍五入到分。边界用例存在的价值是让Agent在处理真实业务约束时发生认知冲突逼它去读需求文档而不是自我发挥。3.3 运行参数配置检查点、失败阈值与里程碑审批任务说明书准备好之后下一步是选择怎么跑。我一般把这种长任务分成三个阶段预热、主跑、验收。预热阶段只给Agent分配总任务量的五分之一设置较短时限观察它是否理解了需求的方向和风格。如果预热阶段就频繁跑偏我不会急着修改prompt而是回到任务说明书里找问题。确认说明书没问题才进入正式的主跑阶段。下面是一组我自己常用的启动命令你可以根据自己的项目调整ai-dev start \ --task spec_price_refactor.md \ --repo ~/project/order-service \ --max-attempts 4 \ --max-consecutive-failures 3 \ --checkpoint-dir ./agent_state \ --checkpoint-interval 15min \ --approval-mode milestone \ --approval-rules db_migration, delete_file, dependency_add, api_signature_change参数解释--max-attempts 4意味着整个任务最多做四轮大的规划循环避免它在目标没达成时无限从头再来。--checkpoint-dir 是所有状态文件存放的位置。我建议放在项目外的一个独立目录否则如果Agent误操作清空了工作区它会把自己的记忆也一起删掉。--approval-mode milestone是当Agent计划执行涉及审批规则里列出的操作时它必须先暂停输出一段说明文字等待你点击确认。夜间跑批时这个卡点会一直等天亮后你自然就会去处理。启动之前我强烈建议你做一个缩小版预演。把任务说明书里的一小部分抽出来让Agent跑30分钟你盯着日志看一轮完整循环。确认它的计划分解方式、代码风格、工具调用习惯符合预期再放手让它跑过夜。这听起来多花半小时但能省掉第二天整理烂摊子的两小时。3.4 分钟级日志审计看它到底干了什么Agent跑完12小时你不可能一行行读完它产生的所有日志但也不能不看就合并。我这里的实践经验是建立一套分钟级摘要关键节点事件的审计习惯。所谓分钟级摘要是指Agent每完成一个原子步骤框架就自动生成一条精简记录改了什么文件、为什么改、测试结果如何、有没有产生新的技术债。关键节点事件则包括计划生成、里程碑完成、失败高峰出现、审批触发。这些事件会被单独标记方便我第二天早晨快速浏览。我实际看到过一条典型记录长这样[03:12:05] plan: 将折扣计算迁移至 src/pricing/discount.py [03:12:40] edit: 新增 discount.py声明 DiscountEngine 类 [03:13:02] test: tests/unit/test_discount.py 新增 3 个用例预期失败 [03:14:37] fix: 修正 applyDiscount 对 combo 类型为空时的空指针 [03:15:10] test: 全部通过 (5 passed)覆盖率 71%低于门禁 [03:15:11] next: 补充边界用例目标覆盖率 90%这类日志的价值在于你能快速判断Agent是在按照你的思路前进还是在自我折腾。如果一个文件被反复修改超过五次以上我会直接去看这个文件最后的样子确认是不是因为起点设计有问题。我还有一个习惯让Agent在每个里程碑结束时输出一段给评审人的话用自然语言总结它做了什么、有什么风险、希望评审重点看哪。这是因为Agent自己最清楚它在改动里埋了什么雷它有义务说出来。如果它每次都说没有风险那我反而会提高警惕。4. 高频故障与排查速查表那些跑偏到天明的夜里长任务跑得多了你会慢慢意识到问题并不取决于Agent聪明不聪明而取决于它的运行环境有没有失控。下面这张速查表是我踩过几十次坑之后整理出来的针对的是连续工作12小时场景下的高频故障。现象可能原因处置方法同一个编译错误反复失败上下文被大量噪音占据或修复策略过保守限制连续失败阈值强制它输出改动描述失败原因再决定是否继续后半夜产出明显偏离目标上下文污染旧的错误假设残留在会话里尊重断点机制新会话加载摘要重新继续测试全绿但需求不对验收标准写成了技术指标而非业务行为把验收标准改成行为描述补充边界用例Agent频繁请求审批进度停滞审批规则过宽或动作空间太窄分类放开低风险动作把审批集中在真正的敏感操作上输出代码风格完全不像团队风格缺少项目级上下文把项目README、代码风格规范、近期PR模式预先喂给Agent作为参考凌晨三点报告任务已完成但仓库里没有对应提交状态持久化或提交环节出问题检查checkpoint文件确认是否提交失败手动触发最后一步4.1 死循环与连续失败同一错误重复三次就该停这是长任务里最常见的翻车现场。Agent在修复同一个函数的编译错误时会反复尝试但每次只改动一行、再跑一遍得到同样的报错再改一行周而复始。它本质上是在一个高维空间里面做局部搜索但因为没有人类那种啊这个方向看来是死路的直觉它会一直撞墙。处理办法很简单在框架层面加一条硬规则当同一个错误签名连续出现三次时Agent自动停止并输出一份重试报告。报告里必须说清楚三件事我最后一次改了什么、期望得到什么结果、实际报错是什么。如果你看完报告发现它的方向确实是错的甚至可以很明确地在指令里纠正它不要试图修复类型不匹配问题去改用 factory 模式重新实现这段逻辑。死循环的另一个诱因是任务粒度没有拆细。如果Agent被要求一次性实现整个模块的所有接口它会因为每项工作都太大而反复在各子任务之间跳来跳去。我现在的做法是在计划阶段就强制所有步骤原子化一个步骤只做一件事做完立刻验证验证通过才进入下一步。粒度够细死循环的概率就会大幅下降。4.2 上下文污染与旧假设残留换会话比继续对话更有效我见过最让人崩溃的场景Agent早上七点提交的代码里还带着半夜三点的那条过时决策即使需求已经在凌晨四点被修正过。原因是同一个会话里残留的信息太多模型已经分不清哪一条是最新的。人的对话里你打断对方说你理解错了我改一下需求对方能实时衔接到新上下文。但Agent不是这样的。它把整段历史都塞在上下文里越早的信息权重越低但并非被清除而是像一层旧底色一样污染所有后续输出。最可靠的办法不是纠正它而是换一个大脑继续它。当你发现Agent长期在同一个错误假设里打转就不要继续在那个会话里和它纠缠。先把当前状态写入checkpoint文件把最新需求写清楚然后新开会话只加载最新的状态文件和任务说明书。这个操作虽然需要几分钟但效果立竿见影它的记忆里已经没有那些错误轨迹就不会再被拖进旧思路里。我自己会在任务说明书的头部加一行最新变更记录每次人工介入调整需求后都把变更内容追加到最前面作为最高优先级上下文。这相当于给Agent重新装了一幅关于当前事实的地图。4.3 测试都绿了但需求错了验收标准与覆盖率不是一回事有一类失败是最难察觉的Agent第二天交付的代码单测全绿、覆盖率达标、编译通过、代码风格也规范但你把业务需求拿出来一对比发现它的核心逻辑根本不是你想要的。问题往往出在验收标准的表述上。如果标准写的是单元测试覆盖率不低于90%那Agent自然会追求覆盖率——补一堆毫无业务价值的测试、mock掉外部依赖、把断言写得没有区分度覆盖率数字漂亮但代码语义空洞。它把完成理解为满足数字指标而不是满足业务行为。补救的方法是把验收标准从技术指标改成业务行为描述。比如描述折扣叠加顺序先按会员等级打折再应用满减最后四舍五入到分价格小于等于零时原样返回。这样Agent的每一个实现细节都能与具体业务规则对应上测试才算真正有内容。我在做长任务之前会专门花十几分钟做一件反向验证站在Agent的视角用它的逻辑读一遍验收标准问自己如果我只看这一句话会怎么实现如果答案是随便写覆盖率到就行那说明标准还是太泛了。4.4 权限卡顿与审批风暴给Agent一个合理的动作空间权限设计太紧Agent每走三步就要停下来等审批跑一整夜可能只完成20%的进度权限设计太松它有可能会擅自推一个全新的数据库表结构或者把公共依赖升级到不兼容版本。我建议用分级权限替代一刀切。把Agent可能执行的动作分成只读、局部写、全局写、敏感操作四类。只读动作完全放开局部写限制在工作区内全局写需要审批敏感操作数据库迁移、删文件、改协议全部卡住。实际操作中先用一个白天任务摸清这个Agent在你们项目里到底需要用到哪些操作再把对应的权限放出。还有一个容易被忽略的点Agent请求审批时它给出的解释往往只是一句需要修改配置文件请批准。这种模糊表述是危险信号说明它自己也不清楚这次改动会带来什么影响。我会让审批系统强制要求Agent填写改动对象、影响范围、回滚方案三项内容填不清楚就不予通过。这套机制既能挡住真正的危险操作也能逼着Agent在执行之前先想清楚后果。5. 开发者能力模型的重构真正稀缺的是把模糊变清晰的能力5.1 交付半径的变化一个人的团队边界在扩大回到标题里那个问题当AI学会连续工作12小时我们开始重新定义开发者。最直观的变化是交付半径。过去一个合格的后端开发者一天能完成一个中等模块的编写和自测已经是高效率。现在我把同样的任务拆成一份任务说明书丢给Agent跑过夜第二天早上拿到的不只是代码还包括完整的测试、迁移说明和评审日志。一个开发者加上一组Agent在边界清晰的任务上能够覆盖从前一个小组才能完成的工程量。这不是夸张。我自己在模拟项目X里做过一次对照一个数据管道加报表服务的小项目以前我和另一位同事两个人花了两个工作日从设计到上线。上个月我把同样的需求整理成说明书让Agent连续跑了两夜早上起来需要做的事只剩下代码评审和部署配置微调。整个过程中我实际写的代码量不到一百行但我投放进去的时间并没有减少太多——只是时间从敲键盘变成了拆需求、定边界、审代码。这带来一个很现实的问题如果从产能角度衡量一个人的产出上限被AI抬高了数倍。但对每个开发者个体来说真正稀缺的已经不再是能写多少行代码而是能不能把一个模糊想法拆解成一个让Agent不跑偏或跑偏后能快速兜底的工程任务。5.2 新能力模型从手写代码到定义边界的五维转换我把这种转型总结成一张对照表方便你理解它到底改变了什么能力维度旧模式新模式首要技能手写高质量代码写清楚验收标准与边界条件核心武器调试器与编程语言深度任务拆解与结果评审对需求的介入方式读懂文档后直接编码把模糊需求转成被验证的工程规格代码评审侧重点实现是否优雅、性能是否达标意图是否被正确转译、边界是否覆盖风险控制手段编码时靠经验避坑通过审批门禁、测试门禁、日志审计兜底最显著的变化集中在两点。第一从写代码到写规格。以前我们说一个人代码写得好是说他在抽象、命名、设计模式这些维度上有判断。现在Agent写代码的能力已经很强但它的判断来自于你给的上下文。如果规格写得暧昧它就会替你发挥。所以写规格变成了开发者的核心技能。这里的规格不只是需求文档还包括验收标准、边界条件、负面清单以及你希望Agent在遇到不确定情况时采取什么默认策略。第二从实现优先到验证优先。过去你想验证一段代码对不对自己写单测自己看结果。现在你要验证的是Agent的产出对不对这不仅需要代码评审能力还需要更敏锐的系统边界感哪里容易被Agent过度设计哪里又会因为Agent的保守而没有做这种敏感性只能在长任务的复盘里慢慢培养起来。5.3 异步协作成为主流Agent跑批人来做评审团队协作的节奏也在发生变化。以前开发流程是线性的今天写代码今天提交今天评审。现在夜里Agent跑批白天人评审一个异步开发的新循环开始成形。这对我个人的工作方式影响非常直接。以前每天最有创造力的上午时间全部消耗在编译、调试、纠结命名上。现在上午的第一个任务是打开昨天Agent跑批后的评审列表逐个确认它是如何理解需求的有没有突破边界有没有产生新的技术债。这意味着评审Agent的产出变成了一项正式工作而不再是偶尔看一眼的流程。评审的侧重点也和以前完全不同。过去评审代码最关心的是这段代码写得好不好现在评审Agent的产出最关心的是它对需求的理解与你的意图是否一致。代码本身的风格、结构问题Agent通常能自己调整真正会把项目带偏的是它在某个细节上自作主张地缩小或放大了需求范围。我逐渐形成了一套自己的评审清单第一验收标准是否全部被满足有没有通过改标准来凑答案的情况第二负面清单有没有被突破如果有原因是什么第三不该出现的设计扩张有没有出现——比如明明只需要修一个bug结果它顺手抽象出了一个框架第四测试是不是在保护真正的业务行为而不是在保护它自己写出来的逻辑。这套清单看起来简单实际执行起来需要相当的经验因为你得真正在那个业务上下文里才能判断Agent的某一步修改到底是合理延伸还是越权发挥。所以我一直跟身边人说AI长跑并没有降低对工程师能力的要求它只是把能力要求从写得快变成了判断得准。6. 一点个人体会把什么算完成想清楚再按下启动键这篇讲了很多机制、参数和排查技巧但如果你只记住一句话我想是这句连续工作12小时真正考验的不是Agent的忍耐力而是你定义目标的能力。我现在的习惯是每天晚上下班前花十五分钟把第二天值得丢给Agent的任务列出来。每一条都必须能回答什么算完成验收标准是什么边界在哪里什么情况下可以停下来求助。然后启动跑批任务设置审批门禁关电脑。早上起来先看状态文件再挑最可疑的变更做重点评审。这个过程坚持了几个月之后我发现自己对需求清晰度的敏感度变高了写文档时会下意识避开那些过大的、不可验证的表述。最后分享一个小技巧如果你不确定一份任务说明书是否足够清晰可以先用它让Agent跑十五分钟然后问它你计划怎么做打算修改哪些文件。只要它能把计划讲得具体到文件和步骤你就可以安心让它跑过夜。如果它的计划听起来模棱两可那缺席的其实不是Agent的能力而是你心里那个还没成形的答案。去找清楚那个答案再让机器替你熬夜。