AI写得越快，OPC越需要一份“产品决策账本”

AI一天能帮你完成几个功能，也能同时打开几个开发方向。但代码可以重构，产品决定不能失去来路——那些藏在代码里的业务承诺，一旦被AI“优化”掉，产品规则也就一并消失了。

本文提出一套OPC（一人公司）在产品开发中管理决策的实操框架：产品决策账本（Decision Ledger） 。它不是复杂软件，而是一本放在代码旁边的航海日志，专门记录那些会影响后续开发路线的决定。

一、为什么要记录决策？

开发产品时，有些决定容易被记住——选什么技术栈、卖多少钱、先做哪类用户。但另一些决定则安静得多：免费账户最多保存多少条记录，普通成员能否邀请新人，删除数据后保留几天，失败的支付要重试几次。

这些小决定数量很多，分散在不同阶段。它们被写进代码之后，很快便失去原来的面貌。几个月后重新看到一条判断，你可能只觉得它有些古怪，却想不起当初为什么坚持这样写。

AI恰好很擅长处理古怪的代码——它会建议合并重复逻辑、删除多余分支、统一权限判断，让整个项目显得更整洁。倘若那段“多余逻辑”背后藏着业务承诺，清理完成的同时，产品规则也被一并清理了。

一条合格记录至少要回答几个问题：当时遇到了什么情况，最后选择了什么方案，为什么这样选，还有哪些方案被放弃。它最好写明影响范围，以及什么条件出现时可以重新讨论。

示例：

免费用户最多创建三个项目。这个限制用于控制存储和模型调用成本，同时保留完整的试用体验。项目数量达到上限后，可以继续查看和导出已有内容，但不能创建新项目。若免费用户的付费转化率连续两个月低于目标，再重新评估上限。

这段话只有几十个字，却比代码中的if project_count >= 3多保存了很多东西。AI能看到数字，也能看到数字背后的商业考虑；它可以修改页面提示，却不会因为“优化体验”就擅自把限制改成五个。

记录发生变化时，旧决定要保留下来，标明已被哪一条新决定取代。代码遵循新规则，文档仍在描述旧规则——这种混乱是AI最擅长传播的。

并非所有决定都值得登记。按钮放左边还是右边、变量怎样命名，可以交给实现者判断。但权限、计费、数据和外部服务必须受到更严格的照看——这些地方一旦漂移，通常会直接影响用户权益。

权限： 最好做成一张简单的矩阵，Owner、Member、Guest分别能查看、创建、修改、删除和导出哪些内容。没有明确授权的操作默认禁止。

计费： 写明金额单位、扣费时点、退款条件和套餐降级后的处理方式。许多支付问题并非计算错误，而是产品没有把“什么时候算完成”“失败后怎么办”说清楚。

数据： 哪些信息可以发给第三方，哪些必须保存在自己的系统里，账户删除后保留多久，用户是否能够导出。这些规则可以放进一份CONSTRAINTS.md，措辞越直接越好，多使用“必须”“不得”和“只有在……之后才可以”。

很多人使用AI时，会在需求后面加一句“直接实现”。这句话省去了几轮沟通，也让AI隐藏的假设直接进入代码。

涉及账户、支付、权限或数据的功能，可以多加一个短步骤：要求AI在动手前写出它对需求的理解，并列出准备自行决定的部分。

提示词示例：

请先说明本次改动会影响哪些产品规则，并列出需求中没有明确说明、需要你自行假设的内容。凡是涉及权限、计费、数据流向、外部服务和架构变化的假设，等我确认后再实施。

这一轮通常只花几分钟，却很容易发现方向偏差。AI可能会告诉你，它准备允许所有成员发起邀请，默认删除账户后立即清空数据——它把想法写出来时，你会立刻知道哪里需要踩刹车。

完成代码后，换一个会话进行审查，并让它读取产品决策账本。别只问“有没有Bug”，可以问：

这次改动是否引入了需求之外的产品规则？是否改变权限、计费、数据边界或既有架构？请为每项判断提供对应的代码位置和决策依据。

OPC的发布检查表不宜太长。十个问题足够，其中最重要的几项：

这份检查表的价值不在于阻止所有错误，而在于让那些容易被包装成实现细节的决定重新浮到水面。产品可以改变，规则当然也可以推翻，只要变化留下了来路，责任仍由产品的主人承担。

AI把代码生产压缩得很快，一天可以完成几个功能，也可以同时打开几个方向。产品决策却仍需要慢一点，因为它们会进入用户习惯、合同承诺和数据结构，日后很难像代码一样随手重写。

给自己留一份产品决策账本，听上去没有自动生成整套功能那样令人兴奋。但当你在半年后打开项目，面对几十次AI修改留下的代码，它会帮你回答一个十分朴素的问题：这里为什么会是这个样子？

本文来自投稿，不代表OPC成长社区立场，如若转载，请注明出处：https://www.opc.cn