2025年被称之为 Vibe Coding 元年，由于模型能力的增强，以 Claude Code 为代表，出现了大量低门槛的 Vibe Coding 工具，同时，低代码、可视化开发等技术也受到了很大的冲击。然而，Vibe Coding 带给企业的并非只有提效的优势，AI 生成发散，技术栈不受控，代码难以维护等问题严重影响了企业落地 AI Coding 。

本次分享会分析自然语言编程的问题，用 Spec Driven（规格驱动） 引入形式化约束来"降熵"，同时将 CodeWave NASL 可视化底座与 SDD 结合，构建从需求标准化→技术设计→ NASL 代码生成的完整 AI 软件工厂。技术上通过马具工程、渐进式上下文披露、沙箱隔离等手段保障长程任务稳定性，并建立 Benchmark 体系驱动模型微调迭代。通过此套实践，重塑 AI 开发工作流，实现企业级大规模应用的 AI Coding 稳定落地。

1. 为什么要用 SDD 来解决 Vibe Coding 的问题
   • 低代码 + AIGC 的思路及目前存在的问题：低代码 + AIGC 效果不及预期，难以度量，Vibe Coding 方式缺少必要的约束，质量不可控。
   • 48 年前的预言与分析问题本质：自然语言 + 软件工程局限性 → 引入 Spec 先行
   • 介绍 Spec driven，通过 Spec driven 解决 Vibe coding 遇到的问题
   • 两套形式化的发展和对比：从 AI Coding 到 AI + 可控底座，从低代码到拥有自研语言的低代码到 Spec Driven
   • 结合低代码的规范和最佳实践，实现 Spec Driven 驱动的可视化开发模式，让 AI Coding 支撑大规模企业级应用的开发
2. 产品介绍：围绕需求标准化（Spec First）的开发平台
   • 基于 Spec-Driven 理念的企业级全栈开发平台，及 SDD 核心：需求工程（EARS 标准化、消除模糊词、量化非功能需求）的介绍
   • 老应用历久弥新：基于 SDD+Code2Sepc 的逆向工程
3. 技术方案：大规模 SDD 任务的 Harness Engineering 实践
   • CodeWave平台架构介绍：AI 友好的平台底座
   • 代码智能体底层：需要什么样的 Code Agent（开源 Wave-Agent 介绍）
   • 围绕 NASL 生成的 SDD 全链路介绍
   • "马具工程"到底是什么
     • 需求标准化：上百页需求如何塞进上下文窗口
     • 技术设计：如何生成给架构师看的完整文档
     • NASL 代码生成：海量上下文下的任务稳定性保障渐进式披露：私有知识如何避免上下文遗忘
     • Compound 复合工程：让 AI 越跑越精准
     • 文档解析：RAG 知识工程能力复用
     • 多模态支持：UI 理解与图片意图判断
     • 沙箱技术：智能体运行时核心（Bubblewrap）
     • 总结：马具工程设计原则 — 解决长程任务稳定性
4. Benchmark：数据驱动的产品与语言模型训练
   • 核心痛点：提效难度量 / 产品能力难度量 / 效果达不到预期
   • No Data No BB — 建立 AI 功能的 Benchmark 体系
   • 建立 AI 提效的量化标准
   • 语言能力的瓶颈如何量化：行业 Benchmark（HumanEval）
   • 选择模型基座的标准（代码生成/补全/推理能力）
   • 微调自己的大语言模型（数据构造 → SFT → DPO 偏好对齐）
   • AI Infra：工程化平台支撑 AI 功能迭代与微调闭环
5. 总结与展望
   • Spec Driven 的本质：通过形式化来"降熵"
   • CodeWave 可视化软件工厂 vs AI Coding IDE 对比
   • 未来规划

您认为，这样的技术在实践过程中有哪些痛点？

• 原始需求到标准化需求到 NASL 代码的关联
• 长时复杂任务的稳定性和可干预性
• 需求到代码生成的准确率、完整度和验证

演讲亮点

• Spec Driven 的形式化约束方案
• 需求标准化-EARS 驱动的需求工程与多模态解析
• 大规模 AI Agent 的 Harness 实践
• 私有化语言模型能力训练与AI效果量化

听众收益

• Spec Driven 方式在低代码可视化开发领域的落地及面向未来的软件生产方式
• Coding Agent 的设计与优化方案
• 大规模需求管理的需求工程思路
• 复杂 AI Agent 的 Harness engineering 实践
• 构建并训练开源私有化模型实现 ToB 商业交付

面对AI编码实践中暴露出的研发流程低效（如需求理解偏差、多轮调试）和编码质量不可控（如单文件臃肿、代码纠缠、前后端耦合、缺乏架构约束）两大核心问题，我们团队一直在持续不断的迭代优化实践经验，前期实践分享无论在内网还是外网都获得广泛认可。本次分享结合团队实战经验，融合Spec-Kit的规范严谨性与OpenSpec的轻量敏捷性以及当前主流技术，创新提出 “Rules + Spec + Skills”三位一体全栈AICoding架构，进一步提高研发效率：

1. Rules（宪法级规则）：将工程目录结构、技术栈、架构模式等全局信息固化为“项目宪法”，确保AI生成内容与现有系统完全兼容；
2. Spec（场景化规范）：针对前后端差异设计专属需求分析模板（前端重交互逻辑，后端重业务规则），并前置表结构、错误码、依赖分析等逻辑设计，强化需求完整性与可实施性；
3. Skills（自动化能力包）：封装动态路由的任务流程（如“分析工程→分析需求→编码实现→归档”），实现意图识别、规范加载、代码生成、DDL/接口文档自动生成的一站式闭环，真正达成“用户无感、过程透明、高度自动”。

该方案已落地验证：支持0门槛上手、极简过程文件、高质量生码、易扩展复用。其本质是——在AI消融技术门槛的时代，将开发者角色从“写代码”升维为“定义问题+设定规则”，以规范为锚、以自动化为翼，实现人机协同效能的最大化。

演讲提纲

1.  AI 编码的本质思考及挑战：AI编码工具层出不穷，为什么依然写不好生产级代码
   • AI编码的“幻觉”本质
   • 生产级编码应用面临的挑战
   • AI编码对程序员认知的转变
2.  AI编码方案的探索：如何低门槛让AI高效写出可控的生产级代码
   • 让AI写出质量可控的生产级代码
   • 系统架构的兼容与落地
   • AI生码质量和效率的平衡
   • AI编码方案的规模化可复用
   • AI编码方案的自由扩展性
3.   AI编码方案的演进：AI编码方案随着新技术的出现不断迭代升级，紧跟AI技术潮流
   • AI编码范式的发展及演进
   • AI编码主流技术分析及对比
   • Rules+Skills+Spec三位一体AI编码方案的形成
   • 构建自我反思与规范迭代的持续进化机制
4. 中后台全栈研发的破局：突破技术栈限制，AI助力走向全栈开发
   • 前后端研发技术的特点分析
   • 研发规范的分而治之
   • 前端研发实践的三种模式
5. AI编码质量的保障：人机协作，多维度共同保障AI编码质量
   • 需求分析阶段的澄清至关重要
   • 多维度的代码质量审查
   • 构建审查->优化->再审查的闭环机制
   • 人作为监督者的不可或缺
6. AI编码方案的推广及运营：如何让大家轻松接受AI，提升团队整体AI能力
   • AI编码指标牵引
   • 营造AI编码氛围
   • 运营推广，助力全员AI
7. AI编码未来的演进方向：迈向全自动智能研发闭环
   • 跨应用AI研发任务的智能化拆分
   • 测试驱动的更加完善的AI迭代保障机制
   • 构建“研发-测试-部署-运维”全链路AI智能化协作生态

这样的技术在实践过程中有哪些痛点？ 

1. 面对不同团队可能需要调整规范（具备高扩展），在实践的过程中不断迭代演进；
2. 无法确保生成100%符合预期的代码，研发人员作为Review者的角色很重要；
3. 面对跨应用需求，当前阶段还不能自动根据应用拆分需求，需要人工界定需求边界。

演讲亮点

1. 融合Spec-Kit的规范严谨性与OpenSpec的轻量敏捷性，比OpenSpec更轻量，具备高扩展，自适应工程架构。
2. 弥补了Spec-Kit和OpenSpec在编码阶段缺少的编码规范，这套规范在我们的前期实践中已经得到了质量验证，产出更高质量的代码。
3. 洞察前后端研发特点（前端更注重交互逻辑，后端更侧重业务逻辑），拆分出前、后端不同的研发规范，遵循统一套流程，真正做到前后端全栈。
4. 对用户更友好，0门槛上手，无需特别指令（commands），全程自动识别用户意图、自动加载相关技能及规范，用户只需聚焦于需求分析的正确性、完整性

听众收益

1. AI编码当前主流技术，以及各技术优缺点；
2. AI如何生成得以控制的高质量代码；
3. AI生成的代码如何跟当前工程架构兼容；
4. 如何实现团队级的研发提效，打造适合自己团队的研发范式，而不是每人一套方案；
5. 一套基于Rules+Spec+Skills方法论打造的高质量可复用的AI全栈开发新范式，有助于沉淀团队级的研发范式，提高人机协作效率。

随着AI Coding技术的飞速发展，大模型能力不断增强，MCP、Skills等工具协议日趋标准化，智能体的能力边界不断扩展。然而，一个根本性挑战始终存在：模型上下文窗口的限制。在企业级复杂编码场景中，如何在有限的上下文窗口内让大模型高效完成任务，已成为制约AI编码落地的关键瓶颈。同时，企业内部用户群体多元化，需求各异，如何平衡标准化与个性化，是另一个亟待解决的难题。

本次演讲将深入分享JoyCode在京东内部的真实实践经验，探讨我们如何突破这些挑战，构建真正适用于企业级场景的AI编码解决方案。

演讲提纲

1. JoyCode面临的核心挑战
   • 业务场景复杂：专业壁垒与自研生态京东作为电商巨头，业务场景极其复杂，涉及零售、物流、金融、健康等多个专业领域。
   • 大量自研框架、中间件和业务组件构成了独特的技术生态，这对AI编码工具提出了极高的专业领域知识要求。
   • 用户画像丰富：千人千面的需求图谱从初级开发工程师到资深架构师，从业务开发到基础架构，从敏捷团队到传统瀑布模型，京东内部用户群体呈现出高度多元化的特征。不同角色对AI编码工具的期望和使用方式存在显著差异，如何满足多样化的需求成为一大挑战。
   •  复杂长任务：上下文膨胀的困境企业级开发任务往往涉及跨模块、跨系统的复杂变更，单次任务可能需要理解数千个文件、数十个服务。这种复杂性导致上下文迅速膨胀，远超模型的处理能力，形成"上下文爆炸"的困境。
   • 超大代码仓：海量上下文的理解难题如庞大的代码海洋中，如何快速定位相关代码、理解业务逻辑、避免重复造轮子，成为AI编码工具必须解决的核心问题。
2. JoyCode的创新解决方案
   • 企业知识增强：构建智能化的知识基础设施
     • RepoWiki：代码知识的三维可视化：我们将代码仓库转化为可交互的知识图谱，通过RepoWiki实现代码结构、依赖关系、业务逻辑的三维可视化。这不仅帮助AI更好地理解代码上下文，也让开发者能够直观地探索代码库，快速定位关键信息。
     • 企业知识融合：打通内部知识平台：通过与京东内部知识平台深度集成，我们将产品文档、技术规范、最佳实践、历史经验等企业知识无缝融入AI编码流程。当开发者编写代码时，AI能够实时引用相关的业务规则、技术标准和历史决策，确保代码符合企业规范。
   •   智能体能力增强：构建多层次的智能协作体系
     • Skills生态：按需加载的能力扩展：基于标准化 Skills 框架，我们构建了可插拔的能力生态系统。根据任务需求动态加载相应的工具和技能，既保证了功能的丰富性，又避免了资源的浪费。
     • 多智能体协同：团队智能体+自定义智能体+企业知识的三位一体：有效应对不同用户群体的多样化需求。
     • 自主规划生成：Spec+TRD+Rules 智能化代码生成：通过整合技术规范（Spec）、技术需求文档（TRD）、编码规则（Rules），实现了业务特色代码的自主规划和生成。
   • 上下文工程管理：突破窗口限制的技术创新
     • 多路检索引擎：精准高效的代码定位：重点打磨检索工具，多路并行的检索策略，实现了按需读取，大大提升了上下文获取的效率和准确性。
     • 外置记忆系统：窗口有限，记忆无限：将短期记忆外置存储，构建了持久化的上下文记忆系统。AI能够记住之前的对话内容、代码变更历史和用户偏好，实现跨会话的连续协作。这种"窗口有限，记忆无限"的设计理念，从根本上突破了上下文窗口的限制。
     • 代码图谱：海量上下文的快速理解：通过构建代码图谱，将代码库转化为结构化的知识网络。AI能够通过图谱快速理解代码间的复杂关系，识别关键节点和核心路径，在海量上下文中迅速定位关键信息，大幅提升理解效率。
3. 未来趋势：一切尽在上下文
   • 自主规划：基于全面的上下文理解，AI自主设计最优实现路径
   • 异步委派：复杂任务异步执行，上下文持续积累，结果主动推送
   • 可观测评估：上下文驱动的任务监控与质量评估体系

这样的技术在实践过程中有哪些痛点？ 

1. 上下文窗口限制与复杂场景的矛盾
   • 上下文爆炸：企业级复杂长任务导致上下文迅速膨胀，超出模型处理能力
   • 专业领域知识鸿沟：大量业务特定知识和自研框架增加了理解难度
2. 多样化用户需求的平衡挑战
   • 用户画像复杂：不同角色（开发、测试、架构师等）有截然不同的使用场景和期望
   • 个性化需求冲突：标准化工具难以满足所有用户的特定需求
3. 知识孤岛问题
   • 企业知识分散：内部知识平台与编码工具割裂，无法有效融合

演讲亮点

1. 创新的上下文工程技术
   • RepoWiki 可视化：将代码知识转化为可交互的知识图谱，实现代码结构的直观理解。
   • 多路检索 + 按需读取：突破传统全文检索局限，实现精准、高效的代码定位。
   • 外置记忆系统：创造性地将短期记忆外置存储，实现“窗口有限，记忆无限”。
2. 多智能体协同架构
   • 团队智能体 + 自定义智能体 + 企业知识：各司其职又协同工作。
3. 企业级知识工程
   • 知识平台打通：实现内部知识平台与编码工具的无缝融合。
   • Spec + TRD + Rules：完整的业务特色代码生成框架，确保输出符合企业规范。

听众收益

1. 实用的技术解决方案
   • 可落地的上下文管理策略：直接可用的超大代码库处理方案。
   • 多智能体设计模式：企业级 AI 工具的产品架构参考。
   • 知识工程实施路径：企业知识如何有效融入 AI 编码工具。
2. 避免常见陷阱
   • 用户需求平衡策略：如何在标准化与个性化间找到平衡点。
   • 知识孤岛破解方法：企业知识如何有效沉淀和复用。
3. 前沿技术趋势洞察
   • 记忆系统演进方向：从简单提示工程到复杂记忆架构的发展趋势。

我们在蚂蚁内部建设了可视化 AI Coding 平台，目标是让非技术同学也能用“对话+可视化编辑”快速做出可交付的网站与系统。随着用户从尝鲜进入投产阶段，平台面临的核心挑战不再是“能生成”，而是“稳定交付”：长对话与大工程上下文膨胀、生成质量与一致性、上线部署与安全、以及用户中途离开导致的任务中断等。我们采用“框架约束 + 受控工具链 + 自愈交付”的方案：通过约定式全栈框架与脚手架降低发散，引入实时校验，构建失败自动修复与离线容器续跑并通知，保证结果可用。当前平台 MAU 已达 1 万+，线上运行应用/运行时规模 1 万+。本次分享关键选型、工程细节与踩坑经验。

演讲提纲

1. 背景：AI 普惠不是“给工程师提效”，而是“让全员都能交付”
   •  Muse 的定位：可视化在线 Vibe Coding + Coding Agent，让非技术岗位也能做应用/网站
   • 阶段变化与规模信号：从 0-1 探索到 1-N 投产（MAU、运行时规模、典型用户画像可点到）
   • 主线金句：Coding 越来越不重要，交付才是关键
2. 从 Vibe 到交付：非技术用户的“成功路径”长什么样
   • 用户旅程：一句话需求 → 生成页面/功能 → 调整 → 接数据/权限 → 发布 → 运行与迭代
   • 为什么 GUI 仍重要：降低启动门槛、帮助表达意图、让结果可见
   • 但为什么“结果优先”：用户不关心代码，只关心稳定可用与可分享
3. 规模化投产的六大问题域（总览）
   • 超长轮次对话、超大工程/大仓库、能力膨胀（skills）、稳定性与部署、生态链接、权限与数据
   • 这些问题来自真实业务规模化使用，不是 demo 阶段问题
4. 解法 1：超长对话与不稳定——上下文工程 + 文件即记忆
   • 上下文治理：分层记忆、加载/卸载、把“长期状态”外化成工程文件
   • 文件即记忆：spec/runbook/readme_for_agent 等，让 Agent 每次可稳定读取与续作
5. 解法 2：超大工程/大仓库——索引化与工程地图（CodeMap）
   • 核心判断：全仓塞进上下文不可持续
   • CodeMap：基于语言服务（LSP/tsserver）+ 构建依赖信息形成工程地图
   • 文件系统 read/write 工具：支持增量改动、边界控制与验证闭环
6. 解法 3：能力膨胀——skills 按需加载 + Agentic 决策
   • 意图理解路由：不同任务加载不同 skills（生态/数据/页面美化/检索等）
   • skills 产出落盘：结果文件化，支持复用与“无限上下文”的外部承载
7. 解法 4：让用户只看结果——稳定性链路与自愈交付
   • 事前：前置指导/脚手架/约束/最佳实践，让默认写对
   • 事中：LSP/TSC/Lint 等检测进入 Agent 流程，边生成边校验
   • 事后：构建错误静默修复；离线容器续跑 + 通知（人走了活还继续干完）
8. 解法 5：交付链路——内外网托管 + 生态链接 + 权限数据一体化
   • 托管部署：内外网、独立域名、高可用/抗流量、安全生产要点
   • 生态链接：钉钉/语雀/项目管理/ODPS/代码仓库，真正“接入工作流”
   • 权限与数据：一体化数据库、对话改表、默认安全、2088/内网登录、低门槛但企业级
9. 反推底座：三项硬需求（AI-native 全栈能力栈）
   • MuseJS 全栈框架（对等 Next.js）：约定式工程形态 + 内置最佳实践 + Agent 友好
   • Sandbox：安全隔离、可控工具调用、可审计/可回放、离线执行
   • 一体化数据库（对等 Supabase）：默认安全 + 权限合规 + 面向峰值可用
10. 趋势判断：Coding Agent 将如何重塑平台与协作
    • Token 入口与 Agent-first 文档（readme_for_agent.md）成为关键资产，GUI 可能腐化
    • 新协作形态：任务/变更轨迹驱动的协作层（不仅是 PR）
    • Supervisor 展望：多 agent 调度、容器化执行，“干到成功为止”
11. 收尾：AI 普惠的关键不是“更强模型”，而是“更强交付系统”
    • 复述主线：让每个员工都能产出业务价值
    • Takeaways：低门槛启动、工程化治理、交付链路、生态/权限/数据、Agent-first 资产化

这样的技术在实践过程中有哪些痛点？
主要痛点是多维取舍：低门槛 vs 企业级复杂度（权限/数据/上线不可避免变复杂），自由度 vs 可控性（约束越强越稳但不够灵活），成功率 vs 成本/时延（校验与自愈越多越慢越贵），自动修复 vs 可解释性（修好了但用户不知道改了什么），生态集成 vs 安全合规（接得越深风控与治理成本越高）。

演讲亮点 ：

1. 交付链路内建的工程化闭环：不是只做“生成代码”，而是把类型/语义校验与构建运行反馈纳入同一条 Agent 流程，并支持失败自动修复、离线续跑与结果回传，使生成过程具备可验证、可收敛的生产特性。
2. 面向大工程的上下文治理：不依赖“全仓塞进上下文”，而是以文件系统读写工具为基础，结合语言服务索引构建 CodeMap（符号、引用、依赖与入口点），让 Agent 能按任务召回上下文、增量改动并控制变更边界，降低大仓库场景的误改与不可控。

听众收益 ：

1. 一套可复用的“Coding Agent 投产方法论”：从生成到交付的工程闭环（校验、构建反馈、自愈、离线续跑），以及如何把不确定性收敛到可治理的生产系统。
2. 大仓库/长上下文下的落地实践：如何用语言服务索引构建 CodeMap，配合文件级增量编辑与变更边界控制，避免“全仓上下文”带来的性能与误改问题。
3. 面向企业内规模化推广的关键设计点：如何在低门槛体验与企业级安全/权限/合规之间做取舍，并通过运行时隔离、工具调用治理与审计机制保证可控。

随着 Coding Agent 走向真实研发流程，越来越多团队发现问题并不在模型能力，而在于 Agent 难以持续优化：行为不可控、效果不可量化、优化高度依赖少数专家。本次分享结合实际落地经验，介绍我们如何通过 Feedback Loop、Benchmark 与 Agent Engineers 构建一个可运转的 Coding Agent 飞轮。

我们通过工程化的反馈闭环采集 Agent 的真实使用信号，引入贴近生产环境的场景化 Benchmark，对 Agent 行为进行持续评测，并推动研发团队整体转型为 Agent Engineers，使 Agent 的设计、评测与演进成为日常工程活动的一部分。

演讲提纲

1. 背景与问题
   • Coding Agent 在真实工程中遇到的三个问题：不可控 / 不可评测 / 不可规模化
   • 为什么“模型更强”并不能解决这些问题
2. Feedback Loop：让 Agent 的行为可观测
   • 如何采集真实使用反馈，而不是只看显式评分
   • 结构化记录 Agent 决策、工具调用和用户采纳行为
3. Benchmark：评测比生成更难
   • 通用 Benchmark 与真实研发场景的差距
   • 构建场景化、多维度 Benchmark 的实践
4. Agent Engineers：人如何进入飞轮
   • 不再区分前后端/算法/平台角色
   • 研发人员统一参与 Agent 的设计、评测与优化
5. 飞轮如何跑起来
   • Feedback Loop 提供信号
   • Benchmark 指导优化
   • Agent Engineers 承接持续演进

这样的技术在实践过程中有哪些痛点？

• 真实反馈难获取，且质量不稳定
• 离线评测结果难以指导线上优化
• Agent 能力过度依赖个体经验

演讲亮点

1. 从“调模型”转向“调系统”：多数方案聚焦模型或 Prompt，而本方案以工程闭环为核心，强调可观测、可评测、可回滚的 Agent 行为设计。
2. 把“人”纳入飞轮，而不是排除人：不追求“全自动 Agent”，而是通过 Agent Engineers 的组织设计，让人持续参与 Agent 演进，避免黑盒化。

听众收益

• 一套可落地的 Coding Agent 工程实践框架
• 对 Agent 评测和反馈设计的实战认知
• 对 Agent 时代研发组织演进的可操作思路

随着大模型与 Coding Agent 的推理和执行能力持续迭代增强，研发团队在 AI Coding 落地方面已迈入深水区。AI 具有极强的可塑性，我们通过对实际项目工程的持续探索与实践，在试点的高频迭代复杂业务系统中，AI 入库代码占比已达 60%。同时，我们对 AI 如何驱动业务平台开发形成了新的解读：即通过“设计+规范”、“知识+工具”、“模式+流程”三大驱动，实现 AI 模型与工具的能力增强与研发团队工程优化的双向管齐下与双向奔赴。

演讲提纲

1. 平安爱码：平安科技上万开发者的Coding Agent，研效提升的"曲率引擎"
   • 平安爱码Agent的形态和能力概述
   • 2025年平安爱码赋能研效提升成果
2. 核心实践：金融级“严谨”AlCoding的四大支柱
   • 规范驱动：核心实践构是建提质提效的 AI 规范驱动开发，我们在大型业务平台系统工程落地 AI Coding 的过程中，开展了两大规范驱动实践：
     • 首先，沉淀 AI 开发指导规范：针对前后端业务功能及技术任务细分，体系化梳理形成开发指南，作为 AI Agent 产能释放的关键，有力支撑了 60%的 AI 代码占比。
     • 其次，实现代码质量强约束与AI“自愈”：借助 AI 将项目私域的架构设计与代码规范批量转化为 Lint、ArchUnit、P3C 等 CI 工具，无论是人工还是 AI 产出的代码，均须通过强制校验，将无形规范转化为有形约束，显著提升人机协作的代码一致性。
   • 知识工程：核心实践是如何沉淀一个大型业务系统的结构化私域知识，大型业务系统代码库动辄百万行，涉及大量企业私域的业务概念与规则，通用大模型难以精准理解。我们通过“软件项目知识银行“的实践，将一个软件系统关键知识利用图数据库、向量数据库及文档数据库等针对性结构化存储，并通过 MCP 将知识外挂赋能 Coding Agent，补齐模型的私域业务认知短板。
   • 上下文工程：核心实践是分场景精准管理上下文，确保 Coding Agent 在每次大模型请求时携带任务相关的精准上下文。基于一线研发实践，我们将核心任务场景划分为三类：项目功能开发、项目理解分析、项目开发质量保障，每一大类上下文又进一步细分。通过细分场景所需的具体规范、知识与工具，实现高质量私域上下文的精准加载。
   • 人机异步协作：打造“睡后编程”人机流程，我们AI Coding研发的先锋团队已开始全面转型异步协作模式，开发人员在工作日一定时段会调整工作重点（每日下午后两小时及周五下午）从传统开发转向布置 AI 异步开发任务，挖掘夜间及周末等非工作时间价值。通过实施 How-to/To-do两阶段异步开发模式，最大化研发时间的利用率提升人机异步产出。
3. 总结与展望：Coding Agent持续演化
   • 过去是，等等指令的"实习生"
   • 当前是，只认文档的"外包团队"
   • 下一步，主动规划的"技术合伙人"

这样的技术在实践过程中有哪些痛点？ 

1. 很多项目的开发架构缺乏 AI 亲和严重制约了 AI Coding 在项目上的落地和发挥效果。开发架构在 AI 时代会异常重要，我们也在持续探索什么样的代码工程结构和代码组织方式是比较有利于 AI 开发的？比如 单体、微服务、模块化宏服务，前后端分离与前后端整合等怎么来提升 AI Coding 的效果？
2. AI Coding 的编程推理模型持续在迭代能力越来越强，但是模型和项目代码库之间的隔阂全靠 coding Agent 的上下文来对齐，上下文窗口一直在扩展但是也是有限的，如何在有限的上下文上支持研发过程中多个种场景的 AI 提效，如项目理解场景、功能开发代码生成场景、质量保障场景等？
3. 我们也在推动开发人员在 AI 加持下面的角色左移和右移，希望打造既懂业务又懂技术的前线交付工程师，全流程端对端怎么搭建稳定高效的 agentic 工作流？目前我们有一些局部尝试断点较多，特别在行业属性合规和准确要求高的要求下如何在端到端的 AI 开发上发力？

演讲亮点

• 平安科技 AI 编码实践案例
• 金融行业独家严谨 AI Coding 之道

大模型与 Coding Agent 让“生成代码”变得容易，但在真实研发流程中，企业遇到的核心矛盾已经从“能不能写”转向“能不能稳定交付、能不能容易落地”：需求理解与实现经常漂移，AI 产出缺少一致性约束，质量与回归验证成本被放大；同时如果“人 / Agent”无法在同一迭代内顺畅切换（交接成本高、上下文补齐不成体系），AI 往往只能停留在局部试点，难以规模化复制。

与此同时，AI 工具与平台迭代速度极快，很多自研流程或能力很快会被更成熟方案替代。真正长期有效、且形成组织差异化竞争力的，是部门级研发资产：规范、契约、知识、门禁、测试证据、历史经验的结构化沉淀和项目级基座。

本次分享聚焦：我们如何将 AI 从“个人效率工具”升级为“可复制的工程能力”——以 PRD→上线 SOP 为骨架，以工程资产化为底座，用“Work Item 最小交接包 + 单一事实源 + 门禁化流程”让人/Agent 可自由接力；并在小范围探索 DeepWiki 类的 Doc↔Code 双向联动与 git diff 驱动测试验证，让 AI 的价值可承接、可验证、可演进。

演讲提纲

1. 从 Vibe 到交付：为什么“模型更强”依然不够
   • AI Coding 的三类交付性问题：发散、漂移、不可验证
   • 企业级落地的目标：可承接 / 可回滚 / 可度量 / 可规模化
   • 真正卡点不是“会不会写”，而是“能不能接得住 + 换得动”（人/Agent 自由切换）
2. PRD→上线 SOP：让 AI 进入“确定性交付”链路
   • PRD 自然语言如何转化为可版本化的 Spec/契约输入
   • 接口与约束前置：单一事实源（契约、口径、权限、验收点）
   • 研发阶段：AI 参与边界与门禁化协作（模板/规范/结构化 PR）
   • Review 与测试：从“看实现”到“核对契约 + 验证证据”
   • 上线与治理：线上信号回收 → 反哺规范/测试/资产库
   • Hybrid Execution Protocol（混合执行协议）：同一迭代内按 Work Item 粒度“人/Agent 自由切换”
   • 缺口门禁：Agent 先自检缺口→问题清单→补齐→再 plan→code→verify
3. 工程资产：让 AI 稳定输出的“护城河”
   • 项目级资产：Spec、接口契约、验收清单、埋点/稳定标识、回归策略
   • 团队级资产：组件/模板、规范、风险模式库、测试资产
   • 部门级资产：质量门禁、评测口径、历史缺陷与影响面知识
   • 工具会快速迭代，资产决定长期复利
   • Repo OnBoarding（存量冷启动）：一次性生成 MVP 项目基座 + 后续“文档自然长出来”的增量机制
4. Doc 与 Code 双向联动：从“文档同步”到“工程事实回流”
   • 基于 DeepWiki / deepwiki-open 的代码库语义化入口
   • 需求→代码：从 Spec 定位实现与风险点
   • 代码→文档：从接口/测试/变更生成“证据摘要”，降低漂移与知识断层
5. git diff 驱动测试验证（试点）：变更触发的验证闭环
   • diff → 结构化变更信号（接口/schema/权限/关键模块/SQL 等）
   • 影响面映射 → 回归集推荐（必须跑/建议跑/可跳过）
   • 验证证据产出：把“回归选择与结果”沉淀为可追溯资产
   • 目标：把“靠经验选回归”升级为“可解释、可复算”的变更验证
6. 未来一年：标准化、闭环化、基座化
   • 资产标准化：面向新人/实习生/全栈初尝者的上手路径（模板、清单、示例库、门禁）
   • Doc↔Code 闭环跑通：需求变更与工程事实的双向回流
   • 部门级资产基座化：以资产驱动的 AI 全栈 Advisor（建议/风险/验证路径）

这样的技术在实践过程中有哪些痛点？

1. PRD→Spec 的图片信息不稳定：当关键交互依赖截图/大图表达时，模型对状态/边界/异常分支抽取容易偏差，导致 spec 口径漂移；需要通过“关键交互文本化/状态机化/验收清单化”补齐。
2. Repo 深度扫描的安全 vs 准确率两难：DeepWiki 类全量扫描在企业环境存在权限/数据出域等安全顾虑；deepwiki-open 等本地化方案在复杂仓库上准确率不足，短期难成为唯一事实入口，只能先走“迭代归档 + 基座增量生长”的渐进路线。
3. Token 成本：复杂任务天然 token 大、优质模型单价高。 当进入“多轮补齐 + 结构化 Review/归档”这类重推理场景时，即使流程做得很规范，token 消耗仍会显著上升，带来直接费用压力。

演讲亮点

1. Hybrid Execution：人 / Agent 自由切换：同一迭代按 Work Item 最小交接包推进，任何时刻都能把任务从人切给 Agent、或从 Agent 切回人而不中断。
2. /implement 内置“缺口门禁”：不是人判断上下文够不够，而是 Agent 先做缺口扫描并输出问题清单；补齐到阀值后才进入 plan → code → verify。
3. 补齐后自动回写，治理漂移：人补充信息后，Agent 自动判断是否需要同步更新 design / spec / 项目基座，用“回写”锁住一致性。
4. Repo OnBoarding：老项目冷启动：先用初始化 Skills 扫目录/入口/依赖/公共模块/历史坑位，产出 项目级 MVP 基座文档；后续迭代增量回写，文档自然生长。
5. 单一事实源：四类资产把输入面写死：spec（语义基线）+ design（Work Item/验收）+ 基座（宪法/约束）+ OpenAPI（接口事实源），让 AI 写代码不靠“聊天记忆”。
6. 提测前 Review + 测试补充建议：Review 不止审代码：基于 diff + spec + 测试用例清单，输出技术问题清单 + 用例增量建议/必跑回归，降低漏测。
7. 上线后迭代归档 + 基座回写：上线稳定后用 diff 生成版本归档：改了什么、影响什么；并自动判断是否需要更新项目基座。

听众收益

1. 一套可复用的 PRD→上线 AI 交付 SOP（如何定义输入基准、过程约束、结果门禁）；
2. “工程资产驱动 AI”的方法论：哪些资产最关键、如何沉淀为组织能力；
3. Hybrid Execution：人 / Agent 自由切换的落地方法；
4. Doc↔Code 双向联动的落地思路：如何用 DeepWiki 类能力降低需求—实现漂移；
5. Repo OnBoarding：老项目冷启动与“文档自然生长”机制；
6. Doc↔Code + diff 驱动验证的闭环框架；
7. 面向未来一年的演进路线：从团队能力到部门级资产基座，再到 AI 全栈 Advisor。