HyperFrames：先跑通全片

在正式生成画面之前，我用 HyperFrames 做无配音全片预演。它用 HTML 组合和时间轴数据，把 18 个镜头的字幕、占位镜头和已有素材串成一条可从头播放的 200 秒预演。

这一步的价值不在画面好看，而在于：不依赖人声，我也能判断结构、高潮、停顿和结尾是否成立。缺的镜头用明确的构图占位，不为了消灭灰板而提前生成。

AI 生图 / 生视频：只在缺口处使用

AI 画面只承担两类工作：一是关键帧（概念帧），用来定下“青出于蓝”“登高远眺”“舟行江面”这些意象的构图；二是短段生视频，为某些明确缺口补动态，比如染布的扩散、冰晶的形成。

每段生成都记录镜头 ID、模型/版本、参考图、提示词、参数和候选号，方便追溯来源。

真人录音 + 本地 ASR 对齐

声音是全片的叙事主线。我用本人原声录制整段旁白，然后用本地 SenseVoice 做语音识别，得到未经校订的全文和字级时间。

接着按文稿对古文误识做规范化（比如“已／矣”“臂／比”、通假字“生”读 xìng），再用识别时间和校订文本做字符对齐，生成准确到字的字幕时间点。这样字幕不再靠人工逐字拍时间，节奏也更贴原声。

Python 脚本 + ffmpeg 合成

每个版本都有对应的构建脚本（build_v2.py 一路到 build_v10.py），负责读时间线、字幕、停顿和镜头位置，再用 ffmpeg 把片段按实际句子时间重新排布、编码。

到 v10，整段原声处理后约 140 秒，加上片头片尾各三秒，全片 146 秒；1920×1080、25fps、AAC 48kHz，48 个画面片段按句子时间重新对齐。

交付

最终导出 1080P 成片和封面，满足 MP4、16:9、≥1080p、≥25fps、≤200MB 的要求。整个流程里最省心的部分，是把“字幕、节奏、合成”这些重复劳动交给脚本和工具，把注意力留给真正需要判断的地方。

如果你也在做 AI 视频，我的经验是：把可重复的步骤工程化，把不可重复的判断留给自己。

答案不等于理解

片子的开头是这样一句旁白：“有时候，答案来得太快了。一个问题输入屏幕，几秒钟后，我就能得到解释。可当我合上答案，试着用自己的话说清楚时，我还是会停下来。答案有了，我真的懂了吗？”

这几乎就是我自己的真实体验。用 AI 查问题太方便了，方便到有时候我会误以为“看到了答案”就等于“学会了”。但真正让我停下来的是：关掉屏幕，让我自己讲一遍，我还是讲不利索。

工具与判断，是两件事

《劝学》里说“君子生非异也，善假于物也”，讲的是借助外物扩大自己的能力。我以前只记住了“善假于物”四个字，却容易漏掉它前面的那一层意思：借了车马、舟楫，不等于自己就会走路、会游泳。

所以我把结尾落在这样一句上：“舟能帮我渡过江河，却不能替我选择方向。桨握在手里，我仍要观察水流，也要一次次调整。”

AI 能给我答案，甚至能帮我“看见更远的风景”，但理解、判断和修改，仍然要由我完成。工具负责“假物”，而我负责“善假”。

不把 AI 当敌人，也不把关电脑当成长

做片子的过程中，我有意识地避开了两个极端。

一个极端是把 AI 写成敌人，好像只要关掉电脑、回到纸笔，人就自然成长了。这不真实，也不诚实。电脑和课本完全可以同时摆在桌上。

另一个极端是把“得到答案”当成终点，忘了后面还有理解、比较、删改和表达。

我在结尾让主角既不关电脑，也不做夸张的顿悟，只是继续修改自己的句子。成长不是一次性的醒悟，而是“一次提问，一次比较，一次删改”这样一点点长出来的。

学习没有变得更简单

AI 时代，学习没有变得更简单，只是问题变了。以前的问题是“我能不能找到答案”，现在的问题更多是“我是不是真的懂了”“我该信哪一份答案”“我要怎么把它变成自己的表达”。

这些问题，工具都替不了我。

善假于物，不是停下学习，而是学会更好地出发。

一开始的问题

项目早期，我急着验证“舟楫渡河”这个高潮能不能做出来。渡河段涉及人物、水面、木舟、桨的动作和转场，是全片最容易出错的镜头。我在这里反复试了很多版，人物不一致、水面不真实、动作穿帮，一遍遍返工。

结果很尴尬：局部样片堆了很多，整部片子却始终不能从头到尾看一遍，因为声音和结构都还没定。

一次“重启”

后来我停下来，把整个项目“重启”了一遍，只定了四条硬规则：

1. 先锁文案，后录配音。声音和全片结构没锁定之前，不做正式配音，更不投钱做付费生成。
2. 先全片，后精镜。先做出能从头播放的低成本预演，再针对性地精修单个镜头。
3. 每轮只解决一个问题。人物、物理动作、风格、节奏，不在同一轮里同时试错。
4. 反馈集中收集。不逐镜零散返工，一次集中审片、一次性改完。

这四条看起来平淡，但正是它们把项目从“局部很好、整片跑不通”救回到“能稳定交付”。

制作顺序

新的顺序是：文案 → 试读 → 锁镜头时间 → 静态分镜 → 高风险镜头测试 → 全片无配音预演 → 集中补拍 → 正式生成 → 精剪交付。

其中最关键的是“无配音预演”：在没有任何配音的情况下，用字幕和占位镜头把 18 个镜头的节奏先跑通，确认高潮、停顿和结尾都成立，才进入下一步。

控制 AI 生成

AI 生图、生视频是这套流程里最不可控的部分，所以我定了两条小规则：

• 一条生成只安排一个主要动作、一种运镜。复杂的正面说话、连续上船动作优先实拍或分切，不指望长段 AI 一次成功。
• 同一镜头最多连续试三轮。首轮验证、二轮修正、三轮还不行就简化动作或换镜头，不为一个复杂变形无限烧预算。

最想记住的一条

回想起来，这个项目教会我的不是某个工具的用法，而是生产顺序。先确认“要说什么”和“怎么讲完”，再去解决“某一个镜头怎么做得漂亮”。顺序对了，AI 才是帮手；顺序反了，AI 只会放大返工。

如果你也在做 AI 视频，我的建议只有一句：先把整部片子跑通，再回来打磨最漂亮的那几秒。

从《劝学》出发

这个作品参加的是“典耀中华·课本里的中国”语文 AI 创作展示活动。我选了荀子的《劝学》，只用一个主文本，不把别的课文拼进来。方向落在最后一句——“君子生非异也，善假于物也”。

我没有把它拍成“AI 有多厉害”的宣传片，而是想讲一个更具体的故事：一个学生得到了现成的答案，却发现自己还是说不清楚，于是通过朗读、想象、比较和修改，慢慢把答案变成自己的理解。

六段结构

整部片子按旁白分成六段，共 18 个镜头：

1. 答案与理解——现实书桌，提出“答案不等于理解”。
2. 学习使人改变——“学不可以已”“青出于蓝”“水凝成冰”。
3. 从思考到看见——“终日而思”走向“登高博见”。
4. 舟楫渡河——“假舟楫者”，这是全片唯一的视觉高潮。
5. 积累与判断——“不积跬步”，回到删改、重写的具体动作。
6. 回到当下——电脑和课本并置，继续修改自己的表达。

最终成片大约 146 秒，1920×1080、25fps。镜头顺序和文案都锁定以后，我才录自己的原声旁白。

真人声音 + AI 意象

这部片子最重要的决定，是让真人声音当叙事主体，AI 影像只负责难以实拍的空间和意象。

书桌、翻页、握笔这些镜头用实拍或占位；而“青出于蓝”的布纹扩散、“水凝成冰”的纹理、“登高远眺”的开阔河谷，这些用 AI 生成的关键帧和短段视频来表现。清晰可读的古文字幕由后期排字完成，不交给视频模型去“画字”。

现在的状态

项目从 v1 迭代到 v10，中间经历过一次“重启”——我一度把大量时间投在最难的渡河段，结果局部样片迭代很多，整片却始终无法从头播放。后来我回到“先锁文案、先全片后精镜”的顺序，才一步步走到可交付的版本。

到今天，v10 已经导出 1080P 成片和封面，放在交付文件夹里。距离正式提交还有一点时间，接下来主要是按官方要求做最后的参数核对和逐字校对。

这部片子让我重新读了一遍《劝学》，也让我更清楚地看到：工具能把我送到更远的地方，但掌舵的仍然是自己。

每天往返于住处和公司，看到的是高楼、地铁和匆匆赶路的人群。下班后也没有太多特别想去的地方，城市似乎没有想象中那么鲜明。不过，正是在这种略显单调的生活中，我第一次真正接触企业研发，也第一次发现，工作的“新鲜”并不来自每天都有好玩的事情，而是来自不断遇到自己不会的问题，再想办法把它解决。

这三周里，我主要参与智能翻译 Agent 的开发。

第一周：适应真实的研发环境

刚进入公司，我先完成了堡垒机、Token、权限申请等开发环境配置。以前自己写项目时，打开电脑就可以直接开始，但企业项目需要经过权限、流程和协作环节。因为部分权限没有及时开通，我一开始无法正常接入。后来通过主动询问和沟通，问题才得到解决。

这一周，我也开始熟悉智能翻译项目以及公司的组织结构。刚接触项目时，代码、内部工具和协作方式都比较陌生，需要先理解每个模块负责什么，再判断自己能够从哪里开始。第一周让我意识到，真实研发并不只是写代码。环境配置、权限管理、沟通反馈和团队协作，都是工作的一部分。

第二周：从开源框架走向真正落地

第二周，我开始真正参与功能开发。为了更快理解智能翻译 Agent 的实现方式，我参考了 GitHub 上的开源项目，并下载了一个基础框架。但这个框架并不能直接照搬。它原本依赖本地数据库，而我们的项目需要运行在浏览器环境中，所以我必须重新设计数据存储方式。

最终，我使用浏览器本地存储实现用户记忆，保存用户选择的语言、学习水平和最近的会话历史。同时，我将 Skill 改为按需加载，增加空数据降级、请求重试和多搜索源适配。即使部分服务暂时不可用，基础翻译功能也能继续运行。

在这个基础上，我还搭建了支持文本、图片、音频和文档输入的多模态 Web Demo，并逐渐建立统一的输入规范、模块注册和结果组装流程。翻译不再只是输入一句话、输出一句话，而是可以结合用户背景、历史记录和具体情境，选择不同的功能模块。

这让我明白，开源项目提供的是起点和思路，而不是标准答案。真正的工程开发，需要理解为什么这样设计，再根据自己的运行环境、产品目标和失败场景重新实现。把项目下载下来并不难，难的是把它变成真正适合当前需求的系统。

第三周：重构、验证与表达

第三周，我的工作从增加功能转向架构、测试和技术表达。我继续优化模块边界，加入缓存、懒加载、错误恢复、历史回溯和批量导入，并逐步完善多个输出模块的契约、提示词和评测样例。项目测试数量增加到 132 项并全部通过，部分请求的响应时间也得到了明显改善。

这一周，我还准备了工作汇报和工程问题分享。最初，我习惯把大量代码和技术细节放进 PPT，以为内容越多越能证明自己做得深入。但实际效果并不好：别人很难在短时间内抓住重点。

后来，我把复杂代码改成流程图、状态图和生活化类比，重点说明问题是什么、为什么发生、如何解决。这个过程让我认识到，技术做得再深，如果不能让别人听懂，就很难真正产生价值。工程师不仅要会实现，也要能清楚表达自己的判断。

从等待安排到主动推进

这三周给我最大的改变，是开始理解工作与学习的不同。

在学校里，课程表会告诉我今天学什么，老师会布置作业，考试会给出明确范围。但在工作中，很少有人不断提醒“你下一步应该做什么”。当任务不明确时，需要自己梳理；遇到阻塞时，需要主动沟通；完成一个功能后，还要自己考虑是否存在边界问题、如何验证，以及下一步还能改进什么。

刚来之前，我以为进入企业项目的人应该都非常厉害，很多问题可能只有我不会。真正相处以后，我发现大家也会遇到不了解的技术，也需要查资料、讨论和反复尝试。同学之间的实际差距并没有我想象中那么神秘。真正重要的不是谁从来不犯错，而是谁能够更主动地开始、更快地找到问题，并愿意持续把事情做完。

北京的生活也许没有想象中热闹，实习工作也没有想象中神秘。大多数时候，只是坐在屏幕前阅读代码、修改功能、排查问题，再一次次验证结果。但这种平静的重复，让我开始从“等待别人安排任务”，慢慢走向“主动发现下一步”。

如果要用几个词总结这三周，我会选择：适应、落地、重构和表达。

北京依然有些无聊，但这个夏天并不单调。城市的特色未必只藏在景点和高楼里，也可能藏在深夜仍然亮着的屏幕、一次次被修复的错误，以及一个高中生第一次真正参与 AI 项目时，逐渐建立起来的判断力和责任感。

本周完成

1. 完成 trans_agent-demo v1.1.0 系统改进

• 使用 ESLint 和 Prettier 统一代码规范，将 lint 告警清零。
• 加入请求缓存与懒加载，响应时间降低约 40%。
• 增加错误恢复、翻译历史回溯和批量导入功能。
• 重构模块边界，降低模块之间的耦合。

2. 完善测试、安全与 Skill 工具

• 搭建由 8 个测试文件和分析报告组成的测试体系。
• 完善评分系统中的 PBKDF2 与 AES-GCM 加密流程。
• 开发由 3 个模块组成的 Skills 导出工具，整理 34 个 Skill 定义。
• 完成七个输出模块的第一层实现，并为不同模块补齐契约、Prompt、评测脚本和语义样例。
• 测试数量由 119 项增加到 132 项并全部通过。

3. 准备工作汇报与工程问题分享

• 完成 10 页工作汇报答辩 PPT，并使用 Ardot 画布完成版面设计。
• 制作水墨动画 HTML 演示稿。
• 完成 9 页工程问题分享稿，分析“反馈按钮互斥”和“重试上下文丢失”两个 Bug 的根因与修复方案。

遇到的问题及解决方式

第一个问题是 Ardot 画布不支持动画。我没有放弃原来的视觉想法，而是改用 HTML 和 Canvas，实现水墨冲刷式的翻页效果。

第二个问题是工程分享稿第一版塞入了太多代码。虽然技术细节完整，但别人很难迅速理解。第二轮修改时，我把大段代码换成 SVG 图解和生活化类比，让问题的状态变化、根因和修复逻辑更直观。

两个 Bug 带来的思考

“反馈按钮互斥”和“重试上下文丢失”表面上并不相关，但继续向下分析后，我发现它们有相同的根因：把界面表现误当成了系统状态的唯一来源。

界面会重新渲染，局部数据也可能丢失。真正可靠的状态应该被明确建模和管理，而不是从按钮是否高亮、页面当前显示什么反向推断。

这让我体会到，修复 Bug 不能只盯着出问题的那一行代码。找到共同根因，才能避免同类问题再次出现。

下周计划

1. 根据答辩反馈继续修改和完善 PPT。
2. 跟进 v1.1.0 后续改进项。
3. 继续迭代产品规格文档和模块化架构。
4. 持续验证模型路由、多模块组合和边界场景表现。

本周收获与感想

这一周，我不仅更理解了状态管理、模块解耦和测试体系，也重新认识了技术表达。

图比大段文字更容易理解，大白话比堆砌术语更有效。技术做得再深，如果不能让团队理解它解决了什么问题、为什么这样设计，就很难真正产生价值。

第三周的关键词是：重构、验证、表达。

本周完成

1. 加入用户记忆功能：保存用户选择的语言和学习水平，下次打开时不必重新设置；同时支持空白草稿、会话复制和最近 8 条历史压缩。
2. 调整 Skill 调用方式：将技能改为按需、分层加载，减少不必要的调用，让系统更容易扩展。
3. 标准化 Skill 文档：打通批量导出、导入和自动去重流程，为后续统一维护技能体系打下基础。
4. 接入自我学习机制：用户反馈可以进入改进流程，帮助系统发现未命中场景并持续完善。
5. 增加情境提醒：根据天气、位置和附近门店提供建议，并优先使用免费接口。
6. 搭建可运行的多模态 Web Demo：支持文本、图片、音频和文档输入，建立 11 个场景级 Skill，并验证翻译路由能够正确命中。
7. 启动 v0.2 框架基线：建立统一输入、模块注册、执行计划和结果组装规范，让翻译与功能规划可以并行执行，并对单个模块失败进行隔离。

遇到的问题及解决方式

参考的开源方案依赖本地数据库，但项目需要直接运行在浏览器环境中，无法照搬。

我最终改用浏览器自带的本地存储，并增加空数据自动降级机制。即使历史数据不存在或读取失败，原有翻译功能也能继续使用。同时，针对模型和搜索服务的不稳定，我补充了递增重试、多搜索源适配和安全降级策略。

这次经历让我更加理解：开源方案提供的是思路，不是可以不加判断直接复制的答案。真正的工程实现，需要结合运行环境、产品目标和失败场景重新设计。

下周计划

1. 拆分过大的核心文件，按模块重构，提高可读性和维护效率。
2. 让能够独立执行的子任务并行运行，缩短整体响应时间。
3. 补充更多边界场景测试，提高意图识别和模块选择的准确率。
4. 继续完善模块输出、去重规则和回归评测。

本周收获与感想

这一周，我没有硬搬任何一套开源方案，而是把每个值得借鉴的部分结合浏览器环境改造后再使用。

如果说第一周学到的是“遇到阻塞要及时沟通”，那么第二周学到的就是：能跑起来只是开始，能够在限制条件下稳定运行，才是真正的工程能力。

第二周的关键词是：落地、适配、降级。

对我来说，这不仅是一张证书，更是一次走进企业技术实践场景、了解 AI 与小程序开发结合方式的难得机会。

从“学习技术”到“完成项目”

在学校和日常训练中，我接触得更多的是编程语言、算法题和个人项目。参加营地后，我更加关注一个完整应用是怎样从想法走到实现的：不仅要考虑技术能不能完成，还要考虑功能是否真正解决问题、用户是否能顺利使用，以及作品能否被清楚地展示出来。

AI 小程序开发把两个我非常感兴趣的方向连接在了一起：一边是人工智能能力，另一边是离真实用户很近的小程序应用。技术只有被放入具体场景，才会从“会使用的工具”变成“能够解决问题的产品”。

四天带来的改变

四天时间并不长，但集中式实践让我再次感受到，学习效率不仅取决于掌握了多少知识点，还取决于能不能快速理解任务、拆解问题并完成交付。

这段经历也让我更明确了接下来的学习方向：

1. 继续提高把 AI 能力落地为真实产品的能力。
2. 不只关注功能实现，也要关注用户体验和应用场景。
3. 学会在有限时间内判断优先级，先完成可用版本，再持续迭代。
4. 通过复盘和输出，把短期活动中的经验沉淀为长期能力。

一次企业实践，也是一份荣誉

这次结营认证代表我完成了营地设置的全部学习环节，但它不是终点。真正重要的是把营地里形成的产品意识、实践方法和解决问题的习惯，带回到之后的 AI 项目与学习中。

从腾讯 Mini鹅深圳营地，到之后参与更真实的 AI 项目开发，我正在逐渐从“喜欢编程”走向“尝试用技术做出真正有价值的东西”。

项目详情可以访问：腾讯营地官网。

这次经历的关键词是：实践、产品、成长。

本周完成

1. 完成堡垒机接入配置。
2. 完成 Token 接入与相关权限申请。
3. 初步接手并熟悉 AI 翻译项目。
4. 了解公司的组织架构以及不同职位的职责定位。

遇到的问题及解决方式

在配置堡垒机和 Token 时，因为权限尚未开通，暂时无法正常接入。

发现问题后，我及时向老师反馈，并在老师的协助下完成了权限开通。这个过程让我更加清楚：进入真实的企业研发环境后，除了写代码，还需要熟悉权限、协作和内部流程；遇到阻塞时，也要及时沟通，避免问题长时间停留。

下周计划

1. 深入理解并完善 AI 翻译项目的功能开发。
2. 将项目部署、上传至堡垒机。

本周收获与感想

入职一周，老师带我们快速了解了公司的组织架构和各岗位的职责定位。在实际操作中，我遇到了权限接入问题，也逐渐开始熟悉企业项目的工作方式。

这一周也让我意识到，自己在技术细节上还有不少欠缺。接下来要加快学习节奏——菜就多练，争取早日具备独立承担模块开发的能力。

自媒体更新

在完成实习适应和项目学习的同时，我也继续更新自己的自媒体，记录这段从竞赛训练、AI 开发走向真实企业研发的成长经历。输出不仅是分享，也是一次重新整理和复盘。

第一周的关键词是：适应、沟通、学习。下一周，继续向真正的项目开发迈进一步。

不知不觉已经 16 岁了。回想过去的一年，最让我有成就感的事情，莫过于完成了那个 基于计算机视觉的智能环保分类垃圾桶 项目。

起初，我只是想在桌面上放一个能“自动张嘴”的垃圾桶，觉得这样很酷。但随着想法的深入，我开始思考：既然学了 Python 和 AI 相关的知识，为什么不让它变得更聪明一点呢？于是，这个全栈 AI 项目的构思就诞生了。

踩坑与挑战

1. 算力瓶颈与模型轻量化

刚开始，我直接套用了 ResNet50，结果在树莓派上跑起来简直是灾难——一秒钟一帧都不到。看着垃圾桶迟钝的反应，我意识到在端侧部署 AI 并不是简单的 API 调用。 后来，我查阅了大量资料，尝试使用了 MobileNetV2，并进行了模型量化（Quantization），最终把推理速度提升到了可接受的范围。

2. C++ 与 Python 的混合双打

为了榨干硬件的最后一丝性能，我决定用 C++ 来重写视频流的拉取和硬件控制模块，而 Python 则专注于 AI 推理。如何让这两种语言高效通信？

• 尝试过 Socket 通信，但延迟不稳定。
• 最后使用了共享内存（Shared Memory）和本地 C++ 扩展（Pybind11）的方式，完美解决了数据传递的瓶颈。

收获

当你写下的代码能够控制物理世界的机械臂，当你训练的模型能够准确认出一个塑料瓶，那种感觉是纯粹的软件开发无法比拟的。

16 岁这一年，我不再满足于做算法题（虽然 NOIP 还是得继续卷 😂），我开始渴望构建真正的、有用的系统。

继续前行吧，向着改变世界的那一行代码！🚀