编者摘要：阿里、Anthropic、OpenAI 三家都在搞 AI 原生研发，简单说就是不再只让 AI 帮程序员补代码，而是让智能体 Agent 完整参与做项目。

大模型写代码已经很强，但真正拖慢效率的不是写代码本身，而是读懂老业务、搭运行环境、做测试校验、权限管控、人和 AI 怎么配合这些事。

阿里AI原生研发范式手册的实践来自真实线上商业业务，手上是大量历史旧系统。包括广告投放、用户增长、协作平台三个项目，摸索出 “人定目标担责任，AI 负责干活执行”；不光搞技术，还关注怎么衡量效果、员工心态、岗位变化，解决大公司复杂权限、多团队协作难题。

Anthropic 主要做两类实践：一类是极限技术试验，比如多 AI 一起写编译器、百万行代码大迁移；另一类是公司内部日常工作，让 AI 做故障初排查。擅长多 AI 并行干活、搞测试校验，推出 MCP 通用工具协议，方便 AI 对接各类系统，但原型项目多，对企业组织、员工顾虑谈得少。

OpenAI 侧重底层机制，研究多个子 AI 怎么分工调度。提出 Harness 工程思路：AI 出问题优先改造环境工具，而不是反复改提示词。案例大多是内部技术原型。

三家共同点：不追求 AI 完全替代人；测试验证、隔离沙箱必不可少；AI 适合执行，关键判断、风险必须交给人。

核心区别：阿里重大型存量业务 + 组织配套；Anthropic 重能力上限 + 工具互通；OpenAI 重多智能体底层调度机制。落地不能迷信更强大模型，环境、验证、知识资产往往比模型更重要。

10 个关键问题问与答

Q1：AI 原生研发就是 AI 代替程序员写代码吗？ A：不是。写代码只是一小部分，重点是让 Agent 走完完整研发流程；人保留目标、业务判断和最终责任。

Q2：三家公司做 AI 原生研发最大的共识是什么？ A：不追求完全无人化；测试验证、隔离沙箱必不可少；高风险决策必须交给人。

Q3：阿里和 Anthropic 的案例最大底色差别？ A：阿里都是线上存量商业业务，要考虑营收风险；Anthropic 很多是干净环境技术原型，没有历史业务包袱。

Q4：什么是 Anthropic 的对抗评审？ A：专门安排人 / Agent 对 AI 产出找茬审查，用来降低大规模代码生成带来的隐藏 bug。

Q5：OpenAI 提出的 Harness 工程是什么白话解释？ A：AI 干活出错，优先去改环境、工具、规则，不要只会不停加长提示词哄模型。

Q6：MCP 协议能干什么？ A：相当于 Agent 的通用 USB 接口，让 AI 可以标准化对接数据库、Git、告警等各种各样外部系统。

Q7：云上 Scrum 是阿里独有的 Agent 协作模式吗？ A：是的。数字员工常驻业务域持续干活；人主要维护验证闭环、筛选高价值需求，不需要传统排期开会。

Q8：为什么大规模代码迁移就算全部测试通过，上线依然会出 bug？ A：测试很难覆盖全部真实业务边界；模型会遗漏隐性业务约束，必须人工终审观察线上表现。

Q9：阿里为什么要重点研究 “蒸馏焦虑”，另外两家公开谈得少？ A：阿里面对数万员工真实企业环境，员工担心把经验教给 AI 后自己被替代；Anthropic、OpenAI 公开案例多聚焦技术层面。

Q10：普通企业落地 AI 原生，直接照搬编译器、代码迁移这类原型案例行不行？ A：不建议。原型是理想干净环境；企业有老系统、权限、业务风险，要优先补齐环境、验证、安全护栏。

附录一 阿里 AI‑Native 研发范式 vs Anthropic、OpenAI 内部研发范式深度对比分析

基于阿里《AI‑Native 研发范式实践手册》、Anthropic Claude Code 工程公开案例、OpenAI Codex‑CLI / Multi‑Agent V2 与 Harness Engineering 公开工程实践，从内部案例、底层理念、基础设施、组织模式、共性、核心差异、落地启示完整展开Anthropic。

一、各家内部典型实践案例梳理

1、阿里巴巴：面向大型业务交付的三个真实业务案例

阿里全部案例发生在成熟大规模存量业务环境，服务对外商业产品，并非纯技术原型验证。

1. AIDC 数字投手（国际广告营销 Agent）
   面向商家广告投放业务。演进三阶段：超级个体→数字员工→云上 Scrum；架构拆解为投手经验、手脚、头脑、评测四大组件；搭建经验 Loop、手脚 Loop 两条云上供给闭环；核心模式是人定目标验收，数字员工承担执行；重点解决业务可控性、风险围栏、业务效果闭环，不是追求代码生成速度，而是解决业务策略迭代效率。
2. 千问用增 Agent（用户增长工业化运营系统）
   完整存量代码库，经历粗放探索→存量工程适配→SDLC 全流程覆盖；构建代码知识图谱、需求 Spec 沉淀、TDD 测试驱动、TraceId 线上排障；业务结果：交付周期减半、千行缺陷率‑70%、变更失败率‑90%+；工程师重心从写代码迁移到问题定义、边界约束、验证体系建设。
3. 万有无界平台（人与 Agent 企业协作平台）
   打通评审‑设计‑开发‑测试‑线上故障全链路；基于事实与证据驱动交付；设计师直接提交可运行代码分支，auto‑bugfix 自动修复成功率 89%；暴露痛点：自动修复成功率高，但任务触发、业务判断高度依赖人，bug 日清率提升有限。

阿里案例共性：业务目标优先，模型只是工具；大量存量业务、复杂权限、多团队协同、真实生产风险；产出可度量业务指标，同时暴露组织、度量、权限、知识资产等现实痛点。

2、Anthropic 内部 Claude Code 研发实践案例

Anthropic 实践分为技术原型实验 + 内部工程迁移 + CI/CD 运维自动化三类，以模型能力验证 + 工程效率提升为主Anthropic。

1. 多 Agent 并行构建 C 编译器原型
   16 个 Claude Agent 并行，2000 次会话，约 2 万美金成本，从零实现 10 万行 Rust 编写 C 编译器，可编译 Linux 内核；属于干净环境原型验证，无存量业务历史包袱，验证多 Agent 大规模协同编码上限Anthropic。
2. 大规模代码库迁移
   ①Bun 项目百万行 Zig 迁移 Rust，两周完成，CI 测试全部通过；②16.5 万行 Python 迁移 TypeScript，多阶段门控 + 多轮对抗评审；核心经验：不要只修复代码，要修复产生代码的循环（Loop），把测试、自检内置到 Agent 工作流中Claude。
3. Claude‑Tag 值班 Agent
   接管部分 CI/CD 告警，自动排查 K8s 集群问题、生成 PR 变更，人类 on‑call 做最终审核；Skill 存放在 Git 仓库，版本化管理，处理线上故障、金丝雀发布流量调控Claude。
4. 内部统计数据：截至 2026‑08，Claude 主导 26% 内部研发工作，90% 研发实现 AI 协作，3 万 Agent 并行运行；大量用于代码迁移、重构、写单测、PR 评审、数据分析；以模型公司自身代码库为主，对外业务案例更多来自外部客户36氪。

3、OpenAI Codex‑CLI / Multi‑Agent V2 内部工程实践案例

OpenAI 以Harness Engineering（智能体支架工程）为核心思想，以自研模型基础设施为主要试验场，探索子 Agent 派发、长任务、上下文压缩、人机协作模式。

• Harness Engineering 百万行代码内部实验
  3‑7 人团队历时 5 个月，核心结论：阻碍 Agent 交付往往不是模型写代码能力，而是环境规格缺失、工具不足；工程师工作从写代码转向构建 Agent 运行的支架环境；提出新的合并哲学：Agent 生成 PR 吞吐量巨大，修改成本低，等待审核成本高，适度放宽阻塞式门禁，允许后续迭代修复缺陷OpenAI。
• Multi‑Agent V2 子 Agent 调度实验
  支持父 Agent 派发不同角色子 Agent，支持角色隔离、模型选型控制、上下文 fork 策略；解决子 Agent 继承全部上下文带来的膨胀与越权问题；探索 “AI 研究实习生”，让 Agent 独立完成明确定义的研究任务；内部数据：Agent 总运行时长已经超过人类工程师工时；高层业务规划依旧由人类承担36氪。
• Ralph Wiggum Loop 闭环实践
  ：Codex‑CLI 自主修改代码、本地自测、调用子 Agent 评审、迭代直到评审通过，生成 PR 交给人类终审；自动上下文压缩解决长任务 Token 膨胀；重点面向 OpenAI 内部基础设施，对外业务场景公开案例少于阿里。

二、三家范式底层理念对比

三、基础设施体系对比

1、共性基础设施概念

三家都认同：

• Agent Harness（智能体编排框架）
  不是简单 Prompt 封装，包含上下文管理、任务规划、工具调用、状态恢复、验证纠错、人机交接闭环。
• Skill / 工作流资产化
  Agent 的能力要版本化，纳入代码仓库，可评审、可迭代，不是临时提示词片段。
• 沙箱 Sandbox 隔离执行
  Agent 不能直接操作生产环境，需要隔离运行环境，防止误操作。
• 验证优先
  不能只看生成代码，必须有自动化测试、执行反馈作为 Agent 行动输入。

2、关键差异

1. 阿里：完整企业级全栈基础设施
• 除 Harness 之外重点建设：企业知识库、MCP/Skill/CLI 工具体系、可复现 Coding 运行上下文、Agent 独立身份与 Policy、Guardrail 生产安全护栏、完整 Trajectory 全链路可观测。
• 重点解决大型企业特有问题：复杂存量业务系统、多套遗留研发平台、细粒度委托授权、大规模团队度量体系 L1/L2/L3 三层指标；OpenSandbox 开源沙箱，解决项目完整运行上下文，不止代码，还包含数据库、配置、测试基线。
• Skill 治理思路：Skill 视同业务代码，纳入 CI/CD，出 bug 需要责任人，强调大规模的管控、质量治理、可观测审计。
2. Anthropic：MCP 协议为核心，强调工具互通与 Skill 编写方法论
• 输出 MCP（Model Context Protocol）开放协议，标准化 Agent 调用外部系统；Claude Managed Agents 提供托管运行时；Skill 方法论侧重怎么写好 Skill，重点写清楚 “坑点 Gotchas”，给模型触发器描述，而不是写死步骤指令。
• 沙箱、身份更多托管在平台层；知识库更多依靠 MCP 对接外部 RAG，没有完整自研企业知识库全链路治理体系；度量更多聚焦任务成功率，没有阿里面向大规模组织的完整三层业务度量框架。
3. OpenAI：Harness 工程 + Multi‑Agent 子 Agent 调度为核心
• 重点攻克：子 Agent 派生与权限隔离、长任务上下文自动压缩、Harness 工程范式；Agent SDK 提供 handoff 任务交接机制。
• 沙箱、身份、可观测偏向模型研发内部场景；对外企业级知识库、生产 Guardrail 护栏、业务度量体系公开披露较少；Harness 强调：Agent 犯错优先改造系统机制，而不是加长 Prompt 提示词。

四、组织与人才模式对比

1. 阿里巴巴
• 现象：超级个体涌现，跨岗位能力；鼓励 3‑5 人小团队；传统产品、设计、前后端岗位边界模糊；直面蒸馏焦虑：员工把经验沉淀 Skill，担心自己被替代；提出组织需要新激励机制、新晋升通道，不能只追求裁员降本；度量体系不仅看工具使用，同时评估上下文资产沉淀；组织变革是 AI‑Native 非常关键的一环，和技术同等重要。
2. Anthropic
• Labs 小团队模式，4 人以上项目就要 “毕业” 转入正式产品团队；快速试错，大量原型快速淘汰；工程师主要学习如何写高质量 Skill、设计 Agent 自验证循环；公开讨论：Skill 和数据模型同步变更，否则会出现 Agent 准确率持续衰减；对员工蒸馏焦虑讨论公开材料较少36氪。
3. OpenAI
• 工程师角色转变：从写业务代码，转为搭建 Harness、设计 Agent 任务边界、设计工具链；接受 Agent 产出大量 PR，人的主要工作变成审核、设定门禁；重点研究 AI 研究实习生角色；公开材料对员工心理、蒸馏焦虑几乎没有讨论，更多聚焦技术实现层面OpenAI。

五、三大体系共性

1. 范式共识：从 Copilot 走向 Agentic
   全部三家都确认，单纯 IDE 内代码补全已经是过去式；真正价值来自行动‑验证‑纠错闭环；编码只是环节之一，环境、验证、工具链是更大瓶颈。
2. Harness 不是 Prompt 包装
   Harness 是运行时、状态、工具、验证、人机交接整套系统；Agent 出问题优先改造系统环境、Skill、测试，而不是无限加长 Prompt。
3. Skill 必须工程化版本管理
   Skill 不能只是聊天框临时提示词，必须纳入 Git，可评审、可迭代，把业务经验沉淀为可复用资产。
4. 人不可被完全替代
   高风险决策、业务目标、取舍判断、最终责任，必须保留给人类；Agent 聚焦确定性、可执行的执行任务。
5. 沙箱隔离是底线
   Agent 不允许直接裸奔操作生产环境；所有生产变更需要有校验、可回滚、可审计。

六、差异

1、业务场景底色不同（最本质差异）

• 阿里：存量大型商业业务为主
  案例来自对外商业产品，历史庞大代码库、复杂多团队协作、真实营收风险；要兼容大量遗留内部研发平台（如 Aone）；问题是：在已经存在的巨型企业里，如何让 Agent 安全规模化落地。
• Anthropic：以模型公司自身代码库为主，外部案例来自客户
  大量是干净环境原型、大规模代码迁移重构；MCP 面向通用外部客户打通各类工具；重点探索：Agent 能力的边界，如何让外部企业快速用上托管 Agent。
• OpenAI：主要面向自身模型基础设施做实验
  重点研究多 Agent 调度、长任务 Harness 工程；案例更多偏向技术原型与内部工具；目标是探索 Agent 软件工程的底层机制。

2、安全与生产风险的权衡取舍

• 阿里：强生产护栏 Guardrail 优先
  生产发布必须完备证据链，不可逆高风险操作强拦截；宁可牺牲部分效率，守住业务与资金风险，适合互联网大规模线上业务。
• Anthropic：最小权限、优先可逆，不确定就询问人
  ，依靠 MCP 授权体系；适合通用混合场景。
• OpenAI：Harness 层面做隔离；在内部非核心场景接受 “修复比等待便宜” 的理念，适度放宽门禁，核心生产依旧严格管控。

3、关注点侧重不同

• 阿里：技术 + 度量 + 组织三位一体。技术基础设施之外，花很大篇幅讲度量、组织文化、人才画像、激励、蒸馏焦虑；完整回答 “整个组织怎么转型”。
• Anthropic：模型能力 + 开放工具协议 MCP+Skill 方法论；更关注 “怎么把 Agent 能力交付给各行各业客户使用”。
• OpenAI：Harness 工程 + Multi‑Agent 多智能体底层机制；聚焦 Agent 运行底层技术问题。

4、Skill 治理思路差异

• 阿里：管控视角，Skill 视同业务代码，必须 CI/CD，要责任人，面向大规模企业团队治理。
• Anthropic：创作视角，教会工程师如何写出高质量 Skill，关注 Skill 的编写范式与触发器设计。
• OpenAI：运行视角，关注 Skill 在 Harness 框架下如何被调度、出错如何被系统拦截。

七、落地启示

1. 如果你的场景是大型存量商业业务，线上业务风险高，多团队协同，阿里这套体系参考价值最高：不能只关注模型编码能力，环境、验证、度量、组织、权限缺一不可。
2. 如果是原型探索、代码迁移、外部系统快速打通，Anthropic MCP、Skill 编写方法论更适合快速起步。
3. 如果重点做复杂长任务、多子 Agent 分工，OpenAI Harness Engineering 与 Multi‑Agent V2 可以借鉴，但要注意其公开案例多来自内部技术原型，直接上生产需要叠加阿里式的 Guardrail 护栏、度量、权限体系。
4. 三家共同警示：不要幻想靠更强大模型解决全部问题；Agent 生产落地最大的障碍来自环境、验证、上下文资产、组织人的协同，而非模型本身。

附录二 Anthropic‑Claude‑Code 官方公开工程案例

全部来自 Anthropic 官方工程博客、技术白皮书、对外案例发布，分为内部工程压力测试案例（在 Anthropic 公司内部开展）、内部团队日常生产案例、外部客户落地案例三大部分；同时提炼每个案例的背景、过程、关键数据、核心工程启示，并补充和阿里案例的对照要点Anthropic。

一、内部压力测试原型案例（偏向技术极限验证，非线上业务产品）

案例 1：16 个并行 Agent 从零编写 Rust 实现 C 编译器（2026‑02 官方发布）Anthropic

1. 背景
   验证多 Agent 团队协同大规模软件构建的能力；干净环境实验，Agent 全程无互联网访问。目标产出可编译 Linux 内核的 C 编译器。
2. 过程
   16 个独立 Claude Opus4.6 Agent，共用同一个 Git 仓库，依靠文件锁做任务分片协调，不存在中央总控 Agent；多会话异步并行开发；开发完成后跑 GCC Torture 测试套件、真实开源软件编译验证。
3. 关键数据
• 时长约 2 周，近 2000 次 Claude Code 会话；API 成本约 2 万美金
• 产出约 10 万行 Rust 代码；GCC torture 测试通过率 99%
• 可编译 Linux6.9 内核（x86‑64/ARM/RISC‑V）、PostgreSQL、Redis、FFmpeg、QEMU 等 150 + 项目
• 短板：没有实现完整汇编器 / 链接器，依赖 GCC 工具链；16 位实模式代码生成存在缺陷。
4. 工程启示
   Anthropic
• 多 Agent 可以异步协作大型项目，但必须配套Harness 约束：日志输出重定向至文件、减少控制台污染、错误标准化输出，否则上下文会快速膨胀失效；
• 测试集是 Agent 的 “客观裁判”；Agent 团队不适合完全无人，人类负责定义目标、验收边界。
5. 和阿里对照
   属于干净的技术原型，无历史存量包袱；阿里 3 个业务案例全部建立在几十年存量业务、遗留系统之上。

案例 2：Bun 项目百万行 Zig→Rust 大规模代码迁移（2026‑07 官方）Claude

1. 背景
   Bun 运行时（被 Anthropic 收购）原有 96 万行 Zig 代码，长期受内存泄漏困扰，人工重写成本极高；使用 Claude Code 做完整语言迁移。
2. 过程
   1）人先编写迁移规则手册 Rulebook，定义 Zig/Rust 语法、类型、内存模型映射关系； 2）数十个 Claude Agent 并行分片翻译； 3）循环执行：翻译→编译→冒烟测试→修复缺陷； 4）多轮对抗评审 Adversarial Review；合并前全量 CI 测试回归。
3. 关键数据
• 耗时 11 天，最多同时运行 64 个 Agent；提交 6502 次 commit，生成约 100 万行 Rust 代码；API 成本约 16.5 万美金。
• 合并前：原有 Bun 测试套件 100% 通过；上线后发现 19 个回归 bug，全部修复。
• 业务收益：内存泄漏大量消除，重复构建内存占用从 6745MB 下降到 609MB；二进制体积缩小 19%，HTTP 服务性能提升 2‑5%。
4. 工程启示
• 大规模代码迁移不是丢给模型直接翻译；人的核心产出是规则手册与验证 Harness；
• 自动化测试套件是大规模 Agent 重构的底线；即使全部 CI 通过，上线后依然会出现回归缺陷，不能相信 “测试全过 = 业务完全正确”。
5. 阿里对照
   阿里千问用增 Agent 同样处理存量代码库，但目标不是 “语言大迁移”，而是持续迭代业务功能；阿里更强调 Spec 需求澄清、TDD 开发；Bun 案例侧重 “一次性大规模重构”。

案例 3：16.5 万行 Python 迁移 TypeScript（Mike Krieger，Anthropic Labs）Claude

1. 背景：内部业务 Python 代码库，希望迁移 TS 获得类型安全。
2. 过程：8 个阶段门控、数百 Agent 并行，三轮对抗评审；每一轮都对比新旧版本输出行为完全对齐。
3. 关键数据：一个周末完成 165000 行代码迁移；每阶段设置门控，不达标不进入下一阶段。
4. 启示：阶段门控 + 对抗评审，是大迁移中降低风险的关键手段。

二、Anthropic 内部日常生产实践案例（真实团队工作流，Claude Tag 为载体）

案例 4：Claude‑Tag 作为 CI/CD 故障的值班第一响应人（On‑call 值班 Agent，官方 2026‑08）Claude

1. 背景
   Anthropic 内部 Slack 工作流，Claude‑Tag 作为团队共享 Agent，接入告警、代码库、CI 系统；用于处理 CI 失败、线上小故障。
2. 工作模式
   工程师在 Slack 频道 @Claude，把告警信息丢给 Agent；Agent 自动拉取日志、测试报告、代码变更，输出初步事故分析报告，给出可执行建议；高危操作不能直接执行，由人类确认后执行变更，Agent 跟踪验证结果。
3. 实例：一次 44 条测试用例消失故障。Agent 定位是 feature‑flag 开关变更导致；给出回滚建议；人类执行回滚，Agent 监控指标确认错误率回落基线。
4. 内部统计：大部分 CI 事故，Agent15 分钟内输出首版事故调查报告；产品团队约 65% 代码由内部 Claude‑Tag 参与产出。
5. 启示
• Agent 适合做故障信息收集、根因初筛、生成修复方案；执行变更、风险判断由人掌握；
• Agent 不是替代 on‑call 工程师，而是把工程师从信息搜集、日志翻阅的机械劳动释放出来。
6. 阿里对照
   千问用增 Agent 的线上排障链路（基于 TraceId 证据链）思想高度趋同；阿里会增加 Guardrail 生产护栏做硬拦截，而 Anthropic 更多依靠权限 + 人类确认。

案例 5：内部业务效率小工具批量构建（销售、市场团队）

1. 销售团队：Claude Code 读取 Salesforce、Gong 客户数据，自动生成客户定制 PPT；原本 20‑30 分钟的工作缩短到几秒。
2. 市场团队：自动读取周报数据，为每一位销售代表生成个性化每周业务简报，批量分发。
3. 特点：非纯后端开发，业务人员直接使用 Agent 完成内部工具；体现 Agent 向非开发岗位渗透。

三、外部公开客户案例（Claude Code 外部企业落地，官方 case‑study）

案例 6：加拿大阿尔伯塔省政府：大规模代码安全漏洞扫描修复（2026‑07）Anthropic

1. 背景
   政府遗留大量老旧无完整文档业务系统，需要批量做安全审计与漏洞修复。
2. 过程：使用 Claude Code（Opus+Sonnet）批量扫描；20 小时扫描 4.66 亿行代码，定位并修复安全漏洞，产出配套工具链。
3. 价值：传统人工评估需要数年，Agent 在极短时间完成初筛；政府输出白皮书供其他公共机构参考。
4. 约束：高危修改依然由人工复核；Agent 输出仅作为安全初筛。

案例 7：Medkit 医疗模拟应用（Hackathon 获奖案例）Claude

开发者使用 4 个独立 Claude Code 会话分别构建语音引擎、内容生成、3D 游戏层、核心业务；几乎全部采用语音交互；产出用于医学生模拟诊疗训练的应用。启示：多会话隔离上下文，防止上下文污染。

四、从案例提炼 Anthropic Claude‑Code 范式核心特征

1. Harness 优先于 Prompt
   大规模项目中，人的工作量主要不是写提示词，而是构建规则手册、测试套件、阶段门控、Agent 调度机制（Harness），模型只是执行引擎。
2. 并行多 Agent 是重要模式
   大量任务可以做数据分片，多个 Agent 并行执行，依靠客观测试结果做统一校验；不强制需要一个超级总控 Agent。
3. Adversarial Review 对抗评审
   专门安排 Agent 或者人去 “找茬”，对 Agent 产出做逆向审查，这是大迁移、大规模生成代码的关键质量手段。
4. MCP 协议作为统一工具层
   不硬编码大量工具，通过 MCP 标准化协议对接数据库、Git、CI、Slack；Skill、CLAUDE.md 文件用来存放项目级上下文与约束规则。
5. 边界思想：原型压力测试和真实生产要分开
   编译器、Bun 重写属于压力测试原型，不等于可以直接照搬给业务系统；真实生产中，高危动作坚持人终审。

五、对比框架，补充阿里 vs Anthropic 案例差异点

表格

六、主要共性

1. 编码只是一小部分，测试、验证、Harness 才是决定成败的核心；
2. 拒绝完全无人化，高风险业务决策、变更审批保留给人类；
3. Skill / 项目级上下文资产远比单次 Prompt 重要；
4. Agent 不能裸奔，隔离沙箱、最小权限是底线；
5. 存量代码库的最大痛点不是写代码，而是理解业务约束、回归验证。