TraeWork 多端协作：用手机也能高效办公

02我的工作是“点状”的，不再只发生在工位上#

如果要用一句话概括，我认为 AI 时代的工作应该是点状的，而不是面状的。过去，写文档、画 Demo、整理 PRD 都需要人长时间坐在电脑前；手机编辑体验不够好，所以我们离开工位后，顶多在飞书里回几条消息。

现在文档、PRD、Demo，甚至部分代码修改可以先由 Agent 执行，人更重要的动作变成下发任务、补充上下文和 Review。这样一来，工作不必等到我重新坐回电脑前才开始。

我白天有大量会议和沟通，需要不断从同事那里获得上下文。拿到信息后，我会把任务交给 Agent，让它在后台异步推进；有些长程任务会跑一个晚上，第二天再把结果交给我。我不会把整块时间都花在亲手写文档或代码上，而是用几个明确的时间点完成方向确认和验收。

我的白天工作可以是点状的，面状、耗时的执行则让 Agent 在背后完成。

03我用三个部分把工作流串起来#

1. 移动端随时下发任务

   竞品调研、AI 新闻、PRD、埋点文档和数据看板，都可以在手机上用语音快速交代。

2. 桌面端查看、接管与精修

   当我需要比较方案、编辑 HTML、检查复杂 Demo 或完成最终验收时，再回到 PC 工作台。

3. 办公助理承接长期上下文

   把常用模板、Skills、Rules、Memory 和办公渠道连起来，让任务能从飞书、微信等入口继续推进。

这三个部分不是三套孤立工具。手机负责降低任务启动门槛，桌面负责深度操作，办公助理负责让长期记忆和外部数据在不同入口间继续使用。

04在手机上，我通常直接用语音派活#

直播里我展示了一份移动端版本弹窗的 PRD。因为有业务数据，演示里隐藏或替换了敏感内容，但真实工作方式就是这样：我长按语音，说清楚这次想实现什么、现有资料在哪里、需要什么交付物，然后让 Agent 开始。

如果没有 Agent，一个很小的版本弹窗也要由我自己补齐需求背景、详细规则、corner case、版本范围和多语言文案。有移动端以后，我可以先用自然语言下发，TraeWork 再按照我提前准备好的 Skill 和 Rules 生成飞书文档。

竞品调研、AI 新闻、埋点文档和数据看板也是同样的节奏。我不会在手机上完成复杂排版，但可以在会议间隙、排队或通勤途中开始任务，途中查看它进行到哪里；一旦发现方向走偏，就暂停、补充资料或换一个方向。

直播当时，我也说明了移动端可以从应用商店搜索 TRAE，或从官网下载中心扫码进入。入口会变化，但使用原则不变：移动端先让工作动起来，桌面端再完成需要大屏和精确操作的部分。

05为什么一句话能交付：我先搭好了 Harness#

如果只把模型理解成一个聪明大脑，还不足以解释为什么我的一句口语任务能生成接近可用的 PRD。真正支撑结果的，是我围绕 Agent 搭起来的一整套 Harness。

我不会手写所有 Skill，而是让 Agent 帮我沉淀

以 PRD Skill 为例，我先给 Agent 看几份自己认为写得好的 PRD，让它分析共有结构、写法和检查项，再请它创建一份 Skill。Skill 生成后，我负责检查它有没有用，并拿新的真实任务验证。

我不是先学会完整的 Skill 语法，再从空白开始写。我的顺序是：先把做得好的工作样本交给 Agent，让它抽取工作流；我再校正、使用和继续迭代。埋点文档、数据看板等重复任务也是这样沉淀下来的。

当我在移动端说“根据这份需求生成埋点文档”时，它会调用我已经验证过的 tracking Skill，再从飞书读取对应资料。看起来只说了一句话，背后其实已经有工作标准和数据。

06Skill 之外，还要给 Agent 记忆和数据源#

长期协作最痛苦的事情，是我每天都要重新解释自己在做什么。为了解决这个问题，我会把数据分成不同来源：长期规则和偏好进入 Memory，当前任务资料留在项目上下文，飞书、Notion 或其他知识库通过插件按需读取。

我的“第二大脑”每天晚上整理一次上下文

我做了一个叫“第二大脑”的 Skill。每天晚上 10 点，它会遍历当天与 Agent 的对话，判断今天又了解了哪些关于我的新信息，再把值得长期保留的部分提炼进 Memory。

我希望达到的状态是：它知道项目进行到什么程度、我最终想达成什么、哪些偏好已经反复确认。这样我不在线时，它也能基于相近的上下文继续处理任务。当然，进入长期记忆的内容仍然需要我检查；错误或过期事实不能因为被记录下来就自动变成真相。

飞书里的“上班搭子”跟端内助理共享背景

我的办公助理打通了飞书等协作入口，并使用与 TraeWork 端内助理相同的上下文。同事给我转发一段消息时，我可以直接把它转给“上班搭子”；它知道相关项目和我的表达习惯，会调用已有 Skill 生成一版回复。我检查后，就能在飞书里继续沟通，不需要截图、复制，再换一个窗口重新讲背景。

Notion 和知识库可以成为外接大脑

我还会连接 Notion 或类似 Obsidian 的个人知识库。朋友曾分享给我一个包含数百篇交互案例的 Workspace，里面有 Apple、Airbnb 和大量 AI 产品的设计知识。如果靠我从头学完，成本很高；接成数据源后，我遇到交互问题时，可以先让 Agent 阅读对应知识，再作为专家搭子跟我讨论。

管理 Harness 看起来是在管理 Agent，实际上也是在重新组织我对自己工作的理解：哪些任务每天反复出现，哪些步骤值得沉淀，哪些知识应该长期保留。一个任务如果每周反复做三次以上，却始终没有形成可复用流程，它就会持续消耗时间。

07回到电脑后，我会接管 Demo 和生产细节#

我不会用移动端完成所有任务。手机屏幕太小，复杂 HTML、Demo 和视觉细节天然更适合 PC。我自己的 Work、Code、Design 任务也会严格分开：调研、文档和数据放在 Work；需要进入项目和代码时再到 Code；视觉探索则使用 Design。

我的 PRD 顺序也发生了变化：先 Demo，再补文档

过去常见流程是先调研、再写 PRD、最后画原型。现在我通常先把需求想清楚，直接做 Demo；评审时没有可体验原型，很多问题很难说透。Demo 稳定后，我再让 PRD Skill 根据现有结果反向整理文档，并补上 corner case、规则和验收细节。

为了提高还原度，我们有时不会从 Figma 重新描一遍，而是从研发代码仓库里取出前端关键页面、关键帧和动效，在已有结构上迭代。有一次需求评审，Demo 还原得过于真实，研发一开始甚至没有看出它不是正式上线版本。

这能显著减少重新描述页面的上下文，但我也很清楚：以假乱真的 Demo 不等于生产代码。它可能是“豆腐渣工程”，稳定性、可维护性和上线流程仍然需要专业研发把关。

离开工位时观察，回到工位后深度收尾

我会在会议间隙、排队或路上转发资料、下发任务，再通过手机观察长程任务是否走偏。桌面端则负责真正 hands-on 的部分：逐项检查、精细编辑、修复问题和最终交付。

所以多端协作的最佳方式，不是“手机代替电脑”，而是让任务不会因为我暂时离开工位就完全停下。

08办公助理还在解决多人协作的上下文问题#

普通任务通常彼此隔离，而办公助理可以持续使用更长的记忆，也能进入真实沟通渠道。除了个人派活，它还有一个很重要的方向：让人、自己的 Agent、同事和同事的 Agent 更顺畅地协作。

我曾经和研发一起排查 Bug。传统流程是我把问题发给研发，研发再把日志和描述交给自己的 Agent，等排查结束后再转述给我。后来我们把研发的 Agent 拉进群里，直接在同一个上下文里派任务。我能看到它正在做什么，也能在需求表述不准确时当场补充。

我也会用定时任务读取当天的会议和妙记，整理 Todo，甚至为需要跟进的人准备文案。这样做的前提，是尽量让工作信息在线上形成可追溯记录，并且始终知道谁发起、谁授权、谁最终确认。

09直播里，大家还问了这些问题#

每个项目都要建一个“第二大脑”吗

我没有为每个项目建一份。我的助手会在每天晚上统一遍历所有项目和当天对话，再提炼长期信息。创建这个 Skill 本身也不复杂：先跟 Agent 说明“我想每天统一上下文”，让它追问遍历范围、筛选规则和保存位置，再由我确认。

上下文越来越长，会不会变笨

分享时我提到，长对话会做自动压缩，项目检索也会利用缓存减少每次从头读取的成本。但任何压缩都可能丢掉细节，所以真正重要的业务事实不应该只留在聊天里，仍然要进入明确文档、规则或项目文件。

产品和技术人员的边界到底在哪里

我合作过的前端同学往往同时很有产品 Sense；我自己也会主动了解技术细节，减少沟通中的误解。但研发同学对稳定性、可上线性和工程质量的标准，仍然是非常专业、不可替代的。

AI 时代并不是不需要学底层、不需要看代码细节。我们只是能更快跨过一些执行门槛，距离“任何人都能把生产系统完美做好”还很远。与其相信所有岗位马上消失，不如把 AI 用来扩大自己的能力，再认真补上业务判断和专业底层。