看一个典型的交接场景：开发用AI完成了代码，在群里说“做完了”。测试接手时，还要找最新需求、确认测试环境、询问这次改了什么。产品随后验收，又要核对页面对应哪个版本。
代码写得更快，后面的确认仍可能照常发生。个人省下的时间，未必等量缩短团队交付周期。
我们正在一个十几人的产研团队里，整理数字员工参与协作的工作方式。现阶段，整体方案和沟通材料已经成形，岗位套件有现成基础，新增的跨平台链路仍需接入与验收。这里想展开的是这轮已经确定的设计，以及它怎样改变各岗位的交付要求。
一个人完成以后，谁来接着做
我们把这次要处理的问题归为三个方面。
首先是协作推动。一个人完成操作后，下一位未必知道自己可以开始了。即使群里发过通知，也可能缺少接手人、前置条件或仍待处理的问题。项目负责人还得逐个问，再把结果转述一遍。
其次是信息同步。需求在文档里，分支和代码在工程平台，测试结论在报告里，最新决定又可能留在聊天中。每个角色进入任务时，都要重新拼出全貌。这里消耗的不只是查找时间，还有判断“这是不是当前有效版本”的时间。
再往后是经验复用。设计师知道某种交互该怎么处理，开发知道某个组件有什么限制，测试知道哪些边界容易出问题。这些经验即使被说过，也未必进入其他人的工作方法。下一条需求来了，大家仍可能从头解释。
这三个问题把我们引向了不同的改造：通过话题推动交接，通过需求关联信息，通过团队Skill（供AI调用的方法与资源包）沉淀方法。数字员工要参与其中，前提是这些关系和规则先说清楚。
用需求和话题组织协作
我们选了两个组织核心：需求，以及它绑定的飞书话题。
需求负责组织交付依据。需求多维表中的一行记录，关联主需求文档、交付话题、需求主Issue（承载交付的工程工作项）、开发者和主分支；缺陷、测试用例、多轮报告和部署记录再按需关联。靠稳定ID定位，避免凭相似标题猜对象。
话题负责承接围绕这条需求的沟通。讨论、正式确认、关键结果和接手事项，尽量留在原话题中。后来加入的人可以沿着同一条线了解发生过什么，不用在几个临时群里找结论。
原始内容继续留在各自平台。飞书保存正式文档与沟通，GitLab保存工程和缺陷记录，测试平台保存用例与报告。需求表保存关联，话题说明结果与下一步，不要求把代码、长日志和完整文档再复制一遍。
我们也给Skill明确了读取顺序：先读正式需求文档和任务相关材料；需要了解讨论，或文档有歧义时，再补读绑定话题。文档与聊天冲突，就把差异交给负责人确认。最近一条聊天，不能因为时间新就自动覆盖正式要求。
这样安排后，专业工作仍在各岗位的AI工作端和原平台完成。小智通过需求关联找到相关结果，在话题里承接请求和跟进协作。它需要知道自己能读什么、能执行什么，以及哪些决定必须交给人。
沿着一条需求看交接
我们在沟通材料里用了“导出结果提示优化”作为虚构示例。它用来解释工作方式，不是一次已经完成的上线案例。
假设用户导出数据后，只看到一句笼统提示，无法区分成功、部分失败和全部失败。产品需要先明确三种情况各自表达什么、用户能做什么，以及怎样算满足要求。
产品把规则和验收标准写进正式文档，关联静态页面。进入交付后，这条需求有自己的唯一话题。接下来发生的讨论和结果，都能回到这个入口。
开发在Codex团队Skill中领取需求、实际获取并绑定主分支。话题里的领取结果应包含开发者、需求主Issue、分支和开始时间。重复查询时返回已有分支，避免同一需求被重新创建一套工程对象。
开发完成正式自测、合并请求（MR）进入待评审，或者当前版本的持续集成检查（CI）失败及恢复时，再同步需要接手的信息。普通提交和正常CI成功不逐条广播。我们希望话题里的消息能帮助别人行动，而不是让机器人把工程日志重新发一遍。
正式提测要另有明确动作。开发需要交出本轮自测和核心用例依据、测试环境（TEST）及实际部署版本，满足条件后才进入待测试；测试本人领取后，才进入测试中。只说“代码提交了”，还不足以让测试开始。
测试发现的问题先核实，再建立关联缺陷。修复交回时，要能确认这次验证的实际版本。单个Bug关闭，也不能替代整条需求的测试结论。
整体测试通过，并且对应的预发布环境（PRE）部署与核心检查齐备，才交给产品验收。产品明确通过后进入待发布；实际发布和线上验证完成，再由有资格的负责人登记上线。
这条链里，每次交接都要回答几个具体问题：本轮交了什么，对应哪个版本，有什么结果依据，谁能继续。状态和通知只是这些事实的表达，不能反过来替代它们。
岗位经验要形成别人能用的资产
设计分工时，我比较在意的一点是：只把岗位职责重新写一遍，变化仍然很有限。
UI本来就要维护规范，开发本来就要保证代码质量，测试本来就要给出结论。这次增加的要求，是把专业经验做成可维护的Skill资产，让其他角色在工作时直接使用。
这里的Skill，可以理解为AI执行任务时读取的一组方法、规则、模板和工具用法。它还可以引用设计规范、组件文档和工程脚本。团队需要维护的是这套可重复使用的工作方式。
以UI设计为例。我们希望设计师把规范写清，并推动开发完善标准组件；组件代码由开发维护，使用方式和示例则提供给Skill引用。
产品据此生成高保真静态页面，交UI检查规范和体验，微调确认后交开发。默认路径里可以跳过独立设计图的交付，把已经确认的静态页用于后续工程实现。产品仍需说明业务规则和验收标准，开发继续处理真实数据、权限与异常，测试独立验证。
这要求规范有足够具体的内容。例如表单出错怎样提示、无权限时页面如何表现、组件哪些属性可以调整。只放几张示意图，产品生成时仍要猜，开发实现时也会各自理解。
资产的Owner还要负责维护。规范由UI确认，组件代码由开发负责，业务要求由产品确认，验证标准由测试维护。AI生成的内容，需要经过相应角色的质量检查。
同时要分清共用方法与单条需求的事实。正式需求、代码和报告留在原平台；Skill保存可复用的规则、模板与资源入口。某次需求的特殊处理，不能未经复核就变成所有任务都执行的通用规范。
小智怎样参与这套工作方式
在这个设计里，小智有三类职责，发起方向也不完全一样。
信息收集由团队成员发起。例如：“@小智，整理这个需求的最新情况。”它应该按需求找到正式材料、当前负责人、分支、报告和有效决定，附上来源；权限不足或关联缺失时，就说明缺口。项目、人员、观测和业务数据等公共接入，供岗位Skill与小智共同使用。
协作执行也由成员明确发起。例如从讨论整理需求草稿、关联材料、记录缺陷或请求更新状态。小智需要核对身份、资格、阶段和前置依据，再调用已接入工具，并查回实际结果。真正的本地分支获取、编码、专业测试和部署，仍由岗位工作端及原平台承接。
项目跟进则需要小智按约定主动找人。它关注需求停在哪、缺什么、需要谁协助，以及下一位是否具备接手条件。已有阻塞时，应该跟进所需协助；缺少可信记录时，要提示信息缺失，不能直接判断某个人没有工作。
这些都是我们要逐项落实的职责。图里画了一个入口，并不意味着所有请求已经能执行。接入时还要验证工具、权限、真实返回和异常处理。
团队知识和长期记忆放在后续建设中考虑。文档与规范可以形成可检索的正式知识；排查经验、决定依据和协作习惯，需要带来源、适用范围，经负责人复核后再沉淀。知识可以辅助判断，当前需求的状态和版本仍要回查原平台。
先交付可用能力，再在使用中改进
目前，我们已经把整体协作思路、岗位资产方向和关键交接约定整理为沟通材料，完成了内部网页。产品、研发、测试套件也有源码和方法基础，但还需要按共同规则适配，不能把材料完成当成业务链路已经跑通。
下一步的交付分成两类。一类是岗位Skill与插件：给出入口、适用场景、输出标准和真实样例，让团队完成体验和确认。另一类是配套接入：需求关联、工程和测试结果回传、异步补采、失败恢复、Jira兼容同步等，分别定义需求、开发和验收。知识与记忆存储单独安排，不与当前链路混成一个大任务。
技术负责人需要先说明工程操作和部署依据，测试负责人明确覆盖与结论要求，产品和UI整理业务、验收与设计资产。研发实现接入，测试及使用方核对结果。每一项都要有明确Owner、依赖和完成证据。
有些验收问题很具体：如果代码提交成功，写表失败，下次恢复应当只补写表，不能再提交一次。报告回来了，但环境或版本不对应，也不能据此继续交接。这些处理需要落在程序和记录里，不能指望模型记得上次做过什么。
交付完成进入使用阶段后，工具可能仍有缺口。人要按共同约定补材料、做确认、推动接手，并留下临时处理方式。每周把真实问题收集起来，由对应Owner修订规则、研发更新套件，再由测试和使用者验证。
后续我会优先关注交接等待、材料缺项、同步失败与恢复、返工原因。这些记录能帮助我们判断：信息是否更容易找到，交接是否更完整，哪些工作方法仍需调整。等有了可比较的交付样本，再讨论团队效率究竟改善了多少。