假设两种行为分析方案都能在演示视频里给出结果。一种需要持续微调模型，另一种用已有识别工具、明确规则和人工复核。前者展示了更多可能，后者更容易说明每一步发生了什么。
哪一种更好，不能只看演示。交付给谁、要持续多久、允许怎样的错误、谁负责修正，都会改变答案。
我对“稳定可交付”的关注，并不是预先排斥新技术。我想把研究上有趣、工程上能运作，以及当前值得投入这几种判断分别讲清，再检查它们在哪里重合。
先定义交付的单位
一段能运行的代码、一份分析报告、一套下个月仍然有人会使用的流程，是不同交付物。
若客户要的是一次研究判断，搭建通用平台可能增加无关成本。若团队每周都要重复同一工作，只交付一份结果又可能留下最耗时的环节。
我会先把交付单位写成一段过程：谁提供哪些输入，谁在什么时间拿到什么，遇到不完整材料怎么办，最后哪一个决定因此获得支持。完成这一步，再讨论模型和框架，选择才有共同尺度。
这也能揭示一些伪分歧。研究人员想探索新的行为表征，项目负责人想按期拿到可复核结论，两人可能并没有在比较同一件事。可以把探索任务和当前交付拆开，分别设立成功条件。
成本应该沿着整个使用过程计算
模型调用和服务器费用比较容易看到，容易漏掉的是材料整理、质量检查、版本更新、错误恢复和交接。
以下只是决策时的记账框架，不是经过估计的成本模型：
总投入 = 建设 + 数据准备 + 运行 + 人工复核 + 故障恢复 + 迁移退出。
每一项都要指定时间范围和承担者。一种方法可能让分析师快一点，却让工程师每周处理环境问题；也可能让演示准备更简单，却增加最终报告的核查时间。只统计最显眼的一段，容易把工作转移误认作工作减少。
未知项不该随意填一个好看的数。可以先记录范围、依据和最敏感的条件：调用量翻倍后怎样，材料质量下降后怎样，关键维护者离开后怎样。下一次小试验应该优先缩小会改变选择的那项不确定性。
让候选方案面对同一组难题
我会保留一个足够简单的比较对象。它可以是人工流程、固定脚本或明确的规则，不一定是另一套 AI 系统。
对照时，不能只给各自最擅长的演示材料。至少需要正常输入、不完整输入、容易混淆的情境和超出预期范围的任务，并且使用相同的验收口径。
例如，对行为编码，除标签质量外，还要检查漏检、事件边界和复核时间。对研究简报，除文字质量外，还要检查来源能否回查、遗漏是否影响判断、每周更新是否需要重新指导。
Model Cards 提倡说明模型的用途、评价条件和局限，为报告这种适用范围提供了参考。它并不替我们证明某个模型适合当前项目。Model Cards for Model Reporting
我希望拿到的是“在这些条件下，它比当前方法多解决了什么”，而不只是“它能做出来”。
稳定不能成为永远不试新方法的理由
成熟方案同样可能留下结构性缺口。如果每次复核都要花大量时间，或规则始终无法区分关键事件，继续维护旧方案也有成本。
新方法值得试验的地方，是它有没有机会改变这个卡点。可以先限制材料范围、交付责任和试验周期，让它与既有流程并行，检查是否产生足够大的改善。
如果试验失败，要知道失败在哪个假设：输入不足、模型能力不够、集成不稳定，还是其实没有对应的使用需求。这样的结果能减少下一次投入的不确定性。只追求一次好看的演示，反而容易让失败的位置模糊。
我会给复杂方案增加举证要求，也会要求简单方案说明它放弃了什么。复杂与简单都不自动等于合适。
退出能力也是方案的一部分
如果一个组件不可用，工作能否以较低效率继续？输入和结果能否导出？另一位同事能否接手？更换模型时，哪些步骤需要重新检查？
这些问题不必导致一开始就做庞大的通用架构。最小的处理可能是保留原始输入、标准格式输出、版本记录，以及一条可执行的人工路径。
对还在探索的方向，这种可撤回性很有价值。团队可以尝试新工具，而不必把整个工作方式绑在一次技术选择上。
把“暂时不做”写成有条件的判断
一个方案当前不值得投入，不意味着它永远没有价值。更有用的说明是：还缺哪类数据，哪项成本需要下降，哪种效果需要先被证明。
我希望技术选型最后留下三样东西：当前为什么这样选，什么证据会改变选择，以及下一次检查发生在什么时候或什么条件下。
这与所有问题都是技术性问题的出发点相通。把约束展开，才有机会重新组织条件。也与自动化的人力负担相连：技术交付之后，仍然需要问使用者的工作是否真的改善。