AI员工的核心是可验证的流程资产
主要观点
一套可落地的“AI员工”方法：先把业务经验从聊天记录中剥离，整理成项目规则、Skill、脚本、知识库和验收器，再让职责单一的Agent按需读取、执行、测试并回写。B站内容工厂案例进一步用飞书派单、Git回退和回归测试串起多Agent协作。它最有价值的提醒是，自动化质量取决于流程资产是否清晰、可审计、可验证，而非模型是否足够强；与此同时，完全访问权限、Cookie和外部工具链不能被当作无成本配置。
关键要点
- 项目文件承担“员工手册”功能：新对话没有历史记忆，必须先读取身份、职责、流程和验收标准；重要规则若只留在聊天记录里，会因上下文变长而逐渐失效。
- 一个项目最好对应一类稳定职责。代码、规则、材料和产物会持续沉淀，混入无关任务容易造成职责漂移与规则冲突，削弱长期执行的一致性。
- Skill采用按需加载：先判断触发条件，再读取SKILL.md、参考资料和模板，调用脚本、CLI或MCP，完成语义判断后运行验证器，避免把全部规则一次性塞入上下文。
- 项目目录偏向执行环境，保存规则、脚本、验证器、配置与任务记录；知识库偏向长期档案，保存原始资料、历史产物、主题索引和审核结论。规模扩大后应先读总索引，再定位主题文件并更新状态。
- B站案例将硬编码分段逻辑替换为Agent语义判断，并加入归档验收器、7项回归测试和来源清单；真实冒烟测试获取421条字幕，两个既有归档显示0 errors、0 warnings。
- 飞书表格被用作多Agent之间的任务队列和控制台，可定时扫描、执行并回写状态；但示例同时开启Codex完全访问权限，并处理Cookie、CLI及第三方插件，权限边界需要单独设计。
建议带着这些问题阅读
- 哪些判断应交给Agent做语义处理，哪些规则必须写入脚本或验证器，才能避免新的隐性硬编码？
- 多Agent通过飞书任务台串联后，如何设计失败重试、并发冲突和人工复核机制？
- 在不开启完全访问权限的前提下，能否通过目录白名单、凭证隔离和最小权限完成同样的工作流？