AI 合伙人,关键在责任

下班后做产品，最怕的不是没人帮你写代码，而是没人帮你判断这个方向到底该不该继续。

我以前以为，要解决这个问题，可能需要一套更强的 Agent 框架。最好能有很多角色，能自动协作，能自己跑流程，把我一个人做项目时缺掉的那部分团队感补回来。

这个判断，是我自己折腾了一段时间以后才确认的。我试过把 AI 当临时顾问，也看过更复杂的多 Agent 工具。但真正让我感觉稳定下来的，不是某个系统突然变强了，而是我开始把每个 AI 的角色、责任、记忆和复盘写进本地文档里。

这篇不是介绍我有一套多复杂的 copartner 系统。相反，我越来越觉得，一个人刚开始搭 AI 合伙人，最不该先追求复杂。我真正想解决的，不是自动化，而是当我又快把自己说服的时候，有一个长期角色能把我拉回来。

一个人做产品时，很多问题表面上看起来是执行问题，实际是判断问题。比如一个功能要不要继续做，一条内容能不能发，一个方向要不要停，你总能找到理由说服自己再试一周。

最麻烦的地方就在这里：一个人做事时，你不是没有理由，你是理由太多了。今天问产品，明天问增长，后天问技术，每次 AI 都能给你答案，但这些回答未必会变成你的判断系统。

它不知道你上一次为什么停，也不知道你上一次为什么继续。更不会持续追问你：现在是不是又在用加功能逃避增长？是不是又在用写内容代替拿反馈？是不是为了让系统看起来完整，把一个本来可以很轻的东西做重了？

这就是我后来想做 copartner 的原因。不是为了让 AI 显得更像团队，是为了让我每次遇到同类问题时，不要重新从零判断。

我并不反对复杂的多 Agent 系统。但对我当时真正的问题来说，复杂系统不是第一步。因为我每天卡住的不是“怎么让更多 Agent 同时跑”，而是“这个问题到底应该由谁来判断”。

我也很容易被角色表、名字和流程图带来的架构感吸引。它看起来很像一个小团队，但后来我发现，如果一个角色没有责任边界，它就只是人设。今天让它看产品，它也能看；明天让它看增长，它也能讲；后天让它评价审美，它也能给意见。

这句话对我很重要。它让我从“我要几个 AI 角色”这个问题里退出来，开始问：这个 AI 到底负责帮我判断什么？它不负责什么？它每次出现，必须交付什么？如果这些问题没有写清楚，所谓 AI 合伙人就很容易变成一组名字好听的 prompt。

真正让我这套东西变稳定的，不是平台，而是本地文档。这听起来不酷，但它对我有用。

我现在会给每个长期 AI 合伙人建一个文件夹。比如我会把增长合伙人叫 Mars，它不是一个临时 prompt，而是一组固定文件：

copartner/mars/  system-prompt.md  working-rules.md  founder-profile.md  memory/    founder-memory.md    decision-log.md    growth-war-board.md    logs/2026-04.md    evolution-log.md

这不是为了显得工程化。是为了让它每次启动时都知道：它是谁，它负责什么，它不负责什么，它以前和我做过哪些判断，它现在最该盯住什么。

比如增长合伙人 Mars 负责把问题拉回线索、转化和成交，而不是陪我把内容写得更热闹。另一个方向判断合伙人 Dio，则负责判断一个产品长期值不值得做。你也可以不用给它们起名字，先叫“增长判断者”和“方向判断者”就够了。

记忆也是同一个逻辑。我不把记忆当聊天记录，而是分成几层：长期画像记录三个月后仍然影响判断的东西；决策日志记录以后不想反复讨论的判断；当前作战板只放 30 天内真正影响动作的重点；过程日志先接住那些还不能立刻变成结论的高价值讨论。

如果一条记忆不会改变以后怎么判断，那它就只是资料。资料多了，AI 不会更像合伙人，只会更像一个塞满文档的聊天框。

如果你也想搭一个最小 AI 合伙人，我不建议你一上来就搭系统。今晚只需要先建一个文件夹，然后给一个角色写清楚 5 件事：

你负责什么判断：你不负责什么事：你每次必须交付什么：什么时候应该叫你：什么内容需要写入记忆：

这 5 行比一大段人设更重要。因为它不是在描述这个 AI 的性格，而是在定义它的工作边界。写完以后，这个 AI 就不会每次都变成万能顾问。

先别急着搭系统。先选一个你最常遇到的问题：如果你总是做功能做重，就先建一个负责“技术是否过重”的角色；如果你总是发内容但拿不到反馈，就先建一个负责“内容是否靠近反馈”的角色。

一个人做产品，最先需要的不是一个 AI 团队，而是一个不会每次重新开始的判断者。