尧图网页设计 
本文探讨了AI在理解复杂系统架构方面的局限性并提出了构建AI可理解、可推理、可验证的工程系统的方案。文章重点介绍了如何通过知识库建设、需求准入、分层知识库、渐进式披露等技术手段让AI能够完成技术方案设计。文章最后指出技术方案设计Agent是“架构师Agent”的起点通过系统化工程创新方法将架构师的系统理解与技术判断能力逐步显性化、结构化为AI赋能实现更高效的研发流程。AI 仍难以理解复杂系统架构很多团队第一次使用 AI Coding 时都会发现一个类似的问题从零做一个小系统效果往往很惊艳一旦把 AI 放进运行多年的大型系统里效果就开始不稳定。小系统里AI 能在很短时间内搭出页面、接口、数据模型、测试和部署脚本。大型复杂系统里一个看上去不复杂的需求可能涉及十几个仓库、几十个接口、若干配置中心和异步消息链路。AI 写代码本身未必慢真正慢的是它不知道该从哪里开始也不知道哪些地方绝不能动。这不是一个单纯的模型能力问题。代码生成能力已经足够强局部修改、补测试、解释调用链很多模型都做得不错。困难在于复杂系统真正重要的知识并不完整地存在于代码中。一个字段为什么不能删除某个历史分支为什么必须保留一条 MQ 消息为什么只能新增字段不能改语义某个接口为什么不能在网关层做校验某个配置为什么必须跟发布灰度一起生效——这些信息可能散落在历史方案、事故复盘、配置平台、同事经验和没有被正式记录的约定中。人类工程师靠长期参与、沟通和事故记忆补齐了这部分上下文AI 如果没有被提供这些事实只能依据局部代码做推断。所以AI 在复杂存量系统中最容易出现的错误往往不是代码语法错误也不是编译器或单测能直接发现的错误而是“局部正确、整体错误”逻辑写在了不该承担职责的服务里增加了一个看似方便的同步调用却消耗了核心链路的超时预算删掉了一段看似冗余的兼容逻辑破坏了老版本客户端或下游离线任务。以架构师的核心职能技术方案设计为例技术方案设计决定了需求应该落在哪些系统、改动应放在哪一层、哪些能力可以复用、哪些约束不能突破以及改完以后如何证明它仍然安全。AI Coding 的效率会放大方案正确性也会放大方案错误的传播速度。方向错了AI 只会更快地把错误落实成大量代码。复杂存量分布式系统有一个很大的难题AI 必须跨越业务语言、架构链路、多个服务和真实代码才能获得足够上下文来生成技术方案。很多团队目前的做法仍是由架构师或者资深工程师先完成人工方案再把确定的改动点交给 AI 编码在与集团内外和多部门同事、同行的交流中我们也观察到技术方案设计仍是人工介入最深的环节之一仍然是需要架构师强力介入的环节。白纸与旧城新系统容易存量系统困难除了系统规模以外新系统、已有系统对于AI 的挑战也差别非常大。在AI 的加持下一名研发工程师就可以用一周的时间写出类似Salesforce 的系统实现大部分基础功能。但是如果让他在已有的Salesforce 系统上做一个中等规模的AI Coding 迭代可能反而一周搞不定。这是因为新系统、老系统对AI 来讲差别也很大核心差别在于历史上下文的认知、生效方式。从零开始开发一个新系统AI 面对的是一张相对干净的“白纸”。边界可以新建模块可以新拆接口可以新定历史包袱也少。即使某些设计不够优雅后续调整的成本通常仍然可控。就相当于人一样一个订单系统让一位新同学开发往往可以几天之内看到雏形而如果让这位同学在已有的订单系统上开发往往需要几天的时间去熟悉历史代码和历史业务场景。而存量技术系统像一座运行多年的城市。路网、管线、旧建筑、临时改造和居民习惯共同决定了它今天的样子。你不能只看一条街上的建筑风格就决定把地下管线挖掉也不能只看到一个服务里的代码就断定它拥有某项业务的最终决策权。大型分布式系统至少有四类知识同时影响方案设计。第一类是业务知识。产品说“优化退款体验”“增加人群投放”“调整订单展示”这些都是业务语言。它们对应的业务对象、状态含义、边界和例外并不必然等同于代码中的类名和字段名。一个“订单”在不同团队的口语里可能是交易订单、支付单、配送单或对账单如果概念没有被消歧后续检索和设计很容易从第一步就偏离。第二类是架构知识。一个用户请求从客户端进入之后经过哪些 BFF、领域服务、下游 RPC、消息和异步任务哪些服务拥有数据主责哪些只是聚合和展示哪里允许最终一致哪里必须强一致这些决定了变更应该落在什么位置也决定了影响分析的范围。第三类是服务内部知识。单个服务中的 API 契约、领域对象、状态机、数据库、缓存、消息、定时任务、配置项和测试方式决定了“具体怎么改才安全”。仅靠临时 grepAI 可以找到一些相关文件却未必知道哪个入口是主路径哪个分支是历史兼容哪个字段会被下游消费者依赖。第四类是工程与组织知识。例如超时、重试、限流、灰度、发布、回滚、安全审批和监控规则。这些往往不改变业务代码的表面逻辑却直接决定方案能否上线、故障是否可控。从这个角度看“存量复杂系统”的困难不在于“代码太多”而在于知识彼此断裂。代码只表达了部分实现事实文档可能表达了一部分设计意图配置记录了运行时行为经验沉淀了大量没有写下来的约束。没有一套机制把它们组织起来AI 就很难从一个 PRD 走到完整的技术方案。这也是我们希望解决的痛点让“存量的大型分布式系统”不再只存在于少数人的脑中而是逐步成为 AI 可以全方位理解、进而参与方案设计、研发执行和线上排查的工程系统。尤其“技术方案设计阶段”是整个AI Coding 的核心部分是AI Coding 最重要的源头起点。在公开可见的实践中这种面向复杂存量分布式系统的端到端组合仍不常见这部分能力目前业界一直没有很好的可靠解决方案。足以证明达成这个目标确实是有难度、有挑战的但是从价值来讲又是有必要性的因此我们称之为—— 难而正确的事难而正确的事行业走到了哪里从 Spec、Harness 到系统理解我们也调研了最近2年的相关技术设计、与探索实践其实业界早就普遍意识到直接把一句自然语言需求交给 Coding Agent再期待它完成复杂研发并不是稳定的工作方式所以是持续有一些新的技术设计、技术方法论、实践产生第一条主流路线是 Spec-Driven DevelopmentGitHub Spec Kit 将流程组织为Spec → Plan → Tasks → Implement用结构化产物把需求、计划和任务串起来。Kiro 也将需求、设计、任务拆成独立文件对于复杂、陌生或高风险的需求它建议保留阶段性审阅和需求分析而不是直接进入执行。第二条路线是长程 Agent 的 HarnessAnthropic 在长程开发实验中发现只给模型一个高层目标并不足以得到生产级结果需要通过初始化、任务拆分和结构化交接让后续会话知道前面已经完成了什么、还缺什么。这解决的是长时间执行过程中的上下文连续性问题。第三条路线是 Agent-friendly RepositoryOpenAI 的实践强调给 Agent 一张地图而不是一千页说明书。短小的AGENTS.md负责路由结构化文档负责承载事实CI 和自动化检查负责发现知识陈旧、链接失效和结构漂移。这些思路和方向都很重要也和我们的实践高度一致。不过这些实践比较多的还是偏单个微服务系统内部实践对于跨复杂多系统的工业实践层面并没有给出比较理想和细节的设计。而我们希望向前一步让AI 能够完成“复杂系统理解”—— 并能够真正做到类似于人类架构师一样实现跨多系统、甚至多终端的技术方案设计、推理等。从技术方案设计Agent 开始虽然我们要做的是“架构师Agent ”但是为了避免空泛化的设计和过于发散的思考我们把决定先从架构师的核心职能之一 —— 技术方案设计开始逐步落地我们的架构师Agent。图示技术方案设计是AI Coding、乃至 7 x 24 小时的 Agentic coding 的必经之路。但是技术方案设计现在基本都是由架构师人工完成的无法摆脱架构师的脑子和能力站在业界的角度我们希望通过一种系统性的设计和落地切实帮助到我们的日常工作扩大AI 提效的Scope 和高度。同时也尽量形成可迁移的方法论或者流程以帮助到更多的团队乃至业界的工程师。我们的设计思路是系统化地让 AI 完成技术方案设计先理解需求再理解业务和系统再回源代码与配置最后给出可执行、可验证、可审计的方案。这个过程的关键不是一条更长的 Prompt而是一套持续演进的知识工程与Agent 迭代路径。由此也可以看出其中主要的几个抓手和关键点需求质量、分层知识库全面性、准确性、渐进式披露、LLM基模推理能力、技术方案产出规范。我们先从“知识库建设”开始第一步落地。知识库的系统性建设落地在之前的文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中已经系统性的讨论和设计过知识库体系在文章发布后也有很多不同部门的同学过来找我们讨论包括大家各自在知识库建设过程中遇到的一些问题比如指标衡量方式、什么样的知识库结构比较好、如何用指标衡量知识库建设效果等。因此本文会根据我们之前已发表文章中的内容以及大家关心的话题做更多进一步的细化阐述。尤其是AI 时代对于知识库建设方面很多团队天然想到的就是RAG。我倒不是不推荐RAG我们更认为知识库建设的第一层看到的不应该是RAG —— 而应该是“领域”。注引用上一篇文章的原图其中蓝色背景框部分是性价比比较高的模块适合越早投入见效越快的模块。1 知识库应该首先“对齐领域”结构化的设计5 年之前我对AI 一直有一个比喻——“能力强大的小学生”当时AI 确实很强大但是思路层面非常的懵懂经常需要复杂的提示词才能让他理解任务并理解这个任务对应在现实世界中的实际逻辑从而去更加准确的完成人类交给的任务。而最近1年多的大模型迭代让我们看到了非常不一样的能力就是基模能力越来越强我现在已经很愿意把AI 基模形容为“能力强大的大学生”了—— 对物理世界、人类需要的数字世界、各种商业逻辑、互联网业务逻辑等都有了比较强的内化性理解。但无论是小学生还是大学生我对团队同学提的建议是 把AI 当做一名刚毕业的很聪明的实习生来引导指导它的工作。虽然当前主流的大模型采用的 Transformer 架构和人脑神经思考反馈机制差异很大。但是从实践层面来看其推理结果和原始输入是有非常大的强相关性的 —— 原始输入越精确得到的结论越精确、且越高效。这和人类的认知、思考模式的习惯也比较类似。如果我们新入职的实习生同学最快引导其工作的方式应该也是给到他一个结构性比较强的文档层层递进的熟悉和了解自己的工作而不是丢给他一个文档库让他自己去检索。人类架构师对于技术系统的设计是有很成熟的类似DDD领域驱动设计这样的方法论的。所以我们的架构应该天然是有领域边界的天然是“面向领域强结构化”的。同样为了提高AI 对于业务、系统的理解效率 我也强烈推荐让AI 理解这种“强结构化的领域知识”而不是给AI 一个知识库让它自己搜。2 反直觉设计为什么不首推 RAG讨论知识库时很多人的第一反应是 RAG把历史 PRD、技术方案、会议纪要、接口文档、复盘和 Wiki 都放进向量库需要时检索 Top K 片段交给模型。RAG 很有用但它不应该是复杂系统知识建设的第一选择。原因很简单检索解决的是“从资料中找出可能相关内容”并不天然解决“AI 是否已经拿到了做出完整工程判断所需的知识集合”。当数千篇非结构化文档进入同一个索引时常见的问题会同时出现。首先是颗粒度不一致一篇完整方案、一次会议纪要、一段接口说明、一个事故复盘里的截图说明都可能成为检索单元。它们的知识密度差异很大。一个命中的片段看起来相关并不代表它涵盖了这个问题真正重要的边界。其次是语义相似不等于工程相关用户说“订单取消”检索可能找到退款、履约、营销、风控中的大量相似描述却不一定找到“状态机不可跳转”“某个 Topic 仍有历史消费者”“这个接口只有聚合服务可以调用”这类决定方案正确性的约束。再次是 Top K 的完整性、结构性没有保证RAG 很容易返回若干看起来相关的文档但这些文档可能来自不同时间、不同业务范围甚至互相矛盾。模型拿到的是一些碎片而不是一条完整链路。上下文越来越长注意力却没有更集中推理效率反而下降。所以RAG 的问题不在于“召回不够多”而在于它很难独立承担知识建模的职责。把大量低结构、低密度、碎片化资料统一检索得到的经常是一座更容易搜索、但依然杂乱的文档仓库。这里对应的第一性原理思考就是知识是有结构的更适合被结构化的索引和理解。信息比如新闻类内容是结构化松散的更适合被平行/平铺化检索。3 “蒸馏架构师的大脑” —— 业务知识库的建设在上一篇文章中对于“业务知识库”结构我们给出了如下这种结构设计。也有很多同学来找我们问如何实现这个知识库效果如何等等。business/├── index.md├── meta/│ └── index.md├── principle/│ ├── index.md│ ├── timeout.md│ ├── idempotency.md│ ├── consistency.md│ ├── degradation.md│ └── compatibility.md├── scenario/│ ├── index.md│ └── scenario-*.md├── reference/ #关联、引用内容├── practice/│ ├── index.md│ └── practice-*.md└── history/└── history-YYYYMMDD.md其实这层知识库的主要目标是“把架构师脑子里的隐性知识挖出来”—— 从而尽量摆脱“技术方案必须依赖架构师的隐形知识才能产出”的魔咒—— 让AI 对人的依赖进一步降低进而更快的迈向 7 x 24 小时的 Agentic Coding 和交付。所以从这一点来讲就是把架构师大脑中的知识蒸馏出来形成文档。而为了实现这个目标我们开发了新的 skillbusiness-knowledge-distill这个 skill 是专门用来根据比如技术方案设计文档、技术稳定性体系梳理串讲文档等进行蒸馏梳理成强结构化的business-knowledge的。同时因为很多文档中有“交互图”这个skill 也会下载并分析对应的图片内容一起转为结构化的业务知识库从实际生成效果来看还是非常赞的尤其在技术方案设计阶段发挥了很大作用。以高德的实时公交业务为例我们一次蒸馏后形成的业务知识库如下文件内详细内容暂不展开。.├── evidence│ └── images│ ├── b5bebae4a0aba2c0a551.png│ ├── be6c21dc82612f040f2f.png│ ├── d05045ed77ba108686e8.png│ └── image-manifest.json├── history│ └── history-20260817.md├── index.md├── meta│ ├── departure-timetable.md│ ├── index.md│ ├── line-and-station.md│ ├── nearby-recommendation.md│ ├── realtime-bus-info.md│ └── service-roles.md├── practice│ ├── capacity-planning.md│ ├── index.md│ ├── scheduled-tasks.md│scenario从用户或业务场景映射到 API、服务、数据、消息、异常和补偿practice历史决策、事故教训、兼容原因和可复用模式reference与其他领域的关系和契约不复制对方领域的完整知识。这样的结构不是为了让目录看起来整齐而是为了让 AI 在处理需求时有确定的阅读路径。先读元语避免概念混淆再读场景确定业务如何落到技术系统遇到一致性、兼容或降级问题时回到领域原则需要理解历史原因时再查实践。换个角度看固定结构提供的是“知识覆盖约束”。它告诉 AI解决一个业务问题至少要理解哪些方面而 RAG 只能告诉 AI这里有一些可能相关的资料。这并不意味着放弃 RAG。RAG 很适合做长尾资料发现、历史文档定位、开放式问答和证据补充。当固定结构知识库缺少某个细节时可以通过 KBase 等检索能力找到原始文档、历史方案或复盘再把经过确认的结论回写到结构化知识中。因此更合适的关系是固定结构知识库负责定义 AI 必须理解的核心事实架构图谱负责服务寻址和链路分析服务知识库负责约束和验证RAG 负责发现和补证。前者是知识骨架后者是扩展检索能力。骨架没有立起来检索再快也很难让 AI 获得稳定的系统理解。4 知识正确性需要维护机制而不是一次性生成知识库最大的风险不是缺少文档而是文档过期后以“看起来很可信”的方式误导 AI。因此知识维护必须成为研发流程的一部分。服务知识库适合和 Git Push、Pull Request、版本发布建立联动。代码或配置发生变化时Hook 或 CI 可以根据 Diff 识别可能受影响的 API、对象、数据库、消息、配置和测试知识生成待更新的候选项并校验目录结构、交叉链接、版本基线和必填字段。但这里不能走向另一个极端任何代码变更都自动覆盖知识。对 API 契约、数据库语义、MQ Schema、状态机、历史兼容和安全策略等高风险知识自动化应负责发现变化、生成候选和阻止遗漏人工仍负责确认语义。工具擅长守住“代码变了知识不能完全不变”的底线人负责判断“它到底意味着什么”。对于刚刚提到的“业务知识库”同样需要两种互补机制。第一种是日常增量维护关键 API、关键业务链路、业务规则发生新增或变化时关联业务文档、方案和实现事实进行蒸馏有来源但尚未确认的内容标记为待审核不能静默升级为领域事实。在稳定业务上业务知识库的迭代频率是非常低的增量更新可以用人工保障也可以基于需求迭代release 做事件触发关联。第二种是周期性校准。比如高德每年的五一、十一出行节大促重点保障节点前后会产出大量稳定性梳理、系统串讲、链路盘点和复盘资料。它们通常覆盖多个服务之间最容易遗漏的风险与经验是校准业务知识库的高价值资料。日常维护保证及时性大促资料蒸馏帮助补齐跨系统、历史性和高风险知识也是非常重要的触发时机。知识的质量可以在迭代中持续考察或者评测效果每条重要知识最好能够看到来源、最后确认时间、适用范围、当前状态和负责人每份方案最好能看到关键结论来自哪里每次代码变更最好能知道哪些知识可能需要同步更新。这样知识库才不会变成另一座无人维护的文档墓地。5 service-knowledge 到底有没有用在之前的文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中提到了对于单个微服务系统的知识库设计和实现。后续有很多同学过来讨论 service-knowledge 的设计和思考集中的几个主要问题以及对应的思考、实践反馈统一解答一下service-knowledge 是否一定要和代码放到一个 git repo不一定完全可以和代码分开和代码在一起的优点是方便在技术方案设计、coding 、code review 等各个阶段的agent 能够快速摸清楚代码的结构和逻辑但这并不是和代码维护到一起的主要原因 仍然可以通过 agent runtime 或者 Harness 、SKILL 等实现本地文件目录中将二者进行关联service-knowledge 如何保证和代码的一致性可以按照首次生成、增量生成来区分首次生成问题不大覆盖的全面性比较能保障增量生成则可以关联 git hook或者 coding agent hook 的方式来实现。coding agent hook 的方式在 产出物 AGENTS.md文件中已经加入而 git hook 则更适合远端异步维护的方式来生成 service-knowledgeservice-knowledge 和 LLM wiki (markdown) 的差异是什么第一个大的区别是这是一种基于DDD、边界、安全策略等业界成熟的方法论设计的知识库结构基本可以屏蔽不同基模LLM 的能力差异实现一致化的结构和知识—— 方法论是成熟的、跨项目是一致的、对AI 是友好的第二个主要区别YAML 格式的文件 结构性更强信息密度比markdown 等格式会更高一些对大模型更加友好既然代码即事实service-knowledge 是否有存在的必要性这个问题很多同学、同事问到了。service-knowledge 的基础作用是 code indexing可以非常高效快速的让大模型理解代码结构而无需遍历所有代码尤其当代码量超过5万行的时候甚至差异会到一个数量级级别。对于这一点使用 code graph 等插件也可以实现 一般来讲至少提升 25% 的效率第二重作用是抽取系统实体、已有logic 等可以避免coding agent 每次都去分析和理解代码中的实体、逻辑等可以大幅度降低这些重复工作提高效率的同时也节省了 token 成本多个微服务时更加AI Friendly大家都知道大模型的 context window 是有限长度而且前面的几十KB 占用了更高的基模 attention 。当一个 agent task 需要扫描10个微服务的时候如果把这些微服务的代码都放入 context windows 则会瞬间触发记忆压缩而压缩则很容易导致记忆有损甚至丢失重要信息。因此尤其在涉及到多个微服务的时候service-knowledge 这种高信息密度、高结构化的知识的 AI Friendly 会更加明显6 渐进式披露强结构化的知识路径在知识准备完成后AI 不能把所有文档一次性读入上下文。大型系统的有效注意力仍然是稀缺资源。更可靠的方式是渐进披露每一步只加载完成当前判断所必需的知识并让下一步由前一步的结论触发。这条路径可以分成四层。层级AI 要回答的问题主要知识来源迭代频率业务层为什么改业务落在哪里业务元语在技术系统如何理解对应哪些系统或APIbusiness-knowledge、产品资料、历史实践。 采用business-knowledge-distill蒸馏低架构层涉及哪些系统影响谁aitom、服务图谱、接口和依赖关系中系统层单个服务应该怎样安全修改AGENTS.md、.knowledge/、代码和配置。 采用service-knowledge-generate生成高基建层工程底线和上线规则是什么中间件规范、发布流程、安全与稳定性规则。 静态内容很少更新。很低这里主要是践行在上一篇文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中提出的分层思路。本文的重点在于把它用于技术方案设计分层知识不只是用来“解释系统”而是直接决定 AI 的调研顺序和设计边界也契合“渐进式披露”的设计理念。先从业务元语开始。需求中的“区域”“订单”“置顶”“灰度”等词必须先被映射到确定的业务对象、状态和边界。没有这一步后续在仓库和图谱中搜索时AI 会把同名但不同义的概念混在一起。再从业务场景进入技术链路。一个页面上的按钮、一个运营动作、一次用户状态变化应该对应明确的入口 API、同步服务调用、异步消息、数据变化、异常处理和补偿逻辑。业务场景是 PRD 语言与技术系统之间的桥。接着使用 aitom 等架构能力摸清上下游。它帮助 AI 回答谁调用这个服务它又调用谁协议是什么超时多久有没有可以复用的能力改动是否会跨越系统边界。对于跨服务技术方案这一步比单仓库 grep 更重要。代码搜索可以告诉你“哪里出现过一个方法名”图谱才能帮助你判断“它在系统里承担什么角色”。最后进入目标仓库。service-knowledge-generate生成的AGENTS.md和.knowledge/不应该是一份新的长篇 README。短小的入口文件负责告诉 Agent 如何路由结构化知识负责描述系统边界、核心对象、API、下游依赖、基础设施、策略和测试要求。同时结合真实代码、配置和 Git 基线等核对当前事实并给出最终“代码级的技术方案设计”。这里有一个很重要的原则不同事实应回到不同来源确认。生产系统当前行为以代码和配置为准业务意图以已确认的产品和业务知识为准历史原因以可追溯的实践记录为准。不能因为代码实现了某种行为就把它自动视为未来需求的正确业务规则也不能因为一份旧文档写过某种设计就忽略现在代码已经发生的变化。这种回源机制会主动发现“知识漂移”。比如在某一个需求“体验站三期”方案中业务知识库曾记录某个模块“不排序”而代码实际对所有条目统一按权重排序方案据此修正了设计并把知识库回写列入后续工作。更典型的是entrance仓最初因为业务关键词 grep 没有命中而被判断为无需改动后续沿通用规则引擎继续追踪才发现它承载了需要扩展的投放能力。一次方案版本修正说明了一个朴素事实单一资料源给出的“结论”在复杂系统里很容易不够可靠。技术方案设计Agent 落地在经历过上面的步骤把业务知识库进行系统性建设之后终于来到了最关键的环节技术方案设计这也是“技术方案设计Agent”最终的落地环节。1 让 PRD 准入为技术设计的输入技术方案设计不能从“产品已经写完 PRD”开始。因为很多 PRD 只是产品表达的起点不一定已经具备进入研发的条件。一个成熟的需求输入至少要回答几个问题用户是谁在什么情境下遇到什么问题现有替代方式有什么障碍新的方案准备改变什么行为最终用什么指标判断成功。缺少其中任意一环AI 都可能把一个含糊的愿望翻译成一套貌似完整、实际跑偏的技术实现。prd-digest的价值在这里。它不负责替代架构师做详细技术设计而是承担需求准入检查问题与方案是否匹配价值和影响是否有依据范围是否受控现有能力能否复用验收与可逆性是否具备条件。对于材料不足的部分它要明确标记“未知”或“待验证”而不是替产品编造事实。经过这一步之后技术方案 Agent 接收到的就不再是一份原始 PRD而是一份经过结构化整理的需求包可验收目标、需求范围、明确不做项、关键假设、阻断项、待确认问题和专项评审触发项。这一步看上去增加了流程实际上减少了返工。AI 的速度会放大方向错误先把需求逻辑链和边界讲清楚才能避免它用十分钟写出一个需要两周返工的方案。这里想强调的是PRD 评审不是技术方案设计的前置行政动作它是 AI 技术方案设计的第一个输入转换器。2 新名词产品需求增强经过在集团内外走访发现在“产品需求准入”这一个环节也是有两种常见的不同实践思路一种是产品需求准入机制如上文提到另一种是“需求增强”机制—— 帮助产品需求PRD 文档变得更加健全更有助于研发落地。在没有AI agent 的年代认为“产品需求增强”是可以存在的只是职责归属值得讨论很多同学对此也有一些讨论和争议归属研发职能派有些团队会认为这个阶段是研发应该做的因为产品需求增强核心是通过技术系统现状分析实现的产品经理缺乏技术系统判断力无法判断AI 做得增强效果是否靠谱。归属产品经理职能派也有一些团队认为这个阶段的工作是应该产品经理实现的因为需求增强本身涉及到“改需求”而研发是没有权利单独改需求的。其实这两种说法本身都有道理并不能轻易说出谁更正确一些。但是更适合的解决方案是“架构师 Agent” 来做虽然架构师Agent 是以“技术方案设计”为切入点来落地的。但实际上具有技术方案设计能力的架构师Agent 是可以很容易拓展边界实现“产品需求增强”的职能的。拭目以待。3 Agent Context 与 Runtime经过前面的系统化设计分别完成了业务知识、架构与服务知识、系统分析工具以及技术方案设计 Skill 等能力建设。但从 Agent 的运行视角来看这些能力并不是彼此孤立存在的整体分别作用于Agent Context 和 Agent Runtime 调度——也就是Harness 阶段。无论是命令行形式的 Agent Client还是基于 GUI 的 Agent Client无论是 MCP、Skill 等基础能力还是 Agent Harness、Loop Engineering 等更高层的工程机制本质上都是在持续丰富 Agent 的 Context 或者调度 Agent Runtime为 Agent 提供完成复杂任务所需的上下文、知识、工具、行为约束与运行机制。因此前文的设计最终可以收敛为一个面向“跨多个复杂系统进行技术方案设计”的 Agent Runtime。自顶向下当前 Agent Runtime 主要包含以下内容a. 业务理解层基于 KBase MCP 的业务支持库通过 KBase MCP为 Agent 提供结构化的业务知识访问能力包括业务概念、领域模型、业务场景、设计原则、历史实践等。它解决的不是“AI 能否搜索到某篇业务文档”而是在进行技术方案设计之前AI 是否已经理解了当前需求背后的业务语义与领域上下文。b. 系统分析与探索层基于 AITOM 的 API 与链路追踪能力通过 AITOM 提供 API 检索、调用关系分析、链路追踪等能力使 Agent 可以从一个需求或业务入口出发逐步探索真实系统中的相关系统、服务调用关系、上下游依赖、关键业务链路等c. 架构推理层技术方案设计 Skill技术方案设计 Skill 定义了 Agent 在复杂技术方案设计过程中的工作方式包括如何理解和分析需求、如何逐步加载业务与系统上下文、如何定位相关系统与服务、如何对最终方案进行覆盖性与完整性验证等。d. 服务知识层多个微服务的 Service Knowledge每个微服务沉淀自己的 Service Knowledge用于描述服务级别的业务职责与能力边界、核心领域概念、API 与事件契约、数据模型、关键依赖等。e. 事实验证层基于 Git Repository 的 Code Context对于最终需要确认的实现事实Agent 可以进一步访问对应微服务的 Git Repository包括代码实现、配置、API 定义、数据结构等。4 AI 实现技术方案设计基于上述设计技术方案设计不再是一次性的长提示词生成而是一套有输入、有检索路径、有验证和停止条件的推理过程。在知识库完备、代码完备、PRD 准入完备之后可以正式开始做技术方案分析和设计第一步AI/Agent 读取经过需求准入的 PRD提取可验收目标、范围、不做项、风险和待确认信息。第二步AI/Agent 在业务知识库中解析关键元语和场景。它要先确认“需求说的是什么”再确认“这些业务概念在哪些系统、接口和数据上实现”。第三步AI/Agent 通过架构图谱定位候选服务和完整链路。这里要识别主路径、旁路、同步调用、异步事件、下游依赖、服务等级和架构红线而不是只找代码关键词。第四步AI/Agent 进入每个候选仓库根据任务类型读取相应的服务知识。例如新增 API 时优先读取 API 契约、兼容策略、测试和政策约束修改数据库时优先读取表语义、迁移规则、下游依赖和验证要求。随后回源到当前 Git Commit、代码和配置。第五步AI/Agent 形成 Gap 分析。已有能力且语义一致的明确复用已有能力但需要扩展的明确改造边界代码和知识中都不存在的明确新建。Gap 分析的重要性在于它强迫方案回答“为什么这样做”而不是直接罗列文件改动。第六步AI/Agent 生成完整方案包括改动点、调用方影响、异常传播、兼容策略、测试矩阵、发布与配置动作、需求覆盖矩阵、知识库联动和待确认项。Runtime 中的渐进式上下文加载沿着最短认知路径完成任务需要强调的是所有的结构化知识并不会在一次任务开始时全部加载到 Agent Context 中。对于复杂的跨系统技术方案设计如果一次性将所有业务知识、服务知识、代码和工具结果全部注入 Context不仅会造成大量无关信息干扰从 Agent 的视角来看前文建设的各项能力最终共同构成了其进行架构推理和技术方案设计的 Runtime。它追求的不是让 Agent 知道所有信息而是让 Agent 能够以尽可能短、尽可能准确的路径获得完成当前架构决策所必需的上下文和证据。这里的“纯 AI 做技术方案设计”指的是上述调研、检索、链路推理、代码核查、文档生成和覆盖检查由 AI 独立完成不再要求工程师先手工查完仓库、画完链路、写完方案再交给 AI。它并不等于取消人的职责。当出现业务取舍、跨团队接口承诺、数据口径、合规要求或高风险变更授权时AI 应停止猜测并发起明确的问题。人类介入的位置从“替 AI 收集所有资料”转为“裁决事实缺口和承担关键决策”。这个变化很大人不再是系统知识的唯一检索器而是知识质量和决策权的最终负责人。从 Harness 的角度看Skill 负责固化稳定流程、输入输出和边界Harness 负责组织上下文、工具调用、停止条件、证据校验和验证闭环基础模型负责推理、规划和动态编排。三者各自承担不同职责。只靠模型容易遗漏稳定约束只靠流程容易把模型能力锁死只靠文档则很难确保文档被正确加载和使用。5 什么样的方案才算可执行AI 写出一篇逻辑通顺的文章不难AI 写出一份可执行的技术方案要求高得多。一份好的方案至少应包含以下内容。首先明确涉及仓库和范围外参与方。大型需求经常需要多个服务、客户端、运营后台、配置中心甚至外部平台共同完成。方案要说明哪些仓库必改哪些系统只读不改哪些工作虽然必要但不在本方案覆盖内。否则实施阶段很容易出现“每个人都以为别人会做”的空档。其次给出术语对照和代码现状。PRD 语言、业务语言、配置名、服务名和代码名经常不一致。把它们一一映射出来既能避免搜索漏项也能把业务概念转换为具体工程对象。再次使用“复用、改造、新建”组织 Gap。复用不等于看到类似代码就直接调用必须确认用户、规则、状态、权限和风险语义是否一致改造要说明扩展点和存量兼容方式新建则要证明现有能力确实无法承载。然后是影响分析。被改造函数有哪些调用方异常会如何传播哪些存量行为必须逐字节不变修改一个字段、函数签名、缓存结构或配置项可能影响的并不只是眼前接口。方案如果没有这部分往往只是“改动清单”还称不上技术设计。验证部分同样不能只写“补充单测”。新增 API 要看契约测试修改状态机要覆盖核心流程调整消息要验证生产者和消费者兼容修改缓存要关注失效和降级涉及灰度和配置要有开关关闭时的存量行为回归。体验站三期方案中除了单测还给出了手工回归矩阵、异常传播链、需求覆盖矩阵和不改动约束这些内容共同构成了方案的可执行性。最后必须把未知信息留在文档里。待确认项不是方案不完整的证据恰恰相反无法通过现有资料证实的内容被明确登记才说明方案没有把推断伪装成事实。可以用五个问题检查一条需求是否真正被方案覆盖改哪里为什么改影响谁如何验证还有什么没有确认如果这五个问题都能回答方案才有可能进入研发执行。6 AI设计技术方案完备度衡量“技术方案完善度达到 95% 以上”—— 这是我们具体实践中团队同学对于AI 生成技术方案的完成度定下的目标。在这里它不是指 AI 能够预知所有线上情况也不是指任何需求都不需要人确认。它指的是在需求已经完成准入、关键知识能够回源、代码与配置得到核查、人工评审完成之后方案对主要工程问题的覆盖程度足够高。这个指标可以拆成六个维度需求覆盖PRD 条目是否逐项归属为“做、不做或待确认”系统覆盖涉及服务、仓库、配置、上下游和范围外参与方是否完整证据覆盖关键结论是否能回源到业务知识、架构事实、代码、配置或已确认文档风险覆盖兼容、异常、灰度、缓存、消息、状态机和安全约束是否被检查验证覆盖单测、契约、回归、监控、发布与回滚是否清楚不确定性治理未知和冲突信息是否被显式登记而没有被 AI 擅自补全。在“体验站三期”需求的案例中在原始需求完整度相对较高、且知识库体系完备的前提下我们使用当前一流的基模AI Agent 原生设计出来的技术方案覆盖度可以达到 95% 以上。剩余的不确定性通常来自跨团队决策、外部系统行为、数据口径和产品取舍。这些本来就不应由模型单独决定。把它们压缩到少量明确的问题而不是让它们以隐性风险的形式藏在方案里已经是很大的进步。至此我们的“技术方案设计Agent ”成功落地。知识库体系是“多场景 Agent”基建虽然本文知识库体系的主要落地场景是服务于“技术方案设计”但从实际作用价值的角度来看知识库是全流程复用的。比如技术方案设计和线上问题排查看起来是两件事但底层需要的能力却非常接近。方案设计是从需求向未来推演这个能力应该落在哪条链路上修改之后会影响什么。线上排查则是从现象向过去回溯用户看到的问题经过了哪些服务哪个配置、缓存、消息或下游依赖可能异常。两者都需要业务元语来理解问题究竟指什么都需要场景映射来找到入口都需要架构图谱来定位跨服务链路也都需要服务知识来检查状态机、配置、缓存和降级逻辑。在我们的线上问题排查 Agent 实践中同一套体系性知识正是其理解系统和缩小排查范围的基础。这意味着知识库建设的投入并不只服务于“让 AI 写代码”。它会成为研发调研、技术方案、代码修改、线上排查、事故复盘和新人理解系统的共同底座。一次把关键知识显式化可以在多个环节复用。**从“技术方案设计 Agent”到 “架构师 Agent”我们虽然是从技术方案设计切入并不是因为架构师的职责只有写技术方案而是因为技术方案设计恰恰是架构师最核心、最能体现系统性判断的一项工作。面对一个需求架构师需要理解业务意图定位跨系统链路识别服务边界和历史约束判断哪些能力可以复用、哪些地方需要改造并最终给出一条可验证、可落地的技术路径。这个过程的创新并不是某个模型天然比别人更会设计而是尝试把需求准入、业务隐性知识、跨服务图谱、服务内部约束、代码回源和质量验证连接成一条可维护、可执行、可持续演进的技术方案生产线。前面构建的业务知识、架构图谱、服务知识、渐进式上下文加载以及代码回源和证据验证本质上都不是为了让 AI 生成一份更漂亮的技术文档而是在逐步补齐 AI 完成架构判断所需要的知识、上下文、推理路径和验证能力。因此技术方案设计 Agent 并不是终点而是“架构师 Agent”的第一个具体落点。当 AI 能够稳定完成这条链路后同一套系统理解和技术判断能力还可以进一步扩展到需求增强、跨系统影响分析、架构评审、线上问题排查以及对 Coding Agent 的任务规划和技术约束。这些任务的输出不同但底层依赖的是同一种核心能力理解复杂系统并基于真实的业务、架构和工程事实完成判断。轻松扩展“架构师Agent ”的能力边界在实际研发流程中如果我们希望“架构师Agent”拥有排查线上问题的能力那我们只需要给其赋予对应的 LogHouse MCP、Service Runtime MCP 等能能力即可—— 在当前的基础上做“架构师Agent” 的能力边界扩展是很容易的事情。从这个角度看本文的价值不在于定义一个新的模型能力而在于尝试验证一种系统性的工程创新方法通过把原本分散在文档、代码、架构和工程师经验中的知识以及架构师完成判断所经历的流程逐步显性化、结构化并组织成 AI 可以理解、推理和验证的工程系统。技术方案设计是“架构师 Agent”的起点而把架构师的系统理解与技术判断能力逐步工程化、可执行化才是这项实践真正希望探索的方向。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 AI大模型小白必看：轻松掌握架构师技能，从技术方案设计开始
本文探讨了AI在理解复杂系统架构方面的局限性并提出了构建AI可理解、可推理、可验证的工程系统的方案。文章重点介绍了如何通过知识库建设、需求准入、分层知识库、渐进式披露等技术手段让AI能够完成技术方案设计。文章最后指出技术方案设计Agent是“架构师Agent”的起点通过系统化工程创新方法将架构师的系统理解与技术判断能力逐步显性化、结构化为AI赋能实现更高效的研发流程。AI 仍难以理解复杂系统架构很多团队第一次使用 AI Coding 时都会发现一个类似的问题从零做一个小系统效果往往很惊艳一旦把 AI 放进运行多年的大型系统里效果就开始不稳定。小系统里AI 能在很短时间内搭出页面、接口、数据模型、测试和部署脚本。大型复杂系统里一个看上去不复杂的需求可能涉及十几个仓库、几十个接口、若干配置中心和异步消息链路。AI 写代码本身未必慢真正慢的是它不知道该从哪里开始也不知道哪些地方绝不能动。这不是一个单纯的模型能力问题。代码生成能力已经足够强局部修改、补测试、解释调用链很多模型都做得不错。困难在于复杂系统真正重要的知识并不完整地存在于代码中。一个字段为什么不能删除某个历史分支为什么必须保留一条 MQ 消息为什么只能新增字段不能改语义某个接口为什么不能在网关层做校验某个配置为什么必须跟发布灰度一起生效——这些信息可能散落在历史方案、事故复盘、配置平台、同事经验和没有被正式记录的约定中。人类工程师靠长期参与、沟通和事故记忆补齐了这部分上下文AI 如果没有被提供这些事实只能依据局部代码做推断。所以AI 在复杂存量系统中最容易出现的错误往往不是代码语法错误也不是编译器或单测能直接发现的错误而是“局部正确、整体错误”逻辑写在了不该承担职责的服务里增加了一个看似方便的同步调用却消耗了核心链路的超时预算删掉了一段看似冗余的兼容逻辑破坏了老版本客户端或下游离线任务。以架构师的核心职能技术方案设计为例技术方案设计决定了需求应该落在哪些系统、改动应放在哪一层、哪些能力可以复用、哪些约束不能突破以及改完以后如何证明它仍然安全。AI Coding 的效率会放大方案正确性也会放大方案错误的传播速度。方向错了AI 只会更快地把错误落实成大量代码。复杂存量分布式系统有一个很大的难题AI 必须跨越业务语言、架构链路、多个服务和真实代码才能获得足够上下文来生成技术方案。很多团队目前的做法仍是由架构师或者资深工程师先完成人工方案再把确定的改动点交给 AI 编码在与集团内外和多部门同事、同行的交流中我们也观察到技术方案设计仍是人工介入最深的环节之一仍然是需要架构师强力介入的环节。白纸与旧城新系统容易存量系统困难除了系统规模以外新系统、已有系统对于AI 的挑战也差别非常大。在AI 的加持下一名研发工程师就可以用一周的时间写出类似Salesforce 的系统实现大部分基础功能。但是如果让他在已有的Salesforce 系统上做一个中等规模的AI Coding 迭代可能反而一周搞不定。这是因为新系统、老系统对AI 来讲差别也很大核心差别在于历史上下文的认知、生效方式。从零开始开发一个新系统AI 面对的是一张相对干净的“白纸”。边界可以新建模块可以新拆接口可以新定历史包袱也少。即使某些设计不够优雅后续调整的成本通常仍然可控。就相当于人一样一个订单系统让一位新同学开发往往可以几天之内看到雏形而如果让这位同学在已有的订单系统上开发往往需要几天的时间去熟悉历史代码和历史业务场景。而存量技术系统像一座运行多年的城市。路网、管线、旧建筑、临时改造和居民习惯共同决定了它今天的样子。你不能只看一条街上的建筑风格就决定把地下管线挖掉也不能只看到一个服务里的代码就断定它拥有某项业务的最终决策权。大型分布式系统至少有四类知识同时影响方案设计。第一类是业务知识。产品说“优化退款体验”“增加人群投放”“调整订单展示”这些都是业务语言。它们对应的业务对象、状态含义、边界和例外并不必然等同于代码中的类名和字段名。一个“订单”在不同团队的口语里可能是交易订单、支付单、配送单或对账单如果概念没有被消歧后续检索和设计很容易从第一步就偏离。第二类是架构知识。一个用户请求从客户端进入之后经过哪些 BFF、领域服务、下游 RPC、消息和异步任务哪些服务拥有数据主责哪些只是聚合和展示哪里允许最终一致哪里必须强一致这些决定了变更应该落在什么位置也决定了影响分析的范围。第三类是服务内部知识。单个服务中的 API 契约、领域对象、状态机、数据库、缓存、消息、定时任务、配置项和测试方式决定了“具体怎么改才安全”。仅靠临时 grepAI 可以找到一些相关文件却未必知道哪个入口是主路径哪个分支是历史兼容哪个字段会被下游消费者依赖。第四类是工程与组织知识。例如超时、重试、限流、灰度、发布、回滚、安全审批和监控规则。这些往往不改变业务代码的表面逻辑却直接决定方案能否上线、故障是否可控。从这个角度看“存量复杂系统”的困难不在于“代码太多”而在于知识彼此断裂。代码只表达了部分实现事实文档可能表达了一部分设计意图配置记录了运行时行为经验沉淀了大量没有写下来的约束。没有一套机制把它们组织起来AI 就很难从一个 PRD 走到完整的技术方案。这也是我们希望解决的痛点让“存量的大型分布式系统”不再只存在于少数人的脑中而是逐步成为 AI 可以全方位理解、进而参与方案设计、研发执行和线上排查的工程系统。尤其“技术方案设计阶段”是整个AI Coding 的核心部分是AI Coding 最重要的源头起点。在公开可见的实践中这种面向复杂存量分布式系统的端到端组合仍不常见这部分能力目前业界一直没有很好的可靠解决方案。足以证明达成这个目标确实是有难度、有挑战的但是从价值来讲又是有必要性的因此我们称之为—— 难而正确的事难而正确的事行业走到了哪里从 Spec、Harness 到系统理解我们也调研了最近2年的相关技术设计、与探索实践其实业界早就普遍意识到直接把一句自然语言需求交给 Coding Agent再期待它完成复杂研发并不是稳定的工作方式所以是持续有一些新的技术设计、技术方法论、实践产生第一条主流路线是 Spec-Driven DevelopmentGitHub Spec Kit 将流程组织为Spec → Plan → Tasks → Implement用结构化产物把需求、计划和任务串起来。Kiro 也将需求、设计、任务拆成独立文件对于复杂、陌生或高风险的需求它建议保留阶段性审阅和需求分析而不是直接进入执行。第二条路线是长程 Agent 的 HarnessAnthropic 在长程开发实验中发现只给模型一个高层目标并不足以得到生产级结果需要通过初始化、任务拆分和结构化交接让后续会话知道前面已经完成了什么、还缺什么。这解决的是长时间执行过程中的上下文连续性问题。第三条路线是 Agent-friendly RepositoryOpenAI 的实践强调给 Agent 一张地图而不是一千页说明书。短小的AGENTS.md负责路由结构化文档负责承载事实CI 和自动化检查负责发现知识陈旧、链接失效和结构漂移。这些思路和方向都很重要也和我们的实践高度一致。不过这些实践比较多的还是偏单个微服务系统内部实践对于跨复杂多系统的工业实践层面并没有给出比较理想和细节的设计。而我们希望向前一步让AI 能够完成“复杂系统理解”—— 并能够真正做到类似于人类架构师一样实现跨多系统、甚至多终端的技术方案设计、推理等。从技术方案设计Agent 开始虽然我们要做的是“架构师Agent ”但是为了避免空泛化的设计和过于发散的思考我们把决定先从架构师的核心职能之一 —— 技术方案设计开始逐步落地我们的架构师Agent。图示技术方案设计是AI Coding、乃至 7 x 24 小时的 Agentic coding 的必经之路。但是技术方案设计现在基本都是由架构师人工完成的无法摆脱架构师的脑子和能力站在业界的角度我们希望通过一种系统性的设计和落地切实帮助到我们的日常工作扩大AI 提效的Scope 和高度。同时也尽量形成可迁移的方法论或者流程以帮助到更多的团队乃至业界的工程师。我们的设计思路是系统化地让 AI 完成技术方案设计先理解需求再理解业务和系统再回源代码与配置最后给出可执行、可验证、可审计的方案。这个过程的关键不是一条更长的 Prompt而是一套持续演进的知识工程与Agent 迭代路径。由此也可以看出其中主要的几个抓手和关键点需求质量、分层知识库全面性、准确性、渐进式披露、LLM基模推理能力、技术方案产出规范。我们先从“知识库建设”开始第一步落地。知识库的系统性建设落地在之前的文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中已经系统性的讨论和设计过知识库体系在文章发布后也有很多不同部门的同学过来找我们讨论包括大家各自在知识库建设过程中遇到的一些问题比如指标衡量方式、什么样的知识库结构比较好、如何用指标衡量知识库建设效果等。因此本文会根据我们之前已发表文章中的内容以及大家关心的话题做更多进一步的细化阐述。尤其是AI 时代对于知识库建设方面很多团队天然想到的就是RAG。我倒不是不推荐RAG我们更认为知识库建设的第一层看到的不应该是RAG —— 而应该是“领域”。注引用上一篇文章的原图其中蓝色背景框部分是性价比比较高的模块适合越早投入见效越快的模块。1 知识库应该首先“对齐领域”结构化的设计5 年之前我对AI 一直有一个比喻——“能力强大的小学生”当时AI 确实很强大但是思路层面非常的懵懂经常需要复杂的提示词才能让他理解任务并理解这个任务对应在现实世界中的实际逻辑从而去更加准确的完成人类交给的任务。而最近1年多的大模型迭代让我们看到了非常不一样的能力就是基模能力越来越强我现在已经很愿意把AI 基模形容为“能力强大的大学生”了—— 对物理世界、人类需要的数字世界、各种商业逻辑、互联网业务逻辑等都有了比较强的内化性理解。但无论是小学生还是大学生我对团队同学提的建议是 把AI 当做一名刚毕业的很聪明的实习生来引导指导它的工作。虽然当前主流的大模型采用的 Transformer 架构和人脑神经思考反馈机制差异很大。但是从实践层面来看其推理结果和原始输入是有非常大的强相关性的 —— 原始输入越精确得到的结论越精确、且越高效。这和人类的认知、思考模式的习惯也比较类似。如果我们新入职的实习生同学最快引导其工作的方式应该也是给到他一个结构性比较强的文档层层递进的熟悉和了解自己的工作而不是丢给他一个文档库让他自己去检索。人类架构师对于技术系统的设计是有很成熟的类似DDD领域驱动设计这样的方法论的。所以我们的架构应该天然是有领域边界的天然是“面向领域强结构化”的。同样为了提高AI 对于业务、系统的理解效率 我也强烈推荐让AI 理解这种“强结构化的领域知识”而不是给AI 一个知识库让它自己搜。2 反直觉设计为什么不首推 RAG讨论知识库时很多人的第一反应是 RAG把历史 PRD、技术方案、会议纪要、接口文档、复盘和 Wiki 都放进向量库需要时检索 Top K 片段交给模型。RAG 很有用但它不应该是复杂系统知识建设的第一选择。原因很简单检索解决的是“从资料中找出可能相关内容”并不天然解决“AI 是否已经拿到了做出完整工程判断所需的知识集合”。当数千篇非结构化文档进入同一个索引时常见的问题会同时出现。首先是颗粒度不一致一篇完整方案、一次会议纪要、一段接口说明、一个事故复盘里的截图说明都可能成为检索单元。它们的知识密度差异很大。一个命中的片段看起来相关并不代表它涵盖了这个问题真正重要的边界。其次是语义相似不等于工程相关用户说“订单取消”检索可能找到退款、履约、营销、风控中的大量相似描述却不一定找到“状态机不可跳转”“某个 Topic 仍有历史消费者”“这个接口只有聚合服务可以调用”这类决定方案正确性的约束。再次是 Top K 的完整性、结构性没有保证RAG 很容易返回若干看起来相关的文档但这些文档可能来自不同时间、不同业务范围甚至互相矛盾。模型拿到的是一些碎片而不是一条完整链路。上下文越来越长注意力却没有更集中推理效率反而下降。所以RAG 的问题不在于“召回不够多”而在于它很难独立承担知识建模的职责。把大量低结构、低密度、碎片化资料统一检索得到的经常是一座更容易搜索、但依然杂乱的文档仓库。这里对应的第一性原理思考就是知识是有结构的更适合被结构化的索引和理解。信息比如新闻类内容是结构化松散的更适合被平行/平铺化检索。3 “蒸馏架构师的大脑” —— 业务知识库的建设在上一篇文章中对于“业务知识库”结构我们给出了如下这种结构设计。也有很多同学来找我们问如何实现这个知识库效果如何等等。business/├── index.md├── meta/│ └── index.md├── principle/│ ├── index.md│ ├── timeout.md│ ├── idempotency.md│ ├── consistency.md│ ├── degradation.md│ └── compatibility.md├── scenario/│ ├── index.md│ └── scenario-*.md├── reference/ #关联、引用内容├── practice/│ ├── index.md│ └── practice-*.md└── history/└── history-YYYYMMDD.md其实这层知识库的主要目标是“把架构师脑子里的隐性知识挖出来”—— 从而尽量摆脱“技术方案必须依赖架构师的隐形知识才能产出”的魔咒—— 让AI 对人的依赖进一步降低进而更快的迈向 7 x 24 小时的 Agentic Coding 和交付。所以从这一点来讲就是把架构师大脑中的知识蒸馏出来形成文档。而为了实现这个目标我们开发了新的 skillbusiness-knowledge-distill这个 skill 是专门用来根据比如技术方案设计文档、技术稳定性体系梳理串讲文档等进行蒸馏梳理成强结构化的business-knowledge的。同时因为很多文档中有“交互图”这个skill 也会下载并分析对应的图片内容一起转为结构化的业务知识库从实际生成效果来看还是非常赞的尤其在技术方案设计阶段发挥了很大作用。以高德的实时公交业务为例我们一次蒸馏后形成的业务知识库如下文件内详细内容暂不展开。.├── evidence│ └── images│ ├── b5bebae4a0aba2c0a551.png│ ├── be6c21dc82612f040f2f.png│ ├── d05045ed77ba108686e8.png│ └── image-manifest.json├── history│ └── history-20260817.md├── index.md├── meta│ ├── departure-timetable.md│ ├── index.md│ ├── line-and-station.md│ ├── nearby-recommendation.md│ ├── realtime-bus-info.md│ └── service-roles.md├── practice│ ├── capacity-planning.md│ ├── index.md│ ├── scheduled-tasks.md│scenario从用户或业务场景映射到 API、服务、数据、消息、异常和补偿practice历史决策、事故教训、兼容原因和可复用模式reference与其他领域的关系和契约不复制对方领域的完整知识。这样的结构不是为了让目录看起来整齐而是为了让 AI 在处理需求时有确定的阅读路径。先读元语避免概念混淆再读场景确定业务如何落到技术系统遇到一致性、兼容或降级问题时回到领域原则需要理解历史原因时再查实践。换个角度看固定结构提供的是“知识覆盖约束”。它告诉 AI解决一个业务问题至少要理解哪些方面而 RAG 只能告诉 AI这里有一些可能相关的资料。这并不意味着放弃 RAG。RAG 很适合做长尾资料发现、历史文档定位、开放式问答和证据补充。当固定结构知识库缺少某个细节时可以通过 KBase 等检索能力找到原始文档、历史方案或复盘再把经过确认的结论回写到结构化知识中。因此更合适的关系是固定结构知识库负责定义 AI 必须理解的核心事实架构图谱负责服务寻址和链路分析服务知识库负责约束和验证RAG 负责发现和补证。前者是知识骨架后者是扩展检索能力。骨架没有立起来检索再快也很难让 AI 获得稳定的系统理解。4 知识正确性需要维护机制而不是一次性生成知识库最大的风险不是缺少文档而是文档过期后以“看起来很可信”的方式误导 AI。因此知识维护必须成为研发流程的一部分。服务知识库适合和 Git Push、Pull Request、版本发布建立联动。代码或配置发生变化时Hook 或 CI 可以根据 Diff 识别可能受影响的 API、对象、数据库、消息、配置和测试知识生成待更新的候选项并校验目录结构、交叉链接、版本基线和必填字段。但这里不能走向另一个极端任何代码变更都自动覆盖知识。对 API 契约、数据库语义、MQ Schema、状态机、历史兼容和安全策略等高风险知识自动化应负责发现变化、生成候选和阻止遗漏人工仍负责确认语义。工具擅长守住“代码变了知识不能完全不变”的底线人负责判断“它到底意味着什么”。对于刚刚提到的“业务知识库”同样需要两种互补机制。第一种是日常增量维护关键 API、关键业务链路、业务规则发生新增或变化时关联业务文档、方案和实现事实进行蒸馏有来源但尚未确认的内容标记为待审核不能静默升级为领域事实。在稳定业务上业务知识库的迭代频率是非常低的增量更新可以用人工保障也可以基于需求迭代release 做事件触发关联。第二种是周期性校准。比如高德每年的五一、十一出行节大促重点保障节点前后会产出大量稳定性梳理、系统串讲、链路盘点和复盘资料。它们通常覆盖多个服务之间最容易遗漏的风险与经验是校准业务知识库的高价值资料。日常维护保证及时性大促资料蒸馏帮助补齐跨系统、历史性和高风险知识也是非常重要的触发时机。知识的质量可以在迭代中持续考察或者评测效果每条重要知识最好能够看到来源、最后确认时间、适用范围、当前状态和负责人每份方案最好能看到关键结论来自哪里每次代码变更最好能知道哪些知识可能需要同步更新。这样知识库才不会变成另一座无人维护的文档墓地。5 service-knowledge 到底有没有用在之前的文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中提到了对于单个微服务系统的知识库设计和实现。后续有很多同学过来讨论 service-knowledge 的设计和思考集中的几个主要问题以及对应的思考、实践反馈统一解答一下service-knowledge 是否一定要和代码放到一个 git repo不一定完全可以和代码分开和代码在一起的优点是方便在技术方案设计、coding 、code review 等各个阶段的agent 能够快速摸清楚代码的结构和逻辑但这并不是和代码维护到一起的主要原因 仍然可以通过 agent runtime 或者 Harness 、SKILL 等实现本地文件目录中将二者进行关联service-knowledge 如何保证和代码的一致性可以按照首次生成、增量生成来区分首次生成问题不大覆盖的全面性比较能保障增量生成则可以关联 git hook或者 coding agent hook 的方式来实现。coding agent hook 的方式在 产出物 AGENTS.md文件中已经加入而 git hook 则更适合远端异步维护的方式来生成 service-knowledgeservice-knowledge 和 LLM wiki (markdown) 的差异是什么第一个大的区别是这是一种基于DDD、边界、安全策略等业界成熟的方法论设计的知识库结构基本可以屏蔽不同基模LLM 的能力差异实现一致化的结构和知识—— 方法论是成熟的、跨项目是一致的、对AI 是友好的第二个主要区别YAML 格式的文件 结构性更强信息密度比markdown 等格式会更高一些对大模型更加友好既然代码即事实service-knowledge 是否有存在的必要性这个问题很多同学、同事问到了。service-knowledge 的基础作用是 code indexing可以非常高效快速的让大模型理解代码结构而无需遍历所有代码尤其当代码量超过5万行的时候甚至差异会到一个数量级级别。对于这一点使用 code graph 等插件也可以实现 一般来讲至少提升 25% 的效率第二重作用是抽取系统实体、已有logic 等可以避免coding agent 每次都去分析和理解代码中的实体、逻辑等可以大幅度降低这些重复工作提高效率的同时也节省了 token 成本多个微服务时更加AI Friendly大家都知道大模型的 context window 是有限长度而且前面的几十KB 占用了更高的基模 attention 。当一个 agent task 需要扫描10个微服务的时候如果把这些微服务的代码都放入 context windows 则会瞬间触发记忆压缩而压缩则很容易导致记忆有损甚至丢失重要信息。因此尤其在涉及到多个微服务的时候service-knowledge 这种高信息密度、高结构化的知识的 AI Friendly 会更加明显6 渐进式披露强结构化的知识路径在知识准备完成后AI 不能把所有文档一次性读入上下文。大型系统的有效注意力仍然是稀缺资源。更可靠的方式是渐进披露每一步只加载完成当前判断所必需的知识并让下一步由前一步的结论触发。这条路径可以分成四层。层级AI 要回答的问题主要知识来源迭代频率业务层为什么改业务落在哪里业务元语在技术系统如何理解对应哪些系统或APIbusiness-knowledge、产品资料、历史实践。 采用business-knowledge-distill蒸馏低架构层涉及哪些系统影响谁aitom、服务图谱、接口和依赖关系中系统层单个服务应该怎样安全修改AGENTS.md、.knowledge/、代码和配置。 采用service-knowledge-generate生成高基建层工程底线和上线规则是什么中间件规范、发布流程、安全与稳定性规则。 静态内容很少更新。很低这里主要是践行在上一篇文章《分解一座冰山后端系统“AI 知识库体系”建设实践》[5]中提出的分层思路。本文的重点在于把它用于技术方案设计分层知识不只是用来“解释系统”而是直接决定 AI 的调研顺序和设计边界也契合“渐进式披露”的设计理念。先从业务元语开始。需求中的“区域”“订单”“置顶”“灰度”等词必须先被映射到确定的业务对象、状态和边界。没有这一步后续在仓库和图谱中搜索时AI 会把同名但不同义的概念混在一起。再从业务场景进入技术链路。一个页面上的按钮、一个运营动作、一次用户状态变化应该对应明确的入口 API、同步服务调用、异步消息、数据变化、异常处理和补偿逻辑。业务场景是 PRD 语言与技术系统之间的桥。接着使用 aitom 等架构能力摸清上下游。它帮助 AI 回答谁调用这个服务它又调用谁协议是什么超时多久有没有可以复用的能力改动是否会跨越系统边界。对于跨服务技术方案这一步比单仓库 grep 更重要。代码搜索可以告诉你“哪里出现过一个方法名”图谱才能帮助你判断“它在系统里承担什么角色”。最后进入目标仓库。service-knowledge-generate生成的AGENTS.md和.knowledge/不应该是一份新的长篇 README。短小的入口文件负责告诉 Agent 如何路由结构化知识负责描述系统边界、核心对象、API、下游依赖、基础设施、策略和测试要求。同时结合真实代码、配置和 Git 基线等核对当前事实并给出最终“代码级的技术方案设计”。这里有一个很重要的原则不同事实应回到不同来源确认。生产系统当前行为以代码和配置为准业务意图以已确认的产品和业务知识为准历史原因以可追溯的实践记录为准。不能因为代码实现了某种行为就把它自动视为未来需求的正确业务规则也不能因为一份旧文档写过某种设计就忽略现在代码已经发生的变化。这种回源机制会主动发现“知识漂移”。比如在某一个需求“体验站三期”方案中业务知识库曾记录某个模块“不排序”而代码实际对所有条目统一按权重排序方案据此修正了设计并把知识库回写列入后续工作。更典型的是entrance仓最初因为业务关键词 grep 没有命中而被判断为无需改动后续沿通用规则引擎继续追踪才发现它承载了需要扩展的投放能力。一次方案版本修正说明了一个朴素事实单一资料源给出的“结论”在复杂系统里很容易不够可靠。技术方案设计Agent 落地在经历过上面的步骤把业务知识库进行系统性建设之后终于来到了最关键的环节技术方案设计这也是“技术方案设计Agent”最终的落地环节。1 让 PRD 准入为技术设计的输入技术方案设计不能从“产品已经写完 PRD”开始。因为很多 PRD 只是产品表达的起点不一定已经具备进入研发的条件。一个成熟的需求输入至少要回答几个问题用户是谁在什么情境下遇到什么问题现有替代方式有什么障碍新的方案准备改变什么行为最终用什么指标判断成功。缺少其中任意一环AI 都可能把一个含糊的愿望翻译成一套貌似完整、实际跑偏的技术实现。prd-digest的价值在这里。它不负责替代架构师做详细技术设计而是承担需求准入检查问题与方案是否匹配价值和影响是否有依据范围是否受控现有能力能否复用验收与可逆性是否具备条件。对于材料不足的部分它要明确标记“未知”或“待验证”而不是替产品编造事实。经过这一步之后技术方案 Agent 接收到的就不再是一份原始 PRD而是一份经过结构化整理的需求包可验收目标、需求范围、明确不做项、关键假设、阻断项、待确认问题和专项评审触发项。这一步看上去增加了流程实际上减少了返工。AI 的速度会放大方向错误先把需求逻辑链和边界讲清楚才能避免它用十分钟写出一个需要两周返工的方案。这里想强调的是PRD 评审不是技术方案设计的前置行政动作它是 AI 技术方案设计的第一个输入转换器。2 新名词产品需求增强经过在集团内外走访发现在“产品需求准入”这一个环节也是有两种常见的不同实践思路一种是产品需求准入机制如上文提到另一种是“需求增强”机制—— 帮助产品需求PRD 文档变得更加健全更有助于研发落地。在没有AI agent 的年代认为“产品需求增强”是可以存在的只是职责归属值得讨论很多同学对此也有一些讨论和争议归属研发职能派有些团队会认为这个阶段是研发应该做的因为产品需求增强核心是通过技术系统现状分析实现的产品经理缺乏技术系统判断力无法判断AI 做得增强效果是否靠谱。归属产品经理职能派也有一些团队认为这个阶段的工作是应该产品经理实现的因为需求增强本身涉及到“改需求”而研发是没有权利单独改需求的。其实这两种说法本身都有道理并不能轻易说出谁更正确一些。但是更适合的解决方案是“架构师 Agent” 来做虽然架构师Agent 是以“技术方案设计”为切入点来落地的。但实际上具有技术方案设计能力的架构师Agent 是可以很容易拓展边界实现“产品需求增强”的职能的。拭目以待。3 Agent Context 与 Runtime经过前面的系统化设计分别完成了业务知识、架构与服务知识、系统分析工具以及技术方案设计 Skill 等能力建设。但从 Agent 的运行视角来看这些能力并不是彼此孤立存在的整体分别作用于Agent Context 和 Agent Runtime 调度——也就是Harness 阶段。无论是命令行形式的 Agent Client还是基于 GUI 的 Agent Client无论是 MCP、Skill 等基础能力还是 Agent Harness、Loop Engineering 等更高层的工程机制本质上都是在持续丰富 Agent 的 Context 或者调度 Agent Runtime为 Agent 提供完成复杂任务所需的上下文、知识、工具、行为约束与运行机制。因此前文的设计最终可以收敛为一个面向“跨多个复杂系统进行技术方案设计”的 Agent Runtime。自顶向下当前 Agent Runtime 主要包含以下内容a. 业务理解层基于 KBase MCP 的业务支持库通过 KBase MCP为 Agent 提供结构化的业务知识访问能力包括业务概念、领域模型、业务场景、设计原则、历史实践等。它解决的不是“AI 能否搜索到某篇业务文档”而是在进行技术方案设计之前AI 是否已经理解了当前需求背后的业务语义与领域上下文。b. 系统分析与探索层基于 AITOM 的 API 与链路追踪能力通过 AITOM 提供 API 检索、调用关系分析、链路追踪等能力使 Agent 可以从一个需求或业务入口出发逐步探索真实系统中的相关系统、服务调用关系、上下游依赖、关键业务链路等c. 架构推理层技术方案设计 Skill技术方案设计 Skill 定义了 Agent 在复杂技术方案设计过程中的工作方式包括如何理解和分析需求、如何逐步加载业务与系统上下文、如何定位相关系统与服务、如何对最终方案进行覆盖性与完整性验证等。d. 服务知识层多个微服务的 Service Knowledge每个微服务沉淀自己的 Service Knowledge用于描述服务级别的业务职责与能力边界、核心领域概念、API 与事件契约、数据模型、关键依赖等。e. 事实验证层基于 Git Repository 的 Code Context对于最终需要确认的实现事实Agent 可以进一步访问对应微服务的 Git Repository包括代码实现、配置、API 定义、数据结构等。4 AI 实现技术方案设计基于上述设计技术方案设计不再是一次性的长提示词生成而是一套有输入、有检索路径、有验证和停止条件的推理过程。在知识库完备、代码完备、PRD 准入完备之后可以正式开始做技术方案分析和设计第一步AI/Agent 读取经过需求准入的 PRD提取可验收目标、范围、不做项、风险和待确认信息。第二步AI/Agent 在业务知识库中解析关键元语和场景。它要先确认“需求说的是什么”再确认“这些业务概念在哪些系统、接口和数据上实现”。第三步AI/Agent 通过架构图谱定位候选服务和完整链路。这里要识别主路径、旁路、同步调用、异步事件、下游依赖、服务等级和架构红线而不是只找代码关键词。第四步AI/Agent 进入每个候选仓库根据任务类型读取相应的服务知识。例如新增 API 时优先读取 API 契约、兼容策略、测试和政策约束修改数据库时优先读取表语义、迁移规则、下游依赖和验证要求。随后回源到当前 Git Commit、代码和配置。第五步AI/Agent 形成 Gap 分析。已有能力且语义一致的明确复用已有能力但需要扩展的明确改造边界代码和知识中都不存在的明确新建。Gap 分析的重要性在于它强迫方案回答“为什么这样做”而不是直接罗列文件改动。第六步AI/Agent 生成完整方案包括改动点、调用方影响、异常传播、兼容策略、测试矩阵、发布与配置动作、需求覆盖矩阵、知识库联动和待确认项。Runtime 中的渐进式上下文加载沿着最短认知路径完成任务需要强调的是所有的结构化知识并不会在一次任务开始时全部加载到 Agent Context 中。对于复杂的跨系统技术方案设计如果一次性将所有业务知识、服务知识、代码和工具结果全部注入 Context不仅会造成大量无关信息干扰从 Agent 的视角来看前文建设的各项能力最终共同构成了其进行架构推理和技术方案设计的 Runtime。它追求的不是让 Agent 知道所有信息而是让 Agent 能够以尽可能短、尽可能准确的路径获得完成当前架构决策所必需的上下文和证据。这里的“纯 AI 做技术方案设计”指的是上述调研、检索、链路推理、代码核查、文档生成和覆盖检查由 AI 独立完成不再要求工程师先手工查完仓库、画完链路、写完方案再交给 AI。它并不等于取消人的职责。当出现业务取舍、跨团队接口承诺、数据口径、合规要求或高风险变更授权时AI 应停止猜测并发起明确的问题。人类介入的位置从“替 AI 收集所有资料”转为“裁决事实缺口和承担关键决策”。这个变化很大人不再是系统知识的唯一检索器而是知识质量和决策权的最终负责人。从 Harness 的角度看Skill 负责固化稳定流程、输入输出和边界Harness 负责组织上下文、工具调用、停止条件、证据校验和验证闭环基础模型负责推理、规划和动态编排。三者各自承担不同职责。只靠模型容易遗漏稳定约束只靠流程容易把模型能力锁死只靠文档则很难确保文档被正确加载和使用。5 什么样的方案才算可执行AI 写出一篇逻辑通顺的文章不难AI 写出一份可执行的技术方案要求高得多。一份好的方案至少应包含以下内容。首先明确涉及仓库和范围外参与方。大型需求经常需要多个服务、客户端、运营后台、配置中心甚至外部平台共同完成。方案要说明哪些仓库必改哪些系统只读不改哪些工作虽然必要但不在本方案覆盖内。否则实施阶段很容易出现“每个人都以为别人会做”的空档。其次给出术语对照和代码现状。PRD 语言、业务语言、配置名、服务名和代码名经常不一致。把它们一一映射出来既能避免搜索漏项也能把业务概念转换为具体工程对象。再次使用“复用、改造、新建”组织 Gap。复用不等于看到类似代码就直接调用必须确认用户、规则、状态、权限和风险语义是否一致改造要说明扩展点和存量兼容方式新建则要证明现有能力确实无法承载。然后是影响分析。被改造函数有哪些调用方异常会如何传播哪些存量行为必须逐字节不变修改一个字段、函数签名、缓存结构或配置项可能影响的并不只是眼前接口。方案如果没有这部分往往只是“改动清单”还称不上技术设计。验证部分同样不能只写“补充单测”。新增 API 要看契约测试修改状态机要覆盖核心流程调整消息要验证生产者和消费者兼容修改缓存要关注失效和降级涉及灰度和配置要有开关关闭时的存量行为回归。体验站三期方案中除了单测还给出了手工回归矩阵、异常传播链、需求覆盖矩阵和不改动约束这些内容共同构成了方案的可执行性。最后必须把未知信息留在文档里。待确认项不是方案不完整的证据恰恰相反无法通过现有资料证实的内容被明确登记才说明方案没有把推断伪装成事实。可以用五个问题检查一条需求是否真正被方案覆盖改哪里为什么改影响谁如何验证还有什么没有确认如果这五个问题都能回答方案才有可能进入研发执行。6 AI设计技术方案完备度衡量“技术方案完善度达到 95% 以上”—— 这是我们具体实践中团队同学对于AI 生成技术方案的完成度定下的目标。在这里它不是指 AI 能够预知所有线上情况也不是指任何需求都不需要人确认。它指的是在需求已经完成准入、关键知识能够回源、代码与配置得到核查、人工评审完成之后方案对主要工程问题的覆盖程度足够高。这个指标可以拆成六个维度需求覆盖PRD 条目是否逐项归属为“做、不做或待确认”系统覆盖涉及服务、仓库、配置、上下游和范围外参与方是否完整证据覆盖关键结论是否能回源到业务知识、架构事实、代码、配置或已确认文档风险覆盖兼容、异常、灰度、缓存、消息、状态机和安全约束是否被检查验证覆盖单测、契约、回归、监控、发布与回滚是否清楚不确定性治理未知和冲突信息是否被显式登记而没有被 AI 擅自补全。在“体验站三期”需求的案例中在原始需求完整度相对较高、且知识库体系完备的前提下我们使用当前一流的基模AI Agent 原生设计出来的技术方案覆盖度可以达到 95% 以上。剩余的不确定性通常来自跨团队决策、外部系统行为、数据口径和产品取舍。这些本来就不应由模型单独决定。把它们压缩到少量明确的问题而不是让它们以隐性风险的形式藏在方案里已经是很大的进步。至此我们的“技术方案设计Agent ”成功落地。知识库体系是“多场景 Agent”基建虽然本文知识库体系的主要落地场景是服务于“技术方案设计”但从实际作用价值的角度来看知识库是全流程复用的。比如技术方案设计和线上问题排查看起来是两件事但底层需要的能力却非常接近。方案设计是从需求向未来推演这个能力应该落在哪条链路上修改之后会影响什么。线上排查则是从现象向过去回溯用户看到的问题经过了哪些服务哪个配置、缓存、消息或下游依赖可能异常。两者都需要业务元语来理解问题究竟指什么都需要场景映射来找到入口都需要架构图谱来定位跨服务链路也都需要服务知识来检查状态机、配置、缓存和降级逻辑。在我们的线上问题排查 Agent 实践中同一套体系性知识正是其理解系统和缩小排查范围的基础。这意味着知识库建设的投入并不只服务于“让 AI 写代码”。它会成为研发调研、技术方案、代码修改、线上排查、事故复盘和新人理解系统的共同底座。一次把关键知识显式化可以在多个环节复用。**从“技术方案设计 Agent”到 “架构师 Agent”我们虽然是从技术方案设计切入并不是因为架构师的职责只有写技术方案而是因为技术方案设计恰恰是架构师最核心、最能体现系统性判断的一项工作。面对一个需求架构师需要理解业务意图定位跨系统链路识别服务边界和历史约束判断哪些能力可以复用、哪些地方需要改造并最终给出一条可验证、可落地的技术路径。这个过程的创新并不是某个模型天然比别人更会设计而是尝试把需求准入、业务隐性知识、跨服务图谱、服务内部约束、代码回源和质量验证连接成一条可维护、可执行、可持续演进的技术方案生产线。前面构建的业务知识、架构图谱、服务知识、渐进式上下文加载以及代码回源和证据验证本质上都不是为了让 AI 生成一份更漂亮的技术文档而是在逐步补齐 AI 完成架构判断所需要的知识、上下文、推理路径和验证能力。因此技术方案设计 Agent 并不是终点而是“架构师 Agent”的第一个具体落点。当 AI 能够稳定完成这条链路后同一套系统理解和技术判断能力还可以进一步扩展到需求增强、跨系统影响分析、架构评审、线上问题排查以及对 Coding Agent 的任务规划和技术约束。这些任务的输出不同但底层依赖的是同一种核心能力理解复杂系统并基于真实的业务、架构和工程事实完成判断。轻松扩展“架构师Agent ”的能力边界在实际研发流程中如果我们希望“架构师Agent”拥有排查线上问题的能力那我们只需要给其赋予对应的 LogHouse MCP、Service Runtime MCP 等能能力即可—— 在当前的基础上做“架构师Agent” 的能力边界扩展是很容易的事情。从这个角度看本文的价值不在于定义一个新的模型能力而在于尝试验证一种系统性的工程创新方法通过把原本分散在文档、代码、架构和工程师经验中的知识以及架构师完成判断所经历的流程逐步显性化、结构化并组织成 AI 可以理解、推理和验证的工程系统。技术方案设计是“架构师 Agent”的起点而把架构师的系统理解与技术判断能力逐步工程化、可执行化才是这项实践真正希望探索的方向。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】