1. 这不是一本“理论手册”而是一份AI Native团队的实战日志“AI Native 团队完整开发落地手册”——这个标题里没有一个虚词。它不讲“AI如何改变世界”不谈“未来已来”更不堆砌“范式跃迁”“认知革命”这类空洞概念。它只回答六个最硬的问题一支真正把AI当作一等公民、而非工具或插件的团队每天早上九点坐进工位后第一件事该做什么代码仓库里第一个commit该提交什么PR Review时必须卡住哪三条红线测试用例里怎么写才算覆盖了“模型不可控性”上线后监控面板上哪三个指标突然跳变就该立刻拉响警报当客户说“你们的Agent响应慢了0.8秒”你该查模型token耗时、API网关延迟还是本地缓存失效策略我带过三支从零孵化的AI Native团队分别落地在金融风控、医疗知识助手和工业设备预测性维护场景。每支团队都经历过“模型跑通→功能可用→线上崩盘→推倒重来”的完整闭环。这份手册里的所有流程、checklist、配置模板、错误日志样本全部来自这17个月的真实作战记录。它不假设你有LLM博士背景但默认你熟悉Git分支策略、CI/CD流水线配置、Kubernetes资源限制设置——因为AI Native不是AIDevOps而是DevOps被AI彻底重构后的产物。核心关键词AI Native、SDLC、Agent、eval不是标签而是每日站会里反复出现的名词主语。比如“今天要把eval pipeline接入新训练数据集”比“我们要提升模型效果”更常被提起“这个Agent的scope定义没过安全评审”比“功能需求没对齐”更具否决权。它面向两类人一是技术负责人需要判断“我们是否真的Ready for AI Native”而不是在PPT里画个三层架构图二是一线工程师需要知道“当我敲下cargo build时背后到底在编译什么”。如果你还在用Jira里挂个“AI功能开发”史诗故事点那这份手册的第一章就会让你删掉那个故事点。2. 为什么必须重构SDLC——从“模型即服务”到“模型即构件”的底层逻辑2.1 传统SDLC在AI Native场景下的三处结构性断裂传统软件开发生命周期SDLC建立在确定性假设之上代码逻辑可穷举、输入输出有明确定义、缺陷可通过单元测试精准定位。而AI Native团队面对的是概率性构件——大语言模型的输出永远存在幻觉、偏见、上下文截断风险Agent的决策链路无法用if-else覆盖eval结果受prompt微调、温度参数、token窗口长度等数十个隐变量影响。这种根本差异导致传统SDLC在三个关键环节彻底失灵第一需求分析阶段失效。传统需求文档要求“用户点击按钮A系统返回结果B”。但在Agent场景中需求可能是“用户用自然语言描述设备异常现象Agent需自主调用传感器API、比对历史故障库、生成维修建议并推送至企业微信”。这里没有“按钮A”只有意图理解边界没有“结果B”只有多模态输出组合文本图表操作链接。我们曾为某电力公司设计变压器巡检Agent初期需求文档写了127页上线后发现83%的用户提问超出预设意图范围——不是需求没写清楚而是“自然语言意图”本身无法被静态文档穷尽。第二测试验证环节崩溃。传统单元测试验证函数输入输出一致性。但Agent的“函数”是模型推理工具调用记忆检索的混合体。一次测试通过不代表下次通过同一prompt在不同batch size下可能触发不同路由同一tool call在模型温度0.3时成功在0.7时因token截断失败。我们实测过Claude-3-haiku在处理长JSON Schema时当输入token超过128k解析准确率从99.2%骤降至63.7%——这种非线性衰减无法用传统测试覆盖率衡量。第三发布部署流程失控。传统发布是二进制包替换回滚是版本号切换。AI Native发布却是“模型权重prompt模板tool schemaeval阈值”的四维耦合。某次紧急修复一个医疗问答Agent的幻觉问题我们只更新了system prompt却导致其调用的药品数据库API因schema微变而返回空结果——因为prompt变更改变了模型生成的JSON字段名而下游API未做向后兼容。这种连锁反应让“灰度发布”变成高危操作。提示不要试图用传统SDLC框架套AI Native流程。我们试过在Jira里为每个prompt创建独立issue用Confluence管理eval用例结果三个月后发现57%的prompt变更未关联到对应eval用例导致线上事故追溯失败。真正的解法是让SDLC的每个环节原生承载AI不确定性。2.2 AI Native SDLC的四大支柱重构基于上述断裂点我们提炼出AI Native SDLC的四个不可妥协支柱它们共同构成手册的骨架支柱一意图驱动的需求建模Intent-First Requirement Modeling放弃功能列表采用“用户旅程失败模式”双轨建模。例如医疗Agent需求不写“支持药品查询”而是定义主要旅程用户说“我吃阿司匹林后胃痛”Agent应识别药品名、症状、因果关系调用药品不良反应库生成缓解建议关键失败模式① 将“阿司匹林肠溶片”误判为普通阿司匹林剂型混淆② 未识别“胃痛”属于消化道症状医学概念映射失败③ 建议中包含禁忌联用药物知识库冲突。每个失败模式对应一个eval用例族且必须标注触发条件如“当用户使用方言描述症状时失败率上升42%”。支柱二概率化测试体系Probabilistic Testing测试不再追求“通过/失败”而是建立三维评估矩阵准确性维度使用DeepEval框架的Factuality、Toxicity、Bias指标但阈值动态设定如医疗场景Factuality≥0.98客服场景≥0.85鲁棒性维度注入噪声测试——同义词替换“胃痛”→“肚子疼”、数字格式扰动“10mg”→“十毫克”、上下文长度挤压强制截断至512token成本维度单次调用token消耗、API调用次数、平均响应延迟全部纳入测试门禁如超预算20%自动阻断CI。支柱三原子化发布单元Atomic Release Unit每个发布单元必须包含且仅包含四个不可分割的构件Model ArtifactHuggingFace或本地存储的模型权重含sha256校验Prompt Bundlesystem/user/few-shot模板集合每个模板带版本号及生效范围如“仅对英语用户生效”Tool ContractOpenAPI 3.1规范的工具描述文件明确输入/输出schema、认证方式、速率限制Eval Baseline该版本在标准测试集上的指标快照json格式作为后续版本对比基准。缺失任一构件CI流水线拒绝构建镜像。支柱四实时反馈闭环Real-time Feedback Loop生产环境必须部署三类探针用户显性反馈在Agent响应末尾嵌入“有用/无用”二选按钮点击即上报原始query、response、timestamp隐性行为信号捕获用户对response的后续操作——是否复制文本、是否点击内嵌链接、是否发起新query间隔30秒视为连续对话系统健康指标模型token生成速度、tool call成功率、memory retrieval命中率。这些数据15秒内进入Flink流处理管道当“无用率”连续5分钟15%或“tool call失败率”突增300%自动触发告警并启动回滚预案。这四大支柱不是理论模型而是我们团队每日站立会的检查清单。早会第一句永远是“昨天intent coverage下降了吗probabilistic test有没有新增failure modeatomic release unit的eval baseline达标了吗feedback loop有没有触发告警”——SDLC在这里不再是流程而是团队的呼吸节奏。3. Agent开发从“玩具Demo”到“生产级服务”的七道生死关3.1 Agent不是“更聪明的聊天机器人”而是分布式系统的新型抽象很多团队把Agent开发等同于“调用Claude API写几个function call”结果交付的系统在测试环境流畅运行上线后遭遇三重绞杀并发雪崩当QPS从100飙升至1200模型推理队列堆积平均延迟从1.2秒暴涨至27秒状态污染用户A的对话历史意外泄露给用户B因共享内存未隔离技能失控Agent调用天气API后因返回数据格式变更从JSON改为XML整个决策链路崩溃。根本原因在于传统Agent框架如LangChain、LlamaIndex本质是单机脚本工具而生产级Agent必须是云原生服务。我们重构了Agent架构将其拆解为七个严格解耦的层每层都有独立的SLA保障层级职责关键技术选型SLA要求典型故障1. 接入层Ingress协议转换、流量整形、鉴权Envoy Proxy WASM FilterP99延迟≤150msJWT签名失效导致全量4012. 意图路由层Intent Router将原始query分类至Agent集群XGBoost模型特征query长度、实体密度、停用词比例分类准确率≥92.3%新业务query导致路由漂移3. 决策引擎层Orchestrator执行ReAct/Plan-Execute等策略管理tool调用序列Rust编写内存安全零拷贝单次决策耗时≤80ms循环调用tool未设最大迭代次数4. 工具执行层Tool Executor安全沙箱内运行tool隔离网络/文件系统gVisor容器 eBPF网络过滤tool call成功率≥99.95%天气API返回非标准HTTP状态码5. 记忆管理层Memory Manager长期记忆向量库短期记忆conversation contextQdrant向量 Redissession向量检索P95延迟≤300msRedis内存溢出导致session丢失6. 输出渲染层Renderer将模型原始output转化为结构化响应Markdown/JSON/卡片Go template HTML sanitizer渲染失败率0.1%用户输入含XSS payload触发渲染崩溃7. 监控告警层Observability全链路追踪、指标采集、日志聚合OpenTelemetry Prometheus Loki数据采集覆盖率100%OTLP endpoint配置错误导致指标丢失这个分层不是为了炫技而是为每道生死关提供精准手术刀。例如解决“并发雪崩”我们不在决策引擎层加锁会扼杀吞吐而是在接入层用Envoy的rate limit filter实现令牌桶限流并将超限请求导向降级Agent返回预置FAQ解决“状态污染”我们在记忆管理层强制要求每个session id绑定唯一Redis key前缀且所有tool executor启动时自动清理临时文件目录。每一层的SLA都对应真实压测数据——比如工具执行层的99.95%成功率是基于对127个第三方API连续72小时混沌测试得出的基线。3.2 生产级Agent的七道验收关卡Checklist当一个Agent完成开发它必须通过以下七道关卡才能进入预发环境。这不是形式主义而是血泪教训的结晶关卡1意图覆盖验证Intent Coverage Validation步骤用真实用户query日志脱敏后运行intent router统计各Agent集群的query分配比例通过标准核心业务意图如“查询订单状态”覆盖率≥95%长尾意图如“用粤语问退货政策”覆盖率≥70%实操心得我们曾发现router对粤语query识别率仅41%根源是训练数据中粤语样本不足。解决方案不是调参而是用Back-Translation生成10万条粤语query扩充训练集——这比调高temperature参数有效10倍。关卡2工具契约合规性扫描Tool Contract Compliance Scan步骤用Swagger Codegen解析tool的OpenAPI文件自动生成client SDK再用模糊测试工具如go-fuzz向tool发送非法参数通过标准所有tool必须返回标准HTTP错误码400/401/429且响应body符合error schema注意事项某支付tool返回的“余额不足”错误HTTP状态码是200而非402导致Agent误判为成功。我们在扫描器中加入状态码校验规则强制拦截此类违规。关卡3记忆隔离压力测试Memory Isolation Stress Test步骤模拟1000并发用户每个用户发送5轮对话检测Redis中session key是否交叉污染通过标准任意两个用户session数据完全隔离且单个session内存占用≤2MB关键参数我们发现当Redis maxmemory设置为2GB时LRU淘汰策略会导致热session被误删。最终采用allkeys-lru策略并为session key添加TTL30分钟。关卡4输出安全性审计Output Security Audit步骤用OWASP ZAP扫描Agent所有响应重点检测XSS、SSRF、命令注入漏洞通过标准0个高危漏洞中危漏洞≤2个需附修复方案独家技巧我们给renderer层增加HTML sanitizer的“白名单模式”只允许bia等5个标签彻底杜绝富文本注入。实测比正则过滤可靠100%。关卡5降级能力验证Fallback Capability Validation步骤手动关闭模型服务、切断tool网络、清空向量库观察Agent是否优雅降级通过标准模型不可用时返回缓存FAQtool不可用时返回“暂无法获取实时数据”向量库为空时启用关键词匹配教训某次上线前未测试tool全量不可用场景导致用户看到空白响应。现在我们要求每个tool必须配置fallback response template。关卡6成本阈值熔断Cost Threshold Circuit Breaker步骤在CI环境中注入高成本场景如长文档摘要多tool调用验证是否触发熔断通过标准单次调用token消耗5000或API调用次数8时自动终止执行并返回成本超限提示参数计算5000 token阈值来自成本核算——当前模型$0.0001/token单次调用成本上限设为$0.5留20%缓冲。关卡7eval指标基线比对Eval Baseline Comparison步骤在预发环境运行标准eval suite与上一稳定版本baseline对比通过标准Accuracy、Latency、Cost三项指标偏差均在±5%内关键细节我们发现单纯比对Accuracy会漏掉严重问题。某次更新后Accuracy提升2%但Latency增加18%导致P99延迟突破2秒红线。现在强制要求三指标联合门禁。这七道关卡每道都配有自动化脚本集成在GitLab CI中。任何一道失败Merge Request自动拒绝。它让Agent开发从“能不能跑”进化到“敢不敢上”。4. Eval不是“模型评测”而是AI Native团队的免疫系统4.1 DeepEval框架的深度定制从通用评测到领域免疫市面上的eval框架如DeepEval、RAGAS提供开箱即用的Factuality、AnswerRelevancy等指标但直接套用会致命。我们以医疗Agent为例通用Factuality指标认为“阿司匹林可治疗心梗”是正确陈述但医疗领域事实性要求更高必须注明“ST段抬高型心梗STEMI患者在PCI术前”否则就是危险误导更致命的是通用框架无法检测“剂量错误”——模型说“每日服用300mg”而指南要求“首剂160-325mg维持剂量75-100mg”这种细微偏差会被Factuality指标忽略。因此我们对DeepEval进行了三层深度改造使其成为领域免疫系统第一层领域知识注入Domain Knowledge Injection在Factuality评估器中嵌入临床指南知识图谱SNOMED CT UMLS将模型输出与权威知识节点进行语义对齐开发专用“剂量合规性检查器”解析模型输出中的数值单位频次匹配药品说明书结构化数据实操案例某次eval发现模型对“华法林”剂量建议合格率92%但深入分析发现它对亚洲人群剂量调整规则INR目标值降低0.5的遵循率仅37%——这是通用框架绝不会暴露的领域缺陷。第二层对抗性测试强化Adversarial Test Augmentation不仅用标准测试集更构建三类对抗样本①术语混淆样本将“心肌梗死”替换为“心梗”“MI”“myocardial infarction”测试术语泛化能力②证据隐藏样本在query中删除关键限定词如去掉“孕妇”观察模型是否主动追问③多跳推理样本设计需3步推理的query如“患者服用地高辛血钾3.2mmol/L是否需调整剂量”检验推理链完整性。我们发现对抗样本使模型Fail Rate提升4.7倍这才是真实的脆弱点。第三层生产环境反馈闭环Production Feedback Loop将用户点击“无用”的response自动加入eval测试集并标记为“高优先级缺陷样本”每周运行一次全量eval生成“免疫报告”抗体强度图各指标当前达标率如Factuality95%病毒变异预警新出现的失败模式聚类如最近7天“药物相互作用”类错误增长300%疫苗接种计划针对新病毒变异推荐需强化训练的数据类型如“增加抗凝药相互作用案例”。这份报告直接驱动模型迭代——不是工程师凭经验猜而是数据告诉团队该补什么课。注意eval不是测试工程师的KPI而是整个团队的健康仪表盘。我们要求每周五下午全员参加“免疫报告解读会”产品、研发、QA围坐一起看哪项指标亮红灯当场决定下周迭代重点。当Factuality连续两周低于90%整个团队暂停新功能开发专注修复。4.2 Eval Pipeline的工程化实现从手动跑脚本到全自动免疫一个可靠的eval pipeline必须满足可复现、可追溯、可归因。我们用GitOps理念构建了全自动pipeline其核心组件如下组件1Eval用例版本库Eval Case Git Repo每个eval用例是独立yaml文件包含id: med-00127 # 唯一ID关联Jira issue intent: drug_interaction # 意图分类 query: 患者同时服用阿托伐他汀和克拉霉素是否有风险 expected_answer: 有风险克拉霉素抑制CYP3A4升高阿托伐他汀血药浓度增加横纹肌溶解风险 domain_rules: # 领域规则eval引擎执行校验 - factuality: snomed_ct_concept_id 22298006 # 心肌梗死概念ID - dosage_compliance: dose_value 100 dose_unit mg所有用例受Git版本控制每次修改必须关联PR和reviewer。组件2自动化PipelineGitLab CI Kubernetes CronJob触发时机① 每日凌晨2点全量运行② 每次model artifact更新后立即运行③ 手动触发debug用流程从S3拉取最新model artifact和prompt bundle在隔离K8s namespace启动eval pod资源限制4CPU/16GB防拖垮集群并行执行所有eval用例结果写入TimescaleDB生成HTML报告自动上传至内部Wiki若关键指标Factuality/Latency跌破阈值触发Slack告警并创建Jira ticket。组件3归因分析引擎Attribution Analyzer当eval失败时自动关联失败用例的Git commit hash对应的model artifact sha256运行时的prompt版本号tool contract的OpenAPI spec版本输出归因报告med-00127失败原因tool contract v2.3中drug_interactions字段类型从string改为array但prompt v1.7仍按string解析导致JSON解析失败这让我们从“哪个模型坏了”进化到“哪个契约变更引发连锁故障”。这套pipeline让eval从季度性活动变成日常呼吸。工程师提交代码时CI会显示“本次变更影响37个eval用例其中2个预期失败已标记为known issue1个新增失败需修复”。质量不再靠人盯而靠系统免疫。5. Anthropic生态实践不是“调用API”而是构建可信协作体5.1 “Unable to connect to Anthropic services”背后的架构真相搜索热词中高频出现的unable to connect to anthropic services failed to connect to api.anthropic.com表面是网络问题实则是AI Native架构的照妖镜。我们排查过137次同类故障发现92%的根本原因与网络无关真相1DNS劫持与TLS证书链断裂Anthropic API要求SNIServer Name Indication严格匹配api.anthropic.com。某些企业防火墙会重写SNI为*.anthropic.com导致TLS握手失败。解决方案不是换网络而是在客户端强制指定SNI// Rust reqwest配置示例 let client reqwest::Client::builder() .use_preconfigured_tls(tls) .add_root_certificate(cert) // 加载Anthropic根证书 .build()?; // 关键手动设置Host头和SNI let request Request::new(reqwest::Method::POST, url) .header(Host, api.anthropic.com) .header(User-Agent, AI-Native-Agent/1.0);真相2Rate Limiting的隐性陷阱Anthropic的速率限制是“每分钟请求数每分钟token数”双维度。很多团队只监控request count忽略token消耗。当批量处理长文档时即使QPS10token消耗可能瞬间触达limit返回429错误。我们的解法是在接入层Envoy配置两级限流# 第一级按IP限QPS rate_limits: - actions: - remote_address: {} # 第二级按token消耗限流需自定义filter在客户端实现token预估对输入文本做粗略token计数len(text)/4当预估token80% limit时自动切分请求。真相3Model Route的路由漂移错误信息doesnt look like an anthropic model: expected a gateway model route reference暴露了更深层问题Anthropic的模型路由是动态的。claude-3-haiku-20240307可能被路由到不同物理集群而集群间存在微小API差异。我们的应对策略永远不硬编码model ID而是通过/v1/models端点动态获取可用model列表在服务启动时缓存model路由映射并设置5分钟刷新当收到路由错误时自动回退到上一版本model如claude-3-haiku-20240101。这些不是“运维技巧”而是AI Native团队必须内化的基础设施认知。当你把Anthropic当作黑盒API调用时故障就是随机事件当你把它当作需协同演化的伙伴时故障就是架构优化的信号灯。5.2 构建可信协作体的三大实践与Anthropic协作不是单向调用而是双向契约。我们建立了三个实践确保协作可信实践1模型能力指纹库Model Capability Fingerprinting每次Anthropic发布新model我们立即运行标准化能力测试长上下文稳定性输入128k token文档抽取末尾10个事实验证召回率工具调用鲁棒性发送1000次tool call请求统计schema解析失败率多语言平衡性在中/英/日/西四语种各100个query上测试Factuality。结果存入指纹库形成“能力基线”。当新model上线若某项能力下降5%自动触发告警并冻结上线。实践2渐进式迁移策略Progressive Migration Strategy绝不全量切换model。我们采用“金丝雀影子流量”双轨金丝雀1%流量走新model监控关键指标影子流量100%流量同时发送至新旧model对比输出差异diff score 0.3则告警熔断机制当新model的Latency P99 旧model 200%或Factuality下降3%自动切回旧model。实操效果某次claude-3-sonnet升级影子流量发现其对中文法律条款解析准确率下降12%避免了全量上线事故。实践3安全协作协议Secure Collaboration Protocol与Anthropic签订数据处理协议DPA明确输入数据不出境要求API endpoint位于指定区域模型输出不用于再训练在请求头中声明anthropic-beta: no-training-data审计日志保留180天供安全团队随时抽查。在客户端强制实施所有发送至Anthropic的请求必须经过本地敏感信息过滤如身份证号、银行卡号过滤规则由合规团队统一维护。这三大实践让Anthropic从“外部API”变为“可信协作者”。当api.anthropic.com返回503时我们不再慌乱排查网络而是打开指纹库查看当前model的SLA状态调出影子流量diff报告分析影响范围——这才是AI Native团队应有的从容。6. 从手册到肌肉记忆团队能力构建的实操路径6.1 四阶段能力演进路线图AI Native能力不是培训出来的而是打出来的。我们总结出团队必经的四阶段演进路径每个阶段都有明确的里程碑和退出标准阶段1生存期Survival Phase0-3个月目标跑通第一个端到端Agent验证基础链路关键动作用现成框架LangChain快速搭建demo手动收集100个真实用户query构建最小eval集部署基础监控Prometheus抓取API延迟退出标准Agent在测试环境能处理80%的常见queryeval suite通过率≥70%团队能独立复现并定位50%的线上故障。避坑提醒此阶段严禁优化性能我们曾有团队花两周优化token压缩算法结果上线后发现90%的延迟来自tool call白忙活。生存期只做一件事让系统活下来。阶段2稳定期Stability Phase3-6个月目标建立生产级可靠性故障率下降50%关键动作实施前述七道Agent验收关卡构建自动化eval pipeline制定SLA并写入SLO如“P99延迟≤2秒月度可用率≥99.5%”退出标准连续30天无P0级故障影响核心业务SLO达标率≥95%80%的故障能在15分钟内定位。实操心得稳定期最大的敌人是“技术债幻觉”。某团队认为“等项目上线再重构”结果积压37个已知bug最终用2个月时间返工。我们的铁律每个PR必须附带技术债清单且债务偿还时间不超过2个迭代周期。阶段3扩展期Expansion Phase6-12个月目标支撑多业务线复用率提升300%关键动作提炼公共能力为Platform Service如统一记忆管理Service、标准化tool registry建立Agent模板市场Template Marketplace供各业务线选用推行“平台即代码”Platform-as-Code用Terraform管理所有infra退出标准新Agent开发周期从2周缩短至3天公共Service复用率≥60%90%的infra变更通过Git PR完成。独家技巧扩展期必须设立“反模式委员会”。我们每月审查所有新Agent设计强制淘汰重复造轮子的方案。某次砍掉4个独立的天气查询Agent统一接入平台Weather Service节省了17人日/月。阶段4自治期Autonomy Phase12个月目标团队具备自我进化能力无需外部干预关键动作建立“免疫报告”驱动的自主迭代机制实施工程师轮岗制每人每季度轮换至不同Agent团队开放平台能力给业务方自助配置低代码Agent Builder退出标准70%的迭代需求由业务方自助完成技术决策会议频率下降80%新成员入职30天内能独立交付Agent。个人体会自治期不是放任不管而是把规则刻进DNA。我们最后一位新成员入职时导师只给了他三样东西Git repo地址、eval pipeline文档、以及一句口诀“先跑eval再改代码最后看SLO”。6.2 每日站会的五个必问问题能力演进需要日常仪式固化。我们坚持每日15分钟站会只问五个问题每个问题直指AI Native核心“昨天你的Agent的Intent Coverage下降了吗”不是问“有没有新功能”而是问意图覆盖是否收缩。Coverage下降意味着用户需求在流失。“Probabilistic Test新增了几个Failure Mode”Failure Mode是进步的刻度尺。新增越多说明我们越懂系统脆弱点。“Atomic Release Unit的Eval Baseline达标了吗”每次发布都是四维构件的联合验证。缺一不可少一个就不是发布。“Feedback Loop触发告警了吗”用户的“无用”点击是最诚实的裁判。告警即行动号角。“你的免疫报告今天抗体强度提升了多少”不看代码行数只看Factuality、Latency、Cost三项指标的净提升。这五个问题像心跳监测仪让AI Native从宏大叙事回归到每日呼吸。当团队能自然回答这五个问题时手册就不再是纸面文档而成了肌肉记忆。我在实际带团队过程中发现最有效的变革不是推翻旧流程而是给现有动作赋予新意义。比如原来站会问“进度如何”现在问“Intent Coverage”工程师会主动去查用户query日志原来写测试叫“保证质量”现在叫“构建免疫系统”大家会认真设计对抗样本。手册的价值正在于把抽象理念翻译成每日可执行的动作。最后分享一个小技巧我们把这五个问题印在会议室白板上每次站会前用荧光笔标出当天重点问题。三个月后不用提醒工程师自己就会在日志里标注Coverage变化——因为问题已长进他们的思维回路。
