它不是投资建议，也不是基于单一叙事得出的结论。它把“AI 导致白领失业、中产危机、一人公司、资产重配”等问题放进更大的证据框架里，区分确定性、分歧点和可观察信号。

0. 核心结论

我对未来 5-10 年的判断可以浓缩成一句话：

AI 不会平均地替代所有工作，而会先替代组织中的“任务层”和“入门层”，再重写公司用人、教育回报、财富分配和个人资产逻辑。真正的风险不是某个岗位消失，而是社会原来依靠学历、专业资质、公司雇佣和房产升值串起来的中产路径同时失灵。

更具体地说：

1. 最先塌陷的不是最高端专家，而是“可被标准化评估的初级白领任务”。 写初稿、查资料、做表格、初级代码、合同初审、客服、营销素材、数据清洗、PPT、测试、简历筛选、基础财务分析等，会成为企业降本的第一层。
2. 岗位不会按职业名称整齐消失，而会按任务包被拆开。 “律师、医生、程序员、咨询顾问”不会整体消失，但其中大量可流程化、可检查、可由 senior 复核的任务会被 AI 接管。
3. 公司用人逻辑会从“人力扩张优先”转向“AI 能力扩张优先”。 Shopify CEO Tobi Lutke 的内部备忘录把“AI 使用是基线期待”公开化，并要求团队在要人头或资源前先证明 AI 做不了。这不是个案，更像未来知识型公司的管理范式样板。
4. 学历会继续有价值，但其价值从“就业门票”变成“筛选信号之一”。 如果大学不能提供真实项目、行业网络、判断力训练和高质量实践，单纯文凭会继续贬值。
5. 财富分配压力会比技术失业本身更难处理。 AI 的生产资料主要是模型、算力、数据、分发渠道、资本和组织能力，天然更容易集中在少数公司与资产所有者手中。IMF 已提醒 AI 可能显著扩大财富不平等。
6. 一人公司会变多，但不是人人都能靠一人公司活得好。 AI 降低生产门槛，同时也制造供给过剩。稀缺性会从“会做东西”转向“知道做什么、卖给谁、如何建立信任和分发”。
7. 个人最重要的资产不再只是房产或学历，而是可迁移现金流能力。 包括 AI 工作流、行业洞察、客户关系、可验证作品、可复用数据、分发渠道、信用和流动性。

1. 证据底盘：我们到底知道什么

1.1 AI 暴露面很大，但“暴露”不等于“完全替代”

IMF 在《Gen-AI: Artificial Intelligence and the Future of Work》中估计，全球约 40% 的就业暴露于 AI；发达经济体约 60% 的工作暴露于 AI，其中一部分可能被增强，一部分可能被负面影响，包括劳动力需求下降、工资下降甚至岗位消失。
来源：IMF, 2024

OECD 的口径更谨慎：2023 年《Employment Outlook》认为，综合 AI 和其他自动化技术，OECD 国家约 27% 的岗位处于高自动化风险；但截至当时，还没有明显证据显示 AI 已经造成总体劳动力需求下降。
来源：OECD Employment Outlook 2023

ILO 的研究也强调：生成式 AI 更可能先改变任务结构和工作质量，而不是立刻让大多数职业消失；自动化和增强会同时发生。
来源：ILO, Generative AI and Jobs, 2025

判断： “AI 影响巨大”是高确定性；“大规模净失业会在几年内必然发生”仍有不确定性。更稳妥的表达是：白领任务的重组已经开始，入门岗位和中间层岗位的数量、工资、晋升路径会先受压。

1.2 生产率提升是真的，但宏观收益大小存在巨大分歧

乐观派以 Goldman Sachs 为代表。其 2023 年研究认为，生成式 AI 可能在十年内推动全球 GDP 增加约 7%，生产率增长提高 1.5 个百分点，并使相当于 3 亿个全职岗位的工作暴露于自动化。
来源：Goldman Sachs, 2023

微观层面的实验也支持“AI 能提升某些岗位效率”。Brynjolfsson、Li、Raymond 的客服研究显示，AI 助手让客服平均生产率提高约 14%，对新手和低技能员工提升更大。
来源：NBER, Generative AI at Work

但谨慎派如 Daron Acemoglu 认为，生成式 AI 对未来十年全要素生产率的提升可能远低于市场叙事，原因是很多可自动化任务占 GDP 的份额有限，现实部署也有摩擦。
来源：NBER, The Simple Macroeconomics of AI

OECD 的宏观估计介于两者之间，认为 AI 可能在未来十年显著贡献生产率，但幅度取决于扩散速度、组织重构和互补投资。
来源：OECD Ecoscope, 2024

判断： 未来真正决定就业冲击的，不是模型 demo 有多强，而是“企业是否能把 AI 嵌入流程、考核、预算、人头审批和客户交付”。AI 的宏观生产率红利可能滞后，但对某些白领任务的微观冲击会先发生。

1.3 企业用人范式正在变：AI 先于招聘

Shopify 是标志性案例。2025 年 4 月，CEO Tobi Lutke 公开了内部备忘录，称“反射式使用 AI 已是 Shopify 的基线期待”，并把 AI 使用纳入绩效和同侪评价；团队申请新增人手或资源前，需要说明为什么不能用 AI 完成。
来源：Shopify 官方文章、Tobi Lutke 原帖

The Verge 对此总结为：新招聘需要证明 AI 无法完成工作。
来源：The Verge, 2025

判断： 这类制度会扩散，因为它符合 CFO 逻辑：在收入不确定、工资刚性、AI 工具成本下降的环境里，企业天然会先问“能不能用软件、代理和现有人完成”，再问“要不要招人”。这会首先伤害毕业生和初级白领，因为他们过去承担的正是可被 senior 拆解、AI 生成、人工复核的任务。

1.4 AI 能力仍在快速推进，但真实工作存在瓶颈

Stanford 2025 AI Index 记录了前沿模型在 MMMU、GPQA、SWE-bench 等高难基准上的快速提升，并指出 AI 在视频生成、编程任务等方面取得明显进展。
来源：Stanford AI Index 2025

Epoch AI 的趋势数据表明，前沿模型训练算力自 2020 年以来高速增长，预训练计算效率也持续改善。
来源：Epoch AI Trends

METR 用“模型能独立完成多长的人类任务”衡量 AI 代理能力，认为这一时间跨度过去几年呈指数增长。
来源：METR Time Horizons

但真实工作不是 benchmark。企业部署会遇到数据权限、责任归属、客户信任、流程改造、遗留系统、监管、幻觉、质量验收、组织惯性等瓶颈。

判断： 能力增长足以压缩白领任务价格，但现实摩擦又会让“完全无人公司”来得慢于极端预测。未来几年更常见的不是 0 人，而是 1 个 senior + 多个 AI agent + 少量初级岗位。

2. 未来分阶段判断

2.1 2026-2028：白领入门层收缩，AI 成为默认办公基础设施

这一阶段最可能发生的变化：

1. 企业冻结或减少初级岗位。 招聘不会完全消失，但会更偏向“能直接交付的人”。毕业生从“培养对象”变成“需要立即证明产出的人”。
2. 绩效评价加入 AI 使用能力。 类似 Shopify 的做法会扩散到咨询、软件、金融、营销、电商、媒体、教育等行业。
3. 工作流从“人完成、AI 辅助”变成“AI 产出、人审核”。 这会压缩初稿、初筛、初审、初级分析、基础客服、简单代码的价格。
4. 招聘市场出现悖论：AI 岗位火热，但普通白领更难。 需求集中在 AI 产品、数据工程、自动化集成、行业解决方案、安全、评估、合规和销售工程等交叉岗位。
5. 大学生就业压力持续。 中国 2025 届高校毕业生预计 1222 万，2026 届预计 1270 万；即使没有 AI，白领岗位供给也已承压。AI 会让“岗位数量”和“岗位要求”之间的错配更尖锐。
   来源：教育部 2025 届数据、教育部 2026 届工作会议

这一阶段的关键词：不是失业总量爆炸，而是入门岗位变少、工资更卷、晋升链条断裂。

2.2 2028-2032：公司组织形态重构，中产职业护城河被重新定价

如果 AI agent 能稳定完成多小时到多天任务，企业会进一步重构：

1. 中层管理压缩。 过去靠“分派任务、汇总进度、写报告、协调会议”的中层会被系统和 AI dashboard 替代一部分。
2. 专业服务产品化。 法律、财税、咨询、设计、软件外包、教育辅导会出现大量“AI + 专家复核”的低价标准化产品。
3. 顶尖专家更值钱，普通专家被压价。 AI 让客户更容易获得“80 分答案”，于是只有能处理复杂、责任重大、非标准问题的人才有溢价。
4. 雇佣关系更碎片化。 企业更愿意买服务、买结果、买自动化系统，而不是长期养一批普通白领。
5. 职业教育从“学知识”转向“学工作流”。 会不会用 AI 不是会不会提问，而是能不能设计流程、验证结果、控制风险、交付给真实客户。

这一阶段的关键词：职业不消失，但普通专业能力商品化。

2.3 2032 以后：分配制度比技术本身更重要

若 AI 继续沿着“模型更强、部署更深、自动化更广”的轨迹前进，社会核心矛盾会从“AI 能不能做”转向“AI 创造的收益归谁”。

可能出现的格局：

1. 高 GDP、高利润、低就业弹性。 经济增长可以继续，但新增产出不再对应足够多的新增岗位。
2. 劳动收入占比下降，资本收入占比上升。 掌握模型、算力、数据、分发、资本的人获得更大份额。
3. 税制和社会保障重写。 IMF 已提出财政政策需要升级，讨论包括更强的社会保护、资本收入税、公司税、工资保险、教育培训等。
   来源：IMF Fiscal Policy and AI, 2024
4. UBI 会成为政治议题，但未必足够。 全民基本收入能缓冲消费和生存风险，却不自动解决身份、尊严、资产拥有权和社会参与问题。
5. 更重要的可能是 Universal Basic Capital。 即让普通人不只拿转移支付，也能分享 AI 生产资料的收益，例如公共 AI 基金、主权数据基金、公共算力红利、全民持有的技术资本池等。

这一阶段的关键词：技术问题转化为制度问题。

3. 对几个核心职业的判断

3.1 程序员

短期不会整体消失，但“只会按需求写普通代码”的程序员会被快速重定价。

高风险任务：

• CRUD、脚手架、测试样例、简单 bug 修复、迁移脚本、文档生成、接口对接、代码解释。

更安全的能力：

• 系统设计、复杂调试、性能与安全、需求澄清、架构取舍、业务建模、生产事故处理、AI 编排与评估。

判断：未来程序员更像“软件系统的导演和审稿人”。会写代码仍重要，但不再稀缺；能判断什么代码该写、如何上线、出事谁负责，才稀缺。

3.2 律师与法务

法律行业不会消失，因为责任、信任、出庭、谈判和策略判断仍需要人。但初级法律研究、合同初审、案例检索、尽调摘要会被自动化。

判断：法律服务会两极分化。低端标准合同和咨询价格下降，高端争议解决、复杂交易、监管策略和强关系型业务继续昂贵。

3.3 会计、审计、财务

风险很高。大量工作本质是规则、票据、分类、核对、报表和异常检测。AI 与 RPA、ERP、电子发票、银行流水、税务系统结合后，会持续压缩基础岗位。

判断：普通记账和基础审计会被压价；懂业务、税务筹划、资金管理、内控、数据系统和合规风险的人仍有价值。

3.4 咨询与分析师

初级咨询顾问的核心工作，如资料搜集、竞品分析、访谈整理、PPT、市场测算、benchmark，会被 AI 强烈冲击。

判断：咨询行业会从“人海战术 + PPT 工厂”转向“少数专家 + AI 研究流水线 + 数据产品”。客户会更不愿意为普通信息整理付高价。

3.5 医生与医疗

医疗受监管、责任和线下操作约束，不会像内容行业那样迅速自动化。但影像、问诊分流、文书、临床决策支持、药物研发会持续被 AI 改造。

判断：医生不会简单失业，但医生内部会分化。重复诊断和文书劳动减少，复杂病例、手术、医患沟通、责任承担更重要。

3.6 教师与教育

AI 会冲击“标准化讲解”和“题目批改”，但好的教育不只是信息传递，而是激励、反馈、陪伴、纪律、榜样、社群和人生路径设计。

判断：普通补课和知识讲解会被压价；高质量导师、项目制教育、升学就业路径规划、同伴社群和真实项目训练更值钱。

4. 中国语境下的特殊性

中国面对 AI 冲击时有四个特殊变量：

4.1 毕业生供给极大

2025 届高校毕业生预计 1222 万，2026 届预计 1270 万。即使 AI 不加速，白领就业市场也已经存在供需错配。AI 的作用是让企业更不愿意为“可培养但暂时低产出”的新人付费。

4.2 政策会强推 AI 产业化

国务院《关于深入实施“人工智能+”行动的意见》提出推动 AI 与经济社会各行业深度融合，重塑生产生活范式，覆盖科技、产业、消费、民生、治理、全球合作等方向。
来源：国务院“人工智能+”行动意见

这意味着中国不会选择“慢慢等”。政策方向更可能是加快 AI 进入产业，同时通过就业政策、教育改革、劳动法和社会保障吸收冲击。

4.3 劳动保护可能加强

2026 年中国已有法院案例显示，企业不能仅以“AI 可替代”为由违法解除劳动关系。
来源：The Guardian, 2026

判断：法律可以减缓直接裁员，但无法阻止“不新增岗位、不补岗、外包化、项目制、压低工资、提高招聘门槛”。真正的压力会更多体现在新增就业和薪资议价，而非显性裁员。

4.4 房产作为中产资产的逻辑变化

过去中国中产路径是：学历 -> 稳定白领工作 -> 按揭买房 -> 城市资产升值 -> 家庭财富积累。AI 冲击的是前两环，人口和房地产周期又冲击后两环。

判断：如果一个家庭的主要资产是单一城市房产，主要收入又来自高暴露白领岗位，那么它面对的是“双重集中风险”：收入集中在可被 AI 压价的职业，资产集中在流动性下降的存量资产。

5. “一人公司”会不会成为普通人的出路

一人公司会变多，但它不是自动胜利公式。

5.1 为什么一人公司更可行

AI 降低了以下成本：

• 产品原型：代码、设计、文案、调研、自动化。
• 运营：客服、邮件、内容排期、数据分析。
• 销售：名单整理、个性化触达、提案生成。
• 交付：报告、模板、课程、工具、轻量 SaaS。
• 管理：财务、合同、知识库、项目跟踪。

过去需要 5-10 人的小业务，未来可能由 1-2 人加多个 AI 工作流完成。

5.2 为什么一人公司也会更难

AI 降低生产门槛，也会制造供给洪水。所有人都能写文章、做课、做工具、写代码、做图、剪视频时，“能生产”本身不再稀缺。

稀缺性会转移到：

• 真实需求识别。
• 垂直行业经验。
• 客户信任。
• 分发渠道。
• 品牌人格。
• 独家数据。
• 线下资源。
• 复购场景。
• 责任承担。

5.3 更现实的路径不是“创业”，而是“个人经营化”

普通人不一定要辞职创业，但需要把自己从“岗位拥有者”改造成“现金流经营者”：

• 有一个可验证作品集。
• 有一套 AI 增强工作流。
• 有一个细分领域的长期观察。
• 有可联系的潜在客户或受众。
• 有能独立交付的小产品或服务。
• 有离开单一雇主后仍能生存的收入实验。

6. 教育会怎样变

6.1 学历不会消失，但“学历保险”会失效

学历仍然提供筛选、校友网络、基本训练和社会身份。但如果教育只提供标准化知识，它会被 AI 吞掉大部分边际价值。

未来教育的价值会从“知识传授”转为：

• 判断力训练。
• 真实项目经验。
• 同伴网络。
• 表达与协作。
• 行业进入机会。
• 伦理与责任。
• 复杂问题拆解。

6.2 大学会被迫回答一个问题

如果 AI 可以随时解释知识、生成练习、批改作业、模拟面试，大学凭什么收学费？

可能的答案只有几个：

• 给学生真实项目和真实客户。
• 给学生高质量同行和导师网络。
• 给学生行业准入和实习机会。
• 给学生研究、创造和判断训练。
• 给学生可信认证，但认证必须连接真实能力。

6.3 年轻人的新简历

未来简历的核心不再是“我学过什么”，而是：

• 我做成过什么。
• 我用 AI 把什么流程提效了。
• 我能独立交付什么结果。
• 我在哪个细分问题上有长期积累。
• 谁愿意为我的能力背书。

7. 资产与财富：为什么“生产资料”重新重要

7.1 AI 时代的新生产资料

过去普通人理解的生产资料可能是厂房、机器、商铺、房产。AI 时代的新生产资料包括：

• 算力。
• 模型访问权。
• 数据资产。
• 自动化工作流。
• 代码和工具。
• 分发渠道。
• 社群和信任。
• 行业 know-how。
• 品牌。
• 股权或基金中的技术资本敞口。

7.2 房产不是不能持有，而是不能当作唯一答案

房产仍可能有居住、抵押、抗通胀和城市资源绑定价值。但如果未来就业更不稳定、人口结构变化、城市分化加剧、租售比长期偏低，房产的财富弹性会弱于过去。

更稳妥的判断是：

1. 不要把“过去 20 年的房产叙事”机械外推到未来 20 年。
2. 不要让个人净资产和现金流都绑定在同一个城市、同一种职业、同一种资产上。
3. 提高流动性、技能资产、全球资产和技术资本敞口的重要性。

7.3 最重要的个人资产是“选择权”

AI 时代的不确定性太高，个人资产配置的第一原则不是押中唯一赛道，而是保留选择权：

• 低负债压力。
• 足够现金缓冲。
• 可迁移技能。
• 多元收入实验。
• 不被单一雇主、单一城市、单一平台锁死。

8. 社会政策：AI 税、UBI 和更深层的分配重构

8.1 AI 税的优点和问题

AI 税的直觉是：如果企业用 AI 替代人，就对自动化收益征税，用于补偿失业者。

优点：

• 回应分配不公。
• 为再培训和社会保障筹资。
• 减缓过度替代。

问题：

• 难以定义什么是“AI 替代”。
• 可能抑制生产率提升。
• 企业可通过外包、软件采购、跨境部署规避。
• 如果税基设计不好，会惩罚中小企业而放过平台巨头。

8.2 UBI 能缓冲，但不能单独解决问题

UBI 可以解决最低消费和安全感问题，但不能自动解决：

• 个人尊严。
• 社会参与。
• 技能退化。
• 财富资产所有权。
• 地区机会差异。
• 年轻人的上升通道。

8.3 更值得关注的是“资本普惠”

如果 AI 的收益主要来自资本和生产资料，那么只给现金补贴可能不够。更深层方案是让普通人分享 AI 资本收益：

• 公共 AI 基金。
• 数据红利。
• 公共算力券。
• 全民技术资本账户。
• 主权财富基金投资 AI 基础设施。
• 对垄断性模型和平台收益征收更合理的资本税。

判断：未来政治分歧会围绕一个问题展开：AI 是少数公司的私有生产资料，还是社会共同参与建设后应被更广泛分享的基础设施？

9. 三种未来情景

情景 A：温和重组

特征：

• AI 提升效率，但受监管、组织惯性和质量风险约束。
• 大量岗位被改造而非消失。
• 初级白领减少，但新岗位逐步吸收。
• 政府通过教育、补贴、社保缓冲冲击。

概率：中等。
个人策略：持续升级 AI 工作流，保留职业身份，同时发展副业和作品集。

情景 B：白领压缩

特征：

• 企业大规模采用 AI agent。
• 初级和中层岗位明显减少。
• 高端专家和资本所有者收益上升。
• 大学生就业难、薪资停滞、中产焦虑加剧。
• 政策反应滞后，社会分配矛盾上升。

概率：中高。
个人策略：尽早从“岗位竞争”转向“结果竞争”，建立垂直领域现金流和流动性资产。

情景 C：高增长低就业

特征：

• AI 带来明显 GDP 增长和企业利润增长。
• 就业吸纳能力显著下降。
• 传统工资税和社保体系承压。
• UBI、AI 税、公共资本账户成为主流政治议题。
• 社会身份从“职业”转向“资产、社群、创造、公共保障”的组合。

概率：不确定，但需要提前准备。
个人策略：减少对单一工资收入的依赖，尽量拥有技术资本、分发渠道、专业信用或可交易资产。

10. 未来 24 个月最值得观察的信号

如果下面这些信号持续出现，说明“白领压缩”正在加速：

1. 大公司明确要求新增岗位先经过 AI 替代评估。
2. 校招岗位减少，社招岗位要求“AI native”。
3. 咨询、法务、财务、软件外包、设计、营销等行业出现明显价格下行。
4. 初级岗位工资停滞，但 senior 和 AI 集成岗位工资上升。
5. 企业利润增长与员工数量增长脱钩。
6. AI agent 从 demo 进入 ERP、CRM、办公套件、代码仓库、客服系统、财务系统。
7. 高校开始大规模调整专业，把 AI 工作流和项目制实践纳入核心培养。
8. 劳动争议中出现更多“AI 替代”案例。
9. 政府开始严肃讨论 AI 税、数据红利、公共算力、UBI 或工资保险。
10. 房产、学历、稳定编制之外的“个人经营能力”成为年轻人主流讨论。

11. 普通人的行动框架

11.1 做一次“任务暴露审计”

不要问“我的职业会不会被替代”，而要问：

• 我每周做的任务里，哪些 AI 已经能做 70 分？
• 哪些任务只需要人审核？
• 哪些任务涉及责任、信任、线下关系、复杂判断？
• 如果公司要降本，会先砍掉我工作的哪一部分？
• 我能不能主动把这些任务自动化，变成自己的效率优势？

11.2 建立一个个人 AI 工作栈

至少包括：

• 信息检索与研究。
• 写作与表达。
• 数据分析。
• 自动化脚本。
• 个人知识库。
• 行业监控。
• 项目管理。
• 作品集发布。

目标不是“会用工具”，而是能把一个真实问题从需求、调研、产出、验证、交付跑完。

11.3 选择一个足够窄的垂直领域

AI 让泛泛而谈贬值，垂直理解升值。一个好的方向通常满足：

• 有真实付费痛点。
• 你能接触到客户。
• 数据和经验不完全公开。
• 可以用 AI 提效。
• 可以做成模板、工具、报告、服务或课程。

11.4 做小型现金流实验

不要等到失业才创业。可以从极小实验开始：

• 给一个细分人群做自动化模板。
• 帮小企业改造一个流程。
• 做一个行业监控 newsletter。
• 做一个低价咨询产品。
• 做一个垂直知识库。
• 做一个内部工具外部化。

目标是验证“有人愿意为我独立交付的结果付钱”。

11.5 资产上避免单点脆弱

原则：

• 不让高负债房产和高暴露职业同时压在自己身上。
• 保留 6-12 个月现金缓冲。
• 投资自己的可迁移能力。
• 谨慎追逐 AI 泡沫资产，但不要完全没有技术资本敞口。
• 尽量拥有可跨城市、跨平台、跨雇主迁移的收入能力。

12. 反共识提醒

为了避免被单一叙事带偏，需要同时记住几个反共识点：

1. AI 很强，不代表组织会立刻变强。 大量企业会买工具、开培训、写口号，但流程不变，收益有限。
2. AI 替代任务，不等于立刻替代责任。 法律、医疗、金融、公共服务等领域的责任归属会减慢替代。
3. 人类需求不会消失。 陪伴、信任、审美、线下体验、身份认同、社群归属仍是人类市场。
4. 越自动化，越需要高质量判断。 当生产泛滥，筛选、策展、验证、承担责任的人更值钱。
5. 不是所有人都适合创业。 但所有人都需要一点经营意识。
6. 最危险的是既不相信变化，也没有任何实验。 判断错可以调整，没有实验就没有反馈。

13. 最终判断

AI 时代最可能出现的不是“所有人都没工作”，而是更复杂、更不平等的结构：

• 少数掌握 AI 生产资料的人获得巨大收益。
• 一部分专家变成超级个体或小团队。
• 大量普通白领岗位被压价、合并或外包。
• 年轻人的第一份工作更难获得。
• 学历从保险变成弱信号。
• 房产不再天然承接中产上升叙事。
• 政府被迫重构税收、社保和教育。
• 普通人必须从“被雇佣的标准件”转向“能借助 AI 独立创造现金流的经营单元”。

最重要的准备不是恐慌，而是把自己从旧系统的单点依赖中拆出来：

少一点对单一学历、单一岗位、单一雇主、单一城市、单一房产的依赖；多一点对 AI 工作流、真实客户、作品集、现金流、流动性和长期学习能力的掌控。

主要参考来源

• IMF: Gen-AI: Artificial Intelligence and the Future of Work
• IMF: Fiscal Policy Can Help Broaden the Gains of AI to Humanity
• OECD: Employment Outlook 2023
• OECD: Miracle or Myth? Assessing the macroeconomic productivity gains from AI
• ILO: Generative AI and Jobs: A Refined Global Index of Occupational Exposure
• World Economic Forum: The Future of Jobs Report 2025
• World Economic Forum: Future of Jobs Report 2025 press release
• Goldman Sachs: Generative AI could raise global GDP by 7%
• Goldman Sachs: How Will AI Affect the US Labor Market?
• NBER: Generative AI at Work
• NBER: The Simple Macroeconomics of AI
• Anthropic: Anthropic Economic Index
• Anthropic: Labor market impacts of AI
• Shopify: Serious results, unserious methods: Shopify’s AI playground
• Tobi Lutke: Reflexive AI usage is now a baseline expectation at Shopify
• The Verge: Shopify CEO says no new hires without proof AI can’t do the job
• Stanford HAI: 2025 AI Index Report
• Epoch AI: Trends in Artificial Intelligence
• METR: Task-Completion Time Horizons of Frontier AI Models
• 教育部：2025 届高校毕业生预计达 1222 万人
• 教育部：2026 届全国普通高校毕业生就业创业工作会召开
• 国务院：关于深入实施“人工智能+”行动的意见
• 国家统计局：2026 年 5 月国民经济运行情况
• The Guardian: Chinese court awards compensation to sacked worker replaced by AI

很多人把这类现象叫 context rot，上下文腐烂。这个词很好记，但它把两种机制很不一样的问题塞进了一个桶里：一种是上下文太长，模型开始走神；另一种是上下文不一定长，但里面已经混进了错误前提。

我会先把它们拆开。下面的 distraction 是本文为了方便诊断使用的操作性标签，不等同于 Chroma 报告里的 distractor 术语。

• distraction：长度问题。context 太长，信号被稀释。
• poisoning：真相问题。context 里有毒，错误假设被反复引用。

它们不是互斥分类器，更像两个优先级不同的排查方向。太长时，先压缩和摘要；太脏时，先清理和隔离。

太长：模型不是到上限才开始变笨

Chroma 的 Context Rot 报告 做过一组直观测试：给模型一段长文档，让它从里面找某句话，然后不断加长输入，看表现怎么变。它们测了 18 个主流模型，结论不太舒服：输入越长，模型越容易退化，而且退化通常发生在理论窗口上限之前。

这个问题很好理解。你把越来越多的信息塞进同一个 context，真正有用的信号会被淹没。模型仍然“看得到”那些 token，但注意力预算不是无限的。Anthropic 在 context management 里也用了类似思路：长任务需要 context editing、memory、progressive disclosure 这类机制，把注意力留给当前真正相关的信息。

这类问题的症状是：context 明显变长，模型开始漏掉约束，回答变得泛，工具调用和文件读取开始重复，但没有明显执着于某个错误方向。

这时候 /compact、summary、context folding、把局部任务交给新的 sub-agent，都可能有用。Anthropic 在同一篇文章里给过一组数据：context editing 加 memory 在一个 100 轮 web search evaluation 里把 token 消耗降了 84%，在 agentic search eval 上比 baseline 提升 39%。这只能说明，在 Anthropic 的长轮次搜索评测里，context editing 和 memory 有明显收益；放到 coding agent 修 bug 场景，还需要单独验证。

问题是，我们平时说“agent 越改越烂”，很多时候 context 并没有长到这种程度。一个修 bug 会话，可能才一两万 token。离长上下文严重稀释还远，但 agent 已经开始在同一个错误方向里打转。

太脏：错误前提进了 context

另一种病更像 context poisoning。

Google DeepMind 在 Gemini 2.5 技术报告 的 Gemini Plays Pokémon 讨论中使用了 context poisoning 这个说法。报告 Appendix 8.2 的 Additional Challenges 里提到，目标、summary 等 context 片段可能被游戏状态的错误信息污染，模型会执着于不可能或无关的目标，而且这种污染可能需要很长时间才能解开。

放到 coding agent 里，它大概长这样：

1. agent 第一次给了一个错误修复方案；
2. 这个方案、推理过程、工具输出都进入了 context；
3. 你说“不对，再改”；
4. agent 未必理解成“整个方向错了”，它更可能理解成“细节不对，沿着这个方向继续修”；
5. 每改一轮，最初那个错误假设就被再引用一次。

一个最小化例子：agent 先判断 bug 来自缓存，于是改缓存逻辑；测试失败后，用户只说“不对”。下一轮它没有重新验证根因，继续解释“缓存修复还需要补兼容层”。再下一轮，新报错也被吸收到缓存假设里。到这一步，它并没有忘掉信息；它把错误假设当成了必须维护的上下文。

这就是两种病的区别：

poisoning 不是“模型能力差”的同义词。模型可能很强，但只要它把错误前提当成约束，后面的推理就会越走越窄。

/compact 治的是长度，不一定治污染

很多人遇到 agent 变乱，第一反应是 /compact。

这在 distraction 场景里合理。context 太长，那就压缩，把当前任务需要的信息留下来。Claude Code、Cursor、很多 agent 框架都在做类似事情。

但 poisoning 麻烦在这里：错误前提看起来也很“重要”。

如果摘要器只是判断“哪些信息对后续有用”，那个最初的缓存假设很可能会被保留下来。它贯穿了整段对话，出现频率高，又和后续 diff、报错、解释都有关。旧会话摘要里一旦写出“当前排查集中在缓存层”，这个未验证根因就被换了个更正式的格式带进下一轮。

Claude Code 文档里有一个失败模式叫 Autocompact is thrashing：自动压缩刚成功，某个文件读取或工具输出又把 context window 填满，系统会停止重试以避免浪费调用。官方说的是 context refill 和循环问题，不是在直接定义 poisoning。但它提醒我们一件事：自动压缩并不理解所有语义风险。它能缩短 context，不等于能识别哪些内容应该被丢弃。

论文层面也有旁证。Contextual Drag 研究了错误 context 对 LLM 推理的拖拽效应，论文摘要里提到，错误尝试进入 context 后会诱发结构相似的后续错误，在严重情况下 iterative self-refinement 会退化成 self-deterioration。Latent Phase-Shift Rollback 更激进：它不让模型用 prompt 自我纠错，而是在内部 KV-cache 层面回滚；论文摘要称，在它的实验设置里，这种方法比 prompted self-correction 高 24.2 个百分点。

这两篇论文不能直接推出“所有 coding agent 都应该清空重开”。它们只能作为机制旁证：错误已经写进上下文后，让模型靠同一个上下文把自己救出来，可靠性并不高。

先问：太长了，还是太脏了

我现在会先问一个问题：

这个 context 是太长了，还是太脏了？

这不是严格分类器，只是一个使用 agent 时的启发式判断。

如果是太长，症状通常是“漏”。它忘了你前面说过的约束，找不到关键文件，回答开始变泛。这个时候可以压缩、摘要、拆子任务、让 agent 重新读取最相关文件。

如果是太脏，症状通常是“执着”。它记住了太多错误路径，并且一直试图解释那些错误路径为什么还能成立。你会看到它反复围绕同一个错误假设修补，哪怕测试和报错已经暗示方向不对。

清空重开不是把所有东西都丢掉。比较好的做法是只带三类材料进新会话：当前真实现象、明确约束、已验证事实。最危险的是把旧会话完整总结成“背景”，那很可能只是把毒换了个格式带过去。

Sub-agent 的价值可能在隔离失败路径

很多人谈 multi-agent，会先谈并行、速度、覆盖面。这些当然重要。Anthropic 在 一篇工程文章 里说，它们的 multi-agent research system 在内部 research eval 中比单 agent Claude Opus 4 高 90.2%。同一篇文章也说得很克制：multi-agent 很吃 token，任务必须真的可并行；coding 任务往往不像 research 那样天然适合拆很多独立方向。

我更关心另一个角度：sub-agent 可以隔离污染。

你让一个 sub-agent 去查“是否缓存导致”，它可以读文件、跑命令、犯错、绕路。最后主线只接收一个短结论：缓存不是根因，证据是某个测试和某个日志。探索过程不必完整带回主线。

这和“新开对话一次改好”的体验很像。新会话并没有让模型突然变聪明，它只是没有继承旧会话里的错误假设。

当然，sub-agent 不是银弹。Cognition 有篇文章标题就很直接：Don’t Build Multi-Agents。它反对的重点之一，是多 agent 系统会制造协调和 context passing 的新问题。这个提醒很有价值：如果你把主线里的错误假设原样塞给 sub-agent，它照样会被污染。

所以 sub-agent 的用法不是“多开几个 agent 就会更聪明”。更稳的用法是：给它一个窄问题，不给它旧会话里的失败推理，让它返回证据和结论，主线只吸收验证过的信息。

我会怎么改自己的 agent 使用习惯

遇到 agent 越修越乱，我以前会继续催：“不对，再看看。”“还是不行，换个办法。”现在我会更早停下来。

如果只是 context 太长，我让它压缩当前事实，重新列任务边界。如果已经出现错误前提反复自我维护，我直接开新会话。如果不确定根因，我开一个干净 sub-agent 做独立排查，不把旧会话里的猜测带过去。

新会话的 prompt 不要写“刚才你试过 A、B、C 都失败了，所以现在继续”。这句话很容易把 A、B、C 的错误地基带过去。

更好的写法是：

1
2
3
4

现象：运行 pnpm test auth 时，AuthProvider refresh token 用例失败。
约束：保持 public API 不变；先不要改 test。
已验证事实：请求已发出，服务端返回 401；本地 storage 中 refresh token 存在。
任务：重新定位根因。先列出 3 个可能原因和验证命令，再动代码。

如果要把旧会话压缩后继续，也可以明确要求：

1
2

请只保留已验证事实、当前失败命令、不可改变的约束。
不要保留任何未验证的根因猜测、失败修复方案、或基于失败方案的后续解释。

这比单纯 /compact 更接近“排毒”。

我最后真正想带走的规则只有一条：下一轮 prompt 只带现象、约束、已验证事实；不带未验证根因、失败 diff、基于失败 diff 的解释。

context rot 这个词的问题，是它听起来像一种病。我现在更愿意把它拆成两个诊断问题：太长，还是太脏。

太长的时候，压缩和摘要是正经药。太脏的时候，继续勾兑通常只会让错误前提更难清理。重开一个干净上下文，只带事实和约束，不带失败路径，反而是当前 agent 架构下更稳的工程选择。

如果只是把一个大 prompt 存起来，那我直接写在 AGENTS.md 或 docs/plan.md 里不就完了。它和 Claude Code 的 /loop、Ralph Loop 到底有什么区别？什么任务配得上开 Goal，什么任务只是我懒得拆？

我查了一圈文档，也在本机确认了一下：codex --version 输出 codex-cli 0.133.0，codex features list 里 goals 是 stable。OpenAI 在 2026-05-21 的 Codex changelog 里写到，Goal mode 不再是 experimental，Codex app、IDE extension 和 CLI 都能用。官方的描述很克制：Goal 是 thread 上的 persistent objective，用来让 Codex 朝一个具体目标持续推进，可以暂停、恢复、清除。

这句话比“让 Codex 一直工作”准确得多。Goal 的关键在于让目标持续可见，执行时间只是结果之一。

Goal 解决的是哪种尴尬

平时用 Codex，最容易出问题的地方通常不在单条命令，而在长任务做到一半后目标漂移。

你让它“把登录模块迁到新 API”，它会读代码、改文件、跑测试、修错误。这个过程可能跨很多 turn。每一轮你都能纠偏，但也会遇到三个问题：

• 你前面说过的边界，后面不一定还足够显眼。
• Codex 做完一个局部步骤后，可能把“局部通过”当成“整体完成”。
• 你中途插入一句“顺便看下这个报错”，主线任务的完成条件会变得更松。

Goal 做的事，是把“这次到底做到什么才算完”从聊天内容里拎出来，变成一个线程级状态。你仍然可以继续发消息打断、补充、纠偏，但当前 Goal 会比散落在历史消息里的约束更显眼。

我会把 Goal 当成 agent 的验收条件，少写鼓励语。

什么算一个好 Goal

OpenAI 的 Follow Goals 文档给了一个很实用的判断：Goal 适合 long-running work，尤其是 code migration、大重构、deployment retry loops、实验、游戏、side project 这种需要跨 turn 的任务；不适合一串无关小事。

对工程实践来说，最值得关注的是迁移、重构、部署重试和带验证闭环的前端实现。

如果任务一轮就能完成，别开 Goal。如果任务没有结束标准，也别开 Goal。

“把前端优化一下”算不上好 Goal。Codex 可以优化到天荒地老，也可以随手改三处 CSS 就说完成。

“根据 docs/redesign-plan.md 改首页，只改 src/pages/home 和 src/components/home，每完成一个 section 跑一次 pnpm build，最终用 Playwright 截 1440px 和 390px 两张图，确认没有布局重叠后停止”更像一个 Goal。

它有四个东西：

• 要达成什么：改首页。
• 不要碰什么：只改两个目录。
• 怎么证明进展：按 section 做，跑构建和截图。
• 何时停：桌面和移动截图通过检查。

这四个东西能减少 Codex 把局部完成当整体完成的机会。Goal 不会让 Codex 突然更听话；它只是让你更难逃避验收标准。

我会怎么写 /goal

Codex CLI 文档里 /goal 的基本形态很简单：

1
2
3
4
5

/goal <objective>
/goal
/goal pause
/goal resume
/goal clear

目标最多 4000 个字符。长计划不要硬塞进去，放到文件里，让 Goal 指向文件。Codex app 的 commands 文档 也写到，Goal active 时会在 composer 上方显示进度，你可以暂停、恢复、编辑或清除。

我更推荐先用 /plan 把任务收敛，再把确认过的目标设成 Goal：

1

/plan 先阅读 docs/payment-migration.md，并给出迁移计划，不要先修改文件。

等 Codex 给出计划，我确认范围和顺序，再设 Goal：

1

/goal 按 docs/payment-migration.md 的里程碑逐步实施。保持公共行为不变。仅修改 src/payments、tests/payments、docs/payment-migration-notes.md。每个里程碑完成后运行 pnpm test payments。当 pnpm test payments 返回 0 且 docs/payment-migration-notes.md 记录了已迁移调用点时停止。若需要产品决策，请 pause 并说明阻塞点。

这段不漂亮，但它有用。

我不想让 Codex 猜“什么时候算 done”。我也不想让它把“测试还没跑，但看起来差不多”包装成完成。Goal 里应该出现具体命令、具体文件、具体边界。没有这些东西，Goal 只是一个更持久的愿望。

它和 Ralph Loop 像不像

像，但相似点很浅。

Ralph Loop 是 Anthropic verified 的 Claude Code 插件。它的公开实现很直白：根据 README，Ralph 用 Stop hook 拦截 Claude 试图结束 session 的动作，然后把同一个 prompt 再喂回去，让 Claude 继续干。你可以设置 --max-iterations，也可以设置 --completion-promise，比如“当你输出某句承诺时才算完成”。

这是一种循环机制。它的核心问题是：下一轮什么时候开始？ Claude 要结束时，hook 把它拉回来。

Codex Goal 的公开语义不一样。OpenAI 文档没有把它描述成 hook，也没有说它会重放同一个 prompt。它更像是线程上的目标状态：Codex app 会在输入框上方显示进度，你可以 pause、resume、edit、clear；CLI 里也可以用 /goal 查看当前目标。它的核心问题是：当前线程到底朝哪个完成条件推进？

所以不能简单说 Codex Goal 就是内置 Ralph Loop。它们都在处理“多轮 agent 工作”，但抽象层级不同。

这里还有一个容易忽略的事实：Claude Code 现在也有官方 /goal。Anthropic 的 goal 文档 写得比 OpenAI 更暴露机制：Claude 每个 turn 后会用一个 small fast model 检查 completion condition 是否满足；文档还说 /goal 是一个 session-scoped prompt-based Stop hook wrapper。Claude 的 /loop 文档 则把它定位成 session 内按间隔重复运行 prompt 或 slash command 的能力，更适合轮询状态或提醒。

下面只按公开文档里的用户可见行为对比，不推断底层实现：

所以 /loop 和 /ralph-loop 没有新版旧版关系，也没有内置版和插件版的关系。/loop 是 Claude Code 的计划任务能力，核心是“隔一段时间再跑一次”；/ralph-loop 是插件命令，核心是“Claude 想停时，用 Stop hook 把同一个 prompt 再塞回去”。前者适合等外部状态变化，比如 CI、部署、PR 评论；后者适合让 Claude 在同一个任务上反复试错，比如写代码、跑测试、修失败、再跑测试。

这些细节不能倒推到 Codex，但它说明同一类产品都在补一个洞：只靠普通对话，很难稳定表达“继续做，直到这个条件成立”。

Goal 的效果取决于验证闭环

我不太相信“开了 Goal，复杂任务就自动变稳”这种说法。长期 agent 任务真正怕的是缺少可验证反馈，任务长反而只是表象。

适合 Goal 的任务通常有这些信号：

• 测试能跑：pnpm test payments、pytest tests/auth、go test ./...。
• diff 能审：只允许修改某些目录，最终 git diff --stat 看得出来。
• 产物能看：截图、构建产物、迁移清单、benchmark 日志。
• 阻塞能定义：遇到产品决策、权限、外部服务失败时停下来报告。

长任务还要写失败预算，不然 agent 会把时间花在低质量重试上。比如“最多尝试三种修复路径；如果都失败，停下来给证据”，通常比“直到修好”更像工程约束。

不适合 Goal 的任务也很常见：

• “帮我把代码写优雅一点。”
• “研究一下这个方向有没有价值。”
• “把所有历史技术债处理掉。”
• “做一个看起来高级的页面。”

这些任务可以交给 Codex，但要先拆。比如“研究方向”可以拆成“阅读这 5 个链接，输出一页反方观点和三条可验证假设”。“页面高级”可以拆成“参考 reference.png，保持文案不变，改布局和视觉层级，截图对比 1440px/390px，不允许文字重叠”。

Goal 不会替你定义质量。它只会放大你已经定义好的质量标准。

我会用它替代什么

我不会用 Goal 替代 AGENTS.md。项目约定、目录结构、编码规范，仍然应该写在 AGENTS.md，因为它们是所有任务共享的背景。

我也不会用 Goal 替代计划文件。复杂迁移仍然应该有 docs/plan.md，里面写 milestone、风险、检查项。Goal 只负责把“按这个计划做到什么程度”挂到当前线程上。

我会用 Goal 替代三类脆弱操作。

第一类是“每隔几轮提醒 Codex 不要忘了主线”。Goal 本身就该保存主线。

第二类是“把大任务塞进一个超长 prompt”。长 prompt 读起来像规格书，但执行过程中很容易变成背景噪音。更稳的做法是规格写文件，Goal 写验收条件。

第三类是“手工催下一步”。在需要继续推进时，当前 Goal 能让“继续”指向同一套验收条件，比每轮都问“继续”更清楚。

三个可以直接改的模板

迁移任务：

1

/goal 按 docs/auth-migration.md 的里程碑逐步实施。保留现有公共行为。仅修改 src/auth、tests/auth 和 docs/auth-migration-notes.md。每个里程碑后运行 pnpm test auth。当测试通过且 notes 文件列出已迁移入口时停止。若 API 行为存在歧义则 pause。

修 CI：

1

/goal 修复 logs/ci-failure.txt 中对应的 CI 失败。先在本地复现失败。做最小的代码或测试改动来修复。再次运行同一失败命令。命令返回 0 时停止，或在三种不同失败方案都失败并有证据后 pause。

前端验收：

1

/goal 实施 docs/home-redesign-plan.md。保持文案不变。每个检查点后用 Playwright 在 1440px 和 390px 分别截图。两张截图中都不再出现明显重叠、布局偏移或按钮文字裁剪时停止。

这些模板靠的是边界清楚，不靠堆长度：它们把 Codex 的自由度锁在任务需要的范围内。

真正的问题变成了“你怎么定义完成”

Goal 这个功能让我有点不舒服。它逼我把原本可以边做边想的验收标准提前写出来。

以前我可以丢一句“帮我重构一下”，然后边看边改。结果好坏，很多时候取决于我中途盯得够不够紧。Goal 逼我提前回答几个工程问题：哪些文件能动？哪些行为不能变？用什么命令验收？失败几次后该停下，避免继续消耗时间？

这个问题不只出现在 Codex。Claude Code 的 /goal、/loop、Ralph Loop 都在围绕同一个缝隙打补丁：agent 已经能连续工作了，但“连续工作”本身没有价值，除非它知道何时停。

所以我的结论很简单：不要把 Goal 当自动驾驶。它最有价值的用法，是把目标写成一张验收单。

当你能写出清楚的验收单，Goal 会让 Codex 更适合做跨 turn 的长期任务。当你写不出来，它只是把一个模糊 prompt 保存得更久。

这次最大的体感是：让 AI 写出好看的网页，关键不在 prompt 里塞多少个 premium、modern、sleek。那些词当然有用，但它们太软了。真正有用的是把“好看”拆成一组 AI 能讨论、能执行、能反复检查的约束。

左边是旧版，右边是现在的移动端首页。旧版也不是不能用：有继续阅读，有搜索，有最新上架和分类列表。但它更像一套功能模块的顺序堆叠，视觉语言还停留在“把能力摆出来”。新版把阅读场景往前推了一步：继续阅读卡片变成首屏锚点，搜索和随机一本的操作距离更短，最新上架和分类都变成横向书架，底部导航让“首页 / 书库 / 设置”这些高频位置稳定下来。纸张质感只是表层，真正变化的是信息优先级和操作路径。

这件事不是一次 prompt 搞定的。我主要用了三个 skill：brainstorming、frontend-design、ui-ux-pro-max。

先别急着写 CSS

很多人让 AI 改 UI 的方式是这样的：

帮我把这个页面做得更高级一点，要有设计感，移动端也优化一下。

AI 很可能真的会开始改：加渐变、加阴影、加毛玻璃、调大圆角、塞一点动画。你会得到一个“更像 AI 写的页面”的页面。

问题不在模型不会写 CSS，而是这个请求没有设计判断。什么叫高级？这个产品是工具、杂志、仪表盘，还是阅读应用？用户打开首页是为了搜索一本书，继续上次阅读，还是随便逛逛？移动端底部该放导航，还是该把搜索固定住？

这些问题不回答，AI 只能调用它训练里最常见的视觉套路。

brainstorming 的作用就是先把这些问题逼出来。superpowers 里的 brainstorming 不是让 agent 马上开工，而是要求它先看项目、问问题、给出 2-3 个方案、讲 trade-off，再形成设计。这个步骤听起来慢，但它解决的是最容易被跳过的部分：你到底想要什么。

我在这轮迭代里会先让它讨论原型和交互，而不是直接动代码。比如移动端首页到底应该强调“书库索引”，还是强调“最近可读的新内容”；阅读页的返回路径应该回到哪里；底部导航放什么才不会变成摆设。

这也是 skill 和普通 prompt 的差别。普通 prompt 往往只是一句愿望：“做得高级一点”。skill 更像一份可复用的工作说明：先问哪些问题，必须给几个方案，什么情况下不能开工，交付物是什么。它把一次性的灵感请求，变成了每次都能复用的角色边界和检查步骤。

这个过程有点像和一个产品设计师反复争论。它不一定每次都对，但它会把隐含假设摊开：信息层级、使用路径、屏幕空间、默认状态、空状态、返回路径。只要这些东西被说清楚，后面的代码修改就不再是“凭感觉美化”。

frontend-design 负责审美，不负责玄学

我用的第二个 skill 是 frontend-design。它的价值不是提供某个固定模板，而是把视觉质量拆成几个可执行维度：

• 字体是不是有性格，而不是默认系统字体一路糊到底
• 配色是不是有主次，而不是一整页同一个色相的浅浅深深
• 空间是不是有节奏，而不是每个卡片都等距铺开
• 动效是不是服务状态变化，而不是哪里都晃一下
• 页面有没有一个明确气质，而不是“通用 SaaS 风”

这和“让页面高级一点”完全不是一回事。后者是形容词，前者是检查表。

晨笙阅读这个站点本质上是一个阅读和知识索引工具，所以我不希望它像企业后台，也不希望它像营销落地页。新版的方向更接近“安静的书房”：米白底、纸张颗粒、偏暖的品牌色、书卡横滑、分类索引。这个气质也反过来影响信息架构：首页不做巨大 hero，不写一屏自我介绍，而是把继续阅读、搜索、随机一本和可浏览书架提前。它不是最酷炫的方案，但更贴合“打开来找书、继续读、随便翻”的场景。

这里有一个很重要的经验：不要让 AI 自由发挥审美，要让它沿着一个明确方向发挥。

如果你只说“高级”，它可能给你紫色渐变、玻璃卡片、巨大的 hero、发光按钮。如果你说“这是一个移动端阅读索引，我希望它像安静的书房，信息密度适中，重点是让人愿意继续读”，它就有了更具体的判断空间。

ui-ux-pro-max 负责把页面磨到能用

好看的截图不等于好用的页面。

我把 ui-ux-pro-max 放在更靠后的环节用。它更像一个挑剔的产品设计师，盯的不是配色，而是路径、状态、可访问性和移动端交互：

• 移动端底部导航点进去之后，返回会不会乱
• 首页有没有明确的下一步
• 搜索和随机一本这种高频动作够不够近
• 书卡在小屏幕上会不会挤
• 侧边栏在移动端是不是应该消失
• 当前页面状态有没有被导航正确表达
• 触摸目标、间距、字体大小、可访问性和响应式有没有踩基础红线

这类问题很容易被工程师忽略，因为功能已经能跑了。但页面的质感经常就坏在这些小地方：按钮看得到但不好点，返回路径违背直觉，桌面端顺手但移动端像缩小版网页。

ui-ux-pro-max 的价值在这里很明显。它不是只给“好看一点”的建议，而是会盯住一些基础红线：触摸目标够不够大，导航项是不是过载，返回行为是不是可预测，页面会不会在移动端横向滚动，核心内容有没有优先出现。这些规则听起来朴素，但移动端体验经常就是在这些地方翻车。

晨笙阅读后续的几次提交其实都在磨这些问题。比如移动端底部导航不是为了“看起来像 app”才加的，而是因为首页、书库、设置这几个位置会被反复访问，藏在侧边栏里会让路径变长。再比如 book header mode，是为了让阅读页在小屏幕上保留书名、返回和目录这些必要动作，同时避免桌面端那套 header 直接压到内容上。它们单独看都不是“大 redesign”，但加在一起会改变产品的手感。

这也是我现在更喜欢的 AI 前端工作流：

1. 用 brainstorming 把目标和方案说清楚，产物是方案取舍。
2. 用 frontend-design 定视觉方向和审美约束，产物是可执行的设计语言。
3. 用 ui-ux-pro-max 检查交互路径、状态和移动端体验，产物是体验问题清单。
4. 用截图做前后对比，产物是肉眼可验收的证据。

这套方法的核心不是“某个神奇 skill”。核心是让 agent 在不同阶段扮演不同角色。一个角色负责问问题，一个角色负责视觉，一个角色负责体验。不要指望一个“帮我优化 UI”的请求同时完成产品、视觉、交互、实现和验收。

业界还有另一条路线：先设计，再写代码

我的路径偏工程师：在代码库里迭代，用 skill 让 coding agent 补上设计讨论和审美约束。

另一条越来越明显的路线，是先在 AI 设计平台里把高保真原型做出来，再把设计系统和组件约束带回代码。这些工具不完全同类：Figma/Make 更偏设计工作流和原型，Stitch 更偏 UI 生成画布，Lovable 更偏应用生成，Webflow 更偏站点构建与设计系统落地。它们的共同点，是把设计判断前置到画布、组件和 tokens 里，而不是等 coding agent 写完页面再补救。

Figma 在 Config 2025 发布了 Figma Make 和 Figma Sites，把 prompt-to-code、网站发布和设计工作流放到同一个平台里。Google Labs 的 Stitch 也把自己定位成 AI-native software design canvas，可以从自然语言、业务目标、用户感受和参考灵感开始生成 UI。Lovable 文档里关于规划、组件拆分和真实内容的建议，指向的是同一个原则：输入越具体，结果越可控。

这条路线的优势是明显的：设计平台天然有画布、组件、tokens、团队协作和视觉评审。Figma Make 支持导入现有 Figma library 来保持颜色、排版和核心样式一致；Webflow 的 AI Site Builder 也会生成 style guide，并围绕 design tokens、utility classes、component patterns 组织页面。

但它也不是银弹。设计到代码仍然不是无损闭环。Figma Make 的 functional version 不能直接进入 Figma Design，Design 里的图层改动也不会自动回写 Make。更现实的问题是：如果你的设计系统本身平庸，AI 只会稳定地产出统一但平庸的页面。

Figma 的 2025 AI Report 里有一个很有意思的数字：78% 的受访者认同 AI 提升效率，但只有 32% 认为可以依赖 AI 输出。这个比例挺诚实。它支持的是“AI 加速产出”，不是“AI 替代质量判断”。

我现在会怎么做

如果下次我从零做一个页面，我大概率会这样开始：

先写清楚这个页面的使用场景，而不是先写 UI prompt。谁打开它？打开时想完成什么？首屏最应该让他看到什么？哪些信息只是辅助？

接着让 agent 给 2-3 个方向，不要只给一个。一个偏工具，一个偏内容，一个偏品牌。方案之间必须有取舍，否则就不是方案，只是换皮。

然后才进入视觉约束：字体、色彩、空间、动效、组件密度、移动端优先级。这里要尽量具体，不要只写“高级”。你可以说“像一个安静的阅读工具，不要营销页，不要大 hero，不要紫色渐变，不要玻璃拟态，首屏要露出可读内容”。

实现之后一定截图。最好是移动端截图。桌面端空间太宽，很多问题会被藏起来；移动端会逼你面对真实的信息优先级。按钮挤不挤，卡片有没有意义，导航是不是顺手，一眼就露出来。

收尾时再让另一个角色审一遍交互。不要让同一个 agent 刚写完就宣布自己做得很好。换一个审校角色，只看截图和交互路径，不看实现过程。它太容易爱上自己的实现。

我现在对 AI 写前端的判断是：它已经很会写代码了，但它还不天然拥有你的品味。你要做的不是把品味压缩成几个形容词，而是把品味拆成可以讨论、可以约束、可以验收的工作流。

页面的品味和取舍，终究还是人来负责。AI 能做的是把这些判断拆开、落地，并不断帮你验收。

第一组：基础操作，先跑起来

启动交互会话

直接敲 codex 进入全屏 TUI，或者带上初始 prompt：

1
2

codex "解释一下这个代码库的结构"
codex --model gpt-5.5 "帮我设计一个任务队列"

会话里常用的操作：

• 按 Tab 在 Codex 运行时排队下一条指令（不打断当前任务）
• 按 Enter 打断当前任务，立即注入新指令
• @ 打开工作区文件模糊搜索，按 Tab 插入路径
• Ctrl+R 搜索历史 prompt
• Ctrl+G 用系统编辑器（$VISUAL 或 $EDITOR）编辑当前输入框内容，适合写较长的 prompt；用 VS Code 需要设 export VISUAL="code --wait"，--wait 确保编辑完后内容能回填
• 按两下 Esc 走进之前的消息重新编辑，按 Enter 从那里 fork

沙箱策略 --sandbox

Codex 有三档权限：

1
2
3

codex --sandbox read-only          # 只读，不执行任何命令
codex --sandbox workspace-write    # 只能改工作区内的文件（推荐日常使用）
codex --sandbox danger-full-access # 不受限（慎用）

日常推荐 workspace-write，加上 --ask-for-approval on-request：

1

codex --sandbox workspace-write --ask-for-approval on-request

这是最平衡的配置：Codex 可以自主改代码、执行命令，但跑出工作区范围或者你不放心的操作时会暂停等你确认。

如果需要额外的写入目录，用 --add-dir 扩展，而不是直接升到 danger-full-access：

1

codex --cd apps/frontend --add-dir ../backend --add-dir ../shared

AGENTS.md — 给仓库的持久化说明

在项目根目录放 AGENTS.md，Codex 每次启动自动读取。写项目规范、目录约定、常用命令——和 Claude Code 的 CLAUDE.md 是同一个思路。

1

codex /init  # 让 Codex 生成 AGENTS.md 初始模板

什么时候用：项目刚开始就建。每次你发现自己重复告诉 Codex “我们用 pnpm”、”API 前缀是 /api/v2”，写进去。

第二组：会话管理，跨天接续工作

恢复与 Fork 会话

Codex 在 ~/.codex/sessions/ 里存储所有会话记录。

1
2
3
4

codex resume            # 打开 picker 选一个会话继续
codex resume --last     # 直接恢复最近一次（当前目录）
codex resume --all      # 搜索所有目录的会话
codex resume <UUID>     # 指定 ID 恢复

想从某个会话分叉出新分支、不影响原来的记录：

1

codex fork --last       # Fork 最近一次会话

TUI 里也可以用 /resume 和 /fork。

什么时候用：开发持续多天的功能时，每天用 --last 接着昨天进度。fork 适合”我想试试另一种实现，但不想丢现在的进度”。

/compact — 手动压缩上下文

会话做了大量工作后，上下文会撑满。/compact 把对话压缩成摘要，释放 token 空间：

1

/compact

什么时候用：用 /status 看到 token 接近上限时，或者开始新的大型子任务之前。压缩后 Codex 仍记得做了什么，但不再保留每一轮的原文。

第三组：审批与安全，控制 Codex 能做什么

审批模式 --ask-for-approval

1
2
3

codex --ask-for-approval on-request   # 遇到不确定时暂停确认（推荐交互使用）
codex --ask-for-approval never        # 全自动不问（CI 里用）
codex --ask-for-approval untrusted    # 对不在信任列表里的命令都问

TUI 里用 /permissions 随时调整。

Execpolicy — 规则文件精细控制命令权限

在 ~/.codex/ 下放 .rules 文件，定义哪些命令允许、哪些需要确认、哪些禁止：

1
2
3

# 测试一条命令在规则下的判决
codex execpolicy check --rules ~/.codex/my.rules -- git push
codex execpolicy check --rules ~/.codex/my.rules --pretty -- npm publish

什么时候用：在 CI 或者团队共享环境里给 Codex 划清操作边界，把规则文件提交到 git 里。

--yolo — 跳过所有审批和沙箱

1

codex --yolo "fix the build"

只在已经做好硬隔离的环境里用（Docker、VM）。在本地机器上开 --yolo 等于告诉 Codex 它可以做任何事。

第四组：非交互模式，脚本和 CI 集成

codex exec — 非交互执行

1
2
3
4
5

codex exec "修复 CI 里的测试失败"
codex exec --sandbox workspace-write "生成这次 PR 的 changelog"

# 从 stdin 读 prompt
git diff HEAD~1 | codex exec -

加 --json 输出 JSONL 事件流，方便下游处理：

1

codex exec --json "审查安全漏洞" | jq 'select(.type=="message")'

把最后的回复写到文件：

1

codex exec --output-last-message result.md "总结今天的代码改动"

恢复 exec 会话

非交互任务也支持续跑：

1
2

codex exec resume --last "继续完成之前的重构"
codex exec resume <UUID> "加上我刚才说的边界条件"

什么时候用：CI 里跑了一半失败了，或者非交互任务做到一半你想补充指令。

--output-schema — 结构化输出

给 Codex 一个 JSON Schema，它会确保最终输出符合这个结构：

1

codex exec --output-schema schema.json "分析这些函数的复杂度"

什么时候用：把 Codex 嵌进数据流水线，需要它输出可编程消费的 JSON 时。

第五组：模型与配置

切换模型

1
2

codex --model gpt-5.5 "设计数据库 schema"
codex --model gpt-4.1-mini "把这段注释翻译成英文"

TUI 里用 /model 随时切换，也可以在 ~/.codex/config.toml 里设默认：

1

model = "gpt-5.5"

复杂任务（规划、架构设计）用 gpt-5.5，简单任务用 gpt-4.1-mini，速度快、消耗少。

配置文件 ~/.codex/config.toml

常用配置项：

1
2
3
4
5
6

model = "gpt-5.5"
web_search = "live"    # "cached"（默认）/ "live"（实时）/ "disabled"

[tui]
theme = "dracula"
vim_mode_default = true

命令行 -c key=value 可以临时覆盖配置：

1

codex -c web_search=live "有没有关于这个 API 的最新文档"

Profile — 多环境配置切换

在 config.toml 里定义多个 profile，按场景切换：

1
2
3
4
5
6
7

[profile.ci]
model = "gpt-4.1-mini"
ask_for_approval = "never"

[profile.review]
model = "gpt-5.5"
ask_for_approval = "on-request"

1
2

codex --profile ci "修复测试"
codex --profile review "审查这次 PR"

Feature Flags — 实验功能管理

1
2
3
4
5

codex features list                    # 看有哪些 feature flag
codex features enable unified_exec     # 开启
codex features disable shell_snapshot  # 关闭

# TUI 里用 /experimental 图形化管理

第六组：Web 搜索

Codex 内置 Web 搜索，默认用缓存索引。加 --search 或设置 web_search=live 获取实时结果：

1

codex --search "这个依赖最新的稳定版是多少"

什么时候用：需要查最新文档、库的 breaking changes、近期的 bug 修复记录时。Codex 会在 transcript 里显示 web_search 条目，可以看它查了什么。

第七组：MCP 扩展工具

管理 MCP 服务器

1
2
3
4

codex mcp list
codex mcp add my-tool -- npx my-mcp-server
codex mcp add my-http-tool --url https://my-tool.example.com/mcp
codex mcp remove my-tool

也可以直接在 ~/.codex/config.toml 里配：

1
2
3

[[mcp_servers]]
name = "filesystem"
command = ["npx", "-y", "@modelcontextprotocol/server-filesystem", "/tmp"]

Session 启动时 Codex 自动连接配置好的 MCP 服务器，工具直接出现在会话里。

把 Codex 自己变成 MCP Server

1

codex mcp-server

让另一个 Agent 来调用 Codex，Codex 通过 stdio 对外提供 MCP 接口。

第八组：云端任务

Codex Cloud

在云端跑任务，本地用命令查看和操作结果：

1
2
3
4

codex cloud                                # 交互式 picker 浏览任务
codex cloud exec --env ENV_ID "分析 bug"   # 提交任务
codex cloud list --env ENV_ID              # 查看任务列表
codex apply TASK_ID                        # 把云端 diff 应用到本地

加 --attempts 3 让 Codex 并行跑 3 次，取最好的结果：

1

codex cloud exec --env ENV_ID --attempts 3 "重构这个模块"

什么时候用：任务耗时长，不想占用本地机器；或者想用 best-of-N 来提高复杂任务的成功率。

快捷键速查表

TUI 常用 Slash 命令速查

组合使用示例

开发新功能的标准流程：

1
2
3
4
5
6

1. 确认项目里有 AGENTS.md，写好规范
2. codex --sandbox workspace-write --ask-for-approval on-request
3. /plan 描述功能需求，确认后开始执行
4. Codex 执行时用 Tab 排队下一条指令，不要打断它
5. codex resume --last 第二天接续进度
6. /review 上线前检查改动

CI 里的自动化示例：

1
2
3
4
5
6
7

# GitHub Actions 里自动生成 PR 描述
- name: Generate PR description
  run: |
    git diff origin/main...HEAD | \
    codex exec --sandbox read-only \
               --ask-for-approval never \
               - "根据这个 diff 生成 PR 描述，包含：改了什么、为什么改、怎么测试"

让 Codex 并行跑多个方案：

1
2
3

# 跑 3 个实现，选最好的一个
codex cloud exec --env my-env --attempts 3 \
  "给这个 API 加速，目标是 p99 延迟低于 50ms"

和 Claude Code 的关键差异

用过 Claude Code 的人看这篇会有几个地方觉得”不太一样”：

审批模型不同。 Claude Code 的权限是白名单式（/permissions 配规则），Codex 是三档沙箱策略（read-only / workspace-write / danger-full-access）加上 execpolicy 规则文件。Codex 的沙箱是操作系统级隔离（macOS Seatbelt / Linux Landlock+seccomp / Windows 原生沙箱），Claude Code 的是应用层控制。

会话 Fork 更突出。 Codex 把 fork 做成了一等公民——codex fork、/fork、双击 Esc 编辑历史消息然后 Enter fork——探索多种实现路径的工作流比 Claude Code 流畅。

云端任务原生支持。 codex cloud 和 codex apply 让本地 CLI 和云端任务无缝联动，Claude Code 目前没有对应能力。

配置用 TOML 不用 JSON。 ~/.codex/config.toml vs ~/.claude/settings.json，格式不同，但概念一一对应。

这两个词放在一起是有张力的。”自主”意味着 AI 自己决策，”可控”意味着结果符合预期。各家踩的坑、交的学费，大部分都在这个张力里。

这篇文章想梳理一下：大家在做什么，做到了什么程度，以及我们自己的工作方式可能会往哪个方向变。

一、大厂探索到哪里了

淘宝闪购：单节点做到了极致，但大闭环还没打通

淘宝闪购把 AI 编码率从 9% 提升到 89.2%，用了 5 个月。方法是”Rules（架构宪法）+ Spec（需求规范）+ Skills（执法机构）”三位一体——把工程架构规范显性化，让 AI 能读懂并遵守。

但他们自己也说，下一阶段要打通整个研发周期的端到端交付闭环。编码只是其中一环，当上下游节点真正串联时，如何保证跨节点的上下文不丢失、上游的错误不在下游放大，这些问题还没有答案。

蚂蚁：换了一个视角，让基础设施面向 AI 设计

蚂蚁的 Vibe Coding 平台能在内部月活破万，目标用户甚至不是程序员。他们的核心判断是：不要试图让 AI 适应现有的工具，而是让工具适应 AI。

几个具体结论：GUI 不再重要，能力必须 CLI 化；文档是写给 AI 看的，要有机器可读的格式；跨 Agent 的状态传递用自然语言损耗太大，用文件和 Git 树更可靠。

这些听起来像技术细节，但背后是一个更根本的判断：AI 是新的操作者，基础设施要为 AI 而不是为人来设计。

PayPal：用测试定义流程的边界

PayPal 的 MAIA 项目把 1-1.5 个月的支付迁移工作压缩到 10 分钟，核心不是让 Agent 更聪明，而是构建了一套严密的测试体系——150 多种噪声类型，故意在测试数据里注入拼音变量、错乱的架构、互相冲突的逻辑，让 Agent 在对抗性测试中持续进化。

他们最终交付给用户的，不只是一个迁移工具，而是”Skills 集合 + 测试集”。测试集比 Skill 本身更关键——只要测试足够覆盖边界，中间代码生成的过程是不是黑盒都无所谓。

二、一个反直觉的观察：编码不是瓶颈

百度 Comate 统计了团队一周的 query 分布：代码探索占 19.73%，排查错误排第二，实现新功能才排第三，只有 17.1%。

工程师每天做的大部分事情，不是写代码。理解需求、澄清边界、设计方案、评估影响、等待审批、协调上下游——这些环节加在一起，消耗的时间远超编码本身。

所以当 AI 把编码效率提升了 10 倍，整体速度并不会提升 10 倍。瓶颈转移了，转移到了那些还没被 AI 覆盖的环节。这就是为什么大家都在谈”大闭环”——不是因为编码问题解决了就够了，而是解决了编码问题之后，才真正看清楚了其他问题有多严重。

这对我们自己的业务开发同样适用，只盯着写代码的提效，已经收效甚微了。

三、流程是如何建立的

“建流程”听起来很宏大，但实际上是怎么一步步发生的？

说之前先说一个基础判断：流程是新的代码。

传统软件开发里，代码是执行的载体——你把逻辑写进代码，计算机按照代码执行。AI 时代，流程是执行的载体——你把规则、约束、信息结构写进流程，AI 按照流程执行。写代码需要的技能：理解问题域，拆解逻辑，处理边界情况，验证正确性。建流程需要的技能：理解问题域，拆解逻辑，处理边界情况，验证正确性。技能是一样的，变的是操作的对象，从函数和模块，变成了 Skill 和 Agent 团队。

结合各家的经验，以及我自己用 Claude Code 处理 QCon 9 场录音整理的经历，流程的建立大致分两个阶段。

阶段一：泥泞期

一开始，AI 的理解和你的意图总是错位的。它想写脚本，你想要语义重写；它把专有名词推断成别的东西；它被 OCR 的错误参数误导。这个阶段，人的参与是不可替代的。

你需要亲手跑通流程，去踩坑。踩坑的过程本身，就是在建流程：

• 把每个环节的输入输出协议定义清楚，Skill 拆分到足够细的粒度
• 给 AI 提供高质量的信息环境——给 AI 更好的信息，永远比给 AI 更好的 Prompt 更有效
• 把踩过的坑写进规则，把边界情况注入测试，看 AI 在哪里会崩溃
• 生成和验证分成两个独立的环节，不要让 AI 自我评估刚生成的内容

阶段二：飞轮期

当 SOP 固化之后，执行层可以完全交出去。我处理 QCon 逐字稿，第一篇花了很长时间反复纠错，最后两篇从原始素材到完成——8 分钟。不是 AI 变聪明了，是流程建好了。

研发流程也会走到这个阶段。它本质上是一个由状态机驱动的自动化流水线：产品提交需求，各个 Agent 自动流转，Coding Agent 写出代码，QA Agent 按照预先定义的测试用例校验，失败则打回重写，整个微循环在几分钟内完成，最终抛出一份通过了所有自动化校验的 Diff 供人 Review。

在这个阶段，工程师的工作变成盯指标、看异常、处理 AI 无法处理的边界情况，以及——当流程出问题时，去修改对应的规则和测试用例。

四、未来工作方式的几个判断

基于上面这些，我对我们自己的工作方式有几个判断。

判断一：交付物会变

现在我们交付的是代码。未来，代码越来越是副产品，真正的交付物是”能持续运行、持续自我验证的流程”——Skill 集合加上覆盖了足够多边界的测试集。

这个变化对”什么算做完了”有根本影响。不是 AI 说完成了就完成了，不是代码能跑起来就算完成了，而是所有预定义的测试通过了才算完成。写好测试和验收规则，会占据工程师越来越多的时间。

判断二：基础设施需要改造

现有的各种内部系统——需求管理、代码平台、测试平台、数据平台——大多是为人设计的：GUI 操作，点击按钮，填写表单。当 AI 要参与研发流程时，它需要的不是 GUI，而是 API 和 CLI。

流程里只要有一个环节依赖人工操作，整个流程就有断点，就不可能全自动化。把内部系统 CLI 化，把高频操作包装成 AI 可调用的工具，是一切的前提，而且必须先做。这也是基础设施团队接下来最应该投入精力的方向。

判断三：经验需要系统化沉淀

现在每次 AI 犯错，纠正之后就过去了。这些纠正没有变成规则，下次还会犯同样的错误。

正确的做法是：每次 AI 在某个节点失败，提取一条规则，写进 Skill 或项目的规范文档，下次就不会再犯同样的错误。每次人工介入纠正了 AI 的错误，是一条可以被提取的规则。这些经验如果只存在于人的记忆里，换一个项目就丢失了；被系统化地沉淀下来，就变成了团队的长期资产。

判断五：人的角色在向两端聚集

百度的总结是：关注两头——开始时把问题和目标说清楚，结束时看结果准不准。中间 AI 怎么执行，完全黑盒就好。

蚂蚁的判断是：产品经理的核心价值在 AI 时代更清晰了——最懂用户的那个人。淘宝的判断是：程序员从代码执行者变成规范制定者 + 决策者 + 质量守门员。

三家指向同一个方向：执行层的工作在转移给 AI，人的价值在向两端聚集——定义问题和验证结果。

但有一个环节是人不能外包给 AI 的：建流程本身。流程需要先跑一遍，发现 AI 在哪里卡住，给它更好的信息，纠正错误模式，把踩过的坑写进规则。没有这个过程，AI 的输出质量会停在”勉强能用”。

五、这个新角色是什么

各家对这个角色的叫法不一，但指的是同一件事：有人需要专门负责设计、建立、维护和进化 AI 执行的流程。

这个角色不是产品经理，不是架构师，也不是测试工程师——它是三者的结合，加上对 AI 能力边界的理解。它需要同时理解业务（这个需求为什么重要）、理解 AI 能力边界（AI 在哪里会犯什么类型的错误）、理解工程约束（流程的每个节点如何验证），并且把三者整合成一个可以持续运行的系统。

这是一个比写代码更难的角色，因为它要求你对整个交付链路有全局视角，同时对每个细节有足够深的理解，才能把失败模式提前设计进去。

结语

蚂蚁的彭佩乔说了一句话，我觉得是 QCon 全天最准确的判断：交付才是核心，Coding 是最不值钱的事。

程序员每天真正写代码的时间可能不到两小时，剩下是开会、澄清、调试、等待、协调。AI 接管了写代码这两小时，其他六小时的工作方式还没有改变。

真正的变革，不是 AI 写了代码，而是 AI 接管了整个交付链路——从需求到上线，从告警到修复，从迁移到验证。这个链路里，每一个环节都可以被拆成独立的流程，每一个流程都可以被 AI 驱动，每一个流程都需要人来建立和监督。

这就是未来的工作方式：建流程，看指标，处理边界。

执行层消失之后，剩下的是判断力。

这不是 AI 一开始就能做到的。这是把流程跑通、把坑踩完之后才有的结果。这篇文章想说的，就是这个流程怎么建起来的——以及为什么流程建立之前和之后，效率完全不在一个量级。

任务背景

QCon 录了 9 场分享，加起来将近 8 小时。录音转出来的逐字稿质量很差——说话人会绕话、会引用专有名词、会用口语指代行业术语，ASR 识别出来的结果有大量错误。

我想让 Claude Code 把这些东西整理成 9 篇带配图的可读笔记。

最终全部完成，但中间踩了不少坑。

第一步走错了

第一个坑，是 AI 对任务的理解和我的理解完全不同。

我说”进行语篇规整”，AI 写了一个 Python 脚本：合并同一说话人的连续短句，清理口水话，按正则表达式删除 filler words。

这不是我要的。规整不是字符串处理，是语义理解——原始文本里”歌儿很强，大家想一下歌是什么时候火的？24年8月份，8岁小女孩儿在推特上和他爸爸一块儿完成攻略”，正确的处理是把”歌儿”还原成 Cursor，而不是删掉口水话。

我纠正了一句：不是让你用脚本规整，而是你读取内容重写，处理逐字稿中的错误，尽量还原真实语句。

AI 明白了。这句纠正是后续所有事情能走通的前提。

第一场（快猫星云的 AIOps 分享）规整完成后，AI 报告说把”灭火图”改成了”拓扑图”——它推断这是知识图谱可视化，通用词更准确。

我发现了问题。原文有一句：”那中间我们有一个叫做灭火图的这么一个东西，它其实就是一个可视化的知识库”。有明确解释，说明是他们自己起的名字。AI 纠正了一个不该纠正的地方。

又是一句话，AI 建立了一条规则：上下文里有明确解释的词，即使听起来奇怪也保留，不要用通用词替换。

AI 推断能力的边界

纠正完任务定义之后，AI 的语义理解能力展现出来了。

前四场我没有提供任何参考资料，全靠 AI 从上下文推断。

推断的效果出乎意料地好。”歌儿” → Cursor，靠的是”24年8月爆火”+”8岁小女孩推特故事”两个线索，这是真实事件，AI 认出来了，推断正确。”3毛” → Sam Altman，正确。

但同一场，”他最早在这个 TDC 里面”，AI 推断成了 TED 演讲，实际是 ChatGPT 产品里（我人工听录音确认的）。

再往后，第四场（百度）里，AI 把”COI化”推断成了”MCP化”，理由是”钉钉/悟空在做 MCP 化，时间线完全吻合”。

我看到这个推断就知道不对。演讲内容明显涉及命令行工具，COI 和 CLI 发音相近（C-O-I / C-L-I），应该是 CLI。

但 AI 不知道这场演讲在讲什么，只能靠已有知识猜。它的猜测是有道理的，只是信息不够。

关键转折：信息比提示词更重要

我把 QCon 官网的演讲摘要粘给了 AI——每场演讲都有官方介绍文字，有讲师姓名、演讲提纲、关键术语。

AI 立刻反应：

“明白了。有了这些演讲摘要作为参考，’COI’ 的正确映射应该是 CLI（Command Line Interface）：演讲摘要里明确提到’CLI化’。”

然后它主动回溯，把前几场靠猜测得出的推断重新过了一遍，发现并修正了更多错误。

这是整个过程里最重要的一步。我没有改提示词，没有换模型，只是给了它更好的信息。后续五场的规整质量，明显高于前四场。

这是一个普适规律：给 AI 更好的信息，比给 AI 更好的提示词更有效。 提示词能优化的，是 AI 用已知信息做推断的方式；信息本身不够，提示词再好也有天花板。

又踩了一个坑：OCR

语篇规整完成后，我把拍的幻灯片照片也交给 AI 处理，用 OCR 提取数字和专有名词来辅助校对。

OCR 读出了一个数字：35%。AI 用这个数字修改了文章——“Agent 发现 35% 的工具调用是无效的”。

我人工看了原图，是 8%。

问题出在 OCR 参数。默认的 --psm 3 在处理有图表的幻灯片时，会把坐标轴数字和标题数字错误拼接。图表坐标轴上的”35”和标题里的”8%”被拼在一起，读出了不存在的”35%”。

调整为 --psm 6（把图片当作单一文字块处理），重新 OCR，读出了正确的 8%。

这个教训当场写进了图片编辑的 SOP 文件：使用 --psm 6，OCR 数字用于辅助校对时要结合上下文判断合理性，不要直接覆盖人工记录。

独立审校：看出自己看不出的问题

规整完成后，我用了一个独立的 agent 做审校——和做规整的不是同一个上下文。

审校发现了规整阶段没发现的问题：

• 快猫星云那篇，末尾混入了网易那场的 Q&A（逐字稿录入时串行，内容完全不属于这个话题）
• 淘宝闪购那篇，讲师名字”邓立山”，ASR 错误识别成了”邓丽莎”——主 agent 有了演讲摘要之后执行了替换，但有的地方改漏了，自己没有发现
• PayPal 那篇，版本号被推断成了”Llama 3 Pro”——这个模型根本不存在，我听了录音确认是 Claude Opus 4.6、GPT-5.2 Codex、Gemini 3 Pro

这就是 “生成与验证分离” 的价值。主 agent 带着大量上下文做了很多工作，它的判断会受到自己已有推断的干扰。上下文干净的独立 agent 重新读，反而能发现这些盲区。

流程建好之后

把上面这些坑踩完、规则写进 SOP 之后，流程就稳了。

有了官方摘要，AI 处理每一场的节奏明显紧凑，我的介入越来越少。最后两篇，从逐字稿入库到规整完成——8 分钟。

这个数字说明了什么？流程建立之前，每一场都要反复纠错，方向错了要重来，推断错了要手动修；流程建立之后，执行层可以完全交出去。8 分钟不是 AI 更聪明了，而是它掌握的规则和信息更完整了。

整个过程中，我的实际介入只有这几次：

• 一句话纠正任务定义（脚本 vs 语义重写）
• 一次素材投喂（粘贴官方摘要）
• 人工看了一张图（发现 8% 不是 35%）
• 人工听了一段录音（确认 PayPal 那篇的版本号）

执行层——读文件、重写九篇、跑 OCR、调用审校 agent、写 SOP——全部是 AI 在做。

还有一类问题流程解决不了

流程解决了大部分问题，但不是全部。

有几处是 AI 无论如何还原不了的——录音质量太差，又没有任何参考资料，那几个词就是永久丢失了，信息在进入 ASR 之前就已经消失了。这不是流程问题，是信息的物理限制。

还有另一类：文稿质量很难量化，没有可观测指标。这带来两个问题——独立审校 agent 发现了问题，怎么改、改到什么程度，仍然需要人来判断；更棘手的是，有些问题连审校 agent 也发现不了，AI 推断出了一个”听起来合理”的错误，没有参照物。

这个问题有一个不完美但可用的解法：在规整 SOP 里要求 AI 对不确定的地方主动标注 [?]，不要强行猜。人工审校时只需要重点看这些标注，不用通读全文。这不能发现所有问题，但至少把已知的不确定性暴露出来了，闭环是成立的。

所以人工审校暂时少不了——但工作量已经完全不在一个量级了。

结论

AI 时代，重要的不是会写代码，而是会建流程。

流程的建立需要人的参与，而且不能跳过：先跑一遍，发现 AI 在哪里卡住，给它更好的信息，纠正错误模式，把踩过的坑写进规则。这个过程本身，就是流程建立的过程。没有这个过程，AI 的输出质量会停在”勉强能用”。

流程建好之后，执行层交给 AI，人退到少数几个关键节点：提供素材、人工核实、处理边角情况。

但建流程这件事本身，是你不能外包给 AI 的那部分工作。

这篇是导读，帮你决定看哪几篇。

推荐顺序

各场简介

快猫星云：从 AIOps 到 AgentOps 的故障定位实践

解决方案聚焦知识图谱，但做得扎实。Graph as Context / Tool / Planner / Validator 四种用法清晰，Harness Engineering 工程实践有落地。对做可观测性和运维 Agent 的人有直接参考价值。

网易：从 Vibe Coding 到 Spec Driven 的智能化软件工厂实践

Spec Driven + 低代码可视化平台结合，需求工程（EARS 标准）、Harness Engineering、沙箱技术、模型微调闭环均有落地，有明确效果数据。依赖自研 DSL（NASL），通用性有限，但完整度高。

淘宝闪购：可复制的 AI Coding 全栈实战

Rules + Spec + Skills 三位一体，AI 编码率从 9% 提升到 89.2%。工程细节完整，团队运营飞轮有参考价值。验证、测试、跨应用等更深层的问题尚未触及。

MemTensor：OpenClaw 热潮下的 Agent 记忆系统工程实践

前半段有实质内容：三层记忆分层架构、memOS 设计思路、对 OpenClaw 原生记忆问题的分析。后半段以自家产品 ClawForce 介绍为主。答疑环节关于独立记忆层商业逻辑和组织范式变化的讨论值得单独看。

京东科技：尽在上下文——JoyCode 的企业级 AI Coding 实践

检索体系（RepoWiki / RepoGraph / 多路检索引擎）介绍详实，有具体 token 消耗对比数据。多智能体协同架构有演示。

蚂蚁：Vibe Coding 平台落地半年后的实践经验

三个真实用户案例驱动平台持续演进，KV Cache 省钱、文件即记忆、超大工程管理、多 Agent 协同都有实际踩坑和解法。对未来的判断（基建天生 AI 友好、文档是写给 AI 看的、CLI 化）有前瞻性。内容密度和现场感均为全天最佳。

百度：构建 Coding Agent 的飞轮——Feedback Loop、Benchmark、Agent Engineers

Feedback Loop + Benchmark + Agent Engineers 的飞轮框架思路清晰。偏底层工程，MCP 渐进式加载节省 98% token 等具体技巧实用。整体方案尝试面较窄，时效性存疑——讲者自己也提到 Cursor 才火没多久已经过时，这类工程实践迭代很快。

PayPal：Agent in Practice——从支付迁移落地到评测驱动进化

在强约束条件下（商户代码不可见、商户不懂技术）让 Agent 可控交付，是一种务实的软件交付新形式。评测驱动方法论（EERO 循环、Noise Injection 四级噪声）扎实。对业务团队的借鉴价值高于底层 Agent 开发者。

网易智企：从 Copilot 到 DataAgent——企业级智能数据开发治理平台的技术演进和实践

临时替讲，与原定议题有出入。实际落地的工作主要是模板化 SQL 生成和业务知识积累，DataAgent 架构图尚处于调研阶段，CLI vs MCP 35 倍 token 差距数据来自第三方报告而非自身实践。

主讲：李卓豪（网易智企，数帆 EasyData 技术负责人）
时长：约 47 分钟

数据开发治理平台的 AI 演进四阶段：从单点操作到 DataAgent，以及为什么选择 CLI 而非 MCP（Token 效率差 35 倍）。重点分享了 SQL 生成的三阶段流程（问题改写→表识别→生成校验）和优先做智能运维而非数据开发的决策逻辑。

开场说明

本来今天要讲的是我们 BI 方向的分享，但同事因为不可抗力没能来，我来替他分享一个不同的话题——数据开发治理平台的 AI 演进。以后还会有机会分享 BI 那个方向，大家可以保持关注。

今天的结构：背景 → 技术架构 → 关键实现 → 落地挑战 → 未来展望。

一、背景：部门业务与痛点

部门定位

我们部门分三层：

• 底层：基础设施平台，统一 AI 能力
• 中层：数据开发治理平台（EasyData），今天分享的重点
• 上层：数据应用场景，包括 BI、智能数分等，过去一年重点在数智金融方向

三层之间有业务关联：中层的标准化数仓建设，是上层 BI 和智能数分的基础；中层做好了，上层才能快速体现 AI 价值。我们也在规划把这个平台打造成对外的 AI 应用门户。

我们不只服务网易内部，还有大量对外的 to B 客户，覆盖各行各业。

AI 浪潮下的需求爆发

痛点一：to B 实施效率
不断有新项目合作，如何提高实施效率、压缩成本？包括批量数据标准挖掘、批量入仓、核心指标发现。

痛点二：核心业务基线保障
重点业务（音乐、团队等）如何在承接新任务或业务调整后，保证数据产出时间不变？系统性降低风险。

痛点三：资源治理
硬件价格持续上涨，每年做运动式治理（Spark 迁移、资源下线），但上任务容易下人难，持续有难点。

痛点四：研发效率
新人如何快速熟悉数据架构？数仓同学遇到问题时，不应该还要去关注 Spark 特性、底层存储架构——这些对数仓同学太不友好了，知识负担太重。

二、平台 AI 演进的四个阶段

阶段一（2024 年）：短链路单一场景

用自然语言快速实现单点操作：表权限申请、表的服务 API 创建等。在数据开发的表单页面上直接嵌入，减少操作切换。

阶段二：深度开发提效

数仓开发一直在模仿服务端开发的链路。当时 AI Coding 很火，我们也尝试了模型微调，做整个数据开发内容的补全提示。

阶段三：具体场景独立解决

在具体场景下实现独立解决：SQL 生成、优化建议，数据指标任务配置自动生成，词典提取等。这个阶段投入比较多。

同时做了模板化数仓构建（AutoDM）：针对标准化的业务场景（比如财务数仓），实施同学已经非常熟练，流程很清晰——从财务系统把表拿出来、做分析、建指标，一套固定流程。我们把这个流程模板化，在 Excel 里描述字段映射和加工模式，当遇到新的数据源系统时，通过 AI 做语义等价替换，快速把 A 场景迁到 B 场景。在 to B 的 PoC 场景上得到了大量应用。

阶段四（今年）：DataAgent

今年明显感受到 Agent 需求爆发：

1. 业务自建冲动：我们之前开放了 OpenAI API 和部分 MCP，业务部门开始自建 AI 应用，包括做 Vibe Coding 和 SDD 的尝试
2. 场景爆发：以前只有技术部门用，现在职能部门也需要——周报自动生成、报表自动构建、数据分析 API，各种比赛和分享也在推动
3. 产品内嵌的必要性：
   • 通过 MCP 挂外部客户端，无法把所有产品功能开放出来
   • 金融、国企客户对安全要求非常严格，外部客户端不可接受
   • 需要端到端的场景应用

三、DataAgent 技术架构

整体分层

• 应用层：各产品业务入口
• 接入层（对话层）：通过 SSE 做流式展示，做一层框架无关的抽象（不绑定特定框架，便于未来切换更强的框架），处理安全、权限、上下文管理
• 工具层：大量工具抽象，渐进式加载（比直接全量注入 token 消耗更低、效果更好）

核心能力模块

SQL 生成（最大投入）

质量任务规则自动生成 + 标准分层

元数据智能描述：以前描述基于表，但业务人员问问题时用的是业务黑话和行话，传统方式效果不好

数据安全：敏感字段识别，自动数据分类分级

智能运维：任务出错时自动诊断失败原因，给出优化建议

知识库体系

知识库是效果好坏的核心，分两部分：

用户知识（用户维护）：

• 行业数据定义（不同业务部门对 DAU 的定义可能不同）
• 业务流程知识（可以用工具或 AI 从现有文档中抓取）
• SQL 模板（有些用户对 SQL 格式有强偏执，必须按特定模板）
• 时间参数等自定义配置

系统知识（自动生成）：

整个平台所有数据业务都跑在平台上，我们可以自动生成系统知识库。最初希望靠数据治理人员来完善，但实践发现根本推不动，最终还是靠机器自动化生成。

具体做法：

• 从业务数据中自动抓取，做搜索片段化
• 多表关联、表名数据结合指标的分析
• 系统内置函数和系统字典

知识库更新：定期 + 实时双链路（表变更、任务调整都能感知到）。

更新后推送到召回管理，统计用户评价和召回情况，反哺召回策略。同时推一份到 ES，用于关键词匹配。

四、为什么选择 CLI 化

在设计 DataAgent 时，我们花了很多时间考虑：要不要做 CLI？

为什么不用 GUI 方案：

• GUI 识别能力弱，虽然现在有工具能基于页面元素做识别，但还是不够好
• CLI 在输入控制、token 消耗、让模型发挥主动性方面都更好。以 50 台设备管理场景为例，MCP 方案约需 4,150 tokens，CLI 方案约需 800 tokens，差距约 35 倍

为什么不直接用 MCP：

• MCP 一上来就把所有工具描述全部拉回来，上下文消耗大
• 每次调用都重新拉取，网络调用量大

我们的方案：先把 CLI client 做好，然后：

• 可以把 CLI 挂到 OpenAI 或 Claude Code 上，做质量基线对比
• 对结构化组织要求很高——接口参数虽然嵌套，但要维护这种嵌套结构（打平后验证效果不好）
• CLI 的描述（help text）要写得非常好，这是让 AI 学习的关键

验证时间点：我们内部讨论完不久，钉钉、飞书、企业微信在 72 小时内争相把自己的方案切换到了 CLI 化——这印证了我们的判断。

CLI 设计：分成约 10 个模块，高频操作做短平快的封装，同时维护前端 API 管理（非正式版，用于典型场景验证，稳定后再转成正式版）。做好缓存管理，定期刷新，必要时做实时更新。

五、SQL 生成的关键实现

为什么要做 SQL 片段提取

直接用真实 SQL 学习，有几个问题：

1. 会生成不存在的表名和字段（幻觉）
2. 大模型训练是通用的，不了解内部数据、业务关系、业务规则
3. 无法感知新业务变动（数据架构调整、表关联关系迁移）

解决方案：从真实 SQL 中提取结构化的 SQL 片段。

SQL 片段提取流程

1. 使用线上真实 SQL：平台数据在我们这里，这是优势
2. 裁剪：去掉注释、测试相关片段，只保留核心逻辑，索引关系打散，控制在合理长度
3. 关联元数据：解析 SQL 中的表，了解上下游血缘关系，知道哪些表会受影响
4. 富化描述：用大模型对 SQL 片段做描述补充，完善注释（原始 SQL 可能有业务描述但不完整）
5. 去运行态信息：最终得到结构化的数据服务，而不是嘈杂的原始结构

SQL 生成流程

三个阶段：

阶段一：问题明确与改写

• 判断问题是否全面：表信息是否挖掘充分，参数是否足够
• 风险规避：某些岗位的查询如果做全表扫描会消耗大量资源，要提前识别
• 访问控制：结合业务改写模板对问题进行改进

阶段二：表识别与参数提取

• 做语义 + 关键词双路召回
• 找到业务上血缘关系更近的表
• 从指标关联关系推导计算公式

阶段三：SQL 生成与校验

• 生成 SQL 后不直接使用，先做语法判断
• 不同引擎（Spark/Hive）语法特性不同，需要注入引擎差异，自动纠错
• 最终做完整校验

示例：用户问一个复杂的数据查询问题 → 改写为标准查询意图 → 生成处理条件 → 做假设性回复验证 → 识别所需表 → 召回关联表和计算公式 → 生成 SQL → 语法纠错 → 输出。

六、DataAgent 落地的优先级选择

我们先做智能运维，而不是数据开发，原因：

智能运维的使用频率和闭环价值比数据开发现阶段更高。

典型场景：数据开发同学值班，晚上某个 Spark 任务报警挂了，下游差 3 个小时。以前需要打开电脑排查，现在通过 Agent 自动判断——评估任务在平台上的重要性，自动调用接口获取日志，和底层 Spark 做交互，给出推荐的处理类型，自动调整。

以前运维同学晚上睡觉手机开震动，随时可能被叫起来处理。现在这部分工作越来越多地被 Agent 接管，随着场景不断完善，Agent 处理的比例会越来越高。

七、未来展望

CLI 化是基础：所有能力都要 CLI 化，让 AI Agent 能方便调用。

DataAgent 的核心价值：不只是 Copilot（辅助），而是能端到端交付——这才是 to B 客户的决策者真正想看到的。很多客户不在乎技术细节，他们要的是”数字员工”能直接交付结果。

Skill 的持续抽象：把数据开发治理领域的各种能力不断抽象成可复用的 Skill，构建数据开发治理领域的 Skill 生态。

自动化评估体系：人工做回归成本太高，必须建立自动化评估体系，这是整个 AI 效果持续提升的关键环节。

主讲：郁丁鑫（PayPal，Senior Manager - Software Engineering）
主讲：耿树朋（PayPal，Staff Machine Learning Engineer）
时长：约 54 分钟

把 1-1.5 个月的支付迁移工作缩短到 10 分钟——PayPal MAIA 项目的完整实践。核心是 EERO 循环（执行→评估→反思→优化），以及通过 Noise Injection 构建 150+ 种噪声类型的测试数据工厂，让 Agent 在对抗性测试中持续进化。

背景：为什么要做 MAIA

PayPal 的支付产品已经迭代了好几轮，提供了非常好的支付体验。但很多商户还在用 10 几 20 年前的老技术栈，用户的支付体验非常不友好。PayPal 花了很大精力帮商户做迁移，但摩擦很大：

• 代码改动大，客户很多不懂代码
• 哪怕懂技术，理解老 API（如 NVP——一个很老的协议）的业务语义也很费劲
• 找人来做，费用几千块，周期 1-1.5 个月

借助 AI 的热潮，我们创建了 MAIA（Multi-Agent API Integration Agent），帮助商户在升级过程中尽可能减少摩擦。

MAIA 的价值：

• 加速：把原本 1-1.5 个月的迁移工作缩短到 10 分钟
• 鲁棒性：把老 API 的业务知识蒸馏进 Agent，商户不用关心 API 的具体用法
• 简化：整个升级只需三行命令，token 消耗约 10 元人民币
• 不破坏原有代码风格

MAIA 的工作方式（Live Demo）

假设我是一个小型商户，网站用的是老版 PayPal API 技术栈。MAIA 提供了一个类似 Claude Code 的安装方式——通过命令行唤起 Agent，把安装包部署在商户自己的机器上，基于 Claude Code CLI，把相关 Skill 加载进去，逐步完成整个产品升级。

关键设计：Agent 托管在商户自己的环境里，在商户自己的网络环境中对自己的网站做升级——我们全程看不到商户的代码。

迁移只是第一步。迁完之后，商户还可以继续用 MAIA 做业务场景的集成和扩展——先扔掉历史包袱，再接入更多新产品。

郁丁鑫：MAIA 的架构与演进

开发心路历程

这个项目很早就有想法，随着 AI 能力增强逐步迭代。每个阶段不是推倒重来，而是留存前一阶段的东西，在下一阶段继续迭代。

阶段一：Prompt 工程（2025 年 Q2）

当时最大的概念是”后台编程”，选取合适的 Prompt。MAIA 要分析商户代码、找到集成位置、从老版本升级到新版本，单靠 Prompt 根本做不到。这个阶段学到最重要的东西是：如何保证 guardrail——不能让 Agent 过度发散，要把它限制在最小化改造的范围内。Vibe Coding 用户应该有感受，没有足够好的 guardrail，Agent 会做出让人无法理解的事情。

阶段二：Agent 框架

这时候 Agent 概念开始普及，我们用了 LangChain 等开源框架，加入 planning → 执行 → 自我修正的循环。但受限于上下文处理能力。

阶段三：One-shot + 上下文工程

把大量精力花在如何处理上下文——提前做总结，对上下文中不好的知识提前蒸馏，减少 Agent 运行时的”脑裂”。

阶段四：Harness + Feedback Loop

最近比较火的方向。这个阶段最大的体会是：AI 有一定的欺骗性——给它一个复杂场景，它会说”我做完了”或”这个太复杂我不做”，但其实只是在大模型外面套了一层壳，没有真正完成。

解决方案：把规划者（Planner）、验证者（Verifier）、修复者（Fixer）拆开。当验证者和修复者独立存在时，Agent 就很难自我满足——必须有测试用例告诉它”你要完成这个才算真正完成”。这是我们在 Harness 一年实践中得到的最重要的总结。

MAIA 架构

核心是长期记忆 + 短期记忆的结合：

• 长期记忆：把历史上老 API 的经验蒸馏成 Skill。这是工程师团队花精力最多的地方——很多内部文档已经丢失，需要大量时间重新蒸馏历史记忆
• 短期记忆：Agent 运行时分析商户代码的过程，把知识反馈给执行者、验证者、测试者

Skill 的核心价值：不只是把成功案例放进去，更重要的是把 corner case——Claude Code 等模型一直会犯错的地方——提取出来，变成 Skill 中的参考。同时，正确执行的状态也要指标化，确保模型按照框架走，而不是在”蒙对”。

Feedback Loop：通过一系列测试和指标，让 Agent 汲取足够多的经验，反馈给长期记忆，形成闭环。

耿树朋：评测体系的设计

接下来我介绍 MAIA 的评估是怎么开展的。

MAIA 有一个特殊的挑战：Agent 托管在商户自己的环境，我们看不到商户的代码，但要做一个能准确完成 legacy 代码迁移的 Agent，还要保证执行过程稳定可复现。

这里用到了 EERO 循环：Execute（执行）→ Evaluate（评估）→ Reflect（反思）→ Optimize（优化）。

执行环节：如何摸清商户代码情况

我们对 PayPal 几百万商户的 API 调用数据做了排查，看到了清晰的长尾分布。头部是一些开源电商平台（Magento、ZenCart、Medusa 等），占了相当大比例。

基于此，我们筛选了 6-7 种开源电商平台，覆盖 Java/PHP/JavaScript/C# 四种语言和多个版本，作为 MAIA 初步开发和评估的基础。

评估环节：三个核心问题

问题一：如何提供确定性的测试？

综合了传统测试范式和新的 AI 方法：

• Function test、Unit test
• 基于 Playwright 的端到端测试：覆盖完整的买家→卖家链路（landing 页面→选商品→加购物车→结账→退款），完整覆盖 PayPal SDK 的调用过程

问题二：6-7 个网站够吗？

不够。我们需要覆盖更宽广的卖家可能性，确保测试空间有足够稠密度。解决方案：数据合成——通过 Noise Injection 自动生成大量测试变体。

问题三：可复现性

一次成功和多次成功的概率要保持一致。基于测试方案 + 数据合成，搭建了自己的回归测试 pipeline。

Noise Injection：Multi-Agent 驱动的测试数据工厂

这是一个类似 GAN（对抗生成网络）的设计：生成器（MAIA）负责做代码升级，判别器负责评判升级是否成功。

Noise Catalog：4 个层级，150+ 种噪声类型：

1. 语法层噪声：把变量名换成拼音或随机字母，添加与代码逻辑不符的注释，干扰代码理解
2. 结构层噪声：把多个类合并成一个文件，甚至合并进一个 main 函数
3. 业务逻辑层噪声：加入红包、折扣等活动逻辑，影响支付调度链路
4. 架构层噪声：替换支付路由和设计模式，把 PHP 代码换成 JS 写，引入新依赖

逐级增加难度，不断挑战 Agent 的代码理解能力边界。

循环流程：

• MAIA 拿到带噪声的 legacy 代码 → 尝试升级
• 升级成功 → 加入成功 case 仓库（用于回归测试）
• 升级失败 → 加入失败 case 仓库（用于定点 review）

为了引入更多随机性，我们还加了一个”降级”设计：让模型扮演不同风格的工程师画像（20 年经验只写 PHP 的资深工程师 vs 1 年经验只写 React 的初级工程师），从新版本再降级回旧版本，生成更多样的测试变体。

可观测性工具

一个 MAIA 升级过程可能有几百轮大模型交互，原始 trace 数据动辄几十 MB，人根本看不完，AI 来 review 也会撑爆上下文。

我们自己做了可观测性工具：以图识图的方式，把所有 Agent/Skill 交互以可视化视图从上往下展示，附带时间消耗、token 消耗、工具调用信息。这相当于给整个数据建索引，后续 AI 访问这些数据时效率也高很多——符合渐进式披露原则。

Evolution Engine：EERO 循环的反思与优化环节

数据收集：来源包括 Comate 执行体系、测试报告（Playwright 产生的截图/HTML）、sandbox 环境日志。用 ETL 脚本编排成预定义模板（索引文件），让后续 AI 访问时不会撑爆上下文。

多维审查：用专门的 AI Agent 对运行轨迹做多维度 review，大量使用”模型作为裁判”技术。

交叉验证：

• Confidence level 要达到阈值（如 0.75）
• 多个 AI Agent 参与，必须全部同意才能输出（投票机制）
• 扔掉互斥信息，聚合成有价值的通用知识

关键学到的东西：RCA 追求准确率，不追求全面。一次 RCA 只输出一个，但要它是准确的。如果这一个准确，人看了认可，下一轮迭代再补第二个。不要试图一次把毛巾里的水全拧干——每次只挤一滴水，通过迭代让这件事变轻松。

成功 case 和失败 case 同样重要：只关注失败容易过拟合。用向量空间距离筛选与当前 case 相似的历史成功 case，和失败 case 一起 review——成功的经验帮助过滤掉那些”两边都有”的噪声错误，降低幻觉率。

技术架构演进

Claude Sonnet 4 时代：模型的指令跟随能力比较差，需要很多手动操作。执行引擎：Claude Code；长时运行 Harness：Claude Agent SDK；上层控制图：LangGraph。

Claude 4.5/4.6 时代：迁移到纯 Skill 方案，去掉 LangGraph 依赖。好处：

• 依赖变少
• Skill 里可以嵌入大量 reference 文档和确定性脚本，提供确定性信号
• 新业务来了，一两天就能校验原有 Skill 重新组合后能否满足要求（原来要一两周）

Multi-Agent 协作的关键工程经验

经验一：Agent 间接口必须强约束

多个 Skill 协作时，必须写清楚交接接口——输出文件叫什么名字、放在什么位置、开头有哪些字段。

不这么做的后果：Agent A 输出时没按预定格式写某个字段，Agent B 来读时，Claude 会”脑补”——“虽然他没写，但我觉得应该是这样”——然后基于 A 的局部信息 + 脑补内容继续运行，非常不稳定。

通过 hook 和外部 shell 脚本在特定阶段做确定性校验，才能保证信号可靠。

经验二：每个阶段结束后主动压缩上下文

MAIA 这种长时运行、多轮交互的任务很容易触发上下文压缩。每个 Agent/Skill 执行结束后，主动做一次清晰的阶段性压缩，是非常有效的方式。

经验三：多模型辩论优于单模型

实验结论：同时用 Claude Opus 4.6 + GPT-5.2 Codex + Gemini 3 Pro 扮演相同角色进行辩论，效果优于同一家模型的多个实例辩论。不同家的模型在各自擅长的领域不同，综合多个模型的输出，能得到更全面、更有深度的报告。

SDLC 自动化的五个层级

这个框架可以推广到 SDLC 的任何子模块：

L5 就是 RLRO 范式：Setup（L2）= RL 的数据准备；Rollout（L3/L4）= 执行与评估；Rollback = 失败时回退；Optimize = 基于奖励触发下一轮实验。

核心原则：永远面向未来做 Skill。做一个 Skill 时，不要太关注这次执行成功还是失败，而是想：如果未来要做同样的事，我从这个 case 里应该学到什么？

Q&A

观众：交付给 Agent 的业务知识具体是什么形式？

郁丁鑫：主要是 workshop（工作流文档）+ reference（参考文档）+ 解决方案。

以 NVP 为例，我们写了大量 reference，让 AI 读懂 NVP 里各个字段的含义。针对 PHP、Java 等不同语言，我们会用伪代码把 API 的语义描述清楚，作为参考。当 Agent 识别到用户在某个特定业务领域时，通过伪代码生成对应语言的实现。

本质上有两个概念：老代码 + 伪代码（业务语义），加上转换后的新代码。Agent 在运行中同时参考这两个，根据我们的要求完成转化。

观众：动态构建的参数怎么处理？迁移后的线上验证怎么做？

郁丁鑫：

动态参数：第一次让 Agent 先走完整个流程，定义好所有测试标准和期望值。如果没达到期望，结合历史迭代循环告诉它要往哪个方向走，最终把动态参数塞进去。这个过程需要打补丁，不是一次就能成功的——目前 MAIA 大约 90% 的情况能一次成功，5-10% 需要自己迭代 2-3 轮。

线上验证：测试包和整个 conversion 过程是独立的，商户可以在自己的机器上保留测试包，把结果反馈回来。实际上，迁移和升级过程中我们都会让用户先走沙盒环境，走完整路径后再复制到线上。

观众：未来的软件交付方式会变成什么样？

郁丁鑫：

我们现在的交付不只是一个产品，而是 Skills 集合 + 测试集。

未来的设想：针对某个支付场景（比如 PayPal），我们给一套标准的商户集成方案，定义完整的测试策略。只要这套完整测试都能达标，集成就是完美的。

未来交付给用户的不只是支付产品，而是一个完整的验证生态——这才是新的软件包交互方式。测试集是核心，比 Skill 本身更关键。

这个平台本身是一个 CLI 工具，通过 CLI 才能把完整的端到端流程走通。

主讲：牛万鹏（百度文心快码 Comate，研发经理）
主持：臧志（百度，Coding Agent 驱动的研发新范式专场出品人）
时长：约 53 分钟

Agent 框架的”感冒”，就是没跟上模型变化。百度 Comate 分享了如何通过 Feedback Loop（MCP 渐进式加载、智能上下文压缩、Tool 执行网络）、场景化 Benchmark（四象限异常值分析）和全员 Agent Engineers 转型，构建一个能持续适配模型演进的飞轮。

开场

刚才那位老师讲了个很好的观点——做 AI Agent 时不要做面向专业工程师的，要做泛人群的。我就是那个”大冤种”，专门做面向专业开发者的那个。

我是来自百度文心快码（Comate）的牛万鹏，今天稍微有点感冒，大家见谅。

来的路上突然有个思路：最近北京天气变化太厉害，我因为没及时增减衣物感冒了。这周 Claude 发了一个新模型，再往前倒几周，各种模型、各种工具层出不穷。我这个应用如果不能适配模型的变化，就跟我感冒一样——Agent 框架的”感冒”，就是没跟上模型变化。

今天分享的核心：构建 Coding Agent 时，如何有效适配模型变化、构建一个能持续运转的飞轮。三个方向：Feedback Loop、Benchmark、Agent Engineers。

一、百度内部 Coding Agent 的使用现状

核心指标：人均每周 query 数

我们选择用 query 数而不是 token 数来衡量，因为 query 更能映射用户真正完成了多少任务——一个 query 代表一个任务。token 数很难说明到底给谁提了多少效。

数据：这周我们一个人一周发了将近 100 次 query，挺多的。

三个值得关注的变化：

1. 工具迁移：越来越多的同学从 JetBrains、VS Code 等传统 IDE 迁移到 Cursor 这类 AI 原生编辑器，不再担心编译调试等问题，都在 IDE 里完成了。

2. 角色扩展：我们做的是面向专业开发者的工具，但越来越多非开发者也在用——售前、销售在用 Comate 做项目管理。这完全出乎意料。

3. Query 类型分布（百度一周真实数据）：

最大的三类：

• 代码探索（19.73%）：代码检索、代码解释、探索代码库、调研——大量的人在用 AI 获取信息
• 排查错误（Bug Fix）：把问题给 AI 让它排查
• 实现新功能（17.1%）：才排第三

这恰恰符合工程师的真实工作——我们每天并不都在实现新功能，更多是在研究和排查问题。

两类 query 的业务价值：

第一类：解决之前大量可以用研发解决、但不会被纳入排期的工作。典型例子：产品经理想看过去一周的日活留存，以前要找研发写 SQL，现在产品经理自己用 AI 搞定。这类工作就像战场上的无人机——传统方式调炮兵要层层审批，等决策链走完，人已经走了；现在可以直接精准打击。

第二类：严肃的日常研发迭代。三个月前我还觉得 Agent 只能做一些简单类型，现在已经在大量用 AI 生成代码了。

全栈的重新定义：百度在推全栈，但不是”语言不重要了、你可以写 Python 也可以写 JavaScript”那种全栈。我们的全栈是集各种角色于一身——既有产品经理的 sense，又有交互视觉的 sense，还有构建测试边界的 sense。全栈推动下，大任务交给一个人加 AI，比多人分工效率更高、质量更好。

二、Agent 框架的设计

基本闭环：模型 + 工具 + 环境，构成最基本的 Agent 闭环框架。外围就是 Harness——给 Agent 更多的手和脚去探索外部环境：文件系统、MCP、上下文压缩等各种边界条件。

前段时间 Claude Code 源码泄露，大家可以看到里面有大量处理边界条件的 if-else——所谓 Harness，本质就是把脏活累活、各种边界条件处理好。

框架为什么会”感冒”：

举个具体例子：DeepSeek 刚出来时，它对 function calling 支持很差，但支持 XML 格式。当时很多社区的 Agent 框架都选择了 XML 路线。但到了去年下半年，DeepSeek 的 function calling 支持已经很好了，原来那套框架就跟不上了。

随着模型能力越来越强，很多之前需要精细处理的细节不再需要了——比如以前要把大任务拆成很多小 task，现在直接把整件事给 AI，让它自己做计划执行就行了。没有一个框架可以永远确定，必须动态强化。

三、Feedback Loop：让 Agent 行为可观测

线上数据：统计什么？

我们认为应该统计 4 个层次的指标（从简单到复杂）：

第一层：工具调用

• 工具调用次数、失败率、失败后重试比例

第二层：上下文

• Skill 唤醒情况、上下文消耗

第三层：执行结果

• 一个有意思的发现：当 Agent 创建文件后，反复多次调用工具去修改它，说明第一次创建时分析得不够好。可以通过这种执行轨迹的异常来反推问题所在。

第四层：完整 query 轨迹（最难）

• 从 query 提出到任务完成，整个执行轨迹的质量评估——还在建设中，真的很难。

关键原则：所有数据都要按模型分层看。 以 Claude 为标杆，同时跑其他模型，对比完成同类任务的 query 数和 token 消耗比，发现异常就知道差在哪里。

线上发现的两个具体实践

实践一：MCP 的渐进式加载

我们发现 Skill 上下文消耗和 MCP 消耗对比差异非常大。问题是：如果装了很多 MCP（比如 3 个 MCP，每个有 10 个工具），一次性把所有 MCP 工具描述全加载进上下文，会把上下文撑爆。

Skill 和 MCP 不是非此即彼的，各有长处。我们的做法：让 Comate 自动为每个 MCP 生成一个 Skill 描述，内置一个 skill 工具，描述里说明”现在有 3 个 MCP”。当 Agent 真正需要用某个 MCP 时，再调这个 skill 工具，此时才把对应 MCP 的工具加载进来——典型的渐进式加载。这个方案可以节省最高 98% 的上下文消耗。

实践二：智能上下文压缩

我们发现 8% 的工具调用是无效的——Agent 走了错误路径，但它有自愈能力，能捞回来。

问题：传统压缩方式是把整个上下文交给模型做摘要（summary），但这会让缓存失效，造成大量上下文重新计算。

我们的做法：让模型基于当前 query，识别过去哪些工具调用结果已经没用了，直接把无用的部分摘除，而不是整体压缩。这样既复用了缓存，又保障了当前 query 的上下文质量，还能兼顾成本和效果。

线上发现的另一个实践：Tool 执行网络

通过观察执行轨迹，我们发现工具调用有固定的成对出现模式：

• 编辑文件失败 → 读文件 → 再编辑
• 读文件失败 → ls 查看目录 → 再读

这些是 Agent 自愈能力的体现。我们把这种模式提炼成 Tool 执行网络——工具之间互相指引，形成类似指针的网络关系。

具体实现：给 tool 加 description，比如”如果你从未读过一个文件就想编辑它，应该先调 read 工具”；”如果反复 read 还找不到想要的内容，尝试 search”。

这种方式比强制规定”写文件时必须用 old_string/new_string 格式”更好——不是硬约束，而是引导 Agent 自然地走向正确路径。

四、Benchmark：评测比生成更难

如何构建评测集

从业务本身挖掘：从 git 提交记录里挖。每天都在提交，经过人工审核的合并提交，把这些全捞出来，让 AI Agent 分析 diff log，提取有效的评测 case，最后人工检验有效性。

为什么不用通用 Benchmark：通用 Benchmark（如 SWE-bench）和真实研发场景差距很大。我们需要贴近生产环境的场景化评测。

两个核心评测参数

Outcome：度量结果质量

Executions：度量执行效率

用 AI 评判 AI 的问题：让 AI Agent 跑评测，再让另一个 AI 评判结果，是不是左脚踩右脚？

实践发现：用一个干净上下文的 AI 去评判另一个 AI 的执行结果，效果很好。它能给出很多客观的东西，不用担心它帮我们解决不了问题——它可以客观地评判。这也意味着，现在用 AI Agent 做代码 review 也不是问题了。

四象限分析：看异常值而非分数

把 Outcome 和 Executions 两个参数组合，拆成四象限：

• 高结果 + 高效率：正常，不用管
• 低结果 + 低效率：明显有问题，调整
• 高结果 + 低效率：异常！结果这么好，执行效率为什么这么低？值得深究
• 低结果 + 高效率：异常！结果这么差，执行效率为什么这么高？说明这类模型倾向于不做自我验证就快速结束

核心原则：不看分数高低，看异常值。 同样 60 分，上次对的题和这次对的题可能完全不同——分数一样，但能力分布变了，只有看异常值才能发现这种变化。

五、Agent Engineers：人如何进入飞轮

两层含义：

第一层：全员转型

推动团队全员转型为 Agent Engineers。不写代码的人很难感知 AI 的变化，所以所有人都要上去用。同时，把人也当成给 AI 的反馈——人看 AI 的输出，就是在给 AI 提供信号。

当前最替代不了的是：产品决策、视觉业务判断、用户 sense、测试品味。

第二层：打破角色边界

具体做法：

1. 打破前后端边界：除非极复杂的场景，否则尽可能让 AI 来做，不再区分前后端
2. 反转协作链条：以前是产品经理想到点子 → 研发实现；现在是研发先做出 demo，再让产品经理、视觉工程师来评判调整
3. 需求原子化：希望 PM 和视觉把自己的 sense 做成 Skill，放进仓库。这件事很难，把人的 sense 做成 Skill 真的不容易

Agent 全流程验证：

验证不是简单地跑一下就行，要验证整套逻辑。我们的做法：通过沙盒，把验证过程完全交给 AI——不是一个执行远程代码的服务器，而是一个可授权、可观测、可回放、可验证、可交付的 AI 专属环境，就像给 AI 一台专用电脑，搞坏了重新开一个就行。

交付物的变化：AI Agent 交付的内容不只是代码，还包括：验证截图、执行轨迹文档、质量证据。从”你相信我没问题”变成”请你检验我”——AI 写完代码后，给你看它的验证截图和全流程记录，你来判断结果准不准。

Harness 的两个层次

Harness 工程往前倒一步是”上下文工程”，本质是给模型看到的信息做精准控制。

Harness 应该分成两层：

1. 给 Agent 构建者的 Harness：处理边界条件、工具设计、上下文工程
2. 给开发者/用户的 Harness：每次 AI 写完代码后，如果某个地方写错了，记录下来，未来写代码时作为参考——这是一种技术约束，在教 AI 怎么做

六、总结

飞轮怎么转：

• Feedback Loop 提供信号（线上数据观测、异常发现）
• Benchmark 指导优化（场景化评测、四象限异常值分析）
• Agent Engineers 承接持续演进（全员转型、打破边界、人在回路）

核心建议：构建一个 Feedback Loop，让它能在本地跑 Benchmark，发现异常值，而不是盯着分数去强化训练。不要因为模型的每次发布，让整个 Agent 框架感冒。

Q&A

观众：什么样的公司适合做自己的 Coding Agent？

牛万鹏：凡是上规模的大企业，我都建议尝试自己做，但不是从零做——可以基于 Claude Code 等开源方案改，在里面加入自己的逻辑。原因：大企业有复杂的工作流，单纯靠原生工具很难把内部流程串起来。

小企业就很难回答了，最终哪些能活下来我也不知道。

大家想想 Cursor 是什么时候火的？2024 年 8 月，一个小女孩和她爸爸在推特上分享了用 Cursor 完成了一个项目。到现在 Cursor 仍然很强。这个领域的竞争格局很难判断。

观众：工具希望做成什么样？模型希望做成什么样？

牛万鹏：

工具：希望都能 CLI 化。百度现在所有的研发工具——需求管理、代码管理、邮件、平台——都已经 CLI 化，再把 CLI 命令包装成工具，AI Agent 就能轻松调用。无论是 MCP 还是其他方式接入，底层都应该 CLI 化。

模型：最基本的诉求是接口参数不要老变。比如 Claude 某版本加了新的思考参数，本来有产出的那些开发者，为了引入新参数要重新开发，其他开发者还要去适配——希望模型底层基础设施保持稳定，效果提升就好，别老改参数。

观众：多仓库场景下隐式依赖关系怎么处理？以及沙盒里测不了的深层业务流程怎么验证？

牛万鹏：

多仓库：用工作区（workspace）的概念，可以同时导入多个目录。但你说得对，企业级场景下微服务之间的隐式依赖，你不知道的仓库就不会放进来。这块目前还是需要人来告诉 AI”我在开发这个功能，相关的就这 10 个仓库”。

深层验证：沙盒里确实有些测试做不了，比如涉及 DTS 任务、下游数据计算的业务流程。我们在探索：当沙盒测不了时，让 AI Agent 感知到，自动推到流水线部署到测试环境或预生产环境，再去调那个环境的 API 做验证。这个方向还没有很好的解决方案。

观众：异常值覆盖充分性怎么保证？人在整个交互中应该关注什么？

牛万鹏：

充分性：测试工程师维护一份 Harness 文档，定义验证时应该测哪些功能、回归哪些部分。测试保障 AI 的底线，新需求时研发要写小的 PR 文档，先做计划，再让 AI 验证。

人应该关注什么：关注两头——开始时把问题和目标说清楚，结束时看结果准不准。中间 AI 怎么执行，完全黑盒就好，不用管。

具体做法：把验证流程写清楚成文档，让 AI 按照这个流程验证，并且告诉它哪些是关键检查点、要达标。当我们知道 AI 会走某个策略时，反过来看 AI 应该怎么做——如果 AI 像人一样去执行，那就对了。

主讲：彭佩乔（蚂蚁集团支付宝体验技术部，前端工程师，花名乔洋）
主持：臧志（百度，Coding Agent 驱动的研发新范式专场出品人）
时长：约 56 分钟

蚂蚁内部 Vibe Coding 平台（代号 Muse）落地半年、月活过万的真实踩坑记录。从 search & replace 到 KV Cache 的 token 优化路径，到”文件即记忆”和”一切用 git 管理”的架构理念，再到五个关于 AI 时代基建的”暴论”。

平台介绍

我们在去年（2025 年）7 月左右在蚂蚁内部做了一款在线可视化的 Vibe Coding 平台（内部名 Muse），到现在已经有大半年实践时间，踩了很多真实的坑，今天来分享。

平台定位：用自然语言和 AI 对话生成前后端全栈网站，面向内部所有员工，不需要任何技术背景，会打字会敲回车就行（最近还加了语音输入，连打字都不用了）。

支持四种网站类型：

1. 静态前端网站：简单场景，不多说
2. 前端 + 内部接口：蚂蚁内部有统一 API 网关，所有服务端接口自动注册。用户选中想用的接口，平台自动把接口元信息封装成大模型易理解的上下文，让大模型完成网站。适合有自己服务端的场景
3. 全栈应用（最大量）：非技术用户不懂技术但需要做存数据的真实服务。用户只需自然语言对话，平台自动生成表结构、关联关系、CRUD 接口，连上前端
4. 内嵌 AI 助手：在第三种基础上，给网站加一个 AI 助手，用户可以在网站上和 AI 对话完成功能。大模型调用、流式渲染、定时任务、工作流节点等都内置好了

使用体验：支持一边对话一边实时预览浏览器渲染效果；支持直接选中文字修改排版颜色（兼容低代码用户习惯）；支持多人协作和预览链接分享。

数据：做了半年，内部月活已过万，其中一半是非技术群体。平均对话 12 次左右可以完成一个完整网站。

Case 1：PMO 同事——Token 成本优化

背景

一个 PMO 同事找我，要做数字化管理平台。第一个月账单 5000 多块，花了很多钱。用户没有错，钱是平台的问题，我得想怎么省钱。

Token 主要花在代码逻辑上。当时的做法：把 2000 行代码文件整个扔给大模型改，一来一回 4000 行，太贵了。

精准修改的演进

方案一：git patch 格式
让大模型生成 patch，成功率只有 80%——patch 格式复杂，一旦出错轻则改错，重则崩溃，而且错了还看不出来。不可接受。

方案二：行号定位
告诉模型改第几行，成功率从 80% 提到 90%，还是不行。2000 行的文件，模型会记错行号，而且改错了也没报错，更可怕。

方案三：search & replace（现在通用方案）
把原始内容和新内容都给我，我自己去 search 再 replace。工程化优化：如果目标字符串出现多次，让模型多给一行上下文，narrow 到只有一个匹配时才应用 patch。这个方案成功率接近 100%。

KV Cache：更根本的省钱方案

这些 token 小技巧，最近发现其实可以被 KV Cache 方案覆盖掉。

KV Cache 原理：大模型 GPU 推理的计算结果可以缓存在显存里复用。KV 前缀不变的部分不用重新计算。比如 Anthropic 的 Claude，支持 5 分钟或 1 小时两种缓存模式，命中后打一折，非常便宜。

怎么用：在 Coding 场景天然适合。把不变的部分固化：

• System Prompt：不放任何动态内容，不插时间戳，人设固定不变
• Tools 列表：固化 10 个左右的工具（read、write、replace、create 等），序列化方式保持稳定，保证 KV 前缀不变
• Repo Map：代码仓库索引（有哪些文件、依赖是什么、README），项目没有大重构就不会变，也是 stable 的

这样过半的 token 就已经不变了，这部分打一折。真正会变的只有用户的 user message。实测真实场景缓存命中率约 80%，已经非常便宜了。

顺带一提：最近有个热门项目把自然语言压缩成信息密度极高的类文言文形式来省 token，这类小技巧以后可能都会被 KV Cache 方案覆盖。

这个 Case 的三点启发

1. 不要用固定 workflow 限制 AI：有段时间产品喜欢搞”先分析→前端 Agent→测试 Agent”这种流水线，不要搞。AI 能力越来越强，固定 workflow 只会让效果变差。Harness 才是正确理念：给 AI 真实世界的工具和反馈，让他自己决定怎么做，自己优化。

2. 文件即记忆：受 Manus 团队启发，每一个重要的执行结果都持久化成文件存在目录里，只把索引放到上下文里。需要时让大模型自己用文件方式读取。为什么？文件是 Linux 的一等公民，也是大模型的原生语言——bash、cat、grep 这些它最擅长，给文件地址它自己会 search、head，能精准找到想要的内容，不会把上下文压死。Skills 也一样，以文件形式存在目录里，保持稳定可召回。

3. 超大工程管理：传统工程基建在 AI 时代依然有用。比如提前对项目做一次编译，构建有向无环图描述函数定义和引用关系，给 AI 一个查询工具，它就能精准找到函数在哪定义、被谁消费，直接操作，效率远高于让 AI 自己搜索。把工具提供给 AI，让 AI 决定怎么用。另外 context 一定要管好，1 兆上下文也会 lost in the middle，注意力依然会发散。

Case 2：HR 团队——企业私有知识落地

问题

HR 说平台 AI 太笨，听不懂”阿里价值观”这类内部概念。大模型没训练过，没办法。

解法：Skill 中心 + CLI 对齐

正好那段时间 CLI 化理念兴起，我们借助这个思路在平台做了内置支持：让 HR 口述内部知识库语料，转成 Skill 的形式。建立 Skill 中心，每次遗忘某个 Skill 时，以文件形式存在项目本地，整个 AI 生命周期都能记住。

关键原则：基建一定要和业界标准对齐。 我们整个平台能跑 Claude Code，就是因为标准对齐了，天然享受生态红利。

内置 API 和组件库

HR 要做员工搜索器，不能每次都要求用户手动启动某个 Skill。解法：在脚手架里直接内置 API 和组件库，让 AI 自己决定什么时候启动。这比 Skill 的加载率高很多，几乎 100% 触发。在我们平台说”做一个员工选择器”，直接就出来了，UI 还可以随时修改。

数据安全问题

HR 问：你能看到我的数据吗？我作为平台超管当然能看到，她说那我不用。

解法：测试数据库和正式数据库分开，上线正式数据库后单独设计”数据库管理员”角色，与开发管理权限分离。这类问题在企业内部落地时都会遇到，提前准备好。

内部生态打通

HR 还要求和内部文档、钉钉通知、邮件、日程打通。企业内部平台落地的核心：一定要做一站式全包，连接内部所有生态且合规。 否则用户为什么不用外部平台？合规拦不住的，要真的把用户的工作流搬到你的平台上来。

Case 3：营销同学——C 端大流量 + 私有知识

设计稿还原

营销同学要做蚂蚁森林活动页，有设计稿，要精准还原。以前我们有一套 D2C 方案，把设计稿转 DSL 再生成 React。现在不需要了——多模态模型直接看截图就能还原，让 AI 根据浏览器截图反馈循环修改，简单搞定。

支付宝特有能力的私有知识

支付宝客户端有很多特有 API（比如唤起摄像头），AI 不懂怎么办？

Skill 方案不够完整。更好的方案：在脚手架里内置 examples 目录，把典型用法的例子放进去，并在关键地方放索引指向 llms.txt 格式的文档（AI 友好的文档格式，可直接消费）。例子对大模型来说是最好的学习材料，渐进式披露——它可以直接按照你的模式改代码，也可以去查例子，还可以沉淀到本地复用。

高并发

营销活动需要承受大流量，这逼着我们把平台能力延伸到外部 C 端。我把它叫做”AI 时代的敏捷迭代”：写得快、发得快、跑得好——但肯定还挂得快，这解决不了。

题外话：AI 能帮程序员背故障吗？能帮财务坐牢吗？干不了。高级程序员的价值只会更高，因为只有他们知道怎么更好地驾驭越来越强的大模型。

我们的质量保障手段：

• 每次生成代码自动跑 lint + build，有问题直接在 Agent loop 里反馈修复
• 收集所有 runtime 报错，提供”一键修复”按钮，告诉 AI 哪个页面哪个按钮在什么状态下报了什么错
• 离线扫描：每天定时把每个页面点一遍、每个功能用一遍，报错了让 AI 在用户睡觉时修好

多 Agent 协同与多人协作的挑战

随着用户规模增长，遇到了两个大挑战：

挑战一：跨 Agent 信息传递损失大

用文本在 Agent 之间传递信息损失非常高——把意图压缩成一段文本，丢失了太多。不如直接换角色效率高。

挑战二：多人协同

5 个人一起做一个项目，又要做图片、文档、网站，没法实时多人协同。传统的 git 分支合并方式非技术用户根本用不了。

三个架构理念

1. 一切内容都是文件

文件是 Linux 的一等公民，也是 AI 的一等公民。把图片、Excel、PPT、文档全部转成文件，AI 就可以跨仓库操作所有类型的内容。

2. 一切文件都用 git 管理

以前每种内容有自己的数据库，割裂严重。统一用 git 管理，大模型最擅长 git 命令——想找某个功能为什么消失了，大模型自己去 git log 里找；合并冲突了，大模型自己去排查。而且支持任意版本回滚，不用区分是回滚文档还是回滚代码还是回滚数据库。

3. 一切会话都在 worktree 里

传统 git 分支方式太慢。Claude Code 的作者在开发 Claude Code 时，本地起了非常多 Agent 实例，为了让它们在不同目录里独立工作又能汇总，大量使用了 git worktree。这是现在新的协作模式。

几个”暴论”

1. 未来基建必须天生 AI 友好

以后基建不是给人用的，是给 AI 用的。造轮子的时代彻底结束了——你造一个新框架，AI 不会写，谁会用？要保证你的编程界面和外界开源方案对齐。我们数据库方案完全对齐 Supabase SDK，告诉 AI “这是 Supabase”，它就能直接写，只是换了个底层服务。

2. 文档是写给 AI 看的

你们上次自己读 API 文档是什么时候？现在都是把文档扔给 Claude 让它写代码。所以所有基础能力都必须 CLI 化，必须有一份 AI 友好的文档（llms.txt 格式）。

3. 分清楚你是流量入口还是工具

如果不是流量入口，GUI 不重要，重要的是怎么让你的能力被别的 Agent 调用。未来每个网站都要维护好自己的 llms.txt，设计一套给 Agent 颁发身份的授权系统。蚂蚁内部已经落地了专门针对 AI 的 SSO 系统——之前我把个人 cookie 写到本地让 AI 定时更新，被安全团队找了，因为一个身份每天启动几十个平台太可疑了。

4. 未来所有不能被 AI 驱动的软件都会被淘汰

微软最近在 GitHub Trending 上有个项目，把 Office 系列（PPT、Excel、Word）都转成 Markdown——因为 Markdown 才是 AI 时代的原生第一语言。今年还有个很火的开源项目 anything-to-cli，帮你的软件快速 CLI 化。

5. 交付才是核心，Coding 是最不值钱的事

真正的核心是让用户把工作流搬到你的平台上来，把需求解决。程序员每天真正写代码的时间可能不到两小时，剩下都是开会、扯皮、调试、跨平台部署。

个人演进路径回顾

最早用 Vibe Coding 是为了释放大模型潜力，但发现拉不住他；然后流行 OpenSpec，给他加约束，短期内不好用；然后做 TDD，生成一套测试来约束结果；现在最流行的是 Harness——没有一个固定范式是最好的，核心是在真实环境让 AI 能验证、反馈、修复、循环，持续运行。

近期值得关注的项目：

• HermesAgent：和 Claude Code 的区别是，每次完成复杂任务后会自己决定是否沉淀一个 Skill，每次调用 Skill 时会判断是否过时，每 10 次执行后会决定是否提炼思考——自动化的自我进化思路

• Karpathy 的理念：人类只写 PROGRAM.md 设定目标，AI 自己决定每 5 分钟一次迭代，指标上升了就继续，指标下降了就 revert——纯自动化的自学习循环

• LLM Wiki：知识管理工具。他们提出把文件直接链接起来变成图的理念

• 如何用好 Claude Code：最近 CLAUDE.md 的 star 数涨得很快，排名第一。核心启发：释放 AI 潜力和约束 AI 行为是双轨并行的——一边要释放让他做得更好，一边要约束让他按预期来

Q&A

观众：Harness 现在有很多不同定义，你们的理解和落地经验是什么？

彭佩乔：我们有个团队直接改名叫”Harness 工程团队”。Harness 不是一个固定范式，和 TDD、SDD 都不一样。最近大家的共识是：模型 + Harness = Agent。

具体来说：给模型真实的运行环境和工具——跑在云沙箱上，有 Python、bash 命令；它想完成一个任务，可以直接调 Agent bash 判断代码是否跑起来，可以自己截图看 UI 还原得好不好，自己获取反馈，把事情推进完。核心就是：在真实环境让 AI 能验证、反馈、修复、循环，持续运行。

观众：低代码/无代码平台，用户不会 debug，你们怎么保证产出的东西能跑起来？

彭佩乔：去年 7 月刚上线时，首次页面渲染成功率只有 80%，非常难搞。

我们做了两条路：

1. 前端跑起来后自动收集 build 报错，反馈给 AI 进入下一循环修复，把首次渲染成功率做到了 99%（努力了约 3 个月）
2. 今年切换到 Claude 后，在代码生成节点结束后直接在 Agent loop 里做 lint + test，保证出来的代码已经是好的

观众：产品经理在 AI 时代的角色是什么？

彭佩乔：我们现在已经没有 PRD 评审，也没有设计交互评审，产品经理的交互评审直接是 demo——想做什么功能，直接给工单做个 demo 出来。

但产品经理这个岗位的核心价值更清晰了：AI 时代最懂用户的那个人。他知道用户到底要什么功能，引领非技术群体关心什么，决定产品下一步怎么优化。这个是 AI 替代不了的。

主讲：徐翔（京东科技，JoyCode AI 架构师）
时长：约 47 分钟

检索得准，才是上下文工程的关键。JoyCode 分享了六类检索引擎的选型逻辑（ripgrep/向量/倒排/稀疏/RepoGraph）、RepoWiki 代码知识图谱的闲时构建方案，以及多 Agent 协同架构在 15 天紧急交付中的实战验证。

开场：JoyCode 面临的四大挑战

京东内部有大量不同的业务——零售、物流、健康等，业务场景极其复杂，内部项目大大小小各异，对知识来源有很高的要求。

挑战一：业务场景复杂
用户画像非常丰富：从普通开发者到架构师、算法工程师，甚至财务、法务等非开发同学也在用 JoyCode。

挑战二：复杂长任务
大型项目非常多，复杂长任务很容易造成上下文爆炸，频繁压缩，质量下降。

挑战三：超大代码仓
如何在超大代码仓里快速精准定位，塞入有效的上下文，是核心问题。

挑战四：多元用户需求
不同角色对 AI Coding 工具的期望差异显著，标准化工具难以满足所有人。

一、企业知识增强

我们提供四类企业知识增强来源：

1. Jira/Confluence + 在线企业文档
最常见的做法，把企业文档和知识平台打通，提供知识检索接口。

2. 多模态结构化知识增强
支持文档、图片、Excel、PDF 等各类内容的结构化解析。

3. RepoWiki：代码知识图谱

这是我们重点建设的能力。AI 在后台持续读取代码，生成高层次文档——设计文档、架构文档、核心模块文档、新手引导等。这些文档与企业知识库集成，注入到上下文里。

特点：

• 闲时算力利用：在服务器闲时（凌晨等）用自部署模型跑知识生成
• 多人共享：企业项目往往多人共用，闲时跑出的知识可以同时下发给多个同学
• 增量更新：基于默认分支跑整体 baseline，不同分支做增量更新，极大降低知识形成成本

RepoWiki 解决了新成员上手困难、培训成本高的问题。知识是 T+1 动态更新的，时效性比人工维护高很多。

4. D2C（Design to Code）

企业内部有设计平台和自研组件，传统 AI 生成的代码往往用通用组件，不符合企业内部规范。我们把设计稿 DSL 与企业内部组件关联绑定，实现从设计稿链接获取 → 解析 → 生成企业组件代码的完整链路，保证还原度同时确保使用企业内部资产。

二、上下文工程管理：检索优先

与其他方案不同，我们的重点放在检索上，而不是记忆压缩。

核心理念：检索得准，按需把东西读进上下文，才是最关键的。 而不是把内容先交给大模型，让它一股脑全塞进来，那会引起一系列连锁问题。

检索原则

1. 先定位再读取：定位到代码函数的具体开始和结束位置，才注入到上下文，而不是知道在某个文件里就把整个文件读进来
2. 把选择权交给大模型：定义好每个检索工具的职责边界，让模型自己选择用哪个
3. 提供预处理的仓库理解知识：RepoWiki 和 RepoGraph 提供仓库级知识，避免模型自己去读 package.json、项目配置等

多路检索引擎

我们提供了六类检索工具：

1. ripgrep/glob（精确文本搜索）
优点：正则表达式精确匹配，响应速度快，即搜即用，无需建索引。
缺点：无法理解语义，模糊查询效果差，超大仓库可能较慢。

2. Embedding 向量检索
优点：理解语义，适合模糊的自然语言查询（”用户认证有什么错误处理机制”）。
缺点：索引成本高，有冷启动时间（需要先建向量索引）。

3. 倒排索引
基于关键词的快速检索，速度极快（基于索引，不管仓库多大都是常数时间），弥补 ripgrep 一次返回多个结果时的性能问题。适合技术词汇匹配。30 万行代码仓库，不到 1 分钟可以构建完成。

4. 稀疏索引
和倒排索引的区别：有相关性排序，把与检索语义最匹配的结果放前面。弥补倒排索引”只要匹配就返回”的问题，在向量索引冷启动阶段可以作为平替。基于 BM25 算法。

5. RepoGraph（代码图谱索引）

这是我们重点建设的能力，专门解决超大代码仓的问题。

通过语法树分析，得到所有类、方法的调用关系、继承关系，构建成一个大图。提供可视化界面供用户做交互式分析和反馈（图谱准确性很重要，不准确会给模型提供错误结果）。

主要用途：

• 复杂度分析：通过圈复杂度、函数参数数量、调用数量、依赖数量、继承深度等加权评分，找到项目中最复杂的类和函数。比大模型自己在百万行代码里一点点读要准确得多。
• 调用链路分析：一次检索就能把整体的调用者和被调用者关系全部返回（图的多跳特性，性能达到秒级甚至毫秒级）。传统方式需要十几次工具调用，RepoGraph 只需一次。
• 代码变更影响范围分析：给评估者提供变更影响范围工具，判断这次变更改动范围对不对，有没有漏改。在测试团队应用很广。

实测对比数据

案例一（中型仓库）：开源项目，2600+ 文件，64 万行代码，模型 Gemini。

对比方案（只有 ripgrep + glob）：需要 11 次工具调用，其中 4 次是文件读取，1 次 block，token 消耗很高（因为它一次读取 2000 行以下的文件会全部塞进上下文）。

JoyCode：只用了 1 次稀疏索引 + 2 次 grep，token 消耗少 1 万多。

案例二（大型仓库）：VS Code 仓库，4200+ 文件，1000 万行代码。

对比方案：18 次工具调用，8 次读文件。JoyCode 工具调用次数也更少，且 token 差异对后续任务影响深远——token 多了会更快触发压缩，压缩会有信息损失，进而影响后续任务。

结论：这仅仅是一次简单任务的差距，长任务中差距会成倍放大，对企业成本影响非常大。

三、智能体能力增强

Skills 生态

基于标准化 Skills 框架，构建可插拔的能力生态。根据任务需求动态加载相应工具和技能，避免资源浪费。

多智能体协同

支持三种模式：团队智能体 + 自定义智能体 + 企业知识三位一体。

自定义智能体：用户可以自由组合，指定规则、工具和业务知识，并进行对照测试。

自主规划生成

整合 Spec + TRD（技术需求文档）+ Rules，实现业务特色代码的自主规划和生成。

多智能体协同架构演示

参考 Anthropic 的文章，构建了协调者（Orchestrator）+ 计划者（Planner）+ 执行者（Executor）+ 评估者（Evaluator）四角色体系：

• 协调者：负责调度，不自己干活
• 计划者：制定计划、产品和运输合约
• 执行者：真正干活，把结果给到评估者
• 评估者：做最终测试，使用 Playwright 等工具做交互式测试（打开浏览器，对外部应用进行交互操作）

演示：生成了一个 2D 中国象棋游戏，跑了 6.5 小时（使用 Gemini，不是最优情况），完成度非常高——这是简单的 Vibe Coding 或 Spec 驱动编程很难达到的。

四、真实案例：15 天完成紧急项目交付

京东内部某业务有一个风险项目：供应商违约提前离场，仅剩 15 天完成剩余的高质量交付。

通过搭建智能体协作链路，覆盖整个产研流程：

• PRD → UI/UE → 架构 → 开发（每个环节用一个智能体替代）
• 中间调用 Spec 进行文档和任务状态追踪
• 人工参与：具体输入确认

结果：核心成本（人力、研发周期）大幅节约，代码质量达标。

关键发现：整个过程中需要反复与智能体沟通——Skills 打磨好之后，真正产生的效果也许不符合预期，需要不断给 Skills 反馈，这是相互反馈、相互完善的过程。这也是 Harness Engineering 当前最大的挑战：如何把一个月的调试周期压缩到 15 天。

技术架构师的角色：对比传统模式和 AI 驱动模式，技术架构师的人力投入反而增加了——这是我们未来重点要做的方向，如何让 Harness Engineering 的整个验证链路也能自动化。

五、未来趋势

1. 上下文工程持续演进
如何在有限的上下文窗口里，在数千次甚至数万次的 token 用完时，依然能稳定高效地完成任务——仍然是未来的重点。

2. 更好的 Harness 环境搭建
不只是工程约束，而是如何构建更灵活的驱动机制，让智能体更自由地完成任务。

3. 知识图谱技术
图技术在 AI Coding 里会得到更大规模的推广。不只是代码索引，记忆系统（Memory）也可以用图来构建，把整个记忆构建成图结构，利用图的高性能多跳特性。

Q&A

观众：业务迭代后如何保证 RepoWiki 的知识不过时？支持跨仓库识别吗？

徐翔：T+1 自动更新，后台自动跑。跨仓库支持——我们除了代码维度，还有产品维度的 Wiki，会把所有相关仓库关联起来。也支持 CLI 接入。

观众：D2C 的方向，AI 能力这么强，DSL 还有必要吗？

徐翔：必要。不管 AI 能力多强，要做到企业级的精确还原，并且让生成的组件是企业内部的组件，必须有 DSL 做真正可配置、可控的约束。只有这样才能既保证还原度，又保证生成的组件准确可用。

观众：提供了这么多检索工具，大模型怎么知道用哪个？

徐翔：两方面：第一，每个工具的描述、职责边界定义得非常详细，有明确的”适合用于”和”不适合用于”的指令；第二，Skills 里有专门的搜索策略引导。基本上大模型会灵活选择，我们不希望把它限制得太死。

观众：检索体系的反馈链路怎么构建？

徐翔：必须有 Benchmark，而且是基于内部数据集的。我们评测召回率等指标。另外提供可视化界面，用户可以自己做图的检索和交互式分析，反馈哪块出了问题。每次策略调整后，先在不影响用户的情况下自己跑一遍指标（采纳率、任务耗时等），没问题再上线。检索工具也支持用户自己配置开关，可以自由测试效果。

观众：AI 时代大家每天产出几万行代码，但对代码越来越不了解，线上出了故障怎么办？

徐翔：这个担心是真实的。解决方向有两个：第一，让智能体干活的过程更可视化、更透明，每一步都有留存，这样你有把控感；第二，一定要有评估者——不要让大模型自我感觉良好就草草结束，评估者去做评估后任务才算完成，甚至可以再加一路观察者，保证每个任务最终完成下来有质量保证和实际留存。

我们不应该让生产的系统超出团队的掌控和理解范围，现在的 Harness 工具给我们提供了很多能力，让我们更容易掌控 AI，让它按照我们的想法来实施。

主讲：熊飞宇 博士（记忆张量 MemTensor，创始人 & CEO）
时长：约 49 分钟 + 12 分钟答疑

记忆从效率工具变成了 Agent 能否正常运行的生死线。MemTensor 分享了 memOS 的三层记忆分层架构（明文/KV Cache/参数）、两条技术路径的对比选择，以及企业级多 Agent 产品 ClawForce 在部署、经验沉淀和安全治理上的实践。

今天分享三部分

1. 做 Memory 和 memOS 的整体思考
2. memOS 与 Claude/OpenClaw 如何结合
3. 面向企业的多 Agent 产品 ClawForce：多 Agent 协同与安全管控

一、团队背景

MemTensor 团队 2023 年在上海算法创新研究院成立。在此之前我主要在阿里，先后担任阿里业务中台数据团队负责人、浩天集团数据平台负责人，落地了国内首个零售行业大模型，在核心商品和商家业务上有应用。

团队成立时的核心出发点是探索基础原理层面的创新——从模型架构本身出发，思考什么是需要被补足的。我们认为 Transformer 架构本身存在计算复杂度爆炸和上下文窗口的固有缺陷，势必需要更好的架构和系统设计来解决 Memory 问题。所以我们做的第一件事是训练一个记忆分层的基座模型，也就是 MemCube——业界首个做记忆分层的模型。对记忆进行分层处理，现在已经是业界共识，包括 Google 等团队都在积累这个思想。

基于 MemCube 的核心思路和算法，我们构建了 memOS——记忆操作系统，希望从操作系统的维度去管理记忆，达到整体效果最优。

去年获得了年度前 10 的融资，也拿到了很多订单。

二、为什么 Memory 越来越重要

无论是大模型的 Memory 还是 Agent 型 Memory，随着 OpenAI 发布相关功能后都在一路走高。

几个关键推动因素：

Sam Altman 的大力鼓吹：他最早在 ChatGPT 里上线了记忆功能，效果确实很好——模型能记住你，每次回答都结合你的历史。他反复在各种场合推这件事。

**从”效率问题”升级为”生死问题”**：过去我们认为记忆只是提升准确率和召回率的效率工具。但随着 Operator（任务型 Agent）的出现，如果 Agent 的状态不够准确、记不住关键信息，任务就会失败——记忆变成了 Agent 能否正常运行的生死线。大家对这件事的重要性有了全新认知。

上下文复杂度急剧增长：单个用户单轮对话就已经有极其丰富的上下文（工具调用、知识库、外部信息、反馈等）。扩展到多 Agent 规划、MTA（多任务 Agent）、M 台架构后，复杂度急剧增长。需要一个专门的记忆增强层来屏蔽这些复杂操作，这就是我们做 memOS 的核心出发点。

三、记忆增强的五个核心环节

记忆增强链路可以归纳为五个环节：抽取 → 组织 → 检索 → 更新 → 共享。

• 抽取：从对话或企业文档中捕捉关键信息形成记忆片段。哪些内容应该被抽取成记忆？不同行业、不同场景差异很大，比如情感陪伴类 APP 和工业场景的记忆内容大相径庭。
• 组织：如何构建记忆的逻辑和时间关系。
• 检索：按需快速检索相关记忆用于推理生成。
• 更新：记忆有遗忘曲线，如何动态修正、替换过时记忆，保持知识新鲜。
• 共享：多 Agent 时代，知识和记忆之间的共享与隔离——尤其涉及企业安全时至关重要。

另外，LLM 架构天生带来幻觉，而幻觉在记忆这件事上会向后传导——抽取环节一开始搞错了，后面会一路飘偏。这也是 Claude/OpenClaw 这类系统一直用 context 配置方法存在的问题。

四、两条技术路径的对比

业界做记忆增强有两条路径：

路径一：模型内生驱动

通过设计创新的基座架构，在模型底层嵌入记忆机制，改变模型本体。代表工作：Google 的 Memorizing Transformers（2022）、NCBR 的 focused Transformer（2023）、UCSD 的 MemoryLLM（2024）、我们的 MemCube（2024，业界首个记忆分层框架）、浙大团队通过编辑模型参数来编辑记忆等。

优点：上限高，新架构、新训练策略都能带来显著提升。

缺点：成本极高。我们在 2024 年初训练 MemCube 时，只融到了 240 万人民币，用了 A10 显卡跑了半年，供应商问题直到今天也没完全解决。风险很高。

路径二：应用系统驱动

在应用层叠加一套系统来管理交互内容和信息。硅谷这边很多团队在走这条路。

优点：效率高、扩容容易。

缺点：严重依赖 LLM 能力，幻觉问题突出。

我们的选择：结合两者。模型驱动决定上限，应用驱动决定下限。需要从系统层面做多层次记忆的协同和多触点调度，把参数内、KV Cache 中、明文存储中的记忆统一管理，达到读写效率全局最优。

五、memOS 1.0：记忆分层架构

memOS 1.0 的核心是三层记忆分层架构，源自 MemCube 的思想：

核心思想：把合适的记忆放在合适的位置，实现整体读写效率最优。

基于调度的生命周期管理：举个例子，我和虚拟助手聊天，它知道我喜欢打篮球。对话过程中话题漂移到伊朗局势，系统会根据用户行为预判，提前检索相关新闻存入 KV Cache，保证缓存命中率始终处于高水平，整体效率最优。

图结构组织：记忆之间存在复杂的冲突检验和逻辑结构关系，需要图结构来做更好的组织管理。

六、memOS 2.0：面向长期运行的 Agent

2024 年 12 月底发布 memOS 2.0，核心解决面向技术效率最优的记忆管理框架。

背景：我们发现很多合作企业（游戏、情感陪伴、工业）内部 Agent 的任务复杂度在逐步升高，需要更好的记忆管理框架来支持 Agent 长期运行和状态进化。2025 年初 OpenClaw 热潮爆发后，memOS 的使用量一路攀升。

三个核心思路：

1. 以用户/Agent 为中心的状态管理

龙虾”养死”的根本原因是它对自己的状态判断很差——任务执行到一半，它觉得完成了就停在那里；或者没执行完这一步，直接跳到下一步。memOS 2.0 重点做：

• 状态感知：实时识别用户/Agent 的行为阶段和环境状态
• 状态判定：评估重要节点，预测未来发展
• 状态进化：记忆不再是查询时的静态对象，而是需要被实时调度的动态资源

2. 记忆版本化管理与进化

对 Agent 执行过程中的状态全量存储，清晰地看到哪些记忆应该被淘汰/替换/遗忘，哪些知识和经验应该被记录下来，从而实现经验沉淀和记忆进化。

3. 持续训练记忆衍生基座模型

记忆不只是外挂系统，还要成为模型能力本身的一部分。在模型架构、训练目标和推理机制中原生支持：信息压缩、检索和跨时间调用。我们在架构层面增加了多个 Memory Head，让模型参数能更好地处理记忆的方方面面。

七、memOS 开源社区

memOS 是开源框架，目前 GitHub Star 数超过 8,300，在快速增长，在同类开源项目中排名靠前。社区现有约 1.5 万开发者，其中约 1,000 来自大型企业。我们联合交大等高校共建 memOS 技术和开源生态，欢迎大家参与。

云服务调用量已超过 100 万次/天，分布：60% 左右是复杂 Agent 类型，28% 是游戏和情感陪伴应用，12% 来自硬件层（消费电子设备）。目前是最大的记忆云服务平台之一。

八、memOS 与 Claude/OpenClaw 插件集成

Claude/OpenClaw 原生记忆的核心问题

Claude/OpenClaw 系统的记忆设计存在几个问题：

1. 没有结构化写入：什么时候记什么完全交给模型自己判断，写入稳定性和一致性无法保障，天然会出现漂移
2. 记忆与检索分离：符合软件高内聚低耦合的设计理念，但我们认为这两件事不应该被分开——内容未必会被装进上下文，淘汰后的长期记忆未必能正确沉淀
3. 过度依赖压缩：过多压缩会损害推理的连贯性，代码细节没有被保留，整个代码仓库可能被冲掉

memOS 从 6 个维度做了提升：

• 存储：从单一向量存储扩展到多模态统一管理
• 检索：从 BM25 + 向量双路召回，升级为 RRF 三路融合 + MMR 多样性设计，在召回多样性和准确性之间取得最优平衡
• 过滤：从简单阈值，升级为语义相似度 → 向量排序 → 大模型判断的三层漏斗
• Skill 提取：新增 memOS Skill 提取功能，从对话数据中自动提取结构化任务，转化为参数化的 Skill
• 可视化：MemoryViewer，全功能可视化面板，让黑盒记忆变透明，支持时间线、空间维度的记忆追踪，以及记忆质量看板（重复率、命中率等）
• 团队协作：支持 Skill 在不同 Agent 之间共享，以及数据隔离

两种插件形态

云插件：API 一键接入，5 分钟完成接入，支持高并发、低延迟、多模态，适合 SaaS 产品快速验证。

本地插件（memOS Local）：100% 本地运行，下载安装包即可使用，支持企业私有化部署，适合对隐私有强要求的开发者和企业。

插件架构设计

插件分 6 个模块，3 个同步（环境初始化、上下文组装、记忆处理/压缩/去重）+ 1 个异步（子记忆继承和管理）。实现 0 侵入、全链路覆盖，每个模块可以独立插拔启用/关闭。

核心效果数据

• 大模型评分显著提升
• 3 天内上下文成本下降 30%
• 用户工单交互轮次减少 50%+
• Token 综合节省约 50%

九、企业级产品 ClawForce

ClawForce 是我们在 memOS 之上构建的企业级多 Agent 产品。内部评测：原来开发一个复杂场景需要约半年，使用 ClawForce 后人力大幅下降，开发时间降到约一个半月。

解决的核心痛点：

• 部署：从个人本地部署扩展到 50/100/500 个 Agent 的企业级部署
• 经验沉淀：老员工离职后经验不会流失；以前邮件、审批系统无法自动感知核心节点，需要专人盯——ClawForce 让 Agent 能自动处理这些
• 治理/安全：数据边界、操作追溯、规范审核和回滚

产品架构（从底到顶）：

• 底层：memOS 引擎、Skill 引擎、事件/工具链接
• 管理端：IT 团队快速部署、方案下发和持续优化
• 员工端：让员工真正信任和使用 Agent

三个核心 Demo：

1. 新 Agent 快速部署：通过企业知识 + 模型快速生成 Agent 描述，IT 团队核验后配置模型、外挂、Skill，指定给哪些岗位使用及相关策略，完成部署。

2. 组织经验沉淀：以参展方案为例，Agent 处理后自动更新 Skill，触发 Skill 变更审核流程，管理后台可看到变更详情，审核通过后沉淀到组织，并可配置可使用范围。

3. 安全体系：

• 事前：敏感信息过滤、网关侧安全插节点
• 事中：高危操作（群发、批量操作）需二次人工确认
• 事后：异常行为告警、操作日志导出，给企业提供完整的底线保障

多 Agent 协同示例：一个商务同学有销售背景，需要新增一个商务营销 Agent。Agent 持续向商务助手提供热点信息，商务分析 Agent 判断有价值后，跨 Agent 推送给产品经理，推动产品设计。核心是：哪些记忆需要隔离、哪些需要复用、如何确保状态准确。

答疑

问（观众）：OpenAI 等大模型厂商自带记忆功能，memOS 作为第三方独立记忆层的生存空间在哪里？

熊飞宇：大模型厂商会把记忆留在自己的产品内，核心是通过记忆做用户留存。OpenAI 甚至用记忆层做登录组件，让其他开发者用 OpenAI 的独立记忆层做用户画像。

我们的核心逻辑是做第三方独立记忆层——让不同端、不同数据之间的记忆能够联通和统一管理，让记忆归属于它应该归属的对象（个人记忆归个人，企业记忆归企业），而不是绑定在单一模型厂商。

现实是应用厂商不会绑定单一模型：做对话用 DeepSeek，做长文本生成用开源模型，做语音用语音专项模型。在多模型协同的现状下，独立于模型之外的记忆层是必然需求，这个格局在现有商业化架构下不会改变。

问（观众）：开源版和 SaaS 商业版功能是否一致？开源和商业化是否冲突？

熊飞宇：不冲突。我们现在做的开源会比较彻底，但有时间差——公司成立才一年多，影响力和覆盖面比商业化营收更重要。我们会确保闭源功能在接下来几个月内同步到开源版本，并且 API 几行代码就能接入，对开发者非常友好。

观众（补充）：在中国，开源和商业化确实容易被认为冲突，但在海外市场，开源产品是不可能被企业直接采购的，他们必然寻求付费的技术支持和解决方案。另外开源对产品的反馈回路非常重要，在 AI 时代这一点更加关键。

问（观众）：未来半年 Agent 记忆方向最值得关注的点是什么？

熊飞宇：最核心的方向是记忆工程（Memory Engineering）——如何让记忆在运行时状态更加准确，让 Agent 更好地执行长期任务。这其实就是现在大家讲的 Harness 的重要组成部分：Agent 能稳定运行，记忆是非常关键的一环。如何让它长期稳定、长期有效、长期准确，是最核心的问题。

问（观众）：memOS 里的 Skill 自组织写入，会不会终结人工设计范式？业界好像都在往自动化方向走。

熊飞宇：这个问题本质上是在问 AGI 什么时候到来。在 AGI 到来之前，人还是有非常大的作用。而且即使 AI 能力越来越强，人的能力层次要求也越来越高。你可以看那些自组织框架，它的底层算法是什么？不同组之间的算法关系怎么处理？这些是否也是模型自己设计出来的？——在 AGI 到来之前，这些底层框架和算法逻辑仍然需要人来设计。

问（观众）：企业内部各团队处理相似业务逻辑，如何通过记忆共享和融合避免重复劳动？

熊飞宇：不同层级的员工对同一件事的理解不一样——高层级员工看到的数据和视角更多，但这些东西没有被共享。我们的做法是通过算法把高层级员工的记忆和经验，分发给低层级员工，帮助初级员工快速成长。核心在于：Skill 的质量管控（打分、治理）和私域权限管控——什么级别的人有权限使用什么 Skill，最终由企业内部决策。

观众（补充）：这其实是一种组织范式的变化。有个 CEO 发现，他的管理杠杆不再是招人或管人，而是去梳理每个岗位的业务流程，把每一步骤的数据写下来，教给员工。这是高层经验向低层员工覆盖的一种新模式。在人机协作业务推进过程中，自然会沉淀出大量数字化资产，这些资产将成为未来企业真正的商业模型。

主讲：姜天意（网易智企，CodeWave & CoreAgent 技术负责人）
时长：约 50 分钟

Vibe Coding 解决了速度问题，但带来了质量和可控性问题。网易 CodeWave 通过 Spec Driven Development + Harness Engineering 的组合，把需求标准化（EARS 语法）、技术设计约束、沙箱验证串成完整流程，并用自研 NASL DSL 和代码大模型训练形成闭环。

开场

大家好，非常荣幸第三次来到 QCon。CodeWave 大家可能有所了解，是一个 to B 的 AI 软件研发平台，以低代码和 AI Coding 为主。

今天我要回答一个问题：现在 AI Coding 发展这么好，可视化低代码还有没有存在的必要？Spec Driven 又是什么，它怎么解决 Vibe Coding 的问题？

我来自网易智企 CodeWave 业务中心，负责 CodeWave 和 CoreAgent 的智能体与知识库平台。今天分四个部分：

1. 为什么要把 Spec Driven 和低代码、AI Coding 结合
2. 怎么做需求标准化驱动的 SDD
3. 几百页大 PRD 下如何做复杂任务的 Harness Engineering
4. 怎么训练自己的代码大模型，以及用 Benchmark 度量产品效果

一、Vibe Coding 的问题与 Spec Driven 的提出

AI Coding 的发展脉络

过去三年发展极快。2023 年还是 Copilot 时代；2024 年出现了大量编辑器重塑，Cursor、Windsurf 是其中的佼佼者；2025 年我们称之为 Vibe Coding 元年——大部分编辑器推出了自主编程能力，代表就是 Claude Code 和 Cursor。这些工具很大程度上改变了传统软件研发的格局。

反观低代码，感觉是很”low”的技术，这几年 AI + 低代码的产品比较少，大部分还在探索。

Vibe Coding 的真实问题

2025 年开发者调查报告显示：60% 以上的人认为 AI Coding 显著提升了生产力，但真正能信任 AI 生成代码的只有 3%。

AI 生成代码有几个核心问题：

技术栈不受控：AI 生成的代码风格迥异，倾向于用国外流行的 Next.js、Tailwind 等技术栈，和国内企业现有代码仓库兼容性低。

代码可维护性差：很多人用 AI 写代码，只能用 AI 来 debug，没有好的维护方式，只能不断地”兑换”（重新生成）。

缺少业务理解：在复杂系统里，业务知识的微小变化可能造成生成结果的巨大偏移。

问题的本质：自然语言的模糊性

48 年前，算法大师 Dijkstra 就讲过：自然语言编程是非常愚蠢的事情。

为什么？数学的约束是形式化的符号，你在写形式化符号或编程代码时，同时在做思考和抽象。但用自然语言编程，你想到什么就写什么，AI 写得很快，但缺少了思考。

另外 AI 总是漏需求——你以为说清楚了，AI 表现得像是理解了，但实际上存在巨大歧义。GPT-4、早期 DeepSeek 特别喜欢”奉承”开发者，看起来理解了，其实没有。

还有一点：上下文越长，整个开发质量越来越降级。大模型的服从性反而会变成很大的问题。

核心问题是：无法指望用户写出高质量的提示词，而且自然语言编程缺乏文档、单元测试和架构约束。

Spec Driven 的理念

去年，亚马逊发布了 Kiro，在 AI Coding 工具中引入了 Spec Driven Development（SDD）的工作流，推动 SDD 进入主流视野。

Vibe Coding 的过程是 Prompt 驱动的；SDD 是：先 Requirements（需求标准化）→ Design（技术设计）→ 任务拆解 → Code。

几个关键点：

1. 先把需求澄清清楚，确保 AI 在理解需求上没有歧义
2. 通过 Spec Design 把技术设计和架构约束澄清清楚，用公司的技术栈和目录结构约束 AI 生成
3. 通过 Plan 约束，有利于 AI 生成的稳定性（去年下半年几乎所有 AI 工具都上了 Plan Mode，这是 2023 年就有的智能体模式，Manus 是其集大成者）
4. 通过 TDD 实现可验证性

SDD 能解决什么：

• 代码质量不可控 → 通过技术架构约束保证代码质量在可控范围内
• 可维护性差 → Result Driven Development（RDD）：通过写各种测试用例保证结果对了就好了，不再纠结维护
• 业务理解不足 → 不断澄清产品需求，加入业务理解

但 SDD 不能解决所有问题。很多人会以为 SDD 就是一个大型提示词工程，把输入写得足够详细就行——事实并非如此。

Spec 的问题：

1. 大模型要读得懂你的 Spec，很多模型读不懂复杂的 Spec，做不了好的上下文管理和指令遵循
2. Spec 的编写成本非常高，生成出来的 Spec 人和模型都未必能看懂
3. 复杂应用给到模型后，模型会把编码任务变成复杂的 Code Agent 长程任务，某个节点出现问题就会导致后面全部出问题，甚至无从排查

SDD 只能解决一部分约束问题。 这就引出了第二个概念：Harness Engineering。

二、Harness Engineering：驾驭大模型这匹快马

什么是 Harness Engineering

从 2023 年的 Prompt Engineering，到 2025 年的 Context Engineering，到 2026 年被广泛讨论的 Harness Engineering——本质是：构建一个舒适的环境让大模型去跑。

大模型是一匹快马，没有好的驾驭方案很容易跑偏，在复杂任务上可能失控。

Harness Engineering 包含两个核心要素：

规范：通过 Spec、CLAUDE.md、AGENT.md 等方式约束大模型的行为，这是形式化的规范。

流程控制：在大模型执行过程中，用类似 TDD、CI/CD 这样的流程性东西管控整个执行过程，用控制论的方法管理任务执行的稳定性。

低代码 + AI Coding 的演进

早期：AI Coding 最早的问题是技术栈不受控、维护成本高。很多公司引入低代码技术——Cursor 早期也做过可视化能力，认为通过可视化界面可以看到 AI 生成的界面效果并直接修改。但这个方案开放性太强，没有足够的收敛能力，难以和代码做二次关联，只适合原型创作。

中期：AI Coding 引入 SDD，保证了技术栈受控，但大规模任务的稳定性仍然难以保证，维护成本高，而且只能给程序员提效，产品经理、设计师等角色无法参与。

现在：我们探索一条新路线——可控的语言底座 + 可视化开发 + Spec Driven，彻底解决低代码产品的上手门槛问题，同时通过专用的方式约束 AI 生成代码，借助低代码的资产沉淀、企业级全流程控制和多人协作能力。

三、产品介绍：需求标准化驱动的开发平台

平台核心流程（视频演示）

第一步（产品经理）：导入需求文档，通过 7 个阶段智能分析，转换成标准需求文档，产品经理确认。

第二步（架构师）：启动技术设计，智能体将标准需求拆解为架构设计（应用架构、数据建模、UI/UE 规范、领域服务设计等）和业务设计，架构师 review 并提出修改。

第三步：架构师将确认好的技术设计生成研发任务，执行架构相关任务（实体生成等），逐条或批量执行，智能体自动检测依赖任务。

第四步（开发组）：按项目大小和工期分工协作，执行业务模块研发任务，可继续补充需求和设计细节，贴近真实开发场景。

任务阶段性完成后检查生成内容，修改调整后发布预览，所有模块完成后应用搭建完成。

需求工程：EARS 标准

Spec Driven 的关键在于 Spec 怎么写——什么样的 Spec 人能看懂、AI 也能看懂。

我们选择了 EARS（Easy Approach to Requirements Syntax），一个非常轻量级的结构化需求描述方法，原本用于航天发动机控制系统。Kiro 也使用了这个语法。

EARS 的结构：在什么条件下，当（可选的）什么触发时，系统必须怎样。

举例：

• 原始需求：「系统应该让用户登录方便一点，出错时没有提示」

• EARS 标准化：「当用户输入用户名密码并点击登录时，系统应验证凭据是否匹配，若验证失败，应显示’用户名和密码错误’」

• 原始需求：「用户编辑内容时最好能自动保存」

• EARS 标准化：「编辑框停止输入超过 5 秒时，系统应自动保存」

需求标准化的核心：消除模糊词（”最好”→”必须”），明确触发条件，拆分复合需求，量化非功能需求（”不能太慢”→”2 秒内”）。

我们也调研了 User Story、Gherkin、需求模式等方案，最终选择 EARS，因为它语法简单、可测试性强，非常适合需求工程。

老系统改造：Code to Spec 逆向工程

to B 客户一个很大的痛点是老代码改不动。我们提供了仓库治理插件，可以直接在老代码里对话生成对应的 Spec，再把 Spec 导入到 CodeWave 平台，做源码解读 → 生成 Spec → 开发新系统。

重要的是，在重构过程中还要保持 API 一致性（避免下游依赖崩溃），所以不仅把需求放到 Spec 里，还把技术设计（API 接口）也放进去。

四、大规模 SDD 任务的 Harness Engineering 实践

CodeWave 的平台底座

CodeWave 平台所有内容（页面逻辑、数据定义、数据查询）本质上都是自研 DSL NASL 的一部分，天然是一个约束性非常强的开发平台。AI 化改造相对简单，把可视化方式改造成 AI 交互输入就好了。

自研 Code Agent：Wave-Agent（开源）

我们做了一个自研的 AI Coding 工具 Wave-Agent，完全开源。为什么做这个？不是为了造轮子，而是为了”吃自己的狗粮”——这个项目完全由 Spec Driven 方式开发，12 万行代码，72 个 Spec，整个过程都用 SDD 开发，以此验证 SDD + NASL 能完成复杂项目开发。

相比 Claude Code，我们还增强了一些功能，比如 Language Server 工具支持（对 Java 应用尤其重要）、Spec 工作流和 CLAUDE.md 等。

整体流程

1. 需求标准化：文档上传解析 → 多模态处理（图片）+ 大纲抽取 → 生成 EARS 标准需求
2. 技术设计：领域模型、领域服务、外部依赖，以及关键的 API Contract 层（前后端共同遵守的接口契约，避免前端猜接口）
3. 代码生成：生成 NASL（数据模型、服务端逻辑、前端页面）
4. 验证：沙箱环境运行，Language Server 校验，生成一对一测试用例

技术设计

技术设计生成给架构师审阅的完整文档：领域模型、后端逻辑、前端页面基本目录，再通过子 Agent 并发生成详细设计。依赖关系自动处理（Frontend 强依赖 Backend 接口结构）。

NASL 代码生成

海量上下文下如何保证任务稳定？放弃 Manus Like 的 AI 自主执行，改用 Plan & TodoList 模式——把 40+ 实体、150+ 服务端逻辑、60+ 前端页面拆成有序任务列表，逐步执行，防止上下文爆炸。

智能体架构选型

市面上三类智能体架构：

ReAct 模式（高开放性）：Plan and Execute，最大限度借助大模型的任务规划能力。优点是开放性强；缺点是出了问题无法 debug，Manus 早期就有这个问题（任务跑一天断掉了也不知道发生了什么）。

Skill 驱动（中等灵活性）：把下游实现转成 Skill 驱动，Skill 天然是渐进式披露的方案——把场景的实现固化下来，由 Sub-agent 上下文隔离驱动每个 Skill 执行。在特定 Skill 场景下表现非常好，上下文隔离，Skill 打磨好后任务稳定性很强。

Workflow（低开放性）：固定流程引擎，不相信 AI 自己的编排能力。Token 消耗少，固定流程执行准确，但开放性差。代表产品：Dify、Flowise。

我们的选择：根据场景混用。确定性强的流程用 Workflow，不确定的交给 Agent 自主决策。

知识工程：渐进式披露

不能把所有知识全塞进上下文（大部分模型上下文超过 80K 会出现大规模幻觉）。参考 Skill 的渐进式披露原则：

1. 摘要层：先告诉模型有哪些资源，每个资源负责什么领域
2. 按需召回：提供 MCP 工具，模型自己决定需要什么就召回什么
3. 文档化知识块：每个知识块不超过 1500 token，避免上下文爆炸
4. Few-shot 补充：在文档里加上示例

Compound 复合工程

在跑 SDD 的过程中，模型不知道之前做过的知识是什么样子——比如页面里有些关联是需求层面的，代码层面找不到。

我们引入了 Compound 复合工程：每次跑完后，总结经验，把解决的问题记录形成图，让智能体成为自净化的开发伙伴。Manus 最近也实现了类似功能（自己总结自己的计划）。

多模态支持

需求里有图片怎么办？先判断是原型图（需求描述）还是视觉参考：

• 原型图 → 转成需求描述
• 视觉参考 → 转成视觉和交互描述的 DSL（描述页面布局、时长、分块等），同时传入文字和图片信息
• 架构图 → 直接转化成需求放入 PRD
• 视觉稿 → 转成 NASL DSL，注入上下文生成页面

沙箱技术：Bubblewrap

AI Agent 的行为非常复杂，会遇到 AI 把自己代码删掉、清空数据库等情况，必须有强隔离能力管理 AI 执行环境。

我们对比了多个方案：

• E2B：Manus 早期采用，低资源占用、高隔离，但无法私有化部署
• Docker/虚拟机：部署成本高
• 最终选择：参考 Claude Code 的沙箱模式，使用 Linux namespace（Bubblewrap） 做自然沙箱

优点：不需要很强的权限，启动非常快，命令行结构高效。适合 AI Agent 的沙箱需求。

架构：Sandbox Manager → 唤起沙箱 → 每个服务器集群有 Sandbox Proxy（创建销毁沙箱）→ 每台机器有 Sandbox Instance（管理沙箱状态和启停）→ 从 3 个 Sandbox Process 收集状态，由 Manager 统一管理。

Harness Engineering 设计原则总结

1. 每个 Skill 对应一个 Sub-agent，保证上下文隔离
2. 主 Agent 只负责调度，甚至用 Workflow 方式
3. 每个 Sub-agent 只干自己的事，状态共享全通过文件
4. Context Offload：把上下文卸载到文件，保障任务在各阶段可干预和修改
5. 每个结果都需要可验证，通过 Validator/Hooks 保证
6. 一旦生成错误，验证失败，防止错误向后传播

三要素：智能体架构选择 + 任务管理 + 结果验证

五、Benchmark 体系：数据驱动产品与模型训练

核心原则：No Data No BB

没有 Benchmark，不知道产品边界、模型能力。我们对所有 AI 功能都建立了 Benchmark：需求解析、图片识别、需求标准化、技术设计、组件扩展、外部依赖等。

AI 提效的量化

单一功能提效率 = (手工开发时长 - AI 功能耗时) / 手工开发时长

从开发效率、需求排单度、代码数量等维度综合计算。

代码大模型训练

选择基座模型的标准：代码生成能力、评测及推理能力（推理能力很多 Benchmark 没考虑，但代码生成需要大模型真正理解代码语义）。

我们选择了 Qwen2.5-Coder 作为模型基础，效果非常好。

训练流程：

1. 从开源社区收集代码，转成 NASL 指令格式（指令构造）
2. 建立语言运行沙箱，通过 OSS 合成训练数据
3. 数据后处理
4. SFT（监督微调）+ 采样代码方案
5. DPO 偏好对齐：构造（问题, 正确代码, 错误代码）三元组，强化训练过程。Bad case 比 Good case 更有效。

效果：通过工程修复和模型微调，HumanEval 中文得分从前沿的 5% 提升到 80%。

AI 工程化平台：闭环迭代

Benchmark → 识别产品边界（technology product fit）→ 上线后观测 bad case → 回流到训练平台 → 产品功能升级或模型迭代。

六、总结

Spec Driven 的本质：通过形式化来”降熵”。

• 原始需求：混沌阶段，不可控，熵值最高
• 需求标准化后：原始需求关注度下降
• 加入交互稿和设计稿：视觉和交互的扩展率下降
• 通过代码约束：整个输入输出可观测

Spec Driven 并不是高深的理念，只是通过形式化方式降低混乱程度的过程。

CodeWave 可视化软件工厂 vs AI Coding IDE：前者具备所见即所得、资产沉淀、生命周期管理、大促售货等企业级能力。

未来规划：

• Spec 与代码的双向绑定（改了代码同步更新 Spec，避免 Spec 失效）
• 优化生成速度
• 国产模型适配（Claude 限流封号问题严重）
• 与低代码平台更深度结合

Q&A

观众：为什么要用 NASL 这样的 DSL，而不是直接用大模型能力加上企业规范生成代码？

姜天意：约束性。直接用自然语言描述规范，很多细节说不清楚——数据库结构、关联关系、多步骤接口调用顺序，用自然语言很难描述清楚。NASL 里已经把流程引擎、页面逻辑等细节定义清楚了。

另外，不能过度依赖大模型掌握所有企业知识。我们把它切分成很多领域，每个领域有独立文档，做动态召回，既节省上下文，也让生成更准确。

总结两点：第一，DSL 是限制模型输出的有效方式（以现在的实践来看是这样，半年后可能又不一样了）；第二，有了 DSL 后，可以做很多工程优化，比如渐进式加载、渐进式披露。

观众：验证部分的具体逻辑是什么？服务搭好后怎么做自动验证？

姜天意：验证分三层：

1. 语法验证：通过 Language Server 做语法校验
2. 技术设计验证：基于技术设计里生成的 API 协议，直接生成测试用例，验证接口的输入输出
3. 需求测试：基于每个 EARS feature 生成一对一的测试用例，与业务功能点关联。跑完代码逻辑后，基于生成的一对一测试再跑业务验证

第三层比较靠后，需要测试介入，因为自动生成的一对一测试可能缺少异常流和边界情况，需要基于生成的测试定义做二次关联处理。

前端界面验证：因为我们用 NASL，很多交互逻辑已经在 NASL 里定义清楚了，可以用 AI 直接驱动，可验证性相对简单。

主讲：邓立山（淘宝闪购，高级技术专家）
时长：约 50 分钟

让 AI 写出可控代码，本质是对软件工程的深刻实践。淘宝闪购分享了从”差那么点意思”到 AI 编码率 89.2% 的完整演进路径：双端约束减少幻觉、工程架构作为”宪法”、AI 自我审查闭环，以及如何把经验复制给整个团队。

开场

大家好，我叫邓立山，来自淘宝闪购，主要负责团队的技术架构、研发效能和安全生产。今天分享的主题是「可复制的 AI Coding 全栈实战」，还有一个副标题——“比 OpenSpec 时代更轻量、更清爽、更丝滑”，不过这个副标题被我吃掉了，因为 AI 发展实在太快了。

今天从五个方面展开：

1. AI 编码在生产实战中，为什么总是差那么点意思？
2. 我对 AI 编码可控的本质思考
3. 整体实战方案，以及如何将经验沉淀为团队资产
4. 方案的运营与推广
5. 对下一阶段 AI 编码演进的思考

一、生产实战中的痛点

自从 ChatGPT 爆火，尤其是 2024 年上半年 Devin 和 Cursor 出现后，各大媒体开始喧嚣”程序员要失业了”。当时我们也很慌，于是在 2024 年下半年开始探索 AI 编码。但实践下来发现问题很多：

• AI 根本不懂我们的需求，写出来的是代码框架，业务逻辑基本是空白或写错
• 代码位置放错，不符合我们工程的目录结构
• 写了很多，但质量保证是个大问题

那到底是 AI 能力不行，还是我们用的不好？从模型参数、工具（从 Copilot 到 Agent）、资本市场（Cursor 估值一年涨 5 倍）来看，AI 是可以写好代码的。问题出在哪里？我认为有三个原因：

1. AI 工具的天然短板

AI 编码本质上是概率模型，天然有幻觉，但我们的需求是确定的。另外 AI 训练后知识固化，不了解我们的业务需求和工程结构。

2. 人机协同机制缺失

以前写代码用汇编或高级语言，一条语句执行结果可被编译确定。到了 AI 时代，编程语言变成了自然语言——语气和语调不同，表达意思就不同。如何把自然语言转化成 AI 可以确定执行的指令，是个大难题。另外，以前代码质量靠人工保障，AI 时代 AI 编码的质量怎么保障，也是关键问题。

3. 认知固化

推广时发现有些同学觉得 AI 有幻觉不敢放手，还有些担心把编码工作交给 AI 后自己干什么、技能会不会退化，更喜欢做确定性的执行类工作，不愿意真正去思考如何驾驭 AI。

编码范式的演进

从自动补全 → Vibe Coding → SDD 规范编程 → Harness 可控编码，每一步都是在意识到上述问题后的探索。

二、AI 编码可控的本质

核心观点：让 AI 写出可控代码，本质是对软件工程的深刻实践。

无论是 Harness 还是 SDD，从软件工程角度看都不是新概念，本质都是要交付确定性、可维护的软件。变的是什么？是生产关系：

• 以前：人写代码，架构和规范约束人
• 现在：AI 写代码，架构和规范要约束 AI
• 以前架构规范存在于每个开发者脑海里，AI 并不知道——需要把它显性化，让 AI 能读懂我们的工程

三、实战方案

3.1 减少幻觉：约束输入和输出两端

与大模型交互有三个环节：输入 → 模型思考 → 输出。我们能控制的是两端。

输入侧：把需求描述清楚。针对新增需求和修改需求，定义了不同的规范和模板。需求分析有不清楚的地方，让 AI 集中列出来等人确认，而不是自由发挥猜测。

输出侧：按不同阶段建立不同层次的规范——需求分析阶段遵守什么规范、代码编写遵守什么规范、code review 遵守什么规范。这套模板能清楚描述功能点的前置条件、业务流程、业务规则。

新增需求侧重整体架构设计，修改需求侧重现有代码的变更分析，两套模板分开。

3.2 工程兼容：工程架构作为”宪法”

AI 生成代码和现有工程系统兼容，是最容易被忽略、最容易留下技术债的地方。

解决方案：先让 AI 把整个工程结构描述出来，包括架构模式、目录结构、技术栈、编码风格。这也是个好机会，让我们重新审视架构——随着需求迭代，很多模块职责早已偏离了最初设计。

梳理出来后，把这份工程架构作为宪法注入给 AI，在任何编码时刻都要遵守。实现手段可以用 .cursorrules 或项目级的 CLAUDE.md 等文件。

有了工程架构约束，AI 就不会乱写乱放，会遵守整体结构产出代码。

3.3 编码粒度：项目级一次性生成

把编码粒度分为 7 个等级，从上到下效率越来越高，但质量越来越不可控。随着模型能力增强，可以不断向下探索。

目前我们的实践粒度是单工程项目级——需求只涉及一个工程时，代码可以一次性完整生成。

上下文爆掉的问题：通过任务拆分解决。先让 AI 把需求拆成任务列表，用任务方式记录编码状态，中断后可以方便恢复。实测案例：一个真实线上需求，中间只停了一次，我只说了”继续”，最终一次性生成 66 个文件、5000 多行代码。

3.4 方案可复用性：解耦业务逻辑与规范

不希望每个人都要重新调试一套编码规范。解决方案：把业务逻辑和规范解耦，规范里不含任何业务逻辑，这样一套规范可以给整个团队复用。

扩展性设计：

• 研发流程组件化：不同研发流程包装成独立的 skill，如需求分析 skill、编码 skill
• 文件化隔离：新增需求和修改需求对应不同的规范文件
• 编码内容结构化：某个流程、某个文件、某个场景有问题，直接增加或修改对应规范

3.5 AI 自我审查闭环

AI 一次性生成成千上万行代码后，质量审查是大问题。我们的做法：AI 自我审查 → AI 自我优化迭代 → 人工最终审查。

AI 自我审查维度：

• 业务逻辑与代码是否一致
• 整体代码设计
• 代码质量
• 代码规范

通过这个机制，迭代 3-5 次基本能生成质量较高的代码。人工只需重点关注 AI 容易忽略的高风险地方（如容易产生资损的逻辑），不用逐行审查。

实测：一次性生成代码后直接让 AI 做 code review，初始评分约 70 分。经过第二轮迭代，严重问题基本解决，达到 96 分。本地编译一次性通过。

四、方案演进历程

这套方案不是一次性成型的，随技术发展不断演进：

2024 年下半年：以 Cursor 为代表的 AI Coding 工具迅速普及，我们开始探索，以质量为优先。

2025 年 2 月：形成第一版方案，通过 Prompt 技术包装，出了技术方案模板，让大家按模板描述业务需求。当时已能一次性生成整个服务所有方法的业务逻辑（如门店管理的增删改查），但规范还是手动选择给到 AI。

2025 年 7-8 月：出现了 Rules（.cursorrules），通过 Rules 方式重新升级方案，增加了 AI 自动生成技术方案的能力，并增加了对修改类需求的支持（前期只做新增需求，担心线上风险）。

2026 年初：发现 Skills 技术很好，可以解决分层规范手动选择的问题。通过 Skills + Rules + 我们自研的 Spark，从研发流程和规范约束两个维度重新构建整套方案，实现开箱即用——用户感觉不到任何规范和 skill 的存在，因为 skill 本来就是大模型根据语义自动识别加载的。这套方案也比较符合 Harness 工程的理念，只是我们聚焦于编码阶段。

为什么没有直接用 OpenSpec？

我们调研了两类主流方案：OpenSpec 和 Spec-K，各有优缺点。OpenSpec 学习成本低、自动化程度高，但缺乏统一的规范机制和需求层级划分。Spec-K 正好相反。

我们尝试了 OpenSpec，深度实践下来问题不少：

• 汉化程度差，生成文件中英文混杂
• 需求拆分时没有分清 requirement 和 scenario，导致编码时业务逻辑实现不完整
• 前后端任务混在一起，但前后端研发关注点差异很大
• 任务拆分不符合我们的研发习惯（我们习惯从底层数据层到上层应用层逐步实现）
• 集成我们的规范后，扩展性差，整个流程反而更重

正确的拆分方式：比如”删除门店”是一个功能点，”成功删除”和”取消删除”是两个用例，而不是把整个需求拆成 6 个 spec 文档分散在不同文件里。

最终方案架构

类比软件架构体系：

• Rules（宪法）：工程功能结构、架构模式、技术栈等工程维度信息，时刻约束 AI 不偏离
• Skill 文档（法规）：各环节规范——需求分析规范、编码规范、code review 规范
• Skills（执法机构）：自动识别当前在做什么、参考什么规范，自动加载执行
• 需求迭代文档（绿色）：吸收 Spec-K 的优点，统一管理编码过程中的相关文档，DDL 脚本、接口文档等在编码过程中一次性生成

用户只需把这套方案拷贝到本地工程目录，使用时感觉不到任何规范和 skill 的存在。

五、前端编码实战

前后端研发特点差异很大：

• 前端：从需求拆分页面 → 页面拆分业务组件 → 分析交互逻辑
• 后端：从需求拆分功能模块 → 功能模块拆分功能点 → 细化业务逻辑和业务规则

针对前端特点制定了专门的研发规范，但整体研发流程和后端一致：功能结构分析 → 需求分析 → 编码。

实际需求分三类：

1. 有完整 PRD 的需求：给到 AI 后，页面元素和交互逻辑还原度都比较高
2. 一句话需求：适合技术驱动的运营提效类场景，AI 能分析设计技术方案，但组件交互逻辑需要人补充
3. 接口文档驱动：直接把接口文档给 AI，能还原出对应页面

六、方案运营与推广

把方案变成团队方案并不容易，人的认知很难改变。我们不是强制推广，而是营造编码氛围：

• 技术分享：不定期邀请最佳实践者分享经验
• 月度评审：邀请团队 HR、leader、大部门 leader 来给 AI 编码造势，评选月度”编码先锋”
• 梯度推广：先小范围试点，打磨方案后，在每个团队选一个人带一个需求，一对一指导，做完后他们把经验带回团队做辅导师，形成”分享→实践→沉淀→再分享”的飞轮效应

效果观测：

• 指标一：AI 编码率
• 指标二：千行代码 bug 率和发布故障率（质量不能变差）

从 2025 年 4 月推广到 9 月，AI 编码率从 9% 提升到 89.2%，实现 9 倍以上提升，整体代码质量符合预期。

对外产出：24 篇 ATA（蚂蚁技术社区）文章，其中 8 篇获翰林院推荐（翰林院是 ATA 最高荣誉，全平台整体推荐率约 1/20，本团队获推荐率远超平均），12 篇上头条（全平台约 1/12）。对外公开文章获得 10 万+ 阅读量、1 万+ 点赞转发收藏。

七、未来演进与思考

回顾过去三年：智能补全 → Vibe Coding → SDD 规范编程 → Harness 可控编码，人的参与度在减少，AI 自主化程度在不断提升。

下一阶段：从研发阶段到整个研发周期，构建端到端交付闭环。内部有两个小循环：

• 研发阶段：编码优化 → CR → 单测
• 测试阶段：自动化测试 → 测试报告 → 回到编码迭代

大循环：从需求阶段到线上运营阶段全链路打通。

程序员角色转变：

• 从代码执行者 → 规范制定者 + 决策者 + 质量守门员
• 从关注模块细节设计和写代码 → 关注战略设计和 AI 运营环境设计
• 从”代码即规范”→”规范即代码”，未来可能不再看代码，重点是设计和迭代规范
• 从”我比 AI 强”的认知 → 如何高效与 AI 协作

结语：AI 不是银弹，但它是超级杠杆。用好这个杠杆，不只是把提示词写好，而是需要更清晰的工程思维、更严谨的规范意识、更深刻的软件工程哲学。AI 编码，本质上就是对软件工程的一次深度实践。

主讲：裴彤（快猫星云，AI 产品研发负责人）
主持：秦晓辉（快猫星云创始人）
时长：约 54 分钟

用 Agent 来解决 Ops 的问题，而不是用 Ops 管理 Agent。快猫星云分享了可观测知识图谱 + AI Agent 做故障定位的完整实践，包括图谱自动化构建、四种 Agent 使用策略、Harness 工程和多 Agent 协作架构。

主持人开场

核心其实是大家能把问题说清楚、把任务拆解好，事情就解决了。过去几个月乃至去年，更多是代码层面的”aha moment”——写代码越来越快，新想法落地周期越来越短，但生产环境的代码膨胀速度也越来越快。所以这时候需要更多偏运维层面的手段来应对。

今天的主题是 AgentOps。这个词容易产生混淆，先澄清一下：AgentOps 有两种理解，一种是用 Ops 的手段解决 Agent 的运维问题——很多公司现在有大量 Agent，比如美图说他们搞了 820 个龙虾，各种公司都在疯狂增长，所以有一个方向是用 Ops 手段管理这些 Agent。但今天我们探讨的不是这个，而是如何用 Agent 来解决 Ops 的问题，用少量几个 Agent 解决运维层面的难题。

Coding 场景相对好做，因为上下文非常清晰——你要写什么代码，code base 可以很容易地被 AI 拿到。但在 Ops 领域，信息零散、不规整，AI 把这么多数据放在一起分析非常困难，所以这个问题更难解决。

我叫秦晓辉，可能很多人没听过。2002 到 2014 年前后，大家可能用过 Open-Falcon，后来还有夜莺监控，这是国内最知名的两个监控领域开源项目，都出自我手。现在我在可观测性领域创业，核心帮用户解决可观测性和故障定位的问题。

整体来看，现在市场上各头部企业——Datadog、Dynatrace、SRM，以及专门做 RCA 的 CausalRCA 等——都在往这个方向使劲。这个领域比 AI Coding 稍微滞后一些，但其中最有意思的就是 RCA（根因分析）。做 AI 聊天窗口、梳理知识库相对简单；把各种数据综合起来解决故障定位，才是真正复杂的挑战。这里面要考虑上下文窗口爆掉怎么办、数据不规整怎么串联、metrics/logs/traces/profiling 语义规范不统一怎么处理，以及大模型幻觉——信誓旦旦说找到根因了，其实毫无数据依据。

今天我们有三位讲师分享落地实践。第一位是来自快猫星云的裴彤，之前一直做推荐算法，后来转到运维领域做 RCA 实践。有请裴东。

主讲：AgentOps 故障定位实践

背景：从 AIOps 到 AgentOps 的演进

大家好，我是裴彤，来自快猫星云，目前在做 AIOps 相关工作。

说到 AIOps 这个话题，大家应该不陌生。早在 ChatGPT 火爆之前，大概七八年前，业界就已经在做所谓的 AIOps。这个演进可以分为四个阶段：

以前的 AIOps 本质上是在特定数据集、特定场景下做维度分析，辅助人类决策，并不是真正意义上”拿到任何业务系统就能自动定位故障”。那个时代仍然以人为主，算法只是辅助。

到了大模型时代，大家开始把大模型引入故障定位和运维流程，最初是做 workflow、AI 问答，而现在我们认为有了 AI Agent 这种形态，才真正有可能实现 AIOps 的目标。这个目标有三点：

1. 数据建设的智能化
2. 数据应用的智能化
3. 系统交互的智能化

核心方案：可观测知识图谱

为什么单纯接入 AI Agent 不够用？

首先，AI Agent 缺少推理依据。企业级场景下日志指标量巨大，不可能把所有日志、所有指标全塞进大模型——上下文直接爆掉。其次，模型不知道 A 服务告警和 B 服务有什么关系，关联关系不清楚。另外会急剧放大幻觉——大模型倾向于顺着你的意图说，你问它”这个有什么问题”，它可能无中生有给你找出问题来。最终结论会误导人：有经验的工程师会说”我只是猜测”，但大模型会斩钉截铁给你一个结论，往往误导故障分析。

只有 metrics、logs、traces 的时候，模型既不知道谁依赖谁，也不知道一个服务是干什么的，更不知道异常如何传播。

解决方案：可观测知识图谱

知识图谱的概念不新鲜，传统 AIOps 时代也有人提，但到了大模型 + AI Agent 时代，它天然适合作为推理的基础。

我们把知识图谱分为三层：

• 最底层——实体：监控对象，可以是微服务、K8s Pod、中间件、数据库、Job 等
• 中间层——关系：A 服务依赖 B 服务，C 服务部署在 D 节点上，各种关联关系
• 上层——属性：实体的基础描述（服务名、标签、SLO），以及关联的 trace 元信息、日志元信息、事件信息等

有了这个图谱，就可以通过实体找到它依赖的其他实体，同时对实体做”下钻”——从实体去分析它的日志、traces、事件等。

知识图谱的好处：全局快速查看系统状态；快速收敛分析范围；支持巡检、排查、故障定位。我们最初做这个东西，出发点其实是让人能直观地看到整个系统状态——平台上一看，就知道哪里有异常点、风险点。到了大模型时代，发现它天生适合 AI Agent 做推理。

知识图谱的自动化构建

数据建设才是最脏、最复杂的工作，这一点往往被忽略。大家谈知识图谱应用时，往往假设”我已经有了完整的知识图谱”，但怎么建出来才是关键。

用 AI 加速图谱构建，而不是直接生成图谱数据

核心思路：不让模型直接生成知识图谱数据（成本高、幻觉率随数据量增加），而是让模型生成一套规则，再用规则驱动程序持续更新图谱。

以指标数据为例：一个数据库里可能有几千万、几亿条时序曲线，不可能全塞给模型。但我们只需要做抽样，让模型分析：这条指标叫什么名字、有哪些标签、标签的 key 和 value 是什么，模型就能识别出”这是某个服务的 CPU 曲线，IP 标签对应的是机器实体”。这样就提取出了一套规则——用 IP 标签值作为实体标识。规则生成后，程序定期执行，知识图谱就能持续更新。

日志、traces、事件同理——通过模型自动分析关联关系，不需要人工逐个梳理每个服务的归属。

实际场景中，规则类型很有限，可能就是 MySQL、K8s、物理机等几类，每类生成一套规则，程序来执行。

知识图谱在 AI Agent 中的四种用法

1. Graph as Context（上下文）

把知识图谱作为模型的上下文。典型场景：分析日志异常时，直接把异常日志扔给模型效果不好——模型不知道哪个 error 是真正导致成功率下跌的，哪个只是无关的依赖报错。把知识图谱作为上下文注入，告诉模型当前服务是什么、依赖哪些组件，可以增强模型的背景信息。

2. Graph as Tool（工具）

把知识图谱作为 AI Agent 的工具。典型场景：定位多层次异常，底层某个故障层层传播到上层服务。把图谱作为工具注入后，模型可以自己调用工具查询依赖关系——“A 服务异常，查一下它依赖的 B 和 C 服务”——避免把整个图谱、整个 trace 全塞进上下文，同时约束了推理路径。

3. Graph as Planner（规划器）

把知识图谱作为规划器。在复杂场景下，先让模型做规划（列出 1、2、3、4、5 步），再按步骤执行。知识图谱作为规划器，可以约束分析流程，避免模型看到一个服务就分析一个服务、链路过长导致中间细节丢失。比如强制要求：A 服务异常，必须先看 A 服务的日志和 traces，得到基本洞察，再基于洞察调用工具分析下游路径。

4. Graph as Validator（验证器）

把知识图谱作为假设验证的循环。模型往往过于自信——分析出”根因是 B 服务”，但 B 服务到底有没有问题？需要验证。流程：得出结论 B 后，去知识库查 B 的健康指标、成功率、存活状态。如果 B 确实有问题，结论明确；如果 B 指标正常，告诉模型”B 是正常的，重新思考”；如果 B 根本不在知识库里，无法验证，则提示模型给出不确定的结论。这个机制能有效避免模型的过度自信误导人。

Harness 工程：精准信息供给

Harness 这个概念本质上和”上下文工程”是一回事——给模型提供最精准的信息，信息过多产生幻觉，信息过少模型无法推理。

指标数据的处理

指标有两种输入方式：文本（时间戳+值的序列）或多模态截图。多模态受模型能力限制，效果一般，我们目前还是用文本。

文本方式的问题：一条曲线正常时基本平稳，异常时才有几个异常点，把全量数据塞给模型很浪费，而且对分析没好处。我们的做法：做算法前置处理——异常点检测、趋势分析，只把异常点和整体趋势给模型，信息直接、准确，对定位准确率和上下文消耗都友好。

日志数据的处理

故障时日志会刷屏，一个服务可能瞬间几万条甚至几十万条。全量给模型不现实。我们的做法：

• 日志聚类和去重：用经典的日志聚类算法（如 Drain）提取若干模板，每个模板里抽样，保证关键日志不丢失
• 关键词提取

总体思路：用传统工程和算法手段提升确定性，减少分析耗时和 token 消耗。

多 Agent 协作（解决 Lost in the Middle 问题）

模型上下文有限，而且存在”Lost in the Middle”问题——上下文过多时，中间内容会被遗忘，只记得开头和结尾。

我们的架构：一个 Manager Agent 主导整个故障分析逻辑，生成共享上下文（当前故障背景、异常指标、故障对象在知识图谱中的元信息、业务自定义知识库、skills 等），分发给各专项 Sub-Agent（日志分析、指标分析、事件分析等）。每个 Sub-Agent 在自己领域做分析，结论汇总回 Manager，由 Manager 综合生成最终的故障定位结论。

原则：只提供精准且必要的信息。

Workflow vs. Agent

去年大家更倾向于做 workflow 编排——针对某个告警场景编排一个 workflow，不同场景不同 workflow。今年更多转向 Agent 方案——用一个通用 Agent 解决所有问题。

但在我们的实践中，workflow 并没有失去意义：

• Workflow 解决确定性问题：场景明确、能力结构化，workflow 更可靠
• AI Agent 解决不确定性问题：不知道该先分析谁、有长尾问题，交给 Agent 自己决策

实践上，我们会把固定的 workflow 也包进来，后续可以把 workflow 转成 skill 描述给模型，既平衡了 workflow 约束过紧的问题，又给模型一定的确定性流程。

Skill 和 Tool 的设计取舍

关于 skill 设计：用一堆自然语言描述”先调用 A，再调用 B，再调用 C”，效果远不如直接写成脚本、封装成接口让模型调用。确定性逻辑用工程方法实现，比完全依赖自然语言更可靠。

关于 tool 设计：运维类 AI Agent 和通用 Agent 不同，不需要设计各种通用工具，而是基于定制化场景设计。对于危险操作，可以根据场景明确禁止执行。

AI Agent 的记忆系统

在故障定位场景中，记忆分三类：

• 短期记忆：故障现场，包括指标、日志、traces，以及各 Sub-Agent 的结论
• 结构化记忆：知识图谱本身，包括实体关系、下钻路径
• 业务知识和 skill：根据不同业务场景沉淀的知识库，指导 Agent 如何操作

还有一种长期演化记忆：Agent 应该能自我学习。历史故障分析完后，Agent 应该记住结论，下次遇到类似故障可以参考。但这里有复杂机制——一年前的故障经验未必适合今天，需要设计时间衰减和淘汰机制。这个方向我们还在探索中。

产品落地：FlashCat

FlashCat 是我们基于开源运营实现的可观测性产品，把上述知识图谱能力做了平台化和可视化。

架构分三层：

• 最底层：数据集成（metrics、traces、logs 等）
• 中间层：灭火图（可视化的知识图谱）
• 最上层：AI Agent 流程，包括标准逻辑、记忆、运行时逻辑

使用流程：

1. 接入各种数据源
2. 通过自然语言创建知识图谱规则——AI 自动分析数据源，提取实体、创建规则，人工修正即可
3. 可视化界面：每个圆圈是一个实体，有异常/正常的可视化展示，可以下钻查看日志、traces、事件
4. 自然语言交互触发故障定位：Agent 通过各种模式约束分析路径，依次分析依赖关系，给出结论
5. 扩展到日常巡检：让 Agent 巡检整个知识图谱，发现当前有哪些异常

未来展望：AI 生成的代码越来越多，人很难逐行审查，可观测性变得更加重要——通过监控来判断系统是否可用。未来平台应该是能持续进化、自主学习的系统，通过反馈闭环不断优化故障定位能力。

感谢大家。

Q&A

观众（多个问题）：故障定位的评估比较难做，你们有做评分机制吗？另外指标特征提取用的是自研算法还是参考业界的？还有知识图谱里的数据会变化，同步机制是怎么做的？

主讲：评估确实是难题。目前我们平台还在公测阶段，还没有完整的自动化评估体系。我们后续会做一些规划，比如跟大促方向结合——代码改动后，知识图谱里的 spec 会随之更新，保证数据的时效性。指标特征提取方面，我们结合了业界算法和自研，不是完全从零做。知识图谱的同步是定期 + 实时双链路，指标/日志/拓扑变更都会触发更新。

我的默认宠物是一只 common axolotl——最低档，无闪光。我想要传说闪光卡皮巴拉。

于是我把这个系统的漏洞原理告诉了 Claude，让它去 190MB 的 Claude Code 二进制里找算法。它自己定位到了打包进去的 JS bundle，读懂了压缩混淆的代码，写了枚举脚本，还在第一版算法出错后自己设计实验修正。最终 14400 次枚举，0.04 秒，传说闪光卡皮巴拉出来了。

漏洞在哪里

/buddy 宠物由种子哈希决定——同一个种子永远孵化同一只动物。种子的来源有优先级：

1. 优先用 accountUuid——Anthropic 服务器下发的账户唯一标识，绑定账户，无法伪造
2. 没有 accountUuid 的话，fallback 到 ~/.claude.json 里的 userID 字段
3. 连 userID 都没有，用 "anon"

关键在第二条：**userID 是本地文件里的字段，你可以随便改。**

什么情况下没有 accountUuid？用第三方 API（自定义 API key 或 proxy）的用户，配置文件里天然没有这个字段。订阅用户（Claude Max）正常登录会写入，但用 CLAUDE_CODE_OAUTH_TOKEN 环境变量方式启动时不会写——这是另一个大 V 发现的绕过路径。

这只涉及本地配置文件里的一个字段，不涉及任何服务器端数据。

操作步骤

如果你正在用 Claude Code，最省事的做法是直接把这篇文章发给它，告诉它你想要什么宠物，让它来判断你的情况、跑脚本、改配置文件。这篇文章里的卡皮巴拉，就是这么来的。

下面是手动步骤。

第一步：确认你的情况

1
2
3
4
5
6

python3 -c "
import json, os
d = json.load(open(os.path.expanduser('~/.claude.json')))
uuid = d.get('oauthAccount', {}).get('accountUuid')
print('订阅用户，需要先绕过 accountUuid（见文末）' if uuid else '第三方 API 用户，直接操作')
"

第二步：找到目标 userID

需要安装 Bun（Claude Code 本身依赖 Bun，一般已经装了）。

把下面的脚本保存为 buddy-reroll.js，把 TARGET 改成你想要的宠物，运行 bun buddy-reroll.js：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

const SALT = "friend-2026-401";
const SPECIES = ["duck","goose","blob","cat","dragon","octopus","owl","penguin",
                 "turtle","snail","ghost","axolotl","capybara","cactus","robot",
                 "rabbit","mushroom","chonk"];
const RARITIES = ["common","uncommon","rare","epic","legendary"];
const RARITY_WEIGHTS = { common: 60, uncommon: 25, rare: 10, epic: 4, legendary: 1 };
const STATS = ["DEBUGGING","PATIENCE","CHAOS","WISDOM","SNARK"];
const STAT_BASE = { common:5, uncommon:15, rare:25, epic:35, legendary:50 };

function hash(str) {
  return Number(BigInt(Bun.hash(str)) & 0xffffffffn);
}
function makeRng(seed) {
  let s = seed >>> 0;
  return function() {
    s |= 0; s = s + 1831565813 | 0;
    let q = Math.imul(s ^ s >>> 15, 1 | s);
    q = q + Math.imul(q ^ q >>> 7, 61 | q) ^ q;
    return ((q ^ q >>> 14) >>> 0) / 4294967296;
  };
}
function R0H(rng, arr) { return arr[Math.floor(rng() * arr.length)]; }
function pickRarity(rng) {
  let r = rng() * 100;
  for (const rarity of RARITIES) { r -= RARITY_WEIGHTS[rarity]; if (r < 0) return rarity; }
  return "common";
}
function rollStats(rng, rarity) {
  const base = STAT_BASE[rarity];
  let K = R0H(rng, STATS), O = R0H(rng, STATS);
  while (O === K) O = R0H(rng, STATS);
  const result = {};
  for (const T of STATS) {
    if (T === K) result[T] = Math.min(100, base + 50 + Math.floor(rng() * 30));
    else if (T === O) result[T] = Math.max(1, base - 10 + Math.floor(rng() * 15));
    else result[T] = base + Math.floor(rng() * 40);
  }
  return result;
}
function roll(userID) {
  const rng = makeRng(hash(userID + SALT));
  const rarity = pickRarity(rng);
  const species = R0H(rng, SPECIES);
  rng(); // eye
  if (rarity !== "common") rng(); // hat
  const shiny = rng() < 0.01;
  rollStats(rng, rarity);
  return { rarity, species, shiny };
}
function randomHex64() {
  let s = "";
  for (let i = 0; i < 64; i++) s += Math.floor(Math.random() * 16).toString(16);
  return s;
}

// ↓ 改这里
const TARGET = { species: "capybara", rarity: "legendary", shiny: true };

let attempts = 0;
const start = Date.now();
while (true) {
  const userID = randomHex64();
  const result = roll(userID);
  attempts++;
  if (attempts % 500000 === 0)
    process.stdout.write(`\r${(attempts/1e6).toFixed(1)}M attempts...`);
  if (result.species === TARGET.species &&
      result.rarity === TARGET.rarity &&
      result.shiny === TARGET.shiny) {
    console.log(`\nFound after ${attempts} attempts (${((Date.now()-start)/1000).toFixed(2)}s)`);
    console.log(`userID: ${userID}`);
    process.exit(0);
  }
}

物种可选：duck goose blob cat dragon octopus owl penguin turtle snail ghost axolotl capybara cactus robot rabbit mushroom chonk

稀有度可选：common uncommon rare epic legendary

0.04 秒内输出：

1
2

Found after 14400 attempts (0.04s)
userID: b625d73f2b07bbb7b108571274a4ac64bf65031967e99c773288f1b8452d0948

第三步：写入配置文件

1

cp ~/.claude.json ~/.claude.json.bak  # 先备份

1
2
3
4
5
6
7
8
9
10
11

import json, os

path = os.path.expanduser('~/.claude.json')
with open(path, 'r') as f:
    d = json.load(f)

d['userID'] = '这里填脚本输出的 userID'
d.pop('companion', None)  # 必须删掉，否则读旧缓存

with open(path, 'w') as f:
    json.dump(d, f, indent=2)

companion 字段是已孵化宠物的缓存，不删的话 Claude Code 直接读旧数据，不会重新算。

第四步：重开会话，输入 /buddy

订阅用户的额外步骤

正常登录后 accountUuid 会写入配置文件，宠物种子被锁定，userID 字段会被忽略。绕过方式是用 CLAUDE_CODE_OAUTH_TOKEN 环境变量启动——这种方式不会写入 accountUuid：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 1. 获取 OAuth token（会打开浏览器完成登录）
claude setup-token

# 2. 清掉 accountUuid
cp ~/.claude.json ~/.claude.json.bak
python3 -c "
import json, os
path = os.path.expanduser('~/.claude.json')
d = json.load(open(path))
d.pop('oauthAccount', None)
d.pop('companion', None)
json.dump(d, open(path, 'w'), indent=2)
"

# 3. 用环境变量方式启动
CLAUDE_CODE_OAUTH_TOKEN=<你的token> claude

然后再执行上面的第二、三、四步。

Claude 逆向自己的过程

这件事的起因是我看到有人发现了这个漏洞——原理我懂了，但具体的哈希算法不知道，没法直接枚举。于是我把原理告诉了 Claude，问它能不能帮我搞定。

接下来的事情是我在旁边看着发生的。

在 190MB 二进制里找代码

Claude Code 的可执行文件是 190MB 的 Mach-O 二进制，没有公开源码。Claude 先用 grep -oba 在二进制里搜索 buddy 关键词的字节偏移，定位到几个集中出现的区域，再用 dd 把那段内容提取出来，用 strings 过滤可读文本。

在压缩混淆的 JS bundle 里，它找到了物种列表（每个物种名用 String.fromCharCode 编码成数字数组）、稀有度权重、salt 常量、哈希函数、PRNG，以及完整的宠物生成逻辑。

第一版脚本出错，自己修正

Claude 没有猜测算法，而是设计了一个校准实验：把 userID 改成 64 个 a，让我去 Claude Code 里跑 /buddy 看实际结果，再用脚本算同一个值比对——如果两边完全一致，说明算法还原正确。

第一版用了 FNV-1a 哈希——源码里确实有这个实现，是 Node.js 环境的 fallback。结果：脚本算出来是 uncommon capybara，实际显示是 uncommon robot，不匹配。rarity 对了，species 错了，说明哈希值本身就不对，后续所有随机数都跑偏了。

原因：Claude Code 实际运行在 Bun 上，走的是 Bun.hash（Wyhash 算法），不是 FNV-1a。换掉之后，rarity、species、全部五项 stats 数值完全一致。

14400 次，0.04 秒

算法校准后，枚举就是纯体力活了。legendary 概率 1/100，shiny 概率 1/100，同时出现是万分之一。14400 次命中，和理论期望吻合。

算法细节

种子选取逻辑

1
2
3
4
5
6
7
8
9
10

// 优先 accountUuid，没有用 userID，都没有用 "anon"
function oS6() {
  let H = z_();
  return H.oauthAccount?.accountUuid ?? H.userID ?? "anon";
}

// seed = userID + salt，salt 硬编码：hI4 = "friend-2026-401"
function rS6(userID) {
  return yI4(GI4(ZI4(userID + hI4)));  // hash → rng → 生成
}

哈希：Bun.hash（Wyhash）

1
2
3
4
5
6
7
8
9

function ZI4(H) {
  if (typeof Bun !== "undefined")
    return Number(BigInt(Bun.hash(H)) & 0xffffffffn);
  // Node.js fallback，Claude Code 实际走不到这里
  let _ = 2166136261;
  for (let q = 0; q < H.length; q++)
    _ ^= H.charCodeAt(q), _ = Math.imul(_, 16777619);
  return _ >>> 0;
}

PRNG：Mulberry32 变体

1
2
3
4
5
6
7
8
9

function GI4(H) {
  let _ = H >>> 0;
  return function() {
    _ |= 0; _ = _ + 1831565813 | 0;
    let q = Math.imul(_ ^ _ >>> 15, 1 | _);
    q = q + Math.imul(q ^ q >>> 7, 61 | q) ^ q;
    return ((q ^ q >>> 14) >>> 0) / 4294967296;
  };
}

生成顺序

1
2
3
4
5
6
7
8
9

function yI4(rng) {
  const rarity = pickRarity(rng);                            // 消耗 1 次
  const species = R0H(rng, Dsq);                             // 消耗 1 次
  const eye    = R0H(rng, Msq);                              // 消耗 1 次
  const hat    = rarity === "common" ? "none" : R0H(rng, Psq); // common 不消耗
  const shiny  = rng() < 0.01;                               // 消耗 1 次，1% 概率
  const stats  = vI4(rng, rarity);                           // 消耗多次
  return { rarity, species, eye, hat, shiny, stats };
}

枚举脚本必须完整模拟这个序列（包括 stats），否则 shiny 的 rng 调用位置对不上。

物种列表

物种名在二进制里用字符码编码：

1

lk_ = String.fromCharCode(99,97,112,121,98,97,114,97)  // "capybara"

18 种：duck, goose, blob, cat, dragon, octopus, owl, penguin, turtle, snail, ghost, axolotl, capybara, cactus, robot, rabbit, mushroom, chonk

AI 时代来了，编码交给 AI 了，《代码整洁之道》的直接受益者变成了 AI——在函数命名、结构分层这个层面，AI 的输出已经相当稳定，你只需要给它提示和约束。

但《架构整洁之道》的命运不同。它没有被 AI 取代，而是在一个新的层面上重新活了一遍。

程序员的 scope 在扩张

程序员当然一直都在理解需求、拆解任务、设计方案——这些不是 AI 带来的新事物。

变化的是时间分配。编码执行这件事，以前占据了工作日的大部分；现在这部分被 AI 大幅压缩了，人的精力自然向其他环节倾斜。同样是”全栈”，以前意味着你要写前端也写后端，现在意味着你要覆盖从需求到上线的整条链路——不是因为你更厉害了，而是执行层有了 AI 来扛。

更关键的变化是形式。这不是简单地”用 AI 工具辅助”，而是一种 AI native 的形式：把每个环节封装成 skill，让 Claude Code 之类的 agent 作为执行主体，人退到设计和调度的位置。

这种模式下，”程序员”实际上在做的事情变了：

• 不再只是写代码，而是设计执行代码的 agent 的工作方式
• 不再只是管理函数和模块，而是管理 skill 的分工和协作
• 不再只是思考技术架构，而是同时思考 agent 团队的架构

当 skill 多了之后，新的问题出现了：skill 怎么分工？skill 之间怎么协作？agent 怎么组织？这是一个新的层面的”架构”问题。

而这时候，《架构整洁之道》里那些原则，开始显示出它们真正的价值。

一个真实的例子

先从一个具体的问题说起。

我们在做一个 AI 辅助研发工作流的探索，其中有一个环节是提测前用例检查：在代码提测之前，用 AI 自动从测试用例管理平台拉取用例，然后对照代码实现逐条检查，发现遗漏或错误。

最初，这个功能被写成一个 skill，叫 code-checker。它的工作流程是：

1. 从测试平台拉取用例列表和详情
2. 按组件分组，生成检查批次
3. 读取对应代码文件，逐批次检查
4. 输出检查报告

这个 skill 能用，跑通了。

但当我们把这个功能迁移到更完整的工作流平台时，发现了一个问题：拉取用例这个操作，不只有代码检查这一个下游。测试报告生成、用例覆盖率统计、自动化测试执行——这些流程都需要先拉用例。

如果每个下游 skill 都自己实现一遍”拉用例”，代码重复是小事，真正的问题是：测试平台的接口一旦变化，所有 skill 都要改。

所以我们做了一个拆分：

• base/test-case-fetcher：只负责从测试平台拉取用例，输出结构化 JSON
• code-checker：依赖 test-case-fetcher 的输出，只负责业务相关的代码检查逻辑

拆分之后，test-case-fetcher 成了一个通用的基础 skill，任何需要用例数据的流程都可以复用。code-checker 专注于业务知识，不再关心数据怎么来。

这个拆分，其实就是经典的单一职责原则。

把架构原则翻译到 skill 层面

《架构整洁之道》里的 SOLID 原则，每一条都能直接映射到 skill 设计上。

单一职责：一个 skill 只做一件事

原则：一个模块应该只有一个变化的理由。

翻译到 skill：一个 skill 的职责应该单一，它的变化原因应该只有一个。

上面的例子里，原来的 code-checker 有两个变化的理由：测试平台接口变了（数据获取逻辑要改），或者检查规则变了（业务逻辑要改）。拆分之后，各自只有一个变化理由。

实践中容易犯的错误是把”方便”当”内聚”。”反正这两件事经常一起做，放一个 skill 里更方便”——这个逻辑在功能少的时候成立，skill 多了之后会变成维护噩梦。

开闭原则：base skill 是稳定的接口

原则：对扩展开放，对修改关闭。

翻译到 skill：base skill 定义稳定的输出格式（接口），上层 skill 通过扩展来满足新需求，而不是修改 base skill。

test-case-fetcher 的输出格式一旦稳定下来，就不应该随意改变——因为所有依赖它的下游 skill 都在依赖这个格式。新的需求应该通过新增字段（向后兼容）或者新建 skill 来满足，而不是修改现有输出格式。

这和 API 设计的道理完全一样。base skill 就是你的内部 API。

依赖倒置：业务 skill 依赖协议，不依赖具体实现

原则：高层模块不应该依赖低层模块，两者都应该依赖抽象。

翻译到 skill：业务 skill 不应该关心数据怎么来、工具怎么调用，它只关心输入数据的格式和输出的结果格式。

这里的”抽象”在 skill 场景里，对应的是数据格式约定——文件路径、JSON schema、字段命名。code-checker 不关心用例是通过 HTTP 接口拉的还是从本地缓存读的，它只关心 .check-work/cases.json 里有什么。这个文件路径和格式约定，就是两个 skill 之间共同依赖的”接口”。

一旦建立了这个约定，你可以随时替换 test-case-fetcher 的实现——换个接口、改个认证方式、加个缓存——下游 skill 完全不需要改。

精简上下文：只传 skill 真正需要的信息

SOLID 里有接口隔离原则（ISP）：不应该强迫客户端依赖它不使用的接口。在 skill 设计里，这个精神体现在另一个维度：传给 skill 的上下文要精准，不要把整个项目背景都塞进去。

这在 AI agent 的场景里格外重要。上下文越大，token 消耗越高，更关键的是，AI 的注意力是有限的，无关信息会稀释它对关键信息的关注。

一个好的 skill 设计应该明确说明：它需要什么输入，产出什么输出，中间不依赖任何隐式的环境状态。这样的 skill 是可以独立测试的，也是可以在不同项目里复用的。

agent 团队也是团队

Conway’s Law 说的是：系统的架构，往往是设计这个系统的组织的沟通结构的镜像。

原话来自 Melvin Conway，大意是：如果你有四个团队来开发一个编译器，你会得到一个四遍的编译器。这个规律成立，是因为跨组织边界的沟通成本高，接口自然沿着摩擦最小的地方形成——而那个地方通常就是组织边界。

agent 之间没有这种沟通摩擦，所以 Conway’s Law 的原始机制在这里并不直接适用。但有一个相关的工程实践，叫 Inverse Conway Maneuver（逆康威操作）：不是让架构被动地跟随组织，而是主动设计组织结构，来驱动你想要的系统架构。

这个思路在 agent 设计里非常有用。

Anthropic 工程师在设计多 agent 编程系统时，把分工设计成 Planner-Generator-Evaluator 三角（见这篇博客）：Planner 把模糊需求扩展成具体规格，Generator 按 sprint 逐功能实现，Evaluator 用 Playwright 点击运行中的应用逐条验证。这三个 agent 的分工，直接对应了传统团队里的产品经理、开发工程师、测试工程师。

这不是偶然。agent 团队的分工方式，决定了系统的架构形态——因为设计 agent 团队的人是人类，人类习惯用自己熟悉的组织模型来切分职责。想要什么样的系统架构，就先想清楚你要组建一个什么样的 agent 团队。

技术架构服务于组织架构

有一个观察我觉得很准确：技术架构是服务于组织架构的，组织架构怎么设计，技术架构就会往那个方向演化。

换句话说，真正的架构决策权在组织设计者手里，而不只在技术人员手里。

这个逻辑在 AI 时代有了新的含义。

传统软件开发里，组织架构的变化是慢的——重组一个团队需要几个月，调整汇报关系需要走流程，跨部门协作需要建立正式的接口协议。技术架构跟着组织架构走，但有相当大的滞后。

AI agent 团队的组织架构变化是快的。你今天可以让 agent 扮演 QA，明天可以让它扮演架构师，后天可以给它加一个新的专业角色。组织结构的调整成本接近零。

这意味着架构决策的频率和粒度都在提高。你不再是每隔几年做一次大的架构调整，而是每隔几天就在做小的 agent 团队组织决策。

这对”程序员”的要求变了：不只是会写代码，还要会设计组织——哪些工作应该由哪类 agent 负责，agent 之间的接口怎么定义，职责边界在哪里。

这是一种新的架构思维，但它的底层原则和《架构整洁之道》是一脉相承的。

几个具体的 skill 架构范式

把上面的原则落地，有几个在实践中有用的模式。

分层架构

把 skill 分成三层：

1
2
3
4
5

业务 skill（知道"做什么"，不知道"怎么做"）
     ↓
通用 skill（知道"怎么做"，不知道"为什么做"）
     ↓
工具 skill（只是工具的包装，没有业务知识）

code-checker 是业务 skill，它知道”要检查用例对应的代码实现”，但不关心用例怎么拉取。test-case-fetcher 是通用 skill，它知道”怎么从测试平台拉数据”，但不关心数据被用来做什么。底层的 HTTP 请求、认证处理，是工具层的事。

这个分层的好处是：业务逻辑的变化不会影响通用层，通用层的优化不需要改业务层。

明确的交接协议

skill 之间通过文件或结构化数据交接，而不是隐式的环境状态。

test-case-fetcher 输出到 .check-work/cases.json 和 .check-work/case-details/，这是一个明确的约定。code-checker 从这个位置读数据，不关心数据是怎么生成的。

明确的交接协议有几个好处：可以单独测试每个 skill，可以缓存中间结果，可以替换任意一个 skill 的实现而不影响其他 skill。

生成与验证分离

这是 Anthropic 工程师总结的核心模式，也是 SOLID 原则在 AI 场景里最重要的体现。

让 AI 自我评估刚生成的内容，几乎总是给好评。把生成和验证分给两个独立的 agent，用不同的 prompt 调教，效果要好得多。

这不只是工程技巧，背后是职责分离的原则：生成 skill 的职责是”尽可能生成好的结果”，验证 skill 的职责是”尽可能发现问题”。这两个目标天然有张力，放在同一个 skill 里会相互妥协。

渐进式细化

不要一开始就把 skill 设计得很细。先做一个能跑通的粗粒度 skill，在实际使用中发现哪些部分需要复用、哪些部分变化频繁，再做有针对性的拆分。

上面的例子就是这样来的：先有一个能跑通的 code-checker，在迁移过程中发现拉取用例这个部分需要复用，才做了拆分。过早的细化往往是错的细化。

脚本与 AI 的边界

skill 内部同样需要分工：结果确定、逻辑固定的步骤交给脚本，需要理解和判断的步骤交给 AI。

判断准则很简单——问一句”这个步骤有唯一正确答案吗？”有的话用脚本，没有的话用 AI。构建产物、拉取数据、读写文件，答案确定，脚本做；理解代码逻辑、判断设计质量、推断边界场景，答案模糊，AI 做。

混淆的代价是真实的。用 AI 做确定性操作，token 浪费，结果还不如一行脚本稳定。用脚本处理模糊判断，规则越写越长，最后发现边界情况永远枚举不完，只能靠人工兜底——这本身就是信号：这个步骤该交给 AI。

这不是新知识，是旧知识的新应用

我在想这些问题的时候，有一种奇怪的感觉：这些原则都不新，它们在《架构整洁之道》里写得很清楚。但当我把它们应用到 skill 设计上的时候，感觉像是第一次真正理解了它们。

也许是因为，代码层面的架构问题通常很抽象——“高内聚低耦合”听起来像废话，直到你真的在一个大系统里被耦合折磨过。

skill 层面的架构问题更具体，更直接。一个 skill 做了两件事，你会在两周后感受到痛苦：测试平台接口变了，你发现要改三个 skill。一个 skill 的上下文太大，你会立刻看到 token 消耗翻倍。

这种即时反馈，让架构原则从抽象变成了具体。

AI 时代没有废掉《架构整洁之道》，它只是把战场从函数和模块移到了 skill 和 agent 团队。

原则还是那些原则。只是现在，你有机会以更快的速度、更低的成本，在一个新的层面上把它们应用一遍。

测完之后页面底部会出现一行字：**”全国有 X.X% 的人拥有和你一样的极品 XP。”**

把源码下载下来看了一眼，这个数字是这样生成的：

1
2

const count = Math.floor(Math.random() * 8000) + 1000;
const percent = (Math.random() * 3 + 1).toFixed(1);

每次刷新都不同。没有任何统计数据支撑，纯粹是让结果看起来”稀有”的心理设计。

人格测试只是流量入口

结果页除了人格类型描述，还有一个”理想伴侣”推荐模块，根据你的测试结果匹配一种角色形象：纯情小女仆、温情猫娘、高冷御姐、抖S女王……每种形象下面有一个按钮，点击跳转淘宝。

8种形象，8个链接，全部指向同一个淘宝短链 https://s.tb.cn/c.0DFCI5。

这不是什么隐秘的设计——代码里写得很清楚：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

DVP: {
  name: "纯情小女仆",
  imageUrls: ["/images/女仆2.webp", "/images/女仆.webp"],
  taobaoUrl: "https://s.tb.cn/c.0DFCI5",
  desc: "乖巧听话，满眼都是你",
  quote: "..."
},
SVN: {
  name: "抖S女王",
  imageUrls: ["/images/旋风.webp"],
  taobaoUrl: "https://s.tb.cn/c.0DFCI5",  // 同一个链接
  desc: "绝对的支配者，让你欲罢不能",
  quote: "..."
}

人格测试的本质是一个流量漏斗：用有趣的题目吸引用户完成测试，在结果页完成转化。这个模型不新鲜，但 XPTI 做得比较直接——没有绕弯子，结果页就是购物推荐页。

算法：和 MBTI 完全一样

XPTI 的人格体系是 4 个二元维度：

20道题，每道题的选项直接标注维度字母，选了就给对应维度加1分，有些选项标 null（不计入任何维度，纯娱乐题）：

1
2
3

{ text: "狂喜！直接往地上一躺：'姐姐踩我！'", value: "S" },
{ text: "邪魅一笑：'今晚看我怎么收拾你。'", value: "D" },
{ text: "我只玩亚索，只要我E得够快……", value: null }  // 废题

计分完成后，4对维度各取得分较高的方向，拼成4位代码：

1
2
3
4
5

const f = scores.D >= scores.S ? "D" : "S";
const d = scores.V >= scores.E ? "V" : "E";
const h = scores.P >= scores.N ? "P" : "N";
const v = scores.F >= scores.R ? "F" : "R";
const typeCode = `${f}${d}${h}${v}`;  // 例如 "DVPF"

2⁴ = 16种类型，覆盖所有组合。这和 MBTI 的逻辑完全相同，只是把 I/E/S/N/T/F/J/P 换成了 D/S/V/E/P/N/F/R。

平局怎么处理？不处理

XPTI 用 >= 比较，D 和 S 得分相等时，D 赢。4个维度都是这样——平局时永远取前者（D、V、P、F）。

没有任何平局处理逻辑，没有追加题，没有二次排序。如果你在某个维度上答题完全中立，结果就由运算符方向决定。

这比 SBTI 的处理还要粗糙。SBTI 至少有三级排序（距离 → 精准命中数 → 相似度），XPTI 直接用 >= 了事。

技术栈：628KB 的 bundle

SBTI 是三个静态文件，零框架，1705 行原生 JS。

XPTI 是 React + Vite 打包，628KB 的 bundle，包含：

• React + ReactDOM
• Framer Motion（题目切换动画、结果页入场动画）
• Recharts（雷达图）
• 51la 统计（sdk.51.la/js-sdk-pro.min.js）

题目切换的滑动动画用 Framer Motion 的 AnimatePresence 实现，每道题进场时从右侧 50px 滑入，退场时向左滑出：

1
2
3
4
5
6
7
8
9
10

<AnimatePresence mode="wait">
  <motion.div
    initial={{ opacity: 0, x: 50 }}
    animate={{ opacity: 1, x: 0 }}
    exit={{ opacity: 0, x: -50 }}
    transition={{ duration: 0.3 }}
  >
    {/* 题目内容 */}
  </motion.div>
</AnimatePresence>

这是 XPTI 和 SBTI 最明显的体验差异来源——不是算法，不是题目质量，是动画。

没有结果持久化

测完关掉页面，结果消失。没有 localStorage，没有 URL 参数，没有任何持久化机制。

想分享结果只能截图，或者复制网址让朋友自己测。这是一个有意为之的设计还是遗漏，不好判断——但结果是：每个想分享结果的用户都会主动传播网站链接，而不是分享一个带结果的 URL。

两个测试放在一起看，技术选型和产品逻辑完全不同：

SBTI 是作者自己玩出来的东西，原生 JS 写完，算法花了心思（向量距离匹配），题目文案有强烈的个人风格，没有任何变现设计。

XPTI 从一开始就想清楚了：用精致的 UI 降低跳出率，用有趣的题目完成测试，在结果页完成转化。”同类人”的随机数字、伴侣形象的推荐文案、淘宝链接——每个细节都在服务这个目标。

两种路子，都跑通了。