给智能体装上一块看板，效果比换更强的模型、写更好的提示词都明显。这块看板由三个Markdown文件加一个Obsidian插件组成，它决定Claude Code该做什么、一件活什么时候算完成、什么时候该回来找人拍板。这些规则全部来自软件团队用了多年的待办清单、用户故事和验收标准，如今被套在一支智能体团队身上。
围绕AI智能体的讨论几乎全在编排上：工具调用、记忆层、多智能体路由。几乎没有人在谈怎么管理工作本身，作者自己的配置也缺了这一块。打开一个Claude Code会话，挑点东西让它做，然后放手跑。有时能成，很多时候会跑偏。上下文从一个会话渗到下一个会话，三天后回来，完全不知道事情处在什么状态、某个东西为什么被做成那样。问题从来不在智能体：是把工作流里所有管理结构都拆掉了，却指望结果不变。
看板本身是一个Markdown文件，由Obsidian Kanban插件渲染成三列：待办、进行中、已完成。每张卡片只是一个指向故事文件的维基链接，卡面上不放别的东西。故事文件按固定命名，内容包含目标、硬性门槛、阻塞项和工作日志。硬性门槛就是“完成”的定义，每一条都打勾之前，故事不会移动。某件事推进不下去时，卡片留在待办列并标记为阻塞，智能体不会悄悄跳过或放弃，而是标出卡片、说明阻塞原因，然后停下。
谁移动卡片，是这套配置的关键。作者让Claude去处理下一个故事，故事随智能体工作移入进行中，需要人来决定时再回到作者手上。Claude是唯一移动卡片的东西，所以看板没法对工作状态撒谎。没有故事，就不会有东西被动手做。故事移入已完成之前还有一步上下文更新：工作日志和项目的CLAUDE.md用来记录做了什么决定、为什么这么决定，而不只是记录建了什么。一个勾都没打的故事不算有效，靠感觉留不住有价值的经验。
团队是一个Markdown文件，列着具名角色，每个角色在流程的特定节点被调用。最有用的一个是规划委员会，六个智能体依次过一遍计划：批评者、反方、技术负责人、软件架构师、工程经理，最后由修订规划者综合前五个人的意见。每一个都针对前一个没指出的缺陷。
作者在重新设计一条活动分析流水线时，委员会指出了计划里的问题：把新的分类层和渲染改动一起上线，就没法隔离回归问题。修订后的计划把它们拆成两个故事：先以影子模式上线分类器，在已知案例上验证，然后才开启渲染工作。代价是两分钟的延迟，产出是两个故事而不是一个，每个都有更清晰的硬性门槛。
其余角色各有分工。编排者是默认模式，读看板、分派工作、把大任务拆成故事。技术负责人在任何架构性内容上线前被调用，设计师在写第一行标记之前跑一遍体验审查。想要快速过一遍，批评者会在一分钟内返回“继续”“修改”或“中止”。配合看板，每个故事从计划到完成都走同一条路径。
下一个要补的软件开发生命周期环节是复盘，目前有两个实验在进行。一个每周回顾技能，提供一个结构化的时刻退后一步，回看这一周并留下有用的部分。一个智能体复盘技能，跨会话寻找模式：常用哪些技能、哪些任务被重复或放弃、缺口在哪里。两个都还很粗糙。复盘是唯一一个把错误转化为流程的仪式，而智能体还无法为自己做这件事。
待办、故事、验收标准、角色和评审，这套做法已经用了十五年。AI智能体没有发明新的工作方式，只是给了一个需要管理的新团队。作者押注的就是这一点：软件开发生命周期的模式可以迁移，跟得越紧，智能体驱动的开发就越好。
开放问题依然存在。上下文无法完全跨越会话边界，决策理由会从记录里蒸发。跨会话、跨协作者的共享上下文尚未解决。上周在柏林的一场活动上，每个房间都绕回同样的问题，没有人破解。作者的猜测是，答案看起来很像问题本身：更好的故事交接、更好的会话摘要、更好的办法让工作日志成为事实来源。那意味着更深入投资旧实践，而不是发明新东西，尽管作者也还不确定。在那之前，让一支智能体团队保持正轨的，是三个Markdown文件组成的看板，低科技得有点难为情，却一直在做人团队里它一直做的事。
热门跟贴