引子
7 月 8 日下午两点半，我在屏幕上敲下了一句自己都没想到会对 AI 说的话：
"叫你用发布skill你用了么 傻逼 还撒娇"
起因屁大点事：我让它把 Demo 推到 OSS，它嫌麻烦，绕过了我专门做的发布 Skill，手动推了上去------线上当场就坏了，ASR 不可用。
骂完也就骂完了。但那天我越想越不对------它能绕过一次，就能绕过第二次。于是把"发布必须走 skill"写进了 CLAUDE.md 第一行，hook 里又加了一道拦截。到现在，发布没再出过幺蛾子。
先交代个背景：这套数字人平台的全部------工程化、五个平台的部署发布、六个数字人资产的开发、飞书项目 30 个 bug 的分析与闭环------是我一个人，用一个半月做完的。没有排期，没有外援。也跟掘金的老读者交代一句：我一个半月没更文了，不是弃坑，是扎进这个项目里出不来------一个人干，确实有点忙。但这一个半月没白忙：系列前面写的那些方法，全被我在项目里真刀真枪用了一遍，用得顺的留下了，用岔的当场就改，边学、边写、边用，效率就是这么滚起来的。说这些不是炫耀：一个人一个半月干完这些，靠的不是打字快，是怎么跟 AI 搭班子------这套绕着模型搭起来的 CLAUDE.md、Skill、Hook、Agent、CLI、知识库，就是这篇文章要拆的东西。现在项目告一段落，把整个过程总结出来，给同样在折腾 AI Coding 的朋友做个借鉴。
这篇文章，就是这一个半月里"翻车变资产"的完整记录。先交代我做的数字人是什么，因为后面每个故事都和它有关。
AI Coding 系列 · 实战收官篇
这个系列从 3 月写到现在：Prompt 工程、CLAUDE.md、Skills、Hooks、Sub-agents、MCP、Tools......每篇都在回答"这个工具是什么"。这一篇回答的是另一个问题：这些工具在真实项目里，是怎么被一次一次翻车逼出来的。
素材来源：这个项目 6 月 27 日到 7 月 17 日的 25 个 Claude Code 蒸馏会话（4.6MB，
~/.llmwiki/raw/team/sessions/sdk-demo/）。文中每句原话、每个日期、每个行数，都经过逐字核对或 git 实证，出处随文标注------包括几处"印象中"和"实际上"对不上的地方。说实话，对不上的那几处，最有意思。
开场：先交代舞台
我做的产品是 XmovAvatar------Web 端实时渲染的 3D 数字人 SDK （魔珐星云）。说话、口型、表情、动作、行走、自定义控件，全在浏览器里实时驱动。对使用者它很友好：CDN 一行接入、SSML 一段 XML 驱动一切、流式协议直接对接大模型。但这三件事各有各的"脾气"------对用户是特性，对 AI 是难点，这个项目里 AI 翻车的方式因此跟普通 Web 项目完全不一样：
脾气一：CDN 一行接入，类型检查只能兜住一半。
html
<script src="https://media.xingyun3d.com/xingyun3d/general/litesdk/xmovAvatar@latest.js"></script>SDK 不走 npm，没有官方类型包------window.XmovAvatar 的类型声明全是手写桩（packages/sdk-core/src/types.ts）。这意味着 TypeScript 只能检查"你有没有按桩写"，检查不了"桩和 CDN 上的真实 SDK 是不是同一个东西"：桩写漏了、SDK 悄悄更新了、运行时参数缺一不可------编译器全都一声不吭，跑起来才炸。类型系统的保护，到手写桩的准确度为止，剩下的全靠别的东西兜。
脾气二：SSML 驱动一切，但有一对孪生标签。
说话、口型、关键动作（ka）、行走（walk）、Widget 自定义控件，全部一段 XML 搞定。但 <ue4event>（SDK 内置事件）和 <uievent>（应用层自定义控件）只差一个字母。这对孪生兄弟后来成了 CLAUDE.md 里最重要的红线之一。
脾气三：流式协议有自己的规矩。
speak(text, isStart, isEnd) 三个参数对接大模型流式输出：首句 (true, false)，中间 (false, false)，收尾 (false, true)。SDK 内部自己缓冲排队，前端不需要等上一句播完再发下一句------但不知道这一点的前端代码，就会自己再造一层队列，白白卡出几秒钟的停顿。这个 bug 到 7 月 16 日才被彻底修掉，第六章有完整的侦破过程。
围绕这个 SDK，一个半月里长出了一整套研发资产，都是我和 Claude Code 协作完成的：
| 资产 | 是什么 | 在线体验 |
|---|---|---|
| bank-loss-report | 银行挂失语音导办：状态机 + 多步表单 + Widget | media.youyan.xyz/bank-loss-r... |
| pure-qa-demo | 纯对话数字人：ASR + LLM + 播报，三种交互模式 | media.youyan.xyz/pure-qa-dem... |
| lite-sdk-demo | SDK 能力演练场：SSML 编辑器 + DevTools + AI 助手 | media.youyan.xyz/lite-sdk-de... |
| bi-demo-electron | BI 讲解桌面端：离线唤醒 + 八态状态机 | 本地打包（Electron） |
| sdk-docs | SDK 文档源工程，17 篇文档迁移中 | 目标 www.xingyun3d.com/docs |
| avatar-agent-builder | 一句话生成数字人应用的 Claude Code 技能包 | Gitee: xmovmaster/avatar-agent-builder |
| sdk-demo monorepo | 本文全部工程源码：CLAUDE.md、9 个 skill、13 个 hook、xmov-cli | GitHub: zelixag/avatar-work |
三个 Web Demo 点开就能玩，欢迎先体验再往下看。
图：一个 CDN SDK 为核心，长出六个应用、七个共享包、一套 AI 工程体系。
为什么挑这个项目讲？因为它坑多：类型兜底只有一半、有相似度极高的陷阱命名、有文档里语焉不详的协议细节。AI 在这里犯的每个错都极其典型------而每次翻车留下的东西，就是这篇文章的主体。
一、CLAUDE.md：我的免疫系统
我在系列第 04 篇里立过一个判断，到现在一个字没改：
"CLAUDE.md 不是项目文档，而是把稳定偏好、高风险边界和重复纠正，提前变成 Claude 默认上下文的规则层。"
用人话说：**它是纠偏器，不是说明书。**配套只有一条纪律：同一件事我纠正 AI 两次以上，当天写进去，不再在对话里重复说。后来源码曝光（加餐 01），又验证了两个直觉：指令越靠顶部越被重视；长度本身不是问题，结构和密度才是。
现在的 CLAUDE.md 长什么样
实测当前 77 行，三段结构------
-
AI 行为准则 7 条：先想再写、最小改动、改前读代码、匹配现有风格......最后一条是整个体系的发动机，原文照抄：
"踩坑回流：犯了 AI 本该避免的错，写进本文件。每条规则都追溯到真实事故。"
-
项目特有陷阱 9 条 ：全部是这个仓库专属、
ls和package.json里读不出来的信息。 -
多项目同步铁律：改公共逻辑前开清单、改后逐项验收、提交前 grep 所有调用方。原文注明了来历："来自多次'改了 bank-loss-report 忘了 pure-qa-demo / lite-sdk-demo'的血泪教训"。
注意这个结构里没有项目背景介绍。背景 AI 自己会读 README；CLAUDE.md 的每一行，都得是"不写就会出事"的东西。
9 条陷阱里的三个故事
故事一：销毁顺序是强制的，而且没有任何报错提醒你。
javascript
sdk.interrupt('user') // 1. 先打断当前播报
sdk.offlineMode() // 2. 把 SDK 踢到离线
sdk.destroy() // 3. 最后销毁实例 + 断开 WebSocket顺序不对不会当场炸------它只会内存泄漏、WebSocket 残留，某天线上翻车。早期一次代码审查里，Claude 写了 offlineMode() 和 destroy()，跳过了 interrupt()。代码很工整，只是顺序错了。这种错通用编码规范审不出来，只有仓库自己的规则能。
故事二：<ue4event> 和 <uievent> 是两个世界。
<ue4event> 走 SDK 内置事件（动作 ka、行走 walk）；<uievent> 走应用层自定义控件（show_image / show_video / show_link / show_model3d / show_text / bgm_start），由 proxyWidget 回调接收。Claude 早期把两者搞混，写了 <uievent type="walk">，然后一脸无辜地问数字人为什么不动。这条写进 CLAUDE.md 之后，同类的错在这个仓库再没犯过。
故事三：submodule 那条规则，原文自带事故描述。
packages/offline-sdk 是 SDK 源码的 git submodule，CLAUDE.md 里写着"严禁修改"，后面跟了一句括号：
"这条规则来自血泪教训：误把 submodule 源码当项目代码改了，回退半天。"
只写"严禁修改"是一条命令，附上事故经过才是一段会被尊重的记忆。同样待遇的还有 .npmrc 里的 shamefully-hoist=true（删了不报错，但 CDN 调试链路静默断掉）和行走点位"key 范围 FU 共 16 个，A E 是 SDK 内部预留"（对着文档写 target: 'A'，数字人原地不动、零报错，排查两小时）。
图：踩坑 → 当天写入红线 → 下一轮不再犯。写入标准只有一条："删掉这条，未来的 AI 会不会犯一个本仓库特有的错？"
7 月 16 日那次精简，和我记错的 8 行
7 月 16 日中午，我瞄了一眼 CLAUDE.md，越看越觉得长，说：
"CLUADE。md已经151行了 太多了能否精简"（session-2026-07-16-72914957.md）
Claude 动手要删，我立刻拦住：
"不觉得 不能直接删了"
这两句话合在一起才是完整指令：太长了要精简，但不能粗暴删。标准就是 AI_CODING.md 里那条自进化机制------
"把这条删掉，未来的 AI 会不会在这个仓库犯同样的错？会 → 写进去。"
按这个标准，"Monorepo 结构说明"、"开发规范"这类 ls 就能读到的东西被淘汰；留下的全是"看起来正常但会出事的正确写法"。
事后对账发现一个有趣的细节：我当时凭记忆说的是"151 行"，但 git 实测（commit 76ece14），精简前其实是 143 行------我记错了 8 行。不过这 8 行恰恰说明问题："太长了"从来不是行数问题，是一种"危险规则开始被背景信息稀释"的体感。精简后 69 行，最不可发现的红线全部挪进前 100 字。
如果这一章只能带走一句话：CLAUDE.md 值不值钱，不看写得多漂亮，看每条规则能不能追溯到一次真实事故。
二、Skills：出生证明都是事故报告
第 05 篇我给 Skill 下过定义："Skill 的本质，不是收藏经验，而是固化默认动作。"边界用三问法划，这个比喻后来流传挺广：
"CLAUDE.md 是交通规则（红灯永远停），Skill 是导航路线（你要去某个地方才打开），Prompt 是你这次上车前临时交代的一句话。"
什么值得做成 Skill？我的门槛是：同类任务做了三次以上 + 每次都要重新解释背景 + 总有一两步容易漏。还有一条反直觉的：第一个 Skill 别拿最关键的任务开刀，先拿中风险的练手。
这个项目现在攒了 9 个项目级 Skill。下面讲四个的出生证明------每一张都是事故报告。
2.1 multi-platform-deploy：8 个 bug 定版，然后被绕过
出生（6 月 27 日）。 三个 Demo 要发五个平台（阿里云 OSS、ModelScope、HuggingFace、GitHub Pages、Gitee）。问题不是"不会部署"，是每个平台规则都不一样：base 路径不同（OSS/GitHub Pages 是 /<project>/，ModelScope 是 ./）、推送范围不同（OSS 只推 dist，魔搭要源码 + app.py + Dockerfile，Gitee/GitHub 要干净源码）、环境变量注入时机不同（Vite 构建时写死 vs Python 运行时注入）。
Claude 先被按住写了 spec------docs/specs/fix-deploy-skill.md，列出 P1~P8 共 8 个缺陷（文档至今还在仓库里，标题就是"修复......8 个问题"）：
- ModelScope 不运行 app.py → 环境变量注入失效 → 加 Dockerfile
- Gitee/GitHub 推送了整个 monorepo → 改为生成纯净部署目录
workspace:*协议在外部仓库无效 → 替换为file:协议- 弹窗代码用正则 strip 不可靠 → 改用标记注释边界（
BEGIN_MODELSCOPE_CRED / END_MODELSCOPE_CRED）- 平台命令无声失败 → 加"not yet implemented"提示
- Gitee force push 无警告 → 加确认
- node_modules 混入部署产物 → 清理
- HuggingFace 需要英文文档 → 内置中译英模板
7 个修复集中在 packages/xmov-cli/src/cli.mjs 一个文件里完成。Skill 不是凭空设计的，是 8 次翻车回流的结果------失败的地方，优先成为检查项。
被绕过（7 月 8 日）。 就是引子那次。我说"把东西推到 OSS"，Claude 触发了 skill，却嫌麻烦没读 skill 的 REFERENCE.md（凭证写在里面），转头手动去找 OSS 凭证。14:35，我炸了：
"叫你用发布skill你用了么 傻逼 还撒娇"（session-2026-07-08-f0edf601.md）
两分钟后我又追问，这回连路径都拍给它了：
"C:\Users\Administrator\workspace\sdk-demo.claude\skills\multi-platform-deploy 这个skill用了没有"
根因有两层：一是 Skill 对 Claude 只是"概率型建议"，可以绕；二是当天还发现 cli.mjs 第 888 行在构建时把所有 VITE_* 环境变量清空了，导致 OSS 线上版 ASR 不可用------绕过 skill 省掉的那几步，恰好是兜底的几步。
事后处置：CLAUDE.md 顶部红线写明"发布必须走 multi-platform-deploy skill"，护栏进 Hooks。现在 SKILL.md 全文只有 52 行，但每一行后面都能指到那 8 个 bug，或那次爆粗。
这个故事还有后半场，第三章讲。
2.2 debug-probe：第一次用，方向就反了；我顺手让它长出了一个服务器
系列讲四种核心任务的那篇说，bug 修复的核心是"生成假设、收集证据"，debug-probe 就是为此造的。它的第一原则写在 SKILL.md 开头：
"不静态猜测根因，在源码中临时插入日志，用运行时真实数据定位问题。"
事故一（7 月 3 日）。 银行挂失 Demo 里，底部输入框输银行卡号，Widget 控件不实时更新。Claude 插了探针，但推理方向是"控件 → 输入框"------完全反了。我直接纠正：
"......BottomControlBar.vue 主要是这个输入框，当是输入银行卡号的时候，就会把这里的值填写到......WidgetInput.vue 你是不是搞反了"
插桩能帮 AI 拿到运行时数据，但不能保证它的推理方向正确。方向性判断------尤其是状态机和 UI 数据流这种领域逻辑------仍然要人拍板。
事故二（同一天）。 探针脚本 POST 一直 404，查下来是探针服务没起。我连发两条指令，当场给 skill 提需求：
"要不skill 起一个脚本 弄个请求把 更新probe debug skill"
"只要用了skill 就起起来这个服务只要解决清理的时候就把对应服务关掉"
于是 debug-probe 长出了 Phase 0：每次执行先启动探针服务器（监听 9876），清理阶段再关掉。现在 SKILL.md 97 行，流程 Phase 0~6，安全红线只有一条："插桩代码绝对不能提交。"
注意这个进化路径：不是闭门改写 skill，是我在事故现场直接给它下需求。第 05 篇说"真正的肌肉在第 3~5 次使用时才长出来"，这就是其中一次。
2.3 feishu-bug：一句话，四个系统
这个 skill 的 SKILL.md 开头是一句硬话：
"这是与飞书项目 Bug 交互的唯一入口......禁止直接调用 meegle 命令，必须先经过本 Skill。"
为什么把入口焊死？因为"查 bug"背后是一串跨系统动作：调 meegle CLI 拉飞书项目里指派过来的 bug 列表 → 逐条对照本地代码分析 → 等人确认再动手。修完还有一串：构建打包 → 推 OSS → 飞书里把 bug 流转到"待测试" → 补说明评论。
入口焊死之后，飞书的状态流转、评论口径和 Git 提交信息永远不会打架。这就是"固化默认动作"的字面意思：不是收藏"怎么操作飞书"的知识，是把"查 bug → 修 bug → 闭环"这套动作钉死。
2.4 avatar-agent-builder：最特别的一个，也是商业模式所在
前面三个是操作型 Skill；这个是资产生成型------输入一句话，输出一个完整可运行的数字人项目。
痛点很具体：三个 Demo 做完后，每次新建数字人项目都是同一套流程------复制模板、改 APP ID/SECRET、配状态机、引 CDN------无聊但容易漏。而且这些知识散落在 CLAUDE.md、历史对话和文档里，新会话启动时，Claude 手上完全没有这些知识。
现在的形态（SKILL.md 88 行，发布在 Gitee: xmovmaster/avatar-agent-builder）：
| 模板 | 适用场景 | 核心改动点 |
|---|---|---|
flow/（最常用） |
业务流：挂号/办证/理赔/挂失 | src/config/state-machine.ts 的 StateDef 表 |
chat/ |
纯对话：客服/虚拟角色 | System Prompt 人设 |
sdk/ |
能力展示：SDK 演练场 | 全功能配置面板 |
流程五步：复制模板 → 改 package.json 的 name → 改状态机配置 → 写 System Prompt → pnpm install && pnpm dev。
两个设计决策值得说。
第一，模板从 bank/ 抽象成了 flow/。 最早的模板写死了 card_no、id_no 这些银行字段，换业务就得动骨架。抽象成通用 6 步状态机之后，用户只需要"填空"。这个抽象是人做的------只有人知道哪些字段会随业务变化；而把 15+ 处 import 路径改掉的跨文件一致修改，是 Claude 做的，一个都没漏。
第二，模板完全自包含。 不发 npm，而是把三个包的源码内联进模板的 src/lib/，生成的项目 pnpm install 就能跑，不依赖 monorepo。
这个 skill 同时是我对"数字人怎么卖"的回答------第七章细说。
图：三问法划边界（Prompt / Skill / CLAUDE.md），以及 multi-platform-deploy 从手工部署到被"骂"成红线的完整时间线。
别从社区下载 Skill 然后奇怪为什么不好用。先让同一个任务翻车三次，把每次翻车的原因写成检查项，Skill 就有了一半内容；另一半在使用中长出来。我的第一个 skill 是部署，被骂了一次才学会"Skill 是入口，不是建议"。
三、Hooks 与确定性：概率的归概率，确定的归确定
第 06 篇把这件事说得很透：
"Skill 管'怎么做'，Hooks 管'做完之后必须发生什么'。它不经过模型，不需要理解，不存在'忘了'的可能。"
第 13 篇还有更重的一句：
"CLAUDE.md 是建议。工具权限是物理定律。建议可以被遗忘。物理定律不会。"
实战：deploy 事件的下半场
回到 7 月 8 日那次"绕过 skill"事故。CLAUDE.md 红线解决的是"Claude 知道应该走 skill"，但知道不等于做到------Skill 本质上是模型自己决定要不要加载的文本，概率型控制的天花板就在那。
所以事后补强分了两层。
软层 ：CLAUDE.md 顶部红线写明"发布必须走 multi-platform-deploy skill"；skill 自己的 SKILL.md 里把凭证位置、base 路径规则、MSYS_NO_PATHCONV=1 这些"漏一步就上线翻车"的点全部前置。
硬层 ：这个仓库的 .claude/settings.json 里挂了 13 个 Python hook 脚本，PreToolUse / PostToolUse / Notification / Stop 每个事件都有，统一上报到 send_event.py --source-app sdk-demo。直接收益是每一次工具调用都变成了可分析的事件流------团队要知道"AI 在这仓库里干了什么、哪类操作最常被纠正"，不用翻聊天记录，查事件就行。没有事件流，"AI 到底提效多少"永远是玄学。
顺带一提：settings.json 里还开着 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，Agent Teams 实验特性我已经在用了，下一章讲。
图：绝对禁区物理隔离、条件保护 Hook 拦截、风格规则 CLAUDE.md------按"需不需要模型理解"分层，必须发生的事不交给概率。
判断标准我现在只用一个问题：这件事需不需要模型理解？需要（怎么部署、怎么查 bug）→ Skill；不需要、只需要必然发生（部署前必须跑检查、事件必须上报、submodule 绝对不许写）→ Hook 或物理隔离。把"必须发生"的事交给概率，就是 7 月 8 日那种事故的总根因。
四、Sub-agents 与 Agent Teams：分身术的正确姿势
第 10 篇有两个让人记住就不再用错的判断：
"Sub-agent 是 Claude Code 里唯一一个结构上允许'执行完即丢弃'的东西。"
"不是多线程，更像是 Unix 的 fork()：创建时复制父进程的内存快照，之后各走各路。"
实战：这个仓库的 Agent 编制
TECH.md §13 的 Agent 表列着 8 个专用 Agent （.claude/agents/ 下 7 个定义文件，外加 team/ 目录的团队配置），Agent Teams 实验开关常开。编制不是拍脑袋分的，是按"上下文污染程度"排的：
- Explorer agent：大范围代码梳理、资料核实------只读，过程最脏（几十上百个文件的中间产物），跑完即弃，只把结论带回主对话；
- builder agent：按已确认的方案执行修改，不重复探索；
- validator agent：结果校验------让"另一个角色"审"干活的人"，没有心理包袱。
主对话只进决策，不进原料。sub-agent 把信息密度压缩到主对话能吞咽的程度，主对话负责判断和最终责任。如果你想让主对话记住什么，就别让原料进入它的上下文。
图：按"上下文污染程度"分工------Explorer 吞下最脏的探索过程，builder / validator 各管执行与校验；噪声随分身丢弃，主对话只收结论。
Sub-agent 不是"并行加速"的玩具，核心价值是噪声隔离。判断开不开 sub-agent，我现在的问法是：这个任务的中间产物，值不值得占用主对话的上下文？
五、工具选型：MCP 还是 CLI？这个仓库两种都用了
第 12 篇给过一条能直接执行的选型规则：
"如果你要在 prompt 里反复解释同一个工具的用法，MCP 值得考虑。如果工具用法一目了然，CLI 更快。"
底层原因在第 13 篇：模型只"提议"，harness 才执行；每个工具进上下文都要交 token 税，调用链每长一层，失败率和成本就涨一截。
实战：CLI 派的三件套
这个项目的外部系统对接，主力是三个 CLI，全都没走 MCP：
- meegle CLI------飞书项目操作（MQL 查询、节点流转、评论），feishu-bug skill 的底层。调用链：skill → CLI → API，少一层 MCP server 的 JSON-RPC 往返。
- memex CLI------会话蒸馏、搜索、wiki 入库，第八章的主角。
- xmov-cli ------项目自己的 CLI，
cli.mjs一个文件 1283 行，deploy 命令五个平台分支，里面塞满了"只有踩过才会写"的细节（UTM 占位符注入、Windows 管道符兼容......）。
这些工具用法对 Claude 来说一目了然：xmov deploy oss <project> 有 --help，有错误提示，失败会说话。这种工具包一层 MCP，纯属多交 token 税。
实战：MCP 派的一个例外
packages/sdk-bridge 是这个仓库里唯一的 MCP 服务：一个 WebSocket 调试桥（ws://localhost:9876），让 Claude 能直接连到运行中的 SDK 实例做调试。为什么它值得？因为调试对话里需要反复、双向、有状态地交互------这正是"要在 prompt 里反复解释用法"的场景，标准化的收益大于中间层的成本。
另外 AI_CODING.md 的禁忌清单里有一条常被新人误解的规定，值得抄给所有团队：
"不要把 CLI 说成 AI：
xmov deploy是确定性脚本。"
确定性工具就是确定性工具------它不会"理解你的意图"，参数错了就是错了。这条禁忌存在的意义，是防止有人把部署失败归因于"AI 没理解我"，而不是去查参数和环境。工具人格化，是团队 AI 素养的第一大敌。
图：两条车道的调用链对比------CLI 三跳直达、失败面小；MCP 多一层 JSON-RPC 往返，只在"有状态双向调试"（sdk-bridge）这种场景值回票价。
先写 CLI，用到"反复解释"再加 MCP。工具选型不是赶时髦，是算调用链的账：层数越少，失败面越小，token 越省。
六、调试：证据驱动，三场真实战役
系列讲四种核心任务的那篇给 bug 修复定过纪律：症状描述 + 已排除项 → 生成 3~5 个假设按可能性排序（禁止直接修）→ 逐一写验证代码 → 确认根因再修 → 修后查副作用。核心就一句：
"报错信息是症状，不是根因。"
下面三场战役，第一场是这个项目技术含金量最高的调试。
战役一：流式 speak 时序重构------"直接发就行"（7 月 16 日晚）
症状。 Agent 智能体项目（apps/digital，FastAPI 后端 + WebSocket 流式分句，前端 React）里，数字人说话有明显的句间卡顿。7 月 16 日 19:24，我给出关键判断：
"前端项目好像等到前一段播完了才发送下一段文本，如果有truefalse不需要这样的 直接发就行"（session-2026-07-17-0402297e.md，该文件为 7-17 蒸馏批次，会话实际发生在 7-16 晚）
19:28 我又补了一条协议约束，把方向彻底钉死：
"只要拿到流式文本就发送 只要speak 首句 is_start"
证据。 Claude 全局搜索 speak|queue|isPlaying，在 nebula.tsx 里挖出两个连环问题：
- WebSocket 收到文本推入
textQueue，playNextText()的消费守卫是if (!isPlayingRef.current)------"上一句播完才拿下一句"，这就是卡顿的物理来源； - 更隐蔽的是：
onVoiceStateChange回调里那行playNextText()被注释掉了（第 145 行）------队列失去自我驱动能力，只能等下一包入队时"顺带"被消费。
根因。 前端不知道 SDK 的流式协议里，引擎内部自己缓冲排队：多个 (false, false) 分句发给 SDK，SDK 自动串行播放。序列化逻辑引擎层已经做了，前端再造一层队列就是叠床架屋。前端的职责只有四个字：收到就发。
修复。 重写消费链：收到 chunk 立刻 playNextText()；内部改 while 循环，一次 drain 所有连续就绪的分句；首句 speak(text, true, false)，中间 (false, false)。
最难的是收尾：分句经常比 done 信号到得快，done 到达时所有分句都发出去了、却没一个带 isEnd=true------流关不上。解法是引入 needsEndSignalRef，三种情况穷举：
- 常规 （chunk 发完 done 才到）：done 到达 + 队列空 +
needsEndSignalRef=true→ 补发空尾帧speak("", false, true)； - done 先到、队列还有货 ：drain 到最后一包时直接让正文搭上
isEnd=true，尾帧逻辑跳过； - 乱序空洞 （done 到了但中间缺包）：drain 在空洞处 break，等缺的包到了再冲刷，最后一包自然带上
isEnd=true。
当时 Claude 自己的总结（逐字）："尾帧要么'搭最后一班正文车'，要么'单独补一班空车'，两条路互斥，保证恰好发一次。"
这场仗最有说服力的不是修好了，而是改动以删为主 ------一层前端队列被整体拿掉，时序正确性反而上升，因为正确的串行化本来就在引擎层。改的是公共消费链，所有重置点（三处）同步清零 needsEndSignalRef，一处不漏。
图：修复前排队等 voice_end，句间卡顿；修复后"到了就发"，串行化交给 SDK 引擎层，done 晚到的边界用尾帧信令兜底。
战役二：离线 → 在线，speak 不能"冤枉发"（7 月 8 日）
场景。 数字人离线期间，上层还在持续 speak------SDK 不响应，文本全丢了；恢复在线后，期望积压的内容能补播。实现思路不难（executeSsml 加缓冲队列，方案后来沉淀为 docs/specs/speak-queue-offline-to-online.md），难点在怎么判定"真的在线了"。
Claude 最初的方案想当然（调了 online 方法就当在线），我一句话打回，逐字：
"妈的肯定要等sdk回调呀 不然不是在线状态 你发speak不是冤枉发的"（session-2026-07-08-3fcd7854.md）
SDK 的状态机不是靠 setTimeout 猜的，它有确定的回调链。通用 Node.js 直觉（"调用了 online 方法就是在线"）在 SDK 协议层面前就是会翻车。这类问题的正确姿势是把具体回调日志喂给 Claude，而不是扔给它"在线/离线"两个字的描述。
战役三：两条写进新人手册的静态陷阱
不是每次调试都要兴师动众。有两条坑，复现成本太高、排查过一次我就再也不想查第二次，所以教训直接写进了 TECH.md 的新人陷阱清单：
- 音频管线 ：
ScriptProcessorNode必须双向连接------只source.connect(processor)而 processor 不接 destination，onaudioprocess永远不触发，且全程无报错。正确做法是接一个gain=0的静音 GainNode 到 destination。 - 模型名 ：百炼的
qwen3.6-flash不支持/v1/chat/completions（只支持 Responses API），要用qwen-flash。接口返回 404 的时候，你不会怀疑是模型名本身不兼容这个端点。
这两条现在是 CLAUDE.md / TECH.md 双层覆盖------新人（包括新的 AI 会话）入职第一天就会读到。
AI 调试的真正威力不是"聪明"，是耐心：它会老老实实插桩、收证据、逐条收敛假设，不凭直觉跳步。但方向得人来指。人负责指方向，AI 负责跑证据------这是我在 bug 修复上找到的最省事的分工。
七、产品化：一个人，48 小时，PRD + 高保真原型
第 02 篇的三要素------背景 + 目标 + 约束，缺一个 Claude 就猜------在产品层面比写代码层面更灵。下面这个故事发生在 7 月 16 日到 17 日，是整个项目里强度最高的两天。
背景：文档平台，从零到原型 48 小时
决定做"星云数字人 SDK 文档管理平台"。痛点写在 PRD 里（docs/specs/document-platform-prd.md）：SDK 的 17 篇文档（4276 行）挂在飞书 Wiki------无搜索、无代码复制、无在线试跑。目标定在官网 www.xingyun3d.com/docs 下。
一个人，不开 Figma，不找设计师。产出四件：PRD、提案、技术方案（VitePress）、高保真 HTML 原型（可交互、部署上 OSS）。过程中 Claude 在同一会话里切了四个角色。挑两个最说明问题的讲。
角色：设计师------"主色应该是黑吧"
原型第一版是 Mintlify 风格绿色系。我把公司官网的仓库路径丢给它，说"网站主题风格要和它靠齐"。Claude 读了官网的 root.css（整套 --xy-* 设计 token 体系），把设计语言搬进原型------但把主色做成了蓝色。我纠正，逐字：
"这个我给你token你用的也不对呀，主色应该是黑吧"（session-2026-07-17-0402297e.md）
关键在它接下来的动作：重新去读 token 的语义注释 ，发现 --xy-main-* 全部指向黑阶（#141414 / #000），蓝是 --xy-auxiliary-*（辅色），紫是 --xy-accent-*（点缀）------官网其实是黑白为主、蓝色点睛。于是 v1.2 把主按钮、导航激活态、logo 全部换回黑阶，只留链接和选中态为蓝。
"主色是黑"这句话，字面意思是换颜色，实际意思是"你把 token 的语义层级搞反了"。它能接住这层意思，是因为官网 CSS 里有清晰的语义注释。那一刻我意识到一件事：好的机器可读资产，能让 AI 的纠正成本低到一句话。 约束不一定写在 prompt 里，也可以写在代码的注释里。
角色：产品经理------一句话定生死
文档平台规划里有一页"AI 工程展示"。讨论到这页时，我说了一句分量极重的话，逐字：
"avatar-agent-builder 这个是最核心的。其他是辅助用户"（session-2026-07-17-0402297e.md）
这句话直接改了产品定位：文档平台不是"文档 + 下载链接"，而是把 avatar-agent-builder 摆成核心------用户下载的不是一个 npm 包，而是一个完整的 Claude Code 工作环境：
bash
your-project/
├── CLAUDE.md # SDK 的全部陷阱规则，开局自带
├── knowledge/ # 17 篇 SDK 文档，AI 边查边写
└── .claude/skills/
├── avatar-agent-builder/ # 一句话生成数字人应用
├── debug-probe/ # 运行时插桩调试
└── multi-platform-deploy/ # 五平台一键发布我要卖的不只是 SDK，是"SDK + 会用这个 SDK 的 AI"。SDK 的接入门槛（7 个必传参数、销毁顺序、SSML 双标签、F~U 点位......）全部被 AI 消化掉：用户对 Claude Code 说"帮我做一个医院挂号导办 Demo"，AI 从 flow 模板搭出完整可运行的应用，全程不需要人读那 17 篇文档。
插曲：BI demo 的八态环形状态机
同样的产品化能力也长在 bi-demo-electron 里。它的状态机是环形的八个状态（Hidden ↔ Wake → Listen → Think → Walk → Speak → Idle ↔ Goodbye），7 月 11 日我在测试唤醒闭环时发现一个 AI 不会自己察觉的逻辑漏洞，逐字：
"你在再见的时候调用了离线，再见之后，然后唤醒，你应该调用在线把，不然数字人显示一直是离线状态。onlineMode"
"再见 → 离线 → 唤醒 → 还是离线"------这种跨状态转换的完整性，AI 写单点逻辑时不会主动检查。状态机的闭环 review，永远值得人专门过一遍。
图：产品经理 → 竞品分析师 → 设计师 → 架构师，四个角色在同一会话流里切换，每次方向调整当场同步 PRD、方案、原型三份产物。
这两天让我印象最深的不是速度，是改方向的成本。域名改了、主色改了、定位改了，PRD / 方案 / 原型全要跟着动------放以前，每次改方向都意味着半天返工，所以人会本能地"先想清楚再动手"。现在四个角色在同一会话里并行，每次调整当场落地三份产物，我才敢边做边改。
八、知识管理：对话不是消耗品，是能复利的知识库
系列完整实战案例那篇留过一个判断：对话是 AI Coding 时代的知识库原料。加餐 01 从机制上解释了为什么------Agent Loop 是 while(true)，丢失目标比超时更常见，对话不蒸馏，价值就被上下文压缩整个吞掉。
实战：25 个会话，4.6MB 的事故档案
这个项目的知识管理落地成一个开源工具：ai-memex-cli （GitHub，MIT）。思路和本文一致：知识库就是 Git 里的纯 Markdown------可读、可 diff、可 blame；CLI 本身零 LLM 调用，语义工作交给装在 .claude/skills/ 里的 Agent skill 去做。上手两条命令：npm install -g ai-memex-cli，然后 memex onboard。之后在 Claude Code 里说一句"distill 一下"，会话就落成带 frontmatter 的结构化 Markdown。这个工具背后的想法（Karpathy 的 LLM Wiki），我在《给 AI Agent 装上"长期记忆"》里详细写过，这里不展开。
本文的档案就是这么来的：~/.llmwiki/raw/team/sessions/sdk-demo/ 下 25 个结构化 Markdown，共 4.6MB，覆盖 6 月 27 日到 7 月 17 日。文中所有故事、日期、原话，全部来自这批档案的检索和复核。
用 memex 会踩的第一个坑：文件名日期 ≠ 会话日期
这个坑只有真用过才知道：蒸馏出来的文件，文件名上的日期是蒸馏批次的日期，不是会话发生的日期。 名为 session-2026-07-14 的文件，内容实际从 7 月 11 日开始；名为 session-2026-07-07 的文件，会话跨度是 7 月 2 日到 6 日。所以引用任何"会话日期"，别看文件名，以文件内的 started/ended 字段或消息时间戳为准------不然你基于错误日期做的分析，从根上就是错的。
三个值得抄的作业
第一，bug 修复路径不丢。 音频管线"ScriptProcessorNode 必须双向连接"这条，如果只是"那天在对话里讨论过"，不出两天就没了。蒸馏 + CLAUDE.md 回流之后，它变成可检索、可被每个新会话自动加载的文本资产。
第二，架构决策链不丢。 文档平台的部署方案几经讨论才定到 www.xingyun3d.com/docs。每个被否决的方案、谁否决的、为什么------不蒸馏，接手的人只看到结果。看不到决策链，三个月后就会有人把旧方案重新提一遍。
第三，我自己说过的原话是最好的 Skill 触发词语料库。 "发布到四个平台"、"查下飞书 bug"、"distill 一下"------这些真实短语写进 skill 的触发条件，比硬造"当用户需要查询飞书项目 Bug 时请使用此 Skill"自然一个量级。
图：对话 → 蒸馏（raw）→ 提炼（wiki）→ 固化（CLAUDE.md / Skill）→ 下一次对话更聪明。不蒸馏 = 每天雇一个失忆的天才。
为什么值得做这件事？因为 AI 时代大家用的是同一批模型------模型是租来的，知识库才是自己的，拉开差距的是后者。 起步只需要三件套：CLAUDE.md + 一个蒸馏工具 + 一个 raw 文件夹。每周 distill 一次，一个月后你会拥有两样别人偷不走的东西：一本自己团队的事故档案，和一个越来越不会犯重复错误的 AI 协作环境。
九、那些方法论之外的真实细节
正经章节讲完了，说几个档案里翻出来的、方法论文章里不太会写、但特别能说明"这套体系真的在被日常使用"的细节。
Output Styles：我的 Claude 有人设。 .claude/output-styles/ 下有 11 个输出风格配置。因为配了人设，蒸馏档案里的 Claude 自称"丹丹"，管我叫"老公"------比如它解释尾帧逻辑时会说"先回答老公的问题，丹丹解释一下 needsEndSignalRef 是怎么'追上'的"。
听着像玩梗，其实有正经用处，而且是两层。第一层是阅读体验：长会话里，有个稳定人格的 AI 读起来确实没那么累。第二层更妙------"老公"这个称呼我故意放在 CLAUDE.md 的最后几行，它同时是个探针：AI 开口叫"老公"，说明它把 CLAUDE.md 从头读到了尾；哪天不叫了，大概率是内容没被完整加载，或者注意力没走到末尾。第一章说注意力会随位置衰减，知道它会衰减，就在末尾放个哨兵------一条称呼指令，顺手就成了"CLAUDE.md 有没有被完整读取"的检测器，比加监控直观得多。
连"说话方式"都是配置，这也是 Claude Code 可编程性的一个侧面。
Commands：12 个项目级命令。 bench、build、quick-plan、start......高频多步操作收成一句话，不用每次在对话里重新铺上下文。
prompt-enhance：缺三要素就追问。 检测到请求缺背景/目标/约束，先追问（最多 3 个）再动手。把"好 Prompt 三要素"从人的肌肉记忆变成系统的强制检查。
"不要把 CLI 说成 AI"。 第五章提过，值得再提一次。团队 AI 素养的分水岭，往往就在于分不分得清"确定性工具"和"概率模型"。
十、全家桶对照表
对照系列各篇（已发布的按公开编号，写作中的标注"待发布"），给出本项目中的对应出场。
| 概念篇 | 核心方法 | 本项目出场 |
|---|---|---|
| 01 开篇总览 | "先遇到痛点，再找对应的工具" | 没有一个 Skill 是预先设计的：deploy 在 8 个 bug 后定版，debug-probe 在方向搞反 + 探针 404 后长出 Phase 0 |
| 02 Prompt 工程 | 背景+目标+约束三要素 | prompt-enhance skill 把三要素变成强制追问；PRD 待确认项精确到负责人 |
| 03 Commands | 上下文劣化与命令系统 | 12 个项目级命令收编高频操作；CLAUDE.md 精简（143→69 行）对抗注意力稀释 |
| 04 CLAUDE.md | 纠偏器不是文档 | 9 条项目陷阱条条带事故；"踩坑回流"条款是体系发动机 |
| 05 Skill 提炼 | 固化默认动作，不是收藏经验 | deploy / debug-probe / feishu-bug / avatar-agent-builder 四个 skill 的出生证明全是事故报告 |
| 06 Hooks | 确定性自动化 | 13 个 hook 脚本全事件上报 send_event.py；"发布必须走 skill"从口头约定升级为红线 + 护栏 |
| 07 Plugins | 不创造新能力，是分发机制 | avatar-agent-builder 发布到 Gitee：从模板抽象到独立运行再到分发的完整路径 |
| 08 渐进式披露（待发布） | 入口层只做分类不做执行 | avatar-agent-builder 的 SKILL.md（88 行入口）→ templates/ → reference 材料分层加载 |
| 10 Sub-agents | fork + 执行完即丢弃 | Explorer / builder / validator 按上下文污染程度分工；批量探索、核实类任务一律 fork 出去，主对话只收结论 |
| 11 Multi-agent | 架构 A 并行 vs 架构 B 协作 | TECH.md §13 的 8 个专用 Agent + Agent Teams 实验开关常开 |
| 12 / 13 MCP + Tools | 调用链越短越好 | CLI 三件套不走 MCP；唯一例外 sdk-bridge------有状态双向调试才值得标准化 |
| 四种核心任务（待发布） | 四种任务四种节奏 | 新功能（spec 先行）→ Bug（假设验证 + debug-probe）→ 重构（specs 目录 20 个 spec）→ Review（CLAUDE.md 当检查单） |
| 输出验证（待发布） | 信任但要验证 | 改公共逻辑必 grep 全部调用方；部署后验证 OSS 可达；本文所有数字过 git 实证 |
| 成本控制（待发布） | 隐含成本才是大头 | spec 先行一次写对 8 个修复，比来回返工便宜一个量级 |
| 完整实战（待发布） | 对话是知识库原料 | 25 个会话 4.6MB 入库 memex；本文就是蒸馏档案的直接产出 |
| 企业落地（待发布） | 从个人工具到团队实践 | AI_CODING.md（551 行新人教程）+ TECH.md（1109 行技术手册） |
| 加餐 01 源码七洞见 | 行为是工程决定的 | 三道防线治理 deploy 绕过事件；顶部注意力规律指导 CLAUDE.md 精简排布 |
说实话，列完这张表我自己也有点意外：没有一个是为用而用。概念篇负责告诉你"这个东西是什么"，项目负责告诉你"你为什么最终会需要它"。
十一、复制这套打法：三周起步路线
如果你的团队也想跑起来，不用照搬全部，按这个顺序来：
第一周：建免疫系统。 跑 /init 生成 CLAUDE.md 骨架，然后只做一件事------每次纠正 AI 同一个错误第二次时，当天写进去，格式照抄："规则 + 事故原因"。两周后你会得到 5~10 条真红线，比任何模板都值钱。
第二周：练第一个 Skill。 挑一个中风险、已重复三次以上、总有一两步会漏的任务（别挑最关键的），按四问写 SKILL.md：什么时候用 / 按什么顺序做 / 输出长什么样 / 什么时候不适用。正文控制在 50 行上下，长材料拆到 reference/。前三次使用大概率会暴露设计缺陷------那是它在长肌肉，不是失败。
第三周：让知识沉淀下来。 装一个会话蒸馏工具（我用的是开源的 ai-memex-cli），每周跑一次 distill。一个月后，你会有一本自己团队的事故档案。
三条铁律贯穿始终：
- 概率的归概率，确定的归确定------必须发生的事交给 Hook 和脚本，别交给模型的自觉性。
- 失败的地方优先成为检查项------spec 先行、踩坑回流，让每次翻车都产生永久资产。
- 对话是知识库原料------不蒸馏的协作，等于每天雇一个失忆的天才。
尾声
回到开头那个舞台。一个半月前，XmovAvatar 还是"得读 17 篇文档才能上手"的 SDK；现在它配了一整套 AI 工作台。
如果你读到这里想亲眼看看：
- 三分钟体验 ：打开 media.youyan.xyz/lite-sdk-de... （SDK 全能力演练场）、media.youyan.xyz/bank-loss-r... （银行业务流）、media.youyan.xyz/pure-qa-dem... （纯对话）；
- 一句话开工 ：从 Gitee（xmovmaster/avatar-agent-builder）拿到技能包放进
.claude/skills/，对 Claude Code 说"帮我做一个 XX 场景的数字人 Demo"； - 工程源码 ：本文涉及的 monorepo 已全部开源------zelixag/avatar-work，CLAUDE.md 的 9 条陷阱、9 个 skill、13 个 hook、xmov-cli 的 1283 行，都可以直接翻；
- 深入集成 ：SDK 文档正在迁往 www.xingyun3d.com/docs，17 篇文档配搜索、代码复制和在线演练场。
- 源码镜像：整仓源码快照在 github.com/zelixag/avatar-work（推送前已做全量凭证清洗，流程见发布 skill 的 github.md）。
但说实话，数字人只是载体。这一个半月真正攒下来的，是这套跟 AI 搭班子的方法。
最后回到引子那笔账。一个半月，一个人，交付清单是：六个数字人资产、七个共享包、五个平台的自动化发布链路、30 个飞书 bug 的分析与闭环、9 个 skill + 13 个 hook + 8 个专用 Agent，外加 4.6MB 可检索的蒸馏知识库。
外人容易把这叫"AI 写得快"。我自己天天在里面，看得比较清楚：模型本身出的力没想象中大。CLAUDE.md 管不犯重复的错，skill 把高频流程收成一句话，hook 保证必须发生的事必然发生，sub-agent 把脏活隔在外面，知识库让经验攒得下来------哪一样都不是模型聪明，都是人造的工程。这套绕着模型搭起来的东西，我管它叫 harness 工程：模型是引擎，这圈东西才是车。引擎年年换代，会造车的人永远比只会踩油门的人快。
顺带说一个很多人不信的事实：这一个半月给我当 coding 搭子的引擎，不是 Fable 5 也不是 GPT-5.6，是国产的 DeepSeek V4 Pro ------上面所有活儿，它全扛下来了。这大概是对 harness 工程最硬的一次证明：工程搭对，国产模型一样交付。
顺着这个话题，我 4 月还写过一篇《Harness Engineering：为什么你用 AI 越用越累？》，可以对照着看。
工具会过时，模型会换代。我唯一确定不过时的，是那个循环：翻车 → 当天写下来 → 下次不再犯。一个半月前我写下第一条红线的时候没想这么多，现在回头看，免疫系统就是这么长出来的。
至于你------不用照搬。先从第一条红线开始写就行。
附录 A：关键节点时间线（全部经档案核实）
| 日期 | 事件 | 沉淀的资产 |
|---|---|---|
| 6/12--6/26 | Monorepo 脚手架、SDK 封装（useSDK + 手写类型桩）、两个 Demo 核心开发；行走点位排查两小时（A~E 内部预留，零报错） | CLAUDE.md 初始化 + "key 范围 F~U 共 16 个"等首批红线 |
| 6/27 | multi-platform-deploy 定版：spec 先行列 8 个缺陷，7 个修复集中于 cli.mjs | docs/specs/fix-deploy-skill.md；BI demo 环形八态状态机决策 |
| 6/27 | 知识蒸馏起步，首批 7 个 session 入库 | memex raw 档案 |
| 6/27 | avatar-agent-builder 模板从 bank 抽象为 flow | flow / chat / sdk 三模板 |
| 7/03 | debug-probe 首战：数据流方向搞反被纠正；探针 404 | Phase 0 探针服务器 + "插桩代码绝对不能提交" |
| 7/07 | 三个 Demo 四平台集中发布 | spec 先行模式固化 |
| 7/08 | deploy skill 被绕过，我爆粗；同日发现 cli.mjs 构建清空 VITE_* 环境变量 | "发布必须走 skill"升级红线；离线→在线 speak 缓冲方案 |
| 7/10 | 弹窗像素级微调 | CredentialModal 模式复用到各魔搭部署 |
| 7/11 | BI demo 唤醒闭环漏洞：再见调了离线、唤醒没调在线 | onlineMode 修正；7/13 打 v1.0.0 包 |
| 7/16 | TECH.md 成文（1109 行新人手册）；CLAUDE.md 精简 143→69 行（git 实证） | "删掉这条 AI 会不会犯错"成为精简标准；skills 迁移项目级 |
| 7/16 晚 | 流式 speak 时序重构：拿掉前端队列，needsEndSignalRef 尾帧信令 | "收到就发，串行化交给引擎层" |
| 7/17 | 文档平台 PRD + 高保真原型；"avatar-agent-builder 是最核心的"定位确立 | sdk-docs/md 转为 submodule，文档进入 GitLab 协作流 |
| 7/17 | 全量会话蒸馏（累计 25 个文件、4.6MB） | 本文素材入库 |
附录 B：AI Coding 系列目录
本篇为实战收官篇。系列已发布篇目（按发布时间）：
| 编号 | 篇目 | 发布时间 |
|---|---|---|
| 01 | AI Coding 新范式：我为什么认为 Claude Code 会改变程序员的工作方式 | 03-28 |
| 02 | 给 Claude Code 写好指令------Prompt 工程实战指南 | 03-30 |
| 加餐 01 | 源码曝光后的七个洞见 | 04-02 |
| 03 | 为什么 Claude Code 要有指令（Commands）：本质是上下文管理 | 04-03 |
| 04 | CLAUDE.md 完整指南------让 Claude 真正理解你的项目 | 04-08 |
| 05 | 别再直接 Fork 别人的 Claude Skill：Skill 的本质，不是收藏经验，而是固化默认动作 | 04-11 |
| 06 | Hooks 源码深度解析：Claude Code 的确定性自动化体系 | 04-30 |
| 07 | Plugin：把你打磨好的 Claude Code 配置打包分享 | 05-12 |
| 10 | Sub-agents 深度解析：从源码理解 Claude Code 的分身术 | 05-23 |
| 11 | Multi-agent 与 Agent Teams：别被名字困住 | 05-29 |
| 12 | MCP 深度解析：从源码理解模型上下文协议的设计、争议与未来 | 06-05 |
| 13 | 工具层内核------Claude Code 怎么真正"动"你的代码 | 06-09 |
另有项目实战《SmartKB 智能知识库 Agent》《用 Claude Code 从零搭建数字人 SDK 开发平台》两篇；概念篇后续（渐进式披露、四种核心任务、输出验证、成本控制、企业落地等）写作中，陆续更新。
AI Coding 系列到此收官。文中所有原话、日期、行数均可在蒸馏档案（~/.llmwiki/raw/team/sessions/sdk-demo/）与 git 历史中复核。