北京
早上八点，我端着咖啡打开看板。待处理列里躺着一个新任务：2026-07-12博客草稿，已排期。点进去，完整的博客初稿已经写好了。评论线程里留着两条凌晨的消息——01:01：收到，话题扫描完成，选定了任务管理概览这个方向，开始起草。01:03：完成，草稿已放入笔记，任务状态改为待审核。
作者不是人类。它是一个AI代理。在我睡觉的时候，它选好了题目，查了产品文档，写出了初稿，把任务卡片挪到了待审核列，还在评论线程里打了个招呼。
我读完草稿，回了一句：选题太宽了，找一个具体的用例，当成故事来讲。几分钟后，草稿被重写了一遍——你现在看到的这篇文章，就是那次重写的产物。这篇文章要讲的，是这个流程是怎么搭起来的，以及为什么任务系统才是人类和AI之间最自然的交接界面。
先聊一个核心设计理念：在UnDercontrol里，任务不是简单的待办事项，而是一个通用的信息容器。它可以是一条真正的待办——比如修登录页的校验bug。也可以是一份文档，一个设计方案、会议纪要、维基页面。还可以是一条决策记录，写清楚为什么最终选了B方案。当然，也可以是一篇博客草稿，就像这篇文章的初稿，它就是以任务笔记的形式存在的。任务的正文是Markdown格式，配合标签和自定义元数据，你决定任务是什么，而不是被工具的数据结构框死。
建产品的人都知道一个痛点：内容输出必须持续稳定，但写作的启动能量太高了。选题、收集素材、搭框架、写初稿——每一步都在消耗本该属于代码的精力。那让AI全自动写并且直接发布可以吗？不行，没有人类把关的内容，发出去就是在透支自己的信誉。
我要的是一个人类和AI协作的流程：AI干粗活，包括话题去重、文档调研和初稿起草；我只做那件真正值得我花时间的事——做判断、给反馈。问题来了：AI生成的内容放在哪？我在哪里看？反馈怎么传回去？答案是，所有环节全部落在任务系统里。
这个流程不需要搭建独立的AI平台，它完全由任务系统的四个原生能力拼装而成：定时任务、@提及、笔记和评论。每天凌晨一点，定时任务触发，创建当天的草稿任务。任务描述就是给AI的完整指令集，一上来就@了我的代理。指令很明确：生成一篇博客草稿供审核，不要跑完整的发布流程。第一，从auto/blog-topics.json里选题，用ud grep task命令检查哪些话题已经写过了，选第一个没覆盖到的。第二，只把文本草稿写进这条任务的笔记里。第三，把任务状态设为待处理。第四，在评论里简单回复完成情况。整个过程没有人类介入，但每一步都有迹可查，笔记、评论、状态变更全都留在任务卡片里。
这个设计的妙处在于，人机协作不需要切换到另一个系统。我早上打开看板，草稿就在平时看任务的同一个地方等我。我读完，直接在评论里给反馈，AI接着改。对AI而言，任务系统就是它的工作台；对我而言，它还是我的审核后台。两边的界面重合在同一块板子上，交接成本被压到了最低。一篇博客从选题到定稿的全生命周期，就凝结在一条任务的时间线里——凌晨生成、早上审核、接着修改、最终发布，每一步都可追溯。
做内容的人经常纠结一个问题：效率和掌控到底怎么平衡？全交给AI，速度有了，但内容里缺少真正的经验和判断，读者一眼能看出来。完全自己写，质量控制住了，但输出频率跟不上，产出焦虑很快就压过来。这个流程提供了第三种解法：把机械劳动交给AI，把策略判断留给自己。AI负责的是话题扫描、材料整理和初稿输出，它不替你做决策，它只是把一切准备好，等你说往哪个方向走。这种方式下，人的价值反而被放大了——你不用花精力在启动和执行的体力活上，可以把注意力集中在选题判断、结构取舍和语气把控上。这些东西才是内容真正的护城河。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
