从 Plan、Design、Build 到 Test、Deploy、Maintain，Anthropic 正在重新设计 AI 时代的产品研发流程。最新的 Playbook 也印证了一个判断：金融 AI 的胜负根本不在模型本身，而在于 AI-Native 方法论能否在真实业务里跑通。
过去两年，大模型在产品研发中的能力提升非常快。最直观的变化发生在软件工程环节：从最初的代码补全，到今天的 Claude Code、Codex 等 Coding Agent，AI 已经可以读取完整代码库、理解需求、修改代码、执行测试，甚至连续完成复杂的开发任务。
但 Anthropic 在 2026 年 8 月发布的《The AI-Native SDLC Playbook》中提出了一个更值得讨论的问题：如果“写代码”已经越来越快，为什么一款产品从需求产生到真正交付的整体研发流程，并没有同比例变快？
SDLC，即 Software Development Lifecycle，通常译为“软件开发生命周期”。不过，Anthropic 这份 Playbook 讨论的已经不只是“如何用 AI 写代码”，而是从需求产生、方案设计、构建测试，到上线和持续迭代的一整套产品研发流程。传统 SDLC 通常包含 Plan、Design、Build、Test、Deploy、Maintain 六个环节，也就是规划、设计、构建、测试、发布和运维。Anthropic 的核心判断是，当 AI 大幅压缩 Build——真正写代码——所需要的时间以后，瓶颈会开始向代码之外转移。
需求仍在开会讨论，设计仍在不同部门之间传递，测试仍需要排队，审批仍按原来的节奏进行，系统出了问题仍需要人工发现、排查和重新立项。于是可能出现一种反差：AI 几个小时就能完成大量编码工作，但一个需求从产生到真正上线，依然需要几周。
因此，这份 Playbook 真正讨论的并不是“怎样让 Claude 写更多代码”，而是一个更大的问题：当 Agent 已经可以承担越来越多执行工作以后，原来围绕“人执行”设计的整个工作流程，是否也需要重新设计？
所以，与其把这份报告看成一份面向程序员的 AI Coding 指南，不如把它理解为 Anthropic 对 AI 时代产品研发方式的一次系统性重构。更进一步，如果把“代码”替换成研究报告、投资尽调、风险分析、投后报告等专业成果，会发现很多知识工作正在面对相似的问题。真正值得讨论的，已经不是 AI 能不能帮我们完成某一个步骤，而是当 AI 进入真实业务流程以后，整个工作的组织方式会发生什么变化。
代码变快之后，瓶颈去了哪里？
传统的软件研发流程，本质上是在一个“代码昂贵”的时代形成的。过去，一项复杂的软件需求可能需要几周甚至几个月开发，因此围绕开发建立大量管理机制是合理的：产品经理写需求，团队进行评审，技术人员给出排期，开发完成后交给测试，再经过安全、合规和发布审批，最终上线。因为真正写代码本身很慢，所以前后多花几天沟通，并不会显著改变整个项目周期。
Coding Agent 改变了这个前提。Anthropic 在报告中指出，首先，瓶颈开始向 Build 两侧移动。代码可以快速生成，但 Plan、Test、Review、Deploy 等环节仍然按照人的速度运行。其次，原来的控制机制开始承受压力。过去人工逐行 Review 代码是可行的，因为代码本身也是人逐行写出来的；当 Agent 能快速生成大量代码以后，如果所有检查仍完全依赖人工，审核很快就会成为新的堵点。
更进一步，如果每个异常仍必须进入会议、审批委员会和跨部门确认，AI 甚至可能只是把更多工作更快地推到这些节点前面。
因此，AI-Native SDLC 的关键并不是简单地让 AI 接管产品研发的六个环节，而是重新思考：哪些工作适合 Agent 承担，哪些可以交给确定性程序自动完成，哪些真正需要人的判断。带着这个问题，再看 Anthropic 对六个阶段的重新设计，会清晰很多。
01 Plan：从“写需求”变成“捕获意图”
Anthropic 对第一个环节的改造看起来并不复杂：它提出用一个 intent.md 来记录任务意图。不要被这个技术名字吓到，它本质上是一份简洁的“任务意图说明”，重点不是把需求写得多正式，而是把最初的问题、目标、约束和仍未解决的问题保存下来。
传统流程中，一个业务人员有了想法，往往要经过“业务提出想法—产品经理理解—写成需求—多轮沟通—研发再次理解”的链条。每一次交接都可能发生信息损失。Anthropic 提出的方式，是让最初提出问题的人直接与 AI 讨论：当前到底存在什么问题，希望得到什么结果，谁会受到影响，有哪些明确约束，还有哪些问题没有答案。AI 可以继续追问、补充遗漏，再把这些内容整理成结构化的 Intent。
这里有一个非常重要的边界：AI 可以帮助整理 Intent，但最终仍由提出者或负责人确认。Anthropic 并没有把“需求到底是什么”这件事交给模型决定。AI 的作用，是降低表达和交接成本，让下一阶段能够直接基于已经确认的意图继续工作。
为什么 Agent 越强，Intent 反而越重要？因为执行成本下降之后，“快速把错误的事情做完”可能比“做得慢”更加危险。过去一个需求理解错了，可能两周以后才发现；现在 Agent 可能几个小时就把错误方向完整实现出来。
同样的问题也存在于金融业务中。用户说“帮我分析一下这家公司”，其实并不是一个完整任务。他可能只是第一次接触这个项目，希望快速形成公司 360° 画像；也可能已经准备立项，希望进行一次 PreDD（投前初步尽调），重点判断行业空间、技术壁垒、融资能力、可比估值和核心风险；还可能已经进入正式尽调，需要围绕此前发现的问题继续深挖。表面上都叫“分析公司”，但三种任务需要的数据、分析深度、工作路径和最终交付物完全不同。
执中基于“数据+业务模型+AI 技术”融合的核心能力构建的金融垂类 AI 应用——欧拉 Euler，在处理这类任务时也会先区分用户处于什么业务场景、真正希望回答什么问题、这次工作的边界在哪里、最终需要交付什么。明确这些问题以后，Agent 才应该决定后续调用哪些能力。这与 intent.md 背后的思想非常接近：AI 不应该从一句模糊指令直接冲向结果，而应该先理解这项工作真正要完成什么。
02 Design：把专业规则前置，而不是最后再检查
Intent 明确以后，Anthropic 进入 Design 阶段。传统流程中，业务需求、产品设计、安全检查、合规要求常常分散在不同环节，于是经常出现一种情况：一个方案已经设计甚至开发得差不多了，才发现违反某项规则，只能返工。
AI-Native 的思路，是让 Agent 在形成方案时，就能够读取组织已有的专业规则，例如品牌规范、安全规范、合规要求和 UX 设计规则，再基于上一阶段的 intent.md 形成更完整的 spec.md。
这里出现了一个重要概念：Skill。很多人第一次接触 Agent 时，会把 Skill 理解成一个“更复杂的 Prompt”，但二者并不完全相同。Prompt 更像“这一次你希望 AI 做什么”，Skill 更接近“面对这一类专业任务，我们通常按照什么方法工作”。
以行业研究为例，如果只是告诉大模型“请以资深投资人的视角深度分析一下这个行业”，模型当然也可以生成一份看起来不错的报告，但每次分析的框架、深度和判断标准都可能不同，更重要的是，它未必真正继承了一个专业研究团队长期积累的方法论。
例如在设计“行业赛道研究”这类 Skill 时，可以把相对完整的行业分析拆解为十个核心模块：行业定义与边界、生命周期与发展阶段、产业链结构与价值分配、竞争格局与市场集中度、商业模式与盈利逻辑、市场规模与增长空间、成长驱动因素、核心壁垒与护城河、风险与不确定性，以及财务分析与估值框架。
但专业方法并不是简单的“十项检查清单”。研究人形机器人这样的技术驱动型行业，逻辑可能更适合按照“发展阶段—技术路线—供给能力—下游应用—商业模式—市场空间”展开；面对需求已经相对成熟的行业，则可能更接近“需求—周期—供需—产品与竞争—商业模式—市场空间”。也就是说，Skill 真正需要沉淀的，不只是“分析哪些内容”，还包括这些内容之间如何组织、什么情况下应该采用什么分析逻辑。
过去，这些 Know-how 可能散落在资深研究员的经验、券商研报、研究模板和内部方法论中。Skill 所做的一件重要事情，就是把原来主要存在于“人脑”和文档里的专业方法，逐步转化为 Agent 可以理解和执行的工作方法。Anthropic 在 Playbook 中强调的 Institutional Knowledge——组织知识——变得可被 Agent 调用，核心也是这个方向。
所以，真正值得关注的并不是再写一个更长的 Prompt，而是一个组织能否把自己长期积累的方法、规则和工作经验，逐步沉淀成 AI 可以调用、执行并持续迭代的能力。
欧拉在这件事上的做法，是把行业定义与边界、产业链结构、竞争格局、市场规模口径、核心壁垒这些环节固化成一套可调用的分析方法——研究人形机器人和研究一个需求成熟的行业，用的分析逻辑并不相同；用户只需把任务讲清楚，Agent 会自己完成编排。它要沉淀的不是更长的提示词，而是执中在金融业务里长期形成的判断标准。
03 Build：真正的变化不是“AI 写代码”，而是“AI 按计划执行”
到第三阶段 Build，终于进入大家最熟悉的 AI Coding。但 Anthropic 并没有建议用户拿着需求直接让 Claude 开始写代码，而是强调 PlanMode：先让 Agent 研究现有系统，形成明确的 plan.md，说明准备修改哪些地方、按照什么顺序做、可能有哪些风险，以及最后用什么方法证明任务完成。
更关键的是，Plan 阶段不直接修改代码。工程师首先 Review 的不是最终生成的几百行代码，而是 Agent 准备怎么做。这个变化把人的判断位置向前移动了：过去更接近“研发先干，干完以后 Review”，AI 原生方式则更接近“Agent 先理解并形成计划，人确认关键方向，然后 Agent 大规模执行”。修改计划的成本很低，如果最终成果已经生成完才发现方向错误，返工成本就会明显提高。
Anthropic 在 Build 阶段还强调了 CLAUDE.md。它可以理解为一份长期有效的“项目工作说明书”，记录项目如何启动、如何测试、目录如何组织、哪些模块不能随意修改、团队有哪些长期约定。值得注意的是，Anthropic 反而建议这类文件尽可能短，因为 Agent 每次都要读取它。过期信息、冗余规则和大量无关内容不仅没有帮助，还会占用上下文并干扰判断。
这背后对应的是今天越来越重要的 Context Engineering——上下文工程。AI 并不是“知道越多越好”，而是在正确的时候拿到正确的信息。哪些规则应该长期存在，哪些专业知识只在特定任务中调用，哪些事实应该实时查询，需要被分别管理。
MCP：让 Agent 从“知道怎么做”走向“真的完成工作”
有了任务计划和专业方法，Agent 接下来还面临一个现实问题：它拿什么完成这项工作？这就涉及今天 Agent 领域经常提到的 MCP。可以简单理解为，大模型负责理解和推理，Skill 告诉它一类专业工作应该按照什么方法完成，而 MCP 等工具让它能够真正访问外部的数据、模型和业务系统。
如果 Skill 回答的是“这项工作应该怎么做”，那么 MCP 更接近“完成这项工作时，我能够调用什么”。这两者组合以后，Agent 才开始从一个“会回答问题的模型”，变成一个“能够组织资源完成工作的系统”。
还是以金融业务为例。假设一名投资经理提出：“帮我对这家公司做一个 PreDD。”真正的 PreDD 显然不是让大模型搜索几篇网页，然后生成一份看起来完整的报告。一项相对完整的任务，可能需要建立公司画像和股权结构，判断企业所处行业和产业链位置，研究市场空间与增长驱动力，分析技术壁垒和专利布局，梳理历史融资和融资能力，寻找可比公司并建立估值参照，再核查司法和知识产权风险，最终形成投资逻辑、核心风险和后续建议。
这时就会发现，一项专业任务的完成已经远远超出了“大模型回答一个问题”的范畴。它可能需要读取工商和股权数据，查询产业链和赛道信息，阅读券商研报，分析专利，调用融资模型，进行机构匹配，查询上市公司财务和估值数据，再核查风险事件。而且这些数据不能只是“找到了”，还需要按照前面定义的专业方法，被组织进同一条工作链中。
例如市场规模可能存在多个不同口径，Agent 不能简单挑一个最大的数字，而需要解释产业规模、行业收入和下游经济价值之间为什么不同；寻找可比公司时，也不能仅凭“公司看起来相似”，而应该先明确比较口径，再区分直接竞品、相邻赛道、技术平台型公司等不同类型；最终形成 SWOT 时，也不能凭模型重新发挥，每一项优势、劣势、机会和威胁都应该能够回到前面的事实和分析。
从这个角度看，真正的企业 Agent 越来越像一个工作系统：模型负责理解和推理，Skill 提供专业方法，数据提供事实依据，MCP 和其他工具连接真实世界，而 Agent 负责根据当前任务把这些能力组织起来。MCP 的价值也不仅仅是“给大模型接几个 API”，真正重要的是 Agent 能否在正确的业务步骤调用正确的数据和工具，并把返回结果继续用于后续判断。
执中 MCP 把金融数据封装成 Agent 可以直接调用的能力：从机构 LP、基金、GP、基金管理人一路到项目公司，各级主体之间可以互相穿透；LP 出资、投融资、并购、IPO、减持、S 交易这些事件沿着资金链条串在一起。Agent 接上以后，不需要自己拼接口、自己猜字段，数据会按业务步骤被调取。这也正是前面那句话的意思：MCP 的价值不在接口本身，而在于让正确的数据出现在正确的步骤上。
做到这一步，AI 才开始从“生成内容”走向“完成工作”。但 Anthropic 的 Playbook 接下来马上进入另一个更加关键的问题：当 Agent 已经能够完成如此复杂的工作以后，我们怎么知道它做对了？
04 Test：从“AI 说完成了”到“拿出证据证明完成了”
这是整份 Playbook 中非常值得关注的一部分。Anthropic 提出的第一个原则非常直接：不要让 Agent 自己说“我完成了”，而要让它拿出证据。开发完成以后，要真正执行 Build、真正运行 Test 和 Lint；如果是界面任务，就真正打开页面、查看结果，必要时用截图与设计要求比较。
Anthropic 还给出了一个很有代表性的做法：如果是在修复 Bug，可以先把这个 Bug 写成一个会失败的测试，确认测试确实失败以后，再让 Claude 修改代码，同时不允许 Agent 为了让结果通过而擅自修改这个测试。这样，当测试最终通过时，才形成一个更可靠的证明——不是 Agent 把标准改了，而是它真的把问题解决了。
这背后是一个非常重要的 Agent 原则：“AI 认为自己完成了”与“任务真的完成了”，是两件不同的事。
Evals：测试的不只是一次结果，而是整套 Agent 能力
Anthropic 进一步引入了 Agent 领域越来越重要的概念：Eval，评测。传统软件测试往往是输入 A 应该得到结果 B，但 Agent 是一个更复杂的系统。模型、Prompt、Skill、上下文、工具、底层数据乃至工具返回格式发生变化，都可能影响最终表现。
因此，Anthropic 建议从真实工作中选择一批有代表性的任务，形成一套长期 Eval。当模型、Skill、Hook 等 Agent 配置发生变化以后，就重新运行这批任务，观察整体表现有没有提升或退化。报告给出的一个实用起点，是从近期真实工作中收集约 20～50 个任务，明确什么样的结果可以接受，再持续测试。
这件事放到专业知识工作中会更加具体。仍以“行业赛道研究”Skill 为例，如果升级了这套 Skill，仅仅比较“新版本报告是不是写得更长、排版是不是更漂亮”，其实没有太大意义。真正需要评测的是它背后的专业能力有没有提升。
可以准备一批来自不同类型行业的真实任务，例如分析低空经济行业、研究人形机器人赛道、判断某成熟行业未来几年的增长空间，或者分析某产业链中最具价值量和利润弹性的环节。每次 Skill、模型或数据链路升级以后，再持续检查一系列更具体的问题：行业边界有没有定义准确？有没有把产业规模、行业收入、下游经济价值等不同口径混在一起？产业链是否真正识别出了价值高地，而不是简单罗列上下游？竞争格局是否给出了市场份额、CR3、CR5 等可以验证的依据？市场规模预测背后的假设是否明确？成长驱动因素有没有形成“触发因素—中间变量—影响环节—兑现时间”的传导链？所谓核心壁垒究竟有数据支持，还是只是泛泛而谈？
这时，Eval 评估的就不再是“AI 能不能生成一份行业报告”，而是：这套 Agent 能不能按照一套稳定的专业研究方法，对不同类型的行业持续给出合格的研究结果？
这里也能看出 Agent Eval 与传统软件测试的差异。有些问题可以确定性判断，例如某个关键模块是否遗漏、引用的数据是否真实存在、市场规模计算是否前后一致、CR5 是否计算正确；但另一些问题需要专业判断，例如产业链中真正的价值高地识别得是否合理，某项技术到底是不是行业发展的核心瓶颈，某个增长驱动究竟属于短期催化还是长期结构性变化。
因此，一个成熟的 Eval 往往不是简单的“正确/错误”，而可能同时包含程序校验、数据事实核验、规则检查、模型评分和专业人员抽样判断。如果保留一批经过专业人员确认的研究案例，每次模型、Skill、数据源或者 Agent 工作流变化以后都重新运行，就可以回答一个关键问题：这次升级究竟是真的提升了研究能力，还是只是让模型“看起来更会写了”？
进入 Agent 时代以后，Eval 很可能会成为企业 AI 系统的一项基础设施。它评估的不是一次回答漂不漂亮，而是整套系统能不能持续、稳定地完成专业工作。
这里还有一个前提容易被跳过：要核验一个数字是否真实存在，前提是有一份可以对得上的底稿。欧拉的报告里，一个数字、一组对标、一次风险提示之所以能够回到具体来源，靠的是执中在主体、事件、并购、司法、专利、产业链这些维度上长期结构化留存的数据。这和前面说的 Artifact 是同一种思路：结论要能回溯，前提是事实本身可以核对。
05 Deploy：不是取消人工，而是重新设计“人应该出现在哪里”
到第五阶段 Deploy，Anthropic 开始讨论一个更敏感的问题：如果 AI 已经可以规划、写代码、测试和 Review，那么人还需要做什么？
Anthropic 的答案并不是把人移出流程。相反，它提出的是把人的注意力从大量低价值检查，移动到真正需要判断的地方。比如传统 Code Review 需要工程师阅读大量代码；在 AI-Native SDLC 中，可以先让 Agent 从逻辑错误、安全风险、是否符合原需求、是否符合实现计划、是否违反组织政策等不同维度进行检查，再把真正重要的问题交给人。
人的核心任务因此可能从“这几百行代码到底写了什么”，逐渐转向“它是不是做了我们真正想做的事”“这个风险是否可以接受”。
这对业务人员其实更容易理解。以一项投资研究为例，AI 可以完成资料收集、事实核验、结构化分析、模型计算，甚至形成一套相对完整的投资逻辑，但“是否投资”并不因此自动变成一个应该完全交给模型的动作。AI 可以把判断所需的信息和分析准备得更充分，人则把注意力集中到真正需要承担责任的专业决策上。
Skill 是指导，权限才是真正的边界
这一阶段还有一个非常重要的观点：告诉 Agent“不能做什么”，和让系统“真的不能做什么”，不是一回事。
例如可以在 Skill 或 Prompt 里告诉 Agent：“不允许修改生产环境”“敏感操作必须先征得批准”。这些指令有价值，但模型仍然可能误解或犯错。因此，对必须执行的规则，还需要权限系统、Hook、Sandbox 等程序机制进行约束。
可以把它理解成一个很直观的区别：Skill 更像“制度培训”，权限系统更像“门禁”。告诉一个员工“你不能进入金库”，和他的门禁卡从系统层面根本打不开金库，并不是同一种控制。
Anthropic 因此强调，Agent 可以自动执行大量工作，但越接近生产环境和高风险操作，权限越应该收紧。真正进入 Production Gate 之前，需要明确授权；Agent 使用的凭证也应该尽可能短期、范围受限，并根据不同环境设置不同权限。
这揭示了 AI-Native 一个经常被误解的地方：它并不意味着“无限自治”。更准确地说，是在边界清晰、验证充分的区域不断扩大自动化，在关键判断和高风险节点上保留确定的人类责任。
06 Maintain：真正的 Agent，不应该做完一次任务就结束
传统软件运维通常是这样的：系统上线，监控发现问题，触发报警，有人看到报警，工程师开始排查，创建 Bug，再重新进入开发流程。
Anthropic 希望进一步把这件事闭环。系统监控发现错误率上升、某项指标偏离正常区间或测试失败率异常后，可以触发 Agent。Agent 读取日志和相关信息，进行诊断，形成新的 Intent，再重新进入 Plan、Design、Build、Test、Deploy。这样，运维不再只是研发流程的最后一步，而开始成为下一轮产品迭代的输入。
但这里有一个特别值得注意的设计：Anthropic 并没有主张让 AI 自己判断“一切是不是异常”。对于能够明确量化的异常，优先使用确定性程序进行监测；只有当指标达到阈值、真正需要理解和推理时，再调用模型分析原因和下一步动作。
也就是说，程序更适合回答“有没有发生异常”，AI 更适合回答“为什么发生异常、接下来应该怎么办”。这是一种很重要的 Agent 工程思想：能用确定性程序可靠解决的事情，不一定非要交给大模型；真正需要模型的，是那些涉及语义理解、复杂推理和开放判断的部分。
同样，“形成反馈闭环”也不等于模型会自动学习。把一次失败写进日志，只是留下记录。要让下一次执行真的变好，还需要把经验转化成新的测试、修订后的 Skill、工具修复、数据治理或权限规则，再重新验证这些改变是否有效。
六个阶段串起来，Anthropic 真正在设计什么？
如果只看局部，会看到很多技术名词：intent.md、spec.md、plan.md、CLAUDE.md、Skill、Eval、Hook、MCP、CI/CD……但把整个 Playbook 拉远一点看，会发现 Anthropic 实际上在设计一件更大的事情。
传统产品研发是一条高度依赖人工推动的链条：需求—设计—开发—测试—发布—运维。AI-Native SDLC 则逐渐变成：意图—结构化任务—专业规则—Agent 执行—自动验证—风险判断—执行—反馈—新意图。
更重要的是，每一步都会留下下一步可以继续读取和使用的 Artifact——工作成果。intent.md 保存最初的目标，spec.md 保存设计要求，plan.md 保存执行计划，代码 Diff 记录实际改变，测试结果记录验证证据，Review 记录保留审查过程，Incident Record 记录上线后的问题。这些 Artifact 串在一起，本身就是一条完整的工作轨迹：为什么做、准备怎么做、实际做了什么、依据什么判断做对了、谁批准了关键动作、出了问题以后如何回溯。
所以，AI 原生并不是把原来的流程全部删除，而是让原来大量依赖“人在脑子里记住、人在会议里传递、人在不同系统里手工推动”的工作，逐渐变成机器和人都能够理解、继续执行和验证的工作链。
从产品研发再往前一步：这套思想可能不仅属于 Coding
这也是读完整份 Playbook 后最值得进一步思考的地方。Anthropic 的起点是软件工程，但它展示的已经是一套更广泛的 AI 产品研发方法。如果再把“代码”替换成其他专业成果，会发现很多知识工作都有相似结构。
例如一次投资尽调：有人提出任务，明确投资场景，搜集企业和行业数据，按照专业方法分析，调用不同的数据和模型，生成报告，核验事实，识别风险，交由投资经理判断，再进入后续业务流程并持续跟踪企业变化。它与 Plan、Design、Build、Test、Deploy、Maintain 并不完全一一对应，但背后的组织逻辑非常接近。
从这个角度看，一个真正能够工作的金融 Agent，也很难只靠“大模型更聪明”来解释。模型负责理解和推理，金融与实体经济数据提供真实世界的信息，MCP 等工具让 Agent 能够获取数据和调用系统，Skills 把投资、尽调、估值、产业研究等专业 Know-how 转化为可执行的方法，Agent 负责根据任务组织这些能力，而验证、权限、流程和反馈机制决定这些能力能否真正进入专业工作。
这也是欧拉在做的事。它要交付的不是一段回答，而是报告、估值、匹配结果这类可以直接使用的成果。但更重要的是，Anthropic 这份 Playbook 给出了一个跨行业都值得参考的框架：真正的企业 Agent，最终比拼的可能并不只是一次回答有多聪明，而是一整套系统能否在明确边界内持续完成工作，并且让结果可验证、过程可追溯、风险可控制。
一个具体的场景是一次 PreDD。它并不是从“先搜几篇资料”开始：读懂 BP、研究行业与产业链、寻找可比公司、估值、投前尽调、核查司法与知识产权风险，这些环节在欧拉里按一条相对固定的顺序展开，前一步的结果直接成为下一步的输入。模型负责给出线索和依据，投资经理把注意力留在“这家公司值不值得投”这个判断上——被压缩的往往不是研究本身，而是环节之间的等待和搬运。类似的工作过去通常需要几个人分工、历时数周，过程散落在不同文件里；现在一条链路跑完，每一步仍然可以回查。
最后：AI Native 真正改变的，可能不是“谁来干活”
Anthropic 在这份 Playbook 中始终保留了一个重要前提：需要判断的决策，人仍然承担责任。
所以 AI-Native SDLC 并不是过去产品研发的六个环节由不同角色完成，以后全部交给 Claude。真正发生变化的，是人、Agent 与确定性系统之间的工作边界正在被重新划分。
AI 更适合承担信息整理、方案生成、重复执行、工具调用、大规模初步审查和复杂信息分析；确定性程序更适合承担权限控制、规则校验、阈值监测、身份验证和强制阻断；而人的注意力，则应该逐渐集中到目标是否正确、判断是否合理、风险是否可以接受，以及最终是否应该采取行动。
如果说上一阶段的 AI 应用主要是在回答“AI 能帮我们做什么”，那么 Anthropic 这份《The AI-Native SDLC Playbook》真正开始回答的是另一个问题：当 AI 已经能够工作以后，一个组织应该怎样重新设计“工作本身”？
这或许才是 Agent 从工具走向真正生产力系统时，最值得关注的一步。
参考资料：Anthropic, “The AI-Native SDLC Playbook”, 2026-08-21. https://claude.com/blog/the-ai-native-sdlc-playbook
发表于 4 天前
|
查看: 14|
回复: 0
