三个 40 岁老程序员决定用 AI 重新出发（八）：人和 Agent 共用的待办清单

你好，我是曹犟。

在这个系列的上一篇文章中，我讲了我们的 Agent 如何替客户挡掉一笔不该花的预算。文末我预告了两个选题，一个是“做 AI 营销 Agent 的公司自己怎么做营销”，一个是“Agent 第一次叫停一个在烧钱的关键词”，这两篇都还在路上。

今天先插播一篇其它内容的，不讲客户，而是讲我们自己。前两天，我花了大约半个小时，和 Claude Code 给三个人搭了一套待办同步系统。事情很简单，但是回头看，里面把“人和 Agent 怎么协作”这件事讲得很清楚，值得记录一下。

一、需求很小，但判断标准变了

我们三个人的日常工作，现在已经高度 AI 化了。写文档、改代码、做客户方案、出周报，基本都是人和 Claude Code 一起干。在干的过程中，经常会冒出一些需要对方配合的事情：让一位同学看一份刚写完的客户档案，让另一位确认一个接口的口径，或者其他两个人让我审一段对外的文案。

这类事情我们以前怎么处理？在企业微信里说一声，at 一下。之后呢？很大概率淹没在群里面的海量聊天记录里。三个人都忙，也没时间追着问“你看了没”，过两天想起来再翻聊天记录，可能已经错过了当时的时机。

所以我想要有一个三个人的待办同步系统。需求列出来其实就三条：

1. 工作中随时可以给对方分配一件事，比如“看一下某个文档”；

2. 这个系统必须对 AI 友好：我的 Agent 可以替我给别人建待办，对方的 Agent 能看到分给自己的待办，跟 Agent 一起把活干完之后，Agent 顺手就能把待办勾掉；

3. 神策内部用企业微信，但它的 cli 目前并不完善，对十人以上的组织基本没有开放。

如果是几年前，我去挑一个待办软件，比较的是界面顺不顺手、提醒灵不灵。但现在选型的第一标准变了：不是人用着顺不顺手，而是 Agent 用着顺不顺手。在我们的工作流里，Agent 和人是同等地位的；待办的第一个读者和第一个写入者，往往不是人，是各自的 Agent。

而市面上的待办软件，对人都很友好，对 Agent 就没那么好用：要么没有像样的接口，要么要走一堆授权，要么部署太重，Agent 每次读写都隔着一层。

二、方案：数据放 Git 仓库，企业微信只负责通知

我把需求交给 Claude Code，让 Fabel5（当时还是可用状态）帮我想方案。它先干了一件让我有点意外的事：没有急着推荐工具或者设计方案，而是先把我们仓库里已有的基建盘了一遍，然后告诉我，你们其实已经有两块现成的东西可以复用。

第一块，我们的部署脚本里已经有一个企业微信的消息推送，每次发测试版本会自动往群里发通知，消息通道是现成的。第二块，我们仓库里已经有一个 Git 钩子，每次推送代码时，如果改动了客户跟进记录，会自动把它同步到线索系统。也就是说，“文件一变就自动触发动作”这条路，我们已经跑过。

于是它给出的方案很简单：待办的数据放在 Git 仓库的纯文本文件里，企业微信降级成通知通道。

具体方案大概是这样的。仓库里建三个文件，分别对应一个“被分配人”。给谁派活，就往谁的文件里加一行；想看自己的待办，Agent 读自己那个文件就行；干完了，把那一行勾掉。

每一行大概长这样：

- [ ] T-0612-01 ｜ from 曹犟 ｜ 2026-06-12 ｜ 看一下 docs/strategy/xxx.md 的定价部分，周五前给意见

通知怎么实现？放在 Git 钩子里。每次推送代码，钩子检查这批提交有没有动过待办文件，有就解析变化：新增了一行未完成的，往群里发“新任务”并且 @ 被分配的人；某一行从未完成变成了已完成，发“已完成”并且 @ 当初创建它的人。

为什么通知放在钩子里，而不是放在操作入口里？因为不管这条待办是谁建的、从哪里建的，是人手敲的还是 Agent 顺手写的，只要进了仓库，通知就不会漏。入口可以有很多个，出口只有一个。

最后再配一个 /todo 的 Skill，相当于一份操作手册，告诉 Agent 这套系统怎么用：建待办先拉取最新代码，任务编号怎么生成，完成之后行尾要补一个完成日期，提交信息写成什么格式。关于 Skill 这个概念，我在系列第六篇里展开讲过，简单说就是用自然语言写成的、给 AI 看的 SOP。

这个方案里我最喜欢的一个细节是：待办内容里如果涉及仓库里的文档，直接写文档的相对路径。这样对方收到“看一下某份档案”的待办时，他的 Agent 拿到路径就能直接打开那份文档，连找都不用找。这是任何外部待办软件都给不了的体验：任务和完成任务所需要的上下文，存在同一个仓库里。

三、搭建过程：一问一答里全是细节

方案定了，剩下的就是实现。整个过程更像结对编程，它写，我看，中间几次关键的拍板都在一问一答里完成。

我对方案的第一个问题是：“这个 Skill 搭出来，他们俩 pull 一下代码就能直接用了吧？”

它的回答分了三层：Skill 本身进了仓库，拉下来就能用；但 Git 钩子出于安全考虑不会自动启用，每个人要手动跑一次启用脚本；然后它顺手检查了一下我这台机器，告诉我一个尴尬的事实：我自己机器上的钩子就没启用。也就是说，之前说好的“客户台账自动同步”，在我这台电脑上其实一直没在运行。

这个检查动作很有意思，如果它只回答我“pull 了就能用”，这个坑就埋下去了。一个靠钩子驱动的系统，钩子没启用，所有自动化都是装饰。

第二个问题是 @ 人。群里发通知，想真正 @ 到人，需要每个人在企业微信里的账号标识。这个信息 Agent 自己拿不到，于是我打开企业微信的管理后台，把三个人的资料页截了三张图发过去。它从截图里读出三个账号，又自己跑去查了 Git 的提交记录，把每个人的 Git 提交名和企业微信账号对上，做成一张映射表写进了系统。我们三个人在这个仓库里一共有两千多次提交，三个身份对得清清楚楚。

然后是测试。它没有直接拿真实数据试，而是先造了两个临时提交，模拟“新增一条待办”和“勾掉一条待办”，空跑了一遍通知逻辑，确认消息内容和 @ 的人都对，再把临时提交撤掉。确认没问题后，才正式上线。

上线后的第一条真实待办，是发给另外两位同学的同一句话：“拉一下代码，跑一次启用脚本，把待办通知的钩子装上。”

用系统本身，去通知另外两个人安装这个系统。这条待办推送出去的那一刻，新任务通知也顺手测了一遍。等他们俩装完、把这条待办勾掉，完成通知也会跟着测到。一个系统上线后的第一个任务是部署它自己，这个收尾我很满意。

四、翻车：接口说成功了，群里没收到

第一条待办推出去之后，脚本显示发送成功，企业微信的接口返回也是成功。我切到我们三个人的常用群一看：什么都没有。

查下来原因很简单。我们复用的那个消息通道，是当年配部署通知时建的，它绑定的是另一个群。消息确实发出去了，发到了一个我们很少看的群里。接口没有撒谎，它只是把消息忠实地送到了错误的地方。

修复只花了几分钟：在常用群里建一个新的消息通道（顺便说一句，企业微信现在有个新产品叫“各种消息”，可以直接给群配消息推送，不用再挂一个机器人），把密钥换进脚本，重发，这次群里收到了，@ 也生效了。

但这次翻车给我的提醒挺有意思：接口返回成功，不等于用户收到了。Agent 能验证的是“调用成功”，验证不了“真的到了该到的地方”。最后一公里的验收，目前还得人来做。我看一眼群里有没有消息，这一步 Agent 做不了，因为它根本不在那个群里。

五、半小时之后，我记住的四件事

事情本身讲完了，从讨论方案到全链路跑通，总共大约半个小时。回头复盘，有四件事。

第一，给 Agent 选适合它的载体。

这套系统最关键的选择，是把数据放在纯文本和 Git 里，而不是某个待办软件里。纯文本加 Git，是 Agent 读写最方便的介质：读就是读文件，写就是改文件，同步就是拉取和推送，历史记录天然就有。与其逼着 Agent 去适配人类软件的残缺接口，不如把数据搬到 Agent 顺手的地方，把人类软件降级成一个响铃的喇叭。

这个判断不只适用于待办系统。以后给团队选任何工具，“Agent 用它顺不顺手”都会是一票否决项。

第二，软件分发变成了文档分发。

这套系统“部署”到另外两位同学那里，靠的不是安装包，是一份进了 Git 仓库的 Skill 文档。他们拉下代码，各自的 Agent 读到同一份操作手册，行为就自动一致了。三个人的三个 Agent，都按同一份 SOP 干活。放到传统组织管理里，这件事叫统一作业标准；放到 AI 团队里，它变成了一份可以被 Agent 直接执行的文档。系列第六篇讲过 Skill 驱动的逻辑，这次就是它在一个最小的场景上的实践。

第三，把主动性写进 CLAUDE.md。

系统搭完之后，我让 Claude Code 在我们仓库的 CLAUDE.md 里加了两条约定：工作中出现需要他人配合的事项，Agent 要主动提议建待办；每次会话开始，Agent 要顺带看一眼对应的人名下有没有未完成的待办。CLAUDE.md 是 Claude Code 每次会话都会先读的项目说明文件，写在里面的规则，对我们三个人的 Agent 都生效，相当于这个仓库的章程。

这两条补充进去，这套系统才算真正可用。否则它只是一个等人想起来才会被用的工具。写进 CLAUDE.md 之后，Agent 会在干活的过程中自己说“这件事得让另一位同学确认，要不要给他建个待办”，也会在每天第一次开工时提醒我“昨天有人给你派了个活”。三个 Agent 通过 Git 仓库这块共享的黑板，开始异步地替三个人传递工作。

第四，人留下的四件事：需求、拍板、供给、验收。

这半个小时里我实际做的事情其实很简单。需求：告诉 AI 我想要一个什么样的系统；拍板：方案选 Git 还是选外部软件，通知发哪个群，用账号还是手机号来 @ 人。供给：截三张通讯录的图，建一个消息通道，把密钥给它。验收：看一眼群里到底收没收到。剩下的工作，包括盘点基建、写代码、造测试数据、查身份映射、发现我机器上没启用钩子，都是 Agent 自己干的。

这个分工并不是我有意设计出来的，是干着干着自然形成的。但事后看，这时间事情恰好就是人更该留在手上的：需求的提出，方向上的决策，Agent 够不着的信息，以及最后一公里的真实性确认。

尤其是真实性确认这件事，Agent 的世界目前停在接口返回值上，而真实世界在接口的另一头。在两边接上之前，人就是那个站在旁边点头的角色。

回到这个系列的主题。我们这个三个人的小团队，从第一天起就在试验一种新的组织形态：人很少，Agent 很多。以前我觉得这句话的重点在“Agent 替人干活”，这次搭待办系统让我意识到，更有意思的部分在后面：当每个人都有自己的 Agent 之后，协作系统本身也要为 Agent 重新设计一遍。待办、文档、周报、交接，这些组织里最日常的东西，都值得按“Agent 也是真用户”的标准重新过一遍。

而我们先从一个待办清单开始了。