前言

首先还是感谢发帖方提供这次实践机会。这个项目让我更清楚地认识了自己的能力边界，也让我对现阶段 AI 编程有了更现实的判断：模型可以显著放大检索、编码、排错和迭代能力，但在医学教学这类高专业门槛、错误代价较高的跨领域任务中，它仍更适合作为辅助工具，而不能替代领域知识、业务验收和责任主体。对于缺乏相关行业经验的人来说，仅凭模型和 Harness，还不足以把“能够生成一个作品”直接转化为“能够独立承接并交付专业项目”。

（此文由GPT5.6SOL撰写，它缺少了一开始我使用Hermes + deepseek v4 Flash 迭代时候的上下文）

本项目来自论坛的 “AI 产品溢出产能回收计划——任务一”。2026 年 7 月 15 日，发帖方公开宣布将任务交给我；到 8 月 16 日决定收口，前后约一个月（按自然日约 32 天）。

原任务帖已经有一套公开规则，并不是完全没有约定：佣金为 100 美元，承接方可以提出有数据支持的新价格，最高可谈至 2000 美元；验收人为发帖方本人，争议可由符合资格的第三方裁定。7 月 21 日，发帖方又公开说明任务一带有尝试性质，因此没有限制工期；项目交接后会发布支付截图，并允许开发者反馈难点和解决思路。

但这仍不是一份签字盖章、逐项列明里程碑和验收用例的服务合同。公开任务只是框架，真正的医学材料、具体工作流和质量期待在私聊交接后逐步展开。本文不打算追责某个人，也不准备证明谁对谁错，只想按发帖方此前提出的要求，在不公开业务机密和医学原始材料的前提下，说明项目为什么越做越大、最终做出了什么、为什么仍未被采用，以及实际投入。

合作前期，对方曾明确表达愿意共同试验，也提供过方案判断和鼓励；后期则因为认为成片与手术教学要求差距较大、继续指导也会占用其时间和金钱，决定退出。两种表态放在不同项目阶段都有其现实原因，但也说明：没有书面范围、责任分工和验收标准时，双方对“共同折腾”的理解很容易不同——一方可能理解为共同迭代，另一方可能只愿意在较短周期内验证可行性。

文中涉及的样本和人员均做匿名处理。视频只应视为技术原型，不构成医学结论，也没有经过医学权威验收。

这不是偶尔抽空做了几次测试，而是跨越一个完整订阅周期的持续开发、运行、审片和纠偏。

一、公开任务、私聊交接与实际开发并不是同一个范围

公开任务帖中的要求相对直接：用六阶段纸质扫描图片和文字说明，制作 ComfyUI 自动化生产工作流，把六阶段图片转成六阶段课件动画；环境为 Linux/NVIDIA，交付工作流 JSON 和手机录制的生产过程视频。发帖方还表示自己已经在 Windows 上跑通过一份工作流（机智罗LTX2.3工作流），可以提供现成脚本。

如果项目始终停留在这个边界，它更像是“把既有 ComfyUI 工作流在指定环境跑通并调整输出”。但后续迭代中，项目目标开始发生漂移。甲方原意是提供一套运行于 Kimi 云端环境的 Skill 供我参考；我方在将其与既有成果整合时，又逐步把目标扩展为完整本地化，并加入“运行时只输入图片和脚本、不依赖在线 AI 或历史资产、同一入口回归 V15/V16/V17”等约束。这个扩大过程是双方沟通、我方技术判断与 Agent 方案共同作用的结果，不宜简单归于任何一方。

这次 scope change 没有同步形成新的报价、里程碑和医学验收表，成为后续治理失衡的起点。

二、最初的技术方案其实也很明确

甲方提供了一套运行在 Kimi 云端环境中的“分步医学示意图转动画”Skill。最初需求并不是重写整套系统，而是做本地化：

• 输入端增加本地多模态模型，负责识别整页图片中的面板、标记和动作对象；
• 中间由本地大语言模型把脚本转为动画规划和提示词；
• 主动画仍由本地图生视频模型生成；
• 输出端再增加本地多模态质检，检查生成片段并决定是否重试；
• OpenCV 和 FFmpeg 只作为保底路径；
• 运行时只输入一张图片和一份脚本，数据不出公网，全流程自动完成。

当时设计的是一机三卡：RTX 3080 Ti 跑 Qwen2.5-VL，RX 7900 XTX 跑 Qwen 文本规划，另一张 RX 7900 XTX 跑 ComfyUI/LTX 图生视频。概括起来，就是在原管线“前后两头”补上本地 AI 感知与审核，中间尽量沿用既有 Skill。

最初的 POC 其实并非完全失败：面板识别、JSON 输出、动作原语规划和本地 LTX 出片都曾跑通。原 Skill 的一次盲测记录中，使用 Skill 约 20 分钟，优于约 100 分钟的 baseline；另一次约 8 分钟的 Skill 结果则因 float 动作过弱，输给约 15 分钟的 baseline。这说明最初路线有明显效率潜力，但稳定性不足。很快又暴露出几个实际问题：低分辨率面板直接送入图生视频导致画面发白、动作像 PPT 平移、复杂面板漏检，以及生成耗时较长。尤其在本次匿名化医学示意图样本中，LTX 对“小尺寸、离散、数量必须准确”的缝线对象不稳定：要求增加少量缝线时，模型可能把它扩增为大量无关的重复线条并散布到画面其他区域。这个问题后来没有继续靠提示词硬压，而是把逐条擦除和恢复改为程序化渲染。

三、路线后来是怎样一步步改变的

1. 从“本地图生视频为主”转向“程序化能力补丁”

为了补救 LTX 不擅长的精细动作，项目开始从旧管线中移植超分、抠图、clean plate、路径描画、器械演员、组件擦除与恢复等模块。此时架构已经不再只是替换云端 API，而是同时维护生成式视频和程序化渲染两套能力。

2. 从“先出视频再改”转向“先证明每一层都无歧义”

在尝试把 V15、V16、V17 三个历史成功案例统一到一条入口时，系统逐步加入大量 fail-closed 门：面板拓扑、标签归属、像素 ownership、动作证据、mask 权威、组件生命周期、历史能力等价、自动 QC、候选资产和 Compile 前预检等。

这些门中有不少是合理的，尤其项目涉及医学教学，不能把错误动作包装成通过。但治理上出现了明显失衡：每遇到一次失败，就增加一层证据协议、状态分类或审计记录；很多完整运行在 Renderer 和 FFmpeg 之前就停止，导致数天内不断产生 JSON、日志、委员会意见和 SHA，却长期没有新视频可供 1.0× 审看。

期间遇到过的典型阻断包括：

• Qwen3.6 子进程因显存分配失败退出，外层 API 仍存活，形成“models=200、health=503”的假健康表象；
• 请求上下文膨胀到约 8.7 万 token，超过 3.27 万上下文上限；
• 本地模型返回截断或非法 JSON；
• OCR、panel label、candidate ownership 和 relation graph 无法唯一绑定；
• source mask、clean plate、缝线组件族和动作角色在不同阶段之间缺乏统一权威；
• 验证器本身也出现过假阳性，例如几何分母符号错误、把 clean plate 的纹理基线误判为残留。

最终，工程的主要精力逐渐从“提升成片能力”转向“证明系统为什么不能继续”。这正是本项目最值得复盘的地方。

3. 从“复杂统一生产管线”切换到 Hermes 的 video-first 路线

在旧路线多次无法产生候选视频后，甲方建议改用 Hermes Agent 接入本地多模态模型，并让 Hermes 理解、改造原 Skill。新路线明确压缩前置门槛：只要输入仍是当前图片和脚本、所有感知在本地 fresh 生成、没有读取历史坐标/mask/计划/视频或样本 Oracle，就优先产出带诊断性质的完整 MP4，再由人按 1.0× 提意见。

这条路线很快生成了第一条 V16，随后修正脚本解析和 panel binding，生成了 V15、V16、V17 三条视频。后续几轮又逐步加入或恢复了：

• 从左到右的划线与切割顺序；
• 笔、手术刀、注射器、针线等程序化器械演员；
• 局部抠图和平移；
• clean-first 与逐组件恢复；
• V16/V17 的缝线逐条出现；
• 关系箭头、字幕、面板绑定和终态恢复。

到了最后，实际主路径已经与最初设想明显不同：

最初是“本地 VLM + 本地 LLM + 本地图生视频，前后两端加审核，OpenCV 只兜底”；最后变成了“Hermes 编排本地模型，重写 Skill，把 OpenCV/FFmpeg、mask、器械演员和生命周期模块作为主动画引擎，生成式视频退出关键路径，并大幅压缩前置审核门”。

换句话说，这不是在原管线两端增加两个模型，而是事实上重写了一套以确定性合成为主的动画系统。

四、最后真正做出了什么

最终冻结包中有三条由同一入口、同一套代码生成的审片视频：V15、V16、V17，均为 1920×1080、30fps、H.264/AAC，并附带 Manifest、时间线图、Skill 包、代码 SHA 和使用说明。

从纯工程角度看，以下目标已经达到：

• 本地离线运行；
• 运行时只换图片和脚本；
• 三个样本能由同一入口生成完整可播放视频；
• 程序化动作能力可以被组合；
• 产物、代码和输入之间有基本可追溯性。

冻结时，交付包状态是“等待甲方 1.0× 审片”。实际发出后，甲方认为手术教学逻辑存在系统性偏差，并非换模型或修改两三个视觉细节就能解决，因此没有接受当前版本。我们内部对最后一版的判断更接近“视觉原型约 80 分”，而甲方关注的是“能否作为手术教学材料”。这两套评分标准并不等价。

因此，当前真实结论是：

• 技术原型和三样本演示存在；
• 三样本在视觉形式上实现了一定程度的统一；
• 医学真值、教学顺序和临床安全性没有得到专业权威闭合；
• 不能把它包装成已经合格的医学教学产品。

五、项目治理为什么失控

我认为这次失败不宜简单归因于“模型不够强”或“甲方要求太高”，更大的问题是项目治理与委托能力不匹配。

1. 非专业委托方很难及时识别路线偏移

我是以结果为导向参与，希望尽快看到视频，再按画面提出问题。但当 Agent 开始不断扩充后端、状态机、审计门和证据协议时，一个不熟悉软件架构的人很难判断：哪些是医学项目真正必要的安全措施，哪些只是为了让下一次 fail-closed 更容易解释，哪些已经偏离了“尽快形成可审片成片”的目标。

结果是，每次单独看都有技术理由，累计起来却形成严重的投入产出倒挂。

2. 审核门没有和客户可见价值绑定

项目曾同时区分 technical、action temporal、human 1.0×、historical capability equivalence、medical truth、client candidate、production 等状态。这种分层本身并非错误，但没有一条强制规则要求：每投入若干小时，必须产出一条可播放的 diagnostic MP4；新增一个硬门，必须说明它能避免哪类客户可见错误，以及不增加它会造成什么具体风险。

于是出现了“过程越来越严密，视频反而越来越少”的倒挂。医学安全需要硬门，但硬门不能替代产品迭代，更不能让静态检查、委员会意见和自动 QC 冒充真实审片。

3. 多 Agent 与委员会放大了协调成本

主 Agent、监督 Agent、子 Agent 和委员会可以减少单点误判，但也会让责任边界变模糊：一个 Agent 负责设计，一个负责审核，一个负责状态归因，最后没有人对“今天必须让用户看到什么”承担唯一责任。

当系统把大量 token 用于互相解释、复核、改名和追加审计时，模型看起来一直在工作，客户可见产出却可能为零。

4. 缺少早期止损与变更控制

原始任务是本地化 Skill，后来演变为像素级资产系统、结构化事务协议、全局图绑定、生命周期验证和程序化手术动画引擎。每一次扩展都有局部合理性，但缺少正式的 scope change：谁批准、增加多少时间、用什么结果验收、失败后退回哪里。

对小预算项目而言，这种无边界研发比单次技术失败更危险。

六、为什么另一个“完全放手”的项目成功，而本项目没有

论坛里还有一篇值得对照的成功复盘：《零代码编程小记——一次完全放手的 Vibe Coding 心路历程》。该作者把人的角色分为“董事长、总监、组长”，并认为只给业务目标和验收标准、让 AI 自己决定技术实现，是当前性价比最高的模式。

我赞同这个结论，但前提是人必须真正有能力定义业务正确性。成功帖中的数据工具，可以用加载时间、分页完整性、去重、错误恢复、报告结果等客观测试定义成品；业务负责人也能直接判断数据是否符合用途。因此，AI 即使自由选择技术路线，最终仍被稳定的业务测试约束。

手术课件不同。程序能否运行、视频能否播放、mask 是否闭合，都不等于手术逻辑正确。如果委托方没有在开工前把术式顺序、器械方向、组织关系、可接受的视觉简化和禁止表达写成逐项验收用例，而开发者本身又不是医学专家，那么 AI 只能不断为“代码内部的一致性”写测试，却无法替双方定义“医学上什么是正确的”。

这也解释了本项目最反常的一幕：我们后来拥有上百个命名运行和大量技术 PASS，最终仍被一句“手术逻辑错误较多”整体否定。不是测试没有写，而是大量测试定义的是代码合同，不是最终业务合同。

成功帖还强调“模型决定质量上限，Harness 决定做事风格”。本项目也验证了模型升级确实能改善识图、规划和排错，但医学真值不在任何通用模型的上下文里。更换 Qwen、Kimi、Grok 或新的 Harness，可以提高执行质量，却不能自动补上缺失的专业验收责任。

成本数据也不能机械对比。成功帖公开了 99 个会话、约 2500 万输入 token，按 OpenCode Go 额度折算后 AI 成本约 6.1 美元，并估算人的注意力投入为 16–24 小时。本项目没有覆盖全程的统一 token/会话计量，不能编造一个同口径数字；现有记录只能证明其中一个 local-pixel 冲刺就估算投入约 27.5 工程小时，而整个项目持续了约 32 天。低价订阅能降低调用成本，却不能消除需求不清、领域验收缺位和反复返工的成本。

所以本项目真正的教训不是“完全放手一定不行”，而是：只有当业务负责人能写出并持续执行产品级验收时，才有资格完全放手；否则，放手只是把未定义的正确性交给模型猜。

七、到底写了多少“版本”，堆了多少工程量

工作区没有完整可用的 Git 历史，因此无法严谨地说“总共发布了多少个独立代码版本”。下面只能给出可复核的下限，而不能把每个日志目录都冒充正式版本：

• V17 的 audit 目录下一级有 101 个审计/运行目录，其中 95 个名称带有 round、R 或 longrun 标识；
• Hermes video-first 阶段另有至少 8 份明确命名的 baseline、repair round 或 delivery 记录；
• 因此，可追溯的命名迭代/运行产物已经超过 100 个，但它们并不等于 100 套完全独立的程序；
• 仅 V17 与 Hermes 的主要源码、实验脚本和测试目录，就有至少 269 个 Python 文件、约 115,875 行；
• 若把同范围内其他脚本类型也计入，则约 318 个代码文件、126,860 行；
• 最大单文件 core.py 约 12,933 行。

磁盘规模同样能反映问题：

• 当前整个项目工作区约 62GB；
• V17 约 50GB，几乎全部集中在 V17/audit；
• V17/audit 内约 64,136 个文件，其中约 4,706 个是 JSON、Markdown、文本或日志；
• Hermes 整个 POC 工作区约 604MB；
• 真正给甲方的最终压缩包只有约 11.2MB、23 个文件。

远端也曾因为把 V17/audit、逐帧图片和旧输出重复同步到每个 retry 目录而塞满：/mnt/secure 从约 173GB、100% 使用，清理后降至约 15GB、9%，释放约 158GB。这部分大多是临时审计和重复产物，并没有直接转化成最终交付能力。

这些数字不能简单理解为“所有代码都没用”。其中确实沉淀了 mask、器械演员、时序、渲染和审计能力。但从小预算交付角度看，工程体积与最终 11.2MB 交付包之间的差距，足以说明研发路线发生了严重膨胀。

八、现金投入与隐性成本

以下金额按实际购买情况列示；美元项目最终人民币扣款仍应以银行卡账单和当日汇率为准：

• ChatGPT Pro：200 美元/月（OpenAI 官方说明）；
• Ollama Pro：确认按月付费，并在官网支付过一次 20 美元（Ollama 官方价格）；
• OpenCode Go：本次实际支付 5 美元（OpenCode Go 官方说明）；
• SuperGrok 年费：印度区促销期间，通过购买面值 6500 的 Apple Store 点券支付，点券实际花费人民币 461.37 元；
• Ollama Pro 另有一次闲鱼代充，实际支付人民币 80 元。约使用一周后，在确认收货之后，该 API key 开始返回 HTTP 403。现有证据不足以判断是密钥、账号、代充渠道还是服务策略导致，因此这里只记录时间顺序和实际损失，不对责任方作结论。

项目周期从 7 月 15 日持续到 8 月 16 日，基本覆盖一个完整项目月。能够确认的订阅及充值支出合计为：

• 美元支出：ChatGPT Pro 200 美元＋Ollama Pro 20 美元＋OpenCode Go 5 美元，合计 225 美元；
• 人民币支出：SuperGrok 点券 461.37 元＋Ollama 闲鱼代充 80 元，合计 541.37 元。

也就是说，当前可确认的现金投入是 225 美元＋541.37 元人民币，尚未计入税费和换汇手续费。若只为便于阅读、按 1 美元约合 7.1 元人民币粗略换算，总额约为 2139 元人民币；这不是财务结算汇率，准确金额仍以支付账单为准。如果部分会员同时用于其他事项，也可以在讨论项目净成本时按使用比例另行分摊。

以上仍没有计入：

• 本地 3080 Ti 与两张 7900 XTX 的折旧；
• 连续推理、渲染和转码的电费；
• SSD/存储占用和远端清理成本；
• 数周沟通、审片、纠偏和重新授权的时间；
• 从 7 月 15 日到 8 月 16 日约一个月的持续项目占用与其他机会损失；
• 为项目占用的订阅额度和机会成本。

原任务帖明确列出的基础佣金是 100 美元，同时允许承接方提供理由和数据后重新报价，最高可谈至 2000 美元。但本项目发生重大范围变化后，双方没有重新锁定价格。换言之，即使按最保守的订阅价格计算，实际投入也已高于基础佣金；若最终不结算，直接现金回报为零。

以上费用是我为推进和尝试项目主动发生的个人投入，仅用于复盘投入产出，不等同于要求甲方逐项报销或当然承担。

九、如果重来，怎样避免同样的问题

如果同类项目重新开始，我会采用完全不同的治理方式：

1. 先签清楚验收标准。 医学动作、字幕、时序和画面美术分别由谁验收，必须在写代码前明确。
2. 医学内容必须有专业责任人。 AI、程序员和通用视频审核都不能替代临床或教学专家。
3. 第一天必须出 diagnostic MP4。 除数据泄露、程序崩溃和明显安全风险外，其余问题先进入带水印诊断片，由人审片后排序。
4. 每轮只解决 2–3 个最高价值缺陷。 不在同一轮扩展新的架构、状态分类和审核委员会。
5. 硬门要有客户价值说明。 每新增一门，都要回答它避免了哪个可见错误；不能回答就先不加。
6. 强制 scope change。 从“本地化现有 Skill”变成“重写动画系统”时，必须重新报价、重新排期、重新确认是否继续。
7. 设置代码和审计预算。 例如代码超过一定规模、审计产物超过 5GB、连续两轮没有新 MP4，就自动进入架构复盘或止损。
8. 三样本通过只代表有限域回归。 不能把 V15/V16/V17 三个样本跑通直接宣传为对未知医学课件具备通用性。

十、最终态度

这次项目不是“什么都没有做出来”。我们确实完成了本地化探索、三套历史能力梳理、程序化动画模块、同入口三样本视频和一套可运行的 Hermes Skill 原型。

但也不能因为投入巨大，就把一个未通过医学教学逻辑验收的原型说成合格交付。沉没成本不能替代质量结论。

所以我的收口方式是：保留三版资料、对应视频、统一入口、代码与 SHA，完整说明已知限制；是否付费、付多少由对方根据实际可用价值判断。项目不再继续无预算扩张。如果未来还有合作机会，应当以新的范围、医学审核责任、预算和验收合同重新开始，而不是在这座已经膨胀的工程上继续叠加。

这篇复盘最想留下的一句话是：

AI 项目最危险的，不一定是模型不会做，而是每一次局部合理的“再加一层”，最终把一个需要尽快交付的视频任务，变成了没有人能及时叫停的研发系统。

本机 OpenCodex 最近30天的使用统计：约5.22万次请求、90亿 Token，按公开 API 单价估算的等价价值约4257.95美元。项目接入后，本机工作主要围绕该项目展开；按个人使用记录估计，其中约80%–90%与本项目有关，但平台没有按项目精确归因，因此该比例只能作为估算。这里展示的是模型调用强度和订阅杠杆，不是实际现金账单；实际付款仍以前文列出的订阅及充值费用为准。