AI 写的文档越多我越看不懂自己的产品

最近，我让AI重新梳理几个项目的产品需求，却有了一个有点尴尬的发现：

这些项目是我发起的，但有些产品细节，我已经说不清楚了。

一个企业知识库、一个数据智能体，还有一个族谱小程序——它们都推进了一段时间，消耗了不少精力和额度，却还没到可以放心说“完整交付”的时候。

不是忘了要做什么。三个项目的主要方向，我当然还记得。可某些设计为什么这样定，哪些需求后来加了进来，哪些只是阶段性方案，眼下真正能用的是哪一部分，我越来越需要回头查。

设计文档并不少。恰恰相反，AI写得很勤快。

但文档越积越多，我并没有因此更了解自己的产品。

一、我不是不关心产品，而是真的看不过来了

现在，产品设计和开发中的很多工作，我都交给Codex推进。

它会写需求、拆流程、做设计、解释方案，再根据讨论继续调整。单独看每一次输出，似乎都很有道理。

问题是，我不是只做这一个项目。

三个研发项目在并行，此外还有备课、与人交流等事情。留给我仔细阅读设计的时间，被切得很碎。

有些内容我会认真看，有些只能大概扫一眼。对于我觉得不那么重要的推进点，往往就顺着AI的建议继续做。

我也有过这样的想法：先让它把产品做出来，我再从用户角度用一遍。体验不对、流程不顺、哪里有明显问题，到时候再反馈。

这并不完全是偷懒。实际使用确实能发现许多文档里不容易看出来的问题。

但它有一个前提：我得知道自己想要的产品是什么，也得理解那些关键设计意味着什么。

如果某个选择我当时就没弄明白，只是同意往下走，等实现以后再改，就不只是修一个按钮或一段代码了。

尤其是阶段目标的变化。有时为了先把一条流程做通，会暂时缩小范围，把其他需求留到后面。这本来很合理。但如果我没有把这些取舍连起来理解，只看到某一轮“通过了”的反馈，就可能误以为离原来想要的完整产品已经很近。

我需要的不是更多“这一轮做完了”，而是有人把这一轮放回整个产品里，告诉我它解决了什么，又留下了什么。

我开始担心：我参与了很多次“确认”，却没有因此保持对产品同等程度的理解。

二、以前团队评审替我完成的事，现在缺了一层

回想以前在公司做研发管理，产品评审不是把一堆文档发给我，让我自己看完。

产品经理会讲：为什么设计这个功能，给什么人用，准备解决什么问题，一些细节为什么这样安排。

我可以站在用户和业务的角度判断，研发负责人会考虑实现，测试人员会追问异常，UI、交互相关同事也会提出不同意见。

我不需要一个人预先想到所有问题。大家的解释、提问和争论，会帮助我逐渐理解这个产品。

而现在，我虽然让AI扮演过多个角色，却不等于这套评审过程自然就回来了。

AI可能把产品、研发、测试的文档都交给我，但“为什么这样做”“还有没有别的选择”“这个例外会造成什么后果”，仍然需要有人讲到我能判断的程度。

文档交到了我手里，不等于理解也一起交付了。

以前我更关心AI能不能持续干活。现在我发现，另一个问题同样重要：它持续推进的时候，我能不能跟得上。

只增加文档，未必能补上这一层。

真不知道那些 OPC是如何做到的。

三、先给自己留一个能看懂产品的入口

这次，我先做了一件看起来很普通的事：把三个项目的产品资料整理进自己的Obsidian知识库。

Obsidian是我正在使用的本地笔记工具。但这里的重点不是换软件，也不是给资料重新分一遍文件夹。

我希望每个项目都有一个短入口，先回答几件事：它给谁用，为什么做；现在真正做到了什么；还有什么没完成；主要卡在哪里；下一步准备到达什么里程碑。

如果确实需要我决定，再把那个选择单独说清楚。

完整需求和原始材料仍然保留，想追某个细节时可以继续往下找。但我不用每次都从一长串研发对话里，重新拼出整个产品。

我还希望把关键取舍的理由留下来。隔一段时间再看，不只是知道“现在这么设计”，还能知道“为什么走到这一步”。

对我来说，这才是本次整理和以前存资料不一样的地方：它要帮助我恢复对正在做的事情的理解。

不过，这个知识库不能变成另一套独立发号施令的地方。

当前研发采用哪份需求、允许做什么、什么已经验收，仍然要回项目里的正式记录核对。知识库里的阶段总览，要有日期和来源；新想法也不能写进去就自动算批准了。

否则，两边各改各的，AI读到一个版本，我看到另一个版本，反而会更乱。

本次整理时，每个项目里负责推进工作的AI，都已实际读取过相关资料，也安排了后续读取入口。但这只说明资料开始接上了，不能说明我已经重新掌握了所有细节。

四、关键变化不再只让我读设计，而是讲一遍用户怎么用

知识库能帮我找回背景，却不能替我评审。

所以，另一项调整，是我要求AI改变向我讲解关键产品变化的方式。

不要先给一篇长方案，再问我“是否同意”。先讲一个具体场景，把变化前后和异常后果说明白。

比如，设想一个族谱小程序里“补家人”的场景。下面只是我希望AI怎样讲清楚问题的示例，不是在描述当前设计或已经发生的缺陷。

一位普通成员想补充一位家人，点了提交。此时，页面告诉他的是“申请已提交”，还是“关系已经建立”？谁还需要确认？

如果负责人拒绝了，他再进入页面，会看到什么？如果提交失败，重试会不会让他误以为已经成功？

这些问题，我能从用户角度思考。

我需要知道：哪些行为早就批准了，这次只是照着实现；哪些准备改变；改变会影响谁；真正要我选择的是什么。

必要时，用一个小原型或页面演示，会比让我猜一段抽象描述更容易理解。

详细设计并不是不要了，只是先让我看懂产品行为，再按需要展开实现依据。

而且，这种评审只针对关键变化，不是要求AI把每个小动作都拿来问我。

已经批准范围内的普通实现、等价整理、常规修复，不应该因为换了一种汇报格式，又变成一串新的“请确认”。

没有新的产品取舍，就明确告诉我：本次不需要你再作产品决定。涉及费用、真实数据、部署等必要授权，仍然按原来的边界处理。

我要减少的是机械确认，不是把关键判断也一起放弃。

五、这不是我已经验证成功的方法

这两项调整刚开始，离证明有效还早。

在最初收到的回应中，其中两个项目的AI先把手上的事情分清了：哪些是在落实已批准的规则，哪些还缺必要的前置证据，并明确不需要我重复作产品决定。

这不是一份漂亮的新模板，也还不是一次完整的关键变化评审。它只能说明，新要求开始进入实际回应了。

接下来，我更想观察的是：隔一段时间，我能不能用短总览重新讲清产品；关键设计变化时，能不能更早发现自己没理解的地方；原来要翻聊天、反复追问的事，是否真的少了。

还有，这套资料维护会不会反过来增加负担。

如果最后只是文件越来越厚，我仍然说不清产品，那就得继续简化，而不是因为已经建了知识库，就坚持把它维护得更复杂。

我也不会把AI自己的总结，当成它已经做对了的证明。该看的实际行为、该核对的依据，还是要看。

这次反思让我重新认识到，所谓一个人借助AI做更多事，不只是把工作分出去。还得想办法，让自己的理解和判断跟得上。

AI可以帮我承担更多工作，但不能让我在不理解产品的情况下，逐渐退出产品决策。

你用AI推进项目时，有没有经历过“文档越来越详细，自己却越来越看不进去”的阶段？你是怎么找回产品全貌的？