过去半年我几乎把AI辅助编程当成了日常主食但真正让我停下来重新思考的是看到Anthropic内部那套研发流程的公开材料。核心关键词就一个——Anthropic重做了AI时代的研发流程这跟我过去理解的用AI加速写代码完全是两码事。这不是把某个环节换成AI工具而是把整条研发流水线从需求拆解、任务分配、编码实现到质量验收全部重排了一遍。对于正在用AI做开发、做测试、做团队管理的工程师和技术负责人来说这篇文章里有Anthropic这套做法的拆解也有我自己的落地经验和踩坑记录适合所有想知道AI时代研发流程到底应该长什么样的人参考。1. 为什么说重做——从工具升级到流水线重排的本质转变很多团队现在搞AI研发流程本质上做的事情是在原有的研发流程上加AI。需求评审还是人开会排期还是人拍脑袋编码让AI帮个忙测试还是人来写总结下来就是AI是个加强版的自动补全和搜索引擎。但Anthropic的做法完全不同它是把流程本身拆开重新思考每一个环节里人和AI各自的角色流程的设计围绕AI的能力边界来展开而不是围绕人的习惯来展开。1.1 传统研发流程与新流程的本质差异传统流程的逻辑链条是产品经理写需求文档项目经理排计划架构师画方案开发写代码测试写用例运维管上线。整个链条的搬运主体是人文档是人与人之间的交接凭证。这个模式有一个隐含假设流程的速度取决于人的带宽和人传递信息的效率。Anthropic重做之后链条变成了需求意图转化为结构化规格AI负责把规格逐步细化并直接生成可执行方案多个Agent分工完成编码和测试质量闸门用自动化规则和独立Agent做双重校验人在关键节点做裁决。核心变化不是某个环节变快了而是整个链条的搬运主体从人变成了结构化文档加AI执行体。我自己的类比是传统研发像一家手工坊老师傅从头做到尾Anthropic的做法像是把手工坊改成了流水线工厂。工厂不是给每个工人发了一台更好的机床而是把工件分成无数标准件每个工位只做一件标准化的事质量靠工位间的检查环节保证。这就是重做的真正含义。1.2 驱动这次重做的底层原因Anthropic敢这么重做根本原因在于大模型的能力曲线走到了一个临界点模型已经能够理解足够复杂的上下文并且能够按照指令执行多步骤任务同时还能保证一定的输出质量稳定。但临界点的另一面是模型的上下文窗口有限注意力有衰减单次会话处理长链路任务会越走越偏。所以流程设计必须把大任务切碎成小任务每个小任务的边界必须清晰输入输出必须明确验收标准必须可执行。过去的流程设计考虑的是人怎么协同现在的流程设计考虑的是人怎么给模型下达不会误解的指令。提示如果在你的团队里AI写的代码经常跑偏大概率不是模型不行而是你的任务拆解得太粗。这是Anthropic这套流程给我最大的启发。2. 需求拆解是第一道工序把模糊想法变成Agent可执行的任务卡片Anthropic研发流程里最被低估的环节是需求拆解。它不只是写一堆用户故事而是把需求变成一个一个原子化的任务卡片每张卡片都包含背景、目标、验收条件、边界约束和自动化测试方式。模型不需要理解意图它只需要照着任务卡片执行。2.1 任务卡片的标准结构我总结了一套在团队里实测有效的任务卡片模板核心字段如下任务名称一句话动词开头明确产出物背景说明2到3句话交代这份任务出现在哪个模块里为什么存在目标描述可量化的结果描述完成长什么样验收条件可以被自动化脚本或测试用例验证的判定标准边界约束明确哪些事禁止做、哪些模块不能动、哪些依赖不可升级输入输出协议任务读什么数据、写什么数据、接口签名是什么参考示例给出一个最小可运行的理想输出样例举个例子一次重构缓存模块的任务我写的卡片是任务名称为将缓存模块的存储层替换为TTL自动清理实现。背景是现有缓存只支持手动清理导致内存增长不可控。目标是缓存条目超过10000条或存活超过5分钟时自动淘汰命中率不低于95%。验收条件是压测脚本能验证淘汰逻辑和命中率两个指标。边界约束是不允许改动上层调用接口不允许引入新依赖。这个卡片直接交给Claude去执行它生成的代码基本没有返工。2.2 任务粒度的判断标准很多团队在实践时卡在任务拆多细这个问题上。我的经验是三条标准一个任务应该在2到4小时内由AI完成第一版超过这个时间说明拆得还不够细任务的输入输出必须明确AI不需要做设计决策只需要做实现决策每个任务的验收条件可以被脚本测试覆盖不能靠人肉看代码觉得对粒度太细会有另一个问题任务之间大量重复交接上下文反而降低了效率。我常用的判断是让AI每完成一个任务后写一个极简的产出摘要包含改动文件清单、关键实现逻辑和自测结论这个摘要会作为下一个任务的上下文输入。这样既控制粒度又不丢失信息。2.3 提示词不只是对话而是一种流程产物热词里反复出现AI编程提示词我想说的是Anthropic这套流程里的提示词不是你和AI聊天时随手打的句子而是流程中的标准化产物。每个任务卡片应该配一个固定格式的System Prompt里面定义AI的角色、行为准则、输出格式、禁止事项。我自己常用的System Prompt模板大概是你是一名资深后端工程师根据任务卡片完成代码实现输出包括改动文件列表、代码diff说明、自测结果三项内容。禁止修改非任务范围的代码禁止引入新依赖所有函数必须包含docstring错误处理必须返回错误码而不是抛运行时异常。这套固定化之后AI的输出会稳定非常多不会三天两头给你整出惊喜。3. 多Agent协作与质量闸门让AI彼此验收而不是一个人盯着Anthropic研发流程里最让我兴奋的部分是多AI协作的设计。你在热搜词里也能看到多AI协作AI Agent这些词频繁出现。这不是噱头而是应对大模型固有缺陷的必然选择。单个Agent在长链路任务里会因为上下文漂移和注意力衰减出现质量问题多个Agent互相制约就能把问题控制在每个环节内。3.1 四个角色的分工设计我的实践里把Agent分成四类角色规划Agent读任务卡片输出实施方案包括技术选型、改动文件清单、实现顺序和风险点编码Agent按照实施方案写代码一次只改一个文件或一个模块审查Agent检查编码Agent的产出重点看边界条件、空指针、并发安全和接口兼容性测试Agent根据任务卡片自动生成单元测试和集成测试并执行输出覆盖率报告这四个角色不是四个不同的模型而是同一个模型加载不同的System Prompt、不同的上下文切片、不同的工具权限。规划Agent只读任务卡片和方案模板编码Agent只读实施方案和当前代码文件审查Agent只读代码diff和编码规范测试Agent只读代码和验收条件。角色之间通过结构化产出物交互不直接对话。3.2 质量闸门的具体节点质量闸门是这套流程里防止错误累积的关键机制我在每个环节之间都设置了硬性检查点第一道闸门是方案评审。规划Agent输出的实施方案必须通过固定格式自检包括是否覆盖了所有验收条件、是否标注了风险点、是否给出回滚方案。闸门不通过不进入编码环节。第二道闸门是代码静态检查。审查Agent对编码Agent的产出做规则检查比如未处理的错误返回值、过长的函数、缺失的类型声明每个问题必须给出严重等级。第三道闸门是测试闭环。测试Agent生成的测试必须在目标环境跑通测试覆盖率达到任务卡片约定的阈值。第四道闸门是人工裁决。前三道闸门都通过后人工做最终验收重点看业务语义是否正确有没有AI自己察觉不到的隐含假设错误。这一步无法省AI的盲区必须用人的业务判断来兜底。3.3 为什么要搞这么重有人可能会问为什么不让一个Agent干完所有事非要拆成四个角色来回交接我实测下来的答案是一个Agent干所有事的时候它在写代码时已经忘了方案里定的约束在写测试时又只测试自己代码里已经实现的行为相当于自己出题自己答错误能被隐藏到交付那一刻。拆开之后编码Agent和测试Agent看的是不同的上下文测试Agent不知道编码Agent写了什么细节只按照卡片验收条件验证这样才能真正发现问题。提示如果你现在是一个人用AI写项目最低限度也要拆两个Agent一个写代码一个写测试并执行。就这一个改变返工率能下降一半以上。4. 工具链落地实操Claude API接入与代码生成的工作台搭建Anthropic重做研发流程最终要落到工具链上才能跑起来。我搭建这套工作台经历了从纯对话到半自动化再到全流程化的过程接下来把这几个阶段的做法和关键参数都写出来方便你直接参考。4.1 第一步用Claude API直接跑通核心能力要支撑多Agent协作不能用网页版一个个对话必须用API把Agent串起来。最基本的调用方式很简单需要注意几个参数model选择我日常用claude-sonnet-4-0或你账号能访问的最新稳定型号跑编码任务用claude-opus级别跑方案设计和复杂重构因为推理深度更好但延迟和成本更高。max_tokens编码任务设置最大值这个参数不会限制上下文输入只决定输出上限。写完整模块我习惯设到8192。temperature编码场景设0.2保证输出稳定做方案发散可以设0.7测试生成设0.1因为测试需要严格匹配验收条件。一个最基本的调用示例我用Python requests库写的import requests import json def call_claude(system_prompt, user_content, modelclaude-sonnet-4-0, max_tokens4096, temperature0.2): headers { x-api-key: 你的API Key, anthropic-version: 2023-06-01, content-type: application/json } payload { model: model, max_tokens: max_tokens, temperature: temperature, system: system_prompt, messages: [ {role: user, content: user_content} ] } resp requests.post(https://api.anthropic.com/v1/messages, headersheaders, jsonpayload, timeout300) data resp.json() return data[content][0][text]这里有个细节system字段在API请求里是顶层参数不是messages数组里的成员。这个位置放错会导致额外的system提示被模型当成普通对话内容来解读。4.2 第二步用工具调用约束Agent行为光靠对话让Agent写代码它会经常自作主张所以必须用工具调用机制约束它的行为。Anthropic API支持让模型输出结构化工具调用你只需要定义好工具接口让Agent通过工具完成文件读写和命令执行。我给编码Agent定义的工具集如下write_file(file_path, content)写入文件路径必须在项目白名单内read_file(file_path, line_start, line_end)读取指定范围的代码run_command(command, timeout)在沙箱里执行测试命令search_code(query)搜索代码库中相关标识符每个工具都有严格的入参和返回值定义Agent准备调用工具时API会返回一个tool_use结构。你需要循环处理把结果回传给模型直到模型输出最终答案。这个循环逻辑看起来简单但它是整个Agent工作台的地基。def run_agent_loop(client, system, task, tools): messages [{role: user, content: task}] for _ in range(30): resp client.messages.create( modelclaude-sonnet-4-0, max_tokens8192, systemsystem, toolstools, messagesmessages ) if any(block.type text for block in resp.content): return resp.content[0].text tool_calls [b for b in resp.content if b.type tool_use] for call in tool_calls: result execute_tool(call.name, call.input) messages.append({role: assistant, content: [call]}) messages.append({role: user, content: [ {type: tool_result, tool_use_id: call.id, content: str(result)} ]}) return None注意循环上限的必要性。如果没有迭代上限一个失控的Agent能无限调用工具把你的磁盘写满或者把测试命令跑几十次。我遇到过Agent陷入修改代码再跑测试再修改的死循环加上上限之后这个问题再没有出现过。4.3 第三步全套流程串联工具调通之后我把四类Agent串成一条完整流水线。我写了一个调度脚本流程如下读取任务卡片的JSON文件启动规划Agent获得实施方案将实施方案传给编码Agent限制它只操作指定文件将代码diff传给审查Agent获得审查意见若存在不通过项则打回编码Agent修改将最终代码传给测试Agent生成并执行测试脚本汇总所有产出物输出一份研发报告包括方案、代码、审查意见和测试结果整套脚本我放在项目根目录下的pipeline文件夹里每次新任务只需要写一张任务卡片JSON然后执行一个命令python pipeline/run.py --task tasks/cache_refactor.json实测下来一个中等复杂度的模块改造从写卡片到拿到可运行代码和完整的测试报告大约需要20到40分钟。这个速度在过去是不可想象的。但前提是卡片写得好、工具循环稳定中间任何一环偷懒都会导致流程断路。5. 踩坑实录连接异常、网关路由与上下文失控的三类事故任何工具链跑久了都会遇到问题Anthropic这套流程也不例外。我把这段时间遇到的最典型的三个问题写出来每个问题都给出完整的排查链路而不是直接甩结论。5.1 unable to connect to anthropic services failed to connect to api.anthropic.c的排查链路报错字样为unable to connect to anthropic services failed to connect to api.anthropic.c这个错误大多发生在Agent工作台的API调用环节。我的排查顺序是先看网络连通性。用带超时的请求探测API端点是否可达我写了个小脚本用requests库设置connect_timeout10如果超时说明网络层不通检查防火墙规则、公司内网白名单配置如果连接成功但返回5xx说明是服务端负载或状态问题稍后重试。再看API key。检查环境变量里的key是否被误改、是否过期。这里有个常见坑在Shell里export的变量换了一个终端窗口就失效了所以我在调度脚本启动时强制校验环境变量是否存在不存在直接报错退出避免带着空key去请求。最后做重试策略。AI Agent循环调用API的频率比人手敲高得多偶尔出现瞬断是正常的。我给请求加上指数退避重试重试3次间隔分别是1秒、2秒、4秒。加了重试之后整个流水线因为瞬断中断的概率从一天三四次降到了几乎为零。import time def call_with_retry(system_prompt, user_content, max_retries3): for attempt in range(max_retries): try: return call_claude(system_prompt, user_content) except Exception as e: if attempt max_retries - 1: raise e time.sleep(2 ** attempt)5.2 claude doesnt look like an anthropic model: expected a gateway model route的工程解读这条报错我第一次见到时一头雾水。字符串里出现了expected a gateway model route实际意思是请求被网关路由到了某个模型但网关侧的模型标识与上游期望的模型不匹配。简单说就是你请求头里指定的model参数和网关配置的路由规则对不上。排查链路是先确认请求里的model字段拼写是否完全正确模型名大小写敏感写错一个字符就会触发这个报错再检查网关或个人代理层的路由表确认目标模型区域和请求头一致最后确认账号权限有些模型只在特定区域开放权限不足也会出现类似的模型不可用回报。工程上的解法是把模型名统一收敛到配置文件中不在代码里硬编码。这样切换模型或调整路由时只要改一处配置。我在项目里用了环境变量export ANTHROPIC_MODELclaude-sonnet-4-0调度脚本启动时读取这个变量所有Agent调用统一使用它避免各个脚本分散硬编码导致路由不一致。5.3 上下文失控Agent做着做着忘了任务本身这是比连接错误更隐蔽的问题。Agent工具循环跑了几轮之后它会沉迷于工具调用的细节忘记最初的代码规范。我遇到过一次编码Agent开始用不存在的API写代码审查Agent居然没发现因为审查Agent的输入只有diff没有原始任务卡片。解决方案是在每轮循环里把任务卡片重新注入上下文让Agent每完成一步都回到任务本身。具体做法是在工具结果的回传消息后面追加一条固定的提醒文本注意你正在执行的任务是{task_summary}请确保当前操作仍在任务范围内。开销很小但效果立竿见影。另一个防御措施是给每个Agent的System Prompt加上一句一旦发现当前工具调用链超过15步仍未完成立即停止并输出阶段性总结。这能避免失控循环浪费token和时间。提示多Agent协作时审查Agent和测试Agent的输入信息必须和编码Agent的输入信息做隔离。如果大家都看同一份完整上下文就失去了互相查错的意义。6. 组织方式重构工程师从写代码的人变成定义AI行为的人Anthropic这套流程带来的不仅仅是工具链的变化它对团队组织结构的影响才是更深层的重做。我在自己团队实践一段时间后清晰地看到每个人的角色开始位移。6.1 工程师的新核心能力传统工程师的核心能力是写代码新的流程里写代码的任务大量交给Agent之后工程师的核心能力变成了三件事第一件事是需求拆解能力。能把模糊的产品意图拆成任务卡片这是新的稀缺技能。拆得好的工程师他定义的Agent产出质量和交付速度完全碾压别人。第二件事是验收设计能力。能够写出准确、可自动化验证的验收条件。很多工程师习惯了代码能跑就行的思维现在要转变成跑通了分支场景还不够要定义清楚所有边界条件。第三件事是质量责任意识。AI生成代码后最终签字的还是工程师出了生产事故背责任的也是工程师。所以每个任务卡片的最终验收环节人工必须认真做业务语义层面的审查不能因为测试Agent都跑通了就盲目相信。6.2 文档从记录工具变成控制中枢传统研发里文档经常是摆设代码才是真相。Anthropic这套流程把顺序颠倒过来了任务卡片和实施方案才是控制中枢代码只是执行结果。这要求文档必须保持实时准确因为Agent会严格按照文档执行文档错了代码就错了而且错得比人写代码时更彻底。我现在的习惯是每次任务开始前先写卡片任务过程中如果发现需要调整先改卡片再让Agent继续。绝不允许让Agent自行偏离卡片去发挥。这套做法刚开始感觉很麻烦但坚持下来之后项目知识库的质量有了质的提升因为所有决策理由都留在了卡片注释里而不是留在某个人的脑子里。6.3 对团队规模的要求和参考路径有人说这套流程是大厂专属我需要澄清一下Anthropic的做法本身很重但对中小团队来说可以直接采用简化版落地。我个人的参考路径是先砍需求拆解和多Agent协作这两块工具上只需要一个能跑API脚本的工程师。跑通之后再逐步加审查Agent、测试Agent和质量闸门。团队里只有一个人的情况下也能用你就是规划者和验收者编码和执行交给AI。我在个人项目里就是一个人维护四个Agent脚本负担完全可以接受。6.4 行业里的同方向信号热搜词里出现了deepseek公开ai智能体训练新方法这不是孤立事件。开源的智能体训练方法越来越多本质上都是往同一个方向使劲让模型的行为更可控、更可预测、更适合嵌入流程执行。这说明Anthropic重做研发流程并不是一家公司的孤例而是整个行业对AI如何融入严肃生产这个问题的共同回应。作为一线工程师早点适应这套新流程比等着行业标准定了再学要划算得多。我在实际落地这套流程的过程中最大的体会是真正慢下来的环节不是AI写代码而是人把需求想清楚。任务卡片写得越细整个流水线越顺反之卡片写得很模糊后面所有环节都会连环返工。所以如果你准备参考Anthropic这套做法我建议第一步不要急着搭工具链先拿纸笔练习拆任务卡片拆到能把一个功能拆成10个以上的原子任务再开始碰API脚本。另外一个我反复强调的经验是Agent之间必须做信息隔离不要图省事把完整上下文丢给所有Agent否则多Agent协作就退化成了一个Agent自问自答失去查错的意义。这套流程还有很多可以优化的细节比如如何让测试Agent更好地覆盖产品级场景、如何把人工验收变成更轻量的一次点击这些都是下一步值得折腾的方向。